debugger doesn't work with native lldb adapter type

OS: macOS Catalina 10.15.2
VSCode version:  1.41
Extension version: 1.4.5
Python version: Python 3.7.5
LLDB version: lldb-1<IP_ADDRESS>
Apple Swift version 5.1.3 (swiftlang-1100.0.282.1 clang-1<IP_ADDRESS>)
I am debugging the aom av1 which is the video codec written by C (https://aomedia.googlesource.com/aom/). When I use the native lldb adapter type, the debugger seems to stop. It can't display call stack well (only shows the function that has break point). I changed the adapter type to classic, then it works well. In the case of simple c code, both adapter type works well.

 However, var,[10] expression doesn't work with classic adapter.

Simple question:
Is there any way to see the multiple elements of the array with hex or decimal format by user setting?
ex) var,[10],x ??

Can you please add "lldb.adapterEnv": { "RUST_BACKTRACE": "1" } to your workspace settings and post the resulting debugger log again?

However, var,[10] expression doesn't work with classic adapter.

Classic adapter does not support such formatting.

Is there any way to see the multiple elements of the array with hex or decimal format by user setting?

Not currently.   However you can switch the default display format to hex (via LLDB: Display Format... command).

Thanks you for you reply.
I added "lldb.adapterEnv": { "RUST_BACKTRACE": "1" } to settings.json in .vscode directory. Output log is as below:
configuration: {
name: 'Launch',
type: 'lldb',
request: 'launch',
program: '${workspaceFolder}/aom_build/aomenc',
args: [
'-o',
'output.av1',
'-w',
'352',
'-h',
'288',
'--limit=3',
'foreman_cif.yuv'
],
cwd: '${workspaceFolder}/aom_build/',
relativePathBase: '/Users/brayden/Project/Voyager1/aomedia'
}
liblldb: /Users/brayden/.vscode/extensions/vadimcn.vscode-lldb-1.4.5/lldb/lib/liblldb.dylib
libpython: /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/Python
environment: { RUST_BACKTRACE: '1' }
params: {}
Listening on port 58254
[2020-01-06T04:38:26Z DEBUG codelldb] New debug session
INFO(Python) 13:38:26 rust: Initializing, module name=rust
DEBUG(Python) 13:38:26 rust: attaching summary get_tuple_summary to "^(.)$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StrSliceSynthProvider to "&str", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "&str", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StrSliceSynthProvider to "str", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StrSliceSynthProvider to "str*", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdStringSynthProvider to "collections::string::String", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "collections::string::String", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdStringSynthProvider to "alloc::string::String", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdStringSynthProvider to "alloc::string::String", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdVectorSynthProvider to "^collections::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^collections::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdVectorSynthProvider to "^alloc::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdVectorSynthProvider to "^alloc::vec::Vec<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic SliceSynthProvider to "^&(mut\s*)?[.]$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^&(mut\s)?[.]$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic SliceSynthProvider to "^slice<.+>.$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_SliceSynthProvider to "^slice<.+>.*$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdCStringSynthProvider to "std::ffi::c_str::CString", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdCStrSynthProvider to "std::ffi::c_str::CStr", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdOsStringSynthProvider to "std::ffi::os_str::OsString", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdOsStrSynthProvider to "std::ffi::os_str::OsStr", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdPathBufSynthProvider to "std::path::PathBuf", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdPathSynthProvider to "std::path::Path", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdPathSynthProvider to "std::path::Path", is_regex=False
DEBUG(Python) 13:38:26 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Rc<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Rc<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdRcSynthProvider to "^alloc::rc::Weak<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdRcSynthProvider to "^alloc::rc::Weak<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Arc<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdArcSynthProvider to "^alloc::(sync|arc)::Weak<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdMutexSynthProvider to "^std::sync::mutex::Mutex<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdMutexSynthProvider to "^std::sync::mutex::Mutex<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdCellSynthProvider to "^core::cell::Cell<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdCellSynthProvider to "^core::cell::Cell<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdRefCellSynthProvider to "^core::cell::RefCell<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdRefCellSynthProvider to "^core::cell::RefCell<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::Ref<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::Ref<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdRefCellBorrowSynthProvider to "^core::cell::RefMut<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdHashMapSynthProvider to "^std::collections::hash::map::HashMap<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching synthetic StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.+>$", is_regex=True
DEBUG(Python) 13:38:26 rust: attaching summary _get_synth_summary_StdHashSetSynthProvider to "^std::collections::hash::set::HashSet<.+>$", is_regex=True
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] --> {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"lldb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"ko"},"type":"request","seq":1}
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] <-- {"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,"supportsCompletionsRequest":true,"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsDataBreakpoints":true,"supportsDelayedStackTraceLoading":true,"supportsEvaluateForHovers":true,"supportsFunctionBreakpoints":true,"supportsGotoTargetsRequest":true,"supportsHitConditionalBreakpoints":true,"supportsLogPoints":true,"supportsRestartFrame":true,"supportsSetVariable":true}}
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] --> {"command":"launch","arguments":{"name":"Launch","type":"lldb","request":"launch","program":"/Users/brayden/Project/Voyager1/aomedia/aom_build/aomenc","args":["-o","output.av1","-w","352","-h","288","--limit=3","foreman_cif.yuv"],"cwd":"/Users/brayden/Project/Voyager1/aomedia/aom_build/","relativePathBase":"/Users/brayden/Project/Voyager1/aomedia","_adapterSettings":{"displayFormat":"decimal","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null},"__sessionId":"560f2714-25d9-45d6-826d-33ffa5e83403"},"type":"request","seq":2}
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":1,"event":"initialized"}
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] --> {"command":"setBreakpoints","arguments":{"source":{"name":"av1_fwd_txfm2d.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/av1_fwd_txfm2d.c"},"lines":[77,87,109],"breakpoints":[{"line":77},{"line":87},{"line":109}],"sourceModified":false},"type":"request","seq":3}
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] --> {"command":"setBreakpoints","arguments":{"source":{"name":"bitstream.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/bitstream.c"},"lines":[2873],"breakpoints":[{"line":2873}],"sourceModified":false},"type":"request","seq":4}
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] --> {"command":"setBreakpoints","arguments":{"source":{"name":"daalaboolwriter.h","path":"/Users/brayden/Project/Voyager1/aomedia/aom/aom_dsp/daalaboolwriter.h"},"lines":[54],"breakpoints":[{"line":54}],"sourceModified":false},"type":"request","seq":5}
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] --> {"command":"setBreakpoints","arguments":{"source":{"name":"decodeframe.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/decoder/decodeframe.c"},"lines":[1551],"breakpoints":[{"line":1551}],"sourceModified":false},"type":"request","seq":6}
[2020-01-06T04:38:26Z DEBUG codelldb::wire_protocol] --> {"command":"setBreakpoints","arguments":{"source":{"name":"rdopt.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/rdopt.c"},"lines":[3468],"breakpoints":[{"line":3468}],"sourceModified":false},"type":"request","seq":7}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"line":77,"message":"Locations: 1","source":{"name":"av1_fwd_txfm2d.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/av1_fwd_txfm2d.c"},"verified":true},{"id":2,"line":87,"message":"Locations: 1","source":{"name":"av1_fwd_txfm2d.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/av1_fwd_txfm2d.c"},"verified":true},{"id":3,"line":109,"message":"Locations: 1","source":{"name":"av1_fwd_txfm2d.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/av1_fwd_txfm2d.c"},"verified":true}]}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":4,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":4,"line":2874,"message":"Locations: 1","source":{"name":"bitstream.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/bitstream.c"},"verified":true}]}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":5,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":5,"line":54,"message":"Locations: 3","source":{"name":"daalaboolwriter.h","path":"/Users/brayden/Project/Voyager1/aomedia/aom/aom_dsp/daalaboolwriter.h"},"verified":true}]}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":6,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":6,"line":1551,"message":"Locations: 1","source":{"name":"decodeframe.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/decoder/decodeframe.c"},"verified":true}]}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":7,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":7,"line":3468,"message":"Locations: 1","source":{"name":"rdopt.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/rdopt.c"},"verified":true}]}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":8}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":8,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":9}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":9,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] --> {"command":"setExceptionBreakpoints","arguments":{"filters":[]},"type":"request","seq":10}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":10,"success":true,"command":"setExceptionBreakpoints"}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] --> {"command":"configurationDone","type":"request","seq":11}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"request","seq":2,"command":"runInTerminal","arguments":{"args":["/Users/brayden/.vscode/extensions/vadimcn.vscode-lldb-1.4.5/adapter2/codelldb","terminal-agent","--port=58256"],"cwd":"","kind":"integrated","title":"Launch"}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] --> {"type":"response","seq":12,"command":"runInTerminal","request_seq":2,"success":true,"body":{"shellProcessId":12722}}
[2020-01-06T04:38:27Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":3,"event":"output","body":{"output":"Launching: /Users/brayden/Project/Voyager1/aomedia/aom_build/aomenc -o output.av1 -w 352 -h 288 --limit=3 foreman_cif.yuv\n"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":2,"success":true,"command":"launch"}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace194298 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":11,"success":true,"command":"configurationDone"}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace192d68 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace192e48 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace194938 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace194aa8 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace194b88 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace194c98 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcac7c2e378 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcac7c2e588 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcac7c2e7e8 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcac7ed4d48 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcac7ed4c08 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcac7c2ea18 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcac7c2ec48 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace198dc8 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace199008 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace19b048 Event: broadcaster = 0x7fcac8020018 (lldb.target), type = 0x00000002 (modules-loaded), data = {dyld, aomenc}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace19ef70 Event: broadcaster = 0x7fcac926ce50 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fcac926ce18 (pid = 12758), state = running}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":4,"event":"module","body":{"module":{"addressRange":"100578000","id":"100578000","name":"dyld","path":"/usr/lib/dyld","symbolFilePath":"/usr/lib/dyld","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":5,"event":"module","body":{"module":{"addressRange":"100000000","id":"100000000","name":"aomenc","path":"/Users/brayden/Project/Voyager1/aomedia/aom_build/aomenc","symbolFilePath":"/Users/brayden/Project/Voyager1/aomedia/aom_build/aomenc","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":6,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"threads","type":"request","seq":13}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":13,"success":true,"command":"threads","body":{"threads":[{"id":401733,"name":"1: tid=401733"}]}}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcac7f23488 Event: broadcaster = 0x7fcac8020018 (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_configuration.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_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}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":7,"event":"module","body":{"module":{"addressRange":"7FFF6FBD1000","id":"7FFF6FBD1000","name":"libc++.1.dylib","path":"/usr/lib/libc++.1.dylib","symbolFilePath":"/usr/lib/libc++.1.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":8,"event":"module","body":{"module":{"addressRange":"7FFF6F8EB000","id":"7FFF6F8EB000","name":"libSystem.B.dylib","path":"/usr/lib/libSystem.B.dylib","symbolFilePath":"/usr/lib/libSystem.B.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":9,"event":"module","body":{"module":{"addressRange":"7FFF6FC25000","id":"7FFF6FC25000","name":"libc++abi.dylib","path":"/usr/lib/libc++abi.dylib","symbolFilePath":"/usr/lib/libc++abi.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":10,"event":"module","body":{"module":{"addressRange":"7FFF7288E000","id":"7FFF7288E000","name":"libcache.dylib","path":"/usr/lib/system/libcache.dylib","symbolFilePath":"/usr/lib/system/libcache.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":11,"event":"module","body":{"module":{"addressRange":"7FFF72894000","id":"7FFF72894000","name":"libcommonCrypto.dylib","path":"/usr/lib/system/libcommonCrypto.dylib","symbolFilePath":"/usr/lib/system/libcommonCrypto.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":12,"event":"module","body":{"module":{"addressRange":"7FFF728A0000","id":"7FFF728A0000","name":"libcompiler_rt.dylib","path":"/usr/lib/system/libcompiler_rt.dylib","symbolFilePath":"/usr/lib/system/libcompiler_rt.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":13,"event":"module","body":{"module":{"addressRange":"7FFF728A8000","id":"7FFF728A8000","name":"libcopyfile.dylib","path":"/usr/lib/system/libcopyfile.dylib","symbolFilePath":"/usr/lib/system/libcopyfile.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":14,"event":"module","body":{"module":{"addressRange":"7FFF728B2000","id":"7FFF728B2000","name":"libcorecrypto.dylib","path":"/usr/lib/system/libcorecrypto.dylib","symbolFilePath":"/usr/lib/system/libcorecrypto.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":15,"event":"module","body":{"module":{"addressRange":"7FFF72A60000","id":"7FFF72A60000","name":"libdispatch.dylib","path":"/usr/lib/system/libdispatch.dylib","symbolFilePath":"/usr/lib/system/libdispatch.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":16,"event":"module","body":{"module":{"addressRange":"7FFF72AA2000","id":"7FFF72AA2000","name":"libdyld.dylib","path":"/usr/lib/system/libdyld.dylib","symbolFilePath":"/usr/lib/system/libdyld.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":17,"event":"module","body":{"module":{"addressRange":"7FFF72AD8000","id":"7FFF72AD8000","name":"libkeymgr.dylib","path":"/usr/lib/system/libkeymgr.dylib","symbolFilePath":"/usr/lib/system/libkeymgr.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":18,"event":"module","body":{"module":{"addressRange":"7FFF72AE6000","id":"7FFF72AE6000","name":"liblaunch.dylib","path":"/usr/lib/system/liblaunch.dylib","symbolFilePath":"/usr/lib/system/liblaunch.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":19,"event":"module","body":{"module":{"addressRange":"7FFF72AE7000","id":"7FFF72AE7000","name":"libmacho.dylib","path":"/usr/lib/system/libmacho.dylib","symbolFilePath":"/usr/lib/system/libmacho.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":20,"event":"module","body":{"module":{"addressRange":"7FFF72AED000","id":"7FFF72AED000","name":"libquarantine.dylib","path":"/usr/lib/system/libquarantine.dylib","symbolFilePath":"/usr/lib/system/libquarantine.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":21,"event":"module","body":{"module":{"addressRange":"7FFF72AF0000","id":"7FFF72AF0000","name":"libremovefile.dylib","path":"/usr/lib/system/libremovefile.dylib","symbolFilePath":"/usr/lib/system/libremovefile.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":22,"event":"module","body":{"module":{"addressRange":"7FFF72AF2000","id":"7FFF72AF2000","name":"libsystem_asl.dylib","path":"/usr/lib/system/libsystem_asl.dylib","symbolFilePath":"/usr/lib/system/libsystem_asl.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":23,"event":"module","body":{"module":{"addressRange":"7FFF72B0A000","id":"7FFF72B0A000","name":"libsystem_blocks.dylib","path":"/usr/lib/system/libsystem_blocks.dylib","symbolFilePath":"/usr/lib/system/libsystem_blocks.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":24,"event":"module","body":{"module":{"addressRange":"7FFF72B0B000","id":"7FFF72B0B000","name":"libsystem_c.dylib","path":"/usr/lib/system/libsystem_c.dylib","symbolFilePath":"/usr/lib/system/libsystem_c.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":25,"event":"module","body":{"module":{"addressRange":"7FFF72B93000","id":"7FFF72B93000","name":"libsystem_configuration.dylib","path":"/usr/lib/system/libsystem_configuration.dylib","symbolFilePath":"/usr/lib/system/libsystem_configuration.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":26,"event":"module","body":{"module":{"addressRange":"7FFF72B97000","id":"7FFF72B97000","name":"libsystem_coreservices.dylib","path":"/usr/lib/system/libsystem_coreservices.dylib","symbolFilePath":"/usr/lib/system/libsystem_coreservices.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":27,"event":"module","body":{"module":{"addressRange":"7FFF72B9B000","id":"7FFF72B9B000","name":"libsystem_darwin.dylib","path":"/usr/lib/system/libsystem_darwin.dylib","symbolFilePath":"/usr/lib/system/libsystem_darwin.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":28,"event":"module","body":{"module":{"addressRange":"7FFF72BA4000","id":"7FFF72BA4000","name":"libsystem_dnssd.dylib","path":"/usr/lib/system/libsystem_dnssd.dylib","symbolFilePath":"/usr/lib/system/libsystem_dnssd.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":29,"event":"module","body":{"module":{"addressRange":"7FFF72BAC000","id":"7FFF72BAC000","name":"libsystem_featureflags.dylib","path":"/usr/lib/system/libsystem_featureflags.dylib","symbolFilePath":"/usr/lib/system/libsystem_featureflags.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":30,"event":"module","body":{"module":{"addressRange":"7FFF72BAE000","id":"7FFF72BAE000","name":"libsystem_info.dylib","path":"/usr/lib/system/libsystem_info.dylib","symbolFilePath":"/usr/lib/system/libsystem_info.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":31,"event":"module","body":{"module":{"addressRange":"7FFF72C29000","id":"7FFF72C29000","name":"libsystem_m.dylib","path":"/usr/lib/system/libsystem_m.dylib","symbolFilePath":"/usr/lib/system/libsystem_m.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":32,"event":"module","body":{"module":{"addressRange":"7FFF72C71000","id":"7FFF72C71000","name":"libsystem_malloc.dylib","path":"/usr/lib/system/libsystem_malloc.dylib","symbolFilePath":"/usr/lib/system/libsystem_malloc.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":33,"event":"module","body":{"module":{"addressRange":"7FFF72C99000","id":"7FFF72C99000","name":"libsystem_networkextension.dylib","path":"/usr/lib/system/libsystem_networkextension.dylib","symbolFilePath":"/usr/lib/system/libsystem_networkextension.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":34,"event":"module","body":{"module":{"addressRange":"7FFF72CA7000","id":"7FFF72CA7000","name":"libsystem_notify.dylib","path":"/usr/lib/system/libsystem_notify.dylib","symbolFilePath":"/usr/lib/system/libsystem_notify.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":35,"event":"module","body":{"module":{"addressRange":"7FFF72CC6000","id":"7FFF72CC6000","name":"libsystem_sandbox.dylib","path":"/usr/lib/system/libsystem_sandbox.dylib","symbolFilePath":"/usr/lib/system/libsystem_sandbox.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":36,"event":"module","body":{"module":{"addressRange":"7FFF72CCB000","id":"7FFF72CCB000","name":"libsystem_secinit.dylib","path":"/usr/lib/system/libsystem_secinit.dylib","symbolFilePath":"/usr/lib/system/libsystem_secinit.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":37,"event":"module","body":{"module":{"addressRange":"7FFF72BFC000","id":"7FFF72BFC000","name":"libsystem_kernel.dylib","path":"/usr/lib/system/libsystem_kernel.dylib","symbolFilePath":"/usr/lib/system/libsystem_kernel.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":38,"event":"module","body":{"module":{"addressRange":"7FFF72CB1000","id":"7FFF72CB1000","name":"libsystem_platform.dylib","path":"/usr/lib/system/libsystem_platform.dylib","symbolFilePath":"/usr/lib/system/libsystem_platform.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":39,"event":"module","body":{"module":{"addressRange":"7FFF72CBB000","id":"7FFF72CBB000","name":"libsystem_pthread.dylib","path":"/usr/lib/system/libsystem_pthread.dylib","symbolFilePath":"/usr/lib/system/libsystem_pthread.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":40,"event":"module","body":{"module":{"addressRange":"7FFF72CCE000","id":"7FFF72CCE000","name":"libsystem_symptoms.dylib","path":"/usr/lib/system/libsystem_symptoms.dylib","symbolFilePath":"/usr/lib/system/libsystem_symptoms.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":41,"event":"module","body":{"module":{"addressRange":"7FFF72CD6000","id":"7FFF72CD6000","name":"libsystem_trace.dylib","path":"/usr/lib/system/libsystem_trace.dylib","symbolFilePath":"/usr/lib/system/libsystem_trace.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":42,"event":"module","body":{"module":{"addressRange":"7FFF72CEE000","id":"7FFF72CEE000","name":"libunwind.dylib","path":"/usr/lib/system/libunwind.dylib","symbolFilePath":"/usr/lib/system/libunwind.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":43,"event":"module","body":{"module":{"addressRange":"7FFF72CF4000","id":"7FFF72CF4000","name":"libxpc.dylib","path":"/usr/lib/system/libxpc.dylib","symbolFilePath":"/usr/lib/system/libxpc.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":44,"event":"module","body":{"module":{"addressRange":"7FFF7173C000","id":"7FFF7173C000","name":"libobjc.A.dylib","path":"/usr/lib/libobjc.A.dylib","symbolFilePath":"/usr/lib/libobjc.A.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}}
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Callback for breakpoint location 1.1: where = aomenc`fwd_txfm2d_c + 280 at av1_fwd_txfm2d.c:77:30, address = 0x00000001001a8668, resolved, hit count = 1
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] Debug event: 0x7fcace194310 Event: broadcaster = 0x7fcac926ce50 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fcac926ce18 (pid = 12758), state = stopped}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":45,"event":"stopped","body":{"allThreadsStopped":true,"reason":"breakpoint","threadId":401733}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"threads","type":"request","seq":14}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":14,"success":true,"command":"threads","body":{"threads":[{"id":401733,"name":"1: tid=401733"}]}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"stackTrace","arguments":{"threadId":401733,"startFrame":0,"levels":1},"type":"request","seq":15}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":15,"success":true,"command":"stackTrace","body":{"stackFrames":[{"column":30,"id":1001,"line":77,"name":"fwd_txfm2d_c","source":{"name":"av1_fwd_txfm2d.c","path":"/Users/brayden/Project/Voyager1/aomedia/aom/av1/encoder/av1_fwd_txfm2d.c"}}],"totalFrames":21}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"temp_in[0],d","frameId":1001,"context":"watch"},"type":"request","seq":16}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"temp_in[1],d","frameId":1001,"context":"watch"},"type":"request","seq":17}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"temp_in[2],d","frameId":1001,"context":"watch"},"type":"request","seq":18}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"temp_in[3],d","frameId":1001,"context":"watch"},"type":"request","seq":19}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"temp_in,[4]","frameId":1001,"context":"watch"},"type":"request","seq":20}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"input[0]","frameId":1001,"context":"watch"},"type":"request","seq":21}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"input[1]","frameId":1001,"context":"watch"},"type":"request","seq":22}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"input[2]","frameId":1001,"context":"watch"},"type":"request","seq":23}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"evaluate","arguments":{"expression":"input[3]","frameId":1001,"context":"watch"},"type":"request","seq":24}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":16,"success":true,"command":"evaluate","body":{"result":"","type":"int32_t","variablesReference":0}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":17,"success":true,"command":"evaluate","body":{"result":"","type":"int32_t","variablesReference":0}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":18,"success":true,"command":"evaluate","body":{"result":"","type":"int32_t","variablesReference":0}}
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":19,"success":true,"command":"evaluate","body":{"result":"","type":"int32_t","variablesReference":0}}
thread 'DebugSession' panicked at 'called Option::unwrap() on a None value', src/libcore/option.rs:378:21
stack backtrace:
0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
1: core::fmt::write
2: std::io::Write::write_fmt
3: std::panicking::default_hook::{{closure}}
4: std::panicking::default_hook
5: std::panicking::rust_panic_with_hook
6: std::panicking::continue_panic_fmt
7: rust_begin_unwind
8: core::panicking::panic_fmt
9: core::panicking::panic
10: codelldb::debug_session::DebugSession::handle_evaluate_expression
11: codelldb::debug_session::DebugSession::handle_request
12: codelldb::debug_session::DebugSession::handle_message
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
[2020-01-06T04:38:28Z DEBUG codelldb::debug_session] ### DebugSession::drop()
[2020-01-06T04:38:28Z DEBUG codelldb] ### session_to_client stream terminated
[2020-01-06T04:38:28Z INFO  codelldb] ### server resolved: Ok(())
[2020-01-06T04:38:28Z DEBUG codelldb::wire_protocol] --> {"command":"stackTrace","arguments":{"threadId":401733,"startFrame":1,"levels":19},"type":"request","seq":25}

Does this still happen?


Allow to develop on any Chromium-based Browser

Discussed in https://github.com/cezaraugusto/extension.js/discussions/56

Originally posted by jolo-dev May 11, 2024
To my shame, I don't use Chrome but another Chromium-based browser (Arc or Brave). Is there a possibility to use them instead?
If not, how about making the --browser more generic and pointing to the path of the browser?

For this to be done, we need a generalist Chromium plugin. Once webpack-run-chrome-extension is more mature, it can be forked and have the browser path as a parameter in the plugin class.
We should support all major browsers (defined in README.md) and allow support for custom paths for the --browser flag, for unsupported browsers.


ssh, option to pycopy

This PR has two things:

ability to build not only vanilla micropython, but also pycopy fork,
ability to flash esp32 via ssh jumpstation, configure it to webrepl over wifi network, etc...

Hi @maho!
Thank you for your contribution!
It may, however, be a while before I'm able to find the time to review this, so I apologize in advance.

No problem. I admit that it's substantial piece of new functionality, so I was considering starting just new project.
However, I think my changes to firmware building, and ability to choose micropython or pycopy a worth of keeping in your project and it would be bad to keep it in fork rather than in your base.

@maho, I'm sorry to let this languish and am happy to see that you've continued your development in https://github.com/maho/yampid
Given the existence of YAMPiD, my lack of bandwidth, and a desire to constrain features to what I personally require, I'm going to close this. I'm glad that you were able to find utility in this project and thank you again for your contribution.


config.py

Can you provide the config.py file? @ranandalon. thank you!

Yes, I would also need it. Thanks!

Do you have config.py now? Thank you! @CF2220160244  @steve3nto

I don't understand how this repo is posted without the config.py file..

Can you provide the config.py file? @ranandalon. thank you!

Do you have config.py now? Thank you!


✅ Verify Binary Checksum

Description:
the current approach fails for binaries that have interrupted downloads
or at least file sizes

done


[VS Code] Starting collaboration session: Invalid root scheme: vsls, expected 'file'

Error:
Starting collaboration session: Invalid root scheme: vsls, expected 'file'
Steps to Reproduce:

Version Data

extensionName
VSLS

extensionVersion
0.3.1182

protocolVersion
2.2

applicationName
VSCode

applicationVersion
1.30.1

platformName
MacOS

platformVersion
18.2.0

@refo  Closing as duplicate of #1672 .  Let's continue the conversation there. Can you provide some more information about your scenario? Was this blocking you from starting a collaboration session?


Why not newer than CUDA 10.0?

Why should i not install CUDA newer than v10.0? 10.0 does not support newer versions of VS 2019.
A newer version of CUDA 10 says it does support VS 2019, see: https://docs.nvidia.com/cuda/archive/10.2/cuda-installation-guide-microsoft-windows/index.html.
And even newer, CUDA 11.2.1 does also say it supports VS, see: https://docs.nvidia.com/cuda/archive/11.2.1/cuda-installation-guide-microsoft-windows/index.html
What is the reason this page explicit says that i should not install anything that Nvidia says is supported by newer versions of VS?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0495cff9-97a6-68ba-504c-ec7fcbc69a9c
Version Independent ID: 0c7c0298-37e3-f945-fee5-fc6ccd7a362d
Content: How to install GPU support in Model Builder - ML.NET
Content Source: docs/machine-learning/how-to-guides/install-gpu-model-builder.md
Product: dotnet-ml
GitHub Login: @luisquintanilla
Microsoft Alias: luquinta

Hi @zsleepy
Thanks for your question. I've posted an issue in the ML.NET repo since this is not a documentation issue dotnet/machinelearning#5726
Closing this issue for now. Please follow the discussion on there.


Refactor SQLite usage

Refactor to avoid corruption in the database

I'm not sure what we're thinking for this issue. Some ideas:

Audit our code for corruption. This probably means reading through "How To Corrupt An SQLite Database File" and making sure we aren't doing any of these things.

Audit for proper transaction usage. We may not be running operations in transactions correctly.

Audit for connection cleanups. We might not be closing the database if there are errors. For example, this could be problematic:
const db = new Database(filePath)
somethingThatMightThrow()
db.close()

Something like this is better:
const db = new Database(filePath)
try {
  somethingThatMightThrow()
} finally {
  db.close()
}

I fixed at least one of these problems in #113, but there may be others. I don't expect this to cause corruption, but maybe?

Change database setup options. Some ideas:

Enable foreign keys, not enabled by default.
Set the synchronous option to something a little safer, like "FULL". I don't think this is necessary because we use WAL mode, and it's slower.
Set the fullfsync or checkpoint_fullfsync options for better reliability at the cost of performance. In my experience, checkpoint_fullfsync is worth it but fullfsync is not (it is significantly slower).

Periodic optimizations. I don't think any of these affect corruption. Some ideas:

Enable auto-vacuum.
Run PRAGMA optimize periodically, perhaps when closing the database.
Run PRAGMA shrink_memory periodically, perhaps at moments of downtime.

Improve the experience when the database gets corrupted. We want to avoid this, but we can do some things if this happens:

Run and log PRAGMA integrity_check (or quick_check) to diagnose problems.
Build a dump-and-recover system.

Have a single worker responsible for SQLite interactions. I know we've discussed having a single "choke point" for the database. Admittedly, I don't understand the value of this as it relates to corruption, as SQLite typically[^0] allows multiple connections just fine. Maybe there's a deadlock bug we're worried about, or something else I don't understand.

Which of these things make sense to do as part of this issue? (Are there things I didn't list that we should do?)
[^0]: It wouldn't if we set the locking_mode to EXCLUSIVE, but I don't think we do that.

I think this issue came from a concern that writing to the same SQLite file from two separate threads could lead to corruption, because of conflicting information I have seen around the interwebs about multi-threaded write support in SQLite.
Because we perform the large imports in a separate thread, which take some time (e.g. 500Mb+ mbtiles files), it's quite likely that a write could occur in the main thread while that is happening. I'm just not sure how SQLite handles that, specifically the build of SQLite that we are using with better-sqlite3. It may be just a case of making sure we correctly handle SQLITE_BUSY errors, and the risk is not corruption after all. I found this reference on StackOverflow: https://stackoverflow.com/questions/1680249/how-to-use-sqlite-in-a-multi-threaded-application. I can't find the reference I originally read about not writing to SQLite from two separate threads, so maybe that is not an issue? If we need to, then we can move all SQLite operations to a single thread - this would be relatively simple to do in Drizzle with a custom proxy driver. But maybe I am over-complicating this, and the way we use SQLite currently is just fine.

SQLite can be safely used across multiple processes.
The story is more complicated when using multiple threads, like in our case. SQLite has three threading modes, and only one of them is fully safe for multi-threaded access.
Unfortunately, this safe option is not the default option in better-sqlite-3.[^issue]
I think our options are as follows, assuming the consumer of this module passes in a database instance:

Document that whoever creates the database should change to the thread-safe mode, which isn't the default in better-sqlite3.
That punts this problem to the consumer of this module (CoMapeo? mapeo-core-next?), and probably requires making a custom SQLite build or forking better-sqlite3.

better-sqlite3 uses a semi-safe threading mode. It allows multi-threaded database access as long as it isn't concurrent. We could build our own database locking system.
Like the above, this probably needs some coordination with the consumers of this module. You could imagine the worker thread locking the map server's database connection but not CoMapeo's, which would cause problems.

Stop using a worker thread and start using a completely separate process, letting us rely on SQLite's file locking mechanisms. This is probably slower and a little more complex, but should be safer.

Move all database access to a single thread. This would likely block the database for a long time, but maybe there's something we can do to speed this up.

Something else I'm not thinking of!

I don't think moving this repo's connection to a worker thread will help because it has the same problem: multi-threaded database access. It might not be multi-threaded in this repo, but any consumer will need to be super careful.
We could simplify these problems by letting the map server manage its own database file, which would make a lot of this stuff simpler. In that world, all of these options are much easier because we don't have to worry about the consumer's use of SQLite.
If we keep the API such that the consumer provides the database, then I think option 3 is my favorite. If we let this module manage its own database, I think option 1 is my favorite (compile SQLite in thread-safe mode).
[^issue]: This might be intentional but it seems wrong to me; I've opened an issue.

@EvanHahn Couple of thoughts based on your proposals:

We could simplify these problems by letting the map server manage its own database file, which would make a lot of this stuff simpler. In that world, all of these options are much easier because we don't have to worry about the consumer's use of SQLite.

I think this makes sense to do in general. Looking back on it, there hasn't been any noticeable benefit to having the consumer create the database. Let's say we do this, regardless of the options you listed to address concurrent write issues:

I want to note that for the mobile app, we have to create native builds of better-sqlite3 in order for it to work on Android (see https://github.com/digidem/better-sqlite3-nodejs-mobile). not sure how that plays into your proposals (most likely relevant for (1)) - maybe it's a non-issue but wanted to highlight

re: (3), what's the difference between using a separate process vs a worker thread? (keeping in mind that these would be the only contexts managing the db connection)

I think this makes sense to do in general. Looking back on it, there hasn't been any noticeable benefit to having the consumer create the database. Let's say we do this [...]

Done in #119.

I want to note that for the mobile app, we have to create native builds of better-sqlite3 in order for it to work on Android (see https://github.com/digidem/better-sqlite3-nodejs-mobile). not sure how that plays into your proposals (most likely relevant for (1)) - maybe it's a non-issue but wanted to highlight

I glanced at this and I don't think it's an issue, but good to call out—I wasn't sure things were okay there.

re: (3), what's the difference between using a separate process vs a worker thread? (under the assumption that whichever is chosen is the sole manager of the db connection)

A lot of my comment was wrong (see https://github.com/WiseLibs/better-sqlite3/issues/1138#issuecomment-1934353076). There's no safety difference between a separate process and a worker thread, unless we deliberately change SQLite's multi-threading mode (I see no reason to do this).

Once #119 merges, I don't think there's anything else we need to do here. We may want to file a new issue about SQLITE_BUSY errors, but that's separate and unrelated to corruption.
I'm going to close this issue, but let me know if that's wrong and I'll reopen!


[Workshop Admin/ Deputy] - personal cabinet functionality #1173

[Workshop Admin/ Deputy] - personal cabinet functionality #1173

Заступник директора cannot block/delete other deputies, admins. The header of the table was deleted but actions still exist

Deputy should not be able to create new deputy, admins, so this button should be hidden

There should be filtration for the workshop. Admin can delete, and edit only workshops he/she is assigned to. ALso can manage application only to his/her workshops

Confirm with BA should admin see all other workshops/application (without actions, only view);
maybe for correct workshop filtering help from backend is needed


feat: bump Ruby version to 2.7

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I see several green ci/circleci builds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)
[x] I've read the Contribution Guidelines
[ ] I've updated the documentation if necessary.
[ ] I've added or updated relevant unit tests.

Motivation and Context
Tried to allow faraday v2, but it requires to bump Danger to 9.2, and Danger 9.2 requires Ruby 2.7

Description
Dear reviewer, all hard work related to the Ruby version change is done in https://github.com/fastlane/fastlane/pull/22272/commits/b16d8423bb3df604f02fba10d11d07b83bbe1abf. And rubocop fixes are done in this commit: https://github.com/fastlane/fastlane/pull/22272/commits/265e2f44e0f8e6415b344afcb9512564502a56b8.

Updated gemspec.
Removed fakefs version limit, since the limit is no longer required.
Removed unnecessary code from ErbalT.render.
Updated CI: CircleCI and AppVeyor.
Fixed linting problems with rubocop -A here -> https://github.com/fastlane/fastlane/pull/22272/commits/265e2f44e0f8e6415b344afcb9512564502a56b8.

Testing Steps
In CI I trust 😅.

I prepared #21685 earlier. Anything we should recover from that work?

I prepared #21685 earlier. Anything we should recover from that work?

@lacostej
I think it's better to use Visual Studio 2022 instead of 2019 on AppVeyor, in case they will skip some ruby versions on 2019.
And delete unnecessary code in fastlane/lib/fastlane/erb_template_helper.rb render. See 27-33 lines.
And do you have any plans to merge your PR in the nearest future?

| And do you have any plans to merge your PR in the nearest future? Your PR is 10 months old 😅.
Well my understanding back then that we didn't want to drop ruby 2.6 until MacOS dropped ruby 2.6 or that the number of users using it was going down sufficiently. I made some heuristics to try to guess the %age of users. See the PR.
I was waiting for some feedback from other committers. Has anyone commented on this topic?
Also, I was hoping that @joshdholtz or someone else would release #fastlane/docker#8, but that's not blocking.
I'll look at your PR in the coming days.

I just checked the percentage of tickets reported using ruby 2.6 and it is now below 4% (for tickets since March).

Closing since there is a similar PR: https://github.com/fastlane/fastlane/pull/21685


Question about error "mmco: unref short failure" in finetune stage.

Thanks for tharing this great work.
When I finetuning the model from the pretrained weights, I keep getting the error message:
[h264 @ 0x7d53ee00] mmco: unref short failure
Despite the error message, the training continued and the loss kept dropping.
After searching through the web, I found that this error may introduced by "decord" (https://github.com/dmlc/decord/issues/177) . I wonder if you encountered this problem before?

Got it. Thanks for the quick reply! 😃


Edge not closed after tests running with gitlab-runner

What is your Test Scenario?

Running test with Gitlab-runner using the shell executor.
What is the Current behavior?

When the tests are finished Edge doesn't close, only testcafe with a disonnected status is shown in the browser.
What is the Expected behavior?

The browser shall close when the tests are finished.
What is your web application and your TestCafe test code?

Your website URL (or attach your complete example):
x

Your complete test code (or attach your test files):

 import { config } from "../../../testEnvironment/config";
import { logger } from "../../hosting/logger";
import { initialize } from "../../../helpers/initialize";
import { Selector } from "testcafe";

fixture(`Project`)
  .page(config.httpsUrl_DevEnv)
  .requestHooks(logger.simpleLogger)
  .beforeEach(async () => {
    // await initialize(logger.simpleLogger);
  });

test.only("First automation test", async t => {
  await t.click(Selector("input[type=checkbox]")).click(Selector("button"));
});

Your complete configuration file (if any):

.testcaferc.json

{
  "browsers": ["edge", "chrome", "firefox"],
  "debugMode": false,
  "debugOnFail": false,
  "developmentMode": false,
  "hostname": "localhost",
  "port1": "5050",
  "port2": "5051",
  "screenshotPath": "/reports/screenshots",
  "takeScreenshotsOnFails": true,
  "reporter": "list",
  "selectorTimeout": 40000,
  "src": ["src/ui/project/*.test.ts", "src/ui/devices/*.test.ts"],
  "quarantineMode": false
}

.gitlab-ci.yml

stages:
  - test
Build_test:
  stage: test
  script:
    - npm ci
    - npm test

Your complete test report:
x

```
</details>

<details>
<summary>Screenshots:</summary>
<!-- If applicable, add screenshots to help explain the issue. -->

![edge_disconnected](https://user-images.githubusercontent.com/29160941/61870810-56e06f80-aedf-11e9-84ea-fade28bfc958.PNG)

</details>

### Steps to Reproduce:
<!-- Describe what we should do to reproduce the behavior you encountered. -->

1. Go to my website ...
3. Execute this command...
4. See the error...

### Your Environment details:

* testcafe version:  v1.3.3                 <!-- run `testcafe -v` -->
* node.js version:   v10.15.3                 <!-- run `node -v` -->
* browser name and version: Edge 17.17134.0
* platform and version:  Windows 10.0.0
* other:    Gitlab-runner v12.1.0                               <!-- any notes you consider important -->

If you use gitlab-runner start command to start your GitLab agent, it will be started as a service. There are some restrictions for running GUI apps as a service: https://gitlab.com/gitlab-org/gitlab-runner/issues/1046. Please, try to disable and stop the GitLab service and start your GitLab agent in the current user session by running gitlab-runner run in the command prompt.

If you use the gitlab-runner start command to start your GitLab agent, it will be started as a service. There are some restrictions for running GUI apps from a service: https://gitlab.com/gitlab-org/gitlab-runner/issues/1046. Please try to disable and stop the GitLab service and start your GitLab agent in the current user session by executing gitlab-runner run in the command prompt.

@AndreyBelym  thanks for your quick feedback!
Yes, it worked now!
BR

Thank you for the update. I'm happy to hear that you have figured out how to resolve the issue.


Correct method of authenticating with refresh token only

I'm using v10.5.0 with Javascript.
I have a manual user workflow to generate and store a refresh token. I now want my JS client to use that same refresh token across all my users so they can all upload to the same dropbox account without any manual OAuth flow for them.
I checked the code and it seems that if I do pass a refresh token and I don't pass an access token then  checkAndRefreshAccessToken will determine that a refresh is required and call refreshAccessToken. I believe this is being called because I see this POST request in my network:
https://api.dropboxapi.com/oauth2/token?grant_type=refresh_token&refresh_token={myRefreshToken}&client_id={myClientId}
The result of this call is;
{"error_description": "No auth function available for given request", "error": "invalid_request"}
I did some testing with the HTTP call, and I found that I had to pass an Authorization header client_id/client_secret and I had to remove 'client_id' from the parameters. If I do this, then a new access token is returned.
Can you let me know what I am doing wrong? I have a refresh token, it should be enough to generate a short-lived access token, but I just can't work out how to get this library to do it.
Current constructor:
        let dbx = new Dropbox({
            clientId: data.dropbox.client_id,
            refreshToken: data.dropbox.refresh_token,
            fetch: isoFetch,
        });

Thanks in advance.

[Cross-linking for reference: https://www.dropboxforum.com/t5/Discuss-Dropbox-Developer-API/Refresh-token-using-dropbox-sdk-js-returns-400-error/td-p/538793 ]
This will actually depend on whether or not you used "PKCE" (set by the usePKCE option on , e.g., as shown in this example) when retrieving that refresh token.
If you used PKCE, you can supply just the client ID and refresh token like you're doing here.
If you didn't use PKCE, you would need to supply both the client ID and secret as well as the refresh token. Otherwise, you'll get an error like this.
I see you're not supplying the client secret, so it appears you did not use PKCE to get this refresh token. That being the case, you would need to either add the clientSecret parameter to your Dropbox constructor when using this refresh token, or get a new refresh token using PKCE.

Thanks for such a quick response Greg.
I've switched over to PKCE as recommended and I have the flow working successfully. I did have a couple of issues that maybe you can help with:

In the dropbox documentation (https://www.dropbox.com/developers/documentation/http/documentation) the PKCE curl example doesn't include the authentication header requirement. I was only able to get mine to work when I also pass the client id/secret header. Here is the docs example:

Example: PKCE code flow token request

curl https://api.dropbox.com/oauth2/token \
    -d code=<AUTHORIZATION_CODE> \
    -d grant_type=authorization_code \
    -d redirect_uri=<REDIRECT_URI> \
    -d code_verifier=<VERIFICATION_CODE> \
    -d client_id=<APP_KEY>

I was unable to get the sha256 to work. I passed the hashed code in the initial request and the unhashed code in the token request and received an invalid code verifier error. I independently verified that my PHP hashing algorithm was working. I noticed that the hashed string you generate in your JS client is different to the string I would generate as a result of a PHP hash. Here was how I generated my query param:

$queryString = $foo .

// Returns "invalid code verifier" error
// 'code_challenge=' . hash( 'sha256', self::CODE_VERIFIER ) . '&' .
// 'code_challenge_method=S256&' .

// Successful
'code_challenge=' . self::CODE_VERIFIER . '&' .
'code_challenge_method=plain';


Add additional transport icons

Following on from https://github.com/lucide-icons/lucide/pull/1412#pullrequestreview-1550057373

car-sports-front to represent racing/motorsport, or even a luxury car dealership on a map… Related to #1304.
coach-front to distinguish between coach and existing bus (the biggest difference being short vs long journey times on say a travel booking site…)
car-electric-front alternatives:

Also leaving bus-school-front here for reference…

tram/-front alts:

station-charge-electric alternative:

The zap is too small in these icons. On 100% scale you can barely see them.
Maybe an idea for the electric charging station is too use a plug instead on the end of the hose?
For example the plug from the cable icon?
Like this one:

@danielbayley What do you think of this charge station?

@danielbayley What do you think of this charge station?

@ericfennis Did you miss the draft at the bottom of this https://github.com/lucide-icons/lucide/pull/1460#issue-1824677065? 😅

@danielbayley I saw it. But it would be nice if we use the same plug icon as the cable icon. And the same pump case as fuel.

The zap is too small in these icons.

@ericfennis It’s no smaller than—and in fact uses exactly the same zap as—the existing plug-zap-2 icon. Again going for consistency… But one possibility would be to make car/taxi-front bigger to free up a bit more space…?

it would be nice if we use the same plug icon as the cable icon. And the same pump case as fuel.

Agreed. Looks like there is some wiggle room to the left of fuel to play with…

The z is too small IMO.


Centralize NPM Scripts

As a developer, I want to be able to run project NPM scripts, like install, start, and test; from the central package.json, instead of having to do it individually on each sub-project.
Example of linking install: Scott's answer - The best way to run npm install for nested folders? - Stack Overflow
You can run scripts in parallel with npm-run-all or Concurrently.

Close as done.
npm-run-all was chosen.


request help: upgrade apisix, error: stream mode is disabled, can not add any stream routes

Issue description
i upgrade apisix by helm ,this is the upgrade cmd:
helm upgrade apisix apisix/apisix --set gateway.type=LoadBalancer --set admin.allow.ipList="{<IP_ADDRESS>/0}" --set etcd.persistence.storageClass="cbs" --set etcd.persistence.size="20Gi"    --namespace ingress-apisix --version 0.11.3
however,after i upgrade the apisix, the apisx pod 和apisix-ingress-controller pod print the flowing error message:
apisx pod error message:
apisix-admin:9180 "GET /apisix/admin/stream_routes HTTP/1.1" 400 78 0.000 "-" "Go-http-client/1.1" - - - "http://apisix-admin:9180"
2023/04/19 07:59:25 [warn] 49#49: *893808 [lua] init.lua:164: handler(): stream mode is disabled, can not add any stream routes, client: <IP_ADDRESS>, server: , request: "GET /apisix/admin/stream_routes HTTP/1.1", host: "apisix-admin.ingress-apisix.svc.cluster.local:9180"
2023/04/19 07:59:25 [warn] 49#49: *893808 [lua] init.lua:164: handler(): stream mode is disabled, can not add any stream routes, client: <IP_ADDRESS>, server: , request: "GET /apisix/admin/stream_routes HTTP/1.1", host: "apisix-admin.ingress-apisix.svc.cluster.local:9180"
apisix-ingress-controller pod  error message:
2023-04-19T16:03:18+08:00	error	apisix/cluster.go:212	failed to list routes in APISIX: Get "http://apisix-admin.ingress-apisix.svc.cluster.local:9180/apisix/admin/routes": context canceled
2023-04-19T16:03:18+08:00	error	apisix/cluster.go:172	failed to sync cache	{"cost_time": "59.823µs", "cluster": "default"}
2023-04-19T16:03:18+08:00	info	ingress/controller.go:380	controller now is running as a candidate	{"namespace": "ingress-apisix", "pod": "apisix-ingress-controller-66fcc99f89-vnqdw"}
I0419 16:03:18.905856       1 leaderelection.go:248] attempting to acquire leader lease ingress-apisix/ingress-apisix-leader...
2023-04-19T16:03:18+08:00	info	ingress/controller.go:328	LeaderElection	{"message": "apisix-ingress-controller-66fcc99f89-vnqdw became leader", "event_type": "Normal"}
I0419 16:03:18.912413       1 leaderelection.go:258] successfully acquired lease ingress-apisix/ingress-apisix-leader
2023-04-19T16:03:18+08:00	info	ingress/controller.go:413	controller tries to leading ...	{"namespace": "ingress-apisix", "pod": "apisix-ingress-controller-66fcc99f89-vnqdw"}
2023-04-19T16:03:18+08:00	info	apisix/stream_route.go:39	resource stream_routes is disabled
2023-04-19T16:03:18+08:00	warn	apisix/cluster.go:334	waiting cluster default to ready, it may takes a while
2023-04-19T16:03:18+08:00	info	apisix/cluster.go:374	syncing schema	{"cluster": "default"}
2023-04-19T16:03:18+08:00	info	apisix/cluster.go:162	syncing cache	{"cluster": "default"}
2023-04-19T16:03:18+08:00	error	apisix/route.go:119	failed to list routes: unexpected status code 404; error message: {"message":"Key not found"}
2023-04-19T16:03:18+08:00	error	apisix/cluster.go:212	failed to list routes in APISIX: unexpected status code 404; error message: {"message":"Key not found"}
2023-04-19T16:03:19+08:00	info	gin@v1.8.1/context.go:173	path: /healthz, status: 200, method: GET, query: , ip: <IP_ADDRESS>, user-agent: kube-probe/1.18+, errors: , cost: 36.458µs
2023-04-19T16:03:20+08:00	error	apisix/route.go:119	failed to list routes: unexpected status code 404; error message: {"message":"Key not found"}
2023-04-19T16:03:20+08:00	error	apisix/cluster.go:212	failed to list routes in APISIX: unexpected status code 404; error message: {"message":"Key not found"}
2023-04-19T16:03:22+08:00	error	apisix/route.go:119	failed to list routes: unexpected status code 404; error message: {"message":"Key not found"}
2023-04-19T16:03:22+08:00	error	apisix/cluster.go:212	failed to list routes in APISIX: unexpected status code 404; error message: {"message":"Key not found"}
2023-04-19T16:03:24+08:00	error	apisix/route.go:119	failed to list routes: unexpected status code 404; error message: {"message":"Key not found"}
2023-04-19T16:03:24+08:00	error	apisix/cluster.go:212	failed to list routes in APISIX: unexpected status code 404; error message: {"message":"Key not found"}
i search the  github issue to help, and try to use
--set ingress-controller.enabled=true --set dashboard.enabled=true  to upgrade apisix again
but  upgrade failed,here is the error message:
Error: UPGRADE FAILED: rendered manifests contain a resource that already exists. Unable to continue with update: ServiceAccount "apisix-dashboard" in namespace "ingress-apisix" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "apisix": current value is "apisix-dashboard"
hope get help,thanks
Environment
apisix version: （tag）：2.15.1-debian
apisix-ingress-controller version:  1.0.0

what do you mean? Do you know help to solve the problems? I am freshman for the apisix user, Really
Hope your reply and help  ,Thanks very much !

@orangezhang123 you can pass the --set gateway.stream.enabled=true flag when installing apisix ingress with helm.

ok ,i will try this ,thanks


1.12.2 compatibility and errors

Last version of bukkit "PermissionsEx v1.23.4" causes problems with other plugins and does not let users enter, expelling them after the attempt to enter and the latest version https://ci.yawk.at/view/PermissionsEx/job/PermissionsEx gives this error in console.
https://hastebin.com/pokudimano.vbs
Server version 1.12.2
All the best.

I have been running PermissionsEx v1.23.4 for a few years and I upgraded to the latest bukkit version as they were released, I'm currently running 1.12.2 and don't have any issues with PEX. Maybe its the other plugin or PEX not being setup right.


Navbar shriking hides navbar options

Navbar shrinking currently hides tabs such as "Create" before switching to mobile version. @cryptodamsky just tried presenting from 13 inch macbook and couldn't click on "Create" because it wasn't there.

👋

It works for me and shows most of items in nav-bar from my 13-inch macbook.
Maybe he could try to adjust the browser's zoom settings? My zoom level is 100%. @petersopko

It works for me and shows most of items in nav-bar from my 13-inch macbook.
The items on the nav-bar are responsive.
Maybe he could try to adjust the browser's zoom settings? My zoom level is 100%. @petersopko

Hmm, now is see that I've operated on 75% zoom, however, I still think it is kind of unfortunate to make half of the navbar not accessible if you zoom in. It's not that it was zoomed out of the screen, the button for "Create" is getting hidden and there's no option to click it (when zoomed in guess).

yes, maybe need to think about how to deal with these hidden buttons, though it related to #2760

👋

👋

👋


fix: vulnerable package (high) Regular Expression Denial of Service

High vulnerability detected in webpack-bugsnag-plugins with this path:
webpack-bugsnag-plugins > bugsnag-build-reporter > meow > trim-newlines
The offending package is trim-newlines, which is fixed in >=4.0.1. You can see the advisory here:

https://www.npmjs.com/advisories/1753

Bumping meow resolves the issue. I have not tested this change

Hi @dannyrb, thanks for the PR - this issue was raised in #14 and we already have work in progress to address this in an upcoming release. Bumping the meow version means we have to drop support for Node 6 which will mean a new major release.


no firebase config file in repo

Hi - I'm unable to run this project locally as there is no firebase config file found here: https://github.com/zoom/zoomapps-serverless-vuejs/blob/main/firebase.config.js.
Can someone please add this file or a sample file to the repo?

I am also having the same issue and wondered if you had resolved it!

Has anyone figured thisout?


bwa failed: -1 issue

Hi, I got an issue when using proovread after Seqchunker.
[Tue Sep  3 04:58:18 2019] Running mode: mr
[Tue Sep  3 04:58:18 2019] Preparing long reads
ls #------------------------------------------------------------------------------#
perl -I/data/download/correction/proovread/proovread/bin/../lib/ /data/download/correction/proovread/proovread/bin/SeqFilter --fasta --in 20190226/r\
ead-long/20190226.fq --line-width 80 --lower-case --out 20190226/read-long/2019\
0226.masked.fa --phred-offset 33
#------------------------------------------------------------------------------#
[Tue Sep  3 05:45:42 2019] Read IDs don't look like proper PacBio subread IDs.
Falling back to running mode: mr-noccs

[Tue Sep  3 05:47:46 2019] Running task bwa-mr-1
[Tue Sep  3 05:50:41 2019] Indexing Long reads
#------------------------------------------------------------------------------#
/data2/jji/download/correction/proovread/proovread/bin/../util/bwa/bwa-proovrea\
d index 20190226/read-long/20190226.masked.fa 20190226/read-long/20190226.maske\
d.fa 2>20190226/bwa-mr-1/20190226_bwa.log
#------------------------------------------------------------------------------#
Can't open 20190226/bwa-mr-1/20190226_bwa.log: No such file or directory at /data/download/correction/proovread/proovread/bin/proovread line 1277.
#------------------------------------------------------------------------------#
  bwa failed: -1

        Exited at 'main'
        '/data/download/correction/proovread/proovread/bin/proovread', line 1277
        Last call 'main::run_bwa'
        '/data/download/correction/proovread/proovread/bin/proovread', line 853

The command I used is /data/download/correction/proovread/proovread/bin/proovread -l /data/compare/chunk_LR.fq -s /data/Nanopore_WGS/0_RawData/20190116/PM-AU-0011-T-A1/PM-AU-0011-T-A1_merged_piped_hg38.sortfix_mrkdup.BQSR.chr21-22.merged.fastq --pre /data/compare/PM-AU

I have produced several outputs perfectly fine before using these inputs, but it doesn't work all of a sudden with showing this error.
I checked the inputs again, but I don't see any problems.
Thanks

Odd. This also doesn't look like an issue with the data or even proovread. Things fail at the very basic step of trying to open a file using a shell command. Basically this doesn't seem to work
echo "blabla" 2>20190226/bwa-mr-1/20190226_bwa.log
# Can't open 20190226/bwa-mr-1/20190226_bwa.log...

This seems to indicate some issues with you system. Are you on cluster? Did you run into a file quota maybe?


Logarithmic volume increments?

Just throwing it out there.. for those of us with external speakers set to near-max.. the first few increases have a more drastic change if you're casually working or listening to music, then if you're partying and you want to go from loud to louder :)
Would logarithmic increments be something supported? I guess it would require 3rvx to know what the current volume is.. then it can increase it by smaller amounts if it's low, and get increasingly larger increments as the volume is jacked.
Stackoverflow has some algorithms for implementing it :
http://stackoverflow.com/questions/1165026/what-algorithms-could-i-use-for-audio-volume-level

Hmm, that's a great idea, and probably should've been an option from the start. I'll do some experimenting and hopefully I can get this put into the next beta!

:+1: I was about to suggest the same!

I've just about got something ready for this, where the curve can be configured as well to make it more or less sensitive. Hopefully will have an update ready in the next few days!

Is there a build ready for testing?

I'll try to get something put together in the next couple days!

(I see that's what I said before -- but now I REALLY mean it... ;-))

Ok, I haven't finished reworking the settings app to support this yet (I'm in the process of adding an OSD settings tab where this will be), but I thought I'd push out a prerelease for testing the volume curve modification: http://3rvx.com/releases/3RVX-2.9.2-pre2.zip
If you replace the executables in your current install with these, you will also need to replace the "Classic" skin (it has been updated with Brightness images).
To activate the curve adjustment, you'll need to modify your Settings.xml (%APPDATA%\3RVX\Settings.xml if you're using an installer version) and add a curveAdjust tag like:
<curveAdjust>3</curveAdjust>

The number provided to curveAdjust represents the "strength" of the curve modification. Here's what the curves look like on my system (I believe these could vary based on hardware (?)):

Where 0 is the original unmodified curve, 4 gives a roughly linear increase in output dB. Beyond that, things start to get a little extreme on the loud end. In the next few days I'll also finish adding support for a volume limiter, which would put an upper bound on the high end of the curve (while still applying the desired curve adjustment)
For the UI of the settings app, I was planning on adding a simple dropdown for this with some predefined values (maybe 1 through 10). Let me know if you think there's a better way to adjust this/convey it to the user.

Oh man, it's heaven! It works really well at high volumes! It does scale
quickly at the high end, but 99% of the time I am listening at the low end.
Can you use either % or volume units and they are both affected by the
curve?
For the configuration, what about :
[checkbox] Enable Logarithmic Volume
[dropdown] Log strength (or correction?)
Low
Medium
High
Custom
Greg
On 22 October 2015 at 16:12, matthew<EMAIL_ADDRESS>wrote:

Ok, I haven't finished reworking the settings app to support this yet (I'm
in the process of adding an OSD settings tab where this will be), but I
thought I'd push out a prerelease for testing the volume curve
modification: http://3rvx.com/releases/3RVX-2.9.2-pre2.zip
If you replace the executables in your current install with these, you
will also need to replace the "Classic" skin (it has been updated with
Brightness images).
To activate the curve adjustment, you'll need to modify your Settings.xml
(%APPDATA%\3RVX\Settings.xml if you're using an installer version) and add
a curveAdjust tag like:
3
The number provided to curveAdjust represents the "strength" of the curve
modification. Here's what the curves look like on my system (I believe
these could vary based on hardware (?)):
[image: curve]
https://cloud.githubusercontent.com/assets/2635718/10676891/56ca5a22-78c6-11e5-83e7-1cc553029670.png
Where 0 is the original unmodified curve, 4 gives a roughly linear
increase in output dB. Beyond that, things start to get a little extreme on
the loud end. In the next few days I'll also finish adding support for a
volume limiter, which would put an upper bound on the high end of the curve
(while still applying the desired curve adjustment)
For the UI of the settings app, I was planning on adding a simple dropdown
for this with some predefined values (maybe 1 through 10). Let me know if
you think there's a better way to adjust this/convey it to the user.
—
Reply to this email directly or view it on GitHub
https://github.com/malensek/3RVX/issues/32#issuecomment-150343313.

That sounds good to me. I'm working on getting the UI updated for this... What levels do you think should correspond to low, medium, and high?
For the % and units, both are affected. It would be possible to add an option to override it in the hotkey setup, though...

@malensek these are my results with test version:
0 | 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52
  | 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100
--+-----------------------------------------------------------------------------
1 | 0 3 6 8 11 14 16 19 21 24 26 29 31 33 36 38 40 42 44 46 49 51 53 55 57 58 60
  | 62 64 66 68 70 71 73 75 77 78 80 82 83 85 86 88 90 91 93 94 96 97 99 100
--+-----------------------------------------------------------------------------
2 | 0 4 8 12 16 19 22 25 28 31 34 37 39 42 44 46 49 51 53 55 57 59 61 63 64 66
  | 68 69 71 73 74 76 77 79 80 82 83 84 86 87 88 90 91 92 93 94 96 97 98 99 100
--+-----------------------------------------------------------------------------
3 | 0 6 12 17 21 26 29 33 36 39 42 45 47 50 52 54 57 59 61 62 64 66 68 69 71 72
  | 74 75 77 78 79 81 82 83 84 85 86 88 89 90 91 92 93 94 95 96 97 98 99 100
--+-----------------------------------------------------------------------------
4 | 0 9 17 23 28 33 37 41 44 47 50 53 55 57 59 61 63 65 67 69 70 72 73 75 76 77
  | 78 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
--+-----------------------------------------------------------------------------
5 | 0 14 23 30 36 41 45 48 52 54 57 59 62 64 66 67 69 71 72 74 75 76 77 79 80 81
  | 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
--+-----------------------------------------------------------------------------
6 | 0 20 30 38 43 48 52 55 58 60 63 65 67 69 70 72 73 75 76 77 79 80 81 82 83 84
  | 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
--+-----------------------------------------------------------------------------
7 | 0 26 37 44 50 54 57 60 63 65 67 69 71 73 74 76 77 78 79 80 81 82 83 84 85 86
  | 87 88 89 90 91 92 93 94 95 96 97 98 99 100
--+-----------------------------------------------------------------------------
8 | 0 33 44 50 55 59 62 65 67 69 71 73 74 76 77 78 80 81 82 83 84 85 86 87 88 89
  | 90 91 92 93 94 95 96 97 98 99 100

This appears to give less control on the lower range, which is the exact
opposite of what I want. I want smaller increments on the soft range and larger
increments on the loud range.

That doesn't seem to be acting right. Are these values reported by the windows mixer? Also, what skin/hotkey/etc are you using so I can try to reproduce this behavior? Thanks!

Are these values reported by the windows mixer?

Yes

Also, what skin/hotkey/etc are you using

Vista Glass / Volume +

@malensek any comment?

Hey Steven, I think I have this solved, but it will take fixing another bug to fully fix the problem. Sorry for the long wait! I've been traveling, so don't always have a great internet connection. I need to go through a few commits that should have this working as expected. Thanks!


How can i extract a paragraph and all associated sentences in document

How can i extract a paragraph and all associated sentences in document
Basically i need paragraphs with associated sentences @lukehsiao  @SenWu  @vincentschen @ZZWENG @stephenbach
Appreciate your help

It's not clear to me exactly what you're trying to accomplish, and whether it makes sense to use Fonduer. Fonduer helps extract pre-determined relationships from richly-formatted documents. If you just want the document contents, you might be able to use something simpler, like Poppler's pdftotext instead. Can you explain your use case in detail?


Outdated page

The service described on this page is outdated and the page is misleading.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 42fff764-77f2-2878-f27f-867c71d9a8fc
Version Independent ID: 669c3568-eedc-f959-01d6-fcde93b9daaa
Content: Configure app passwords for Azure AD Multi-Factor Authentication - Azure Active Directory
Content Source: articles/active-directory/authentication/howto-mfa-app-passwords.md
Service: active-directory
Sub-service: authentication
GitHub Login: @Justinha
Microsoft Alias: justinha

@jurissm
Thanks for your feedback! I have assigned this issue to the author who will investigate and update as appropriate.

App passwords are still a thing if you are not using Conditional Access and have apps that use legacy authentication. #please-close


Bug in error message creation

This (example and therefore absolute useless) program is saved as main.pony:
use "time"
use "promises"

actor Main
    new create(e: Env)=>
        let now = Time.now()
        let d = PosixDate(now._1, now._2)
        let p = Promise[None]
        p.next[None]({(x: None) => d.min})

Building the program I encounter this error msg:
woody@lappi:~$ ponyc
Building builtin -> /usr/lib/pony/0.28.0/packages/builtin
Building . -> /home/woody/sources/pony/tests/time
Building time -> /usr/lib/pony/0.28.0/packages/time
Building collections -> /usr/lib/pony/0.28.0/packages/collections
Building ponytest -> /usr/lib/pony/0.28.0/packages/ponytest
Building random -> /usr/lib/pony/0.28.0/packages/random
Building promises -> /usr/lib/pony/0.28.0/packages/promises
Error:
/usr/lib/pony/0.28.0/packages/time/posix_date.pony:17:3: this parameter must be sendable (iso, val or tag)
  new create(seconds: I64 = 0, nanoseconds: I64 = 0) =>
woody@lappi:~$

The error is of course not in the posix_date.pony  but main.pony, line 7 should be let d = recover val PosixDate(now._1, now._2) end
In this example the error is easy to find but in a huge project with 100 of PosixDate.create calls it will be a challenge.

The error message is completely broken and incorrect. We need to investigate and fix.


[BottomNavigation] not having the muiTheme as Context

Problem description
When using the BottomNavigation component within my MuiThemeProvider with the darkBaseTheme selected, the BottomNavigation remains in the lightBaseTheme.
The theme actually works just fine for the AppBar component.
So I used the React dev tools to see what's going on in the jsx, and compared it to the jsx on material-ui.com. It looks like the BottomNavigation is missing the muiTheme as Context.
Steps to reproduce
Use create-react-app for the boilerplate and run the following setup:
index.js
import React from 'react';
import ReactDOM from 'react-dom';

// Needed for onTouchTap
// http://stackoverflow.com/a/34015469/988941
import injectTapEventPlugin from 'react-tap-event-plugin';
injectTapEventPlugin();

// Layout
import App from './layouts/App';

// Styles
import './fonts.css';
import './index.css';

ReactDOM.render(
    <App />,
    document.getElementById('root')
);

App.js
import React, { Component } from 'react';
import { BrowserRouter } from 'react-router';

// Material UI
import MuiThemeProvider from 'material-ui/styles/MuiThemeProvider';
import getMuiTheme from 'material-ui/styles/getMuiTheme';
import darkBaseTheme from 'material-ui/styles/baseThemes/darkBaseTheme'
import { yellow500, deepPurpleA100, deepPurpleA200, deepPurpleA400 } from 'material-ui/styles/colors';

const muiTheme = getMuiTheme(Object.assign(darkBaseTheme, {
    palette: {
        primary1Color: '#303030',
        primary2Color: yellow500,
        accent1Color: deepPurpleA200,
        accent2Color: deepPurpleA400,
        accent3Color: deepPurpleA100,
        alternateTextColor: yellow500
    }
}));

import AppBar from 'material-ui/AppBar';
import Drawer from 'material-ui/Drawer';

// Custom Components
import NavigationBar from '../components/NavigationBar';

// Styles
import './App.css';

class App extends Component {
    constructor() {
        super();
        this.handleDrawerToggle = this.handleDrawerToggle.bind(this);

        this.state = {
            drawer: false
        };
    }

    handleDrawerToggle() {
        this.setState({
            drawer: !this.state.drawer
        });
    }

    render() {
        return (
            <BrowserRouter>
                <MuiThemeProvider muiTheme={muiTheme}>
                    <section className="app">
                        <AppBar title="StarWars Clicks" onLeftIconButtonTouchTap={this.handleDrawerToggle} />
                        <Drawer
                            docked={false}
                            open={this.state.drawer}
                            onRequestChange={(drawer) => this.setState({ drawer })}
                        >
                            {/* Drawer content */}
                        </Drawer>
                        <NavigationBar />
                    </section>
                </MuiThemeProvider>
            </BrowserRouter>
        );
    }
}

export default App;

NavigationBar.js
import React, {Component} from 'react';

// Material UI
import Paper from 'material-ui/Paper';
import {BottomNavigation, BottomNavigationItem} from 'material-ui/BottomNavigation';
import FontIcon from 'material-ui/FontIcon';

const scanIcon = <FontIcon className="material-icons">photo_camera</FontIcon>;
const collectionsIcon = <FontIcon className="material-icons">collections</FontIcon>;
const storeIcon = <FontIcon className="material-icons">store</FontIcon>;

import './NavigationBar.css';

class NavigationBar extends Component {
    constructor() {
        super();
        this.selectNavigationItem = this.selectNavigationItem.bind(this);

        this.state = {
            selectedIndex: 0
        };
    }

    selectNavigationItem(index) {
        this.setState({
            selectedIndex: index
        });
    }

    render() {
        return (
            <Paper className="navigation-bar" zDepth={1}>
                <BottomNavigation selectedIndex={this.state.selectedIndex}>
                    <BottomNavigationItem
                        label="Scan"
                        icon={scanIcon}
                        onTouchTap={() => this.selectNavigationItem(0)}
                    />
                    <BottomNavigationItem
                        label="Collections"
                        icon={collectionsIcon}
                        onTouchTap={() => this.selectNavigationItem(1)}
                    />
                    <BottomNavigationItem
                        label="Store"
                        icon={storeIcon}
                        onTouchTap={() => this.selectNavigationItem(2)}
                    />
                </BottomNavigation>
            </Paper>
        );
    }
}

export default NavigationBar;

Versions

Material-UI: ^0.16.0
React: ^15.3.2
Browser: Chrome 53.0.2785.143 (64-bit)

@HofmannZ: I'm not being able to reproduce your issue, can you please provide a bin or a repository with the minimal environment to test it?

Yeah sure, just made the repo, I'll switch it back once we resolved the issue. Just run npm install & npm start.

Hey @HofmannZ, thank you for sharing your code.
The problem is in here: https://github.com/HofmannZ/starwars-clicks-app/blob/master/src/layouts/App.js#L10.
Your Object.assign() is overwriting the darkBaseTheme pallete property.

Get the MUI theme corresponding to a base theme. It's possible to override the computed theme values by providing a second argument. The calculated theme will be deeply merged with the second argument.

Which would be like this:
const muiTheme = getMuiTheme(darkBaseTheme, {
	palette: {
		primary1Color: deepPurpleA100,
	},
});

And your screen would be very pretty:

Hope this helps you!

Thanks @lucasbento! I'm looking at the docs now, but could not find your reference right away. Maybe add a small example to the docs, instead of in a comment in a linked file? 🤔
Anyway thanks!

@HofmannZ: yeah, that would be a good addition, It would be nice if you could open a PR for it. 😉
I'm closing this since it's resolved.

Any way to customize directly the BottomNavigationItem with a style property on it?
MuiTheme settings seem to be ignored and no style property describing how to style the label is in docs :)
let theme = getMuiTheme({
	fontFamily: 'Verdana',
	snackbar: { actionColor: '#fff' },
	bottomNavigation: { backgroundColor: 'black' },
});
console.log(theme.bottomNavigation);


add resource instance v1alpha1 API types

Signed-off-by: Paolo Dettori<EMAIL_ADDRESS>
Description of your changes
Initial commit for IBM Cloud APIs

Fixes #
N/A
I have:

[ x] Read and followed Crossplane's contribution process.
[ x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
N/A

@pdettori just wanted to let you know that I have updated branch protection to:

require signed commits
require approval before merge
require status checks to pass

Let me know if you have any questions!


Update README.md

I think you want this to be the same as the below example.

Good catch. Thank you :smile_cat:


🐛 | Resume starts song at the beginning and only then jumps to current index

Hi all,
First of all thanks to all of you contributing to this project. I really enjoyed building the Phoniebox and my son loves it. The idea and its implementation is really great!
I have a minor problem which I would like to place here as a bug. I am happy to contribute as well if somehow possible.
Bug
Currently the resume functionality is a little broken. It first starts at the beginning of the title and only then jumps to the specific index. This is a really weired and unexpected behaviour. I understand that it was introduced to fix a bug which seems to be related to Spotify with PR #1149. In the description of the workaround the behaviour is even mentioned. On the one hand side I understand that a somehow working resume functionality is better then no resume at all. But for my purpose this workaround is making things worse. I tried reverting the change and the resume works perfectly fine (with just MP3 files). So I assume the workaround is only required for Spotify.
What I did
Installed 2.2 with oneline installer on Raspberry 3b (Hifiberry MiniAmp, OnOffShim, RC522, no GPIO buttons). Uploaded MP3 files and configured the folder to use resume functionality in the web ui.
What happened
Whenever I start a MP3 using a card which has resume enabled the first half second is played and only then the playback jumps to the correct sequence.
I expected this to happen
Immediately start at the correct index.
Further information that might help
Reenabling this line in the resume_play.sh makes everything behave fine again:
echo -e seek $PLAYLISTPOS $ELAPSED \\nclose | nc -w 1 localhost 6600
Software
Base image and version
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
Branch / Release
pi@raspberrypi:~/RPi-Jukebox-RFID $ git status | head -2
On branch master
Your branch is up to date with 'origin/master'.

Installscript
scripts/installscripts/buster-install-default.sh
Hardware
I don't assume any dependency of this issue to my hardware. Please let me know in case you need more details.

@albert0815, thanks for investigating this issue and finding the root cause.
@StefanMinke can you confirm that the fix #1149 was intended and works for Spotify?
if that’s the case we could try to handle Spotify and classic edition differently in resume_play.sh.

Martin, thats correct and works for me as indended.
But you are right, I havent tested the resume function with local files.
Maybe youre right an the seek command will work with local files, but not with spotify playlists.

Martin, thats correct and works for me as indended.
But you are right, I havent tested the resume function with local files.
Maybe youre right an the seek command will work with local files, but not with spotify playlists.

I can confirm that I am using classic edition without Spotify and seek command is working fine with local files.

I can confirm that I am using classic edition without Spotify and seek command is working fine with local files.

So is the difference local files vs. streams or is the difference classic edition (MPD) vs. Spotify edition (Mopidy)?

So is the difference local files vs. streams or is the difference classic edition (MPD) vs. Spotify edition (Mopidy)?

currently I cant check whether resuming local files in spotify edition works well with the seek command. I can try it in about 1 week and will report, if nobody else did before.

currently I cant check whether resuming local files in spotify edition works well with the seek command. I can try it in about 1 week and will report, if nobody else did before.

Hi.
Big SORRY for the very late response. :-/
Resuming local files with the seek command doesn't work either.
So the workaround is absolutely suitable for this version.
Whether this patch is also neccessary for the classic version has to be checked by someone who uses this version.

Hi, I experience this problem as well using the Spotify version while resuming Spotify or resuming a Webradio stream. Any plans to fix this bug?
Thanks to all contributors of this project :)

Hi,
I am currently testing to call mpc directly. This seems to have a significantly reduced delay so it is not hearable (for me) that the song is starting at the beginning and then skipping to the position.
mpc play expects song index to start at 1 and HH:MM:SS format for position though, therefore the two extra lines.
Let me know what you think. I could create a PR for this.
#echo -e "play $PLAYLISTPOS" | nc -w 1 localhost 6600
#echo -e seekcur $ELAPSED \\nclose | nc -w 1 localhost 6600
HHMMSS=$(date -d@$ELAPSED -u +%H:%M:%S)
PLAYLISTPOS=$((PLAYLISTPOS+1))
mpc play $PLAYLISTPOS
mpc seek $HHMMSS


applied change to DocumentManagerInterface

Applies the changes from https://github.com/sulu-io/sulu-document-manager/pull/6

@danrot I don't know how, but I think there was a git force push and subsequently 2 commits prior to this one were removed. Strangely I cannot find this commit in my git histrory now. Could you make another PR?

@dantleech done in #1196


f16 vector-times-matrix matmul codegen is slow

Testcase:
func.func @matmul_1x4096x4096_f16(%in: tensor<1x4096xf16>) -> tensor<1x4096xf16> {
  %weights = arith.constant dense_resource<__elided__> : tensor<4096x4096xf16>
  %out = arith.constant dense_resource<__elided__> : tensor<1x4096xf16>
  %result = linalg.matmul ins(%in, %weights: tensor<1x4096xf16>,tensor<4096x4096xf16>) outs(%out: tensor<1x4096xf16>) -> tensor<1x4096xf16>
  return %result: tensor<1x4096xf16>
}

This is extracted from https://github.com/nod-ai/SHARK/issues/1581 (@dan-garvey @powderluv) - this is the first matmul op in that model and it's representative of this whole model, a bunch of vector-times-matrix where all element types (including accumulator) are f16.
Compile:
tools/iree-compile $HOME/matmul_1x4096x4096_f16.mlir --iree-hal-target-backends=llvm-cpu --iree-llvmcpu-target-triple=x86_64-linux-gnu -o /tmp/matmul_1x4096x4096_f16.vmfb --iree-llvmcpu-target-cpu-features=host --iree-flow-enable-data-tiling --mlir-print-op-on-diagnostic=false --iree-util-zero-fill-elided-attrs --iree-llvmcpu-link-embedded=false --iree-llvmcpu-keep-linker-artifacts

Note: this is on a host supporting AVX2+FMA+F16C
Note: --iree-llvmcpu-link-embedded=false helps objdump understand the output.
Disassemble:
objdump -Mintel -d /tmp/matmul_1x4096x4096_f16_dispatch_0-3a6b7e.so

Disassembly pasted here:
https://gist.github.com/bjacob/5b6c0135dce336b32931408416781a5b
Number of instructions:
64 vmulps
64 vaddps
208 vcvtph2ps
128 vcvtps2ph
Apparent issues already from the number of instructions:

Excessive unrolling.
Too many f16<->f32 conversions.
Not taking advantage of FMA -- separate vmulps, vaddps instructions.

Data-tiling is not yet implemented for f16 but I will pursue that now. And then, a microkernel. Filing this issue to provide the ground motivation and in case someone wants to pick up work on the non-data-tiled path / non-ukernel path for this.

Cc @dcaballe
First thing we need to do is not unroll using LLVm

We have ukernels for f16f16f16 gemms/gemvs/gevms today, so we can close the issue?