Breakpoint in specific function causes the debug process to deadlock

OS: Ubuntu 20.04.1 LTS
VSCode version: Version: 1.57.1 (Also reproduced in 1.58.2)
Extension version: 1.6.5
Compiler: rustc 1.49.0 (e1884a8e3 2020-12-29) (NB: Also tested when using latest rustc 1.54.0 (a178d0322 2021-07-26))
Build target: 1.49-x86_64-unknown-linux-gnu

While debugging a integration test, we encounter that a breakpoint placed within a random, but specific function will not trigger the breakpoint but instead just stop and deadlock the entire process. Using breakpoints elsewhere in the code base or integration tests does not trigger this error.
The process is after the line
log: INFO - FOOBAR

Debug log
configuration: {
  type: 'lldb',
  request: 'launch',
  name: 'test it_commits_dirty_targets',
  program: '${workspaceFolder}/target/debug/deps/it_commits_dirty_targets-d584e243daf3f578',
  args: [ 'it_commits_dirty_targets', '--exact', '--nocapture' ],
  cwd: '${workspaceFolder}',
  sourceMap: {},
  sourceLanguages: [ 'rust' ],
  env: {
    RUST_BACKTRACE: 'short',
    LANGUAGE: 'en_US',
    USER: 'morten',
    SSH_CLIENT: '<IP_ADDRESS> 52837 22',
    LC_TIME: 'en_DK.UTF-8',
    XDG_SESSION_TYPE: 'tty',
    SHLVL: '1',
    MOTD_SHOWN: 'pam',
    HOME: '/home/morten',
    LC_MONETARY: 'en_DK.UTF-8',
    LC_CTYPE: 'C.UTF-8',
    DBUS_SESSION_BUS_ADDRESS: 'unix:path=/run/user/1000/bus',
    LOGNAME: 'morten',
    _: '/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/node',
    XDG_SESSION_CLASS: 'user',
    XDG_SESSION_ID: '9071',
    PATH: '/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/bin:/home/morten/.nvm/versions/node/v12.22.1/bin:/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/bin:/home/morten/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin',
    VSCODE_AGENT_FOLDER: '/home/morten/.vscode-server',
    PAPERSIZE: 'a4',
    LC_ADDRESS: 'en_DK.UTF-8',
    XDG_RUNTIME_DIR: '/run/user/1000',
    LANG: 'C.UTF-8',
    LC_TELEPHONE: 'en_DK.UTF-8',
    SHELL: '/bin/bash',
    LC_NAME: 'en_DK.UTF-8',
    LC_MEASUREMENT: 'en_DK.UTF-8',
    LC_IDENTIFICATION: 'en_DK.UTF-8',
    PWD: '/home/morten',
    SSH_CONNECTION: '<IP_ADDRESS> 52837 <IP_ADDRESS> 22',
    XDG_DATA_DIRS: '/usr/local/share:/usr/share:/var/lib/snapd/desktop',
    LC_NUMERIC: 'en_DK.UTF-8',
    LC_PAPER: 'en_DK.UTF-8',
    VSCODE_INJECT_NODE_MODULE_LOOKUP_PATH: '/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/remote/node_modules',
    VSCODE_CWD: '/home/morten',
    NVM_INC: '/home/morten/.nvm/versions/node/v12.22.1/include/node',
    LS_COLORS: '',
    NVM_DIR: '/home/morten/.nvm',
    LESSCLOSE: '/usr/bin/lesspipe %s %s',
    LESSOPEN: '| /usr/bin/lesspipe %s',
    NVM_CD_FLAGS: '',
    NVM_BIN: '/home/morten/.nvm/versions/node/v12.22.1/bin',
    VSCODE_LOG_NATIVE: 'false',
    VSCODE_AMD_ENTRYPOINT: 'vs/server/remoteExtensionHostProcess',
    VSCODE_PIPE_LOGGING: 'true',
    VSCODE_VERBOSE_LOGGING: 'true',
    VSCODE_EXTHOST_WILL_SEND_SOCKET: 'true',
    VSCODE_HANDLES_UNCAUGHT_ERRORS: 'true',
    VSCODE_LOG_STACK: 'false',
    VSCODE_NLS_CONFIG: '{"locale":"en","availableLanguages":{}}',
    BROWSER: '/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/bin/helpers/browser.sh',
    VSCODE_IPC_HOOK_CLI: '/run/user/1000/vscode-ipc-3e1c77e3-eea5-4603-9700-89be364c34b0.sock',
    APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL: 'true'
  },
  relativePathBase: '/home/morten/cc/firmware_hal'
}
liblldb: /home/morten/.vscode-server/extensions/vadimcn.vscode-lldb-1.6.5/lldb/lib/liblldb.so
environment: {}
params: {
  evaluateForHovers: true,
  commandCompletions: true,
  sourceLanguages: [ 'rust' ]
}
Listening on port 35603
[2021-08-04T08:34:41.220Z DEBUG codelldb] New debug session
INFO(Python) 10:34:41 formatters: Initializing
INFO(Python) 10:34:41 formatters.rust: Initializing
[2021-08-04T08:34:41.481Z DEBUG codelldb::dap_codec] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-gb","supportsProgressReporting":true,"supportsInvalidatedEvent":true},"type":"request","seq":1}
[2021-08-04T08:34:41.482Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"rust_panic","label":"Rust: on panic"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2021-08-04T08:34:41.572Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"test it_commits_dirty_targets","program":"/home/morten/cc/firmware_hal/target/debug/deps/it_commits_dirty_targets-d584e243daf3f578","args":["it_commits_dirty_targets","--exact","--nocapture"],"cwd":"/home/morten/cc/firmware_hal","sourceMap":{},"sourceLanguages":["rust"],"env":{"RUST_BACKTRACE":"short","LANGUAGE":"en_US","USER":"morten","SSH_CLIENT":"<IP_ADDRESS> 52837 22","LC_TIME":"en_DK.UTF-8","XDG_SESSION_TYPE":"tty","SHLVL":"1","MOTD_SHOWN":"pam","HOME":"/home/morten","LC_MONETARY":"en_DK.UTF-8","LC_CTYPE":"C.UTF-8","DBUS_SESSION_BUS_ADDRESS":"unix:path=/run/user/1000/bus","LOGNAME":"morten","_":"/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/node","XDG_SESSION_CLASS":"user","XDG_SESSION_ID":"9071","PATH":"/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/bin:/home/morten/.nvm/versions/node/v12.22.1/bin:/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/bin:/home/morten/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin","VSCODE_AGENT_FOLDER":"/home/morten/.vscode-server","PAPERSIZE":"a4","LC_ADDRESS":"en_DK.UTF-8","XDG_RUNTIME_DIR":"/run/user/1000","LANG":"C.UTF-8","LC_TELEPHONE":"en_DK.UTF-8","SHELL":"/bin/bash","LC_NAME":"en_DK.UTF-8","LC_MEASUREMENT":"en_DK.UTF-8","LC_IDENTIFICATION":"en_DK.UTF-8","PWD":"/home/morten","SSH_CONNECTION":"<IP_ADDRESS> 52837 <IP_ADDRESS> 22","XDG_DATA_DIRS":"/usr/local/share:/usr/share:/var/lib/snapd/desktop","LC_NUMERIC":"en_DK.UTF-8","LC_PAPER":"en_DK.UTF-8","VSCODE_INJECT_NODE_MODULE_LOOKUP_PATH":"/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/remote/node_modules","VSCODE_CWD":"/home/morten","NVM_INC":"/home/morten/.nvm/versions/node/v12.22.1/include/node","LS_COLORS":"","NVM_DIR":"/home/morten/.nvm","LESSCLOSE":"/usr/bin/lesspipe %s %s","LESSOPEN":"| /usr/bin/lesspipe %s","NVM_CD_FLAGS":"","NVM_BIN":"/home/morten/.nvm/versions/node/v12.22.1/bin","VSCODE_LOG_NATIVE":"false","VSCODE_AMD_ENTRYPOINT":"vs/server/remoteExtensionHostProcess","VSCODE_PIPE_LOGGING":"true","VSCODE_VERBOSE_LOGGING":"true","VSCODE_EXTHOST_WILL_SEND_SOCKET":"true","VSCODE_HANDLES_UNCAUGHT_ERRORS":"true","VSCODE_LOG_STACK":"false","VSCODE_NLS_CONFIG":"{\"locale\":\"en\",\"availableLanguages\":{}}","BROWSER":"/home/morten/.vscode-server/bin/507ce72a4466fbb27b715c3722558bb15afa9f48/bin/helpers/browser.sh","VSCODE_IPC_HOOK_CLI":"/run/user/1000/vscode-ipc-3e1c77e3-eea5-4603-9700-89be364c34b0.sock","APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL":"true"},"relativePathBase":"/home/morten/cc/firmware_hal","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null,"evaluateForHovers":true,"commandCompletions":true},"__sessionId":"eba6aa2c-ef6b-4a75-b56d-9a05b6600907"},"type":"request","seq":2}
[2021-08-04T08:34:41.573Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":1,"event":"capabilities","body":{"capabilities":{"exceptionBreakpointFilters":[{"default":true,"filter":"rust_panic","label":"Rust: on panic"}],"supportTerminateDebuggee":true,"supportsCancelRequest":true,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsReadMemoryRequest":true,"supportsRestartFrame":true,"supportsSetVariable":true}}}
[2021-08-04T08:34:41.826Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":2,"event":"initialized"}
[2021-08-04T08:34:41.826Z DEBUG codelldb::dap_codec] <-- {"type":"request","seq":3,"command":"runInTerminal","arguments":{"args":["/home/morten/.vscode-server/extensions/vadimcn.vscode-lldb-1.6.5/adapter/codelldb","terminal-agent","--port=41409"],"cwd":"","kind":"integrated","title":"test it_commits_dirty_targets"}}
[2021-08-04T08:34:41.903Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"ccupd.rs","path":"/home/morten/cc/firmware_hal/update/src/ccupd.rs"},"lines":[],"breakpoints":[],"sourceModified":false},"type":"request","seq":3}
[2021-08-04T08:34:41.903Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"it_commits_dirty_targets.rs","path":"/home/morten/cc/firmware_hal/update/tests/it_commits_dirty_targets.rs"},"lines":[114],"breakpoints":[{"line":114}],"sourceModified":false},"type":"request","seq":4}
[2021-08-04T08:34:41.903Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[]}}
[2021-08-04T08:34:41.903Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"manager.rs","path":"/home/morten/cc/firmware_hal/update/src/manager.rs"},"lines":[266],"breakpoints":[{"line":266}],"sourceModified":false},"type":"request","seq":5}
[2021-08-04T08:34:41.956Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":4,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":114,"message":"Locations: 1","verified":true}]}}
[2021-08-04T08:34:41.959Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":5,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":2,"line":266,"message":"Locations: 2","verified":true}]}}
[2021-08-04T08:34:42.053Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":6,"command":"runInTerminal","request_seq":3,"success":true,"body":{"shellProcessId":3718294}}
[2021-08-04T08:34:42.188Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":7}
[2021-08-04T08:34:42.189Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":7,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2021-08-04T08:34:42.304Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":8}
[2021-08-04T08:34:42.304Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":8,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2021-08-04T08:34:42.442Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["rust_panic"]},"type":"request","seq":9}
[2021-08-04T08:34:42.451Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":9,"success":true,"command":"setExceptionBreakpoints"}
[2021-08-04T08:34:42.524Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":10}
[2021-08-04T08:34:42.524Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":10,"success":true,"command":"configurationDone"}
[2021-08-04T08:34:42.525Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"output":"Launching: /home/morten/cc/firmware_hal/target/debug/deps/it_commits_dirty_targets-d584e243daf3f578 it_commits_dirty_targets --exact --nocapture\n"}}
[2021-08-04T08:34:42.598Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":11}
[2021-08-04T08:34:43.236Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":5,"event":"output","body":{"output":"Launched process 3720387\n"}}
[2021-08-04T08:34:43.236Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":2,"success":true,"command":"launch"}
[2021-08-04T08:34:43.236Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":11,"success":true,"command":"threads","body":{"threads":[{"id":3720387,"name":"1: tid=3720387 \"it_commits_dirt\""}]}}
[2021-08-04T08:34:43.236Z DEBUG codelldb::debug_session] Debug event: 0x56170037a1b0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {ld-2.31.so}
[2021-08-04T08:34:43.236Z DEBUG codelldb::debug_session] Debug event: 0x5617004012a0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {[vdso](0x00007ffff7fcd000)}
[2021-08-04T08:34:43.236Z DEBUG codelldb::debug_session] Debug event: 0x561700365b70 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-08-04T08:34:43.236Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":6,"event":"module","body":{"module":{"addressRange":"7FFFF7FCF000","id":"7FFFF7FCF000","name":"ld-2.31.so","path":"/usr/lib/x86_64-linux-gnu/ld-2.31.so","symbolFilePath":"/usr/lib/x86_64-linux-gnu/ld-2.31.so","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.236Z DEBUG codelldb::debug_session] Debug event: 0x561700365ce0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-08-04T08:34:43.236Z DEBUG codelldb::debug_session] Debug event: 0x56170037fc40 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-08-04T08:34:43.236Z DEBUG codelldb::debug_session] Debug event: 0x56170037fe60 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-08-04T08:34:43.236Z DEBUG codelldb::debug_session] Debug event: 0x5617003800a0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {it_commits_dirty_targets-d584e243daf3f578}
[2021-08-04T08:34:43.236Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":7,"event":"module","body":{"module":{"addressRange":"7FFFF7FCD000","id":"7FFFF7FCD000","name":"[vdso]","path":"[vdso]","symbolStatus":"Symbols not found"},"reason":"new"}}
[2021-08-04T08:34:43.236Z DEBUG codelldb::debug_session] Debug event: 0x5617003f9cf0 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = running}
[2021-08-04T08:34:43.236Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":8,"event":"module","body":{"module":{"addressRange":"555555554000","id":"555555554000","name":"it_commits_dirty_targets-d584e243daf3f578","path":"/home/morten/cc/firmware_hal/target/debug/deps/it_commits_dirty_targets-d584e243daf3f578","symbolFilePath":"/home/morten/cc/firmware_hal/target/debug/deps/it_commits_dirty_targets-d584e243daf3f578","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.236Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":9,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2021-08-04T08:34:43.238Z DEBUG codelldb::debug_session] Debug event: 0x7fa688da6ba0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {ld-linux-x86-64.so.2}
[2021-08-04T08:34:43.238Z DEBUG codelldb::debug_session] Debug event: 0x7fa6887d7a60 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-08-04T08:34:43.238Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":10,"event":"module","body":{"module":{"addressRange":"FFFFFFFFFFFFFFFF","id":"FFFFFFFFFFFFFFFF","name":"ld-linux-x86-64.so.2","path":"/lib64/ld-linux-x86-64.so.2","symbolFilePath":"/lib64/ld-linux-x86-64.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.238Z DEBUG codelldb::debug_session] Debug event: 0x7fa689348470 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-08-04T08:34:43.238Z DEBUG codelldb::debug_session] Debug event: 0x7fa689348520 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-08-04T08:34:43.238Z DEBUG codelldb::debug_session] Debug event: 0x7fa688da4570 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {[vdso](0x00007ffff7fcd000)}
[2021-08-04T08:34:43.238Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":11,"event":"module","body":{"module":{"addressRange":"7FFFF7FCD000","id":"7FFFF7FCD000","name":"[vdso]","path":"[vdso]","symbolStatus":"Symbols not found"},"reason":"new"}}
[2021-08-04T08:34:43.242Z DEBUG codelldb::debug_session] Debug event: 0x7fa688d883d0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libdbus-1.so.3}
[2021-08-04T08:34:43.243Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":12,"event":"module","body":{"module":{"addressRange":"7FFFF7F65000","id":"7FFFF7F65000","name":"libdbus-1.so.3","path":"/lib/x86_64-linux-gnu/libdbus-1.so.3","symbolFilePath":"/lib/x86_64-linux-gnu/libdbus-1.so.3","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.243Z DEBUG codelldb::debug_session] Debug event: 0x7fa688da6ba0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libgcc_s.so.1}
[2021-08-04T08:34:43.243Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":13,"event":"module","body":{"module":{"addressRange":"7FFFF7F4A000","id":"7FFFF7F4A000","name":"libgcc_s.so.1","path":"/lib/x86_64-linux-gnu/libgcc_s.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/libgcc_s.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.244Z DEBUG codelldb::debug_session] Debug event: 0x7fa688d935a0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {librt.so.1}
[2021-08-04T08:34:43.244Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":14,"event":"module","body":{"module":{"addressRange":"7FFFF7F3F000","id":"7FFFF7F3F000","name":"librt.so.1","path":"/lib/x86_64-linux-gnu/librt.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/librt.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.264Z DEBUG codelldb::debug_session] Debug event: 0x7fa6894868c0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libpthread.so.0}
[2021-08-04T08:34:43.264Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":15,"event":"module","body":{"module":{"addressRange":"7FFFF7F1C000","id":"7FFFF7F1C000","name":"libpthread.so.0","path":"/lib/x86_64-linux-gnu/libpthread.so.0","symbolFilePath":"/usr/lib/debug/.build-id/4f/c5fc33f4429136a494c640b113d76f610e4abc.debug","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.266Z DEBUG codelldb::debug_session] Debug event: 0x7fa68948a6e0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libm.so.6}
[2021-08-04T08:34:43.266Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":16,"event":"module","body":{"module":{"addressRange":"7FFFF7DCD000","id":"7FFFF7DCD000","name":"libm.so.6","path":"/lib/x86_64-linux-gnu/libm.so.6","symbolFilePath":"/lib/x86_64-linux-gnu/libm.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.267Z DEBUG codelldb::debug_session] Debug event: 0x7fa6894b6580 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libdl.so.2}
[2021-08-04T08:34:43.267Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":17,"event":"module","body":{"module":{"addressRange":"7FFFF7DC7000","id":"7FFFF7DC7000","name":"libdl.so.2","path":"/lib/x86_64-linux-gnu/libdl.so.2","symbolFilePath":"/lib/x86_64-linux-gnu/libdl.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.271Z DEBUG codelldb::debug_session] Debug event: 0x7fa689672c10 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libc.so.6}
[2021-08-04T08:34:43.271Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":18,"event":"module","body":{"module":{"addressRange":"7FFFF7BD3000","id":"7FFFF7BD3000","name":"libc.so.6","path":"/lib/x86_64-linux-gnu/libc.so.6","symbolFilePath":"/lib/x86_64-linux-gnu/libc.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.273Z DEBUG codelldb::debug_session] Debug event: 0x7fa68947daa0 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libsystemd.so.0}
[2021-08-04T08:34:43.273Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":19,"event":"module","body":{"module":{"addressRange":"7FFFF7B24000","id":"7FFFF7B24000","name":"libsystemd.so.0","path":"/lib/x86_64-linux-gnu/libsystemd.so.0","symbolFilePath":"/lib/x86_64-linux-gnu/libsystemd.so.0","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.274Z DEBUG codelldb::debug_session] Debug event: 0x7fa6897b7370 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {liblzma.so.5}
[2021-08-04T08:34:43.274Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":20,"event":"module","body":{"module":{"addressRange":"7FFFF7AFB000","id":"7FFFF7AFB000","name":"liblzma.so.5","path":"/lib/x86_64-linux-gnu/liblzma.so.5","symbolFilePath":"/lib/x86_64-linux-gnu/liblzma.so.5","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.274Z DEBUG codelldb::debug_session] Debug event: 0x7fa68975d160 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {liblz4.so.1}
[2021-08-04T08:34:43.274Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":21,"event":"module","body":{"module":{"addressRange":"7FFFF7ADA000","id":"7FFFF7ADA000","name":"liblz4.so.1","path":"/lib/x86_64-linux-gnu/liblz4.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/liblz4.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.276Z DEBUG codelldb::debug_session] Debug event: 0x7fa689035020 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libgcrypt.so.20}
[2021-08-04T08:34:43.276Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":22,"event":"module","body":{"module":{"addressRange":"7FFFF79BC000","id":"7FFFF79BC000","name":"libgcrypt.so.20","path":"/lib/x86_64-linux-gnu/libgcrypt.so.20","symbolFilePath":"/lib/x86_64-linux-gnu/libgcrypt.so.20","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.277Z DEBUG codelldb::debug_session] Debug event: 0x7fa68975d160 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libgpg-error.so.0}
[2021-08-04T08:34:43.277Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":23,"event":"module","body":{"module":{"addressRange":"7FFFF7997000","id":"7FFFF7997000","name":"libgpg-error.so.0","path":"/lib/x86_64-linux-gnu/libgpg-error.so.0","symbolFilePath":"/lib/x86_64-linux-gnu/libgpg-error.so.0","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::debug_session] Debug event: 0x7fa688d88600 Event: broadcaster = 0x5616fdbf8e58 (lldb.target), type = 0x00000002 (modules-loaded), data = {libdbus-1.so.3, libgcc_s.so.1, librt.so.1, libpthread.so.0, libm.so.6, libdl.so.2, libc.so.6, libsystemd.so.0, liblzma.so.5, liblz4.so.1, libgcrypt.so.20, libgpg-error.so.0}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":24,"event":"module","body":{"module":{"addressRange":"7FFFF7F65000","id":"7FFFF7F65000","name":"libdbus-1.so.3","path":"/lib/x86_64-linux-gnu/libdbus-1.so.3","symbolFilePath":"/lib/x86_64-linux-gnu/libdbus-1.so.3","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":25,"event":"module","body":{"module":{"addressRange":"7FFFF7F4A000","id":"7FFFF7F4A000","name":"libgcc_s.so.1","path":"/lib/x86_64-linux-gnu/libgcc_s.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/libgcc_s.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":26,"event":"module","body":{"module":{"addressRange":"7FFFF7F3F000","id":"7FFFF7F3F000","name":"librt.so.1","path":"/lib/x86_64-linux-gnu/librt.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/librt.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":27,"event":"module","body":{"module":{"addressRange":"7FFFF7F1C000","id":"7FFFF7F1C000","name":"libpthread.so.0","path":"/lib/x86_64-linux-gnu/libpthread.so.0","symbolFilePath":"/usr/lib/debug/.build-id/4f/c5fc33f4429136a494c640b113d76f610e4abc.debug","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":28,"event":"module","body":{"module":{"addressRange":"7FFFF7DCD000","id":"7FFFF7DCD000","name":"libm.so.6","path":"/lib/x86_64-linux-gnu/libm.so.6","symbolFilePath":"/lib/x86_64-linux-gnu/libm.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":29,"event":"module","body":{"module":{"addressRange":"7FFFF7DC7000","id":"7FFFF7DC7000","name":"libdl.so.2","path":"/lib/x86_64-linux-gnu/libdl.so.2","symbolFilePath":"/lib/x86_64-linux-gnu/libdl.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":30,"event":"module","body":{"module":{"addressRange":"7FFFF7BD3000","id":"7FFFF7BD3000","name":"libc.so.6","path":"/lib/x86_64-linux-gnu/libc.so.6","symbolFilePath":"/lib/x86_64-linux-gnu/libc.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":31,"event":"module","body":{"module":{"addressRange":"7FFFF7B24000","id":"7FFFF7B24000","name":"libsystemd.so.0","path":"/lib/x86_64-linux-gnu/libsystemd.so.0","symbolFilePath":"/lib/x86_64-linux-gnu/libsystemd.so.0","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":32,"event":"module","body":{"module":{"addressRange":"7FFFF7AFB000","id":"7FFFF7AFB000","name":"liblzma.so.5","path":"/lib/x86_64-linux-gnu/liblzma.so.5","symbolFilePath":"/lib/x86_64-linux-gnu/liblzma.so.5","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":33,"event":"module","body":{"module":{"addressRange":"7FFFF7ADA000","id":"7FFFF7ADA000","name":"liblz4.so.1","path":"/lib/x86_64-linux-gnu/liblz4.so.1","symbolFilePath":"/lib/x86_64-linux-gnu/liblz4.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":34,"event":"module","body":{"module":{"addressRange":"7FFFF79BC000","id":"7FFFF79BC000","name":"libgcrypt.so.20","path":"/lib/x86_64-linux-gnu/libgcrypt.so.20","symbolFilePath":"/lib/x86_64-linux-gnu/libgcrypt.so.20","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.278Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":35,"event":"module","body":{"module":{"addressRange":"7FFFF7997000","id":"7FFFF7997000","name":"libgpg-error.so.0","path":"/lib/x86_64-linux-gnu/libgpg-error.so.0","symbolFilePath":"/lib/x86_64-linux-gnu/libgpg-error.so.0","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-08-04T08:34:43.286Z DEBUG codelldb::debug_session] Debug event: 0x7fa68800a0f0 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = stopped}
[2021-08-04T08:34:43.286Z DEBUG codelldb::debug_session] Debug event: 0x7fa6899592c0 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = running}
[2021-08-04T08:34:43.286Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":36,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2021-08-04T08:34:43.288Z DEBUG codelldb::debug_session] Debug event: 0x7fa68c016360 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = stopped}
[2021-08-04T08:34:43.289Z DEBUG codelldb::debug_session] Debug event: 0x7fa689916120 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = running}
[2021-08-04T08:34:43.289Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":37,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2021-08-04T08:34:43.291Z DEBUG codelldb::debug_session] Debug event: 0x7fa68995a360 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = stopped}
[2021-08-04T08:34:43.291Z DEBUG codelldb::debug_session] Debug event: 0x7fa68991ba70 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = running}
[2021-08-04T08:34:43.291Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":38,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2021-08-04T08:34:43.294Z DEBUG codelldb::debug_session] Debug event: 0x7fa6899157a0 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = stopped}
[2021-08-04T08:34:43.294Z DEBUG codelldb::debug_session] Debug event: 0x7fa689915cd0 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = running}
[2021-08-04T08:34:43.294Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":39,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2021-08-04T08:34:43.297Z DEBUG codelldb::debug_session] Debug event: 0x7fa68991bb00 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = stopped}
[2021-08-04T08:34:43.297Z DEBUG codelldb::debug_session] Debug event: 0x7fa6899157a0 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = running}
[2021-08-04T08:34:43.297Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":40,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2021-08-04T08:34:43.300Z DEBUG codelldb::debug_session] Debug event: 0x7fa689915d60 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = stopped}
[2021-08-04T08:34:43.300Z DEBUG codelldb::debug_session] Debug event: 0x7fa68991bad0 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = running}
[2021-08-04T08:34:43.300Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":41,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2021-08-04T08:34:43.412Z DEBUG codelldb::debug_session] Debug event: 0x7fa689916030 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = stopped}
[2021-08-04T08:34:43.412Z DEBUG codelldb::debug_session] Debug event: 0x7fa6899157d0 Event: broadcaster = 0x561700349478 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x561700349440 (pid = 3720387), state = running}
[2021-08-04T08:34:43.412Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":42,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}

Uh, sorry, there isn't much to go on here.   What do you mean by "deadlock the entire process"?   Does does codelldb respond to commands in console?  Try e.g. process status.

@vadimcn i've reproduced this in with plugin version 1.6.6 now:
When i request process status it resolves instantly.
When i request process trace it seems to print the "start" of the help header. Continue stalling for a while and then crash with the remainder info, i.e. perform these steps:

Start debugging session with reproduction
Wait between 0s -> 120s (or how much you want to establish that the process does not crash by itself)
execute process trace in VSCode Debugging Console
See header printed

process trace
Commands for tracing the current process.

Syntax: process trace  []

The following subcommands are supported:

Wait approx 20s, remainder is then printed:

      start -- Start tracing this process with the corresponding trace plug-in.
      stop  -- Stop tracing this process. This does not affect traces started
               with the "thread trace start" command.

For more help on any particular subcommand, type 'help  '.
Process exited with code -1.

For full log, and again, if you do not invoke process trace but instead only process status nothing crashes the debug process, but instead it just stays in the "deadlock" state:

Launched process 1666107
process status
Process 1666107 is running.
process trace
Commands for tracing the current process.

Syntax: process trace  []

The following subcommands are supported:

FOO
process
process status
      start -- Start tracing this process with the corresponding trace plug-in.
      stop  -- Stop tracing this process. This does not affect traces started
               with the "thread trace start" command.

For more help on any particular subcommand, type 'help  '.
Process exited with code -1.
Commands for interacting with processes on the current platform.

Syntax: process  []

The following subcommands are supported:

      attach    -- Attach to a process.
      connect   -- Connect to a remote debug service.
      continue  -- Continue execution of all threads in the current process.
      detach    -- Detach from the current target process.
      handle    -- Manage LLDB handling of OS signals for the current target
                   process.  Defaults to showing current policy.
      interrupt -- Interrupt the current target process.
      kill      -- Terminate the current target process.
      launch    -- Launch the executable in the debugger.
      load      -- Load a shared library into the current process.
      plugin    -- Commands for operating on a ProcessGDBRemote process.
      save-core -- Save the current process as a core file using an appropriate
                   file type.
      signal    -- Send a UNIX signal to the current target process.
error: 'FOO' is not a valid command.
      status    -- Show status and stop location for the current target process.
      trace     -- Commands for tracing the current process.
      unload    -- Unload a shared library from the current process using the
                   index returned by a previous call to "process load".

For more help on any particular subcommand, type 'help  '.
Process 1666107 exited with status = -1 (0xffffffff) lost connection


Documentation update: Use DynamicProperties to show that dynamic properties have different variable scopes

Hi folks,
Something I caught while reading the code is that both the meta and property dynamic properties evaluate flowfile attributes: https://github.com/marklogic/nifi/blob/88341593832017a606228ab2ab9bc98f18425e78/nifi-marklogic-processors/src/main/java/org/apache/nifi/marklogic/processor/PutMarkLogic.java#L496-L510
However, the DynamicProperty annotation covers all properties in one go, and so shows that the language scope is VARIABLE_REGISTRY only:
https://github.com/marklogic/nifi/blob/88341593832017a606228ab2ab9bc98f18425e78/nifi-marklogic-processors/src/main/java/org/apache/nifi/marklogic/processor/PutMarkLogic.java#L75-L78
I believe it would be possible to use the DynamicProperties annotation to split these apart and make their use clearer, e.g as in the PutFTP processor:
https://github.com/apache/nifi/blob/e4b7e47836edf47042973e604005058c28eed23b/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutFTP.java#L50-L60

@sgsabbage Do you know where the info from a DynamicProperty is actually shown in NiFi? There's an overridden getSupportedDynamicPropertyDescriptor method in AbstractMarkLogicProcessor that NiFi uses for showing a description of a dynamic property that's been added to the processor. I'm using NiFi 1.9.x, but I would figure that the name/value/description from DynamicProperty has value somewhere, I just can't find it.

@rjrudin sorry for the delay on getting back to you. Best I can tell is that the @DynamicProperties annotation is used to provide the   documentation for the Usage page, e.g.

while the getSupportedDynamicPropertyDescriptor function is used when viewing the properties in the processor, e.g.

Thanks - I verified that the getSupportedDynamicPropertyDescriptor method is returning correct descriptions, including the correct expression language scope.


[BUG] Node server ungracefully crashes when given unparsable json for the state (e.g. http://localhost:3000/__rsc?state=invalid{state)

Describe the bug
When a server request contains a query param which contains a single double quote ("), the server will crash with a JSON parse error.
Edit: As mentioned in https://github.com/Shopify/hydrogen/issues/1863#issuecomment-1201993074 any invalid state given to the __rsc endpoint will cause the node server to ungracefully crash.
To Reproduce
Clone and run the following repo: https://github.com/nattyg93/hydrogen-bug-search-param-quote

Run the server
Load the homepage
Click the "Bug Out - step 1" button
If the server hasn't already crashed at this point - click "Bug Out - step 2" (And then click "Bug Out - step 1" again, but it will have crashed by now)

Additional context

Hydrogen version: 1.1.0
Node version: 16.14.0

I've tested with Hydrogen 1.2.0 and this issue is still present.
We're keen to upgrade Hydrogen to benefit from #1830, which is currently doubling the load time of navigating between some of our routes.

@frandiox This looks like it was introduced in #1780

Further to this, any invalid json in the state param will cause the node server to ungracefully crash. For example, if you visit http://localhost:3000/__rsc?state=invalid{state the node server will crash.

@nattyg93 Sorry for the late response! I might have missed this notification. This should be fixed in #2315

@frandiox The server no longer crashes when given invalid JSON, but the original issue (as described in my initial message) of the query params containing a double quote (") resulting in an error is still present.


OpenOCD not working on mac

I followed all the steps of installing tools required for stm32f3discovery board on Macbook Pro having USB3.0 ports yet when I ran openocd -f interface/stlink-v2.cfg -f target/stm32f3x.cfg I get the following result
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
To my best knowledge, I think its an issue due to usb 3.0 but since I am a newbie I require assistance from sonsummate professionals

I'm experiencing the exact same issue.

I had a similar issue on Big Sur, but with a Nucleo-F439ZI board. In my case, following the hint in #263 helped and I was able to get it to work with the newer stlink config. Maybe try:
openocd -f interface/stlink-v2-1.cfg -f target/stm32f3x.cfg

I had a similar issue on Big Sur, but with a Nucleo-F439ZI board. In my case, following the hint in #263 helped and I was able to get it to work with the newer stlink config. Maybe try:
openocd -f interface/stlink-v2-1.cfg -f target/stm32f3x.cfg

I am currently experiencing a similar issue, but my error message is a bit different:
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Error: open failed
There is not any information about why the error occurs either.

I am currently experiencing a similar issue, but my error message is a bit different:
Open On-Chip Debugger 0.11.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 1000 kHz Error: open failed
There is not any information about why the error occurs either.

I'm getting the same sorta issue - unable to find anything.

someone got the issue solved?


Can't run dotnet test

@mellinoe
When I  run dotnet test on Slices it says
dotnet-test Error: 0 : System.InvalidOperationException: Can not find runtime target for framework '.NETStandard,Version=v1.0' compatible with one of the target runtimes: 'win10-x64, win81-x64, win8-x64, win7-x64'. Possible causes:
1. The project has not been restored or restore failed - run `dotnet restore`
2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 'runtimes' section.
   at Microsoft.DotNet.ProjectModel.BuildWorkspace.GetRuntimeContext(ProjectContext context, IEnumerable`1 runtimeIdentifiers)
   at Microsoft.DotNet.Tools.Test.TestCommand.<>c__DisplayClass2_0.<DoRun>b__0(ProjectContext c)
   at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Microsoft.DotNet.Tools.Test.TestCommand.DoRun(String[] args)

dotnet restore doesn't help.

Oh.. I should've run in tests\System.Slices.Tests..
Closing.


Derive AsBindGroup Improvements: Better errors, more options, update examples

Objective

Provide better compile-time errors and diagnostics.
Add more options to allow more types textures and sampler types.
Update array_texture example to use upgraded AsBindGroup derive macro.

Solution
Draft PR since visibility is not yet supported, and I'm willing to change the names of any attributes/args/etc for clarity.
Split out the parsing of the inner struct/field attributes (the inside part of a #[foo(...)] attribute) for better clarity
Parse the binding index for all inner attributes, as it is part of all attributes (#[foo(0, ...)), then allow each attribute implementer to parse the rest of the attribute metadata as needed. This should make it very trivial to extend/change if needed in the future.

#[texture(u32, ...)]

dimension can be "1d", "2d", "2d_array", "3d", "cube", or "cube_array".
sample_type can be "float", "depth", "s_int" or "u_int".
filterable can be true or false. This can only be set if sample_type is "float".
multisampled can be true or false.

#[sampler(u32, ...)]

sampler type can be "filtering", "non_filtering", or "comparison".

Replaced invocations of panic! with the syn::Error type, providing fine-grained errors that retains span information. This provides much nicer compile-time errors, and even better IDE errors.

Updated the array_texture example to demonstrate the new changes.
TODO:

[x] Remove all panic! uses, replace with syn::Error
[x] Extend #[texture] attribute

[x] Support dimension, sample_type, multisampled, and filterable attribute arguments

[x] Extend #[sampler] attribute

[x] Support sampler_type

[ ] Support visibility  attribute argument

Changelog

Added more options to #[texture(...)] and #[sampler(...)] attributes, supporting more kinds of materials. See above for details.
Upgraded IDE and compile-time error messages.
Updated array_texture example using the new options.

I know it's still a draft, but I would suggest splitting this in 2 PRs. One for the better parsing and one that adds the new options. This will make it easier to review and increases how fast something can get merged.

I know it's still a draft, but I would suggest splitting this in 2 PRs. One for the better parsing and one that adds the new options. This will make it easier to review and increases how fast something can get merged.

Yep, I may actually split it into 3, one for the syn errors, one for the reorganized parsing, and one for the new options.

Looks like you need to run cargo fmt.

I'm adding this to the 0.8 milestone as it makes for a big improvement to the new AsBindGroup feature.

If you want to iterate more quickly on getting this to pass CI checks, you can run cargo run -p ci locally.

Did a bit of clean-up, pretty happy with this PR now. Ready for review I suppose. Also now supports visibility flags
#[derive(AsBindGroup, Debug, Clone, TypeUuid)]
#[uuid = "9c5a0ddf-1eaf-41b4-9832-ed736fd26af3"]
struct ArrayTextureMaterial {
    #[texture(0, dimension = "2d_array", visibility(FRAGMENT))]
    #[sampler(1)]
    array_texture: Handle<Image>,
}

impl Material for ArrayTextureMaterial {
    fn fragment_shader() -> ShaderRef {
        "shaders/array_texture.wgsl".into()
    }
}

The syntax I think is pretty solid, but feel free to suggest any changes.

Yup lets leave this as-is. Splitting out would definitely help with reviews, but I'm comfortable reviewing this as a unit in the interest of time / including this in 0.8.

bors r+


Adding autoscale region move to the dcoumentation

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

Recreating another PR, please ignore


Support transforming arc commands

This fixes an issue where most non-trivial transformations were not being correctly applied to arcs. The endpoints would move but the arc radii and rotation angle would remain unchanged, resulting in an incorrect final path. Test cases illustrate some of the ways this failed previously.
I left a lot of algebra in the comments, which hopefully sheds light on how the transformation works. I can trim it down if you think the math is too obvious (or add more English if the math isn't obvious enough).

I appreciate you contribution but too much math for me to review it quickly (before i actually deep dive into shapes and matrix transformations).
Let's be confident into your work. I'll merge and publish your changes once the travis build will be repaired in order to get them passing. I'll work on it asap.
Thanks again for your contribution.

Thanks for you valuable contributions.


Import error

Hi there, maybe I messed up something during installation, but I can't seem to import the package.
I have reliablegpt-0.2.9612 installed in python 3.11.4 on Mac. When running from reliablegpt import reliableGPT I get:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'reliableGPT' from 'reliablegpt' (/opt/homebrew/lib/python3.11/site-packages/reliablegpt/__init__.py)

When trying to import the package as a whole I get nothing attached to it:
>>> import reliablegpt
>>> dir(reliablegpt)
['__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__']

Am I doing something wrong?

hey @c0d3rman that's odd - just pushed a couple updates, can you try now. I believe our local Macs have similar specs.
Is this an M-series Mac or Intel?

Reinstalled, still the same issue. It's an M-series mac. Note that I'm installing from pip, not from source.
Here's what my reliablegpt/__init__.py file looks like:
# reliablegpt/__init__.py
# from .RateLimitHandler_helpers import *
# from .Alerting import *
# from .IndividualRequest import *
# from .Model import *
# from .RateLimitHandler import *
# from .main import *  # Import all the symbols from main.py

That's probably the cause of the issue. Not sure why it's like this though.

what version of reliableGPT are you using ?
can you try
pip install reliableGPT==0.2.976
My phone number is +1<PHONE_NUMBER> if it does not work again and you'd like to resolve it faster. Else will monitor here

Hi, I reinstalled everything in a fresh virtual env and then manually installed some dependencies (waitress and flask), and have finally gotten it to work. The version I had before was 0.2.9612, which is the one I got from a vanilla pip install reliablegpt. After today's reinstall, I now have 0.2.976. For some reason, pip wouldn't update to 0.2.976 even with pip install -U reliablegpt, but a force reinstall did it. (The install still errors until I manually install those dependencies though.)

does it work for you now @c0d3rman ?

Yes it does

Thanks for flagging this @c0d3rman. I'll look into the default install issue.
If you face any errors feel free to text either me (+17708783106) or Ishaan (+14126186238). Also happy to hop on a call to help solve any reliability issues your facing - https://calendly.com/kdholakia/30min.

FYI you can view your requests / saved exceptions at: https://reliable-gpt-fe.vercel.app/
It looks like this

live link: https://reliable-gpt-fe.vercel.app/
I'll look into the default install issue.
If you face any errors feel free to text either me (+17708783106) or Ishaan (+14126186238).
I'd love to hop on a call to help solve any reliability issues your facing - Link for your convenience https://calendly.com/kdholakia/30min.


Add Java Microbenchmarking Tool Dependency

Context
Added dependency to support JMH -- Java Microbenchmarking Tool in the project.
Changes

Added jmh dependency
Added src/test/java/org/apache/commons/imaging/BenchmarkRunner.java as Benchmarking Runner

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (6cbe44a) 71.16% compared to head (2f9a4c5) 71.16%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##             master       #8   +/-   ##
=========================================
  Coverage     71.16%   71.16%
  Complexity     3522     3522
=========================================
  Files           351      351
  Lines         17299    17299
  Branches       2672     2672
=========================================
  Hits          12311    12311
  Misses         3932     3932
  Partials       1056     1056

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


NPE in BasicRelationalConverter: @WritingConverter in combination with null [DATAJDBC-578]

Clemens Hahn opened DATAJDBC-578 and commented
I have a Entity Ticket with a column status which is a enum:
data class Ticket(
        @Id var id: Long? = null,
        val title: String,
        val assigned: String? = null,
        val status: TicketStatus = TicketStatus.UNKNOWN
) {
    enum class TicketStatus(private val databaseValue: String?) {
        OPEN("oPeN"),
        SOLVED("solVed"),
        UNKNOWN(null);

        @ReadingConverter
        class EnumReadingConverter : Converter<String, TicketStatus> {
            override fun convert(dbValue: String): TicketStatus {
                return values().first { it.databaseValue == dbValue }
            }
        }

        @WritingConverter
        class EnumWritingConverter : Converter<TicketStatus, String> {
            override fun convert(entity: TicketStatus): String? {
                return entity.databaseValue
            }
        }
    }
}

As you can see the TicketStatus UNKNOWN should be represented by null in the database.
Perhaps this is a bad approach at all, but I noticed a hard NullPointerException in org.springframework.data.relational.core.conversion.BasicRelationalConverter.getPotentiallyConvertedSimpleWrite(BasicRelationalConverter.java:214). Full stacktrace is attached.
In order to reproduce this case please see my created spring-boot project at GitHub (ticket/DATAJDBC-578 branch), especially the tests in com.example.springdatajdbc.showcase.ShowcaseApplicationTests
So the root cause of this exception is not spring-data-jdbc. Please change the jira-project if necessary, thanks!

Attachments:

NPE-BasicRelationalConverter.txt (11.40 kB)

+1 I hit the same issue while trying to make a converter that takes an Optional type. It makes sense for the Optional type, if empty, to be converted to a NULL in the DB.


ES6 Symbols are handled as Objects

Simple example
The Symbol is a primitive type.

See https://github.com/facebook/flow/issues/810


it's more useful for webhook_config support template and custom the header

why not webhook_config support the template and custom the header? most of the time, we just modify configuration file to integrations custom alert system

Duplicate of #701 and https://github.com/prometheus/alertmanager/pull/2184. So far we haven't reached a consensus on it.
I'm closing it for now. If you have further questions, please use our user mailing list, which you can also search.

tks


add an iterative version of stats._mannwhitneyu._MWU._f to fall back to when recursion limit is hit by 'exact' method

Reference issue
#14622
What does this implement/fix?
mannwhitneyu hits recursion limits when _mwu_choose_method chooses 'exact' but one sample is large. This implements an iterative version of _f in _MWU that is used as a fallback when the recursion limit is hit.
Additional information
The iterative version is slower than the recursive; however, this only affects the rare edge cases that the issue pertains to. Nevertheless, in those cases, reverting to the 'asymptotic' method only to work around the recursion limit may cause a significant difference in the resulting p-value; therefore, it is proposed to fall back to iteration instead.

Thanks. It looks like you tied this in really cleanly. I hope someone can review in detail soon. (I would probably not be before December for me.) Could you add the test to test_hypotests instead? That where most of the MWU tests are; the ones in test_stats are just preserved because that's where they were before the overhaul. Also, please consider:
* adding the iterative method to `test_exact_distribution`

Will do.

* testing a call to `mannwhitneyu` with a case that triggers the iterative method and check for accuracy (e.g. you could hard-code the results from the recursive solution as ground truth),

Right, I did not add this because it would be slow.

* testing a call with n-d array input that triggers the iterative method to check that it still does the right thing (maybe using the asymptotic method as a reference? We don't need to check for perfect accuracy; just that it's still applying the `axis` parameter appropriately.).

OK, I'll make a test for this.

If some of these tests are really slow and we can be convinced they're not needed, let us know. These are just some things that come to mind.

FYI, without caching, iteration for cases that would hit the recursion limit run for slightly over a minute on an i5 laptop. Cases slightly smaller than these edge cases run for ~40 seconds with recursion. Thus, iteration is not super slow, but it is definitely slower than recursion. The cause of course is method calls and .append/.pop inside the loop. I tried to strip it down as much as possible but the slight performance increase did not seem to justify the loss of readability.
On that note, do you know why an array is used for caching (_fmnks in _MWU)? I tested with a dict and it appeared faster. In some large cases, assigning the array for the cache can hit memory limits as well. A dict would suffer less from this.

I

Thanks. It looks like you tied this in really cleanly. I hope someone can review in detail soon. (I would probably not be before December for me.) Could you add the test to test_hypotests instead? That where most of the MWU tests are; the ones in test_stats are just preserved because that's where they were before the overhaul. Also, please consider:

adding the iterative method to test_exact_distribution

Added this. I just cloned your existing tests and forced iteration.

testing a call to mannwhitneyu with a case that triggers the iterative method and check for accuracy (e.g. you could hard-code the results from the recursive solution as ground truth),
testing a call with n-d array input that triggers the iterative method to check that it still does the right thing (maybe using the asymptotic method as a reference? We don't need to check for perfect accuracy; just that it's still applying the axis parameter appropriately.).

I added tests for this.

If some of these tests are really slow and we can be convinced they're not needed, let us know. These are just some things that come to mind.

The issue is, all edge cases that trigger iteration will be solved slowly. Both recursion (with increased recursion limit) and iteration will take minutes. Thus, I did not include these "real" tests. Instead, I included smaller problems and forced _mwu_state to use iteration. I suspect that if solutions of small problems are equivalent, solutions of large problems will be equivalent as well. I tested equivalence of large problems manually and everything looked OK.
TestMannWhitneyU::test_gh_11355 and TestMannWhitneyU::test_gh_4067 failed due to ValueError: x and y must not contain NaNs. My changes are apparently unrelated to this, but I am not sure.

For lint checks, consider looking for an IDE option that eliminates trailing or blank line whitespace.

Removed blanks.

The issue is, all edge cases that trigger iteration will be solved slowly. Both recursion (with increased recursion limit) and iteration will take minutes. Thus, I did not include these "real" tests.

BTW you can decorate very slow tests (the ones that take minutes) with pytest.xslow. These don't run in the CI and one can run the tests locally with the SCIPY_XSLOW env variable set to 1. Although, as you already test with smaller problems and verified it works for larger problems, it'd be OK not to do this.

@szkafander I subclassed TestMannWhitneyU to always use the iterative implementation and got some assertion errors.
Here's the implementation:
class TestMannWhitneyUIterative(TestMannWhitneyU):
    class _MWU_Iterative(_MWU):
        def cdf(self, k, m, n):
            '''Cumulative distribution function'''
            # We could use the fact that the distribution is symmetric to avoid
            # summing more than m*n/2 terms, but it might not be worth the
            # overhead. Let's leave that to an improvement.
            pmfs = self.pmf(np.arange(0, np.max(k) + 1), m, n)
            cdfs = np.cumsum(pmfs)
            return cdfs[k]
    _mannwhitneyu._mwu_state = _MWU_Iterative()
    _mannwhitneyu._mwu_state._use_iter = True

Failures:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_auto - assert 0.41083916083916083 == 0.09597902097902099
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_basic[kwds3-expected3] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_basic[kwds4-expected4] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_basic[kwds5-expected5] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_asymptotic_behavior - AssertionError: assert 0.047152776667529275 < 0.001
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_gh_9184[True-less-exact-0.8967698967699] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_gh_9184[True-greater-exact-0.1272061272061] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_gh_9184[True-two-sided-exact-0.2544122544123] - AssertionError:

I haven't carefully investigated the failures but it looks like the iterative implementation genuinely fails for some test cases. Can you please confirm these failures and try to find what's wrong with the implementation?

@szkafander I subclassed TestMannWhitneyU to always use the iterative implementation and got some assertion errors.
Here's the implementation:
class TestMannWhitneyUIterative(TestMannWhitneyU):
    class _MWU_Iterative(_MWU):
        def cdf(self, k, m, n):
            '''Cumulative distribution function'''
            # We could use the fact that the distribution is symmetric to avoid
            # summing more than m*n/2 terms, but it might not be worth the
            # overhead. Let's leave that to an improvement.
            pmfs = self.pmf(np.arange(0, np.max(k) + 1), m, n)
            cdfs = np.cumsum(pmfs)
            return cdfs[k]
    _mannwhitneyu._mwu_state = _MWU_Iterative()
    _mannwhitneyu._mwu_state._use_iter = True

Failures:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_auto - assert 0.41083916083916083 == 0.09597902097902099
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_basic[kwds3-expected3] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_basic[kwds4-expected4] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_basic[kwds5-expected5] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_asymptotic_behavior - AssertionError: assert 0.047152776667529275 < 0.001
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_gh_9184[True-less-exact-0.8967698967699] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_gh_9184[True-greater-exact-0.1272061272061] - AssertionError:
FAILED scipy/stats/tests/test_hypotests.py::TestMannWhitneyUIterative::test_gh_9184[True-two-sided-exact-0.2544122544123] - AssertionError:

I haven't carefully investigated the failures but it looks like the iterative implementation genuinely fails for some test cases. Can you please confirm these failures and try to find what's wrong with the implementation?

Will do. I need a few days.

Looks like this fell off the radar - no problem! We went ahead and finished this up in gh-15920. Thanks!


Export HTML as JSON

Foo

      th1
      th2

      td11
      td12

      td21
      td22

[
   {
      "value": "Foo"
   },
   {
      "value":
      {
         "headers": ["th1", "th2"],
         "values":
         [
            [ "td11", "td12" ],
            [ "td21", "td22" ]
         ]
      }
   }
]

Need a

new parameter for API, like IConfig.OutputConfig

new HTML postprocessor created

new HTML postprocessor integrated with config
It depends on how Postprocessing gonna go, which should:

Strip hmtl

Format Json
Could take a week.
8SP.

I want to split this work, but aint gonna pollute with tickets.
I will create multiple pull requests instead:
#9_Processor
#9_Config
#9_Final

[Test]
    public void Scarp_SingleTag_AsJson_ShouldWork()
    {
        var scrapper = new Scrapper();
        var css = "p";
        var html = """

 Preface

 Content

        """;

        string[] expected = [
            """{"value":" Preface "}""",
            """{"value":" Content "}"""
        ];

        var actual = scrapper
            .Scrap(html, css)
            .AsJson();

        Assert.That(actual, Is.EquivalentTo(expected));
    }


Filter should have default settings for different types to make the graphiql cleaner.

Different data types should have pre-set filters parameters by default instead of having all the different types of filter applied for each type.
Currently if you apply filters in the graphiql it has all the filters by default  as seen here: https://i.stack.imgur.com/D3zeO.jpg
I would propose to have something like these rules for default:
id: exact, inlist
string: contains, endswith, icontains, iexact/exact, iregex, isnull, startswith, inlist
int/float: exact/iexact, gt, gte, lt, lte, range, isnull, inlist
Some logic like anything with required! should not have isnull
Also an option on the filter when writing the class to modify the filters if you want something not preset as default.
This will make the Graphiql interface more clean and less confusing .

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

https://github.com/strawberry-graphql/strawberry-django/pull/478


Fix Dictionary ordering in TestHTTPURLResponse.test_NSCoding

TestHTTPURLResponse.test_NSCoding was sometimes failing after #5019 since Dictionary ordering can be unpredictable when encoding/decoding, e.g.
TestFoundation/TestHTTPURLResponse.swift:239: error: TestHTTPURLResponse.test_NSCoding : XCTAssertEqual failed: ("[AnyHashable("Content-Disposition"), AnyHashable("Content-Type")]") is not equal to ("[AnyHashable("Content-Type"), AnyHashable("Content-Disposition")]") - Archived then unarchived http url response must be equal.

This PR makes a small change to the test to compare Sets of the keys instead.

@swift-ci please test

@swift-ci please test Linux

https://github.com/swiftlang/swift/pull/77414
@swift-ci Please test


Update Puppeteer to version 21.6.0 and force "CDP" protocol

Similar to PR #17392 but also enforcing CDP as protocol to workaround a regression in the recent Puppeteer release.

/botio test

/botio integrationtest


Support Server Table

add table pb
(ps: based on core table)

We will re-design the all implementation of table. And it will be renamed to sql support.


Implement Lazy load in contributers profile page

The contributors page displays a lengthy section for the "Contributions" area.

In the screenshot provided, we can observe that the data for contributions made by a user appears extensive on the right-hand side. To optimize performance and improve user experience, we aim to implement lazy loading. This entails loading only a portion of the data initially and dynamically loading additional content as the user scrolls through it.

If you think we should implement this, please do assign me.

@rithviknishad can you review this PR #416. I reassigned you after you asked for changes.


row_to_json(text) does not exist

While creating an example for #987 i ended up in this error.
create table one(id text, primary key(id));
create table two(id text, primary key(id), two text references one(id));
grant select, references on one to testuser;
grant select, references on two to testuser;

curl -X GET "http://localhost:3000/one?select=two(*)" -H "accept: application/json" ; echo

{"hint":"No function matches the given name and argument types. You might need to add explicit type casts.","details":null,"code":"42883","message":"function row_to_json(text) does not exist"}

you have to select at least one field (primary key preferably) from table one (that's your first problem.) and don't use *, specify the primary key form table two and any additional fields you need
if that does not solve your problem, check what version of PostgreSQL you are using, has to be 9.3+ (although i see no reason for not using 9.6)

This also seems to appear for me when I selected a column from a referring table which has the same name as it's table. I.e.
CREATE TABLE parent {
  parent_id serial PRIMARY KEY
}

CREATE TABLE child {
  child_id serial PRIMARY KEY,
  parent_id integer REFERENCES parent(parent_id) NOT NULL,
  child text NOT NULL
}

It seems that in this case, http://localhost:8000/parent?parent_id=eq.1&select=child(child_id, child)
would result in row_to_json(text) does not exist, with the solution being to rename the child column in the child table to something other than the name of the table, i.e. full_name text and thus calling http://localhost:8000/parent?parent_id=eq.1&select=child(child_id, full_name).
disclaimer: haven't tried to run this exact example, but ran into this situation w/ a similar fix as detailed above.

@ruslantalpa should this bug than be reopened?

Can reproduce the errors in both examples in v<IP_ADDRESS> but not on master.
The fix was done in https://github.com/begriffs/postgrest/pull/996, tests were added here https://github.com/begriffs/postgrest/commit/e1cab584a3671171dc1b93cf9e94f0a51b9d381a.


[Beta] : Define the Head and Body of an HTML Document : Fails test case

Challenge define-the-head-and-body-of-an-html-document has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
fails test and says the head should wrap the title element also the example of page layout is not showing, I am using chrome canary browser
<!DOCTYPE html>

<title>The best page ever</title>

The best page ever

Cat ipsum dolor sit amet, jump launch to pounce upon little yarn mouse, bare fangs at toy run hide in litter box until treats are fed. Go into a room to decide you didn't want to be in there anyway.  Meow i could pee on this if i had the energy for slap owner's face at 5am until human fills food dish yet scamper.  Make meme, make cute face. Sleep in the bathroom sink chase laser but pee in the shoe.  There's an open PR (#12633) that has a fix for the failing test in this challenge. I'm going to close this issue since it should be resolved soon. Thanks so much for the help QA'ing the new challenges!


[WIP] Fix/issue-171 No icons shown in the palette

[ ] Ensure that you followed http://eclipse.github.io/winery/dev/ToolChain#github---prepare-pull-request.
[X] Branch name checked. That means, the branch name starts with thesis/, fix/, ...
[X] Ensure that the commit message is a good commit message
[X] Ensure to use auto format in all files
[X] Ensure that you appear in NOTICE at Copyright Holders
[X] Tests created for changes
[X] Screenshots added (for UI changes)

follow up: https://github.com/eclipse/winery/pull/307


Add sandboxes to the examples in the docs

This is an extension on https://github.com/reactjs/redux/pull/2486.
It adds the example sandboxes to the gitbook documentation as well.

Thanks again!


Max number of retries reached. model times out

things are getting better - i put in the following text to test with
build this "Contact the City of Charlottesville Zoning Office at<PHONE_NUMBER> for site approval, including building structural changes. Download a Business License Zoning Approval Application(pdf) If conducting business from your home, you will need a Home Occupation Provisional Use Permit (PDF) If erecting a sign at your business location, you will need a Sign Permit (PDF)"
and the response came through
It looks like you want to create a BPMN process for obtaining site approval and necessary permits from the City of Charlottesville Zoning Office. Would you like me to help you design this process? If so, I can create a new BPMN diagram for you."
and i said "yes" and things got started, however the model timed out?

bpmn_frontend-1       | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
bpmn_frontend-1       | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
bpmn_frontend-1       | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
bpmn_frontend-1       | 10-listen-on-ipv6-by-default.sh: info: IPv6 listen already enabled
bpmn_frontend-1       | /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
bpmn_frontend-1       | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
bpmn_frontend-1       | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
bpmn_frontend-1       | /docker-entrypoint.sh: Configuration complete; ready for start up
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: using the "epoll" event method
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: nginx/1.26.1
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: built by gcc 13.2.1 20231014 (Alpine 13.2.1_git20231014)
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: OS: Linux 6.6.32-linuxkit
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker processes
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 22
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 23
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 24
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 25
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 26
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 27
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 28
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 29
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 30
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 31
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 32
bpmn_frontend-1       | 2024/07/18 14:32:10 [notice] 1#1: start worker process 33
bpmn_assistant-1      | INFO:     Started server process [1]
bpmn_assistant-1      | INFO:     Waiting for application startup.
bpmn_assistant-1      | INFO:     Application startup complete.
bpmn_assistant-1      | INFO:     Uvicorn running on http://<IP_ADDRESS>:8000 (Press CTRL+C to quit)
bpmn_frontend-1       | <IP_ADDRESS> - - [18/Jul/2024:14:32:14 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36" "-"
bpmn_frontend-1       | <IP_ADDRESS> - - [18/Jul/2024:14:32:14 +0000] "GET /assets/index-BqfP9bEH.css HTTP/1.1" 304 0 "http://localhost:8080/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36" "-"
bpmn_frontend-1       | <IP_ADDRESS> - - [18/Jul/2024:14:32:14 +0000] "GET /assets/index-BjMKp_3P.js HTTP/1.1" 304 0 "http://localhost:8080/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36" "-"
bpmn_assistant-1      | INFO:     <IP_ADDRESS>:61366 - "GET /available_providers HTTP/1.1" 200 OK
bpmn_frontend-1       | <IP_ADDRESS> - - [18/Jul/2024:14:32:14 +0000] "GET /favicon.ico HTTP/1.1" 304 0 "http://localhost:8080/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36" "-"
bpmn_frontend-1       | <IP_ADDRESS> - - [18/Jul/2024:14:32:14 +0000] "GET /assets/materialdesignicons-webfont-Dp5v-WZN.woff2?v=7.4.47 HTTP/1.1" 304 0 "http://localhost:8080/assets/index-BqfP9bEH.css" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36" "-"
bpmn_assistant-1      | [INFO]: 2024-07-18 14:32:35.530 llm_facade.py:55 - Calling LLM
bpmn_assistant-1      | [INFO]: 2024-07-18 14:32:36.597 _client.py:1026 - HTTP Request: POST https://api.openai.com/v1/chat/completions "HTTP/1.1 200 OK"
bpmn_assistant-1      | INFO:     <IP_ADDRESS>:64349 - "POST /determine_intent HTTP/1.1" 200 OK
bpmn_assistant-1      | INFO:     <IP_ADDRESS>:64349 - "OPTIONS /talk HTTP/1.1" 200 OK
bpmn_assistant-1      | INFO:     <IP_ADDRESS>:64349 - "POST /talk HTTP/1.1" 200 OK
bpmn_assistant-1      | [INFO]: 2024-07-18 14:32:36.622 llm_facade.py:55 - Calling LLM
bpmn_assistant-1      | [INFO]: 2024-07-18 14:32:37.075 _client.py:1026 - HTTP Request: POST https://api.openai.com/v1/chat/completions "HTTP/1.1 200 OK"
bpmn_assistant-1      | [INFO]: 2024-07-18 14:32:55.084 llm_facade.py:55 - Calling LLM
bpmn_assistant-1      | [INFO]: 2024-07-18 14:32:55.964 _client.py:1026 - HTTP Request: POST https://api.openai.com/v1/chat/completions "HTTP/1.1 200 OK"
bpmn_assistant-1      | INFO:     <IP_ADDRESS>:45786 - "POST /determine_intent HTTP/1.1" 200 OK
bpmn_assistant-1      | [INFO]: 2024-07-18 14:32:56.008 app.py:81 - Creating a new BPMN process...
bpmn_assistant-1      | [INFO]: 2024-07-18 14:32:56.008 llm_facade.py:55 - Calling LLM
bpmn_assistant-1      | [INFO]: 2024-07-18 14:33:04.391 _client.py:1026 - HTTP Request: POST https://api.openai.com/v1/chat/completions "HTTP/1.1 200 OK"
bpmn_assistant-1      | [WARNING]: 2024-07-18 14:33:04.393 bpmn_modeling_service.py:51 - Validation error (attempt 1): 'next'
bpmn_assistant-1      | [INFO]: 2024-07-18 14:33:04.393 llm_facade.py:55 - Calling LLM
bpmn_assistant-1      | [INFO]: 2024-07-18 14:33:18.158 _client.py:1026 - HTTP Request: POST https://api.openai.com/v1/chat/completions "HTTP/1.1 200 OK"
bpmn_assistant-1      | [WARNING]: 2024-07-18 14:33:18.161 bpmn_modeling_service.py:51 - Validation error (attempt 2): 'next'
bpmn_assistant-1      | [INFO]: 2024-07-18 14:33:18.161 llm_facade.py:55 - Calling LLM
bpmn_assistant-1      | [INFO]: 2024-07-18 14:33:34.428 _client.py:1026 - HTTP Request: POST https://api.openai.com/v1/chat/completions "HTTP/1.1 200 OK"
bpmn_assistant-1      | [WARNING]: 2024-07-18 14:33:34.430 bpmn_modeling_service.py:51 - Validation error (attempt 3): 'next'
bpmn_assistant-1      | [INFO]: 2024-07-18 14:33:34.430 llm_facade.py:55 - Calling LLM
bpmn_assistant-1      | [INFO]: 2024-07-18 14:33:49.905 _client.py:1026 - HTTP Request: POST https://api.openai.com/v1/chat/completions "HTTP/1.1 200 OK"
bpmn_assistant-1      | [ERROR]: 2024-07-18 14:33:49.907 app.py:91 - Error: Max number of retries reached. Could not create the BPMN process.
bpmn_assistant-1      | Traceback (most recent call last):
bpmn_assistant-1      |   File "/app/src/bpmn_assistant/app.py", line 82, in _modify
bpmn_assistant-1      |     process = bpmn_modeling_service.create_bpmn(
bpmn_assistant-1      |   File "/app/src/bpmn_assistant/services/bpmn_modeling_service.py", line 59, in create_bpmn
bpmn_assistant-1      |     raise Exception(
bpmn_assistant-1      | Exception: Max number of retries reached. Could not create the BPMN process.
bpmn_assistant-1      | INFO:     <IP_ADDRESS>:45786 - "POST /modify HTTP/1.1" 500 Internal Server Error

Thanks for the bug report, I believe this should be fixed with the following commit: 03c65f27d9820e21b4beb8a32a03f485e13cabf3
Let me know if you encounter any other issues. Thanks!


Add inline spell attack rolls to Shadow Signet

I'm sure the system is doing something more elegant in the future, but in the meantime I think this is a decent stopgap.

The future is now!


Initial pybind11 Controller Wrapper

Problem

Switching from ctypes python controller implementation to pybind11.

Change overview

Initial implementation of the controller using pybind11
This does not interfere with the current implementation of the python controller.
Creates a new directory with the new python controller implementation.
Updates to the build_python script to install both wheels created.
Updated dev docker file to install python3.9.
Added pybind11 git submodule.
Added Zap files to use legacy Cluster + Ctypes

Testing

Imported the module successfully.
BLE connection initiated successfully
BLE pairing initiated successfully
BLE pairing on Linux successful
BLE Pairing on macOS successful

cool, please also have the cirque mobile test as well, the existing python device controller has the test to run in cirque to exercise pairing/thread provisioning/command/read/write.
Does this integration have any python version prerequisite?

This feature should not go to TE4, and should target TE5.

This feature should not go to TE4, and should target TE5.

We need this for Test Harness development, so we need it in the TE4 branch as we need to use known good branches for our harness development.

This feature should not go to TE4, and should target TE5.

We need this for Test Harness development, so we need it in the TE4 branch as we need to use known good branches for our harness development. We will not be using this controller for TE4, we will stay with the old one.

You can use the main branch for development.

This feature should not go to TE4, and should target TE5.

We need this for Test Harness development, so we need it in the TE4 branch as we need to use known good branches for our harness development. We will not be using this controller for TE4, we will stay with the old one.

You can use the main branch for development.

We need to have a stable base to do our development and history has shown that main is not stable enough over the long term.  We can spin a specific branch from the TE4 branch with this change if that works better.

This is a 17K PR
Are we checking in generated code? If so, please explain why. I would expect python to specifically not try to expose the C++ API as this API is not python-style or python-friendly

They are not fully generated, they are simply 'pre-generated' as an initial step to finish the binding files.
As mentioned in our discussions v1 will be a simple C++ python wrapper that will be used by the test harness (to provide development speed), then we will work to wrap it additionally in Python as the SDK settles.

This is a 17K PR
Are we checking in generated code? If so, please explain why. I would expect python to specifically not try to expose the C++ API as this API is not python-style or python-friendly

PyBind11 takes care of making it python-style and python-friendly. If you take a look at src/pybindings/pycontroller/TestDeviceController.py This is directly calling the bindings and it is pretty straight forward. Also, we are planning to update src/pybindings/pycontroller/ChipDeviceCtrl.py with the pybind11 bindings to make it even more python-style and keep it the same as previously. Once complete, pairing will look like this:
from ChipDeviceCtrl import ChipDeviceController
discriminator = 0xF00
setup_code = 20202021
node_id = 1
chip_controller = ChipDeviceController()
chip_controller.ConnectBLE(discriminator, setup_code, node_id)
chip_controller.CloseBLEConnection()

This is a 17K PR
Are we checking in generated code? If so, please explain why. I would expect python to specifically not try to expose the C++ API as this API is not python-style or python-friendly

They are not fully generated, they are simply 'pre-generated' as an initial step to finish the binding files.
As mentioned in our discussions v1 will be a simple C++ python wrapper that will be used by the test harness (to provide development speed), then we will work to wrap it additionally in Python as the SDK settles

I was under the impression that the discussions regarding python API leaned towards "write a nice python interface rather than trying to just wrap existing C++ API" - at least this is what I have been requesting from the SDK design perspective.
I find that "wrap C++ API" while the API is in flux will lock us in a lot more and I worry that our API in general is still quite in flux as we add more spec functionaity. I strongly believe python should generally not see 'PlatformMemoryInit" or need to access "BleMgrImpl".

This feature should not go to TE4, and should target TE5.

We need this for Test Harness development, so we need it in the TE4 branch as we need to use known good branches for our harness development. We will not be using this controller for TE4, we will stay with the old one.

You can use the main branch for development.

We need to have a stable base to do our development and history has shown that main is not stable enough over the long term. We can spin a specific branch from the TE4 branch with this change if that works better. It is also about maintainability because we often have to squash and rebase our fork, and it is easier to do in chunks than with constant changes to main.

Separate CSG development branch sounds better - I am looking to decouple large changes from the TE4 branch since the TE4 one has tighter deadlines.

Please start smaller - wrap just one API, preferably a simple one so we can get this off the ground.
Lots of stuff here seems wrong to me (e.g. subtyping CHIPDevice or the "example" operational credentials deledgate) but it is far too much to review in one go.

When we did the initial PR we were asked to wait until we had parity with the existing controller before submitting.  Since we didn't get much comments on the initial PR it was decided the basic format was ok.

Please start smaller - wrap just one API, preferably a simple one so we can get this off the ground.
Lots of stuff here seems wrong to me (e.g. subtyping CHIPDevice or the "example" operational credentials deledgate) but it is far too much to review in one go.

When we did the initial PR we were asked to wait until we had parity with the existing controller before submitting. Since we didn't get much comments on the initial PR it was decided the basic format was ok.

I don't know what you mean by "format".
Lack of comments doesn't mean anything. What you need are explicit approvals.
It's a huge lift to get all this done in one big PR, whoever told you to that, I disagree with them.


feat(example): Improve readability of the code

Split the example and library bundle files into several ones to improve
the readability of the example while inspecting the source code.
Fix #98
What do you think about that one @vvo ?

Some lint stuff ^ :)
Seems like a handy bit of plugin :) What does it do exactly? Create separate output?

I wonder if that's better. We do now see multiple files (good).
But first reaction is why "commons-chunk"? (I get it but the users?).
Then you look at the code and see:

For me it's trying to show the user that the code is readable while it's not very readable and it will just raise the FUD around it.
I would no tackle this for now, it's not a big deal if we have good documentation on how to use instantsearch.js.
Users really wanting to know how the example works can just have a look at the source code.
The instantsearch demo will be the tutorial we show to users, not the example app of instantsearch.js which should be used as a dev tool and not something we want our users to fully understand.
The instant search demo port using instantsearch.js will be the entry point for our users to understand how to build such UI.

For me it's trying to show the user that the code is readable while it's not very readable and it will just raise the FUD around it.

Ideally, I would remove webpack from the app.js file but didn't want to remove your require("template/...") instructions. I understand it's not very nice, but I think it's already better than what we have. Then if we find a loader that is replacing the require in place without defining those __webpack_require__ functions, maybe it's a good compromise.

Users really wanting to know how the example works can just have a look at the source code.

I'm convinced that's a very very small part of the users.

I would remove the public example url, it was here only to be able to demo the current prototype easily. And stop publishing it to gh-pages also.
To our developers, users, public the integration we will show will be the instant search demo built with instantsearch.js. This will be our documentation and main example, not the example/.
The example/ was mostly done to ease the development process.
Trying to make our development example readable for the public (that do not go to github) is no more necessary if there's no running version of it.
If we try to make it somehow readable what we will endup with is more issues and FUD in our development process.

Ideally, I would remove webpack from the app.js

Yes me too, that's why that's not what we should show to the public, but this: https://github.com/algolia/instant-search-demo/blob/feat/instantsearch.js-implementation/app.js.
I am :-1: for this PR

I would remove the public example url, it was here only to be able to demo the current prototype easily. And stop publishing it to gh-pages also.
To our developers, users, public the integration we will show will be the instant search demo built with instantsearch.js. This will be our documentation and main example, not the example/.

Ah if we keep that code as something only used for dev/test and we don't promote it on gh-pages, I'm 100% OK to close the PR and keep the previous code.

Ah if we keep that code as something only used for dev/test and we don't promote it on gh-pages, I'm 100% OK to close the PR and keep the previous code.

That's it, it was a mistake to make it public without explaining the long term goal.

see #200


feat: mean pooling

The current implementation does not include pooling. This result in wildly different embedding to fastembed python counterpart.
This pull request add a default mean pooling for token embeddings output from ort session.
This pull request includes:

[x] Added a hard coded embedding test,
[x] Added mean_pool function,
[x] Applied mean_pool in embedding generation.
[x] Add pooling config loader
[x] Implement pooling as a post processing step
[x] Add explicit pooling option for existing models

Noted, will take a look after work.


Make include guards unique.

Some include guards do not fit to the expected naming convention of the C language standard. This detail can be fixed by the deletion of leading underscores.
The probability for name clashes can also be reduced by the addition of a kind of universally unique identifier as a suffix.
This update suggestion corresponds to the issue "reserved identifier violation".

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


chore: [9719] png compression - 11654.85 KB saved

Description
PNG Images have been compressed by evaluating PNGOUT, OptiPNG, and DeflOpt outputs and choosing the smallest file, via PNGGauntlet - losslessly
11654.85 KB saved
Packaged Apps will be smaller, Web version will load faster due to lessened network bloat.
Closes #9719

coverage: 54.482%. remained the same
when pulling 47f6da4e822d2448391697217ffdabcb74bf5c1d on mikeirvingweb:png-compress
into a284398f74c4b82542a3ce3a70a6e3a7afefcaca on microsoft:main.

Looks great from the first sight, thanks!
This is pending embedded metadata review


Introspection Engine should try to classify the db and output that

In order to support our tools we should try to identify how the database was created / migrated. The classes could be:

Prisma 1
Prisma 1.1
Prisma 2
Non-Prisma

This is now available after https://github.com/prisma/prisma-engines/pull/726 was merged.


[SPARK-44642][CONNECT] ReleaseExecute in ExecutePlanResponseReattachableIterator after it gets error from server

What changes were proposed in this pull request?
Client:
When server returns error on the response stream via onError, the ExecutePlanResponseReattachableIterator will not see the stream finish with a ResultsComplete. Instead, a StatusRuntimeException will be thrown from next() or hasNext(). Handle catching that exception, telling the server to ReleaseExecute when we receive it, and rethrow it to the user.
Server:
We also have to tweak the behaviour of ReleaseAll to also interrupt the query. The previous behaviour that in case of a running query one has to first send an interrupt, and then release was done to prevent race conditions of an interrupt coming after ResultComplete. Now, this has been resolved with proper synchronization at the final moments of execution in ExecuteThreadRunner, and as we want the release to be async, having one ReleaseExecutel vs. needing a combination of Interrupt+ReleaseExecute simplifies things.
Why are the changes needed?
If ReleaseExecute is not called by the client to acknowledge that the error was received, the execution will keep dangling on the server until cleaned up by timeout.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Automated tests will come with https://issues.apache.org/jira/browse/SPARK-44625.

Merged to master and branch-3.5.


Asylum finder generated schema updates

See #431

Makes https://github.com/alphagov/specialist-publisher/pull/927 pass.


Including JsonSerializer.h Disables Warnings in Visual Studio

Including <aws/core/utils/json/JsonSerializer.h>, which in turn includes <aws/core/external/json-cpp/json.h>, causes warnings 4267 and 4512 to be disabled on Visual Studio 2008 and newer. Perhaps this should be wrapped in a #pragma warning(push/pop) pair?

We should be able to fix this fairly easily.  I believe there is another related issue outstanding, much older; let me go dig it up and perhaps we can get both knocked out.

This should be fixed in the latest release

Thanks!


Getting weird error response while executing simple script

from bardapi import Bard
token = '.......'
bard = Bard(token=token)
resp = bard.get_answer("What is BARD?")
print(resp)
It responds with {'content': 'Response Error: b')]}\'\n\n38\n[["wrb.fr",null,null,null,null,[9]]]\n55\n[["di",72],["af.httprm",72,"8367677104245371628",47]]\n25\n[["e",4,null,null,130]]\n'.'}
I started trying the API today morning.. Anyone else facing such issue or am I making a newbie mistake?

I am based in India. Is it due to country? I tried with VPN but got the same result..

Please refer to the following answer for instructions.
I've also found that the same error sometimes occurs during normal processes. Please give it some time or try resetting your cookie values.
Close this issue as a duplicate issue.

Thanks. I will try the options. Closing the issue for the moment..


error  Definition for rule '@graphql-eslint/require-selections' was not found

it's still operations-recommended

In my case I had this issue because I was expecting require-selections to be available on the latest stable NPM version, which is 3.20.1 -- however, the documentation references version 4.0.0_alpha. It would be nice if we could view docs for earlier versions.

this rule was renamed in v4 from require-id-when-available, if you are looking for v3 docs check the link in banner


catalog_table: Do not push metadata to worker until after init

catalog_table has been pushing inconsistent data to the worker, causing
unnecessary work. E.g., visiting a page with #releaseKeys=<foo>, the page
will actually push releases:<foo>, then releases:[], then
releases:<foo> due to controller initialization races. Using AngularJS's
$onInit() to set releases once during the initialization phase (then again
if the user interacts with the UI, of course; hence $onChanges) resolves
this race from the worker's perspective.

Codecov Report

Merging #107 into master will decrease coverage by 2.63%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #107      +/-   ##
==========================================
- Coverage   64.53%   61.89%   -2.64%
==========================================
  Files          35       35
  Lines        1672     1761      +89
  Branches      125      135      +10
==========================================
+ Hits         1079     1090      +11
- Misses        593      671      +78

Impacted Files
Coverage Δ

lib/component/catalog_table.es6.js
7.14% <0%> (-0.55%)
:arrow_down:

lib/client/api_matrix.es6.js
49.31% <0%> (-10.41%)
:arrow_down:

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 e33790c...e30795d. Read the comment docs.


Implement use gradle plugin for build ndk

Can you please explain what this change does?

It changes build native code with help tasks gradle plugin. It simply build script.

I don't understand. Will it help perhaps to import the project and run it?
On Thu, May 21, 2015 at 10:54 AM, skyrylyuk<EMAIL_ADDRESS>wrote:

It changes build native code with help tasks gradle plugin. It simply
build script.
—
Reply to this email directly or view it on GitHub
https://github.com/AndroidDeveloperLB/AndroidJniBitmapOperations/pull/24#issuecomment-104169904
.

Yes, I build project in Android Studio

I see. Can you please post a step by step tutorial about how to import the project into Android-Studio ? Ever since I've moved to Android-Studio, I couldn't succeed impoting it well.


Example gallery

As functionality and examples keep growing we should consider having a gallery of examples instead of tabs.

Hi @aloctavodia,
If this is not taken up, I can work on it

Great!

BTW, it will be enough to create the infrastructure with a couple of placeholder. Then I can populate the examples.


[R000583] Rep. Thomas Rooney

Rep. Thomas Rooney:
http://rooney.house.gov
Likely contact form URL to start with:
https://forms.house.gov/rooney/webforms/issue_subscribe.html

YAML file lost. I am working on it.


About the leakyReLU

Hi,
it seems that your implementation has a leaky ReLU between two fully connected layers in both Meso4 and MesoInception4.
But figure 4 in your paper does not have a leaky ReLU.
Why the difference?
Thanks

Hi,
Yes you are right. The training of the model dates back two years ago so I cannot say for sure, but I suppose this was an implementation detail I did not mention in the paper because of a lack of space. If I remember, the models were a bit less performant with ReLU, it was a way to gain one or two points of accuracy.
As for the general differences between ReLU and LeakyReLU, you may know it's a way to avoid dead neurons for a training with high-variance gradients.

Thank you :D