pulsecnt module seems to be "missing" in branch esp32-dev

So today I tryed my best to get the Pulse Counter working on my ESP32 but encountered some quite unique issues.
Output Log:

Full Log
I also find it interesting that the chip is doing something with wifi but the firmware shouldn't include this module.
(Re-Requesting build's also didn't do the trick)
node.restart()
> node.restart()
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6736
ho 0 tail 12 room 4
load:0x40078000,len:11116
load:0x40080400,len:5940
entry 0x40080700
I (73) boot: Chip Revision: 1
I (73) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (41) boot: ESP-IDF v3.3-beta2-887-g9e70825d1 2nd stage bootloader
I (41) boot: compile time 17:12:49
I (41) boot: Enabling RNG early entropy source...
I (48) boot: SPI Speed      : 40MHz
I (52) boot: SPI Mode       : DIO
I (56) boot: SPI Flash Size : 4MB
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 00180000
I (93) boot:  3 lfs              unknown          c2 01 00190000 00010000
I (101) boot:  4 nodemcuspiffs    unknown          c2 00 001a0000 00070000
I (108) boot: End of partition table
I (113) boot_comm: chip revision: 1, min. application chip revision: 0
I (120) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x24c30 (150576) map
I (180) esp_image: segment 1: paddr=0x00034c58 vaddr=0x3ffb0000 size=0x035e8 ( 13800) load
I (185) esp_image: segment 2: paddr=0x00038248 vaddr=0x40080000 size=0x00400 (  1024) load
I (187) esp_image: segment 3: paddr=0x00038650 vaddr=0x40080400 size=0x079c0 ( 31168) load
I (207) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0xa0478 (656504) map
I (430) esp_image: segment 5: paddr=0x000e0498 vaddr=0x40087dc0 size=0x0d5bc ( 54716) load
I (451) esp_image: segment 6: paddr=0x000eda5c vaddr=0x400c0000 size=0x00064 (   100) load
I (465) boot: Loaded app from partition at offset 0x10000
I (465) boot: Disabling RNG early entropy source...
I (465) cpu_start: Pro cpu up.
I (469) cpu_start: Application information:
I (474) cpu_start: Project name:     NodeMCU
I (479) cpu_start: App version:      dd3b217-dirty
I (484) cpu_start: Compile time:     Sep 15 2020 17:12:52
I (490) cpu_start: ELF file SHA256:  8de9dabc96a3e962...
I (496) cpu_start: ESP-IDF:          v3.3-beta2-887-g9e70825d1
I (503) cpu_start: Starting app cpu, entry point is 0x400812e8
I (489) cpu_start: App cpu up.
I (513) heap_init: Initializing. RAM available for dynamic allocation:
I (520) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (526) heap_init: At 3FFB9CC8 len 00026338 (152 KiB): DRAM
I (533) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (539) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (545) heap_init: At 4009537C len 0000AC84 (43 KiB): IRAM
I (551) cpu_start: Pro cpu start user code
I (234) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

Mounting flash filesystem...
No LFS image loaded
I (395) wifi:wifi driver task: 3ffc4430, prio:23, stack:3584, core=0
I (395) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (395) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (425) wifi:wifi firmware version: 44aa95c
I (425) wifi:config NVS flash: enabled
I (425) wifi:config nano formating: disabled
I (425) wifi:Init dynamic tx buffer num: 32
I (435) wifi:Init data frame dynamic rx buffer num: 32
I (435) wifi:Init management frame dynamic rx buffer num: 32
I (445) wifi:Init management short buffer num: 32
I (445) wifi:Init static rx buffer size: 1600
I (455) wifi:Init static rx buffer num: 10
I (455) wifi:Init dynamic rx buffer num: 32

NodeMCU ESP32 built with Docker provided by frightanic.com
  branch: dev-esp32
  commit: f4887bf134235c05e6c9b2efad370e6d5018f91a
  SSL: true
  modules: -
built on nodemcu-build.com provided by frightanic.com
  branch: dev-esp32
  commit: dd3b217df201fde00fcf84be1d485d555d433bed
  SSL: false
  modules: file,gpio,node,pulsecnt,tmr,uart
build 2020-09-15-17-10-55 powered by Lua 5.1.4 on ESP-IDF v3.3-beta1-1391-g9e70825d1 on SDK IDF
Hello World!
file
romtable: 0x3f4042a4
gpio
romtable: 0x3f404530
node
romtable: 0x3f403fe8
pulsecnt
nil
tmr
romtable: 0x3f404b34
uart
romtable: 0x3f409064

Code in question:

Firmware used:

integer
float
(tested both)

Tool-Chain used:
https://nodemcu-build.com/index.php
http://chilipeppr.com/esp32
https://github.com/marcelstoer/nodemcu-pyflasher/releases/download/v4.0/NodeMCU-PyFlasher-4.0-x64.exe
Flash Log:

I am unsure how to act further therefore im opening this issue (which is btw my first so please excuse me for the bad writeup)

This...does not make any sense at all.
NodeMCU ESP32 built with Docker provided by frightanic.com
  branch: dev-esp32
  commit: f4887bf134235c05e6c9b2efad370e6d5018f91a
  SSL: true
  modules: -
built on nodemcu-build.com provided by frightanic.com
  branch: dev-esp32
  commit: dd3b217df201fde00fcf84be1d485d555d433bed
  SSL: false
  modules: file,gpio,node,pulsecnt,tmr,uart
build 2020-09-15-17-10-55 powered by Lua 5.1.4 on ESP-IDF v3.3-beta1-1391-g9e70825d1 on SDK IDF

You either flash the firmware from the cloud builder - what you did according to the screen shot - or the one you built yourself with Docker - which you also seem to have done. I don't understand how you could get a mix therefore? And what's with ChilliPeppr?
Here's what I would do:

build a binary on the cloud builder using only the default modules
flash it
confirm you get a clean boot message
connect to your WiFi

If all is well then continue by building a new firmware with the modules you really need and repeat.

The firmware used in those screenshots is one from the cloud-builder. I havent attempted building it myself.
The script in the end shall have just one ability: counting a single channel and returning this measurement through rs232.
Therefore no WiFi connection is needed as USB/Serial via UART is enough for this case.
So I obviously need the pulsecnt module: which seems undefined according this screen tho, which right now is my only problem.

And what's with ChilliPeppr?
Thats just the "IDE" im using for uploading/executing the script.

So again what I did so far:

forged a binary using the cloud builder
flashed it
got boot
uploaded hello world script
got expected reply
uploaded this script
also got expected reply EXCEPT pulsecnt == nil

I am requesting a build without pulsecnt right now which will prolly execute and run just as good but obviously will also not have the pulse counter module. (next comment upcomming)

As promised (and expected):

Mail
Your NodeMCU custom build finished successfully. You may now download the firmware:
- float: https://nodemcu-build.com/builds/nodemcu-dev-esp32-7-modules-2020-09-15-19-44-47-float.bin
- integer: https://nodemcu-build.com/builds/nodemcu-dev-esp32-7-modules-2020-09-15-19-44-47-integer.bin

This was built against the dev-esp32 branch and includes the following modules: file, gpio, net, node, tmr, uart, wifi.
The files are guaranteed to be available for download for 24h.

I invite you to try my standalone desktop tool to flash firmware binaries: https://github.com/marcelstoer/nodemcu-pyflasher

Learn how to flash the firmware: https://nodemcu.readthedocs.io/en/dev-esp32/en/flash/. If you're upgrading from a previous version you should carefully study the "Upgrading Firmware" instructions on that page.

Please help keep this service alive: http://nodemcu-build.com/faq.php#support

Flash-Log
Command: esptool.py --port COM3 --baud 115200 --after no_reset write_flash --flash_mode dio 0x00000 F:\Users\user\Downloads\nodemcu-dev-esp32-7-modules-2020-09-15-19-44-47-float.bin --erase-all

esptool.py v2.6
Serial port COM3
Connecting......
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 24:62:ab:ff:8e:64
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Erasing flash (this may take a while)...
Chip erase completed successfully in 7.8s
Compressed 985840 bytes to 615676...
Wrote 985840 bytes (615676 compressed) at 0x00000000 in 54.6 seconds (effective 144.4 kbit/s)...
Hash of data verified.

Leaving...
Staying in bootloader.

Firmware successfully flashed. Unplug/replug or reset device
to switch back to normal boot mode.

stdout
node.restart()
node.restart()
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6736
ho 0 tail 12 room 4
load:0x40078000,len:11116
load:0x40080400,len:5940
entry 0x40080700
I (73) boot: Chip Revision: 1
I (73) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (41) boot: ESP-IDF v3.3-beta2-887-g9e70825d1 2nd stage bootloader
I (41) boot: compile time 19:44:49
I (41) boot: Enabling RNG early entropy source...
I (48) boot: SPI Speed      : 40MHz
I (52) boot: SPI Mode       : DIO
I (56) boot: SPI Flash Size : 4MB
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 00180000
I (93) boot:  3 lfs              unknown          c2 01 00190000 00010000
I (101) boot:  4 nodemcuspiffs    unknown          c2 00 001a0000 00070000
I (108) boot: End of partition table
I (113) boot_comm: chip revision: 1, min. application chip revision: 0
I (120) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x25e38 (155192) map
I (181) esp_image: segment 1: paddr=0x00035e60 vaddr=0x3ffb0000 size=0x035ec ( 13804) load
I (187) esp_image: segment 2: paddr=0x00039454 vaddr=0x40080000 size=0x00400 (  1024) load
I (188) esp_image: segment 3: paddr=0x0003985c vaddr=0x40080400 size=0x067b4 ( 26548) load
I (207) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0xa2278 (664184) map
I (432) esp_image: segment 5: paddr=0x000e2298 vaddr=0x40086bb4 size=0x0e7c8 ( 59336) load
I (455) esp_image: segment 6: paddr=0x000f0a68 vaddr=0x400c0000 size=0x00064 (   100) load
I (469) boot: Loaded app from partition at offset 0x10000
I (469) boot: Disabling RNG early entropy source...
I (469) cpu_start: Pro cpu up.
I (473) cpu_start: Application information:
I (478) cpu_start: Project name:     NodeMCU
I (483) cpu_start: App version:      dd3b217-dirty
I (488) cpu_start: Compile time:     Sep 15 2020 19:44:52
I (494) cpu_start: ELF file SHA256:  cfc264376821d2e0...
I (500) cpu_start: ESP-IDF:          v3.3-beta2-887-g9e70825d1
I (507) cpu_start: Starting app cpu, entry point is 0x400812e8
I (493) cpu_start: App cpu up.
I (518) heap_init: Initializing. RAM available for dynamic allocation:
I (524) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (530) heap_init: At 3FFB9CD0 len 00026330 (152 KiB): DRAM
I (537) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (543) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (549) heap_init: At 4009537C len 0000AC84 (43 KiB): IRAM
I (556) cpu_start: Pro cpu start user code
I (238) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

Mounting flash filesystem...
No LFS image loaded
I (399) wifi:wifi driver task: 3ffc4624, prio:23, stack:3584, core=0
I (399) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (399) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (429) wifi:wifi firmware version: 44aa95c
I (429) wifi:config NVS flash: enabled
I (429) wifi:config nano formating: disabled
I (429) wifi:Init dynamic tx buffer num: 32
I (439) wifi:Init data frame dynamic rx buffer num: 32
I (439) wifi:Init management frame dynamic rx buffer num: 32
I (449) wifi:Init management short buffer num: 32
I (449) wifi:Init static rx buffer size: 1600
I (459) wifi:Init static rx buffer num: 10
I (459) wifi:Init dynamic rx buffer num: 32

NodeMCU ESP32 built with Docker provided by frightanic.com
  branch: dev-esp32
  commit: f4887bf134235c05e6c9b2efad370e6d5018f91a
  SSL: true
  modules: -
built on nodemcu-build.com provided by frightanic.com
  branch: dev-esp32
  commit: dd3b217df201fde00fcf84be1d485d555d433bed
  SSL: false
  modules: file,gpio,net,node,tmr,uart,wifi
build 2020-09-15-19-44-47 powered by Lua 5.1.4 on ESP-IDF v3.3-beta1-1391-g9e70825d1 on SDK IDF
lua: cannot open init.lua
file.open("init.lua", "w")
file.writeline([[print("Hello World!")]])
file.close()
node.compile("init.lua")
> file.open("init.lua", "w")
> file.writeline([[print("Hello World!")]])
> file.close()
> node.compile("init.lua")
node.restart()
> node.restart()
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6736
ho 0 tail 12 room 4
load:0x40078000,len:11116
load:0x40080400,len:5940
entry 0x40080700
I (73) boot: Chip Revision: 1
I (73) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (41) boot: ESP-IDF v3.3-beta2-887-g9e70825d1 2nd stage bootloader
I (41) boot: compile time 19:44:49
I (41) boot: Enabling RNG early entropy source...
I (48) boot: SPI Speed      : 40MHz
I (52) boot: SPI Mode       : DIO
I (56) boot: SPI Flash Size : 4MB
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 00180000
I (93) boot:  3 lfs              unknown          c2 01 00190000 00010000
I (101) boot:  4 nodemcuspiffs    unknown          c2 00 001a0000 00070000
I (108) boot: End of partition table
I (113) boot_comm: chip revision: 1, min. application chip revision: 0
I (120) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x25e38 (155192) map
I (181) esp_image: segment 1: paddr=0x00035e60 vaddr=0x3ffb0000 size=0x035ec ( 13804) load
I (187) esp_image: segment 2: paddr=0x00039454 vaddr=0x40080000 size=0x00400 (  1024) load
I (188) esp_image: segment 3: paddr=0x0003985c vaddr=0x40080400 size=0x067b4 ( 26548) load
I (207) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0xa2278 (664184) map
I (432) esp_image: segment 5: paddr=0x000e2298 vaddr=0x40086bb4 size=0x0e7c8 ( 59336) load
I (455) esp_image: segment 6: paddr=0x000f0a68 vaddr=0x400c0000 size=0x00064 (   100) load
I (469) boot: Loaded app from partition at offset 0x10000
I (469) boot: Disabling RNG early entropy source...
I (469) cpu_start: Pro cpu up.
I (473) cpu_start: Application information:
I (478) cpu_start: Project name:     NodeMCU
I (483) cpu_start: App version:      dd3b217-dirty
I (488) cpu_start: Compile time:     Sep 15 2020 19:44:52
I (494) cpu_start: ELF file SHA256:  cfc264376821d2e0...
I (500) cpu_start: ESP-IDF:          v3.3-beta2-887-g9e70825d1
I (507) cpu_start: Starting app cpu, entry point is 0x400812e8
I (493) cpu_start: App cpu up.
I (518) heap_init: Initializing. RAM available for dynamic allocation:
I (524) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (530) heap_init: At 3FFB9CD0 len 00026330 (152 KiB): DRAM
I (537) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (543) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (549) heap_init: At 4009537C len 0000AC84 (43 KiB): IRAM
I (556) cpu_start: Pro cpu start user code
I (238) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

Mounting flash filesystem...
No LFS image loaded
I (399) wifi:wifi driver task: 3ffc4624, prio:23, stack:3584, core=0
I (399) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (399) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (429) wifi:wifi firmware version: 44aa95c
I (429) wifi:config NVS flash: enabled
I (429) wifi:config nano formating: disabled
I (429) wifi:Init dynamic tx buffer num: 32
I (439) wifi:Init data frame dynamic rx buffer num: 32
I (439) wifi:Init management frame dynamic rx buffer num: 32
I (449) wifi:Init management short buffer num: 32
I (449) wifi:Init static rx buffer size: 1600
I (459) wifi:Init static rx buffer num: 10
I (459) wifi:Init dynamic rx buffer num: 32

NodeMCU ESP32 built with Docker provided by frightanic.com
  branch: dev-esp32
  commit: f4887bf134235c05e6c9b2efad370e6d5018f91a
  SSL: true
  modules: -
built on nodemcu-build.com provided by frightanic.com
  branch: dev-esp32
  commit: dd3b217df201fde00fcf84be1d485d555d433bed
  SSL: false
  modules: file,gpio,net,node,tmr,uart,wifi
build 2020-09-15-19-44-47 powered by Lua 5.1.4 on ESP-IDF v3.3-beta1-1391-g9e70825d1 on SDK IDF
Hello World!

Next Comment will be the exact same but with the "Pulse Counter" module.

Mail
Your NodeMCU custom build finished successfully. You may now download the firmware:
- float: https://nodemcu-build.com/builds/nodemcu-dev-esp32-8-modules-2020-09-15-20-02-16-float.bin
- integer: https://nodemcu-build.com/builds/nodemcu-dev-esp32-8-modules-2020-09-15-20-02-16-integer.bin

This was built against the dev-esp32 branch and includes the following modules: file, gpio, net, node, pulsecnt, tmr, uart, wifi.
The files are guaranteed to be available for download for 24h.

I invite you to try my standalone desktop tool to flash firmware binaries: https://github.com/marcelstoer/nodemcu-pyflasher

Learn how to flash the firmware: https://nodemcu.readthedocs.io/en/dev-esp32/en/flash/. If you're upgrading from a previous version you should carefully study the "Upgrading Firmware" instructions on that page.

Please help keep this service alive: http://nodemcu-build.com/faq.php#support

Flash-Log
Command: esptool.py --port COM3 --baud 115200 --after no_reset write_flash --flash_mode dio 0x00000 F:\Users\user\Downloads\nodemcu-dev-esp32-8-modules-2020-09-15-20-02-16-float.bin --erase-all

esptool.py v2.6
Serial port COM3
Connecting.....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 24:62:ab:ff:8e:64
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Erasing flash (this may take a while)...
Chip erase completed successfully in 7.8s
Compressed 985856 bytes to 615704...
Wrote 985856 bytes (615704 compressed) at 0x00000000 in 54.6 seconds (effective 144.3 kbit/s)...
Hash of data verified.

Leaving...
Staying in bootloader.

Firmware successfully flashed. Unplug/replug or reset device
to switch back to normal boot mode.

stdout
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6736
ho 0 tail 12 room 4
load:0x40078000,len:11116
load:0x40080400,len:5940
entry 0x40080700
I (73) boot: Chip Revision: 1
I (73) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (41) boot: ESP-IDF v3.3-beta2-887-g9e70825d1 2nd stage bootloader
I (41) boot: compile time 20:02:18
I (41) boot: Enabling RNG early entropy source...
I (48) boot: SPI Speed      : 40MHz
I (52) boot: SPI Mode       : DIO
I (56) boot: SPI Flash Size : 4MB
I (60) boot: Partition Table:
I (63) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 00180000
I (93) boot:  3 lfs              unknown          c2 01 00190000 00010000
I (101) boot:  4 nodemcuspiffs    unknown          c2 00 001a0000 00070000
I (108) boot: End of partition table
I (112) boot_comm: chip revision: 1, min. application chip revision: 0
I (120) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x25e40 (155200) map
I (181) esp_image: segment 1: paddr=0x00035e68 vaddr=0x3ffb0000 size=0x035ec ( 13804) load
I (186) esp_image: segment 2: paddr=0x0003945c vaddr=0x40080000 size=0x00400 (  1024) load
I (188) esp_image: segment 3: paddr=0x00039864 vaddr=0x40080400 size=0x067ac ( 26540) load
I (207) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0xa2278 (664184) map
I (432) esp_image: segment 5: paddr=0x000e2298 vaddr=0x40086bac size=0x0e7d0 ( 59344) load
I (455) esp_image: segment 6: paddr=0x000f0a70 vaddr=0x400c0000 size=0x00064 (   100) load
I (469) boot: Loaded app from partition at offset 0x10000
I (469) boot: Disabling RNG early entropy source...
I (469) cpu_start: Pro cpu up.
I (473) cpu_start: Application information:
I (478) cpu_start: Project name:     NodeMCU
I (483) cpu_start: App version:      dd3b217-dirty
I (488) cpu_start: Compile time:     Sep 15 2020 20:02:21
I (494) cpu_start: ELF file SHA256:  6303efc429f147ca...
I (500) cpu_start: ESP-IDF:          v3.3-beta2-887-g9e70825d1
I (507) cpu_start: Starting app cpu, entry point is 0x400812e8
I (0) cpu_start: App cpu up.
I (517) heap_init: Initializing. RAM available for dynamic allocation:
I (524) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (530) heap_init: At 3FFB9CD0 len 00026330 (152 KiB): DRAM
I (536) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (543) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (549) heap_init: At 4009537C len 0000AC84 (43 KiB): IRAM
I (555) cpu_start: Pro cpu start user code
I (238) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

Mounting flash filesystem...
Formatting file system. Please wait...

No LFS image loaded
I (7219) wifi:wifi driver task: 3ffc411c, prio:23, stack:3584, core=0
I (7219) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (7219) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (7279) wifi:wifi firmware version: 44aa95c
I (7279) wifi:config NVS flash: enabled
I (7279) wifi:config nano formating: disabled
I (7279) wifi:Init dynamic tx buffer num: 32
I (7279) wifi:Init data frame dynamic rx buffer num: 32
I (7289) wifi:Init management frame dynamic rx buffer num: 32
I (7289) wifi:Init management short buffer num: 32
I (7299) wifi:Init static rx buffer size: 1600
I (7299) wifi:Init static rx buffer num: 10
I (7299) wifi:Init dynamic rx buffer num: 32

NodeMCU ESP32 built with Docker provided by frightanic.com
  branch: dev-esp32
  commit: f4887bf134235c05e6c9b2efad370e6d5018f91a
  SSL: true
  modules: -
built on nodemcu-build.com provided by frightanic.com
  branch: dev-esp32
  commit: dd3b217df201fde00fcf84be1d485d555d433bed
  SSL: false
  modules: file,gpio,net,node,pulsecnt,tmr,uart,wifi
build 2020-09-15-20-02-16 powered by Lua 5.1.4 on ESP-IDF v3.3-beta1-1391-g9e70825d1 on SDK IDF
lua: cannot open init.lua
file.open("init.lua", "w")
file.writeline([[print("Hello World!")]])
file.writeline([[]])
file.writeline([[print("gpio module loaded?")]])
file.writeline([[print(gpio)]])
> file.open("init.lua", "w")
file.writeline([[]])
> file.writeline([[print("Hello World!")]])
file.writeline([[print("pulsecnt module loaded?")]])
> file.writeline([[]])
file.writeline([[print(pulsecnt)]])
> file.writeline([[print("gpio module loaded?")]])
file.close()
node.compile("init.lua")
> file.writeline([[print(gpio)]])
> file.writeline([[]])
> file.writeline([[print("pulsecnt module loaded?")]])
> file.writeline([[print(pulsecnt)]])
> file.close()
> node.compile("init.lua")
node.restart()
> node.restart()
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6736
ho 0 tail 12 room 4
load:0x40078000,len:11116
load:0x40080400,len:5940
entry 0x40080700
I (73) boot: Chip Revision: 1
I (73) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (41) boot: ESP-IDF v3.3-beta2-887-g9e70825d1 2nd stage bootloader
I (41) boot: compile time 20:02:18
I (41) boot: Enabling RNG early entropy source...
I (48) boot: SPI Speed      : 40MHz
I (52) boot: SPI Mode       : DIO
I (56) boot: SPI Flash Size : 4MB
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 00180000
I (93) boot:  3 lfs              unknown          c2 01 00190000 00010000
I (101) boot:  4 nodemcuspiffs    unknown          c2 00 001a0000 00070000
I (108) boot: End of partition table
I (113) boot_comm: chip revision: 1, min. application chip revision: 0
I (120) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x25e40 (155200) map
I (181) esp_image: segment 1: paddr=0x00035e68 vaddr=0x3ffb0000 size=0x035ec ( 13804) load
I (187) esp_image: segment 2: paddr=0x0003945c vaddr=0x40080000 size=0x00400 (  1024) load
I (188) esp_image: segment 3: paddr=0x00039864 vaddr=0x40080400 size=0x067ac ( 26540) load
I (207) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0xa2278 (664184) map
I (432) esp_image: segment 5: paddr=0x000e2298 vaddr=0x40086bac size=0x0e7d0 ( 59344) load
I (455) esp_image: segment 6: paddr=0x000f0a70 vaddr=0x400c0000 size=0x00064 (   100) load
I (469) boot: Loaded app from partition at offset 0x10000
I (469) boot: Disabling RNG early entropy source...
I (469) cpu_start: Pro cpu up.
I (473) cpu_start: Application information:
I (478) cpu_start: Project name:     NodeMCU
I (483) cpu_start: App version:      dd3b217-dirty
I (488) cpu_start: Compile time:     Sep 15 2020 20:02:21
I (494) cpu_start: ELF file SHA256:  6303efc429f147ca...
I (500) cpu_start: ESP-IDF:          v3.3-beta2-887-g9e70825d1
I (507) cpu_start: Starting app cpu, entry point is 0x400812e8
I (493) cpu_start: App cpu up.
I (518) heap_init: Initializing. RAM available for dynamic allocation:
I (524) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (530) heap_init: At 3FFB9CD0 len 00026330 (152 KiB): DRAM
I (537) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (543) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (549) heap_init: At 4009537C len 0000AC84 (43 KiB): IRAM
I (556) cpu_start: Pro cpu start user code
I (238) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.

Mounting flash filesystem...
No LFS image loaded
I (399) wifi:wifi driver task: 3ffc4624, prio:23, stack:3584, core=0
I (399) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (399) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (429) wifi:wifi firmware version: 44aa95c
I (429) wifi:config NVS flash: enabled
I (429) wifi:config nano formating: disabled
I (429) wifi:Init dynamic tx buffer num: 32
I (439) wifi:Init data frame dynamic rx buffer num: 32
I (439) wifi:Init management frame dynamic rx buffer num: 32
I (449) wifi:Init management short buffer num: 32
I (449) wifi:Init static rx buffer size: 1600
I (459) wifi:Init static rx buffer num: 10
I (459) wifi:Init dynamic rx buffer num: 32

NodeMCU ESP32 built with Docker provided by frightanic.com
  branch: dev-esp32
  commit: f4887bf134235c05e6c9b2efad370e6d5018f91a
  SSL: true
  modules: -
built on nodemcu-build.com provided by frightanic.com
  branch: dev-esp32
  commit: dd3b217df201fde00fcf84be1d485d555d433bed
  SSL: false
  modules: file,gpio,net,node,pulsecnt,tmr,uart,wifi
build 2020-09-15-20-02-16 powered by Lua 5.1.4 on ESP-IDF v3.3-beta1-1391-g9e70825d1 on SDK IDF
Hello World!
gpio module loaded?
romtable: 0x3f404a70
pulsecnt module loaded?
nil

Script
print("Hello World!")

print("gpio module loaded?")
print(gpio)

print("pulsecnt module loaded?")
print(pulsecnt)

same problem sadly 😞

I'm a little less confused now. This hit me out of the blue, sorry.
The weird boot message appears to be a bug - never seen anything like that. I'm tracking this at https://github.com/marcelstoer/nodemcu-custom-build/issues/39.
The missing pulse counter module is related to an upstream change in the firmware Kconfig that wasn't properly reflected in the cloud builder. This is already fixed.


Feat: Hooks for Lambda handlers

Request for adding this to Ion https://docs.sst.dev/clients#hooks
https://discord.com/channels/983865673656705025/1177071497974648952/1228266409210150974

Second this!
I'm using Ion for infra only with the non-Ion NPM package because I have these hooks throughout my codebase.
It's becoming problematic because I can't import { Resource } from "sst" to reference my infra since I am still using this older version of the node package.
Looking forward to having ApiHandler, GraphQLHandler, useQueryParam, useCookie, useResponse etc. brought over into the Ion npm package

would be great to get some info on this one so we know what we can expect and how we should structure ion apps going forward.

This is so important!


Bump to Node 20

changes already merged into main branch but not released. do you have any news?

yes the new release workflow is being added this week which will unblock this

thank you

Hi there,
I think there is an issue with the new release workflow. As you can see after the last merge onto main the release workflow failed
[Invalid workflow file: .github/workflows/release-pr.yml#L16](https://github.com/Azure/setup-kubectl/actions/runs/7718484552/workflow)
error parsing called workflow
".github/workflows/release-pr.yml"
-> "Azure/action-release-workflows/.github/workflows/release_js_project.yaml@e4a1a0385530d6861c9a9b7262058ad33b10c769"
: failed to fetch workflow: workflow was not found.

I'm not totally sure how that works but if e4a1a0385530d6861c9a9b7262058ad33b10c769 is a commit sha on the other repository, that commit does not exist -> https://github.com/Azure/action-release-workflows/commit/e4a1a0385530d6861c9a9b7262058ad33b10c769
I hope this help to debug the issue.

@davidgamero any news on this? As @pacoguzman pointed out it seems like the release has failed.
I created a PR to set the version on action-release-workflows to the latest release.

Thanks @davidgamero, it works like charm :+1:  The node 16 deprecation notice is gone 🥳

i am glad to hear that it is working
closing this issue for now, we can reopen if a further issue is discovered


Pretrained

Hello
Is there any pretrained model for the OCT?

Hi @shersoni610, you can find it here:
https://www.kaggle.com/code/ayushdabra/retinal-oct-images-classification/data?select=finetuned_model.h5


add postgres init db

I completed the 3 steps below:

[] I've read the Contribution Guide.
[] I've updated the documentation. (refer to this for how to do so).
[] I enjoyed my time contributing and making developer's life easier :)

Hi @ahkui
don't forget add POSTGRES_ENTRYPOINT_INITDB default config to env-example file.


Cannot Post MISSING_CONFIG_BLOCK

Hi,
I've set up a Staticman instance on Heroku, here:
https://staticman-axiomshift.herokuapp.com/
to use on my Gatsby blog hosted on Netlify here:
https://wikiskills.org/
Here are the config files:
https://github.com/joeczar/wikiSkills-blog/blob/master/staticman.yml
https://github.com/joeczar/wikiSkills-blog/blob/master/_config.yml
The error:
{"success":false,"message":"Error whilst parsing Staticman config file","rawError":{"_smErrorCode":"MISSING_CONFIG_BLOCK"},"errorCode":"MISSING_CONFIG_BLOCK"}
I have read all the threads I can find and they all say that the issue has something to do with the staticman.yml file. I have tried every version of this I can find and nothing works. I'm sure it's something small I've overseen, so I could really use some help. I want to use Staticman!
Thank you,
Joe

Can you try deploying the dev branch to Heroku and try using that to see if you get a different error message? There are some issues with the Staticman error handler that are resolved on the dev branch (see #342). You can have multiple applications running on Heroku so this should be pretty easy to deploy. Just go to the README on the dev branch, click the deploy button, and copy over your config variables from your existing instance.

Thanks for the quick response.
Dev build is running here:
https://staticman-dev-axiomshift.herokuapp.com/
I've provided Heroku with the same RSA & GitHub Token as the other instance.
But, when I try and get the invitation with:
https://staticman-dev-axiomshift.herokuapp.com/v2/connect/joeczar/wikiskills-blog
I get:
No invitation found
I changed up the git token and RSA key but only got the same response. I went ahead to try a post call.
With the comment post, I get the following 404 looking for the
"method":"GET","url":"https://api.github.com/repos/joeczar/wikiSkills-blog/contents/staticman.yml?ref=master" ( complete response below )
I then created a new contents folder in the root and copied the staticman.yml there, but I get the same response.
Thanks again.
{"success":false,"rawError":{"name":"HttpError","status":404,"headers":{"access-control-allow-origin":"*","access-control-expose-headers":"ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset","connection":"close","content-encoding":"gzip","content-security-policy":"default-src 'none'","content-type":"application/json; charset=utf-8","date":"Mon, 30 Mar 2020 09:30:34 GMT","referrer-policy":"origin-when-cross-origin, strict-origin-when-cross-origin","server":"GitHub.com","status":"404 Not Found","strict-transport-security":"max-age=31536000; includeSubdomains; preload","transfer-encoding":"chunked","vary":"Accept-Encoding, Accept, X-Requested-With","x-accepted-oauth-scopes":"repo","x-content-type-options":"nosniff","x-frame-options":"deny","x-github-media-type":"github.v3; format=json","x-github-request-id":"A590:10A23:4409836:4F3CE33:5E81BC3A","x-oauth-scopes":"repo, user","x-ratelimit-limit":"5000","x-ratelimit-remaining":"4984","x-ratelimit-reset":"1585561877","x-xss-protection":"1; mode=block"},"request":{"method":"GET","url":"https://api.github.com/repos/static-bot/wikiSkills-blog/contents/staticman.yml?ref=master","headers":{"accept":"application/vnd.github.v3+json","user-agent":"Staticman octokit.js/16.35.0 Node.js/13.11.0 (Linux 4.4; x64)","authorization":"token [REDACTED]"},"request":{"timeout":5000,"validate":{"owner":{"required":true,"type":"string"},"path":{"required":true,"type":"string"},"ref":{"type":"string"},"repo":{"required":true,"type":"string"}}}},"documentation_url":"https://developer.github.com/v3/repos/contents/#get-contents","_smErrorCode":"GITHUB_READING_FILE"},"errorCode":"GITHUB_READING_FILE"}

OK, looks like it's working!
https://github.com/joeczar/wikiSkills-blog/pull/1#issue-395539472

I had the bot's username in the URL, not mine.
There was no need to move the staticman.yml out of Root

One thing I'm going to have to figure out is how to keep the request from opening in a new window. I've had to stitch together several tutorials to get this running on my setup
Thanks, @alexwaibel for the Dev branch suggestion. it got me up and running.


Resolve Windows chromium path and add jdk20 tool on Jenkins

Description
Resolve Windows chromium path and add jdk20 tool on Jenkins
Issues Resolved
https://github.com/opensearch-project/opensearch-build/issues/1563
https://github.com/opensearch-project/opensearch-build/issues/3434
Closes https://github.com/opensearch-project/opensearch-build/issues/3425
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

We will merge this after the 2.8.0 releases.

https://build.ci.opensearch.org/job/packer-build/36/console
https://build.ci.opensearch.org/job/packer-build/37/console


How about error "Failed to query service endpoint"

I've successfully created service endpoint for DEV, but subsequently trying to create same for TEST/PROD Resource Groups fail with error when pressing "Verify connection":
"Failed to query service endpoint api: https://management.azure.com//subscriptions/?api-version=2016-06-01. Error Message: The remote server returned an error: (403) Forbidden.."

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

ID: 010be6f9-10ae-a117-5354-7084a6843518
Version Independent ID: 25941814-7c61-cc10-b943-7e47a8e90177
Content: How to troubleshoot Azure Resource Manager service endpoints in VSTS and TFS
Content Source: docs/build-release/actions/azure-rm-endpoint.md
Service: unspecified
GitHub Login: @douge
Microsoft Alias: ahomer

Thank you for your feedback. I will pass your question onto the product team and let you know their response.

Unfortunately I am unable to obtain any more useful information. If you are still experiencing this problem, please let me know with more details that I can pass on to the product team.

I do experience the same thing with TFS 2017, I suspect it is somehow related to the service principal permissions.

I am also facing this issue with TFS 2019.  Do we have any resolution to this?

@alexhomer1 did you ever get a solution from the product team.  We have a Azure container registry tied to an Azure app service.  Code sits on TFS 2019.  We are unable to create a service principal connection between TFS 2019 and the Azure container registry.  An app registry is also in place on the Azure Active Directory.


[cpe/alps] netcdf-hdf5-parallel

https://jira.cscs.ch/browse/VCMSA-319 (part2)
Current test codes are serial -> moving to parallel tests, for example:
    https://github.com/Unidata/netcdf-c/blob/main/examples/C/simple_xy_wr.c
    https://github.com/Unidata/netcdf-c/blob/main/examples/C/simple_xy_rd.c
    -> https://github.com/Unidata/netcdf-c/blob/main/nc_test4/tst_parallel.c

[       OK ] ( 1/15) netCDFTest %lang=cpp /2bb65ff7 @hohgant:cpu+PrgEnv-aocc
[       OK ] ( 2/15) netCDFTest %lang=cpp /2bb65ff7 @hohgant:cpu+PrgEnv-cray
[       OK ] ( 3/15) netCDFTest %lang=cpp /2bb65ff7 @hohgant:cpu+PrgEnv-gnu
[       OK ] ( 4/15) netCDFTest %lang=cpp /2bb65ff7 @hohgant:cpu+PrgEnv-nvhpc
[       OK ] ( 5/15) netCDFTest %lang=cpp /2bb65ff7 @hohgant:cpu+PrgEnv-nvidia
[       OK ] ( 6/15) netCDFTest %lang=c /00cc832a @hohgant:cpu+PrgEnv-aocc
[       OK ] ( 7/15) netCDFTest %lang=c /00cc832a @hohgant:cpu+PrgEnv-cray
[       OK ] ( 8/15) netCDFTest %lang=c /00cc832a @hohgant:cpu+PrgEnv-gnu
[       OK ] ( 9/15) netCDFTest %lang=c /00cc832a @hohgant:cpu+PrgEnv-nvhpc
[       OK ] (10/15) netCDFTest %lang=c /00cc832a @hohgant:cpu+PrgEnv-nvidia
[       OK ] (11/15) netCDFTest %lang=f90 /00ff1fae @hohgant:cpu+PrgEnv-aocc
[       OK ] (12/15) netCDFTest %lang=f90 /00ff1fae @hohgant:cpu+PrgEnv-cray
[       OK ] (13/15) netCDFTest %lang=f90 /00ff1fae @hohgant:cpu+PrgEnv-gnu
[       OK ] (14/15) netCDFTest %lang=f90 /00ff1fae @hohgant:cpu+PrgEnv-nvhpc
[       OK ] (15/15) netCDFTest %lang=f90 /00ff1fae @hohgant:cpu+PrgEnv-nvidia

Overall it looks good. The only problem that I see is that it's tied to cray specific paths/prg envs so it won't work without a cray environment.

we can fix that when we update the test for uenv


Expose HyperV partition privileges

These privileges can be used in the hvinfo tool to display following missing features:

vpindex
synic
reenlightenment
runtime
stimer

I will create a PR for hvinfo once this PR is merged.

@fromanirh any chance you can help to review this?


Reboot, when inverter is ofline -> error + unknown state until next reboot (when inverter is online)

Hi,
am using haOS (2023.7.2), Solarman v1.4.3 and a deye SUN600G3.
When i reboot my homeassistant when the inverter is offline (no sun (ie in the night)) it will not come back until i reboot again, when its online.
2023-07-18 23:36:24.576 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up solarman platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 353, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/solarman/sensor.py", line 79, in async_setup_entry
_do_setup_platform(hass, entry.options, async_add_entities)
File "/config/custom_components/solarman/sensor.py", line 49, in _do_setup_platform
raise vol.Invalid('configuration parameter [inverter_serial] does not have a value')
voluptuous.error.Invalid: configuration parameter [inverter_serial] does not have a value

settings:

Sample Value:

Same issue here.
When I reboot or even just restart the Homeassistant when the inverter is offline at night, the Solarman integration does not properly connect to the inverter when the inverter comes back in the morning.
I have to restart Homeassistant again when the inverter is online and then everything is fine.


Support medium.com posts

^

A couple problems causing it is kind hard:

Seems medium can sync from a gist, which is displayed as an inner HTML page
Image sync is a bit awkward

commit


[SPARK-38153][BUILD] Remove option newlines.topLevelStatements in scalafmt.conf

What changes were proposed in this pull request?

Remove option newlines.topLevelStatements in scalafmt.conf
Why are the changes needed?

The configuration
newlines.topLevelStatements = [before,after]

is to add a blank line before the first member or after the last member of the class. Without the conf, scalafmt will still add blank lines between consecutive members (or initializers) of a class.
This is neither encouraged nor discouraged as per https://github.com/databricks/scala-style-guide#blanklines
As I tried running the script ./dev/scalafmt, I saw unnessary blank lines

Does this PR introduce any user-facing change?

No
How was this patch tested?

Manual test

cc @lipzhu @HyukjinKwon @srowen @koeninger
The conf was added in https://github.com/apache/spark/pull/32383

Merged to master. Thank you, @gengliangwang and all.


Upgrade to Go 1.17

Opening for CI

Why not just bump the golang version to go1.19? Go 1.17 is not maintained anymore.


in mirror mode flash permissions screen is flipped too

A minor problem: If I right-click on Flash player movie, and select Settings, I get it flipped.

I am using the mirror mode (flip_horiz configuration option) because I want the camera to behave as it is in Skype.
I think it should be possible to fix this by transforming only the internal MovieClip, and not the whole flash player movie.

Yeah, sorry, I'm doing the mirror flip in HTML5 CSS, not in Flash, so the entire movie DIV is getting flipped.  Someday I'll figure out how to do it properly and rewrite the mirror feature.

It's a pain, but I think this issue can be fixed by reacting to events dispatched by the webcam. You simply need to un-mirror the div while the dialog is visible.

To my knowledge, there is no way to catch the events of when the user manually goes to the settings dialog, and when he dismisses it.  I don't think Flash emits events for those things.
Luckily, this only happens when someone right-clicks in the Flash movie and selects "Settings".  It does not happen when I throw up the dialog on startup (I am delaying the mirror effect until after the user clicks Allow).  So I wouldn't call this a P1 bug.  But I think I can flip the internal camera object internally in Flash, and skip the CSS3 transform.  It's a bit messy, but doable.

Sorry, didn't mean to make this P1.

I'd like to vote for this one as well—I'll investigate if I can figure out how to make this work.

Implemented a fix—check it out :3

I looked at it, it looks nice and clean. Let see if the maintainer merges it in. Btw, you may check out my fork where I have added info how to build flash without actually having an ide, but just using the sdk.

Oh wow!  @osdiab this is awesome!  Thank you so much!  I've been wanting to implement this forever, but I was terrified to touch the ActionScript.  It frightens me.  I'll review and accept this PR very soon!
@borisreitman Thanks for reviewing it!

@jhuckaby np :) My first Flash PR, and hopefully one of my last hahah.

@borisreitman i'll check that out for sure! Because I'm not going to actually pay for adobe animate.... lol

I applied the patch and it works for me. Going to use it.


State Change does not re-authorize Permissions

I am navigating between states in my application and have noticed that on some states the Permissions are not being applied. I have debugged this and found this to be due to my state hierarchy and the way angular-permissions decides whether to check permissions.
I have the following states:

app.test (on this state. I have defined various things to inherit including data: { permissions: {....)
app.test.child1
app.test.child2
app.anothertest

If I navigate from app.anothertest to app.test.child1 the permissions defined on the parent state app.test do not get tested.
The Wiki states:

Important! Angular permission is using ui-router state decoration to be able to inherit permissions/roles from parent states. So make sure that permission dependency is included just after ui-router as in example above.

So, according to the above permission/role definitions should be inherited from parent definitions. But they don't seem to be because of the following in angular-permissions:
1) Authorization is only run if !isAuthorizationFinished() is true and areSetStatePermissions(toState) returns true:
permission.run(['$rootScope', '$state', '$q', 'Authorization', 'PermissionMap', function ($rootScope, $state, $q, Authorization, PermissionMap) {
    $rootScope.$on('$stateChangeStart', function (event, toState, toParams, fromState, fromParams, options) {

     ** if (!isAuthorizationFinished() && areSetStatePermissions(toState)) {**
        event.preventDefault();
        setStateAuthorizationStatus(true);

        if (!areStateEventsDefaultPrevented()) {
          var compensatedPermissionMap = compensatePermissionMap(toState.data.permissions);
          authorizeForState(compensatedPermissionMap);
        }
      }

**
2) areSetStatePermissions only checks the current state for the existence of the data and permissions objects. It does not check the parent states.
**
      function areSetStatePermissions(state) {
        return angular.isDefined(state.data) && angular.isDefined(state.data.permissions);
      }

3) Therefore, as in my example above when changing state to a child state without data.permissions set, the authorization functions will not fire.
This means that every state that you can navigate to will need to have a data.permissions object defined even if it has no permissions to be defined. In our app there are many states and therefore this will mean duplication of unnecessary configuration. We rely on state inheritance set rules for child states so shouldn't have to do this!
I don't think this is right? areSetStatePermissions should check all parent states to see if data.permissions has been set rather than just the toState? I haven't checked it yet, but when the state does change I'm presuming the permissions for all parent states are tested? I hope they are.

I've implemented the changes you have made to test them out. It does reauthorize now, but the permission-only\except directives on the views don't seem to be checked now. I have a few on views where there are no data: { permissions: {.... defined in any state definitions in the hierarchy. They should always be retested though. I'm trying to debug to pin down why they aren't being checked...

i saw the deprecation warning for 'permission only' and changed all references to 'permission-only'... might have caused it..


Add xarray-datatree to CI environment

@jhamman, it turns out that one of the issues had to do with the minimum Python version (Python 3.9) required by datatree. we should keep an eye out for https://github.com/xarray-contrib/datatree/pull/70 and once it's merged, we can revert back to supporting Python 3.8 within ndpyramid if needed.


Allow executing AST

use hebi::{Hebi, syntax};

let hebi = Hebi::new();

let module = syntax::parse("1 + 1").unwrap();
println!("{}", hebi.eval::<i32>(module).unwrap());

AST should also be serializable, so that it can be cached.
Eventually a similar API should also exist for emitting bytecode, caching it, and executing it later. This might complicate source information and spans.

This feature doesn't seem to pull its weight.


always send LaunchResponse after successful initialization

Currently the LaunchResponse is only send if stopOnEntry is true. This results in hanging connection if stopOnEntry is false, as the client is waiting for the LaunchResponse

@Gama11 could you please review? thanks!!

Gracias, a ver como me queda


rocm-llvm-alt optional closed-source package compilation fails

ROCm provides an optional package – rocm-llvm-alt – that provides a closed-source compiler for users interested in additional closed-source CPU optimizations. This feature is not functional in the ROCm 6.2.0 release. Users who attempt to invoke the closed-source compiler will experience an LLVM consumer-producer mismatch and the compilation will fail. There is no workaround that allows use of the closed-source compiler. It is recommended to compile using the default open-source compiler, which generates high-quality AMD CPU and AMD GPU code.
The rocm-llvm-alt package will be removed in an upcoming release. Users relying on the functionality provided by the closed-source compiler should transition to the open-source compiler. Once the rocm-llvm-alt package is removed, any compilation requesting functionality provided by the closed-source compiler will result in a Clang warning: [AMD] proprietary optimization compiler has been removed.

The rocm-llvm-alt-package is removed as of ROCm 6.3.0.


add cli.md for automation

/azp run automation - sdk

Can one of the admins verify this patch?

/azp run


Custom metadata on error responses

Feature Request
Motivation
Currently it seems only possible to return some custom info with a non-zero gRPC status in one predefined header:
const GRPC_STATUS_DETAILS_HEADER: &str = "grpc-status-details-bin";
#[derive(Clone)]
pub struct Status {
    /// The gRPC status code, found in the `grpc-status` header.
    code: Code,
    /// A relevant error message, found in the `grpc-message` header.
    message: String,
    /// Binary opaque details, found in the `grpc-status-details-bin` header.
    details: Bytes,
}

What if I want to use a different header name? What if I want to return more than one header/trailer on error response? gRPC spec does support that possibility. Libraries in other languages that I've worked with (Go, Scala) also don't have that restriction. We actually use a different header name in production in our company, so it's a quite real use case.
Proposal
Min: allow details from Status to go to a header with a custom name.
Max: allow any number of custom metadata key/values, ASCII or binary (via *-bin headers), on non-zero gRPC statuses.

I'd like to expose a similar ability to get access to a metadata map like https://docs.rs/tonic/0.2.0/tonic/struct.Response.html#method.metadata
This way you can add your own custom metadata values.

Sorry to comment on an old issue, but it appears that isn't possible because the only way to create metadata is through Response:
https://github.com/hyperium/tonic/blob/9ea03c2c44ad6bf76e4141e6fb40870b9b30ab63/tonic/src/response.rs#L26
and that calls a Metadata constructor with 0 capacity:
https://github.com/hyperium/tonic/blob/9ea03c2c44ad6bf76e4141e6fb40870b9b30ab63/tonic/src/metadata/map.rs#L227
Resulting in:
thread 'tokio-runtime-worker' panicked at 'index out of bounds: the len is 0 but the index is 0'

At runtime. Is there a way at present to achieve this? A quick googling didn't reveal any currently open issues around this behavior. I can open one if that's the correct next step.

@avantgardnerio if you're still seeing this, lets open another issue and really what would be helpful would be to recreate this in a test in map.rs (there are already a bunch of tests). Thanks!

I am still seeing it, and I will PR a test, thank you for your prompt response!

I take that back. I am seeing it in my project, but I can't get it to reproduce with a unit test in tonic. I'll try to look into it more when I free up. I think just disregard for now unless anyone else is seeing the same thing. Thanks @LucioFranco !

one note, just to look into ... if you use camelcase key name, like "X-Device" instead of "x-device" error will appear.

one note, just to look into ... if you use name like "X-Device" instead of "x-device" error will appear.

Yea similar issue here, had to set metadata "authorization" instead of "Authorization" on the client - it became "Authorization" on the server though..

is it possible set metadata in middleware？ now only when the request is successful, resp can read the metadata，when error，it appears in message：
rpc err: status: Internal, message: "an internal server error occurred No such file or directory (os error 2)", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc", "date": "Wed, 03 Apr 2024 02:13:11 GMT", "content-length": "0", "logid": "666"} }

impl<T, RB> Future for LogidFuture<T>
where
    T: Future<Output = Result<http::Response<RB>, Infallible>>,
{
    type Output = T::Output;

    fn poll(
        mut self: std::pin::Pin<&mut Self>,
        cx: &mut std::task::Context<'_>,
    ) -> std::task::Poll<Self::Output> {
        match self.inner.as_mut().poll(cx) {
            std::task::Poll::Ready(mut resp) => {
                resp = resp.map(|mut v| {
                    v.headers_mut().insert(
                        HEADER_LOGID,
                        HeaderValue::from_str(&self.logid).expect("logid"),
                    );
                    v
                });
                std::task::Poll::Ready(resp)
            }
            std::task::Poll::Pending => std::task::Poll::Pending,
        }
    }
}

one note, just to look into ... if you use name like "X-Device" instead of "x-device" error will appear

I found this issue because of this. Honeycomb documents its auth header as X-Honeycomb-Team, so that's what I tried to use... and the error message is not helpful at all. Either insert and append should handle capital letters, or, at a minimum, the panic message should say something to the effect that capital letters aren't allowed.


Type annotations for method signatures

I'd like to see type annotations throughout the code, especially in function and method signatures, so I can see what's needed where, and so users and other developers will be able to see what's needed where. Sphinx (for generating documentation) can, if we're lucky, use these when it's showing the signature of methods.
I've gone through and done this in the code, but the commit isn't ready yet and I wanted to to see if https://github.com/bytecodealliance/wasmtime-py/pull/17 would be merged, if at all, as I might need to make a case for this ticket just as I do for that one.
I also drew a big diagram of all the classes, using PlantUML, as I went. Doing these at the same time is, I find, usually a very sensible idea. It took quite a bit a work to figure out what was needed where, including much use of the debugger. I think there's a new Python tool to help do this that Guido worked on, but I find that doing it manually makes for a good way of getting to know the code.

I would be very happy to see type annotations in signatures as they have virtually no cost and are a major improvement in accessibility, especially when using IDEs, but in the documentation as well.

I'd be more than happy to merge these in!

Here's the diagram I mentioned above. Work in progress.


Implement HTTP function invoke

In order to support the http data source from terraform

https://github.com/pulumi/pulumi-http


Repo sync for protected CLA branch

The pull request is created from master637417513830797495 to master to fix git push error for protected CLA branch

@cmcclister : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Update contributing docs to save people's time

Result of #269.
Save people's time by defining the contributing constraints.

It is good to expect some discussion when submitting changes to the README of a project.

That's for sure, thing is that it's usually the case that such things are in the CONTRIBUTING.md file and such discussion happen before the PR is merged.
Thanks for the effort.

That's true and also we're human and make mistakes.

Two things that would reduce friction for README PRs imo,

README examples should also exist in live unit-tests verified by the testing job. This would enforce passing README tests and also increase the size of those PRs, increasing expectation of discussion,
The README linting should be fixed, so that the README is linted as part of the CI pipeline for each PR

related https://github.com/eslint/eslint-plugin-markdown/issues/227


Update hmr-react.md

Add note about using es6 modules with webpack 2 tree-shaking

Could you sign the CLA?

Can you rebase against master? The development happens against it now (faster deployments).

Can you rebase against master? The development happens against it now (faster deployments).

signed SLA and rebased against master @bebraw @SpaceK33z

Thanks. 👍


Add ScholDoc 0.1.3-alpha

ScholDoc is a command-line utility that converts ScholarlyMarkdown documents
to HTML5, LaTeX, and Docx

Thanks!


Types that implement FromStr should implement TryFrom<&str> and friends

Updated issue text so this issue is actionable
Any type that has a FromStr should have TryFrom<{&str, String, Box<str>, Rc<str>, Arc<str>}>. (See discussion below for reasoning.)
Original issue text:
Is this correct

Blocks implements FromStr, but not TryFrom<&str>. This is actually intentional, because despite being nearly identical traits signature-wise they mean two very different things: FromStr implies parsing from a string whereas TryFrom<&str> is for when your data type is a subset of all strings. In our case, FromStr is the correct one to use.

(from @apoelstra's recently linked blog post: https://sabrinajewson.org/blog/errors
Does this mean that Network should implement TryFrom<&str> not FromStr (using Network as an example because I just looked at that code this morning during review).

No, TryFrom<&str> would imply that a Network somehow is a kind of string, which (in my view) it is not.

I disagree there is a semantic difference between them. FromStr is from the time when TryFrom didn't exist and I even remember discussions about impl<'a, T: FromStr> TryFrom<&'a str> for T and deprecating FromStr but it didn't happen because it would conflict with impl<U, T: Into<U>> TryFrom<T> for U which was more important.
I'm pretty sure if we could go back in time most developers would agree to not have FromStr in the first place and only use TryFrom<&str>.
From practical standpoint, TryFrom<&str> is more flexible since it allows borrowing the input while FromStr allow using the parse() method on str. Having also TryFrom<{String, Box<str>, Rc<str>, Arc<str>}> can enable some optimal generic code. (I would've used them in [parse_arg`](https://docs.rs/parse_arg/latest/parse_arg/) but at the time of creating some important impls were missing.) Therefore my standpoint is to implement all of them in libraries.

My understanding is the same as @Kixunil . Also

FromStr implies parsing from a string whereas TryFrom<&str> is for when your data type is a subset of all strings. In our case, FromStr is the correct one to use.

Is so subtle, that I have to grab another coffee, and even then I'm afraid I'll never be able to correctly use it in practice.
I'm not against re-purposing now redundant FromStr , but that's the first time I'm seeing someone trying to do that, and I doubt it's a well spread knowledge, so I think it will just confuse people.

I'd call that consensus! Any type that has a FromStr should have TryFrom<{&str, String, Box<str>, Rc<str>, Arc<str>}>.

Possibly we just add a macro that produces this:

impl TryFrom<&str> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: &str) -> Result<Self, Self::Error> { Self::from_str(s) }
}

impl TryFrom<Box<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Box<str>) -> Result<Self, Self::Error> { Self::from_str(&s) }
}

impl TryFrom<Arc<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Arc<str>) -> Result<Self, Self::Error> { Self::from_str(&s) }
}

impl TryFrom<Rc<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Rc<str>) -> Result<Self, Self::Error> { Self::from_str(&s) }
}

It's a bit better to call a fn internal_parse<S: AsRef<str> + Into<String>>(string: S) -> Result<Self, E> since we can avoid allocations.

The Into<String> messes with the Arc<str> and Rc<str> impls, you suggest that just for the error path, right? If that is correct I don't think we need it because std::num::IntErrorKind has good enough error handling. Or am I missing something? This builds:
impl WitnessVersion {
    fn internal_parse<S: AsRef<str>>(string: S) -> Result<Self, ConversionError> {
        let version = string.as_ref().parse::<u8>()?;
        WitnessVersion::try_from(version)
    }
}

impl FromStr for WitnessVersion {
    type Err = ConversionError;

    fn from_str(s: &str) -> Result<Self, Self::Err> { WitnessVersion::internal_parse(s) }
}

impl TryFrom<&str> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: &str) -> Result<Self, Self::Error> { WitnessVersion::internal_parse(s) }
}

impl TryFrom<Box<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Box<str>) -> Result<Self, Self::Error> { WitnessVersion::internal_parse(s) }
}

impl TryFrom<Arc<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Arc<str>) -> Result<Self, Self::Error> { WitnessVersion::internal_parse(s) }
}

impl TryFrom<Rc<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Rc<str>) -> Result<Self, Self::Error> { WitnessVersion::internal_parse(s) }
}

I can't see the allocation in the initial code I posted either (the body of internal_parse is what I had in the FromStr impl). What am I missing?

I'd call that consensus! Any type that has a FromStr should have TryFrom<{&str, String, Box<str>, Rc<str>, Arc<str>}>.

After one day of conversation? I thought (rough) consensus meant that (roughly) all stakeholders agreed.
I don't want to be known for being the pedant of the group (maybe I already am), but I kinda agree with the original post that there is a subtle semantic difference. I see FromStr and Display as both making sense for types that have "one or more possible representations as a string", while [Try]From<str> and Into<str> as for types that have a "single canonical representation as a string" (kinda meaning they can be thought of as a string themselves in some way, like the author of that post suggests). The std::convert::TryFrom docs speak specifically of "conversion" which suggests invertibility. Like, Into<str> and TryFrom<str> would make sense for Address, whereas it wouldn't for Amount. I agree that any type that has Into<str> and TryFrom<str> should obviously also have proxying impls for FromStr and Display, I wouldn't argue the reverse.
In fact, to add to @Kixunil's argument about TryFrom allowing for a more efficient impl by not needing to potentially re-allocate the string, that argument actually kinda follows the same argument because it's only possible if the type actually is the string or is gonna use the string to be part of itself. In the types where along the above argument TryFrom and Into would not make sense, you will probably never be able to use the String in the conversion. (Unless you would maybe to fancy substring-ing without re-allocation or something but afaik Rust doesn't have APIs for that.)

@tcharding for Arc and Rc we need to pass &*s. They aren't costlessly convertible anyway. (Well, I have some crazier ideas but not sure if wee should do it.)
@stevenroose not entirely, if we want to capture the string in error then TryFrom<String> is costless on error path. But my larger point was about being used in generic code. Being able to treat both borrowed and non-borrowed strings the same is just nicer.
Anyway, this debate may belong to URLO since we want to be in sync with Rust ecosystem.

Anyway, this debate may belong to URLO since we want to be in sync with Rust ecosystem.

You mean like updating MSRV as soon as new stable is out? ;)
Fwiw, personally I don't care about error case optimization 99.9% of the time. Few users will be doing thousands of iterations of an error case.

Heh, I half-expected this kind of snark but I hoped everyone understands that following Rust guidelines etc is recommendation, not obligation.
I personally like to avoid allocations or other if I can without significantly degrading other properties of the code. In this case I see no downside except for supposed semantic difference which I don't believe in.

I don't want to be known for being the pedant of the group (maybe I already am), but I kinda agree with the original post that there is a subtle semantic difference.

It's good to be a pedant when working on an important library like rust-bitcoin.
@Kixunil Seems like initial couple of voices are pro-semantic-difference. Looking at it a little bit more - if there was supposed to be no difference, why is standard library not implementing TryFrom<String> for i32, again? Were there any technical reasons or are we waiting for something?
I think we can ignore how these types came to be. It's not very important. If the community thinks it's worthwhile to have a difference, and we already have the traits, so there can be a difference.
OK... So FromStr is for parsing from &'str without ability to take over the ownership (because it's parsing, not a conversion)...
... since I'm a conformist, let me look at the past discussion from that PoV...

No, TryFrom<&str> would imply that a Network somehow is a kind of string, which (in my view) it is not.

OK. So here I would dissagree. Is it just "network" in some abstract sense or rather "network designator" or "network type". Because if you have a "mainnet" or "bitcoin" string it very much is a designator of an network. It doesn't even require any "parsing" (like checking digits). It's a straight lookup in a list.
So I'd say that even assuming FromStr is distinct, Network should still impl TryFrom<String> etc.
Looking more practically - is there any benefit (class of bugs prevented) that would make not implementing it better than implementing it for the consumers of this library?

So I'd say that even assuming FromStr is distinct, Network should still impl TryFrom<String> etc.

Ok, I buy this.

After one day of conversation? I thought (rough) consensus meant that (roughly) all stakeholders agreed.

Yes that's what I meant :) We had Andrew, dpc, and Kix all in agreement, that is one more than roughly all stakeholders that show up on a daily basis over the last 18 months. This topic is mainly of academic interest so there is no risk to getting it wrong. It hasn't sunk in yet that you are showing up regularly but it will soon, no doubt!

I don't want to be known for being the pedant of the group

You'll have to fight for that title, we have a few proud contenders. Legendary usage of language BTW, I had to look up what "pedant" means - such a good description for how I often feel.
As for the rest of the discussion, I'm struggling with the difference between "parsing" and int from "6" and "conversion" of an int for "6"? I also struggled with the whole "when to implement From<Foo> and when to use inherent from_foo discussion. Is the string "6" a number or is it a string representation of a number that must be parsed, I'm not sure I get the subtlety?

why is standard library not implementing TryFrom<String> for i32? Were there any technical reasons or are we waiting for something?

I strongly believe that the reason is "nobody made a PR for it". I'm actually thinking of making it though I worry it might border on abuse of ACP.

Looking more practically - is there any benefit (class of bugs prevented) that would make not implementing it better than implementing it for the consumers of this library?

Exactly, I don't see any. If someone provides a real example of harm I will be first to drop this.

I'm struggling with the difference between "parsing" and int from "6" and "conversion" of an int for "6"?

Me too and I guess it's because there's no meaningful difference between the other than "one makes more instructions than the other during conversion by some arbitrary margin".

Me too and I guess it's because there's no meaningful difference between the other than "one makes more instructions than the other during conversion by some arbitrary margin".

To me it's: if you need to algorithmically calculate a different representation from a string encoding, then it's parsing. If it's near to 1:1 match / lookup, then it passes as a conversion. I agree that it's fuzzy and somewhat arbitrary, but it doesn't invalidate it necessarily.

It hasn't sunk in yet that you are showing up regularly but it will soon, no doubt!

I feel that, haha. And don't want to set expectations either.. But anyway.

I had to look up what "pedant" means

"someone who has the habit of being pedantic"?
To me it seems like every reply in the forums agrees there is a semantic difference. But then again people lingering forums are usually the more pedantic kind :sweat_smile:
To me the semantic difference is equivalent to the semantic difference between parsing and converting. I don't know if that helps. Conversion more strongly implies there is an expected canonical string. But I wouldn't say that's all. Yeah it's hard to pin down, but to me there is a semantic difference between parsing and converting. Like a conversion you expect to "generally work, except in some cases when there was some error". While parsing is more like "let's see if this in any way makes sense to be of this type".
Also, tbh I think the implementation stdlib has for both TryFrom (none) and FromStr. All of those types I would expect have TryFrom (Paths etc) actually have From.
Think like this: 5u64 and 5u32 are obviously exactly the same semantic value of five, but need a TryFrom conversion because obviously there are some u64's that are not u32's.

I'm picking this up to work on it

We don't assign, just go wild and push up a PR. Thanks!

We don't assign, just go wild and push up a PR. Thanks!

Alright, thanks for the feedback

The Into<String> messes with the Arc<str> and Rc<str> impls, you suggest that just for the error path, right? If that is correct I don't think we need it because std::num::IntErrorKind has good enough error handling. Or am I missing something? This builds:
impl WitnessVersion {
    fn internal_parse<S: AsRef<str>>(string: S) -> Result<Self, ConversionError> {
        let version = string.as_ref().parse::<u8>()?;
        WitnessVersion::try_from(version)
    }
}

impl FromStr for WitnessVersion {
    type Err = ConversionError;

    fn from_str(s: &str) -> Result<Self, Self::Err> { WitnessVersion::internal_parse(s) }
}

impl TryFrom<&str> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: &str) -> Result<Self, Self::Error> { WitnessVersion::internal_parse(s) }
}

impl TryFrom<Box<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Box<str>) -> Result<Self, Self::Error> { WitnessVersion::internal_parse(s) }
}

impl TryFrom<Arc<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Arc<str>) -> Result<Self, Self::Error> { WitnessVersion::internal_parse(s) }
}

impl TryFrom<Rc<str>> for WitnessVersion {
    type Error = ConversionError;

    fn try_from(s: Rc<str>) -> Result<Self, Self::Error> { WitnessVersion::internal_parse(s) }
}

Hey @tcharding , needed a little sanity check. Do these changes need to be implemented only for WitnessVersion ? and in the implementation, you refer to ConversionError which is not in the original file. So should I make a custom enum for the implementation?

Its in the title :) "Types that implement FromStr should implement TryFrom<&str> and friends)"
But I don't know the validity of this issue, I started reading the thread again and the linked discussion on URLO but I don't know what others want to do about this.

I continue to dislike this idea and think that From is about converting between string-like types and FromStr is about parsing strings. But I won't hold it up because in the linked issue apparently many other people disagree and have some idea about what they want done here.

@apoelstra if there wasn't potential performance optimization I wouldn't want to do it either. Maybe we could have parse_arg::ParseArg instead which is more general and achieves the same thing but it could look a bit weird to use that to parse non-arg strings.

I think we should do the most idiomatic thing, which is FromStr.
If we also have From<&str> I think that's mostly harmless, since nobody will realize that it exists.

I never said to drop FromStr...
The real power of these generics comes from having both TryFrom<&str> and TryFrom<String>.


src: move State off of Request (WIP)

error[E0119]: conflicting implementations of trait `endpoint::Endpoint<_>`:
  --> src\endpoint.rs:70:1
   |
54 | / impl<State, F, Fut, Res> Endpoint<State> for F
55 | | where
56 | |     State: Send + Sync + 'static,
57 | |     F: Send + Sync + 'static + Fn(Request) -> Fut,
...  |
67 | |     }
68 | | }
   | |_- first implementation here
69 |
70 | / impl<State, F, Fut, Res> Endpoint<State> for F
71 | | where
72 | |     State: Send + Sync + 'static,
73 | |     F: Send + Sync + 'static + Fn(Request, State) -> Fut,
...  |
83 | |     }
84 | | }
   | |_^ conflicting implementation

Not sure I understand this error. F should be a distinct type for both?? Note: the difference is in F and those compiler messages don't show enough lines for that.

I guess the compiler thinks F might implement both Fn(Request) -> Fut and Fn(Request, State) -> Fut. You can make such a type with #![feature(fn_traits, unboxed_closures)] by manually implementing Fn and its supertraits.

Err... this isn't solving the issue that #642 and #644 solve... this is just general ergonomics, imo? Likewise see https://github.com/http-rs/tide/issues/643#issuecomment-657621351

One interesting implication of this PR is that it would've made https://github.com/http-rs/tide/pull/670 easier to implement; no State means no Default either.


VM Ticket Control

Added per VM Control with Tickets to add granularity.

@Diogo21Costa Ready, I think :)

@Diogo21Costa Ready, I think :)

LGTM :) Have you tested these changes?

Yes! Only the baremetal setup, but I think it won't be an issue with other guests.

Yes! Only the baremetal setup, but I think it won't be an issue with other guests.

Ok, LGTM!


Multiple explicit Out-Of-Band invitations with public DID

Current state:
Inviter throws exceptions when receiving connection requests to explicit public Out-Of-Band invitations, when there is more than one explicit public Out-Of-Band invitation in state invitation. The connection isn't established and stays in state invitation.
Desired state:
Inviter can create multiple explicit public Out-Of-Band invitations and invitees can receive them when they want to, without exceptions in the inviter.
Details:
When creating an invitation with public_did=true, the inviter will create a database entry for a connection with field invitation_key = public_did.verkey (see outofbound manager #L247). When providing multiple invitations, the inviter will have multiple invitations with the same invitation_key (and initially the same state invitation). If now an invitee receives one of the invitations, the inviter will run into an StorageDuplicateError in didexchange manager #L396.
If I understand the code correctly, fixing this would need some adjustments on how the didexchange manager correlates a received request to a previously created invitation.

@ffendt The fix is ready if you want to give it a quick test.

@shaangill025 Looks good, I can't reproduce the problem with the fixes from your PR. Thank you very much.
I'll close this issue and subscribe to the PR to retest if there are any major code changes.


Compiler errors when trying to build with Swift 5

Hello. I use Cocoapods to install your library. Very useful, thanks!
I got some issues:
What I did?

install framework using pod Geodesy
tried to build with Swift 5

What went wrong?

I get compiler errors in Region.swift file: 'characters' is unavailable: Please use String directly

I saw that a commit which should fix exactly that, but the build for that commit has failed, so it's possible that commit was ignored and did not get into a master branch. Another options is that the .podspec version has to be also bumped again.
Really enjoying your work, but I have to manually use the files because of those errors. That would wonderful if I could just use the pod directly.

Thanks for the pr. I've invited you to be a contributor.

I've released a swift 5 version. 1.2.0 and updated the .podspec. I believe this should fix your issue. Please let me know.

Hi Todd! Thanks for being so prominent :)
Things but worse, unfortunately. After I run pod update the versos of the pod is still 1.1.1 and more over the files Geohash.swift and Geodesy.xcconfig are missing, thus I still have my project not compilable with this pod installed.
Have you published the cocoapod?
Could my pull requests be a case of such errors?

Seems like compile time errors are resolved with Xcode restart and clean build. But the problem with cocoa pod version being 1.1.1 instead of 1.2.0 still remains.

I ran into this problem and it appears that the 1.2.0 .podspec isn't in the Cocoapods spec repo.  To get around it, I added this to my Podfile:
  pod 'Geodesy',
      :git => 'https://github.com/proxpero/Geodesy.git',
      :tag => '1.2.0'

That installed the correct version but the output from pod install still said it installed 1.1.1.

Yes the podspec needs to be pushed to the cocoapods trunk repo.
Also, the .swift-version file should be updated to say 5.0


feat(units): adding units, changing tf2d interface

Adding subclasses to float and numpy array to let them carry unit information. Note that this is intentionally a very thin wrapper and I don't support things like arithmetics/comparisons that also take unit into account. To do that we'll have to use a full units framework (https://github.com/hgrecco/pint looks pretty good), but then we'll be taking on one more dependency and can't use numpy operations that pint doesn't support.
Making ThomasFermi2dData a typed NamedTuple

Closing for now to fix up more interfaces


⚠ Samsung has degraded performance

In 949dddf, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 1955 ms

Resolved: Samsung performance has improved in 81103a3.


emmet.extensionsPath do not work on 1.14.0

VScode cannot recognize the path.

@thelastfantasy The path should be set to the folder not the file


[Build] Centralize .NET NuGet Package Versions

Summary of the Pull Request
Enables Centralized Package Management for .NET projects. All NuGet package versions are managed within Directory.Packages.props, removing the need for individual versions to be defined within a project. It fully incorporates with Visual Studio and will automatically update the version in a single place / add a new entry when a new package is added to a project.
Currently only .NET packages are supported.

PR Checklist

[ ] Closes: #xxx
[X] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

Run ls -Recurse -include bin,obj,ARM64,x86,x64,packages,Release,Debug | rmdir -recurse in PowerShell from the root PowerToys repo directory to remove all packages and existing compiled binaries
Execute a NuGet Package Restore
Rebuild the entire solution
Temporarily update a package version and verify Directory.Packages.props is updated with a version matching
Temporarily add a package to a project and verify Directory.Packages.props is updated with a new entry referencing the package and version.

Changes LGTM. Thank you for the contribution!
We need to change some stuff for the release CI, which is failing:
##[error]The nuget command failed with exit code(1) and error(NU1507: There are 2 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping (https://aka.ms/nuget-package-source-mapping) or specify a single package source. The following sources are defined: PowerToysDependencies, https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-Labs/nuget/v3/index.json

I'll delete the additional mapping since I think we've added it to our sources already, or just try adding source mappings and it should be able to figure it out.
That's on my plate now ;) Thank you!


CanonicalPathways distribution

Here's the distribution of the number of genes in the canonicalpathways dataset from PLIER.
Obtained via
library(PLIER)
data(canonicalPathways)
hist(colSums(canonicalPathways), breaks=30)

Wrong repo :)


Exporting a snapshot with depth=900 might not be sufficient to bootstrap a forest or lotus node

Describe the bug

To Reproduce Steps to reproduce the behaviour:

forest --chain calibnet --encrypt-keystore false --no-gc --height=-900 --auto-download-snapshot
forest-cli snapshot export -d=900
forest --chain calibnet --encrypt-keystore false --import-snapshot [SNAPSHOT] or lotus --remove-existing-chain --import-snapshot [SNAPSHTO] fail with below errors

7u5nd7v6ovgi4dyitvsc757ayemvbmdg bafy2bzacecxlqvpliee2eliwtrw2f4jg2tmsxgamsaiphhm6guxprljkv57jw]: collectChain failed: collectChain syncMessages: message processing failed: validating block bafy2bzacebd5w4eezqkhbilor4xu3gvteaoquc762v2ucllhjdqmwmhtpbh4c: 1 error occurred:
        * determining if miner has min power failed:
    github.com/filecoin-project/lotus/chain/consensus/filcns.(*FilecoinEC).ValidateBlock.func2
        /opt/filecoin/chain/consensus/filcns/filecoin.go:186
  - loading power actor state:
    github.com/filecoin-project/lotus/chain/stmgr.minerHasMinPower
        /opt/filecoin/chain/stmgr/actors.go:410
  - load state tree:
    github.com/filecoin-project/lotus/chain/stmgr.(*StateManager).ParentState
        /opt/filecoin/chain/stmgr/read.go:28
  - failed to load state tree bafy2bzaced4wmuzsqsbeap77zfypimgtpolgtuxgjutvrwwg2itt3fqe3yxua:
    github.com/filecoin-project/lotus/chain/state.LoadStateTree
        /opt/filecoin/chain/state/statetree.go:295
  - failed to load hamt node:
    github.com/filecoin-project/specs-actors/actors/util/adt.AsMap
        /go/pkg/mod/github.com/filecoin-project/specs-actors@v0.9.15/actors/util/adt/map.go:41
  - ipld: could not find bafy2bzaced4wmuzsqsbeap77zfypimgtpolgtuxgjutvrwwg2itt3fqe3yxua

Repo CI log: https://github.com/ChainSafe/forest/actions/runs/8423386587/job/23080675345
Log output

Log Output
paste log output...

Expected behaviour

Screenshots

Environment (please complete the following information):

OS:
Branch/commit

Other information and links

@hanabi1224, why are you exporting with 900 recent stateroots? The default is 2000.

@LesnyRumcajs The minimum allow value is CHAIN_FINALITY=900, if that's insufficient we should update the CLI with a working minimum, does that make sense?

The current minimum value matches the logic in Lotus. There may be a use case where setting it that low makes sense. At most, I'd add a warning, but I'd still leave enough rope for the user to hang himself with it. :)

I think you have some "off by 1" issue somewhere. During "ideal conditions" i.e. no reorgs, 900 state roots "should" be enough. I tried with forest-cli snapshot export -d=901 and it works where as 900 doesn't. I also did forest-cli state fetch on the state root (SNAPSHOT_HEAD - 900) Forest fails to load from, and everything works after that as well.

@ec2 Thanks for your investigation, there is indeed some offset by 1 issue in the code.

Update:
This is a problem in the daemon logic instead of the snapshot export logic. In this case, the heaviest tipset in the snapshot should be trusted and skipped.
Repro steps:
# Export a forest snapshot
forest-cli snapshot export --skip-checksum -t 1516720 -d 900 -o forest_1516720.car.zst
# Export a lotus snapshot
lotus chain export --skip-old-msgs --tipset @1516720 --recent-stateroots 900 lotus_1516720.car

# The snapshots are confirmed identical
zstd -d forest_1516720.car.zst
cmp forest_1516720.car lotus_1516720.car

# Bootstrap forest from scratch
forest --chain calibnet --encrypt-keystore false --save-token /tmp/forest_token --import-snapshot forest_1516720.car.zst

# Got
# WARN forest_filecoin::chain_sync::tipset_syncer: Validating block [CID = bafy2bzaced5izwa2uuule3y2qtlvfmznq6rv3bi7o5rf243pqtbcgcxnxldwm] in EPOCH = 1516720 failed: Validation error: Validation error: Consensus error: StateManager error: Can't create a valid state tree from the given root. This error may indicate unsupported version. state_root_cid=bafy2bzacec2vt33g6ydokkuj5k6ljvhrgoeo5enxntqalsui6a32wnmx6ckca, state_root_version=unknown parent_state=bafy2bzacec3zzdczp46lunfghkfemarev66a6mk346hwqo3562ofecemn73sw

# Bootstrap lotus from scratch
lotus daemon --remove-existing-chain --import-snapshot ~/fr/snapshots/calibnet/forest_1516720.car.zst
# Got
...
2024-04-11T19:28:11.230+0800    INFO    chain   chain/sync.go:625       block validation        {"took": 4.91154541, "height": "1516721", "age": 6881.230240799}
...

@lemmih  Looking into the lotus code. It seems that lotus Syncer validates tipsets in (current_head+1)..proposed_head range, while forest Syncer validates tipsets in current_head..proposed_head range.
Lotus code:  https://github.com/filecoin-project/lotus/blob/master/chain/sync.go#L732
blockSet := []*types.TipSet{incoming}

// Parent of the new (possibly better) tipset that we need to fetch next.
at := incoming.Parents()

// we want to sync all the blocks until the height above our
// best tipset so far
untilHeight := known.Height() + 1
...
loop:
	for blockSet[len(blockSet)-1].Height() > untilHeight {
		...
		ts, err := syncer.store.LoadTipSet(ctx, at)
		...
		blockSet = append(blockSet, ts)
		at = ts.Parents()
	}

Forest code:
let mut parent_tipsets = nonempty![proposed_head.clone()];
...
'sync: loop {
	let oldest_parent = parent_tipsets.last();
	...
	// Check if we are at the end of the range
	if oldest_parent.epoch() <= current_head.epoch() {
		// Current tipset epoch is less than or equal to the epoch of
		// Tipset we a synchronizing toward, stop.
		break;
	}
	...
	// Attempt to load the parent tipset from local store
	if let Some(tipset) = chain_store
		.chain_index
		.load_tipset(oldest_parent.parents())?
	{
		parent_blocks.extend(tipset.cids());
		parent_tipsets.push(tipset);
		continue;
	}
}


Create a public API replacement for TypeSystem

(Capturing some in-person discussion between me and @bwilkerson)
Currently the analyzer public API exposes the TypeSystem class to clients in three ways:

AnalysisSession.typeSystem returns it
ResolveResult.typeSystem returns it
DartType.flattenFutures requires it as an argument

Several of the methods on TypeSystem seem very unlikely to be needed by clients.  We would like to change the public API so that it exposes some other object (with a narrower interface), and relegate TypeSystem to be an implementation detail of the analyzer.

https://dart-review.googlesource.com/c/sdk/+/87602


Improve existing DAAS Logging

Investigate the existing logging that exists in DAAS and allow the collectors \ analyzers to generate logs of their own that can be used to check what happened or what went wrong

Enabling Application Logging by going to Website diagnostics (not sure if this is 100% required)
Add AppSetting DAAS_DEBUG and set it to TRUE
Restart the WebApp
Create a new file in D:\home\site\wwwroot\App_Data\Jobs\Continuous\DaaS called DaasRunnger.exe.config and paste the following contents

<?xml version="1.0" encoding="utf-8" ?>
	<configuration>
	<system.diagnostics>
	    <trace autoflush="true">
	      <listeners>
	        <add
	        name="TextWriterTraceListener"
	        type="System.Diagnostics.TextWriterTraceListener"
	        initializeData="d:\home\logfiles\Daas.trace.log" />
	      </listeners>
	    </trace>
	  </system.diagnostics>
	  </configuration>

Restart DaasRunner once to be sure

Look for the log file present in d:\home\logfiles\Daas.trace.log (there will be one per instance)


initWithScrollView:delegate: should call initWithFrame: on super, not self

Since initWithScrollView:delegate: is a de-facto designated initializer it should call designated initializer  of superclass with super, not self
Explicitly stating that it's a designated initializer with NS_DESIGNATED_INITIALIZER would be nice.

Did this not result in a warning at https://github.com/soffes/sspulltorefresh/blob/3ee6473e1f35c8c1eab8c28c933592141a8a9759/SSPullToRefresh/SSPullToRefreshView.m#L161
which is my original complaint?
The thing is I can't subclass SSPullToRefreshView in Swift without overriding init(frame:) which is odd.

Fixed that in 68ac0ee1febdf1e514b128f2c6cd05848fa66828


srcset missing from ~ tag helper.

looking at https://github.com/aspnet/Mvc/issues/2807 I think the srcset attribute is missing for the list.

e73e73acddf824260aed9d8be761543bb793ba61


List type slots are populated by processor with only last item in list and not the entire list

Rasa Core version:
0.8.4
Python version:
3.5.4
Operating system (windows, osx, ...):
Windows 10
Issue:
When running a bot that has multiple items for the same entity returned from the NLU, the rasa_core.processor is not pushing the list to a list type slot, but only pushing the last item.  This is possibly occurring due to the code around line 228 of processor.py
 # store all entities as slots
        for e in self.domain.slots_for_entities(parse_data["entities"]):
            tracker.update(e)

Here is an example from the core log when running in debug mode.  Notice the two values for location in the first row, but the current slot values only receives the final item of the list:
DEBUG:rasa_core.processor:Received user message 'Tell me about Prague and London' with intent '{'confidence': 0.2412529688289353, 'name': 'store_name'}' and entities '[{'value': 'prague', 'extractor': 'ner_crf', 'entity': 'location', 'start': 14, 'end': 20}, {'value': 'london', 'extractor': 'ner_crf', 'entity': 'location', 'start': 25, 'end': 31}]'
DEBUG:rasa_core.processor:Logged UserUtterance - tracker now has 4 events
DEBUG:rasa_core.processor:Current slot values:
	location: london
	person: None

Content of domain file (if used & relevant):
entities:
  - user_name
  - location
  - person

slots:
  location:
    type: list
  person:
    type: text

@akelad So when can we expect the update

That depends, someone from the community might get to it, otherwise we'll look into it eventually. In the meantime though you can use a custom action to fill the list slot

@akelad Can I take this one as a first issue?

sure

how is it going @adhaamehab do you need any help?

@AbdurRub so a simple solution for now while this isn't fixed is to use a custom action to set the slot as a list

duplicates #171

@akelad hello, I'm trying to do that but it only takes the last element of the list. This is what I'm doing:
                   matches = []                     for doc in docs:                         event = doc['event']['name']                         matches.append(event)                     return [SlotSet('matching_events', matches)]
but when i do this:
 matches = tracker.get_slot("matching_events")
it only has one element.
Is this the correct way to use it?

Please post this kind of question in the forum. Ideally including the domain file, so we can see whether the slot is of type list


Run tests only in command line.

Hi guys,
We would like to use mocha to test our meteor app only using command line, when we directly run
meteor --test.
Is it possible to configure the package so that velocity does not start together with the app during development?

:+1:

:+1:

In other words, is it possible to have mocha integration with velocity using this package, but without forcing us to use html-reporter?
Do you think that splitting this package into mike:mocha-base and mike:mocha, with the latter simply depending on mocha-base and velocity:html-reporter would be a good solution?

That's been suggested before, and I think it's probably a good idea. I've been holding off, just because it means I have to release two packages instead of one. Would it be enough to be able to "turn off" the reporter, or are you concerned that the reporter is interfering with the front-end of your app?

Yes, it would be helpful to be able to turn the reporter off instead of changing css files.
Splitting the package is a good idea. It would also be nice to have an ability to turn whole velocity off with environment variable. I tested meteor-jasmine and you can just write "VELOCITY=0 meteor" which switches velocity off for the run.

:+1: for both the ability to turn off with an evironment var and a command line only version

yes please!

:+1: For passing environment variables to Velocity

Related to #101

+1

+1

:+1:

+1


BUG: addImage rotation doesn't work

Hey there,
I'm trying to rotate an image in my PDF, but it doesn't seem to work.
Even the live editor (http://mrrio.github.io/jsPDF/) ignores the angle when passed into the object like so:
// Rotate Image - new feature as of 2014-09-20
doc.addImage({
imageData : imgData,
angle     : -20,
x         : 10,
y         : 78,
w         : 45,
h         : 58
});
Does anybody have an idea what the problem could be or how to get it to work?
Thanks!

@lllHuber did you ever find an answer to this problem? I am having the same issue.

 Probably using a PDF  transformation matrix is a cleaner solution.

If a transformation matrix is possible in PDF for images

Yeah checked the reference. Check chapter 8.9.4 image coordinate system.

Fixed in PR #1560

Rotation repaired by PR #1560
Will be in the next release.


Error when compiling sample app using Spring-boot 2.4.9 and Spring-cloud 2020.0.3: The bean 'tokenRelayGatewayFilterFactory', defined in class path resource [org/springframework/cloud/security/oauth2/gateway/TokenRelayAutoConfiguration.class], could not be registered

Description:
When compiling micro services sample app, change of maven libs from:
spring-boot: 2.3.8.RELEASE -> 2.4.9
spring-cloud-dependencies: Hoxton.SR10 -> 2020.0.3
error is thrown:
The bean 'tokenRelayGatewayFilterFactory', defined in class path resource [org/springframework/cloud/security/oauth2/gateway/TokenRelayAutoConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/cloud/gateway/config/GatewayAutoConfiguration$TokenRelayConfiguration.class] and overriding is disabled.
Based on the compability matrix spring-boot 2.4.x should work with spring-cloud 2020.0.x (https://spring.io/projects/spring-cloud).
Github:
https://github.com/SaiUpadhyayula/springboot-microservices-project
Steps to reproduce:

clone & compile
git clone https://github.com/SaiUpadhyayula/springboot-microservices-project
cd springboot-microservices-project/api-gateway-service/api-gateway-service/
mvn clean install # no error while compiling

change spring-boot version from 2.3.x to 2.4.x
FROM <version>2.3.8.RELEASE</version> TO <version>2.4.9</version>

change spring-cloud-dependencies version from Hoxton.x to 2020.0.x
FROM <spring-cloud.version>Hoxton.SR10</spring-cloud.version> TO <spring-cloud.version>2020.0.3</spring-cloud.version>

add version to spring-cloud-starter-security:
<version>2.2.5.RELEASE<version>

mvn clean install # error is thrown

Error Description:
The bean 'tokenRelayGatewayFilterFactory', defined in class path resource [org/springframework/cloud/security/oauth2/gateway/TokenRelayAutoConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/cloud/gateway/config/GatewayAutoConfiguration$TokenRelayConfiguration.class] and overriding is disabled.
Action:
Consider renaming one of the beans or enabling overriding by setting spring.main.allow-bean-definition-overriding=true
Workaround:
Add following line to application.properties:
spring.main.allow-bean-definition-overriding=true

With the latest spring cloud projects, spring-cloud-starter-security has been removed and the files have been moved to respective projects. As part of this, looks like TokenRelayGatewayFilterFactory was moved to org.springframework.cloud.gateway.filter.factory.TokenRelayGatewayFilterFactory.
I removed the dependency to org.springframework.cloud:spring-cloud-starter-security and the app is working fine.

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.