Request timeout when using JAVASCRIPT template

I am attempting to mock response with some values coming in the request.  The idea is to use JAVASCRIPT template to grab a field from the JSON body of the request and return it.  Expectation is created w/o any issues but when I send my request it times out after a long wait.  There are no errors in the logs.  Here is my expectation:
curl -v -X PUT "http://localhost:1080/mockserver/expectation" -d '{ "httpRequest": {         "path": "/test",         "body" : {             "type" : "JSON"         } }, "httpResponseTemplate": {        "template": "return { statusCode: 200, body: JSON.stringify({id: JSON.parse(request.body).id}) };",        "templateType": "JAVASCRIPT"    } }'
And here is my request I am trying to mock:
curl -v -H "Accept: application/json" -H "Content-Type: application/json" -X "POST" "http://localhost:1080/test" -d '{"id": "1234"}'
Somehow my request content type is being handled as TEXT.  Here is the corresponding log entry showing the incoming request:
`INFO o.m.m.HttpStateHandler request:
    {
      "method" : "POST",
      "path" : "/test",
      "headers" : {
        "Host" : [ "localhost:1080" ],
        "User-Agent" : [ "curl/7.54.0" ],
        "Accept" : [ "application/json" ],
        "Content-Type" : [ "application/json" ],
        "Content-Length" : [ "14" ]
      },
      "keepAlive" : true,
      "secure" : false,
      "body" : {
        "type" : "STRING",
        "string" : "{\"id\": \"1234\"}",
        "contentType" : "text/plain; charset=utf-8"
      }
    }`

I think you have to return the json object and not JSON.stringify(...). I had the same problem a while ago. Check the logs of the server. As I remember there should be a message - somthing like "must be an object instead of string"
return { statusCode: 200, body: {id: JSON.parse(request.body).id} };

I played a bit with your example. stringify is not the problem.
And now i see the problem, too. If you acces the 'string' attribute your remplate works... But this should not be the solution...

I received some help on https://gitter.im/jamesdbloom/mockserver to get around this limitation.  Here is a working set including reset, expectation and the request being mocked:
curl -X PUT "http://localhost:1080/mockserver/reset" && \ curl -X PUT "http://localhost:1080/mockserver/expectation" -d '{     "httpRequest": {         "path": "/test",         "body" : {               "type" : "JSON"         }     },     "httpResponseTemplate": {             "template": "return { statusCode: 200, headers: { Date: [ Date() ] }, body: JSON.stringify({the_received_id: JSON.parse(request.body.string).id}) };",             "templateType": "JAVASCRIPT"     } }' && \ curl "http://localhost:1080/test" -d '{"id": "1234"}'
It would be great to get the content-type header recognition fixed so that we can create the expectations w/o using a workaround.

Would it be possible to not hang when something is wrong with a javascript template?

Yes, I can add some additional error checking and return a failure response and add log events to aid the debugging the issue.  I'll look into this issue and try to resolve what is going on here in the next few days.

This is now fixed, when there is a template rendering failure due to an error in the template a 404 is returned and the error is logged to the event log and to the console (unless console logging is disabled).
The fix is available in the latest SNAPSHOT release http://mock-server.com/where/maven_central.html#sonatype_snapshot or will be available in the next RELEASE.


treewide: use src.name in sourceRoot

Description of changes
should be 0 rebuilds

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

I don’t feel great about introducing more rec. The rest all seems good though.

I don’t feel great about introducing more rec

I would frame that as a problem of builders that don't support finalAttrs, this PR is merely exposing that. And ofc hardcoding source/ is objectively wrong


3.2.1 update

Just a simple update of the glfw repo. The changelog is here.
I’m updating because I get an error from EGL in if I link use this crate in glfw. Looks like they fixed that (see the changelog about the lib stuff).
I didn’t use the upstream’s master, I just pulled a branch from the release’s tag.

Saw someone already did that. Closing for duplicate.

Dammit it was the 3.1.2!


[BUG]Compilation error of silabs-sensors in silabs_examples

Description of the issue
I encountered a compilation error when trying to use the "sl_uart_log_output=true" option to enable the serial port logging feature provided by you. This error may be present in many of the sample routines.I believe this is a minor spelling mistake and I hope you can fix it.
FAILED: obj/third_party/connectedhomeip/examples/platform/silabs/efr32-common.syscalls_stubs.cpp.o
arm-none-eabi-g++ -MMD -MF obj/third_party/connectedhomeip/examples/platform/silabs/efr32-common.syscalls_stubs.cpp.o.d -march=armv8-m.main+dsp -mcpu=cortex-m33 -mabi=aapcs -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mthumb -Og -g2 -fno-common -ffunction-sections -fdata-sections --specs=nosys.specs --specs=nano.specs -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wall -Werror -Wstack-usage=8192 -Wextra -Wshadow -Wunreachable-code -Wvla -Wformat -Wformat-nonliteral -Wformat-security -Wno-deprecated-declarations -Wno-missing-field-initializers -Wno-unknown-warning-option -Wno-unused-parameter -Wno-cast-function-type -Wno-psabi -Wno-maybe-uninitialized -fdiagnostics-color -fno-strict-aliasing -Wno-type-limits -fmacro-prefix-map=../third_party/connectedhomeip/= -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/plugin/security_manager/ -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/hardware/kit/common/bsp -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/hardware/board/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/hardware/driver/memlcd/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/hardware/driver/memlcd/src/ls013b7dh03 -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/hardware/driver/configuration_over_swo/inc/ -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/bootloader -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/bootloader/config -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/bootloader/config/s2/btl_interface -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/bootloader/api -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/CMSIS/Core/Include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/CMSIS/RTOS2/Include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/common/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emdrv/common/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emdrv/gpiointerrupt/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emdrv/dmadrv/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emdrv/nvm3/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emdrv/rtcdrv/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emlib/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/halconfig/inc/hal-config -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/peripheral/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/common -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/chip/efr32 -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/chip/efr32/rf/common/cortex -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/protocol/ieee802154 -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/plugin/pa-conversions -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/plugin/rail_util_pti -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/plugin/rail_util_rf_path -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/device_init/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/hfxo_manager/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/hfxo_manager/src -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/mpu/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/power_manager/inc/ -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/power_manager/src/ -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/sleeptimer/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/system/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/udelay/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/legacy_hal/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/token_manager/config -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/token_manager/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/token_manager/test -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/token_manager/test/include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/token_manager/test/stack/config -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/token_manager/test/stack/include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/middleware/glib -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/middleware/glib/config -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/middleware/glib/glib -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/middleware/glib/dmd -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/base/hal/plugin/psstore -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/base/hal/plugin/antenna -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/protocol/bluetooth/inc/ -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/plugin/plugin-common/fem-control -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/silicon_labs/silabs_core/graphics -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/silicon_labs/silabs_core/memory_manager -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/mbedtls/include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/mbedtls/include/psa -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/mbedtls/library -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/security/sl_component/sl_alt/include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/security/sl_component/sl_protocol_crypto/src -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/security/sl_component/sl_mbedtls_support/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/security/sl_component/sl_mbedtls_support/config/ -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/security/sl_component/sl_psa_driver/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/security/sl_component/sl_psa_driver/inc/public -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/security/sl_component/se_manager/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/security/sl_component/se_manager/src/ -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/freertos/cmsis/Include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/freertos/kernel/include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/driver/debug/inc -isystem../third_party/connectedhomeip/third_party/silabs/matter_support/matter/efr32/efr32mg24/BRD4187C/config -isystem../third_party/connectedhomeip/third_party/silabs/matter_support/matter/efr32/efr32mg24/BRD4187C/autogen -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/hal -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/hal/efr32 -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/driver/leddrv/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/driver/button/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/hardware/driver/mx25_flash_shutdown/inc/sl_mx25_flash_shutdown_usart -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emdrv/uartdrv/inc -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emdrv/uartdrv/config -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/hardware/driver/memlcd/inc/memlcd_usart -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/Device/SiliconLabs/EFR32MG24/Include -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/chip/efr32/efr32xg2x -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/freertos/kernel/portable/GCC/ARM_CM33_NTZ/non_secure -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/plugin/pa-conversions/efr32xg24 -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/radio/rail_lib/plugin/pa-conversions/efr32xg24/config -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/service/device_init/config/s2/ -isystem../third_party/connectedhomeip/third_party/silabs/gecko_sdk/platform/emdrv/spidrv/inc -Wno-maybe-uninitialized -Wno-shadow -Wno-error=array-parameter -Wno-error=array-bounds -mcmse -Wno-format-nonliteral -std=gnu++14 -fno-rtti -Wnon-virtual-dtor -DOTA_PERIODIC_TIMEOUT=86400 -DDISPLAY_ENABLED -DQR_CODE_ENABLED -DSILABS_OTA_ENABLED -DCHIP_HAVE_CONFIG_H=1 -DMBEDTLS_CONFIG_FILE=\"efr32-chip-mbedtls-config.h\" -DMBEDTLS_PSA_CRYPTO_CONFIG_FILE=\"psa_crypto_config.h\" -D__STARTUP_CLEAR_BSS -DHARD_FAULT_LOG_ENABLE -DCORTEXM3_EFM32_MICRO -DSILABS_LOG_ENABLED=true -DNVM3_DEFAULT_NVM_SIZE=40960 -DNVM3_DEFAULT_MAX_OBJECT_SIZE=4092 -DKVS_MAX_ENTRIES=255 -DEFR32_OPENTHREAD_API -DPHY=EMBER_PHY_RAIL -DCORTEXM3 -DMICRO=EMBER_MICRO_CORTEXM3_EFR32 -DPLAT=EMBER_PLATFORM_CORTEXM3 -DEFR32MG24B220F1536IM48=1 -DBRD4187C=1 -DSL_SUPRESS_DEPRECATION_WARNINGS_SDK_3_1 -D__HEAP_SIZE=0 -DSL_CATALOG_FREERTOS_KERNEL_PRESENT=1 -DMBEDTLS_THREADING_C=1 -DMBEDTLS_THREADING_ALT=1 -DSL_THREADING_ALT=1 -DSL_COMPONENT_CATALOG_PRESENT=1 -DPLATFORM_HEADER=\"platform-header.h\" -DUSE_NVM3=1 -DSL_CATALOG_POWER_MANAGER_PRESENT -DSL_CATALOG_SLEEPTIMER_PRESENT -DSILABS_LOG_OUT_UART=1 -DSILABS_LOG_OUT_RTT=0 -DENABLE_WSTK_LEDS -DCHIP_DEVICE_CONFIG_THREAD_ENABLE_CLI=1 -DCONFIG_ENABLE_UART -DCONFIG_USE_EXTERNAL_FLASH -DEFR32MG24 -DEFR32_SERIES2_CONFIG4_MICRO -DCHIP_ADDRESS_RESOLVE_IMPL_INCLUDE_HEADER=\<lib/address_resolve/AddressResolve_DefaultImpl.h\> -DSL_SENSOR_TYPE=1 -DBLE_DEV_NAME=\"SL-OCC-SENSOR\" -DOPENTHREAD_PROJECT_CORE_CONFIG_FILE=\"OpenThreadConfig.h\" -DOPENTHREAD_CORE_CONFIG_PLATFORM_CHECK_FILE=\"openthread-core-efr32-config-check.h\" -DPACKAGE_NAME=\"OPENTHREAD\" -DPACKAGE_VERSION=\"1.0.0\" -DRADIO_CONFIG_DMP_SUPPORT=1 -DEFR32MG24B220F1536IM48 -I../third_party/connectedhomeip/examples/platform/silabs/efr32 -I../third_party/connectedhomeip/examples/platform/silabs/display -I../third_party/connectedhomeip/examples/common/QRCode/repo/c -I../third_party/connectedhomeip/src/include -I../third_party/connectedhomeip/src -Igen/include -I../third_party/connectedhomeip/zzz_generated/app-common -I../third_party/connectedhomeip/src/platform/silabs/efr32 -I../third_party/connectedhomeip/silabs_examples/silabs-sensors/efr32/include -I../third_party/connectedhomeip/src/lib -I../third_party/connectedhomeip/examples/platform/silabs -I../third_party/connectedhomeip/third_party/jlink/segger_rtt/RTT -Igen/include/RTT -I../third_party/connectedhomeip/third_party/nlassert/repo/include -I../third_party/connectedhomeip/third_party/nlio/repo/include -I../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/openthread/include -I../third_party/connectedhomeip/examples/providers -I../third_party/connectedhomeip/zzz_generated/lighting-app -Igen/third_party/connectedhomeip/silabs_examples/silabs-sensors/efr32/data_model -Igen/third_party/connectedhomeip/silabs_examples/silabs-sensors/efr32/data_model/zapgen -I../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/openthread/examples/platforms -I../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/openthread/src -I../third_party/connectedhomeip/third_party/silabs/gecko_sdk/util/third_party/openthread/src/core -I../third_party/connectedhomeip/examples/platform/silabs/efr32/project_include -I../third_party/connectedhomeip/examples/platform/efr32 -I../third_party/connectedhomeip/third_party/silabs/matter_support/matter/efr32/efr32mg24/BRD4187C -I../third_party/connectedhomeip/third_party/silabs/gecko_sdk/protocol/openthread/platform-abstraction/efr32 -c ../third_party/connectedhomeip/examples/platform/silabs/syscalls_stubs.cpp -o obj/third_party/connectedhomeip/examples/platform/silabs/efr32-common.syscalls_stubs.cpp.o
../third_party/connectedhomeip/examples/platform/silabs/syscalls_stubs.cpp: In function 'int _read(int, char*, int)':
../third_party/connectedhomeip/examples/platform/silabs/syscalls_stubs.cpp:177:12: error: expected primary-expression before '=' token
  177 |     return = uartConsoleRead(ptr, len);
      |            ^
At global scope:
cc1plus: note: unrecognized command-line option '-Wno-unknown-warning-option' may have been intended to silence earlier diagnostics
[18/598] c++ obj/third_party/connectedhomeip/zzz_generated/app-common/app-common/zap-generated/attributes/sensor_data_model.Accessors.cpp.o
ninja: build stopped: subcommand failed.

Steps to reproduce the issue
1.Activate Environment
2./silabs_examples/silabs-sensors/efr32
3.edit ./args.gni: add this option "sl_uart_log_output=true"
4.compile it with following:
 export SILABS_BOARD=BRD4187C
 gn gen ./out
 ninja  -C  ./out
5.The error occurred.

Device type(s) and network topology
Matter over Thread
BRD4187C
Proposed solution(s)
Make the following modifications to the code：
--- a/examples/platform/silabs/syscalls_stubs.cpp
+++ b/examples/platform/silabs/syscalls_stubs.cpp
@@ -174,7 +174,7 @@ int __attribute__((weak)) _read(int file, char * ptr, int len)
 {
     (void) file;
 #if SILABS_LOG_OUT_UART
-    return = uartConsoleRead(ptr, len);
+    return uartConsoleRead(ptr, len);
 #else
     (void) ptr;
     (void) len;
~

SMG version
release_2.1.0-1.1
Protocol(s)
Thread
Hardware platform(s)
BRD4187C
Development platform(s)
No response
Captured data or logs
No response

@QingtianHoorii Thanks for reporting this! We'll be having a look at this shortly and I'll post an update here once available.


[Blood and Gold] New Sheet Code not active on roll20.net

PR was merged almost 29 hours ago, and still not reflected on roll20.net for my game character sheet Blood and Gold.

Looks like it's up.

I have forced an update on the sheet, just to make sure. @Rnedlose let me know if this is still not working.

Thanks Nic.  That worked.  I appreciate it.
Rodney Nedlose

On Apr 20, 2023, at 4:21 PM, Nic Bradley @.***> wrote:
I have forced an update on the sheet, just to make sure. @Rnedlose https://github.com/Rnedlose let me know if this is still not working.
—
Reply to this email directly, view it on GitHub https://github.com/Roll20/roll20-character-sheets/issues/11734#issuecomment-1516961840, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMCEVQ6F4VXYKHM5KUJAXQLXCGSELANCNFSM6AAAAAAXE3CVWI.
You are receiving this because you were mentioned.


[zh] adjust format in docs/tutorials/kubernetes-basics

[zh] adjust format in docs/tutorials/kubernetes-basics
%  ./scripts/lsync.sh content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html
content/zh/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html is still in sync
%
% ./scripts/lsync.sh content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
content/zh/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html is still in sync
%
% ./scripts/lsync.sh content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html
content/zh/docs/tutorials/kubernetes-basics/explore/explore-intro.html is still in sync
%
% ./scripts/lsync.sh content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html
content/zh/docs/tutorials/kubernetes-basics/expose/expose-intro.html is still in sync

/lgtm
/approve


Vectorize functions

Some of the slower running functions (zscore calculation, HMM peak calling) could be sped up by vectorizing the operations currently happening within for loops. This would also speed up parameter searches/testing where these functions would be run repeatedly!

Great suggestion! :)  Lets do it! :) Oh man, multiple parameter searches happening repeatedly! So bad haha.  I went ahead and assigned you but happy to jump in as well.


Bug with download automatically generated subtitle.

Checklist

[x] I'm reporting a broken site support issue
[x] I've verified that I'm running youtube-dl version 2021.1.16
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar bug reports including closed ones
[x] I've read bugs section in FAQ

I expect to use this command to download automatically generated subtitle file, but it always download the manual subtitles.

Test Command line
youtube-dl --write-auto-sub --sub-lang en --skip-download "https://www.youtube.com/watch?v=GWGbOjlJDkU"
[youtube] GWGbOjlJDkU: Downloading webpage
[youtube] GWGbOjlJDkU: Looking for automatic captions
[info] Writing video subtitles to: Who are you-GWGbOjlJDkU.en.vtt

Although the vtt file can be downloaded this time,But the vtt file is still artificial subtitles, not automatic subtitles.
The words of automatic subtitles are all lowercase.
vim "Who are you-GWGbOjlJDkU.en.vtt"
WEBVTT
Kind: captions
Language: en

00:00:30.203 --> 00:00:32.328
Why when things seem to be good

00:00:32.744 --> 00:00:33.578
 Surprise...

00:00:33.578 --> 00:00:34.661
 No warning

00:00:36.245 --> 00:00:38.745
 Stop working?

The above subtitles have the first letter capitalized, so they are only artificial subtitles, not automatic subtitles.
If the correct automatic subtitle file is downloaded, the subtitle text should be all lowercase, and each word has a timestamp.
Like this:
welcome<00:00:01.790><c> my</c><00:00:02.790><c> name</c><c.colorCCCCCC><00:00:02.820><c> is</c><00:00:03.210><c> Helga</c></c><c.colorE5E5E5><00:00:03.449><c> Vieira</c><00:00:03.929><c> and</c><00:00:04.080><c> this</c></c>

00:00:04.670 --> 00:00:04.680 align:start position:0%
welcome my name<c.colorCCCCCC> is Helga</c><c.colorE5E5E5> Vieira and this
 </c>

Please pay attention to this bug instead of closing this issue.
This bug has not been resolved.
Or, please indicate what the duplicate id is?

Please pay attention to this bug instead of closing this issue.
This bug has not been resolved.
Or, please indicate what the duplicate id is?


fix(region): Add support for suspend when syncing status of guest

这个 PR 实现什么功能/修复什么问题:
同步状态支持suspend。
是否需要 backport 到之前的 release 分支:

release/2.13
release/2.14
release/3.0

/area region

/lgtm

Codecov Report

Merging #4474 into master will increase coverage by 0.02%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master   #4474      +/-   ##
=========================================
+ Coverage    6.82%   6.85%   +0.02%
=========================================
  Files         521     521
  Lines       88442   88419      -23
=========================================
+ Hits         6037    6059      +22
+ Misses      81900   81855      -45
  Partials      505     505

Flag
Coverage Δ

#aFlag
6.85% <0%> (+0.02%)
:arrow_up:

Impacted Files
Coverage Δ

pkg/compute/guestdrivers/managedvirtual.go
0% <0%> (ø)
:arrow_up:

pkg/compute/models/zonequota.go
20.35% <0%> (-0.95%)
:arrow_down:

pkg/compute/models/disks.go
0.58% <0%> (-0.01%)
:arrow_down:

pkg/compute/models/instance_snapshots.go
4.61% <0%> (ø)
:arrow_up:

pkg/compute/models/guest_actions.go
0% <0%> (ø)
:arrow_up:

pkg/compute/models/networks.go
0.54% <0%> (ø)
:arrow_up:

pkg/compute/models/guestnetworks.go
0.22% <0%> (ø)
:arrow_up:

pkg/cloudcommon/db/standalone.go
0.88% <0%> (ø)
:arrow_up:

pkg/cloudcommon/db/modelbase.go
1.46% <0%> (+0.01%)
:arrow_up:

pkg/compute/models/regionquota.go
9.46% <0%> (+0.48%)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

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

/lgtm

/approve

/approve

/approve

/lgtm

/approve

/approve

/approve


Question about the LiLora aux matrix

I noticed that the original paper stated that down_aux/up_aux is a progressive orthogonal vector, but the code in this repository orthogonalized the auxiliary layer weights with down_dim/out_feature_dim. This may be the reason why losses cannot be converged. Can you take a look at it? Thanks!

@1585231086

I checked the paper again
I think I'm doing it in the right way
I also contected with author to ensure that I can just use pytorch's orthogonal
if you have better method can you just try to modify the code and make a PR?

I noticed that the original paper stated that down_aux/up_aux is a progressive orthogonal vector, but the code in this repository orthogonalized the auxiliary layer weights with down_dim/out_feature_dim. This may be the reason why losses cannot be converged. Can you take a look at it? Thanks!

In the pre-optimization stage, the loss can converge normally, indicating that the implementation in Lilora is correct. However, after exporting the Lilora weights to LoRA, the inference testing results are distorted.

The primary issue is to ensure that the training and exporting of Lilora work properly, Lilora consists of a state aux_seed and learnable parameters weights. I trained Lilora using a single image, and the loss function converged normally. However, after exporting it as Lora, it fails to generate accurate results.

i think so, too

The primary issue is to ensure that the training and exporting of Lilora work properly, Lilora consists of a state aux_seed and learnable parameters weights. I trained Lilora using a single image, and the loss function converged normally. However, after exporting it as Lora, it fails to generate correct results.

I think so, too

When I tried to resume from the latest checkpoint for further training of the hypernetwork, the validation results suddenly become weird and far from the ones generated from the previous iterations, there may be some issues about saving/loading lilora (weights/rng_state)?

Simply changing the down_aux and up_aux in Lilora from random orthogonal matrices to learnable matrices, and training it with a single image, the loss function converges normally. After exporting Lilora to regular Lora, the inference testing successfully generates correct facial images. From this, we can conclude that the issue lies in the implementation of down_aux and up_aux.

I noticed that the original paper stated that down_aux/up_aux is a progressive orthogonal vector, but the code in this repository orthogonalized the auxiliary layer weights with down_dim/out_feature_dim. This may be the reason why losses cannot be converged. Can you take a look at it? Thanks!

The author mentioned a similar work on twitter.
Hope this works for you.
[1] Z. Qiu et al., “Controlling Text-to-Image Diffusion by Orthogonal Finetuning,” arXiv preprint arXiv:2306.07280, 2023.

I think the most possilbe reason is I actually got "different" aux when I rebuilt weight from pre_optimized weights
so it just didn't work
But I don't have time recently
If anyone have more experiments on this plz tell me or open PR

I think the most possilbe reason is I actually got "different" aux when I rebuilt weight from pre_optimized weights so it just didn't work
But I don't have time recently
If anyone have more experiments on this plz tell me or open PR

I have verified the code of reusing the aux by a random seed. It rightly uses the pre-training-stage aux. By the way, if using the trainable aux weights, I can indeed get a face image instead of something strange.

I think the most possilbe reason is I actually got "different" aux when I rebuilt weight from pre_optimized weights so it just didn't work
But I don't have time recently
If anyone have more experiments on this plz tell me or open PR

I have verified the code of reusing the aux by a random seed. It rightly uses the pre-training-stage aux. By the way, if using the trainable aux weights, I can indeed get a face image instead of something strange.

So the aux things may have something wrong
but I also have tried something similar before
"only train lora_up for lora" so lora_down are remain random
I have some idea, checking

I think the most possilbe reason is I actually got "different" aux when I rebuilt weight from pre_optimized weights so it just didn't work
But I don't have time recently
If anyone have more experiments on this plz tell me or open PR

I have verified the code of reusing the aux by a random seed. It rightly uses the pre-training-stage aux. By the way, if using the trainable aux weights, I can indeed get a face image instead of something strange.

So the aux things may have something wrong but I also have tried something similar before "only train lora_up for lora" so lora_down are remain random
I have some idea, checking

I found that the nn.init_orthogonal_()'s output will be different with the tensor's device even using the same random_seed. And another interesting thing is that if using xavier_normal initialization, the lilora weights can generate faces well(inspired by @chenxinhua ).

I have retained orthogonal initialization for the weights, but made modifications to the initialization method of lilora and the implementation method of update_weight. By adjusting the learning strategy, I am now able to generate normal faces.

I have retained orthogonal initialization for the weights, but made modifications to the initialization method of lilora and the implementation method of update_weight. By adjusting the learning strategy, I am now able to generate normal faces.

In my experiments, Only needed to change this repo's down_aux initial method to random initialization, the pre-optimization can work fine.

I have retained orthogonal initialization for the weights, but made modifications to the initialization method of lilora and the implementation method of update_weight. By adjusting the learning strategy, I am now able to generate normal faces.

In my experiments, only needed to change this repo's down_aux initial method to random initialization, the pre-optimization can work fine.

is it possible to make pr for this?
We really need the fixes for this

I have retained orthogonal initialization for the weights, but made modifications to the initialization method of lilora and the implementation method of update_weight. By adjusting the learning strategy, I am now able to generate normal faces.

In my experiments, only needed to change this repo's down_aux initial method to random initialization, the pre-optimization can work fine.

is it possible to make pr for this? We really need the fixes for this

Just change the lilora.py line nn.init.orthogonal_(down_aux,gain=1) to nn.init.xavier_normal_(down_aux,gain=1).

nice work! is there any problem with train hypernetwork?

Hello, I found that the dataset definition may has something wrong. The index of image is needed to be sorted before the path_to_idx building:
        self.instance_images_path = list(Path(instance_data_root).iterdir())
        self.path_to_idx = {
            str(path): idx
            for idx, path in enumerate(sorted(self.instance_images_path))
        }
...
        img_path = self.instance_images_path[index % self.num_instance_images]

I made some improvements to lilora, there is no need to perform orthogonal initialization for down_aux and up_aux every time when update_weight is executed.
I also made some changes to train_preoptimized_liloras.py, the weights are saved directly for down_aux and up_aux matrices instead of aux_seed.
Additionally, I added a script that can directly export lilora weights according to any given identity. During inference testing, it is now possible to generate normal faces.

Here are some generated faces based on the exported weights according to 2 given identities.

can you share pretrained file? @chenxinhua

After further optimization, I will share the pretrained model.

I hope I can use it soon
@chenxinhua

I have retained orthogonal initialization for the weights, but made modifications to the initialization method of lilora and the implementation method of update_weight. By adjusting the learning strategy, I am now able to generate normal faces.

In my experiments, only needed to change this repo's down_aux initial method to random initialization, the pre-optimization can work fine.

is it possible to make pr for this? We really need the fixes for this

Just change the lilora.py line nn.init.orthogonal_(down_aux,gain=1) to nn.init.xavier_normal_(down_aux,gain=1).

done this

I made some improvements to lilora, there is no need to perform orthogonal initialization for down_aux and up_aux every time when update_weight is executed.
I also made some changes to train_preoptimized_liloras.py, the weights are saved directly for down_aux and up_aux matrices instead of aux_seed.
Additionally, I added a script that can directly export lilora weights according to any given identity. During inference testing, it is now possible to generate normal faces.

Here are some generated faces based on the exported weights according to 2 given identities.

your 1 and 2 is actually not a "improvements" which require extra vram/memory/storage for them
and lilora is for "you only need to store small amount of params"
for trianing process, cache aux may be ok but I think it should be optional
and for storage, I don't think store aux is a good idea

Does anybody check the train_hyperdreambooth.py? I found that the grads of weights are zero matrices in TransformerBlocks. Thanks.

@1585231086 you are training with pre_optimized weights?

@1585231086 you are training with pre_optimized weights?

Yes, I can ensure it. In face, now I just used the pre_optimized weights as the gt weights instead of with the unet generation loss together.

@1585231086 you are training with pre_optimized weights?

Yes, I can ensure it. In fact, now I just used the pre_optimized weights as the gt weights instead of with the unet generation loss together.

My test is wrong. The grads of weights are normal.

the same problem

Does anybody check the train_hyperdreambooth.py? I found that the grads of weights are zero matrices in TransformerBlocks. Thanks.

the same problem, and my pre-optimized weight generates zero matrices as pre_opt_weights too

@chenxinhua
I can't reproduce that picture either.
Could you please share the code?

Previously, you had
nn.init.orthogonal_(down_aux,gain=1)
nn.init.orthogonal_(up_aux,gain=1)

However, their dimensions are transposed, so I feel like the orthogonal_ function for the down_aux has to be used with a transposed dimension.
In other words,
down_aux = torch.empty(self.in_features, self.down_dim, dtype=weight.dtype, device=weight.device)
up_aux = torch.empty(self.out_features, self.up_dim, dtype=weight.dtype, device=weight.device)

# ...

nn.init.orthogonal_(down_aux,gain=1)
down_aux = torch.t(down_aux)
nn.init.orthogonal_(up_aux,gain=1)


Add Atmel SAM I2S (Inter-IC Sound) driver based on SSC module

This PR comes in three parts: DMA driver used by I2S, I2S driver itself and I2S testcases. The testcases are not yet complete however bulk of the functionality is already tested.

Hi @galak, it would be great if you could have a look at this PR. I don't want it to be forgotten. If it's of any help I can submit Atmel SAM DMA driver in a separate PR. All together it's certainly a large chunk of code.

Shouldn't it be done automatically by the script based on the CODEOWNERS file?

You're right. Which means the script has a bug then because:
drivers/*/*qmsi*                         @nashif
And there is a qmsi driver in drivers/dma so @nashif  should have been added.

I pushed new version fixing issues reported by @tbursztyka and rebased on latest 'arm' branch.

@galak yes, let's aim for 1.10 release. This PR was already way too long in the waiting. I'll prepare an updated version with DTS support for DMA controller in the next few days.

@mnkp I started with DTS support for DMA, currently I do not have time for it, you can take it over: https://github.com/jfischer-phytec-iot/zephyr/tree/wip-dma-dts ping me (IRC) if you have any questions

@mnkp can you please port this to cmake?

I've ported this PR to cmake. I'll need some more time to add DTS support for DMA controller. Since  DTS support for DMA controller is completely missing in Zephyr we could merge this PR as it is and add  DTS support later.

This got merged into the arm branch and don't have DTS support.  I'm willing to let them in with the understanding that we will fixup the DTS support in the future.


feat: add unit tests(chatgpt);enable unit test and codecov in github …

…actions

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@a665d57). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main      #45   +/-   ##
=======================================
  Coverage        ?   67.92%
=======================================
  Files           ?        8
  Lines           ?      318
  Branches        ?        0
=======================================
  Hits            ?      216
  Misses          ?       89
  Partials        ?       13


Feature/country zoom buttons

Overview

Map button theme.
Zoom buttons on the map.
Actions to manage the zoom with redux.

Demo

Works well for me and looks great :+1:


Panic bunker is just whitelist by another name

Description

Minimum age: 24 hours

Account age: over 2 months

Whitelist enabled: false
Try connecting:

Surely this isn't intended behavior, right? What's the difference between this and just having whitelist then

Yes, it should let you in if your account has entered the server more than 24 hours earlier. While a whitelist is intended to only allow specified accounts, a panic bunker is intended to allow everyone except for people that have never visited the server before, to counter raiding.


Vehicle dynamics

Hello! Great project!
Can you please help me with parameter tweaking?
I am using your drift car preset and trying to make car more dynamic (much faster 0-100mph) and at the same time add more inertia, so car can make 360 and drift longer.
Which parameters should I look at first?

Thank you!


Make pythonz-bd optional dependency

I prefer pyenv to pythonz.  And I like tools having less dependencies.
Would you make pythonz-bd dependency optional?

+100

Closing in favor of issue #155


[Bug Report] Message box can't access the Vuex store

Element UI version
2.3.8
OS/Browsers version
chrome 71.0.3578.98
Vue version
2.6.7
Reproduction Link
http://jsfiddle.net/al_sade/a2b7L4v0/25/
Steps to reproduce
create a component - 'MyCmp' ,that shows data coming from the store threw getters using a computed property.
importing 'MyCmp' component into another component that contains the message box.
pass 'MyCmp' to the messagebox message property
What is Expected?
The message box should render the value coming from the store using a computed property
What is actually happening?
An error is received :
vue.js:634 [Vue warn]: Error in render: "TypeError: Cannot read property 'getters' of undefined".
the box is shown with any other information that's hard coded, but every dynamic data like the
computed property is missing.

...

@bar-yariv meet same problem, have solutions?

@bar-yariv just Manual inject store. because vuex auto injection is invalid in MessageBox Component.
below is the auto inject store code in vuex source code .  https://github.com/vuejs/vuex/blob/dev/src/mixin.js
function vuexInit () {
    const options = this.$options
    // store injection
    if (options.store) {
      this.$store = typeof options.store === 'function'
        ? options.store()
        : options.store
    } else if (options.parent && options.parent.$store) {
      this.$store = options.parent.$store
    }
  }
}

below is the fixed code
// component with value from the store

const store = new Vuex.Store({
  state: {
    count: 0
  },
  getters: {
    count: state => state.count
  }
})
const myCmp = Vue.component('myCmp', {
  template: '<div>{{counter}}</div>',

 // this line inject store manually
  store: store,

  computed: {
    counter() {
      return this.$store.getters.count;
    }
  }
})

const vm = new Vue({
  el: '#app',
  components: {
    myCmp
  },
  data: {
    key: 1
  },
  methods: {
    showBox() {
      const h = this.$createElement;
      this.$msgbox({
        title: 'EUI',
        message: h(myCmp, {
          key: this.key++
        }) // passing cmp to the box
      })
    }
  },
  store
})

message box component 不是Vue 根组件的子节点，和store所在的组件没有子级关系


feat(README) : Add info over how to do the releases (AEROGEAR-9372)

Motivation
https://issues.jboss.org/browse/AEROGEAR-9372
What

Fix tag name in the CHANGELOG
Add info to the README over how to do the releases

Why

Have this process doc

Checklist:

[X] Code has been tested locally by PR requester
[ ] Changes have been successfully verified by another team member

Progress

[X] Finished task
[ ] TODO

Seems to be some duplication with https://github.com/aerogear/mobile-security-service-operator/pull/118 Wanna rebase before we do the review?

Hi @laurafitzgerald both have the CI automated. However, each project is a project and need to have your steps doc. Also, note that for the operator we have other steps and not these ones too.

@camilamacedo86 yep, didn't spot that it was the service repo and not the operator one. What are the verification steps here?

@laurafitzgerald verification steps to doc the process in the readme?

Regarding a changelog - a benefit of conventional commits is the ability to generate change logs from commits.
Is this something we have tried?
https://github.com/conventional-changelog/conventional-changelog

LGTM @camilamacedo86
@craicoverflow I am happy with the manual changelog for now and have our good commit messages be part of a release in GitHub.

Regarding a changelog - a benefit of conventional commits is the ability to generate change logs from commits.
Is this something we have tried?
https://github.com/conventional-changelog/conventional-changelog

This is something we've discussed in the past and part of the reason we switched to using the commit message convention we use now. I feel the discussion may spiral beyond the scope of this PR, so have posted more detailed thoughts in our chat channel


String Data Type

You previously explained how we may have to define a data type when adding a Data Element to a Data Set if one has not already been defined.
I seemed to have created a new data type, not realising that one already existed. The difference being that one has a lower case s and one has an upper case S.
What will happen as I add further Data Elements using both data types?
Should we be prevented from creating the same data type again?

I'll point you to this Mauro Data Mapper documentation about data types: https://maurodatamapper.github.io/glossary/primitive-data-type/primitive-data-type/. Specifically:

A Primitive Data Type is one of the four possible Data Types within Mauro Data Mapper. It describes data which has no further details about structure or referencing.
For example, if a Data Element is a name, then it’s Primitive Data Type would be ‘String’. Whereas, if a Data Element is a number, then it’s Primitive Data Type would be ‘Integer’.

When adding a Data Element to a Data Set, there is no specific data type you really need to assign to it, but Mauro requires one. So we have been suggesting you enter a primitive data type called "String" if one does not already exists. The name of the data type is irrelevant, as is the fact you have two with different upper/lowercase initials. You could even name it something completely different, like "Text". The key part is that you have assigned a data type to the Data Element, simply because one is required - it is not actually used when publishing the Data Set to DITA.

30/09/24 - this is unrelated to publishing so is not an issue for the DITA.
Look at the Wiki.

@KatePalmerLilley - we need to discuss this for the Wiki.

We need to retest https://nhsd-confluence.digital.nhs.uk/pages/viewpage.action?pageId=391971867

Kate and Angie to test on different new data sets.

Wiki page updated for Kate to test.

I have tested the wiki and it works, but i would like to discuss with @jamesrwelch on Tuesday call

Wiki to be updated to make this clear.

Wiki updated. @KatePalmerLilley - are you now Ok with this.

yes thanks
Kate Palmer-Lilley (she/her)
Associate Standards Architect
Information Standards Architecture | TSAS (Technology Strategy, Architecture and Standards)
Transformation Directorate | NHS England
07736 484 787

From: AngelaFaulding @.>
Sent: Tuesday, November 26, 2024 14:57
To: NHSDigital/DataDictionaryPublication @.>
Cc: PALMER-LILLEY, Kate (NHS ENGLAND - X24) @.>; Mention @.>
Subject: Re: [NHSDigital/DataDictionaryPublication] String Data Type (Issue #584)
This message originated from outside of NHSmail. Please do not click links or open attachments unless you recognise the sender and know the content is safe.
Wiki updated. @KatePalmerLilleyhttps://github.com/KatePalmerLilley - are you now Ok with this.
—
Reply to this email directly, view it on GitHubhttps://github.com/NHSDigital/DataDictionaryPublication/issues/584#issuecomment-2501037691, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AW4P2ZWP42FIYKGEGXSWZED2CSD7BAVCNFSM6AAAAABOVP3Z4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBRGAZTONRZGE.
You are receiving this because you were mentioned.Message ID: @.***>

This message may contain confidential information. If you are not the intended recipient please:
i) inform the sender that you have received the message in error before deleting it; and
ii) do not disclose, copy or distribute information in this e-mail or take any action in relation to its content (to do so is strictly prohibited and may be unlawful).
Thank you for your co-operation.
NHSmail is the secure email, collaboration and directory service available for all NHS staff in England. NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and other accredited email services.
For more information and to find out how you can switch visit Joining NHSmail – NHSmail Supporthttps://support.nhs.net/article-categories/joining-nhsmail/


Can't convert existing wsl 1 linux image to wsl 2. Also can't install ubuntu as wsl 2 from scratch.  Windows 10 Home.

Environment
Windows 10 Home

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.19041.0 Microsoft Windows NT 10.0.19041.0

Microsoft Windows [Version 10.0.19041.329]

Steps to reproduce
PS C:\Users\jaros> wsl --set-version Ubuntu-20.04 2
Conversion in progress, this may take a few minutes...
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
There are no more endpoints available from the endpoint mapper.
PS C:\Users\jaros>

#Attached logs
I was following the instruction, please let me know if those logs are helpful in any way
logs.zip
Expected behavior
should convert linux distribution to wsl 2
Actual behavior
There are no more endpoints available from the endpoint mapper. ---> conversion failed
> wsl --list --verbose

  NAME            STATE           VERSION
* Ubuntu-20.04    Stopped         1
  Ubuntu-18.04    Stopped         1

related issues:
#4403
#5152
I tried reinstalling/restaring windows features related to WSL without any change in behaviour.
I also tried uninstalling all distributions and installing from scratch with default wsl set to version 2. But in that scenario I falled into #5331 issue.
Any help will be really welcome, I'm blocked from using docker and I just have bought home license :(

The suggestion over in #4403 was to collect network logs.

/dupe #4403


[Unit Test] dotnet-sdk: Coverage Audit

As part of dapr/dapr#2226 we need to perform a unit test coverage audit for this package. The purpose of this audit is to identify unit test coverage gaps that we would like to close ahead of v1.0.
Audit Guidelines:

We're not shooting for a particular coverage percentage, rather we're looking to add tests which deliver on ensuring correctness and reliability. We prefer efforts that deliver coverage of critical components, rather than just bumping up our coverage percentage.
Please create issues for each identified high value area. Be sure to add the label "area/test/unit" and be sure to link this issue and dapr/dapr#2226 in the issue discussion. Also, be sure to add them to the appropriate rc1 and 1.0 milestones.
You can close this ticket and update the table in dapr/dapr#2226 once a maintainer of this package has signed off on the list of high value test coverage tickets.
Unit testing will always be an ongoing process. The goal of this audit is not to be "done" with unit test coverage, just to ensure that we have a reasonable baseline of coverage that we can maintain and improve upon ahead of the v1.0 release.

Need to complete dapr/dotnet-sdk#436 first
RELEASE NOTE: NOT APPLICABLE

This was being tracked for 1.0, which is a while ago now. We do have test coverage reports and are continuing to improve.


Add is_playing_tv property and test

Also update the docs to note that the switch/play tv are for playbar.

Hi @dajobe - did you manage to do the test you detailed here:
https://github.com/SoCo/SoCo/pull/225#issuecomment-57056437
To confirm it is different from the "Line-In"
If it is indeed different - then it would be good to get this merged in

@robwebset the playbar only has one input and intended for TV, so Line-In == TV.  I'm not sure what to do with this patch.
"PLAYBAR connects to your TV using a single optical cable and plays all sources connected to the TV, including cable boxes and game consoles." -- http://www.sonos.com/shop/products/playbar
See http://www.sonos.com/shop/i/products/playbar.detail_big.jpg

@dajobe The question is - does your code is_playing_tv do the same as the check for line-in already in SoCo?
And if you have something that has a line-in - does this is_playing_tv method return "true" when it is using line in?

@robwebset I can check out the playbar part of it at home, but I don't have any other sonos device with line-in to check the opposite.

If no one else steps up, I can probably do the test here. In any case, I don't think it should be pulled before it has been tested (and possibly fixed), because the name of the property would then be misleading.

@robwebset I was looking for "the check for line-in already in SoCo?" you mentioned but I can't see it.  There is no is_playing_linein method - maybe we should add that too?
I can see switch_to_line_in that uses x-rincon-stream: with CurrentURI arg to avTransport.SetAVTransportURI
Looks like if that's the difference then TV and Line-In are distinguishable since my patch here looks for TrackURI starting 'x-sonos-htastream:'.  I'm curious if my code would make TrackURI return x-rincon-stream... if playing line in.  I can't test that since I only have a Playbar.  @KennethNielsen can you help ?

@dajobe Sorry, yes you are correct - got confused - the question I meant to ask - is this the same as line-in, so will the same command check TV and Line in - in which case it should have a generic name to cover both cases - if they are different checks - then they should have different names :)

Agree with @robwebset about that the names should reflect the functionality.
@dajobe Yes, I may be able to test it this evening or over the weekend. Can you supply the test code you wich me to run on this branch?

Coverage increased (+2.76%) to 53.9% when pulling 83d2db886b065d76499276cff0ac2989fb5c3a07 on dajobe:is-playing-tv into 9302fd2deb0c26596d3d8f0e2a7acec062aeb403 on SoCo:master.

Coverage increased (+3.04%) to 54.18% when pulling 6c5a2626255d85f4bb43cca730454854e1e805d4 on dajobe:is-playing-tv into 9302fd2deb0c26596d3d8f0e2a7acec062aeb403 on SoCo:master.

@KennethNielsen I added two new is_playing methods we can try out but more specifically see if is_playing_line_in and is_playing_tv work correctly.  I can only test playbar (TV in).

Coverage increased (+3.04%) to 54.18% when pulling 68a460c31f9540ca8cead75cf2cdf446350cacf4 on dajobe:is-playing-tv into 9302fd2deb0c26596d3d8f0e2a7acec062aeb403 on SoCo:master.

So I think once the is_playing_lin_in has been verified (unfortunately I can't - I don't have anything with a line-in) we can get this into the 0.11 release https://github.com/SoCo/SoCo/issues/278
+1

When playing tv through my playbar with this code:
In [18]: coord.is_playing_tv
Out[18]: True

In [19]: coord.is_playing_radio
Out[19]: False

In [20]: coord.is_playing_line_in
Out[20]: False

Coverage increased (+0.25%) to 54.38% when pulling 68e5ee07e85084b9f319663102d6ffb6d6d6cce4 on dajobe:is-playing-tv into 843be920fc8d13ff93a015b381e9b47c315cb703 on SoCo:master.

Coverage increased (+0.25%) to 54.38% when pulling 68e5ee07e85084b9f319663102d6ffb6d6d6cce4 on dajobe:is-playing-tv into 843be920fc8d13ff93a015b381e9b47c315cb703 on SoCo:master.

Coverage increased (+0.25%) to 54.38% when pulling 68e5ee07e85084b9f319663102d6ffb6d6d6cce4 on dajobe:is-playing-tv into 843be920fc8d13ff93a015b381e9b47c315cb703 on SoCo:master.

@dajobe I'm very sorry for not reporting back after having promised it. I've been busy with my 5 months old, still that's no excuse for not writing here that I was too busy.
In any case, I finally found a few moments to test the branch. I played something on line-in on my play 5 and it works the way it is supposed to:
>>> kontor.is_playing_tv
False
>>> kontor.is_playing_line_in
True
>>> kontor.is_playing_radio
False

@robwebset Wow, this has been laying around for a while. I guess this is ready for merge after the test I did, correct?

@dajobe ^^

+1 from me - think everything is OK to go in

@KennethNielsen thanks.  this took a while :)

@dajobe You agree it is good to go in in current form corretc?

@KennethNielsen yes. :shipit:

I'll merge. Please drop a line about the change in the issue with information for the release notes #311

@dajobe never mind my comment about added line to the release notes, it seems that @stefankoegl already did it.


Is there any document about mx.optimizer?

I cannot find the description document about mx.optimizer.
Help me:question:

please refer the doc module-mxnet.optimizer

thank you


Package request: PyMC Stack

Project description
I'm keen to add pymc stack to nix and maintain it, what are my next steps?
PyMC Ecosystem

[ ] pymc-experimental
[ ] pymc-marketing
[ ] causalpy
[ ] nutpie
[ ] nuts-rs (Rust)

pymc-experimental

homepage URL: https://github.com/pymc-devs/pymc-experimental
source URL: https://github.com/pymc-devs/pymc-experimental
license: Apache License, Version 2.0
platforms: universal

pymc-marketing

homepage URL: https://github.com/pymc-labs/pymc-marketing/
source URL: https://github.com/pymc-labs/pymc-marketing/
license: Apache License, Version 2.0
platforms: universal

causalpy

homepage URL: https://github.com/pymc-labs/CausalPy/
source URL: https://github.com/pymc-labs/CausalPy/
license: Apache License, Version 2.0
platforms: universal

nutpie

homepage URL: https://github.com/pymc-devs/nutpie
source URL: https://github.com/pymc-devs/nutpie
license: Apache License, Version 2.0
platforms: rust supported

nuts-rs

homepage URL: https://github.com/pymc-devs/nuts-rs
source URL: https://github.com/pymc-devs/nuts-rs
license: Apache License, Version 2.0
platforms: rust supported
Here, probably @aseyboldt can help to set things properly, but going to just use nix-init

Add a :+1: reaction to issues you find important.

I'm intrigued. I'd like to learn some nix.


Fix autoload config

This is a 🐞 bug fix.
🙋♂ feature or enhancement.
This is a 🧐 documentation change.

[ ] I've added tests (if it's a bug, feature or enhancement)
[x] I've adjusted the documentation (if it's a feature or enhancement)
[x] The test suite passes (run bundle exec rspec to verify this)

Summary
Fix config.autoload_paths. Also renamed it from config.extra_autoload_paths to config.autoload_paths. The jets upgrade command will handle this.
Context
https://community.rubyonjets.com/t/config-extra-autoload-paths-doesnt-seem-to-work/224/3

Released in v2.1.1


Delete sector sync not working

When clicking the stop sync button, the frontend sends the below request and gets a 204 No Content response from the backend, and the sector sync isn't deleted:
https://api.col.plus/assembly/3/sync/2729
Host: api.col.plus
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Authorization: Bearer [redacted]
Origin: https://www.col.plus
DNT: 1
Connection: keep-alive
Referer: https://www.col.plus/
DELETE: HTTP/1.1 204 No Content
Date: Tue, 10 Sep 2019 15:41:17 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type, Accept-Language, X-Requested-With
Keep-Alive: timeout=5, max=72
Connection: Keep-Alive

The deleted sector syncs still show in the API:
{"attempt":2,"state":"preparing","started":"2019-09-09T22:09:42.133","finished":"2019-09-09T22:09:42.14","error":"IllegalArgumentException: Sector 2729 does have a non existing subject CLASS Polypodiopsida for dataset 1140","type":"SectorSync","sectorKey":2729,"usagesCount":0},
{"attempt":2,"state":"preparing","started":"2019-09-09T22:09:42.071","finished":"2019-09-09T22:09:42.128","error":"IllegalArgumentException: Sector 2728 does have a non existing subject CLASS Lycopodiopsida for dataset 1140","type":"SectorSync","sectorKey":2728,"usagesCount":0},

The bug can be reproduced from the steps described in #468.
Frontend version: 5e066ea September 10, 2019 8:46 AM
Backend version: 530045e September 9, 2019 11:45 AM

Actually delete sector sync does seem to work because I got an InterruptedException, it just doesn't remove the sector from the sector sync list so the frontend still displays it.

the sector sync should still be in the list, but it should have a state=CANCELED. That does not seem to happen if I read this right?

The clearinghouse-ui sends the following API call when clicking any of the stop sync buttons on this page:
DEL https://api.catalogue.life/assembly/3/sync/1

204 No content

I thought it was a clearinghouse-ui bug but the sector ID that we want to delete is actually sectorKey 1:
https://api.catalogue.life/assembly/3/sync?limit=25&offset=0
It doesn't end up as state=CANCELED and stays at state=preparing.


How can I build a setimmediate flavor that is not uglified?

We are currently using 'promise/setimmediate/es6-extensions' from npm which is uglified (e.g. this._state and this._value are uglified). It would be very useful to have an uglified built to be used in some specialized development environment ;)

We intentionally do not support this in order to prevent people relying on the name of those properties.


Single New EKS Cluster Open Source Observability Accelerator pattern feature to alert with AMP

Is your feature request related to a problem? Please describe.
We need to creating alerting rules  via GitOps.
Describe the solution you'd like
We need to creating alerting rules  via GitOps.
Describe alternatives you've considered
We need to creating alerting rules  via GitOps.
Additional context
We need to creating alerting rules  via GitOps.

@elamaran11 alerting rules are created with PR 76; please check if ok

This is working now. Closing this PR.


Fix compilation error on bootstrap module

Getting a compilation failure on the bootstrap module while trying to do a mvn clean package from the root of the project.
The error is complaining about being unable to find javax.annotation.PostConstruct in bootstrap/src/main/java/io/jenkins/jenkinsfile/runner/bootstrap/commands/JenkinsLauncherCommand.java.
Adding the javax.annotation-api dependency to the bootstrap module makes things happy.

[X] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your master branch!
[X] Ensure that the pull request title represents the desired changelog entry
[X] Please describe what you did
[ ] Link to relevant issues in GitHub or Jira
[ ] Link to relevant pull requests, esp. upstream and downstream changes
[ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

🤦 yeah, that'll be it.  I didn't notice in my IDE that the project was setup for Java 11 instead of 8.  Changed it to 8 and all became happy.  I'll close this PR.


Fixing executemany

Hello!
I have noticed, that executemany does several little queries instead one big query. So I have tried to fix it.
I took regular expression from library pymysql.

I'm not sure I understand what's the issue with sending multiple queries?
The regex looks complicated, there is certainly no REPLACE or ON DUPLICATE in ClickHouse.

About executemany:
So if I write query like:
params = [
  ('something', 'something'),
  ('something', 'something'),
  ('something', 'something'),
]
sql_alchemy.execute('INSERT INTO table (name, name2) VALUES (%s, %s)',  *params)

Query will be sent three time, because will be builded three different queries,like this:
INSERT  INTO table (name, name2) VALUES ('something', 'something');
INSERT  INTO table (name, name2) VALUES ('something', 'something');
INSERT  INTO table (name, name2) VALUES ('something', 'something');

But we should build one big query like this:
INSERT  INTO table (name, name2) VALUES ('something', 'something'), ('something', 'something'), ('something', 'something');

Ok, makes sense, thanks!


Fails to publish data source to server

About You:
Name: Max
Company: Gigaspaces
Your question:
I am having an issue publishing a data source from a desktop to a server when Gigaspaces connector is in use.
We are using a connector that is not packed as a taco file.
Connectivity to Desktop works with no issues.
Failed to publish data source from Desktop to a Tableau server, getting error "Tableau doesn't recognize the data source type 'insightedge_jdbc'... "
Tableau Desktop version 2019.2.8
Tableau Services Manager command line version 20192.20.0218.0709.
Tableau Server version 20192.20.0218.0709.
C:\tdvt_workspace_02>tsm configuration get -k native_api.connect_plugins_path
C:/insightedge-connector
In log vizportal/vizportal_node1-0.log.2020-03-11
Caused by: com.tableausoftware.nativeapi.exceptions.DataSourceException: Tableau doesn't recognize the data source type 'insightedge_jdbc'. It might not be available in this version of Tableau, or it might be a
 connector plugin that's not installed on this system..
.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method).
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62).
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45).
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423).
        at com.tableausoftware.nativeapi.serialization.ExceptionMapper.mapTableauException(ExceptionMapper.java:111).
        at com.tableausoftware.nativeapi.serialization.ExceptionMapper.mapVizqlWorkerException(ExceptionMapper.java:57).
        at com.tableausoftware.nativeapi.serialization.ExceptionMapper.mapVizqlWorkerException(ExceptionMapper.java:74).
        at com.tableausoftware.nativeapi.dll.NativeApiJNI.ExtractAndDCInfo_getDSExtractAndDCInfoFromFile(Native Method).
        at com.tableausoftware.nativeapi.dll.ExtractAndDCInfo.getDSExtractAndDCInfoFromFile(ExtractAndDCInfo.java:103).
        at com.tableausoftware.nativeapi.connections.DatasourceInfoUtils.extractDatasourceInfoFromDatasourceFile(DatasourceInfoUtils.java:49).
        at com.tableausoftware.model.workgroup.service.VqlServerService.extractDatasourceInfoFromDatasourceFile(VqlServerService.java:346).
        at com.tableausoftware.domain.content.publishing.DatasourceExtractInfo.(DatasourceExtractInfo.java:44).
        ... 21 more.
2020-03-11 15:06:11.868 +0000 (Default,admin@local,sgsniONpSoOrXN7H9LfR7A,Xmj@Y7VUAe9Z3nr7ikgVXgAAAgE,0:-7dee36a5:170be04a8b6:a2f) pool-28-thread-1 vizportal: INFO  com.tableausoftware.domain.asyncjobs.AsyncJob
Service - Async job id: [14], type: [Publish Datasource], status: [failed].

Did you call command tsm pending-changes apply to apply the change and restart server?
If so, check logs nativeapi_vizqlserver*.txt in C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs\vizqlserver see if the connector is loaded correctly.

Yes, the changes were applied.
C:\Users\Administrator>tsm pending-changes list
Topology
There are no pending topology changes.
I did not see any obvious errors in the logs.
Attaching some snippets from the logs.
Please let me know if you want me to send over the full log files and how to transfer the logs to you.
 12/03/2020   13:06.37   /drives/c/ProgramData/Tableau/Tableau Server/data/tabsvc/logs/vizqlserver  grep insight nativeapi_vizqlserver_1-1_2020_03_12_00_00_00.txt
{"ts":"2020-03-12T11:23:01.822","pid":6056,"tid":"8e0","sev":"info","req":"-","sess":"-","site":"-","user":"-","k":"server-startup-options","v":{"kms.use_mock":"false","license.server":"localhost","licenseservice.vendor_daemon.port":"8153","licensing.app.lmreread":"C:/Program Files/Tableau/Tableau Server/packages/bin.20192.20.0218.0709/lmreread.exe","licensing.asr.dir":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/services/vizqlserver_1.20192.20.0218.0709/lib","licensing.file":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/config/vizqlserver_1.20192.20.0218.0709/tableau.lic","licensing.log.dir":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/logs/licensing","licensing.login_based_license_management.default_requested_duration_seconds":"0","licensing.login_based_license_management.enabled":"true","licensing.login_based_license_management.max_requested_duration_seconds":"15552000","licensing.random_extra_sleep":"0.5","licensing.sleep_between_tries":"3.0","licensing.tries":"5","line.separator":"\r\n","local_metadata.worker.connectiontimeout":"30","local_metadata.worker.hcfails":"2","local_metadata.worker.hcinterval":"30","local_metadata.worker.hcpasses":"1","local_metadata.worker.retry":"300","local_vizportal.worker.connectiontimeout":"30","local_vizportal.worker.hcfails":"2","local_vizportal.worker.hcinterval":"30","local_vizportal.worker.hcpasses":"1","local_vizportal.worker.retry":"300","log.rotate":"true","log.rotate_interval":"86400","log4j.configuration":"file:///C:/ProgramData/Tableau/Tableau%20Server/data/tabsvc/vizqlserver/1/conf/log4j.xml","logdir":"C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs\vizqlserver","logfile":"C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs\vizqlserver\vizqlserver_node1-1.log","longRunningTransactions.CheckFrequencySeconds":"300","longRunningTransactions.LongRunningWarningThresholdSeconds":"60","longRunningTransactions.TransactionStuckAlertThresholdSeconds":"600","maestro.featureFlags.futureFeature":"false","maestro.input.allowed_paths":"","maestro.output.allowed_paths":"","maestro.server_bin_path":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/services/vizqlserver_1.20192.20.0218.0709/bin","maestro.show_allowed_paths":"true","managed_keychain.ttl_in_sec":"21600","managed_keychains.enable_cache":"false","managed_keychains.max_cache_size":"100","materializedViews.BloomFilterBuildPeriod":"10","materializedViews.MaxBatchSubmissionCount":"100","materializedViews.WebAuthoringBatchHoldMinutes":"10","materializedViews.max_allowed_percentage_of_hyper_memory":"50","materializedViews.max_query_cache_entry_size_in_kb":"262144","max_allowed_document_version":"","messagebus.config.topics.dir":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/config/vizqlserver_1.20192.20.0218.0709/messagebus/topics","messagebus.core.messageRetentionTimeInMinutes":"2880","messagebus.core.messageSizeLimitKb":"10","messagebus.subscriber.longPollSeconds":"20","messagebus.subscriber.maxRetryCount":"100","messagebus.subscriber.sessionTimeoutSeconds":"60","metadata.service.graphdb.type":"sqlg","metadatasearchquery.procs":"0","metadatasearchquery.vmopts":"-XX:+UseConcMarkSweepGC -Xmx128m -XX:+ExitOnOutOfMemoryError","metricsservices.authoring.enabled":"false","mode.standalone.enabled":"true","mongrel.tcpqueue.length":"100","monitoring.dataengine.connection_timeout":"30000","monitoring.hyper.connection_timeout":"30000","monitoring.initial_delay":"20","monitoring.interval":"6","monitoring.num_threads":"2","monitoring.shutdown_delay":"5","monitoring.time_period":"60","monitoring.up_percentage":"0","native_api.MaterializedViewMaxNumConnectionsForCacheWarming":"10","native_api.MaterializedViewMinQueryExecutionDurationThresholdInMs":"500","native_api.MaterializedViewQueryExecutionDurationToLoadingRatioInPercentage":"200","native_api.MaterializedViewQueryExecutionDurationToLoadingRatioInPercentageForSpatialData":"240","native_api.MaterializedViewQueryResultReductionRatioInPercentage":"90","native_api.MemberIdentityValidationEnabled":"true","native_api.MemberIdentityValidationMaxBlockDepth":"10","native_api.UseAlternativeFederationEngine":"true","native_api.allowed_paths":"*","native_api.connect_plugins_path":"C:/insightedge-connector","native_api.cpu_use_average":"false","native_api.default_cache_timeout_minutes":"720","native_api.device_specific_dashboard_phone_size":"500","native_api.device_specific_dashboard_tablet_size":"800","native_api.external_cache.use_timestamp":"true","native_api.external_cache_disable":"false","native_api.internal_disallowed_paths":"C:/Program Files/Tableau/Tableau Server; C:/ProgramData/Tableau/Tableau Server","native_api.java_home":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/services/vizqlserver_1.20192.20.0218.0709/repository/jre"}}
✔
 12/03/2020   13:06.45   /drives/c/ProgramData/Tableau/Tableau Server/data/tabsvc/logs/vizqlserver  grep insight nativeapi_vizqlserver_1-0_2020_03_12_00_00_00.txt
{"ts":"2020-03-12T11:23:01.482","pid":6032,"tid":"33a4","sev":"info","req":"-","sess":"-","site":"-","user":"-","k":"server-startup-options","v":{"kms.use_mock":"false","license.server":"localhost","licenseservice.vendor_daemon.port":"8153","licensing.app.lmreread":"C:/Program Files/Tableau/Tableau Server/packages/bin.20192.20.0218.0709/lmreread.exe","licensing.asr.dir":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/services/vizqlserver_0.20192.20.0218.0709/lib","licensing.file":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/config/vizqlserver_0.20192.20.0218.0709/tableau.lic","licensing.log.dir":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/logs/licensing","licensing.login_based_license_management.default_requested_duration_seconds":"0","licensing.login_based_license_management.enabled":"true","licensing.login_based_license_management.max_requested_duration_seconds":"15552000","licensing.random_extra_sleep":"0.5","licensing.sleep_between_tries":"3.0","licensing.tries":"5","line.separator":"\r\n","local_metadata.worker.connectiontimeout":"30","local_metadata.worker.hcfails":"2","local_metadata.worker.hcinterval":"30","local_metadata.worker.hcpasses":"1","local_metadata.worker.retry":"300","local_vizportal.worker.connectiontimeout":"30","local_vizportal.worker.hcfails":"2","local_vizportal.worker.hcinterval":"30","local_vizportal.worker.hcpasses":"1","local_vizportal.worker.retry":"300","log.rotate":"true","log.rotate_interval":"86400","log4j.configuration":"file:///C:/ProgramData/Tableau/Tableau%20Server/data/tabsvc/vizqlserver/0/conf/log4j.xml","logdir":"C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs\vizqlserver","logfile":"C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs\vizqlserver\vizqlserver_node1-0.log","longRunningTransactions.CheckFrequencySeconds":"300","longRunningTransactions.LongRunningWarningThresholdSeconds":"60","longRunningTransactions.TransactionStuckAlertThresholdSeconds":"600","maestro.featureFlags.futureFeature":"false","maestro.input.allowed_paths":"","maestro.output.allowed_paths":"","maestro.server_bin_path":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/services/vizqlserver_0.20192.20.0218.0709/bin","maestro.show_allowed_paths":"true","managed_keychain.ttl_in_sec":"21600","managed_keychains.enable_cache":"false","managed_keychains.max_cache_size":"100","materializedViews.BloomFilterBuildPeriod":"10","materializedViews.MaxBatchSubmissionCount":"100","materializedViews.WebAuthoringBatchHoldMinutes":"10","materializedViews.max_allowed_percentage_of_hyper_memory":"50","materializedViews.max_query_cache_entry_size_in_kb":"262144","max_allowed_document_version":"","messagebus.config.topics.dir":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/config/vizqlserver_0.20192.20.0218.0709/messagebus/topics","messagebus.core.messageRetentionTimeInMinutes":"2880","messagebus.core.messageSizeLimitKb":"10","messagebus.subscriber.longPollSeconds":"20","messagebus.subscriber.maxRetryCount":"100","messagebus.subscriber.sessionTimeoutSeconds":"60","metadata.service.graphdb.type":"sqlg","metadatasearchquery.procs":"0","metadatasearchquery.vmopts":"-XX:+UseConcMarkSweepGC -Xmx128m -XX:+ExitOnOutOfMemoryError","metricsservices.authoring.enabled":"false","mode.standalone.enabled":"true","mongrel.tcpqueue.length":"100","monitoring.dataengine.connection_timeout":"30000","monitoring.hyper.connection_timeout":"30000","monitoring.initial_delay":"20","monitoring.interval":"6","monitoring.num_threads":"2","monitoring.shutdown_delay":"5","monitoring.time_period":"60","monitoring.up_percentage":"0","native_api.MaterializedViewMaxNumConnectionsForCacheWarming":"10","native_api.MaterializedViewMinQueryExecutionDurationThresholdInMs":"500","native_api.MaterializedViewQueryExecutionDurationToLoadingRatioInPercentage":"200","native_api.MaterializedViewQueryExecutionDurationToLoadingRatioInPercentageForSpatialData":"240","native_api.MaterializedViewQueryResultReductionRatioInPercentage":"90","native_api.MemberIdentityValidationEnabled":"true","native_api.MemberIdentityValidationMaxBlockDepth":"10","native_api.UseAlternativeFederationEngine":"true","native_api.allowed_paths":"*","native_api.connect_plugins_path":"C:/insightedge-connector","native_api.cpu_use_average":"false","native_api.default_cache_timeout_minutes":"720","native_api.device_specific_dashboard_phone_size":"500","native_api.device_specific_dashboard_tablet_size":"800","native_api.external_cache.use_timestamp":"true","native_api.external_cache_disable":"false","native_api.internal_disallowed_paths":"C:/Program Files/Tableau/Tableau Server; C:/ProgramData/Tableau/Tableau Server","native_api.java_home":"C:/ProgramData/Tableau/Tableau Server/data/tabsvc/services/vizqlserver_0.20192.20.0218.0709/repository/jre"}}
Regards
Max

Can you see the connector listed in the connector list in your tableau server?

Is this what you mean?
C:\Users\Administrator>tsm configuration get -k native_api.connect_plugins_path
C:/insightedge-connector
C:\Users\Administrator>dir c:\insightedge-connector
Volume in drive C has no label.
Volume Serial Number is 14D2-3798
Directory of c:\insightedge-connector
03/04/2020  01:02 PM              .
03/04/2020  01:02 PM              ..
01/29/2020  01:03 PM               212 ._connection-dialog.tcd
01/29/2020  01:03 PM               212 ._connectionBuilder.js
01/29/2020  01:03 PM               212 ._connectionRequired.js
01/29/2020  01:03 PM               212 ._connectionResolver.tdr
01/29/2020  01:03 PM               212 ._dialect.tdd
01/29/2020  01:03 PM               212 ._manifest.xml
01/29/2020  01:03 PM               586 connection-dialog.tcd
01/29/2020  01:03 PM               930 connectionBuilder.js
01/29/2020  01:03 PM               199 connectionRequired.js
01/29/2020  01:03 PM               356 connectionResolver.tdr
01/29/2020  01:03 PM               857 dialect.tdd
01/29/2020  01:03 PM             1,743 manifest.xml
12 File(s)          5,943 bytes
2 Dir(s)   6,336,880,640 bytes free

Hello
I was suggested to change the directory structure where the connector files were placed and copied the files into a folder under the directory configured as native_api.connect_plugins_path.
After applying the changes and clicking "Publish data source" I was forwarded to the Tableau Server web page. First, I got the message saying that the data source was successfully published, but then I was prompted to provide credentials required for accessing the data source.
The request for credentials comes regardless of the security settings configured on the data source site and in all cases, I receive the error outlined below.
An unexpected error occurred. If you continue to receive this error please contact your Tableau Server Administrator.
Session ID: 195E3126122D409F989D467A82EC86EF-1:0
java.lang.RuntimeException: Error instantiating JsonCustomSchema(name=processorSpace)
There was a Java error.
Unable to connect to the Gigaspaces InsightEdge server "<IP_ADDRESS>". Check that the server is running and that you have access privileges to the requested database.
DataServiceFailure
There was an error with the data source "Orders (processorSpace)". Verify that the data source is configured correctly.

Please advice.
Regards
Mad

tfs 1197820

the request for credentials is not related to the issue discussed in this ticket.
Changing the directory structure was the solution in our case.
Closing


feature request：load the config should log the load source by debug level

When pydantic loads the configuration, it records what data source the configuration is read from, and provides debug-level log output.i think if the feature is added, this library will work better.
By reading the source code, I found that it is currently unable to support recording the configuration source. This can be achieved by encapsulating the chainmap, or by adding an additional dict to record. Due to my limited level, I am afraid that direct modification of the source code will not completely cover it. testing, thus introducing more bugs, so I hope the development team can add this feature.

I tried to submit the code to pydantic v1, and later found that the development team separated the setting from pydantic into a sub-project

Yeah. pydantic-settings is a separate package after V2
Yeah deep_update is in Pydantic package and pydantic-settings used it. it will be deprecated in V2 and we might need to move it to pydantic-settings.
I think even by changing the deep_update it is hard to say the field value comes from which source. Consider the following field:
a: int = Field(validation_alias='a_alias')

and two sources with these values:
s1 = {'a': 1}
s2 = {'a_alias': 2}

deep_update returns a dict like {'a': 1, 'a_alias': 2}. Do you know at this point which value has to be selected for the field? you may find it but I am afraid it would be complicated.
At the end Pydantic validates the data and selects data for fields (based on field_name, alias, alias_generator, and some config).

We may can log values loaded from sources and at the end log the final values that has to be passed to pydantic. something like:
DEBUG    pydantic_settings.main:main.py:120 {'foo': 'foo_secret_value_str'} loaded from SecretsSettingsSource
DEBUG    pydantic_settings.main:main.py:120 {'foo': 'foo_env_value_str'} loaded from DotEnvSettingsSource
DEBUG    pydantic_settings.main:main.py:120 {} loaded from EnvSettingsSource
DEBUG    pydantic_settings.main:main.py:120 {} loaded from InitSettingsSource
DEBUG    pydantic_settings.main:main.py:123 {'foo': 'foo_env_value_str'} is the final settings values

we can easily have it by
diff --git a/pydantic_settings/main.py b/pydantic_settings/main.py
index 88478f1..05a7f5a 100644
--- a/pydantic_settings/main.py
+++ b/pydantic_settings/main.py
@@ -1,5 +1,6 @@
 from __future__ import annotations as _annotations

+import logging
 from pathlib import Path
 from typing import Any

@@ -18,6 +19,8 @@ from .sources import (

 env_file_sentinel: DotenvType = Path('')

+log = logging.getLogger(__name__)
+

 class SettingsConfigDict(ConfigDict):
     case_sensitive: bool
@@ -111,7 +114,14 @@ class BaseSettings(BaseModel):
             file_secret_settings=file_secret_settings,
         )
         if sources:
-            return deep_update(*reversed([source() for source in sources]))
+            sources_values = []
+            for source in reversed(sources):
+                source_values = source()
+                log.debug(f'{source_values} loaded from {source.__class__.__name__}')
+                sources_values.append(source_values)
+            values = deep_update(*sources_values)
+            log.debug(f'{values} is the final settings values')
+            return values
         else:
             # no one should mean to do this, but I think returning an empty dict is marginally preferable
             # to an informative error and much better than a confusing error

But let's wait for @samuelcolvin opinion here

like what I did by my pr

alias may also need to be considered

Considering alias is complicated. the alias will be handled in environment variables sources. but in other sources, it doesn't.
for example if we have a settings model like:
class Settings(BaseSettings):
    x: int = Field(validation_alias='alias_x')

and env variables:
os.environ['x'] = '1'
os.environ['alias_x'] = '2'

and call the settings like:
Settings(**{'x': 3, 'alias_x': 4})

Then, InitSettingsSource source returns {'x': 3, 'alias_x': 4} and EnvSettingsSource returns {'alias_x': '2'}. You can see that EnvSettingsSource only returns the value for alias.
BTW, I still think the logging shouldn't be too complicated and we only need to log values loaded from sources based on priority.

Considering alias is complicated. the alias will be handled in environment variables sources. but in other sources, it doesn't.
for example if we have a settings model like:
class Settings(BaseSettings):
    x: int = Field(validation_alias='alias_x')

and env variables:
os.environ['x'] = '1'
os.environ['alias_x'] = '2'

and call the settings like:
Settings(**{'x': 3, 'alias_x': 4})

Then, InitSettingsSource source returns {'x': 3, 'alias_x': 4} and EnvSettingsSource returns {'alias_x': '2'}. You can see that EnvSettingsSource only returns the value for alias.
BTW, I still think the logging shouldn't be too complicated and we only need to log values loaded from sources based on priority.

When it comes to aliases, we only need to briefly test them. If x has an alias_x, consider the following situations: 1. Whether x and alias_x appear at the same time, and can only be assigned when they are equal at the same time; 2. and 1 is similar, but if it is not equal, is a certain value preferred? 3. Can x and alias_x be assigned as long as they appear in one data source?
Haha, about whether the log is too complicated, in fact, my pr is not much different from your code above, just take the intersection of the two lists, and you can know what appears in those data sources without excessively introducing complicated methods The corresponding key, but maybe some case processing is required?

#68 is my pr

After talking with our team(Pydantic team), we decided to go for a simple logging approach. The one that I suggested here.
Please open a PR with the proposed diff and provide some test for it if you want to work on it.


Fix workflow podvm builds

I've run tests for creating the builders using act.
Still running through the rest but it is a slow process.

Using the make targets for the steps, so that is grabs the versions
Added back in the cloud-provider specific image builds for the vsphere build
Minor clean up of the workflow

can we trigger a test run for this change?

can we trigger these workflows to test the change?

created release https://github.com/jtumber-ibm/cloud-api-adaptor/tree/v0.8.0-alpha.3 on my fork to run the builds,
podvm_builder action: https://github.com/jtumber-ibm/cloud-api-adaptor/actions/runs/6733038159
podvm_binaries action: https://github.com/jtumber-ibm/cloud-api-adaptor/actions/runs/6733145029

~CI passed on your fork, changes look good, thanks! :)~

Image build step failed, the centos failure was due to some missing changes from the remote->local updates. Which I have included in this PR. The other failures were due to authentication errors against dockerhub. Not 100% why as it was autenticated for the other images

Do we need to add hold on this PR until we've resolved the centos issues to ensure we don't break anything (though it might already be broken)?

depends if centos is a blocker for the release.
@katexochen you can see the image build here with the latest updates https://github.com/jtumber-ibm/cloud-api-adaptor/actions/runs/6734612356 (+some required changes just to get it running from my fork)

depends if centos is a blocker for the release.

Good point. I think the RH team are staying on 0.7 for the moment. @bpradipt should the centos build block us for 0.8, and the answer yes is fine!

depends if centos is a blocker for the release.

Good point. I think the RH team are staying on 0.7 for the moment. @bpradipt should the centos build block us for 0.8, and the answer yes is fine!

We have tested the latest build with RHEL9 successfully. Didn't get time to test with CentOS, but it's not a blocker. Please proceed with the release.
Also can you please point me to the CentOS failure. I couldn't find it :-(

Also can you please point me to the CentOS failure. I couldn't find it :-(

It's on JT's fork: https://github.com/jtumber-ibm/cloud-api-adaptor/actions/runs/6734612356/job/18305896782


python312Packages.colored-traceback: 0.3.0 -> 0.4.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.colored-traceback is: Automatically color Python's uncaught exception tracebacks
meta.homepage for python312Packages.colored-traceback is: https://github.com/staticshock/colored-traceback.py
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.4.0 with grep in /nix/store/qlwmwy54viys8yyh3lw46m9dm8k1v8vv-python3.12-colored-traceback-0.4.0
found 0.4.0 in filename of file in /nix/store/qlwmwy54viys8yyh3lw46m9dm8k1v8vv-python3.12-colored-traceback-0.4.0

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath

python311Packages.colored-traceback
python311Packages.pwndbg
python311Packages.pwntools
python312Packages.colored-traceback

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qlwmwy54viys8yyh3lw46m9dm8k1v8vv-python3.12-colored-traceback-0.4.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python312Packages.colored-traceback https://github.com/r-ryantm/nixpkgs/archive/037d77e3147fbd417ca9c5c0e2d00fe2a532e663.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/037d77e3147fbd417ca9c5c0e2d00fe2a532e663#python312Packages.colored-traceback

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qlwmwy54viys8yyh3lw46m9dm8k1v8vv-python3.12-colored-traceback-0.4.0
ls -la /nix/store/qlwmwy54viys8yyh3lw46m9dm8k1v8vv-python3.12-colored-traceback-0.4.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

13 packages built:

pwndbg
pwntools (python312Packages.pwntools)
pwntools.dist (python312Packages.pwntools.dist)
python311Packages.colored-traceback
python311Packages.colored-traceback.dist
python311Packages.pwndbg
python311Packages.pwndbg.dist
python311Packages.pwntools
python311Packages.pwntools.dist
python312Packages.colored-traceback
python312Packages.colored-traceback.dist
python312Packages.pwndbg
python312Packages.pwndbg.dist

Maintainer pings
cc @Pamplemousse for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.colored-traceback is: Automatically color Python's uncaught exception tracebacks
meta.homepage for python312Packages.colored-traceback is: https://github.com/staticshock/colored-traceback.py
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.4.1 with grep in /nix/store/95bsja5a7r0w5mw86kzxhjv0zqpjrln2-python3.12-colored-traceback-0.4.1
found 0.4.1 in filename of file in /nix/store/95bsja5a7r0w5mw86kzxhjv0zqpjrln2-python3.12-colored-traceback-0.4.1

Rebuild report (if merged into master) (click to expand)

9 total rebuild path(s)

9 package rebuild(s)

First fifty rebuilds by attrpath

pwndbg
pwntools
python311Packages.colored-traceback
python311Packages.pwndbg
python311Packages.pwntools
python312Packages.colored-traceback
python312Packages.pwndbg
python312Packages.pwntools

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/95bsja5a7r0w5mw86kzxhjv0zqpjrln2-python3.12-colored-traceback-0.4.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python312Packages.colored-traceback https://github.com/r-ryantm/nixpkgs/archive/96cd2a214a8b2e22f63100c1e3137ad0f34f8f65.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/96cd2a214a8b2e22f63100c1e3137ad0f34f8f65#python312Packages.colored-traceback

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/95bsja5a7r0w5mw86kzxhjv0zqpjrln2-python3.12-colored-traceback-0.4.1
ls -la /nix/store/95bsja5a7r0w5mw86kzxhjv0zqpjrln2-python3.12-colored-traceback-0.4.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

13 packages built:

pwndbg
pwntools (python312Packages.pwntools)
pwntools.dist (python312Packages.pwntools.dist)
python311Packages.colored-traceback
python311Packages.colored-traceback.dist
python311Packages.pwndbg
python311Packages.pwndbg.dist
python311Packages.pwntools
python311Packages.pwntools.dist
python312Packages.colored-traceback
python312Packages.colored-traceback.dist
python312Packages.pwndbg
python312Packages.pwndbg.dist

Maintainer pings
cc @Pamplemousse for testing.

Result of nixpkgs-review pr 326133 run on aarch64-linux 1

13 packages built:

pwndbg
pwntools (python312Packages.pwntools)
pwntools.dist (python312Packages.pwntools.dist)
python311Packages.colored-traceback
python311Packages.colored-traceback.dist
python311Packages.pwndbg
python311Packages.pwndbg.dist
python311Packages.pwntools
python311Packages.pwntools.dist
python312Packages.colored-traceback
python312Packages.colored-traceback.dist
python312Packages.pwndbg
python312Packages.pwndbg.dist

Result of nixpkgs-review pr 326133 run on aarch64-darwin 1

1 package marked as broken and skipped:

pwndbg

12 packages built:

pwntools (python312Packages.pwntools)
pwntools.dist (python312Packages.pwntools.dist)
python311Packages.colored-traceback
python311Packages.colored-traceback.dist
python311Packages.pwndbg
python311Packages.pwndbg.dist
python311Packages.pwntools
python311Packages.pwntools.dist
python312Packages.colored-traceback
python312Packages.colored-traceback.dist
python312Packages.pwndbg
python312Packages.pwndbg.dist


E722 do not use bare except

flake8 E722
add py37 to tox

Coverage remained the same at 92.759% when pulling 59f8a78433b1bfcd88a20862c53ddae3af6f9404 on piotr1212:E722 into 7a26cef1cc713ef2642c08785281a3650f28288e on graphite-project:master.

Coverage remained the same at 92.759% when pulling 59f8a78433b1bfcd88a20862c53ddae3af6f9404 on piotr1212:E722 into 7a26cef1cc713ef2642c08785281a3650f28288e on graphite-project:master.

Coverage remained the same at 92.759% when pulling 59f8a78433b1bfcd88a20862c53ddae3af6f9404 on piotr1212:E722 into 7a26cef1cc713ef2642c08785281a3650f28288e on graphite-project:master.

Coverage remained the same at 92.759% when pulling 59f8a78433b1bfcd88a20862c53ddae3af6f9404 on piotr1212:E722 into 7a26cef1cc713ef2642c08785281a3650f28288e on graphite-project:master.

Thanks! Merging