First set of proposed msgs for setting up Cartesian Impedance parameters

General comments:

use SI units everywhere (REP-103). Conversion to whatever a particular controller/robot needs will need to be done in robot-specific code.
follow naming conventions for msgs and fields: see wiki/msg and wiki/ROS/Patterns/Conventions. In particular, no camelcasing fieldnames.

Thank you so much for your suggestions @shaun-edwards and @gavanderhoorn.
Just one general question regarding the definition of the damping parameters. For the KUKA they are unitless ( Lehr’s damping ratio). I suggest to go with this now and explicitly state this in the explanation of the message. If you have better idea how we can handle unitless msg let me know :)

Unit-less damping ratio seems OK with me.  Would the damping be limited 0-1 or is it possible to have an over-damped (>1) situation?

Thank you @shaun-edwards . The damping ratio is set to be between the values: 0.1 - 1. In case of the iiwa is not allowed to be 0 nor to be >1

@rkojcev: do you have any examples of other robots that support setting damping in this way? What units (if any) do they use?
I just want to avoid modelling all of this on the way KUKA does things.

Also: general comment: I'd not put URLs in the comments of the messages, it seems redundant. Locally users can just do a rosmsg show .. if they want to know more about the structure of a particular field, and online the rosdoc generators will already make all types clickable links.
Besides being redundant, it's also adds maintenance overhead: you/we now have to make sure the links keep working.

@gavanderhoorn I only have access to the kuka iiwa and kuka lbr 4+. However in the literature, even though most of the publications are from DLR regarding this topic, there are some publications that use custom-made robots and they use Ns/m. It would be a good idea to reach to other people who use Cartesian Impedance on industrial robots and maybe we could get some input from them on this matter.
It might be also good idea to make 2 types of damping messages, one could be called damping_ratio and will use unitless values (same as the ones KUKA is using) and other called just damping which will use Ns/m.

It would be a good idea to reach to other people who use Cartesian Impedance on industrial robots and maybe we could get some input from them on this matter.

That would be a very good idea.

Question after an internal review here:

the damping/stiffness of the end-effector need to be in some reference frame (while the null-space stiffness/damping is independent thereof). This is not explicit in any of the messages. So are those always in the current frame of the position/orientation control? What happens if you switch to a different frame for position/orientation control?

@gavanderhoorn here things get interesting.
Compared to Cartesian Control w/o impedance usually you adjust just the position and orientation of the new frame (tool). When you want to perform a trajectory motion with Cartesian impedance you need to know the exact mass of the tool, center of mass and moments of inertia of the tool.
Once you set this values for the tool then the robot will know how to adjust its motor torques taking into account the new tool properties. Then when you set all the Cartesian Impedance parameters the new tool is taken into account. From the user perspective the values he is setting for the Impedance Control do not have to be changed if you add a new tool, what is important is to properly define all the parameters of the tool to have desired Cartesian Impedance Motion, otherwise the robot might not behave as desired, and the spring properties of the Cartesian Impedance will not be correct. This leads to bad Force Control for example.
This is mostly visible if the robot is in gravity compensation mode. When the tool properties are not set correctly the robot will not be able to maintain its position or will jump up/down with its maximum speed.
In KUKA LBR4+ you are only able to set these parameters directly on the controller. On the iiwa you are able to send this parameters via messages. Usually these robots offer possibility to determine all of these properties via tool calibration steps directly on the controller and this is the desired procedure to do this.
In my plan I am also envisioning to have this set of messages for setting the tool properties as well. :) We can offer this possibility to the user to set the tool properties via messages even though I do not recommend it. If it was up to me I would go trough the painful calibration when adding new tool. In my experience the robot has better behavior if the tool is calibrated internally on the controller. At least that was the case for the KUKAs.

@gavanderhoorn and @shaun-edwards I have addressed all of your comments.
Should we make a new PR or you can check the changes in this one?

So do I understand you correctly that you say that it doesn't make sense to include any reference frame because it is always relative to the currently defined / calibrated tool? I think the question I relayed was more about "in what frame are these damping parameters defined" (obviously not for null-space).

Yes exactly @gavanderhoorn
Sorry for the long answer. I just wanted to elaborate little bit more on the differences when doing Cartesian Impedance Control

Related to @gavanderhoorn's question.  The rotational/translational elements are specified with respect to a particular frame.  Assuming the tool frame?  Should this message set make that assumption, or should we name the frame in which these elements are represented?  If we name the frame, can we avoid the "tool setting" message set (i.e. the driver will set the tool if the message it receives specifies a different frame)?

Sorry about my long answers.

The rotational/transnational elements are specified with respect to a particular frame. Assuming the tool frame?

Yes that is correct.

Should this message set make that assumption, or should we name the frame in which these elements are represented? If we name the frame, can we avoid the "tool setting" message set (i.e. the driver will set the tool if the message it receives specifies a different frame)?

In my opinion it has to make this assumption. Every time we set the robot into Cartesian Impedance a set of commands is loaded. The most important one is verifying the tool mass and center of mass. This usually happens before you can call set Cartesian Impedance Parameters and is when the robot is initialized. While the controller allows changing Cartesian Impedance parameters interactively I have never tried changing tool interactively (I am not sure this is feasible) but its worth trying.
Let us assume we go with the option where we name the frame in the msgs. Then on the controller side we have to look for all the calibrated frames, that are usually stored on the controller and see if any of them matches the one in the send msgs, once match is found we have to call the robot internal tool verification, and handle errors.
As I mentioned I would not recommend setting tool mass properties directly unless I have very good mechanical model of the tool where I have made all the necessary calculations of its properties and still in my experience that one is more prone to failure compared to the one where I calibrate the tool internally on the robot controller.
I would like to try this out and see what is practically feasible :) Sending and setting frame directly from the message would be a better idea compared to making new set of messages for loading the tool.

What you describe seems based on your experience with KUKA robots (which is fine!). While it is true that there are not many others that expose impedance controls, I feel it makes more sense to design this set of msgs for an abstract, 'ideal' and yet to be constructed robot. That way we at least try as much as possible to avoid (implicitly) encoding assumptions into the messages based on how KUKA does things.
I'd like to see the frame made explicit for two reasons:

future proofing: the fact that changing the tool on-line is not supported (or is difficult) right now (and then only on the robots that are part of the 'reference group') is not a good argument to not include it imo. Future robots / controllers might support it (or even depend on it), and by making the design decision to not include an explicit frame reference, the msgs will be less useful in those cases.

I've not seen any / searched, but how does an IIWA interact with tool changers fi? I would assume it would need to update parameters in that case as well.

'safety' (I put this in quotes as it's a software / user-level thing (ie: convenience, saving you from dumb things), not a safety-rated feature): ROS applications are mostly autonomous, but still made by people. Having the frame explicit makes it possible for the receiving entity (ie: a controller) to check that whatever comes in actually corresponds to what it knows about / is configured for. For configuration type msgs / services, if the robot does support on-line configuration, it can perform checks and then update its configuration. For robots that don't, always return an error if a change is requested, otherwise, check specified frame corresponds to what is currently configured and update the corresponding parameters.

@rkojcev wrote:

As I mentioned I would not recommend setting tool mass properties directly unless I have very good mechanical model of the tool where I have made all the necessary calculations of its properties and still in my experience that one is more prone to failure compared to the one where I calibrate the tool internally on the robot controller.

While I understand what you're trying to say, I don't think this is something that should influence our decision on whether or not to include something in the messages. It would be the users responsibility to make sure that the messages are used properly. A geometry_msgs/Twist can also be a dangerous thing if I don't set it up correctly.

What you describe seems based on your experience with KUKA robots (which is fine!). While it is true that there are not many others that expose impedance controls, I feel it makes more sense to design this set of msgs for an abstract, 'ideal' and yet to be constructed robot. That way we at least try as much as possible to avoid (implicitly) encoding assumptions into the messages based on how KUKA does things.

I definitely agree on this one. We should not constrain our design on any particular hardware.

I've not seen any / searched, but how does an IIWA interact with tool changers fi? I would assume it would need to update parameters in that case as well.

Yes, it needs to update all the necessary parameters. Changing tool interactively under Cartesian Impedance is something that I would like to try it out and see how the robot behaves.  Then I can open an issue here where we can think of possible outcome if it supports or does not.

For configuration type msgs / services, if the robot does support on-line configuration, it can perform checks and then update its configuration. For robots that don't always return an error if a change is requested, otherwise, check specified frame corresponds to what is currently configured and update the corresponding parameters.

I also agree on this one. Checks need to be performed in any way.
I agree with you @gavanderhoorn on your points raised here. I know that for now I am testing everything on the iiwa and I might be biased in some of the arguments I am raising, but definitely having feedback from everyone will help us design a general msgs which could be used in any present or future hardware.
In general, I also think we should add frame to the msgs and I also would like to try out interactively changing the frame. I think this feature will be quite useful to have.

closing this and opening new pull request with the changed msg after discussion above.


Kapacitor alert templating

I am trying to use httppost to send alerts to elasticsearch. However, I am getting - "mapper parsing exception", I assume its because of time and _value in data.series.columns list.
This is the Alert format - {"time":"2022-08-24T06:00:00Z","duration":0,"level":"OK","data":{"series":[{"name":"kpi","tags":{"BID":"1017","_field":"key-field","cid":"labec17-1017","version":"6.0"},"columns":["time","_value"],"values":[["2022-08-24T06:00:00Z","100"]]}]},"previousLevel":"CRITICAL","recoverable":true} .
I want to remove time from "columns" array and similarily timestamp from "values" array. I found an answer in stackoverflow - https://stackoverflow.com/questions/47576251/what-language-do-kapacitors-alert-message-templates-use and tried to use alert template, however its not working. How can I do it?

You can define your own templates for the alert handlers.  Here is the documentation for it. Its just a golang stdlib text template.
https://docs.influxdata.com/kapacitor/v1.6/event_handlers/post/#alert-templates
https://pkg.go.dev/text/template


Design & spec "Card group"

Card group (Actual component name TBD) is a section used on AEM solution template.
Acceptance criteria

[x] Finalize design. Needs to be fleshed out with all variations
[x] Visual and functional spec
[ ] Write out some basic usage guidance :book:

"Card group" component has preliminary design below:

Can be build with existing components. Will move to done.


Prefix the property name of secrets and configmaps

I had to read the multiple secrets to connect to the Strimzi. As Strimzi is auto-generating the the secrets, the secrets contain the same properties (sasl.jaas.config, ...).
Is possible to prefix the properties to support multiple secrets (or configmaps) with the same properties?
For example:
If the secret "consumer" would have the prefix "kafka.consumer", the value of K8 secret property would accessible by "kafka.consumer.sasl.jaas.config" in Spring.
If the secret "producer" would have the prefix "kafka.producer", the value of K8 secret property would accessible by "kafka.producer.sasl.jaas.config" in Spring.
Or can I remap the secrets and configmaps in different way?

I am trying to understand better the problem.
You have multiple secrets, each with the same property?
For example,
Secret 1
sasl.jaas.config=....
Secret 2
sasl.jaas.config=....
Secret 3
sasl.jaas.config=....
Any you are trying to use these secrets within the same application?

Exactly as you have described it!
I have multiple secrets, each with with the same properties and the secrets should be used with the same applications.
My problem is that I can't influence the secret creation itself as the secrets will be generated by the Strimzi (Kafka) Operator.
One secret contains the config for the communication with the Kafka handling the communication between the microservices.
Another secret contains the config for the Kafka which triggers the webhooks or sends the notifications to the UI.

@ryanjbaxter I looked into the code of the secrets configuration.
If you would add an additional config parameter prefix to the sources configuration like this:
spring.cloud.kubernetes.secrets.sources.prefix
https://github.com/spring-cloud/spring-cloud-kubernetes/blob/f43b5c1a45e958f65b46fdd04a8a37b745e5755d/spring-cloud-kubernetes-commons/src/main/java/org/springframework/cloud/kubernetes/commons/config/SecretsConfigProperties.java#L102
Then you could provide the new parameter prefix to method getSourceData in KubernetesClientSecretsPropertySource
https://github.com/spring-cloud/spring-cloud-kubernetes/blob/1a136a52680ad733edc5e52e18155f61d7799a0c/spring-cloud-kubernetes-client-config/src/main/java/org/springframework/cloud/kubernetes/client/config/KubernetesClientSecretsPropertySource.java#L48
which then can provide the prefix to putAll. If prefix is set, the name (aka k) will be prefix otherwhise it will simple use k as name.
https://github.com/spring-cloud/spring-cloud-kubernetes/blob/1a136a52680ad733edc5e52e18155f61d7799a0c/spring-cloud-kubernetes-commons/src/main/java/org/springframework/cloud/kubernetes/commons/config/SecretsPropertySource.java#L45
Would do you think about this approach?

I wonder if you could use the name of the secret as the prefix, with the option to specify your own if you wanted.  Thoughts?

@ryanjbaxter Using the name of the secret's source as prefix would work for me.  The values of name and prefix would have been the same anyway.
My idea behind the separate property "prefix" was to control the usage of the prefix mechanism to have backward compatibility that the secrets aren't automatically prefix. But this can be controlled by an other config setting.

We would certainly need it to be optional, at least for now.  So a property to opt into the functionality would be necessary.  We could also add a warning if there is already a property source with the same name.  Make sense?

@ryanjbaxter Make sense to me!

Is this something you would like to contribute?

@ryanjbaxter I have implemented the support and created a pull request.
https://github.com/spring-cloud/spring-cloud-kubernetes/pull/818

@ryanjbaxter  and this one too


Everything looks right, I'm seeing meters in debug, but I'm not getting anything sent to mqtt

Hello,
I'm not sure what's misconfigured, but I'm not getting any meter or autodiscover data sent to my MQTT broker. This is the contents of my mqtt section
mqtt:
  host: 192.168.1.xx   #xx is the number of my hassio VM, running mosquitto
  user: mymqttuser
  #password: "mymqttpassword"
  ha_autodiscovery: true
  ha_autodiscovery_topic: homeassistant

I also put intentionally wrong config info in there, and I didn't get any messages in the logs, either, so I'm not sure is it's managing to connect at all or not.

fwiw, this is what the docker logs for your container look like for me
Starting in DEBUG Mode...
listening...
{"Time":"2021-09-09T17:37:04.480287828Z","Offset":0,"Length":0,"Message":{"ID":xxxxx928,"Type":12,"TamperPhy":3,"TamperEnc":0,"Consumption":238360,"ChecksumVal":9190}}

{"Time":"2021-09-09T17:37:13.821391357Z","Offset":0,"Length":0,"Message":{"ID":yyyyy738,"Type":12,"TamperPhy":2,"TamperEnc":0,"Consumption":682008,"ChecksumVal":38380}}

{"Time":"2021-09-09T17:37:18.848854257Z","Offset":0,"Length":0,"Message":{"ID":xxxxx314,"Type":12,"TamperPhy":3,"TamperEnc":0,"Consumption":236312,"ChecksumVal":16941}}

...repeat json string forver

I see other print messages in your python script, but none of them show up in the docker logs, so I'm not sure what I'm missing

Same here. I have a similar config:
mqtt:
  host: 172.16.30.xx
  user: rtlamr
  password: REDACTED

meters:
  # ...

...and am seeing this in the logs:
Meter "xxxx" - Consumption 33792.054. Sending value to MQTT.
...

...but nothing shows up in my MQTT broker. I've verified manually that the IP/port, username, and password all work.

Some more info. I'm monitoring two meters:

Electricity: SCM+ (ID: 1234)
Gas: SCM (ID: 5678)

I patched rtlamr2mqtt.py to output paho-mqtt's DEBUG-logs and saw this:
Meter "51643176" - Consumption 0441.362. Sending value to MQTT.
DEBUG:root:Sending CONNECT (u1, p1, wr0, wq0, wf0, c1, k60) client_id=b'rtlamr2mqtt'
DEBUG:root:Sending PUBLISH (d0, q0, r1, m2), 'b'rtlamr/gas_meter/state'', ... (8 bytes)
DEBUG:root:Sending DISCONNECT

Meter "100583244" - Consumption 33792.124. Sending value to MQTT.
DEBUG:root:Sending CONNECT (u1, p1, wr0, wq0, wf0, c1, k60) client_id=b'rtlamr2mqtt'
DEBUG:root:Sending PUBLISH (d0, q0, r1, m3), 'b'rtlamr/electricity_meter/state'', ... (9 bytes)
DEBUG:root:Sending DISCONNECT
``

Only the electricity meters shows up in my MQTT broker:

![CleanShot 2021-09-09 at 11 58 25@2x](https://user-images.githubusercontent.com/47216/132738180-1c064478-adae-4209-8205-68795121ac33.png)

Hello @bachya , thanks for your time on this!
Are you using mosquitto? Do you have ACLs in place?

@allangood I'm using VerneMQ. It has an ACL enabled by default, but since one meter comes through, I can't imagine that's an issue?

Hi @ponchohoncho , looks like you are running the container in DEBUG mode. In this mode nothing will be sent to MQTT, it will only output meter readings in the screen.
This mode was created to help people to find their meters IDs. From your output looks like it is working as intended.
If you want to run in NORMAL mode, then you have to remove the -e DEBUG=true from your Docker call.

@bachya it really depends on how the ACL is configured. I don't know how VerneMQ handle the ACLs, but on Mosquitto is possible to set ACLs for specific topics like:
user rtlamruser
topic readwrite rtlamr/gas_meter/#

From your message is possible to see the container is trying to send 2 messages.
Could you double check the ACLs?

@allangood Turning the ACL off makes that topic show up, which is good. That said, I don't want to just leave it disabled. I've never had to manually configure user/topic combos in the ACL; why would that start now?

@bachya , I have never used this VerneMQ, so I don't know how to help with this.
On my Mosquitto, I have ACLs for the whole topic, like this:
user rtlamruser
topic readwrite homeassistant/sensor/rtlamr/#
topic readwrite rtlamr/#

With this configuration, the rtlamr user is allowed to send the auto-discover packages to HA and update their status.
Having one single user with RW rights to anything is the same as not having ACLs at all. If security is a concern (what should be), every client should have their own user with rights to specific topics.
You have to read the manual for your MQTT broker to have the right configuration in place.
This cannot be solved anywhere else.

I am closing this as none of them are bug in the code.
Open a new issue or reopen this one if you have further comments.
Thank you for your feedback!

I'm still having an issue with meter readings. I got homeassistant autodiscover messages showing up in Mosquitto, but meter readings aren't coming in. Readings all showed up beautifully when DEBUG was on, but now the docker logs are full of this
listening...
RTLAMR started with PID 29962
Use the device argument 'rtl_tcp=<IP_ADDRESS>:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
bye!
RTL_TCP started with PID 29967
listening...
RTLAMR started with PID 29973
Use the device argument 'rtl_tcp=<IP_ADDRESS>:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
bye!
RTL_TCP started with PID 29977
listening...
RTLAMR started with PID 29983
Use the device argument 'rtl_tcp=<IP_ADDRESS>:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
bye!
RTL_TCP started with PID 29988
listening...
RTLAMR started with PID 29994
Use the device argument 'rtl_tcp=<IP_ADDRESS>:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
bye!
RTL_TCP started with PID 29999
listening...
RTLAMR started with PID 30005
Use the device argument 'rtl_tcp=<IP_ADDRESS>:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
bye!
RTL_TCP started with PID 30010

@ponchohoncho how your configuration looks like and how are you running the container (i.e. the command you used to run the container)?

thanks for your help @allangood ! here's my docker-compose entry
  rtlamr:
    container_name: rtlamr
    image: allangood/rtlamr2mqtt
    restart: unless-stopped
    devices:
      - /dev/bus/usb/001/003
    volumes:
      - ./rtlamr/rtlamr2mqtt.yaml:/etc/rtlamr2mqtt.yaml:ro
    #environment:
    #  - DEBUG=true
    #  - RTL_MSGTYPE="all"

and my rtlarm2mqtt.yaml
# (Optional section)
general:
  # Sleep for this amount of seconds after one successful of every meter
  # Set this to 0 (default) to disable it
  sleep_for: 0

# (Required section)
mqtt:
  host: 192.168.1.xx
  user: myusername
  password: mysecurepass
  ha_autodiscovery: true
  ha_autodiscovery_topic: homeassistant

# (Optional)
custom_parameters:
  rtltcp: "-s 2048000"
  # ***DO NOT ADD -msgtype, -filterid nor -protocol parameters here***
  rtlamr: "-unique=true -symbollength=7"

meters:
  - id: 65xxxx06
    name: meter_electric
    protocol: scm
    unit_of_measurement: kWh
    icon: mdi:gauge
  - id: 38xxxx38
    name: meter_gas
    protocol: scm
    unit_of_measurement: 'ft\uB003'
    icon: mdi:gauge
  - id: 19xxxx71
    name: meter_water
    protocol: scm
    unit_of_measurement: '\33A5'
    icon: mdi:gauge

hassio runs on a vm on another host, and rtlarm2mqtt runs on a docker host running ubuntu. i have a few other containers on this host that do mqtt and sdr (frigate, rtl_433) and they all work, so i know that communication, mqtt, etc all work between the two hosts/networks. i have one sdr device for rtl_433 and another one for rtlamr2mqtt.

@ponchohoncho do you have ACLs on your MQTT broker?

No, no ACLs, just the one user/pass

@ponchohoncho , looks like the process is having problems to open the device.
Could you change the device section of your compose files to:
devices:
      - /dev/bus/usb

Also, does the lsusb command output your USB SDR device?
And last, just to be sure, all those IP, password, username and meters IDs that looks redacted are correct on your configuration?

I think part of the problem is that it's a crapshoot to determine which container gets which device on reboot. I tried specifying the exact usb device ID in the devices part of docker-compose, but that wasn't perfect.
all the IPs, users, pass, etc are correct, just redacted for posting here.
both sdr sticks do show up in lsusb and rtl_test on the host. i have used the -d flag on rtl_433 to have it select a specific stick. i'll see if I can use custom_parameters to pass the -d flag to rtl_tcp in your container.
I think that this is an issue on my end with one container or the other not being able to use the hardware it wants. i'll keep messing with it.
it would be very helpful if there were more error messages caught from the underlying programs (paho-mqtt, rtl_tcp, rtlamr, etc) and passed up into your container's logs to debug things like this.
I think that your current DEBUG mode is more like a "discovery" mode, one to help someone narrow down what devices are available, their IDs, protocols, etc. the discovery mode wouldn't care about mqtt settings because it's not sending anything in. a discovery mode is super super helpful.
a real DEBUG mode would do everything the normal mode does (send to mqtt, autodiscover, fully parse all the yaml), just with more verbose info and errors, I think.

even when i take down rtl433, and make sure that nothing is using either sdr stick, and rtlamr can take its pick of free devices to use, I still now get a log full of
RTLAMR started with PID 47
Use the device argument 'rtl_tcp=<IP_ADDRESS>:1234' in OsmoSDR (gr-osmosdr) source
to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...).
bye!

rtl_tcp or rtlamr is not liking something that's being passed to it

@ponchohoncho , I agree the output could be more verbose. I am going to add a new verbose option to the configuration to address this.
Also, I need to handle better errors. I did the project initially just for myself and just assumed everything is working.
You can try this to debug the problem:
docker exec -ti rtlamr2mqtt /bin/ash

This will give you a shell inside the container. From there, you can execute:
rtl_tcp &
rtlamr -msgtype=scm+

@ponchohoncho , every time your machine reboots, a big probability of your USB devices would be associated with different USB devices. A way to fix this is to use udev rules.
With the right udev rule you can "pin point" one device with a specific /dev/ file

When I open a shell into rtlamrmqtt and run rtl_test, I see both USB sticks there. I have rtl_433 using the nesdrv4 with the "-d1" flag. but when I try to run "rtl_test -d 0", to use the stick I've designated for rtlamr2mqtt, I get this:
Found 2 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: rtlsdrv3pro
  1:  Realtek, RTL2832UHIDIR, SN: nesdrv4

Using device 0: Generic RTL2832U OEM
usb_claim_interface error -6
Failed to open rtlsdr device #0.

isn't this because the container is already using it?
ps shows me this
/tmp # ps
PID   USER     TIME  COMMAND
    1 root      0:00 python3 /usr/bin/rtlamr2mqtt.py
  425 root      0:00 /bin/ash
 1084 root      0:00 /usr/bin/rtl_tcp -d 0 -s 2048000
 1090 root      0:00 ps

i can't kill the rtl_tcp process because it's constantly dying and restarting. killing python3 drops me out of that shell.
I added the -d 0 flag in rtltcp commands in rtlamr2mqtt's config yaml. since rtl_tcp would try 0 default anyways, i get the same results i've been getting either way.
Thanks so much for your help through all of this!

@ponchohoncho , yes, if you kill any of the process, the python script will spawn a new one. One way to work around this is setting the sleep_for parameter with something > 0. This will give you that amount of seconds to kill those process.
Looks like all problems you are facing is because of these 2 antennas and the USB "mess".
In this case, having udev rules is highly recommended.

ok, I'm back with my learnings. In short, with rtl_sdr in docker, udev rules don't matter. what you pass in via docker devices is not the same as what librtlsdr sees, and librtlsdr doesn't understand when it tries to use the first available sdr device listed, but can't due to docker device permissions.
librtlsdr chooses a device based on the device index, and can't be told to pick a device based on a serial number or udev name. lsusb and rtl_test see all sdr devices plugged into the host, but only have permission to talk to the ones passed in via the device flag in docker run/compose.
there's decently in-depth conversation about it here: https://forums.balena.io/t/mount-specific-usb-into-each-container/5651
imagine a docker setup like this. two containers that use rtl_sdr, and two sdr devices. let's imagine that in rtl_test, you see that the device on 001/002 is listed as device 0, and 001/003 is listed as device 1.
rtlamr:
    devices:
      - /dev/bus/usb/001/002 #device 1
rtl433:
    devices:
      - /dev/bus/usb/001/003 #device 0

if you run lsusb in both containers, you will see both sdr devices listed. but if you try to use rtl_test -d 1 in rtlamr, it'll give you an error because it doesn't have the permissions to use that device.
so it comes down to knowing which device is listed as which index, and then using the -d flag in each container to assign a device to that container, while passing /dev/bus/usb to each container.
where i think i got most tripped up is that in DEBUG/LISTEN mode, your container ignores the rtl_tcp flags in the yaml, so I thought I was specifying -d 1, when it was using -d 0 by default, and it couldn't use -d 0 because either it didn't have permissions as per the device flags, or because the other rtl container was already using it.
i have it all running now happily, and it's sending my meter readings to HA via MQTT, and rtl_433 is using the other device and all is right with the world. my only suggestion would be to allow the specifying of rtl_tcp flags that are used in regular, listen, and debug modes, so we can specify which device index to use for the container as a whole regardless of the mode.
thank you so much for making such a great container, listening to everyone's feedback, and being so quick with the fixes!


Add support for new Translate languages

New languages for Amazon Translate: Greek, Hungarian, Romanian, Thai, Ukrainian, Urdu and Vietnamese

Fixed in https://github.com/awslabs/aws-media-insights-engine/issues/61


fix(schema.mustache): table down() function comment

changed "alternations" to "alterations"

Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[x] Lint and unit tests pass locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works.
[x] I have added necessary documentation (if appropriate)

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

Coverage remained the same at 48.438% when pulling 3b78196992b2254f1c6b2ab5b68ff9c59f00627c on un-versed:patch-1 into 1e698919332d65e629b73a0ea8a800274e9e1cf1 on adonisjs:develop.


[explicit-member-accessibility] Remove rule

This rule does not have an automatic fix, so applying it to a new codebase requires large amounts of manual intervention.
Plus, it goes against the Standard.js style. All class members are public by default, so there is no reason to write this explicitly. Standard.js tends to remove things that the language infers automatically like semicolons or useless constructors, so requiring public everywhere seems counter to this philosophy. It also makes the code look less Javascript-ish, since plain ES6 classes doesn't even have accessibility declarations.

I agree.
The benefit that I found is that it compels the writer to decide the accessibility for each member. And where members would be "neglected" as default, the writer would likely use more restrictive specifiers on some of them, when "forced" to.
Yes, it does go a long way from JS, but this is TypeScript and here's an opportunity to decide on good practices.
Migrating to a rule set usually involves some manual intervention. This can have a large impact, yes. Is it worth it? Does it improve the code? I feel that it does. And how many lines would break in a project? I haven't done any class based development in TypeScript, so I'm not experienced enough to understand the weight of this rule.
@LinusU?

Standard.js tends to remove things that the language infers automatically like semicolons or useless constructors, so requiring public everywhere seems counter to this philosophy.

I kind of feel like this as well. In face, I think that I would prefer a rule that forced you to not have public since that is the default.

And the benefit that it compels you to decide on member accessibility—what about that? Doesn't that offer value? Wouldn't it result in your code ending up more reliable, because you set some members as not public? Wouldn't it be prudent of as as developers to use all of the means available to better our code? Wouldn't this rule be one such mean? Yet, if it is so bothersome that it is impractical, it should not be in Standard. I understand that.

And the benefit that it compels you to decide on member accessibility—what about that?

That would be like saying we should use semicolons, because they "compel you to decide where lines end". Standard.js users don't need semicolons, though - we quickly learned the implicit line-ending rules when we started. After that, line ending is natural and obvious, and semicolons are just extra noise.
Likewise, members are public unless you say otherwise. Omitting the accessibility specifier is making a clear choice - it's a choice for public. Typing redundant keywords offers no real benefit once you get used to the language rules.

With line endings, there is no decision to be made. You only ever mean one thing. You always know where you mean to end the line. There is no decision to make.
Member accessibility is different, because it's about making a decision regarding the accessibility of a member of a class. There is a decision to make.
So the comparison between the two above as a response to the benefit of the rule forcing a decision is irrelevant, because in ASI there is no decision to be made.
In member accessibility, forcing a decision by forcing to explicitly define, does force a decision, and that means that the developer was forced to make that decision. That feels like a benefit to me, as it could produce better code, as private and protected increase the type safety of the code. Let's take at the very least the example of the developer who doesn't even know about the accessibility modifiers—wouldn't it have educational and code result benefit in his case?
I'm not saying it's clearly worth the extra work, though. I'm quite thorough and so I'd probably go along with it, but this is a public library and so I'd like to get some more feelings here than me and you two. And I'd like you to address this, please. Even if just by stating that you feel it's not worth it.

Let's take at the very least the example of the developer who doesn't even know about the accessibility modifiers—wouldn't it have educational and code result benefit in his case?

Ah, I see what you are saying. I usually assume that developers know the rules and use them to their advantage. An experienced developer will naturally use private and protected everywhere possible, since stable public API's require a lot of extra work. Meanwhile, a truly bad developer will just type public everywhere because that's the fastest way to "make the errors go away."
You aren't worried about these two groups. Instead, you want to encourage good habits in more mid-level developers. I see how this rule could have benefits for that group.

I'm not saying it's clearly worth the extra work, though. [...] And I'd like you to address this, please. Even if just by stating that you feel it's not worth it.

I could live with this rule if it were auto-fixable, but it's not. My day job is a React Native project with several hundred classes and a few thousand members, so fixing things manually would be quite expensive. Other projects moving to Standard.js + TypeScript would have the same problem.
The Standard.js change log gives an estimate of how many projects each new rule would affect, based on the official test suite. I don't think the test suite contains any TypeScript projects, though. If it did, my guess is that this rule would affect close to 100% of projects that aren't already using it. It's a very common pattern.
Between the manual fix and broad reach, I don't think this rule is worth it. If a bunch of people feel strongly that this rule should stay, making it auto-fixable ould be a high priority.

Thank you for your input @swansontec. I truly appreciate it.
I can imagine this being auto-fixable. Yet, with some caveats. Expecially regarding importable projects, where it could not be analyzed whether the member is meant to be publicly used or not.
Let's remove the rule.


Mismatch between number of columns produced by 'SHOWGRANTS' and the number of aliases specified

I get this error when trying to upload a table to snowflake.
I've been using excelerator for over a year and this is the first time this has happened and I don't think there have been any changes in what I've been doing.
ERROR: Error:
SQL Compilation error:
Mismatch between number of columns produced by 'SHOWGRANTS' and the number of aliases specified

I have the same issue today - from my investigation it looks like Snowflake might have added another column to the returning result set from the show grants command. The query generated by Excelerator specifies the expected columns, but the result of the command produces an additional column so it doesn't know what to do with it and errors out, causing Excelerator to roll back the upload. I'm going to try to find where that query is generated in the VBA. It would be great if the developer would share a fix that could be "pasted in" as I have a couple minor modifications I would prefer not to re-create.

Screenshot of what I added to my version of the VBA code attached. It worked for me, but please note I am not a developer for this add-in, so I don't know of any possible side-effects (I don't expect any). Just a guy who has benefited from many people posting useful stuff on the internet.
The function requiring modification is under the "Load" Module.

I actually realized later that the upload was actually successful - still
getting the error message but when I check the updated table is indeed in
snowflake.
On Fri, Apr 21, 2023 at 2:07 PM mherman-amd @.***>
wrote:

I have the same issue today - from my investigation it looks like
Snowflake might have added another column to the returning result set from
the show grants command. The query generated by Excelerator specifies the
expected columns, but the result of the command produces an additional
column so it doesn't know what to do with it and errors out, causing
Excelerator to roll back the upload. I'm going to try to find where that
query is generated in the VBA. It would be great if the developer would
share a fix that could be "pasted in" as I have a couple minor
modifications I would prefer not to re-create.
—
Reply to this email directly, view it on GitHub
https://github.com/Snowflake-Labs/Excelerator/issues/38#issuecomment-1518173214,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALZ5INEPJ3UOEZL7ZHDXS5LXCLEGPANCNFSM6AAAAAAXG464FM
.
You are receiving this because you authored the thread.Message ID:
@.***>

I actually realized later that the upload was actually successful - still getting the error message but when I check the updated table is indeed in snowflake.
…
On Fri, Apr 21, 2023 at 2:07 PM mherman-amd @.> wrote: I have the same issue today - from my investigation it looks like Snowflake might have added another column to the returning result set from the show grants command. The query generated by Excelerator specifies the expected columns, but the result of the command produces an additional column so it doesn't know what to do with it and errors out, causing Excelerator to roll back the upload. I'm going to try to find where that query is generated in the VBA. It would be great if the developer would share a fix that could be "pasted in" as I have a couple minor modifications I would prefer not to re-create. — Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZ5INEPJ3UOEZL7ZHDXS5LXCLEGPANCNFSM6AAAAAAXG464FM . You are receiving this because you authored the thread.Message ID: @.>

Ok, for me the table was there but it didn't actually contain the updates. I assume that's because the default behavior or Excelerator is to try to swap back the original data when it encounters an error.

@mherman-amd & @stephenchen408
Thank you guys for hunting this down. You are right, there was a new column added to the GRANTS_TO_ROLES view, which this leverages.
https://docs.snowflake.com/en/release-notes/2023-03-bcr
Your fix looks good, but I would actually prefer the change to specify the columns explicitly instead of using the 'SELECT *'. I should never have relied on that in the first place. Poor design.
So the change to the SQL would look like this:
(select 'created_on','privilege','granted_on','name','granted_to','grantee_name','grant_option','granted_by','granted_by_role_type' from  table(result_scan(last_query_id())))
I'm actually not sure if the new column 'granted_by_role_type ' is needed. I'm not able to test it currently. Would you try with and without this last column?
This columns is part of a new Snowflake feature that some accounts have turned on and some do not.
If it works without the new column then that is preferable since it will work in accounts with this turned on or off.
Please let me know how it goes.
Thanks.
Steve

So this error seemed to have resolved itself - I didn’t change anything and
the next day everything was back to working normally.
On Sun, Apr 23, 2023 at 9:02 PM Steven Segal @.***>
wrote:

@mherman-amd https://github.com/mherman-amd & @stephenchen408
https://github.com/stephenchen408
Thank you guys for hunting this down. You are right, there was a new
column added to the GRANTS_TO_ROLES view, which this leverages.
https://docs.snowflake.com/en/release-notes/2023-03-bcr
Your fix looks good, but I would actually prefer the change to specify the
columns explicitly instead of using the 'SELECT *'. I should never have
relied on that in the first place. Poor design.
So the change to the SQL would look like this:
(select
'created_on','privilege','granted_on','name','granted_to','grantee_name','grant_option','granted_by','granted_by_role_type'
from table(result_scan(last_query_id())))
I'm actually not sure if the new column 'granted_by_role_type ' is needed.
I'm not able to test it currently. Would you try with and without this last
column?
This columns is part of a new Snowflake feature that some accounts have
turned on and some do not.
If it works without the new column then that is preferable since it will
work in accounts with this turned on or off.
Please let me know how it goes.
Thanks.
Steve
—
Reply to this email directly, view it on GitHub
https://github.com/Snowflake-Labs/Excelerator/issues/38#issuecomment-1519231303,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALZ5INCPKD4J4DIJTPOPXE3XCXGKPANCNFSM6AAAAAAXG464FM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Maybe that new feature was disabled for now. It might come back, so let me know.

We had to manually alter showgrants code as well. For future changes sake we decided to hardcode only necessary columns:
sql = "with ShowGrants (privilege,granted_to,grantee_name,grant_option,created_on) as " & _
    "(select " & Chr(34) & "privilege" & Chr(34) & ", " & Chr(34) & "granted_to" & Chr(34) & ", " & Chr(34) & "grantee_name" & Chr(34) & ", " & Chr(34) & "grant_option" & Chr(34) & ", " & Chr(34) & "created_on" & Chr(34) & " from  table(result_scan(last_query_id()))) " & _

@ssegal100, it looks like the granted_by_role_type came and went in Snowflake somehow (maybe someone was changing our account settings? and then I got the same error again when I was looking for it in the VBA query), so I updated my add-in version to remove the reference (it couldn't have been required previously) and changed the "select *" from the next line to explicit column references, now working again.


fix(ingestion/glue): Add support for missing config options for profiling in Glue

Summary:

Glue Source Profiling Configuration:

Configuration parameters include:

enabled: Flag to enable or disable profiling (default: false).
profile_table_level_only: Flag to enable profiling at the table level only, excluding column-level profiling (default: false).
max_workers: Number of worker threads to use for profiling, defaulting to 5 times the CPU count.

Test Cases:

Added new test cases for Glue source to verify the new profiling configuration.
Ensured that existing Glue source test cases are compatible with the new configuration.

Documentation Update:

Updated the updating-datahub.md file to document the breaking change related to the profiling configuration for Glue source under the "Breaking Changes" section.

QA:

Validated the change locally to ensure its working as expected

Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Summary by CodeRabbit
Summary by CodeRabbit

New Features

Introduced profiling support for AWS Glue data ingestion, including options to enable profiling and restrict it to table-level only.

Improvements

Simplified profiling logic for enhanced readability and efficiency.

Tests

Added comprehensive test cases to validate profiling functionalities within the AWS Glue data ingestion module.

Failure in airflow unrelated


[GPII-3624]: Fixes for CouchDB split brain issues

This PR contains changes to CouchDB chart required for patched stateful set assembler (https://github.com/gpii-ops/couchdb-statefulset-assembler/pull/1).
Deployment of this will require short downtime, because changes to stateful set causes K8s to restart all running pods (during my tests 14 of 10k requests to preferences failed with 404, 1 request failed with 503, and about 100 requests took more than 3 seconds to complete).
Deployment plan will be in the ticket.

LGTM
(Deploy plan not available when I reviewed this.)

I am planning to deploy this together with #450
Deployment plan is in GPII-3341.

LGTM


Upgrade react-table to the newest version

React table was completely rebuilt and version 8 should have lots of breaking changes.

https://github.com/TanStack/table/issues/4241 is pretty much a blocker for upgrading at the moment. It's the first step in recreating the table with version 8 and there is already a problem.

Still hitting the same problem and does not seem like I'm the only one. Putting this back on ice.

@sroy3 when you get back, let's please review and see if it's still blocked

Seems like the previous errors are no longer shown. It isn't blocked anymore. It should take a little while to convert everything since there is no documentation for upgrading and everything looks very different, it'll be easier to rebuild everything from scratch (while using the old code as reference).

Congrats @sroy3 🎉 :) Great effort.


Suggestions for QoL Improvements in development

Suggestions:

[ ] A Contributors.md to detail layout of the codebase and where things belong.
[ ] Upgrade to Typescript to support types or remove Typescript types in src/components/history.js.
[ ] Add a utils folder for process reuse-ability. JsonRPC/WS stuff is a good example of this: They're pretty standard in how they're conducted, so it could be beneficial to create a /utils/networkCalls module for re-use across providers/chains. Next time you need it, you can just import and re-use with a networkCalls.getAddressBalance( provider, address ) or something like that
[ ] Remove console.log()'s in production. Maybe replace with Debug for development env?
[ ] Stop routing based on pathname length

If I think of others, i'll add them :-)

I created separate issues for this list. We'll add them to sprints eventually. Thanks for your input!

A Contributors.md to detail layout of the codebase and where things belong.

#202

Add a utils folder for process reuse-ability. JsonRPC/WS stuff is a good example of this: They're pretty standard in how they're conducted, so it could be beneficial to create a /utils/networkCalls module for re-use across providers/chains. Next time you need it, you can just import and re-use with a networkCalls.getAddressBalance( provider, address ) or something like that

There's currently two design documents, that propose solutions to this:

https://docs.google.com/document/d/1GtS_NxhxSt9XVTphp4fWRvjeQjIVT8WbYsqpKAlWbfE
https://github.com/leapdao/burner-wallet/issues/109

Feedback welcome :)

Remove console.log()'s in production. Maybe replace with Debug for development env?

IMO this is not too big of an issue at this point. Bigger fish to fry.

Stop routing based on pathname length

#194. Will soon be fixed.
Closing this for now. Feel free to reopen.


Explorer took >90s to display

Describe the bug
Cross-chain claiming flow we link the user to explorer
https://testnet.connextscan.io/tx/0x6dd69cd8381b2e893db90a75859bdb7f59324b57f0708229122b14521015d7d5
I saw a 404 error for an extremely long time. This delay is not really acceptable because we link the user immediately to Explorer to track their transfer.
Private Zenhub Image
Private Zenhub Image

updated: https://github.com/CoinHippo-Labs/connextscan-ui/pull/86


Transactions

Hi there!
Cool library. I was wondering how transactions affect the query cache - Do query results get cached immediately or only after successful transaction commit. Wondering if it introduces dirty reads and/or phantom reads.

It there is an "insert ", "update ", "delete " or "create " in your intercepted query, the related cache item will be invalidated automatically.

What about the following scenario?
using(var txn = new dbContext.Database.BeginTransaction())
{
   // Read and modify an entity
   var entity = dbContext.SomeEntities.First();
   entity.Name = "FOO";

   // Save the change, cache will be invalidated
   dbContext.SaveChanges();

   // Read the same entity, this will get cached with name "FOO"
   entity = dbContext.SomeEntities.First();

   // Call some method
   // THIS METHOD THROWS AN EXCEPTION SO THE TRANSACTION IS NEVER COMMITTED
   DoSomeWork(entity);

   // (we never hit these lines, so the cache is not invalidated and the transaction is not committed)
   dbContext.SaveChanges();
   txn.Commit();
}

Unless I am mistaken, the entity will now be cached with name "FOO", which is incorrect since that change was never actually committed to the database.

which is incorrect
Why? There's no harm in it, because it's a reflection of your actual db. Next time you call dbContext.SomeEntities.First(), it will be faster.

In my sample code that change to "FOO" would never be committed to the physical database because the transaction was never committed, so the cached version would be out of sync with the database

It's not.

The name "FOO" will not be in the cache?  Note that this change would only be written to the database if the transaction is successfully committed, but because DoSomeWork() throws an exception, we never commit the transaction so the name of "FOO" is not written to the DB (the transaction will roll back).

dbContext.SomeEntities.First() will call your db, not your in-memory context. It's not a LINQ to Objects query.

Inside the transaction when I call dbContext.SomeEntities.First() it will return the entity with name "FOO", even though it is not physically committed to the database yet.  It will only get physically written to the database when the transaction is committed, but inside the transaction EF will still return the pending state.

To demonstrate the issue, assume this.context.SomeEntities.First() returns an entity with name "BAR"
            using (var txn = this.context.BeginTransaction())
            {
                // query, modify, and save
                var temp = this.context.SomeEntities.First();
                temp.Name = "FOO";
                this.context.SaveChanges();

               // query again
               temp = this.context.SomeEntities.First();

                // Do not commit txn
            }

Without caching enabled, in a subsequent request when I call this.context.SomeEntities.First() I get entity with name "BAR" (correct - matches physical DB).
With caching enabled, in a subsequent request when I call this.context.SomeEntities.First() I get entity with name "FOO" (incorrect - does not match physical DB).
This is indeed a great library btw!  Just a nuance we need to watch out for.

To work around this issue in our project, we simply suppress caching when there is an open transaction.  For us, missing out on some caching is less severe than having cached data which is out of sync.
To accomplish this we have implemented an interceptor which wraps the SecondLevelCacheInterceptor and only invokes it when command.Transaction is null, otherwise we call down to the base.
I have attached the sample code for others who would like to take a similar approach.
TransactionFixInterceptor.txt


bluez-firmware-rpidistro: update bluez-firmware

Latest bluez-firmware release updates BCM4345C0.hcd to
<IP_ADDRESS>6.0280, restoring LE scan capability.
Signed-off-by: Ricardo Salveti<EMAIL_ADDRESS>

Can one of the admins verify this patch?

@jenkins-ag ok to test


[ReferenceError: localStorage is not defined] <Whenever coinbaseWallet is used in custom wallet list>

Is there an existing issue for this?

[X] I have searched the existing issues

RainbowKit Version
^2.0.0-beta.6
wagmi Version
^2.5.17
Current Behavior
Whenever coinbaseWallet is used in the custom wallet list, below error will come up:
ReferenceError: localStorage is not defined
    at ScopedLocalStorage.setItem (webpack-internal:///(ssr)/./node_modules/@coinbase/wallet-sdk/dist/lib/ScopedLocalStorage.js:12:9)
    at new CoinbaseWalletSDK (webpack-internal:///(ssr)/./node_modules/@coinbase/wallet-sdk/dist/CoinbaseWalletSDK.js:42:23)
    at Object.getProvider (webpack-internal:///(ssr)/./node_modules/@wagmi/connectors/dist/esm/coinbaseWallet.js:77:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async reconnect (webpack-internal:///(ssr)/./node_modules/@wagmi/core/dist/esm/actions/reconnect.js:54:27)
ReferenceError: localStorage is not defined
    at ScopedLocalStorage.setItem (webpack-internal:///(ssr)/./node_modules/@coinbase/wallet-sdk/dist/lib/ScopedLocalStorage.js:12:9)
    at new CoinbaseWalletSDK (webpack-internal:///(ssr)/./node_modules/@coinbase/wallet-sdk/dist/CoinbaseWalletSDK.js:42:23)
    at Object.getProvider (webpack-internal:///(ssr)/./node_modules/@wagmi/connectors/dist/esm/coinbaseWallet.js:77:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async reconnect (webpack-internal:///(ssr)/./node_modules/@wagmi/core/dist/esm/actions/reconnect.js:54:27)
 ✓ Compiled /favicon.ico in 4.5s (2309 modules)
 ⨯<EMAIL_ADDRESS>(12:0) @ ScopedLocalStorage.setItem
 ⨯ unhandledRejection: ReferenceError: localStorage is not defined
    at ScopedLocalStorage.setItem (webpack-internal:///(ssr)/./node_modules/@coinbase/wallet-sdk/dist/lib/ScopedLocalStorage.js:12:9)
    at new CoinbaseWalletSDK (webpack-internal:///(ssr)/./node_modules/@coinbase/wallet-sdk/dist/CoinbaseWalletSDK.js:42:23)
    at Object.getProvider (webpack-internal:///(ssr)/./node_modules/@wagmi/connectors/dist/esm/coinbaseWallet.js:77:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async reconnect (webpack-internal:///(ssr)/./node_modules/@wagmi/core/dist/esm/actions/reconnect.js:54:27)
null
 ⨯<EMAIL_ADDRESS>(12:0) @ ScopedLocalStorage.setItem
 ⨯ unhandledRejection: ReferenceError: localStorage is not defined
    at ScopedLocalStorage.setItem (webpack-internal:///(ssr)/./node_modules/@coinbase/wallet-sdk/dist/lib/ScopedLocalStorage.js:12:9)
    at new CoinbaseWalletSDK (webpack-internal:///(ssr)/./node_modules/@coinbase/wallet-sdk/dist/CoinbaseWalletSDK.js:42:23)
    at Object.getProvider (webpack-internal:///(ssr)/./node_modules/@wagmi/connectors/dist/esm/coinbaseWallet.js:77:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async reconnect (webpack-internal:///(ssr)/./node_modules/@wagmi/core/dist/esm/actions/reconnect.js:54:27)
null

No error if coinbaseWallet is not included in the list.
Expected Behavior
No error
Steps To Reproduce
Step 1: Initiate project using yarn create @rainbow-me/rainbowkit
Step 2: edit pages/_app.tsx file to change default setting to custom wallet list including coinbaseWallet
Step 3: npm run dev
Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
https://codesandbox.io/p/github/linghuccc/rainbowkit-test/master
Anything else?
It is an existing project and there used to be no error about 3 weeks back. The error came to emerge recently when I pick up my previous work.

@linghuccc Add ssr: true to your createConfig or getDefaultConfig function.

@linghuccc Add ssr: true to your createConfig or getDefaultConfig function.

You are the best, man!

@linghuccc Add ssr: true to your createConfig or getDefaultConfig function.

You are the best, man!

But When I added ssr:true to the config,the rainbow wallet show less wallet than I configured. I'm using NextJs 14 pages router, not app router

@HappySean2845 Can you try updating your wagmi version to 2.5.22 ? There were some issues with pervious wagmi versions not showing all rainbowkit wallets.

@HappySean2845 Can you try updating your wagmi version to 2.5.22 ? There were some issues with pervious wagmi versions not showing all rainbowkit wallets.

It works! Great appriciate!


Checklist for 2021.02 (and 2021.02.1)

Additions:

[ ] Add support of the is implementation-detail trait
for classes and roles -4384fc5c
[ ] Introduce support for passing multiple time units
to earlier and later methods on Dateish -8a1f8f6f-10dea6ef
[x] Add "Solaris" option to the list returned by KERNELnames
method on $*RAKU -f918f0fd
[ ] Introduce the slice method on Seq accepting indices
(e.g. @a.Seq.slice(0, 2 ... *)) -63be83d3
[ ] Implement Map method on QuantHash -110343d2

Changes:

[x] Add a way to set arg0 (when specified, passed as first argument
to the process instead of the program name) for Proc objects -ce124551
[x] Return to REPL implementation prior to 2020.12 release -d53a9273-39103199
[x] Move to CentOS 7 in binary release GNU/Linux build -38e69d87
[ ] Provide single argument semantics for assigning
a QuantHash to an Array object -6cd50ab2
[ ] Conversion of a Str object to Enum now returns a
Failure object wrapping an X::Enum::NoValue instead
of returning the enum's type object
-e3a0c32d-28b95813-184079c9-5bc394f6-bcb9a2c9-e44b524e
[ ] Module installing at sorting now prefers API sorting over version sorting -43613ac5
[ ] Implement the item method for QuantHash and Capture types -8f6c7fe7
[x] Throw a proper NYI error on attempt to parametrize a Hash with native types -5aec4aaa

One of the commits moves earlier and later to base role. Opened #3848 for that.

Everything's now checked (lizmat++), closing.


Add Zipformer Onnx Support

Adding onnx support to pruned_transducer_stateless7 export.py
Adding torch.onnx.is_in_onnx_export to unsupported operations
Adding torch pretrained script
Adding onnx test

I will add test to here

Hi, @csukuangfj could you check below part if it is correct or not? Now, model can only recognize when num_frame can be divided by 4.
https://github.com/k2-fsa/icefall/blob/d40e8b9f25adea99ff98d854b01211f56caaacc2/egs/librispeech/ASR/pruned_transducer_stateless7/zipformer.py#L1261-L1280
For example , features = torch.rand((1, 448, 80)) is running without a problem , but features = torch.rand((1, 446, 80)) gives below error:
---------------------------------------------------------------------------
RuntimeException                          Traceback (most recent call last)
<ipython-input-5-1f3f4dd04d88> in <module>
      2 encoder_out_nodes = encoder.get_outputs()
      3
----> 4 encoder_out, encoder_out_lens = encoder.run(
      5     [encoder_out_nodes[0].name, encoder_out_nodes[1].name],
      6     {

~\AppData\Roaming\Python\Python38\site-packages\onnxruntime\capi\onnxruntime_inference_collection.py in run(self, output_names, input_feed, run_options)
    198             output_names = [output.name for output in self._outputs_meta]
    199         try:
--> 200             return self._sess.run(output_names, input_feed, run_options)
    201         except C.EPFail as err:
    202             if self._enable_fallback:

RuntimeException: [ONNXRuntimeError] : 6 : RUNTIME_EXCEPTION : Non-zero status code returned while running Reshape node. Name:'Reshape_1310' Status Message: D:\a\_work\1\s\onnxruntime\core\providers\cpu\tensor\reshape_helper.h:41 onnxruntime::ReshapeHelper::ReshapeHelper gsl::narrow_cast<int64_t>(input_shape.Size()) == size was false. The input tensor cannot be reshaped to the requested shape. Input shape:{219,1,384}, requested shape:{110,2,1,384}

Mentioned Reshape_1310 is here:
https://github.com/k2-fsa/icefall/blob/d40e8b9f25adea99ff98d854b01211f56caaacc2/egs/librispeech/ASR/pruned_transducer_stateless7/zipformer.py#L792

I guess the problem is that onnx model cannot do padding here
Mentioned Reshape_1310 is here:
https://github.com/k2-fsa/icefall/blob/d40e8b9f25adea99ff98d854b01211f56caaacc2/egs/librispeech/ASR/pruned_transducer_stateless7/zipformer.py#L785-L794

I fixed. I just changed here
https://github.com/k2-fsa/icefall/blob/d40e8b9f25adea99ff98d854b01211f56caaacc2/egs/librispeech/ASR/pruned_transducer_stateless7/export.py#L254
from
x = torch.zeros(1, 100, 80, dtype=torch.float32)
x_lens = torch.tensor([100], dtype=torch.int64)

to
x = torch.zeros(1, 101, 80, dtype=torch.float32)
x_lens = torch.tensor([101], dtype=torch.int64)

So, during exporting onnx, tracing method can trace if condition loops.

I will commit and also add onnx_check.py and request a review in a few days.

Thanks! Will merge after CI passes.

Hi, @EmreOzkose , can this PR support onnx export for streaming zipformer in pruned_transducer_stateless7_streaming ?

can this PR support onnx export for streaming zipformer in pruned_transducer_stateless7_streaming?

Hi @kobenaxie , I am not sure if streaming_forwards are exportable to onnx, I haven't tried.


Update to TTK v1.1.0

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

hi @lhofmann
thanks a lot for the PR!
your edits look fine with me!
I am not sure what is going on with the CI.
it's complaining about a (sort-of) MPI dep on ttkAlgorithm (DIY).
it looks like MPI is enabled in TTK but not in paraview??!! is that possible?
either way, I'd suggested to disable MPI for the anaconda package (TTK_ENABLE_MPI=OFF).
what do you think?

It looks like the commit below introduced a dependency to VTK::FiltersParallelDIY2, but this module should only be linked if MPI is enabled.
I have added a patch here which removes this for now.
https://github.com/topology-tool-kit/ttk/commit/4baa7ce431fcd769d1ffe6648dc233ea72cc21af


SIMD-acceleration for f16 with AVX2 and AVX-512

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


Create a Video Transcription app

Duplicate of https://github.com/Call-for-Code/Solution-Starter-Kit-Education-2020/issues/3


enable dependabot for GitHub actions

This allows to get updates for GitHub actions automatically. I have used this for my own packages, the Trixi.jl framework, and the SciML organization. After merging this, you could also enable other Dependabot actions in 'Settings -> Code security and analysis -> Dependabot alerts' and '... -> Dependabot security updates'.
See https://github.com/SciML/MuladdMacro.jl/pull/37

Hey @ranocha , I don't know dependabot and have never used it. What kind of benefit does it provide? Which problem does it solve that has arisen (for you or others) on the repository of OSMMakie.jl? Thanks for any insights.

See for example https://discourse.julialang.org/t/psa-use-dependabot-to-update-github-actions-automatically/96001/2:
To be more specific, you can see Dependabot as an anlog of CompatHelper for GitHub actions dependencies such as actions/checkout@v2. Based on semver, you will not use actions/checkout@v2 with this setup. Dependabot will create a PR updating such a line to actions/checkout@v3. This will fix deprecation warnings such as
Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16:
actions/checkout@v2, actions/cache@v2, codecov/codecov-action@v2.
For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.

That's handled by updating the GitHub actions mentioned there to there new major version - which dependabot will do for you by submitting PRs. See also https://github.com/JuliaArrays/TiledIteration.jl/pull/42

Bumo


Full screen map has dragging issues

This seems to only happen when floating visualizations are open. I suspect it might be some kind of circular state (something coming back from the saved user analysis?) but I can't see an obvious culprit.
To reproduce (in fsm-all)

open FSM
put up a barplot
move the map
shortly after the barplot has finished updating, drag the map again
you should see the map jump back to where you started dragging (and the barplot will update again)

Tested also with boxplot - same issue (and assume same for all)

Also, try cancelling the overlay variable (top right panel) at step 4 instead of dragging the map.  That also gets reset.
Wait a few seconds first and it's fine.

No dragging issues seen.


APIv2: SelectByTextCommand and t.selectByText

Seems like we will need to use a little bit different machinery for this one to make it work in raw API (dedicated factory and executor)

t.selectByText(regExpOrString, n = 0)
SelectorByText(regExpOrString) or Selector.byText(regExpOrString)
Nth element selector:
t.selectNth(selector, n =0, deps, opts) or we can just add additional parameter to t.select
\cc @DevExpress/testcafe What do you guys think?

Selector.byText(regExpOrString, n = 0)
Selectron.nthOfType(selector, n = 0, deps, opts)

t.select
t.selectByText
t.selectText
Which is the odd-one-out?

We've decided to rename t.select so we have:
t.selectNode
t.selectNodeByText

OK, so we have:
Selector.byText(regExpOrString, idx, scopeVars)
Selector.nthOfType(fn, idx, scopeVars)
t.selectNodeByText(regExpOrString, idx, scoperVars, opts)
t.selectNthOfType(fn, idx, scoperVars, opts)

One more:
Selector -> SelectFunction (like ClientFunction)

SelectByTextFunction

BTW, regarding text selector, after a little dog fooding I found out that it extremely useful to specify additional selector for text and then filter it's results by text, so here is how it might look like:
Selector.byText(fn, textFilter (re or string), index)
or
Selector.byText(regExpOrString, subsetSelector, index)
Here is how it will be used:
Selector.byText('li.items', 'Honda', 0);

// or

Selector.byText('Honda', 'li.items', 0);

\cc @DevExpress/testcafe

I prefer the second, because I expect the text argument to be first in the byText function. And can I write Selector.byText('Honda') in this case if I want to find an element by text only (without selector)?

Or as a third option we can have compound signature for selector:
Selector(fn, textFilter, n, scopeVars)

and we will not need additional functions then.

ohh, I've nearly documented all this stuff...
okay, so I stop updating documentation until we have a release version finalized.
Once we finalize it, allow a few days for docs to be updated accordingly.

@VasilyStrelyaev What would you say about proposal?

I prefer the last one (3rd) option

OK, so we will have:
Selector(fn, textFilter, index, scopeVars)
// and
t.select(fn, textFilter, index, scoperVars, options)

I'm thinking about host object for textFilter, index and scopeVars, so we will have:
t.select('li.item', { withText: 'Honda' })

Any ideas how to name such object?

I predict that question will arose about difference between options object and such host object (let's name it initOptions for now). options specifies optional things, selector will function without them, they just adjust some aspects of behavior. Meanwhile initOptions describes selector itself, it's not an adjustment of the options it's a part of selector definition.

One more question: how we should behave if selector fn returns single element and we have index specified? Should we throw in that case or if index > 0 return null?

of if we return 3 nodes and index === 4

I suppose it should be the same behavior if selector doesn't return any element. What we do in this case now?

I think we should return null if index > the number of returned nodes

of if we return 3 nodes and index === 4

It will be null then. Regarding initializeOptions: how about filteringOptions or filterOptions?

Or we can just completely ignore index if fn returns DOM node.

I think we should not ignore this. If you write select(selector, 1), you expect that should be more than one elements with this selector on the page. If there is just one, something went wrong

Regarding initializeOptions: how about filteringOptions or filterOptions?

em... you mean filterOptions will include scopeVars. no, I think

em... you mean filterOptions will include scopeVars. no, I think

We can remove scopeVars from this object then.

If you write select(selector, 1), you expect that should be more than one elements with this selector on the page. If there is just one, something went wrong

Emm, if you specify select(selector, 1) it doesn't make things better either. Or we should have index: null by default, signaling that we don't expect any collection.

Or maybe I'm just over complicate things and we should just merge all options in one object?

@DevExpress/testcafe
Is it clear with such naming:
var selector = Selector(fn, filterOptions, scopeVars); // BTW, I'm thinking about renaming scopeVars
                                                                                // back to dependencies

var newSelector = selector.with(executionOptions);

I think, yes

Will executionOptions contains scopeVars in second case?

Looks nice. But... would not it be a little better if it would be like
Selector(fn, scopeVars).filter(filteringOptions).with(executionOptions)?

Will executionOptions contains scopeVars in second case?

Nope, scopeVars is the part of selector definition

Selector(fn, scopeVars).filter(filteringOptions).with(executionOptions)?

Looks interesting, but we've just discussed if it correct. E.g. fn may return DOM node collection without filter it will end up in selector error (because we don't allow anything except node as selector return value), so without additional .filter call selector is not functional. In general we should avoid such cases by enforcing correct behavior with API, so I have a strong feeling that filterOptions should be a part of selector definition, like scopeVars

As long as index belongs to filtering...
What if we go with
var selector = Selector(fn, options, scopeVars);

var newSelector = selector.with(executionOptions);

yeah, it brings mess to `t.select(fn, options, scopeVars, executionOptions) though

whats stops us from merging all options in... just options.
var selector = Selector(fn, options, scopeVars);
t.select(fn, options, scopeVars);

You may redefine them all via with. (we are creating a new selector anyway)
var newSelector = selector.with(options);

or, it hurts the ideology, we can get rid of with and use
var newSelector = Selector(selector, options);

instead


docs: Add module documentation for 'containerfile' and 'files'

This looks good!
Should we depreciate bash files module for this one?
What is the plan for that?

This looks good!
Should we depreciate bash files module for this one? What is the plan for that?

I think we should since we aren't using any of the bash from that module.

I'm not sure about including the files module docs here, because the bash module will be kept alive too, but the docs here are essentially the same.
Will review other docs more closely later today.

I opted to put the files module docs only here instead, removing the docs from the bash modules repo.


Deprecated syllable_tokenize #322

syllable_tokenize is deprecated, use subword_tokenize instead #322
What does this changes
Deprecated syllable_tokenize
Your checklist for this pull request
🚨Please review the guidelines for contributing to this repository.

[ ] Passed code styles and structures
[ ] Passed code linting checks and unit test

Todo

[ ] move test set
[ ] edit docs

Hello @wannaphong! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file pythainlp/tokenize/core.py:

Line 425:80: E501 line too long (102 > 79 characters)

Coverage decreased (-0.1%) to 95.606% when pulling 92cefd3511ab922e62199e82cc594feafd7285d7 on merge-syllable-subword into 449e9b0205e5e8ab0217099e5a80f33c0b59e77d on dev.


SeaORM support

Hey this PR sketches out an initial draft of SeaORM support which would allow users to have type safety all the way down to their DB and back.
I thought I'd see what your inclination was for accepting such a PR before working further on it!
If not - happy to maintain a fork for my own purposes.

Thanks. I wouldn't mind supporting this in principle, but the issue is the same as the one I pointed out in https://github.com/diesel-rs/diesel/discussions/3993 -- this is committal in a way that's irreversible, and has negative impacts on the ecosystem. My preference would be for "large" dependencies like SeaORM (or Diesel) to depend on "small" dependencies like newtype-uuid.
At Oxide, within the database layer we've been using our own newtypes that have From and Into conversions (this is partly why I used a type parameter), and it's been okay. Not great but okay. We convert to these types as soon as we retrieve data from the database layer.


Added default dependencies

When installing with ansible-galaxy, it will print an error message:
- influxdb was installed successfully
Traceback (most recent call last):
  File "/usr/local/bin/ansible-galaxy", line 959, in <module>
    main()
  File "/usr/local/bin/ansible-galaxy", line 953, in main
    fn(args, options, parser)
  File "/usr/local/bin/ansible-galaxy", line 845, in execute_install
    role_dependencies = role_data['dependencies']
KeyError: 'dependencies'

Can be solved by adding the following to "meta":
dependencies: []

Thanks!


Get nested system styles using styled

💬 Questions and Help
I would really like to have a deeply nested theme object such as:
const theme = {
  colors: {
    primary: 'blue',
    text: '#000',
    background: '#fff',
    variants: {
      primary: {
        light: 'lightblue',
        dark: 'darkblue'
      }
    }
}

const StyledDiv = styled.div`
  border-color: primary;
  background-color: variants.primary.dark;
`

The theme is just simplified and could be flattened, but in my use case it would be a messy if the object is flattened, e.g. I want to have values like colors.variants.state.error.dark
It doesn't seem like there's a way to do this, is there?

Your example should work great! This is exactly the way to do it :)


Add precommit and update tox targets

Fixes #15
Fixes #21
the eslint job should be added after #20

Ta. I'm going to merge this one now. I will deal with the monster rebase on https://github.com/wagtail/cookiecutter-wagtail-package/pull/32 sometime after Christmas.

Thanks @zerolab and all - this is a nice improvement


Feature/categories

Add categories ENUM and in set.entity
Add endpoint for played of set
Add tests for both

Codecov Report

Merging #49 (82d07c3) into main (ab5aa5c) will increase coverage by 0.09%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #49      +/-   ##
==========================================
+ Coverage   97.70%   97.79%   +0.09%
==========================================
  Files          52       53       +1
  Lines         609      634      +25
  Branches       57       59       +2
==========================================
+ Hits          595      620      +25
  Misses         13       13
  Partials        1        1

Impacted Files
Coverage Δ

src/set/dto/create-set.dto.ts
100.00% <100.00%> (ø)

src/set/entities/set.entity.ts
100.00% <100.00%> (ø)

src/set/enums/setcategory.ts
100.00% <100.00%> (ø)

src/set/set.controller.ts
100.00% <100.00%> (ø)

src/set/set.data.ts
100.00% <100.00%> (ø)

src/set/set.service.ts
98.86% <100.00%> (+0.05%)
: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 ab5aa5c...82d07c3. Read the comment docs.


EngineLayer/GlobalVariables.cs writes into codebase, not allowed in Singularity or HPC

Files: CustomAminoAcids/CustomAminoAcids.txt and settings.toml are written into the code base when MetaMorpheus is first run.
This is an issue when running MetaMorpheus in a Singularity container.   The codebase is in a read only file system for security reasons.
This could also be an issue for an a HPC system in which multiple jobs could be run concurrently if  the jobs need to alter those files.
Could there be command line option for a user DataDir that could override or modify defaults rather than writing back into the codebase?

I've got this resolved in #1835 but needs testing + unit tests

While our Docker container works fine on a personal laptop, we're experiencing probably the same issue with the converted Singularity container on a cluster. Here's the complete output:
Welcome to MetaMorpheus
Unhandled exception. System.TypeInitializationException: The type initializer for 'EngineLayer.GlobalVariables' threw an exception.
 ---> System.IO.IOException: Read-only file system
   at System.IO.FileSystem.CreateDirectory(String fullPath)
   at System.IO.Directory.CreateDirectory(String path)
   at EngineLayer.GlobalVariables.WriteAminoAcidsFile()
   at EngineLayer.GlobalVariables.RefreshAminoAcidDictionary()
   at EngineLayer.GlobalVariables..cctor()
   --- End of inner exception stack trace ---
   at MetaMorpheusCommandLine.Program.Run(CommandLineSettings settings)
   at MetaMorpheusCommandLine.Program.<>c__DisplayClass3_0.<Main>b__1(CommandLineSettings options)
   at CommandLine.ParserResultExtensions.WithParsed[T](ParserResult`1 result, Action`1 action)
   at MetaMorpheusCommandLine.Program.Main(String[] args)
CMD: line 2: 59159 Aborted

Our user replied that the dev container (converted into Singularity) mentioned in #1835 is working on our cluster. Thanks again for all your help!

Great to hear! I'll make a new release soon (probably within a week or two).
For those following this issue:
You can pull the current smithchemwisc/metamorpheus:dev tag from DockerHub which includes this change. the dev tag is a Docker image containing a build of the current master branch.
something like this (assuming you're using Singularity to pull from DockerHub):

I'll close this issue because it seems to be resolved at this point.


Broken URL in python page.

The guide URL provided on the python page for flow_py_sdk is broken.
The link in the python page is:  https://janezpodhostnik.github.io/flow-py-sdk
Correct Link:  https://janezpodhostnik.github.io/flow-py-sdk/python_SDK_guide/

Thank you very much for reporting.
It was already fixed in the past, but a version was never released.
Released a new version, and the link works now.

Thank you for responding.


TODO

Code optimizations: (1) prefetching memory references, (2) introducing a leading matrix dimension such that aligned Load and/or Store instructions can be used, and (3) AVX-512 testing and tuning.
Incorporate separate routines for matrix transposes, and check performance of a specialized MM kernel which is multiplying with a pretransposed B matrix.
Improved build system retiring the current mechanism (INDICES_M, INDICES_N, and INDICES_K). It is also accepting empty list(s) i.e., not generating a specialized function.
Publish performance results along with the benchmark driver.

The current revision of the library resolved or implemented most of the above issues. The remaining issues (beside of the published roadmap issue) are the following:

Thoroughly validate the assembly code generate (and make it the new default).
Publish a variety of reproducible performance results.


Add inflateRRect to EdgeInsets.

Fix https://github.com/flutter/flutter/issues/108689.
Not breaking.

The original proposal is for Rect and RRect, but @Hixie gave the idea EdgeInsets already implements inflateRect, so I could complement it with inflateRRect.
Rect/RRect misses equality and many of the methods you mentioned. The bigger quality is how useful would it be to "fix" Rect rather than finish what EdgeInsets do.

Closing until I can convince someone.


[BUG] Cannot read Tags of subscription if permission is inherited via Management Group

Describe the bug
I want to read the tags on an Azure Subscription using "Microsoft.Azure.Management.ResourceManager.SubscriptionClient".
The Service Principal is able to read the subscriptions details but the tags-property is always null if the SP was given the "Reader" role on the management group of the subscription.
If I add the SP directly to the Subscription itself as a "Reader" I can successfully read the tags.
It seems some permissions are not fully inherited from the parent management group.
Expected behavior
The Service Principal should be able to read the Tags of the subscription.
Actual behavior (include Exception or Stack Trace)
The Tags property of the subscription is always null.
To Reproduce
You need to have some subscriptions bound to an Azure Management Group.

Create an App Registration in Azure.
Assign the created Service Principal the Reader-role on the management-group.
Set some Tags on the subscription.
Get some azure credentials:

var credentials = SdkContext.AzureCredentialsFactory.FromServicePrincipal(clientId,
                    clientSecret, tenantId,
                    AzureEnvironment.AzureGlobalCloud);

Get a new resource-manager-client and check the Tags-Property. It is always null:

var subscriptionClient = new Microsoft.Azure.Management.ResourceManager.SubscriptionClient(azureCredentials);
var subscriptions = await subscriptionClient.Subscriptions.ListAsync();
      foreach (var sub in subscriptions)
      {
          var t = sub.Tags;
      }

Assign the Reader-role directly to the subscription and now you're able to read the tags successfully.

Environment:
VS 16.8.3
Microsoft.Azure.Management.ResourceManager: 3.12.1-preview

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

Thank you for your question, we will route to the appropriate team for follow-up.

@DGOIT-Jan could you please provide the HTML request and response? Thank you


Added 'Add users' guide from Intercom to the docs.

Summary of the changes / Why this is an improvement
Added the 'Add users to organizations and projects' Guide from Intercom to the Docs. See planning
Checklist

[ ] CLA is signed

Retest this, please


Fixing MISRA violation 4.6, 10.4

Description

Test Steps

Related Issue

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/bot run uncrustify


[GUI] Fix fixedRatioMasterIsWidth not being preserved on the GUI Editor

Example PG: #KEZ57F#1
When opened:

If you open the GUI Editor, it switches from fixed width ratio to fixed height:

This also exposes the property fixedRatioMasterIsWidth so the user can set it to their preference.

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/13958/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13958/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13958/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/13958/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/13958/merge
https://gui.babylonjs.com/?snapshot=refs/pull/13958/merge
https://nme.babylonjs.com/?snapshot=refs/pull/13958/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/13958/merge#BCU1XR#0

@PatrickRyanMS I think this is a different problem, I'll have to dig deeper into it to understand what's going on


[Tables] Create clients from connectionString

Support 2 kinds of connection strings to instantiate TableClient and TableServiceClient

Account Connection String (Node.js Only)
SAS Connection String

Docs for Tables Shared Key Authorization: https://docs.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key#table-service-shared-key-authorization
Note: Parts of the authorization using Shared Keys are similar to other Storage Services, however Tables has some specific requirements different from Blob, Queues, etc. It may be a good idea at some point to move common building blocks to a common/core package so that each service can compose their own Authorization reusing  them. Filed issue #10291 to track this investigation

/cc @HarshaNalluru who worked on this for storage.


Add deserialization validation for ChunkWithProof and IndexedMerkleProof

deserializer should prevent deserialization when objects contain incorrect/inconsistent data"

PR ready for review here: https://github.com/xcthulhu/casper-node/pull/7


Create M_ISPx2

Looks good but needs a dependency on ModuleManager.
"depends": [
    { "name" : "ModuleManager" }
]

ok, thanks
(: but ... everyone have modulemanager :)

Yes, thats true but just to be sure.


Xbox One Controller Resets Custom Inputs (+ inputs a set of new ones?) if the bluetooth self disconnects due to inactivity from Computer

[x] I have checked the known issues and searched Github to ensure this issue has not already been reported.
[x] This is not a feature request, I know those belong on Discord/Github Discussions.

Description of the bug:
I left my Bluetooth Connected Xbox One controller alone to go do something and when i came back to it, it had disconnected, when i turned it back on and resumed playing, I tried moving my camera around (as I had Free-Look enabled) and ended up using my Bombs, when I threw them, i felt my controller rumble (even though i had it turned off). When i checked the Controller Input Menu, it showed there was another set of Xbox Inputs but they were Red. In addition, rumble was on again.
Can you reproduce? If so please list the steps:

[x] No, I cannot reproduce this bug
[ ] Yes, here are the steps to reproduce the bug:

Connect Xbox One Controller via Bluetooth, Launch Program, & Begin Playing
Customize Inputs, Leave Controller & Game Idle (preferably on the pause menu), Once Controller Disconnects, Reconnect and Resume Play
Witness (or use Free-Cam and nearly blow yourself up as i did.).

Expected behavior:

Screenshots or videos:

System Information:

OS: Windows 10
GFX Backend: DirectX11
Game Version: Rika-Alfa 1.0.0
Rom Version: "MM-US 1.0"

Additional Information:
I am unable to reproduce this bug manually or organically. I tried to do it manually at first and it didnt do anything, stayed as is, but when i did it the way it happened before, it also didnt do it either. Im leaving the steps there as a means to possibly replicate this one in a million chance of a bug. At first i thought it was because the program thought i was using a new controller, despite using the same controller (hence why it probably inputted an additional set of xbox inputs).

Running into the same issue as above. When controller disconnects due to inactivity and powers back on, Ship2 treats it like a brand new controller, and often resets the inputs to inoperable dummy "axis" controls, rather than what I assume would normally be xinput.  Controls must be fully reset every time.

this should be fixed in Rika Bravo (1.0.1), if this is still an issue on that version (after clearing out all the mappings from 2ship2harkinian.json) i can reopen this


When typing an update on Bastyon, edit box doesn't scroll into view

Describe the bug
When I type an update in Bastyon app on Android, edit box doesn't scroll into view and I end up not seeing the cursor or what I am typing.
Steps to reproduce

Open Bastyon app on android
Click on white cross in the blue icon to create a new post
Tap on the edit box that has "What's new?" placeholder

Expected behavior
Expected: The edit box scrolls into view and I can see the cursor and what I am typing.
Actual: The edit box doesn't scroll into view. I can however still type characters, it's just I don't see what I am typing.
Screenshots and recordings
Before tapping in the edit box

After tapping on the edit box

OS / Linux distribution
Android 12
Version
12
Type application
Mobile
Additional context

Device: Samsung Galaxy S20 FE 5G
OS: Android 12 with One UI version 4.1
Browser: Bastyon App
Version 1.7.17

The original issue that was erroneously opened here - https://github.com/pocketnetteam/pocketnet.core/issues/486

Thank you for your feedback, @gked! 🙂👍 Can you check if the latest version of Bastyon app resolves the issue for you? It can be that the bug is still there, but check it please as your version is very old. The latest version is 1.8.33 for Android. Thanks in advance!

@shpingalet007 I didn't realize that I had an outdated version of Bastyon. I don't repro the bug anymore. Closing the issue.


Testing using webcam

Can I do the testing through my webcam?
Is there a way to shorten the testing process? It's takes too long.

Can I do the testing through my webcam?
Is there a way to shorten the testing process? It's takes too long.

Hey @srtcdemir did you successfully implement it?

Can I do the testing through my webcam?
Is there a way to shorten the testing process? It's takes too long.

Hey @srtcdemir did you successfully implement it?

I'm also interested in..

no i couldn't. I have not been interested in this project for a long time. @geadalfa


sf::Mouse::setPosition not working with Wayland/xwayland

Prerequisite Checklist

[X] I searched for existing issues to prevent duplicates
[X] I searched for existing discussions on the forum to prevent duplicates
[X] I am here to report an issue and not to just ask a question or look for help (use the forum or Discord instead)

Describe your issue here
We've received multiple reports that sf::Mouse::setPosition() doesn't seem to work to work when using Wayland:

ArchLinux: https://en.sfml-dev.org/forums/index.php?topic=29196.0
Debian GNOME: https://en.sfml-dev.org/forums/index.php?topic=29246.0

It might just be a bug in xwayland, but we should double check
Maybe related to #2709
Your Environment

OS / distro / window manager: ArchLinux Plasma KDE / Debian GNOME through xwayland
SFML version: 2.5.1 / apt (probably 2.5.1)
Compiler / toolchain: ?
Special compiler / CMake flags: ?

Steps to reproduce

Run the following example

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode({1280, 720}), "Minimal, complete and verifiable example");
    window.setFramerateLimit(60);

    while (window.isOpen())
    {
        for (sf::Event event; window.pollEvent(event);)
        {
            if (event.type == sf::Event::Closed)
                window.close();
            else if (event.type == sf::Event::KeyPressed)
                sf::Mouse::setPosition({200, 200});
        }

        window.clear();
        window.display();
    }
}

Expected behavior
When pressing any key, the mouse should be moved to position (200, 200)
Actual behavior
The mouse is not moved

Doesn't seem to work in Sway (wlroots) either.

I tested the sample code & experienced this issue within my own project, but have come to the conclusion I think it does work, but not as expected. I adjusted the sample code above to also print the mouse position every frame. When I hit any key press I do not visually see my cursor migrate on the screen, but the position reported is {200, 200}.

Tangentially related to this, window.setCursorGrabbed doesn't work on Sway either. It doesn't confine the mouse to the window, though nothing else is focusable, so clicks outside of the window do nothing.

Wayland does not support getting the mouse position in desktop coordinates (although this seems to work through XWayland), and it does not support setting the mouse position in general (not even in XWayland).
setMouseCursorGrabbed can be implemented with the pointer-constraints-unstable-v1 protocol (when using native Wayland instead of XWayland), the relative-pointer-unstable-v1 protocol may also be helpful.

Wayland does not support getting the mouse position in desktop coordinates (although this seems to work through XWayland), and it does not support setting the mouse position in general (not even in XWayland).
setMouseCursorGrabbed can be implemented with the pointer-constraints-unstable-v1 protocol (when using native Wayland instead of XWayland), the relative-pointer-unstable-v1 protocol may also be helpful.

The inability to set the mouse position seems rather cumbersome limit to overcome for some game types, or even supporting existing game codebases that rely on this. Grabbing the cursor isn't enough for some control schemes to work correctly.

Came across this list, that has a lot of X11 stuff which are broken in Wayland: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
Additionally, there's this repo with some potential workarounds: https://github.com/probonopd/wayland-x11-compat-protocols/

For context, this gist has became a meme in the wayland world, the majority of the points are wrong or misleading and for the few valid points, it's done in a very unproductive way (complaining about things that are explicitly incompatible with the security model like background keyboard listening and self activation, tools/apps written specifically for x11 e.g. X11 atoms and NetWM, etc. and just from a quick glance a lot of things are wrong/outdated e.g. drag and drop exists and has existed for a long time, allowing screen tearing isn't "recently" anymore and doesn't work just on KDE, DRM leasing exists, etc.). The "x11-compat" protocols are much better either, anyone can write some xml files and call them protocols, but if nobody agrees on them and nobody implements them they might as well not exist - they don't even have reference implementations, heck they aren't even valid.
There's a new proposed pointer_warp_v1 protocol (rendered) which will solve this.


Put badge on finished notebooks

Completed notebooks should have a part at the top that points to the binder.org online version of the most recent master-branch notebook.
For example:
"Run notebook online with Binder:\n"

By "finished", we mean those that will be done by the JOSS submission


38 - UI Design preview

hello @swapnilsparsh sir,
I have added the ui designs of home and projects sir. Pls review it sir.

r

Use Glassmorphism rather than Neumorphism.🙂

hello sir,
I have added the 2 glass morphism designs in the code. Please review it @swapnilsparsh sir.

hello sir,
I have added the 2 glass morphism designs in the code. Please review it @swapnilsparsh sir.

All the designs are very good 🤩
Just enhance the cards and footer with glassmorphism.👍🏼