souffle: add darwin support

Description of changes
This PR fixes compilation error of souffle package for darwin. Currently is marked as broken.
Things done
After building the package in aarch64-darwin I was able to do a smoke test of the binary.
% ./result/bin/souffle --version
----------------------------------------------------------------------------
Version:
----------------------------------------------------------------------------
Copyright (c) 2016-22 The Souffle Developers.
Copyright (c) 2013-16 Oracle and/or its affiliates.
All rights reserved.
============================================================================

I also run the https://souffle-lang.github.io/simple example successfully
% ./result/bin/souffle -F. -D. example.dl

I am surprised that the changes introduced by missing-override.patch and hardeningDisable = lib.optionals stdenv.isDarwin [ "strictoverflow" ]; were not needed in linux already.
The missing override patch is already present in upstream (See https://github.com/souffle-lang/souffle/pull/2279) but is not released in 2.3. So I am applying it on linux also.
The other patches were done by consulting https://github.com/alicevision/geogram/issues/2#issuecomment-536835320 and https://github.com/NixOS/nixpkgs/issues/39687#issuecomment-598607106
Without threads.patch I was getting:
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
CMake Error at /nix/store/4lqag9hdrzfcpsrb79ny90jlwnn5gckz-cmake-3.24.3/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
  /nix/store/4lqag9hdrzfcpsrb79ny90jlwnn5gckz-cmake-3.24.3/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /nix/store/4lqag9hdrzfcpsrb79ny90jlwnn5gckz-cmake-3.24.3/share/cmake-3.24/Modules/FindThreads.cmake:230 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:251 (find_package)

-- Configuring incomplete, errors occurred!
See also "/tmp/nix-build-souffle-2.3.drv-0/source/build/CMakeFiles/CMakeOutput.log".
See also "/tmp/nix-build-souffle-2.3.drv-0/source/build/CMakeFiles/CMakeError.log".

Without disabling strictoverflow I was getting
make: *** [Makefile:136: all] Error 2
error: builder for '/nix/store/im01by48y5dlzj0asjljcy6b5qahx4xs-souffle-2.3.drv' failed with exit code 2;
       last 10 log lines:
       > clang-11: error: argument unused during compilation: '-fno-strict-overflow' [-Werror,-Wunused-command-line-argument]
       > clang-11: error: argument unused during compilation: '-fno-strict-overflow' [-Werror,-Wunused-command-line-argument]
       > make[2]: *** [src/CMakeFiles/libsouffle.dir/build.make:199: src/CMakeFiles/libsouffle.dir/ast/BooleanConstraint.cpp.o] Error 1
       > make[2]: *** [src/CMakeFiles/libsouffle.dir/build.make:171: src/CMakeFiles/libsouffle.dir/ast/Attribute.cpp.o] Error 1
       > make[2]: *** [src/CMakeFiles/libsouffle.dir/build.make:143: src/CMakeFiles/libsouffle.dir/ast/AliasType.cpp.o] Error 1
       > make[1]: *** [CMakeFiles/Makefile2:104: src/CMakeFiles/libsouffle.dir/all] Error 2
       > make[1]: *** Waiting for unfinished jobs....
       > [ 10%] Linking CXX executable souffleprof
       > [ 10%] Built target souffleprof
       > make: *** [Makefile:136: all] Error 2
       For full logs, run 'nix log /nix/store/im01by48y5dlzj0asjljcy6b5qahx4xs-souffle-2.3.drv'.

Without missing-override.patch I was getting
error: builder for '/nix/store/2f1d014pnlw9d4m204ay8gh5dnz0415g-souffle-2.3.drv' failed with exit code 2;
       last 10 log lines:
       > /tmp/nix-build-souffle-2.3.drv-0/source/src/main.cpp:306:10: error: 'endInput' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
       >     bool endInput() {
       >          ^
       > /tmp/nix-build-souffle-2.3.drv-0/source/src/main.cpp:213:18: note: overridden virtual function is here
       >     virtual bool endInput() = 0;
       >                  ^
       > 1 error generated.
       > make[2]: *** [src/CMakeFiles/souffle.dir/build.make:76: src/CMakeFiles/souffle.dir/main.cpp.o] Error 1
       > make[1]: *** [CMakeFiles/Makefile2:156: src/CMakeFiles/souffle.dir/all] Error 2
       > make: *** [Makefile:136: all] Error 2
       For full logs, run 'nix log /nix/store/2f1d014pnlw9d4m204ay8gh5dnz0415g-souffle-2.3.drv'.

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/787


Set up rultor

@rultor hello

@rultor hello

@kolayne Hi there! I understand a few simple commands: "merge", "deploy", etc. This page explains them briefly. Any questions or bug reports are welcome. Have fun :)


_get_default_schema_name implementation

In order for engine's default_schema_name property to work, _get_default_schema_name should be implemented

Corresponding PR is https://github.com/cloudflare/sqlalchemy-clickhouse/pull/59

Thanks for fixing!


Don't use English font family for Chinese UI

VSCode Version: 1.00
OS Version: Windows 10 Version 1511

Steps to Reproduce:

Change system language to Chinese (Simplified)
Install Visual Studio Code
Open 'File Panel', take a look at Chinese char.
They are blue , and not clear, very hard to read

We should use Microsoft YaHei for Chinese char, like toolbar and window title
ScreenSnap:

Bad ↑

Good ↑

+1

@ArianeLu @medifle this should be much better with our new insiders release.
You can give it a try from our insiders release today: http://code.visualstudio.com/Download#insiders
Closing in favor of https://github.com/Microsoft/vscode/issues/5260


Improve BillingMode replacement

Background:
We have a conditional billing mode on prod vs staging environments.
Conditions:
    IsProd:
        Fn::Equals:
            - ${self:provider.stage}
            - prod

and the billing mode:
            BillingMode: !If
                - IsProd
                - PROVISIONED
                - PAY_PER_REQUEST

This PR supports these kind of configurations

Thanks for your contribution! Released in v0.2.56.


Enterprise sub-section in APIs

ChangeLog:title
Signed-off-by: Peter Grzybowski<EMAIL_ADDRESS>(cherry picked from commit cb44225236647f4a7d3beb9a208e38c4bb9e2984)

I am going to close https://github.com/mendersoftware/mender-docs/pull/746 since it was against 2.1.x this one is cherry picked -- no changes. @michaelatmender please take a look as well. thanks @kacf for comments in https://github.com/mendersoftware/mender-docs/pull/746 (especially git-magic!)

@michaelatmender check Kristian's https://github.com/mendersoftware/mender-docs/pull/746#issuecomment-528739341 they can be helpful in review, the files where just copied.


Remove reference to absent code

Summary
There is a reference to Seq.toList that was perhaps part of code in a previous version of the doc. However, it now seems not necessary, anymore, since it does not refer to any current code in the doc. Removing that said reference will make the doc more clear.

Remove reference (Seq.toList) to absent code.


Kasada Anti-Bot

The Vercel AI Playground is using Kasada to defend itself from automated requests. Things will not function as expected.
See issue ading2210/vercel-llm-api#22

Is there Any Solution?


Update TextMate grammar to properly represent Razor content.

Right now we're re-using the built-in Razor TextMate grammar but it has its own flaws. One of which is the following end </p> tag is not colored correctly<EMAIL_ADDRESS>

Have done a lot of work to get the Razor grammar into a usable state for most scenarios. That being said there are several known things I still haven't done:

[ ] Email addresses

[ ] Razor templates

[ ] Nested HTML in non-transitioned C# constructs

[ ] Known TagHelpers

[ ] TagHelper C# attribute content

@NTaylorMullen

[ ] @code blocks (this specific screen comes from Mac OS, but I consider this xplat):

Where should someone look when considering contr., here or Omnisharp/VSCode?

@peterblazejewicz this is the correct repo 😄. I've gone ahead and added a lot of colorization support to the next release. Once O# releases (sometime this week) you should see improvements.

The only pieces of the grammar that are yet to be completed are intermingling HTML into deep C# structures. This is tracked by  microsoft/vscode-textmate#122, microsoft/vscode#87496
Now for why, when we hand off the grammar to the C# grammar it doesn't always give us the opportunity to enable HTML constructs. For top level constructs like @if (...) { we understand everything in the declaration portion, the keyword, condition and opening brace. This means we can allow for HTML inside of the body (the opening  brace) because we declare what the body allows; however, in the case of:
@code {
    public void RenerHTML()
    {
        // Content
    }
}

we don't understand method declarations (Razor hasn't had a need to understand them). This means when we let the C# grammar parse the body of @code it will understand method declarations in their entirety and never unweave to give us the opportunity to "allow" HTML.
The two issues I have filed on VSCode take advantage of a TextMate grammar concept called injection grammars. Basically I had the idea that we could tie into specific C# constructs with an injection grammar to give us an opportunity to allow HTML. Turns out they don't currently support injections into child grammars, aka when a top-level grammar (aspnetcorerazor) calls into a child grammar (source.cs).
If VSCode isn't willing to fix the issue we'll need to copy the C# grammar wholesale and edit each piece individually. Or if VS' TextMate grammar support doesn't support injection grammars either we'll have to do this as well.
Leaving this issue as blocked until we hear back from the VSCode and VS folks (i've started those conversations).

Hmm, VSCode's PHP grammar does similar things and they've been able to get this to work. When I have time i'll have to look into this more.


Support for elixir assets

I'm using gulp with Laravel Elixir to build and control version of assets on my project.
To support it on the CDN package, I used the same logic on helpers.php (Illuminate/Foundation/helpers.php).
Also edited the readme to reflect the new facade function and fixed a typo on test case namespace.

@filipegar very interesting, thanks for the efforts!


$ref via ajax ist not working

Hi,
I have an issue with the editor, if I try to externalize the enum select values via $ref
I have the following schema
{   "type": "object",   "properties": {    "property": { "enum":{"$ref":"test.json"} , "type": "string"}   } }
and a test.json file
["Value1","Value2"]
Select appears, but without any values.
Any help would be great.
Thx

Need more info to help you. How are you setting the base URI against which "test.json" should be resolved?

@sam-at-github I have solved this in the app by having a select box outside of the json-editor. However the issue/ "not understanding how to do" from my side is still open. I have included the editor in a jhipster app. There are REST api calls I can use for a lookup. I will try to configure a lookup and provide you more information. Thanks for getting back on this.

Given a schema:
{
  "type": "object",
  "properties": {
    "someprop": {
      "$ref": "/some/url"
    }
  }
}

/some/url should return:
{
  "title" : "title",
  "type" : "string",
  "enum" : [ "Value 1", "Value 2" ]
}

and the ajax init option should be true.


Unknown type bug issue

Hello. A couple days ago I was playing LC with my teammate for 3 hours. Somewhere around 1.5 hours when I have remade the lobby, my teammate couldn't wear or see any skin and the ship interior for him changed to default one. After several attempts of remaking the lobby he made skins work and the ship became usual for him but he lost reserved slots. After another reconnect everything returned back to when the bug appeared. I tried to make him host and I encountered the same bug as him.
Next day I was trying to find the buggy mod and this bug resolved only after disabling reserved slots entirely.
So the bug is - after 3 launches the ship becomes default nad skins break, sometimes even models become invisible. Occasionally slots may disappear and the bug disappears.
Reserved slots are up-to-date, game files verified etc.

Also someone suggested to reset game data entirely, that worked also only for 3 games, then it breaks.

That is very interesting. My mod doesn't even touch any of that.
My guess is that maybe my mod ran into an error, which stopped the execution of some of the vanilla code because the error wasn't caught and handled correctly.
Would you happen to know if there were any errors in the console/logs that the reserved mods might have caused?

Also, were you guys playing with the slots automatically unlocked, or did you enabling purchasing them?

Yes, I did open them in config

Idk why i didn't see that first message, so about errors. First thing when I tried to find out why - I tried to search for those errors. I said my friend to show me console, but the logs were normal, there were some errors, but they are kind of usual already. I also watched my logs when I was client, and nothing.

I will try to reproduce situation again, maybe I have skipped it.

At first I wasn't totally sure about that the issue in reserved slots, but yesterday evening I was playing LC for several hours and haven't met this bug anymore. I have reverted mod version to 2.0.7 I think. In 2.0.7 things are good.

So I have updated reserved mods again to latest and met this bug.
Ship is totally empty (shouldn't), bunk beds present (also shouldn't), interior is default, skins missing.
I have LogOutput file
LogOutput.log
But I don't see anything strange, only MoreEmotes seems to encounter some problems, but they are kind of regular for me already. And old version of slots works normal.

Hello @cmooref17 I have't received an answer for a week now... Looking for your answer.

Oh sorry. I must have missed your message where you included the log file. Let me take a look at this in a little bit and hopefully I can see what might be going on.

Also, did you mention if you were playing on v49 or v50? I see errors caused by more emotes because it might be referencing an old method? And it hasn't been updated to support v50, at least not fully. Maybe this isn't even causing issues, but I'll keep looking through the logs.

Okay, I'm guessing more emotes is fine. I don't think those errors would prevent any vanilla code, or code from other mods from running.
Have you tried this since the last ReservedItemSlotCore update by chance? I was made aware of a bug where if a player is holding a reserved item before a player joins, that player wouldn't receive any synced updates about unlockables, and potentially other updates, like maybe skins like you were referring to? I'm not sure about the skins part. This bug was fixed since then, but I guess I'm just wondering if that sounds like it might have been your issue. Thanks and let me know!

About latest reserved, not yet. I may try it later. I am playing on v50 stable

Sooo we tried to update reserved slots to the laaatest version you recommended and seems like it works. I guess bug was fixed..?

I will try to play it now on our modpack and I will let you know (we have checked mods on test modpack)

Okay thank you, I appreciate it!

I think it works fine, although the mod broke for single time, but after restart it got back to normal.

Hello @cmooref17 so after 2 days of playing when I pick up reserved items before the client connects, it won't show reserved slots now. Maybe the bug isn't fully fixed.

Sorry, let me look into this in a bit to see if I can figure out what exactly is going on.
And just double checking, did you say you enabled purchasing the reserved item slots in the config? Or do you not have this option set?

I have unlocked it thru config. My friend loses his reserved items kinda randomly, because sometimes I pick reserved items and he is fine, but sometimes I pick and it breaks.

Oh, gosh, I totally forgot the word "sometimes" when I was writing that message. My bad >_<
It's not permanent, it occurs a bit rarely and fixes with plain restart of the game.


failed to load configuration on docker-compose up

Description of Problem / Feature Request
Hi,
When I try to install Clair with docker-compose guidline but after all is done clair dont look like run correctly.
If I run docker-compose up without deamon I got this error :
docker-compose up
Starting clair_postgres ... done
clair_clair is up-to-date
Attaching to clair_postgres, clair_clair
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:14.946953","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:15.747215","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:17.104118","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:18.459353","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:19.605702","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:21.582408","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:25.127498","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:31.933963","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:30:45.142796","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:31:11.163885","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:32:02.741953","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:21.394930","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:21.997409","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:22.525595","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:23.258225","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:24.418696","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:26.357028","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:29.894359","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:36.659419","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:39:49.849858","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location"                                                                                :"main.go:190","Time":"2019-01-31 14:40:15.919065","error":"yaml: line 24: found                                                                                character that cannot start any token"}
clair_postgres | 2019-01-31 14:40:54.384 UTC [1] LOG:  listening on IPv4 address                                                                                "<IP_ADDRESS>", port 5432
clair_postgres | 2019-01-31 14:40:54.384 UTC [1] LOG:  listening on IPv6 address                                                                                "::", port 5432
clair_postgres | 2019-01-31 14:40:54.407 UTC [1] LOG:  listening on Unix socket                                                                                "/var/run/postgresql/.s.PGSQL.5432"
clair_postgres | 2019-01-31 14:40:54.456 UTC [20] LOG:  database system was inte                                                                                rrupted; last known up at 2019-01-31 14:30:18 UTC
clair_postgres | 2019-01-31 14:40:54.483 UTC [20] LOG:  database system was not                                                                                properly shut down; automatic recovery in progress
clair_postgres | 2019-01-31 14:40:54.498 UTC [20] LOG:  redo starts at 0/1651D10
clair_postgres | 2019-01-31 14:40:54.499 UTC [20] LOG:  invalid record length at                                                                                0/1651D48: wanted 24, got 0
clair_postgres | 2019-01-31 14:40:54.500 UTC [20] LOG:  redo done at 0/1651D10
clair_postgres | 2019-01-31 14:40:54.593 UTC [1] LOG:  database system is ready                                                                                to accept connections
clair_clair exited with code 1
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:14.946953","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:15.747215","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:17.104118","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:18.459353","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:19.605702","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:21.582408","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:25.127498","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:31.933963","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:30:45.142796","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:31:11.163885","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:32:02.741953","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:21.394930","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:21.997409","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:22.525595","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:23.258225","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:24.418696","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:26.357028","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:29.894359","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:36.659419","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:39:49.849858","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:40:15.919065","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:41:07.915504","error":"yaml: line 24: found character that cannot start any token"}
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:42:08.353516","error":"yaml: line 24: found character that cannot start any token"}
...
Expected Outcome
Dont know, done maybe ?
Actual Outcome
clair_clair | {"Event":"failed to load configuration","Level":"fatal","Location":"main.go:190","Time":"2019-01-31 14:42:08.353516","error":"yaml: line 24: found character that cannot start any token"}
Environment

Clair version/image: latest
Clair client name/version:  clair-git
Host OS: Debian
Kernel (e.g. uname -a): 8.x
Kubernetes version (use kubectl version): dont have
Helm version (use helm version): dont know what is it
Network/Firewall setup: local network

TY for support

What is the content of your config.yaml ? And have you tested out clair instead of clair-git ?

Hi @mikkeschiren  and thanks for try to help me.
Yes , I had try to "docker-compose up" on "clair" repository and I got the same issue.
See below my "config.yaml" :
nano config.yaml
Copyright 2015 clair authors

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
The values specified here are the default values that Clair uses if no configuration file is specified or if the keys are not defined.
clair:
database:
# Database driver
type: pgsql
options:
# PostgreSQL Connection string
# https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-CONNSTRING
# source: host=localhost port=5432 user=postgres sslmode=disable statement_timeout=60000
source: postgresql://postgres:password@postgres:5432?sslmode=disable
  # Number of elements kept in the cache
  # Values unlikely to change (e.g. namespaces) are cached in order to save prevent needless roundtrips to the database.
  cachesize: 16384

  # 32-bit URL-safe base64 key used to encrypt pagination tokens
  # If one is not provided, it will be generated.
  # Multiple clair instances in the same cluster need the same value.
  paginationkey:

api:
# v3 grpc/RESTful API server address
addr: "<IP_ADDRESS>:6060"
# Health server address
# This is an unencrypted endpoint useful for load balancers to check to healthiness of the clair server.
healthaddr: "<IP_ADDRESS>:6061"

# Deadline before an API request will respond with a 503
timeout: 900s

# Optional PKI configuration
# If you want to easily generate client certificates and CAs, try the following projects:
# https://github.com/coreos/etcd-ca
# https://github.com/cloudflare/cfssl
servername:
cafile:
keyfile:
certfile:

updater:
# Frequency the database will be updated with vulnerabilities from the default data sources
# The value 0 disables the updater entirely.
interval: 2h
enabledupdaters:
- debian
- ubuntu
- rhel
- oracle
- alpine
- suse
notifier:
# Number of attempts before the notification is marked as failed to be sent
attempts: 3
# Duration before a failed notification is retried
renotifyinterval: 2h

http:
  # Optional endpoint that will receive notifications via POST requests
  endpoint:

  # Optional PKI configuration
  # If you want to easily generate client certificates and CAs, try the following projects:
  # https://github.com/cloudflare/cfssl
  # https://github.com/coreos/etcd-ca
  servername:
  cafile:
  keyfile:
  certfile:

  # Optional HTTP Proxy: must be a valid URL (including the scheme).
  proxy:

TY

I think this line:
source: postgresql://postgres:password@postgres:5432?sslmode=disable

Should be something like:
source: host=postgres port=5432 password=password user=postgres sslmode=disable statement_timeout=60000

Sorry but source: postgresql://postgres:password@postgres:5432?sslmode=disable is for my connection with my postgres container and I dont have any problem of connection between clair and postgres.
If I change to host=postgres port=5432 password=password user=postgres sslmode=disable statement_timeout=60000 I got a new error "could not connect database".

Hi,
this is my first comment on github. Yay.
I think you should add your database-name after the port like:
postgresql://postgres:password@postgres:5432/$DB-NAME?sslmode=disable
this works on my site.

Hi @sfo-md
Ty for your help, it's work now :+1:  . First comment, first help, first win :)

Please close when it's solved.
Thanks.


force AST Injected properties check with staticCheckerVisitor

I will merge it with slight modifications.

thx

Fixed. http://jira.codehaus.org/browse/GROOVY-5333


"make build" fails

"make build" fails with error message:
/bin/sh: 9: Syntax error: "(" unexpected
Makefile:65: recipe for target 'blog/index.html' failed

It would have been polite to mention which version of make and which shell are required.
I have GNU make 4.1 and zsh 5.4.2.

It's kinda not the makefile's fault.
The build is breaking due to 2 rouge files.

src/Classic-bechamel-sauce
src/schinkenfleckerl-gratinated

these 2 files should have an .md extenstion and lowercased. which is clearly an oversight on the maintainer.
for the time being, remove theses files and commit.
Since the makefile grabs the list of recipes using git:
ARTICLES = $(shell git ls-tree HEAD --name-only -- $(BLOG_SRC)/ 2>/dev/null)

I suspected the shell issue because when I replaced all "$(shell" with "$(bash" in the Makefile everything works fine.

What's the program that's used for the "markdown" command?

What's the program that's used for the "markdown" command?

discount

it doesn't build with css. How do I fix?

Move css manually from data to blog.
make deploy from github actions does that automatically

ok

There's no link tag in the index.html. make deploy just does rsync.

This comment is not directly related to the above conversation, but instead the overarching subject. I just wanted to note that the Makefile target build will not work on OSX as of c3b8ff6. This is because OSX uses BSD sed instead of GNU sed (to resolve, one option is to install gnu-sed via homebrew). Given the purpose of this project, I don't think this incompatibility requires any attention, I just wanted to note it for others who may come looking in the future.


Use tempdir for test file cleanup

We should use something like https://docs.rs/tempdir/latest/tempdir/ to cleanup files written by tests (like reports)

nevermind, we already do this


GPII-4349: Update the GKE stable version

https://issues.gpii.net/browse/GPII-4349

This is good, but won't work till all the regions in use are on 1.14. Atm. us-central1 is still 1.13.
I have created intermediate PR - https://github.com/gpii-ops/gpii-infra/pull/591, and once 1.14 is rolled out across all zones we can merge this one.

$ gcloud container get-server-config --zone us-central1 | grep defaultCluster
Fetching server config for us-central1
defaultClusterVersion: 1.14.10-gke.17
$ gcloud container get-server-config --zone us-east1 | grep defaultCluster
Fetching server config for us-east1
defaultClusterVersion: 1.14.10-gke.17

LGTM


Owls93995 fix a race condition when DomainNamespaceSelectionStrategy is changed from List to LabelSelector

If the DomainNamespaceSelectionStrategy is LabelSelector, the operator relies on specifying the LabelSelector on the listNamespaceAsync call to filter the namespaces. When the strategy is changed from List to LabelSelector when the operator is running, listNamespaceAsync call may return the full list of namespaces instead of the namespaces that match the label selector, because the strategy is still List when the call is made. The changes in this PR modifies the isDomainNamespace method, which is used to filter the namespaces that are returned from the listNamespaceAsync call; instead of always returning true, it now actually evaluates the selector again in the LabelSelector case.
In order to add a unit test for the race condition, the KubernetesTestSupport class is enhanced to have an option to ignore a specified label selector when listing a type of resources.
This PR also fixes a NPE that I noticed during testing/debugging in DomainProcessorImpl (in the apply method of DomainPresenceInfoStep).
Integration test results (no unknown failures):
Main branch:
https://build.weblogick8s.org:8443/job/weblogic-kubernetes-operator-kind-new/8066/
https://build.weblogick8s.org:8443/job/weblogic-kubernetes-operator-kind-new/8080/
This branch:
https://build.weblogick8s.org:8443/job/weblogic-kubernetes-operator-kind-new/8067/
https://build.weblogick8s.org:8443/job/weblogic-kubernetes-operator-kind-new/8081/

I believe that the current approach is flawed, and requires too many changes, plus is not guaranteed to work in all cases.
The basic problem starts with the reality that our list namespace call is asynchronous, meaning that the strategy used to create the call might not match the strategy when we process the response. This has been identified in a specific case: changing from List to LabelSelector, as the latter does no post-processing, assuming that the filtering is being done by Kubernetes. It should also, then, logically be a problem in other combinations. For example, changing from LabelSelector to any other strategy means that the namespaces we start handling will exclude those without the label, even though we have explicitly said that we want to see them all. In general, any attempt to compensate for the mismatch runs into a problem of this kind. I therefore suggest that we have two simpler approaches, depending on how we want the operator to react. Both require creating the list response step with the current strategy

We could simply use the specified strategy for all strategy-dependent computations, thus ensuring that the request and processing are consistent. This would mean that the user’s change of strategies would take effect with the next list operation, not the in-flight one.

We could declare a mismatch to be an error, and restart the request. This would cause the change to take effect even with an in-flight request. The difficulty is whether we have a way to restart a multi-step list (used when there are a large number of namespaces), when the change happens partway through. If there is not, I would recommend against this approach.

I believe that the current approach is flawed, and requires too many changes, plus is not guaranteed to work in all cases.

The PR contains fixes for other existing and unrelated issues that I noticed during testing, such as NPE. The only change for this is to filter the namespaces that the operator get from the listNamesapces call, which matches the handling of all other strategies.

The basic problem starts with the reality that our list namespace call is asynchronous, meaning that the strategy used to create the call might not match the strategy when we process the response. This has been identified in a specific case: changing from List to LabelSelector, as the latter does no post-processing, assuming that the filtering is being done by Kubernetes. It should also, then, logically be a problem in other combinations. For example, changing from LabelSelector to any other strategy means that the namespaces we start handling will exclude those without the label, even though we have explicitly said that we want to see them all. In general, any attempt to compensate for the mismatch runs into a problem of this kind. I therefore suggest that we have two simpler approaches, depending on how we want the operator to react. Both require creating the list response step with the current strategy
1. We could simply use the specified strategy for all strategy-dependent computations, thus ensuring that the request and processing are consistent. This would mean that the user’s change of strategies would take effect with the next list operation, not the in-flight one.

This is error-prune because the operator uses the current selection strategy in many other places.  If the operator continues with the in-flight one here, we need to make sure all other places use the in-flight strategy as well, which is hard to do and error-prune.

2. We could declare a mismatch to be an error, and restart the request. This would cause the change to take effect even with an in-flight request. The difficulty is whether we have a way to restart a multi-step list (used when there are a large number of namespaces), when the change happens partway through. If there is not, I would recommend against this approach.

This is error-prune because the operator uses the current selection strategy in many other places. If the operator continues with the in-flight one here, we need to make sure all other places use the in-flight strategy as well, which is hard to do and error-prune.

In what other cases do you think a problem will occur? It's a problem in the list case because the request and post-processing need to use the same strategy. In most cases, it should not be an issue, as far as I can tell. And if it is indeed a problem, how do the changes here address it?

Having thought more about the problem, I think we should not have used the label selector in the list call for LabelSelector case. We should always list all namespaces (without a selector), and filter the returned list with the selector. All other strategies are handled this way.


Measure and document inference latency overhead

The goal is to understand the system overhead in resource usage and latency for inference.

Addressed in MMS 1.0


PWA apps don't appear to work with Workspaces

Microsoft PowerToys version
0.84.
Installation method
PowerToys auto-update
Running as admin
No
Area(s) with issue?
Workspaces
Steps to reproduce
Install a PWA app (e.g., Outlook web app, Loop, To-Do) and try to setup a workspace using that app.
✔ Expected Behavior
Launching the workspace would launch the PWA app (as the app, not as a normal Edge window)
❌ Actual Behavior
A new instance of Edge is opened that brings me to a blank tab that doesn't load any web page.
Other Software
No response

try this
https://gofile.io/d/yMHabA
select the desired compiler in the installer

maybe same bug https://github.com/microsoft/PowerToys/issues/34558

/dup #34572


⚠ Bofrost.at has degraded performance

In 24abf3d, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 924 ms

Resolved: Bofrost.at performance has improved in d74c31b after 44 minutes.


Quick hyperlink reference for ENUM data type

Knowing ENUM data type of different database (MySQL and Postgres) helps the users to understand what would be the replaceable data type in cockroach DB

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/1d1dd782cf529a99b0bbdfb5571c59243b62477a/
Edited pages:

v19.1/migration-overview.md


Added MusicUI

Write a short description about your art piece, such as what your artwork represents and your experience drawing it!
This is a simple UI for a music app. The bars on the top are supposed to be a visualiser and the height of them randomly changes. The progress indicator is also placed at a random point. The experience of using the blot editor was overall enjoyable. It took me a while to understand how the polylines work, although being able to drag my mouse over the numbers to change them definitely helped.

[x] I have read the steps to getting a blot
[x] I have read all the submission requirements and follow them
[x] I am submitting art that...

[x] is algorithmically generated (will meaningfully change each time the program is run)
[x] is your own work that is not copied from somewhere else
[x] is drawable through the editor(does not use outside tools)
[x] doesn't call Math.random() (See the documentation on randomness)
[x] is drawable on Blot itself (doesn't have lines overlap more than 5 times)

[x] Doesn't overlap lines more than 5 times
[x] Fits in the working area of 125x125mm
[x] Doesn't rely on colour to look good

If you used based your art on something else, used a tutorial, or remixed it from something else, please link it here:
Lastly, link a picture of your art piece here:

Hello! Sorry it's been so long. The main reviewer has been swamped lately, so I wanted to give you a few hints so you have the best chance of getting a blot.
I really like where you're going with this! It looks really cool. To get a blot, though, you'll need to make it a bit more complex. Generally, people spend ~15-20 hours on a project for it to be "blot-worthy", and I spent closer to 25-30.
Some suggestions I have are:

Could you add more buttons to the UI? Like skip buttons, etc.
Could you add a little image and name preview above the current UI with a randomly generated "currently playing song"? That would be a great way to add a bunch of complexity to your project!
It would be cool if you could use a for loop to generate the bars so that you could control how many bars there are

I'm really excited to see where this goes!

I'm planning on working on this over the next few days now that exams are over, so please don't close the pr. Thanks!

@EnterpriseGoose I made the changes you recommended, what do you think? Is there anything else I should change?


formatter error

Setup
Versions

Rust: 1.32.0
Diesel: 1.4.1
Database: Postgres 11
Operating System Linux

Feature Flags

diesel: chrono, postgres, r2d2, uuid

Problem Description
On connecting to a DB and embedded_migrations::run(&pool.get()?)?;-ing, I get the incredibly unhelpful error "formatter error," which seems to be from deep in std, if the migrations would introduce a constraint violation.
What are you trying to accomplish?
Apply some migrations to prod that worked in dev
What is the expected output?
[INFO] Started!
What is the actual output?
[ERROR] Failed with: formatter error
Are you seeing any additional errors?
Not from the app/diesel, but from diesel migration run, which shows the error.
Steps to reproduce
have a DB
ALTER TABLE some check constraints on in a migration
run the migration
Checklist

[x] I have already looked over the issue tracker for similar issues.
[x] This issue can be reproduced on Rust's stable channel. (Your issue will be
closed if this is not the case)

I'm having the exact same problem trying to run a SQLite migration.
CREATE TABLE `chals` (
    `id` INTEGER PRIMARY KEY AUTO_INCREMENT,
);

This is the full contents of the up.sql in question. Here's some parts of the code:
mod sqlite {
    #[derive(EmbedMigrations)]
    #[embed_migrations_options(migrations_path = "migrations/sqlite")]
    struct _Dummy;
}
...
sqlite::run_with_output(conn, out) // fails

nvm my syntax is wrong, trailing comma

This is a real error that occurs if anything whatsoever goes wrong during a migration run. For example, the following migration:
up.sql
SELECT 1 FROM does_not_exist;

Executed with:
embedded_migrations::run_with_output(&conn, &mut std::io::stdout()).expect("unable to migrate");

Will result in the following output:

Running migration<PHONE_NUMBER>3919
thread 'main' panicked at 'unable to migrate: MigrationError(IoError(Custom { kind: Other, error: StringError("formatter error") }))', src/libcore/result.rs:997:5
note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace.
Executing migration script

What SHOULD be shown is something along the lines of:

thread 'main' panicked at 'unable to migrate: QueryError(DatabaseError(__Unknown, "relation "test" already exists"))', src/libcore/result.rs:997:5

It turns out that the reason is very simple. Upon encountering an error, diesel attempts to display the filename of the failed migration:
https://github.com/diesel-rs/diesel/blob/03ec1d96ffa8a4f957ba6dc9bd5ab5b556a96d12/diesel_migrations/migrations_internals/src/lib.rs#L337-L344
Since the embedded migration's impl Migration is left without a file_path() implementation:
https://github.com/diesel-rs/diesel/blob/03ec1d96ffa8a4f957ba6dc9bd5ab5b556a96d12/diesel_migrations/migrations_macros/src/embed_migrations.rs#L37-L49
...  it returns the default None, which then triggers the formatting error here:
https://github.com/diesel-rs/diesel/blob/03ec1d96ffa8a4f957ba6dc9bd5ab5b556a96d12/diesel_migrations/migrations_internals/src/migration.rs#L49-L52
And since the writeln!() for the error message uses ?, the formatting error from above ends up replacing the original error entirely.

Your explanation of the issue makes sense, but I do not think that pretending an embedded migration has a file path is the right solution. Can we try fixing this by handling the None case in impl Display for MigrationFileName?


"You do not have permission to use this command!"

Trying to teleport as a member of the "Guest" group.
/world teleport museum - or - /pjw world teleport museum
and
/world teleport world - or - /pjw world teleport world
http://pastebin.com/cBsFCJrd
Oh the joys of establishing a new permissions system in any context among any of the technical fields.
I've got a good feeling the problem is between the seat and the steering wheel. Lemme know what I'm missing.

Was this edited by hand?

My mere mortal mittens did indeed edit it. I just went back through and tried all through the console/in-game. I'll test a few more things before I come back with more of the juicy details.

Closing as a Pex configuration issue, not PJW


Add acknowledgements messages

Currently some messages have no response. For flow control it is important that any non-acknowledgment message without a response receives some feedback message. Such a message should also be sent on connecting, workers already send READY but clients would have to say hello too, so that the broker can answer with message counters. Also we would need one hello per class of service.

We moved away from flow control, but the original problem of being vulnerable to lost message is still valid.


docs: add missing output

Codecov Report

Merging #3 (e8f8e34) into main (694cb77) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #3   +/-   ##
=======================================
  Coverage   91.07%   91.07%
=======================================
  Files           3        3
  Lines          56       56
=======================================
  Hits           51       51
  Misses          5        5

Help us with your feedback. Take ten seconds to tell us how you rate us.

Doesn't fix the issue. Rendering correctly local but not RTD build.

Need to investigate cause. Related issue #4


Update ISSUE_TEMPLATE.md - add FAQ link to the wiki

these FAQ will be updated frequently and don't quite fit in the official FAQ page on the website.
I am thinking to keep these to a bare minimum - 20-30 at max and delete questions that haven't been asked in the last 2-3 months.
I would like to try and see if it will help reduce the issues and if it becomes useless will just remove the link.

@brian-brazil do you want to give it a try to see if it will help?
Since you are most active in answering issues I will close if you don't think it will do any good.

I looked through the last 2 weeks of issues, and none are covered by the FAQ. It would seem that user support requests are so varied that maintaining such a list isn't very practical.

ok


avoid several deprecation notices with Symfony >= 5.3

Feedback is appreciated.

Coverage decreased (-1.0%) to 97.485% when pulling e37c1b90d1633951b2fcd7d431b14458fc645345 on avoid-deprecation-notices into 03edb599cab904091fdc074caacc877c12368406 on master.


replace the os.Stdout with stdout to adapt platform

We have got the stdin, stdout, stderr by term.StdStreams(), so the os.Stdin, os.Stdout and os.Stderr should be replaced.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:qq690388648/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

Looks like this is replaced by https://github.com/docker/docker/pull/18991
@qq690388648 could you please not open new PR's, but update the existing PR's in stead (using the instructions that @GordonTheTurtle gave here).
I'll close this PR as it's replaced by https://github.com/docker/docker/pull/18991


Supported installation options links not working

Where is the problem?
‘Supported installation options’ links/icons
What is your suggestion?
The links under ‘Supported installation options’ don’t seem to be working. Clicking on an icon doesn’t do anything. Tested in the latest versions of Safari and Chrome.
Code of Conduct and Community Expectations

[X] I agree to follow this project's Code of Conduct
[X] I agree to abide by the Community Expectations

It looks like the runtime installation docs are baked into the step-by-step installation process so this change was likely intentional.


[FIX] Remove _check_tfr_params from Transformer constructor

Reference issue
Fixes #10971.
What does this implement/fix?
The mne.decoding.time_frequency.TimeFrequency transformer called the mne.time_frequency.tfr._check_tfr_params function in the constructor. This function violates scikit-learn best practices on estimators, since it modifies some of the input parameters.
This PR removes the call to _check_tfr_params, since it is called later in the _compute_tfr method anyway. The _check_option call can remain, since it doesn't modify parameters.

It seems like some of the tests failed due to CI issues (#11023 and #11012). I have merged the latest main, so hopefully that should resolve the failing tests.

Failing test is unrelated and being tackled in #11034. Thanks for looking into this @Dod12 , I'll go ahead and merge!
If you're feeling motivated, you could add similar tests for all of our decoding classes, they probably need it...


Add meta schema describing valid recap schemas

Meta schema
Currently there is no programmatic description of what a valid recap spec is shaped like. The closest to that I could find is the text description at https://recap.build/specs/type/0.2.0/.
Other data description specifications like JSON Schema publish meta schemas.
Meta schema format
I think at least two formats should be used to describe recap spec documents: recap and JSON Schema.

recap because recap is a data description spec highly relevant to this project
JSON Schema because it is often supported by editors](https://code.visualstudio.com/docs/languages/json#_json-schemas-and-settings) to allow autocompletion and linting in the editor. This will also allow any developers that want to build tools that accept recap in non-python languages to validate the schemas without defining much custom validation logic.

First draft
I have already taken a crack at defining this in JSON Schema. With some feedback and direction I'd be happy to make a PR for this.
Click to expand JSON
```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://recap.build/specs/jsonschema/versiontodo/",
  "type": "array",
  "items": {
    "$ref": "#/$defs/RecapType"
  },
  "$defs": {
    "RecapType": {
      "oneOf": [
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapNull"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapBool"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapInt"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapFloat"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapString"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapBytes"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapList"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapMap"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapStruct"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapEnum"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        },
        {
          "allOf": [
            {
              "$ref": "#/$defs/RecapUnion"
            },
            {
              "$ref": "#/$defs/RecapCommonFields"
            }
          ]
        }
      ]
    },
    "RecapCommonFields": {
      "type": "object",
      "properties": {
        "alias": {
          "type": "string"
        },
        "doc": {
          "type": "string"
        }
      }
    },
    "RecapNull": {
      "type": "object",
      "required": [
        "type"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "null"
          ]
        }
      }
    },
    "RecapBool": {
      "type": "object",
      "required": [
        "type"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "bool"
          ]
        }
      }
    },
    "RecapInt": {
      "type": "object",
      "required": [
        "type",
        "bits"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "int"
          ]
        },
        "bits": {
          "type": "integer",
          "minimum": 1,
          "maximum": 64
        },
        "signed": {
          "type": "boolean"
        }
      }
    },
    "RecapFloat": {
      "type": "object",
      "required": [
        "type",
        "bits"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "float"
          ]
        },
        "bits": {
          "type": "integer",
          "minimum": 1,
          "maximum": 64
        }
      }
    },
    "RecapString": {
      "type": "object",
      "required": [
        "type"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "string"
          ]
        },
        "bytes": {
          "type": "integer",
          "minimum": 1
        },
        "variable": {
          "type": "boolean"
        }
      }
    },
    "RecapBytes": {
      "type": "object",
      "required": [
        "type"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "bytes"
          ]
        },
        "bytes": {
          "type": "integer",
          "minimum": 1
        },
        "variable": {
          "type": "boolean"
        }
      }
    },
    "RecapList": {
      "type": "object",
      "required": [
        "type",
        "values"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "list"
          ],
          "values": {
            "$ref": "#/$defs/RecapType"
          }
        },
        "length": {
          "type": "integer",
          "minimum": 1
        },
        "variable": {
          "type": "boolean",
          "default": true
        }
      }
    },
    "RecapMap": {
      "type": "object",
      "required": [
        "type",
        "keys",
        "values"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "map"
          ]
        },
        "keys": {
          "$ref": "#/$defs/RecapType"
        },
        "values": {
          "$ref": "#/$defs/RecapType"
        }
      }
    },
    "RecapStruct": {
      "type": "object",
      "required": [
        "type",
        "fields"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "struct"
          ]
        },
        "name": {
          "type": "string"
        },
        "fields": {
          "type": "array",
          "items": {
            "allOf": [
              {
                "$ref": "#/$defs/RecapType"
              },
              {
                "type": "object",
                "properties": {
                  "name": {
                    "type": "string"
                  },
                  "default": {
                    "type": "string"
                  }
                }
              }
            ]
          }
        }
      }
    },
    "RecapEnum": {
      "type": "object",
      "required": [
        "type",
        "symbols"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "enum"
          ]
        },
        "symbols": {
          "type": "array",
          "items": {
            "type": "string"
          }
        }
      }
    },
    "RecapUnion": {
      "type": "object",
      "required": [
        "type",
        "types"
      ],
      "properties": {
        "type": {
          "type": "string",
          "enum": [
            "union"
          ]
        },
        "types": {
          "type": "array",
          "items": {
            "$ref": "#/$defs/RecapType"
          }
        }
      }
    }
  }
}
```

Click to expand YAML
$schema: https://json-schema.org/draft/2020-12/schema
$id: https://recap.build/specs/jsonschema/versiontodo/
type: array
items:
  $ref: "#/$defs/RecapType"
$defs:
RecapType:
oneOf:
- allOf:
- $ref: "#/$defs/RecapNull"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapBool"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapInt"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapFloat"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapString"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapBytes"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapList"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapMap"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapStruct"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapEnum"
- $ref: "#/$defs/RecapCommonFields"
- allOf:
- $ref: "#/$defs/RecapUnion"
- $ref: "#/$defs/RecapCommonFields"
RecapCommonFields:
type: object
properties:
alias:
type: string
doc:
type: string
RecapNull:
type: object
required:
- type
properties:
type:
type: string
enum: ["null"]
RecapBool:
type: object
required:
- type
properties:
type:
type: string
enum: ["bool"]
RecapInt:
type: object
required:
- type
- bits
properties:
type:
type: string
enum: ["int"]
bits:
type: integer
minimum: 1
maximum: 64 # TODO double check
signed:
type: boolean
RecapFloat:
type: object
required:
- type
- bits
properties:
type:
type: string
enum: ["float"]
bits:
type: integer
minimum: 1
maximum: 64 # TODO double check
RecapString:
type: object
required:
- type
properties:
type:
type: string
enum: ["string"]
bytes:
type: integer
minimum: 1
variable:
type: boolean
RecapBytes:
type: object
required:
- type
properties:
type:
type: string
enum: ["bytes"]
bytes:
type: integer
minimum: 1
variable:
type: boolean
RecapList:
type: object
required:
- type
- values
properties:
type:
type: string
enum: ["list"]
values:
$ref: "#/$defs/RecapType"
length:
type: integer
minimum: 1
variable:
type: boolean
default: true
RecapMap:
type: object
required:
- type
- keys
- values
properties:
type:
type: string
enum: ["map"]
keys:
$ref: "#/$defs/RecapType"
values:
$ref: "#/$defs/RecapType"
RecapStruct:
type: object
required:
- type
- fields
properties:
type:
type: string
enum: ["struct"]
name:
type: string
fields:
type: array
items:
allOf:
- $ref: "#/$defs/RecapType"
- type: object
properties:
name:
type: string
default:
type: string
RecapEnum:
type: object
required:
- type
- symbols
properties:
type:
type: string
enum: ["enum"]
symbols:
type: array
items:
type: string
RecapUnion:
type: object
required:
- type
- types
properties:
type:
type: string
enum: ["union"]
types:
type: array
items:
$ref: "#/$defs/RecapType"

Validation
I think a good way to validate that the meta schema is defined correctly would be to create a handful of example recap specs that exhibit the full range of features, and then have a test suite that uses the meta schema to validate those examples. We could use python-jsonschema to evaluate the jsonschema meta schema against examples, and recap to evaluate the recap meta schema against examples.
Limitations
I don't think there's a way using JSON Schema to validate that alias references actually refer to another element, so this spec may accept a document that isn't actually valid due to an invalid pointer.
Joke
I'm So Meta Even This Acronym

I love this! @mjperrone let me take a look at this in a bit and get back to you with next steps.

K, read things over a bit. Few thoughts/comments/questions:

I'm not sure I follow what the "click to expand YAML" section is. Can you clarify that?

What I'm thinking is:

Put a 0.2.0.json in https://github.com/recap-build/recap-website/tree/main/specs/type (similar to what open lineage does in their spec dir).
Create a new folder in the recap project: tests/spec.
Write a bunch of test schemas in tests/spec and validate that they parse properly using python-jsonschema. We'll have to automatically fetch the JSON schema from the recap-website github repo when we run the tests, but that's fine.

Regarding alias reference validation, I don't think that's easily doable using the jsonschema validator. The schema should still validate, as you said, but the reference might point to an undefined alias. I propose that we leave that as it is for now. We can write a custom checker for aliases in the future, if we want; it's not too crazy (some converters already do this kind of logic). But for expediency and incremental builds, let's start small.

I would love it if you could submit a PR for this. Definitely welcome.

I'm not sure I follow what the "click to expand YAML" section is. Can you clarify that?

I initially defined the JSON Schema using YAML. I used yq to convert that to json. I posted both here in case you prefer reading one or the other. I initially messed up the github markdown formatting but just fixed that now.

I'm not sure I follow what the "click to expand YAML" section is. Can you clarify that?

I initially defined the JSON Schema using YAML. I used yq to convert that to json. I posted both here in case you prefer reading one or the other. I initially messed up the github markdown formatting but just fixed that now.

Ahh 😅 Got it.

I set up the test harness: https://github.com/recap-build/recap/pull/346
I didn't flesh out the valid examples yet. I wanted to set up the test harness so you can give feedback on that, and so we can brainstorm the example set here. My initial thoughts on examples we should add:

an example that uses each of the base types
examples for each base type with optional types excluded and also included
a test that we expect to fail with an invalid alias reference

I'm a little fuzzy on the semantics/use cases for the more advanced features like logical types and aliases, so I could use some thoughts on good examples for that.

This is great! I left a review. I addressed the logical types in the comments of the review.
Re: aliases, let's leave that as a follow-on GH issue. I think it requires some Python code to make it work properly. I'd rather keep this PR focused on the harness and smoke test types.


refactor(spectrumColorpickerDirective): replace $apply by $timeout

In order to avoid to trigger another digest while one is already in progress
PTAL @Xiphe

does NOT look good to me!
Please read this: http://stackoverflow.com/a/23102223/1468875
Recheck if the error you want to fix is caused by this project or the one you're using this in.
If this needs to be fixed here: use $evalAsync

$evalAsync did the trick
PTAL again @Xiphe

LGTM


fixing a small typo on the OutOfDisk condition

Faced some errors generating the rules for the k8s configmap, found an small typo on the conditional
curl -X POST http://ingress.mycluster/metrics/-/reload
failed to reload config: one or more errors occurred while applying the new configuration (-config.file=/etc/prometheus/config/prometheus.yaml)

After change this, rules are loaded correctly

Can you open this PR against the master branch, and re-generate the rule manifest using make generate in the contrib/kube-prometheus/ directory.

Sure, just to double check, to re-generate the rule manifest make generate should be executed in master or in release-0.12 branch ?

All of that from master branch.

This typo only affects  the branch release-0.12 , this is not an issue in master. That's why I created the PR against  release-0.12 and I can not make the change in master as requested.

I'm confused, as to why you want it to be in the release branch? We're not going to cut a new release for a change in the kube-prometheus manifests. The release branches are meant to version the Prometheus Operator code. The remaining code is versioned on best effort.

Sorry for my delay response,
So in that case feel free to close this PR,
I was using tectonic installer with prometheus-operator v0.12.0 and prometheus v1.7.1,
Generated manifest prometheus-k8s-rules.yaml  it's in a good state, but if you want to generate new rules, contrib/kube-prometheus/assets/prometheus/rules/node.rules
contains the typo I was trying to fix, and rules are not loaded at all.

In that case I recommend to just use more up to date releases. But thanks for all your efforts!


Usage with sentry

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.
[x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

electron-forge version: 6.0.0-beta.44
Please describe your issue:
Apologies as this is more a question than bug report, I've been trying to setup sentry with electron forge and am not having much success.
From the issues in the sentry-electron project it seems they do have issues with webpack, but none of the solutions people discuss there seem to work with electron-forge.
With using the default sentry electron instructions - bundled apps crash on startup.
When following the guidance in https://github.com/getsentry/sentry-electron/issues/92, bundled apps start up okay, however no crashes are sent to sentry.
Does someone have a working sentry setup they would be able to share? (I'd be happy to open up a docs pr with the information if so)

Finally got around to revisiting this, and other changes I had made to my webpack config since trying to get sentry setup have resulted in it now working.
In the renderer.config, under the resolve key I'd set mainFields to["module", "main"],.
in both the main and renderer configs I'd added "@sentry/electron": 'require("@sentry/electron")', under the externals key.
And I was initing  sentry on the main process using the as yet undocumented suggestion offered at https://github.com/getsentry/sentry-electron/issues/92#issuecomment-453534680.


Notification not received for huawei device that uses only hms

Notification is sent and received successfully by non-huawei devices as well as by huawei devices using both gms+hms. Problem is that newest huawei devices running only hms seem to not allow app to send remote notification (see attached screenshots). Also, hms only devices have transport protocol set to "Notificare", not "HMS". I am not sure if that is the problem. Notificare version used is 3.3.1

Hi @gtsak1 ,
You must include the  push-hms peer dependency for supporting HMS devices.
implementation "re.notifica:notificare-push:$notificare_version"
implementation "re.notifica:notificare-push-gms:$notificare_version"        // Enable support for Google Mobile Services.
implementation "re.notifica:notificare-push-hms:$notificare_version"

I've quickly tested it with our sample app and push messages are being received.
We intend to keep the GitHub issues as a channel for reporting bugs.
For support-related matters, please create a ticket via our helpdesk or send an email to<EMAIL_ADDRESS>That way we can provide more contextualised support.

We cannot reproduce this with our HMS-only devices.
Can you share some evidence of the problem? Application logs from the configuration phase until after you've enabled remote notifications, a sample app where the problem occurs.
For the logs, enable debug logging by adding the following to your AndroidManifest.xml application node:
<meta-data android:name="re.notifica.debug_logging_enabled" android:value="true" />

It seems there is certificate fingerprint error, although I have configured SHA-256 certificate fingerprint in developer Huawei appGallery Connect
E/Notificare: [ServiceManager] Failed to retrieve HMS token.
com.huawei.hms.common.ApiException: 6003: certificate fingerprint error

Unlike Firebase, Huawei requires you to configure all fingerprints — not just the release fingerprint.
I suggest checking your signing configurations (debug & release), configuring those in the Huawei portal and downloading their configuration file. From that error, we can be sure it's a configuration mismatch.
Regarding the warning, the SDK only prints the warning but does not restrict anything. We must, indeed, improve that warning since it's only checking for the FCM permission, which is not applicable in this case.

Problem solved by adding apps in the Huawei portal for every product flavor of the project and by adding debug and release SHA-256 certificate fingerprints for each app in the Huawei portal.


Speedup for multiple regions

This speeds up pipelines run by

Skip downloading cache layers from other regions if we successfully pull it
Pushing images to multiple regions in parallel

Can we get a review on this one please? We are waiting on this one for long time.
Tagging @72636c

@BEvgeniyS this is a good change thanks for making it.
We'll do a better job of maintining these repos. Sorry you all had to make forks to get the changes into a published version.


Workaround references list not updating

Not the ideal fix but this makes it so that ChatCollapsibleListContentPart does not have a live version of the references list passed to it. The current code results in the item never being re-rendered because hasSameContent would always return true, so the references list would not update
There are a bunch of layers above this that all say they are readonly arrays too. Being readonly is correct from the consumer side, but it looks like the array does get mutated behind the scenes which is often unexpected

As an alternative, we could make either ChatResponseModel.contentReferences or ChatResponseViewModel.contentReferences do the array copy. That seems to be the place where we return a readonly array that's actually backed by a mutable array
However that impacts more code so I wanted to try a more scoped fix for now

Oh yeah, have had this kind of problem before. This change is fine but I think I'd rather have ChatResponseModel.contentReferences return a copy, that makes sense to me.


Plugin Idea: Faction Show / Hide

Create a plugin to hide all portals / links / fields for a given faction. Useful for finding targets in  dense areas.
I have a prototype written.

Is there anything in this issue that hasn't been implemented yet?

enlightened/resistance layer choices have been available for some time


Manage sessions through the Source Data instance manager rather than the Subjects table

To allow the Subjects page to focus on subject data, we will move this capability to the Source Data instance manager.
While doing this, we should make sure that there is the ability to add and remove sessions from each subject.

@CodyCBakerPhD This is inconsistent with #482. Assuming we aren't pursuing this direction anymore?

I think they're kind of compatible - the main idea was still to have the session management separated from the subject table
Whether or not that is a table on the same page or a button in the manager form on the next page is the main difference; the table seems simpler

Yeah I agree. Even if we moved the table to a separate page, the general idea of isolating Session specification from other metadata specification is a smart move for one-directional data flow.
This Issue just seems overly attached to the method rather than that rationale, unlike #482

replaced by #482


joints_allowed_start_tolerance doesn't support joints with slash in their name

Description
Due to the use of NodeHandle::getParam(std::string, std::map<std::string, double>), TrajectoryExecutionManager::updateJointsAllowedStartTolerance() doesn't work if a joint has a slash in its name.
Your environment

ROS Distro: Noetic
OS Version: e.g. Ubuntu 20.04
Binary build 1.1.14-1focal.20240812.164411

Steps to reproduce
Fill move_group/trajectory_execution/joints_allowed_start_tolerance with values for a joint with a slash in its name, e.g.
move_group:
  trajectory_execution:
    joints_allowed_start_tolerance:
      ur5e/shoulder_pan_joint: 0.05

Expected behaviour
The TrajectoryExecutionManager should take in account the values in joints_allowed_start_tolerance
Actual behaviour
It doesn't

This is a fundamental constraint of ROS parameters: slashes are always interpreted as structure and cannot be part of the name. For this reason, you should not use slashes in names, which can occur as ROS parameters (like here joint names).
My suggestion is to change the joint names. For example, you could use: "ur5e:shoulder_pan_joint".
Closing, as won't fix.


Discussion: Where should our data conversion scripts live?

Our code for downloading and converting satellite data lives in the Satip repo.
Our code for downloading and converting other data sources (NWP, GSP PV, etc.) lives in this repo.
Are we happy with this situation?
Or should we have separate repos for downloading and preparing each data source?  Or maybe just for the "big" data sources (e.g. NWPs?  And GSP?).
Advantages of splitting out the downloading-and-converting scripts into separate repos:

Reduces number of dependencies required by nowcasting_dataset
Makes it a little easier for other people to re-use our downloading-and-converting code for other purposes

Disadvantages:

Managing multiple repos can get time-consuming!
Some of the data sources literally just require a single conversion script (e.g. converting the PassivSystems PV data).  Do we really want a whole repo for a single conversion script?

What do you guys think, @jacobbieker and @peterdudfield?

Possibly a repo for all the download scripts, but I wouldn't really separate them all out into separate repos, as yeah, it gets a bit confusing keeping everything in sync. Would it reduce a lot of dependencies? I would think a decent amount of the dependencies would still need be used for the nowcasting-dataset

It we look ahead to the live system, we a service for data source, in that case I think it will be good to have separate repos. There will be docker files, and separate tests, and infrastructure code, that are handled much easier in smaller chunks. Also versioning is a bit easier then., i.e we can update one data source at a time.
I would be tempted to leave them here for the moment, until we start building out these data_source 'consumers', and then that'll be a good time to separate things?

It we look ahead to the live system, we a service for data source, in that case I think it will be good to have separate repos. There will be docker files, and separate tests, and infrastructure code, that are handled much easier in smaller chunks. Also versioning is a bit easier then., i.e we can update one data source at a time.
I would be tempted to leave them here for the moment, until we start building out these data_source 'consumers', and then that'll be a good time to separate things?

Yeah, that's a good point. So maybe leave this for later then? Also, if each one is then bundled with infra code, docker files, etc. it makes more sense as separate repos rather than currently where it would just be single files for a lot of them.

It we look ahead to the live system, we a service for data source, in that case I think it will be good to have separate repos.

Ooh, that's an excellent point!
Cool.  As you've both suggested, I agree that we should leave our data conversion scripts where they are for the remainder of 2021.
I've moved this issue into the "WP2" project.

Good use of https://github.com/orgs/openclimatefix/projects/6


Codegen handler return

Support Handler and Handler method return types, for instance:
Handler<String> someHandler() {
  return s -> {};
}

or
Handler<AsyncResult<String>> someHandler() {
  return ar -> {};
}

Used by https://github.com/vert-x3/issues/issues/84

done


Matching Analysis

Uploading Final_Fuzzy.csv…

Thank you for your effort. Just added contribution instructions. Could you adapt your pull request according to that
https://github.com/moest-np/incubator/blob/main/2024-05_school_mapping/CONTRIBUTING.md


[feat][broker] PIP-264: Add OpenTelemetry managed ledger metrics

PIP-264
Motivation
Adds Managed Ledger metrics, as currently described here, to the OpenTelemetry pipeline.
Modifications

Adds the metrics described in https://github.com/apache/pulsar-site/pull/930 to the collector runs.

Verifying this change

[x] Make sure that the change passes the CI checks.

This change modified tests and can be verified as follows:

Updated test ManagedLedgerMetricsTest#testManagedLedgerMetrics to cover the OpenTelemetry metrics

Does this pull request potentially affect one of the following parts:

[ ] Dependencies (add or upgrade a dependency)
[ ] The public API
[ ] The schema
[ ] The default values of configurations
[ ] The threading model
[ ] The binary protocol
[ ] The REST endpoints
[ ] The admin CLI options
[x] The metrics: As described in https://github.com/apache/pulsar-site/pull/930
[ ] Anything that affects deployment

Documentation

[ ] doc
[x] doc-required https://github.com/apache/pulsar-site/pull/930
[ ] doc-not-needed
[ ] doc-complete

Matching PR in forked repository
PR in forked repository: https://github.com/dragosvictor/pulsar/pull/35

Codecov Report
Attention: Patch coverage is 98.03922% with 2 lines in your changes missing coverage. Please review.

Project coverage is 73.45%. Comparing base (bbc6224) to head (97db472).
Report is 427 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #22987      +/-   ##
============================================
- Coverage     73.57%   73.45%   -0.12%
- Complexity    32624    33287     +663
============================================
  Files          1877     1909      +32
  Lines        139502   143054    +3552
  Branches      15299    15578     +279
============================================
+ Hits         102638   105080    +2442
- Misses        28908    29943    +1035
- Partials       7956     8031      +75

Flag
Coverage Δ

inttests
27.74% <98.03%> (+3.16%)
:arrow_up:

systests
24.75% <47.05%> (+0.42%)
:arrow_up:

unittests
72.47% <98.03%> (-0.37%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files
Coverage Δ

...he/bookkeeper/mledger/ManagedLedgerAttributes.java
100.00% <100.00%> (ø)

...kkeeper/mledger/impl/ManagedLedgerFactoryImpl.java
82.03% <100.00%> (+0.64%)
:arrow_up:

...ookkeeper/mledger/impl/ManagedLedgerMBeanImpl.java
90.34% <100.00%> (+0.63%)
:arrow_up:

.../mledger/impl/OpenTelemetryManagedLedgerStats.java
100.00% <100.00%> (ø)

.../pulsar/opentelemetry/OpenTelemetryAttributes.java
100.00% <100.00%> (ø)

...a/org/apache/bookkeeper/mledger/ManagedLedger.java
0.00% <0.00%> (ø)

...che/bookkeeper/mledger/impl/ManagedLedgerImpl.java
81.33% <80.00%> (+0.67%)
:arrow_up:

... and 476 files with indirect coverage changes


HttpClient

Switch to HttpClient when angular-jwt will be ready: https://github.com/auth0/angular2-jwt/tree/v1.0

Removed angular-jwt. Switched to angular-oauth2-oidc & HttpClient.


fix(circus): make sure to install globals before emitting setup event

Summary
Fix for https://github.com/facebook/jest/pull/10484#issuecomment-703761828
In addition to restoring time when globals are added, I've also added a property to the setup event that comes with the globals. That way consumers don't have to care about this.globals.*, which would also be unset if the end user use injectGlobals: false.
/cc @noomorph

Test plan
Verified locally that globals are set during setup

Looks good, I'll give it a try on the Detox suite.

Btw, the idea of emitting globalsObject looks fantastic and fun to use. :+1: kudos!

@noomorph would love for you to confirm

it fixes the regression without code changes on detox's side
you're able to use runtimeGlobals over this.global.*

@SimenB, yes, I've been able to confirm both your statements:

your changes make the existing codebase work as usual.
it is fully possible to combine injectGlobals: false and Object.assign(this.global, event.runtimeGlobals); in TestEnvironment class' setup event handler, and achieve the very same result.

Thanks much again! Looking forward to the release!

Perfect, thank you!

@noomorph out in https://github.com/facebook/jest/releases/tag/v26.5.2

@SimenB, excellent. We'll provide a user-friendly warning for Detox users if anyone ever encounters 26.5.0-26.5.1 versions.

See: https://github.com/wix/Detox/pull/2391


Misdetecting license/path for core Ruby modules

Ruby 2.3.1 includes a JSON module. If not explicitly specified (i.e., when installed as a dependency of another gem and not explicitly listed in a project's Gemfile), Bundler detects the core JSON module as v1.8.3, and uses it to satisfy other gem's 'json', '~> 1' requirement. It also adds "json (1.8.3)" to Gemfile.lock.
When LicenseFinder finds "json (1.8.3)" in Gemfile.lock, it searches for the gem in lib/ruby/gems/2.3.0/gems/json-1.8.3, and ignores the core module in lib/ruby/2.3.0/json. LicenseFinder is unable to find the gem, and incorrectly returns a license of "unknown", instead of "ruby".
This happens because there is a gem that shares a name with a core module, and the core module can be used to satisfy a dependency on the gem. It's possible this is a bundler issue (see "This may be because Bundler is confused" below), and it can be worked around by whitelisting json v1.8.3. But it seemed worth reporting, in case it's worth adding fallback behavior for when a Ruby dependency is not found (i.e., the directory does not exist) but does exist as a core module.
Steps to Recreate
Ensure a clean testing environment (on OS X 10.11.6):
% rbenv uninstall 2.3.1
rbenv: remove ~/.rbenv/versions/2.3.1? y
% rbenv install 2.3.1
Downloading ruby-2.3.1.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.bz2
Installing ruby-2.3.1...
Installed ruby-2.3.1 to ~/.rbenv/versions/2.3.1
% gem install bundler -v 1.12.5
Fetching: bundler-1.12.5.gem (100%)
Successfully installed bundler-1.12.5
Parsing documentation for bundler-1.12.5
Installing ri documentation for bundler-1.12.5
Done installing documentation for bundler after 5 seconds
1 gem installed

Specify the Ruby version:
% rbenv local 2.3.1

Create a Gemfile with two dependencies, license_finder and a gem that requires json 1.8.3 (httparty 0.13.0 in this case):
source 'https://rubygems.org'

gem 'license_finder', '~> 2.0'
gem 'httparty', '~> 0.13.0'

Bundle (note "Using json 1.8.3"):
% bundle
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Using json 1.8.3
Installing multi_xml 0.5.5
Using bundler 1.12.5
Installing rubyzip 1.2.0
Installing thor 0.19.1
Installing xml-simple 1.1.5
Installing httparty 0.13.7
Installing license_finder 2.1.2
Bundle complete! 2 Gemfile dependencies, 8 gems now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
Post-install message from httparty:
When you HTTParty, you must party hard!

Run LicenseFinder (note "json, 1.8.3, unknown"):
% license_finder
..............................................................
Dependencies that need approval:
bundler, 1.12.5, MIT
httparty, 0.13.7, MIT
json, 1.8.3, unknown
license_finder, 2.1.2, MIT
multi_xml, 0.5.5, MIT
rubyzip, 1.2.0, "Simplified BSD"
thor, 0.19.1, MIT
xml-simple, 1.1.5, ruby

If you look at the LicenseFinder object, it shows the wrong path for the JSON module:
> require 'license_finder'
=> true
> lf = LicenseFinder::Core.new
=> #<LicenseFinder::Core:0x007ffc0b1ec440 @logger=#<LicenseFinder::Logger::Progress:0x007ffc0b1ec350>, @config=#<LicenseFinder::Configuration:0x007ffc0b1e6ec8 @primary_config={}, @saved_config={}>>
> lf.unapproved.find { |i| i.name == 'json' }
=> #<LicenseFinder::BundlerPackage:0x007ffc0b1bdf50 @logger=#<LicenseFinder::Logger::Progress:0x007ffc0b1ec350>, @name="json", @version="1.8.3", @authors="", @summary="This json is bundled with Ruby", @description="", @homepage="", @children=[], @parents=#<Set: {"httparty"}>, @groups=[], @whitelisted=false, @blacklisted=false, @manual_approval=nil, @license_names_from_spec=[], @install_path="~/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/json-1.8.3", @missing=false, @decided_licenses=#<Set: {}>, @licenses=#<Set: {#<LicenseFinder::License:0x007ffc0b1074a8 @short_name="unknown", @pretty_name="unknown", @other_names=[], @url=nil, @matcher=#<LicenseFinder::License::NoneMatcher:0x007ffc0b1074f8>>}>>

This may be because Bundler is confused:
% bundle show json
The gem json has been deleted. It was installed at:
~/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/json-1.8.3

But Ruby is looking in the right place:
> require 'json'
=> true
> JSON.parse('')
JSON::ParserError: A JSON text must at least contain two octets!
	from ~/.rbenv/versions/2.3.1/lib/ruby/2.3.0/json/common.rb:156:in `initialize'

Upon further investigation, it looks like this is an issue with Bundler/Ruby, and not LicenseFinder. Bundler appears to be reporting the wrong value for full_gem_path, and Ruby 2.3.1 doesn't specify the license in the gemspec (fixed in master). Apologies for the premature bug report. Closing.


rewrite 316 on QAOA

https://github.com/Blueqat/blueqat-tutorials/blob/master/tutorial/316_trafficflow.ipynb

updated with mixer


Problem with GPS

Hi.
My company bougth one of those boards but I don't know if it was with or without GPS. I have been working with it without any problem using ESP-IDF modem component (pppos client, cmux,...).
Now, I want to use A7670G incorporated GNSS in a project. However, any command related with GPS answer with ERROR response. AT+CGNSSPWR, AT+CGPSINFO, AT+CAGPS,.. with everyone I get  response. It makes me think that modem was bougth without GPS version. If those command would be supported, AT+CGNSSPWR=? response should be valid instead GPS was not correctly configured.
Check pictures of responses here: https://community.lilygo.cc/topic/474/lilygo-t-a7670g-gps-problem
My question is... is it a "problem" with A7670G device that has not internally GPS device? or, is it problem with A7670G firmware version? If board bought was not GPS version, is there a way to enable GPS uploading new firmware version to modem?
Response to AT+SIMCOMATI:
Manufacturer: INCORPORATED
Model: A7670G-LLSE
Revision: A011B12A7670M7
A7670M7_B12V02_220613
QCN:
IMEI:<PHONE_NUMBER>15744
MEID:
+GCAP: +CGSM,+FCLASS,+DS
DeviceInfo:
OK

a7670g no gps

A7670G does not have GPS, different versions of firmware cannot be input


Deleting event class breaks reflection cache

I removed OnDawnEvent, fixed all compile errors and started the game with gradle run. It crashed with the message that the type name for OnDawnEvent could not be resolved.
Deleting the reflection cache file solved the problem.

Closing as complete - cache is only used for jars now, not local workspaces.