Changed serialised index type of std::variant to std::uint32_t

This makes saving & loading std::variant cross-platform.

Here's the basic change, as discussed in #473.
A few notes/comments:

The function and template argument (int target and int N) are both ints. I am not sure whether this may now result in a type-conversion/narrowing warning if std::uint32_t is not int. But that would probably be only on exotic platforms? And previously it might have generated a warning too because std::size_t is probably not int on many platforms.

I can't see a unit test for variant, i.e. no test_variant. Shall I copy & paste test_boost_variant here and add that?

I think something is not quite right yet with a88e1c7dfd2f1f1323694932df8c314af8f1777e. I've got VS2017 15.6, I confirmed that /std:c++17 is enabled for test_cpp17_variant, but my _MSVC_LANG is 201403L, not 201703L.
Also I think test_cpp17_variant, here: https://github.com/USCiLab/cereal/blob/develop/unittests/cpp17/variant.cpp#L32 should either test for _MSVC_LANG too or use CEREAL_HAS_CPP17 for the test (and the same for the .hpp file).
But either of these will not help as _MSVC_LANG is 201403L for me, even with /std:c++17.

Okay, it seems the IDE is giving me the wrong tooltip value for _MSVC_LANG. It is indeed 201703L.
Now I am just still confused why CEREAL_HAS_CPP17  is not set if I include macros.hpp in the variant test .cpp file.
I am also confused why there is a .cpp and a .hpp file in the cpp17 test folder. The .hpp file seems to be never included, and both files have similar contents. What am I missing?
I also seem to have a problem that none of the tests seem to compile anymore... Severity	Code	Description	Project	File	Line	Suppression State Error	C2220	warning treated as error - no 'object' file generated	test_vector	cereal\include\cereal\external\rapidjson\document.h	110	 . I got one of them to run an hour ago, and didn't really change much since. Hmm.

Okay, I think this is ready to merge. But please have a look at my comments above (the ones that are not strike-through). First and foremost I think we need to replace more instances of #if __cplusplus >= 201703L with the added _MSVC_LANG check.
Second, I really don't understand why there is a .cpp and .hpp file to each test, but maybe that's irrelevant.
I also really do not understand why CEREAL_HAS_CPP17 seems not get defined on my platform if I include "cereal/macros.hpp" in the unittest, even though if I #pragma message("_MSVC_LANG=" BOOST_PP_STRINGIZE(_MSVC_LANG)) it shows as 201703L.

Do you think there should be some documentation somewhere about how to turn on the C++17 tests? Since it's only for building the tests, maybe it would be sufficient as a comment in the CMakeLists.
Regarding the template parameter, hard to say what the best thing to do here is. I think most likely it will be fine left as int - this can always be changed later if it is ever an issue; it shouldn't ever be a breaking change.
The .hpp/.cpp is an oversight on my part - the original PR had the tests in the .cpp but the preferred way is to have the test logic in the .hpp and instantiate it in the .cpp, I'll fix that up.
You are right on the checks for C++17, they all need to be updated to have the MSVC friendly check.

Do you think there should be some documentation somewhere about how to turn on the C++17 tests? Since it's only for building the tests, maybe it would be sufficient as a comment in the CMakeLists.

Hmm yea, really not sure. Maybe if there was a CEREAL_USE_CPP17 flag or something, it would be a bit more obvious. But adding such a flag just for people that run the tests (mainly library developers I guess) may be a bit overkill too. Maybe just leave it I guess. I stumbled upon it but it's not too hard to figure out. I mainly missed it I think because they were in a subdirectory, and I had already scrolled down looking for something like test_*optional* - so I was just a bit blind :)
Ok great, yep agree w.r.t. the template params!
I think if you could fix the .hpp/.cpp part that would be great.
I can update the checks to be MSVC friendly next week - I'll do that in a separate PR, so that it's not in the way of merging this one.


Assasination Rogue Debuff Color for Herotalent Deathstalker's Mark

Hey there,
I'd LOVE to see the addition of Assasination Rogue's debuff "Deathstalker's Mark" (spelll ID 457052)
to the coloring options.
Thank you so much in advance!

hi @rljohn,
I added the debuffs for Assasination & Sub rouge. @Bu321 tested it ;-)
[259] = {	-- ASSASSINATION ROGUE
{703,1943,457129}, -- Garrote + Rupture + Deathstalker's Mark
{457129,1943}, -- Deathstalker's Mark + Rupture
{703,1943}, -- Garrote + Rupture
457129, -- Deathstalker's Mark
703,	--	Garrote
1943,	--	Rupture
394036,	-- Serrated Bone Spike
},
[261] = { 	-- SUBLETY ROGUE
457129, -- Deathstalker's Mark
316220, -- Find Weakness
1943,	-- Rupture
385408, -- Sepsis
384631, -- Flagellation
},


Implement TFChainError in chain client

Changes

Created a new Error wrapper to throw errors based on their type.
Determined the type of error and threw it accordingly.
Updated the error interface to differentiate between Module, Token, and other error types.
Remove the TFChain error from the types package.

Related Issues

https://github.com/threefoldtech/tfgrid-sdk-ts/issues/3071
https://github.com/threefoldtech/tfgrid-sdk-ts/issues/3072

Checklist

[ ] Tests included
[ ] Build pass
[ ] Documentation
[ ] Code format and docstrings
[ ] Screenshots/Video attached (needed for UI changes)

I see we are going to move the tfchain error from the types package to the tfchain package, is there a reason for that, as we discussed before we need to only refactor the class, and for the other issue we could add a method to that class to resolve the error.

I see we are going to move the tfchain error from the types package to the tfchain package, is there a reason for that, as we discussed before we need to only refactor the class, and for the other issue we could add a method to that class to resolve the error.

As discussed with @AhmedHanafy725 , we'll create an interface with specific fields to capture error details. We'll populate these fields based on the error type. Placing the changes in the types package makes sense yeah. Please review the changes.


Django 3.2 Support

Is there a plan to officially support Django 3.2, one of the LTS versions? The package seems to work as-is, but it's not listed as supported which is causing some apprehension to using the package on my team. I'm happy to open a PR to add support if there isn't some reason that has been avoided.

my bad and thanks for the nudge... I'll make this explicit.
my company has been using it in production with django 3.2 for a while now


Some enhancements

[x] Change id field of document from string to bson.ObjectId
[x] Create  a command to create the first master key
[x] Write some docs about running a go command (through docker-compose and natively)
[ ] Write some unit test for src packages
[ ] Write unit test for command

see: https://github.com/miniwaveme/api/commit/e5a7dcc190a0fbf3efadad44c2872c4983ab6f41#commitcomment-12891136

I create a issue related to code coverage increasing (#13)


add 'style' as a main field for imported modules

Makes us able to import primer modules without referencing the absolute path since they all should now have the style property set to the compiled CSS.

I added examples on how to do it in JS or CSS! 😺


cc.distutils_extension() does not work in project with nested structure

I believe there is a bug when using cc.distutils_extension() in a project with a nested structure.

Project setup

-project_name
  -src
    -my_module
      -__init__.py
      -code2compile.py
  -setup.py
  -pyproject.toml
  -setup.cfg
  -requirements.txt

Sample code

setup.py:
import os
import sys
if os.getcwd() not in sys.path:
    sys.path.append(os.getcwd())
from src.my_module.code2compile import cc
from setuptools import setup
if __name__ == "__main__":
    setup(ext_modules=[cc.distutils_extension()])

code2compile.py:
from numba.pycc import CC
cc = CC("my_compiled_code")
@cc.export("f8", "f8(f8)")
@cc.export("f4", "f4(f4)")
def f(a):
    return a + 1.0

pyproject.toml:
[build-system]
requires = ["setuptools>=42.0", "wheel", "numba>=0.55"]
build-backend = "setuptools.build_meta"

setup.cfg:
[metadata]
name = my_module
platforms = win32
classifiers =
    Programming Language :: Python :: 3
    Programming Language :: Python :: 3.9
    Programming Language :: Python :: 3 :: Only
[options]
packages=
    my_module
install_requires=
    numba>=0.55
    numpy>=1.20
    scipy>=0.16
python_requires = >=3.9
package_dir =
    =src
zip_safe = no

requirements.txt:
numba>=0.55
numpy>=1.20
scipy>=0.16

Error on project installation

When installing the package via pip install -e . the following error is produced:

copying build\lib.win-amd64-cpython-39\src\my_module\my_compiled_code.cp39-win_amd64.pyd -> src\src\my_module
error: could not create 'src\src\my_module\my_compiled_code.cp39-win_amd64.pyd': No such file or directory

How I fixed the bug

new code2compile.py:
import numpy as np
from numba.pycc import CC
cc = CC("my_compiled_code")
cc._source_module = "my_module.my_compiled_code"  # src removed from self._source_module
@cc.export("f8", "f8(f8)")
@cc.export("f4", "f4(f4)")
def f(a):
    return a + 1.0

I believe the error is with this line in numba/numba/pycc/cc.py: python_package_path = self._source_module[:self._source_module.rfind('.')+1].
During initialisation of the CC() class in code2compile.py cc._source_module is src.my_module.code2compile. If  cc._source_module is replaced with my_module.code2compile the copy error is not produced and the pip install -e . is successful.

Recommendation on fix

Seems like when working on a project with a nested structure the line that defines python_package_path is not working as it should (i.e. is not getting the my_module directory). I recommend replacing it with:
python_package_path = ''.join((self._source_module.split('.')[-2], '.')) to allow for projects with nested structures, which would produce the correct result for python_package_path of "my_module." when calling cc.distutils_extension().

I am not sure if the fix will work as expected for module that aren't nested.
It seems like a problem that the package is being imported under a different name than it is being exported under.
from src.my_module.code2compile import cc

I think this needs to be:
from my_module.code2compile import cc

And I know that is incompatible with your current module structure. The source_module can be overridden:
cc = CC("my_compiled_code", "my_module.code2compile")

but this second parameter must be a module that's already loaded by Python, which is isn't because it's being imported as src.my_module.code2compile.

I have tried the following project structure:
-project_name
  -src
    -code2compile.py
    -my_module
      -__init__.py
  -setup.py
  -pyproject.toml
  -setup.cfg
  -requirements.txt

Notably, code2compile.py is under src (rather than previously under src.my_module).
code2compile.py:
import numpy as np
from numba.pycc import CC
cc = CC("my_compiled_code")
@cc.export("f8", "f8(f8)")
@cc.export("f4", "f4(f4)")
def f(a):
    return a + 1.0

Notably, I have removed the line cc._source_module = "my_module.my_compiled_code" from my first post.
When running pip install -e . I receive the same error as before:
copying build\lib.win-amd64-cpython-39\src\CoorUtilsAOT.cp39-win_amd64.pyd -> src\src
error: could not create 'src\src\CoorUtilsAOT.cp39-win_amd64.pyd': No such file or directory

Possibly related to #3824


Removed redundant commands in readme

Looks like the bot was borked and repeatedly appended the commands to the readme.
No idea where the bot is configured, so not sure what happened. Looks like maybe someone turned it off since it stopped committing this afternoon.

Readme broke the build D:

There was a network error. No worries, it is not an automatic rejection

Thanks for the catch, @jhmcstanton ! We found the culprit in our CI, and have fixed it so it doesn't happen again.

This bot existed in om/ci/tasks/readme/task.yml
We changed the commit name to be more helpful


[istio] custom app labels

One thing to note — it looks like your branch is behind master, where I had merged a refactor to better handle the management default values when using this module as a submodule.
The only thing you’ll have to account for is to declare the kiali values in the locals block like this:
locals {
  kiali_values = var.kiali_values != null ? var.kiali_values : [ yamlencode({
    cr = { <YOUR_VALUES_HERE> }
  })]
}


http: configuration refactor

This is a wip but opening as a draft to keep track of this follow up to #421. This is also part of #402.
This introduces the Config struct to serve as a facade to the configuration module. It's essentially a flattened CompatibleConfigFile struct exposing only the fields necessary to running the daemon.

bors r+


How to deal with the OOV words

My sample contains the word 'Silsby', but it does not exist in the vocab.
How to deal with the OOV situation?
python extract_attention.py --preprocessed-data-file samples_10.json --bert-dir data/cased_L-12_H-768_A-12  --max_sequence_length 256 --word_level --cased

Creating examples...
Traceback (most recent call last):
  File "extract_attention.py", line 144, in <module>
    main()
  File "extract_attention.py", line 108, in main
    example = Example(features, tokenizer, args.max_sequence_length)
  File "extract_attention.py", line 29, in __init__
    self.input_ids = tokenizer.convert_tokens_to_ids(self.tokens)
  File "/Users/smap10/Project/attention-analysis-master/bert/tokenization.py", line 182, in convert_tokens_to_ids
    return convert_by_vocab(self.vocab, tokens)
  File "/Users/smap10/Project/attention-analysis-master/bert/tokenization.py", line 143, in convert_by_vocab
    output.append(vocab[item])
KeyError: 'Silsby'

Are you passing in your data using the key "words" in your json? If so, the script should run BERT tokenization for you (see here). But if you are instead passing in the data using the key "tokens," the script assumes the data is already BERT-tokenized (i.e., each token is in the vocab).

I pass the data using the key "tokens", which is already BERT-tokenized

In that case you should only pass in "words", not both "words" and "tokens". Sorry for the confusion!

Can I only pass the "tokens"?

Sure, but then you can't get word-level attention. Passing in both "words" and "tokens" is redundant because the words you pass in get tokenized automatically.

Understood, thanks!


Remove the hard-coded path requirement

Description
The path is previously hard-coded.  This can be removed and the tool will use the environment that is active at the time of execution
Motivation and Context
The directions say to call is venv. But some may not follow that naming convention. And this would previously break the deployment. .
How Has This Been Tested?
Yes, I was able to launch with a virtual env named env

@anandtiwarics


Isomorphic Solutions to window.location

Hi there,
I was looking through the existing issues and came across this being the closest answer to what I need and I'm just looking to see if there is a better option.
In my application, I'm trying to make a library of functions that any page we make can utilise creating a simple place to find most if not all the API routes we make available. I am building off the base example for MobX so there is currently a minimal server file for my application currently as I am building out all the groundwork for what we need.
Currently, my base URL function looks something like this:
const getBaseUrl = (req) => {
    let url

    if (req) {
      // Server side rendering
      console.log(req);
      console.log(req.connection.encrypted);  // undefined
      console.log(req.protocol); // undefined
      url = req.protocol + '://' + req.headers.host
    } else {
      // Client side rendering
      url = window.location.protocol
    }

    return url
}

On the server, I get req.protocol as undefined and in the linked issue the use of req.get('host') returns req.get is not a function. On the client, everything works as expected (though I don't know why window's protocol returns the protocol, hostname, and port, but I'll live with that).
If anyone has a better option it is greatly appreciated. I am continuing to try and find a solution where I'm not hard coding the protocol on the server as it could change as we deploy for different customers making it more of a pain than an answer.
Thanks,
Steve

To follow up on this, I apparently need to not work on things at 10 pm as I derped real hard and didn't realise I wasn't even using Express... Sorry for the issue pollution.


pip or python setup fails with python 3.7.3

Expected Behavior
As a user, I want to install ramstk and test it.
Pip install not working witth python 3.7.3###
pip install or python setup.py install

RAMSTK Version: pypy or github (same behavior)
Operating System: windows
OS Distribution (if Linux):
OS Version: W8.1
Hardware:
Required Software Versions:

Python == 3.7.3 (Anaconda)

Faill to install eith er via pip or python setup.py install > same issue
"  File "setup.py", line 14, in
long_description = f.read()
File "C:\ProgramData\Anaconda3\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position 5586: character maps to "
Am I alone to have this defect ?

Probably not.  The problem is the setup.py file doesn't indicate the README.md file's encoding ("utf-8").  I can fix that, but I'll have find a Windows machine to test this on (pull requests are welcome, of course ;)).  However, a little further along in the setup.py file, you'll see this:
if not sys.version_info[0] == 2:
sys.exit("Sorry, Python 3 is not supported yet.")
So that'll be the ultimate problem trying to use RAMSTK on your system.  The current push is to provide support for Python 3.

The following modules have been refactored to date:

Revision
Function
Requirement
Validation
The develop branch installs and runs using Python 3.7.2 and the Makefile target 'install'.  Recommend installing in a virtual environment or --user if there's an interest in testing what's available to date.

python setup.py install works from the release/v1.0.0 or develop branch.  The attached file is a postgres database dump of a small project that can be used to test RAMSTK.
ramstk_test_db.sql.txt

pip install ramstk==0.12.1 will install the latest RAMSTK that works (at least on my machine) with Python 3.6, 3.7, and 3.8.  There are yanked versions that may attempt to install if you pip install ramstk, so ensure you pass the version number.

pip install ramstk==0.12.1 will install the latest RAMSTK that works (at least on my machine) with Python 3.6, 3.7, and 3.8.  There are yanked versions that may attempt to install if you pip install ramstk, so ensure you pass the version number.


Handle different possible plugin dirnames

Depending on how the plugin is imported:
local resurrect = wezterm.plugin.require 'https://github.com/MLFlexer/resurrect.wezterm' or local resurrect = wezterm.plugin.require 'https://github.com/MLFlexer/resurrect.wezterm/', a different directory in the Wezterm plugins folder will be created. If you require the plugin with a / at the end, the plugin directory will have sZs at the end. You can end up duplicate plugin directories with different names
This PR:

checks for the existence of these directories and will return httpssCssZssZsgithubsDscomsZsMLFlexersZsresurrectsDswezterm by default
creates an is_windows() utility function to use throughout.

Thanks for the PR!

There is a problem with how sub modules require other sub modules, which I think we need to address. Submodules have the following code in them to be able to depend on submodules.
-- in table_state.lua
-- Line below can create a clone of the already existing repo, but with the sZs postfix
local resurrect = wezterm.plugin.require("https://github.com/MLFlexer/resurrect.wezterm/")
local pane_tree_mod = require(resurrect.get_require_path() .. ".plugin.resurrect.pane_tree")

From my perspective, there are 2 options, one is to change the package.path to include the path <plugin_directory>/<name_of_resurrect_directory>/plugin/?.lua. Then the code for requireing the modules would be changed to this:
-- in table_state.lua
local pane_tree_mod = require("resurrect.pane_tree")

The other option is just keeping what we have, and then users might have a duplicate of the plugins, however maintaining becomes harder as there might be two different versions of the plugin installed.
I hope this problem can be fixed with the next release of Wezterm, but for now this is the solutions as I see them

I really like the is_windows() function, it makes the code much more readable

I've updated the PR to add the plugin to the package.path and handle the submodules differently.

[!WARNING]
This represents a breaking change to the API and I've updated the README accordingly.


Bark notifications : Unsupported Parameters., error=400.

Describe the bug
I am using bark self-built server, when I configure bark notification, this error appears:
Unsupported Parameters., error=400.
Version
v<IP_ADDRESS>
To Reproduce
Steps to reproduce the behavior:

Go to 'settings'
Click on 'notifications'
Enter the AppRise Bark url 'bark://bark.examples.com/BjiqCe9MauVBNSKBM5GSNT/'
See error “Bad Request - Unsupported Parameters., error=400.”

! ALWAYS INCLUDE AN EXAMPLE URL WHERE IT IS POSSIBLE TO RE-CREATE THE ISSUE - USE THE 'SHARE WATCH' FEATURE AND PASTE IN THE SHARE-LINK!
Desktop (please complete the following information):

OS: [Windows 11]
Browser [Brave]
Version Version 1.60.114 Chromium: 119.0.6045.124 (Official Build) (64-bit)]

Additional context
The error log:
2023/11/15 15:43:47,000 - SENDING - null
b'{"code":400,"message":"failed to get device token: failed to get [push] device token from database","timestamp":1700063028}'
2023-11-15 15:43:48,738 - DEBUG - Response Details:
2023-11-15 15:43:48,734 - WARNING - Failed to send Bark notification to BjiqCe9MauVBNSKBM5GSNT: Bad Request - Unsupported Parameters., error=400.
2023-11-15 15:43:47,909 - DEBUG - Bark Payload: {'title': 'ChangeDetection.io Notification - https://changedetection.examples.com/settings#notifications', 'body': 'https://changedetection.examples.com/settings#notifications had a change.\n---\n\n---', 'icon': 'https://github.com/caronc/apprise/raw/master/apprise/assets/themes/default/apprise-info-128x128.png', 'device_key': 'BjiqCe9MauVBNSKBM5GSNT'}
2023-11-15 15:43:47,908 - DEBUG - Bark POST URL: http://bark.examples.com/push (cert_verify=True)
2023-11-15 15:43:47,882 - DEBUG - Loaded Bark URL: bark://bark.examples.com/BjiqCe9MauVBNSKBM5GSNT?image=yes&format=text&overflow=upstream&rto=4.0&cto=4.0&verify=yes

Thanks for your reply.
I found the problem and solved it.
When I checked the log again and read this sentence:
gets://, posts://, puts://, deletes:// for direct API calls (or omit the "s" for non-SSL ie get://)

Then I changed bark to barks and tested again, and I can already receive reminders.
Finally, the bark service configured with ssl should be written as:
barks://bark.examples.com/BjiqCe9MauVBNSKBM5GSNT/

@soundghost ok i'll close this, bumped it over to the apprise repo to add that barks:// text to the docs, thanks again


Making diagrams for data jouneys

we would like to make diagrams that can coded into the page instead of frozen images, this is for the data jouneys as a subpage of the planning page

This is the data journey that will be nice to have: https://miro.com/app/board/uXjVM2ZU8BU=/?share_link_id=827417946442


Add unit tests for ONNX PRelu and fix importer to pass them.

@masahi Thank you!

Thanks @mbrookhart


Update node-abi to 2.1.1 for Electron 1.8.0 support

Otherwise "Could not detect abi for version 1.8.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron"
Please publish new version after merge if possible.

Workaround for Yarn:
"resolutions": {
    "node-abi": "^2.1.1"
  }

I don't think there's the need to release a new version since 2.1.1 satisfies the version requirements of ^2.0.0 (https://semver.npmjs.com/).
Since you're using yarn I think regenerating the yarn.lock file should solve the issue.

@lgeiger Problem is that yarn resolves ^2.0.0 to 2.0.3 And not to 2.1.1. I use Yarn 1.0. yarn upgrade doesn't help also.

Problem is that yarn resolves ^2.0.0 to 2.0.3 And not to 2.1.1. I use Yarn 1.0. yarn upgrade doesn't help also.

Woa, to me this looks like pretty serious bug in yarn.
In any case 👍 for merging this (Sorry, I don't have write access).

Things a more complicated. If I remove node_modules (and revert yarn.lock), it is resolved to 2.1.0. That's why in the electron-builder I always prefer to update dependencies version.

In any case :+1: for merging this (Sorry, I don't have write access).

You do now! :wink:

In any case :+1: for merging this (Sorry, I don't have write access).

You do now! :wink:

Thanks @ralphtheninja


Action failed, due to server error. after upgrade to lates version 1.7.5

I got this error, when I tried to upload image! It was working fine with version 1.7.0. then I upgraded to each version sub sequiently up to 1.7.5 as I often do 'composer update' while developing! I didn't check the filemanager in the mean time. But today after upgrading to 1.7.5 I checked and experience this problem!

Sorry, I didn't notice before. but it was solved once I've applied the folloing:
php artisan vendor:publish --tag=lfm_view --force
php artisan vendor:publish --tag=lfm_public --force
php artisan vendor:publish --tag=lfm_config --force


Error detected while processing WinScrolled Autocommands for "*":

Error detected while processing WinScrolled Autocommands for "*":
E5108: Error executing lua ...start/nvim-treesitter-context/lua/treesitter-context.lua:182:
'width' key must be a positive Integer
Neovim Version -
NVIM v0.5.0

System -
macOS Big Sur
v 11.4

I have a tmux session with 2 splits and neovim with two splits(with tmux zoomed in the neovim pane). As soon as I switch tmux pane, the zoomed-in pane is unzoomed and this error pops up in neovim.
Is there any way we to avoid this issue?

Not sure why that happens, but I've added some logic to try to prevent the errors from popping up. If it persists let me know.

It works. Thanks 👍


Pipewire crashes

Bug report, debug log and your config file (FULL LOGS ARE MANDATORY)

Steps to reproduce
Use HyperHDR with pipewire sceen capture on Nixos Sway
What is expected?
Screen grabbing works
What is actually happening?
After about 10 seconds the screen grabbing stops working
System

In OBS and other application the pipewire screen capture works without problems.

Please provide FULL logs. Thank you. HyperHDR depends heavily on the authentication token that should be provided by the portal. Without the token such portal implementation (missing true Portal protocol 4 specification despite reporting it) is useless for HyperHDR usage.

GUI application2022-09-23T20:42:56.204 MAIN                   : <INFO> Database path: '/home/raphael/.hyperhdr/db/hyperhdr.db', readonlyMode = disabled
2022-09-23T20:42:56.204 MAIN                   : <INFO> Starting HyperHdr - <IP_ADDRESS>,  (), built: Jan  1 1980:00:00:00
2022-09-23T20:42:56.204 MAIN                   : <INFO> Set user data path to '/home/raphael/.hyperhdr'
2022-09-23T20:42:56.205 DB                     : <INFO> Database opened: /home/raphael/.hyperhdr/db/hyperhdr.db
2022-09-23T20:42:56.234 SETTINGSMGR            : <INFO> Settings database initialized
2022-09-23T20:42:56.234 HYPERHDR               : <INFO> Sound device is disabled
2022-09-23T20:42:56.244 V4L2:AUTO              : <INFO> Cropping image: width=0 height=0; crop: left=0 right=0 top=0 bottom=0
2022-09-23T20:42:56.244 V4L2:AUTO              : <INFO> Restarting video grabber is now blocked due to reloading of the configuration
2022-09-23T20:42:56.244 V4L2:AUTO              : <INFO> Cropping image: width=0 height=0; crop: left=0 right=0 top=0 bottom=0
2022-09-23T20:42:56.244 V4L2:auto              : <DEBUG> GrabberWrapper.cpp:75:setCecStartStop() | CEC keycode. Start: 0, stop: 0
2022-09-23T20:42:56.244 V4L2:AUTO              : <DEBUG> Grabber.cpp:259:setBrightnessContrastSaturationHue() | setBrightnessContrastSaturationHue nothing changed
2022-09-23T20:42:56.244 V4L2:AUTO              : <DEBUG> V4L2Grabber.cpp:125:setHdrToneMappingEnabled() | setHdrToneMappingMode to: Disabled
2022-09-23T20:42:56.244 V4L2:AUTO              : <DEBUG> Grabber.cpp:168:setFpsSoftwareDecimation() | setFpsSoftwareDecimation to: 1
2022-09-23T20:42:56.244 SIGNAL_OLD             : <DEBUG> DetectionManual.cpp:85:setSignalDetectionOffset() | Signal detection area set to: 0.250000,0.250000 x 0.750000,0.750000
2022-09-23T20:42:56.244 SIGNAL_OLD             : <DEBUG> DetectionManual.cpp:75:setSignalThreshold() | Signal threshold set to: {12, 12, 12} and frames: 200
2022-09-23T20:42:56.244 SIGNAL_AUTO            : <DEBUG> DetectionAutomatic.cpp:383:setAutoSignalParams() | Automatic signal detection -> errorTolerance: 9, modelTolerance: 90, sleepTime: 5000, wakeTime: 1000
2022-09-23T20:42:56.244 V4L2:AUTO              : <DEBUG> Grabber.cpp:367:setDeviceVideoStandard() | setDeviceVideoStandard preparing to restart video grabber. Old: '' new: 'auto'
2022-09-23T20:42:56.244 V4L2:AUTO              : <INFO> Delayed restart of the grabber due to change of selected device
2022-09-23T20:42:56.244 V4L2:AUTO              : <DEBUG> Grabber.cpp:186:setEncoding() | Force encoding to: NO_CHANGE (old: NO_CHANGE)
2022-09-23T20:42:56.244 V4L2:AUTO              : <INFO> setQFrameDecimation is now: disabled
2022-09-23T20:42:56.244 V4L2:auto              : <DEBUG> GrabberWrapper.cpp:545:handleSettingsUpdate() | Frame cache is: enabled
2022-09-23T20:42:56.244 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Cropping image: width=0 height=0; crop: left=0 right=0 top=0 bottom=0
2022-09-23T20:42:56.245 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Loaded Pipewire proxy library for screen capturing
PipewireHandler: ScreenCast protocol version: 4
Portal.ScreenCast: protocol version = 4
2022-09-23T20:42:56.247 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Restarting video grabber is now blocked due to reloading of the configuration
2022-09-23T20:42:56.247 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> Grabber.cpp:145:trySetWidthHeight() | Set new width: 512, height: 512 for capture
2022-09-23T20:42:56.247 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> Grabber.cpp:322:setWidthHeight() | setWidthHeight preparing to restarting video grabber 0
2022-09-23T20:42:56.247 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Delayed restart of the grabber due to change of the capturing resolution
2022-09-23T20:42:56.247 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Delayed restart of the grabber due to change of the framerate
2022-09-23T20:42:56.247 SIGNAL_OLD             : <DEBUG> DetectionManual.cpp:85:setSignalDetectionOffset() | Signal detection area set to: 0.250000,0.250000 x 0.750000,0.750000
2022-09-23T20:42:56.247 SIGNAL_OLD             : <DEBUG> DetectionManual.cpp:75:setSignalThreshold() | Signal threshold set to: {0, 0, 0} and frames: 50
2022-09-23T20:42:56.247 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> Grabber.cpp:367:setDeviceVideoStandard() | setDeviceVideoStandard preparing to restart video grabber. Old: '' new: 'Pipewire System Dialog selection'
2022-09-23T20:42:56.247 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Delayed restart of the grabber due to change of selected device
2022-09-23T20:42:56.253 SETTINGSMGR            : <INFO> Settings database initialized
2022-09-23T20:42:56.254 BLACKBORDER            : <INFO> Set mode to: default
2022-09-23T20:42:56.254 IMAGETOLED0            : <DEBUG> ImageProcessor.cpp:163:setLedMappingType() | Set LED mapping type to advanced
2022-09-23T20:42:56.254 IMAGETOLED0            : <DEBUG> ImageProcessor.cpp:147:setSparseProcessing() | setSparseProcessing to 0
2022-09-23T20:42:56.254 RGB_TRANSFORM0         : <INFO> RGB transform classic_config: 1, saturationGain: 1.000000, luminanceGain: 1.000000, backlightThreshold: 1
2022-09-23T20:42:56.254 RGB_TRANSFORM0         : <INFO> setBacklightThreshold: 1
2022-09-23T20:42:56.254 ADJUST_RED0            : <INFO> Set correction to 255
2022-09-23T20:42:56.254 ADJUST_BLUE0           : <INFO> Set correction to 255
2022-09-23T20:42:56.254 ADJUST_GREEN0          : <INFO> Set correction to 255
2022-09-23T20:42:56.254 HYPERHDR0              : <INFO> Led strip RGB order is: rgb
2022-09-23T20:42:56.255 DB                     : <INFO> Database opened: /home/raphael/.hyperhdr/db/hyperhdr.db
2022-09-23T20:42:56.259 JSONSERVER             : <DEBUG> JsonServer.cpp:24:JsonServer() | Created instance
2022-09-23T20:42:56.260 JSONSERVER             : <INFO> Started on port 19444
2022-09-23T20:42:56.260 FLATBUFSERVER          : <INFO> Started on port 19400
2022-09-23T20:42:56.260 FLATBUFSERVER          : <ERROR> Could not start local domain socket server 'hyperhdr-domain'
2022-09-23T20:42:56.260 WEBSERVER              : <INFO> Initialize Webserver
2022-09-23T20:42:56.260 WEBSERVER              : <INFO> Initialize Webserver
2022-09-23T20:42:56.261 WEBSERVER              : <INFO> Apply Webserver settings
2022-09-23T20:42:56.261 WEBSERVER              : <INFO> Set document root to: :/webconfig
2022-09-23T20:42:56.261 WEBSERVER              : <INFO> Apply Webserver settings
2022-09-23T20:42:56.261 WEBSERVER              : <INFO> Set document root to: :/webconfig
2022-09-23T20:42:56.261 WEBSERVER              : <INFO> Started on port 8090 name 'HyperHDR Webserver'
SLEEP HANDLER REGISTERED!
2022-09-23T20:42:56.263 SMOOTHING0             : <INFO> Clearing queued colors before: enabling
2022-09-23T20:42:56.263 SMOOTHING0             : <INFO> Smoothing queue is cleared
2022-09-23T20:42:56.263 COMPONENTREG0          : <INFO> Smoothing: enabled
2022-09-23T20:42:56.264 SMOOTHING0             : <INFO> Creating config (0) => type: Alternative, dirMode: false, pause: false, settlingTime: 150ms, interval: 20ms (50Hz), antiFlickTres: 0, antiFlickStep: 2, antiFlickTime: 0
2022-09-23T20:42:56.264 SMOOTHING0             : <INFO> Clearing queued colors before: enabling. Smoothing configuration changed: restarting timer.
2022-09-23T20:42:56.264 SMOOTHING0             : <INFO> Smoothing queue is cleared
2022-09-23T20:42:56.264 SMOOTHING0             : <INFO> Selecting config (0) => type: Alternative, dirMode: false, pause: false, settlingTime: 150ms, interval: 20ms (50Hz), antiFlickTres: 0, antiFlickStep: 2, antiFlickTime: 0
2022-09-23T20:42:56.264 SMOOTHING0             : <INFO> Selecting config (0) => type: Alternative, dirMode: false, pause: false, settlingTime: 150ms, interval: 20ms (50Hz), antiFlickTres: 0, antiFlickStep: 2, antiFlickTime: 0
2022-09-23T20:42:56.264 LEDDEVICE_WLED         : <INFO> Start LedDevice 'wled'.
2022-09-23T20:42:56.264 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:51:init() |
2022-09-23T20:42:56.264 LEDDEVICE_WLED         : <DEBUG> LedDevice.cpp:164:init() | deviceConfig: [{"colorOrder":"rgb","currentLedCount":305,"hardwareLedCount":305,"host":"<IP_ADDRESS>","maxRetry":60,"refreshTime":0,"type":"wled"}]
2022-09-23T20:42:56.264 LEDDEVICE_WLED         : <DEBUG> LedDevice.cpp:228:setRefreshTime() | RefreshTime updated to 0ms
2022-09-23T20:42:56.264 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:59:init() | DeviceType   : wled
2022-09-23T20:42:56.264 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:60:init() | LedCount     : 305
2022-09-23T20:42:56.264 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:63:init() | Max retry    : 60
2022-09-23T20:42:56.264 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:105:initRestAPI() |
2022-09-23T20:42:56.264 MUXER0                 : <INFO> Register new input 'System/SYSTEMGRABBER' with priority 245 as inactive
2022-09-23T20:42:56.265 COMPONENTREG0          : <INFO> System capture device: enabled
2022-09-23T20:42:56.265 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> PipewireGrabber.cpp:162:init() | init
2022-09-23T20:42:56.265 PIPEWIRE_SYSTEM:PIPEWI : <INFO> *************************************************************************************************
2022-09-23T20:42:56.265 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Starting Pipewire grabber. Selected: 'Pipewire System Dialog selection' (1) max width: 512 (512) @ 60 fps
2022-09-23T20:42:56.265 BOBLIGHT               : <INFO> Instance created
2022-09-23T20:42:56.265 PIPEWIRE_SYSTEM:PIPEWI : <INFO> *************************************************************************************************
2022-09-23T20:42:56.265 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Loading restoration token:
Pipewire: initialization invoked. Cleaning up first...
PipewireHandler: ScreenCast protocol version: 4
Sender: 1_3247
Pipewire: CreateSession finished
2022-09-23T20:42:56.267 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Started
2022-09-23T20:42:56.267 HYPERMANAGER           : <INFO> HyperHDR instance 'First LED instance' has been started
2022-09-23T20:42:56.267 DAEMON                 : <INFO> Unload CEC
Pipewire: Got response from portal CreateSession
Pipewire: SelectSources finished
Pipewire: Got response from portal SelectSources
Pipewire: Start finished
Pipewire: Got response from portal Start
No restoration token (portal protocol version 4 required and must be implemented by the backend GNOME/KDE... etc)
Pipewire: format property size 3840 x 2160
Connecting to Pipewire interface for stream: 3840 x 2160
Pipewire: state CONNECTING (1, 0)
Pipewire: core info reported. Version = 0.3.56
Pipewire: state PAUSED (2, 1)
Pipewire: got new video format selected
Pipewire: video format = 7 (Spa:Enum:VideoFormat:RGBx)
Pipewire: video size = 3840x2160 (RGB order = true)
Pipewire: framerate = 0/1
Pipewire: state STREAMING (3, 2)
2022-09-23T20:42:56.279 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:116:initRestAPI() | [1]
2022-09-23T20:42:56.279 LEDDEVICE_WLED         : <DEBUG> LedDevice.cpp:164:init() | deviceConfig: [{"colorOrder":"rgb","currentLedCount":305,"hardwareLedCount":305,"host":"<IP_ADDRESS>","maxRetry":60,"port":19446,"refreshTime":0,"type":"wled"}]
2022-09-23T20:42:56.279 LEDDEVICE_WLED         : <DEBUG> LedDevice.cpp:228:setRefreshTime() | RefreshTime updated to 0ms
2022-09-23T20:42:56.280 LEDDEVICE_WLED         : <DEBUG> ProviderUdp.cpp:69:init() | Successfully parsed <IP_ADDRESS> as an IP-address.
2022-09-23T20:42:56.280 LEDDEVICE_WLED         : <DEBUG> ProviderUdp.cpp:99:init() | UDP socket will write to <IP_ADDRESS>:19446
2022-09-23T20:42:56.280 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:94:init() | Hostname/IP  : <IP_ADDRESS>
2022-09-23T20:42:56.280 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:95:init() | Port         : 19446
2022-09-23T20:42:56.280 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:99:init() | [1]
2022-09-23T20:42:56.280 LEDDEVICE_WLED         : <DEBUG> LedDevice.cpp:102:enable() | Enable device
2022-09-23T20:42:56.280 LEDDEVICE_WLED         : <DEBUG> LedDevice.cpp:310:switchOn() | Switch on
2022-09-23T20:42:56.280 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:128:powerOn() |
2022-09-23T20:42:56.280 LEDDEVICE              : <DEBUG> ProviderRestApi.cpp:165:put() | PUT: [http://<IP_ADDRESS>/json/state] [{"on":true,"live":true}]
2022-09-23T20:42:56.281 WEBSERVER              : <INFO> Setup SSL certificate
2022-09-23T20:42:56.281 WEBSERVER              : <INFO> Setup private SSL key
2022-09-23T20:42:56.281 WEBSERVER              : <INFO> Started on port 8092 name 'HyperHDR Webserver'
2022-09-23T20:42:56.284 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Portal protocol version: 4
2022-09-23T20:42:56.284 SMOOTHING0             : <INFO> Using alternative smoothing procedure (0)
2022-09-23T20:42:56.333 MUXER0                 : <INFO> Priority 245 is now active
2022-09-23T20:42:56.333 MUXER0                 : <INFO> Set visible priority to 245
2022-09-23T20:42:56.333 IMAGETOLED0            : <INFO> Total index number is: 34080 (memory: 34080). User sparse processing is: disabled, image size: 480 x 270, area number: 230
2022-09-23T20:42:56.333 HYPERHDR0              : <INFO> New priority[245], previous [255]
2022-09-23T20:42:56.333 HYPERHDR0              : <INFO> New source available -> switch LED-Device on
2022-09-23T20:42:56.333 SMOOTHING0             : <INFO> Clearing queued colors before: enabling
2022-09-23T20:42:56.333 SMOOTHING0             : <INFO> Smoothing queue is cleared
2022-09-23T20:42:56.528 LEDDEVICE              : <DEBUG> ProviderRestApi.cpp:194:put() | PUT exit: [http://<IP_ADDRESS>/json/state] [{"on":true,"live":true}]
2022-09-23T20:42:56.528 LEDDEVICE              : <DEBUG> ProviderRestApi.cpp:383:getResponse() | Reply.httpStatusCode [200]
2022-09-23T20:42:56.528 LEDDEVICE_WLED         : <DEBUG> LedDevice.cpp:102:enable() | Enable device
2022-09-23T20:42:56.528 COMPONENTREG0          : <INFO> LED device: enabled
2022-09-23T20:42:56.528 EFFECTENGINE0          : <INFO> Run effect "Rainbow swirl fast" on channel 0
2022-09-23T20:42:56.528 EFFECTENGINE0          : <DEBUG> EffectEngine.cpp:174:runEffectScript() | Start the effect: name [Rainbow swirl fast], smoothCfg [2]
2022-09-23T20:42:56.528 MUXER0                 : <INFO> Register new input 'System/EFFECT' with priority 0 as inactive
2022-09-23T20:42:56.529 HYPERHDR               : <INFO> Initial foreground effect 'Rainbow swirl fast' started
2022-09-23T20:42:56.529 SMOOTHING0             : <INFO> Using alternative smoothing procedure (0)
2022-09-23T20:42:56.529 MUXER0                 : <INFO> Set visible priority to 0
2022-09-23T20:42:56.529 SMOOTHING0             : <INFO> Clearing queued colors before: enabling. Smoothing configuration changed: restarting timer.
2022-09-23T20:42:56.529 SMOOTHING0             : <INFO> Smoothing queue is cleared
2022-09-23T20:42:56.529 SMOOTHING0             : <INFO> Selecting config (2) => type: Linear, dirMode: false, pause: false, settlingTime: 200ms, interval: 40ms (25Hz), antiFlickTres: 0, antiFlickStep: 0, antiFlickTime: 0
2022-09-23T20:42:56.529 SMOOTHING0             : <INFO> Using linear smoothing input (2)
2022-09-23T20:42:56.529 HYPERHDR0              : <INFO> New priority[0], previous [245]
2022-09-23T20:42:56.529 EFFECT0(Rainbo...)     : <INFO> Begin playing the effect with priority: 0
2022-09-23T20:42:56.530 MUXER0                 : <INFO> Priority 0 is now active
2022-09-23T20:42:56.530 IMAGETOLED0            : <INFO> Total index number is: 1000 (memory: 1000). User sparse processing is: disabled, image size: 80 x 45, area number: 230
2022-09-23T20:42:56.569 SMOOTHING0             : <INFO> Using linear smoothing procedure (2)
Local IPv4 address: <IP_ADDRESS>
Local IPv4 address: <IP_ADDRESS>
Local IPv4 address: <IP_ADDRESS>
Opened 3 sockets for mDNS query
Sending mDNS query : _hyperhdr-http._tcp.local PTR
Reading mDNS query replies
Local IPv4 address: <IP_ADDRESS>
Local IPv4 address: <IP_ADDRESS>
Local IPv4 address: <IP_ADDRESS>
Opened 3 sockets for mDNS query
Sending mDNS query : _hue._tcp.local PTR
Reading mDNS query replies
Local IPv4 address: <IP_ADDRESS>
Local IPv4 address: <IP_ADDRESS>
Local IPv4 address: <IP_ADDRESS>
Opened 3 sockets for mDNS query
Sending mDNS query : _wled._tcp.local PTR
Reading mDNS query replies
Local IPv4 address: <IP_ADDRESS>
Opened 2 sockets for mDNS service
Service mDNS: _hyperhdr-http._tcp.local.:8090
Hostname: beauregard
Sending announce
2022-09-23T20:42:57.857 WEBSOCKET              : <DEBUG> WebSocketClient.cpp:30:WebSocketClient() | New connection from ::ffff:<IP_ADDRESS>
2022-09-23T20:42:57.857 WEBSOCKET              : <DEBUG> JsonAPI.cpp:96:handleInstanceSwitch() | Client '::ffff:<IP_ADDRESS>' switch to HyperHDR instance 0
2022-09-23T20:42:57.922 DB                     : <INFO> Database opened: /home/raphael/.hyperhdr/db/hyperhdr.db
2022-09-23T20:42:58.001 WEBSOCKET              : <DEBUG> WebSocketClient.cpp:30:WebSocketClient() | New connection from ::ffff:<IP_ADDRESS>
2022-09-23T20:42:58.001 WEBSOCKET              : <DEBUG> JsonAPI.cpp:96:handleInstanceSwitch() | Client '::ffff:<IP_ADDRESS>' switch to HyperHDR instance 0
2022-09-23T20:42:58.206 WEBSOCKET              : <DEBUG> JsonAPI.cpp:1633:handleLedDeviceCommand() | message: [{"command":"leddevice","ledDeviceType":"wled","subcommand":"discover","tan":436}]
2022-09-23T20:42:58.206 LEDDEVICE_WLED         : <DEBUG> LedDeviceWled.cpp:228:discover() | devicesDiscovered: [{"devices":[],"ledDeviceType":"wled"}]
2022-09-23T20:42:58.206 WEBSOCKET              : <DEBUG> JsonAPI.cpp:1657:handleLedDeviceCommand() | response: [{"devices":[],"ledDeviceType":"wled"}]
2022-09-23T20:42:59.543 EFFECT0(Rainbo...)     : <INFO> The effect quits with priority: 0
2022-09-23T20:42:59.543 MUXER0                 : <INFO> Removed source priority 0
2022-09-23T20:42:59.544 MUXER0                 : <INFO> Set visible priority to 245
2022-09-23T20:42:59.544 IMAGETOLED0            : <INFO> Total index number is: 34080 (memory: 34080). User sparse processing is: disabled, image size: 480 x 270, area number: 230
2022-09-23T20:42:59.544 HYPERHDR0              : <INFO> New priority[245], previous [0]
2022-09-23T20:42:59.544 EFFECTENGINE0          : <INFO> Effect 'Rainbow swirl fast' has finished.
2022-09-23T20:42:59.544 EFFECT0(Rainbo...)     : <INFO> Deleting effect named: 'Rainbow swirl fast'
2022-09-23T20:42:59.544 EFFECT0(Rainbo...)     : <INFO> Effect named: 'Rainbow swirl fast' is deleted
2022-09-23T20:42:59.544 SMOOTHING0             : <INFO> Clearing queued colors before: enabling. Smoothing configuration changed: restarting timer.
2022-09-23T20:42:59.544 SMOOTHING0             : <INFO> Smoothing queue is cleared
2022-09-23T20:42:59.544 SMOOTHING0             : <INFO> Selecting config (0) => type: Alternative, dirMode: false, pause: false, settlingTime: 150ms, interval: 20ms (50Hz), antiFlickTres: 0, antiFlickStep: 2, antiFlickTime: 0
2022-09-23T20:42:59.544 SMOOTHING0             : <INFO> Using alternative smoothing input (0)
2022-09-23T20:42:59.564 SMOOTHING0             : <INFO> Using alternative smoothing procedure (0)
Read 0 records
Closed sockets
Read 0 records
Closed sockets
Read 0 records
Closed sockets
2022-09-23T20:44:00.013 PERFORMANCE            : <INFO> [INSTANCE0: FPS = 62.50, processed = 3750], [LED0: FPS = 50.00, send = 3000, processed = 3000]
2022-09-23T20:44:28.516 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Restarting video grabber is now blocked due to reloading of the configuration
2022-09-23T20:44:28.516 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Delayed restart of the grabber due to change of the framerate
2022-09-23T20:44:28.516 SIGNAL_OLD             : <DEBUG> DetectionManual.cpp:85:setSignalDetectionOffset() | Signal detection area set to: 0.250000,0.250000 x 0.750000,0.750000
2022-09-23T20:44:28.516 SIGNAL_OLD             : <DEBUG> DetectionManual.cpp:75:setSignalThreshold() | Signal threshold set to: {0, 0, 0} and frames: 50
2022-09-23T20:44:28.516 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> Grabber.cpp:272:unblockAndRestart() | Planned restart of video grabber after reloading of the configuration
Pipewire: got new video format selected
Pipewire: state PAUSED (2, 3)
Pipewire: state UNCONNECTED (0, 2)
Pipewire: handle (/org/freedesktop/portal/desktop/session/1_3247/hyperhdr_s2c869e9ff7e24b07bd0492d1b90cf31e) released
Pipewire: driver is closed now
2022-09-23T20:44:28.519 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Stopped
2022-09-23T20:44:28.519 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> PipewireGrabber.cpp:153:uninit() | Uninit grabber: Pipewire System Dialog selection
2022-09-23T20:44:28.519 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> PipewireGrabber.cpp:162:init() | init
2022-09-23T20:44:28.519 PIPEWIRE_SYSTEM:PIPEWI : <INFO> *************************************************************************************************
2022-09-23T20:44:28.519 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Starting Pipewire grabber. Selected: 'Pipewire System Dialog selection' (1) max width: 512 (512) @ 30 fps
2022-09-23T20:44:28.519 PIPEWIRE_SYSTEM:PIPEWI : <INFO> *************************************************************************************************
2022-09-23T20:44:28.519 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Loading restoration token:
Pipewire: initialization invoked. Cleaning up first...
PipewireHandler: ScreenCast protocol version: 4
Sender: 1_3247
Pipewire: CreateSession finished
2022-09-23T20:44:28.522 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Started
Pipewire: Got response from portal CreateSession
Pipewire: SelectSources finished
Pipewire: Got response from portal SelectSources
Pipewire: Start finished
Pipewire: Got response from portal Start
No restoration token (portal protocol version 4 required and must be implemented by the backend GNOME/KDE... etc)
Pipewire: format property size 3840 x 2160
Connecting to Pipewire interface for stream: 3840 x 2160
Pipewire: state CONNECTING (1, 0)
Pipewire: core info reported. Version = 0.3.56
Pipewire: state PAUSED (2, 1)
Pipewire: got new video format selected
Pipewire: video format = 7 (Spa:Enum:VideoFormat:RGBx)
Pipewire: video size = 3840x2160 (RGB order = true)
Pipewire: framerate = 0/1
Pipewire: state STREAMING (3, 2)
2022-09-23T20:44:28.555 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Portal protocol version: 4
2022-09-23T20:45:22.552 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Restarting video grabber is now blocked due to reloading of the configuration
2022-09-23T20:45:22.552 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Delayed restart of the grabber due to change of the framerate
2022-09-23T20:45:22.552 SIGNAL_OLD             : <DEBUG> DetectionManual.cpp:85:setSignalDetectionOffset() | Signal detection area set to: 0.250000,0.250000 x 0.750000,0.750000
2022-09-23T20:45:22.552 SIGNAL_OLD             : <DEBUG> DetectionManual.cpp:75:setSignalThreshold() | Signal threshold set to: {0, 0, 0} and frames: 50
2022-09-23T20:45:22.552 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> Grabber.cpp:272:unblockAndRestart() | Planned restart of video grabber after reloading of the configuration
Pipewire: got new video format selected
Pipewire: state PAUSED (2, 3)
Pipewire: state UNCONNECTED (0, 2)
Pipewire: handle (/org/freedesktop/portal/desktop/session/1_3247/hyperhdr_s335e7b37e4664dcfb9bd981ac9fd968c) released
Pipewire: driver is closed now
2022-09-23T20:45:22.555 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Stopped
2022-09-23T20:45:22.555 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> PipewireGrabber.cpp:153:uninit() | Uninit grabber: Pipewire System Dialog selection
2022-09-23T20:45:22.555 PIPEWIRE_SYSTEM:PIPEWI : <DEBUG> PipewireGrabber.cpp:162:init() | init
2022-09-23T20:45:22.555 PIPEWIRE_SYSTEM:PIPEWI : <INFO> *************************************************************************************************
2022-09-23T20:45:22.555 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Starting Pipewire grabber. Selected: 'Pipewire System Dialog selection' (1) max width: 512 (512) @ 15 fps
2022-09-23T20:45:22.555 PIPEWIRE_SYSTEM:PIPEWI : <INFO> *************************************************************************************************
2022-09-23T20:45:22.555 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Loading restoration token:
Pipewire: initialization invoked. Cleaning up first...
PipewireHandler: ScreenCast protocol version: 4
Sender: 1_3247
Pipewire: CreateSession finished
2022-09-23T20:45:22.557 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Started
Pipewire: Got response from portal CreateSession
Pipewire: SelectSources finished
Pipewire: Got response from portal SelectSources
Pipewire: Start finished
Pipewire: Got response from portal Start
No restoration token (portal protocol version 4 required and must be implemented by the backend GNOME/KDE... etc)
Pipewire: format property size 3840 x 2160
Connecting to Pipewire interface for stream: 3840 x 2160
Pipewire: state CONNECTING (1, 0)
Pipewire: core info reported. Version = 0.3.56
Pipewire: state PAUSED (2, 1)
Pipewire: got new video format selected
Pipewire: video format = 7 (Spa:Enum:VideoFormat:RGBx)
Pipewire: video size = 3840x2160 (RGB order = true)
Pipewire: framerate = 0/1
Pipewire: state STREAMING (3, 2)
2022-09-23T20:45:22.623 PIPEWIRE_SYSTEM:PIPEWI : <INFO> Portal protocol version: 4

@awawa-dev  sure no problem, here are the logs from a run where this happened. I've restarted pipewire in the middle of it as you can see.

As for the token, you don't actually need one for every current xdg-portal that is out there. xdg-portal-desktop-wlr for example has a config option to always choose a specific output without user interaction:

That way no token or refresh is required, so it should work with HyperHDR as well.

Thanks. Didn't know that it's possible for user to overcome that behavior when Portal ask you every time to select and confirm which monitor to capture (and save it for later usage, that crucial option is provided by properly implemented protocol 4, currently works only in Gnome Portal implementation I think). Beside that missing token logs looks normal, the Pipewire stream seems OK and HyperHDR is receiving "something" from Pipewire because it holds to priority 245 (system grabber in your case).

@awawa-dev  Super weird then. Can I increase the log level or something so that we can find out why exactly the screen capture stops working?

For the application the stream is active, the portal error callback was not invoked so everything is "fine" and there is no way to increase log level by some settings: everything in that grabber is set to high level and logs to console almost everything. But you can add a line to https://github.com/awawa-dev/HyperHDR/blob/785fc77d17cdcb53871bac6070408623be6758fa/sources/grabber/pipewire/PipewireHandler.cpp#L586 to make sure something indeed is received e.g. std::cout << "Pipewire: new frame is received" << std::endl;

Alright thanks, will do that and report back !

One more thing: 3840 x 2160 is quite a lot but it should works if there are necessary resource. Try to test it with 1080p and lower capturing rate to 10 or something.

@awawa-dev How do I lower that? In the settings it is already 512px.

I meant your OS desktop resolution to test it and rule out resouces. Framerate you can set in HyperHDR. Observe htop usage.

Oh my cpu usage is absolutely fine with the capturing, this is a pretty beefy desktop pc.

Maybe something gets messed up during transport to my WLED instance? But hyperion-ng did that without problems so it should work here as well.
I guess I will try and log the pipewire frame and then go from there.

Oh my cpu usage is absolutely fine with the capturing, this is a pretty beefy desktop pc.
The problem could be not in CPU. It's worth to test it.

Forget WLED or any other LED driver, for 99% it's not related but you can set LED driver to debug/file if you want.

Because there is no trace of the crash or any other HyperHDR problem in the logs, I move it to the discussion.


Remove bucketServerLocation if timeout error

@echobravopapa @pdxcodemonkey This is the PR with the change regarding the client metadata update when there is a timeout error that I mentioned in the dev list

@pdxcodemonkey @echobravopapa Have you had the opportunity to check how could I add a test to verify this?
What if I create a separate ticket for the test case and this change is merge in the meanwhile? As after a timeout there is always a IO error, this change seems an improvement in the current situation when that happens, as it is in our case.

I will use a separated ticket and branch for this issue, so im closing this PR. New one is here https://github.com/apache/geode-native/pull/662


Error in the docs regarding collection2

The docs of this package read:
This package is currently included automatically with the aldeed:collection2 package.

but this is not true. The aldeed:collection2 package does not include a reference to aldeed:schema-index. It has to be installed manually.

same


Fix Memory Leak in Compile

Fix Memory Leak in Compile
Parse Memory: 2254360
Parse Memory: 3318685
Parse Memory: 3550415
Parse Memory: 4172510
Parse Memory: 4242092
Parse Memory: 4940764
Parse Memory: 5816199
Parse Memory: 6316315
Parse Memory: 7182689
Parse Memory: 10975061
Parse Memory: 11160205
Parse Memory: 12049336
Parse Memory: 14402135
Parse Memory: 15857080
Parse Memory: 15972298
Parse Memory: 17555590
Parse Memory: 17679865
Parse Memory: 17688961
Preprocess Memory: 119783088
Typecheck Memory: 421119714
Compile Memory:<PHONE_NUMBER>

Sort of high across the board, but really bad in compilation.

I think this is related to unnecessary closes that were required to evade the missing feature of large returns. To fix this it is important to understand that opens are free but only close costs memory.

This is probably 95% coming from unification attempts in lookup.

Next suspect is chain maybe?

Somewhere unify-ctx is too heavy. This seems to be a big factor still.


Convert Banner to Variants

Variants in Figma

[x] Add documentation link

Variant properties:
Dark theme: True/False
Variant: Text/Text + icon/Actions

Looking good @benkeq


Feature Request: Monitoring Capability for SuperDuperDB

Why
Currently, SuperDuperDB lacks a monitoring capability, which is crucial for tracking activities and ensuring the integrity and performance of deployed models on databases. To address this limitation, I propose implementing a monitoring feature that enables users to easily monitor changes and detect potential issues in their database collections.
How
I suggest introducing a new API contract for the monitoring feature in SuperDuperDB. The proposed API structure is as follows:
config = MonitorConfig(drift='all', psi=True, summarize=True)

watcher = MonitorWatcher(identifier='my-monitor', select=Collection('test_collection').find(), reference=Collection('training_data').find(), config=config, every='1hr')
db.add(watcher)

The MonitorConfig class allows users to configure various monitoring options such as drift detection ('all'), population stability index (PSI) calculation (psi=True), and summary generation (summarize=True). The MonitorWatcher class represents a monitoring job and includes parameters like an identifier for the monitor, the selection criteria for the monitored collection (select), the reference collection for comparison (reference), the monitoring configuration (config), and the frequency of monitoring (every='1hr').
Once this feature is implemented, any activity on the defined collection will trigger the corresponding monitoring job, allowing users to track changes, identify potential drift, and maintain the accuracy and performance of their deployed models.
Expected Benefits
The addition of monitoring capabilities to SuperDuperDB offers several benefits, including:
Enhanced Model Performance: Users can effectively track and monitor database collections, ensuring the accuracy and performance of deployed models over time.
Automated Detection of Drift: The monitoring feature automatically detects drift in the monitored collection, helping users identify changes that may impact model predictions.
Population Stability Index (PSI) Calculation: PSI calculation provides a statistical measure of population changes, allowing users to assess the stability of their data and take appropriate actions if significant shifts occur.
Summary Generation: Users can obtain summary reports detailing the detected changes and overall model performance, facilitating better decision-making and troubleshooting.
Implementation Details
To implement the monitoring capability, the following steps are proposed:

Create the MonitorConfig and MonitorWatcher classes that encapsulate the necessary parameters and functionality for monitoring.
Integrate the monitoring API into SuperDuperDB's existing codebase, ensuring compatibility and adherence to coding standards.
Implement the logic to trigger monitoring jobs based on defined configurations and frequencies.
Develop the drift detection, PSI calculation, and summary generation mechanisms to provide valuable insights to users.
Write comprehensive unit tests to ensure the accuracy and robustness of the monitoring feature.
Update the SuperDuperDB documentation to include instructions and examples on how to utilize the monitoring capabilities.

Additional Considerations
While implementing this feature, the following points should be taken into account:
Scalability: Ensure that the monitoring feature is optimized to handle large database collections without compromising performance.
Flexibility: Consider providing additional configuration options and customization capabilities to cater to diverse monitoring requirements.
Error Handling: Implement appropriate error handling mechanisms and clear error messages to aid users in troubleshooting potential issues.
Related Issues and Dependencies
This feature request does not have any direct dependencies on existing issues. However, it may be beneficial to coordinate with the SuperDuperDB team to ensure alignment with the project roadmap and avoid any potential conflicts with ongoing development.
cc @blythed @fkiraly

With the new features on the @trigger branch: https://github.com/superduper-io/superduper/pull/2434,
we will be able to easily build triggers to force recalculation of metrics.


Maya: Refactor Extract Look with dedicated processors for maketx

Changelog Description
Refactor Maya extract look to fix some issues:

[x] Allow Extraction with maketx with OCIO Color Management enabled in Maya.
[x] Fix file hashing so it includes arguments to maketx, so that when arguments change it correctly generates a new hash
[x] Fix maketx destination colorspace when OCIO is enabled
[x] Use pre-collected colorspaces of the resources instead of trying to retrieve again in Extract Look
[x] Fix colorspace attributes being reinterpreted by maya on export (fix remapping) - goal is to resolve #2337
[x] Fix support for checking config path of maya default OCIO config (due to using lib.get_color_management_preferences which remaps that path)
[x] Merged in #2971 to refactor MakeTX into TextureProcessor and also support generating Redshift .rstexbin files. - goal is to resolve #2599
[x] Allow custom arguments to maketx from OpenPype Settings like mentioned here by @fabiaserra for arguments like: --monochrome-detect, --opaque-detect, --checknan.
[x] Actually fix the code and make it work. :) (I'll try to keep below checkboxes in sync with my code changes)

[x] Publishing without texture processor should work (no maketx + no rstexbin)
[x] Publishing with maketx should work
[x] Publishing with  rstexbin should work

[ ] Test it.

Additional info
~Please note: It's currently WIP draft and will not work as is - hound will likely go crazy too if it sees some of my "WIP commits with todos" in them.~
~I'm only opening as draft so others know there's work in progress plus maybe get some comments in about features that I might have missed that should be in here.~
Current state should be usable but it's quite a big refactor I've done relatively quickly so I'd say definitely give it a thorough look over the code to comment on anything that stands out and test the different test cases of the testing notes below.
Testing notes:

Start Maya
Extract Looks with textures, considering cases like:

Extract without making tx files (with and without maya color management enabled)
Extract with making tx files (with and without maya color management enabled)
Extract with making rstexbin (with and without maya color management enabled)
Test in Maya 2020 (Py2) and Maya 2022 or 2023 (Py3)
Colors spaces and colors should be preserved or correctly set for the published texture (and also be correctly preserved in the look workfile after publishing)
Colors should render as intended from the lookdev, should have no color shifts
Try setting project_settings/maya/publish/ExtractLook/maketx_arguments to additional arguments for maketx and make sure they are used during the maketx conversion.

Can't test it, but codewise looks much better (and explicit) than previous state.


A datetimepicker in a table will replace all table cells with a date value (suggested fix included)

Version 3.1.3
Steps to reproduce:

Create a HTML table with a few rows of fake data.
Add a datetimepicker in one of the table cells

Expected result:

The datetimepicker renders a picker in one cell

Actual result:

All table cells are replaced with a string value representing the datetimepicker's default value.

Suggested fix: Replace '.parents("table")' with '.closest("table")' in this block:
yearCont = picker.widget.find('.datepicker-years').find(
    'th:eq(1)').text(year + '-' + (year + 9)).parents('table').find('td');

Please try V4 and post a jsfiddle with your issue

I ran into this as well.  Probably won't upgrade to v4 due to trajectory of project.


(paper) Support more Minecraft versions

This PR adds support for 1.19.1 and (very likely) future Minecraft versions, and replaces NMS-dependent recentTps field with Paper's getTPS().

I was already working on multi-version support using reflection with some commits still unpushed, but it seems that this solution is simpler and works, thank you very much