[ENH] Revise command line script

Part of #225.
In this PR the run.py script is revised:

[x] Create a new module fmriprep.utils.bids to bring together those methods handling bids. This module is a potential candidate to be wrapped in niworkflows and use it with mriqc.
[x] Some improvements to the logging, will work on this in a future.
[x] Reorganized logical flow (which, btw was broken: it did not have much sense to run --reports-only and --write-graph.
[x] Checking some flags brought earlier. We probably want to customize the parser to remove the clutter from run.py. For now we only have two checks, so no big deal.
[x] Some linting and PEP8 fixes.

Also, are you wanting to merge this and #622 changes before 0.6.0?

Yes, thanks for your comments. I'll incorporate them tomorrow morning
On Jul 29, 2017 11:00, "Chris Markiewicz"<EMAIL_ADDRESS>wrote:

Also, are you wanting to merge this and #622
https://github.com/poldracklab/fmriprep/pull/622 changes before 0.6.0?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/pull/621#issuecomment-318847736,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkhxi30SfcHU-3M2Kf7o2d1cRFNdj2gks5sS3NCgaJpZM4OnMVa
.

Does this look like a quick fix, or should we push these two off to the next release?

Sure, np
On Jul 31, 2017 05:46, "Chris Markiewicz"<EMAIL_ADDRESS>wrote:

Does this look like a quick fix, or should we push these two off to the
next release?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/pull/621#issuecomment-319056912,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkhxjRW3sWLl2hzClZNHcvmuTtGnU6Iks5sTcyrgaJpZM4OnMVa
.

@effigies @chrisfilo it'd be great that we all explicitly agree on that transforming as many tests as we can to doctests is a good idea.
Doctests would also play better with @effigies' future idea of adding the code to the generation of documentation to also cover the API.

Thanks a lot :). I'm enjoying this housekeeping! :+1:


Add more sensors to Eurotronic SpiritZ

Better Hass support, for graphing and data
To work with entities which represent data, added some sensors for
homeassistant discovery

Valve Position: Values 0-100
Room temperature: Celsius room temperature
Set temp as Sensor for normal and Eco

@robertsLando I would like these to be used from both stella and spiritz. But I do not know how to make them merge an array of sensors and the Climate hashmap
in order words something like:
 [SPIRIT_ZWAVE_PLUS] + EUROTRONIC_S_ZWAVE_SENSORS
where the latter can be one hashmap with all sensors.

Are them using the same values? Because each value can only be binded to a unique Hass discovery

Are them using the same values? Because each value can only be binded to a unique Hass discovery

i have a customDiscovery using these sensors, and some values are also shared (same) with the climate discovery.
the system seems to work properly. in my homeassistant.
  "328-1-3": [
    {
      "type": "climate",
      "object_id": "thermostat",
      "values": [
        "64-1-0",
        "49-1-1",
        "67-1-1",
        "67-1-11"
      ],
      "mode_map": {
        "off": "Off",
        "heat": "Heat",
        "cool": "Heat Eco"
      },
      "setpoint_topic": {
        "Heat": "67-1-1",
        "Heat Eco": "67-1-11"
      },
      "default_setpoint": "67-1-1",
      "discovery_payload": {
        "min_temp": 8,
        "max_temp": 28,
        "modes": [
          "off",
          "heat",
          "cool"
        ],
        "mode_state_topic": "64-1-0",
        "mode_command_topic": true,
        "current_temperature_topic": "49-1-1",
        "temp_step": 0.5,
        "current_temperature_template": "{{ value_json.value }}",
        "temperature_state_template": "{{ value_json.value }}",
        "temperature_command_topic": true
      }
    },
    {
      "type": "sensor",
      "object_id": "target_temperature_heat",
      "discovery_payload": {
        "value_template": "{{ value_json.value }}",
        "device_class": "temperature",
        "unit_of_measurement": "°C",
        "state_topic": "67-1-1"
      },
      "values": [
        "67-1-1"
      ]
    },
    {
      "type": "sensor",
      "object_id": "target_temperature_heat_eco",
      "discovery_payload": {
        "value_template": "{{ value_json.value }}",
        "device_class": "temperature",
        "unit_of_measurement": "°C",
        "state_topic": "67-1-11"
      },
      "values": [
        "67-1-11"
      ]
    },
    {
      "type": "sensor",
      "object_id": "room_temperature",
      "discovery_payload": {
        "value_template": "{{ value_json.value }}",
        "device_class": "temperature",
        "unit_of_measurement": "°C",
        "state_topic": "49-1-1"
      },
      "values": [
        "49-1-1"
      ]
    },
    {
      "type": "sensor",
      "object_id": "valve_position",
      "discovery_payload": {
        "value_template": "{{ value_json.value }}",
        "state_topic": "38-1-0"
      },
      "values": [
        "38-1-0"
      ]
    }
  ],```

@billiaz I need to check the code, I'm sure that in some cases it will work without any problems but on z2m side I only store 1 discovery for each value, I think that for example in the case you press "rediscover node" only the last one will rediscovered for example

Yes like I told you if you check /lib/Gateway.js you will see it has a property named discovered that is a map String --> Object where the key is the valueId string and the value contains the discovery payload. This could work but could also create some problems as I said in my previous comment

so this is clearly a z2m bit. are these values used to produce uniqueness or also to discover where they belong?
Asking this, if these are just "labels" might worth to name them differently in this case.

@billiaz @aretakisv them are used to keep track of the discovered values of each node, them are used to remove the discovered values for xample when a node is removed or to rediscover them when the user press on rediscover, also if you check on discovered devices you should not be able to see all of them if some have multiple devices discovered with same valueId. Also when a message is received I check for discovered device of that valueId to see If it need to be parsed (for example rgb values)

@robertsLando i am the same person Billiaz or this, just replying from another account.
if the value for instanes is 49-1-1-S would that cause any issues, as teh 49-1-1 topi path do not exist? in that case

@billiaz I think that the only fix would be to make that an array of discovered templates instead of single objects

you mean , like my example of customDevices.json right? one array of templates!
ofcourse in the end we submit this as an array as you can see.

you mean , like my example of customDevices.json right? one array of templates!

Nope I mean in Gateway.js, discovered actually keeps track of 1 discovered template foreach value ATM. Needs to be converted in array to support this (but this would need some refactor on the code)

you mean , like my example of customDevices.json right? one array of templates!

Nope I mean in Gateway.js, discovered actually keeps track of 1 discovered template foreach value ATM. Needs to be converted in array to support this (but this would need some refactor on the code)

I think this will be useful change. I am not sure for other devices but for this thermostat in particular it hinders its functionality. For example the topic 64-1-0 is used for setting the heating mode but also for enabling the direct valve control. The current dimmer on/off functionality is not working.
Another benefit is what @aretakisv is doing to expose some of the readings as sensors. This can be done with custom defined sensors in HA but it is better if they are working correctly with autodiscovery.
Are there plans for changing the implementation in the Gateway.js? Unfortunately my JS is not existing at all.

Are there plans for changing the implementation in the Gateway.js? Unfortunately my JS is not existing at all.

Actually nope because I'm focusing on the transition to https://github.com/zwave-js/zwavejs2mqtt


Update Composer dependencies (2020-06-10-00-11)

Visual regression test passed!
View the visual regression test report


Fixes Issue Where 'validate' CLI can only validate md5 and sha1

Currently - the validate cli does some pre-flight checking that will falsely return "not a valid bag" if the manifest is something other than md5 or sha1.
The Bag class does a good job of validating, and logging any errors already.
I did a version bump since the output could be different and I want to be upfront that
if anyone is shelling out to bagit validate then the output could be different.
Here's a few example runs:
Against A Perfect sha512 manifested bag
$ bagit validate ~/Desktop/gigantic_bag

I, [2016-12-14T15:10:35.226085 #87202]  INFO -- : true

Against A Bag with corrupted files
$ bagit validate ~/Desktop/gigantic_bag

E, [2016-12-14T15:24:12.065865 #88549] ERROR -- : false: Consistency expected /Users/sschor/Desktop/gigantic_bag/data/lorem_1.txt to have Digest::SHA512: x969d110708b17873e9e6ca7ee4aef8baabbec765df80af88b9d6ec11711810bf6ce460610fbe4694c5a7f5808c284e8cacee9d3e12bf9bc4f76ec1329e5e45d, actual is 2969d110708b17873e9e6ca7ee4aef8baabbec765df80af88b9d6ec11711810bf6ce460610fbe4694c5a7f5808c284e8cacee9d3e12bf9bc4f76ec1329e5e45d, Consistency expected /Users/sschor/Desktop/gigantic_bag/data/video_1.mov to have Digest::SHA512: x0d70bc663de5afda6b1e95634115b8e81a63acbccb58a3530e5ad92fc0d25c2dc0b3d77c9009813c15d11453b17cea93980e8a8a3a64681a33f48706bbb56f1, actual is f0d70bc663de5afda6b1e95634115b8e81a63acbccb58a3530e5ad92fc0d25c2dc0b3d77c9009813c15d11453b17cea93980e8a8a3a64681a33f48706bbb56f1, Consistency expected /Users/sschor/Desktop/gigantic_bag/data/urand.data to have Digest::SHA512: x4f857fe404d2858140edfe74f1a45d93604e4884494b4a9d9c4851ba7dd11b1814020de8c2f169fd01d3dfcc57bd422e75794b5cc69236e75c42c84e7f7c911, actual is 64f857fe404d2858140edfe74f1a45d93604e4884494b4a9d9c4851ba7dd11b1814020de8c2f169fd01d3dfcc57bd422e75794b5cc69236e75c42c84e7f7c911, Consistency expected /Users/sschor/Desktop/gigantic_bag/manifest-sha512.txt to have Digest::SHA512: aa4d37c0708df182485ba7cc97732e24e898ee166aa73f79e2cb44232c7b55858852dd83a34322db02b9e8c05571f8de819dd39775f72062bf21e20891075ea3, actual is 234ba48d097666b1c56f2061a38908007f5354d3377dfd0edb2cec50698716972ffd34ee01553dcb8ab6ffe6331bc1d308388efb11d660bcc8ff9a20898e6c81, Consistency is invalid

With a manifest named 'manifest-sha51333.txt'
$ bagit validate ~/Desktop/gigantic_bag
/Users/sschor/.rvm/gems/ruby-2.3.0/gems/bagit-0.3.5/lib/bagit/valid.rb:65:in `block in consistent?': Algorithm sha51333 is not supported. (ArgumentError)
	from /Users/sschor/.rvm/gems/ruby-2.3.0/gems/bagit-0.3.5/lib/bagit/valid.rb:49:in `each'
...SNIP!

Coverage remained the same at 98.361% when pulling 47df9498fc9c0e35542b1cbacafc78c7a78299d2 on nodanaonlyzuul:change-cli-output into f0593db0eb989e53130a5ca0892fab693663f7e6 on tipr:master.

Coverage remained the same at 98.361% when pulling b62d02b02b29972118f6476146e9f66f123def99 on nodanaonlyzuul:change-cli-output into f0593db0eb989e53130a5ca0892fab693663f7e6 on tipr:master.


Add project launch date

TODO:

[x] increment counters manually where counter cache is removed
[x] update/recount workflow.classifications_count

Fixes #1398 btw

I'm voting against my previous thought wrt unretire in this branch. Smaller branches are better.

@camallen moved callbacks to service objects.

Looks good, specs failing though.

LGTM - if you are happy, lets get it live!


Potential UB on exception in otext_cursor::write

otext_cursor has two write members, both stylistically similar to:
void write(const character_type_t<encoding_type> &value) {
    iterator_type tmp{current};
    int encoded_code_units = 0;
    encoding_type::encode(state(), tmp, value, encoded_code_units);
    current = tmp;
}

Note that the function copies the adapted iterator member current, updates the copy by passing a reference to encoding_type::encode, and then stores its value back into current. Presumably the intent of this delayed update is to leave current unmodified if encoding_type::encode throws an exception.
However, iterator_type is only required to be single-pass: if it is truly a single pass (input or output but not forward) iterator, the "old" value in current is not required to be valid after encoding_type::encode increments tmp (or even simply writes a value through tmp in the output case). The exception safe approach may introduce undefined behavior.
I would solve this problem by creating an RAII guard class that stores a reference to an iterator and a copy of its value - only if that iterator's type models ForwardIterator - and moves the value back into the original object unless released prior to destruction.

Yup, good find, Casey, thank you!  Your suggested solution sounds exactly right as well.

Fixed by commit 6b499433ea8a46a76df7cacb97863ece921f16bf.


Register v3.5.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/855
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.5.0 -m "<description of version>" e40dc65bc343d7adb1713e527d6efa9e33104606
git push origin v3.5.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/1235
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.6.0 -m "<description of version>" c985be8bd834dd53113c16b3679bc20d1b317291
git push origin v3.6.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/2798
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.6.2 -m "<description of version>" c7e81d252ced859459a8c5785c8c2722af892137
git push origin v3.6.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/3353
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.7.0 -m "<description of version>" aa684a80ba5404cfb8c2be7c379597447a2c930c
git push origin v3.7.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/4947
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.8.0 -m "<description of version>" f72eb8e4c6faced36ff1eb66b75538c231431a0b
git push origin v3.8.0

@JuliaRegistrator register()

Registration pull request updated: JuliaRegistries/General/4947
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.8.0 -m "<description of version>" ba79f881c667556829579c3c4d146e82b794f333
git push origin v3.8.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/6064
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.8.1 -m "<description of version>" 90ec5466df22a61129c3d84665bb113cf6aafd81
git push origin v3.8.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/8879
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.8.2 -m "<description of version>" e17d3f11db5d9f4c9e75af74c6cf10468533ae8a
git push origin v3.8.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/9899
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.8.3 -m "<description of version>" 4180a5b040e56c98257471e40047efd3303a4aae
git push origin v3.8.3

@JuliaRegistrator register()

Error while trying to register: "Tag with name 3.8.3 already exists and points to a different commit"

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/10942
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if Julia TagBot is installed, or can be done manually through the github interface, or via:
git tag -a v3.9.0 -m "<description of version>" 1651f8686f8f912546f3d2fb36c6272ffa1a18c7
git push origin v3.9.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/12314
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.0.0 -m "<description of version>" 6643177a7981ef9380d13d6a43315063d1f426c7
git push origin v4.0.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/12648
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.1.0 -m "<description of version>" fcd51e95e1d35fc50d63007230219ac00bd45982
git push origin v4.1.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/12935
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.1.1 -m "<description of version>" 7057981f9b814c6e0b0f5bf4eb85d58a537a6b84
git push origin v4.1.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/13523
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.2.0 -m "<description of version>" eb6b89a4eace7c11cd9ba828b5363bb7952b1db1
git push origin v4.2.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/13846
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.2.1 -m "<description of version>" 7b2b6e9df644da19292918cbf69bdaf39a48643c
git push origin v4.2.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/14766
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.2.2 -m "<description of version>" 2067b587e57b1c6668bb61444670dc0015fa3a29
git push origin v4.2.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/16391
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.2.3 -m "<description of version>" 8c82c59869a774b236bf594a36a1f715752d3c0b
git push origin v4.2.3

@JuliaRegistrator register()

Error while trying to register: "Tag with name v4.2.1 already exists and points to a different commit"

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/19686
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.2.6 -m "<description of version>" 659de1cf9a14f7b99759e17a683e3ed765c35f19
git push origin v4.2.6

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/19875
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.3.0 -m "<description of version>" 73fc3af7231482e41976128e9ebe01f1a898a59e
git push origin v4.3.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/26907
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.4.0 -m "<description of version>" 5181d22b1523aed26452e3b56cba5510cb47c24f
git push origin v4.4.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/35970
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.4.2 -m "<description of version>" b192fc893087a8e660b8e3b24d6120156b583d8a
git push origin v4.4.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/36037
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.4.3 -m "<description of version>" 7b34c2eb58c250321fa189db9eb70c0116c11f3f
git push origin v4.4.3

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/38353
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.5.0 -m "<description of version>" 6cdf6b4a90ea26854428a455c22a0a1bc9d1c31f
git push origin v4.5.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/39961
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.5.1 -m "<description of version>" f67f1a63a836df56849f77a3fc583d6cb458e48e
git push origin v4.5.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/40936
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.5.2 -m "<description of version>" 9403f43ec5fbf97d7a33790dd2f26dd5989e40d1
git push origin v4.5.2

@JuliaRegistrator register()

Error while trying to register: "Tag with name v4.5.2 already exists and points to a different commit"

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/41046
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.5.3 -m "<description of version>" 62f2e03adf85ec0eed0c397c43022974fcd72e35
git push origin v4.5.3

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/45758
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.5.4 -m "<description of version>" 480e6231b515d5cb363e54f769edddb35f426ba3
git push origin v4.5.4

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/46067
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.6.0 -m "<description of version>" 8bb15e9a0defdc0ccb7f78ec28c362e1e47a0908
git push origin v4.6.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/50995
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.7.0 -m "<description of version>" 8ba3a78d00cef4ddb4cd6afae6b36d347023e2a0
git push origin v4.7.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/51164
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.7.1 -m "<description of version>" 6d5c9aabdb5d1b9c07625ff811e09e259aa5ed02
git push origin v4.7.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/51316
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.8.0 -m "<description of version>" 77cff79fc9c7b9afdbac5f4ac12702b6ada4e2a6
git push origin v4.8.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/51601
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.9.0 -m "<description of version>" 8f15d52f709e1f8b78f9ba0989eb097c3ad89f26
git push origin v4.9.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/51988
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.9.1 -m "<description of version>" d14e851905bdac58de3f3d420bfada4d7205f270
git push origin v4.9.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/54426
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.9.2 -m "<description of version>" 5d8e840bf79aaca21ea46606faf435c5c2a3e901
git push origin v4.9.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/60275
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.9.4 -m "<description of version>" 8a6d87f1dcbb7033d04e1076caaf32c9adb80bc0
git push origin v4.9.4

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/66630
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.9.5 -m "<description of version>" 5653e19cd4442addf9299e1cf6a10873f7c6d9ca
git push origin v4.9.5

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/66752
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.10.0 -m "<description of version>" 5b56612f9ec8cb13a50f3e22cf3a5b79bbfe8b64
git push origin v4.10.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/67635
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.10.1 -m "<description of version>" c7469aa1a164efb03e20c47c558eeacbc2755e24
git push origin v4.10.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/70362
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.10.2 -m "<description of version>"<PHONE_NUMBER>92132a659fdba0fe9c42a7535a2d65
git push origin v4.10.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/70377
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.10.3 -m "<description of version>" 5c1f88769a5060e92d9f32789f04435f11269363
git push origin v4.10.3

@JuliaRegistrator register()

@JuliaRegistrator register()

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/72854
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.11.0 -m "<description of version>" df85d9fe6ed1b2b2b7f610185ebdb59d23f0f3b7
git push origin v4.11.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/72880
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.11.1 -m "<description of version>" 2d3407010910d67dd36101561435422fe3903e41
git push origin v4.11.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/73438
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.11.2 -m "<description of version>" 7a4882f725a4250d555cf365233526a41aee0ac5
git push origin v4.11.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/73444
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.11.3 -m "<description of version>" c00489eb668c291c9e546c1a010ba40297721a94
git push origin v4.11.3

@JuliaRegistrator register()

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/75638
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.12.0 -m "<description of version>" 12f69c2b6870e39b806aaffbca4c4ef6c764e694
git push origin v4.12.0

@JuliaRegistrator register()

Registration pull request updated: JuliaRegistries/General/75638
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.12.0 -m "<description of version>" aa5681f610afc44a3ccc0298a0f767d844db6fcc
git push origin v4.12.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/76630
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.13.0 -m "<description of version>" 887404782c89dc32d5748e268bb0fd308a68f76c
git push origin v4.13.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/77072
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.14.0 -m "<description of version>" fe412b3686bc49e732d28b025801078c797c5a86
git push origin v4.14.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/77298
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.15.0 -m "<description of version>" 697c05dfcf5c63306974731e6d19dfc4c005d3dc
git push origin v4.15.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/79607
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.16.0 -m "<description of version>" df8c45d44570029c0e18b77d12b16c8a605a654c
git push origin v4.16.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/82844
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.17.0 -m "<description of version>" 92891ee4f805b086d41d4c4a87f09602f4f79d85
git push origin v4.17.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/83772
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.18.0 -m "<description of version>" f4d7801ae1ea8947a201a97421ca6653b6c66527
git push origin v4.18.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/84312
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.19.0 -m "<description of version>" 090c2d4df08da1cfce6516abbf488df1b3c64168
git push origin v4.19.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/86663
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.19.1 -m "<description of version>" 37f466b14eba4cae8b3bcf1ebb2b32f34b3a2469
git push origin v4.19.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/86698
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.19.2 -m "<description of version>" 0f046225987cd8a132b7e56b75c0d2ada115d1fb
git push origin v4.19.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/86708
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.19.3 -m "<description of version>" 439a225287f3242e8e9556803d1814a60fbb555b
git push origin v4.19.3

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/91414
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.19.5 -m "<description of version>" e69a23deadcf1e1ae0ce9e5dfaf92b85bdf28cc7
git push origin v4.19.5

Also, note the warning: Version 4.19.5 skips over 4.19.4
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/91415
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.19.4 -m "<description of version>" e4a165c26fd0a52149af49a4afd0890589d3df10
git push origin v4.19.4

Registration pull request created: JuliaRegistries/General/91664
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.19.5 -m "<description of version>" f0a693685ff65aadea072ac2701153f2bc870ae4
git push origin v4.19.5

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/91955
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.20.0 -m "<description of version>" ca8ac7cd0c0c9d096abcbaf904f88b16b9bc6356
git push origin v4.20.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/94192
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.20.1 -m "<description of version>" b01e0c3d5633e0e72ade903fe35c9a8e955d2840
git push origin v4.20.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/96834
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.21.0 -m "<description of version>" fc4326937183f62c794385126b19f9c184428429
git push origin v4.21.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/96851
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.22.0 -m "<description of version>" b9307f79803c13c88a25c57889bd1a9b5a291ba2
git push origin v4.22.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/96976
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.22.1 -m "<description of version>" efd1a0a04a99ed68b3bc5f42e94e8e2aecbfdf09
git push origin v4.22.1

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/97669
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.24.0 -m "<description of version>" fc3452da35634dbdeb0ad1e6671099f2f8100683
git push origin v4.24.0

Also, note the warning: Version 4.24.0 skips over 4.23.0
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

@JuliaRegistrator register()

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/99676
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.23.2 -m "<description of version>" ce4753f518ae318f3b9a067121e9de576e2f0866
git push origin v4.23.2

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/100966
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.24.0 -m "<description of version>" 1ca5ee44d6fdc36da6a4e11b71d4450248cd64c5
git push origin v4.24.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/113371
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.25.0 -m "<description of version>" d7e83c086d40e1b5b7ce470cccfea5dfd5586ec3
git push origin v4.25.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/117042
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.26.0 -m "<description of version>" d22dbf36cfbd3b98759f3398109b3a4520e9d343
git push origin v4.26.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/118972
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v4.26.1 -m "<description of version>" cdde5c9cba3671ddd5f223c58b0949963e43431e
git push origin v4.26.1


Added AlertMessageComponent unit tests

Added AlertMessageComponent unit tests for issue #69

Can one of the admins verify this patch?

ok to test


ResultSet fetch size doesn't work on a specific table

Description
Since last update (I think), for a specific table, the fetch size limit doesn't work.
Dbeaver do a request without LIMIT as you can see in the screenshot.
All tables are on the same (local) database, and only the table with name "APPLY" has the problem.
I think the issue came from the table name because I have the same issue with other remote DB with table named "APPLY".

DBeaver Version
CE <IP_ADDRESS>312241705
Operating System
Ubuntu 20.04
Database and driver
Server : MySQL 8.0.35-0ubuntu<IP_ADDRESS>
Driver : MySQL Connector/J mysql-connector-j-8.2.0 (Revision: 06a1f724497fd81c6a659131fda822c9e5085b6c)
Steps to reproduce
1 Create a DB with a table named APPLY (with a column "test")
2 Try to open table data tab.
Additional context
No response

I found something :
On version 23.3.0, the limit for the table APPLY is made with "SET SQL_SELECT_LIMIT=2000"  (why ?)
2024-01-05T11:07:46.430594Z	    8 Query	/* ApplicationName=DBeaver 23.3.0 - Main */ SET SQL_SELECT_LIMIT=2000
2024-01-05T11:07:46.430916Z	    8 Query	/* ApplicationName=DBeaver 23.3.0 - Main */ SELECT x.* FROM mydb.APPLY x
2024-01-05T11:08:07.740136Z	    8 Query	/* ApplicationName=DBeaver 23.3.0 - Main */ SELECT x.* FROM mydb.ANSWER x
LIMIT 0, 2000

On 23.3.1, the "SET SQL_SELECT_LIMIT=2000" is missing.
2024-01-05T11:09:28.851750Z	    9 Query	/* ApplicationName=DBeaver 23.3.1 - Main */ SELECT x.* FROM mydb.APPLY x
2024-01-05T11:10:20.541644Z	   10 Query	/* ApplicationName=DBeaver 23.3.1 - Main */ SELECT x.* FROM mydb.ANSWER x
LIMIT 0, 2000

Thanks for the report.

Hello @LonwoLonwo,
While waiting for this bug to be resolved, is there a workaround?
Since you say “For now, I see that the SELECT statement correctly adds limits if I have quotes around the Apply table name.”, I was looking for a way to add quotes to DBeaver generated queries, but I couldn't find any config in DBeaver settings or in the jdbc driver :/.


Unable to attach the Screenshot to the report

Hi @grasshopper7
I am using the below code to attach the screenshot to the report, but in the report the image is empty, Can you please help?
@After
public void addScreenshotsToReport(Scenario scenario) {
    if (scenario.isFailed()) {
        byte[] screenshot = ((TakesScreenshot) baseDriver.driver).getScreenshotAs(OutputType.BYTES);
        scenario.attach(screenshot, "image/png", scenario.getName());
    }
}

Do u have the screenshot properties in the extent.properties? Can u add the extent.properties here?
screenshot.dir=test-output/
screenshot.rel.path=../

I found the issue and fixed. Thanks 👍
Code and Properties here :
    @After     public void addScreenshotsToReport(Scenario scenario) throws IOException {         if (scenario.isFailed()) {             byte[] screenshot = ((TakesScreenshot) baseDriver.driver).getScreenshotAs(OutputType.BYTES);             scenario.attach(screenshot, "image/png", scenario.getName());         }     }
screenshot.dir=test-output/screenshots screenshot.rel.path=./screenshots/


[BUG]: Missing unsigned bigint for serial reference

What version of drizzle-orm are you using?
0.28.2
What version of drizzle-kit are you using?
No response
Describe the Bug
See this discussion: https://github.com/drizzle-team/drizzle-orm/discussions/491
At the moment, it's not possible to use a serial() for primary key, and then reference it in another table because Drizzle doesn't offer anyway to create an BIGINT UNSIGNED.
Expected behavior
We need an API like: bigint('something', { mode: 'number' }).unsigned().notNull()
Environment & setup
No response

I had this issue not long ago and saw one of the solutions provided here by using custom types, please take a look.
https://github.com/drizzle-team/drizzle-orm/issues/258#issuecomment-1586393450

Thank you, @thisisandreww  !
Closing this issue as it's a duplicate of https://github.com/drizzle-team/drizzle-orm/issues/258


[RFC] Data Layout Structure in TVM Node System

As we now more and more rely on data layout optimization to get decent performance, I'd like to introduce Layout structure into TVM Node system. It would make life easier because,

Relay and NNVM both have AlterOpLayout pass to modify data layout between layers, for now they have their own Layout implementation.
Later on @kevinthesun will introduce end-to-end auto-tuning. The basic idea is to take inter-layer layout transformation overhead into consideration. As a module in AutoTVM, it will be more nature to use LayoutNode in TVM (instead of that in Relay or NNVM)
Layout operation can be exposed to Python/Java/Rust/Golang/... frontend directly. TOPI developers will benefit from it as performance is greatly related to data layouts.

It was initially proposed by @tqchen https://discuss.tvm.ai/t/datalayout-structure/80 . A modified implementation can be found here.
Definition of a Single Layout
The layout is composed of upper cases, lower cases and numbers, where upper case indicates a primal axis and the corresponding lower case with factor size indicates the subordinate axis. For example, NCHW16c can describe a 5-D tensor of [batch_size, channel, height, width, channel_block=16]. data_NCHW and data_NCHW16c can be converted to each other by data_NCHW[n, c, h, w] = data_NCHW16c[n, c/16, h, w, c%16]
LayoutNode can be constructed by a valid layout string. It provides helper function to query the index of an axis, number of dimension, etc.
LayoutNode is not implemented to be bind with a fixed shape, that is to say, technically one can assign layout NCHW to a 3-dim tensor, while this is highly discouraged, developers need to keep it in mind.
Bijective Layout and Layout Transform
Formally a data layout transformation is a bijective function mapping from the source index (i0, i1, …, im) to the target index (j0, j1, … jm). Given two LayoutNode, BijectiveLayoutNode build and store the mapping rule as following,
// Describes how source axis can be mapped
// to the target axis, e.g., [i0 / 16, i1, i0 % 16] can describe NC -> NC16n
Array<Expr> forward_rule;
// and vice versa
Array<Expr> backward_rule;

If the given two layouts cannot be converted to each other (e.g., NCHW and OIHW), an undefined Node will be returned. So one can check bilayout.defined() to test whether two layouts are convertible.
The C++ code below shows the transform interface.
class BijectiveLayout : public NodeRef {
 public:
  BijectiveLayout() = default;
  explicit BijectiveLayout(NodePtr<Node> n) : NodeRef(n) {}

  // Given the shape of the source layout, infer the target shape.
  TVM_DLL Array<Expr> ForwardShape(const Array<Expr>& shape) const;
  // Given the target shape, recover the source shape.
  TVM_DLL Array<Expr> BackwardShape(const Array<Expr>& shape) const;
  // Given the indices in the source layout, infer the target indices.
  TVM_DLL Array<Expr> ForwardIndex(const Array<Expr>& index) const;
  // Given the indices in the target layout, infer the source indices.
  TVM_DLL Array<Expr> BackwardIndex(const Array<Expr>& target_index) const;

  /*!
   * \brief access the internal node container
   * \return the pointer to the internal node container
   */
  inline const BijectiveLayoutNode* operator->() const;

  /*! \brief specify container node */
  using ContainerType = BijectiveLayoutNode;
};

For example, to convert shape,
bilayout = tvm.bijective_layout("NCHW", "NCHW16c")
dst_shape = bilayout.forward_shape((1, 32, 7, 7))
assert get_const_tuple(dst_shape) == (1, 2, 7, 7, 16)

print(bilayout.forward_shape([tvm.var("n"), tvm.var("c"), tvm.var("h"), tvm.var("w")]))
# output [n, (c/16), h, w, 16]

to convert tensor access index,
bilayout = tvm.bijective_layout("NCHW", "NCHW16c")
dst_index = bilayout.forward_index([0, 18, 6, 6])
assert get_const_tuple(dst_index) == (0, 1, 6, 6, 2)  # 1 * 16 + 2 = 18

print(bilayout.forward_index([tvm.var("n"), tvm.var("c"), tvm.var("h"), tvm.var("w")]))
# output [n, (c/16), h, w, (c%16)]

closed by https://github.com/dmlc/tvm/pull/2509


The big refactor: Integrate atmst+cbrrr

Closing this issue because the refactor has turned into a full rewrite, of course https://github.com/DavidBuchanan314/millipds
I'll be leaving this repo as-is for reference purposes, I think it's a useful example of how simple an atproto PDS can be, even if it cuts some corners to get there!


[Docs] Getting Started - Error Management

We need a huge section for this since it is by far our hugest problem for new users.
Here are cases we need to make sure we cover:

Fail task and stop stream when an error occurs

This should be the default behavior

Fail task after stream finished when an error occurs

testing or linting

Log when an error occurs but stop nothing

for people who like partial builds

Will we still have option to exit with error code on any error?
I wrap gulp scripts with bash and this behavior is also required.

:+1: really. I cannot use gulp in my CI because I am afraid I am not catching all the errors, I would like to know a bullet proof approach for  catching all the errors inside task or a composition of tasks with parallel/series

@phated Are there any docs anywhere for error management in bach/gulp 4?

@contra https://github.com/phated/async-done#completion-and-error-resolution but it hasn't been thoroughly tested with gulp pipelines and all the errors that can happen there.  Also, --continue flag is available to continue running on failure.  See #871

Hey @contra
Another case i would like to see (it its makes sense)
it's like case 3. but it filters the failed files from the stream.
My use case:
I have partial build with linter before the build step on the same pipe.
i would like that if file have linter error to log error and not continue down the pipe to the build step without breaking the entire stream.

@Bnaya You mean like the behavior using gulp-plumber?

I'm working with gulp4 and i understand that plumber is not needed (?)
Also i read plumber's docs and i can see any reference that it will filter the files with errors from the stream. i might have missed something
This is what i want to achieve, without the need to explicitly check for file.eslint.errorCount
my  builder.build will break if file with syntax error will get to it so i need to filter them.
gulp.src(changedFileRef.path)
.pipe(gulpEslint())
.pipe(gulpMap(function (file) {
    if (file.eslint.errorCount === 0) {
        return builder.build(toRelative(file.path));
    } else {
        return Promise.resolve();
    }
})

And also if there a more elegant way to send the data to the builder.build without gulp-map. i couldn't find something else
Thanks!

gulp-plumber not needed in gulp4? sounds strange.. indeed?

I just came on to beg that Gulp 4 report errors by default, am I correct in interpreting this ticket as handling that?

Updated the title here because it will belong under the "Getting Started" documentation and it'll be titled "Error Management"

I've had some trouble finding examples of migrating error handling from Gulp 3 to 4. I'm not sure if likes it, but to me the developer experience of error handling is my greatest frustration with Gulp. I've spent dozens of hours over the years trying to make three things work across tasks:

Errors don't end a running watch task.
Errors fire an OS notification with small hints at the issue (task, file, line number).
Errors are logged to the console with detail on the issue and good UX (formatting, color).

I'm not a JS architect, but I'd like to share some code failures and successes to get the ball rolling.
Failed

Works when the task compiles
Fails when the task doesn't compile, which ends the watcher.

function css (cb) {
    var task = config.task.css;

    gulp
    .src(task.src, { sourcemaps: true })
    .pipe(sass(task.sassOptions))
    .pipe(autoprefixer(task.autoprefixerOptions))
    .pipe(gulp.dest(task.dest, { sourcemaps: task.mapDest }))
    .pipe(gulpif(!isSilent, notify(task.notifyOptions)));

    cb();
};

Failed

Works when the task compiles.
Fails when the task doesn't compile, which ends the watcher and doesn't run the error handler.

function css () {
    var task = config.task.css;

    return pump([
        gulp.src(task.src, { sourcemaps: true }),
        sass(task.sassOptions),
        autoprefixer(task.autoprefixerOptions),
        gulp.dest(task.dest, { sourcemaps: task.mapDest }),
        gulpif(!isSilent, notify(task.notifyOptions))
    ], errorHandler);
};

Works

Works when the task compiles.
Works when the task doesn't compile, and the watcher stays running.

function css (cb) {
    var task = config.task.css;

    pump([
        gulp.src(task.src, { sourcemaps: true }),
        sass(task.sassOptions),
        autoprefixer(task.autoprefixerOptions),
        gulp.dest(task.dest, { sourcemaps: task.mapDest }),
        gulpif(!isSilent, notify(task.notifyOptions))
    ], errorHandler);

    cb();
};

Failed
The only approach that I found to work for my CSS task failed my JS task. I'm not sure why.

Works when the task compiles.
Works when the task doesn't compile, but the watcher only detects the first error. It stays watching but can't detect a fixed issue without restarting.

function jsAppPost (cb) {
    var task = config.task.jsAppPost;

    pump([
        gulp.src(task.src, { sourcemaps: true }),
        uglify(task.uglifyOptions),
        concat(task.file),
        gulp.dest(task.dest, { sourcemaps: true }),
        gulpif(!isSilent, notify(task.notifyOptions))
    ], errorHandler);

    cb();
}

My error handler
For reference, here's my error handler:
var beeper = require('beeper');
var color  = require('ansi-colors');
var notify = require('gulp-notify');

module.exports = function (error) {
    if (typeof error !== 'undefined') {
        // [log] Uncomment to show the full error object
        //console.log(error);

        // ----------------------------------------------
        // Normalize error responses

        var report = ['\n'];
        var notifyMessage = '';

        if (error.plugin == 'gulp-eslint') {
            report.push(color.red('Plugin: ') + error.plugin     + '\n');
            report.push(color.red('File:   ') + error.fileName   + '\n');
            report.push(color.red('Line:   ') + error.lineNumber + '\n');
            report.push(color.red('Note:   ') + error.message    + '\n');

            notifyMessage = 'JS linter found errors.';
        }

        if (error.plugin === 'gulp-sass') {
            report.push(color.red('Plugin: ') + error.plugin          + '\n');
            report.push(color.red('File:   ') + error.relativePath    + '\n');
            report.push(color.red('Line:   ') + error.line            + '\n');
            report.push(color.red('Column: ') + error.column          + '\n');
            report.push(color.red('Note:   ') + error.messageOriginal + '\n');

            notifyMessage = error.relativePath + '\n' + error.line + ' : ' + error.column;
        }

        if (error.plugin == 'gulp-stylelint') {
            notifyMessage = 'CSS linter found errors.';
        }

        if (error.plugin === 'gulp-uglify') {
            report.push(color.red('Plugin: ') + error.plugin         + '\n');
            report.push(color.red('Path:   ') + error.fileName       + '\n');
            report.push(color.red('File:   ') + error.cause.filename + '\n');
            report.push(color.red('Line:   ') + error.cause.line     + '\n');
            report.push(color.red('Column: ') + error.cause.col      + '\n');
            report.push(color.red('Note:   ') + error.cause.message  + '\n');

            notifyMessage = error.cause.filename + '\n' + error.cause.line + ' : ' + error.cause.col;
        }

        // ----------------------------------------------
        // Show error in console

        console.error(report.join(''));

        // ----------------------------------------------
        // Fire Mac/Windows notification for error

        notify({
            title:   'Failed Gulp — See Console',
            message: notifyMessage,
            sound:   'Sosumi' // Sound for Mac. See: https://github.com/mikaelbr/node-notifier#all-notification-options-with-their-defaults
        }).write(error);

        beeper(); // Fallback to system sound (for Windows).
    }
};

Next steps
I'd like to help create the docs for error handling, and hope these examples get some feedback. I'm sure there's a working recipe and I just haven't found the right blog yet.

Now that Node.js v8 has reached its EOL, every pump() in gulp docs should probably be replaced with stream.pipeline().
https://nodejs.org/en/docs/guides/backpressuring-in-streams/#the-problem-with-data-handling

Is there any new known workaround for gulp 5 to prevent errors thrown during gulp watch from stopping the stream?

Is there any new known workaround for gulp 5 to prevent errors thrown during gulp watch from stopping the stream?

Is the --continue flag what you're looking for, @battk? I'm not using gulp 5 yet, but it appears to still be available in the latest gulp-cli

No difference, the problem doesnt actually affect gulp 4. I would guess its the same issue as in #2812. Its a little concerning that error handling has been a problem for a decade.

There is some update about this problem, described here.


[clarification]: Clarification on Case Sensitivity for Keywords in ANTLR Grammar for Jakarta Data Specification

Specification
https://github.com/jakartaee/data/blob/main/spec/src/antlr/JDQL.g4
I need clarification on ...
Please clarify how the Jakarta Data specification intends to handle case sensitivity for Query keywords in the ANTLR grammar.
Specifically, should the grammar support uppercase and lowercase keywords such as SELECT, UPDATE, and DELETE?
Another question: should the select be a constant instead of the quote:
select_clause : SELECT select_list;

select_clause : SELECT select_list;
// Token rules
SELECT          : 'SELECT' | 'select';

If we intend to allow both "SELECT" and "select" (or any other variations), then using 'SELECT' directly in your rules can be considered a bug because it restricts the input to only one case.
Additional information
No response

Section 5.2.1 says:

Identifiers are case-sensitive

Keywords and other reserved identifiers are case- insensitive

I think that covers it, no?

you are right


Add thorough data layer tests

The data layer is fundamental to how all operations on QuTiP Qobjs are performed, so we need to be really sure they're correct in all cases.
To achieve this we need to generate tests that thoroughly cover the possible inputs and combinations of dispatch functions. One possible approach / source of ideas is to reuse the test utilities from the data layer itself (see https://github.com/qutip/qutip/blob/dev.major/qutip/tests/core/data/test_mathematics.py).
Another possible approach is to use hypothesis -- see https://hypothesis.readthedocs.io/en/latest/numpy.html.

This has been tackled in #10 .


Remove useless bboxes&labels in CocoDataset

不好意思，PR #158 测试不周，，，，valid set 返回 NoneType 时会在collate时引发类型错误，修复了下这个问题～

以下是我对模型做了少量更改（为了部署）后得测试结果。
版本：commit 2021.2.22
修改内容：

leaky_relu -> relu6
PAN -> FPN
FPN(bilinear) -> FPN(nearest)

测试结果：
BGR：
mAP: 0.27045186089989737
AP_50: 0.4214516444114105
AP_75: 0.2862484957541031
AP_small: 0.10793292324828849
AP_m: 0.2944064369754226
AP_l: 0.39395007400120235

RGB：
mAP: 0.2794905872668077
AP_50: 0.4308761059392766
AP_75: 0.2924213184092761
AP_small: 0.11358375294212335
AP_m: 0.2997194595821626
AP_l: 0.4088541954988801

Pardon, but why would you want to remove all images without bounding boxes? Isn't it beneficial for the model to learn not to produce boxes for these images? Does it cause an issue somewhere later in the training loop?

Pardon, but why would you want to remove all images without bounding boxes? Isn't it beneficial for the model to learn not to produce boxes for these images? Does it cause an issue somewhere later in the training loop?

It will only delete images without bboxes in valid set, and will not affect train set.

Pardon, but why would you want to remove all images without bounding boxes? Isn't it beneficial for the model to learn not to produce boxes for these images? Does it cause an issue somewhere later in the training loop?

It will only delete images without bboxes in valid set, and will not affect train set.

I was thinking of these added lines in get_train_data:
        # Remove image without label&bbox
        if self.mode == 'train' and len(meta['gt_bboxes']) == 0:
            return None


Still doesn't connect after reinstall

Hi @MSMortensen
I think this is pretty much expected that there will be a limit. I'm not sure what's the max and how requests are counted (is it per user or the max is shared for whole app).
I'd suggest to decrease frequency, I believe the counter will get reset-ed after a while. Personally I run the sync once a day.
Best regards,
Jarek
Originally posted by @jaroslawhartman in https://github.com/jaroslawhartman/withings-sync/issues/11#issuecomment-722283294
Hi again,
I removed the docker container and image, as well as .withings_user.json, and tried to install it again.
I get the same error as before.
Any idea how I can get it to work again?
Best Martin
PS: I used my garmin username and password
$ docker run -v $HOME:/root --interactive --tty --name withings stv0g/withings-sync --garmin-username={MY_USERNAME} --garmin-password={MY_PASSWORD}
Unable to find image 'stv0g/withings-sync:latest' locally
latest: Pulling from stv0g/withings-sync
df20fa9351a1: Pull complete
36b3adc4ff6f: Pull complete
3e7ef1bb9eba: Pull complete
78538f72d6a9: Pull complete
1692f1a2776b: Pull complete
4dacf6c2b0b3: Pull complete
c860f9f6deb6: Pull complete
49e18d18e796: Pull complete
5ef3985ee8a9: Pull complete
ae195f2fe619: Pull complete
Digest: sha256:342fbae1c3cfa40c4f91bcbe555abb3038a1d9e14ab091463846671d1de874b4
Status: Downloaded newer image for stv0g/withings-sync:latest
2020-11-08 13:30:33,043 - withings - ERROR - Can't read config file /root/.withings_user.json
2020-11-08 13:30:33,044 - withings - WARNING - User interaction needed to get Authentification Code from Withings!
2020-11-08 13:30:33,044 - withings - WARNING -
2020-11-08 13:30:33,044 - withings - WARNING - Open the following URL in your web browser and copy back the token. You will have 30 seconds before the token expires. HURRY UP!
2020-11-08 13:30:33,045 - withings - WARNING - (This is one-time activity)
2020-11-08 13:30:33,045 - withings - WARNING -
2020-11-08 13:30:33,045 - withings - INFO - https://account.withings.com/oauth2_user/authorize2?response_type=code&client_id=183e03e1f363110b3551f96765c98c10e8f1aa647a37067a1cb64bbbaf491626&state=OK&scope=user.metrics&redirect_uri=https://jaroslawhartman.github.io/withings-sync/contrib/withings.html&
2020-11-08 13:30:33,046 - withings - INFO -
Token : 1fe12aff58bb01943b4750fd7e2fd2cda11de1f1
2020-11-08 13:30:53,622 - withings - INFO - Get Access Token
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 159, in _new_conn
conn = connection.create_connection(
File "/usr/local/lib/python3.8/site-packages/urllib3/util/connection.py", line 61, in create_connection
for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
File "/usr/local/lib/python3.8/socket.py", line 918, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Try again

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 670, in urlopen
httplib_response = self._make_request(
File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 381, in _make_request
self._validate_conn(conn)
File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 978, in _validate_conn
conn.connect()
File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 309, in connect
conn = self._new_conn()
File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 171, in _new_conn
raise NewConnectionError(
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPSConnection object at 0x7fe503241040>: Failed to establish a new connection: [Errno -3] Try again

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 439, in send
resp = conn.urlopen(
File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 726, in urlopen
retries = retries.increment(
File "/usr/local/lib/python3.8/site-packages/urllib3/util/retry.py", line 439, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='account.withings.com', port=443): Max retries exceeded with url: /oauth2/token (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fe503241040>: Failed to establish a new connection: [Errno -3] Try again'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/bin/withings-sync", line 33, in
sys.exit(load_entry_point('withings-sync==3.1.2', 'console_scripts', 'withings-sync')())
File "/usr/local/lib/python3.8/site-packages/withings_sync-3.1.2-py3.8.egg/withings_sync/sync.py", line 191, in main
sync(**vars(args))
File "/usr/local/lib/python3.8/site-packages/withings_sync-3.1.2-py3.8.egg/withings_sync/sync.py", line 77, in sync
withings = WithingsAccount()
File "/usr/local/lib/python3.8/site-packages/withings_sync-3.1.2-py3.8.egg/withings_sync/withings2.py", line 161, in init
self.withings = WithingsOAuth2()
File "/usr/local/lib/python3.8/site-packages/withings_sync-3.1.2-py3.8.egg/withings_sync/withings2.py", line 59, in init
self.getAccessToken()
File "/usr/local/lib/python3.8/site-packages/withings_sync-3.1.2-py3.8.egg/withings_sync/withings2.py", line 106, in getAccessToken
req = requests.post(Withings.TOKEN_URL, params)
File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 119, in post
return request('post', url, data=data, json=json, **kwargs)
File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 530, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 643, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='account.withings.com', port=443): Max retries exceeded with url: /oauth2/token (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7fe503241040>: Failed to establish a new connection: [Errno -3] Try again'))

Hi Jarek,
No matter what I do, I keep getting the message that the Mac retries exceeded with url.
Do you know if there is any way I can reset this for my withings account? I was hoping not to have to create a new withings or garmin account to get this otherwise amazing little program to work again.
Best,
Martin

Hi Jarek,
No matter what I do, I keep getting the message that the Mac retries exceeded with url.
Do you know if there is any way I can reset this for my withings account? I was hoping not to have to create a new withings or garmin account to get this otherwise amazing little program to work again.
Best,
Martin

Hi @MSMortensen,
I havnt experienced the issue you have with the max retries. Possibly the Docker container rans into some bug which then quickly exceeds the maximum number of retries which you are allowed to perform.
I would suggest to try it from another IP (e.g. your celluar connection) and contact the Withings support to get some info about their rate limits or how you can unblock your account.

I dig some further digging into this issue. The max retries exeeded message is acutally raised by the Python code not the Withings API. So I assume this must be a connection issue with your setup.
Maybe some broken DNS or IPv6.
I am closing the issue here as I doubt its caused by withings-sync and there are no other people with the same issue.


The debugging with stetho documentation is not updated apparently.

Description
The onCreate showed in the react-native debugging with stetho page is different that the showed in github.
//Showed in react page
public void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      Stetho.initializeWithDefaults(this);
      OkHttpClient client = new OkHttpClient.Builder()
      .connectTimeout(0, TimeUnit.MILLISECONDS)
      .readTimeout(0, TimeUnit.MILLISECONDS)
      .writeTimeout(0, TimeUnit.MILLISECONDS)
      .cookieJar(new ReactCookieJarContainer())
      .addNetworkInterceptor(new StethoInterceptor())
      .build();
      OkHttpClientProvider.replaceOkHttpClient(client);
}

//Showed in github page
public void onCreate() {
     super.onCreate();
     Stetho.initializeWithDefaults(this);
     OkHttpClient client = new OkHttpClient.Builder()
     .connectTimeout(0, TimeUnit.MILLISECONDS)
     .readTimeout(0, TimeUnit.MILLISECONDS)
     .writeTimeout(0, TimeUnit.MILLISECONDS)
     .cookieJar(new ReactCookieJarContainer())
     .addNetworkInterceptor(new StethoInterceptor())
     .build();
     OkHttpClientProvider.replaceOkHttpClient(client);
}

Reproduction
I'm new in react and I was trying to debug my app with stethos but I was having errors by following the react page instructions, but when I used the github onCreate method my debug works!.
Additional Information
React Native version: 0.41.2
Platform: Android
Operating System: Win 10

This is due to the way the website is built. You can always see the same docs as those from master on GitHub by clicking on the release version at the top of the site and choosing "master". You'll see the version change to next in that case.


angular-cli example

Can you provide an working angular-cli example?
We really want to achieve type safe queries on client side.

It seems angular-cli does not expose Custom Transformers API (I'm not an angular fan, not familiar with it).
If you find the way, please tell me 😄


Initial nomenclature

Implemented initial, agreed (with AEA) nomenclature compatible with TIMES-AT and medea.

closing in favor of #6


Tink_worker on sandbox deployment fails with CERT issue

As soon as the tink_worker is started it fails with an error x509 : certificate signed by unknown authority at linuxkit
Expected Behaviour

The tink_worker should work as the certificate is signed by Tinkerbell CA
Current Behaviour

The linuxkit boot screen is stuck waiting for the deployment. Upon checking the logs of the container we see that it fails to start with Unknown certificate issue.
Possible Solution

Need to sign the certificate properly
Steps to Reproduce (for bugs)

Run the docker container sandbox
Complete the template, hardware and workflow
Wait for the physical machine to acquire PXE boot and start of linuxkit
Linuxkit is stuck waiting for the container (tink_worker) to start. Upon evaluating the container logs we see the x509: certificate signed by Unknown authority.

Context

We are using tinkerbell in production to provision multiple linux physical machines and this issue has stopped us from moving forward.
Your Environment

Operating System and version (e.g. Linux, Windows, MacOS):

Ubuntu 18.04

How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:

Using docker-compose from sandbox ( https://github.com/tinkerbell/sandbox/tree/main/deploy/compose)

Link to your project or a code example to reproduce issue:

@gianarb , Did you get a chance to have a look at this issue? because I am also facing some cert related issues in tink-worker from last couple of days while setting it up on local machine using vagrant and virtualbox on Ubuntu 20.04.
I have not created a new ticket/issue because I think it is somewhat similar to this one.

Hey @umashankar1988, sorry for the delayed response. I've experienced this before and was able to resolve it by deleting the ca.pem file (this is in the state/ dir tree) and then docker-compose down and docker-compose up -d. Mind trying that?

Hi @jacobweinstock I tried using the steps suggested above but the issue still remains the same. Below is a screenshot from the /var/log/docker.log from the worker


auto compile documentation makes vim starts slower?

I have put the line
call pathogen#helptags()

in .vimrc.
I wonder if that will make vim starts slower than usual since it has to generate documentation each time for all plugins.
Haven't noticed any slowness yet since I just have 2 plugins in my bundle folder.

Pathogen only generates helptags if they do not already exist.  There is some overhead for scanning directories in your runtimepath, but I would say it is negligible.  Run a benchmark to see for yourself:
rm -rf /tmp/vim.log
vim --startuptime /tmp/vim.log -c quit
less /tmp/vim.log

Indeed. Automatically generating helptags is kind of "un-Vim-like", and you won't catch me doing it, but the downsides are minimal.


refactor(app): add warning if robot doesn't support custom labware

overview
If the user has custom labware present in the app, and they navigate to the protocol upload page, a warning will display if the robot hasn't yet been updated to the version needed to support custom labware in Python protocols
changelog

refactor(app): add warning if robot doesn't support custom labware

review requests
Ensure your app's "Custom Labware" feature flag is enabled
Empty folder

[ ] Warning does not show

Folder has labware, robot has support

[ ] Warning does not show

Folder has labware, robot does not have support

[ ] Warning does shows if not protocol was uploaded
[ ] Warning shows if protocol was uploaded and simulation errored
[ ] Warning does not show if protocol simulates successfully

Empty folder

[x] Warning does not show

Folder has labware, robot has support

[x] Warning does not show

Folder has labware, robot does not have support

[x] Warning does shows if not protocol was uploaded
[x] Warning shows if protocol was uploaded and simulation errored
[x] Warning does not show if protocol simulates successfully


communities: config: Update static page URLs to prevent name collisions

Fixes: https://github.com/inveniosoftware/invenio-communities/issues/1209

latest proposal (by @slint) on how to handle the links
/communities/new ---> /communities-new
/communities-search ----> /communities
/communities/<slug> -> leave as is
/communities ---> /communities-home

and we don't "reserve" any slugs
ping @ntarocco, is that OK?

Reviewed with Nico, going forward with the updated comment.


Add possibility to turn on mode when app only autorespond to numbers you already called or messaged to them.

hmm weird ticket, i see no purpose.


Modal example not working

In the page http://v4-alpha.getbootstrap.com/components/modal/, the modal example under "Tooltips and popovers" is not closing if I mouse-over through the tooltip links. I tried in Chrome over a mac.

The same in Opera for Windows and Android.

already fixed - please search the current repo before filing :) https://github.com/twbs/bootstrap/pull/21671

Have you tested it?

Have you? To be clear, http://v4-alpha.getbootstrap.com/ is v4.0.0-alpha.6 while the repo here is more up-to-date than that...


Add non-bracket functionality to autoclose

The autoclose plugin how has the ability to auto-indent in languages like Python and Lua.
Before, autoclose would only auto-indent and close brackets. Now it has the ability to auto-indent after words like then, do, and :.

Maybe this kind of functionality should be in a separate autoindent plugin? What do you think?

Separate plugin? I can do that.


Add discovery/gossipier persistens

Coverage decreased (-0.3%) to 73.654% when pulling f5f7a54eaa8c9249726e5e555a6c23b028c7d68b on AndrewSamokhvalov:gossipier_persistens into f9c78b7c2bf2801bfcd7dd4cf02c62565743c72a on lightningnetwork:master.

Coverage decreased (-0.2%) to 73.433% when pulling 4f3464bd0ca84f7fab485c6382424f416ece35ab on AndrewSamokhvalov:gossipier_persistens into 533cd69c7b44ad6d14acbd8aee374d99213a23b8 on lightningnetwork:master.


Add space around of !

if ( ! file_exists($filename))
{
    //
}

Hi @natanfelles,
When I started this, I based some rules on consistency in the majority of the code, there was no requirement for a space before a 'boolean not' in the CodeIgniter 4 style guide either, it does however indicate there should be a space after. I realise this differs to the CodeIgniter 3 style guide and I think as we're moving forward with a completely new version we can eliminate some of those CodeIgniter 3 oddities. If @jim-parry or @lonnieezell instruct me otherwise I'll change it, no problem.
So the CodeIgniter 4 syntax at the moment which the standard checks for is:
if (! file_exists($filename))
{
    //
}

@louisl the way you've got it working currently is the preferred way.
Just realized @jim-parry hasn't moved this over to the official repo, yet, has he?

@lonnieezell Thanks for the confirmation.
I haven't heard anything for a quite some time, but that's suited me to be honest, I've been very busy with the day job these last few months. I can see a few users are using the standard but it's not "out there" yet looking at the CI4 source code.
I've been working on another standard and have that working in a Travis CI build to check the source of some projects we're doing on pull requests. So when @jim-parry and yourself are ready to make it part of the pull request process I'll be able to help with the Travis set-up.
It'll flag up a ton of stuff at the moment though and I guess there's probably quite a few forks being worked on so I'm not sure if you want to implement it just yet.

@louisl It looks like the process to transfer the repo would be

add me as a maintainer to your repo
I can transfer it to bcit-ci
you retain maintainer rights on the transferred repo

packagist.org will need updating, with the new github repo link too
I will make an announcement on our forum once this is done :)

Closing, thanks!


OSASINFRA-3567: Fix setting external DNS on create

What this PR does / why we need it:
We were setting externalDNSDomain in completedCreateOptions, but reading it
from RawCreateOptions, so the value we were using was never set.
Fixing this changes how all services are published when setting
ExternalDNSDomain in the core options, which we do in CI.
Which issue(s) this PR fixes
Fixes #
Checklist

[x] Subject and description added to both, commit and PR.
[x] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.
[x] Create a bug in OSASINFRA

Thanks for fixing this, that was indeed an error in the initial CLI PR.
/lgtm
/hold for CI
e2e-openstack needs to pass first.

/lgtm cancel

/test e2e-openstack

/test e2e-openstack

/test e2e-openstack

Some console logs captured from a failing node:
[ 1477.795562] ignition[822]: GET error: Get "https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition": net/http: TLS handshake timeout
[ 1482.800859] ignition[822]: GET https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition: attempt #100
[ 1492.821930] ignition[822]: GET error: Get "https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition": net/http: TLS handshake timeout
[ 1497.822514] ignition[822]: GET https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition: attempt #101
[ 1507.844494] ignition[822]: GET error: Get "https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition": net/http: TLS handshake timeout
[ 1512.848844] ignition[822]: GET https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition: attempt #102
[ 1522.870240] ignition[822]: GET error: Get "https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition": net/http: TLS handshake timeout
[ 1527.870582] ignition[822]: GET https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition: attempt #103

> host ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com
ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com has address <IP_ADDRESS>
ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com has address <IP_ADDRESS>
ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com has address <IP_ADDRESS>

> curl https://ignition-example-jwzsl.service.ci.hypershift.devcluster.openshift.com/ignition

Note that the curl hung.

/test e2e-openstack

/hold cancel

/approve

bot went sleep...
/test e2e-aws e2e-kubevirt-aws-ovn-reduced


Complete & incomplete colour different design feedback 🔥

Complete & incomplete colour different design feedback 🔥

Hi Jasper, how would you like it if Complete was green/blue and Incomplete was yellow?

Yes master, dobby will work on it


nrf52840_mdk: support qspi flash

Added support for installed MX25R64 QSPI NOR flash.
Signed-off-by: Stephane D'Alu<EMAIL_ADDRESS>

Fixes #29271


[Bug]: Registering Network Storage Services with DynamoDb

Issue description
Registering network storage services for dynamoDb uses interface IMarket instead of INetwork.
Line in question:
https://github.com/iotaledger/explorer/blob/dev/api/src/initServices.ts#L156
Expected behaviour
ServiceFactory.register("network-storage", () => new LocalStorageService<INetwork>(
            config.rootStorageFolder, "network", "network"));

Actual behaviour
 ServiceFactory.register("network-storage", () => new AmazonDynamoDbService<IMarket>(
            config.dynamoDbConnection, "network", "network"));

Can the issue reliably be reproduced?
Yes
Steps to reproduce the issue
No response
Errors
No response
Duplicate declaration

[X] I have searched the issues tracker for this issue and there is none

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Seems to be already fixed.


refresh the timeline in the wall

This feature is part of the milestone target at https://groups.google.com/forum/#!msg/loklak/7azwyuslmTU/q9ueCSgwjZUJ
Because this feature changes the content of the top-tweet, it is based on the feature https://github.com/loklak/loklak_webclient/issues/32
The wall shall re-load itself. The refresh period shall be based on the number, given in the search result json search_metadata.period which is the average time between tweets in milliseconds. The refresh time shall be
20 seconds if period is > 30000
0.7 * period if period is <= 30000
5 seconds if period is < 7000
An update period below 5 is very rare and we don't want to put the scraping frequency on twitter too high.
The refresh method must compare the previous list with the new one and identify the number of tweets which are new. For each new tweet, there shall be an update animation:

replace the top tweet by the new one
add the previous top tweet to the timeline below, which shall be moved smoothly downwards
wait at least three seconds before doing this again with the next new tweet.

This feature is only for the wall view, right ? not the search view ?

right, this is only for the wall, not the search view.

This is working well, but the update does not shift the entries, it just reloads the whole page.
Can you make this with animations, like move the content down and place the first on top?

It's already done, it's weird that you can't see it...

There're already some animations. Let's close this!


Move Cask specs into brew tests.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[x] Have you successfully run brew tests with your changes locally?

Finally coverage is (seems to be, at least 😉 ) working.

@reitermarkus Nice work 👏


path,single-quoted-string style combination regressed

As #475 pointed out, when ./foo existed, : 'f'oo highlighted the 'f' in underline,fg=yellow and the oo in underline.  That regressed — bisected to 6835121eafa49899b396f5f85207fb1fe229bc1c.  It'd be nice to have it back ☺

In 6835121: typeset -a region_highlight=( '0 1 fg=green' '2 7 none' '2 7 underline' '2 5 fg=yellow' '2 5 fg=yellow' )
In the preceding revision: region_highlight=( '0 1 fg=green' '2 7 none' '2 5 fg=yellow' '2 7 underline' )

The fix is "simple":
diff --git a/highlighters/main/main-highlighter.zsh b/highlighters/main/main-highlighter.zsh
index c44b1c3..1c6768e 100644
--- a/highlighters/main/main-highlighter.zsh
+++ b/highlighters/main/main-highlighter.zsh
@@ -1314,7 +1314,7 @@ _zsh_highlight_main_highlighter_highlight_argument()
     fi
   fi

-  highlights=($(( start_pos + $1 - 1 )) $end_pos $base_style $highlights)
+  highlights+=($(( start_pos + $1 - 1 )) $end_pos $base_style)
   _zsh_highlight_main_add_many_region_highlights $highlights
 }

It fixes the issue, but breaks a number of tests because of ordering of expectations.
Also, I suspect it was written this way for a reason… Matthew?

The reason is later styles override earlier styles, so in the case of
ZSH_HIGHLIGHT_STYLES[path]=fg=red
ZSH_HIGHLIGHT_STYLES[single-quoted-argument]=fg=cyan

'f' should be cyan and oo should be red. With the above patch, the whole string is red.
I think this is a bug in ZLE.

Agreed. Thanks. So the fix'll be to the $region_highlight combiner in zle.
Labelled "good first issue", but this requires C work.


Add back collection of rustc cfg in json projects

This undoes the removal of the default cfg generation for json projects. This is related to #4840 and will have follow-ups to address customizing the targets even further.
CC @woody77

I didn't realize how simple of a change #4864 would be, so closing this so review can be focused there instead.


Website edits for Elizabeth and Kirsten

Hello! It all seems to have gone well except I can't seem to figure out how I messed up the formatting for the 'About' page. I have added myself and Kirsten's information in the same way as all the other profiles but it doesn't seem to render properly. I have tried fixing it several times with no luck!

Hey @ElizabethHoughton ! Thank you for your update! I've forked your repo and rendered the website here and it works perfectly. Does @JoeyBernhardt or @jennsunday spot a breaking point?


Failed to Download pytorch State Dict from website

I was trying to download the pytorch state dict for the powerful chipmunk-model https://bioimage.io/#/?id=10.5281%2Fzenodo.5847355 in order to run it on ilastik. clicking on the ilastik logo and then clicking the download pytorch state dict button doesn't work and gives the following error in the console.

Hello Josh,
Thanks for telling us! There is in fact an error with the button on downloading weights for Ilastik. We are taking care of it and will tell you as soon as this is solved.
Thank you!
Best,
Caterina

Hi again Josh,
This is now solved! Try it again and tell us if you have any other issue!
Thank you for pointing it out!
Best,
Caterina