Use crypto.getRandomValues for new seeds

It's ill advised to use plain math.random due to the low entropy available in testing environments.  Instead, use getRandomValues where available (IE11+ var crypto = window.crypto || window.msCrypto;).

This has come up multiple times and my answer is always the same.
First, Chance doesn't use Math.random() under the hood to generate its random, by default it uses a Mersenne Twister. More info in the docs
It does use Math.random() by default to pick a seed for the twister if none is provided as the default. This is an important distinction.
This was intentional to provide the ability for "repeatable random" if desired by providing the same seed. This is useful for certain use cases (like unit tests where you may want repeatable results).
Second, the rationale for not using any specific crypto library under the hood was that Chance was built to work almost anywhere. It will currently run in practically any Browser or Node.js, in Mongo, in Rhino. I've even had people email me about successfully cross-compiling Chance to Java and other languages.
I've ensured this is the case by having zero dependencies, using only vanilla JS (es5), and by not depending on any specific crypto implementations (e.g. window.crypto or Node's crypto)
If Chance instead used what you suggest (window.crypto) that limits functionality only to the browser (breaking all server-side implementations along with cross compilation), and further only to browsers that support crypto (which is admittedly becoming more prevalent but still not yet universal).
However, I anticipated this from Chance's humble start a few years back, so back in 2013 I wrote into Chance the ability to specify an arbitrary random function of your choosing so a developer could override the default and use any method for the random number generator underlying Chance. This provides optimal flexibility.
You can simply specify the function you'd like to use as a random number generator (any function which returns a number from 0 to 1) and Chance will use your method instead of its Mersenne Twister. See the docs here.
So if you'd like to specify window.crypto for your particular application rather than the Mersenne Twister, the following snippet will do it for you:
var chance = new Chance(function() {
    var arr = new Uint32Array(1);
    window.crypto.getRandomValues(arr);
    // This jazz is necessary to translate from a random integer to a floating point from 0 to 1
    return arr[0]/(0xffffffff + 1);
});
// Now chance will use window.crypto for random rather than the Mersenne Twister

This will get you the results you'd like without limiting compatibility and without dropping the feature of being able to provide a seed and get repeatable random.
Given that not using window.crypto is a feature, not a bug, I am closing this issue.

This has come up multiple times and my answer is always the same.

My apologies, I searched through the issue tickets before posting and I noticed a note on the website about using a truly random source:

There is nothing that would prevent this library from choosing, on instantiation, another random underbase though so in theory this whole library could work with a “true” random base.

I took this to mean that you would like to improve the source for your random seed for situations in which true randomness was desired.

First, Chance doesn't use Math.random() under the hood to generate its random, by default it uses a Mersenne Twister. More info in the docs

It uses Mersenne Twister, but (unless I'm reading the code incorrectly) the default seed is generated using Math.random:
    var MersenneTwister = function (seed) {
        if (seed === undefined) {
            // kept random number same size as time used previously to ensure no unexpected results downstream
            seed = Math.floor(Math.random()*Math.pow(10,13));
        }
        /* Period parameters */
        this.N = 624;
        this.M = 397;
        this.MATRIX_A = 0x9908b0df;   /* constant vector a */
        this.UPPER_MASK = 0x80000000; /* most significant w-r bits */
        this.LOWER_MASK = 0x7fffffff; /* least significant r bits */

        this.mt = new Array(this.N); /* the array for the state vector */
        this.mti = this.N + 1; /* mti==N + 1 means mt[N] is not initialized */

        this.init_genrand(seed);
    };

Second, the rationale for not using any specific crypto library under the hood was that Chance was built to work almost anywhere. It will currently run in practically any Browser or Node.js, in Mongo, in Rhino. I've even had people email me about successfully cross-compiling Chance to Java and other languages.

I was not suggesting that you give up cross-platform compatibility, it's trivial to perform feature detection and fallback to vanilla Math.random when desired.  I suggested crypto because it is available in all non-end-of-life browsers and Node has supported randomBytes since 2011.  This would be a 20-line commit and wouldn't break compatibility in older environments.

Discussing the entropy of an RNG when you're generating a single integer in a library that is used for dummy data does not seem like time well spent.

99% on the time, I use a fixed integer as a seed because I use Chance to build demo web applications.  When the user returns to the site, or moves from page to page, the get a consistent experience.
That said, if for those times I need random data for testing, I wouldn't mind seeing a crypto solution used.
@indolering, if you can post here a small example of injecting a better integer into the constructor... Thanks!

if you can post here a small example of injecting a better integer into the constructor... Thanks!

Not sure what the source comments meant by "downstream" or whether I can just pass a string, but here is a simple implementation:
if(window && window.crypto && window.crypto.getRandomValues){ //browser
  seed = "";
  var ints = new Uint32Array(4);
  for(var i = 0; i < ints.length; i++){
    var int = array[i];
    seed = seed + int.toString('hex');
  }
} else if (GLOBAL && !window){ //node
  crypto = require('crypto');
  var buf = crypto.randomBytes(128);
  seed = buf.toString('hex');
} else {
  seed = Math.floor(Math.random()*Math.pow(10,13));
}

You could also wrap it in a try/catch if you are concerned about node/browser-detection.

Discussing the entropy of an RNG when you're generating a single integer in a library that is used for dummy data does not seem like time well spent.

In the end-to-end tests I use at work, the client creates records that are actually saved to a database. Collisions between certain fields could result in a failed test.  To save time, I run several versions of each browser in parallel. Since we aren't using the crypto API, it's entirely possible that the browser's seed could remain unchanged due to the limited entropy available on the virtual machines.  I thought of this in advance and use Selenium's test session UUID as a seed, but it would be nice if chance.js used a truly random seed by default.  Given the triviality of the change ....

It doesn't matter if it's "truly random", it won't save you from collisions. Random does not imply unique. You're already doing the correct thing by using a unique seed.

It doesn't matter if it's "truly random", it won't save you from collisions. Random does not imply unique.

Uhh, using a high-entropy source of random is ~half the point of crypto.getRandomValues.

Random does not imply unique.

It implies lower chances of collisions and (in many cases) virtually eliminates them.  The other half of this is to ensure that the random seed is random and not screwed up by a VM's low entropy state.

You're already doing the correct thing by using a unique seed.

It would be nice to not have to worry about this sort of thing.  Would you be against a PR adding this functionality?

So, you're currently using a universally unique ID for your seed to avoid collisions and want to exchange that for a high-entropy random value, because that is somehow better?
Adding something, that I consider useless, to a library is something I would be opposed to, yes. But this is not my decision :) I just like to argue about this topic :P

So, you're currently using a universally unique ID for your seed to avoid collisions and want to exchange that for a high-entropy random value, because that is somehow better?

They are equivalent, you can get a duplicate UUID due to crappy seeding of the PRNG.  We could cutout the middle man and just make chance.js actually random.

Adding something, that I consider useless, to a library is something I would be opposed to, yes. But this is not my decision :) I just like to argue about this topic :P

The very first item on the website's TODO list is making chance.js "truly random" which (AFAIK) means switching to a seed with high-quality entropy.  I'm not suggesting altering the PRNG and the Math.random() fallback should eliminate compatibility issues.
@victorquinn what am I missing here?  I could use some help figuring out how to pass in 80-128 bits of entropy, but I could just pass in the floating point number the way you outlined earlier....

The very first item on the website's TODO list is making chance.js "truly random" which (AFAIK) means switching to a seed with high-quality entropy. I'm not suggesting altering the PRNG and the Math.random() fallback should eliminate compatibility issues.
@victorquinn what am I missing here?

My apologies, I should probably update that TODO list.
I wrote that almost 3 years ago now after I first wrote Chance and tried to find a way to get cross platform true random and basically failed.
However, that turned out to be a blessing in disguise because in failing to get true random, I stumbled upon another 2 features:

User supplied source of random
Repeatable random, which has been a feature many (including myself) have relied upon since.

Since writing that TODO list, there has been a lot of adoption which is fantastic! (there are now >80k downloads per month and almost a hundred dependent modules according to npm)
However, along with that comes the responsibility to no longer introduce potentially breaking changes for no great reason. In my opinion, adding the kind of messy script proposed above just to generate a more random seed is not terribly helpful and has the potential to introduce a lot of breakage.
And it doesn't accomplish all that much. My example in my initial reply to you showed how you could use window.crypto for a pure random source for all of the Chance generators in your specific use case.
What you propose is just getting a "more random" seed which then still feeds into a pseudo-random generator which, in my opinion, is not a change of much utility as it doesn't change much.
If that's what you want, I'd say it makes more sense for you to just invoke Chance as follows:
   var arr = new Uint32Array(1);
   window.crypto.getRandomValues(arr);
   var chance = new Chance(arr[0]);

Anyway, this is all a really long-winded way of saying I won't accept a PR with the change suggested above to simply get a more random seed on some platforms.
I'd suggest invoking Chance using one of the methods I suggested above to either use window.crypto as a source of true random under the hood or as the source of a more random seed for the Mersenne Twister or forking Chance if adding those 2 or 3 lines in your specific use case is really that big of a deal to you (all hail the glory of open source).

However, that turned out to be a blessing in disguise because in failing to get true random, I stumbled upon another 2 features:
User supplied source of random
Repeatable random, which has been a feature many (including myself) have relied upon since.

Both are killer features, I have both in my homegrown solution, but these are orthogonal issues.

And it doesn't accomplish all that much.

Low entropy testing environments are honestly one of the few places in which seeds with low entropy can be found.  Sure, tests with side-effects are somewhat rare and users can work around the issue, but it would (as you pointed out three years ago) be nice if Chance handled this on it's own.

However, along with that comes the responsibility to no longer introduce potentially breaking changes for no great reason. In my opinion, adding the kind of messy script proposed above just to generate a more random seed is not terribly helpful and has the potential to introduce a lot of breakage.

I wrote the above code without much thought, here's a better proposal that uses an enhanced version of underscore's Node detection and produces a random integer all wrapped neatly in a try/catch.
var seed = fallbackSeed();

try {
  if(typeof window !== 'undefined' && typeof window.crypto !== 'undefined' && typeof window.crypto.getRandomValues === 'function'){ //browser
    var arr = new Uint32Array(1);
    window.crypto.getRandomValues(arr);
    seed = arr[0];
  } else if (typeof exports !== 'undefined' && this.exports !== exports){ //node
    crypto = require('crypto');
    var buf = crypto.randomBytes(4);
    var hex = buf.toString('hex');
    seed = parseInt(hex, 16);
  }
} catch(error) {
  seed = fallbackSeed();
}

//overkill
if(typeof seed !== 'number'){
  seed = fallbackSeed();
}

function fallbackSeed(){
  return Math.floor(Math.random()*Math.pow(10,13));
}

Unless someone has deliberately sabotaged the environment in a very specific way, you will get a random seed.

Just to mention that the current implementation might have a bias.
See this question on Stack Overflow, where most of the answers use similar codes, then see this answer that states that these codes have a bias, and thankfully provides a code stated as unbiased.


Let the developer customize the input area

The same feature as https://github.com/vaadin/vaadin-combo-box/issues/198

The work done for vaadin-combo-box can be found in the feature/custom-input branch.
https://github.com/vaadin/vaadin-combo-box/tree/feature/custom-input

While planning the developer usability tests, we started thinking that vaadin-date-picker should have the same API as the vaadin-combo-box element.
This would mean that we need to create a vaadin-date-picker-light also. We can't get rid of all paper-* imports because of the full screen mode, but that could be planned later. At least we should define the same API for both.

Working on the refactoring of vaadin-date-picker as a behaviour imported in vaadin-date-picker and vaadin-date-picker-light to follow the same pattern than combo-box


Prototype Merger

Fixes #5
Fixes #8

[x] Include works from #7
[x] Required changes from #7
[x] Tests added

Tests failing as env not set. Please check

@YashKumarVerma I don't understand why u went through the pain of writing the whole program again. As discussed I had already added the working code on develop branch, any specific reasons for this?
As mentioned in the issue, only adding tests were remaining

Don't worry 🙃 I didn't write the logic again, it's the same as your branch.
Just added tests and removed a component.

Okay then. I'll remove tests run from CI, as we will be running this locally anyways. Other than that it seems good. Could you merge your changes to develop branch

Could you remove the 'Run test' part from pr.yml and build.yml?

There's one pre-build.yml I could find. where are pr and build.yml ??

Sorry my bad. It's pre-build.yml

Sorry my bad. It's pre-build.yml

I guess it's safe now to remove uploadToCloudinary right ?

Sorry my bad. It's pre-build.yml

I guess it's safe now to remove uploadToCloudinary right ?

I think we can keep it. Will be useful if its decided to add in last moment.
Can clean up once the submission is done


[Doc] libSyntax: add the instruction for experimenting libSyntax APIs in an Xcode command line tool.

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci Please clean test Linux platform

Build failed
Swift Test Linux Platform
Git Sha - 5218dfc1f1d38dd9d41d27ab6852730c94dbf7a7

@nkcsgexi I'm trying to use your instructions, but they don't seem to work for me
https://github.com/AndrewSB/libMoji/issues/1

@AndrewSB Have you selected the installed OSS toolchain to use? Have you specified "Runpath search paths" and "Library search paths"?

Yup, that should be evident from the commit on that repository.
I just talked to @harlanhaskins and he said that theres a chance SwiftSyntax isn't included until the 4.1 release, but that he wasn't sure. The toolchain offered on https://swift.org/download/#snapshots might not be new enough. I'll investigate soon and update here with what works 🙃

@AndrewSB I think you need a master toolchain.

@AndrewSB please also notice there's a slight api change shown in #14744


Read through the nginx code and figure out why it's faster

https://github.com/nginx/nginx/tree/master/src

Note: this is only for large files, we're within a factor of 2 for small requests but we're behind by 3 orders of magnitude for large files. I'm seeing TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies.  Check SNMP counters. in dmesg, maybe if we accepted more simultaneous connections the kernel wouldn't throttle us? This could also just be because nginx uses mmap, that's on the feature list.

This was an error on my part - my nginx config was set up wrong so it was serving a 404 on every page, which understandably is significantly faster than sending back 7 megs of binary. We're down to a factor of three difference (yay!)

Down to factor of 2 with https://github.com/jyn514/crappy-server/issues/13.

TCP: request_sock_TCP: Possible SYN flooding on port 80. Sending cookies. Check SNMP counters. has gone away for requests of 22MB, it's still present trying to get a 77MB file though. I'm inclined to leave it, I doubt 100 people at a time are downloading files that big off a single server is that common.

We could also look into thread pools and see if that makes a difference. That does mean implementing proper semaphores.


Link to mentioned articles in the docs instead of just naming them

Very simple nuisances that had been peeving me for a while. Without the direct links, it forces the users to look around the internet, even though the author clearly intended for a specific page to be seen.
These were the only 4 times the class reference said "article" by the way.

Removed the quotes around them

Thanks!

Cherry-picked for 4.2.2.


ios 12?

I cannot upgrade to ios 13.
is it technically doable for ios 12? I am on 12.4
thank you

It is possible, yes. Once I get the last few issues ironed out to the best of my ability I can look into it.

lovely, can't wait, thank you! :-)
On 12/13/20, Lightmann<EMAIL_ADDRESS>wrote:

It is possible, yes. Once I get the last few issues ironed out to the best
of my ability I can look into it.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/UsrLightmann/Quorra/issues/28#issuecomment-744019155

Okay, have a test build ready. Would you be willing to try it out? If so, please shoot me an email (mail icon on my repo

iOS support added with v1.0.7

thank you for the email build. I wasn't able to test it as quickly as you but the latest released version works!
cheers! 🙂


Sometimes ProjectStartedEventArgs doesn't contain Properties/Items

In some .binlogs for some projects for some initial targets we see Properties/Items missing from under the project node. We think it's most likely in MSBuild.
All the BinaryLogger does is this:
https://source.dot.net/#Microsoft.Build/Logging/BinaryLogger/BuildEventArgsWriter.cs,179
Basically under some circumstances ProjectStartedEventArgs.Properties may be null.

There are two reasons that the project started args would differ:
The first is that by default we do not log properties/items if the build is running on a remote node: https://github.com/microsoft/msbuild/blob/master/src/Build/BackEnd/Components/Logging/ProjectLoggingContext.cs#L88. this accounts for almost all of the diff you might see.
The second is that if the system finds the result of a build in the cache, here: https://github.com/microsoft/msbuild/blob/master/src/Build/BackEnd/Components/Logging/NodeLoggingContext.cs#L83, then the properties and items have not be rehydrated and will not be present


Vortex Cache Replacement Algorithm

The Vortex cache replacement algorithm is a novel algorithm designed for cache management in computing systems, especially in environments with large, dynamic datasets. It optimizes cache hits and minimizes cache misses by determining which items to evict from the cache based on the frequency of access patterns.

@pankaj-bind Please Review my Pr

@pankaj-bind Please Review my Pr


chore(deps): update dependency gdatacyberdefense.vaas to v7.3.0 - abandoned

This PR contains the following updates:

Package
Type
Update
Change

GDataCyberDefense.Vaas
nuget
minor
7.2.0 -> 7.3.0

:warning: Warning
Some dependencies could not be looked up. Check the warning logs for more information.

Configuration
:date: Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Autoclosing Skipped
This PR has been flagged for autoclosing. However, it is being skipped due to the branch being already modified. Please close/delete it manually or report a bug if you think this is in error.


Add QCT to LF-Edge lanscape

Add logo and metadata for QCT

https://drive.google.com/open?id=1T3G8_hynJSRHa_xbPOx5vD6mlefn1TB9


Update locale/en from nullius-1.3.4

This PR is automatically created by the GitHub Action workflow Create update-locale PR

closing in favor of https://github.com/sakuro/nullius-ja/pull/78


test speed extremely slow with pytorch 0.4.1 and 1.0

Tried both pytorch 0.4.1 (cuda9) pytorch 1.0 (cuda10) with m2det. Demo runs fine with downloaded pretrain model. Training (800 config) seems to be fine too, e.g. 4 GPUs are all heavily utilized during training.
However, test speed is around 5s per image (not 5 fps, but 5 seconds per frame! it means many hours to get an evaluaiton score). Look into it closely, it seems GPU has very low utility.
Anyone has seen this issue? Thx.
Env: ubuntu 16.04.6, Nvidia 1080 ti (4 GPUs). Cuda9/cudnn7.2.1 or cuda10/cudnn7.4.1.

After turns off soft_nms, speed increased about 10x, still get only about 2.5 images/s (for 704x704) input, well below 11.8fps quoted in the paper for 800 size. GPU 1080 Ti is comparable to Titan X.

I also encountered a similar problem when test.
I improved by using CUDA 9.2.
Env

NVIDIA Docker: 1.0.1
GPU: GTX 1080 ti
Image Size: 800x800

Time

nvidia/cuda:9.0-cudnn7-devel-ubuntu16.04 & pytorch 0.4.1

It was almost normal(8-10 fps) but occasionally very slow (~10s /per image)

It was very slow when I used weight made by other machine
But it was strange because it is normal by weight...


python3.pkgs.numba: report a valid version

just now if packages check for a numba bigger than a specific version they will fail to find this package
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 248316 run on x86_64-linux 1

10 packages marked as broken and skipped:

piper-train
piper-train.dist
python310Packages.graspologic
python310Packages.graspologic.dist
python310Packages.qiskit
python310Packages.qiskit-machine-learning
python310Packages.qiskit-machine-learning.dist
python310Packages.qiskit.dist
python310Packages.scikit-tda
python310Packages.scikit-tda.dist

59 packages failed to build:

pentestgpt
pentestgpt.dist
pianotrans
pianotrans.dist
pitivi
python310Packages.awkward
python310Packages.awkward.dist
python310Packages.bambi
python310Packages.bambi.dist
python310Packages.clifford
python310Packages.clifford.dist
python310Packages.coffea
python310Packages.coffea.dist
python310Packages.dask-awkward
python310Packages.dask-awkward.dist
python310Packages.dask-glm
python310Packages.dask-glm.dist
python310Packages.dask-ml
python310Packages.dask-ml.dist
python310Packages.datashader
python310Packages.datashader.dist
python310Packages.gumath
python310Packages.gumath.dist
python310Packages.hyppo
python310Packages.hyppo.dist
python310Packages.langchain
python310Packages.langchain.dist
python310Packages.librosa
python310Packages.librosa.dist
python310Packages.mplhep
python310Packages.mplhep.dist
python310Packages.numbaWithCuda
python310Packages.numbaWithCuda.dist
python310Packages.piano-transcription-inference
python310Packages.piano-transcription-inference.dist
python310Packages.pymc
python310Packages.pymc.dist
python310Packages.pynndescent
python310Packages.pynndescent.dist
python310Packages.pyscf
python310Packages.pyscf.dist
python310Packages.pytensor
python310Packages.pytensor.dist
python310Packages.sparse
python310Packages.sparse.dist
python310Packages.stumpy
python310Packages.stumpy.dist
python310Packages.torchlibrosa
python310Packages.torchlibrosa.dist
python310Packages.trackpy
python310Packages.trackpy.dist
python310Packages.umap-learn
python310Packages.umap-learn.dist
python310Packages.uproot
python310Packages.uproot.dist
python310Packages.vector
python310Packages.vector.dist
tts
tts.dist

35 packages built:

openai-whisper (python310Packages.openai-whisper)
openai-whisper.dist (python310Packages.openai-whisper.dist)
python310Packages.aeppl
python310Packages.aeppl.dist
python310Packages.aesara
python310Packages.aesara.dist
python310Packages.arviz
python310Packages.arviz.dist
python310Packages.cppe
python310Packages.cppe.dist
python310Packages.ffcv
python310Packages.ffcv.dist
python310Packages.galois
python310Packages.galois.dist
python310Packages.numba
python310Packages.numba-scipy
python310Packages.numba-scipy.dist
python310Packages.numba.dist
python310Packages.phik
python310Packages.phik.dist
python310Packages.pygmo
python310Packages.pymatting
python310Packages.pymatting.dist
python310Packages.pymoo
python310Packages.pymoo.dist
python310Packages.resampy
python310Packages.resampy.dist
python310Packages.shap
python310Packages.shap.dist
python310Packages.stytra
python310Packages.stytra.dist
python310Packages.timezonefinder
python310Packages.timezonefinder.dist
python310Packages.xarray-einstats
python310Packages.xarray-einstats.dist

The current patch seems to leave numba.__version__ at 0+unknown.
Would you please add another patch?
https://github.com/numba/numba/blob/46059957ad416e68476d1e5f32ccd59f7d5df2bb/numba/_version.py#L639
Since python310Packages.awkward looks at this variable, it cannot determine the numba version.

Looks like this might resolve https://github.com/NixOS/nixpkgs/issues/248363


New release

I am once again asking you to build a new release (inc. Windows builds) since it's been 1½ years since the last release and many improvements have been made in the meantime.
Thanks!

https://github.com/cathugger/mkp224o/releases/tag/v1.7.0 done.


Lighting Network

Hi Nicolas,
Do you plan an integration with the Lighting Network?
I'm using your great lib in my projects!

I think @NicolasDorier is planning it. I am planning it myself, too. It's just we are busy with other stuff at the moment.
But it also worth defining what "integration with the Lighting Network" means. I think there are two ways to do this:

Implement a client that connects to a lightning daemon, it'd be equivalent to the RPCClient class, which is connecting to Bitcoin Core's daemon. Today lnd is considered to be the most stable LN daemon. Yesterday lnd launched on the mainnet. That being said, a month ago I played around with it and it was terribly buggy. Nevertheless you can do this work yourself easily.
Implement the Lightning Primitives.

I think integration with LN would be done in a separate repository. But yeah today I have not started working on it.

I have done some of this work inside BTCPay I may extract it into reusable lib once it stabilize.


add rbac permissive mode attributes to request metrics

https://github.com/istio/istio/issues/5345

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
If they are not already assigned, you can assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/cc @kyessenov

/cc @clyang82

@gyliu513: GitHub didn't allow me to request PR reviews from the following users: clyang82.
Note that only istio members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/cc @clyang82

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: andraxylia, kyessenov
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

install/OWNERS [andraxylia]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

Can someone please provide documentation of these changes, including expected cardinality impact on individual metrics?
I don't see the supporting attributes documented on the website or anywhere else, either. All attributes should be well-documented.
In the future, it would be good to bring these changes to the Policy and Telemetry WG for discussion, as this impacts all customers of default metrics, etc.


Doc fix

Coverage remained the same at 100.0% when pulling 5ffe2c4ccfb7304e2b130784d64c449a5c146804 on doc-fix into 908a6fb05a671c4af015f2d29262781f270ac5de on feature-logger.


how to find the temporary cache folder?

Question

I use Windows 8.1
How can I find the temporary cache folder when using mpv player

C:\Users\Name>mpv --ytdl link_youtube

Well using from the cmd, it doesn't tell me what folder the files are in and my question is that I want to know where the caches or files are stored.

Address this to mpv support.


Save cookies on disk to avoid repeated relogin

Why writing bots, it is often needed to restart the whole script. But each time Itchat will start a new requests.sesion(), and QR need to be re-scanned.
Could it be implemented that cookies are saved on disk and reuse it whenever possible?

@ccaapton
It's possible with all the necessary information stored.
But actually itchat need to re-scan after about two minutes because of the heart-beat loop of wechat.
I will get it done in the next version.

@ccaapton I have add this feature in 1.0.12 of py2.
Have a try with the new version of itchat:
pip install itchat --upgrade

You may have a look at this commit for more details: No more re-scan in repeat login [RB#31: ccaapton]
And the following is the demo program:
import itchat

if itchat.load_login_status():
    @itchat.msg_register('Text')
    def simple_reply(msg):
        print(msg['Text'])
    itchat.run()
else:
    itchat.auto_login()
    itchat.dump_login_status()
    print('Config stored')

Truly thanks for your suggestion!


[NEXT] Trailing slashes not working in localePath

Environment

Operating System: Windows_NT
Node Version:     v18.12.1
Nuxt Version:     3.0.0
Nitro Version:    1.0.0
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      extends, app, ssr, css, modules, vite, runtimeConfig, hooks, router
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

Reproduction
In any .vue file:
router.push(localePath({ name: '<route-name>', hash: `#${<uuid>}` }));

In nuxt.config.ts:
export default defineNuxtConfig({
	// ...
	router: {
		options: {
			strict: true,
		},
	},
});

I guess it worked when I set router.trailingSlash to true in Nuxt 2
Describe the bug
I get this warning in console:
[Vue Router warn]: The selector "#<uuid>" is invalid. If you are using an id selector, make sure to escape it. You can find more information about escaping characters in selectors at https://mathiasbynens.be/notes/css-escapes or use CSS.escape (https://developer.mozilla.org/en-US/docs/Web/API/CSS/escape).

Additional context
No response
Logs
No response

Hi, thanks for reporting your issue. Does the issue persist without passing hash? router.push(localePath({ name: '<route-name>' })); (I understand you may require it, but curious)

@ineshbose Every time without specifying a hash, or if the hash is an empty string, I get the link without the slash at the end. It would be great if this functionality could be added ❤

Hi!
nuxtjs/i18n v8 beta has already provide trailingSlash option.
Could you try to it on nuxt.config.ts?

@kazupon I have configs in seperate files, but this option works. Thanks you very much!
const options: NuxtI18nOptions = {
	trailingSlash: true,
	// ...
};
export default options;


Update aws-java-sdk-core to 1.12.485

About this PR
📦 Updates com.amazonaws:aws-java-sdk-core from 1.12.481 to 1.12.485
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.amazonaws", artifactId = "aws-java-sdk-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.amazonaws", artifactId = "aws-java-sdk-core" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #541.


Guest Mode Switch

Thanks for developing this plugin. It's very well laid out!
I forked https://github.com/PeteLawrence/homebridge-people a while ago to add a virtual switch so that I could essentially force the Anyone sensor to report occupancy regardless of any of the child sensors.
My plugin https://github.com/zackwag/homebridge-people-guest-mode is no where near as good as yours.
I was wondering if it would be possible for you to add a virtual switch to accomplish this task.
Essentially, you add a virtual stateful switch and when the Anyone sensor reports occupancy, it will check to see if the switch is turned on. If it is, it returns true and doesn't check any child sensors.

Thanks for the many compliments :)
yes I can and will do that...
give me some time and it will be implemented

Looking forward to this! Would be an excellent add-on feature to this plugin and will help solve a lot of situations :)

+1 🙂


slowness of GEO-> HCA script

The GEO to HCA script has become slow when converting large datasets (anything over 100 samples). This needs to be investigated and optimised so that it can convert larger datasets.

The running time is now under 8 mins when the large dataset with >2000 samples & >5500 file names is requested :) Standardly though it runs in <20 secs for most datasets (stats below). There are a couple more updates I want to make (add some more technology specifics) but then I'll create a pull request. It would be great @yusra-haider if you could review to see if further improvements might be good. We could meet sometime Monday if you're free!
`

GEO   accession
number of samples
number of experiments
number of fastq files
number of   multiprocessing threads
time taken
manual intervention by   user?

GSE140231
12
12
56
1
0m14.464s

GSE140231
12
12
56
5
0m14.266s

GSE101207
13
13
22
1
0m13.189s

GSE101207
13
13
22
5
0m13.129s

GSE150132
5
5
files   not in ENA
1
0m19.098s
yes   (script asks the user to indicate if a publication title is correct or not)

GSE150132
5
5
files not in ENA
5
0m17.204s
yes (script asks the user to indicate if a   publication title is correct or not)

GSE116222
9
9
files   not in ENA
1
0m14.394s

GSE116222
9
9
files not in ENA
5
0m13.960s

GSE96769
2779
2779
5557
1
8m15.466s

GSE96769
2779
2779
5557
5
7m35.361s

`

The running time is now under 8 mins when the large dataset with >2000 samples & >5500 file names is requested :) Standardly though it runs in <20 secs for most datasets (stats below). There are a couple more updates I want to make (add some more technology specifics) but then I'll create a pull request. It would be great @yusra-haider if you could review to see if further improvements might be good. We could meet sometime Monday if you're free!
`

GEO   accession
number of samples
number of experiments
number of fastq files
number of   multiprocessing threads
time taken
manual intervention by   user?

GSE140231
12
12
56
1
0m14.464s

GSE140231
12
12
56
5
0m14.266s

GSE101207
13
13
22
1
0m13.189s

GSE101207
13
13
22
5
0m13.129s

GSE150132
5
5
files   not in ENA
1
0m19.098s
yes   (script asks the user to indicate if a publication title is correct or not)

GSE150132
5
5
files not in ENA
5
0m17.204s
yes (script asks the user to indicate if a   publication title is correct or not)

GSE116222
9
9
files   not in ENA
1
0m14.394s

GSE116222
9
9
files not in ENA
5
0m13.960s

GSE96769
2779
2779
5557
1
8m15.466s

GSE96769
2779
2779
5557
5
7m35.361s

`

Linking to new tickets for improvements:
https://github.com/ebi-ait/dcp-ingest-central/issues/133

Linking to new tickets for improvements:
https://github.com/ebi-ait/dcp-ingest-central/issues/133

Everything is ready now for review @yusra-haider, I'll do a pull request to the improve_speed branch now.

Everything is ready now for review @yusra-haider, I'll do a pull request to the improve_speed branch now.

I have refactored the script based on Yusra's review/discussion and merged the pull request for that branch so the latest version is now ready for others to use. I created a new refactoring branch today to improve the readability and maintainability of the code, including splitting into separate scripts and documenting functions.

I have refactored the script based on Yusra's review/discussion and merged the pull request for that branch so the latest version is now ready for others to use. I created a new refactoring branch today to improve the readability and maintainability of the code, including splitting into separate scripts and documenting functions.

Finished refactoring so moving to done.

Finished refactoring so moving to done.


err = b from CHIP on attributes

Any idea what causes this? It is transitory and will go away after a while.
I (87517) chip[IM]: Received status response, status is 0x00
I (87527) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0xFFFC is 0 **********
I (87537) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0xFFFD is 4 **********
I (87547) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0000 is 0 **********
I (87557) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0001 is 0 **********
I (87567) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0002 is 0 **********
I (87577) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0003 is 0 **********
I (87587) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0004 is 0 **********
E (87607) chip[DMG]: Error retrieving data from clusterId: 0x0000_0005, err = b
err b is CHIP_ERROR_NO_MEMORY
This is from the subscription Google Home initially sets up to monitor the device.

This error may be caused when reading Attribute 0x0005 of scene cluster which is optional in specification.
I tried to recreate this using ./chip-tool scenes read-by-id "0xfffc,0xfffd,1,2,3,4,5" 6 1 but I could not.
Can you check if adding the optional attribute solves this for Google home?
cluster_t *scene_cluster = cluster::get(endpoint, Scenes::Id);
attribute_t *last_configured_by = attribute::create(scene_cluster, 0x0005, ATTRIBUTE_FLAG_NULLABLE, esp_matter_nullable_uint64(nullable<uint64_t>()));

I get many, many of these err b
I (108127) app_main: Free 63284
I (108627) app_main: Free 63284
I (109127) app_main: Free 63304
I (109487) chip[EM]: >>> [E:61309r M:23965279] (U) Msg RX from 0:649B121CB1D7A4A8 [0000] --- Type 0000:30 (SecureChannel:CASE_Sigma1)
I (109487) chip[IN]: CASE Server received Sigma1 message. Starting handshake. EC 0x3fc9af90
I (109497) chip[IN]: CASE Server disabling CASE session setups
I (109507) chip[EM]: <<< [E:61309r M:56296145 (Ack:23965279)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (109517) chip[IN]: (U) Sending msg 56296145 to IP address 'UDP:[FE80::1E53:F9FF:FEB3:3B54%st1]:5540'
I (109527) chip[SC]: Received Sigma1 msg
I (109537) chip[SC]: CASE matched destination ID: fabricIndex 1, NodeID 0x00000000810609B2
I (110037) chip[EM]: <<< [E:61309r M:56296146 (Ack:23965279)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:31 (SecureChannel:CASE_Sigma2)
I (110037) chip[IN]: (U) Sending msg 56296146 to IP address 'UDP:[FE80::1E53:F9FF:FEB3:3B54%st1]:5540'
I (110047) chip[SC]: Sent Sigma2 msg
E (110057) chip[DL]: Long dispatch time: 568 ms, for event type 3
I (110067) app_main: Free 58972
I (110107) chip[EM]: >>> [E:61309r M:23965280 (Ack:56296146)] (U) Msg RX from 0:649B121CB1D7A4A8 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (110207) chip[EM]: >>> [E:61309r M:23965281 (Ack:56296146)] (U) Msg RX from 0:649B121CB1D7A4A8 [0000] --- Type 0000:32 (SecureChannel:CASE_Sigma3)
I (110207) chip[EM]: <<< [E:61309r M:56296147 (Ack:23965281)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (110227) chip[IN]: (U) Sending msg 56296147 to IP address 'UDP:[FE80::1E53:F9FF:FEB3:3B54%st1]:5540'
I (110237) chip[SC]: Received Sigma3 msg
E (110247) chip[SC]: The device does not support GetClock_RealTimeMS() API: 6c.  Falling back to Last Known Good UTC Time
I (111267) NimBLE: GAP procedure initiated: advertise;
I (111267) NimBLE: disc_mode=0
I (111267) NimBLE:  adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 adv_itvl_min=32 adv_itvl_max=32
I (111277) NimBLE:

I (111277) chip[EM]: <<< [E:61309r M:56296148 (Ack:23965281)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
I (111297) chip[IN]: (U) Sending msg 56296148 to IP address 'UDP:[FE80::1E53:F9FF:FEB3:3B54%st1]:5540'
I (111307) chip[SC]: SecureSession[0x3fc998d8]: Moving from state 'kEstablishing' --> 'kActive'
I (111317) chip[IN]: CASE Session established to peer: <0000000097985A03, 1>
I (111327) chip[IN]: CASE Server enabling CASE session setups
E (111327) chip[DL]: Long dispatch time: 1124 ms, for event type 3
I (111337) chip[EM]: >>> [E:61310r M:169145165] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:03 (IM:SubscribeRequest)
I (111347) chip[DMG]: Final negotiated min/max parameters: Min = 0s, Max = 120s
I (111357) chip[EM]: >>> [E:61309r M:23965282 (Ack:56296148)] (U) Msg RX from 0:649B121CB1D7A4A8 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (111367) NimBLE: GAP procedure initiated: stop advertising.

I (111377) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x001D's Attribute 0xFFFC is 0 **********
E (111387) chip[DMG]: Error retrieving data from clusterId: 0x0000_001F, err = b
I (111397) chip[EM]: <<< [E:61310r M:85848652 (Ack:169145165)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111407) chip[IN]: (S) Sending msg 85848652 on secure session with LSID: 41766
I (111417) app_main: Free 60416
I (111427) chip[EM]: >>> [E:61310r M:169145166 (Ack:85848652)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111437) chip[IM]: Received status response, status is 0x00
I (111447) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x001F's Attribute 0xFFFC is 0 **********
I (111457) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0028's Attribute 0xFFFC is 0 **********
I (111467) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0028's Attribute 0xFFFD is 1 **********
I (111477) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0028's Attribute 0x0005 is  **********
E (111487) chip[DMG]: Error retrieving data from clusterId: 0x0000_0028, err = b
I (111497) chip[EM]: <<< [E:61310r M:85848653 (Ack:169145166)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111507) chip[IN]: (S) Sending msg 85848653 on secure session with LSID: 41766
I (111537) chip[EM]: >>> [E:61310r M:169145167 (Ack:85848653)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111537) chip[IM]: Received status response, status is 0x00
I (111547) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0030's Attribute 0xFFFC is 0 **********
I (111557) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0030's Attribute 0xFFFD is 1 **********
I (111567) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0030's Attribute 0x0000 is 0 **********
E (111577) chip[DMG]: Error retrieving data from clusterId: 0x0000_0030, err = b
I (111587) chip[EM]: <<< [E:61310r M:85848654 (Ack:169145167)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111597) chip[IN]: (S) Sending msg 85848654 on secure session with LSID: 41766
I (111637) chip[EM]: >>> [E:61310r M:169145168 (Ack:85848654)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111637) chip[IM]: Received status response, status is 0x00
I (111647) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0031's Attribute 0xFFFD is 1 **********
E (111657) chip[DMG]: Error retrieving data from clusterId: 0x0000_0031, err = b
I (111667) chip[EM]: <<< [E:61310r M:85848655 (Ack:169145168)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111677) chip[IN]: (S) Sending msg 85848655 on secure session with LSID: 41766
I (111737) chip[EM]: >>> [E:61310r M:169145169 (Ack:85848655)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111737) chip[IM]: Received status response, status is 0x00
I (111747) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0033's Attribute 0xFFFC is 0 **********
I (111757) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0033's Attribute 0xFFFD is 1 **********
I (111767) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x003C's Attribute 0xFFFC is 0 **********
E (111777) chip[DMG]: Error retrieving data from clusterId: 0x0000_003C, err = b
I (111797) chip[EM]: <<< [E:61310r M:85848656 (Ack:169145169)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111797) chip[IN]: (S) Sending msg 85848656 on secure session with LSID: 41766
I (111837) chip[EM]: >>> [E:61310r M:169145170 (Ack:85848656)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111847) chip[IM]: Received status response, status is 0x00
I (111847) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x003C's Attribute 0xFFFD is 1 **********
I (111857) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x003E's Attribute 0xFFFC is 0 **********
E (111877) chip[DMG]: Error retrieving data from clusterId: 0x0000_003E, err = b
I (111887) chip[EM]: <<< [E:61310r M:85848657 (Ack:169145170)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111887) chip[IN]: (S) Sending msg 85848657 on secure session with LSID: 41766
I (111927) app_main: Free 60964
I (111947) chip[EM]: >>> [E:61310r M:169145171 (Ack:85848657)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111947) chip[IM]: Received status response, status is 0x00
E (111957) chip[DMG]: Error retrieving data from clusterId: 0x0000_003E, err = b
I (111967) chip[EM]: <<< [E:61310r M:85848658 (Ack:169145171)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111977) chip[IN]: (S) Sending msg 85848658 on secure session with LSID: 41766
I (111987) chip[EM]: >>> [E:61310r M:169145172 (Ack:85848658)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111997) chip[IM]: Received status response, status is 0x00
I (112007) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x003E's Attribute 0xFFFD is 1 **********
E (112017) chip[DMG]: Error retrieving data from clusterId: 0x0000_003E, err = b
I (112027) chip[EM]: <<< [E:61310r M:85848659 (Ack:169145172)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (112037) chip[IN]: (S) Sending msg 85848659 on secure session with LSID: 41766
I (112047) chip[EM]: >>> [E:61310r M:169145173 (Ack:85848659)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (112057) chip[IM]: Received status response, status is 0x00
I (112067) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0036's Attribute 0xFFFC is 0 **********
I (112077) chip[ZCL]: Node is currently connected to Wi-Fi network with BSSID:
I (112077) chip[ZCL]: The current type of Wi-Fi security used: 4
I (112087) chip[ZCL]: The current 802.11 standard version in use by the Node: 3
I (112097) chip[ZCL]: The channel that Wi-Fi communication is currently operating on is: 1
E (112107) chip[DMG]: Error retrieving data from clusterId: 0x0000_0036, err = b
I (112117) chip[EM]: <<< [E:61310r M:85848660 (Ack:169145173)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (112127) chip[IN]: (S) Sending msg 85848660 on secure session with LSID: 41766
I (112147) chip[EM]: >>> [E:61310r M:169145174 (Ack:85848660)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (112147) chip[IM]: Received status response, status is 0x00
I (112157) chip[ZCL]: The channel that Wi-Fi communication is currently operating on is: 1
I (112167) chip[ZCL]: The current RSSI of the Node’s Wi-Fi radio in dB: -62
I (112177) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0036's Attribute 0xFFFD is 1 **********
I (112187) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x001D's Attribute 0xFFFC is 0 **********
E (112197) chip[DMG]: Error retrieving data from clusterId: 0x0000_001D, err = b
I (112207) chip[EM]: <<< [E:61310r M:85848661 (Ack:169145174)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (112217) chip[IN]: (S) Sending msg 85848661 on secure session with LSID: 41766
I (112257) chip[EM]: >>> [E:61310r M:169145175 (Ack:85848661)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (112267) chip[IM]: Received status response, status is 0x00
I (112267) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0003's Attribute 0xFFFC is 0 **********
I (112277) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0003's Attribute 0xFFFD is 4 **********
I (112287) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0003's Attribute 0x0000 is 0 **********
I (112297) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0003's Attribute 0x0001 is 0 **********
I (112317) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0004's Attribute 0xFFFC is 1 **********
I (112327) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0004's Attribute 0xFFFD is 4 **********
I (112337) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0004's Attribute 0x0000 is 128 **********
E (112347) chip[DMG]: Error retrieving data from clusterId: 0x0000_0004, err = b
I (112357) chip[EM]: <<< [E:61310r M:85848662 (Ack:169145175)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (112367) chip[IN]: (S) Sending msg 85848662 on secure session with LSID: 41766
E (112377) chip[DL]: Long dispatch time: 105 ms, for event type 3
I (112387) chip[EM]: >>> [E:61310r M:169145176 (Ack:85848662)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (112397) chip[IM]: Received status response, status is 0x00
I (112397) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0xFFFC is 0 **********
I (112407) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0xFFFD is 4 **********
I (112417) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0000 is 0 **********
I (112437) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0001 is 0 **********
I (112447) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0002 is 0 **********
I (112457) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0003 is 0 **********
I (112467) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0004 is 0 **********
E (112477) chip[DMG]: Error retrieving data from clusterId: 0x0000_0005, err = b
I (112487) chip[EM]: <<< [E:61310r M:85848663 (Ack:169145176)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (112497) chip[IN]: (S) Sending msg 85848663 on secure session with LSID: 41766
E (112507) chip[DL]: Long dispatch time: 105 ms, for event type 3
I (112507) app_main: Free 60560
I (112557) chip[EM]: >>> [E:61310r M:169145177 (Ack:85848663)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (112557) chip[IM]: Received status response, status is 0x00
I (112567) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0xFFFC is 1 **********
I (112577) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0xFFFD is 4 **********
I (112587) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x0000 is 0 **********
I (112597) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4000 is 1 **********
I (112607) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4001 is 0 **********
I (112617) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4002 is 0 **********
I (112627) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4003 is 0 **********
E (112647) chip[DMG]: Error retrieving data from clusterId: 0x0000_0006, err = b
I (112657) chip[EM]: <<< [E:61310r M:85848664 (Ack:169145177)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (112667) chip[IN]: (S) Sending msg 85848664 on secure session with LSID: 41766
E (112667) chip[DL]: Long dispatch time: 106 ms, for event type 3
I (112677) chip[EM]: >>> [E:61310r M:169145178 (Ack:85848664)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (112687) chip[IM]: Received status response, status is 0x00
I (112697) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0xFFFC is 3 **********
I (112707) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0xFFFD is 5 **********
I (112717) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 1 **********
I (112727) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0011 is 254 **********
I (112737) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x000F is 0 **********
I (112747) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0001 is 0 **********
I (112767) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0002 is 1 **********
I (112777) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0003 is 254 **********
I (112787) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x4000 is 0 **********
E (112797) chip[DMG]: Error retrieving data from clusterId: 0x0000_0008, err = b
I (112807) chip[EM]: <<< [E:61310r M:85848665 (Ack:169145178)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (112817) chip[IN]: (S) Sending msg 85848665 on secure session with LSID: 41766
E (112827) chip[DL]: Long dispatch time: 128 ms, for event type 3
I (112867) chip[EM]: >>> [E:61310r M:169145179 (Ack:85848665)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (112867) chip[IM]: Received status response, status is 0x00
I (112877) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x001D's Attribute 0xFFFC is 0 **********
I (112887) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x0003's Attribute 0xFFFC is 0 **********
I (112897) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x0003's Attribute 0xFFFD is 4 **********
I (112907) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x0003's Attribute 0x0000 is 0 **********
I (112917) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x0003's Attribute 0x0001 is 0 **********
E (112927) chip[DMG]: Error retrieving data from clusterId: 0x0000_0003, err = b
I (112937) chip[EM]: <<< [E:61310r M:85848666 (Ack:169145179)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (112947) chip[IN]: (S) Sending msg 85848666 on secure session with LSID: 41766
I (112967) chip[EM]: >>> [E:61310r M:169145180 (Ack:85848666)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (112967) chip[IM]: Received status response, status is 0x00
I (112977) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x001E's Attribute 0xFFFC is 0 **********
I (112987) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x001E's Attribute 0xFFFD is 1 **********
I (112997) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x0004's Attribute 0xFFFC is 1 **********
I (113007) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x0004's Attribute 0xFFFD is 4 **********
I (113017) esp_matter_attribute: ********** Endpoint 0x0002's Cluster 0x0004's Attribute 0x0000 is 128 **********
E (113027) chip[DMG]: Error retrieving data from clusterId: 0x0000_0004, err = b
I (113047) chip[EM]: <<< [E:61310r M:85848667 (Ack:169145180)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (113047) chip[IN]: (S) Sending msg 85848667 on secure session with LSID: 41766
I (113057) app_main: Free 60556
I (113067) chip[EM]: >>> [E:61310r M:169145181 (Ack:85848667)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (113077) chip[IM]: Received status response, status is 0x00
I (113087) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x001D's Attribute 0xFFFC is 0 **********
I (113097) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x0003's Attribute 0xFFFC is 0 **********
E (113107) chip[DMG]: Error retrieving data from clusterId: 0x0000_0003, err = b
I (113117) chip[EM]: <<< [E:61310r M:85848668 (Ack:169145181)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (113127) chip[IN]: (S) Sending msg 85848668 on secure session with LSID: 41766
I (113167) chip[EM]: >>> [E:61310r M:169145182 (Ack:85848668)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (113177) chip[IM]: Received status response, status is 0x00
I (113177) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x0003's Attribute 0xFFFD is 4 **********
I (113187) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x0003's Attribute 0x0000 is 0 **********
I (113207) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x0003's Attribute 0x0001 is 0 **********
I (113217) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x003B's Attribute 0xFFFC is 30 **********
I (113227) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x003B's Attribute 0xFFFD is 1 **********
I (113237) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x003B's Attribute 0x0000 is 2 **********
I (113247) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x003B's Attribute 0x0001 is 0 **********
I (113257) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x003B's Attribute 0x0002 is 3 **********
I (113267) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x0040's Attribute 0xFFFC is 0 **********
I (113277) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x0040's Attribute 0xFFFD is 1 **********
E (113287) chip[DMG]: Error retrieving data from clusterId: 0x0000_0040, err = b
I (113297) chip[EM]: <<< [E:61310r M:85848669 (Ack:169145182)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (113307) chip[IN]: (S) Sending msg 85848669 on secure session with LSID: 41766
E (113317) chip[DL]: Long dispatch time: 138 ms, for event type 3
I (113377) chip[EM]: >>> [E:61310r M:169145183 (Ack:85848669)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (113377) chip[IM]: Received status response, status is 0x00
I (113387) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x0041's Attribute 0xFFFC is 0 **********
I (113397) esp_matter_attribute: ********** Endpoint 0x0003's Cluster 0x0041's Attribute 0xFFFD is 1 **********
I (113407) esp_matter_attribute: ********** Endpoint 0x0004's Cluster 0x001D's Attribute 0xFFFC is 0 **********
E (113417) chip[DMG]: Error retrieving data from clusterId: 0x0000_001D, err = b
I (113437) chip[EM]: <<< [E:61310r M:85848670 (Ack:169145183)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (113437) chip[IN]: (S) Sending msg 85848670 on secure session with LSID: 41766
I (113477) chip[EM]: >>> [E:61310r M:169145184 (Ack:85848670)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (113477) chip[IM]: Received status response, status is 0x00
I (113487) chip[EM]: <<< [E:61310r M:85848671 (Ack:169145184)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (113497) chip[IN]: (S) Sending msg 85848671 on secure session with LSID: 41766
I (113517) chip[EM]: >>> [E:61310r M:169145185 (Ack:85848671)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (113527) chip[IM]: Received status response, status is 0x00
I (113527) chip[DMG]: Refresh Subscribe Sync Timer with min 0 seconds and max 120 seconds
I (113537) chip[EM]: <<< [E:61310r M:85848672 (Ack:169145185)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:04 (IM:SubscribeResponse)
I (113547) chip[IN]: (S) Sending msg 85848672 on secure session with LSID: 41766
I (113567) app_main: Free 61516
I (113577) chip[EM]: >>> [E:61310r M:169145186 (Ack:85848672)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (114067) app_main: Free 63304
I (114567) app_main: Free 63304
I (115067) app_main: Free 63304
I (115567) app_main: Free 63304
I (116067) app_main: Free 63304
I (116567) app_main: Free 63304

Another interaction from Google Home that does not generate any error b
So what is the pattern?
 (109903) app_main: Free 63140
I (110363) chip[EM]: >>> [E:61317r M:38411751] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:08 (IM:InvokeCommandRequest)
I (110363) esp_matter_command: Received command 0x0004 for enpoint 0x0001's cluster 0x00000008
I (110373) chip[ZCL]: 0x3c12fb40MOVE_TO_LEVEL_WITH_ON_OFF 4 null 0 0
I (110383) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 1 **********
I (110393) chip[ZCL]: Setting on/off to 0x3c12fcb0 due to level change
I (110403) chip[ZCL]: On/Off set value: 1 1
I (110403) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x0000 is 0 **********
I (110413) chip[ZCL]: Toggle on/off from 0 to 1
I (110423) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0xFFFC is 1 **********
I (110433) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4001 is 0 **********
I (110443) chip[ZCL]: On Command - OffWaitTime :  0
I (110443) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4002 is 0 **********
I (110463) chip[ZCL]: On/Toggle Command - Stop Timer
I (110463) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4000 is 1 **********
I (110473) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x0000 is 1 **********
I (110483) app_main: Free 59956
I (110493) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0003 is 0 **********
I (110503) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0xFFFC is 3 **********
I (110513) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4000 is 1 **********
I (110523) chip[EM]: <<< [E:61317r M:151345120 (Ack:38411751)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:09 (IM:InvokeCommandResponse)
I (110533) chip[IN]: (S) Sending msg 151345120 on secure session with LSID: 60740
E (110543) chip[DL]: Long dispatch time: 183 ms, for event type 3
I (110553) chip[EM]: >>> [E:61318r M:38411752] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:08 (IM:InvokeCommandRequest)
I (110563) esp_matter_command: Received command 0x0001 for enpoint 0x0001's cluster 0x00000006
I (110573) chip[ZCL]: On/Off set value: 1 1
I (110573) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x0000 is 1 **********
I (110583) chip[ZCL]: On/off already set to new value
I (110593) chip[EM]: <<< [E:61318r M:151345121 (Ack:38411752)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:09 (IM:InvokeCommandResponse)
I (110603) chip[IN]: (S) Sending msg 151345121 on secure session with LSID: 60740
I (110623) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0003 is 0 **********
I (110623) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x0000 is 1 **********
I (110633) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4000 is 1 **********
I (110653) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4002 is 0 **********
I (110663) chip[EM]: <<< [E:14107i M:151345122] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (110673) chip[IN]: (S) Sending msg 151345122 on secure session with LSID: 60740
I (110683) chip[DMG]: Refresh Subscribe Sync Timer with min 0 seconds and max 120 seconds
I (110683) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 1 **********
I (110693) chip[ZCL]: Event: move from 1
I (110703) chip[ZCL]:  to 4
I (110703) chip[ZCL]: (diff +1)
I (110713) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 4 **********
I (110723) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x000F is 0 **********
I (110733) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0003 is 0 **********
I (110743) chip[ZCL]: Setting on/off to 0x3c12fcb0 due to level change
I (110753) chip[ZCL]: On/Off set value: 1 1
I (110753) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x0000 is 1 **********
I (110763) chip[ZCL]: On/off already set to new value
I (110773) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0001 is 0 **********
I (110783) chip[EM]: >>> [E:61317r M:38411753 (Ack:151345120)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (110793) chip[EM]: >>> [E:61318r M:38411754 (Ack:151345121)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (110813) chip[EM]: >>> [E:14107i M:38411755 (Ack:151345122)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (110823) chip[IM]: Received status response, status is 0x00
I (110833) chip[EM]: <<< [E:14107i M:151345123 (Ack:38411755)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (110843) chip[IN]: (S) Sending msg 151345123 on secure session with LSID: 60740
I (110853) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0003 is 0 **********
I (110863) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 4 **********
I (110873) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0001 is 0 **********
I (110883) chip[EM]: <<< [E:14108i M:151345124] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (110893) chip[IN]: (S) Sending msg 151345124 on secure session with LSID: 60740
I (110903) chip[DMG]: Refresh Subscribe Sync Timer with min 0 seconds and max 120 seconds
I (110913) chip[EM]: >>> [E:14108i M:38411756 (Ack:151345124)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (110923) chip[IM]: Received status response, status is 0x00
I (110933) chip[EM]: <<< [E:14108i M:151345125 (Ack:38411756)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (110943) chip[IN]: (S) Sending msg 151345125 on secure session with LSID: 60740
I (110973) chip[EM]: >>> [E:61319r M:38411757] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:08 (IM:InvokeCommandRequest)
I (110973) esp_matter_command: Received command 0x0004 for enpoint 0x0001's cluster 0x00000008
I (110983) chip[ZCL]: 0x3c12fb40MOVE_TO_LEVEL_WITH_ON_OFF 91 null 0 0
I (110993) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 4 **********
I (111003) chip[ZCL]: Setting on/off to 0x3c12fcb0 due to level change
I (111003) chip[ZCL]: On/Off set value: 1 1
I (111013) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x0000 is 1 **********
I (111023) chip[ZCL]: On/off already set to new value
I (111033) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0xFFFC is 3 **********
I (111043) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4000 is 1 **********
I (111053) NimBLE: GAP procedure initiated: advertise;
I (111053) NimBLE: disc_mode=0
I (111063) NimBLE:  adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 adv_itvl_min=32 adv_itvl_max=32
I (111073) NimBLE:

I (111073) chip[EM]: <<< [E:61319r M:151345126 (Ack:38411757)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:09 (IM:InvokeCommandResponse)
I (111083) chip[IN]: (S) Sending msg 151345126 on secure session with LSID: 60740
E (111093) chip[DL]: Long dispatch time: 128 ms, for event type 3
I (111103) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x4000 is 1 **********
I (111113) chip[EM]: <<< [E:14109i M:151345127] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111123) chip[IN]: (S) Sending msg 151345127 on secure session with LSID: 60740
I (111133) chip[DMG]: Refresh Subscribe Sync Timer with min 0 seconds and max 120 seconds
I (111143) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 4 **********
I (111153) chip[ZCL]: Event: move from 4
I (111153) chip[ZCL]:  to 145
I (111163) chip[ZCL]: (diff +1)
I (111163) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 145 **********
I (111173) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x000F is 0 **********
I (111183) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0003 is 0 **********
I (111193) chip[ZCL]: Setting on/off to 0x3c12fcb0 due to level change
I (111203) chip[ZCL]: On/Off set value: 1 1
I (111213) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0006's Attribute 0x0000 is 1 **********
I (111223) chip[ZCL]: On/off already set to new value
I (111223) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0001 is 0 **********
I (111233) NimBLE: GAP procedure initiated: stop advertising.

I (111383) chip[EM]: >>> [E:61319r M:38411757] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:08 (IM:InvokeCommandRequest)
I (111393) chip[EM]: <<< [E:61319r M:151345128 (Ack:38411757)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (111403) chip[IN]: (S) Sending msg 151345128 on secure session with LSID: 60740
I (111413) chip[EM]: >>> [E:61319r M:38411758 (Ack:151345126)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (111423) chip[EM]: >>> [E:14109i M:38411759 (Ack:151345127)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111443) chip[IM]: Received status response, status is 0x00
I (111443) chip[EM]: <<< [E:14109i M:151345129 (Ack:38411759)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (111463) chip[IN]: (S) Sending msg 151345129 on secure session with LSID: 60740
I (111473) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0005's Attribute 0x0003 is 0 **********
I (111483) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 145 **********
I (111493) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0001 is 0 **********
I (111503) chip[EM]: <<< [E:14110i M:151345130] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0001:05 (IM:ReportData)
I (111513) chip[IN]: (S) Sending msg 151345130 on secure session with LSID: 60740
I (111523) chip[DMG]: Refresh Subscribe Sync Timer with min 0 seconds and max 120 seconds
I (111533) app_main: Free 61624
I (111533) chip[EM]: >>> [E:14110i M:38411760 (Ack:151345130)] (S) Msg RX from 1:0000000097985A03 [DC52] --- Type 0001:01 (IM:StatusResponse)
I (111543) chip[IM]: Received status response, status is 0x00
I (111553) chip[EM]: <<< [E:14110i M:151345131 (Ack:38411760)] (S) Msg TX to 1:0000000097985A03 [DC52] --- Type 0000:10 (SecureChannel:StandaloneAck)
I (111563) chip[IN]: (S) Sending msg 151345131 on secure session with LSID: 60740
I (112033) app_main: Free 63148
I (112533) app_main: Free 63148
I (113033) app_main: Free 63148
I (113533) app_main: Free 63128

Why this one, it read a single attribute...
I (112187) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x001D's Attribute 0xFFFC is 0 **********
E (112197) chip[DMG]: Error retrieving data from clusterId: 0x0000_001D, err = b

It is normal to encounter CHIP_ERROR_NO_MEMORY during chunked reads.
When commissioner performs a wildcard read,it reads all the attributes from all the clusters. Due to this the chunk allocated to read the data gets filled up and remaining attributes are read in the next chunk.
Here's the related discussion on the same issue in connectedhomeip repository https://github.com/project-chip/connectedhomeip/issues/24481


Deprecate Github CI; using Hydra instead

We'll loose our haddock integration :thinking:

Status badge on README.md needs to be removed as well.

Once it's good to go, we should edit CI requirement to check Hydra instead of GH Action.


Chosen key exchange mode shouldn't be part of SSL session structure

Background: Fundamentally, there are three different categories of data processed during a TLS connection:

Handshake-local data, which is only relevant for the duration of the handshake.
Context-local data, which is only relevant for the duration of a specific connection.
Session-local data, which is relevant for the entire duration of a session, across resumption.

Handshake-local data resides in mbedtls_ssl_handshake_params, context local data resides in mbedtls_ssl_context, and session-local data resides in mbedtls_ssl_session.
It's not always clear to decide where some piece of information belongs, but generally we should strive to find the place of shortest lifetime in the interest of saving RAM as well as conceptual clarity.
For pre-TLS 1.3, the SSL session contains the identifier for the ciphersuite, which for those versions encompasses both key exchange and bulk encryption mechanism. In TLS 1.3, those pieces of information are treated separately, and we need to decide where we put each of them.
Issue: It seems that the key exchange mode key_exchange_modes, key_exchange is actually only handshake-local, because it's neither needed after the handshake nor for session resumption, as far as I see. At the moment, however, the chosen key exchange method is stored in mbedtls_ssl_session.

merged .


ice/fire/poison jet timer

All the jets in dungeons are on a 20s timer: 10s off and then 10s on, starting at the creation of the instance. It should be supereasy to make a timer just like the Urgoz one... do you want the map IDs?

The ones in Nightfall are on a very similar timer, but it's not exactly the same so I'm not sure if it would just be misleading to include them.

fire jets:
Catacombs of Kathandrax level 1
Catacombs of Kathandrax level 3
Cathedral of Flames level 3
Bloodstone Caves level 1
Shards of Orr level 3
Oola's Lab level 2
Arachni's Haunt level 2
ice jets:
Sepulchre of Dragrimmar level 1
Raven's Point level 1
Raven's Point level 2
Heart of the Shiverpeaks level 1
poison jets:
Cathedral of Flames level 2
Bogroot Growths level 1
Bloodstone Caves level 3
Shards of Orr level 1
Shards of Orr level 2
fire spouts:
Shards of Orr level 3
Cathedral of Flames level 3
Heart of the Shiverpeaks level 3
ice spouts:
Darkrime Delves level 1
Secret Lair of the Snowmen
poison spouts:
Cathedral of Flames level 2
Bloodstone Caves level 2
Bloodstone Caves level 3

note: this is indeed quite easy, add another function like the urgoz timer here https://github.com/HasKha/GWToolboxpp/blob/master/GWToolbox/GWToolbox/Widgets/TimerWidget.cpp#L75


fix local time issue

I think its fix the bug.

For now, "Hamagen" is Israeli App , so you have a point, but I think one of the member need to give answer, because in the code they use UTC time, and not Israel time


Move JTAG TAP to swerv_wrapper

This enables a SoC that uses another physical interface than JTAG to access
the debug interface by instantiating swerv.sw instead of swerv_wrapper.sv
Existing users of swerv_wrapper.sv are not affected.

Updated for SweRV 1.2 release

This change is now part of the 1.3 release.


node: support following logs

This is the final step to fix #5
https://user-images.githubusercontent.com/1752631/105516932-57251b00-5cce-11eb-9b68-2efffb1e5623.mov

PRs with screen recording should be merged without review IMO

PRs with screen recording should be merged without review IMO

I can't tell if that's a rant or a praise :D
Since we have no tests, I just wanted to show the feature working, and also share my enthusiasm of getting it to work.

I can't tell if that's a rant or a praise :D
Since we have no tests, I just wanted to show the feature working, and also share my enthusiasm of getting it to work.

can't image testing this to be easy... maybe cut and paste kubelet tests?

can't image testing this to be easy... maybe cut and paste kubelet tests?


Install/remove package after adding or removing a line in package.json

Visual studio code adds IntelliSense to package.json, that's great feature but is the package automatically installed after I add a line or removed after I remove a line? Also will it update if I change a version of some package?

I believe this falls under #2590
Closing as a duplicate


Incompatibility with Rails 5

It is not possible to install rancher-api in a Rails 5 project, as it depends on her, which depends on activemodel 4 (see below). Also, I checked her and it seems like the project is dead (no activity for almost an year).
    rails (~> 5.0.0) was resolved to 5.0.0, which depends on
      activerecord (= 5.0.0) was resolved to 5.0.0, which depends on
        activemodel (= 5.0.0)

    rancher-api (~> 0.3) was resolved to 0.3.0, which depends on
      her (~> 0.7.6) was resolved to 0.7.6, which depends on
        activemodel (<= 4.3.0, >= 3.0.0)

Is this something you plan to support? I'm willing to collaborate.

If there's an alternative to her, or some nice API wrapper so that we don't need to write all the boilerplate, I'm happy to switch from her.
Alex
Sent from my iPhone

On Jul 7, 2016, at 20:16, Henrique Zambon<EMAIL_ADDRESS>wrote:
It is not possible to install rancher-api in a Rails 5 project, as it depends on her, which depends on activemodel 4 (see below). Also, I checked her and it seems like the project is dead (no activity for almost an year).
rails (~> 5.0.0) was resolved to 5.0.0, which depends on
  activerecord (= 5.0.0) was resolved to 5.0.0, which depends on
    activemodel (= 5.0.0)

rancher-api (~> 0.3) was resolved to 0.3.0, which depends on
  her (~> 0.7.6) was resolved to 0.7.6, which depends on
    activemodel (<= 4.3.0, >= 3.0.0)

Is this something you plan to support? I'm willing to collaborate.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Or we could use one of the forks of her which support rails 5

It's an option... I'm not the biggest fan of using dead projects though. 😛

Looks like Her got rails support in version 0.8.2


⚠ Bofrost.de has degraded performance

In 62d812f, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 2493 ms

Resolved: Bofrost.de performance has improved in f9bdb90 after 6 minutes.


sdk: add request hook to fix API path

Due to a limitation in OpenAPI, we cannot use the generated client as-is to evaluate rules: path: "foo/bar" would end up as POST /v1/data/foo%2fbar, which OPA doesn't understand. This hook fixes the request path accordingly.
Should you want to query data.foo["a/b"], the same approach still works -- path: "foo/a%2fb" would end up encoded twice, and the one decode in the hook causes the right request to be sent to OPA, POST /v1/data/foo/a%2fb.

is it possible to scope this hook to only run for specific API calls? Does it make a difference?

is it possible to scope this hook to only run for specific API calls? Does it make a difference?

Right now, it wouldn't, I think. But it won't hurt! Updated.

:memo: I've also tested that it works fine when passing query parameters like explain=full and metrics=true. ✔


Fix/catalog saver defaults

Adjustments and some refactoring to allow CatalogSaver to better handle default and initial values for the modal dialog fields.
This ensures the defaults adapt properly to user-defined names given in the Editor, who is the parent of the modal.

Fix looks good.  Can you squash the commits and force push?  In this case that part of history is unhelpful.

(I will merge as soon as that is done.)


Seen.txt and updated.txt are empty

I am trying to setup yahoo streaming benchmark for one of my assignments. I was able to run the benchmark suite and see results on console. I was expecting results in seen.txt and updated.txt in data dir but as mentioned in the README of project. In my case those files are always empty. I might have made a mistake in setup but can you guys help to resolve it and get the results in updated.txt/seen.txt.
I even to tried to run https://github.com/dataArtisans/yahoo-streaming-benchmark but here as well files were empty after execution.

This seems to indicate that data did not show up in redis like expected, of the tool could not find redis to get the data from.  How are you trying to run the benchmark?

I have downloaded zip version of benchmark from github and copied it on CentOS server. I am trying to run benchmark as,
./stream-bench.sh SPARK_TEST

That is odd.  I'll try to reproduce it and see what I can come up with.

Could you reproduce it?

I was able to reproduce it, but only after making a bunch of changes to the script to have it download the correct things.  (Spark and Flink both removed packages)  also it seems to only be happening for spark.  From what I can tell spark is not writing anything into redis at all, so the files are actually accurate.  I will have to do some more digging to see what might be happening.

OK I saw the issue with flink too, but storm seems OK.  This is really odd, but because we had to get newer versions of both spark and flink to get a release that is available for download there might be something there.  More likely it is something with scala 2.11 which I also had to upgrade, but I will try and look at them.

Thanks for the updates. Please suggest/share if you have a solution for this issue.

Could you identify the root cause for the issue and solution?.
My team is planning to run benchmarks against spark and because of that I need a solution for this issue.

I have not been able to identify it yet, but I honestly have not tried that hard and have a lot of other priorities right now.  I hopefully will find some time to dig in tomorrow.

Is there any idea? I've got the same issue

I have the same issue when running Flink tests only!

For flink looks like the issue happens because of requested operator parallelism. Setting parallelism to default (1), it works


Feature/Bug/Improvement: Recoverable should validate the reset_password_token

reset_password_tokens should be valid - when trying to reset a password with an invalid password token there should pop an validation error saying "invalid reset_password_token" or something.

A simple way to have just one step for users to confirm email address and set initial password using the link you proposed...
Send one email your app generates, including a reset_password_token, and consider user's possession of that token confirmation of the validity of that email address.
In system account generation code, assuming User model is set up with :recoverable and :database_authenticatable Devise modules...
acct=User.new
acct.password=User.reset_password_token #won't actually be used...
acct.reset_password_token= User.reset_password_token
<EMAIL_ADDRESS>#assuming users will identify themselves with this field
#set other acct fields you may need
acct.save
Make the devise reset password view a little clearer for users when setting initial password. In YourApp/views/devise/passwords/edit.html.erb ...
...
<%= "true"==params[:initial] ? "Set your password" : "Reset your password" %>
...
In the email view your code generates ...
Hi<EMAIL_ADDRESS>An account has been generated for you.
Please visit www.oursite.com/users/password/edit?initial=true&reset_password_token=<%= @user.reset_password_token %> to set your password.
More custom details to communicate...
No need to include :confirmable Devise module in your User model, since accounts created by your app won't get accessed without the reset_password_token in the email.
Devise will handle the submit and clear the reset_password_token field.
See devise_gem_folder/lib/devise/models/recoverable.rb and database_authenticatable.rb for details on reset_password_token method and friends.
If you want to use Devise :confirmable module rather than this approach, here's a Devise wiki page that might help: https://github.com/plataformatec/devise/wiki/How-To:-Override-confirmations-so-users-can-pick-their-own-passwords-as-part-of-confirmation-activation

A simple way to have just one step for users to confirm email address and set initial password using the link you proposed...
Send one email your app generates, including a reset_password_token, and consider user's possession of that token confirmation of the validity of that email address.
In system account generation code, assuming User model is set up with :recoverable and :database_authenticatable Devise modules...
acct=User.new
acct.password=User.reset_password_token #won't actually be used...
acct.reset_password_token= User.reset_password_token
<EMAIL_ADDRESS>#assuming users will identify themselves with this field
#set other acct fields you may need
acct.save
Make the devise reset password view a little clearer for users when setting initial password. In YourApp/views/devise/passwords/edit.html.erb ...
...
<%= "true"==params[:initial] ? "Set your password" : "Reset your password" %>
...
In the email view your code generates ...
Hi<EMAIL_ADDRESS>An account has been generated for you.
Please visit www.oursite.com/users/password/edit?initial=true&reset_password_token=<%= @user.reset_password_token %> to set your password.
More custom details to communicate...
No need to include :confirmable Devise module in your User model, since accounts created by your app won't get accessed without the reset_password_token in the email.
Devise will handle the submit and clear the reset_password_token field.
See devise_gem_folder/lib/devise/models/recoverable.rb and database_authenticatable.rb for details on reset_password_token method and friends.
If you want to use Devise :confirmable module rather than this approach, here's a Devise wiki page that might help: https://github.com/plataformatec/devise/wiki/How-To:-Override-confirmations-so-users-can-pick-their-own-passwords-as-part-of-confirmation-activation


Feature Proposal: Support Nested NodeGraphs

MaterialX Nested Nodegraphs
This document outlines the proposal to support a <nodegraph> which a child of another <nodegraph>. As there are no syntax changes, the proposal is for a 1.38.x incremental release.
Authors
Niklas Harrysson, Bernard Kwok, Jonathan Stone
Motivation
Currently compound nodegraphs can be specified at the document level. The extension to this is to allow nesting at any level in a graph hierarchy.
This allows for packaging of sub-parts of a graph into logical units for better organization and readability. When a graph becomes large it becomes convenient to have the ability to wrap parts of it into compounds where it make sense.
For example, in the nodegraph for standard_surface there are several parts of the graph that can be separated into child compounds that calculate a particular piece of logic such as:

Tangent rotations
How coat affect roughness
How coat effect diffuse and sss colors
How fresnel effects the EDF

Even the logical layering of BSDFs can probably have been separated out into compounds for better readability in a graph editor.
As an artist this becomes a useful tool in the toolbox for organizing graphs.
In addition, when such a compound is found to be reusable it can be published as a new definition (nodedef) with a functional nodegraph allowing it to be instantiated and reused. Without the ability to create child compounds an artist currently has to first move the graph up to the document level, then recreate the logic there, and then perform the "publish" to a nodedef.
Another motivation is that a user is presented with the ability to
construct nested nodegraphs in the Graph Editor, but cannot save the result to a document.
Syntax Changes
None
Connection Logic Changes
Connection handling becomes more consistent between nodes and nodegraphs by
generalizing connections. This is achieved by removing the restriction that some things you can do on nodes are not allowed on nodegraphs. Namely:

interfacename can be specified on nodegraph <input>s to allow connections between inputs on a child nodegraph and a parent nodegraph.

Possible Configurations
Given a parent <nodegraph> called parentNG and a child nodegraph childNG, and child nodes childNodeUp and childNodeDown:

The <input> on childNG is connected to the output of an upstream node childNodeUp
<input ... node="childNodeUp"> [output="output on childNodeUp"]>

 graph TB;
 subgraph parentNG
     childNodeUp
     childNG
 end
 subgraph childNG
   input([input])
 end
 childNodeUp --> input
 style input fill:#0bb, color:#111

The output is specified if childNodeUp has multiple outputs.
If the upstream node was a nodegraph then syntax would be nodegraph=
instead of node=. (See *)

The <output> on childNG is connected to the input of a downstream node childNodeDown
<input ... nodegraph="childNG"> [output="output on childNG"]>

 graph TB;
 subgraph parentNG
     childNodeDown
     childNG
 end
 subgraph childNG
   output([output])
 end
 output --> childNodeDown
 style output fill:#0b0, color:#111

The output is specified if childNG has multiple outputs.

The <input> on childNG is connected to the interface <input> called parentNGInput of the parent nodegraph parentNG
<input ... interfacename="parentNGInput"`>

 graph TB;
 subgraph parentNG
     parentNGInput([parentNGInput])
     childNG
 end
 subgraph childNG
   input([input])
 end
 parentNGInput  --interfacename--> input
 style input fill:#0bb, color:#111
 style parentNGInput fill:#0bb, color:#111

The <output> on childNG is connected to the <output> of the parent nodegraph parentNG
<output ... nodegraph="childNG" [output="output on childNG"]>

 graph TB;
 subgraph parentNG
     outputparentNG([output])
     childNG
 end
 subgraph childNG
   output([output])
 end
 output  --> outputparentNG
 style output fill:#0b0, color:#111
 style outputparentNG fill:#0b0, color:#111

with the output being specified if childNG has multiple outputs.

(*) Note that <nodegraph> to <nodegraph> connections are already supported so is similar to the node to nodegraph connection scenario.
Interface Example
Example shows interfaces being connected between parent and child nodegraphs
<?xml version="1.0"?>
<materialx version="1.38" colorspace="lin_rec709">
  <nodegraph name="parentNG">
    <input name="parentNGInput" type="color3" value="1, 1, 0.2"  />
    <input name="parentNGInput2" type="color3" value="0.2, 1, 1" />
    <nodegraph name="childNG">
      <input name="childNGInput" type="color3" interfacename="parentNGInput" />
      <input name="childNGInput2" type="color3" interfacename="parentNGInput2" />
      <multiply name="multiplyNode" type="color3">
        <input name="in1" type="color3" interfacename="childNGInput" />
        <input name="in2" type="color3" interfacename="childNGInput2" />
      </multiply>
      <output name="childNGOutput" type="color3" nodename="multiplyNode" />
    </nodegraph>
    <output name="parentNGOutput" type="color3" nodegraph="childNG" />
  </nodegraph>
</materialx>

graph TD;
    top_shader[top_shader]
    parentNG_childNG_multiplyNode[multiplyNode] --> childNGOutput
    parentNG_childNG_childNGInputINT([childNGInput]) ==.in1==> parentNG_childNG_multiplyNode[multiplyNode]
    style parentNG_childNG_childNGInputINT fill:#0bb, color:#111
    parentNG_childNG_childNGInput2INT([childNGInput2]) ==.in2==> parentNG_childNG_multiplyNode[multiplyNode]
    style parentNG_childNG_childNGInput2INT fill:#0bb, color:#111
    parentNGOutput --".base_color"--> top_shader[top_shader]

  subgraph parentNG
    parentNG_childNG
    parentNG_parentInput([parentInput])
    parentNG_parentInput2([parentInput2])
    style parentNG_parentInput2 fill:#0bb, color:#111
    style parentNG_parentInput fill:#0bb, color:#111
    parentNGOutput([parentNGOutput])
    style parentNGOutput fill:#0b0, color:#111
   end
  subgraph parentNG_childNG[childNG]
    parentNG_childNG_childNGInput2INT
    parentNG_childNG_childNGInputINT
    parentNG_childNG_multiplyNode
    childNGOutput([childNGOutput]) --> parentNGOutput
    style childNGOutput fill:#0b0, color:#111
  end

    parentNG_parentInput([parentInput]) --> parentNG_childNG_childNGInputINT
    parentNG_parentInput2([parentInput2]) --> parentNG_childNG_childNGInput2INT

The resulting rendering in MaterialXView would look something like this,
where the parent nodegraph inputs (parentNGInput, parentNGInput2) are exposed as input uniforms via shader code generation.

Implementation Requirements

Graph traversal logic, shader generation, and value evaluation handles interfacename on nodegraph inputs, and traversal from a parent nodegraph output to a child nodegraph output
"Inherited" properties (such as fileprefix, colorspace) evaluate properly through parent/child nodegraphs. This should already be the case.
No "upgrade" path is required.

Based on this Slack thread, for interop this would allow for future support so that USD (hdMtlx) would no longer need to pre-flatten it's graphs for conversion to MaterialX. The flip side would be that conversion to USD could support nested graphs, with a possible utility pre-flatten within MaterialX.
This is implied that only connections within the current scope are allowed as re-confirmed by Doug Smythe.

See [this Slack thread  additional discussion.

Looks really good to me!
Just some thoughts on the connection:
<input ... nodegraph="childNG"> [output="output on childNG"]>

It's logical to use nodegraph= to specify the "childNG" as input, since node graphs are not quite nodes (shaders) in MaterialX. Though in DCC, node graphs can be thought as a node with children inside, so there it may be permissible to also think of the connection as node="childNG".
I think we should indeed use nodegraph="childNG" for MaterialX. I just wanted to mention it, in case there are some other implications (eg, on scripting, etc).

Hi @rafalSFX ,
Indeed, If we treat a nodegraph as something you can encapsulate as a node we'd only need node connection concept.
The notation of using nodegraph= and node= is historical, (as is interfacename=), so just following what's there now.
We had a proposal to generalize syntax to use 'connect='  (which would also align better with USD) but this pulled in too many other elements at one time.  The thought is to perhaps revive this as a separate proposal as a syntactic change and / or an API generalization. (e.g. a getConnection/setConnection() API).