zstd: 1.3.3 -> 1.3.4

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

https://github.com/facebook/zstd/releases/tag/v1.3.4
De facto closes #22218

Success on x86_64-linux (full log)
Attempted: zstd
Partial log (click to expand)
shrinking /nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4/lib/libzstd.so.1.3.4
shrinking /nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4/bin/zstd
gzipping man pages under /nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4/share/man/
strip is /nix/store/fzcs0fn6bb04m82frhlb78nc03ny3w55-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4/lib  /nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4/bin
patching script interpreter paths in /nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4
/nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4/bin/zstdless: interpreter directive changed from "/bin/sh" to "/nix/store/q1g0rl8zfmz7r371fp5p42p4acmv297d-bash-4.4-p19/bin/sh"
/nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4/bin/zstdgrep: interpreter directive changed from "/bin/sh" to "/nix/store/q1g0rl8zfmz7r371fp5p42p4acmv297d-bash-4.4-p19/bin/sh"
checking for references to /build in /nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4...
/nix/store/l4z9cpa9vgfhj80m697f2ng51ibras4d-zstd-1.3.4

Success on aarch64-linux (full log)
Attempted: zstd
Partial log (click to expand)
shrinking /nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4/bin/zstd
shrinking /nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4/lib/libzstd.so.1.3.4
gzipping man pages under /nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4/share/man/
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4/lib  /nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4/bin
patching script interpreter paths in /nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4
/nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4/bin/zstdgrep: interpreter directive changed from "/bin/sh" to "/nix/store/3gg2p6n4kv2f0lsxd41f5iz1ivkbzyzr-bash-4.4-p19/bin/sh"
/nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4/bin/zstdless: interpreter directive changed from "/bin/sh" to "/nix/store/3gg2p6n4kv2f0lsxd41f5iz1ivkbzyzr-bash-4.4-p19/bin/sh"
checking for references to /build in /nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4...
/nix/store/ikndl5afgr9jjqrfyca63l2w5llj841r-zstd-1.3.4


🐞 Extra characters added to "to hit" value before dice roller

Check for existing bug reports before submitting.

[X] I searched for existing Bug Reports and found no similar reports.

Expected Behavior
Parentheses in the to-hit parsing for an action before the dice roller token should only contain the +/- <value>  string and no extra characters.
Current behaviour
A couple characters (": " normally, but omitting the colon will result in other characters getting added) before the to-hit bonus are getting added to the portion in parentheses after the dice roller. The example markup provided in the readme renders like this:
  - name: Bite
    desc: "Melee Weapon Attack: +15 to hit, reach 15 ft., one target. Hit: 19 (2d10 + 8) piercing damage plus 9 (2d8) acid damage."

Reproduction
Parse a 5e statblock with the normal melee attack text (the Black Dragon example from the readme will replicate the issue).
Simple example:
```statblock
name: Extra Colon
size: Small
actions:
  - name: Bite
    desc: "Melee Weapon Attack: +15 to hit, reach 15 ft., one target. Hit: 19 (2d10 + 8) piercing damage plus 9 (2d8) acid damage."
```

Which Operating Systems are you using?

[ ] Android
[ ] iPhone/iPad
[ ] Linux
[ ] macOS
[X] Windows

Obsidian Version Check
1.4.16 and 1.4.13
Plugin Version
3.15.2
Confirmation

[X] I have disabled all other plugins and the issue still persists.

Possible solution
Possibly related to the recent fix for #135 ?

This should be fixed in v3.15.8


Would be better if TreeNode

Very nice lib!
It would be better if treeNode has generic type to make it easier to access data's fields without cast.

Hey, thank you for trying the package out!
I have worked with that before but  was lost somewhere and I still had to cast it in the example.
Any suggestions on how to approach this without making every class accept generics?

Any suggestions on how to approach this without making every class accept generics?

For now I haven't figured out a solution, or It might be suggested to write generics everywhere according to linter:rules - always_specify_types

For now I haven't figured out a solution, or It might be suggested to write generics everywhere according to linter:rules - always_specify_types

It's also written in there that we should use Object if we need that variable to override == and hashcode.
With generics I can't guarantee that the variable won't be dynamic.

Sure, I didn't see that.  Could give it a try


Updated Program list in ./Programs/README.md

This PR is related to:  Issue 32

Does it close the issue?:  Y

Summary:  Simplifies the name of each program.

Other:  NA

Sure, I'll make the changes


gas-report: rename binary to just gas-report

It's not MUD specific so we can rename from mud-gas-report to gas-report and let ~anyone use it.

what do you think about a separate repo for it? (the package could still be @latticexyz/gas-report) It is indeed completely standalone and we could reduce our package number a bit.
btw I called it mud-gas-report mostly as an analogy to mud gas-report (the only way it could be called before the new package), no strong reason for that name

I think we should continue to publish packages from the monorepo, even if they could technically exist standalone.


[AutoPR cognitiveservices/data-plane/WebSearch] Plug WebSearch for the automation

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/3000

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/2517


Information about extracting speaker signature value or speaker embedding

HI thanks for the wonderful toolkit. I am working on it and trying to dig down the code for speaker id classification. I had a confusion that in code speechbrain/templates/speaker_id/speechbrain/pretrained/interfaces.py line number 646 there is a code
"out_prob = self.modules.classifier(wavs).squeeze(1)"
I want to confirm what does this self.modules.classifier reffers to. I mean from where the function classifier is being called I want to see the internal code of classifier. Could you please help me out. Is it calling internally from classifer.ckpt ?? or some internal python function

Maybe you can take a look here to figure out how the interface work. For instance, look at these two lines:
from speechbrain.pretrained import EncoderClassifier
classifier = EncoderClassifier.from_hparams(source="speechbrain/spkrec-ecapa-voxceleb")

In the second like we basically read the hyperparameter file that you find here. As you can see this hyperparameter file has a pretrainer object that pretrain  the classifier with the file "classifier.ckpt" found in the repository.


Hue groups : tries to autodiscover, but shouldn't.

seeing this:
2021-11-29 10:47:05 ERROR (MainThread) [custom_components.powercalc.model_discovery] light.alarm: Cannot autodiscover model, not found in the hue bridge api
2021-11-29 10:47:05 ERROR (MainThread) [custom_components.powercalc.model_discovery] light.lounge: Cannot autodiscover model, not found in the hue bridge api
2021-11-29 10:47:05 ERROR (MainThread) [custom_components.powercalc.model_discovery] light.spots_on_the_wall: Cannot autodiscover model, not found in the hue bridge api
2021-11-29 10:47:05 ERROR (MainThread) [custom_components.powercalc.model_discovery] light.zolder_living: Cannot autodiscover model, not found in the hue bridge api

for all Hue groups.
Raising it here, for reference (aware this was discussed).

Yes we have discussed this on Discord. This is a know issue. Will fix this when Hue V2 support is released in HA.
Probably 2021.12
Will leave this issue as a reference so I don't forget to fix this.

@Mariusthvdb Is this one also resolved for you? Than we can close this issue.

yes! working perfectly! thanks a lot.


Replace std::aligned_storage due to depreceation

Hello,
According to P1413R3, aligned_storage (and aligned_union) are not to be used. From the paper's background:
aligned_* are harmful to codebases and should not be used. At a high level:

Using aligned_* invokes undefined behavior (The types cannot provide storage.)
The guarantees are incorrect (The standard only requires that the type be at least as large as requested but does not put an upper bound on the size.)
The API is wrong for a plethora of reasons (See "On the API".) Because the API is wrong, almost all usage involves the same repeated pre-work (See "Existing usage".)

Also see this stack overflow discussion for a brief summary of the issue, and cppreference for this paper being a part of the C++23 standard.
The suggested replacement (from the linked document) is:
template <typename T>
using aligned_storage = alignas(T) std::byte[sizeof(T)];

Aligned storage is used ~7 times in the codebase, and I would be happy to submit a PR with the proposed changes.

Yeah I’m aware of the issue, I read the papers from time to time I just didn’t have the capacity to take action. Please submit a PR if you can otherwise I’ll do it sometime in the future


[Feature] Seamless import/export for symbolic datasets using BDD representation.

Loading/storing BDDs is a pain. This should be much more user friendly.

This is currently blocked by the fact that we need the graph/context for a symbolic set, but it is not yet clear how this context should be serialized.