no more possible to force accepting a transfer

With beta 5 it was possible to accept a transfer with the force boolean, with beta 6 this possibility has been removed. @dr-orlovsky I don't recall this being communicated or discussed. This breaks our Lightning Network node so please re-introduce this ASAP (to be included in the next beta release).

This was not intentional. Can you provide a specific information which function signature is mot there anymore?

During this commit range
git log --oneline add376c^..813bbcb

813bbcb containers: better differentiate Contract and Transfer types
8904684 persistence: impl display for consignments
24a4290 persistence: expose more methods
7f25ac1 persistence: expose type system in builder
705ea62 persistence: expose missed methods
10c4944 persistence: add debug getters for memory types
30a6b65 persistence: make load/store trait-based and generic
5159f80 persistence: implement file load/save operations
8183ba6 persistence: improve Stock error convertors
ef0df69 persistence: always resolve to mempool in fascia
aa75a57 persistence: return validation status from Stock::consume_consignment
5e0128d persistence: default implementations
43e1040 persistence: fix stock module
9251967 iface: bring back amount change
8814cf3 resolvers: relax Error trait requirements
f96f418 containers: remove outdated tests
2a8b656 persistence: provide default generics for Stock
add376c persistence: completed index, state and stock refactoring

the accept_transfer method has been removed (in add376c) and then re-added (in 813bbcb), but when it has been re-added its force boolean parameter has been dropped.

Ok, I see now: the new methods take ValidConsignment (or ValidTransfer) and thus do not need force argument, since they do not try to validate anyway - there is nothing to force. And there should be unsafe method assume_valid to convert any consignment into valid version if needed

there should be unsafe method assume_valid to convert any consignment into valid version if needed

I have looked into the code but couldn't find the assume_valid method. Can you be more specific, please?

Sorry, when answering to the issue I was on BTC Prague and answered from the phone with no ability to check.
I recall I had an intention to do such method, but I was not able to find it in the standard library. So I just made one: https://github.com/RGB-WG/rgb-std/pull/221

I tried to use the new assume_valid method added in #221 to restore the force functionality when accepting a transfer but I cannot do so successfully in rgb-lightning-node, in the context of a LN channel opening.
The issue is that consume_consignment fails when calling create_or_update_state > resolve_height, as the witness anchor has not been broadcast yet, so it can't find it (which is expected).
To me this means that assume_valid might be a way to forcefully validate a consignment, but it's not enough to force the consuming of such a consignment.

I've tried the assume_valid method, which fixes the initial issue (i.e. unable to call accept_transfer because I was unable to retrieve a ValidConsignment). I totally agree with Nicola that the method should not be unsafe though. unsafe should not be misused, it should be used only when the compiler needs it because of usage of unsafe Rust. In this case we are not doing anything that's unsafe for the operating system (like for example accessing memory manually), so we should definetely drop it.
After using assume_valid I've investigated the new behavior reported by Nicola and I've noticed an error in the electrum resolver. I've fixed the issue in https://github.com/RGB-WG/rgb/pull/214. After the merge of that PR and the fix and merge of https://github.com/RGB-WG/rgb-std/pull/221 I think we can close this issue.

I had a discussion with @nicbus in chat where I explained to him why accepting unverified consignment in funding channel is a security vulnerability and must not be done. The plan that he would discuss
By all means this method is unsafe in terms of type safety and I am for closing #221 without merging: the method is not needed.

That discussion led to us checking the behavior of the resolver when accepting a transfer and that's how we discovered that an electrum resolver refactor introduced a bug where it would panic when a transaction was not found, instead of returning it as Offchain. After fixing that, the assume_valid method proved to be correct (with some caveats we're already discussing).
Let's look at an example of what we're doing:

validating the consignment
checking that the only failures we get are UnresolvedTransactions for the expected transaction
once it's passed validation, we call assume_valid to get a ValidConsignment
we call accept_transfer with that consignment

So the method is needed and does not pose any additional risks compared to other cases where it's not used, not even RGB type safety.

My point is that even if you do not misuse the method, others may misuse it. It is wrong to ship a library with a method which can be easily misused creating security vulnerability.

That's not the case. Anyone can modify the code to produce a ValidConsignment anytime. Security doesn't come from the absence of methods to achieve what's needed in some cases.
Moreover this can be mitigated with good documentation. For example, rust-bitcoin has an assume_checked method (https://docs.rs/bitcoin/latest/bitcoin/address/struct.Address.html#method.assume_checked) which if improperly used (to bypass address network validation) could lead to loss of funds. But still, the method could make sense in some special cases, therefore it has been provided and documented as "potentially risky".

What I would recommend is just do a dedicated resolver wrapping the electrum resolver, name it RlnResolver or something, and let it return the funding transaction to the validator, so you would have ValidConsignment in a natural way, instead of hacking into types with assume_valid footgun.

This approach is cumbersome and doesn't add any security, as the reality is that the transaction has not been broadcast and there can be no guarantee that the exact same transaction would be broadcast in the future. Validating the consignment using "fake" data provided by a modified resolver doesn't improve anything.

@dr-orlovsky did I understood correctly that your main objection here is that some users may misuse the method? If so it doesn't seem to be a strong motivation as good documentation should prevent mistakes from the users. If we were to apply the same logic everywhere we would probably find a lot of other ways in which a user can misuse an RGB library.

Well, it is not just a misuse, it is (1) there is no single reason for this method to exist and (2) if it exists it opens a direct security vulnerability.
From what I understood this method is not needed for RGB LN node - and if it is still needed it means it has a security issue. Under no circumstances an unvalidated consignment should be accepted (the only exception is penetration testing).

Well, it is not just a misuse, it is (1) there is no single reason for this method to exist and (2) if it exists it opens a direct security vulnerability.

This method is needed, as already explained:

in LN, when opening a channel, it's essential to create, exchange and verify signatures for the commitment transactions before broadcasting the funding transaction
in order to create the commitment transactions funding transaction/transfer needs to have been accepted (since the funding UTXO is the input of the commitment TXs)
there's no other (good) way to accept a transfer for an off-chain transaction

It doesn't open any security vulnerability, as already explained:

security doesn't come from the absence of this method, as it can always be added by a user (e.g. an rgb-std fork) to carry out an attack
security needs to be there in spite of this code existing
this issue and the related PR constitute documentation for a user on how to do this, so it's really easy for anyone
this can be implemented by anyone even without forking rgb-std using unsafe rust, which would actually be bad
if done properly, the consignment gets correctly validated, so validation is not skipped but just some specific and expected errors are ignored
having it, well documented, is better than having users come up with a custom solution, potentially more risky than this method

From what I understood this method is not needed for RGB LN node - and if it is still needed it means the node has a security issue. Under no circumstances an unvalidated consignment should be accepted (the only exception is penetration testing).

It seems like your understanding is that it's not needed because the same effect can be achieved by using a custom resolver that provides fake transaction data. This is not different from having this method and changes nothing on the security side. Using a custom resolver is just another way to force the consignment validation to succeed.
From my understanding of the matter, I conclude that:

the assume_valid method is the simplest way to achieve what's needed (accept a transfer for a transaction that's not been broadcast yet)
it has no downsides compared to alternatives
alternatives are:

using a custom resolver to provide fake data and have validation pass
modify accept_transfer, re-introducing the previous functionality, but this would mean refactoring the validation as well (it now takes a ValidConsignment)

I'm against using a custom resolver as it's the most cumbersome approach and requires the user to do a lot of unneeded work, for no gain
I'm against changing accept_transfer as it means heavily refactoring the code (again) for no real gain

It seems like your understanding is that it's not needed because the same effect can be achieved by using a custom resolver that provides fake transaction data.

Yes. That is the only right and secure method of doing it.

This is not different from having this method and changes nothing on the security side.

No it does. Your arguments are superficial:

security doesn't come from the absence of this method, as it can always be added by a user (e.g. an rgb-std fork) to carry out an attack

First, this is not about performing an attack, but about footguns for the users of this library. Second, by the same logic you can add any hacky function to secp245k1 as well, saying otherwise it will be added anyway just by forking the library

this can be implemented by anyone even without forking rgb-std using unsafe rust, which would actually be bad

There is a difference between "footgunny API" which can be simply misused (and docs do not protect from that) and a well-aware unsafe rust with pointers etc.
I can just merge this PR or add any other hacky function you need to the system, but I do believe this is a very bad practice.
If you insist, you can disregard my opinion and merge this PR by yourselves - I will give you the rights to do that. But again, my experience of working with Blockstream team on libraries like rust-bitcoin says that better not to do that: never replace a proper API with hacks in the security-critical code just for the sake of simplicity.

I think it's ok to have the assume_valid method included, restoring the functionality that's been lost from accept_transfer, so I'll take your offer and ask you to allow the merge of #221 (I don't have the permissions). We can have a discussion on how to improve matters separately if needed.

restoring the functionality that's been lost from accept_transfer

For the history record, it wasn't "lost functionality", it was "removed bug"
@nicbus I have added you to the maintainers, it should work for you now and you should be able to merge. I pushed commit 63c3f5d0e00f9a7c516f170b7af9dc5d1005093e so you can merge the PR as is. In any way, please keep my comment there

@nicbus I have added you to the maintainers, it should work for you now and you should be able to merge. I pushed commit 63c3f5d so you can merge the PR as is. In any way, please keep my comment there

Thanks for that. Anyway I won't be merging that PR, see my comment there.
As a recap, after we had discussions elsewhere, this is no more an issue as the solution provided in https://github.com/RGB-WG/rgb-std/pull/233 is a much better alternative and has already been confirmed to work as intended, so I'm closing this.


V1 endpoint support in MSAL JS - verify endpoint checks

Ensure V1 .well-known/openid-configuration is called for all V1 requests in MSAL JS

Address this before closing #844

@sameerag  any updates on this


Disable groovy condition caching for policy evaluation if superseded…

…by decision caching.

@anubhavi25, I implemented requested changes.  Please merge if approved.


[Feature Request] Invalid Action Mask

it would be very useful to be able to adjust the gradient based on a binary vector of which outputs you want to be considered when computing the gradient.
This would be insanely helpful when dealing with environments where the number of actions is dependent on the observation. A simple example of this would be in StarCraft. At the beginning of a game, not every action is valid.

Hello,
How would you implement that?

which outputs you want to be considered when computing the gradient.

I think I only understand partially your idea. The high-level idea is clear (prevent from taking invalid action) but the technical details are not for me.

Related: https://github.com/hill-a/stable-baselines/issues/212

I am not entirely sure myself. You could call tf.stop_gradients on the weights of the last layer that go to each output you don't want considered, but I don't see a way to do it for the deeper layers as you go backwards.
A simpler approach would be adding an optional argument on .step() for a binary vector of which actions to consider.

I hacked this for a little bit and figured out how to do it. I made a new tf tensor that is the masking vector. I then multiply where appropriate in common/distriubtions.py.
The scope of this tensor is rather buried away from a user perspective (in common/policies). I cheated and used a global to access the mask vector created by the environment in the policy; I am not by any means familiar with this code base, but if this feature is desired, I could work with someone to make a PR.

I just found a similar idea, but that only does masking, no use of tf.stop_gradient in this repo:
https://github.com/calclavia/NOS

I hacked this for a little bit and figured out how to do it.

It runs, but does it actually work?

It works fine. I've been doing this for two-ish years with my own implementation of A3C.

Do you have a minimal example on how you made it work?
I'm afraid this would require a lot of changes if we include that in the codebase. However, if it is no so hard to integrate in a custom version, I would like to have it in the documentation ;) (dealing with invalid actions seems to be often a problem with games).

I made a tf placeholder and in feed, I accessed the valid actions from a global variable, which obviously isn't a real solution.
 RL is getting applied to more and more things everyday it seems, and this feature would be very valuable for many.
In PySC2, they embed this information within the observation. Maybe allow environments to allow returning a dict observation (lots of change on your end), or allow environments to have a function that tells you the valid actions, and if it is implemented, use the mask vector and apply it?
Both require some recoding of various areas, but the second one does not introduce a possible breaking update that would cause old environments to no longer work.

I accessed the valid actions from a global variable
aybe allow environments to allow returning a dict observation (lots of change on your end),

It already exists, this is called the info dict ;) (returned when calling env.step(), one caveat: it is not present at reset)

That's awesome to hear. Would you consider adding the feature if I made a PR?

Would you consider adding the feature if I made a PR?

as I told you, it really depends on the amount of complexity it adds. Do you have a branch where you made the changes?
But I would like to have it documented anyway, this could be really helpful to others ;)

Really the only changes that are needed are creating a 1D tensor of all ones, then at each step, check to see if info dict contains something like "valid_actions", assign it to the tensor, then in common/distributions.py, apply the masking tensor to the various functions for each distribution.
I do not know what is considered "standard" when computing negative log likelihood with masked actions. Do you only take the softmax of the valid actions? I don't think any literature exists on this topic, unfortunately.

apply the masking tensor to the various functions for each distribution.

Only for the discrete distribution (and derivates), no?

Do you only take the softmax of the valid actions?

You can apply the mask before or after the softmax. In both cases, the loss will only affect the taken action, no? (so invalid actions won't be affected)

Only for the discrete distribution (and [derivatives]), no?

Yeah

You can apply the mask before or after the softmax. In both cases, the loss will only affect the taken action, no? (so invalid actions won't be affected)

Wouldn't applying the masking before vs after the softmax influence the gradient computed when trying to minimize the negative log likelihood?

Wouldn't applying the masking before vs after the softmax influence the gradient computed when trying to minimize the negative log likelihood?

You are right. I think we need to write that done or test it to see if there is a huge difference in doing one way or the other.

I have a gut feeling that if you apply the mask before the softmax, gradients may explode (and possibly become inf). Testing is required for sure.

Replying to your email:

so I figured I'd email you as to not clutter up issue#351 on hill-a/stable-baselines.

That's not a problem to have a long discussion in the issue. I prefer this way so everybody (especially the other maintainers) know about it.

I am confused on how to set up the dict that created in _train_step (I
am working with PPO2 to start, function begins at line 247).

Yes, PPO2 seems like a good starting point.

My question is: I have a placeholder for the action mask, sized
(n_batch, ac_space.n), somewhat following suite with the action_ph, but
I cannot get a forward to pass to work, because the the action_mask at
runtime is just shape ac_space.n, but when I remove the batch size dim,
the dimensions don't match when actually training.

I am rather lost at untangling this problem, any insight would be helpful.

It seems like you would need some broadcasting.
In numpy this would look like that:

import numpy as np

# n_batch = 10
actions = np.ones((10, 2))

# Only the second action is valid
# mask has shape (,2)
mask = np.array([0, 1])

# Element wise multiplication
print(actions * mask)

And in tensorflow:
import tensorflow as tf
import numpy as np

actions = tf.placeholder(shape=(None, 2), dtype=tf.float32)
masks = tf.placeholder(shape=(2,), dtype=tf.float32)
masked_actions = actions * masks

sess = tf.Session()
sess.run(tf.global_variables_initializer())
sess.run([masked_actions], feed_dict={actions: np.ones((10, 2)), masks: np.array([1.0, 0.0])})

To start, the action_mask_ph is currently in the BasePolicy class, is
that appropriate?

It seems ok.

I have this working using the info dict to store the Boolean vector. I use tf.boolean_mask to apply it. Id like to test this on my environments beyond my custom gym environment to figure out where the best location to apply the mask with respect to the softmax activation (before or after). Going to clean up for stuff then push it to a fork. Do you want me to submit a pr with just PPO, have it reviewed, then add others? Or would you prefer to wait to review it until after each algorithm has the feature?

We've encountered a similar issue while setting up our custom environment. It would be really helpful if you could outline your final plan in more detail, or post some code while you're getting it ready for a PR. We've got limited time - the internship ends soon! Thanks!

I have been busy with two paper deadlines that are in the week, so I haven't been able to get everything ready for a PR in the timeline that I wanted. It is ready for PPO, which i just uploaded here for your sake: https://github.com/H-Park/stable-baselines/commit/6107ef4a260f824506622669fa530dff1865552b
Note: this will not work for anything other than PPO.
Usage guideline:
return obs, reward, done, {'valid_actions': valid_actions}
where valid_actions is a binary vector

Thank you so much! We've been pouring over this issue thread trying to reconstruct what you suggested.

You said that if this feature didn't add too much complexity it'd get merged. Is this too much overhead?

I don't have much time now to look closely (will be AFK for some weeks) but at least finish and polish what you did with PPO2 because anyway we will put a link to your fork (in the best case, we'll merge your PR ;)) in the documentation if it is too much changes.
I did a very quick pass, some one remark:

a solution to remove the try except (which I did not like much) and to simplify the code would be to always use a valid action mask but setting it to ones by default.

I have mostly everything working (and removed the try/catch blocks), except one set of unit tests. In the distribution tests in test/test_distri.py, due to my addition of a tensor ("action_mask_ph"), causes the test to fail because this test does not instantiate an actor/critic model.
I am not entirely sure how to solve this while still keeping the unit test simple. Thoughts?

This would be extremely usefull!

I redid my changes and moved them to the actual policy, which removes the tensor look up by name in common/distributions.py, of which I was never a fan. The implementation requires that the action space be from [0, n], as the mask is just an element-wise multiplication. There is no way to use tf.boolean_mask on an element by element basis. While tf.ragged.boolean_mask exists, it returns a ragged tensor, which is not a valid datatype for the operations in common/distributions. The code is a lot cleaner now, but there is a lot of repeated code across algorithms, but that seems to be common for general data handling.

@H-Park I'm back ;)
Could you open a draft PR so it will be easier to take a look at what you did?

but there is a lot of repeated code across algorithms, but that seems to be common for general data handling.

Unfortunately, we cannot avoid that for some part of the code (this is a trade-off between ease of use for the user and modularity)

Although we have not yet discussed the correct solution, we offer another solution for the transition period.
https://github.com/hill-a/stable-baselines/pull/505

Now merged in SB3 contrib: https://github.com/Stable-Baselines-Team/stable-baselines3-contrib


LIRC and LCD questions?

Hi,
Is there any guide for configuring LIRC and 20x2 LCD alphanumeric displays?
regards

Not on here, you could try asking on the forum.


cpuset: when creating container, don't pass cpuset details

Today we only clear out the cpuset details when doing an update call on
existing container/pods. This works in the case of Kubernetes, but not
in the case where we are explicitly setting the cpuset details at boot
time. For example, if you are running a single container via docker ala:
docker run --cpuset-cpus 0-3 -it alpine sh
What would happen is the cpuset info would be passed in with the
container spec for create container request to the agent. At that point
in time, there'd only be the defualt number of CPUs available in the
guest (1), so you'd be left with cpusets set to 0. Next, we'd hotplug
the vCPUs, providing 0-4 CPUs in the guest, but the cpuset would never
be updated, leaving the application tied to CPU 0.
Ouch.
Until the day we support cpusets in the guest, let's make sure that we
start off clearing the cpuset fields.
Fixes: ####
Signed-off-by: Eric Ernst<EMAIL_ADDRESS>

/test

/test-clh

/test

Looks like a lot of timeouts on CI jobs. Let’s try one more time...
/test

/test

All CLH CI failures are caused by changes from a dependency repo of cloud-hypervisor, which is causing building static binary of CLH to fail.
To fix the CI failures, I sent a PR to the packaging repo (https://github.com/kata-containers/packaging/pull/1192) to not build CLH from source when the released binary is available (same as what we are doing in kata 2.0).

/test-virtiofs

/test-clh

Added a do-not-merge to gate on the CLH CI failures.

The CLH CI failures are now being fixed. But there are quite many other failing CIs. Any comments on those? @egernst @jcvenegas @devimc  @GabyCT @chavafg

Also, both qemu and CLH docker CI are failing in the --cpuset-cpus test which makes sense:
13:54:59 CPU constraints
13:54:59 /tmp/jenkins/workspace/kata-containers-runtime-ubuntu-1804-PR-cloud-hypeprvisor-docker/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:147
13:54:59   checking container with CPU constraints
13:54:59   /tmp/jenkins/workspace/kata-containers-runtime-ubuntu-1804-PR-cloud-hypeprvisor-docker/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:167
13:54:59     with cpuset-cpus to 0
13:54:59     /tmp/jenkins/workspace/kata-containers-runtime-ubuntu-1804-PR-cloud-hypeprvisor-docker/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:195
13:54:59       /sys/fs/cgroup/cpuset/cpuset.cpus should have 0 [It]
13:54:59       /tmp/jenkins/workspace/kata-containers-runtime-ubuntu-1804-PR-cloud-hypeprvisor-docker/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:196
13:54:59
13:54:59       Expected
13:54:59           <string>: 0
13:54:59       to equal
13:54:59           <string>: 0-1

The actual output of /sys/fs/cgroup/cpuset/cpuset.cpus in the guest ("0-1") actually makes sense with this patch, as we are never constraining the cpu/cpuset cgroups in the guest and we are always having 1 (default vCPU) + requested number of vCPU from docker CLI. To fix the docker test, I think we should adjust the Expected value to 0-1. WDYT?

@likebreath , I see that the CI failures are related with the CPU constraints tests as well as sandbox cgroup of the shimv2 tests. Maybe related with this change?

I see that the CI failures are related with the CPU constraints tests as well as sandbox cgroup of the shimv2 tests. Maybe related with this change?

That's likely. Also, we may need to adjust the shimv2 tests accordingly, as what I mentioned above for the docker tests.

I agree -- we should be updating the tests. @likebreath are you PRing those changes?

I agree -- we should be updating the tests. @likebreath are you PRing those changes?

Sure. I can open a PR to the test repo to fix the docker tests. As I am not familiar with the shimv2 test, can you please take a shot on that one? Thanks. @egernst

Also; it seems we aren't exercising this on 2.0 tests repo, as we were able to merge w/ out test (buggy tests) failures? :-(

I opened a PR to fix the docker cpuset test. Please check the details in the issue (https://github.com/kata-containers/tests/issues/3241) and the PR (https://github.com/kata-containers/tests/pull/3242). Any questions or comments, please let me know. Thank you.

As the PR kata-containers/tests#3242 is landed, restarted the CI jobs on clh-docker, virtiofs, initrd, vsocks, rhel.

I see the one job fail still: http://jenkins.katacontainers.io/blue/organizations/jenkins/kata-containers-runtime-cri-containerd-PR/detail/kata-containers-runtime-cri-containerd-PR/2489/pipeline#log-2409

TL;DR: All CI jobs are now passing on this PR, while instability of the CI  jenkins-ci-cri-containerd is observed (that is not related to this PR changes). Merging the PR now.
I checked the history of the CI failure on jenkins-ci-cri-containerd , where I found the original failure (CI job 2487) was also on the docker cpuset test (but as a part of "sandbox-cgroup" test). Failure details as below. This failure is already being fixed by the PR kata-containers/tests#3242. Double checked by the debugging PR https://github.com/kata-containers/tests/pull/3252.
[2] • Failure [4.868 seconds]
[2] CPU constraints
[2] /tmp/jenkins/workspace/kata-containers-runtime-cri-containerd-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:147
[2]   checking container with CPU constraints
[2]   /tmp/jenkins/workspace/kata-containers-runtime-cri-containerd-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:167
[2]     with cpuset-cpus to 0
[2]     /tmp/jenkins/workspace/kata-containers-runtime-cri-containerd-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:195
[2]       /sys/fs/cgroup/cpuset/cpuset.cpus should have 0 [It]
[2]       /tmp/jenkins/workspace/kata-containers-runtime-cri-containerd-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:196
[2]
[2]       Expected
[2]           <string>: 0
[2]       to equal
[2]           <string>: 0-1
[2]
[2]       /tmp/jenkins/workspace/kata-containers-runtime-cri-containerd-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:200
[2] ------------------------------
[2] SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
[2]
[2] Summarizing 1 Failure:
[2]
[2] [Fail] CPU constraints checking container with CPU constraints with cpuset-cpus to 0 [It] /sys/fs/cgroup/cpuset/cpuset.cpus should have 0
[2] /tmp/jenkins/workspace/kata-containers-runtime-cri-containerd-PR/go/src/github.com/kata-containers/tests/integration/docker/cpu_test.go:200
[2]
[2] Ran 15 of 195 Specs in 101.759 seconds
[2] FAIL! -- 14 Passed | 1 Failed | 0 Pending | 180 Skipped

The recent failures from restarting the same CI on this PR (job 2488-2491) are not related to the changes from this PR, and should be instability of the jenkins-ci-cri-containerd itself. The same failure on this CI is also  observed from another PR https://github.com/kata-containers/runtime/pull/3135 (CI JOB 2492). The observed error is:
[reset] Removing info for node "ubuntu1804-azure233682" from the ConfigMap "kubeadm-config" in the "kube-system" Namespace
W0216 17:23:30.772546    3918 removeetcdmember.go:61] [reset] failed to remove etcd member: error syncing endpoints with etc: etcdclient: no available endpoints
.Please manually remove this etcd member using etcdctl

For future reference: This PR serves as the back-porting PR of kata-containers/kata-containers#1406.


Scale Requirements

Question/Comment on FedRamp Dashboard RFQ
Name and affiliation
Jason McNutt - Applied Information Sciences - Agile BPA Manager
Section of RFQ documents
Section 4 PWS
Question/Comment
Does 18F expect the vendor to provide past performance to the Scale described  in Section 4 as well as provide the key personnel that either supported that past performance or similar experience?

18F expects that past performance would be at the scale requested but we do not require that the key personnel that will be provided are necessarily on those examples. Please continue to follow the directions in the RFQ provided.


evidence: More reliable evidence reporting + couple of bug fixes

It was confirmed that this patch fixes the issues that were seen on the Gaia RS testnet.


404 Errors when loading the built app

After the build process completes, I copy ./buildOutput/app into my webserver.
I've run into a couple issues:
When I try to load the application, the loading screen spinner shows.  I get a bunch of 404 errors in the console:
/jsapi/jsapi/dojo/resources/dojo.css
/jsapi/jsapi/dijit/themes/claro/claro.css
https://gisdev.eon.faa.gov/jsapi/jsapi/esri/css/esri.css
jsapi/jsapi/dojox/layout/resources/ResizeHandle.css
/jsapi/jsapi/init.js
The application is looking for these resources at the root of my webserver, not the root of the app.  That being said, I don't see a jspai folder anywhere.  In the buildOutput folder there is an app-packages folder which seems to have the correct resources, except init.js, which is in the root of the app folder.
To get around this, I uncommented the apiUrl in env.js, which seems to load the resources.  But you may want to uncomment that from the getgo or include it in the documentation if you don't have the API hosted at the root of your webserver...
However, now I'm getting a bunch of init.js errors (the app is now loading init.js from Esri's CDN, and the first error is
Cannot read property 'en-us' of undefined: init.js:113....
Thoughts?

Which version of Web App Builder are you using?
Most JSAPI files should be loaded internally, but at this version its still taking some of the resources from the CDN.  If the API version is different than developed for, the find and replace won't work correctly.

Thanks!
I'm using the most recent version, version 2.4 -
However, the errors change based on where   Ultimately, two directories are created when running this tool: buildOutput and build-src.  Inside buildOutput there is an app folder and an app-packages folder.  If I want to deploy this new built application on my webserver, what folders do I need to use.  Just the app?  The app folder in buildOuptut?  The entire buildOutput folder?  Can I rename them?
I'm getting a couple different errors based on where I put the folder.  Most recently, I'm getting a couple multipleDefine errors.
It would be best to know the intended behavior (ie - what to do with the biuldOutput and build-src folders, and then I can more accurately troubleshoot the errors.
Also, thanks so much for this functionality - we use WebAppBuilder apps a good bit, including some custom widgets, and the improved performance will be great once I iron out the issues.

The following link should solve your issue :
https://developers.arcgis.com/web-appbuilder/sample-code/change-url-of-arcgis-api-for-javascript.htm
Quick fix :
In the buildOutput\app\env.js uncomment line 98
  apiUrl = '//js.arcgis.com/3.20';

I think this rolls into #10 for WAB 2.4 support.


Review possible system font stack for the project

Compare that of Wagtail vs. Tailwind latest

Here’s a diff between Wagtail’s system font stack and that of Tailwind. Tailwind in green, Wagtail in red:
+ui-sans-serif
--apple-system,
-BlinkMacSystemFont,
-"Segoe UI",
system-ui,
-Roboto,
-"Helvetica Neue",
-Arial,
sans-serif,
Apple Color Emoji,
"Segoe UI Emoji",
"Segoe UI Symbol",
"Noto Color Emoji",

So they both use the same emoji stacks. Tailwind uses ui-sans-serif, which is only supported on Apple from 2020 onwards. The Wagtail font stack uses more explicit fallbacks.
For our template, I like the idea of combining them both:
font-family: ui-sans-serif, -apple-system, BlinkMacSystemFont, "Segoe UI", system-ui, Roboto, "Helvetica Neue", Arial, sans-serif, Apple Color Emoji, "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";

That way we get good support for older devices. What do you think @nandini584?

I agree that this will improve the user experience as well. Shall I proceed to configure it in tailwind.config.js.

Discussed with @nandini584, making the change in #10


[WIP] Inventory override of fact gathering action

Proposal: Inventory override of fact gathering action
Author: Matt Davis @nitzmahone
Date: 2016/05/20

Status: New
Proposal type: Core fact behavior
Targeted Release:
Associated PR:
Estimated time to implement: 3 days

Motivation
The current automatic fact gathering action (setup) must often be disabled for non-Unix target platforms, since it cannot  be reliably overridden without breaking fact gathering for other platforms. Some platforms (eg, Windows) collude with a connection plugin to filter fact modules by file extension, but this behavior won't work for many other platforms (eg, networking) and may eventually break for Windows as well for non-Powershell setup modules or ssh-on-Windows.
Problems
What problems exist that this proposal will solve?

Any target platform can easily provide a fact gathering action without collusion from a connection plugin
Users needing custom fact gathering behavior can override built-in on a more granular per-host basis

Solution proposal
Add support for a new inventory variable, ansible_fact_action, which will allow inventory-level override of the default fact gathering action (setup). Normal action resolution will be performed on the named action, allowing for control-side execution of an action_plugin for fact gathering if desired- otherwise falling back to module resolution.
Testing
The new feature will require expanded unit/integration test coverage
Documentation
The final solution should include explicit documentation on how to write fact actions/modules, and how subsets (and any other fact-gathering alterations/args) are to be passed.

Does this proposal assume the module doesn't need any arguments passed to it in order to run?

currently there is no way to pass arguments at 'gather_facts'

Interesting point- IIRC most of @privateip's network modules require various extra args to work... I guess this comes back to needing some way to patch things through from inventory automatically. Unfortunately, the other ideas discussed around that wouldn't necessarily solve this case (eg, block-level inventory arg maps, adding playbook-level args to gather_facts), as we're allowing the setup module itself to be abstracted at inventory, so potentially different args needed per host.

Thinking of the interface:
- hosts: network_devices
  gatherers:
     - ios
     - juniper
  ....

Would execute ios_facts and juniper_facts modules instead of setup.py

I'd vote for less "magic" in the names (eg, don't turn "ios" into "ios_facts", just specify "ios_facts").

ok, but i would still try to restrict it to _facts modules ... don't want to run 'parted' as part of fact gathering

At some point when is this even advantageous as opposed to just making your
first task a fact gathering task?  Begs the question, do we even need to
have a way to "automagically" run fact collection as opposed to
transitioning to a model where including one (or more) fact gathering tasks
is just a best practice in playbook design?  I haven't thought about it
long enough to propose the idea, but wanted to toss it out there for
consideration...
On Mon, Jul 25, 2016 at 2:03 PM, Brian Coca<EMAIL_ADDRESS>wrote:

ok, but i would still try to restrict it to _facts modules ... don't want
to run 'parted' as part of fact gathering
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ansible/proposals/issues/17#issuecomment-235033082,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZTokaE_synLWLHuOs_4DepBbo_pVQLks5qZPpWgaJpZM4IjbGr
.

not as much on a single play, it is good for an override, my initial thought was being able to set this in config and/or inventory so as not to repeat on every play.

I've never been a big fan of most automagic behavior, as it causes a lot of questions and corner cases, so you can imagine how I feel about this one. :)

Explicit is better than implicit. Especially a best practice for Ansible  :+1:

I like the idea of being able to add fact gatherers for custom facts. We're currently adding items for use with our CMDB in a separate module.

https://github.com/ansible/ansible/pull/31783

implemented by https://github.com/ansible/ansible/pull/49399 - closing


Replace Nocilla in specs

Nocilla has internal race conditions, and appears to be ill-maintained or abandoned. It works well enough for now, but it’s not ideal. Let’s investigate another HTTP stubbing framework.
@onekiloparsec points out the venerable OHHTTPStubs. Would need to investigate whether it can do ad hoc stubbing in code instead of reading from files.
Mockingjay looks interesting.
The ability to explicitly delay and then resume responses is essential for Siesta’s specs. Any alternative would need to have that.

Almost 4 years later. Awesome, and congratulations !

Thanks! Feels good! And more good things coming.


chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-k8s-25-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 3390

Questions ?
Please refer to the Backport tool documentation


Update JS samples to use latest API and add error handling

Also make JS style more uniform and fix URL for JS SDK.

@Lucashuang0802 Okay, I'll return the initPublisher callback but console.error is preferred over alert in modern web development.

👍 LGTM


Weird behaviour using screen readers on our table grid

Description of the bug

[ ] This issue might be coming from the design system. Will check there as well

We got in a report on some weird behavior on our grid component when using screen reader. (Tested with VoiceOver on multiple browsers)
Chrome
Form mode (tabbing)
Seems correct

Element to element (control-option-arrows)
Goes wild with column header and reads it out 4 times total.

Also true when just reading the heading

Firefox
Form mode (tabbing)
Reads out headers correct

Element to element (control-option-arrows)
Reads the column header twice

Edge
Form mode (tabbing)
Seems correct

Element to element (control-option-arrows)
Goes bananas with the column headers. This is also true when just reading the column header.

Steps To Reproduce

Go to a form with a table
Try to read it going element to element

Additional Information
Seems like VOiceOver reading double headers is a known issue in Chrome. But we should still try to avvoid it being read 4 times!

I have identical results using NVDA on Windows

Tested today on chrome and firefox, could not reproduce.
@Febakke and @tvs-brreg could you please test again on the same app running the latest version of frontend and backend, and report if the bug is still present?


Document Bevy coordinate system rationale in the FAQ

Bevy uses right-handed Y-Up by convention in both 2D and 3D. People regularly ask why, especially once they discover that "forward" is -Z (which is generally an implementation detail, but does sometimes come up). It feels suboptimal, despite being the optimal solve.
I recently answered this question again on Discord:

From my perspective this really only comes down to these choices:

Do what is natural for left handed 2D / 2.5D and make Y-Up the global assumption across 2D and 3D, at the cost of making 3D slightly weird by making  -Z "forward" semantically. This is a hidden implementation detail for most people.
Do what is maximally natural for left handed 3D and make Z-up the global assumption, at the cost of making 2D very very weird (2D gamedevs think in z-levels for depth, not y-levels. Y is always the horizontal axis, not Z)
Fracture Up, Down, Forward, and Back concepts in Bevy into UP_2D (Y) and UP_3D (Z). These would no longer be universal in Bevy.  This increases our weirdness budget/api surface and makes documenting/answering questions hard ("User: what is up in Bevy?", followed by "Helpful Bevian: Thats a complicated question ... [dumps a bunch of info]").  It also puts 2.5D / platformer style games in an awkward position. Would those devs pick UP_3D because they have 3D models? Or would they pick UP_2D because they want to use the conventions natural to their genre?
Switch handedness, which breaks compatibility with math conventions and most of the ecosystem that we care about (ex: all 3D modeling programs, godot)

IMO (1) is the optimal solve (the current approach) by a wide margin
Unity and unreal dodged this problem by doing (4)
But they created way more painful problems as a result

It is worth putting something like this in the FAQ, ideally a bit more polished (and elaborating more on the RH vs LH debate).

"FAQ" being a Github Discussion with the FAQ label: https://github.com/bevyengine/bevy/discussions/categories/q-a?discussions_q=is%3Aopen+category%3AQ%26A+label%3AFAQ

No sense in letting perfect being enemy of the good. I've created an answer here and I can edit it later over time:
https://github.com/bevyengine/bevy/discussions/10488


Use xpc_connection_send_message_with_reply_sync

This works better than  instead of xpc_connection_send_message_with_reply
This prevents priority inversion and makes the code simpler.

Since this is macOS-specific and Apple is not using OpenPrinting CUPS, not going to take this change. You can try providing this to the Apple CUPS repository but they haven't been too responsive there...

With all due respect Mr. Sweet:
That's because you left that repo.

https://github.com/apple/cups/pull/6078 Here it is just in case: @michaelrsweet


Add missing columns to url_report model

Are you a current Fivetran customer?
Yes, consulting analytics engineer for FTD
What change(s) does this PR introduce?
This PR adds the missing columns ad_squad_id, ad_squad_name, campaign_id and campaign_name to url_report model and snapchat.yml. These columns come from CTEs that were already present in the url_report model, just not joined and added. Hence, these columns could not be populated downstream in e.g. the ad_reporting package.
Did you update the CHANGELOG?

[x] Yes

Does this PR introduce a breaking change?

[ ] Yes (please provide breaking change details below.)
[x] No  (please provide an explanation as to how the change is non-breaking below.)
This change only adds new columns, this should be handled gracefully by all databases.

Did you update the dbt_project.yml files with the version upgrade (please leverage standard semantic versioning)? (In both your main project and integration_tests)

[x] Yes

Is this PR in response to a previously created Bug or Feature Request

[ ] Yes, Issue/Feature [link bug/feature number here]
[x] No
It is is related though to a bug filed in the ad reporting package

How did you test the PR changes?

[ ] Buildkite
[x] Local (please provide additional testing details below)
Added the local package to the package.yml to override the package of an existing project using snapchat_ads. Then ran dbt build -s +snapchat_ads succesfully.

Select which warehouse(s) were used to test the PR

[x] BigQuery
[ ] Redshift
[ ] Snowflake
[ ] Postgres
[ ] Databricks
[ ] Other (provide details below)

Provide an emoji that best describes your current mood

:metal:
Feedback
We are so excited you decided to contribute to the Fivetran community dbt package! We continue to work to improve the packages and would greatly appreciate your feedback on our existing dbt packages or what you'd like to see next.

Hi @dumkydewilde thanks so much for opening this (and the other ad reporting) PR to address the original issue you raised!
My team and I will review these changes and let you know if we have any questions before proceeding to integrated into the next release of the packages. I do just want to make sure there was not an intentional reason we left these out in the final releases.
Would you be able to confirm that when bringing in the ad_squad and campaign ctes, you don't see any duplication of ads. I will test with your branch locally, but just wanted to confirm before moving forward.

Thanks for getting back @fivetran-joemarkiewicz! I was indeed curious why it was left out originally, but so far we haven't come across any issues in our own reporting when enabling it locally. I will double check on Monday though and get back to you then.

Sounds great, thanks so much @dumkydewilde. Let me know and if all looks good on your end come next week, we can move forward with these suggested changes.

Hi @fivetran-joemarkiewicz, just double checked for any anomalies in our Snapchat data running the pipeline with the updates from this PR and couldn't find anything. Please do check on your side as well of course, but looking at the models I also wouldn't expect anything being impacted since it is all just left joins adding columns to existing rows.

@dumkydewilde thanks so much for the confirmation here! I will double check on my end, but will look to do a more thorough review of your PRs this week and will hope to integrate them into the packages soon.
I will follow up in these PRs if there are any other clarifying questions I may have during my reviews.


Add ability to mute users

Closes #1629.

[x] Let's you mute or unmute users from the dropdown available for comments. Comments from these muted users will be minimized on page load.
[x] As mentioned in https://github.com/sindresorhus/refined-github/issues/1629#issuecomment-441348474, the original post, issues, and PRs from muted users will still be visible, but any of their comments will be minimized.
[x] Shows list of users who are muted in the options.
[ ] Disable self-muting.
[ ] Possibly show on a users profile if you are muting them.

Screenshots
A minimized comment

Unmute button

Mute button

Options menu

Test
On any issue or PR.

Should the comment be hidden by hide-useless-comments instead of being minimized?
That’s how muting generally works.

Should the comment be hidden by hide-useless-comments instead of being minimized inline?

Looking at the feature name, it should be hidden and not minimized. But if a user were having a conversation with another user muted by the viewer then it would not make any sense on what is happening. But if there were a minimized comment then that would mean the they are having a conversation.
And if the comments were hidden inline, then the user can individually expand that specific comment, unmute the user then and there without having to go look in the options section and try to see who commented on the issue/PR by individually unmuting each user.

If not, then this is a completely different feature from hide-useless-comments and should be separate.

That's what I initially thought when the code grew a bit large than what it was before. WDYT? Should I move it to something like minimize-muted-user-comments?

And if the comments were hidden inline, then the user can individually expand that specific comment, unmute the user then and there without having to go look in the options section and try to see who commented on the issue/PR by individually unmuting each user.

To see the hidden comment you’d click the regular link at the bottom: “3 unhelpful comments were hidden”
I never needed this feature so let’s see what @sindresorhus expects from it

Should the comment be hidden by hide-useless-comments instead of being minimized inline?

It should be minimized.

Then should be extracts into mute-users because there’s no overlap.

Blocked by https://github.com/bfred-it/webext-options-sync/commit/fc77d661742e95ecefce66d0b738c1e3a7d7aae3#r34067329.

(tested https://github.com/sindresorhus/refined-github/pull/2185)

Is this still blocked?

Is this still blocked?

Need a new release of https://github.com/bfred-it/webext-options-sync.

oops, done. 0.21.2

Weird, I minimized @notlmn first response here:

it was minimized
following page loads also kept it minimized

but... your second comment here was never minimized, even if the menu correctly says "restore user"

It might have something to do with him being the OP, but it's still a bug

🙌

2 months in the making

Oh no

Also the .dropdown-menu should be set to width: 205px !important because the text is being clipped...

How's this?
https://github.com/sindresorhus/refined-github/compare/master...sharkykh:simple-fix-mute-users

Or maybe it should be more like comments-time-machine-links?

No, the fewer DOM operations the better. comments-time-machine-links used to be 100% outside the dropdown and now it's 50/50

How's this?
master...sharkykh:simple-fix-mute-users

I think we just need a :not([aria-label="Add your reaction"]) selector in the delegate

I think we just need a :not([aria-label="Add your reaction"]) selector in the delegate

The edit buttons also get selected by that. So, summary.timeline-comment-action:not([aria-label="Add your reaction"])?


Agent shouldn't store PSModulePath as a capability

Agent Version and Platform
Version of your agent? '2.181.0'
OS of the machine running the agent? Windows
Azure DevOps Type and Version
dev.azure.com/sabinio
What's not working?
During capability scanning the agent was picking up that the psmodulepath was set to C:\Program Files\Microsoft Monitoring Agent\Agent\powershell. Because this was set the default powershell behaviour of adding the machine module path wasn't working and thus no modules could be found.
Not really sure why all the environment variables at startup are stored and they overwrite anything at startup. PSModulepath might be a special case.
Troubleshooting this was really hard as there is nothing in the log that says the agent is overwriting all the environment variables with what is defined in the capabilities.

Hi @simonsabin thanks for contribution! Related changes have already been rolled out - I'm closing this at the moment, please let us know if you have any other issues.


GPII-4102: Block egress traffic

This PR adds network policies to block egress external traffic unless it's going via the egress gateway, it's part of work on controlling egress traffic - GPII-4102. This will effectively bring us back to the state before GKE Istio 1.1, when any egress traffic was denied by default.
PR Changes:

Block egress traffic from gpii namespace - egress traffic is blocked by default, there are several exceptions:

Egress to Istio control plane is allowed - this is required for traffic routed via Egress gateway and other Istio traffic to istio control plane
Egress traffic within gpii namespace is allowed (traffic is already controlled by ingress rules on corresponding services)
Egress traffic to Kube DNS service is allowed
Egress traffic to GCP metadata is allowed on port 8181

Deployment:
This is a non-disruptive deploy. (All the traffic is already routed via Egress gateway).
Testing:

I've confirmed traffic is truly routed via Egress gateway and all other traffic blocked after applying blocking Network Policies.

Thanks for reviews @natarajaya, I believed I addressed all the points. I'll add some details about the traffic routing directly to the https://github.com/gpii-ops/gpii-infra/pull/548 PR.

LGTM


Improve model architecture error message

When providing an incorrect model architecture:
error: invalid value 'llama1' for '--model-architecture <MODEL_ARCHITECTURE>': llama1 is not one of supported model architectures: [Bloom, Gpt2, GptJ, GptNeoX, Llama, Mpt]

It is much easier for users to know what available model architectures are.

Congratulations on your first PR! Much appreciated 🚀

Thank you for merging my first PR @philpax! 😄


looking for a way to handle a conversation

I'm trying to build a conversation bot and I'm looking for a conversation handler method in order to whenever a user starts chatting with the bot, the conversation continues the previous conversation.
can anyone help with this?

@soheilrt read issue template.


Progress bar

Hi, nice plugin.
How i can implement progress bar?
self.YD.on("progress", function(progress) {
		console.log(JSON.stringify(progress));
	});

How i can send it to the client side? Should i send file via xhr??

Sorry, I can’t do individual project support. Have a look at socket.io

I didn't ask you about full implementation:) Maybe just suggestions ;)
9 дек. 2017 г. 10:24 пользователь "Tobi"<EMAIL_ADDRESS>написал:

Sorry, I can’t do individual project support. Have a look at socket.io
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tobilg/youtube-mp3-downloader/issues/21#issuecomment-350432421,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AY5vYhlBW-e4ufHvdXr0CawQIc5dgD-cks5s-kOfgaJpZM4Q7gP4
.

Also, it can't download large files... App goes down and nothing happens. Maybe I need change some settings of app?
In console I see that it starting download several times and percentage wrong...

I don’t know what you’re doing, and as I said, I can’t support individual projects. Try the sample code with the video that crashed in your app. If that works, it’s your code.

I use code from sample and didn't change anything. Only path to ffmpeg.
10 дек. 2017 г. 14:39 пользователь "Tobi"<EMAIL_ADDRESS>написал:
I don’t know what you’re doing, and as I said, I can’t support individual
projects. Try the sample code with the video that crashed in your app. If
that works, it’s your code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tobilg/youtube-mp3-downloader/issues/21#issuecomment-350545547,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AY5vYnGu8VQ97pPjzZi-FaFWeU5HiSsEks5s-9ERgaJpZM4Q7gP4
.


Improve reliability of basic usage and address several minor issues

Thanks a lot for producing such awesome libraries for the Deno community! I have used cliffy on another project and wanted to give back :D
I really love the ergonomics of zx and use it heavily for my own scripting needs, but I think that Deno is actually even better suited to the use case since it can reference third party code with a much more straightforward mechanism via urls. Your dzx library is amazing, and really well organized but when I went to use it I ran into a few issues that were simple enough for me to just take a look and address. Hopefully these can save you some keystrokes!
Note that I tried to use very discrete and linear commits which fully encapsulate the steps I took to address things. If you have any questions, please feel free to let me know!
Included updates and fixes:
(https://github.com/c4spar/deno-dzx/commit/adbbf73802546ea91a496652a008dbbaea20a7d8) Lint fixes

Deno lint was failing due to the deprecation of Deno.copy as well as a re-declared global identifier
for $. Both of these issues are now fixed, however as a side effect, the version of the std library
needed to be updated to have access to the ioutil.copy method, and since the std lib was updated to
the latest, the supported semver version of deno in the readme also needed to be udpate.

(https://github.com/c4spar/deno-dzx/commit/f89e1dc8ba56c6212c4469c78bd518b68e5f9f46) and then (https://github.com/c4spar/deno-dzx/commit/129c46420f3699e911e581c4ef64b588954d5a29) Testing basics

Add a testing step to ci, then add a baseline test so that deno test does not fail to find a test file in ci, but note that at the point of these commits this test failed for more a few reasons which will be fixed in a subsequent commit

(https://github.com/c4spar/deno-dzx/commit/b1f88d62952557e9c0cd3a1ccc3ccef2dcdfcf22) Passing initial test

There were two reasons the tests were failing initially; (1) the dash shell (/bin/sh) does not
have the "pipefail" option, and (2) the child process was leaking file descriptors. These are both
resolved now by (1) removing the pipefail option and (2) ensuring that if the out/err pipes are
present on the child process that they are closed and that the process as a whole is also closed.

(https://github.com/c4spar/deno-dzx/commit/175ae578335e6334bf286fa3299cad7efafebbb1) Core functionality tests
(https://github.com/c4spar/deno-dzx/commit/6df1f851a6e4faa4e9408f44cef940a33b962821) Bump deps now that tests exist
(https://github.com/c4spar/deno-dzx/commit/1f40248928c446f7e935bd783994de7860eb314f) and then (https://github.com/c4spar/deno-dzx/commit/686639218289eb439a0af59195e6e98c2c98d1fd) New Feature: Allow passing one exec result into another for improved ergonomics between steps in a script. Then add tests against this.
Two more things:

I found with dzx bundle that due to the lack of explicit compiler options opting out of sourcemaps, that Deno.emit would emit sourcemaps in the result.files array, and sometimes the sourcemap would be the first entry, and other times it wouldn't. Whenever the sourcemap was first in the array, the dzx bundle command would fail. To fix this intermittent failure, I added explicit opt-out of soucemaps, which improves the reliability of just grabbing the first element of the results array. It's not perfect though, so I left a TODO comment to look at it more closely.
I wonder if the default $.shell option should just be bash and not sh? This would enable putting the pipefail option back in the prefix and I think it might be nice to optimize for a default use case of people who have bash vs the less common scenario where someone is running without bash available - since such users can just override back to /bin/sh this seems safe enough IMO. I'll also note that in my testing, you don't actually need to supply the fully qualified executable path, so just $.shell = 'bash' will work (saving having to look up where bash is installed). Perhaps at a later time it might be nice to do a quick lookup at dzx startup that checks for bash and if found, uses it with a more restrictive prefix, then if not found, falls back to sh automatically with the more permissive prefix. Thoughts?

@andrewbrey thx a lot for your pr and your feedback! 🙂
i haven't maintained this project much in the last time due to some deno issues with sub-processes but i will definitly keep working on it! Will look into you changes now!

@c4spar Sounds great, and yea, I have seen some of the limitations with subprocesses as well as I've been tinkering around with Deno, but it will get there in time :+1:

@c4spar I've made the requested updates and re-requested review :rocket:

Cheers, and thanks again for the quality project :+1:


Migrate to package:web to support WASM

The short version:

Migrate usage of dart:html to package:web
Migrate usage of dart:js, dart:js_util, and package:js to dart:js_interop

This will also compiling to WASM engine instead of just JavaScript on web.
Full migration guide: https://dart.dev/interop/js-interop/package-web

@ThexXTURBOXx this would also be a nice addition to the version 4.0.0 😌

Thank you for reminding me. That was the last thing I wanted to do for 4.0.0, but I could not remember it. Will migrate in a minute :)

Done in 4.0.0-alpha.2!


Add dump_content function to avoid unclear item_content transformation process

In order to avoid mistakes when creating the item_content of a message, the extended_json_encoder has been added from the aleph-sdk-python package to this central piece of the aleph architecture.
Based on #89

Can you explain the issue in more details ? I do not understand what the problem is from this short description.

Well, I figured that some functions in connection with messages are too important, to have them spread out around the different repos. IMHO we want:

The whole item_hash generation process to be contained in this repo as reference for other language implementations (like TypeScript).
Standardized serialization, like here in dump_content, on which also the item_hash generation process relies.

This way we can also write tests for the validators, to make sure that what transformations we implemented here, are working fine with the current message spec.

This branch is mixing unrelated stuff, can you move black and forbid to other branches ?

Is the code coverage increasing or at least identical after these changes ? I don't see changes in the tests.

93% -> 92%, due to the decreasing coverage on the utils.py file from 100% -> 72%. Will increase coverage


Allow previously preprinted journal articles to be included in the article activity feed

http://localhost:8080/articles/activity/10.1099/acmi.0.000569.v1 should also include expression that points to a published journal article https://www.microbiologyresearch.org/content/journal/acmi/10.1099/acmi.0.000569.v3

b4dd827 allows journal articles to show up on the paper activity page. It's buggy as e.g. it allows the journal article http://localhost:8080/articles/activity/10.1099/jgv.0.001944 to show up and say it's on Access Microbiology when it's not, it an article from the Journal of General Virology.

Investigations reveal that both the Access Microbiology journal and other microbiology journals use the same domain microbiologyresearch.org. We display "published on Access Microbiology", on checking that the domain is microbiologyresearch.org.

We will be trying to restrict the search Crossref query to consider 4 types of relation rather than not filtering at all:
https://api.crossref.org/works?filter=relation.object:10.1101/2<IP_ADDRESS>0898,type:posted-content,type:journal-article,relation.type:has-version,relation.type:is-version-of,relation.type:has-preprint,relation.type:is-preprint-of

We suspect 503 responses from Crossref are getting into our cache:
app-1  | {
app-1  |   "timestamp": "2024-01-18T10:38:42.019Z",
app-1  |   "level": "debug",
app-1  |   "message": "Response time",
app-1  |   "payload": {
app-1  |     "url": "https://api.crossref.org/works/10.21203/rs.3.rs-1828415/v3/transform",
app-1  |     "durationInMs": 3,
app-1  |     "responseStatus": 200,
app-1  |     "requestId": "bf85aef0-b5ed-11ee-8550-fbff1f28a786"
app-1  |   }
app-1  | }
app-1  | {
app-1  |   "timestamp": "2024-01-18T10:38:42.019Z",
app-1  |   "level": "warn",
app-1  |   "message": "Unable to find authors",
app-1  |   "payload": {
app-1  |     "expressionDoi": "10.21203/rs.3.rs-1828415/v3",
app-1  |     "response": "unexpected DoiDBrecord.get issue: null\n(org.crossref.common.exceptions.IORuntimeException occured 1/18/24 5:35 AM)",
app-1  |     "requestId": "bf85aef0-b5ed-11ee-8550-fbff1f28a786"
app-1  |   }
app-1  | }
app-1  | {
app-1  |   "timestamp": "2024-01-18T10:38:42.019Z",
app-1  |   "level": "warn",
app-1  |   "message": "Unable to find server",
app-1  |   "payload": {
app-1  |     "expressionDoi": "10.21203/rs.3.rs-1828415/v3",
app-1  |     "response": "unexpected DoiDBrecord.get issue: null\n(org.crossref.common.exceptions.IORuntimeException occured 1/18/24 5:35 AM)",
app-1  |     "requestId": "bf85aef0-b5ed-11ee-8550-fbff1f28a786"
app-1  |   }
app-1  | }
app-1  | {
app-1  |   "timestamp": "2024-01-18T10:38:42.020Z",
app-1  |   "level": "info",
app-1  |   "message": "Sent HTTP response",
app-1  |   "payload": {
app-1  |     "status": 503,
app-1  |     "durationInMs": 5,
app-1  |     "requestId": "bf85aef0-b5ed-11ee-8550-fbff1f28a786"
app-1  |   }
app-1  | }

For testing:
https://elifesciences.org/articles/90184 relating to http://localhost:8080/articles/activity/10.7554/eLife.90184.4

Link to Grafana query that filters out xml and json responses
One of the examples that is returned using the above query:
{"timestamp":"2024-01-18T11:18:43.445Z","level":"debug","message":"Response from Crossref is valid, caching","payload":{"responseBody":"unexpected DoiDBrecord.get issue: null\n(org.crossref.common.exceptions.IORuntimeException occured 1/18/24 11:18 AM)","url":"https://api.crossref.org/works/10.1101/2<IP_ADDRESS>82362/transform","requestId":"56c0f270-b5f3-11ee-86f7-313eef9145c2"}}


Responsive design

[x] Variable for text-colors
[x] "Zentrieren weg", fixe Position von oben
[x] Always allow scroll-right side
[ ] Responsiveness

[ ] Collapse header to logo
[x] Collapse left navigation
[x] Fix responsivness (Buttons width, team width)?

The forms are now responsive and they can also be edited on a small phone. Comments welcome.


update to use latest node

@yauhenuzum, thanks for the suggestion.
Please check this release: v1.0.4

Works like a charm, thanks!

Ah, looks like had an exception now(
Error: Cannot find module '@actions/core'
Happened only with 1.0.4

WIll check the issue and write here. Thanks!


Custom square root matrix procedure to Qmcu class

Quick fix for build error raised by automated unittests of the Qdmcu class regarding the sqrtm procedure from scipy library.

Thank you, @IsmaelCesar !
Should we create an Issue on the SciPy repository regarding this bug?

Thank you, @IsmaelCesar ! Should we create an Issue on the SciPy repository regarding this bug?

Definitelly. In fact, if we're able to spot the problem we could even submit a pull request with a solution.


A login page always call logout API request

When login page is shown a logout API call request can be found in firebug console. It doesn't make sense as login page is accessible only when no user is logged in.

Used packages:
tendrl-api-doc-1.2.1-04_05_2017_01_51_04.noarch
tendrl-commons-1.2.2-04_05_2017_04_42_03.noarch
tendrl-dashboard-1.2.1-04_05_2017_11_03_12.noarch
tendrl-performance-monitoring-1.2.1-04_05_2017_11_26_14.noarch
tendrl-api-1.2.1-04_05_2017_01_51_04.noarch
tendrl-api-httpd-1.2.1-04_05_2017_01_51_04.noarch
tendrl-node-agent-1.2.2-04_05_2017_00_01_04.noarch
tendrl-node-monitoring-1.2.1-04_05_2017_11_26_13.noarch

@anivargi if this is not fixed in the current package set, could you make it as one of the issues we fix in the next package build set?

@ltrilety The bug is fixed from our side. Please verify on the new build[1] available.
[1]. tendrl-dashboard-1.2.1-04_09_2017_18_25_13.noarch

No unnecessary logout called.
Checked with:
tendrl-dashboard-1.2.1-04_10_2017_04_11_04.noarch


eCAL Player cannot load measurements from paths with non-ASCII characters

Describe the bug
The eCAL Player fails to load measurements from paths with non-ASCII characters, at least on Windows.
Screenshots

Additional context
I should probably also check whether the eCAL Recorder can handle non-ascii characters

Work is currently in progress and not merged, yet.


UserAgent._sessions

Is your feature request related to a problem? Please describe.
UserAgent._sessions is marked as private. When switching between multiple calls, it's useful.
Describe the solution you'd like
UserAgent.sessions public
Describe alternatives you've considered
I used UserAgent.sessions = UserAgent._sessions to make my existing code work, but I found it to be hack.
Additional context
I'm not sure why you have decided to depreciate so many features from older visions. It makes development with your software difficult.

Perhaps providing a shallow copy in an array would work? Don't want to leak a reference to the UserAgents internal session container.

I use my own wrapper using the delegates provided in the UserAgent.
const sessions = new Map<string, Session>()

userAgent.delegate.onInvite = (invitation) => {
  sessions.set(invitation.id, invitation)

  invitation.stateChange.addListener((state) => {
    if (state === SessionState.Terminated) {
      sessions.delete(invitation.id)
    }
  })
}

Yes - and you can track outgoing ones in the same fashion just before calling inviter.invite(). Your approach is the best one currently.
The concern with exposing the sessions UserAgent is tracking is that UserAgent arguably should not be tracking them at all. The only reason UserAgent currently tracks sessions is for housekeeping when stop() is called and there's a case being made in another issue that UserAgent should not be doing that housekeeping (and/or what it is doing now is broken). And so if UserAgent should not be doing the housekeeping, then it would make sense to eliminate the sessions from UserAgent altogether.
All that said, sessions obviously do need to be tracked someplace if multiple sessions are being utilized.

I was previously maintaining my own sessions, but had two problems;
If the user agent maintained its own sessions, and I also maintain sessions in another object, there could be the possibility of the two becoming out of sync. I certainly don't want to maintain both.
Also I wanted to look at adding multiple registrations into my solution (that already supports multiple sessions). It would have been easier to refer to existing UserAgent objects.
Personally I feel that if a UserAgent is responsible for creating a session, it "belongs" to the agent, and not brought into some global space. I find that messy.

I use your solution on a daily basis, and am highly focused on building a great user experience from it. It's capable of just about everything I need so far, for example: https://github.com/InnovateAsterisk/Browser-Phone/
Looking forward to hearing how you guys solve this. I'm aware of the efforts you guys put in here! So, Thanks

I've pushed a new class SessionManager to the main branch. It's basically SimpleUser with support for multiple concurrent sessions. I'm proposing...

the managed sessions are public: public managedSessions: Array<ManagedSession>
the ManagedSession interface has a reference to the associated Session
the ManagedSession instance is created via a configurable ManagedSessionFactory allowing the user to supply their own custom ManagedSession objects
the SimpleUser class is now implemented using SessionManger
the library will provide for management of multiple concurrent sessions via the SessionManager class going forward
the utilization of the lower level UserAgent API directly will require the user to track session on their own and the recommended approach to doing so is the one outlined earlier in this issue and codified by example in the SessionManager class

The upshot for UserAgent._sessions is that will remain private (and hopefully eliminated in the future in line with not tracking sessions in multiple places as a matter of good design). I spent a bunch of time looking at exposing the sessions at the UserAgent level this past week and my opinion is stronger now that I spent time attempting to code it up. It seems to me that managing a collection of sessions is best done "one level up" from UserAgent given the current software architecture.
So I did that and now we have SessionManager which suffices as the base for a number of projects I'm aware of that are currently coding to the API directly because SimpleUser was not sufficient. All these project are managing their own session collections and could now use SessionManager instead. And if one needs to manage their own sessions, the SessionManger class provide a working example of the recommended approach to doing so.
Feedback welcome. My default course is to push this out shortly with an upcoming 0.21.0 release.

Released 0.21.2


Pull request for branch "issue76" (#76)

@thysultan
As discussed: Support for "contextTypes" has not been implemented - you've said you take care of that on your own.
Could you please review my changes?
Please let me know in case I should change/add/fix something.
Thanks.

Coverage remained the same at 100.0% when pulling 99dad6ec07b353521e36cc26bd19d11b1ccdada1 on issue76 into 62239dc2d2b9fb5c434fed0771c652a0242838d3 on master.

@thysultan @Zolmeister Okay, I've fixed all issues discovered at @Zolmeister's review. The whole task is about making development with DIO more comfortable, so I pimped the error messages a bit to be also a bit "more comfortable".

@mcjazzyfunky Lets move checkPropTypes out of Component into it's own file. i.e Types/Check?

@thysultan
I've commited all requested changes (and some more) to branch "issue76":

Removed propTypes logic for ContextProvider (file "Context.js" is equal to "master" now)
If a propType validator is not a function there will not be any special logic any longer => instead, a "normal" "is not a function" exception will be thrown
Modified propTypes validator handling: Any result value is allowed now => true is okay, false will throw an error and everything else will also throw an error object if Boolean(result) === true
Moved propTypes related unit tests to new file "PropTypes.spec.js"
Fixed #81 and added two corresponding unit tests

LGTM, feel free to merge this. Thanks.


Switching contexts throws a panic

What's your CLI version?
0.75.9
Description & steps to reproduce
$ kurtosis context ls
 15:42:38<EMAIL_ADDRESS>Drive/checklists-and-templates/brazil-apartment-bills (master)  kurtosis context ls
    UUID           Name                Remote Host
*   e5605959c984   default             -
    37726bbf2de2   kurtosis-kloud-01   <IP_ADDRESS>

$ kurtosis context switch kurtosis-kloud-01
INFO[2023-05-08T15:42:58-03:00] Switching context...
INFO[2023-05-08T15:42:58-03:00] Context switched to 'kurtosis-kloud-01', Kurtosis engine will now be restarted
panic: Propagate must be provided with a cause

goroutine 1 [running]:
github.com/kurtosis-tech/stacktrace.Propagate(...)
	/go/pkg/mod/github.com/kurtosis-tech/stacktrace@v0.0.0-20211028211901-1c67a77b5409/stacktrace.go:85
github.com/kurtosis-tech/kurtosis/cli/cli/commands/kurtosis_context/context_switch.run({0x1038b44f0, 0x1400003a0c0}, 0x0?, 0x14000449910?)
	/root/project/cli/cli/commands/kurtosis_context/context_switch/switch.go:118 +0x924
github.com/kurtosis-tech/kurtosis/cli/cli/command_framework/lowlevel.(*LowlevelKurtosisCommand).MustGetCobraCommand.func2(0x140003ffb00?, {0x14000449910, 0x1, 0x1})
	/root/project/cli/cli/command_framework/lowlevel/lowlevel_kurtosis_command.go:294 +0x330
github.com/spf13/cobra.(*Command).execute(0x140003ffb00, {0x140004498d0, 0x1, 0x1})
	/go/pkg/mod/github.com/spf13/cobra@v1.6.1-0.20230225213037-567ea8ebc9b4/command.go:940 +0x5c8
github.com/spf13/cobra.(*Command).ExecuteC(0x10410ae00)
	/go/pkg/mod/github.com/spf13/cobra@v1.6.1-0.20230225213037-567ea8ebc9b4/command.go:1068 +0x35c
github.com/spf13/cobra.(*Command).Execute(...)
	/go/pkg/mod/github.com/spf13/cobra@v1.6.1-0.20230225213037-567ea8ebc9b4/command.go:992
main.main()
	/root/project/cli/cli/main.go:52 +0x80

Desired behavior
Switching contexts works as expected
What is the severity of this bug?
Critical; I am blocked and Kurtosis is unusable for me because of this bug.

The panic is due to this: https://github.com/kurtosis-tech/kurtosis/pull/658.
It's likely that kurtosis somehow encountered some issues restarting the engine after switching context. Unfortunately, because of the panic we will never know why.
With the fix, at least the error will be more user friendly, and next time it happens we will actually know why.
In the meantime, since I suppose cloud is not at the top of our priorities right now, I'll close that one until we hit this again, unless you disagree


Problem Generating a token

I followed the directions to install the Docker instance from the Full Stack.
I am using docker-compose version v2.20.3
I am also using a free account on openAI
I modified the docker.compose.yml with my API key formatted as :
LLM_API_AUTHORIZATION=my key
The docker container spun up linked to the database and was confirmed running.
The GUI link on port 3000 directs to google.com From the "Generate token" button.
When using the chat box this error shows
"The previous query failed.
Error message:
Please check your token."

I was able to get the app to respond after I followed your changes


Feat/base skeleton

This PR brings preliminary design skeleton to the SDK, nothing functional. the intent is to setup a base on interfaces.
🗂 Structure
Find below details on the different go modules:
├── auth        # Content related to the authentication of identities against the protocol in a generic way.
│   └── jwt     # Content related to the management of identities through JWT tokens.
├── dataverse   # Contains client elements to interact with the dataverse.
├── http        # Carry an http server configurable enough to simply build http connectors for services.
├── keys        # Carry the logic related to cryptographic keys.
└── provider    # Contains the logic associated with different types of resources providing services (e.g. storage, computation, etc...).
    └── storage # Implement an extensible storage service proxy, providing the base implementation allowing to customise the underlying logic.

🌐 Main components
auth.Proxy
A generic component to authenticate an identity given a signed credential, exposing a single Authenticate func. The idea is to be agnostic on the way the authentication is served (e.g. rest, gRPC...) and carry here only the business logic. the jwt.Factory can use it to issue JWT tokens and provide configuration elements to issue and verify jwt tokens on an http server.
storage.Proxy
A component to implement storage service proxies, taking care of all the generic tasks:

Authentication through auth.Proxy
Authorization on read & store requests

The specific logic to implement with an S3 for example is achieved by providing related functions when instantiating it.
It is also agnostic to the transport layer in its implementation, it offers configuration elements for an http server but could eventually be exposed in a different way.
dataverse.Client
Provide interactions with the protocol with a business logic  dataverse oriented.
http.Server
An http server intended to be configured directly by proxy implementation to be served over http.
📺 Example
Here is an example of a storage connector implementation using these:
ctx := context.Background()
var dataverseClient dataverse.Client
serviceKeys, _ := keys.NewKeyFromMnemonic("")

storageProxy, _ := storage.NewProxy(
    ctx,
    serviceKeys,
    dataverseClient,
    func(ctx context.Context, resourceID string) (io.Reader, error) {
        // Implement specific read logic here
        return bytes.NewReader([]byte("resource data")), nil
    },
    func(ctx context.Context, resourceID string, data io.Reader) error {
        // Implement specific store logic here
        return nil
    },
)

axonehttp.NewServer(
    "<IP_ADDRESS>:8080",
    storageProxy.HTTPConfigurator([]byte("jwt_secret_key"), 5*time.Minute),
).Listen()

🙈 Missing
There is currently no canonical error handling here.
SSI & verifiable credentials management are also not covered currently.
❓Remarks
@ccamel @bdeneux Let's challenge everything, structure, naming, etc..
Some methods are pre-implemented to give an idea of their scopes.

Let's begin with that then :)


Wallet wont sync, split or mint . Request failed with status code 500:64: dust

Lots of going on here. Think the first problem is the wallet not syncing eventhough i have sent funds and checked explorer.
i also get : when splitting wallet into multiple UTXos
Request failed with status code 500:64: dust
Everything was fine yesterday, and today it wont work.
Any ideas?

Also get this one when trying to mint:
Request failed with status code 500:258: txn-mempool-conflict
From my understanding the balance is not syncing eventhough it says its synced.

Same problem i have faced.

can you check env file and tell me your fee per kb


Very rapid keyboard interaction can "crash" a Select2 field

When typing very quickly in a select2 search field, it is possible to get "stuck" with a Select2 instance that has "Searching..." visible at the top of the select list but is no longer responsive.
A JavaScript stack trace (below) shows that the exception occurs when setClasses is called from within handleSearch, but there is no data defined for the visible result option.
Eg, in a page containing a single select2 instance, when this problem has been triggered, this expression evaluates to undefined:
$.data( $('.select2-results__option[aria-selected]').get(0), 'data' )
Once this problem is triggered, it seems impossible to recover -- you can type into the search field, but the result list never updates and clicking on the result options has no effect other than logging additional exceptions to the console.
If there are other Select2 instances on the same page, they are unaffected and continue to function normally.
This doesn't happen in typical usage, but I was specifically testing the response to very rapid keyboard interaction to confirm that a problem our users had reported with Chosen.js was not present with Select2.js -- thankfully it isn't, but I did accidentally discover this other problem along the way.
Expected behavior: no combination of keystrokes should cause the select2 instance to get permanently stuck.
Seen in a multi-select instance; unknown whether it also affects single-selects.
First seen on our custom application pages, using Select2 4.0.1, jQuery 1.9.1.
Reproduced on the Select2 examples page, using Select2 4.0.1, jQuery 1.11.2.
https://select2.github.io/examples.html#multiple
Reproduced by tabbing/clicking into the example for "Multiple select boxes" and then repeatedly hitting the "a" and "tab" keys in very rapid succession to start and interrupt searching. It can take a a couple of minutes / a few hundred key strokes to trigger the problem, but sometimes it happens sooner.
Seen in Safari 9.0.2 on Mac OS 10.9.5; unknown whether it also affects other browsers.
Browser console JavaScript stack trace:
[Error] TypeError: undefined is not an object (evaluating 'item.id')  select2.full.js:862
(anonymous function) select2.full.js:861
each jquery.min.js:125
each jquery.min.js:26
(anonymous function) select2.full.js:855
current select2.full.js:3020
setClasses select2.full.js:847
(anonymous function) select2.full.js:1029
invoke select2.full.js:622
trigger select2.full.js:612
trigger select2.full.js:5320
(anonymous function) select2.full.js:5215
invoke select2.full.js:622
trigger select2.full.js:612
trigger select2.full.js:5320
(anonymous function) select2.full.js:5170
invoke select2.full.js:622
trigger select2.full.js:616
handleSearch select2.full.js:1986
(anonymous function) select2.full.js:579
(anonymous function) select2.full.js:1943
dispatch jquery.min.js:337
handle jquery.min.js:207:662

I seem to be getting this also


Fix Background Play

Currently The app has some issues with background play. When something is being played and we go to the song list/ menu it stops playing i.e. when the activity changes.

@Pra-San is this issue assigned to someone??

@RITIK-CHAUDHRY yes

Resolved


Cache 1 arc second resolution earth relief grid

Saves workshop users from having to all wait for a 214MB file download at the same time, and also mitigates against possibility of GMT server being down at a bad time. For anyone interested, the postBuild script runs grdimage with region (R) Oceania and projection (J) EPSG:4326.

Are you trying to download the earth_relief file? You can use gmt which -Gu @earth_relief_60m.grd instead.

Right, I knew there must be a better way! Thanks for the tip.


Updated http/1.1 to 2

@mattlunzer : Thanks for your contribution to the Azure documentation! The author, @KumudD, has been notified to review your proposed change.

As per the service PM, the change proposed in this PR is not technically accurate.
#please-close


Only query specified attributes.

With this PR, XRays do not yet use the attribute() function, correct?

With this PR, XRays do not yet use the attribute() function, correct?

They do, in https://github.com/googlecartographer/point_cloud_viewer/pull/367/files#diff-510d3c09c443afc25a26519f35942b99R483

Thanks a lot for your reviews!


Consider Nothing as scitype

So scitype(nothing) == Nothing in every convention

Codecov Report

Merging #112 into dev will increase coverage by 0.16%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev     #112      +/-   ##
==========================================
+ Coverage   97.05%   97.22%   +0.16%
==========================================
  Files           2        2
  Lines          34       36       +2
==========================================
+ Hits           33       35       +2
  Misses          1        1

Impacted Files
Coverage Δ

src/ScientificTypes.jl
92.30% <100.00%> (ø)

src/scitype.jl
100.00% <100.00%> (ø)

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 d352cb8...d29f9b5. Read the comment docs.


Alert reach Opsgenie with different deduplicating aliases even in the presence of group_by labels

What did you do?
Our development teams all have a route they can configure, matched by a label only they use. They all have a configured receiveer that relies on opsgenie_configs to integrate with a Prometheus integration they own in opsgenie.
In addition to this we have one more "wire-tap" opsgenie integration which gets absolutely all the alerts.
So X teams and X+1 opsgenie_configs blocks.
To support this setup we are grouping alerts with group_byand 3 labels present on all alerts: alertname, environment and namespace.
Alerts are flowing to opsgenie, hitting botht he wire-tapping route and the one specific for the team owning the system.
What did you expect to see?
We expected the alert sent to the wire-tapping route and the team's route to have the exact same opsgenie alias, so they get deduplicated in opsgenie.
That's also what we understood should work based on the official documentation at https://prometheus.io/docs/alerting/latest/configuration/#route
What did you see instead? Under which circumstances?
Alerts going throug wire-tapping and those going to teams have different aliases, leading to what we consider duplicate alerts in Opsgenie.
Environment

System information:
N/A

Alertmanager version:
From alert manager status page

Version Information
Branch:HEAD
BuildDate:20221222-14:51:36
BuildUser:root@abe866dd5717
GoVersion:go1.19.4
Revision:258fab7cdd551f2cf251ed0348f0ad7289aee789
Version:0.25.0

Prometheus version:
From Prometheus status page (web)

Version: 2.42.0
Revision: 225c61122d88b01d1f0eaaee0e05b6f3e0567ac0
branch: HEAD
BuildUser: root@c67d48967507
BuildDate: 20230201-07:53:32
GoVersion: go1.19.5

Alertmanager configuration file:
Complete file is big, extracting the relavant parts here, more can be provided if necessary.

global:
  resolve_timeout: 5m
  http_config:
    follow_redirects: true
    enable_http2: true
  smtp_hello: localhost
  smtp_require_tls: true
  opsgenie_api_url: https://api.opsgenie.com/
  opsgenie_api_key_file: /etc/alertmanager/secrets/opsgenie/api_key
route:
  receiver: "null"
  group_by:
  - alertname
  - namespace
  - environment
  continue: false
  routes:
  - receiver: global-config/global-config-prom-rules-prometheus-rules-signicat/null
    group_by:
    - alertname
    - namespace
    - environment
    matchers:
    - namespace="global-config"
    continue: true
    routes:
    - receiver: serviceX/Opsgenie
      matchers:
      - severity="critical"
      - environment="prod"
      continue: true
  - receiver: opsgenie
    matchers:
    - severity="critical"
    - signicat_cloud="gke-prod"
    continue: true
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
inhibit_rules:
- source_matchers:
  - severity="critical"
  target_matchers:
  - severity=~"warning|info"
  equal:
  - namespace
  - alertname
- source_matchers:
  - severity="warning"
  target_matchers:
  - severity="info"
  equal:
  - namespace
  - alertname
- source_matchers:
  - alertname="InfoInhibitor"
  target_matchers:
  - severity="info"
  equal:
  - namespace
receivers:
- name: opsgenie
  opsgenie_configs:
  - send_resolved: true
    http_config:
      follow_redirects: true
      enable_http2: true
    api_key_file: /etc/alertmanager/secrets/opsgenie/api_key
    api_url: https://api.opsgenie.com/
    message: '{{ template "opsgenie.default.message" . }}'
    description: '{{ template "opsgenie.default.description" . }}'
    source: '{{ template "opsgenie.default.source" . }}'
- name: serviceX/Opsgenie
  opsgenie_configs:
  - send_resolved: true
    http_config:
      follow_redirects: true
      enable_http2: true
    api_key: <secret>
    api_url: https://api.opsgenie.com/
    message: '{{ template "opsgenie.default.message" . }}'
    description: '{{ template "opsgenie.default.description" . }}'
    source: '{{ template "opsgenie.default.source" . }}'
templates:
- /etc/alertmanager/config/*.tmpl

Prometheus configuration file:
N/A, can be disclosed if relevant

Logs:
N/A

Some more information, because we've been looking into the code:

This is where the hash based on the group_by labels is created and set in the alias which Opsgenie relies on for deduplicating
If we're not mistaken the hash is hashing the string returned by this function.

And that's at 2 that we are confused: the hash seems to be tied to the route key, which is not explicit in the documentation - and we'd actually argue that it's simply not what the documentation promises and why this is filed as a bug: one should not have the routeKey as part of the hash, or provide a way to opt out of it, making the group_by list the only thing hashed.
Can you start confirming or correcting our findings? and then I hope we can discuss how to proceed and if you are open to a change.

Any feedback?


X509 certificates authorization

add X-ClickHouse-SSL-Certificate-Auth support
fix https://github.com/Altinity/clickhouse-grafana/issues/580

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

11 of 18 (61.11%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.05%) to 75.735%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/client.go
7
9
77.78%

src/datasource/datasource.ts
4
9
44.44%

Totals

Change from base Build<PHONE_NUMBER>6:
-0.05%

Covered Lines:
3498

Relevant Lines:
4393

💛  - Coveralls


[Gazebo project] as2_behavior_tree_main-1 ERROR

ROS2 Version
humble
Version
main
What happened?
When i run ./launch_as2.bash -b in Gazebo project, I get error:
[INFO] [as2_behavior_tree_main-1]: process started with pid [3741]
[as2_behavior_tree_main-1] [ERROR] [1687087606.296221559] [drone0.bt_manager]: "TakeOffBehavior" action server not available after waiting for 1 s
[as2_behavior_tree_main-1] terminate called after throwing an instance of 'std::length_error'
[as2_behavior_tree_main-1]   what():  basic_string::_M_create
[ERROR] [as2_behavior_tree_main-1]: process has died [pid 3741, exit code -6, cmd '/home/ubuntu/ros2/aerostack2_ws/install/as2_behavior_tree/lib/as2_behavior_tree/as2_behavior_tree_main --ros-args -r __ns:=/drone0 --params-file /tmp/launch_params_21ibjgk7'].

I use my own docker image (with your install instructions) based on tiryoh/ros2-desktop-vnc:humble

Second start after stop is ok. Looks It can be fixed by adding more wait time TakeOffBehavior action server before throw error.

But when i run python3 mission_behavior_tree.py dron does nothing and script ends instantly.

I understood reason of this empty end of python3 mission_behavior_tree.py, finally. It does not work without -t (keyboard teleoperation). You should add automatic start keyboard teleoperation when only -b key present.
I mean ./launch_as2.bash -b does not work now and ./launch_as2.bash -b -t works.

Relevant log output
No response

Tried ros2 topic pub /drone0/start std_msgs/msg/String "data: ''" 5 times with and without -t. All times it works fine.

No error on gazebo window neither? Spawn problems usually come from zombie processes in the background. Check if some gazebo bridges or similar did not die properly.


GAME CRASH DUE TO GLOW

When trying to turn on Glow, the game crashes out, while other functions work quietly.

When trying to turn on Glow, the game crashes out, while other functions work quietly.

Which operating system are you using? Windows or linux?

Windows 10 LSTC


[bootstrap] Refactor to be compatible with Python 2 or 3

The desire was expressed in MR #59 that the bootstrap script should be refactored to be compatible with both Python 2 and 3 rather than be hardcoded to one only. This patch refactors the bootstrap script
to do just that.
I was able to test this on OS X (Python 2.7.11) and on Arch Linux (Python 3.5.1).

Thanks for working on this!
This didn't work with my Python 2.7 (2.7.10) without:
from future import print_function
but worked with that. Do you know why you didn't see this in your testing?

I didn't, and probably still don't, not really a Python-ista. These porting patches are the first Python code I've ever written. I looked and I am using the Homebrew version of Python 2.7 (which is why mine is 2.7.11 and yours is not). Though that doesn't really explain anything and I was at a loss. ¯_(ツ)_/¯
All that having been said, the Python 2 docs for the print function clearly state:

This function is not normally available as a built-in since the name print is recognized as the print statement. To disable the statement and use the print() function, use this future statement at the top of your module:
from __future__ import print_function

Looks like it needs to be there. Therefore, I will add it and retest on Python 3.

With python3 I get:
$ python3 Utilities/bootstrap
Traceback (most recent call last):
  File "Utilities/bootstrap", line 721, in <module>
    main()
  File "Utilities/bootstrap", line 620, in main
    create_bootstrap_files(sandbox_path, opts)
  File "Utilities/bootstrap", line 349, in create_bootstrap_files
    link_input_nodes, predecessor_node)
  File "Utilities/bootstrap", line 229, in write_swift_compile_commands
    print("    other-args: %s" % json.dumps(' '.join(other_args)), file=output)
TypeError: sequence item 6: expected str instance, bytes found

@mxcl when I run that command I get:
$ python3 Utilities/bootstrap
bootstrap: error: unable to find 'swift-build-tool' tool for bootstrap build

Did you give it other command line args?

You will need to point it at a copy of swift-build-tool (built from llbuild) or have it available in your path. See --help for the full list of options.

Daniel

On Jan 4, 2016, at 10:46 AM, Ryan Lovelett<EMAIL_ADDRESS>wrote:
@mxcl https://github.com/mxcl when I run that command I get:
$ python3 Utilities/bootstrap
bootstrap: error: unable to find 'swift-build-tool' tool for bootstrap build
Did you give it other command line args?
—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-package-manager/pull/108#issuecomment-168764810.

I use:
export PATH="/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin:$PATH"

To set up my environment first.

I just want to say I have not abandoned this. I'm just having a problem with my system.

Ok I've updated to 556b404. I missed a few subprocess.check_output method calls that needed to have universal_newlines=True added to the argument list.
@mxcl this should now fix the problem you illustrated. Here was the test I ran from the root of the swiftpm repository.
$ export PATH="/Library/Developer/Toolchains/swift-latest.xctoolchain/usr/bin:$PATH"
$ rm -rf .build && python2 Utilities/bootstrap
$ rm -rf .build && python3 Utilities/bootstrap

Tested on all platforms, works good, thanks 👍🏻