[Firmware] Add timestamps to UnfusedData

We need to add hardware timestamps to UnfusedData. We may want to be generic on the timestamp type, so that we can represent when things are hardware timestamps vs software timestamps.
Fusion algos will need this, as several can use a dt to improve performance: https://github.com/jmagnuson/ahrs-rs#field_access

After some research into this, I now believe that reading timestamps from the fifo is not the right approach. Rather, we should sample the mcu timestamp at each new data ready interrupt, and then use that to track an exponential moving average of the estimated sample rate, in terms of MCU time (which is lower ppm/drift than the internal clock on most IMUs). We can use that sample rate to update the sample rate of the fusion algorithm, possibly on some fixed interval task.
In other words, the sample rate of the data stream should be tracked, rather than associating the deltaT or absolute time of each sample with the unfused data.


Update DNSPolicy default geo logic

What
Update the default geo logic for loadbalanced policy types to make the creation of the default geo endpoint dependant on the current cluster existing in the desired default geo. If the there is no match the endpoint should not be added to the endpoint list .
Why
Currently it is assumed that we will always want the default geo to be set to something, if no cluster(s) matches the current default geo it will automatically select one that does exist. This is used primarily for route53 to ensure that a dnsName is accessible from all locations around the world. With distributed dns however, individual clusters cant be sure what the default geo should really be and should not try and be smart during the selection of it.
How

Update the logic here to only set the default if it matches(remove the else) https://github.com/Kuadrant/kuadrant-operator/blob/main/controllers/dns_helper.go#L263-L271
Update this to only add the default endpoint if its not nil https://github.com/Kuadrant/kuadrant-operator/blob/main/controllers/dns_helper.go#L278-L285
Update tests, ensure to add a test that doesn't default geo
Update DNSPolicy docs to call out the behaviour
Set DNSPolicy default geo to required

@makslion as part of this pls ensure the DNSPolicy CRD has defaultGEO as required


[d3d11, d3d10, dxgi] Handle null ppvObject in QueryInterface.

When a null ppvObject is passed into a QueryInterface on any IUnknown, a E_POINTER should be returned as the result (and it should not crash.)
This matches native d3d11/d3d10/dxgi behaviour and the documentation found here https://docs.microsoft.com/en-us/windows/desktop/api/unknwn/nf-unknwn-iunknown-queryinterface(q_) for IUnknown.

A few d3d9 games rely on this, so I figured I'd check if the same was true for d3d11 and indeed it was.
May or may not fix anything but it's probably a good idea to match native behaviour (and also not crash :stuck_out_tongue:) -- and yes, it returns E_POINTER even if it doesn't have the interface. :frog:


How Can I Lock Cells in the excel

Hi,
I need to lock cell first row and first column of the excel.  Can I achieve this. Is there any way to lock the cell.

Any upadte on this issue?

any update on this issue?

ping

Has it been any update?

Any update on this?

did u know it ?

I need this feature, is it added yet?

Cell protection and other styling are part of our Pro builds


Multiplayer Enet error

Godot version:
3.1.2 Stable
OS/device including version:
Ubuntu 19
Issue description:

I have tried to create a server and run it on ubuntu, but i always get this
problem

Closing, as the error appears to be due to a network configuration issue per https://github.com/godotengine/godot/issues/35605#issuecomment-578833476.


could not find a supported CD ISO creation command (the supported commands are: xorriso, mkisofs, hdiutil, oscdimg)

What are the relate apps I need to install?
Please help me, Thank you!

It tells you in the output:

You need to have 1 of these tools in your PATH.
I usually install oscdimg which can be installed through the Windows ADK: https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install

I assume you figured it out since there has been no response 👍


Move OTEL logs and traces indexes to datetime nanos

Description
Move to native datetime field.
How was this PR tested?

[x] Updated unit tests and added new ones
[x] Tested manually with local Jaeger UI
[x] Wrote new integration test

@guilload as requested by matou on discord, we should set resource_attributes as fast. (I thought it was by default ://).
I'm wondering if we should put other json fields as fast too.


Implement Custom Loader

Is your feature request related to a problem? Please describe.
I was going through this amazing package which was easy to use but one problem was I couldn't implement a Custom Loader because this one is kind of very default and because I wanted to use one of the loaders of the SpinKit Package.
Describe the solution you'd like to offer.
I copied the code into my local project and added a new Widget variable and changed the block of code with the default loader in the Expanded Widget. And it worked perfectly.
Additional context

Sorry for being late @jnvee , this idea will be awesome, we'll add in our roadmap for sure, maybe we'll deliver it next month, if you want it faster, you can open a pull request and I'll merge it right away.

great I'll submit a PR in a few hours


support to Google Cloud Vision and tesseract fix

added support to Google Cloud Vision API (OCR),
fixed isssue with input_module=tesseract being decoded two times

This is now implemented. If you want some changes to it, feel free to open a new PR.


added defensive code just in case user wants to buy participation tok…

…ens but the current fee winoow hasn't been created
https://app.clubhouse.io/augur/story/14519/buying-pts-should-create-a-new-fee-window-if-necessary
adding defensive code, wasn't able to repro the issue on private change.

Pull Request Test Coverage Report for Build 1015

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.004%) to 66.684%

Totals

Change from base Build 1011:
-0.004%

Covered Lines:
3583

Relevant Lines:
4886

💛  - Coveralls


Weather Dark Sky, wrong unit for wind speed

Home Assistant release with the issue:

0.78.2
Last working Home Assistant release (if known):
N/A
Operating environment (Hass.io/Docker/Windows/etc.):

Hass.io
Component/platform:

https://www.home-assistant.io/components/weather.darksky
Description of problem:
Setting up weather darksky and looking at the value it is clear that the wind speed is reported in the wrong unit.
For metric it is reported in km/h even if forcing configuration option units to  si
We need to introduce wind speed unit in the weather or dark sky sensors
Looking at darksky web site it is clear how it should be:
<select class="units" tabindex="-1">
      <option value="us">˚F, mph</option>
      <option value="si">˚C, m/s</option>
      <option value="ca">˚C, km/h</option>
      <option value="uk2">˚C, mph</option>
    </select>

As a reference, sensor/darksky.py looks correct
SENSOR_TYPES = {

'wind_speed': ['Wind Speed', 'm/s', 'mph', 'km/h', 'mph', 'mph',
                   'mdi:weather-windy', ['currently', 'hourly', 'daily']],

}

    def update_unit_of_measurement(self):
        """Update units based on unit system."""
        unit_index = {
            'si': 1,
            'us': 2,
            'ca': 3,
            'uk': 4,
            'uk2': 5
        }.get(self.unit_system, 1)
        self._unit_of_measurement = SENSOR_TYPES[self.type][unit_index]

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
weather:
  - platform: darksky
    api_key: !secret darksky_api
    units: si

Traceback (if applicable):
N/A

Additional information:

See this other issue that I raised too. The problem here is that the units for the weather component don't seem to be stored anywhere accessible.

Same is happening for weather.buienradar component. #18558
Here also the unit for windspeed is shown as 'km/h' but should be 'm/s'. And here also the unit is correct in the separate Buienradar Sensor for weather.
Maybe the issue is on a higher level than these components (darksky, buienradar) are?

Is this still an issue?  Have you upgraded to the latest version?

Don’t know, not using it anymore...

Hi, yes it is still an issue. The value is correct but the unit is incorrect (should be miles and mph). configuaration.yaml:
  - platform: darksky
    api_key: !secret darksky_key
    units: uk2

For reference, when calling the API using postman:
https://api.darksky.net/forecast/<api_key>/<lat>,<lon>?units=uk2
{
    ...
    "currently": {
        "nearestStormDistance": 102,
        "windSpeed": 9.66,
        "visibility": 6.61,
    }.
    "flags": {
        "units": "uk2"
    },
}

https://api.darksky.net/forecast/<api_key>/<lat>,<lon>?units=ca
{
    ...
    "currently": {
        "nearestStormDistance": 164,
        "windSpeed": 15.55,
        "visibility": 10.59,
    }.
    "flags": {
        "units": "ca"
    },
}

Also for reference, here is OpenWeatherMap which was not configured for units (I think it's hard-coded to metric):

This is still an issue.
It has been for a couple of years actually. (Yes it has been reported before)
To clarify,
Let say the actual wind speed is 3.2 m/s (reported by Dark Sky with units: si)
Currently, Homeassistant wrongly displays it as 3.2 Km/h
For each 'units' parameter in configuration.yaml under various weather platform, corresponding weather services report appropriately converted values per requests.
For Dark Sky, units:si means reporting wind speed in meter for second or m/s.
Receiving this data, Homeassistant displays it as Km/h WITHOUT any conversion!
(Of course, we made sure all HA user-side configurations are correct, Dark Sky is sending correct value, etc)
It is just a bug which has not been fixed for years, probably because some people think it is just a discussion of partial preference of units.
It is not.
Even if Homeassistant is designed to display wind speed only in Km/h or mph, then it needs to do a mathematical conversion first. Not just swap units text string.


Avoid compilation warnings about potentially-undefined functions.

The byte compiler isn’t smart enough to figure out that these functions are
indeed defined in this code branch.

Sorry, forgot to merge.


Unable to close files with ctrl-w in normal mode with vscodevim

VSCode Version: Code 1.17.0 (be377c0faf7574a59f84940f593a6849f12e4de7, 2017-10-04T23:33:45.303Z)
OS Version: Linux x64 4.4.0-96-generic
Extensions:

Extension
Author (truncated)
Version

rust
rus
0.3.1

vim
vsc
0.10.1

Steps to Reproduce:

Open a file
ctrl-w

Note: I was in normal mode while testing this. If I were in insert mode this obviously would have a different result.

Reproduces without extensions: No (caused by vscodevim)

Please file issues against VSCodeVim.


Assertion `cur_target >= 0 && cur_target < n_classes' failed

Hi,
Thank you for your project. It's helpful. I'm tried to launch your train.py script on a new dataset and i have encounter the following error

File "src/train.py", line 60, in
metric_list=metric_list, verbose=True)
File "/workspace/src/unet/model.py", line 186, in fit_dataset
train_logs = self.fit_epoch(dataset, n_batch=n_batch, shuffle=shuffle)
File "/workspace/src/unet/model.py", line 99, in fit_epoch
training_loss = self.loss(y_out, y_batch)
File "/usr/local/lib/python3.6/site-packages/torch/nn/modules/module.py", line 493, in call
result = self.forward(*input, **kwargs)
File "/workspace/src/unet/metrics.py", line 25, in forward
ignore_index=self.ignore_index)
File "/usr/local/lib/python3.6/site-packages/torch/nn/functional.py", line 2056, in cross_entropy
return nll_loss(log_softmax(input, 1), target, weight, None, ignore_index, None, reduction)
File "/usr/local/lib/python3.6/site-packages/torch/nn/functional.py", line 1873, in nll_loss
ret = torch._C._nn.nll_loss2d(input, target, weight, _Reduction.get_enum(reduction), ignore_index)
RuntimeError: Assertion `cur_target >= 0 && cur_target < n_classes' failed.  at /pytorch/aten/src/THNN/generic/SpatialClassNLLCriterion.c:109

As i search in the internet for the cause, i find that maybe it's the dimensions of the output layer. The problem is thta i did not change anything and i used a similar dataset
Thank you for your help

Hi! Although I don't have your data with me, I am pretty confident that you didn't specify --out_channels correctly. From the exception, it follows that the cross-entropy loss function expects less classes than there are in your labeled images. Let me know the results!

Hi,
Thank you for your project. It's helpful. I'm tried to launch your train.py script on a new dataset and i have encounter the following error

File "src/train.py", line 60, in
metric_list=metric_list, verbose=True)
File "/workspace/src/unet/model.py", line 186, in fit_dataset
train_logs = self.fit_epoch(dataset, n_batch=n_batch, shuffle=shuffle)
File "/workspace/src/unet/model.py", line 99, in fit_epoch
training_loss = self.loss(y_out, y_batch)
File "/usr/local/lib/python3.6/site-packages/torch/nn/modules/module.py", line 493, in call
result = self.forward(*input, **kwargs)
File "/workspace/src/unet/metrics.py", line 25, in forward
ignore_index=self.ignore_index)
File "/usr/local/lib/python3.6/site-packages/torch/nn/functional.py", line 2056, in cross_entropy
return nll_loss(log_softmax(input, 1), target, weight, None, ignore_index, None, reduction)
File "/usr/local/lib/python3.6/site-packages/torch/nn/functional.py", line 1873, in nll_loss
ret = torch._C._nn.nll_loss2d(input, target, weight, _Reduction.get_enum(reduction), ignore_index)
RuntimeError: Assertion `cur_target >= 0 && cur_target < n_classes' failed.  at /pytorch/aten/src/THNN/generic/SpatialClassNLLCriterion.c:109

As i search in the internet for the cause, i find that maybe it's the dimensions of the output layer. The problem is thta i did not change anything and i used a similar dataset
Thank you for your help

Have you solved this problem, can you tell me a way, I also encountered the same problem

Hi,
Thank you for your project. It's helpful. I'm tried to launch your train.py script on a new dataset and i have encounter the following error

File "src/train.py", line 60, in
metric_list=metric_list, verbose=True)
File "/workspace/src/unet/model.py", line 186, in fit_dataset
train_logs = self.fit_epoch(dataset, n_batch=n_batch, shuffle=shuffle)
File "/workspace/src/unet/model.py", line 99, in fit_epoch
training_loss = self.loss(y_out, y_batch)
File "/usr/local/lib/python3.6/site-packages/torch/nn/modules/module.py", line 493, in call
result = self.forward(*input, **kwargs)
File "/workspace/src/unet/metrics.py", line 25, in forward
ignore_index=self.ignore_index)
File "/usr/local/lib/python3.6/site-packages/torch/nn/functional.py", line 2056, in cross_entropy
return nll_loss(log_softmax(input, 1), target, weight, None, ignore_index, None, reduction)
File "/usr/local/lib/python3.6/site-packages/torch/nn/functional.py", line 1873, in nll_loss
ret = torch._C._nn.nll_loss2d(input, target, weight, _Reduction.get_enum(reduction), ignore_index)
RuntimeError: Assertion `cur_target >= 0 && cur_target < n_classes' failed.  at /pytorch/aten/src/THNN/generic/SpatialClassNLLCriterion.c:109

As i search in the internet for the cause, i find that maybe it's the dimensions of the output layer. The problem is thta i did not change anything and i used a similar dataset
Thank you for your help

Have you solved this problem, can you tell me a way, I also encountered the same problem


Delete gradle.properties

This file is misleading and is not used. The version of the plugin is derived from -Dopensearch.version. That mechanism prevents a conflict between the version in gradle.properties and the OpenSearch version passed in.
CheckList:
[x] Commits are signed per the DCO using --signoff
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #262 (f74df60) into main (ea7d526) will increase coverage by 0.05%.
The diff coverage is n/a.

:exclamation: Current head f74df60 differs from pull request most recent head d2c9a85. Consider uploading reports for the commit d2c9a85 to get more accurate results

@@             Coverage Diff              @@
##               main     #262      +/-   ##
============================================
+ Coverage     78.53%   78.58%   +0.05%
+ Complexity      218      217       -1
============================================
  Files           173      173
  Lines          6968     6968
  Branches        915      915
============================================
+ Hits           5472     5476       +4
+ Misses         1007     1005       -2
+ Partials        489      487       -2

Impacted Files
Coverage Δ

...ing/destination/client/DestinationEmailClient.java
72.50% <0.00%> (-5.00%)
:arrow_down:

.../kotlin/org/opensearch/alerting/core/JobSweeper.kt
71.50% <0.00%> (-0.50%)
:arrow_down:

...ain/kotlin/org/opensearch/alerting/AlertService.kt
78.53% <0.00%> (-0.49%)
:arrow_down:

...ing/model/destination/DestinationContextFactory.kt
66.66% <0.00%> (ø)

...in/kotlin/org/opensearch/alerting/MonitorRunner.kt
72.05% <0.00%> (+0.67%)
:arrow_up:

...arch/alerting/model/action/ActionExecutionScope.kt
69.84% <0.00%> (+6.34%)
:arrow_up:

...rch/alerting/model/action/ActionExecutionPolicy.kt
87.50% <0.00%> (+8.33%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ea7d526...d2c9a85. Read the comment docs.


hello of homepage in spanish is missing subtitles

'hello' on spanish home site links to http://hello.p5js.org/
video displayed is english without spanish subtitles

the same for 'interactuar' link on home site

added to #8


removed nomacs.rb

Seems like they aren’t providing OS X compiled binaries anymore.

ACK. I had looked into this a little bit, wasn't able to find an osx binary

Also tried to find the binaries when the issue firstly appeared. At the moment, it's only available via MacPorts, so this one could be removed without any doubts.


Add resource update error handling

Add some try expectations which handles a missing or corrupted update from the resource provider. Currently implemented in OTC adapter

Codecov Report

Merging #6 into master will decrease coverage by 1.72%.
The diff coverage is 17.24%.

@@            Coverage Diff             @@
##           master       #6      +/-   ##
==========================================
- Coverage   60.66%   58.94%   -1.73%
==========================================
  Files          26       26
  Lines         600      626      +26
==========================================
+ Hits          364      369       +5
- Misses        236      257      +21

Impacted Files
Coverage Δ

tardis/exceptions/tardisexceptions.py
76.47% <100%> (+3.13%)
:arrow_up:

tardis/resources/dronestates.py
30.83% <4.54%> (-4.82%)
:arrow_down:

tardis/adapter/otc.py
39.7% <40%> (+0.02%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9ff4fe4...d9ba085. Read the comment docs.


Add Vulkan Video support

Hi, I am working on this. It is 100% work-in-progress still. I am testing my changes through a RTX2060 + the proprietary NVIDIA blob on Linux and comparing the results against GStreamer's vkh264dec.

[ ] Update documentation to reflect any user-facing changes - in this repository.

[ ] Make sure that the changes are covered by unit-tests.

[ ] Run cargo fmt on the changes.

[ ] Please put changelog entries in the description of this Pull Request
if knowledge of this change could be valuable to users. No need to put the
entries to the changelog directly, they will be transferred to the changelog
file by maintainers right after the Pull Request merge.
Please remove any items from the template below that are not applicable.

[ ] Describe in common words what is the purpose of this change, related
Github Issues, and highlight important implementation aspects.

Changelog:
### Public dependency updates
- [some_crate](https://crates.io/crates/some_crate) 1.0

### Breaking changes
Changes to `Foo`:
- Renamed to `Bar`.

### Additions
- Support for the `khr_foobar` extension.

### Bugs fixed
- `bar` panics when calling `foo`.

Hi @Rua,
Yeah I will change the names to match better then.
If you want to, I can leave encoding out of this completely for now.

@Rua How do I get these?
#define VK_STD_VULKAN_VIDEO_CODEC_H264_DECODE_SPEC_VERSION VK_STD_VULKAN_VIDEO_CODEC_H264_DECODE_API_VERSION_1_0_0

#define VK_STD_VULKAN_VIDEO_CODEC_H264_DECODE_EXTENSION_NAME "VK_STD_vulkan_video_codec_h264_decode"

Is there anything I can use in order to index into physical_device.extension_properties() ?

Vulkano doesn't expose those, but Ash (used by Vulkano) does. What do you need it for, though?

@Rua
It is used to create the video session:
    let video_session_create_info = VideoSessionCreateInfo {
        queue_family_index: video_queue_family_index,
        video_profile: profile_info,
        picture_format: format.format,
        max_coded_extent: video_caps.max_coded_extent,
        reference_picture_format: format.format,
        max_dpb_slots: video_caps.max_dpb_slots,
        max_active_reference_pictures: video_caps.max_active_reference_pictures,
        std_header_version: video_caps.std_header_version,   <-----------------------
        ..Default::default()
    };

So far I am getting away by reusing the one returned in VideoCapabilities, but I wonder what if someone wants to specify a different one.
Also it's currently not possible to use vulkan_bitflags! on e.g.:
https://github.com/ash-rs/ash/blob/3f5b96b3638a9ff341584e82188c3ba3aa5cb996/ash/src/vk/native.rs#L94
This macro apparently expects the path to be available in ash::vk, but native is not reexported: https://github.com/ash-rs/ash/blob/3f5b96b3638a9ff341584e82188c3ba3aa5cb996/ash/src/vk.rs#L31

According to VUID-VkVideoSessionCreateInfoKHR-pStdHeaderVersion-07190, the extension name must match the one returned in the capabilities, and according to VUID-VkVideoSessionCreateInfoKHR-pStdHeaderVersion-07191, the spec version must not be greater than the one in the capabilities.

What do you think of making video::h264 and video::h265 submodules, to keep the specifics for these encodings separate from the generic stuff?
Regarding those constants, I'm not really sure what they are for. They don't seem to be defined in the Vulkan spec, and they're not defined in the vk.xml file either. It looks like they are actually constants defined to the video encoding scheme itself, and not by the Vulkan standard?

@Rua
If you want me to I can split the codecs outside of the video module, that's fine.
Regarding the constants in native, they match the codec specifications, yes. In fact everything from the codec specs seem to be defined in ash::native instead of ash::vk. They're used to pass metadata from the codec bitstream into the driver so that the driver can program the hardware encoders/decoders in the GPU.

Are those constants something that the Vulkano user would be expected to use directly? If so, then they could be re-exported in Vulkano.


Syslog and Loggly plugins

Syslog Plugin - send logs to local system log
Loggly Plugin - send logs to Loggly over UDP

why not open two separate PR?

I started with aim to get loggly working but it turn out that we can also another plugin syslog logging to system log. so did both in same branch.

syslog plugin will work with both any 3rd party supporting syslog format like Loggy and SymoLogic

Please reopen against next as explained in #622.

Oh sorry totally forget about that


trollop dependency deprecated for optimist

trollop gem dependency deprecated in favor of optimist.
Updating trollop
!    The 'trollop' gem has been deprecated and has been replaced by 'optimist'.
!    See: https://rubygems.org/gems/optimist
!    And: https://github.com/ManageIQ/optimist

% gem uninstall trollop

You have requested to uninstall the gem:
  trollop-2.1.3

lolcat-99.9.11 depends on trollop (~> 2.1.2)

Hmm, I can't reproduce your cited warning message.
~ $ gem uninstall trollop lolcat
Gem 'trollop' is not installed
Gem 'lolcat' is not installed
~ $ gem install lolcat
Fetching: trollop-2.1.3.gem (100%)
Successfully installed trollop-2.1.3
Fetching: lolcat-99.9.11.gem (100%)
Successfully installed lolcat-99.9.11
2 gems installed

When did you see the message, on your first gem install lolcat?

Now do:
% gem update
Updating installed gems
Updating trollop
Fetching: trollop-2.9.9.gem (100%)
!    The 'trollop' gem has been deprecated and has been replaced by 'optimist'.
!    See: https://rubygems.org/gems/optimist
!    And: https://github.com/ManageIQ/optimist
Successfully installed trollop-2.9.9
Gems updated: trollop

Ah, interesting, thanks for the heads up! 🤔
The warning is harmless and can be safely ignored.
The dependency in lolcat is pinned to ~> 2.1.2, it never actually uses v2.9.9.
And to prevent the warning from sneaking in at install time I'll now pin trollop to = v2.1.3.
We'll eventually switch to optimist, but I'm not sure
when I'll get around to it (PRs welcome :) ).


fix for the SIL

Bug fix to the Uintah reader for SILs. This bug fix can be rolled into the 3.1RC

Something is messed up in the branch rather than wasting time I created a new one with a request from it: https://github.com/visit-dav/visit/pull/4233


Error when separate_b0_and_dwi is called from CLI

Assume that only .nii file exists and .bval is missing, then I get following error:
$ source /usr/local/lib/bash_basics/bash_basic_functions.sh
$ separate_b0_and_dwi dMRI_AP.nii.gz
File dMRI_AP.bval does not exist.
/usr/local/lib/bash_basics/bash_basic_functions.sh: \u0159ádek 578: kill: 2449110#: argumenty musí být proces nebo identifikátor úlohy

The error is related to trap_exit function. Possible fix https://github.com/valosekj/bash_basics/commit/b6e9ab01f3d3ba3d05e8dfe6c25aa1f19713e378


Handle edge case of string macro functions

The macro string functions don't necessarily need any string markup to be considered a string. This new construction handles identifying the content within a string function as a string.

Thank you for contributing @cedporter!


[BUG] Response formatting to include quotation marks

Bug description:
Currently when adding responses through the user interface, the domain.yml doesn't wrap the response text in quotation marks.
How it is:
utter_example:
- text: Hello
Expected behavior:
How it should be:
utter_example:
- text: "Hello"
Please modify the logic responsible for writing the responses into domain.yml so that all response texts are enclosed in double quotes.
Screenshots:

Added mapper function to wrap all text: contents in domain into quotations if absent.
Datamapper PR
Training module


Write ATS for TG requirement 44

For each dataset available the OpenSearch description shall contain a "Query" element that has a "role" attribute with the value "example" and "spatial_dataset_identifier_code" and "spatial_dataset_identifier_namespace" attributes together containing unique spatial dataset identifier. The value of the "crs" and "language" attributes shall be set to the values considered as the default ones by the service provider.

Are the "crs" and "language" attributes mandatory? This is not specifically mandated in the requirement, but would make sense.


Accept multiple filters.

Filter should now optionally accept multiple filters as an array of values.

Codecov Report

Merging #327 into develop will increase coverage by 0.01%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop     #327      +/-   ##
===========================================
+ Coverage    92.81%   92.82%   +0.01%
===========================================
  Files           71       71
  Lines         2560     2565       +5
  Branches       229      231       +2
===========================================
+ Hits          2376     2381       +5
  Misses         151      151
  Partials        33       33

Impacted Files
Coverage Δ

datahub/search/elasticsearch.py
96.47% <100%> (+0.17%)
:arrow_up:

datahub/company/serializers.py
97.84% <0%> (+0.01%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3df7d65...8be02ae. Read the comment docs.


CSidebarBrand wrappedInLink should open with target="_blank"

Hi,
We'd like to link to main site from the admin sidebar brand logo.
However, clicking on it navigates away from the admin, since there's no target="_blank"
Would you please make it open in a new window, or make wrappedInLink an object, so we can pass href and target attributes?
https://github.com/coreui/coreui-vue/blob/v3-alpha/src/components/sidebar/CSidebarBrand.vue
Thanks!

Hi!
It is an object, you can pass all of CLink props.


Compatibility issue with latest Google Drive API

Hi Miro,
I want to use your example with newer version of API, But I found that there are so many changes in the API core schema. So any suggestion, what should I do to make File Uploading with Newer Version of API.
Thank you

Hi!
I haven't orientated myself in any newer version of the API, so I cannot give you a good answer on this. If you do decide to try to use my example with the newer API, you can put up a PR for me for a working version of it!


time to upgrade to latest bcc-devel pkg?

Is your feature request related to a problem? Please describe.
Current bcc-devel pkg used by Kepler is v0.19.
There are quite changes in latest iovisor bcc since v0.19.
Is it time to upgrade to latest bcc-devel pkg
Describe the solution you'd like
Upgrade the kepler base image

maybe you cut a release like 0.1 or 0.01 of kepler with current bcc then
continue to update main with latest bcc so folks won't be affected if they need older one somehow ?

Is there any kernel requirement to upgrade the bcc?
If not, this should be fine!

@jichenjc there is a release-0.3 branch.
@marceloamaral newer bcc supports newer kernels per release page

Here is the bcc release info https://github.com/iovisor/bcc/releases

@rootfs with a quick look to the releases minutes I did not see any possible conflict...
We can try, I should be fine


solution: use icons2 for address

Codecov Report

Merging #18 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #18   +/-   ##
=======================================
  Coverage   91.39%   91.39%
=======================================
  Files          83       83
  Lines         279      279
  Branches       35       35
=======================================
  Hits          255      255
  Misses         14       14
  Partials       10       10

Impacted Files
Coverage Δ

src/components/Address/Address.js
71.42% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a34ebd0...a4a19c8. Read the comment docs.


[bug] Is running a cloud function equivalent to publishing?

Search before asking

[X] I had searched in the issues and found no similar issues.

Environment
https://laf.dev
What happened
Currently, I have modified the cloud function and clicked the run button to find that it has been published
How to reproduce
1
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Not really.


Revamp CUDA support in BLT

The CMake code in SetupCUDA.cmake seems to be relying on both find_package(CUDA), which was deprecated since CMake 3.10, and the modern first-class CUDA language support in CMake.
Using both is confusing.
This part can be refined and cleaned up quite a bit and we should consider leveraging FindCUDAToolkit(https://cmake.org/cmake/help/latest/module/FindCUDAToolkit.html#) that is available with newer versions of CMake as applicable.

Just to add to this issue so it's not forgotten.  At the time this line (https://github.com/LLNL/blt/blob/0d71af8d3ac0ea1abeb8983a201013753a857a35/cmake/SetupCompilerOptions.cmake#L268) was implemented, CMake did not support C++17 or higher when compiling CUDA.  Newer versions of CMake now support all the way up to C++20.  This check should be improved to check which CMake version you are running and error out only if that version doesn't support higher C++ standards.

For versions of CMake where FindCUDAToolkit is not available, https://gitlab.kitware.com/cmake/cmake/-/issues/17816 describes how similar functionality can be implemented without relying on FindCUDA.cmake.

Hello! Has there been any developments towards replacing the following with find_package(CUDAToolkit REQUIRED)?
https://github.com/LLNL/blt/blob/9cfe8aedb12c17da04b4df1859ec5e802030795c/cmake/thirdparty/BLTSetupCUDA.cmake#L101
I've been seeing warnings like the following with newer CMake versions (e.g. 3.29.2):
CMake Warning (dev) at Umpire/install/lib/cmake/camp/thirdparty/BLTSetupCUDA.cmake:101 (find_package):
  Policy CMP0146 is not set: The FindCUDA module is removed.  Run "cmake
  --help-policy CMP0146" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.


diffoscope: 282 -> 283

Changes: https://diffoscope.org/news/diffoscope-283-released/

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 354620

x86_64-linux

:white_check_mark: 7 packages built:

diffoscope
diffoscope.dist
diffoscope.man
diffoscopeMinimal
diffoscopeMinimal.dist
diffoscopeMinimal.man
garble


Initial integration of shared cluster chart

Towards https://github.com/giantswarm/roadmap/issues/3124
I templated the chart out from main and then from this branch and compared the two directory structures with diff:
 ➜  diff -ur /tmp/vsphere/main/cluster-vsphere/templates/ /tmp/vsphere/feature/cluster-vsphere/templates/
 ➜

I then removed .global.nodePools from the values files on my branch and templated the branch out again to test usage of the defaults added in this PR (see notes below code block). Note that this doesn't include the Cluster resource - that is further down:
 ➜  diff -ur /tmp/vsphere/pre/cluster-vsphere/templates/ /tmp/vsphere/defaults/cluster-vsphere/templates/
diff -ur /tmp/vsphere/pre/cluster-vsphere/templates/kubeadmconfigtemplate.yaml /tmp/vsphere/defaults/cluster-vsphere/templates/kubeadmconfigtemplate.yaml
--- /tmp/vsphere/pre/cluster-vsphere/templates/kubeadmconfigtemplate.yaml	2024-07-19 12:11:29.769101218 +0100
+++ /tmp/vsphere/defaults/cluster-vsphere/templates/kubeadmconfigtemplate.yaml	2024-07-19 12:15:31.997789637 +0100
@@ -3,7 +3,7 @@
 apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
 kind: KubeadmConfigTemplate
 metadata:
-  name: test-worker-c275c4fe
+  name: test-def00-fa98c372
   namespace: default
   labels:
     app: "cluster-vsphere"
@@ -119,7 +119,7 @@
             eviction-soft-grace-period: "memory.available=5s"
             anonymous-auth: "true"

-            node-labels: "giantswarm.io/node-pool=worker"
+            node-labels: "giantswarm.io/node-pool=def00"
       files:
         - path: /etc/ssh/trusted-user-ca-keys.pem
           permissions: "0600"
diff -ur /tmp/vsphere/pre/cluster-vsphere/templates/machinedeployment.yaml /tmp/vsphere/defaults/cluster-vsphere/templates/machinedeployment.yaml
--- /tmp/vsphere/pre/cluster-vsphere/templates/machinedeployment.yaml	2024-07-19 12:11:29.769101218 +0100
+++ /tmp/vsphere/defaults/cluster-vsphere/templates/machinedeployment.yaml	2024-07-19 12:15:31.997789637 +0100
@@ -3,7 +3,7 @@
 apiVersion: cluster.x-k8s.io/v1beta1
 kind: MachineDeployment
 metadata:
-  name: test-worker
+  name: test-def00
   namespace: default
   labels:
     app: "cluster-vsphere"
@@ -35,12 +35,12 @@
         configRef:
           apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
           kind: KubeadmConfigTemplate
-          name: test-worker-c275c4fe
+          name: test-def00-fa98c372
           namespace: default
       clusterName: test
       infrastructureRef:
         apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
         kind: VSphereMachineTemplate
-        name: test-worker-81f02996
+        name: test-def00-1f2b4d56
         namespace: default
       version: v1.27.14
diff -ur /tmp/vsphere/pre/cluster-vsphere/templates/vspheremachinetemplate.yaml /tmp/vsphere/defaults/cluster-vsphere/templates/vspheremachinetemplate.yaml
--- /tmp/vsphere/pre/cluster-vsphere/templates/vspheremachinetemplate.yaml	2024-07-19 12:11:29.769101218 +0100
+++ /tmp/vsphere/defaults/cluster-vsphere/templates/vspheremachinetemplate.yaml	2024-07-19 12:15:31.997789637 +0100
@@ -36,7 +36,7 @@
 apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
 kind: VSphereMachineTemplate
 metadata:
-  name: test-worker-81f02996
+  name: test-def00-1f2b4d56
   namespace: default
   labels:
     app: "cluster-vsphere"
@@ -55,12 +55,8 @@
       server: https://foo.example.com
       thumbprint: F7:CF:F9:E5:99:39:FF:C1:D7:14:F1:3F:8A:42:21:95:3B:A1:6E:16
       cloneMode: linkedClone
-      diskGiB: 25
-      memoryMiB: 8192
-      network:
-        devices:
-        - dhcp4: true
-          networkName: grasshopper-capv
-      numCPUs: 2
-      resourcePool: grasshopper
+      memoryMiB: 16896
+      network: {}
+      numCPUs: 6
+      resourcePool: '*/Resources'
       template: flatcar-stable-3815.2.2-kube-v1.27.14-gs

Notes on the diff:

the nodepool names change from worker to def00 to align with other provider nodePool naming.
the worker vspheremachinetemplate spec changes a little because the defaults are different to the values which are used in main at the moment. The templated resource is still a valid CR.
changing the values in cluster.providerIntegration.workers.defaultNodePools.def00 results in an updated mtRevisionHash so the hashing function still works correctly following the removal of nodeClasses` (not shown in the diff but tested locally).

Cluster
Cluster resource rendered from main:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: test
  namespace: default
  annotations:
    cluster.giantswarm.io/description: "test cluster"
  labels:
    cluster-apps-operator.giantswarm.io/watching: ""
    giantswarm.io/service-priority: "highest"
    app: "cluster-vsphere"
    app.kubernetes.io/managed-by: "Helm"
    cluster.x-k8s.io/cluster-name: "test"
    giantswarm.io/cluster: "test"
    giantswarm.io/organization: "giantswarm"
    application.giantswarm.io/team: "rocket"
    app.kubernetes.io/version: "0.56.1"
    helm.sh/chart: "cluster-vsphere-0.56.1"
    policy.giantswarm.io/psp-status: disabled
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - <IP_ADDRESS>/16
    services:
      cidrBlocks:
        - <IP_ADDRESS>/16
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: test
    namespace: default
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: VSphereCluster
    name: test
    namespace: default

Cluster resource rendered from this branch:
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  annotations:
    cluster.giantswarm.io/description: "test cluster"
  labels:
    cluster-apps-operator.giantswarm.io/watching: ""
    # deprecated: "app: cluster-vsphere" label is deprecated and it will be removed after upgrading
    # to Kubernetes 1.25. We still need it here because existing ClusterResourceSet selectors
    # need this label on the Cluster resource.
    app: "cluster-vsphere"
    app.kubernetes.io/name: "cluster"
    app.kubernetes.io/version: "0.35.0"
    app.kubernetes.io/part-of: "cluster-vsphere"
    app.kubernetes.io/instance: "test"
    app.kubernetes.io/managed-by: "Helm"
    helm.sh/chart: "cluster-0.35.0"
    application.giantswarm.io/team: "turtles"
    giantswarm.io/cluster: "test"
    giantswarm.io/organization: "giantswarm"
    giantswarm.io/service-priority: highest
    cluster.x-k8s.io/cluster-name: "test"
    cluster.x-k8s.io/watch-filter: capi
    policy.giantswarm.io/psp-status: disabled
  name: test
  namespace: org-t-eu1qa2b7j76eccn72v
spec:
  clusterNetwork:
    apiServerPort: 6443
    services:
      cidrBlocks:
        - <IP_ADDRESS>/16
    pods:
      cidrBlocks:
        - <IP_ADDRESS>/16
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: test
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: VSphereCluster
    name: test

E2E tests

standard: https://tekton.ci.giantswarm.io/#/namespaces/tekton-pipelines/pipelineruns/pr-cluster-vsphere-238-cluster-test-suites6g7fg?pipelineTask=run-tests&taskRunName=pr-cluster-vsphere-238-cluster-test-suites6g7fg-run-tests-1&step=run-tests
upgrade:
on-capv: https://github.com/giantswarm/cluster-vsphere/pull/238#issuecomment-2242990116

/run cluster-test-suites

the cmp-helm-rendering check will fail because the CI values files have been updated with the name value (which isn't allowed in the main branch values schema.

nope, forgot to update the e2e values. all tests will fail until the linked PR :point_up: is merged

nice

/run cluster-test-suites

and of course the upgrade test will fail to deploy a cluster because of the added name value:
status:
  appVersion: ""
  release:
    lastDeployed: null
    reason: |
      values don't meet the specifications of the schema(s) in the following chart(s):
      cluster-vsphere:
      - global.metadata: Additional property name is not allowed
    status: values-schema-violation

@glitchcrab I checked the deletion issue. There was a problem with the cleaner operator. Restarting the pod solved the issue. I created a ticket for that to our board.


Not an Issue just a feature req

When you are in a pair, you have the bar with the info in front of the editor, could you relocate it or hide it. It's in the way of the first few lines of code. :)

Ah! You mean the bar saying 'Your pair buddy has joined the session' etc.? If you click on it and press escape, does it go? Maybe I should add a hotkey to remove these views - atm it's just escape (but that's only if it's focussed on)

Ahh, I will try that. Maybe have some text at the bottom saying to close this: "click it and hit esc" :)

or maybe a little x to close it :)

Thanks for the request! :)

1.1.5 has this feature :)

Awesome!


Scene Activation CC (43) support with MQTT Discovery

Version
Build/Run method:
[ X] Docker
[ ] Git Clone + npm install + npm run build + npm start
[ ] Pkg
Z-Wave JS UI version: 9.8.2
Z-Wave JS version: 12.4.3
Describe the bug
I have a ZME_RC2  remote controller. It was working well until I upgrade to the last version (I don't know which version I was using before, one from the end of 2023),
After troubleshooting, I ve found that the change states are not published to "right" mqtt topic.
In home assistant section, i see hass device json with command topic like :
"command_topic": "zwave/27/112/0/10/set",
But when I check with mqtt explorer, when the device change, the value is set in "zwave/27/43/0/"
Here is debug information when I press a key on remote controller
2024-01-31 20:56:38.707 DEBUG MQTT: Publishing to zwave/27/lastActive: { time:<PHONE_NUMBER>707, value:<PHONE_NUMBER>706 } with options { qos: 1, retain: false }
2024-01-31 20:56:38.722 DEBUG MQTT: Publishing to zwave/27/43/0/sceneId: {
  time:<PHONE_NUMBER>721,
  value: 72,
  nodeName: 'Telecommande',
  nodeLocation: ''
} with options { qos: 1, retain: false }
2024-01-31 20:56:38.724 INFO Z-WAVE: [Node 027] Value notification: 43-0-sceneId 72
2024-01-31 20:56:38.729 DEBUG MQTT: Publishing to zwave/27/43/0/dimmingDuration: {
  time:<PHONE_NUMBER>726,
  value: Duration { unit: 'default', _value: 0, [value]: [Getter/Setter] },
  nodeName: 'Telecommande',
  nodeLocation: ''
} with options { qos: 1, retain: false }
2024-01-31 20:56:38.731 INFO Z-WAVE: [Node 027] Value updated: 43-0-dimmingDuration default => default
2024-01-31 20:56:38.959 DEBUG MQTT: Publishing to zwave/27/lastActive: { time:<PHONE_NUMBER>959, value:<PHONE_NUMBER>706 } with options { qos: 1, retain: false }
2024-01-31 20:56:39.724 DEBUG MQTT: Publishing to zwave/27/43/0/sceneId: {
  time:<PHONE_NUMBER>724,
  value: undefined,
  nodeName: 'Telecommande',
  nodeLocation: ''
} with options { qos: 1, retain: false }

Here is the full Hass Device Json
{
  "type": "number",
  "object_id": "config_number_16",
  "discovery_payload": {
    "value_template": "{{ value_json.value }}",
    "command_topic": "zwave/27/112/0/16/set",
    "enabled_by_default": false,
    "entity_category": "config",
    "min": 0,
    "max": 5,
    "state_topic": "zwave/27/112/0/16",
    "availability": [
      {
        "payload_available": "true",
        "payload_not_available": "false",
        "topic": "zwave/27/status",
        "value_template": "{{'true' if value_json.value else 'false'}}"
      },
      {
        "topic": "zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status",
        "value_template": "{{'online' if value_json.value else 'offline'}}"
      },
      {
        "payload_available": "true",
        "payload_not_available": "false",
        "topic": "zwave/driver/status"
      }
    ],
    "availability_mode": "all",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xc7bf3f61_node27"
      ],
      "manufacturer": "Z-Wave.Me",
      "model": "Z-Wave Remote Control+ (ZME_RC2)",
      "name": "Telecommande",
      "sw_version": "1.1"
    },
    "name": "Telecommande_config_number_16",
    "unique_id": "zwavejs2mqtt_0xc7bf3f61_27-112-0-16"
  },
  "discoveryTopic": "number/Telecommande/config_number_16/config",
  "values": [
    "112-0-16"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "number_config_number_16"
}

Tell me if I have to send other informations.
Thank you for your help

@barrydouu there is no support for Scene Activation CC (43) with MQTT discovery, I'm sorry. The zwave/27/112/0/10/set refers to a configuration value and that's not what you are looking for

So I just revert to 9.6.2
Hass Device Json is really different :
{   "type": "sensor",   "object_id": "scene_state_sceneid",   "discovery_payload": {     "state_topic": "zwave/27/43/0/sceneId",     "value_template": "{{ value_json.value | default('') }}",     "json_attributes_topic": "zwave/27/43/0/sceneId",     "device": {       "identifiers": [         "zwavejs2mqtt_0xc7bf3f61_node27"       ],       "manufacturer": "Z-Wave.Me",       "model": "Z-Wave Remote Control+ (ZME_RC2)",       "name": "Telecommande",       "sw_version": "1.1"     },     "name": "Telecommande_scene_state_sceneid",     "unique_id": "zwavejs2mqtt_0xc7bf3f61_27-43-0-sceneId"   },   "discoveryTopic": "sensor/Telecommande/scene_state_sceneid/config",   "values": [     "43-0-sceneId"   ],   "persistent": false,   "ignoreDiscovery": false,   "id": "sensor_scene_state_sceneid" }
And the list of "subdevice" is different. With 9.6.2, I have only 4
battery_level, battery_islow, scene_state_sceneid, scene_state_dimmingduration
With last version, I have a lot more. At least one for each "button" of the remote controller (ex : config_number_10, onfig_number_11, ...,  config_number_16)
Hope it could help

That PR has been from @ccutrer, I would be curious to know the reason why he removed that and added the state class, maybe he had a reason

For the Scene Activation CC, it's not that it was removed on purpose, it's that writable values are no longer published (as read-only sensors!), since that doesn't make any sense. If I don't hear any different, I'll
It seems to me that a writable-only value should be exposed as a select (without a state topic), a number (without a state topic), a series of scenes, or a series of buttons. WDYT @kpine? A read-write value should definitely be either a select or a number (perhaps based on some threshold?). If I don't hear any feedback in the next 48 hours, I'll just select one which seems to make the most sense based on the metadata my devices have, and do a PR.
As for setting the state class, and forcing it to be numeric... it's cause it is numeric! The irony of the impact on Home Assistant is I had to fix some bugs in openHAB (and even for this particular case) where the value was missing in incoming JSON that Home Assistant just silently ignores, but openHAB was throwing an error on. Honestly, the Central Scene should not be sensors at all, though. They should be device triggers, which can even map nicely to "single press", etc., which I'm pretty sure zwave-js already has all the metadata to do. I'll try and get a PR together to do this this weekend.

Hello
I just asked for this enhancement in domoticz too
ZWaveJSUI : Websocket integration instead of mqtt discovery
I'm not specialist enough to understand why one is better than the other one.
I understand that websocket is easier than mqtt discovery. But in this case, mqtt was working before.
Should I hope the breaking change will be corrected or rollback ?
Thank you

Should I hope the breaking change will be corrected or rollback ?

We are already working to fix the breaking change, see #3580

@barrydouu If you can add this link to your issue in the Domoticz forum: https://github.com/openhab/openhab-core/issues/4080

Done :)
Thank you for the fixing work. I missed it.

(from @kpine)

But you removed the case statement for Scene Activation CC, so it's no longer handled at all. Was that an accident?

It definitely was not an accident. Before #3539, Scene Activation was exposed as a read only sensor. But like you say at https://github.com/zwave-js/zwave-js-ui/pull/3580#discussion_r1477651685, Scene Activation sceneId is always both readable and writable, so it didn't work at all, at least for Home Assistant and openHAB (I can't speak to domoticz). Since that PR fixed Central Scene to not expose writable values as read-only sensors, there was no point in exposing Scene Activation at all. But Scene Activation CC is still a useful thing to expose, so this PR adds it (using a component type that makes it actually workable).
(from @kpine)

I don't use MQTT so take my suggestions with a grain of salt.

Indeed, I am. But I'm also trying to get the lay of the land, and where different people are coming from. For example @robertsLando seems to be the primary maintainer of zwave-js-ui, and he also does not use MQTT (or at least MQTT Auto Discovery), and has no desire to maintain MQTT Auto Discovery, but seems to be open to others sending PRs to improve it for those that do. @kpine seems to be an infrequent contributor (at least PRs), but has a lot of opinions about MQTT AD, even though they don't use it.
(from @robertsLando)

I completely agree and I would like to propose this to the OH team...

Yes, this would be ideal. I can tell you that it's unlikely to happen anytime soon. I've become the maintainer in openHAB for the MQTT binding, and also Home Assistant Auto Discovery on top of that. Because it was not maintained at all. I don't have the time or the interest in writing an entire ZWave-JS binding from scratch using the websocket protocol. Part of that is that openHAB is Java, and while I've gotten fluent enough to be able to improve the existing bindings to fix lots of issues and add support for several things, it wouldn't exactly be quick for me to write an entire binding from scratch.  openHAB also already has a completely native ZWave binding, that's partially maintained, but mostly on life support. It has no support for S2 (though apparently someone is looking into adding it), let alone Smart Start, and general network management can be difficult. These are reasons I switched to ZWave-JS-UI in the first place.
(from @robertsLando)

MQTT discovery is very complicated, limited and hard to maintain based on my experience. It is there just to give users an alternative but I would be very happy to completely remove it from the project in the future

This is certainly an opinion, though I would posit that that opinion comes from someone that doesn't actually use it. MQTT (and MQTT Auto Discovery) is the sole method that zigbee2mqtt uses to communicate with other projects, and it works just fine. ESPHome has a preference for a websocket (though speaking a Home Assistant native protocol, not a proprietary protocol, so is not an exact analogue to zwave-js-server), but maintains near-100% compatibility with MQTT Auto Discovery with zero issues. Tasmota has completely removed support for Home Assistant-based MQTT Auto Discovery in favor of their own proprietary (still MQTT based) auto discovery. I also maintain a number of other device-specific integrations that are set up similarly to ZWave-JS-UI (a separate process from the Home Automation server - i.e. Home Assistant, openHAB, or domoticz), and initially I used the Homie Convention - mainly because I also thought Home Assistant MQTT Auto Discovery seemed unneccesarily complicated, and also lacking in actual specification since it changes relatively often with no notice, simply based on the whims of Home Assistant itself. But then I had plenty of users that used Home Assistant, which does not support the Homie Convention, and I added support for Home Assistant MQTT Auto Discovery. Since then, the Homie convention has also proven itself to be somewhat capricious in changing its "specification," and given the popularity of Home Assistant, and other projects that support Home Assistant, I shifted my efforts on improving openHAB to better support Home Assistant Auto Discovery in order to have a larger bang-for-buck of how many 3rd party projects openHAB can work well with given my limited time.
Given all that, I'd be perfect happy to continue to improve support for MQTT Home Assistant Auto Discovery in zwave-js-ui, including taking Home Assistant itself as the baseline of compatibility (even though that's not a recommended configuration), ensuring it works well with openHAB, and taking into account the needs of domoticz users as well, as long as the latter two don't impose requirements that would "violate" how Home Assistant itself works with MQTT Auto Discovery. If you're not actually interested in that though, might I suggest that you set a firm deprecation/removal date or version for Home Assistant MQTT Auto Discovery in zwave-js-ui, and I'll instead focus my efforts on a 3rd party project that uses zwave-js-server to simply read metadata from zwave-js-ui, and then publish its own MQTT Home Assistant Auto Discovery metadata. I would do this in Ruby, my primary language, so I could develop it much faster. Especially since I already have a library that makes it easy to work with Home Assistant MQTT discovery, instead of manually throwing together the JSON.

@ccutrer Thanks for your detailed explaination.

and has no desire to maintain MQTT Auto Discovery, but seems to be open to others sending PRs to improve it for those that do

I would better say that I prefer to focus in other issues/features giving that, based on our stats, the users using it are very few compared to the ones using the "official" ways.

This is certainly an opinion, though I would posit that that opinion comes from someone that doesn't actually use it.

I used it when I had introduced the support for it. I spawned an Home assistant instance and I started writing down all the things needed. First problem is that this feature has come after I added the mqtt gateway support and this is the first problem that makes it hard because the topic mapping have not been created with the discovery feature in mind, if you check thermostats for example they need a new discovery every time the mode changes, also each thermostat/fan or device that has more then a value lickely needs a custom device json in order to work propely. I also experienced many breaking changes in the past on each minor/major home assistant upgrade. Before the official Home Assistant Integration I had tons of discovery issues and I was just not able to sort them all alone.
All this is just to explain my points a bit better, anyway If you or any other user want to help me with that every help is more then welcome, thanks 🙏🏼

I get it!

First problem is that this feature has come after I added the mqtt gateway support and this is the first problem that makes it hard because the topic mapping have not been created with the discovery feature in mind, if you check thermostats for example they need a new discovery every time the mode changes, also each thermostat/fan or device that has more then a value lickely needs a custom device json in order to work propely.

Two of my isolated integrations expose climate components to openHAB, and yeah, it was a bit of a contortion getting what I had originally designed for Homie discovery with very basic types to fit into the Home Assistant ecosystem where a climate component is a very complex object with many (possibly optional!) properties.

I also experienced many breaking changes in the past on each minor/major home assistant upgrade.

I'm guessing you've experienced this more than I have. But yes, it can be quite annoying. Last summer in particular they had one that drastically changed how you should name devices and components. I've also seen references in openHAB's code to  discovery fields that no longer even exist in Home Assistant's docs; I'm still deciding what I do about them.

Hello
I've seen it was fixed in daily version (9.8.3).
I've just updated, and tested and it's OK !
Thank you so much. My wife is happy. The remote control is for roller shutter. She can open and close without taking a computer :)
I've seen lot of new HA Devices, like "number_config_number_XX", or "switch_config_switch_XX" and asking myself what is it ?

Those are to allow you to automate changing configuration option on your ZWave devices. As was mentioned above, they're "disabled by default". In Home Assistant, that means you have to go find them and explicitly enable them before you use them. In openHAB, it means they're hidden behind an "Advanced" check. It sounds like Domoticz does not respect that at all. Hopefully Domoticz exposes the name for those entities somewhere.
I use it for two things - first is my switches have status LEDs that are set via configuration params, and I automate turning on specific LEDs to specific colors depending on if a door is open, a window is open, etc. Second is I have some motion switches that can be set to manual, occupancy, or vacancy modes. I set them to occupancy during the day, and vacancy at night (meaning they won't turn on when they see motion, but they'll turn off when there is no motion).

@robertsLando

MQTT discovery is very complicated, limited and hard to maintain based on my experience. It is there just to give users an alternative but I would be very happy to completely remove it from the project in the future

as a MQTT AD user let me state that i am very grateful that MQTT AD support is there. Currently MQTT AD is the only way to get zwave support in domoticz. So that's why i migrated to it.  And i was very happy to find out that in parallel i can now use my ZWAVE network from both Home Assistant and Domoticz in parallel.  So ofcourse I understand your point on maintenance, but i really hope the feature will be there for a long time..., cause it does add a lot af value to happy users like me
Keep up the good work!!

You would be able to do exactly the same if Domoticz could add the support to websockets, anyway yeah no worries about MQTT AD, I know many are using it I just want to ensure users have the best experience using ZwaveJS

a ok.. tx a lot!

Those are to allow you to automate changing configuration option on your ZWave devices. As was mentioned above, they're "disabled by default". In Home Assistant, that means you have to go find them and explicitly enable them before you use them. In openHAB, it means they're hidden behind an "Advanced" check. It sounds like Domoticz does not respect that at all. Hopefully Domoticz exposes the name for those entities somewhere.

Yes, it seems Domoticz did ignore the 'disabled by default' flag for number devices.
For other types, they show up in the overall devices overview, where you also need to explicitly add them to the system.
I will make a patch for this....
Is there a reason to send these not-enabled-by-default values to MQTT?
Depending on the QoS this might have some impact on the system, especially when using bridges.
And I assume they are persistent as well. When any client connects (or application) it gets huge traffic for not-enabled items.
If you can set them to 'enabled' in the zwavejs-ui framework easily, I would prefer to send them just then.


[Comments] 170417

Comments for https://bit101.github.io/lab/dailies/170417.html

hi @bit101!
I wanted to say thank you for the nice work you are putting out there. I've been enjoying quicksettings on several projects, e.g. https://unfoldcollective.github.io/bloom/.
Browsing your lab I came across this daily and thought it would fit nicely as the background for a festival site I was building at the time. We've now launched it and I'd love to share it with you:
https://sensorium.is/

As you can see, we're inviting visitors to play with the parameters, to which I've made some tweaks.
You can find the sketch as part of the project here:
https://github.com/unfoldcollective/2018.sensorium.is/blob/master/user/themes/imaginarious/js/170417-sensorium.js
Many thanks for sharing your inspiration and keep up the great work!

Neat. It would be nice to have a mention on the site.

I agree. I plan to publish an announcement of the festival's theme which
ties in with the background design. I think that will be the best place to
mention your work and expand a little on how we integrated it.
I will let you know when that is live.
Neat. It would be nice to have a mention on the site.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bit101/lab/issues/107#issuecomment-371316083, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA3HLmNm4JnpH4-iEeT4_dXw9N0G38_rks5tcGZHgaJpZM4M_FOB
.

hi, sorry for the long wait!
I've finally gotten round to writing that piece on the festival theme and have added a mention to you on the about page and in the footer.
I'm linking to http://www.bit-101.com/ and https://bit101.github.io/lab/thumbs.html
Are you cool with those links, or would you rather have us link to somewhere else?


Fix NaN problem while normailze the data

Here is a problem when data_x/data_y/data_z have the same value, e.g. $Z = [1,1,1,\cdots,1]$, the result of stats.zscore(data) would be NaN, which caused the error in the subsequent eigh section.

Here is the code to test this commit. Should I put this code into the folder causal-learn/tests?
By the way, there is also a problem in the class cit because [origin document](https://causal-learn.readthedocs.io/en/latest/independence_tests_index/kci.html) it says X, Y, and condition_set: column indices of data but in the cit class, X, Y can only be a single int variable, so I also write some code to make it support multi variable while not change the origin usage (see the last commit).
from icecream import ic
from causallearn.utils.cit import CIT
from tqdm import trange
import numpy as np

def generate_single_sample(type, dim):
    if (type == 'chain'):
        X = np.random.random(dim)
        Y = np.random.random(dim)+X
        Z = np.random.random(dim)+Y
        #X->Y->Z
    elif (type == 'collider'):
        # X->Y<-Z
        X = np.random.random(dim)
        Z = np.random.random(dim)
        Y = np.random.random(dim)+X+Z
    #Y = np.zeros(dim)+np.average(Y)
    return list(X)+list(Y)+list(Z)+[1]# 31 dim X:0..9; Y:10..19; Z:20..29; 1: 30

def generate_dataset(dim, size):
    dataset = []
    for i in range(size):
        datapoint = generate_single_sample('collider', dim)
        dataset.append(datapoint)
    dataset = np.array(dataset)
    return dataset

if __name__ == '__main__':
    dataset = generate_dataset(10, 1000)
    cit_tester = CIT(dataset, method = 'kci')
    ic(cit_tester.kci(0, 20, []))

    # Origin version can not pass this due to the feature-30 have the similar value
    ic(cit_tester.kci(0, 20, [30]))

    # The follow is from one of my recent requirements, which is using CIT to test high dim variables
    # Test high dim variables is not supported by current cit class, which is different from the documents,
    # so I also implement this function in the last commit.
    # An issue is related to the "CIT of test high dim variables" which I will put forward latter
    ic(cit_tester.kci(range(10), range(20,30), range(10,20)))
    ic(cit_tester.kci(range(10), range(20,30), []))
    ic(cit_tester.kci(range(10), range(10,20), []))
    ic(cit_tester.kci(range(10), range(20,30), [30]))
    ic(cit_tester.kci(range(10), range(10,20), [30]))

Thanks @cogito233 for your great work! And congrats on your first PR to improve public codebase! We really appreciate your help on making causal-learn better! :)
I'll defer to @MarkDana for the final review. I guess @MarkDana will then push another PR based on this PR, right?


Support for C# Inline Action

This adds support for the recently announced C# Inline Action. VS Code editor support is not there yet, however it's already possible to add csx files to the workflow by creating the files manually, where the name matches the action name.
The addition scans the logic app directory for any *.csx files and copies them to the working directory at the same relative paths. The reason for scanning the whole logic app directory is because it's possible to reuse code by importing *.csx files from locations outside of the workflow directory. Instead of trying to figure out which script imports which file this is the most straightforward solution.
The PR includes a test to verify the functionality.

Bump

Hi @sschutten , thank you for the contribution and apologies for the delay in sorting this out.
I hope to get the next version of LogicAppUnit published to NuGet next week.

Hi @mark-abrams, any chance you could get a new version of the NuGet package out? Would be nice yo get rid of my fork :-)

Hi @sschutten , I have released version 1.10.0 of LogicAppUnit. Thank you for your contribution, and many apologies for the delay in shipping the new version.


Use router guards in the Angular 2 client

example implemented here:
https://github.com/damienbod/AspNet5IdentityServerAngularImplicitFlow/tree/master/src/ResourceWithIdentityServerWithClient/angular2App/app/guards


Refactor the extension using a webhook for OperatingSystemConfigs to add containerd hosts.toml files

How to categorize this PR?

/kind enhancement
What this PR does / why we need it:
This PR:

Switches from the old and deprecated pattern for configuring containerd registries to the new hosts directory pattern.
Switches from a cri-config-ensurer DaemonSet to apply the desired containerd config to a webhook for OperatingSystemConfigs that adds the needed containerd hosts.toml files.

Which issue(s) this PR fixes:
Part of https://github.com/gardener/gardener-extension-registry-cache/issues/3
Special notes for your reviewer:
N/A
Release note:

The registry-cache extension is refactored in the following aspects:
- It no longer uses [the old and deprecated pattern](https://github.com/containerd/containerd/blob/main/docs/cri/registry.md) for configuring containerd registries. It is now using [the hosts directory pattern](https://github.com/containerd/containerd/blob/main/docs/hosts.md) which is available starting<EMAIL_ADDRESS>- It no longer uses a `cri-config-ensurer` DaemonSet to apply the desired containerd config. The DaemonSet is replaced by a webhook for OperatingSystemConfigs. The webhook adds containerd `hosts.toml` files (registry configuration files) to the OperatingSystemConfig.

Can we use services cluserIPs from the status here: https://github.com/ialidzhikov/gardener-extension-registry-cache/blob/c203d3c003683c2b4dedd0e838177b9f295b9475/pkg/controller/actuator.go#L172?

Can you elaborate in more details? Do you mean that the 1st commit duplicates the code that fetches the Service clusterIPs. If yes, later in the 3rd commit the old (and duplicated) part for fetching the Service clusterIPs is dropped together with the cri-config-ensurer. So, current we only fetch once the Service clusterIPs during reconciliation.


File upload fails with "Unexpected end of form"

Issue workflow progress

Progress of the issue based on the Contributor Workflow

[x] 1. The issue provides a reproduction available on Github

Just a graphql-file-upload-example without image convert

[ ] 2. A failing test has been provided
[ ] 3. A local solution has been provided
[ ] 4. A pull request is pending review

Describe the bug
Any multipart upload form mesh seems to fail with Unexpected end of form error.
To Reproduce

Take graphql-file-upload-example or simplified one I provided
Start apis (3001 port), start gateway (4000 port)
use curl to try multipart  with api itself curl localhost:3001/graphql -vvv -F operations='{ "variables":{"upload":null}, "query": "mutation ($upload: File!) {uploadFile(upload: $upload){filename}} "}' -F map='{"1":["variables.upload"]}' -F<EMAIL_ADDRESS>Result is {"data":{"uploadFile":{"filename":"vk.png"}}}
use curl to try multipart  with gateway curl localhost:4000/graphql -vvv -F operations='{ "variables":{"upload":null}, "query": "mutation ($upload: File!) {uploadFile(upload: $upload){filename}} "}' -F map='{"1":["variables.upload"]}' -F<EMAIL_ADDRESS>Result is {"errors":[{"message":"Unexpected end of form"}]}

Expected behavior
File is uploaded succesfully in both cases
Environment:

OS: macOS v11.6.8
@graphql-mesh/cli: 0.78.21,
@graphql-mesh/graphql: 0.31.15,
NodeJS: v16.15.1

Additional context

graphql-yoga v3 seems to be the breaking element, stacktrace somewhat like this:

graphql-yoga POSTMultipart
whatwg-node getFormDataMethod
busboy multipart

Couple of more weird things:

in my project upload works for small files (5kb), but I cant replicate such behaviour with example
Separate api with graphql-yoga v3 handles uploads just fine

Seems to be fixed with newer yoga


Requests when used in combination with R3

I have two requests.
1. readonly-observable-Dictionary
The IReadonlyReactiveDictionary that existed in UniRx was easy to use, so we request a function equivalent to it.
If I tried to handle the current ObservableDictionary Readonly, I would have to divide it into two parts, IReadonlyDictionary and IObservableCollection<KeyValuePair>, which is not easy to handle.
2.   Publish OnCompleteMessage from IObservableCollection.
When dealing with IObservableCollection in R3, I feel uncomfortable that it is not possible to unsubscribe from the collection side.
For example, could it be possible to make IObservableCollection inherit IDisposable and issue OnCompleted on Dispose()?

When the CancellationToken of each subscription method (ObserveAdd, etc...) of R3Extensions is canceled, OnCompleted will be issued.
This is the same behavior as R3's Observable.Timer, etc.


Provide command to add comment to pull-request

I would like to be able to add comments to a pull-request.
This might be done with a command of the following signature:
az repos pr comment add "My comment to add\nwith more than one line" --org https://..... --id 12345

Is there any plan to do this? Is there any way to do this aside from the direct POST?

Hello Team, what is the way to get this done while we don't have a command to help?

@DanielHRio while nothing official, i ended up just doing the REST API way - https://gist.github.com/ransagy/e62d5505770125d32a1c57670972a874

Any updates on this one? 😊

Dear Team, is there an update on this request? This seems to be a basic feature that is missing.


Support context.Timeout during Connection initiation.

Presently, the native.Connect doesn't have a mechanism for timeouts. This gives rise to situations where the connection hangs for ever.
Can be re-created easily with wrong address or port during establishing connection.
Asterisk Version: 18 LTS.
cl, err := native.Connect(&native.Options{
		Application:  appName,
		Username:     user,
		Password:     pass,
		URL:          fmt.Sprintf("http://%s:%d/ari", host, port),
		WebsocketURL: fmt.Sprintf("ws://%s:%d/ari/events", host, port),
	})

Oops!  That's an unpleasant oversight.

I'd be happy to accept it, thanks.   I started looking at it yesterday, and the right way to do it would be to modify the base signatures of the functions to include the context as the first parameter.  However, that would break backward compatibility (though that's not necessarily a reason to not do it).  A usual method of getting around that is to just create a new function with the Context prefix (e.g. ConnectContext())... that would be fine, too.
BUT, the real problem here is that the underlying websocket dial doesn't use context for its cancellation; it needs to have an explicit timeout declared in its configuration struct.  Now, we could derive that from our context's deadline, but that would conflate the retries mechanism, which I don't much like.
So, I think it would generally be better to NOT use context deadlines here at all, but rather extend our Options to include a DialTimeout, which would be used to construct the websocket Dialer options.

I agree with you there. The way I am doing it now is create a *-withContext function as well as expanding the options. This way we can keep the backward compatibility as well as provide a choice for future consumers.


Customisation example answers do not appear when editing plan

Expected behaviour: When you edit a plan using a customised template, you should see either:
* Both the funder's and the customising org's example answers
* The customising org's example answer
Actual behaviour: You only see the funder's example answer and the other one is never displayed
Screenshot:

testing on dmptool stage and here is what i see @briri  (screenshot below):

example answers now appear w/appropriate org label, but there is also a label w/the funder name and a blank space if there's no funder-provided sample answer below every question. desired behavior is to only display an example answer for the funder or the org if one has been provided.

this now works as expected on roadmap stage. closing issue.

Yay! This is fantastic to see. We've been asked to display multiple example answers in the past so we've added a new feature here. One to promote in the release notes and blog ;-)
Looks great!


Can't run amplify mock

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
No response
Amplify CLI Version
10.4.0
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No
Amplify Categories
api
Amplify Commands
Not applicable
Describe the bug
When I run "amplify mock" or "amplify mock api" I get the following error message:
{     "name": "UnknownFault",     "classification": "FAULT",     "options": {         "message": "Cannot read property 'stop' of undefined",         "resolution": "Please report this issue at https://github.com/aws-amplify/amplify-cli/issues and include the project identifier from: 'amplify diagnose --send-report'",         "stack": "TypeError: Cannot read property 'stop' of undefined\n    at APITest.stop (/snapshot/repo/build/node_modules/amplify-util-mock/lib/api/api.js:149:33)\n    at APITest.start (/snapshot/repo/build/node_modules/amplify-util-mock/lib/api/api.js:127:18)\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)",         "link": "https://docs.amplify.aws/cli/project/troubleshooting/"     },     "downstreamException": {},     "resolution": "Please report this issue at https://github.com/aws-amplify/amplify-cli/issues and include the project identifier from: 'amplify diagnose --send-report'",     "link": "https://docs.amplify.aws/cli/project/troubleshooting/" }
Expected behavior
Running amplify mock should not throw any errors.

}

Project Identifier
fe991c4ae488b4f8c1065cb5a01664c7
Log output

# Put your logs below this line

Additional information
No response

This error appears if Java is not installed. After installing Java on my Mac it worked. Therefore closing this, even though I think, there should be a better error message that hints to the developer to install Java.


Scavengers: Viewhunt/Queue improvements/fixes

Add "unrated" hunts to queue system
fix /forcestarthunt, an add an unrated option for this.
allow /viewhunt to show the current question while leaving the unknown answer blank

I plan to soon do typescripting with scav stuff so it's like the other chat-plugins
I swear I am a good neko!!!

As far as I know, we have no devs on Scavengers? Someone will need to run these changes past Scavs auth.

If i held back on my salty shitposting I would be lol. Anyways regarding this, it has full approval from Meicoo (screenshots on Discord)

@Zarel I've updated it :3

I'm not a fan of this huge line 183, but the change seems fine.


Inconsistent handling of nicknames

Compare
    first: Buddy
    last: Carter
    official_full: Earl L. "Buddy" Carter

to:
    first: Garland
    last: Barr
    nickname: Andy
    official_full: Andy Barr

I like the style of having all the name components available but using only the members' preferred name (as given on their websites) as the official_full name. So, I think it would be preferable to update Rep. Carter to read:
    first: Earl
    middle: L.
    nickname: Buddy
    last: Carter
    official_full: Buddy Carter

Also need to have a look at the full names of Eric A. "Rick" Crawford, Charles J. "Chuck" Fleischmann, Henry C. "Hank" Johnson Jr., and Robert C. "Bobby" Scott ... and that's just the current legislators!
What do you think?

official_full is being used for some sanity checking in the scripts:
https://github.com/unitedstates/congress-legislators/search?utf8=✓&q=official_full
For House members, its value can't be changed without breaking the sanity checks.

.... And the rest of the name fields reflect how the legislator wants to be referred to (as opposed to what we think the legislator's legal name might be).

So, the official_full name for House members must match http://clerk.house.gov/?
Those entries are sometimes at odds with what the legislators have on their own sites.
Compare:

Chuck Fleischmann http://fleischmann.house.gov/
Charles J. "Chuck" Fleischmann http://clerk.house.gov/member_info/mem_contact_info.aspx?statdis=TN03

Sorry, unclear on the sources for the name info -- how do we know what name the legislator wants used, @JoshData ?

So, the official_full name for House members must match http://clerk.house.gov/?

If we want the ability to sanity check the scripts, yes.

unclear on the sources for the name info -- how do we know what name the legislator wants used

Their website primarily, or how they appear in official documents (say, bill text).

I don't understand the purpose of the sanity check against the Clerk site if that site is not the canonical source for name information.
If official_full is going to remain untouched, though, can the rest of Buddy Carter's name properties be adjusted as I suggest? Should there be pull requests modifying the yaml file directly, or do you use a script to fetch the proper name information? I don't see a script.

I don't understand the purpose of the sanity check against the Clerk site if that site is not the canonical source for name information.

It's not a check on the value of the fields --- it's a check that the data we're pulling from the Clerk site is lining up with the right person at all, because we're fetching it by state & district and not by an identifier linked to a person specifically, if I recall right.
The names are maintained by hand.
I would be okay with the Buddy Carter changes (as a pull request, yes). For others reading, that's from
first: Buddy
last: Carter

to
first: Earl
middle: L.
nickname: Buddy
last: Carter

even though his website primary says "Buddy Carter", on the basis that his name is spelled out on his bio and the longer form matches the Clerk site.
Anyone else want to ring in?

:+1: Looks good to me.

:+1: as well.
Unfortunate that the field is named official_full as it implies that it's an official display name, which it apparently is not. Even more confusing when the proper name to use should be found "in official documents" but official_full does not reflect that. Oh well, ¯\_(ツ)_/¯.


feat: upgrade office-ui-fabric-react to 6.185.0

Would need some more work to remove duplicated modals and minor style differences.
The big thing is eliminating the modal issues and we would want to evetually be on 6.x for support anyways.  We can at least we can start with this to find more bugs later.
There are some differences listed in this comment: https://github.com/OfficeDev/office-ui-fabric-react/issues/8264#issuecomment-476300818

:tada: This PR is included in version 0.359.0 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


URL Error and socket timeout errors

Since the last update of our Raumfeld Devices I sometimes get the following two exceptions when calling raumfeld.discover():
File "/home/pi/.local/lib/python3.7/site-packages/raumfeld/__init__.py", line 60, in discover
    devices = [RaumfeldDevice(location) for location in locations]
  File "/home/pi/.local/lib/python3.7/site-packages/raumfeld/__init__.py", line 60, in <listcomp>
    devices = [RaumfeldDevice(location) for location in locations]
  File "/home/pi/.local/lib/python3.7/site-packages/raumfeld/__init__.py", line 79, in __init__
    xml = fetch(self.location, self.http)
  File "/home/pi/.local/lib/python3.7/site-packages/pysimplesoap/helpers.py", line 76, in fetch
    response, xml = http.request(url, 'GET', None, headers)
  File "/home/pi/.local/lib/python3.7/site-packages/pysimplesoap/transport.py", line 145, in request
    f = self.request_opener(req, timeout=self._timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/lib/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 1352, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/lib/python3.7/urllib/request.py", line 1326, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error timed out>

and
  File "/home/pi/.local/lib/python3.7/site-packages/raumfeld/__init__.py", line 60, in discover
    devices = [RaumfeldDevice(location) for location in locations]
  File "/home/pi/.local/lib/python3.7/site-packages/raumfeld/__init__.py", line 60, in <listcomp>
    devices = [RaumfeldDevice(location) for location in locations]
  File "/home/pi/.local/lib/python3.7/site-packages/raumfeld/__init__.py", line 79, in __init__
    xml = fetch(self.location, self.http)
  File "/home/pi/.local/lib/python3.7/site-packages/pysimplesoap/helpers.py", line 76, in fetch
    response, xml = http.request(url, 'GET', None, headers)
  File "/home/pi/.local/lib/python3.7/site-packages/pysimplesoap/transport.py", line 145, in request
    f = self.request_opener(req, timeout=self._timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/lib/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 1352, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/lib/python3.7/urllib/request.py", line 1327, in do_open
    r = h.getresponse()
  File "/usr/lib/python3.7/http/client.py", line 1336, in getresponse
    response.begin()
  File "/usr/lib/python3.7/http/client.py", line 306, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.7/http/client.py", line 267, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.7/socket.py", line 589, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

How can I fix that?

To be honest I have no idea. It seems like the device is not reachable in the network?
The problem is I don't own any Raumfeld devices anymore. Maybe try it with https://github.com/scjurgen/pyfeld ?

Thank you. I will try this :)


tracing: Support tracing in http/async_client

Description: Add another public-facing interface that allows http/async_client to trace a request. Any custom filters that use this client can ensure requests are traced by passing in the active parent span.
Risk Level: Low, only adds new APIs (backwards compatible)
Testing: Not sure how to test the new spans being created, since there are no unit tests in this folder. We also do not have any integration tests from tracing. The current tests will at least verify that this code hasn't broken anything.
Docs Changes: N/A
Release Notes: N/A

Please add tests here: https://github.com/envoyproxy/envoy/blob/master/test/common/http/async_client_impl_test.cc

/wait

Will it be cleaner if we add parent trace span as another property of the request/stream options instead? That way, you can get it applied for gRPC async client as well.

Will it be cleaner if we add parent trace span as another property of the request/stream options instead? That way, you can get it applied for gRPC async client as well.

I didn't look at the change yet but +1

Will it be cleaner if we add parent trace span as another property of the request/stream options instead? That way, you can get it applied for gRPC async client as well.

The grpc async client already allows custom filters to pass a parent span in directly to the constructor: https://github.com/envoyproxy/envoy/blob/master/source/common/grpc/async_client_impl.h#L95
This change basically mimics the same behavior for the http async client.
Should it be added to the request options? This will result in the two interfaces being different for creating spans.

If you do, you should clean up the gRPC interface to be consistent with the HTTP one. I think it is a cleaner interface to pass HTTP router options like the trace span via the options object.

That does make sense, but that would be a breaking change. Any custom filters that construct the grpc async client always pass in a span, so moving it to the options would break those filters. Any easy way to resolve that?

It's not a breaking change. Envoy does not provide a strong guarantee on its internal C++ interfaces. If this leaves code in a better state, I'd say go for it, but it's up to maintainers to decide, of course.

I'm confused on why TEST_F(AsyncClientImplTest, ResetStream) is broken. It seems like this->streamInfo() is null in void AsyncRequestImpl::cancel(). Any advice?

I'm confused on why TEST_F(AsyncClientImplTest, ResetStream) is broken. It seems like this->streamInfo() is null in void AsyncRequestImpl::cancel(). Any advice?

Nevermind, this was an issue with the headers and trailers being null, since the cancel occurs before the response.
/wait

Ready for review. I added unit tests.
This code mimics grpc async client, where the parent_span is passed in as a arg to the constructor instead of in the RequestOptions. Let me know if we should follow @kyessenov's suggestion and move the span to the RequestOptions in both clients.
I prefer to do it this way since it requires less code change and doesn't remove from the public-facing interface, but I can implement it the other way too if it's cleaner!

I prefer to do it this way since it requires less code change and doesn't remove from the public-facing interface, but I can implement it the other way too if it's cleaner!

I agree with @kyessenov and recommend that we add it to options. It's a more sustainable long term approach which will make it so that we no longer have to do massive constructor updates everywhere. Thank you!
/wait

Ready for review :100:
Moved the parent_span_ to the RequestOptions for the http async client.
I would prefer to cleanup the grpc async client in a separate PR. I can make an issue and work on it later this week if needed.

All tests passed on my machine. I can't figure out what the failure on CI was. Help?

Fixed the issue, it was a problem in my tests (not src)


NF: Correct a broken markdown link

Thanks so much @Arthur-Milchior! Keep these corrections coming!


Search API stopped working

A few days ago the search api stopped working. There are a few things that need to be addressed to get it working again:

The client_id when logging in needs to be updated to 30100.
The x-picnic-agent header needs to be updated to 30100;1.15.232-15154.
The url has changed to /pages/search-page-results?search_term=.... The response is now json data that contains page layout and analytics information but the search results can be found by looking for selling_unit.
The search results only contain one of the available bundle option, e.g., in case you can buy 1, 2, or 4 items in a bundle, you might only find the bundle containing 2 items. If you are interested in all bundle options, /pages/bundle-overview-page?sole_article_id=...&show_category_action=true provides that information. The sole_article_id is part of the selling_unit object returned by the search-page-results api. The article ids can be fetched by using the regex /"product-page-bundle-item-(s[0-9]+)"/.
For both, 3 and 4, the x-picnic-agent needs to be part of the request.

Making the first two changes is easy. However, it is hard to maintain the current api when updating point 3 and 4 for the following reasons:

The semantics have changed as different bundle options are not part of the search result any more.
The data structure has changed, e.g., the discounted price is not part of the selling_unit's decorators any more.

Yes, that is the case. I reversed the API around last week and found a solution based on the new API. Not only the new API endpoint needs to be considered, but also the authentication needs to be changed due to the insufficient authorisations that the old bearer token has. Therefore, the MFA must also be taken into account.
So I made a monkey patch to the Picnic package in advance, but best practice would be to set this up as a default in the latest official Python package. Nevertheless, considering these new things, everything works like a charm.

Sorry for being a noob but does this mean its being fixed or already fixed? How can i get the monkey patch?

Quick update: I'm currently implementing the fix for this, together with some other outdated types and featurs such as the bundling of products and planning to release it tomorrow! 😄

I've added nr 3 in the latest release since it was quite straight forward. For nr 4 I/we need to think about how to do this nicely, as some of the properties have to be extracted from the giant pml objects, which would be very sensitive to errors. Happy to hear your suggestions on this.

For nr 4 I/we need to think about how to do this nicely, as some of the properties have to be extracted from the giant pml objects, which would be very sensitive to errors. Happy to hear your suggestions on this.

@MRVDH, in my local copy I avoided parsing the whole pml structure by using a regex to find the article ids of the bundle options.
getBundles: (soleArticleId: string) => Promise<string[]> = async (
    soleArticleId: string,
  ) => {
    const picnicClient = await this.createPicnicClient();

    const response: any = await picnicClient.sendRequest(
      "GET",
      `/pages/bundle-overview-page?sole_article_id=${soleArticleId}&show_category_action=true`,
      null,
      true,
    );

    const articleIdMatches: string[] = Array.from(
      JSON.stringify(response.body).matchAll(
        /"product-page-bundle-item-(s[0-9]+)"/g,
      ),
    ).map((match) => match[1]);

    const uniqueArticleIds: string[] = [...new Set(articleIdMatches)];

    return uniqueArticleIds;
  };

Based on the article ids the actual articles can be retrieved using the existing getArticle API. The downside of this approach is that you need to make an additional network request per bundle option. The benefit is that we don't depend on the overall pml structure but only on that one regular expression. If we go with such an approach, soleArticleId needs to be added to the SearchResult type.

Added this in v3.1.1! Let me know if there can be more improvements, otherwise I'd say we can close this issue.

It is working great - thanks for making the changes!

@MRVDH, I'd like to have a crack at implementing fixes for this issue in the python-picnic-api as well.
However, looking through the commit d4d616 it is not immediately obvious to me which changes address the 5 points mentioned by @christof-mathies at the beginning of this thread. Could you point me to the right place? (e.g., the x-picnic-agent update)

Hi @thijmen-j , sure!
The commits are a bit messy due to formatting changes, so let me point you to the relevant pieces of code:

https://github.com/MRVDH/picnic-api/blob/v3.1.2/src/index.ts#L79
https://github.com/MRVDH/picnic-api/blob/v3.1.2/src/index.ts#L476
https://github.com/MRVDH/picnic-api/blob/v3.1.2/src/index.ts#L145-L166
https://github.com/MRVDH/picnic-api/blob/v3.1.2/src/index.ts#L172-L192
This is the 4th true parameter when sendReuest is called. For some endpoints it has to be included. (1, 2)

Let me know if that clears it up or if you need more info 👍


fix(SPV-1069) fix lint errors for "models" package

Pull Request Checklist

[ ] 📖 I created my PR using provided  : CODE_STANDARDS
[ ] 📖 I have read the short Code of Conduct: CODE_OF_CONDUCT
[ ] 🏠 I tested my changes locally.
[ ] ✅ I have provided tests for my changes.
[ ] 📝 I have used conventional commits.
[ ] 📗 I have updated any related documentation.
[ ] 💾 PR was issued based on the Github or Jira issue.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 57.14286% with 3 lines in your changes missing coverage. Please review.

Project coverage is 45.95%. Comparing base (492beda) to head (2906087).

Files with missing lines
Patch %
Lines

models/request/transaction_specification.go
33.33%
2 Missing :warning:

models/request/opreturn/data_type.go
50.00%
1 Missing :warning:

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #800   +/-   ##
=======================================
  Coverage   45.95%   45.95%
=======================================
  Files         364      364
  Lines       17595    17595
=======================================
  Hits         8086     8086
  Misses       8912     8912
  Partials      597      597

Flag
Coverage Δ

unittests
45.95% <57.14%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines
Coverage Δ

models/contact.go
0.00% <ø> (ø)

models/filter/access_key_filter.go
70.00% <ø> (ø)

models/filter/contact_filter.go
0.00% <ø> (ø)

models/filter/destination_filter.go
72.72% <ø> (ø)

models/filter/generics.go
0.00% <ø> (ø)

models/filter/paymail_filter.go
73.91% <ø> (ø)

models/filter/transaction_admin_filter.go
0.00% <ø> (ø)

models/filter/transaction_filter.go
84.21% <ø> (ø)

models/filter/utxo_filter.go
71.87% <ø> (ø)

models/filter/xpub_filter.go
72.72% <ø> (ø)

... and 7 more

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 492beda...2906087. Read the comment docs.