Topology validation failed. hosts mapped to multiple host groups

Hi,
After fixing the issue https://github.com/hortonworks/ansible-hortonworks/issues/52
Reran the apply-blueprint.sh -vvv
Got error like "Topology validation failed: org.apache.ambari.server.topology.InvalidTopologyException: the following hosts are mapped to multiple host groups: [hostsA]...."
Meanwhile, indeed 'hostA' is mapped into the "hdp-management" group and the "hdp-masternode-01"
I guess that's the problem. The things is that i have 2 NN one of which i'd like to use to host also KNOX/ZEPPELIN/RANGER/ATLAS/KERBEROS, and key the 4 DN to host the HBASE_REGIONSERVER and SOLR instances
so i moved the ambari-server/knox/zeppelin/ranger/atlas to the hdp-masternode-02 along with the SECONDARY_NAMENODE service.
Running

apply_blueprint.sh -vvv --check

leads to "Fail if could not get a VersionDefinition from Ambari"
yet the playbook/group_vars/all contains the definition

ambari_version: '<IP_ADDRESS>'

would appreciate if you could provide some guidance on this
thanks

Hi, that last error seems to indicate that the version definition was not uploaded. This happens in the ambari-config role: https://github.com/hortonworks/ansible-hortonworks/blob/master/playbooks/roles/ambari-config/tasks/main.yml#L156
So, can you re-run ./configure_ambari.sh and make sure it finishes successfully and then ./apply_blueprint.sh ?

Hmm, it's still strange you had that issue with hdp-management group. I remember testing that blueprint and worked fine.
Regarding uninstalling, wouldn't be easier to just rebuild the nodes (that is, if you're using some sort of cloud of course)?
And about SOLR_SERVER, do you actually want to install HDP Search / Solr as well? If that's so, you'd also need to re-run the configure_ambari.sh script as the ambari-config role would install the HDP Search mpack: https://github.com/hortonworks/ansible-hortonworks/blob/master/playbooks/roles/ambari-config/tasks/main.yml#L43

unfortunately, we are using bare metal hosts. So, i guess, we are left with no other option than clean manually the hosts.
As for the SOLR_SERVER, the mpack was already installed (as i tried manually the following command :

sudo ambari-server install-mpack --mpack=http://public-repo-1.hortonworks.com/HDP-SOLR/hdp-solr-ambari-mp/solr-service-mpack-3.0.0.tar.gz
Using python  /usr/bin/python
Installing management pack
2018-10-01 14:59:54,557 - Execute[('tar', '-xf', '/var/lib/ambari-server/data/tmp/solr-service-mpack-3.0.0.tar.gz', '-C', '/var/lib/ambari-server/data/tmp/')] {'tries': 3, 'sudo': True, 'try_sleep': 1}
ERROR: Management pack solr-ambari-mpack-3.0.0 already installed!
ERROR: Exiting with exit code -1.
REASON: Management pack solr-ambari-mpack-3.0.0 already installed!

yet theservice doesn't appear in the list of services to be deployable in ambari's add new service.

Are you using HDP 2.6.X / Ambari 2.6.X? (can you double check as well?)
HDP Search <IP_ADDRESS> doesn't work on HDP 3/ Ambari 2.7.
Other than that... no idea, something must be messed up in your ambari. Try to clean it as much as you can (yum remove, rm -rf /var/lib/ambari* /usr/lib/ambari*, drop the ambari database, etc).

thanks for your replies.
sorry to hear that SOLR is not supported on HDP 3; Hopefully some times soon

@madiot @alexandruanghel I am happy to inform you that SOLR(_SERVER) component indeed works on HDP-3.0.1, but of course you need v4
# On HDP-3.0.1 you need HDP Search v4, see: https://docs.hortonworks.com/HDPDocuments/HDPS/HDPS-4.0.0/bk_solr-search-installation/content/hdp-search40-public-repos.html
hdpsearch_version: '4.0.0'                                # must be the full version number
hdpsearch_build_number: '400'                             # the HDP Search build number from docs.hortonworks.com ...

# and the latest HDP/HDF versions
ambari_version: '<IP_ADDRESS>'                                 # must be the 4-part full version number
hdp_version: '<IP_ADDRESS>'                                    # must be the 4-part full version number
hdf_version: '<IP_ADDRESS>'                                    # must be the 4-part full version number

I just deployed a new cluster (with latest master) and above custom values, and looks good

Yes @lhoss @madiot correct :) HDPSearch 4 was released which brings support for HDP3 (you'd still have to use HDPSearch 3 for HDP2).
https://docs.hortonworks.com/HDPDocuments/HDPS/HDPS-4.0.0/bk_solr-search-installation/content/hdp_solr_search_40-relnotes-new-features.html
So yes, we should update those variables, I was only waiting to do another round of version bump once HDP 3.0.3 was going to be released, which should happen any day now

I was only waiting to do another round of version bump once HDP 3.0.3 was going to be released, which should happen any day now

OK, looking fwd 👍
HDP 3.0.3 ? is 3.0.2 skipped ? :D


Improve documentation about font fallback

See discussion in https://github.com/Alexays/Waybar/pull/364. The existing font list in the default style and examples doesn't seem to be very useful.
I would recommend only listing a single font, if any, in the default style / examples, and add a comment to the css files that explains how to create a custom font or configure fontconfig to make icons work consistently.

I'll try to check why gtk failed to pick some icon.


[📚] Notice for archived docs is missing for firebase_messaging

https://firebase.flutter.dev/docs/messaging/overview

Will be fixed with: https://github.com/firebase/flutterfire/pull/8874


Add LazyLedger as Data Availability layer

[x] DA layer interface + ADR
[ ] LazyLedger DA implementation
[ ] ADR for LL DA

Resolves #64

Codecov Report

Merging #53 (ca395c1) into main (bc1ca00) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #53   +/-   ##
=======================================
  Coverage   60.77%   60.77%
=======================================
  Files          14       14
  Lines         872      872
=======================================
  Hits          530      530
  Misses        280      280
  Partials       62       62

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 bc1ca00...ca395c1. Read the comment docs.

Closing in favor of #71, #72, #73 (and probably more)

Closing in favor of #71, #72, #73 (and probably more)


Route::resource and apiResource interfering with get routes

Laravel Version: 8.11.2
PHP Version: 7.4.5

Description:
Adding new get routes below a previous resource route will result in a 404 not found error
Steps To Reproduce:
In web.php i had:
	Route::apiResource('encuestas', SurveyController::class);
	Route::get('encuestas/covid', [SurveyController::class, 'covid'])->name('encuestas.covid');
	Route::get('encuestas/tos', [SurveyController::class, 'cough'])->name('encuestas.cough');
	Route::get('encuestas/temperatura', [SurveyController::class, 'temperature'])->name('encuestas.temperature');

With this configuration any attempt to enter to any new encuestas named routes will result in a 404 not found error, to fix it i had to setup in this configuration (moving apiResource to the end) :
	Route::get('encuestas/covid', [SurveyController::class, 'covid'])->name('encuestas.covid');
	Route::get('encuestas/tos', [SurveyController::class, 'cough'])->name('encuestas.cough');
	Route::get('encuestas/temperatura', [SurveyController::class, 'temperature'])->name('encuestas.temperature');
	Route::apiResource('encuestas', SurveyController::class);

This bug will also appear using resource instead of apiResource

It is not a bug. I'd say it is a limitation. The
Route::apiResource('encuestas', SurveyController::class);`

Will register several routes under the hood. One of them, to retrieve a single resource, will be:
GET /encuestas/{encuesta}

Which accepts a second parameter that can be anything.
So when the router tries to match this path: /encuestas/covid, if API Resource is defined before the route you expected, the router will match this path against /encuestas/{encuesta} and will try to run the associated controller action  (SurveyController@show).
There are a couple of ways you could avoid it, one is using route parameter constraints:
https://laravel.com/docs/8.x/routing#parameters-global-constraints
So the pattern is more unlikely to be match, if for example your model identifier is an integer or an UUID.
But I think the easiest solution is to define routes with dynamic paths before routes with static paths.

See above.


Update application-gateway-diagnostics.md

adding TLS version for easier searching

@dcbrown16 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@dcbrown16 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


[5.8] Adding toResponseArray to Resources

In my use case i want to use Pagination with Resources but i want an Array instead of a JsonResponse, because i want to inject the data as props in a Vue Compoenent.
Currently there is no way of fetching the Pagination Data, only as JsonResponse.
My change doesn't change anything, it only introduces a new method for getting array instead of JsonResponse.

Curious how you are trying to use this that doesn't work as-is?

If you want to use something like:
return view('something', ['data' => Resource::collection(Model::paginate())])

And you want to inject this to a Vue Component as prop, you can't transform it on the same format as you get when you return that directly from your controller, what i want is to the same return i would have, something like:
        [
            'data' => [
                [
                    'id' => 5,
                    'title' => 'Test Title',
                    'custom' => true,
                ],
            ],
            'links' => [
                'first' => '/?page=1',
                'last' => '/?page=1',
                'prev' => null,
                'next' => null,
            ],
            'meta' => [
                'current_page' => 1,
                'from' => 1,
                'last_page' => 1,
                'path' => '/',
                'per_page' => 15,
                'to' => 1,
                'total' => 10,
            ],
        ]

So i could work the same for when it comes from prop or from ajax.

Please could you test it with nested resources?
Because I think you will not have a plain recursive array with your implementation, only the first level and then nested objects or resources.
On my side, for testing purposes, I've implemented it with a simple
public function parse(): ?array
{
    if (!$this->resource) {
        return null;
    }

    return jsonDecode(jsonEncode($this));
}

But I'm sure we can do better than that.

Well i'm using the very same implementation as the one that generates the response, so i can't see a reason to not work, but i'll do some more testing later today.

@dbpolito the main difference is that the recursivity is handled directly by json_encode, jsonSerializing automatically all the nested objects.
@taylorotwell I think you merged something that doesn't work... 😕

@mathieutu Well, won't it work because it will be casted as array? json_encode basically calls toArray, the logic should be the same.
Can you give me an resource example with nested resource so i can test?

I think you didn't understand my point.
It's about recursivity. json_encode is natively made to handle recursivity to construct proper json until the last nested object, calling jsonSerialize on all of them.
JsonResources use that principle, and it's standard to have nested objects in them because of relations.
I let you try with this updated test: https://gist.github.com/62f8859cc8396a38d3da669ab23547f4
So @taylorotwell I can confirm that this PR isn't working. For now only a json_decode(json_encode(..)) can do the job.

Now i see, i'm experimenting a possible fix.

I've reverted this PR. Please try to resubmit once all concerns stated here and in the other PR are taken care of.


Introducing Sqlite database for wikiwoods.

This PR introduces an sqlite database for wikiwoods
and a script to convert a wikiwoods.dm file into database file - so next time when we want to update the wikiwoods with a new wikiwoods.dm file, just put the wikiwoods.dm  file in the top project and run python create_wikiwoods_db.py also I've included wikiwoods.dm file in the .gitignore.
Also includes ORM files for db access (model.py)
updated the findBestPears.py and scorePages.py to reflect the database migration.

Cool! Way to go @stultus ! LGTM!
Happy to merge. But will let others review too. :)

I've pushed this change to heroku app as well.

Very excited about this but I'm in the middle of a research grant deadline, so won't have proper look. Please merge! And yeah!


Fix detection of libstdc++ with multiple installed

With more than one result in libstdcpp_path readlink fails. Reverse sort results and take first to hopefully use newest.
Fixes microsoft#203967

@n8falke with the recent change merged from https://github.com/microsoft/vscode/pull/204032, is this changed required ? Can you clarify why sorting is needed ? Does ldconfig use the same sort order when resolving the library ?

It's good to look for the latest version.  E.g. I have Ubuntu 20.04 with Ubuntu 18.04 library for software compatibility.   Unfortunately this patch might not work.  The sort should happen AFTER the versions are extracted, (after readlink).  Sorting the symbolic links don't guarantee picking up the latest version.

Patch in pull request https://github.com/microsoft/vscode/pull/204221

Closing in favor of https://github.com/microsoft/vscode/pull/204221
@n8falke please test if the fix in the linked PR works for your scenario as well. Thanks!

On my system https://github.com/microsoft/vscode/pull/204221 works fine. I can not test the libc.so.6 part.


Fix this script does not work on Python 2.7

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
sudo python get-pip.py
Fix error

ERROR: This script does not work on Python 2.7 The minimum supported Python version is 3.6. Please use https://bootstrap.pypa.io/2.7/get-pip.py instead.

The correct url is https://bootstrap.pypa.io/pip/2.7/get-pip.py instead of https://bootstrap.pypa.io/2.7/get-pip.py


upgrade is one of the commands, expose it!

Adds in upgrade to the list of bash completions. Once we switch to kingpin this can be automated while keeping our fancy completions for versions, aliases, etc.

:+1:


Fix directives for checking TS_USE_TLS_OCSP

#ifdef directives for TS_USE_TLS_OCSP doesn't make sense. Because TS_USE_* are defined as 0 or 1, unlike HAVE_OPENSSL_* nor OPENSSL_NO_* (these are defined or undefined).
https://github.com/apache/trafficserver/blob/5b86099e66221d2786ba09b5a432f8d73619cf35/include/tscore/ink_config.h.in#L83

[approve ci debian]


Share center in embedded browser

Description:
We want to test Proof-of-concept of a specific Share Center feature that we are building to Web UI.
We would like to add menu item to this page under Developer Settings, so we can see if the page would work correctly.
This page URL is on Dev Station web: devstation.ruuvi.com/shares
Related to: https://github.com/ruuvi/com.ruuvi.station.webui/issues/317

QA passed, seems to work reliably, we will need to likely finetune later on before moving this visible in the build.


YARD-Coverage being reported inconsistently

I have encountered an issue with the Yardstick::Rake::Verify. When I run my rake task, the output is as follows:
$ bundle exec rake yard:verify
YARD-Coverage: 82.3% (threshold: 100%)
rake aborted!
YARD-Coverage must be at least 100% but was 81.7%

After the first time #total_coverage is called, inYardstick::Rake::Verify#verify_measurements LOC:54, the measurements.coverage is a much larger set than in subsequent calls.
I've added some debugger to demonstrate:
$ bundle exec rake yard:verify
measurements.coverage: 13749/16690
YARD-Coverage: 82.3% (threshold: 100%)
measurements.coverage: 193/236
measurements.coverage: 193/236
YARD-Coverage must be at least 100% but was 81.7%

config/yardstick.yml:
---
threshold: 100
path: 'app/**/*.rb'
require_exact_threshold: false
rules:
  ApiTag::Presence:
    enabled: false
    exclude: []
  ApiTag::Inclusion:
    enabled: false
    exclude: []
  ApiTag::ProtectedMethod:
    enabled: false
    exclude: []
  ApiTag::PrivateMethod:
    enabled: false
    exclude: []
  ExampleTag:
    enabled: false
    exclude: []
  ReturnTag:
    enabled: true
    exclude: []
  Summary::Presence:
    enabled: true
    exclude: []
  Summary::Length:
    enabled: false
    exclude: []
  Summary::Delimiter:
    enabled: true
    exclude: []
  Summary::SingleLine:
    enabled: false
    exclude: []

Rakefile
if Rails.env.development?
  require 'yardstick/rake/verify'
  require 'yardstick/rake/measurement'

  namespace :yard do
    options = YAML.load_file('config/yardstick.yml')

    Yardstick::Rake::Measurement.new(:measure, options) do |measurement|
      measurement.output = 'doc/•yardstick_report.txt'
    end

    Yardstick::Rake::Verify.new(:verify, options)

    task :save_stats => :environment do
      sh %{yard stats --list-undoc --compact > 'doc/•undocumented.txt'}
    end
  end
end

After some spelunking, I discovered that the original total_coverage includes many Objects and Modules in Ruby. These are the first 5 lines, after my repo's  code, from my latest doc/•yardstick_report.txt:
array.c:659: Array.try_convert: The method summary should not end in a period
array.c:659: Array.try_convert: The @return tag should be specified
array.c:721: Array#initialize: The method summary should not end in a period
array.c:721: Array#initialize: The @return tag should be specified
array.c:786: Array.[]: The method summary should not end in a period

$ yard stats
Files:         259
Modules:        13 (   11 undocumented)
Classes:       261 (  254 undocumented)
Constants:      26 (   20 undocumented)
Attributes:     22 (    0 undocumented)
Methods:      1104 (  868 undocumented)
 19.14% documented


Install script hangs on some systems doing apt-get upgrade

updated install script prompts for y/n to continue on some systems.
stdout redirected to file, so user can't see it.

hey did you have any luck getting it to work? I have the same problem

@LeviDavisCode
yes, use the updated script, see the external script repo for the new url
https://github.com/sdetweil/MagicMirror_scripts

Hi,
I used the external script url but my installation is still stuck at apt-update. The last line in the log file is apt-get update completed ok

@vkramsingh
please use the install script from  here
https://github.com/sdetweil/MagicMirror_scripts

FYI, The link to (broken) the install script is removed from the README.md.

Experienced the same issue when I reinstalled my mirror this weekend. It's because the script uses sudo to run the majority of commands. But for some reason, the script does not prompt for the password, hence the hang.
Once you run at least once command with sudo before hand, the password is cached and the script will work fine.
I don't know if this is a regression or not, last time it worked fine but I might have used sudo prior to executing the script.

the newer updated script does handle this..   the new doc points to the alternate install sites

I am closing this, link to new site
https://github.com/sdetweil/MagicMirror_scripts


Distributing the patch for layeredFS

Greetings,
As a fellow Switch modder, I couldn't help but notice that you seem to only distribute your patch as a NSP, which, on top of being rare, can lead to bans on hardware and is not recommended by SciresM (Atmosphere lead dev),
After some manipulations, I compared what files you guys have edited to the base game and used them through layeredFS on Switch, and it worked flawlessly for a full run of Arcueid's route (massive props to the translation team btw, amazing work and no typo).
Why did I bother to do this? Well, as I said, NSPs are unsafe on Switch and I think you guys would benefit a lot from distributing the patch for use with LayeredFS for the safety of your users (on top of not giving them a heart attack when reading the instructions).
I'm aware the installation guide mentions you will not take responsibility for bans, and that's totally fair, but you wouldn't need to warn people if you distributed a safe alternative. And hey, you can still keep the NSP way for ease of use on emulators!
I also noticed you distribute a patched exefs, why not use one of the existing alternatives like Skyline (compatible with Ryujinx and soon with Yuzu) or Starlight (generates a IPS patch with an extra subsdk file that contains the code)? I have no intention to call you out on that, but I'm not sure distributing an edited copyrighted executable is a good idea if you want to protect yourselves from takedown notices.

I am a patch maker in other languages. I tried to seal the pictures that need to be modified in allpac into allpaccg. There will be problems with some of the teaching pictures of princess. Other pictures are normal, I don't know how to correctly patch exefs.

I'm a Chinese patch maker

Exefs are currently patched through IPS, but the patching is incomplete

I found that the error reporting problem only occurs in the switch. Ryujinx didn't appear, everything was normal

I recently found that this engine can be use the modified files in  allpac&allpaccg, and RULE files in allpac,  rename them and package them in allpacml.
Then the ips patch the exefs.
It does not need skyline and third-party SDKs to avoid being banned perfectly.
I'm from the Chinese localization team.
Thanks to rschlaikjer's mangetsu tool.
Thank you. Good luck with your work.

Greetings,
As a fellow Switch modder, I couldn't help but notice that you seem to only distribute your patch as a NSP, which, on top of being rare, can lead to bans on hardware and is not recommended by SciresM (Atmosphere lead dev),
After some manipulations, I compared what files you guys have edited to the base game and used them through layeredFS on Switch, and it worked flawlessly for a full run of Arcueid's route (massive props to the translation team btw, amazing work and no typo).
Why did I bother to do this? Well, as I said, NSPs are unsafe on Switch and I think you guys would benefit a lot from distributing the patch for use with LayeredFS for the safety of your users (on top of not giving them a heart attack when reading the instructions).
I'm aware the installation guide mentions you will not take responsibility for bans, and that's totally fair, but you wouldn't need to warn people if you distributed a safe alternative. And hey, you can still keep the NSP way for ease of use on emulators!
I also noticed you distribute a patched exefs, why not use one of the existing alternatives like Skyline (compatible with Ryujinx and soon with Yuzu) or Starlight (generates a IPS patch with an extra subsdk file that contains the code)? I have no intention to call you out on that, but I'm not sure distributing an edited copyrighted executable is a good idea if you want to protect yourselves from takedown notices.

Hello thanks for this, The instructions gave me a heart attack as well and when I tried to install in tinfoil I kept getting an error for unsigned code and it wouldn’t download. Do you have copy of the files I could use to play it patch on my switch without the NSP? I’d be so grateful

Greetings,
As a fellow Switch modder, I couldn't help but notice that you seem to only distribute your patch as a NSP, which, on top of being rare, can lead to bans on hardware and is not recommended by SciresM (Atmosphere lead dev),
After some manipulations, I compared what files you guys have edited to the base game and used them through layeredFS on Switch, and it worked flawlessly for a full run of Arcueid's route (massive props to the translation team btw, amazing work and no typo).
Why did I bother to do this? Well, as I said, NSPs are unsafe on Switch and I think you guys would benefit a lot from distributing the patch for use with LayeredFS for the safety of your users (on top of not giving them a heart attack when reading the instructions).
I'm aware the installation guide mentions you will not take responsibility for bans, and that's totally fair, but you wouldn't need to warn people if you distributed a safe alternative. And hey, you can still keep the NSP way for ease of use on emulators!
I also noticed you distribute a patched exefs, why not use one of the existing alternatives like Skyline (compatible with Ryujinx and soon with Yuzu) or Starlight (generates a IPS patch with an extra subsdk file that contains the code)? I have no intention to call you out on that, but I'm not sure distributing an edited copyrighted executable is a good idea if you want to protect yourselves from takedown notices.

Heyya!
Was wondering if you still had the files to play this as a mod, as opposed to a NSP?
I wanna play this so bad, but I'm not sure how to do it with a legal copy of the game without using Skyline or something like that.

As part of our final release, we have included a script and instructions for converting the NSP patch to a layeredfs patch.
You can find them on the website here.
https://tsukihimates.com/patch/#atmosphere_layeredfs


[FEATURE]: Alignment of UI structure

Feature Suggestion
First of all, your project is amazing and I am really impressed with the idea. The feature or you can say a styling that I want to improve is that some of the things are unstructured for mobile and desktop screen sizes.
Screenshots

As you can see, the font sizes doesn't fit well for small screens

On the guides page, the heading is left aligned and out of the place, I think it looks good at the center, also there is no spacing between the content and heading.

In the contributors' section, there isn't much spacing.
Would you be up for working on this?
Hell yeah!
Pre-Submission Checklist

[X] I have checked this issue has not already been raised
[X] I've searched the docs for an answer
[X] I agree to follow thr Code of Conduct

@Lissy93 Can you assign this issue to me? I have experience with frontend web development and I am looking for an good pr merge during hacktoberfest.

@Lissy93 please assign this issue to me.  i have prior knowledge. if i am given an oppurtunity i will be more happy to serve this repository


Rename files to ..ts to follow best practice

card.ts would be card.component.ts for example.

Yes indeed, it would be better


Multi-arch engine images

Current design assumes all images are of amd64 architecture, but we should not be locking pipelines to a specific arch.
Explore options to support multi-arch images.

Multi-arch OCI images are stored in repositories as top-level manifests that points to hashes of images per specific architecture. These manifests have their own unique hash and they're the one that are usually tagged with version numbers.
A combination of such top-level hash and the platform name is enough to fetch the same image (reproducible).
When performing data transformations, however, we should record somewhere what image/architecture was actually used. There is nothing that prevents amd64 image to be completely different from arm64, thus we must be able to warn users that a failure to reproduce results may be due to platform differences. We could even try suggesting to re-run it with original image under QEMU emulation.


install: check if /boot/config.txt is a symlink

Should fix GPIO config on PiOS Bookworm
https://github.com/raspberrypi/linux/issues/5710#issuecomment-1808918578


Non Determinism Between Threads

Describe the bug
In the course of benchmarking, there was significant non-determinism between threads.
I assumed this was because of the non-determinism of SPAdes (https://github.com/ablab/spades/issues/111) but Unicycler was not non-deterministic, so I think Flye is the issue.
https://github.com/fenderglass/Flye/issues/509
https://github.com/fenderglass/Flye/pull/546
** Fixes**
Testing out --deterministic Flye output for benchmarking, see if that works (moreso the effect on speed, shouldn't be too bad after subsampling).

Turns out even with --deterministic there's still some non-determinism, much less though.

It has not that much effect on speed. Good to go.

Turns out that even that is very non-deterministic.
Accordingly, implementing Raven - much less non-deterministic (Plassembler outputs are almost identical), much faster and uses less RAM.

After all this, even Raven is non-deterministic. So I am leaving both as options.
If you use Plassembler, please be warned that there is potential for non-determinism between threads, which is likely more so if you use Flye compared to Raven.


Feature/multimessage yield

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

43 of 43 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>5:
0.0%

Covered Lines:
1811

Relevant Lines:
1811

💛  - Coveralls


open-pull-requests-limit: 0 not being respected for yarn

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
yarn
Package manager version
npm v9.2.0 yarn 1.21.1
Language version
node v16.14.2
Manifest location and content before the Dependabot update
No response
dependabot.yml content
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"
      day: "sunday"

  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "monthly"
      day: "sunday"
    open-pull-requests-limit: 0

Updated dependency
One example:
Bumps aws-sdk from 2.1372.0 to 2.1381.0.
What you expected to see, versus what you actually saw
I expect dependabot to open no pull requests, but it is still opening them.
Major reason for wanting this to work as intended is so that we can exclude dependabot alerts from our PR channel. The Slack integration (at least two months ago lol) did not have the ability to filter out dependabot PRs. :(
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue

Create a node project using yarn.
Configure dependabot with the provided dependabot.yml.
Set one of the dependencies to a previous version.
Observe PR request.

The open pull request limit setting only affects Version Updates which run on a schedule, and not Security Updates which run when there's an alert.
If I'm understanding correctly it sounds like you don't want Security Updates at all. Those can be disabled in the UI:

If I'm understanding correctly it sounds like you don't want Security Updates at all. Those can be disabled in the UI:

No this is not what I am after. I want security alerts, but not pull request. This was the first setting I checked and I have confirmed it is disabled.
What I want is no automated PRs opening, but I want the alerts and email digest of dependencies. This configuration works with npm and others, but for whatever reason is not working for yarn.

Screenshot of the repo settings.

Ah I see, looks like you've got it all set up correctly then.
This seems like https://github.com/dependabot/dependabot-core/issues/7361 where the repo is out of sync in Dependabot's database. We can resync it but we need the repository name and owner, or you can try pushing a change to dependabot.yml which should reprocess the repository.

I went the dependabot.yml route. :) I gave it a boop by changing the limit to 1 and then back 0. I'll have to wait for a dependency update - probably by tomorrow morning one will happen.

No PRs so far! I think we are good :)


Report title on download

It would be nice if the report title were included on top of the downloaded image.
The image would then be ready for use e.g. in a text document without needing photoshopping to add the title.
Thank you.

Here an example of what you asked, is it fine? Is not that easy to remove the buttons from the image.

Let us know if you have some feedbacks

This is an example of what a download looks like now.
It would indeed be nice to have the title above.
I understand the system takes a "snapshot" of the report "as is" and that it is therefore not possible to remove the buttons and sliders from the top and bottom. This is not ideal, but it's better than having no title at all :-)
Thanks


Plugin doesn't create appropriate devices of TS0505A lamp

Issue description
The plug-in does not create appropriate devices for the TS0505A zigbee lamp

After restarting Domoticz, the following messages are in the log:
2020-12-16 18:21:35.533 Error: (Zigbee2MQTT) Hoek_Lamp1: can not process feature type "light"
2020-12-16 18:21:35.537 Error: (Zigbee2MQTT) Hoek_Lamp2: can not process feature type "light"

It only creates an Effect device

I already deleted the devices and restarted Domoticz...same result.
The device "Woonkamer_Licht" (an _rgbw group) which members are those TS0505A zigbee lamps, also has a problem.
The group switch physically turnes on/off the lamps of the group, but the On/Off state of the domoticz device  "Woonkamer_Licht" is not updated.
The following error is shown in the log when an On/Off command is performed:
2020-12-16 18:58:06.116 Status: User: Admin (IP: <IP_ADDRESS>) initiated a switch command (531/Woonkamer_Licht/Off)
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) 'onMessage' failed 'ZeroDivisionError':'float division by zero'.
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 279 in '/home/pi/domoticz/plugins/zigbee2mqtt/plugin.py', function onMessage
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 124 in '/home/pi/domoticz/plugins/zigbee2mqtt/plugin.py', function onMessage
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 167 in '/home/pi/domoticz/plugins/zigbee2mqtt/mqtt.py', function onMessage
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 201 in '/home/pi/domoticz/plugins/zigbee2mqtt/plugin.py', function onMQTTPublish
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 81 in '/home/pi/domoticz/plugins/zigbee2mqtt/groups_manager.py', function handle_mqtt_message
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 64 in '/home/pi/domoticz/plugins/zigbee2mqtt/adapters/base_adapter.py', function handle_mqtt_message
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 65 in '/home/pi/domoticz/plugins/zigbee2mqtt/devices/base_colortemp_light.py', function handle_message
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 22 in '/home/pi/domoticz/plugins/zigbee2mqtt/devices/base_colortemp_light.py', function get_color_value
2020-12-16 18:58:06.329 Error: (Zigbee2MQTT) ----> Line 100 in '/home/pi/domoticz/plugins/zigbee2mqtt/devices/base_colortemp_light.py', function get_rgb_from_xy_and_brightness
2020-12-16 18:58:06.384 Error: (Zigbee2MQTT) 'onMessage' failed 'ZeroDivisionError':'float division by zero'.
2020-12-16 18:58:06.384 Error: (Zigbee2MQTT) ----> Line 279 in '/home/pi/domoticz/plugins/zigbee2mqtt/plugin.py', function onMessage
2020-12-16 18:58:06.384 Error: (Zigbee2MQTT) ----> Line 124 in '/home/pi/domoticz/plugins/zigbee2mqtt/plugin.py', function onMessage
2020-12-16 18:58:06.384 Error: (Zigbee2MQTT) ----> Line 167 in '/home/pi/domoticz/plugins/zigbee2mqtt/mqtt.py', function onMessage
2020-12-16 18:58:06.384 Error: (Zigbee2MQTT) ----> Line 201 in '/home/pi/domoticz/plugins/zigbee2mqtt/plugin.py', function onMQTTPublish
2020-12-16 18:58:06.384 Error: (Zigbee2MQTT) ----> Line 81 in '/home/pi/domoticz/plugins/zigbee2mqtt/groups_manager.py', function handle_mqtt_message
2020-12-16 18:58:06.384 Error: (Zigbee2MQTT) ----> Line 64 in '/home/pi/domoticz/plugins/zigbee2mqtt/adapters/base_adapter.py', function handle_mqtt_message
2020-12-16 18:58:06.384 Error: (Zigbee2MQTT) ----> Line 65 in '/home/pi/domoticz/plugins/zigbee2mqtt/devices/base_colortemp_light.py', function handle_message
2020-12-16 18:58:06.385 Error: (Zigbee2MQTT) ----> Line 22 in '/home/pi/domoticz/plugins/zigbee2mqtt/devices/base_colortemp_light.py', function get_color_value
2020-12-16 18:58:06.385 Error: (Zigbee2MQTT) ----> Line 100 in '/home/pi/domoticz/plugins/zigbee2mqtt/devices/base_colortemp_light.py', function get_rgb_from_xy_and_brightness

Note:
TS0505A is actually a Lidl lamp which already is added the zigbee2mqtt dev branche, but not yet in 1.16.2.
In 1.16.2 it is recognized as a TuYa TS0505A device, but that has nothing to do with the problem I guess?
Additional information
Zigbee2MQTT version: 1.16.2
Python version: 3.7.3
Domoticz version: 2020.2 (build 12732)
Plugin version: v3.0
Logs
Attach any additional logs here which might be useful: mqtt, domoticz, plugin logs

Could you please enable debug mode in the plugin and post here the log

In the z2m webbased frontend page I removed the lidl devices from the group, deleted the group and re-created the group + added lidl bulbs. Restarted domoticz, and added the "Woonkamer_Licht(_rgbw)" device again
The group device "Woonkamer_Licht" is not causing an error anymore (for now).
I am testing these Lidl bulbs and yesterday evening (late) I unplugged them from the power, maybe this caused the group device to error?
Regarding the Lidl Bulbs....they still won't create devices but only the (effect) device. Here is the log after  turning on debug and restarted domoticz:
2020-12-16 21:33:05.126 Status: Domoticz V2020.2 (build 12732) (c)2012-2020 GizMoCuz
2020-12-16 21:33:05.126 Status: Build Hash: fc9c7c2d0-modified, Date: 2020-12-07 15:53:06
2020-12-16 21:33:05.126 Status: Startup Path: /home/pi/domoticz/
2020-12-16 21:33:05.126 Status: Startup delay... waiting 20 seconds...
2020-12-16 21:33:25.332 Status: PluginSystem: Started, Python version '3.7.3'.
2020-12-16 21:33:25.338 Status: WebServer(HTTP) started on address: :: with port 9090
2020-12-16 21:33:25.345 Status: WebServer(SSL) started on address: :: with port 443
2020-12-16 21:33:25.388 Status: TCPServer: shared server started...
2020-12-16 21:33:25.389 Status: RxQueue: queue worker started...
2020-12-16 21:33:27.389 Status: YeeLight Worker started...
2020-12-16 21:33:27.390 Status: RFXCOM: Worker started...
2020-12-16 21:33:27.390 Status: WOL: Started
2020-12-16 21:33:27.391 Status: (Yamaha) Started.
2020-12-16 21:33:27.391 Status: (iDetect) Started.
2020-12-16 21:33:27.391 Status: (Pi-Monitor) Started.
2020-12-16 21:33:27.391 Status: (Plug-ins Manager) Started.
2020-12-16 21:33:27.391 Status: (Zigbee2MQTT) Started.
2020-12-16 21:33:27.392 Status: EventSystem: reset all events...
2020-12-16 21:33:27.398 Status: NotificationSystem: thread started...
2020-12-16 21:33:27.401 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/TV_Lamp.lua
2020-12-16 21:33:27.401 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Tafel_Lamp.lua
2020-12-16 21:33:27.401 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Woonkamer_Lampen_Switch.lua
2020-12-16 21:33:27.402 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Tafel_Lamp_AB_Switch.lua
2020-12-16 21:33:27.402 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Keuken_Licht_Dimmer.lua
2020-12-16 21:33:27.402 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Keuken_Licht_Remote_Sync.lua
2020-12-16 21:33:27.403 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Remote_Keuken_Licht_Sync.lua
2020-12-16 21:33:27.403 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Wekker_Timer_Gerben.lua
2020-12-16 21:33:27.404 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Wekker_Timer_Fay-Linn.lua
2020-12-16 21:33:27.404 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Wekker_Timer_Jose.lua
2020-12-16 21:33:27.404 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Tuin_Licht_Remote_Sync.lua
2020-12-16 21:33:27.404 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Remote_Tuin_Licht_Sync.lua
2020-12-16 21:33:27.405 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/TV_Lamp_AB_Switch.lua
2020-12-16 21:33:27.405 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Schuurdeur_Security.lua
2020-12-16 21:33:27.405 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Ganglamp_entree.lua
2020-12-16 21:33:27.405 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Woonkamer_Sfeer.lua
2020-12-16 21:33:27.406 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Frietpan.lua
2020-12-16 21:33:27.406 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Frietpan_Auto_Off_A.lua
2020-12-16 21:33:27.406 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Batterij_Check.lua
2020-12-16 21:33:27.406 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Tafel_Lamp_AB.lua
2020-12-16 21:33:27.407 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/TV_Lamp_AB.lua
2020-12-16 21:33:27.407 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Wekker_Switch_Gerben.lua
2020-12-16 21:33:27.407 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Wekker_Switch_Faye-Linn.lua
2020-12-16 21:33:27.407 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Wekker_Switch_Jose.lua
2020-12-16 21:33:27.408 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Rookmelders.lua
2020-12-16 21:33:27.408 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Wintertijd_WeekLicht.lua
2020-12-16 21:33:27.408 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Woonkamer_Lampen.lua
2020-12-16 21:33:27.408 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Electric_Fence_On_Off.lua
2020-12-16 21:33:27.409 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Rookmelder_Test.lua
2020-12-16 21:33:27.409 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Kerst_Licht.lua
2020-12-16 21:33:27.409 Status: dzVents: Write file: /home/pi/domoticz/scripts/dzVents/generated_scripts/Wall_Switch_RGBWW.lua
2020-12-16 21:33:27.409 Status: EventSystem: reset all device statuses...
2020-12-16 21:33:27.700 Status: PluginSystem: Entering work loop.
2020-12-16 21:33:27.799 Status: Python EventSystem: Initalizing event module.
2020-12-16 21:33:27.800 Status: EventSystem: Queue thread started...
2020-12-16 21:33:27.800 Status: EventSystem: Started
2020-12-16 21:33:27.905 Status: (Yamaha) Entering work loop.
2020-12-16 21:33:27.905 Status: (Yamaha) Initialized version 2.0.2, author 'thomasvillagers'
2020-12-16 21:33:28.017 Status: (iDetect) Entering work loop.
2020-12-16 21:33:28.018 Status: (iDetect) Initialized version 2.0, author 'ESCape'
2020-12-16 21:33:28.134 Status: (Pi-Monitor) Entering work loop.
2020-12-16 21:33:28.135 Status: (Pi-Monitor) Initialized version 3.1, author 'Xorfor'
2020-12-16 21:33:28.330 Status: (Plug-ins Manager) Entering work loop.
2020-12-16 21:33:28.330 Status: (Plug-ins Manager) Initialized version 1.0.0
2020-12-16 21:33:28.392 Status: MQTT: Connecting to <IP_ADDRESS>:1883
2020-12-16 21:33:28.394 Status: RFXCOM: Using serial port: /dev/serial/by-id/usb-RFXCOM_RFXtrx433XL_DO2VYPCR-if00-port0
2020-12-16 21:33:28.593 Status: MQTT: connected to: <IP_ADDRESS>:1883
2020-12-16 21:33:28.642 Status: (Zigbee2MQTT) Entering work loop.
2020-12-16 21:33:28.642 Status: (Zigbee2MQTT) Initialized version 3.0.0
2020-12-16 21:33:28.793 Status: MQTT: Subscribed
2020-12-16 21:33:29.697 (Zigbee2MQTT) Installing plugin custom page...
2020-12-16 21:33:29.697 (Zigbee2MQTT) Copying files from /home/pi/domoticz/plugins/zigbee2mqtt/frontend to /home/pi/domoticz/www/templates
2020-12-16 21:33:29.715 (Zigbee2MQTT) Installing plugin custom page completed.
2020-12-16 21:33:29.715 (Zigbee2MQTT) MqttClient::__init__
2020-12-16 21:33:29.715 (Zigbee2MQTT) MqttClient::open
2020-12-16 21:33:29.766 (Zigbee2MQTT) onConnect called
2020-12-16 21:33:29.767 (Zigbee2MQTT) Connected to MQTT Server: <IP_ADDRESS>:1883
2020-12-16 21:33:29.767 (Zigbee2MQTT) MQTT CLIENT ID: 'Domoticz_1608150809_9451'
2020-12-16 21:33:29.817 (Zigbee2MQTT) MqttClient::subscribe
2020-12-16 21:33:29.869 (Zigbee2MQTT) onMQTTSubscribed
2020-12-16 21:33:29.869 (Zigbee2MQTT) Zigbee2mqtt bridge is online
2020-12-16 21:33:29.869 (Zigbee2MQTT) MqttClient::publish zigbee2mqtt/bridge/config/groups ()
2020-12-16 21:33:29.869 (Zigbee2MQTT) Zigbee2mqtt log level is debug
2020-12-16 21:33:29.869 (Zigbee2MQTT) Joining new devices is disabled on the zigbee bridge
2020-12-16 21:33:29.872 (Zigbee2MQTT) Received available devices list from bridge
2020-12-16 21:33:29.872 (Zigbee2MQTT) Coordinator address is 0x00124b00216005b6
2020-12-16 21:33:29.876 (Zigbee2MQTT) {"features": [{"access": 7, "description": "On/off state of this light", "name": "state", "property": "state", "type": "binary", "value_off": "OFF", "value_on": "ON", "value_toggle": "TOGGLE"}, {"access": 7, "description": "Brightness of this light", "name": "brightness", "property": "brightness", "type": "numeric", "value_max": 254, "value_min": 0}, {"access": 7, "description": "Color temperature of this light", "name": "color_temp", "property": "color_temp", "type": "numeric", "unit": "mired", "value_max": 500, "value_min": 150}, {"description": "Color of this light in the CIE 1931 color space (x/y)", "features": [{"access": 7, "name": "x", "property": "x", "type": "numeric"}, {"access": 7, "name": "y", "property": "y", "type": "numeric"}], "name": "color_xy", "property": "color", "type": "composite"}], "type": "light"}
2020-12-16 21:33:29.877 (Zigbee2MQTT) {"features": [{"access": 7, "description": "On/off state of this light", "name": "state", "property": "state", "type": "binary", "value_off": "OFF", "value_on": "ON", "value_toggle": "TOGGLE"}, {"access": 7, "description": "Brightness of this light", "name": "brightness", "property": "brightness", "type": "numeric", "value_max": 254, "value_min": 0}, {"access": 7, "description": "Color temperature of this light", "name": "color_temp", "property": "color_temp", "type": "numeric", "unit": "mired", "value_max": 500, "value_min": 150}, {"description": "Color of this light in the CIE 1931 color space (x/y)", "features": [{"access": 7, "name": "x", "property": "x", "type": "numeric"}, {"access": 7, "name": "y", "property": "y", "type": "numeric"}], "name": "color_xy", "property": "color", "type": "composite"}], "type": "light"}
2020-12-16 21:33:29.878 (Zigbee2MQTT) MqttClient::subscribe
2020-12-16 21:33:29.929 (Zigbee2MQTT) onMQTTSubscribed
2020-12-16 21:33:29.929 (Zigbee2MQTT) Received groups list from bridge
2020-12-16 21:33:29.929 (Zigbee2MQTT) Group Keuken_Spots_ct
2020-12-16 21:33:29.930 (Zigbee2MQTT) Group Tuin_Licht_dimmer
2020-12-16 21:33:29.930 (Zigbee2MQTT) Group Stopcontacten
2020-12-16 21:33:29.930 (Zigbee2MQTT) Group Woonkamer_Licht_rgbw
2020-12-16 21:33:29.046 Status: RFXCOM: Async Disabled
2020-12-16 21:33:29.654 Status: (iDetect) Tracker activated:<IP_ADDRESS> port 22, user: admin, type: prefab and options: {'ssh': 'wlanconfig ath10 list; wlanconfig ath0 list'}
2020-12-16 21:33:29.655 Status: (iDetect) Tracker activated:<IP_ADDRESS> port 22, user: root, type: prefab and options: {'user': 'root', 'password': '********', 'ssh': 'wl_atheros assoclist'}
2020-12-16 21:33:29.876 Error: (Zigbee2MQTT) Hoek_Lamp1: can not process feature type "light"
2020-12-16 21:33:29.877 Error: (Zigbee2MQTT) Hoek_Lamp2: can not process feature type "light"
2020-12-16 21:33:39.784 (Zigbee2MQTT) MqttClient::ping
2020-12-16 21:33:45.023 Status: (iDetect) <IP_ADDRESS> ====> SSH connection established
2020-12-16 21:33:46.733 Status: (iDetect) <IP_ADDRESS> ====> SSH connection established
2020-12-16 21:33:49.320 (Zigbee2MQTT) MqttClient::ping
2020-12-16 21:33:59.297 (Zigbee2MQTT) MqttClient::ping
2020-12-16 21:41:19.473 (Zigbee2MQTT) MqttClient::ping
2020-12-16 21:41:21.531 (Zigbee2MQTT) New request: [1] bridge_getstatus({})
2020-12-16 21:41:21.532 (Zigbee2MQTT) MqttClient::publish zigbee2mqtt/bridge/config/permit_join ()
2020-12-16 21:41:21.941 (Zigbee2MQTT) Zigbee2mqtt log level is debug
2020-12-16 21:41:21.941 (Zigbee2MQTT) Joining new devices is disabled on the zigbee bridge
2020-12-16 21:41:21.992 (Zigbee2MQTT) New request: [2] devices_get({})
2020-12-16 21:41:21.992 (Zigbee2MQTT) MqttClient::publish zigbee2mqtt/bridge/config/devices/get ()
2020-12-16 21:41:22.104 (Zigbee2MQTT) New request: [3] groups_get({})
2020-12-16 21:41:22.105 (Zigbee2MQTT) MqttClient::publish zigbee2mqtt/bridge/config/groups ()
2020-12-16 21:41:22.167 (Zigbee2MQTT) Received groups list from bridge
2020-12-16 21:41:22.167 (Zigbee2MQTT) Group Keuken_Spots_ct
2020-12-16 21:41:22.167 (Zigbee2MQTT) Group Tuin_Licht_dimmer
2020-12-16 21:41:22.168 (Zigbee2MQTT) Group Stopcontacten
2020-12-16 21:41:22.168 (Zigbee2MQTT) Group Woonkamer_Licht_rgbw

Maybe this helps. For the TS0505A I created pull request #507. It also adds HG06337 (wall socket).
I used the 'normal' branch so not the more advanced V3.0.
Adding 2 lines to the /adapters/silvercrest/init.py did the trick for me. (sorry about the 7 commits)
After the change and restart of Domoticz, there were two new devices added 'auto-magically'.
For both, the link quality information also became available under 'Extra'. The coordinator is the Electrolama CC2652 Stick.
Quote from the Zigbee controller:
{"type": "response", "requestId": 2, "isError": false, "payload":
[
{"dateCode": "20201026", "friendly_name": "Coordinator", "ieeeAddr": "0x00124b0021b780d5", "lastSeen":<PHONE_NUMBER>918, "networkAddress": 0, "softwareBuildID": "zStack3x0", "type": "Coordinator"},
{"dateCode": "", "description": "RGB+CCT light controller", "friendly_name": "Lidl RGB lamp", "hardwareVersion": 1, "ieeeAddr": "0x842e14fffe367d49", "lastSeen":<PHONE_NUMBER>123, "manufacturerID": 4098, "manufacturerName": "_TZ3000_dbou1ap4", "model": "TS0505A", "modelID": "TS0505A", "networkAddress": 51460, "powerSource": "Mains (single phase)", "type": "Router", "vendor": "TuYa"},
{"dateCode": "", "description": "Smart Plug", "friendly_name": "Lidl Plug", "hardwareVersion": 1, "ieeeAddr": "0xbc33acfffe14047c", "lastSeen":<PHONE_NUMBER>432, "manufacturerID": 4098, "manufacturerName": "_TZ3000_kdi2o9m6", "model": "HG06337", "modelID": "TS011F", "networkAddress": 32887, "powerSource": "Mains (single phase)", "type": "Router", "vendor": "Silvercrest"}
]
}

@plando2act, read this...I think that all Lidl lamps (of 3 different vendors) now all have one vendor name ‘Lidl’ and their own model number in Zigbee2mqtt 1.16.2-dev, maybe this needs to be changed?
https://github.com/Koenkk/zigbee-herdsman-converters/commit/13be3d24088412ae48dfce68879dcab8310114fd
In my case I have a livarnolux model, which is still recognized as TS0505A, because I am not in the dev branch. I know I have reconfigure them when Zigbee2mqtt is going to use the new_api, which is released at 1 januari 2021

Will be covered in scope #548

Will be covered in scope #548


Reorder request draining logic for responses without status codes

For requests with bodies and responses without them, kestrel delays sending the response until the request is drained. In the process it can also send a 100 Continue contrary to the applications intentions.
Aside from adding extra latency to the response this also has functional impacts for clients, especially for authenticated upload scenarios.
Expect: 100-continue is designed to allow the server application to specify if the body will be accepted or not before the body gets sent. This allows the application to preemptively respond with failures like 401 for auth and can save significant time and bandwidth. When the application completes the response without reading the body the server has a choice, it can close the connection or drain the body. When the client receives the final status code (401, 404) instead of the 100 Continue it has three choices. 1) It can close the connection rather than upload the data, or 2) for chunked it can send just the chunked terminator, or 3) for content-length it sends the full body. For small bodies it's worth sending it to avoid the cost of creating a new connection, but for large bodies is far more economical close the connection.
When kestrel sends the 100 Continue without prompting from the application it negates the purpose of 100 Continue. The client does not get to see the final status code and does not get to make any of their choices. If the client did not buffer their data then they may not even be able to replay the request.
The reason given for Kestrel's current behavior of delaying responses until the request is drained is to allow it to replace the response with an error code in the event of a request body error. What errors are expected from draining the request body? Client disconnect, timeouts, or a protocol violation seem like the only errors you could hit during drain. Those all warrant closing the connection anyways, there's limited value in flowing an error to the client in those cases, especially when the application disregarded the request body.
The reason kestrel sends the 100 continue is to encourage the client to send the body in a timely fashion so kestrel can drain it. It does this because it has not sent the final status code provided by the app. If it send the apps response then the client would also be unblocked.
Workaround: Kestrel does not delay or send the 100 continue if the application flushes the response headers. This is not a long term solution, there are many components in the stack that send responses without bodies. it also causes your responses to show as having empty chunked bodies rather than no body. When is the chunked body completed? Before or after the request body drain?
Recommended changes:
When the request pipeline unwinds without draining the request body or staring the response then kestrel should send the response headers before draining the request. It may also make a choice to add Connection: close if it thinks draining the request body is not worth it (e.g. large content-length remaining).

I think this change is a little risky. If we were to automatically flush the response headers without draining the request body or sending a 100 Continue, we would run into dotnet/corefx#24435 in relatively common auth and 404 scenarios. This issue causes the Linux HttpClient to send corrupt requests that ultimately lead to request timeouts.
Even if we wait for dotnet/corefx#24435 to be resolved, there are still likely to be apps using older versions of the Linux HttpClient making requests to apps using newer Kestrel server versions. There's also the minor breaking change that some 400/408 responses now become whatever was set by the app.
The workaround should complete the chunked response body prior to consuming the request body (or "Content-Length: 0" could be set), but it would also run into the Linux HttpClient bug.


Can Marigold be used as segmentation?

Awesome Work~
The foreground effect of the depth estimation is very good, even better than SAM ，Have you considered applying it to the field of saliency detection?

Thanks for your interest! You might be onto something, but it is not immediately clear to me how you propose to separate the foreground. In your example, the floor area at the very bottom is closer to the camera than the bench pixels, which is why naive thresholding won't work. Also, I see no simple way to perform connected components analysis, as the bottom of the bench legs has the same depth values as the floor underneath. All in all, this calls for some learned approach. I will close the ticket for now, but feel free to continue the discussion in this ticket -- we are always on the lookout for cool applications!

Thanks for your interest! You might be onto something, but it is not immediately clear to me how you propose to separate the foreground. In your example, the floor area at the very bottom is closer to the camera than the bench pixels, which is why naive thresholding won't work. Also, I see no simple way to perform connected components analysis, as the bottom of the bench legs has the same depth values as the floor underneath. All in all, this calls for some learned approach. I will close the ticket for now, but feel free to continue the discussion in this ticket -- we are always on the lookout for cool applications!

Maybe consider fine-tuning a new model specifically for other discriminative tasks? I see no direct obstacles preventing such generalization of your methodology. There are previous studies that train diffusion models from scratches for segmentation or depth estimation, and Marigold essentially extends this schema to fine-tuning a general-purpose SDv1.5 instead. So it makes sense to train new Marigold models for other tasks.


Run samples test on both Java 8 and Java 11

The Spanner sample tests should be executed on both Java 8 and Java 11, as some dependencies are only included in Java 9 and higher. This has caused broken builds in Java 9 and higher to pass without notice.
See also #280

@chingor13 Is this something you could help with? I do not know how to add an additional Kokoro build to execute the Samples test on both Java 8 and Java 11.

I can help out with this. I'm trying to understand the Kokoro configs and will get back to you once I learn how this is setup.

@skuruppu @olavloite the sample test badges are not shown in the README file as well, should we add them or is that going to be confusing?

@thiagotnunes Those test badges are automatically generated for all Java clients for the different Google Cloud projects here: https://github.com/googleapis/synthtool/tree/master/synthtool/gcp/templates/java_library
So if we were to change that, we would have to change it for all Java clients.
I don't feel very strongly either way about this.

Got it, thanks @olavloite. I will refrain from changing the badges now due to the impact of the change. I will follow up on this decision with @skuruppu.

@thiagotnunes Can this issue be closed now that #345 has been merged?

@olavloite not yet, I still need to do something in the backend to enable the tests. Hopefully today it will get sorted out and I will close #345.

We should now see the samples tests for java8 and java11 being run in kokoro


Tweaking the auto completion?

OS version: Ubuntu 18.04
Editor: Sublime Text
Editor version: 3 - Build 3210
Programming language: JavaScript
TabNine extension version: 3.1.4?

Issue Details:
When working in JavaScript, whenever I do an import TabNine almost always adds the extension on the end, which isn't normal practise. This involves me deleting the last 3 characters after auto-complete each time. Is there a way to change/supress the suggestions?
e.g. instead of suggesting require("./sampleLocation"); TabNine will suggest require("./sampleLocation.js");

Thanks for the feedback Ian!
We also hate that behaviour, and will make sure it is fixed ASAP. If anything else bothers you, please feel free to bring it up as well. 🤩
Thanks!!

@IPWright83 This behaviour was fixed (or rather improved?) based on your suggestion. If you are a beta user (tap tabnine::config in your IDE to find out) you should have received the fix, it will be released to GA probably tomorrow.
Thanks again!

Thanks! I'm not a beta user, and currently TabNine is completely broken for me pending https://github.com/codota/tabnine-sublime/issues/69. I can't test it out till that's fixed I'm afraid as Tab doesn't work anymore (which is unfortunate given the name!)

@dimacodota is working on a fix for that


⚠ Bofrost.de has degraded performance

In 75f297d, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1515 ms

Resolved: Bofrost.de performance has improved in 896f19b after 7 minutes.


Update dimensions and size in wallet page

resolve #345

The "Verify your seed phrase so you can recover your funds when needed." text should be 12sp not 14sp. Same  thing goes for the "Not backed up" text.
The bottom padding of the "Add new account" button looks off.

* Proper margin, padding, sizes are yet to be applied to the watch-only wallets section
* The separator below the section title should extend all the way to the side of the card widget. It should not be
   bounded by the card padding.

The wallet row doesn't look like it uses appropriate paddings when the seed has been backed up.


fix: path.owner() can raise when using filesystem adapter

catch the error and return a None owner

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


Is react-dates still actively maintained?

I can see, lats commits are like 17 months ago, so I wonder is this project still alive?

Yes, it is.

Yes, it is.


Formatted the codebase using black

Description
Formatted the codebase using black
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
Please describe the tests / checks that you performed to verify your changes. Provide instructions so we can reproduce. Please delete options that are not relevant.

[X] Tested the API endpoint on Swagger with the 'Try it out' feature
[X] Tested the Models using the Django Shell
[X] Any other tests you performed for checking edge cases.
[X] Any other tests you performed for checking exceptions.

Checklist:

[X] My code follows the style guidelines of this project
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas

Unfortunately, there seems to be merge conflicts.. probably because there were newer commits from today.
Once your other PR is merged (which has the github action), can you please sync-up with Ishvinder to get this merged? (or idk, probably you might have to raise a new one ;( )

Hi @anuran-roy , your first PR was merged by Ishvinder: https://github.com/AI4Bharat/Shoonya-Backend/pull/332
I just noticed that it has the following triggers:
on: [push, pull_request]

Can you please just make it as:
on: [pull_request]

We only have limited minutes for running GitHub Actions per month, so we may not be able afford running actions for each commit that's being pushed.
Can you please try updating in this PR itself, after resolving the above conflicts?
Or please raise a new PR. Thanks!

@GokulNC @ishvindersethi22 I resolved those conflicts - can you please see it?


Missing autocomplete for mutation variables

The suggestions it's giving here are the names of other mutations.

There might be an off by one error here, i.e. works well on a newline etc

Yeah kinda works with a new line


SignIn page update required.

Want to add a link/button to redirect them to SIgnUp page incase the user has not registered yet. Assign this issue to me under Gssoc23 , i want to contribute. @MonalikaPatnaik

Hey..similar issue is already been assigned..
Thanks!

close this @Krishnakalani111

Done


Fix for gdscript_highlighter dictionaries as function arguments

Fixes #81362
Dictionaries passed as function arguments were having their values highlighted green due to being misinterpreted as function argument hints.
Pics below and after code change.

While at it, you can also fix the comments near your changed lines to use "Sentence case."

Commit has been amended  👍. Ready for another review.

bool in_function_args = false; should be replaced with int in_function_args = 0; like in this PR.

@adeneve Would you be able to update this PR with this additional fix? If so, please do it by amending the commit, so it stays a single commit for both related fixes.

Ready for another review. Commit has been amended to address the parentheses bug.

bool in_function_args = false; should be replaced with int in_function_args = 0; like in this PR.

Thanks! And congrats for your first merged Godot contribution :tada:


Edit Account - Inactive/Enabled selection

Edit Account Dialog Box
Using existing users imported from Stroom 6.1.
User=xxxx Inactive.
In Edit Account Dialog box find Inactive selected . Expect to be able to click "Enabled", which will clear "Inactive".
The three selections Enabled/Inactive/Locked should be mutually exclusive to each other and at all times one must be selected.

The states are distinct so this is a non issue


integrate ttop into ddc

it would be massively useful to include ttop in ddc. we should embed the binary so as to simplify distribution

[x] add license header along with the apache license and the files affected (in this case just sjk-tool.jar) into a NOTICE-bin file use this example https://github.com/apache/bookkeeper/blob/master/bookkeeper-dist/src/main/resources/NOTICE-all.bin.txt
[x] make a folder called "lib" under ./cmd/local/ttopcollect/
[x] add the jar to the folder
[x] update bootstrap script to download ttop to this jar folder we created
[x] add a .gitignore with  "lib/" to the ./cmd/local/ttopcollect/ folder
[x] add a collect function in cmd/local/ttopcollect/ that uses that file to write out the binary and execute it using java java -jar sjk-tools.jar -ri 1 -n 100 -p %v the -p being for pid
[x] call function in /cmd/local/local.go and run it on another thread
[x] update the./cmd/local/conf/defaults.go to add a flag for capture time with the defaultCaptureSeconds
[x] update the./cmd/local/conf/defaults.go to add a flag for collecting ttop with a default of true
[x] update ./cmd/local/conf/conf_key_names.go and add the flags keys (something like --ttop-collection-seconds, and --collect-ttop )

ttop gives us several ways to collect (and sort)
       Sort order. Value tags: CPU, USER, SYS, ALLOC, NAME
       Default: [CPU]

I usually would get both CPU and ALLOC ?

I think we have too many flags already, but I would take a PR on this assuming adequate testing on the permutations that result (need to test all the different sort orders, what do you do with a bad sort order), as well as thead count and all the ttop options documented, however, it's definitely out of scope for this issue as it may take longer than the work so far.
Further more as far as usefullness:

sort can be changed by any aggregation tool consuming the threads
most users rarely read straight ttop and rely on some tool for analysis and aggregation, this is just because there are a lot of threads and one may need to aggregate them to see globally how much a multithreaded process or phase is using
there is rarely a case with very low cpu utilization and very high gc allocation (I would say never?) so an adequate thread count in an analysis report will allow one to get the biggest users of cpu and allocation and then.
raising thread count too high (-n option in ttop) increases collection time and cost, likewise it causes pain on the post analysis end.

TLDR I think 100 threads with a default sort gets us nearly all the way there


Compatibility with PyTorch 2.0

Is it available with PyTorch 2.0?

Some parts of the code may not be working with PyTorch 2.0.
We will update the code for the compatibility.


Advice for mapping weights back to labels

Are you able to include some documentation to describe how weights are ordered in wMode?  I would have assumed that the ordering of weights in wMode and weights would be the same, but I don't think that's true in practice.  Instead, I think the rows in wMode are the weights when the weight names are ordered alphabetically.  Is this true?  Thanks.

Yes, it's a bit confusing. But weights is a dict and so has no order. The
weights in wMode are arranged alphabetically.
On Mon, Nov 18, 2019, 10:10 PM Zoe Ashwood<EMAIL_ADDRESS>wrote:

Are you able to include some documentation to describe how weights are
ordered in wMode? I would have assumed that the ordering of weights in
wMode and weights would be the same, but I don't think that's true in
practice.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nicholas-roy/psytrack/issues/7?email_source=notifications&email_token=ABGH37TIQ536EEOH4Y6XMFDQUMHGJA5CNFSM4JO22VI2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H2FQOMA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABGH37QCSRITMALZUAFRKR3QUMHGJANCNFSM4JO22VIQ
.

Ok, thanks.

The documentation and code was updated to make this more clear in the most recent version 1.2.0 — thanks again for the contribution!


Two Functions Named setup_developer_token() In install/config.sh

Summary
The first function is meant to setup the user's Adwords API developer token and the second is meant to set an API key used for endpoints that need special approval from Google.
381 setup_developer_token() {
382   forced=$1
383
384   echo ""
385   echo "----------------------------------------"
386   echo "Set Developer Token - ${STARTHINKER_DEVELOPER_TOKEN}"
387   echo "----------------------------------------"
388   echo ""

414 setup_developer_token() {
415   forced=$1
416
417   echo ""
418   echo "----------------------------------------"
419   echo "Set API Key - ${STARTHINKER_API_KEY}"
420   echo "----------------------------------------"
421   echo ""

Proposed Solution
Rename the second function setup_api_key()
414 setup_api_key() {
415   forced=$1
416
417   echo ""
418   echo "----------------------------------------"
419   echo "Set API Key - ${STARTHINKER_API_KEY}"
420   echo "----------------------------------------"
421   echo ""

Great catch, thank you! Fixed.
https://github.com/google/starthinker/blob/master/install/config.sh#L414


Add ARIA labels to Home page - Vue

Add ARIA labels to Home page - Vue
🚀 Goal
Improve the accessibility of the Home page in our Vue DWA starter by adding appropriate ARIA labels to key elements.
🤔 Background
Adding ARIA (Accessible Rich Internet Applications) labels helps make our application more accessible to users relying on assistive technologies.

This is part of our larger project to create a Vue.js DWA starter. See our main issue here for the full context and list of all related tasks.

🔑 Tasks

[ ] The project exists here https://github.com/TBD54566975/tbd-examples/tree/main/javascript/dwa-starter-vue
[ ] Review the current structure of the Home page component
[ ] Identify key elements that need ARIA labels (e.g., main content area, navigation, buttons)
[ ] Add appropriate ARIA labels to identified elements
[ ] Ensure any images have proper alt text
[ ] Test the page with a screen reader to verify improvements

🌟 Resources

Vue.js Accessibility Guide
MDN ARIA Documentation

Getting Started

Comment ".take" on this issue to get assigned
Fork the repository and create a new branch for this task
Follow the tasks outlined above
Submit a pull request with your changes
Respond to any feedback during the review process

Questions?
If you have any questions or need clarification, please comment on this issue or join our Discord community.
Happy coding! 🎉

.take

Thank you @Adjoa


Misleading introduction or description

MSDC is not exclusively for Cloud; It for the entire hybride infrastructure, for Cloud and On-premises.

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

ID: be0f96ef-df12-de7a-173a-c056062bef8f
Version Independent ID: de058799-cca2-f999-63a3-73c2ccdd2a5d
Content: What is Microsoft Defender for Cloud? - Microsoft Defender for Cloud
Content Source: articles/defender-for-cloud/defender-for-cloud-introduction.md
Service: defender-for-cloud
GitHub Login: @dcurwin
Microsoft Alias: dacurwin

@361b3rn3
Thanks for your feedback! We will investigate and update as appropriate.

@361b3rn3
Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can take a look at it accordingly.
@dcurwin
Can you please check and add your comments on this doc update request as applicable.

@361b3rn3 In the documentation we expand on all the environments Defender for Cloud runs on. Thank you for your comment.
#please-close


Faster mutex implementation (optionally reentrant)

I made some improvements in the Mutex implementation to optimize the time it takes to lock/unlock and handoff the ownership to waiting fibers.
Current implementation is quite slow (specially in MT mode) because it always tries to be extremely fair by passing the ownership to the first fiber in the waiting queue. But that fiber might be running in a thread that is already sleeping, and waking up threads is costly and slow. So now the fiber is still awaken but it doesn't automatically have the ownership of the lock. Instead it will compete again with other fibers that might not be sleeping yet. Also, the lock will spin some time before sleeping allowing small critical sections to be acquired without passing through the waiting queue at all.
So, the changes included in this PR are:

The lock will spin some time before sleeping
The Mutex is not reentrant by default. Reentrancy requires keeping track of the locking mutex. Non-reentrant mutex just stores an atomic bit and it's much faster to "swap" the content than doing an atomic CAS operation.
Ownership is not passed to the waiting fibers. They are just awaken and will try again to obtain the lock.
An atomic count of the number of waiting fibers is kept, so the lock over the queue can be optimistically skipped. This makes the unlock faster if no fibers are waiting.

I was running a benchmark https://gist.github.com/waj/0c4b5835af088e8921fee4cc2c6006ed#file-bm_lock-cr (provided by @carlhoerberg, thanks Carl!) and these are the results:
Before changes:
$ crystal run --release bm_lock.cr
Mutex.synchronize  78.03M ( 12.82ns) (± 1.39%)  0.0B/op  fastest

$ crystal run --release -D preview_mt bm_lock.cr
Mutex.synchronize 110.29k (  9.07µs) (± 2.15%)  0.0B/op  fastest

After changes:
$ bin/crystal run --release bm_lock.cr
Mutex.synchronize 107.36M (  9.31ns) (± 2.08%)  0.0B/op  fastest

$ bin/crystal run --release -D preview_mt bm_lock.cr
Mutex.synchronize  40.15M ( 24.91ns) (±41.89%)  0.0B/op  fastest

I was also running another test (https://gist.github.com/waj/0c4b5835af088e8921fee4cc2c6006ed#file-test-mutex-cr) to evaluate the correctness of the mutex:
Before changes:
$ crystal run --release test-cr.cr -- 1000000
00:00:00.042806000
4000000

$ crystal run --release -D preview_mt test-cr.cr -- 1000000
00:00:18.215747000
4000000

After changes:
$ bin/crystal run --release test-cr.cr -- 1000000
00:00:00.029512000
4000000

$ bin/crystal run --release -D preview_mt test-cr.cr -- 1000000
00:00:00.124867000
4000000

now the fiber is still awaken but it doesn't automatically have the ownership of the lock. Instead it will compete again with other fibers that might not be sleeping yet.

Weird, we usually want the exact opposite to avoid contention —waking all resources will lead them to fight again to get the lock... when n - 1 of them will return back to sleep.

@ysbaddaden this is not waking all resources. It just wake one of the fibers and it will have to compete with those still not sleeping, if they exist. If they don't it will acquire the lock right away. Otherwise, if it looses, it will spin a little bit one more time, and hopefully get the lock before going back to sleep. It might sound weird for that fiber, but the global throughput is improved because it reduces the time the mutex is not owned by any non-sleeping fiber.

Ah, thanks for the clarification. It makes sense now. Yes, spinning is always a good idea :)

I really don't think having non-reentrant (recursive) be the default is a good idea. What happens if you accidentally recurse? A deadlock? Corruption? The only acceptable state is an exception, or having a recursive lock. There may be an unsafe option to make the lock much faster for the cost of having to be extra careful not to get it wrong, but safety must be the default.

I agree. Crystal should always put safety before performance.

@bcardiff @waj ?

If you are using mutexes is because you're dealing with "unsafe" code. I mean, there is some shared state that must be protected with a mutex in order to deal with potential race conditions. In most cases a non-reentrant mutex is all you need. A non-reentrant mutex is not owned by any fiber and that means it can be unlocked by a different fiber. That is actually a feature of the mutex. You can lock, pass a message to another fiber and assume the ownership there and unlock later.
If you accidentally try to recursively lock a mutex it will deadlock and the program will fail, way much faster and deterministic than failures that can occur for not locking at all.
In other words, we're not adding safety just making the mutex reentrant, non-reentrant mutex is way much faster and all you need in most cases. That was the rationale behind the decision of making non-reentrant option the default.

The story of having better diagnostics/debugging tools is independent of the API mutex should have. Using a non-reentrant mutex as a reentrant mutex will block and not segfault, so the behavior is in the safe/sound side. The performance difference and the more common requirement for non-reentrant seems enough to stay with the optionally reentrant API.

I think this will mostly hit users in a silent way when doing stuff like:
# called from multiple functions
def helper_function
  @mutex.synchronize do
    # some data
  end
end

def main_function
  @mutex.synchronize do
    do_something
    helper_function # Oops, deadlock, not easy to debug
  end
end

Would it cost too much performance to require an explicit lock owner akin to Java's synchronized? It shouldn't be more than a pointer comparison and an , right? Something like
def lock(owner)
  raise "Already locked" if @current_owner = owner.object_id
  real_lock
  @current_owner = owner.object_id
end

Or actually a CAS operation for that.
Then Ary's example would raise.

But if you are using a lock that is hold you want to wait for it to be free, not fail immediately. Maybe a reasonable timeout on debug mode can help, but I am not sure I even like that alternative.
Or you mean that only for non-reentrant mutex to signal a hey: you might need a reentrant mutex?

Yes, the reentrant one wouldn't raise in that case, or even do anything with the owner I guess (other than keeping it for debug purposes maybe).

It's not about debugging tools, it's about being able to debug in the first place. Users will not appreciate having to dig out gdb on a production server to debug their deadlocks. This is especially annoying because hung process detection and restarting is far less common and tricky to set up than auto-restart on crash. They'd much prefer if the process just crashed and have them a backtrace to investigate.
Is a benchmark of the non-reentrant vs reentrant available?

I still don't understand why we have a deadlocking but less performance behavior as a default one, instead of a safer but slower one. One can always optimize a bottleneck once it's found. Having to deal with deadlocks or crashes upfront is not fun. But we'll see with feedback.

Still:

Is a benchmark of the non-reentrant vs reentrant available?

With reentrant you must acces Fiber.current, thus access a thread local, then make more writes to memory when locking and unlocking. For the tight usages we make of Mutex, its necessarily faster to not have all these writes. I had 2 mutexes in my MT experiment, one private (no validation) and 1 public (deadlock detection, optionally reentrant) wrapping the private one. No need to say the private one was much more performant (for tight usages, such as in Channel, ...)
I wish there was a third option, on by default: detect and raise on deadlock/wrong fiber unlocking the mutex. Then, you know there is an issue and have a backtrace to understand it, or use a reentrant mutex if it's acceptable (thought, they're a smell for me, they bypass a bug, and can still lead to deadlock when using lock/unlock) instead of a hanging process.
I agree with Ary: validation shouldn't be opt-in. You can disable all checks if there is a performance issue (or you're a boss), thought unless in tight benchmarks/loops it may not be that significant (except for MT synchronization primitives).

I wish there was a third option, on by default: detect and raise on deadlock/wrong fiber unlocking the mutex. Then, you know there is an issue and have a backtrace to understand it, or use a reentrant mutex if it's acceptable (thought, they're a smell for me, they bypass a bug, and can still lead to deadlock when using lock/unlock) instead of a hanging process.

This is what I have been asking for all along... Have I been unclear?

That would be my preference as well, safe by default, fast by need.
.new(reentrant: true) seems clear

Well, there's non-reentrancy, and skipping deadlock checks in unsafe code for speed. They're different things to me (feature vs safety).

Yes, and that's why I insisted above on having all 3 states:

check by default: raise on deadlock + wrong fiber unlocking (safe);
reentrant option (may still deadlock when skipping an unlock, but otherwise safe);
disable checks option: full speed (unsafe: can deadlock + any fiber can unlock).

I.e. similar to pthreads options but checked by default. It prevents deadlocks by default and reports where a deadlock/invalid unlock occurred —without having to reproduce in GDB. It keeps some flexibility with reentrant, and it won't impact performance when checks are disabled (we already check for reentrant).

Somebody wants to open an issue about this so we don't forget it?

@jhass this is blocking the release so it certainly won't be forgotten

Is it blocking the release? I think we can release it like that for 0.32.0 and adjust in 0.32.1 or 0.33.0

It's too easy to forget about a regression if it makes it into a release.


RandomInit trait for models

Most model should have a moderate random initial state, which is placed on the attractor.
However, we cannot choose good initial point for all parameters. Thus, this should be return Result value, and assured to return value for default setting.
trait RandomInit {
  fn random_init(&self) -> Result<ArrayBase<S, D>, DivergenceError>
}

This will be hard since this need time evolution while we cannot specialize them...


ITMS-90809: deprecated API UIWebView usage

Apple announced, that apps using UIWebView won't be accepted from April 2020 (new submissions) / December 2020 (updates). So that we are be able to submit our apps in April, we test the submit with a fresh created trigger.io app (forge create) and build it (forge build ios) and uploaded it to Apple TestFlight.
Unfortunately we received the warning from Apple for this fresh trigger.io core app too.

We looked for UIWebKit symbols (nm development/ios/device-ios.app/Forge | grep UIWebView). This is the result:

Expected behaviour
No usage of the deprecated UIWebView API in the trigger core. So that a fresh plain trigger core app is accepted from Apple.
Actual behaviour
Apple will stop accepting the submission of an app with trigger.io core from April on.
App information:

new created trigger.io app
Forge Platform version: 2.8.5
trigger config.json

{
	"config_version": "4",
	"name": "Test App",
	"author": "soemo",
	"version": "0.1",
	"platform_version": "v2.8.5",
	"description": "An empty app created by default",
	"core": {
		"general": {
			"logging": {
				"level": "DEBUG"
			},
			"reload": true
		},
	"ios": {
                "webview": "WKWebView",
                "device_family": "any",
                "package_name": "com.xyz.uiwebviewtest.ios"
               }
	},
	"modules": {
	}
}

Thank you for the report.
We've been keeping the window for UIWebView users open for as long as possible before permanently deleting the UIWebView support code from the runtime.
We'll be pushing a new build to staging that finally deletes UIWebView support from the runtime early next week.
Community discussion: https://community.trigger.io/t/final-removal-of-uiwebview-support/1047

Thank you for the explanation and announcement of the roadmap

I've just pushed platform version v2.8.6 which removes the last remaining UIWebView code from the Forge runtime.
You can update by bumping your platform version as follows:
"platform_version": "v2.8.6"

Thanks. We tried it out and with a new created trigger.io core app we received no the deprecated UIWebView warning from Apple anymore.
But if we include the bolts module into the config, we still see a reference to UIWebView in our app.
development/ios/device-ios.app/Forge | grep UIWebView
                 U _OBJC_CLASS_$_UIWebView
0000000100279bf0 s ___block_descriptor_48_e8_32s40r_e31_v24@?0@"UIWebView"8@"NSError"16l
0000000100279bc0 s ___block_descriptor_64_e8_32s40s48s56r_e19_v16@?0@"UIWebView"8l

The only reference to UIWebView in bolts we can found is in a comment though: https://github.com/trigger-corp/trigger.io-bolts/blob/ff8ff07e7eda08669de6898dd2317648bea64973/inspector/ios-inspector/ForgeModule/Bolts.framework/Headers/BFWebViewAppLinkResolver.h#L16
Looks like it uses https://github.com/BoltsFramework/Bolts-ObjC which has a reference to UIWebView. We saw this new PR UIWebview -> WKWebView
Might be necessary to update trigger.io-bolts to get a version that integrates this PR?
trigger config.json
{
	"config_version": "4",
	"name": "Test App",
	"author": "soemo",
	"version": "0.1",
	"platform_version": "v2.8.6",
	"description": "An empty app created by default",
	"core": {
		"general": {
			"logging": {
				"level": "DEBUG"
			},
			"reload": true
		},
		"ios": {
			"webview": "WKWebView",
			"device_family": "any",
			"package_name": "com.xyz.uiwebviewtest.ios"
		}
	},
	"modules": {
		"bolts": {
			"version": "1.9.0",
			"config": {}
		}
	}
}

Wow! Thank you so much for doing the legwork on this.
I've pulled the PR in question into bolts v1.10.0 and updated the parse module dependencies to the new version.
If you bump your Parse config to v3.2 you should be good to go:
"parse": {
    "version": "3.2",
    ...
}

Thanks, with the new module version we received no deprecated UIWebView warning for our app from Apple anymore.

When do you think will be version 2.8.6 set to stable?

Great to hear!
We'll probably be moving the release to stable towards the end of the month. We need to extend the window as wide as possible for everyone to get a chance to test submission.

To be honest, the end of the month is too late for us. To be really well prepared for the beginning of April, we need the stable version as soon as possible. Our internal deadline is the 20th of March.
If someone does not want to use it yet, he does not need to upgrade from version 2.8.5 to 2.8.6.

Unfortunately this is not a case of "you don't have to upgrade if you don't want to".
Apple will be rejecting app submissions that are not built with this release so it does affect all of our customers.
As other customers submit their apps it is likely that there will still be outstanding issues as their configurations are different from theirs.
As a consequence, pushing this branch to production prematurely will create a situation where we need to push out a new release for every customer!
You don't have to wait for a staging branch to be pushed to production if you are happy that your app passes review and wish to urgently submit for release. This is exactly the reason we started making our staging branch available publicly.

v2.8.6 has been pushed to stable:
https://trigger.io/docs/current/api/release_notes.html


New Attunement Altar, Drops 2 blocks when broken

Closed by https://github.com/Pursuit-of-Glowstone/Obsidimancy/commit/d213c72a1730e6cd3d01036b62c64ef41bebf250


allow win-arm64 platform

I've noticed that the ARM64 builds are also highlighted downloads even when using an x64 system. This probably isn't a great idea as those builds won't even run and less technically proficient users may get confused with the option.
@shuffle2 @delroth is it possible to only highlight the x64 Windows builds on x64 systems? I'm not sure how exactly the site does detection for that and if browsers on ARM systems include that info in their user agent or not.
I think the reverse situation of highlighting x64 builds on ARM systems is still fine as some users may still want to run those especially older versions before the buildbot was updated.

Afaik it’s not possible to differentiate.
I prefer it how it is (unless there’s a real way to differentiate)

It would be possible to differentiate using the new User Agent Client Hints feature. We would need to set the following headers in our response:
Accept-CH: Sec-CH-UA-Arch
Critical-CH: Sec-CH-UA-Arch

This would allow us to read the Sec-CH-UA-Arch header, which will either be arm or x86.
I don't really know Django, but if nobody is interested in contributing a patch then I could figure it out myself.

@reflectronic while i'm not against the idea, it's not that simple:

browser on windows arm64 could be x86, x64, arm32, arm64
browser on windows x64 could be x86, x64

It looks like Sec-CH-UA may expose enough information to resolve all these possibilities back to the real underlying OS arch, but I'm not sure / probably would need a test. It's not clear if the browser is required to expose the OS information or just information relating to the browser build itself (and it seems more likely to be the latter...?)
If the OS arch resolving fails, it's probably best to just fallback to highlighting both windows buttons (as it is now), as opposed to highlighting nothing.

it's not that simple

The standard specifically says that the only values that Sec-CH-UA-Arch can have are:

x86
arm
empty string

You need to use Sec-CH-UA-Bitness to differentiate between e.g. 32- and 64-bit Arm.

It's not clear if the browser is required to expose the OS information or just information relating to the browser build itself

The hints specifically describe "the user agent's underlying CPU architecture." Chromium specifically implements checks to detect the underlying CPU architecture, even when running under emulation or WOW64.

In general I'm in favor of switching to using CH for this (as long as we
fallback to the existing UA detection). It's not completely trivial since
that also means moving the implementation from server side to client side.
If you want to give it a shot please feel free to do so, I'll be busy in
the next few weeks so I'm unlikely to do so myself.
On Sat, Jul 16, 2022, 19:18 John Tur @.***> wrote:

it's not that simple
The standard specifically says
https://wicg.github.io/ua-client-hints/#http-ua-hints that the only
values that Sec-CH-UA-Arch can have are:

x86
arm
empty string

You need to use Sec-CH-UA-Bitness to differentiate between e.g. 32- and
64-bit Arm.
It's not clear if the browser is required to expose the OS information or
just information relating to the browser build itself
The hints specifically describe "the user agent's underlying CPU
architecture." Chromium specifically implements
https://github.com/chromium/chromium/blob/44fdbe2237e61b5c664290e2b9878098ae61a9aa/content/common/user_agent.cc#L109
checks to detect the underlying CPU architecture, even when running under
emulation or WOW64.
—
Reply to this email directly, view it on GitHub
https://github.com/dolphin-emu/www/pull/145#issuecomment-1186244169, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABRQLXG35YPTXVA43D5O7LVULVGRANCNFSM5ZAGIXYQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Additional log cleanup

When I run my servers, I have SourceMod, MetaMod and some other items generating log files. These end up in a few well-defined places. I'd like to look at adding a feature to the LGSM to either auto-detect well-known sources of logging (i.e. SourceMod), or allowing the user to define additional log directories to manage. If I can get some feedback, and other people think it's worthwhile, I'll start hacking away on this next week.

Just realized this is in line with #354 - not sure if we want to start a new discussion or carry on there?

Yep, i was gonna point you to my issue too !
I totally forgot about that !
I guess, for now, it's not in lgsm's philosophy to remove logfiles from addons unless we propose an optional installation. But it's still a good idea to cleanup at least default addons.
I'm gonna need some more BASH knowledge to fixt that. For now i'd rely on @dgibbs64 , or let me some time (maybe a bit long) to go work on that :)

Yeah I forgot about this as well. Im happy to support some common mods and it cannot be too difficult. But currently I dont have time.
in fact I really need to do some code rather that responding to all these issues :/

I've seen the gamelogdir variable
https://github.com/dgibbs64/linuxgsm/blob/master/GarrysMod/gmodserver#L83
https://github.com/dgibbs64/linuxgsm/blob/master/CounterStrikeGlobalOffensive/csgoserver
Did you already add support for some of the default gamelog files ? I guess yes ! Which is great.
For addons' logs removal, i can only think of an extension that would be supported by the skeleton directory. Once again :p
https://github.com/dgibbs64/linuxgsm/issues/585

Closing to merge with #354


Implement __eq__ Methods.

Hi all,
When writing tests I am finding that it would be nice to be able to assert that spectrum == ... ect. We can implement this functionality. Do you think it is worth the effort.
Regards
Jordan

This would have been very useful for implementing tests, however, it is now too late I think to make proper use of a structural change without just creating a lot more work.