I want to run "./chip-tool onoff toggle i 1" with i=1...5 ( without only one CLI)

Reproduction steps
I loop the main.cpp 50 times in home/connectedhomeip/examples/chip-tool/main.cpp:
/=====================================================================/
Main.cpp
/=====================================================================/
#include "commands/common/Commands.h"
#include "commands/example/ExampleCredentialIssuerCommands.h"
#include "commands/discover/Commands.h"
#include "commands/group/Commands.h"
#include "commands/interactive/Commands.h"
#include "commands/pairing/Commands.h"
#include "commands/payload/Commands.h"
#include "commands/storage/Commands.h"
#include <zap-generated/cluster/Commands.h>
#include <zap-generated/test/Commands.h>
// ================================================================================
// Main Code
// ================================================================================
int main(int argc, char * argv[])
{
ExampleCredentialIssuerCommands credIssuerCommands;
Commands commands;
registerCommandsDiscover(commands, &credIssuerCommands);
registerCommandsInteractive(commands, &credIssuerCommands);
registerCommandsPayload(commands);
registerCommandsPairing(commands, &credIssuerCommands);
registerCommandsTests(commands, &credIssuerCommands);
registerCommandsGroup(commands, &credIssuerCommands);
registerClusters(commands, &credIssuerCommands);
registerCommandsStorage(commands);
commands.Run(argc, argv);
mark++;
if(mark<50)
return main(argc,argv);
}
Bug prevalence
First device completed toggle, but other device ( other nodeId) didn't toggle
GitHub hash of the SDK that was being used
https://github.com/project-chip/connectedhomeip/tree/v1.0-branch
Platform
esp32
Platform Version(s)
ESP32 WROOM KIT
Type
Test Improvement
Anything else?
This is log of chip-tool:
[1681839455.623143][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs
[1681839455.626248][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_factory.ini
[1681839455.626620][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_config.ini
[1681839455.626853][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_counters.ini
[1681839455.627413][114395:114395] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-gykxl7)
[1681839455.627623][114395:114395] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1681839455.627691][114395:114395] CHIP:DL: NVS set: chip-counters/reboot-count = 9 (0x9)
[1681839455.627955][114395:114395] CHIP:DL: Got Ethernet interface: enp2s0
[1681839455.628129][114395:114395] CHIP:DL: Found the primary Ethernet interface:enp2s0
[1681839455.628276][114395:114395] CHIP:DL: Got WiFi interface: wlp1s0
[1681839455.628838][114395:114395] CHIP:DL: FiagnosticDataProviderImpl::ResetWiFiNetworkDiagnosticsCounts()
[1681839455.628851][114395:114395] CHIP:DL: Found the primary WiFi interface:wlp1s0
[1681839455.628897][114395:114395] CHIP:IN: UDP::Init bind&listen port=0
[1681839455.628933][114395:114395] CHIP:IN: UDP::Init bound to port=48562
[1681839455.628942][114395:114395] CHIP:IN: UDP::Init bind&listen port=0
[1681839455.628971][114395:114395] CHIP:IN: UDP::Init bound to port=52840
[1681839455.628979][114395:114395] CHIP:IN: BLEBase::Init - setting/overriding transport
[1681839455.628987][114395:114395] CHIP:IN: TransportMgr initialized
[1681839455.629001][114395:114395] CHIP:FP: Initializing FabricTable from persistent storage
[1681839455.629084][114395:114395] CHIP:TS: Last Known Good Time: 2023-04-18T20:17:41
[1681839455.629937][114395:114395] CHIP:FP: Fabric index 0x1 was retrieved from storage. Compressed FabricId 0x8667A69C0E7F00AB, FabricId 0x0000000000000001, NodeId 0x000000000001B669, VendorId 0xFFF1
[1681839455.630685][114395:114395] CHIP:ZCL: Using ZAP configuration...
[1681839455.630974][114395:114395] CHIP:DL: MDNS failed to join multicast group on enp2s0 for address type IPv4: ../examples/chip-tool/third_party/connectedhomeip/src/inet/UDPEndPointImplSockets.cpp:761: Inet Error 0x00000110: Address not found
[1681839455.631251][114395:114395] CHIP:CTL: System State Initialized...
[1681839455.631287][114395:114395] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1681839455.631308][114395:114395] CHIP:CTL: Setting attestation nonce to random value
[1681839455.631320][114395:114395] CHIP:CTL: Setting CSR nonce to random value
[1681839455.631344][114395:114395] CHIP:IN: UDP::Init bind&listen port=5550
[1681839455.631369][114395:114395] CHIP:IN: UDP::Init bound to port=5550
[1681839455.631376][114395:114395] CHIP:IN: UDP::Init bind&listen port=5550
[1681839455.631396][114395:114395] CHIP:IN: UDP::Init bound to port=5550
[1681839455.631402][114395:114395] CHIP:IN: TransportMgr initialized
[1681839455.631571][114395:114400] CHIP:DL: CHIP task running
[1681839455.632266][114395:114400] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1681839455.632283][114395:114400] CHIP:CTL: Setting attestation nonce to random value
[1681839455.632321][114395:114400] CHIP:CTL: Setting CSR nonce to random value
[1681839455.634421][114395:114400] CHIP:CTL: Generating NOC
[1681839455.634774][114395:114400] CHIP:FP: Validating NOC chain
[1681839455.635456][114395:114400] CHIP:FP: NOC chain validation successful
[1681839455.635515][114395:114400] CHIP:FP: Updated fabric at index: 0x1, Node ID: 0x000000000001B669
[1681839455.635526][114395:114400] CHIP:TS: Last Known Good Time: 2023-04-18T20:17:41
[1681839455.635536][114395:114400] CHIP:TS: New proposed Last Known Good Time: 2021-01-01T00:00:00
[1681839455.635545][114395:114400] CHIP:TS: Retaining current Last Known Good Time
[1681839455.636826][114395:114400] CHIP:FP: Metadata for Fabric 0x1 persisted to storage.
[1681839455.637319][114395:114400] CHIP:TS: Committing Last Known Good Time to storage: 2023-04-18T20:17:41
[1681839455.637773][114395:114400] CHIP:CTL: Joined the fabric at index 1. Compressed fabric ID is: 0x0000000000000000
[1681839455.637799][114395:114400] CHIP:IN: UDP::Init bind&listen port=5550
[1681839455.637836][114395:114400] CHIP:IN: UDP::Init bound to port=5550
[1681839455.637845][114395:114400] CHIP:IN: UDP::Init bind&listen port=5550
[1681839455.637872][114395:114400] CHIP:IN: UDP::Init bound to port=5550
[1681839455.637880][114395:114400] CHIP:IN: TransportMgr initialized
[1681839455.643382][114395:114400] CHIP:TOO: Sending command to node 0x1
[1681839455.643594][114395:114400] CHIP:CSM: FindOrEstablishSession: PeerId = [1:0000000000000001]
[1681839455.643615][114395:114400] CHIP:CSM: FindOrEstablishSession: No existing OperationalSessionSetup instance found
[1681839455.643647][114395:114400] CHIP:CTL: OperationalSessionSetup[1:0000000000000001]: State change 1 --> 2
[1681839455.643948][114395:114400] CHIP:DIS: Warning: Attempt to mDNS broadcast failed on enp2s0:  ../examples/chip-tool/third_party/connectedhomeip/src/inet/UDPEndPointImplSockets.cpp:409: OS Error 0x02000065: Network is unreachable
[1681839455.644349][114395:114400] CHIP:DIS: mDNS broadcast had only partial success: 3 successes and 1 failures.
[1681839455.843809][114395:114400] CHIP:DIS: Checking node lookup status after 200 ms
[1681839455.875616][114395:114400] CHIP:DIS: UDP:[fe80::cac9:a3ff:fed0:65bc%wlp1s0]:5540: new best score: 3
[1681839455.875742][114395:114400] CHIP:DIS: UDP:<IP_ADDRESS>%wlp1s0:5540: score has not improved: 2
[1681839455.875796][114395:114400] CHIP:DIS: Checking node lookup status after 232 ms
[1681839455.875938][114395:114400] CHIP:DIS: OperationalSessionSetup[1:0000000000000001]: Updating device address to UDP:[fe80::cac9:a3ff:fed0:65bc%wlp1s0]:5540 while in state 2
[1681839455.875998][114395:114400] CHIP:CTL: OperationalSessionSetup[1:0000000000000001]: State change 2 --> 3
[1681839455.876212][114395:114400] CHIP:IN: SecureSession[0x7f763400b030]: Allocated Type:2 LSID:20649
[1681839455.876295][114395:114400] CHIP:SC: Initiating session on local FabricIndex 1 from 0x000000000001B669 -> 0x0000000000000001
[1681839455.877793][114395:114400] CHIP:SC: Including MRP parameters
[1681839455.878104][114395:114400] CHIP:EM: <<< [E:3880i M:251214339] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:30 (SecureChannel:CASE_Sigma1)
[1681839455.878304][114395:114400] CHIP:IN: (U) Sending msg 251214339 to IP address 'UDP:[fe80::cac9:a3ff:fed0:65bc%wlp1s0]:5540'
[1681839455.878590][114395:114400] CHIP:SC: Sent Sigma1 msg
[1681839455.878645][114395:114400] CHIP:CTL: OperationalSessionSetup[1:0000000000000001]: State change 3 --> 4
[1681839456.049543][114395:114400] CHIP:EM: >>> [E:3880i M:28427396 (Ack:251214339)] (U) Msg RX from 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
[1681839456.049629][114395:114400] CHIP:EM: Found matching exchange: 3880i, Delegate: 0x7f763400d918
[1681839456.049685][114395:114400] CHIP:EM: Rxd Ack; Removing MessageCounter:251214339 from Retrans Table on exchange 3880i
[1681839457.148350][114395:114400] CHIP:EM: >>> [E:3880i M:28427397 (Ack:251214339)] (U) Msg RX from 0:0000000000000000 [0000] --- Type 0000:31 (SecureChannel:CASE_Sigma2)
[1681839457.148438][114395:114400] CHIP:EM: Found matching exchange: 3880i, Delegate: 0x7f763400d918
[1681839457.148510][114395:114400] CHIP:EM: CHIP MessageCounter:251214339 not in RetransTable on exchange 3880i
[1681839457.148601][114395:114400] CHIP:SC: Received Sigma2 msg
[1681839457.148720][114395:114400] CHIP:SC: Peer assigned session session ID 21845
[1681839457.155273][114395:114400] CHIP:SC: Found MRP parameters in the message
[1681839457.155340][114395:114400] CHIP:SC: Sending Sigma3
[1681839457.156207][114395:114400] CHIP:EM: <<< [E:3880i M:251214340 (Ack:28427397)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:32 (SecureChannel:CASE_Sigma3)
[1681839457.156405][114395:114400] CHIP:IN: (U) Sending msg 251214340 to IP address 'UDP:[fe80::cac9:a3ff:fed0:65bc%wlp1s0]:5540'
[1681839457.156643][114395:114400] CHIP:SC: Sent Sigma3 msg
[1681839457.352793][114395:114400] CHIP:EM: >>> [E:3880i M:28427398 (Ack:251214340)] (U) Msg RX from 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
[1681839457.352893][114395:114400] CHIP:EM: Found matching exchange: 3880i, Delegate: 0x7f763400d918
[1681839457.352995][114395:114400] CHIP:EM: Rxd Ack; Removing MessageCounter:251214340 from Retrans Table on exchange 3880i
[1681839459.708127][114395:114400] CHIP:EM: >>> [E:3880i M:28427399 (Ack:251214340)] (U) Msg RX from 0:0000000000000000 [0000] --- Type 0000:40 (SecureChannel:StatusReport)
[1681839459.708212][114395:114400] CHIP:EM: Found matching exchange: 3880i, Delegate: 0x7f763400d918
[1681839459.708253][114395:114400] CHIP:EM: CHIP MessageCounter:251214340 not in RetransTable on exchange 3880i
[1681839459.708328][114395:114400] CHIP:SC: Success status report received. Session was established
[1681839459.712433][114395:114400] CHIP:SC: SecureSession[0x7f763400b030]: Moving from state 'kEstablishing' --> 'kActive'
[1681839459.712492][114395:114400] CHIP:IN: SecureSession[0x7f763400b030]: Activated - Type:2 LSID:20649
[1681839459.712542][114395:114400] CHIP:IN: New secure session activated for device <0000000000000001, 1>, LSID:20649 PSID:21845!
[1681839459.712606][114395:114400] CHIP:CTL: OperationalSessionSetup[1:0000000000000001]: State change 4 --> 5
[1681839459.712709][114395:114400] CHIP:TOO: Sending cluster (0x00000006) command (0x00000002) on endpoint 1
[1681839459.712874][114395:114400] CHIP:DMG: ICR moving to [AddingComm]
[1681839459.712917][114395:114400] CHIP:DMG: ICR moving to [AddedComma]
[1681839459.713065][114395:114400] CHIP:EM: <<< [E:3881i M:48363933] (S) Msg TX to 1:0000000000000001 [00AB] --- Type 0001:08 (IM:InvokeCommandRequest)
[1681839459.713124][114395:114400] CHIP:IN: (S) Sending msg 48363933 on secure session with LSID: 20649
[1681839459.713339][114395:114400] CHIP:DMG: ICR moving to [CommandSen]
[1681839459.713366][114395:114400] CHIP:EM: <<< [E:3880i M:251214341 (Ack:28427399)] (U) Msg TX to 0:0000000000000000 [0000] --- Type 0000:10 (SecureChannel:StandaloneAck)
[1681839459.713408][114395:114400] CHIP:IN: (U) Sending msg 251214341 to IP address 'UDP:[fe80::cac9:a3ff:fed0:65bc%wlp1s0]:5540'
[1681839459.713437][114395:114400] CHIP:EM: Flushed pending ack for MessageCounter:28427399 on exchange 3880i
[1681839460.014999][114395:114400] CHIP:EM: >>> [E:3881i M:51274839 (Ack:48363933)] (S) Msg RX from 1:0000000000000001 [00AB] --- Type 0001:09 (IM:InvokeCommandResponse)
[1681839460.015083][114395:114400] CHIP:EM: Found matching exchange: 3881i, Delegate: 0x7f763400a7a8
[1681839460.015166][114395:114400] CHIP:EM: Rxd Ack; Removing MessageCounter:48363933 from Retrans Table on exchange 3881i
[1681839460.015240][114395:114400] CHIP:DMG: ICR moving to [ResponseRe]
[1681839460.015422][114395:114400] CHIP:DMG: InvokeResponseMessage =
[1681839460.015474][114395:114400] CHIP:DMG: {
[1681839460.015529][114395:114400] CHIP:DMG:     suppressResponse = false,
[1681839460.015579][114395:114400] CHIP:DMG:     InvokeResponseIBs =
[1681839460.015657][114395:114400] CHIP:DMG:     [
[1681839460.015706][114395:114400] CHIP:DMG:    	 InvokeResponseIB =
[1681839460.015779][114395:114400] CHIP:DMG:    	 {
[1681839460.015821][114395:114400] CHIP:DMG:    		 CommandStatusIB =
[1681839460.015880][114395:114400] CHIP:DMG:    		 {
[1681839460.015931][114395:114400] CHIP:DMG:    			 CommandPathIB =
[1681839460.015994][114395:114400] CHIP:DMG:    			 {
[1681839460.016053][114395:114400] CHIP:DMG:    				 EndpointId = 0x1,
[1681839460.016111][114395:114400] CHIP:DMG:    				 ClusterId = 0x6,
[1681839460.016166][114395:114400] CHIP:DMG:    				 CommandId = 0x2,
[1681839460.016222][114395:114400] CHIP:DMG:    			 },
[1681839460.016294][114395:114400] CHIP:DMG:
[1681839460.016343][114395:114400] CHIP:DMG:    			 StatusIB =
[1681839460.016403][114395:114400] CHIP:DMG:    			 {
[1681839460.016461][114395:114400] CHIP:DMG:    				 status = 0x00 (SUCCESS),
[1681839460.016513][114395:114400] CHIP:DMG:    			 },
[1681839460.016573][114395:114400] CHIP:DMG:
[1681839460.016621][114395:114400] CHIP:DMG:    		 },
[1681839460.016690][114395:114400] CHIP:DMG:
[1681839460.016735][114395:114400] CHIP:DMG:    	 },
[1681839460.016804][114395:114400] CHIP:DMG:
[1681839460.016847][114395:114400] CHIP:DMG:     ],
[1681839460.016919][114395:114400] CHIP:DMG:
[1681839460.016966][114395:114400] CHIP:DMG:     InteractionModelRevision = 1
[1681839460.017012][114395:114400] CHIP:DMG: },
[1681839460.017161][114395:114400] CHIP:DMG: Received Command Response Status for Endpoint=1 Cluster=0x0000_0006 Command=0x0000_0002 Status=0x0
[1681839460.017265][114395:114400] CHIP:DMG: ICR moving to [AwaitingDe]
[1681839460.017460][114395:114400] CHIP:EM: <<< [E:3881i M:48363934 (Ack:51274839)] (S) Msg TX to 1:0000000000000001 [00AB] --- Type 0000:10 (SecureChannel:StandaloneAck)
[1681839460.017539][114395:114400] CHIP:IN: (S) Sending msg 48363934 on secure session with LSID: 20649
[1681839460.017745][114395:114400] CHIP:EM: Flushed pending ack for MessageCounter:51274839 on exchange 3881i
[1681839460.018145][114395:114395] CHIP:CTL: Shutting down the commissioner
[1681839460.018193][114395:114395] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1681839460.018369][114395:114395] CHIP:CTL: Shutting down the controller
[1681839460.018423][114395:114395] CHIP:IN: Expiring all sessions for fabric 0x1!!
[1681839460.018476][114395:114395] CHIP:IN: SecureSession[0x7f763400b030]: MarkForEviction Type:2 LSID:20649
[1681839460.018526][114395:114395] CHIP:SC: SecureSession[0x7f763400b030]: Moving from state 'kActive' --> 'kPendingEviction'
[1681839460.018581][114395:114395] CHIP:IN: SecureSession[0x7f763400b030]: Released - Type:2 LSID:20649
[1681839460.018642][114395:114395] CHIP:FP: Forgetting fabric 0x1
[1681839460.018713][114395:114395] CHIP:TS: Pending Last Known Good Time: 2023-04-18T20:17:41
[1681839460.019360][114395:114395] CHIP:TS: Previous Last Known Good Time: 2023-04-18T20:17:41
[1681839460.019410][114395:114395] CHIP:TS: Reverted Last Known Good Time to previous value
[1681839460.019466][114395:114395] CHIP:CTL: Shutting down the commissioner
[1681839460.019492][114395:114395] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1681839460.019581][114395:114395] CHIP:CTL: Shutting down the controller
[1681839460.019612][114395:114395] CHIP:CTL: Shutting down the System State, this will teardown the CHIP Stack
[1681839460.019807][114395:114395] CHIP:DMG: IM WH moving to [Uninitialized]
[1681839460.019829][114395:114395] CHIP:DMG: IM WH moving to [Uninitialized]
[1681839460.019853][114395:114395] CHIP:DMG: IM WH moving to [Uninitialized]
[1681839460.019879][114395:114395] CHIP:DMG: IM WH moving to [Uninitialized]
[1681839460.019907][114395:114395] CHIP:DMG: All ReadHandler-s are clean, clear GlobalDirtySet
[1681839460.019996][114395:114395] CHIP:BLE: BleConnectionDelegate::CancelConnection is not implemented.
[1681839460.020428][114395:114395] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-bLHbmy)
[1681839460.021010][114395:114395] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1681839460.021108][114395:114395] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
[1681839460.021135][114395:114395] CHIP:DL: Inet Layer shutdown
[1681839460.021163][114395:114395] CHIP:DL: BLE shutdown
[1681839460.060082][114395:114395] CHIP:CTL: Device Controller Factory already initialized...
[1681839460.060122][114395:114395] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1681839460.060138][114395:114395] CHIP:CTL: Setting attestation nonce to random value
[1681839460.060163][114395:114395] CHIP:CTL: Setting CSR nonce to random value
[1681839460.060288][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs
[1681839460.060297][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Attempt to re-initialize with KVS config file: /tmp/chip_kvs
[1681839460.060350][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_factory.ini
[1681839460.060358][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Attempt to re-initialize with KVS config file: /tmp/chip_factory.ini
[1681839460.060374][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_config.ini
[1681839460.060382][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Attempt to re-initialize with KVS config file: /tmp/chip_config.ini
[1681839460.060398][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_counters.ini
[1681839460.060406][114395:114395] CHIP:DL: ChipLinuxStorage::Init: Attempt to re-initialize with KVS config file: /tmp/chip_counters.ini
[1681839460.060542][114395:114395] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-7XyWIb)
[1681839460.060726][114395:114395] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1681839460.060755][114395:114395] CHIP:DL: NVS set: chip-counters/reboot-count = 10 (0xA)
[1681839460.060979][114395:114395] CHIP:DL: Got Ethernet interface: enp2s0
[1681839460.061112][114395:114395] CHIP:DL: Found the primary Ethernet interface:enp2s0
[1681839460.061239][114395:114395] CHIP:DL: HOANG: RUN In ConnectivityUtils::GetWiFiInterfaceName(sWiFiIfName, IFNAMSIZ) == CHIP_NO_ERROR)
[1681839460.061248][114395:114395] CHIP:DL: Got WiFi interface: wlp1s0
[1681839460.061801][114395:114395] CHIP:DL: FiagnosticDataProviderImpl::ResetWiFiNetworkDiagnosticsCounts()
[1681839460.061825][114395:114395] CHIP:DL: Found the primary WiFi interface:wlp1s0
[1681839460.061888][114395:114395] CHIP:IN: UDP::Init bind&listen port=0
[1681839460.061986][114395:114395] CHIP:IN: UDP::Init bound to port=57702
[1681839460.062024][114395:114395] CHIP:IN: UDP::Init bind&listen port=0
[1681839460.062113][114395:114395] CHIP:IN: UDP::Init bound to port=50927
[1681839460.062142][114395:114395] CHIP:IN: BLEBase::Init - setting/overriding transport
[1681839460.062160][114395:114395] CHIP:IN: TransportMgr initialized
[1681839460.062197][114395:114395] CHIP:FP: Initializing FabricTable from persistent storage
[1681839460.062431][114395:114395] CHIP:TS: Last Known Good Time: 2023-04-18T20:17:41
[1681839460.062959][114395:114395] CHIP:FP: Fabric index 0x1 was retrieved from storage. Compressed FabricId 0x8667A69C0E7F00AB, FabricId 0x0000000000000001, NodeId 0x000000000001B669, VendorId 0xFFF1
[1681839460.063924][114395:114395] CHIP:ZCL: Using ZAP configuration...
[1681839460.064226][114395:114395] CHIP:DL: MDNS failed to join multicast group on enp2s0 for address type IPv4: ../examples/chip-tool/third_party/connectedhomeip/src/inet/UDPEndPointImplSockets.cpp:761: Inet Error 0x00000110: Address not found
[1681839460.064514][114395:114395] CHIP:CTL: System State Initialized...
[1681839460.064542][114395:114395] CHIP:IN: UDP::Init bind&listen port=5550
[1681839460.064575][114395:114395] CHIP:IN: UDP::Init bound to port=5550
[1681839460.064585][114395:114395] CHIP:IN: UDP::Init bind&listen port=5550
[1681839460.064617][114395:114395] CHIP:IN: UDP::Init bound to port=5550
[1681839460.064626][114395:114395] CHIP:IN: TransportMgr initialized
[1681839460.064808][114395:114403] CHIP:DL: CHIP task running
[1681839460.064930][114395:114403] CHIP:TOO: Sending command to node 0x1
[1681839460.065118][114395:114395] CHIP:CTL: Shutting down the commissioner
[1681839460.065127][114395:114395] CHIP:CTL: Stopping commissioning discovery over DNS-SD
[1681839460.065159][114395:114395] CHIP:CTL: Shutting down the controller
[1681839460.065168][114395:114395] CHIP:CTL: Shutting down the System State, this will teardown the CHIP Stack
[1681839460.065237][114395:114395] CHIP:DMG: IM WH moving to [Uninitialized]
[1681839460.065245][114395:114395] CHIP:DMG: IM WH moving to [Uninitialized]
[1681839460.065254][114395:114395] CHIP:DMG: IM WH moving to [Uninitialized]
[1681839460.065263][114395:114395] CHIP:DMG: IM WH moving to [Uninitialized]
[1681839460.065273][114395:114395] CHIP:DMG: All ReadHandler-s are clean, clear GlobalDirtySet
[1681839460.065302][114395:114395] CHIP:BLE: BleConnectionDelegate::CancelConnection is not implemented.
[1681839460.065427][114395:114395] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-tiyzdX)
[1681839460.065579][114395:114395] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1681839460.065606][114395:114395] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
[1681839460.065616][114395:114395] CHIP:DL: Inet Layer shutdown
[1681839460.065626][114395:114395] CHIP:DL: BLE shutdown
[1681839460.065636][114395:114395] CHIP:DL: System Layer shutdown
[1681839460.065667][114395:114395] CHIP:TOO: Run command failure: ../examples/chip-tool/third_party/connectedhomeip/src/controller/CHIPDeviceController.h:212: CHIP Error 0x00000003: Incorrect state

chip-tool when running in non-interactive mode might be shutting things down and then not restarting them again if you just try to call main() again, since it does not expect you to do that.
In particular, you are failing on GetConnectedDevice on a CHIPDeviceController when its state is not State::Initialized.
You'll need to do some tracking of what exactly happens with controller lifetimes in this very odd setup.

Thank you! So how can I controll onoff 5 device and caculate their delay time without call main() again? And can you explain the information of --trace_file for me?
./chip-tool onoff toggle 1 1 --trace_file onoff.tx
--> So what information onoff.txt does this file have?
Best regards!

"trace_file" is where a log of the message traffic gets saved.

So how can I controll onoff 5 device and caculate their delay time without call main() again?

What are you actually trying to do?  Are they 5 different devices?  Do you want to calculate the "delay time" including session establishment to each device?  Or are you trying to talk to the same device 5 times?

I want to establish a benchmark systerm:
I controll onoff them with only 1 CLI ( examples I create a script as "./chip-tool onoff toggle 1-50 1" mean toggle nodeID from 1 to 50). So I run demo 5 devices. And I want to caculate "time delay" including session establishment to each device!
Thank you!

Is there a reason the "only one CLI" can't be a script that then invokes chip-tool multiple times?
If you absolutely need the functionality in chip-tool itself you will need to do some digging through the code to see how to make it do things it's currently not designed to do.

Yes, it's necessary for me with " only one CLI", because I have to test them with a long time and others function. I have read the flow of code ( command ./chip-tool onoff toggle 1 1). I have 1 idea, after chip-tool process argv[2] ( "toggle" ), I will check how chip-tool save NodeId, to transport message, and I execute "for nodeId from 1 to 50). May be it logical?
Thanks!

It might be logical, if you also make sure that all the setup/teardown happens properly for that use case.  Again, chip-tool may not be set up right now to repeatedly set up and tear down controllers.


Features??

How many of these features are actually available?
Log all login attempts to the database
support for reverse proxies with different headers for IP addresses
rate limit based on:
username
ip address
use redis for the blacklist
configuration
redis server
host
port
database
password
key_prefix
block length
number of incorrect attempts before block
95% code coverage
full documentation
Ability to store login attempts to the database
Management command to clean up login attempts database table
admin pages
list of blocked usernames and ip's
ability to unblock people
list of recent login attempts
Can be easly adapted to custom authentication method.

Should be all, except for backlist, which is currently in design stage.

closing this since it isn't an issue. all features are listed in the readme, if you have an actual issue, please let us know


config means/std incorrect for training data

@andregraubner  The means and std values in the configuration file look to be incorrect.  I am assuming these are actual means and std calculated from the training data and used for normalization.  For instance the mean for PSL is 1619.3 which is odd as its calculated from a field that is in hPA. (94000-105000).  As long as the data used for inference is also normalized using these wonky values the model is able to pick out features correctly but as soon as means calculated from the inference data are used the trained model is unable to detect AR's TC's

Hi Andre.  I work for NCAR and our group is actually collaborating with the climatenet team although that started a few years ago while Prabhat was still there.  We produced the CAM5.1 data that is being used for training.  The cam6 data we are using should have the same statistics as the data in your repository.  Although these bad normalizing values do produce valid looking masks the normalizing data looks to be far enough off (at least for PSL) to affect the accuracy.  I just wanted to make sure I wasn't missing something.  We will recalculate the means/std, fix the config file and retrain, I trust you'll do the same.  I think the new interface looks great by the way, nice job!

Hi @andregraubner, I've been working with @jtruesdal and happened to recently calculate some of the mean and standard deviation values for the training dataset, so I thought I'd share that here in case it is helpful for cross-checking.
TMQ mean: 19.21849
TMQ std: 15.73182
U850 mean: 1.55302
U850 std: 8.27790
V850 mean: 0.25413
V850 std: 6.21594
PSL mean:<PHONE_NUMBER>1
PSL std: 1454.36969

Thank you very much. We will soon provide an additional pre-trained model using these values. I'll post an update here then and close the issue accordingly. Please reach out if anything else pops up!

Thank you again for bringing this to our attention. We have updated the pre-trained model accordingly and verified that there results reported in the paper still hold. Please don't hesitate to reach out if anything else comes up.

@andregraubner I'm revisiting this issue as I have two questions about best practices for calculating these means and standard deviations for the cgnet config file. I'd be interested to hear your & others thoughts.

Should the mean calculation utilize a weighted mean across space (lat/lon)? The numbers @TeaganKing shared above are for an unweighted mean across space/time for the training data.
Should the standard deviation including any weighting? Currently we are calculating standard deviation across all space/time values for a single variable.

For reference, here are the mean values if you include weighting by cos(lat) over space. They do differ from above but not very significantly:
TMQ mean: 24.92724
U850 mean: 1.03567
V850 mean: 0.20848
PSL mean:<PHONE_NUMBER>
I have a notebook here if you want to take a closer look at the calculations:
https://github.com/katiedagon/ML-extremes/blob/main/notebooks/get_averages_and_standard_devs.ipynb


Cant uncheck RadioButton

Cant uncheck radiobutton, because clearCheck() function stetted private, is there any other alternative?

You can uncheck the radio button using:
radioButton.isChecked = false

@raheemadamboev  i have also same issue if i set radioButton.isChecked = false then it won't check again.

@raheemadamboev the issue is if i use mentioned code programmatically  then we cant check again same radio button

@pamungkasandono have you found solution ?


[Feature Request] Option to Disable Auto-Trigger for Specific Pull Requests

My team often creates pull requests (PRs) from a combined branch that has already reviewed branches for production deployment. In these cases, executing auto-triggered tasks on such PRs is often unnecessary, as they may involve extensive code changes and place significant load on the pr-agent service.
So, I suggest adding an option to selectively disable auto-triggered tasks on specific pull requests. This feature would allow teams to optimize their workflow and reduce unnecessary processing load. I have implemented and utilized this feature in our pr-agent codebase.
For example, this can be implemented by adding a flag to the PR title or at the end of the PR description. When this flag is present, pr-agent will not automatically perform a review. However, if needed, users can still trigger a review manually by entering a command in a comment after the PR is created.
HyeonUng

try asking first the new help tool
https://github.com/Codium-ai/pr-agent?tab=readme-ov-file#september-21-2024
/help
"add a flag to the PR title or at the end of the PR description. When this flag is present, pr-agent will not run automatically"

@mrT23 Oh, that seems like a good new tool. Thanks. In which PR would I have to ask using command?

Whatever you want. Use an older one that was already closed, for example.
We will soon add it also for the PR chat, so the usage will be more natural

It seems that the ignore pr title configuration in the document page has not yet been updated. Or intentionally left out?
https://pr-agent-docs.codium.ai/usage-guide/automations_and_usage/#github-app-automatic-tools-when-a-new-pr-is-opened

what ?
https://github.com/Codium-ai/pr-agent/pull/1248#issuecomment-2368921748

Oh, the ignore pr section has been moved to the additional configuration menu? It was in the Automation and Usage menu in the previous version, so I thought it had been removed. Thanks anyway.

Oh, the ignore pr section has been moved to the additional configuration menu? It was in the Automation and Usage menu in the previous version, so I thought it had been removed. Thanks anyway.

use the help search, as i instructed


Notification email text and template tweaks

Several of the notification emails need their text tweaked to make more sense.

Fixed


Fix #685 - Enable autocompletion and quickinfo for config.js

This is the remaining work to enable autocompletion / quick info in the config.js (which is now a config.tsx).
This moves the default configuration strategy to use TypeScript, which allows us to bring the full capabilities of the language service + the oni api typings with configuration, resulting in a much better experience:

This fixes a bug in the distribution build where we don't supply typings properly for oni-api, and adds a CiTest to validate it build-over-build

Created this document on migration, too:
https://github.com/onivim/oni/wiki/Migrating-Configuration-to-TypeScript


Quantization fails using ARMNN if layers are in particular Sequence

Hi,
I have created ResNet FP32 model using armnn APIs. When I tried to quantize it fails with below error
Thread 1 "ArmnnQuantizer" received signal SIGSEGV, Segmentation fault.
0x0000007fbe7a7454 in armnn::OutputSlot::CalculateIndexOnOwner() const () from ./libarmnn.so.19

But when I change the order of layers like moving the poolLayer1 below convLayer10. It proceeds and gives out error simialr to issue https://github.com/ARM-software/armnn/issues/321
Attached is ResNet.cpp(contains portion of ResNet model)  which is used for creation of FP32 model and then used for quantization.
Let me know if you need any further info.
ResNetQuery.zip
Thank you,
Praveen.

Closing this per comment acknowledging fix on #321


Requirements specification incorrect: Matplotlib

Description
To install pip packages the requirements file suggests there are no version restrictions.
A run of Travis CI clearly warns at least one test will break for Matplotlib >=3.3

The dependency showing the error is not used, so that can be fixed easily.
I am not sure how I would go about to check the minimum version required for each library. Would you need me to do so?

Isn't there is a minimum python version?  this should be in the requirements file - I believe python allows this.
For package minimum versions take the smallest version numbers that you know to work the time of publication.
Yes please add minimum versions numbers - the role of your users is not to discover minimum package versions by discovering/reporting what versions do not work.

I added "minimum" versions in the requeriments.txt file as well as in the setup.py


Coinbase.lua:85: attempt to index field 'native_balance' (a nil value)

Can some one help me with: Coinbase.lua:85: attempt to index field 'native_balance' (a nil value)
Ths response I get when I try to integrate my coinbase account into MoneyMoney

Hey @mpjjanssen would you like to share more information here? Versions of the coinbase.lua and MoneyMoney would be helpful.

Thanks for asking!
MoneyMoney Version 2.4.33 (442) Beta
I cannot find the Lua version . I don’t know where to find it.
Thanks,
Martien
Von: Martin Wilhelmi @.>
Datum: Samstag, 30. März 2024 um 10:58
An: mnin/coinbase-moneymoney @.>
Cc: mpjjanssen @.>, Mention @.>
Betreff: Re: [mnin/coinbase-moneymoney] Coinbase.lua:85: attempt to index field 'native_balance' (a nil value) (Issue #15)
Hey @mpjjanssenhttps://github.com/mpjjanssen would you like to share more information here? Versions of the coinbase.lua and MoneyMoney would be helpful.
—
Reply to this email directly, view it on GitHubhttps://github.com/mnin/coinbase-moneymoney/issues/15#issuecomment-2027997116, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARZSPILTBWQLZDVCVCAVBPDY2Z5CRAVCNFSM6AAAAABFOBTDIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXHE4TOMJRGY.
You are receiving this because you were mentioned.Message ID: @.***>

Simply start MoneyMoney, then go to Help and "Show Database in Finder" in the menu bar. The Finder then opens with three directories: Database, Extension, Statements. Then go to the Extensions folder. There you should find the file Coinbase.lua, open it e.g. with TextEdit and you should see this in the first lines:
WebBanking {
  version = 2.1,
  url = "https://api.coinbase.com",
  description = "Fetch balances from Coinbase API and list them as securities",
  services = { "Coinbase Account" },
}

If it is not version 2.1, download the latest version from https://github.com/mnin/coinbase-moneymoney/blob/main/dist/Coinbase.lua and replace it in the folder and try again.

Hello Martin
Thank you so much! It worked!!!
Martien Janssen
Von: Martin Wilhelmi @.>
Datum: Montag, 1. April 2024 um 14:22
An: mnin/coinbase-moneymoney @.>
Cc: mpjjanssen @.>, Mention @.>
Betreff: Re: [mnin/coinbase-moneymoney] Coinbase.lua:85: attempt to index field 'native_balance' (a nil value) (Issue #15)
Simply start MoneyMoney, then go to Help and "Show Database in Finder" in the menu bar. The Finder then opens with three directories: Database, Extension, Statements. Then go to the Extensions folder. There you should find the file Coinbase.lua, open it e.g. with TextEdit and you should see this in the first lines:
WebBanking {
version = 2.1,
url = "https://api.coinbase.com",
description = "Fetch balances from Coinbase API and list them as securities",
services = { "Coinbase Account" },
}
If it is not version 2.1, download the latest version from https://github.com/mnin/coinbase-moneymoney/blob/main/dist/Coinbase.lua and replace it in the folder and try again.
—
Reply to this email directly, view it on GitHubhttps://github.com/mnin/coinbase-moneymoney/issues/15#issuecomment-2029675248, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARZSPIP3PKAVM65XXYMTESDY3FGPDAVCNFSM6AAAAABFOBTDIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRZGY3TKMRUHA.
You are receiving this because you were mentioned.Message ID: @.***>


Required  Guid from Header is not shown as required

I am using 2.4 version and for property:
    [FromHeader(Name = "x-guid-id")]
        [Required]
        public Guid GuidId { get; set; }

generated documentation doesn't show Required.
It works correctly for
[FromHeader(Name = "x-string-id")]
        [Required]
        public string StringId { get; set; }

You can loaded an example  from https://github.com/MNF/Samples/tree/master/SwashbuckleExample

Swashbuckle sets the required flag according to ASP.NET Core's built-in request validation behavior (i.e. ModelState.IsValid). In your example, that validation will succeed even if the request DID NOT contain the GuidId parameter. This is because the RequiredAttribute has no effect on properties that have a non-null default value. Therefore, and by design, SB does not mark it required.
Swashbuckle aside, you need to make the Guid nullable to get the validation behavior you want. And, if you do that, SB will follow suit by describing it as required

Thank you for explaining the implementation details. I’ve also found https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/599, that gives me more info about the approach.
However I think that you should honour RequiredAttribute.
As an API author, I am marking  the property as Required and wish to see it in the generated documentation to highlight it for clients.

Developers, including myself, can fall into the trap of using RequiredAttribute on a value type without realizing that a subsequent validation can't possibly fail.
From https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/599

Yes, it’s technically redundant, but I don’t think, that it should be  Swashbuckle concern. Neither Visual Studio nor Resharper warn that it’s redundant.
It would be good if Swashbuckle will generate a warning, but follow author’s instructions and the promise on the readme:

this metadata will be inferred automatically so long as you're using ASP.NET Core Model Binding or Data Validation attributes to implement request validation.

BTW see related requirement Swashbuckle: Make non-nullable properties required

A few things ...
Firstly, it is Swashbuckle’s concern because it’s underlying principle is to treat the “implementation as truth”. There might be other libraries that take the opposite approach but not Swashbuckle. This has always been the goal.
Secondly, this is described in the readme so not sure what promise you’re referring to.
Thirdly, Swashbuckle provides many extension points so you could override this with the behavior you want quite trivially.
Finally, experience with this project has shown that it’s truly impossible to keep everyone happy. So, I stick to the underlying goal - implementation is truth.

“this metadata will be inferred automatically so long as you’re using ASP.NET Core or Data validation attributes to implement request validation”.
The last few words are the key here. If you’re using the RequireAttribute redundantly on a value type then you’re not using it to implement request validation :)
I thought this, combined with the additional note just after, makes it pretty clear. But, I could always take a second pass to clarify further.

As an API author, I don’t need to understand exact meaning of each word in readme. I had 2 properties (string and guid) that are mandatory for my request. I’ve marked both as “Required” and wanted to see the same in swagger.json document.
Is it a reasonable expectation?
The actual behaviour is confusing and required research to understand the difference.
Would it be better if the default behaviour will be consistent, intuitive and driven by  explicit properties in the code?
Yes, there are different possible workarounds ( I just made both properties strings). My feedback is that your library converts c# APIs to swagger very intuitively, but in this case it is not intuitive at all.


Modifier error quality in object literals

var v = { public x() { } };

The parser gives poor errors here because it does not recognize public as a modifier. This is a candidate for a cleaner error.

I now get "Modifiers cannot appear here".


Update path in config file

Updating file in config.py file to match with all operating systems

Go Ahead


node schedules workload always on "Require ALL of" instead of "Require ANY of"

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
create cluster with 4 nodes:
two with "label=app"
two with "label=worker"
create a workload
label "require ANY of" with "label=app"
Result:
look at details:
workload was labeled with:
"require ALL of" with "label=app"
Expected Result:
workload should labeled with:
"require ANY of" with "label=app"
Other details that may be helpful:
https://user-images.githubusercontent.com/1597621/124339783-0c7ac980-dbb1-11eb-9fe0-1bb23ae38fba.mov
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):

v2.5.8

Installation option (single install/HA):

single instal

ping.. to don't get lost..


Update CODOWNERS and README

Checklist

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

The autobot wasn't re-rendering properly despite the changed maintainer list. So this PR does it manually

@conda-forge-admin, please rerender


0.1.1 is 245.2 MiB size!!!!

Why GFM plugin is so huge in size O_o?

I would suggest to not bundle those OS specific libs, but to download them on demand - from dropbox or somewhere. Jetbrains would surely appreciate it :)

For rendering a preview you need to have some sort of WebView.
Early versions of this plugin used(and still are) LoboEvolution and JavaFx WebView but those two has their drawbacks. Starting from 0.1.0 gfm plugin uses JxBrowser(200+mb) for rendering as a default. Here is small comparison table for WebViews which i considered to use in gfm plugin:

JxBrowser
JavaFX WebView
LoboEvolution
SWT browser

Can be embedded in swing without  on OS X (64 bit)
:white_check_mark:
:white_check_mark:
:white_check_mark:
:x: (cocoa restrictions)

Runs with Java 6
:white_check_mark:
:x: (Unless it's Windows)
:white_check_mark:
:white_check_mark:

Renders SVG
:white_check_mark:
:white_check_mark:
:x:
:white_check_mark:

Renders Images
:white_check_mark:
:white_check_mark:
:x:
:white_check_mark:

Renders Css properly
:white_check_mark:
:ballot_box_with_check: (Has problems with fonts)
:x:
:white_check_mark:

Fast rendering speed
:white_check_mark:
:white_check_mark:
:x:
:white_check_mark:

Many people still run Intellij platform products on java 6(no JavaFx) due to font rendering problems with java 7 and java 8 on retina displays; some versions(new ones) of Intellij platform products comes with bundled OpenJre 8 without OpenFx bundled(so JavaFx WebView will not work). In fact even if Intellij is run with (Oracle)Java8 JavaFx is not in classpath so I need to do some nasty things to get it worked.
I'll contact Jetbrains about on demand lib downloading. If Jetbrains will be Ok about getting OS specific libs from some kind of storage on demand that'll do.

I'm sorry, but even if you'll download it on demand, this is ***king crazy amount of data, IDE itself with lots of functionality have 312 MiB size.
Even browser with all possible extensions I have have smaller size. Lets be honest, 245.2 MiB is TOO MUCH for plugin of such kind.
I'm not familiar with Java, so I can't suggest anything here, but I hope it will be possible to find solution with reasonable size, lets say, < 10 MiB

@nazar-pc libs for other OSs take 200MB. 50 MB jar for Windows is totally ok with me, if the permgen can handle it.

@krasa, well, I'm on Linux x64)

@nazar-pc 70MB is still ok ^^

maybe you can take a look at (ghfm, a good implementation in node.js)[https://github.com/arboleya/ghfm]... they do it in 23 MB.  ;-)

I suggest to distribute a version without bunding jxbrowser-<platform>-<version>.jar, and when rending engine is JxBrowser, notify the user.
I don't think any user like to download 3 useless huge other platform's jar. For the size:

File
Size

jxbrowser-linux32-5.4.3.jar
74M

jxbrowser-linux64-5.4.3.jar
73M

jxbrowser-mac-5.4.3.jar
54M

jxbrowser-win-5.4.3.jar
45M

gfm-plugin.jar, Loboevolution.jar, ...
~ 4.5M

Actually, only one jar is needed. And for other jar, total 4.5M, it's acceptable.

And, another question, why still include LoboEvolution?

Whatever the answer, it kind of sucks to wait 15 minutes for a minor update.
(The JetBrains CDN is very slow...)

yeah the size is bad. not a fan :(

sad to see its open since 2015


Local: mimic the path semantics of cloud backends

This fixes #170
Store the Item's relative path to its container, not
its full path. When constructing container-based items,
treat relative paths as relative to the container, but keep
supporting absolute paths as well.
This is analogous to cloud backends, and so container.Item("name")
means the same thing in all backends - it means an item called "name"
that is stored inside the container.
On the other hand, we still want to support
container.Item("/full/path/to/name"), because the full path is the ID
of the Item. So this patch interprets an absolute path as the full
path of the item, and converts that to a relative path for internal
storage.

PR updated with a commit to do the same with containers, relative to their location (i.e. for the local backend, location.Container("foo") means /path/to/location/foo)

@urisimchoni are you thinking of pushing this? Is something blocking you? I encountered this bug too

@kumare3 I have no push rights here. Things have been pretty quiet in this project - we need to reach the maintainers and ask what's up.

@urisimchoni Team is reviewing now along with your other PRs.

New version. This is pretty much a rewrite of the previous PR:

no link from item to container, instead keep the length of the path that belongs to the component
the added tests are generic tests instead of local-specific. This demonstrates the behavior in other backends, namely that c.Item(name) is relative to the container etc. - the new tests pass with cloud backends, but only pass on the local backend with changes applied
add a local-specific test to document the URL-to-item tranlsation, as requested in the PR.

Any update on this?


[Post-v1.11] Add validate mode info

To be merged after https://github.com/zowe/zowe-install-packaging/pull/1335
Signed-off-by: stevenhorsman<EMAIL_ADDRESS>Is there a related issue for this PR?
Issue number: #1180

Hi @stevenhorsman , FYI if you intend to publish this soon it will need to be merged into master rather than doc-staging branch. If you merge into doc-staging the content won't go out until v1.12.0. Apologies if you already know that!

@BrandonJenkins14 - thanks for making sure - but this is doc-ing new function which isn't in 1.11, so deliberately against doc-staging

@stevenhorsman Hi Steve, I tweaked the wording to be as follows, which might sound more task-oriented and from the user's perspective. Let me know if there is any technical inaccuracy. Thanks!

If you are a Zowe administrator, you might want to check whether all the component validation checks of the Zowe installation pass without starting any of the components. To do this, you can add VALIDATE_ONLY=true to the instance.env file. Then, Zowe will not be launched after the validation stage.

zowe/zowe-install-packaging#1335 has been merged to staging, so merging the docs in this PR.


Add DocIdSetOprator to explain plan

Description
The current implementation of explain plan skips creating an
entry for DocIdSetOperator. This PR adds it.
Testing:

Modified ExplainPlanQueriesTest to reflect the changes.

Codecov Report

Merging #8446 (42b3a1d) into master (51904fb) will decrease coverage by 6.36%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #8446      +/-   ##
============================================
- Coverage     70.58%   64.21%   -6.37%
- Complexity     4282     4285       +3
============================================
  Files          1663     1618      -45
  Lines         87283    85375    -1908
  Branches      13208    13004     -204
============================================
- Hits          61609    54827    -6782
- Misses        21385    26563    +5178
+ Partials       4289     3985     -304

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
67.06% <ø> (+0.03%)
:arrow_up:

unittests2
14.15% <ø> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 51904fb...42b3a1d. Read the comment docs.

@amrishlal Did you intentionally skip the DocIdSetOperator, or that one missing unexpectedly?

@amrishlal Did you intentionally skip the DocIdSetOperator, or that one missing unexpectedly?

Yes it was skipped intentionally but there wasn't any strong reason behind it. At the time, we just decided to do the initial merge and postpone improvements such as putting in DocIdSetOperator for later incremental PRs.

Just wanted to add - based on the discussion here (DocIDSetOperator.java file), we agreed that it would be useful to show DocIdSetOperator in the explain plan tree just so that the user understands that there is an execution layer between projection and filter operator.


fix

Codecov Report

Merging #289 (213cfbb) into master (ad6cd9c) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #289      +/-   ##
==========================================
+ Coverage   87.51%   87.52%   +0.01%
==========================================
  Files          22       22
  Lines        2298     2301       +3
==========================================
+ Hits         2011     2014       +3
  Misses        287      287

Impacted Files
Coverage Δ

src/circuits/noise.jl
85.58% <100.00%> (+0.13%)
:arrow_up:

src/tomography/fulltomography.jl
97.34% <100.00%> (+0.04%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 16b38f4...213cfbb. Read the comment docs.


Add most recent Python versions in Travis CI

Add more recent Python versions including
development branches and nightly build.
The motivation came from reading @brettcannon's article : https://snarky.ca/how-to-use-your-project-travis-to-help-test-python-itself/ . Trying to activate the newest Python versions on CI jobs is in most case a win-win situation: if everything works fine, there is nothing to worry about. If an issue is spotted, it is good to know about it to fix it on your side or to open a bug on Cython ( https://bugs.python.org/ ).
Also, if a failures is spotted, you can use the allow_failures option in your matrix build (more information about this in the link above).
Also, nightly and 3.7-dev may be a bit too recent/unstable so I can remove then if need be.
More information about how this PR happened on https://github.com/SylvainDe/CIthon .

Coverage decreased (-0.7%) to 72.86% when pulling 3cdcdda8f06fb46a8160fcf65c0e365c4c5b20d8 on SylvainDe:master into 85e2df565efa8680ef1ee2b88a7aebcd65ac19a0 on nficano:master.


Stutter - allowscrolloverheader

Appears to be a noticeable  stutter when tabs.container has allowscrolloverheader={true}.  After pulling down, as the over header then closes it seems to stutter.
Not sure if its because of promotion on iphone

I'm also getting a stutter and noticed its tied to the yScroll it seems to have "spikes" when the amount of renderItems is like less than 5.


issue #157

py3.8 tests added in ci according issue #157

Hey @4lovi4 ! This looks great—thank you so much! 🙌
Worryingly, CircleCi still isn't building for some reason. I've tried resetting it to see if so I'm going to play around and make some empty pushes to this branch to see if that will trigger it—apologies for the noisy notifications.

Ahh, I think I may have figured out what happened. From the CircleCI docs:

Note: If a user submits a pull request to your repository from a fork, but no pipeline is triggered, then the user most likely is following a project fork on their personal account rather than the project itself of CircleCi, causing the jobs to trigger under the user’s personal account and not the organization account. To resolve this issue, have the user unfollow their fork of the project on CircleCI and instead follow the source project. This will trigger their jobs to run under the organization when they submit pull requests

Could you unfollow your fork of abagen on CircleCI and instead follow the rmarkello/abagen project? Once you do that let me know and we can re-trigger a build on this PR.
Let me know if you have any questions!

I've unfollowed my fork project in circleci. Unfortunately I can't find the way how to follow the original rmarkello/abagen. Maybe I have a lack of permissions. Didn't find this in ci doc also.

It looks like perhaps un-following was all you needed to do—the CircleCI is running (with the new Python 3.8 test build 🎉)!
The Azure error is unrelated to your changes here and I'm working on resolving it, so I'll merge this in if the CircleCI build passes :100:

As said, Azure failing is unrelated so I'm gonna go ahead and merge this. Thanks so much for adding Python 3.8 testing!!


Static glfw3.lib is linked with dynamic MSVCRT by default

Windows users sometimes perfer to build static binary to avoid the hassle of managing DLLs.
Building from source, cmake -DBUILD_SHARED_LIBS=OFF will create the static library glfw3.lib, which is linked with the dynamic link library MSVCRT (/MD). To verify, grep __imp_qsort glfw3.lib will match, and __imp_qsort only appears in MSVCRT, not LIBCMT (/MT, the static link library).
The users will be unable to build static executables with glfw3.lib and other objects compiled with /MT. Linking will fail due to symbol conflicts between LIBCMT referenced by user objects, and MSVCRT referenced by glfw3.lib.
The official binary package also contains glfw3.lib with the same issue.
Perhaps, USE_MSVC_RUNTIME_LIBRARY_DLL should be automatically turned off when building glfw3.lib.

The default in VC++ is multithreaded DLL. A user who knows to change that setting in the application's project file should also know how to do it in the GLFW project file.

What about the prebuilt binary glfw-3.1.1.bin.WIN64.zip? The static version glfw3.lib in it is linked with dynamic version. Users who want to build static binary cannot use this prebuilt binary.

That's correct. Those packages don't provide debug mode binaries either, or binaries with all combinations of compilation options. It's a convenience aimed at the most common common use case.

I'l take that as a EWONTFIX.

Yes.
It would be unreasonable to include every combination of bitness, compiler version, libc and compilation options. There are people wanting different settings for all of those. The best option will always be to compile the version you want and that is what the download page recommends.

There is no point in providing the static glfw3.lib if you are not going to support its use case of building static binary.

This needs reopening. @xlz is correct.
I use the C++ build tools for Windows using CL from the command prompt to statically link libs. The exact issue @xlz discusses is the issue I'm having. I can't recompile. I don't have VS installed and I don't have the bandwidth to install it.
So frustrating that a static library is compiled with /MD. Why exactly?!

You're right. I was wrong. Releases now contain both /MT and /MD static libraries for all supported versions of VS, as well as a single /MT DLL built with the latest version of VS.


Validation for @cols attribute too drastic [DITA OT 2.0]

The Java method "ValidationFilter.validateCols" should not try to validate a @cols attribute value if it is set on a tgroup from a table element which has a conref.
For example this topic could be output to HTML using an older DITA OT:
    <?xml version='1.0' encoding='UTF-8'?>
    <!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "http://docs.oasis-open.org/dita/v1.1/OS/dtd/topic.dtd">
    <topic id="introduction">
        <title>Introduction</title>

                    <tgroup cols="cols_rgx_hjy_qq">

                            <row>
                                <entry/>
                            </row>

                    </tgroup>

                    <title>abc</title>
                    <tgroup cols="2">
                        <colspec colname="c1" colnum="1" colwidth="1.0*"/>
                        <colspec colname="c2" colnum="2" colwidth="1.0*"/>

                            <row>
                                <entry/>
                                <entry/>
                            </row>

                            <row>
                                <entry/>
                                <entry/>
                            </row>
                            <row>
                                <entry/>
                                <entry/>
                            </row>
                            <row>
                                <entry/>
                                <entry/>
                            </row>

                    </tgroup>

    </topic>

Any updates on this? The problem is that when from Oxygen you insert a conref to a table we will automatically add required XML content to the table element which has the conref attribute and the required content will have some random generated value for the cols attribute, something like cols="cols_rgx_hjy_qq".
So people who used Oxygen to create DITA content and to reuse DITA table will not be able to publish anymore using DITA OT 2.0 because the error seems fatal, it breaks completely the processing.

My vote is :-1: because for

  <tgroup cols="cols_rgx_hjy_qq">

      <row>
        <entry/>
      </row>

  </tgroup>

The value of @cols should clearly be "1".

I think that the @cols value generated by Oxygen is invalid - the specification states that this attribute "Indicates the number of columns in a  in a table", and that's true whether or not conref is in use (the same way these elements are required whether or not conref is used). I agree that the sample @jelovirt added should have a @cols value of "1".
So I think values like "cols_rgx_hjy_qq" are really an error. Given that these values probably exist in tables today (particularly for Oxygen users), it would be nice if this didn't completely stop processing - or if it only did so when running in a strict mode.

This is actually what OT2 currently does, processing fails only in strict mode.

FWIW I have other processing code (outside of DITA-OT) that just failed this morning for a user with similar @cols values. Given the definition in the spec, I suspect other tools probably also rely on this value being a number.

Closing as won't fix as both DITA and OASIS Table Exchange Model specs are pretty clear in this, that it must be an integer. Since only strict processing treats this as a fatal error, it's only an inconvenience, not a show stopper.

There is a situation in which the "ValidationFilter.validateCols" validation MUST not report a problem:

        <title>abcdef</title>
        <tgroup cols="-dita-use-conref-target" conref="#introduction/tgroup_sh4_g1d_tq">

                <row>
                    <entry/>
                </row>

        </tgroup>

In this case the validation should allow the "-dita-use-conref-target" value set on the @cols attribute.

The processing-mode is LAX by default, right?

Per the DITA 1.2 spec, -dita-use-conref-target is not explicitly allowed in @cols. @robander, the spec says:

The value -dita-use-conref-target is available on enumerated attributes and may also be specified on other attributes.

What's the intent here? Is it implicitly allowed in @cols?

If "-dita-use-conref-target" would not be an allowed value in @cols it would be impossible to state that the tgroup takes the number of columns from the conref target element because it needs to specify a value for @cols in order to be valid according to the schema.
I think this is the main reason that attributes which were intended to have numeric values are still specified in the specification as being NMTOKEN, to allow for this particular attribute value.

Hmm, interesting questions.
@cols was defined with NMTOKEN long before we had the token -dita-use-conref-target, so I don't think that was connected.
I do think that the DITA TC thought "oh, this can go anywhere", implicitly allowing it anywhere, but I don't remember any discussion of using it on attributes that explicitly would not allow such a value (such as @cols here, or the date fields in metadata). It was explicitly not limited to #REQUIRED attributes, because a specialization could make any attribute required. Probably should send a note to the TC to discuss.
Final comment: while legal, I think it would be very unusual to actually use @conref on a <tgroup> element...

The only reason I can think of to use conref on tgroup would be where the table content was invariant but the table title was different, but that seems like a vanishingly rare edge case.

Agreed - very low use case, and I suspect that many editors would not be able to handle it, given that many editors rely on common, DITA-unaware (sometimes very old) code to handle CALS tables. But the question is still an interesting one, and applies to any other attributes that we're validating against the standard (as opposed to validating against the schema).

@robander @drmacro if you can get back to this question, whether -dita-use-conref-target is implicitly allowed on any attribute (even @id) and this issues can be used to correct the implementation if needed.

Sending a note to the TC. The answer cannot be "any attribute" - because some are restricted in the schema enough that this value is not allowed. For example, @id on <topic> is defined as ID type in the grammar files, so that is not legal, and DITA can't explicitly break basic XML parsing rules. So I think the question is whether we implicitly allow this on any attribute (where the token itself is legal according to the schema).

Sent: https://lists.oasis-open.org/archives/dita/201501/msg00046.html

Discussed at OASIS TC today - determined that -dita-use-conref-target is implicitly allowed anywhere that it is not forbidden by the grammar files. We could also explicitly disallow it somewhere in the spec, but that is not done for any attribute today, so the result is that it's legal unless forbidden by the DTD/XSD/RNG.


Support Typescript highlighting

Hi burodepeper,  I can't live without your awesome package!
Could you please add support for typescript highlighting when you have time ?
Thank you!

Hey @joeaniu, thanks for the compliment! What package do you use for Typescript highlighting? Shouldn't be an issue adding that to the next release.

I am using markdown-preview-enhanced 0.15.6 and language-markdown 0.26.0 as attached image show.

@joeaniu He means the package for TypeScript highlighting. Are you using the base language-typescript package?

@kylebarron yes, I am using language-typescript 0.3.3


That is a bad idea to use Redis SCAN command, it works not like you expects...

Example:
My Redis Instance is also used as cache storage there are 260k keys right now. Cached keys have a big TTL, so they are always there.
Your "addRecord" method always writes a new key to the end of the keys list. (With much lower TTL)
Your "getRecord" method uses a SCAN command with "COUNT" property.
By default "COUNT" property is set to 1000 (by you).
Probably you expect that COUNT property is used to limit the number of rows returned by SCAN command...
But actually, COUNT property limits the number of keys to check with MATCH pattern, by default it will scan only the first 1000 keys stored in Redis.
So it never gets to the rows written by "addRecord" method in my case.
Extending of count property value to something like "300000" is not an option, because it will impact SCAN performance.
I would highly recommend you to replace the SCAN command with something else.
Also, I would highly recommend avoiding the usage of this package until this issue is fixed.
In my case, the throttler was not working on the production environment for a loooong time, until I found this issue.

Here is fast proof:
I have 6 keys in DB
localhost:6379> KEYS *
1) "kt-apiv2-develop:develop-240446:graphql_schema_shop"
2) "kt-apiv2-test:test-240258:variants-expired-start-date"
3) "kt-apiv2-develop:develop-240446:variants-expired-start-date"
4) "kt-apiv2-test:test-240258:graphql_schema_admin"
5) "kt-apiv2-develop:develop-240446:graphql_schema_admin"
6) "kt-apiv2-test:test-240258:graphql_schema_shop"

Pattern "kt-apiv2-test:test-240258:*" matches with 3 keys, (2, 4, and 6).
Let`s use a scan command with COUNT "2"
localhost:6379> scan 0 MATCH "kt-apiv2-test:test-240258:*" COUNT 2
1) "12"
2) 1) "kt-apiv2-test:test-240258:variants-expired-start-date"

As you can see the result have only 1 row.
because in this case scan processed only the first 2 keys ("kt-apiv2-develop:develop-240446:graphql_schema_shop"
and "kt-apiv2-test:test-240258:variants-expired-start-date")
Let`s increase the COUNT property to 4
localhost:6379> scan 0 MATCH "kt-apiv2-test:test-240258:*" COUNT 4
1) "14"
2) 1) "kt-apiv2-test:test-240258:variants-expired-start-date"
   2) "kt-apiv2-test:test-240258:graphql_schema_admin"

Now we see 2 rows returned. because only 4 first rows were processed.
The third key is still not returned.

@kkoomen Please review, my Pull Request which will replace usage of the SCAN command with sets:
https://github.com/kkoomen/nestjs-throttler-storage-redis/pull/1041

@Zizitto Hi. Let me start off by answering some of your questions and then discuss further on your suggestions:

Probably you expect that COUNT property is used to limit the number of rows returned by SCAN command...
But actually, COUNT property limits the number of keys to check with MATCH pattern, by default it will scan only the >first 1000 keys stored in Redis.
So it never gets to the rows written by "addRecord" method in my case.

When implementing this, I was aware of this. I added the option to adjust the SCAN limit, because it may vary for applications. I've worked with applications where 1000 is by far enough. I got a feature request once to support 100k or more, so I allowed people to adjust this value. Nonetheless, I am aware that this might raise performance issues.
However, I haven't used Redis clusters and personally don't need it. If people want support for this, then people can do a PR and test it with their own database. I know clusters are a headache so it does require some thorough testing as well.
Your database would be a good test subject, so if you are willing to support this plugin with your PR, I highly appreciate that, because having support for clusters is a nice milestone I'd say.
FYI: I did implement a possible implementation for redis instances as well as clusters in #1038, please have a look at that and let me know, because it might be useful to have a custom class for cluster configuration, but if that isn't needed (like in your PR #1041) then I do prefer that version of course.
Unfortunately, my knowledge about clusters isn't sufficient in order to judge what code could potentially work, so I might learn towards your suggestion if you've tested thoroughly and are confident about your solution. If we all agree on a certain implementation, it is required to write proper tests for this in some kind of way.

Hi @kkoomen.
About your changes at https://github.com/kkoomen/nestjs-throttler-storage-redis/pull/1038:
Looks like you have changed "addRecord" method arguments, that is a breaking change (at least for me).
I will not able to use this storage with the plugin i`m using now.
Your changes for clusters are useless for me because it will be much more profitable to fix the core issue - performance. SCAN command is still used as I see, you wrapped it with a "while" loop, so now the performance of "addRecord" method is, even more, dependent on the number of keys stored in your DB.
The performance of sets will be much better.
I`ve already tested my implementation with Docker Redis and GCP Redis Memorystore.
FYI: My PR also has a breaking change, I've removed a "scanCount" property from the constructor, this will trigger an exception for people who will still pass this argument to the constructor after upgrading to the new version. Please note that...
I`ve cleaned a few code-style issues. Please review my PR one more time.

Hi @kkoomen.
About your changes at #1038: Looks like you have changed "addRecord" method arguments, that is a breaking change (at least for me). I will not able to use this storage with the plugin i`m using now.
Your changes for clusters are useless for me because it will be much more profitable to fix the core issue - performance. SCAN command is still used as I see, you wrapped it with a "while" loop, so now the performance of "addRecord" method is, even more, dependent on the number of keys stored in your DB.
The performance of sets will be much better. I`ve already tested my implementation with Docker Redis and GCP Redis Memorystore.

You're right. Thanks for clarifying.

FYI: My PR also has a breaking change, I've removed a "scanCount" property from the constructor, this will trigger an exception for people who will still pass this argument to the constructor after upgrading to the new version. Please note that...

That's not a problem, because the next version bump will be a minor version number. I think it even will be a major version bump, according to the official versioning standards, so people can always not use the latest version.

Resolved by #1041


Request for a new section about APIs

Hi!
I'd like to add a section for APIs, but I'm not sure where to add this section. This is my suggestion:

Advanced Topics:

API:

Guidlines and Best Practices
Bla Bla
.
.

What is your opinion?
Best Regards
Reganto

That's awesome. That section is def needed for sure. Thanks. Much appreciate that. Feel free to add that section btw. :))


Support mutable existential parameters.

Fixes #3818.
This change implements the necessary logic in existential type handling to support mutable existential parameters.
Up-casting to base interface type is not an l-value
The first change is to make an up-cast from a concrete type to a base interface type an R-Value operation, which means the result of the up-cast is always a non-left-value. Consider the following case:
float Run(inout IOperation op, float val)
{
    ...
}

struct TOperationMax : IOperation { ... }

void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
{
    TOperationMax opMax;
    float result = Run(opMax, val); // not valid!
}

The call to Run should not be valid, because by definition, Run can return a value of different type through op argument, and in that case the new value won't fit in the opMax variable anymore.
Instead, the user must wrap things into an existential value, and then call the Run function:
void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
{
    TOperationMax opMax;
    IOperation op = opMax; // box opMax into op.
    float result = Run(op, val); // OK! op can be of different type after the call.
}

Don't open an existential argument if it is passed to a mutable interface typed parameter.
We have logic to "open" an existential value when using it to call a function that  takes an interface typed parameter, so that the function is called with a concrete typed argument that can be picked up by the specialization pass. The "opened" existential value is considered a sub type of the interface type so the call is still valid. However since opening an existential yields a r-value, we can't pass it to a mutable parameter location. Therefore, we have logic inplace to check that if the parameter is out, we don't want to open it. The same should apply if the parameter is inout, but we are missing that case we need to add the case there.
Correctly lowering ExtractEixstentialType to AnyValueType.
Currently we lower ExtractExistentialType inst to a tuple extract, which works if the type is used as a value. If the type is used as a type of some other inst, it should be lowered into AnyValueType instead.
Fix lowerWitnessLookup pass
The lowerWitnessLookup pass replaces the this argument in all calls to the witness lookup result to the existential value object. This is incorrect if some of the calls mutates the this parameter. Instead we need to reconstruct the existential value for this for each call independently, using only the initial existential object's type info.

It looks like there is a similar issue when the interface uses "__generic".
Here is an example,
//TEST(compute):COMPARE_COMPUTE(filecheck-buffer=CHECK):-shaderobj -output-using-type

__generic<T:__BuiltinFloatingPointType>
interface IOperation
{
    [mutating]
    void Store(float v);

    float Load();
};

__generic<T:__BuiltinFloatingPointType>
struct TOperationMax : IOperation<T>
{
    float result;

    [mutating]
    void Store(float v)
    {
        result = v;
    }

    float Load()
    {
        return result;
    }
};

__generic<T:__BuiltinFloatingPointType>
float Run(inout IOperation<T> op, float val)
{
    op.Store(val);
    return op.Load();
}

//TEST_INPUT:ubuffer(data=[0 0 0 0], stride=4):out,name outputBuffer
RWStructuredBuffer<float> outputBuffer;

[numthreads(4, 1, 1)]
[shader("compute")]
void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
{
    TOperationMax<float> opMax;
    opMax.result = 0.f;
    float val = 2.f;
    IOperation<float> op = opMax;
    float result = Run<float>(op, val);
    // CHECK: 2.0
    outputBuffer[0] = result;
}

And when tried, the compile error message looks like following,
core(231): error 50100: No type conformances are found for interface 'IDifferentiable'. Code generation for current target requires at least one implementation type present in the linkage.
core(130): error 50100: No type conformances are found for interface 'IFloat'. Code generation for current target requires at least one implementation type present in the linkage.
core(327): error 50100: No type conformances are found for interface '__BuiltinFloatingPointType'. Code generation for current target requires at least one implementation type present in the linkage.

It sounds like capability related problem but I am not sure.


Issue on the new ulimit feature of the run command 1.6 RC4

This is minor and probably won't be caught for some time but...
See code command snippet
vagrant@ubuntu-1:~$ docker -v
Docker version 1.6.0-rc4, build e2e39fc
vagrant@ubuntu-1:~$ cid=$(docker run -itd --ulimit data=8192 ubuntu)
vagrant@ubuntu-1:~$ docker logs $cid
bash: xmalloc: .././locale.c:81: cannot allocate 2 bytes (0 bytes allocated)

ping @cpuguy83
On Mon, Apr 6, 2015 at 5:54 PM, John Willis<EMAIL_ADDRESS>wrote:

This is minor and probably won't be caught for some time but...
See code command snippet
vagrant@ubuntu-1:~$ docker -v
Docker version 1.6.0-rc4, build e2e39fc
vagrant@ubuntu-1:~$ cid=$(docker run -itd --ulimit data=8192 ubuntu)
vagrant@ubuntu-1:~$ docker logs $cid
bash: xmalloc: .././locale.c:81: cannot allocate 2 bytes (0 bytes allocated)
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/12116.

I have a feeling this is due to the way the process in the container is started up.
If you up the ulimit value (ie, 819200) it works just fine.
We've also disbaled as from ulimit entirely because it causes a segv.

This probably just requires some additional documentation.

cool \o/ what i like to hear haha

Don't want to be a pest.. and like I said it's a minor issue.. however;  on the other ulimit (kbytes ) based values it looks like we default to zero or unlimited if the number calculates to low.  For example:
--ulimit memlock=8190.
I agree that we should just update the doc for this release but eventually I think we should resolve the issue.  Some user is going to set it and not understand why the instance failed... my 2 cents...

Definitely not a pest :)
What's really happening is we are taking the user's value and doing the syscall to set that exact value, we aren't ever changing what the user has provided.
The issue is what is the actual minimum? It changes with each new commit since docker itself is execing these processes in the container, so there needs to be enough to be able to fire up a docker binary, basically.
Maybe there's some sort of runtime magic that we can do to say "hey, the value you entered isn't going to work"?

Ya or just explaining that.
On Mon, Apr 6, 2015 at 8:02 PM, Brian Goff<EMAIL_ADDRESS>wrote:

Definitely not a pest :)
What's really happening is we are taking the user's value and doing the
syscall to set that exact value, we aren't ever changing what the user has
provided.
The issue is what is the actual minimum? It changes with each new commit
since docker itself is execing these processes in the container, so there
needs to be enough to be able to fire up a docker binary, basically.
Maybe there's some sort of runtime magic that we can do to say "hey, the
value you entered isn't going to work"?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/issues/12116#issuecomment-90224717.

Totally makes sense...   I'll try and update the doc in the next few days.

I labeled this with "writing", unless there are still plans to solve this in code, not sure if "proficient" applied here, but a proper understanding of the matter is required :smiley:
Marked this as "claimed" for you, @botchagalupe (thanks!)

can we get this in before thursday por favor

Is this fixed? if not please update the milestone

Don't know if it's fixed yet. Moved the milestone for now
@botchagalupe are you / have you been working on this?

do you mind to review #13558?


Size of minimap isn't correct after reload the (save-)game

Hi,
there seems to be a bug in the minimap size implementation.
After reloading a game (continue or loading a savegame) the size of the minimap is wrong.
The cqui settings shows the correct value (f.e. 400), but the minimap size is different (f.e. 512 instead of 400).
Changing the size to a different value and back again - Civ will use the correct size for the map until I reload the game/savegame.
First 	assumption was that its a problem with the in-game-implementation, so I have changed the value in the CQUI_Settings.sql too -> same problem.
Version: Civ VI <IP_ADDRESS>
Regards,
Jens

I've got a fix ready on my local repo that I'll be pushing out later today. Thanks for the report 👍


service: Add flag for stopped services

We should add a flag that will prevent the service from being stopped twice.
#Why
Currently, all our Stop calls depends on fx.Lifecycle which guarantees it will be called once. Receiving of BEFP also cause service stopping. The second Stop call can either crash or freeze the node.

As discussed with @Wondertan and @renaynay we should properly design such service and after that start implementation. We agreed that stopping flag  is not enough for a separate service and it should include more features.

Currently, all our Stop calls depends on fx.Lifecycle which guarantees it will be called once. Receiving of BEFP also cause service stopping. The second Stop call can either crash or freeze the node.

This was fixed by https://github.com/celestiaorg/celestia-node/pull/2091, so closing


rbx_cookie does not consider WSL as a windows operating system

Describe the bug
If the user is running inside WSL it should still grab the cookie from wincred for the running studio instance.
Expected behavior
I was trying to debug an issue as to why another programmer couldn't get their cookie, until I realised they're running inside WSL. When rbx_cookie is compiled for linux it will return None, which is not helpful inside WSL. It should return the cookie for the running studio instnace.
To Reproduce

Open an instance of roblox studio and log in
Run rbx_cookie::get() from WSL

Hey, thanks for raising this. I'm not sure how I could solve this directly since the Linux binary cannot access windows APIs.
From a quick Google search it looks like you could run the windows exe from within your WSL environment and it would work: https://stackoverflow.com/a/69619400
You could install rbx_cookie in your windows file system then add that file to your WSL path to execute it. It looks like the binary would need to explicitly have the .exe extension though.

I reported this issue on behalf of the other programmer on our team.
cc @sanrom - see above.


Cml regen new module format

CML regen with new module format
also includes direct use of crypto types through cddl-codegen's
integration with RawBytesEncoding (https://github.com/dcSpark/cddl-codegen/pull/148)
address.rs was manually updated. other files had to have their imports
manually fixed as everything is in a different location vs how CML
outputs things for single-crate output.
includes updates to the spec for style changes + instructions for
generation

@SebastienGllmt do we want to handle any of the following in this PR or in separate ones after? (leaving cip36 not compiling in the meantime):

implement the hand-written structs (plutus const data, bigint, bounded bytes)
Update CIP36 (since it pulled in some stuff via ChainCrypto and could also benefit from this raw bytes encoding stuff + separate all the hand-written stuff into a utils.rs like with cip25/the rest of CML now)

If not, I can change those incorrect crypto sizes and mark it as ready for review.

I have no issue with having it a separate PR


Config changes to reflect the default branch from master to main. Please merge to complete the default branch renaming job.

Auto branch renaming content.

Docs Build status updates of commit bd6f878:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-GitBranchDeletedOrForcePushed] Cannot sync git repo to specified commit because branch 15a5a80e-d632-405c-a126-1076525824ad has been deleted or has been force pushed

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


feat: add initialization task

Signed-off-by: ThibaultFy<EMAIL_ADDRESS>Summary
This PR adds an initialisation task to each strategy in SubstraFL. This allows to load the Algo and its model to the platform before any training, and allow to perform a testing task before any training.
This init task consist in submitting a empty function, coded in the BaseAlgo.
@remote
def initialize(self, shared_states):
     return

The init task return a local output that'll go to a test task, and to the first train task.
An other change in this PR is that test tasks don't take a shared as input anymore. This was needed before generic task but not anymore.
The graph pass from:
flowchart LR
    TrainTask1_round0--Local-->TestTask1_r0
    TrainTask1_round0--Shared-->TestTask1_r0

	TrainTask2_round0--Shared-->AggregateTask
    TrainTask2_round0--Local-->TestTask2_r0
    TrainTask2_round0--Shared-->TestTask2_r0

    AggregateTask--Shared-->TrainTask1_r1
    TrainTask1_round0--Local-->TrainTask1_r1

    AggregateTask--Shared-->TrainTask2_r1
    TrainTask2_round0--Local-->TrainTask2_r1
    TrainTask1_round0--Shared-->AggregateTask

    TrainTask1_r1--Local-->TestTask1_r1
    TrainTask1_r1--Shared-->TestTask1_r1

    TrainTask2_r1--Local-->TestTask2_r1
    TrainTask2_r1--Shared-->TestTask2_r1

to:
flowchart LR
    InitTask1_round0--Local-->TestTask1_r0
    InitTask2_round0--Local-->TestTask2_r0

    InitTask1_round0--Local-->TrainTask1_r1
    InitTask2_round0--Local-->TrainTask2_r1

    TrainTask2_r1--Shared-->AggregateTask
    TrainTask1_r1--Shared-->AggregateTask
    TrainTask1_r1--Local-->TestTask1_r1
    TrainTask2_r1--Local-->TestTask2_r1

    TrainTask1_r1--Local-->TrainTask1_r2
    TrainTask2_r1--Local-->TrainTask2_r2
    AggregateTask--Shared-->TrainTask1_r2
    AggregateTask--Shared-->TrainTask2_r2

    TrainTask1_r2--Local-->TestTask1_r2
    TrainTask2_r2--Local-->TestTask2_r2

Please check if the PR fulfills these requirements

[ ] If the feature has an impact on the user experience, the changelog has been updated
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ] The commit message follows the conventional commit specification

/e2e --tests=substrafl --mode=standalone --benchmarks=camelyon

/e2e --tests=substrafl --mode=standalone --benchmarks=camelyon

/e2e --tests=substrafl --mode=standalone --benchmarks=camelyon

End to end tests: :hourglass_flowing_sand: STARTING

/e2e --tests=substrafl --mode=standalone --benchmarks=camelyon

End to end tests: :hourglass_flowing_sand: STARTING

/e2e --tests=substrafl --mode=standalone --benchmarks=camelyon

End to end tests: :hourglass_flowing_sand: STARTING


feat: add x64 simd for sparse vector operations

We need to sync https://github.com/rust-lang/stdarch/commit/e50b2f6fa7f8a9a0081c88b1793d8560462d5848 to https://github.com/tensorchord/stdarch

@VoVAllen

done

And I think we can remove native vp2intersect since it's slower according to https://arxiv.org/abs/2112.06342

And I think we can remove native vp2intersect since it's slower according to https://arxiv.org/abs/2112.06342

Actually the paper says that if we only get one output mask, it's slower. But in our occasion, it needs two masks. https://ar5iv.labs.arxiv.org/html/2112.06342#:~:text=When used to,first output mask

The gap looks small. Prefer to remove the native vp2intersect for simplicity

Prefer to remove the native vp2intersect for simplicity.

done

Tests failed after being merged.

thread 'vector::veci8::tests_2::test_cos_i8' panicked at crates/base/src/vector/veci8.rs:552:9:
assertion failed: (result.0 - result_expected).abs() / result_expected < 0.25
stack backtrace:
   0: rust_begin_unwind
             at /rustc/516b6162a2ea8e66678c09e8243ebd83e4b8eeea/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/516b6162a2ea8e66678c09e8243ebd83e4b8eeea/library/core/src/panicking.rs:72:14
   2: core::panicking::panic
             at /rustc/516b6162a2ea8e66678c09e8243ebd83e4b8eeea/library/core/src/panicking.rs:144:5
   3: base::vector::veci8::tests_2::test_cos_i8
             at ./src/vector/veci8.rs:552:9
   4: base::vector::veci8::tests_2::test_cos_i8::{{closure}}
             at ./src/vector/veci8.rs:531:21
   5: core::ops::function::FnOnce::call_once
             at /rustc/516b6162a2ea8e66678c09e8243ebd83e4b8eeea/library/core/src/ops/function.rs:250:5
   6: core::ops::function::FnOnce::call_once
             at /rustc/516b6162a2ea8e66678c09e8243ebd83e4b8eeea/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
test vector::veci8::tests_2::test_cos_i8 ... FAILED

It seems related to veci8. cc @my-vegetable-has-exploded

This test fails with a probability and I thought it's just because the value was too strict so I relaxed the constant 0.01 to 0.25. But it seems not helpful...

I tried to run this test for many times.
I think that it may fails when the cosine result is small.
Do you think it is good idea to change it to codes below? @usamoi @silver-ymz
            assert!((result.0 - result_expected).abs() / result_expected < 0.25 || (result.0 - result_expected).abs() < 0.001);

@my-vegetable-has-exploded Yes. It's good.


[Coverity CID :195828]Memory - corruptions in /boards/posix/native_posix/cmdline.c

Static code scan issues seen in File: /boards/posix/native_posix/cmdline.c
Category: Memory - corruptions
Function: native_add_command_line_opts
Component: Other
CID: 195828
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

@aasthagr : What is the line number? (I cannot see the coverity report)

False positive, awaiting permission in Coverity to mark it as so.


Update service_manual.html.erb

Updated content in line with new metrics pages.
Please can you add links to the new pages (once they exist) to the metrics set out in bullet points under heading 'The KPIs'.

Thanks @luciawhittaker. I will add the links in a separate PR.


feat: show unpublished and source doc changes

Fix #170

:tada: This PR is included in version 3.26.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Update cortex-m-rt version in examples to 0.7.3

Summary
Bumps the cortex-m-rt versions in the lockfiles in the examples to 0.7.3.
Due to the discovery in https://github.com/rust-embedded/cortex-m/discussions/469, it is not advisable to be using 0.7.1 or 0.7.2 of cortex-m-rt anymore.

Also, would it be a good idea to also explicitly use the 0.7.3 version of cortex-m in all PACs? Or is that responsibility better placed in the hands of the users of this crate?

No, I wouldn't bet on that. It's better to explicitly set the minimum.
I'll try to address this this week, unless someone else throws PR. It would require a PACs release.

@markhakansson the general problem is now addressed in new PACs that are subject to release. But I'd like this change in examples as well. Could you, please, update the CHANGELOG.md appropriately for CI to pass? I can't push to a branch on your fork w/o your explicit permission (which I believe is GH flaw, as maintainer of the target repo I should be allowed to push fixes to PRs before merging).

Could you, please, update the CHANGELOG.md appropriately for CI to pass?

Sure thing! I'll fix it right away.

I can't push to a branch on your fork w/o your explicit permission (which I believe is GH flaw, as maintainer of the target repo I should be allowed to push fixes to PRs before merging).

Interesting, as long as  Allow edits by maintainers is enabled (as it is here) on the PR I would assume that it should work.

@michalfita I rebased and added the changelog entry now.

Interesting, as long as Allow edits by maintainers is enabled (as it is here) on the PR I would assume that it should work.

To be honest I haven't tried with this one in particular, but my experience shows that's mostly the case. It rings a bell such option exists, but I think most people doesn't enable it.
Thanks for the effort anyway.


GoogleDepsWriter NullPointerException

BUILD# 1086
Looking at the GoogleDepsWriter class, line 100 is calling visited.clear();
However, the visited variable is not created until line 248.  Not certain if this is the problem, but seems plausible.
Internal error: java.lang.NullPointerException org.apache.royale.compiler.internal.graph.GoogDepsWriter.getListOfFiles(GoogDepsWriter.java:100)org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyalePublisher.publish(MXMLRoyalePublisher.java:376)org.apache.royale.compiler.clients.MXMLJSCRoyale.compile(MXMLJSCRoyale.java:384)org.apache.royale.compiler.clients.MXMLJSCRoyale._mainNoExit(MXMLJSCRoyale.java:240)org.apache.royale.compiler.clients.MXMLJSCRoyale.mainNoExit(MXMLJSCRoyale.java:197)org.apache.royale.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:345)org.apache.royale.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:281)org.apache.royale.compiler.clients.MXMLJSC.staticMainNoExit(MXMLJSC.java:240)org.apache.royale.compiler.clients.MXMLJSC.main(MXMLJSC.java:222)
64.68937496 seconds
Build halted with errors.

Line 248 is a class initializer so visited should be created at instantiation and before any APIs are called.  What are the options being passed to the compiler and what is the entire console output leading up to the exception?

Ahh, you're correct.  Makes sense.  I found I'm getting a "No GoogDep" right before the error.  This happens with -remove-circulars set to true which is default.  If I set it to false, it builds without errors.
Output-RemoveCircularsError.txt

I can't explain why it is saying line #100 is at fault.  What version of Royale are you using?
But anyway, the NPE is because we don't catch errors when a dependency can't be found, in this case createjs.EventDispatcher.  It looks like you have your own CreateJS.swc, Should it have a createjs.EventDispatcher?  Looks like a SoundManager class is dependent on it.

I'm using build #1086 from Jenkins
http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/1086/
I am indeed using my own CreateJS.swc.  I'll have a look at my SoundManager class and see if I can find anything.  Thanks for looking into this.

I corrected the issue in my code, but this may be a problem overall.  I found instantiating a new class instance from a class in a SWC on a static variable was causing the issue.  So, I moved the instance creation inside a method to correct the error.  The CreateJS.swc I created is an as3 api only and doesn't include javascript in the swc, so perhaps that's the reason?
Below is what caused my error.
private static var _dispatchObject:EventDispatcher = new EventDispatcher();

I altered one of the examples to add that line of code and it compiled without errors.
GoogDepsWriter is going around looking for JS files for classes required by other JS files.  EventDispatcher (if it is org.apache.royale.events.EventDispatcher) should be in Core.swc, but if you referenced some other EventDispatcher and it was in your CreateJS.swc and there was no JS file for it, it could cause a problem in GoogDepsWriter, but I'm not sure it should have made a difference if you created the EventDispacher in the static initializer or not.  Referencing a class in a static initializer does affect GoogDepsWriter.  It will give priority when removing circulars to classes referenced in static initializers, but at some other point, it should have gone looking for EventDispatcher and successfully find it in Core.swc, or fail to find its JS file.

Sorry, I wasn't clear earlier.  I used createjs.EventDispatcher.  My CreateJS.swc is just a skeleton of classes and it's used as an external-library.  So, the compiler should not try to include and classes in the built output.  The CreateJS.swc works just fine except in the instance below.  I attached my swc for reference.
CreateJS.zip
private static var _dispatchObject:EventDispatcher = new createjs.EventDispatcher();

Ah, ok.  I think then that the issue may be that we weren't checking if classes used in static initializers were external or not.  I just pushed a change for that.  If the nightly builds pass you can get a newer compiler that way or grab a nightly build of the compiler and replace the jars.

Awesome!  Thanks @aharui !  I'll check it out once the build passes.

That fixed it!  Great work @aharui

Is StaticClass in your source path, or some external dependency?

@aharui StaticClass is indeed in my source path.  I'm seeing the issue with other projects where the error states that the method is not a constructor.  So, basically anywhere a class is instantiated on a static variable.

@aharui Do you think this can get fixed before the next release?  This breaks all of SpriteFlexjs unfortunately.  This would prevent me from pushing a new update to SpriteFlexjs until this is corrected.

Oh yeah, I knew I was forgetting something.  I will look into it now.

AFAICT, this error wasn't cause by the above commit.  It just allowed you to get further to the point where you would run into this issue.  I'm surprised we didn't hit this sooner.  The main class's dependencies were not being added to the addDependency list.  The only reason it worked is because those same dependencies were referenced elsewhere in the code other than the static dependency list.  I am testing a fix now.

@kennylerma don't worry about to reach this release, we have still many things to do. My advice is to get your development environment running with the actual repo code so you can work in SpriteFlexJS and prepare a PR. For that you need to prepare the library and setup maven for the project. We'll help you when you reach that point ;).

@carlosrovira yeah I mainly want to be able to generate some videos using Royale and SpriteFlexjs and I would like to direct people to the latest royale release and have it work correctly.  So, that's the main reason, but it looks like @aharui may have resolved it already.  I'll start looking at what is needed to add Spriteflexjs into Royale very soon.

Hi Kenny that's great. In case you find something is not in a released SDK you can always point the users that "the feature will shio in forthcoming SDK x.x.x", that's the strategy I took for Jewel that is still unreleased in an official SDK version. In the other hand, we decided to release as often as possible, and more reasons is if you bring some new functionality like spriteflexjs to the plate. I think we should not be too late in release a other version with that. thanks.