Domoticz features not being added for certain devices

Issue description
Having upgraded to latest v3.1.0 beta some devices have no Domoticz features created even though the device appears in the zigbee2mqtt custom page and api_transport. So far I have:

Deleted zigbee2mqtt from Hardware tab and therefore removed all devices from Domoticz; re-added zigbee2mqtt hardware - same issue
Deleted zigbee2mqtt from Hardware tab, stopped Domoticz, deleted the plugin completely from Domoticz plugins, git cloned fresh plugin, restarted Domoticz, re-added zigbee2mqtt hardware - same issue
Deleted a sensor without any Domoticz devices and re-added via 'pair new device' - same issue

Some of the same model of zigbee sensors have Domoticz devices, some have nothing.  These sensors were all working and recognised prior to the upgrade to v3.1.0 beta.
Looking at the Plugin Configuration tab the devices with no features are missing (see log from plugin configuration in logs section).
Full device list:
Bathroom Light Button	SNZB-01	Wireless button	EndDevice	0x00124b001f8ac44a
* Bathroom PIR	RTCGQ11LM	Aqara human body movement and illuminance sensor	EndDevice	0x00158d0004876875
Bedroom Light	ZBMINI	Zigbee two way smart switch	Router	0x847127fffe95f838
Bedroom Light Button	SNZB-01	Wireless button	EndDevice	0x00124b001f9162d8
Coordinator	N/A	N/A	Coordinator	0x00124b002291d411
Dining Room Light	TS0011	Smart light switch - 1 gang	EndDevice	0x847127fffef7cc8b
* Downstairs Smoke Detector	TS0205	Smoke sensor	EndDevice	0x847127fffe9c1648
* Downstairs Toilet PIR	RTCGQ11LM	Aqara human body movement and illuminance sensor	EndDevice	0x00158d0004514c0e
Electricity Meter	ZHEMI101	Energy meter	EndDevice	0x0015bc001b021c22
* Garage PIR	RTCGQ01LM	MiJia human body movement sensor	EndDevice	0x00158d000632d41c
* Garage_Light	ZBMINI	Zigbee two way smart switch	Router	0x84fd27fffe9280e9
* Hive Controller	SLR2	Dual channel heating and hot water thermostat	Router	0x001e5e090209cd73
Hive Thermostat	SLT3	Heating thermostat remote control	EndDevice	0x001e5e090217847d
J Bedroom Light	ZBMINI	Zigbee two way smart switch	Router	0x847127fffe280f13
J Room Radiator	TS0601_thermostat	Radiator valve with thermostat	EndDevice	0x847127fffe9f2a45
Kitchen PIR	RTCGQ11LM	Aqara human body movement and illuminance sensor	EndDevice	0x00158d00054d2f08
* Landing Smoke Detector	TS0205	Smoke sensor	EndDevice	0x5c0272fffec1b6c0
Living Room Light	ZBMINI	Zigbee two way smart switch	Router	0xb4e3f9fffeb1b388
* Living Room Light Switch	WXKG02LM_rev2	Aqara double key wireless wall switch (2018 model)	EndDevice	0x00158d0003faaa79
* Living Room PIR	RTCGQ11LM	Aqara human body movement and illuminance sensor	EndDevice	0x00158d00054bc5f9
ti Router	ti.router	Texas Instruments router	Router	0x00124b00219fb3b9

Devices marked with a * have no Domoticz features.  Even devices of the same type have some which are OK and some which aren't, for example 00158d00054d2f08 is a RTCGQ11LM PIR which has all its Domoticz features, but 0x00158d0004876875,  0x00158d000632d41c, 0x00158d0004514c0e and 0x00158d00054d2f08 are missing all Domoticz features...
All of the devices appear in the api_transport device, for example:
"friendly_name": "Garage PIR", "ieee_address": "0x00158d000632d41c", "interview_completed": true, "interviewing": false, "manufacturer": "LUMI", "model_id": "lumi.sensor_motion", "network_address": 5685, "power_source": "Battery", "supported": true, "type": "EndDevice"}, {"definition": {"description": "Aqara human body movement and illuminance sensor", "exposes": [{"access": 1, "description": "Remaining battery in %", "name": "battery", "property": "battery", "type": "numeric", "unit": "%", "value_max": 100, "value_min": 0}, {"access": 1, "description": "Indicates whether the device detected occupancy", "name": "occupancy", "property": "occupancy", "type": "binary", "value_off": false, "value_on": true}, {"access": 1, "description": "Measured temperature value", "name": "temperature", "property": "temperature", "type": "numeric", "unit": "\u00b0C"}, {"access": 1, "description": "Voltage of the battery in millivolts", "name": "voltage", "property": "voltage", "type": "numeric", "unit": "mV"}, {"access": 1, "description": "Measured illuminance in lux", "name": "illuminance_lux", "property": "illuminance", "type": "numeric", "unit": "lx"}, {"access": 1, "description": "Measured illuminance in lux", "name": "illuminance", "property": "illuminance", "type": "numeric", "unit": "lx"}, {"access": 1, "description": "Link quality (signal strength)", "name": "linkquality", "property": "linkquality", "type": "numeric", "unit": "lqi", "value_max": 255, "value_min": 0}], "model": "RTCGQ11LM", "supports_ota": false, "vendor": "Xiaomi"}, "endpoints": {"1": {"bindings": [], "clusters": {"input": [], "output": []}
Additional information
Zigbee2MQTT version: 1.21.1 commit: 4a51e0c0
Python version: PluginSystem: Python version '3.7.3'.
Domoticz version: Domoticz V2021.1 (build 13639) (c)2012-2021 GizMoCuz Status: Build Hash: d20f51ba2, Date: 2021-09-29 06:58:52
Plugin version: plugin: v.3.1.0-beta, zigbee2mqtt: v.1.21.1 (zStack3x0 20210319)
Logs
Attach any additional logs here which might be useful: mqtt, domoticz, plugin logs
{
	"aliases": [
		{
			"domoticz": {
				"device_id": "0x847127fffe95f838",
				"legacy_alias": "state",
				"unit": 1
			},
			"zigbee": {
				"address": "0x847127fffe95f838",
				"endpoint": "n/a",
				"feature": "state"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe95f838",
				"legacy_alias": "signal",
				"unit": 2
			},
			"zigbee": {
				"address": "0x847127fffe95f838",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "signal",
				"unit": 1
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "signal"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "cell",
				"unit": 2
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "cell"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "btperc",
				"unit": 3
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "btperc"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "mode",
				"unit": 4
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "mode"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "preset",
				"unit": 5
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "preset"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "week",
				"unit": 6
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "week"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "spoint",
				"unit": 7
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "spoint"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "sp_eco",
				"unit": 8
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "sp_eco"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "sp_cmf",
				"unit": 9
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "sp_cmf"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "temp",
				"unit": 10
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "temp"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "level",
				"unit": 11
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "level"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "wnd",
				"unit": 12
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "wnd"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe9f2a45",
				"legacy_alias": "child",
				"unit": 13
			},
			"zigbee": {
				"address": "0x847127fffe9f2a45",
				"endpoint": "n/a",
				"feature": "child"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00124b00219fb3b9",
				"legacy_alias": "signal",
				"unit": 1
			},
			"zigbee": {
				"address": "0x00124b00219fb3b9",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00124b001f9162d8",
				"legacy_alias": "btperc",
				"unit": 1
			},
			"zigbee": {
				"address": "0x00124b001f9162d8",
				"endpoint": "n/a",
				"feature": "battery"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00124b001f9162d8",
				"legacy_alias": "actio",
				"unit": 2
			},
			"zigbee": {
				"address": "0x00124b001f9162d8",
				"endpoint": "n/a",
				"feature": "action"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00124b001f9162d8",
				"legacy_alias": "signal",
				"unit": 3
			},
			"zigbee": {
				"address": "0x00124b001f9162d8",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffef7cc8b",
				"legacy_alias": "state",
				"unit": 1
			},
			"zigbee": {
				"address": "0x847127fffef7cc8b",
				"endpoint": "n/a",
				"feature": "state"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffef7cc8b",
				"legacy_alias": "signal",
				"unit": 2
			},
			"zigbee": {
				"address": "0x847127fffef7cc8b",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe280f13",
				"legacy_alias": "state",
				"unit": 1
			},
			"zigbee": {
				"address": "0x847127fffe280f13",
				"endpoint": "n/a",
				"feature": "state"
			}
		},
		{
			"domoticz": {
				"device_id": "0x847127fffe280f13",
				"legacy_alias": "signal",
				"unit": 2
			},
			"zigbee": {
				"address": "0x847127fffe280f13",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00124b001f8ac44a",
				"legacy_alias": "btperc",
				"unit": 1
			},
			"zigbee": {
				"address": "0x00124b001f8ac44a",
				"endpoint": "n/a",
				"feature": "battery"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00124b001f8ac44a",
				"legacy_alias": "actio",
				"unit": 2
			},
			"zigbee": {
				"address": "0x00124b001f8ac44a",
				"endpoint": "n/a",
				"feature": "action"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00124b001f8ac44a",
				"legacy_alias": "signal",
				"unit": 3
			},
			"zigbee": {
				"address": "0x00124b001f8ac44a",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0xb4e3f9fffeb1b388",
				"legacy_alias": "state",
				"unit": 1
			},
			"zigbee": {
				"address": "0xb4e3f9fffeb1b388",
				"endpoint": "n/a",
				"feature": "state"
			}
		},
		{
			"domoticz": {
				"device_id": "0xb4e3f9fffeb1b388",
				"legacy_alias": "signal",
				"unit": 2
			},
			"zigbee": {
				"address": "0xb4e3f9fffeb1b388",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0x001e5e090217847d",
				"legacy_alias": "btperc",
				"unit": 1
			},
			"zigbee": {
				"address": "0x001e5e090217847d",
				"endpoint": "n/a",
				"feature": "battery"
			}
		},
		{
			"domoticz": {
				"device_id": "0x001e5e090217847d",
				"legacy_alias": "signal",
				"unit": 2
			},
			"zigbee": {
				"address": "0x001e5e090217847d",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0x0015bc001b021c22",
				"legacy_alias": "power",
				"unit": 1
			},
			"zigbee": {
				"address": "0x0015bc001b021c22",
				"endpoint": "n/a",
				"feature": "power"
			}
		},
		{
			"domoticz": {
				"device_id": "0x0015bc001b021c22",
				"legacy_alias": "signal",
				"unit": 2
			},
			"zigbee": {
				"address": "0x0015bc001b021c22",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00158d00054d2f08",
				"legacy_alias": "temp",
				"unit": 1
			},
			"zigbee": {
				"address": "0x00158d00054d2f08",
				"endpoint": "n/a",
				"feature": "temperature"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00158d00054d2f08",
				"legacy_alias": "btperc",
				"unit": 2
			},
			"zigbee": {
				"address": "0x00158d00054d2f08",
				"endpoint": "n/a",
				"feature": "battery"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00158d00054d2f08",
				"legacy_alias": "motion",
				"unit": 3
			},
			"zigbee": {
				"address": "0x00158d00054d2f08",
				"endpoint": "n/a",
				"feature": "occupancy"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00158d00054d2f08",
				"legacy_alias": "volt",
				"unit": 4
			},
			"zigbee": {
				"address": "0x00158d00054d2f08",
				"endpoint": "n/a",
				"feature": "voltage"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00158d00054d2f08",
				"legacy_alias": "lx",
				"unit": 5d
			},
			"zigbee": {
				"address": "0x00158d00054d2f08",
				"endpoint": "n/a",
				"feature": "illuminance"
			}
		},
		{
			"domoticz": {
				"device_id": "0x00158d00054d2f08",
				"legacy_alias": "signal",
				"unit": 6
			},
			"zigbee": {
				"address": "0x00158d00054d2f08",
				"endpoint": "n/a",
				"feature": "linkquality"
			}
		}
	]
}

domoticz.log for the start-up phase of the plugin:
2021-09-29 07:52:47.555  Status: zigbee2mqtt: (zigbee2mqtt) Entering work loop.
2021-09-29 07:52:47.555  zigbee2mqtt hardware started.
2021-09-29 07:52:47.555  Status: zigbee2mqtt: (zigbee2mqtt) Started.
2021-09-29 07:52:47.983  Status: zigbee2mqtt: (zigbee2mqtt) Initialized version 3.1.0-beta
2021-09-29 07:52:47.986  zigbee2mqtt: (zigbee2mqtt) Debug logging mask set to: PYTHON
2021-09-29 07:52:47.987  zigbee2mqtt: (zigbee2mqtt) Installing plugin custom page...
2021-09-29 07:52:47.987  zigbee2mqtt: (zigbee2mqtt) Copying files from /home/pi/domoticz/plugins/zigbee2mqtt/frontend to /home/pi/domoticz/www/templates
2021-09-29 07:52:48.010  zigbee2mqtt: (zigbee2mqtt) Installing plugin custom page completed.
2021-09-29 07:52:48.010  zigbee2mqtt: (zigbee2mqtt) MqttClient::__init__
2021-09-29 07:52:48.010  zigbee2mqtt: (zigbee2mqtt) MqttClient::open
2021-09-29 07:52:48.063  zigbee2mqtt: (zigbee2mqtt) onConnect called
2021-09-29 07:52:48.063  zigbee2mqtt: (zigbee2mqtt) Connected to MQTT Server: <IP_ADDRESS>:1883
2021-09-29 07:52:48.063  zigbee2mqtt: (zigbee2mqtt) MQTT CLIENT ID: 'Domoticz_1632898368_9499'
2021-09-29 07:52:48.114  zigbee2mqtt: (zigbee2mqtt) MqttClient::subscribe
2021-09-29 07:52:48.165  zigbee2mqtt: (zigbee2mqtt) Subscribed to "zigbee2mqtt/#" topic
2021-09-29 07:52:48.166  zigbee2mqtt: (zigbee2mqtt) Zigbee2mqtt bridge is online
2021-09-29 07:52:48.166  zigbee2mqtt: (zigbee2mqtt) Zigbee2mqtt log level is info
2021-09-29 07:52:48.166  zigbee2mqtt: (zigbee2mqtt) Joining new devices is disabled on the zigbee bridge
2021-09-29 07:52:48.172  zigbee2mqtt: (zigbee2mqtt) Received available devices list from bridge
2021-09-29 07:52:48.172  zigbee2mqtt: (zigbee2mqtt) Coordinator address is 0x00124b002291d411
2021-09-29 07:52:48.173  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe95f838(state)
2021-09-29 07:52:48.173  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.173  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "state" key for device with ieeeAddr 0x847127fffe95f838
2021-09-29 07:52:48.177  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe95f838(signal)
2021-09-29 07:52:48.177  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.177  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x847127fffe95f838
2021-09-29 07:52:48.181  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(signal)
2021-09-29 07:52:48.182  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.182  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.186  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(cell)
2021-09-29 07:52:48.186  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.186  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "battery_voltage" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.191  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(btperc)
2021-09-29 07:52:48.191  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.191  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "battery" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.196  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(mode)
2021-09-29 07:52:48.196  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.196  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "system_mode" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.202  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(preset)
2021-09-29 07:52:48.202  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.202  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "preset" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.209  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(week)
2021-09-29 07:52:48.209  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.209  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "week" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.215  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(spoint)
2021-09-29 07:52:48.216  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.216  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "current_heating_setpoint" key for device with ieeeAddr 0x847127fffe9f2a4                                                5
2021-09-29 07:52:48.222  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(sp_eco)
2021-09-29 07:52:48.222  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.222  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "eco_temperature" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.229  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(sp_cmf)
2021-09-29 07:52:48.229  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.229  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "comfort_temperature" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.237  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(temp)
2021-09-29 07:52:48.237  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.237  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "local_temperature" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.245  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(level)
2021-09-29 07:52:48.245  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.245  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "position" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.253  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(wnd)
2021-09-29 07:52:48.253  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.253  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "window_detection" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.261  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe9f2a45(child)
2021-09-29 07:52:48.262  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.262  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "child_lock" key for device with ieeeAddr 0x847127fffe9f2a45
2021-09-29 07:52:48.271  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00124b00219fb3b9(signal)
2021-09-29 07:52:48.271  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.271  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x00124b00219fb3b9
2021-09-29 07:52:48.280  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00124b001f9162d8(btperc)
2021-09-29 07:52:48.280  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.280  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "battery" key for device with ieeeAddr 0x00124b001f9162d8
2021-09-29 07:52:48.290  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00124b001f9162d8(actio)
2021-09-29 07:52:48.290  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.290  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "action" key for device with ieeeAddr 0x00124b001f9162d8
2021-09-29 07:52:48.300  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00124b001f9162d8(signal)
2021-09-29 07:52:48.300  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.300  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x00124b001f9162d8
2021-09-29 07:52:48.311  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffef7cc8b(state)
2021-09-29 07:52:48.311  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.311  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "state" key for device with ieeeAddr 0x847127fffef7cc8b
2021-09-29 07:52:48.321  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffef7cc8b(signal)
2021-09-29 07:52:48.321  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.322  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x847127fffef7cc8b
2021-09-29 07:52:48.333  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe280f13(state)
2021-09-29 07:52:48.333  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.333  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "state" key for device with ieeeAddr 0x847127fffe280f13
2021-09-29 07:52:48.344  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x847127fffe280f13(signal)
2021-09-29 07:52:48.344  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.344  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x847127fffe280f13
2021-09-29 07:52:48.356  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00124b001f8ac44a(btperc)
2021-09-29 07:52:48.356  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.356  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "battery" key for device with ieeeAddr 0x00124b001f8ac44a
2021-09-29 07:52:48.368  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00124b001f8ac44a(actio)
2021-09-29 07:52:48.368  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.369  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "action" key for device with ieeeAddr 0x00124b001f8ac44a
2021-09-29 07:52:48.381  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00124b001f8ac44a(signal)
2021-09-29 07:52:48.381  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.381  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x00124b001f8ac44a
2021-09-29 07:52:48.395  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0xb4e3f9fffeb1b388(state)
2021-09-29 07:52:48.395  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.395  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "state" key for device with ieeeAddr 0xb4e3f9fffeb1b388
2021-09-29 07:52:48.408  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0xb4e3f9fffeb1b388(signal)
2021-09-29 07:52:48.408  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.408  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0xb4e3f9fffeb1b388
2021-09-29 07:52:48.422  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x001e5e090217847d(btperc)
2021-09-29 07:52:48.422  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.422  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "battery" key for device with ieeeAddr 0x001e5e090217847d
2021-09-29 07:52:48.436  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x001e5e090217847d(signal)
2021-09-29 07:52:48.437  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.437  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x001e5e090217847d
2021-09-29 07:52:48.452  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x0015bc001b021c22(power)
2021-09-29 07:52:48.452  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.452  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "power;energy" key for device with ieeeAddr 0x0015bc001b021c22
2021-09-29 07:52:48.467  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x0015bc001b021c22(signal)
2021-09-29 07:52:48.467  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.467  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "linkquality" key for device with ieeeAddr 0x0015bc001b021c22
2021-09-29 07:52:48.483  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00158d00054d2f08(temp)
2021-09-29 07:52:48.483  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.483  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "temperature" key for device with ieeeAddr 0x00158d00054d2f08
2021-09-29 07:52:48.498  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00158d00054d2f08(btperc)
2021-09-29 07:52:48.498  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.498  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "battery" key for device with ieeeAddr 0x00158d00054d2f08
2021-09-29 07:52:48.514  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00158d00054d2f08(motion)
2021-09-29 07:52:48.514  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.514  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "occupancy" key for device with ieeeAddr 0x00158d00054d2f08
2021-09-29 07:52:48.530  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00158d00054d2f08(volt)
2021-09-29 07:52:48.531  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.531  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "voltage" key for device with ieeeAddr 0x00158d00054d2f08
2021-09-29 07:52:48.547  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00158d00054d2f08(lx)
2021-09-29 07:52:48.547  zigbee2mqtt: (zigbee2mqtt) No such device found
2021-09-29 07:52:48.547  zigbee2mqtt: (zigbee2mqtt) Creating domoticz device to handle "illuminance" key for device with ieeeAddr 0x00158d00054d2f08
2021-09-29 07:52:48.566  zigbee2mqtt: (zigbee2mqtt) Trying to get legacy device 0x00158d00054d2f08(signal)
2021-09-29 07:52:48.566  zigbee2mqtt: (zigbee2mqtt) No such device found

Hi @stas-demydiuk  I have identified the problem which is how features are handled in adapter.py.. there were two issues:

Error: zigbee2mqtt: (zigbee2mqtt) Hive_Controller: can not process binary item "temperature_setpoint_hold"
This needed an entry creating to handle this as an on/off switch;
temperature_setpoint_hold_duration  is a numeric value but has no unit as its just a number, so the code fails with
Error: zigbee2mqtt: (zigbee2mqtt) 'onMessage' failed 'KeyError':'('unit',)'. as it assumes all keys with setpoint in them contain a unit, so I added a try/except to read feature['unit'] and add as a custom value in the except.

All devices identified after the failure of temperature_setpoint_hold_duration  were therefore not processed which is why they don't have any features.
I have fixed these issues on my local branch but don't have permission to push to create a PR - can you give me permission to do so please?

As I can't create a PR I created a diff patch so you can check and apply if you're happy with the changes...
git diff adapter.py ~/adapter.py
diff --git a/adapter.py b/home/pi/adapter.py
index 9e96e39..420bf13 100644
--- a/adapter.py
+++ b/home/pi/adapter.py
@@ -171,6 +171,11 @@ class UniversalAdapter(Adapter):
             self._add_device(alias, feature, ContactSensor, ' (Consumer Connected)')
             return

+        if (feature['name'] == 'temperature_setpoint_hold' and state_access and write_access):
+            alias = self._generate_alias(feature, 'temphld')
+            self._add_device(alias, feature, OnOffSwitch)
+            return
+
         if (feature['name'] == 'state' and state_access and write_access):
             alias = self._generate_alias(feature, 'state')
             self._add_device(alias, feature, OnOffSwitch)
@@ -257,16 +262,25 @@ class UniversalAdapter(Adapter):
             self._add_device(alias, feature, CurrentSensor, ' (Current)')
             return

-        if 'setpoint' in feature['name'] and feature['unit'] == '<C2><B0>C' and write_access:
-            alias = self._generate_alias(feature, 'spoint')
-            self._add_device(alias, feature, SetPoint, ' (Setpoint)')
+        if 'setpoint' in feature['name']:
+            try:
+                unit=feature['unit']
+            except:
+                unit=''
+
+            if unit == '<C2><B0>C' and write_access:
+                alias = self._generate_alias(feature, 'spoint')
+                self._add_device(alias, feature, SetPoint, ' (Setpoint)')
+            elif unit == '':
+                alias = self._generate_alias(feature, 'duration')
+                self._add_device(alias, feature, CustomSensor, ' (Hold Duration)')
             return

         if (feature['name'] == 'position' and state_access):
             alias = self._generate_alias(feature, 'level')
             self._add_device(alias, feature, LevelSwitch)
             return
-
+
         if (feature['name'] == 'color_temp_startup' and state_access):
             return

Hi, even though this was about sensors, do you think the root cause is the same as here: https://github.com/stas-demydiuk/domoticz-zigbee2mqtt-plugin/issues/707

Possibly - what I had in the logs which I'd dismissed as irrelevant was
2021-09-28 12:51:00.435  Error: zigbee2mqtt: (zigbee2mqtt) Hive Controller: can not process binary item "temperature_setpoint_hold"
2021-09-28 12:51:00.435  Error: zigbee2mqtt: (zigbee2mqtt) 'onMessage' failed 'KeyError':'('unit',)'.
2021-09-28 12:51:00.435  Error: zigbee2mqtt: (zigbee2mqtt) Exception traceback:
2021-09-28 12:51:00.435  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 298 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/plugin.py', function onMessage
2021-09-28 12:51:00.435  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 137 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/plugin.py', function onMessage
2021-09-28 12:51:00.436  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 167 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/mqtt.py', function onMessage
2021-09-28 12:51:00.436  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 166 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/plugin.py', function onMQTTPublish
2021-09-28 12:51:00.436  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 45 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/devices_manager.py', function set_devices
2021-09-28 12:51:00.436  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 47 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/adapter.py', function __init__
2021-09-28 12:51:00.436  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 59 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/adapter.py', function _add_features
2021-09-28 12:51:00.436  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 71 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/adapter.py', function _add_feature
2021-09-28 12:51:00.436  Error: zigbee2mqtt: (zigbee2mqtt) ----> Line 260 in '/home/pi/domoticz/plugins/zigbee2mqtt-plugin/adapter.py', function add_numeric_device

but actually this caused the feature creation to stop for any devices after/including the Hive Controller device, so it could be the same for your devices - as @stas-demydiuk asked in #707 what do you see in the domoticz.log?  If you see adapter.py messages in the domoticz.log its probably a similar condition which needs trapping / handling in the code...
I would say remove the plugin (Delete it from Devices), re-add the plugin again (to ensure all devices cleared) and then ensure you capture the zigbee2mqtt messages from the log - I have Domoticz logging to /var/log/domoticz.log so its easy to cat the log and grep for a pattern (eg cat /var/log/domoticz.log | grep adapter.py)....  adapter.py is where the features get added so if there's an issue its likely to be in that class...

@russdan, anyone could create a PR to this repo, you just need to fork it, push your changes to the fork and then create a PR

DIYRuZ_Flower still do not show soil_moisture       DIYRuZ_Geiger still do not show radioactive_events_per_minute etc.
thank you


Long compilation time of ASR models

We're not able to compile the model in days, something goes wrong. Probably have bad configurations for some dispatches, which introduces many operations. File a bug for tracking it.

Looks like it stuck in iree-stream-refine-usage pass

Fixed by https://github.com/iree-org/iree/pull/10487


general code cleanup

used atom-beautify to cleanup some code. Requested as part of
hacktoberfest.

@A1fus Thanks, but those documentation files are generated automatically by scripts in ./contrib directory and they shouldn't be edited manually so sorry, we can't merge this.
If you are looking for some other low hanging fruit you can go over the docs, I'm pretty sure there are plently of typos and grammar errors which need to be fixed :)

@kami Okay thanks not an issue.


On order items are being marked as available

See the very last item in this list: https://bibdata-alma-staging.princeton.edu/bibliographic/9939075533506421/holdings/22194161030006421/availability.json
It is an item that is on order.  I do not believe its status should be Available.  Is there a reason it is marked as available?

Also the case for "In Process" items https://bibdata-alma-staging.princeton.edu/bibliographic/99122455086806421/holdings/22477860740006421/availability.json
In Voyager "On-Order" = Alma "Acquisition"
In Voyager "In Process" = Alma "Acquisitions and Cataloging"


Superscript and Subscript do not render in a Markdown card

Issue Summary
When trying to insert a superscript or subscript in a Markdown card within the editor, the ^test^ and ~test~ do not render their expected results.
To Reproduce

Create a new post
Select a Markdown card from the "+" menu
Type in the markdown for either superscript (^supertext^) or subscript (~subtext~)
Observe that neither bits of text are transformed.

That said, both do work in the regular editor using Markdown.
Technical details:

Ghost Version: v3.33.0
Database mysql

I will look into working on this

This seems to remain an open problem, using the normal~subscript~ syntax renders subscript in the editor but not the published page.

This seems to remain an open problem, using the normal~subscript~ syntax renders subscript in the editor but not the published page.

I noticed this as well. I've put in a pull request to fix this issue: Koenig/#400.


Use the real kubeconfig path in $KUBECONFIG note

We say
Note: For kubectl to work, please set $KUBECONFIG to $HOME/go/src/github.com/kinvolk/kube-spawn/.kube-spawn/default/kubeconfig.

But my $GOPATH is in $HOME/work/go. Can we do better and give the actual path where kubeconfig is?

Closed via https://github.com/kinvolk/kube-spawn/pull/112


get() now returns the same array object unless the wallets have changed

Summary
This is important for the next PR in this stack. Returning the same array from this getter if the wallets haven't change unlocks opportunities to memoize downstream code.
Test plan
cd packages/examples/react
pnpm start
open http://localhost:1234

Observed the example app load and find my browser's wallets.


How to use nzCustomFilter in table when fetch data from remote server

What problem does this feature solve?
I have a table, data fetch from remote server, and use server side filter
<th
        nzCustomFilter
        nzColumnKey="birthday"
        nzWidth="10%"
        [nzSortFn]="true"
        [nzFilterFn]="true"
      >
        Birthday
        <nz-filter-trigger
          [(nzVisible)]="birthdaySearchVisible"
          [nzActive]="false"
          [nzDropdownMenu]="dateSearchMenu"
        >
          <i nz-icon nzType="search"></i>
        </nz-filter-trigger>
      </th>

Any example for nzCustomerFilter ?
What does the proposed API look like?
no

Thanks

https://ng.ant.design/components/table/zh#components-table-demo-custom-filter-panel
pass the searchValue to your server


KIM Integration - Volume support and worker group name

Description
Changes proposed in this pull request:

support for volume size, volume type default values
support of worker group name (hard-wired)
volume size populated from parameters (if present)

Related issue(s)

#791
#905

What do you think about adding consts for all repeating values? I would like to know more about the origin of values, let's have a short call.

It is supposed to be next step in the refactoring. We are working on test in small increments, still a lot to cover and improve.


ioc_detections

Insider Threat Detection ESCU - Information Sabotage

high_frequency_copy_of_files_in_network_share.yml

Emerging Threat IOC

csc__net_on_the_fly_compilation.yml
firewall_allowed_program_enable.yml
network_discovery_using_route_windows_app.yml
runas_execution_in_commandline.yml
suspicious_process_dns_query_known_abuse_web_services.yml
loading_of_dynwrapx_module.yml

process macro

macros/process_csc.yml
macros/process_route.yml
macros/process_runas.yml

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Network Discovery Using Route Windows App :x:

diskUsage: 483328
runDuration: 1.942s
scanCount: 1

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Network Discovery Using Route Windows App :x:

diskUsage: 434176
runDuration: 1.926s
scanCount: 1

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Runas Execution in CommandLine :x:

diskUsage: 581632
runDuration: 2.309s
scanCount: 124

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
High Frequency Copy Of Files In Network Share :white_check_mark:

diskUsage: 237568
runDuration: 1.105s
scanCount: 100

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Firewall Allowed Program Enable :white_check_mark:

diskUsage: 503808
runDuration: 4.752s
scanCount: 4687

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
CSC Net On The Fly Compilation :white_check_mark:

diskUsage: 602112
runDuration: 2.573s
scanCount: 6

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Network Discovery Using Route Windows App :white_check_mark:

diskUsage: 421888
runDuration: 2.376s
scanCount: 4687

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Runas Execution in CommandLine :white_check_mark:

diskUsage: 417792
runDuration: 3.571s
scanCount: 2217

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Suspicious Process DNS Query Known Abuse Web Services :white_check_mark:

diskUsage: 442368
runDuration: 2.137s
scanCount: 70

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Loading Of Dynwrapx Module :x:

diskUsage: 172032
runDuration: 1.647s
scanCount: 1

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Loading Of Dynwrapx Module :x:

diskUsage: 172032
runDuration: 1.095s
scanCount: 1

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Loading Of Dynwrapx Module :x:

diskUsage: 172032
runDuration: 1.103s
scanCount: 1

This PR was created by Automated Detection Testing Service :robot:
Tested detections:
Loading Of Dynwrapx Module :white_check_mark:

diskUsage: 176128
runDuration: 1.198s
scanCount: 5


Show FailedScheduling issues in the Start Modal

Resolves: #528
Description

The modal start time is not an accurate enough time to use. We need the immutable activity time from the Notebook to tell us when it was requested to do something. This way if there are events that are immediate, we can get those. The FailedScheduling error that prevents you from spinning up a Notebook when your size is too large happens before the modal opens so we didn't show it (to avoid showing previous attempt events).

How Has This Been Tested?

Using x-large size time from the defaults and not having the space on-cluster for it.
Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work

I will always get a null for my first event time when starting the notebook.

Can you also update here https://github.com/opendatahub-io/odh-dashboard/blob/main/frontend/src/pages/notebookController/screens/server/StartServerModal.tsx#L165 to
event.lastTimestamp || event.eventTime in case of null timestamp in the logs?


Highlight the active dataset

We can't see which dataset is active, so we should apparently highlight the active dataset.

Resolved in: https://github.com/t29mato/starry-digitizer/pull/164


man_made=water_well areas show up weirdly

man_made=water_well can apparently (rarely) be mapped as an area, not just as a point. And that isn't handled well by the map; it shows each individual node in the way as a separate item.
Screenshot

Link to where this issue occurs on OpenInfraMap
https://openinframap.org/#14.88/42.4984/-71.41625/L,W
Link to the corresponding entity on OpenStreetMap
https://www.openstreetmap.org/way/29776473#map=16/42.49735/-71.42119&layers=D

This is now fixed but caching means it may take a while to disappear.


set default value to numKeysToRead->1500000,numKeysToWrite->2000000 for YSQL and YCQL

Fixed : https://github.com/yugabyte/yugabyte-db/issues/7193
Test case:

Ran sample application and validated docker container exits once it completes read(default) and write(default) operations, it does not keep running, tested for both YSQL and YCQL

@gurushant-yb , @Arnav15 -- the PR / description doesn't clarify the old behavior. What was the old defaults for these values?
cc: @nmantrav2 , @rao-vasireddy , @rkarthik007 .

@gurushant-yb , @Arnav15 -- the PR / description doesn't clarify the old behavior. What was the old defaults for these values?
cc: @nmantrav2 , @rao-vasireddy , @rkarthik007 .

I have updated the PR description , and for more details you may visit to the linked issue.

Hey @gurushant-yb - any reason we don't change the default launch command in the docker container? I am ok with this, but was curious about this change.

Hey @gurushant-yb, After you land the changes, we'll need to release a new version of yb-sample-apps. I can work with you on releasing the new jar to maven central, I'll walk you through the steps.
Once we release the new version of yb-sample-apps, I believe we will need to make changes in platform UI to use the latest sample app.


issue in swagger with TriggerLimits

    "TriggerLimits": {
        "description": "Limits on a specific trigger"
    },

I think it should have "type": "object" as it apparently returns arbitrary json?

reference: https://github.com/openwhisk/openwhisk/blob/master/core/controller/src/resources/whiskswagger.json

Thanks for catching you're absolutely right


chore: release v1.0.0-alpha.2

Changes in preparation for our second alpha release of v1.0.0:

CHANGELOG rendered
Manual E2E run

IMPORTANT:
The first commit of this PR is manually undoing the unclog release that was performed for v1.0.0-alpha.1 (#1710). In our release process, pre-releases do not have their own section in the changelog, so we must not run unclog release when cutting pre-releases (see RELEASES.md).
Therefore, it is advised to exclude the first commit from the diff view when reviewing this PR.

PR checklist

[ ] Tests written/updated
[ ] Changelog entry added in .changelog (we use unclog to manage our changelog)
[ ] Updated relevant documentation (docs/ or spec/) and code comments
[ ] Title follows the Conventional Commits spec

#2327 should be part of the QA process, so we need to backport it to v1.x and include it in this release.


Failed git delete, error 218, "Directory banana-social is not empty and can't be removed"

Keybase GUI Version: 4.5.0-20190919001132+93e889ab01
Attempted to clone git repo in GitHub and received error 218 (worktree). Tried deleting repo in Keybase and get error that directory isn't empty. Get same error using CLI. Happened on two Keybase repos that were new and had never cloned or used at all.

If you do a keybase log send, and post the resulting ID here, I can take a look.

First attempt, tried to send the log but received the following error in the terminal: ERROR API network error: Post https://api-0.core.keybaseapi.com/_/api/1.0/logdump/send.json: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Second attempt, same error.

Hmm ok sorry.  A few more attempts might eventually work, but no worries.  If you have file system integration enabled with your operating system (not sure what platform you're on), you can try navigating to the corresponding directory that holds the git repos from the terminal.  For example, if the repo is in keybase://private/ryanstraight and you're on linux or macOS, go to /keybase/private/ryanstraight.
From there:
cd .kbfs_git/.kbfs_deleted_repos

Then you can try renaming the directory in there to something else, like broken_repo maybe.  If the repo you deleted was super old (back from when we first announced git) it might have a known bug where there was an undeletable . file in it, but renaming it to a different file name scheme should work ok.

Worked like a charm. Thanks!


Add support for go modules.

This PR does 4 things:

Adds support for Go modules
Moves the build from Travis to CircleCI
Fixes a race condition that appeared in the tests.
Fixes the local import pathes (mwitkow/go-flagz -> improbable-eng/go-flagz) because it is a recently forked library.

is this going in / still being worked on / maintained?


#eof? method returning wrong value when it's used on a csv file

Ruby version : 3.1.2p20, as well as 2.7.4p191 (replit)
Steps to reproduce the issue(?) :

Open a csv file with CSV.open('file.csv')
Call #pos on it, it returns 0
Call #eof? on it, it returns false
Call #read on it
Call #pos on it, it returns the last position
Call #eof? on it, it returns false when it should be true

It seems to return true if #eof? isn't called before reading the file. (i.e: omit the third line above)
Demonstration : https://replit.com/@Jee-El/Ruby-CSV-eof-issue?v=1

Could you paste main.rb and attach event_attendees.csv here for easy to refer?

main.rb
require 'csv'

# it returns true on the second call of #eof? as expected only if
# I comment the 4th line, starting from the line below this
puts 'csv'
csv = CSV.open('event_attendees.csv')
puts "pos : #{csv.pos}" # expecting 0
puts "eof? : #{csv.eof?}" # expecting false
csv.read
puts "pos : #{csv.pos}" # expecting 1814
puts "eof? : #{csv.eof?}" # expecting true
puts

# no issue when using File.open
puts 'File'
file = File.open('event_attendees.csv')
puts "pos : #{file.pos}" # expecting 0
puts "eof? : #{file.eof?}" # expecting false
file.read
puts "pos : #{file.pos}" # expecting 1814
puts "eof? : #{file.eof?}" # expecting true

event_attendees.csv

Thanks. I've fixed this.


TektonHub Tasks apiversion v1beta1 not supported with new pipeline release v0.43.0

Expected Behavior
tkn hub install task [task-from-hub] succeeds with task installed.
Actual Behavior

tkn hub install task kaniko
Error: the API version in the data (tekton.dev/v1beta1) does not match the expected API version (tekton.dev/v1)

Steps to Reproduce the Problem

minikube start --kubernetes-version v1.24.4 (install k8s)
kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml (install latest tekton)
tkn hub install task [some-hub-task]

Additional Info

Kubernetes version: 1.24.4
Output of kubectl version:

kubectl version --short
Client Version: v1.25.4
Kustomize Version: v4.5.7
Server Version: v1.24.4

- Tekton Pipeline version:

Client version: 0.27.0
Pipeline version: v0.43.0
also attempted with upgraded tektoncd-cli:
Client version: 0.28.0
Pipeline version: v0.43.0

Further testing needs to take place but even with all tasks updated to appropriate apiversion, 'v1' the aforementioned error "Error: the API version in the data (tekton.dev/v1beta1) does not match the expected API version (tekton.dev/v1)" still occurs when attempting to run pipeline. So in essence nothing seems to work for me now.

This should probably be a cli issue or a hub issue. We do have https://github.com/tektoncd/cli/issues/1837 on cli to track this.
/cc @tektoncd/hub-maintainers

Yes , I'm facing the same issue when I tried to run on minikube  "tkn hub install task git-clone
Error: the API version in the data (tekton.dev/v1beta1) does not match the expected API version (tekton.dev/v1) , which any one can help

Hello I also has the issue with tekton 0.43.0, I downgrade to version 0.42.0 and it worked again.
tkn version
Client version: 0.29.0
Pipeline version: v0.42.0

Hi , Can i please get update on this as we are completely blocked with this reported issue.

Hi @sivachandran-s, the fix for this is tracked in https://github.com/tektoncd/cli/issues/1837. As a workaround for now, you can start pipelineruns/taskruns by using kubectl to apply yaml directly to the cluster, and install hub tasks by applying the task yaml directly to the cluster with kubectl. Downgrading your pipelines version should also fix this problem.

Hi @lbernick thank you, I will try out the steps as you suggested.

I think this can be closed as the linked CLI issue has been addressed.


circe 0.9.3

Looks like this has merge conflicts

@blast-hardcheese  Conflict resolved.

Nice, thanks!


V4

-Uses MyQ V4 API
-Scheduling fix
-Additional sensor can trigger a refresh
-runscope.com troubleshooting for untested devices
-Goodbye mode can select the doors now

-Uses MyQ V4 API
-Scheduling fix
-Additional sensor can trigger a refresh
-runscope.com troubleshooting for untested devices
-Goodbye mode can select the doors now


rustfmt can delete comments within an attribute

source:
#[derive(A,
    B,
    C,
    D,
    // E,
)]
fn foo() {
    bar(1,
        2,
        3,
        4,
        // 5,
    );
}

post-rustfmt:
#[derive(A, B, C, D)]
fn foo() {
    bar(
        1, 2, 3, 4,
        // 5,
    );
}

I would expect something like:
#[derive(
    A, B, C, D,
    // E,
)]
fn foo() {
    bar(
        1, 2, 3, 4,
        // 5,
    );
}

I'd be happy to submit a PR for this.

I'd be happy to submit a PR for this.

Awesome, thank you! Don't feel obligated to look into this by any means, but there's another issue with derives where they get dropped when malformed (#4029/#3898), and the respective fixes would likely touch a lot of the same code.

@calebcartwright ok, I fixed all three.

Awesome! Thank you so much @ahl :tada:


scripts: unify unit testing

The idea behind these changes is to have a single place for scripts unit testing. As of today, there are at least two places where one can find pytest based tests: tests and west_commands/tests. dts also has its own set of tests, but it looks like it will be moved to a standalone library so I haven't done anything there. Having a single place for tests makes things easier, for things such as: shared fixtures, single entry point for CI, etc.

Putting a -1 on this for now as I don't think a common folder is necessarily the right thing.
These scripts have different requirements on their test environments and I think it's good that they are allowed to differ.

The idea is to have a folder for the common cases, that does not force people to use it (e.g. dts has its own set of tests). I think pytest is flexible enough to accommodate different needs, e.g. we can have tags, multiple conftest.py for fixtures/specifics that only apply to tests on a subfolder, etc.
What I'd like is to have a place to add my test_x.py unit-test suite and see that CI exercises it without more effort. Stuff like scripts/west_commands/run_tests.py or a custom README.md for twister tests makes things unnecessarily complex and more difficult to maintain. If we talk about system-level testing, then I understand that requirements may be more diverse and it may justify a completely separate CI/test suite.

OK, then I don't think the west command tests belong in the common folder :)
Have you considered using tox instead?

OK, then I don't think the west command tests belong in the common folder :)

they can be left alone then, but having something like scripts/west_commands/run_tests.py raises my eyebrows. In the end, one can always do pytest tests/west_commands to just run west_commands tests. I still don't see why they have specific needs.

Have you considered using tox instead?

I'm not a fan of tox, but it can be added to have the "run tox to check all" as an optional thing. If there is intereset in moving this forward I can add it, otherwise I'll need to create yet another workflow to handle some tests I'm planning to add and that do not fit in any of the current setups as they are specific to either west_commands or twister.

having something like scripts/west_commands/run_tests.py raises my eyebrows.

Yeah, I agree it's weird. I added it because I wanted it to be easy for people to run the tests on their local machines in both Windows and Linux.


Added mosaic envelop icon and tooltips for transaction list.

Feat

Added 2 new icons, mosaics, and envelop.
Added tooltips for mosaics icon (show top 5 mosaics, the rest will be replaced by add x more ...)
Added tooltips for the message (show length 40, the rest will be replaced by ...)
Amount column will only show XYM amount, else will leave it empty with the mosaics icon.

Resolved: #1090

close this PR, refer here https://github.com/nemgrouplimited/symbol-desktop-wallet/pull/1549


Update example.py

I understand that you're making this change to the example to support environments where a user might have pre-configured their SparkContext in a kernel.json, startup-script, etc. Can you add a comment above the if-statement you added to explain why it's there?

Change made


CORGI-746 - refactor latest component filter into pg stored proc

will need to adjust for type (as per https://github.com/RedHatProductSecurity/component-registry/pull/562)


Add an admin interface

there should be an admin page that.  only users with admin permissions can ansswer.
Ideally this admin interface can be generated automatically. A script reads the prismsa.schema file and generates all admin pages automatically.
The views will be essentially the same for all models; that is an index file with a table and a search functionality, and an item page which is essentially a form that includes form fields for parent, children, json, lisst and other complex fields.
with the exception of the shopping cart and the blog views which need some customization so that they can be used by the staff with ease.
for the blog view use this:
https://mdxeditor.dev/

Add pages for

categories
subcategories
products
leads
orders
carts
users
coupons

Add translation inputs in the admin form. These will have. little lang dropdown toward the right, allowing the user to input different values for different langs

Add an image input. Recycle and improve image input from torus commerce

make certain fields uneditable:

id
sku
createdAt
updatedAt
createdBy
updatedBy

add admin/products/new page that has a form input to create a new product.

add option to delete a product, both in the list view and in the product view. Should dipslay a confirmation dialog before deleting

in the automate cli, create a script that will generate the entire admin interface including all dircetories and pages with the corresponding components.

products

page.tsx
[id]/page.tsx
new/page.tsx


Module version checking

Emit symbols in the binary which let the linker issue an error if the swiftmodule file does not match the generated archive/dylib.
Store an MD5 hash in the swiftmodule file and generate a symbol in the binary which encodes that hash.
For each imported module, reference the module hash symbol.
If the swiftmodule does not match, the linker will issue an undefined-symbol error.
Of course, this is only done for modules which are not compiled with library evolution.
In the current implementation version checking only works with whole-module-compilation.
The reason for this feature is that I spent too many days of my life with debugging horrible crashes which turned out to be just such version mismatches.

@slavapestov, @DougGregor What do you think about this?

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

How to change the base branch: (Link)
More detail about the branch update: (Link)


Ensure Quantity.unit setting rules are printed after Quantity setting rules

Addresses CIMPL-639, ensuring that Quantity.unit setting rules are exported after Quantity setting rules to prevent unexpected overwrites of the unit field. A switchQuantityRules function has been added that's called during export by ExportableInstance, ExportableProfile, and ExportableExtension. This function simply iterates through the rules on these SDs and moves whole Quantity-setting rules to be just before Quantity.unit-setting rules.

So I made some bold moves! When Instances are processed, each individual property of a Quantity gets its own assignment rule. For example, if we process this element within an instance...
  "valueQuantity": {
    "unit": "C",
    "value": 36.5,
    "system": "http://unitsofmeasure.org",
    "code": "Cel"
  }

In lieu of an Optimizer, this will yield the following assignment rules:
* valueQuantity.unit = "C"
* valueQuantity.value = 36.5
* valueQuantity.system = "http://unitsofmeasure.org"
* valueQuantity.code = Cel

The above is actually valid FHIR, as an overwrite would only happen when the CombineCodingAndQuantityValuesOptimizer runs and merges the  latter three rules into one, giving us this:
* valueQuantity.unit = "C"
* valueQuantity= 36.5 'C'

In this case, the first rule setting the unit property will be overwritten. With this in mind, I actually thought it would be better to update the CombineCodingAndQuantityValuesOptimizer to include each property of the Quantity into a single assignment rule on Instances. Given the changes that we're making on the sushi side to broaden support for non-UCUM systems on quantities, I thought that this would be okay to do.

So I made some bold moves! When Instances are processed, each individual property of a Quantity gets its own assignment rule. For example, if we process this element within an instance...
  "valueQuantity": {
    "unit": "C",
    "value": 36.5,
    "system": "http://unitsofmeasure.org",
    "code": "Cel"
  }

In lieu of an Optimizer, this will yield the following assignment rules:
* valueQuantity.unit = "C"
* valueQuantity.value = 36.5
* valueQuantity.system = "http://unitsofmeasure.org"
* valueQuantity.code = Cel

The above is actually valid FHIR, as an overwrite would only happen when the CombineCodingAndQuantityValuesOptimizer runs and merges the  latter three rules into one, giving us this:
* valueQuantity.unit = "C"
* valueQuantity= 36.5 'C'

In this case, the first rule setting the unit property will be overwritten. With this in mind, I actually thought it would be better to update the CombineCodingAndQuantityValuesOptimizer to include each property of the Quantity into a single assignment rule on Instances. Given the changes that we're making on the sushi side to broaden support for non-UCUM systems on quantities, I thought that this would be okay to do.


Connection to database not possible and no apex running

Hi,
I have issues with the current release.
I cant get access to the database:
"Status: Nicht erfolgreich -Test nicht erfolgreich: I/O-Fehler: Got minus one from a read call, connect lapse 72 ms., Authentication lapse 0 ms."
And the tomcat ist giving a 404 when accessing apex.
Here is a screenshot of the processes running as oracle user.

Do you have an idea whats wrong?
Btw. its a very nice docker build ;) The version before apex 18 was great. Now I wanted to use it again.

Hi @sebastianreinig
do you use the newest scripts from this repository?
Seems that something went wrong when building the image...
For me it works here on my Mac quite fine, just have a detailed look at the console output when building the image

Ah ok, good to know! Great that it works now!


Update Settings “general”

Automatically generated by Netlify CMS

👷 Deploy Preview for delicate-tiramisu-a90fd0 processing.

Name
Link

🔨 Latest commit
355c59f076b8c3811fbd2f4f4e717190e44b0032

🔍 Latest deploy log
https://app.netlify.com/sites/delicate-tiramisu-a90fd0/deploys/65a182bae9dd270008066802


Add bitwise operators to typechecker/normalizer

These should really come for free:
let _ = assert (FStar.UInt64.logor 0x8000000000000000UL 0x8000000000000000UL = 0x8000000000000000UL)

let _ = assert (FStar.UInt64.logand 0x8000000000000000UL 0x8000000000000000UL = 0x8000000000000000UL)

let _ = assert (FStar.UInt64.lognot 0x8000000000000000UL = 0x7FFFFFFFFFFFFFFFUL)

(+ via assert_norm)
I'm going to give this a go on Bug Squashing Monday; shouldn't be too hard to do in a day I hope.

I remember being confused by that one. Uniformity would be good, e.g. normalize all integer operatiors.

https://github.com/FStarLang/FStar/commit/bfc3b4b62c4cd55c83b14a3b5a67aace49e3203b and subsequent commits, e.g. 03f47c7ad

The shifts remain to be implemented. Please open a new issue if need be.
Thanks,
Jonathan


Investigate Json overflow mechanism via Toth.Json

See https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/handle-overflow on System.Text.Json
In short, this can be used as a preliminary implementation to unblock #365 from #384/#385 . Untyped fields could target a specific field that is present on all datamodel types to dump the tokenized json there. After #385 is implemented, it is still useful work because the Dynamic object would just replace that field, but access to the tokenized json is still necessary to implement that.

@HLWeil could you shortly summarize your progress on this here so we can close this and focus efforts on #384 ? IIRC you solved this in a private repo


expectObservable runs asynchronously

Bug Report
Current Behavior
expectObservable runs asynchronously.
Reproduction
const scheduler = new TestScheduler((actual, expected) => {
    console.log('TestScheduler', {actual, expected});
})

scheduler.run(({hot, expectObservable}) => {
    expectObservable(hot('a')).toBe('a');
    console.log('This is run before expectObservable.');

    setTimeout(() => console.log('This is run after expectObservable.'), 0);
});

Expected behavior
That the whole test suite will run synchronously.
Environment

RxJS 6.4.0

Additional context/Screenshots
This caused a confusing problem with a mocked function in Jest that boiled down to the following:
expectObservable(aStreamThatFlatMapsMyMockedFunction$).toBe(result);
expect(myMockedFunction).toHaveBeenCalled();

The second assertion runs first and since Jest short-circuits on failures the stream is never subscribed, which leads to very confusing error messages.
Workarounds:

Call flush() after expectObservable().
Wrap subsequent assertions in a setTimeout(() => {...assertions...}, 0) to cause the event loop to turn once first.

:) You're BOTH RIGHT!!!
What's "asynchronous" or "synchronous" is relative to any given execution context.


Complete work and about sections

-Work section completed
-About section completed
-README update New features list
-Linter errors fixed

@Qoosim  sorry but I am sure my linter test all passed


Possible Intermittent US State County level reporting issues - FYI

Just noticed this on page where Colorado Data was scraped.  Only state totals were provided.  County and demographic data removed at the moment.
"Due to the high volume of tests being processed by the state lab and a need to get the information out quickly, today’s case summary does not contain a demographic breakdown. Demographic data will be provided as soon as the lab is able to provide the statistical breakdown."

Yes, I saw that and it angered me. https://github.com/lazd/coronadatascraper/blob/master/scrapers.js#L610


Fix broken links (#70)

@linuxdaemon I don't think that rewrite is required, unless you want to add it for completeness?

Nah, the rewrite isn't needed as long as we don't link to the page


fix the missing update of lane_change_type

fix the missing update of lane_change_type

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Design question

Hi,
Question from someone learning V8 and deno_core and using your repo.
I'm wondering, purely for learning purposes why you used the op_return, __rust_return and ResourceTable as the means for getting values back from deno_core?
I've noticed that when I create my own ops using deno_core directly I often get values back as v8::Global<T> and then I hit a brick wall, this value does not seem useful for getting at the underlying value generated from executing the javascript in deno.
Is this the reason for your design decision?
Were there others you considered or know of?
Thanks for you time. Your repo is extremely useful for seeing something minimal and practical done with deno_core.

At the time I first looked into deno_core, this seemed like the most straightforward way. My thought process was:

deno_core is designed to call Rust functions from JavaScript. How can I use this mechanism to do the opposite and call JavaScript from Rust? If I use ops as functions to submit the return value, how could I pass in the function arguments?

And this led to the current design, with "eval-style" code strings for the arguments and ops for the return values.
That said, I haven't followed up new deno_core APIs very closely, so it's possible that there are other (better?) ways of doing that.


Conflicting types for ‘max_align_t’ (while building libvpx dep)

The title is self-explanatory:
In file included from test/../nestegg/halloc/src/halloc.c:19:0:
test/../nestegg/halloc/src/align.h:33:25: error: conflicting types for ‘max_align_t’
 typedef union max_align max_align_t;
                         ^
In file included from test/../nestegg/halloc/src/../halloc.h:18:0,
                 from test/../nestegg/halloc/src/halloc.c:18:
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include/stddef.h:429:3: note: previous declaration of ‘max_align_t’ was here
 } max_align_t;

This could be circumvented on my side by commenting/removing the corresponding line in halloc.h, but I guess it's here for a reason in the first place, still on some systems this may cause trouble as max_align_t is already defined in standard headers (with gcc 5.2.0 at least).

I can confirm this issue on Debian Jessie. I circumvented it so far by installing libvpx-dev from the repository and removing vpx from the package list in Makefile. I will try and see whether it works that way.

We have upgraded vpx to 1.4, but I am not sure if this helps on this issue. You may have a test. BTW, we are also modifying an alternative version of dependency make file, which attempts to use system libraries instead of building all of them.

I submitted kinetiknz/nestegg#31 which is a partial fix (works for GCC and Clang).


Editable project location

When using Poetry for building virtual environments, all package entries have a "location" key with a file path in the pip list output. This results in pip-api determining that all packages are editable, which is incorrect. As of pip version 21.3, an editable_project_location key is available, which is a better indicator of whether a package is truly editable. I've added support to pip-api for using this key, which should provide more accurate information for virtual environments, especially ones created with Poetry.
Thanks in advance for your review.

Thanks! If you have an interesting use case for pip-api and wouldn't mind adding it here, I'd appreciate it!

Thank you for merging my changes and doing a release! I'm not using pip-api directly (only through pip-audit), so I don't have anything to add to use cases.


Deploy via Vercel

Description
BoG has historically used Vercel, but recent changes have disabled automatic deployments. Luckily in the past a very cool BoG member wrote this GitHub action to get around the restrictions.
Acceptance Criteria
[ ] On PR, deploy to Vercel and link to PR
[ ] On merge to main, deploy to prod
[ ] The README is updated with instructions on how to setup the GitHub action

Closed with PR https://github.com/GTBitsOfGood/boggers/pull/15


Using scipy fsolve or other solvers (e.g. GEKKO) in combination with backpropagation models

I was wondering if there was any progress or existing methodologies to use existing solvers such as GEKKO to find/update certain values in your network.
E.g: When using PINN networks on a electrical circuit, one might use a variable resistance dependent on one of your network input parameters. When this dependency is given by an explicit equation it would be nice to, given the inputs, be able to use existing solvers as scipy's fsolve to get this value and use it further on in the network.
From my experience in order to be able to use solvers, tensors should be converted to numpy elements and used in combination with tf.numpy_function, this way I can use solvers as such, however it breaks the chain of gradients and TF can no longer find gradients for certain values and thus no longer train the network.
System information

Tensorflow 2.3.0 (but using some TF1 functionalities from tf.compat.v1:
No possibility to share existing code, but see below for small (hypothetical) case example.

start of code
from scipy.optimize import fsolve
Class PPINlayer(tf.keras.layers.Layer)
def init(self):
super(PPINlayer, self).init(**kwargs)
   def call(self, input, NN *args):
           NNoutput = NN(input)                # this is a NN already initialized somewhere else with trainable parameters
           output = self.f(NNoutput, input)
           return output                                # the output is then used later on to compare with labeled data as loss function for training
   def f(self, NNoutput, input)
         R0 = input[0]
         R1 = input[1]
         V0 = input[2]
         def R2_eq(R2, R0, R1):
                return np.exp(R2/R1) * R1/R2 + R0**2
         R2 = fsolve(R2_eq, 0, args=(R0, R1))
         return (V0/R0 * R2)

Thanks in advance!
Cedric

Hi @cevheck !
Please post this issue on keras-team/keras repo.
To know more see;
https://discuss.tensorflow.org/t/keras-project-moved-to-new-repository-in-https-github-com-keras-team-keras/1999 . Thanks!

Hi @mohantym!
I will do that, I'll close this issue then.
Thanks!


_LF Linked Filters issue: wont work if primary view is a chart

Hi, I'm trying to use linked filters to drive a dashboard of graphs.  I find that if the first view (the one with the primary filter) is a Grid then all the cascading filters work, including those on my pie charts.  But if the first view is a Pie Chart, then no cascading filters work at all.  I seem to recall this was an original issue but was fixed long ago.  Has the issue arisen again?   Using current standard release.

Feature / Reports Subview Keyword _lf #194
The _lf now works on Charts. I brought this feature back. However, a chart cannot link to its own Report view or any specific charts inside or out. It can link only to other Report views, Table views and List views. If you want to link a chart to other charts, you must move the targeted charts outside the "master/source" chart's Report view.
Charles

Thanks Charles.  In the meantime I found a way to solve my immediate need that avoids the ongoing limitation mentioned above - as my first view on the dashboard page I created a 1-row grid view of the table that underlies all the following charts, and I set that up as my primary filter source, and use javascript to hide the actual grid element, leaving only the title and filter visible.  Works a treat.

The only minor niggle is that the hidden grid "expands" slightly if I scroll the page down to see more charts below, which leaves an untidy gap between the filters and the first chart.  The code I'm using to hide that grid is below - if you know of a different way to hide that grid element that wont have this niggle I'd be grateful - I'm not a coder just a newbie, so any advise from a pro is always welcome.
$(document).on('knack-view-render.view_205', function (event, view, data) {
$("table.kn-table").hide();
});

I just found the soln to my question.  It was the table wrapper element causing the issue.  This fixes it:
$(document).on('knack-view-render.view_205', function (event, view, data) {
$("table.kn-table").hide();
$(".kn-table-wrapper").hide();
});


Improving dormant help channel embed

Following the successful implementation of an updated available help channel embed, I think it's time that we update the dormant help channel embed as well. There are two main reasons and goals for wanting to update this:

Improving consistency
Improving the dormant message

Telling the user what to do if the question wasn't answered

Current help channel embeds
Here is the new available help channel embed:

This is the current dormant embed:

Implementation
I'm currently considering the following styling:

A red embed
Uses a red x icon

I actually quite like that the embed is not flashy (no icon, plain black border).

We should link #how-to-get-help in the dormant help channel embed.

Uses a red x icon

I don't think that sends the right message. Channels are often closed with successes (problems were fixed) too, and I don't think that conveys that.

We should link #how-to-get-help in the dormant help channel embed.

Is the justification for this because users will click on a channel in the Dormant category?

Thinking about the call to action the embed represents, I think a color could make it more immediately notable to the eye but that color should be neutral. Blurple perhaps?  Happens to align the Zzz emote used presently.

I actually quite like that the embed is not flashy (no icon, plain black border).

@minalike I agree. My stance today is that we could make the embed less cluttered, but still keep it neutral.
Why was this issue revived all of a sudden?

I was just looking for possible issues to put on staff meeting agenda.

What about a simple embed like this?

Here's the raw text:
This help channel has been closed and it's no longer possible to send messages here. If your question wasn't answered yet, feel free to ask in a new help channel by checking out <#704250143020417084>. To maximize your chances of getting a response, check out this guide on [asking good questions](https://pythondiscord.com/pages/asking-good-questions/).

We should link #how-to-get-help in the dormant help channel embed.

Is the justification for this because users will click on a channel in the Dormant category?

Yes.


Data type error? - looks like Python / Pandas programming error in user script

Hi there
My data type is object , and i have used astype(str) to do the  conversion but keep on getting the error.
<EMAIL_ADDRESS>df['Cntr_Number'].astype(str))

From error message above, it looks like you have a Python / Pandas error. If you try print(df['Cntr_Number'].astype(str)) you might also get the same error.
If it does, then this has nothing to do with the package but some error in how you write your Python and Pandas code, will need to google and debug in that direction.

From error message above, it looks like you have a Python / Pandas error. If you try print(df['Cntr_Number'].astype(str)) you might also get the same error.
If it does, then this has nothing to do with the package but some error in how you write your Python and Pandas code, will need to google and debug in that direction.

solved the error with this code:
df.loc[:,'Cntr_Number'] = df.Cntr_Number.apply(lambda x: str(x)+',')


Add Grype vuln scanning/reporting

This will report to GitHub's Code Scanning reports, showing known CVEs in our go dependencies.

/lgtm

/approve


showSnippets renamed to insertSnippet

VSCode Version: 1.9.0.-insider 83db3c
OS Version: Windows 10

Steps to Reproduce:
I'd bound "Alt+K S" to editor.action.showSnippets. In this build, it's not working.

Looks like @jrieken renamed it to editor.action.insertSnippet in https://github.com/Microsoft/vscode/commit/9aaa2de60ffe177923eb28d7a83e81cd253b81e2

Yes - we renamed that to the more correct insertSnippet. Unsure we should provide a backwards-comp action or just document this...

I see. Though when I try to run insertSnippet from command palette, it says cannot read property 'snippet' of null.

That should be fixed with todays insiders


Push hash-fix instead of making a PR

Will save a good amount of time :)
Tested here - https://github.com/rashil2000/Extras/commits/master
Issues got closed automatically - https://github.com/rashil2000/Extras/issues?q=is%3Aissue+is%3Aclosed

Thumbs up for this improvement.
IMO, It would be better to add an extra check for file sizes, e.g. The file should not be less than 100KB, to avoid corrupted files when the link is invalid redirected to a web page.

It would be better to add an extra check for file sizes, e.g. The file should not be less than 100KB, to avoid corrupted files when the link is invalid redirected to a web page.

I don't quite get it, which files?

I mean the archive/installer in manifest's url.
Sometimes the developer of the software changes the file url, which causes the page to be redirected to a 404 page, homepage or something else.
This will obviously cause installation to fail if we straight up corrects the hash.

Sometimes the developer of the software changes the file url, which causes the page to be redirected to a 404 page, homepage or something else.
This will obviously cause installation to fail if we straight up corrects the hash.

Have we seen such a case? It will be better to discuss this in an issue here - since it's not directly related to this PR.
I was under the impression that Scoop will not download/throw an error if it detects a 404, to prevent downloading a webpage.


API: /org/{org}/repos is inconsistent with the rest of the api

Gitea version (or commit ref): 1.11.0+dev-213-g173da1b5a
Git version: 2.22.0
Operating system: linux
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[x] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes
[ ] No
[x] Not relevant

Description
The api for creating a new repo for an organisation uses the /api/v1/org/{org} prefix instead of the /api/v1/orgs/{org} prefix like the rest of the api.
I have an (untested) change in my fork: https://github.com/ederuiter/gitea which deprecates the /api/v1/org/{org}/repos call and adds a new /api/v1/orgs/{org}/repos call. If this is something you want I can test it and create a pull request for it.

https://developer.github.com/v3/repos/
Creates a new repository in the specified organization. The authenticated user must be a member of the organization.

POST /orgs/:org/repos

@ederuiter can you create a PR

@ederuiter I'll make a PR with your commits ...

#9186 close this @ederuiter if you have some thoughts pleace let me know!

:+1: @6543 I haven't had time create the PR and test it, so thanks for doing this! Looks good to me


Release v4.10.0

Making this one a minor release as even though there are no changes the end users will see, there's been a lot of re-jigging under the hood.

Add linting
Ensure only people who are allowed to view unpublished judgments can view them
Refactor tests
Break judgment checkout
Methods & XQueries to get & set all metadata
DRY up some aspects of the API Client
Support renaming of the XSL Transformation files

Changes in this PR:
Trello card / Rollbar error (etc)

[ ] Requires env variable(s) to be updated

I think I'd very much like at least the
Don't check privilege if user does not ask for unpublished judgments commit in this to avoid significant performance regressions on public-ui live.


refactor: replace @tabler/icons with @tabler/icons-react for smaller bundle sizes

Motivation
We were previously using jotai-devtools in version 0.2.0 after seeing how great the ui looks with the 0.3.0 version we were excited to upgrade!
We however found, that the bundle size has increased significantly!
To reproduce I had created a simple example using  create-react-app   with Typescript:
App.tsx:
import React from 'react';
import './App.css';
import { DevTools } from 'jotai-devtools';
import { Component } from './Component';
import { createStore, Provider } from 'jotai';
const store = createStore();
function App() {
  return (

      <Provider store={store}>
        <DevTools />
        <Component />
      </Provider>

  );
}

export default App;

Component.tsx:
import React from "react";
import { atom, useAtom } from "jotai";

const countAtom = atom(0);
countAtom.debugLabel = "countAtom";

export function Component() {

    const [count, setCount] = useAtom(countAtom);

    return (

        {count}
        <button onClick={() => setCount(count + 1)}>+</button>

)

}

Now, when Using jotai-devtools in version 0.3.1 analyzing the production bundle of the CRA-App with source-map-explorer yields:

So I thought I'd look into @tabler/icons and found that they recently published a package: @tabler/icons-react promising:
"It's build with ESmodules so it's completely tree-shakable. Each icon can be imported as a component."
So I thought I'd give it a shot to replace the @tabler/icons with @tabler/icons-react and see how that looks:

I think that looks like a good downsizing by roughly 700KB. I am not an expert on bundlers and optimizing for bundle sizes, I just thought this could be an easy improvement, so let me know what you think :)

First off, this is great! Thanks for the investigation and for creating a PR 🙌
<DevTools/> component is designed to be tree-shaken by your bundler (in this case CRA) in a production build. So we should not be seeing it in the bundle at all 🤔
My theory is that CRA imports jotai-devtools's ESM module that wraps this check with (import.meta.env && import.meta.env.MODE) !== "production". AFAIK, CRA currently does not support import.meta, hence, the check is truthy, and it includes <DevTools/> in your production build.
I suppose our options are

jotai-devtools adopts process.env.NODE_ENV for ESM modules (I'd want to avoid this)
Have CRA support import.meta (Highly unlikely as CRA is vanishing and the industry moves towards adopting SSR/Next.js based client-side apps)
CRA users switch to one of the React frameworks
CRA users somehow (may need to eject 🤔) use the babel-plugin-syntax-import-meta plugin
Wrap <DevTools/> with a process.env.NODE_ENV check on their end like so const DevOnlyJotaiDevTools = () => process.env.NODE_ENV !== 'production' ? <DevTools/> : null;

I'd still like to merge this change though (less bundle size is always a win 😁).

 component is designed to be tree-shaken by your bundler (in this case CRA) in a production build. So we should not be seeing it in the bundle at all

My theory is that CRA imports jotai-devtools's ESM module that wraps this check with (import.meta.env && import.meta.env.MODE) !== "production". AFAIK, CRA currently does not support import.meta, hence, the check is truthy, and it includes  in your production build.

Yeah that's also something that surprised me too. Maybe that's due to how the Module is structured such that the MantineTheme and DevToolsMain will always be evaluated.
It seems to me that the simple  if (!__DEV__) return null   does it's job to hide to hide away the devtools in production bundle, still uses a bunch of libraries to evaluate the code until that point.
Maybe there's also ways we can split things up there a bit and leverage (default) exports more to reduce the amount of imported code in production bundles.
As for now it seems that at DevTools.tsx there are dependencies being imported and evaluated, before we even get down to the Component where check whether or not we are in Dev mode.

Could you help test it on Vite and Next as well?

I will try setting up lab-projects this weekend and report my findings.

Also, how did we verify the bundle size drop? For some reason, CodeSandbox CI shows the same size thinking

The library should stay the same size (after all, we didn't really change anything) - what should minimize the the prod bundle sizes of the Applications USING Jotai-Devtools.
To measure that in my CRA-Example I used source-map-explorer. So in the CRA I ran that against the /dist folder after running  npm run build  .

It seems to me that the simple  if (!DEV) return null does it's job to hide to hide away the devtools in production bundle, still uses a bunch of libraries to evaluate the code until that point.

Do you mean that the <DevTools/> is still being bundled despite adding an env check? Evaluation should only occur during compile time 🤔 and the component and the libraries (Mantine) used by it should not be included in your bundle. Which option did we go with from the above?
Re: Testing on Next js
I tested this PR on Next JS (CSB here), and its failing with this error, have you ran into this before  or know what could be up 🤔?

It seems to me that the simple  if (!__DEV__) return null does it's job to hide to hide away the devtools in production bundle, still uses a bunch of libraries to evaluate the code until that point.

We are facing this issue as well, @blanky0230 / @arjunvegda . Any luck figuring out how to avoid that?

It seems to me that the simple  if (!__DEV__) return null does it's job to hide to hide away the devtools in production bundle, still uses a bunch of libraries to evaluate the code until that point.

We are facing this issue as well, @blanky0230 / @arjunvegda . Any luck figuring out how to avoid that?

Sorry, I'm unsure about the issue we're referring to here ^.  Could you elaborate a little on it? It might be easier to file a discussion
If the <DevTools/> is being included in the bundle, one of the solutions in this comment should help

Sorry, I'm unsure about the issue we're referring to here ^. Could you elaborate a little on it? It might be easier to file a discussion
If the <DevTools/> is being included in the bundle, one of the solutions in this comment should help

@arjunvegda - The issue is that DevTools is being included in the bundle. We tried all suggested solutions and, unfortunately, none of them worked.

Sorry, I'm unsure about the issue we're referring to here ^. Could you elaborate a little on it? It might be easier to file a discussion
If the <DevTools/> is being included in the bundle, one of the solutions in this comment should help

@arjunvegda - The issue is that DevTools is being included in the bundle. We tried all suggested solutions and, unfortunately, none of them worked.

That's interesting! In that case could you please file a separate discussion and provide us with a small repro? I can look into it.

That's interesting! In that case could you please file a separate discussion and provide us with a small repro? I can look into it.

hmmm this is interesting. Whenever I created a quick NextJS/React repo the prod build size went from 74 kb to 74.2 kb, while my actual repo went from 596kb to 1.73kb just by importing DevTools. I can't share the company repo, unfortunately, but any idea what could be causing it? I literally only imported DevTools <DevTools store={jotaiState} />

Similar issue @blanky0230 ??
Thoughts @arjunvegda ?

That's interesting! In that case could you please file a separate discussion and provide us with a small repro? I can look into it.

hmmm this is interesting. Whenever I created a quick NextJS/React repo the prod build size went from 74 kb to 74.2 kb, while my actual repo went from 596kb to 1.73kb just by importing DevTools. I can't share the company repo, unfortunately, but any idea what could be causing it? I literally only imported DevTools <DevTools store={jotaiState} />

Similar issue @blanky0230 ??
Thoughts @arjunvegda ?

Let's avoid using PRs for discussions, please continue the conversation here

It seems to me that the simple  if (!DEV) return null does it's job to hide to hide away the devtools in production bundle, still uses a bunch of libraries to evaluate the code until that point.

Do you mean that the <DevTools/> is still being bundled despite adding an env check? Evaluation should only occur during compile time thinking and the component and the libraries (Mantine) used by it should not be included in your bundle. Which option did we go with from the above?
Re: Testing on Next js I tested this PR on Next JS (CSB here), and its failing with this error, have you ran into this before or know what could be up thinking?

I don't know what CSB does there tbho...
For local testing I checked out the repo and installed jotai-devtools by filepath.
I tested the setup now with Vite and Next, where I get similar results for bundling. I will attach Screenshots if needed.

It seems to me that the simple  if (!DEV) return null does it's job to hide to hide away the devtools in production bundle, still uses a bunch of libraries to evaluate the code until that point.

Do you mean that the <DevTools/> is still being bundled despite adding an env check? Evaluation should only occur during compile time thinking and the component and the libraries (Mantine) used by it should not be included in your bundle. Which option did we go with from the above?
Re: Testing on Next js I tested this PR on Next JS (CSB here), and its failing with this error, have you ran into this before or know what could be up thinking?

I don't know what CSB does there tbho...
For local testing I checked out the repo and installed jotai-devtools by filepath.
I tested the setup now with Vite and Next, where I get similar results for bundling. I will attach Screenshots if needed.

So it's working fine locally? Could you try updating @tabler/icons-react to 2.16.0 (latest), see if that fixes the issue on CSB?

Fixed in #64


Accelerate the data transfer between JVM and Python for the plan 'GpuWindowInPandasExec'

This PR aims at accelerating the data transfer between JVM and Python for the plan 'GpuWindowInPandasExec' by leveraging the cuDF. Instead of going from cuDF to rows to arrow, we can go from cuDF to arrow directly and vice versa, to avoid transformations between row and arrow.
This PR includes

Removing the GpuWindowInPandasExec  in shims since it does not extends from WindowExecBase any more.
Processing the incoming batches for the window function execution on Python side.

Split the big incoming batches into small batches where each contains only one group data,
Calculate the window frame bounds on each group batch. Now it is OK to send the batches to the Python side one by one.

Adding more integration tests for windowing.

build

Mark as WIP to verify the actual integration tests first.

build

rebased onto the top of branch-0.3.

build

build

I am a little curious why we don't need the shim layers any more.

I am a little curious why we don't need the shim layers any more.

It is the class WindowExecBase is different between spark 310 and 300, from which our current implementation extends.
In this PR, the GpuWindowInPandasExec does not extends from  WindowExecBase any more, so no need shim layers.

build

rebased

build

build

The changes look good my only concern right now is documentation. We are moveing from an implementation that supports all window operations to a version that does not, but is faster for the ones that it does. This is off by default, but if someone tries to use this with a range based query it will fail. For regular window functions we fall back to the CPU, but we cannot do that here. I am OK with that, but we need to update the documentation so it is clear to a customer that this experimental feature is broken in this one area.

Hi, for RangeFrame, it will fall back to the CPU as well, here is the check https://github.com/NVIDIA/spark-rapids/blob/7e6c3d180263539941f86dd158615ad6d163e00e/sql-plugin/src/main/scala/org/apache/spark/sql/rapids/execution/python/GpuWindowInPandasExec.scala#L72 , and i will update the doc accordingly.

For regular window functions we fall back to the CPU, but we cannot do that here.

I do not fully get it, Could you explain more ?
Since as far as I know, regular window functions such as RowNumber, Rank  are executed in the plan GpuWindowExec, while GpuWindowInPandasExec is dedicated to Pandas (Python) UDF over window. Seems we do not need to consider the regular window functions in this plan.

rebased

build

updated the config doc

build

Sorry I do not fully get it, Could you explain more ?

Actually you understood the code better than I did. I thought we were not falling back to the CPU for range queries on python UDFS, but I was wrong, and you updated the documentation so it all looks good now.


How to use Orbit DB with Helia?

So I have been trying to use OrbitDB, but with ipfs-core, it doesnt seem to work anymore. I have then tried to use it with Helia, but I can't find anything explaining how to do it?
const ipfs = await IPFS.create()
const orbitdb = await createOrbitDB({ ipfs})
I am trying to change this to ->
const ipfs= await createHelia()
const orbitdb = await createOrbitDB({ ipfs })
But it doesnt seem to work. I get this error: 'Uncaught (in promise) TypeError: ipfs.id is not a function'
Thanks

They are in the process or rewriting it for Helia in this pr for in the nextgen repo: https://github.com/orbitdb/orbit-db-nextgen/pull/62

They merged that repo and are working on bringing support for helia at this branch called orbitdb/helia. There is no ETA afaik, hopefully in the next month or two would be my guess

I am one of the contributors on OrbitDB. To update you on the current state of Helia integration; we have started preliminary development of Helia integration and are currently working with Protocol Labs on completing a more comprehensive development cycle. We have made numerous attempts at integrating Helia, but because of limited time and with LibP2P currently under heavy development, we have not had immediate success in integrating IPFS's new platform.
In the case of the OP's errors:

Using Helia WILL NOT WORK.

Using with js-ipfs should work. If it isn't, I would recommend posting details of your issue either here or via OrbitDB's Matrix channel. I'm going to assume that you are running into this issue.

OrbitDB is a small project run by volunteers and so there are limitations on time and resources that we, the core contributors, can dedicate to development. We hope to rectify this in the future but at the moment we are fully committed to the development of OrbitDB and are throwing all available time at the project.

@haydenyoung any update?

@haydenyoung any update?

Unfortunately, we were unable to secure formal funding for the Helia integration. Fortunately, we were able to push ahead with a work-in-progress integration and limited testing. Benchmarking and Helia-specific testing along with Helia documentation is currently missing although Helia and Libp2p both provide extensive docs on their respective git repos. There is also example configuration featured in the OrbitDB unit tests. You can follow the progress here.

There's an open PR in the OrbitDB repo: https://github.com/orbitdb/orbitdb/pull/1108.
@haydenyoung we're here if you need any help with the migration to Helia.
Closing this issue.


Hotfix: Downgrade Rack to 2.2.9

Due to some change in policy regarding how rack parses requests from version 3 on, some of our nested forms are parsed in way that produces an incorrect parameters hash in the controller. In this hotfix we downgrade to Rack 2.2.9. We have to go through each form, update them and migrate to Rack 3 at a later time.

related: https://github.com/rack/rack/issues/2128
and: https://github.com/rails/rails/issues/49601
and: https://github.com/rails/rails/issues/49783

To reproduce: upgrade to Rack 3, then go to the profile page. There should be an error thrown due to nested forms and how parameters are passed as arrays.


Lighthouse github action: migrate deprecated set-output

~The lighthouse GitHub action has been failing for awhile. It seems like we need to set a GitHub token in this repo's secrets (see https://github.com/treosh/lighthouse-ci-action/issues/60).~
Also, set-output will be retired on May 31, 2023 and needs to be migrated to environment files (see https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/)
@chosak @wpears do we want to make these updates, or do we want to retire the lighthouse action as we talked about doing with https://github.com/cfpb/cfgov-lighthouse ?

I think this is failing due to https://cfpb.github.io/design-system/guidelines/frames-of-reference-mural-template?

(the iframe embed is causing the lighthouse issues, I just updated it to use a static image instead)

I'm not sure that's related. The failure I see in the action is No GitHub token set, skipping GitHub status check. The instructions have either adding the Lighthouse GitHub app to repo or setting the LHCI_GITHUB_TOKEN, neither of which we have set.

Hmm actually I see GitHub accepted "failure" status for "lhci/url/design-system/guidelines/frames-of-reference-mural-template". … is that what tipped you off?

This PR handles the token issue, but the set-output still needs migrating --> https://github.com/cfpb/design-system/pull/1522

Isn't the use of set-output due to this line related to the Yarn cache dir?

Isn't the use of set-output due to this line related to the Yarn cache dir?

Yes should be that line (part of the Lighthouse GH action workflow, not lighthouse itself).

Dupe of https://github.com/cfpb/design-system/issues/1508