parse environment variables

Make librespot able to parse environment variables for options and flags. To avoid name collisions environment variables must be prepended with LIBRESPOT_ so option/flag foo-bar becomes LIBRESPOT_FOO_BAR.

Verbose logging mode (-v, --verbose, LIBRESPOT_VERBOSE=) now logs all parsed environment variables and command line arguments (credentials are redacted).

Haven't done the changelog yet because I didn't want to deal with any merge conflicts between this and https://github.com/librespot-org/librespot/pull/883. After that is merged I'll rebase and edit the changelog.

This is very handy for daemonizing librespot with systemd as you can specify an environment file and use that as a no cost config file and keep configuration details out of the service unit file. It's also a security win in that case since systemctl status does not require elevated privileges and previously username and password had to be passed as args so anyone could call systemctl status and see the passed creds in plain text.
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#EnvironmentFile=

In terms of your last comment specifically, other projects use a method where the service unit has something like
ExecStart=/usr/bin/foo --something_generic $FOO_OPTS

and then also define an EnvironmentFile=-/etc/default/foo which contains something like:
FOO_OPTS="--something1 hello --something2 world --secret mypasswordhere"

The benefit of this method is you don't need any special code to handle reading environment variables.

@kingosticks I know this, see the linked Raspotify issue. And generally that withstanding it's pretty common for command line apps to read environment variables. I don't understand the push back?

The roll your own var method is a kludge for apps that can't read env vars.

@kingosticks did you look at the code?  I don't think of parsing env vars as some sort of fancy feature, it a pretty basic thing that a great many command line apps are capable of doing.
IMHO this PR isn't about adding a feature but fixing an omission.

It wasn't meant to be push-back. I was highlighting the alternative because although it might be mentioned in https://github.com/dtcooper/raspotify/issues/460 it's not as clear in your comment here that the specific use-case of hiding arg values can be accomplished without changing librespot. You call that alternative a kludge and that opinion is fine.
This change might actually have as much benefit to those running from the command line (i.e. not a service) as it would allow them to more easily keep librespot settings in their dotfiles.
If/when you make this change, probably need to document somewhere which of the two config methods takes precedence when both are set.

It wasn't meant to be push-back. I was highlighting the alternative because although it might be mentioned in dtcooper/raspotify#460 it's not as clear in your comment here that the specific use-case of hiding arg values can be accomplished without changing librespot. You call that alternative a kludge and that opinion is fine.

Ok fair enough.
If/when you make this change, probably need to document somewhere which of the two config methods takes precedence when both are set.
If both are present the passed command line arg takes precedence. That seemed like the logical order of things to me.

fn arg_to_var(arg: &str) -> String {
    // To avoid name collisions environment variables must be prepended
    // with `LIBRESPOT_` so option/flag `foo-bar` becomes `LIBRESPOT_FOO_BAR`.
    format!("LIBRESPOT_{}", arg.to_uppercase().replace("-", "_"))
}

fn env_var_present(arg: &str) -> bool {
    env::var(arg_to_var(arg)).is_ok()
}

fn env_var_opt_str(option: &str) -> Option<String> {
    match env::var(arg_to_var(option)) {
        Ok(value) => Some(value),
        Err(_) => None,
    }
}

   let opt_present = |opt| matches.opt_present(opt) || env_var_present(opt);

   let opt_str = |opt| {
        if matches.opt_present(opt) {
            matches.opt_str(opt)
        } else {
            env_var_opt_str(opt)
        }
    };

env vars aren't even evaluated if command line args are present.

I know (I did read the code) and I agree that's the correct order. It was a reminder that it needs to be specified in the wiki/whatever.

The caveat being that flags are set if present (env and command line). The only way to override a flag set with an env var is to remove the env var. You can't override a set flag with another command line arg. If that makes sense?

It was a reminder that it needs to be specified in the wiki/whatever.

I will note it in the change log when the time comes and in the wiki.

The caveat being that flags are set if present (env and command line). The only way to override a flag set with an env var is to remove the env var. You can't override a set flag with another command line arg. If that makes sense?

Yes, I was thinking about that too. I think it has the potential to muddy the water when debugging as we often ask for the exact command used to invoke librespot in order to understand the settings they are running with. You can imagine someone setting an envvar, forgetting about it and later wondering why it's doing something odd. A solution would be to ensure there is (at least verbose) logging for every setting value. Or, have a mode that just prints the configured value for every setting and exits. The latter is quite nice as you can ask for that self-contained output in the bug report template etc.

Adding a trace level message would be pretty easy. An arg that outputs all args is kinda meta though. It's kinda like altering what you're trying to observe.

Meta not necessarily in a bad way but just in a way that it an arg about arg.

You could see it that way but that's not an argument against doing it. It's similar to help.
Anyways, it's out of scope here. Just something to keep in mind for later if we find ourselves getting tricked by the multiple sources for options. No need to fix something that isn't a problem (yet)!

I'm not arguing against it but I agree that we can cross that bridge if we come to it.

There the change log is updated and as noted after this is merged I will update the wiki.

To clarify the result would be:
/usr/bin/foo --something_generic --something1 hello --something2 world --secret mypasswordhere
And your "secret"  being completely visible to any and all user with  systemctl status foo. All you've managed to do is move it from the unit file to a environment file to make it easy to change. It's not secure at all even if you locked down the environment file because you've passed it as an arg and args are shown in plain text when you use  systemctl status.

And your "secret" being completely visible to any and all user with systemctl status foo. All you've managed to do is move it from the unit file to an environment file to make it easy to change. It's not secure at all even if you locked down the environment file because you've passed it as an arg and args are shown in plain text when you use systemctl status.

and echo $LIBRESPOT_PASSWORD?
PS: I like french windows, and a red door on my bike shed :-D
Nah, in all seriousness, given our use case, I don't think we should aim at anything more than opportunistic credit leaking, which you seem to have tackled for the raspotify use case.

and echo $LIBRESPOT_PASSWORD?

That won't do anything. The vars set in a service file aren't visible from the outside.

That won't do anything. The vars set in a service file aren't visible from the outside.

TIL!

My point was not to bikeshed but to clarify that the secret in the example is anything but a secret. The example seems to imply that it is. All the environment file does in that case is make it easier to change the args. It makes a faux config file.

I'm also not implying that proper env vars are bullet proof security. They're just marginally better.

My point was not to bikeshed but to clarify that the secret in the example is anything but a secret. The example seems to imply that it is. All the environment file does in that case is make it easier to change the args. It makes a faux config file.

Sorry, my comment was a drive-by - no offense meant!
FWIW, I got fed up with all the flags and moved to reading a config file on my fork, not for security, but usability/"singe source of truth".

Sorry, my comment was a drive-by - no offense meant!

No offense taken. It's all good. :smile:

FWIW, I got fed up with all the flags and moved to reading a config file on my fork, not for security, but usability/"singe source of truth".

I didn't go that far because I don't think everyone would be receptive to that. Reading env vars is really generic and pretty no-controversial, so I figured it had a much better chance of being merged and in the end in my case serves the same purpose.

If work is going into making librespot - the binary better, it might be time to just bite the bullet and convert it to librespot - the daemon? I feel we are hesitant to commit to the daemon, making life with the binary a bit convoluted?

I kinda already see librespot as 2 things. Taken all together built as a singular binary it really is functionally a daemon. And ofc it can be used as individual libs. I look at main as the glue that holds the bits together and makes the daemon. I think as long as we maintain the modularity it can be both. That is to say so long as changes to main to make for a better daemon don't make for worse libs I'm good personally.

I actually didn't realise the variable gets expanded. So it's no better for security, just nicer to have things in a dedicated config file rather than littering the service file (with the headaches that brings on upgrade).
The systemd docs make a big deal about environment variables being a bad idea for passing secrets. Not sure we need to buy into that level of paranoia. I think there's a limit to how secret this data needs to be. I guess if someone cares enough they can add support for something like .netrc or keyrings.

If work is going into making librespot - the binary better, it might be time to just bite the bullet and convert it to librespot - the daemon? I feel we are hesitant to commit to the daemon, making life with the binary a bit convoluted?

This is a good point.

echo $LIBRESPOT_PASSWORD

Ha! Is that the contents of your event handler script? I guess that'd work...

The systemd docs make a big deal about environment variables being a bad idea for passing secrets. Not sure we need to buy into that level of paranoia. I think there's a limit to how secret this data needs to be. I guess if someone cares enough they can add support for something like .netrc or keyrings.
I was mainly just trying to keep it out of the view of your average Lookie-loo. Realistically we're not talking about state secrets.

Not having garbage littering the service file is the primary reason. As you mention it makes updating much easier when/if args are added and/or change names.

Args are expended. Environment variables are not. Whatever you set as env vars is not visible. In your example you are passing the vars as args. You can set vars with a env var file and it will not be visible as long as you don't pass them as args.

In the example I gave i had fully intended to pass as an env variable loaded from the file.. Sorry, thought that intention was obvious.

This has kinda gone off the rails a bit. But I think I would be correct in say that everyone so far agrees that this is a good addition @roderickvd what do you think? Ready to merge?

Yeah I was lurking to see how this all unfolded 😆
I'll review it soon, this evening I'm keen to iron out the last things in my new-api WIP and push it out to you guys. Didn't know it was a contest but expect more than a few LOC 😜

I'll review it soon, this evening I'm keen to iron out the last things in my new-api WIP and push it out to you guys. Didn't know it was a contest but expect more than a few LOC

I'm more of the cleanup crew at this point, while you guys are the builders. You  guys do the heavy lifting and then I go in and smooth the rough edges and put a little polish on it.
I look forward to the new (new-new?) API. I think that once that is ironed out and maybe libmdns is cleaned up (if it even needs to be?) librespot has the opportunity to be a really next level stuff. I personally look forward to the audio back end bits when we move to supporting more than just vorbis.

There @kingosticks -v / --verbose now logs the env vars and command line args. The output looks like this:
$ export LIBRESPOT_NORMALISATION_PREGAIN=-3.0
$ export LIBRESPOT_AUTOPLAY=

$ librespot -u username -v --bitrate 320

[2021-11-27T22:30:34Z INFO  librespot] librespot 0.3.1 e2c3808 (Built on 2021-11-27, Build ID: TgKYi39V, Profile: release)
[2021-11-27T22:30:34Z TRACE librespot] Environment variables:
[2021-11-27T22:30:34Z TRACE librespot] 		LIBRESPOT_NORMALISATION_PREGAIN=-3.0
[2021-11-27T22:30:34Z TRACE librespot] 		LIBRESPOT_AUTOPLAY=
[2021-11-27T22:30:34Z TRACE librespot] Command line arguments:
[2021-11-27T22:30:34Z TRACE librespot] 		-u XXXXXXXX
[2021-11-27T22:30:34Z TRACE librespot] 		-v
[2021-11-27T22:30:34Z TRACE librespot] 		--bitrate 320

Creds are redacted.

Again I'm following this, please let me know when you're ready for final review and are all in agreement.

I'm ready. I'm still waiting for @kingosticks as he mentioned the idea of logging all the command line args and env vars so I added that.

Anyone that would like to see an implementation of this can checkout https://github.com/dtcooper/raspotify/tree/new-config

Specifically:
https://github.com/dtcooper/raspotify/blob/new-config/raspotify/lib/systemd/system/raspotify.service
And
https://github.com/dtcooper/raspotify/blob/new-config/raspotify/etc/raspotify/conf

Sorry, I've not got time to actually look at the code right now but the example in the comment looks great. Nice one.

@kingosticks the code isn't particularly clever. It just loops though vars and args outputs a trace level log message if there are any.

@roderickvd and @kingosticks and @ashthespy what say you? Merge?

LGTM :-) Thanks for your work!


fix check-format.pl false positive reporting '{1 stmt}' after multi-line if(expr)

fixes #11284
This PR also marks util/check-format.pl as executable (new mode 100755).

I've added a fix for a further (minor) false positive
and extended the negative tests checking for false positives.

I can't say that I quite understand the change, but the test files do show triggering examples, so...

This pull request is ready to merge

Pushed - thanks!


Ember-Core: simplify logic for push promises.

Compact the calls to traverse and parTraverse on a single branch, the one with push enabled and any push promises in the response.

I think this simplification is absolutely legit 👍🏻


Writes templates the first time custom data is used

Now that we allow comments in the custom data files, this change writes
localized templates as well as basic instructions. Links to McBopomofo
User's Manual are also provided.

LGTM.


Adding support for OPTIONS

https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request

Codecov Report

Merging #804 into master will decrease coverage by 0.12%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #804      +/-   ##
============================================
- Coverage     66.76%   66.64%   -0.13%
+ Complexity     4098     4091       -7
============================================
  Files           353      353
  Lines         26789    26830      +41
  Branches       3374     3376       +2
============================================
- Hits          17887    17880       -7
- Misses         7970     8003      +33
- Partials        932      947      +15

Impacted Files
Coverage Δ
Complexity Δ

...src/main/java/com.github.ambry/rest/RestUtils.java
96.41% <ø> (ø)
59 <0> (ø)
:arrow_down:

...main/java/com.github.ambry/config/StoreConfig.java
100% <ø> (ø)
1 <0> (ø)
:arrow_down:

...java/com.github.ambry/config/ClusterMapConfig.java
100% <ø> (ø)
1 <0> (ø)
:arrow_down:

...github.ambry.frontend/AmbryBlobStorageService.java
93.83% <100%> (+0.37%)
39 <2> (+2)
:arrow_up:

...om.github.ambry.frontend/AmbrySecurityService.java
97.24% <100%> (ø)
44 <0> (+2)
:arrow_up:

...n/java/com.github.ambry/config/FrontendConfig.java
100% <100%> (ø)
1 <0> (ø)
:arrow_down:

...rc/main/java/com.github.ambry/rest/RestMethod.java
100% <100%> (ø)
1 <0> (ø)
:arrow_down:

...ub.ambry.frontend/AccountAndContainerInjector.java
98.85% <100%> (ø)
25 <0> (ø)
:arrow_down:

.../main/java/com.github.ambry.rest/NettyRequest.java
94.71% <100%> (+0.04%)
79 <0> (+1)
:arrow_up:

...github.ambry.rest/AsyncRequestResponseHandler.java
87.62% <100%> (-3.2%)
23 <0> (ø)

... and 10 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9ef1084...3cf6421. Read the comment docs.


Hub Networking - Add publicIpPrefix declaration capability

Describe the feature end to end, including deployment scenario details under which the feature would occur.
Cannot currenly use Public IP addresses that are created within pubilc ip prefixes:

Capability needs added to module (Gateway, Bastion, Firewall) with relevant parameters to declare this:

Why is this feature important. Describe why this would be important for your organization and others. Would this impact similar orgs in the same way?
Will be fairly straight forward to implement the logic to the accelerator so a quick win for others.
Please provide the correlation id associated with your error or bug.
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Can you describe any alternatives that you have taken since this feature does not exist?
No response
Feature Implementation
No response
Check previous GitHub issues

[X] I have searched the issues for this item and found no duplicate

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Hey @oZakari - if i get chance, i'll look into it. I just made amendments to my local files to get around this issue for now.


Support NODE_PATH in forked process

This PR tries to fix #515 in a non-destructive way.
Basically it checks for the presence of NODE_PATH env variable before forking the process and creates an absolute path from it, so it could be used in test-worker.js as additional node module path.
That won't work there because process.cwd() points to the forked process test file.

Rather than modifying process.env.NODE_PATH in api.js you should probably pass a custom value in fork.js: https://github.com/sindresorhus/ava/blob/bdb8b6ebaa05f1dc31cdab7c84aed7d92317b8ed/lib/fork.js#L19:L22

Thanks for your input @novemberborn , I made the following changes:

removed the ugly process.env.NODE_PATH modify in api.js
added an option for the forked process (projectRoot) which contains the original path from where ava was called;
cycled through possible multiple values of process.env.NODE_PATH (with a simple OS check) and join their path with the one supplied by projectRoot.

Perhaps resolve the additional, absolute NODE_PATHs in the main process, once, and then pass the array through the opts to the test-worker.
You should add a test, probably in test/fork.js. Note that tests are written using node-tap. Maybe use t.spawn to spawn another test file (from the fixtures directory) with a NODE_PATH environment variable, then in that file use the lib/fork module to run an AVA test. You could set up NODE_PATH so the final test can do an import and have it be resolved correctly. I'm in Gitter if that wasn't clear https://gitter.im/sindresorhus/ava

I added the test and it seems like it's green now, but I surely forgot something else, let me know if something is missing!

LGTM!

Thanks @novemberborn for your patience, I hope that if I'll ever have to contribuite again it will be a smoother process, I learned a lot anyway :)

Thanks @novemberborn for your patience, I hope that if I'll ever have to contribuite again it will be a smoother process, I learned a lot anyway :)

No worries, looking forward to your next contribution!

Ugh, I really dread this change. Not the PR itself, but the fact of having to support NODE_PATH, which is deprecated and awful in so many ways...
Wouldn't it be better to just pass all environment variables from the parent to the worker? That way we wouldn't have to special-case future environment variable needs.

Wouldn't it be better to just pass all environment variables from the parent to the worker? That way we wouldn't have to special-case future environment variable needs.

The problem is that NODE_PATH can be relative and the tests run in a different working directory.

if (process.env.NODE_PATH) {
	process.env.NODE_PATH = process.env.NODE_PATH
		.split(path.delimiter)
		.map(function (p) {
			return path.resolve(p);
		})
		.join(path.delimiter);
}

Then?

In cli.js? Anywhere else and it may interfere with the programatic API.

Yes, or even better, just pass this directly to the env option when forking the worker, without overwriting the current process.env.NODE_PATH.

Well I will wait to make further changes so, while a better solution is found!

@ingro I think what @sindresorhus is saying is that you can add an env object in fork.js which sets NODE_PATH to the corrected value. Then you don't need the changes in test-worker.js.

Yup, and keep in mind that the whole existing process.env needs to be passed to the fork thing to preserve existing behavior, so use object-assign to copy the object and then modify the NODE_PATH key.

Well I think that's cleaner, I will look at it as soon as I have time!

The commit has some conflicts, what's the procedure in situation like this?

@ingro You resolve the merge conflict. (No need to open a new PR)

It seems we are back to green!

Welp sorry, I blindly copied from one of your comment above.
That should fix the wrong assignment:
env = objectAssign(env, { NODE_PATH: nodePath });
Anyway tests still fails, will look into that!

I think I found the problem with the test, it was:
var nodePaths = 'node-paths/modules' + path.delimiter + 'node-paths/deep/nested';

while it should have been:
var nodePaths = 'fixture/node-paths/modules' + path.delimiter + 'fixture/node-paths/deep/nested';

That's because NODE_PATH should be relative to the directory from which ava is running, not to the test itself.
I've fixed that in my fork, I should create another pull request?

I should create another pull request?

Yep! :dancers:

Created here https://github.com/sindresorhus/ava/pull/559

@sindresorhus I think this regressed with commit 1f10a7cfa1b2ccc9378143c08f79727e725c5550.

@hildjj that was intentional.

Is this the correct place to discuss whether that was the correct decision?  I don't see an issue or pull request associated with that commit, so I'll assume yes, unless you'd like me to open a new issue.
I have an (admittedly crappy) use case where being able to manipulate NODE_PATH is very handy.  It involves using the same test suite to test two different builds of the same software that have subtle differences in their dependencies.  I can figure out another way around this if I have to, but it was convenient.

You could use an ava.config.cjs file to rewrite the NODE_PATH and configure it as an environment variable for AVA to use for the worker processes. We're not going to bring back specialized handling in AVA itself.

I'm arguing that it's not specialized handling.  ava is now modifying the environment being passed to my tests in a surprising way.  At the very least I would have expected something in the release notes and something in the docs for a change that breaks existing functionality built in to node.  The docs currently say:
"environmentVariables: specifies environment variables to be made available to the tests. The environment variables defined here override the ones from process.env"
which is at least confusing at the moment, since it's not clear that the process.env isn't the same as the environment passed in to ava.
ava.config.cjs might work for me, with some logic to detect which of the cases I'm in, I suppose.

No, AVA 3 no longer modifies anything. But let's continue this in a Discussion.

https://github.com/avajs/ava/discussions/2682 for linkage


swarm not compatible with latest docker

It is not possible to retrieve the hostname of a swarm replica using cc-runtime 3.0.4 with docker 17.06-ce as it leaves the replicas in "create" state.
$docker swarm init
Swarm initialized: current node (cl0wp2btl2e2gt0yaeh33m2og) is now a manager.
$ docker service create --name testswarm --replicas 1 --publish 8080:80 mcastelino/nginx /bin/bash -c "hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"" 2> /dev/null
10oehfg3hn2byxv2emb3z8ukg
$docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b017d21f121c mcastelino/nginx:latest "/bin/bash -c 'hostna" 2 minutes ago Created testswarm.1.3jjt16h597dko31tjgb8pfegy
Setup:
cc-runtime : 3.0.4
commit : 28bd75d
OCI specs: 1.0.0-rc5

However, this behaviour does not occurr when we are using docker-engine 1.12.1

@amshinde @GabyCT @jodh-intel just some early debug info.
The docker swarm networking implementation has changed quite a bit. The service IP assignment has moved from the container interface to the loopback interface. Also in my case I could not get some of the tests to work even with runc. I will look at all the docker swarm changes in detail and come up with a set of changes. However this will involve some work from our end.
So we should qualify which version of swarm we support yet again till we fix all the issues.

For the record, I see the following curl behaviour on Ubuntu 17.04:

docker 17.05.0-ce: hangs.
docker 1.12.6-0ubuntu4: connection refused.
docker 1.12.1-0ubuntu15: works.

Although with 1.12.1 the curl works, qemu and cc-proxy processes are left behind.
fuentess@test-swarm:~/go/src/github.com/clearcontainers/tests$ ps -ef | grep -c qemu
17
fuentess@test-swarm:~/go/src/github.com/clearcontainers/tests$ ps -ef | grep -c cc-pr
18

Also cc-runtime list stops working:
fuentess@test-swarm:~/go/src/github.com/clearcontainers/tests$ sudo cc-runtime list
stat /var/lib/docker/overlay2/beb512b966cf76f45e8a6d36a49c5d9ae9278ac7dfcdf548bf9db52e0e4875bf/merged: no such file or directory

On cc-runtime log:
Dec 28 18:10:20 test-swarm cc-runtime[86681]: time="2017-12-28T18:10:20Z" level=error msg="Container still running, should be stopped" source=runtime

On cc-proxy log:
Dec 28 18:10:20 test-swarm cc-proxy[86113]: time="2017-12-28T18:10:20.033990165Z" level=error msg="error serving client: write unix /run/virtcontainers/pods/4aca4486137fca02d7b02ea73cc3d0261b34e9ed8000af51564c4a
6713a8905f/proxy.sock->@: write: broken pipe" client=2 name=cc-proxy pid=86113 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86113]: time="2017-12-28T18:10:20.034216762Z" level=info msg="connection closed" client=2 name=cc-proxy pid=86113 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86113]: time="2017-12-28T18:10:20.050816354Z" level=info msg="client connected" client=5 name=cc-proxy pid=86113 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86113]: time="2017-12-28T18:10:20.051177949Z" level=info msg="AttachVM(containerId=4aca4486137fca02d7b02ea73cc3d0261b34e9ed8000af51564c4a6713a8905f)" client=5 name=cc-proxy pi
d=86113 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86113]: time="2017-12-28T18:10:20.052367934Z" level=info msg="hyper(cmd=\\\"killcontainer\\\", data=\\\"{\\\\\\\"container\\\\\\\":\\\\\\\"4aca4486137fca02d7b02ea73cc3d0261b34
e9ed8000af51564c4a6713a8905f\\\\\\\",\\\\\\\"signal\\\\\\\":9,\\\\\\\"allProcesses\\\\\\\":true}\\\")" client=5 name=cc-proxy pid=86113 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86113]: time="2017-12-28T18:10:20.078413208Z" level=error msg="error writing I/O data to client: write unix /run/virtcontainers/pods/4aca4486137fca02d7b02ea73cc3d0261b34e9ed80
00af51564c4a6713a8905f/proxy.sock->@: use of closed network connection" name=cc-proxy pid=86113 section=io source=proxy vm=4aca4486137fca02d7b02ea73cc3d0261b34e9ed8000af51564c4a6713a8905f
Dec 28 18:10:20 test-swarm cc-proxy[86113]: time="2017-12-28T18:10:20.084839327Z" level=info msg="hyper(cmd=\\\"removecontainer\\\", data=\\\"{\\\\\\\"container\\\\\\\":\\\\\\\"4aca4486137fca02d7b02ea73cc3d0261b
34e9ed8000af51564c4a6713a8905f\\\\\\\"}\\\")" client=5 name=cc-proxy pid=86113 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86113]: time="2017-12-28T18:10:20.189627114Z" level=info msg="connection closed" client=5 name=cc-proxy pid=86113 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.514057147Z" level=info msg="Signal(killed,0,0)" client=2 name=cc-proxy pid=86094 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.514138646Z" level=info msg="waiting for runtime to execute the process for token hLxW8hejRP1Us5w0UB0kJRowv6VZrtN0XaERKi3V4LE= (timeout 30s)"
name=cc-proxy pid=86094 section=io source=proxy vm=ef34fe9a2798081739c102ee232e557cb8a8929b7b320310d897ad13759a8529
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.519005485Z" level=error msg="error serving client: write unix /run/virtcontainers/pods/ef34fe9a2798081739c102ee232e557cb8a8929b7b320310d897ad
13759a8529/proxy.sock->@: write: broken pipe" client=2 name=cc-proxy pid=86094 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.519236982Z" level=info msg="connection closed" client=2 name=cc-proxy pid=86094 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.543561977Z" level=info msg="client connected" client=5 name=cc-proxy pid=86094 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.543722675Z" level=info msg="AttachVM(containerId=ef34fe9a2798081739c102ee232e557cb8a8929b7b320310d897ad13759a8529)" client=5 name=cc-proxy pi
d=86094 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.544061971Z" level=info msg="hyper(cmd=\\\"killcontainer\\\", data=\\\"{\\\\\\\"container\\\\\\\":\\\\\\\"ef34fe9a2798081739c102ee232e557cb8a8
929b7b320310d897ad13759a8529\\\\\\\",\\\\\\\"signal\\\\\\\":9,\\\\\\\"allProcesses\\\\\\\":true}\\\")" client=5 name=cc-proxy pid=86094 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.559092982Z" level=info msg="hyper(cmd=\\\"removecontainer\\\", data=\\\"{\\\\\\\"container\\\\\\\":\\\\\\\"ef34fe9a2798081739c102ee232e557cb8
a8929b7b320310d897ad13759a8529\\\\\\\"}\\\")" client=5 name=cc-proxy pid=86094 source=proxy
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.563611626Z" level=error msg="error writing I/O data to client: write unix /run/virtcontainers/pods/ef34fe9a2798081739c102ee232e557cb8a8929b7b
320310d897ad13759a8529/proxy.sock->@: use of closed network connection" name=cc-proxy pid=86094 section=io source=proxy vm=ef34fe9a2798081739c102ee232e557cb8a8929b7b320310d897ad13759a8529
Dec 28 18:10:20 test-swarm cc-proxy[86094]: time="2017-12-28T18:10:20.661964793Z" level=info msg="connection closed" client=5 name=cc-proxy pid=86094 source=proxy

This sometimes leads to not being able to start the replicas:
ok 2 # skip (This is not working (https://github.com/clearcontainers/tests/issues/694)) check_service_ip_among_the_replicas
not ok 3 obtain hostname of the replicas
# (in test file integration/swarm/swarm.bats, line 83)
#   `REPLICAS[$i]="$(curl --connect-timeout $timeout --retry $number_of_retries $url)"' failed with status 7
# Swarm initialized: current node (8t65ureewbkxty8s06r26urnv) is now a manager.
#
# To add a worker to this swarm, run the following command:
#
#     docker swarm join \
#     --token SWMTKN-1-39nw7h9kj2uldqdixzn3fmw2n1irbxox9gi85b1xipjhcpcq5z-4trwiu6und6sktoy3cgo2nouc \
#     <IP_ADDRESS>:2377
#
# To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
#
# 6uat0eob3dpqau6lqkg4ltijn
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
# ID            NAME       REPLICAS  IMAGE         COMMAND
# 6uat0eob3dpq  testswarm  0/4       gabyct/nginx  sh -c hostname > /usr/share/nginx/html/hostname; nginx -g "daemon off;"
#   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
#                                  Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0curl: (7) Failed to connect to <IP_ADDRESS> port 8080: No route to host
# testswarm
# Node left the swarm.


Post-Gen/Custom Chronicle Limitations (Feature Request)

Submitter: Annastasya
Email<EMAIL_ADDRESS>First off, I really like the generator. An amazing job was done here! I do notice however that it seems to be limited to first-time generation rules as to the bubble limits. While in many cases this won't be an issue for ongoing characters leveling up or special campaigns (for instance one I am running currently the players have a lot of experience in VtM and are playing a campaign as elders of 3rd/4th gen) you aren't able to expand beyond 5 in any trait/skill/etc. It would be nice to have the option of expanding to a full 9 or 10 dots as an option. Perhaps there can be a checkbox/binary toggle switch for regular generation that flips between limiting to 5 dot boxes or 10?
Thanks again for the wonderful job thus far, I'm going to recommend to my group that they take a look and use this in the future.
~Anna

I appreciate the feedback. XP expansion is a highly requested feature. I'll make sure to make a note of this as the most wanted thing for the site.


Codal fs

Introduction of persistent logging to USB interface.

enables ~120KB of persistent storage for user use
introduces CSV logging capability, with integrated HTML preview and download on MICROBIT drive

Killer! Nice work all involved!


Updates benchmarks for new S3 bucket/versions

Updates the data plugins (not benchmarks, which do not need to be modified) to allow benchmarks to pull from Brain-Score AWS instead of old DiCarlo AWS.

Requires https://github.com/brain-score/brainio/pull/55 to work


Using a hook.disable() on a service should remove that from the Allow header for REST services

@sjmcdowall commented on Mon Oct 03 2016
I disabled a bunch of service calls using hooks.disable() in a before hook call with code like:

exports.before = {
    all: [],
    find: [],
    get: [],
    create: [hooks.disable()],
    update: [hooks.disable()],
    patch: [hooks.disable()],
    remove: [hooks.disable()]
};

Yet the Allow header still shows all services available:
Allow →GET,POST,PUT,PATCH,DELETE
(From Postman)
I would think that if we use a stock hook.disable() then the associated Allow header component should be removed as well.

How would a hook remove the associated Allow header component?

This would require collaboration between a hook and response middleware.

Which actually should be possible in the next version because the providers can actually get the hook object (instead of just the result) thanks to https://github.com/feathersjs/feathers/pull/607

No, there has been no change.

Is this a change I could help with?

You are invited to give it a try. :)

Okay I will. Do we discuss implementation in this issue or DM?

Its best you outline it here so @daffl can comment on it.

I'm going to close this since it isn't really possible to do this via just hooks anyway because other than the method that is being called, there is no way to figure out which other methods the disable hook is attached to.

Sorry for commenting on a closed issue @daffl. I would like to reacte to the above if I may.
My suggestion would be to not try and solve this using magic, but keep it transparent. I have done a quick proof of concept in which I have:

Implemented a hook: allowed-methods:

const { arrayContainsArray } = require('../libs/common');

const validMethods = [ 'GET', 'POST', 'PUT', 'PATCH', 'DELETE' ];

// TODO handle nested service calls
module.exports = function (allowedMethods = []) {
  return context => {
    if (!Array.isArray(allowedMethods)) allowedMethods = [ allowedMethods ];
    if (!arrayContainsArray(validMethods, allowedMethods)) {
      throw new Error('Allowed methods: ' + validMethods.join(', '));
    }

    // Make sure the hook is returned instead of just the result data, so that the middleware can adjust the http
    // Allow header accordingly
    context.params.__returnHook = true;
    context.params.allowedMethods = allowedMethods;
  };
};

Added a custom middleware:

app.configure(express.rest(function(req, res) {
  // If hook is returned instead of just the result data, check if supportedMethods is set and update the HTTP Allow header
  // accordingly
  if (res.hook && res.hook.params.allowedMethods) {
    // Update the HTTP Allow header with the allowed methods
    res.set('Allow', res.hook.params.allowedMethods.join(','));
  }
  res.json(res.data);
}));

Added the hook to the service hooks:

module.exports = {
  before: {
    all: [
      allowedMethods('GET')
    ],
    find: [
      disallow()
    ],
    get: [],
    create: [
      disallow()
    ],
    update: [
      disallow()
    ],
    patch: [
      disallow()
    ],
    remove: [
      disallow()
    ]
  },
  ...
}

This shows that it can work.
There are a few additional functionalities required:

Hook

It should able be possible to specify per transport
It should send a 405 (Method not allowed) if a method is called for a transport that is not supported

Middleware

The middleware implementation should move to the default middleware

What do you think?

An alternative approach could be to adapt the disable functionality and disallow hook to update a property of params, i.e. disabledMethods. They could also set the __returnHook to true. The default middleware could then pickup this information to set the HTTP Allow header. This approach means the users will not have to configure anything extra.
What do you think of this alternative?

Yes, an allow hook like
  before: {
    all: [
      allow('rest', [ 'find', 'get' ])
    ],

Would make this possible but would still require changes in @feathersjs/express because the Allow header is hardcoded at the moment (see: https://github.com/feathersjs/feathers/blob/master/packages/express/lib/rest/wrappers.js#L35). __returnHook is only for internal use and should not be necessary. Any middleware will already have the hook in res.hook.

Yes, I saw that in the middleware. Good to know the __returnHook is unnecessary.
Can I move forward with the changes? Must I open a new/another issue in Feathers Express for that change?

@nidkil Are you suggesting to also submit a PR for @feathersjs/express?
I would not call the hook allow as that's too ambiguous. Maybe allowHeaders.
@daffl ^^^

@eddyystop yes that is what I am suggesting also based on @daffl's remarks. An alternative would be to add a custom middleware, but I'm not sure that is the route to go. Your thoughts on this?

@eddyystop & @daffl my first idea was to name the hook allowedMethods, daffl is suggesting allow and eddyystop is suggesting allowHeaders. My preference goes to eddyystops suggestion as I think it clearly describes what it is for. You guys agree?

There are enough common hooks that its confusing. Each hook name needs to identify what it does so its easier to find.
I think allowHeaders is the least specific we can have., though that's still ambiguous. Better might be something like httpAllowHeader. I'm open to suggestions for a clear name. Naming is hard.

I'm not talking about headers, I'm suggesting a hook that allows certain service methods for a certain transports. It could then add that information somewhere on the context and it can be used in an Express middleware.
Unless @feathersjs/express is being changed to check if the Allow header already exists, the only way to set the header at the moment is in a custom formatter middleware.

Okay to summarize:

Create hook (httpAllowHeader) that sets allowed methods per transport and sets this information on the context (context.params.httpAllowedMethods).
Modify default middleware (@feathers/express) to check if allowed methods is set on the context for the transport and if it is set the HTTP Allow header.

If you guys agree I will implement it this way.
One more question to be sure: this functionality is only relevant for the REST transport isn't it? Does that mean that the transport isn't relevant for the hook as the context settings will only be picked up by the Express middleware?

As most other things in Feathers, hooks should not have to know about their transport. That's why I was suggesting to allow service methods (not HTTP methods). It can be mapped to their HTTP methods in the middleware.

I agree that hooks in principle should not have knowledge about the transports. However in this case that seems awkward as the hook is only applicable to the REST transport. Isn't it?
This actually comes back to the question in my last response: isn't this functionality only applicable to the REST transport? If so it means:

The transport is not needed when setting the hook
Both the hook name (httpAllowHeader) and context information (context.params.httpAllowHeaderMethods) are transport specific (REST)

Is this correct?

This is what I'm talking about:
const { Forbidden } = require('@feathersjs/errors');

const allowMethods = (provider, methods) => {
  return context => {
    const { method, params } = context;

    if(params.provider === provider) {
      if(!methods.includes(context.method)) {
        throw new Forbidden(`Method ${method} is not allowed`);
      }

      context.methods = methods;
    }

    return context;
  };
};

Update @featherjs/express in https://github.com/feathersjs/feathers/blob/master/packages/express/lib/rest/wrappers.js#L19-L25 to also receive the hook context and use context.methods:
const allowedMethods = function (service, context) {
 const methods = context.methods || Object.keys(methodMap)
    .filter(method => typeof service[method] === 'function');

  return methods.map(method => methodMap[method])
    // Filter out duplicates
    .filter((value, index, list) => list.indexOf(value) === index);
};

Now we have a hook that can be used to allow methods for any transport and for REST allows to set the proper header like I showed initially:
  before: {
    all: [
      allowMethods('rest', [ 'find', 'get', 'create' ])
    ],

Are you proposing to replace the disallow hook by this new hook?


Rework security labels for devices

"can-access-hardware-devices" is incorrect for device=all since it allows access to emulated/"software" devices as well
The label for can-access-input-devices is incorrect. --device=input doesn't allow access to keyboard and mices. See https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1428#note_1993226
It's mostly useful for gamepads and usb gadgets

I think this will blow up the weblate repo, I usually try to only edit the main translation en - not sure renaming complete keys won't cause a merge conflict in their repo.


Help users easier to report bugs

Thank you for your contribution to the KodaDot NFT gallery.
Let's do a quick check before the merge.
Your contribution will be an eternal part of the community codebase
Before submitting this PR, please make sure:

[x] Code builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I didn't break any original functionality

Optional

[x] I've tested it on mobile and everything works

PR type

[ ] Bugfix
[ ] Feature
[x] Refactoring

What's new? (maybe part of changelog)

closes #<601> -

If issue contains bounty label ($,$$,$$$)

Your KSM address: <Kusama_address>

Community participation

[x] Are you at KodaDot Discord? If no, let's join us - https://discord.gg/35hzy2dXXh

Screenshot

[x] Whenever your fix will change something on UI, a screenshot is more than welcome

LGTM 🚀


Remove nullptr subtraction in pqsort.c

nullptr subtraction behavior is undefined
MacOS warning:
pqsort.c:106:7: warning: performing pointer subtraction with a null pointer has undefined behavior [-Wnull-pointer-subtraction]
loop:   SWAPINIT(a, es);
^~~~~~~~~~~~~~~
pqsort.c:65:47: note: expanded from macro 'SWAPINIT'
#define SWAPINIT(a, es) swaptype = ((char *)a - (char *)0) % sizeof(long) || \

I'm a bit conflicted here.  The code dates to the early 90s and has worked fine, but this warning is quite new: https://reviews.llvm.org/D98798
I'm not sure what the original intent of subtracting zero was.

It looks like its an archaic way to get an integer from a pointer in a safe way.  I think we should cast to the modern intptr_t type.  If clang is making a warning about this they may miscompile in the future.


Preview: "Close All" leaves all instances of OpenConsole.exe running

Windows Terminal version
WindowsTerminalPreview 1.16.2209.21001
Windows build number
10.0.19044.2130
Other Software
No response
Steps to reproduce
Start WT preview.  Open a few tabs, click the "X" and click "Close all".
Expected Behavior
The instances of OpenConsole.exe are terminated.
Actual Behavior
All instances of OpenConsole.exe are left running.
Note that this does not happen with the release version of WT (1.15.2209.09004).

Thanks for the report! I believe this is a /duplicate of #14132, where OpenConsole is waiting for teardown to finish before exiting but it's blocked on teardown.


WASM runner / WebView

I had some success, a while back ,  running the main panel as a WASM in a WebView. All golang if coatse.
the deck gio canvas ran fine there.
the file tree is the same on the left .
this is only so you can swap out the binary that runs in the main panel. I  needed it because the schema varies and so the gui needs to be loaded as WASM .
If your interested we can make an example or something
the tabs on the top were gio native btw . So each view has side a tab is a WebView.
it also means you can phat video and other stuff which is hellish without a WebView

Sure, that might deserve a dedicated project. You can post your goal and I'll contribute. I have played around with the webviewer some time ago. It worked pretty well except the layout does not play well with Gio's layout system.

I'm looking forward to it.


feat(unplugin-vue-i18n): allow for a custom i18n block transform hook

Background
My organization has been using Vue i18n for over 6 years now and it has been invaluable to the project. We recently upgraded to Vue 3 and ran into an issue with the latest version if i18n and it's newest plugins.
Due to the size of our application we've had a custom loader that runs before the Vue i18n plugin in Webpack. This allows us at build time to fetch the translations and then replace the <i18n> blocks with the correct format.
Reasoning
Due to the size of our application, we can't feasibly put all the translations into our components during development so we create the slugs and then the translations are entered into our CMS by our content team. We could put translations in json files in the repo - but then it requires content folks to edit via JSON files and know how to use git etc.  The ability to edit in a CMS alongside all other content is a better DX for content teams and to make that work the plugin needs this type of async hook
Additionally, this method allows us to compartmentalize the translations in the <i18n> blocks and the translations are bundled with each component's respective chunk.
Example of our workflow:
Before
<i18n>
[
    'slug-one',
    'slug-two'
]
<i18n>

After
<i18n>
{
    'en': {
      'slug-one': 'foo',
      'slug-two': 'bar'
    },
    ja: {
      'slug-one': 'foo',
      'slug-two': 'bar'
    }
}
</i18n>

This PR aims to allow the plugin to accept a custom transform function that will modify the source before the plugin parses the i18n block.
This is only necessary because it appears we read the file from disk during build and I'm unsure on how to modify the file before it reaches the Vuei18n plugin. If there's a better way to handle this please let me know. Thanks for your consideration!
To Do

[x] Add unit tests
[x] Fix failing tests

@kazupon I would very much appreciate your feedback on this approach. Should I open an issue for this PR as well? Thanks for your consideration 👍

Thank you for your contribution! That sounds good!
We need the docs for that option in the readme before you can merge your PR. https://github.com/intlify/bundle-tools/tree/main/packages/unplugin-vue-i18n#-options
Could you put it to docs? 🙏

Excellent. I was out last week, I'll work on updating it this week! Thanks

I've just released v5.0.0-beta.4
You can try to install it!


Compress pairs variables related by linear equality

Feature request:
If a constraint of the form a x_1 + b x_2 = c,
remove the variable x_2 be substituting x_2 =  c/a - b/a x_2.
Translate solutions back to full variable set afterwards.
These kinds of constraints show up in a number of application in problems (especially linear problems), as it is often assumed the impact of the redundant variables on the speed of solution will be negligible.

A note for the future when we do implement this, we'll need to be a bit careful to not introduce self-loops. Because right now we transform
xx <= 5

into
xy <= 5
x - y = 0

so naively following the compression rules would undo that transformation.


Failure to attach cppdbg

Hello folks!
I have the following tasks.json:
{
    "version": "2.0.0",
    "runner": "terminal",
    "options": {
        "cwd": "${workspaceRoot}/Firmware",
        "env": {
            "PATH": "${env:PATH}:${workspaceFolder}/../build-tools/bin/linux"
        }
    },
    "tasks": [
        {
            "label": "4-attach-logger",
            "type": "shell",
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "dedicated",
                "showReuseMessage": true,
                "clear": false
            },
            "isBackground": true,
            "dependsOn": "3-start-debugger",
            "command": "telnet <IP_ADDRESS> 2342",
            "problemMatcher": []
        },
        {
            "label": "3-start-debugger",
            "type": "shell",
            "dependsOn": "2-deploy-image",
            "command": "azsphere device app start --debug --componentid 0f149356-2cb8-4aa4-9608-f41e060d82c5",
            "presentation": {
                "echo": true,
                "reveal": "always"
            }
        },
        {
            "label": "2-deploy-image",
            "type": "shell",
            "dependsOn": "1-build-firmware",
            "command": "azsphere device sideload deploy --manualstart --imagepackage out/debug/eGYM_Backbone.imagepackage",
            "presentation": {
                "echo": true,
                "reveal": "always"
            }
        },
        {
            "label": "1-build-firmware",
            "type": "shell",
            "command": "./rungn debug -p",
            "presentation": {
                "echo": true,
                "reveal": "always"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                {
                    "owner": "cpp",
                    "fileLocation": [
                        "relative",
                        "${workspaceRoot}/Firmware"
                    ],
                    "pattern": {
                        "regexp": "^../../(.*):(\\d+):(\\d+):\\s+(warning|\\w*\\s?error):\\s+(.*)$",
                        "file": 1,
                        "line": 2,
                        "column": 3,
                        "severity": 4,
                        "message": 5
                    }
                },
                {
                    "owner": "cpp",
                    "fileLocation": [
                        "relative",
                        "${workspaceRoot}/Firmware"
                    ],
                    "pattern": {
                        "regexp": "^../../(.*?):(.*):\\s+(warning|\\w*\\s?error):\\s+(.*)$",
                        "file": 1,
                        "severity": 3,
                        "message": 4
                    }
                }
            ]
        }
    ]
}

And the following launch.json:
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "eGYM.Backbone (gdb)",
            "type": "cppdbg",
            "request": "launch",
            "externalConsole": true,
            "miDebuggerServerAddress": "<IP_ADDRESS>:2345",
            "cwd": "${workspaceFolder}/Firmware",
            "preLaunchTask": "4-attach-logger",
            "miDebuggerPath": "/opt/azurespheresdk/Sysroots/4+Beta2001/tools/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-musleabi/arm-poky-linux-musleabi-gdb",
            "program": "${workspaceRoot}/Firmware/out/debug/exe.unstripped/eGYM_Backbone.out",
            "MIMode": "gdb",
            "sourceFileMap": {
                "${workspaceRoot}/Firmware": "Firmware"
            },
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                }
            ]
        }
    ]
}

Following the numbers on the tasks array you will see that when I press F5, it build and pack the project (1), deploy it to the target device (3), ask the device to go into the debug mode (4).
The step 4 is where my problem exist. In order for the device to be able to really start the gdbserver it requires me first to connect over telnet to the port 2342. So when I run this project I see this on the terminal:

That means the debugger actually started, and is listening on 2345. If you see from the launch.json it should be ok and the debugger should just be able to attach to it right? Except it doesn't. Even marking the task 4 as "isBackground": true, the task still hanging and VSCode still stuck on the running progress bar:

The fact is that, in order to debug, I need to follow the following tasks:

Build the C/C++ code
Pack the device image
Deploy to the device
Tell the device to enter debug mode
Telnet to 2342 and keep the telnet running while at the same time let VSCode proceed
Attach gdb to 2345
When the debugger session is over, both gdb and telnet must be killed
reboot

The current configs hand on 5.
This issue is basically "how can I run a background task that is used as preLaunchTask and that must keep the process running while the debugging session is running without block the debugger to actually run?".
So, can anyone point me what am I doing wrong with those configs in order to support that scenario?

PS: Please ignore the fact that it is an Azure Sphere MCU device as you may figure out by some usages of azsphere CLI over the tasks.json and that it has its own extension on VSCode marketplace. We don't want to use CMake and since it is a regular linux device with a public SDK/toolchain, it should work with regular C/C++ extension as well. We are using gn with ninja and everything works well (I can keep the telnet running on another terminal but that is far from ideal), except the F5 experience.

Thank you! I really appreciate any help!

Please file against the C++ extension.

@weinand it is not a CPP extension problem. It is the fact the VSCode isn't allowing me to run a task in back ground as it should. That is why I've opened the issue here...

@weinand I've opened it there but they said tasks.json problems are VSCode team problem... So, you say it is their problem, they said it is yours... Who can we finally hope for support?

@weinand The title is misleading. @galvesribeiro is trying to call a task that he wants to leave running in the background and then to start debugging but the problem is he calls this task and it hangs there, never getting to the actual debugging step. If this is something in the extension that we need to fix, can you point me on where to look?

I think we actually fixed this already with https://github.com/microsoft/vscode/issues/66561
@galvesribeiro can you please see if your issue occurs in the latest release of VS Code?

Hello @alexr00!
It was fixed with that PR indeed. The problem was timing. Just like on the PR repro case you linked.
Thank you!


Error in setup

The problem
After upgrading to the latest version (0.3.11) I get this error when I restart HA or reload nest protect:
2023-02-21 20:34:36.077 DEBUG (MainThread) [custom_components.nest_protect] Migrating from version 3
2023-02-21 20:34:36.077 DEBUG (MainThread) [custom_components.nest_protect] Migration to version 3 successful
2023-02-21 20:34:36.077 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Nest Protect for nest_protect
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 382, in async_setup
    result = await component.async_setup_entry(hass, self)
  File "/config/custom_components/nest_protect/__init__.py", line 55, in async_setup_entry
    refresh_token = entry.data[CONF_REFRESH_TOKEN]
KeyError: 'refresh_token'

And all the devices (3) are unavailable
It worked yesterday, in 0.3.10.
What version of this integration (ha-nest-protect) has the issue?
0.3.11
What version of Home Assistant Core has the issue?
2023.2.5
Device / Model
Model: Topaz-2.33, Firmware: 3.4.1rc1
Diagnostics information
No response
Home Assistant log
Logs
```
Copy/paste any log here, between the starting and ending backticks (`)
```

Additional information
No response

Did you use the cookie version before? If so, you shouldn't have updated since the update does not support cookie auth yet.
Best is to revert to the previous version.

I tried installing older versions all the way back to 0.3.8 (which is from before my installation) using HACS.
The same happens in .8 .9 and .10 versions.

@hmorkemo did you use the cookie auth method before? If so, you didn't install my version, but another version...

I'm confused.
I have now deleted the next protect integration.
When I try to add it again, it appears twice in the repository list.
I'll try the the top one (with 189 likes).
I can't get past the invalid_request error, even if I follow the advice in #105.
When I select the other one, it says that the repository is owned by iMicknl. When I try to go to Github, I arrive at nicoinch/ha-nest-protect, whici is forked from the iMickNL one.
I tried the nicoinch one as well. There I get
Translation Error: The intl string context variable "url" was not provided to the string "To link your Google account, authorize your account.
when I try to add the integration. So no luck there either.
Something is wrong, or at least hard to understand.

@hmorkemo -- did you manage to get this resolved? i am getting the same issue.

Please update to latest pre-release (beta) via HACS or GitHub releases and try again.


Make openapi spec endpoint public (HMS-1220)

At least two flaws.
The testcase fails! But that should be fixed (in the code, not the test) I guess. Result is:
--- Expected
+++ Actual
@@ -1095,2 +1095,3 @@
 "servers":[{"url":"/api/image-builder/v1"},
+{"url":"/api/image-builder/v1.0"},
 {"url":"/api/image-builder/v1.0"}]}

and the splitting of API with tags is not really nice.
I'm not a pro on openAPI and there might be a solution by using oapi-codegen with security context?
When I tried it, the context is generated after the middleware callbacks so those would need to be more flexible to also accept unauthenticated requests. Please guide me to a good solution.

I think I found the problem why my testcase failed...

Does it make sense to show what I mean (changing the middleware functions) by creating a second DRAFT PR so we can choose?

Does it make sense to show what I mean (changing the middleware functions) by creating a second DRAFT PR so we can choose?

Up to you, but I'd love that :orange_heart:


Correction in section 3.9 "Extending neomodel" of documentation

I believe there should be a correction in documentation of section 3.9. Currently the extend code is written as
class Person(StructuredNode):
    name = StringProperty(unique_index=True)
    def __init__(self, name, **args):
        self.name = name
        super(Person, self).__init__(self, **args)

while it should be
class Person(StructuredNode):
    name = StringProperty(unique_index=True)
    def __init__(self, name, *args, **kwargs):
        self.name = name
        super(Person, self).__init__(self, *args, **kwargs)

as the constructor of StructuredNode also takes in these 3 parameters
On a side note, I have a question whether something like selecting all nodes given a list is supported ( I cannot find it in current doc)? like the sql IN list query

@siddharthm great thanks for the catch, if you wouldn't mind opening up a PR with that change I can get it merged in. If not I'll get it updated as soon as possible.
For you side note there currently isn't a very clean way to accomplish that using one of neomodel's query methods. We can open up an additional ticket to investigate how something could be implemented to support it but in the mean time the easiest solution will probably to use a cypher query. That will enable you to do something like the following:
from neomodel import db
query = "MATCH (tobias { name: 'Tobias' }),(others)" \
             "WHERE others.name IN ['Andres', 'Peter'] AND (tobias)<--(others)" \
             "RETURN others"
results, meta = db.cypher_query(query)
people = [Person.inflate(row[0]) for row in results]

Depending on what you want to accomplish the query could be changed to be something like
query = "MATCH (p:People) WHERE p.name IN ['Andres', 'Peter'] RETURN p"

There's a lot of documentation around MATCH queries here and specific docs on the IN usage for filtering here.
Keep in mind that the class name you give to your model will be used to create a Label on the node that can be used to reduce the amount of nodes that are returned in your subgraph for filtering with WHERE. That's what the People reference in the second query is aimed at accomplishing rather than the first where it finds a node with an index of name but doesn't care about the type of node it's looking for.

@bleib1dj Thanks for the detailed and prompt reply. I have raised a pull request regarding the same https://github.com/robinedwards/neomodel/pull/158
Regarding second query i.e the in list query, I will try to provide a patch for the same soon

@siddharthm, awesome thank you very much for the help :).


How to get HTTP headers in query/mutation?

Can I get HTTP headers or HttpContext inside query/mutation method? It is necessary for authorization.

The HTTPContext is now available through dependency injection or via the IResolverContext. This behaviour will be available with once #177 is merged.

Change is integrated in 0.4.0-preview-2.


Saving file (custom) attributes breaks ckEditor instances in composer form

As descibed in the title there is a bug when we save a  file attribute from withing the composer form (also trough the attributes panel) that breaks all ckEditor Instances in the page. See video.
https://user-images.githubusercontent.com/515153/109429110-651b3980-79fa-11eb-941d-4c51c7e232b0.mp4
In my opinion this is because of the following line : https://github.com/concrete5/concrete5/blob/c605939aac01f04295a574aa587af979e2df207e/concrete/js/build/core/editable-field/container.js#L117 as it destroys all instances of ckEditor. Here we could build a check and destroy only the instance relative to the file attribute.

This is resolved in version 9.

@aembler do i still have time for a PR for version 8.5.5 to be approved? If yes i can invest sometime here in the next 2-3 days.

If it's something you feel strongly about you can submit a PR for the 8.5.x branch; we'll be launching 8.5.5 within two weeks.


AsciiMath/Fopub problem whit white space between word

Hi i have problem whit fopub and asciimath.
Work all good but when i try to add white space between word, is not rendered in pdf:
Example:
I have this file:
= Insiemi Equivalenze Logiche e Definizioni
:stem:
|===
|Insieme |Definizione
| stem:[A nn B]
|  stem:[{ x \ : \ x in A ^^ x in B }]
| stem:[A - B]
|  stem:[{ x \ : \ x in A ^^ x !in B }]
| stem:[bar A]
| stem:[{x \ : \  x in bbb"U" ^^ x  !in A}]
|===
When i preview this code on Mozilla the \ render a white space correctly between semicolon and x:

But when i use fopub for render the pdf \ not work, render this:

Command i use for for convert to docbook xml is this:
asciidoctor -b docbook -a stem insiemi_equivalenze_logiche.adoc
and later execute fopub like this:
fopub insiemi_equivalenze_logiche.xml
How can add white space in pdf usig fopub?
Thanks.

i found the error, when you write \ for give a white space in the document, fopub do not map \ to <mml:mo> </mml:mo> in the xml file.
I'm insert <mml:mo> </mml:mo> this string manually in the xml file generated from fopub and work well.


fix(yaml): changed host path for creating sparse file

changed the hostpath at which sparse file is created by NDM. Now sparse file will be created at /var/openebs/sparse directory. Also, the core-dump will be stored at the same location.
Signed-off-by: Akhil Mohan<EMAIL_ADDRESS>

Codecov Report

Merging #232 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #232   +/-   ##
=======================================
  Coverage   51.44%   51.44%
=======================================
  Files          49       49
  Lines        2255     2255
=======================================
  Hits         1160     1160
  Misses       1006     1006
  Partials       89       89

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4378fb6...7c497ba. Read the comment docs.


sys.socket: Add getpername

Basically a copy of getsockname but s/sock/peer/. Briefly tested.

typo in subject : s/getper/getpeer/

thanks, but it's just the title of a closed pull request, so no matter :-)


exoscale: rename exo into exoscale

A minor nitpick with the exo name and a little addition for the AAAA record (to be future proof).
Thanks for the great work. I'll see if I can get it to work on a minikube.

@greut I think you'll have to do this now :-) https://github.com/kubernetes-incubator/external-dns/blob/master/CONTRIBUTING.md

@FaKod great! time to CLA.

@greut What happened here is, that I rebased my changes to one commit this morning. But you didn't pull them and I merged your branch in mine. So I think we should do that again, to get a clean pull request, ok?

@greut I've made a new branch external-dns-exoscale. Can you reissue your changes there please? (sorry for the noise)


Clipboard content sharing not working in 'Full Graphics' display mode

Describe the issue
Copy-and-paste clipboard content sharing is not working when 'Full Graphics' display mode (under Display tab) is selected. It is working when 'Console Only' display mode is selected. Clipboard sharing was enabled in Sharing tab and the SPICE guest additions were installed.
Configuration

UTM Version: 2.2.4
OS Version: 11.6
Intel or Apple Silicon? Apple M1
Guest OS: Debian 10 ARM

Debug log
debug.log

Did you install the VM with 'Full Graphics' enabled or did you install in 'Console Only' mode?
I have a VM with copy/paste working with Full Graphics, installed with Full Graphics enabled.

With the Debian minimal image nothing is happening when I right click in the VM window in console/graphics modes. In console mode cmd+v is working, but in graphics mode none of the shortcuts (shift+ctrl+v / ctrl+v / cmd+v) are working.

Alright, good to know. I think this is related to #3094

Although my comment does not address the topic of switching a console install to full graphics mode, I did have some luck troubleshooting and resolving clipboard not functioning in an debian (minimal) install.

I was running into the same problem with clipboard not functioning properly in debian 12 (net install/minimal) installed via graphics mode, running i3wm.
It turned out in my case that spice-vdagent was not running.  I've not configured spice in the past, so I expected to sudo systemctl enable spice-vdagent.service, but this errored out.  I opted to launch spice-vdagent via i3wm:
$ grep spice ~/.config/i3/config
exec --no-startup-id spice-vdagent

Now clipboard appears to be functioning.


Minor typo in README.md (example playbook)

In the README.md, the example playbook references the role diodonfrost.omyzsh, which should be diodonfrost.ohmyzsh instead.

Thanks !


Review project infra and licence headers (to match other oss projects) before bringing back frs

@chrisdennis yes I noticed that too... It's a mess ;-) we can choose one and I will go back to the 3 other projects done already to update them.
Now...
Which one ?
@jhouserizer - fyi ;-)


[patch] update packages

update package
Signed-off-by: kpango<EMAIL_ADDRESS>

Codecov Report

Merging #25 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #25   +/-   ##
=======================================
  Coverage   87.13%   87.13%
=======================================
  Files          14       14
  Lines         692      692
=======================================
  Hits          603      603
  Misses         60       60
  Partials       29       29

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8737f1e...cb4e01e. Read the comment docs.


add FMT-ISN for FORMATting instructions

This also changes some (current 1) call site of PRINT-INSTRUCTION to use the new format directive.
This addresses #116.

Thoughts? Too long a name?

I think the name is fine: the package qualifier is nearly as long as the name.

Maybe pprint- isn't really the right prefix. The pprint- functions in the cl package refer to interactions with the pretty printer, and this isn't so. Maybe I'll replace it with fmt-.

Instead of bulk-changing code that has no visible effect, I'm going to suggest we do it piecemeal.

@rigettizach @ecpeterson @notmgsk thoughts on the name? Ideally whatever convention is here should be followed elsewhere.

I like fmt- just fine.

@stylewarning I don't like the abbreviation but I don't think the full expansion is a great name either; FORMAT-INSTRUCTION sounds like something you could call with just an instruction, but the format ~// conventions don't fit with that. INSTRUCTION-STRING likewise.
Since I can't think of anything I like better, the current name is acceptable to me.

@stylewarning I don't like the abbreviation but I don't think the full expansion is a great name either; FORMAT-INSTRUCTION sounds like something you could call with just an instruction, but the format ~// conventions don't fit with that. INSTRUCTION-STRING likewise.
Since I can't think of anything I like better, the current name is acceptable to me.

I in general don't like short names either, but I also don't want 80 character format strings.
What about flipping the order @rigettizach ? {isn, instruction}-fmt?

@stylewarning I think instruction-fmt would be better than fmt-isn.


feat(stage name update for acceptance (review of the application)): Stage name update for Acceptance

Stage name update for Acceptance (Review of the application)

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

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


Singularity limit with long command line calls

Snakemake version
all
Describe the bug
See here: https://github.com/sylabs/singularity/issues/5057. Essentially, Singularity has a hard-coded limit of around 120.000 characters (131072 bytes to store the configuration in JSON format). For pipelines with many files that are aggregated in a rule, this limit can be reached. This is mainly because of using absolute file names rather than relative ones.
Logs
FATAL: Failed to initialize runtime engine: engine "" is not found error
Minimal example
Just construct a rule with >120.000 characters and run it inside a Singularity container
Additional context
Since this limitation is not going to be changed soon according to the reply from the Singularity maintainers (see above), Snakemake should check whether the command exceeds this length and if so, gracefully exit with an informative error message. I am not sure about solutions, though, the only thing that comes into my mind now is to replace absolute by relative paths.

This was addressed in Singularity, I think version 3.7 solves this https://github.com/hpcng/singularity/issues/5057.


ci: add K8S deployment

Description
Add K8S deployment:

add Helm Chart for Server-API with templates

@BOLT04 I don't know if you are familiar with k8s, so please don't review if you are not, but if you want to you can 😅

@magicmatatjahu I'm a bit familiar with Kubernetes, but I've never used Helm 😅
I just have one comment 🙂, is there is a missing quote " here?
- | image.repository | string | `asyncapi/server-api"` |  |
+ | image.repository | string | `"asyncapi/server-api"` |  |

Other than that this PR seems pretty cool, I only saw the event-gateway repo with these Helm definitions too so it would be cool if @smoya could also take a look 👍

There is one thing it is not clear to me within this PR context.
Is this chart supposed to be used by users or rather the one used for deploying api.asyncapi.com (or whatever name we choose) ? Because values.yaml might be different on each

@smoya

Is this chart supposed to be used by users or rather the one used for deploying api.asyncapi.com (or whatever name we choose) ? Because values.yaml might be different on each

You should be able to deploy on your machines :) Of course we will use these templates for api.asyncapi.com but primary it is for community.

This looks great 👍, I think we can merge this @magicmatatjahu  🚀

@BOLT04 Thanks but we need to wait for that PR https://github.com/asyncapi/.github/pull/117 and then for Docker Image in another PR in this repo :) I wanna first deploy app with image to check that everything work as expected :) I hope that it will be tomorrow.

@smoya @BOLT04 I improved templates by adding to every resource the namespace. I think that we can merge it. Also, important thing: should we go with ci (or chore) prefix for PR's title? It's not related with source code but with infra and infra prefix isn't allowed and also I don't want release new version of package, or we should, WDYT?

@smoya @BOLT04 I improved templates by adding to every resource the namespace. I think that we can merge it. Also, important thing: should we go with ci (or chore) prefix for PR's title? It's not related with source code but with infra and infra prefix isn't allowed and also I don't want release new version of package, or we should, WDYT?

I think ci works in this case.

@smoya Hello! I added in the last commit the Ingress resource :)


timer trigger reference article 404 Not Found

The link for timer trigger reference article gives a 404 Not Found.

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

ID: 2b7b9f5c-4610-8cea-28d4-fea8ea03e7e1
Version Independent ID: cc09b46d-cd40-45e8-ed45-7a0e3bf4b100
Content: Develop and deploy WebJobs using Visual Studio - Azure
Content Source: articles/app-service/webjobs-dotnet-deploy-vs.md
Service: app-service
GitHub Login: @ggailey777
Microsoft Alias: glenga;david.ebbo;suwatch;pbatum;naren.soni

@eshudnow, Thanks for bringing this to our attention. We are taking a look into this and will get back to you soon.

The hyperlink for ‘timer trigger reference article’ points to the Azure doc “Timer trigger for Azure Functions” > ‘CRON expressions’ section and works fine now. Could you please take a look and confirm? Kindly do let us know if you need further assistance with this.

It appears to be resolved.  Thank you.

@ElanShudnow, We will close this out, but if you feel you need more information on this topic please just let us know. Thanks again for sharing your feedback.


Update Handlebars dependency to version 4

Handlebars < 4.0 shipped with a version of uglify-js that has some issues. Upgrading to 4 brings in a fixed version of uglify-js.

I'm actually holding off from doing this on purpose as there's a breaking change in 4 that I haven't properly thought through the consequences of yet.
Instead, I'm going to be pushing a few changes back to the v3 branch of handlebars short term, publish a new version of express-hbs to use that, then also do v4.
S'been on my todo list for the past week, will try to get to it asap!

a few changes back

For clarity, there's a fix for a vulnerability in handlebars + the need to update uglify-js

Awesome--will close this.
Out of curiosity, what's the breaking change? The tests pass and nothing really jumped out of from changelog from v3 -> v4.

Ha, it's actually a change I requested (and am very happy about) however it is gonna cause weird bugs in old themes for sure: https://github.com/wycats/handlebars.js/issues/1028
From the 4.0 compat notes:

Depthed paths are now conditionally pushed on to the stack. If the helper uses the same context, then a new stack is not created. This leads to behavior that better matches expectations for helpers like if that do not seem to alter the context. Any instances of ../ in templates will need to be checked for the correct behavior under 4.0.0. In general templates will either reduce the number of ../ instances or leave them as is. See #1028.

I think it's very likely that this will affect very few people, because it was easier to workaround this weirdness than to understand and use it in templates. Casper has some inconsistencies between the author.hbs and tag.hbs templates which I have never cleaned up for this exact reason.
However, I figure it's safer to update v3 to be safe for now, and then do a bit of data mining on popular themes to see if any of them are affected before making the breaking change, possibly as the part of the 0.8 release for ghost. That also gives anyone else depending on express-hbs the same opportunity = a secure upgrade and then a breaking one.

Turns out trying to publish a security fix to v3 of handlebars is not easy enough to warrant doing it - can you reopen this?

I didn't expect it to come back so I deleted the branch. I opened a new PR #92.


Add an MIT LICENSE file for clarity

This adds an MIT LICENSE file for licensing clarity. (Just like in pierrec/js-xxhash#12.) MIT is already specified in the README and package.json, but having a file like this makes it easier.
Thanks for sharing this project!

Thanks.


[Dubbo-4793]make RegistryDirectory can refresh the invokers when providers number become 0 when using nacos registry

What is the purpose of the change
fix #4793
Brief changelog
NacosRegistry.java
1.fix issue 4793, add toUrlWithEmpty emthod like ZookeeperRegistry.java, when the provider number become 0, generate an url with empty protocol.

createInstance method: delete useless code

Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #4802 into master will increase coverage by 0.02%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##             master    #4802      +/-   ##
============================================
+ Coverage      63.9%   63.93%   +0.02%
  Complexity      451      451
============================================
  Files           769      769
  Lines         33171    33177       +6
  Branches       5229     5232       +3
============================================
+ Hits          21199    21212      +13
+ Misses         9551     9539      -12
- Partials       2421     2426       +5

Impacted Files
Coverage Δ
Complexity Δ

...org/apache/dubbo/registry/nacos/NacosRegistry.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...onfig/spring/extension/SpringExtensionFactory.java
80.48% <0%> (-4.88%)
0% <0%> (ø)

.../apache/dubbo/remoting/transport/AbstractPeer.java
63.04% <0%> (-2.18%)
0% <0%> (ø)

.../dubbo/remoting/transport/netty4/NettyChannel.java
64.7% <0%> (-1.18%)
0% <0%> (ø)

...pache/dubbo/remoting/transport/AbstractServer.java
47.91% <0%> (-1.05%)
0% <0%> (ø)

.../java/org/apache/dubbo/config/ReferenceConfig.java
60.94% <0%> (+0.36%)
0% <0%> (ø)
:arrow_down:

.../rpc/protocol/dubbo/LazyConnectExchangeClient.java
58.82% <0%> (+2.35%)
0% <0%> (ø)
:arrow_down:

...pache/dubbo/registry/support/AbstractRegistry.java
81.6% <0%> (+3.06%)
0% <0%> (ø)
:arrow_down:

.../apache/dubbo/qos/protocol/QosProtocolWrapper.java
82.92% <0%> (+17.07%)
0% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 897709b...9925f7c. Read the comment docs.

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


MINOR: fix deprecation warnings

Updated this. @vvcephei @cpettitt-confluent

Updated this again. Hope it's ok now. @vvcephei @cpettitt-confluent


htu url in DPoP payload contains query parameters and fragments

Hi,
When trying to send the authorization to an url that contains query params the DPoP verification fails with the following message:
[DPoPWebIdExtractor] {Primary} warn: Error verifying WebID via DPoP-bound access token: The DPoP proof htu parameter must be the HTTP request URI without query and fragment parts.
As far as I understand, the htu url is not allowed to contain any query or fragment parts as defined in RFC 9449 section 4.2 .
I noticed that the request url just gets handed through until create_dpop_header in dpop_utils.py. I think it would make sense to remove the query parts there.
Something like this:
def create_dpop_header(url: str, method: str, key: jwk.JWK) -> str:
    updated_url = urlsplit(url)._replace(query=None, fragment=None).geturl()
    payload = {
        "htu": updated_url,
    ...

Hi, thank you for the detailed suggestion!
I used your code suggestion and applied it here (changing None to an empty string, because the type system required a str): https://github.com/Otto-AA/solid-client-credentials-py/commit/e208e4eba414ba24e4d5fee8757a0eeda02f8c14
The added test case succeeds when removing the query and fails when keeping the query, so it looks good. If you want, you can test it before I publish the package.
I would try to make a new version next week and publish it to pypi.

Hi,
thanks for the fast response and sorry that I took so long to answer.
It looks fine to me and I am looking forward to the next version.

No worries :)
It should work now with v1.0.2


Passing by reference to COM object

I’m trying to access a com object written in C in python script in Dynamo which uses IronPython. I have successfully managed to load the com object and the function calls seem to work (no errors or exceptions) but when I use the functions with parameters passed by reference, I only ever get zero returned:
t = System.Type.GetTypeFromProgID("myComObject")
o = System.Activator.CreateInstance(t)
o.Open("afile") <==the com object needs to open a file to be of use
aNumber=0
o.GetAValue(0,aNumber);
The signature of the GetAValue function is defined as:
short GetAValue(short value1, short* value2)
The return value indicating success (always zero) and the second parameter being the value i’m interested in.
aNumber is always zero. The exact same script (with only changing the functions to load the com object) when ran using spyder using python 3.6 works just fine and I get a non zero value returned as expected.
I have asked the developers of the com object to confirm that the functions are being called as expected when called from IronPython. They have debugged the code and have proved that the value is being passed in and set to a non-zero value BUT when it the function returns back to the script, it is being set back to a default value. We have both independently tried passing the value by clr reference and this just throws an error.
s= clr.Referenceint
o.GetAValue (0,s)
ValueError: Could not convert argument 0 for call to GetAValue
Is this a bug in the way it is passing ref parameters?

Have you tried matching the data type?
s = clr.Reference[System.Int16]()
o.GetAValue(0,s)

It's entirely possible there's is a bug...

that’s solved it.  Thanks a lot.
From: slozier<EMAIL_ADDRESS>Sent: 02 September 2020 14:46
To: IronLanguages/ironpython2<EMAIL_ADDRESS>Cc: Tim Rutter<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: [External] Re: [IronLanguages/ironpython2] Passing by reference to COM object (#737)
Have you tried matching the data type?
s = clr.ReferenceSystem.Int16
o.GetAValue(0,s)
It's entirely possible there's is a bug...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/101Jqz-T6k9xAIyvUUOraKWgzNUFuA8hzl4rfPGesK4Nw8rqYeTXmIhYIkKaAPljyNy7crbrIDc2jmu5gh1tS9DGoO8Ntxgk48sBjmXrqafzGVL1JniISvPB6LQ3sErfafVCExXeqSJaMtHwZagoMZhYgY3Ve88-Q6le4VEjokmKMrZtck5V3Zu31yO1KQB-mtosJGDNc35xR1N0W9qn9oASgHcv4mUtzpWbq1QI5TsvCYx5fW4RIU2WXlOjbP3f258f-raxkJTl7D95jQOjPe3DyiS_qCC8tk047d3wpuIChaR5JKJDwB1i0WfDAaOA8tqj66HJx1HGuXhuxOkiGkA/https%3A%2F%2Fgithub.com%2FIronLanguages%2Fironpython2%2Fissues%2F737%23issuecomment-685747953, or unsubscribehttps://secure-web.cisco.com/1wFEBi7ZTuAQCMbXbWqNNUABJ59BB5Lthtt68sppk-8FQn7PFRVwh9pex9RNfhko9pndwg4DzoHR2YesH4H9YqW4vGRBnehbpYHFAcKYC2o9SflaAst9FtJTsjlPWLGv5VZqSq0jqLsNPfg37Trc9xz8Iz_iDrAzRfjn8TzrPntTVX_2g96dv6nBo4yF6tH6NjqnN9jpf4Y3aasMFWe2F_cWM93vV1SgfjF_GRfK0JhVF4qBoyb0WZOGkjuNW3mq1sZZ6Wd3nPv6mMlGa1nQh8RVw4apPAigrV1HTG7lwv0HF4SRJPlxgH7yuXhL77yZECdE0ZQJAn5mJHkoXG_Pc8A/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMIFQ3AMIT24CTGOCVBRBG3SDZECBANCNFSM4QS4LOZQ.

Electronic mail messages entering and leaving Arup business systems are scanned for viruses and acceptability of content.


When browser is zoomed or on high-DPI screens, onRowsRendered fires twice with an incorrect startIndex when scrolling via scrollToIndex

This Code Sandbox project demonstrates the issue.
I've been working on a Chrome extension that uses a <List> component to render a few hundred items.  The user can press Pg Up or Pg Down to move the selection a screen at a time, which scrolls the next selected row into view (if needed) by setting the List's scrollToIndex prop.
After developing it on a standard DPI laptop and monitor, I recently tested it on a Windows 10 laptop with a 4K screen, where the UI is scaled to 250% in the display settings.  I noticed that when paging up the list after paging down, it scrolls one row too far, which never happened on the standard DPI screen.
In the code example above, the list is exactly the height of 5 rows.  Open the console to see the indices returned by onRowsRendered.
If you scroll the list so that an odd-numbered item is partially visible at the bottom of the list, such as Item 7, then onRowsRendered will report 2 as the startIndex and 7 as the stopIndex, since 4 whole rows and 2 partial rows are visible at this point.  If you then click the Down button, Item 7 will scroll fully into view and become selected, and Item 3 will be visible at the top of the list.
If you do this on a normal resolution screen, onRowsRendered will correctly report the indices as 3 and 7 after you click Down.  But if you do the same thing on a screen scaled at something other than a whole multiple of 100%, then onRowsRendered fires twice, first with 3 and 7 and then again with 2 and 7.  The latter event is wrong, since after scrolling Item 7 fully into view, Item 2 is no longer visible.  If you then click the Up button, it scrolls too far and shows Item 2, since the component is relying on onRowsRendered to track which rows are currently visible.
I've also seen the same behavior on a 4K desktop monitor with Windows 10 scaled to 175%.  Changing that to 200% seems to make the extra, incorrect onRowsRendered event go away.  I haven't had a chance to try it on a Mac with a Retina screen.
This issue seems like it may be due to a rounding error somewhere, though I don't know why it would cause onRowsRendered to fire twice.  For instance, if you change the RowHeight to 44 instead of 45, it doesn't happen, nor if you change the number of visible rows to 4 instead of 5 (4 * 45 = 180 vs. 5 * 45 = 225).
Test environment:

Windows 10
Chrome 64
React 15.6.2 in the extension, 16.0.0 in the Code Sandbox
React Virtualized 9.9.0 and 9.18.5

Bugfix PR welcome.
I doubt I'll have any time to look into this.

I looked at the issue and found that when browser zoom level is not 100%, setting scrollTop to X might not result in scrollTop = X.
I put break point at this line and tried to set the scrollTop.
This is the result:
this._scrollingContainer.scrollTop = 25;
console.log(this._scrollingContainer.scrollTop); // 24.44444465637207
This causes the actual scrollTop and scrollLeft to be different from the state.
Thus, when the handleScrollEvent function is called after scrollTop or scrollLeft are set, the check here fails to prevent the re-render.
I'm trying to fix the issue by adding new variables for actual scroll values but this approach made "should not re-render grid components if they extend PureComponent" test fail.

@prachp , thanks for investigating.  I first saw the issue on a high-DPI screen with a scaled UI, where the browser zoom was at 100%.  But you're right, the same thing happens if the browser itself is zoomed, so this is probably a more widespread issue.
I just tried it in Chrome on Win7 with normal 100% UI-scaling, but I zoomed the codesandbox posted above to 110%, and onRowsRendered fired twice, the second time with incorrect values.
I haven't looked into the React Virtualized code enough to have a useful opinion, but synching up the state and the actual scroll offsets seems like a reasonable approach.

Hi @fwextensions - did you found any solution for this issue?


Add error message for invalid task status

Pull Request
Related issue
Fixes #2940
What does this PR do?

Makes Meilisearch show a correct error message for invalid task status as this page shows

PR checklist
Please check if your PR fulfills the following requirements:

[x] Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
[x] Have you read the contributing guidelines?
[x] Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Hello @shogohida
Thanks for the PR!
Is your PR finished? I see you opened a draft PR and not a "ready to review" one. Let us know when yo have finished
Also, I see there is an issue with the Rustfmt test, can you fix this?
Thanks for your contribution 🙏

bors try

@curquiza
Thanks for your comment! I fixed the issue of Rustfmt so I decided to open the pull request.
As I commented here, I'm still stuck to get a correct error message... I haven't written any tests yet due to that.
It seems it's because ResponseError is used to generate the message here even though I want to use just Code and ErrorCode.
I would really appreciate your review and help 🙏

Maybe @ManyTheFish can help you on this? 😊

Hello @shogohida, it seems that the message actually generated comes from https://github.com/meilisearch/meilisearch/blob/fcedce8578ca9dfa5366485b4eb87070199821c4/meilisearch-http/src/task.rs#L49-L52, you should probably start your investigation from here.

@ManyTheFish
Thanks for your comment!
Well, I knew the message comes from the point you mentioned. I already changed the message for invalid_task_status.
https://github.com/meilisearch/meilisearch/pull/2948/files#diff-21e50aae04d9a49b84a561124faf0389e9fa35d0d366f8616c95def5298faebfR97-R98
I get the message like this and haven't been able to show "invalid_task_type" for "code" and "link"

Hello @shogohida, I don't understand, why don't you modify the error at line 49 instead of the error at line 103?

Closing this issue due to lack of answers. Plus, we decided to implement this on our side, to avoid losing more time. We need this fix for v0.30.0.
Thanks anyway for your work! 😄

@curquiza
I'm so sorry for not responding 🙇 I couldn't implement this myself so I will see your implementation to see how close my implementation was and which parts were wrong.
Thanks for your message! Hope to contribute to another issue in the future 👍

No problem @shogohida, you made your best, and we found out the issue was not that easy! It's completely normal you don't have the time for this, don't worry. Of course you are more than welcome to come back contributing 😄

Merci! I look forward to seeing the correct code!


Update usage.mdx

Suggested text and images updates for Progress bar. Addresses some of the issues identified in the accessibility review of the component.

BTW, @aagonzales, there's a Loading: skeleton states link at the bottom that is a 404. I couldn't figure out what it was supposed to be pointing at. I also wasn't sure why it was broken out in a second Components list.

Adding @thyhmdo as a reviewer since she is closest to this information.

This is probably the correct link to loading skeleton states: https://carbondesignsystem.com/patterns/loading-pattern/#skeleton-states

This PR has been displaced by https://github.com/carbon-design-system/carbon-website/pull/2978


[Fix] batched_nms using proper box score values

In the  bbox_nms the box classes valid_cls were provided to batched_nms instead of box scores valid_con

Problem example
import torch
from torchvision.ops import batched_nms # type: ignore
valid_box = torch.Tensor([[10,10,20,20],[12,12,22,21]])
valid_con =torch.Tensor([0.3, 0.9])
batch_idx = torch.Tensor([0,0])
valid_cls = torch.Tensor([1,1])
rez_con = batched_nms(valid_box,valid_con,batch_idx, 0.5)
rez_cls = batched_nms(valid_box,valid_cls,batch_idx, 0.5)
print(rez_con, rez_cls) # rez_con = 1 rez_cls = 0
valid_con_reversed = torch.Tensor([0.9,0.3])
rez_con = batched_nms(valid_box,valid_con_reversed,batch_idx, 0.5)
rez_cls = batched_nms(valid_box,valid_cls,batch_idx, 0.5)
print(rez_con, rez_cls) # rez_con = 0 rez_cls = 0
different results obtained because of valid_box box order

Hi,
I believe this issue has already been fixed in PR #76. However, the DEPLOY branch hasn't been merged into the main branch yet. It will be merged later.
Best regards,
Henry Tsui

Yes you are right. I'll close the pull request.


[WIP] Add a way for worker subclasses to handle settings changes

part of https://github.com/ManageIQ/manageiq/issues/21992
Non-rails workers get their settings via STDIN on startup.  This means there is no easy way to "reload" the worker settings after startup.  As settings don't change that frequently we can just restart the worker if settings have changed.
TODO:

[ ] Use Vmdb::Settings.changes or diff_to_deltas and compare with worker_settings_paths to see if any settings that the worker cares about changed

This may require only passing a subset of setting to the worker...that way we only need the reload if the settings that matter change.  Is there a separate issue for sending less settings?

This may require only passing a subset of setting to the worker...that way we only need the reload if the settings that matter change. Is there a separate issue for sending less settings?

Not specifically for reducing the settings sent to the worker, I was thinking restarting on any settings change will cover 100% of the cases and settings don't change that frequently.  We can follow-up with scoping the settings a worker cares about per-worker to improve the performance and reduce the times a worker is restarted needlessly.

Closing, superseded by https://github.com/ManageIQ/manageiq/pull/22329