[bazel] ./bazelisk.sh build //hw:verilator fails fusesoc_build failed: error executing FuseSoC command

Description
On branch master @  commit 7dea163643309eeddd31b2c9f6a278d90596f0b4
Ubuntu 24.04 (WSL2)
Verilator  5.031 devel rev v5.030-137-g676fd3163
Fusesoc  0.5.dev0
when running ./bazelisk.sh build //hw:verilator
I get the following error (I have trimmed some of the INFO messages and some verilator missing pin warnings)
./bazelisk.sh build //hw:verilator
INFO: Analyzed target //hw:verilator (679 packages loaded, 26757 targets configured).
ERROR: /home/my_home/Projects/opentitan/hw/BUILD:35:14: FuseSoC hw/build.verilator_real/sim-verilator/Vchip_sim_tb failed: (Exit 1): fusesoc_build failed: error executing FuseSoC command (from target //hw:verilator_real) bazel-out/k8-opt-exec-ST-d57f47055a04/bin/util/fusesoc_build '--config=bazel-out/k8-fastbuild/bin/hw/build.verilator_real.fusesoc_config.toml' '--cores-root=.' run '--flag=fileset_top' '--target=sim' ... (remaining 6 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
INFO: Preparing lowrisc:constants:jtag_id_pkg:0
INFO: Preparing lowrisc:constants:top_pkg:0

INFO: Generating lowrisc:prim:ram_1r1w-impl:0
INFO: Generating lowrisc:prim:ram_2p-impl:0
INFO: Generating lowrisc:prim:rom-impl:0
INFO: Generating lowrisc:prim:and2-impl:0
INFO: Generating lowrisc:prim:buf-impl:0
INFO: Generating lowrisc:prim:clock_buf-impl:0
INFO: Generating lowrisc:prim:flash-impl:0
INFO: Generating lowrisc:prim:flop-impl:0
INFO: Generating lowrisc:prim:otp-impl:0
INFO: Generating lowrisc:prim:pad_attr-impl:0
INFO: Generating lowrisc:prim:pad_wrapper-impl:0
INFO: Generating lowrisc:prim:usb_diff_rx-impl:0
INFO: Generating lowrisc:prim:xnor2-impl:0
INFO: Generating lowrisc:prim:xor2-impl:0
INFO: Wrote dependency graph to bazel-out/k8-fastbuild/bin/hw/build.verilator_real/sim-verilator/lowrisc_dv_chip_verilator_sim_0.1.deps-after-generators.dot
INFO: Setting up project
INFO: Running pre_build script check_tool_requirements_verilator
INFO: Building simulation model
INFO: verilator -f lowrisc_dv_chip_verilator_sim_0.1.vc -DDISABLE_PRIM_CDC_RAND_DELAY --trace --trace-fst --trace-structs --trace-params --trace-max-array 1024 --unroll-count 512 -CFLAGS " -std=c++11 -Wall -DVM_TRACE_FMT_FST -DVL_USER_STOP -DTOPLEVEL_NAME=chip_sim_tb" -LDFLAGS " -pthread -lutil -lelf" -Wall --threads 4 -Wno-fatal --threads 4

ERROR: %Warning-PINMISSING: ../src/lowrisc_dv_sim_sram_0/sim_sram.sv:68:7: Cell has missing pin: 'en_ifetch_i'
   68 |     ) u_tl_adapter_sim_sram (
      |       ^~~~~~~~~~~~~~~~~~~~~
                     ../src/lowrisc_tlul_adapter_sram_0.1/rtl/tlul_adapter_sram.sv:53:19: ... Location of port declaration
   53 |   input   mubi4_t en_ifetch_i,
      |                   ^~~~~~~~~~~
                     ... For warning description see https://verilator.org/warn/PINMISSING?v=5.031
                     ... Use "/* verilator lint_off PINMISSING */" and lint_on around source to disable this message.
%Warning-PINMISSING: ../src/lowrisc_dv_sim_sram_0/sim_sram.sv:68:7: Cell has missing pin: 'req_type_o'
   68 |     ) u_tl_adapter_sim_sram (
      |       ^~~~~~~~~~~~~~~~~~~~~
                     ../src/lowrisc_tlul_adapter_sram_0.1/rtl/tlul_adapter_sram.sv:57:32: ... Location of port declaration
   57 |   output mubi4_t               req_type_o,
      |                                ^~~~~~~~~~
%Warning-PINMISSING: ../src/lowrisc_dv_sim_sram_0/sim_sram.sv:68:7: Cell has missing pin: 'intg_error_o'
   68 |     ) u_tl_adapter_sim_sram (
      |       ^~~~~~~~~~~~~~~~~~~~~
                     ../src/lowrisc_tlul_adapter_sram_0.1/rtl/tlul_adapter_sram.sv:63:32: ... Location of port declaration
   63 |   output logic                 intg_error_o,
      |                                ^~~~~~~~~~~~
%Warning-PINMISSING: ../src/lowrisc_dv_sim_sram_0/sim_sram.sv:68:7: Cell has missing pin: 'user_rsvd_o'
   68 |     ) u_tl_adapter_sim_sram (
      |       ^~~~~~~~~~~~~~~~~~~~~
                     ../src/lowrisc_tlul_adapter_sram_0.1/rtl/tlul_adapter_sram.sv:64:32: ... Location of port declaration
   64 |   output logic [RsvdWidth-1:0] user_rsvd_o,
      |                                ^~~~~~~~~~~
%Warning-PINMISSING: ../src/lowrisc_dv_sim_sram_0/sim_sram.sv:94:7: Cell has missing pin: 'cfg_i'
   94 |     ) u_sram (
      |       ^~~~~~
                     ../src/lowrisc_prim_abstract_ram_1p_0/prim_ram_1p.sv:37:28: ... Location of port declaration
   37 |   input ram_1p_cfg_t       cfg_i
      |                            ^~~~~

%Warning-WIDTHEXPAND: ../src/lowrisc_systems_chip_earlgrey_verilator_0.1/rtl/chip_earlgrey_verilator.sv:588:6: Input port connection 'scanmode_i' expects 4 bits on the pin connection, but pin connection's VARREF 'scanmode' generates 1 bits.
                                                                                : ... note: In instance 'chip_sim_tb.u_dut'
  588 |     .scanmode_i                   ( scanmode                   )
      |      ^~~~~~~~~~
%Error: Exiting due to 6 error(s)
make: *** [Makefile:16: Vchip_sim_tb.mk] Error 1

ERROR: Failed to build lowrisc:dv:chip_verilator_sim:0.1 : '['make']' exited with an error: 2
Creating prim_pkg.sv
Core file written to prim_pkg.core.
Implementations for primitive clock_div: generic, xilinx_ultrascale
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_clock_div.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_clock_div-impl_08bojwqhq/prim_clock_div.sv
Creating core file for primitive clock_div.
Core file written to /tmp/lowrisc_prim_clock_div-impl_08bojwqhq/prim_clock_div.core
Implementations for primitive clock_gating: generic, xilinx, xilinx_ultrascale
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_clock_gating.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_clock_gating-impl_04qr03s4o/prim_clock_gating.sv
Creating core file for primitive clock_gating.
Core file written to /tmp/lowrisc_prim_clock_gating-impl_04qr03s4o/prim_clock_gating.core
Implementations for primitive clock_inv: generic, xilinx_ultrascale
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_clock_inv.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_clock_inv-impl_08gr9uq74/prim_clock_inv.sv
Creating core file for primitive clock_inv.
Core file written to /tmp/lowrisc_prim_clock_inv-impl_08gr9uq74/prim_clock_inv.core
Implementations for primitive clock_mux2: xilinx_ultrascale, generic, xilinx
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_clock_mux2.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_clock_mux2-impl_0rx8g_jha/prim_clock_mux2.sv
Creating core file for primitive clock_mux2.
Core file written to /tmp/lowrisc_prim_clock_mux2-impl_0rx8g_jha/prim_clock_mux2.core
Implementations for primitive flop_2sync: generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_flop_2sync.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_flop_2sync-impl_0hb95pzz0/prim_flop_2sync.sv
Creating core file for primitive flop_2sync.
Core file written to /tmp/lowrisc_prim_flop_2sync-impl_0hb95pzz0/prim_flop_2sync.core
Implementations for primitive flop_en: xilinx, xilinx_ultrascale, generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_flop_en.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_flop_en-impl_0a0a34evp/prim_flop_en.sv
Creating core file for primitive flop_en.
Core file written to /tmp/lowrisc_prim_flop_en-impl_0a0a34evp/prim_flop_en.core
Implementations for primitive ram_1p: badbit, generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_ram_1p.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_ram_1p-impl_0au6j663c/prim_ram_1p.sv
Creating core file for primitive ram_1p.
Core file written to /tmp/lowrisc_prim_ram_1p-impl_0au6j663c/prim_ram_1p.core
Implementations for primitive ram_1r1w: generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_ram_1r1w.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_ram_1r1w-impl_08jbj5by6/prim_ram_1r1w.sv
Creating core file for primitive ram_1r1w.
Core file written to /tmp/lowrisc_prim_ram_1r1w-impl_08jbj5by6/prim_ram_1r1w.core
Implementations for primitive ram_2p: generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_ram_2p.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_ram_2p-impl_0qsunxj8r/prim_ram_2p.sv
Creating core file for primitive ram_2p.
Core file written to /tmp/lowrisc_prim_ram_2p-impl_0qsunxj8r/prim_ram_2p.core
Implementations for primitive rom: generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_rom.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_rom-impl_0_3f5rhj8/prim_rom.sv
Creating core file for primitive rom.
Core file written to /tmp/lowrisc_prim_rom-impl_0_3f5rhj8/prim_rom.core
Implementations for primitive and2: generic, xilinx_ultrascale, xilinx
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_and2.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_and2-impl_002vack24/prim_and2.sv
Creating core file for primitive and2.
Core file written to /tmp/lowrisc_prim_and2-impl_002vack24/prim_and2.core
Implementations for primitive buf: xilinx_ultrascale, xilinx, generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_buf.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_buf-impl_0nsjycvs5/prim_buf.sv
Creating core file for primitive buf.
Core file written to /tmp/lowrisc_prim_buf-impl_0nsjycvs5/prim_buf.core
Implementations for primitive clock_buf: xilinx, generic, xilinx_ultrascale
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_clock_buf.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_clock_buf-impl_00ib_98vx/prim_clock_buf.sv
Creating core file for primitive clock_buf.
Core file written to /tmp/lowrisc_prim_clock_buf-impl_00ib_98vx/prim_clock_buf.core
Implementations for primitive flash: generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_flash.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_flash-impl_03hkh4av5/prim_flash.sv
Creating core file for primitive flash.
Core file written to /tmp/lowrisc_prim_flash-impl_03hkh4av5/prim_flash.core
Implementations for primitive flop: xilinx_ultrascale, xilinx, generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_flop.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_flop-impl_0uvtnjx6a/prim_flop.sv
Creating core file for primitive flop.
Core file written to /tmp/lowrisc_prim_flop-impl_0uvtnjx6a/prim_flop.core
Implementations for primitive otp: generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_otp.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_otp-impl_0wpmms4p8/prim_otp.sv
Creating core file for primitive otp.
Core file written to /tmp/lowrisc_prim_otp-impl_0wpmms4p8/prim_otp.core
Implementations for primitive pad_attr: xilinx, generic, xilinx_ultrascale
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_pad_attr.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_pad_attr-impl_09n57rrhh/prim_pad_attr.sv
Creating core file for primitive pad_attr.
Core file written to /tmp/lowrisc_prim_pad_attr-impl_09n57rrhh/prim_pad_attr.core
Implementations for primitive pad_wrapper: generic, xilinx, xilinx_ultrascale
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_pad_wrapper.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_pad_wrapper-impl_0ivqot12y/prim_pad_wrapper.sv
Creating core file for primitive pad_wrapper.
Core file written to /tmp/lowrisc_prim_pad_wrapper-impl_0ivqot12y/prim_pad_wrapper.core
Implementations for primitive usb_diff_rx: generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_usb_diff_rx.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_usb_diff_rx-impl_03qn089sv/prim_usb_diff_rx.sv
Creating core file for primitive usb_diff_rx.
Core file written to /tmp/lowrisc_prim_usb_diff_rx-impl_03qn089sv/prim_usb_diff_rx.core
Implementations for primitive xnor2: xilinx_ultrascale, xilinx, generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_xnor2.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_xnor2-impl_0wjtw7c7v/prim_xnor2.sv
Creating core file for primitive xnor2.
Core file written to /tmp/lowrisc_prim_xnor2-impl_0wjtw7c7v/prim_xnor2.core
Implementations for primitive xor2: xilinx, xilinx_ultrascale, generic
Inspecting generic module /home/my_home/.cache/bazel/_bazel_my_home/a47cf925d4290aa5a4ac1f95f37830e8/sandbox/linux-sandbox/1103/execroot/_main/hw/ip/prim_generic/rtl/prim_generic_xor2.sv
No module named 'google_verible_verilog_syntax_py'
Verible parser failed, using regex fallback instead.
Creating SystemVerilog module for abstract primitive
Abstract primitive written to /tmp/lowrisc_prim_xor2-impl_0vb18bift/prim_xor2.sv
Creating core file for primitive xor2.
Core file written to /tmp/lowrisc_prim_xor2-impl_0vb18bift/prim_xor2.core

Target //hw:verilator_bin failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 25.826s, Critical Path: 23.00s
INFO: 7 processes: 7 internal.
ERROR: Build did NOT complete successfully

Run into the same issue as you.....
Anyone having any ideas how to fix? Thanks.
--vincent

Use the supported version of Verilator (4.210). Otherwise, the lint errors would need to be handled.

@a-will are you suggesting that versions of Verilator higher than 4.210 are not supported?

@a-will are you suggesting that versions of Verilator higher than 4.210 are not supported?

That kind of depends on your definition of "supported," but only 4.210 is run in CI and checked. It is the version that we currently ensure is kept working as PRs come in.
Other versions might work (and we'd like them to!), but fixing issues specific to them is unlikely to be prioritized over other tasks. The warnings here are probably cleanups that would be good to do, but there's always a lot of things to do.
In general, 4.x versions higher than 4.210 are probably fine, but 5.x brought in a lot of changes that are more likely to show incompatibilities.

@a-will, thanks for clarifying.
I was able to compile and use verilator 4.210 following the instructions listed in https://opentitan.org/book/doc/getting_started/setup_verilator.html
I get to the point where I see
INFO: Found 1 target...
Target //hw:verilator_bin up-to-date:
  bazel-bin/hw/build.verilator_real/sim-verilator/Vchip_sim_tb
INFO: Elapsed time: 989.354s, Critical Path: 988.38s
INFO: 3 processes: 2 internal, 1 linux-sandbox.
INFO: Build completed successfully, 3 total actions

However, the smoke test fails on a libclang issue as reported on #25522


Use layout effect

@moshfiqrony
@ahmmedabir9
@nazir021
@nomandhoni-cs
@shakib609
@ahnafyy
@nafistiham
@nutboltu
Hello Maintainers,
I've completed the translation of the useLayoutEffect hook page. Welcome to Roast my translation.

Thanks @mustaquenadim, You don't have to mention all the maintainers. Just open a PR with proper description is enough.

Is there anything I have to do from my side?


v2.6 merged

v2.6 master-ARGC branch is merged into the ARGC.
All the tests are passed
< Additional features of ARGC. >

Hybrid garbage collector (Reference Count + Mark & Sweep)
   (Patched all the sources for -objc-arc mode support)
Java compatible  process sequence.
Java compatible String.intern()
Auto exclusion of unreachable package & sources
    (cf. --not-include option and guava makefile)
Auto convert JUnit TestCase into XCTestCase for Xcode.
    (cf. -Xios-test option)
ObjectiveCType annotation.

And...

Optimized Translator speed
   InputSourceList cache
   JarFile cache
   Allow sources.jar to source-list
2.
More optimized AbstractStringBuilder.
Added and changed some files in android/frameworks/base/core/java/ (Not fully tested)

@googlebot I fixed it.

@googlebot I fixed it.

@googlebot I fixed it.


Add support for POST file uploads from in-memory buffers

This patch adds support for supplying a file's contents in a memory buffer, so that if you already have the file in memory, you don't need to write it out to a temporary file before you can upload it.
The buffer is specified as iterator ranges, so it works with both STL containers and C-style arrays, without making an extra copy of the data.

I'm pretty sure this is dangerous if the Iterator is anything other than a char*. The implicit assumption being made here is that the data is contiguous in memory, which won't necessarily be true for lots of STL containers (think things like std::list).
I think the only safe STL containers here are likely std::vector, std::array, and std::string.
See e.g. http://think-async.com/Asio/asio-1.10.6/doc/asio/reference/buffer.html

Hmm good point.  Any suggestions how to restrict it to a contiguous type, while allowing both STL containers and raw pointers to be used?  Preferably without a hundred overloaded functions!

@adam-nielsen I think there will be a concept for this in C++17, I don't know whether there is an enable_if based way

Merged, thanks @adam-nielsen!!


Support for lidarr

Hi,
I was under the impression that adding in lidarr like this would just work
  lidarr:
    image: ghcr.io/thijmengthn/swaparr:latest
    container_name: swaparr-lidarr
    restart: unless-stopped
    environment:
      - BASEURL=http://localhost:8686/lidarr/ # IP or FQDN           (Required)
      - APIKEY=reallylongwordwithnumbers           # Sonarr API Key       (Required)
      - PLATFORM=lidarr               # "radarr" or "sonarr" (Optional) default: radarr
      - TIME_THRESHOLD=2h             # 1d, 6h, 30m, etc..   (Optional) default: 2h
      - SIZE_THRESHOLD=25GB           # 1TB, 1GB, 1MB, etc.. (Optional) default: 25GB
      - CHECK_INTERVAL=10m            # 1d, 6h, 30m, etc..   (Optional) default: 10m
      - STRIKE_THRESHOLD=3            # Positive number      (Optional) default: 3
      - AGGRESSIVE_STRIKES=true      # Boolean              (Optional) default: false

But it doesn't so I'm assuming that i need to put in this feature request
error message is :
swaparr-lidarr    |  ─ FATAL
swaparr-lidarr    | ╭─╮ The provided "APIKEY" is not valid.
swaparr-lidarr    | ╰─╯ Obtain the lidarr API key in Settings > General > API Key

thanks in advance

Hi @kysersoze81 👋
Well, it should - though I haven't been able to test it much since I don't have Lidarr running.
I'll investigate to see if I can resolve the problem.
Btw, your BASEURL ends in /lidarr, that could be the issue as well.
You'll hear from me within a day or two.
^ Thijmen

Nevermind i see the formatting has changed . ill redo all the arrs and confirm that they are all working

The changes are backwards compatible, so that really shouldn't be an issue - please do let me know if that resolves it.
^ Thijmen

Hi Thijmen,
I removed the base URL's for all my containers (7 in total)and changed the environment variables to the new version and everything is working now. i have a second container for Radarr and renaming it in the label and on the title worked fine as well.
thanks for your quick reply and you can close this off

Oh, that's good to hear!
Sorry that the backwards compatibility didn't work out as intended.
I'll close this issue.
Have a nice day!
^ Thijmen


Add Global Social Chain (GSC)

Currency name: Global Social Chain
Symbol: GSC
Website: https://www.gsc.social/
Logo (PNG): https://camo.githubusercontent.com/8493f505fc8622e81e92b531e6ab460543db4ba2/68747470733a2f2f692e6c6f6c692e6e65742f323031382f30362f31392f356232393061613038383566312e706e67

notes: at the time of writing i just found the PNG file. and i cant do tracing image to svg format. currently im requesting svg format to their admins . if there is  anyone can do the tracing it will be great appreciation.

logo_traced-01.zip
i just ask our designer to trace this png to svg. please add into repo.
thanks


[Tests] Skip LocalTest if test directory is not available

@Herzult Changed basing on your feedback.


PHOENIX-6193 PHOENIX-6151 slows down shading

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 11s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ master Compile Tests _

-1 :x:
mvninstall
47m 35s
root in master failed.

+1 :green_heart:
compile
0m 34s
master passed

+1 :green_heart:
javadoc
0m 13s
master passed

_ Patch Compile Tests _

-1 :x:
mvninstall
15m 19s
root in the patch failed.

+1 :green_heart:
compile
0m 27s
the patch passed

+1 :green_heart:
javac
0m 27s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  1s
The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
0m 11s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
12m  7s
phoenix-client in the patch passed.

+1 :green_heart:
asflicense
0m 11s
The patch does not generate ASF License warnings.

78m 26s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/phoenix/pull/925

Optional Tests
dupname asflicense javac javadoc unit xml compile

uname
Linux b5e26355b6b7 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev/phoenix-personality.sh

git revision
master / 1784848

Default Java
Private Build-1.8.0_242-8u242-b08-0ubuntu3~16.04-b08

mvninstall
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/1/artifact/yetus-general-check/output/branch-mvninstall-root.txt

mvninstall
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/1/artifact/yetus-general-check/output/patch-mvninstall-root.txt

Test Results
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/1/testReport/

Max. process+thread count
63 (vs. ulimit of 30000)

modules
C: phoenix-client U: phoenix-client

Console output
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/1/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

I'll try this out today.

Faster, about 500KB/s, but still take a long time to build the two 150MB jars.
Can we build client and client-embedded in parallel?

I've re-run the build with warm maven caches:
Pre-6151:
[INFO] Phoenix Client ..................................... SUCCESS [02:20 min]
With this patch:
[INFO] Phoenix Client ..................................... SUCCESS [05:10 min]
So we're still about twice as slow as the original shading setup. Part of that is probably simply that we are shading more stuff, but using excludes probably also contributes.
Putting the two client JARs in different modules is certainly possible, however I did not have much luck running the build in multiple threads. The test parameters (numITCount) are usually tuned to fully use the test machine, and -T will cause a lot of test failures due to resource exhaustion. (and if you are on a very large machine, you're probably still better off increasing numITCount when running the full test suite)
Since we do not actually test the shaded artifacts, there is not much point in building them in Jenkins, and they are not useful 95% percent of the time during local development. We could shave off 10 minutes from the CI builds by not building the shaded artifacts at all. Yetus sets some default profile/property that we could re-use for this, and of course this could also be used locally.
For local development builds that aren't deployed to a real cluster I usually just use:
mvn clean package -DskipTests -am -pl phoenix-core :
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Apache Phoenix 5.1.0-SNAPSHOT:
[INFO]
[INFO] Phoenix Hbase 2.1.6 compatibility .................. SUCCESS [  4.551 s]
[INFO] Apache Phoenix ..................................... SUCCESS [  1.355 s]
[INFO] Phoenix Core ....................................... SUCCESS [ 27.730 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  34.456 s

Perhaps we can have a maven option to not build the -embedded jar.

The new patch implements both of your suggestions, @lhofhansl .
Note that this changes the embedded client maven coordinates.
At the same time, the new module structure should make adding new client variants easier.(for PHOENIX-6144, specifically)

Awesome!
Did a skim... Looks great. And I like the structure for adding new clients.
I'll take a closer look tomorrow.

Wait... Looks like it's still taking a very long time. (The previous run wasn't finished... My mistake)

Sorry for the noise  - it's a bit early for me in seems. Now assembly fails for me. I'll come back when I fully tested this.

I've rebased the patch, as we had some (unrelated) build breaking bugs in master, that @virajjasani has found a fixed. @lhofhansl.
It builds fine now.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/2/console in case of problems.

When I do git apply with the patch I see that we still have the old, SLOW, exclude patterns.
Might be a mistake about how I apply the patch. But let's double check.

There are two patches, and github only exports the second, I guess.

I've squashed them.

git am did it. Sigh.

Yeah. Looks good now.

Hmm. Looks like Yetus cannot correctly handle PRs that consist of more than one patch, even when working directly from GitHub.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ master Compile Tests _

+0 :ok:
mvndep
3m 38s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
33m 36s
master passed

+1 :green_heart:
compile
1m 19s
master passed

+1 :green_heart:
javadoc
1m 28s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
18m  8s
the patch passed

+1 :green_heart:
compile
1m 16s
the patch passed

+1 :green_heart:
javac
1m 16s
the patch passed

+1 :green_heart:
shellcheck
0m  1s
There were no new shellcheck issues.

+1 :green_heart:
shelldocs
0m  1s
There were no new shelldocs issues.

-1 :x:
whitespace
0m  0s
The patch has 1 line(s) that end in whitespace. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
xml
0m  9s
The patch has no ill-formed XML file.

-1 :x:
javadoc
0m 10s
phoenix-assembly in the patch failed.

_ Other Tests _

-1 :x:
unit
99m 22s
root in the patch failed.

-1 :x:
asflicense
1m 52s
The patch generated 8 ASF License warnings.

166m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/phoenix/pull/925

Optional Tests
dupname asflicense shellcheck shelldocs javac javadoc unit xml compile

uname
Linux d93ab81a4843 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev/phoenix-personality.sh

git revision
master / 5b58d9b

Default Java
Private Build-1.8.0_242-8u242-b08-0ubuntu3~16.04-b08

whitespace
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/2/artifact/yetus-general-check/output/whitespace-eol.txt

javadoc
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/2/artifact/yetus-general-check/output/patch-javadoc-phoenix-assembly.txt

unit
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/2/artifact/yetus-general-check/output/patch-unit-root.txt

Test Results
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/2/testReport/

asflicense
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/2/artifact/yetus-general-check/output/patch-asflicense-problems.txt

Max. process+thread count
6701 (vs. ulimit of 30000)

modules
C: phoenix-client-parent/phoenix-client phoenix-assembly phoenix-client-parent/phoenix-client-embedded . phoenix-client phoenix-client-parent U: .

Console output
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-PreCommit-GitHub-PR/job/PR-925/2/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.7.0

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


Improve LinearFunction API

During TypeScript porting with @jbphet, we saw that TypeScript was confused by our usage of LinearFunction.  We say it is a @constructor and invoke it with new but we return a different function from the constructor.  This causes type errors in TypeScript.  We found things get better if we remove @constructor and new.  We may also want to return a rich object with "evaluate" and "inverse" methods, or rename it to createLinearFunction.

I'm planning to turn LinearFunction into a class with an evaluate method.  It will be instantiated with new.  This will match up with other interfaces we use such as Transform1 and PiecewiseLinearFunction.  There are around 70+ usages of LinearFunction, so they will need to all be updated.

Everything is passing aqua locally, I think this is ready for commit.

I wasn't sure who to ask for review, so I ran
_.sample('JG, JB, JO, CK, SR, MK, CM'.split(' '))
'JG,'

@jessegreenberg can you please review?  Close if all is well.

On second thought, I noticed the original author of LinearFunction was @pixelzoom, so perhaps @pixelzoom should review.

The proposed solution sounds great to me. I've always hated the original implementation - which was a consensus as I recall, to make call sites less verbose.

Thanks, closing.

Upon reflection, it is unclear whether @pixelzoom reviewed the implementation or the proposal only.  @pixelzoom can you clarify?  Please close if all is well.

Implementation looks good, closing.


Can't resolve 'date-fns/locale/en-US' in eact-date-range

Its time to update date-fns
Date range is throughing error because of date-fns
Can't resolve 'date-fns/locale/en-US' in '\node_modules\react-date-range\dist\components\Calendar'

Hi, its answered here. I'm closing this issue.

What would be the next troubleshooting step when encountering this error if date-fns is already installed?

It would appear that var _enUS = _interopRequireDefault(require("date-fns/locale/en-US")); is not valid, as the current form of date-fns only has /locale/en, not /locale/en-US.


Runtime performance guidelines

ML techniques are understandably pretty heavy to run, and even these test examples put some strain on the underpowered computer I used for package evaluation. I think it would be really helpful for the user to have a general understanding of the expected runtime and resource requirements for this tool with realistic dataset sizes. Does the user need this installed on an academic HPC or cloud ec2/etc. to get it to run? How big a dataset/complex a model space can it handle? These are the kinds of practical questions that I think could really help a potential user.

I've added runtime performance guidelines in the vignette. I've also added default learners for each parameter that are nonparametric but also run pretty quickly. Install and running all the tests will still take a while but for a standard dataset this should run on a modern local machine within a couple hours depending the dimensions and number of folds chosen. Proc time is given in each example so users can see how long it runs on some simulated data and real world type synthetic data.

Thank you for including this, I think it helps a lot.


Are there any ways to get QK scores from attention?

Hi!
I'm wondering if there is a way to get attention scores from the engine in TRT-LLM? Are there any plans to make it available?
Thank you!

Hi @ttim , TRT-LLM does not support returning attention scores.
In addition, TRT-LLM by default uses fused MHA, which avoids writing the attention scores to global memory. This improves computation efficiency and reduces memory consumption. Returning attention scores significantly damages these features. Currently, we don't have any plans for returning attention scores.

@syuoni got it, thanks for the reply!


Publish to VSX-Registry

All VScode users that use a forked VScode version (e.g. Gitpod) can only use Extensions from the VSX-registry.
Could you please upload your extension also to VSX?
There is a guide: https://github.com/eclipse/openvsx/wiki/Publishing-Extensions
And there is also a Github Action that uploads to MS Marketplace and VSX-registry at the same time: https://github.com/HaaLeo/publish-vscode-extension#readme

Now available, in open vsx: https://open-vsx.org/extension/RafaelMartinez/svelte-preview


Placeholder not going away (dashboard)

Describe the bug
Placeholder elements won't leave domain table, if user does not own domains
To Reproduce

Create an account
Go to the dashboard

Expected behavior
Placeholders should disappear

Fixed in Dev (canary) due to new error handling


WithApplicationComponents causing java.lang.NoSuchMethodError

I'm using play 2.6.1 and scalatestplus-play 3.1.0
My test code looks roughly like
27: class CallbackControllerTest extends PlaySpec with OneAppPerSuiteWithComponents {
...
38: override def components: BuiltInComponentsFromContext = new BuiltInComponentsFromContext(context) with NoHttpFiltersComponents {
39:     import play.api.routing.Router
40:     lazy val router: Router = Router.empty
41:  }

At runtime I get
[info] com.ebay.n.bot.controllers.CallbackControllerTest *** ABORTED ***
[info]   java.lang.NoSuchMethodError: play.api.ApplicationLoader$.createContext$default$5()Lplay/api/inject/DefaultApplicationLifecycle;
[info]   at org.scalatestplus.play.components.WithApplicationComponents$class.context(WithApplicationComponents.scala:37)
[info]   at controllers.CallbackControllerTest.context$lzycompute(CallbackControllerTest.scala:27)
[info]   at controllers.CallbackControllerTest.context(CallbackControllerTest.scala:27)
[info]   at controllers.CallbackControllerTest$$anon$2.<init>(CallbackControllerTest.scala:38)
[info]   at controllers.CallbackControllerTest.components(CallbackControllerTest.scala:38)
[info]   at controllers.CallbackControllerTest.components(CallbackControllerTest.scala:27)
[info]   at org.scalatestplus.play.components.WithApplicationComponents$class.newApplication(WithApplicationComponents.scala:30)
[info]   at controllers.CallbackControllerTest.newApplication(CallbackControllerTest.scala:27)
[info]   at org.scalatestplus.play.components.OneAppPerSuiteWithComponents$class.fakeApplication(OneAppPerSuiteWithComponents.scala:141)
[info]   at controllers.CallbackControllerTest.fakeApplication(CallbackControllerTest.scala:27)

Am I doing something wrong? My goal is to obtain an instance of ControllerComponents so that I may test my compile-time DI Controllers.

I would suggest to first check the dependencies using dependencyTree in SBT, guessing there are version conflicts for some Play libs.

@jsw can you confirm that using ScalaTest+Play 3.1.1 and Play 2.6.2 fixes the problem?

@marcospereira Confirmed. Thanks for the fix and update. 👍
BTW: In the meantime, my workaround was to use the following, which is also more succinct. I'm not sure what the pros/cons are otherwise.
class ExampleControllerTest extends PlaySpec with StubControllerComponentsFactory {
...
  new ExampleController(stubControllerComponents(playBodyParsers = stubPlayBodyParsers(app.materializer)))


Inconsistent data source system vs application - ARC GIS

The data displayed in the application is inconsistent with the system specified as the source.
To Reproduce
Steps to reproduce the behavior:

Go to 'https://www.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6'
Scroll down to widgets: Global Cases, Global Deaths
See error - the value is different from the value displayed in your application

Expected behavior
the data should not be misleading, or should contain information about the last refresh time
Desktop (please complete the following information):

OS: ios
Browser Chrome
Version 87.0.4280.141

Hi @maagdalenakaczynska,
Thanks for recognizing and opening the issues with regard to inconsistent data

Hi @maagdalenakaczynska,
Thanks for recognizing and opening the issues with regard to inconsistent data


Allow state changes bot actions processing

This is a proposition following the discussion in #291
We still ignore bot events except state changes, because the integration never updates PR states by itself, triggering no events, and we still avoid infinite event loops.

@saquibkhan @rachellerathbone @atrigueiro
this resolves:

https://github.com/integrations/jira/pull/403
https://github.com/integrations/jira/issues/394

that issue has a P1 label (meaning prio 1 bug?) and we are waiting for a solution desperately.
at the time the issue was parked because of a team transition.
recently i've seen new activity by the three of you so i'm assuming you guys are the new team?
any info regarding this issue?
Thanks!

Hi @Raul6469 and @InteNs,
We've indeed started the team transition and are ramping up with the integration now. This issue is one of our priorities and it's being actively looked at right now. We'll keep you posted as soon as the team comes up with a solution for this behavior. Thanks.

Closing this PR in favour of https://github.com/integrations/jira/pull/437


Url params

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 44 (0.0%)  changed or added relevant lines in 9 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.2%) to 29.618%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/components/Pages/DictionaryPage/index.ts
0
1
0.0%

src/components/Router/Router.tsx
0
1
0.0%

src/utils/validateLang/index.ts
0
1
0.0%

src/components/Pages/DictionaryPage/DictionaryPage.tsx
0
2
0.0%

src/server/validateData.ts
0
3
0.0%

src/utils/validateLang/validateLang.ts
0
5
0.0%

src/services/dictionary.ts
0
9
0.0%

src/index.tsx
0
10
0.0%

src/middlewares/urlParamsMiddleware.ts
0
12
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/index.tsx
1
0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
1318

Relevant Lines:
5443

💛  - Coveralls


My english cartoons default to russian and other issues

Hello again @lukasf
Are you sure this is the best way of determining the default audio stream in a file?

auto audioStreamIndex = av_find_best_stream(avFormatCtx, AVMEDIA_TYPE_AUDIO, -1, -1, NULL, 0);
...
bool isDefault = index == audioStreamIndex;

Shouldn't we just default to stream 0?

Bonus issue: when I switch the audio streams, video stops playing and starts buffering samples.

Most file formats have a "default" flag for streams. The first stream is not neccessarily the default stream. Only if no "default" flag is found, the method will take the first stream. So yes, I do think that this is the correct way to do it.
It looks like we get a "OnStarting" call after a stream switch, that is why there is a short interruption (seek operation plus flush of buffers). We could try to skip that seek in case a SwitchStream has just happened. But we'd have to be sure to not accidentially skip other seek requests.

Oh well, looks like my cartoon shop likes russian alot then 📦
But still we have the 2nd problem, video stops after switching streams. Can you reproduce the sample or should I send over some cartoons?^^


XFA - Handle correctly nested containers with lr-tb layout (bug 1718670)

/botio test

There is a regression in firefox-xfa_issue13500-page2.

I'm sad here because I'd say that this "yellow pages" on 2 lines is not so bad...
The parent container as a layout lr-tb and the field "yellow..." has no dimensions. And in this case, we have enough space to put the field at the end of the line.

I'm OK with accepting the regression, @brendandahl wdyt?

I think it's better to fix: we could have strange things because of that.
My idea is when it's possible always "prefer" a non-broken text.

/botio test

/botio makeref


defaultSizes behavior combined with minSize and  proportionalLayout

Hey @johnwalley ,
Thanks for providing us with Allotment.  It is great!
So I think I might be confused at how to correctly use defaultSizes.  For my use-case I have two panes (left, right).  I expect the one on the left to always be larger than the one on the right [500, 365].   Below is my impl for the Allotment that contains those two panes.
This seems to work correctly unless my parent container (365px) is smaller than the required "allotment" (365+365) due to minSize.  At this point both left and right panes are resized to 365 and the right pane seems to take priority pushing the left pane out of view.  Where I would expect the left to take priority due to defaultSizes.
Allotment.onChange sizing:
size (2) [1043, 762] <- resize full screen (parent 1043px)
size (2) [365, 365] <- resize parent to 365px.
 <Allotment
            className="dash-allotment"
            onChange={(size: number[]) => {
                console.log('size', size);
            }}
            proportionalLayout
            defaultSizes={[500, 365]}
            minSize={365}
        >
<leftPane/>
<rightPane/>
</Allotment>

My question is should defaultSizes ratio take priority and resize proportionally when the size of the parent is not large enough to account provided panes within?  I've added  proportionalLayout but seems to have no effect.  When I reduce minSize to 150 the layout seems to behave again.
Once again thanks for the help and I appreciate any advice/feedback on what I might be doing incorrect,
Michael

Might be related to : https://github.com/johnwalley/allotment/issues/99

Hi @michaelbdavid. Thanks for submitting this, just wanted to say I will get around to reading this and that I'm not ignoring you!


[feat] WebArena benchmark, MiniWoB++ benchmark and related arch changes

Major changes:

Arch changes to support eval with browsergym infrastructure inside the project
Incorporate WebArena benchmark code
Incorporate MiniWoB++ benchmark code

Eval Results:
All tested on BrowsingAgent V1.0
MiniWoB++, 125 tasks (3 runs due to random init task)
GPT4o: 0.384, 0.416, 0.424, avg: 0.408
GPT3.5: 0.288, 0.256, 0.272, avg: 0.272
WebArena, 812 tasks (high cost, single run due to fixed task)
GPT4o: 0.1478
GPT3.5: 0.0517

Also related: I wonder if we should allow configurable agents somewhere in the codebase? Now we can configure LLM configs, but not agents. It's nice to have configurable options passed the Agent class to control the prompts and stuff.

For some reason I cannot directly push to your branch. Could you please run

ONLY_TEST_AGENT=BrowsingAgent ./tests/integration/regenerate.sh

to fix the test, now that the prompt has been updated?

@li-boxuan fixed, and should be in a mergeable state.


Support different types of prediction

Currently, vetiver supports the predict method when handling models. In other use cases, it maybe important to be able to use predict_proba or predict_log_proba.

On the R side, we handle this by passing in an argument about the type of predictions. It would look something like this:
pr() %>% vetiver_pr_predict(v, type = "prob")
## or
pr() %>% vetiver_pr_predict(v, type = "quantile")
## and so on

Hi there,
Has there been any progress on this?
I am particulalry interested in predict_proba, is there a work around that you can direct me to meanwhile?
Many thanks

Hi there 👋 -- there has not been worked on yet (for context: nowadays I am spending most of my time in this repository -> https://github.com/posit-dev/positron, but am still around to do maintenance and features as needed :D)
For predict_proba, there are a few current workarounds. The first would be would be able to add another endpoint with VetiverAPI.vetiver_post if you wanted to have both the /predict and /predict_proba options. In this case, you would create a function that returns the predict_proba values and then add it to the API. Another option is to create a custom handler for this prediction type, where the handler_predict would return the output of predict_proba.
Let me know if you run into any troubles or if you have any followup questions!


Must the CI/CD modify a running database on production/dev/etc environment?

https://github.com/prisma/docs/blob/334d8e61c7073b986d7a7886d274b6887f1b8ad5/content/300-guides/200-deployment/550-deploy-database-changes-with-prisma-migrate.mdx#L9
I think that this is a bad advice, because the database migrations must be done on runtime. If you use the build time for this:
1 - The database must be public available to the agent of the CI/CD
or 2 - If not public, must be done with a VPN
or 3 - The CI/CD agent must be deployed where can access to the database
or 4 - I think that the build process of an app can't modify in any aspect the deployed environment.

I think that must specify that is on Delivery time, not include the CI part.

Hey Luis 👋 thanks for opeining this issue! I'm aware that the issue has been around for a while but we're only now getting to a major cleanup of the docs repo, so apologies for the delay 🙏

I think that this is a bad advice, because the database migrations must be done on runtime.

I just double-checked internally and our Engineering team and it doesn't seem like we want to recommend migrations as a best practice. Here's the reasoning from one of our engineers:

It's unclear what the app should do if the migrations fail. Does it start anyway or fail to start, causing an outage?
What happens if multiple app versions are active at once with different stages of schema evolution?
Separating into CI forces you to consider that the app must be backwards or forwards compatible since the migrations must be run as a separate step before or after app deployment. This is critical in the event migrations fail for any reason and gives you more confidence in how you can safely roll back. Coupling it with a runtime deployment usually leads to devs assuming that everything will work perfectly and they'll never need to roll back their app.

I'm closing this issue, but please feel free to open other issues in the future if you notice anything that can be improved in the Prisma docs 🙏


Not working with 7.13.2

Hi,

I´ve installed Elastic 7.13.2, Kibana 7.13.2 and enhanced table and enhanced-table-1.13.0_7.13.2.zip on it, from the scratch
Load some sample data
When creating a new viz (table based or aggregation based) got an error:

@http://localhost:5601/40943/bundles/plugin/enhancedTable/1.13.0/enhancedTable.plugin.js:1754:108
asyncFunctionResume@[native code]
@[native code]
promiseReactionJobWithoutPromise@[native code]

Surprising.
Could you fully remove your browser cache (using Ctrl+Shift+Suppr) and then fully reload page (using Shift+F5) and check if you reproduce the error?

I´ve tried removing cache, in developer console with "Disable cahce" (that´s for Chromium and Chrome), and manually removing local and session storage. I´ve tried with Safari an Firefox too ;-(
All this browser cames to the same erorr, with a little diffrent verbose messages, but at the end all say the same:
TypeError: Object(...) is not a function     at handleCourierRequest (http://localhost:5601/40943/bundles/plugin/enhancedTable/1.13.0/enhancedTable.plugin.js:1754:108)     at async enhancedTableRequestHandler (http://localhost:5601/40943/bundles/plugin/enhancedTable/1.13.0/enhancedTable.plugin.js:1487:20)     at async fn (http://localhost:5601/40943/bundles/plugin/enhancedTable/1.13.0/enhancedTable.plugin.js:1943:13)     at async Execution.invokeFunction (http://localhost:5601/40943/bundles/plugin/expressions/kibana/expressions.plugin.js:1:53783)     at async Execution.invokeChain (http://localhost:5601/40943/bundles/plugin/expressions/kibana/expressions.plugin.js:1:52867)

Something wrong on my side... I don´t know what, but I´ve reinstalled from scratch and now works.
Thank you.

Happy to know that it finally works!


Navigation menu (beta)

I like the new menu, especially the fact that from now there is one menu and not two. But I would change something.

In the desktop (non-mobile) version, the menu could expand automatically when hovering and hide when not hovering menu. https://stackoverflow.com/questions/4811807/hidden-sidebar-that-shows-up-on-hover

I would remove this small hamburger menu icon from the logo. Instead, when you expand the menu next to the logo, the text "Homebridge" would appear. In the mobile version, it would be permanent because at the moment there is a long empty bar (only logo).

In mobile view you can add Hamburger menu icon on the right. Currently in the mobile version, clicking on the bar opens the menu, not only on the logo.

In mobile view, Clicking outside the menu should close the menu.

So to sum up:

In the mobile version, there should be Logo (without small hamburger icon) + the text Homebridge and on the right the Hamburger menu icon. Menu should open / close on click on bar and close on click outside menu
In the desktop version, the sidebar should open on hover (and close on not hover) and text Homebridge should appear next to the logo.

Example:
https://github.com/user-attachments/assets/12e68bfc-6a04-4c09-b53a-ca7635a8b749
Code:
// with timeout because element needs to be loaded
setTimeout(function(){

  // Get a reference to the element that you want to work with
  var element = document.querySelector(".sidebar");

  $(function() {
    $('#sidebar').hover(function() {
      element.classList.add("expanded");
    }, function() {
      element.classList.remove("expanded");
    }).trigger('mouseleave');
  });

}, 2000);

To close menu if click outside:
// with timeout because element needs to be loaded
setTimeout(function() {

  // First we check if you support touch, otherwise it's click:
  let touchEvent = 'ontouchstart' in window ? 'touchstart' : 'click';

  const element = document.querySelector(".sidebar");

  document.addEventListener(touchEvent, (event) => {
    if (!element.contains(event.target)) {
      console.log("Clicked Outside");
      document.querySelector(".sidebar").classList.remove("expanded");
      document.querySelector(".content").classList.remove("sidebarExpanded");
    }
  });

}, 500);


fix(server) Allows for multiple simulatneous MJPG clients

This allows for multiple MJPG clients connected at the same time.
Known Limitations
This only fixed the MJPG stream, the bounding boxes and other client updates still need to be fixed for full multi-client capabilities.

nice !

I'm happy this fix turned out simpler than expected. I could test this locally with streaming YoloSimulation on Firefox and Safari. But it should work out with YoloDarknet as well.


bug: .xcodeproj doesn't contain Team field

Type: bug
Platform: ios 8 webview
To deploy my app, I need to open the .xcodeproj and chose from the dropdown my deployment team or else xcodebuild will just hang.

It seems that by doing this in the UI it writes out a TargetAttributes dictionary in the PBXProject section right after LastUpgradeCheck = 510. Can you do this automatically when you make the project please?

Greetings @ptarjan!
My sensors indicate that you need to update your issue through our custom issue form. We are now requiring all issues to be submitted this way, to ensure that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
I will have no choice but to close this issue if it is not resubmitted through the form. Please fill out the rest of the form, so that I may use my friendly robot powers to assist you.
Thank you!

Hey @ptarjan, could you tell me a bit more about your account setup? Are you part of multiple teams? Are they a mix of personal and enterprise?

@perrygovier I have a single enterprise team.
While I was investigating this, I saw that ionic build --release --device ios actually made a .ipa in the directory, but if I did
xcodebuild -project "$IOS_DIR/${APP_NAME}.xcodeproj" -scheme "$APP_NAME" -configuration Release clean archive -archivePath "$APP_DIR/$APP_NAME"
-rm "$DEST_DIR/$APP_NAME.ipa"
-xcodebuild -exportArchive -exportFormat ipa -archivePath "$APP_DIR/${APP_NAME}.xcarchive" -exportPath "$DEST_DIR/$APP_NAME.ipa" -exportProvisioningProfile "$APP_NAME"

then it would just hang.
Is the expected way to push an ionic app to do cordova build --release --device ios and then find the .ipa in build/device all signed correctly?

Thanks for the info. Not a framework issue per say so going to close.


Crash when having a dictionary property (ArgumentDecoder.swift:89: Fatal error)

Swift argument parser crashes when adding a dictionary property - see attached reproducer.
ArgumentParser version: 1.2.2 (reproduced with main too)
Swift version: swift-driver version: 1.62.15 Apple Swift version 5.7.1 (swiftlang-<IP_ADDRESS>.3 clang-14<IP_ADDRESS>) Target: arm64-apple-macosx13.0
Checklist

[x] If possible, I've reproduced the issue using the main branch of this package
[x] I've searched for existing GitHub issues

Steps to Reproduce
Unpack the attached reproducible project and run from command line with:
swift run swift-argument-parser-reproducer --command run
The complete code is simply:
import ArgumentParser

typealias BenchmarkIdentifier=Int

struct BenchmarkResult: Codable {
    var x:Int
}

@main
struct BenchmarkTool: AsyncParsableCommand {
    @Option(name: .long, help: "The command to perform")
    var command: String

    var benchmarkResults: [BenchmarkIdentifier: [BenchmarkResult]] = [:] // comment this out to not crash

    mutating func run() async throws {
    }
}

Expected behavior
hassila@ice ~/G/swift-argument-parser-reproducer> swift run swift-argument-parser-reproducer --command run
Building for debugging...
[3/3] Linking swift-argument-parser-reproducer
Build complete! (0.39s)
USAGE: benchmark-tool --command <command>

OPTIONS:
  --command <command>     The command to perform
  -h, --help              Show help information.

hassila@ice ~/G/swift-argument-parser-reproducer>

Actual behavior
hassila@ice ~/G/swift-argument-parser-reproducer> swift run swift-argument-parser-reproducer --command run
Building for debugging...
[47/47] Linking swift-argument-parser-reproducer
Build complete! (4.50s)
ArgumentParser/ArgumentDecoder.swift:89: Fatal error
fish: Job 1, 'swift run swift-argument-pars...' terminated by signal SIGTRAP (Trace or breakpoint trap)

swift-argument-parser-reproducer.zip

Can minimise even more actually the following also fails:
import ArgumentParser

@main
struct BenchmarkTool: AsyncParsableCommand {

    var benchmarkResults: [Int: Int] = [:] // comment this out to not crash

    mutating func run() async throws {
    }
}

The immediate proximate cause of the crash is the lack of an implementation of KeyedDecodingContainerProtocol.allKeys:
https://github.com/apple/swift-argument-parser/blob/main/Sources/ArgumentParser/Parsing/ArgumentDecoder.swift#L88-L90
As triggered by Dictionary's built-in Codable conformance:
https://github.com/apple/swift/blob/main/stdlib/public/core/Codable.swift#L5660
I'll see if I can open a PR to fix this, but the underlying concern to me is whether ArgumentParser could avoid interacting with properties not tagged with one of the parsable property wrappers altogether, or if it needs to be documented to avoid mixing parsable and non-parseable properties in a command. Dictionary's implementation of Codable hasn't changed in very long time, and neither has most of the ArgumentDecoder code - this appears to be a long-standing issue that no one noticed until now?

@gwynne Initial versions of ArgumentParser made it difficult to include non-flag/optional/argument properties in with the parsed ones in a ParsableCommand, but there's been improvement in that area. This should be working as @hassila describes, so a fix would be great!


MSVC: Add API to create EnvironmentInfo from a compiler

Why this is needed in principle: for any project building C++ on windows, it may be necessary to include additional DLLs from the "redist" folder. We can provide a function to do that, or we can create a generic function that will allow us to easily create an EnvironmentInfo that we can use to query about various MSVC information.
This is not necessarily the correct implementation of this function. If you have a better idea, I am open to it. But the requirement is that the function return an EnvironmentInfo with the same version number and architecture as the compiler (not necessarily the same installation).

Also, we need test coverage, but would like feedback first.

Actually it would probably be better to make EnvironmentInfo a property of the compiler through monkeypatching.

Closing for now.


allow an election immediately after start with checkquorum

port ectd https://github.com/coreos/etcd/pull/6286

LGTM

LGTM


When content-type with wildcards are sent via StreamBridge all the MessageConverters match even when they should not

Describe the issue
Given a custom MessageConverter, when a message is sent via StreamBridge with a generic mime type, the message converter is always called, even though the MessageConverter does not supports the mime type.
For example if the MessageConverter supports messages for application/bar. If a message is sent with the content-type application/*+json, the converter is called when it should not.
To Reproduce
Execute the following test:
@SpringBootTest(classes = MessageConverterTestConfig.class)
@EnableAutoConfiguration
class MessageConverterTest {

	@Autowired
	private StreamBridge streamBridge;

	@SpyBean
	private TestMessageConverter testMessageConverter;

	@Test
	void genericJsonMimeTypeShouldNotCallTestConverter() {
		streamBridge.send("output-out-0", "text-message", new MimeType("application", "*+json"));

		Mockito.verify(testMessageConverter, Mockito.never()).convertToInternal(Mockito.any(), Mockito.any(),
				Mockito.any());
	}

	@Configuration(proxyBeanMethods = false)
	@Import(TestChannelBinderConfiguration.class)
	static class MessageConverterTestConfig {

		@Bean
		public TestMessageConverter testMessageConverter() {
			return new TestMessageConverter();
		}

	}

	public static class TestMessageConverter extends AbstractMessageConverter {

		private static final MimeType DEFAULT_MIME_TYPE = new MimeType("application", "bar");

		public TestMessageConverter() {
			super(DEFAULT_MIME_TYPE);
		}

		@Override
		public Object convertFromInternal(Message<?> message, Class<?> targetClass,
				@Nullable Object conversionHint) {

			return message.getPayload().toString();
		}

		@Override
		public Object convertToInternal(Object payload, @Nullable MessageHeaders headers,
				@Nullable Object conversionHint) {

			Object ret = null;

			if(payload != null) {
				ret = payload.toString();
			}

			return ret;
		}

		/**
		 * {@inheritDoc}
		 */
		@Override
		protected boolean supports(Class<?> clazz) {
			return true;
		}

	}
}

Version of the framework
Spring Cloud Stream version: 3.1.0
Additional context
Note that in the the legacy annotation-based support it worked as expected.
I used this feature with org.springframework.cloud.schema.registry.avro.AvroSchemaRegistryClientMessageConverter. With this converter, the output content-type was set as application/*+avro and the converter changed the countent-type headers with the specific avro schema.

Did you notice that you set 'supports' to true?
protected boolean supports(Class<?> clazz) {
	return true;
}

Did you notice that you set 'supports' to true?
protected boolean supports(Class<?> clazz) {
	return true;
}

Yes, it is made on purpose in order to accept all the types. Note that org.springframework.cloud.schema.registry.avro.AvroSchemaRegistryClientMessageConverter does the same:
@Override
protected boolean supports(Class<?> clazz) {
    //we support all types
   return true;
}

About the methods you mentioned, I think the default implementations is correct for this use case:
protected boolean canConvertFrom(Message<?> message, Class<?> targetClass) {
    return (supports(targetClass) && supportsMimeType(message.getHeaders()));
}

protected boolean canConvertTo(Object payload, @Nullable MessageHeaders headers) {
    return (supports(payload.getClass()) && supportsMimeType(headers));
}

as they check whether the converter supports the mime type included as a header, (which should be false).
Investigating a bit more, I saw that when the mime type of the output message is not concrete, the class org.springframework.cloud.function.context.config.SmartCompositeMessageConverter is changing the header content-type for the one supported by the converter:
 @Override
@Nullable
public Message<?> toMessage(Object payload, @Nullable MessageHeaders headers) {
for (MessageConverter converter : getConverters()) {
	Object value = headers.get(MessageHeaders.CONTENT_TYPE).toString();
	String[] contentTypes = StringUtils.delimitedListToStringArray((String) value, ",");
	for (String contentType : contentTypes) {
		if (!MimeType.valueOf(contentType).isConcrete()) {
			List<MimeType> supportedMimeTypes = ((AbstractMessageConverter) converter).getSupportedMimeTypes();
			for (MimeType supportedMimeType : supportedMimeTypes) {
				MessageHeaderAccessor h = new MessageHeaderAccessor();
				h.copyHeaders(headers);
				h.setHeader(MessageHeaders.CONTENT_TYPE, supportedMimeType);
				Message<?> result = converter.toMessage(payload, h.getMessageHeaders());
				if (result != null) {
					return result;
				}
			}
		}
		else {
			(...)
		}
	}
}
return null;
}

The key lines are the following:
List<MimeType> supportedMimeTypes = ((AbstractMessageConverter) converter).getSupportedMimeTypes();
h.setHeader(MessageHeaders.CONTENT_TYPE, supportedMimeType);

It gets the converter supported mime types and sets them to the headers. That is why the converter ALWAYS supports the mime type, even when it should not.

Yes, it is made on purpose in order to accept all the types. Note that org.springframework.cloud.schema.registry.avro.AvroSchemaRegistryClientMessageConverter does the same:
@Override
protected boolean supports(Class<?> clazz) {
    //we support all types
   return true;
}

About the methods you mentioned, I think the default implementations is correct for this use case:
protected boolean canConvertFrom(Message<?> message, Class<?> targetClass) {
    return (supports(targetClass) && supportsMimeType(message.getHeaders()));
}

protected boolean canConvertTo(Object payload, @Nullable MessageHeaders headers) {
    return (supports(payload.getClass()) && supportsMimeType(headers));
}

as they check whether the converter supports the mime type included as a header, (which should be false).
Investigating a bit more, I saw that when the mime type of the output message is not concrete, the class org.springframework.cloud.function.context.config.SmartCompositeMessageConverter is changing the header content-type for the one supported by the converter:
 @Override
@Nullable
public Message<?> toMessage(Object payload, @Nullable MessageHeaders headers) {
for (MessageConverter converter : getConverters()) {
	Object value = headers.get(MessageHeaders.CONTENT_TYPE).toString();
	String[] contentTypes = StringUtils.delimitedListToStringArray((String) value, ",");
	for (String contentType : contentTypes) {
		if (!MimeType.valueOf(contentType).isConcrete()) {
			List<MimeType> supportedMimeTypes = ((AbstractMessageConverter) converter).getSupportedMimeTypes();
			for (MimeType supportedMimeType : supportedMimeTypes) {
				MessageHeaderAccessor h = new MessageHeaderAccessor();
				h.copyHeaders(headers);
				h.setHeader(MessageHeaders.CONTENT_TYPE, supportedMimeType);
				Message<?> result = converter.toMessage(payload, h.getMessageHeaders());
				if (result != null) {
					return result;
				}
			}
		}
		else {
			(...)
		}
	}
}
return null;
}

The key lines are the following:
List<MimeType> supportedMimeTypes = ((AbstractMessageConverter) converter).getSupportedMimeTypes();
h.setHeader(MessageHeaders.CONTENT_TYPE, supportedMimeType);

It gets the converter supported mime types and sets them to the headers. That is why the converter ALWAYS supports the mime type, even when it should not.

Correct, and that is on purpose as well. Basically the idea is, if content type is set to something like */* or application/* etc., then we try with any converter that says "yes". Now, the converter that said "yes" may still not be able to convert it, so we continue to iterate. Once a particular converter was able to convert, we stop iterating and use the content type of that converter as an output content type.
So, basically what I am trying to say is that the MessageConverter API accounts for various filtering method that would allow you to determine if this converter should even attempt to convert it. The supports method is really primitive way of saying yes/no, hence those other methods that I have suggested.
That said, I am going to assume that you still have an issue that I may not fully understand , so let me try something different.
You implemented custom converter. It was added at the top of the stack of existing MessageConverters, so it get's tested first. What do you want to accomplish given that you said . . .Yes, it is made on purpose in order to accept all the types.?

Correct, and that is on purpose as well. Basically the idea is, if content type is set to something like */* or application/* etc., then we try with any converter that says "yes". Now, the converter that said "yes" may still not be able to convert it, so we continue to iterate. Once a particular converter was able to convert, we stop iterating and use the content type of that converter as an output content type.
So, basically what I am trying to say is that the MessageConverter API accounts for various filtering method that would allow you to determine if this converter should even attempt to convert it. The supports method is really primitive way of saying yes/no, hence those other methods that I have suggested.
That said, I am going to assume that you still have an issue that I may not fully understand , so let me try something different.
You implemented custom converter. It was added at the top of the stack of existing MessageConverters, so it get's tested first. What do you want to accomplish given that you said . . .Yes, it is made on purpose in order to accept all the types.?

The issue arose when migrating an application from the legacy to functions. With the legacy mode it worked fine.
Basically we had two custom MessageConverter. They are similar to AvroSchemaRegistryClientMessageConverter but added some custom logic. An example of binding configuration is:
spring:
  cloud:
    stream:
      bindings:
        output:
          destination: topic1
          content-type: application/*+avro
        output2:
          destination: topic2
          content-type: application/*+non-registered-avro

So when a message is sent via output,  the content-type of the message would be application/*+avro, and when the message is sent via output2 the content-type would be application/*+non-registered-avro.  What cause that depending on the content-type of the message, one converter or the other is executed.
With functions, as we mentioned before, if the content type of the message contains a * the converter always says "yes", so the first converter is always executed although the content-type of the message does not match with the converter's supported mime types.

The issue arose when migrating an application from the legacy to functions. With the legacy mode it worked fine.
Basically we had two custom MessageConverter. They are similar to AvroSchemaRegistryClientMessageConverter but added some custom logic. An example of binding configuration is:
spring:
  cloud:
    stream:
      bindings:
        output:
          destination: topic1
          content-type: application/*+avro
        output2:
          destination: topic2
          content-type: application/*+non-registered-avro

So when a message is sent via output,  the content-type of the message would be application/*+avro, and when the message is sent via output2 the content-type would be application/*+non-registered-avro.  What cause that depending on the content-type of the message, one converter or the other is executed.
With functions, as we mentioned before, if the content type of the message contains a * the converter always says "yes", so the first converter is always executed although the content-type of the message does not match with the converter's supported mime types.

Hi @olegz.
I agree with @JordiMartinezVicent. If you modify the content-type header before calling converter.toMessage, the converter gets that modified content-type and always "say yes".
Maybe the fix is just to modify the content-type header only after the converter really converted the message?
We're waiting for this fix too. Any plans on this?
Thanks in advance!

So, this one is being fixed in two places - https://github.com/spring-cloud/spring-cloud-function/issues/773
Will push stream fix shortly

Snapshots for 3.2 and 3.1.6 are available


Couldn't count generated lines for private repo

I know there's mention of this:

Optional: To load the .gitattributes for private repos, you need to enter a GitHub personal access token.

But the thing is... I don't need nor use .gitattributes. For me the basic functionality is just enough.
Currently it just hangs into this state infinitely:

IMO for simple cases without .gitattributes, – extension has all the info just on the page: token shouldn't be needed.
I just tried to add github token though, and it suddenly worked. But it shouldn't require it.
I think it is a minor issue yet important enough to mention.

The label could be better.

Optional: To show a generated count on private repos, you need to enter a GitHub PAT. Without a token, this extension is unable to make API calls required to recalculate the diff.

Loading the gitattributes file is only one of the API calls made using the token. The others involve loading information about the current PR or commits, and PAGINATING through all files for very large diffs.
When I started working on this extension originally, I attempted to find the required information from the page, but when lots of files change, GitHub does not load everything all at once, so some of the line counts I need are missing.
Using the API solves this problem and one other big one: ongoing maintenance. I don't want to fix the extension every time GitHub changes their UI and potentially breaks the query selectors used to find the line counts.

I'll fix the issue with the spinner not going away and update the token's label, but I'm not going to attempt to parse the page to recalculate the diff.

For future reference, here is the code that uses the PAT to load the current commit, the gitattributes file, and recalculate the diff.
https://github.com/aklinker1/github-better-line-counts/blob/aff927f3c3536c6a27af47b1c6be2362005ef5ed/src/utils/github/service.ts#L113


Consider writing to ByteArrayInputStream instead of temporary file

The reason to write to a file is the reduced memory consumption.
However, the zip file is usually very much smaller than the amount of RAM you would need to open the entire workbook with POI.
So if you gave the option not to write the temp file but instead save it into RAM as a byte array, you would have more memory usage than today, but still much less than standard POI.
That, of course, should be optional and would allow working in environments where writing files is forbidden.

Reposted as https://github.com/pjfanning/excel-streaming-reader/issues/30 since I realized that's the alive version of this


Create Demo developerforce2020

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

This seems like nonsense


Scanner: Do not try so scan projects and packages with the same id

It can happen that the same identifier appears for a project and for a
package. Possible reasons for this are that the package manager
implementation does not detect that a dependency is also a project and
creates a package instance for it, or that the same identifier appears
for different package managers, for example NPM and Yarn.
If those duplicates are passed to the PostgresStorage it fails because
it expects identifiers to be unique.
To fix this make sure to not pass duplicate identifiers to the scanner.
If duplicates are found prefer the project over the package, because it
has likely more accurate metadata.
Other means to further improve this in future are:

Change the Scanner and ScanResultsStorage API to take a set of
packages instead of a list.
Add post-processing to the analyzer to detect those duplicates.

If duplicates are found prefer the project over the package, because it has likely more accurate metadata.

Is that actually so? In my experience, projects (which can be considered as unpublished packages) have less metadata available in machine readable format (which usually only gets generated when publishing). I'm e.g. thinking of Gradle projects here, why by themselves cannot declare a license, but once their artifacts get published as packages, the license is / can be in the accompanying POM.

If duplicates are found prefer the project over the package, because it has likely more accurate metadata.

Is that actually so? In my experience, projects (which can be considered as unpublished packages) have less metadata available in machine readable format (which usually only gets generated when publishing). I'm e.g. thinking of Gradle projects here, why by themselves cannot declare a license, but once their artifacts get published as packages, the license is / can be in the accompanying POM.

I changed the commit message to say "provenance information" instead of "metadata", because for projects VCS information can usually be read from the working tree.


Ball Transport Subsystem

Ball Transport
What is the primary purpose?
Transport cargo from the intake mechanism to the shooter.
What operations does it need to do?

Detect cargo entering through the intake mechanism.
Detect color of cargo entering through intake mechanism.
Shunt cargo from transport if it is the wrong color.
Transport cargo from intake to shooter.

What does the subsystem need to know?

Color of the cargo entering the transport subsystem.

What actuators are on the subsystem?

2 motors per conveyor system.
1 motor for shunting system.

What sensors are on the subsystem?

Color sensor.

How can the subsystem fail?
Not transporting the cargo from intake to shooter, not getting rid of the correct colored ball.
How can we mitigate failure?
Make sure cargo can get from point A to B before everything else.
What can be automated?
Ball shunting can be automated, the transport mechanism itself should be automated.

Why might it not transport from intake to shooter?
How does the shunting system work?
Can the shunt system run at the same time as the conveyors?
Is there more than one conveyor?

[ ] Detect cargo entering through the intake mechanism.
[ ] Detect color of cargo entering through intake mechanism.
[ ] Shunt cargo from transport if it is the wrong color.
[ ] Transport cargo from intake to shooter.

This is as feature-complete as we want it to be.


Upgrade Jackson 2.16.2 -> 2.17.0

This PR contains the following updates:

Package
Type
Update
Change

Jackson
import
minor
2.16.2 -> 2.17.0

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

Suggested commit message:
Upgrade Jackson 2.16.2 -> 2.17.0

See https://github.com/FasterXML/jackson-bom/compare/jackson-bom-2.16.2...jackson-bom-2.17.0

.... internet on the bus .... :top:


SSL CA option

We have an SSL certificate from GoDaddy where we need to provide an CA (Certificate authority) file. I tried to only add a key and certificate as sslKey and sslCert but this didn't work. With these patches added our SSL works fine. Don't know how to create any test(s) for this case, I'm afraid.

Our tests around https are to ensure that the correct parameters are passed to createServer.
In connection-endpointSpec.js we check that both sslKey and sslCert has been provided as parameters to createServer .
If you could add a separate test case to indicate that if sslCa is provided it is also passed in as an argument we can then merge this.
Many thanks for the PR!

Added three different tests for the new sslCa-option. Hope these are enough :)
Thanks for an awesome library!

Thanks for the quick update, Looks good!


Tree inside form triggers window reload on click

Describe the bug
When the tree is a child of a form element, and the user clicks on any node on the tree, then the window refreshes
To Reproduce
Add a tree inside a form element, and click on any node on the tree. The window will refresh
Expected behavior
We expect that the primary action will trigger (and maybe expand) but without refreshing the window
Demo
https://codesandbox.io/s/react-complex-tree-playground-forked-r69m1?file=/src/App.tsx
Desktop:

OS: iOS
Browser: Chrome
Version: Latest, 94

Root cause
The container element is a button by default, and the default button type is submit. When a submit button is clicked inside a form it automatically refreshes the window, unless someone calls preventDefault on the form on submit event or the on click event of the button.
Solution
Add an attribute type="button" to the button node container:
https://github.com/lukasbach/react-complex-tree/blob/6eb9a0e6baf1c1fcc661fbf0b6681dfae93666c4/packages/core/src/renderers/createDefaultRenderers.tsx#L116
I can raise a PR if needed
Thanks for the great component btw!

Fixed in 1.1.4


File extension being inconsistent

Somehow in a recent? ish update some inconsistency with the file extension was introduced.
When calling the saveAs function (example below), on windows it now doesnt recognize the .bin extension and assumes its a IN file, on android the .bin extension gets succesfully recognized and added and on Linux no extension gets added but it still works (so thatd be fine ig).
The problem im having with this is, that on Android (and i belive iOS too), the ext: 'bin' works fine as it always has, but on windows it breaks. I can now change it to ext: '.bin' to fix this issue on windows, but now on mobile i get 2 ..
Please fix this issue as soon as possible as my app is relying on this package, thanks!
FileSaver.instance.saveAs(
          name: tag.name,
          bytes: Uint8List.fromList(tagDump),
          ext: 'bin',
          mimeType: MimeType.other);

it seems to happen with 0.2.9 and anything upwards?

Hey, sincerest apologies for such a late response, I will check it up & fix it for sure, thanks

Oh hey, thanks for looking into this issue!

hey, uummm... any news on this issue?


Get 500 error building image from Dockerfile, internally reports "not a valid repository/tag"

I have a very simple Dockerfile, along with a very simple POM.  I'm using a private enterprise registry.
The Dockerfile (in "src/docker") is just the following:
FROM tomee:8-jdk-7.0.0-webprofile
(Obviously, more will be added when I work through infrastructure issues.)
The POM is just this:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">   <modelVersion>4.0.0</modelVersion>   <groupId>orderProcessingDashboard</groupId>   <artifactId>ordersImage</artifactId>   <version>0.0.1-SNAPSHOT</version>   <packaging>pom</packaging>   <build>     <plugins>   		<plugin>   			<groupId>com.spotify</groupId>   			<artifactId>docker-maven-plugin</artifactId>   			<configuration>   				<registryUrl>http://<host>:5000</registryUrl>   				<dockerDirectory>src/docker</dockerDirectory>   				<imageName>ordersImage</imageName>   			</configuration>   		</plugin>   	</plugins>   </build> </project>
When I run "mvn docker:build", I get this:

[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:0.4.11:build (default-cli) on project ordersImage: Exception caught: Request error: POST unix://localhost:80/build?t=ordersImage: 500: HTTP 500 Internal Server Error -> [Help 1]

I then looked at /var/log/messages and found this line:

Aug 10 17:36:21  dockerd: time="2016-08-10T17:36:21.395888585-04:00" level=error msg="Handler for POST /build returned error: Error parsing reference: "ordersImage" is not a valid repository/tag"

It's definitely a problem that the Maven build didn't report the full error message.  I don't know whether that's a problem with docker or the plugin.  The bigger problem is understanding why it thinks the name I'm trying to create the image with is invalid.

Hey @davidmichaelkarr thanks for the report. It is an issue within the plugin - I don't think it passes on the response body of the error response from Docker. I believe this is already captured in #119 so I will close this issue.

Well, thanks, but it was pretty obvious to me that it wasn't passing on the response body.  That should obviously be fixed, but that's not why I created this issue.  My problem is WHY is it saying that "ordersImage" is an invalid image name?  It says "is not a valid repository/tag". Even in your own docs you have a sample that uses an imageName value of "example".  I'm fairly certain that if I set my imageName to "example" I would get a similar error.


Detect dismission

Hi
I would like to hide the status bar before presenting the image (which is easily done) but I fail to detect the moment when GSImageViewerController has been dismissed again, in order to show the status bar again. I had to edit your files...
Is there a way to detect it? I was not able to do so by using viewDidAppear by any presenting viewControllers nor by using dismiss(animated...), which is simply not called on the presenting viewController...
Any ideas? Help would be appreciated!
Thanks!

Thanks for your question, I added a new tag 1.4.1 and this callback:
imageViewer.dismissCompletion = {
    print("dismissCompletion")
}

That was really fast! Thank you!


Vnet injection tutorial

This PR adds a tutorial and modifies code as necessary for the tutorial to work.

This is to solve issue #45


Add USDGLO as donation token on Stellar

We should investigate how to allow users to donate USDGLO on the Stellar network.

Using the current donation flow users should be able to select USDGLO as an elegible token.
They should be able to donate it using the QR code feature and
donations should be able to be confirmed and show up on the project details page -
the tracked price should show correctly - its a stable $1 per USDGLO
USDGLO should be GIVbacks eligible token

cc: @MoeNick

Donating tokens (non XLM)  on Stellar with currant flow needs users add another recipient address.
So if we want to handle tokens like USDGLO or USDC we need design and tech research, if it's priority I can jump into this issue with a solution.

Donating tokens (non XLM) on Stellar with currant flow needs users add another recipient address. So if we want to handle tokens like USDGLO or USDC we need design and tech research, if it's priority I can jump into this issue with a solution.

oh wow that's terrible! I didn't realize it was so complicated.. let's think about this one before we jump into approving it.


Support for GitHub Models using the Azure AI Inference API

Fix #1719
This adds GitHub Models (see https://github.com/marketplace/models ) support with the new Azure AI Inference API Java SDK.

I've added support for all the current models:

ChatModel
StreamingChatModel
EmbeddingModel

I also added tests for everything.
There are a couple of things which aren't perfect:

Function calling only works with GPT-4. According to https://thenewstack.io/a-comprehensive-guide-to-function-calling-in-llms/ , Mistral and Cohere should support it too, but it doesn't work. I'm guessing this is because they use a different API, and that the Azure AI Inference SDK doesn't support it yet.
TokenUsage for StreamingChatModel is always 0. As it works for ChatModel, I believe this is currently an API limitation.

To run the tests, you need 2 environment variables:

GITHUB_TOKEN : your GitHub authentication token
CI_DELAY_SECONDS_GITHUB_MODELS: a delay in order not to have rate limitations. I personally put it at 5 seconds.

All tests should be green, but I'll need to do another test tomorrow, as currently I've exhausted my quotas!!

Would be also great to have a dedicated documentation page and list Github Models in this table: https://docs.langchain4j.dev/integrations/language-models/
While documentation can wait a bit, I guess it would be nice to have at least a single example in https://github.com/langchain4j/langchain4j-examples repo for the release (which is happening this Wednesday in the morning)

@jdubois BTW I did not find EmbeddingModel, did you forget to push it?

Not sure I understand you, there is a GitHubModelsEmbeddingModel, is it what you are looking for?

@jdubois BTW I did not find EmbeddingModel, did you forget to push it?

Not sure I understand you, there is a GitHubModelsEmbeddingModel, is it what you are looking for?

Sorry, I missed it somehow...

BTW what is the plan for azure-ai-inference vs azure-ai-openai? I read in GItHub Models documentation that users are supposed to still use azure-ai-inference when they are ready for production, but we have langchain4j-azure-open-ai which uses azure-ai-openai and is probably supposed to be used for production (as well)?

BTW what is the plan for azure-ai-inference vs azure-ai-openai? I read in GItHub Models documentation that users are supposed to still use azure-ai-inference when they are ready for production, but we have langchain4j-azure-open-ai which uses azure-ai-openai and is probably supposed to be used for production (as well)?

It's 2 different products: Azure OpenAI is on Azure, for the big enterprises (you have your own instances, with specific security stuff like Service Principals), while GitHub Models is easy to use for developers (and probably some enterprises too, as it's a lot easier, probably cheaper, and it's the same thing in the end).
The two SDK are pretty similar, then there are some specific things for Azure OpenAI, including security. While GitHub Models is more generic. Those SDKs are mostly generated, so it's not really a duplication effort on the Azure side.

Would be also great to have a dedicated documentation page and list Github Models in this table: https://docs.langchain4j.dev/integrations/language-models/
While documentation can wait a bit, I guess it would be nice to have at least a single example in https://github.com/langchain4j/langchain4j-examples repo for the release (which is happening this Wednesday in the morning)

Here's a PR for the samples: https://github.com/langchain4j/langchain4j-examples/pull/110

And I have just pushed the documentation, which links to the examples 👍

@langchain4j code, examples and documentation should be OK, I'm crossing my fingers we can have this for tomorrow!


Fixed #33855 -- Removed unnecessary system check calls from test worker initialization.

ticket-33855
Regression in 3b3f38b3b09b0f2373e51406ecb8c9c45d36aebc.

Thanks for all reviews :100:


Splitting string that contains consecutive delimiters

Expected behavior:
split("a SPLITSPLIT b", "SPLIT") ---> ["a ", "", " b"]
Observed behavior:
split("a SPLITSPLIT b", "SPLIT") ---> ["a ", "SPLIT b"]
Within the loop in bsplitstrcb, i is sent too far forward
upon finding a match. Here is a proposed fix including tests,
open to suggestions. A few more details in the GH pull request.

Splitting string containing consecutive delimiters gives unexpected results
Expected behavior:
split("a SPLITSPLIT b", "SPLIT") ---> ["a ", "", " b"]
Observed behavior:
split("a SPLITSPLIT b", "SPLIT") ---> ["a ", "SPLIT b"]
For me, this is not the expected behavior.
It seems to not correspond with the behavior when a single char delimiter is used,
split("a || b", "|") ---> ["a ", "", " b"]
(Note that the string gets sent to bsplitcb when delim is one char.)
Also, the behavior does not correspond with JavaScript, Python, etc. split().
Precise example:
struct tagbstring delim = bsStatic("aa");
struct tagbstring s = bsStatic("1aaaa1");
bstrlist *list = bsplitstr(s, delim);
list is ["1", "aa1"] instead of ["1", "", "", "1"]
Proposed fix attached, but open to suggestions


RFC Typings: opt-in typing for data and find methods

The current typings leave get and set accepting/returning any, which is effectively what they do, however it's much more useful to be able to extract data with a type already in place e.g. const customer = this.get<Customer>('customer'). On it's face, that's not much of a distinction from const customer: Customer = this.get('customer'), but it really starts paying off when you want to do something like const customers = this.get<Customer[]>('customers').filter(c => c.balance > 0);, where you don't want to have to do an extra set of parens to do a cast on the get.
To that end, I've pushed up a typings change on edge that does this. The default type param for everything is still any, so not supplying it is mostly the same as without the change. The one difference is expected return type inference as in the example with the customer above. With the type param, typescript will infer Customer as the type parameter in const customer: Customer = this.get('customer') because of the typing on the variable. I think this is better, as it prevents something like const customer: Customer = this.get('customer') || {}; accidentally blowing something up (I actually found a few of these in my code trying out this change) because the {} doesn't have methods or whatever that Customer requires.
I'm opening this issue as a request for comments on this change. Obviously if you don't use typescript, you probably don't care, but for those who do, what do you think about this, or at the very least, does this negatively affect you?

I think this is a great improvement! Will tinker with it next week and report back!

After a few tests, this approach seems to improve Ractive's Typescriptenss considerably.
You have my vote! 😄👍


Fixed the default value and documentation for Input.action_press() from commit 8c45282

Fixed the default value and documentation for Input.action_press() from commit 8c45282
fixes https://github.com/godotengine/godot/issues/23772

same with #23776 but this has additional documentation.

Thanks!


What is the equivalent of dataTransfer.setData and dataTransfer.getData

Actually I am building an interface that needs to pass information from one component to another via drag and drop. But the interface does not need to move HTML elements around, just information attached to the draggable elements.
To do this, I am using DataTransfer.setData() and DataTransfer.getData() APIs.
So, what is the equivalent of those in this library?

@mbarakaja Thanks for bringing this up! There is no API to do this internally with draggable, but there are workarounds to this issue.
You could do this via HTMLElement.dataset or HTMLElement attributes on drag:start and drag:stop. (set on drag start and read on drag stop)
Alternatively you could use the DragSensor, which uses the browsers Drag and Drop API, you could something like:
const draggable = new Draggable(containers, {
  draggable: 'some-selector',
  // Adds the native drag sensor, which is not included by default
  sensors: [DragSensor],
});

// Removes the mouse sensor, which is included by default
draggable.removeSensor(MouseSensor);

draggable.on('drag:start', ({sensorEvent}) => {
  // originalEvent is now a native Browser Drag event with DataTransfer object
  const originalEvent = sensorEvent.originalEvent;

  originalEvent.dataTransfer.setData(/* ... */);
})

draggable.on('drag:stop', ({sensorEvent}) => {
  const originalEvent = sensorEvent.originalEvent;

  console.log(originalEvent.dataTransfer.getData(/* ... */));
})

There are currently no plans to add a native DataTransfer API for Draggable, but this may change depending on demand.
I hope this helped

Let me know if that answered your question @mbarakaja .
Closing this for now

Hello @tsov, sorry for not texting you back. Your post was really helpful. I ended up using the native drag and drop API.
Draggable is fantastic, but is overkill for what I need for now.
Thank you very much.