Invalid python code like x2+2-3 without red squiggle.

Environment data

Build of Visual Studio Code - Insiders: 1.92.0-insider
Build of python-insider: v2024.13.2024073102 (pre-release)
Build of pylance-insider: v2024.7.104 (pre-release)

Code Snippet

x2+2-3

Repro Steps

Open a new python file.
Type invalid python into it. Like x2+2-3 on a single line.
Verify you get a red squiggle.

Expected behavior
Get a red squiggle.
Actual behavior

Logs

Output for Python Language Server in the Output panel

2024-08-01 08:52:18.598 [info] (Client) Pylance async client (2024.7.104) started with python extension (2024.13.2024073102)
2024-08-01 08:52:20.933 [info] [Info  - 8:52:20 AM] (22824) Server root directory: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist
2024-08-01 08:52:20.933 [info] [Info  - 8:52:20 AM] (22824) Experimental Pylance language server 2024.7.104 (pyright version 1.1.373, commit ee424479) starting
2024-08-01 08:52:20.933 [info] [Info  - 8:52:20 AM] (22824) Starting service instance "Folder5"
2024-08-01 08:52:20.963 [info] [Info  - 8:52:20 AM] (22824) Setting pythonPath for service "Folder5": "C:\Python310\python.exe"
2024-08-01 08:52:20.964 [info] [Info  - 8:52:20 AM] (22824) Setting environmentName for service "Folder5": "3.10.11 (global)"
2024-08-01 08:52:20.964 [info] [Info  - 8:52:20 AM] (22824) No include entries specified; assuming c:\Users\vting\Downloads\Folder5
2024-08-01 08:52:20.965 [info] [Info  - 8:52:20 AM] (22824) Auto-excluding **/node_modules
2024-08-01 08:52:20.965 [info] [Info  - 8:52:20 AM] (22824) Auto-excluding **/__pycache__
2024-08-01 08:52:20.965 [info] [Info  - 8:52:20 AM] (22824) Auto-excluding **/.*
2024-08-01 08:52:21.118 [info] [Info  - 8:52:21 AM] (22824) Assuming Python version 3.10.11.final.0
2024-08-01 08:52:21.347 [info] [Info  - 8:52:21 AM] (22824) Found 1 source file
2024-08-01 08:52:21.552 [info] [Info  - 8:52:21 AM] (22824) Background analysis(1) root directory: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist
2024-08-01 08:52:21.552 [info] [Info  - 8:52:21 AM] (22824) Background analysis(1) started
2024-08-01 08:52:21.948 [info] [Info  - 8:52:21 AM] (22824) Indexer background runner(2) root directory: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist (index)
2024-08-01 08:52:21.948 [info] [Info  - 8:52:21 AM] (22824) Indexing(2) started
2024-08-01 08:52:22.600 [info] [Info  - 8:52:22 AM] (22824) scanned(2) 20 files over 1 exec env
2024-08-01 08:52:22.938 [info] [Info  - 8:52:22 AM] (22824) indexed(2) 9 files over 1 exec env
2024-08-01 08:52:22.957 [info] [Info  - 8:52:22 AM] (22824) Indexing finished(2).
2024-08-01 08:52:49.923 [info] (22824) No configuration file found.
2024-08-01 08:52:49.923 [info] (22824) No pyproject.toml file found.
2024-08-01 08:52:49.923 [info] [Info  - 8:52:49 AM] (22824) Setting pythonPath for service "Folder5": "C:\Python310\python.exe"
2024-08-01 08:52:49.924 [info] [Info  - 8:52:49 AM] (22824) Setting environmentName for service "Folder5": "3.10.11 (global)"
2024-08-01 08:52:49.924 [info] [Info  - 8:52:49 AM] (22824) No include entries specified; assuming c:\Users\vting\Downloads\Folder5
2024-08-01 08:52:49.924 [info] [Info  - 8:52:49 AM] (22824) Auto-excluding **/node_modules
2024-08-01 08:52:49.924 [info] [Info  - 8:52:49 AM] (22824) Auto-excluding **/__pycache__
2024-08-01 08:52:49.924 [info] [Info  - 8:52:49 AM] (22824) Auto-excluding **/.*
2024-08-01 08:52:50.140 [info] [Info  - 8:52:50 AM] (22824) Assuming Python version 3.10.11.final.0
2024-08-01 08:52:50.140 [info] (22824) Assuming Python platform Windows
2024-08-01 08:52:50.473 [info] [Info  - 8:52:50 AM] (22824) Search paths for file:///c%3A/Users/vting/Downloads/Folder5
2024-08-01 08:52:50.473 [info] [Info  - 8:52:50 AM] (22824)   c:\Users\vting\.vscode-insiders\extensions\ms-python.vscode-pylance-2024.7.104\dist\typeshed-fallback\stdlib
2024-08-01 08:52:50.474 [info] [Info  - 8:52:50 AM] (22824)   c:\Users\vting\Downloads\Folder5
2024-08-01 08:52:50.474 [info] [Info  - 8:52:50 AM] (22824)   c:\Users\vting\Downloads\Folder5\typings
2024-08-01 08:52:50.474 [info] [Info  - 8:52:50 AM] (22824)   c:\Users\vting\.vscode-insiders\extensions\ms-python.vscode-pylance-2024.7.104\dist\typeshed-fallback\stubs\...
2024-08-01 08:52:50.474 [info] [Info  - 8:52:50 AM] (22824)   c:\Users\vting\.vscode-insiders\extensions\ms-python.vscode-pylance-2024.7.104\dist\bundled\stubs
2024-08-01 08:52:50.474 [info] [Info  - 8:52:50 AM] (22824)   c:\Python310\DLLs
2024-08-01 08:52:50.474 [info] [Info  - 8:52:50 AM] (22824)   c:\Python310\Lib
2024-08-01 08:52:50.474 [info] [Info  - 8:52:50 AM] (22824)   c:\Python310
2024-08-01 08:52:50.474 [info] [Info  - 8:52:50 AM] (22824)   c:\Python310\Lib\site-packages
2024-08-01 08:52:50.475 [info] [Info  - 8:52:50 AM] (22824) Adding fs watcher for library directories:
 file:///c%3A/Python310/DLLs
file:///c%3A/Python310/Lib
file:///c%3A/Python310
file:///c%3A/Python310/Lib/site-packages
2024-08-01 08:52:50.475 [info] [Info  - 8:52:50 AM] (22824) Adding fs watcher for directories:
 file:///c%3A/Users/vting/Downloads/Folder5
2024-08-01 08:52:50.475 [info] (22824) Searching for source files
2024-08-01 08:52:50.478 [info] [Info  - 8:52:50 AM] (22824) Found 1 source file
2024-08-01 08:52:50.664 [info] (22824) Attempting to resolve using local imports: __builtins__
2024-08-01 08:52:50.665 [info] (22824) [BG(1)] analyzing: file:///c%3A/Users/vting/Downloads/Folder5/a.py ...
2024-08-01 08:52:50.665 [info] (22824) [BG(1)]   parsing: file:///c%3A/Users/vting/Downloads/Folder5/a.py (103ms)
2024-08-01 08:52:50.737 [info] (22824) [BG(1)]   parsing: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/builtins.pyi [fs read 1ms] (78ms)
2024-08-01 08:52:50.779 [info] (22824) [BG(1)]   binding: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/builtins.pyi (30ms)
2024-08-01 08:52:50.779 [info] (22824) [BG(1)]   binding: file:///c%3A/Users/vting/Downloads/Folder5/a.py (0ms)
2024-08-01 08:52:50.832 [info] (22824) [BG(1)]   checking: file:///c%3A/Users/vting/Downloads/Folder5/a.py ...
2024-08-01 08:52:50.833 [info] (22824) [BG(1)]     parsing: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/typing.pyi [fs read 1ms] (42ms)
2024-08-01 08:52:50.833 [info] (22824) [BG(1)]     binding: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/typing.pyi (7ms)
2024-08-01 08:52:50.845 [info] (22824) [BG(1)]     parsing: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/types.pyi [fs read 0ms] (8ms)
2024-08-01 08:52:50.884 [info] (22824) [BG(1)]     binding: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/types.pyi (14ms)
2024-08-01 08:52:50.884 [info] (22824) [BG(1)]     parsing: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi [fs read 0ms] (7ms)
2024-08-01 08:52:50.884 [info] (22824) [BG(1)]     binding: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi (2ms)
2024-08-01 08:52:50.885 [info] (22824) [BG(1)]     parsing: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/abc.pyi [fs read 1ms] (2ms)
2024-08-01 08:52:50.885 [info] (22824) [BG(1)]     binding: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/abc.pyi (0ms)
2024-08-01 08:52:50.885 [info] (22824) [BG(1)]   checking: file:///c%3A/Users/vting/Downloads/Folder5/a.py (105ms)
2024-08-01 08:52:50.885 [info] [Info  - 8:52:50 AM] (22824) Heap stats: total_memory_size=32768MB, total_free_size=18086MB, total_heap_size=52MB, used_heap_size=44MB, cross_worker_used_heap_size=44MB, total_physical_size=52MB, total_available_size=4050MB, heap_size_limit=4096MB
2024-08-01 08:52:50.885 [info] (22824) [BG(1)] analyzing: file:///c%3A/Users/vting/Downloads/Folder5/a.py (318ms)
2024-08-01 08:52:50.894 [info] (22824) [BG(1)] indexing: file:///c%3A/Users/vting/Downloads/Folder5/a.py [found 0] (0ms)
2024-08-01 08:52:50.894 [info] (22824) Indexing Done: file:///c%3A/Users/vting/Downloads/Folder5/a.py
2024-08-01 08:52:51.056 [info] (22824) Attempting to resolve using local imports: __builtins__
2024-08-01 08:52:51.056 [info] (22824) [FG] parsing: file:///c%3A/Users/vting/Downloads/Folder5/a.py (58ms)
2024-08-01 08:52:51.181 [info] (22824) [FG] parsing: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/builtins.pyi [fs read 4ms] (146ms)
2024-08-01 08:52:51.213 [info] (22824) [FG] binding: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist/typeshed-fallback/stdlib/builtins.pyi (32ms)
2024-08-01 08:52:51.213 [info] (22824) [FG] binding: file:///c%3A/Users/vting/Downloads/Folder5/a.py (0ms)
2024-08-01 08:52:51.214 [info] (22824) pytest configurations: {"message":"script","classes":["Test"],"files":["test_*.py","*_test.py"],"functions":["test"]}
2024-08-01 08:52:51.356 [info] (22824) [BG(1)] SemanticTokens delta previousResultId:1722502341981 at file:///c%3A/Users/vting/Downloads/Folder5/a.py (1ms)
2024-08-01 08:52:51.398 [info] [Info  - 8:52:51 AM] (22824) Indexer background runner(3) root directory: file:///c%3A/Users/vting/.vscode-insiders/extensions/ms-python.vscode-pylance-2024.7.104/dist (index)
2024-08-01 08:52:51.399 [info] [Info  - 8:52:51 AM] (22824) Indexing(3) started
2024-08-01 08:52:51.476 [info] (22824) pytest configurations: {"message":"script","classes":["Test"],"files":["test_*.py","*_test.py"],"functions":["test"]}
2024-08-01 08:52:51.641 [info] (22824) [IDX(3)] scan packages file:///c%3A/Users/vting/Downloads/Folder5 ...
2024-08-01 08:52:51.641 [info] (22824) [IDX(3)]   read stdlib indices (30ms)
2024-08-01 08:52:52.078 [info] (22824) [IDX(3)] scan packages file:///c%3A/Users/vting/Downloads/Folder5 (468ms)
2024-08-01 08:52:52.079 [info] [Info  - 8:52:52 AM] (22824) scanned(3) 20 files over 1 exec env
2024-08-01 08:52:52.419 [info] (22824) [IDX(3)] index packages file:///c%3A/Users/vting/Downloads/Folder5 ...
2024-08-01 08:52:52.419 [info] (22824) [IDX(3)]   index execution environment file:///c%3A/Users/vting/Downloads/Folder5 ...
2024-08-01 08:52:52.419 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/concurrent/__init__.py [skipped: no '__all__' defined] (2ms)
2024-08-01 08:52:52.419 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/distutils/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.419 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/idlelib/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.419 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/lib2to3/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.419 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/pydoc_data/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.420 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/test/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.420 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/turtledemo/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.420 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/urllib/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.420 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/wsgiref/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.420 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/xmlrpc/__init__.py [skipped: no '__all__' defined] (1ms)
2024-08-01 08:52:52.420 [info] (22824) [IDX(3)]     indexing: file:///c%3A/Python310/Lib/site-packages/tzdata/__init__.py [skipped: no '__all__' defined] (2ms)
2024-08-01 08:52:52.420 [info] (22824) [IDX(3)]   index execution environment file:///c%3A/Users/vting/Downloads/Folder5 [found 1522 in 9 files] (26ms)
2024-08-01 08:52:52.420 [info] (22824) [IDX(3)] index packages file:///c%3A/Users/vting/Downloads/Folder5 [found 1522 in 1 exec envs] (86ms)
2024-08-01 08:52:52.420 [info] [Info  - 8:52:52 AM] (22824) indexed(3) 9 files over 1 exec env
2024-08-01 08:52:52.445 [info] [Info  - 8:52:52 AM] (22824) Indexing finished(3).

If you go to your settings.json file, do you have typeCheckingMode set to off?

@ttSpace I am not sure what you meant by invalid. x2+2-3 looks like syntactically valid code. if you are talking about x2 being used before defined. and you want to make it error rather than warning.
you have 2 choice.
in settings.json, you can either change
"python.analysis.typeCheckingMode" to "basic" or "strict"
or set that specific diagnostic as error with typecheckingmode: off
"python.analysis.diagnosticSeverityOverrides": {
        "reportUndefinedVariable": "error"
    },

@StellaHuang95 Yes, the typeCheckingMode is off.

I see, looks like packages\vscode-pylance\package.json and packages\pyright\packages\vscode-pyright\package.json have inconsistent default value.

I will close the issue since it works as expected for off mode.


Code isn't saving on JS challenges

@benmcmahon100 please note that the framework refactor seems to have broken the code saving mechanism just for the showJS views - the showHTML views work fine.

This appears to have been resolved between when this bug was filed and now, so I'm closing it. Please reopen if I've done this in error.


Correctly log elapsed milliseconds in CentralDogmaBeanFactory

Motivation:
When the elapsed time in CentralDogmaBeanFactory#get() is logged, it prints nanoseconds with ms unit.
Modifications:

Convert the elapsed time to milliseconds before logging.

Result:
The logs correctly display the elapsed time of obtaining the initial value.

@KarboniteKream 👍 👍 👍


Unable to create network : invalid cross-device link on chainkit start

I have been trying to start the Chainkit application on my localhost.
The build is working okay so far. But when I do chainkit start, it throws an error:
✗ unable to create network:
link /home/shikhar/go/src/github.com/fbchain-app/chainkit.yml /tmp/chainkit-network087127657/chainkit.yml:
invalid cross-device link

Is this an issue with application path or something else while building?
Because i don't see any file named as chainkit.yml in /tmp/chainkit-network087127657

Can you give some more data about what you use?
Local system, version of docker, command you type.
I think the file in /tmp is inside the container, that's why you don't see it.

Hey, thanks.
It was in the container itself.

I am facing the same issue. I tried copying the chainkit.yml file to the  tmp/chainkit-networkxxxxxx but it doesn't work because every time I execute chainkit start it spins up a new container which is again missing the 'chinkit.yml'.


KnowRob can't be started via roslaunch after Prolog update

When starting KnowRob via rosrun knowrob knowrob.launch, it gets stuck in urdf_init (has_kinematics_file does not return). I could reproduce this with the current KnowRob master in a clean VM with nothing installed but ROS, Prolog and KnowRob.
This is "caused" by the Prolog update on 30. September, (version 8.2.4 --> 8.4.0, see https://launchpad.net/~swi-prolog/+archive/ubuntu/stable) which was automatically installed via the regular Ubuntu package updates. The old 8.2.4 version of Prolog can't be installed via the official PPA anymore, so I built it from source (https://www.swi-prolog.org/build/unix.html). When that version is used, the problem does not occur anymore --> workaround: Building and installing swi-prolog 8.2.4 from source.
Some things I noticed:

Starting knowrob via rosrun rosprolog rosprolog knowrob works also with swi-prolog 8.4.0. It seems like running the ROS node makes the difference.
It looks like the first holds statement in has_kinematics_file never unifies. swi-prolog constantly occupies one core on my machine and unification never finishes. When starting KnowRob with rosrun rosprolog rosprolog knowrob and manually invoking has_kinematics_file, it returns immediately.

@daniel86 I could pinpoint the problem to this line of code:
https://github.com/knowrob/knowrob/blob/4d7af5484683cf2ff0aedd3b0126ae8c5077e035/src/utility/threads.pl#L204
If I set the time to a negative number, so that thread_get_message fails immediately if it doesn't get a message, KnowRob will start. Weirdly a number bigger than 0 will still result in an lock (the code will not step over this step in the given time). I'm at the moment not sure what the correct fix would be here (also I don't know how this changed by the updated Prolog version).

@benjaminalt This issue should be resolved by this PR: https://github.com/knowrob/knowrob/pull/315
It is just a hotfix and I created a new issue that is more specific to the general issue: https://github.com/knowrob/knowrob/issues/316


Additional checks during pull requests

for PRs that target master or the release branch:

check if the version number was increased
check if the changelog was updated

The checks should not be required to merge the PR. Their purpose is to remind us of those things before we merge.

version numbers are handled via git tags so this should work anyway (we should only generate stable docs from tags)
for other checks we could implement PR templates (example)


Lower resolution: unable to set breakpoints

Issue Type: Bug
My colleague who needs to work in a higher resolution and bigger fonts cannot see the edge on the editor pane where one can click to place breakpoints.
The tabs seems to be under the activity bar. But also when we hide the activity bar and not maximizing the window, the left tab and left part of the editor is also not fully visible.
His screen resolution is 1024*768.

VS Code version: Code 1.42.0 (ae08d5460b5a45169385ff3fd44208f431992451, 2020-02-06T10:51:34.058Z)
OS version: Windows_NT x64 10.0.18363

@JurgenStillaert please confirm that I understand this correctly: the issue is not about "setting breakpoints". The problem is that not all editor tabs are visible if you have more than fit into the window, correct?
In this case you can use horizontal (mouse) scrolling to reach the non-visible editor tabs.

@weinand Just the vertical line where you click to set a breakpoint is not visible or clickable on his screen. There is no scroll bar. As you can see on the first screenshots - without activity bar -, the first tab is only visible less than half (nent.ts), the line numbers are right after the window border.
On the second screenshot - with activity bar -, the tab is more visible (etail.component.ts) and the linenumbers are glued to the activity bar. There should be some space to click for setting and viewing breakpoints.

There are two independent issues:

the half-visible tab is a consequence of too many open tabs and a small screen size. You can scroll the horizontal tab region by scrolling horizontally in that region.
the missing vertical area where you set breakpoints (so called "gutter") only exists, if you can  actually set breakpoints in the underlying file. What type of file is visible in that screen shot?

Ok, the first one is a non-issue.
The second one: it's a typescript file. Same setup as the last pc, on which it is working.

When setting a breakpoint with shortcuts, there is a breakpoint icon in the text, but not in the gutter.

@isidorn it the gutter hidden if there is not enough space?

No the gutter does not get gidden.
@JurgenStillaert can you repro with vscode insiders
https://code.visualstudio.com/insiders/

We've uninstalled VS Code, removed all extensions and settings for the user, re-installed and now the gutter is visible again. We will try to install the extensions again and see if it disappears again.

@JurgenStillaert it might be one of the extensions that disables the gutter.
Make sure that you do not have in your setting file
"editor.glyphMargin": false
If you find reproducable steps let us know and we can reopen.
If it is one of the extension please file the issue against that extension. Thank you


Refactor Traits for Tokio Multithreading in hapi-rs

refactors traits to facilitate multithreading with Tokio. Minor adjustments have been made to ensure thread safety and compatibility with Tokio runtime

Thanks @BerKai97
Looks reasonable, let me run a few tests in the following days and I'll merge it if everything is okay.

Hey, sorry for dragging it for so long. This changes are now in main ! ( I didn't merge your PR directly due to some git conflicts on my side, I manually cherry-picked it)
I'm going to close this PR. Cheers.


Replace userforeignkey with crum?

I noticed the the https://pypi.org/project/django-userforeignkey/ hasn't been updated for 2,5 years, doesn't support Django 2.2 or 3.x and its homepage link leads to https://ks.co.at/ which shows nothing but an invalid ssl certificate warning.
I was checking it out, because in my projects I am using https://pypi.org/project/django-crum/ and was wondering if I should remove that one as having 2 libraries to capture the current request seems a bit overkill.
But it looks like crum might actually be a better choice. Its main purpose is to capture the request and current user, where the other one also added some ORM related stuff. It supports Django 2.2, and 3.x and python 3.6/7/8/9.
What do you think?

Thanks for the suggestion. As we help maintaining https://pypi.org/project/django-userforeignkey/ and it fits our scope we don't consider a switch. Also it seems that the suggested package is no longer maintained.


src/compat-5.3.c:451:42: error: initializer element is not computable at load time [-Werror=pedantic]

With compat-5.3.[ch] from keplerproject/lua-compat-5.3@73fb49f4323a817ef00a88bb33b9c565720556ca I get following error:
gcc -O2 -fPIC -std=c89 -pedantic -Wall -Werror -O0 -g --coverage -D_XOPEN_SOURCE=600 -DPACKAGE_STRING="\"LuaLDAP 1.2.3\"" -DLUA_C89_NUMBERS -I/opt/luaenv/versions/5.1.5/include -I/usr/include -I/usr/include -I../compat/src   -c -o src/lualdap.o src/lualdap.c
In file included from src/compat-5.3.h:419:0,
                 from src/lualdap.c:26:
src/compat-5.3.c: In function 'compat53_load_53':
src/compat-5.3.c:451:42: error: initializer element is not computable at load time [-Werror=pedantic]
   compat53_reader_data compat53_data = { reader, data, 1, 0, 0 };
                                          ^~~~~~
src/compat-5.3.c:451:50: error: initializer element is not computable at load time [-Werror=pedantic]
   compat53_reader_data compat53_data = { reader, data, 1, 0, 0 };
                                                  ^~~~
cc1: all warnings being treated as errors

For details see:

https://circleci.com/gh/lualdap/lualdap/88
https://circleci.com/gh/lualdap/lualdap/89
https://circleci.com/gh/lualdap/lualdap/86

Thanks for the reports.


fix: LEAP-521: Update LSF and DM files on monorepo

PR fulfills these requirements

[x] Commit message(s) and PR title follows the format [fix|feat|ci|chore|doc]: TICKET-ID: Short description of change made ex. fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errors
[ ] Tests for the changes have been added/updated (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] Best efforts were made to ensure docs/code are concise and coherent (checked for spelling/grammatical errors, commented out code, debug logs etc.)
[ ] Self-reviewed and ran all changes on a local instance (for bug fixes/features)

Change has impacts in these area(s)
(check all that apply)

[ ] Product design
[ ] Frontend

Describe the reason for change
(link to issue, supportive screenshots etc.)
What does this fix?
(if this is a bug fix)
What is the new behavior?
(if this is a breaking or feature change)
What is the current behavior?
(if this is a breaking or feature change)
What libraries were added/updated?
(list all with version changes)
Does this change affect performance?
(if so describe the impacts positive or negative)
Does this change affect security?
(if so describe the impacts positive or negative)
What alternative approaches were there?
(briefly list any if applicable)
What feature flags were used to cover this change?
(briefly list any if applicable)
Does this PR introduce a breaking change?
(check only one)

[ ] Yes, and covered entirely by feature flag(s)
[ ] Yes, and covered partially by feature flag(s)
[ ] No
[ ] Not sure (briefly explain the situation below)

What level of testing was included in the change?
(check all that apply)

[ ] e2e
[ ] integration
[ ] unit

Which logical domain(s) does this change affect?
(for bug fixes/features, be as precise as possible. ex. Authentication, Annotation History, Review Stream etc.)

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

Comparison is base (a3e4f43) 68.69% compared to head (f3a5e62) 64.59%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1664      +/-   ##
==========================================
- Coverage   68.69%   64.59%   -4.10%
==========================================
  Files         443      443
  Lines       28721    28721
  Branches     7636     7522     -114
==========================================
- Hits        19729    18553    -1176
- Misses       7748    10168    +2420
+ Partials     1244        0    -1244

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

Everything is up to date


[FIX] Fixes new datetime error in loaders

There is a typo in one of the behavioral CSV files that caused coercion to datetime to error; we're just going to coerce from now on.

Codecov Report

Merging #11 into master will decrease coverage by 0.02%.
The diff coverage is 87.5%.

@@            Coverage Diff             @@
##           master      #11      +/-   ##
==========================================
- Coverage   78.51%   78.48%   -0.03%
==========================================
  Files          11       11
  Lines         512      516       +4
==========================================
+ Hits          402      405       +3
- Misses        110      111       +1

Impacted Files
Coverage Δ

pypmi/tests/test_loaders.py
100% <ø> (ø)
:arrow_up:

pypmi/loaders.py
79.03% <87.5%> (-0.09%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0a726ff...cc8223c. Read the comment docs.


Unable to install on macOS

The installation fails with:
Traceback (most recent call last):
  File "./gyp-mac-tool", line 611, in <module>
    sys.exit(main(sys.argv[1:]))
  File "./gyp-mac-tool", line 28, in main
    exit_code = executor.Dispatch(args)
  File "./gyp-mac-tool", line 43, in Dispatch
    return getattr(self, method)(*args[1:])
  File "./gyp-mac-tool", line 246, in ExecFilterLibtool
    if not libtool_re.match(line) and not libtool_re5.match(line):
TypeError: cannot use a string pattern on a bytes-like object
make: *** [Release/opus.a] Error 1

Full output log: https://pastebin.com/DAjLmR0t
Relevant versions:
macOS High Sierra
node.js v9.6.1
npm v5.6.0
node-gyp v3.6.2
Am I doing something wrong?

This seems like a problem with your development environment. The TypeError is a Python error from node-gyp. Maybe a python version incompatibility? I don't know what the requirements of node-gyp are for Python versions.

Turns out node-gyp only works with Python 2.7 and not 3.X. Changing the global default to 2.7 worked, thanks!


Fix broken link to mocha-opts anchor tag

http://mochajs.org/#mochaopts doesn't work, but http://mochajs.org/#mocha-opts does.

this will be reverted as soon as somebody rebuilds the ToC.  the PR would probably have to go to marked-toc to fix it

i'll accept this PR, but it's a band-aid


quic: delay calling set_max_concurrent_uni_streams/set_receive_window

Delay calling connection.set_max_concurrent_uni_streams() and connection.set_receive_window() to when we know we've accepted the connection. Avoids a short window where the peer could start transmitting even if we're going to drop the connection, and avoids taking the connection mutex and waking a task.

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

Project coverage is 81.9%. Comparing base (86667f5) to head (4a23d31).
Report is 2 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##           master     #904     +/-   ##
=========================================
- Coverage    81.9%    81.9%   -0.1%
=========================================
  Files         853      853
  Lines      231776   231779      +3
=========================================
- Hits       189871   189854     -17
- Misses      41905    41925     +20


Notify

This PR includes:

The implementation of ldns-notify and dnst notify.
Stelline in the env.
Printing version and help from ldns argument parsing.

FYI: ldns-notify supports -v

@mozzieongit do your worst! Give me that great feedback! 😄


OrderWizard : Display Grid

Hey there, i would like to display an existing grid in an order-like wizard (a dropdown is not displaying enough fields so i would like to display the grid so that the user can select a row then switch to next step.
Is that possible Volkan ?
Or maybe use a combination of PickerProduct (to allow 1 selection) then switch to next step in wizard ?

i would love to but even with source code (startsharp) i am not able to do this

If you add an @Serenity.Decorators.editor on your grid, it can be used just like an editor grid, then check enabling selection topic on wiki and samples

Closing due to inactivity.


Fix build errors and warnings

Since the swift-syntax dependency was updated and the PR fixes build errors, it would be nice to release 0.2.0 when it gets merged.

Updated and locked (to avoid unexpected build errors) swift-syntax version
Fixed deprecation warnings
Fixed compilation errors
Fixed tests
Couldn't fix AddAsync/AddCompletionHandler macros, they are called multiple times and produce diagnostic errors, but since it's a showcase I guess it shouldn't be a blocker for fixing compilation errors

Hey Maxim, thanks for the PR! I'll have a look at your changes and then merge if all good, but I've got a deadline today followed by an all-weekend event, so I likely won't get around to fixing the example macros (which I'd like to do before releasing v0.2.0).
For some reason I thought I'd already locked the swift-syntax version which would've avoided those build errors and warnings from appearing 😅 thanks for picking up on that and updating the dependency while you were at it, that'll also save me some time when updating to the stable release of swift-syntax whenever that happens.

I'm actually quite pleasantly surprised about the changes that they've made to swift-syntax since I last used it. The newer API changes make it feel more swifty and consistent.

Yeah, new API feels fancier 😅
Btw I was thinking about updates, it feels kinda important to keep up with the latest swift-syntax version, so it's probably worth making releases with the locked version, but then revert main branch Package.swift file to the default one, so you can get stability for release versions and still notice if something changed when you or someone else who forked the repo opens the package 🤔

Btw I was thinking about updates, it feels kinda important to keep up with the latest swift-syntax version, so it's probably worth making releases with the locked version, but then revert main branch Package.swift file to the default one, so you can get stability for release versions and still notice if something changed when you or someone else who forked the repo opens the package 🤔

Hmm yeah that could be a good idea.
I finally got around to fixing up the tests so I've added the v0.2.0 tag now.

Random fun fact:
I was implementing @AssociatedObject macro for https://github.com/capturecontext/swift-foundation-extensions and I somehow I managed to break the compiler, so now it builds on CI, but I can't compile macros locally 🤡
Hopefully xcode reinstall will help 😅

Lol rip, that's always so annoying when that happens

Well, after hours of searching for workarounds I managed to fix the issue, I simply forgot to declare a compiler plugin type 😅, but the error was not helpful at all 💀

Haha that’s still weird that it didn’t happen in CI 🤔 macro compilation errors could definitely do with some improvement lol


New diff function

New diff function allowing user to control recursion. Ie a leaf diff except not recursing into arrays is more optimal for normalized data.

Naahhh. This would be useful for processing the diff in order to edit a model but when that model comes back into that system that used this diff, the model would be a different shape.
Not needed.


Can't specify port on URL

Thank you again for this awesome plugin.
Following up #29
Now I can use http://, but can't specify the port:
http://localhost:12345/user/repo.git

Gives me the following error:
remote: No such host at :80
fatal: repository http://localhost/12345/user/repo.git/ not found

I don't know much about the implementation, but maybe you could just use the URL given by the user instead of trying to validate it?
Cheers.

Oops. I'll fix that now.
Did you build from source ?

Did you build from source?

Yes

Try again now :)

It's working now. Thank you again.


hash generate with v3.0.4 doesn't be the same with v3.0.5 because node 0.10

In 3.0.4 pbkdf2 generate a hash correctly with digest parameter sha256.
With 3.0.5 pbkdf2 generate a hash silently ignoring 'sha256' and use sha1 instead.

Tape tests doesn't pass with node 0.10.
Pbkdf2 doesn't support node 0.10 anymore ?
If this is the case can we add { "engines" : { "node" : ">=0.12" } } in package.json
This is an important change not being represented in version number :-( ~3.0.4 in my package.json

Indeed @HugoPoi 0.10 was dropped in 3.0.5 due to the version reaching end-of-life as far as support goes.
I'll add { "engines" : { "node" : ">=0.12" } } now.

This is an important change not being represented in version number :-( ~3.0.4 in my package.json

You are also right,  this should have been 4.0.0.
@calvinmetcalf thoughts on path forward?


restart typo removed

shutdown -r now not restart shutdown -r now after setting new swap file.

Thanks for this nice catch! :-)


examples: Add Amazon Linux 2 Disk Image

This PR includes:

example YAML configuration of Amazon Linux 2 on Lima.

As of now (2021-Feb-03):

containerd does not seem to work

stucks at sshfs binary to be installed when containerd installation is enabled
Amazon Linux 2 has yum, but it doesn't have dnf, therefore installation of packages fails (@ https://github.com/lima-vm/lima/blob/67e465e2a57ad673cb41e5c8b51695dc783e401b/pkg/cidata/cidata.TEMPLATE.d/boot/30-install-packages.sh )

legacyBIOS is needed to boot (similar to Rocky Linux)

Amazon Linux 2022 (successor of Amazon Linux 2, current in Preview state) seemingly has dnf, so Amazon Linux 2022 should support containerd.

Signed-off-by: KOSHIKAWA Kenichi <reishoku.misc @ pm.me>

Amazon Linux 2 is based on CentOS 7, which was decided not to be supported due to it's age.
That is probably why sshfs is missing.

https://github.com/lima-vm/lima/pull/344

I agree with @afbjorklund . Let's wait until the release of the 2022 edition.

Can we close this, or should it be moved next to CentOS 7 in the "deprecated" section perhaps?

Amazon Linux 2 end of support date (End of Life, or EOL) has been extended by two years from 2023-06-30 to 2025-06-30 to provide customers with ample time to migrate to the next version.

https://aws.amazon.com/amazon-linux-2/faqs/

Let's close this. Still welcome PR for AL2023.


Could not load file or assembly ''Microsoft.Build

Environment data
dotnet --info output:
~/jigsaw/git/main fixes> dotnet --info
.NET Command Line Tools (2.0.2)

Product Information:
 Version:            2.0.2
 Commit SHA-1 hash:  a04b4bf512

Runtime Environment:
 OS Name:     fedora
 OS Version:  26
 OS Platform: Linux
 RID:         fedora.26-x64
 Base Path:   /usr/share/dotnet/sdk/2.0.2/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

VS Code version:
Version 1.17.2
Commit b813d12980308015bcd2b3a2f6efa5c810c33ba5
Date 2017-10-16T13:57:00.652Z
Shell 1.7.7
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
C# Extension version:
1.13.0 (November 7, 2017)
Steps to reproduce
Load C# project

uname -a
Linux xiaosan 4.13.10-200.fc26.x86_64 #1 SMP Fri Oct 27 15:34:40 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Expected  behavior
OmniSharp works
Actual behavior
OmniSharp does not work at all
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Build, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
File name: 'Microsoft.Build, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at OmniSharp.MSBuild.MSBuildProjectSystem.LoadProject (System.String projectFilePath) [0x00038] in :0
Notes

It was working yesterday.
I have tried the tintoy package but it did not help (same output)

Hi @martinellison -- you have Mono 5.4 installed into Fedora 26, correct? If so, OmniSharp will attempt to use Mono's msbuild. Unfortunately, that is not included in the mono-complete or mono-devel packages. However, you should be able to install it with sudo yum install msbuild. That should get OmniSharp working again.
Note: The FileNotFoundException for Microsoft.Build was fixed earlier today with https://github.com/OmniSharp/omnisharp-roslyn/pull/1016. That should make its way into a new update to C# for VS Code in the next couple of days.

sudo dnf install -y msbuild
worked thanks
Regards,
Martin
On 10 November 2017 at 12:54, Dustin Campbell<EMAIL_ADDRESS>wrote:

Hi @martinellison https://github.com/martinellison -- you have Mono 5.4
installed into Fedora 26, correct? If so, OmniSharp will attempt to use
Mono's msbuild. Unfortunately, that is not included in the mono-complete
or mono-devel packages. However, you should be able to install it with sudo
yum install msbuild. That should get OmniSharp working again.
Note: The FileNotFoundException for Microsoft.Build was fixed earlier
today with OmniSharp/omnisharp-roslyn#1016
https://github.com/OmniSharp/omnisharp-roslyn/pull/1016. That should
make its way into a new update to C# for VS Code in the next couple of days.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OmniSharp/omnisharp-vscode/issues/1852#issuecomment-343374616,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIgNgifo-OmHLAUGVUlSMvBpf_r8VPi8ks5s09b1gaJpZM4QZCWp
.

Great! Thanks!


Fixes Windows specific Unix date formatting bug

Getting Unix time with strftime("%s") will only work on POSIX platforms, so not on Windows. time() is fine for both.

@kipparker Please remove the unnecessary import so I will be able to merge the PR

@pitbulk thanks, removed.


DHN 2019 Copenhagen

[ ] list this workshop on our website

We need to have that listed on our website.

Solved in 8cc0d81a935597044b3ee96729b04166599ba3d1.


Cool theme! Any plans to include a Gruvbox Light version?

Not yet, maybe in the future.

@Vincent-P I just came across this gruxbox theme plugin, been looking for one for a while, would be cool to have a light version as well.


Plugin startup crashes Homebridge

Environment:

Raspberry Pi 3B (Using homebridge image)
Node: v12.18.2
NPM : 6.14.7
Homebridge: 1.1.2

Issue:
I am attempting to hookup 6 lightstrip controllers with this plugin, but homebridge returns the following, and crashes:
(Sorry, it won't let me copy and paste from my phone D:)

Config:
{
    "bridge": {
        "name": "Homebridge 74C0",
        "username": "0E:D5:9C:65:74:C0",
        "port": 51618,
        "pin": "726-16-707"
    },
    "accessories": [],
    "platforms": [
        {
            "name": "Config",
            "port": 8581,
            "platform": "config"
        },
        {
            "pruning": {
                "pruneMissingCachedAccessories": false,
                "restartsBeforeMissingAccessoriesPruned": 3,
                "pruneAllAccessoriesNextRestart": false
            },
            "whiteEffects": {
                "simultaniousDevicesColorWhite": true,
                "colorWhiteThreshold": 10,
                "colorWhiteThresholdSimultaniousDevices": 50,
                "colorOffThresholdSimultaniousDevices": 5
            },
            "deviceManagement": {
                "blacklistOrWhitelist": "blacklist",
                "blacklistedUniqueIDs": [
                    ""
                ]
            },
            "platform": "homebridge-magichome-dynamic-platform"
        }
    ]
}

Troubleshooting:
I have tried:

Updating the plugin
Updating config-ui-x
Clear both persist and cachedAccessories
Ensure all devices are able to be used in local mode

Yes... your "phone".

Yes... your "phone".

Do you mean the screenshots? It's a shortcut lol. I saw an earlier issue about different controller protocols like V2,4, etc. is that the cause of it?

Hey @iRayanKhan, not sure I have anything to add. Just want to say I'm experiencing this issue as well. I'm going to look at any recent changes and see if they might have caused this.

@iRayanKhan wow sorry to leave you hanging with just that reply. Somehow my message didn't get finished. I think I was doing some more research into the issue midway to an actual reply and got sidetracked. I did want to thank you for all that information and the most unique log I've ever received. Appreciate the effort.
Installed my plugin on a new pi and got the same errors as you on first few startups. But it eventually started working smoothly.
Classes started today so I won't get a chance to look at this til the weekend.
@LoganDan The issue is in transport.ts. I do some hacky stuff there to get V9 firmware bulbs to work properly. There are also many warnings in the diff, but I am unclear what they are. Version management is not my strong suit. Any help is appreciated.

Hey, @LoganDan and @iRayanKhan
So I found a bug that was causing the plugin to not wait long enough for the light to reply with a version type. Even worse, it gave a false version type if it got no response. I've updated the plugin to handle this better so if you'd like, give this another try.
Please update in config ui x > plugins > homebridge-magichome-dynamic-platform > update. (!Important!) Next purge all magic-home accessories by going to config ui x > plugins > homebridge-magichome-dynamic-platform > settings > checkmark "Prune All Accessories Next Restart (Warning Dangerous!)" > restart homebridge at least twice > un-checkmark "Prune All Accessories Next Restart (Warning Dangerous!)" > restart homebridge.
Let me know how this goes.

@Zacknetic thanks for your effort! Still same issue for me though, fresh install & no update available as currently on v1.4.3 - is there any more potential issues that could trigger this? Once the plugin is added/installed my homebridge just keeps crashing every few seconds. Never manages to properly keep running. Any ideas would be great help!

@vpiskunov I'd ask for your logs but I think I know what's going on. There are some incompatibilities with the old plugin so if you have magichome accessories associated with the old plugin, they mess things up. Follow these steps:

This is important! Purge all magic-home accessories by going to config ui x > plugins > homebridge-magichome-dynamic-platform > settings > checkmark "Prune All Accessories Next Restart (Warning Dangerous!)" > restart homebridge at least twice
Lastly un-checkmark "Prune All Accessories Next Restart (Warning Dangerous!)" > restart homebridge.

@Zacknetic here's my log anyway (sorry it's a full one, just look for any ECONNRESET)
https://gist.github.com/vpiskunov/32be0c09854e31019a9a8bfd606d6542
I've done all steps word by word, any have a clean install of homebridge with this being the only plugin ever ;) but last step, to un-checkmark I didn't do. Wouldn't expect that to mess it up, as it's a shutdown-time-flag?

Any ideas @Zacknetic? if there's an idea to a fix/pointer I could try getting a PR in. Though I've not explored the repo much yet!

@vpiskunov to be honest you shouldn't need to use a clean install of homebridge. Be sure to purge the accessories the way I explained. What it does is completely remove the magichome accessories. But it will do so every restart if it's not disabled.
Checkmark "prune All Accessories Next Restart " > save> restart
Uncheckmark "prune All Accessories Next Restart " > save > restart
Just to be sure. Because the accessories don't necessarily remove themselves even after a clean homebridge install.

Looking further. That probably won't solve your problem. Could you please send me a link to your controller wherever you bought it? A picture would help.
Is it RGB, RGBW, RGBWW? Is it a strip or a bulb?
I think the wrong protocol is being sent.

Sure - I meant that it's an initial install, which happened after your latest version rollout with the changes above. Just to say I never had it work since the 1st attempt.
The controller is this one: https://www.amazon.co.uk/gp/product/B07KVWT38V

It will definitely work in the magichome app. There are variations to the protocol, that's what may be causing the issue.
A few things;

Any chance you could connect your homebridge server to the same 2.4ghz band as your magichome lights? I see it's connected VIA ethernet

Could you please enable debugging, disable "prune all accessories", run homebridge a few more times and then send me an updated log?

I'm kind of at a loss right now as to why it's not working, but we'll push on.

I'm having similar issues... any update on this? (first time user of this plugin and 'magic home' lights)
Error:
[9/21/2020, 7:57:12 PM] Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:205:27)
[9/21/2020, 7:57:12 PM] Got SIGTERM, shutting down Homebridge...

@johncameron3 No there is no update so far.
Please keep in mind I'm one person maintaining the code for this plugin in my spare time. I do what I can but school / work comes first.
I think the firmware on the GRB devices may have updated the protocol to 9bytes instead of 8. I'm worried if I change this, it will break this plugin for users without the updated firmware version.
I will try it regardless because this may or may not be problem, but it'd be good to confirm.

@Zacknetic appreciate you looking into this & know you’re busy! If it’s a small change for the 9bytes, let me know what to do, and I can apply the change locally in my install, and report on results.
Otherwise perhaps one way would be to make a feature-branch and we could install it thru NPM via git/https clone link to that branch?

Anything I can do to help / test?

@vpiskunov @johncameron3 @LoganDan @iRayanKhan  Making the necessary changes now to the development branch. Standby.

Great @Zacknetic thank you! I have ordered a few more of these devices so I will be able to test them all. Any way I should pull in the dev branch into homebridge? Git URL in npm?

I have updated the master branch. Be sure to purge ALL your magichome accessories either by deleting the accessories folder or using my prune feature. Be sure to turn the prune feature off after you restart.

Updated plugin. Pruned accessories. Still crashing.

Okay then I will revert back and consider my options. Thanks for letting me know.

@jocamero @vpiskunov @LoganDan @iRayanKhan
I have come up with a new version of the plugin that should solve this issue.
Please update your plugin to version 1.5.1 . Note: if you are updating from version 1.4.x you'll need to purge all your magichome devices after updating. Then restart homebridge to rescan.
With help, I found a bug in the code that caused duplicate device to register if the user had multiple subnets. Thus the crash. I was trying to scan on more than one subnet but didn't account for devices showing up on more than one.
Let me know how it goes. Thank you.

Just tested it today @Zacknetic, I get this error crashing home bridge on boot:
[11/3/2020, 11:41:23] [homebridge-magichome-dynamic-platform] ( Modified) Light version: 1 matches known device type records
[11/3/2020, 11:41:23] Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:205:27)
HAP Warning: Characteristic 000000E3-0000-1000-8000-0026BB765291 not in required or optional characteristics for service 00000043-0000-1000-8000-0026BB765291. Adding anyway.
[11/3/2020, 11:41:23] [homebridge-magichome-dynamic-platform]
Registering new accessory 'Simple GRB'
Model: 'AK001-ZJ2131'
Unique ID: 'C82E47604325'
IP-Address: '<IP_ADDRESS>'
Light Version 8
Version Modifier: 51
Protocol Version: 1

[11/3/2020, 11:41:23] [homebridge-magichome-dynamic-platform]
Registered 7 Magichome device(s).
New devices: 4
Cached devices that were seen this restart: 3
Cached devices that were not seen this restart: 0

[11/3/2020, 11:41:23] Got SIGTERM, shutting down Homebridge...
[11/3/2020, 11:41:23] Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:205:27)
[11/3/2020, 11:41:23] Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:205:27)

@jocamero @vpiskunov @LoganDan @iRayanKhan
Please update to version 1.6.2, purge your magichome devices using the built in settings "prune all accessories next restart". Be sure to disable that setting after everything is successfully purged.
I'm fairly confident about this update, but you never know. If things don't work, be sure to upload a sanitized homebridge.log file.
Additionally, you can contact me and other magichome plugin users here at the official MagicHome Discord Server. I am usually much more responsive there.

1.7.4 fixed it for me. Thank you @Zacknetic!

Thank you god.


Wierd particle state after reset the process material in GPUParticle2D

Tested versions
Godot v4.3.dev (89cc635c0)
System information
Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; <IP_ADDRESS>01) - 12th Gen Intel(R) Core(TM) i7-12700F (20 Threads)
Issue description
When trying to debug https://github.com/godotengine/godot/issues/87123, I sometimes notice that after reset the process material, the particle will go crazy like below:

give it the shader for the first time might looks like this:

I admit the shader here is not that valid, but it does look like that some state is not inited well. And even the shader is not good, reset it is supposed to give the correct ( normal )  result.
shader_type particles;

void start() {
	// Called when a particle is spawned.
	USERDATA1 = vec4(1.0f,1.0,1.0f,1.0);
}

void process() {
	// Called every frame on existing particles (according to the Fixed FPS property).
	//TRANSFORM[3] = USERDATA1;
}

See the video below, sometimes I can get the wierd result at the first try:
https://github.com/godotengine/godot/assets/8315986/1c501e0a-329d-4fb3-88c8-bc6ca434c210
Steps to reproduce

Make a GPUParticle2D
Give it a texture
Give it a Shader material and the related shader
reset and re-assign serveral times, observe

Minimal reproduction project (MRP)
GPUParticle2D.zip

I'm seeing the same thing after testing #87123 as well. It looks like (un)commenting the USERDATA1 variable will constantly trigger a different glitch. It also happens with the other USERDATA variables for me.
Closing and reopening the project seems to fix the issue, so I don't think the repro project in the OP will be of much use (also similar to #87123). My guess would be that memory isn't being allocated for USERDATA variables until the initial shader compilation if it does contain that variable, and USERDATA overwrites other particle variables in memory in all other cases.


feat: add feedtime

Codecov Report

Merging #3 (c746934) into master (058796b) will increase coverage by 100.00%.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##           master        #3        +/-   ##
=============================================
+ Coverage        0   100.00%   +100.00%
=============================================
  Files           0         1         +1
  Lines           0         4         +4
=============================================
+ Hits            0         4         +4

Impacted Files
Coverage Δ

src/ZooLib/Utility/FeedTime.cs
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


[build] Enforce module-level code coverage verfication

Motivation
We want to ensure enough unit tests will be written for each new PR and gradually improve code coverage among modules.
Start with a new CI step which verifies each module has met enough line coverages. The threshold is defined per module and we can continue tweaking it as we go.
Note that this PR doesn't introduce new code coverage check, only module-level code coverage check. The former will be done in a later PR.
Testing
 ./gradlew jacocoTestCoverageVerification and the new CI step.
WcTest/7390
For a build that meets the coverage requirements:
https://github.com/linkedin/venice/actions/runs/3852662122/jobs/6564983018
/// no error output

For a build that doesn't meet the coverage requirements:
https://github.com/linkedin/venice/actions/runs/3852887609/jobs/6565384906
Rule violated for bundle da-vinci-client: lines covered ratio is 0.4, but expected minimum is 0.8

Are you planning to skip generated and test classes from the check?

Are you planning to skip generated and test classes from the check?

For the record, I think this commit lists these classes.
Jacoco reports currently included them but they have relatively low percentage compared to our own codes. That being said, I will try to exclude them at later time.


type error

what a great peace of software, made a rainy weekend great!
i have only a liitle issue, each time i press deploy in node-red i get errormessages like this:
30 May 16:53:13 - [error] [homegear-mqtt in:Thermostat] TypeError: done is not a function
30 May 16:53:13 - [error] [homegear-mqtt out:SetTemp] TypeError: done is not a function
any idea what i'm doing wrong?
i'm running the following versions
node v4.4.5
npm 2.15.5
node-red v0.13.4
many thanks
andi

I get the same errors.

Hi, I can confirm these errors and also that they have no influence on the working if the plugin.
I will try to nail the reason down but I at least my node works fine even with these messages on deploy.

I thought it had to do with the way multiple scripts are called in the output node, but I think it's the old jQuery version used, that doesn't allow for this type of callback.

I found the issue, and created a pull request


CMake causes slow eigenvalue decomposition (dsyev, dspgv, etc.)

Hi devs!
Problem description
When compiled by cmake (instead of make), some eigenvalue decomposition functions can be extremely slow. For dsyev, this can be 6x times slower; for test_dsyevd, this can be 2x times slower.
This problem can be easily resolved by using make instead of cmake, but it seems to be too confusing and suspicious for me. It may well be possible that I missed something on how to build OpenBLAS; and hope for any suggestions or thoughts on this.
Timings Evidence
16 cores @ Ryzen 7945HX (Zen4)
Using pthreads for multithreading.
Both cmake and make have the same openblas_get_config output.
openblas_get_config: OpenBLAS 0.3.28 NO_AFFINITY COOPERLAKE MAX_THREADS=16
Compile command:

cmake: cmake .. -DBUILD_SHARED_LIBS=1 -DNO_AFFINITY=1
make: make CC=gcc FC=gfortran NUM_THREADS=16

All problems are 2048 x 2048. For function dspgvx, we only need first 512 eigenvalues and eigenvectors; for other cases, all eigenvalues and eigenvectors are required.

Task
OpenBLAS cmake
OpenBLAS make
MKL 2024.1

dgemm
17.7 msec
19.1 msec
23.4 msec

dsyrk
13.8 msec
11.4 msec
22.9 msec

dsyev
26578.6 msec
4030.9 msec
584.2 msec

dsyevd
728.2 msec
367.2 msec
218.7 msec

dsyevr
1607.9 msec
783.8 msec
688.8 msec

dsyevx
24461.5 msec
3354.8 msec
514.1 msec

dspgv
35749.2 msec
6132.1 msec
1797.2 msec

dspgvd
5466.5 msec
2201.3 msec
1496.6 msec

dspgvx
3965.5 msec
1809.9 msec
1036.5 msec

All results are available from https://github.com/ajz34/issue_openblas_dsyev/tree/fc75b82593224be7c7b0673991cce5b72d24be8a

To avoid environment variable pollution, I also tried on machine on github actions.
It seems to behave similar problem, where functions like dsyev cmake can be extremely slower than that of make.
Configuration for github actions uses USE_OPENMP=1, and OpenBLAS version is 0.3.27.
https://github.com/ajz34/issue_openblas_dsyev/actions/runs/11269032870/job/31336861677

Try adding the -DCMAKE_C_FLAGS="-O2" option when using CMake.

@XiWeiGu This option may be useful, but still seems to be much slower when using CMake, comparing to that of make.
For github action, time of dsyev/dsyevx/dspgv are not decreased, after adding -DCMAKE_C_FLAGS="-O2", some timing evidence can be retrived from the following link.
https://github.com/ajz34/issue_openblas_dsyev/actions/runs/11269032870/job/31336861677
On my computer, these functions are faster by about 20% when using CMake, but still 4x-5x times slower than that of make.

Possible solution
-DCMAKE_Fortran_FLAGS="-O3" or any other effective Fortran compiler flags works.

I think it is somehow confusing, that cmake and make have different compiling flags by default. I guess this may not affect most BLAS functions, but can affect some Lapack functions.
I think set both CFLAGS and FFLAGS to be at least -O2 in cmake will be helpful for (not so advanced) users.

@martin-frbg Reply of https://github.com/OpenMathLib/OpenBLAS/issues/4931#issuecomment-2405034686

It occurs to me that your build script for make appears to limit the library to supporting only 2 threads, while the cmake build is set up for however many cores the build system has.

For clarification, for benchmark on 16 cores @ Ryzen 7945HX, the OpenBLAS is compiled with option NUM_THREADS=16.
Perhaps you saw the code on main branch, where only 2 threads are available (on github action).
Compiling script on my computer is different, and is on branch 16-cores-Ryzen-7945HX.

If the benchmark itself runs fast enough, maybe the difference in allocation overhead on startup is enough to cause a noticable difference in performance overall.

You are mostly correct. Performance turbulance is significant.
So this is mostly qualitative, not quantitative.

More on https://github.com/OpenMathLib/OpenBLAS/issues/4931#issuecomment-2405521788
@martin-frbg After some elementary profiling, computation bottleneck for dsyev/dsyevx/dspgv are indeed dlasr (but not dspgvx; the latter bottleneck is daxpy_k and dot_compute). You've mentioned in another issue https://github.com/OpenMathLib/OpenBLAS/issues/4758#issuecomment-2178773636, and that is correct :smile:
I found that using optimized fortran compiling flag will largely accelarate dlasr. So I guess that's why using cmake -O3 can be a lot faster, and even faster than using make (which I believe is make -O2) for dsyev/dsyevx/dspgv.
dlasr is still the computation bottleneck, even given -O3. And this function is mostly not running in parallel.
@XiWeiGu Your suggestion is useful! (though in another way :joy:)
I tried to objdump the function dlasr_. I found that using -DCMAKE_C_FLAGS="-O2" or "-O3" will not make any difference; but -DCMAKE_Fortran_FLAGS="-O3" makes difference.

Task
cmake default
cmake with -O3
make

dgemm
17.7 msec
19.0 msec
19.1 msec

dsyrk
13.8 msec
12.4 msec
11.4 msec

dsyev
26578.6 msec
2854.0 msec
4030.9 msec

dsyevd
728.2 msec
375.4 msec
367.2 msec

dsyevr
1607.9 msec
781.0 msec
783.8 msec

dsyevx
24461.5 msec
2404.4 msec
3354.8 msec

dspgv
35749.2 msec
4695.0 msec
6132.1 msec

dspgvd
5466.5 msec
2223.2 msec
2201.3 msec

dspgvx
3965.5 msec
1812.5 msec
1809.9 msec

Results updated and available from
https://github.com/ajz34/issue_openblas_dsyev/tree/88c9b90599e2e179c8b5a2fc4ee3f36bad00397a

CMake has its own ideas about optimization levels - namely that the user should specify CMAKE_BUILD_TYPE (where "Release" corresponds to -O3 for all languages involved). MKL will usually be faster for LAPACK functions as OpenBLAS
uses the  unoptimized, non-parallelized implementations from Reference-LAPACK (except for GETRF/POTRF and a handful of others) - LASR is probably the most extreme bottleneck

Ah that's a clear explanation and a good practice. Thanks!

Glad to hear your issue has been resolved.


Adding child_file_title_generator_function

Adding child_file_title_generator_function
0d88a021ae038a27996bfd4cbc6c8f623a4aac91
Prior to this commit, we had a hard-coding approach to configuring a
child work's title.
With this commit, we preserve the existing behavior (for better or
worse) but expose a configuration option to help in the process
generation.
Related to:

https://github.com/scientist-softserv/iiif_print/issues/204

Removing dead code
e83f70a5ea0064bcb4a07bdc81d2693397dba775
Refactoring internal method for Child Work title
ac0b5edfb7fa21b234f067ad796a0eab4e1bed67
Based on feedback from clients and process improvements, this is a
change that will help ensure more unique titles; and make a visiual
connection to the PDF that child works were generated from.
Related to:

https://github.com/scientist-softserv/iiif_print/issues/204

Removing private variables no longer needed
d435eeb0622a46364eb48d0a7add8a1e0517f1ea
This commit includes a deprecation documentation, a bit of recursive
humor, and removal of variables and parameters that are no longer
necessary based on the updated child work title function.

Screenshot of default config from adventist

Do we have or need a plan to handle existing data on prod?

We do, but that's the next step.

Fix IiifPrint
Update it in Adventist to fix ongoing issues
Figure out what to do with existing works


Unable to resolve loaders if directory contains an octothorpe

Bug report
What is the current behavior?
Webpack is unable to resolve loaders if the folder name contains # (octothorpe/number sign/pound/hash)
The error output shows a whitespace character being added in front of the symbol which in turn causes the required files not to be found.
If the current behavior is a bug, please provide the steps to reproduce.
Create a project where the root directory or any directory leading up to it has a name containing the #-symbol, e.g. "#Test".
Add webpack and any loader (e.g. ts-loader) as dependencies.
When trying to run a webpack build it will throw an exception such as the following;
(Note the prepended whitespace in the error message which is not seen in the require stack)
ERROR in ../ #Test/src/main.ts
Module build failed (from ../ #Test/node_modules/ts-loader/index.js):
Error: Cannot find module 'C:\Projects\ #Test\node_modules\ts-loader\index.js'
Require stack:
- C:\Projects\#Test\node_modules\loader-runner\lib\loadLoader.js
- C:\Projects\#Test\node_modules\loader-runner\lib\LoaderRunner.js
- C:\Projects\#Test\node_modules\webpack\lib\NormalModule.js
- C:\Projects\#Test\node_modules\webpack\lib\NormalModuleFactory.js
- C:\Projects\#Test\node_modules\webpack\lib\Compiler.js
- C:\Projects\#Test\node_modules\webpack\lib\webpack.js
- C:\Projects\#Test\node_modules\webpack\lib\index.js
- C:\Projects\#Test\node_modules\webpack-cli\lib\utils\package-exists.js
- C:\Projects\#Test\node_modules\webpack-cli\lib\webpack-cli.js
- C:\Projects\#Test\node_modules\webpack-cli\lib\bootstrap.js
- C:\Projects\#Test\node_modules\webpack-cli\bin\cli.js
- C:\Projects\#Test\node_modules\webpack\bin\webpack.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:880:15)
    at Function.Module._load (internal/modules/cjs/loader.js:725:27)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (C:\Projects\#Test\node_modules\v8-compile-cache\v8-compile-cache.js:159:20)
    at loadLoader (C:\Projects\#Test\node_modules\loader-runner\lib\loadLoader.js:19:17)
    at iteratePitchingLoaders (C:\Projects\#Test\node_modules\loader-runner\lib\LoaderRunner.js:183:2)
    at runLoaders (C:\Projects\#Test\node_modules\loader-runner\lib\LoaderRunner.js:396:2)
    at NormalModule.doBuild (C:\Projects\#Test\node_modules\webpack\lib\NormalModule.js:631:3)
    at NormalModule.build (C:\Projects\#Test\node_modules\webpack\lib\NormalModule.js:775:15)
    at C:\Projects\#Test\node_modules\webpack\lib\Compilation.js:1193:12

What is the expected behavior?
Loaders being found regardless of special characters in the full path name.
Other relevant information:
webpack version: 5.10.0
Node.js version: 14.15.1
Operating System: Windows 10
Additional tools: -

Do you have   (space) in directory name?

Do you have   (space) in directory name? Directory name is Projects #Test, right?

No, the directory is
C:\Projects\#Test\
Compare it to the error message;
Error: Cannot find module 'C:\Projects\ #Test\node_modules\ts-loader\index.js'
                                       ^ there is a space here

Seem to be a bug in loader path handling. I guess the space is really a \0

@MelnCat Can you provide example of the problem

@MelnCat Can you provide example of the problem

Just found this issue after posting a similar issue, but the error message I get is different and I'm not having the issue with it inserting a space, so these might be separate issues. I don't know if any of the information I provided might help though. #12574

@benderbr22 not related to your problem

Reproduce example too https://github.com/webpack/webpack/issues/12574#issuecomment-772435703

Tried updating to 5.35.1. While the prepended space is now removed in the error message, there still seem to be issues resolving loaders.
This can be tested by renaming the working directory to anything containing the #-symbol, causing webpack to be unable to find any loader.
Another perhaps simpler way to test this is by copying a loader to a folder containing the #-symbol, e.g.;
module: {
  rules: [
    test: /\.ts$/,
    use: [
      {
        loader: path.resolve(__dirname, 'loaders/my-loader.js'), // Works
      },
      {
        loader: path.resolve(__dirname, 'loaders#/my-loader.js'), // Error: Cannot find module...
      },
    ],
  ],
},

Let me know if I should create a new issue for this.

Yep, please open an issue issue


Fixes for datalayer modules

lower minSdk for mobile to 21, and protect internally. (example https://github.com/joreilly/Confetti/blob/main/androidApp/src/main/AndroidManifest.xml#L9)
Check for API availability in all APIs. Avoid any external checks. (example https://github.com/joreilly/Confetti/blob/main/androidApp/src/main/java/dev/johnoreilly/confetti/wear/WearSettingsSync.kt#L30)

Fixed or tracked separately


GatewayPortNotOnWorkload analyzer logic seems to be incorrect

Bug description
The GatewayPortNotOnWorkload analyzer checks that Gateway resource ports are defined in the Service ports list. While this seems correct at the first glance, I think the Gateway resource ports refer to "workload" ports which means that this checker should be validating that the service "targetPort" list has the Gateway resource ports defined instead of service ports itself.
This is further complicated by how the predefined service ports "80" & "443" are handled as a special case where the Gateway resource port "80" & "443" get converted to target ports "8080" & "8443" for the gateway workload ports to get the around the priveleges issue related to ports under 1024.
Affected product area (please put an X in all that apply)
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[x] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Expected behavior
Analyzer doesn't surface false positive messages
Steps to reproduce the bug

Install Istio 1.7.3 with demo profile
Deploy a GW resource like this:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: frontend-gateway
spec:
  selector:
    # use Istio default gateway implementation
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---

Run "istioctl analyze -n default" and no error messages are displayed which is correct but notice that the istio-ingressgateway service forwards traffic on service port 80 to target port 8080 and the Envoy config dump on the ingress gateway pod will show that the configured listener is also on port 8080.
Update the gateway resource to use port 8080:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: frontend-gateway
spec:
  selector:
    # use Istio default gateway implementation
    istio: ingressgateway
  servers:
  - port:
      number: 8080
      name: http
      protocol: HTTP
    hosts:
    - "*"
---

Run "istioctl analyze -n default" and a warning message is displayed which is not correct as the traffic still flows correctly due to service port 80 being mapped to gateway workload port 8080. I'm assuming Istio control plane is doing this translation on for ports 80 and 443 for backwards compatibility.

Warn [IST0104] (Gateway frontend-gateway.default) The gateway refers to a port that is not exposed on the workload (pod selector istio=ingressgateway; port 8080)

Version (include the output of istioctl version --remote and kubectl version --short and helm version if you used Helm)
How was Istio installed?
Via istioctl following steps here.

FYI @esnible @therealmitchconnors @howardjohn

@shamsher31 are you working on this?

@shamsher31 are you working on this?

yes, I am experiencing the same as the OP. I started off thinking I actually had a problem to solve but as far as I can tell, everything lines up ports wise and my workloads are functioning.


Issue 12: Extract assert_executes into its own assertions file

I was following this blog post (https://chriskottom.com/blog/2014/08/customize-minitest-assertions-and-expectations/) which suggested re-opening the minitest::assertions module.
I don't have any real problem with re-opening Minitest, and I think this is an okay use case for doing so.


Consider monorepo is not contributor friendly

I believe monorepo is a good choice for projects with a lot of small highly coupled packages that share their dependencies. But this is a bad choice for projects with a lot of almost independent packages whose have high amount of dependencies not related to each other.
I have an average hdd (seagate barracuda 156MB/s). I want to contribute to a package inside opentelemetry-js (just one small PR that removes a couple of lines). I fork repository, clone it and run npm i. And it keeps my disk 100% busy for an hour! After installation repository takes 4GB (430732 files, 55092 directories) on my disk...
And I have to repeat this 1-hour performance several times. Because when you have millions installation steps some of them tends to fail (some dependencies is missing, git submodules is not properly configured, locks conflicts, windows stuff etc).
And after that I run npm t and ... it fails... It fails in a package that I don't want to contribute to.
I may be overly sensitive, but this is crazy to me.
I suggest either move to polyrepo or extend Contributing Guide with steps explaining how to make changes to a single package independently of the rest of the packages.
I believe this will make the project much more friendly to the potential contributors.

Performance concerns related to the monorepo structure have been a problem for a while. They also cause slow CI builds. This was a big reason why we decided to split the contrib packages into their own repo. In contrib, you can use each package independently by just running npm install without using lerna and be fine. In the main repo that doesn't work as well though since the packages are actually pretty tightly coupled. A change in the core module for example may require changes in many other modules. Having the modules linked together is very valuable for making these types of changes.

I fully understand the reasons.  But at the moment it is very difficult to contribute to the project.  We need a path for modifying a separate package without building and testing all the rest.

@morigs for now, you can bootstrap a single package and only its dependencies by doing lerna bootstrap --scope @opentelemetry/package-name --include-filtered-dependencies

It sounds exactly like what I wanted. But doesn't work)
$ npx lerna bootstrap --scope @opentelemetry/plugin-http --include-filtered-dependencies
WARN deprecated --include-filtered-dependencies has been renamed --include-dependencies
lerna notice cli v3.22.1
lerna notice filter including "@opentelemetry/plugin-http"
lerna notice filter including dependencies
lerna info filter [ '@opentelemetry/plugin-http' ]
lerna WARN bootstrap Installing local packages that do not match filters from registry
lerna info Bootstrapping 9 packages
lerna info Installing external dependencies
lerna ERR! npm install --no-save exited 1 in '@opentelemetry/context-async-hooks'
lerna ERR! npm install --no-save stderr:
npm ERR! Unexpected end of JSON input while parsing near '...evDependencies":{"sho'

npm ERR!      C:\Users\gogam\AppData\Roaming\npm-cache\_logs\2020-08-26T06_45_48_681Z-debug.log

lerna ERR! npm install --no-save exited 1 in '@opentelemetry/context-async-hooks'
lerna WARN complete Waiting for 8 child processes to exit. CTRL-C to exit immediately.

This is clean repository. I have done only npm i (without bootstrap)


Index refactoring

Everything is the same, but shorter :)

Nice job, thanks!

@TrySound : How are you feeling about the API now?

Seems much better


Download link broken

The latest download link on https://rg3.github.io/youtube-dl/download.html is broken.
Might be more stable to update the downloader to parse https://github.com/rg3/youtube-dl/releases instead.

https://github.com/fent/node-youtube-dl/pull/122


Efficiency after 2024/5 API Change

I'm making a new issue out of this, because it's a separate issue from the core requests changing.

What I have now from testing:

Interval(s)
Efficiency
Start
End
Start %
End %
100%

59
0.534
10:08:17
10:35:14
47.0%
59.0%
2:00

30
0.932
10:49:43
11:01:18
61.0%
70.0%
2:00

30
0.809
11:01:18
11:08:43
70.0%
75.0%
2:00

30
1.002
11:08:43
11:15:54
75.0%
81.0%
2:00

It also feels like efficiency is slowing down over time, but I'm not at all confident about that.

Some more data, +1% and -1% are maximum measurement inaccuracies

Measurements
Interval(s)
Efficiency
Start
End
Start%
End%
100%
+1%
-1%

1
59
0.534
10:08:17
10:35:14
47.0%
59.0%
2:00
0.579
0.490

2.1
30
0.932
10:49:43
11:01:18
61.0%
70.0%
2:00
1.036
0.829

2.2
30
0.809
11:01:18
11:08:43
70.0%
75.0%
2:00
0.971
0.647

2.3
30
1.002
11:08:43
11:15:54
75.0%
81.0%
2:00
1.169
0.835

2.4
30
0.888
11:15:54
11:26:43
81.0%
89.0%
2:00
0.998
0.777

2.5
30
0.882
11:26:43
11:53:56
44.0%
54.0%
4:00
0.970
0.794

2.all
30
0.897
10:49:43
11:53:56
30.0%
54.0%
4:00
0.934
0.860

We should consider whether we want to keep the current system of manually interacting with the API.
This software can essentially be split into three main components:

Deciding what to watch
Watching
Claiming the drop
1 & 3 work as expected, and for 2 it would be very easy to plug-in a Selenium Firefox instance and point it at an actual live stream to watch at lowest quality.

We should consider whether we want to keep the current system of manually interacting with the API. This software can essentially be split into three main components:

Deciding what to watch
Watching
Claiming the drop

1 & 3 work as expected, and for 2 it would be very easy to plug-in a Selenium Firefox instance and point it at an actual live stream to watch at lowest quality.

As I found out here, the actual watching (GET requests) is not the issue. Since it has operated on the minute-watched model, I think it checks a bunch of stuff each loop, that could be done way less often. Haven't taken a closer look at it, tho. It's in twitch.py async def _watch_loop(self)
requests duration: 1.0315825939178467
watch loop duration: 19.580376863479614
requests duration: 0.9307780265808105
watch loop duration: 10.93083930015564
requests duration: 0.8689451217651367
watch loop duration: 10.870950698852539
requests duration: 0.8665504455566406
watch loop duration: 10.88144564628601
requests duration: 0.894366979598999
watch loop duration: 10.891481161117554
requests duration: 0.8790795803070068
watch loop duration: 10.88401746749878
requests duration: 0.9005200862884521
watch loop duration: 10.91445255279541

Measurments
interval(s)
efficiency
start
end
start%
end%
100%
+1%
-1%

1
59
0.534
10:08:17
10:35:14
47.0%
59.0%
2:00
0.579
0.490

2.1
30
0.932
10:49:43
11:01:18
61.0%
70.0%
2:00
1.036
0.829

2.2
30
0.809
11:01:18
11:08:43
70.0%
75.0%
2:00
0.971
0.647

2.3
30
1.002
11:08:43
11:15:54
75.0%
81.0%
2:00
1.169
0.835

2.4
30
0.888
11:15:54
11:26:43
81.0%
89.0%
2:00
0.998
0.777

2.5
30
0.882
11:26:43
11:53:56
44.0%
54.0%
4:00
0.970
0.794

2.all
30
0.897
10:49:43
11:53:56
30.0%
54.0%
4:00
0.934
0.860

3
15
0.861
12:12:43
12:23:52
54.0%
58.0%
4:00
1.076
0.646

4.1
15
1.009
01:02:07
02:27:45
47.0%
71.0%
6:00
1.051
0.967

Also this shows at a very high confidence, that 15s is enough. My guess would be we need one every 20s. It would fit the linear improvement with the limit of 1 I'd expect:

My error should be +- 2%, to fully account for the same percentage being shown for a longer time, both at the start and at the end. I'll fix that after I finish testing 25s.

| Measurements | Interval(s) | Efficiency | Start    | End      | Start% | End% | 100%  | +2%   | -2%   |
|--------------|-------------|------------|----------|----------|--------|------|-------|-------|-------|
| 1            | 59          | 0.534      | 10:08:17 | 10:35:14 | 47.0%  | 59.0%| 2:00  | 0.623 | 0.445 |
| 2.1          | 30          | 0.932      | 10:49:43 | 11:01:18 | 61.0%  | 70.0%| 2:00  | 1.140 | 0.725 |
| 2.2          | 30          | 0.809      | 11:01:18 | 11:08:43 | 70.0%  | 75.0%| 2:00  | 1.133 | 0.485 |
| 2.3          | 30          | 1.002      | 11:08:43 | 11:15:54 | 75.0%  | 81.0%| 2:00  | 1.336 | 0.668 |
| 2.4          | 30          | 0.888      | 11:15:54 | 11:26:43 | 81.0%  | 89.0%| 2:00  | 1.109 | 0.666 |
| 2.5          | 30          | 0.882      | 11:26:43 | 11:53:56 | 44.0%  | 54.0%| 4:00  | 1.058 | 0.705 |
| 2.all        | 30          | 0.897      | 10:49:43 | 11:53:56 | 30.0%  | 54.0%| 4:00  | 0.972 | 0.822 |
| 3            | 15          | 0.861      | 12:12:43 | 12:23:52 | 54.0%  | 58.0%| 4:00  | 1.291 | 0.430 |
| 4            | 15          | 1.009      | 1:02:07  | 2:27:45  | 47.0%  | 71.0%| 6:00  | 1.093 | 0.925 |
| 5            | 21          | 0.991      | 2:41:40  | 7:14:00  | 50.0%  | 100.0%| 9:00 | 1.031 | 0.952 |
| 6            | 25          | 0.967      | 8:45:48  | 13:33:41 | 18.0%  | 76.0%| 8:00  | 1.000 | 0.934 |

20s clearly seems like the highest the interval can go, without losing efficiency.

What is 2% +/- in this case? - Is this your area of confidence?

What is 2% +/- in this case? - Is this your area of confidence?

My error should be +- 2%, to fully account for the same percentage being shown for a longer time, both at the start and at the end. I'll fix that after I finish testing 25s.

To clarify, when I look at how much percent the progress is, I don't know whether it just increased to that, or is just about to increase further. This is for both the start and end time, thus the uncertainty is 2*1%=2%. This does not account for other hard to measure bias, like the time from starting the bot and me taking a drop inventory screenshot, but especially for the multiple hour runs, this should be negligible, while an increase from let's say 20% to 50% would mean 29%<actual progress<31%, an uncertainty of ~6%. You can really see this with the first measurement, where what appears to be 12% drop progress, could actually be 10% or 14%, depending on the screenshot timing.

I have monitored the current watched minutes at a frequency of 60 seconds and did not find such a big error. Maybe this is acceptable. I'll keep testing it.

I have monitored the current watched minutes at a frequency of 60 seconds and did not find such a big error. Maybe this is acceptable. I'll keep testing it.

That is the shortest test I made, it just showed that there is no way it's efficient and I feel like me further tests confirm it. I would look at the accurate 15s, 21s, 25s and 30s tests, that in my opinion clearly show 20s is the limit.
That being said, it is a little weird, that 30s is more than 66% and 59s is more than 33%, which is what you would expect, if each "watch" simply added 20s.

I observed that after each ts file request, watch time will continue to increase by 1-2 minutes, without any loss. So is the problem related to frequency?

I added how many (seconds of progress)/watch we get. It's odd.
I guess you could call the less frequent intervals "more efficient", but you aren't getting the progress corresponding to time spent watching, which would not only make the calculation of the remaining time difficult, but more importantly could cause you to miss drops.

Of course, it's possible that my observations are wrong.I'll measure it tomorrow morning.

I'll be happy to hear how your measurements go.

Measurements
interval(s)
efficiency
start
end
start%
end%
100%
+2%
-2%
s/watch +2%
s/watch -2%

1
0:00:59
0.534
10:08:17
10:35:14
47.0%
59.0%
2:00
0.623
0.445
0:00:37
0:00:26

2.1
0:00:30
0.932
10:49:43
11:01:18
61.0%
70.0%
2:00
1.140
0.725
0:00:34
0:00:22

2.2
0:00:30
0.809
11:01:18
11:08:43
70.0%
75.0%
2:00
1.133
0.485
0:00:34
0:00:15

2.3
0:00:30
1.002
11:08:43
11:15:54
75.0%
81.0%
2:00
1.336
0.668
0:00:40
0:00:20

2.4
0:00:30
0.888
11:15:54
11:26:43
81.0%
89.0%
2:00
1.109
0.666
0:00:33
0:00:20

2.5
0:00:30
0.882
11:26:43
11:53:56
44.0%
54.0%
4:00
1.058
0.705
0:00:32
0:00:21

2.all
0:00:30
0.897
10:49:43
11:53:56
30.0%
54.0%
4:00
0.972
0.822
0:00:29
0:00:25

3
0:00:15
0.861
12:12:43
12:23:52
54.0%
58.0%
4:00
1.291
0.430
0:00:19
0:00:06

4
0:00:15
1.009
1:02:07
2:27:45
47.0%
71.0%
6:00
1.093
0.925
0:00:16
0:00:14

5
0:00:21
0.991
2:41:40
7:14:00
50.0%
100.0%
9:00
1.031
0.952
0:00:22
0:00:20

6
0:00:25
0.967
8:45:48
13:33:41
18.0%
76.0%
8:00
1.000
0.934
0:00:25
0:00:23

I added how many (seconds of progress)/watch we get. It's odd.
I guess you could call the less frequent intervals "more efficient", but you aren't getting the progress corresponding to time spent watching, which would not only make the calculation of the remaining time difficult, but more importantly could cause you to miss drops.

Of course, it's possible that my observations are wrong.I'll measure it tomorrow morning.

I'll be happy to hear how your measurements go.

This is awesome, thanks for doing this and sharing all the above results. Mind if I ask how you're doing this, as far as the test/timings + visualizing as charts? Python/Excel combo? I'd be interested in doing this, as well.

It's in Excel. I had both TDM and the Twitch inventory open. For each test, I changed the frequency in VS Code and ran the miner. I would then take screenshots of both at the same time. Then, I manually entered the measurement index number, Interval and, from those screenshots, the respective progress, time (from the taskbar) and total drop duration. The rest is done with the following formulas. I should note that I let ChatGPT make this table, so it might be messed up somewhere, since it had to compose the table, instead of just formatting it.

AS
AT
AU
AV
AW
AX
AY
AZ
BA
BB
BC
BD

Measurements
interval(s)
efficiency
start
end
start%
end%
100%
+2%
-2%
s/watch +2%
s/watch -2%

{manual input}
{manual input}
=(AZ2*(AY2*(AX2/(AW2-AV2))))
{manual input}
{manual input}
{manual input}
{manual input}
{manual input}
=(AZ2*(AY2+2%-AX2)/(AW2-AV2))
=(AZ2*(AY2-2%-AX2)/(AW2-AV2))
=(AZ2*(AY2+2%-AX2))*AT2/(AW2-AV2)
=(AZ2*(AY2-2%-AX2))*AT2/(AW2-AV2)

Moving to https://github.com/Windows200000/TwitchDropsMiner_2024-5-fix/issues/3


Avatar refactor in people.js

This PR supports https://github.com/zulip/zulip/pull/8901 by rewriting the first commit in a more readable fashion.
@showell can you give this a review?
@skunkmb FYI

I'd be tempted to just squash this all into one commit.  It's hard to see that some of the incremental commits are truly extractions, but the overall resulting code seems sane to me.
These avatar functions are always going to be fiddly by nature, so I hope our node coverage is decent.

We have full node coverage on this (well, were missing a line of new code, which I fixed).  I merged this without squashing because I found it more readable that way.
I confirmed that we do need all the code paths; the corner case we were talking about above I think comes up with the late_user addition code path.  There might be a better fix there, though.


new rule: "Incomplete property Object at calling"  pull request.

I was try to make a prototype　a new rule
as  "Incomplete property Object at calling" ,
and "Vauge property Object at calling".
I think  that's effective to check the Model layer in the MVC or MVP.
I　hope re-implementation　 to people who can respond to changes in the New versions and the diverse version of TypeScript.
(a) "Incomplete property Object at calling"
when argument of callExpression was the interface of 101 properties,
if only 100 properties have not been assigned, and then reports  that it is not enough.
It gives a warning　 to those who believe that ”just hundred is good” .

interface IRecord{
a:string; b:number ; c? : any; junc:any;
}
var d = < IRecord > {};
d.a = "one";
callFunc(d); // error becouse d.b is undefind
d.b = 2;  // d.junc is undefine yet
callFunc(d) // ok

supress Error fot optional property(d.c) or exceps-specified name property(d.junc).
restful resource contains a lot of property to the communication message of json format.
Therefore,we leak as described above is liable to occur.
exsample of tslint.json Option:

"ng-Incomplete-Object": [true,
{"callNames":["'$http'.get","'$http'.put","'$http'.post","'RestResource'.postHttp","delete"],
"exceptNames":["junc", "filler","yobi"],
"valueExpand": true,
"CheckVauge": true
}]

(b) "Vauge property Object at calling".
it encourage the "single assignment" of a function-oriented design.
example;

{
if(flag) a=1;
else a=0;
callFunc(a);
}

above code let Vauge Value a={|1 |,| 0|}  at  "callFunc.args[0]".

{a= (flag ? 1: 0);  callfunc(a); }

above code is not Vauge Value at calling "callFunc.args[0]".
Data conversion in model layer is desirable to be unified into one unit.
Therefore, following code is better code.

{
a = booltoNumberConverter(flag);
callfunc(a);
}

Detailed execution example, please refer to the following.
https://github.com/reversi-fun/tslint-microsoft-contrib/blob/reversi-fun-patch2/test-data/ngIncompleteObjectFailingTestInput.ts
https://github.com/reversi-fun/tslint-microsoft-contrib/blob/reversi-fun-patch2/test-data/ngIncompleteObjectFailingTestOutput.txt
please refer to the following my code.
https://github.com/reversi-fun/tslint-microsoft-contrib/blob/reversi-fun-patch2/src/ngIncompleteObjectRule.ts

I am sorry, but the failure scenarios are unclear. Can you please send a pull request?

Oh! 2mounth later..
I send " Pull Request #111 Reversi fun patch2".
can You read flowing:
・src/ngIncompleteObjectRule.ts
・test/ngIncompleteObjectFailingTestInput.ts
・test/ngIncompleteObjectFailingTestOutput.txt

tslint.json  for my   "Incomplete property Object at calling"  and  test/ngIncompleteObjectFailingTestInput.ts.
//
"ng-Incomplete-Object": [true,
{"callNames":["'$http'.get","'$http'.put","'$http'.post","'$http'.delete","'Rest'.postHttp","delete"],
"exceptNames":["junc", "filler","yobi"]
}],
//
--"callNames": what call Expression to be Checks?.
-- "exceptNames": what properties name prefix  in object will be except?.
-- "valueExpand": wants expands values in tslint messages?.
-- "CheckVauge": wants Vague vales?.


Fix for serverless.yml jest configuration not being honored

Fixes #24
There were essentially two issues with the upgrade to Jest v23:

The settings within serverless.yml were not being passed through to Jest properly due to the changes to jest-cli
The promise from the runTests method was not resolving properly due to (surprise!) the method signature changes to jest-cli

I added two tests to explicitly verify that the settings within serverless.yml are making it through to jest-config as expected, so that should (in theory) help avoid something like this happening in the future.
I found that creating the necessary files for the tests on-the-fly seemed to be faster than the heavier copy-paste operations from some of the other tests.

@laardee @artoliukkonen mind taking a look at this one?  Unfortunately the previous jest work in #23 doesn't work properly without this.

Thanks! I'll review, merge & publish the changes in few hours.

I'm not sure if there was a reason behind copying the entire project directory to .local for each of the test-service* tests, but it didn't seem necessary or related to what they were attempting to test, so I refactored that process slightly and sped up the tests somewhat significantly.
A previous test run would take:
Time:        68.975s

Now it takes:
Time:        23.313s


Detecting "a Serve" - Possible ?

Is there a way for a textual app itself to detect when it is being served via textual_serve vs being used directly in terminal?
Use case is, eg I want BINDINGS or other functionality which becomes active when my app is being served via textual_serve...

@willmcgugan Do we have a publicly exposed mechanism for this?

Just check if os.environ.get('TEXTUAL_DRIVER') == 'textual.drivers.web_driver:WebDriver' would work.

Thank you for the workaround.
Would still love to see textual expose an official property for this.

That will work for the foreseeable future. But we can definitely add some kind property to app. It is a Textual thing though, so I'll create an issue there.


How to get clean text only image from subtitle image?

How to get clean text only image from subtitle image?
blue stroke + white text fill

Please use forum.opencv.org for questions and discussions.


Implementation of the Expiration extension

tusd does currently not support the Expiration extension and people have to rely on custom scripts or provider-specific approaches to clean up old uploads. This issue is intended to serve as a discussion place for a possible implementation of this extension. In the end, tusd should be able to do two things:

Provide the expiration time of an upload in the HEAD response to clients, and
Be able to cleanup (finished and unfinished) uploads after a given time.

Sending the expiration time to the client should not be a though nut to crack. However, when looking at the actual clean up work, it could be hairy to find a solution for the various storage options that tusd supports:

For the file storage, it is probably the best approach to iterate through all uploads on disk and determine which upload needs to be cleaned up. This could be implemented as an additional binary (maybe named tusd-cleaner) which the user must configure to run regularly as a cron job.
When looking at the S3 and GCS storage, the cloud providers also offer some expiration mechanism built into their platform. For example, AWS S3 allows to delete files after a certain time. However, this mechanism has a low granularity since the expiration can only be configured in days. This approach is not helpful if someone wants to delete uploads after two hours. For these cloud providers we should consider providing two mechanisms: Either let the expiration be handled by the cloud provider itself or run the tusd-cleaner regularly which will iterate through your cloud bucket and find old uploads.

One might ask, we do we need two binaries (tusd for accepting uploads and tusd-cleaner for clean up old uploads)? Why can't we integrate the cleaning into tusd directly? Well, if you have multiple tusd servers running in parallel for redundancy and load balancing, you don't want every one of these tusd instances to scan through your upload directory at the same time. It would be better to let this be handled by one server with a cron job.
On the implementation side we would need following:

A new directory for our tusd-cleaner binary in https://github.com/tus/tusd/tree/master/cmd
A new datastore interfacer for iterating through existing uploads in https://github.com/tus/tusd/blob/master/pkg/handler/datastore.go
Implementations for the new datastore interface in our storages (maybe try filestore first and later s3store and gcsstore)
A new method for tusd to retrieve the expiration time of an uploads and include in the response to the client

These are just some ideas from me. I am open to hearing other thoughts and approaches!

@Acconut Is this still open? I can pitch in for the design, discussion and implementation.

@DravitLochan Yes, this task is still open. Any help is appreciated!

@Acconut Shouldn't the overall file expiry and expiry of partial uploads be two different features? IMO TUS being a protocol (or a pseudo protocol), the overall file expiry should be out of the scope of TUS. That's something the applications should handle using a cron. Thoughts?

@DravitLochan I think your point of keeping different expiry for completed and partial uploads can be finely grained to configuration which allows user to define

An overall expiry (based on first creation time of file)
Different expiry for completed & partial uploads

One another opinion I would like to add is to clean uploads based on max available system disk (e.g. If the disk consumed is >90% then it should automatically delete the older uploads/start rejecting the new uploads).

One another opinion I would like to add is to clean uploads based on max available system disk (e.g. If the disk consumed is >90% then it should automatically delete the older uploads/start rejecting the new uploads).

Well, I am not sure of this as a feature for resumable-uploads. Also as a backend dev, to start deleting the older uploads on disk hitting 90% seems like an unacceptable thing to me. I might start to lose some critical files and hence my end user will start to churn.
If you want to solve the above problem, I'd say the best way would be to have alerts in place for disk hitting 80, 85, 90 and 95%. In-fact if you run out of space, let the application handle it on it's end "due to high traffic, we are not allowing any new file uploads. We will be back up in no time".

@DravitLochan Your point makes sense, and rejecting the uploads sounds like correct option, but not sure if we need implementation for this at the moment, @Acconut can clarify.
Implementation wise I think storing expiry in FileInfo struct makes sense, since every FileSystem can have different abstraction for the same.

@Acconut what do you think?

TUS being a protocol (or a pseudo protocol), the overall file expiry should be out of the scope of TUS.

Yes, tus should not be concerned about the expiry of files after the upload is completed, but tusd can definitely be concerned about this. There are multiple areas where tusd offers more features than the tus protocol specifies, just because those are handy and fit well into tusd. So, I see not problem when tusd offers expiration of uploads and files in one convenient package. Does that make sense? :)

One another opinion I would like to add is to clean uploads based on max available system disk

Interesting idea, but I think that is outside of tusd's scope and is very application specific. This does not seem like a good fit for tusd, as @DravitLochan already mentioned.

rejecting the uploads sounds like correct option, but not sure if we need implementation for this at the moment,

You can already check the free space of the disk in the pre-create hook and reject uploads if the disk is too full. There is not additional implementation needed inside tusd.

Also I'm not sure how we can parse common flags for config etc across the binaries, since most of them will be same in tusd & tusd-cleaner

That should not be a big problem. The parsing and/or validation of flags can be extracted into a shared module, which is imported by both programs (if that makes sense in the case).

@Acconut
I am currently using the CreatedUploads event to push tasks to a queue for cleaning up files. This way, I don't have to worry about which instance of tus created the file. So far, this approach is working well for us. Do you have any feedback or comments on this approach?
for event := range handler.CreatedUploads {
		log.Printf("Upload %s created\n", event.Upload.ID)
		uploadedFilePath := hook.Upload.Storage["Path"]

		tusFiles := []string{
			uploadedFilePath,
			fmt.Sprintf("%v.info", uploadedFilePath),
		}

               // Add file cleanup task for tusFiles to message queue to be executed at the time of expiry
}

That should be fine as long as the delay is large enough to make sure uploads are either finished or abandoned when the clean up occurs.


add whisperx implementation

Hi Hay,
Here is a whisperX implementation, it still needs work, but i think it should be usable on Snellius (although there might be some small bugs in there). Now it simply replaces whisper via command line call with whisperx using the python implementation, perhaps you want the user to be able to choose.

Merged this into a new branch, because i want to add a couple of switches to make this optional, but we want the code to live somewhere.


Error in gtkbuilder sample: AtkAction not implemented

$ lua gtkbuilder.lua
lgi-Message: gobject-introspection binding for Lua, 0.4
(lua:865): Gtk-WARNING **: accessibility action on a widget that does not implement AtkAction
lua: gtkbuilder.lua:35: attempt to index a boolean value
stack traceback:
gtkbuilder.lua:35: in main chunk
[C]: ?
OS: Archlinux
gobject-introspection 1.30.0-1
lua 5.1.4,
gtk 3.2.3
lgi: master@github

This is GTK3.2 issue.  The very same warning is issued by gtk3-demo, after invoking 'Builder' demo (note that gtkbuilder.lua is just more or less direct port of this demo).
Anyway, thanks for the report. :-)

I meant that the program crashed. Anyways, if I force gtk_builder_use_standard_api=true then this sample works (even if there is still the warning). So for me only the standard API works.

Err, the sample was broken, fixed and pushed now, see the last commit in master.  Thanks again!

Now it works, thanks! Anyways I should have noticed the broken path...