IOS Commissioning Failed | mDNS discovery Timeout

Background:

Commissioning ESP32 WRoom 32D through IOS
USING: lighting-app example & CHIP Tool darwin
Commissioning Succeeds through CHIP TOOL on MacOS
Commissionin Succeeded a couple of times using CHIP TOOL on IOS (about 40 times). Commissioning then started failing

Problem:

Commissioning finished & succeeded multiple times on IOS, then started failing
Fail Error IOS:  CHIPTool[1329:109531] Error retrieving device informations over Mdns: Error Domain=MTRErrorDomain Code=9 "Transaction timed out." UserInfo={NSLocalizedDescription=Transaction timed out., underlyingError=<MTRErrorHolder: 0x2817aafc0>}
Fail Error ESP32: E (105380) chip[ZCL]: OpCreds: Got FailSafeTimerExpired

Exploring the persistance of the error:

Changed Commisisoning Network Used, same error remained
Tried other ESP32 examples, same error remained
Tried using ESP32 Factory provider for the Certificate, same error remained
Tried creating a new ESP32 matter app with customized clusters (was a simple on-off light) , same error remained
Tried creating a new IOS matter app using Swift UI bridged from the Objective C matter framework using a bridging header, same error remained

IOS CHIP Tool commissioning log:
 2022-08-22 23:06:07.715730+0300 CHIPTool[1329:109325] New SSID: KifahK.com Password: 03235059
2022-08-22 23:06:07.716165+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767716] [1329:109325] CHIP: [CTL] Setting wifi credentials from parameters
2022-08-22 23:06:07.716203+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767716] [1329:109325] CHIP: [CTL] Setting attestation nonce to random value
2022-08-22 23:06:07.716304+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767716] [1329:109325] CHIP: [CTL] Setting CSR nonce to random value
2022-08-22 23:06:07.716396+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767716] [1329:109325] CHIP: [CTL] Commission called for node ID 0x000000000000000B
2022-08-22 23:06:07.716420+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767716] [1329:109325] CHIP: [CTL] Commissioning stage next step: 'SecurePairing' -> 'ReadCommissioningInfo'
2022-08-22 23:06:07.716438+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767716] [1329:109325] CHIP: [CTL] Performing next commissioning step 'ReadCommissioningInfo'
2022-08-22 23:06:07.716453+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767716] [1329:109325] CHIP: [CTL] Sending request for commissioning information
2022-08-22 23:06:07.716777+0300 CHIPTool[1329:109325] [all] 🟢 [1661198767716] [1329:109325] CHIP: [DMG] SendReadRequest ReadClient[0x120565220]: Sending Read Request
2022-08-22 23:06:07.717821+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767717] [1329:109325] CHIP: [IN] Prepared secure message 0x16b1df680 to 0xFFFFFFFB00000000 (0)  of type 0x2 and protocolId (0, 1) on exchange 46752i with MessageCounter:5175733.
2022-08-22 23:06:07.717860+0300 CHIPTool[1329:109325] [all] 🔵 [1661198767717] [1329:109325] CHIP: [IN] Sending encrypted msg 0x16b1df680 with MessageCounter:5175733 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48C742 msec
2022-08-22 23:06:07.717887+0300 CHIPTool[1329:109325] [all] 🟢 [1661198767717] [1329:109325] CHIP: [DMG] MoveToState ReadClient[0x120565220]: Moving to [AwaitingIn]
2022-08-22 23:06:07.978823+0300 CHIPTool[1329:109531] [all] 🔵 [1661198767978] [1329:109531] CHIP: [EM] Received message of type 0x5 with protocolId (0, 1) and MessageCounter:55635521 on exchange 46752i
2022-08-22 23:06:07.979204+0300 CHIPTool[1329:109531] [all] 🟢 [1661198767979] [1329:109531] CHIP: [EM] Found matching exchange: 46752i, Delegate: 0x120565230
2022-08-22 23:06:07.986869+0300 CHIPTool[1329:109531] [all] 🔵 [1661198767986] [1329:109531] CHIP: [CTL] ----- NetworkCommissioning Features: has WiFi. endpointid = 0
2022-08-22 23:06:07.988568+0300 CHIPTool[1329:109531] [all] 🔵 [1661198767988] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'ReadCommissioningInfo'
2022-08-22 23:06:07.988923+0300 CHIPTool[1329:109531] [all] 🔵 [1661198767988] [1329:109531] CHIP: [CTL] Commissioning stage next step: 'ReadCommissioningInfo' -> 'ArmFailSafe'
2022-08-22 23:06:07.989069+0300 CHIPTool[1329:109531] [all] 🔵 [1661198767989] [1329:109531] CHIP: [CTL] Performing next commissioning step 'ArmFailSafe'
2022-08-22 23:06:07.989301+0300 CHIPTool[1329:109531] [all] 🔵 [1661198767989] [1329:109531] CHIP: [CTL] Arming failsafe (60 seconds)
2022-08-22 23:06:07.992306+0300 CHIPTool[1329:109531] [all] 🟢 [1661198767992] [1329:109531] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:07.992648+0300 CHIPTool[1329:109531] [all] 🟢 [1661198767992] [1329:109531] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:07.993242+0300 CHIPTool[1329:109531] [all] 🔵 [1661198767993] [1329:109531] CHIP: [IN] Prepared secure message 0x16b523390 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46753i with MessageCounter:5175734.
2022-08-22 23:06:07.993456+0300 CHIPTool[1329:109531] [all] 🔵 [1661198767993] [1329:109531] CHIP: [IN] Sending encrypted msg 0x16b523390 with MessageCounter:5175734 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48C855 msec
2022-08-22 23:06:07.994203+0300 CHIPTool[1329:109531] [all] 🟢 [1661198767994] [1329:109531] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:08.100550+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768100] [1329:109531] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635522 on exchange 46753i
2022-08-22 23:06:08.100964+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768100] [1329:109531] CHIP: [EM] Found matching exchange: 46753i, Delegate: 0x121a08c68
2022-08-22 23:06:08.101207+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768101] [1329:109531] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:08.101756+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768101] [1329:109531] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_0030 Command=0x0000_0001
2022-08-22 23:06:08.103537+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768103] [1329:109531] CHIP: [CTL] Received ArmFailSafe response errorCode=0
2022-08-22 23:06:08.104008+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768103] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'ArmFailSafe'
2022-08-22 23:06:08.104358+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768104] [1329:109531] CHIP: [CTL] No NetworkScan enabled or WiFi/Thread endpoint not specified, skipping ScanNetworks
2022-08-22 23:06:08.104592+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768104] [1329:109531] CHIP: [CTL] Commissioning stage next step: 'ArmFailSafe' -> 'ConfigRegulatory'
2022-08-22 23:06:08.104805+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768104] [1329:109531] CHIP: [CTL] Performing next commissioning step 'ConfigRegulatory'
2022-08-22 23:06:08.104996+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768104] [1329:109531] CHIP: [CTL] Setting Regulatory Config
2022-08-22 23:06:08.105442+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768105] [1329:109531] CHIP: [CTL] Device does not support configurable regulatory location
2022-08-22 23:06:08.106768+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768106] [1329:109531] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:08.107086+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768107] [1329:109531] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:08.107931+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768107] [1329:109531] CHIP: [IN] Prepared secure message 0x16b522b40 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46754i with MessageCounter:5175735.
2022-08-22 23:06:08.108264+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768108] [1329:109531] CHIP: [IN] Sending encrypted msg 0x16b522b40 with MessageCounter:5175735 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48C8C8 msec
2022-08-22 23:06:08.109422+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768109] [1329:109531] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:08.109796+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768109] [1329:109531] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:08.250527+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768250] [1329:109676] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635523 on exchange 46754i
2022-08-22 23:06:08.251016+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768251] [1329:109676] CHIP: [EM] Found matching exchange: 46754i, Delegate: 0x121a06408
2022-08-22 23:06:08.251288+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768251] [1329:109676] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:08.251727+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768251] [1329:109676] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_0030 Command=0x0000_0003
2022-08-22 23:06:08.251955+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768251] [1329:109676] CHIP: [CTL] Received SetRegulatoryConfig response errorCode=0
2022-08-22 23:06:08.252169+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768252] [1329:109676] CHIP: [CTL] Successfully finished commissioning step 'ConfigRegulatory'
2022-08-22 23:06:08.252354+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768252] [1329:109676] CHIP: [CTL] Commissioning stage next step: 'ConfigRegulatory' -> 'SendPAICertificateRequest'
2022-08-22 23:06:08.264995+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768264] [1329:109676] CHIP: [CTL] Performing next commissioning step 'SendPAICertificateRequest'
2022-08-22 23:06:08.265980+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768265] [1329:109676] CHIP: [CTL] Sending request for PAI certificate
2022-08-22 23:06:08.266163+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768266] [1329:109676] CHIP: [CTL] Sending Certificate Chain request to 0x12400fe00 device
2022-08-22 23:06:08.268932+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768268] [1329:109676] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:08.269529+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768269] [1329:109676] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:08.270012+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768269] [1329:109676] CHIP: [IN] Prepared secure message 0x16b37ea70 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46755i with MessageCounter:5175736.
2022-08-22 23:06:08.270157+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768270] [1329:109676] CHIP: [IN] Sending encrypted msg 0x16b37ea70 with MessageCounter:5175736 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48C96A msec
2022-08-22 23:06:08.270680+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768270] [1329:109676] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:08.270868+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768270] [1329:109676] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:08.493120+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768493] [1329:109531] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635524 on exchange 46755i
2022-08-22 23:06:08.493551+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768493] [1329:109531] CHIP: [EM] Found matching exchange: 46755i, Delegate: 0x121a08c68
2022-08-22 23:06:08.493858+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768493] [1329:109531] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:08.494293+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768494] [1329:109531] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_003E Command=0x0000_0003
2022-08-22 23:06:08.494517+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768494] [1329:109531] CHIP: [CTL] Received certificate chain from the device
2022-08-22 23:06:08.494735+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768494] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'SendPAICertificateRequest'
2022-08-22 23:06:08.495195+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768495] [1329:109531] CHIP: [CTL] Commissioning stage next step: 'SendPAICertificateRequest' -> 'SendDACCertificateRequest'
2022-08-22 23:06:08.495415+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768495] [1329:109531] CHIP: [CTL] Performing next commissioning step 'SendDACCertificateRequest'
2022-08-22 23:06:08.495596+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768495] [1329:109531] CHIP: [CTL] Sending request for DAC certificate
2022-08-22 23:06:08.495791+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768495] [1329:109531] CHIP: [CTL] Sending Certificate Chain request to 0x12400fe00 device
2022-08-22 23:06:08.496264+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768496] [1329:109531] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:08.496747+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768496] [1329:109531] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:08.498723+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768498] [1329:109531] CHIP: [IN] Prepared secure message 0x16b522a90 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46756i with MessageCounter:5175737.
2022-08-22 23:06:08.499186+0300 CHIPTool[1329:109531] [all] 🔵 [1661198768499] [1329:109531] CHIP: [IN] Sending encrypted msg 0x16b522a90 with MessageCounter:5175737 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48CA4F msec
2022-08-22 23:06:08.500424+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768500] [1329:109531] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:08.500891+0300 CHIPTool[1329:109531] [all] 🟢 [1661198768500] [1329:109531] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:08.702203+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768702] [1329:109676] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635525 on exchange 46756i
2022-08-22 23:06:08.702639+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768702] [1329:109676] CHIP: [EM] Found matching exchange: 46756i, Delegate: 0x121c04dc8
2022-08-22 23:06:08.702939+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768702] [1329:109676] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:08.703386+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768703] [1329:109676] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_003E Command=0x0000_0003
2022-08-22 23:06:08.703615+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768703] [1329:109676] CHIP: [CTL] Received certificate chain from the device
2022-08-22 23:06:08.703835+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768703] [1329:109676] CHIP: [CTL] Successfully finished commissioning step 'SendDACCertificateRequest'
2022-08-22 23:06:08.704040+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768704] [1329:109676] CHIP: [CTL] Commissioning stage next step: 'SendDACCertificateRequest' -> 'SendAttestationRequest'
2022-08-22 23:06:08.704235+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768704] [1329:109676] CHIP: [CTL] Performing next commissioning step 'SendAttestationRequest'
2022-08-22 23:06:08.704415+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768704] [1329:109676] CHIP: [CTL] Sending Attestation Request to the device.
2022-08-22 23:06:08.704888+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768704] [1329:109676] CHIP: [CTL] Sending Attestation request to 0x12400fe00 device
2022-08-22 23:06:08.705614+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768705] [1329:109676] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:08.705908+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768705] [1329:109676] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:08.707195+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768707] [1329:109676] CHIP: [IN] Prepared secure message 0x16b37ea70 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46757i with MessageCounter:5175738.
2022-08-22 23:06:08.707505+0300 CHIPTool[1329:109676] [all] 🔵 [1661198768707] [1329:109676] CHIP: [IN] Sending encrypted msg 0x16b37ea70 with MessageCounter:5175738 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48CB1F msec
2022-08-22 23:06:08.708653+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768708] [1329:109676] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:08.708929+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768708] [1329:109676] CHIP: [CTL] Sent Attestation request, waiting for the Attestation Information
2022-08-22 23:06:08.709155+0300 CHIPTool[1329:109676] [all] 🟢 [1661198768709] [1329:109676] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:09.245538+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769245] [1329:109531] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635526 on exchange 46757i
2022-08-22 23:06:09.246064+0300 CHIPTool[1329:109531] [all] 🟢 [1661198769246] [1329:109531] CHIP: [EM] Found matching exchange: 46757i, Delegate: 0x121a08c68
2022-08-22 23:06:09.246366+0300 CHIPTool[1329:109531] [all] 🟢 [1661198769246] [1329:109531] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:09.246804+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769246] [1329:109531] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_003E Command=0x0000_0001
2022-08-22 23:06:09.247051+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769247] [1329:109531] CHIP: [CTL] Received Attestation Information from the device
2022-08-22 23:06:09.247391+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769247] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'SendAttestationRequest'

2022-08-22 23:06:09.254246+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769254] [1329:109531] CHIP: [CTL] Commissioning stage next step: 'SendAttestationRequest' -> 'AttestationVerification'
2022-08-22 23:06:09.255519+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769255] [1329:109531] CHIP: [CTL] Performing next commissioning step 'AttestationVerification'
2022-08-22 23:06:09.255799+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769255] [1329:109531] CHIP: [CTL] Verifying attestation
2022-08-22 23:06:09.311155+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769311] [1329:109531] CHIP: [CTL] Successfully validated 'Attestation Information' command received from the device.
2022-08-22 23:06:09.311262+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769311] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'AttestationVerification'
2022-08-22 23:06:09.311306+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769311] [1329:109531] CHIP: [CTL] Commissioning stage next step: 'AttestationVerification' -> 'SendOpCertSigningRequest'
2022-08-22 23:06:09.311356+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769311] [1329:109531] CHIP: [CTL] Performing next commissioning step 'SendOpCertSigningRequest'
2022-08-22 23:06:09.311396+0300 CHIPTool[1329:109531] [all] 🟢 [1661198769311] [1329:109531] CHIP: [CTL] Sending CSR request to 0x12400fe00 device
2022-08-22 23:06:09.311849+0300 CHIPTool[1329:109531] [all] 🟢 [1661198769311] [1329:109531] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:09.311888+0300 CHIPTool[1329:109531] [all] 🟢 [1661198769311] [1329:109531] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:09.312057+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769312] [1329:109531] CHIP: [IN] Prepared secure message 0x16b520730 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46758i with MessageCounter:5175739.
2022-08-22 23:06:09.312106+0300 CHIPTool[1329:109531] [all] 🔵 [1661198769312] [1329:109531] CHIP: [IN] Sending encrypted msg 0x16b520730 with MessageCounter:5175739 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48CD7C msec
2022-08-22 23:06:09.312249+0300 CHIPTool[1329:109531] [all] 🟢 [1661198769312] [1329:109531] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:09.312280+0300 CHIPTool[1329:109531] [all] 🟢 [1661198769312] [1329:109531] CHIP: [CTL] Sent CSR request, waiting for the CSR
2022-08-22 23:06:09.312319+0300 CHIPTool[1329:109531] [all] 🟢 [1661198769312] [1329:109531] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:10.383613+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770383] [1329:109531] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635527 on exchange 46758i
2022-08-22 23:06:10.384027+0300 CHIPTool[1329:109531] [all] 🟢 [1661198770384] [1329:109531] CHIP: [EM] Found matching exchange: 46758i, Delegate: 0x12059b728
2022-08-22 23:06:10.384298+0300 CHIPTool[1329:109531] [all] 🟢 [1661198770384] [1329:109531] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:10.384753+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770384] [1329:109531] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_003E Command=0x0000_0005
2022-08-22 23:06:10.384998+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770384] [1329:109531] CHIP: [CTL] Received certificate signing request from the device
2022-08-22 23:06:10.385241+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770385] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'SendOpCertSigningRequest'
2022-08-22 23:06:10.385455+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770385] [1329:109531] CHIP: [CTL] Commissioning stage next step: 'SendOpCertSigningRequest' -> 'ValidateCSR'
2022-08-22 23:06:10.385665+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770385] [1329:109531] CHIP: [CTL] Performing next commissioning step 'ValidateCSR'
2022-08-22 23:06:10.411929+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770411] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'ValidateCSR'
2022-08-22 23:06:10.412220+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770412] [1329:109531] CHIP: [CTL] Commissioning stage next step: 'ValidateCSR' -> 'GenerateNOCChain'
2022-08-22 23:06:10.412301+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770412] [1329:109531] CHIP: [CTL] Performing next commissioning step 'GenerateNOCChain'
2022-08-22 23:06:10.412406+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770412] [1329:109531] CHIP: [CTL] Getting certificate chain for the device from the issuer
2022-08-22 23:06:10.426929+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770426] [1329:109531] CHIP: [CTL] Received callback from the CA for NOC Chain generation. Status /Volumes/1tbssd/GalMatter/connectedhomeip/src/darwin/Framework/CHIP/MTROperationalCredentialsDelegate.mm:321: Success
2022-08-22 23:06:10.427001+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770426] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'GenerateNOCChain'
2022-08-22 23:06:10.427126+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770427] [1329:109531] CHIP: [CTL] Performing next commissioning step 'SendTrustedRootCert'
2022-08-22 23:06:10.427168+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770427] [1329:109531] CHIP: [CTL] Sending root certificate to the device
2022-08-22 23:06:10.427895+0300 CHIPTool[1329:109531] [all] 🟢 [1661198770427] [1329:109531] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:10.427950+0300 CHIPTool[1329:109531] [all] 🟢 [1661198770427] [1329:109531] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:10.428352+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770428] [1329:109531] CHIP: [IN] Prepared secure message 0x16b51eb00 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46759i with MessageCounter:5175740.
2022-08-22 23:06:10.428402+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770428] [1329:109531] CHIP: [IN] Sending encrypted msg 0x16b51eb00 with MessageCounter:5175740 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48D1D8 msec
2022-08-22 23:06:10.428563+0300 CHIPTool[1329:109531] [all] 🟢 [1661198770428] [1329:109531] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:10.428603+0300 CHIPTool[1329:109531] [all] 🔵 [1661198770428] [1329:109531] CHIP: [CTL] Sent root certificate to the device
2022-08-22 23:06:10.428774+0300 CHIPTool[1329:109531] [all] 🟢 [1661198770428] [1329:109531] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:11.191505+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771191] [1329:109631] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635528 on exchange 46759i
2022-08-22 23:06:11.191935+0300 CHIPTool[1329:109631] [all] 🟢 [1661198771191] [1329:109631] CHIP: [EM] Found matching exchange: 46759i, Delegate: 0x1205bdc38
2022-08-22 23:06:11.192189+0300 CHIPTool[1329:109631] [all] 🟢 [1661198771192] [1329:109631] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:11.192733+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771192] [1329:109631] CHIP: [DMG] Received Command Response Status for Endpoint=0 Cluster=0x0000_003E Command=0x0000_000B Status=0x0
2022-08-22 23:06:11.193053+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771193] [1329:109631] CHIP: [CTL] Device confirmed that it has received the root certificate
2022-08-22 23:06:11.193318+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771193] [1329:109631] CHIP: [CTL] Successfully finished commissioning step 'SendTrustedRootCert'
2022-08-22 23:06:11.193502+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771193] [1329:109631] CHIP: [CTL] Commissioning stage next step: 'SendTrustedRootCert' -> 'SendNOC'
2022-08-22 23:06:11.193797+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771193] [1329:109631] CHIP: [CTL] Performing next commissioning step 'SendNOC'
2022-08-22 23:06:11.194622+0300 CHIPTool[1329:109631] [all] 🟢 [1661198771194] [1329:109631] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:11.194895+0300 CHIPTool[1329:109631] [all] 🟢 [1661198771194] [1329:109631] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:11.197884+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771197] [1329:109631] CHIP: [IN] Prepared secure message 0x16b266b40 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46760i with MessageCounter:5175741.
2022-08-22 23:06:11.198657+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771198] [1329:109631] CHIP: [IN] Sending encrypted msg 0x16b266b40 with MessageCounter:5175741 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48D4DA msec
2022-08-22 23:06:11.200061+0300 CHIPTool[1329:109631] [all] 🟢 [1661198771200] [1329:109631] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:11.200485+0300 CHIPTool[1329:109631] [all] 🔵 [1661198771200] [1329:109631] CHIP: [CTL] Sent operational certificate to the device
2022-08-22 23:06:11.200863+0300 CHIPTool[1329:109631] [all] 🟢 [1661198771200] [1329:109631] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:12.091240+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772091] [1329:109631] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635529 on exchange 46760i
2022-08-22 23:06:12.091660+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772091] [1329:109631] CHIP: [EM] Found matching exchange: 46760i, Delegate: 0x121c04dc8
2022-08-22 23:06:12.091919+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772091] [1329:109631] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:12.092352+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772092] [1329:109631] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_003E Command=0x0000_0008
2022-08-22 23:06:12.092855+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772092] [1329:109631] CHIP: [CTL] Device returned status 0 on receiving the NOC
2022-08-22 23:06:12.093122+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772093] [1329:109631] CHIP: [CTL] Operational credentials provisioned on device 0x12400fe00
2022-08-22 23:06:12.093329+0300 CHIPTool[1329:109631] DevicePairingDelegate status updated: 0
2022-08-22 23:06:12.093731+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772093] [1329:109631] CHIP: [CTL] Successfully finished commissioning step 'SendNOC'
2022-08-22 23:06:12.093961+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772093] [1329:109631] CHIP: [CTL] Commissioning stage next step: 'SendNOC' -> 'WiFiNetworkSetup'
2022-08-22 23:06:12.094169+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772094] [1329:109631] CHIP: [CTL] Performing next commissioning step 'WiFiNetworkSetup'
2022-08-22 23:06:12.096864+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772096] [1329:109631] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:12.097334+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772097] [1329:109631] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:12.098680+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772098] [1329:109631] CHIP: [IN] Prepared secure message 0x16b266a40 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46761i with MessageCounter:5175742.
2022-08-22 23:06:12.099106+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772099] [1329:109631] CHIP: [IN] Sending encrypted msg 0x16b266a40 with MessageCounter:5175742 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48D85F msec
2022-08-22 23:06:12.100396+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772100] [1329:109631] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:12.100790+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772100] [1329:109631] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:12.210319+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772210] [1329:109631] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635530 on exchange 46761i
2022-08-22 23:06:12.210731+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772210] [1329:109631] CHIP: [EM] Found matching exchange: 46761i, Delegate: 0x121a08c68
2022-08-22 23:06:12.210991+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772210] [1329:109631] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:12.211444+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772211] [1329:109631] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_0031 Command=0x0000_0005
2022-08-22 23:06:12.211689+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772211] [1329:109631] CHIP: [CTL] Received NetworkConfig response, networkingStatus=0
2022-08-22 23:06:12.211901+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772211] [1329:109631] CHIP: [CTL] Successfully finished commissioning step 'WiFiNetworkSetup'
2022-08-22 23:06:12.212097+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772212] [1329:109631] CHIP: [CTL] Commissioning stage next step: 'WiFiNetworkSetup' -> 'WiFiNetworkEnable'
2022-08-22 23:06:12.212281+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772212] [1329:109631] CHIP: [CTL] Setting wifi connection time min = 30
2022-08-22 23:06:12.212479+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772212] [1329:109631] CHIP: [CTL] Performing next commissioning step 'WiFiNetworkEnable'
2022-08-22 23:06:12.214702+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772214] [1329:109631] CHIP: [DMG] ICR moving to [AddingComm]
2022-08-22 23:06:12.215251+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772215] [1329:109631] CHIP: [DMG] ICR moving to [AddedComma]
2022-08-22 23:06:12.216746+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772216] [1329:109631] CHIP: [IN] Prepared secure message 0x16b266b20 to 0xFFFFFFFB00000000 (0)  of type 0x8 and protocolId (0, 1) on exchange 46762i with MessageCounter:5175743.
2022-08-22 23:06:12.217444+0300 CHIPTool[1329:109631] [all] 🔵 [1661198772217] [1329:109631] CHIP: [IN] Sending encrypted msg 0x16b266b20 with MessageCounter:5175743 to 0xFFFFFFFB00000000 (0) at monotonic time:<PHONE_NUMBER>48D8D5 msec
2022-08-22 23:06:12.218586+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772218] [1329:109631] CHIP: [DMG] ICR moving to [CommandSen]
2022-08-22 23:06:12.218923+0300 CHIPTool[1329:109631] [all] 🟢 [1661198772218] [1329:109631] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:23.791498+0300 CHIPTool[1329:109631] [all] 🔵 [1661198783791] [1329:109631] CHIP: [EM] Received message of type 0x9 with protocolId (0, 1) and MessageCounter:55635531 on exchange 46762i
2022-08-22 23:06:23.791907+0300 CHIPTool[1329:109631] [all] 🟢 [1661198783791] [1329:109631] CHIP: [EM] Found matching exchange: 46762i, Delegate: 0x121a0bbc8
2022-08-22 23:06:23.792201+0300 CHIPTool[1329:109631] [all] 🟢 [1661198783792] [1329:109631] CHIP: [DMG] ICR moving to [ResponseRe]
2022-08-22 23:06:23.792842+0300 CHIPTool[1329:109631] [all] 🔵 [1661198783792] [1329:109631] CHIP: [DMG] Received Command Response Data, Endpoint=0 Cluster=0x0000_0031 Command=0x0000_0007
2022-08-22 23:06:23.794817+0300 CHIPTool[1329:109631] [all] 🔵 [1661198783794] [1329:109631] CHIP: [CTL] Received ConnectNetwork response, networkingStatus=0
2022-08-22 23:06:23.795282+0300 CHIPTool[1329:109631] [all] 🔵 [1661198783795] [1329:109631] CHIP: [CTL] Successfully finished commissioning step 'WiFiNetworkEnable'
2022-08-22 23:06:23.795515+0300 CHIPTool[1329:109631] [all] 🔵 [1661198783795] [1329:109631] CHIP: [CTL] Commissioning stage next step: 'WiFiNetworkEnable' -> 'FindOperational'
2022-08-22 23:06:23.795729+0300 CHIPTool[1329:109631] [all] 🔵 [1661198783795] [1329:109631] CHIP: [CTL] Performing next commissioning step 'FindOperational'
2022-08-22 23:06:23.795935+0300 CHIPTool[1329:109631] [all] 🟢 [1661198783795] [1329:109631] CHIP: [CSM] FindOrEstablishSession: PeerId = [1:000000000000000B]
2022-08-22 23:06:23.796136+0300 CHIPTool[1329:109631] [all] 🟢 [1661198783796] [1329:109631] CHIP: [CSM] FindOrEstablishSession: No existing OperationalSessionSetup instance found
2022-08-22 23:06:23.796408+0300 CHIPTool[1329:109631] [all] 🟢 [1661198783796] [1329:109631] CHIP: [CTL] OperationalSessionSetup[1:000000000000000B]: State change 1 --> 2
2022-08-22 23:06:23.796625+0300 CHIPTool[1329:109631] [all] 🔵 [1661198783796] [1329:109631] CHIP: [DIS] Resolving 448B895A81A66FC1:000000000000000B ...
2022-08-22 23:06:23.796857+0300 CHIPTool[1329:109631] [all] 🟢 [1661198783796] [1329:109631] CHIP: [DIS] Resolve type=_matter._tcp name=448B895A81A66FC1-000000000000000B interface=0
2022-08-22 23:06:23.803115+0300 CHIPTool[1329:109631] [all] 🟢 [1661198783803] [1329:109631] CHIP: [DMG] ICR moving to [AwaitingDe]
2022-08-22 23:06:23.999287+0300 CHIPTool[1329:109631] [all] 🔵 [1661198783999] [1329:109631] CHIP: [DIS] Checking node lookup status after 203 ms
2022-08-22 23:06:38.799165+0300 CHIPTool[1329:109531] [all] 🔵 [1661198798799] [1329:109531] CHIP: [DIS] Checking node lookup status after 15002 ms
2022-08-22 23:06:38.799941+0300 CHIPTool[1329:109531] [all] 🔴 [1661198798799] [1329:109531] CHIP: [DIS] OperationalSessionSetup[1:000000000000000B]: operational discovery failed: ../../../../../../../../../../../../../Volumes/1tbssd/GalMatter/connectedhomeip/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:174: CHIP Error 0x00000032: Timeout
2022-08-22 23:06:38.800189+0300 CHIPTool[1329:109531] [all] 🔵 [1661198798800] [1329:109531] CHIP: [CTL] Device connection failed. Error ../../../../../../../../../../../../../Volumes/1tbssd/GalMatter/connectedhomeip/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:174: CHIP Error 0x00000032: Timeout
2022-08-22 23:06:38.800411+0300 CHIPTool[1329:109531] [all] 🔵 [1661198798800] [1329:109531] CHIP: [CTL] Error on commissioning step 'FindOperational': '../../../../../../../../../../../../../Volumes/1tbssd/GalMatter/connectedhomeip/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:174: CHIP Error 0x00000032: Timeout'
2022-08-22 23:06:38.800597+0300 CHIPTool[1329:109531] [all] 🔴 [1661198798800] [1329:109531] CHIP: [CTL] Failed to perform commissioning step 18
2022-08-22 23:06:38.800797+0300 CHIPTool[1329:109531] [all] 🔵 [1661198798800] [1329:109531] CHIP: [CTL] Going from commissioning step 'FindOperational' with lastErr = '../../../../../../../../../../../../../Volumes/1tbssd/GalMatter/connectedhomeip/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:174: CHIP Error 0x00000032: Timeout' -> 'Cleanup'
2022-08-22 23:06:38.801355+0300 CHIPTool[1329:109531] [all] 🔵 [1661198798801] [1329:109531] CHIP: [CTL] Performing next commissioning step 'Cleanup' with completion status = '../../../../../../../../../../../../../Volumes/1tbssd/GalMatter/connectedhomeip/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:174: CHIP Error 0x00000032: Timeout'
2022-08-22 23:06:38.801581+0300 CHIPTool[1329:109531] [all] 🔵 [1661198798801] [1329:109531] CHIP: [CTL] Successfully finished commissioning step 'Cleanup'
2022-08-22 23:06:38.801840+0300 CHIPTool[1329:109531] DevicePairingDelegate Commissioning complete. NodeId 11 Status ../../../../../../../../../../../../../Volumes/1tbssd/GalMatter/connectedhomeip/src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:174: CHIP Error 0x00000032: Timeout
2022-08-22 23:06:38.803709+0300 CHIPTool[1329:109531] Error retrieving device informations over Mdns: Error Domain=MTRErrorDomain Code=9 "Transaction timed out." UserInfo={NSLocalizedDescription=Transaction timed out., underlyingError=<MTRErrorHolder: 0x2817aafc0>}
2022-08-22 23:07:21.647005+0300 CHIPTool[1329:110132] [all] 🔴 [1661198841646] [1329:110132] CHIP: [BLE] ack recv timeout, closing ep 0x1149b4d78
2022-08-22 23:07:21.647483+0300 CHIPTool[1329:110132] [all] 🟢 [1661198841647] [1329:110132] CHIP: [IN] Clearing BLE pending packets.
2022-08-22 23:07:21.689108+0300 CHIPTool[1329:109675] [all] 🔵 [1661198841689] [1329:109675] CHIP: [BLE] Auto-closing end point's BLE connection.

ESP32 Lighting app commissioning log:
 (60940) chip[DL]: `WIFI_EVENT_STA_CONNECTED`
I (60950) chip[DL]: WiFi station state change: Connecting -> Connecting_Succeeded
I (60950) chip[DL]: WiFi station state change: Connecting_Succeeded -> Connected
I (60960) chip[DL]: WiFi station interface connected
I (60970) light-app-callbacks: PostAttributeChangeCallback - Cluster ID: '0x0030', EndPoint ID: '0x00', Attribute ID: '0x0000'
I (60980) light-app-callbacks: Unhandled cluster ID: 48
I (60980) light-app-callbacks: Current free heap: 99456

I (60990) chip[IN]: Prepared secure message 0x3ffdef94 to 0xFFFFFFFB00000000 (1)  of type 0x9 and protocolId (0, 1) on exchange 46762r with MessageCounter:55635531.
I (61000) chip[IN]: Sending encrypted msg 0x3ffdef94 with MessageCounter:55635531 to 0xFFFFFFFB00000000 (1) at monotonic time:<PHONE_NUMBER>00EB5B msec
I (61010) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (61020) NimBLE: GATT procedure initiated: indicate;
I (61030) NimBLE: att_handle=14

I (61030) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (61040) chip[ZCL]: WiFiDiagnosticsDelegate: OnConnectionStatusChanged
I (61050) chip[DL]: Done driving station state, nothing else to do...
I (61060) app-devicecallbacks: Current free heap: 99456

E (61060) chip[DL]: Long dispatch time: 118 ms, for event type 49152
I (61070) chip[DIS]: Advertise operational node 448B895A81A66FC1-000000000000000B
I (61080) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'.
I (61080) chip[DIS]: mDNS service published: _matter._tcp
I (61090) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (61090) chip[SVR]: Operational advertising enabled
I (61110) app-devicecallbacks: Current free heap: 99432

I (61110) chip[DL]: Updating advertising data
I (61120) app-devicecallbacks: Current free heap: 100964

E (61210) chip[DIS]: Failed to reply to query: 3000004
E (61220) chip[DIS]: Failed to reply to query: 3000004
W (61220) wifi:<ba-add>idx:0 (ifx:0, 50:0f:f5:bd:36:a8), tid:0, ssn:2, winSize:64
I (62250) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (62250) chip[DIS]: Failed to reply to query: 3000004
I (62250) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (62260) chip[DIS]: Failed to reply to query: 3000004
I (62820) esp_netif_handlers: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
I (62820) chip[DL]: IP_EVENT_STA_GOT_IP
I (62820) chip[DL]: IPv4 address ready on WiFi station interface: <IP_ADDRESS>/<IP_ADDRESS> gateway <IP_ADDRESS>
I (62830) chip[DL]: IPv4 Internet connectivity ESTABLISHED
I (62840) app-devicecallbacks: Current free heap: 100532

I (62840) app-devicecallbacks: IPv4 Server ready...
I (62850) chip[DIS]: Updating services using commissioning mode 0
I (62860) chip[DIS]: CHIP minimal mDNS started advertising.
I (62870) chip[DIS]: Advertise operational node 448B895A81A66FC1-000000000000000B
I (62870) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'.
I (62880) chip[DIS]: mDNS service published: _matter._tcp
I (62880) app-devicecallbacks: Current free heap: 100888

I (62890) chip[DIS]: Updating services using commissioning mode 0
I (62900) chip[DIS]: CHIP minimal mDNS started advertising.
I (62910) chip[DIS]: Advertise operational node 448B895A81A66FC1-000000000000000B
I (62910) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'.
I (62920) chip[DIS]: mDNS service published: _matter._tcp
I (62920) app-devicecallbacks: Current free heap: 100040

I (63580) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
I (65210) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (65210) chip[DIS]: Failed to reply to query: 3000004
I (65220) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (65220) chip[DIS]: Failed to reply to query: 3000004
I (66080) NimBLE: GATT procedure initiated: indicate;
I (66080) NimBLE: att_handle=14

I (66080) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (66160) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (68620) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
W (70030) wifi:<ba-add>idx:1 (ifx:0, 50:0f:f5:bd:36:a8), tid:6, ssn:0, winSize:64
I (71120) NimBLE: GATT procedure initiated: indicate;
I (71120) NimBLE: att_handle=14

I (71120) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (71170) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (73210) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (73210) chip[DIS]: Failed to reply to query: 3000004
I (73220) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (73220) chip[DIS]: Failed to reply to query: 3000004
I (73660) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
I (76160) NimBLE: GATT procedure initiated: indicate;
I (76160) NimBLE: att_handle=14

I (76160) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (76210) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (78700) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
I (81200) NimBLE: GATT procedure initiated: indicate;
I (81200) NimBLE: att_handle=14

I (81200) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (81250) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (83740) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
I (86240) NimBLE: GATT procedure initiated: indicate;
I (86240) NimBLE: att_handle=14

I (86240) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (86290) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (88780) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
I (91280) NimBLE: GATT procedure initiated: indicate;
I (91280) NimBLE: att_handle=14

I (91280) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (91330) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (93820) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
I (96320) NimBLE: GATT procedure initiated: indicate;
I (96320) NimBLE: att_handle=14

I (96320) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (96400) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (98890) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
I (100340) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (100340) chip[DIS]: Failed to reply to query: 3000004
I (100340) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (100350) chip[DIS]: Failed to reply to query: 3000004
I (101390) NimBLE: GATT procedure initiated: indicate;
I (101390) NimBLE: att_handle=14

I (101390) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 0
I (101440) chip[DL]: Confirm received for CHIPoBLE TX characteristic indication (con 0) status= 14
I (103930) CHIP[DL]: Write request received for CHIPoBLE RX characteristic con 0 12
I (105290) chip[FS]: Fail-safe timer expired
E (105290) chip[SVR]: Failsafe timer expired
I (105290) chip[SC]: SecureSession[0x3ffc57d0]: Moving from state 'kActive' --> 'kPendingEviction'
E (105300) chip[SVR]: Commissioning failed (attempt 1): 32
I (105310) chip[BLE]: Releasing end point's BLE connection back to application.
I (105320) chip[DIS]: Updating services using commissioning mode 1
I (105330) chip[DIS]: CHIP minimal mDNS started advertising.
I (105330) chip[DIS]: Advertise operational node 448B895A81A66FC1-000000000000000B
I (105340) chip[DIS]: CHIP minimal mDNS configured as 'Operational device'.
I (105350) chip[DIS]: mDNS service published: _matter._tcp
I (105350) chip[DIS]: Advertise commission parameter vendorID=65521 productID=32768 discriminator=3840/15 cm=1
I (105370) chip[DIS]: CHIP minimal mDNS configured as 'Commissionable node device'.
I (105380) chip[DIS]: mDNS service published: _matterc._udp
E (105380) chip[ZCL]: OpCreds: Got FailSafeTimerExpired
E (105380) chip[ZCL]: OpCreds: Proceeding to FailSafeCleanup on fail-safe expiry!
E (105390) chip[FP]: Reverting pending fabric data for fabric 0x1
E (105410) chip[FP]: Warning: metadata not found during delete of fabric 0x1
I (105450) chip[FP]: Fabric (0x1) deleted.
I (105450) chip[ZCL]: UserLabel: Last Fabric index 0x1 was removed
I (105450) chip[ZCL]: OpCreds: Fabric index 0x1 was removed
I (105530) chip[TS]: Pending Last Known Good Time: 2022-08-22T21:52:04
I (105530) chip[TS]: Previous Last Known Good Time: 2022-08-22T21:52:04
I (105530) chip[TS]: Reverted Last Known Good Time to previous value
E (105550) chip[FP]: Warning: metadata not found during delete of fabric 0x1
E (105560) chip[ZCL]: OpCreds: failed to delete fabric at index 1: d8
I (105560) light-app-callbacks: PostAttributeChangeCallback - Cluster ID: '0x0030', EndPoint ID: '0x00', Attribute ID: '0x0000'
I (105570) light-app-callbacks: Unhandled cluster ID: 48
I (105570) light-app-callbacks: Current free heap: 102288

I (105580) app-devicecallbacks: Current free heap: 102288

E (105590) chip[DL]: Long dispatch time: 293 ms, for event type 32782
I (105590) chip[FS]: Fail-safe cleanly disarmed
I (118930) chip[DL]: Write request/command received for CHIPoBLE TX CCCD characteristic (con 0 ) indicate = 0
I (118930) chip[DL]: CHIPoBLE unsubscribe received
E (118930) chip[BLE]: no endpoint for unsub recvd
I (118940) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable, device name MATTER-3840)
I (118950) NimBLE: GAP procedure initiated: advertise;
I (118960) NimBLE: disc_mode=2
I (118960) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (118970) NimBLE:

I (118980) chip[DL]: CHIPoBLE advertising started
I (118980) app-devicecallbacks: Current free heap: 102288

I (119020) chip[DL]: BLE GAP connection terminated (con 0 reason 0x213)
I (119020) app-devicecallbacks: CHIPoBLE disconnected
I (119020) app-devicecallbacks: Current free heap: 102288

I (119030) chip[DL]: Configuring CHIPoBLE advertising (interval 25 ms, connectable, device name MATTER-3840)
I (119040) chip[DL]: Device already advertising, stop active advertisement and restart
I (119050) NimBLE: GAP procedure initiated: stop advertising.

I (119060) NimBLE: GAP procedure initiated: advertise;
I (119060) NimBLE: disc_mode=2
I (119070) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=40 adv_itvl_max=40
I (119080) NimBLE:

I (135320) chip[DL]: Configuring CHIPoBLE advertising (interval 500 ms, connectable, device name MATTER-3840)
I (135320) chip[DL]: Device already advertising, stop active advertisement and restart
I (135330) NimBLE: GAP procedure initiated: stop advertising.

I (135340) NimBLE: GAP procedure initiated: advertise;
I (135340) NimBLE: disc_mode=2
I (135350) NimBLE:  adv_channel_map=0 own_addr_type=1 adv_filter_policy=0 adv_itvl_min=800 adv_itvl_max=800
I (135360) NimBLE:

I (154710) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (154710) chip[DIS]: Failed to reply to query: 3000004
I (154710) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (154720) chip[DIS]: Failed to reply to query: 3000004
I (154730) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (154730) chip[DIS]: Failed to reply to query: 3000004
I (397920) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (397920) chip[DIS]: Failed to reply to query: 3000004
I (397920) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (397930) chip[DIS]: Failed to reply to query: 3000004
I (397940) chip[DIS]: mDNS broadcast full failed in 1 separate send attempts.
E (397940) chip[DIS]: Failed to reply to query: 3000004
I (902430) chip[SVR]: Closing pairing window
I (902430) chip[DIS]: Updating services using commissioning mode 0
I (902430) chip[DIS]: CHIP minimal mDNS started advertising.
I (902440) NimBLE: GAP procedure initiated: stop advertising.

I (902450) chip[DL]: CHIPoBLE advertising stopped
I (902450) app-devicecallbacks: Current free heap: 103872

I found darwin app sometimes  happend this issue when commissioning succeeded a couple of times. I guess when multi devices in the same network, this issue will happened.

@JourneyYoung I only had 2 devices commissioned on the fabric when this issue happened & they weren't even connected.  How does matter expect its protocol be adpoted as a standard if there are such basic reliability issues? It's supposed to release this fall. I think they most probably would delay it.

@LiwaaK For this step:

Commissionin Succeeded a couple of times using CHIP TOOL on IOS (about 40 times). Commissioning then started failing

what were the exact steps involved? Were >40 different devices used? Or was one device reset multiple times? Were any unpairing or reset steps performed on the iOS CHIPTool app?
It would be good to understand exactly how to reproduce this.

40 is a rough number that represents the net number of times commissioning succeeded before the error happened. I only tested with 6 ESPs. I simply tested the process of commissioning about 40 times with different device certificates and fabric Ids. The number is meant to simply express that the error wasn't occuring initially.
During the first time this error appeared, about 5 devices were commissioned on the fabric. The 6th device failed. After a few tests with commissioning for a different Access point and still failing, I erased flash of off all ESPs, and created a new fabric.
With the new fabric having no devices commissioned, for the same AP, the commissioning failed.
When trying with a new Access point, commissioning failed. There were 2 times were commissioning actually succeeded, during these:

Disconnected the iOS phone from the Access point and reconnected it once mDNS broadcasting on the ESP32 started
I couldn't recreate this more than 2 times though.

At this point,I had tried 2 different APs, and it failed, so I posted this issue.
I then tried to use one of the ESP32s as an Access point, and test commissioning devices to that AP. Commissioning Succeeded.

For 2 Access points that are home internet routers, commissioning failed
For the ESP32 as an access point, commissioning succeeds.

It seems that it doesn't work with certain APs for certain reasons, I'm further exploring this.

This issue seems to still be present. As described by @LiwaaK starts failing after successfully commissioning the ESP32 device many times before I get a CHIP Error 0x000002022-12-26 20:44:54.450794+0100 CHIPTool[11618:1268044] Error retrieving device informations over Mdns: Error Domain=MTRErrorDomain Code=1 "Undefined error:11." UserInfo={underlyingError=<MTRErrorHolder: 0x2812fcd80>, NSLocalizedDescription=Undefined error:11., errorCode=11}.
Tested with the All-Clusters-App example and the CHIP Tool App for IOS on commit 93da711

@noname202 The issue seems to be associated with certain access points that don’t reliably support mDNS. I haven’t delved deeper into this, maybe you should.
Try different access points, using mobile data hotspot should work. Let me know the cases where it fails and succeeds.

In my case it seems like the issue was that the Chip-Tool App was still somehow configured as a fabric on the device. Removing  it fixed the issue for me. However, unfortunately I didn’t have the time to investigate further, so please don‘t quote me on that.

For what it's worth, "errorCode=11" means CHIP_ERROR_NO_MEMORY.
That's a strange situation to run into on iOS.  If you are able to share a sysdiagnose, that would be very helpful...

Closing this given it looks like there's been no update in a while. If you're still hitting this please re-open with new logs!


Make Create New Project Python Script

 Create New Project Python Script

Just weighing in before the PR shows up, but this is much needed especially as Debug support gets added to all the examples.
After doing a very brief amount of playing around with VCV rack a week or so ago, it was cool to see their python helper script, helper.py, be a singular script to assist with most utility actions. Might be worth doing something similar here to limit the number of scripts needed.
could be like:
#  Create MyNewProject for DaisyPatch
python helper.py create --board patch MyNewProject

# Duplicate MyOldProject and and rename everything to MyNewProject
python helper.py duplicate MyOldProject MyNewProject

the long-form  --board could be -b or just a second positional argument.

works as part of helper.py


When set GimbalMode.YAW_FOLLOW , there is crash!!!

I want to look at the determined roi region with fixed camera but I am getting this error.
Traceback (most recent call last):
  File "C:\Users\m42se\PycharmProjects\odtu\main.py", line 86, in <module>
    loop.run_until_complete(run())
  File "C:\Users\m42se\AppData\Local\Programs\Python\Python39\lib\asyncio\base_events.py", line 642, in run_until_complete
    return future.result()
  File "C:\Users\m42se\PycharmProjects\odtu\main.py", line 23, in run
    await drone.gimbal.set_mode(GimbalMode.YAW_FOLLOW)
  File "C:\Users\m42se\PycharmProjects\odtu\venv\lib\site-packages\mavsdk\gimbal.py", line 484, in set_mode
    raise GimbalError(result, "set_mode()", gimbal_mode)
mavsdk.gimbal.GimbalError: ERROR: 'Error'; origin: set_mode(); params: (<GimbalMode.YAW_FOLLOW: 0>,)

That's not nice :astonished:, let me check that.

So I just ran the gimbal example against PX4 SITL with the typhoon_h480 model and it all worked, this is with latest MAVSDK-Python 1.0.0 version. Can you double check that?
And if it fails, could you share the exact steps or script that I should try to reproduce it? Thank you.

Ok, and you're trying this against what, SITL? And if so, which model?

I am using MAVSDK-Puthon 1.3.0 and ArduPilot SITL with ArduCopter/+ vehicle and have the same error. Everything was configured according to the official manual.

Thanks, @julianoes. What do you suggest to use to test gimbal controls?

So I would expect that the gimbal v1 protocol works for ArduPilot, however, the mode command might not be implemented, or implemented in the same way. If you figure out how/if ArduPilot allows you to change the mode, then we can implement that in MAVSDK.
Note that gimbal is a bit of a sad topic, as it was - a long time ago - decided on the MAVLink call that there should be a new protocol, which I then developed but which is only implemented and accepted very slowly, if at all.


chore: allow cloud instead of cockpit properties

Issue
https://gravitee.atlassian.net/browse/CJ-1220
Description
A small description of what you did in this PR.
Additional context

Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:

use it directly by updating your project with version: 5.0.13
download it from Artifactory here

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

5.0.14
GitHub release

Your semantic-release bot :package::rocket:


Added changes to make Email,fullName persist to PersonaData

Proposed changes
Added changes to make Email,fullName persist to PersonaData and changed React.useState to useState in multiple instances.
Types of changes
What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

[ x] New feature (non-breaking change which adds functionality)
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices applies)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x ] I have read the CONTRIBUTING doc
[ ] I have signed the commit for DCO to be passed.
[ ] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[ ] I have added necessary documentation (if appropriate)

Dependency

Please add the links to the dependent PR need to be merged before this (if any).

Special notes for your reviewer:

Closing this as this has been added in Litmus 3.0.


Using trained model for predictions

Once we've finished a training and generated the .h5 file, how do we create a new detector (or recognizer) object that will use that model and the new calculated weights?

I got the .h5 files as described in the documentation:
https://keras-ocr.readthedocs.io/en/latest/examples/end_to_end_training.html

Then I'm trying to load them:
detector = keras_ocr.detection.Detector()
detector.model.load_weights("./keras_ocr/data/detector.h5")
recognizer = keras_ocr.recognition.Recognizer()
recognizer.model.load_weights("./keras_ocr/data/recognizer.h5")
pipeline = keras_ocr.pipeline.Pipeline(detector=detector, recognizer=recognizer)

And I get the next error:
ValueError: Cannot assign value to variable ' fc_12/kernel:0': Shape mismatch.The variable shape (256, 37), and the assigned value shape (256, 41) are incompatible.


Filter is not contextually limited to one instance of Vuetable

I followed the tutorial and set up two Vuetables with their own separate API-endpoints, each with full configuration including pagination, sorting, and filtering. However, when both are included on the same page their methods conflict:
onFilterSet(filterText) {
  this.moreParams.filter = filterText
  Vue.nextTick(() => this.$refs.vuetable.refresh())
},
onFilterReset() {
  delete this.moreParams.filter
  Vue.nextTick(() => this.$refs.vuetable.refresh())
}

Each component, in its separate .vue-file, applies these methods, but filtering in one Vuetable applies the filter to both tables, despite refresh() being applied through this. Sorting and pagination is not affected by the conflict, so I assume this is because of Vue.nextTick(). Can nextTick() be applied within the context of the component?

@OleVik The tutorial is just to demonstrate how the filtering can be applied. If my guess is right, it is possible that you use FilterBar.vue for both of the Vuetable instances.
FilterBar emits filter-set event to the interested parties (those who listen to this event) to notify that it just got a filterTextand anyone who is interested should take it and do something.
So, if both of your component listen to filter-set event (via this.$events.$on('filter-set'...)), it will get the same filterText no matter which instance it came from.
The easiest fix is to use different event name for each Vuetable instance, e.g. filter-set-one and filter-set-two. The same is true for filter-reset event as well.

I see, I got it working by implementing the contents of FilterBar.vue into MyVuetable.vue and renaming filter-set and filter-reset for all the filter-methods. Thanks for clarifying.

@OleVik do you have a jsfiddle of it working? or at least some sample code? I'm having the same issue.

I do not unfortunately, as I am using it in a project that is not currently online. To get it working I adjusted the emitted events to be filter-set-first, filter-set-second, and the same for reset, so that the filters have unique events to listen for.


feat: Improve shuffle metrics (second attempt)

Which issue does this PR close?

N/A
This PR replaces https://github.com/apache/datafusion-comet/pull/1173
Rationale for this change

Changes:

Fix: Report write time accurately (this is now just the time for writing to disk but it previously included some of the IPC encoding time)
New: Number of input batches
New: Encoding and compression time
New: Total time spent in native shuffle code

Before

After

What changes are included in this PR?

How are these changes tested?

@mbutrovich @parthchandra fyi

Codecov Report
Attention: Patch coverage is 76.92308% with 3 lines in your changes missing coverage. Please review.

Project coverage is 34.32%. Comparing base (95727aa) to head (6adb04c).
Report is 14 commits behind head on main.

Files with missing lines
Patch %
Lines

...apache/spark/sql/comet/CometCollectLimitExec.scala
50.00%
0 Missing and 1 partial :warning:

...ark/sql/comet/CometTakeOrderedAndProjectExec.scala
50.00%
0 Missing and 1 partial :warning:

...t/execution/shuffle/CometShuffleExchangeExec.scala
80.00%
0 Missing and 1 partial :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##               main    #1175      +/-   ##
============================================
- Coverage     34.32%   34.32%   -0.01%
  Complexity      899      899
============================================
  Files           115      115
  Lines         43500    43506       +6
  Branches       9496     9498       +2
============================================
+ Hits          14931    14932       +1
- Misses        25659    25661       +2
- Partials       2910     2913       +3

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Just for clarification - what's the relation between shuffle write time, encoding and compression total time, and native shuffle total time?
I would think shuffle write time + encoding and compression total time = native shuffle total time, but that does not seem to be the case?

Just for clarification - what's the relation between shuffle write time, encoding and compression total time, and native shuffle total time? I would think shuffle write time + encoding and compression total time = native shuffle total time, but that does not seem to be the case?

There is also evaluating the partition expressions (typically very fast if they are just column references) and then the time to actually split the batches into partitions.

Just for clarification - what's the relation between shuffle write time, encoding and compression total time, and native shuffle total time? I would think shuffle write time + encoding and compression total time = native shuffle total time, but that does not seem to be the case?

There is also evaluating the partition expressions (typically very fast if they are just column references) and then the time to actually split the batches into partitions.

From the above screenshot, shuffle write time + encoding and compression total time = 18.4s and  native shuffle total time=28.8s, so there is a difference of 10.4s which is substantial. Wondering if we are missing something.
Nonetheless, the PR certainly improves on the current.

There is also interaction with the memory pool, which makes JNI calls into synchronized code in the JVM.
I will see if I can make the metrics more complete in this PR.

@parthchandra The numbers almost add up now.

Here is Gluten's equivalent for comparison:

@parthchandra The numbers almost add up now.

Brilliant!


Dryrun option

Add dryrun option to config.yml. If dryrun is true, magellan-gcs-proxy does netither downloading, uploading nor executing command.
And this PR includes a bug fix of pubsub_progress_notifier. It had still used google-cloud-ruby,  I fixed it to use google-api-ruby-client.
Reviewers

@nagachika
@yodack
@ko1nksm
@guemon

@guemon If you find something wrong, please make another Issue.


[SPARK-50090] Refactor ResolveBinaryArithmetic to separate single-node transformation

What changes were proposed in this pull request?

Refactor ResolveBinaryArithmetic to separate single-node transformation.
Why are the changes needed?

Single-pass resolver utilizes these single-node transformations and separations is needed between Catalyst and single-pass logic.
Does this PR introduce any user-facing change?

How was this patch tested?

Existing tests
Was this patch authored or co-authored using generative AI tooling?

The lint failure is unrelated, thanks, merging to master!


feat: added oclif

This PR aims to successfully set up oclif.

To make the PR's small and manageable, I created a new branch https://github.com/asyncapi/cli/tree/oclif-migration I aim to first open PR's to this branch successfully migrating to oclif then merge it with the main branch.
In this PR I just generated oclif with the npx and created the routing logic for oclif. Currently, both oclif and ink works, but will delete the ink logic in future PR's.
Related issue(s)

see also #83

Shall I merge this, is anything left.


Bastion does not recognize incremental deployment

Not sure if this goes here or elsewhere.
Deploying Bastion goes well on first deploy, but consecutive deploys produce the following error:
New-AzResourceGroupDeployment: 17.55.50 - The deployment 'testbastion3' failed with error(s). Showing 1 out of 1 error(s).
Status Message: Subnet AzureBastionSubnet is in use by /subscriptions/551bee8b-f033-422c-b148-c515d9c5cf5e/resourceGroups/rg-smo-axtest3/providers/Microsoft.Network/bastionHosts/bast3/bastionHostIpConfigurations/IpConf and cannot be deleted. In order to delete the subnet, delete all the resources within the subnet. See aka.ms/deletesubnet. (Code: InUseSubnetCannotBeDeleted)

I'm pretty sure this is a ARM issue. If needed, I'd be delighted to supply additional information on the issue.

Can you share the full file? Is the subnet being declared as a child resource instead of a property on the vnet/

Running this:
param virtualNetworkName string = 'vnet01'
param vNetIpPrefix string = '<IP_ADDRESS>/16'
param bastionSubnetIpPrefix string = '<IP_ADDRESS>/27'
param bastionHostName string
param location string = resourceGroup().location

resource publicIp 'Microsoft.Network/publicIPAddresses@2020-06-01' = {
  name: '${bastionHostName}-defpip'
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
  }
}

resource virtualNetwork 'Microsoft.Network/virtualNetworks@2020-06-01' = {
  name: virtualNetworkName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        vNetIpPrefix
      ]
    }
  }
}

resource subNet 'Microsoft.Network/virtualNetworks/subnets@2020-06-01' = {
  name: '${virtualNetwork.name}/AzureBastionSubnet'
  properties: {
    addressPrefix: bastionSubnetIpPrefix
  }
}

module bas 'bastion.bicep' = {
  name: 'DeployBastion'
  params: {
    bastionHostName: bastionHostName
    virtualNetworkName: virtualNetwork.name
  }
}

with this
'```bicep
param bastionHostName string
param location string = resourceGroup().location
param virtualNetworkName string = 'vnet01'
resource publicIp 'Microsoft.Network/publicIPAddresses@2020-06-01' existing = {
name: '${bastionHostName}-defpip'
}
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2020-06-01' existing = {
name: virtualNetworkName
}
resource subNet 'Microsoft.Network/virtualNetworks/subnets@2020-06-01'  existing = {
name: '${virtualNetwork.name}/AzureBastionSubnet'
}
resource bastionHost 'Microsoft.Network/bastionHosts@2020-06-01' = {
name: bastionHostName
location: location
properties: {
ipConfigurations: [
{
name: 'IpConf'
properties: {
subnet: {
id: subNet.id
}
publicIPAddress: {
id: publicIp.id
}
}
}
]
}
}

works on the first go. Running it again generates the error.

It's because the subnet is declared as a child resource. When the VNET is redeployed, it thinks you want 0 subnets and attempts to delete them. Because the subnet is in use, the deployment fails. It's an unfortunate API design that we are trying to resolve, but in the meantime, if you declare the subnet as a property of the vnet, you can resolve this:
resource virtualNetwork 'Microsoft.Network/virtualNetworks@2020-06-01' = {
  name: virtualNetworkName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        vNetIpPrefix
      ]
    }
    subnets: [
      {
        name: 'AzureBastionSubnet'
        properties: {
          addressPrefix: bastionSubnetIpPrefix
        }
      }
    ]
  }
}

Thanks, Alex!


Fix nargs handling for optionals

This fixes the handling for nargs values N ? * + as shown in the unit test. Some extra work is needed to make argparse.REMAINDER work properly.

[Current coverage][cc-pull] is 77.24%

Merging [#131][cc-pull] into [master][cc-base-branch] will increase coverage by 0.53%

@@             master       #131   diff @@
==========================================
  Files             5          5
  Lines           760        769     +9
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            583        594    +11
+ Misses          177        175     -2
  Partials          0          0

Powered by Codecov. Last updated by [3973d28...c15ec80][cc-compare]
[cc-base-branch]: https://codecov.io/gh/kislyuk/argcomplete/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/kislyuk/argcomplete/compare/3973d28d4bb65cc786b7fee542dc48e9153563da...c15ec80900d82ef5af1b5b9a00419d08baaf597b
[cc-pull]: https://codecov.io/gh/kislyuk/argcomplete/pull/131?src=pr

This looks great. Thanks!

Released in v1.3.0.


Revert "Update README.md"

Reverts mukulikadey/SOEN341-Group1#45

Updated the goals and features.


Popping audio on M1 MacBook Pro (macOS Monterey 12.2.1)

A recent issue I've been having is popping/glitching audio when playing music in Hermes.  I'm not sure if it's tied specifically to Hermes or not.
If I play audio from pandora.com in my browser, I don't get any popping.
This may have started with 12.2.1 -- I don't recall it happening when I first got the computer a few months ago.
I'll update this issue if the problem goes away after updating to 12.3.

Closing this out as it is affects other audio apps, including Apple's own Music app.  And a Google search turns up many people affected by the issue.

I have this same issue with Hermes on an M1 MacBook as well.  Spotify on the same laptop doesn't have the issue.


⚠ Minetest Wiki (for comparison against mirror) has degraded performance

In b27fbc2, Minetest Wiki (for comparison against mirror) (https://wiki.minetest.net/Main_Page) experienced degraded performance:

HTTP code: 200
Response time: 8232 ms

Resolved: Minetest Wiki (for comparison against mirror) performance has improved in 2200186 after 10 minutes.


Added support for anthropic models through GCP Vertex AI

Description
While Anthropic models were already supported, there was no option to use them with GCP Vertex AI, so I added it.
Version Bump?
Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

[X] Yes
[ ] No

Type of Change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)
[X] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Added an integration test, so you need to set three environment variables, which are:

ANTHROPIC_MODEL: The Vertex AI name of anthropic model you want to use

ANTHROPIC_REGION: The Vertex AI region

ANTHROPIC_PROJECT_ID: The vertex AI project ID

[X] Added new unit/integration tests

[X] I stared at the code and made sure it makes sense

Suggested Checklist:

[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation
[ ] I have added Google Colab support for the newly added notebooks.
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] I ran make format; make lint to appease the lint gods

@masci @nerdai Thank you for your reviews! The changes you requested are done.

@masci going to merge this now 🙏🏼


Update supported awscrt version to 0.16.19

Codecov Report
Base: 93.55% // Head: 93.50% // Decreases project coverage by -0.06% :warning:

Coverage data is based on head (cc492e0) compared to base (c915020).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #2863      +/-   ##
===========================================
- Coverage    93.55%   93.50%   -0.06%
===========================================
  Files           63       63
  Lines        13400    13400
===========================================
- Hits         12536    12529       -7
- Misses         864      871       +7

Impacted Files
Coverage Δ

botocore/compat.py
91.33% <0.00%> (-1.34%)
:arrow_down:

botocore/httpsession.py
91.40% <0.00%> (-0.40%)
:arrow_down:

botocore/utils.py
79.01% <0.00%> (-0.20%)
:arrow_down:

botocore/credentials.py
98.53% <0.00%> (-0.11%)
:arrow_down:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


ktlint violation location in detekt-formatting is broader

Expected Behavior
Highlight the exact location ktlint reports (│):
private fun getErrorMessage(value: String): String =
        @Suppress("DEPRECATION")
        customMessage.takeUnless { it.isEmpty() }│ ?: String.format(DEFAULT_ERROR_MESSAGE_WITH_NO_REASON, value)

Current Behavior

Context
While working on a PR we found a ktlint violation in the code that was confusing (see above in current screenshot). This was reported at https://github.com/pinterest/ktlint/issues/2028, and investigated and explained there. The reason it was confusing was because the highlighted code (yellow in above screenshot) didn't match up with the error message "Expected newline". The annotation looked correctly wrapped, but the same rule also checks if the annotated element is nicely separated, hence this emission.
In the explanation there was a line that hit me "This LintError contains the offset (line and position)", and a short investigation lead me to
https://github.com/detekt/detekt/blob/948276a8db4578b962bf24c63eee3b8548bac627/detekt-formatting/src/main/kotlin/io/gitlab/arturbosch/detekt/formatting/FormattingRule.kt#L97
showing that the offset reported by the ktlint emit function is ignored (_). This means that detekt-wrapped ktlint rules will always report less precise location than if they were directly executed with another wrapper.
This is just one example, there could be many others where the detekt-wrapped reporting is confusing. I understand this is quite a fundamental issue, and might not fit detekt's model, but wanted to record the problem anyway.

This is just one example, there could be many others where the detekt-wrapped reporting is confusing. I understand this is quite a fundamental issue, and might not fit detekt's model, but wanted to record the problem anyway.

Thanks for reporting this. I was aware of this misalignment when I worked on KtLint wrapper recently (previously we were reporting a finding on the whole file, now it's on the AST Node level, which is already an improvement).
I remember trying to use the offset information provided by KtLint but the result wasn't good enough (I was getting reports at wrong locations). We definitely need to look again into this.

This issue is stale because it has been open 90 days with no activity. Please comment or this will be closed in 7 days.

Related with #6390, right? Should that pr close this one?

Related with #6390, right? Should that pr close this one?

I think this was originally fixed by my PR #5876, but @arturbosch's one #6390 will fix a follow-up bug from it.

Related with #6390, right? Should that pr close this one?

I think this was originally fixed by my PR #5876, but @arturbosch's one #6390 will fix a follow-up bug from it.

Not necessary all cases are fixed. Imagine KtLint reports offsets for nodes but on a class node. The recent detekt change would use the class node as reporting location e.g. all kdoc + annotations.
So yes, #6390 should fix all these cases as we again report the original KtLint offsets.


[Feature Request]: Integration of frontend with v2 Routes

Is your feature request related to a problem? Please describe.
Currently, JB manager only support whatsapp channel which is populating in JBChannel while activating the bot. There is no feature to manually add channels through JBManager frontend.
Describe the solution you'd like
Currently, there exist the following API's in /v2 of JB Manager.

Add channel to bot
Edit Channel
Activate Channel
Deactivate Channel
Delete Channel
List Available Channels

There should be a support of using these API using the JBManager frontend. Appropriate UI changes should be required to incorporate this.
Additional context
No response

I can work on this

Mock Ui

@sm98 Can you please add all the mocks and flows in this issue?

@mx-om @code-with-om will you be able to take up this issue?

@shreypandey sure, I can work on this. But can you please explain the task that we are trying to implement here ? Because, as above, I can see some tasks are already done.

Updated Mockup.
User can access this screen from left navigation bar within the project.
This ui enables multiple bots in same channel (whatsapp, telegram, etc) in a compact view.
User can add, enable, disable, delete and edit channels.

@abhaymathur21, Any update on this please?

@Lekhanrao This is same as #176

Karan spoke with Shrey and we understand that #152 will be closed once #176 is completed. #176 is assigned to ris-code at this time and he is working on it.

@KaranrajM to review the PR and close by this Friday 4th Oct


Tasks from office hours

The issue for logging tasks from meetings

Office hours held on Friday 03-Jul-21

[ ] Display T1w /  T2w results
[ ] Add reference horizontal lines
[ ] Diserable metrics for dropdown menu:

[ ] MEAN (area)
[ ] MEAN (RL)
[ ] MEAN (AP)
[ ] MEAN (angle_AP)

📅 Office hours held on Friday 23-Jul-21

[ ] Need to change notebook to be less "dummy notebook" (more scientific content.
[ ] One or more figures similar to the current one but showing the results in the brain.

@jcohenadad says that @agahkarakuzu should have the data to give. See https://github.com/courtois-neuromod/anat-processing-book/issues/8


update text

@homunkulus try

:hourglass: Trying commit 25f33ae with merge 25f33ae...

:broken_heart: Test failed - status-travis

@homunkulus r+

:pushpin: Commit 488e5e0 has been approved by japaric

:hourglass: Testing commit 488e5e0 with merge 488e5e0...

:broken_heart: Test failed - status-travis

:pushpin: Commit 554cee1 has been approved by japaric

@homunkulus r+

:hourglass: Testing commit 554cee1 with merge 554cee1...

:broken_heart: Test failed - status-travis

:pushpin: Commit 7e2b827 has been approved by japaric

@homunkulus r+

:hourglass: Testing commit 7e2b827 with merge 7e2b827...

:broken_heart: Test failed - status-travis

@homunkulus r+

:pushpin: Commit 0488602 has been approved by japaric

:hourglass: Testing commit 0488602 with merge 0488602...


KeyError: 'optimizer' when resuming training from checkpoint

I am trying to resume training from the checkpoint provided in the repo (fpn_resnet_18_epoch_300.pth), and when I run python train.py --gpu_idx 0 --resume_path ../checkpoints/fpn_resnet_18/fpn_resnet_18_epoch_300.pth I get this error:
Traceback (most recent call last):   File "train.py", line 281, in <module>     main()   File "train.py", line 67, in main     main_worker(configs.gpu_idx, configs)   File "train.py", line 132, in main_worker     optimizer.load_state_dict(utils_state_dict['optimizer']) KeyError: 'optimizer'

Hi @yukaryote
I saved weights & optimizer states in 2 files


Reload browser on change

I'm using 'dotnet watch run' to restart the application on a change.
Is there an option to also reload the browser after the restart?
Maybe integrate with something like LiveReload?

The best way to do this today is to use the ASP.NET Core webpack middleware. See https://docs.microsoft.com/en-us/aspnet/core/client-side/spa-services, especially the section about hot module replacement.
By the way, this enabled by default in some of our 2.0 templates. If you have 2.0.0-preview2, do the following:
dotnet new angular
npm install
$env:ASPNETCORE_ENVIRONMENT='Development'
dotnet watch run

This will start a webpack watcher that will reload the browser when your JS and HTML assets change.


First Stage: A POA bridge supporting verify darwinia events

[x] A POA Bridge with trust setup. Any authority can submit a MMR.
[x] A guard system that can verify correctness of  header MMR, if not can stop bridge after specific darwinia block number.
[x] Only superviser(a multisig) can restore from pause status and clean wrong submitted mmr.

Any submitted MMR will need to wait for a period(number of ethereum blocks) before confirm, in this period, other authority can challenge and pause.
Any authority can pause the bridge by submitting a pause tx(with info of the latest submitted valid darwinia header he think, any mmr after this header can not be used for verify darwinia events). Other authority can continue pause with older headers.
Only admin(multsig) can restore from pause and do clean stuffs.
A cooperating backing module for issue and redeem protocol

The description is more close and for Ethereum=>Darwinia Bridge, we are going to use EsdsaAuthority(Fraud proof) to replace POA and work as proxy for grandpa authories.


Api endpoint for deleting a channel

The diff for this PR is including #11's changes, I this is because I merged in develop's changes after #11 landed into this PR's branch and git did a fast-forward, so GH is showing the diff from when this branch was started. Creating a new PR to fix the diff.


A block quote can be empty

See https://spec.commonmark.org/0.30/#example-239

This issue is a duplicate of issue #100.


Segmentation fault in CLI binary classification demo

For bugs or installation issues, please provide the following information.
The more information you provide, the more easily we will be able to offer
help and advice.
Environment info
Operating System: OS X El Capitan Version 10.11.6
Compiler: clang-8<IP_ADDRESS>
Package used (python/R/jvm/C++): C++
xgboost version used: 0.6
If installing from source, please provide

The commit hash (git rev-parse HEAD): 70071fc38c3a93966ce276ac609cfbdf96f89526

Steps to reproduce

git clone --recursive https://github.com/dmlc/xgboost xgboost
cd xgboost; cp make/minimum.mk ./config.mk; make -j4
cd demo/binary_classification/
./runexp.sh

logs:
[00:07:11] 6541x127 matrix with 143902 entries loaded from agaricus.txt.train
[00:07:11] 1583x127 matrix with 34826 entries loaded from agaricus.txt.test
[00:07:11] src/cli_main.cc:198: Loading data: 0.021951 sec
[00:07:11] boosting round 0, 4.49982e-08 sec elapsed
[00:07:11] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 12 extra nodes, 0 pruned nodes, max_depth=3
[00:07:11] [0]	test-error:0.015793	train-error:0.014524
[00:07:11] boosting round 1, 0.00579598 sec elapsed
[00:07:11] src/tree/updater_prune.cc:74: tree pruning end, 1 roots, 10 extra nodes, 0 pruned nodes, max_depth=3
[00:07:11] [1]	test-error:0.000000	train-error:0.001223
[00:07:11] update end, 0.00959829 sec in all
[00:07:11] 1583x127 matrix with 34826 entries loaded from agaricus.txt.test
[00:07:11] start prediction...
./runexp.sh: line 9:  8938 Segmentation fault: 11  ../../xgboost mushroom.conf task=pred model_in=0002.model

Adding the following line at the end of Load method in learner.cc
seems to be able get rid of the segmentation fault.
diff --git a/src/learner.cc b/src/learner.cc
index 689e1f9..c35e285 100644
--- a/src/learner.cc
+++ b/src/learner.cc
@@ -314,6 +314,7 @@ class LearnerImpl : public Learner {
     cfg_["num_class"] = common::ToString(mparam.num_class);
     cfg_["num_feature"] = common::ToString(mparam.num_feature);
     obj_->Configure(cfg_.begin(), cfg_.end());
+    gbm_->Configure(cfg_.begin(), cfg_.end());
   }

core dump on predicting
[19:33:44] 287x79 matrix with 21321 entries loaded from train.feat.test
[19:33:44] start prediction...
段错误 (核心已转储)

Environment info
ubuntu16.04
gcc-5.4.0
install from source git rev-parse HEAD
Step to reproduce
~/work/github/xgboost/xgboost houseprice.conf task=pred model_in=0002.model

by follow @eroicaleo 's solution, predict success

I am getting this error as well on running the binary_classification demo.
Stack trace
Thread 1 "xgboost" received signal SIGSEGV, Segmentation fault.
0x0000000000594ae1 in xgboost::gbm::GBTree::PredictBatch(xgboost::DMatrix*, std::vector<float, std::allocator >, unsigned int) ()
(gdb) bt
#0  0x0000000000594ae1 in xgboost::gbm::GBTree::PredictBatch(xgboost::DMatrix, std::vector<float, std::allocator >, unsigned int) ()
#1  0x0000000000423ab6 in xgboost::LearnerImpl::PredictRaw(xgboost::DMatrix, std::vector<float, std::allocator >, unsigned int) const ()
#2  0x0000000000423b87 in xgboost::LearnerImpl::Predict(xgboost::DMatrix, bool, std::vector<float, std::allocator >*, unsigned int, bool, bool) const ()
#3  0x000000000040d086 in xgboost::CLIPredict(xgboost::CLIParam const&) ()
#4  0x0000000000410d36 in xgboost::CLIRunTask(int, char**) ()
#5  0x00007ffff6d4d830 in __libc_start_main (main=0x408400 , argc=4, argv=0x7fffffffe508,
init=, fini=, rtld_fini=, stack_end=0x7fffffffe4f8)
at ../csu/libc-start.c:291
#6  0x000000000040c729 in _start ()

@eroicaleo - I can confirm that this solution also worked for me, although I have no idea what it is actually doing. I was running this from my macbook with macOS Sierra. The only thing I want to add is that I had to re-run the make -j4 command for the solution to work.

I also have this error.
$ cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)
$ gdb ../../xgboost core.5501
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7
...
...
...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `../../xgboost machine.conf task=pred model_in=0002.model'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000055203e in xgboost::gbm::GBTree::PredictBatch(xgboost::DMatrix*, std::vector<float, std::allocator >*, unsigned int) ()
Missing separate debuginfos, use: debuginfo-install glibc-2.17-157.el7.x86_64 libgcc-4.8.5-11.el7.x86_64 libgomp-4.8.5-11.el7.x86_64 libstdc++-4.8.5-11.el7.x86_64

Ping? We're seeing the same issue. Just changing 'objective' from 'reg:linear' to 'reg:logistic' or 'binary:logistic' causes a segfault in an attempted use-case.
@eroicaleo 's comment above seems reasonable, esp given this comment above the block he's noting:
https://github.com/dmlc/xgboost/blob/master/src/learner.cc#L304
which indicates this logic is supposed to mirror LazyInitModel. However, LazyInitModel calls Configure on gbm_ and obj_:
https://github.com/dmlc/xgboost/blob/master/src/learner.cc#L537
As does the LearnerImpl::Configure method:
https://github.com/dmlc/xgboost/blob/master/src/learner.cc#L258
@tqchen this looks like some pretty long-standing code... is the fix just @eroicaleo 's suggestion? Seems troubling for classification/ranking to be broken in this way.

But does anyone care enough to submit a PR? :)

@suntzu86 I cannot seem to reproduce the issue with the latest master. Can you post a script that reproduces the bug? Thanks!


Add dynamic tooltip to Mortgage Performance map

The MP map needs to show the selected location's delinquency rate alongside the national average. A tooltip formatting function is passed to cfpb-chart-builder that uses it to render HTML for the tooltip.
Additions

renderTooltip function that returns HTML for the tooltip.
CSS for the tooltip.

Changes

Misc. font size cleanup.
Updated cfpb-chart-builder to the latest version that supports custom tooltips.
Renames the location variable to loc to avoid Checkmarx false positive. (I think it's confusing it with window.location).

Testing

Pull down this branch and ./setup.sh
Set up the mortgage performance API.
Create a mortgage chart block and page.

Screenshots

Checklist

[ ] PR has an informative and human-readable title
[ ] Changes are limited to a single goal (no scope creep)
[ ] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the development playbook
[ ] Passes all existing automated tests
[ ] New functions include new tests
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[ ] Project documentation has been updated
[ ] Reviewers requested with the Assignee tool :arrow_right:

The national averages on both 30-89 and 90 day maps don't change between years. Does the national average value get updated with a date change?

Ooh good call. I'll dig into this.

@higs4281 @marteki I opened a PR against cfpb-chart-builder to fix the tooltip updating. I'll leave this PR open until that one is merged.


Parametric Weighting factors

Docs show the CIEDE2000 takes Kl, Kc, and Kh as args, all set at unity to 1, which does not seem to be required.
delta_e_cie2000(color1, color2, Kl=1, Kc=1, Kh=1)
In the Sharma, Wu and Dalal paper, these parametric weighting factors are used in equation 22, in the denominators. kl is used once, while kc and kh are used twice. While this would be a big deal if anything other than 1 were used, that is not the case in the application here, and the constancy of the weighting factors makes passing them in as agruments useless.

Thanks, @markwbrown. I don't suppose you have some sort of link for me, or is this article behind a paywall?
I'm going to be mobile-only for a week or so pending Comcast getting service set up at the new place, otherwise I'd do some more digging myself.

That would be the paper:
http://www.ece.rochester.edu/~gsharma/ciede2000/ciede2000noteCRNA.pdf
Sharma, G., Wu, W., & Dalal, E. N. (2005). The CIEDE2000 color‐difference formula: Implementation notes, supplementary test data, and mathematical observations. Color Research & Application, 30(1), 21–30. doi:10.1002/col.20070
I'm not sure they specify values for the factors, although I think K_L could have value of 2 for textile application. I could try to dig that in the original paper from Luo MR, Cui G and Rigg B.

The paper indicates K_L, K_C & K_H were all set to 1. It seems the previous papers indicated K_L could be set to  2 for textiles, but that seems to be a coming from what was used in the 94 version. My point is it seems arbitrary to pass in values which do not change the calculation. If there is a better reason for weighting L c or h differently, I haven't found it in CIEDE2000. Changing c or h have a great effect on the calculation, as they are used twice, but the effect of using a larger K_L, K_C, of K_H makes the end result a smaller number.

It seems the previous papers indicated K_L could be set to 2 for textiles, but that seems to be a coming from what was used in the 94 version.

Yes, the 1994 uses 2 for textile related applications.

My point is it seems arbitrary to pass in values which do not change the calculation.

Yes, agreed.

Would anyone be interested in submitting a pull request to give us a basis for discussion?

Closing due to inactivity. Feel free to submit a PR and link here!


use fake account to return error message so that code service can return login error

without using the security error page which is designed for server-side rendering.

 use fake account to return error message so that code service can return login error master


FoxyLand 2 [PCSE01438]

App summary

App name: FoxyLand 2
App serial: PCSE01438
App version: 1.00

Vita3K summary

Version: v0.1.8
Build number: 3233
Commit hash: https://github.com/vita3k/vita3k/commit/a6f64367
CPU backend: Dynarmic
GPU backend: OpenGL and Vulkan

Test environment summary
Tested by: space1
OS: Windows 11
CPU: AMD Ryzen 5 3600
GPU: Nvidia 3070
RAM: 32 GB
Issues
Black screen with musis and sounds, you can hear the character jump.
Screenshots

Log
vita3k_save.log
Recommended labels
Bootable

as of https://github.com/Vita3K/Vita3K/commit/c196c7d79ca21ca474e856629f9c122061d96b14, the game now displays and has some graphical glitches after completing level 1 (see in 3rd screenshot), but despite that the game is playable.
Screenshots

Log
vita3k.log
Recommended Labels

Playable
graphical bug


docs(advancedtheming.md breakpoints.md): change grammar

change grammar in the advancedTheming.md and breakpoints.md files
bootstrap-styled
Thank you for contributing! Please take a moment to review our contributing guidelines
to make the process easy and effective for everyone involved.
Please open an issue before embarking on any significant pull request, especially those that
add a new library or change existing tests, otherwise you risk spending a lot of time working
on something that might not end up being merged into the project.
Before opening a pull request, please ensure:

[ ] You have followed our contributing guidelines
[ ] Double-check your branch is based on dev and targets dev
[ ] Your are doing semantic commit message using commitizen and our commit message convention
[ ] Pull request has tests (we are going for 100% coverage!)
[ ] Code is well-commented, linted and follows project conventions
[ ] Documentation is updated (if necessary)
[ ] Description explains the issue/use-case resolved and auto-closes related issues

Be kind to code reviewers, please try to keep pull requests as small and focused as possible :)
IMPORTANT: By submitting a patch, you agree to allow the project
owners to license your work under the terms of the  License.

I made some grammar changes to the documentation.

Thank you

Thank you for accepting my PR.
On Mon, May 18, 2020 at 2:26 AM Dimitri KOPRIWA<EMAIL_ADDRESS>wrote:

Thank you
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bootstrap-styled/bootstrap-styled/pull/149#issuecomment-629886086,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEEDA6LK2FU4WGHFEX4RRNTRSB6BTANCNFSM4NDQN3HQ
.

--
Thank you and regards
Brighton Dube


youtube-dl: 2021.03.03 -> 2021.03.14

https://github.com/ytdl-org/youtube-dl/releases/tag/2021.03.14

Motivation for this change
Things done

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

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

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

20.09: 01897afb96063f5e2d6ee6f76ff843c413e7b271


A11y_Azure Tools Storage Explorer_Settings_Application_Keyboard : Inactive elements such as heading text receives keyboard focus on navigation.

GitHubTags: #C&AI_Aug2020_BMAzure Tools Storage Explorer;#A11yMAS;#A11YTCS;#Azure Tools Storage Explorer;#WCAG2.1.1;#MAC;#A11ySev2;#Benchmark;#Keyboard;#FTP;#BM-Azure Tools Storage Explorer-MAC-Aug2020;
Environment Details:
Application Name: Azure Tool Storage Explorer
Application version: 1.15.0
AzCopy Version: 10.6.0
OS Version: macOS Catalina Version 10.15.6
Screen Reader: Voiceover
Repro Steps:

Launch Storage Explorer
Navigate to Setting menu on left pane and click on it.
Navigate to "Application" on right pane and click on it.
"Application" screen gets opened.
Using keyboard navigate though the "Application" screen and observe if the heading text receives keyboard focus or not.

Actual:
When keyboard users navigate through the screen content the inactive element such as heading text present on the screen i.e. the "Application" heading text receives keyboard focus which is incorrect.
This issue is observed in the below scenarios:

Settings - Data Explorers
Settings - Transfers

Expected:
Inactive element such as heading text should not receive keyboard focus while navigation using keyboard.
User Impact:
If inactive element receive keyboard focus for the content present on the screen then the keyboard only user will interpret them as actionable control and while try activating them. This will lead to confusion as incorrect information is conveyed to them.
Attachment:
https://microsoftapc-my.sharepoint.com/:v:/g/personal/v-manai_microsoft_com/EW45SLwiT8lHuucd9_028dsBBTxyztkoksyxmOUOddC4ww?e=IpYgm0

@MayuriNaik Could you please verify and close this issue if it is fixed?

For keyboard users the heading text now does not receive keyboard focus while navigation using 'Tab' key. The bug is fixed and hence closing the bug.Verified in application version Version: 1.16.0-dev AzCopy Version: 10.6.0.

GitHubTags: #Closed