[flake8-noqa][help] Implement NQA002, NQA003, NQA004, and NQA005

Summary
Implement flake8-noqa rules. Part of #850.
Test Plan
Test fixtures have been added for all rules.

I'm hoping someone can help me here. I've basically finalized the rules, but I can't run cargo test because the project won't compile as whole, as can be seen in the failing test runs. It seems to be related to the new plugin being added to the registry, but I can't put my finger on the issue.
Appreciate any help.

Hi @augustelalande thanks for the pull request! I haven't looked at the changes yet but I think what you're looking for is cargo dev generate-all to get the schema up to date with your changes.

@zanieb cargo dev generate-all fails with the same error when compiling.
➜  cargo dev generate-all
   Compiling ruff_source_file v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_source_file)
   Compiling chrono v0.4.35
   Compiling ruff_formatter v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_formatter)
   Compiling lsp-types v0.95.0
   Compiling lsp-server v0.7.6
   Compiling ruff_python_trivia v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_python_trivia)
   Compiling ruff_notebook v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_notebook)
   Compiling ruff_python_ast v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_python_ast)
   Compiling quick-junit v0.3.5
   Compiling ruff_python_parser v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_python_parser)
   Compiling ruff_python_semantic v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_python_semantic)
   Compiling ruff_python_index v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_python_index)
   Compiling ruff_python_codegen v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_python_codegen)
   Compiling ruff_python_formatter v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_python_formatter)
   Compiling ruff_linter v0.3.2 (C:\Users\Auguste\workspace\ruff\crates\ruff_linter)
   Compiling ruff_workspace v0.0.0 (C:\Users\Auguste\workspace\ruff\crates\ruff_workspace)
error[E0275]: overflow evaluating the requirement `fn() -> RuleCodePrefix: Unpin`
  |
  = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`ruff_linter`)
note: required because it appears within the type `PhantomData<fn() -> RuleCodePrefix>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\marker.rs:809:12
note: required because it appears within the type `std::iter::Empty<RuleCodePrefix>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\sources\empty.rs:31:12
note: required because it appears within the type `std::option::Option<std::iter::Empty<RuleCodePrefix>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Empty<RuleCodePrefix>, Map<AirflowIter, {closure@codes.rs:65:1}>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Empty<RuleCodePrefix>, Map<AirflowIter, ...>>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Empty<RuleCodePrefix>, Map<AirflowIter, ...>>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Empty<RuleCodePrefix>, Map<AirflowIter, ...>>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Empty<RuleCodePrefix>, Map<..., ...>>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Empty<RuleCodePrefix>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Empty<RuleCodePrefix>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Empty<...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<Empty<...>, ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Map<Chain<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\map.rs:62:12
note: required because it appears within the type `Option<Map<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<Map<Chain<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Option<Chain<Map<Chain<Chain<Chain<..., ...>, ...>, ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\option.rs:570:10
note: required because it appears within the type `Chain<IntoIter<String, 6>, Chain<Map<Chain<..., ...>, ...>, ...>>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\chain.rs:23:12
note: required because it appears within the type `Filter<Chain<IntoIter<String, 6>, Chain<Map<..., ...>, ...>>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\filter.rs:19:12
note: required because it appears within the type `Filter<Filter<Chain<IntoIter<String, 6>, Chain<..., ...>>, ...>, ...>`
 --> /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce\library\core\src\iter\adapters\filter.rs:19:12

For more information about this error, try `rustc --explain E0275`.
error: could not compile `ruff_linter` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

Ah sorry I looked at the Linux CI which was failing for the reason I said but the Windows CI is indeed failing with that error
error[E0275]: overflow evaluating the requirement `fn() -> RuleCodePrefix: Unpin`
  |
  = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`ruff_linter`)

I'd recommend trying the change they suggest here.
cc @konstin who knows a bit more about Windows-specific Rust problems :)

@zanieb It doesn't seem like a windows only issue. Check out the mkdocs check (running ubuntu).

Thanks I could reproduce locally.
https://github.com/astral-sh/ruff/pull/10325/commits/1ad9498f3b9628d389ec95e5fd4a477ca324c387 should resolve this

@zanieb Thanks I was wary of making the change because I was also not sure of the implications.

Thank you @augustelalande, for working on the noqa rules.
I've reviewed the rules and to my understanding:

NQA002, NQA003 overlap with PGH004:

x = 2  # noqa X100 gets flagged by PGH004, although the error message could be improved (playground)
x = 2  # noqa  : X400 gets flagged by PGH004. Again, the error message could be improved (playground)

NQA005 overlaps with RUF100, although RUF100. RUF100 doesn't flag x = 2  # noqa: D100, D100, D100 today but the rule is focused on identifying unused noqa directives (the explanation is more narrowly focused but I think it fits well from the rule name)

That's why I think that it would be best to integrate:

NQA002 and NQA003 into PGH004 by improving the error message and providing a specific fix when we identify the incorrect formatting fix. The rules fit in my view because blanked-noqa is about catching any noqa suppressions that ruff would interpret as blanked noqas
NQA005 into RUF100

I don't think there's an existing rule that covers NQA004, although I think it's worth considering moving the rule to RUF, considering that it's the only remaining noqa rule.
What do you think?

That sounds fine to me.

Done. If you merge this, you may want to consider closing #850, as I don't think anything else from there needs to be added to ruff.

I'm gonna split this into seperate PRs to make it easier to merge.


Adding pre-commit hook for auto code formatting

This PR adds a pre-commit hook to ensure consistent code formatting.

@gaursagar21 my bad... Noticed this now-

How can we configure prettier settings?

Nevertheless, the new one seems more compact and readable. Keeping it for now.

pre-commit depends on the repo instead of PyPI index, causing a bug.
https://www.reddit.com/r/Python/comments/yvfww8/flake8_took_down_the_gitlab_repository_in_favor/

https://github.com/Udayraj123/OMRChecker/issues/119


Can You Give A WebSIte Example which is tested?

In fact I test the following website

meta.discourse.org
meta.discoursecn.org

my local machine

none of it works

Oooops!  Its my network configuration error.
my local machine works now!


[Package Issue]: Google.Chrome.Beta 120.0.6099.5 identified as >118...

Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue
Installation issue.
Brief description of your issue
my currently installed Google.Chrome.Beta is 119.0.6045.21 (Official Build) beta (64-bit)
but Winget identifies it as > 118.0.5993.18
> winget upgrade
Name               Id                 Version         Available    Source
-------------------------------------------------------------------------
Google Chrome Beta Google.Chrome.Beta > 118.0.5993.18 119.0.6045.9 winget
1 upgrades available.

Steps to reproduce

install Google.Chrome.Beta
open the program, navigate to Help -> About  ( chrome://settings/help )
restart browser if it just did a self-update
check Help -> About again
check the output of winget upgrade

Actual behavior
Winget tries to downgrade Google.Chrome.Beta from v119.0.6045.21 to  v119.0.6045.9
edit: but when actually trying to install, it fails because of installer hash not matching.
PS C:\WINDOWS\system32> winget upgrade Google.Chrome.Beta
Found Google Chrome Beta [Google.Chrome.Beta] Version 119.0.6045.9
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://dl.google.com/tag/s/dl/chrome/install/beta/googlechromebetastandaloneenterprise64.msi
  ██████████████████████████████   110 MB /  110 MB
Installer hash does not match; this cannot be overridden when running as admin
PS C:\WINDOWS\system32>

/edit
Expected behavior
do not nuke newer versions
Environment
Windows Package Manager v1.6.2771
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.3570
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.2771.0

Screenshots and Logs

side note: Google.Chrome.Beta might be another package that could use the UpgradeBehavior: deny  mechanism introduced with the new version 1.6.0 client, but for which we don't have a schema manifest yet  https://github.com/microsoft/winget-pkgs/issues/121127
this is because Beta upgrades for Chrome have a way faster release cadence than winget can keep up with...

in PR https://github.com/microsoft/winget-pkgs/pull/122849 the manifest for Chrome Beta was changed to 119.0.6045.21
but... the existing Chrome Beta version is still mis-identified as 118-something and when trying to apply the update shows
A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version.

another note:
my Chrome Beta was originally installed with the EXE installer from https://www.google.com/chrome/beta/
but winget is trying to upgrade it using the MSI for Enterprise installer....  so i uninstalled that one and re-installed the MSI one from winget ...
... and the problem still remains, Chrome Beta 119.0.6045.21 that was just installed moments ago... is detected as being 118-something... and winget wants to upgrade it again, using the same MSI installer:
(btw, the package that cannot be determined below is an older version of Mikrotik.TheDude)

side note: Google.Chrome.Beta updated itself to version 119.0.6045.33.. and the 118 version identification by winget is still happening... and winget is yet again trying to downgrade it to 119.0.6045.21 because it has no manifests for newer versions.
for future versions where it happens i will just change the issue title without adding additional comments.

It seem like does it side to side install.

Chrome Beta on my systems it is not a side-by-side installation, it is installed system-wide (scope: machine)
(yes, plural - the problem with winget happens the same on multiple machines)

also, the stable version of Chrome is 119.0.6045.106 (currently), so i don't know where winget is pulling the 118 version number from...

i found a version 118 of a Chromium-derived browser ... but is Microsoft Edge, not Google Chrome... could winget mis-identify MS Edge as Google Chrome?

I think could be displayed version key was not deleted.

I am going to do with a quick check to see if binary is correct.

It look like I was trying to download but an interrupted action which is vanity url

Resolving where is the hashes failed.

@denelon. Sometimes, it was misidentified or winget confused.

The pipelines was merged #124544. Is the issue still persists.

Chrome Beta is still identified as version 118-something.... ¯\_(ツ)_/¯

I am going to del superseded manifests. This one might help

Waiting to see if #124601 get merged.

@R-Adrian, Can you see if that one was resolved?.

It seem like need to cleanup all the folder.

Someone set display version and upgrade code which caused it

I am going to del all other version left the newest version.

Can you see if that one was resolved?.

the problem still happens

Someone set display version and upgrade code which caused it.

i looked back through the commit history, it looks like this started to happen when @vedantmgoyal2009 migrated the winget package manifest version from 1.2.0 to 1.5.0 ,,, but i cannot figure out where did they get that DisplayVersion number from...
https://github.com/microsoft/winget-pkgs/pull/117105/commits/3dc8c61a62f54b994bce28ab60ba2877d02ca680

Can you double check to see if the hashes was mismatched on current version.

 Installer Url: https://dl.google.com/tag/s/dl/chrome/install/beta/googlechromebetastandaloneenterprise64.msi
 Installer SHA256: 88e53d6fb3d9cc1a67273e6a911a82806587c72d55e6c6c59a13ca772b19749f

those lines from the 120.0.6099.5 manifest are still correct, that SHA256 hash matches the file that i just downloaded manually from Google.
I forced a re-install of the MSI on top of the existing Chrome Beta and the version 118 detection still happens... (i think because the other pull requests to delete old version of manifests have not been commited yet)
> winget upgrade
Name               Id                 Version         Available    Source
-------------------------------------------------------------------------
Google Chrome Beta Google.Chrome.Beta > 118.0.5993.11 120.0.6099.5 winget
1 upgrades available.

Yes, that is true

The manifest cleanup of old versions has finally been approved and commited, the wrong version detection is no longer happening.
Thank you!

(that pin for Discord in the screenshot is an unrelated issue - the Discord app is doing self-updates but is not updating the version number in registry when it updates itself))


Very slow stdout

Hi,
I am working on porting this library for NXP IMXRT1062, NewlibNano and FreeRTOS environment. It is really not a easy task but and I am at good way to go.
Bu I have strange problem with very slow text outputs to stdout. I am using semihost debug console, I know semihost it is slow by design, but it is working fine at all my other projects .

If realsense library is not in the project, then all text output to stdout are buffered. STD library is waiting for end of line to transmit whole buffer at once. This method is fast.
If realsense library is included in the project, then this buffer is somehow disabled and every character is printed immediately and it is extremely slow. Problem is caused even if library is not used but it is included and compiled in project.

I look manually at library sources but I did not found part of code that can possibly cause disabling of stdout buffer.
Can you guys know where is the problem?
Regards,
Peter.

Maybe try disabling debug to console when building the lib:  cmake -DRSID_DEBUG_CONSOLE=OFF ..

Maybe try disabling debug to console when building the lib: cmake -DRSID_DEBUG_CONSOLE=OFF ..

I am not using cmake.
This symbol is undefined in my project settings. I  try to add new symbol RSID_DEBUG_CONSOLE=OFF to my project setting and it did not solve the problem.
I fund in realsense source code, this is used in some multiple parts of code: #ifdef RSID_DEBUG_CONSOLE.
So, I think it is correct to keep symbol undefined rather then defined it to OFF value.

I fund in realsense source code, this is used in some multiple parts of code: #ifdef RSID_DEBUG_CONSOLE.
So, I think it is correct to keep symbol undefined rather then defined it to OFF value.

Right, when not using CMake, the equivalent of  cmake -DRSID_DEBUG_CONSOLE=OFF is not to define RSID_DEBUG_CONSOLE


GNR, SRF, GRR, MTL: Release event updates

GNR

Release core events TX_MEM.ABORT*, RESOURCE_STALLS.SB, RTM_RETIRED.*, OCR.READS_TO_CORE.*, OCR.DEMAND_DATA_RD.*, OCR.DEMAND_RFO.ANY_RESPONSE, OCR.RFO_TO_CORE.L3_HIT_M, and OCR.WRITE_ESTIMATE.MEMORY
Update FRONTEND_RETIRED.LATE_SWPF MSR value.
Release uncore power and sleep state events.

SRF

Update ARITH.DIV_ACTIVE description.
Move uncore events UNC_CHA_TOR_OCCUPANCY.IA_* out of experimental and release numerous uncore power and sleep state events.

GRR

Update ARITH.DIV_ACTIVE description.

MTL

Release E-core events OCR.[FULL, PARTIAL]_STREAMING_WR.ANY_RESPONSE, BR_INST_RETIRED.*, BR_MISP_RETIRED.INDIRECT_JMP, MEM_UOPS_RETIRED.STLB_MISS_[LOADS, STORES] and MS_DECODED.MS_BUSY.
Release P-core event RESOURCE_STALLS.SB.

All events reviewed and approved internally before submitting.


Chat Header shrinks as more messages are added by the chatbot

Bug
Chat header shrinks gradually from 48px height to a max of 40px height, as messages are added by the chatbot.

Fixed


Revert "Upgraded microsite to Docusaurus 3.6"

This reverts commit 93a091cdf8aba795b9446034f673f8d2e517a2cd.
Hey, I just made a Pull Request!
I think timeline matches as deploy_microsite.yml is broken for some reason since then :(

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

@h7kanna if you have any ideas

Oh, I did not check the deploy step. only the build step which passed successfully.
I am suspecting CPU starvation indicated The hosted runner: GitHub Actions 611 lost communication with the server. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error. as Docusaurus 3.6 does multithreading.


@module-federation/native-federation-typescript doesn't create remoteEntry.js upon build for vite and rspack

Describe the bug
Running vite build while @module-federation/native-federation-typescript is configured to expose an exported function, doesn't create a remoteEntry.js file in my dist folder.
@mf-types.zip file is being created fine though.

I use react with vite as build tool
I installed<EMAIL_ADDRESS>I made my app entry point async with `import("./bootstrap")
I export a simple Customer function-component:

export function Customer() {
   return
hi
;
}

my config looks like this:

// vite.config.ts

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { NativeFederationTypeScriptRemote } from "@module-federation/native-federation-typescript/vite";
import packageJson from "./package.json";

const moduleFederationConfig = {
  name: "mfRemote",
  filename: "remoteEntry.js",
  exposes: {
    "./customer": "./src/components/customer",
  },
  shared: {
    ...packageJson.dependencies,
    react: {
      singleton: true,
      eager: true,
      requiredVersion: packageJson.dependencies.react,
    },
    "react-dom": {
      singleton: true,
      eager: true,
      requiredVersion: packageJson.dependencies["react-dom"],
    },
  },
};

export default defineConfig({
  plugins: [
    NativeFederationTypeScriptRemote({ moduleFederationConfig }),
    react(),
  ],
  server: {
    port: 3000,
    proxy: {
<EMAIL_ADDRESS>{
        target: "http://localhost:3000",
        changeOrigin: true,
        rewrite: () => `/<EMAIL_ADDRESS>      },
    },
    fs: {
      allow: ["./dist", "./src"],
    },
  },
});

I tested it on mac, windows and wsl and I got the same result

I downloaded the example from module-federation-examples/native-federation-tests-typescript-plugins and built the remote app with vite, rspack and webpack and remoteEntry.js file was created only for webpack build

Reproduction
https://github.com/module-federation/module-federation-examples/tree/master/native-federation-tests-typescript-plugins
Used Package Manager
npm
System Info
System:
    OS: macOS 14.6.1
    CPU: (10) arm64 Apple M2 Pro
    Memory: 42.09 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.13.1 - ~/.nvm/versions/node/v20.13.1/bin/node
    npm: 10.8.1 - ~/.nvm/versions/node/v20.13.1/bin/npm
    pnpm: 9.7.1 - ~/.nvm/versions/node/v20.13.1/bin/pnpm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 127.0.6533.120
    Safari: 17.6

Validations

[X] Read the docs.
[X] Read the common issues list.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Module federation issue and not a framework-specific issue.
[X] The provided reproduction is a minimal reproducible example of the bug.

rspack has v2 built in which already has typescirpt support as first class, no need for this plugin on rspack builds

@ScriptedAlchemy Thanks, I just realized that this package is only for providing and consuming the types of the remote entries, not for the providing and consuming the entries themselves. I must of misread the documentation


If kubedns is not up and running, the installation continues

There seems to be a regression in our kubedns readiness validation, as I just ran into a case where kubedns did not come up properly, but the installation continued.

Technically not a regression in dev, as it's also in 1.5.3.

I've seen where a pod would be reported as ready for a few seconds before the healthProbes reported otherwise and then Ansible would pick this up and continue, could this be something that is happening?

Judging from these logs, looks like something is wrong, as stdout is empty:
12984 2017-09-28 14:22:52.102+0000 - FAILED - RETRYING: wait up to 5 minutes until DNS pods are ready (20 retries left).Result was: {
12985 2017-09-28 14:22:52.102+0000 -     "attempts": 11,
12986 2017-09-28 14:22:52.102+0000 -     "changed": true,
12987 2017-09-28 14:22:52.102+0000 -     "cmd": [
12988 2017-09-28 14:22:52.102+0000 -         "kubectl",
12989 2017-09-28 14:22:52.102+0000 -         "get",
12990 2017-09-28 14:22:52.102+0000 -         "deployment",
12991 2017-09-28 14:22:52.102+0000 -         "kube-dns",
12992 2017-09-28 14:22:52.102+0000 -         "-n",
12993 2017-09-28 14:22:52.102+0000 -         "kube-system",
12994 2017-09-28 14:22:52.102+0000 -         "-o",
12995 2017-09-28 14:22:52.102+0000 -         "jsonpath={.status.availableReplicas}"
12996 2017-09-28 14:22:52.102+0000 -     ],
12997 2017-09-28 14:22:52.102+0000 -     "delta": "0:00:00.204607",
12998 2017-09-28 14:22:52.102+0000 -     "end": "2017-09-28 14:22:51.657813",
12999 2017-09-28 14:22:52.102+0000 -     "failed": false,
13000 2017-09-28 14:22:52.102+0000 -     "failed_when_result": false,
13001 2017-09-28 14:22:52.102+0000 -     "invocation": {
13002 2017-09-28 14:22:52.102+0000 -         "module_args": {
13003 2017-09-28 14:22:52.102+0000 -             "_raw_params": "kubectl get deployment kube-dns -n kube-system -o jsonpath='{.status.availableReplicas}'",
13004 2017-09-28 14:22:52.102+0000 -             "_uses_shell": false,
13005 2017-09-28 14:22:52.102+0000 -             "chdir": null,
13006 2017-09-28 14:22:52.102+0000 -             "creates": null,
13007 2017-09-28 14:22:52.102+0000 -             "executable": null,
13008 2017-09-28 14:22:52.102+0000 -             "removes": null,
13009 2017-09-28 14:22:52.102+0000 -             "warn": true
13010 2017-09-28 14:22:52.102+0000 -         }
13011 2017-09-28 14:22:52.102+0000 -     },
13012 2017-09-28 14:22:52.102+0000 -     "rc": 0,
13013 2017-09-28 14:22:52.102+0000 -     "retries": 31,
13014 2017-09-28 14:22:52.102+0000 -     "start": "2017-09-28 14:22:51.453206",
13015 2017-09-28 14:22:52.102+0000 -     "stderr": "",
13016 2017-09-28 14:22:52.102+0000 -     "stderr_lines": [],
13017 2017-09-28 14:22:52.102+0000 -     "stdout": "",
13018 2017-09-28 14:22:52.102+0000 -     "stdout_lines": []
13019 2017-09-28 14:22:52.102+0000 - }

And then:
13849 2017-09-28 14:26:29.285+0000 - TASK [kube-dns : fail if DNS pods are not ready] *******************************
13850 2017-09-28 14:26:29.285+0000 - task path: /Users/abrand/Downloads/ket153/ansible/playbooks/roles/kube-dns/tasks/main.yaml:43
13851 2017-09-28 14:26:29.307+0000 - skipping: [ip-10-0-3-18] => {
13852 2017-09-28 14:26:29.307+0000 -     "changed": false,
13853 2017-09-28 14:26:29.307+0000 -     "skip_reason": "Conditional result was False",
13854 2017-09-28 14:26:29.307+0000 -     "skipped": true
13855 2017-09-28 14:26:29.307+0000 - }

I think the grep -v might be the culprit since it doesn't work as I thought it does when I wrote this.


An easy way to find synonyms and related terms in Transifex

This is a wish list item. It is unlikely to happen in the near future.
I find it somewhat uncomfortable to find the synonyms and related terms in Transifex. I get the idea (which may be true), that some presets and fields just don't have them added in English / elsewhere yet and therefore I'm unable to add them in English. Or that, due to the way synonyms and related terms structure has changed historically, some may be listed in the preset's own translation and it is not communicated to the translator.
The problem is that names, synonyms and related terms are not well linked and therefore one must resort to regular search and may need to go into the preset's file to find the terms to search for.
(If there are names which are not supposed to have synonyms or related terms for some reason let me know)
( This issue's focus is similar to https://github.com/openstreetmap/id-tagging-schema/issues/289 )

My understanding is, that the EN terms all belong inside the JSON, not inside Transifex. I expected Transifex to not have any content there, since that would be a weird duplication of what is in the JSON directly. I tried describing that in https://github.com/openstreetmap/id-tagging-schema#translations.
Btw, we need to update that section since it is not only the "terms" key only, anymore, right?


Revert disabling hex private registry unit test

The private registry server is back up, so these are now failing (yay for pending showing when this happens!)
This reverts https://github.com/dependabot/dependabot-core/pull/6930/commits/1c4cc2de36e0f502c99e041af1be2b812454d17f which landed as part of https://github.com/dependabot/dependabot-core/pull/6930.
Long term it'd still be convenient if these didn't depend on an external private registry(https://github.com/dependabot/dependabot-core/issues/6931); however, they do serve as a nice integration test (or a surprising one if it gets upgraded unexpectedly!)
For now though this unblocks main.

True, VCRs won't help us if Hex is making the calls so we need to figure that out.


Combining multiple files into one keeps references to some api files

Problem
I have an API splitted in several files and I have used swagger-cli to combine those files into one (to use that file in API consumer services/applications)
When any API file is referenced using $ref that file is exported (included) in the new API file as component (that's good). But those files that are referenced without using $ref are exported (included in the bundled file) keeping the reference to the file.
Example
Let's suppose that we have OpenApi.yaml that has this endpoint deffinition
 [...]
 /offering:
    post:
      [...]
      requestBody:
        description: This is an offering
        required: true
        content:
          application/json:
            schema:
              $ref: ./Offering.yaml
 [...]

This is Offering.yaml
title: Offering
description: Interface of offering requests
oneOf:
  - $ref: ./LocalOffering.yaml
  - $ref: ./InternationalOffering.yaml
discriminator:
  propertyName: type
  mapping:
    local: ./LocalOffering.yaml
    international: ./InternationalOffering.yaml

When I combine the API files (executing: swagger-cli bundle OpenApi.yaml --outfile CombinedApi.yaml --type yaml) this is the outcome (CombinedApi.yaml):
 [...]
Offering:
      title: Offering
      description: Interface of offering requests
      oneOf:
        - $ref: '#/components/schemas/LocalOffering'
        - $ref: '#/components/schemas/InternationalOffering'
      discriminator:
        propertyName: type
        mapping:
          local: ./LocalOffering.yaml
          international: ./InternationalOffering.yaml
 [...]

As we can see the discriminator.mapping.local and discriminator.mapping.international keeps files references. That means that we need those files so the combination in one file is not valid
Expected behavior
I would expect than those files referenced without using $ref would be exported in a way (maybe the same way that $ref ones) that doesn't keep the reference to the files.
Expected outcome:
 [...]
Offering:
      title: Offering
      description: Interface of offering requests
      oneOf:
        - $ref: '#/components/schemas/LocalOffering'
        - $ref: '#/components/schemas/InternationalOffering'
      discriminator:
        propertyName: type
        mapping:
          local: '#/components/schemas/LocalOffering'
          international: '#/components/schemas/InternationalOffering'
 [...]

Same problem here


WFLY-12759 Extract microprofile-config galleon layer from observability

https://issues.jboss.org/browse/WFLY-12759
Microprofile specs like OpenAPI don't require metrics nor health, suggesting the microprofile layers should be more granular.

@bstansberry Fixed.

@jmesnil OK with you?

Actually, would it make any sense to document this in {{docs/src/main/asciidoc/_admin-guide/Galleon_provisioning.adoc}}? Seems unnecessary as its basically not useful by itself.

@rhusar MicroProfile Config is usable directly by applications, so any layer at all could possibly be decorated with this one.
It seems simpler to document them all too.


Possible Error in Documentation

Note sure if this is a bug or my misunderstanding regarding your program, but I thought I would file this just in case:
Your documentation "Create your first rule": https://github.com/tfeldmann/organize
When you use the demo scripts in the manual or your own scripts, if you use the word "locations" instead of "folders" it outputs an error:
rules:

name: "PDF"
locations: ~/Desktop/incomplete
subfolders: true
filters:

extension: pdf
actions:
echo: "Found Files!"
move: ~/Desktop/complete/

Working Version:
rules:

name: "PDF"
folders: ~/Desktop/incomplete
subfolders: true
filters:

extension: pdf
actions:
echo: "Found Files!"
move: ~/Desktop/complete/

Screenshots*
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

OS: Ubuntu 22.04
Output of organize --version:
1.10.1

Your config file
# paste your config file here

My mistake, ubuntu installed a very very old version for some reason.


Refactor Closure Library to npm

Seriously, the world needs that. Bying able to consume Closure Library goodness without base and compiler would be awesome.

We would like to build a roadmap to ES6 modules but the world isn't ready for that yet and we aren't going to go to something else before that.

World ready is. Check https://babeljs.io

No browser implements es6 modules.
On Tue, Aug 4, 2015, 5:25 PM Daniel Steigerwald<EMAIL_ADDRESS>wrote:

World ready is. Check https://babeljs.io
—
Reply to this email directly or view it on GitHub
https://github.com/google/closure-library/issues/511#issuecomment-127802641
.

JavaScript is compiled language now. I don't know why you guys are not eating your dog food - Traceur. Or use Babel.

+1

You can use Closure with Node/NPM right now. Look at the README.
We don't promise support for any particular library though. It's possible some are making references to web-only constructs and will break. That said, the libs that are obviously not web-based are fine (e.g., goog.crypt).


Added some defaults to the javascript side, fixed some path issues

looks good, but maybe it should be possible for users in the future to set the quality


Add manual expansion for event search

The client currently manually expands the venue, category, and subcategories. We also need the organizer. Can this be manual or be updated?

Hi @nswekosk
Sorry for late answer. I will update on this weekend.


No upstream host populated

I'm using a custom bridge instead of linked containers
vagrant@vagrant-ubuntu-trusty-64:~$ sudo docker exec es-reverse-proxy nginx -t
2016/04/12 13:37:04 [emerg] 25#25: no host in upstream ":9200" in /etc/nginx/conf.d/default.conf:35
nginx: [emerg] no host in upstream ":9200" in /etc/nginx/conf.d/default.conf:35
nginx: configuration file /etc/nginx/nginx.conf test failed

# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
# scheme used to connect to this server
map $http_x_forwarded_proto $proxy_x_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}
# If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any
# Connection header that may have been passed to this server
map $http_upgrade $proxy_connection {
  default upgrade;
  '' close;
}
gzip_types text/plain text/css application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
log_format vhost '$host $remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent"';
access_log off;
# HTTP 1.1 support
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
server {
        server_name _; # This is just an invalid value which will never trigger on a real hostname.
        listen 80;
        access_log /var/log/nginx/access.log vhost;
        return 503;
}
upstream es-node1.dev.company.internal {
                        # es-node1
                        server :9200;
}
server {
        server_name es-node1.dev.company.internal;
        listen 80 ;
        access_log /var/log/nginx/access.log vhost;
        location / {
                proxy_pass http://es-node1.dev.company.internal;
        }
}
upstream es-node2.dev.company.internal {
                        # es-node2
                        server :9200;
}
server {
        server_name es-node2.dev.company.internal;
        listen 80 ;
        access_log /var/log/nginx/access.log vhost;
        location / {
                proxy_pass http://es-node2.dev.company.internal;
        }
}
upstream es-node3.dev.company.internal {
                        # es-node3
                        server :9200;
}
server {
        server_name es-node3.dev.company.internal;
        listen 80 ;
        access_log /var/log/nginx/access.log vhost;
        location / {
                proxy_pass http://es-node3.dev.company.internal;
        }
}

vagrant@vagrant-ubuntu-trusty-64:~$ sudo docker network inspect development
[
    {
        "Name": "development",
        "Id": "f6c03cd6fabb1d409b2557a4acb210af91bbcb9f046f3e1b6295b8cf620da2f2",
        "Scope": "local",
        "Driver": "bridge",
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "<IP_ADDRESS>/16",
                    "Gateway": "<IP_ADDRESS>/16"
                }
            ]
        },
        "Containers": {
            "183dbe6091ea94335ec117b2ae3d0f641c2a22e59ab3cf2221d921e1777fe516": {
                "Name": "es-node1",
                "EndpointID": "0496e4a5e71104a028e116b797d622e48b5a36bf36da845b68d382270b63a157",
                "MacAddress": "02:42:ac:12:00:03",
                "IPv4Address": "<IP_ADDRESS>/16",
                "IPv6Address": ""
            },
            "a53e925b6121e45d1310c2b6d58b3f55656d361a187bb509bad6d7eb3652f66f": {
                "Name": "es-node2",
                "EndpointID": "4bd02cdd3940f61a82944313433047c50c3222fd485537915ef9f17c71e643a9",
                "MacAddress": "02:42:ac:12:00:04",
                "IPv4Address": "<IP_ADDRESS>/16",
                "IPv6Address": ""
            },
            "aafd5b274b445e5fc7c0816d053ce115ce9d77f733fa3e58339f3bdd875a423c": {
                "Name": "es-node3",
                "EndpointID": "051d8986213efc65d6eff3a23bd584e6438b7e463a2990c078985c8c3310a39b",
                "MacAddress": "02:42:ac:12:00:05",
                "IPv4Address": "<IP_ADDRESS>/16",
                "IPv6Address": ""
            },
            "ef7f08a449ed2065bf2d2025b2266d39ffee34a4f6bbe52ab49a8db38c778013": {
                "Name": "es-reverse-proxy",
                "EndpointID": "4f20981157e3689d8c7e0ff377fa87c2df8bef2eb6445f83ac22651243a0c273",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "<IP_ADDRESS>/16",
                "IPv6Address": ""
            }
        },
        "Options": {}
    }
]

Related to #304?

Yeah after digging through I think so


add binary_paintshop example to ionq

Hi @MLeib, I fixed the header and added the _book.yaml entry for our site. I also removed an API key that was left in there, and in order to remove it from git history I rebased your commit. You won't be able to push from your local branch because of this, I recommend removing your local branch (git branch -D ionq_bpsp_example) and checkout your remote branch again (git checkout origin/ionq_bpsp_example -b ionq_bpsp_example or similar).

A couple of small comments.  I will take another pass on this to flesh it out a little bit more, but let's get this one submitted.


Anyway to fetch an XML using, well fetch?

Anyway to fetch an XML using, well fetch?
I saw json() cmd, but nothing for xml() or event pure text?
regards
Sean.

You will need to parse XML yourself by piping res.body or passing res.text() to the parser module of your choice.
ref:

https://github.com/bitinn/node-fetch#usage
https://fetch.spec.whatwg.org/

tx for the quick response, I have tried .text() but for some reason I get back
Promise {  }
while it is just a pure  that I get back, odd...

Just remove the console.log ;)

well I want to display to the user the returned output (its a cmd line utility) but the promise string is pre-appended


discussion about commit message styles; closes #302

I agree. Motivation for this is that the group asking for the workshop explicitly asked about it but it is not meant to overwhelm beginners and I need to make that part clearer.


Can't assign D input to the action

I installed version 4
and added to rpg.toml  this:
[inputs.up]
    name = "up"
    repeat = true
    bind = "w"

[inputs.down]
    name = "down"
    repeat = true
    bind = "s"

[inputs.right]
    name = "right"
    repeat = true
    bind = "d"

[inputs.left]
    name = "left"
    repeat = true
    bind = "a"

My hero does not move right direction (D is not assignable)
Expected result: My player can move to right direction

Hello,
I can't reproduce the error. On my side, the character moves well.
I'm still looking...

Hello,
You were right.
I am sorry, this issue occurred because of my browser extension.


Fabricated words in the daily puzzle

Apologies for using this channel for feedback, but I couldn't find any other ones.
Recently the solution to the daily puzzle has on multiple occasions been a word not included in the Kielitoimiston Sanakirja wordlist. Today's word (12.7.24, to avoid spoilers) hasn't even a (Finnish language) definition discoverable by online search.
[Edit. In the end, I did find today's word in Kielitoimiston Murresanakirja. Maybe the change I'm wishing for is if the game would link to the right dictionary, instead of always to Kielitoimiston Sanakirja.]
I can understand the desire or need to include words beyond the original corpus, but, if I may, I would like to propose that all included words should have a linkable-to definition, preferably by a dictionary.
Thanks for reading and, despite this minor gripe, many thanks for the game.

Words on the daily puzzle have been picked mostly randomly from the full word list, which started off from the Kielitoimiston Sanakirja based material, but has since been adjusted based on the feedback received, as people mostly wanted more pretty reasonable spoken finnish words to be added that were missing from the original dictionary material.
As of today, I've received nearly 27k requests to alter the word list through the Google Forms, but nowadays I have little interest in actually maintaining it as that work was quite labor intensive and this game is/was a small hobby project of a single person. Nowadays I just skim through the feedback every now and then, sometimes changing something but this project is on pretty inactive maintenance mode nowadays. I plan to keep this game online for the time being, as there's still a reasonable number of active players and hosting this only costs me the domain.
The daily word of 12.7.2024 (kuiru) was indeed a bad one, and while I've attempted to manually review the list https://github.com/Cadiac/sanuli/blob/master/src/bin/generate-daily-words.rs script generates (while removing duplicates that have already been the sanuli of the day) this must've slipped through last time I extended the list of daily words in January.
I'll probably drop "kuiru" from the word list as it has a pretty obscure meaning, it was added on the relatively early days 2022-01-23 after someone requested it, explaining it being a word for a type of a boat.
The link to a dictionary is a "best effort" lazy solution - just always linking to kielitoimiston sanakirja with that word as the query parameter. Support for linking to alternative dictionaries wouldn't be difficult to implement, but gathering the dictionary link to use for all ~8k words on the full-words.txt would take a lot of half manual work that I'm at least unwilling to do at this time.
Thanks for the feedback anyways!

Thanks for responding.


[AutoPR frontdoor/resource-manager] [AFD WAF] Add defaultState and defaultAction to managed rule set definitions

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

(message created by the CI based on PR content)

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


[BUG] Callibration does not work with OAK-D-SR.

Describe the bug
When launching command:
python3 calibrate.py -s 3.76 --board OAK-D-SR -nx 17 -ny 9
I get error:
Traceback (most recent call last):
  File "calibrate.py", line 1192, in <module>
    Main().run()
  File "calibrate.py", line 1181, in run
    self.startPipeline()
  File "calibrate.py", line 474, in startPipeline
    pipeline = self.create_pipeline()
  File "calibrate.py", line 565, in create_pipeline
    sensorName = cam_info['sensorName']
KeyError: 'sensorName'

Minimal Reproducible Example
Followed the documentation at:
https://docs.luxonis.com/projects/hardware/en/latest/pages/guides/calibration/?highlight=calibrate
My depthai repo is at e1c1f58746ff.
Additional context
I did little printing from callibrate.py.
cameraProperties = self.device.getConnectedCameraFeatures()
is:
[{socket: RGB/CENTER/CAM_A, sensorName: OV9782, width: 1280, height: 800, orientation: AUTO, supportedTypes: [COLOR, MONO], hasAutofocus: 0, name: color}]
self.board_config
is: {'name': 'OAK-D-SR', 'revision': 'R0M0E0', 'cameras': {'LEFT': {'name': 'left', 'hfov': 71.86, 'type': 'color', 'extrinsics': {'to_cam': 'RIGHT', 'specTranslation': {'x': -2.0, 'y': 0, 'z': 0}, 'rotation': {'r': 0, 'p': 0, 'y': 0}}}, 'RIGHT': {'name': 'right', 'hfov': 71.86, 'type': 'color'}}, 'stereo_config': {'left_cam': 'LEFT', 'right_cam': 'RIGHT'}}
I am able to run
python3 -m depthai_viewer
however the resulting point cloud  shows significant barrel distortion when flat wall with dots is viewed:

pip install depthai -U should fix the issue.


Failed to parse response data

Operating System version: Ubuntu 16.04
Firebase SDK version: ____
Library version: 5.0.0
Firebase Product: notification

[REQUIRED] Step 3: Describe the problem
I'm using firebase-admin to fire FCM notifications to iOS and Androids clients. The module work fine but some time throw exception "Failed to parse response data"
I've tried to search but seem no one report it before and I don't know why it's happen.
Steps to reproduce:
Fire FCM notification
fcmSender.messaging().sendToDevice(registrationTokens, fcmPayload, fcmOptions)

Here is trace log:
Error: Failed to parse response data: "SyntaxError: Unexpected end of JSON input". Raw serverresponse: "."
  File "/backend/node_modules/firebase-admin/lib/utils/error.js", line 39, col 28, in FirebaseAppError.FirebaseError [as constructor]
    var _this = _super.call(this, errorInfo.message) || this;
  File "/backend/node_modules/firebase-admin/lib/utils/error.js", line 84, col 23, in new FirebaseAppError
    return _super.call(this, {
  File "/backend/node_modules/firebase-admin/lib/utils/api-request.js", line 104, col 48, in IncomingMessage.<anonymous>
    var parsingError = new error_1.FirebaseAppError(error_1.AppErrorCodes.UNABLE_TO_PARSE_RESPONSE, "Failed to parse {snip}
  File "events.js", line 110, col 20, in emitNone
  File "events.js", line 207, col 7, in IncomingMessage.emit
  File "_stream_readable.js", line 1047, col 12, in endReadableNT
  File "internal/process/next_tick.js", line 102, col 11, in _combinedTickCallback
  File "internal/process/next_tick.js", line 198, col 9, in process._tickDomainCallback

How often does this happen? Do you have a deterministic way to reproduce it?

I have a feeling the above stacktrace has nothing to do with messaging (FCM). I would have expected to see some messaging related files or classes in the stacktrace. The error clearly originated at HttpRequestHandler which is used by the entire SDK to make HTTP calls. But if the invocation originated at messaging API, the error would have been converted into a FirebaseMessagingError at FirebaseMessagingRequestHandler.
To start with I'm going to improve the error messages thrown by the HttpRequestHandler. Then we will have more information to debug this type of issues.

Thank for your fast reply @hiranya911
I'm sorry that I'm tried to but not able to find a correct way to reproduce it. It happened for me 16 times over 2 months. My app did send around 12k requests over that time.
I think this error may cause by the networking problem, but if you can improve the error messages that would be great. So we can determine should retry the request or not.

Thanks

I have updated the error message. I'll try to get this improvement released in a few days.
You're probably right about this being a network issue. We'll know more once we have more details in the error message.

Hi @hiranya911 ,
Seem like the output error still not enough information to trace the problem :(
FCM sending message failed { Error: Failed to parse response data: "SyntaxError: Unexpected end of JSON input". Raw serverresponse: "". Status code: "200". Outgoing request: "POST fcm.googleapis.com/fcm/send"     at FirebaseAppError.FirebaseError [as constructor] (/node_modules/firebase-admin/lib/utils/error.js:39:28)     at new FirebaseAppError (/node_modules/firebase-admin/lib/utils/error.js:84:23)     at IncomingMessage.<anonymous> (/node_modules/firebase-admin/lib/utils/api-request.js:104:48)     at emitNone (events.js:110:20)     at IncomingMessage.emit (events.js:207:7)     at endReadableNT (_stream_readable.js:1059:12)     at _combinedTickCallback (internal/process/next_tick.js:138:11)     at process._tickDomainCallback (internal/process/next_tick.js:218:9)   errorInfo:     { code: 'app/unable-to-parse-response',      message: 'Failed to parse response data: "SyntaxError: Unexpected end of JSON input". Raw serverresponse: "". Status code: "200". Outgoing request: "POST fcm.googleapis.com/fcm/send"' } }

This is somewhat useful. I can check with the FCM team whether this is a server-side issue. I think this is some low-level issue though -- a loss of connection or a connection reset.

Starting from v5.3.0 Admin SDK retries HTTP requests on low-level errors. That should help with this too.

@taina0407 did you get a chance to try your implementation with Admin SDK v5.3.0 or higher? Does it help alleviate the problem?

@hiranya911 I already upgrade to v5.3.0 and it seem the problem stop happen for 1 month already, so I think it   resolved now. Thanks


No shared framework scheme, breaks Carthage

It looks like there isn't a shared framework scheme in the project, so Carthage doesn't know how to compile the framework.
*** Skipped building SwiftForms due to the error:
Dependency "SwiftForms" has no shared framework schemes for any of the platforms: iOS

Apologies - I can see that this is only present on master, and my Cartfile was only importing the last tag: 1.0.2. Works fine now!


Add support for java.sql.Timestamp

Hello Stewart :)
Let me explain my usage. We are using DAO to create objects by querying the DB. The Java Beans which model a record use java.sql.Timestamp to store the dates. We do not use java.util.Date nor Joda Time since the java date type corresponding to the DB date is Timestamp.
It would be a nice improvement if the matchers could also support java.sql.Timestamp. Internally, the matcher could convert/cast from Timestamp to Date and then use it.
This change should not add new Maven/external dependencies since java.sql.Timestamp is already included in the Java Runtime.

Hi Sorin,
Nice to see you're using a few of my libs :). In many cases I'd expect java.sql.timestamp to work with many of the matchers already because it's a subclass of java.util.Date. Do you have a code snippet or simple test which illustrates the use case you had in mind. (I've tried locally testing a couple of things e.g. sameInstant, sameDate, etc and they call compiled and passed OK).
Thanks
Stewart

Hello Stewart,
It seems to be working. I was getting another error, but not related to the matcher :) Now I am trying to figure out how the matcher works, since the java Generics accept only Date type. I can't find any mention or Java Generics usage like Matcher<? extends Date>. Also, the method public static Matcher before(final Date date) ``` specifies a Date type. So where is the cast to Timestamp being made ? :)
You can close the issue and sorry for the noise :)

Hi Sorin,
java.sql.Timestamp extends java.util.Date so passing in Timestamp still matches the signature of the matcher which is why it's working OK. I'll close the issue.
Thanks
Stewart


IC improvements for Heat Transfer

Proposed changes
Currently when running a transient Heat Transfer problem, an initial condition is required.
The process is a bit cumbersome as if users just want to initialise the temperature to say 300 K then they have to

create a InitialCondition object
give it the field "T" (which is redundant!)
pass it to HeatTransferProblem

This PR simplifies the process.
Now users can simply give a float, int or sympy Expression as the initial_condition argument.
If users want to give a initial condition from XDMF then the process is unchanged.
Moreover, this adds an error when transient heat transfer sims are run without giving an IC.
Documentation was also updated as the confusion was first reported here.
Types of changes
What types of changes does your code introduce to FESTIM?

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Code refactoring
[ ] Documentation Update (if none of the other choices apply)
[ ] New tests

Checklist

[x] Black formatted
[x] Unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation (if appropriate)

Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

@RemDelaporteMathurin
Looks good to me. I also got a bit tired of using InitialCondition with a constant initial temperature.
Just two unnecessary moments


Update Globals “nav”

Automatically generated by Netlify CMS

👷 Deploy Preview for shimmering-marigold-4f5b4a processing.

Name
Link

🔨 Latest commit
33693114314e9a1926a1aab382e74a9d10704b14

🔍 Latest deploy log
https://app.netlify.com/sites/shimmering-marigold-4f5b4a/deploys/64ff873482a4de0008b625c7


load_from_checkpoint: TypeErrror: init() missing 1 required positional argument

def load_checkpoint(path):
    model = resnet50().load_from_checkpoint(path)
    print(model)
    model.eval()
    logit = model._modules.get('fc')
    return model, logit

When i call this function, i got this error.
TypeError: init() missing 1 required positional argument: 'layers'
My model resnet50 is public code in torchvision.
What is wrong in my code?

In my model ResNet def init() i added this line self.save_hyperparameters().
It works :)

Thanks!


Add functionality to retrieve index of qubit in a register

What is the expected enhancement?
When trying to find the index of a qubit in a register one used to be able to use the index of a Qubit. This is deprecated, but there is no good alternative. A minimal example
from qiskit.circuit import QuantumRegister
register = QuantumRegister(2)
qubits=[register[0]]

# we want to find the indices of the qubits in the register
qubit_indices = [q.index for q in qubits] # deprecation warning
qubit_indices = [register._bits.index(q) for q in qubits] # uses private methods of the register

Suggested improvement: either add a find_qubit method to the register, or expose the register._bits through a public interface.

This should be resolved by https://github.com/Qiskit/qiskit-terra/pull/6621 . Please feel free to re-open if not.


Implement some changes through less instead of in the html

The changes in the header and footer from https://github.com/gigforks/gogs/commit/4321a92309843d96d83f2cd1441acd774416c0b5 should be implemented in the iyo.less to limit the changes in common files.

fixed in gigforks/gitea:
The templates and locales now are fully separated in custom repo:
Incubaid/gitea_custom

solved in gitea  1.0.0


snappymail: 2.18.1 -> 2.18.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/the-djmaze/snappymail/releases.
meta.description for snappymail is: "Simple, modern & fast web-based email client"
meta.homepage for snappymail is: "https://snappymail.eu"
meta.changelog for snappymail is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.18.2 with grep in /nix/store/1f87172m1la1cyqmznag4rsjf3z7bi6q-snappymail-2.18.2
found 2.18.2 in filename of file in /nix/store/1f87172m1la1cyqmznag4rsjf3z7bi6q-snappymail-2.18.2

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
snappymail

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1f87172m1la1cyqmznag4rsjf3z7bi6q-snappymail-2.18.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A snappymail https://github.com/r-ryantm/nixpkgs/archive/e29f582bc65d743a4db62623c2e7f38890b87cec.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1f87172m1la1cyqmznag4rsjf3z7bi6q-snappymail-2.18.2
ls -la /nix/store/1f87172m1la1cyqmznag4rsjf3z7bi6q-snappymail-2.18.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

snappymail

Maintainer pings
cc @Mic92 for testing.

Result of nixpkgs-review pr 192823 run on x86_64-linux 1

1 package built:

snappymail

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/the-djmaze/snappymail/releases.
meta.description for snappymail is: "Simple, modern & fast web-based email client"
meta.homepage for snappymail is: "https://snappymail.eu"
meta.changelog for snappymail is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.18.3 with grep in /nix/store/n4svllpgh81v044pylcgjikaiqxsw7p4-snappymail-2.18.3
found 2.18.3 in filename of file in /nix/store/n4svllpgh81v044pylcgjikaiqxsw7p4-snappymail-2.18.3

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
snappymail

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/n4svllpgh81v044pylcgjikaiqxsw7p4-snappymail-2.18.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A snappymail https://github.com/r-ryantm/nixpkgs/archive/5c2397dcceed05d316c779a2929c410f02ad3df9.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/n4svllpgh81v044pylcgjikaiqxsw7p4-snappymail-2.18.3
ls -la /nix/store/n4svllpgh81v044pylcgjikaiqxsw7p4-snappymail-2.18.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

snappymail

Maintainer pings
cc @Mic92 for testing.


Preprocessor support of "defined" and "!defined" macros

Clang can do these macros (and more macros! so many macros!), as of 3.0.3413-dev


Fix build failure due to non-defined system variable

Thanks! Not sure why this part is executed when running debug build task, but as we couldn't figure out now, let's just go forward with this :)


Check if .NET SDK is installed on plugin add

During installation check if .NET Sdk is installed

Check against package.json sdk version
Warn if mismatch

Supply link to current version

download link to the binaries dotnet.microsoft.com/download/dotnet/thank-you/sdk-[5.0.200]-[macos/windows/linux]-[cpu]-binaries my suggested we download the binaries and place them into .bin folder. The alternative is to create another package which we publish fist and then use typescript bash to wrap it.

My only concern with this approach would be keeping that version number up to date. It would not be too big of a burden to update the plugin to support latest version every now and again, but is something to consider. We should definitely use global version rather than install sdk locally if available and version matches though, .net sdk doesn't need to be cloned all over a user's pc.

Just a note in that one. Microsoft has a version json of the latest version and download link. Maybe that's a better route.

Ah, that could definitely work well. Do you have a link to that json file?

https://raw.githubusercontent.com/dotnet/core/main/release-notes/releases-index.json
https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/5.0/releases.json
We could have like version 5 then depending on if its ^ or ~ depends on what we actually provide. Another way is to then make a npm package compile on each update so a team can fix a version too

Thats very interesting, we will need to decide for versioning whether to version the plugin based off of Nx's major version or .NET's major version. It would certainly make it easier for users to update their package.json if for example we launched at 11.0.0 since Nx is at  11.x.y, but that might not be a huge help.
I wish there was a spot in that json that stated if it was a preview, release candidate or stable.

In my experience when using nx-plugins, it can be helpful when they are versioned in line with nx as this eliminates the need to figure out if a plugin version is compatible with the version of nx. That said having a table on the repo page with nx version to plugin version range easily fixes that + there is also the warning from npm for incorrect peer deps.
Also removing the control of the major version from the naming scheme does limit the plugin lib team to be able to publish breaking changes without an nx major version change.
Tying the plugin versioning to the  major version of the downstream tech would be very unusual looking at the other nx plugins. Ans also kind of feels backwards. It might also be that a one version of the plugin does support multiple versioning of the downstream tech (there are some nx plugins that do that today).
So in my opinion you should:

Either go for completely entirely separate sem versioning
Or tie it to major version of nx

Yeah, the versioning will be standalone since we have semantic-release setup now. Currently we are not doing anything for this issue, but at minimum doing something like:
dotnet --version and giving an error if dotnet is not found would be enough to close this out imho.


Test extractable

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@sanjay-jm: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: sanjay-jm
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Update values.yaml

Current configuration try to create pod fluentbit for each node of fargate and it’s not working

I installed this helm chart with default values on EKS cluster with fargate pods. Every fargate pods look in Kubernetes as node, so with default settings, I got one pending fluentbit pod for each fargate pod. Because it's daemonset

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @sergeylanzman is this still an issue or we can close this?

I'm closing this since we don't have any activity, if needed please reopen the PR 😄


Error in retrieving messages from kafka from WindowsServer2012R2

Description
using direct consumer and able to retrieve messages from kafka queue from Windows7
but the same code is not working with WindowsServer2012R2 with error "5/5 brokers are down"
Attached consumer logs from both machine
Consumer Code.txt
Windows7.txt
WindowsServer2012.txt
How to reproduce
Checklist
Please provide the following information:

[ ] Confluent.Kafka nuget version: 0.11.5
[ ] Apache Kafka version:
[ ] Client configuration: Attached code
[ ] Operating system: WindowsServer2012R2
[ ] Provide logs (with "debug" : "..." as necessary in configuration) Attached logs for security,protocol,consumer
[ ] Provide broker log excerpts
[ ] Critical issue

Have a similar problem on Win2012R2 servers while on Win7 it works.
I figured that on win2012 consumer group is hanged on wait-broker state and not doing coordinator request like on win7 in example:
CGRPQUERY [thrd:main]: kafkanode05.mysite.com:9092/bootstrap: Group "6585ac10-64b9-4edb-b449-68eca0f93d5b": querying for coordinator: intervaled in state wait-broker
Didn't find workaround yet.

As a workaround moved to previous version (0.11.4 Confluent.Kafka) and is working fine in Win2012R2 servers.

This could be related to the timing issues in #603

... which will be resolved in 1.0-beta, due to be released soon.

0.11.6-RC1 is now on nuget.org which should resolve this.

Closing this with Matt's comment above.