text:
Failure to open external terminal (with "terminal: external" option)

OS: macOS-x64 11.4 (20F71), (Darwin Kernel Version 20.5.0, xnu-7195.121.3~9)
VSCode version:  1.58.2
Extension version: v1.6.5
Compiler: Apple clang version 12.0.5 (clang-1205.0.22.11)
Build target: x86_64-apple-darwin20.5.0
When I try to debug a C program with "terminal": "external" option, "Terminal.app" opens for a moment but closes almost right away. After that in the "Debug Console" I  receive this:
Failed to redirect stdio to a terminal. (Terminal agent did not respond within the allotted time.)
Debuggee output will appear here.

worked fine a month ago.
tried downgrading both vscode and vscode-lldb extension, but it does not help
there was a fairly large Xcode update, maybe it broke something?
C/C++ extension from microsoft opens external terminal just fine
this is what happens in the vscode-lldb extension log:

[2021-07-22T09:32:21.945Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":9,"command":"runInTerminal","request_seq":3,"success":false,"message":"/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/externalTerminal/node/TerminalHelper.scpt: execution error: Terminal got an error: Can’t set window id 1250 to true. (-10006)"}
[2021-07-22T09:32:25.794Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"category":"stderr","output":"Failed to redirect stdio to a terminal. (Terminal agent did not respond within the allotted time.)\nDebuggee output will appear here.\n"}}

If I switch to iTerm.app it still does not work (iTerm pops the message: "A session ended very soon after starting. Check that the command in profile "Default" is correct."), but the log is different:

[2021-07-22T10:28:25.972Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":9,"command":"runInTerminal","request_seq":3,"success":true,"body":{}}
[2021-07-22T10:28:29.721Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"category":"stderr","output":"Failed to redirect stdio to a terminal. (Terminal agent did not respond within the allotted time.)\nDebuggee output will appear here.\n"}}

Debug log
configuration: {
  type: 'lldb',
  request: 'launch',
  name: 'Launch',
  program: '${workspaceFolder}/main',
  args: [],
  terminal: 'external',
  cwd: '${workspaceFolder}',
  __configurationTarget: 5,
  expressions: 'native',
  relativePathBase: '/Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail'
}
liblldb: /Users/anpan/.vscode/extensions/vadimcn.vscode-lldb-1.6.5/lldb/lib/liblldb.dylib
environment: {}
params: { evaluateForHovers: true, commandCompletions: true }
Listening on port 49427
[2021-07-22T09:32:20.496Z DEBUG codelldb] New debug session
INFO(Python) 12:32:20 formatters: Initializing
INFO(Python) 12:32:20 formatters.rust: Initializing
[2021-07-22T09:32:20.779Z 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-07-22T09:32:20.780Z DEBUG codelldb::dap_codec] <-- {"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}}
[2021-07-22T09:32:20.787Z DEBUG codelldb::dap_codec] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Launch","program":"/Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail/main","args":[],"terminal":"external","cwd":"/Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail","__configurationTarget":5,"expressions":"native","relativePathBase":"/Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":false,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null,"terminalPromptClear":null,"evaluateForHovers":true,"commandCompletions":true},"__sessionId":"99c8dd7b-c53a-42d0-aac8-17e1450fa381"},"type":"request","seq":2}
[2021-07-22T09:32:20.787Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":1,"event":"capabilities","body":{"capabilities":{"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}}}
[2021-07-22T09:32:20.788Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":2,"event":"initialized"}
[2021-07-22T09:32:20.788Z DEBUG codelldb::dap_codec] <-- {"type":"request","seq":3,"command":"runInTerminal","arguments":{"args":["/Users/anpan/.vscode/extensions/vadimcn.vscode-lldb-1.6.5/adapter/codelldb","terminal-agent","--port=49429"],"cwd":"","kind":"external","title":"Launch"}}
[2021-07-22T09:32:20.791Z DEBUG codelldb::dap_codec] --> {"command":"setBreakpoints","arguments":{"source":{"name":"main.cpp","path":"/Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail/main.cpp"},"lines":[14],"breakpoints":[{"line":14}],"sourceModified":false},"type":"request","seq":3}
[2021-07-22T09:32:20.792Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":14,"message":"Locations: 1","verified":true}]}}
[2021-07-22T09:32:20.796Z DEBUG codelldb::dap_codec] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
[2021-07-22T09:32:20.796Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2021-07-22T09:32:20.798Z DEBUG codelldb::dap_codec] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":5}
[2021-07-22T09:32:20.798Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":5,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2021-07-22T09:32:20.800Z DEBUG codelldb::dap_codec] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":6}
[2021-07-22T09:32:20.800Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":6,"success":true,"command":"setExceptionBreakpoints"}
[2021-07-22T09:32:20.802Z DEBUG codelldb::dap_codec] --> {"command":"configurationDone","type":"request","seq":7}
[2021-07-22T09:32:20.803Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":7,"success":true,"command":"configurationDone"}
[2021-07-22T09:32:20.804Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":8}
[2021-07-22T09:32:20.805Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":8,"success":true,"command":"threads","body":{"threads":[]}}
[2021-07-22T09:32:21.945Z DEBUG codelldb::dap_codec] --> {"type":"response","seq":9,"command":"runInTerminal","request_seq":3,"success":false,"message":"/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/externalTerminal/node/TerminalHelper.scpt: execution error: Terminal got an error: Can’t set window id 1250 to true. (-10006)"}
[2021-07-22T09:32:25.794Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":4,"event":"output","body":{"category":"stderr","output":"Failed to redirect stdio to a terminal. (Terminal agent did not respond within the allotted time.)\nDebuggee output will appear here.\n"}}
[2021-07-22T09:32:25.795Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":5,"event":"output","body":{"output":"Launching: /Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail/main\n"}}
[2021-07-22T09:32:26.115Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":6,"event":"output","body":{"output":"Launched process 1733\n"}}
[2021-07-22T09:32:26.115Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":2,"success":true,"command":"launch"}
[2021-07-22T09:32:26.115Z DEBUG codelldb::debug_session] Debug event: 0x7fe442dba878 Event: broadcaster = 0x7fe443984e40 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-07-22T09:32:26.115Z DEBUG codelldb::debug_session] Debug event: 0x7fe442db3e48 Event: broadcaster = 0x7fe443984e40 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-07-22T09:32:26.115Z DEBUG codelldb::debug_session] Debug event: 0x7fe442e9f1f8 Event: broadcaster = 0x7fe443984e40 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-07-22T09:32:26.115Z DEBUG codelldb::debug_session] Debug event: 0x7fe442c7ebc8 Event: broadcaster = 0x7fe443984e40 (lldb.target), type = 0x00000002 (modules-loaded), data = {dyld, main}
[2021-07-22T09:32:26.115Z DEBUG codelldb::debug_session] Debug event: 0x7fe442c5a5a0 Event: broadcaster = 0x7fe4231c0050 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fe4231c0018 (pid = 1733), state = running}
[2021-07-22T09:32:26.115Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":7,"event":"module","body":{"module":{"addressRange":"100010000","id":"100010000","name":"dyld","path":"/usr/lib/dyld","symbolFilePath":"/usr/lib/dyld","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.115Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":8,"event":"module","body":{"module":{"addressRange":"100000000","id":"100000000","name":"main","path":"/Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail/main","symbolFilePath":"/Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail/main.dSYM/Contents/Resources/DWARF/main","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.115Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":9,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2021-07-22T09:32:26.168Z DEBUG codelldb::debug_session] Debug event: 0x7fe442eb0838 Event: broadcaster = 0x7fe443984e40 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-07-22T09:32:26.168Z DEBUG codelldb::debug_session] Debug event: 0x7fe442dd3eb8 Event: broadcaster = 0x7fe443984e40 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-07-22T09:32:26.168Z DEBUG codelldb::debug_session] Debug event: 0x7fe442dd3db8 Event: broadcaster = 0x7fe443984e40 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2021-07-22T09:32:26.168Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":10,"event":"breakpoint","body":{"breakpoint":{"id":2,"message":"Locations: 2","verified":true},"reason":"changed"}}
[2021-07-22T09:32:26.168Z DEBUG codelldb::debug_session] Debug event: 0x7fe442c7ef68 Event: broadcaster = 0x7fe443984e40 (lldb.target), type = 0x00000002 (modules-loaded), data = {libc++.1.dylib, libSystem.B.dylib, libc++abi.dylib, libcache.dylib, libcommonCrypto.dylib, libcompiler_rt.dylib, libcopyfile.dylib, libcorecrypto.dylib, libdispatch.dylib, libdyld.dylib, libkeymgr.dylib, liblaunch.dylib, libmacho.dylib, libquarantine.dylib, libremovefile.dylib, libsystem_asl.dylib, libsystem_blocks.dylib, libsystem_c.dylib, libsystem_collections.dylib, libsystem_configuration.dylib, libsystem_containermanager.dylib, libsystem_coreservices.dylib, libsystem_darwin.dylib, libsystem_dnssd.dylib, libsystem_featureflags.dylib, libsystem_info.dylib, libsystem_m.dylib, libsystem_malloc.dylib, libsystem_networkextension.dylib, libsystem_notify.dylib, libsystem_product_info_filter.dylib, libsystem_sandbox.dylib, libsystem_secinit.dylib, libsystem_kernel.dylib, libsystem_platform.dylib, libsystem_pthread.dylib, libsystem_symptoms.dylib, libsystem_trace.dylib, libunwind.dylib, libxpc.dylib, libobjc.A.dylib, liboah.dylib}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":11,"event":"module","body":{"module":{"addressRange":"7FFF205A1000","id":"7FFF205A1000","name":"libc++.1.dylib","path":"/usr/lib/libc++.1.dylib","symbolFilePath":"/usr/lib/libc++.1.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":12,"event":"module","body":{"module":{"addressRange":"7FFF2A814000","id":"7FFF2A814000","name":"libSystem.B.dylib","path":"/usr/lib/libSystem.B.dylib","symbolFilePath":"/usr/lib/libSystem.B.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":13,"event":"module","body":{"module":{"addressRange":"7FFF205F7000","id":"7FFF205F7000","name":"libc++abi.dylib","path":"/usr/lib/libc++abi.dylib","symbolFilePath":"/usr/lib/libc++abi.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":14,"event":"module","body":{"module":{"addressRange":"7FFF2A80E000","id":"7FFF2A80E000","name":"libcache.dylib","path":"/usr/lib/system/libcache.dylib","symbolFilePath":"/usr/lib/system/libcache.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":15,"event":"module","body":{"module":{"addressRange":"7FFF2A7CA000","id":"7FFF2A7CA000","name":"libcommonCrypto.dylib","path":"/usr/lib/system/libcommonCrypto.dylib","symbolFilePath":"/usr/lib/system/libcommonCrypto.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":16,"event":"module","body":{"module":{"addressRange":"7FFF2A7F4000","id":"7FFF2A7F4000","name":"libcompiler_rt.dylib","path":"/usr/lib/system/libcompiler_rt.dylib","symbolFilePath":"/usr/lib/system/libcompiler_rt.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":17,"event":"module","body":{"module":{"addressRange":"7FFF2A7E9000","id":"7FFF2A7E9000","name":"libcopyfile.dylib","path":"/usr/lib/system/libcopyfile.dylib","symbolFilePath":"/usr/lib/system/libcopyfile.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":18,"event":"module","body":{"module":{"addressRange":"7FFF203CB000","id":"7FFF203CB000","name":"libcorecrypto.dylib","path":"/usr/lib/system/libcorecrypto.dylib","symbolFilePath":"/usr/lib/system/libcorecrypto.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":19,"event":"module","body":{"module":{"addressRange":"7FFF20496000","id":"7FFF20496000","name":"libdispatch.dylib","path":"/usr/lib/system/libdispatch.dylib","symbolFilePath":"/usr/lib/system/libdispatch.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":20,"event":"module","body":{"module":{"addressRange":"7FFF20649000","id":"7FFF20649000","name":"libdyld.dylib","path":"/usr/lib/system/libdyld.dylib","symbolFilePath":"/usr/lib/system/libdyld.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":21,"event":"module","body":{"module":{"addressRange":"7FFF2A805000","id":"7FFF2A805000","name":"libkeymgr.dylib","path":"/usr/lib/system/libkeymgr.dylib","symbolFilePath":"/usr/lib/system/libkeymgr.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":22,"event":"module","body":{"module":{"addressRange":"7FFF2DC1B000","id":"7FFF2DC1B000","name":"liblaunch.dylib","path":"/usr/lib/system/liblaunch.dylib","symbolFilePath":"/usr/lib/system/liblaunch.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":23,"event":"module","body":{"module":{"addressRange":"7FFF2A7A8000","id":"7FFF2A7A8000","name":"libmacho.dylib","path":"/usr/lib/system/libmacho.dylib","symbolFilePath":"/usr/lib/system/libmacho.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":24,"event":"module","body":{"module":{"addressRange":"7FFF29FA0000","id":"7FFF29FA0000","name":"libquarantine.dylib","path":"/usr/lib/system/libquarantine.dylib","symbolFilePath":"/usr/lib/system/libquarantine.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":25,"event":"module","body":{"module":{"addressRange":"7FFF2A802000","id":"7FFF2A802000","name":"libremovefile.dylib","path":"/usr/lib/system/libremovefile.dylib","symbolFilePath":"/usr/lib/system/libremovefile.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":26,"event":"module","body":{"module":{"addressRange":"7FFF24EA5000","id":"7FFF24EA5000","name":"libsystem_asl.dylib","path":"/usr/lib/system/libsystem_asl.dylib","symbolFilePath":"/usr/lib/system/libsystem_asl.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":27,"event":"module","body":{"module":{"addressRange":"7FFF2037B000","id":"7FFF2037B000","name":"libsystem_blocks.dylib","path":"/usr/lib/system/libsystem_blocks.dylib","symbolFilePath":"/usr/lib/system/libsystem_blocks.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":28,"event":"module","body":{"module":{"addressRange":"7FFF20518000","id":"7FFF20518000","name":"libsystem_c.dylib","path":"/usr/lib/system/libsystem_c.dylib","symbolFilePath":"/usr/lib/system/libsystem_c.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":29,"event":"module","body":{"module":{"addressRange":"7FFF2A7FC000","id":"7FFF2A7FC000","name":"libsystem_collections.dylib","path":"/usr/lib/system/libsystem_collections.dylib","symbolFilePath":"/usr/lib/system/libsystem_collections.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":30,"event":"module","body":{"module":{"addressRange":"7FFF292A6000","id":"7FFF292A6000","name":"libsystem_configuration.dylib","path":"/usr/lib/system/libsystem_configuration.dylib","symbolFilePath":"/usr/lib/system/libsystem_configuration.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":31,"event":"module","body":{"module":{"addressRange":"7FFF2858E000","id":"7FFF2858E000","name":"libsystem_containermanager.dylib","path":"/usr/lib/system/libsystem_containermanager.dylib","symbolFilePath":"/usr/lib/system/libsystem_containermanager.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":32,"event":"module","body":{"module":{"addressRange":"7FFF2A54B000","id":"7FFF2A54B000","name":"libsystem_coreservices.dylib","path":"/usr/lib/system/libsystem_coreservices.dylib","symbolFilePath":"/usr/lib/system/libsystem_coreservices.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":33,"event":"module","body":{"module":{"addressRange":"7FFF22A84000","id":"7FFF22A84000","name":"libsystem_darwin.dylib","path":"/usr/lib/system/libsystem_darwin.dylib","symbolFilePath":"/usr/lib/system/libsystem_darwin.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":34,"event":"module","body":{"module":{"addressRange":"7FFF2A806000","id":"7FFF2A806000","name":"libsystem_dnssd.dylib","path":"/usr/lib/system/libsystem_dnssd.dylib","symbolFilePath":"/usr/lib/system/libsystem_dnssd.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":35,"event":"module","body":{"module":{"addressRange":"7FFF20515000","id":"7FFF20515000","name":"libsystem_featureflags.dylib","path":"/usr/lib/system/libsystem_featureflags.dylib","symbolFilePath":"/usr/lib/system/libsystem_featureflags.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":36,"event":"module","body":{"module":{"addressRange":"7FFF2068F000","id":"7FFF2068F000","name":"libsystem_info.dylib","path":"/usr/lib/system/libsystem_info.dylib","symbolFilePath":"/usr/lib/system/libsystem_info.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":37,"event":"module","body":{"module":{"addressRange":"7FFF2A75F000","id":"7FFF2A75F000","name":"libsystem_m.dylib","path":"/usr/lib/system/libsystem_m.dylib","symbolFilePath":"/usr/lib/system/libsystem_m.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":38,"event":"module","body":{"module":{"addressRange":"7FFF20469000","id":"7FFF20469000","name":"libsystem_malloc.dylib","path":"/usr/lib/system/libsystem_malloc.dylib","symbolFilePath":"/usr/lib/system/libsystem_malloc.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":39,"event":"module","body":{"module":{"addressRange":"7FFF24E38000","id":"7FFF24E38000","name":"libsystem_networkextension.dylib","path":"/usr/lib/system/libsystem_networkextension.dylib","symbolFilePath":"/usr/lib/system/libsystem_networkextension.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":40,"event":"module","body":{"module":{"addressRange":"7FFF22EA3000","id":"7FFF22EA3000","name":"libsystem_notify.dylib","path":"/usr/lib/system/libsystem_notify.dylib","symbolFilePath":"/usr/lib/system/libsystem_notify.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":41,"event":"module","body":{"module":{"addressRange":"7FFF300AA000","id":"7FFF300AA000","name":"libsystem_product_info_filter.dylib","path":"/usr/lib/system/libsystem_product_info_filter.dylib","symbolStatus":"Symbols not found"},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":42,"event":"module","body":{"module":{"addressRange":"7FFF292AA000","id":"7FFF292AA000","name":"libsystem_sandbox.dylib","path":"/usr/lib/system/libsystem_sandbox.dylib","symbolFilePath":"/usr/lib/system/libsystem_sandbox.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":43,"event":"module","body":{"module":{"addressRange":"7FFF2A7FF000","id":"7FFF2A7FF000","name":"libsystem_secinit.dylib","path":"/usr/lib/system/libsystem_secinit.dylib","symbolFilePath":"/usr/lib/system/libsystem_secinit.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":44,"event":"module","body":{"module":{"addressRange":"7FFF2060D000","id":"7FFF2060D000","name":"libsystem_kernel.dylib","path":"/usr/lib/system/libsystem_kernel.dylib","symbolFilePath":"/usr/lib/system/libsystem_kernel.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":45,"event":"module","body":{"module":{"addressRange":"7FFF20685000","id":"7FFF20685000","name":"libsystem_platform.dylib","path":"/usr/lib/system/libsystem_platform.dylib","symbolFilePath":"/usr/lib/system/libsystem_platform.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":46,"event":"module","body":{"module":{"addressRange":"7FFF2063D000","id":"7FFF2063D000","name":"libsystem_pthread.dylib","path":"/usr/lib/system/libsystem_pthread.dylib","symbolFilePath":"/usr/lib/system/libsystem_pthread.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.169Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":47,"event":"module","body":{"module":{"addressRange":"7FFF26580000","id":"7FFF26580000","name":"libsystem_symptoms.dylib","path":"/usr/lib/system/libsystem_symptoms.dylib","symbolFilePath":"/usr/lib/system/libsystem_symptoms.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.170Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":48,"event":"module","body":{"module":{"addressRange":"7FFF203B3000","id":"7FFF203B3000","name":"libsystem_trace.dylib","path":"/usr/lib/system/libsystem_trace.dylib","symbolFilePath":"/usr/lib/system/libsystem_trace.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.170Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":49,"event":"module","body":{"module":{"addressRange":"7FFF2A7D6000","id":"7FFF2A7D6000","name":"libunwind.dylib","path":"/usr/lib/system/libunwind.dylib","symbolFilePath":"/usr/lib/system/libunwind.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.170Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":50,"event":"module","body":{"module":{"addressRange":"7FFF2037D000","id":"7FFF2037D000","name":"libxpc.dylib","path":"/usr/lib/system/libxpc.dylib","symbolFilePath":"/usr/lib/system/libxpc.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.170Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":51,"event":"module","body":{"module":{"addressRange":"7FFF204DB000","id":"7FFF204DB000","name":"libobjc.A.dylib","path":"/usr/lib/libobjc.A.dylib","symbolFilePath":"/usr/lib/libobjc.A.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.170Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":52,"event":"module","body":{"module":{"addressRange":"7FFF2A7E1000","id":"7FFF2A7E1000","name":"liboah.dylib","path":"/usr/lib/liboah.dylib","symbolFilePath":"/usr/lib/liboah.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2021-07-22T09:32:26.172Z DEBUG codelldb::debug_session] Callback for breakpoint location 1.1: where = main`main + 22 at main.cpp:14:5, address = 0x0000000100003f66, resolved, hit count = 1
[2021-07-22T09:32:26.172Z DEBUG codelldb::debug_session] Debug event: 0x7fe442e0d830 Event: broadcaster = 0x7fe4231c0050 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fe4231c0018 (pid = 1733), state = stopped}
[2021-07-22T09:32:26.172Z DEBUG codelldb::dap_codec] <-- {"type":"event","seq":53,"event":"stopped","body":{"allThreadsStopped":true,"reason":"breakpoint","threadId":25330}}
[2021-07-22T09:32:26.182Z DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":10}
[2021-07-22T09:32:26.183Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":10,"success":true,"command":"threads","body":{"threads":[{"id":25330,"name":"1: tid=25330"}]}}
[2021-07-22T09:32:26.186Z DEBUG codelldb::dap_codec] --> {"command":"stackTrace","arguments":{"threadId":25330,"startFrame":0,"levels":1},"type":"request","seq":11}
[2021-07-22T09:32:26.186Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":11,"success":true,"command":"stackTrace","body":{"stackFrames":[{"column":5,"id":1001,"line":14,"name":"main","source":{"name":"main.cpp","path":"/Volumes/Crucial/3rd_party_projects/vscode/plugins/vadimcn_vscode_lldb/bug_reports/external_terminal_fail/main.cpp"}}],"totalFrames":3}}
[2021-07-22T09:32:26.613Z DEBUG codelldb::dap_codec] --> {"command":"stackTrace","arguments":{"threadId":25330,"startFrame":1,"levels":19},"type":"request","seq":12}
[2021-07-22T09:32:26.614Z DEBUG codelldb::disassembly] libdyld.dylib`start + 1
[2021-07-22T09:32:26.614Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":12,"success":true,"command":"stackTrace","body":{"stackFrames":[{"column":0,"id":1002,"line":4,"name":"start","presentationHint":"subtle","source":{"name":"@start","sourceReference":1000}},{"column":0,"id":1003,"line":4,"name":"start","presentationHint":"subtle","source":{"name":"@start","sourceReference":1000}}],"totalFrames":3}}

What happens if you use the "Open New External Terminal" command?

What happens if you use the "Open New External Terminal" command?

It opens new "Terminal.app" window

The immediate problem seems to be that VSCode fails to start a program that the debugger asks it to launch in a terminal.    There is not enough information here to determine why.

Created a new macos user profile and everything works fine. Looks like something broke on my end. Sorry for the hassle.

authors: panourgue vadimcn

repo: vadimcn/vscode-lldb


text:
Feature Request: Adding a section for bonus actions

Hey there!
I'm loving this plugin so far. Would it be possible to add a section for bonus actions in addition to regular and legendary actions? It would be useful for people who make homebrew creatures that utilize bonus actions a lot more for added versatility.
Thanks!

In the beta (2.0) you should already be able to do that:
In there you can copy the basic 5e Layout and edit it to your liking, and you can even add your own blocks and properties if so desired. As an example I made this here:

Now if you create a monster with the "bonusactions" property, it will read and behave like the standard action property.

It seems that there is either a limit to how many traits you can have or adding traits isn't working properly. I am using version 2.11.5 as of this post.

source: gharchive/issue

authors: Azraelv1 dschibster spacemessenger

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 Hacker News is down

In 6114d85, Hacker News (https://news.ycombinator.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Hacker News is back up in a3d48fa after 37 minutes.

repo: valofe/upptime


text:
chore(dropdowns): not working with minified version

Hey,
I tried ng2-bootstrap today and wanted to use dropdowns without any luck.
The following html
html

  A

B

C

does not work with ../node_modules/ng2-bootstrap/bundles/ng2-bootstrap.min.js but does work with ../node_modules/ng2-bootstrap/bundles/ng2-bootstrap.js.
I get the follwoing exception
EXCEPTION: No provider for a! (a -> a)BrowserDomAdapter.logError @ angular2.dev.js:22690BrowserDomAdapter.logGroup @ angular2.dev.js:22701ExceptionHandler.call @ angular2.dev.js:1163(anonymous function) @ angular2.dev.js:12416NgZone._notifyOnError @ angular2.dev.js:13324collection_1.StringMapWrapper.merge.onError @ angular2.dev.js:13228run @ angular2-polyfills.js:141(anonymous function) @ angular2.dev.js:13247zoneBoundFn @ angular2-polyfills.js:111lib$es6$promise$$internal$$tryCatch @ angular2-polyfills.js:1511lib$es6$promise$$internal$$invokeCallback @ angular2-polyfills.js:1523lib$es6$promise$$internal$$publish @ angular2-polyfills.js:1494(anonymous function) @ angular2-polyfills.js:243microtask @ angular2.dev.js:13279run @ angular2-polyfills.js:138(anonymous function) @ angular2.dev.js:13247zoneBoundFn @ angular2-polyfills.js:111lib$es6$promise$asap$$flush @ angular2-polyfills.js:1305
angular2.dev.js:22690 STACKTRACE:BrowserDomAdapter.logError @ angular2.dev.js:22690ExceptionHandler.call @ angular2.dev.js:1165(anonymous function) @ angular2.dev.js:12416NgZone._notifyOnError @ angular2.dev.js:13324collection_1.StringMapWrapper.merge.onError @ angular2.dev.js:13228run @ angular2-polyfills.js:141(anonymous function) @ angular2.dev.js:13247zoneBoundFn @ angular2-polyfills.js:111lib$es6$promise$$internal$$tryCatch @ angular2-polyfills.js:1511lib$es6$promise$$internal$$invokeCallback @ angular2-polyfills.js:1523lib$es6$promise$$internal$$publish @ angular2-polyfills.js:1494(anonymous function) @ angular2-polyfills.js:243microtask @ angular2.dev.js:13279run @ angular2-polyfills.js:138(anonymous function) @ angular2.dev.js:13247zoneBoundFn @ angular2-polyfills.js:111lib$es6$promise$asap$$flush @ angular2-polyfills.js:1305
angular2.dev.js:22690 Error: DI Exception
    at NoProviderError.BaseException [as constructor] (http://localhost:8080/node_modules/angular2/bundles/angular2.dev.js:7070:21)
    at NoProviderError.AbstractProviderError [as constructor] (http://localhost:8080/node_modules/angular2/bundles/angular2.dev.js:1627:14)

Moreover I am using system.js.
Any suggestions?

sorry for it, this is known beta.1 issue for minified  version
can you create a plunker for it? may be I can fix it somehow

it seems that meta notations lost, I should add @Inject() may be will help

Hi,
Sorry, was on vacation.
Will recheck this issue this weekend and hopefully submit a plunker, too.

if you use minified version turn of mangle
ng2 beta doesn't play nice with minification

If I use the non-min version, I get
No provider for Dropdown! (DropdownToggle -> Dropdown)
instead...

@jayhahn Did you add the dropdown on that parrent taag of the one with dropdownToggle?

  <button type="button" class="btn" dropdownToggle>Simple Dropdown</button>

Action

Separated link

authors: Dinistro jayhahn jtandler valorkin


text:
Custom Cell Renderer and Cell Editor

Are there any samples or documentation in using custom renderers and editors?  I'm thinking it would be something like creating a component and assigning that component in the column definition as either the renderer or the editor.
Thanks, team!

Here's a code snippets for using a custom cell renderer:
export class TableComponent {
  protected columnData: any[];
  protected handstontableOptions: ht.GridOptions;

  ...

  constructor() {
    const columns: ht.ColumnsOptions[] = this.columnData.map((col, index) => ({
      data: col.data,
      renderer: (instance: any, td: Element, row: number, col: number, columnKey: string, data: any, cellProperties: any) => {
        if (data.html) {
          $(td).html(data.html);
        } else {
          Handsontable.renderers.TextRenderer.apply(instance, arguments);
        }
      }
    }));
    this.handstontableOptions.columns = columns;
  }
}

with
<hot-table [options]="handstontableOptions">
</hot-table>

Does that help?

Thanks, Rene.
Yup, that's for custom cell renderer. But actually I'm more interested in custom cell editors.  I believe HOT supports this.
https://docs.handsontable.com/0.15.0-beta1/tutorial-cell-editor.html

On 3 Apr 2017, at 4:29 PM, Rene Hamburger notifications@github.com wrote:
Here's a code snippets for using a custom cell renderer:
export class TableComponent {
protected columnData: any[];
protected handstontableOptions: ht.GridOptions;
...
constructor() {
const columns: ht.ColumnsOptions[] = this.columnData.map((col, index) => ({
data: col.data,
renderer: (instance: any, td: Element, row: number, col: number, columnKey: string, data: any, cellProperties: any) => {
if (data.html) {
$(td).html(data.html);
} else {
Handsontable.renderers.TextRenderer.apply(instance, arguments);
}
}
}));
this.handstontableOptions.columns = columns;
}
}
with
<hot-table [options]="handstontableOptions">

Does that help?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I haven't tried that yet, but it should work analogously. Feel free to share some example code if you get it to work.

@raskolnikov1041 Were you able to implement a custom editor? I'd love to see an example of this.

Has anyone gotten this to work?  This is a pretty big show stopper for this, otherwise, this component works fairly well (minus weird rendering of cells to headers)

I was able to add a custom editor relying heavily on this documentation. I needed a select box that takes key/value pairs instead of an array of strings. Here is the editor (I'm sure it could be cleaned up): https://gist.github.com/ben-dalton/6fd4cad0917cad150324afc8060562a3
Then I could import the editor and point to it in the columns array, e.g.
import { SelectValueEditor } from '../shared/utils/handsontable/editors';
...
const columns = [
  {
    data: 'campusId',
    strict: true,
    filter: false,
    renderer: SelectValueRenderer,
    editor: SelectValueEditor,
    selectOptions: () => this.campusList,
    required: true
  }
]

@ben-dalton I actually copied your code but it still does not appear to work.  I've set breakpoints in the prepare function with no luck there either.  Any suggestions?

@Zenoware my code is pretty tightly coupled to the structure of my containing component so I think it will only be helpful as a reference. My implementation depends on a campusList function on the class that pulls back some data. It might be better to try and implement a simpler editor or renderer, just to get your bearings and see some results to start with. The password editor in the docs was the most helpful for me.

@ben-dalton I did figure out the problem.  It was that I was setting the columns in an observable.  Not sure why that was a problem but it caused renderer and editor to not work at all.  Moving it out and just updating the optionsList works inside the observable.  Only issue now is that the rerender is not being fired after the change event.  It does change the value of the cell though

authors: Zenoware ben-dalton raskolnikov1041 renehamburger

license: mit

license_source: bigquery


text:
Improve

Is your feature request related to a problem? Please describe.
Presently, the aea framework is unable to handle yaml format in terms of config overrides.
This is as we only presently parse json like strings.
However this is incompatible with the yaml formatting we use throughout the definitions of our components.
Please revert https://github.com/valory-xyz/consensus-algorithms/pull/913
upon completion of this ticket as this will then remove the need for this.
Revert the please reference to revert #913 when this has been fixed on open-aea
Describe the solution you'd like
The ability to parse yaml like overrides as yaml so that we are able to specify lists and dictionary in yaml from
aea config set skill example.connections.http_echo ['test', 'test']

Additional context
Add any other context or screenshots about the feature request here.

Addressed here https://github.com/valory-xyz/open-aea/pull/284

repo: valory-xyz/open-aea


text:
Wifi turned off when preload ride option enabled

With the preload ride option enabled it turns off wfi but does not turn it back on.
Create an  option to re-enable it (if previously enabled) after the preload has happened.

Thanks, I noticed that too.
Can you tell me which Ki2 version do you have installed? I tried to fix that in version 0.6. Let me know.

I've just upgraded to 0.6 (was on 0.5) and the latest version has solved the Wi-Fi issue

authors: JayUK valterc


text:
[feature] support Unsupported() types

schema.prisma
generator kysely {
  provider           = "prisma-kysely"
  output             = "../../build/prisma/primary"
  fileName           = "types.ts"
  unsupportedFilename = "unsupported-types.ts"
}

model Payment {
  id     BigInt                              @id @default(autoincrement())
  amount Unsupported("money_with_currency")?
}

types.ts (generated by prisma-kysely)
import UnsupportedTypes from '~/unsupported-types';

export type Payment = {
    id: Generated<bigint>;
   amount: UnsupportedTypes['money_with_currency'] | null;
}

unsupported-types.ts (defined by us manually)
export type MoneyWithCurrency = {
  amount: bigint;
  currency: CurrencyCode;
}

export const Unsupported = {
  'money_with_currency': MoneyWithCurrency
} as const;

Would this be possible? We're currently stuck with this and realised that Prisma wouldn't support custom type just for Postgres use case. Would be great if we can make this happen. Thanks.

Prisma side feature request to put Unsupported into DMMF so it is available for generators: https://github.com/prisma/prisma/issues/20756

thanks @janpio for linking that, this is my issue I opened last week. I'm looking for an alternative in the meantime to deal with this as it could be sometime before this is added to the DMMF

(Your username did seem familiar 😆)

authors: cayter dylel janpio

repo: valtyr/prisma-kysely


text:
RiskEstimation study with fixed evaluation time points

Question
How to run a RiskEstimationStudy with fixed evaluation time points?
Further Information
I'm currently trying to use Autoprognosis to develop a risk estimation model on a clinical study dataset. The study has evaluation time points at 3, 6 and 12 months. The presence of disease is determined at each of these time points for each subject. Patient characteristics are gathered at baseline.
I have looked at the survival analysis example and see that in the example dataset, the duration/time-to-event column seems to contain the time-to-event (or general survival), Y contains the presence of an event and time_horizons seems to be evaluations? How do you recommend coding the duration column in this case? The easiest way would be to just use the presence of disease at the different timepoints (ie if someone has the disease at the 3 month evaluation assign 3 months as the time-to-event value). however, this would that there are only 3 different values in the time-to-event column: 3, 6 and 12.
Maybe you have encountered this problem before and can give a recommendation on how to handle such cases.

I think the way you explained it should be the right way to do it.
If you can frame your problem as a a time-series problem, you could also try: our time-series library: https://github.com/vanderschaarlab/temporai

authors: DrShushen VHolstein

repo: vanderschaarlab/autoprognosis


text:
libc upgrade fix

Ensure the dockerfile upgrades libc/bin to the correct version with security patch

Dockerfile included instructions to install libc and then update. However the update version was the same as the original installation version. Updated the 2nd instruction for update to update to a newer version.


text:
export type { Primitive, Props, PropValue, State, StateView } from "./shared"

mini-van.d.ts
van-plate.d.ts

Removed duplicate types.

I'm adding some isomorphic helpers. Consistent types are useful for adding code that is meant to work both on the browser & server. The second commit adds more types into shared.

shared.ts can instead import from mini-van.d.ts & van-plate.d.ts, allowing the two files to have no dependencies.

Hi,
Thanks for your commit!
Overall this PR seems to do many things and make the type system of Mini-Van much more complicated. But I'm struggling to understand the main motivation of the PR. Preferably, if there are multiple objectives to achieve, we can break down into smaller PRs, so that the change for each objective becomes more clear.
Here are my general opinion regarding the PR:

For now, a good feature of Mini-Van is: you can download a single .js file and a single .d.ts file to start working with, without the need of NPM integration. I would like to keep that feature, unless there is convincing benefit if we give up on it. I tried to find some TypeScript bundling solutions but couldn't get a workable one. In the end, I decided to just have some duplicate code among mini-van.d.ts, van-plate.d.ts and shared.ts. For now the amount of duplication is manageable. I think we can keep the duplication until the complexity hits an inflection point.
I noticed that one improvement of this PR is to enable more type-checkings in shared.ts for tag functions. I can see the benefit. If this is something you want to improve, I would prefer to have a minimal PR just to address that. This way it will be easier to weigh in the pros and cons of the PR. Ideally, I'm hoping we can make the improvement without breaking the feature in 1).

I reverted mini-van.d.ts & van-plate.d.ts, added common types into shared.ts, & rebased.
Here is a couple of extensions that I'm working on:
const protoOf = Object.getPrototypeOf
const objProto = protoOf({})
export type PropsWithUndefined = Record<string, PropValue|undefined|StateView<PropValue>|(()=>PropValue)>
export type TagFuncWithUndefined = (first?:PropsWithUndefined|ChildDom, ...rest:readonly ChildDom[])=>Element
export function Raw(van:VanObj, html:string):ChildDom {
	if (globalThis['window']) {
		const frag = document.createDocumentFragment()
		const temp = document.createElement('div')
		temp.innerHTML = html
		while (temp.firstChild) {
			frag.appendChild(temp.firstChild)
		}
		return frag as any as ChildDom
	}
	else {
		const { __proto__ } = van.tags.div()
		return {
			__proto__,
			renderToBuf(buf:any[]) {
				buf.push(html)
			},
		} as any as ChildDom
	}
}
export function vanProxy<V extends VanObj>(van:V):Omit<V, 'tags'>&{
	tags:Readonly<Record<string, TagFuncWithUndefined>>
} {
	let tags = new Proxy<typeof van.tags>(van.tags, {
		get(target, p, receiver) {
			const f = Reflect.get(target, p, receiver)
			if (!f) return f
			const fn:typeof van.tags[string] = (...args)=>{
				let [props, ...children] = protoOf(args[0] ?? 0) === objProto ? args : [{}, ...args]
				return f(cleanProps(props), ...children)
			}
			return fn
		}
	})
	return new Proxy<typeof van>(van, {
		get(target, p, receiver) {
			if (p === 'tags') return tags
			return Reflect.get(target, p, receiver)
		}
	})
}
function cleanProps(props:Props) {
	for (const key of Object.keys(props)) {
		if (props[key] === undefined) delete props[key]
	}
	return props
}

@Tao-VanJS I took a different approach with shared.ts, adding a VanShape type. VanShaped is used in the generics for types where mini-van.d.ts & van-plate.d.ts differ. Some types were added to mini-van.d.ts & van-plate.d.ts as well.
This gist contains the example that I used.

I left in VanObj but I think VanShape could replace VanObj.

Hi @btakita,
Thank you so much for your contribution! I did take a in-depth review of this PR. It's a difficult decision but I haven't come to a point for merging this PR in.
First, about my view on TypeScript and .d.ts files in VanJS-series projects: I am considering TypeScript as add-on type annotations. The core library should work on its own without the .d.ts annotations, and the purpose of d.ts annotations is to try our best to assist our users for writing correct client code while keeping the type annotations simple and easy to understand. While advanced TypeScript features allow us to do very sophisticated type gymnastics but doing too much will make the type system hard to digest and navigate.
For this specific PR, I'm afraid that we're pushing the complexity of relevant TypeScript files to a point that is no longer easy to understand. This can be judged by the size increases of the files, especially in shared.ts. It's really hard for me to be sure that the benefit we can get from this PR worths the complexity.
Moreover, I don't think this specific PR can significantly enhance the type-checking capabilities of Mini-Van, especially with the introduction of any in different places. Here are a few issues that I noticed:

In Line 20 of van-plate.d.ts:

export type BindingFunc = (dom: Element) => ValidChildDomValue

I don't think this change is right. Indeed, the signature of BindingFunc is quite complex, which is why I'm using any for van-plate to avoid making the type too complex in van-plate. In VanJS, the signature is:
export type BindingFunc = ((dom?: Node) => ValidChildDomValue) | ((dom?: Element) => Element)

In mini-van the signature is:
export type BindingFunc<ElementType extends HasFirstChild, TextNodeType> =
  | ((dom?: ElementType | TextNodeType) => ValidChildDomValue<ElementType, TextNodeType>)
  | ((dom?: ElementType) => ElementType)

In Line 49 of van-plate.d.ts:

readonly add: AddFunc<any, any>

This is reducing the type checking capability of van-plate, as literally any function is compatible to AddFunc<any, any>.
3. In shared.ts, the definition of VanShape, I noticed that the mini-van portion of the definition:
{
  readonly _BindingFunc?: MiniBindingFunc<any, any>
  readonly _ChildDom?: MiniChildDom<any, any>
  readonly _ValidChildDomValue?: MiniValidChildDomValue<any, any>
  readonly add: MiniAddFunc<any, any>
  readonly html: MiniHtmlFunc<any, any>
  readonly tags: MiniTags<any, any>
  readonly tagsNS: MiniTagsNSFunc<any, any>
}

Because of the using of any, we're literally making any function compatible with these defined types, thus the VanShape has hardly any type-checking capability.
It's not 100% clear to me what you're trying to achieve in this PR. i.e.: what exactly is missing in the current type annotations of Mini-Van for the things that you plan to work on. If you're trying to create some utility functions that can work for both mini-van and van-plate, my suggestion is to start with something simple with just some basic type-checking capabilities, and leverage weak-typing (such as any) when type gymnastics are pushed for too far. Then we can start to gradually introduce more type-checking, step by step, with each step we make sure to keep the complexity under control. Another approach is for utility functions to deal with more specific concrete types. The types in van-plate are pretty simple and specific. The types in mini-van are quite generic but you can start working with the concrete specializations that you care about.
Let me know if it makes sense to you.

Hi @Tao-VanJS, thanks for taking a look. I'm attempting to create isomorphic functions to extend Van. I ran into type issues & usability issues using the type system on main. The example I posted in the gist has to work for both the van-plate & mini-van.
I'm having trouble with the types in the main branch, particularly around the types that have the <ElementType extends HasFirstChild, TextNodeType> generics in mini-van. I hope to have a shared set of types that can provide a better experience to verify both type systems work.
Domain Consistency
First I had to wrap my head around the terminology. van-plate for SSR & mini-van for CSR. When making isomorphic components, I want to use the shared types as much as possible, as it indeed is shared between SSR & CSR. Using SSR types for isomorphic components limits the type system capabilities when the component is rendered in CSR. I don't think I could even figure out how to do the example in the gist with the type system in main. Isomorphic components would have to reconcile & support both the <ElementType extends HasFirstChild, TextNodeType> generic for mini-van & the lack of generics for van-plate.
Making van-plate types do double duty as a generic type for isomorphic components adds complexity & influences the decision of how to design the types in van-plate. The types in van-plate are no longer meant to accurately model what happens in SSR, but to also be a generic type for isomorphic components. This forces types to be overly-wide for SSR.
You pointed out:

export type BindingFunc = (dom: Element) => ValidChildDomValue

I don't think this change is right. Indeed, the signature of BindingFunc is quite complex, which is why I'm using any for van-plate to avoid making the type too complex in van-plate. In VanJS, the signature is:
export type BindingFunc = ((dom?: Node) => ValidChildDomValue) | ((dom?: Element) => Element)

I updated the type to:
export type BindingFunc = (dom?: Element) => ValidChildDomValue

From what I understand, dom?: Element is the actual type expected in van-plate for BindingFunc. If there are other types expected, why not explicitly model what is happening during execution? If van-plate's BindingFunc double as the common isomorphic type, then we have to use dom:any.

In Line 49 of van-plate.d.ts:

I missed removing the generic. AddFunc is not a generic type in van-plate.
Consistency with Generics
VanShape is the current try to keep mini-van & van-plate simple with no dependencies, while providing a consistent type api to target isomorphic code.

Because of the using of any, we're literally making any function compatible with these defined types, thus the VanShape has hardly any type-checking capability.

Good catch! I strengthened VanShape:
type VanCommon = {
  readonly state: <T>(initVal: T) => State<T>
  readonly val: <T>(s: T|StateView<T>) => T
  readonly oldVal: <T>(s: T|StateView<T>) => T
  readonly derive: <T>(f: () => T) => State<T>
  readonly _: UnderscoreFunc
}
export type VanShape = VanCommon&(MiniVan|VanPlate)

and removed the defaults for generics using VanShape (<V extends VanShape> instead of <V extends VanShape = VanPlate>):
Now VanShape has stronger typing, there were a couple of errors in the example code that I had to fix.
I updated the example gist.
Raw component
I had to use a ReturnType ternary to resolve correctly.
type Return<V extends VanShape> = V extends MiniVan ? DocumentFragment : VanPlateElement

There are tests at the bottom of the file.
vanCleanProps
With stronger type checking, I got a type error when trying:
				let [
					props,
					...children
				] = (protoOf(args[0] ?? 0) === objProto ? args : [{}, ...args]) as [Props, ...ChildDom<V>[]]
				return tag(cleanProps(props), ...children)

It seems like TagFunc<V> does not narrow the type when checking for valid valid arguments. It needs to work for both MiniVan & the VanPlate types even if the ternary type check is the same between TagFunc<V> & ChildDom<V>. To fix it, I had to use ChildDom<VanPlate>. I'm not satisfied with this solution, but at least it's a stronger type check than what was originally in the shared VanObj, which was:
readonly tags: Record<string, Function>

Note the type return by vanCleanProps
export type PropsWithUndefined = Record<string, Props[string]|undefined>
export type TagFuncWithUndefined<V extends VanShape> =
	(first?:Props|ChildDom<V>|PropsWithUndefined, ...rest:readonly ChildDom<V>[])=>ReturnType<TagFunc<V>>
export type VanWithUndefined<V extends VanShape> = V&{
	tags:Record<string, TagFuncWithUndefined<V>>
	tagsNS:(namespaceURI:string)=>Readonly<Record<string, TagFuncWithUndefined<V>>>
}

I'm not sure how do accomplish the same thing without chaos with the main branch...

I realize a couple of things now. van is meant to run in the browser. mini-van is meant to run on the server to render to a DOM library (e.g. JSDOM) or in the browser with limited prop & reactive support. van-plate is meant to render to a html string. Is this correct?
I also realize that BindingFunc is not run in van-plate, so (dom: any) makes sense.
With that being said, isomorphic types that delegate based on the Van type would need to depend on van-core in addition to this library. That makes me think that it would make more sense to not include the delegation in this library. The 3 type sets can support the delegation use case by keeping the same set of names.

I realize a couple of things now. van is meant to run in the browser. mini-van is meant to run on the server to render to a DOM library (e.g. JSDOM) or in the browser with limited prop & reactive support. van-plate is meant to render to a html string. Is this correct?

Yes. Your understanding is correct.
I will try to explain my thought process regarding type systems in VanJS-series projects.
Generally speaking, for type systems of projects with the level of generic and flexibility like VanJS, designing a good type system is a challenging task and needs juggling among the 3 main type of problems:

Types are too loose. Cost of this type of problems:

We're not able to catch some bugs before run time.
We lose some perks from the IDE, especially, a better suggestion for auto-complete.

Types are too tight. Cost of this type of problems:

Correct client code result in type errors.

Types are too complex. Cost of this type of problems:

Type system is hard to understand. It's hard to figure out whether there are bugs in the type system by reading the code.
Type system is hard to deal with. It's hard to maintain and keep evolving the type system.
When users get type errors, the error messages are usually hard to understand, sometimes misleading. This is quite evident in C++ template errors.

There are times where it's hard to avoid all 3 types of problems altogether. Thus in case we need to do some tradeoffs, in my opinion, the stack ranking of importance is: 3 > 2 > 1.
This is why in shared.ts, we chose to have problem 1, rather than problem 3 or 2.
Another remark is that, when we're developing VanJS, mini-van, van-plate and VanX, because of the generic and flexibility we have in the implementations, it will make the type system more complex than desired if we had them implemented in TypeScript. As a result, we chose to have the JavaScript-based implementation first, and then try to annotate the public interface of these projects in d.ts files with a type system that is reasonably simple and tries to catch client-side bugs as much as possible. Separating the implementation and type annotations helps us decouple the entangled problems, and as a result greatly simplify things. Indeed, we recognize the limitation of the type checking thus that's why we have van.debug.js which enables more sanity checks than what are possible in TypeScript.
For your specific work stream, I would recommend a similar approach. If I understand correctly, what you want to have is an extension of van object with your preferred behavior. You want the extension to be generic enough so that it can cover VanJS, mini-van and van-plate. I think by trying to implement your extension completely in JavaScript first and then add a d.ts file to annotate the public interface can simplify lots of things.
I think you can simply have some public interface like:
export function extend<T extends ClientVan | MiniVan<Element, Text> | VanPlate>(van: T): T

For Raw function, you can have something like:
type RawReturn<T extends ClientVan | MiniVan<Element, Text> | VanPlate> =
  T extends ClientVan ? DocumentFragment :
  T extends MiniVan<Element, Text> ? MiniVanDocumentFragment :
  PlateElement

export function Raw<T extends ClientVan | MiniVan<Element, Text> | VanPlate>(van: T, html: string): RawReturn<T>

Does it make sense to you?

That makes sense. I agree that .js + .d.ts simplifies things for library development while .ts has been good for app development. I like how having .js decoupled from the types allows "hidden" behavior while the types more-or-less represent the API of the library.
I appreciate you bringing up the 3 tradeoffs re: types. I think different development contexts weigh the tradeoffs differently from each other.
I have a large number of codebases to maintain, both open source & proprietary. Not many developers (if any) use these libraries. I experiment with some techniques & have had significant churn with the code with new libraries, techniques. I'm more concerned about managing isomorphic development across many codebases. I will need to be able to come back to a codebase after time passes (sometimes over a year later) & understand the code. My code bases have also gone through considerable development churn as the state of the art changes, better libraries are introduced, etc.
That being said, I favor flat architectures, consistent type systems, injecting context, reactive programming, modular global state management, custom code for simple behavior, simple dependencies backed by a skillful community for more complex behavior.
I'm not as concerned about some complexity in the types, assuming there is a coherent set of patterns to the types. I'm more concerned about balancing the 3 points depending on the development context. I don't think I can codify a rigid order of preference of the 3 tradeoffs you mentioned at this point.
That being said, I moved the types into https://github.com/btakita/van-type-delegate. I converted my website over to use VanJS. I left in the SolidJS components as well for comparison.
I have to say that I'm very satisfied with moving the components over to VanJS. I think it integrates very well with Astro. For example, within a *.astro or *.mdx component, I can use <Fragment> to render the VanJS component. It's nice to use plain old functions. A VanJS component in Astro does not support <slot>, but it's not a big loss. Using Astro <slot> in a framework (e.g. SolidJS) component has complicated progressive async rendering behavior.
I have a V_footnote & V_footnote_list components where the footnote html is stored & rendered in the V_footnote_list at the bottom of the page. The VanJS implementation is cleaner & more coherent than the Astro + SolidJS (or any other supported framework) implementation...Due to the simplicity of calling synchronous functions instead of working with progressive async rendering.
I'm tweaking van-type-delegate to make it as smooth as possible while providing adequate isomorphic type checking.

Thanks @btakita for sharing your context and perspective! And also thanks for your kind remark on VanJS. I'm really glad it provides you the developer experience you enjoy.
Regarding the support of asynchronous rendering, we have Await utility component in VanJS, thanks to @Hunter-Gu's contribution.

source: gharchive/pull-request

authors: Tao-VanJS btakita

repo: vanjs-org/mini-van


text:
Webpack 4 issue importing .mjs files

Description of the bug
When importing postprocessing in webpack 4, I see many errors such as the following:
ERROR in ../node_modules/postprocessing/build/postprocessing.mjs 6246:37-56
Can't import the named export 'WebGLRenderTarget' from non EcmaScript module (only default export is available)

ERROR in ../node_modules/postprocessing/build/postprocessing.mjs 4828:22-34
Can't import the named export 'sRGBEncoding' from non EcmaScript module (only default export is available)

I can work around this (partially) by introducing the following module rule to webpack.config.js:
      {
        test: /\.mjs$/,
        include: /node_modules/,
        type: "javascript/auto",
      },

However, doing so causes webpack (typescript?) to duplicate the three library, as it appears to be unable to resolve the three peer dependency as the same library within both my app's code and postprocessing's code. I see a warning in the JS console:
WARNING: Multiple instances of Three.js being imported.

And indeed, when building my app, it has two instances of three.js, both at version 0.129.0.
To Reproduce
If it would be helpful, I can write a small app to reproduce this, but I don't have time right now.
Expected behavior
I should be able to import { ... } from "postprocessing" in typescript.
Library versions used

Three: 0.129.0
Post Processing: 6.24.0

Desktop

OS: Linux
Browser: Chromium, Firefox, etc.
Graphics hardware: Intel

Thanks for the report.
The package type of three was changed to module in r137 and I changed the extension of the exported postprocessing bundle to .mjs which has the same effect. Since this broke compatibility with older version of three, it should be considered a bug. I'll look into possible solutions in a bit.

Fixed in postprocessing@6.24.1.

authors: canadaduane vanruesc

repo: vanruesc/postprocessing

license: Zlib


text:
🧑💻: Enhance the styling of the navbar and fixing the alignment

Title
Enhance the styling of the navbar and fixing the alignment
Enhancement Aim
Enhance the styling of the navbar and fixing the alignment
Changes
Enhance the styling of the navbar and fixing the alignment
Screenshots 📷
No response
Guidelines

[X] I have read the guidelines
[X] I have the link to my latest merged PR

Full Name
Shriya Dindi
Participant Role
gssoc-extd

Title
Enhance the styling of the navbar and fixing the alignment
Enhancement Aim
Enhance the styling of the navbar and fixing the alignment
Changes
Enhance the styling of the navbar and fixing the alignment
Screenshots 📷
No response
Guidelines

[x]  I have read the guidelines
[x]  I have the link to my latest merged PR

Full Name
Shriya Dindi
Participant Role
gssoc-extd

Duplicate issue


text:
该 vant-nuxt是基于vant的哪个版本？

rt

4.0

authors: leikeren tolking

repo: vant-ui/vant-nuxt


text:
Support hpc7a

It would be great to add https://aws.amazon.com/ec2/instance-types/hpc7a/

hpc7a.12xlarge
hpc7a.24xlarge
hpc7a.48xlarge
hpc7a.96xlarge

Thanks! ☺

These have been added.

authors: brookemckim hongbo-miao


text:
Queues does not support Swift 5.2

Because Queues no longer supports 5.2 due to a few missing self. in QueueWorker.swift the test for Vapor with Queues as a provider now fail, see for example: https://github.com/vapor/vapor/pull/2511/checks?check_run_id=1272354381
I suggest we either drop down to 5.2 in the test or test for both 5.2 and 5.3. On a related note, the README also says Queues supports 5.2.

@siemensikkema good catch - we should probably just add back in those missing self. items. I will do that sometime this week!

Closed via #91

authors: 0xTim jdmcd siemensikkema

repo: vapor/queues


text:
with message 'No origin header'

hello
my name is hisa
I use version 2.0.8.
i run "php server.php" .
When the ip address is (http://127.0.0.1:8000, ws: // 127.0.0.1: 8000) it works normally,
but my local ip 192.168.1.6 (http: //192.168. 1.6: 8000, ws: // 192.168.1.6: 8000)
If specified ('No origin header') an error will be displayed.
By the way, 192.168.1.6 is the ip address allocated from the home wifi router.
[message]
info: Wrench\ConnectionManager: Wrench\Connection: 192.168.1.6:61801 (680871ddbcc61956670124d9d8dcea6e8857e5ab0379ff823ca8453fe3babc9a8ae17cea788024f106db26171bd2fe49d90e46459fa0d285b9356e8c8a16583c): Connected
warning: Wrench\ConnectionManager: Error on client socket: exception 'Wrench\Exception\BadRequestException' with message 'No origin header' in /Users/hisashi/git/Wrench/vendor/wrench/wrench/lib/Wrench/Protocol/Protocol.php:471
Stack trace:
#0 /Users/hisashi/git/Wrench/vendor/wrench/wrench/lib/Wrench/Connection.php(223): Wrench\Protocol\Protocol->validateRequestHandshake('GET /chat_a/exa...')
#1 /Users/hisashi/git/Wrench/vendor/wrench/wrench/lib/Wrench/Connection.php(206): Wrench\Connection->handshake('GET /chat_a/exa...')
#2 /Users/hisashi/git/Wrench/vendor/wrench/wrench/lib/Wrench/Connection.php(402): Wrench\Connection->onData('GET /chat_a/exa...')
#3 /Users/hisashi/git/Wrench/vendor/wrench/wrench/lib/Wrench/ConnectionManager.php(243): Wrench\Connection->process()
#4 /Users/hisashi/git/Wrench/vendor/wrench/wrench/lib/Wrench/ConnectionManager.php(168): Wrench\ConnectionManager->processClientSocket(Resource id #35)
#5 /Users/hisashi/git/Wrench/vendor/wrench/wrench/lib/Wrench/Server.php(198): Wrench\ConnectionManager->selectAndProcess()
#6 /Users/hisashi/git/Wrench/examples/server.php(45): Wrench\Server->run()
#7 {main}

Feel free to rebase and reopen

authors: dominics hisahisa

repo: varspool/Wrench

license: WTFPL


text:
Using Azure OpenAI API

Hi there,
Thanks for the great project, I want to use Azure OpenAI API instead of OpenAI, but I don't know where I can modify it (Keys,..)
Thank you.

Hey, there
Thank you for the great project, I also ran into the same problem, also want to use  Azure OpenAI API , what needs to be modified thanks.

@thanhsang298 and @wyl88wyl I've good news - in this PR https://github.com/varunshenoy/GraphGPT/pull/40 you can use Azure AI Studio API :-) Please add +1 and of course, if you have any feedback, please add in the below PR.

repo: varunshenoy/GraphGPT


text:
Unstable z values

When using the library I often have the z dimension reaching unexpected high values (and not recovering from it). I had a peek at the source and changing line 19 in cluster.js seems to fix it.
Original:
l = Math.sqrt(x * x + y * y);

Updated:
l = Math.sqrt(x * x + y * y + z * z);

Good catch @christiandewit. The z dimension is not being included in the distance calculation.
Would you like to open a PR with the fix?

authors: christiandewit vasturiano


text:
Either a bug or I'm just ignorant. Workspaces on waybar

Workpsaces do not appear on waybar. I already tried Hyprland/workspaces, hyprland/workspaces, and wlr/workspaces in the config file.
Also, how do I add a windowrule to set a window to ignore the transparency and blur setting? I saw the example windowrules, and decided you were more immature then I thought.

thanks for the "you were more immature than i thought" line.
workspaces do not appear on waybar? launch from a terminal and notice that big-ass red error that the module was not found. Compile waybar manually with the HAVE_WLR and EXPERIMENTAL flags. If you don't know how to add them, just define them in the factory header.
windowrules to ignore opacity and blur do not exist yet.

sounds good

I'm struggling to edit the file correctly, could you point me in the right direction? I know this isn't a hyprland issue, but I'd really appreciate it.

factory.hpp

@niwheeler07 Did you make waybar workspaces work? Built waybar with the needed flags but when using wlr/workspaces the modules is just empty in waybar. No errors on cli either about the workspace module missing

I have to switch workspaces before they will show up. Just to clarify, you put
#define HAVE_WLR
#define USE_EXPERIMENTAL
in your factory.hpp file (in the git repo) before compiling?

I have to switch workspaces before they will show up.

thats how the protocol works. waybar cant record certain default workspaces because they're init'd a bit too early. switch away from it (so that it gets deleted, so no windows on it) and back.

Also on my machine the workspace data shown on waybar is only accurate as to how many workspaces there are

correct. no idea why, i'll look into waybar, but hyprland does emit which workspace is active.

Cool, thanks!

I have to switch workspaces before they will show up.

fixed now

Also on my machine the workspace data shown on waybar is only accurate as to how many workspaces there are

seems like a waybar issue, however I couldn't see anything wrong either on mine or on their side. will look more into it later

Hate to bother ya again, but is it possible to prevent workspaces being deleted when there are no windows on them and they are not focused?

not possible.

ok

active workspaces use the style #workspaces button.active in waybar. Closing.

authors: VaughnValle niwheeler07 vaxerski

repo: vaxerski/Hyprland


text:
todo when AIP advances is available

@vbelus just an issue to keep in mind that once the AIP Advances paper is released, we should update the reference on the readme and link to it.

@vbelus the manuscript has just been released! Congratulations. I will send an email soon to everybody in the project. Can you add the link?
https://aip.scitation.org/doi/10.1063/1.5132378

PS: attends un peu pour linkedin etc, on en discute sur comment partager, j aimerais attendre la semaine prochaine pour le post linkedin.

repo: vbelus/falling-liquid-film-drl


text:
把vben3-doc集成过来

已经是monorepo结构了，把vben3-doc集成过来，就不用下两个项目了。

那个是文档


text:
Problems with wp-admin, frontend

I tried importing an existing database, overwriting the "wordpress" database. When I go to http://vccw.dev, the frontend works, though there is a large space above my content (and a smaller space below it). Odd. But if I go to http://vccw.dev/wp-admin, I get the following:

WordPress on VCCW is running with Debug Mode.
https://codex.wordpress.org/Debugging_in_WordPress
It is a problem of wpfw_menus_management plugin.

Thanks. Changing Debug Mode to "false" in /wp-config.php resolved both issues.

repo: vccw-team/vccw


text:
Added Pagination Component to Storybook

Added a Pagination component story to Storybook for better visualization and testing.
Maintained state in the Storybook story to demonstrate the Pagination component's functionality.

Ready for review and feedback.

I am new to this. Apologize if the last merge was not correct but I think the build failed. I have updated the packages/index.tsx

I am new to this. Apologize if the last merge was not correct but I think the build failed. I have updated the packages/index.tsx

no worries

I am new to this. Apologize if the last merge was not correct but I think the build failed. I have updated the packages/index.tsx

No worries, I can help you

repo: vczb/sagu-ui


text:
Response from MetaTrader is null

Hello dear,
funcitons return ==> Response from MetaTrader is null
Please you can guide me on what is missing to do, or why I receive the above message, I should do some steps before running the tester or what !!, check the attached image, thanks.
waiting for your replay.

the issue fixed from my side just built the solution with x64 to be compatible.

closing

repo: vdemydiuk/mtapi


text:
#60: Change certain fields to integers

#60

Codecov Report

Merging #61 (2e19218) into main (e13792d) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #61   +/-   ##
=======================================
  Coverage   94.06%   94.06%
=======================================
  Files           8        8
  Lines         236      236
=======================================
  Hits          222      222
  Misses         10       10
  Partials        4        4

Impacted Files
Coverage Δ

formatter/formatter_csv.go
100.00% <100.00%> (ø)

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 e13792d...2e19218. Read the comment docs.

authors: codecov-commenter vdjagilev

repo: vdjagilev/nmap-formatter


text:
modify image version

modify image version

modify image version

repo: vearch/vearch


text:
Added update_vocs to snakefile

Adds update_vocs to snakemake file

I must have push an outdated version of the branch and not caught it. I retested the snakemake file and it looks like everything is set now.

repo: vector-engineering/covidcg


text:
Client unable to send messages

Since the last update of Matrix-Synapse I'm unable to send messages with my Android Client.
When I write a message and send it, the message turns green.
After some waiting it just says that it couldn't send my message and asks me if I want to retry it,
or if I want to cancel it.

We've experienced this problem too, with synapse 1.5.1 and only with encrypted rooms. Clearing the app data and cache (to force a resync) fixed it for me.

Is this going to get fixed? It's very annoying.

Cleaning only the cache of riot was enough here. Thanks @rbns

I've also been bitten by this and it is really annoying, especially for non-technical users who just see it as "Riot is not working" and even more especially because since it's triggered in encrypted rooms, it directly affects non-casual use of the system.
I tried on several devices to just clean the cache (not app data), but it didn't do the trick for me. :cry:
Would it be safe to temporarily revert to say Matrix Synapse 1.4.1? I also see that 1.6.0 is out, I'll try it and report back…

Upgrading to Synapse 1.6.0 seemed to fix the issue (for the moment) and all pending "grey and green" messages went through. I don't know which one of the fixes in the release did the magic, though!

Would it be safe to temporarily revert to say Matrix Synapse 1.4.1? I also see that 1.6.0 is out, I'll try it and report back…
I'd say you just relogon to your mobile devices, that fixed it for me.

This is a bit old. Don't know if fixed or now.
Possible walkarounds are to clear the cache of the app or to logout and log back in.
Both ways need you to login again anyways.
// closed

repo: vector-im/riot-android


text:
[feat] enable prefix cache in block manager

Key features:

allocate shared blocks from prefix cache based on prefix
put blocks into prefix cache instead of return back to allocator
only try to evict blocks from prefix cache if no blocks available in block allocator.

disabled failed schedule tests for now. the root cause is related to object gc problem before exit. need further investigation. Following check triggered.
BlockAllocator::~BlockAllocator() {
  CHECK(free_block_count_ == free_blocks_.size())
      << "Not all blocks have been freed";
}

repo: vectorch-ai/ScaleLLM


text:
Filter not being applied anymore after reordering columns

Hello,
I still have the problem even with the latest beta (using 0.8.8.beta.30 in local, and 0.8.8.beta.26 in jsfiddle) that is supposed to handle reordering on all filter types.
Here is my code example :
http://jsfiddle.net/Cymo_/j7h7c5cg/11/
The col 3 is supposed to be filtered by the number range slider, and the col 0 by the multiple select.
It work fine with the "All" and "Scenario 1" scenarios because the order is the same.
But when I manually reorder or when I chose another scenario, suddenly, a wild bug appears and is super effective (aka the filters don't work anymore)!
I am using external filters and I select the content to filter with the "html_data_selector" property.
Any ideas?
Thanks for your help!
Tim

Please try beta.31

Hi vedmack,
It seems like it does not work either with the beta.31 version of the script. :(
Here is the jsfiddle : http://jsfiddle.net/j7h7c5cg/13/
You can see in the 'External Resources' section that I included the file you linked in your last comment.
Am I doing something wrong?

Hello Daniel,
I confirm this problem with beta 32 too (see all my test case).
http://yadcf.johndegey.org/

Will see what went wrong, because I remember it used to work in your examples @johndegey

can you check your table with the beta.17 version and tell me how it works for you

closing this one because I found the bug that messed my colreorder suppport, hopefully it fixed your issue too, if not let me know,
grab the beta.35

Seems to work fine with the beta.35, awesome work man.
I will get back to you if I find some side effects of your bugfix.
Again, thank you ! :)

Nice work...
Thanks

Hi Daniel,
Datatables forgets the pagination and the filters that have been set with "exFilterColumn" when I refreshthe page... (The filters set through the UI are saved)
Could it be related?
Might be a problem similar to the one you posted in february :
https://github.com/DataTables/DataTables/issues/499
I use table.columns.adjust().draw(false); myself at some point (note the boolean), but it does not work either.
I tried with the nightly 1.10.8-dev of Datatables and the last beta of your plugin (beta.35).
Thanks!

Hi,
Try without yadcf, and see if pagination getting lost after refresh, also try with .draw(true) ... if it works with true report to datatables, if pagination getting lost in either true or false report to datatables too

Hi,
I did try without yadcf, it works as expected :
DataTables saves the pagination and the draw(true) resets it (draw(false) does not change the current pagination as well)
I got two questions remaining :

Is it normal that the filters are not saved with oTable.fnSettings().oApi._fnSaveState(oTable.fnSettings()); when calling the exFilterColumn method?
I see in the exFilterColumn method that the oTable.fnSettings().oLoadedState.yadcfState
array is not updated when setting programmaticaly the column filter value.
Would it be possible to do so when the stateSave parameter is set to true in the DataTables settings?
I don't know if it is a bug or a feature. :)

For the pagination loss problem :
The oTable.fnDraw(false); in the initAndBindTable function on line 2995 is the one responsible of the pagination change (commented it, the pagination did not change on page refresh).
Though, the fnDraw() is supposed to be fixed in the version of DT that I use...
Do you think it is a problem on the DT side?

Thanks for you help / work !

Thanks, I will check it in the following days

grab beta.36 it solves the StateSavefor exFilterColumn , as to the pagination, I could not reproduce it, try this link , you can try calling yadcf.exFilterColumn(oTable, [[4, 'Tag1']]); from the dev tools console, the best thing would be if you provide a link to a working sample with a scenario to reproduce it... (better open a new issue for that)

Hi vedmack,
I have the same problem with pagination. The @Cymo had previously reported.
I am using the DataTables version 1.10.12 and Yadcf version 0.8.9.
I am using stateSave: true and when i go refresh the page, my pagination not save.
When i changed the code at line 3413:
//when using DOM source
if (isDOMSource(oTable)) {
	//we need to make sure that the yadcf state will be saved after page reload
	oTable.fnSettings().oApi._fnSaveState(oTable.fnSettings());
	//redraw the table in order to apply the filters
	oTable.fnDraw(false);
}

to:
//when using DOM source
if (isDOMSource(oTable)) {
	//we need to make sure that the yadcf state will be saved after page reload
	oTable.fnSettings().oApi._fnSaveState(oTable.fnSettings());
	//redraw the table in order to apply the filters
	oTable.draw(true); // ** I changed **
}

It's works!
Your link previously reported is broken.
You can check, please?
Thank you.

Hi,
Please provide a test page using your prefered js playground page with the latest datatables and the latest yadcf beta and open a new issue

Ok, thank you!
I will provide

authors: Cymo- DiloWagner johndegey vedmack

repo: vedmack/yadcf


text:
improve docs on pie charts

What is your suggestion?
Currently there are very few examples of how to use pie charts.
There are a couple of examples that come to my mind which are complex and general enough to allow for many use cases.
First:

I know there is currently the laballed example using mark_text and the radius. Sometimes the data is too dense for it to be usable. It would be nice to see how one could create a
Have you considered any alternative solutions?
No response

Thanks for the suggestion! Currently there is no way of automatically positioning labels so that they don't overlap. When https://github.com/vega/vega-lite/issues/7228 is implemented in Vega-Lite, this functionality will be available in Altair.

Hey! Just got around to read a bit on that issue. Hope that gets implemented soon.
I just realized my issue was cut short!
The topics I was most interested in were:

The "arrows" that connect the slices with the labels.
The possibility to make these charts interactive.

I kept trying to come up with something for the second thing, but couldn't make it. I'm not very savy on visualizations.
Thanks for your time!

authors: francocalvo joelostblom

repo: vega/altair


text:
Issues with staking page after mainnet upgrade

Caused by an api issue getting nodeData

repo: vegaprotocol/frontend-monorepo


text:
Only close extension once queue of transactions/interactions has been completed

Chore
When #185 lands we only want to close the auto opened when the queue is cleared.
Probably this logic should be moved to the backend.
Tasks

[ ]
[ ]
[ ]

Notes

Decided this was too painful for the value it delivered. Descoped.

repo: vegaprotocol/vegawallet-browser


text:
Zoom has to be greater than or equal to 0.031250

From https://mods.factorio.com/mod/TLBE/discussion/671ce2f9dc0b8de9590f7c65

Hi,
playing Space Age with this mod (, thanks, it has worked great until) today while I was expanding my outer perimeter I received an error as follows:
The mod Time Lapse Base Edition (2.0.1) caused a non-recoverable error.
Please report this error to the mod author.
Error while running event TLBE::on_ tick (ID 0)
Zoom has to be greater than or equal to 0.031250
stack traceback:
[C]: in function 'take_screenshot'
TLBE/scripts/main.lua:168: in function 'takeScreenshot'
TLBE/scripts/main.lua:46: in function 'tick'
TLBE/control.lua:81: in function <TLBE/control.lua:80>

Max zoom has been fixed over 4 years ago by 645c528efcca6116bb6ebd1b047316d9c033a347
But there is a path where the check
https://github.com/veger/TLBE/blob/3f20d91be85e4e53a7d02c89b8722028f67db795/scripts/camera.lua#L200
is circumvented. Which is possible when smooth transitions are disabled.

This should be fixed in the next release

v2.0.2 is released

repo: veger/TLBE


text:
Add Java4Ever framework

Added Java4Ever framework information on Venom Developer Program

Nice

authors: Kingrarewolf cassandrus

repo: venom-blockchain/developer-program


text:
Preserve file modification date when stripping binaries

Fix for https://github.com/veracruz-project/veracruz/issues/541

The change looks safe enough but ... why should the EIF be rebuilt every time (is it because of a hardwired certificate expiry date?), why was it being rebuilt every other time, why does this change fix the problem, and is it safe to modify the output of cargo build in place rather than create the stripped file elsewhere, which is what happens in workspaces/icecap-runtime/Makefile using a -o argument with strip?

why should the EIF be rebuilt every time (is it because of a hardwired certificate expiry date?)

I don't know how often it should be built. At least as often as the RM binary is built.
Before this PR, the EIF would be built everytime the RM binary is built, but also every other time the RM binary was not built IIUC, which is confusing and wastes CPU time.

why was it being rebuilt every other time

It was built every other time because strip was called regardless of whether cargo build was successful in building RM (there doesn't seem to be any way to know whether cargo build actually rebuilt the binary, besides grepping the output or looking at the binary), which changed the modification date of the RM binary, which led make to believe on the next run that the RM binary had been updated.

why does this change fix the problem

Now strip preserves modification time, which is one solution among others

and is it safe to modify the output of cargo build in place rather than create the stripped file elsewhere, which is what happens in workspaces/icecap-runtime/Makefile using a -o argument with strip?

In the past we suffered from stale binaries originating from superfluous copies (cf. https://github.com/veracruz-project/veracruz/pull/339). It's a real pain to debug so I'd argue against that.
How about calling strip only if the binary was updated?

The alternating behaviour can be demonstrated with this simplified Makefile:
eif: binary
	cp binary eif

binary: binary-phony

binary-phony:
	touch binary

I've made #617 which fixes a related bug, I think, though I haven't really tested it: it's time to go home now!

Already fixed in https://github.com/veracruz-project/veracruz/pull/617

authors: egrimley-arm gbryant-arm

repo: veracruz-project/veracruz


text:
AR4SI mappings folder

Starting with CCA

@SimonFrost-Arm @setrofim @yogeshbdeshpande please review

repo: veraison/docs


text:
Update layout.tsx

Obvious unnecessary null check remove.
It assigns a variable then makes a null check. I see mock purposes but wanted to prevent confusion.

Thanks!

authors: MetinArslanturk delbaoliveira

repo: vercel/app-playground


text:
Added Umbraco provider

Adding a link to the Umbraco + Umbraco Commerce implementation of the Vercel Commerce demo.
Worth noting, our repo has a little different structure as we wanted to include the back end project as well so we have a backend/main and a frontend/main branch accordingly. The frontend/main branch can easily be merged with upstream changes from the vercel commerce repo.
NB This is a re-submission of https://github.com/vercel/commerce/pull/1165 as during come cleanup I inadvertently removed my previous fork 🤦♂

@leerob just to follow up from the original PR, the 500 error is resolved and I'd like to request a copy of the product images to see if that resolves slow image load speeds 👍

I'd like to request a copy of the product images

You can download them here.

Images should now be updated so hopefully this resolves the slow loading for you.
Beyond that, I believe it should now be good to approve

No problem at all. Thank you for taking the time to feedback. It’s a lovely demo project and really glad I got to implement it.

authors: manovotny mattbrailsford

repo: vercel/commerce


text:
Sync from codesandbox adoring-smoke

ts.config aliases updated

Same as https://github.com/vercel/next-learn/pull/742

authors: De-Ash delbaoliveira

repo: vercel/next-learn


text:
fix(docs): landing page CLS

Fix CLS on landing page caused by font loading issues

Sending this one to fix ASAP

repo: vercel/turbo


text:
Skip formatting ffi.rs

This can otherwise cause rustfmt to fail with the following when ffi.rs hasn't been generated yet:
Error writing files: failed to resolve mod `ffi`: /Users/alex/dev/turbo/shim/src/ffi.rs does not exist

the proper fix would be to not generate files into the src directory (or commit them to the repo)

authors: ForsakenHarmony alexkirsz


text:
Scoped packages not showing up in the WebUI

My reason:
Publishing a scoped package such as @company/mypackage works correctly and allows the package to be installed using npm. However the package does not show up anywhere on the WebUI.
Steps to reproduce:

Run verdaccio in a docker container
Publish a scoped package such as @company/mypackage
Access the webui http://localhost:8473
The package is not displayed in the index and searching for it does not return anything

Publishing the exact same package but without the scope works as expected.
App Version:
verdaccio@2.6.3
Config file:
storage: /verdaccio/storage

web:
  enable: true
  title: "Company Verdaccio"

auth:
  ldap:
    type: ldap
    groupNameAttribute: "cn"
    client_options:
      url: "ldaps://ldap.company.com"
      searchBase: "ou=personnel,dc=dir,dc=company,dc=com"
      searchFilter: "(uid={{username}})"
      cache: False
      searchAttributes:
        - memberOf

uplinks:
  npmjs:
    url: https://registry.npmjs.org/

packages:
  "**":
    access: $all
    publish: $authenticated
    proxy: npmjs

  "@*/*":
    access: $all
    publish: $authenticated
    proxy: npmjs

logs:
  - {type: stdout, format: pretty, level: http}

Additional information:
Verdaccio runs in a docker container built using the following config:
# Based on: https://github.com/verdaccio/verdaccio/blob/master/Dockerfile
FROM node:8.7.0-alpine
LABEL maintainer="https://github.company.com/user/verdaccio"

RUN apk --no-cache add openssl && \
    wget -O /usr/local/bin/dumb-init https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64 && \
    chmod +x /usr/local/bin/dumb-init && \
    apk del openssl

ENV APPDIR /usr/local/app

WORKDIR $APPDIR

ADD . $APPDIR

ENV NODE_ENV=production

RUN npm config set registry http://registry.npmjs.org/ && \
    npm install -g verdaccio@latest verdaccio-ldap@latest

RUN mkdir -p /verdaccio/storage /verdaccio/conf

ADD config.yaml /verdaccio/conf/config.yaml

RUN addgroup -S verdaccio && adduser -S -G verdaccio verdaccio && \
    chown -R verdaccio:verdaccio "$APPDIR" && \
    chown -R verdaccio:verdaccio /verdaccio

USER verdaccio

ENV PORT 4873
ENV PROTOCOL http

EXPOSE $PORT

VOLUME ["/verdaccio"]

ENTRYPOINT ["/usr/local/bin/dumb-init", "--"]

CMD verdaccio --config /verdaccio/conf/config.yaml --listen $PROTOCOL://0.0.0.0:${PORT}

The host is running macOS 10.12.6.

Are you using a Nginx or Apache as a proxy?

Nope.
I am running the container standalone for testing.
Build Command:
docker build -t company-verdaccio .

Run Command:
docker run -it --rm --name company-verdaccio -p 4873:4873 company-verdaccio

This is using Docker for Mac.

I have the same set up and works for me. I'll have to check again.

Same here, i can't reproduce this issue with:
packages:
  "**":
    access: $all
    publish: $authenticated
    proxy: npmjs

  "@*/*":
    access: $all
    publish: $authenticated
    proxy: npmjs

Guys. I have to apologize.
After doing more testing I discovered that I had configuration in my global .npmrc file that set the registry for the scope I was testing with to a different server which overwrote my package publishConfig setting and the --registry command line parameter so I was publishing to a different private registry when I was testing with that scope.
Not a verdaccio issue, thank you for all your help!

authors: Meeeeow juanpicado marekl

repo: verdaccio/verdaccio


text:
V1.12.1 issue: Connection refused to VerneMQ server since 7/23/2021

It worked fine before 7/22/2021. Found out that you just updated to 1.12.1 between 7/22 and 7/23. Now we can't connect to the vernemq. Could you please let us know what have been changed from 1.11.0 to 1.12.1?
Here is the log:

OnConnectingFailed [Exception]:       MQTTnet.Exceptions.MqttCommunicationException: Connection refused
---> System.Net.Sockets.SocketException (111): Connection refused
at System.Net.Sockets.Socket.BeginConnectEx(EndPoint remoteEP, Boolean flowContext, AsyncCallback callback, Object state)
at System.Net.Sockets.Socket.UnsafeBeginConnect(EndPoint remoteEP, AsyncCallback callback, Object state, Boolean flowContext)
at System.Net.Sockets.Socket.BeginConnect(EndPoint remoteEP, AsyncCallback callback, Object state)
at System.Net.Sockets.Socket.BeginConnect(IPAddress address, Int32 port, AsyncCallback requestCallback, Object state)
at System.Net.Sockets.Socket.BeginConnect(String host, Int32 port, AsyncCallback requestCallback, Object state)
at System.Net.Sockets.Socket.ConnectAsync(String host, Int32 port)
at System.Net.Sockets.SocketTaskExtensions.ConnectAsync(Socket socket, String host, Int32 port)
at MQTTnet.Implementations.CrossPlatformSocket.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
at MQTTnet.Implementations.MqttTcpChannel.ConnectAsync(CancellationToken cancellationToken)
at MQTTnet.Internal.MqttTaskTimeout.WaitAsync(Func`2 action, TimeSpan timeout, CancellationToken cancellationToken)
at MQTTnet.Adapter.MqttChannelAdapter.ConnectAsync(TimeSpan timeout, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at MQTTnet.Adapter.MqttChannelAdapter.WrapException(Exception exception)
at MQTTnet.Adapter.MqttChannelAdapter.ConnectAsync(TimeSpan timeout, CancellationToken cancellationToken)
at MQTTnet.Client.MqttClient.ConnectAsync(IMqttClientOptions options, CancellationToken cancellationToken)
at MQTTnet.Client.MqttClient.ConnectAsync(IMqttClientOptions options, CancellationToken cancellationToken)
at MQTTnet.Extensions.ManagedClient.ManagedMqttClient.ReconnectIfRequiredAsync()
OnDisconnected [ClientWasConnected]:       False
OnDisconnected [AuthenticateResult]:
OnDisconnected [Exception]:       MQTTnet.Exceptions.MqttCommunicationException: Connection refused

Environment

VerneMQ Version:1.12.1
OS:
Erlang/OTP version (if building from source):
VerneMQ configuration (vernemq.conf) or the changes from the default
Cluster size/standalone:

Expected behaviour

Please describe the expected behaviour.

Actual behaviour

Please include minimal steps to reproduce the issue, if possible.

@bliusb thanks... this is a client log that tells you the connection was refused. It's not enough information to allow me to help. First thing to do is to check whether the MQTT listener(s) are actually up (vmq-admin listener show).

:point_right: Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
:point_right: Using the binary VerneMQ packages (.deb/.rpm/Docker) requires a subscription.

authors: bliusb ioolkos

repo: vernemq/vernemq