Guide :: Update Headline

Per Sprint 4 demo, thought is to tweak headline guide copy to intro what a design studio is.
Per Chuck, suggested updated headline is:
Design studios help you get a whole week's work done in a day.

Reassigned to @sshaar08 per standup. If we need Tony to jump on this let me know.
Please share with @Misokate for design to see if it needs to break to two lines

pushed


[question] unknown device Aeotec Indoor Siren 6

Hi,
Since my Zwave2Mqtt was updated to 2.0.4, my Aeotec Indoor Siren 6 (ZW164) is not recognized anymore. The product is shown as "Unknown: type=0003, id=00a4 (Aeotec Limited)". I re-included the device without any results. The device is alive but can't be configured.
I know there are some known issues with the indoor siren but is there something wrong with my installation of did you exclude the product? Thx
Raspberry pi3b, Raspbian Buster, docker >> Hass.io & Zwave2Mqtt

@jerepeer Are you using docker?

Yes, I am.
com.docker.compose.version | 1.24.1

Try to send “refreshNodeInfo” command to the wrong discovered nodes. It has been added as command some commits ago if you don’t find it you can send it with mqtt apis
Daniel

On 28 Oct 2019, at 21:15, jerepeer<EMAIL_ADDRESS>wrote:

Yes, I am.
com.docker.compose.version | 1.24.1
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Sorry, no custom build here. Do you have a nightly build with the refreshNodeInfo command?
No experience with calling a Zwave API (JSON object). Even my fellow zwave2mqtt friends don't know ;)

I will release 2.0.5 version soon
Daniel

On 30 Oct 2019, at 10:05, jerepeer<EMAIL_ADDRESS>wrote:

Sorry, no custom build here. Do you have a nightly build with the refreshNodeInfo command?
No experience with calling a Zwave API (JSON object). Even my fellow zwave2mqtt friends don't know ;)
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Great! I'll wait for the release and let you know if it worked !

Got the update, thnx! Ran the refreshNodeInfo command but still no luck..... "Unknown: type=0003, id=00a4 (Aeotec Limited)"
Here's the log..
OpenZWave Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x3b, 0x00, 0x00, 0x0f, 0xdf
OpenZWave Detail, Node017, ZW_SEND_DATA Request with callback ID 0x3b received (expected 0x3b)
OpenZWave Info, Node017, Request RTT 149 Average Request RTT 148
OpenZWave Detail, Expected callbackId was received
OpenZWave Detail, Node017, Received: 0x01, 0x0b, 0x00, 0x04, 0x00, 0x11, 0x05, 0x8e, 0x03, 0x09, 0x05, 0x00, 0x65
OpenZWave Detail,
OpenZWave Info, Node017, Response RTT 227 Average Response RTT 226
OpenZWave Info, Node017, Received Multi Instance Association report from node 17, group 9
OpenZWave Info, Node017, The group contains:
OpenZWave Info, Node017, Querying associations for node 17 is complete.
OpenZWave Detail, Node017, Expected reply and command class was received
OpenZWave Detail, Node017, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Notification: Group
OpenZWave Detail, Node017, Query Stage Complete (Associations)
OpenZWave Detail, Node017, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Neighbors live=1
OpenZWave Detail, Node017, QueryStage_Neighbors
OpenZWave Detail, Requesting routing info (neighbor list) for Node 17
OpenZWave Detail, Node017, Queuing (Command) Get Routing Info (Node=17): 0x01, 0x07, 0x00, 0x80, 0x11, 0x00, 0x00, 0x03, 0x6a
OpenZWave Detail, Node017, Queuing (Query) Query Stage Complete (Neighbors)
OpenZWave Detail,
OpenZWave Info, Node017, Sending (Command) message (Callback ID=0x00, Expected Reply=0x80) - Get Routing Info (Node=17): 0x01, 0x07, 0x00, 0x80, 0x11, 0x00, 0x00, 0x03, 0x6a
OpenZWave Detail, Node017, Received: 0x01, 0x20, 0x01, 0x80, 0xcf, 0xf7, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x62
OpenZWave Detail,
OpenZWave Info, Node017, Received reply to FUNC_ID_ZW_GET_ROUTING_INFO
OpenZWave Info, Node017, Neighbors of this node are:
OpenZWave Info, Node017, Node 1
OpenZWave Info, Node017, Node 2
OpenZWave Info, Node017, Node 3
OpenZWave Info, Node017, Node 4
OpenZWave Info, Node017, Node 7
OpenZWave Info, Node017, Node 8
OpenZWave Info, Node017, Node 9
OpenZWave Info, Node017, Node 10
OpenZWave Info, Node017, Node 11
OpenZWave Info, Node017, Node 13
OpenZWave Info, Node017, Node 14
OpenZWave Info, Node017, Node 15
OpenZWave Info, Node017, Node 16
OpenZWave Info, Node017, Node 19
OpenZWave Detail, Node247, Expected reply was received
OpenZWave Detail, Node247, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Query Stage Complete (Neighbors)
OpenZWave Detail, Node017, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Session live=1
OpenZWave Detail, Node017, QueryStage_Session
OpenZWave Detail, Node017, Queuing (Query) PowerlevelCmd_Get (Node=17): 0x01, 0x09, 0x00, 0x13, 0x11, 0x02, 0x73, 0x02, 0x25, 0x3c, 0x9e
OpenZWave Detail, Node017, Queuing (Query) Query Stage Complete (Session)
OpenZWave Detail,
OpenZWave Info, Node017, Sending (Query) message (Callback ID=0x3c, Expected Reply=0x04) - PowerlevelCmd_Get (Node=17): 0x01, 0x09, 0x00, 0x13, 0x11, 0x02, 0x73, 0x02, 0x25, 0x3c, 0x9e
OpenZWave Detail, Node017, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node017, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x3c, 0x00, 0x00, 0x09, 0xde
OpenZWave Detail, Node017, ZW_SEND_DATA Request with callback ID 0x3c received (expected 0x3c)
OpenZWave Info, Node017, Request RTT 92 Average Request RTT 120
OpenZWave Detail, Expected callbackId was received
2019-10-31T18:58:26.280Z z2m:Zwave zwave node 17: changed: 115-1-0:Powerlevel:Normal -> Normal
2019-10-31T18:58:26.285Z z2m:Zwave zwave node 17: changed: 115-1-1:Timeout:0 -> 0
OpenZWave Detail, Node017, Received: 0x01, 0x0a, 0x00, 0x04, 0x00, 0x11, 0x04, 0x73, 0x03, 0x00, 0x00, 0x94
OpenZWave Detail,
OpenZWave Info, Node017, Response RTT 170 Average Response RTT 198
OpenZWave Info, Node017, Received a PowerLevel report: PowerLevel=Normal, Timeout=0
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=list
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Expected reply and command class was received
OpenZWave Detail, Node017, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Query Stage Complete (Session)
OpenZWave Detail, Node017, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Dynamic live=1
OpenZWave Detail, Node017, QueryStage_Dynamic
OpenZWave Detail, Node017, Queuing (Send) BasicCmd_Get (Node=17): 0x01, 0x09, 0x00, 0x13, 0x11, 0x02, 0x20, 0x02, 0x25, 0x3d, 0xcc
OpenZWave Detail, Node017, Queuing (Send) AlarmCmd_Get (Node=17): 0x01, 0x0c, 0x00, 0x13, 0x11, 0x05, 0x71, 0x04, 0x00, 0x07, 0x01, 0x25, 0x3e, 0x9c
OpenZWave Detail, Node017, Queuing (Send) AlarmCmd_Get (Node=17): 0x01, 0x0c, 0x00, 0x13, 0x11, 0x05, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x3f, 0x92
OpenZWave Detail, Node017, Queuing (Send) MultiChannel Encapsulated (instance=4): AlarmCmd_Get (Node=17): 0x01, 0x10, 0x00, 0x13, 0x11, 0x09, 0x60, 0x0d, 0x01, 0x03, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x40, 0x92
OpenZWave Detail, Node017, Queuing (Send) MultiChannel Encapsulated (instance=5): AlarmCmd_Get (Node=17): 0x01, 0x10, 0x00, 0x13, 0x11, 0x09, 0x60, 0x0d, 0x01, 0x04, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x41, 0x94
OpenZWave Detail, Node017, Queuing (Send) MultiChannel Encapsulated (instance=6): AlarmCmd_Get (Node=17): 0x01, 0x10, 0x00, 0x13, 0x11, 0x09, 0x60, 0x0d, 0x01, 0x05, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x42, 0x96
OpenZWave Detail, Node017, Queuing (Query) Query Stage Complete (Dynamic)
OpenZWave Detail,
OpenZWave Info, Node017, Sending (Send) message (Callback ID=0x3d, Expected Reply=0x04) - BasicCmd_Get (Node=17): 0x01, 0x09, 0x00, 0x13, 0x11, 0x02, 0x20, 0x02, 0x25, 0x3d, 0xcc
OpenZWave Detail, Node017, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node017, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x3d, 0x00, 0x00, 0x11, 0xc7
OpenZWave Detail, Node017, ZW_SEND_DATA Request with callback ID 0x3d received (expected 0x3d)
OpenZWave Info, Node017, Request RTT 168 Average Request RTT 144
OpenZWave Detail, Expected callbackId was received
OpenZWave Detail, Node017, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x11, 0x03, 0x20, 0x03, 0x00, 0xc3
OpenZWave Detail,
OpenZWave Info, Node017, Response RTT 246 Average Response RTT 222
2019-10-31T18:58:26.530Z z2m:Zwave zwave node 17: changed: 32-1-0:Basic:0 -> 0
OpenZWave Info, Node017, Received Basic report from node 17: level=0
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Expected reply and command class was received
OpenZWave Detail, Node017, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail,
OpenZWave Info, Node017, Sending (Send) message (Callback ID=0x3e, Expected Reply=0x04) - AlarmCmd_Get (Node=17): 0x01, 0x0c, 0x00, 0x13, 0x11, 0x05, 0x71, 0x04, 0x00, 0x07, 0x01, 0x25, 0x3e, 0x9c
OpenZWave Detail, Node017, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node017, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x3e, 0x00, 0x00, 0x0b, 0xde
OpenZWave Detail, Node017, ZW_SEND_DATA Request with callback ID 0x3e received (expected 0x3e)
OpenZWave Info, Node017, Request RTT 111 Average Request RTT 127
OpenZWave Detail, Expected callbackId was received
OpenZWave Detail, Node017, Received: 0x01, 0x0f, 0x00, 0x04, 0x00, 0x11, 0x09, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x07, 0xfe, 0x00, 0x9e
2019-10-31T18:58:26.721Z z2m:Zwave zwave node 17: changed: 113-1-0:Alarm Type:0 -> 0
2019-10-31T18:58:26.724Z z2m:Zwave zwave node 17: changed: 113-1-1:Alarm Level:0 -> 0
2019-10-31T18:58:26.729Z z2m:Zwave zwave node 17: changed: 113-1-2:SourceNodeId:0 -> 0
2019-10-31T18:58:26.733Z z2m:Zwave zwave node 17: changed: 113-1-10:Burglar:254 -> 254
OpenZWave Detail,
OpenZWave Info, Node017, Response RTT 189 Average Response RTT 205
OpenZWave Info, Node017, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Burglar event:254, status=255
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=254, new value=254, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Expected reply and command class was received
OpenZWave Detail, Node017, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail,
OpenZWave Info, Node017, Sending (Send) message (Callback ID=0x3f, Expected Reply=0x04) - AlarmCmd_Get (Node=17): 0x01, 0x0c, 0x00, 0x13, 0x11, 0x05, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x3f, 0x92
OpenZWave Detail, Node017, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node017, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x3f, 0x00, 0x00, 0x0b, 0xdf
OpenZWave Detail, Node017, ZW_SEND_DATA Request with callback ID 0x3f received (expected 0x3f)
OpenZWave Info, Node017, Request RTT 110 Average Request RTT 118
OpenZWave Detail, Expected callbackId was received
OpenZWave Detail, Node017, Received: 0x01, 0x0f, 0x00, 0x04, 0x00, 0x11, 0x09, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x08, 0xfe, 0x00, 0x91
OpenZWave Detail,
2019-10-31T18:58:26.926Z z2m:Zwave zwave node 17: changed: 113-1-0:Alarm Type:0 -> 0
2019-10-31T18:58:26.931Z z2m:Zwave zwave node 17: changed: 113-1-1:Alarm Level:0 -> 0
2019-10-31T18:58:26.937Z z2m:Zwave zwave node 17: changed: 113-1-2:SourceNodeId:0 -> 0
2019-10-31T18:58:26.944Z z2m:Zwave zwave node 17: changed: 113-1-11:Power Management:254 -> 254
OpenZWave Info, Node017, Response RTT 189 Average Response RTT 197
OpenZWave Info, Node017, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=254, new value=254, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Expected reply and command class was received
OpenZWave Detail, Node017, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail,
OpenZWave Info, Node017, Sending (Send) message (Callback ID=0x40, Expected Reply=0x04) - MultiChannel Encapsulated (instance=4): AlarmCmd_Get (Node=17): 0x01, 0x10, 0x00, 0x13, 0x11, 0x09, 0x60, 0x0d, 0x01, 0x03, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x40, 0x92
OpenZWave Detail, Node017, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node017, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x40, 0x00, 0x00, 0x0b, 0xa0
OpenZWave Detail, Node017, ZW_SEND_DATA Request with callback ID 0x40 received (expected 0x40)
OpenZWave Info, Node017, Request RTT 115 Average Request RTT 116
OpenZWave Detail, Expected callbackId was received
OpenZWave Detail, Node017, Received: 0x01, 0x13, 0x00, 0x04, 0x00, 0x11, 0x0d, 0x60, 0x0d, 0x03, 0x01, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x08, 0xfe, 0x00, 0xe6
OpenZWave Detail,
2019-10-31T18:58:27.122Z z2m:Zwave zwave node 17: changed: 113-4-0:Alarm Type:0 -> 0
2019-10-31T18:58:27.126Z z2m:Zwave zwave node 17: changed: 113-4-1:Alarm Level:0 -> 0
2019-10-31T18:58:27.130Z z2m:Zwave zwave node 17: changed: 113-4-2:SourceNodeId:0 -> 0
2019-10-31T18:58:27.134Z z2m:Zwave zwave node 17: changed: 113-4-11:Power Management:254 -> 254
OpenZWave Info, Node017, Response RTT 193 Average Response RTT 195
OpenZWave Info, Node017, Received a MultiChannelEncap from node 17, endpoint 3 for Command Class COMMAND_CLASS_ALARM
OpenZWave Info, Node017, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=254, new value=254, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Expected reply and command class was received
OpenZWave Detail, Node017, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail,
OpenZWave Info, Node017, Sending (Send) message (Callback ID=0x41, Expected Reply=0x04) - MultiChannel Encapsulated (instance=5): AlarmCmd_Get (Node=17): 0x01, 0x10, 0x00, 0x13, 0x11, 0x09, 0x60, 0x0d, 0x01, 0x04, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x41, 0x94
OpenZWave Detail, Node017, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node017, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x41, 0x00, 0x00, 0x0c, 0xa6
OpenZWave Detail, Node017, ZW_SEND_DATA Request with callback ID 0x41 received (expected 0x41)
OpenZWave Info, Node017, Request RTT 120 Average Request RTT 118
OpenZWave Detail, Expected callbackId was received
OpenZWave Detail, Node017, Received: 0x01, 0x13, 0x00, 0x04, 0x00, 0x11, 0x0d, 0x60, 0x0d, 0x04, 0x01, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x08, 0xfe, 0x00, 0xe1
OpenZWave Detail,
OpenZWave Info, Node017, Response RTT 198 Average Response RTT 196
OpenZWave Info, Node017, Received a MultiChannelEncap from node 17, endpoint 4 for Command Class COMMAND_CLASS_ALARM
2019-10-31T18:58:27.326Z z2m:Zwave zwave node 17: changed: 113-5-0:Alarm Type:0 -> 0
2019-10-31T18:58:27.329Z z2m:Zwave zwave node 17: changed: 113-5-1:Alarm Level:0 -> 0
2019-10-31T18:58:27.333Z z2m:Zwave zwave node 17: changed: 113-5-2:SourceNodeId:0 -> 0
2019-10-31T18:58:27.337Z z2m:Zwave zwave node 17: changed: 113-5-11:Power Management:254 -> 254
OpenZWave Info, Node017, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=254, new value=254, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Expected reply and command class was received
OpenZWave Detail, Node017, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail,
OpenZWave Info, Node017, Sending (Send) message (Callback ID=0x42, Expected Reply=0x04) - MultiChannel Encapsulated (instance=6): AlarmCmd_Get (Node=17): 0x01, 0x10, 0x00, 0x13, 0x11, 0x09, 0x60, 0x0d, 0x01, 0x05, 0x71, 0x04, 0x00, 0x08, 0x01, 0x25, 0x42, 0x96
OpenZWave Detail, Node017, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
OpenZWave Detail, Node017, ZW_SEND_DATA delivered to Z-Wave stack
OpenZWave Detail, Node017, Received: 0x01, 0x07, 0x00, 0x13, 0x42, 0x00, 0x00, 0x0b, 0xa2
OpenZWave Detail, Node017, ZW_SEND_DATA Request with callback ID 0x42 received (expected 0x42)
OpenZWave Info, Node017, Request RTT 117 Average Request RTT 117
OpenZWave Detail, Expected callbackId was received
OpenZWave Detail, Node017, Received: 0x01, 0x13, 0x00, 0x04, 0x00, 0x11, 0x0d, 0x60, 0x0d, 0x05, 0x01, 0x71, 0x05, 0x00, 0x00, 0x00, 0xff, 0x08, 0xfe, 0x00, 0xe0
2019-10-31T18:58:27.522Z z2m:Zwave zwave node 17: changed: 113-6-0:Alarm Type:0 -> 0
2019-10-31T18:58:27.526Z z2m:Zwave zwave node 17: changed: 113-6-1:Alarm Level:0 -> 0
2019-10-31T18:58:27.530Z z2m:Zwave zwave node 17: changed: 113-6-2:SourceNodeId:0 -> 0
2019-10-31T18:58:27.533Z z2m:Zwave zwave node 17: changed: 113-6-11:Power Management:254 -> 254
OpenZWave Detail,
OpenZWave Info, Node017, Response RTT 194 Average Response RTT 195
OpenZWave Info, Node017, Received a MultiChannelEncap from node 17, endpoint 5 for Command Class COMMAND_CLASS_ALARM
2019-10-31T18:58:27.582Z z2m:Zwave node 17 ready: Aeotec Limited - Unknown: type=0003, id=00a4 (Unknown)
OpenZWave Info, Node017, Received Alarm report: type=0, level=0, sensorSrcID=0, type:Power Management event:254, status=255
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=0, new value=0, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Refreshed Value: old value=254, new value=254, type=byte
OpenZWave Detail, Node017, Changes to this value are not verified
OpenZWave Detail, Node017, Expected reply and command class was received
OpenZWave Detail, Node017, Message transaction complete
OpenZWave Detail,
OpenZWave Detail, Node017, Removing current message
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Notification: ValueChanged
OpenZWave Detail, Node017, Query Stage Complete (Dynamic)
OpenZWave Detail, Node017, AdvanceQueries queryPending=0 queryRetries=0 queryStage=Configuration live=1
OpenZWave Detail, Node017, QueryStage_Configuration
OpenZWave Detail, Node017, QueryStage_Complete
OpenZWave Warning, CheckCompletedNodeQueries m_allNodesQueried=0 m_awakeNodesQueried=1
OpenZWave Warning, CheckCompletedNodeQueries all=0, deadFound=0 sleepingOnly=1
OpenZWave Detail, Node017, Notification: NodeQueriesComplete

Not that it helps but mines been discovered and working fine from 2.0.4, 2.05 and 2.0.6, although I have had issues  setting most of the chime/volume related values. When I've seen problems like yours before forgetting the item and re-adding it usually clears it up

Thanks for the input 917HuB. Tried to delete and add a new node but no luck.
I'll contact Aeotec. This is annoying. We have the same device (minus the doorbell)

@917huB have you had any luck setting the volume or chime in any way?  I was trying to figure out how to do so for a few hours and got absolutely nowhere.  I'd hoped maybe using ozwcp would allow it, but no luck there either.

These devices use a new command class called SoundSwitch. That’s only supported in OZW 1.6. So make sure your using that variant.

@enobrev Im using a build of 1.6 from a few weeks ago but setting volume or tone doesn't make any difference. I haven't had the time to debug in any detail yet to be able to provide any details though.

Thanks @Fishwaldo @917huB , I had been using 1.6.  I had tried the release as well as pulling from master and compiling, but was never able to adjust volume or chimes.  It's been a few weeks since I tried, so I don't remember what I was seeing in the logs, but the doorbell remains on a shelf until I can change the ridiculous default volume on this thing.
Sorry for hijacking this thread - I couldn't find a way to contact @917huB elsewhere.

So to sum up, can we setup the volume of the ZW162 correctly with the latest release?

I haven't had a chance to test.     I haven't returned it because I legitimately want the thing, I'm just waiting to hear if anyone has had success with it before I touch the box and wake the whole neighborhood.

Still wasn't working when I last tested, I'l grab latest and verify this weekend.
Like you I wanted a wifi doorbell so worked around the problem by mounting the siren in a box stuffed with rags, that attenuates the siren & doorbell volume to something bearable whilst the code geniuses figure out how to tame this thing.

I’m sorry for this but as it is not a problem caused by z2m I can’t really help with this, try to reopen the same issue on openzwave library and reference this issue for more information. Let me know if you fix this
Daniel

On 4 Jan 2020, at 00:43, 917huB<EMAIL_ADDRESS>wrote:

Still wasn't working when I last tested, I'l grab latest and verify this weekend.
Like you I wanted a wifi doorbell so worked around the problem by mounting the siren in a box stuffed with rags, that attenuates the siren & doorbell volume to something bearable whilst the code geniuses figure out how to tame this thing.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@robertsLando FYI ... it all works like a charm now with the latest release 2.2.0  including setting the volume.
Thx for the update !


Adds account alias pattern doc

@tfelix Please document this in terms of the dhall config model

I dont think we use/document our internal dhall config in the documentation. What do you mean exactly?


Map Centering problem

For some reason, when I open the map, it's pretty fail at finding my location and zooms out really far on load. It appears to be only happening for me (and maybe won't happen once I move to a different location), but it's something to look in to.

Oh, and I just hit the location find button after it loaded and got really big, and it actually worked perfectly. So it does know my location. It just doesn't know it early enough, maybe?

... And this time it worked just fine. So the bonus fun is that it only happens sometimes! yay fun bugs!


Fix matplot deprecation warning

Fix matplot deprecation warning in rss merging example.
MatplotlibDeprecationWarning: Case-insensitive properties were deprecated in 3.3 and support will be removed two minor releases later

PR #444


TeamsJS library - Update wording to reflect use of v2.0.0+ library for new apps

TeamsJS library entry is outdated, as v2.0+ is the default library for new apps:
The TeamsJS library enables you to create hosted experiences in Teams. Starting with TeamsJS v.2.0.0, you can extend Teams apps to run in Outlook and Office.
Can we update the definition to reflect the default case of using v2.0.0+ library for new apps? Using v1.x is the exception for new apps. Recommended wording:
The TeamsJS library enables you to create hosted experiences in supported clients including Teams, Outlook, and Office. (Note: When using TeamsJS v.1.x hosted experiences are for Teams client only.)
Thanks!
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: ff9690f5-fa8b-98bb-d3b4-ad4ed1030114
Version Independent ID: ff9690f5-fa8b-98bb-d3b4-ad4ed1030114
Content: Microsoft Teams developer documentation- Glossary - Teams
Content Source: msteams-platform/get-started/glossary.md
Service: msteams
GitHub Login: @surbhigupta
Microsoft Alias: surbhigupta

@jeroen-ms -Thanks for reporting your issue.
We will check this at our end and will get back to you.

@surbhigupta12 -Could you please help us update the document-
In the table TeamsJS Library section, please replace the definition description as follows: -
The TeamsJS library enables you to create hosted experiences in supported clients including Teams, Outlook, and Office. (Note: When using TeamsJS v.1.x hosted experiences are for Teams client only.)
Document Link- https://learn.microsoft.com/en-us/microsoftteams/platform/get-started/glossary#t


Link not working on Azure App Service Page for FunctionApp resource

https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/azure/appservice/#FunctionApp navigates to the Kind FunctionApp.  I think this is because there is both a kind and resource named FunctionApp.

this is no longer an issue, so closing.


Location for code within Package: markov_approx.jl

I came across this due to a broken link in the lecture site.
Should src/markov_approx.jl be located in the markov folder?

Implemented in #99. See discussion there


Fix gateway service dependencies

Please provide a description of this PR:
Fixes https://github.com/istio/istio/issues/42400
The root cause is https://github.com/istio/istio/pull/39168, we should check the old service visibility as well, otherwise users can not opt in
To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

[ ] Ambient
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

Please check any characteristics that apply to this pull request.

[ ] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

@dddddai: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
7fbfc857ee6290a6c82eb4087cca08b15e8cce34
link
true
/test release-notes

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

The issue is cluster shouldn't be visible, We get services from SidecarScope.

The issue is we are not sending new clusters to the gateway, because it does not get xds push if the updated service is not visible, while we should push since the service visibility is changed

In response to a cherrypick label: new pull request created: #42736


how to get data in and out

I'd like to know how I can set/get node values from an external MonoBehaviour.

Hello robotfunk. Could you be more precise?
If you are writing an MonoBehaviour and want to modify the nodes of a graph you just need to get the Graph instance. For example you can get subscribe to the OnCreateGraph event as seen in the documentation.

Hi aphex-, I'm looking for info on how to change values to input and output sockets inside custom nodes. The closest I found was SetDirectInputNumber but I need to change other data types as well.

The SetDirectInputNumber sets a number directly to an InputSocket to avoid connecting another Node to it. It is a convenience feature for the UI.
Currently nothing else than numbers are supported here. If you want to support e.g. direct strings for that you need to implement it for your self. Note that the direct input number is made persistent if you save the Graph as json. You need to do that for your direct input type as well.
It would be easier to write a new Node with e.g. a text field to hold your input data. Note that such a Node (StringNode) already exists for strings. The annotation [SerializeField] in the StringNode tells BON to make the value persistent. This only works for primitive datatypes.
You could also consider buying GDI since this is a more advanced version of BON. Note that GDI does not contain your requested feature!


Fix alignment issue of TensorData bytes

Checklist

[x] Confirmed that run-checks all script has been executed.
I have some issues with flaky tests, in particular quantize_dynamic_int8 and downsample_interpolation are off-by-1 in a few cases. I've ignored them locally, they seem to be fine in CI.
Further, I've stumbled over a test failure seemingly related to my AMD GPU driver

ACO ERROR:
In file ../mesa-24.1.4/src/amd/compiler/aco_assembler.cpp:1056
Unsupported opcode:  v4: %370:v[8-11] = v_wmma_f32_16x16x16_f16 (latekill)%369:v[36-43].xx, (latekill)%359:v[48-55].xx, %368:v[8-11].xx

[ ] Made sure the book is up-to-date with this PR. Not applicable, changes to internals only.

Related Issues/PRs
Fixes #2375.
Changes
Add a new opaque structure Bytes which holds on to tensor data. As explained in the linked issue, using a Vec<u8> is incorrect, as this will deallocate the memory with an incorrect alignment/memory layout given to the allocator, which violates the allocator contract. Instead, the structure remembers the alignment of the data and uses that when deallocating.
For serialization, only the bytes are written and no alignment is taken into account. Instead, when deserializing, the data is allocated with over-alignment (currently align_of::<u128>) which should be sufficient to interpret a slice of the data as a slice of some larger type, such as f32 etc.
Note that this means that serialization is not strictly a round-trip, which can show in the difference between how slices and Vec works:

to re-interpret a [u8] as a [E], the slice needs to be aligned at least as strictly as the alignment of E.
to re-interpet a Vec<A> as a Vec<B>, the alignments must be exactly equal. This means that a deserialized instance of Bytes possibly can not be converted via Bytes::try_into_vec. In case this is needed in the future, one would either need to get access to the needed alignment during deserialization or copy the data to a correctly aligned buffer. Such an API is possible but not included in this PR.

Testing
Some limited tests of TensorData has been run through miri manually to confirm that it doesn't complain after the patch. In case you want tests in the repo, I would need more guidance how to set that up, since miri should probably only run a limited number of tests for CI performance reasons.

Re Codecov report:
The missed lines are for the most part the Debug impl of Bytes. I think it makes sense to invest a bit more time into nice formatting there, any comments on what the output should be would be appreciated.

Sorry for the delayed response! We discussed this offline but forgot to get back to you.
First, thanks for identifying the potential issue.
While these changes to handle alignment concerns more generically could certainly provide better safety, it also adds complexity and might not be immediately necessary. That's why we're a bit hesitant on making this change for now. As you noticed this is not an issue for most allocators.
Of course that doesn't mean it is not an issue, just that it does not affect the majority of use cases. So we should still keep this in mind, and we might circle back in the future thanks to your investigation.

While I understand the added complexity makes it difficult to review, I am a bit disappointed. There is no way around the fact that the currently implementation is misusing unsafe. miri rightfully complains about it. Yes, on the major platforms I have on my hand (linux and windows) the allocator plays along, yet burn-tensor is no_std. I do not have a ras-pi on my hands to test this, but the burn book mentions the embedded-alloc crate and that already seems much more fickle about the alloc requirements. After all, this is rust.
I only noticed this when I implemented the deserialization logic, but please note that the current impl will also happily allocate a Vec<u8> aligned to "just" a u8 even for element types of f32 or whatever you element type one has that will surprisingly and inconveniently fail to by cast to a slice of its own element type for example here.
In any case, I suppose there is no problem with just leaving this open for the time being.
Just one more question: Would you be less wary if the new unsafe code was in a tested outside crate such as bytemuck? Some parts such as the (de)serialization I think don't make sense to be outside burn, but most of the "byte container" could possibly make more sense upstream.

Don't read this as me trying to rush this in, I would also not be happy to see this merged without a proper review.

No worries, we're on the same page here 🙂
I think our main concerns were more in terms of trade-offs, mostly time and possible ramifications to this breaking change (though I think my position has changed on that.. as you'll see below).

burn-tensor is no_std. I do not have a ras-pi on my hands to test this, but the burn book mentions the embedded-alloc crate and that already seems much more fickle about the alloc requirements

I'm glad you brought this up! Honestly I think I kind of forgot to take that into consideration.. this should be especially important for Burn as we aim for portability. I think our previous position was that the current implementation was not an issue for most modern processors and platforms, but that's not good enough.
I should really get a ras-pi myself and start messing around with Burn on no_std so we can improve this.

Just one more question: Would you be less wary if the new unsafe code was in a tested outside crate such as bytemuck? Some parts such as the (de)serialization I think don't make sense to be outside burn, but most of the "byte container" could possibly make more sense upstream.

I'm not too wary about this tbh.
I gotta run but wanted to make sure to get back to you with my current thoughts.
In short, in my previous comment I was opened to the change but did not think it was required for the short term. But now I think we should make sure that this is addressed (ideally, without performance impacts to de/serialization - so we should make sure to benchmark that for some practical use cases).

I gotta run but wanted to make sure to get back to you with my current thoughts.
In short, in my previous comment I was opened to the change but did not think it was required for the short term.

No worries, I too think we are on the same page :) While strictly speaking violating the allocator contract like atm could lead to memory unsafety, I don't think any allocator actually does use the violated guarantees in a meaningful way (but I'm open to surprises). On the other hand, misaligned allocations would be a real concern but at least as far as I can tell mostly lead to panics, not undefined behaviour or violations of memory safety, so a relaxed approach to fixing this is fine :+1: Sorry if I came off as a bit panicky

@WorldSEnder I was looking at your PR yesterday and I think we'd like to stay away from a new opaque type for now.
I also benchmarked some solutions to preserve alignment and none of them come close to the current pointer re-interpret sadly.
I think we can keep both approaches instead based on some target architectures for now, since we know that heap allocations are overaligned on mainstream systems. And for others with stricter alignment rules, we fallback to something similar to what you implemented in the Bytes opaque type. We also add some documentation for anyone that might come across the code in the future 🙂
    /// Initializes a new tensor data structure from the provided values.
    fn init<E: Element, S: Into<Vec<usize>>>(
        mut value: Vec<E>,
        shape: S,
        dtype: DType,
    ) -> Self {
        // Ensure shape is valid
        let shape = shape.into();
        let shape_numel = Self::numel(&shape);
        value.truncate(shape_numel);
        let numel = value.len();
        assert_eq!(
            shape_numel, numel,
            "Shape {:?} is invalid for input of size {:?}",
            shape, numel,
        );

        let bytes = Self::to_bytes(value);

        Self {
            bytes,
            shape,
            dtype,
        }
    }

    fn to_bytes<E: Element>(value: Vec<E>) -> Vec<u8> {
        // Fast path for architectures with heap allocation overalignment.
        #[cfg(all(
            not(miri),
            any(target_arch = "x86", target_arch = "x86_64", target_arch = "aarch64")
        ))]
        {
            let mut value = value;
            let factor = std::mem::size_of::<E>() / std::mem::size_of::<u8>();
            let len = value.len() * factor;
            let capacity = value.capacity() * factor;
            let ptr = value.as_mut_ptr();

            std::mem::forget(value);

            // SAFETY: Practically, mainstream systems align heap allocations beyond
            // the minimum required alignment for the element type (e.g., 8 bytes on 64-bit
            // systems).
            //
            // This is not guaranteed by Rust's memory model, which follows strict alignment
            // requirements as specified by the type's layout.
            //
            // But we leverage the overalignment and efficient unaligned access to interpret
            // the same memory layout as individual bytes instead of `E` elements.
            // This simple trick makes this pointer cast acceptable (and requires no copy).
            unsafe { Vec::from_raw_parts(ptr as *mut u8, len, capacity) }
        }

        // Fallback for architectures with stricter alignment rules.
        #[cfg(any(
            miri,
            not(any(target_arch = "x86", target_arch = "x86_64", target_arch = "aarch64"))
        ))]
        {
            let num_bytes = value.len() * std::mem::size_of::<E>();
            let mut bytes = vec![0u8; num_bytes];
            unsafe {
                std::ptr::copy_nonoverlapping(
                    value.as_ptr() as *const u8,
                    bytes.as_mut_ptr(),
                    num_bytes,
                );
            }
            bytes
        }
    }

I also added miri to the conditions to make sure it doesn't complain 😅 let me know how you feel about this.
We probably need to be careful about f64 elements for 32-bit systems too so the condition might need to be changed.

@laggui I think in the long run, an opaque wrapper should happen (note the wrapper in this PR does no mem-copy so should not have the overhead you mention). A publicly exposed field of Vec<u8> lets the user mem::swap in any Vec<u8> that they may have constructed themselves. I'd want to double check if that entails that the storage has to be aligned if the system allocator always aligns it, my current assumption would be that it entails more weirdness that an opaque wrapper struct would cover.
Secondly, the target detection is perhaps 90% there. Sadly, I don't think there is a way to detect the specific allocator being used, and the check is of course only detecting the target_*, not whether System is being used as the #[global_allocator] and as far as I know there is no way to detect which allocator ends up being used in the end as the forwarding Global does not expose this.
Note for future reference: It seems the choice of default system allocator is made in the std in here if we want to go the route of just using system information as a proxy.
What exactly is the concern with an opaque struct? It seems there would be a simple almost-zero-cost conversion from Vec<u8> to TensorData, a Deref<Target=[u8]> impl and reasonably efficient conversion back to Vec<u8> (though that might entail a mem-copy or the downside of possibly-undefined-behaviour-maybe-just-panicking.
PS: Did you encounter any slowdown with this PR in your benchmarking? If so, this would be a concern and I would put in more work to make sure I didn't miss any unreasonable overhead.

Yeah I think we could (should) remove the public field and users could only get the slice with the current available methods. So no direct access to the underlying bytes. Not sure why we left it public actually 😅

I was wondering if it was intentional that you could push further bytes after construction, cause that seems a bit weird since you could push e.g. a single u8 even when the TensorData contains u16 etc. Good to hear that this was never intended, thought I missed something :D

Was trying to cover the most important cases with this condition where stricter alignment requirements are necessary, but I realize this is not 100%.

After more investigation, and a bit longer look than I had wished, I found that the default allocator on windows actually does use the passed align in a non-trivial way. Specifically, data below MIN_ALIGN is just allocated as-is, but anything beyond that will allocate additional space and contain a header with a pointer to the actual allocation, pictogram:
 v --- aligned to MIN_ALIGN, this pointer is allocated from HeapAlloc
 | x x x x Header(ptr) | u u u u u u u ..... |
 ^----------------^-^
                       ^  aligned to requested alignment, this pointer is returned to user-code

The reason the current code gets away with it - supposedly - is because on 64-bit platforms MIN_ALIGN is 16, which is larger than the data types that currently get put into a tensor. But it's awefully brittle and it just feels like corner-case after corner-case to find these kind of "exceptions" to the allocator playing nicely along to wrong alignment.

it introduces a breaking change

Yeah, the timing close to the release of 0.15 is a bit unfortunate. Not sure about your planned release cycles, I wouldn't mind holding it until the breaking 0.16 comes along naturally.

Also tiny note on the current Bytes implementation: what about sending between threads?

Thread-safety is indeed a good point. The current Bytes should be Send + Sync without a problem since Element: Send + Sync and &Bytes offering only read access, but that could be encoded in some static asserts and tests.

The results seem to be on par with the current, which is great 🙏

There seems to be a slight slowdown in deserialization, which might perform an extra copy to an aligned buffer. I think in that case we can get away with actually checking the runtime alignment instead (still storing and de-allocating with the alignment of the actual buffer) and not copying/only copying when someone wants to convert it an actual Vec<E>. I will take another look 👍

Alright, have added both suggestions (Sync and Send + avoiding a copy if the deserialized vector ends up being aligned). I have added further tests and these can be run under miri. In case you want to do that yourself, try it with

cargo +nightly miri test --package burn-tensor --lib -- tensor::bytes::tests --show-output

@laggui I wanted to merge the changes from quantization and in the process came up with a few questions where I'm not sure what's intended and what is not, again about serialization.
There should be no difference in this PR and the state on main, but (de)serialization seems to assume that data in storage is in system byte order. I don't see any conversion from/to network byte order. So serializing a tensor on a little endian (LE) system such as x86, then deserializing on a BE system (well mostly SPARC; but fairly uncommon I think) would shuffle the bytes and not recover the data as intended. Further network order is big endian (which is lame, as most systems have to perform a byte shuffle for what are merely historic reasons). So the question is this: Since serialization is performed as a byte sequence where endianess matters, is the current state just assuming little endian everywhere and not correcting for it correct?
If the answer to the above is yes, and there is no external constraints on the byte order, I don't see why the byte packing (which does seem to pad with 0s, then reinterpret as a Vec of big endian u32) could not just use the system endianess and pad then reinterpret without endianess conversion and do so in place. The current implementation seems to create 2 extra Vecs. One in pack_i8s_to_u32s, then another in to_vec().
In any case, I will implement a fn extend_from_slice for Bytes to accomodate storing the quantization strategy there.
A lot of methods seem to ignore the difference between values_as_bytes and as_bytes and try to make use of the additional quantization data, too (such as iter, to_vec). Is that intentional?

@laggui I wanted to merge the changes from quantization and in the process came up with a few questions where I'm not sure what's intended and what is not, again about serialization.
There should be no difference in this PR and the state on main, but (de)serialization seems to assume that data in storage is in system byte order. I don't see any conversion from/to network byte order. So serializing a tensor on a little endian (LE) system such as x86, then deserializing on a BE system (well mostly SPARC; but fairly uncommon I think) would shuffle the bytes and not recover the data as intended. Further network order is big endian (which is lame, as most systems have to perform a byte shuffle for what are merely historic reasons). So the question is this: Since serialization is performed as a byte sequence where endianess matters, is the current state just assuming little endian everywhere and not correcting for it correct?

Yep, we don't check for endianness atm so we assume everything is fine for now. Might have to check in the future.

If the answer to the above is yes, and there is no external constraints on the byte order, I don't see why the byte packing (which does seem to pad with 0s, then reinterpret as a Vec of big endian u32) could not just use the system endianess and pad then reinterpret without endianess conversion and do so in place. The current implementation seems to create 2 extra Vecs. One in pack_i8s_to_u32s, then another in to_vec().

Funny you bring this up, I realized the other day while making some changes that the "packing" order might not be as optimal. Quantization is still WIP but we were just about to refactor the quantization kernels in jit along with the representation. Learning some things as we go :)

In any case, I will implement a fn extend_from_slice for Bytes to accomodate storing the quantization strategy there.
A lot of methods seem to ignore the difference between values_as_bytes and as_bytes and try to make use of the additional quantization data, too (such as iter, to_vec). Is that intentional?

In iter we chose not to dequantize the values so it is intentional for the current behavior. Doesn't make as much sense in to_vec, we should change that.

Yep, we don't check for endianness atm so we assume everything is fine for now. Might have to check in the future.

Ah okay! If you do, that could be a good spot to move the assumption of a MAX_ALIGN to something more dtype dependent, as I would assume that converting byte order also needs to know about the underlying datatype, which could in one swoop also fix the runtime alignment (try_enforce_runtime_align in this PR).

I was wondering if it was intentional that you could push further bytes after construction, cause that seems a bit weird since you could push e.g. a single u8 even when the TensorData contains u16 etc.

I think there might be some use cases for that actually.. I discussed with @nathanielsimard last week and iirc this was one of the reasons for keeping it as Vec<u8> at the moment. Correct me if I'm wrong, but this was for some work in burn-remote? Can't remember exactly what you mentioned so maybe you could chime in here with your points.

I don't recall a reason to push u8 into the vector.

@syl20bnr I believe https://github.com/tracel-ai/github-actions/blob/b87057a7f68360d9d01a8da21de874c38e7acbab/setup-rust/action.yml#L23-L26 is accidentally run on windows machines as well, leading to some tests failing there.

Argh, thank you, fixing it.

@WorldSEnder should be fixed, I restarted the job.

Okay, implemented Bytes::extend_from_byte_slice to support appending quantization data. This means TensorData::quantized should use at one less vec copy in most cases. Note that pack_i8s_to_u32s could probably be done in place, but that's left for another PR.
I realized that most methods that use the bytes, such as the aforementioned as[_mut]_slice and to_vec/into_vec refuse on the grounds of mismatching datatypes ("normal" vs quantized) before trying to touch the unrelated quantization data. Perhaps this could be a deliberate choice telling users to unquantize before being allowed to use these methods anyway.
As a side-effect of working Bytes into quantized, this now has a length check (unified with new), I suppose this was meant to be there in the first place. Let me know if I missed anything :)

TLDR This PR should be merged asap. Fixing a soundness issue that could turn into a security advisory should not be stalled for this long.
I recently started experimenting with burn, enjoyed it a lot, but now came across this PR and I'm concerned.

As explained in the linked issue, using a Vec<u8> is incorrect, as this will deallocate the memory with an incorrect alignment/memory layout given to the allocator, which violates the allocator contract.

This is still an understatement. When violating a safety condition of an unsafe method, you need to assume that this causes undefined behaviour (and in this case it immediately does and is caught by Miri).

While these changes to handle alignment concerns more generically could certainly provide better safety, it also adds complexity and might not be immediately necessary. That's why we're a bit hesitant on making this change for now. As you noticed this is not an issue for most allocators.

The Rust compiler is allowed to do anything with a program that exhibits undefined behaviour. So any program that uses burn somewhere could in theory be compiled into complete garbage because burn includes unsound code. The compiler is not as optimising/punishing that every soundness issue infects compilation this way, as can be seen by this code running just fine, but that can change with any new release of Rust. It would be a shame if some larger application upgrades their Rust version and suddenly crashes at runtime because the compiler is now smart enough to exploit this undefined behaviour for further optimisations.
While you are right that this does issue does not manifest on the most popular platforms, Rust has a high standard for writing sound code - "it hasn't segfaulted on my machine yet" is not sufficient in Rust. Safe Rust code must never exhibit undefined behaviour (and so any soundness issues should be fixed as soon as they're discovered) and should never segfault, and since you are exposing TensorData with a safe interface, you are required to make sure that no undefined behaviour can occur when calling it from safe code.

"it hasn't segfaulted on my machine yet" is not sufficient in Rust.

To be fair, it hasn't segfaulted on any machine for Burn users 😅 the current implementation is safe on the target platforms using Rust's default allocator. The discussion in this PR details why it works in practice with the supported tensor data types, and other allocators were out of scope. Now, as I mentioned in my previous comments, this doesn't mean that this is a non issue.
I actually would have liked to merge this two weeks ago following the planned release, but we had to work on other issues and improvements (here and in CubeCL) which have caused us to push our release schedule. And the plan was to make this breaking change for the following release.

I’m happy to hear the PR will be merged soon <3
I really like burn so far and want to use it for a longer term project.
The default Rust std allocator is unspecified, but currently delegates to the System allocator. After a few more layers of redirection, we end up with its implementation here (for Unix, in adjacent files for other operating systems): https://github.com/rust-lang/rust/blob/master/library/std/src/sys/alloc/unix.rs You can see that it boils down to libc being called on Unix.
However, different targets use different allocators to back the system and so you would have to check all of their implementations to see if your stronger requirements are met.
Furthermore, supplying a different global allocator is not a feature that a Rust crate can choose to not support. The global allocator is opaque to all libraries and the only assumptions you can make are in its safety contract.
So you could, with just safe code, change the allocator to one where freeing memory with a different (but same-sized) layout than it was allocated with (the effect of creating a Vec from the raw parts of a Vec of a type with a different size and alignment) does mess things up. In that case, the UB would still be burn’s fault.
All of this is to say that UB must be taken seriously.
Perhaps it might be a good idea to run your test suite in CI with Miri (probably only the pure Rust parts, so e.g. just the NdArray backend and only on smaller examples since Miri is quite slow) so that you can have more reassurance that your code is safe.

@WorldSEnder thanks for keeping this up to date with the changes on main 🙏
Before merging I wanted to be sure that there were no big performance impacts, but running a quick serialization / deserialization test showed ~30% slowdown for deserialization. In my previous benchmarks I only tested the module loading (without saving / loading on disk), so this discrepancy seems to be directly related to the Deserialize implementation.
main

Benchmark
Feature
Backend
Device
Median

serialize
ndarray
ndarray
Cpu
835.821ms

deserialize
ndarray
ndarray
Cpu
114.644ms

Bytes struct

Benchmark
Feature
Backend
Device
Median

serialize
ndarray
ndarray
Cpu
799.097ms

deserialize
ndarray
ndarray
Cpu
148.214ms

Once the deserialization is on par, this should be good to merge 🙂
I'll look into this tomorrow but feel free to ping me otherwise.

Benchmark Code
use backend_comparison::persistence::save;
use burn::record::{FullPrecisionSettings, HalfPrecisionSettings, NamedMpkFileRecorder};
use burn::tensor::backend::Backend;
use burn::tensor::Device;
use burn::{config::Config, module::Module, nn};
use burn_common::benchmark::{run_benchmark, Benchmark};
use derive_new::new;

#[derive(Module, Debug)]
struct BenchmarkModule<B: Backend> {
    linears: Vec<nn::Linear<B>>,
}

#[derive(Config, Debug)]
struct BenchmarkConfig {
    linear: nn::LinearConfig,
    num_layers: usize,
    path: String,
}

impl BenchmarkConfig {
    pub fn init<B: Backend>(&self, device: &B::Device) -> BenchmarkModule<B> {
        BenchmarkModule {
            linears: (0..self.num_layers)
                .map(|_| self.linear.init(device))
                .collect(),
        }
    }
}

#[derive(new)]
struct SerializeBenchmark<B: Backend> {
    config: BenchmarkConfig,
    device: Device<B>,
}

impl<B: Backend> Benchmark for SerializeBenchmark<B> {
    type Args = (
        BenchmarkModule<B>,
        NamedMpkFileRecorder<HalfPrecisionSettings>,
    );

    fn name(&self) -> String {
        "serialize".into()
    }

    fn execute(&self, (module, recorder): Self::Args) {
        module
            .save_file(self.config.path.clone(), &recorder)
            .unwrap();
    }

    fn prepare(&self) -> Self::Args {
        let module = self.config.init(&self.device);

        (module.clone(), NamedMpkFileRecorder::new())
    }

    fn sync(&self) {
        B::sync(&self.device)
    }
}

#[derive(new)]
struct DeserializeBenchmark<B: Backend> {
    config: BenchmarkConfig,
    device: Device<B>,
}

impl<B: Backend> Benchmark for DeserializeBenchmark<B> {
    type Args = (
        BenchmarkModule<B>,
        NamedMpkFileRecorder<FullPrecisionSettings>,
    );

    fn name(&self) -> String {
        "deserialize".into()
    }

    fn num_samples(&self) -> usize {
        50
    }

    fn execute(&self, (module, recorder): Self::Args) {
        let _ = module.clone();
        module
            .load_file(self.config.path.clone(), &recorder, &self.device)
            .unwrap();
    }

    fn prepare(&self) -> Self::Args {
        let module = self.config.init(&self.device);

        (module.clone(), NamedMpkFileRecorder::new())
    }

    fn sync(&self) {
        B::sync(&self.device)
    }
}

#[allow(dead_code)]
fn bench<B: Backend>(
    device: &B::Device,
    feature_name: &str,
    url: Option<&str>,
    token: Option<&str>,
) {
    let config = BenchmarkConfig::new(
        nn::LinearConfig::new(2048, 2048),
        12,
        "/tmp/serialize.mpk".into(),
    );

    let benchmark_serialize = SerializeBenchmark::<B>::new(config.clone(), device.clone());
    let benchmark_deserialize = DeserializeBenchmark::<B>::new(config.clone(), device.clone());

    save::<B>(
        vec![run_benchmark(benchmark_serialize)],
        device,
        feature_name,
        url,
        token,
    )
    .unwrap();
    save::<B>(
        vec![run_benchmark(benchmark_deserialize)],
        device,
        feature_name,
        url,
        token,
    )
    .unwrap();
}

fn main() {
    backend_comparison::bench_on_backend!();
}


Some assets look bad in HiDpi

I'm using a 3200x1800 screen and some assets, specifically the close, minimize, and resize widgets look obviously blurry.

There is a PR on the way to fix it, thanks for bringing it up 👍

Great, thanks for the update!
Love the theme.

Affects me too! I use a 2560x1440 screen and it looks blurry with hidpi scaling. I hope this can be updated with hidpi assets eventually!

This was fixed in one of the PR. Can anyone confirm the same?

Fixed in #88


Inventory stock update

I want to update the Inventory stock details to Amazon Seller Central using SP-API.
What is API for updating the Inventory stock?
Does anyone have suggestions?

@amz-tools
Can you hep in the case also?


Use new storage + messaging libs

[x] bags_api
[x] ingests_api
[x] bag_auditor
[x] bag_register
[x] bag_replicator
[x] bag_unpacker
[x] bag_verifier
[x] common
[x] display
[x] ingests
[x] ingests_common
[x] notifier

There's a replicator bug which traces back to scala-storage; see wellcometrust/platform#3630.

✨ 🎉 ✨


Thread did not Finish

Specs:
AMD Ryzen 5 3600X 6-core
Radeon RX 570
Modlist:
Loading game from file Pact of Farreoum with mods:

Harmony
RimWorld
HugsLib
Humanoid Alien Races
Hospitality
PawnNameVariety
SRTSexpanded
BetterPawnControl
Animals Logic
Blueprints
AllowTool
Android Tiers
Snapout
GlassLights
Mend And Recycle
Miscellaneous.Core
MoreTradeShips
Infused
Bulletcasings
Pack Mules Extended-Dinosauria
Pack Mules Extended
MineItAll
Glowinghealroot
Misc. Robots
Misc Robots ++
Simple Search Bar
Color Coded MoodBar [1.1+]
Damage Indicators [1.2]
Project RimFactory Revived
Reinforced Walls
Wall Light
Achtung
Alpha Animals
Dub's Paint Shop
Level Up!
Various Space Ship Chunk (Continued)
Expanded Roofing
Simple Sidearms
Dinosauria
Research Tree (Out of Date mod, for 1.0 & 1.1 currently)
EdB Prepare Carefully
Doors Expanded (Out of Date mod, for 1.0 & 1.1 currently)
[FSF] Filth Vanishes With Rain And Time
Harvest Organs Post Mortem
More Sculpture
RimNauts
NetGun
Absolute Legends Hair
Project Itzal - Main Pack
Project Itzal - Even More Guns
Project Itzal - Bonus Pack
Extended Human Body Simulation
Holsters And Scabbards
Bandage Wraps
Electric Fences And Floors (Continued)
Modders Deserve Credit, too
Sandy's RPG Style Inventory [1.2]
Vanilla Cooking Expanded - Sushi
Vanilla Cooking Expanded - Stews
Fav Locker
Vanilla Hair Expanded
Vanilla Hair Expanded - Beards
Ranged DPS
Dragon's Descent
Vanilla Expanded Framework
Vanilla Plants Expanded
Vanilla fishing Expanded
Vanilla Cooking Expanded
Vanilla Plants Expanded - Succulents
Vanilla Brewing Expanded
Vanilla Weapons Expanded - Grenades
Smarter Construction
Vanilla Weapons Expanded - Lasers
The  Human Hive
TMC Armory - Shotguns # 1
TMC Armory - AssaultRifle # 1
TMC Armory - Sidearms # 1
No Death Cooties On Armor
T45b Power Armor (Out of Date mod, for 1.0 & 1.1 currently)
RimThreaded [1.2]
Android Resurrection Kit (rebuild)
Jewelry
Gunplay
Grazing Lands
RimHeli
Save Our Ship 2
LED Lights
Room Sense
Pick Up And Haul (Out of Date mod, for 1.0 & 1.1 currently)

Issue:
Game comes to a Crawling Frozen Slideshow, Debug menu shows multiple "Thread: XX did not finish within 1000ms. Restarting thread... " errors.
As far as I can discern, this is caused by a herd of Muffalo Revenge Chasing a Tier[2] Android settler of mine who had been hunting them began as two Muffalo got close enough to attack the Colonist. However I tried to wait it our and the error continues to happen actively whilst the Muffalo were not actively attacking, though they were on melee cooldown still (see Screenshots). I have replicated this in a new game by getting a herd of elephants to revenge at my colonist. the moment they went into the manhunter state, the game began to freeze and i started getting the "Thread: XX did not finish..." messages.
I had this issue happen with a raid previously, but it only seemed to happen for a short period of the approach when two of the attackers were moving on the same tile. They were in no way engaging in combat as they  were out of range at the time. I unfortunately do not have screenshots of this and have not been able to replicate it.
I have not had problems with pawns walking on the same spot otherwise, even with caravans, so perhaps it has to do with the pawns being drafted or manhunting?
I hope this data is helpful!
Good Luck!
Muffalo Incident Debug Menu output

Recreation Debug Menu Output

and screenshots for all
screenshots and original logs.zip

@cseelhoff Here aswell


[Decomp] Decompile connect.gc

Pull Request Test Coverage Report for Build 604288261

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 68.72%

Totals

Change from base Build 603892416:
0.002%

Covered Lines:
30652

Relevant Lines:
44604

💛  - Coveralls


[BUG] Tar shows weird errors regarding JDK 11 in 1.3.0

tar: opensearch-1.3.0/jdk/legal/jdk.zipfs: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.xml.dom: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.unsupported.desktop: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.unsupported: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.security.jgss: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.security.auth: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.sctp: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.scripting.nashorn.shell: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.scripting.nashorn: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.rmic: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.pack: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.net: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.naming.rmi: implausibly old time stamp 1970-01-01 00:00:00
tar: opensearch-1.3.0/jdk/legal/jdk.naming.ldap: implausibly old time stamp 1970-01-01 00:00:00

This only happens in 1.3.0 after we change to JDK11.
I am not able to understand how this is coming from.
To reproduce, download this and extract it:
wget https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/1.3.0/1240/linux/x64/dist/opensearch/opensearch-1.3.0-linux-x64.tar.gz
tar -xzvf opensearch-1.3.0-linux-x64.tar.gz

Thanks.

@peterzhuamazon I cannot reproduce it on my Ubuntu 21.10 :(

@peterzhuamazon I cannot reproduce it on my Ubuntu 21.10 :(

Interesting, it shows on my AL2 test machine.
Let me dig a bit more into it.
Thanks.

Seeing some possibly related notice here: https://bugzilla.redhat.com/show_bug.cgi?id=1229160

I am specifically testing on AL2 EC2 instance.
Not sure about containers at the moment.

Ran it on Ubuntu 20.04 and AL2 5.1
Noticed similar issues with AL2. Investigating
AL2-tar-log.txt
ubuntu-tar-log.txt

Found a similar issue: https://jira.mongodb.org/browse/TOOLS-2706
https://github.com/mongodb/mongo-tools/pull/309/files

Pointed the head to before the JDK changes - https://github.com/kotwanikunal/OpenSearch/tree/test-jdk-issue
components:
  - name: OpenSearch
    repository: https://github.com/kotwanikunal/OpenSearch.git
    ref: test-jdk-issue
    commit_id: 919d18036e421f3d48ce0c3278d698fb8651cb22
    location: /Users/kkotwani/workspace/opensearch-build/builds/opensearch/dist/opensearch-min-2.0.0-linux-x64.tar.gz

Ran ./build.sh -p linux -a x64 -d tar manifests/2.0.0/opensearch-2.0.0.yml --component OpenSearch, followed by ./assemble.sh builds/opensearch/manifest.yml
Extracting the resulting tar file still gives the same error.

Binary searched through the distribution builds. The issue started to occur with Build 755 exactly.
The distribution build occurred around February 2, 2022, 11:43:17 (UTC-08:00)

@kotwanikunal Any update on the fix for this bug? Please update this thread when you have an answer - https://discuss.opendistrocommunity.dev/t/implausibly-old-time-stamp-1969-12-31-error-while-untarring-opensearch-1-3-0/8989

@kotwanikunal Any update on the fix for this bug? Please update this thread when you have an answer - https://discuss.opendistrocommunity.dev/t/implausibly-old-time-stamp-1969-12-31-error-while-untarring-opensearch-1-3-0/8989

I tried working around the issue with the JDK versions and the tarballing configuration. I haven't had a lot of luck fixing/root causing it.
I'll be working with the team to find a path forward.

@minalsha I don't think this was prioritized and is being actively looked into.
@CEHENKLE / @anasalkouz

Checked out the opensearch repo and ran  ./gradlew :distribution:archives:linux-tar:assemble. While trying to untar the tar.gz file present in distribution/archives/linux-tar/build/distributions/ I am facing implausibly old time stamp 1970-01-01 00:00:00 error for all the files related to opensearch.
After doing some deep-dive the issue seems to be coming from here. The isPreserveFileTimestamps property is set to false due to which the modification time of the files getting copied is not preserved, reason being method  returning 0 instead of mod-time in epoch.
Can someone please look into this and set this property to true?
After setting the property to true by hardcoding in the code, the tarball is not throwing timestamp warning during untar.
@kotwanikunal @bbarani @peterzhuamazon @reta

@rishabh6788 the isPreserveFileTimestamps comes from Gradle's org.gradle.api.tasks.bundling.Tar task, with default value being true. It was changed to false in this commit [1] to support reproducible builds (to eliminate dates factor), probably have to be reverted :(
[1] https://github.com/opensearch-project/OpenSearch/commit/6da253b8fff9a9d9cbbf65807efa7aeaddc9c9d3

Got it! Not really sure about the impact of reverting the change but the warnings on each file during untar doesn't give a good user experience. @reta

Indeed it does not, @nknize @andrross any concerns with reverting some parts of https://github.com/opensearch-project/OpenSearch/pull/1995?

Reverting #1995 will break reproducible builds, right? Is there any way around this short of recommending that users supply --warning=no-timestamp to the tar command?

It does not prevent the untar just warnings.
That is why I was not particularly concern on the 1st place.
It will just default back to 1970 if no timestamp.

Reverting #1995 will break reproducible builds, right?

Yes, it will

That is why I was not particularly concern on the 1st place, just annoying.

Correct, it just floods the output

My inclination is to keep reproducible builds (and the resulting warning from the untar command) as opposed to reverting #1995. The untar warnings can be suppressed with --warning=no-timestamp but including real timestamps breaks reproducible builds with (to my knowledge) no alternate workaround.

@andrross / @kotwanikunal  can one of you summarize the issue and next steps for this issue?

@minalsha The "reproducible builds" feature is the capability to deterministically produce the same output of a build given the same input. One example of non-determinism is using build-time timestamps on file timestamps when creating the build artifacts. A maintainer for OpenSearch in Arch Linux created a pull request (#1995) against OpenSearch core to change the gradle build settings to make the build reproducible, which involves removing build-time file timestamps (I don't actually know if the times are zeroed out or just omitted...). One side effect of this change is that by default in some environments, the tar command will produce a lot of warning statements about implausibly old timestamps when extracting the tar archive.
My opinion is that we should probably not do anything here, since reproducible builds seem like a good thing and the tar warnings are harmless (and can be avoided if you pass the --warning=no-timestamp option when untarring the archive). @reta @rishabh6788 What are your opinions on this issue?

@reta @rishabh6788 What are your opinions on this issue?

I think there is a value in reproducible builds, but may be we need a bit different approach then just zeroing timestamps: may be we could always set the timestamp out of the last commit? In this case, whenever the same change set is being build - it is reproducible build. If it sounds like a thing to try, I could try it out, @andrross wdyt?

@reta Totally agree that zeroing out timestamps seems odd. But we are following the recommended approach from the Gradle documentation to create reproducible builds. I'm not opposed to using the commit time like you described, but would just worry if it introduced a lot of complexity.

I am thinking about it as a simple change, if it is not - I will not spend time on it (Gradle is always full of surprises) ....


Type namespace prefixes

One of the main reasons that different datasources play well together is that they use different prefixes for their types. However, this is neither enforced nor validated. I would like GrAMPS to apply the namespace of the datasource to my types itself, instead of having to do this myself for every type. I think this would make individual datasources a lot more readable, and given that they are always supposed to be processed through GrAMPS, it seems logical that GrAMPS would be in charge of managing those namespaces.
I don't know if there are cases where you explicitly don't want types to be prefixed. If that's the case, then this proposal wouldn't work. In that case, I would some form of validation, instead of depending on mergeSchemas to throw an error.

@kbrandwijk One of the things I have in my test suites of my GrAMPS server is a check that each of the data sources has a unique namespace. While I see where this sentiment is coming from, I think this solution results in too much magic being done by GrAMPS itself. At the very least, I would argue that if this were to be implemented, it should be opt-in, not opt-out, since I think that many dev teams would want tight control of their GraphQL type names.


How to close a database connection?

I'm sorry for asking this stupid question here, but...
where is the 'close(db)' function of something to that effect?
I'm implementing an application that needs to open/close/reopen multiple connections with separate SQLite db files (like tens of them), I can not just abandon the previous connection...

Found other ways to do it ( three to be precise). Thank you.

Can you communicate how do you do that please?

I'd be curious aswell since I too often get stuck in "Database is locked" errors.

You can call SQLite._close(db) for now; I can probably clean things up and implement an official close(db) that will be safe and idempotent.


Refactor the website to be more user-friendly

Here are the changes:

Update the Contributing page to be more current, including adding a
SPREAD THE WORD message

Refactor the introduction to show more of what Wash can do upfront

Reorganize some links so more "interesting" stuff is first

Resolves https://github.com/puppetlabs/wash/issues/648
Signed-off-by: Enis Inan<EMAIL_ADDRESS>

Based the PR off master so that the changes here can be viewed at https://ekinanp.github.io/wash/

We could probably iterate on each plugin's screencast, but that can be done separately. I think what's here seems good enough to start with.


Don't show delayed routes if delayed by <= 2 minutes

The live tracking only gets updated every 30 seconds and it's finicky sometimes, and people miss the bus because they expect it to be delayed but it's not.

was this resolved? @alanna-zhou

was this resolved? @alanna-zhou

iOS is dealing with this now.


Logrotate for Influxdb

I think logrotating could be useful for influxdb... Is something planned?

https://github.com/influxdb/influxdb/issues/1943

Ops, sry didnt see...


command not found: __git_aliased_command

Fresh install breaks git auto-completion, and causes terminal to crash.

Looks like something going wrong with the gitfast plugin. Possibly that the git-completion.bash script is not getting sourced.
$ grep -r git_zsh_bash_func *
plugins/gitfast/_git:__git_zsh_bash_func ()
plugins/gitfast/_git:		__git_zsh_bash_func $command
$ grep -r git_aliased_command *
plugins/gitfast/_git:	local expansion=$(__git_aliased_command "$command")
plugins/gitfast/git-completion.bash:# __git_aliased_command requires 1 argument
plugins/gitfast/git-completion.bash:__git_aliased_command ()
plugins/gitfast/git-completion.bash:	local expansion=$(__git_aliased_command "$command")
$

I can't reproduce on my OS X 10.9.5 box. What OS and theme are you using?
Could you run omz_diagnostic_dump and post the results as a gist so we can get debugging info for this?

Closing for the time being for not responding. Reopen if necessary.

im not running gitfast, but here is a omz_diagdump for you to look at: https://gist.github.com/tdyer-aio/b3e8d9f794b521f2fd81

also, this seems like it may be related to a recent upgrade to el capitan.

Interesting. I had thought the problem was confined to the gitfast plugin. Will take another shot at reproducing this on el cap.

@mcornella or @azer, can you reopen this issue since we have another lead and report of ongoing breakage?

➜  .oh-my-zsh git:(master) ✗ grep -r __git_aliased_command *
plugins/gitfast/_git:	local expansion=$(__git_aliased_command "$command")
plugins/gitfast/git-completion.bash:# __git_aliased_command requires 1 argument
plugins/gitfast/git-completion.bash:__git_aliased_command ()
plugins/gitfast/git-completion.bash:	local expansion=$(__git_aliased_command "$command")
➜  .oh-my-zsh git:(master) ✗

I disabled git autocomplete plugin and things began working again. I think zsh is conflicting with manually installed git autocomplete plugin.

Is this still relevant? @azer when you say git autocomplete plugin you mean gitfast?


Linux: experiment linking libvips with -Bsymbolic-functions

See https://github.com/kleisauke/libvips-packaging/commit/41fb70c9ae3dd237fb7f3e9924f7121505ca1b28 and https://github.com/kleisauke/net-vips/issues/90 for context. Could possibly resolve https://github.com/lovell/sharp/issues/575 (and other node-canvas related issues).
GLib uses this linker flag by default, so it might make sense to also link libvips with this flag. The above NetVips issue had no issues running this on macOS, so I'm not sure if this flag is needed there as well (Homebrew also seems to avoid any -Bsymbolic* linker flags, probably due to missing support for this in Xcode(?)).

Nice idea, happy for a PR if you're able. This is an ELF-only feature so should be ignored by linkers for e.g. macOS targets.

Great, I'll prepare a PR.
Ah, you're right, this linker flag only applies to ELF binaries and not to Mach-O, for example. I got confused since HarfBuzz seems to configure successfully with -Bsymbolic-functions on macOS, see:
C++ compiler for the host machine: clang++ (clang 11.0.3 "Apple clang version 11.0.3 (clang-1<IP_ADDRESS>)")
C++ linker for the host machine: clang++ ld64 556.6
Host machine cpu family: x86_64
Host machine cpu: x86_64
Compiler for C++ supports link arguments -Bsymbolic-functions: YES

(Re-opening auto-closed issue until we publish a new release.)

At @lovell's suggestion, I've just opened https://github.com/electron/electron/issues/25495 (which may help other native modules).


Added integration with Travis-CI deployments and test execution.

Important notice
You will need to update the follwing to make integrations work for you:

signup onto travis and enable repo integration
signup to dockerhub and do one of

ask me for access to our docker repo for DB images
create your own images in private repo (see: https://github.com/utPLSQL/docker-scripts or https://github.com/oracle/docker-images/tree/master/OracleDatabase)

set secret env variables
- DOCKER_USER          - Your Dockerhub user
- DOCKER_PASSWORD      - Your Dockerhub PASS
- ORACLE_OTN_USER      - Your Oracle Tech Net user
- ORACLE_OTN_PASSWORD  - Your Oracle Tech Net PASS
- DB_SYS_PASSWORD      - SYS account password for DB
- SONAR_TOKEN          - if you want to use sonarcloud.io for static code analysis and publishing of test results - see https://docs.travis-ci.com/user/sonarcloud/
to make sonarcloud integration, signup to sonarcloud with your github account and configure it. It's actually pretty simple.
you will also need to update badges in readme.md, snarcloud organization in travis.yml and sonar-project.properties (they all point to jgebal/Logger repo)

Content
Added integration with sonarcloud.io
Converted and added test package as utPLSQL v3 unit test.
The change includes:
testing deployment of Logger in automated fashion on each commit
running tests and showing test results in Travis-CI
exporting test results and coverage into sonar
performing static code analysis in sonar
Additional badges for sonar and travis were added to readme.md
For details on integration see:
https://www.sonarcloud.io/documentation/integrations/github/
https://docs.travis-ci.com/user/sonarcloud/
To see the integration working on my github see:

badges integrated with readme: https://github.com/jgebal/Logger/blob/3.2.0/README.md
sonarcloud analysis: https://sonarcloud.io/dashboard?id=jgebal_Logger
Travis builds: https://travis-ci.org/jgebal/Logger/builds
Travis build log indicating a failing test: https://travis-ci.org/jgebal/Logger/jobs/540434451#L3313
Travis notifications on Pull requests: https://github.com/jgebal/Logger/pull/1 https://github.com/jgebal/Logger/runs/140210253

@martindsouza - any chance to get this PR reviewed?


[Bug]: nil pointer dereference in crypto.BytesToPrivateKey

Preflight Checklist

[X] I could not find a solution in the documentation, the existing issues or discussions
[X] I have joined the ZITADEL chat

Version
v3.4.0
Describe the problem caused by this bug
There is no check for nil at pkg/crypto/key.go:11 which causes panic if no valid PEM data was found in the priv argument.
To reproduce
https://go.dev/play/p/n66dBYyTusx
package main

import (
	"github.com/zitadel/oidc/v3/pkg/crypto"
)

func main() {
	// panic: runtime error: invalid memory address or nil pointer dereference
	crypto.BytesToPrivateKey([]byte("some not well-formatted PEM data"))
}

Screenshots
No response
Expected behavior
Return an error rather than panic.
Additional Context
No response

I'll make a PR in the next 24 hours. Thank you for the quick response, @muhlemmer!


Could not run places retriever via genkit UI

Expected Behavior

I get some data back like shown in the codelab

Actual Behavior

the execution fails with the error TypeError: Cannot read properties of undefined (reading 'where')

Steps to Reproduce the Problem

Follow the steps of the codelab
use the real places retriever via defineFirestoreRetriever
Paste the example query input to genkit
Run the retriever

Specifications

Version:

  "dependencies": {
    "@genkit-ai/ai": "^0.5.0-rc.11",
    "@genkit-ai/core": "^0.5.0-rc.11",
    "@genkit-ai/dotprompt": "^0.5.0-rc.11",
    "@genkit-ai/firebase": "^0.5.0-rc.11",
    "@genkit-ai/flow": "^0.5.0-rc.11",
    "@genkit-ai/vertexai": "^0.5.0-rc.11",
    "firebase-admin": "^12.1.0",
    "zod": "^3.23.8"
  },
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^5.12.0",
    "@typescript-eslint/parser": "^5.12.0",
    "eslint": "^8.9.0",
    "eslint-plugin-import": "^2.25.4",
    "typescript": "^4.9.5"
  },

Platform: Linux Ubuntu 22.04

Sounds like you're reading from an empty object.
I added some null/empty checks and some default `` string values in #23
so I expect this to fix your issue (that would occur sometimes, if the model decides to not retrieve enough docs).
If not, please reopen.


Is mold need to be built from source everytime

Hello maintainer, I'm new to GitHub actions and looking forward to using your action script in my CI.
However, when using the action I noticed that the mold linker is built from source. And the log seems to mention cache, is there any plans to make users able to download the binary file directly? That will save a lot of time.

Yes, initial plan was to cache mold binary. The code does this but there's a cache miss every time for some reason.
Same cache worked for my other action.

Please try again v1 now @ClSlaid

Now mold v1.1 is released with pre-built binaries. 🥳

Please try again v1 now @ClSlaid

But the v1 is still the version published 20 days ago, you may need to publish first?

https://github.com/actions/toolkit/issues/58
🤦


blocking recaptcha v3

Google's Recaptcha v3 is an "invisible" captcha, which determines if you're human or a bot based on your behaviour on the website (mouse movement, clicks, scrolls, etc).
With the ddg privacy extension active, your data is still sent to Google when websites use Google's recaptcha. The data sent to Google is obfuscated so it is unclear which data they gather. For all I know they might even track what data you enter in the form. An xhr request is sent to Google upon a form field change, so that might as well be true. Google's privacy policy isn't clear about this (at least as far as I've read it).
Is there no way to block it without breaking a website's contact forms?

I'm sorry, but that is not possible, the site that uses it receives data from the captcha script in the form, and server-side they'll contact Google to verify the data. If the data isn't present, because you blocked the ReCaptcha script, you'll be recognized as a bot.


bug-report: include ambientz in debug output

To help debug ambient issues

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
e7b84083b238341f91a6f21c01b57694611cfe17
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

/retest


generate a unique cleanup step key for builds that have more than one

use the triggering BUILDKITE_STEP_ID to give us a unique cleanup step key

@toshok Actually since we're not depending on the cleanup step anywhere right now, we could probably just remove the key entirely.

oh that's much easier.  let me do that instead. 👍


Switch from System.Random to a crypto RNG provider

Talk to @GrabYourPitchforks about this and this is a must-fix.
In this code:
https://github.com/aspnet/WebSockets/blob/dev/src/Microsoft.AspNet.WebSockets.Protocol/CommonWebSocket.cs#L92-L112
We need to stop using System.Random and switch to using a proper crypto RNG provider.

@muratg can you find someone to work on this?

ZeroMask is a debug setting so that you can read the data in Netmon. It just makes the masking step a no-op so it should work with any server.

@Tratcher I moved the ZeroMask discussion to https://github.com/aspnet/WebSockets/issues/27 so we could treat it separately.

Is this still relevant @Tratcher @muratg @Eilon ? If so, we should move it to beta6

Yes, moved to beta6.

:+1:

FYI, RNGCryptoServiceProvider is not yet available on CoreCLR, so we'll have to continue using System.Random there. Mono does have a RNGCryptoServiceProvider implementation that uses /dev/random or /dev/urandom on *nix. We'd need to sync up with CoreCLR on the plan for implementing this there.
Is this OK @Eilon @Tratcher @muratg @blowdart ?

I'm fine waiting.

If you're already branching based on OS to use the Mono one, then why not pinvoke if you're on Windows whilst we wait.

Gross :frowning:

Because I will likely introduce more bugginess and spend valuable time?

Per what @anurse said, this would ironically make the behavior of the code even more random :trollface:

A single if statement is more bugginess? I have way more faith in you than that Andrew :D
As gross as it is the RFC specifies PRNGs for a reason and we should make an effort here until CoreCLR catches up.
CryptGenRandom is what you want - https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx?f=255&MSPPError=-2147217396

Don't forget CryptAcquireContext and figuring out which container/provider I'm supposed to use :)

Well yes, but just lift it from 4.6 framework code :p

@Eilon I think I'm going to need to get you to sign-off on doing that :)

I can do it though, it'll just take a bit for me to work out what to pull where and when. What are we going to do on CoreCLR Linux/Mac? Read from /dev/random ourselves?

In Mono use their class, in Linux/Mac ... ummm, abort with notSupported? :D

WebSockets are not supported on CoreCLR Linux/Mac?

If you can't support the RFC's intent should you support it at all?

The framework RNG has a bunch of tendrils through the rest of System.Security.Crypto to support custom CSP Parameters and such. Would it be safe to assume we don't need to support that and can just use the default CSP (i.e. parameterless ctor for RNGCryptoServiceProvider)?

I think it'd do for now, until we can switch to their version.

At the moment it's very difficult for the WebSockets code to detect what kind of CoreCLR it is running on. @davidfowl and I talked and we think the most achievable result for beta6 is to #ifdef and use System.Random on CoreCLR. If that's not acceptable for now, we need to punt this bug to beta7 and work with the CoreCLR team to get either RNGCryptoServiceProvider or Platform-detection logic in ASAP.

Or not support on core? Has anyone talked to coreclr about their timescales?

Heh, I thought that RNGCryptoServiceProvider support had been recently added to CoreCLR?
https://github.com/dotnet/corefx/commit/f394692c7de8cb9e3e9c1b6d3a72ba1196e0d28b
https://github.com/dotnet/corefx/pull/1944

Awesome, we just have to track down if we've got it in DNX now :)

I'm pretty sure there's a package for that: System.Security.Cryptography.RandomNumberGenerator :smile:

Indeed :)

If only our Package Search tool had been updated cough @glennc cough :P


python312Packages.getmac: 0.9.4 -> 0.9.5

Diff: https://github.com/GhostofGoes/getmac/compare/refs/tags/0.9.4...0.9.5
Changelog: https://github.com/GhostofGoes/getmac/blob/0.9.5/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

23 packages built:

home-assistant-component-tests.bosch_shc
home-assistant-component-tests.dlna_dmr
home-assistant-component-tests.mysensors
home-assistant-component-tests.nmap_tracker
home-assistant-component-tests.samsungtv
home-assistant-component-tests.upnp
home-assistant-component-tests.vilfo
python311Packages.boschshcpy
python311Packages.boschshcpy.dist
python311Packages.getmac
python311Packages.getmac.dist
python311Packages.pymysensors
python311Packages.pymysensors.dist
python311Packages.vilfo-api-client
python311Packages.vilfo-api-client.dist
python312Packages.boschshcpy
python312Packages.boschshcpy.dist
python312Packages.getmac
python312Packages.getmac.dist
python312Packages.pymysensors
python312Packages.pymysensors.dist
python312Packages.vilfo-api-client
python312Packages.vilfo-api-client.dist


access lhs as DenseElementsAttr in ElementsAttrBuilder::allEqual

because ElementsAttr cannot access all cpptypes
added lit test which exhibited the problem with f16 element type
moved expensive IsConstOfZeros tests last in const prop pattern constraints
fixes #2344

@tungld can I ask you to review this PR?

Jenkins Linux amd64 Build #11782 [push] access lhs as DenseEleme... started at 02:18

Jenkins Linux s390x Build #11794 [push] access lhs as DenseEleme... started at 03:18

Jenkins Linux amd64 Build #11782 [push] access lhs as DenseEleme... passed after 1 hr 17 min

Jenkins Linux s390x Build #11794 [push] access lhs as DenseEleme... passed after 1 hr 40 min


Add ROS yaml export

Would be useful to be able to export ROS yaml files directly, post-calibration.

Partially solved: https://github.com/i3drobotics/stereo-vision-toolkit/commit/141ddd5f654e79c7e1011be6d3235a6ff7d17b1c
Currently exports by default, should add an option to this.

User can now select this in the calibrate from images dialog. https://github.com/i3drobotics/stereo-vision-toolkit/commit/816ab867540efb999156f9d4a86cdb86774ccb89


Add %check section and build also for Python3

Looks like I turned Python3 builds off in 93d5854 (don't ask me why) and nobody has objected so far.
Let's turn them on again.
It'd also be nice to run tests when building the packages, so here's a %check section.
There are however some packages (e.g. flexmock) missing on rhel/epel so we can run the tests on Fedora only.
We also have to skip (if there's no internet connection) tests that try to access httpbin.org, because there's no connection in koji build environment. Here's example scratch-build build.log

LGTM

LGTM

rebased & merged


Need readme?

Now that we have multiple documents in this repo, should we add a short Readme.md explaining what they are?

Good idea! Can you put in a PR, @p-galligan?

README should point to license, include a brief statement about what's here and what it's for and, if necessary, provide caveats.


--secret-file is optionnal for AWS deployment.

Currently when you issue the install command, it requires you to give a --secret-file argument.
If you deploy on AWS, the aws sdk go might be able to use the kube2iam or instance role if you don't pass this env var.
As it is a possibility, I think the secret-file parameter should be optional and the documentation updated to reflect that.

@pierreozoux Thanks, I've been meaning to file this issue and have a note to make secret-file optional. See #1674 for a discussion of some options. You can currently pass in an empty file, but that's obviously not ideal.
I'll get a PR in for this soon.


Add MindsDB repo with several good first issues

Add MindsDB repo with several good first issues for beginners.
https://github.com/mindsdb/mindsdb

I dunno why is the reason of the conflict i check that and i can't understand

I think it's because there are new changes on main.
If you can't figure it out, feel free to close this PR and send a new one from a new fresh branch.


laravel 5.5 ?

laravel 5.5 ?

waiting

As laravel 5.5 is now released, I will start working on it soon.

@yuandalu @john5db @devaescasio @advisor- @danielpuent3, @jilster @chrisye909 @cyrlx
Hello Guys, I just pushed support for Laravel 5.5 in to develop branch with Datatables 8.0. Also updated docs to for 5.5. (http://labs.infyom.com/laravelgenerator/docs/develop/installation).
I haven't got proper time to test it. Will be testing later today but you guys are most welcome to test it whenever you get time and report any bugs if you found.
Will be waiting to hear you guys :)

@mitulgolakiya
Great!!! and big thanks for this.  Yeah, I've noticed yajra datatables exporting to pdf has errors too.
If you don't mind please make old() works too in your based repository so it could used only 1 fields.blade.php.
Thanks once again,

@devaescasio ok, will check it out and will try to get it fixed.

@mitulgolakiya Very nice, but found that the plurals are wrong for some reason.
For example, if I create a table Noticia related with a Categoria in my DB this is how he output the releationship:
Noticia Model:

Categoria Model:

Any idea why this is happening and how I can solve this ?

To get it to work under 5.5 i had to change ->getQualifiedForeignKeyName() to ->getQualifiedForeignKey() everywhere in BaseRepository->updateRelations.

Closing in Ref of #513


what is it?

Could you add a bit more detail to the README.md? Like what platforms it can be used on and what prerequisites there are before install?

Sure! @spences10 👍
I'm not sure if I should put platforms and install directions, as it's just an open source Twitter bot, this is the code that lets it "learn" from data and tweet it out.

I added more info, check it out 😄

Thanks


Is model split in OPT TP mode?

I tried HF OPT-13b on a 4 GPU machine with tensor-parallel: 4. One observation is all GPUs used the same amount of memory (~25G). It is consistent with other users report. And I also found the memory is as same as the memory used when tensor-parallel: 2. So my question is whether the model is split after it is loaded into CPU memory as said in this thread? My understanding is the memory should be a fourth if the model is split when tensor-parallel: 4 and a second when tensor-paralle: 2.
By the way, I also didn't really find latency reduction when increasing tensor parallel number (the latency only has 2 or 3 ms difference).

Hi @larry-fuy thanks for using MII! I'll assume you're checking memory using with nvidia-smi - if that's the case, you are likely seeing that the total memory usage per GPU includes cached memory that can be freed. This is due to how we are loading and splitting a model across GPUs. I've created a PR that will empty the torch cache after splitting the model and the correct amount of memory usage is now reported. Please try it out: #121
As for the latency, could you share some more details to help me understand your setup?

what GPUs are you running on and how many?
how are you measuring latency?
what are the exact measurements you have?

@mrwyattii  how to get latency using mii api？


user experience

settings: file path bug fix
responsive design
single/album: audio player
social media link

social media links: let user pick icons in admin
album audio player: need an easier way to insert a player