Implement a CLI

There's been some work done: see the core.clj file in the master branch.
If the chosen approach/library is suboptimal, feel free to do it differently altogether.

Let's get one situation working well, before we define the entire possible CLI schema.
For step zero, make sure you have cli-matic (CLI library) installed (lein deps) and that stuff works:
$ lein run

This gives you the global help text (ignore the error because you didn't pass in required args of course). Note that -? and --help don't work at this level with Leiningen, since it thinks you're asking help for its run command. So the way shown above is how you get the help text to show.
Then, for the first step, let's get this to work:
$ metamorph --profile <PROFILE_DIR> avro --output <OUTPUT_FILE>
# must do a full avro run

Little explanation on forehand: inputting a profile will work the same no matter what target schema we desire, so --profile can be a global option. But the output can differ depending on the schema (different options, dir/file, ...). That's why --output is a option of the command avro, and not a global option. This way we stay flexible.
Anyways, this will be the meatiest part. The core.-main function is called with the CLI args, so you start there. There cli-matic is ran with the defined cli-conf map covering the definition of the CLI params/commands/args. There might be some global options I defined that we don't use yet (manifest files and all). Just ignore that for now. Also ignore spec keys for now.
Notice :runs transform-schema, so that function will be your entry point. That's where you can write the logic for how to call everything.
Note for later: In the library documentation you'll see that you can provide runs per (sub)command, so we might not need to write our own switch over avro/sql etc.
Third step: add the --format option for avro, allowing json, binary and edn to be chosen (see code). EDN is Clojure's native JSON-like serialization, this is useful sometimes for developers. Lancaster supports outputting all of these, but currently a CLI placeholder is enough. It should just work for JSON now.


Verify output matches schema

Create an automated test to be sure the output JSON matches the schema
segment-context-schema.

It looks like there is a docker container that contains the dcmqi tools:
https://hub.docker.com/r/qiicr/dcmqi


Premerge databricks CI autotrigger [skip ci]

fix https://github.com/NVIDIA/spark-rapids/issues/5049 https://github.com/NVIDIA/spark-rapids/issues/4920
verified in forked repo. This change will take effect after merge

build


Inaccurate Google search results description

When searching on Google for OpenCue, the results currently include the following description for the opencue.io site:

Your browser does not currently recognize any of the video formats available. Click here to visit our frequently asked questions about HTML5 video.

I think this is a result of recently adding the ASWF sizzle reel from YouTube, so we need to experiment with adjusting the landing page to provide a better description for the site.
This issues seems confined to Google search and I couldn't replicate it using other search engines.

Google search results now correctly display the meta description for the site. The site is now ranked second in the list of results for the term 'OpenCue'.


Questions on Ground Truth Optical Flow Computation and Interpolation in the DSEC Dataset

Hello author,
First of all, thank you for providing such an amazing dataset.
Since my English skills may not be perfect, I apologize if my questions aren’t fully clear, but I’ll do my best.
I have a few general questions about the optical flow in the DSEC dataset. If any of this information is already publicly available, I apologize in advance:

How are valid pixels (valid status = 1) and non-valid pixels (valid status = 0) defined? From what I can tell, it doesn’t seem to be directly related to pixels where events occur.

How is the optical flow computed? For instance, is an optical flow algorithm applied to an accumulated event frame?

If I need the optical flow between two arbitrary timestamps, would simple bilinear interpolation yield a reasonable approximation?
For example, if the dataset provides the optical flow between timestamps<PHONE_NUMBER>0,<PHONE_NUMBER>0), and I want the flow between<PHONE_NUMBER>0,<PHONE_NUMBER>0), would scaling the flow vector by 0.5 yield a good approximation?

Usami

Hi @usamic

This is described here: https://dsec.ifi.uzh.ch/data-format/

If you want the details, I suggest having a look at the paper. Essentially, we use LIdar + IMU odometry for locally accurate ego-motion estimation. Then from the depth values we from the Lidar we can compute the scene flow for static parts of the scene which is used to compute depth and optical flow.

It's an approximation but not very accurate. Nowadays, you could actually create your own optical flow ground truth at higher rate using a SOTA non-causal point tracker on the frames at 20 Hz. If you then need intermediate flow approximations you could approximate the flow with cubic splines.

Thank you, @magehrig , for your clear and detailed answers to all of my questions. I appreciate your efforts in addressing my concerns comprehensively. I also apologize for inadvertently including information that has already been made public in my queries.
I have now understood everything perfectly and am truly grateful for the outstanding dataset that you’ve shared.


Use 3rd party priority queues

It may be better not to reimplement priority queues and use existing one instead like:
https://hackage.haskell.org/package/psqueues

Yeah, I agree. I'll move to that library (or an equivalent) shortly.


Sync eng/common directory with azure-sdk-tools for PR 8516

Sync eng/common directory with azure-sdk-tools for PR https://github.com/Azure/azure-sdk-tools/pull/8516  See eng/common workflow

Skipping because failing - tests pipelines are listed in the checks.

/check-enforcer override


java-service-wrapper: init at 3.5.41

Motivation for this change
Provide java service wrapper for the i2p package (see https://github.com/NixOS/nixpkgs/pull/67641).
I don't know in which category I should put it, so I put it in misc.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

Done.


Update bindings

When you do a new 0.6 release you probably want to require 4.10 instead of 4.9 in the Cargo.tomls for v4_10.

When you do a new 0.6 release you probably want to require 4.10 instead of 4.9 in the Cargo.tomls for v4_10.

I completely forgot about that, done


Release 9.3 does not have back-port of fix for CUDA enhanced compatibility

PR #5097 was not backported to v9 so it was not included in release 9.3.
cc @rlratzel @pentschev

Conditions (you can just paste the output of python -c 'import cupy; cupy.show_config()')

CuPy version: 9.3
OS/Platform: Ubuntu 20.04
CUDA version: 11.4

Code to reproduce

Create a CuPy array with CuPy for CUDA 11.4, with driver < 470.

Error messages, stack traces, or logs

With driver < 470:
(base) ➜  ~ nvidia-smi
Wed Aug  4 13:24:56 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.32.03    Driver Version: 460.32.03    CUDA Version: 11.2     |
|-------------------------------+----------------------+----------------------+
...
(rapids) root@71740761bae2:/workspace/cuml/python
Python 3.8.10 | packaged by conda-forge | (default, May 11 2021, 07:01:05)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cupy as cp
>>> cp.ones(10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/conda/envs/rapids/lib/python3.8/site-packages/cupy/_creation/basic.py", line 154, in ones
    a.fill(1)
  File "cupy/_core/core.pyx", line 570, in cupy._core.core.ndarray.fill
...
  File "cupy_backends/cuda/api/driver.pyx", line 125, in cupy_backends.cuda.api.driver.check_status
cupy_backends.cuda.api.driver.CUDADriverError: CUDA_ERROR_UNSUPPORTED_PTX_VERSION: the provided PTX was compiled with an unsupported toolchain.
>>>

Sorry about this, we just backported it and it will be available in the next release, scheduled by the end of August.

Backported in v9.4. #5611 Thanks again for reporting!


Transparent navbar menu in mobile format

From @anaqreon on February 8, 2015 20:20
When logged out, the dropdown menu items are on top of a transparent background, making items difficult to see and tap. It seems to fix the problem to add a stylesheet item like this:
.navbar-collapse {
	background-color: #111111;
}

but I'm not sure where it is appropriate to put this in the CSS files, because I believe it derives from Bootstrap directly.
Copied from original issue: friendica/red#891

From @friendica on February 8, 2015 22:52
Oh but you're using your original landing page which messes with z-index if I recall.

From @anaqreon on February 8, 2015 22:13
I'm pretty sure it was only on the home landing page. Perhaps my workaround should be included in some form?

From @git-marijus on February 8, 2015 20:48
this usually happens with bootstrap if the panel is forced to have a specific height... did you see this on a "normal" login page or a home landing page?

From @anaqreon on February 9, 2015 1:0
To verify, I copied the /assets folder from commit https://github.com/friendica/red/commit/712bc643b5f26315602f34e9d9822ef83cb6b65a and I still get the behavior. Here is a screenshot:

From @git-marijus on February 9, 2015 5:54
I'll have a look at it today...

From @git-marijus on February 9, 2015 7:38
fixed in b31a2f109fc08d8440d3c9d8fabe221ee93527bb

From @friendica on February 9, 2015 1:51
I can duplicate but I can't figure out what's causing it.
util/config system projecthome 1
turns the project home page on
util/config system projecthome 0
turns it off.
When it's on and the small device navbar kicks in, it is indeed transparent. Turn off projecthome and it fixes itself. The background color seems to be set by navbar-inverse which is color 222 with a gradient applied. I can't see what's different in the css when the projecthome is swapped in and out, but the collapsed menu seems to lose inheritance to its background color. Note that assets/home.html does mess with z-index of the nav and header, which was done originally because there were some issues with the navbar display when the project homepage was first added. But I've tried commenting them out and see no change. At the moment I can't figure out what the culprit is.


Add initial Cluster support

Add cluster support to svd2rust. I am calling it initial, because I have only tested it against the nRF52 svd file.
Note, this is based on https://github.com/japaric/svd2rust/pull/180, so I would prefer that PR be merged first. If that PR is rejected, I can instead rebase these changes on japaric/master (just let me know).

This is based on the work of @brandonedens earlier https://github.com/japaric/svd2rust/pull/149, and I believe would close https://github.com/japaric/svd2rust/issues/107 and related issues.
CC @japaric @emilgardis @therealprof
Edit 2: Here are some handy references:

SVD snippet with clusters
code generated before
code generated after
diff of code generated

I have also now tested this against ATSAMD21E15A.svd, and that has revealed that there are some additional problems that need to be fixed. One of these issues is fixed in d275d6f.
Another problem is that the ATSAMD svd has clusters with repeating names. This is currently not handled by my changes. See this snippet:
       <cluster>
        <name>USART</name>
        <description>USART Mode</description>
        <alternateCluster>I2CM</alternateCluster>
        <headerStructName>SercomUsart</headerStructName>
        <addressOffset>0x0</addressOffset>
        <register>
          <name>BAUD</name>
          <description>USART Baud Rate</description>
          <alternateGroup>DEFAULT_MODE</alternateGroup>
          <addressOffset>0x0C</addressOffset>
          <size>16</size>
          <fields>
            <field>
              <name>BAUD</name>
              <description>Baud Rate Value</description>
              <bitOffset>0</bitOffset>
              <bitWidth>16</bitWidth>
            </field>
          </fields>
        </register>
        <register>
          <name>BAUD</name>
          <description>USART Baud Rate</description>
          <alternateGroup>FRAC_MODE</alternateGroup>
          <addressOffset>0x0C</addressOffset>
          <size>16</size>
          <fields>
            <field>
              <name>BAUD</name>
              <description>Baud Rate Value</description>
              <bitOffset>0</bitOffset>
              <bitWidth>13</bitWidth>
            </field>
            <field>
              <name>FP</name>
              <description>Fractional Part</description>
              <bitOffset>13</bitOffset>
              <bitWidth>3</bitWidth>
            </field>
          </fields>
        </register>
        <register>

@Emilgardis - apologies for basing this on my "refactoring" branch. It took me a while to understand what components had to do with which parts of the generation process, and the refactoring branch was me organizing things based on my learning while trying to tackle the cluster feature. As previously mentioned, I would be happy to rebase this on top of master (but I am hoping the other PR is merged).
Additionally I agree that I need to improve the situation with comments. I will plan to add those in the near future.

I think https://github.com/japaric/svd2rust/pull/182#issuecomment-368916284 is not technically a blocker to merging this, though clusters that contain multiple registers at the same offset (like ATSAMD21E15A.svd shown above) will not (yet) be able to take advantage of the cluster support, until there is support for union'd types (I think covered by issue #16).

Don't worry about the FUBAR ATSAMD too much, that'll only make your life miserable but doesn't bring any benefit to the cause. The chat I had with a Microchip guy yesterday at the Embedded World was very revealing, too.

Hey, quick status update on this:

Currently register offsets inside of clusters are not being calculated correctly
I have a very ugly brute force fix for it, and I am working on cleaning it up a bit
My laptop fan just died, so I need to get that fixed before I can do any serious compilation or testing, so I expect a delay of a day or two.

I just wanted to follow up in case anyone other than me was trying to use this branch :). If you want to try out my ugly fixes, I can push those to another branch on my fork, just @ me.

@jamesmunns I just tried a few SVD and it seems to work great. No regressions with simple ones and nrf51 gets a few more components by using this.
Few nits:

I'm getting lint errors due to gratuitous use of use vcell::VolatileCell; where not needed.
The formatting after rustfmt is slightly different, even worse than it was before, e.g. docstrings right after opening braces: pub enum SRCR {#  [ doc = "Internal 32KiHz ...

@therealprof Be careful with the current branch. In the generated output, the #[doc = ""] comments have the correct offsets, but extra _reservedxx fields are being generated if your clusters do not have an explicit <size> field. You can verify this in GDB by looking at the addresses of the fields.
Regarding formatting, yeah, its pretty rough. I wonder what we are doing that makes cargo fmt upset. Probably worth an improvement issue.
Regarding VolatileCell, I can probably take that out of the generated code, and we can just use vcell::VolatileCell; once at the top of the file (in fact, I think we already do).

@jamesmunns I've just done some basic regression testing and worked for my curiosity (since you mentioned you require that for the nrf52 I was curious to see whether the nrf51 also has some additional hidden components -- yes it does!). No concrete use case at the moment.

@therealprof I don't expect this to break anything that already worked before, but the "new stuff" (e.g. the peripherals/registers that were cluster based) I would expect not to work in some cases.
Were you testing the new peripherals? Or your existing nrf51-hal code?

No, just checking that a swapped out version would compile. I haven't even noticed that (albeit very few) peripherals were missing so obviously I didn't those so far.

Fixed size rendering (as far as I can tell).
bors r+

Looks like this failed due to the excess "VolatileCell" mentioned above: https://travis-ci.org/japaric/svd2rust/jobs/349051903 - I'll try and find a clever fix, otherwise I'll hit it with an #[allow(unused)].

bors r+

@japaric I'm a little confused - CI passed but Bors timed out? Is this okay to merge?

Merging as tests have passed.

@jamesmunns I increased the timeout to 2 hours the other day. If it still takes longer than that to run the tests feel free to increase it.

@therealprof:

Don't worry about the FUBAR ATSAMD too much, that'll only make your life miserable but doesn't bring any benefit to the cause. The chat I had with a Microchip guy yesterday at the Embedded World was very revealing, too.

Care to share the details? Also, I'd be curious to know whether you consider previously-Atmel chips FUBAR or just the SVDs. Thing is, I have an ATSAMD21 board that I'd like to bring up and play with the peripherals and the register cluster issue has been blocking, as far as I understand.

@istankovic For whatever reason the engineers at (formerly) Atmel decided that it would be a great idea to have lots of totally asynchronously running clocks driving the individual peripherals. While (in theory) this yields a ton of freedom tweaking all the clocks to run at just the perfect speed for the job, it actually means that you can never be sure that data arrives at the right place at the right time due to clock drift so whenever you have peripherals working in lockstep (as one pretty much always does) you have to sprinkle costly busy wait loops all over the map in your peripheral access code. Not to mention that getting the clocks set up in the first place is a major PITA and can easily drive one mad because the chips will simply lock up somewhere in the initialisation code and you've no idea why... That combined with the fact that the documentation is in large portions conflicting, incorrect or even absent and Atmel seems to consider examples to be for wussies only is a bit of a buzzkill.
I was asking the Microchip guy at the Embedded World for new advancements in the BLE/802.15.4 area to which he frankly replied that they somewhat underestimated the demand for that so they're still playing catchup in their design teams. And when I nudged him a bit about my experience with the ATSAM chips and the crazy clocks he just nodded and said that this probably wasn't the brightest hour of the engineering team.
The SVDs are just another sad part of the story...
Wez Furlong is working on ATSAMD21 support and if you want to look at something "working" (although definitely not pretty) you might want to have a look at my https://github.com/therealprof/atsamd20e15a which implements something "shiny" for the lowlier but otherwise mostly compatible brother.

@therealprof thanks for the elaboration. Yes, regarding the Atmel parts, clock configuration can sometimes really be painful and I spent many hours debugging non-functioning peripherals. However, I'd say that once one gets used to it, it isn't such a big deal and it has its advantages (lower power, speed optimization etc.) Regarding the documentation, I'm not sure about the current state, but back when I was actively working with Atmel parts, AVRs upto Cortex-Ms, I considered Atmel docs to be one of the better in the industry, honestly. One could actually build a system solely by following a datasheet and perhaps consulting a few app notes, without needing to spend a great deal of time searching the net for answers/advice. Maybe that changed.
Thanks for the pointer, I'll check out your repo.

@istankovic

it isn't such a big deal and it has its advantages (lower power, speed optimization etc.)

That's what they claim, I haven't seen that in real life though.

Atmel parts, AVRs upto Cortex-Ms, I considered Atmel docs to be one of the better in the industry, honestly.

The AVR documentation is indeed really good; I've worked a lot with ATTiny, ATMega and AT90 in the past and those are well documented in stark contrast to the ATSAMD parts; haven't bothered checking other ATSAM parts though.


Conjugate connections to oligo structures doesn’t prompt for particular R groups

I cannot reproduce this one with 2016-10-11 version.

I cannot reproduce it.  Could you have a screenshot here?

I can't reproduce either - sent to Jeff and Eric to confirm.

Seems to be fixed. Close.


Enum mapping doesn't being recognized when used in a query

Describe the bug
When defining in .eslintrc.js file under overrides.types a mapping of an enum, safeql doesn't recognize it when the enum is used in a query (and not as a type).
The .eslintrc.js file:

The error:

To Reproduce
Use a enum as a parameter of a query
Expected behavior
No error should appear
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: iOS
PostgreSQL version: 15
Version: 0.1.0

It seems like I didn't take into consideration enums. I'll push a fix today or in a few days


⚠ Bofrost.lu has degraded performance

In 27d2247, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1599 ms

Resolved: Bofrost.lu performance has improved in 3ec3556 after 20 minutes.


[Fix] LibreOffice does not support multi-threading

I wonder if we might investigate another tool?
http://documents4j.com/#/
https://angelozerr.wordpress.com/2012/12/06/how-to-convert-docxodt-to-pdfhtml-with-java/
alternatively a pool of isolated Open Office instances in Docker containers as a temporary workaround

@hkkenneth could we update the docs to show using this for scaling the pipeline for Patient Timeline  although I wonder if this should be treated using the modular mechanism suggested in #17

You mean pull this logic out as a plugin? Yes that seems to be a cleaner solution. There was a bit of "history" behind this current implementation... the PDF / thumbnail generation feature was written before I had the "plugin" idea. So this feature went straight into master even though no other projects need it at the moment.
I am a bit hesitate to write this in the doc as "standard feature" yet because I have never confirmed our SLaM jobs really ran stably in a reasonable "multi-threading" scenario (e.g. 8 threads or more).
Some more testing in the new dev VM would be helpful.

On 13 May 2017 at 00:37, Kenneth Lui<EMAIL_ADDRESS>wrote:

I am a bit hesitate to write this in the doc as "standard feature" yet
because I have never confirmed our SLaM jobs really ran stably in a
reasonable "multi-threading" scenario (e.g. 8 threads or more).
Some more testing in the new dev VM would be helpful.

>> ok sure...  I'll see if the dev env is cleared to be used again. Would
be good to test.

--

Amos Folarin

This issue was moved to CogStack/cogstack#22


[K32W] Failure during the BLE Rendezvous session

SPAKE2+ session is successful. Then the commissioner sends a CSR Request to the DUT, it looks like the DUT replies with a CSR Request Response but the chip-device-ctrl looks to timeout the message.
Head is at
commit f6af7b9c9d86174f2e894d54e90dbf9cef250ad0 (upstream/master, upstream/master)
Author: Song Guo<EMAIL_ADDRESS>Date:   Wed Jun 2 13:15:21 2021 +0800

[python] Add flag to disable BLE for controller (#7179)

I checked with other vendors and everything is ok on their side. I expect that there is a problem on the DUT side. Any help on how to debug this would be appreciated.
Logs on the device side:
[Info]Welcome to NXP ELock Demo App
[Info]OpenThread started: OK
[Info]Setting OpenThread device type to SLEEPY END DEVICE
[Info]OpenThread polling interval set to 1000ms
[Info]Using ZAP configuration...
[Info]deactivate report event
[Info]OpCreds: Initiating OpCreds cluster by writing fabrics list from admin pairing table.
[Info]Set the admin pairing table delegate
[Info]OpCreds: Call to writeAdminsIntoFabricsListAttribute
[Info]OpCreds: Stored 0 admins in fabrics list attribute.
[Info]Unknown cluster ID: 40
[Info]Unknown cluster ID: 40
[Info]Unknown cluster ID: 40
[Info]Unknown cluster ID: 40
[Info]Unknown cluster ID: 40
[Info]Unknown cluster ID: 40
[Info]Unknown cluster ID: 40
[Info]Unknown cluster ID: 40
[Info]Unknown cluster ID: 40
[Info]Init admin pairing table with server storage
[Info]TransportMgr initialized
[Info]local node id is 0x0000000000BC5C01
[Info]Start dns-sd server
[Info]Server Listening...
[Info]SetupQRCode: [CH:Y3.13G3600A50324800]
[Info]Copy/paste the below URL in a browser to see the QR Code:
[Info]https://dhrishi.github.io/connectedhomeip/qrcode.html?data=CH%3AY3.13G3600A50324800
[Info]Manual pairing code: [34970112332]
[Info]Current Firmware Version: 04-2020-te2
[Info]Thread task running
[Info]CHIP task running
[Info]OpenThread State Changed (Flags: 0x00038200)
[Info]   Network Name: OpenThread
[Info]   PAN Id: 0xFFFF
[Info]   Extended PAN Id: 0xDEAD00BEEF00CAFE
[Info]   Channel: 11
[Info]   Mesh Prefix: FDDE:AD00:BEEF::/64
[Info]   Master Key: 4D69D05232A8447494BA06C0AF1F0F5D
[Info]Assigned local session key ID 0
[Info]Waiting for PBKDF param request
[Info]Started BLE Advertising!
[Info]Started Advertising.
[Info]Started NFC Tag Emulation!
[Info]BLE is connected with device: 0.

[Info]Started Advertising.
[Info]NFC Tag emulation is already started!
[Info]BLE MTU size has been changed to 247.
[Info]local and remote recv window sizes = 3
[Info]selected BTP version 3
[Info]using BTP fragment sizes rx 128 / tx 20.
[Info]BLE EndPoint 0x400ea50 Connection Complete
[Info]Long dispatch time: 300 ms
[Info]Received message of type 32 and protocolId 0 on exchange 39017
[Info]ec id: 39017, Delegate: 0x4010420
[Info]Received PBKDF param request
[Info]Sent PBKDF param response
[Info]Long dispatch time: 20760 ms
[Info]Long dispatch time: 140 ms
[Info]Long dispatch time: 210 ms
[Info]Long dispatch time: 150 ms
[Info]Long dispatch time: 290 ms
[Info]Received message of type 34 and protocolId 0 on exchange 39017
[Info]Received spake2p msg1
[Info]Using Object Id --> 28

[Info]Peer assigned session key ID 0
[Info]Sent spake2p msg2
[Info]Long dispatch time: 2380 ms
[Info]Long dispatch time: 210 ms
[Info]Long dispatch time: 140 ms
[Info]Long dispatch time: 210 ms
[Info]Long dispatch time: 210 ms
[Info]Long dispatch time: 210 ms
[Info]Long dispatch time: 210 ms
[Info]Received message of type 36 and protocolId 0 on exchange 39017
[Info]Received spake2p msg3
[Info]New pairing for device 0x0000000000000000, key 0!!
[Info]Device completed SPAKE2+ handshake
[Info]Persisting admin ID 0, next available 1
[Info]Stored value in server storage
[Info]KVS, put key id:: 150
[Info]Admin (0) persisted to storage. Calling OnAdminPersistedToStorage
[Info]OpCreds: Admin 0 was persisted to storage. FabricId<PHONE_NUMBER>0000000, NodeId<PHONE_NUMBER>0000000, VendorId 0x0EC9
[Info]OpCreds: Call to writeAdminsIntoFabricsListAttribute
[Info]OpCreds: Skipping over unitialized admin with fabricId 0x0000000000000000, nodeId 0x0000000000000000 vendorId 0x0000
[Info]OpCreds: Stored 0 admins in fabrics list attribute.
[Info]KVS, put key id:: 170
[Info]Persisting admin ID successfully
[Info]Device completed Rendezvous process
[Info]Stored value in server storage
[Info]KVS, put key id:: 241
[Info]Stored value in server storage
[Info]KVS, put key id:: 3
[Info]Long dispatch time: 2660 ms
[Info]Stopped Advertising
[Info]Stopped NFC Tag Emulation!
[Info]Secure transport received message destined to fabric 0, node 0x0000000000097ED1. Key ID 0
[Info]Setting nodeID lX on admin.
[Info]Setting fabricID lX on admin.
[Info]Since admin was modified, persisting changes to KVS
[Info]Stored value in server storage
[Info]KVS, put key id:: 150
[Info]Admin (0) persisted to storage. Calling OnAdminPersistedToStorage
[Info]OpCreds: Admin 0 was persisted to storage. FabricId 00001B66900000000, NodeId 97ed10000000000000000, VendorId 0x0EC9
[Info]OpCreds: Call to writeAdminsIntoFabricsListAttribute
[Info]OpCreds: Skipping over unitialized admin with fabricId 0x000000000001B669, nodeId 0x0000000000097ED1 vendorId 0x0000
[Info]OpCreds: Stored 0 admins in fabrics list attribute.
[Info]Received message of type 8 and protocolId 327680 on exchange 39018
[Info]ec id: 39018, Delegate: 0x4013f08
[Info]ICR moving to [Initialize]
[Info]Received Cluster Command: Cluster=3e Command=hx Endpoint=hx
[Info]OpCreds: commissioner has requested an OpCSR
[Info]OpCreds: Finding admin with fabricId 0x000000000001B669.
[Info]Checking ind:0 [fabricId 0x000000000001B669 nodeId 0x0000000000097ED1 vendorId 0] vs [fabricId 0x000000000001B669 nodeId 0x0000000000000000 vendorId 0]
**[Info]Found a match!
[Info]OpCreds: NewCertificateSigningRequest returned 0
[Info]ICR moving to [AddCommand]
[Info]Secure message was encrypted: Msg ID 1
[Info]Sending msg from 0x0000000000097ED1 to 0x000000000001B669 at utc time: ld msec
[Info]Sending secure msg on generic transport
[Info]Secure msg send status No Error**
[Info]ICR moving to [   Sending]
[Info]ICR moving to [Uninitiali]
[Info]Long dispatch time: 5070 ms
[Info]Long dispatch time: 210 ms
[Info]Long dispatch time: 140 ms
[Info]Long dispatch time: 210 ms
[Info]Long dispatch time: 140 ms
[Info]Long dispatch time: 220 ms
[Info]Long dispatch time: 150 ms
[Info]Long dispatch time: 290 ms
[Info]Long dispatch time: 220 ms
[Info]Long dispatch time: 220 ms
[Info]Long dispatch time: 150 ms
[Info]Long dispatch time: 220 ms
[Info]Long dispatch time: 140 ms
[Info]Long dispatch time: 210 ms
[Info]Long dispatch time: 140 ms
[Info]Long dispatch time: 220 ms
[Info]Long dispatch time: 150 ms
[Info]Long dispatch time: 220 ms
[Info]Long dispatch time: 140 ms
[Info]Clearing BLE pending packets.
[Info]Releasing end point's BLE connection back to application.
[Info]BLE connection timeout: Forcing disconnection.
[Info]Stopped connectionTimeout timer.
[Info]BLE is disconnected with device: 0.

Logs on the chip-device-ctrl side:
chip-device-ctrl > connect -ble 3840 020202021
Device is assigned with nodeid = 622289
CHIP:SC: Assigned local session key ID 0
CHIP:IN: Message appended to BLE send queue
CHIP:SC: Sent PBKDF param request
CHIP:DL: TRACE: Bluez mainloop starting Thread
CHIP:DL: TRACE: Bus acquired for name C-50b1
CHIP:CTL: SyncSetKeyValue on StartKeyID
CHIP:DL: PlatformBlueZInit init success
CHIP:BLE: BLE removing known devices.
CHIP:BLE: BLE initiating scan.
CHIP:BLE: New device scanned: 00:60:37:53:24:DC
CHIP:BLE: Device discriminator match. Attempting to connect.
CHIP:BLE: Scan complete notification without an active scan.
CHIP:DL: ConnectDevice complete
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0013
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0001
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0001
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service0001
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: Char1 /org/bluez/hci0/dev_00_60_37_53_24_DC/service000c
CHIP:DL: New BLE connection 0xffff8c038140, device 00:60:37:53:24:DC, path /org/bluez/hci0/dev_00_60_37_53_24_DC
CHIP:DL: HandlePlatformSpecificBLEEvent 16385
CHIP:IN: BleConnectionComplete: endPoint 0xffff972d2fb8
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: HandlePlatformSpecificBLEEvent 16388
CHIP:BLE: subscribe complete, ep = 0xffff972d2fb8
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:BLE: peripheral chose BTP version 3; central expected between 2 and 3
CHIP:BLE: using BTP fragment sizes rx 20 / tx 128.
CHIP:BLE: local and remote recv window size = 3
CHIP:IN: BLE EndPoint 0xffff972d2fb8 Connection Complete
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:EM: Received message of type 33 and protocolId 0 on exchange 39017
CHIP:SC: Received PBKDF param response
CHIP:SC: Sent spake2p msg1
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:EM: Received message of type 35 and protocolId 0 on exchange 39017
CHIP:SC: Received spake2p msg2
CHIP:SC: Peer assigned session key ID 0
CHIP:SC: Sent spake2p msg3
CHIP:IN: New pairing for device 0x0000000000097ed1, key 0!!
CHIP:CTL: Remote device completed SPAKE2+ handshake

CHIP:CTL: Sending OpCSR request to 0x3e5932c8 device
CHIP:DMG: ICR moving to [Initialize]
CHIP:DMG: ICR moving to [AddCommand]
CHIP:IN: Secure message was encrypted: Msg ID 0
CHIP:IN: Sending msg from 0x000000000001B669 to 0x0000000000097ED1 at utc time: 791969033 msec
CHIP:IN: Sending secure msg on generic transport
CHIP:IN: Secure msg send status No Error
CHIP:DMG: ICR moving to [   Sending]
CHIP:CTL: Sent OpCSR request, waiting for the CSR
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:CTL: SyncSetKeyValue on StartKeyID
CHIP:CTL: SyncSetKeyValue on PairedDevice97ed1
Failed to establish secure session to device: 4050
CHIP Error 4050 (0x00000FD2): Timeout
chip-device-ctrl > CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
**CHIP:DMG: Time out! failed to receive invoke command response from Exchange: 39018
CHIP:ZCL: DefaultResponse:
CHIP:ZCL:   Transaction: 0xffff972d1378
CHIP:ZCL:   status: EMBER_ZCL_STATUS_FAILURE (0x01)**
CHIP:CTL: Device failed to receive the CSR request Response: 0x01
CHIP:CTL: SyncSetKeyValue on StartKeyID
Failed to establish secure session to device: 4172
CHIP:DMG: ICR moving to [Uninitiali]
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff8c038140
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:IN: Secure transport received message destined to fabric 0, node 0x000000000001B669. Key ID 0

cc @pan-apple

It doesn’t seem that the controller is getting the OpCSR response from the DUT. I can see the DUT did send a message. Can you add more logs in this function to make sure that it did the correct response?
emberAfOperationalCredentialsClusterOpCSRRequestCallback()
The function has logs for error scenarios, but not sure if those are not getting printed for some reason.
For reference, we should see some of the following logs on the controller side when it receives the OpCSR.
[1622647452470] [0x1701a3] CHIP: [EM] Received message of type 9 and protocolId 327680 on exchange 44250
[1622647452470] [0x1701a3] CHIP: [DMG] InvokeCommand =
[1622647452470] [0x1701a3] CHIP: [DMG] {
[1622647452470] [0x1701a3] CHIP: [DMG]  CommandList =
[1622647452470] [0x1701a3] CHIP: [DMG]  [
[1622647452470] [0x1701a3] CHIP: [DMG]          CommandDataElement =
[1622647452470] [0x1701a3] CHIP: [DMG]          {
[1622647452470] [0x1701a3] CHIP: [DMG]                  CommandPath =
[1622647452470] [0x1701a3] CHIP: [DMG]                  {
[1622647452470] [0x1701a3] CHIP: [DMG]                          EndpointId = 0x0,
[1622647452470] [0x1701a3] CHIP: [DMG]                          ClusterId = 0x3e,
[1622647452470] [0x1701a3] CHIP: [DMG]                          CommandId = 0x5,
[1622647452470] [0x1701a3] CHIP: [DMG]                  },
[1622647452470] [0x1701a3] CHIP: [DMG]
[1622647452470] [0x1701a3] CHIP: [DMG]                  CommandData =
[1622647452470] [0x1701a3] CHIP: [DMG]                  {
[1622647452470] [0x1701a3] CHIP: [DMG]                          0x0 = [
[1622647452470] [0x1701a3] CHIP: [DMG]                                  0x30, 0x81, 0xcb, 0x30, 0x70, 0x2, 0x1, 0x0, 0x30, 0xe, 0x31, 0xc, 0x30, 0xa, 0x6, 0x3, 0x55, 0x4, 0xa, 0xc, 0x3, 0x43, 0x53, 0x52, 0x30, 0x59, 0x30, 0x13, 0x6, 0x7, 0x2a, 0x86, 0x48, 0xce, 0x3d, 0x2, 0x1, 0x6,
[1622647452470] [0x1701a3] CHIP: [DMG]                  ]
[1622647452470] [0x1701a3] CHIP: [DMG]                          0x1 = [
[1622647452470] [0x1701a3] CHIP: [DMG]                                  0x14, 0x5c, 0xbd, 0xd, 0xce, 0xc0, 0xa8, 0x91, 0x9b, 0xd6, 0x73, 0xc4, 0x84, 0xc, 0x2a, 0x57, 0x23, 0xda, 0xa, 0x4, 0xd6, 0x18, 0x1c, 0x10, 0x9e, 0x19, 0xa7, 0xee, 0x60, 0xbd, 0x3e, 0x11,
[1622647452470] [0x1701a3] CHIP: [DMG]                  ]
[1622647452470] [0x1701a3] CHIP: [DMG]                          0x2 = [
[1622647452470] [0x1701a3] CHIP: [DMG]
[1622647452470] [0x1701a3] CHIP: [DMG]                  ]
[1622647452470] [0x1701a3] CHIP: [DMG]                          0x3 = [
[1622647452470] [0x1701a3] CHIP: [DMG]
[1622647452470] [0x1701a3] CHIP: [DMG]                  ]
[1622647452470] [0x1701a3] CHIP: [DMG]                          0x4 = [
[1622647452470] [0x1701a3] CHIP: [DMG]
[1622647452470] [0x1701a3] CHIP: [DMG]                  ]
[1622647452470] [0x1701a3] CHIP: [DMG]                          0x5 = [
[1622647452470] [0x1701a3] CHIP: [DMG]
[1622647452470] [0x1701a3] CHIP: [DMG]                  ]
[1622647452470] [0x1701a3] CHIP: [DMG]                  },
[1622647452470] [0x1701a3] CHIP: [DMG]          },
[1622647452470] [0x1701a3] CHIP: [DMG]
[1622647452470] [0x1701a3] CHIP: [DMG]  ],
[1622647452470] [0x1701a3] CHIP: [DMG]
[1622647452470] [0x1701a3] CHIP: [DMG] }
[1622647452470] [0x1701a3] CHIP: [ZCL] Received Cluster Command: Cluster=3e Command=5 Endpoint=0
[1622647452470] [0x1701a3] CHIP: [ZCL] OpCSRResponse:
[1622647452470] [0x1701a3] CHIP: [ZCL]   CSR: 206
[1622647452470] [0x1701a3] CHIP: [ZCL]   CSRNonce: 32
[1622647452470] [0x1701a3] CHIP: [ZCL]   VendorReserved1: 0
[1622647452470] [0x1701a3] CHIP: [ZCL]   VendorReserved2: 0
[1622647452470] [0x1701a3] CHIP: [ZCL]   VendorReserved3: 0
[1622647452470] [0x1701a3] CHIP: [ZCL]   Signature: 0
[1622647452470] [0x1701a3] CHIP: [CTL] Received certificate signing request from the device

Thanks @pan-apple for helping me.
I step into emberAfOperationalCredentialsClusterOpCSRRequestCallback and it returns with success.
Then I took a closer look at the logs on the chip-device-ctrl-side:

CHIP:CTL: Sending OpCSR request to 0x2eeabb08 device
CHIP:DMG: ICR moving to [Initialize]
CHIP:DMG: ICR moving to [AddCommand]
CHIP:IN: Secure message was encrypted: Msg ID 0
CHIP:IN: Sending msg from 0x000000000001B669 to 0x0000000000000001 at utc time: 857971535 msec
CHIP:IN: Sending secure msg on generic transport
CHIP:IN: Secure msg send status No Error
CHIP:DMG: ICR moving to [   Sending]
CHIP:CTL: Sent OpCSR request, waiting for the CSR
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff80038120
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff80038120
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff80038120
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff80038120
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DL: Indication received, conn = 0xffff80038120
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: Indication received, conn = 0xffff80038120
CHIP:DL: HandlePlatformSpecificBLEEvent 16389
CHIP:DL: HandlePlatformSpecificBLEEvent 16387
CHIP:DMG: Time out! failed to receive invoke command response from Exchange: 39018
CHIP:ZCL: DefaultResponse:
CHIP:ZCL:   Transaction: 0xffff91977378
CHIP:ZCL:   status: EMBER_ZCL_STATUS_FAILURE (0x01)
CHIP:CTL: Device failed to receive the CSR request Response: 0x01

So there are some indications that are being received from the device side. Then I looked into the device side, and these indications are being sent immediately after the CSR Op Rsp is generated, so they should contain DER bytes. As long as the SPAKE2+ session was successful, I don't expect that BLE transport lost any byte. Here are the relevant logs on the device side (first I print the DER bytes inside emberAfOperationalCredentialsClusterOpCSRRequestCallback then I print the BLE bytes in BLEManagerImpl.cpp):
[Info]Received message of type 8 and protocolId 327680 on exchange 39018
[Info]ec id: 39018, eived Cluster Command: Cluster=3e Command=hx Endpoint=hx
[Info]OpCreds: commissioner has requested an OpCSR
[Info]OpCreds: Finding admin with fabricId 0x000000000001B669.
[Info]Checking ind:0 [fabricId 0x000000000001B669 deId 0x000000000 0]
[Info]Found a match!
[Info]OpCreds: NewCertificateSigningRequest returned 0
[Info]ICR moving to [AddCommand]
[Info]csr[0]=30
[Info]csr[1]=81
[Info]csr[2]=ca
[Info]csr[3]=30
[Info]csr[4]=70
[Info]csr[5]=2
[Info]csr[6]=1
[Info]csr[7]=0
[Info]csr[8]=30
[Info]csr[9]=e
[Info]csr[10]=31
[Info]csr[11]=c
[Info]csr[12]=30
[Info]csr[13]=a
[Info]csr[14]=6
[Info]csr[15]=3
[Info]csr[16]=55
[Info]csr[17]=4
[Info]csr[18]=a
[Info]csr[19]=c
[Info]csr[20]=3
[Info]csr[21]=43
[Info]csr[22]=53
[Info]csr[23]=52
[Info]csr[24]=30
[Info]csr[25]=59
[Info]csr[26]=30
[Info]csr[27]=13
[Info]csr[28]=6
[Info]csr[29]=7
[Info]csr[30]=2a
[Info]csr[31]=86
[Info]csr[32]=48
[Info]csr[33]=ce
[Info]csr[34]=3d
[Info]csr[35]=2
[Info]csr[36]=1
[Info]csr[37]=6
[Info]csr[38]=8
[Info]csr[39]=2a
[Info]csr[40]=86
[Info]csr[41]=48
[Info]csr[42]=ce
[Info]csr[43]=3d
[Info]csr[44]=3
[Info]csr[45]=1
[Info]csr[46]=7
[Info]csr[47]=3
[Info]csr[48]=42
[Info]csr[49]=0
[Info]csr[50]=4
[Info]csr[51]=f9
[Info]csr[52]=3b
[Info]csr[53]=fd
[Info]csr[54]=b3
[Info]csr[55]=5e
[Info]csr[56]=f
[Info]csr[57]=46
[Info]csr[58]=66
[Info]csr[59]=fa
[Info]csr[60]=d3
[Info]csr[61]=ba
[Info]csr[62]=ab
[Info]csr[63]=f7
[Info]csr[64]=7f
[Info]csr[65]=9b
[Info]csr[66]=da
[Info]csr[67]=49
[Info]csr[68]=25
[Info]csr[69]=12
[Info]csr[70]=55
[Info]csr[71]=28
[Info]csr[72]=be
[Info]csr[73]=d4
[Info]csr[74]=bf
[Info]csr[75]=2b
[Info]csr[76]=a6
[Info]csr[77]=5f
[Info]csr[78]=a4
[Info]csr[79]=52
[Info]csr[80]=61
[Info]csr[81]=f0
[Info]csr[82]=d6
[Info]csr[83]=ec
[Info]csr[84]=14
[Info]csr[85]=b0
[Info]csr[86]=1b
[Info]csr[87]=5e
[Info]csr[88]=8
[Info]csr[89]=d3
[Info]csr[90]=38
[Info]csr[91]=fe
[Info]csr[92]=63
[Info]csr[93]=a6
[Info]csr[94]=65
[Info]csr[95]=fb
[Info]csr[96]=1e
[Info]csr[97]=8f
[Info]csr[98]=37
[Info]csr[99]=e5
[Info]csr[100]=be
[Info]csr[101]=a5
[Info]csr[102]=1a
[Info]csr[103]=17
[Info]csr[104]=86
[Info]csr[105]=ee
[Info]csr[106]=93
[Info]csr[107]=13
[Info]csr[108]=b1
[Info]csr[109]=2e
[Info]csr[110]=62
[Info]csr[111]=40
[Info]csr[112]=3d
[Info]csr[113]=6b
[Info]csr[114]=66
[Info]csr[115]=a0
[Info]csr[116]=0
[Info]csr[117]=30
[Info]csr[118]=c
[Info]csr[119]=6
[Info]csr[120]=8
[Info]csr[121]=2a
[Info]csr[122]=86
[Info]csr[123]=48
[Info]csr[124]=ce
[Info]csr[125]=3d
[Info]csr[126]=4
[Info]csr[127]=3
[Info]csr[128]=2
[Info]csr[129]=5
[Info]csr[130]=0
[Info]csr[131]=3
[Info]csr[132]=48
[Info]csr[133]=0
[Info]csr[134]=30
[Info]csr[135]=45
[Info]csr[136]=2
[Info]csr[137]=20
[Info]csr[138]=a
[Info]csr[139]=ce
[Info]csr[140]=28
[Info]csr[141]=24
[Info]csr[142]=2d
[Info]csr[143]=e1
[Info]csr[144]=94
[Info]csr[145]=e8
[Info]csr[146]=1b
[Info]csr[147]=c0
[Info]csr[148]=9d
[Info]csr[149]=dc
[Info]csr[150]=70
[Info]csr[151]=e0
[Info]csr[152]=2
[Info]csr[153]=45
[Info]csr[154]=b3
[Info]csr[155]=bd
[Info]csr[156]=6f
[Info]csr[157]=40
[Info]csr[158]=27
[Info]csr[159]=a2
[Info]csr[160]=c9
[Info]csr[161]=a4
[Info]csr[162]=be
[Info]csr[163]=67
[Info]csr[164]=6a
[Info]csr[165]=65
[Info]csr[166]=44
[Info]csr[167]=e
[Info]csr[168]=36
[Info]csr[169]=4c
[Info]csr[170]=2
[Info]csr[171]=21
[Info]csr[172]=0
[Info]csr[173]=b9
[Info]csr[174]=6a
[Info]csr[175]=67
[Info]csr[176]=c0
[Info]csr[177]=40
[Info]csr[178]=9c
[Info]csr[179]=e0
[Info]csr[180]=33
[Info]csr[181]=79
[Info]csr[182]=39
[Info]csr[183]=c8
[Info]csr[184]=bc
[Info]csr[185]=c5
[Info]csr[186]=b4
[Info]csr[187]=c2
[Info]csr[188]=14
[Info]csr[189]=7
[Info]csr[190]=8
[Info]csr[191]=96
[Info]csr[192]=67
[Info]csr[193]=a6
[Info]csr[194]=20
[Info]csr[195]=f1
[Info]csr[196]=bf
[Info]csr[197]=3e
[Info]csr[198]=9f
[Info]csr[199]=d0
[Info]csr[200]=35
[Info]csr[201]=d2
[Info]csr[202]=41
[Info]csr[203]=c1
[Info]csr[204]=5d
[Info]Secure message was encrypted: Msg ID 1
[Info]Sending msg from 0x0000000000000001 to 0x000000000001B669 at utc time: ld msec
[Info]Sending secure msg on generic transport
[Info]Trying to send indication. Len: 20
[Info]data[0]=9
[Info]data[1]=9
[Info]data[2]=f
[Info]data[3]=43
[Info]data[4]=1
[Info]data[5]=21
[Info]data[6]=23
[Info]data[7]=1
[Info]data[8]=0
[Info]data[9]=0
[Info]data[10]=0
[Info]data[11]=1
[Info]data[12]=0
[Info]data[13]=0
[Info]data[14]=0
[Info]data[15]=0
[Info]data[16]=0
[Info]data[17]=0
[Info]data[18]=0
[Info]data[19]=69
[Info]BLE Event - Sent :-)
[Info]Secure msg send status No Error
[Info]ICR moving to [   Sending]
[Info]ICR moving to [Uninitiali]
[Info]Long dispatch time: 5250 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=10
[Info]data[2]=b6
[Info]data[3]=1
[Info]data[4]=0
[Info]data[5]=0
[Info]data[6]=0
[Info]data[7]=0
[Info]data[8]=0
[Info]data[9]=0
[Info]data[10]=0
[Info]data[11]=80
[Info]data[12]=ab
[Info]data[13]=94
[Info]data[14]=91
[Info]data[15]=37
[Info]data[16]=64
[Info]data[17]=e4
[Info]data[18]=64
[Info]data[19]=34
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 180 ms
[Info]Trying to send indication. Len: 20
[Info]data[0]=a
[Info]data[1]=a
[Info]data[2]=11
[Info]data[3]=67
[Info]data[4]=4b
[Info]data[5]=78
[Info]data[6]=1b
[Info]data[7]=8e
[Info]data[8]=4c
[Info]data[9]=6b
[Info]data[10]=f0
[Info]data[11]=c5
[Info]data[12]=9b
[Info]data[13]=c7
[Info]data[14]=38
[Info]data[15]=f0
[Info]data[16]=73
[Info]data[17]=99
[Info]data[18]=a1
[Info]data[19]=39
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 210 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=12
[Info]data[2]=91
[Info]data[3]=d7
[Info]data[4]=87
[Info]data[5]=fa
[Info]data[6]=49
[Info]data[7]=83
[Info]data[8]=36
[Info]data[9]=98
[Info]data[10]=61
[Info]data[11]=81
[Info]data[12]=d
[Info]data[13]=55
[Info]data[14]=4
[Info]data[15]=e1
[Info]data[16]=f
[Info]data[17]=a9
[Info]data[18]=e8
[Info]data[19]=70
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 200 ms
[Info]Trying to send indication. Len: 20
[Info]data[0]=a
[Info]data[1]=b
[Info]data[2]=13
[Info]data[3]=3f
[Info]data[4]=5d
[Info]data[5]=2b
[Info]data[6]=a
[Info]data[7]=13
[Info]data[8]=b8
[Info]data[9]=4c
[Info]data[10]=cb
[Info]data[11]=e0
[Info]data[12]=21
[Info]data[13]=2e
[Info]data[14]=e4
[Info]data[15]=6f
[Info]data[16]=f7
[Info]data[17]=b0
[Info]data[18]=cb
[Info]data[19]=1b
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 140 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=14
[Info]data[2]=67
[Info]data[3]=e9
[Info]data[4]=99
[Info]data[5]=d4
[Info]data[6]=e6
[Info]data[7]=e6
[Info]data[8]=bc
[Info]data[9]=a0
[Info]data[10]=6a
[Info]data[11]=83
[Info]data[12]=c2
[Info]data[13]=78
[Info]data[14]=51
[Info]data[15]=6e
[Info]data[16]=6b
[Info]data[17]=e3
[Info]data[18]=a5
[Info]data[19]=fd
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 490 ms
[Info]Trying to send indication. Len: 20
[Info]data[0]=a
[Info]data[1]=c
[Info]data[2]=15
[Info]data[3]=64
[Info]data[4]=1
[Info]data[5]=6e
[Info]data[6]=28
[Info]data[7]=a8
[Info]data[8]=41
[Info]data[9]=6d
[Info]data[10]=2e
[Info]data[11]=9c
[Info]data[12]=15
[Info]data[13]=a7
[Info]data[14]=70
[Info]data[15]=29
[Info]data[16]=62
[Info]data[17]=cc
[Info]data[18]=76
[Info]data[19]=af
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 140 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=16
[Info]data[2]=51
[Info]data[3]=57
[Info]data[4]=94
[Info]data[5]=a9
[Info]data[6]=e4
[Info]data[7]=37
[Info]data[8]=90
[Info]data[9]=2e
[Info]data[10]=b8
[Info]data[11]=e3
[Info]data[12]=e8
[Info]data[13]=2a
[Info]data[14]=f8
[Info]data[15]=72
[Info]data[16]=2b
[Info]data[17]=68
[Info]data[18]=34
[Info]data[19]=f2
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 200 ms
[Info]Trying to send indication. Len: 20
[Info]data[0]=a
[Info]data[1]=d
[Info]data[2]=17
[Info]data[3]=92
[Info]data[4]=75
[Info]data[5]=41
[Info]data[6]=bf
[Info]data[7]=d6
[Info]data[8]=ea
[Info]data[9]=98
[Info]data[10]=ba
[Info]data[11]=80
[Info]data[12]=4b
[Info]data[13]=fc
[Info]data[14]=57
[Info]data[15]=7c
[Info]data[16]=f9
[Info]data[17]=44
[Info]data[18]=33
[Info]data[19]=e7
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 150 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=18
[Info]data[2]=70
[Info]data[3]=c
[Info]data[4]=31
[Info]data[5]=8a
[Info]data[6]=c5
[Info]data[7]=48
[Info]data[8]=bd
[Info]data[9]=e7
[Info]data[10]=44
[Info]data[11]=ba
[Info]data[12]=b
[Info]data[13]=bf
[Info]data[14]=c4
[Info]data[15]=d6
[Info]data[16]=4c
[Info]data[17]=ab
[Info]data[18]=7f
[Info]data[19]=b
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 200 ms
[Info]Trying to send indication. Len: 20
[Info]data[0]=a
[Info]data[1]=e
[Info]data[2]=19
[Info]data[3]=a3
[Info]data[4]=85
[Info]data[5]=a8
[Info]data[6]=2e
[Info]data[7]=c
[Info]data[8]=21
[Info]data[9]=66
[Info]data[10]=92
[Info]data[11]=1c
[Info]data[12]=97
[Info]data[13]=ff
[Info]data[14]=8b
[Info]data[15]=c7
[Info]data[16]=32
[Info]data[17]=7
[Info]data[18]=e8
[Info]data[19]=25
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 140 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=1a
[Info]data[2]=35
[Info]data[3]=5d
[Info]data[4]=63
[Info]data[5]=cc
[Info]data[6]=53
[Info]data[7]=75
[Info]data[8]=d2
[Info]data[9]=78
[Info]data[10]=a2
[Info]data[11]=18
[Info]data[12]=6c
[Info]data[13]=d6
[Info]data[14]=f1
[Info]data[15]=bb
[Info]data[16]=b1
[Info]data[17]=4a
[Info]data[18]=43
[Info]data[19]=16
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 190 ms
[Info]Trying to send indication. Len: 20
[Info]data[0]=a
[Info]data[1]=f
[Info]data[2]=1b
[Info]data[3]=71
[Info]data[4]=c4
[Info]data[5]=40
[Info]data[6]=6c
[Info]data[7]=80
[Info]data[8]=df
[Info]data[9]=c4
[Info]data[10]=67
[Info]data[11]=29
[Info]data[12]=d2
[Info]data[13]=5f
[Info]data[14]=6d
[Info]data[15]=ec
[Info]data[16]=e5
[Info]data[17]=75
[Info]data[18]=58
[Info]data[19]=f7
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 140 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=1c
[Info]data[2]=a4
[Info]data[3]=72
[Info]data[4]=63
[Info]data[5]=a7
[Info]data[6]=20
[Info]data[7]=74
[Info]data[8]=85
[Info]data[9]=8f
[Info]data[10]=27
[Info]data[11]=fc
[Info]data[12]=5
[Info]data[13]=7d
[Info]data[14]=9e
[Info]data[15]=f9
[Info]data[16]=2
[Info]data[17]=2c
[Info]data[18]=ae
[Info]data[19]=b7
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 200 ms
[Info]Trying to send indication. Len: 20
[Info]data[0]=a
[Info]data[1]=10
[Info]data[2]=1d
[Info]data[3]=5
[Info]data[4]=56
[Info]data[5]=87
[Info]data[6]=fb
[Info]data[7]=78
[Info]data[8]=d2
[Info]data[9]=78
[Info]data[10]=74
[Info]data[11]=df
[Info]data[12]=ee
[Info]data[13]=27
[Info]data[14]=7c
[Info]data[15]=65
[Info]data[16]=2d
[Info]data[17]=b3
[Info]data[18]=c1
[Info]data[19]=a5
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 290 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=1e
[Info]data[2]=70
[Info]data[3]=f4
[Info]data[4]=38
[Info]data[5]=19
[Info]data[6]=61
[Info]data[7]=d5
[Info]data[8]=89
[Info]data[9]=17
[Info]data[10]=d1
[Info]data[11]=dc
[Info]data[12]=1d
[Info]data[13]=5b
[Info]data[14]=66
[Info]data[15]=6b
[Info]data[16]=92
[Info]data[17]=fb
[Info]data[18]=9c
[Info]data[19]=fc
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 190 ms
[Info]Trying to send indication. Len: 20
[Info]data[0]=a
[Info]data[1]=11
[Info]data[2]=1f
[Info]data[3]=e4
[Info]data[4]=86
[Info]data[5]=13
[Info]data[6]=7c
[Info]data[7]=31
[Info]data[8]=f1
[Info]data[9]=ec
[Info]data[10]=14
[Info]data[11]=98
[Info]data[12]=46
[Info]data[13]=fa
[Info]data[14]=4
[Info]data[15]=f9
[Info]data[16]=27
[Info]data[17]=95
[Info]data[18]=92
[Info]data[19]=3c
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 210 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 20
[Info]data[0]=2
[Info]data[1]=20
[Info]data[2]=5c
[Info]data[3]=bf
[Info]data[4]=9d
[Info]data[5]=30
[Info]data[6]=81
[Info]data[7]=cf
[Info]data[8]=b9
[Info]data[9]=c1
[Info]data[10]=4b
[Info]data[11]=94
[Info]data[12]=89
[Info]data[13]=f5
[Info]data[14]=19
[Info]data[15]=9b
[Info]data[16]=da
[Info]data[17]=12
[Info]data[18]=b8
[Info]data[19]=9b
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 410 ms
[Info]Trying to send indication. Len: 13
[Info]data[0]=e
[Info]data[1]=12
[Info]data[2]=21
[Info]data[3]=52
[Info]data[4]=0
[Info]data[5]=40
[Info]data[6]=92
[Info]data[7]=85
[Info]data[8]=87
[Info]data[9]=ec
[Info]data[10]=25
[Info]data[11]=8
[Info]data[12]=a8
[Info]BLE Event - Sent :-)
[Info]Long dispatch time: 210 ms
[Info]Attribute write request(device: 0,handle: 14).
[Info]Write request/command received forCHIPoBLE RX characteristic (con 0, len 3)
[Info]Trying to send indication. Len: 3
[Info]data[0]=8
[Info]data[1]=14
[Info]data[2]=23
[Info]BLE Event - Sent :-)

After several hours of debugging I found a fix:
diff --git a/src/messaging/ExchangeContext.cpp b/src/messaging/ExchangeContext.cpp
index 5aa546cda69..ae54556138f 100644
--- a/src/messaging/ExchangeContext.cpp
+++ b/src/messaging/ExchangeContext.cpp
@@ -73,7 +73,9 @@ void ExchangeContext::SetResponseExpected(bool inResponseExpected)

 void ExchangeContext::SetResponseTimeout(Timeout timeout)
 {
-    mResponseTimeout = timeout;
+    ChipLogError(ExchangeManager, "Set timeout %d", timeout);
+
+    mResponseTimeout = timeout * 2;
 }

The initial value for the mResponseTimeout is 30000 (30s?), but the timeout error occurs after 20s - I don't understand why. Doubling the value fixed the Rendezvous session.

That's really weird. Does doubling it change it to 40s? It would indicate some issue with the timer itself.
Also, 20s should have been long enough to receive the CSR response.

With the default value, the timer always expires in the middle of the CSR response reception - this happens after ~16-17s after the "connect -ble" is issued. However, it's unclear to me if the timer is armed for the whole rendezvous session or only for the CSR response.

This timer issue seems to be related to https://github.com/project-chip/connectedhomeip/issues/7005: the embedded device sent the required packets but the chip-device-ctrl times out.

@doru91 , I think this function is setting up the response timer
CHIP_ERROR CommandSender::SendCommandRequest(NodeId aNodeId, Transport::AdminId aAdminId, SecureSessionHandle * secureSession)

specifically, here
    mpExchangeCtx->SetResponseTimeout(kImMessageTimeoutMsec);

Looks like the default timeout is 6 seconds.
uint32_t kImMessageTimeoutMsec  = 6000;

@doru91, I have submitted this issue (https://github.com/project-chip/connectedhomeip/issues/7489) to have a proper fix for the timeouts. For time being, you could probably increase kImMessageTimeoutMsec to 12 seconds. If you plan to go that route, please mention the issue 7489 in the code comment as a TODO.

Perfect, @pan-apple . Submitted https://github.com/project-chip/connectedhomeip/pull/7490

Is this resolved?


Per-FedAVG clients are trained twice

I found there will be two client.train() called in each round. Is it on purpose? Could you please explain it to me? Thanks!

I have the same question.
In serverperavg.py:
            # choose several clients to send back upated model to server
            for client in self.selected_clients:
                client.train()
                client.train()

I found there will be two client.train() called in each round. Is it on purpose? Could you please explain it to me? Thanks!

Perhaps because of this, you can see the commit record this time:
https://github.com/TsingZ0/PFL-Non-IID/commit/4f394efe04f30dbd3cab4278467631854f997903#diff-63e160f53ad3e0f07661ac69c3db7896c4d81fb8396e705d38ac1d680e175e41
Note the difference in the train() function, batch_size*2, so we need to train() twice.

@NJU-TJL Yes.
I call client.train() twice to keep the number of update steps of Per-FedAvg the same as other methods, e.g., FedAvg. To perform meta-learning for Per-FedAvg, I first update the local model to an intermediate model with the first batch of data, obtain the gradients of the intermediate model on the second batch of data, and update the original local model with these gradients. Thus, only half of the data in the training set updates the local model if one calls client.train() once.

How is the Hessian matrix of Per-FedAvg calculated?


Tags badge in blog post not rendering

I'm trying to make tags badge appear in blog posts.
I se that in single.html the code is present, but tags don't appear.
I tried to add tags in the header copying them from a page of your exampleSite, but the site then doesn't render and gives an error because the heaer is formatted
tags = ["value","value2"]
but Hugo is expecting
tags: ["value","value2"]
is that the cause of the issue?

Yeah, this would depend on the front-matter you use i.e. using +++ means it's TOML which would be tags = ["value","value2"] whilst --- means it's YAML which would be tags: ["value","value2"].


chore(FDS-148): get all *TestID code out of ActionEdit.js

Resolves: FDS-148
Snapshots
Snapshots changed because now we are getting all collumns from the dataConfig.display prop, plus one for the actions.
Unit tests

added unit tests for the current change
added unit tests for FDS-164 (table header not adding an extra column for actions)

Fails

:no_entry_sign:
Please add a '### Snapshots' section to explain the reason we are changing snapshots.

  Generated by :no_entry_sign: dangerJS against 7d4822aadeca912a5aa7c4df934bc74918a8d2b5

Fails

:no_entry_sign:
Please add a '### Dependencies' section to explain the reason we are changing dependencies.

  Generated by :no_entry_sign: dangerJS against fd4f2053d39cdde8193a618c04f2b791e5be89f3


Add support for retrieval from LDAPresult messages

The simplest result messages contain a result code and/or a string.  Optionally, there could be more.
It would be ideal if these could be retrieved from a response message in a generic manner.  Especially when passing requests to a server, it is useful to be able to learn easily what it has said.
Similarly, the ability to build such responses through generic support is welcome, because many commands do not require additional data anyway.

One way of doing this is by side-channeling responses to lillyget_response() and lillyput_response().  This would simplify both processing responses and generating them, just as planned above.  Moreover, it would integrate nicely with the API above.
The question that remains is when to invoke lillyget_operation() with a more-than-average result.  This may be the decision of the configuration, and could possibly be made specifically for an operation code.  Whether lillyput_operation() or lillyput_response() is used is a much easier choice; the application simply does what it likes.
We should put some thought into the ordering of the API calls, for sure, but it does seem to make sense to add response handling with a possibly different treatment.

Done in 0f01cdd11d82652d9e7c3d956a62ef2dd56778fc


Docker build error

Docker version 20.10.6, build 370c289   macOS 11.4 aarch64 on commit e58c6a54f2.
=> ERROR importing cache manifest from rvt_base:latest
I had to delete this line from docker/mkimage:
--cache-from="${DOCKER_IMAGE_NAME}:${DOCKER_VERSION}" \

This cache doesn't exist on the first build?

Another error on commit 46fd9f1ab883b.
macOS 11.4, aarch64, Docker version 20.10.6, build 370c289
docker/build
To build LLVM11 version, use env LLVM11=yes docker/build
Making docker image rvt_base:latest using Dockerfile
../mkimage: line 20: [: -v: unary operator expected
[+] Building 0.6s (3/3) FINISHED
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 1.88kB                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => ERROR [internal] load metadata for docker.io/library/ubuntu:20.04                                                                       0.5s
------
 > [internal] load metadata for docker.io/library/ubuntu:20.04:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: rpc error: code = Unknown desc = open /Users/USERNAME/.docker/.token_seed: permission denied

Ran sudo docker/build, now getting this error that it is unable to find many packages.
 => ERROR [2/3] RUN apt-get --yes update   && apt-get install --no-install-recommends --yes   bison   build-essential   clang-10   clang-format-10   c  8.7s
------
 > importing cache manifest from rvt_base:latest:
------
------
 > [2/3] RUN apt-get --yes update   && apt-get install --no-install-recommends --yes   bison   build-essential   clang-10   clang-format-10   clang-tools-10   clang-11   clang-format-11   clang-tools-11   gcc-multilib   g++-7-multilib   cmake   curl   doxygen   expect   flex   git   libboost-all-dev   libcap-dev   libffi-dev   libgoogle-perftools-dev   libncurses5-dev   libsqlite3-dev   libssl-dev   libtcmalloc-minimal4   lib32stdc++-7-dev   libgmp-dev   libgmpxx4ldbl   lld-10   lld-11   llvm-10   llvm-10-dev   llvm-11   llvm-11-dev   ncurses-doc   ninja-build   perl   pkg-config   python   python3   python3-minimal   python3-pip   subversion   sudo   unzip   wget   && apt-get clean   && pip3 install --no-cache-dir setuptools   && pip3 install --no-cache-dir     argparse     colored     lit     pyyaml     tabulate     termcolor     toml     wllvm:
#6 0.419 Get:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease [265 kB]
#6 1.035 Get:2 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease [114 kB]
#6 1.135 Get:3 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease [101 kB]
#6 1.260 Get:4 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [114 kB]
#6 1.465 Get:5 http://ports.ubuntu.com/ubuntu-ports focal/restricted arm64 Packages [1317 B]
#6 1.473 Get:6 http://ports.ubuntu.com/ubuntu-ports focal/multiverse arm64 Packages [139 kB]
#6 1.480 Get:7 http://ports.ubuntu.com/ubuntu-ports focal/main arm64 Packages [1234 kB]
#6 2.020 Get:8 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 Packages [11.1 MB]
#6 6.737 Get:9 http://ports.ubuntu.com/ubuntu-ports focal-updates/main arm64 Packages [988 kB]
#6 7.171 Get:10 http://ports.ubuntu.com/ubuntu-ports focal-updates/restricted arm64 Packages [2893 B]
#6 7.171 Get:11 http://ports.ubuntu.com/ubuntu-ports focal-updates/universe arm64 Packages [912 kB]
#6 7.501 Get:12 http://ports.ubuntu.com/ubuntu-ports focal-updates/multiverse arm64 Packages [5147 B]
#6 7.502 Get:13 http://ports.ubuntu.com/ubuntu-ports focal-backports/universe arm64 Packages [4304 B]
#6 7.503 Get:14 http://ports.ubuntu.com/ubuntu-ports focal-security/restricted arm64 Packages [2649 B]
#6 7.505 Get:15 http://ports.ubuntu.com/ubuntu-ports focal-security/universe arm64 Packages [666 kB]
#6 7.656 Get:16 http://ports.ubuntu.com/ubuntu-ports focal-security/multiverse arm64 Packages [2378 B]
#6 7.657 Get:17 http://ports.ubuntu.com/ubuntu-ports focal-security/main arm64 Packages [586 kB]
#6 7.879 Fetched 16.3 MB in 8s (2114 kB/s)
#6 7.879 Reading package lists...
#6 8.245 Reading package lists...
#6 8.580 Building dependency tree...
#6 8.648 Reading state information...
#6 8.679 Package gcc-multilib is not available, but is referred to by another package.
#6 8.679 This may mean that the package is missing, has been obsoleted, or
#6 8.679 is only available from another source
#6 8.679
#6 8.715 E: Package 'gcc-multilib' has no installation candidate
#6 8.715 E: Unable to locate package g++-7-multilib
#6 8.715 E: Couldn't find any package by regex 'g++-7-multilib'
#6 8.715 E: Unable to locate package lib32stdc++-7-dev
#6 8.715 E: Couldn't find any package by regex 'lib32stdc++-7-dev'
------
executor failed running [/bin/sh -c apt-get --yes update   && apt-get install --no-install-recommends --yes   bison   build-essential   clang-10   clang-format-10   clang-tools-10   clang-11   clang-format-11   clang-tools-11   gcc-multilib   g++-7-multilib   cmake   curl   doxygen   expect   flex   git   libboost-all-dev   libcap-dev   libffi-dev   libgoogle-perftools-dev   libncurses5-dev   libsqlite3-dev   libssl-dev   libtcmalloc-minimal4   lib32stdc++-7-dev   libgmp-dev   libgmpxx4ldbl   lld-10   lld-11   llvm-10   llvm-10-dev   llvm-11   llvm-11-dev   ncurses-doc   ninja-build   perl   pkg-config   python   python3   python3-minimal   python3-pip   subversion   sudo   unzip   wget   && apt-get clean   && pip3 install --no-cache-dir setuptools   && pip3 install --no-cache-dir     argparse     colored     lit     pyyaml     tabulate     termcolor     toml     wllvm]: exit code: 100'''

z3 isn't releasing an aarch64 Ubuntu build. This will have to be built from source pinned to whatever commit hash is recommended.
Next error, there is no prebuilt config for aarch64 on klee-uclibc:
=> ERROR [8/8] RUN sh build_klee                                                                                12.3s
------
> importing cache manifest from rvt_klee:latest:
------
------
> [8/8] RUN sh build_klee:
#13 0.164 Cloning into 'klee-uclibc'...
#13 12.12 Note: switching to 'klee_uclibc_v1.2'.
#13 12.12
#13 12.12 You are in 'detached HEAD' state. You can look around, make experimental
#13 12.12 changes and commit them, and you can discard any commits you make in this
#13 12.12 state without impacting any branches by switching back to a branch.
#13 12.12
#13 12.12 If you want to create a new branch to retain commits you create, you may
#13 12.12 do so (now or later) by using -c with the switch command. Example:
#13 12.12
#13 12.12   git switch -c <new-branch-name>
#13 12.12
#13 12.12 Or undo this operation with:
#13 12.12
#13 12.12   git switch -
#13 12.12
#13 12.12 Turn off this advice by setting config variable advice.detachedHead to false
#13 12.12
#13 12.12 HEAD is now at 8ccd74cf6 Merge pull request #25 from MartinNowack/fix_32bit_detection
#13 12.15 INFO:Forcing C compiler to be.../usr/bin/clang-10
#13 12.15 INFO:Absolute path to compiler.../usr/bin/clang-10
#13 12.15 INFO:Disabling assertions
#13 12.15 INFO:Configuring for Debug build
#13 12.15 INFO:Configuring for LLVM bitcode archive
#13 12.15 INFO:Using llvm-config at.../usr/bin/llvm-config-10
#13 12.18 INFO:Using llvm tool dir.../usr/lib/llvm-10/bin
#13 12.18 INFO:Found "/usr/lib/llvm-10/bin/llvm-objdump".
#13 12.18 INFO:Found "/usr/lib/llvm-10/bin/llvm-link".
#13 12.18 INFO:Found "/usr/lib/llvm-10/bin/llvm-ar".
#13 12.18 INFO:Found "/usr/lib/llvm-10/bin/llvm-nm".
#13 12.18 INFO:Testing LLVM Bitcode compiler.../usr/bin/clang-10
#13 12.24 INFO:Compiler /usr/bin/clang-10 works
#13 12.24 INFO:Using LLVM Bitcode Compiler.../usr/bin/clang-10
#13 12.24 INFO:Checking for ncurses...
#13 12.29 INFO:Writing templated file to "/home/root/klee-uclibc/Makefile.klee"
#13 12.29 INFO:Setting up pre-made configure for...aarch64
#13 12.29 ERROR:"/home/root/klee-uclibc/klee-premade-configs/aarch64" does not exist. Cannot install pre-made .config file
------
executor failed running [/bin/sh -c sh build_klee]: exit code: 1

Thanks for the report.
It looks like the first issue is due to Ubuntu having a slightly different set of packages (or names for packages??) on Arm than on x86. Probably not too hard to fix.
The second issue seems to be about KLEE and KLEE-uclibc supporting Arm. A quick search on their github page suggests that there have been no discussions of AArch64 or Arm so it doesn't seem to be on their radar.
You could perhaps try the KLEE project's own docker images https://klee.github.io/docker/ and https://hub.docker.com/r/klee/klee/ in case they work. (If those do work, then I can try to figure out what they do different; if not, probably best reporting on the KLEE issue tracker)
[Incidentally... In case you are wondering why don't just use KLEE's docker images directly? When we first started using KLEE, this was not possible. After the recent simplification of our own docker images, I think that we are very close to being able to use the KLEE docker images. I suspect that we will switch to using their images sometime in the future.]


Added function to calculate Corpus-level BLEU and RIBES

In the process of adding functions to calculate corpus-level BLEU and RIBES, the following changes were made:

Set the default uniform weights for 4grams when calculating BLEU scores.

The original paper also set default weights and limits to 4grams, thus the default weights were at at [0.25] * 4.

Added function for corpus-level BLEU by calculating mirco-average precision

The original BLEU paper (Papineni et al. 2002) was meant to calculate micro-average corpus-level score. So the modified precision and brevity penalty scores does return a float but the sum of numerators and denominators. Simply averaging sentence level BLEU (i.e. marco-average) will not be the same as the BLEU as intended in the paper.

Change _modified_precision() to return numerator and denominator instead of a single-sentence BLEU score, i.e. corpus_bleu()

sentence_modified_precision() will return the floating point BLEU score for a single sentence.
Also, by disentangling the float return from the precision and penalty functions, smoothing on the precision can be easily extended, now that _modified_precision() and _brevity_penalty() returns numerators and denominators. E.g. when someone wants  to implement BLEU smoothing from http://acl2014.org/acl2014/W14-33/pdf/W14-3346.pdf.

Change the nltk.translate namespaces

To preserve current user's code. the tranlsate.__init__.py imports the sentence_bleu as the default nltk.translate.bleu. So from the user's end, BLEU still works the same way and calculating corpus-level bleu will require importing from nltk.translate.bleu_score import corpus_bleu.

Added function for corpus-level RIBES score, i.e. corpus_ribes()

Different from BLEU's micro-average precision, RIBES calculates the macro-average precision by averaging the best RIBES score for each pair of hypothesis and its corresponding references. So we can safely sum and divide by len(). See line 307 from RIBES v1.03.1 (http://www.kecl.ntt.co.jp/icl/lirg/ribes/)

@hoontw Thanks for the review! The Fraction return type suggestion is great! That simplifies all the silly duck functions I was creating. The revised version of the code looks much cleaner now.

Looks much better than before! Just a few more minor tweaks and it is good to go.

@hoontw sorry for the late commits, I was moving around and at last I've reached where I'm supposed to be =)

Thanks @alvations for the changes. It's great to have corpus-level metrics for MT.

Now we can do some tuning using the corpus-level metrics, possibly something like https://github.com/alvations/mosesdecoder/blob/master/scripts/training/propy/pro.py.

@dimazest Thanks for the suggestions! Changes made in #1238


[ci skip] NO_CI adding bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I've added bot automerge as instructed in #1.
Merge this PR to enable bot automerging.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender


Unexpected behavior for Json::encode()

I have xml with the following structure:
<?xml version="1.0" encoding="UTF-8"?>
<file>
  <apiKey>ieu2iqw4o</apiKey>
  <modelName>Address</modelName>
  <calledMethod>getCities</calledMethod>
  <methodProperties>
    <FindByString>Kiev</FindByString>
  </methodProperties>
</file>

The described structure should be converted to array and the easiest way do it - it's encoding to json and decode back.
The following code:
$document = simplexml_load_string($data);
$data = Json::encode((array) $document);
var_dump(Json::decode($data, true));

is return
Array
(
    [apiKey] => ieu2iqw4o
    [modelName] => Address
    [calledMethod] => getCities
    [methodProperties] => Array
        (
            [FindByString] => Array
                (
                )
        )
)

As you see the FindByString property is empty, but the implementation of json_decode(json_encode((array) $document), true) works correctly.
After debugging I found what https://github.com/yiisoft/yii2/blob/master/framework/helpers/BaseJson.php#L147 method not processing data for FindByString node, because the $data is a SimpleXMLElement object, but not array.
I think the typecasting $data to array in foreach should solve this problem.

@joni-jones would you like to make a PR?

Casting to array before foreach may break handling of \Traversable objects.
I think we should add a new condition branch especially for XML Elements and cast $data there:
} elseif ($data instanceof \SimpleXMLElement)` {
    $data = (array) $data;
}

@SilverFire, to add new check for SimpleXMLElement it's not good idea, because in future may be needed another condition

I think it's not a problem

It's increase code complexety

Yes, it is, but your idea breaks iterating over \Traversable classes completely: https://3v4l.org/tWhcD

Typecasting was been a variant how to fix, but it doesn't consider Traversable, so need to find another solution.

I have already suggested the solution and it looks good enough for me, but I'm open to better options.

Maybe it would be better to check if element not traversable and when and typecasting to array?

@yiisoft/core-developers need your opinions

I think it's not JSON class responsibility to convert XML into arrays.

@samdark, yes, json functions not designed for it, but they can do it. The Json::encode() extends capabilities of json_encode(), but it shouldn't broke exists.

https://github.com/yiisoft/yii2/blob/master/framework/helpers/BaseJson.php#L147
foreach ((array)$data as $name => $value) {
    $result[$name] = $value;
}

@LAV45 could you read the issue a little bit more attentively, please?
@samdark Your opinion is generally correct, but there is a bunch of conditions to convert different objects to array. Why not add XML handling?

@SilverFire , OK
then let's add a check
if (!$items instanceof \Traversable) {
   $data = (array)$data;
}
foreach ($data as $name => $value) {
    $result[$name] = $value;
}

Casting to array is enough - no need to iterate over $data again.

$document = simplexml_load_string($xml);
var_dump($document instanceof \Traversable) // => true

$json = json_encode($document);
$data = json_decode($json, true);
var_dump($data);
/** return
array (
  'apiKey' => 'ieu2iqw4o',
  'modelName' => 'Address',
  'calledMethod' => 'getCities',
  'methodProperties' =>
  array (
    'FindByString' => 'Kiev',
  ),
)
*/

@joni-jones , in your case it is best to use standard php methods json_encode and json_decode

@LAV45 , now I use json_encode/json_decode, but it's little strange what Json::encode() brokes php methods.

Fixed https://github.com/yiisoft/yii2/commit/95edff3b1dc66829957f6999bd3c646d841e14d1


The childNodes method supprot

Use for nested structure, avoid parse again,
example:
NodeA has Node1..Node9
on normal, have to parse NodeA then use For or While parse each node.
use the method only parse one time, then get each child node.

This does the same thing that the -children property does, that was already added in. See https://github.com/topfunky/hpple/blob/master/TFHppleElement.h#L56


Fix spelling

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Hi @SudhakarKuma I've reviewed your changes and they look good to me. Thank you for contributing ❤


Sentinel4github Updates

Change(s):
Sentinel4github Solution

Updates for Go Live

Updates

[x] Workbook - Rename GitHub Advanced Security Workbook json from workbook/update-to-workbook-1.json to GitHubAdvancedSecurity.json
[x] Workbook -  Rename GithubSecurity.json to GitHubSecurity.json
[x] Data Connector - Webhook Instructions include GitHub Advanced Security specific events
[x] Parser - Rename GithubSecretScanningData to GitHubSecretScanningData - case sensitive in KQL
[x] Logo - Moved the GitHub icon svg into @repo/Logos from
existing location

Publish Step (TODO: review if any of these can be done in json)

SentinelTeam - per our understanding these tasks must be done during publish. Let us know if these updates are needed in repo!
[ ] Content Hub -  Publish workbooks using new naming GitHubSecurity.json and GitHubAdvancedSecurity.json
[ ] Content Hub - Add the GitHub icon svg to both workbooks and the overall solution in the Content hub
[ ] Content Hub - Enhance Description on the content hub for GitHubAdvancedSecurity.json to: Visualize GitHub Advanced Security alerts for Code Scanning, Secret Scanning, and Dependabot.
[ ] Content Hub - Enable Azure Gov flag for deployment
[ ] Connector - Webhook instructions in UI experience (currently deep links to repo doc) - Post Deployment Steps / Step 2 / # 5 ... edit text to be: Subscribe for events (include Code scanning alerts, Repository vulnerability alerts, and Secret scanning alerts)  and Click on "Add Webhook"
[ ] Marketplace - can you confirm this will remain the link to the Sentinel4GitHub solution in both public beta/GA
[ ]  Gallery - is the intention that we have content living @ parsers/hunting/workbooks/detections and inside the GitHub solution or is this best combined?

Reason for Change(s):

Final review of sentinel4github Advanced Security / webhook integration

Version Updated:

N/A

Testing Completed:

N/A

Checked that the validations are passing and have addressed any issues that are present:

N/A

@felickz  Let us know once it is ready for review.

Hi @NikTripathi ready for review here, working with @prtanej  on this one.

Hi @felickz , Workbook.json was added recently by @AlexDeMichieli with PR# https://github.com/Azure/Azure-Sentinel/pull/5764, but I can see in this PR you are removed this workbook file can we proceed with merging this PR?.

Hi @felickz , Workbook.json was added recently by @AlexDeMichieli with PR# #5764, but I can see in this PR you are removed this workbook file can we proceed with merging this PR?.

update-to-workbook-1.json was actually the latest updated version of workbook.json.  In this PR I renamed update-to-workbook-1.json to GitHubAdvancedSecurity.json
Since it was showing up in the content hub as just workbook - we renamed the file to match the expected title in Content Hub.  The display name in the hub should be GitHub Advanced Security


Test Flowzone PR 507

Auto-generated by https://github.com/product-os/flowzone/pull/507
Will be closed automatically once the PR is merged.

Auto-closing pull request


improve traceback logging for workflows

This PR fixes two major annoyances

Exceptions in workflows had their actual tracebacks/code-paths swallowed. While the error was the same, the code path pointed to our dispatcher. This change fixes that
When cancel_run() is used, there is a scary looking tracback printed from the dispatcher. This PR removes that

idk whats up the nebius or why its installing the wrong version of pydantic. Can fix later, unrelated to this PR


What are the reasons for restricting the non-file values in multipart/form-data to only strings?

As mentioned in this post: https://github.com/wkh237/react-native-fetch-blob/issues/151 , non-file form fields are only limited to strings. This means that id's (typically int) won't be able to be uploaded. Is there a reason for this limitation?

Found the answer: https://developer.mozilla.org/en-US/docs/Web/API/FormData/append


TypeScript Object Initializer Syntax

Introduction
I would like to submit this proposal for discussion (and hopefully implementation into the language spec) to introduce object initializer syntax into TypeScript.
Rationale
TypeScript already gives us the ability to create record type classes through syntactic sugar that allows us to declare member variables that can be assigned via the constructor.
class Point {
    constructor(
        public x: number = 0,
        public y: number = 0) {
    }
}

This is really useful, and I find myself using this syntax more often than not, but there are cases where this syntax is not appropriate for an object; granted the example above essentially exposes a default constructor, since all parameters are optional, one could create a point with no arguments.
const point = new Point();

There are however cases where this is not appropriate; we may in some cases want to implement classes where member variables or properties are not set during constructor initialization. Point is actually not a great candidate for this but for argument sake...
class Point {
    public x: number = 0;
    public y: number = 0;

    constructor () {
    }
}

If we wanted to construct a point implemented like the one above, we would currently have to do so like this.
const point = new Point();
point.x = 123;
point.y = 456;

Solution
It would be nice if we had object initializer syntax which would make this a little easier.
const point = new Point() {
    x = 123;
    y = 456;
}

Which would compile to
const point = (function() {
    const point = new Point();
    point.x = 123;
    point.y = 456;
    return point;
})();

Before I Forget
I've read a few articles on alternative ways to do this with TypeScript, but frankly I don't like them, mainly because most of them only specify contractual constraints on object declarations and initialization, but require object literals to do so; my solution ensures that actually, you get back the expected type.
interface IPoint {
    x?: number;
    y?: number;
}

const point: IPoint = {
    x = 123;
}

This would compile, but it doesn't actually give you a Point instance.

This feels like a dupe of #3895 (which is marked as out of scope).

If we wanted to construct a point implemented like the one above, we would currently have to do so like this.
const point = new Point();
point.x = 123;
point.y = 456;

Or you could do this:
class Point {
  constructor (public x: number = 0, public y: number = 0) {}
}

const point = new Point(1, 2);

but frankly I don't like them

For all things like this, you really have to have a compelling reason why you would want to break compatibility with ECMAScript/JavaScript.  Developer convenience doesn't seem like one of those.

const point = new Point() {
    x = 123;
    y = 456;
}

This isn't much more readable than:
const point = new Point({
    x: 123,
    y: 456,
});

That can be accomplished with:
class Point {
    readonly x: number;
    readonly y: number;
    constructor(options: { x: number, y: number }) {
        this.x = options.x;
        this.y = options.y;
    }
}

The advantage of this is that you can make your fields readonly, while with the syntax you propose it seems like they would have to be mutable, even if only intended to be set during initialization. It also gives you a place to do assertions, and lets the initialization options differ from the internal structure of the fields.

Or an even more complete re-implementation which includes the default values:
class Point {
    readonly x: number;
    readonly y: number;
    constructor({ x = 0, y = 0 }: { x?: number, y?: number }) {
        this.x = x;
        this.y = y;
    }
}

const p1 = new Point({ x: 123 });
const p2 = new Point({ y: 256 });

I know this has been closed, but I would request it be re-opened, as there is a compelling reason for this feature which wasn't covered in this thread.
The constructor shorthand, like:
class Point {
    constructor(public x: number, public y: number)
}

is great, in that it avoids a lot of boilerplate, and provides a completeness guarantee. That is, it's guaranteed that every field is explicitly initialized. However, it has a major downside, in that it becomes unwieldy if your class has more than a couple fields. Image this class instead:
class User {
    constructor(
        public name: string,
        public birthday: Date,
        public regdate: Date,
        public social: string,
        public passwordHash: string,
        public isAdmin: bool
    )
}

let myUser = new User(name, regdate, birthday, ssn, hash, false)

I need to break it into multiple lines because it's getting too long! And this is still fairly mild. In real production systems, there are plenty of objects that can have twice that many fields. In order to call this constructor, I need to provide six ordered, unlabeled arguments, some of which are of the same type. In fact, notice the bug here? The regdate and birthday are backwards, which could cause all sorts of subtle bugs.
There was an alternate example provided above which uses a single constructor argument which takes an object with a specified structure. Which would look like this:
class User {
    public name: string,
    public birthday: Date,
    public regdate: Date,
    public social: string,
    public passwordHash: string,
    public isAdmin: bool
    constructor(args: {
        name: string,
        birthday: Date,
        regdate: Date,
        social: string,
        passwordHash: string,
        isAdmin: bool
    }) {
        self.name = args.name
        self.birthday = args.birthday
        self.regdate = args.regdate
        self.social = args.social
        self.passwordHash = args.passwordHash
        self.isAdmin = args.isAdmin
    }
}

let myUser = new User({
    name = name,
    birthday = birthday,
    regdate = regdate,
    social = social,
    passwordHash = passwordHash,
    isAdmin = false
})

The completeness guarantee is still here, which is great, and the initialization is now labeled instead of ordered so it'll be much harder to accidentally mix up arguments of the same type. But the boilerplate is ridiculous!
With a generic object initializer syntax, we can get the best of all words: no boilerplate, completeness guaranteed, and labeled instead of ordered initialization. This example now looks like this:
class User {
    public name: string,
    public birthday: Date,
    public regdate: Date,
    public social: string,
    public passwordHash: string,
    public isAdmin: bool
}

let myUser = new Class() {
    name = name,
    birthday = birthday,
    regdate = regdate,
    social = ssn,
    passwordHash = passwordHash,
    isAdmin = false
}

So much better!
(Note: All of this is assuming this feature comes with a completeness guarantee, i.e. the object initializer must contain every field that's in the object it's initializing, which doesn't have a default value. Without that, this feature has a lot less value. But I see no reason why you wouldn't force completeness on object initializers.)

@Cifram This pattern would work without duplicating the properties:
function init<T>(a: T, b: T): void { Object.assign(a, b) }

interface UserData {
    name: string;
    birthday: Date;
    regdate: Date;
    social: string;
    passwordHash: string;
    isAdmin: boolean;
}
interface User extends UserData {}
class User {
    constructor(data: UserData) {
        init<UserData>(this, data);
    }

    deservesCake() {
        return this.birthday.getDate() == new Date().getDate() || this.isAdmin;
    }
}

Of course, if you don't need to define any methods you could just use an interface directly:
interface User { ... }
const myUser: User = { ... };

That does largely solve the problem, though I think the init function is a little unfortunate.

@andy-ms @Cifram Except if you need to define decorators on your class properties!!

This isn't any more readable than:
const point = new Point({
    x: 123,
    y: 456,
});

That can be accomplished with:
class Point {
    readonly x: number;
    readonly y: number;
    constructor(options: { x: number, y: number }) {
        this.x = options.x;
        this.y = options.y;
    }
}

Or with less typing writing:
class Point {
    readonly x: number;
    readonly y: number;
    constructor(point: Point) {
        this.x = point.x;
        this.y = point.y;
    }
}

Or with much more less writing, but (i think, not tested) slower:
(I mean less writing relative to the number of properties)
class Point {
    readonly x: number;
    readonly y: number;
    constructor(point: Point) {
        Object.keys(point).forEach((key) => this[key] = point[key]);
    }
}

Here is the cleanest version I can think of:
class Greeter {
    greeting: string = this.input.greeting || 'default';
    greeting2?: string = this.input.greeting2;
    constructor(private input: Partial<Greeter>) {}
    greet(): string {
        return this.greeting;
    }
    greet2(): string {
        return this.greeting2 || 'hi';
    }
}
let greeter = new Greeter({ greeting: 'hello' });

The only problem with this is that because the input is a Partial of itself, all the fields are optional. That means you have to handle the default values correctly or make the properties themselves optional. At least this way avoids Object.assign or Object.keys which isn't very Typescript friendly.
Hope this helps.

Not very elegant but preverves default values:
class Point {
  x ?= 0;
  y ?= 0;

  constructor(p: Point) {
      Object.assign(this, p);
  }
}

let p1 = new Point({x: 1}); --> (1,0)
let p2 = new Point({y: 1}); --> (0,1)

When I receive data from my API, it is a JS object, not TypeScript yet. I wish I could do as:
const point= new Point(...data)

Each key would match its proper attribute name.

@Elfayer TypeScript is a structural typing system, because JavaScript is largely structural.  You don't need to apply a nominal constructor to some arbitrary data to have it be that type.  If it is structurally the same, it is that type in TypeScript, irrespective of how it was created.  Don't try to fit a square peg in a round hole.  It will lead to 😭 .

I'm not sure what you mean. I just wish we could have keyword parameters: new Point(x=2, y=3)
And allow such syntax to exist for very long constructors: new Point(...obj)
This is available in Python for example: https://docs.python.org/dev/whatsnew/3.5.html#pep-448-additional-unpacking-generalizations
>>> print(*[1], *[2], 3, *[4, 5])
1 2 3 4 5

>>> def fn(a, b, c, d):
...     print(a, b, c, d)
...

>>> fn(**{'a': 1, 'c': 3}, **{'b': 2, 'd': 4})
1 2 3 4

Because you don't understand what I mean is why you are asking for something that doesn't make sense in TypeScript.
You example again:
const data = { x: 1, y: 1};

interface Point {
    x: number;
    y: number;
}

const point: Point = { ...data };

TypeScript is a structural typing system.  If you wanted a new way to create instances of a class though, you would be best to advocate for this in ECMAScript/JavaScript (https://esdiscuss.org/) and if it got adopted there, TypeScript would follow along.  TypeScript is a (mostly) an erasable type system, not the languages syntax.


Add wheels for mercurual 6.7.4

xref https://github.com/galaxyproject/wheelforge/pull/40/

Duplicate of #40 ?

Yep, just checked wheels but not the repo 😅


camerad: refactor camera_open() into separate functions for clarity

The lengthy camera_open() method was refactored into logical parts, each handling a specific aspect of the camera setup. This change improves clarity and makes the code easier to work with.
Following this PR, we can further refine these functions to improve the robustness and readability of the camera initialization code, as well as clarify the logging.

trigger-jenkins