Provide 1.12.* packages for Fedora 25

The issue is about providing Fedora 25 rpms for docker 1.12.* . The fedora 24 repository have both 1.12.* and 1.13.*, providing the same releases for Fedora 25 should be (hopefully!) straightforward.

It'd be super nice if docker 1.12.* could be available for fedora 25. A lot of projects need a slightly older version of docker at the moment and we can't install those versions from docker managed repositories.
Steps to reproduce the issue:

Follow the fedora installation document for fedora 25
Can't install any of the 1.12.* versions

Describe the results you received:
Only 1.13.* is available in https://yum.dockerproject.org/repo/main/fedora/25/Packages
Describe the results you expected:
I should be able to install, say 1.12.1, on Fedora 25.

Fedora 25 was not available when 1.12 was released. We only add new distro versions at .0 currently, and 1.12 is no longer supported.

Ah well, that's a shame, I was hoping to move you enough to start providing those packages on Fedora 25. I guess we can still try to install the binary release (https://get.docker.com/builds/Linux/x86_64/docker-1.12.1.tgz), but it doesn't feel as integrated.

Closing since this won't be added to the 1.12 branch, but feel free to discuss.
Thanks!

If you're going to run a 1.12.x version, I recommend using 1.12.6, which contains security fixes


Update chromedriver to version 84 to match latest chrome version

Automated tests will fail when Chrome and chromedriver versions are out of sync. This PR updates the version of chromedriver to use the same version as Chrome.

Coverage remained the same at 98.913% when pulling 4a22a9b573a79de712b326efb94d9c11377d70dc on maxrandolph:mrandolph/patch-1 into f6568e9145c4e84e61a9e14bc9b0fdcb045a41a2 on tableau:master.


Remove the NoDisplay=true from desktop file

Reverts #2864. People there seem to agree that this should be done.
TUI apps usually have their desktop files visible in system menus.
Also, flathub no longer allows apps with invisible desktop files.

I'm for the common approach too and within Debian one patch line can be removed. So back to the initial state...


Custom database UNITE fungi update

Hi,
we are currently using the UNITE general fasta v8.3 fungi pre-built database provided here and have been wondering whether there will be an update of it available in the near future?
Best,
Monika

We built this for our own project lately: https://osf.io/s59tn/?view_only=6defbb457eb84c11aa4ad30fee5ab0ae.  Trust this may be of some help.
Best,
Sunil

Thanks a lot for sharing, I just downloaded it and will try it in the near future.
Best,
Monika

We do not intend on updating the emu pre-built UNITE databases, but we of course encouraging building databases with our build-database scripts and sharing as is done here! Thanks @sunilnagpal !


Cypress for user and system level tags deletion

User-level tags should be accessible to delete.
System-level tags should not be accessible to delete.

PR for added flag  https://github.com/open-metadata/OpenMetadata/pull/9126

Not exist anymore


Reprint your plugin

What feature would you like to request?
Sorry for the trouble, I know Issues are not used that way
But the Chinese internet generally cannot access the chat software you are using, and using VPN may violate the law
There has been a significant change in the MC community in China this year, and I cannot explain the specifics
I opened an MC forum（ https://mcobs.fun/ ）. I would like to repost your plugin here, is that okay
Are you able to help implement the feature?
SORRY
Is your feature request related to an existing bug or issue?
SORRY
Please enter any additional comments below.
SORRY for the trouble, I know Issues are not used that way
But the Chinese internet generally cannot access the chat software you are using, and using VPN may violate the law
There has been a significant change in the MC community in China this year, and I cannot explain the specifics
I opened an MC forum（ https://mcobs.fun/ ）. I would like to repost your plugin here, is that okay

@x1aoren yes you can repost it there. Thank you for sharing the plugin, and thank you for asking!

Thank you.


[bug] Can’t lock/unlock Schlage BE469 (via HASS Discovery)

Version
Build/Run method

[x] Docker
[ ] PKG
[ ] Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.0.0-alpha.2
Describe the bug
Connected to Home Assistant via HASS Discovery. When HASS loads, the lock shows an unlocked state no matter what. When I attempt to lock/unlock the lock, I get an error:
2021-01-03 07:06:01.353 INFO MQTT: Message received on zwavejs2mqtt/16/98/0/targetMode/set
2021-01-03 07:06:01.354 INFO ZWAVE: Writing LOCK to 98-0-targetMode
2021-01-03 07:06:01.355 INFO ZWAVE: Controller status: Driver: Door Lock: "targetMode" must be of type "number", received "string"
2021-01-03 07:06:01.356 ERROR ZWAVE: Unable to write LOCK on 98-0-targetMode

I want to help fix this discovery
I suggest

to export the node json and post it. I am interested to find out where it stucks.
enable log to file forl the driver and add silly as mode, then once everything is interviewed exeute the command and send us the driver output. until new version (6.0) is added, we will need to get these info from the bin/zwave-<pid>.log of your docker container.  usuallys is 1

That for now :)

I want to help fix this discovery
I suggest

to export the node json and post it. I am interested to find out where it stucks.
enable log to file forl the driver and add silly as mode, then once everything is interviewed exeute the command and send us the driver output. until new version (6.0) is added, we will need to get these info from the bin/zwave-<pid>.log of your docker container.  usuallys is 1

That for now :)

Thanks, @billiaz. Appreciate your help.
Nodes: https://gist.github.com/bachya/0954e9827cd4466a2f36110cc6cc9ac8
Log: https://gist.github.com/bachya/07d984a1f9dedf58bc3d1ca6cf002503

Thanks, @billiaz. Appreciate your help.
Nodes: https://gist.github.com/bachya/0954e9827cd4466a2f36110cc6cc9ac8
Log: https://gist.github.com/bachya/07d984a1f9dedf58bc3d1ca6cf002503

i suspect something needs to be fixed on targetMode! we faced a similar in climate.
Can you help me a bit with

get an export of the node and not the whole list, as the whole list shows only highlevel info

can you paste the   zwavejs2mqtt/16/98/0/targetMode payload on mqtt side?

i suspect something needs to be fixed on targetMode! we faced a similar in climate.
Can you help me a bit with

get an export of the node and not the whole list, as the whole list shows only highlevel info

can you paste the   zwavejs2mqtt/16/98/0/targetMode payload on mqtt side?

@billiaz Here you go!
Schlage BE469 Node Info: https://gist.github.com/bachya/bfaa5a32776f00873ddf3353b5115eac
When I lock/unlock the lock, this is the only payload that appears under zwavejs2mqtt/16/98/0/targetMode:
{"time":1609771434569}

@billiaz Here you go!
Schlage BE469 Node Info: https://gist.github.com/bachya/bfaa5a32776f00873ddf3353b5115eac
When I lock/unlock the lock, this is the only payload that appears under zwavejs2mqtt/16/98/0/targetMode:
{"time":1609771434569}

targetmode supports the following:
        {
          "text": "Unsecured",
          "value": 0
        },
        {
          "text": "UnsecuredWithTimeout",
          "value": 1
        },
        {
          "text": "InsideUnsecured",
          "value": 16
        },
        {
          "text": "InsideUnsecuredWithTimeout",
          "value": 17
        },
        {
          "text": "OutsideUnsecured",
          "value": 32
        },
        {
          "text": "OutsideUnsecuredWithTimeout",
          "value": 33
        },
        {
          "text": "Unknown",
          "value": 254
        },
        {
          "text": "Secured",
          "value": 255
        }
      ],

what value do you try to set?
from the currentValue topic i can see       "value": 255, which reflects Secured
can you send a command to topic zwavejs2mqtt/16/98/0/targetMode/set and the text plaintext be Unsecured.
And tell me what happened

targetmode supports the following:
        {
          "text": "Unsecured",
          "value": 0
        },
        {
          "text": "UnsecuredWithTimeout",
          "value": 1
        },
        {
          "text": "InsideUnsecured",
          "value": 16
        },
        {
          "text": "InsideUnsecuredWithTimeout",
          "value": 17
        },
        {
          "text": "OutsideUnsecured",
          "value": 32
        },
        {
          "text": "OutsideUnsecuredWithTimeout",
          "value": 33
        },
        {
          "text": "Unknown",
          "value": 254
        },
        {
          "text": "Secured",
          "value": 255
        }
      ],

what value do you try to set?
from the currentValue topic i can see       "value": 255, which reflects Secured
can you send a command to topic zwavejs2mqtt/16/98/0/targetMode/set and the text plaintext be Unsecured.
And tell me what happened

@billiaz The Home Assistant MQTT Discovery configuration for this node (homeassistant/lock/nodeID_16/lock/config) shows this:
{
  "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
  "state_locked": "true",
  "state_unlocked": "false",
  "value_template": "{% if value_json.value == false %} false {% elif value_json.value == true %} true {% else %} unknown {% endif %}",
  "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "device": {
    "identifiers": [
      "zwavejs2mqtt_0xc8341d86_node16"
    ],
    "manufacturer": "Allegion",
    "model": "Touchscreen Deadbolt (BE469)",
    "name": "nodeID_16",
    "sw_version": "113.22"
  },
  "name": "-nodeID_16_lock",
  "unique_id": "zwavejs2mqtt_0xc8341d86_16-98-0-currentMode"
}

When I attempt to lock the lock and look at the command topic (zwavejs2mqtt/16/98/0/targetMode/set), I see:
LOCK

So, to your point, that looks like the issue: we need to be sending an integer that corresponds to the lock state. I will test shortly and follow up!

@billiaz The Home Assistant MQTT Discovery configuration for this node (homeassistant/lock/nodeID_16/lock/config) shows this:
{
  "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
  "state_locked": "true",
  "state_unlocked": "false",
  "value_template": "{% if value_json.value == false %} false {% elif value_json.value == true %} true {% else %} unknown {% endif %}",
  "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "device": {
    "identifiers": [
      "zwavejs2mqtt_0xc8341d86_node16"
    ],
    "manufacturer": "Allegion",
    "model": "Touchscreen Deadbolt (BE469)",
    "name": "nodeID_16",
    "sw_version": "113.22"
  },
  "name": "-nodeID_16_lock",
  "unique_id": "zwavejs2mqtt_0xc8341d86_16-98-0-currentMode"
}

When I attempt to lock the lock and look at the command topic (zwavejs2mqtt/16/98/0/targetMode/set), I see:
LOCK

So, to your point, that looks like the issue: we need to be sending an integer that corresponds to the lock state. I will test shortly and follow up!

@billiaz can we customize the template to make it send a number instead of lock and unlock? otherwise we need to parse the value on gateway side, if the value has states look for states text matching and take the state text value as valid value

@billiaz can we customize the template to make it send a number instead of lock and unlock? otherwise we need to parse the value on gateway side, if the value has states look for states text matching and take the state text value as valid value

Okay, additional follow-up. Here are the results of my tests (posting various raw payloads to zwavejs2mqtt/16/98/0/targetMode/set):

0: unlocked the door (but no update of the lock entity's state in Home Assistant)
255: locked the door (but no update of the lock entity's state in Home Assistant)
Unsecured: no change (and the same Docker console log: "targetMode" must be of type "number", received "string")
Secured: no change (and the same Docker console log: "targetMode" must be of type "number", received "string")

So, preliminarily, I think two things need to happen with Discovery:

zwavejs2mqtt/16/98/0/targetMode/set needs to receive integers, not strings
The value_template needs to be changed to reflect those integers – perhaps something like:

"{% if value_json.value == 0 %} false {% elif value_json.value == 255 %} true {% else %} unknown {% endif %}"

(Although, that template should probably be made more robust to include the other integer code possibilities listed above, but I'll leave that to someone wiser than I. 😉)

Okay, additional follow-up. Here are the results of my tests (posting various raw payloads to zwavejs2mqtt/16/98/0/targetMode/set):

0: unlocked the door (but no update of the lock entity's state in Home Assistant)
255: locked the door (but no update of the lock entity's state in Home Assistant)
Unsecured: no change (and the same Docker console log: "targetMode" must be of type "number", received "string")
Secured: no change (and the same Docker console log: "targetMode" must be of type "number", received "string")

So, preliminarily, I think two things need to happen with Discovery:

zwavejs2mqtt/16/98/0/targetMode/set needs to receive integers, not strings
The value_template needs to be changed to reflect those integers – perhaps something like:

"{% if value_json.value == 0 %} false {% elif value_json.value == 255 %} true {% else %} unknown {% endif %}"

(Although, that template should probably be made more robust to include the other integer code possibilities listed above, but I'll leave that to someone wiser than I. 😉)

Okay, additional follow-up. Here are the results of my tests (posting various raw payloads to zwavejs2mqtt/16/98/0/targetMode/set):

0: unlocked the door (but no update of the lock entity's state in Home Assistant)
255: locked the door (but no update of the lock entity's state in Home Assistant)
Unsecured: no change (and the same Docker console log: "targetMode" must be of type "number", received "string")
Secured: no change (and the same Docker console log: "targetMode" must be of type "number", received "string")

I think the Home Assistant entity not updating is related to the value_template looking for boolean values.
So, preliminarily, I think two things need to happen with Discovery:

zwavejs2mqtt/16/98/0/targetMode/set needs to receive integers, not strings
The value_template needs to be changed to reflect those integers – perhaps something like:

{% if value_json.value == 0 %} false {% elif value_json.value == 255 %} true {% else %} unknown {% endif %}

(Although, that template should probably be made more robust to include the other integer code possibilities listed above [assuming they are useful across various lock types], but I'll leave that to someone wiser than I. 😉)

you do not this complexity if you only use the 255 and 0
reading this https://www.home-assistant.io/integrations/lock.mqtt/ should be easy to patch payloads for lock. i need a bit of time and setup this.

Okay, additional follow-up. Here are the results of my tests (posting various raw payloads to zwavejs2mqtt/16/98/0/targetMode/set):

0: unlocked the door (but no update of the lock entity's state in Home Assistant)
255: locked the door (but no update of the lock entity's state in Home Assistant)
Unsecured: no change (and the same Docker console log: "targetMode" must be of type "number", received "string")
Secured: no change (and the same Docker console log: "targetMode" must be of type "number", received "string")

I think the Home Assistant entity not updating is related to the value_template looking for boolean values.
So, preliminarily, I think two things need to happen with Discovery:

zwavejs2mqtt/16/98/0/targetMode/set needs to receive integers, not strings
The value_template needs to be changed to reflect those integers – perhaps something like:

{% if value_json.value == 0 %} false {% elif value_json.value == 255 %} true {% else %} unknown {% endif %}

(Although, that template should probably be made more robust to include the other integer code possibilities listed above [assuming they are useful across various lock types], but I'll leave that to someone wiser than I. 😉)

you do not this complexity if you only use the 255 and 0
reading this https://www.home-assistant.io/integrations/lock.mqtt/ should be easy to patch payloads for lock. i need a bit of time and setup this.

@billiaz Great! Let me know how I can support you: I'm a core Home Assistant member and obviously have this lock, so I'm at your disposal.

@billiaz Great! Let me know how I can support you: I'm a core Home Assistant member and obviously have this lock, so I'm at your disposal.

@bachya
{
  "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
  "state_locked": 255,
  "state_unlocked": 0,
  "payload_lock": 255,
  "payload_unlock": 0,
  "value_template": "{{ if value_json.value }}",
  "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "device": {
    "identifiers": [
      "zwavejs2mqtt_0xc8341d86_node16"
    ],
    "manufacturer": "Allegion",
    "model": "Touchscreen Deadbolt (BE469)",
    "name": "nodeID_16",
    "sw_version": "113.22"
  },
  "name": "test_lock",
  "unique_id": "zwavejs2mqtt_0xc8341d86_test"
}

can you try this?
How can you try this?
on the bottom of Zj2m interface you can on the right side ADD a new device.. if you paste this code and click ADD you should be able to add this! it is temporary. this will give it an entity name in HASS test_lock
if this works I can then make a patch in z2m! but testing it will help me!

@bachya
{
  "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
  "state_locked": 255,
  "state_unlocked": 0,
  "payload_lock": 255,
  "payload_unlock": 0,
  "value_template": "{{ if value_json.value }}",
  "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "device": {
    "identifiers": [
      "zwavejs2mqtt_0xc8341d86_node16"
    ],
    "manufacturer": "Allegion",
    "model": "Touchscreen Deadbolt (BE469)",
    "name": "nodeID_16",
    "sw_version": "113.22"
  },
  "name": "test_lock",
  "unique_id": "zwavejs2mqtt_0xc8341d86_test"
}

can you try this?
How can you try this?
on the bottom of Zj2m interface you can on the right side ADD a new device.. if you paste this code and click ADD you should be able to add this! it is temporary. this will give it an entity name in HASS test_lock
if this works I can then make a patch in z2m! but testing it will help me!

I got this to work - but the state topic isn't read correctly, so hass shows it still unlocks.
{
  "type": "lock",
  "object_id": "lock",
  "discovery_payload": {
    "command_topic": "homeassistant/FrontDoor/98/0/targetMode/set",
    "state_locked": 255,
    "state_unlocked": 0,
    "payload_lock": 255,
    "payload_unlock": 0,
    "value_template": "{{ value.x }}",
    "json_attributes_topic": "homeassistant/FrontDoor/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xeeb41e63_node52"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "FrontDoor",
      "sw_version": "128.22"
    },
    "name": "FrontDoor_lock",
    "unique_id": "zwavejs2mqtt_0xeeb41e63_52-98-0-currentMode"
  },
  "discoveryTopic": "lock/FrontDoor/lock/config",
  "values": [
    "98-0-currentMode",
    "98-0-targetMode"
  ],
  "persistent": true,
  "ignoreDiscovery": false,
  "id": "lock_lock"
}

I got this to work - but the state topic isn't read correctly, so hass shows it still unlocks.
{
  "type": "lock",
  "object_id": "lock",
  "discovery_payload": {
    "command_topic": "homeassistant/FrontDoor/98/0/targetMode/set",
    "state_locked": 255,
    "state_unlocked": 0,
    "payload_lock": 255,
    "payload_unlock": 0,
    "value_template": "{{ value.x }}",
    "json_attributes_topic": "homeassistant/FrontDoor/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xeeb41e63_node52"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "FrontDoor",
      "sw_version": "128.22"
    },
    "name": "FrontDoor_lock",
    "unique_id": "zwavejs2mqtt_0xeeb41e63_52-98-0-currentMode"
  },
  "discoveryTopic": "lock/FrontDoor/lock/config",
  "values": [
    "98-0-currentMode",
    "98-0-targetMode"
  ],
  "persistent": true,
  "ignoreDiscovery": false,
  "id": "lock_lock"
}

@billiaz When I select my node, input that JSON, click "Add," then click "Rediscover," I don't see the new entity in Home Assistant. Did I miss a step?

@billiaz When I select my node, input that JSON, click "Add," then click "Rediscover," I don't see the new entity in Home Assistant. Did I miss a step?

change value.x on template with value_json.value
also delete the discovery and readd

change value.x on template with value_json.value
also delete the discovery and readd

This appears to be working for me now! Thanks @billiaz @bachya !
{
  "type": "lock",
  "object_id": "lock",
  "discovery_payload": {
    "command_topic": "homeassistant/FrontDoor/98/0/targetMode/set",
    "state_locked": 255,
    "state_unlocked": 0,
    "payload_lock": 255,
    "payload_unlock": 0,
    "value_template": "{{ value_json.value }}",
    "json_attributes_topic": "homeassistant/FrontDoor/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xeeb41e63_node52"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "FrontDoor",
      "sw_version": "128.22"
    },
    "name": "FrontDoor_lock",
    "unique_id": "zwavejs2mqtt_0xeeb41e63_52-98-0-currentMode"
  },
  "discoveryTopic": "lock/FrontDoor/lock/config",
  "values": [
    "98-0-currentMode",
    "98-0-targetMode"
  ],
  "persistent": true,
  "ignoreDiscovery": false,
  "id": "lock_lock"
}

This appears to be working for me now! Thanks @billiaz @bachya !
{
  "type": "lock",
  "object_id": "lock",
  "discovery_payload": {
    "command_topic": "homeassistant/FrontDoor/98/0/targetMode/set",
    "state_locked": 255,
    "state_unlocked": 0,
    "payload_lock": 255,
    "payload_unlock": 0,
    "value_template": "{{ value_json.value }}",
    "json_attributes_topic": "homeassistant/FrontDoor/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xeeb41e63_node52"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "FrontDoor",
      "sw_version": "128.22"
    },
    "name": "FrontDoor_lock",
    "unique_id": "zwavejs2mqtt_0xeeb41e63_52-98-0-currentMode"
  },
  "discoveryTopic": "lock/FrontDoor/lock/config",
  "values": [
    "98-0-currentMode",
    "98-0-targetMode"
  ],
  "persistent": true,
  "ignoreDiscovery": false,
  "id": "lock_lock"
}

@billiaz Sorry, I'm still not clear. Your payload is different from what @johnsonnc posted; yours still doesn't work for me.
Am I supposed to add @johnsonnc's payload as a new device under the actual lock node (16 in my case)?

@billiaz Sorry, I'm still not clear. Your payload is different from what @johnsonnc posted; yours still doesn't work for me.
Am I supposed to add @johnsonnc's payload as a new device under the actual lock node (16 in my case)?

yes! once you do this! and you both confirm works as expected. I will add this on one of the next releases (create patch)

yes! once you do this! and you both confirm works as expected. I will add this on one of the next releases (create patch)

@billiaz Sorry to be such a noob, but it's not working. Here's what I'm doing, explicitly:

I click on Node 16, which is this lock.
I paste this JSON into the Hass Device JSON text area:

{
  "type": "lock",
  "object_id": "lock",
  "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
  "state_locked": 255,
  "state_unlocked": 0,
  "payload_lock": 255,
  "payload_unlock": 0,
  "value_template": "{{ if value_json.value }}",
  "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xc8341d86_node16"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "nodeID_16",
      "sw_version": "113.22"
    ,
    "name": "test_lock",
    "unique_id": "zwavejs2mqtt_0xc8341d86_test"
  }
}

I click ADD. Nothing happens (i.e., I don't see this new test_lock device in the list to the left).
I click REDISCOVER NODE. No change.
I try restarting the Docker container. No change.

I also tried a different JSON payload that included key/value pairs that @johnsonnc had present
{
  "type": "lock",
  "object_id": "lock",
  "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
  "state_locked": 255,
  "state_unlocked": 0,
  "payload_lock": 255,
  "payload_unlock": 0,
  "value_template": "{{ if value_json.value }}",
  "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xc8341d86_node16"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "nodeID_16",
      "sw_version": "113.22"
    ,
    "name": "test_lock",
    "unique_id": "zwavejs2mqtt_0xc8341d86_test"
  },
  "discoveryTopic": "lock/nodeID_16/lock/config",
  "values": [
    "98-0-currentMode",
    "98-0-targetMode"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "lock_test_lock"
}

...but again, same steps, no change.
What am I doing wrong?

@billiaz Sorry to be such a noob, but it's not working. Here's what I'm doing, explicitly:

I click on Node 16, which is this lock.
I paste this JSON into the Hass Device JSON text area:

{
  "type": "lock",
  "object_id": "lock",
  "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
  "state_locked": 255,
  "state_unlocked": 0,
  "payload_lock": 255,
  "payload_unlock": 0,
  "value_template": "{{ if value_json.value }}",
  "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xc8341d86_node16"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "nodeID_16",
      "sw_version": "113.22"
    ,
    "name": "test_lock",
    "unique_id": "zwavejs2mqtt_0xc8341d86_test"
  }
}

I click ADD. Nothing happens (i.e., I don't see this new test_lock device in the list to the left).
I click REDISCOVER NODE. No change.
I try restarting the Docker container. No change.

I also tried a different JSON payload that included key/value pairs that @johnsonnc had present
{
  "type": "lock",
  "object_id": "lock",
  "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
  "state_locked": 255,
  "state_unlocked": 0,
  "payload_lock": 255,
  "payload_unlock": 0,
  "value_template": "{{ if value_json.value }}",
  "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
  "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xc8341d86_node16"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "nodeID_16",
      "sw_version": "113.22"
    ,
    "name": "test_lock",
    "unique_id": "zwavejs2mqtt_0xc8341d86_test"
  },
  "discoveryTopic": "lock/nodeID_16/lock/config",
  "values": [
    "98-0-currentMode",
    "98-0-targetMode"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "lock_test_lock"
}

...but again, same steps, no change.
What am I doing wrong?

delete "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
and change "value_template": "{{ if value_json.value }}", -> "value_template": "{{ value_json.value }}",
In then click "Update", click the local entity again, click 'Rediscover' next to 'Update'.
I would then check under the device in HA, under 'MQTT Info' and look for the Lock Entity Discovery payload and see if it updated.

delete "state_topic": "zwavejs2mqtt/16/98/0/currentMode",
and change "value_template": "{{ if value_json.value }}", -> "value_template": "{{ value_json.value }}",
In then click "Update", click the local entity again, click 'Rediscover' next to 'Update'.
I would then check under the device in HA, under 'MQTT Info' and look for the Lock Entity Discovery payload and see if it updated.

@johnsonnc Here's what I did:

Click on Node 16.
Click on the existing lock device lock_lock.
Updated the Hass Device JSON to mirror your suggestion above.
Clicked UPDATE.
Clicked REDISCOVER.

No change: I went to Home Assistant, attempt to lock/unlock the lock and there was no response. I went into the lock_lock device and saw the old Hass Device JSON.
I don't know where to check for your last sentence:

under the device in HA, under 'MQTT Info'

I don't see that in zwavejs2mqtt.

@johnsonnc Here's what I did:

Click on Node 16.
Click on the existing lock device lock_lock.
Updated the Hass Device JSON to mirror your suggestion above.
Clicked UPDATE.
Clicked REDISCOVER.

No change: I went to Home Assistant, attempt to lock/unlock the lock and there was no response. I went into the lock_lock device and saw the old Hass Device JSON.
I don't know where to check for your last sentence:

under the device in HA, under 'MQTT Info'

I don't see that in zwavejs2mqtt.

Those steps with this version. If it doesn't work, I am curious if you have discovery on in HA and zwavejs2 on?
{
  "type": "lock",
  "object_id": "lock",
  "discovery_payload": {
    "command_topic": "zwavejs2mqtt/16/98/0/targetMode/set",
    "state_locked": 255,
    "state_unlocked": 0,
    "payload_lock": 255,
    "payload_unlock": 0,
    "value_template": "{{ value.x }}",
    "json_attributes_topic": "zwavejs2mqtt/16/98/0/currentMode",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xc8341d86_node16"
      ],
      "manufacturer": "Allegion",
      "model": "Touchscreen Deadbolt (BE469)",
      "name": "nodeID_16",
      "sw_version": "113.22"
    },
    "name": "-nodeID_16_lock",
    "unique_id": "zwavejs2mqtt_0xc8341d86_16-98-0-currentMode"
  },
  "discoveryTopic": "lock/-nodeID_16_lock/lock/config",
  "values": [
    "98-0-currentMode",
    "98-0-targetMode"
  ],
  "persistent": true,
  "ignoreDiscovery": false,
  "id": "lock_lock"
}

That payload "worked" (in that it was saved and updated), but then, back in Home Assistant, nothing happens when I try to unlock/lock.
Discovery is enabled, yes?

This is what mine looks like.

This is what mine looks like.

Thanks for your help, @johnsonnc.
I'll get back on this tomorrow.

Thanks for your help, @johnsonnc.
I'll get back on this tomorrow.

@bachya do not spend time struggling with, with the positive reply from @johnsonnc I am going to write the patch! and ask for review through that. If you have patience a few days! :)
I am also sometimes struggling with entities, as HASS do not really update them.
The setting I see posted are for Auto generated ones! and how topics stored. to avoid going into a mess of your setup do not change these for now! but let me finish the auto discovery bit and I will ask for your review. I will also build a container on my private docker hub registry to test against.

@bachya do not spend time struggling with, with the positive reply from @johnsonnc I am going to write the patch! and ask for review through that. If you have patience a few days! :)
I am also sometimes struggling with entities, as HASS do not really update them.
The setting I see posted are for Auto generated ones! and how topics stored. to avoid going into a mess of your setup do not change these for now! but let me finish the auto discovery bit and I will ask for your review. I will also build a container on my private docker hub registry to test against.

Sounds good, @billiaz – I am relieved. 😂 I'll await the official release and will test then. Thank you!

Sounds good, @billiaz – I am relieved. 😂 I'll await the official release and will test then. Thank you!

@bachya pushed a pull request based on @johnsonnc payload. this should fix it.
feel free to compile branch fix-137 and give feedback.
Alternatively you can use the docker from : docker hub varet/zwavejs2mqtt:fix-137

@bachya pushed a pull request based on @johnsonnc payload. this should fix it.
feel free to compile branch fix-137 and give feedback.
Alternatively you can use the docker from : docker hub varet/zwavejs2mqtt:fix-137

@billiaz Used the varet/zwavejs2mqtt:fix-137 image and can confirm: I can lock/unlock my locks from Home Assistant and the state is updated immediately! 🥳 Well done!

@billiaz Used the varet/zwavejs2mqtt:fix-137 image and can confirm: I can lock/unlock my locks from Home Assistant and the state is updated immediately! 🥳 Well done!


Measure statistical significance of Domain setup

There's one remaining usage of cpu_relax in spinning the first domain while waiting for the second domain to start-up:
https://github.com/jmid/multicoretests/blob/8a9a2327e06036f06ca5ef4b1321129ccff557d6/lib/lin.ml#L122-L124
Now that we have statistics in place, it would be natural to give this Domain setup a run-down to see what aspects actually influence the bug-finding ability similar to what I did for Thread recently: https://github.com/jmid/multicoretests/blob/8a9a2327e06036f06ca5ef4b1321129ccff557d6/src/statistics/README.md?plain=1#L129-L143
For Thread a wait loop had an significant effect. For Domain it would be nice to confirm - and also investigate whether there could be better ways to accomplish this. In the tests for the work-stealing deque that has now been pulled out of domainslib the spinning did not work at all to trigger issues on MacOSX, so I ended up going with a binary semaphore: https://github.com/jmid/multicoretests/blob/8a9a2327e06036f06ca5ef4b1321129ccff557d6/src/domainslib/ws_deque_test.ml#L131-L133
The simpler, the better. A combination of a Mutex and a Condition variable may also be sufficient.
Originally posted by @jmid in https://github.com/jmid/multicoretests/issues/43#issuecomment-1099991569

I've been trying to have some numbers comparing bug-triggering with cpu_relax and semaphore. I have some strange results (no buggy programs found over 10000 while CI is happy with 1000...) and I don't understand yet, but it seems that synchronization with a semaphore is a bit faster than with a cpu_relax:
$ dune exec -- src/neg_tests/conclist_stm_tests.exe
random seed: 138767447
generated error  fail  pass / total     time test name
[✓] 10000     0     0 10000 / 10000   103.1s STM int64 CList with cpu_relax
[✓] 10000     0     0 10000 / 10000    78.5s STM int64 CList with semaphore
================================================================================
success (ran 2 tests)
relax : 0 / 10000
semap : 0 / 10000

Code is here: https://github.com/n-osborne/multicoretests/blob/domain-stats/src/neg_tests/conclist_stm_tests.ml#L53 and here: https://github.com/n-osborne/multicoretests/blob/domain-stats/lib/STM.ml#L391

That's indeed interesting that the Semaphore is faster than the "Atomic waiting loop" :+1: :thinking:
I had a quick look:

When an exception is raised mk_prop does not increase the counter (I think it should)
I also noticed that the stats tests are not using repeat. To be comparable to the CI's 1000 iterations I would try to use it here too.

* When an exception is raised `mk_prop` does not increase the counter (I think it should)

Yes, that works better that way.

* I also noticed that the stats tests are not using `repeat`. To be comparable to the CI's 1000 iterations I would try to use it here too.

That was just to have something a bit more accurate for speed.
So Semaphore are indeed faster, but spot far less buggy programs:
This is with repeat 25 prop.
$ dune exec -- src/neg_tests/conclist_stm_tests.exe
random seed: 300478220
generated error  fail  pass / total     time test name
[✓] 10000     0     0 10000 / 10000  3302.4s STM int64 CList with cpu_relax
[✓] 10000     0     0 10000 / 10000  1970.2s STM int64 CList with semaphore
================================================================================
success (ran 2 tests)
relax : 36868 / 10000
semap : 8 / 10000

Ah, that is indeed quite a difference! :open_mouth:
i'm surprised by the number 36868 though!
Because of the way Util.repeat is implemented it should stop early on the first failed property.
I would thus expect it to increment the counter at most once for each of the 25 repetitions and hence reach at most 10000. :thinking:


Error with date data type?

I have this line in my model field :dob, :date, but when save to database, I got the following error:
** (Protocol.UndefinedError) protocol Enumerable not implemented for ~D[2000-01-01]. This protocol is implemented for: DBConnection.PrepareStream, DBConnection.Stream, Date.Range, File.Stream, Function, GenEvent.Stream, HashDict, HashSet, IO.Stream, List, Map, MapSet, Mongo.AggregationCursor, Mongo.Cursor, Mongo.SinglyCursor, Postgrex.Stream, Range, Stream, Timex.Interval

Can anyone please help me?

Probably I have to use utc_datetime instead, because MongoDB does not have Date data type.

Yes, you will want to use a DateTime type


ember-cli 0.2.6 deprecation warning

[Deprecated] this.pickFiles is deprecated, please use broccoli-funnel directly instead  [addon: ember-cli-async-button]

I haven't seen this, but feel free to reopen if it's still an issue


UnifiedG1GCParser doesn't recognize  survivor & eden occupancy

Describe the solution you'd like
Hello, i noticed that the code was already implemented but commented out, is there any special reason for doing this?

Good question, I don't know the answer. I'd suggest that the code be uncommented and see if it passes all the tests.

@kcpeppe  I uncommented the code , and all tests passed.  Should i submit a PR or wait for the community to fix it?

I'm happy with a pull requsst


Update readme

goals / in scope, out of scope. see brain storming.

Readme Updated and "documentation" started


Graphics glitch in Viking Child (like stage has "drowned" a bit)

This seems to be a HBL timing issue

Also, some sprites are misplaced:

Version 0.5.0 - "drowning" issue is sstill here. Sprites are now in right places.


Cannot build Sample App - Error running and authorising sample app

IMPORTANT: Before you create an issue, please take a look at our Issue Reporting Guide.
Briefly summarize your issue:

I enter these commands to run and authorise the SampleApp:
cd /home/pi/sdk-folder/sdk-build
PA_ALSA_PLUGHW=1 ./SampleApp/src/SampleApp ./Integration/AlexaClientSDKConfig.json DEBUG9
What is the expected behaviour?

The SampleApp should run
What behaviour are you observing?

Nothing, just nothing happens the SampleApp won't authorise or run. I don't get any error message or any result of any kind.
Provide the steps to reproduce the issue, if applicable:

no error message is thrown, the file and directory having tried every possible combination appear to be there and be recognised. I am at a loss as to why this is happening.
Tell us about your environment:

What version of the AVS Device SDK are you using?
The latest version
Tell us what hardware you're using:

[RPi 4 Model B] Raspberry Pi

Tell us about your OS (Type & version):

[ ] Linux
[ ] MacOS
[ ] Raspbian Stretch
[ ] Raspbian Jessy
[Raspbian Buster ] Other - tell us more:

I am using SDK 1.19, I used the command make SampleApp to build the SDK I dont get any logs the response message says when I try to debug:
-- Logs begin at Wed 2020-04-29 00:16:20 BST, end at Thu 2020-04-30 18.51:05 BST -- No entries --
Thanks for your help :-)

Hi @gemma2301, I would actually like to know what cmake command you used when building the SDK. (Not "make SampleApp", but the cmake command you would have used before that.)
For example, in our quick start guide, we suggest something like the following (step 1):
 cmake /home/pi/sdk-folder/sdk-source/avs-device-sdk \
 -DSENSORY_KEY_WORD_DETECTOR=ON \
 -DSENSORY_KEY_WORD_DETECTOR_LIB_PATH=/home/pi/sdk-folder/third-party/alexa-rpi/lib/libsnsr.a \
 -DSENSORY_KEY_WORD_DETECTOR_INCLUDE_DIR=/home/pi/sdk-folder/third-party/alexa-rpi/include \
 -DGSTREAMER_MEDIA_PLAYER=ON \
 -DPORTAUDIO=ON \
 -DPORTAUDIO_LIB_PATH=/home/pi/sdk-folder/third-party/portaudio/lib/.libs/libportaudio.a \
 -DPORTAUDIO_INCLUDE_DIR=/home/pi/sdk-folder/third-party/portaudio/include

Yours will probably look a little different.

I just used the sample cmake command in the guidance notes - I was terrified to add any customised variables as this is all new to me. I may have misread the instructions.

Can you copy and paste the cmake command you used into this issue, so that I can see it, as well as the output that is printed when you run the cmake command?
You will need to confirm that all the file paths mentioned in the cmake command actually exist on your computer.
For example, what is the output if you do the following:
ls /home/pi/sdk-folder/sdk-build
ls /home/pi/sdk-folder/sdk-source/avs-device-sdk

ls /home/pi/sdk-folder/sdk-build
I get the following output which shows in the picture
Integration SampleApp
ls /home/pi/sdk-folder/sdk-source/avs-device-sdk
shows in the screen grab

make SampleApp  appears previously to have worked once I have run the cmake commands the problem is running and autorising the SampleApp

Hi @gemma2301, can you please copy the cmake command that you used here?
Also, just to make sure I am understanding correctly: When you type PA_ALSA_PLUGHW=1 ./SampleApp/src/SampleApp ./Integration/AlexaClientSDKConfig.json DEBUG9, what exactly happens? Is there any output to the terminal? Does the command just hang?
You can either copy and paste the output, or you can give a screenshot (like you did above). Thanks!

I have taken a screen grab of the latest error with the cmake command. I have previously managed to make it run however.
PA_ALSA_PLUGHW=1 ./SampleApp/src/SampleApp ./Integration/AlexaClientSDKConfig.json DEBUG9  the command just hangs so there is no output to the terminal.

apologies! wrong screengrab! here is the cmake command.

The screenshot you posted is the cmake command not being found.  Can you post one where it runs?

Hi @gemma2301 I think you might have some missing dependencies. Can you try running this command again to make sure all required dependencies are installed?
sudo apt-get -y install \  git gcc cmake build-essential libsqlite3-dev libcurl4-openssl-dev libfaad-dev \  libssl-dev libsoup2.4-dev libgcrypt20-dev libgstreamer-plugins-bad1.0-dev \  gstreamer1.0-plugins-good libasound2-dev doxygen
after this please post the cmake command and the out put of the command here.

I am indeed missing dependencies. How should i reinstall those? see screengrab.

@gemma2301 Can you enter run this command before running the command to get the dependencies?
sudo apt-get upgrade

i ran the upgrade which seemed to run without problem. Is it possible to just install the individual missing packages? I can try that next.

when i try to install the packages individually i get an error unable to locate package

also please advise if i should be using a virtual environment. I have tried to troubleshoot the install package issues without luck so far.

@gemma2301 Can you enter run this command before running the command to get the dependencies?
sudo apt-get upgrade

I responded to this some days ago please see thread.

Hi can you run that command without the \ as one line?
sudo apt-get -y install git gcc cmake build-essential libsqlite3-dev libcurl4-openssl-dev libfaad-dev libssl-dev libsoup2.4-dev libgcrypt20-dev libgstreamer-plugins-bad1.0-dev gstreamer1.0-plugins-good libasound2-dev doxygen

I have tried this and am getting the following errors:
E: Failed to fetch http://raspbarian.raspberrypi.org
deb 404 not Found - IP <IP_ADDRESS> 80
unable to fetch some archives

i will attach a screen grab

@gemma2301,
This sounds like a more generic apt-get problem.  Googling the error message "unable to fetch some archives" I find the following possibly helpful bits of advice:
https://stackoverflow.com/questions/38743951/unable-to-fetch-some-archives-maybe-run-apt-get-update-or-try-with-fix-missin
Please let us know the problem has been resolved.
Best regards,
-SWH

Closing this due to inactivity. Please open a new issue if you continue to have problems. Thanks!


Include .hprof files when uploading artifacts

Motivation:
These are created when a test runs out of heap memory, and we need them to be able to effectively debug OOMEs in our builds.
Modification:
Make the upload-artifact action include any hprof files anywhere, when it wraps up the state of a failed build.
Result:
We should now get .hprof files included in the archives when a build fails with an OutOfMemoryError.

Huh, we actually run into some kind of file permission issue with this:
Run actions/upload-artifact@v2
  with:
    name: build-linux-x86_64-java11-unsafe-buffer-target
    path: **/target/surefire-reports/
  **/hs_err*.log
  **/*.hprof

    if-no-files-found: warn
  env:
    MAVEN_OPTS: -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.http.retryhandler.count=5 -Dmaven.wagon.httpconnectionManager.ttlSeconds=240
With the provided path, there will be 236 files uploaded
Starting artifact upload
For more detailed logs during the artifact upload process, enable step-debugging: https://docs.github.com/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging
Artifact name is valid!
Container for artifact "build-linux-x86_64-java11-unsafe-buffer-target" successfully created. Starting upload of file(s)
events.js:187
      throw er; // Unhandled 'error' event
      ^

Error: EACCES: permission denied, open '/home/runner/work/netty/netty/buffer/java_pid18546.hprof'
Emitted 'error' event on ReadStream instance at:
    at internal/fs/streams.js:120:12
    at FSReqCallback.oncomplete (fs.js:146:23) {
  errno: -13,
  code: 'EACCES',
  syscall: 'open',
  path: '/home/runner/work/netty/netty/buffer/java_pid18546.hprof'
}

interesting...


Merge conflict on fedora downstream version update for qm rpm

What happened? What is the problem?
i see a strange issue with packit updates on the qm package . The PRs in there are having a merge conflict with trying to bump versions from 0.5.7 to 0.6.0 when packit had already done a prior PR bump from 0.5.7 to 0.5.8
What did you expect to happen?
should not have had merge conflicts and should have correctly bumped from 0.5.8 to 0.6.0.
Example URL(s)
No response
Steps to reproduce
No response
What is the impacted category (job)?
Fedora release automation
Workaround

[X] There is an existing workaround that can be used until this issue is fixed.

Participation

[ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)

cc @dougsland

hi @lsm5 ! Thanks for reporting, from the first look this really doesn't look right. We need to investigate this more, I will have a look into our logs.

We will try to prioritise this issue since this should definitely not happen. From looking into the logs and the code, this is really strange as we always fetch the latest changes from the dist-git repo.

I have analyzed the open/merge branch history and found out that the 0.5.8 related branch was merged after the creation of the 0.6.0 related branch.
After we create a branch we do not automatically update/rebase it and for this reason it went out of sync
I think this work already scheduled could probably prevent this to happen again, what do you think @lbarcziova and @lachmanfrantisek?

branch
for release
action
time

f38
0.5.8
opened
2023-11-01 13:40:52

merged
2023-11-05 13:06:35

0.5.9
opened
2023-11-03 20:01:47

0.6.0
opened
2023-11-05 13:02:08

f39
0.5.8
opened
2023-11-01 13:40:27

merged
2023-11-05 13:06:11

0.5.9
opened
2023-11-03 20:00:40

0.6.0
opened
2023-11-05 13:01:47

rawhide
0.5.8
opened
2023-11-01 13:40:04

merged
2023-11-05 13:04:01

0.5.9
opened
2023-11-03 20:00:01

0.6.0
opened
2023-11-05 13:01:28

@majamassarini good catch! Yes, I think packit/packit#2182 should prevent this from happening.

I close this one and start to work on https://github.com/packit/packit/issues/2182


Connection to node doesn't work in 0.4.9

Describe the bug
In example connection to node fails on android, because webViewController is never initialized in _web in SubstrateService. Interesting fact that it works fine on iOS.
To Reproduce
Steps to reproduce the behavior:

Launch ./example
Tap 'connect' button

Expected behavior
I expect to get an initialized webview after calling plugin.sdk.init()
Smartphone:

Device: Mi 9T
OS: Android
Version 0.4.9

Additional context
Error:
[ERROR:flutter/lib/ui/ui_dart_state.cc(198)] Unhandled Exception: Null check operator used on a null value
  #0      WebViewRunner.evalJavascript package:polkawallet_sdk/service/webViewRunner.dart:199
  #1      WebViewRunner.connectNode package:polkawallet_sdk/service/webViewRunner.dart:221
  #2      PolkawalletApi.connectNode package:polkawallet_sdk/api/api.dart:93
  #3      _MyHomePageState._connectNode package:polkawallet_sdk_example/main.dart:115
  #4      _MyHomePageState.build.<anonymous closure> package:polkawallet_sdk_example/main.dart:159
  #5      _InkResponseState._handleTap package:flutter/…/material/ink_well.dart:1005

Works fine in 0.5.1


Update Travis

Sweet! :sparkles:
For what it's worth I love it when people summarize the problem and solution in the body of the comment (e.g. Get Travis CI to actually run the tests). A bit of extra context makes it a lot easier for people to review, which in turn makes it easier and quicker to get things merged and into production.
I've written a bit about good pull request messages here:
http://tinyletter.com/exercism/letters/exercism-pull-requests


Clean chassis from OVN when deleting EDPM nodes

The cleanup of edpm nodes takes care only of virsh instances. The patch also adds calls to OVN database to remove the nodes from OVN because often in the dev environments the IPs for newly created compute nodes are reused which doesn't play well with OVN.
JIRA: OSPRH-639

/ok-to-test


Avoid failing E2E CI/CD pipeline by switching to 'dynamic' nightly-cluster names

Description
Currently, the reconciler E2E CI/CD pipeline is failing caused by reaching the LetsEncrypt certificate rate limit:
https://status.build.kyma-project.io/job-history/gs/kyma-prow-logs/logs/nightly-main-reconciler-e2e
A longterm solution would be to use to use differnet cluter-names per day, e.g.

Monday = rec-nightly1
Tuesday = rec-nightly2
Wednesday = rec-nightly3
...

Expected result
E2E tests don't exhaust the LetsEncrypt certificate creation threshold by using each day a different cluster names.
Actual result
E2E test pipeline temporarily fails because the LetsEncrypt certificate threshold is reached by reusing the cluster-name every day.
Steps to reproduce

Troubleshooting

Fixed in https://github.com/kyma-project/test-infra/pull/4527.

@suleymanakbas91 : QQ - this failure from Friday evening is already known?
 2021/12/03 17:00:51 UTC [INFO] *************************************************************************************
 2021/12/03 17:00:51 UTC [INFO] * Connecting to nightly cluster
 2021/12/03 17:00:51 UTC [INFO] *************************************************************************************
 Error from server (NotFound): secrets "rec-night.kubeconfig" not found

https://storage.googleapis.com/kyma-prow-logs/logs/nightly-main-reconciler-e2e/1466814546730553344/build-log.txt


Wheel Assembly Documentation: 1.2 Cutting the Clamping Hub

Hi everyone,
Section 1.2 of the Wheel Assembly documentation (Cutting the Clamping Hub) lists the quantity of the 4mm Face Tapped Clamp Hub (S14) as 4. But the next section calls for 6 of the "4mm Face Tapped Clamp Hub (Modified)", therefore section 1.2 should have 6 as the count, not 4.
Not a huge deal, but I didn't read ahead so I only cut 4. Then the next day when I went back to the assembly I realized the 4-count was just a mistake. I had just assumed it was on purpose and I would find out why later :)
Kevin

This has been fixed and merged


RunLength codec

It would be possible to implement a simple run length codec, e.g., making use of https://gist.github.com/nvictus/66627b580c13068589957d6ab0919e66. This would very likely not offer any better compression than proper compressors, but might be interesting to try out.

Migrated to https://github.com/alimanfoo/numcodecs/issues/2


Support using entt::type_info as key in associative containers

I want to use entt::type_info as the key in an associative container (e.g. std::map). However, type_info has some problems.
template<typename Type>
type_info type_id() ENTT_NOEXCEPT;

could be constexpr if they didn't include type_seq. My knowledge with constexpr seems to be lacking here, so it's not clear that it's possible to do this at all, so maybe this aspect of the issue can be ignored.
That being said, the type_id() function should be [[nodiscard]]. As a (mostly) pure function, there's no reason to call it without doing something with the result. The default implementation being constexpr (if possible) and [[nodiscard]] wouldn't influence explicit specializations that the end user makes, so probably best not to rely on that inside of EnTT, but if the user of EnTT doesn't implement non-constexpr specializations of type_id<>() then they could take advantage of that. (Again, assuming it's even possible to use constexpr here, which it may not be)

type_seq, type_hash and type_name should have implicit conversion operators to allow for short-hand usage.
template<typename Type, typename = void>
struct type_seq final {
    [[nodiscard]] static constexpr id_type value() ENTT_NOEXCEPT;
    constexpr operator id_type() const ENTT_NOEXCEPT { return value(); }
};

template<typename Type, typename = void>
struct type_hash final {
    [[nodiscard]] static constexpr id_type value() ENTT_NOEXCEPT;
    constexpr operator id_type() const ENTT_NOEXCEPT { return value(); }
};

template<typename Type, typename = void>
struct type_name final {
    [[nodiscard]] static constexpr std::string_view value() ENTT_NOEXCEPT;
    constexpr operator std::string_view() const ENTT_NOEXCEPT { return value(); }
};

Use like:
void foo(id_type);
foo(entt::type_seq<MyType>{});
foo(entt::type_seq<MyType>::value()); // same as above.
foo(entt::type_hash<MyType>{});
foo(entt::type_hash<MyType>::value()); // same as above.

void bar(std::string_view);
foo(entt::type_name<MyType>{});
foo(entt::type_name<MyType>::value()); // same as above.

type_seq, type_hash, type_name, and type_info should define comparison operators. If you want to be lazy, just operator<=> from C++20 would probably work fine. It's not clear to me that defining comparisons against either of id_type of std::string_view would make sense on their own, but EnTT may have internal rules that I'm not aware of that require uniqueness for both of these independently and also together, and as such maybe it does make sense.

Is there a reason for id_type being used for both type_hash and type_seq ? I would have expected these to be different types, since they are inherently not comparable against each other.

Also, I'm kind of confused at:

Overloads of internal::type_hash and internal::type_name with char and int, but only (apparently?) the int overload used? What's the goal of having two overloads, and would it be easier for the reader to understand if these were std::true_type / std::false_type, or specific empty tag-structs that clearly denote what the two overloads are for?
Inconsistent use of static and constexpr for intermediate variables for all of these functions.

For 2, some examples:
All of these variables can be static constexpr, including pretty_function. Without marking them as static constexpr, there's a good chance the compiler will do work at runtime if these functions are called at runtime on lower optimization levels. (Observed in the wild with MSVC, for example, on my job's codebase)
template<typename Type>
[[nodiscard]] constexpr auto stripped_type_name() ENTT_NOEXCEPT {
#if defined ENTT_PRETTY_FUNCTION
    std::string_view pretty_function{ENTT_PRETTY_FUNCTION};
    auto first = pretty_function.find_first_not_of(' ', pretty_function.find_first_of(ENTT_PRETTY_FUNCTION_PREFIX)+1);
    auto value = pretty_function.substr(first, pretty_function.find_last_of(ENTT_PRETTY_FUNCTION_SUFFIX) - first);
    return value;
#else
    return std::string_view{};
#endif
}

The variables in this function can be static as well.
template<typename Type, auto = stripped_type_name<Type>().find_first_of('.')>
[[nodiscard]] static constexpr id_type type_hash(int) ENTT_NOEXCEPT {
    constexpr auto stripped = stripped_type_name<Type>();
    constexpr auto value = hashed_string::value(stripped.data(), stripped.size());
    return value;
}

Reading https://github.com/skypjack/entt/wiki/Crash-Course:-core-functionalities#almost-unique-identifiers
I have a suggestion for how to help overcome the conflicting type names + hashes.
Consider providing a macro that can be defined with a user specified prefix or suffix to be included in the typename that is hashed.
You could provide 4 such macros.

Prefix / suffix for type_name itself.
prefix / suffix for hash, which also would include the prefix/suffix for type_name, if provided.
These could, optionally, provide the consumer of entt a mechanism to avoid multiple dlls having conflicting hashs, though they would need to be used with care, certainly.

A final consideration.
It would be an ABI break, but what about using an inline template variable for type_seq, type_hash, type_name, and eschew the ::value() functions entirely?
E.g.
#if defined ENTT_PRETTY_FUNCTION
    template<typename TYPE_T>
    inline id_type type_hash = internal::type_hash<Type>(0);
#else
    template<typename TYPE_T>
    inline id_type type_hash = type_seq<Type>::value();
#endif

template<typename TYPE_T>
inline std::string_view type_name = internal::type_name<Type>(0);

This is... huge. 😄 Let's try to answer all of your doubts.

I want to use entt::type_info as the key in an associative container (e.g. std::map).

It's not really meant for that, as it isn't std::type_info. You should use the sequential identifier or the hashed name as a key. They are integral types and offer out of the box all you need for that already.

However, type_info has some problems.
template<typename Type>
type_info type_id() ENTT_NOEXCEPT;

could be constexpr if they didn't include type_seq.

Yeah, but it includes type_seq for a reason. So... 🙂

That being said, the type_id() function should be [[nodiscard]].

Good catch. 👍 You're right.

The default implementation being constexpr (if possible)

To make type_id constexpr, type_info should have at least a constexpr constructor. It doesn't make sense at the moment, since type_seq isn't constexpr but in theory you could redefine it and make it constexpr.
To be honest, I don't really see a reason for that. If you want a constexpr key for your maps for some reason, you should rather use type_hash<T>::value() directly probably.

type_seq, type_hash and type_name should have implicit conversion operators to allow for short-hand usage.

value is static, the conversion operator couldn't be so. Not sure I see the advantages here, but still, it seems feasible.

type_seq, type_hash, type_name, and type_info should define comparison operators. If you want to be lazy, just operator<=> from C++20 would probably work fine.

I can't be lazy here, because EnTT is a C++17 library at the moment.
In any case, they shouldn't define comparison operators at all. Becuase value is static, they don't need to. The returned value is also already comparable (it's an integral type after all).
I don't see why we should add more and more code to maintain for no real benefits.

Is there a reason for id_type being used for both type_hash and type_seq ? I would have expected these to be different types, since they are inherently not comparable against each other.

type_hash is type_seq when for example ENTT_STANDARD_CPP is defined. So, they may be the same, yeah, and are definietely comparable.
It's like saying that the returned values of two different hashing functions aren't inherently comparable. They are in fact, since probably the two functions both return integral values. 🤷♂

Overloads of internal::type_hash and internal::type_name with char and int, but only (apparently?) the int overload used? What's the goal of having two overloads, and would it be easier for the reader to understand if these were std::true_type / std::false_type, or specific empty tag-structs that clearly denote what the two overloads are for?

It's a sfinaed call. See auto = stripped_type_name<Type>().find_first_of('.').
All this is required to take in account some nasty issues with older compilers. I won't go in details because it would require the whole Sunday 😄 but the commit messages as well as gitter/discord contain tons of details on these points.

Inconsistent use of static and constexpr for intermediate variables for all of these functions.

Same as above unfortunately. It's not inconsistency. These variables are from macroed sections that just work for a compiler or the other.

For 2, some examples:
All of these variables can be static constexpr, including pretty_function.

Well, no, this is a good example already. PRETTY_FUNCTION is a non-standard extension and therefore you have no guarantees. In particular, it wasn't constexpr in older version of GCC (< 8 if I remember it correctly).

Without marking them as static constexpr, there's a good chance the compiler will do work at runtime if these functions are called at runtime on lower optimization levels. (Observed in the wild with MSVC, for example, on my job's codebase)

In theory, that part is designed to avoid this. Either with constexpr values or using static variables where the constexpr flavor isn't available (see above). So, it shouldn't do work at runtime. Of course, there may be an error but I need a reproducible example in this case.

I have a suggestion for how to help overcome the conflicting type names + hashes.

All type_* utilities are sfinae-friendly. You can already do this if needed. 👍

It would be an ABI break, but what about using an inline template variable for type_seq, type_hash, type_name, and eschew the ::value() functions entirely?

It was like that initially. However, it breaks when __declspec(dll*) is defined (see ENTT_API).

I want to use entt::type_info as the key in an associative container (e.g. std::map).

It's not really meant for that, as it isn't std::type_info. You should use the sequential identifier or the hashed name as a key. They are integral types and offer out of the box all you need for that already.

Respectively, I disagree. You make it clear in the 3.6.0 release notes that hash collisions can occur, so the combination of type_seq, type_hash, and type_name are more unique than any of the three individually. Obviously there's the additional cost of an extra integer comparison, and a pointer+size_t comparison, but that's cheap in the grand scheme of things. Much better than full string comparisons, which my codebase is currently doing anyway.
Adding
#ifdef C++20
 operator<=>(type_info) = default;
#endif

should work out of the box for users of EnTT that use C++20 compilers, without any additional work from you.

However, type_info has some problems.
............
could be constexpr if they didn't include type_seq.

Yeah, but it includes type_seq for a reason. So... slightly_smiling_face

The function itself can still be constexpr, because your users might make a specialization for type_seq that is constexpr.
constexpr template functions will degrade to non-constexpr when the implementation can't be. But non-constexpr templates can never be used as constexpr.

The default implementation being constexpr (if possible)

To make type_id constexpr, type_info should have at least a constexpr constructor. It doesn't make sense at the moment, since type_seq isn't constexpr but in theory you could redefine it and make it constexpr.
To be honest, I don't really see a reason for that. If you want a constexpr key for your maps for some reason, you should rather use type_hash<T>::value() directly probably.

the type_info struct itself can be constexpr so long as entt::id_type and std::string_view can be constexpr constructed.
I would consider it reasonable to use a macro to allow users of entt to turn that off if they want to use an entt::id_type that can't be constexpr constructed.
I thought that C++20 added some kind of constexpr(bool) notation, but I can't find any documentation on that, so maybe it's something being considered for c++23.

type_seq, type_hash and type_name should have implicit conversion operators to allow for short-hand usage.

value is static, the conversion operator couldn't be so. Not sure I see the advantages here, but still, it seems feasible.

My objective with this request is merely to reduce typing.

type_seq, type_hash, type_name, and type_info should define comparison operators. If you want to be lazy, just operator<=> from C++20 would probably work fine.

I can't be lazy here, because EnTT is a C++17 library at the moment.
In any case, they shouldn't define comparison operators at all. Becuase value is static, they don't need to. The returned value is also already comparable (it's an integral type after all).
I don't see why we should add more and more code to maintain for no real benefits.

My meaning was to only offer this for C++20 environments. E.g. #ifdef C++20 /**/ #endif kind of thing.
I can see your intention for type_seq, type_hash, and type_name, though I'm not completely convinced there's no utility to having the comparison operators provided.
We already talked about type_info above, so i'll not address that twice.

Is there a reason for id_type being used for both type_hash and type_seq ? I would have expected these to be different types, since they are inherently not comparable against each other.

type_hash is type_seq when for example ENTT_STANDARD_CPP is defined. So, they may be the same, yeah, and are definietely comparable.
It's like saying that the returned values of two different hashing functions aren't inherently comparable. They are in fact, since probably the two functions both return integral values. man_shrugging

They are only comparable when ENTT_STANDARD_CPP is defined, or when a specialization is provided by the end-user that makes them the same.
It's true that two different hashing algorithm might return an integral type, and thus the outputs can be compared in the meaning of integer comparisons, but it's not a meaningful comparison. If your MD5 and SHA256 algorithm are returning the same integral value, that doesn't speak much to whether the items that they hashed to get that integral value are comparable in any generic sense.
It happens to be the case that you've design the type_hash to use type_seq as a fallback, but I don't think that it's reasonable to claim that they return concepts / types that are comparable in any meaningful way without relying on insider knowledge.
My recommendation is that you make these functions return different types, and define some id_hash_from_seq(id_seq) function that, by default, simply returns the provided numeric value. This way, if the end-user provides different types for hashing versus sequencing, they have a safety valve to adapt their custom types to the internals of the entt framework (or perhaps this would be adapting the entt framework to their custom type).
The default behaviour can, of course, remain that id_hash and id_seq are just integers, if the user of entt doesn't provide their own definitions.
Similarly, I recommend providing an end-user facing way to tweak the type_name item. For example, I have a custom string implementation that is a better fit for the workload that I'm doing, which is API comparable (nearly identical, really) to std::string_view, and I can see using that for type_info instead of std::string_view

Overloads of internal::type_hash and internal::type_name with char and int, but only (apparently?) the int overload used? What's the goal of having two overloads, and would it be easier for the reader to understand if these were std::true_type / std::false_type, or specific empty tag-structs that clearly denote what the two overloads are for?

It's a sfinaed call. See auto = stripped_type_name<Type>().find_first_of('.').
All this is required to take in account some nasty issues with older compilers. I won't go in details because it would require the whole Sunday smile but the commit messages as well as gitter/discord contain tons of details on these points.

Ah. I see.
Wouldn't it be more appropriate to use your choice type from type_traits.hpp ?
I fully understand the issues with supporting older compilers, I've been dealing with code exactly like what you have here for years, which is why I'm making the recommendations I am.

Inconsistent use of static and constexpr for intermediate variables for all of these functions.
Well, no, this is a good example already. PRETTY_FUNCTION is a non-standard extension and therefore you have no guarantees. In particular, it wasn't constexpr in older version of GCC (< 8 if I remember it correctly).

Then how can the whole function be constexpr, if the individual variables cannot?
To be perfectly honest, I don't see how it's worth it to allow newer compilers to suffer because of older compilers. The way I'd approach this kind of thing is to put an #ifdef OLD_BROKEN_COMPILER around the entire function, and let the non-broken compiler version of the function use the correct keywords.

Without marking them as static constexpr, there's a good chance the compiler will do work at runtime if these functions are called at runtime on lower optimization levels. (Observed in the wild with MSVC, for example, on my job's codebase)

In theory, that part is designed to avoid this. Either with constexpr values or using static variables where the constexpr flavor isn't available (see above). So, it shouldn't do work at runtime. Of course, there may be an error but I need a reproducible example in this case.

In the general sense, static variables without the constexpr keyword, have the cost of an atomic initializer guard flag, and ugly code gen. Sometimes on high (e.g. -O3) compilation settings those restrictions evaporate, and MSVC is especially hard to make it not emit the atomic initializer code. But "static constexpr" never has that, as far as I've ever been able to test.

I have a suggestion for how to help overcome the conflicting type names + hashes.

All type_* utilities are sfinae-friendly. You can already do this if needed. +1

My basic point was that if it's enough of a possibility that you have to write several paragraphs about the subject in the release notes, it's a situation that will happen enough that you would want to provide a built in mechanism to overcome the problem.
By default, the solution should work for 90% of the cases. Then, you provide a macro that can cover 9% of the additional cases, leaving the library as solving 99% of cases. Then, for the remaining 1%, they can use the sfinae method for all of their types, to work around whatever broken toolchain that they are using.
If it wasn't a common enough problem for you to write about how to work around it, then something like a macro / constexpr defined prefix / suffix system wouldn't be a suggestion worth making.

It would be an ABI break, but what about using an inline template variable for type_seq, type_hash, type_name, and eschew the ::value() functions entirely?

It was like that initially. However, it breaks when __declspec(dll*) is defined (see ENTT_API). So, I had to change it because of a compiler issue. man_shrugging

Ah, I understand.

hash collisions can occur, so the combination of type_seq, type_hash, and type_name are more unique than any of the three individually

I would discourage this practice. In case of collisions, you can either avoid them working externally (that is, you can use a different name for a colliding element) or you can specialize on a per-type basis the type hash struct. In both cases, you've a much faster alternative to comparing sequence, hash and name all the times, especially if you consider that the three aren't required nor guaranteed to be compile-time expressions.

Adding
#ifdef C++20
 operator<=>(type_info const&) = default;
#endif

should work out of the box for users of EnTT that use C++20 compilers, without any additional work from you.

I'd rather avoid this too. EnTT is a C++17 library at the moment, aimed at working in environment where C++17 is the commonly supported revision of the language. I don't want an #ifdef C++20 token to leak all over the codebase.
Sooner or later, I'll freeze the C++17 version and start working on a C++20 one, as it happened when I moved from C++14 to C++17. This is still a sort of free time project, don't be fooled by the fact that many use it. I don't want and don't have the bandwidth to support multiple revisions of the standard at once, nor I think that already supporting C++20 would be a good idea.

The function itself can still be constexpr, because your users might make a specialization for type_seq that is constexpr.
[...]
the type_info struct itself can be constexpr so long as entt::id_type and std::string_view can be constexpr constructed.

Yeah, makes sense.

I would consider it reasonable to use a macro to allow users of entt to turn that off if they want to use an entt::id_type that can't be constexpr constructed.

You don't really need a macro here. Just don't create your objects with compile-time expressions. A constexpr constructor doesn't mean that all created objects are constexpr just because.

type_seq, type_hash and type_name should have implicit conversion operators to allow for short-hand usage.

My objective with this request is merely to reduce typing. The extra ::value() needing to be repeated every time I want to query the type_name is quite annoying.

🙂

type_seq, type_hash, type_name, and type_info should define comparison operators. If you want to be lazy, just operator<=> from C++20 would probably work fine.

My meaning was to only offer this for C++20 environments. E.g. #ifdef C++20 /**/ #endif kind of thing.

This isn't really a solution. Even if I wanted to leak that ifdefall over the codebase, I'd still need to provide an alternative for non-C++20 users.
EnTT is mainly used in the game industry and C++20 isn't a thing there yet (actually, it's not a thing in general yet, if we consider compiler support and portability).

I can see your intention for type_seq, type_hash, and type_name, though I'm not completely convinced there's no utility to having the comparison operators provided. Especially if you add the comparison against entt::id_type, which cuts down on boilerplate that your end users would have to use. E.g.
entt::id_type bob;
if(bob == type_hash<MyType>{}) { ... }

Is a simplified example of why this would be useful. (though, the implicit conversion would cover THIS situation).

As a side note, to make this works, a conversion operator would be enough.

Here's a more complex one.
template<typename ONE_T, typename TWO_T>
static_assert(MyLib::do_complex_thing_returning_entt_type_name<ONE_T> == MyLib::do_DIFFERENT_Complex_thing_returning_entt_type_name<TWO_T>);

The provision of comparison operators between type_hash and other type_hash instantiations would cut down on end-user boilerplate. The goal isn't to provide functionality they can't accomplish on their own, but it does help with avoiding annoying code patterns.

I don't get the example. Something like type_hash isn't meant to be instantiated and only offers static functions in its API.
If you really want to avoid this annoying code pattern:
do_complex_thing_returning_entt_type_name<ONE_T>::value() == do_complex_thing_returning_entt_type_name<TWO_T>::value()

You can make your function return the right type, that is, the hashed value. It already supports all comparison functions and seems like the right thing to return here.

I don't see why we should add more and more code to maintain for no real benefits.

One tiny inline function per type (for 3 types) is not very much of a maintenance burden. I would understand your reluctance if my proposal required hundreds of lines of code, of course.

Unfortunately, it isn't a tiny inline function. To make it work with C++17, it's 5 operators for 3 classes. Just to offer what a call to ::valuealready offers out of the box. So, yeah, I'm a bit reluctant. 🙂

It happens to be the case that you've design the type_hash to use type_seq as a fallback, but I don't think that it's reasonable to claim that they return concepts / types that are comparable in any meaningful way without relying on insider knowledge of how EnTT is built, and I would further argue that it's a serious end-user bug if they are comparing type_hash and type_seq's returned id_types against each other. Enough of one that it should be a compilation error, IMHO.
In one of my codebases, I use something like enum class MyId : int16_t {} and enum class MyOtherId : int16_t {} to make "opaque id types" incomparable to each other (without static casts, of course)

I see what you mean. Though, it's like pretending that std::vector<T>::capacity and std::vector<T>::size didn't return the same type because users could compare them by mystake. I mean, sure, users can do it, but I don't want to make it more cumbersome for all other users that decided to not shoot in their feet (where all other users means me too, because these two functions are widely used within the rest of the library).

My recommendation is that you make these functions return different types, and define some id_hash_from_seq(id_seq) function that, by default, simply returns the provided numeric value. This way, if the end-user provides different types for hashing versus sequencing, they have a safety valve to adapt their custom types to the internals of the entt framework (or perhaps this would be adapting the entt framework to their custom type).

It's not that easy unfortunately. The per-type sfinae-friendly nature requires that the types are fixed and known in advance.
So, users cannot decide all of a sudden that their hashing functions return a struct my_type without breaking the internals of the library. It may be possible with a bunch of macros used literally everywhere, but imho there is no real advantage in this kind of flexibility.

Similarly, I recommend providing an end-user facing way to tweak the type_name item. For example, I have a custom string implementation that is a better fit for the workload that I'm doing, which is API comparable (nearly identical, really) to std::string_view, and I can see using that for type_info instead of std::string_view

Same as above. We can change the required type, but it's a little annoying to make it fully customizable and it probably requires its own macro. As for the name, it's limited in scope and may be viable. Though, I'd probably turn it in a char *and size pair, something that does fit the vast majority of reasonable cases.

I could also see a use-case where a user of entt would want their type_name to return an index / iterator to a global container that has the std::string_view, with an implicit conversion operator, because their use of type_name for some reason takes up too much storage, and they want to slim things down, but pay more for rendering the type_name into an actual string. Couldn't say beyond that I can see how someone would go about doing that.

True. I can see how users could want to do lot of things that aren't allowed by this library. Though, we can't design for maximum flexibility and offer all possible customization points to match all cases that could ever knock at our door. I don't want 1M macros nor to have to maintain ugly code just because someone, who knows when, could want to do who knows what.
EnTT offers some tools. It has customization points for a lot of things here and there, while it took some decisions and set some constraints somewhere else for many reasons.
The type_info class is an example of this. It's designed as a sfinae-friendly tool that users can customize to some degree. If it doesn't fit the requirements, well, nothing prevents users from rolling a better tool for the purpose.

Wouldn't it be more appropriate to use your choice<N> type from type_traits.hpp ?

Well, yes and no. For two overloads, you don't need it and it's one less include, other then less template specializations.

Then how can the whole function be constexpr, if the individual variables cannot? Your explanation reminds me of the similar compiler bugs that I encountered with GCC's handling of the PRETTY_FUNCTION variable. The PRETTY_FUNCTION variable may not be fully specified, and thus compiler specific, but GCC's handling of it has been simply broken for a long time.

The function within type_name is constexpr, but its constexprness depends on the invoked function. internal::type_name is sfinaed instead, constexpr when the pretty function is constexpr, not constexpr otherwise. So, overall, the type name value is constexpr if the value at the source is constexpr, that is, if the compiler offers a constexpr pretty function.
Not sure I get your objection. Are you experiencing problems with this function or it's just a guess that it may not work?

To be perfectly honest, I don't see how it's worth it to allow newer compilers to suffer because of older compilers. The way I'd approach this kind of thing is to put an #ifdef OLD_BROKEN_COMPILER around the entire function, and let the non-broken compiler version of the function use the correct keywords.

That's what's happening here. The if-old-compiler part is buried in another file, because I don't want to leak this kind of things all over the codebase. Though, yeah, if you put all pieces together, this is exactly what's happening. My feeling is that we are only discussing of a stylistic choice, unless I'm missing the problem you're trying to point out.
There is no compiler that suffers because of another compiler at the moment. At least, none of which I'm aware, but I may be wrong of course. If there is an actual problem, a reproducible example to explain it would really help.

In the general sense, static variables without the constexpr keyword, have the cost of an atomic initializer guard flag, and ugly code gen. Sometimes on high (e.g. -O3) compilation settings those restrictions evaporate, and MSVC is especially hard to make it not emit the atomic initializer code. But "static constexpr" never has that, as far as I've ever been able to test.

Though, here the problem is the opposite one. You pointed out a constexpr variable without a static keyword, not a static variable without a constexpr keyword. The former should emit the same code in all cases. Am I wrong?

My basic point was that if it's enough of a possibility that you have to write several paragraphs about the subject in the release notes, it's a situation that will happen enough that you would want to provide a built in mechanism to overcome the problem.
By default, the solution should work for 90% of the cases. Then, you provide a macro that can cover 9% of the additional cases, leaving the library as solving 99% of cases. Then, for the remaining 1%, they can use the sfinae method for all of their types, to work around whatever broken toolchain that they are using.

I wrote a paragraph in the documentation because the documentation contains a paragraph for... literally... everything! 😄
So far, I've never encountered nor I've ever been reported of a conflict to be honest. EnTT uses a possibly constexpr fnv-1a hashing algorithm in a space of 32b by default, 64b if you like. You can customize the hashing function on a per-traits and per-type basis if needed and the library is usually used in contexts where users have full control on the names to hash.
I'm pretty confident that the solution works for 99% of cases out of the box and the customization points can solve the remaining 1%. Two additional macros seem to me cumbersome, especially if you consider that users can specialize the type_name class for all types at once already and add the prefix/postifx extension on their own if needed.

If it wasn't a common enough problem for you to write about how to work around it, then something like a macro / constexpr defined prefix / suffix system wouldn't be a suggestion worth making.

It's definitely not a common enough problem. 🙂
I wrote about the customization points as I wrote about anything else in the library.

I'm closing this issue because I ported upstream the relevant changes and keep thinking that the suggested solution of using the hashed value rather than a type_info object is the right thing to do here.
I don't see any other change to perform, but I must admit that the discussion was very interesting and I learnt a few things of which I wasn't aware. So, thank you for your time.
Feel free to continue the discussion and to suggest other changes that I may have missed if required. Thanks.

We've gone deep enough into the other subjects that I brought up that I don't think those need to be addressed any further.
But I did have a small number of followups.

Unfortunately, it isn't a tiny inline function. To make it work with C++17, it's 5 operators for 3 classes. Just to offer what a call to ::valuealready offers out of the box. So, yeah, I'm a bit reluctant. 🙂

I don't understand how this code is 5 operators for 3 classes? It's three 1-liners.
template<typename Type, typename = void>
struct type_seq final {
    [[nodiscard]] static constexpr id_type value() ENTT_NOEXCEPT;
    constexpr operator id_type() const ENTT_NOEXCEPT { return value(); }
};

template<typename Type, typename = void>
struct type_hash final {
    [[nodiscard]] static constexpr id_type value() ENTT_NOEXCEPT;
    constexpr operator id_type() const ENTT_NOEXCEPT { return value(); }
};

template<typename Type, typename = void>
struct type_name final {
    [[nodiscard]] static constexpr std::string_view value() ENTT_NOEXCEPT;
    constexpr operator std::string_view() const ENTT_NOEXCEPT { return value(); }
};

Were you responding to both my request for operator<=> and also implicit conversion operators at the same time?

I see what you mean. Though, it's like pretending that std::vector<T>::capacity and std::vector<T>::size didn't return the same type because users could compare them by mystake. I mean, sure, users can do it, but I don't want to make it more cumbersome for all other users that decided to not shoot in their feet (where all other users means me too, because these two functions are widely used within the rest of the library).

Forgive me, but I just don't see how your counter example applies.
You do want to check if the capacity of a vector is larger than or equal to it's current size (or it's current size + some number) in lots of situations, because that's how you check to see if you need to allocate more space. std::vector<T>::resize and std::vector<T>::reserve. The API of std::vector<T>::capacity and std::vector<T>::size explicitly says that they return values that represent the same concept and are intended to be comparable. E.g. "number items". For size, it's "number items in the container" and capacity it's "number of items that the container can hold before reallocating".
I cannot think of a situation where comparing a entt::type_seq and a entt::type_hash is ever a valid thing to do. Even for code where ENTT_STANDARD_CPP is defined, those codebases can, and should, use the appropriate comparison.
Could you give me an example where comparing a seq to a hash is the best approach over comparing a seq to a seq and a hash to a hash ?

Were you responding to both my request for operator<=> and also implicit conversion operators at the same time?

I guess so, yeah. 😄 Let me create a dedicate issue for that. 👍

You do want to check if the capacity of a vector is larger than or equal to it's current size

Ahah, fair enough. Not the best example ever. 🙂
Let's say that it's as if someone asked to differentiate the return types of offsetof and vector<T>::size or any other method that returns an std::size_t, or even the size_type of a vector and that of a map and so on. The fact is that even the standard library has a sort of opaque and platform dependent catch-all type used all over, namely std::size_t. It's how things work and nobody ever considered the possibility of better encapsulating these types by making them strong integral types that you can't mix.
As for EnTT, there is no situation in which comparing the value returned by type_seq and that returned by type_hash makes sense as far as I can tell, but this doesn't mean that they should have different types. I don't see any case in which offsetof(clazz, member) == vec.size() makes sense too, but I can do it if I like and I'm fine with it.
The main problem is that giving them actual different types would complicate some things, break existing code and help only in the case in which users decide to compare apples with pears, that is imho an error user side that shouldn't be fixed by the library itself, as you correctly pointed out:

those codebases can, and should, use the appropriate comparison


[#3] [Chore] Create the base React-app

#3

What happened 👀

[x] bootstrap a fresh new app with the npx create-react-app my-app --template typescript command (using typescript)
[x] update README.md to include development commands
[x] eject the project from create-react-app custom helpers

Insight 📝
N/A
Proof Of Work 📹

Project is running

Project can build
Tests are passing

README.md

@carryall
Hehe good remark, I did not know we had a react template :P
I think I will continue on the non-nimble one, this might add some tasks but I can learn with these. On a real project, I might use Nimble template to save time ;-)
Thanks for sharing that  :)


[Bug]: Crash when booting game only sometimes? (pneumaticcraft compat issue?)

Minecraft Version
1.20.1
Mod Loader and Version
Forge 47.1.0
Ad Astra! Version
1.15.1
Addon Mod Version (This Mod)
5.1
The details

Install Ad Astra
Install Giselle Addon
Have pneumaticcraft installed.
Boot game.
Crash.
profit.

Crash-report: https://gist.githubusercontent.com/Gbergz/c57081d1016d03ea0b31c79d915fe7ee/raw/5b9661c0917c62dda41c315c3798d0a5645642f2/gistfile1.txt
Note: It's a weird one because this only happens on some systems, even then not always.

Mod loading order is looks weired.

Something that I can do about that myself or is this your doing?

I failed to reproduce it. but found candidate to fix.
Can you test with new version(5.2)?
https://legacy.curseforge.com/minecraft/mc-mods/ad-astra-giselle-addon/files/4630415

Seems to have fixed it for people who tested.

OK good, thanks for report.


Project status?

I have my own simple component object system and am interested in cache coherency. Currently I'm just heap allocating everything, but plan to use pools (much faster allocation and memory usage efficiency), but then you are iterating over the data in a random order.
I wondered what you learnt from the project, or if abandoned, why so? The other reference I have for this is the Insomniac guys.

The projects abandoned in the sense I only worked on it as a learning exercise when I was a bit green in engine design/C++. I sometimes refer back to it.

You need to amortise deletes or introduce the concept of a bulk delete/sleep/wake. The object swapping in the negative case for a large pool almost looks like a GC pause in a profiler.
Making this data structure thread safe will be hard, although you could do it with read/writer locks in principle.
I'm not entirely sure the ComponentReference is bug free. I would probably use a handles next time as they are far simpler than smart pointers.
The cache coherency of the pseudo stack layout is real. Although I would maybe think about the strategy a little more carefully.
The pool as a piece of Architecture fundamentally limits the Structs of Arrays layout optimisation, which is probably a deal breaker for any serious engine work. Although I have seen SoA engines that do a similar thing to this pool.


Added a optional Dashboard Title

Handy for instances where a single screen may show multiple Dashboards on rotation

Nice, only problem is updating the dashboard column height to 90vh means that there's a gap when the title isn't set :(

Ah worked it out, need moar flex boxes

Ahh, kewl.  Yeah good point, I came up with a solution very similar to yours @mikefarah.  :+1:


Create a data connector for Google Drive

Create a data connector that pulls documents from Google Drive, stores them locally (at least temporarily for processing), and runs them through unstructured.partition.auto.
See Adding Data Connectors for details on how to get started. Make sure to include a link to this issue when submitting a PR.
Definition of Done

The checklist has been completed.
The connector is able to process a single document.
The connector is able to process all documents in a Google Drive folder, recursively.
For now, it is OK to process only doc types that unstructured.partition.auto is capable of processing. Google Drive documents should be converted to PDF or Word Doc for processing (unless there is a better way).
Bonus points: the ability to filter by document type.

Hi @cragwolfe I'd like to give this a shot.

@HAKSOAT , sounds good, please go ahead! Thanks for mentioning it. :)

Hi @cragwolfe what about creating a separate issue to create a connector for Google Cloud Storage (GCS) too? If so I'd like to contribute and tackle that 👍🏻

Good idea, added https://github.com/Unstructured-IO/unstructured/issues/301 .