docs: Updated API reference

:tada: This PR is included in version 10.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


New implementation test files: resolve linting issues discovered by pylint and mypy

I believe we should enable linting (tox -e lint) for new test files (maybe even for some recent additions).
The first step to do that would be to apply black and isort on the new test files testing the new code
which is documented in #1656.
The next step is to resolve the lining issues discovered by pylint and mypy.
Synchronize with https://github.com/theupdateframework/python-tuf/issues/1656 and https://github.com/theupdateframework/python-tuf/issues/1582

I will assign myself as have commits that I can use for pr resolving this issue.


Visible jitter when moving

Especially visible when moving sideways. Probably has something to do with the physics interpolation or camera movement

The issue is very likely due to physics interpolation. Or rather the fact that there's no physcis interpolation in Godot as of right now. So, the jitters can be fixed by installing the "Smoother" plugin from the Asset Store

Found a possible fix, will try to implement

Seems like it would be better to wait for the official implementation of 3D physics interpolation and use the "Smoother" add-on meanwhile.


Release with Panel support

Hi,
can you please tag a release with panel support (i.e. 6c438fe97a43e8989d18526cc7b71578f8565c78)
Thanks!

Done, dub should update shortly.


Could not initialize Python interpreter

Which OS: macOs Catalina (10.15)
Which VSCode version:  1.39.2
Which extension version: 1.4.0
Which adapter type: native
Which LLDB version: lldb-1<IP_ADDRESS>
Apple Swift version 5.1 (swiftlang-1100.0.270.13 clang-1<IP_ADDRESS>)
What is the problem:
I tried to debug a simple program in C with a couple of breakpoints. But when I run it I get this:

The log:
configuration: { type: 'lldb',   request: 'launch',   name: 'Debug',   program: '${workspaceFolder}/compiler',   args: [],   cwd: '${workspaceFolder}',   relativePathBase: '/Users/javier/Documents/Practica1/compiler' } liblldb: /Users/javier/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/lldb/lib/liblldb.9.0.0-custom.dylib libpython: null environment: {} params: {} [2019-10-23T12:41:10Z ERROR codelldb] load_python: Internal("\"dlopen(/Users/javier/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib, 257): Symbol not found: _PyBool_Type\\n  Referenced from: /Users/javier/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib\\n  Expected in: flat namespace\\n in /Users/javier/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib\"") Listening on port 52819 [2019-10-23T12:41:10Z DEBUG codelldb] New debug session [2019-10-23T12:41:10Z 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":"en-gb"},"type":"request","seq":1} [2019-10-23T12:41:10Z 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}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"command":"launch","arguments":{"type":"lldb","request":"launch","name":"Debug","program":"/Users/javier/Documents/Practica1/compiler/compiler","args":[],"cwd":"/Users/javier/Documents/Practica1/compiler","relativePathBase":"/Users/javier/Documents/Practica1/compiler","_adapterSettings":{"displayFormat":"auto","showDisassembly":"auto","dereferencePointers":true,"suppressMissingSourceFiles":true,"evaluationTimeout":5,"consoleMode":"commands","sourceLanguages":null},"__sessionId":"1f9e0fb8-9588-4a96-a30e-c41a4d136b29"},"type":"request","seq":2} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":1,"event":"output","body":{"category":"stderr","output":"Could not initialize Python interpreter - only native expressions will be available.\n"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":2,"event":"initialized"} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"command":"setBreakpoints","arguments":{"source":{"name":"syntacticAnalyzer.c","path":"/Users/javier/Documents/Practica1/compiler/syntacticAnalyzer.c"},"lines":[16,19,21],"breakpoints":[{"line":16},{"line":19},{"line":21}],"sourceModified":false},"type":"request","seq":3} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"message":"Locations: 0","verified":false},{"id":2,"message":"Locations: 0","verified":false},{"id":3,"message":"Locations: 0","verified":false}]}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"command":"setExceptionBreakpoints","arguments":{"filters":["cpp_throw"]},"type":"request","seq":5} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":5,"success":true,"command":"setExceptionBreakpoints"} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"command":"setDataBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":6} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":6,"success":true,"command":"setDataBreakpoints","body":{"breakpoints":[]}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"command":"configurationDone","type":"request","seq":7} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"request","seq":3,"command":"runInTerminal","arguments":{"args":["/Users/javier/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/codelldb","terminal-agent","--port=52821"],"cwd":"","kind":"integrated","title":"Debug"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"type":"response","seq":8,"command":"runInTerminal","request_seq":3,"success":true,"body":{"shellProcessId":7138}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":4,"event":"output","body":{"output":"Launching: /Users/javier/Documents/Practica1/compiler/compiler\n"}} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0b7e28e68 Event: broadcaster = 0x7fb0bc001218 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0b7e28f28 Event: broadcaster = 0x7fb0bc001218 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":2,"success":true,"command":"launch"} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0b7e28fe8 Event: broadcaster = 0x7fb0bc001218 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":7,"success":true,"command":"configurationDone"} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0b7e291b8 Event: broadcaster = 0x7fb0bc001218 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0ba30b928 Event: broadcaster = 0x7fb0bc001218 (lldb.target), type = 0x00000002 (modules-loaded), data = {dyld, compiler} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0ba30aa30 Event: broadcaster = 0x7fb0bc011c50 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fb0bc011c18 (pid = 8943), state = running} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":5,"event":"module","body":{"module":{"addressRange":"100008000","id":"100008000","name":"dyld","path":"/usr/lib/dyld","symbolFilePath":"/usr/lib/dyld","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":6,"event":"module","body":{"module":{"addressRange":"100000000","id":"100000000","name":"compiler","path":"/Users/javier/Documents/Practica1/compiler/compiler","symbolFilePath":"/Users/javier/Documents/Practica1/compiler/compiler","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":7,"event":"continued","body":{"allThreadsContinued":true,"threadId":0}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"command":"threads","type":"request","seq":9} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":9,"success":true,"command":"threads","body":{"threads":[{"id":161865,"name":"1: tid=161865"}]}} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0ba32a888 Event: broadcaster = 0x7fb0bc001218 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0ba00a518 Event: broadcaster = 0x7fb0bc001218 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0ba00a6e8 Event: broadcaster = 0x7fb0bc001218 (lldb.target), type = 0x00000001 (breakpoint-changed), data = {} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":8,"event":"breakpoint","body":{"breakpoint":{"id":4,"message":"Locations: 2","verified":true},"reason":"changed"}} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0b7d14d38 Event: broadcaster = 0x7fb0bc001218 (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} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":9,"event":"module","body":{"module":{"addressRange":"7FFF710CD000","id":"7FFF710CD000","name":"libc++.1.dylib","path":"/usr/lib/libc++.1.dylib","symbolFilePath":"/usr/lib/libc++.1.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":10,"event":"module","body":{"module":{"addressRange":"7FFF70DEF000","id":"7FFF70DEF000","name":"libSystem.B.dylib","path":"/usr/lib/libSystem.B.dylib","symbolFilePath":"/usr/lib/libSystem.B.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":11,"event":"module","body":{"module":{"addressRange":"7FFF71121000","id":"7FFF71121000","name":"libc++abi.dylib","path":"/usr/lib/libc++abi.dylib","symbolFilePath":"/usr/lib/libc++abi.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":12,"event":"module","body":{"module":{"addressRange":"7FFF73D5E000","id":"7FFF73D5E000","name":"libcache.dylib","path":"/usr/lib/system/libcache.dylib","symbolFilePath":"/usr/lib/system/libcache.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":13,"event":"module","body":{"module":{"addressRange":"7FFF73D64000","id":"7FFF73D64000","name":"libcommonCrypto.dylib","path":"/usr/lib/system/libcommonCrypto.dylib","symbolFilePath":"/usr/lib/system/libcommonCrypto.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":14,"event":"module","body":{"module":{"addressRange":"7FFF73D70000","id":"7FFF73D70000","name":"libcompiler_rt.dylib","path":"/usr/lib/system/libcompiler_rt.dylib","symbolFilePath":"/usr/lib/system/libcompiler_rt.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":15,"event":"module","body":{"module":{"addressRange":"7FFF73D78000","id":"7FFF73D78000","name":"libcopyfile.dylib","path":"/usr/lib/system/libcopyfile.dylib","symbolFilePath":"/usr/lib/system/libcopyfile.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":16,"event":"module","body":{"module":{"addressRange":"7FFF73D82000","id":"7FFF73D82000","name":"libcorecrypto.dylib","path":"/usr/lib/system/libcorecrypto.dylib","symbolFilePath":"/usr/lib/system/libcorecrypto.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":17,"event":"module","body":{"module":{"addressRange":"7FFF73F30000","id":"7FFF73F30000","name":"libdispatch.dylib","path":"/usr/lib/system/libdispatch.dylib","symbolFilePath":"/usr/lib/system/libdispatch.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":18,"event":"module","body":{"module":{"addressRange":"7FFF73F72000","id":"7FFF73F72000","name":"libdyld.dylib","path":"/usr/lib/system/libdyld.dylib","symbolFilePath":"/usr/lib/system/libdyld.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":19,"event":"module","body":{"module":{"addressRange":"7FFF73FA8000","id":"7FFF73FA8000","name":"libkeymgr.dylib","path":"/usr/lib/system/libkeymgr.dylib","symbolFilePath":"/usr/lib/system/libkeymgr.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":20,"event":"module","body":{"module":{"addressRange":"7FFF73FB6000","id":"7FFF73FB6000","name":"liblaunch.dylib","path":"/usr/lib/system/liblaunch.dylib","symbolFilePath":"/usr/lib/system/liblaunch.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":21,"event":"module","body":{"module":{"addressRange":"7FFF73FB7000","id":"7FFF73FB7000","name":"libmacho.dylib","path":"/usr/lib/system/libmacho.dylib","symbolFilePath":"/usr/lib/system/libmacho.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":22,"event":"module","body":{"module":{"addressRange":"7FFF73FBD000","id":"7FFF73FBD000","name":"libquarantine.dylib","path":"/usr/lib/system/libquarantine.dylib","symbolFilePath":"/usr/lib/system/libquarantine.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":23,"event":"module","body":{"module":{"addressRange":"7FFF73FC0000","id":"7FFF73FC0000","name":"libremovefile.dylib","path":"/usr/lib/system/libremovefile.dylib","symbolFilePath":"/usr/lib/system/libremovefile.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":24,"event":"module","body":{"module":{"addressRange":"7FFF73FC2000","id":"7FFF73FC2000","name":"libsystem_asl.dylib","path":"/usr/lib/system/libsystem_asl.dylib","symbolFilePath":"/usr/lib/system/libsystem_asl.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":25,"event":"module","body":{"module":{"addressRange":"7FFF73FDA000","id":"7FFF73FDA000","name":"libsystem_blocks.dylib","path":"/usr/lib/system/libsystem_blocks.dylib","symbolFilePath":"/usr/lib/system/libsystem_blocks.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":26,"event":"module","body":{"module":{"addressRange":"7FFF73FDB000","id":"7FFF73FDB000","name":"libsystem_c.dylib","path":"/usr/lib/system/libsystem_c.dylib","symbolFilePath":"/usr/lib/system/libsystem_c.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":27,"event":"module","body":{"module":{"addressRange":"7FFF74063000","id":"7FFF74063000","name":"libsystem_configuration.dylib","path":"/usr/lib/system/libsystem_configuration.dylib","symbolFilePath":"/usr/lib/system/libsystem_configuration.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":28,"event":"module","body":{"module":{"addressRange":"7FFF74067000","id":"7FFF74067000","name":"libsystem_coreservices.dylib","path":"/usr/lib/system/libsystem_coreservices.dylib","symbolFilePath":"/usr/lib/system/libsystem_coreservices.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":29,"event":"module","body":{"module":{"addressRange":"7FFF7406B000","id":"7FFF7406B000","name":"libsystem_darwin.dylib","path":"/usr/lib/system/libsystem_darwin.dylib","symbolFilePath":"/usr/lib/system/libsystem_darwin.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":30,"event":"module","body":{"module":{"addressRange":"7FFF74073000","id":"7FFF74073000","name":"libsystem_dnssd.dylib","path":"/usr/lib/system/libsystem_dnssd.dylib","symbolFilePath":"/usr/lib/system/libsystem_dnssd.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":31,"event":"module","body":{"module":{"addressRange":"7FFF7407B000","id":"7FFF7407B000","name":"libsystem_featureflags.dylib","path":"/usr/lib/system/libsystem_featureflags.dylib","symbolFilePath":"/usr/lib/system/libsystem_featureflags.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":32,"event":"module","body":{"module":{"addressRange":"7FFF7407D000","id":"7FFF7407D000","name":"libsystem_info.dylib","path":"/usr/lib/system/libsystem_info.dylib","symbolFilePath":"/usr/lib/system/libsystem_info.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":33,"event":"module","body":{"module":{"addressRange":"7FFF740F8000","id":"7FFF740F8000","name":"libsystem_m.dylib","path":"/usr/lib/system/libsystem_m.dylib","symbolFilePath":"/usr/lib/system/libsystem_m.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":34,"event":"module","body":{"module":{"addressRange":"7FFF74140000","id":"7FFF74140000","name":"libsystem_malloc.dylib","path":"/usr/lib/system/libsystem_malloc.dylib","symbolFilePath":"/usr/lib/system/libsystem_malloc.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":35,"event":"module","body":{"module":{"addressRange":"7FFF74168000","id":"7FFF74168000","name":"libsystem_networkextension.dylib","path":"/usr/lib/system/libsystem_networkextension.dylib","symbolFilePath":"/usr/lib/system/libsystem_networkextension.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":36,"event":"module","body":{"module":{"addressRange":"7FFF74176000","id":"7FFF74176000","name":"libsystem_notify.dylib","path":"/usr/lib/system/libsystem_notify.dylib","symbolFilePath":"/usr/lib/system/libsystem_notify.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":37,"event":"module","body":{"module":{"addressRange":"7FFF74195000","id":"7FFF74195000","name":"libsystem_sandbox.dylib","path":"/usr/lib/system/libsystem_sandbox.dylib","symbolFilePath":"/usr/lib/system/libsystem_sandbox.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":38,"event":"module","body":{"module":{"addressRange":"7FFF7419A000","id":"7FFF7419A000","name":"libsystem_secinit.dylib","path":"/usr/lib/system/libsystem_secinit.dylib","symbolFilePath":"/usr/lib/system/libsystem_secinit.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":39,"event":"module","body":{"module":{"addressRange":"7FFF740CB000","id":"7FFF740CB000","name":"libsystem_kernel.dylib","path":"/usr/lib/system/libsystem_kernel.dylib","symbolFilePath":"/usr/lib/system/libsystem_kernel.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":40,"event":"module","body":{"module":{"addressRange":"7FFF74180000","id":"7FFF74180000","name":"libsystem_platform.dylib","path":"/usr/lib/system/libsystem_platform.dylib","symbolFilePath":"/usr/lib/system/libsystem_platform.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":41,"event":"module","body":{"module":{"addressRange":"7FFF7418A000","id":"7FFF7418A000","name":"libsystem_pthread.dylib","path":"/usr/lib/system/libsystem_pthread.dylib","symbolFilePath":"/usr/lib/system/libsystem_pthread.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":42,"event":"module","body":{"module":{"addressRange":"7FFF7419D000","id":"7FFF7419D000","name":"libsystem_symptoms.dylib","path":"/usr/lib/system/libsystem_symptoms.dylib","symbolFilePath":"/usr/lib/system/libsystem_symptoms.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":43,"event":"module","body":{"module":{"addressRange":"7FFF741A5000","id":"7FFF741A5000","name":"libsystem_trace.dylib","path":"/usr/lib/system/libsystem_trace.dylib","symbolFilePath":"/usr/lib/system/libsystem_trace.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":44,"event":"module","body":{"module":{"addressRange":"7FFF741BD000","id":"7FFF741BD000","name":"libunwind.dylib","path":"/usr/lib/system/libunwind.dylib","symbolFilePath":"/usr/lib/system/libunwind.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":45,"event":"module","body":{"module":{"addressRange":"7FFF741C3000","id":"7FFF741C3000","name":"libxpc.dylib","path":"/usr/lib/system/libxpc.dylib","symbolFilePath":"/usr/lib/system/libxpc.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":46,"event":"module","body":{"module":{"addressRange":"7FFF72C12000","id":"7FFF72C12000","name":"libobjc.A.dylib","path":"/usr/lib/libobjc.A.dylib","symbolFilePath":"/usr/lib/libobjc.A.dylib","symbolStatus":"Symbols loaded."},"reason":"new"}} [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] Debug event: 0x7fb0b7e6f520 Event: broadcaster = 0x7fb0bc011c50 (lldb.process), type = 0x00000001 (state-changed), data = { process = 0x7fb0bc011c18 (pid = 8943), state = exited} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":47,"event":"output","body":{"output":"Process exited with code 0.\n"}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":48,"event":"exited","body":{"exitCode":0}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"event","seq":49,"event":"terminated","body":{}} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] --> {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":10} [2019-10-23T12:41:10Z DEBUG codelldb::wire_protocol] <-- {"type":"response","request_seq":10,"success":true,"command":"disconnect"} [2019-10-23T12:41:10Z ERROR codelldb::debug_session] Stream::poll after shutdown [2019-10-23T12:41:10Z DEBUG codelldb] ### session_to_client stream terminated [2019-10-23T12:41:10Z INFO  codelldb] ### server resolved: Ok(()) [2019-10-23T12:41:10Z INFO  codelldb] ### client_to_session stream terminated [2019-10-23T12:41:10Z DEBUG codelldb::debug_session] ### AsyncDebugSession::drop() [2019-10-23T12:41:10Z DEBUG codelldb] ### Exiting Debug adapter exit code=0, signal=null.

Do you have python 3 installed on that machine?  What's the output of python3 -m sysconfig?

Yes I do

Which OS: macOs Mojave (10.14)
Which VSCode version: 1.39.2
Which extension version: 1.4.0
Which adapter type: native
lldb version: lldb-1<IP_ADDRESS>
Apple Swift version 5.1 (swiftlang-1100.0.270.13 clang-1<IP_ADDRESS>)
I'm seeing similar issue, but I have also recently installed pyenv and switched between version 2 and 3, so it's not unlikely I've caused this myself. However after switching back to the system version of Python I get:
configuration: { type: 'lldb',
  request: 'launch',
  name: 'xxx',
  program: '${workspaceRoot}/target/debug/xxx',
  args: [],
  cwd: '${workspaceRoot}/target/debug',
  sourceLanguages: [ 'rust' ],
  env: { RUST_BACKTRACE: '1' },
  relativePathBase: '/Users/johanster/Projects/rust/fabrik' }
[2019-10-24T19:06:00Z ERROR codelldb] load_python: Internal("\"dlopen(/Users/johanster/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib, 257): Symbol not found: _PyBool_Type\\n  Referenced from: /Users/johanster/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib\\n  Expected in: flat namespace\\n in /Users/johanster/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib\"")
Listening on port 58279

Running python -m sysconfig yields:
python -m sysconfig
Platform: "macosx-10.14-intel"
Python version: "2.7"
Current installation scheme: "posix_prefix"

Paths:
	data = "/System/Library/Frameworks/Python.framework/Versions/2.7"
	include = "/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7"
	platinclude = "/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7"
	platlib = "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages"
	platstdlib = "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7"
	purelib = "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages"
	scripts = "/System/Library/Frameworks/Python.framework/Versions/2.7/bin"
	stdlib = "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7"

@JavierYepez: I was interested in the "Variables" section.
I've tested with system and brew python3, not with conda.   Finding location of libpython3 is proving to be a headache :(    If you can locate it yourself, set the lldb.libpython configuration parameter.

@johanster: That should be "python3 -m sysconfig".  Please post the "Variables" section, maybe as attached file, if it's too long.   Thanks!

@vadimcn I don't have python3 in my path any longer since I'm using pyenv to enable/disable versions. I can understand how complicated finding that lib is, especially if you use external tools or virtual envs! I will try to use lldb.libpython as well.

Thanks for your help!

But now It doesn't stops at my breakpoints. I don't know if I'm doing something wrong.
Please tell me what information do you need to help me out

But now It doesn't stops at my breakpoints. I don't know if I'm doing something wrong.
Please tell me what information do you need to help me out.

Does it stop if you add "stopOnEntry": true into the launch config?  If so, the debugger probably works fine, but for some reason cannot find debug symbols for your binary.
I don't know an easy bulletproof way of checking symbols on macOS, but dsymutil -s <binary> | grep N_OSO outputting something seems to be a pretty good indicator of their presence.
Also, please try the command-line lldb.   If it works, the problem is likely to be in my extension, otherwise, some general problem with your build setup is likely.

I'm new using a debuggers without an IDE, so I don't know how to give you more useful information... But if I add the "stopOnEntry": true it stops here (I only see assembler code):

Also it never reaches my breakpoints. Also here is the dsymutil -s <binary> | grep N_OSO output:

And seems that lldb works:
`Process 1484 exited with status = 9 (0x00000009)
Process 1542 launched: '/Users/javier/Documents/OneDrive - Universidade de Santiago de Compostela/Estudios/Ing_Informatica/Cuarto/Compiladores e Interpretes/Practica1/compiler/compiler' (x86_64)
Process 1542 stopped

thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x000000010000184a compilerinitLexicalAnalyzer + 26 compilerinitLexicalAnalyzer:
->  0x10000184a <+26>: movq   %rdi, (%rax)
0x10000184d <+29>: movl   $0x38, %edi
0x100001852 <+34>: callq  0x100002d42               ; symbol stub for: malloc
0x100001857 <+39>: xorl   %ecx, %ecx
Target 0: (compiler) stopped.`

Well, looks like the debug info is there, however lldb still cannot find your source file.  Did you move the binary after having compiled it?
Try issuing bt command when lldb has stopped on access violation.   It will show all stack frames and whatever source location it found for them (if any).   Also, source info.
I would recommend getting familiar with LLDB commands.   There's a lot of useful features there that are not exposed in the IDE.

Yes I moved it. Now i fixed the access violation and runs smoothly but the vs code debugger still skips my breakpoints. But I was able to set a breakpoint directly with lldb

Any idea why?

The equivalent of b in VSCode would be setting a regex function breakpoint.
As you can see, the lldb still does not display the source code.  This is probably because source file locations are encoded relative to binary's location, so if you moved the latter, the debugger won't be able to find the source.  Try  executing source info after having stopped in main, it should tell you where the debugger thinks the source file is.   If it's wrong, you may need to set up a source mapping.
If you still can't figure it out, I suggest seeking help from someone nearby.

First of all thanks for the patience.
Second, I'm not moving the binary so i shouldn't need a source mapping, right? also the source info didn't find the source code.
In this picture you can see the project structure and the terminal with the lldb commands:

I've set lldb.libpython to my brew installed /usr/bin/python3 but still getting same error:
"dlopen(/usr/bin/python3, 257): image not found"
[2019-11-04T08:48:07Z ERROR codelldb] load_python: Internal(""dlopen(/Users/gilescope/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib, 257): Symbol not found: _PyBool_Type\n  Referenced from: /Users/gilescope/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib\n  Expected in: flat namespace\n in /Users/gilescope/.vscode/extensions/vadimcn.vscode-lldb-1.4.0/adapter2/libcodelldb_python.dylib"")
Any other tips on how to debug this, I tried otool -L but it seemed happy.

"Could not initialize Python interpreter" is more of a warning on OSX.  The debugger will still work, although without python features.
You need to point lldb.libpython to libpythonXX.dylib not to the main executable.

For others, the only way I could get this working was doing:
open -a "Visual Studio Code"

from within an anaconda environment (i.e. a command prompt where which python and which python3 are pointing into a specific python env). No idea why my base python osx is broken, but at least got something that works now.
(I can even see a HashMap contents and it breaks on panic! - thank you so much @vadimcn  - happy rust dev.)


lncli: do not hang on ctrl-c

If the lnd package is referenced, the interrupt signal handler will be initialized causing lncli to not properly exit on ctrl-c.
This commit prevents this by making the initialization of the interrupt interceptor an explicit action.

Yes, I described those alternatives in the commit message. Copied them over to the PR description for visibility.

Switched to explicit init approach

Add did a hodl invoice on the other side

Yay, late to the party, but this PR fixed the signal race that happened on shutdown. :)


Fix tqdm zip bug

This PR solves #5117, by wrapping the entire zip clause in tqdm.
For more information, please checkout this Stack Overflow thread:
https://stackoverflow.com/questions/41171191/tqdm-progressbar-and-zip-built-in-do-not-work-together

@albertvillanova Thanks for your comment. What do you think about creating 2 pbar for each case? I see the pbar_iterable is initialized differently. Maybe pbar can also be initialized like that.

@albertvillanova Another solution I implemented is to change pbar_iterable and add the zip to it. I updated the PR with this solution. Let me know what you think.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

@albertvillanova Done :) Let me know what you think.

@albertvillanova Thanks :) I also don't see an easy way to test this. This was just a problem in the way tqdm was used. I'm not sure we should cover it in tests.

Hi,
First of all, thanks for this PR.
It's the first time I join a discussion on GitHUB on problem resolution in libraries such as transformers, so I hope I comply to the best practices for an efficient communication...
I am running AutoTokenizer.from_pretrained in a Google Colab notebook for using with BERT base.
I am experiencing issue 5117.
Each time I run my notebook, I do:
! pip install transformers  ! pip install datasets  ! pip install huggingface_hub
As I understand, the issue has been resolved and the solution merged to the released version of the code?
So I expect that the bug is resolved in my notebook, however this is not the case.
Do I get something wrong?
Do I have to implement some change in the source code myself?
Thanks in advance for your help!

@Cochonaki Hi :) The problem was fixed but there wasn't a release since then. I believe a new release should come out in the upcoming weeks. Maybe someone from the core maintainers can answer that :)
cc: @albertvillanova

Baby Haiti Coffee SE is born
NH watch
On Sun, Oct 23, 2022 at 02:39 Dudu Lasry @.***> wrote:

@Cochonaki https://github.com/Cochonaki Hi :) The problem was fixed but
there wasn't a release since then. I believe a new release should come out
in the upcoming weeks. Maybe someone from the core maintainers can answer
that :)
cc: @albertvillanova https://github.com/albertvillanova
—
Reply to this email directly, view it on GitHub
https://github.com/huggingface/datasets/pull/5120#issuecomment-1288024546,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB4E2NCT7QO7W3PTQGDIKDWETMQ7ANCNFSM6AAAAAARGRBY2M
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi, @Cochonaki.
As @david1542 pointed out, we have not made a release since this bug was fixed. We will make one in the following weeks.
In the meantime, if you would like to incorporate the bug fix, you can install datasets from this repo main branch:
pip install git+https://github.com/huggingface/datasets#egg=datasets

Thanks a lot @albertvillanova and @david1542, it works now!
I am really thankful for your help, that encourages me to participate more in this community.
See you around!

Welcome!!! 🤗


Google Drive url

Hello, I want to display a kml file's layer, from url (from resource works well!)  using those two functions of the api :
private void retrieveFileFromUrl() {         new DownloadKmlFile(getString(R.string.kml_url)).execute();     }
` protected byte[] doInBackground(String... params) {
try {
InputStream is =  new URL(mUrl).openStream();
ByteArrayOutputStream buffer = new ByteArrayOutputStream();
int nRead;
byte[] data = new byte[16384];
while ((nRead = is.read(data, 0, data.length)) != -1) {
buffer.write(data, 0, nRead);
}
buffer.flush();
return buffer.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
    protected void onPostExecute(byte[] byteArr) {
        try {
            KmlLayer kmlLayer = new KmlLayer(mMap, new ByteArrayInputStream(byteArr),
                    getApplicationContext());
            kmlLayer.addLayerToMap();
            kmlLayer.setOnFeatureClickListener(new KmlLayer.OnFeatureClickListener() {
                @Override
                public void onFeatureClick(Feature feature) {
                    Toast.makeText(KmlDemoActivity.this,
                            "Feature clicked: " + feature.getId(),
                            Toast.LENGTH_SHORT).show();
                }
            });
            moveCameraToKml(kmlLayer);
        } catch (XmlPullParserException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
} `

well those two functions worked for the direct url used in the demo : " http://googlemaps.github.io/kml-samples/morekml/Polygons/Polygons.Google_Campus.kml "
but don't work for Google drive url! what should i change ?

I'm not sure what the solution is, but I'll close this for now since it isn't an issue specific to this library.
Might be worth posting to stackoverflow.com for better coverage.


Would you consider adding function to "RunningAverage"

I'm working with sensors - most of the time the interval between sensing periods is very close such that a simple running average for the hour, 8 hour or day works fine.   However I've also been working to make the sensing packages reduce energy if the battery appears to be dropping - and that typically means stretching out time between samples.
This means the data needs to be time weighted averages (TWA).
Easy way is to use the RunningAverage liibrary.  In the application use TWO circular buffers,  the first will be the numerator in calculating TWA,  the second would contain the values for the denominator.
TWA =  Sum_of (delta_T X sensor_value) / (Sum_of (delta_T))

By using the existing library,  it's now possible to use your existing functions to find the jitter in the interval between measurements.  That jitter or variation can mean a lot in the accuracy...
Your existing library code  with new function like:
//
float RunningAverage::getsum() const
{
  if (_count == 0)
  {
    return NAN;
  }

  return _sum;   //
}

(added syntax highlighting)

Thanks for sharing,
Sounds like an interesting addition. And I need to think about how it affects existing projects. A derived class might be tight choice.

@heidnerd
Could it be interesting to make the weight more generic?
Default weight is 1, your proposal the weight is time, however it could also be an other unit.
This would imply that addValue(value, weight = 1) would allow the user to add any weight it wants to,
It would also solve a "time problem" for the first sample, the library cannot add a weight to it, so it should be zero.?

@heidnerd
Created a first implementation of a RA_weight class in the develop branch.
It is derived from RunningAverage and implements the core functions to add a value and to get average.
Note however that not all functionality is implemented with weight (needs investigation if they make sense and how)
The outcome might be a stand alone repo with a stripped interface.

Note: https://en.wikipedia.org/wiki/Weighted_arithmetic_mean

@heidnerd
Note: I kept the implementation in the RA_weight class pretty generic so people have to add the weight themselves with addValue(value, weight). If none is given the weight == 1.
This allows you to add the duration as weight and other people using theirs.
Please let me know if there is functionality missing that would logically fit into the RA_weight class.

I can come up with some examples.   Pretty simple examples of the TWA
and the interval jitter is useful.
I can add in the section of code and see how that works - but I really
don't like forking libraries unnecessarily.

Dennis Heidner
(206) 817-1164
On 2024-06-24 20:44, Rob Tillaart wrote:

Thanks for sharing,
Sounds like an interesting addition. And I need to think about how it
affects existing projects. A derived class might be tight choice.
--
Reply to this email directly, view it on GitHub [1], or unsubscribe
[2].
You are receiving this because you authored the thread.Message ID:
@.***>

Links:
[1]
https://github.com/RobTillaart/RunningAverage/issues/30#issuecomment-2187911479
[2]
https://github.com/notifications/unsubscribe-auth/ALN7EVW47KW2SX4WNECYTEDZJDRRBAVCNFSM6AAAAABJ23FFNGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBXHEYTCNBXHE

I can come up with some examples.   Pretty simple examples of the TWA
and the interval jitter is useful.

That would be very informative as keeping the API close to real use cases is good (imho).

I can add in the section of code and see how that works

Your feedback is welcome

but I really don't like forking libraries unnecessarily.

Agree,
however in my experience the Arduino (IOT) ecosystem is very diverse. I have seen projects working with tiny processors with 2K Ram or less running on 1 MHz and on the other end things like ESP32's with plenty room to spare at 240 MHz and beyond. For me in my role as (Arduino) library developer I must guard that performance and footprint is more or less stable over versions, especially for often used libraries like RA. Furthermore the interface must be kept simple to not confront new tinkers with steep learning curves (adding weights is not the problem here).
Adding weights to the base RunningAverage library roughly doubles the RAM footprint, which is limited at the low end of the IOT spectrum. Therefor I have to be careful and prefer a separate derived class. Then users can select the class with or the class without weights. Only if a derived class is harder (whatever that means) than a new library the latter comes into sight.
Hope this helps to understand my thoughts around libraries in general and this issue specific.

Spend a few hours trying to understand the definition of STDDEV and STDERR in context of a weighted running average.
no conclusion (code) yet

For testing -  a delay which might be something like    additional call to random number then -- delay (random(1,250);   OR simply use the value of the second call to the random number function  and then addValue (random(250) );

So you only need the function getSum() ?
I was in the assumption you needed something far more different.
Still this investigation has learned me a few new things and even more new question ;)
So definitely worth the time spend.

@heidnerd
Redid the whole bunch ==> see develop branch + PR.
I have added a number of checks if the internal array was allocated for robustness.
This changed a number of return types, is backwards compatible.
Please verify if develop branch meet your needs.

Correct only getSum,  as simple as possible.   Yet that export makes it possible to create TWA by using two or more instances...

Correct only getSum, as simple as possible. Yet that export makes it possible to create TWA by using two or more instances...
I'll see about adding some links on how TWA is used with sensors to help estimate exposures and health risks.

Then I will merge the PR asap, there is an additional new function - see #31 - and some improved signatures.
Furthermore I will close this issue. Feel free to open a new issue if needed.

I saw #31 while I don't need it now, it will be useful.
Thanks,   I'll at some links and explanation.  I can also try doing a simple example sketch.

getSum() is now in version 0.4.6, released a few minutes ago.
Again thanks for the issue,
the "derived class weighted running average" is on my todo list and will appear sometime in the future.


Fixed CCUD CI detection when using wsl-bash on GHA

Added the CCUD necessary env vars to the WSLENV for wsl-bash githubActions testing.
Until now, cross-platform tests on windows, which use wsl-bash shell did not correctly pick up that this was executed on github actions. This is not an issue of CCUD, it's an issue of WSL, which by default doesn't "forward" env vars set in Windows (host) by default. The only way to forward them is to set them using WSLENV - see discussion and Microsoft blog. You can also observe that in this test project, where the env vars are printed out. All of them are available with the default windows shell (pwsh), but almost none are there with wsl. When WSLENV is configured, the specified vars are available, which also means that CCUD will tag the build correctly, as well as add all of the other values.
Note: These are the two cross-platform runs with these changes:

Run Cross-Platform Tests (Use Development Release) - Example scan with custom data
Run Cross-Platform Tests (Build From Source) - Example scan with custom data

Yes, however if they're using WSL, they should already be aware of this, so they hopefully have this in place already. But if they don't we can direct them here.


Multiple filetype icon themes render side by side

VSCode Version: 1.5.2
OS Version: Windows10 Pro

It's hard to reproduce but sometimes when switching icon themes, the old and the new icon theme render side by side.
It looks like the old icon theme get's cached somehow somewhere.
Steps to reproduce:

Download and set an icon theme.
Close and reopen VSCode.
Go into FILE ICON THEME category and change to other icon pack theme.

I can reproduce the issue with --disable-extensions as well.

@androidu you have the vscode-icons extension installed which patches our bits. the only fix is to completly uninstall and reinstall VS Code.


ESP32 as SPI Slave trying to receive 12 bit transfers.

I am trying to use ESP32SPISlave to intercept the data between a keypad and a passive LCD display with status icons. My goal is to be able to monitor the state remotely.
Using an digital analyzer the keypad display is updated with what is very similar to SPI, but it sends 12 bits when the SS is pulled low. The device sends 18 x 12 bit bytes to the screen for the various icons and the last four bits are the ones that change the state of the icon. I can remove the display and manually control it as a master by manually setting the SS low and transfering the data (adding extra 0s to the last 4 bits does not affect the device), however when I try to listen in as a slave to see how it is being updated I can only see the first 8 bits. I have tried  looking at the next data in the buffer array i.e. spi_slave_rx_buf[1], spi_slave_rx_buf[2]... by looping through the array but the data is not there.  I Also tried shifting the bits of the rxbuffer but that also didn't work.
Is there any way to modify my code or the ESP32SPISLave.h file to see the full 12 bits sent or extract the last 4 bits seperately? Or possibly to read the MOSI line in 4 bit bytes?
The code I am using is:
#include <ESP32SPISlave.h>

ESP32SPISlave slave;

static constexpr uint32_t BUFFER_SIZE {32};
uint8_t spi_slave_tx_buf[BUFFER_SIZE];
uint8_t spi_slave_rx_buf[BUFFER_SIZE];

void setup() {
    Serial.begin(115200);
    // begin() after setting
    // HSPI = CS: 15, CLK: 14, MOSI: 13, MISO: 12 -> default
    // VSPI = CS:  5, CLK: 18, MOSI: 23, MISO: 19
    slave.setDataMode(SPI_MODE3);
    slave.begin();
    // slave.begin(VSPI);   // you can use VSPI like this

    // clear buffers
    memset(spi_slave_tx_buf, 0, BUFFER_SIZE);
    memset(spi_slave_rx_buf, 0, BUFFER_SIZE);
}

void loop() {
    // block until the transaction comes from master
    slave.wait(spi_slave_rx_buf, BUFFER_SIZE);

    // if transaction has completed from master,
    // available() returns size of results of transaction,
    // and buffer is automatically updated
    char data;
    while (slave.available()) {
        // show received data
         Serial.println(spi_slave_rx_buf[0], HEX);
         data = spi_slave_rx_buf[0];
         slave.pop();
    }

}

Analyzer signal:

Serial Output:

Does your LCD become an SPI master? Or does the status data come from LCD as a Slave after you send data as a Master?

I believe the LCD is a SPI slave and the keypad is the master. I am hooking my ESP32 into the 3 data lines (clk, ss, mosi) running from the keypad to display to sniff the data as it's being sent from keypad to lcd. So i assumed my esp32 would also act like a slave in parrallel with the LCD and receive the same data.

In your code, you are printing only the first byte per transaction. Is this correct?
    // if transaction has completed from master,
    // available() returns size of results of transaction,
    // and buffer is automatically updated
    char data;
    while (slave.available()) {
        // show received data
         Serial.println(spi_slave_rx_buf[0], HEX);
         data = spi_slave_rx_buf[0];
         slave.pop();
    }

If not, please refer to my example:
https://github.com/hideakitai/ESP32SPISlave/blob/ec346e2b50b3611e7fe8213c65f12cd810789669/examples/slave_simple_wait/slave_simple_wait.ino#L29-L41

Sorry, I did try looping through the spi_slave_rxbuf[i] array for each transaction.
Only spi_slave_rx_buf[0] is correct and matches the first 8 bit bytes from the logic analyzer. (i.e. 0x9c, 0x80, 0x83, 0x85...) But second byte in the array or spi_slave_rx_buf[1] is the same for every transaction i.e. 0xF7 and incorrect. It should be 0x7, 0xB, 0x0, 0x3...). Even if it inputted 0s for the last 4 bits (0x70, 0xB0, 0x00, 0x30...) I could work with that but it gives me the same constant result for every transaction 0xF7 (when i get back to my bench I will hook it up again and screenshot the data).
It is like the second byte does not get recorded at all because only 4 of the 8 bits of the second byte are transmitted before the CS goes high and the next transaction starts. If I could make it read 4 bit bytes at a time instead of 8 per transaction, all the data should make it into spi_slave_rx_buf[i] evenly. So for the data would come out:
1st transaction:
spi_slave_rx_buf[0] = 0x9, spi_slave_rx_buf[1] = 0xC, spi_slave_rx_buf[2] = 0x7.
2nd transaction:
spi_slave_rx_buf[0] = 0x8, spi_slave_rx_buf[1] = 0x0, spi_slave_rx_buf[2] = 0x3.
3rd transaction:
spi_slave_rx_buf[0] = 0x8, spi_slave_rx_buf[1] = 0x0, spi_slave_rx_buf[2] = 0xB.
...

Could you give me code that can reproduce the same issue in my environment, with one of the SPIs on the ESP32 as a dummy Master (sending the same byte sequence as the target) and another SPI on the same ESP32 as a Slave (causing the same phenomenon as the issue)?

I don't know if I'll be able to write code to mimmick that hardware. The signal is being sent from an alarm keypad that I'm attempting to intercept the lcd display data to read the alarm status remotely.
However I got a different keypad model that uses a standard HD44780 16x2 display and I was able to decode and read the data correctly on that model and so haven't worked on the other one that uses the odd 12 bit SPI signal in a while. Ill take another look at the 12 bit SPI keypad again soon and see if I can provide better details.

If you still need help, please feel free to reopen this issue.


reactive config loading buggy

Did not pick up my config changes after editing Assets/configuration.edn. Hard to say why or provide an illustrative example.

Need more than this

I've found something that might be an issue.
After compiling core, it looks like we're redefining clojure.core.protocols/CollReduce. The filewatcher uses arcadia.internal.map-utils/valsr, which reifies that protocol. The redefinition breaks the reification.
Reloading the VM after compiling core should do the trick. Removing the dependency on valsr ought to do it too.

Though if we're also compiling map-utils it shouldn't be a problem... nevertheless, after compiling I end up with:
(instance? clojure.core.protocols.CollReduce
  (arcadia.internal.map-utils/valsr
    (zipmap (range 10) (range))))
;; => false

then after reevaling map-utils:
(instance? clojure.core.protocols.CollReduce
  (arcadia.internal.map-utils/valsr
    (zipmap (range 10) (range))))
;; => true

If this is a problem here, it will be a problem elsewhere.
I notice we're compiling internal namespaces one at a time, this seems dangerous; let's use arcadia.compiler/aot-namespaces instead

I'm assuming this one is closed as of a946a4fd517be085c92e40d874ffa4dbd8837fbb, which changes the aot policy such that namespaces aren't double-aot'd.


TRIDENT-17354 Automation Service beta

Purpose of this pull request
This pull request (PR) adds a new "Automation Service" article for beta release.
The beta article will be located here:
https://help.sumologic.com/docs/cse/integrations/automation-service/
Issue number:
TRIDENT-17354
Select the type of change:

[ ] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions and updating sections
[x] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - Updates, maintenance, and new packages for the site, Gatsby, React, etc

@pkazmir-sumo, you can see the draft article here (from the deploy-to-review check):
https://d2t1s0ah22jxsa.cloudfront.net/1972/merge/docs/cse/integrations/automation-service/

Thanks for the review, @kimsauce! I committed all your suggestions.


Error regarding env file

I have done all the steps as mentioned in readme but when i put my credentials in the .env file i am getting this error. I would be thankful if you help me regarding this

Have you check the .env.example file?

Yess added my credentials

May I see how it look like?. You can erase the value of your key.


Handle Wallet Onfido flow

Tested with https://github.com/Expensify/Web-Secure/pull/2174
Details
Handle Onfido flow in P2P wallet activation
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/191962
Tests
Tests can be found in https://github.com/Expensify/Web-Secure/pull/2182
QA Steps
None
Screenshots
Web

Friendly Bump @marcaaron @ctkochan22 and @francoisl for review

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @nkuoch in version: 1.1.46-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @timszot in version: 1.1.46-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

Hi @nkuoch, could you please let us know if there is an easy way to get to this screen in order to test it from the accessibility perspective? Can we use any testing account to get to it? Thanks!
CC @SumitDiyora @Stutikuls


[Android] Add build target for XWalkRuntimeLibLzma.apk

This runtime APK is used in silent download mode and the size is
significantly reduced by using LZMA compression to compress the
key components of the runtime APK.
We put the compressed ingredients to assets and then package them as
an APK, this is intented to utilize the APK integrity/signature
check for security concern.
XWALK-5214

@lincsoon @halton Please take a look, Thanks!
@rakuco We need to distribute this APK through 01.org download.

@axinging

@rakuco Please take a look again. thanks.

@heke123 you should be included in this review cause it affect lite branch somehow.

OK, I finally had time to get back to this. See my branch 3317-the-right-way: it implements the suggestions I've mentioned in this review on top of your existing commit. There's no hardcoding of outputs anymore, and the action input list is now correct.

@rakuco Great, your implementation looks better. Would you help to submit a PR combining the full commits? I wanted to update this PR with your commit but found that it's still WIP. Thanks!

feel free to squash them together and update this pull request. I only marked my commit WIP because it was a proof of concept.

@rakuco Thanks so much! Updated.

merging. please remember to file a ticket if you need additional APKs to be shipped in download.01.org.


Add ability to strong name sign the output of the build

In the same way that all Chocolatey artifacts, i.e. choco.exe, chocolatey.dll, etc are strong name signed, all the artifacts of Chocolatey GUI i.e. chocolateygui.exe, chocolateyguicli.exe, chocolateygui.common.dll, etc, should all be strong name signed as well.
These should use a different snk file from the Chocolatey repositories, so that there is clear separation between what is related to Chocolatey and what is Chocolatey GUI.

@punker76 thank you for all your help here!  This seems to now be working! 🎉


DiskSpaceAllocatorPool is currently not thread-safe for runtime initialization

Currently DiskSpaceAllocatorPool is only initialized when server starts up. In the future, we might need runtime initialization after adding/removing stores. Hence, we should make the DiskSpaceAllocatorPool thread-safe especially when stores are concurrently requesting/returning segments and compaction thread is occupying some segments.
This is not urgent for Store addition/deletion because in worst case we could let DiskSpaceAllocator take care of additional/extra segments when the server restart next time.
In the long term, we need to figure out a proper way to support thread-safe initialization. The tentative plan is:
(1) started with adding lock for each method.
(2) monitor metrics to evaluate influence.
(3) if performance became bad,  temporarily roll back.
(4) discuss almost all possible race condition cases and come up with a new scheme (like create pool for each store)

DiskSpaceAllocator is now supporting dynamically adding/removing store without re-initialization.
Details in #1210


make one Tuple class aross all the projects

#1791

LGTM - we'll want to do another rc release with this before 1.0.0

Approving an early merge because the change is purely syntactic and all linux tests have passed.

Coverage decreased (-0.02%) to 81.04% when pulling ca11b5706f72ad02059bdf23378fc0c313bba567 on neozwu:make-common-tuple into 50e37e624a8e7a8eb8087d90fb9f001a1654a980 on GoogleCloudPlatform:master.


Overriding sugar methods

This branch is very outdated and in any case to land it we'd want to merge with gh-pages.
I don't think this is how we want to proceed.


perf: fix redundant docs rendering

After 05229ddc2fd1695c979e2807aa96842978dd4779 adding the use of stylize_markdown, I consistently experience half second stutters when docs are open and switching between items. Nvim-cmp has zero issues with this.
Basically I copied what nvim-cmp does, which removed all performance issues for me.  The buffer is cleared more efficiently. nvim_buf_set_lines is not used redundantly only to be instantly overridden by stylize_markdown. Setting the "modified" option is moved to the end of the function.

I've A-B tested doc performance with both this PR and main and there definitely an improvement here, however slight.
I did notice the doc output looks different. For example, this is main:

And with your changes:

The latter looks better, IMO. Any idea why this is?

I'm not sure why main looks different to you. For me this PR looks the same.
Also the lag seems to be much more pronounced with rust-analyzer for some reason. With lua_ls it didn't really make a difference.
The lag is also much worse on nightly.
main with nvim nightly (After the first 6 secs I start tapping quickly and it stutters badly):
Screencast_20241015_123926.webm
this PR with nvim nightly (I'm tapping just as quick and there is no stutter):
Screencast_20241015_124018.webm
It doesn't show that well on video because KDE Spectacle seems to add its own lag but it feels way better.

Thanks for finding this regression! I wasn't happy with the performance even if we cached it and noticed that it was using regex highlighting instead of treesitter. I took inspiration from the vim.treesitter.highlighter code to highlight the documentation window ourselves. It has a high initial cost of 50ms for compiling the markdown query, but afterwards, it updates in a few ms. Lmk if performance looks good on your end

Performance feels great now. Also looks better with treesitter. Thanks!


"Winutil /tweaks/ create winutil shortcut "   link are not working

Describe the bug
With the latest version of winutil  the function " create  winutil shortcut " in tweak section  dont work as before!    Those dirty developers always trying to  get our money...
In all seriousness, this might get removed if it becomes problematic with AntiVirus programs. I've had a lot of false flags and noticed anytime I share a lnk file with people all AV flag the program.
Either way you can always run the program with powershell, so there is no need to buy the EXE if you don't want to. You can also make your own shortcut with powershell 7 and adding the run command "irm christitus.com/win | iex".

 FEELS LIKE THEY ARE TRYING TO GET US TO BUY THE EXE

weird enough that it works for me until as of now.

I have already buyed the .exe  (as a Donor because its worth! ) but always use terminal/Pshell because is more easy than searching for damned usb key always lost in the lab


Various unit tests

My only issue with this PR is you didn't report the coverage increase. I guess we'll see it now on master! ;-p
Merging.

It's tiny :(


Documentation with MultiDocumenter.jl

Merge the test-multidocs branch.
Related issues:

https://github.com/JuliaGraphs/GraphNeuralNetworks.jl/issues/483
https://github.com/JuliaGraphs/GraphNeuralNetworks.jl/issues/481
https://github.com/JuliaGraphs/GraphNeuralNetworks.jl/issues/457
https://github.com/JuliaGraphs/GraphNeuralNetworks.jl/issues/456
https://github.com/JuliaGraphs/GraphNeuralNetworks.jl/issues/450

It is ok that the workflows fail, its because we cannot push from a PR to the branch that contains the html.
Maybe I should create another workflow to check the docs of the PRs.


FiveM can only run occlusions for a single map

So when you use this method to make another set of audio occlusions for another map so for example I have:
MLO - Warehouse
MLO - Mafia
And we make occlusions for Warehouse and run it they work, then we make it for Mafia and start that resource 2nd in the config, Occlusions will work for Warehouse but not mafia, if we disable warehouse and its occlusions then occlusions will work for Mafia. Is there a way to run both sets of audio occlusions?

FiveM seems only support one occlusion files.
so you need to merge it to single file. and stream onec.

I haven't had any problems running more than one resource with occlusion files inside of it

One way how to counter your issue is combining both occlusion data files together what Nikez does, but I think he has made custom tools to do it for him


oEmbed Discovery

The spec strongly suggests that clients should use discovery, and not the list of providers, for finding oEmbeds.
This site does not.
https://oembed.com/#section4

Ah — this is probably why trying to use permalinks from Mastodon instances isn't working.
Argh.


Dynamically configure use case routes at runtime

Similar to Alexa, use cases would provide a JSON document with information including which URL to send a request to toggle on/off for example. We would then read the JSON documents and send the requests to the correct url based on the robot type (in info server).
We can also define calibration paramenters, interface type etc in the JSON document.

#149 achieves this, in a way


Traefik and docker websocket handshake fail

Do you want to request a feature or report a bug?
I want to report a bug (or a lack of documentation)

What did you do?
I'm trying to make websocket handshake working with traefik and docker

What did you expect to see?
Websocket handshake succeeded => 101 Switching Protocols
What did you see instead?
Websocket hanshake failed => 403 Forbidden
Output of traefik version: (What version of Traefik are you using?)
1.3.2
What is your environment & configuration (arguments, toml, provider, platform, ...)?
Here is my traefik.toml conf:
defaultEntryPoints = ["http", "https", "ws", "wss"]

[web]
address = ":8080"

[entryPoints]

[entryPoints.http]
 address = ":80"

[entryPoints.http.redirect]
entryPoint = "https"

[entryPoints.https]
 address = ":443"
[entryPoints.https.tls]
      [[entryPoints.https.tls.certificates]]
      CertFile = "/ssl/server.crt"
      KeyFile = "/ssl/server.key"

[docker]
endpoint = "unix:///var/run/docker.sock"
domain = "example.com"
watch = true
exposedbydefault = false

And docker side, here is my service container conf:
labels:
      - "traefik.network=app-network"
      - "traefik.protocol=http"
      - "traefik.frontend.entryPoints=https"
      - "traefik.port=9000"
      - "traefik.backend=app-main"
      - "traefik.frontend.rule=Host:app-main.docker.localhost"
      - "traefik.frontend.rule=PathPrefix:/,/logo,/avatars,/internal/users/findByEmail,/internal/users,/wsApp" #(I think when / is specified the other paths are useless?)

If applicable, please paste the log output in debug mode (--debug switch)
time="2017-07-06T15:33:12Z" level=debug msg="Writing outgoing Websocket request to target connection: &{Method:GET URL:ws:/wsApp/129/mcmpg5fu/websocket Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Sec-Websocket-Extensions:[permessage-deflate; client_max_window_bits] Sec-Websocket-Version:[13] Sec-Websocket-Key:[ZsG8z67B9AGPSQrzpnD9uw==] Connection:[Upgrade] Accept-Language:[fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4] Upgrade:[websocket] Cookie:[SESSION=a8849fb7-84fe-40a1-a124-7f064cd93422] Cache-Control:[no-cache] Pragma:[no-cache] User-Agent:[Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36] Accept-Encoding:[gzip, deflate, br] Origin:[https://<IP_ADDRESS>]] Body:{} GetBody:<nil> ContentLength:0 TransferEncoding:[] Close:false Host:<IP_ADDRESS> Form:map[] PostForm:map[] MultipartForm:<nil> Trailer:map[] RemoteAddr:<IP_ADDRESS>:60832 RequestURI:/wsApp/129/mcmpg5fu/websocket TLS:0xc4208d49a0 Cancel:<nil> Response:<nil> ctx:0xc4206c16c0}"
time="2017-07-06T15:33:12Z" level=debug msg="Switching protocol failed"

I read no special configuration is required to make websocket working, so I couldn' find any doc on the subject but I can't deal with it...

Already fixed by #1782 😉

Still have the problem...
My service is reachable via http whereas traefik is reachable via https. But when I try to unsecure traefik, the websocket handshake works fine:
           ws                   ws

browser ===> traefik ===> service      OK
           wss                ws

browser ===> traefik ===> service      KO (403 Forbidden)

I can confirm this issue, this is happening on 1.3.4. When using 1.3.3, there aren't any problems.

related to  #1835

@ldez I believe you mean #1900. This is a regression bug since 1.3.4 from the looks of it. Let me know if you need any more information in the form of debug logs; I'd be happy to provide them. 😃

yes mistake 😉
@mvdstam The symptoms you are experiencing differ from those of the original bug submitter.
Your problem (egression bug since 1.3.4) is #1900, @j0hnsmith have a problem with 1.3.2

@johncitron can you try with latest version (1.3.7) ?
Thx

I'll close the issue due to inactivity but feel free to re-open if needed.


Adjusted file structure for python module

Added file: setup.py
Moved files into subfolder pyaudio_analysis
The module files have to be in a subfolder, called pyaudio_analysis to allow comfortable installation using python setup.py install

This looks useful. Is there still interest in the PR?


Alert when table row drawing

Making a table for listing users. And sometimes started alert(1) display.
After some debugging time found that one of objects in array contain:
{
      "ObjectId":"5966996c-0186-412d-911f-8b2a22e775fe",
      "IdClientProfile":10099,
      "Organization":"<script>alert(1);</script>",
      "Department":"department_775.756",
<EMAIL_ADDRESS>}

And when we switch to page with that row, or searching and row in search results - will be alert in browser window. That's valid JSON, but I think this is bug.

P.S.: Using jquery 1.11.3 and dataTables 1.10.7

Hi,
Could you clarify what you would expect the correct behaviour to be? To my mind this looks correct as it is at the moment - you are telling the table to insert a script tag that performs an action - it does that. If you don't want that, the HTML should be suitable escaped.

I expect that in table cell will be <script>alert(1);</script> text and nothing from raw data will be executed (now alert executed and table cell is empty)

In that case you need to escape the HTML - i.e. use <script>alert(1);<script>. DataTables writes to the cell using innerHTML - hence why you are seeing what you are. If it did not do that it would be impossible to inject complex HTML into the table cells.
Going to close this issue as it is working as I would expect.


How do you import this?

Installation and usage are shown, but how is it imported?

Hi @deltaGPhys, good catch! I'll update the documentation to address this. To answer your question from the demo app:
Import this library as:
https://github.com/ajitzero/ng-auto-animate/blob/2a576d9314dda0ac1126f55403854f3deae3f9a0/apps/demo/src/app/app.component.ts#L5
The directive is exported as NgAutoAnimateDirective and must be included in your component's imports array (or app.module, etc.):
https://github.com/ajitzero/ng-auto-animate/blob/2a576d9314dda0ac1126f55403854f3deae3f9a0/apps/demo/src/app/app.component.ts#L21
Extra imports, if you need them, from the original library: (This is not an exhaustive list)
https://github.com/ajitzero/ng-auto-animate/blob/2a576d9314dda0ac1126f55403854f3deae3f9a0/apps/demo/src/app/app.component.ts#L4

In general, I suggest exploring the demo app's source code for specific concerns and let me know if you feel there's anything else we're missing. Source link: https://github.com/ajitzero/ng-auto-animate/tree/main/apps/demo/src


feat: add start and end G-code command options

Usefull to turn on/off relay/power supply only once.
I would prefer to use multi line text fields on the dialog but this is a new feature from Inkscape 1.0 and would not be compatible with previous versions.

The feature is actually already there but not documented. Just add "header" and "footer" files(txt file without extension) in your destination directory

Ok great thank you for your answer !

Should I close this issue and we could add some documentation or do you think this can be usefull on the GUI ?

For information, using header and footer files, there are two lines missing at the exported GCODE :

G90 after header lines (Absolute position)
G1 X0 Y0 after footer lines (Move to X0 Y0)


Parse errorunknown at-rule in stylesheet context: @keyframes

See https://developer.mozilla.org/en-US/docs/Web/CSS/@keyframes for a description of this CSS feature.
test.css:
@keyframes identifier {
    0% { top: 0; left: 0; }
    30% { top: 50px; }
    68%, 72% { left: 50px; }
    100% { top: 100px; left: 100%; }
}

test.py
import tinycss

parser = tinycss.make_parser('page3')
ss = parser.parse_stylesheet_file('test.css')
print(ss.errors)

$ python3 test.py
[ParseError('Parse error at 1:1, unknown at-rule in stylesheet context: @keyframes',)]

tinycss unfortunately needs to be modified for every new kind of rule you might want to add. (There is an extension mechanism, but it’s not great.)
I recommend using tinycss2 instead, which was designed to fix this: you get an AtRule object that you can parse yourself. Something like:
for rule in parse_stylesheet(...):
    if rule.type == 'at-rule' and rule.lower_at_keyword == 'keyframes':
        name =  parse_one_component_value(rule.prelude)
        if name.type != 'ident':
            continue
        name = name.lower_value
        for keyframe in parse_rule_list(rule.content):
            if keyframe.type != 'qualified-rule'
                continue
            # You get the idea…

Look at that! I gave basically the same answer last year in #6.


Can't run on M1 macOS

Describe the bug
cargo install binsider
Expected behavior
compile with no error.  yet got this error:
Some errors have detailed explanations: E0308, E0425, E0432, E0599.
Software information

Operating system: macOS
Rust version: 1.8.2
Project version: 0.2.1

Additional context
brew install binsider succesfully, but can't launch it:
ELF parse error: Invalid Magic Bytes: [CF, FA, ED, FE]``

Are you sure you are running binsider on an ELF file? See #20


Feature: Allow custom Emoji data sources

The used emoji database is always found on the XDG config path, but if it could be overridable with an environment variable, one could create their own Rofi invocations to load only some subsets of Emojis.
Some examples:
# Only show People & Body emojis
ROFI_EMOJI_FILE=<(grep "People & Body" /usr/share/rofi-emoji/all_emojis.txt) \
  rofi -modi emoji -show emoji

# Only show my favorite emojis
ROFI_EMOJI_FILE=~/.local/share/emojis.txt \
  rofi -modi emoji -show emoji

This will also require some more robust parsing and escaping of the data as right now it's assumed to be well-formed (and if it's damaged, then it's not a problem if the output looks weird since you're not supposed to muck around with the file).

Empty files should show some empty state
Files that cannot be parsed should show some error message

This is implemented using CLI arguments inside #44.


How does it work with vue-class-component?

When creating a project with the latest version of the vue cli (4.5.7), you can select jsx, typescript, or vue-class-component to create the project together, but errors are generated in the project.

ERROR in src/views/Home.vue:4:1
TS1238: Unable to resolve signature of class decorator when called as an expression.
  Type 'VueConstructor<Vue<unknown, never[], {}>>' is not assignable to type 'typeof Home'.
    Construct signature return types 'Vue<unknown, never[], {}>' and 'Home' are incompatible.
      The types of 'render' are incompatible between these types.
        Type '(() => void | VNode<RendererNode, RendererElement, { [key: string]: any; }>) | undefined' is not assignable to type '() => boolean'.
          Type 'undefined' is not assignable to type '() => boolean'.
    2 | import { Options, Vue } from "vue-class-component";
    3 |
  > 4 | @Options({})
      | ^^^^^^^^^^^^
    5 | export default class Home extends Vue {
    6 |   render(){
    7 |     return (

ERROR in src/views/Home.vue:4:2
TS2345: Argument of type 'typeof Home' is not assignable to parameter of type 'VueConstructor<Vue<unknown, never[], {}>>'.
  Types of property 'prototype' are incompatible.
    Type 'Home' is not assignable to type 'Vue<unknown, never[], {}>'.
      Type 'Home' is not assignable to type 'ClassComponentHooks'.
        The types returned by 'render()' are incompatible between these types.
          Type 'boolean' is not assignable to type 'void | VNode<RendererNode, RendererElement, { [key: string]: any; }>'.
    2 | import { Options, Vue } from "vue-class-component";
    3 |
  > 4 | @Options({})
      |  ^^^^^^^^^^^
    5 | export default class Home extends Vue {
    6 |   render(){
    7 |     return (

ERROR in src/views/Home.vue:6:3
TS2416: Property 'render' in type 'Home' is not assignable to the same property in base type 'Vue<unknown, {}, {}>'.
  Type '() => boolean' is not assignable to type '() => void | VNode<RendererNode, RendererElement, { [key: string]: any; }>'.
    Type 'boolean' is not assignable to type 'void | VNode<RendererNode, RendererElement, { [key: string]: any; }>'.
    4 | @Options({})
    5 | export default class Home extends Vue {
  > 6 |   render(){
      |   ^^^^^^
    7 |     return (
    8 |
456

    9 |     )

ERROR in src/views/Home.vue:8:10
TS2304: Cannot find name 'div'.
     6 |   render(){
     7 |     return (
  >  8 |
456

       |          ^^^
     9 |     )
    10 |   }
    11 | }

The Vue3 will not support class API. Please use Composition-API.


[Bug]: CodeMagic Android build error

Platform
CodeMagic Android sdk 34
Plugin
android_intent_plus, connectivity_plus
Version
android_intent_plus 5.0.2, connectivity_plus 6.0.2
Flutter SDK
stable 3.19.5
Steps to reproduce
Updated the plugin to v5 and some other plugins, and now codemagic builds fail. Works on my machine (Mac Mini M1 14.4.1)
I tried downgrading the plugin to v4, it gets the same error but for connectivity_plus
Maybe related: https://github.com/fluttercommunity/plus_plugins/issues/2251
Code Sample
No response
Logs
== Building for Android ==

> flutter build apk --release --dart-define FLUTTER_APP_FLAVOR=prod --no-tree-shake-icons

Running Gradle task 'assembleRelease'...
Checking the license for package Android SDK Platform 34 in /usr/local/share/android-sdk/licenses
License for package Android SDK Platform 34 accepted.
Preparing "Install Android SDK Platform 34 (revision: 3)".
"Install Android SDK Platform 34 (revision: 3)" ready.
Installing Android SDK Platform 34 in /usr/local/share/android-sdk/platforms/android-34
"Install Android SDK Platform 34 (revision: 3)" complete.
"Install Android SDK Platform 34 (revision: 3)" finished.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':android_intent_plus:compileReleaseJavaWithJavac'.
> error: invalid source release: 17

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 23s
Running Gradle task 'assembleRelease'...                           84.8s
Gradle task assembleRelease failed with exit code 1

Build failed :|
Failed to build for Android

### Flutter Doctor

```shell
Cant get it from codemagic

Checklist before submitting a bug

[X] I searched issues in this repository and couldn't find such bug/problem
[X] I Google'd a solution and I couldn't find it
[X] I searched on StackOverflow for a solution and I couldn't find it
[X] I read the README.md file of the plugin
[X] I'm using the latest version of the plugin
[X] All dependencies are up to date with flutter pub upgrade
[X] I did a flutter clean
[X] I tried running the example project

I have really high doubts that you really did any of items that you checked before opening this issue. There were a few issues on this topic already in this repo, not to mention numerous other repos and it can be Googled right away.
This is not related to the plugin, but your Codemagic setup. There is even
Won't share the link to the solution as believe it is a disrespect of other people's time to claim that you did something while in reality you didn't.

I spent many hours googling and trial and erroring before making this issue. I also linked the similar issue in this repo. I would be really thankful if you could share the link to the solution.

I spent many hours googling and trial and erroring before making this issue

Sorry, but I still don't believe in this.
https://github.com/juliansteenbakker/mobile_scanner/issues/922#issuecomment-1914432008


Fixed window and tile resizing/scaling issue

Fixes #3 and fixes #7 :)

Can you make some upding screenshots showing how it looks, perhaps in the middle of the game?  Maybe even add on to the pull request to replace the one currently shown in the readme.md

@scottmc, I have the screenshots, but I have no idea how you put them on README.md :(
What do I do?

for now, just add the screenshot.png to the root of the source code and from there I can then add it into the readme

Okay @scottmc :)

~/tmp/Haiku2048> make
mkdir -p objects.x86-cc2-release; \
mkdepend  -I./  -Iobjects.x86-cc2-release/ -p .cpp:objects.x86-cc2-release/%n.o -m -f "objects.x86-cc2-release/WindowBoard.d" WindowBoard.cpp
g++ -c WindowBoard.cpp  -I./  -Iobjects.x86-cc2-release/ -I-   -O3    -o "objects.x86-cc2-release/WindowBoard.o"
/boot/home/tmp/Haiku2048/WindowBoard.cpp: In method `void GameWindow::FrameResized(float, float)':
/boot/home/tmp/Haiku2048/WindowBoard.cpp:189: implicit declaration of function `int SetScale(...)'
/boot/system/develop/etc/makefile-engine:291: recipe for target 'objects.x86-cc2-release/WindowBoard.o' failed
make: *** [objects.x86-cc2-release/WindowBoard.o] Error 1

Ooof. I didn't notice until now. The "SetScale" function should be "ScaleBy" in WindowBoard.cpp,  method GameWindow::FrameResized. I'm really sorry to cause all this chaos :(


Direct installation with Pip from Github

In the README, you can add
pip install git+git://github.com/KordingLab/spykes

as a way to install directly (does the clone step in the background).

good idea
+1


Make PSM ToString code more maintainable

I don't really understand how an array of strings is more maintainable than the tab-separated header; I get that it's difficult to line the header up with the value but I don't think this makes it any easier?

I think the ideal would be a dictionary where the keys are static and the values are object-specific but I'm not sure that's possible

The arrays got rid of the "\t" anywhere and everywhere. I like this idea about the dictionaries.


JBPM-5492 - Timer does not retry after failure in another node

depends on https://github.com/droolsjbpm/drools/pull/1050

jenkins retest this

jenkins retest this

jenkins retest this

changed it back to default timeout value ... build triggered again


Provide a DOM creation option

It would be nice for simdjson to allow a stage 3 for creation of a DOM, like rapidjson and others do. also, i wonder if benchmarking that against rapidjson would be more accurate

perhaps it doesn't need to be split out into a stage 3, integration in stage 2 could be faster. but the general idea is just to create a DOM

To be clear, here is what I mean by DOM: an ordered tree structure where each node (value, object, array) in the JSON document is accessible via an API.  In this sense, the result of the parsing in simdjson is a DOM. Our API is quite similar to RapidJSON and others (and we are implementing JSON pointers, and other features). In some ways, our core API is arguably superior to that of RapidJSON.
The main difference with RapidJSON is that it is a static DOM (that cannot be manipulated). The backend of RapidJSON works much like we do... it does memory allocation in block, which is basically equivalent to our tape structure.
Evidently, RapidJSON has more features as it is not solely a parser, but a whole framework to handle JSON, whereas simdjson is mostly just a parser.
Even so, our current tape data structure could 'easily' be replaced by some other data structure. E.g., it would be possible to plug simdjson in RapidJSON... the main reason that this is difficult is that RapidJSON does not support a pluggable parser.
I am going to close this issue. Please reopen it if you think it holds by making it more precise.
I think that what you mean is that simdjson should produce a mutable DOM.

The following commit should help clarify the issue...
https://github.com/lemire/simdjson/commit/abdf81b39b3b4116ee570cc4ef1731163685c5cd
We have a full DOM with iterators, and JSON Pointer support is upcoming.

Yes, this issue is a mistake due to a few misunderstandings of mine. I was under the impression that RapidJSON uses a hash for dictionaries to go from key -> value. I then thought that that was the standard way to do DOM parsing. Instead, it appears to use an array structure like simdjson does. Thank you for the clarification.
It is interesting that they both use array structures, as random access (which is what, e.g., swift's Decodable protocol requires) is O(n). If the client puts the object's member fields in the same order as the json dictionaries do, then it can be fast anyways. Otherwise, it could use a hash, or something like a trie generated for each type that traverses using the key and has nodes as offsets to where the data is within a dynamically generated struct.

By random access I mean lookup by key

Yes, I understand what you mean.
The big-O analysis only works if n is large. If you have JSON objects with 100 keys, then... yes, this becomes a concern. But my experience with JSON is that this is not common. There are usually few keys.
A hash table can be slower than array if there are few keys. It will certainly use more memory and be have more overhead.
So far, all tests I have run suggests that querying the DOM in simdjson or RapidJSON is super fast... much, much faster than parsing the DOM.
You are right though this aspect of the problem needs to be better studied and documented... however, we have work to do in simdjson to optimize better even the current design.


Hovering the gray circle breakpoint in the editor does not show warning message about not being able to set bks

Testing #150664

Create a file named one.js

console.log('1234')

function hellothere(){
	const x = require('./two.js');
	x.saySomething();
}

hellothere();

Create a file named two.js

exports.saySomething = function () {
  console.log("Said somethign");
  return "1234";
};

Add a break point to the last line hellothere in one.js
Add a breakpoint to the secod line (inside saySomething fn) in two.js
Start debugging
The warning icon appears as expected and displays the right message
However the following does not work
Hovering the gray circle breakpoint in the editor shows the same message

It works for me

Are you sure?

Oh wait you meant in the editor, i thought you were referring to the grey circle against the bk in the bk panel.
Works as expected


3.5.1 breaks simple_fields_for for custom form objects

Environment

Ruby 2.5.0
Rails 5.1.4
Simple Form 3.5.1

Current/ expected behavior
Prior to 3.5.1, I was able to build my own form objects using http://dry-rb.org/gems/dry-types/ . It is looking something like
class CategoryForm < DryTypes::Model
  attribute :names, DryTypes::Strict::Array.member(DryTypes::Translation)
end

and
  = simple_form_for category_form do |f|
    = f.simple_fields_for :names do |name_fields|
      - name = name_fields.object
      = name_fields.input :value, label: "Name (#{name.language.name})"

After the update, name_fields.object returns nil and breaks my code. Does somebody have a hint which change could have caused the issue?

Probably because object gets converted into to_model in 3.5.1 My SimpleDelegator decorators are broken too in 3.5.1 so freezing to 3.5.0

It seems we have a similar problem, if we have a wrapped model (presenter using SimpleDelegator) then object.form returns the model, not the wrapped model.
StudyAssignmentPresenter.new(StudyAssignment.new).class # => StudyAssignmentPresenter
StudyAssignmentPresenter.new(StudyAssignment.new).to_model.class # => StudyAssignment

The PR introducing the call to to_model is here: https://github.com/plataformatec/simple_form/pull/1256

I can confirm that reverting the change from https://github.com/plataformatec/simple_form/pull/1256 fixes the problem for me!

@lacco does adding def to_model; self; end to CategoryForm work? You could also consider include ActiveModel::Conversion.
/cc @timurvafin

Actually I am already providing to_model to make use of Rails automatisms to guess URL, HTTP method, ... : def to_model; category; end. I am sure that def to_model; self; end should solve my problems with simple_form, but I would rewrite the other code.

You are right, now we have to implement #to_model if we are using a PORO or Object that doesn't repond to it - BTW, it is the same behavior of form_for.
This information should be included in the releases notes, sorry about that 😥 . I will add some documentation about it.
Thank you folks.

@lacco just for curiosity. Does DryTypes::Model implements #to_model and other Active Model methods or you are expliciting it in the form?

@felipegimenesptec You are correct, my DryTypes::Model implementation is aware of ActiveModel features, the implementation looks roughly like this:
class DryTypes::Model < Dry::Struct
  include ActiveModel::Conversion
  include ActiveModel::Validations
  extend ActiveModel::Naming

  # This is actually overwritten to def to_model; category; end in my case
  def to_model
    self
  end

  def persisted?
    to_model == self ? false : to_model.persisted?
  end
end

I don't understand why this issue is closed, can you provide any context?  Apps that break in a patch-level upgrade from 3.5.0 to 3.5.1 seems like it must be a bug?  I would consider it a bug for patch-level release to ever include breaking changes...

I consider it a bug fix since Simple Form should work as a Rails Form like form_for do and it wasn't.

I guess it isn't a breaking change since it doesn't break any features described in the README. The fact it supported non-ActiveModel compliant objects was an unintentional feature and strictly speaking a bug since that meant it did not have parity with form_for, which is what the patch fixed.
It is just a bit unfortunate.


Update comment with example for translateJ2objcLibs fixes #258

For the example, it should be a subset of the existing J2objc libs. You'll never put "my library" there. So it should be something like:
translateJ2objcLibs = ["jre_emul.jar", "javax-inject.jar", ...]
It's important that the example be as close as possible to how people are likely to use it.

For example:
translateJ2objcLibs = ["j2objc_junit.jar", "jre_emul.jar"]

@brunobowden thanks for the advice.

fixed


fix: stepfunction stop_execution

Fixes #2846
Calling stop_execution on a stepfunction should set the status to ABORTED not SUCCEEDED.

Coverage remained the same at 94.293% when pulling bb8d4180540602088e24f5cd6ce90eeb52f6e4fb on ConstantinoSchillebeeckxSimpleRose:fix/stepfunction_stop_execution into 95e95cc97d122d1f5efa38032147e1a17dce1564 on spulec:master.


implement shr, mul & div for i128

Partially fix https://github.com/MaxGraey/as-bignum/issues/35

I thought the test failures were due to my pr but they were already present last pr (cf https://github.com/MaxGraey/as-bignum/pull/81)

Please sync with main branch and update deps. Latest commit should fix test runner

Thanks!


Manual (FreeBSD) Instructions

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
Following wiki instructions and issuing "service teslamate start". Fails cube.control extenion control file. Unable to access teslamate service at locahost:4000.
Expected Behavior
No response
Steps To Reproduce
No response
Relevant log output
warning: a term is constructed, but never used
  usr/local/src/teslamate/_build/prod/rel/teslamate/lib/teslamate-1.25.0/priv/repo/migrations/20190925182253_add_geofence_id_to_addresses.exs

2021-12-16 07:09:44.963 [info] == Running<PHONE_NUMBER>2807 TeslaMate.Repo.Migrations.CreateGeoExtensions.change/0 forward
2021-12-16 07:09:44.965 [info] execute "CREATE EXTENSION IF NOT EXISTS cube"
** (Postgrex.Error) ERROR 58P01 (undefined_file) could not open extension control file "/usr/local/share/postgresql/extension/cube.control": No such file or directory
    (ecto_sql 3.7.1) lib/ecto/adapters/sql.ex:760: Ecto.Adapters.SQL.raise_sql_call_error/1
    (elixir 1.11.4) lib/enum.ex:1411: Enum."-map/2-lists^map/1-0-"/2
    (ecto_sql 3.7.1) lib/ecto/adapters/sql.ex:852: Ecto.Adapters.SQL.execute_ddl/4
    (ecto_sql 3.7.1) lib/ecto/migration/runner.ex:343: Ecto.Migration.Runner.log_and_execute_ddl/3
    (ecto_sql 3.7.1) lib/ecto/migration/runner.ex:117: anonymous fn/6 in Ecto.Migration.Runner.flush/0
    (elixir 1.11.4) lib/enum.ex:2193: Enum."-reduce/3-lists^foldl/2-0-"/3
    (ecto_sql 3.7.1) lib/ecto/migration/runner.ex:116: Ecto.Migration.Runner.flush/0
    (ecto_sql 3.7.1) lib/ecto/migration/runner.ex:280: Ecto.Migration.Runner.perform_operation/3

Screenshots
No response
Additional data
No response
Type of installation
Manual
Version
1.25.0

Verified postgresql13-server port does not include cube.control extension by default. Still investigating the reason. https://cgit.freebsd.org/ports/tree/databases/postgresql13-server/pkg-plist-server

Additional control files available under postgresql13-contrib in ports tree. Will issue pull request with instructions if I get everything working.


The value range are only for 0 to 10?

I used multi-slider and set the value for example [20,50], bit it doesn't work, it only work when I set value [0.10] or [3,7] .., so it seems the value   range are limited in 0~10 ?

Have you tried passing in the props, min, max, step?
These are by default
    step: 1,
    min: 0,
    max: 10,

@tsaohucn
Did you get it up and running?

@ptomasroos , I set  the props, min, max, step, and it work now, thanks, but is there any document describe the API information ?

Will add to the readme. Feel free to send a pr.
Otherwise the runnable example.
Glad it worked out!

I have same issue with multi slider,  I set value  [0, 100000000]
step: 1,
min: 0,
max: 100000000,
The app crash

Aouch! Never tried it with 100000000, feel free to send a PR if you can get it working! Just edit the component in your node modules! @fauzzi

@fauzzi FACING SAME ISSUE.

@fauzzi Same happened with me. How were you able to correct? Is there any addition for big max value till now @ptomasroos


New component

Please, add react-native-blur: https://github.com/Kureev/react-native-blur to the list

Thank you @Kureev, it should be there now :+1:


Can't compile locally using Windows preview

Official Meteor support for Windows is right around the corner and I'm testing the preview they've published. I've encountered an error when adding fourseven:scss as a local package - I get the following error:
While loading plugin `scss` from package `scss`:

C:\Git\MeteorDataTool\meteor\packages\scss\.npm\plugin\scss\node_modules\node-sass\lib\index.js:21:11:
`libsass` bindings not found. Try reinstalling `node-sass`?
at getBinding
(C:\Git\MeteorDataTool\meteor\packages\scss\.npm\plugin\scss\node_modules\node-sass\lib\index.js:21:11)
at Object.<anonymous>
(C:\Git\MeteorDataTool\meteor\packages\scss\.npm\plugin\scss\node_modules\node-sass\lib\index.js:211:23)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object._.extend.Npm.require
(C:\Users\Fredrik\AppData\Local\.meteor\packages\meteor-tool\1.1.0-winr.0\mt-os.windows.x86_32\tools\bundler.js:1331:22)
at Package (packages/scss/plugin/compile-scss.js:2:1)
at <runJavaScript-80>:119:4
at <runJavaScript-80>:126:3

The relevant line probably being libsass bindings not found. Try reinstalling node-sass?
While this is an error thrown by node-sass and not fourseven:scss, it seems to be an issue specifically when node-sass is installed by Meteor, since I can install it elsewhere on my system using just npm and it works fine.
I'd be happy to help fix this, but I was wondering if you (or anyone) has an idea of what could cause this problem?

Honestly, the platform specific build chain doesn't support windows yet - so I'm not surprised that the released packages don't support it. Are their build boxes for windows in beta?

Nope, no build boxes yet. I suppose you have a point, they haven't said anything about what they intend to do with binary packages for Windows, so there might be further support for that in the works.
But still, a lot of npm packages do compile properly when wrapped in a Meteor package, so I thought I'd raise the question to see what to make of it in this case

I'll have a poke around this week and see what I can find. Which version of the scss package are you installing?

Cool! I downloaded the repo at the latest version (2.0.0-beta2 at the time, I believe) and added it as a local package.

I tried raising a general question around binary packages and Windows in the windows preview issue tracker, but haven't gotten any response there yet.

It seems that the node binary that comes bundled with Meteor is 32-bit. I'm not sure whether this is what causes the problem, but at the same time I can see that the node-sass package seems to be downloading libsass bindings for 64-bit (which is what my OS, which is Windows 8.1 btw, is running).

I get as well

While checking for<EMAIL_ADDRESS>error: No compatible build found

I have a Windows machine. How can I help?
BTW there have been some updates in https://github.com/meteor/windows-preview/issues/45

The Meteor team published a release candidate (0.3.0) the other day, and some advice for packages with binary dependencies as well as regarding generally publishing packages cross platform. Have you had a chance to try to publish the package with the latest Meteor?

I'll have a look this weekend. I got very burned by this last time I tried (hence why there's a 2.0.1_2 and 2.0.1_3 release) so I'll see how it goes this time around.

Since it's starting to gain traction, here's where it's failing now. https://github.com/meteor/windows-preview/issues/108 - This is a WIP, hope to have a working version eventually.

Actually make that https://github.com/meteor/windows-preview/issues/105

Hah just realised we'd be discussing the same issue @fredrikekelund - do you have a windows box to test<EMAIL_ADDRESS>If it works I will close this (it's published, don't have a windows box handy though).

Haha yeah, I've been eager to see this fixed.
It works, both downloading it and using it :tada: Actually it works even if I'm using<EMAIL_ADDRESS>to run the app

Works for me now. Thanks!

Cool :balloon: