Add bump mapping based on textures

Not sure if this is feasible without giving too much "fake" feelings. Should be optional.
Specular mapping would also be nice.

This must be impossible because the terrain shaders don’t know where the surface normal is pointing to. I know Matts achieved something in this area, but I have no idea what he did.


S3 metadata is out of date from the DB (catalogPath)

Problem
We changed catalogPath to include the indicator short name in our MySQL metadata:

From: grapher/worldbank_wdi/2022-05-26/wdi/wdi
To: grapher/worldbank_wdi/2022-05-26/wdi/wdi#ny_gdp_mktp_pp_kd

However, this change did not propagate to R2, and is missing from here:
https://api.ourworldindata.org/v1/indicators/446382.metadata.json
Impact
The catalogPath field is mostly annoying for the admin, but it raises the question of whether there's any other changes we've made just to the DB.
Technical notes

My hypothesis is that we updated the DB, instead of updating the ETL and triggering a full rebuild, which would have regenerated the data and metadata files

However, we have probably done a full rebuild since the WDI update -- does metadata get fully rebuilt in R2 on rebuild?

If we want the ability to update the DB then flush metadata, we might need a special command for that

https://github.com/owid/owid-grapher/commit/8cca1479d99d567b12356e044400457943ef00eb

Looks like this WDI release is explicitly excluded from the build, perhaps it was breaking: https://github.com/owid/ops/blob/main/templates/etl-prod/etl-prod.sh#L81C2-L81C2


luaPackages.luaexpat: unbreak, it builds just fine

Motivation for this change
While upgrading my Jabber server to 20.03 I noticed that the package was
marked broken but builds just fine.
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

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

@GrahamcOfBorg test prosody


sqlite3 8-bit bytestring error while loading vcf into gemini

Hello Gemini developers,
I am running into the following error when trying to load a vcf into gemini:
insert error trying 1 at a time: Traceback (most recent call last):   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/bin/gemini", line 7, in <module>     gemini_main.main()   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/gemini/gemini_main.py", line 1248, in main     args.func(parser, args)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/gemini/gemini_main.py", line 311, in loadchunk_fn     gemini_load_chunk.load(parser, args)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/gemini/gemini_load_chunk.py", line 914, in load     gemini_loader.populate_from_vcf()   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/gemini/gemini_load_chunk.py", line 244, in populate_from_vcf     database.insert_variation(self.c, self.metadata, self.var_buffer)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/gemini/database.py", line 452, in insert_variation     trans.execute(stmt, b)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 945, in execute     return meth(self, multiparams, params)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/sqlalchemy/sql/elements.py", line 263, in _execute_on_connection     return connection._execute_clauseelement(self, multiparams, params)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1053, in _execute_clauseelement     compiled_sql, distilled_params   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1189, in _execute_context     context)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1402, in _handle_dbapi_exception     exc_info   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/sqlalchemy/util/compat.py", line 203, in raise_from_cause     reraise(type(exception), exception, tb=exc_tb, cause=cause)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1182, in _execute_context     context)   File "/gpfs/fs1/data/bcbio_data_1.0.4/anaconda/lib/python2.7/site-packages/sqlalchemy/engine/default.py", line 470, in do_execute     cursor.execute(statement, parameters) sqlalchemy.exc.ProgrammingError: (sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless you use a text_factory that can interpret 8-bit bytestrings (like text_factory = str). It is highly recommended that you instead just switch your application to Unicode strings.  I googled the bytestring error and it seems to have something to do with compression when storing values as a blob. Here's a relevant post on Stack Overflow
I would really appreciate any help or insight into this issue and how I can fix my vcf so that it is compatible with gemini
Thanks,
Moiz

Hi, can you verify that you have the latest version of gemini?

Hi Brent,
The version of gemini that I am using is 0.20.1.
Thanks,
Moiz

this should be fixed in master, could you give it a try?

Hi Brent,
I upgraded to the latest devel version of gemini 0.20.2-dev (upgraded both gemini and associated data) but I still get the same error as above and at the same variant as above. Additionally I see the following warning pop up multiple times for the same set of consequences:
WARNING: unknown severity for 'frameshift_variant&start_lost&start_retained_variant|Atg/tg|M/X|388697|HRNR|NM_001009931.2|2/3|||1/2850|prot ein_coding|YES|'. using LOW for [u'frameshift_variant', u'start_lost', u'start_retained_variant']
Let me know if you need any further information to help debug this.
Thanks,
Moiz

Hi @brentp. Any updates regarding the above issue?


Why is is_training set Ture in test.py

Hi Kwotsin, thanks a lot for your work.
But why is is_training set Ture in test.py?

This was made as the model performed better when this setting was used, maintaining the train-test split. This issue was referenced quite a few times in the TF repo here https://github.com/tensorflow/models/issues/391, where you can refer to for more informatino.


How to set the application version of the app

Maybe include that information under config.version

Hi @vitorcremonez ,
For now the application version is automatically set to be the version of your app, specified in:

versionName in build.gradle for Android
"Version" field in Xcode for iOS

To help us improve the SDK, could you share what your use case is?

Hi @vitorcremonez
You can now specify a version in the configuration:
By default, the SDK will report the version as the commercial version of your app (for example, "1.2.44").
If you use an Over The Air (OTA) updates provider like Microsoft's Codepush, you can override this version to indicate which version of your JavaScript code is running.
The recommended way is to do so by specifying a versionSuffix to the DdSdkReactNativeConfiguration object:
const config = new DdSdkReactNativeConfiguration(
    '<CLIENT_TOKEN>',
    '<ENVIRONMENT_NAME>',
    '<RUM_APPLICATION_ID>',
    true,
    true,
    true
);

config.versionSuffix = 'codepush.3';

If the commercial version of your app is "1.2.44", it will then be reported as "1.2.44-codepush.3" in Datadog - a dash (-) is automatically added between the version and the suffix.
You can also completely override the version by specifying the version field. However, make sure you set it correctly, as it will have to match the one specified during the upload of your source maps and other mapping files.
For more information about limitations on the version field, see the Tags documentation.
I am closing this issue, feel free to reopen it for further questions.


Automated Accessibility Checking

From the epic (#1580):

If feasible, the first step in this process would be an automated check of each document that is uploaded to ScholarSphere during the workflow for depositing a work. This check would use a third-party tool to analyze and evaluate each document in terms of accepted accessibility standards. We've begun to describe this step in https://github.com/psu-libraries/scholarsphere/issues/1580. We would want this automated check to be triggered by each document upload and to run asynchronously in the background. The result of the check should be a pass/fail evaluation of each document along with a list of any detected accessibility issues (and suggested remediations) for each document.

We have decided to use Adobe's PDF Services API to do our accessibility checking.  Refer to https://github.com/psu-libraries/scholarsphere/issues/1580#issuecomment-2359209601 for some links to documentation.  We will need to build our own wrapper that returns a pass/fail analysis and parses out any issues and remediations given to us by the API.  Accessibility checking should kick off in an async Sidekiq job for each uploaded file after the file upload step in the submission workflow.
There may be a way to pass signed URLs from ScholarSphere's AWS S3 bucket to Adobe for checking, so let's investigate that before considering other options.  Here's the documentation for passing signed URLs: https://developer.adobe.com/document-services/docs/overview/pdf-services-api/howtos/pdf-external-storage-sol/ .

Part of #1580

Look into how Adobe handles our PDFs when we send them.  For security/privacy concerns, we may need to mention to users that an external entity will have temporary access to their work.
We could hold off on accessibility checking for embargoed works.


[React native webView bridge] -

I am using this plugin to connect webView with my React Native code. I can send multiple messages from React Native to webView. But when I try to send message from webView to React native then I can send this only once. When I tried to send message again then it is showing error message. I tried hard to fix this but unable to fix. I am using same example as defined - I just added one button into HTML page to send multiple messages to React Native.
Please see attach screen shot.

Thanks for using my plugin,
One thing you should do is every time your onMessage callback called, you have to register your callback again.
so here's what I have in one of my project:
  registerCallback() {
    var webViewBridge = this.refs[WEBVIEW_REF];
    webViewBridge.onMessage(this.onBridgeMessage.bind(this));
  }

  onBridgeMessage(message) {
    var type = message.type;
    switch(type) {
      case 'toggle':
        //do something
        break;

      case 'ready':
        //it is ready
        break;

      case 'open-link':
        //do something here
        break

      default:
        console.log('got undefined logic for', message);
    }

    this.registerCallback();
  }

  componentDidMount() {
    this.registerCallback();
  }

  render() {
    var props = this.props;

    return (
      <WebViewBridge
        ref={WEBVIEW_REF}
        style={{ flex: 1 }}
        bounces={false}
        url={props.url}/>
    );
  }

So once the component mounted, I registered my callback and for every message that I receive I re-register the callback again.

Thanks for early reply.
Yes, I tried this and it worked.
:)

I have a patch that fixes this issue. I will update you once it's ready.

I have a patch that fixes this issue. I will update you once it's ready.

@alinz - Hey, just wondering if you had that patch handy?
I noticed that even if I register my callback immediately, I still miss messages. It's easy for me to reproduce by calling bridge.send twice. E.g.,
bridge.send(message1);
bridge.send(message2);

Sorry about that,
one thing you can do is wrap send with higher order function and call it with setTimeout.
For example:
function asyncCall(method) {
    return (value) => {
        setTimeout(() => { method(value); }, 0);
    };
}

bridge.send = asyncCall(bridge.send);

so now your bridge.send becomes async which might solve this problem.
p.s. For some reason higher order function becomes the next big thing :P


shutter recognized as dimmer

Dear all,
i connected the homeassistant to zwave-js-ui.
made working with mqtt discovery because of issues that the shutter is recognized as dimmier
once i made the choice i can see home assistant option on the device.
but the device reporting also as dimmer:
{
"type": "light",
"object_id": "dimmer_9",
"discovery_payload": {
"command_topic": "zwave/lab/gp9/switch_multilevel/endpoint_9/targetValue/set",
"state_topic": "zwave/lab/gp9/switch_multilevel/endpoint_9/currentValue",
"state_value_template": "{{ "OFF" if value_json.value == 0 else "ON" }}",
"brightness_command_topic": "zwave/lab/gp9/switch_multilevel/endpoint_9/targetValue/set",
"brightness_scale": 99,
"brightness_state_topic": "zwave/lab/gp9/switch_multilevel/endpoint_9/currentValue",
"brightness_value_template": "{{ value_json.value }}",
"on_command_type": "brightness",
"availability": [
{
"payload_available": "true",
"payload_not_available": "false",
"topic": "zwave/lab/gp9/status",
"value_template": "{{'true' if value_json.value else 'false'}}"
},
{
"topic": "zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status",
"value_template": "{{'online' if value_json.value else 'offline'}}"
},
{
"payload_available": "true",
"payload_not_available": "false",
"topic": "zwave/driver/status"
}
],
"availability_mode": "all",
"device": {
"identifiers": [
"zwavejs2mqtt_0xf2e08abf_node48"
],
"manufacturer": "TouchWand Co., Ltd.",
"model": "Glass 9 v2.03 (Glass9)",
"name": "lab-gp9",
"sw_version": "4.13.8"
},
"name": "lab-gp9_dimmer_9",
"unique_id": "zwavejs2mqtt_0xf2e08abf_48-38-9-currentValue"
},
"discoveryTopic": "light/lab-gp9/dimmer_9/config",
"values": [
"38-9-currentValue",
"38-9-targetValue"
],
"persistent": false,
"ignoreDiscovery": false,
"id": "light_dimmer_9"
}
is there anything i can do to make it work as shutter?
are there any automation for making all dimmer recognized as shutter?
zeev

Hi @zeev-mindali , the code that defines if discovering a cover or a light dimmer is here: https://github.com/zwave-js/zwave-js-ui/blob/cfcde4a61113139ac2436e3d8338e9d0a6299397/api/lib/Gateway.ts#L1254
I may have to add a case to handle your device as a cover, could you do a node export from the ui so I can check the node.deviceClass.generic and node.deviceClass.specific

Dear robert,
i attaching two files:
node46_ui node46_driver.
in node46_driver i see that node 8,9,10, identify as Motor class C, i think this is the start point of the bug.
node46_ui.json
node46_driver.json
zeev

Oh ok I may have understand what's the issue here, seems I only get the device class of root endpoint instead of getting it for each one, this requires a fix on my side

hi @robertsLando
i didn't see any change on my side regrading that issue,
it's still shows dimmer,
i check the linked pull, but it's not working for now.

@zeev-mindali The PR is not merged yet, how did you test it?

I have created 9.18.1 relese, give it a try

great, i will check it today, tnx a lot

dear @robertsLando,
i made the update, and i using the zwave-js-ui as my main zwave in home assistant,
i can see in the home assistant tab, that it's recognized as cover, but home assistant still show me as light,
is it something on zwave-js-ui or on home assistant?

I think that's something related to HA but I'm not an HA expert, try to ask to them and let me know :)

@robertsLando
the problem is deffentily HA fault.
i used the mqtt in HA , and i got cover, but the zwave-js of HA is still shown as light.
closing the issue

here the files:
zwavejs_current.log
z-ui_current.log

From discovery prospecctive seems good:
2024-09-16 16:53:38.703 DEBUG GATEWAY: Publishing discovery: {
  type: 'cover',
  object_id: 'position_8',
  discovery_payload: {
    command_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_8/targetValue/set',
    position_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_8/currentValue',
    set_position_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_8/targetValue/set',
    position_template: '{{ value_json.value | round(0) }}',
    position_open: 99,
    position_closed: 0,
    payload_open: 99,
    payload_close: 0,
    availability: [
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/lab/gp9/status',
        value_template: "{{'true' if value_json.value else 'false'}}"
      },
      {
        topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status',
        value_template: "{{'online' if value_json.value else 'offline'}}"
      },
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/driver/status'
      },
      [length]: 3
    ],
    availability_mode: 'all',
    device: {
      identifiers: [ 'zwavejs2mqtt_0xe98f251e_node24', [length]: 1 ],
      manufacturer: 'TouchWand Co., Ltd.',
      model: 'Glass 9 (Glass9)',
      name: 'lab-gp9',
      sw_version: '2.10.3'
    },
    name: 'lab-gp9_position_8',
    unique_id: 'zwavejs2mqtt_0xe98f251e_24-38-8-currentValue'
  },
  discoveryTopic: 'cover/lab-gp9/position_8/config',
  values: [ '38-8-currentValue', '38-8-targetValue', [length]: 2 ],
  persistent: false,
  ignoreDiscovery: false
}
2024-09-16 16:53:39.190 DEBUG GATEWAY: Publishing discovery: {
  type: 'cover',
  object_id: 'position_9',
  discovery_payload: {
    command_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_9/targetValue/set',
    position_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_9/currentValue',
    set_position_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_9/targetValue/set',
    position_template: '{{ value_json.value | round(0) }}',
    position_open: 99,
    position_closed: 0,
    payload_open: 99,
    payload_close: 0,
    availability: [
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/lab/gp9/status',
        value_template: "{{'true' if value_json.value else 'false'}}"
      },
      {
        topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status',
        value_template: "{{'online' if value_json.value else 'offline'}}"
      },
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/driver/status'
      },
      [length]: 3
    ],
    availability_mode: 'all',
    device: {
      identifiers: [ 'zwavejs2mqtt_0xe98f251e_node24', [length]: 1 ],
      manufacturer: 'TouchWand Co., Ltd.',
      model: 'Glass 9 (Glass9)',
      name: 'lab-gp9',
      sw_version: '2.10.3'
    },
    name: 'lab-gp9_position_9',
    unique_id: 'zwavejs2mqtt_0xe98f251e_24-38-9-currentValue'
  },
  discoveryTopic: 'cover/lab-gp9/position_9/config',
  values: [ '38-9-currentValue', '38-9-targetValue', [length]: 2 ],
  persistent: false,
  ignoreDiscovery: false
}
2024-09-16 16:53:39.676 DEBUG GATEWAY: Publishing discovery: {
  type: 'cover',
  object_id: 'position_10',
  discovery_payload: {
    command_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_10/targetValue/set',
    position_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_10/currentValue',
    set_position_topic: 'zwave/lab/gp9/switch_multilevel/endpoint_10/targetValue/set',
    position_template: '{{ value_json.value | round(0) }}',
    position_open: 99,
    position_closed: 0,
    payload_open: 99,
    payload_close: 0,
    availability: [
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/lab/gp9/status',
        value_template: "{{'true' if value_json.value else 'false'}}"
      },
      {
        topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status',
        value_template: "{{'online' if value_json.value else 'offline'}}"
      },
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/driver/status'
      },
      [length]: 3
    ],
    availability_mode: 'all',
    device: {
      identifiers: [ 'zwavejs2mqtt_0xe98f251e_node24', [length]: 1 ],
      manufacturer: 'TouchWand Co., Ltd.',
      model: 'Glass 9 (Glass9)',
      name: 'lab-gp9',
      sw_version: '2.10.3'
    },
    name: 'lab-gp9_position_10',
    unique_id: 'zwavejs2mqtt_0xe98f251e_24-38-10-currentValue'
  },
  discoveryTopic: 'cover/lab-gp9/position_10/config',
  values: [ '38-10-currentValue', '38-10-targetValue', [length]: 2 ],
  persistent: false,
  ignoreDiscovery: false
}

Then light dimmers:
2024-09-16 16:52:46.192 DEBUG GATEWAY: Publishing discovery: {
  type: 'light',
  object_id: 'dimmer_1',
  discovery_payload: {
    command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_1/targetValue/set',
    state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_1/currentValue',
    state_value_template: '{{ "OFF" if value_json.value == 0 else "ON" }}',
    brightness_command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_1/targetValue/set',
    brightness_scale: 99,
    brightness_state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_1/currentValue',
    brightness_value_template: '{{ value_json.value }}',
    on_command_type: 'brightness',
    availability: [
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/lab/wallwand/status',
        value_template: "{{'true' if value_json.value else 'false'}}"
      },
      {
        topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status',
        value_template: "{{'online' if value_json.value else 'offline'}}"
      },
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/driver/status'
      },
      [length]: 3
    ],
    availability_mode: 'all',
    device: {
      identifiers: [ 'zwavejs2mqtt_0xe98f251e_node25', [length]: 1 ],
      manufacturer: 'TouchWand Co., Ltd.',
      model: 'WallWand touch panel (WallWand)',
      name: 'lab-wallwand',
      sw_version: '1.48'
    },
    name: 'lab-wallwand_dimmer_1',
    unique_id: 'zwavejs2mqtt_0xe98f251e_25-38-1-currentValue'
  },
  discoveryTopic: 'light/lab-wallwand/dimmer_1/config',
  values: [ '38-1-currentValue', '38-1-targetValue', [length]: 2 ],
  persistent: false,
  ignoreDiscovery: false
}
2024-09-16 16:52:46.349 DEBUG GATEWAY: Publishing discovery: {
  type: 'light',
  object_id: 'dimmer_2',
  discovery_payload: {
    command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_2/targetValue/set',
    state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_2/currentValue',
    state_value_template: '{{ "OFF" if value_json.value == 0 else "ON" }}',
    brightness_command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_2/targetValue/set',
    brightness_scale: 99,
    brightness_state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_2/currentValue',
    brightness_value_template: '{{ value_json.value }}',
    on_command_type: 'brightness',
    availability: [
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/lab/wallwand/status',
        value_template: "{{'true' if value_json.value else 'false'}}"
      },
      {
        topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status',
        value_template: "{{'online' if value_json.value else 'offline'}}"
      },
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/driver/status'
      },
      [length]: 3
    ],
    availability_mode: 'all',
    device: {
      identifiers: [ 'zwavejs2mqtt_0xe98f251e_node25', [length]: 1 ],
      manufacturer: 'TouchWand Co., Ltd.',
      model: 'WallWand touch panel (WallWand)',
      name: 'lab-wallwand',
      sw_version: '1.48'
    },
    name: 'lab-wallwand_dimmer_2',
    unique_id: 'zwavejs2mqtt_0xe98f251e_25-38-2-currentValue'
  },
  discoveryTopic: 'light/lab-wallwand/dimmer_2/config',
  values: [ '38-2-currentValue', '38-2-targetValue', [length]: 2 ],
  persistent: false,
  ignoreDiscovery: false
}
2024-09-16 16:52:46.654 DEBUG GATEWAY: Publishing discovery: {
  type: 'light',
  object_id: 'dimmer_5',
  discovery_payload: {
    command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_5/targetValue/set',
    state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_5/currentValue',
    state_value_template: '{{ "OFF" if value_json.value == 0 else "ON" }}',
    brightness_command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_5/targetValue/set',
    brightness_scale: 99,
    brightness_state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_5/currentValue',
    brightness_value_template: '{{ value_json.value }}',
    on_command_type: 'brightness',
    availability: [
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/lab/wallwand/status',
        value_template: "{{'true' if value_json.value else 'false'}}"
      },
      {
        topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status',
        value_template: "{{'online' if value_json.value else 'offline'}}"
      },
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/driver/status'
      },
      [length]: 3
    ],
    availability_mode: 'all',
    device: {
      identifiers: [ 'zwavejs2mqtt_0xe98f251e_node25', [length]: 1 ],
      manufacturer: 'TouchWand Co., Ltd.',
      model: 'WallWand touch panel (WallWand)',
      name: 'lab-wallwand',
      sw_version: '1.48'
    },
    name: 'lab-wallwand_dimmer_5',
    unique_id: 'zwavejs2mqtt_0xe98f251e_25-38-5-currentValue'
  },
  discoveryTopic: 'light/lab-wallwand/dimmer_5/config',
  values: [ '38-5-currentValue', '38-5-targetValue', [length]: 2 ],
  persistent: false,
  ignoreDiscovery: false
}
2024-09-16 16:52:47.137 DEBUG GATEWAY: Publishing discovery: {
  type: 'light',
  object_id: 'dimmer_6',
  discovery_payload: {
    command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_6/targetValue/set',
    state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_6/currentValue',
    state_value_template: '{{ "OFF" if value_json.value == 0 else "ON" }}',
    brightness_command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_6/targetValue/set',
    brightness_scale: 99,
    brightness_state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_6/currentValue',
    brightness_value_template: '{{ value_json.value }}',
    on_command_type: 'brightness',
    availability: [
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/lab/wallwand/status',
        value_template: "{{'true' if value_json.value else 'false'}}"
      },
      {
        topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status',
        value_template: "{{'online' if value_json.value else 'offline'}}"
      },
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/driver/status'
      },
      [length]: 3
    ],
    availability_mode: 'all',
    device: {
      identifiers: [ 'zwavejs2mqtt_0xe98f251e_node25', [length]: 1 ],
      manufacturer: 'TouchWand Co., Ltd.',
      model: 'WallWand touch panel (WallWand)',
      name: 'lab-wallwand',
      sw_version: '1.48'
    },
    name: 'lab-wallwand_dimmer_6',
    unique_id: 'zwavejs2mqtt_0xe98f251e_25-38-6-currentValue'
  },
  discoveryTopic: 'light/lab-wallwand/dimmer_6/config',
  values: [ '38-6-currentValue', '38-6-targetValue', [length]: 2 ],
  persistent: false,
  ignoreDiscovery: false
}
2024-09-16 16:52:47.334 DEBUG GATEWAY: Publishing discovery: {
  type: 'light',
  object_id: 'dimmer_7',
  discovery_payload: {
    command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_7/targetValue/set',
    state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_7/currentValue',
    state_value_template: '{{ "OFF" if value_json.value == 0 else "ON" }}',
    brightness_command_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_7/targetValue/set',
    brightness_scale: 99,
    brightness_state_topic: 'zwave/lab/wallwand/switch_multilevel/endpoint_7/currentValue',
    brightness_value_template: '{{ value_json.value }}',
    on_command_type: 'brightness',
    availability: [
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/lab/wallwand/status',
        value_template: "{{'true' if value_json.value else 'false'}}"
      },
      {
        topic: 'zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status',
        value_template: "{{'online' if value_json.value else 'offline'}}"
      },
      {
        payload_available: 'true',
        payload_not_available: 'false',
        topic: 'zwave/driver/status'
      },
      [length]: 3
    ],
    availability_mode: 'all',
    device: {
      identifiers: [ 'zwavejs2mqtt_0xe98f251e_node25', [length]: 1 ],
      manufacturer: 'TouchWand Co., Ltd.',
      model: 'WallWand touch panel (WallWand)',
      name: 'lab-wallwand',
      sw_version: '1.48'
    },
    name: 'lab-wallwand_dimmer_7',
    unique_id: 'zwavejs2mqtt_0xe98f251e_25-38-7-currentValue'
  },
  discoveryTopic: 'light/lab-wallwand/dimmer_7/config',
  values: [ '38-7-currentValue', '38-7-targetValue', [length]: 2 ],
  persistent: false,
  ignoreDiscovery: false
}

this is my problem, the wallwand is not a dimmer, it's a cover :(

@zeev-mindali those are the logs, I need an export of the node like you did hre: https://github.com/zwave-js/zwave-js-ui/issues/3862#issuecomment-2323158518

node_3.json
node_3_dump.json

@zeev-mindali are ALL dimmers above covers? Because some are reporting specific_type_basic_wall_controller and others specific_type_motor_multiposition. While the second is self explanatory the fist I'm not sure if should be alwats considered a cover

the controller have two multi level switch:

multiposition motor.
long/short switch , which is virtual switch which long press (3 seconds) makes it's true, for not make action accedently.

@zeev-mindali wait for 9.19.1, will release it the end of the week

Dear @robertsLando ,
any news on the release?

Coming in one hour :)

Dear @robertsLando ,
first of all it's recognize the cover :)
but there is a strange problem with the stop command.
while the percentage and therefor the up/down is made in mqtt :
zwave/bedrom/ww_left/switch_multilevel/endpoint_1/targetValue/set
0
for stoping the device the mqtt path is diffrent:
zwave/bedrom/ww_left/switch_multilevel/endpoint_1/Down/set
false
this happing on the two multilevel switch , the GlassPanel 9 by MCO home and WallWand by touchwand.
i sent the mqtt command and paths, and it's working when i sent to Up or Down the false as value.

@AlCalzone does all covers have up and down commands?

@AlCalzone all covers have up and down command for glass9 and wallwand

Bit of confusion here.
First off, all Multilevel Switches support being opened/closed/dimmed up/dimmed down using Start/StopLevelChange.
They can also be set to a specific value/position using target value.
The two MQTT topics @zeev-mindali mentions are a mix of both.

.../switch_multilevel/endpoint_1/targetValue/set <value> means go to position <value>
.../switch_multilevel/endpoint_1/Down/set false means stop moving

That is fine, but this would be more consistent:

.../switch_multilevel/endpoint_1/Up/set true to start opening
.../switch_multilevel/endpoint_1/Down/set true to start closing
.../switch_multilevel/endpoint_1/Up/set false or .../switch_multilevel/endpoint_1/Down/set false to stop moving

@AlCalzone
you are correct :)
the up/down is for open close dim up dim down and stop (but in dimming is little problematic with the timing to stop, prefer dali for dimming)
the targetValue is for position setup

@zeev-mindali could you share the discovery payload?

for getting up or position:
Topic: zwave/mbr/gp9/switch_multilevel/endpoint_10/targetValue
{"time":1727239904945,"value":99}
for getting down or position:
Topic: zwave/mbr/gp9/switch_multilevel/endpoint_10/targetValue
{"time":1727239904945,"value":0}
the problem is in:
Topic: zwave/mbr/gp9/switch_multilevel/endpoint_10/targetValue
{"time":1727239904945,"value": stop}
it should be:
Topic: zwave/mbr/gp9/switch_multilevel/endpoint_10/Down
{"time":1727239904945,"value": false}
if you need any more data , don't hasitate to ask for

@zeev-mindali I need the discovery payload, the one you find by going to home assistant tab when you click on a node on control panel table, then select the cover in the list of discovery devices and you will see the discovery payload on the right that's the one sent to HA

for an endpoint 8
{
"type": "cover",
"object_id": "position_8",
"discovery_payload": {
"command_topic": "zwave/mbr/gp9/switch_multilevel/endpoint_8/targetValue/set",
"position_topic": "zwave/mbr/gp9/switch_multilevel/endpoint_8/currentValue",
"set_position_topic": "zwave/mbr/gp9/switch_multilevel/endpoint_8/targetValue/set",
"position_template": "{{ value_json.value | round(0) }}",
"position_open": 99,
"position_closed": 0,
"payload_open": 99,
"payload_close": 0,
"availability": [
{
"payload_available": "true",
"payload_not_available": "false",
"topic": "zwave/mbr/gp9/status",
"value_template": "{{'true' if value_json.value else 'false'}}"
},
{
"topic": "zwave/_CLIENTS/ZWAVE_GATEWAY-zwave/status",
"value_template": "{{'online' if value_json.value else 'offline'}}"
},
{
"payload_available": "true",
"payload_not_available": "false",
"topic": "zwave/driver/status"
}
],
"availability_mode": "all",
"device": {
"identifiers": [
"zwavejs2mqtt_0xeeea28a4_node8"
],
"manufacturer": "TouchWand Co., Ltd.",
"model": "Glass 9 (Glass9)",
"name": "mbr-gp9",
"sw_version": "4.13.8"
},
"name": "mbr-gp9_position_8",
"unique_id": "zwavejs2mqtt_0xeeea28a4_8-38-8-currentValue"
},
"discoveryTopic": "cover/mbr-gp9/position_8/config",
"values": [
"38-8-currentValue",
"38-8-targetValue"
],
"persistent": false,
"ignoreDiscovery": false,
"id": "cover_position_8"
}

Based on docs the command_topic is the one where we should send the open/close commands but we actually have two topics to send the open/close ( Down and Up), so what?
cc @ccutrer as I know he have a good understanding on auto discovery topic

@robertsLando
i have for endpoint 8 two entity
one is cover, as i posted above
the second is switch:
{
"type": "switch",
"object_id": "switch_8",
"discovery_payload": {
"payload_off": false,
"payload_on": true,
"value_template": "{{ value_json.value }}",
"command_topic": "zwave/mbr/gp9/switch_binary/endpoint_8/targetValue/set",
"state_topic": "zwave/mbr/gp9/switch_binary/endpoint_8/currentValue",
"availability": [
{
"payload_available": "true",
"payload_not_available": "false",
"topic": "zwave/mbr/gp9/status",
"value_template": "{{'true' if value_json.value else 'false'}}"
},
{
"topic": "zwave/_CLIENTS/ZWAVE_GATEWAY-zwave/status",
"value_template": "{{'online' if value_json.value else 'offline'}}"
},
{
"payload_available": "true",
"payload_not_available": "false",
"topic": "zwave/driver/status"
}
],
"availability_mode": "all",
"device": {
"identifiers": [
"zwavejs2mqtt_0xeeea28a4_node8"
],
"manufacturer": "TouchWand Co., Ltd.",
"model": "Glass 9 (Glass9)",
"name": "mbr-gp9",
"sw_version": "4.13.8"
},
"name": "mbr-gp9_switch_8",
"unique_id": "zwavejs2mqtt_0xeeea28a4_8-37-8-currentValue"
},
"discoveryTopic": "switch/mbr-gp9/switch_8/config",
"values": [
"37-8-currentValue",
"37-8-targetValue"
],
"persistent": false,
"ignoreDiscovery": false,
"id": "switch_switch_8"
}
maybe the solution will be from this side.

maybe the solution will be from this side.

What does the switch do?

nope, you correct

@robertsLando
the more i digging into it, the command topic is the one we need, you totally correct.
but for stoping we can use the Up or Down as if i understand correctly.

@robertsLando
i made a change to mqtt command in home assistant:
#cover test with mqtt mqtt:   cover:     - unique_id: cover-test       name: "Cover Test"       state_topic: "zwave/mbr/gp9/switch_multilevel/endpoint_10/currentValue"       command_topic: "zwave/mbr/gp9/switch_multilevel/endpoint_10/targetValue/set"       position_topic: "zwave/mbr/gp9/switch_multilevel/endpoint_10/currentValue"       set_position_topic: "zwave/mbr/gp9/switch_multilevel/endpoint_10/targetValue/set"       position_template: "{{ value_json.value | round(0) }}"       position_open: 99       position_closed: 0       payload_open: 99       payload_close: 0       payload_stop: false # <=== for stoping the covert       qos: 1       retain: false
i just add payload_stop: false, and the stop start to work :)
is it posibble to add the line to the cover payload?

@zeev-mindali yeah but this is the problem here, Up and Down are two different topics, I cannot map them dinamically on the discovery payload command, I don't have many alternatives here

@robertsLando
i agree with you, i played with the mqtt configuration in the home assistant.
found there is another topic, called payload_stop
but in glass9 by mco home, i needed to check if the cover is opening or closing for sending true or false for stop.
in wallwand by touchwand, it's has no effect.
in both cases the only solution is Up/Down set to false, but after the expriance from the glass9 i not sure if needed only up or down, or both for using that.
still playing with it

@zeev-mindali let me know if there is something I can do on my side

@robertsLando
i very confused , i have a simple shutter also from mco home, which works great.
so why the other one is not :( it's seems it's not related to mqtt, but more to the zwave commands.
if i able to make mqtt commands to make it work, maybe the problem on the driver side?
is the entity of the cover is treated like a single end point cover device?
it's payload:
{
"type": "cover",
"object_id": "position",
"discovery_payload": {
"command_topic": "zwave/mbr/shutter/switch_multilevel/endpoint_0/targetValue/set",
"position_topic": "zwave/mbr/shutter/switch_multilevel/endpoint_0/currentValue",
"set_position_topic": "zwave/mbr/shutter/switch_multilevel/endpoint_0/targetValue/set",
"position_template": "{{ value_json.value | round(0) }}",
"position_open": 99,
"position_closed": 0,
"payload_open": 99,
"payload_close": 0,
"availability": [
{
"payload_available": "true",
"payload_not_available": "false",
"topic": "zwave/mbr/shutter/status",
"value_template": "{{'true' if value_json.value else 'false'}}"
},
{
"topic": "zwave/_CLIENTS/ZWAVE_GATEWAY-zwave/status",
"value_template": "{{'online' if value_json.value else 'offline'}}"
},
{
"payload_available": "true",
"payload_not_available": "false",
"topic": "zwave/driver/status"
}
],
"availability_mode": "all",
"device": {
"identifiers": [
"zwavejs2mqtt_0xeeea28a4_node11"
],
"manufacturer": "Mco Home Co., Ltd.",
"model": "Shutter Panel (MH-C621)",
"name": "mbr-shutter",
"sw_version": "4.14"
},
"name": "mbr-shutter_position",
"unique_id": "zwavejs2mqtt_0xeeea28a4_11-38-0-currentValue"
},
"discoveryTopic": "cover/mbr-shutter/position/config",
"values": [
"38-0-currentValue",
"38-0-targetValue"
],
"persistent": false,
"ignoreDiscovery": false,
"id": "cover_position"
}

@zeev-mindali Sincerly I have no clue, I'm sorry :(

@robertsLando
found the problem, finally
when i use the payload_stop or any other
the zwave get:
command class : 0x26 - COMMAND_CLASS_SWITCH_MULTILEVEL
command : 0x01 - SWITCH_MULTILEVEL_SET
this is not correct
it should be:
command class : 0x26 - COMMAND_CLASS_SWITCH_MULTILEVEL
command : 0x05 - SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE
i tested the zwave js ui, and it's working and sending the correct command, the issue is with mqtt or HA which not using the correct methods.
if it's help, i can send you a zniffer log, for not working and working

Can this be a fix? https://github.com/zwave-js/zwave-js-ui/pull/3916
BTW I'm not sure if that could create some issue

i saw in the gateway file, referance for open and close, didn't see a zwave command for stop, or i missed that?

Can this be a fix? #3916
BTW I'm not sure if that could create some issue

does the fix is in the new release?

@robertsLando
mange to fix the code :)
gateway file
in function  - > parsePayload(payload: any, valueId: ZUIValueId, valueConf: GatewayValue)
in the begining of the function
i checked if payload is STOP, which reflects the stop from HA.
if the payload is top, i move the up (not matter if it's up or down) to false.
if (payload === 'STOP') {
this._zwave
.writeValue({...valueId,property: 'Up',},false,)
.catch(() => {})
return null
}
and the stop from ha is now working :)
i checking now with the wallwand (needs to works also) and a single shutter MCO Home C621.
if it will working without a problem, i will notify you :)

@robertsLando
tested with 3 diffrent devices, two has multi endpoint and one is shutter.
first of all you need to take out the change that you made with the open close, which represent up/down
where you wrote : // ref issue https://github.com/zwave-js/zwave-js-ui/issues/3862
and add to the begining of the function the code:
if (payload === 'STOP') {
this._zwave
.writeValue({...valueId,property: 'Up',},false,)
.catch(() => {})
return null
}
this will fix the issues with the stop
now it's all working.
i tried to compile to arm v7 , but it's says the package will work only on macos :(
so if you can also help with that also, i can check with the package

sent you the suggested change

Just submitted a change to #3916, could you check it? Only stop should be handled so?

@robertsLando
only stop should be handled, but if it's found in payload STOP then it should be false and not true
this._zwave
.writeValue(
{
...valueId,
property: 'Up',
},
false,   <== this will stop him
)

@zeev-mindali Ok will change the payload to be false instead. Wondering if I should also handel the down command someway and write false there too in case it's going down? Dunno how it works sincerly as I never used a z-wave cover

@robertsLando
it doesn't matter if it's up->false or down->false, on both cases it will stop the cover.
i running checks on my side, to check the code.

Ok perfect thanks for the feedback, merging now, patch release will come in next days

@robertsLando
down is working, with stop, up is not working
the else if is killed the solution.
when i put the stop handle in the begining of the function, it worked

@robertsLando
in line 435:
hassDevice.type === 'cover' && valueId.property === 'targetValue'
i don't think the valueId.property is targetValue, therefor , the block command will not work.

@zeev-mindali You will find it on workflow assets once this ends: https://github.com/zwave-js/zwave-js-ui/actions/runs/11108825157

@zeev-mindali 9.21.1 is out
https://github.com/zwave-js/zwave-js-ui/releases/tag/v9.21.1

the 9.21.1 fixed the problem with start stop issue :)
you can close it


Add support for Python 3.7.16, 3.8.16, 3.9.16, 3.10.9 and 3.11.1

https://blog.python.org/2022/12/python-3111-3109-3916-3816-3716-and.html
https://www.python.org/downloads/release/python-3716/
https://www.python.org/downloads/release/python-3816/
https://www.python.org/downloads/release/python-3916/
https://www.python.org/downloads/release/python-3109/
https://www.python.org/downloads/release/python-3111/
GUS-W-10333182.
GUS-W-12177582.
GUS-W-12177588.

$ make publish
Deploy as version: v224 [y/n]? y

Tagging commit 06c79dbc943277c16713f092b6f4e683cae9098c with v224...
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/heroku/heroku-buildpack-python
 * [new tag]           v224 -> v224

Publishing to the buildpack registry...
Two-factor code: ********************************************
Publishing buildpack heroku/python... done
Publishing buildpack was successful

Version  Released At               Status
───────  ────────────────────────  ─────────
224      2022-12-07T00:44:00.969Z  published

https://devcenter.heroku.com/articles/python-support#specifying-a-python-version
https://devcenter.heroku.com/articles/python-runtimes#selecting-a-runtime
https://devcenter.heroku.com/changelog-items/2510


fix(strm-2223): set default policy retention to 0, the proto default value

This makes sure that the retention doesn't get overwritten when not provided by the user during an update command.

i'm fine with it.

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


Add option to skip cache version in links

The motivation of this PR is to explore a way to fix #7.
Upgrading an application to use this new version of Turbolinks, we found a few situations where loading the cached version when visiting a new page is not working fine. In our case, we would like to skip loading the cached version in two cases:

We don't want to show data entered by users when visiting again a page with a form
We also have permalinks to sections where a modal dialog is opened. The animation triggers twice in those cases.

I couldn't find in the API any way to deal with this cases. I'm aware that taking advantage of the turbolinks:before-cache event could be used to solve the form issue, e.g. clearing the form at this point. However, I didn't know how to fix the animation problem without adding this option.
Even for the form case, I feel like having a way to skip the cached version would be a much simpler solution.
In case of adding this option, the name of the data attribute can be further discussed.
What do you think about this addition?

Hi Jorge --
Thanks for taking the time to explore this. I agree that there should be some way to control page caching behavior. Before we discuss that, I wanted to address the two cases you mentioned, as I think you can solve them without needing explicit caching control.

We don't want to show data entered by users when visiting again a page with a form

As you've noted, the turbolinks:before-cache event is the appropriate time to reset forms and make any other preparations before the DOM is stored. You'll likely want to do this even with an option to disable previews, since the same cached snapshot will be shown on a restore when browsing by history.

We also have permalinks to sections where a modal dialog is opened. The animation triggers twice in those cases.

You should be able to wait for turbolinks:load before applying behavior. This is fired once after each visit, whether or not a preview was shown. If that's not possible (say, because you're using MutationObserver and are notified at each appearance of your element in the DOM), you can detect whether Turbolinks is displaying a preview by checking for the data-turbolinks-preview attribute on the <html> element. If you have behavior that you don't want applied to a preview, you can avoid installing it. (I wrote more about the preview DOM in the comments on Issue #7).
All that said, an option to control caching behavior would be a welcome addition – I know it's come up in our use at Basecamp. I'm not sure that a link annotation or an option to Turbolinks.visit() is the way to go, though. When would you want to disable the preview only sometimes for a location?
I think this option should live at the page level. In other words, pages should be able to declare their caching behavior. I think a <meta> element is appropriate for such a declaration.
Perhaps something like <meta name="turbolinks-show-cache" content="...">, where content can be one of never, only-restore, only-preview, or always. The implied default would be always.
To declare that a cached page should only be shown for a restore, but not for a preview (where its eventual replacement might cause a visual glitch), you'd do the following:
<head>
  <meta name="turbolinks-show-cache" content="only-restore">
</head>

I'm not sure about the names of everything, but that's the general idea. What do you think?

Hey @packagethief, thanks for the feedback!
I agree that most of the issues mentioned in this thread and #7 can be solved by using turbolinks:before-cache and turbolinks:load events, or checking the presence of data-turbolinks-preview.
I only have one case that I can not solve with these options: the issue that I mentioned in #7 about the sidebar values that sometimes shows an inaccurate value navigating to a different section, ending up in a visual glitch. Since data-turbolinks-permanent is not an option in our specific situation, probably the best way to fix the problem with the current API is clearing the cache Turbolinks.clearCache() as you suggested (with the associated cost of losing the cache when navigating back).
Although these solutions are feasible, I happy to hear that you find valuable the possibility of opt out the preview cache. I see this addition as a huge simplification, at least in our specific app (I hope it would be the same for many apps!).

All that said, an option to control caching behavior would be a welcome addition – I know it's come up in our use at Basecamp. I'm not sure that a link annotation or an option to Turbolinks.visit() is the way to go, though. When would you want to disable the preview only sometimes for a location?
I think this option should live at the page level. In other words, pages should be able to declare their caching behavior. I think a  element is appropriate for such a declaration.

I don't have a strong opinion here. In fact, having the option in the link as I implemented in this PR is not the perfect fit for our app either. That's because I ended up adding the data-turbolinks-skip-preview to almost every link :tired_face:.
When I realized about this issue (after opening this PR), I wished to have a global setting, e.g. Turbolinks.turbolinksCacheMode = ... instead of marking individual links.

Perhaps something like , where content can be one of never, only-restore, only-preview, or always. The implied default would be always.

I like this idea! It's similar to defining it as a global setting but scoped to pages.
I'm not sure if there is any real use case where you want to use the cache "only for preview", but I'm OK with the overall idea :+1:
Let me rework this PR using the meta attribute and test against our app. I will share the results.

Hi @packagethief, please take a look now. I've tested this new implementation relying on a meta attribute as we discussed last week.
This solution solves the issues that we have in our application without adding extra complexity or hacks.
Regarding the implementation, I'm not sure if we should add tests for this changes. I noticed there are some tests but I didn't find a easy way to add tests for this addition. What would you do in this case? Any recommendation?
Thanks

Hey @jmbejar, thanks a lot for working on this.
During a visit, I think we should ask the cached page whether it allows itself to be shown for the requested action–not the current page. That way, pages are responsible for declaring their own caching behavior.
To do this we'll need to load the snapshot from cache and query its <head> for the setting.
Perhaps Visit can perform this check as part of getCachedSnapshot(). It already checks whether the snapshot should be used for anchored locations. That could be extracted, along with a check for the cache setting, to something like shouldUseCachedSnapshot(snapshot).
Then hasCachedSnapshot will be accurate, and getCachedSnapshot can be reduced to:
getCachedSnapshot: ->
  snapshot = @controller.getCachedSnapshotForLocation(@location)
  snapshot if snapshot and @shouldUseCachedSnapshot(snapshot)

I also think we should include support for a "never" option. If you have a page that isn't well-suited to being cached, you won't want it shown for previews or restores. In that case it would probably be simplest  to avoid caching the page altogether.
What do you think?

During a visit, I think we should ask the cached page whether it allows itself to be shown for the requested action–not the current page. That way, pages are responsible for declaring their own caching behavior.

Yeah, that's a valid point. In our specific app it doesn't make a big difference because we decided to mark all pages with only-restore for now, however I think you're totally right. I'll do the change.

I also think we should include support for a "never" option. If you have a page that isn't well-suited to being cached, you won't want it shown for previews or restores. In that case it would probably be simplest to avoid caching the page altogether.

Right, so all the possibilities are covered :+1:

Hey Jorge,
Before you try implementing this further, I was just discussing it with @sstephenson and we're thinking that the original suggestion of options like "only-preview" and "only-restore" isn't quite right. For one, I can't come up with a good reason why you'd want "only-preview".
It seems to me that most common cases are: 1) don't cache this page ever, and 2) don't use a cached copy of this page for a preview. These are the only two cases I think we ought to support.
I know I suggested it originally, but the name "turbolinks-show-cache" doesn't seem quite right either. It doesn't do a very good job of communicating that this is a per-page option for declaring caching directives.
To that end, here's a revised proposal:
I think it would be cute if we paid homage to the HTTP Cache-Control header (especially since it can also be specified in HTML with a <meta> tag). We'd name our tag "turbolinks-cache-control", and accept two directives: "no-cache" and "no-preview".
To prevent the page from ever being cached by Turbolinks:
<meta name="turbolinks-cache-control" content="no-cache">

Or, to prevent a cached copy of the page from being used for a preview during an application visit:
<meta name="turbolinks-cache-control" content="no-preview">

In addition to being clearer, I think this will simplify the implementation. Snapshots can be responsible for knowing whether they're cacheable (isCacheable) or previewable (isPreviewable). Then it's just a matter of asking a snapshot these questions before we use it. Pages declared "no-cache" wouldn't be saved to the cache at all.
What do you think?

@packagethief I can say that this new proposal will cover the essential cases. I agree that there should not be cases where the "only-preview" option would be useful.
I will follow this new ideas and get back to you if some doubt arises, however I think it should work fine :+1:

Here is a new implementation following yesterday's feedback.
We have now two commits, the first one (https://github.com/jmbejar/turbolinks/commit/f1f694ac4d59accdd053b2baebd60239094c002f) adds the ability to prevent previews.
You can see the isPreviewable function added to Snapshot as we planned.
In the second commit (https://github.com/jmbejar/turbolinks/commit/072ce15474e9c564e30bf7c4a78b7104edb2a53e), I had problems implementing the isCacheable within Snapshot, it seems to fit better in the controller. This is because we should check if the page is cacheable right before notifying the app (triggering "before-cache" event), however I need to trigger those events before generating the snapshot:
  cacheSnapshot: ->
    if @isCacheable()
      @notifyApplicationBeforeCachingSnapshot()
      snapshot = @view.getSnapshot()
      @cache.put(@lastRenderedLocation, snapshot)

Therefore, I should not wait for the snapshot generation to check the current page meta tag for "cache-control".
I think this implementation has the best of both worlds, with minimal code duplication (e.g. "cache-control" retrieval is implemented twice, in Snapshot and Controller)

@packagethief I've addressed all your feedback. Thanks again for all your help!

Excellent work, @jmbejar. Thanks for seeing this through.

@sstephenson @packagethief :+1:


New release?

In order to use the support for dask arrays added in #52, a new release would be needed. Are there plans for creating a new release?

@bouweandela Good to hear from you, as always!
We need to show some major love to python-stratify in order to breath some life back into the CI et al, which has all gone majorly stale.
@HGWright is now going to be spinning up on python-stratify to do this work, and we aim to do a release as soon as possible. It'll also a learning exercise for him to understand the new code base, but ultimately he will be the core developer of python-stratify... so an ideal point-of-contact for you (apart for myself :wink:)
We have a GH Project Board to cover the forthcoming work, which we're about to refine and prioritize. We'll aim to deliver a Minimum Viable Product to unblock the release of python-stratify 0.3.0, then re-spin to mop up other outstanding tasks.
How this is okay with you?

The project board looks nice but also a lot of work.  Maybe just reviving the test infrastructure and setting up automatic package upload to PyPI would be enough for a working release and the rest could go into a next release?

Great to hear that someone will be looking after this package! :partying_face:

@bouweandela You will be pleased to hear, we are not planning to do everything on the board before the next release. Only the things that we thing are necessary will be included (Marked with the :key: MVP tag on the board). We currently estimate that at the very least we will have the next release out by the end of April. This date is not set in stone and if we can get it out for you sooner then we will.
One of the things we are planning to do in this release is to review the supported versions of Python and we have discussed only supporting Python 3.8 onwards. Would this be a problem for you?

Would this be a problem for you?

Not a problem at all, we're only supporting 3.8 and later in ESMValTool/ESMValCore too.

@bouweandela Version 0.3.0 of Python-Stratify is now released and available on PYPI and Conda-Forge.  Please install, use and be sure to let us know if any issues come up.


Vim Newbie

I'm pretty new to Vim, installed Vundle using git command but don't know how to configure ~/.vimirc. Please help! (OSX by the way.)

you can refer https://github.com/VundleVim/Vundle.Vim https://github.com/VundleVim/Vundle.Vim.
There are details about how to configure the vimrc .
Good Luck.

在 2015年12月8日，上午5:52，zeraus<EMAIL_ADDRESS>写道：
I'm pretty new to Vim, installed Vundle using git command but don't know how to configure ~/.vimirc. Please help! (OSX by the way.)
—
Reply to this email directly or view it on GitHub https://github.com/VundleVim/Vundle.vim/issues/676.

@zeraus just following up. were you able to get setup?

Closing. Please respond if you still need help


Call to private method RainLoop\Actions::getAccountFromToken() error

Just upgraded from <IP_ADDRESS>4 to <IP_ADDRESS>2. After the upgrade, I cannot login anymore. Instead, when I enter the correct login credentials, the screen would refresh and the login prompt would show again. This is part of the error message from the webserver:
[error] 17528#0: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Call to private method RainLoop\Actions::getAccountFromToken() from context '' in /var/www/mail/rain
/rainloop/v/<IP_ADDRESS>2/app/libraries/RainLoop/Actions.php on line 9140" while reading response header from upstream...

Thanks! Sorry for that.
Fast fix:
/var/www/mail/rain/rainloop/v/<IP_ADDRESS>2/app/libraries/RainLoop/Actions.php ~1274
private function getAccountFromToken($bThrowExceptionOnFalse = true)
{

public function getAccountFromToken($bThrowExceptionOnFalse = true)
{

Fastest fix ever. Thanks.  :+1:

Fixed in <IP_ADDRESS>3 version.


Newly Revamped Navbar + "Filter" Section

Hello! I noticed that this app's Navbar and Filters section could use some redesigning. I am a professional Graphic Designer and I'm looking into contributing to opensource, so I'd be honored if I was given the opportunity to redesign these sections of your app!
Here are my proposals:

Merge "Select language" and "Search Bar" into a single "double search bar" like the one on Indeed.com.
Create a new "Filters" section that combines the page-search bar and the "Filters" dropdown into a single line
Move "Sort By Stars" and "Sort By Forks" to a new "Sort By" button that is attached to the "Filters" section
Make everything responsive, so it works on mobile devices

I firmly believe that these changes would modernize the look of the app and lead to a significantly improved user experience.
This would be my first opensource contribution, but I'm excited to learn about the opensource workflow. If it goes smoothly I could even design a new logo for the site!

Hey, this is great! Thanks for the inputs will update the tags so someone can pick it up as an enhancement!

Yeah I'd love to pick it up if possible! :)


Can't close database properly when database is locked.

Because Connection::close consumes the connection, it's impossible to retry when closing yields an error. I've encountered an "Error code 5: The database file is locked" error when closing. It seems that the proper thing to do is to sleep for some time and then try again, but I can't do this because I no longer own the connection or hold a reference to it.
Very possible I'm misunderstanding something here, but from what I can understand it seems there's something wrong here.

Hmm you're right. Maybe we should return something like std::Result<(), (Connection, Error)> so on failure you get back both the error and the connection so you can retry. Would that be suitable for your use?

Depending on the crate version, the issue may be related to #186.
Regards.

Yes, good point. @joshhansen were you using cached statements and if so, could you retry with release 0.8?
Conceptually this is still an issue though - we shouldn't consume the connection on close() and then fail and leave the user without a way to retry.

@joshhansen #200 addresses the API issue of close consuming the connection even when it fails, although I think in principle you shouldn't be able to get a database locked error when closing (unless it's the result of a bug, like the prepared statement one referenced above). If you're still seeing errors from close on 0.8 please open another issue so we can investigate.

Yes, I am using cached statements, so the connection to #186 seems accurate. I was using 0.7.3 and tried upgrading to 0.8.0, and it appears to have resolved the error I was getting. As far as the conceptual issue with the API, I agree that returning std::Result<(), (Connection, Error)> would be sufficient as it would allow for arbitrary retries.
Thanks for the speedy feedback and for the library!

Cool, I won't worry about rushing out another release with #200 included then. Thanks for the update!


Question - How can you test meteor methods

How would you test Meteor methods and for example test the Meteor accounts on create user method? Are there any examples for this?

+1

Hi, any updates on this?


Sql File backup

Can permissionsex have this SQL backup where when it loses connection to MySQL it can run from a backup file it last updated? It was a bit annoying for my users when my MySQL had some issues.

Sorry wrong section :P


Typo leading to confusion: missing "not"?

In the section about Microsoft Teams, you state "The [userType] property on the B2B user, whether guest or member, does change the end user experience."
You initially say "Users created by cross-tenant synchronization will have the same experience when accessing Microsoft Teams and other Microsoft 365 services as B2B collaboration users created through a manual invitation"
So presumably there is a "not" missing in the first piece I quote, as in "does not change the end-user experience"? Although equally the "not" might be missing from the second piece I quote!
Since this is slated to change over time, it will be important to be crystal clear on what the current state is!
Cheers
James

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: f85ee4b9-27cf-8dd6-15cf-4c3b4489b371
Version Independent ID: 735ec160-05cf-c910-f9e1-f031b7c110e7
Content: What is a cross-tenant synchronization in Azure Active Directory? (preview) - Microsoft Entra
Content Source: articles/active-directory/multi-tenant-organizations/cross-tenant-synchronization-overview.md
Service: active-directory
Sub-service: multi-tenant-organizations
GitHub Login: @rolyon
Microsoft Alias: rolyon

@JBWCowling
Thanks for your feedback! We will investigate and update as appropriate.

@JBWCowling
Thanks for pointing this out. I have performed the required changes and it will reflect soon in the document.


port to Java(FX)

An ... idea:
What is the points to port D3 to Java, current target is JavaFX?
Thanks

D3 is heavily reliant on the W3C DOM API. You could take the concepts behind D3 (such as the selection and data-join) and apply them to a different scenegraph, but it wouldn’t be so much a “port” as a conceptual cousin. At any rate, I have no plans on porting D3 to other environments, so that would be a project for someone else. :grin:


Replication controller issues too many lists

Currently RC has the following logic:
MainLoop():

Watch for new RC and sync them immediately
Every 5 sec list all RC and sync them

SyncRC():

List all pods matching selector for RC
Add/Remove pods

This is suboptimal on both layers. We should use watch for both RC and pods. Current implementation generates very high load in apiserver.

cc @wojtek-t @davidopp @lavalamp

@bprashanth

I believe this is addressed in https://github.com/GoogleCloudPlatform/kubernetes/issues/5884

Changing assignee since @bprashanth is actually working on this.

@fgrzadkowski @bprashanth - what's the current status of it? Is it fixed now?

I think this is done. Currently most lists come from kubelet which is expected.

Thanks for confirmation (that was also my observation).


Allow attributes duplication on element

It will be great to have element attributes validation as [[name, value]] array, instead of Record<name, value>.
Why it may be needed?
In glimmer-next we allow users to have multiple class attributes to avoid ugly concat statements.

Sample: https://github.com/lifeart/glimmer-next/blob/6b90ffce23ed26e68b2d8ecbc3bbd3d892e2195e/src/components/pages/benchmark/Row.gts#L87
It bring clear separation of concerns (static class parts, dynamic class parts).

Why not?:

At the moment there is no way to allow ...attributes to drop some classes (because it's merged by default)
But it we allow constructions like this:

@NullVoxPopuli it’s not an Ember proposal, it’s just about flexibility of internal architecture, since in hbs ast we already have attributes represented as array of properties, not objects.


Expand on this

Expand on this
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: fe44a625-07a6-7d65-d16e-a8544c034261
Version Independent ID: 54310bdb-1397-cd5a-688c-f8e5c042a3fb
Content: Custom business processes - Azure Solution Ideas
Content Source: docs/solution-ideas/articles/custom-business-processes.yml
Service: architecture-center
Sub-service: solution-idea
GitHub Login: @Zimmergren
Microsoft Alias: architectures

@asir1997
Could please elaborate your query for better understanding. Thanks!!!

@asir1997
We are going to close this thread, if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.
#Please-close


Circle tool: Radius/Diameter values are being converted when unit is changed (ArcMap)

build 11 Jan 2017 13:51 addin

I enter a center point, a radius of 1000. Units were set to meters when tab was accessed...

I now change the Units from Meters to Kilometers...

I click back into Radius / Diameter parameter and hit return so graphic is created...

Instead of the circle having a radius of 1000 kilometers it converted the initial value of 1000 meters and converted to the equivalent kilometers. The tool should not be converting units value when the units is changed.

PR #262

Verified @elinz

@joebayles @pHill5136 @rjones0 Issue verified. Closing issue.


Linked Lists

Pull Request for PyVerse 💡
Issue Title :  Linked Lists

Info about the related issue (Aim of the project) :   Linked lists are a fundamental data structure that allows efficient storage and manipulation of data and learn about it.
Name:  Aviral Garg
GitHub ID:  aviralgarg05
Email ID<EMAIL_ADDRESS>Idenitfy yourself: (Mention in which program you are contributing in. Eg. For a WoB 2024 participant it's, WoB Participant)  GSSOC 24' Extended

Closes: #issue number that will be closed through this PR
#7
Describe the add-ons or changes you've made 📃
Created a Linked Lists algorithm for Data Structures
Give a clear description of what have you added or modifications made
Created a Linked Lists algorithm for Data Structures
Type of change ☑
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested? ⚙
Describe how it has been tested: - Outputs have been clearly mentioned
Describe how have you verified the changes made:- Runtime and Correct outputs
Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

@aviralgarg05 please add comments in the code too in this format
'''python
def <function_name>():
"""
<Brief description of the function's purpose.>
Args:
    <parameter_name> (<parameter_type>): <Description of the parameter.>

Returns:
    <return_type>: <Description of the return value.>

Example:
    >>> <function_name>(<example_input>)
    <example_output>
"""
# Function logic here

'''

@aviralgarg05 please add comments in the code too in this format
def <function_name>():
<Brief description of the function's purpose.>

Args:
    <parameter_name> (<parameter_type>): <Description of the parameter.>

Returns:
    <return_type>: <Description of the return value.>

Example:
    >>> <function_name>(<example_input>)
    <example_output>

# Function logic here

Changes requested are made


Can't get graphql-import-loader work in my Prisma GraphQLServer written in typescript

Hi,
I have been struggling in the last days trying to make this work without any success. What I want to do is configure my graphql server with Webpack 4. The server is written with Typescript. In the end, I want to be able to call something like this in my index.ts file:
import { GraphQLServer } from 'graphql-yoga';
import { Prisma } from './generated/prisma';

import resolvers from './resolvers';
import typeDefs from './schema.graphql';

const server = new GraphQLServer({
  typeDefs,
  resolvers,
  context: req => ({
    ...req,
    db: new Prisma({
      endpoint: process.env.PRISMA_ENDPOINT,
      secret: process.env.PRISMA_SECRET,
      debug: true
    })
  })
});

server.options.port = Number(process.env.PORT) || 4000;
server.options.endpoint = '/';

server.start(() =>
  console.log(`Server is running on http://localhost:${server.options.port}`)
);

Critical point here is
import typeDefs from './schema.graphql';

Until several days of googling, I wasn't able to find a solution to make this work.
Here's my package.json:
{
  "name": "MyServer",
  "version": "0.0.0",
  "scripts": {
    "start": "dotenv -- nodemon -e ts,graphql -x ts-node src/index.ts",
    "dev": "npm-run-all --parallel start playground",
    "debug": "dotenv -- nodemon -e ts,graphql -x ts-node --inspect src/index.ts",
    "clean": "rimraf dist",
    "tsc": "tsc",
    "playground": "graphql playground",
    "build": "npm run clean && webpack --config ./webpack.prod.js",
    "postinstall": "cross-var prisma login --key $PRISMA_SERVICE_TOKEN && prisma deploy"
  },
  "dependencies": {
    "bcryptjs": "2.4.3",
    "graphql-yoga": "1.7.0",
    "jsonwebtoken": "8.2.0",
    "prisma-binding": "1.5.16"
  },
  "devDependencies": {
    "@types/bcryptjs": "2.4.1",
    "babel-core": "^6.26.0",
    "babel-loader": "^7.1.4",
    "babel-preset-env": "^1.6.1",
    "cross-var": "^1.1.0",
    "dotenv-cli": "1.4.0",
    "graphql-cli": "2.15.8",
    "graphql-import-loader": "^0.2.1",
    "json-loader": "^0.5.7",
    "nodemon": "1.17.2",
    "npm-run-all": "4.1.2",
    "prisma": "1.5.1",
    "rimraf": "2.6.2",
    "ts-loader": "^4.2.0",
    "typescript": "2.8.1",
    "uglifyjs-webpack-plugin": "^1.2.5",
    "webpack": "^4.6.0",
    "webpack-cli": "^2.0.15",
    "webpack-node-externals": "^1.7.2"
  }
}

Here's my webpack config:
const webpack = require('webpack');
const path = require('path');
const nodeExternals = require('webpack-node-externals');

module.exports = {
	target: 'node',
	entry: './src/index.ts',
	externals: [nodeExternals()],
	output: {
		filename: '[name].[chunkhash].js',
		chunkFilename: '[name].[chunkhash].js',
		path: path.resolve(__dirname, 'dist'),
		libraryTarget: 'commonjs'
	},
	resolve: {
		extensions: ['.graphql', '.ts', '.js', '.json']
  },
  node: {
    fs: 'empty'
  },
	module: {
		rules: [
			{
                            exclude: /node_modules/,
                            test: /\.ts$/,
                            use: [
				{ loader: 'babel-loader' },
				{ loader: 'ts-loader' },
                            ],
			},
			{
			  test: /\.json$/,
			  exclude: /node_modules/,
			  loader: 'json-loader'
			},
			{
				test: /\.graphql$/,
				exclude: /node_modules/,
				loader: 'graphql-import-loader',
			}
		]
	},

	mode: 'development',
};

Here's my tsconfig.json:
{
  "compilerOptions": {
    "target": "es5",
    "moduleResolution": "node",
    "module": "commonjs",
    "allowJs": true,
    "sourceMap": true,
    "outDir": "dist",
    "lib": [
      "esnext", "dom"
    ]
  },
  "files": ["typings/typings.d.ts"]
}

In addition to my index.ts file, I have defined the following typings.d.ts:
declare module '*.json' {
  const content: any
  export default content
}

declare module '*.graphql' {
  const content: any
  export default content
}

In that file, I also tried this:
declare module '*.graphql' {
  import { DocumentNode } from 'graphql'
  const content: DocumentNode
  export default content
}

That doesn't work better. My graphql schemes look like this:
# import Post from "./src/generated/database.graphql"

type Query {
  feed: [Post!]!
  drafts: [Post!]!
  post(id: ID!): Post
  me: User
}

type Mutation {
  signup(email: String!, password: String!, name: String!): AuthPayload!
  login(email: String!, password: String!): AuthPayload!
  createDraft(title: String!, text: String!): Post!
  publish(id: ID!): Post!
  deletePost(id: ID!): Post!
}

type AuthPayload {
  token: String!
  user: User!
}

type User {
  id: ID!
  email: String!
  name: String!
  posts: [Post!]!
}

where "./src/generated/database.graphql" is found at the correct location and is valid (is generated by Prisma deploy).
My file structure is as follows:

database

datamodel.graphql
...

node_modules
src

generated

database.graphql
prisma.ts

resolvers

Query.ts
...

index.ts
schema.graphql
...

typings

typings.d.ts

Now, when I try the following code in my index.ts, I get the "undefined" output:
import typeDefs from './schema.graphql';
console.log("schema = " + typeDefs);

The output of this console log is:
schema = undefined

I tried to use
import * from typeDefs from './schema.graphql';
This is outputting the complete schema.graphql file in my console, but then I don't know how to use it in the GraphQLServer.
Could someone please explain to me how to make this work?

/label question

Until now, I was actually able to get that working but somehow not very elegantly. I can do the following:

webpack copies the graphql files from the src to the dist folder
I use the graphql-import package like this:

import { importSchema } from 'graphql-import'

const typeDefs = importSchema('./schema.graphql');

const server = new GraphQLServer({
  typeDefs,
  resolvers,
  ...
});

Then, it works. But in this case, I need to be very careful about the location of the graphql files and how I run my server. I really need to
cd dist
node main.mychunk.js

and then it works. If I was able to do what graphql-import-loader promises I can do in its documentation, then I would just need to import the graphql schema and it will be integrated to my final js file in my dist folder. I would not need to let webpack copy the graphql file into the dist folder and I would not need to care how I run my server.

I have posted a similar question here: https://github.com/graphql-boilerplates/typescript-graphql-server/issues/194
Indeed, my code comes from that repo.

Please give a try to the following in your typings.d.ts:
declare module '*.graphql' {
  const value: any
  export = value
}

Then hopefully importing it like that import * from typeDefs from './schema.graphql' should be working...

This is working now. Thank you very much. May I ask you what the difference is between
declare module '*.graphql' {
  const value: any
  export = value
}

and
declare module '*.graphql' {
  const value: any
  export default value
}

?


missing license?

Heyo!
Should this repo be licensed? Can you add it if it's missing, please? :)

Fixed, all code contained in all commits to this repository are licensed under MIT


New Website Logo: Expensya

Please fill the following out:

Name: Expensya
Homepage url: http://www.expensya.com
Brand Guidelines/Licensing: Go ahead, we want you to add the logo :)
Logo: https://notefraistest.blob.core.windows.net/emails/Expensya.png

Ping :) and happy summer!


@Test methods from super class are re-executed for every sub class

TestNG Version 6.14.3
Expected behavior
The @Test methods from the super class are executed once no matter how many sub classes inherit the super class.
Actual behavior
The @Test methods are executed with each sub class.
Is the issue reproductible on runner?

[ ] Shell
[ ] Maven
[x] Gradle
[ ] Ant
[ ] Eclipse
[ ] IntelliJ
[ ] NetBeans

Test case sample
public class BaseTest  extends SetupClass{
    @BeforeClass...
    @BeforeMethod...
    @AfterClass...
    @AfterMethod....

    @Test
    public void baseMethod(){
        System.out.println("base method");
    }
}

public class Test1 extends BaseTest{
    @Test
    public void test1(){
        System.out.println("test1");
    }
}

public class Test2 extends BaseTest{
    @Test
    public void test2(){
        System.out.println("test2");
    }
}

I am running these tests in parallel from a TestNG xml file that looks like this:
<suite name="Regression Suite" verbose="1" parallel="classes" thread-count="4">
    <parameter name="project" value="TestPrj"/>
    <parameter name="server" value="QA01"/>
    <test name="QA01 TestPrj">
        <parameter name="environment" value="macos"/>
        <groups>
            <run>
                <include name="regression"/>
            </run>
        </groups>
        <packages>
            <package name="test"/>
        </packages>
    </test>
</suite>

P.S. Editing code in github issues is incredibly bad...please move to something else.

@vlad230

P.S. Editing code in github issues is incredibly bad...please move to something else.

You might want to spend sometime getting yourself familiarized with Markdown. That would make it very easy to add code snippets along with formatting.

@krmahadevan thanks for the formatting :)

Am not quite sure I understand your issue here. Ultimately the child classes would get the base class methods as well. And if they are annotated with TestNG annotations they are going to get executed for every child class. That is the behavior of TestNG. So I would say that TestNG is working as designed.

If you ask me, it wouldn't make any sense to execute the tests in the super class multiple times.
If this is the expected behaviour of TestNG right now, maybe we could add this as in improvement.

Working as designed.
Why don't you move baseMethod test in its own class?

@vlad230

If you ask me, it wouldn't make any sense to execute the tests in the super class multiple times.

What exactly are you trying to achieve? It would be great if you could please help elaborate or explain your scenario.

If this is the expected behaviour of TestNG right now, maybe we could add this as in improvement.

Am not sure that would be taken up as an enhancement because its counter intuitive . If you basically want the base class method to be executed exactly once, no matter how many child classes are present, then you could do it today in your test project by doing the following

Have your base class implement org.testng.IHookable
Within its run() method, add an edit check that would check if the base class method is already executed and run it if not executed.

Here's a sample
Marker interface that indicates that a base class method should run only once
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;

import java.lang.annotation.Retention;
import java.lang.annotation.Target;

@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)
@Target({METHOD, TYPE})
public @interface RunOnce {
}

Here's the state tracker singleton
import java.lang.reflect.Method;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class StateTracker {

  private static final StateTracker instance = new StateTracker();

  private final Map<String, Object> runOnceData = new ConcurrentHashMap<>();

  private StateTracker() {}

  public static StateTracker getInstance() {
    return instance;
  }

  boolean canExecute(Method method) {
    RunOnce runOnce = method.getAnnotation(RunOnce.class);
    String methodName = method.getName();
    boolean execute = true;
    if (runOnce != null) {
      if (runOnceData.containsKey(methodName)) {
        execute = false;
      } else {
        runOnceData.put(methodName, new Object());
      }
    }
    return execute;
  }
}

Here's how the base class would look like
import org.testng.IHookCallBack;
import org.testng.IHookable;
import org.testng.ITestResult;
import org.testng.annotations.Test;

public class BaseTest implements IHookable {

  @Test
  @RunOnce
  public void baseclassTestMethod() {
    System.err.println("Base class test method executed");
  }

  @Override
  public void run(IHookCallBack callBack, ITestResult testResult) {
    boolean execute =
        StateTracker.getInstance()
            .canExecute(testResult.getMethod().getConstructorOrMethod().getMethod());
    if (execute) {
      callBack.runTestMethod(testResult);
    } else {
      testResult.setStatus(ITestResult.SKIP);
      testResult.setThrowable(new RuntimeException("Intentionally skipping"));
    }
  }
}

Here's how the child classes would look like
import org.testng.annotations.Test;

public class ChildClass1 extends BaseTest {

  @Test
  public void childTest() {
    System.err.println(getClass().getName() + ".childTest() executed");
  }
}

import org.testng.annotations.Test;

public class ChildClass2 extends BaseTest {

  @Test
  public void childTest() {
    System.err.println(getClass().getName() + ".childTest() executed");
  }
}

You would need to add some filtering mechanism that prunes the test results and removes skipped tests which are annotated using @RunOnce

@krmahadevan
What exactly are you trying to achieve? It would be great if you could please help elaborate or explain your scenario.

I'm trying to separate the tests in multiple classes (that are related to a feature). For example you have a "base class" that has the setup part for that feature with @Before & @After methods along side other helper methods (not tests) that support the tests from the base class along side the tests in the "child classes". So, this way you would just add new tests to your child classes and not duplicate the code in the child classes.
The base class would have some test methods that test more general parts of that feature and the child classes will have more specific tests.
Since I'm trying to optimize the test run time by running classes in parallel, I had to split my original "base class" which had 50+ test methods into multiple smaller "child classes" such that these smaller classes are distributed to other threads/executors.
@krmahadevan thanks a lot for the detailed solution but it looks a bit cumbersome to me. Since TestNG can be customized, I would rather see this as the default behaviour.
I don't see a need of constantly re-executing the tests from the base class. If it's a matter of setup/teardown one could always use @Before/@After that would be re-executed every time before a child class from the base class.

Yes, I think the behavior could be configurable.
In fact, I don't find a use case where we want to run the parent test for each child instance.
Unless you have a direct dependency to test (dependsOnMethods) because the test state is often modified like that in integration tests.
@krmahadevan WDYT?

@vlad230

thanks a lot for the detailed solution but it looks a bit cumbersome to me

Your use case also kind of looks a bit different from the regular. Moreover I have given you a working example of how it can be done. All you need to do is, just adopt this and build upon this.

Since TestNG can be customized, I would rather see this as the default behaviour.

No. That cannot be done in my opinion. Tests are meant to be executed all the time. Just because they reside in a base class doesn't mean that they have to be selectively executed. TestNG can be customised. But that doesn't mean TestNG needs to support all customisations. It merely needs to provide for ways in which a user should be able to customise it to their needs and work with it. The sample I shared is an example of applying those customisations without TestNG having to undergo changes.

I don't see a need of constantly re-executing the tests from the base class. If it's a matter of setup/teardown one could always use @Before/@after that would be re-executed every time before a child class from the base class.

To me that is just one way of looking at things. If a particular method shouldn't be executed everything, then you should not be using the @Test annotation. You could very well use the configuration annotations such as @BeforeTest (which gets executed only once per <test> tag) or @BeforeSuite (which gets executed only once per <suite> tag) no? Wouldn't they work for you.
I am not sure, if your test methods in your base class are really test methods. To me they sound more like configurations which establish the setup conditions to be satisfied for the test to run through.
@juherr - I am not quite sure I agree with the use case here. A test irrespective of where it is found is meant to be executed. If there is scenario wherein we don't want it to be executed for all child classes, then we should be using the configuration annotations and not the @Test annotation.
On the implementation side, I think this will add a lot of chaos to the codebase especially when people start resorting to using groups as a means for execution.
Moreover, I feel that there is already a way of doing this currently within TestNG (which I have shared as an example). Why not just leverage that? This seems to be a one off use case, and doesn't seem to fit into the regular way of how TestNG is used.

@krmahadevan I'm sorry, but I think you didn't understand what I'm trying to do.
In my parent class (base class - e.g. DashboardTest) I have 15 tests now and I have 3 child classes (e.g. DashboardFilterTest, DashboardTreeTest, DashboardEditorTest) that each have tests inside. Using the approach I described in my post, each time I run the tests, those 15 tests get executed 3 times over bringing no value and extending the run time uselessly.
I still think it doesn't make sense for tests that are located in a parent class to be re-executed each time tests form a child class are executed. Would prefer the default behaviour of TestNG to execute test methods from a parent class once, irrespective of the number of child classes that are extending it.
If this cannot be done, I understand. Thanks anyway.

@vlad230
Thanks for adding additional context.

In my parent class (BaseTest - e.g. DashboardTest) I have 15 tests now and I have 3 child classes (e.g. DashboardFilterTest, DashboardTreeTest, DashboardEditorTest) that each have tests inside. Using the approach I described in my post, each time I run the tests, those 15 tests get executed 3 times over (so, 3x15 = 45 tests being executed) bringing no value and extending the run time uselessly, as opposed to just executing the 15 tests once.

In that case, why would DashboardFilterTest, DashboardTreeTest, DashboardEditorTest be extending DashboardTest ? It looks like DashboardTest tests need to reside in their own class instead of you leveraging an inheritance approach here no? The base class should be refactored to remove out all the common test methods and be housed in a separate test class, and DashboardTest should be refactored to just house common non @Test methods no ?

If this cannot be done, I understand. Thanks anyway.

It's not about if they can be done or not (the implementation challenges is a separate topic), but I am still having a hard time trying to understand the validity of the use case itself.

@krmahadevan

In that case, why would DashboardFilterTest, DashboardTreeTest, DashboardEditorTest be extending DashboardTest ? It looks like DashboardTest tests need to reside in their own class instead of you leveraging an inheritance approach here no? The base class should be refactored to remove out all the common test methods and be housed in a separate test class, and DashboardTest should be refactored to just house common non @Test methods no ?

'DashboardTest' contains helper methods (e.g. openDashboard(), createDashboard() etc.) and setup/teardown/cleanup (@Before/@After) methods that are needed for the child classes as well. So, I don't need to replicate the code in the child classes.
Yes, some of the tests in 'DashboardTest' could be moved to some other specific classes but I wanted to keep them here since they are more general (e.g. checking the overall look of the dashboard, basic CRUD tests or even some tests that didn't fit in a specific category or are a mix).
Sure, I could have a non-@Test test class (although it looks weird since I'm using the POM design pattern) but it would be just to avoid this issue, right?

@vlad230

'DashboardTest' contains helper methods (e.g. openDashboard(), createDashboard() etc.) and setup/teardown/cleanup (@Before/@after) methods that are needed for the child classes as well. So, I don't need to replicate the code in the child classes.

This makes sense. and yes they can very well reside within the base class so that the configuration methods are made available to the child classes as well.

Yes, some of the tests in 'DashboardTest' could be moved to some other specific classes but I wanted to keep them here since they are more general (e.g. checking the overall look of the dashboard, basic CRUD tests or even some tests that didn't fit in a specific category or are a mix).

You could still create a class called GenericDashboardTest extends DashboardTest which houses all the generic @Test methods in it.

Sure, I could have a non-@test test class (although it would be weird and someone could add tests here by mistake) but it would be just to avoid this issue, right?

Well, isn't that what code reviews are there for :) To prevent such slippages. The base class (from what you explained) doesn't need to contain the common generic @Test methods. It can very well house just the helpers and the configurations and you can have one more test class which extends the base class and houses the generic test methods. That should resolve the confusion at hand.

Closing this issue with resolution as working as designed


Pin pyarrow<13 on macOS to avoid crash (sc-51866)

Temporarily pin pyarrow<13 on macOS to avoid crash (sc-51866).

This does not appear to be possible for 2.25

I confirmed this. The latest tiledb that can be co-installed with pyarrow 12 is 2.24.1. The reason is the aws-crt-cpp pin (though there may be additional incompatible pins; this is the just the first incompatibility the solver finds). pyarrow 12 was last built against aws-crt-cpp 0.26, but tiledb 2.25 was first built against aws-crt-cpp 0.27.
mamba create --dry-run -n test -c conda-forge 'pyarrow<13' tiledb
## + aws-crt-cpp                    0.26.12  he940a02_1            conda-forge      340kB
## + tiledb                          2.24.1  h2aae180_1            conda-forge        4MB
## + python                          3.11.9  hb806964_0_cpython    conda-forge       31MB
## + libarrow                        12.0.1  h0de2578_50_cpu       conda-forge       28MB
## + pyarrow                         12.0.1  py311h8eb17fa_50_cpu  conda-forge        4MB

# pyarrow 12 was not built against aws-crt-cpp 0.27
mamba create --dry-run -n test -c conda-forge 'pyarrow<13' aws-crt-cpp=0.27
# long solver error

# tiledb 2.25 was not built against aws-crt-cpp 0.26
mamba create --dry-run -n test -c conda-forge tiledb=2.25 aws-crt-cpp=0.26
## The following packages are incompatible
## ├─ aws-crt-cpp 0.26**  is requested and can be installed;
## └─ tiledb 2.25**  is not installable because it requires
##    └─ aws-crt-cpp >=0.27.3,<<IP_ADDRESS>a0 , which conflicts with any installable versions previously reported.

Wait a second. I realized I don't understand the context of this PR. What is the crash on macOS? Has a new error been identified?
I know in the past that we pinned pyarrow in order to avoid a macOS-specific segfault due to the AWS SDK (https://github.com/apache/arrow/issues/42154), but it's my understanding that this bug only affects the PyPI wheels because both tiledb and pyarrow bundle statically linked AWS C libraries.
xref: https://github.com/TileDB-Inc/tiledb-vcf-feedstock/pull/114, https://github.com/TileDB-Inc/tiledb-vcf-feedstock/pull/111

Closing, @gspowley is working on the underlying issue.


[Doc] Doc update on bitmap_count & character_length

add doc for bitmap_count & character_length

Signed-off-by: Kevin Xiaohua Cai<EMAIL_ADDRESS>What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[X] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto backported to target branch

[ ] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

@mergift backport branch-2.5 branch-2.4 branch-2.3

@mergify backport branch-2.5 branch-2.4 branch-2.3


Armv8.2 Compile

How to configure -march=armv8.2-a+fp16 when compiling ios c++ library with Cmake？

.

This issue tracker is for a command-line tool called "hub" which is written in Go. Your question seems unrelated to this project, and you should find a more appropriate forum to ask it in. Thank you.