Still problems with sporadic meter faults

Hi Sebastian,
the export control is basically working, and I am using 2x D1 Mini Boards for 2 separate inverters.
But sometimes, I get the meter fault error thrown by the inverter and I haven´t yet figured out why.
I found, that the source sensor for power consumption (Shelly 3EM) sometimes takes 10-15 seconds to update values regarding power consumption. To get around this, I added an heartbeat filter to the code, to send the source value to the power demand sensor every (tried) 3 or 5 seconds, even if the power consumtion sensor hasn´t been updated in between.
  name: solax-meter-gateway
  device_description: "Control the export of a Solax X1 mini via RS485"
  external_components_source: github://syssi/esphome-solax-x1-mini@main

external_components:
  - source: ${external_components_source}
    refresh: 0s

uart:
  - id: uart_0
    baud_rate: 9600
    tx_pin: GPIO12
    rx_pin: GPIO14

solax_meter_modbus:
  - id: modbus0
    uart_id: uart_0

solax_meter_gateway:
  solax_meter_modbus_id: modbus0
  address: 0x01
  # The state of this sensor (instantaneous power in watt) is used as source
  power_id: powermeter0
  power_sensor_inactivity_timeout: 25s
  update_interval: 1s

sensor:
  - platform: homeassistant
    id: powermeter0
    entity_id: sensor.power_consumption
    internal: true
    force_update: true
    filters:
      heartbeat: 5s

  - platform: solax_meter_gateway
    power_demand:
      name: "${name} power demand"

text_sensor:
  - platform: solax_meter_gateway
    operation_mode:
      name: "${name} operation mode"

But despite that change, sporadically the meter fault still shows up.
Any ideas what would cause this? Could it be related to using 2 Boards at 2 Inverters sharing the same code?
Out in the field currently (work related), will be back on Thursday to provide according logs or increase the Log Level

Hi Sebastian,
after checking the Log, I doubt that the heartbeat would do anything different, since the last value of that source sensor is handed over very frequently to the inverter.
[09:48:38][D][sensor:093]: 'powermeter0': Sending state 238.89999  with 1 decimals of accuracy
[09:48:39][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:39][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:39][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:39][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:39][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:39][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:39][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:39][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:40][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:40][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:40][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:40][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:40][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:40][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:40][D][sensor:093]: 'powermeter0': Sending state 238.89999  with 1 decimals of accuracy
[09:48:40][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:40][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:41][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:41][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:41][D][homeassistant.sensor:024]: 'sensor.power_consumption': Got state 249.08
[09:48:41][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:41][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:41][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:41][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:42][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:42][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:42][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:42][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:42][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:42][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:42][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 238.89999 W with 0 decimals of accuracy
[09:48:42][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:42][D][sensor:093]: 'powermeter0': Sending state 249.08000  with 1 decimals of accuracy
[09:48:43][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:43][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:43][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:43][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:43][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:43][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:43][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:43][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:44][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:44][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:44][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:44][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:44][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:44][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:44][D][sensor:093]: 'powermeter0': Sending state 249.08000  with 1 decimals of accuracy
[09:48:44][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:44][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:45][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:45][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:45][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:45][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:45][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:45][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:46][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:46][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:46][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:46][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:46][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:46][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:46][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:46][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:46][D][sensor:093]: 'powermeter0': Sending state 249.08000  with 1 decimals of accuracy
[09:48:47][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:47][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:47][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:47][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:47][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:47][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:47][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:47][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
[09:48:48][D][sensor:093]: 'solax-meter-gateway power demand': Sending state 249.08000 W with 0 decimals of accuracy
[09:48:48][D][text_sensor:064]: 'solax-meter-gateway operation mode': Sending state 'On'
´´´
I can try to keep the Log output open until it happens, to have a closer look to the Logfile. Is there a certain log level (like Very_Verbose) I should use for that - or any other information I can provide?
The manual says wrong wiring / wrong baud rate for troubleshooting, but I would doubt those 2 reasons for this case - since it works most of the time but just sporadically gets to that meter error state.

PS: also running kind of the same config at my Dad´s Inverters. Also 2 pcs. D1 Mini Boards, completely independently wired and connected. Where also sporadically the meter fault shows up and I don´t know exactly what´s causing it.
Even though the inverter is recovering from that state usually by itself, it would be of course better to not fall into that meter fault state at all... 😅😁

@Sven177 Do you use discord and can we have a quick chat here? My handle is syssi.

I have a discord account - but how to find you there? 😅

Direct messages -> Add friend -> syssi.

seems I found a syssi - but it seems it is the wrong one.
Oh, the "." needs to be there as well?

Long story short: Using hardware UARTs (GPIO1/GPIO3 on an ESP8266 or any GPIO on an ESP32) should resolve the issue.

OK, tried using GPIO1 and GPIO3 on ESP8266, but getting meter fault instantly on that config... 🤔

Did you swap RX/TX accidently? Did you update the uart section of your YAML configuration? Does the TX led of the RS485 converter board blink periodically?

Hi,
yes - here from the Log. Is the internal UART missing some adjustment for the inverter?
[11:51:01][C][logger:416]: Logger:
[11:51:01][C][logger:417]:   Level: DEBUG
[11:51:01][C][logger:418]:   Log Baud Rate: 0
[11:51:01][C][logger:420]:   Hardware UART: UART0
[11:51:01][C][uart.arduino_esp8266:102]: UART Bus:
[11:51:01][C][uart.arduino_esp8266:103]:   TX Pin: GPIO1
[11:51:01][C][uart.arduino_esp8266:104]:   RX Pin: GPIO3
[11:51:01][C][uart.arduino_esp8266:106]:   RX Buffer Size: 256
[11:51:01][C][uart.arduino_esp8266:108]:   Baud Rate: 9600 baud
[11:51:01][C][uart.arduino_esp8266:109]:   Data Bits: 8
[11:51:01][C][uart.arduino_esp8266:110]:   Parity: NONE
[11:51:01][C][uart.arduino_esp8266:111]:   Stop bits: 1
[11:51:01][C][uart.arduino_esp8266:113]:   Using hardware serial interface.
[11:51:01][C][solax_meter_modbus:096]: SolaxMeterModbus:

Hi,
seems like for whatever reason my bord doesn´t like that Pin 1 and 3 at all, so I was using the SWAP Config, to assign Pins 13 and 15 instead.
substitutions:
  name: solax-meter-gateway
  device_description: "Control the export of a Solax X1 mini via RS485"
  external_components_source: github://syssi/esphome-solax-x1-mini@main

external_components:
  - source: ${external_components_source}
    refresh: 0s

uart:
  - id: uart_0
    baud_rate: 9600
    tx_pin: GPIO15
    rx_pin: GPIO13
    debug:
      direction: BOTH

solax_meter_modbus:
  - id: modbus0
    uart_id: uart_0

solax_meter_gateway:
  solax_meter_modbus_id: modbus0
  address: 0x01
  # The state of this sensor (instantaneous power in watt) is used as source
  power_id: powermeter0
  power_sensor_inactivity_timeout: 20s
  update_interval: 1s

It was working on that config so far.
Nevertheless, I decided to switch to an ESP32 Board, for controlling 2 Inverters with one of those at the same time, instead of using two separate 8266 boards for that purpose... 😉


Add a test that the opensearch server starts and serves the default e…

…ndpoint.
Fixes:
Related:
Pre-review Checklist

somehow need to get opensearch to bind to <IP_ADDRESS>:9200 vs. <IP_ADDRESS>:9200, this seems to be the problem with the test now

This is blocked on this: https://github.com/wolfi-dev/os/pull/1107

appears to still fail with newer package:
installing opensearch-2 (2.6.0-r2)

I had to increase the sleep to 20s and now it works.


fix little typo in backend crate

Ah, commited to wrong branch. Will create another pull request with clean changes.


Improve plural support for the matches counter

It turns out that only specifying one and other in #10070 is not enough, so we may need to add all other options too for other locales (note that there are no bugs because of this, it should only be more helpful for other languages this way).

Important note: at this point you need to change the string ID for all these strings (it should have been changed in #10070).
It would be great if we could land this fix soon, and merge it back to m-c. If that requires a lot of time, I'll need to ask to backout https://hg.mozilla.org/mozilla-central/rev/5f9d6d1fa6cc

One more issue
find_matches_count={[ plural(n) ]}
find_matches_count[one]={{current}} of {{total}} match
find_matches_count[other]={{current}} of {{total}} matches

You define n as the variable defining plural, but it should be total.

To summarize:

plural(n) should be changed to plural(total);
along with [one] and [other] we should also provide [zero], [two], [few] and [many], which will just be copies;
after doing this, we need change all string IDs to be unique (for example find_matches_count_).

Correct?

Correct? If so, this can certainly be fixed on our side.

Yes

Would that require another upstream merge or would the current patch need to be backed out upstream anyway?

It depends on the timing. If it requires more than a few days to have the updated patch in m-c, we should back that out, then land the updated version of PDF.js when it's ready (there's no real need to back-out from PDF.js too).

The only problem with changing plural(n) to plural(limit) is that we're setting limit: limit.toLocaleString() when making the string.

I haven't used webl10n strings in years, so I'm not exactly sure. If limit is determined from n, it might still work, but needs testing, and a comment for localizers explaining what's used to determine the plural.


Update LVGL to v9 prerelease version

Update LVGL to v9 prerelease version, commit: #a9960c62
Fix gen_mpy.py binding script
Amend MicroPython files and examples to the new LVGL namings (for example: img -> image, btn -> button)
Update README.md: rename Micropython -> MicroPython
Remove lv.COLOR_FORMAT.NATIVE_REVERSED, and use instead lv_draw_sw_rgb565_swap() function for some displays
Remove lv.COLOR_DEPTH from display drivers and examples
Modify ili9xxx.py: change class attributes to instance attributes (-> eliminate "singleton" class attributes)
Modify ili9xxx.py: set explicit default color formats instead of lv.COLOR_FORMAT.NATIVE

@kisvegabor , @XuNeo , @kdschlosser
Please review this PR before I merge it to master.

@sam0910 :  this PR contains the latest LVGL with fixed display drivers (including the fix for your feedback: https://github.com/lvgl/lv_binding_micropython/pull/298#issuecomment-1880908299).
Please test this multi-instance branch on your device, and if it works, then give an approve to this PR.
Thank you!

Waiting for @sam0910's approval to merge.

This PR works on M5Core2 device  (ESP32 SPIRAM, ILI9341 display)

and would you please separate the display drivers into their own files and import the base class into the file. The amount of memory that gets consumed because of importing a bunch of code for drivers that are not being used is simply out of control.
Also get rid of the class level attribute for the init parameters and put them into a function. they get used only once and to have them sitting there eating up memory after the initialization is just crazy. If the init parameters are set in the __init__ function of the driver you can delete them after they are used. But if they are set at the class level then you cannot delete them because if a user has more than one display attached that is the same the init commands will be gone and will not be able to be used when the second display is initialized.

I suggest merging this PR if it's doesn't break anything, and send smaller ones after that.

and TY for fixing that error in gen_mpy. I mentioned the problem as you know and it was never corrected.

since LVGL internally no longer changes things like structures or unions based on the color depth why is there still a reliance on LV_COLOR_DEPTH??
It sets the NATIVE color format enumerations and it is used to set _LV_COLOR_NATIVE_WITH_ALPHA_SIZE which is used in LV_IMAGE_BUF_SIZE_TRUE_COLOR_ALPHA. This macro is not accessible in the binding nor is it used at all in LVGL's internal code.
the color depth is also used in LV_IMAGE_BUF_SIZE_TRUE_COLOR_CHROMA_KEYED and LV_IMAGE_BUF_SIZE_TRUE_COLOR and none of those macros are used anywhere in LVGL code. Those macros are not exposed in the binding and will never get used. So setting LV_COLOR_DEPTH does not need to be done at all. It's is pointless to do so. It adds additional complexity and it also forces the binding to be a compile time thing instead of a runtime thing. If LV_COLOR_DEPTH is not used at all then a user will not have ro compile and flash their firmware if they want to change out to a different display. All they have to do is upload the new python source file that has the new driver code in it.  That's it. The sole point to using python is rapid development. having to recompile firmware and flash firmware if changing a piece of hardware that is attached kind of negates the point to using it.
LV_COLOR_DEPTH also sets antialiasing in the display driver but that is easily changed in python code.

@kisvegabor, I've just compliled this PR with lv_micropython/feat-multiinstance.
It is working without ANY issue. I am so happy to have the latest LVGL with micropython 1.20.0 :)

with lvgl@a9960c62 is working any issue :)
Thank you so much, and I am very excited that I could use the latest v9,
with great new features.
I have not measured the detail, but the rendering speed is better than v8.
I could feel it :)

I have not measured the detail, but the rendering speed is better than v8.
I could feel it :)

Ahhh, what a relief :slightly_smiling_face:

We can remove LV_IMAGE_BUF_SIZE_ as they are not used anymore. See 5244
LV_COLOR_DEPTH still affects a few minor places and we have no time to remove it for v9. We can get beck to this in the near future.

and would you please separate the display drivers into their own files and import the base class into the file. The amount of memory that gets consumed because of importing a bunch of code for drivers that are not being used is simply out of control.
Also get rid of the class level attribute for the init parameters and put them into a function. they get used only once and to have them sitting there eating up memory after the initialization is just crazy. If the init parameters are set in the init function of the driver you can delete them after they are used. But if they are set at the class level then you cannot delete them because if a user has more than one display attached that is the same the init commands will be gone and will not be able to be used when the second display is initialized.

Next step in a new PR.

The new changes are tested on ST7789 display (ESP32), and it works. For me the performance (FPS) is worse than with LVGL 8.3, but I will investigate this issue later.
@sam0910 , could you please test again on your device this updated PR? Thank you!

The new changes are tested on ST7789 display (ESP32), and it works. For me the performance (FPS) is worse than with LVGL 8.3, but I will investigate this issue later.
@sam0910 , could you please test again on your device this updated PR? Thank you!

Update ili9xxx, st77xx drivers and examples, remove lv.COLOR_DEPTH is looking great! no issues!
it might not be relevant with this PR, but I found a roller widget has 0ms anim_time by default. so user set roller.set_selected(1, lv.ANIM.ON) they cannot see the anim, unless they set roller.set_style_anim_time(1000, lv.PART.MAIN)

Please note these merged PR: https://github.com/lvgl/lvgl/pull/5204
There are no other planned API changes before v9.

Please note this merged PR: lvgl/lvgl#5204 There are no other planned API changes before v9.

Get stuck with an issue about allocating ESP32 DMA-capable memory for display buffers:
https://github.com/lvgl/lv_binding_micropython/issues/313

Please note this merged PR: lvgl/lvgl#5204 There are no other planned API changes before v9.

Get stuck with an issue about allocating ESP32 DMA-capable memory for display buffers: #313

Problem solved in another PR, and it is merged to this multi-instance branch.

@kisvegabor , @XuNeo , @kdschlosser ,
Could you please review & approve this big PR?
I don't want to add any more commits to it, so it is ready to merge to master branch.
After this, every new PRs should target master.
(this PR is tested on M5Core2 ESP32 device, and it works)

Reminder: disable LV_USE_ARABIC_PERSIAN_CHARS
see: https://github.com/lvgl/lvgl/pull/5386

To have a linear and clean git history on master branch, use "Squash and merge" merge strategy.


AST Nodes for authorization logic

This PR includes some c++ AST nodes for authorization logic. The structure of the AST exactly follows the one in //rust/tools/authorization-logic/src/ast.rs, but it is reimplemented in C++. The AST nodes (and other parts) related to generating/checking cryptographic signatures or importing/exporting facts have been left out because these can be implemented as a separate feature later.

You can ignore the failing test on cloudbuild and take a look at this now. The failing test does not do anything at the moment :)

@bgogul @markww see unresolved conversations

Since this was already reviewed, is this OK to merge as is (if the comments have been addressed), and then I can add a ToString and some tests as a follow-up PR? Or would you rather I do that in this PR?

Since this was already reviewed, is this OK to merge as is (if the comments have been addressed), and then I can add a ToString and some tests as a follow-up PR? Or would you rather I do that in this PR?

As practice, let us always add tests when creating new functionality, unless there is a strong reason not to. However, I am not sure what tests you will add here as these are just defining the data structures.
That said,  I have some suggestions and questions (working on it). So, let us not merge it in yet.

@bgogul @markww I think I will make a visitor in a followup PR, and remove all the accessors (or at least all the accessors to variants). LMK If you'd rather I remove all the accessors or just the variant ones.


Split out index operations into own script

I often have to reindex locally (when the python container crashes due to some hilarious python error I've made, or just when  I turn docker off and on).
This makes that process easier, allowing the index operations to be called independently of refresh-data.sh.

Could you update the documentation, e.g. here?

Done in 1e374b5c1e


Support for STM32F103 RCT6

NOTICE: The issue may be closed without notice when not enough information is provided!
Thank you for giving feedback to the stlink project. Take some time to fill out
check boxes with a X in the following items so developers and other people can try to
to find out what is going on. And add/remove what is appropriate to your problem.
When submitting a feature request, try to reuse the list and add/remove what is appropriate.
Place a X between the brackets [X] to mark the list item.

[x] Programmer/board type: Stlink/v2
[x] Programmer firmware version: V2J29S7 (I'm not sure if this is correct, I got it from the Windows ST-Link utility)
[x] Operating system: Linux Ubuntu 16.04
[x] Stlink tools version and/or git commit hash: v1.5.0
[x] Stlink commandline tool name: st-util
[x] Target chip (and optional board): STM32F103 RCT6

A as-detailed description possible of the problem with debug output when available.
Output:
I'm trying to flash an STM32F103 RCT6 from a Hoverboard's mainboard, but when I use the command st-util I get the following:
st-util 1.4.0-39-g6db0fc2
2018-06-18T13:04:46 INFO common.c: Loading device parameters....
2018-06-18T13:04:46 WARN common.c: unknown chip id! 0x5fa0004
I also tried with the MCU STM32F103 C8T6 and it works fine (I was able to flash the MCU and debug a simple code).
I'm a newbie, please bear with me if I missing some important data. Thanks.
Thank you,

Weird, the STM32F103RCT6 is a MCU which is widely used and should work. Not sure why your C8T6 variant board works. Are you sure the hardware is correct? SWD correctly populated? Could you also paste the verbose output of the target which works? Normaly the chipid should be one of the following for F1 targets https://github.com/texane/stlink/blob/master/include/stlink/chipid.h#L16-L18 (which is according to the datasheets). It is used to detect which MCU is connected to the programmer (software) during probe.

Hi again,
I just got a new mainboard from another manufacturer and I was successfully able to load my code into the STM32F103RCT6. So, we can say that this is not a problem with this project.
But maybe you could please help me figure out what the problem could be or what should I do with the other board to load the code (it works perfectly on the hoverboard), before closing this thread.

Thanks again.

I'm seeing the same issue but connecting to a proton-c, which uses the STM32F303CCT6.

I have seen programming issues can be due to bad cabling (USB, SWD) and programmers which are broken.

Hi,
I'm using the cheap stlink programmer available on ebay/aliexpress. No issue with KEIL or Stlinkutility on WIndows. I got an error output with only the stlink plugged (the same output with the target board connected)
INFO common.c: Loading device parameters....  WARN common.c: unknown chip id! 0x5fa0004
One of the programmer has a STM32F103C8T6 and the other STM32F101C8T6.
I'm using the  v1.5.0 .
COuld I modify the files linked here : https://github.com/texane/stlink/issues/673#issuecomment-367432128 and add references for the chip and recompile [?]

Hello, I have a STM32F3 Discovery kit for STM32F303 MCU which also has this problem.
st-util 1.5.1-30-g84f63d2
2019-06-17T16:54:40 DEBUG common.c: stlink current mode: debug (jtag or swd)
2019-06-17T16:54:40 DEBUG common.c: stlink current mode: debug (jtag or swd)
2019-06-17T16:54:40 DEBUG common.c: *** looking up stlink version
2019-06-17T16:54:40 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2019-06-17T16:54:40 DEBUG common.c: stlink pid     = 0x374b
2019-06-17T16:54:40 DEBUG common.c: stlink version = 0x2
2019-06-17T16:54:40 DEBUG common.c: jtag version   = 0x1b
2019-06-17T16:54:40 DEBUG common.c: swim version   = 0xf
2019-06-17T16:54:40 DEBUG common.c: *** set_swdclk ***
2019-06-17T16:54:40 DEBUG common.c: *** stlink_jtag_reset ***
2019-06-17T16:54:40 DEBUG common.c: *** stlink_reset ***
2019-06-17T16:54:40 DEBUG common.c: *** stlink_write_debug32 5fa0004 to 0xe000ed0c
2019-06-17T16:54:40 INFO common.c: Loading device parameters....
2019-06-17T16:54:40 DEBUG common.c: *** stlink_core_id ***
2019-06-17T16:54:40 DEBUG common.c: core_id = 0x00000000
2019-06-17T16:54:40 DEBUG common.c: *** stlink_read_debug32 5fa0004 is 0xe0042000
2019-06-17T16:54:40 WARN common.c: unknown chip id! 0x5fa0004
2019-06-17T16:54:40 DEBUG common.c: *** stlink_close ***

Any ideas? This is a brand new kit, I'm fairly certain there is nothing wrong due to bad cabling...

I'm not sure but the chipid is indeed incorrect, the coreid seems to read also 0x00000000. https://github.com/texane/stlink/blob/master/include/stlink/chipid.h#L13.

I just had the same thing with a blue pill - my cheap stlink clone appears to have the markings for SWDIO and SWCLK swapped. After swapping the lines over it flashed fine.

Thanks a lot doobedoobedo ! I just bumped into the same issue, lines are swapped.

Feedback resolves #715.


FrechetDistance crash with large linestrings

When calculating the Frechet distance between long linestrings (both ca. 8km in length), the function crashes and everything with it.
`from pygeos import Geometry, frechet_distance
ls1 = Geometry('')
ls2 = Geometry('')
dist = frechet_distance(ls1, ls2)
print(dist)`
To give a frame of reference: This also happens with Spatialite so I assume it is an underlying issue with Geos, which might have a memory issue. Postgis, with a Geos 3.8.0 installation can handle this though.
The linestrings can be found in this file:
crash.txt
Tested with Python 3.9.5 64Bit on Windows 10, pygeos 0.11.1 installed from pypi

I'm not clear on what you mean by crashes.  Does the process exit with a segfault?  I'm assuming you omitted the WKT geometry from your example, since Geometry('') fails with an error.
I did not encounter an error testing with the latest version of GEOS (latest GEOS and pygoes built locally, on MacOS), using the test file you provided:
>>> import pandas as pd
>>> df = pd.read_csv("~/Downloads/crash.txt", delimiter=";")
>>> import pygeos as pg
>>> l = pg.from_wkt(df.ls.values)
>>> l
array([<pygeos.Geometry LINESTRING Z (7.62 47.507 314.8, 7.62 47.507 314.8, 7.62 47...>,
       <pygeos.Geometry LINESTRING Z (7.62 47.507 317.8, 7.62 47.507 317.8, 7.62 47...>],
      dtype=object)
>>> pg.length(l)
array([0.0957573 , 0.09529885])
>>> pg.get_num_coordinates(l)
array([2785, 2770], dtype=int32)
>>> pg.frechet_distance(l[0], l[1])
0.0002499039815609772

This should not be based on memory limits, these geometries are not that big.
I don't remember what version of GEOS is bundled into pygeos 0.11.1 on PyPI.  Could you run:
>>> import pygeos
>>> pygeos.geos_version
(3, 11, 0)

I'm not clear on what you mean by crashes. Does the process exit with a segfault? I'm assuming you omitted the WKT geometry from your example, since Geometry('') fails with an error.

There is a txt file attached with WKT representations.
However, my the latest pygeos from conda-forge, I also can't reproduce this (using GEOS 3.10.0). Also in another environment with GEOS 3.9.1 I get a distance as result (in both cases I am using Linux (Ubuntu)).

In my case, the python interpreter crashes with, presumably, a seg-fault, as soon as that function is executed:
Process finished with exit code -1073741571 (0xC00000FD)
The version output I get from pygeos.geos_version is:
(3, 10, 0)
Maybe it is hitting a recursion limit?

Both conda forge and or wheelbuilder use MSVC version 14.
Compare: https://github.com/pygeos/pygeos/runs/4264227956?check_suite_focus=true
With:
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=408813&view=logs&jobId=a70f640f-cc53-5cd3-6cdc-236a1aa90802&j=a70f640f-cc53-5cd3-6cdc-236a1aa90802&t=f5d15007-a01c-5ad8-c9ce-4d519d3b275f

I am leaning towards closing this issue as it seems to be an issue with GEOS, not with pygeos. Especially because it also happens with spatialite. @Lgum are you ok with this and can you raise the issue instead at the GEOS github repository?

It is most likely a geos issue. I suspect that GEOS is using a recursive algorithm for the Frechet distance and in doing so, hits the stack-limit on windows, which, per default is 1 MB, in contrast to a default of 8 MB on unix systems. Sadly, I haven't been able to test this yet - building pygeos without libs hits a funky cython error on Windows.
I could try to specifically set the stack size with a c-linker-flag. I'll see if I can make it work and will raise an issue at the geos repository. So it's fine by me if you close the issue.

Building on windows tends to give funky errors, yes. We do have a working script that builds on windows and some guidelines in the docs that may be of help:
https://github.com/pygeos/pygeos/blob/master/ci/install_geos.cmd
https://pygeos.readthedocs.io/en/stable/installation.html#installation-with-custom-geos-libary
Note that the last step “be sure that the GEOS dlls are available on your PATH” should be “copy the GEOS dlls into the package dir or you python dll dir” if you are using Python >=3.8.
If you keep hitting the error, please share it!

I managed to build pygeos without binaries. However, what I had to do was:

Create new venv
Install numpy (and possibly cython) with wheels
Then install pygeos with:

python -m pip install pygeos --no-binary :all: --no-build-isolation
While having set the include and lib dirs beforehand

Afterwards I was able to copy the dll's into the python directory.

Sadly: It still crashed :)
I then created a small c++ program and tried to calculate the frechet distance there. The result:

Crash when building GEOS without any special flags and building the program without special flags
No crash when building GEOS without any special flags but specifying /F 8388608 and possibly also putting the stack reserve size to 8388608 and stack commit size to 16384 in the program, that links to the geos dll.

So the conclusion seems to be, that the program, that links to the dll needs to be build with the increased stack-size flags - not so much the dll?
I may put this also to the geos github, but at the moment I'm a bit clueless, how to proceed :)

Thanks for this thorough investigation! If you have the time, we could integrate your findings in the documentation on how to install pygeos from source on windows.
Could you explain to me what you did to make this work? What do you mean precisely by “ the program, that links to the dll”? Do you mean that GEOS (geos*.dll) should be built with increased stack size?

Just tell me what you need for the documentation. It could take a while (all this is just a hobby of mine ;) ) but I can surely give you a step-by-step instruction how I built pygeos from source.
As for what I did to avoid the stackoverflow: I built GEOS normally (basically just downloaded the source, opened it in cmake-gui, generated the visual studio makefiles and built it without any special flags). Afterwards I set the linker flag in my own c++ project accordingly (stack reserve size = 8 mib). I assume that the program, that calls geos, is responsible for the stack - not the geos lib itself.
I suppose that if I build spatialite the same way, it will also stop crashing. As for how to build pygeos to avoid this, I honestly don't know. I am not familiar with the python build process and how it interacts with the stack sizes. Maybe with the threading module?
It's possible that it will be fixed in 3.10.2 - I posted an issue and it got labeled as a bug. So maybe you don't have to worry about this :) => https://github.com/libgeos/geos/issues/516

Now the issue was raised upstream, this can be closed. Concerning the documentation; there actually is already something in.

Get a C compiler applicable to your Python version (https://wiki.python.org/moin/WindowsCompilers)
Download and install a GEOS binary (https://trac.osgeo.org/osgeo4w/)
Set GEOS_INCLUDE_PATH and GEOS_LIBRARY_PATH environment variables (see below for notes on GEOS discovery)
Run pip install pygeos --no-binary
Make sure the GEOS .dll files are available on the PATH


Mockito Support

Are there any plans to make this library work with Mockito?

I don't have any plans I'm afraid.


[refactor] Impl of MemTracker, and related use

Proposed changes
Issue Number: close #7196 (step 1/3)
Problem Summary:
Modify the implementation of MemTracker:

Simplify a lot of useless logic;
Added MemTrackerTaskPool, as the ancestor of all query and import trackers, This is used to track the local memory usage of all tasks executing;
Add cosume/release cache, trigger a cosume/release when the memory accumulation exceeds the parameter mem_tracker_consume_min_size_bytes;
Add a new memory leak detection mode (Experimental feature), throw an exception when the remaining statistical value is greater than the specified range when the MemTracker is destructed, and print the accurate statistical value in HTTP, the parameter memory_leak_detection
Added Virtual MemTracker, cosume/release will not sync to parent. It will be used when introducing TCMalloc Hook to record memory later, to record the specified memory independently;
Modify the GC logic, register the buffer cached in DiskIoMgr as a GC function, and add other GC functions later;
Change the global root node from Root MemTracker to Process MemTracker, and remove Process MemTracker in exec_env;
Modify the macro that detects whether the memory has reached the upper limit, modify the parameters and default behavior of creating MemTracker, modify the error message format in mem_limit_exceeded, extend and apply transfer_to, remove Metric in MemTracker, etc.;

Modify where MemTracker is used:

MemPool adds a constructor to create a temporary tracker to avoid a lot of redundant code;
Added trackers for global objects such as ChunkAllocator and StorageEngine;
Added more fine-grained trackers such as ExprContext;
RuntimeState removes FragmentMemTracker, that is, PlanFragmentExecutor mem_tracker, which was previously used for independent statistical scan process memory, and replaces it with _scanner_mem_tracker in OlapScanNode;
MemTracker is no longer recorded in ReservationTracker, and ReservationTracker will be removed later;

Checklist(Required)

Does it affect the original behavior: (Yes)
Has unit tests been added: (No)
Has document been added or modified: (Yes)
Does it need to update dependencies: (Yes)
Are there any changes that cannot be rolled back: (No)

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

I think maybe we should split the memory tracker to a small pr, for example we may first implement only Query Memory tracker. It is more useful and important.

I think maybe we should split the memory tracker to a small pr, for example we may first implement only Query Memory tracker. It is more useful and important.

It is also possible to split the refactoring of the mem tracker into multiple small PRs, but it takes time to deal with the conflicting parts.
Let’s merge this first, the pr of Hook tcmalloc new/delete later depends on this ==, waiting for push
Next pr for help review~

@xinyiZzz When I test for #8451 , I encounter a memory limit problem.
The problem is that, after the long query, as specified in the test steps of #8451 , is finished, a simple query 'select count() from tableA' will raise memory limit error.
I guess it's related to this pr, since the problem is not present before I merge the new MemTracker code.
The following is mysql client error message.

ERROR 1105 (HY000): errCode = 2, detailMessage = Memory exceed limit. fragment=4f5f114582e7429d-a630eec6e0e45384, details=New partitioned aggregation, while getting next from child 0., on backend=<IP_ADDRESS>. Memory left in process limit=8589934592.00 GB. current tracker <label=RuntimeState:inst

The following is some related logs of be.

I0312 10:58:07.931836  2320 plan_fragment_executor.cpp:76] PlanFragmentExecutor::prepare|pthread_id=140354754955008|backend_num=1|instance_id=35895a325c6943dc
-872eced6dfcb8c91|query_id=35895a325c6943dc-872eced6dfcb8c90
I0312 10:58:07.936765  2203 fragment_mgr.cpp:459] PlanFragmentExecutor::_exec_actual|pthread_id=140355728508672|instance_id=35895a325c6943dc-872eced6dfcb8c91|
query_id=35895a325c6943dc-872eced6dfcb8c90
I0312 10:58:07.936780  2203 plan_fragment_executor.cpp:213] PlanFragmentExecutor::open, using query memory limit: 7.59 GB|mem_limit=8147483648|instance_id=358
95a325c6943dc-872eced6dfcb8c91|query_id=35895a325c6943dc-872eced6dfcb8c90
W0312 10:58:07.936826  2203 status.h:260] warning: Status msg truncated, OK: Memory exceed limit. fragment=35895a325c6943dc-872eced6dfcb8c91, details=New part
itioned aggregation, while getting next from child 0., on backend=<IP_ADDRESS>. Memory left in process limit=8589934592.00 GB. current tracker <label=Runtime
State:instance:35895a325c6943dc-872eced6dfcb8c91, used=18432, limit=8147483648, failed alloc size=-1.00 B>. If query, can change the limit by session variable
exec_mem_limit. precise_code:1
W0312 10:58:07.943392  2203 mem_tracker.cpp:290] Memory exceed limit. fragment=35895a325c6943dc-872eced6dfcb8c91, details=New partitioned aggregation, while g
etting next from child 0., on backend=<IP_ADDRESS>. Memory left in process limit=8589934592.00 GB. current tracker <label=RuntimeState:instance:35895a325c694
3dc-872eced6dfcb8c91, used=18432, limit=8147483648, failed alloc size=-1.00 B>. If query, can change the limit by session variable exec_mem_limit.
 Memory left i
n process limit=8589934592.00 GB. current tracker <label=RuntimeState:inst
I0312 10:58:07.944562  2316 internal_service.cpp:187] cancel fragment, fragment_instance_id=35895a325c6943dc-872eced6dfcb8c92, reason: 3
I0312 10:58:07.944604  2316 plan_fragment_executor.cpp:602] PlanFragmentExecutor::cancel|instance_id=35895a325c6943dc-872eced6dfcb8c92|query_id=35895a325c6943
dc-872eced6dfcb8c90
W0312 10:58:07.944797  2148 fragment_mgr.cpp:231] Got error while opening fragment 35895a325c6943dc-872eced6dfcb8c92: Cancelled: Cancelled
I0312 10:58:07.944806  2203 plan_fragment_executor.cpp:673] Close() fragment_instance_id=35895a325c6943dc-872eced6dfcb8c91

@xinyiZzz When I test for #8451 , I encounter a memory limit problem.
The problem is that, after the long query, as specified in the test steps of #8451 , is finished, a simple query 'select count() from tableA' will raise memory limit error.
I guess it's related to this pr, since the problem is not present before I merge the new MemTracker code.

@xiaokang Sorry I just saw,
The memory should be independent between queries, I will try to find the cause of this problem.
Another problem, after this pr, there may be cases where large queries that were successful before, now fail, because this pr implements Query-level memory limits.
exec_mem_limit is used to limit the memory of the entire query, which is its original meaning. And in the past, exec_mem_limit is actually the memory limit at the Fragment Instance level, not the query.


Affiliation Delete and Undelete Handling

Critical Changes
Changes

Deleting Affiliations marked Primary now blanks out the contact's Primary Affiliation lookup.
Undeleting Affiliations marked Primary now populates the contact's Primary Affiliation lookup. If that lookup already has a value, Primary is unchecked from the Affiliation being undeleted.

Issues Closed

@smarovich could you review the Changes text in this pull request? Let me know if you have any questions. Thanks!

I believe this fixes #2375 (making note to close issue).


Visualization error

I try to visualize the results but it occur the error as below.
How could I solve with this issue?
My command :
!torchpack dist-run -np 1 python tools/visualize.py configs/nuscenes/det/transfusion/secfpn/camera+lidar/swint_v0p075/convfuser.yaml --mode pred --checkpoint pretrained/bevfusion-det.pth --bbox-score 0.5 --out-dir vis_results

The error :
Traceback (most recent call last):
  File "/content/bevfusion/tools/visualize.py", line 166, in <module>
    main()
  File "/content/bevfusion/tools/visualize.py", line 88, in main
    outputs = model(**data)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/parallel/distributed.py", line 1156, in forward
    output = self._run_ddp_forward(*inputs, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/mmcv/parallel/distributed.py", line 165, in _run_ddp_forward
    return module_to_run(*inputs[0], **kwargs[0])  # type: ignore
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/mmcv/runner/fp16_utils.py", line 119, in new_func
    return old_func(*args, **kwargs)
  File "/content/bevfusion/mmdet3d/models/fusion_models/bevfusion.py", line 253, in forward
    outputs = self.forward_single(
  File "/usr/local/lib/python3.10/dist-packages/mmcv/runner/fp16_utils.py", line 119, in new_func
    return old_func(*args, **kwargs)
  File "/content/bevfusion/mmdet3d/models/fusion_models/bevfusion.py", line 301, in forward_single
    feature = self.extract_camera_features(
  File "/content/bevfusion/mmdet3d/models/fusion_models/bevfusion.py", line 133, in extract_camera_features
    x = self.encoders["camera"]["vtransform"](
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/content/bevfusion/mmdet3d/models/vtransforms/depth_lss.py", line 100, in forward
    x = super().forward(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/mmcv/runner/fp16_utils.py", line 208, in new_func
    return old_func(*args, **kwargs)
  File "/content/bevfusion/mmdet3d/models/vtransforms/base.py", line 350, in forward
    x = self.get_cam_feats(img, depth, mats_dict)
  File "/usr/local/lib/python3.10/dist-packages/mmcv/runner/fp16_utils.py", line 208, in new_func
    return old_func(*args, **kwargs)
TypeError: DepthLSSTransform.get_cam_feats() takes 3 positional arguments but 4 were given

Temporary solution
/bevfusion/mmdet3d/models/vtransforms/base.py
x = self.get_cam_feats(img, depth, mats_dict)
→     x = self.get_cam_feats(img, depth)
It could successfully executed but I am not sure if it's correct.
I just skip it.

I am also experiencing this error, how did you fix it?

Hello, I encountered a similar issue. Any solution?

I got the same error.

I resolved it by the following:
-- compare the code between test.py and visualize.py
-- since test.py works, check what is in test.py that is missing in visualize.py
-- one such missing code snippet relates to wrap_fp16_model
-- modify visualize.py accordingly to be the same as test.py

This is the same as #532, this should help: solution


[contracts] feat: Implement Protection Against Multicall Buys in Memecoin Launch

Issue: Implement Protection Against Multicall Buys in Memecoin Launch
Description
This issue addresses the need for enhanced security measures in the Unruggable Memecoin project to protect against potential attack vectors that could arise from the multicall feature, specifically during the coin launch phase. The proposed solution involves utilizing get_tx_info to limit purchases not just per account address but also per transaction hash.
Objective
To mitigate risks associated with multicall attacks where limits can be bypassed through multiple smart contract calls in the same transaction.
Implementation

Utilizing get_tx_info: Incorporate the use of get_tx_info in the transaction validation logic to retrieve the transaction hash.
Limit Per Transaction Hash: Implement a mechanism that enforces buying limits per transaction hash, in addition to the existing per-account address limits.
Integration with Buying Logic: Ensure this security feature is seamlessly integrated with the current buying logic and does not impede legitimate transactions.

Considerations

Efficiency: Ensure the solution is gas-efficient and does not significantly increase transaction costs.
Compatibility: Verify compatibility with existing smart contract functionalities and ensure no conflicts arise.
Testing: Rigorously test the implementation to validate its effectiveness in preventing multicall buy attacks and to ensure it does not interfere with normal buying processes.

Impact and Benefits

Enhanced Security: Significantly reduces the risk of multicall buy attacks during the coin launch phase.
Fairness: Ensures equitable buying opportunities for all participants by enforcing limits consistently.

Could I try this one? :D

I can work on this one

Hey, I have raised the PR #81

Can this be closed or is there anything else needed to be done here?

Closed in #81 (people remember to link PR to issues!)


react/prop-types breaks when propTypes use spread operator

In a component similar to this one:
static propTypes = {
  foo: PropTypes.string,
}

componentDidMount() {
  const { foo, bar } = this.props;
  console.log(foo, bar);
}

react/prop-types complains that 'bar' is missing in props validation, which is correct.
However, if I change the propTypes to
static propTypes = {
  foo: PropTypes.string,
  ...{ other: PropTypes.bool, stuff: PropTypes.func },
}

eslint will pass, which seems to be a bug.
I did not find any similar issue here on github, but maybe I just missed it.

The spread is basically impossible to statically analyze; but I’d still expect the error on foo, since it’s defined statically.

You mean bar, right?
I think the addition of something, even if not statically analyzable, should not prevent the rest from being statically analyzable, because it seems like this is the case.

ahhh right, that's why. Because we can't determine if bar is present or not, we currently treat a spread as "all possible props".
If we errored on bar here, and you'd actually brought it in via the spread, then you'd be forced to silence the false positive, or to duplicate the bar declaration.

I see! That's what I presumed. Thank you for clarifying that!
I wonder if would make sense to make an option out of that:

throw an error regardless of the spread, which could lead to false positives
Treat the spread as "all possible prop" as it is right now.

I don't know if that's worth the effort, though.

I'm noticing something similar. I have the following rules set up
"react/prop-types": [
  "error",
  {
    "ignore": [],
    "customValidators": [],
    "skipUndeclared": false
  }
],

And the following component
const Force = ({ type, emitterId, id, fx, fy, fz, life, easing, update }) => (
  <Behaviour {...{ type, emitterId, id, easing, update }}>
    <ControlsBlock>
      <NumberInput
        defaultValue={fx}
        label="fx"
        onValueUpdate={fx => update(type, emitterId, id, { fx })}
      />
      <NumberInput
        defaultValue={fy}
        label="fy"
        onValueUpdate={fy => update(type, emitterId, id, { fy })}
      />
      <NumberInput
        defaultValue={fz}
        label="fz"
        onValueUpdate={fz => update(type, emitterId, id, { fz })}
      />
    </ControlsBlock>
  </Behaviour>
);

Does not cause any prop type validations to display errors. If I remove the spread object completely, the rules work again.

I’d suggest avoiding spreading props entirely; one big benefit is regaining the static analysis that doing so prevents.

What you suggest is going against DRY quite a bit though and this is an extremely common React pattern so I don’t think people are going to stop doing it.

@ljharb thanks for the "you're holding your phone wrong" kind of comment. Is there any technical reason that you're not supporting basics of the language, or is just your opinion pushed onto others?

@brandonaaskov the technical reason is that it's impractical and/or impossible to figure out, statically, what's inside spread props. My opinion is that this problem shouldn't come up in the first place - but the problem remains unavoidable.
There's plenty basics in the language that nobody should ever use; that's what linters are for - to stop you from using bad parts of the language.

@ljharb are you saying that the spread operator is, in your opinion (I really need to keep emphasizing that word), a bad part of the language? I think a lot of people would disagree with you. I think that. I don't know that. Kind of like an opinion.
I get that this is open source software, but I didn't write it and open source it, y'all did. There's an expectation and assumption that the creators of any product actually care about the audience they're creating it for. So when you say that it's "impractical" I would say, to whom? Doesn't seem impractical to me as an end user of these tools.
And when you say that it's "impossible to figure out, statically..." you're again misunderstanding your audience. Most of the people using these tools are using them because they don't want to know/care about that lower level stuff. Which makes projects like this great. But it makes responses like yours condescending and unhelpful. Since the problem remains unavoidable by your own admission, perhaps it's a problem worth solving.
I'm going to point out one last time that you're pushing your opinions and not listening. You said yourself:
"I’d suggest avoiding spreading props entirely; one big benefit is regaining the static analysis that doing so prevents." You'd suggest....
Well a suggestion is one thing, but now you're saying it's a must. And if I don't care about that "big benefit", I should be able to opt out of it. React, for example, suggests that you shouldn't set HTML from code with innerHTML, and gives you the opportunity to ignore that suggestion. They let you opt out of that "big benefit."
And lastly, "There's plenty basics in the language that nobody should ever use; that's what linters are for".... Uhhhhh.... No??? Do you really think a linter's primary function is to "fix" broken aspects of the language? Maybe that's what you think they're for, but for the majority of javascript devs, the primary reason is to maintain a consistent code style across codebases and teams.

@brandonaaskov no, i'm saying that "spread syntax exists in the language" is, like for every language feature, insufficient justification on its own to use it.
Yes, a linter's primary function is ABSOLUTELY to fix the broken parts of the language, including "there's more than one way to do something".
This issue has "help wanted". If you want it to happen, write a PR. Effectively accusing me of not improving the software because of my personal opinions is hostile, inappropriate, unprofessional, and unwelcome here.

@ljharb... you're just gonna shut down the discussion unceremoniously? Great communicator. What an adult. I didn't even say anything mean or offensive. I had no idea you had such delicate sensibilities.

And for the record, I accused you of not listening to your audience because your ego is in the way. And I stand by that, but I'm happy to leave that comment on Twitter or something if you think that's a better place for it.

I marked the issue as "help wanted", long before offering my opinion. That means I have ALREADY listened, and explicitly indicated a PR to solve it would be accepted.
You're accusation is ridiculous, because offering an opinion is not "not listening".

Given the options in https://github.com/yannickcr/eslint-plugin-react/issues/2195#issuecomment-472358331, I think there's nothing to be done here.
If someone believes differently, a PR with test cases would be welcome.

@ljharb can you explain why "The spread is basically impossible to statically analyze" I'm not seeing how that is true.
If you mean within the same file, you're right, since variables could come from anywhere. It would require that the code tree walk to find the source of the variable that is being spread, that's possible but would have negative performance impact.
I still feel that this is critical to remaining DRY propType declarations.

eslint only operates within the same file.


add countTokensVertex to support different request format.

This looks pretty good, but I think we can make ourselves safe from potential changes to the other APIs with a tweak.
https://github.com/google-gemini/generative-ai-dart/pull/180
The usage should look pretty similar for you - the parse* method is already exposed, so the vertex implementation can pretty much match this implementation with a different body JSON content.
WDYT?


Add TON (The Open Network)

https://github.com/ton-community/awesome-ton
This PR is to include the TON (The Open Network) in the Decentralized Systems list. TON is a scalable and flexible blockchain platform developed by Telegram, that aims to bring speed, efficiency, and broader usability to decentralized transactions and services.
The included resource, ton-community/awesome-ton, is a curated list of awesome resources, tools, and projects related to TON. It covers a wide range of categories from wallets and explorers to development resources, making it a valuable addition to the list for developers and enthusiasts in the blockchain community.
Thank you for considering this addition.
PR Review

https://github.com/sindresorhus/awesome/pull/2647#issuecomment-1568862506
https://github.com/sindresorhus/awesome/pull/2642#issuecomment-1568866147
https://github.com/sindresorhus/awesome/pull/2640#issuecomment-1568881327

By submitting this pull request I confirm I've read and complied with the below requirements 🖖
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.
Requirements for your pull request

[x] Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it. Instead use #2242 for incubation visibility.
[x] Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
[x] You have to review at least 2 other open pull requests.
Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions. Comments pointing out lint violation are allowed, but does not count as a review.
[x] You have read and understood the instructions for creating a list.
[x] This pull request has a title in the format Add Name of List. It should not contain the word Awesome.

✅ Add Swift
✅ Add Software Architecture
❌ Update readme.md
❌ Add Awesome Swift
❌ Add swift
❌ add Swift
❌ Adding Swift
❌ Added Swift

[x] Your entry here should include a short description about the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb.

✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
✅ - [Framer](…) - Prototyping interactive UI designs.
❌ - [iOS](…) - Resources and tools for iOS development.
❌ - [Framer](…)
❌ - [Framer](…) - prototyping interactive UI designs

[x] Your entry should be added at the bottom of the appropriate category.
[x] The title of your entry should be title-cased and the URL to your list should end in #readme.

Example: - [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.

[x] The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

[x] Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
[x] Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
https://github.com/ton-community/awesome-ton/pull/42
[x] The default branch should be named main, not master.
[x] Includes a succinct description of the project/theme at the top of the readme. (Example)

✅ Mobile operating system for Apple phones and tablets.
✅ Prototyping interactive UI designs.
❌ Resources and tools for iOS development.
❌ Awesome Framer packages and tools.

[x] It's the result of hard work and the best I could possibly produce.
If you have not put in considerable effort into your list, your pull request will be immediately closed.
[x] The repo name of your list should be in lowercase slug format: awesome-name-of-list.

✅ awesome-swift
✅ awesome-web-typography
❌ awesome-Swift
❌ AwesomeWebTypography

[x] The heading title of your list should be in title case format: # Awesome Name of List.

✅ # Awesome Swift
✅ # Awesome Web Typography
❌ # awesome-swift
❌ # AwesomeSwift

[x] Non-generated Markdown file in a GitHub repo.
[x] The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
[x] Not a duplicate. Please search for existing submissions.
https://github.com/ton-community/awesome-ton/pull/44
[x] Only has awesome items. Awesome lists are curations of the best, not everything.
[x] Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
https://github.com/ton-community/awesome-ton/pull/50
[x] Includes a project logo/illustration whenever possible.
https://github.com/ton-community/awesome-ton/pull/44

Either centered, fullwidth, or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

[x] Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
[x] Includes the Awesome badge.
https://github.com/ton-community/awesome-ton/pull/48

Should be placed on the right side of the readme heading.

Can be placed centered if the list has a centered graphics header.

Should link back to this list.

[x] Has a Table of Contents section.
https://github.com/ton-community/awesome-ton/pull/42

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of nested lists, preferably none.
Must not feature Contributing or Footnotes sections.

[x] Has an appropriate license.
https://github.com/ton-community/awesome-ton/pull/43

We strongly recommend the CC0 license, but any Creative Commons license will work.

Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=main&template=cc0-1.0 (replace <user> and <repo> accordingly).

A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
Place a file named license or LICENSE in the repo root with the license text.
Do not add the license name, text, or a Licence section to the readme. GitHub already shows the license name and link to the full text at the top of the repo.
To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.

[x] Has contribution guidelines.
https://github.com/ton-community/awesome-ton/pull/42

The file should be named contributing.md. Casing is up to you.
It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
The section should not appear in the Table of Contents.

[x] All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
[x] Has consistent formatting and proper spelling/grammar.
https://github.com/ton-community/awesome-ton/pull/44

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

[x] Does not use hard-wrapping.
[x] Does not include a CI (e.g. GitHub Actions) badge.You can still use a CI for linting, but the badge has no value in the readme.
https://github.com/ton-community/awesome-ton/pull/42
[x] Does not include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

Thanks for making an Awesome list! 🙌
It looks like you didn't read the guidelines closely enough. I noticed multiple things that are not followed. Try going through the list point for point to ensure you follow it. I spent a lot of time creating the guidelines so I wouldn't have to comment on common mistakes, and rather spend my time improving Awesome.

The entry must be moved to the bottom of "Decentralized Systems" as stated in the guidelines: Your entry should be added at the bottom of the appropriate category.

I have completed the modifications you suggested. Thank you for your feedback.

unicorn

Thanks for the PR, but I have decided to not accept any more blockchain related lists. I'm getting too many of them and I'm not interested in being a promotion channel for blockchains.


hook.sh: line 217: $1: unbound variable

Attempting to renew with LetsEncrypt in FreeBSD 13.1-RELEASE-p7 produces the error:
/usr/local/etc/dehydrated/hook.sh: line 217: $1: unbound variable
Line 217 appears to be the following function:
startup_hook() {
  # This hook is called before the cron command to do some initial tasks
  # (e.g. starting a webserver).

  :
}

Can you give any more details? From what I see the hook scripts aren't even configured by default in the freebsd dehydrated port. And the hook script should never be called without an argument so $1 should always be defined.

Thank you! It seems a new FreeBSD package built by my poudriere on 17th January inserted a hook.sh script which was called automatically since I had /usr/local/etc/dehydrated configured as CONFGI_D. Maybe that was wrong. I shall try commenting it out.


Update to version 1.11.0 failing

Issue Type: Bug
Running Win10 on a Dell XPS 15 laptop. The updater launches then freezes. I  have to end the process in task manager. This is also causing general PC performance issues while it is frozen.
Azure Data Studio version: azuredatastudio 1.10.0 (5fdb967ffcea41df0335ec17cfa396a694bb174e, 2019-08-14T18:28:10.311Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2808)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwareoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.83GB (4.68GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions: none

@theGrower how long did the the installer hang prior to killing it?
When performing an upgrade the first the installer does is to uninstall the previous version, during which time the progress bar won't be updated.  The uninstall typically takes a minute or two depending on hardware, load on the machine, etc.

@theGrower how long did the the installer hang prior to killing it?
When performing an upgrade the first the installer does is to uninstall the previous version, during which time the progress bar won't be updated. The uninstall typically takes a minute or two depending on hardware, load on the machine, etc.

10 minutes the first time. I tried a two more times and stopped the process after 4 or so minutes.
I ended up upgrading using the installer downloaded from the website.

@theGrower thanks for the additional details!  We'll take a look.

We haven't been able to reproduce this issue internally and haven't seen other reports for the 1.12 or 1.13 release.  So I'll close this issue out now.  Please let me know if you continued to see this bug on 1.12 or 1.13 updates.  Thanks!

It happened again on 1.12. However, for 1.13 I just started the update and came back after a 20 minute meeting and it worked. Who knows. My guess is it is an environmental issue in my machine. Thanks for your due diligence.


chore(deps): update all non-major dependencies (v1)

This PR contains the following updates:

Package
Type
Update
Change

@commitlint/cli (source)
devDependencies
patch
^19.6.0 -> ^19.6.1

@iconify/json (source)
devDependencies
patch
^2.2.277 -> ^2.2.290

@nuxt/ui (source)
dependencies
patch
^3.0.0-alpha.9 -> ^3.0.0-alpha.10

@nuxt/ui-pro
dependencies
patch
^3.0.0-alpha.9 -> ^3.0.0-alpha.10

@nuxtjs/i18n (source)
devDependencies
patch
^9.1.0 -> ^9.1.1

@types/node (source)
devDependencies
patch
^22.10.1 -> ^22.10.2

@vueuse/nuxt (source)
devDependencies
minor
^12.0.0 -> ^12.2.0

lint-staged
devDependencies
minor
^15.2.10 -> ^15.3.0

node
final
minor
22.11-alpine -> 22.12.0-alpine

node
stage
minor
22.11-alpine -> 22.12.0-alpine

nuxt (source)
devDependencies
minor
^3.14.1592 -> ^3.15.0

nuxt-zod-i18n
devDependencies
patch
^1.11.0 -> ^1.11.2

pnpm (source)
packageManager
minor
9.14.2 -> 9.15.2

unocss
devDependencies
minor
^0.64.1 -> ^0.65.3

unplugin-vue-components
devDependencies
minor
^0.27.5 -> ^0.28.0

vite (source)
devDependencies
patch
^6.0.1 -> ^6.0.6

vue-tsc (source)
devDependencies
minor
^2.1.10 -> ^2.2.0

yaml (source)
dependencies
minor
^2.6.1 -> ^2.7.0

zod (source)
dependencies
minor
^3.23.8 -> ^3.24.1

[!WARNING]
Some dependencies could not be looked up. Check the warning logs for more information.

Release Notes

conventional-changelog/commitlint (@commitlint/cli)
v19.6.1
Compare Source
Note: Version bump only for package @commitlint/cli

iconify/icon-sets (@iconify/json)
v2.2.290
Compare Source
v2.2.289
Compare Source
v2.2.288
Compare Source
v2.2.287
Compare Source
v2.2.286
Compare Source
v2.2.285
Compare Source
v2.2.284
Compare Source
v2.2.283
Compare Source
v2.2.282
Compare Source
v2.2.281
Compare Source
v2.2.280
Compare Source
v2.2.279
Compare Source
v2.2.278
Compare Source

nuxt/ui (@nuxt/ui)
v3.0.0-alpha.10
Compare Source
⚠ BREAKING CHANGES

module: migrate to reka-ui (#2448)
Form: resolve async validation in yup & issue directly mutate state (#2702)

Features

Avatar: add default slot for fallback (b741ef3)
Calendar: add icon props (#2778) (0f64802)
Calendar: implement component (#2618) (2e9aeb5)
ColorPicker: implement component (#2670) (e475b64)
CommandPalette: add active field on items for consistency (3765537)
css: use color-scheme utilities on body (a2512f6)
i18n: add Dutch locale (#2728) (3baddfd)
i18n: add Turkish locale (#2716) (de8228e)
locale: add Brazilian Portuguese language (#2825) (b7ff7d8)
locale: add Japanese language (#2794) (ecc4755)
locale: add Portuguese language (#2855) (8b5d412)
locale: add Slovak language (#2821) (68a10f0)
locale: translate Korean (#2703) (2cbf83e)
module: migrate to reka-ui (#2448) (81ac076)
NavigationMenu: handle item.trailingIcon display (4b653ef)
Stepper: new component (#2733) (6484d01)
Table: handle meta.class on th and td (#2790) (004a577)

Bug Fixes

Breadcrumb: missing aria-hidden on presentation items (a7a1227), closes #2725
Calendar: handle icons in RTL mode (#2770) (e7b69b7)
Calendar: omit as / asChild props (9478fc0)
ColorPicker: handle RTL mode (#2858) (f98b91c)
CommandPalette: keep ignoreFilter groups at their place (#2833) (3b9ca22)
components: apply class on trigger instead of content when present (a6ecef0), closes #2132
components: specify collisionPadding to all menus (148b024)
ContextMenu: remove close animation (#2798) (ed27222)
defineShortcuts: return useEventListener to unregister the listener (80befc1), closes #2031
devtools: error with renderer when colorMode is disabled (#2792) (f06fbaf)
Form: resolve async validation in yup & issue directly mutate state (#2702) (c9806da)
icons: make loading icon clockwise (#2797) (bc2bcb3)
Link: partial query match for Vue (#2787) (a6c2205)
locale: improve German translation (#2826) (c440c91)
Modal: prevent from going out of screen (b7ba2c7), closes #2711
NavigationMenu: wrong badge class (86f2b48), closes #2766
Progress: handle horizontal animation in RTL mode (#2723) (0baa3a0)
Stepper: handle RTL mode (#2844) (198d04d)
Stepper: missing import (816bb69)
Table: handle loading animation in RTL mode (#2771) (b1550d5)
Tabs: prevent hover on disabled (a938d24)
Tabs: truncate not working (c1ff978)
types: handle array of strings in AppConfig (#2854) (4b241ba)
useLocale: update locale import to enable tree shaking (#2735) (3bccb67)

nuxt-modules/i18n (@nuxtjs/i18n)
v9.1.1
Compare Source
This changelog is generated by GitHub Releases
🚀 Features

Configurable bundle.optimizeTranslationDirective  -  by @BobbieGoede in https://github.com/nuxt-modules/i18n/issues/3256 (1b457)

🐞 Bug Fixes

Default language multi domain locales  -  by @DotwoodMedia and Vincent de Vreede in https://github.com/nuxt-modules/i18n/issues/3250 (7f7ea)

View changes on GitHub

vueuse/vueuse (@vueuse/nuxt)
v12.2.0
Compare Source
🚀 Features

useArrayDifference: New symmetric option  -  by @wangliangxin, wangliangxin3 and @antfu in https://github.com/vueuse/vueuse/issues/4146 (46fdc)
useEventSource: New autoConnect option to align with useWebSocket  -  by @ferferga and @antfu in https://github.com/vueuse/vueuse/issues/4204 (230f8)
useImage: Support more native option  -  by @btea and @antfu in https://github.com/vueuse/vueuse/issues/4173 (4ca72)
usePreferredReducedTransparency: Add new function  -  by @huiliangShen and @antfu in https://github.com/vueuse/vueuse/issues/4201 (34cd7)

🐞 Bug Fixes

useWebSocket: Clear retryTimer when connected  -  by @ilyaliao and @antfu in https://github.com/vueuse/vueuse/issues/4383 (ffa00)

View changes on GitHub
v12.1.0
Compare Source
🚀 Features

createEventHook: Add clear function  -  by @ilyaliao in https://github.com/vueuse/vueuse/issues/4378 (40265)
useBase64: Add options for Data URL output control  -  by @ilyaliao and Jelf in https://github.com/vueuse/vueuse/issues/4316 (4b4bd)
useDeviceMotion: Add permission controls, improve destructure  -  by @thefeymesaleng and @antfu in https://github.com/vueuse/vueuse/issues/4127 (cf729)
useElementVisibility: Add rootMargin option  -  by @dritter and @antfu in https://github.com/vueuse/vueuse/issues/4100 (3a928)
useMediaControls: Add 'media' option to define media query for resources  -  by @aaronLejeune in https://github.com/vueuse/vueuse/issues/4344 (209de)
useRafFn: Allow framerate to be a reactive value  -  by @OrbisK and Anthony Fu in https://github.com/vueuse/vueuse/issues/4409 (4759f)
useSSRWidth: Add optional support for SSR in useMediaQuery and useBreakpoints  -  by @Tofandel, Anthony Fu and @antfu in https://github.com/vueuse/vueuse/issues/4317 (55965)
useUrlSearchParams: Add writeMode options  -  by @ishakhorski, Ivan Shakhorski and @antfu in https://github.com/vueuse/vueuse/issues/4392 (2c972)
useWebSocket: Introduce autoConnect options to control auto connections on url changes  -  by @ilyaliao and @antfu in https://github.com/vueuse/vueuse/issues/4417 (05e75)
useWebsocket: Support ref or getter as message  -  by @SnowGuest, Anthony Fu and @antfu in https://github.com/vueuse/vueuse/issues/4116 (a72c0)
useWindowSize: Add type: visual option that leverage visualViewport  -  by @huiliangShen and @antfu in https://github.com/vueuse/vueuse/issues/4395 (e78ef)

🐞 Bug Fixes

injectLocal: Allow inject to app context  -  by @antfu (b08a9)
useAsyncState: Use ShallowRef instead of Ref type  -  by @joris-gallot and Anthony Fu in https://github.com/vueuse/vueuse/issues/4294 (4d0a7)
useDropZone: Update type to allow readonly array param  -  by @briankchan in https://github.com/vueuse/vueuse/issues/4319 (df363)
useFetch: Handle empty payload  -  by @ilyaliao in https://github.com/vueuse/vueuse/issues/4366 (8a89d)
useMediaQuery: The return value should be computed  -  by @alexzhang1030 and @antfu in https://github.com/vueuse/vueuse/issues/4403 (3af75)
useRouteParams,useRouteQuery: Set route param/query to undefined when defaultValue is ref or getter  -  by @vojvodics and Anthony Fu in https://github.com/vueuse/vueuse/issues/3977 (23fdb)
useScroll: To properly report arriveState for elastic scroll  -  by @719media and Anthony Fu in https://github.com/vueuse/vueuse/issues/4133 (90ff4)
useTextareaAutosize: Make input required  -  by @axuj, @antfu and Anthony Fu in https://github.com/vueuse/vueuse/issues/4129 (25ed2)
useWebNotification: Prevent notifications when checking for support  -  by @9romise in https://github.com/vueuse/vueuse/issues/4019 (01f92)
useWebSocket: Close socket connection inside WebWorker fix  -  by @catz in https://github.com/vueuse/vueuse/issues/4229 (ece6a)

View changes on GitHub

lint-staged/lint-staged (lint-staged)
v15.3.0
Compare Source
Minor Changes

#1495 e69da9e Thanks @iiroj! - Added more info to the debug logs so that "environment" info doesn't need to be added separately to GitHub issues.

#1493 fa0fe98 Thanks @iiroj! - Added more help messages around the automatic git stash that lint-staged creates as a backup (by default). The console output also displays the short git hash of the stash so that it's easier to recover lost files in case some fatal errors are encountered, or the process is killed before completing.
For example:
% npx lint-staged
✔ Backed up original state in git stash (20addf8)
✔ Running tasks for staged files...
✔ Applying modifications from tasks...
✔ Cleaning up temporary files...

where the backup can be seen with git show 20addf8, or git stash list:
% git stash list
stash@{0}: lint-staged automatic backup (20addf8)

v15.2.11
Compare Source
Patch Changes

#1484 bcfe309 Thanks @wormsik! - Escape paths containing spaces when using the "shell" option.

#1487 7dd8caa Thanks @iiroj! - Do not treat submodule root paths as "staged files". This caused lint-staged to fail to a Git error when only updating the revision of a submodule.

nodejs/node (node)
v22.12.0: 2024-12-03, Version 22.12.0 'Jod' (LTS), @ruyadorno
Compare Source
Notable Changes
require(esm) is now enabled by default
Support for loading native ES modules using require() had been available on v20.x and v22.x under the command line flag --experimental-require-module, and available by default on v23.x. In this release, it is now no longer behind a flag on v22.x.
This feature is still experimental, and we are looking for user feedback to make more final tweaks before fully stabilizing it. For this reason, on v22.x, when the Node.js instance encounters a native ES module in require() for the first time, it will emit an experimental warning unless require() comes from a path that contains node_modules. If there happens to be any regressions caused by this feature, users can report it to the Node.js issue tracker. Meanwhile this feature can also be disabled using --no-experimental-require-module as a workaround.
With this feature enabled, Node.js will no longer throw ERR_REQUIRE_ESM if require() is used to load a ES module. It can, however, throw ERR_REQUIRE_ASYNC_MODULE if the ES module being loaded or its dependencies contain top-level await. When the ES module is loaded successfully by require(), the returned object will either be a ES module namespace object similar to what's returned by import(), or what gets exported as "module.exports" in the ES module.
Users can check process.features.require_module to see whether require(esm) is enabled in the current Node.js instance. For packages, the "module-sync" exports condition can be used as a way to detect require(esm) support in the current Node.js instance and allow both require() and import to load the same native ES module. See the documentation for more details about this feature.
Contributed by Joyee Cheung in #55085
Added resizable ArrayBuffer support in Buffer
When a Buffer is created using a resizable ArrayBuffer, the Buffer length will now correctly change as the underlying ArrayBuffer size is changed.
const ab = new ArrayBuffer(10, { maxByteLength: 20 });
const buffer = Buffer.from(ab);
console.log(buffer.byteLength); 10
ab.resize(15);
console.log(buffer.byteLength); 15
ab.resize(5);
console.log(buffer.byteLength); 5

Contributed by James Snell in #55377
Update root certificates to NSS 3.104
This is the version of NSS that shipped in Firefox 131.0 on 2024-10-01.
Certificates added:

FIRMAPROFESIONAL CA ROOT-A WEB
TWCA CYBER Root CA
SecureSign Root CA12
SecureSign Root CA14
SecureSign Root CA15

Contributed by Richard Lau in #55681
Other Notable Changes

[4920869935] - (SEMVER-MINOR) assert: make assertion_error use Myers diff algorithm (Giovanni Bucci) #54862
[ccffd3b819] - doc: enforce strict policy to semver-major releases (Rafael Gonzaga) #55732
[acc6806900] - doc: add jazelly to collaborators (Jason Zhang) #55531
[88d91e8bc2] - esm: mark import attributes and JSON module as stable (Nicolò Ribaudo) #55333
[98bfc7dce5] - (SEMVER-MINOR) http: add diagnostic channel http.client.request.created (Marco Ippolito) #55586
[337f61fb25] - (SEMVER-MINOR) lib: add UV_UDP_REUSEPORT for udp (theanarkh) #55403
[1628c48ad6] - (SEMVER-MINOR) net: add UV_TCP_REUSEPORT for tcp (theanarkh) #55408
[457e73f4c9] - (SEMVER-MINOR) sqlite: add support for SQLite Session Extension (Bart Louwers) #54181

Commits

[f6885e1c68] - assert: fix the string length check for printing the simple diff (Giovanni Bucci) #55474
[907484f04d] - assert: fix deepEqual always return true on URL (Xuguang Mei) #50853
[301844e249] - assert: differentiate cases where cause is undefined or missing (Antoine du Hamel) #55738
[89ccd3e3f4] - assert: fix deepStrictEqual on errors when cause is not undefined (Edigleysson Silva (Edy)) #55406
[4920869935] - (SEMVER-MINOR) assert: make assertion_error use Myers diff algorithm (Giovanni Bucci) #54862
[c67aec368e] - benchmark: add test-reporters (Aviv Keller) #55757
[49774cc2c0] - benchmark: add test_runner/mock-fn (Aviv Keller) #55771
[4caaeb47b2] - benchmark: add nodeTiming.uvmetricsinfo bench (RafaelGSS) #55614
[cac58564a1] - benchmark: add --runs support to run.js (Rafael Gonzaga) #55158
[5c3ee886fc] - benchmark: adjust byte size for buffer-copy (Rafael Gonzaga) #55295
[6023e1bdb2] - (SEMVER-MINOR) buffer: make Buffer work with resizable ArrayBuffer (James M Snell) #55377
[a6c00c2204] - build: add create release proposal action (Rafael Gonzaga) #55690
[b4e413933b] - build: implement node_use_amaro flag in GN build (Cheng) #55798
[d1db202d4a] - build: apply cpp linting and formatting to ncrypto (Aviv Keller) #55362
[8c670496da] - build: use rclone instead of aws CLI (Michaël Zasso) #55617
[827e2065bd] - build: stop pre-compiling lint-md (Aviv Keller) #55266
[c3ca978d9c] - build: fix building with system icu 76 (Michael Cho) #55563
[23e3287bbe] - build: fix GN arg used in generate_config_gypi.py (Shelley Vohr) #55530
[2b561abb0d] - build: fix GN build for sqlite and nghttp2 (Shelley Vohr) #55529
[7008f29d79] - build: fix GN build for cares/uv deps (Cheng) #55477
[6ee94a394f] - build: fix uninstall script for AIX 7.1 (Cloorc) #55438
[edbbd4a374] - build: conditionally compile bundled sqlite (Richard Lau) #55409
[3d8e3a657c] - build: tidy up cares.gyp (Richard Lau) #55445
[f0c12e8fcb] - build: synchronize list of c-ares source files (Richard Lau) #55445
[8daa8a62f8] - build: fix path concatenation (Mohammed Keyvanzadeh) #55387
[12faf0466e] - build: fix make errors that occur in Makefile (minkyu_kim) #55287
[a21be0294d] - build,win: enable pch for clang-cl (Stefan Stojanovic) #55249
[7ed058cd00] - cli: add --heap-prof flag available to NODE_OPTIONS (Juan José) #54259
[c26b1bfe6a] - crypto: allow length=0 for HKDF and PBKDF2 in SubtleCrypto.deriveBits (Filip Skokan) #55866
[a1201d0392] - crypto: update root certificates to NSS 3.104 (Richard Lau) #55681
[20483aab7a] - crypto: fix RSA_PKCS1_PADDING error message (Richard Lau) #55629
[d345662d50] - crypto: include openssl/rand.h explicitly (Shelley Vohr) #55425
[166ab3209d] - deps: update simdutf to 5.6.1 (Node.js GitHub Bot) #55850
[934979e12e] - deps: update undici to 6.21.0 (Node.js GitHub Bot) #55851
[af77f66424] - deps: update c-ares to v1.34.3 (Node.js GitHub Bot) #55803
[948a88d2f4] - deps: update icu to 76.1 (Node.js GitHub Bot) #55551
[fa4c58a983] - deps: update acorn to 8.14.0 (Node.js GitHub Bot) #55699
[c91155f22e] - deps: update sqlite to 3.47.0 (Node.js GitHub Bot) #55557
[d1cb7af95c] - deps: update amaro to 0.2.0 (Node.js GitHub Bot) #55601
[655e5600cb] - deps: update nghttp2 to 1.64.0 (Node.js GitHub Bot) #55559
[992450c469] - deps: update acorn to 8.13.0 (Node.js GitHub Bot) #55558
[abd2bd4f64] - deps: update undici to 6.20.1 (Node.js GitHub Bot) #55503
[7dc2c2edad] - deps: update googletest to df1544b (Node.js GitHub Bot) #55465
[fa9329c024] - deps: update c-ares to v1.34.2 (Node.js GitHub Bot) #55463
[41a2bcd335] - deps: update ada to 2.9.1 (Node.js GitHub Bot) #54679
[a3b793defd] - deps: update simdutf to 5.6.0 (Node.js GitHub Bot) #55379
[551b8f897d] - deps: update c-ares to v1.34.1 (Node.js GitHub Bot) #55369
[26861eaf4e] - Revert "deps: disable io_uring support in libuv by default" (Santiago Gimeno) #55114
[41c50bc15e] - deps: update libuv to 1.49.1 (Santiago Gimeno) #55114
[26fcc04084] - deps: update amaro to 0.1.9 (Node.js GitHub Bot) #55348
[0ee6715921] - diagnostics_channel: fix unsubscribe during publish (simon-id) #55116
[bf68733e7f] - dns: stop using deprecated ares_query (Aviv Keller) #55430
[ef6707eb9b] - dns: honor the order option (Luigi Pinca) #55392
[0f3810f3e5] - doc: add added tag and fix typo sqlite.md (Bart Louwers) #56012
[d1bd0ef1b7] - doc: remove non-working example (Antoine du Hamel) #55856
[824ac650ed] - doc: add node:sqlite to mandatory node: prefix list (翠 / green) #55846
[b3ea42d887] - doc: add -S flag release preparation example (Antoine du Hamel) #55836
[0bd5d8b9d9] - doc: clarify UV_THREADPOOL_SIZE env var usage (Preveen P) #55832
[27b0236a99] - doc: add notable-change mention to sec release (Rafael Gonzaga) #55830
[476075bada] - doc: fix history info for URL.prototype.toJSON (Antoine du Hamel) #55818
[2743b7b1d3] - doc: correct max-semi-space-size statement (Joe Bowbeer) #55812
[3013870093] - doc: update unflag info of import.meta.resolve (skyclouds2001) #55810
[27bcd103e7] - doc: run license-builder (github-actions[bot]) #55813
[72d4b30ead] - doc: clarify triager role (Gireesh Punathil) #55775
[a30defe9dd] - doc: clarify removal of experimental API does not require a deprecation (Antoine du Hamel) #55746
[ccffd3b819] - doc: enforce strict policy to semver-major releases (Rafael Gonzaga) #55732
[b6d2a4e816] - doc: add path aliases typescript doc (Carlos Espa) #55766
[a435affa11] - doc: add esm example in path.md (Aviv Keller) #55745
[91443c2711] - doc: consistent use of word child process (Gireesh Punathil) #55654
[83fb0079d4] - doc: clarity to available addon options (Preveen P) #55715
[6ca851457a] - doc: update --max-semi-space-size description (Joe Bowbeer) #55495
[e17fffc0ff] - doc: broken PerformanceObserver code sample (Dom Harrington) #54227
[8bd5777f0f] - doc: add write flag when open file as the demo code's intention (robberfree) #54626
[f1e0e0ba55] - doc: remove mention of ECDH-ES in crypto.diffieHellman (Filip Skokan) #55611
[1d60b7ec97] - doc: improve c++ embedder API doc (Gireesh Punathil) #55597
[bbf51d7000] - doc: capitalize "MIT License" (Aviv Keller) #55575
[0e69f6d123] - doc: add suggested tsconfig for type stripping (Marco Ippolito) #55534
[67beb37f50] - doc: add esm examples to node:string_decoder (Alfredo González) #55507
[acc6806900] - doc: add jazelly to collaborators (Jason Zhang) #55531
[a6b3ed54ae] - doc: changed the command used to verify SHASUMS256 (adriancuadrado) #55420
[0ad7ca4f1d] - doc: move dual package shipping docs to separate repo (Joyee Cheung) #55444
[e99a98ddfd] - doc: add note about stdio streams in child_process (Ederin (Ed) Igharoro) #55322
[20302851a9] - doc: add isBigIntObject to documentation (leviscar) #55450
[50d983e80b] - doc: remove outdated remarks about highWaterMark in fs (Ian Kerins) #55462
[07c2fb2045] - doc: move Danielle Adams key to old gpg keys (RafaelGSS) #55399
[41b045170d] - doc: move Bryan English key to old gpg keys (RafaelGSS) #55399
[13724dcc20] - doc: move Beth Griggs keys to old gpg keys (RafaelGSS) #55399
[0230fb1ead] - doc: spell out condition restrictions (Jan Martin) #55187
[66e41f044d] - doc: add instructions for WinGet build (Hüseyin Açacak) #55356
[23d89da3f1] - doc: add missing return values in buffer docs (Karl Horky) #55273
[6e7b33a0ef] - doc: fix ambasador markdown list (Rafael Gonzaga) #55361
[d8c552a060] - doc: edit onboarding guide to clarify when mailmap addition is needed (Antoine du Hamel) #55334
[c7f82ec978] - doc: fix the return type of outgoingMessage.setHeaders() (Jimmy Leung) #55290
[f1b9791694] - doc: update require(ESM) history and stability status (Antoine du Hamel) #55199
[9ffd2dd43b] - doc: consolidate history table of CustomEvent (Edigleysson Silva (Edy)) #55758
[64fb9e6516] - doc: add history entries for JSON modules stabilization (Antoine du Hamel) #55855
[ae2ae2fef1] - esm: fix import.meta.resolve crash (Marco Ippolito) #55777
[15dd43dd6e] - esm: add a fallback when importer in not a file (Antoine du Hamel) #55471
[aed758d270] - esm: fix inconsistency with importAssertion in resolve hook (Wei Zhu) #55365
[88d91e8bc2] - esm: mark import attributes and JSON module as stable (Nicolò Ribaudo) #55333
[a2c8de7fba] - events: add hasEventListener util for validate (Sunghoon) #55230
[4f84cdc8a2] - events: optimize EventTarget.addEventListener (Robert Nagy) #55312
[c17601557b] - fs: prevent unwanted dependencyOwners removal (Carlos Espa) #55565
[4dd609c685] - fs: fix bufferSize option for opendir recursive (Ethan Arrowood) #55744
[d695bd4c4f] - fs: pass correct path to DirentFromStats during glob (Aviv Keller) #55071
[5357338b8e] - fs: use wstring on Windows paths (jazelly) #55171
[0a7f301a36] - http: add diagnostic channel http.server.response.created (Marco Ippolito) #55622
[98bfc7dce5] - (SEMVER-MINOR) http: add diagnostic channel http.client.request.created (Marco Ippolito) #55586
[d2430ee363] - http2: fix client async storage persistence (Orgad Shaneh) #55460
[753cbede2a] - lib: remove startsWith/endsWith primordials for char checks (Gürgün Dayıoğlu) #55407
[6e3e99c81e] - lib: prefer logical assignment (Aviv Keller) #55044
[03902ebb74] - lib: replace createDeferredPromise util with Promise.withResolvers (Yagiz Nizipli) #54836
[ee17fcd6f3] - lib: prefer symbol to number in webidl type function (Antoine du Hamel) #55737
[18f0f07e92] - lib: implement webidl dictionary converter and use it in structuredClone (Jason Zhang) #55489
[bcead24e24] - lib: prefer number to string in webidl type fun

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Hywax Assistant.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: pnpm-lock.yaml
Scope: all 3 workspace projects
Progress: resolved 1, reused 0, downloaded 0, added 0
/tmp/renovate/repos/github/hywax/mafl/apps/mafl:
 ERR_PNPM_FETCH_404  GET https://npm.pkg.github.com/@hywax%2Ftools-eslint: Not Found - 404

This error happened while installing a direct dependency of /tmp/renovate/repos/github/hywax/mafl/apps/mafl

@hywax/tools-eslint is not in the npm registry, or you have no permission to fetch it.

An authorization header was used: Bearer ghp_[hidden]


Assertion fails when destroying rigid body

Assertion mNbNonUsedMovedShapes <= mNbMovedShapes (in function BroadphaseAlgorithm::removeMovedCollisionShape) fails seemingly at random upon destroying rigid bodies.
Edit: I don't know if this helps but if I create 3 rigid bodies and destroy them each before creating the next one, the assertion always fails when the third rigid body is destroyed.

Hello. Thanks a lot for reporting this.
If I understand correctly, you do the following:

Create body 1
Destroy body 1
Create body 2
Destroy body 2
Create body 3
Destroy body 3
Crash here !

Are you doing this before updating the world (calling the update() method on your world) or between several calls to the update() method ?

 Fix Bug #45 - Assert when destroying bodies

Yes exactly in the order you specified, I make multiple calls to world.update() in between. What I do is I create a new body every 2-4 seconds and destroy them each second after creating them.
Also the bodies all share the same ColissionShape, which is allocated in a separate pool and using unique_ptr

Hi, I've also been having the same issue. I'm creating 80+ rigid bodies for a level in a game, destroying them all when a new level is loaded, and then created a new set of rigid bodies. The error seems to occur randomly when destroying the them.

Ok thanks a lot. I will check into that.

I have pushed a modification in the master branch to fix this issue.
Can I ask you to check if the issue is now fixed on your side ?

That fixed it on my end

Great


[BUG] Dead link in config_template.yaml (dtdg.co/flag-hostname-fqdn)

Agent Environment
Current (in this repo)

Describe what happened:
In the config_template.yaml file, there is a shortened link (https://dtdg.co/flag-hostname-fqdn) that points to a dead end in Github.
Describe what you expected:
Redirect should not 404.
Steps to reproduce the issue:
Go to https://dtdg.co/flag-hostname-fqdn
Additional environment details (Operating System, Cloud provider, etc):
See config_template.yaml: https://github.com/DataDog/datadog-agent/blob/main/pkg/config/config_template.yaml#L103C24-L103C58

Hello @kyletaylored, thanks a lot for reporting this !
I'll open a fix.
This used to link to hostname-resolution.md which links to the official Datadog documentation about agent hostname resolution https://docs.datadoghq.com/agent/faq/how-datadog-agent-determines-the-hostname/?tab=agentv6v7.

Hey @kyletaylored, https://dtdg.co/flag-hostname-fqdn now redirects to the official documentation page directly.
Don't hesitate to re-open this issue if it's not fixed for you !


Include the addition of "ngCpfCnpj" module on documentation

The documentation does not mention that you should include the ngCpfCnpj within the other AngularJS modules, something like:
"var app = angular.module(myApplicationName, [ "cordovaHTTP", "ngMask", "ngRoute", "ngCpfCnpj" ])";
I know that it's something pretty obvious, but it may confuse some beginner developers.

I've just merged PR #4 with that fix. Sorry for the mistake and for taking so long to reply!


Add Japanese translation to node property of websocket node

Proposed changes
Because I found that the English message remains on the WebSocket node property in my Japanese browser environment, I added Japanese translations. To support the same change in other languages, I also modified other message catalogs.
Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the forum/slack team.
[x] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage remained the same at 77.592% when pulling 72126730efb4439d474f61d6077903f9989bfc0e on kazuhitoyokoi:master-updatemsgcatalog4websocketnode into 1c63d7ff317a556c6f4fef8413d8f2b988a59764 on node-red:master.

Thank you!


Add Gauge.modifyAndSample function

Should we add this to more than just Guage to keep the API consistent? What's your use case for this?

Sure, I can add this to the rest as well. The use case is we're developing a monitoring API (specifically an mtl-style typeclass) that is agnostic to backends (we want to support at least prometheus, prometheus push, and datadog). It is a lot nicer to have the class expose a modifyGauge function and then implement things like add and sub generically for all implementations, rather than having those special cases put into the interface implemented by the backend.

Makes sense. Yeah I think we should add it across all the metric types if it makes sense for completeness.

@LukeHoersten Done.


gnuradio-osmosdr: 0.1.4 -> 4d83c60, Added support for Soapysdr

Motivation for this change
I needed support for limeSDR in gnuradio and gqrx,
This can be accomplished by using limesuite via soapysdr and soapysdr via gr-osmosdr.
So this results in a rebuild of:

gnuradio-companion
gqrx
qradiolink

Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

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

hmm, awkward, mistyped my review script. Sorry