Wrong Command Executed When Trying to Debug Clang

OS: NixOS with Linux 5.15.63
VSCode version:  1.71.2
CodeLLDB version: v1.7.4
Compiler: clang 16.0.0
Debuggee: clang 16.0.0 (I'm debugging my own build of clang)

As discussed here, debugging clang doesn't appear to be working for me.
When I was using another debugger extension, I had some trouble with the use of single / double quotes in the compile command. Maybe they're the issue here too?
Help is much appreciated!

Output from Debug Console
Console is in 'commands' mode, prefix expressions with '?'.
Launching: /scratch/paul/src/llvm-project/build/bin/clang -Wp,-MMD,DoitLk/.dep_chain_tests.o.d -nostdinc -I./arch/arm64/include -I./arch/arm64/include/generated  -I./include -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT= -Qunused-arguments -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 --target=aarch64-unknown-linux-gnu -fintegrated-as -Werror=unknown-warning-option -Werror=ignored-optimization-argument -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -Wno-psabi -fno-asynchronous-unwind-tables -fno-unwind-tables -mbranch-protection=pac-ret+leaf+bti -Wa,-march=armv8.5-a -DARM64_ASM_ARCH='"armv8.5-a"' -DKASAN_SHADOW_SCALE_SHIFT= -fno-delete-null-pointer-checks -Wno-frame-address -Wno-address-of-packed-member -O2 -Wframe-larger-than=2048 -fstack-protector-strong -Wimplicit-fallthrough -Wno-gnu -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -fno-stack-clash-protection -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -fno-strict-overflow -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-pointer-to-enum-cast -Wno-tautological-constant-out-of-range-compare -Wno-unaligned-access -g -fsanitize=lkmm-dep-checker -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=1208  -DMODULE  -DKBUILD_BASENAME='"dep_chain_tests"' -DKBUILD_MODNAME='"dep_chain_tests"' -D__KBUILD_MODNAME=kmod_dep_chain_tests -c -o DoitLk/dep_chain_tests.o DoitLk/dep_chain_tests.c
Launched process 1398539
clang-14: error: no input files

launch.json config
"preLaunchTask": "produceCompileArgsFile",
"name": "LLDB Debug Module",
"type": "lldb",
"request": "launch",
"program": "${workspaceFolder}/build/bin/clang",
"args": "${input:CompileCmdArgs}",
"cwd": "${env:LINUX}",
"terminal": "console"
"inputs": [
{
"id": "CompileCmdArgs",
"type": "command",
"command": "extension.commandvariable.file.content",
"args": {
"fileName": "${workspaceFolder}/.compile_args",
}
}
]

Verbose log
  Initial debug configuration: {
  preLaunchTask: 'produceCompileArgsFile',
  name: 'LLDB Debug Module',
  type: 'lldb',
  request: 'launch',
  program: '${workspaceFolder}/build/bin/clang',
  args: '${input:CompileCmdArgs}',
  cwd: '${env:LINUX}',
  terminal: 'console',
  __configurationTarget: 6
}
Resolved debug configuration: {
  preLaunchTask: 'produceCompileArgsFile',
  name: 'LLDB Debug Module',
  type: 'lldb',
  request: 'launch',
  program: '${workspaceFolder}/build/bin/clang',
  args: [ '${input:CompileCmdArgs}' ],
  cwd: '${env:LINUX}',
  terminal: 'console',
  __configurationTarget: 6,
  relativePathBase: '/scratch/paul/src/llvm-project',
  _adapterSettings: {
    displayFormat: 'auto',
    showDisassembly: 'auto',
    dereferencePointers: true,
    suppressMissingSourceFiles: true,
    evaluationTimeout: 5,
    consoleMode: 'commands',
    sourceLanguages: null,
    terminalPromptClear: null,
    evaluateForHovers: true,
    commandCompletions: true,
    reproducer: false
  }
}
liblldb: /home/paul/.vscode-server/extensions/vadimcn.vscode-lldb-1.7.4/lldb/lib/liblldb.so
environment: {}
params: { evaluateForHovers: true, commandCompletions: true }
[2022-09-23T14:15:26.750Z DEBUG codelldb] New debug session
[2022-09-23T14:15:26.885Z 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,"supportsMemoryReferences":true,"supportsArgsCanBeInterpretedByShell":true},"type":"request","seq":1}
[2022-09-23T14:15:26.886Z DEBUG codelldb::dap_codec] <-- {"seq":1,"type":"response","request_seq":1,"success":true,"command":"initialize","body":{"exceptionBreakpointFilters":[{"default":true,"filter":"cpp_throw","label":"C++: on throw"},{"default":false,"filter":"cpp_catch","label":"C++: on catch"}],"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,"supportsWriteMemoryRequest":true}}
[2022-09-23T14:15:26.916Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"preLaunchTask":"produceCompileArgsFile","name":"LLDB Debug Module","type":"lldb","request":"launch","program":"/scratch/paul/src/llvm-project/build/bin/clang","args":["-Wp,-MMD,DoitLk/.dep_chain_tests.o.d -nostdinc -I./arch/arm64/include -I./arch/arm64/include/generated  -I./include -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT= -Qunused-arguments -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 --target=aarch64-unknown-linux-gnu -fintegrated-as -Werror=unknown-warning-option -Werror=ignored-optimization-argument -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -Wno-psabi -fno-asynchronous-unwind-tables -fno-unwind-tables -mbranch-protection=pac-ret+leaf+bti -Wa,-march=armv8.5-a -DARM64_ASM_ARCH='\"armv8.5-a\"' -DKASAN_SHADOW_SCALE_SHIFT= -fno-delete-null-pointer-checks -Wno-frame-address -Wno-address-of-packed-member -O2 -Wframe-larger-than=2048 -fstack-protector-strong -Wimplicit-fallthrough -Wno-gnu -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -fno-stack-clash-protection -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -fno-strict-overflow -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-pointer-to-enum-cast -Wno-tautological-constant-out-of-range-compare -Wno-unaligned-access -g -fsanitize=lkmm-dep-checker -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=1208  -DMODULE  -DKBUILD_BASENAME='\"dep_chain_tests\"' -DKBUILD_MODNAME='\"dep_chain_tests\"' -D__KBUILD_MODNAME=kmod_dep_chain_tests -c -o DoitLk/dep_chain_tests.o DoitLk/dep_chain_tests.c"],"cwd":"/scratch/paul/src/linux","terminal":"console","__configurationTarget":6,"relativePathBase":"/scratch/paul/src/llvm-project","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null,"evaluateForHovers":true,"commandCompletions":true,"reproducer":false},"__sessionId":"82528c7c-5b2d-4a11-8842-c5e47f7f656d"},"type":"request","seq":2}
[2022-09-23T14:15:26.916Z DEBUG codelldb::dap_codec] <-- {"seq":2,"type":"event","event":"output","body":{"output":"Console is in 'commands' mode, prefix expressions with '?'.\n"}}
INFO(Python) 14:15:26 formatters: Initializing
INFO(Python) 14:15:26 formatters.rust: Initializing
[2022-09-23T14:15:34.859Z DEBUG codelldb::debug_session] Debug event: 0x55c8e177dca0 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {clang}
[2022-09-23T14:15:34.859Z DEBUG codelldb::dap_codec] <-- {"seq":3,"type":"event","event":"initialized"}
[2022-09-23T14:15:34.860Z DEBUG codelldb::dap_codec] <-- {"seq":4,"type":"event","event":"module","body":{"module":{"addressRange":"FFFFFFFFFFFFFFFF","id":"FFFFFFFFFFFFFFFF","name":"clang","path":"/scratch/paul/src/llvm-project/build/bin/clang","symbolFilePath":"/scratch/paul/src/llvm-project/build/bin/clang","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:34.905Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"LKMMDependenceAnalysis.cpp","path":"/scratch/paul/src/llvm-project/llvm/lib/Transforms/Utils/LKMMDependenceAnalysis.cpp"},"lines":[1145],"breakpoints":[{"line":1145}],"sourceModified":false},"type":"request","seq":3}
[2022-09-23T14:15:35.465Z DEBUG codelldb::debug_session] Debug event: 0x55c8e8457170 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-09-23T14:15:35.465Z DEBUG codelldb::dap_codec] <-- {"seq":5,"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":1145,"message":"Resolved locations: 0","verified":true}]}}
[2022-09-23T14:15:35.499Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2022-09-23T14:15:35.499Z DEBUG codelldb::dap_codec] <-- {"seq":6,"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2022-09-23T14:15:35.534Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2022-09-23T14:15:35.534Z DEBUG codelldb::dap_codec] <-- {"seq":7,"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2022-09-23T14:15:35.565Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":6}
[2022-09-23T14:15:35.565Z DEBUG codelldb::debug_session] Debug event: 0x55c8e8457170 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-09-23T14:15:35.565Z DEBUG codelldb::dap_codec] <-- {"seq":8,"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2022-09-23T14:15:35.595Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":7}
[2022-09-23T14:15:35.596Z DEBUG codelldb::dap_codec] <-- {"seq":9,"type":"event","event":"output","body":{"output":"Launching: /scratch/paul/src/llvm-project/build/bin/clang -Wp,-MMD,DoitLk/.dep_chain_tests.o.d -nostdinc -I./arch/arm64/include -I./arch/arm64/include/generated  -I./include -I./arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DKASAN_SHADOW_SCALE_SHIFT= -Qunused-arguments -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 --target=aarch64-unknown-linux-gnu -fintegrated-as -Werror=unknown-warning-option -Werror=ignored-optimization-argument -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -Wno-psabi -fno-asynchronous-unwind-tables -fno-unwind-tables -mbranch-protection=pac-ret+leaf+bti -Wa,-march=armv8.5-a -DARM64_ASM_ARCH='\"armv8.5-a\"' -DKASAN_SHADOW_SCALE_SHIFT= -fno-delete-null-pointer-checks -Wno-frame-address -Wno-address-of-packed-member -O2 -Wframe-larger-than=2048 -fstack-protector-strong -Wimplicit-fallthrough -Wno-gnu -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang -fno-stack-clash-protection -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -fno-strict-overflow -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-pointer-to-enum-cast -Wno-tautological-constant-out-of-range-compare -Wno-unaligned-access -g -fsanitize=lkmm-dep-checker -mstack-protector-guard=sysreg -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard-offset=1208  -DMODULE  -DKBUILD_BASENAME='\"dep_chain_tests\"' -DKBUILD_MODNAME='\"dep_chain_tests\"' -D__KBUILD_MODNAME=kmod_dep_chain_tests -c -o DoitLk/dep_chain_tests.o DoitLk/dep_chain_tests.c\n"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":10,"type":"event","event":"output","body":{"output":"Launched process 1398539\n"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::debug_session] Debug event: 0x55c8ea984ad0 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {ld-2.33.so}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":11,"type":"response","request_seq":2,"success":true,"command":"launch"}
[2022-09-23T14:15:37.645Z DEBUG codelldb::debug_session] Debug event: 0x55c8ea97eb20 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {[vdso](0x00007ffff7fca000)}
[2022-09-23T14:15:37.645Z DEBUG codelldb::debug_session] Debug event: 0x55c8ea9823e0 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":12,"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2022-09-23T14:15:37.645Z DEBUG codelldb::debug_session] Debug event: 0x55c8ea982660 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-09-23T14:15:37.645Z DEBUG codelldb::debug_session] Debug event: 0x55c8ea9c9980 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-09-23T14:15:37.645Z DEBUG codelldb::debug_session] Debug event: 0x55c8ea9c9ac0 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-09-23T14:15:37.645Z DEBUG codelldb::debug_session] Debug event: 0x55c8ea9c9b70 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {clang}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":13,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7FCC000","id":"7FFFF7FCC000","name":"ld-2.33.so","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/ld-2.33.so","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/ld-2.33.so","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::debug_session] Debug event: 0x55c8ea97d3c0 Event: broadcaster = 0x55c8ea5fc748 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x55c8ea5fc710 (pid = 1398539), state = running}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":14,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7FCA000","id":"7FFFF7FCA000","name":"[vdso]","path":"[vdso]","symbolStatus":"Symbols not found"},"reason":"new"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":15,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":1,"line":1145,"message":"Resolved locations: 1","verified":true},"reason":"changed"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":16,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":2,"message":"Resolved locations: 2","verified":true},"reason":"changed"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":17,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":2,"message":"Resolved locations: 2","verified":true},"reason":"changed"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":18,"type":"event","event":"breakpoint","body":{"breakpoint":{"id":2,"message":"Resolved locations: 2","verified":true},"reason":"changed"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":19,"type":"event","event":"module","body":{"module":{"addressRange":"400000","id":"400000","name":"clang","path":"/scratch/paul/src/llvm-project/build/bin/clang","symbolFilePath":"/scratch/paul/src/llvm-project/build/bin/clang","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.645Z DEBUG codelldb::dap_codec] <-- {"seq":20,"type":"event","event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2022-09-23T14:15:37.649Z DEBUG codelldb::debug_session] Debug event: 0x7f5548362b70 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {ld-linux-x86-64.so.2}
[2022-09-23T14:15:37.649Z DEBUG codelldb::debug_session] Debug event: 0x7f554835ffe0 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-09-23T14:15:37.649Z DEBUG codelldb::dap_codec] <-- {"seq":21,"type":"event","event":"module","body":{"module":{"addressRange":"FFFFFFFFFFFFFFFF","id":"FFFFFFFFFFFFFFFF","name":"ld-linux-x86-64.so.2","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/ld-linux-x86-64.so.2","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/ld-linux-x86-64.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.649Z DEBUG codelldb::debug_session] Debug event: 0x7f5548362c00 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2022-09-23T14:15:37.649Z DEBUG codelldb::debug_session] Debug event: 0x7f5548362820 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000004 (modules-unloaded), data = {ld-linux-x86-64.so.2}
[2022-09-23T14:15:37.649Z DEBUG codelldb::dap_codec] <-- {"seq":22,"type":"event","event":"module","body":{"module":{"id":"FFFFFFFFFFFFFFFF","name":""},"reason":"removed"}}
[2022-09-23T14:15:37.649Z DEBUG codelldb::debug_session] Debug event: 0x7f554835ffe0 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {[vdso](0x00007ffff7fca000)}
[2022-09-23T14:15:37.649Z DEBUG codelldb::dap_codec] <-- {"seq":23,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7FCA000","id":"7FFFF7FCA000","name":"[vdso]","path":"[vdso]","symbolStatus":"Symbols not found"},"reason":"new"}}
[2022-09-23T14:15:37.654Z DEBUG codelldb::debug_session] Debug event: 0x7f554814cd50 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {libpthread.so.0}
[2022-09-23T14:15:37.654Z DEBUG codelldb::dap_codec] <-- {"seq":24,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7FA4000","id":"7FFFF7FA4000","name":"libpthread.so.0","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libpthread.so.0","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libpthread.so.0","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.655Z DEBUG codelldb::debug_session] Debug event: 0x7f554814ca80 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {librt.so.1}
[2022-09-23T14:15:37.655Z DEBUG codelldb::dap_codec] <-- {"seq":25,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7F99000","id":"7FFFF7F99000","name":"librt.so.1","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/librt.so.1","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/librt.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.655Z DEBUG codelldb::debug_session] Debug event: 0x7f5548019110 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {libdl.so.2}
[2022-09-23T14:15:37.655Z DEBUG codelldb::dap_codec] <-- {"seq":26,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7F94000","id":"7FFFF7F94000","name":"libdl.so.2","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libdl.so.2","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libdl.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.661Z DEBUG codelldb::debug_session] Debug event: 0x7f5548013110 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {libm.so.6}
[2022-09-23T14:15:37.661Z DEBUG codelldb::dap_codec] <-- {"seq":27,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7E53000","id":"7FFFF7E53000","name":"libm.so.6","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libm.so.6","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libm.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.662Z DEBUG codelldb::debug_session] Debug event: 0x7f5548013110 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {libgcc_s.so.1}
[2022-09-23T14:15:37.662Z DEBUG codelldb::dap_codec] <-- {"seq":28,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7E39000","id":"7FFFF7E39000","name":"libgcc_s.so.1","path":"/nix/store/18fz9jnhmfkzkh6p1iwwwng4i7x4rag7-gcc-10.3.0-lib/lib/libgcc_s.so.1","symbolFilePath":"/nix/store/18fz9jnhmfkzkh6p1iwwwng4i7x4rag7-gcc-10.3.0-lib/lib/libgcc_s.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.674Z DEBUG codelldb::debug_session] Debug event: 0x7f55483605b0 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {libc.so.6}
[2022-09-23T14:15:37.674Z DEBUG codelldb::debug_session] Debug event: 0x7f5548369190 Event: broadcaster = 0x55c8e18032f8 (lldb.target), type = 0x00000002 (modules-loaded), data = {libpthread.so.0, librt.so.1, libdl.so.2, libm.so.6, libgcc_s.so.1, libc.so.6}
[2022-09-23T14:15:37.674Z DEBUG codelldb::dap_codec] <-- {"seq":29,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7C62000","id":"7FFFF7C62000","name":"libc.so.6","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libc.so.6","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libc.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.674Z DEBUG codelldb::dap_codec] <-- {"seq":30,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7FA4000","id":"7FFFF7FA4000","name":"libpthread.so.0","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libpthread.so.0","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libpthread.so.0","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.674Z DEBUG codelldb::dap_codec] <-- {"seq":31,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7F99000","id":"7FFFF7F99000","name":"librt.so.1","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/librt.so.1","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/librt.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.674Z DEBUG codelldb::dap_codec] <-- {"seq":32,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7F94000","id":"7FFFF7F94000","name":"libdl.so.2","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libdl.so.2","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libdl.so.2","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.674Z DEBUG codelldb::dap_codec] <-- {"seq":33,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7E53000","id":"7FFFF7E53000","name":"libm.so.6","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libm.so.6","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libm.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.674Z DEBUG codelldb::dap_codec] <-- {"seq":34,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7E39000","id":"7FFFF7E39000","name":"libgcc_s.so.1","path":"/nix/store/18fz9jnhmfkzkh6p1iwwwng4i7x4rag7-gcc-10.3.0-lib/lib/libgcc_s.so.1","symbolFilePath":"/nix/store/18fz9jnhmfkzkh6p1iwwwng4i7x4rag7-gcc-10.3.0-lib/lib/libgcc_s.so.1","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.674Z DEBUG codelldb::dap_codec] <-- {"seq":35,"type":"event","event":"module","body":{"module":{"addressRange":"7FFFF7C62000","id":"7FFFF7C62000","name":"libc.so.6","path":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libc.so.6","symbolFilePath":"/nix/store/q29bwjibv9gi9n86203s38n0577w09sx-glibc-2.33-117/lib/libc.so.6","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2022-09-23T14:15:37.681Z DEBUG codelldb::debug_session] Debug event: 0x7f56b8000df0 Event: broadcaster = 0x55c8ea5fc748 (lldb.process), type = 0x00000004 (stdout-available), data = { process = 0x55c8ea5fc710 (pid = 1398539), state = running}
[2022-09-23T14:15:37.681Z DEBUG codelldb::dap_codec] <-- {"seq":36,"type":"event","event":"output","body":{"category":"stdout","output":"clang-14: error: no input files\r\n"}}
[2022-09-23T14:15:37.682Z DEBUG codelldb::debug_session] Debug event: 0x7f56b8000ea0 Event: broadcaster = 0x55c8ea5fc748 (lldb.process), type = 0x00000004 (stdout-available), data = { process = 0x55c8ea5fc710 (pid = 1398539), state = running}
[2022-09-23T14:15:37.682Z DEBUG codelldb::debug_session] Debug event: 0x7f56140bbdd0 Event: broadcaster = 0x55c8ea5fc748 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x55c8ea5fc710 (pid = 1398539), state = exited}
[2022-09-23T14:15:37.682Z DEBUG codelldb::dap_codec] <-- {"seq":37,"type":"event","event":"output","body":{"output":"Process exited with code 1.\n"}}
[2022-09-23T14:15:37.682Z DEBUG codelldb::dap_codec] <-- {"seq":38,"type":"event","event":"exited","body":{"exitCode":1}}
[2022-09-23T14:15:37.682Z DEBUG codelldb::dap_codec] <-- {"seq":39,"type":"event","event":"terminated","body":{}}
[2022-09-23T14:15:37.739Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":8}
[2022-09-23T14:15:37.739Z DEBUG codelldb::dap_codec] <-- {"seq":40,"type":"response","request_seq":8,"success":true,"command":"threads","body":{"threads":[{"id":1398539,"name":"1: tid=1398539 \"clang\""}]}}
[2022-09-23T14:15:37.789Z DEBUG codelldb::dap_codec] --> {"command":"disconnect","arguments":{"restart":false,"terminateDebuggee":false},"type":"request","seq":9}
[2022-09-23T14:15:37.789Z DEBUG codelldb::dap_codec] <-- {"seq":41,"type":"response","request_seq":9,"success":true,"command":"disconnect"}
[2022-09-23T14:15:38.292Z DEBUG codelldb::dap_session] Client has disconnected
[2022-09-23T14:15:38.292Z DEBUG codelldb::debug_session] End of the requests stream
[2022-09-23T14:15:38.292Z DEBUG codelldb::debug_session] DebugSession::drop()
[2022-09-23T14:15:38.292Z DEBUG codelldb] End of debug session
[2022-09-23T14:15:38.303Z DEBUG codelldb] Exiting
Debug adapter exit code=0 (0x0), signal=null.

This is the problem:
Resolved debug configuration: {
  ...
  args: [ '${input:CompileCmdArgs}' ],
  ...

Unfortunately, args tokenization, which happens during launch config resolution, is done before VSCode performs substitution.
You'll need to paste clang arguments directly into launch.json, being careful about double quote escaping.
Though it look like you are trying to do it programmatically...  Well, one option is to perform tokenization on the debugger side, using Python scripting.   If you run a script as a part of preRunCommands, you can modify debuggee's launch environment:
# script.py
import lldb, shlex
launch_info = lldb.target.GetLaunchInfo()
args = shlex.split(launch_info.GetArgumentAtIndex(0))
launch_info.SetArguments(args, False)
lldb.target.SetLaunchInfo(launch_info)

See https://lldb.llvm.org/python_api/lldb.SBLaunchInfo.html
And then in you launch configuration: "preRunCommands": ["command script import .../script.py"]

Thanks! That sounds plausible. I'll give the Python script idea a go tomorrow.

Unfortunately, args tokenization, which happens during launch config resolution, is done before VSCode performs substitution.

Is this unique to the LLDB extension? Because I did have this working with the cppdbg extension? Do they work differently with re: to launch config resolution?

Is this unique to the LLDB extension?

Could be.   CodeLLDB performs args tokenization on the extension side, perhaps cppdbg does this inside the debug adapter.

Could be. CodeLLDB performs args tokenization on the extension side, perhaps cppdbg does this inside the debug adapter.

Right.
I tried your suggested python script, but lldb.target appears to be of type NoneType - so it's not finding it. Is this still extension related or is my setup wrong?
I did add lldb -pto PYTHONPATH as per the LLDB documentation.

Closing as this was expected behaviour. Many thanks for your help @vadimcn!


Enable histogram with variable bin lengths

First of all, thanks for the work on this great package. We've just discovered it recently and it will surely provide some benefit for our daily work in our team.
Painpoint
Having numerical columns with a dense area of values and some extreme outliers, the default histogram does not provide any useful insight because there is basically only one bin with almost all values (dense area) and the other bins are almost empty (outliers).
Solution
Instead of fixed bin widths, it would be useful to use algorithms with variable bin widths to account for unevenly distributed densities. AstroML already has two implementations for this (see here). The algorithms are not to complicated, so that they could be vendored without introducing a new dependency (see here)  @jakevdp.

Great suggestion. I'll look into it.

The Astropy implementations are a better reference: http://docs.astropy.org/en/stable/visualization/histogram.html


Documentation and new_stack

In your README, you said that you did not test your stack depending on linked list, so I implemented my new freestanding one, and I add documentation support to your project. Just type doxygen to generate fresh HTML documents!

Implementing a new stack is redundandent.
Not looking for doxygen at the moment. Project at extremly early stage. Unneccesary dependency/complication.
Closing the request.

Sorry, no offense, but letting stack depending on linked list is somewhat stupid. You tag this repo beginner-project that means it needs to be readable to other beginners, so you should be making the stack simpler.

A stack over a linked list is extremely easy to comprehend, not to mention easy to implement. By itself, there is no DS called stack. In essence, it is built on top of some other DS, like an array, vector or a linked list.  Moreover, comprehension is not the aim of the project.
What you had implemented is basically a form of vector.
The correct way forward is to implement a vector DS, then something like v_stack, which would mean stack using a vector. This removes unnecessary redundancy in the code base.
However, I do not see any reason to use a vector over the linked list for stack after all the complexity of push and pop over stack using linked list is O(1).
From my perspective, having to use realloc() when stack size increases put a significant overhead, compared to a linked list. The only gain I see is the reduction of size_t memory from each node, which seems like a tradeoff in favor of linked list implementation.

I stand corrected. It seems Vector based stack does work better when the data units to be stored is smaller in size, also benefits from caching.
LL is superior when storing complex structures due to space saving. Imagine having a Large structure ( e.g. TCB ), having a vector make a 2x allocation for it hoping future operations.
Seems the correct way to go is to have two container adaptors for stack - one for LL and one based on vector or something more optimal e.g. std::dequeue in STL.

Well, my vector based stack is actually taken from Jerry Cain's Programming Paradigms Lecture from iTunes U. I suggest you to watch some of the lecture videos because that inspires me a lot of generic code


ENGOPS-1634: Custom bk-agent-scaller that runs on funnel agent medium…

… & small queus

hey @dgheo  judging by the PR name looks like you might've wanted to open this to your internal forked repo. are you sure this is the correct location for your PR?


system cost vs. cost system

Some frameworks used the parameter "cost system" instead of "system cost". Please change to "system cost", thanks! :)

Hi :)
I have corrected this for Balmorel and will upload new results as soon as i get the timestamps to work with me!

great thanks Stefanie ! :)


feat: Change the icon loading mode

appendIcon and createIcon icon loading mode is changed to html to facilitate css to change icon color

css change color
.djs-context-pad {
  > .group {
    .create-append-anything-append-element {
      fill: #1e80ff !important;
    }
  }
}
.djs-palette-entries {
  > .group {
    .create-append-anything-create-element {
      fill: #1e80ff !important;
    }
  }
}

Closes #5

 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.

Thanks for your contribution @zxiaozhou ! Could you please lint your code to match our code style and CI does not fail? Make sure npm run lint runs smoothly.

@smbea I'll check later. Maybe I do have a problem with my local style

@falko Have taken care of.

@smbea Have taken care of.


Not creating new Contact object for Secondary Device1

when we have 4 Keepers from OBHR

Secondary Device
Two contact
after upgrade it goes to NBHR manage backup and completes last keeper to complete Level 3 and the reshare start then it not get new contact object with name Secondary Device1

-Verified this issue on Staging app v1.6.0(277)


Satellaview

Could you add the Satellaview broadcasting system as a system for the frontend please?

Added Satellaview to platforms. Should note pretty much no one has cover art or metadata for Satellaview so we're stuck with Libretro's.


Add CZML HeightReference to all supported geometries

Small follow up to #7692
@hpinkos can you do a quick review/merge?

Thanks for the pull request @mramato!

:heavy_check_mark: Signed CLA found.
:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

👍 looks good, thanks @mramato !

CI is green, ready to merge.


[auto-bump] dependency by coffeegoddd

:coffee: An Automated Dependency Version Bump PR :crown:
Initial Changes
The initial changes contained in this PR were produced by go geting the dependency.
$ cd ./go
$ go get github.com/dolthub/<dependency>/go@<commit>
$ go mod tidy

Before Merging
This PR must have passing CI and a review before merging.
After Merging
An automatic PR will be opened against the LD repo that bumps the bounties version there.

This PR has been superseded by https://github.com/dolthub/bounties/pull/950

This PR has been superseded by https://github.com/dolthub/bounties/pull/951


Does Waymo provides the geographic coordinates (latitude, longitude, altitude) of the starting point (origin) of each segment

Hope you're doing great! I'm working on a project with the Waymo Open Dataset and I ran into a bit of a puzzle. I need to convert the "global" coordinates within each segment to actual geographic coordinates (like latitude and longitude), and for that, I need to know if the dataset provides the geographic origin (latitude, longitude, altitude) for each segment.
To be more precise, I have the global coordinates of the ego vehicle (global_center_x, global_center_y, global_center_z) which are directly extracted from the transformation matrix (sdc_pose) provided by the Waymo dataset. However, this global coordinate has no origin. They are specific for each segment. Thus, I am unable to locate each segment in Google Earth or GIS.

We do not currently provide geolocation data for the dataset.


 First one has to do about my feat or fix, then I have to commit again to pass lint rules XD

Coverage remained the same at 100.0% when pulling 8435eac78bccb79fea56395f6f568d681c7671e6 on k1r0s:patch-2 into 10cb57e80cb136337ed60ede8ddc8673ae98be81 on alexjoverm:master.

@k1r0s thanks for your PR, and sorry but I have to reject it.
The reason is I intentionally moved the lint check to the prepush hook, along with the test and so on. The reason is people can make multiple commits before pushing, and it's just quicker to check that only once instead of every commit, it becomes a bit annoying.
But of course, that's an opinionated statement, as it is the starter, so at the end every user must modify it to fit their needs, just as you did, being the starter just an entry point for a library project.


Create 0000-01-02-MehdiM20.md

The second slide to our introductory slides on Github slideshow.

with third items

with third comments.


[JN-828] Track viewed language in form responses

DESCRIPTION
Updates the Answer table to store the code of the language that was being viewed when the participant submitted their responses. Also displays the language name in the form response admin view:

TO TEST:  (simple manual steps for confirming core behavior -- used for pre-release checks)
Test via Populate:

Reboot AdminApi + Admin UI
Repopulate demo: ./scripts/populate_portal.sh demo
View the pre-reg, consent, and The Basics responses for Jonas Salk. Verify that you see a few "Answered in ..." displaying next to the questionStableId. Note that not all The Basics answers come pre-populated with language data: https://localhost:3000/demo/studies/heartdemo/env/sandbox/participants/HDSALK/consents/hd_hd_consent
Verify no regressions in this view for a single-language study (i.e. OurHealth): https://localhost:3000/ourhealth/studies/ourheart/env/sandbox/participants/OHSALK/surveys/oh_oh_basicInfo

Test with new participant:

Reboot ParticipantApi + Participant UI (I suggest booting the UI with REACT_APP_UNAUTHED_LOGIN=true HTTPS=true npm -w ui-participant start so you can bypass B2C)
Register as a new user in the Heart Demo study: https://sandbox.demo.localhost:3001
Go to the Admin UI and view the form response data for your new participant
Verify that you can see the language used when you filled out the form

@connorlbark that's a great catch. fixed in https://github.com/broadinstitute/juniper/pull/737/commits/42620883897f31eed0cc61df9ef37e852d029a14


[bzip2:x64-windows] build failure

Host Environment

OS: Windows 10
Compiler: Visual Studio 2019 version 16.1

To Reproduce
Steps to reproduce the behavior:
./vcpkg install bzip2:x64-windows
Failure logs
C:\Library\vcpkg>vcpkg install bzip2:x64-windows
Computing installation plan...
The following packages will be built and installed:
bzip2[core]:x64-windows
Detecting compiler hash for triplet x64-windows...
Starting package 1/1: bzip2:x64-windows
Building package bzip2[core]:x64-windows...
Could not locate cached archive: C:\Users\frump\AppData\Local\vcpkg\archives\0e\0ec0bc9db97e4bc77bd00760c2552815b64bfb0c.zip
-- Using cached C:/Library/vcpkg/downloads/bzip2-1.0.6.tar.gz
-- Cleaning sources at C:/Library/vcpkg/buildtrees/bzip2/src/1.0.6-8838f21f8e.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/Library/vcpkg/downloads/bzip2-1.0.6.tar.gz
-- Applying patch fix-import-export-macros.patch
-- Applying patch fix-windows-include.patch
-- Using source at C:/Library/vcpkg/buildtrees/bzip2/src/1.0.6-8838f21f8e.clean
-- Configuring x64-windows
-- Building x64-windows-dbg
-- Building x64-windows-rel
-- Fixing pkgconfig
-- Acquiring MSYS Packages...
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):
Command failed: C:/Library/vcpkg/downloads/tools/msys2/msys64/usr/bin/bash.exe --noprofile --norc -c "pacman -S --noconfirm --needed pkg-config"
Working Directory: C:/Library/vcpkg/downloads/tools/msys2
Error code: 1
See logs for more information:
C:\Library\vcpkg\buildtrees\bzip2\msys-pacman-x64-windows-err.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_acquire_msys.cmake:127 (vcpkg_execute_required_process)
scripts/cmake/vcpkg_fixup_pkgconfig.cmake:281 (vcpkg_acquire_msys)
ports/bzip2/portfile.cmake:51 (vcpkg_fixup_pkgconfig)
scripts/ports.cmake:79 (include)
Error: Building package bzip2:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with .\vcpkg update, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
Package: bzip2:x64-windows
Vcpkg version: 2020.06.15-nohash
Additionally, attach any relevant sections from the log files above.
C:\Library\vcpkg\buildtrees\bzip2\msys-pacman-x64-windows-err.log
error: mingw32: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown
error: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" could not be looked up remotely
error: mingw64: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown
error: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" could not be looked up remotely
error: msys: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown
error: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" could not be looked up remotely
error: database 'mingw32' is not valid (invalid or corrupted database (PGP signature))
error: database 'mingw64' is not valid (invalid or corrupted database (PGP signature))
error: database 'msys' is not valid (invalid or corrupted database (PGP signature))

I fixed it temporarily with https://github.com/microsoft/vcpkg/issues/12567#issuecomment-663807503

@ljere, currently this issue fixed by PR #12467 instead, the PR has been merged, please get latest source and try again.


Preserve handler filters if present (allows Filter(s) to work with coloredlogs)

A fix for issue https://github.com/xolox/python-coloredlogs/issues/32 which I've recently encountered myself.
I was able to trace the problem to the way the handlers are replaced, that's when any existing filters get discarded.
The fix is to preserve the existing filters and apply them back once the new handler has been created

Coverage increased (+0.04%) to 91.586% when pulling 95e6c763e3186c89da92c2f8e0813d417c42ecab on eblis:master into<PHONE_NUMBER>bc39057f824c545f2decab49c019ad on xolox:master.

Hi @eblis and thanks for the pull request. I've just published coloredlogs release 14.3 which incorporates these changes. Cheers!


The mountain disappear from chart when user change minimum X-axis value

SEVERITY:  Major
MODULE: Mountain Chart
PLATFORM:

Windows 7 / Chrome 49.0
Windows 7 / Firefox 44.0
Windows 7 / Internet Explorer 11.0

STEPS TO REPRODUCE:

Navigate to the URL: http://www.gapminder.org/tools/mountain
Mountain chart will be loaded
Click on options
Click on X & Y
Click on X axis limit and input min value as “0”

ACTUAL RESULTS:
The mountain disappeared when user input min value of X as “0”
EXPECTED RESULTS:
The chart should adjust according to X axis limit
SCREENSHOT:

https://github.com/Gapminder/vizabi/pull/1680

https://github.com/Gapminder/vizabi/pull/1698


FLEX-4355 ~ Adds get tariff status feature.

retest this please

I stopped the pull request build after pointing the submodules to development.


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v3.2 to before v4.9.300",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0cbf32e1681d870632a1772601cbaadd996dc978",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=262550f29c750f7876b6ed1244281e72b64ebffb"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "0cbf32e1681d870632a1772601cbaadd996dc978",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "262550f29c750f7876b6ed1244281e72b64ebffb",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v4.9.300 by commit 262550f29c750f7876b6ed1244281e72b64ebffb, it was introduced in version v3.2 by commit 0cbf32e1681d870632a1772601cbaadd996dc978. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2022-1000082


Update path to sabhiram/go-gitignore

Fixes #574
See https://github.com/sabhiram/go-gitignore/commit/24b2447174be370e56ea86a72f00a76258606067

@prasmussen I know this tool is no longer maintained, but some of us still use it because we haven't been able to update to an alternative yet. Can we get this PR merged so it remains usable please?


[terra-section-header] SectionHeader a11y updates

Summary

What was changed:
The SectionHeader component was updated to meet accessibility standards.
Why it was changed:
The change was made so that the component was compliant with our accessibility strategy.
Testing

This change was tested using:

[X] WDIO
[X] Jest
[ ] Visual testing (please attach a screenshot or recording)
[ ] Other (please describe below)
[ ] No tests are needed

Reviews
In addition to engineering reviews, this PR needs:

[X] UX review
[X] Accessibility review
[ ] Functional review

Additional Details
N/A
This PR resolves:
UXPLATFORM-9794

Thank you for contributing to Terra.
@cerner/terra

Since this PR has opened for Major version release we can remove some of the todo's that we had planned to do in next MVB release of terra-section-header

We need to remove the title prop from section-header : https://github.com/cerner/terra-core/blob/376977c875123802ada4bc34bca6c606755e65b6/packages/terra-section-header/src/SectionHeader.jsx#L22
We need to remove default value for level prop : https://github.com/cerner/terra-core/blob/376977c875123802ada4bc34bca6c606755e65b6/packages/terra-section-header/src/SectionHeader.jsx#L147

I noticed an error on Axe tool ( which is not related to the changes of this PR ). It looks like we have added heading element h2 on section-header example template which is causing the above Axe violation. While updating the prop name from title to text on examples template was not updated to use new prop due to which empty h2 being added for each of the section-header example.

I am thinking instead of updating the example template with new prop name text. we can remove the h2 element from template since we already have an heading that is being provided from terra-dev-site.

I validated with Edge/JAWS and Safari/VoiceOver. Keyboard and AT interactions worked as required.

Can we update the prop description of level prop. level prop is required prop from next MVB
  /**
   * ![IMPORTANT](https://badgen.net/badge/UX/Accessibility/blue)
   * Sets the heading level. One of `1`, `2`, `3`, `4`, `5`, `6`.
   * `level` should be specified explicitly to allow screen readers to identify headers consistently.
   */
  level: PropTypes.oneOf([1, 2, 3, 4, 5, 6]),

Can we update the prop description of level prop. level prop is required prop from next MVB
  /**
   * ![IMPORTANT](https://badgen.net/badge/UX/Accessibility/blue)
   * Sets the heading level. One of `1`, `2`, `3`, `4`, `5`, `6`.
   * `level` should be specified explicitly to allow screen readers to identify headers consistently.
   */
  level: PropTypes.oneOf([1, 2, 3, 4, 5, 6]),

I don't understand why this prop would need to be required.

Can we update the prop description of level prop. level prop is required prop from next MVB
  /**
   * ![IMPORTANT](https://badgen.net/badge/UX/Accessibility/blue)
   * Sets the heading level. One of `1`, `2`, `3`, `4`, `5`, `6`.
   * `level` should be specified explicitly to allow screen readers to identify headers consistently.
   */
  level: PropTypes.oneOf([1, 2, 3, 4, 5, 6]),

@supreethmr we should log a Jira to do an audit and make all the MVB changes before release e.g. remove deprecation warnings etc.

There's been confusion on this in the past, including myself, but Fusion theme should still get the silly blue glow border.
Otherwise, looks great!

Can we update the prop description of level prop. level prop is required prop from next MVB
  /**
   * ![IMPORTANT](https://badgen.net/badge/UX/Accessibility/blue)
   * Sets the heading level. One of `1`, `2`, `3`, `4`, `5`, `6`.
   * `level` should be specified explicitly to allow screen readers to identify headers consistently.
   */
  level: PropTypes.oneOf([1, 2, 3, 4, 5, 6]),

I don't understand why this prop would need to be required.

Because to ensure header components are always provided with valid heading levels we need this prop to be required as explained here : https://engineering.cerner.com/terra-core/components/cerner-terra-core-docs/action-header/accessibility-guide#heading-level-order-and-arrangement-always

Can we update the prop description of level prop. level prop is required prop from next MVB
  /**
   * ![IMPORTANT](https://badgen.net/badge/UX/Accessibility/blue)
   * Sets the heading level. One of `1`, `2`, `3`, `4`, `5`, `6`.
   * `level` should be specified explicitly to allow screen readers to identify headers consistently.
   */
  level: PropTypes.oneOf([1, 2, 3, 4, 5, 6]),

@supreethmr we should log a Jira to do an audit and make all the MVB changes before release e.g. remove deprecation warnings etc.

I have gone through the MVB PR's which we had for header components. There were only two MVB changes that were done 1. Replacing Title Prop with Text prop .
2. Removal of Default value.
https://github.com/cerner/terra-core/pull/3637/files#diff-730a23e7b4aa5e890677524012b92eac20af22dd6bdf26203ac82387daed394c


Set min and max zoom/scale level

First: great library!
Is there a possibility to set the min and max zoom level? Currently it reverts to a min zoom level defined by the views bounds.

PhotoViewAttacher photoView = new PhotoViewAttacher(img);
photoView.setMaximumScale(10);

We can use also PhotoView#setMaximumScale()


Forward arguments

Since the initial release, the bundle type, the compiler options and the
imports were not properly forwarded from JS to Rust.
We now forward them, and added some tests to verify this behaviour.
Closes https://github.com/denoland/deno_emit/issues/83, https://github.com/denoland/deno_emit/issues/69, https://github.com/denoland/deno_emit/issues/29.

This will be ready once #97 is merged.

@dsherret This is ready!

@dsherret It also closes #69 and #29. That didn't work automatically because I didn't format it properly in the PR description.


Missing gofmt

The go distribution contains two executables; go and gofmt. Only go is exposed (through .proto/{bin,shims} by proto.

Patched here, will land in the next proto.


Network activity went down today.

Guys, something happened around 2:20 UTC.
my command: docker run --pull=always ghcr.io/arriven/db1000n:latest
Unfortunately, cant track if it was config changes.

I don't recall any config changes at that time. Need to investigate

I don't have vpn, btw.
And there is no packet loss:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9001
................................................................................................
RX packets 1403319  bytes 88604937 (84.5 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 283605121  bytes<PHONE_NUMBER>523 (949.6 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
uptime:
12:28:11 up 15:12,  2 users,  load average: 3.19, 2.81, 2.60
Let me know if I can help with any info.

I don't have any ideas on possible cause yet so there's no ETA yet. I'll try to look into it between other critical and high priority tasks since I'm genuinely interested in finding the cause but the impact of this particular issue is relatively low. You can also play with different custom configurations in the meanwhile to try to reproduce this behavior and get more understanding on it if you have some free time

Maybe it's just a case of new json file with smaller list of files?
If you launch db1000n with previous json (from github history) net load is still high.
https://raw.githubusercontent.com/db1000n-coordinators/LoadTestConfig/0287df8617728449359bf0f71fa7d59fc4d627ed/config.json

Maybe it's just a case of new json file with smaller list of sites?
If you launch db1000n with previous json (from github history) net load is still high.
./db1000n -c https://raw.githubusercontent.com/db1000n-coordinators/LoadTestConfig/0287df8617728449359bf0f71fa7d59fc4d627ed/config.json

Can you please give approximate numbers on how many targets was, and is now? I hardly believe it can go down from 1 container consumes 80% cpu core to < 10% cpu core because of a smaller target list.

Can you please give approximate numbers on how many targets was, and is now? I hardly believe it can go down from 1 container consumes 80% cpu core to < 10% cpu core because of a smaller target list.

First of all, my mistake, list is not smaller, just different.
I'm not sure what't the cause, maybe it is:
-different ddos protection
-some servers just not available
-different protocols(ports) generate different traffic
But I can clearly see the difference between load on cpu and network between two json files.
In one case it is 95% load with 10-40 MB/s on my particular vps and in second case it is 5% and 10-100 KB/s. Around 5 instances of db1000n launched in both cases.

./db1000n -c https://raw.githubusercontent.com/db1000n-coordinators/LoadTestConfig/0287df8617728449359bf0f71fa7d59fc4d627ed/config.json
./db1000n -c https://github.com/db1000n-coordinators/LoadTestConfig/blob/main/config.json

Yes, I can confirm with that configuration metrics went up to where it was:
https://raw.githubusercontent.com/db1000n-coordinators/LoadTestConfig/0287df8617728449359bf0f71fa7d59fc4d627ed/config.json:

CPU as well. went up to 80-90%.
Sorry for the false alarm. I didn't know where to look for the config history.

The difference is, that in conf with higher usage, there is a "client": {"async": "true"}. Not sure who and why removed this option from some of the targets.

confirm, have the same issue. CPU load is down, network - almost 0

I've been referencing this in other issues, but essentially more traffic doesn't always mean better DDoS. We're trying different patterns to see whether they get blocked by the target (and even source in case of cloud providers)

@Arriven so can you confirm now that async requests are not necessary now in the current load config? In such way, we will need to run more containers per cpu core if we stick to not use async as of now.

I've tried to explain some basic ideas on DDoS performance here

Ok I see that you are trying to implement here. So 1 container is sufficient for this type of attack (as unique VM IP is required). To utlilize VM resources available for me, I will sidecar some other load testing software on the VMs.

I think we'll do it the following way: create a separate config file that uses advanced techniques and generate less traffic and create a separate docker image pointing to that config. Regular users will use config that maximizes traffic for now but advanced users on (especially those using VMs) will be able to use more advanced techniques if they wish so (see #153 for why this might be important)

so was the bug fixed or not?
I just tried to pull docker and didn't see any traffic again...
config still the same..


Unable to Load Configuration from S3 Folder using Spring Cloud Config: Key Not Found

Issue Description:
I'm trying to access configuration files located inside a folder in an S3 bucket using Spring Cloud Config. Below is the folder structure in S3:
bucket1/
└── config/
    └── application-dev.yml

Here is the relevant Spring configuration:
spring:
  profiles:
    active: awss3
  cloud:
    config:
      server:
        awss3:
          region: us-east-1
          bucket: bucket1/config

When trying to access the configuration via http://localhost:8888/application/dev, I am encountering an issue. The debug logs indicate that the S3 key was not found. The encoded URL appears as /bucket1%2Fconfig/application-dev.yml, and it seems like the folder structure or path encoding might be the cause.
Debug Log Excerpt:
Key not found: /bucket1%2Fconfig/application-dev.yml

Question:
How can I resolve this issue to correctly access the application-dev.yml file from the config folder in the S3 bucket?
(or)
Support for subfolders in a S3 bucket is not available ?
Package versions:
spring-cloud-config-server - 4.1.3
software.amazon.awssdk (s3) - 2.28.1
Any help or suggestions would be appreciated!

According to the S3 docs...

Bucket names can consist only of lowercase letters, numbers, dots (.), and hyphens (-).

True. The bucket name is bucket1 and the sub-folder name is config inside which i have the application-dev.yml file.
Is there any way to access the application-dev.yml file ?

Yes there is an example in the integration test we have
https://github.com/spring-cloud/spring-cloud-config/blob/main/spring-cloud-config-server/src/test/java/org/springframework/cloud/config/server/AwsS3IntegrationTests.java#L94-L95

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

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.


Improve locust scale tests

Related Issue
N/A
Description of changes
Improvements to the locust scale tests:

Add templates to simulate clusters with 100k and 150k resources.
Adds retry logic when receiving 429 Too busy response.

/hold
/lgtm

/unhold


⚠ SceneTime has degraded performance

In fa1da4a, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 2564 ms

Resolved: SceneTime performance has improved in 95b113c after 13 minutes.


Rust TCP port not reachable

Describe the issue you are having
Answer: The server is not reachable by the rust tcp port (28015).
What was you doing before it happened
Answer: Added the docker template and switched to bridge mode, enabled port forwarding on my router.
Screenshots

What are you running on (please complete the following information):

OS: Unraid 6.8.3
Browser: Firefox
Hardware: Ubiquiti USG

Additional information
I waited for the server to start up and tested port forwarding with https://www.yougetsignal.com/tools/open-ports/
For comparison I used the plex server and port forwarding (plex port 32400) which worked as long as the plex docker ran on the unraid server. But even when the rust server is running, I can't see the port 28015 being tunneled through to the server. Even more fascinating is the fact, that the udp port seems to work fine as I can connect to the rust server in my home network (and I guess udp is used for that, but tcp is used for discovery from remote)
When I forward the rcon port (28016), the port forwarding works correctly as well (28016 is reachable from outside, using above web tool). The same applies for the webui port, if I forward it (8080 but 8082 in my case).
Maybe you have some insights or further hints pointing me in the right direction?
Edit: I had UPnP enabled on my router and saw the ports were automatically added for forwarding, still the only port not reachable from outside was 28015.

Oh gosh, never mind!
Discovery of servers is by port 28016, as soon as I forwarded it as well, the server was visible. Strange though that it did not work on my setup with upnp, but as it works now I'll close this issue


Enable kinks in (fuselage) profiles

For many configurations, modeling kinks will be an important feature.
The feature should allow:

Define kinks at a specified interpolation point
Define parameters, at which the points are interpolated. This allows, that e.g. kinks of two profiles meet exactly and adds more freedom to the profile interpolation.
Both require a CPACS defintion change of the profiles

Here's a first snapshot, of how the current status is:

@rmaierl, @sdeinert Is this, what you are looking for?

Looks good!

@sdeinert, @rmaierl, @MarAlder I have a first (hopefully) working version at the branch https://github.com/DLR-SC/tigl/tree/profiles_with_kinks
There is also an example file https://github.com/DLR-SC/tigl/blob/profiles_with_kinks/tests/unittests/TestData/simpletest-fuselagekinks.cpacs.xml, which demonstrates the concept.


Crash if third party cookies are blocked

Version
5.1.0
Browser and OS info
Chrome  73.0.3683.103 / Windows 10
Steps to reproduce

Open Chrome Dev Tools
Click on Vue tab
Click on settings, vuex state, or other tabs

What is expected?
Anything to happen.
What is actually happening?
Nothing happens.

Would like an update on this, vue-dev-tools is completely broken and unusable for me.

After trying again, it works initially but breaks the moment I click on the settings button.

I have similar situation.
Extension version: 5.1.0
Browser: Chrome Version 73.0.3683.103 (Official Build) (64-bit)
OS: macOS Mojave Version 10.14.3
Steps to reproduce

Open Chrome Dev Tools
Click on Vue tab

What is expected?
Everything to work fine and fluently.
What is actually happening?
Entire browser tab and devtool is frozen and broken.
My solution is to install previous version ( 5.0.0) where almost everything works as expected.

where can I get the 5.0.0 v ? @index23

Can confirm happens with Vivaldi (Chromium 73.0.3683.105) on Linux and MacOS Mojave. Everything works fine until settings icon is clicked.
@DespertaWeb You can get releases from releases tab and follow steps for manual installation

I can't reproduce on Chrome 73.0.3683.103 / Win 10.

Same problem here:
Extension version: 5.1.0
Browser: Chrome 74.0.3729.108
OS: Windows 10 Pro (1809)
Steps to reproduce

Open Chrome Dev Tools
Click on Vue Tab
Click on Settings inside Vue Tab

What is expected?
Settings tab opens
What is actually happening?
Browser Tab and Chrome Dev Tools freeze.
Version 5.0.5 is working just fine.

Could you right-click on the devtools, select Inspect (or similar) and share the content of the console in the opened chrome devtools window?

shell.js:7997 Main._createAppUI: 76.946044921875ms
shell.js:7997 Main._showAppUI: 84.51611328125ms
shell.js:7997 Main._initializeTarget: 26.43798828125ms
shell.js:7997 Main._lateInitialization: 11.224853515625ms
devtools.js:7 TypeError: Cannot read property '$options' of undefined
    at ow.c.r.a.config.errorHandler (devtools.js:51)
    at ie (devtools.js:7)
    at ne (devtools.js:7)
    at Array.<anonymous> (devtools.js:7)
    at le (devtools.js:7)
devtools.js:7 DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
    at a.provide (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:51:13275)
    at Le (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:15082)
    at a.t._init (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:34428)
    at new a (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:35694)
    at an (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:21615)
    at init (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:20481)
    at p (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:44114)
    at h (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:43743)
    at H (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:46346)
    at L (chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/build/devtools.js:7:47135)

Are you blocking third-party cookies?

Same issue here, and yes I'm blocking third-party cookies

That's the reason then. We may need to refactor the extension to use chrome.storage instead of localStorage.

@Akryum I unchecked "Block 3rd Party" Cookies and now its working.
It was on by default, and I imagine it would be same for more browsers in future.

Back to v5 and up & running!
great! thanx @nickdex

@Akryum Appreciate you putting in the work to fix this.
When do you think this might be released (week, month, 3 month?)?
I'd really like to turn third party cookies back off!

What worked for me is to add an exception for the Extension URL.
Go to Settings --> Advanced --> Site settings --> Cookies.
With 'Block third-party cookies' enabled press the 'Add' button next to allow and enter chrome-extension://nhdogjmejiglipccpnnnanhbledajbpd/. Click add.
You should now see a 'Vue devtools' icon in the list of allowed cookies. Reload Devtools and you should be able to go to the settings tab.


prebundle js can not be loaded in device when using a proxy server

Now  I am using 0.28. It works as before in Emulator. But when I change to real iphone,  with a proxy server setting in my iphone in order to access some test host,  "Loading from pre-bundled fill..." sign is always visible, and bundle js can never be loaded.
With very limited knowledge with Object C, I don't know what has been changed exactly. Anyway I found the way to solve this :
Change the ip address manually in RCTBundleURLProvider.m. It is a little bit more annoying than before when we had to change 'localhost' in AppDelegate.m to run app in device.
I just wonder if it could be a little bit easier to run in device while using a proxy server.

Hey, we use Github for issues only and all questions should be asked on StackOverflow. This is for us to keep the number of issues smaller so that we can iterate on React Native versions faster and provide you with the better developer experience.
If you have any ideas on how we could improve the entire process, please share your thoughts on React Native Community group.


React 18 whitespace not working

After upgrading to React 18, when I type whitespaces into the editor, nothing is inserted and the placeholder still renders.
I've confirmed that the v2 beta versions have it solved but since it's still beta, we're hesitant to do the upgrade.
CodeSandbox
Ticket due diligence

[ ] I have verified that the issue persists under ReactQuill v2.0.0-beta.2
[x] I can't use the beta version for other reasons

ReactQuill version

[ ] master
[ ] v2.0.0-beta.2
[ ] v2.0.0-beta.1
[x] 1.3.5
[ ] 1.3.4 or older
[ ] Other (fork)

I have the same issue...

@maxstue
Unfortunately no. We ended up bumping our react quill version to v2 beta which solved the issue.

I have the same issue

@nadrianfikri I reinstalled the 2.0.0-beta.4 Version and than the problem was gone🤔

I solved it this way

@b-hexsoul discovered that after upgrading to react-18 we needed to add the prop preserveWhitespace to our <ReactQuill instance.

this looks ok for me :
    const ref = React.createRef<ReactQuill>()

    useEffect(() => {
        let x = ref.current?.getEditor();
        if (x) {
            x.on('text-change', function (delta, oldDelta, source) {
                let innerHtml = x?.root.innerHTML;
                if (innerHtml)
                   console.log(innerHtml)
            })
        }
    }, [])

        return (<>
            <ReactQuill
                ref={ref}
                theme="snow"
                value={props.value} />
        </>);

I did like @taochu and @maxstue and upgraded to beta and everything worked again. I had updated a project to React 18 which introduced this bug. Didn't have to change anything else in the code, only updating the package and running the project again. Thanks guys!

@Inakitajes nobody really knows, thats why I created an Issue at my current Project/Company to switch to another editor (lexical from facebook looks really goot ;) )

try adding  preserveWhitespace property.
ex:


Remove ability to create an environment

When https://github.com/30x/enrober/issues/86 is completed, we need to remove shipyarctl create environment and rely on enrober creating environments on an as-needed basis.

Should we get rid of the shipyardctl get | delete | patch environment commands as well?

I think we should keep them for now.  The idea is we want all environments to be created automatically, although we've not really decided on which Shipyard events would create them beyond creating a deployment.  That being said, you'll still need a way to get the details, update and delete an environment after it's been created.
Maybe @mpnally can comment here or in https://github.com/30x/enrober/issues/86 to suggest which Shipyard APIs should create an environment automatically.

In that case, get and patch cmds are fine to stay, but I'd be a bit hesitant about keeping the delete cmd, in case a user uses it out of curiosity, but can't create another without again going through whatever process we create to automate creating environments...a question of how much rope we want to give users to hang themselves with 😄  maybe we can have the inverse of whatever process creates environments, also delete them?

I'll hopefully have at least a first pass of #86 done today.

I'm fine to keep delete if it is going to be useful, just thought I'd throw a wrench into things 😛

The idea of potentially editing/deleting environments that you can't create manually likely justifies a little bit more discussion.

I agree it makes sense to keep shipyardctl get environment -o acme -e test. This command gives you the "container info" for your Edge environment. I do not think it makes sense to have delete, since the only thing that exists in the user model is the Edge environment and so the only thing you can delete is the edge environment. shipyardctl patch environment -o acme -e test could make sense for patching the "container info" for an edge environment. What information can you patch? I believe that some of the information we used to patch is now disappearing into KVM maps. Is there anything left? If not, se should remove shipyardctl patch
Other than deploy, I'm not sure if other actions need to trigger creation of K8S resources.

I agree that delete is an edge case that might not make sense to support.  Maybe we keep create/delete APIs but do not expose them?  I can see these being useful for cleanup/debugging.  Thoughts?
And as I was about to submit this, the more I think that since we're currently mapping Shipyard environments to namespaces, we could remove these APIs and just use core Kubernetes commands for cleanup/debugging.

I agree w/ @whitlockjc in the above that using k8s commands/kubectl should be good enough to debug/cleanup....after all, kubectl delete namespace does a cascading delete of all resources inside of it, makes for quick cleanup

Yes, for debugging we can just use K8S commands. shipyardctl get hosted-target-info -o acme -e test would give me info across multiple regions, so is not just a simple K8S command. It might also give me info on not-yet-deployed hosted-targets, and also previosuly-existed-but-now-deleted hosted-targets. K8S would not know about those.

Worth noting that the only thing a patch on an environment could edit is the list of hostNames that are stored on the environment. Also worth questioning whether we want this information to still be stored as annotations or if we should be storing this information as a secret/configMap.

hostNames should come from Edge. Edge already knows this information—we just need to retrieve it. If this is all we patch, then patch can be removed.

@whitlockjc I think the primary user of the hostNames annotation is @whitlockjc when he generates the nginx config. I don't know what the consequences would be for him of moving the data to a configMap. All the applications we have written so far get the hostName from the host header in the incoming request, so they don't need to get it from an environment variable and don't need a configMap. However, having an option to get it from an environment variable would be useful for people who can't or won't get the info from a host header. An example would be a daemon (in the unix sense, not the K8S sense) that initiates requests that are not part of the processing of an incoming request. For those people, having the hostNames in a configMap might be useful.

It's worth pointing out that in the current state there is no validation to confirm that a user "owns" the hostName they are assigning to an environment. We simply have a first come first serve system right now. If we can solve the larger issue of k8s controller -> edge communication then it may be better to list hostNames as a subset of virtual hosts at the edge level.

I think if we do this based on the Apigee Edge environment, it would make it impossible for someone to steal someone's host.  But of course, this just makes the issue discussed in https://github.com/30x/project-management/issues/189 much more important to solve.

Agreed. We need to make a time to discuss that issue thoroughly.

I agree that 30x/project-management#189 is important, but we don't need a full resolution of that in order to get hostNames from Edge. All we need to do is read the values from Edge when the K8S namespace is created and define some approach to refresh. We could refresh on each deploy, for example, or on a time period, like Edge microgateway does.

Well, we do need to solve this.  Because either we build a system with features that allow you to work around this, like a manual endpoint or something, that needs to be designed/implemented or we build things right the first time.  But yes, I bet we could come up with the simpler, more manual approach now if you're fine with that.

I think the right model is the EdgeX/apid model, but we don't have that yet. I think it's OK to do some workarounds now, and converge on apid in the second half of 2017. If we try to do anything fancy, there is a danger we end up competing with apid.

That's what https://github.com/30x/project-management/issues/189 is intending to do, get us to agree upon an MVP or sorts so we can design things like the router, application configuration, etc.  So while that issue will not design/solve the greater issue, it will get us all on the same page with where we can go now.

Makes sense. Lets dedicate tomorrow's parking-lot discussion to this

Works for me.  I'll start thinking about what this looks like.

I am going to open a PR to start this. I will remove all environment commands one-be-one in different commits in case we change our mind on some of them for whatever reason...

I think removing all environment commands is not ideal.  Since we will be storing some data in the environment itself, like routing hosts, it would be useful to get/update an environment.  Thoughts?

@whitlockjc Currently we are leaving both the GET and PATCH functionality on an environment.

Great.

I'm going to close this PR. Going to just make the changes in the refactor PR.


GPIO Default Behaviour after Reboot?

I have a very trivial issue, I built a Box with GPIO buttons and it works like a charm. My child however is still very young and when we are playing something for her she randomly pushes buttons which can be quite annoying :-) So I disabled the gpio buttons on the web interface - which works fine.

however after a reboot the gpio settings return to being active, it does not remember the setting I chose on the web interface.
I also tried setting the default option in the gpio_settings.ini to false but it did not have an effect.

The only way to actually disable the buttons is to set every single button to enabled : false in gpio_settings.ini - which means that I cannot reactivate it from the GUI if I need the buttons to work for some time.

I am running Raspbian GNU/Linux 11 (bullseye) which I freshly installed in January 2022 from the newest installer.
Am I doing something terribly wrong here or is this a bug?
All the best
Karl

I'm sorry if I have done something wrong with submitting this issue, but is there a reason why I haven't gotten any reaction on it for the past 9 days? I saw that other issues were answered or at least labelled a couple of hours after they've been submitted. Did I break some code of conduct here?

Hey Karl!

I'm sorry if I have done something wrong with submitting this issue, but is there a reason why I haven't gotten any reaction on it for the past 9 days?

No one tries to avoid your post but usually people only answer when they really have something to say. And maybe that wasn't the case for your request.
The problem you describe is probably correct, and I don't have a solution for you now. This is mainly due to the fact that you are using 2.x but the current development focus is on 3.x.
I actually like the idea of switching of GPIO buttons on demand and of course, it should remain active after reboot as well. Why don't you tag this issue as future3 and a feature request so it can be considered.
Unless you are able to fix it yourself, there might not be much support at the moment for such a feature in 2.x.

Thank you very much for your reply. I understand the development focuses on 3.x and it would be great if it was considered there.
I wouldn't classify this as a feature though because it already exists in the current GUI with the implemented Toggle Button, just that the state is not saved upon reboot which it should be because it is a general setting of the box.

Though this is a bit old, here would be a local solution to save the state even after reboot:
Open the file htdocs/inc.header.php and go to line 331 (starting with gpiostatus).
Add  && /usr/bin/sudo /bin/systemctl enable phoniebox-gpio-control.service to the turnon definition.
Add  && /usr/bin/sudo /bin/systemctl disable phoniebox-gpio-control.service to the turnoff definition.
The result should look someting like this:
    'gpiostatus' => array(
        'turnon' => "/usr/bin/sudo /bin/systemctl start phoniebox-gpio-control.service && /usr/bin/sudo /bin/systemctl enable phoniebox-gpio-control.service",                    // start the gpio control service
        'turnoff' => "/usr/bin/sudo /bin/systemctl stop phoniebox-gpio-control.service && /usr/bin/sudo /bin/systemctl disable phoniebox-gpio-control.service"                     // stop the gpio control service
    ),

With the enable / disable commands the state of the service is preserved on reboot.

Another idea for the described case, would be to set the hold_mode of the Buttons to Postpone. This delays the execution with hold_time. So you have to hold the buttons a while and not just single push them.


Crash in REPL with unclosed string

REPL:
 1: say 'hi
fish: Job 1, './sink' terminated by signal SIGSEGV (Address boundary error)

fix:
https://github.com/voidqk/sink/commit/f8118c9d9c429f97e431737ec09921db2b4099fe


Witness thunk does not need to hop when the witness decl is accessible from anywhere

Fixes rdar://96906314.

@swift-ci please test


Fix enums

Should fix #220 and fix #368. changeThreadColor and reactToMessage are not aware of this change yet.
I'm having trouble with Python 2.7 encoding. Narrowed it down to:
tree = '🎄'
u"abc_{}".format(tree)

If we can figure the encoding errors, we might be able to solve #302?

I might have botched some syntax, but I'm having issues with the client.fetchThreadList() function.
After signing in if I run
threads = client.fetchThreadList()
I get the following:
Traceback (most recent call last):
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\site-packages\fbchat\graphql.py", line 32, in graphql_color_to_enum
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\enum.py", line 309, in __call__
    return cls.__new__(cls, value)
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\enum.py", line 545, in __new__
    return cls._missing_(value)
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\enum.py", line 558, in _missing_
    raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: '#f01d6a' is not a valid ThreadColor

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\site-packages\fbchat\client.py", line 903, in fetchThreadList
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\site-packages\fbchat\client.py", line 903, in <listcomp>
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\site-packages\fbchat\graphql.py", line 246, in graphql_to_thread
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\site-packages\fbchat\graphql.py", line 291, in graphql_to_group
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\site-packages\fbchat\graphql.py", line 43, in get_customization_info
  File "C:\Users\curti\AppData\Local\Programs\Python\Python37-32\lib\site-packages\fbchat\graphql.py", line 34, in graphql_color_to_enum
fbchat.models.FBchatException: Could not get ThreadColor from color: FFF01D6A

I used to use this code all the time and it worked fine. Might also be worth mentioning that it always fails on the first login attempt for me (but succeeds on the second). Also I am on version 1.6.5