Enable test_Collision

Fix https://github.com/conda-forge/dartsim-feedstock/issues/39 . This was triggered by https://github.com/conda-forge/gz-physics-feedstock/pull/24#issuecomment-2001998885, even if I do not know how much the two problems are related.
Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Great, this fails, with output:
2024-03-16T16:48:45.3630667Z 35/71 Test #35: test_Collision ....................***Failed    0.38 sec
2024-03-16T16:48:45.3632033Z Running main() from $SRC_DIR/unittests/gtest/src/gtest_main.cc
2024-03-16T16:48:45.3632353Z [==========] Running 17 tests from 1 test case.
2024-03-16T16:48:45.3632887Z [----------] Global test environment set-up.
2024-03-16T16:48:45.3633200Z [----------] 17 tests from Collision
2024-03-16T16:48:45.3633427Z [ RUN      ] Collision.DROP
2024-03-16T16:48:45.3633725Z Dbg Unrotated box
2024-03-16T16:48:45.3633954Z Current position of the object: 0.2499
2024-03-16T16:48:45.3634151Z      0
2024-03-16T16:48:45.3634302Z      0
2024-03-16T16:48:45.3634484Z Number of contacts: 4
2024-03-16T16:48:45.3634726Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3634985Z contact_points: -5e-05
2024-03-16T16:48:45.3635161Z   0.25
2024-03-16T16:48:45.3635331Z   0.25
2024-03-16T16:48:45.3635873Z contact_points(w): 0.24985
2024-03-16T16:48:45.3636073Z    0.25
2024-03-16T16:48:45.3636229Z    0.25
2024-03-16T16:48:45.3636405Z norm: 0.353553
2024-03-16T16:48:45.3636585Z penetration_depth: 0.0001
2024-03-16T16:48:45.3636779Z normal: -1
2024-03-16T16:48:45.3636989Z -0
2024-03-16T16:48:45.3637166Z  0
2024-03-16T16:48:45.3637387Z ----- CONTACT 1 --------
2024-03-16T16:48:45.3637650Z contact_points: -5e-05
2024-03-16T16:48:45.3637825Z   0.25
2024-03-16T16:48:45.3638028Z  -0.25
2024-03-16T16:48:45.3638204Z contact_points(w): 0.24985
2024-03-16T16:48:45.3638395Z    0.25
2024-03-16T16:48:45.3638567Z   -0.25
2024-03-16T16:48:45.3638753Z norm: 0.353553
2024-03-16T16:48:45.3638948Z penetration_depth: 0.0001
2024-03-16T16:48:45.3639126Z normal: -1
2024-03-16T16:48:45.3639331Z -0
2024-03-16T16:48:45.3639484Z  0
2024-03-16T16:48:45.3639716Z ----- CONTACT 2 --------
2024-03-16T16:48:45.3639954Z contact_points: -5e-05
2024-03-16T16:48:45.3640164Z  -0.25
2024-03-16T16:48:45.3640341Z  -0.25
2024-03-16T16:48:45.3640533Z contact_points(w): 0.24985
2024-03-16T16:48:45.3640724Z   -0.25
2024-03-16T16:48:45.3640921Z   -0.25
2024-03-16T16:48:45.3641086Z norm: 0.353553
2024-03-16T16:48:45.3641284Z penetration_depth: 0.0001
2024-03-16T16:48:45.3641460Z normal: -1
2024-03-16T16:48:45.3641668Z -0
2024-03-16T16:48:45.3641820Z  0
2024-03-16T16:48:45.3642787Z ----- CONTACT 3 --------
2024-03-16T16:48:45.3643030Z contact_points: -5e-05
2024-03-16T16:48:45.3643254Z  -0.25
2024-03-16T16:48:45.3643413Z   0.25
2024-03-16T16:48:45.3643608Z contact_points(w): 0.24985
2024-03-16T16:48:45.3643796Z   -0.25
2024-03-16T16:48:45.3643979Z    0.25
2024-03-16T16:48:45.3644133Z norm: 0.353553
2024-03-16T16:48:45.3644325Z penetration_depth: 0.0001
2024-03-16T16:48:45.3644518Z normal: -1
2024-03-16T16:48:45.3644893Z -0
2024-03-16T16:48:45.3645071Z  0
2024-03-16T16:48:45.3645163Z
2024-03-16T16:48:45.3645342Z Current position of the object:      0
2024-03-16T16:48:45.3645546Z 0.2499
2024-03-16T16:48:45.3645697Z      0
2024-03-16T16:48:45.3645881Z Number of contacts: 4
2024-03-16T16:48:45.3646121Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3646337Z contact_points:   0.25
2024-03-16T16:48:45.3646544Z -5e-05
2024-03-16T16:48:45.3646727Z   0.25
2024-03-16T16:48:45.3646921Z contact_points(w):    0.25
2024-03-16T16:48:45.3647398Z 0.24985
2024-03-16T16:48:45.3647578Z    0.25
2024-03-16T16:48:45.3647750Z norm: 0.353553
2024-03-16T16:48:45.3647952Z penetration_depth: 0.0001
2024-03-16T16:48:45.3648135Z normal: -0
2024-03-16T16:48:45.3648357Z -1
2024-03-16T16:48:45.3648546Z -0
2024-03-16T16:48:45.3648827Z ----- CONTACT 1 --------
2024-03-16T16:48:45.3650082Z contact_points:   0.25
2024-03-16T16:48:45.3650497Z -5e-05
2024-03-16T16:48:45.3650695Z  -0.25
2024-03-16T16:48:45.3650898Z contact_points(w):    0.25
2024-03-16T16:48:45.3651075Z 0.24985
2024-03-16T16:48:45.3651358Z   -0.25
2024-03-16T16:48:45.3651531Z norm: 0.353553
2024-03-16T16:48:45.3651843Z penetration_depth: 0.0001
2024-03-16T16:48:45.3652018Z normal: -0
2024-03-16T16:48:45.3652227Z -1
2024-03-16T16:48:45.3652411Z -0
2024-03-16T16:48:45.3652661Z ----- CONTACT 2 --------
2024-03-16T16:48:45.3652935Z contact_points:  -0.25
2024-03-16T16:48:45.3653402Z -5e-05
2024-03-16T16:48:45.3653655Z  -0.25
2024-03-16T16:48:45.3654011Z contact_points(w):   -0.25
2024-03-16T16:48:45.3654328Z 0.24985
2024-03-16T16:48:45.3654507Z   -0.25
2024-03-16T16:48:45.3654702Z norm: 0.353553
2024-03-16T16:48:45.3654886Z penetration_depth: 0.0001
2024-03-16T16:48:45.3655080Z normal: -0
2024-03-16T16:48:45.3655453Z -1
2024-03-16T16:48:45.3655662Z -0
2024-03-16T16:48:45.3655887Z ----- CONTACT 3 --------
2024-03-16T16:48:45.3656134Z contact_points:  -0.25
2024-03-16T16:48:45.3656349Z -5e-05
2024-03-16T16:48:45.3656532Z   0.25
2024-03-16T16:48:45.3656736Z contact_points(w):   -0.25
2024-03-16T16:48:45.3656938Z 0.24985
2024-03-16T16:48:45.3657095Z    0.25
2024-03-16T16:48:45.3657423Z norm: 0.353553
2024-03-16T16:48:45.3657679Z penetration_depth: 0.0001
2024-03-16T16:48:45.3657877Z normal: -0
2024-03-16T16:48:45.3658064Z -1
2024-03-16T16:48:45.3658271Z -0
2024-03-16T16:48:45.3658359Z
2024-03-16T16:48:45.3658556Z Current position of the object:      0
2024-03-16T16:48:45.3658735Z      0
2024-03-16T16:48:45.3658903Z 0.2499
2024-03-16T16:48:45.3659173Z Number of contacts: 4
2024-03-16T16:48:45.3659435Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3659629Z contact_points:   0.25
2024-03-16T16:48:45.3659825Z   0.25
2024-03-16T16:48:45.3661435Z -5e-05
2024-03-16T16:48:45.3662147Z contact_points(w):    0.25
2024-03-16T16:48:45.3662321Z    0.25
2024-03-16T16:48:45.3662477Z 0.24985
2024-03-16T16:48:45.3662617Z norm: 0.353553
2024-03-16T16:48:45.3662791Z penetration_depth: 0.0001
2024-03-16T16:48:45.3662943Z normal: -0
2024-03-16T16:48:45.3663140Z -0
2024-03-16T16:48:45.3663314Z -1
2024-03-16T16:48:45.3663505Z ----- CONTACT 1 --------
2024-03-16T16:48:45.3663687Z contact_points:   0.25
2024-03-16T16:48:45.3664023Z  -0.25
2024-03-16T16:48:45.3664208Z -5e-05
2024-03-16T16:48:45.3664361Z contact_points(w):    0.25
2024-03-16T16:48:45.3664552Z   -0.25
2024-03-16T16:48:45.3664690Z 0.24985
2024-03-16T16:48:45.3664850Z norm: 0.353553
2024-03-16T16:48:45.3665783Z penetration_depth: 0.0001
2024-03-16T16:48:45.3666571Z normal: -0
2024-03-16T16:48:45.3666811Z -0
2024-03-16T16:48:45.3667026Z -1
2024-03-16T16:48:45.3667260Z ----- CONTACT 2 --------
2024-03-16T16:48:45.3667499Z contact_points:  -0.25
2024-03-16T16:48:45.3668027Z  -0.25
2024-03-16T16:48:45.3668243Z -5e-05
2024-03-16T16:48:45.3668442Z contact_points(w):   -0.25
2024-03-16T16:48:45.3668810Z   -0.25
2024-03-16T16:48:45.3669104Z 0.24985
2024-03-16T16:48:45.3669252Z norm: 0.353553
2024-03-16T16:48:45.3669398Z penetration_depth: 0.0001
2024-03-16T16:48:45.3669569Z normal: -0
2024-03-16T16:48:45.3669717Z -0
2024-03-16T16:48:45.3669888Z -1
2024-03-16T16:48:45.3670085Z ----- CONTACT 3 --------
2024-03-16T16:48:45.3670262Z contact_points:  -0.25
2024-03-16T16:48:45.3670421Z   0.25
2024-03-16T16:48:45.3670776Z -5e-05
2024-03-16T16:48:45.3670966Z contact_points(w):   -0.25
2024-03-16T16:48:45.3671116Z    0.25
2024-03-16T16:48:45.3671259Z 0.24985
2024-03-16T16:48:45.3671391Z norm: 0.353553
2024-03-16T16:48:45.3671557Z penetration_depth: 0.0001
2024-03-16T16:48:45.3671704Z normal: -0
2024-03-16T16:48:45.3671877Z -0
2024-03-16T16:48:45.3672183Z -1
2024-03-16T16:48:45.3672452Z
2024-03-16T16:48:45.3672649Z Dbg Rotated box
2024-03-16T16:48:45.3672839Z Current position of the object: 0.4221
2024-03-16T16:48:45.3673142Z      0
2024-03-16T16:48:45.3673281Z      0
2024-03-16T16:48:45.3673418Z Number of contacts: 1
2024-03-16T16:48:45.3673630Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3673844Z contact_points: -6.55532e-06
2024-03-16T16:48:45.3674054Z   -0.0962696
2024-03-16T16:48:45.3674232Z  -0.00725903
2024-03-16T16:48:45.3674403Z contact_points(w):  0.464225
2024-03-16T16:48:45.3674754Z 0.0853712
2024-03-16T16:48:45.3674942Z -0.016054
2024-03-16T16:48:45.3675088Z norm: 0.0965428
2024-03-16T16:48:45.3675266Z penetration_depth: 1.31106e-05
2024-03-16T16:48:45.3728878Z normal: -1
2024-03-16T16:48:45.3731358Z -0
2024-03-16T16:48:45.3731639Z -0
2024-03-16T16:48:45.3731771Z
2024-03-16T16:48:45.3731957Z Current position of the object:      0
2024-03-16T16:48:45.3732166Z 0.3611
2024-03-16T16:48:45.3732324Z      0
2024-03-16T16:48:45.3732513Z Number of contacts: 1
2024-03-16T16:48:45.3732785Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3736188Z contact_points:     0.229274
2024-03-16T16:48:45.3736574Z -2.12223e-05
2024-03-16T16:48:45.3736789Z    0.0671534
2024-03-16T16:48:45.3737026Z contact_points(w): -0.187188
2024-03-16T16:48:45.3737232Z  0.422332
2024-03-16T16:48:45.3737430Z  -0.13523
2024-03-16T16:48:45.3737625Z norm: 0.238906
2024-03-16T16:48:45.3737804Z penetration_depth: 4.24446e-05
2024-03-16T16:48:45.3738009Z normal: -0
2024-03-16T16:48:45.3738213Z -1
2024-03-16T16:48:45.3738398Z -0
2024-03-16T16:48:45.3738483Z
2024-03-16T16:48:45.3738680Z Current position of the object:      0
2024-03-16T16:48:45.3738856Z      0
2024-03-16T16:48:45.3739029Z 0.3789
2024-03-16T16:48:45.3739191Z Number of contacts: 1
2024-03-16T16:48:45.3739444Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3739641Z contact_points:     0.114592
2024-03-16T16:48:45.3739837Z     0.175342
2024-03-16T16:48:45.3740038Z -3.86478e-05
2024-03-16T16:48:45.3740299Z contact_points(w): -0.138078
2024-03-16T16:48:45.3740546Z -0.142299
2024-03-16T16:48:45.3740711Z   0.31136
2024-03-16T16:48:45.3740894Z norm: 0.209466
2024-03-16T16:48:45.3741076Z penetration_depth: 7.72955e-05
2024-03-16T16:48:45.3743400Z normal: -0
2024-03-16T16:48:45.3743715Z -0
2024-03-16T16:48:45.3743930Z -1
2024-03-16T16:48:45.3744017Z
2024-03-16T16:48:45.3744222Z Current position of the object: 0.2737
2024-03-16T16:48:45.3744427Z      0
2024-03-16T16:48:45.3746618Z      0
2024-03-16T16:48:45.3746844Z Number of contacts: 2
2024-03-16T16:48:45.3747150Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3747415Z contact_points: -4.69774e-06
2024-03-16T16:48:45.3747730Z        -0.25
2024-03-16T16:48:45.3747936Z    -0.223793
2024-03-16T16:48:45.3748193Z contact_points(w):  0.251353
2024-03-16T16:48:45.3748410Z     -0.25
2024-03-16T16:48:45.3753434Z -0.222674
2024-03-16T16:48:45.3753916Z norm: 0.335534
2024-03-16T16:48:45.3754867Z penetration_depth: 9.39547e-06
2024-03-16T16:48:45.3876157Z normal: -1
2024-03-16T16:48:45.3877116Z -0
2024-03-16T16:48:45.3877482Z -0
2024-03-16T16:48:45.3877742Z ----- CONTACT 1 --------
2024-03-16T16:48:45.3878733Z contact_points: -4.69774e-06
2024-03-16T16:48:45.3879020Z         0.25
2024-03-16T16:48:45.3879327Z    -0.223793
2024-03-16T16:48:45.3879585Z contact_points(w):  0.251353
2024-03-16T16:48:45.3879801Z      0.25
2024-03-16T16:48:45.3880068Z -0.222674
2024-03-16T16:48:45.3880283Z norm: 0.335534
2024-03-16T16:48:45.3880573Z penetration_depth: 9.39547e-06
2024-03-16T16:48:45.3880838Z normal: -1
2024-03-16T16:48:45.3881091Z -0
2024-03-16T16:48:45.3881572Z -0
2024-03-16T16:48:45.3881831Z
2024-03-16T16:48:45.3882014Z Current position of the object:      0
2024-03-16T16:48:45.3883184Z 0.2499
2024-03-16T16:48:45.3883612Z      0
2024-03-16T16:48:45.3883852Z Number of contacts: 4
2024-03-16T16:48:45.3884165Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3884404Z contact_points: 0.273709
2024-03-16T16:48:45.3884703Z   -5e-05
2024-03-16T16:48:45.3884929Z 0.223793
2024-03-16T16:48:45.3885173Z contact_points(w): 0.294684
2024-03-16T16:48:45.3885710Z  0.24985
2024-03-16T16:48:45.3885905Z 0.195349
2024-03-16T16:48:45.3886183Z norm: 0.353553
2024-03-16T16:48:45.3886387Z penetration_depth: 0.0001
2024-03-16T16:48:45.3886656Z normal: -0
2024-03-16T16:48:45.3886887Z -1
2024-03-16T16:48:45.3887082Z -0
2024-03-16T16:48:45.3887394Z ----- CONTACT 1 --------
2024-03-16T16:48:45.3887596Z contact_points:  0.223793
2024-03-16T16:48:45.3887832Z    -5e-05
2024-03-16T16:48:45.3888149Z -0.273709
2024-03-16T16:48:45.3888460Z contact_points(w):  0.195349
2024-03-16T16:48:45.3888643Z   0.24985
2024-03-16T16:48:45.3888880Z -0.294684
2024-03-16T16:48:45.3889054Z norm: 0.353553
2024-03-16T16:48:45.3889260Z penetration_depth: 0.0001
2024-03-16T16:48:45.3889439Z normal: -0
2024-03-16T16:48:45.3889648Z -1
2024-03-16T16:48:45.3889834Z -0
2024-03-16T16:48:45.3890088Z ----- CONTACT 2 --------
2024-03-16T16:48:45.3890339Z contact_points: -0.273709
2024-03-16T16:48:45.3890633Z    -5e-05
2024-03-16T16:48:45.3890864Z -0.223793
2024-03-16T16:48:45.3891114Z contact_points(w): -0.294684
2024-03-16T16:48:45.3891328Z   0.24985
2024-03-16T16:48:45.3891541Z -0.195349
2024-03-16T16:48:45.3891731Z norm: 0.353553
2024-03-16T16:48:45.3891914Z penetration_depth: 0.0001
2024-03-16T16:48:45.3892114Z normal: -0
2024-03-16T16:48:45.3892305Z -1
2024-03-16T16:48:45.3892516Z -0
2024-03-16T16:48:45.3892745Z ----- CONTACT 3 --------
2024-03-16T16:48:45.3893017Z contact_points: -0.223793
2024-03-16T16:48:45.3893240Z    -5e-05
2024-03-16T16:48:45.3893429Z  0.273709
2024-03-16T16:48:45.3893669Z contact_points(w): -0.195349
2024-03-16T16:48:45.3893877Z   0.24985
2024-03-16T16:48:45.3894034Z  0.294684
2024-03-16T16:48:45.3894221Z norm: 0.353553
2024-03-16T16:48:45.3894400Z penetration_depth: 0.0001
2024-03-16T16:48:45.3894600Z normal: -0
2024-03-16T16:48:45.3894972Z -1
2024-03-16T16:48:45.3895176Z -0
2024-03-16T16:48:45.3895263Z
2024-03-16T16:48:45.3895454Z Current position of the object:      0
2024-03-16T16:48:45.3895628Z      0
2024-03-16T16:48:45.3895795Z 0.2737
2024-03-16T16:48:45.3895959Z Number of contacts: 2
2024-03-16T16:48:45.3896219Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3896417Z contact_points:     0.223793
2024-03-16T16:48:45.3896609Z         0.25
2024-03-16T16:48:45.3896813Z -4.69774e-06
2024-03-16T16:48:45.3897017Z contact_points(w): 0.222674
2024-03-16T16:48:45.3897186Z     0.25
2024-03-16T16:48:45.3897360Z 0.251353
2024-03-16T16:48:45.3898566Z norm: 0.335534
2024-03-16T16:48:45.3898801Z penetration_depth: 9.39547e-06
2024-03-16T16:48:45.3899014Z normal: -0
2024-03-16T16:48:45.3899258Z -0
2024-03-16T16:48:45.3899471Z -1
2024-03-16T16:48:45.3899693Z ----- CONTACT 1 --------
2024-03-16T16:48:45.3899912Z contact_points:     0.223793
2024-03-16T16:48:45.3900112Z        -0.25
2024-03-16T16:48:45.3901465Z -4.69774e-06
2024-03-16T16:48:45.3901867Z contact_points(w): 0.222674
2024-03-16T16:48:45.3902170Z    -0.25
2024-03-16T16:48:45.3902342Z 0.251353
2024-03-16T16:48:45.3902530Z norm: 0.335534
2024-03-16T16:48:45.3902712Z penetration_depth: 9.39547e-06
2024-03-16T16:48:45.3902917Z normal: -0
2024-03-16T16:48:45.3903111Z -0
2024-03-16T16:48:45.3903315Z -1
2024-03-16T16:48:45.3903661Z
2024-03-16T16:48:45.3903872Z [       OK ] Collision.DROP (128 ms)
2024-03-16T16:48:45.3904074Z [ RUN      ] Collision.FCL_BOX_BOX
2024-03-16T16:48:45.3904290Z Current position of the object:       0
2024-03-16T16:48:45.3904465Z       0
2024-03-16T16:48:45.3904632Z 0.37107
2024-03-16T16:48:45.3904798Z Number of contacts: 1
2024-03-16T16:48:45.3905305Z ----- CONTACT 0 --------
2024-03-16T16:48:45.3905559Z contact_points:    -0.197346
2024-03-16T16:48:45.3905761Z     0.104184
2024-03-16T16:48:45.3907503Z -4.75131e-06
2024-03-16T16:48:45.3907880Z penetration_depth: 9.50262e-06
2024-03-16T16:48:45.3908072Z normal: -0
2024-03-16T16:48:45.3908296Z -0
2024-03-16T16:48:45.3908477Z -1
2024-03-16T16:48:45.3908685Z [       OK ] Collision.FCL_BOX_BOX (78 ms)
2024-03-16T16:48:45.3908909Z [ RUN      ] Collision.SimpleFrames
2024-03-16T16:48:45.3909113Z [       OK ] Collision.SimpleFrames (31 ms)
2024-03-16T16:48:45.3909333Z [ RUN      ] Collision.SphereSphere
2024-03-16T16:48:45.3909738Z point: 0 0 0
2024-03-16T16:48:45.3909993Z point: -1  0  0
2024-03-16T16:48:45.3910167Z point: 0 0 0
2024-03-16T16:48:45.3910378Z [       OK ] Collision.SphereSphere (4 ms)
2024-03-16T16:48:45.3910574Z [ RUN      ] Collision.BoxBox
2024-03-16T16:48:45.3911294Z [       OK ] Collision.BoxBox (10 ms)
2024-03-16T16:48:45.3911512Z [ RUN      ] Collision.testCylinderCylinder
2024-03-16T16:48:45.3911803Z $SRC_DIR/unittests/integration/test_Collision.cpp:754: Failure
2024-03-16T16:48:45.3912130Z Value of: group->collide(option, &result)
2024-03-16T16:48:45.3912356Z   Actual: false
2024-03-16T16:48:45.3912544Z Expected: true
2024-03-16T16:48:45.3912771Z $SRC_DIR/unittests/integration/test_Collision.cpp:755: Failure
2024-03-16T16:48:45.3913034Z Value of: result.getNumContacts() >= 1u
2024-03-16T16:48:45.3913228Z   Actual: false
2024-03-16T16:48:45.3913415Z Expected: true
2024-03-16T16:48:45.3913620Z [  FAILED  ] Collision.testCylinderCylinder (12 ms)
2024-03-16T16:48:45.3913860Z [ RUN      ] Collision.testConeCone
2024-03-16T16:48:45.3914918Z Warning [FCLCollisionDetector.cpp:814] [FCLCollisionDetector::setContactPointComputationMethod] You chose to use FCL's built in contact point computation whileit's buggy (see https://github.com/flexible-collision-library/fcl/issues/106) at least until 0.4.0. It's recommended to use DART's implementation for the contact point computation by setting FCLCollisionDetector::setContactPointComputationMethod(DART).
2024-03-16T16:48:45.3917566Z Warning [FCLCollisionDetector.cpp:790] [FCLCollisionDetector::setPrimitiveShapeType] You chose to use FCL's primitive shape collision feature while it's not complete (at least until 0.4.0) especially in use of dynamics simulation. It's recommended to use mesh even for primitive shapes by settting FCLCollisionDetector::setPrimitiveShapeType(MESH).
2024-03-16T16:48:45.3919117Z Warning [FCLCollisionDetector.cpp:790] [FCLCollisionDetector::setPrimitiveShapeType] You chose to use FCL's primitive shape collision feature while it's not complete (at least until 0.4.0) especially in use of dynamics simulation. It's recommended to use mesh even for primitive shapes by settting FCLCollisionDetector::setPrimitiveShapeType(MESH).
2024-03-16T16:48:45.3920556Z Warning [FCLCollisionDetector.cpp:814] [FCLCollisionDetector::setContactPointComputationMethod] You chose to use FCL's built in contact point computation whileit's buggy (see https://github.com/flexible-collision-library/fcl/issues/106) at least until 0.4.0. It's recommended to use DART's implementation for the contact point computation by setting FCLCollisionDetector::setContactPointComputationMethod(DART).
2024-03-16T16:48:45.3921227Z $SRC_DIR/unittests/integration/test_Collision.cpp:754: Failure
2024-03-16T16:48:45.3921545Z Value of: group->collide(option, &result)
2024-03-16T16:48:45.3921774Z   Actual: false
2024-03-16T16:48:45.3921970Z Expected: true
2024-03-16T16:48:45.3922196Z $SRC_DIR/unittests/integration/test_Collision.cpp:755: Failure
2024-03-16T16:48:45.3922459Z Value of: result.getNumContacts() >= 1u
2024-03-16T16:48:45.3922912Z   Actual: false
2024-03-16T16:48:45.3923110Z Expected: true
2024-03-16T16:48:45.3923488Z [  FAILED  ] Collision.testConeCone (33 ms)
2024-03-16T16:48:45.3923713Z [ RUN      ] Collision.testCapsuleCapsule
2024-03-16T16:48:45.3923921Z [       OK ] Collision.testCapsuleCapsule (1 ms)
2024-03-16T16:48:45.3924156Z [ RUN      ] Collision.testPlane
2024-03-16T16:48:45.3924351Z [       OK ] Collision.testPlane (0 ms)
2024-03-16T16:48:45.3924570Z [ RUN      ] Collision.testHeightmapBox
2024-03-16T16:48:45.3924848Z Dbg Testing ODE (float)
2024-03-16T16:48:45.3925247Z Dbg ODE Heightfield AABB: min = {-1, -1, -2.22045e-16} max = {1, 1, 6}
2024-03-16T16:48:45.3925564Z Dbg Testing ODE (double)
2024-03-16T16:48:45.3925911Z Dbg ODE Heightfield AABB: min = {-1, -1, -2.22045e-16} max = {1, 1, 6}
2024-03-16T16:48:45.3926230Z Dbg Testing Bullet (float)
2024-03-16T16:48:45.3926887Z Dbg DART Bullet heightfield AABB: min = {-1, -1, -2}, max = {1, 1, 2} (will be translated by z=4)
2024-03-16T16:48:45.3927186Z [       OK ] Collision.testHeightmapBox (1 ms)
2024-03-16T16:48:45.3927392Z [ RUN      ] Collision.testHeightmapFlipY
2024-03-16T16:48:45.3927621Z [       OK ] Collision.testHeightmapFlipY (1 ms)
2024-03-16T16:48:45.3927835Z [ RUN      ] Collision.Options
2024-03-16T16:48:45.3928027Z [       OK ] Collision.Options (2 ms)
2024-03-16T16:48:45.3928233Z [ RUN      ] Collision.Filter
2024-03-16T16:48:45.3928744Z Msg [NameManager::issueNewName] (Skeleton::BodyNode | Skeleton) The name [BodyNode] is a duplicate, so it has been renamed to [BodyNode(1)]
2024-03-16T16:48:45.3929439Z Msg [NameManager::issueNewName] (Skeleton::Joint | Skeleton) The name [Joint] is a duplicate, so it has been renamed to [Joint(1)]
2024-03-16T16:48:45.3930006Z Msg [NameManager::issueNewName] (Skeleton::BodyNode | Skeleton) The name [BodyNode] is a duplicate, so it has been renamed to [BodyNode(1)]
2024-03-16T16:48:45.3930596Z Msg [NameManager::issueNewName] (Skeleton::Joint | Skeleton) The name [Joint] is a duplicate, so it has been renamed to [Joint(1)]
2024-03-16T16:48:45.3931190Z Msg [NameManager::issueNewName] (Skeleton::BodyNode | Skeleton) The name [BodyNode] is a duplicate, so it has been renamed to [BodyNode(1)]
2024-03-16T16:48:45.3931747Z Msg [NameManager::issueNewName] (Skeleton::Joint | Skeleton) The name [Joint] is a duplicate, so it has been renamed to [Joint(1)]
2024-03-16T16:48:45.3932066Z [       OK ] Collision.Filter (3 ms)
2024-03-16T16:48:45.3932302Z [ RUN      ] Collision.CreateCollisionGroupFromVariousObject
2024-03-16T16:48:45.3932787Z Msg [NameManager::issueNewName] (World::Skeleton | world) The name [Skeleton] is a duplicate, so it has been renamed to [Skeleton(1)]
2024-03-16T16:48:45.3933363Z Msg [NameManager::issueNewName] (World::Skeleton | world) The name [Skeleton] is a duplicate, so it has been renamed to [Skeleton(1)]
2024-03-16T16:48:45.3933923Z Msg [NameManager::issueNewName] (World::Skeleton | world) The name [Skeleton] is a duplicate, so it has been renamed to [Skeleton(1)]
2024-03-16T16:48:45.3934269Z [       OK ] Collision.CreateCollisionGroupFromVariousObject (38 ms)
2024-03-16T16:48:45.3934525Z [ RUN      ] Collision.CollisionOfPrescribedJoints
2024-03-16T16:48:45.3935010Z Warning [GenericJoint.hpp:335] [GenericJoint::setCommand] Attempting to set a non-zero (-1.5708) command for a PASSIVE joint [joint 1].
2024-03-16T16:48:45.3935605Z Warning [GenericJoint.hpp:335] [GenericJoint::setCommand] Attempting to set a non-zero (-1.5708) command for a PASSIVE joint [joint 1].
2024-03-16T16:48:45.3936193Z Warning [GenericJoint.hpp:375] [GenericJoint::setCommand] Attempting to set a non-zero (-0.0015708) command for a LOCKED joint [joint 1].
2024-03-16T16:48:45.3936769Z Warning [GenericJoint.hpp:335] [GenericJoint::setCommand] Attempting to set a non-zero (-1.57079) command for a PASSIVE joint [joint 1].
2024-03-16T16:48:45.3937538Z Warning [GenericJoint.hpp:375] [GenericJoint::setCommand] Attempting to set a non-zero (-0.00314159) command for a LOCKED joint [joint 1].
2024-03-16T16:48:45.3938142Z Warning [GenericJoint.hpp:335] [GenericJoint::setCommand] Attempting to set a non-zero (-1.57079) command for a PASSIVE joint [joint 1].
2024-03-16T16:48:45.3938724Z Warning [GenericJoint.hpp:375] [GenericJoint::setCommand] Attempting to set a non-zero (-0.00471238) command for a LOCKED joint [joint 1].
2024-03-16T16:48:45.3939323Z Warning [GenericJoint.hpp:335] [GenericJoint::setCommand] Attempting to set a non-zero (-1.57078) command for a PASSIVE joint [joint 1].
2024-03-16T16:48:45.3939919Z Warning [GenericJoint.hpp:375] [GenericJoint::setCommand] Attempting to set a non-zero (-0.00628317) command for a LOCKED joint [joint 1].
2024-03-16T16:48:45.3940308Z [       OK ] Collision.CollisionOfPrescribedJoints (4 ms)
2024-03-16T16:48:45.3940865Z [ RUN      ] Collision.Factory
2024-03-16T16:48:45.3941065Z [       OK ] Collision.Factory (0 ms)
2024-03-16T16:48:45.3941285Z [ RUN      ] Collision.VoxelGrid
2024-03-16T16:48:45.3941485Z [       OK ] Collision.VoxelGrid (2 ms)
2024-03-16T16:48:45.3941829Z [----------] 17 tests from Collision (348 ms total)
2024-03-16T16:48:45.3941968Z
2024-03-16T16:48:45.3942246Z [----------] Global test environment tear-down
2024-03-16T16:48:45.3942488Z [==========] 17 tests from 1 test case ran. (348 ms total)
2024-03-16T16:48:45.3942721Z [  PASSED  ] 15 tests.
2024-03-16T16:48:45.3942915Z [  FAILED  ] 2 tests, listed below:
2024-03-16T16:48:45.3943144Z [  FAILED  ] Collision.testCylinderCylinder
2024-03-16T16:48:45.3943354Z [  FAILED  ] Collision.testConeCone
2024-03-16T16:48:45.3943483Z
2024-03-16T16:48:45.3943642Z  2 FAILED TESTS

And what fails is a test related to Cylinder/Cylinder contact, that is exactly the kind of contact that is not working in https://github.com/conda-forge/gz-physics-feedstock/pull/24#issuecomment-2001998885 .

Indeed, there are some prints related to this:
2024-03-16T16:48:45.3914918Z �[1;33mWarning [FCLCollisionDetector.cpp:814]�[0m [FCLCollisionDetector::setContactPointComputationMethod] You chose to use FCL's built in contact point computation whileit's buggy (see https://github.com/flexible-collision-library/fcl/issues/106) at least until 0.4.0. It's recommended to use DART's implementation for the contact point computation by setting FCLCollisionDetector::setContactPointComputationMethod(DART).
2024-03-16T16:48:45.3917566Z �[1;33mWarning [FCLCollisionDetector.cpp:790]�[0m [FCLCollisionDetector::setPrimitiveShapeType] You chose to use FCL's primitive shape collision feature while it's not complete (at least until 0.4.0) especially in use of dynamics simulation. It's recommended to use mesh even for primitive shapes by settting FCLCollisionDetector::setPrimitiveShapeType(MESH).
2024-03-16T16:48:45.3919117Z �[1;33mWarning [FCLCollisionDetector.cpp:790]�[0m [FCLCollisionDetector::setPrimitiveShapeType] You chose to use FCL's primitive shape collision feature while it's not complete (at least until 0.4.0) especially in use of dynamics simulation. It's recommended to use mesh even for primitive shapes by settting FCLCollisionDetector::setPrimitiveShapeType(MESH).
2024-03-16T16:48:45.3920556Z �[1;33mWarning [FCLCollisionDetector.cpp:814]�[0m [FCLCollisionDetector::setContactPointComputationMethod] You chose to use FCL's built in contact point computation whileit's buggy (see https://github.com/flexible-collision-library/fcl/issues/106) at least until 0.4.0. It's recommended to use DART's implementation for the contact point computation by setting FCLCollisionDetector::setContactPointComputationMethod(DART).

that links an issue that is still open in FCL: https://github.com/flexible-collision-library/fcl/issues/106 . Perhaps we should change some setting of which collision handler to use? Even if as far as I know we are not changing anything.

Interestingly, the same tests seems to have been disabled upstream: https://github.com/dartsim/dart/commit/a6f8a9417860005b912d30e9014395c4e44b511a .

I modified the test to run locally and to be explicit w.r.t. to which collision detector is failing the test, and indeed it turns out that the problem is with the ODE collision detector, that is the one used by default in gz-physics/gz-sim. I have renamed the title of https://github.com/conda-forge/dartsim-feedstock/issues/39 to be more explicit on the problem that the issue is tracking.

This should be now fixed by:

https://github.com/conda-forge/libode-feedstock/pull/22
https://github.com/conda-forge/libode-feedstock/pull/23

Great, now all the failures on Linux/macOS are done, we anyhow still have a Windows failure:
2024-03-19T14:51:58.4765666Z [ RUN      ] Collision.SphereSphere
2024-03-19T14:51:58.4766124Z %SRC_DIR%\unittests\integration\test_Collision.cpp(456): error: Value of: result.getNumContacts() == 1u
2024-03-19T14:51:58.4766630Z   Actual: false
2024-03-19T14:51:58.4766992Z Expected: true
2024-03-19T14:51:58.4767623Z %SRC_DIR%\unittests\integration\test_Collision.cpp(461): error: Value of: contact.point.isApprox(Eigen::Vector3d::UnitX(), tol)
2024-03-19T14:51:58.4768170Z   Actual: false
2024-03-19T14:51:58.4768549Z Expected: true
2024-03-19T14:51:58.4769331Z point: 0 0 0
2024-03-19T14:51:58.4769979Z point: -1  0  0
2024-03-19T14:51:58.4770880Z point: 0 0 0
2024-03-19T14:51:58.4771305Z [  FAILED  ] Collision.SphereSphere (4 ms)

Not sure if this is related to ODE or not.

Perhaps related: https://github.com/dartsim/dart/issues/876 .

Great, now all the failures on Linux/macOS are done, we anyhow still have a Windows failure that anyhow is different from previous failures:
2024-03-19T14:51:58.4765666Z [ RUN      ] Collision.SphereSphere
2024-03-19T14:51:58.4766124Z %SRC_DIR%\unittests\integration\test_Collision.cpp(456): error: Value of: result.getNumContacts() == 1u
2024-03-19T14:51:58.4766630Z   Actual: false
2024-03-19T14:51:58.4766992Z Expected: true
2024-03-19T14:51:58.4767623Z %SRC_DIR%\unittests\integration\test_Collision.cpp(461): error: Value of: contact.point.isApprox(Eigen::Vector3d::UnitX(), tol)
2024-03-19T14:51:58.4768170Z   Actual: false
2024-03-19T14:51:58.4768549Z Expected: true
2024-03-19T14:51:58.4769331Z point: 0 0 0
2024-03-19T14:51:58.4769979Z point: -1  0  0
2024-03-19T14:51:58.4770880Z point: 0 0 0
2024-03-19T14:51:58.4771305Z [  FAILED  ] Collision.SphereSphere (4 ms)

Not sure if this is related to ODE or not.

I opened https://github.com/conda-forge/dartsim-feedstock/issues/63 to track this. In the meanwhile we can at least enable the collision test on Linux/macOS.


better messages in .sign(). updates bundle

Coverage increased (+0.03%) to 94.678% when pulling 5b64d9a700f71de70f563b5518d496227396e9f3 on matiu:messages-in-sign into 1de97bb4018d8d728e5ba3a6e439c227a434558c on bitpay:master.

Coverage decreased (-0.002%) to 94.649% when pulling ccac61e4bcc6585637906d07161822dfe313f3db on matiu:messages-in-sign into 1de97bb4018d8d728e5ba3a6e439c227a434558c on bitpay:master.

Coverage decreased (-0.002%) to 94.649% when pulling f1cc018f864986de94e31093305a775d8bf77332 on matiu:messages-in-sign into 1de97bb4018d8d728e5ba3a6e439c227a434558c on bitpay:master.

Coverage decreased (-0.006%) to 94.646% when pulling 11d535263bda575df881b29cbb9125ba2ce155d2 on matiu:messages-in-sign into 1de97bb4018d8d728e5ba3a6e439c227a434558c on bitpay:master.

Coverage decreased (-0.006%) to 94.646% when pulling 959aff8e8f142f2287e5bcd0e990225b023dc7a0 on matiu:messages-in-sign into 1de97bb4018d8d728e5ba3a6e439c227a434558c on bitpay:master.

updated

Coverage decreased (-0.006%) to 94.676% when pulling cbd05704fd5df1009b71326f661531292c944109 on matiu:messages-in-sign into c0e55798bcb62c3b32d9131270b8406e30d673a5 on bitpay:master.

Coverage decreased (-0.006%) to 94.676% when pulling cbd05704fd5df1009b71326f661531292c944109 on matiu:messages-in-sign into c0e55798bcb62c3b32d9131270b8406e30d673a5 on bitpay:master.


Commisioning issue with android CHIP-tool (CON-284)

Hi.
I am unable to commison the device using the Android CHIP-tool. I am however, able to commsion using google home.
Using a ESP32S3 with the ZAP-light example, the same issue remains on the other examples aswell.
I (24) boot: ESP-IDF v4.4.3-dirty 2nd stage bootloader
I (25) boot: compile time 02:00:20
I (25) boot: chip revision: 0
I (27) boot.esp32s3: Boot SPI Speed : 80MHz
I (32) boot.esp32s3: SPI Mode       : DIO
I (36) boot.esp32s3: SPI Flash Size : 4MB
I (41) boot: Enabling RNG early entropy source...
I (46) boot: Partition Table:
I (50) boot: ## Label            Usage          Type ST Offset   Length
I (57) boot:  0 sec_cert         unknown          3f 06 0000d000 00003000
I (65) boot:  1 nvs              WiFi data        01 02 00010000 00006000
I (72) boot:  2 otadata          OTA data         01 00 00016000 00002000
I (80) boot:  3 phy_init         RF data          01 01 00018000 00001000
I (87) boot:  4 ota_0            OTA app          00 10 00020000 001e0000
I (95) boot:  5 ota_1            OTA app          00 11 00200000 001e0000
I (102) boot:  6 fctry            WiFi data        01 02 003e0000 00006000
I (110) boot: End of partition table
I (114) esp_image: segment 0: paddr=00020020 vaddr=3c0e0020 size=305b8h (198072) map
I (158) esp_image: segment 1: paddr=000505e0 vaddr=3fc97ca0 size=04b24h ( 19236) load
I (162) esp_image: segment 2: paddr=0005510c vaddr=40374000 size=0af0ch ( 44812) load
I (174) esp_image: segment 3: paddr=00060020 vaddr=42000020 size=dd260h (905824) map
I (336) esp_image: segment 4: paddr=0013d288 vaddr=4037ef0c size=08d90h ( 36240) load
I (345) esp_image: segment 5: paddr=00146020 vaddr=50000000 size=00010h (    16) load
I (353) boot: Loaded app from partition at offset 0x20000
I (353) boot: Disabling RNG early entropy source...
I (365) cpu_start: Pro cpu up.
I (365) cpu_start: Starting app cpu, entry point is 0x40375458
0x40375458: call_start_cpu1 at /home/martin/esp-idf/components/esp_system/port/cpu_start.c:148

I (0) cpu_start: App cpu up.
I (379) cpu_start: Pro cpu start user code
I (379) cpu_start: cpu freq: 160000000
I (379) cpu_start: Application information:
I (382) cpu_start: Project name:     zap_light
I (387) cpu_start: App version:      v1.0
I (392) cpu_start: Compile time:     Feb  3 2023 02:00:16
I (398) cpu_start: ELF file SHA256:  b3ab3a573693aeb8...
I (404) cpu_start: ESP-IDF:          v4.4.3-dirty
I (409) heap_init: Initializing. RAM available for dynamic allocation:
I (417) heap_init: At 3FCACAA8 len 0003CC68 (243 KiB): D/IRAM
I (423) heap_init: At 3FCE9710 len 00005724 (21 KiB): STACK/DRAM
I (430) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
I (436) heap_init: At 600FE000 len 00002000 (8 KiB): RTCRAM
I (443) spi_flash: detected chip: generic
I (447) spi_flash: flash io: dio
W (451) spi_flash: Detected size(8192k) larger than the size in the binary image header(4096k). Using the size in the binary image header.
I (465) sleep: Configure to isolate all GPIO pins in sleep state
I (471) sleep: Enable automatic switching of GPIO sleep configuration
I (478) coexist: coexist rom version e7ae62f
I (483) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (546) led_driver_ws2812: Initializing light driver
I (546) gpio: GPIO[0]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (546) pp: pp rom version: e7ae62f
I (556) net80211: net80211 rom version: e7ae62f
I (566) wifi:wifi driver task: 3fceda58, prio:23, stack:6656, core=0
I (566) system_api: Base MAC address is not set
I (566) system_api: read default base MAC address from EFUSE
I (576) wifi:wifi firmware version: 8cb87ff
I (576) wifi:wifi certification version: v7.0
I (586) wifi:config NVS flash: enabled
I (586) wifi:config nano formating: disabled
I (586) wifi:Init data frame dynamic rx buffer num: 32
I (596) wifi:Init management frame dynamic rx buffer num: 32
I (596) wifi:Init management short buffer num: 32
I (606) wifi:Init dynamic tx buffer num: 32
I (606) wifi:Init static tx FG buffer num: 2
I (616) wifi:Init static rx buffer size: 1600
I (616) wifi:Init static rx buffer num: 10
I (616) wifi:Init dynamic rx buffer num: 32
I (626) wifi_init: rx ba win: 6
I (626) wifi_init: tcpip mbox: 32
I (636) wifi_init: udp mbox: 6
I (636) wifi_init: tcp mbox: 6
I (636) wifi_init: tcp tx win: 5744
I (646) wifi_init: tcp rx win: 5744
I (646) wifi_init: tcp mss: 1440
I (656) wifi_init: WiFi IRAM OP enabled
I (656) wifi_init: WiFi RX IRAM OP enabled
I (676) chip[DL]: NVS set: chip-counters/reboot-count = 2 (0x2)
I (676) chip[DL]: Real time clock set to 946684800 (0100/00/01 00:00:00 UTC)
W (676) BT_INIT: esp_bt_controller_mem_release not implemented, return OK
I (686) BT_INIT: BT controller compile version [421c279]
I (686) phy_init: phy_version 503,13653eb,Jun  1 2022,17:47:08
I (736) BT_INIT: Bluetooth MAC: 60:55:f9:f5:26:96

I (736) NimBLE: GAP procedure initiated: stop advertising.

I (736) CHIP[DL]: BLE host-controller synced
I (1236) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable)
I (1236) NimBLE: GAP procedure initiated: advertise;
I (1236) NimBLE: disc_mode=2
I (1236) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (1246) NimBLE:

I (1256) chip[DL]: CHIPoBLE advertising started
E (1256) chip[DL]: Long dispatch time: 581 ms, for event type 2
I (1266) chip[DL]: Starting ESP WiFi layer
I (1266) wifi:mode : sta (60:55:f9:f5:26:94)
I (1276) wifi:enable tsf
W (1276) wifi:Haven't to connect to a suitable AP now!
I (1276) chip[DL]: Done driving station state, nothing else to do...
W (1286) wifi:Haven't to connect to a suitable AP now!
I (1296) chip[DL]: Done driving station state, nothing else to do...
I (1296) chip[SVR]: Server initializing...
I (1306) chip[TS]: Last Known Good Time: 2023-02-03T02:03:56
I (1306) chip[DMG]: AccessControl: initializing
I (1316) chip[DMG]: Examples::AccessControlDelegate::Init
I (1316) chip[DMG]: AccessControl: setting
I (1326) chip[DMG]: DefaultAclStorage: initializing
I (1326) chip[DMG]: DefaultAclStorage: 0 entries loaded
I (1356) chip[ZCL]: Using ZAP configuration...
I (1356) chip[DMG]: AccessControlCluster: initializing
I (1356) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0030's Attribute 0x0000 is 0 **********
I (1366) chip[ZCL]: Initiating Admin Commissioning cluster.
I (1366) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0004's Attribute 0x0000 is 128 **********
I (1376) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0004's Attribute 0xFFFC is <invalid type: 0> **********
E (1396) chip[ZCL]: DeviceInfoProvider is not registered
I (1396) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x002C's Attribute 0x0001 is 0 **********
E (1406) chip[ZCL]: Trying to write invalid Calendar Type
E (1416) chip[ZCL]: Failed to write calendar type with error: 0x87
I (1416) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0004's Attribute 0x0000 is 128 **********
I (1436) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0004's Attribute 0xFFFC is <invalid type: 0> **********
I (1446) chip[ZCL]: On/Off set value: 1 0
I (1446) chip[ZCL]: On/off already set to new value
I (1456) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0008's Attribute 0x0000 is 1 **********
I (1466) led_driver_ws2812: led set r:0, g:0, b:0
I (1476) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0300's Attribute 0x0007 is 0 **********
I (1476) led_driver_ws2812: led set r:0, g:0, b:0
I (1486) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0300's Attribute 0x0008 is 2 **********
I (1496) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0300's Attribute 0x4001 is 2 **********
I (1506) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0406's Attribute 0x0001 is 0 **********
I (1516) esp_matter_attribute: ********** Endpoint 0x0001's Cluster 0x0406's Attribute 0x0002 is 1 **********
I (1526) chip[DIS]: Updating services using commissioning mode 1
I (1536) chip[DIS]: CHIP minimal mDNS started advertising.
I (1546) chip[DIS]: Advertise commission parameter vendorID=65521 productID=32768 discriminator=3840/15 cm=1
I (1556) chip[DIS]: CHIP minimal mDNS configured as 'Commissionable node device'; instance name: AC3C61DE894112A1.
I (1566) chip[DIS]: mDNS service published: _matterc._udp
I (1566) chip[IN]: CASE Server enabling CASE session setups
I (1576) chip[SVR]: Joining Multicast groups
I (1576) chip[SVR]: Server Listening...
E (1586) chip[DL]: Long dispatch time: 287 ms, for event type 2
I (1586) chip[DL]: WIFI_EVENT_STA_START
W (1596) wifi:Haven't to connect to a suitable AP now!
E (1596) esp_matter_core: Node does not exist or esp_matter does not start
I (1596) chip[DL]: Done driving station state, nothing else to do...
I (1616) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable)
I (1626) chip[DL]: Device already advertising, stop active advertisement and restart
I (1636) NimBLE: GAP procedure initiated: stop advertising.

I (1636) NimBLE: GAP procedure initiated: advertise;
I (1646) NimBLE: disc_mode=2
I (1646) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (1656) NimBLE:

I (1656) app_main: Commissioning window opened
E (1666) app_main: Matter start failed: 259
I (1666) led_driver_ws2812: led set r:0, g:0, b:0
I (1676) led_driver_ws2812: led set r:0, g:0, b:0
I (1676) led_driver_ws2812: led set r:0, g:0, b:0
I (1686) led_driver_ws2812: led set r:0, g:0, b:0
> I (31536) chip[DL]: Configuring CHIPoBLE advertising (interval 500 ms, connectable)
I (31536) chip[DL]: Device already advertising, stop active advertisement and restart
I (31546) NimBLE: GAP procedure initiated: stop advertising.

I (31546) NimBLE: GAP procedure initiated: advertise;
I (31556) NimBLE: disc_mode=2
I (31556) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=800 adv_itvl_max=800
I (31576) NimBLE:

I (167986) chip[DL]: BLE GAP connection established (con 1)
I (167986) chip[DL]: CHIPoBLE advertising stopped
I (168726) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (168726) chip[BLE]: local and remote recv window sizes = 5
I (168726) chip[BLE]: selected BTP version 4
I (168736) chip[BLE]: using BTP fragment sizes rx 244 / tx 244.
I (168786) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 1 ) indicate = 1
I (168786) chip[DL]: CHIPoBLE subscribe received
I (168786) NimBLE: GATT procedure initiated: indicate;
I (168796) NimBLE: att_handle=14

I (168846) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (168876) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (168876) chip[EM]: >>> [E:902r M:202845798] (U) Msg RX from 0:56B04672D9E74C08 [0000] --- Type 0000:20 (SecureChannel:PBKDFParamRequest)
I (168886) chip[EM]: <<< [E:902r M:235431901] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:21 (SecureChannel:PBKDFParamResponse)
I (168906) chip[IN]: (U) Sending msg 235431901 to IP address 'BLE'
I (168906) NimBLE: GATT procedure initiated: indicate;
I (168916) NimBLE: att_handle=14

I (168996) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (169056) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (169056) chip[EM]: >>> [E:902r M:202845799] (U) Msg RX from 0:56B04672D9E74C08 [0000] --- Type 0000:22 (SecureChannel:PASE_Pake1)
I (170056) chip[EM]: <<< [E:902r M:235431902] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:23 (SecureChannel:PASE_Pake2)
I (170056) chip[IN]: (U) Sending msg 235431902 to IP address 'BLE'
I (170066) NimBLE: GATT procedure initiated: indicate;
I (170066) NimBLE: att_handle=14

E (170086) chip[DL]: Long dispatch time: 1029 ms, for event type 7
I (170136) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (170196) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (170196) chip[EM]: >>> [E:902r M:202845800] (U) Msg RX from 0:56B04672D9E74C08 [0000] --- Type 0000:24 (SecureChannel:PASE_Pake3)
I (170206) chip[EM]: <<< [E:902r M:235431903] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
I (170226) chip[IN]: (U) Sending msg 235431903 to IP address 'BLE'
I (170226) NimBLE: GATT procedure initiated: indicate;
I (170236) NimBLE: att_handle=14

I (170236) chip[SC]: SecureSession[0x3fca16a0]: Moving from state 'kEstablishing' --> 'kActive'
I (170236) chip[SVR]: Commissioning completed session establishment step
I (170256) chip[DIS]: Updating services using commissioning mode 0
I (170256) chip[DIS]: CHIP minimal mDNS started advertising.
I (170266) chip[SVR]: Device completed Rendezvous process
I (170266) app_main: Commissioning session started
I (170276) app_main: Commissioning window closed
I (170286) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (170316) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (170316) chip[EM]: >>> [E:903r M:184985224] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:02 (IM:ReadRequest)
I (170336) chip[DL]: NVS set: chip-config/reg-location = 0 (0x0)
I (170346) chip[EM]: <<< [E:903r M:61286790] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:05 (IM:ReportData)
I (170346) chip[IN]: (S) Sending msg 61286790 on secure session with LSID: 55944
I (170356) NimBLE: GATT procedure initiated: indicate;
I (170366) NimBLE: att_handle=14

I (170466) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (170466) NimBLE: GATT procedure initiated: indicate;
I (170476) NimBLE: att_handle=14

I (170526) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (170556) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (170556) chip[EM]: >>> [E:904r M:184985225] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (170566) chip[FS]: GeneralCommissioning: Received ArmFailSafe (30s)
I (170576) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0030's Attribute 0x0000 is 3 **********
I (170586) chip[EM]: <<< [E:904r M:61286791] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (170596) chip[IN]: (S) Sending msg 61286791 on secure session with LSID: 55944
I (170596) NimBLE: GATT procedure initiated: indicate;
I (170616) NimBLE: att_handle=14

I (170676) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (170706) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (170706) chip[EM]: >>> [E:905r M:184985226] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (170716) chip[DL]: NVS set: chip-config/reg-location = 0 (0x0)
I (170736) chip[DL]: NVS set: chip-config/country-code = "XX"
I (170736) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0030's Attribute 0x0000 is 4 **********
I (170746) chip[EM]: <<< [E:905r M:61286792] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (170756) chip[IN]: (S) Sending msg 61286792 on secure session with LSID: 55944
I (170766) NimBLE: GATT procedure initiated: indicate;
I (170776) NimBLE: att_handle=14

I (170826) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (170856) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (170856) chip[EM]: >>> [E:906r M:184985227] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (170866) chip[ZCL]: OpCreds: Certificate Chain request received for PAI
I (170876) chip[EM]: <<< [E:906r M:61286793] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (170886) chip[IN]: (S) Sending msg 61286793 on secure session with LSID: 55944
I (170886) NimBLE: GATT procedure initiated: indicate;
I (170906) NimBLE: att_handle=14

I (170976) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (170976) NimBLE: GATT procedure initiated: indicate;
I (170986) NimBLE: att_handle=14

I (171066) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (171066) NimBLE: GATT procedure initiated: indicate;
I (171076) NimBLE: att_handle=14

I (171126) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (171156) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (171156) chip[EM]: >>> [E:907r M:184985228] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (171166) chip[ZCL]: OpCreds: Certificate Chain request received for DAC
I (171176) chip[EM]: <<< [E:907r M:61286794] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (171186) chip[IN]: (S) Sending msg 61286794 on secure session with LSID: 55944
I (171186) NimBLE: GATT procedure initiated: indicate;
I (171206) NimBLE: att_handle=14

I (171276) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (171276) NimBLE: GATT procedure initiated: indicate;
I (171286) NimBLE: att_handle=14

I (171366) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (171366) NimBLE: GATT procedure initiated: indicate;
I (171376) NimBLE: att_handle=14

I (171426) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (171456) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (171456) chip[EM]: >>> [E:908r M:184985229] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (171466) chip[ZCL]: OpCreds: Received an AttestationRequest command
I (171676) chip[ZCL]: OpCreds: AttestationRequest successful.
I (171686) chip[EM]: <<< [E:908r M:61286795] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (171686) chip[IN]: (S) Sending msg 61286795 on secure session with LSID: 55944
I (171696) NimBLE: GATT procedure initiated: indicate;
I (171696) NimBLE: att_handle=14

E (171706) chip[DL]: Long dispatch time: 256 ms, for event type 7
I (171786) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (171786) NimBLE: GATT procedure initiated: indicate;
I (171796) NimBLE: att_handle=14

I (171876) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (171876) NimBLE: GATT procedure initiated: indicate;
I (171886) NimBLE: att_handle=14

I (171966) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (172056) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 1 12
I (172056) chip[EM]: >>> [E:909r M:184985230] (S) Msg RX from 0:FFFFFFFB00000000 [0000] --- Type 0001:08 (IM:InvokeCommandRequest)
I (172066) chip[FS]: GeneralCommissioning: Received ArmFailSafe (0s)
I (172066) chip[FS]: Fail-safe timer expired
I (172086) chip[EM]: <<< [E:909r M:61286796] (S) Msg TX to 0:FFFFFFFB00000000 [0000] --- Type 0001:09 (IM:InvokeCommandResponse)
I (172086) chip[IN]: (S) Sending msg 61286796 on secure session with LSID: 55944
I (172096) NimBLE: GATT procedure initiated: indicate;
I (172096) NimBLE: att_handle=14

E (172116) chip[SVR]: Failsafe timer expired
I (172116) chip[SC]: SecureSession[0x3fca16a0]: Moving from state 'kActive' --> 'kPendingEviction'
E (172126) chip[SVR]: Commissioning failed (attempt 1): 32
I (172126) chip[BLE]: Releasing end point's BLE connection back to application.
I (172146) chip[DIS]: Updating services using commissioning mode 1
I (172146) chip[DIS]: CHIP minimal mDNS started advertising.
I (172156) chip[DIS]: Advertise commission parameter vendorID=65521 productID=32768 discriminator=3840/15 cm=1
I (172156) chip[DIS]: CHIP minimal mDNS configured as 'Commissionable node device'; instance name: AC3C61DE894112A1.
I (172176) chip[DIS]: mDNS service published: _matterc._udp
E (172186) chip[ZCL]: OpCreds: Got FailSafeTimerExpired
E (172186) chip[ZCL]: OpCreds: Proceeding to FailSafeCleanup on fail-safe expiry!
I (172196) chip[TS]: Pending Last Known Good Time: 2023-02-03T02:03:56
I (172176) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 1) status= 14
I (172216) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 1 ) indicate = 0
I (172226) chip[DL]: CHIPoBLE unsubscribe received
I (172196) chip[TS]: Previous Last Known Good Time: 2023-02-03T02:03:56
I (172236) chip[TS]: Reverted Last Known Good Time to previous value
I (172236) esp_matter_attribute: ********** Endpoint 0x0000's Cluster 0x0030's Attribute 0x0000 is 0 **********
I (172256) app_main: Commissioning failed, fail safe timer expired
E (172266) chip[DL]: Long dispatch time: 150 ms, for event type 32782
I (172266) chip[FS]: Fail-safe cleanly disarmed
I (172266) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable)
I (172276) NimBLE: GAP procedure initiated: advertise;
I (172276) NimBLE: disc_mode=2
I (172286) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (172306) NimBLE:

I (172306) chip[DL]: CHIPoBLE advertising started
I (172306) app_main: Commissioning window opened
E (172316) chip[BLE]: no endpoint for BLE sent data ack
E (172316) chip[BLE]: no endpoint for unsub recvd
I (173166) chip[DL]: BLE GAP connection terminated (con 1 reason 0x213)
I (173166) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable)
I (173176) chip[DL]: Device already advertising, stop active advertisement and restart
I (173176) NimBLE: GAP procedure initiated: stop advertising.

I (173186) NimBLE: GAP procedure initiated: advertise;
I (173196) NimBLE: disc_mode=2
I (173196) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (173206) NimBLE:

I (202146) chip[DL]: Configuring CHIPoBLE advertising (interval 500 ms, connectable)
I (202146) chip[DL]: Device already advertising, stop active advertisement and restart
I (202156) NimBLE: GAP procedure initiated: stop advertising.

I (202156) NimBLE: GAP procedure initiated: advertise;
I (202166) NimBLE: disc_mode=2
I (202166) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=800 adv_itvl_max=800
I (202186) NimBLE:

Android CHIPTool is not maintained very well and it is broken much of the time. Try GSAFM instead...
https://github.com/google-home/sample-app-for-matter-android

@MartinPArmstrong As per the logs, the CSR (after the attestation request is successful) request is not received from the commissioner and hence the fail saif timer expires and the commissioning fails. Is it possible to check using other commissioners like host-based chip-tool, Google Home, Apple Home or the custom Android app as mentioned by @jonsmirl above?


Support PodSecurityPolicies in CAPO

PodSecurityPolicies feature gate is not enabled for CAPO yet. We need to enable it for GA.
When we enable PSPs now, kube-proxy is not working. AWS and GCP providers use https://github.com/giantswarm/cluster-shared to deploy necessary PSPs via ClusterResourceSet and state cluster-shared as a dependency like https://github.com/giantswarm/cluster-aws/blob/master/helm/cluster-aws/Chart.yaml#L11

@erkanerol are we doing PSPs for CAPO now or moving directly to Kyverno? If not, then this should be closed.

The last decision was to support PSPs too but we may need to reconsider the decision according to the timeline. PSPs will be deleted in k8s 1.25, which is going to be released at the end of this month or next month. We use 1.22 in THG prod now.


Guarantee  cf entities contain cfGuid value

For top level entities we apply cfGuid to the entity via the api effect
For inline entities these are not applied
Need to apply the cfGuid via the schema option processStrategy
Should also move this to the metadata section (makes a bit more sense sticking it there)

Where is this currently an issue? Anywhere that we use entity.cfGuid on an element that was fetched inline, such as app's in the cf section (TableCellAppStatusComponent)
While doing this we could also look at adding other metadata such as orgGuid and spaceGuid (but only to those who solely exist in one... or maybe have them as arrays... )

Fixed as part of another PR. We now also iterate over inline arrays as well as inline objects.


Waiting for user prompt in unattended mode

Describe the bug
Hi, I'm using the win-acme tool to install the generated certificate by using the script plugin with a custom installation tool. If there is already a renewal defined and the installation script returns an error, a user prompt asking to save the new settings is shown. Since I'm starting the client programmatically in a new Process, it always runs into a timeout while waiting for the mentioned user input.
To Reproduce

Run the tool to ensure an existing renewal configuration
The custom installation script returns an error
Start win-acme programmatically via command "wacs.exe --verbose --closeonfinish --accepttos --emailaddress MyEmail --source manual --host myHost --notaskscheduler --installation script --script myInstallationTool.exe --scriptparameters InstallArgs --validationmode dns-01 --validation script --dnsscript myValidationTool.exe --dnscreatescriptarguments CreateArgs --dnsdeletescriptarguments DeleteArgs"

Expected behavior
The started process returns an error without waiting for user input.
Log
Running the above mentioned command manually via commandline, returns the following output
 [VERB] Process output without data received
 [VERB]Process error without data received
 [EROR] Script finished with exit code 3
 [VERB] Waiting for process to finish...

 Save these new settings anyway? (y/n*) - no

 [EROR] Create certificate failed: Installation plugin Script encountered an error
 [VERB] Exiting with status code -1

Platform:

OS: Windows Server 2019, English]
Version:  2.1.20, 64-bit

Nice catch and thanks for the PR!

This fix is included in the new release: https://github.com/win-acme/win-acme/releases/tag/v<IP_ADDRESS>8


[harfbuzz] fix iOS build

What does your PR fix?
Fix harfbuzz building on iOS where ApplicationServices framework is unavailable

Which triplets are supported/not supported? Have you updated the CI baseline?
All, No

Does your PR follow the maintainer guide?

Yes

@microsoft-github-policy-service agree

Thanks!

The failures looked like baseline issues, I pushed a merge with https://github.com/microsoft/vcpkg/pull/27619 to see if that fixes it.

/azp run

The build break is a baseline issue, investigating.

Thank you!


Fix BigInt comparisons in GraphQL filters

This is clearly not the right order:

The current implementation of order_by takes a String to specify the attribute on which the ordering is performed the JSONB attribute is passed directly to the order by clause in the SQL query.    .order(                 sql::<Text>("data ->> ")                     .bind::<Text, _>(order_attribute).   The attribute is always passed in as text so the ordering is done in Alphabetic order.  We need to cast BigInt attributes as float using CAST(data ->> 'attribute' AS FLOAT) or (data ->>'attribute)::float.
The current StoreQuery struct simply provides a string for the order attribute making it difficult to tell the attribute type, we need to pass in a Value enum so that type casting can be done to perform the ordering correctly.

Is float the right thing to do or can we use Postgres' numeric type?

The best thing to do here is to change the order_by: Option<String> to order_by: Option<(String, ValueType)> where the ValueType matches the values we support in entity attributes.


Optional Typing conflict if a class and one of its member variables share a common named attribute with different expected types

3.1 Alpha.
class_name Game

var state: State = State.new()
var player: Player = Player.new()
var player_two: Player = Player.new()

func _ready():
	player.opponent = player_two
	player_two.opponent = player
	player_two.opponent.state = PLAYER.IDLE # Works
	player.state = PLAYER.IDLE # Does not work

This brings up the error
error(12, 29): Assigned value type (int) doesn't match the variable's type (State).
It seems Player.state is expecting "State" instead of "int" when assigning directly from the class. However if we do player.middleman.state = value, it expects int.
Example Project Zip

It seems this might be a consequence of the "can't shadow variables from parent scopes" in 3.1?


Upgrade to Phoenix 1.3

This upgraded was conducted against version 1.3.0-rc2.

💚 tests after some minor changes to Travis. Nice work @chriserin ! 👍

@tmock12 nice thank you!  good catch!

This is awesome-- thank you! 👍


other types of weapons haveing low duribility commpared to there sword couterparts

some examples are all of the tetra weapons and Spartan weapons

I fixed the Spartan durability values in 7f2574e, now they are equal to vanilla tools.
I'm leaving this open so I can fix Tetra somehow later (via datapack?).

OHHH my god if you fix tetra I will be so happy I get so hurt by this.


Postprocess on gpu

Thank you for your work!
Could you please guide how to run postprocess on gpu (how to create right config)? I use provided weights (for both extractor and processor) to validate my dataset and set accelerator: gpu, then extractor runs on gpu, but processor is still on cpu.

This could be my misunderstanding - I made this conclusion based on this progress bar info with "cpu" label (image attached

) and compared time of postprocess inference with extractor inference (same architecture used) - the first one takes 2-3 times longer. If it's normal behavior, does it mean, that some additional postprocess on cpu (kind of distances rearrangement) take so much time?

Hm, thank you! It's wierd. I will take a look.

the first one takes 2-3 times longer

The time needed for extractor is O(N), where N is the size of your validation dataset.
The time needed for postprocessor is O(N_queries * top_k). The postprocessor's inference itself is also longer since we concatenate images (roughly ~4 times).
So, what are your N, N_queries, top_k?
Anyway, for most of the datasets postprocessing takes longer than extraction stage. So, 2-3 times longer seems okay, but if both of them on GPU. So, I surprised that difference is not as big that I expected. But probably your dataset is just as unique.

I took a look. Everything works fine for me when I set gpu in a config file.

@june94 , Is your Cuda available? If not, your device could be selected by default as cpu. Please, check it out

@june94 if there are any updates here?

Close due to inactivity


Swift 4 : Declarations from extensions cannot be overridden yet

Integrate in Xcode Version 9.0 beta 3.
Issue: Declarations from extensions cannot be overridden yet
Please see screenshot.

I am getting the same problem with XCode 9.0 Beta 5. Any solution yet?

@ravi8x How are you showing menu on the view controllers which is not pushed but instead presented? Any solution?

@abhijithExperion No Abhijith. I have written my own Slider Menu class with very minimal functionalities.

this is a very easily reproducible "bug"; just check out the current branch and import the library to a project using Swift 4 (e.g. XCode 4 Beta 1-4). Probably it is an easy fix...

@andylamp I am using with pods
pod 'SlideMenuControllerSwift'
What changes required when using pod with swift 4, XCode - Version 9.0 beta 3 (9M174d).
Thanks

@KrishnendraPrakash the solution, albeit with warnings, for now it seems to be that you have to put the following:
    @objc public func openLeft() {
      slideMenuController()?.openLeft()
    }

    @objc public func openRight() {
        slideMenuController()?.openRight()    }

    @objc public func closeLeft() {
        slideMenuController()?.closeLeft()
    }

    @objc public func closeRight() {
        slideMenuController()?.closeRight()
    }

Specifically, these are located in lines 1055-1075 in SlideMenuController.swift -- they should work but XCode will complain about deprecated functionality... but it's a temporary solution for the time being.
Hope this helps...

Anybody know if there will be a release for Swift4?
We need the solution by pods installation

Not compatible with swift4

@akshayiosdeveloper as I said, you can alter the source file as indicated in my previous answer and it will run just fine...

@akshayiosdeveloper you can use too branch of Swift 4 if you use as pod.
https://github.com/dekatotoro/SlideMenuControllerSwift/tree/swift4
@andylamp I hope you MR is comming soon.

@andylamp  You are right but if we use Pod file, It will auto update when we update our other pod files, right ?

@arun-perk you can use the pods git branch tool in order to have a specific version, this can be done easily like so:
platform :ios, '11.0'

target 'YourAppName' do
  use_frameworks!
  # more pods...
    pod 'SlideMenuControllerSwift', :git => 'https://github.com/dekatotoro/SlideMenuControllerSwift.git', :branch => 'swift4''
  # even more pods...
end

Hope this helps.

Update your pod

https://guides.cocoapods.org/using/getting-started.html
" sudo gem update cocoapods " in terminal


🚧Refactor unit test assertions

Description:
To allow this pull request to be merged, please make sure that the following items of this pull request are complete.
This pull request closes #107
✅The pull request head branch must be a feature branch with the syntax 'feature/-sync-testing'.
✅The pull request base branch must be a 'main' or 'preview' branch..
✅The pull request head branch contains a valid issue number.
✅The pull request title matches the linked issue title exactly.
✅The pull request assignees match the assignees of the issue.
✅The pull request labels match the labels of the issue.
✅The pull request organizational projects match the organizational projects of the issue.
✅The pull requests milestone matches the milestone of the issue.

Additional Info:

Pull requests are automatically synced with the associated issue upon creation by one of the KinsonDigital workflow bots.
The associated issue is the issue number that is embedded in the pull request head branch.
The list above will be automatically updated as the pull request's various settings match or do not match the associated issue.
To manually sync the pull request to the issue, create a comment with the [run-sync] command.

Note You must be an admin member of the organization to use this command.

[x] Sync with the issue.  Use this to enable or disable this pull request from syncing with its associated issue.

After discussion with @CalvinWilkinson the PR will be pushed for review even if sync status check fails, because the reason of the failure has to do with the CICD system.

[run-sync]

[run-sync]


Does not work with msvc archiver

MSVC targets don't have "ar", but "lib" instead. lib unfortunately has different command-line arguments, so it can't be used as a drop in replacement for ar.

The workaround is to make the library using the cc crate:
for o in nasm.compile_objects() {
    cc.object(o);
}
cc.compile("library");

My PR to fix this was actually just merged.


Telomere replication

Hi
Hope this is a quick fix!
please could the telomere ontology be re-arranged slightly.
Telomere maintenance via telomere lengthening should NOT be a parent to telomere maintenance via semi-conservative replication - as telomere lengthening of any sort  is always telomere maintenance - but 'normal' semi-conservative DNA replication is in fact going to lead to telomere shortening in cells with no active telomerase.
So the new ontology should be:
GO:0000723 telomere maintenance

is_a  child GO:0032201	telomere maintenance via semi-conservative replication
is_a child GO:0010833	telomere maintenance via telomere lengthening
These child terms are siblings not related via parent-child

not sure that you put dbxrefs for ontology rearrangements: GOC:BHF, GOC:BHF_telomere, GOC:rl
Thanks
Ruth

I don't think its clear what these 2 processes are (although I think I probably requested them years ago).
How do telomeres replicate if not via telomerase?
@mah11  might remember more...
Val

digging out some very old stuff that I had long forgotten:
. Drosph. appears different.
From Genome Biol. 2002; 3(10): reviews0007.1–reviews0007.6.
Published online 2002 Sep 27. doi:  10.1186/gb-2002-3-10-reviews0007
"First of all, telomere maintenance in Drosophila is not performed by the canonical telomerase but by a unique transposition mechanism. Two non-LTR (long terminal repeat) retrotransposable elements, HeT-A and TART telomere-associated retrotransposons, are attached specifically to the chromosome ends  (references therein).

not many human cells have telomerase, (e.g. mostly stem cells and cancer cells) but they still have to replicate their DNA using polymerases, but then they get shorter at each replication cycle due to the lack of telomerase

We aren't annotating cancer cells though? only normal cells? (presumably  some stem cells don't have active telomerase if their telomeres are not yet shortened?)
Pombe does some things in mutants lacking telomerase to 'trick' cells into  not perceiving ds breaks at chromosome ends using DSB machinery and recombination... but these are random/chance events giving raise to small populations  of 'survivors'. If these studies are being done in cancer cell lines perhaps don't represent  processes occurring in "normal" cells...Just a thought ......
(PS I don't think human and yeast are *so * different ;)

Hi Val
All germ cells and many stem cells have telomerase as they need to protect their telomeres.
Human telomeres have TTAGGG repeated approximately 2,500 times and at each replication cycle the various different replication and repair methods may lead to the lengthening or shortening of the repeat. For example there is more replication fork stalling due to the repetitive nature of the DNA. This is not the sub-telomeric region as when the telomere shortens these repeats become the shelterin protected part of the 'telomere'.
PMID: 26188776 has a good summary about replicating. Although the suggestion that the telomeres in differentiated cells are lengthened by telomerase when they get too short isn't something that I have read about myself and I am not totally convinced about this, mostly people seem to think that when the telomeres get too short the cell become senescent or die. Anyway hopefully this will convince you that telomere replication has additional features which are unique to telomeres (any maybe other heterochromatic regions - I haven't check this) and therefore the specific term is needed, but does not necessarily lead to lengthening of the telomere. Ill comment on the definition in the other ticket.

Hi @RLovering ,
Could you please review this ticket, and summarise if/what change is requested?
(You wrote “I’ll comment on the definition in the other ticket”, but there is no link, so I’m not sure if your issue was fixed elsewhere and this ticket can be closed or not.)
I also have this other ticket about telomeres with comments from you and Val, could you please check if there is any duplication (i.e. same or similar issue(s) reported in both tickets): https://github.com/geneontology/go-ontology/issues/12227
A revision/summary may make things quicker for all parts involved, many thanks,
Paola

Hi Paola and @ValWood
the two tickets (this one and #12227) can be closed if the following is done:
GO:0000723 telomere maintenance
new definition:
Any process that contributes to the maintenance of proper telomeric length and structure by affecting and monitoring the activity of telomeric proteins, the length of telomeric DNA and the replication and repair of the DNA. These processes includes those that shorten, lengthen, replicate and repair the telomeric DNA sequences.
the new ontology should be:
GO:0000723 telomere maintenance
is_a child GO:0032201 telomere maintenance via semi-conservative replication
is_a child GO:0010833 telomere maintenance via telomere lengthening
Val also expressed an interest in having a term "telomere length maintenance" as a parent to telomere maintenance via telomere lengthening and telomere capping.
I would be concerned that this will get confusing, as even DNA repair is occurring to maintain the length of the telomere (but this wouldn't be a child of the telomere length maintenance term) and this term name is very similar to it's child term telomere maintenance via telomere lengthening.
Maybe Val can confirm whether she is still concerned about the early split in the ontology between telomere maintenance via telomere lengthening and telomere capping.
Best
Ruth

Hi Ruth,
Go ahead with your suggestions, I'm probably being overly picky. I'm also not realistically going to  be annotating telomere biology shortly so we  can make any necessary adjustments if we need to. I think you guys know best.
VAl

Thanks @RLovering and @ValWood ,
All done as Ruth suggested. Closing now.


Add activate and load functions to Spirc

This adds functions that activate (i.e. set 'is active' to true/makes it the active player) and load function to play specific tracks.
I've tried to follow the structure used in the rest of the struct, but if there are any issues I'm more than happy to change.

Sample program to test this at https://github.com/librespot-org/librespot/discussions/1072#discussioncomment-4187603
Maybe it should be a new example

Yep I can make a new example for it and will fix up the tests too.

Thanks! Could you fix the clippy lints and run cargo fmt if you haven't already?

If you rebase your changes on current dev that'll fix it for you @oeed

Great thanks, have done.
Once this is merged I have two additional PRs I'll post that add functions to Spirc to get its state and another that broadcasts PlayerEvents from Spirc.

No problem @roderickvd, done


[Transform] Hoist thread-local allocator within the nested parallel loops

This PR is to track https://github.com/intel/graph-compiler/issues/120

I have a general question on this pass. After buffer hoisting (including in nested parallel, and normal loops in upstream), the lifetime of the buffer is actually extended, which will make buffer-scheduling produce worse result. Can we consider the lifetime of buffers while hoisting?
The reason is that the semantic of a hoisted buffer is changed
for i {
    float a[100]
    use1(a, i)
    use2(a, i)
    float b[100]
    use3(b, i)
    use4(b, i)
}

in the above code, every iteration of i "creates" a new buffer a. So buffers a and b has non-overlapping lifetime. If we hoist a and b, the lifetime will change:
float a[100]
float b[100]
for i {
    use1(a, i)
    use2(a, i)
    use3(b, i)
    use4(b, i)
}

a and b must have overlapping lifetime, because we don't know if use1(a, i) will read the result of the last iteration. If we reuse a for b, the result may be incorrect.

I can find 3 ways to resolve this lifetime issue

Keep hoisting as a independent pass like in this PR, and mark additional info on the hoisted buffers. For example, we can mark on a that it is hoisted from for i. The obstacle of this solution is how can we mark a "block" as attr of an operation.
Adopt the GC V1 way, combine hoisting and scheduling in a single pass. In V1, we first schedule in a parallel-for, and hoist it, and schedule the hoisted buffer with outer parallel-for.
Combine hoisting and scheduling in a single pass, with the new upstream-able interfaces. I am redesigning the buffer-scheduling interface for upstream to make it a general "framework" for developers to customize the scheduling behavior. It might be helpful if we can co-design scheduling interface with our special hoisting. In my understanding, our special hoisting will select a non-default allocation-scope for a buffer (by default, buffer-scheduling will choose the nearest surrounding parallel-for. In our case, we will select the outermost parallel-for),  override the size of the buffer (realSize = originSize * numThreads), and override the IR rewrite behavior. However, most of the code can be reused.
I think maybe we can design the interfaces of buffer scheduling, and let hoisting customize it.

I can find 3 ways to resolve this lifetime issue

Keep hoisting as a independent pass like in this PR, and mark additional info on the hoisted buffers. For example, we can mark on a that it is hoisted from for i. The obstacle of this solution is how can we mark a "block" as attr of an operation.
Adopt the GC V1 way, combine hoisting and scheduling in a single pass. In V1, we first schedule in a parallel-for, and hoist it, and schedule the hoisted buffer with outer parallel-for.
Combine hoisting and scheduling in a single pass, with the new upstream-able interfaces. I am redesigning the buffer-scheduling interface for upstream to make it a general "framework" for developers to customize the scheduling behavior. It might be helpful if we can co-design scheduling interface with our special hoisting. In my understanding, our special hoisting will select a non-default allocation-scope for a buffer (by default, buffer-scheduling will choose the nearest surrounding parallel-for. In our case, we will select the outermost parallel-for),  override the size of the buffer (realSize = originSize * numThreads), and override the IR rewrite behavior. However, most of the code can be reused.
I think maybe we can design the interfaces of buffer scheduling, and let hoisting customize it.

I vote for option 3.

Sounds like yet another case for the cost-modeling'ish approach.

I can find 3 ways to resolve this lifetime issue

Keep hoisting as a independent pass like in this PR, and mark additional info on the hoisted buffers. For example, we can mark on a that it is hoisted from for i. The obstacle of this solution is how can we mark a "block" as attr of an operation.
Adopt the GC V1 way, combine hoisting and scheduling in a single pass. In V1, we first schedule in a parallel-for, and hoist it, and schedule the hoisted buffer with outer parallel-for.
Combine hoisting and scheduling in a single pass, with the new upstream-able interfaces. I am redesigning the buffer-scheduling interface for upstream to make it a general "framework" for developers to customize the scheduling behavior. It might be helpful if we can co-design scheduling interface with our special hoisting. In my understanding, our special hoisting will select a non-default allocation-scope for a buffer (by default, buffer-scheduling will choose the nearest surrounding parallel-for. In our case, we will select the outermost parallel-for),  override the size of the buffer (realSize = originSize * numThreads), and override the IR rewrite behavior. However, most of the code can be reused.
I think maybe we can design the interfaces of buffer scheduling, and let hoisting customize it.

Option 3 looks quite promising.
I would like to emphasis that there're some difference between the buffer hoist in single-thread and multi-thread scenario. For single thread(non-parallel) scenario, the main consideration is for perf perspective, while for multi-thread(parallel) scenario, both functionality (correctness) and perf should be taken into account. That means, for multi-thread scenario, we have to hoist such thread-local allocator out of the parallel loop to avoid any individual thread access another thread's (main thread within any thread-group) local buffer. So I assume buffer-merge pass should mainly focus on the non-parallel scenario?
For the case you mentioned above, doing the buffer-merge firstly then buffer-hoist (the current designed pass order) will resolve the issue? Or maybe you've any other cases for better demonstration?

e yet another case for the cost-modeling'ish approach.

I don't think this optimization needs to rely on or contribute to cost-modeling, due to it's always beneficial to hoist buffer in sequential loops (which is already available in upstream), and it's necessary for parallel loops (to avoid access thread-local buffer cross thread), while this usage is currently mainly happened in our project as upstream always use perfect loop nesting for parallel loops.

And I assume buffer-merge pass should mainly focus on the non-parallel scenario, which means when the pass decides to hoist a buffer it only consider the sequential loops?

You can build parallel-hoisting upon buffer-merge, I suppose. I am updating buffer-merge pass to allow developers to specify 1) where the buffer is allocated after merging (in/out of parallel) 2) the "real" size of the buffer (after parallel hoisting, buffer size expands by num_threads times) 3) how to mutate the IR.
Other things can be handled by buffer-merge.

And I assume buffer-merge pass should mainly focus on the non-parallel scenario, which means when the pass decides to hoist a buffer it only consider the sequential loops?

You can build parallel-hoisting upon buffer-merge, I suppose. I am updating buffer-merge pass to allow developers to specify 1) where the buffer is allocated after merging (in/out of parallel) 2) the "real" size of the buffer (after parallel hoisting, buffer size expands by num_threads times) 3) how to mutate the IR.
Other things can be handled by buffer-merge.

Sure, let's evaluate this function in the new infra, and also the execution order like one-time merge firstly, and then one-time hoisting, or maybe interleaving these two.

Closed as it's duplicated with a new implementation in https://github.com/intel/graph-compiler/pull/283


[Bug]: Create a Template by deselecting a couple of pages - pages are listed and error with uncaught promise when clicked on

Is there an existing issue for this?

[X] I have searched the existing issues

Description
On creating a template by deselecting a couple of pages, the pages are still listed in the menu dropdown, and on clicking any of the pages, Uncaught Promise Rejection error pops up.
Expected behavior, the two deselected pages should not be listed at all.
Steps To Reproduce

Create an app and "Start from a template" .. Choose the Vehicle maintenance template.
Deselect the Select All, and only choose Home Page and click on Add Selected Pages.
From the Open Menu button in the Manage Services heading, the second and third pages are still listed
If we click on either, an error comes up as below

View the loom video for detailed steps -
https://www.loom.com/share/f4969f740cff4ef6aa24c96ca8c51342
Public Sample App
No response
Version
Production

Seems to be working now


Full name font size changes after exporting

Full name size changes after exporting.
The full name size is visible in proper size in the webview but is turned to small after exporting.
Webview:

In PDF :

@AmruthPillai Please take a look.
Can this issue be given the highest priority for now?

@AmruthPillai Please take a look.
Can this issue be given the highest priority for now?

A bit of a different problem but because of the font size my email is split across two lines ...

Adjusting the font size on the app solves this problem but it is still exported in pdf with a somehow default font size.

A bit of a different problem but because of the font size my email is split across two lines ...

Adjusting the font size on the app solves this problem but it is still exported in pdf with a somehow default font size.

Taking a look at it now... introducing new features almost always tends to crop up new issues.

Taking a look at it now... introducing new features almost always tends to crop up new issues.

This has been fixed in v2.5.2 :)

This has been fixed in v2.5.2 :)

Thank you @AmruthPillai . Great Work!

Thank you @AmruthPillai . Great Work!


Bad link to XAML SwapChainPanel DirectX interop sample.

The link "XAML SwapChainPanel DirectX interop sample." doesn't point to the sample. (Not sure what the right link is.)

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

ID: ee9a5a88-6893-33e4-3875-b7c9d3ab54f2
Version Independent ID: 56d8c4f4-c6b6-0369-f0aa-62a53117ae86
Content: SwapChainPanel Class (Windows.UI.Xaml.Controls) - Windows UWP applications
Content Source: https://cpubwin.visualstudio.com/DefaultCollection/windows-uwp/_git/winrt-api-build?path=%2fwinrt-api-build%2fwindows.ui.xaml.controls.swapchainpanel.yml&version=GBlive&_a=contents
Product: uwp
Technology: winui
Git Login: jwmsft
Microsoft Alias: jimwalk

This link has been fixed. Thanks.


Mesh network management API

This PR implements a set of API functions for mesh network management.

[ch28309]

Coverage increased (+0.7%) to 74.874% when pulling 767b099b7666dbca8364285978dd561b34654cc8 on feature/mesh_api into 30d10e94bdf126b808e10e795353a0eb60ce2ace on master.

Nice work @sergeuz. Good to see you in JavaScript land! I noticed a few TODOs in your code, are those issues we want to address now, or after shipping?

@monkbroc Added parameters for pagination and filtering by device type: https://github.com/particle-iot/particle-api-js/pull/98/commits/4ada7d4ca7ba504fec406e653bb828cae4e64411

Go ahead and merge when you are ready


Consider a diff image for testing/samples

I am running into
  Warning  Failed     11s   kubelet            Failed to pull image "perl": rpc error: code = Unknown desc = reading manifest latest in docker.io/library/perl: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

we might want to consider an image out of a diff registry to avoid this unfortunate error
/kind test

/kind test

I have this one
quay.io/eduardoarango/pi:ubi8
This is the repo -> https://github.com/ArangoGutierrez/Pi
``bash
[eduardo@fedora kueue]$ kubectl logs sample-job--1-24kpr
1000 trials, pi is 3.120000

```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: sample-job
  generateName: sample-job-
  annotations:
    kueue.x-k8s.io/queue-name: main
spec:
  parallelism: 3
  completions: 30
  suspend: true
  template:
    spec:
      containers:
      - name: pi
        image: quay.io/eduardoarango/pi:ubi8
        command: ["pi",  "1000"]
        resources:
          requests:
            cpu: 1
            memory: "200Mi"
          limits:
            cpu: 1
            memory: "200Mi"
      restartPolicy: Never

Use gcr.io/k8s-staging-perf-tests/sleep:latest

lgtm


Clarify in the agent overview that pyroscope agent is Windows-only.

Honestly it doesn't hurt adding to the CLI as well
https://github.com/pyroscope-io/pyroscope/blob/main/cmd/pyroscope/command/agent.go#L14
I know the command fails when running in a non Windows machine, but still.
Also this is tangential, but we should mention somewhere that the we don't support running the server on Windows.


Bump Extensions and IdentityModel

Bump Microsoft.Extensions.FileProviders.Embedded to 6.0.9 Bump Microsoft.Extensions.Identity.Stores to 6.0.9 Bump System.IdentityModel.Tokens.Jwt to 6.23.1

Codecov Report

Merging #153 (68c4ffa) into master (62cae94) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #153   +/-   ##
=======================================
  Coverage   23.17%   23.17%
=======================================
  Files          36       36
  Lines         725      725
=======================================
  Hits          168      168
  Misses        557      557

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Using custom typescript components (not replacements) breaking build.

Has any had difficulty using custom Typescript components (not replacement components) imported via the files props. My component renders when it's JavaScript but when I add TypeScript, such as an interface for its props, it breaks. I'm assuming what the bundler is doing is mapping the myComponent string to the contents of util/MyComponent.tsx file. Because the typescript isn't be parsed before get called in an .mdx, it breaks.
    const { code, frontmatter } = await bundleMDX(source, {
        cwd: NOTES_DATA_PATH,
        files: {
             "./myComponent": "util/MyComponent.tsx"
        },
    });

You can close this 1 off. I was able to solve (unrelated to mdx-bundler).


Update php.yml

If we'll leave this as "an named" - it's unobvious is there a typo (as it really is) or is it an error (like if you wanted to write "an unnamed" which is perfectly true)

Thank you @velikanov!


Switch on:change doesn't fire

Just wanted to know how to intercept Switch click events, or if they're broken.  I have the following:
export let isEnabled;
function toggle() {
  console.log('toggling', isEnabled);
  // This function does asynchronous work, resulting in the parent toggling isEnabled when done.
}
// ...
<Switch value={isEnabled} label="Enabled" on:click={toggle} />

The expected behaviour is to see "toggling" printed out, and have the Switch not change its setting when clicked, only when isEnabled is updated.
Actually, the "toggling" message is never printed, and the Switch changes its setting when clicked.
Thanks!

<input id="ad{purse.pursePetname}" type="checkbox" on:click={toggleAutoDeposit} checked={purse.depositBoardId} /> AutoDeposit

works as I expect.  I tried using on:click with the Switch, but that doesn't work either.

    <div on:click={toggle}>
      <Switch value={isEnabled} label="Enabled" />
    </div>

mostly does what I want, except for the visual artifact of the switch briefly toggling and untoggling.

Both on:click bound on the wrapper and on:change bound on the hidden input don't fire.

Sounds a bit like the React way of doing things, where the Component is completely controlled by its props. How about this:
<script lang="ts">
    import {Switch} from 'smelte/src';
    let checked=false
    let checktext = "click me";
    const setCheck = (c:boolean) : string => {
        if (checked){
            if (Math.random()>.5){
	        return "Checked";
	    }
	    checked=false;
	    return "You failed to check me correctly";
	}
	return "click me";
    }
    $: checktext = setCheck(checked);
</script>
<Switch bind:value={checked}/>
<div>{checktext}</div>

https://github.com/matyunya/smelte/blob/6b054cfef5e354e294b5346e27e08131a21853f2/src/components/Switch/Switch.svelte#L52-L56
The check handler is not presently exposed to the caller -- only the value.  The idea is to use bind:value like:
      <Switch bind:value={isEnabled} label="Enabled" />


Redirect to 404 Page - working

First thing, PLEASE READ THIS: ReactPlay Code Review Checklist

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
When we entered anything in the route path, there was no 404 page, so I added one to the routing.
Fixes #847
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Type anything in Route path  like http://localhost:3000/playssdd.
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce.
Checklist:

[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Screenshots or example output

@atapas sir and @koustov bro Please check this PR.

@atapas sir and @koustov bro Please check this PR.

As I'm on vacation,it may take a bit longer. Will check soon.

The 404 page still has some issues. I am not holding this PR for those issues, create a new one on #855


ibu mgmt: remove workaround for lca backup/restore bug

Remove workaround when extra manifests resource must exist before starting upgrade

/cc @achuzhoy

/lgtm


Showing the size of a Cachebox (micro, small...) in the Compass

I've got a suggestion: Can you insert the size of a Cachebox (micro, small...) into the Compass? Everytime on using the compas I have to go back to the cache details to remember what size i'm looking for!
Look at Facebook - I already have 6 supporters

Is this worth to keep it open ?
Right now we focus on having all the navigation tools equally, so the compass is no longer the "one and only".
I think implementing a new function into that is useless...

I have implemented it a few months ago, but only locally. The complete compass-activity must be redone, there are too many bugs.

I think this is still feasible. BTW, the idea of a compass overlay over the map mentioned in the link wouldn't be that bad either....

Map? Another overlay? OOM? :D It's a good idea, but I'm not sure if it's possible with our memory-problems.

As there are other applications out there that mange this I think it is not undoable per se. But it is of course meaningful first after we understood and managed the map related OOM issues accordingly.

Thinking about it we could use the already existing position overlay here ....


Update MD file on new branch 2017-23-18_15-11-48

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Build issue on NetBSD

I am trying to build LTSmin on NetBSD.
I get an error during configure as it tests for function
pthread_mutexattr_setpshared
On NetBSD man pthread_mutexattr_setpshared says:
BUGS
The pthread_mutexattr_getpshared() and pthread_mutexattr_setpshared()
functions are hidden by default since only thread shared attributes
are supported.
Given this, what workaround would you suggest - both for the configure
script and use of this function in src/hre/hre_pthread.c.

patches.txt
Have attached patches that led to a successful build on NetBSD.

Would you mind formatting this as a PR, ie.build a fork of current version, edit the files and then build a PR (contribute button on your fork).
This would make it easier to integrate, netBSD is not the main platform but minor changes such as these are ok if they are formatted as a PR it's easier than diff format.

Above patches were on the last released version. I had a look at the master branch and the patches do not seem to apply as-is. Will need some work on this. Will take it up when time permits.


Warning:  ignores the history prop appears while Memory Router still accepts and handle this property

Version
react-router 5., react-router-native 5.
Test Case
Pass history property (created by createMemoryHistory) to NativeRouter or MemoryRouter
Steps to reproduce
Check dev tools
Expected Behavior
Warning message does not appear
Actual Behavior
Warning message appears
Note
This message confuses me because with proper history it works great, so I do not understand is it bad practice to use history in Memory/NativeRouter or warning is invalid.

If you're making your own history, just use <Router> instead.
const history = createMemoryHistory()
<Router history={history} />


Emails to @mgrdcm not deliverable

Hey @mgrdcm, as a project lead we need to be able to reach you via email and the email address that the Jazzband site has fetched from the GitHub API is defunct according our email provider. Please reach out to me about this so you can receive email notifications again.
I've temporarily disabled your project lead permissions to mitigate a possible domain take over.
@aleksihakli FYI ^

@jezdez thanks for letting me know as well! I'll try and handle releases in the meanwhile.

Hey @jezdez!  Sorry, my colo'd server had some hardware problems.  I've fixed my profile.

@mgrdcm Hey there, thank you for updating your GitHub profile, sadly that's not enough for this to work since we're actually fetching the email addresses from your GitHub user info, so basically the actual email addresses that you added to GitHub and verified. Could you double-check if a working email address is listed on your https://github.com/settings/emails?
Alternatively, it would help if you would re-login on https://jazzband.co/ to sync your profile info again. Thanks again for your help in this matter!

@jezdez  Done!  It was showing as pending authorization so that link must have broken at some point.  How does it look now?

@mgrdcm That did the trick, thank you! I've reinstated you as project lead. If you don't mind, I'll leave @aleksihakli as a backup. Cheers!

Oh absolutely @jezdez the more the merrier.  Actually since I've had that power I don't think I've even handled a release yet!