Severe performance regression in Control.Foldl.vector when using vector-builder

foldl-1.2.5
module Main where

import qualified Data.Vector.Unboxed as V
import qualified Control.Foldl as L

main :: IO ()
main = do
    v <- L.foldM L.vector [1..10000000::Int]
    print . V.maximum $ v

10000000
     971,706,320 bytes allocated in the heap
          13,496 bytes copied during GC
      83,887,216 bytes maximum residency (9 sample(s))
       2,071,424 bytes maximum slop
             168 MB total memory in use (5 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      1388 colls,     0 par    0.000s   0.002s     0.0000s    0.0000s
  Gen  1         9 colls,     0 par    0.000s   0.016s     0.0018s    0.0147s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.172s  (  0.164s elapsed)
  GC      time    0.000s  (  0.018s elapsed)
  EXIT    time    0.000s  (  0.015s elapsed)
  Total   time    0.172s  (  0.197s elapsed)

  %GC     time       0.0%  (9.2% elapsed)

  Alloc rate    5,653,564,043 bytes per MUT second

  Productivity 100.0% of total user, 90.6% of total elapsed

vector-builder-0.3.1
module Main where

import qualified Data.Vector.Unboxed as V
import qualified Control.Foldl as L
import qualified VectorBuilder.Builder as N
import qualified VectorBuilder.Vector as O

main :: IO ()
main = print . V.maximum $ L.fold (L.foldMap N.singleton O.build) [1..10000000::Int]

10000000
   2,914,242,624 bytes allocated in the heap
   4,551,665,120 bytes copied during GC
     823,919,352 bytes maximum residency (15 sample(s))
      68,425,232 bytes maximum slop
            1697 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      5425 colls,     0 par    2.859s   2.754s     0.0005s    0.0012s
  Gen  1        15 colls,     0 par    3.219s   3.557s     0.2371s    0.8895s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.906s  (  0.911s elapsed)
  GC      time    6.078s  (  6.311s elapsed)
  EXIT    time    0.016s  (  0.161s elapsed)
  Total   time    7.000s  (  7.383s elapsed)

  %GC     time      86.8%  (85.5% elapsed)

  Alloc rate    3,215,715,998 bytes per MUT second

  Productivity  13.2% of total user, 14.5% of total elapsed

foldl-1.3.1
module Main where

import qualified Data.Vector.Unboxed as V
import qualified Control.Foldl as L

main :: IO ()
main = print . V.maximum $ L.fold L.vector [1..10000000::Int]

10000000
   2,914,242,624 bytes allocated in the heap
   4,551,665,120 bytes copied during GC
     823,919,352 bytes maximum residency (15 sample(s))
      68,425,232 bytes maximum slop
            1697 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      5425 colls,     0 par    2.625s   2.750s     0.0005s    0.0011s
  Gen  1        15 colls,     0 par    3.078s   3.549s     0.2366s    0.8859s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    1.156s  (  0.907s elapsed)
  GC      time    5.703s  (  6.299s elapsed)
  EXIT    time    0.016s  (  0.162s elapsed)
  Total   time    6.875s  (  7.369s elapsed)

  %GC     time      83.0%  (85.5% elapsed)

  Alloc rate    2,520,426,053 bytes per MUT second

  Productivity  17.0% of total user, 14.5% of total elapsed

cc: @nikita-volkov

Woops. I'll take a look

Alright! I've applied some optimizations there, increasing the performance several times. I've also added more benchmarks including the subject case. GC is still hard, but at least the performance is now still better than of the vector-growing fold. That is, even when building the vector of size 10,000,000 (as in the subject).
However, it takes forever to run even larger benchmarks, so I am not certain now that the algorithm will perform better then, which is why I think it'll make sense to restore the older vector fold in this library and have both alternatives coexist.

Yep. Here's the source: https://github.com/nikita-volkov/vector-builder/blob/455ca422c6e97f9268ddfe1234e989b95441c5ac/foldl-benchmark/Main.hs

ok, every vector is boxed. Is it vector of boxed values?

i'm more interested in the Unboxed/Storable case

The last set of results are a little surprising because up until then the default implementation's performance scaled linearly with the number of elements, but then a 10x increase in elements ran 40x slower

IMO pretty normal for something with 5GB RES.

What's weird is that the performance difference that @klapaucius is seeing is significantly larger than the one that @nikita-volkov  is measuring
@klapaucius: Also, do you get the same results when using Control.Foldl.vector from foldl-1.3.1?

i's difference between Data.Vector and Data.Vector.Unboxed , so performance difference is actually understandable.

foldl-1.2.5 Data.Vector
10000000
     411,952,312 bytes allocated in the heap
     490,201,792 bytes copied during GC
     169,415,272 bytes maximum residency (9 sample(s))
       2,056,576 bytes maximum slop
             369 MB total memory in use (50 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0       298 colls,     0 par    0.578s   0.572s     0.0019s    0.0668s
  Gen  1         9 colls,     0 par    0.219s   0.275s     0.0306s    0.1178s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.094s  (  0.171s elapsed)
  GC      time    0.797s  (  0.847s elapsed)
  EXIT    time    0.000s  (  0.033s elapsed)
  Total   time    0.906s  (  1.051s elapsed)

  %GC     time      87.9%  (80.6% elapsed)

  Alloc rate    4,394,157,994 bytes per MUT second

  Productivity  12.1% of total user, 19.4% of total elapsed

foldl-1.3.1, vector-builder-0.3.3 Data.Vector
10000000
   1,938,887,592 bytes allocated in the heap
   2,076,921,448 bytes copied during GC
     630,191,328 bytes maximum residency (11 sample(s))
       8,271,064 bytes maximum slop
            1088 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      3541 colls,     0 par    1.406s   1.482s     0.0004s    0.0468s
  Gen  1        11 colls,     0 par    1.172s   1.565s     0.1423s    0.5815s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.594s  (  0.411s elapsed)
  GC      time    2.578s  (  3.047s elapsed)
  EXIT    time    0.000s  (  0.131s elapsed)
  Total   time    3.172s  (  3.590s elapsed)

  %GC     time      81.3%  (84.9% elapsed)

  Alloc rate    3,265,494,891 bytes per MUT second

  Productivity  18.7% of total user, 15.1% of total elapsed

foldl-1.2.5 Data.Vector.Unboxed
10000000
     971,706,320 bytes allocated in the heap
          13,496 bytes copied during GC
      83,887,216 bytes maximum residency (9 sample(s))
       2,071,424 bytes maximum slop
             168 MB total memory in use (5 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      1388 colls,     0 par    0.000s   0.003s     0.0000s    0.0001s
  Gen  1         9 colls,     0 par    0.000s   0.017s     0.0019s    0.0157s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.156s  (  0.198s elapsed)
  GC      time    0.000s  (  0.020s elapsed)
  EXIT    time    0.000s  (  0.016s elapsed)
  Total   time    0.156s  (  0.234s elapsed)

  %GC     time       0.0%  (8.4% elapsed)

  Alloc rate    6,218,920,448 bytes per MUT second

  Productivity 100.0% of total user, 91.5% of total elapsed

foldl-1.3.1, vector-builder-0.3.3 Data.Vector.Unboxed
10000000
   1,938,809,440 bytes allocated in the heap
   2,076,900,352 bytes copied during GC
     630,113,176 bytes maximum residency (11 sample(s))
       8,349,216 bytes maximum slop
            1088 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max pause
  Gen  0      3541 colls,     0 par    1.172s   1.193s     0.0003s    0.0124s
  Gen  1        11 colls,     0 par    1.172s   1.504s     0.1367s    0.5151s

  INIT    time    0.000s  (  0.000s elapsed)
  MUT     time    0.438s  (  0.408s elapsed)
  GC      time    2.344s  (  2.697s elapsed)
  EXIT    time    0.016s  (  0.114s elapsed)
  Total   time    2.812s  (  3.220s elapsed)

  %GC     time      83.3%  (83.8% elapsed)

  Alloc rate    4,431,564,434 bytes per MUT second

  Productivity  16.7% of total user, 16.2% of total elapsed

I've updated my benchmarks to include unboxed vectors. For some reason this time the boxed version starts losing at 100,000. The same applies to the unboxed one as well.
 So it tells very little about real performance on large object trees with zillions of refs.
After 100K it's literally GC benchmark:
1M
MUT     time    0.031s  (  0.021s elapsed)
GC      time    0.078s  (  0.100s elapsed)

10M
MUT     time    0.125s  (  0.157s elapsed)
GC      time    0.766s  (  0.836s elapsed)

100M
MUT     time    2.953s  (  2.521s elapsed)
GC      time   19.266s  ( 21.591s elapsed)

So it's critical to have vectorM or something with less memory pressure because, if you can afford many gigs of wasted RAM, 0.5 sec pauses and abysmal 15% MUT productivity why bother to use foldl at all? Isn't it library for efficient, low memory footprint consumption of large datasets?

Either way I'll add vectorM.  I was just wanted to make sure that I understood the difference in results

This is now up on Hackage as foldl-1.3.3


Incorrect windows path for debug

The folder on windows is c:\host\k

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 92e345df-2425-d3ea-2d98-53949bc9314a
Version Independent ID: 171f79d7-e1a6-efa0-d45c-cfdc81faf3c0
Content: View kubelet logs in Azure Kubernetes Service (AKS) - Azure Kubernetes Service
Content Source: articles/aks/kubelet-logs.md
Service: container-service
GitHub Login: @zr-msft
Microsoft Alias: zarhoads

@perosb Thank you for bringing this to our attention!  We are reviewing the documentation and will get back to you shortly.

@perosb All of our repros so far result in c:\k.  We're trying a couple other setups but so far we've been unable to reproduce this.


Swift 3.1

Hi,
I followed the instructions on building AudioKit but I use the latest Xcode and it complains about audiokit not working with Swift 3.1. Am I missing something here?

How are you using AudioKit, from source, as a CocoaPod, from Carthage?  AudioKit works with the latest official releases.  Are you using Xcode beta?

Yes, I have a project using the latest beta of Xcode 8.3 and I tried AudioKit via Carthage.

This seems to be the issue with yesterdays release of 10.12.4 and Xcode updating using swift 3.1.


The AST node won't get fixed unless a field mapper is specified

The mapSchema function from @graphql-tools/utils function doesn't rewire the astNode in the GraphQLSchema object unless a field mapper is specified. This leads to errors when printing the schema to string.

Thank you @joseph-neeraj, can you please also add a changeset as described in https://github.com/n1ru4l/graphql-public-schema-filter/pull/174#issuecomment-1335325843 please?

done @n1ru4l  👍


Patches for 4.16.13162

v52:

[X] Testdata (@geek1011: d01e64ef0fdf76614b719c5ec75d690e78eb6683)
[X] Update patches (@geek1011: 5b5bdec0f4f880e1b53288c0f96574e8b96f83a5)

[X] GeoffR's footer patches broke, now in zlib, needs to be made shorter (@geek1011: 72e8318d8e6e39cb3afc6fd9f218d80fc6e78592, f330b3e46cb9665e4f43e56eceaf5087d1da5c79) (@geoffreynolds: needs to do other patch)
[X] Keyboard patches broke (@geek1011: 72e8318d8e6e39cb3afc6fd9f218d80fc6e78592) (@geoffreynolds: needs to finish updating)
[X] Kepub chapter progress size patch broke (@geek1011: 0ddd0d255950ad66234f9bb69751aaf950e7c2e9)

[X] Add to tests (@geek1011: 7064a5fa60b432cd11e5304265bc606ada7f3409)
[ ] Wait for proper firmware release
[ ] Release (@geek1011)
[ ] Post on MobileRead (@geek1011)

v52/v53:

[ ] Maybe fix #9
[ ] Update/fix remaining patches (@geoffreynolds)

[ ] 24 line spacing values (@geoffreynolds)
[ ] ePub fixed/adjustable margins (@geoffreynolds)
[ ] Footer patches (@geoffreynolds)
[ ] Keyboard patches (@geoffreynolds)

[ ] Release (@geek1011)

I've made some notes about this firmware version here: https://github.com/geek1011/kobopatch-patches/blob/master/src/versions/4.16.13162/notes.txt

Replaced by #18.


Panics on comparison of booleans

Comparison on booleans panics.
 $ xq -n 'false < true'
thread 'main' panicked at 'internal error: entered unreachable code', src/intrinsic/comparator.rs:99:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

xq: 0.1.0-d3808e624efc78b26ebd3c464bea59132f83aec8

Oooops, Nice find! This is a bug I introduced while I was changing Value::True and Value::False to Value::Boolean(bool).


URL text is smaller than other elements in table

I believe the design calls for 14px throughout the table entries, @bia can you confirm?
It appears the name is 14px and the others (type namespace status etc) are all 16px which is very jarring to me

Weird, probably related to the use of a <Link /> component there

Yes, all table text is 14px in the design.


HybridDataManager - Adding SDK version 1.0.1 to correspond to API version 2019-06-01

PR for spec merge of API version 2019-06-01 is https://github.com/Azure/azure-rest-api-specs/pull/8676

kindly ping @prtank

Hi,
I have been waiting for the swagger spec PR to be merged before I take care of these changes. I am expecting that to go through today so I will take care of all these comments before Monday.
Thanks for reviewing in advance :)

Hi @prtank generally the API spec needs to be merged into master BEFORE you generate SDK and submit this PR.
I noticed that the PR is missing a change to /eng/mgmt/mgmtmetadata/hybriddatamanager_resource-manager.txt, also the license headers are difference. I suspect it's caused by running autorest directly, rather that our recommended way: running src/generate.ps1 in your module.
So, please do the following things after the swagger review PR is merged:

Edit src/generate.ps1, change -AutoRestVersion "latest" to "2.0.4413"

Run it to generate SDK

In case you encounter any error, please refer to our document: https://github.com/Azure/adx-documentation-pr/blob/master/engineering/adx_netsdk_process.md#generating-net-sdk

Make sure you check in the txt file mentioned above

Thank you

I have pushed the changed for AutoRest version 2.0.4413, but am curious as to why we are using that specific version instead of the latest - 3.0.6187


About DETR

Dear author, sry to bother you.
I want to ask do you use DETR？I didn't find the code about the DETR, but you thank the DETR in the Acknowledgement.

Thank you for your attention to detail in our project. We indeed drew inspiration from the DETR codebase, particularly focusing on its training and inference pipeline as well as the logging components.

Thank you for your patient responses. I also wanted to inquire about the possibility of making the IMD2020 datalist.json and hdf5 files publicly available


Zoom on individual series

What problem does this feature solve?
Our team would like to have the ability to zoom on indivual series. It could work by selecting a series i a line plot containing multple series, and then apply zoom on the y-axis. Only that series would zoom while the other series would remain unchanged.
I ould not find support for this functionality in the documentation
What does the proposed API look like?
dispatchAction({
    type: 'dataZoom',
    // Optional. If set only zoom on that series data set
    seriesDataIndex: number
    // optional; index of dataZoom component; useful for are multiple dataZoom components; 0 by default
    dataZoomIndex: number,
    // percentage of starting position; 0 - 100
    start: number,
    // percentage of ending position; 0 - 100
    end: number,
    // data value at starting location
    startValue: number,
    // data value at ending location
    endValue: number
})

Sorry that I didn't quite understand the requirement. What do you mean that only one series will be zoomed? How should the axis be if other series not zoom? It would be helpful if you can provide a demo illustration.

Thank you for answering :-)
We have configured multiple y-axis so only the y-axis connected to the series would zoom together with the series.
I will ask our designer if he can make an illustration.

Have you tried dataZoom action? What's the problem with it?
You may need to provide a minimal demo to better illustrate the problem.


Suggestion

Speed option for define moving speed when sentinel have target. For example set path points /npc path set patrol speed /npc speed 0.7 and set /sentinel speed 1 for speed when sentinel attack target. After target killed npc back to patrol speed 0.7

Excellent idea. Will add :)

Sorry for taking so long to do this. Added now! :)


Export additional types

Currently, the ProtoCatCall type is not exported from the public API, which requires the service implementer to either:

Type it as any and loose type safety entirely
Write his own type mimicking ProtoCat's one

Could we expose this type (and possibly others I can't think of) from the public API?

Sure we could. I will try to get to it early next week, but feel free to post a PR.
As a current workaround until next realease, which is unaesthetic, but better than any or copy-paste is to import from dist subdir.
import { ProtoCatCall } from 'protocat/dist/lib/server/call'

Thanks for reporting 👍

Released under 0.5.2 :rocket:

Thanks!

Thanks!


Update span.h to fix breaks

Hasn't been built for a while, so some errors crept in. This should allow compiling on certain older compilers/platforms again.

Still fail on MacOS with
add_compile_definitions(USE_CXX17=1)
message("USE C++17")
set(CMAKE_CXX_STANDARD 17)

Would you mind using absl::span? Then we will not need to spend time on maintaining this file.

Anyway gtest, protobuf and a lot of others already depends on absl.


Add a type attribute to easily identify the type of a rephrased constraint

One can't use isinstance, since most non-parametric constraints are instance of Rephraser. This makes it difficult to write custom code like the one in https://github.com/janluke/cloup/discussions/79#discussioncomment-1046221.

Reverted the commit because this was a non-issue: non-parametric constraint can be checked for identity!
if constraint is mutually_exclusive:
    ...


Updating the redirecting links

Hey Team
There is a problem with this redirecting links so I am updating this.
We’d love to provide a smooth experience for RabbitMQ users who need to use monitoring solutions, such as New Relic.
Thank you for your consideration.

@sjyothi54 Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@sjyothi54 Thank you for signing the Contributor License Agreement!

Thank you


Additions/modifications

Hi Matthias,
First, this is not an issue as such :-)
Second, great work you have done here. Now then, I'm working on an "HomeKit to MQTT Server" that allow bidirectional communication between HomeKit (using your HomeControl) and devices communicating via the MQTT protocol. So far I've made a new transport based on
'ip_transport.go' and a few additions/modifications here and there (including adding new accessories).
So the question is: are you willing to accept PRs (if the code is ok of course)?
If I commit/sync to github you can have a look - any interest?
/michael

This library is only about the HomeKit Accessory Protocol. You should make a separate repository because your additions are related to a different protocol.

Perhaps I didn't explain it well enough: The other protocol, MQTT, is not
part of "my" updates/additions - that takes place outside HC. It's only HAP
but I had to re-arrange some code to get things such as "auto-discovery" to
work.
/michael
2016-09-05 9:41 GMT+02:00 Matthias<EMAIL_ADDRESS>
This library is only about the HomeKit Accessory Protocol. You should make
a separate repository because your additions are related to a different
protocol.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/brutella/hc/issues/56#issuecomment-244678738, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH26WwhAWFin0qp04Ve9Br0vcKAWUjw5ks5qm8eSgaJpZM4J0jR_
.

Lets make pull requests and discuss your changes there.


Allow to specify environment in sfI18nExtractTask

Sf18nExtractTask did not allow to set up environment while extracting strings from project.
When you create environment you can set different translation engine for production and development. While extracting string there was no option to specify which translation source you want to use.
This PR adds missing parameter to the task.

Default environment set to dev as asked

And finally, could you cleanup your commits? Like squashing them to avoid the merge commit you just introduced.
Thanks !

cleaned up :)

@filipc What happen? You force-pushed your master branch and kills the PR :confused:

Yes, I've force-pushed that changes. My mistake.  Please merge #92 instead.


[AzureRmWebAppDeploymentV3] Bump up version of lodash to resolve security alert

Task Name
AzureRmWebAppDeploymentV3
Issue Description
This task has dependencies on archiver and nock which have critical vulnerabilities.
Error logs
To get these error logs you can run npm audit from the Tasks\AzureRmWebAppDeploymentV3 directory:
PS D:\microsoft\azure-pipelines-tasks\Tasks\AzureRmWebAppDeploymentV3> npm audit

                       === npm audit security report ===

# Run  npm update lodash --depth 4  to resolve 5 vulnerabilities

  High            Command Injection
  Package         lodash
  Dependency of   archiver
  Path            archiver > archiver-utils > lodash
  More info       https://npmjs.com/advisories/1673

  High            Command Injection
  Package         lodash
  Dependency of   archiver
  Path            archiver > zip-stream > archiver-utils > lodash
  More info       https://npmjs.com/advisories/1673

  High            Command Injection
  Package         lodash
  Dependency of   archiver
  Path            archiver > async > lodash
  More info       https://npmjs.com/advisories/1673

  High            Command Injection
  Package         lodash
  Dependency of   archiver
  Path            archiver > lodash
  More info       https://npmjs.com/advisories/1673

  High            Command Injection
  Package         lodash
  Dependency of   archiver
  Path            archiver > zip-stream > lodash
  More info       https://npmjs.com/advisories/1673

To get these error logs you can run npm audit from the Tasks\AzureRmWebAppDeploymentV3\Tests directory:
PS D:\microsoft\azure-pipelines-tasks\Tasks\AzureRmWebAppDeploymentV3\Tests> npm audit

                       === npm audit security report ===

# Run  npm update lodash --depth 2  to resolve 5 vulnerabilities

  Low             Prototype Pollution
  Package         lodash
  Dependency of   nock [dev]
  Path            nock > lodash
  More info       https://npmjs.com/advisories/577

  High            Prototype Pollution
  Package         lodash
  Dependency of   nock [dev]
  Path            nock > lodash
  More info       https://npmjs.com/advisories/782

  High            Prototype Pollution
  Package         lodash
  Dependency of   nock [dev]
  Path            nock > lodash
  More info       https://npmjs.com/advisories/1065

  Low             Prototype Pollution
  Package         lodash
  Dependency of   nock [dev]
  Path            nock > lodash
  More info       https://npmjs.com/advisories/1523

  High            Command Injection
  Package         lodash
  Dependency of   nock [dev]
  Path            nock > lodash
  More info       https://npmjs.com/advisories/1673

Dependencies has been updated. Please find the below PR for reference.
Thank you.
https://github.com/microsoft/azure-pipelines-tasks/pull/15460


[SPARK-40618][SQL] Fix bug in MergeScalarSubqueries rule with nested subqueries using reference tracking

What changes were proposed in this pull request?
This PR reverts the previous fix https://github.com/apache/spark/pull/38052 and adds subquery reference tracking to MergeScalarSubqueries to restore previous functionality of merging independent nested subqueries.
Why are the changes needed?
Restore previous functionality but fix the bug discovered in https://issues.apache.org/jira/browse/SPARK-40618.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing and new UTs.

cc @dtenedor, @gengliangwang, @sigmod

@gengliangwang, @cloud-fan could you please take a look at this fix?

thanks, merging to master!

Thanks @cloud-fan!


Fix emoji display in text

Native String split() can't handle emoji in strings correctly so it causes emoji display exception in text component.
I added a library to fix this.

If you set a color for the text, it causes the emoji to be covered by the color, which feels illogical. I made a few more changes so that the color option wouldn't work for emoji characters.

Thank you this is a very nice feature! I'll take a closer look tomorrow.

Is there an existing library you're referencing from?

Is there an existing library you're referencing from?

yes. the code is from here https://github.com/bluelovers/runes

It seems legit, gonna merge now.


Logging -- Standardize log levels and document usage

I have found the debug log level particularly useful.

We don't want trace by default do we?

Also I expect there's room for using the warn level.

Too late I added a commit and merged.

We don't want trace by default do we?

Fixed

Also I expect there's room for using the warn level.

Sure.  Can you think of anything to warn about : )?
I graded the warning into levels... and only really needed four levels. I could imagine using warn for "important info". We might have components be quite chatty about internal state changes on info mode, but only show the importation messages in info mode. But then... if we are showing detailed information from different components we might want to be able to tweak logging per component.

Mutter in general about use cases for logging:
i. Isolating observered behaviour to a particular component: info
ii. Checking what messages to the redux stream look like: debug I was using this to check that process variable names were correct. I imagine it might be useful to filter this
iii. Checking what messages from the network look like
iv. Adding manual console.log lines to a component and checking that they do the correct thing after a particular message.


Test: 347 make playwright wait for hydrated not networkidle

Instead of explicitly making Playwright wait for hydration, it seemed more appropriate for the app to block user interaction before hydration.
I initially went for a minimal loading overlay (https://github.com/sillsdev/languageforge-lexbox/commit/5b79da9cd234df449502a04cbf48663ef0206813), which I included in the history, because it wasn't terrible.
But, it seemed so weird to cover up loaded HTML...
So, I transitioned to making things that tend to need hydration visibility: hidden and in cases where I know that it's a container (only a form so far), it's possible to add a "loading skeleton".
Out of date

https://github.com/sillsdev/languageforge-lexbox/assets/12587509/fb804cf6-f388-4792-82d7-10f26e78ab75
https://github.com/sillsdev/languageforge-lexbox/assets/12587509/24ec9992-1773-405a-a5c2-c987f01c1a83

EDIT: new version (I just couldn't become friends with that weird huge gradient, so I transitioned to a simpler loading animation):
https://github.com/sillsdev/languageforge-lexbox/assets/12587509/ff683be4-63ff-4b75-bd3c-187a3d9a6230

@hahn-kev The problem with disabling the input fields is that we can't block Playwright unless we actually disable/enable them with JS and I thought it would be nice if we could avoid JS for this.
I also don't think it would be a huge visual improvement to show disabled inputs.
I think some sort of navigation/loading indicator (#197) will likely give us the UX boost we need.


dependabot fails to update pnpm-lock.yaml

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
pnpm
Package manager version
8.8.0
Language version
No response
Manifest location and content before the Dependabot update
No response
dependabot.yml content
No response
Updated dependency
No response
What you expected to see, versus what you actually saw
Expected postCSS to be updated in pnpm-lock.yaml
Actual: received error message: Dependabot cannot update postcss to a non-vulnerable version
However, running pnpm audit --fix successfully patches the dependency.
truncated logs:
proxy | 2023/10/11 21:26:31 [139] GET https://registry.npmjs.org:443/type-fest
  proxy | 2023/10/11 21:26:31 [140] GET https://registry.npmjs.org:443/caniuse-lite/-/caniuse-lite-1.0.30001547.tgz
  proxy | 2023/10/11 21:26:31 [143] GET https://registry.npmjs.org:443/electron-to-chromium/-/electron-to-chromium-1.4.550.tgz
  proxy | 2023/10/11 21:26:31 [138] 200 https://registry.npmjs.org:443/escalade
  proxy | 2023/10/11 21:26:31 [144] GET https://registry.npmjs.org:443/update-browserslist-db/-/update-browserslist-db-1.0.13.tgz
  proxy | 2023/10/11 21:26:31 [139] 200 https://registry.npmjs.org:443/type-fest
  proxy | 2023/10/11 21:26:31 [140] 200 https://registry.npmjs.org:443/caniuse-lite/-/caniuse-lite-1.0.30001547.tgz
  proxy | 2023/10/11 21:26:31 [143] 200 https://registry.npmjs.org:443/electron-to-chromium/-/electron-to-chromium-1.4.550.tgz
  proxy | 2023/10/11 21:26:31 [144] 200 https://registry.npmjs.org:443/update-browserslist-db/-/update-browserslist-db-1.0.13.tgz
updater | 2023/10/11 21:26:32 INFO <job_734059994> VulnerabilityAuditor: starting audit
updater | 2023/10/11 21:26:32 INFO <job_734059994> VulnerabilityAuditor: missing lockfile
updater | 2023/10/11 21:26:32 INFO <job_734059994> Requirements to unlock update_not_possible
updater | 2023/10/11 21:26:32 INFO <job_734059994> Requirements update strategy bump_versions
updater | 2023/10/11 21:26:33 INFO <job_734059994> The latest possible version of postcss that can be installed is 8.4.29
updater | 2023/10/11 21:26:33 INFO <job_734059994> The earliest fixed version is 8.4.31.
updater | 2023/10/11 21:26:33 INFO <job_734059994> Finished job processing
updater | 2023/10/11 21:26:33 INFO Results:
updater | Dependabot encountered '1' error(s) during execution, please check the logs for more details.
updater | +------------------------------+
updater | |            Errors            |
updater | +------------------------------+
updater | | security_update_not_possible |
updater | +------------------------------+
updater | time="2023-10-11T21:26:33Z" level=info msg="task complete" container_id=job-734059994-updater exit_code=0 job_id=734059994 step=updater

Native package manager behavior
❯ pnpm audit --fix
1 overrides were added to package.json to fix vulnerabilities.
Run "pnpm install" to apply the fixes.

The added overrides:
{
<EMAIL_ADDRESS>">=8.4.31"
}

Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response

I'm investigating a similar issue for https://github.com/gpbl/react-day-picker/security/dependabot/50/update-logs/350068344 🤔
updater | 2023/10/14 17:06:47 INFO <job_735245446> VulnerabilityAuditor: starting audit
updater | 2023/10/14 17:06:47 INFO <job_735245446> VulnerabilityAuditor: missing lockfile
updater | 2023/10/14 17:06:47 INFO <job_735245446> Requirements to unlock update_not_possible
updater | 2023/10/14 17:06:47 INFO <job_735245446> Requirements update strategy bump_versions
updater | 2023/10/14 17:06:47 INFO <job_735245446> The latest possible version of loader-utils that can be installed is 2.0.4
updater | 2023/10/14 17:06:47 INFO <job_735245446> The earliest fixed version is 3.2.1.
updater | 2023/10/14 17:06:47 INFO <job_735245446> Finished job processing
updater | 2023/10/14 17:06:47 INFO Results:
updater | Dependabot encountered '1' error(s) during execution, please check the logs for more details.

Thanks for letting us know. Can any of you share an example repository showing this problem?

Here's a minimal example.

I am encountering a similar issue. My lockfile is not at the top level of the repo (frontend/pnpm-lock.yaml).
updater | 2023/12/18 09:33:03 INFO <job_763337106> VulnerabilityAuditor: starting audit
updater | 2023/12/18 09:33:03 INFO <job_763337106> VulnerabilityAuditor: missing lockfile
updater | 2023/12/18 09:33:03 INFO <job_763337106> Requirements to unlock update_not_possible
updater | 2023/12/18 09:33:03 INFO <job_763337106> Requirements update strategy bump_versions
updater | 2023/12/18 09:33:04 INFO <job_763337106> The latest possible version of @koa/cors that can be installed is 4.0.0
updater | 2023/12/18 09:33:04 INFO <job_763337106> The earliest fixed version is 5.0.0.
updater | 2023/12/18 09:33:04 INFO <job_763337106> Finished job processing
updater | 2023/12/18 09:33:04 INFO Results:
updater | Dependabot encountered '1' error(s) during execution, please check the logs for more details.
updater | +------------------------------+
updater | |            Errors            |
updater | +------------------------------+
updater | | security_update_not_possible |
updater | +------------------------------+
updater | time="2023-12-18T09:33:04Z" level=info msg="task complete" container_id=job-763337106-updater exit_code=0 job_id=763337106 step=updater

Also running into this issue in our monorepo.

Same issue with also yarn.lock. Monorepo but no workspaces (one package.json, one yarn.lock, one node_modules - all in the root of the repo).

We're having the same issue with pnpm and dependabot. Are there any plans to support pnpm-lock.yaml? Our lock file is in the root directory.

Any plan on fixing this ? It's used by a lot of people.

We've run into this issue when using dependabot in a repository using pnpm workspaces.
Mimicking the behaviour on my local machine, I've noticed that running pnpm update from the root will not update a dependency in a child workspace, however running pnpm update -r does.
I just had a quick dig through the code and it looks like dependabot is not passing the -r (recursive) flag when running the update:
https://github.com/dependabot/dependabot-core/blob/86ab940b72ad9253610e70af76a4834559b17567/npm_and_yarn/lib/dependabot/npm_and_yarn/update_checker/version_resolver.rb#L572-L575
Here is the doc on pnpm's recursive flag https://pnpm.io/cli/recursive
I haven't thought too hard about this, but it seems like a sensible thing to add.

We are having this issue as well, can we get an update from the dependabot team?


Generate RADx MARS HL7 V2 compliant Messages

User Story:
As ReportStream, I want to follow the RADX MARS spec, which means adding the fields that are missing for us to be compliant.
Description/Use Case
There are around 20 fields that need to be added and one set that needs to be adjusted for us to be compliant.
Risks/Impacts/Considerations
Dev Notes:
Here is the doc that lists which fields need to be updated: https://docs.google.com/spreadsheets/d/15dKu5zSY23-VVL0oJphILQyHjyDoj_WmTmXUxGXinzQ/edit#gid=0
When you pick this ticket up please let me (Jessica Willis) know and I will grant you access to it.
Acceptance criteria

[ ] The 20 or so fields are added and can be used to generate HL7 V2 messages.
[ ] The one set has been updated.

Spreadsheet will need review to move this into Ready for Grooming.

needs to updated to use user story template?

@JessicaWNava Please update to use User Story template and flesh out.

Need to make sure that the fields coming in are also being mapped into FHIR. This was originally very receiver specific.


Does audiocraft support torch.compile on MusicGen / AudioGen?

I tried the MusciGen model with torch.compile but the resulting audio is cacaphonous without any musical integrity.
It works fine when I only decorate the encodec model functions like this with torchinductor: https://github.com/sspintel/audiocraft/commit/1a8ed5621eda49766499629b3740f1b5aced9f2a but when the transformer model functions are decorated, the resulting audio output is messy. Are there plans to add torch.compile support?

Any update?


Add help text to explain how to enable alpha features

We currently don't provide any info about how to enable alpha features, link to our official DevHub docs about what alpha means or share the list of permissible values.

@wbreza can you take care of the help updates?


Connectors -  don't call FromJson(string) since it loses swagger type information

Basically, connectors should never call FormulaValue.FromJson(json) because that doesn't leverage swagger.
For example, a string, guid, and date are all the same in json.
The json+swagger serializer solve this problem. But direct calls to FromJson(json) avoid that.
One usage is in DecodeResponseAsync().
What this means is that if a connector returns a Date (and specifies that in its swagger), we'll call FromJson and deserialize as a string!

I support this issues, I was face this issue and I solved it using this modification:
`
public RecalcEngineScope GetScope(string contextJson)
{
var engine = GetEngine();
var Context = JsonConvert.DeserializeObject<Dictionary<string, object>>(contextJson);
foreach (var item in Context)
{
var value_eval = item.Value?.ToString().Trim('"');
var formula_value = EngineContext.GetFormulaValue(engine, value_eval);
engine.Config.SymbolTable.RemoveVariable(item.Key);
engine.UpdateVariable(item.Key, formula_value);
}
        return RecalcEngineScope.FromJson(engine, "{}");
    }

where GetFormulaValue function is a custom function that I used to convert a string, object, or list value to a best formula available in RecalcEngine for example when {value_eval} is date e.g. {"20/09/2022"} I convert it to {DateTimeValue("20/09/2022")} and then pass it toengine.Eval("DateTimeValue("20/09/2022")")and return value to store it in engine usingengine.UpdateVariable(item.Key, formula_value)`
but still, for this moment I still face some issues with other types, So I wish to solve this issue as soon as


(KB2999226) error on Windows 10 Enterprise

http://disq.us/p/1e3h774
You have KB2999226 v1.0.20161023 installed. Version 1.0.20161030 is available based on your source(s).

KB2999226 v1.0.20161030 [Approved]
kb2999226 package files upgrade completed. Performing other installation steps.
Skipping installation because hotfix kb2999226 does not apply to Microsoft Windows 10 Enterprise.

ERROR: This package does not support 64 bit architecture.
The upgrade of kb2999226 was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\KB2999226\tools\chocolateyinstall.ps1'.
 See log for details.

Looks like the default case in the switch is missing a return.

Yeah, that definetely looks to be the problem, thanks for reporting it.
I'll push out an update shortly.

Thanks for fixing this! Could you mention it in the package release notes?

sure, sorry didn't notice that there was a release notes.


elm: add the platform and helpful scripts

cc @peti -- I haven't integrated this into haskell-modules, instead using overrides to add needed packages. Maybe we want to do this some other way?
TODO:

Documentation
A way to package elm modules? (don't see any use case for now)

This patch looks fine to me. I wonder about two things:

Why don't the packages live underneath pkgs/development/pkgs/development/elm-modules? Putting them underneath the compiler is unusual in Nixpkgs.

What is the reason for duplicating Haskell build expressions like elm-compiler rather than using the ones we already have?

This is the Elm platform without any Elm packages in Hackage sense (well, there are technically several packages for elm-reactor, but they are isolated), consisting of a compiler, a REPL, a debugger and Cabal-like utilities -- I felt that this is more a "compiler" than "modules".
The upstream has stopped updating Hackage packages and promotes their own build script which checks out specific git tags and builds a sandbox. I'm using a small Ruby script to generate needed packages from their specification. For instance, elm-compiler-0.15.1 is not on Hackage.

Thank you for the explanations! I wish the Elm people would deprecate their package on Hackage if they don't intend to maintain it there anymore.

Anyway, the code looks fine to me. Merge away if you feel that it's ready. Also, I'm about to push 9e7ce5b to disable the broken Elm variants in the haskellPackages set.

I came up with my own hack to get the latest Elm stuff before I saw this. Your approach is much better (^_^). My hack is here if you want to take a look. I kept the Elm packages a part of haskellPackages, just providing versions that sourced from GitHub instead of Hackage.
My only suggestion for this pull request is that elm-repl requires both elm-make and nodejs to exist in it's $PATH in order for it to actually work. elm-repl has flags to point it at the specific compiler and interpreter binaries you want to use, but being in $PATH is good enough (it will look for elm-make and node or nodejs binaries to use by default). I just used wrapProgram.

@evancz can probably mark the the Hackage packages as deprecated

They are all marked as deprecated.

Thanks!

Also paging

@agrafix wrt elm-bridge
@JoeyEremondi wrt elm-core-sources / elm-build-lib
@JustusAdam wrt elm-init.

I just noticed your packages was also marked broken in https://github.com/NixOS/nixpkgs/commit/9e7ce5bff5758065a7b2bca58d15dc68ce31864d#diff-8f392bd0e4fd42a66d9e0cd4901ec287R919. Are they deprecated?
I'm sure some of these are still actively maintained on Hackage (not part of the Elm platform). elm-bridge was just announced the other day.
These all depend on deprecated packages, so I'm guessing it's safe to mark deprecated:

snap-elm (not included in the commit, but is probably broken)
@tazjin wrt elm-yesod
@maxsnew wrt hakyll-elm

Please mark as deprecated on Hackage if you don't mind.

elm-init doesn't depend on any elm platform packages.
I personally haven't used any package distribution other than hackage and I'd appreciate if someone could tell me what the canonical way of publishing elm related software is now so I can submit upstream changes to the right place.

@rehno-lindeque elm-bridge does not depend on any elm platform packages and is not deprecated.

@peti I believe there was a misunderstanding (correct me if I'm wrong!) -- Elm platform consists only of

elm-make
elm-package
elm-repl
elm-compiler
elm-reactor

Other packages are not in the platform (nor in my PR) and their authors still release them on Hackage.

@doshitan Thanks for your advice! I'll fix this, add some documentation and this should be good to go.

@JustusAdam I think it's probably something you can bring up in the elm-discuss mailinglist. We probably want to avoid spamming this PR (but I believe Hackage should be fine as long as you don't depend on Elm platform packages).

Sorry for the dealy on my part, I just depricated elm-build-lib, it hasn't
been updated in a while, and I'm not sure if anyone is using it.
On Mon, Aug 17, 2015 at 12:32 PM, Nikolay Amiantov<EMAIL_ADDRESS>
wrote:

Merged #9233 https://github.com/NixOS/nixpkgs/pull/9233.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/pull/9233#event-384599215.


Metric for registry errors

Is your feature request related to a problem? Please describe.
The documentation lists argocd_image_updater_registry_errors_total and this metrics is used in the example Grafana dashboard, but it is not implemented.
Describe the solution you'd like
Implement the metric.
Describe alternatives you've considered
Maybe it was implemented in the past and removed for some reason, but couldn't find any information about that.
Additional context
https://github.com/argoproj-labs/argocd-image-updater/blob/da58411eea9f98811f55cc10b92c150385e2d9ae/docs/install/start.md#L309
https://github.com/argoproj-labs/argocd-image-updater/blob/da58411eea9f98811f55cc10b92c150385e2d9ae/config/example-grafana-dashboard.json#L518

Working on this as my first issue

I've just found that metric is already implemented
https://github.com/argoproj-labs/argocd-image-updater/blob/7ed1f675ca2373dd8f0442e1a398e3fc9a227c55/pkg/metrics/metrics.go#L158-L161
https://github.com/argoproj-labs/argocd-image-updater/blob/7ed1f675ca2373dd8f0442e1a398e3fc9a227c55/cmd/run.go#L322
is the confusion due to the naming?

Opps sorry my fault the definition for that metric is here
https://github.com/argoproj-labs/argocd-image-updater/blob/7ed1f675ca2373dd8f0442e1a398e3fc9a227c55/pkg/metrics/metrics.go#L85-L88
And that metric is not what you pointed out.
So forget about this I'll keep looking

Closed by #362


Bring back extended tests

A while back, I unfortunately asked pytest to skip quite a lot of tests in the tests in test_vs_fixest.py.
We should bring back those tests & add tests for the predict() and resid() methods (beyond tests already implemented in test_predict_resid_fixef.py).

For bringing the tests bac: Is this a matter of simply passing the extended marker on the CI tests?

It should all be fixed with this PR https://github.com/py-econometrics/pyfixest/pull/603 - basically consists of getting rid of a lot of poorly chosen skip statements

ah ok! 👍


fix: variants in dynamic functions

Summary
I forgot to pass variants to dynamic functions. Fixes #100
Test plan
Tested locally

wow, that was fast! thanks @jpudysz for such a quick reaction! 🙇🏻 💪🏻


Caddy server not serving QUIC

I'm setting a caddy server (-quic) with caddyfile:
:11220 {
  tls self_signed
}

And I have quic enabled in chrome. But when I try to access to the server:

All I get is TLS 1.2 when I should get QUIC

This might be related to https://github.com/mholt/caddy/issues/2049

We also haven't updated the QUIC library in a while, since it adds too much code bloat: https://github.com/lucas-clemente/quic-go/issues/1353 -- once that gets resolved though, I suspect we can get it updated! (It needs regular updates since Chrome only works with basically the latest version.)
Will close this for now, since not much we can do about it at this point.

QUIC requires an SNI, so you'll need a domain name for this, it won't work when connecting to an IP address.

Ah, good to know. :) Thanks!


feat: export isFloat locales

This commit exports the list of supported locales for isFloat
as isFloatLocales
Ref: #815, #891, follow up for #890

Thanks. I think this is fine for now.


Improve Clarity of Examples in README

Problem Description
The current examples provided in the README may not be sufficiently clear for users to grasp the full potential and usage scenarios of the dynamic casting utility. Users might find it challenging to understand how to apply the dynamic_cast function in more complex scenarios.
Suggested Improvement
Consider revisiting and enhancing the examples to make them more explicit and user-friendly. Provide additional comments or explanations within the code snippets to guide users through the usage of the utility in various contexts. Clearer examples will help users better understand the capabilities of the dynamic casting utility and encourage its effective implementation in their projects.
Additional Suggestions
Consider expanding the examples to cover more diverse use cases.
Provide scenarios where dynamic casting helps handle unexpected input types gracefully.
Include examples involving class instances with complex initialization logic.
Incorporate scenarios where the utility is applied to nested structures or custom data types.
How to Contribute
If you have suggestions for improving the examples or encounter any issues, please feel free to create an issue or submit a pull request. Your contributions are highly appreciated!

Thank you for bringing up this valuable feedback. We acknowledge the need for clearer examples in the README and appreciate your suggestions for improvement. In response to this, we plan to address the clarity issue by adding a dedicated "examples" folder in the upcoming commits


Sharing product using Android Beam doesn't open product in the app

If your phone and the phone of a friend have NFC, you can share a product page by touching them together.
Only issue: the product should open in the app

Android Beam is deprecated. Closing


ERQueryService.java uses unchecked or unsafe operations

Warning generated during maven build:
src\main\j
ava\com\ericsson\ei\erqueryservice\ERQueryService.java uses unchecked or unsafe operations
Recompile with -Xlint:unchecked for details

removed unchecked or unsafe operations in other code also, Here is the pull request   https://github.com/Ericsson/eiffel-intelligence/pull/63


[Bug]: Lsp is not starting on Windows 10

Describe the bug
On my windows 10 machine, :LspInfo displays

0 client(s) attached to this buffer

When I increase the log level of nvim, it prints this error in the log file:

Spawning language server with cmd: C:\Users\<username>\fvm\versions\stable\bin\dart failed. The language server is either not installed, missing from PATH, or not executable.

The above file path points to a bash file.
I had to make the following changes in flutter-tools\executable.lua:49 to make it work.
local function _flutter_sdk_dart_bin(flutter_sdk)
  -- retrieve the Dart binary from the Flutter SDK
  return path.join(flutter_sdk, "bin", "dart.bat") -- I appended .bat extension
end

I have no idea how  to detect if it's running on windows and if so append the .bat suffix.
To Reproduce
Lsp is not started when I open a flutter project in neovim with default configurations of this plugin.
require("flutter-tools").setup{ }

System information

OS: Windows 10 19043.1466
Flutter Version

flutter --version
Flutter 2.10.0 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 5f105a6ca7 (7 days ago) • 2022-02-01 14:15:42 -0800
Engine • revision 776efd2034
Tools • Dart 2.16.0 • DevTools 2.9.2

Neovim version: 0.6.1

@erturk I've encountered a similar issue a while ago from a windows user and asked this question (which they didn't answer unfortunately), should the binary always be append with .bat for all windows users or is it possible a windows user is using WSL or some other mechanism that doesn't require that extension or it would break for. I don't use windows and have no way of testing on it, I'm happy to change this but don't want to immediately be inundated with bug reports that it broke for someone else. If a windows user can give me a clear description of what the universally correct way there is to resolve this on windows then I'm happy to implement it 🤷🏿

I'm not a WSL user and I'm not 100% certain about this but using neovim on a WSL environment is no different to running it on a regular Linux. The OS is Linux in WSL neovim . If it's possible to append the .bat suffix according to detected running OS, it would be a universally correct way, I think.
Thanks for the great plugin.

@akinsho I'm interested on this. I can help on tests.

OK I've just pushed a change to use .bat on Windows hopefully that puts this issue to bed rather than opens up another can of worms in which case I will revert the change and wait for a Windows user to contribute a safer/better solution.

@akinsho It's working on Windows. At moment I use this plugin just on macOS. I will start using it also on Windows so I provide feedback.


White screen of death on error

Hi,
I'm trying to develop an asp.net 5 website using Mono and Kestrel development server. When the website compiles properly, I'm able to load the website without any dramas on the local development port after launching k kestrel
However, if there is an error with my .cshtml view file (referencing wrong model), or even something as simple as a null reference exception error, the Kestrel web server just returns a white screen of death, without any explanation to the cause of the error, either on the webpage (like the traditional asp.net yellow error pages) or within the terminal running Kestrel.
Is there any way that I can determine what is causing the error? The null reference exceptions aren't too bad, by I'm unable to determine the error within my view.
Cheers,
Justin

By design. If you want to see errors, then use the Diagnostics middleware https://github.com/aspnet/Diagnostics/blob/dev/samples/ErrorPageSample/Startup.cs#L10

Thanks for the info, makes sense :)


Possibility View in Status Page

⚠ Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find similar feature request

🏷 Feature Request Type
UI Feature
🔖 Feature description
Possibility to view juste the result of Group in status page without all node in this group
✔ Solution
When to view the status page just view the information per group is it's ok and if selected the group it's expand to view all node in this group
❓ Alternatives
No response
📝 Additional Context
No response

Maybe an alternative would be to create multiple status pages ?

I think having multiple status pages is a good thing. This way I don't have to create many uptime-kuma instances for different projects. But it would be nice to have a collapsing grouping option. This way I can show:
Service 1:

web
api
something else

Service 2:

web
api

and just collapse them both as, and allow the user to quickly see that both service1 and service2 are up, but if any of the underlying services is down then they can uncollapsed.
It would be really nice if I can use the tag to create one of these groups, and if I create a new monitor it is automatically added to this group.

@PopcornPanda  I think this has been implemented+merged.
Any version after 1.22.0-beta.0 supports this.

Could you close this Issue if this has been resolved?

From the screen shot it looks like alphabet has its own monitor from the two services below it. So if one of the sub services (google and youtube in this case) are down, is alphabet marked down, or degraded?


[Framework] Rooch Framework

Rooch Move Framework
v0.1

[x] #16
[x] load rooch framework when moveos starts
[x] #20

Move out  #13 #14  #15  #308 and close this issue.


Dask read_csv does not work when file is in local Network

There is a problem when I try to read a csv file from file in local network.
Using pandas read_csv it works fine. i.e. pd.read_csv(r'\\localnet\folder\file.csv') but does not work with dask.dataframe.  I also tried dd.read_csv(r'file:\localnet\folder\file.csv')
Thank you

cc @martindurant.
@lchara03 what scheduler are you using? Do you create a Client, or are you just using the default threaded scheduler?
Can you set
import dask

dask.config.set(scheduler='single-threaded')

and post the traceback of dd.read_csv("path/to/file")?

This should be fixed in fsspec master. Please try it.
If so, we should probably release it.

Just checking in here, @lchara03 did using the current master branch of fsspec resolve this issue?

Closing for now. @lchara03 please feel free to re-open if this problem persists with the latest release of fsspec. Thanks!


Add Fuchsia-specific reactor and net impls

This change splits out the reactor into separate mio-based and Fuchsia-ports-based implementations. This is greatly beneficial to Fuchsia's uses of tokio-core, as it allows us to schedule and receive custom notifications via the PacketReceiver interface. After this change, the Fuchsia backend for mio will no longer be used by tokio-core.
I apologize this is so much code-- I wanted to do this all at once so that I could see how all the different pieces came together. I hope that the Fuchsia components are isolated enough that it doesn't impose too great of a maintenance burden.
cc @raggi, @raphlinus, @alexcrichton, @carllerche

If this mio issue is resolved, is this PR required?

@carllerche Theoretically we could solve some of the same problems by allowing arbitrary signal data. However, I think this approach allows for a much more flexible implementation, and will require less churn in the future. It allows other libraries to declare their own PacketReceiver types which understand how to handle incoming readiness/signal data. Without this change, that code would have to be baked into mio.
This change also opens the door for Fuchsia-specific optimizations of reactor primitives, such as the Timer/Interval implementation here. I'm also interested in adding multithreading support for the Fuchsia reactor as we move over into the new "tokio" crate.
Finally, this PR makes it much simpler to debug and diagnose issues in Fuchsia's tokio support. There are now far fewer layers to dig through when searching for bugs, and the PacketReceiver structure makes it easier to track down missed or excess wakeups.

I'm pretty hesitant at this point to start adding significant platform specific code to tokio and would rather consider alternate strategies.

@carllerche would you be open to having a separate Fuchsia "back end" playing a role similar to mio for Tokio, with most of the code living there? (NB I haven't reviewed this patch carefully so this may not make sense.)

@carllerche Can you say more about your specific concerns? I'm not expecting the Tokio authors to maintain this code, or ever make sure it compiles. This structure opens up a lot of flexibility for us in terms of how we can use Tokio.
If you're just worried about the code structure being muddled by shifting things into mio-specific and non-mio-specific directories, I'm happy to restructure things as you'd prefer.

@cramertj
This is a pretty big PR w/ not much accompanied documentation. It doesn't explain what PacketReceiver is in this case and what the benefits are.

This change also opens the door for Fuchsia-specific optimizations of reactor primitives, such as the Timer/Interval implementation here.

Timer / Interval are being removed from Tokio.

Can you say more about your specific concerns?

My main concern is that I just don't see the point in having this in Tokio, which aims to be portable. This seems like it should live in a completely different library.

@aturon Tokio is converging to be a light futures + mio shim. The amount of work needed to make such a change makes me think it belongs in a separate library.

@cramertj
And yes, there are maintenance concerns. Unlike Mio, which has a very limited integration surface, this would almost definitely break a lot more often.

@aturon Tokio is converging to be a light futures + mio shim. The amount of work needed to make such a change makes me think it belongs in a separate library.

FWIW I suspect that the amount of code will be much smaller in the new tokio library, since the overall structure of that reactor is much more similar to the Fuchsia one I have here.

This is a pretty big PR w/ not much accompanied documentation. It doesn't explain what PacketReceiver is in this case and what the benefits are.

There is fairly extensive documentation for the PacketReceiver trait here.

@cramertj why can't this be part of mio?

@carllerche The problem with not integrating with Tokio is that it becomes difficult to integrate with any part of the async ecosystem that assumes Tokio (rather than just AsyncRead etc). Ideally we would continue to be able to offer a portable API to non-mainstream platforms like Fuchsia.
FWIW, std is set up in a similar manner, with the surface-level APIs hooking into sys modules that are each expected to export a common API. We've allowed non-1st-tier platforms to include their own sys modules, but do not gate on them in CI, which means there's effectively no maintenance burden on the Rust team (we ask the Redox folks to do their own reviews as well).
If plausible, it does seem good to move as much of the support code as possible into a separate crate, like I said above -- that way Tokio itself is effectively able to work with multiple back-ends, each of which is a distinct crate.

@aturon

The problem with not integrating with Tokio is that it becomes difficult to integrate with any part of the async ecosystem that assumes Tokio

This PR adds non-portable extensions. Tokio is only providing tcp & udp types. AFAIK fuschia already provides tcp / udp w/ tokio.

@aturon it would probably be helpful to focus on specifics. We both agree that "tokio should work on fuschia".

@carllerche If you're interested in pulling PacketReceiver into mio and reimplementing PollEvented in and IoToken in terms of the PacketReceiver structure, I bet we could figure something out. However, that seems like a much bigger change to the existing mio/tokio interaction surface than the one I'm proposing in this PR. Moreover, it would be predicated on moving to the tokio crate since the PacketReceiver interface requires access to the scheduled_io Slab in order to deregister.

@cramertj is it possible to provide a non-portable small hook, akin to Evented, that would allow incorporating other non-portable functionality through a separate add-on crate?

@aturon

@cramertj is it possible to provide a non-portable small hook, akin to Evented, that would allow incorporating other non-portable functionality through a separate add-on crate?

Sure, but you also have to remember all of the other parts of tokio-core that currently know about mio, including all of the net impls, the reactor awakeners and readiness indicators, etc. The API surface there is relatively large.

@aturon @carllerche Should we move this chat to Gitter or IRC (or vidyo/hangouts) so that we can have a bit more bandwidth for communicating?

@cramertj
Can you step back and explain, within the context of only TcpStream, what the problem is with the current setup.

@carllerche TcpStream isn't really an issue-- TcpStream is mostly fine the way it is (modulo the annoying bit about it not being deregistered and leaking, but that could be fixed via the new tokio trait). The real win here is getting direct access to the packets coming from zx::Port and being able to preprocess them as part of the reactor loop, rather than trying to bubble them through some kind of mio readiness type, which will be very challenging since they can contain things like pointers into data buffers and other non-signal information.

@cramertj So why don't you add some way to get the fuschia selector impl out of Poll and then let users pass in PacketReceiver impls there?

In order for that to work, I'd have to have a custom reactor built into the Fuchsia reactor inside of mio which stored all of the Arc<PacketReceiver>s, and bubble access to that reactor up through tokio-core::Handle.  When polling the reactor, I'd have to poll my internal multiple times, dispatching to the PacketReceivers and only returning when a token meant for a tokio-core task or PollEvented is received. On top of all that, we'd still have to deal with the extra layer of abstraction mio introduces, and the performance penalty of mio's reimplementaiton of features that Fuchsia's reactor already provides. None of the additional reactor facilities mio provides are necessary for our reactor-- they already exist and are implemented natively. Plus, that still wouldn't solve the deregistration problem of PollEventeds, and wouldn't allow for us to make platform-specific optimizations to the tokio-core reactor (such as multi-threading).

In order for that to work, I'd have to have a custom reactor built into the Fuchsia reactor inside of mio

This doesn't sound bad (a "reactor" is only a loop).

which stored all of the Arc<PacketReceiver>s

I'm not sure why this would be required when otherwise not.

and bubble access to that reactor up through tokio-core::Handle

This is already done via PollEvented (currently public) and something like IoToken could probably be made public too.

When polling the reactor, I'd have to poll my internal multiple times, dispatching to the PacketReceivers and only returning when a token meant for a tokio-core task or PollEvented is received.

I don't see why this is true. All the work would happen in your fuschia specific reactor and the mio interface is via an Events, which is a batch interface. Your description sounds like you need to do one off work.

On top of all that, we'd still have to deal with the extra layer of abstraction mio introduces

What I am suggesting bypasses mio for all non portable fuschia behavior, so afaik you wouldn't pay any additional cost.

None of the additional reactor facilities mio provides are necessary for our reactor-- they already exist and are implemented natively

Could you be specific? I am not familiar with fuschia, so statements like this doesn't help me understand.

Plus, that still wouldn't solve the deregistration problem of PollEventeds

Could you refresh my memory what the issue is?

nd wouldn't allow for us to make platform-specific optimizations to the tokio-core reactor (such as multi-threading)

Supporting multi-threading is generally a mio TODO and should be tackled separately, I'm not sure what other platform-specific optimizations you would not be able to do, again, please be specific.

Something that may not be obvious. In this path that I am suggesting, you would end up not returning mio Events for resources that go via your PacketReceiver interface. You would pull the task and notify it yourself.

Yes, I understand that. I'll respond in more detail tomorrow.


Week 4 Review Ticket

This is my video

Graded By: Shreya Sapkal
Grade: 2.7/3
Comments: While Jiya ran into some setup errors this week, she worked closely with me, Noor, and Sanika to solve those issues, and we were able to resolve them together. She also made the group repository for us all to share and work on, showing her dedication to our team and maintaining team communication. Her video is exemplary, and includes all the required elements, including a functional local fastpages and python server.

2.7: A well put together video and showed all necessary requirements in the video.

This video is well done and it goes over everything that is required. I explains everything well and the video is still 1 minute long. I give this a 2.7+.

I think you did a great job! You definitely deserve a 2.7+, as you properly showed all of the collaboration components and showed all of your steps with committing changes to the local server (flask and docker) very thoroughly.

Jiya did a fantastic job explaining all the components of her local servers, and her presentation skills communicate to me how well she knows her concepts. The video makes the time constraint, and is worthy of a 2.7+

2.7+
Good split screen video
Clear walkthrough
Fantastic job

Very complete on all aspects.  Like the side by side and the clarity of change.   One transition in middle was a little difficult for me to follow from Fast to Flask.   2.9

2.7+
Detailed explanation
Nice video
Clear and understandable


The manga i added in library are just disappearing after i reopen the app

PLEASE READ THIS
I acknowledge that:

I have updated to the latest version of the app (stable is v8.7.0)
I have updated all extensions
If this is an issue with an extension, that I should be opening an issue in https://github.com/inorichi/tachiyomi-extensions

DELETE THIS SECTION IF YOU HAVE READ AND ACKNOWLEDGED IT

Device information

Tachiyomi version: ?
Android version: ?
Device: ?

Steps to reproduce

First step
Second step

Expected behavior
This should happen.
Actual behavior
This happened instead.
Other details
Additional details and attachments.

sorry for not including other information, i am new in github so
anyway
these are the information
tachiyomi version: latest version of tachiyomiaz
android version: android 5
device : samsung ( Galaxy J5)

It wasn't supposed to have no manga in the library since i added lots of them
but all the manga i added aren't there even if i see the chapters i started downloading in the downloads section and i still receive new chapter updates in updates section


Support mapping repository paths, not just host/port.

Fixes https://jira.duraspace.org/browse/FCREPO-2328

This looks and works good, @escowles. I was about to squash and merge... but how would you like to handle that?

@awoods I've gone ahead and squashed my commits.

@escowles , In considering this further, I am unclear of the source of the requirement that import/export should support exporting a resource then importing it to a different location (i.e. as a different resource). This works fine for single resources or resources that are not inter-referenced... but for any realistic repository, this functionality would appear to be opening the door to import failures.
Can you please remind me of the need or requirement here?

@awoods The primary use case I had in mind was if the repository path changes (e.g. /rest to /fcrepo/rest).  But other changes in the path seem reasonable to me.  For example, Hydra typically adds a top-level container for each Rails environment, so resources would be in /rest/dev or /rest/prod.  Handling these kinds of changes to the baseURL seems useful, and I was surprised that it didn't already work when I tried it.
It's also convenient for adding ITs for https://jira.duraspace.org/browse/FCREPO-2192 — we could start and stop the repository, but it seems much easier to export from one path and import into another path.
Though now that you bring it up, I agree that the translation might not handle resources that are not children of the exported resource.  For example, if you export /rest/dev/a and it references /rest/dev/b, then translating /rest/dev/a to /rest/prod/a would likely fail.  It may be possible to handle this case too — let me see if I can find a mapping that will handle that gracefully.

@ruebot Yep, I'll rebase and see if I can address @awoods' concerns — should have more info by our call today.

@escowles , Thanks for looking more into this. I have also successfully tested the Hydra use case, i.e. export from /rest/dev and import to /rest/prod, where:
</rest/dev/a> dc:hasPart </rest/dev/b>

...which is comforting.
The caveat with the capability offered by this PR is that resources that have been exported from a given repository sub-tree can not reference resources found outside of that same sub-tree. Otherwise, this seems good.

@awoods If the final part of the source and destination URIs is the same, then I think we could update the mapping algorithm to remove the matching parts from the source and destination URIs to determine the correct base URIs to use for mapping.
E.g., if you export http://localhost:8080/rest/dev/a/b/c/abc123 and then import it to http://localhost:8080/rest/prod/a/b/c/abc123, then we should be able to remove the /a/b/c/abc123 from the ends to figure out that we should map /rest/dev to /rest/prod.
Does that seem like a reasonable approach?

@escowles , I must not be understanding your example. Because, I believe that scenario currently works, no?

@awoods It works as long as long as http://localhost:8080/rest/dev/a/b/c/abc123 doesn't reference other resources like http://localhost:8080/rest/dev/d/e/f/def456.  I mean that it should be able to figure out that /rest/dev is the base path and translate http://localhost:8080/rest/dev/d/e/f/def456 to http://localhost:8080/rest/prod/d/e/f/def456.

hmm... I still must not be understanding, because I just tested the scenario you describe... and import/export works.
</rest/dev/a/b/c/abc123> dc:hasPart </rest/dev/d/e/f/def456>

export /rest/dev
import to /rest/prod
Now see:

</rest/prod/a/b/c/abc123> dc:hasPart </rest/prod/d/e/f/def456>

@awoods I think the key part is not exporting/importing the baseDir, but a child directory:
</rest/dev/a/b/c/abc123> dc:hasPart </rest/dev/d/e/f/def456>

export /rest/dev/a/b/c/abc123
import to /rest/prod/a/b/c/abc123

Got it. Thanks.
That is also what I was trying to communicate here: https://github.com/fcrepo4-labs/fcrepo-import-export/pull/48#issuecomment-265475718
The question is, what would we want the dc:hasPart relationship to be after import in this scenario?

</rest/prod/a/b/c/abc123> dc:hasPart </rest/prod/d/e/f/def456> --noting that the object of this triple may likely not exist
</rest/prod/a/b/c/abc123> dc:hasPart </rest/dev/d/e/f/def456>
??

@awoods I would think the former (</rest/prod/a/b/c/abc123> dc:hasPart </rest/prod/d/e/f/def456>) because if you exported the entire /rest/dev tree, that resource would be created at that URI.  Since it doesn't exist, we'd create a placeholder for it.

@escowles , that sounds reasonable... but it also sounds like we are tabling this as a "Phase-3" requirement.

Closing this PR since we've decided not to pursue this functionality right now


Intel OpenGL - fix a crash/shader compile error when you activate Vertex...

... Lit from Material Editor

Confirmed :+1:


MIN_VALIDATOR_WITHDRAWABILITY_DELAY applied twice

The MIN_VALIDATOR_WITHDRAWABILITY_DELAY is applied twice:

In prepare_validator_for_withdrawal() it is included in validator.withdrawable_epoch.
In process_exit_queue() it is used for eligible().

It's definitely intended for both stages of the validator lifecycle to have the delay. Welcome suggestions for what to rename it to.

Would it be fair to say that (for phase 0 at least) the logic is roughly equivalent to removing the delay in process_exit_queue and doubling the delay in prepare_validator_for_withdrawal? My guess is that this is ground work for the phase 1 custody game, but I can't quite put my finger on it.
On this topic, do we want to change the rate limiting logic based on this Ethresear.ch post?

Would it be fair to say that (for phase 0 at least) the logic is roughly equivalent to removing the delay in process_exit_queue and doubling the delay in prepare_validator_for_withdrawal?

I don't think it's quite equivalent to either of those. If x is the queue length, then max(x, 2), max(x, 1) + 1 and x + 2 are all different functions.

On this topic, do we want to change the rate limiting logic based on this Ethresear.ch post?

My heart wants to, my "let's do things now as an investment in making future phases easier" side also does, but my "we have to ship and we need to ban making nontrivial new changes at some point" side says no.....

Closing in favour of #675 item 23 "Improved rate limiting".
I'm inclined to improve rate limiting now :)


Remove toggle switch

The checkboxes in the settings will have some styling to adapt to themes. Probably will be updated after the weekend. See https://github.com/atom/atom/issues/4932#issuecomment-69446042
Unfortunately it breaks your custom toggles:

This PR removes your custom toggles and so that the default checkboxes would look like this:

Let me know if you still prefer the toggles, I can send another PR to add them back. I'm still not sure what to do with the One themes.

Oh that's interesting, I didn't expect that to be an accesibility problem. I'm all for checkboxes then. Thanks!


Alert on DNS in kubernetes when you can't configure DNS

Environment info

NooBaa Version: 4.0
Platform: minikube 1.1.1

Actual behavior

no real DNS problem - so no need for the alert. I can access aws for example

Expected behavior

don't show alert

Steps to reproduce

More information - Screenshots / Logs / Other output

Can you remove the alert altogether? I also believe we removed the check for DNS but it might be in #5521


feat(azure_sdk): initial support for azure sdk

:tada: This PR is included in version 1.65.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fan doesn't mount properly to croom

Attempting to mount the 80mm fan to the croom indicates that the holes are spaced too closely vertically. We need another few millimeters. Also, we might want to take the space in a few mm, to ensure there's no gap around it.

i've implemented a correct differential fanhole() object, and used it in hotbox. now to use it in croom.

switched croom to fanhole(), which fixes several bugs. we now have a fully symmetrical 17mm triangle in each corner with the 4.3mm hole at 4.25mm in from the sides. it ought mate perfectly. the one thing we still want to fix is the angle of the fanhole; that will be addressed by #1.


ios13/12/11... , xcode14,macOS13,flutter_inappwebview: ^5.7.1, my app crash  when app is launching

Translated Report (Full Report Below)
Hardware Model:      MacBookPro16,2
Process:             Runner [36898]
Path:                /Users/USER/Library/Developer/CoreSimulator/Devices/xxxxxxx/data/Containers/Bundle/Application/078153DE-45AA-4FE4-88BD-BABD5FA36783/Runner.app/Runner
Identifier:          xxxxxxxxxx
Version:             1.0.27 (37)
Code Type:           X86-64 (Native)
Role:                Foreground
Parent Process:      launchd_sim [30519]
Coalition:           com.apple.CoreSimulator.SimDevice.F17968E7-10D0-44C1-A252-B7A82C7478D6 [91315]
Responsible Process: SimulatorTrampoline [699]
Date/Time:           2022-12-15 11:00:45.5800 +0800
Launch Time:         2022-12-15 11:00:45.3027 +0800
OS Version:          macOS 13.0 (22A380)
Release Type:        User
Report Version:      104
Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: DYLD 1 Library missing
Library not loaded: /usr/lib/swift/libswiftWebKit.dylib
Referenced from: /Users/USER/Library/Developer/CoreSimulator/Devices/F17968E7-10D0-44C1-A252-B7A82C7478D6/data/Containers/Bundle/Application/078153DE-45AA-4FE4-88BD-BABD5FA36783/Runner.app/Frameworks/flutter_inappwebview.framework/flutter_inappwebview
Reason: image not found
(terminated at launch; ignore backtrace)
Triggered by Thread:  0
Thread 0 Crashed:
0   dyld                          	       0x10574a83a __abort_with_payload + 10
1   dyld                          	       0x1057639c7 abort_with_payload_wrapper_internal + 82
2   dyld                          	       0x1057639f9 abort_with_payload + 9
3   dyld_sim                      	       0x1040a4a1b abort_with_payload + 26
4   dyld_sim                      	       0x1040a4855 dyld::halt(char const*) + 463
5   dyld_sim                      	       0x10405f40c dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 4255
6   dyld_sim                      	       0x10405a1cd start_sim + 122
7   dyld                          	       0x1056e8ff1 dyld4::prepareSim(dyld4::RuntimeState&, char const*) + 1551
8   dyld                          	       0x1056e75be dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 244
9   dyld                          	       0x1056e7281 start + 2289
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000002000209  rbx: 0x0000000000000000  rcx: 0x00007ff7bd7f3278  rdx: 0x00007ff7bd7f36f0
rdi: 0x0000000000000006  rsi: 0x0000000000000001  rbp: 0x00007ff7bd7f32c0  rsp: 0x00007ff7bd7f3278
r8: 0x00007ff7bd7f32f0   r9: 0x0000000000000000  r10: 0x0000000000000128  r11: 0x0000000000000246
r12: 0x0000000000000128  r13: 0x00007ff7bd7f36f0  r14: 0x0000000000000001  r15: 0x0000000000000006
rip: 0x000000010574a83a  rfl: 0x0000000000000246  cr2: 0x0000000105748090
Logical CPU:     0
Error Code:      0x02000209
Trap Number:     133
Binary Images:
0x1056e1000 -        0x105778fff dyld () <0f050705-2258-3d40-b7bc-f3b35a44bbea> /usr/lib/dyld
0x104059000 -        0x1040aefff dyld_sim ()  /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 13.7.simruntime/Contents/Resources/RuntimeRoot/usr/lib/dyld_sim
Error Formulating Crash Report:
dyld_process_snapshot_get_shared_cache failed
EOF

Full Report
------------***--------------------
more:
1 . run app in Macos 13, xcode14,
2. There is not exit libSwiftWebKit.dylib on my computer path --- usr/lib/swift
3.

Please were you able to find a fix to this?

Hey Same issue can anyone make a fix??

It should be in the next version 6.0.0-beta.24


Error with ifdown while activating the scheme. No such interface as 'wlan1'

I've this pretty simple configuration. I am trying to connect to my home router. As described in the docs, i am doing exactly the same. This is what i've done:
>>> scheme = Scheme.for_cell('wlan1', 'home', cell[1], '786 5555')
>>> scheme.save()
>>> scheme.activate()

The last line throws back this error:
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/local/lib/python2.7/dist-packages/wifi/scheme.py", line 172, in activate
   subprocess.check_output(['/sbin/ifdown', self.interface], stderr=subprocess.STDOUT)
 File "/usr/lib/python2.7/subprocess.py", line 223, in check_output
   raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['/sbin/ifdown', 'wlan1']' returned non-zero exit status 1

When i ran the command ifdown wlan1 in the terminal. I got unknown interface error:
ifdown: unknown interface wlan1

I am running Kali Rolling as my distro and this is the settings from my /etc/network/interfaces/ file:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

The below lines were also added when i executed the activate() method:
iface wlan1-home inet dhcp
    wpa-psk eacf5f344981dc7341021b088eb5ecc79fe9cc55ebcff3cc62bd11a81383b56b
    wpa-ssid unknown
    wireless-channel auto

I think it's caused by a missing partial name of interface wlan0, it should be wlan0-home in your example. I have no idea what is the best solution. Because the intuitive way is to modify scheme.py program which is in library.

I've figured out another solution for my project.

I've figured out another solution for my project.

Could you please share your solution? Maybe it suits my project too.

Could you share the solution?

I don't think that that solution would be suitable for you. I was building a PMKID cracker and all i wanted was the first EAPOL frame. So, i'd build a new tool from scapy


Datastore finds of blob_value entities return nil properties

I have entities that are a JSON serialization stored as a blob in Datastore.
Using the dataset.find like this:
key = dataset.key('Digest', '5740703418155118')
entity = dataset.find(key)

Results in a retrieved proto results object passed to self.from_proto (within entity.rb) that looks like this (it is correct so far):
<Gcloud::Datastore::Proto::Entity key:
  <Gcloud::Datastore::Proto::Key partition_id:
    <Gcloud::Datastore::Proto::PartitionId dataset_id: "s~xxxx-xxx">,
    path_element: [<Gcloud::Datastore::Proto::Key::PathElement kind: "Digest", name: "5740703418155118">]>,
    property: [<Gcloud::Datastore::Proto::Property name: "values", value:
    <Gcloud::Datastore::Proto::Value blob_value: "{\"transaction\": {\"car\":<PHONE_NUMBER>, \"version\": 154}}", indexed: false>>]>

However, after the proto results object is processed by Proto.from_proto_value it is turned into this (the values property is now nil):
<Gcloud::Datastore::Entity:0x007fc7b3b9aa00 @properties=#   <Gcloud::Datastore::Properties:0x007fc7b3b9a9d8 @hash={"values"=>nil}>,
@key=#<Gcloud::Datastore::Key:0x007fc7b3b98e80 @kind="AccountDigest",   @name="5740703418155118", @dataset_id="s~xxxx-xxx", @namespace=nil>,
@_exclude_indexes={}>

The problem appears to be that Proto.from_proto_value doesn't support blob_property.
Array(proto.property).each do |p|
  entity[p.name] = Proto.from_proto_value p.value
end

Could we consider adding:
elsif !proto_value.blob_value.nil?
  return proto_value.blob_value

to Proto.from_proto_value?

Right. Gcloud doesn't support blob fields right now. We are hoping to add support for them in the next release.

OK, thanks @blowmage.

@quartzmo Can you give this a look?
@bmclean Any input?

@bmclean This has been released in 0.8.1. Please give it a try. Thanks for your help!

@blowmage I have tested 0.8.1 with images and StringIO JSON and it is working exactly as intended. There is one small catch however. We have entities in our datastore that were previously created using ndb JsonProperty. For those entities the Gcloud::Datastore::Proto::Value blob_value doesn't seem to be returned as Base64 encoded (see my example above). Which is very strange, as when I look at the value for those entities using the cloud.google.com DataStore Viewer they are encoded. Any thoughts? I don't see how gcloud can handle this as it is returned as a blob_value.

@bmclean Just to be clear, using the example above, you mean the blob_value contents is the unencoded string below?
"{\"transaction\": {\"car\":<PHONE_NUMBER>, \"version\": 154}}"

I see what you mean in the docs you linked:

the Datastore stores the JSON serialization as a blob.

Can you think of a solution other than testing that contents of blob_value are in fact base64 encoded before attempting to base64 decode?

@quartzmo Yes. It's very weird. I still think the ndb JsonProperty is Base64 encoded yet it doesn't return that way. Here is another example:
From the cloud.google.com datastore viewer if I look at a property value that was created as a ndb JsonProperty it looks like this:
eyJ0cmFuc2FjdGlvbiI6IHsiY3JjIjogMjMyNTkwMDc1NCwgImVudGl0eV9...
Yet if I add this to Proto.from_proto_value:
elsif !proto_value.blob_value.nil?
  puts "*" * 40
  puts proto_value.blob_value
  return StringIO.new(Base64.decode64(proto_value.blob_value))
else
  nil
end

I get this:
****************************************
{"transaction": {"crc":<PHONE_NUMBER>, "entity_version": 1225}, ...

Should we instead raise an exception if blob_value isn't Base64 encoded? The main datastore docs don't mention anything about a JsonProperty. It states that for Byte String blobValue JSON must be base64-encoded.

@bmclean Can you open a new issue for this? I'm tempted to say we shouldn't do anything for now (you migrate your data), but I want to give others who have similar data the best chance of finding and joining the discussion, which means a well-crafted issue title and description, probably cross-linked with a Stack Overflow question tagged google-datastore.

@quartzmo Sure.

@bmclean Actually can you hold off on that? It may not be necessary, pending something @blowmage is investigating.

@quartzmo oh sorry, I already created an issue! I will hold off on the SO question though.