Improve "Add Node" workflows in the graph editor

Context Aware "Add Node" Workflow
Previously, the tab menu was the only way to add new nodes to the graph editor. Now users can select any pin in the graph, and drag a link off of that pin. If this link does not connect to another pin, on mouse release, the user will be prompted to add a new node. The list of nodes that users can add will be filtered to only include nodes that can be connected to the pin from which this link originates.
This context-aware node filtering in the "Add Node" popup can be toggled on/off with the "Smart Filter" check box.
Demo 🥳

Notice how as you toggle the Smart Filter on and off, the list of allowable nodes changes as well. When Smart Filter is off, every  defined node is allowed to be added.
One future improvement:
Right now, when dragging a link from a pin, nodes that have valid connections are shown in the "Add Node" popup. We could make this popup even more granular -- show both the node name and the specific pin of that node that would be connected by this link. Certain nodes have multiple input or output pins of the same type. By having separate entries for each of the specific pins as well, users can select which pin they want to be connected in the newly added node, and when that node is added, we can automatically draw that link for them.

@jstone-lucasfilm Ach so sorry about that -- I wasn't getting email notifications for github since I haven't signed into this email account since college 😅 . I'll get the license and build errors fixed ASAP. Apologies!

License + build errors fixed @jstone-lucasfilm 😃

@GregoryD2017 In order to keep this proposal moving forward, make sure to resolve the merge conflicts mentioned above!  This change still seems promising, but we'll need to keep it up-to-date with the main branch in order to provide meaningful review.

@GregoryD2017 If you're interested in continuing work on this proposal, we'll be starting Dev Days 2024 on September 25th!

I'll close out this pull request for now, @GregoryD2017, but feel free to pick up work on this in a future Dev Days event!


fix: encode shell args to avoid command injection

Codecov Report

Merging #406 (e59e6b4) into main (1b1baa9) will decrease coverage by 0.28%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #406      +/-   ##
==========================================
- Coverage   64.45%   64.16%   -0.29%
==========================================
  Files          41       41
  Lines        7298     7298
==========================================
- Hits         4704     4683      -21
- Misses       2225     2239      +14
- Partials      369      376       +7

Impacted Files
Coverage Δ

pkg/agent/controller/policy/policy_controller.go
76.52% <0.00%> (-1.47%)
:arrow_down:

plugin/tower/pkg/controller/policy/controller.go
82.97% <0.00%> (-0.72%)
:arrow_down:

pkg/controller/group/group_controller.go
71.63% <0.00%> (-0.54%)
:arrow_down:

pkg/agent/datapath/multiBridgeDatapath.go
58.53% <0.00%> (-0.53%)
:arrow_down:

pkg/monitor/agent.go
71.21% <0.00%> (-0.50%)
:arrow_down:


Automatic removal of failed sessions

Automatically remove failed sessions after a period of time.

This could potentially move to amalthea.

Moved to amalthea and resolved already https://github.com/SwissDataScienceCenter/amalthea/pull/158


replace fmincon for octave

Gabriel feedback:
Information found on Octave compatibility function fmincon
Solutions:
1) function sqp(x0, phi) -> Not exactly the same as fmincon so might provoke errors if the code is not adapted
2)function nonlin_min (f, pin, settings) -> Same as before
3)download Optimization package for Octave forge with fmincon function
4) function npsol in octave

Continuing research

I created a new issue for that so that we don't get mixed we other comments.
My comments:

The optimization package is already part of qMRLab. (installed in startup.m) You can use it if needed.
fmincon is used exclusively in all diffusion models. ex:

            if ~moxunit_util_platform_is_octave
                [xopt, residue] = fmincon(@(x) double(-2*sum(scd_model_likelihood_rician(datadif,max(eps,S0.*equation(obj, addfixparameters(obj.st,x,fixedparam))), SigmaNoise))), double(obj.st(~fixedparam)), [], [], [],[],double(obj.lb(~fixedparam)),double(obj.ub(~fixedparam)),[],optimoptions('fmincon','MaxIter',20,'display','off','DiffMinChange',0.03));
                obj.st(~fixedparam) = xopt; xopt = obj.st;
            end

You can compare validate the fitting of Octave using the Sim_Single_Voxel_Curve method. See function test_sim of test_Models.m. Let me know when you think you have a good solution and I'll test that.

Resolved #298.


Extends check_devices tasks to non-collocated an lvm-batch scenarios

Extends check_devices tasks to non-collocated an lvm-batch scenarios and
Tuned name of a task and error message to make it more user understandable
Fixes BZ 1648168 - ceph-validate : devices are not validated in non-collocated and lvm_batch scenario
Signed-off-by: VasishtaShastry<EMAIL_ADDRESS>

@andrewschoen can you please advise? Thanks

jenkins test dev-lvm_batch

any update on this @VasishtaShastry ?

Closing this in favor of #3641


[Java Client v4] Set up project in conductor-clients/java

conductor-clients dir is going to be the home of Conductor clients/sdks
Acceptance Criteria

Move the incubating Java Client/SDK v4 into the conductor-clients directory under /java.
Set up build pipelines (GitHub Actions) for the new directory structure.
Clean up and organize files as needed to ensure consistency and functionality.

Initial changes were merged here: https://github.com/conductor-oss/conductor/pull/255
CI setup
-- https://github.com/conductor-oss/conductor/pull/259
-- https://github.com/conductor-oss/conductor/pull/260
-- https://github.com/conductor-oss/conductor/pull/268

With these changes Gradle config refactoring https://github.com/conductor-oss/conductor/pull/270 and now that integration tests are running correctly we can consider this done.


Feigenbaum-1

For the next testnet:

#631
#157 and #677
#372
#81
#678
#711
#712
cont. stability testing and profiling

Nice to haves:

#193
#674
#675

┆Issue is synchronized with this Asana task by Unito

Closing this as no longer relevant.


ssocr: init at 2018-08-11

Motivation for this change
Things done

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

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

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

@grahamcofborg build ssocr

Success on aarch64-linux (full log)
Attempted: ssocr
Partial log (click to expand)
install -m 0644 AUTHORS COPYING INSTALL README THANKS /nix/store/6kj2h0h08j8sfgb5aksqxrxycpqh2gs7-ssocr-unstable-2018-08-11/share/doc/ssocr
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/6kj2h0h08j8sfgb5aksqxrxycpqh2gs7-ssocr-unstable-2018-08-11
shrinking /nix/store/6kj2h0h08j8sfgb5aksqxrxycpqh2gs7-ssocr-unstable-2018-08-11/bin/ssocr
gzipping man pages under /nix/store/6kj2h0h08j8sfgb5aksqxrxycpqh2gs7-ssocr-unstable-2018-08-11/share/man/
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/6kj2h0h08j8sfgb5aksqxrxycpqh2gs7-ssocr-unstable-2018-08-11/bin
patching script interpreter paths in /nix/store/6kj2h0h08j8sfgb5aksqxrxycpqh2gs7-ssocr-unstable-2018-08-11
checking for references to /build in /nix/store/6kj2h0h08j8sfgb5aksqxrxycpqh2gs7-ssocr-unstable-2018-08-11...
/nix/store/6kj2h0h08j8sfgb5aksqxrxycpqh2gs7-ssocr-unstable-2018-08-11

Success on x86_64-darwin (full log)
Attempted: ssocr
Partial log (click to expand)
install -s -m 0755 ssocr /nix/store/b1ya5i8gydlkf8wx1wcs1445axxbynbr-ssocr-unstable-2018-08-11/bin/ssocr
install -m 0644 ssocr.1 /nix/store/b1ya5i8gydlkf8wx1wcs1445axxbynbr-ssocr-unstable-2018-08-11/share/man/man1/ssocr.1
gzip -9 /nix/store/b1ya5i8gydlkf8wx1wcs1445axxbynbr-ssocr-unstable-2018-08-11/share/man/man1/ssocr.1
install -m 0644 AUTHORS COPYING INSTALL README THANKS /nix/store/b1ya5i8gydlkf8wx1wcs1445axxbynbr-ssocr-unstable-2018-08-11/share/doc/ssocr
post-installation fixup
gzipping man pages under /nix/store/b1ya5i8gydlkf8wx1wcs1445axxbynbr-ssocr-unstable-2018-08-11/share/man/
strip is /nix/store/4w56qihlrddav67p7d1vy5qkyayaqw11-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/b1ya5i8gydlkf8wx1wcs1445axxbynbr-ssocr-unstable-2018-08-11/bin
patching script interpreter paths in /nix/store/b1ya5i8gydlkf8wx1wcs1445axxbynbr-ssocr-unstable-2018-08-11
/nix/store/b1ya5i8gydlkf8wx1wcs1445axxbynbr-ssocr-unstable-2018-08-11

Success on x86_64-linux (full log)
Attempted: ssocr
Partial log (click to expand)
install -m 0644 AUTHORS COPYING INSTALL README THANKS /nix/store/kl9fzmx753b57kkxr9c97wpqmq1g8js6-ssocr-unstable-2018-08-11/share/doc/ssocr
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/kl9fzmx753b57kkxr9c97wpqmq1g8js6-ssocr-unstable-2018-08-11
shrinking /nix/store/kl9fzmx753b57kkxr9c97wpqmq1g8js6-ssocr-unstable-2018-08-11/bin/ssocr
gzipping man pages under /nix/store/kl9fzmx753b57kkxr9c97wpqmq1g8js6-ssocr-unstable-2018-08-11/share/man/
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/kl9fzmx753b57kkxr9c97wpqmq1g8js6-ssocr-unstable-2018-08-11/bin
patching script interpreter paths in /nix/store/kl9fzmx753b57kkxr9c97wpqmq1g8js6-ssocr-unstable-2018-08-11
checking for references to /build in /nix/store/kl9fzmx753b57kkxr9c97wpqmq1g8js6-ssocr-unstable-2018-08-11...
/nix/store/kl9fzmx753b57kkxr9c97wpqmq1g8js6-ssocr-unstable-2018-08-11


Draft: Ruff

Apply ruff check to the repository.

Awesome, thanks! I skimmed through the unsafe changes on mobile. The vast majority look good, but there's a few where variables are switched to private versions, or assignments are removed completely, that I need to be on my desktop to go dig into the context to see if they're ok. Some of the unit tests seem to be failing in a meaningful way, so hopefully these are connected issues and resolving my red flag changes will trivially resolve the (non-ruff) test issues. I'm afraid I won't be able to dig into it until tomorrow afternoon.

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

0 of 0   changed or added relevant lines in 0 files are covered.
69 unchanged lines in 10 files lost coverage.
Overall coverage increased (+0.02%) to 91.518%

Files with Coverage Reduction
New Missed Lines
%

type_hinting.py
1
97.73%

mixin/run.py
1
93.64%

nodes/transform.py
3
98.25%

nodes/static_io.py
3
85.71%

storage.py
3
96.23%

mixin/semantics.py
6
96.67%

nodes/composite.py
9
91.67%

io.py
10
94.24%

node.py
16
90.91%

workflow.py
17
66.17%

Totals

Change from base Build<PHONE_NUMBER>0:
0.02%

Covered Lines:
3086

Relevant Lines:
3372

💛  - Coveralls

Awesome, thanks! I skimmed through the unsafe changes on mobile. The vast majority look good, but there's a few where variables are switched to private versions, or assignments are removed completely, that I need to be on my desktop to go dig into the context to see if they're ok. Some of the unit tests seem to be failing in a meaningful way, so hopefully these are connected issues and resolving my red flag changes will trivially resolve the (non-ruff) test issues. I'm afraid I won't be able to dig into it until tomorrow afternoon.

The unit test failures all happened because ruff removed unnecessarily complicated code. However, this was used to trigger things in pyiron_workflow which does not happen anymore. I reverted all the changes that broke tests and annoted them so they do not get changed in the future. Test CI is now green.

Now come the more complicated issues.
How do you feel about F401 and the top-level pyiron_workflow import?
Error: pyiron_workflow/create.py:47:5: B019 Use of functools.lru_cache or functools.cache on methods can lead to memory leaks also seems like an issue we should look into.
I will do further fixes by hand.

How do you feel about F401 and the top-level pyiron_workflow import?

The problem is they are only "unused" in a very technical sense that they are not further referenced in that file. In reality, they are used to specify what makes up the "public API" for the sake of semantic versioning. AFAIK there is no standard for how to do this, but however it is done it should be clear. I find this is both technically clear (there is a comment in the file stating that the imports here make up the public API) and practically clear (this is what's easiest for the public to access). So in the absence of a better way to accomplish this goal, these imports should not be removed.

Error: pyiron_workflow/create.py:47:5: B019 Use of functools.lru_cache or functools.cache on methods can lead to memory leaks also seems like an issue we should look into.

This is a good point. I would need to dig into it deeper to say something with absolutely certainty, but after a ten minute investigation I'm at least cautiously optimistic: it sounds like the concern is that the cache prevents the self argument of the cached methods from being released by the garbage collector. In our particular case, these ruff errors are all coming from pyiron_workflow.create.Creator, which is a singleton that gets referenced by every Composite instance. So we're only preserving a reference to a single instance of this thing, and it's not likely we ever want to garbage collect it until we're totally done working with pyiron_workflow anyhow.

How do you feel about F401 and the top-level pyiron_workflow import?

The problem is they are only "unused" in a very technical sense that they are not further referenced in that file. In reality, they are used to specify what makes up the "public API" for the sake of semantic versioning. AFAIK there is no standard for how to do this, but however it is done it should be clear. I find this is both technically clear (there is a comment in the file stating that the imports here make up the public API) and practically clear (this is what's easiest for the public to access). So in the absence of a better way to accomplish this goal, these imports should not be removed.

So which solution do you prefer? I think using the file for the public API is totally valid. I vote for the __all__ solution. Second best option without a preference are silencing the warning or doing a redundant import alias.

Error: pyiron_workflow/create.py:47:5: B019 Use of functools.lru_cache or functools.cache on methods can lead to memory leaks also seems like an issue we should look into.

This is a good point. I would need to dig into it deeper to say something with absolutely certainty, but after a ten minute investigation I'm at least cautiously optimistic: it sounds like the concern is that the cache prevents the self argument of the cached methods from being released by the garbage collector. In our particular case, these ruff errors are all coming from pyiron_workflow.create.Creator, which is a singleton that gets referenced by every Composite instance. So we're only preserving a reference to a single instance of this thing, and it's not likely we ever want to garbage collect it until we're totally done working with pyiron_workflow anyhow.

Yes, the concerns are twofold. a) garbage collection might not work due to the captured self, like you pointed out and b) a separate cache will be built for every instance. Meaning, even though the function call might be exactly the same, if it is called from a different instance, it is not.
I personally do not like singletons at all and I do not like the idea of "we do not use it wrongly" as that might change without notice in the future. Therefore, I vote for fixing it.

Error: pyiron_workflow/create.py:47:5: B019 Use of functools.lru_cache or functools.cache on methods can lead to memory leaks also seems like an issue we should look into.

This is a good point. I would need to dig into it deeper to say something with absolutely certainty, but after a ten minute investigation I'm at least cautiously optimistic: it sounds like the concern is that the cache prevents the self argument of the cached methods from being released by the garbage collector. In our particular case, these ruff errors are all coming from pyiron_workflow.create.Creator, which is a singleton that gets referenced by every Composite instance. So we're only preserving a reference to a single instance of this thing, and it's not likely we ever want to garbage collect it until we're totally done working with pyiron_workflow anyhow.

As far as I can see you are using it to cache module imports? Is it really worth doing this?
https://docs.python.org/3/reference/import.html#the-module-cache

As far as I can see you are using it to cache module imports? Is it really worth doing this?

There are also cases where we're instantiating a dictionary with modules as elements. I'm sure that's slower than the module cache access. I'm happy to abandon caching and use straight properties, but I would still do a quick timeit check on, e.g., Workflow.create.transformer with and without the caching to double-check that it is as cheap as we imagine.

So which solution do you prefer? I think using the file for the public API is totally valid. I vote for the __all__ solution. Second best option without a preference are silencing the warning or doing a redundant import alias.

I would prefer silencing the error as it's the most explicit resolution to the problem -- i.e. the linter simply (and fairly) isn't sophisticated enough to understand our intent with the imports, so just let it know. I'm also open to redundant aliases. I have a strong preference against __all__, because it has the side effect of allowing people to from pyiron_workflow import * -- I don't want to read code that uses this feature, and since I get pinged to debug pyiron_workflow code I choose to simply disallow it 😝

if we de-singleton the creator then we MUST NOT allow such a return [to a registration system], as it will make the shortcuts hell again.

As long as you're on board with this take, I would stack some PRs on this to:

De-singleton classes in create
Check the timing and (probably) remove the caching in create
Touch up the remaining complaints and implement the formatting suggestions

So which solution do you prefer? I think using the file for the public API is totally valid. I vote for the __all__ solution. Second best option without a preference are silencing the warning or doing a redundant import alias.

I would prefer silencing the error as it's the most explicit resolution to the problem -- i.e. the linter simply (and fairly) isn't sophisticated enough to understand our intent with the imports, so just let it know. I'm also open to redundant aliases. I have a strong preference against __all__, because it has the side effect of allowing people to from pyiron_workflow import * -- I don't want to read code that uses this feature, and since I get pinged to debug pyiron_workflow code I choose to simply disallow it 😝

I did it.

if we de-singleton the creator then we MUST NOT allow such a return [to a registration system], as it will make the shortcuts hell again.

As long as you're on board with this take, I will stack some PRs on this to:

[ ]  De-singleton classes in create
[ ]  Check the timing and (probably) remove the caching in create
[ ]  Touch up the remaining complaints and implement the formatting suggestions

Let's keep the singleton if this is what you want. I would prefer removing Creator and Wrappers and enforce "import-what-you-want`, i.e. the pattern you mentioned above.
Check timing, go for it.
Formatting, we do not need to include ruff format. As long as we do have a formatter in place, I am fine. And black is a good choice. At some point I would extend the black coverage to also tests. Unfortunately, black also does the ugly multiline string formatting. I agree with you the other indentation style looks nicer.

What is wrong with
from pyiron_workflow import Workflow
import some_node_package as snp
...
wf.some_node = snp.SomeNode(...)

To me, that is very clear and explicit.

💯. Nothing is wrong with it. This is how we do it and how I want to keep doing it!

I did it.

Awesome, thanks! I had imagined we needed to do a line-by-line ignore; that patch is nice and simple.

Let's keep the singleton if this is what you want. I would prefer removing Creator and Wrappers and enforce "import-what-you-want`, i.e. the pattern you mentioned above.

This is my preference and how I use it, because I already know what I'm looking for. One of the "pyiron" ideas is to lean heavily tab completion, and one way to do that is being able to import a single object that acts as a starting point object for all the built-in functionality (i.e. Workflow). It's not my preferred usage strategy, but I see why others like it and we're not likely to convince the whole team, so I think the lesser evil is to continue to support both approaches.
For "third party" tools, like individual node packages, I think we'll be able to keep everyone on the same page with "import what you want".

Check timing, go for it.

👍

Formatting, we do not need to include ruff format. As long as we do have a formatter in place, I am fine. And black is a good choice. At some point I would extend the black coverage to also tests. Unfortunately, black also does the ugly multiline string formatting. I agree with you the other indentation style looks nicer.

Ok, I'm also content to stick with black. It doesn't complain about the multiline indentation as it is, which is my biggest complaint with ruff. That said, ruff highlighted a few changes I do prefer, so I will probably just run it locally every now and then and cherry pick the suggested changes that improve readability. For the CI we can stick with black.

Let's keep the singleton if this is what you want. I would prefer removing Creator and Wrappers and enforce "import-what-you-want`, i.e. the pattern you mentioned above.

This is my preference and how I use it, because I already know what I'm looking for. One of the "pyiron" ideas is to lean heavily tab completion, and one way to do that is being able to import a single object that acts as a starting point object for all the built-in functionality (i.e. Workflow). It's not my preferred usage strategy, but I see why others like it and we're not likely to convince the whole team, so I think the lesser evil is to continue to support both approaches.
For "third party" tools, like individual node packages, I think we'll be able to keep everyone on the same page with "import what you want".

But you do get almost the same tab completion with imports?!?
import some_node_package as snp
wf.some_node = snp.<tab>

vs
wf.register("some_node_package", "snp")
wf.some_node = wf.create.snp.<tab>

I do not really see the point.

Formatting, we do not need to include ruff format. As long as we do have a formatter in place, I am fine. And black is a good choice. At some point I would extend the black coverage to also tests. Unfortunately, black also does the ugly multiline string formatting. I agree with you the other indentation style looks nicer.

Ok, I'm also content to stick with black. It doesn't complain about the multiline indentation as it is, which is my biggest complaint with ruff. That said, ruff highlighted a few changes I do prefer, so I will probably just run it locally every now and then and cherry pick the suggested changes that improve readability. For the CI we can stick with black.

That is a misperception. black does not complain because you do not run it on the test directory ;) For pyiron_workflow ruff format only adds trailing commas to lists which I can see why you might want to have that.

But you do get almost the same tab completion with imports?!?
import some_node_package as snp
wf.some_node = snp.<tab>

vs
wf.register("some_node_package", "snp")
wf.some_node = wf.create.snp.<tab>

I do not really see the point.

Yes, you're preaching to the choir. Leveraging the top-level __init__ file to define the API gives exactly this advantage. This (or from pyiron_workflow...) is how I use the package myself, and I try to be consistent in using it that way for demos, examples, and use cases I touch (e.g. in pyiron_nodes) in an attempt to shift the user-culture towards what I see as a better approach.
But this is what I'm trying to communicate, the presence of an importable starting point class that is equiped with (nearly) the same tab-completion capabilities is a cultural feature expectation of our community of users. In my estimation, the culture has not yet shifted enough to simply axe this feature  without complaint. Maybe I'm wrong. I don't feel strongly enough to push for a step-change on this; if you do you're welcome to suggest it at the next meeting in January, and I'm happy to say I agree with you, but I'm not willing to fight anyone for the change.

black does not complain because you do not run it on the test directory ;)

🤦♂ 😂 derp, yep!

For pyiron_workflow ruff format only adds trailing commas to lists which I can see why you might want to have that.

Yes, I like those. I also noticed a couple newlines and some other small stuff I liked.
Black is sufficient, but actually it would probably be nice to extend the black to cover the tests too -- https://github.com/pyiron/actions/issues/137

Once #526 and #527 are merged down, I'm happy and I think we've done everything discussed here.


Fix #90

<!-- Make sure you have read http://napalm.readthedocs.io/en/latest/contributing/index.html --!>

Coverage increased (+0.1%) to 79.705% when pulling 9aedd6b04967e11ce38c95bbabffbcddf0aeb65d on mirceaulinic:FIX-90 into 4fb8c60400014ff394f8a18f4a1a24bb4d72e83a on napalm-automation:develop.

Coverage increased (+0.1%) to 79.705% when pulling 9aedd6b04967e11ce38c95bbabffbcddf0aeb65d on mirceaulinic:FIX-90 into 4fb8c60400014ff394f8a18f4a1a24bb4d72e83a on napalm-automation:develop.

Coverage increased (+0.1%) to 79.705% when pulling 9aedd6b04967e11ce38c95bbabffbcddf0aeb65d on mirceaulinic:FIX-90 into 4fb8c60400014ff394f8a18f4a1a24bb4d72e83a on napalm-automation:develop.

Coverage increased (+0.2%) to 79.828% when pulling 4696ee5ddf511b9710b10f1222b3563e75d5a532 on mirceaulinic:FIX-90 into 4fb8c60400014ff394f8a18f4a1a24bb4d72e83a on napalm-automation:develop.

Coverage increased (+0.2%) to 79.828% when pulling 0c1042a404b8968a8a943cca6324cfebdae12b95 on mirceaulinic:FIX-90 into 4fb8c60400014ff394f8a18f4a1a24bb4d72e83a on napalm-automation:develop.

I just have that one single comment, the rest looks good.

Coverage increased (+0.2%) to 79.753% when pulling fbbe7ec4ba261e6f4bcb87b737df57c00947bbf9 on mirceaulinic:FIX-90 into 4fb8c60400014ff394f8a18f4a1a24bb4d72e83a on napalm-automation:develop.

Coverage increased (+0.2%) to 79.753% when pulling fbbe7ec4ba261e6f4bcb87b737df57c00947bbf9 on mirceaulinic:FIX-90 into 4fb8c60400014ff394f8a18f4a1a24bb4d72e83a on napalm-automation:develop.


Change the resumable query API

There were couple of problems with it:

We don't use the async prefix in async method names in the public API
We don't return the result for APIs that returns Success string only

So, I have changed the implementation to fix these problems.
Also, I think it is much better to return the first batch of the results directly to the user, along with an handle to fetch more or stop. This is more similar to API we have in JS SDK, makes the possible misuses impossible (you can't call stop before the start anymore etc.), and makes more sense for the async version. For the async version, we previously marked the function async but did not call any async functions, which was weird.
Also, I have changed the tests a bit to make them more resillient to failures due to potentially delayed indexing, which might happen from time to time.

Yeah I kinda agree with this interface. Within the first PR, this was the interface that I was going with, but I changed it to be able to use with statements better, which I thought would be the default way to use. Thanks for the update.


Update Copyright Headers to 2023

Update Copyright Headers to 2023

@BHoMBot check copyright-compliance

@BHoMBot check project-compliance

@BHoMBot this is a DevOps instruction. I am requesting neutral checks on: core, code-compliance, dataset-compliance, documentation-compliance, serialisation, null-handling, unit-tests, ready-to-merge

@BHoMBot this is a DevOps instruction. I am requesting neutral checks on: project-compliance


how can I use C++example with per-build and mxnet.cpp

when I use MxnetTestApp.sln I can run mlp.cpp success,but when I replace mlp.cpp with other example such as googlenet.cpp ,there is a problem.

It seems you are using the CPU-only version of pre-built library and you
used GPU device in the code. You can either use the GPU version library or
use only CPU device in the code.
On Sun, Aug 7, 2016 at 11:40 AM, Dianxj<EMAIL_ADDRESS>wrote:

when I use MxnetTestApp.sln I can run mlp.cpp success,but when I replace
mlp.cpp with other example such as googlenet.cpp ,there is a problem.
[image: image]
https://cloud.githubusercontent.com/assets/17945397/17460328/93063360-5c93-11e6-908f-21fb145e8a9a.png
[image: image]
https://cloud.githubusercontent.com/assets/17945397/17460332/a6d3e64e-5c93-11e6-85cf-24e1ad83a69b.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dmlc/mxnet/issues/2949, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABFI4ZbaVvaxdE8oPgPtrFbGxT3NnzITks5qdVObgaJpZM4JeawV
.

This issue is closed due to lack of activity in the last 90 days. Feel free to reopen if this is still an active issue. Thanks!


"Watch" grpc API not ending when input stream is closed

It seems that the "Watch" API do not end when the input stream is closed. I also see that the Go client use cancel() to forcely close the watch stream. Is there a reason for not ending the watch stream? Or if is cancelling the stream API the only correct way to end a watch stream?

@hubo1016 the client will attach multiple watches to a single grpc stream for connection efficiency. Canceling a Watch shouldn't take down the entire grpc stream unless there are no other watches on the stream. Calling Close on a clientv3 Watcher will close all the grpc streams it made, but usually cancel() on the ctx passed to client.Watch(ctx, "key") is enough and preferred. Is there a particular use case you have in mind?

@heyitsanthony I'm developing a Python binding for etcdv3. I've noticed that even closing the input stream do not end the API call, so there is no "graceful" way to shutdown the API stream. Many other streaming API like Lease.LeaseKeepAlive DO exit when the input stream is closed.
If it is an intended behavior, I will try cancel()

@hubo1016 closing the input stream won't close the watch on the server side because there may still be open watches streaming events. This is important for the grpc json gateway because without websockets, it will close the input stream immediately after setting up the first watch, and would never receive events.
Also, in case you haven't seen it, there's already two python bindings for v3:

https://github.com/kragniz/python-etcd3
https://github.com/crossbario/txaio-etcd

@heyitsanthony I'm developing an asyncio Python binding for etcdv3. It is just a simple async wrapper on grpc.io, based on https://github.com/hubo1016/aiogrpc

Questions have been answered; closing.


Simple Mode

APM has a flight mode for copters called "Simple mode", which allows the pilot to control a copter regardless its heading. Basically, the copter will take the heading when it's armed as the front direction, though the real heading may change during flying. It's extremely helpful for the beginners. This feather is also supported by Multii Wii Copter, known as "Head Free Mode". Do you have any interest to introduce this feature into px4's firmware?

I believe that's called "Simple mode" but that might have been a typo

OOPS, true

Is anyone still interested in this? I think it would be fairly easy to implement as a position control submode, especially once we refactor the manual setpoint handling into stick mapper.

I'll consider this once we have the stick mapper.

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)


BadgeText DataType corrected from bool to string

Fixes #
Docs for Toolkit PR #
What changes to the docs does this PR provide?

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

[x] For new pages, used the provided template.
[x] For new features, added an entry in the Table of Contents.
[x] Ran against a spell and grammar checker.
[x] Contains NO breaking changes.

Other information

Docs Build status updates of commit c4f5c2d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/views/tabview.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Great catch, thanks!


Scroll field into view when clicking on table of contents row

 Implement "add case" UI flow structure

Codecov Report

Merging #264 into master will decrease coverage by 1.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #264      +/-   ##
==========================================
- Coverage   60.04%   59.04%   -1.01%
==========================================
  Files          13       13
  Lines         413      420       +7
  Branches       96       96
==========================================
  Hits          248      248
- Misses        165      172       +7

Impacted Files
Coverage Δ

.../curator-service/ui/src/components/NewCaseForm.tsx
69.69% <0.00%> (-18.77%)
:arrow_down:

Continue to review full report at Codecov.

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

Nice! gif would be awesome, but I know I ask for too much.

Added


Excess output to console when chatting in game.

I was trying to get a suffix working and noticed that there was alot of excess output in the console when sending out a test message in chat.
I am not sure if my failed attempt at making a suffix is to blame, but as soon as I set it I was disconnected from the server. The command I gave to create the suffix was "/lp group owner meta addsuffix 100 " &c[&nAdmin&n]". Looking back im sure I was not supposed to try and end &n with a ''.
Anyways, I relogged and tried a test and the suffix was not there at all. It was at this point that I took a look at the console and saw a bunch of messages. I cleared out the suffix but the console is still outputting in abundance. I even tried logging out, restarting the server and relogging, but still the same thing.
I'm using LuckPerms-Sponge-3.2.60.jar on a spongeforge-1.12-2443-7.0.0-BETA-2498.jar server running MC version 1.12
Any help would be appreciated.

12.09 21:19:10 [Server] Server thread/INFO [Eonox][l]: Test
12.09 21:19:10 [Server] Server thread/ERROR [Sponge]: Could not pass MessageChannelEvent$Chat$Impl to Plugin{id=nucleus, name=Nucleus, version=1.1.3-LTS-S5.1, description=The Ultimate Essentials Plugin., source=/mods/Nucleus-1.1.3-LTS-S5.1-MC1.10.2-plugin.jar}
12.09 21:19:10 [Server] INFO java.lang.ClassCastException: me.lucko.luckperms.sponge.service.model.SubjectReference cannot be cast to org.spongepowered.api.service.permission.Subject
12.09 21:19:10 [Server] INFO at io.github.nucleuspowered.nucleus.modules.chat.util.TemplateUtil.getTemplate(TemplateUtil.java:61) ~[TemplateUtil.class:1.1.3-LTS-S5.1]
12.09 21:19:10 [Server] INFO at io.github.nucleuspowered.nucleus.modules.chat.listeners.ChatListener.onPlayerChat(ChatListener.java:152) ~[ChatListener.class:1.1.3-LTS-S5.1]
12.09 21:19:10 [Server] INFO at org.spongepowered.common.event.listener.ChatListener_ChatListener_onPlayerChat114.handle(Unknown Source) ~[?:?]
12.09 21:19:10 [Server] INFO at org.spongepowered.common.event.RegisteredListener.handle(RegisteredListener.java:95) ~[RegisteredListener.class:1.12-2443-7.0.0-BETA-2498]
12.09 21:19:10 [Server] INFO at org.spongepowered.mod.event.SpongeModEventManager.post(SpongeModEventManager.java:314) [SpongeModEventManager.class:1.12-2443-7.0.0-BETA-2498]
12.09 21:19:10 [Server] INFO at org.spongepowered.mod.event.SpongeModEventManager.post(SpongeModEventManager.java:265) [SpongeModEventManager.class:1.12-2443-7.0.0-BETA-2498]
12.09 21:19:10 [Server] INFO at net.minecraftforge.fml.common.eventhandler.EventBus.postForgeAndCreateSpongeEvent(EventBus.java:594) [EventBus.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.network.NetHandlerPlayServer.handler$injectChatEvent$zpe000(NetHandlerPlayServer.java:2811) [oy.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.network.NetHandlerPlayServer.func_147354_a(NetHandlerPlayServer.java:932) [oy.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.network.play.client.CPacketChatMessage.func_148833_a(SourceFile:37) [la.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.network.play.client.CPacketChatMessage.func_148833_a(SourceFile:9) [la.class:?]
12.09 21:19:10 [Server] INFO at org.spongepowered.common.network.PacketUtil.lambda$onProcessPacket$0(PacketUtil.java:147) [PacketUtil.class:1.12-2443-7.0.0-BETA-2498]
12.09 21:19:10 [Server] INFO at org.spongepowered.common.network.PacketUtil$$Lambda$1308/47245896.call(Unknown Source) [PacketUtil.class:1.12-2443-7.0.0-BETA-2498]
12.09 21:19:10 [Server] INFO at org.spongepowered.common.event.tracking.CauseTracker.switchToPhase(CauseTracker.java:161) [CauseTracker.class:1.12-2443-7.0.0-BETA-2498]
12.09 21:19:10 [Server] INFO at org.spongepowered.common.network.PacketUtil.onProcessPacket(PacketUtil.java:146) [PacketUtil.class:1.12-2443-7.0.0-BETA-2498]
12.09 21:19:10 [Server] INFO at net.minecraft.network.PacketThreadUtil$1.redirect$onProcessPacket$zjo000(SourceFile:539) [hv$1.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.network.PacketThreadUtil$1.run(SourceFile:13) [hv$1.class:?]
12.09 21:19:10 [Server] INFO at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) [?:1.8.0_45]
12.09 21:19:10 [Server] INFO at java.util.concurrent.FutureTask.run(Unknown Source) [?:1.8.0_45]
12.09 21:19:10 [Server] INFO at net.minecraft.util.Util.func_181617_a(SourceFile:46) [h.class:?]
12.09 21:19:10 [Server] INFO at org.spongepowered.common.SpongeImplHooks.onUtilRunTask(SpongeImplHooks.java:269) [SpongeImplHooks.class:1.12-2443-7.0.0-BETA-2498]
12.09 21:19:10 [Server] INFO at net.minecraft.server.MinecraftServer.redirect$onRun$zia000(MinecraftServer.java:3988) [MinecraftServer.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:720) [MinecraftServer.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:391) [nx.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:665) [MinecraftServer.class:?]
12.09 21:19:10 [Server] INFO at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:523) [MinecraftServer.class:?]
12.09 21:19:10 [Server] INFO at java.lang.Thread.run(Unknown Source) [?:1.8.0_45]

Try using a lower version of Sponge Forge as some big changes happened. I can recommend a version about a week old.

Or rather, the right version of Nucleus for your server. :)
(you're running an API 5 build but your server is API 7)


bytes: Allow for float byte sizes

This implements #13 and allows ToBytes to accept values with floats. For instance, 16.3KB and similar.
With this change, all current tests are passed and we add a couple tests to make sure floats won't break later on.

Thanks for the contribution, @DanielOaks ! Prioritizing for the CF Diego team to evaluate. In the meantime, could you please do as @cfdreddbot instructs and submit a CLA to the CF Foundation?
Thanks again,
Eric, CF Diego PM

Hey, @DanielOaks, did you ever get a chance to submit a CLA for the Cloud Foundry Foundation? Thanks!
Best,
Eric

Oh, I didn't! I wrote it up but haven't submitted it yet, give me a couple hours and I'll have it in

Sure thing, no big rush. Thanks!

Just submitted, thanks for the yell :)


Migrate faucet from argparse to yargs

We don't use argparse directly. It is pulled in via
argparse < js-yaml < cosmiconfig < @lerna/project < @lerna/command


Get the exception when make call to a URI<EMAIL_ADDRESS>

Describe the bug
When I use SimpleUser.call method to make the call to a URI<EMAIL_ADDRESS>the exception was thrown.
Logs
There no logs output for this exception.
To Reproduce (if possible)
Steps to reproduce the behavior:

Register to the SIP PBX
Make the call to<EMAIL_ADDRESS>by SimpleUser.call method
The exception is throw

Expected behavior
Just make the call as normal. Note, make calls to<EMAIL_ADDRESS>is no problem.
Observed behavior
The exception is throw
Environment Information

Backend Server and version: PortSIP PBX v12.3
Browser and version: OS is Windows 10 2004,  Google Chrome version 86.0.4240.198 (Official Build) (64-bit)

Additional context

Not a bug, please see my comments on #872


Msgbox and Inputbox

A few more updates.
The MsgBox commit fixes an issue that I mentioned the other day.
Also introduces a new attached property into the arrays that get passed into custom functions. I put an object into the property so it can be expanded more easily hoping that things don't get too wild if it needs to get expanded.

I've put a revert there. I could squash it with the related one, but I prefer to ask first.

I've put a revert there. I could squash it with the related one, but I prefer to ask first.

Squashing it in your personal branch before the PR is merged is fine. Once the code gets merged to main repository, then we dont want to rewrite history. But I'll let you revert first before merging

Ok, I think it's clean now. The last one was a about a yunit test that could be updated too.

I just saw that an added test wouldn't show the title and I've fixed it.

Please wait a bit more before merging I think I'll add some more tests later

Will do. Just let me know when its ready

I think it's ready now. Added quite a mix of alternations in tests and seem to be producing the same results as v1.


Omit is broken / Modifiers not inferred

@DanielRosenwasser
The new version of Omit discards the field modifiers. The solution is to avoid using a type directly in a keyof statement as TS loses the inference of the field modifiers (optional, readonly).
I am not sure if it should behave this way, as you looked confident writing the Omit type, it's probably part of another problem. In short, TS discards the inference of field modifiers on mapped types that map with another type (instead of keyof).

TypeScript Version:  3.5.0-dev.20190501

Search Terms:
mapped type readonly lose modifiers
Code
type Omit<T, K extends keyof any> = {
    [P in Exclude<keyof T, K>]: T[P]
} //     ^^^^^^^^^^^^^^^^^^^^ optional & readonly not inferred

// Mapping with a type like Exclude<keyof T, K> caused TS to forget modifiers

type O = {
    readonly a: string
    b?: number
    c?: any
}

type test00 = Omit<O, 'b'>

type WhatWeGet = {
    a: string;
    c: any;
} // === test00

type WhatItShouldBe = {
    readonly a: string;
    c?: any;
} // !== test00

Expected behavior:
Should preserve the modifiers
Actual behavior:
Loses the modifiers on the fields
Playground Link:
Related Issues:

Duplicate of #31190


Update defaults/guides with details about new nfs_mounts usage

These should be updated after the new version of the nfs_mount role is available in master branch.

The PR: https://github.com/CSC-IT-Center-for-Science/ansible-role-nfs_mount/pull/3
The guide: https://confluence.csc.fi/display/FGCI/FGCI+Cluster+deployment+and+installation+guide
The defaults: https://github.com/CSC-IT-Center-for-Science/fgci-ansible/tree/master/examples/group_vars

Defaults updated. Some documentation in the release notes.


output MMIF format

This thread to discuss output representation of R-F bindings in MMIF syntax and vocab.

@keighrim  - I had some floating questions about RFB and general MMIF structure

When calling mmif[<annotation_id>] on a mmif object, I noticed that it only works if it's the annotation's .long_id. Using regular .id gives a KeyError. Is this intentional?

Maybe I'm answering my own question, but I also noticed that the .id number is not unique globally, but only unique within a view. As in, v_1 and v_2  can both have a TextDocument td_1  in them. Is there an implicit assumption that this td_1 should correspond to the same document across views? If so, are there any innate enforcements/guards for that assumption, or are clams apps developers supposed to write logic complying with that assumption?

The RFB is implemented to return an empty csv if no roles/fillers are identified in the input (due to noise), or if the parser fails. @haydenmccormick brought up the suggestion that we add a runtime parameter to control whether or not the app should generate an annotation if the CSV content is empty. I thought this sounded reasonable, but had a concern related to the above 2 Q's.
If for example, docTR's td_1 was too noisy, and the user opts to have RFB omit empty CSVs, then it's possible that RFB's td_1  could correspond to docTR's td_2  (or a higher number) , which is not super intuitive. Ultimately, the number mismatch won't prevent us from tracing the relation because we have alignments, but it could be less "user-friendly" to not have a global 1-to-1 mapping between id and document.

Do we care about this?
If we do, should we not include this runtime param, and have RFB always return annotations for each OCR textdocument?

Regarding q1, I have started a new issue to make id unambiguous. https://github.com/clamsproject/mmif/issues/228 The problem is that when we start to force long_id everywhere, that'll break any future apps from past MMIFs (or past apps that generates past MMIFs).
You are right about the annotation id without view-id prefix are implicitly "scoped" to the view it resides. That said, the annotation id can be re-used to refer to different objects as long as the "scope" is different. Thus, having v1:td2 is aligned to v2:td1  is totally fine and we don't care.
Al that put together, I don't think it's a good idea to produce "empty" text document when the RFB parsing fails - it doesn't add any information while adding space and time complexity to handle the MMIF outputs (storage-wise and json.load-wise).


[6.0] Remove the addition of external-plugin-path for dev toolchains

Explanation:  SDK macro plugins are now provided within Platforms and are added by default. There's no need to add an additional path to the toolchain. Doing so prevents the macros in the dev toolchain from being picked up.
Scope: Macros
Risk: Low, this path was added prior to macros moving into Platforms.
Testing: Source compat suite passes (which has various macro projects). We could theoretically test we're not adding the argument, but seems a bit weird to do so.
Original PR: https://github.com/apple/swift-package-manager/pull/7524
Reviewer: @MaxDesiatov

@swift-ci please test


Rated Games

Rated* Games    (added as an issue as recommended)

Listed games are all casual. When a player presses the single button "join rated queue", the server adds them into one of many queues.
Each queue has a specific rating range. This can increase as time passes so that sparsely populated ranges aren't left waiting for too long.
We can implement a client-side timer: "Rated game ETA: <time>".
You can't see the queue or map until the game starts. This also means no chatting.
Everyone is anonymous during the game, but when it concludes everyone's identity is revealed.

*We can call these ranked, but in either case we should try to be as consistent as possible.

I think this is a better fit for either backend or Core. Unity is just about the UI which we can display with a lobby of some sorts. I'd probably say this is a backend thing

Oh right sorry — I knew this but obviously didn't think about it when posting this issue. Is there soe way to move this issue there? Or should I open a new issue?

Open the issue in the backend & Link to this one in your comment/description and then close this one

Just kidding! There is a "Transfer Issue" button on the right side of the issue. I will do that


Idea: ask a scientist platform

Site where members of the public can ask professional scientists a question

+1!!!


refactor: increase log level

Log level set to trace

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


A question about iou_threshold?

When i use the iou_threshold=0.85 0f dynamic_rcnn to improve the mask_rcnn, the effect is same as before,
but when i use the iou_threshold=0.9,the effect is better.
So  i want to know about the influence of iou_threshold.

I haven't met this problem before. I guess that IoU_thr will affect tp and fp, also it will potentially affect the sequence of the pred score. So this may cause your problem

feel free to reopen this issue if you still meet this problem


Ability to choose which IOCs to scan for.

💡 Summary
Add the ability to choose which IOCs to scan for.
Motivation and context
I started using this tool to look for IOCs related to the recent Exchange server vulnerabilities.  The SolarWinds IOCs, albeit helpful to have, are of no use to me in those environments.  It would be nice to select only the IOCs that pertain to the environment which you are scanning.
It would be helpful not only from a convenience factor, but also I would imagine it would speed up the scanning speed somewhat, depending on how many IOCs there are to look for obviously.
Implementation notes
I think this could implemented via command-line switch.  For example, if you only wanted to look for SolarFire IOCs;
chirp.exe -i cisa_solarfire
Another option might be if you wanted to run all the cisa IOCs (cisa_raindrop, cisa_solarfire, cisa_sunshuttle, etc..);
chirp.exe -i cisa
Acceptance criteria
How do we know when this work is done?

[ ] Specific IOCs can be scanned for by specifying the indicator filename or group by way of a command-line switch (-i for example)
[ ] Changes follow cisagov coding conventions
[ ] Tests have been written to ensure future compliance

I've been thinking about this recently too. Since we would like to release more IoCs in the future related to various threat activity, our best method may be to reorganize our indicators folder some to look like this:
indicators/
| -- AA21XXXX/
| -- -- indicator1.yaml
| -- -- indicato2.yaml
| -- AA21XXXX/
| ....

then invoking what activity you want to search for with a switch, like -a AA2177A.


Incorrect check for available storage

I think the pre-push check for available storage is incorrect:

does not take removed files into account (those are currently not considered in disk usage of project)
updated files can be

replaced - in this case new storage is only difference between existing and updated files
updated with diff - we push only diff file, the size of updated file on server is unknown

Even if this is only rough check I am worried about the use case of update with (small) diffs of large existing .gpkg files

That check (https://github.com/MerginMaps/mergin-py-client/blob/0.7.3/mergin/client.py#L548) has been removed in 0.8.0 (https://github.com/MerginMaps/mergin-py-client/commit/95220e02eded281c5c90ec9f12d430d53dc26bff) and we now rely on the server for storage checks.


Make compatible with Python 3.7

Would be handy to up this to support Python 3 as 2 support has been dropped.

Converted :)

Nice work, thank you!


Create Posts “2023-09-13-adventures-with-k8s”

Automatically generated by Netlify CMS

👷 Deploy Preview for musing-bassi-dcff2c processing.

Name
Link

🔨 Latest commit
e90e73c6a111b04d9477306e356852f19c4f9630

🔍 Latest deploy log
https://app.netlify.com/sites/musing-bassi-dcff2c/deploys/65017b2d38eac90007d99dbf


Fix precision issues with higher-frequency cycle counters

Currently not very accurate

This also has issues that cycle counters that don't evenly divide the number of nanoseconds in timeout routines can cause additional timeout tardiness.


[interpreters] Do not add all default interpreters of every whitelisted app

What changes were proposed in this pull request?

This ensures that if user needs an interpreter X, then user needs to add its config under [[interpreters]]. This way we wont be showing all unneeded interpreters and confuse users whenever any app is whitelisted.
If user still wants to add all default interpreters, then they can set the flag enable_all_interpreters to True in the Hue config.

How was this patch tested?

Manually tested different scenarios of Hue config and verified the editors available on the Hue UI.

@ranade1 @wing2fly - Can you please review the PR?


prop-types warns on this.props.children

Should this warn on children when it's a built in prop from React?
Sample Component
export class Component extends React.Component {
  constructor(props) {
    super(props);
  }

  render() {
    return (
      <div>
          {this.props.children}
      </div>
    );
  }
}

Warning:
warning  'children' is missing in props validation for Component  react/prop-types

Yes, there is a note in the documentation about the children case. You an use the ignore option if you don't want to document it in your component.

Thank you, I didn't spot this on the first read.


Error when generating sidebars.

Describe the bug
Cannot generate site - sidebar file generating incorrect document IDs for category/tag pages.
Expected behavior
yarn build should complete successfully.
Current behavior
The following error is seen:

Possible solution
Manually correcting the paths in the output directory's sidebar.js file fixed the issue until the docs are regenerated.
Steps to reproduce

Using this API definition: https://gist.github.com/homotechsual/e32d9c815c62b41501dc7d049fbd06f5
Config: https://gist.github.com/homotechsual/a8b7cc5f405ad97e51ed988c87426454

Context
Documenting moderately complex REST APIs using json schemas.

It's possible you are missing a docsPluginId in your config. See this for more details: https://docusaurus-openapi.tryingpan.dev/#plugin-configuration-options
In your case I think setting it to "classic" should do the trick.

My mistake, it looks like you do have the right docsPluginId specified. I'll see if I can reproduce and will report back. Thanks.

Patch has been merged. Can you try again with 0.0.0-394 and report back if resolved?

@homotechsual any updates to report?

Sorry - I will get some eyes on this tomorrow and report back - haven't had time to look at my docusaurus project in a couple of days :-D

No worries - we've since upgraded to beta.22 (soon to be rc.1) but you can still use 0.0.0-394 to test the fix for your particular issue.

This is working perfectly now :-)

@sserrata Heads up I'm encountering the same issue. I'm on v1.1.8.

Steps to reproduce
Using this API definition: https://github.com/livepeer/livepeer-studio-docs/blob/openapi/spec.yaml
Config: https://github.com/livepeer/livepeer-studio-docs/blob/openapi/docusaurus.config.js


Vulnerability 'summary' field is neither consistent nor complete

I noticed recently when working with a range of PURLs and vulnerabilities that:

the content of the VCIO UI summary field (afaict this applies equally to the API responses) does not always come from the same source,
the source is sometimes impossible to identify (for me at least), and
the summary field value is limited to just one source (even if it varies and might be unknown) and thus omits descriptions from other vulnerability advisories (e.g., nvd.nist.gov but not ghsa or vice-versa).

In the best of all possible worlds, a consumer of vulnerability information might prefer to have access to the vulnerability description from all major advisory providers (however defined).  Among the challenges of doing so is the fact that some advisories, for example many ghsa advisories, contain Description fields that have multiple headings and sometimes sub-headings and reference lists, adding to the complexity of identifying and securing the sought-after content.
I'll provide a few examples below.

From the public UI.  Summary values might not reflect carriage returns in the DB.
Example:
VCID-121u-fy4e-aaah
Summary:
Polymorphic typing issue
Source: unknown
nist.nvd.gov 'Description' field (https://nvd.nist.gov/vuln/detail/CVE-2019-17531):
A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 through 2.9.10. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the apache-log4j-extra (version 1.2.x) jar in the classpath, and an attacker can provide a JNDI service to access, it is possible to make the service execute a malicious payload.
ghsa 'Description' field (https://github.com/advisories/GHSA-gjmw-vf9h-g25v):
A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.0.0 prior to <IP_ADDRESS>, <IP_ADDRESS>, and <IP_ADDRESS>. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has the apache-log4j-extra (version 1.2.x) jar in the classpath, and an attacker can provide a JNDI service to access, it is possible to make the service execute a malicious payload.

Example:
VCID-pu9y-1t3k-aaag
Summary:
Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.
Source: looks like nvd.nist.gov (see below)
nist.nvd.gov 'Description' field (https://nvd.nist.gov/vuln/detail/CVE-2023-2976):
Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.
ghsa 'Description' field (https://github.com/advisories/GHSA-7g45-4rm6-3mm3):
Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.
Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.

Example:
VCID-arnu-neah-aaas
Summary:
OS Command Injection Growl does not properly sanitize input before passing it to exec, allowing for arbitrary command execution.
Source: unclear
nist.nvd.gov 'Description' field (https://nvd.nist.gov/vuln/detail/CVE-2017-16042):
Growl adds growl notification support to nodejs. Growl before 1.10.2 does not properly sanitize input before passing it to exec, allowing for arbitrary command execution.
ghsa 'Description' field (https://github.com/advisories/GHSA-qh2h-chj9-jffq):
Affected versions of growl do not properly sanitize input prior to passing it into a shell command, allowing for arbitrary command execution.

Example:
VCID-uwmq-1z6g-aaap
Summary:
NATS nats-server before 2.9.23 and 2.10.x before 2.10.2 has an authentication bypass. An implicit $G user in an authorization block can sometimes be used for unauthenticated access, even when the intention of the configuration was for each user to have an account. The earliest affected version is 2.2.0.
Source: nvd.nist (see below)
nist.nvd.gov 'Description' field (https://nvd.nist.gov/vuln/detail/CVE-2023-47090):
NATS nats-server before 2.9.23 and 2.10.x before 2.10.2 has an authentication bypass. An implicit $G user in an authorization block can sometimes be used for unauthenticated access, even when the intention of the configuration was for each user to have an account. The earliest affected version is 2.2.0.
ghsa 'Description' field (https://github.com/advisories/GHSA-fr2g-9hjm-wr23):
Background
NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.
NATS users exist within accounts, and once using accounts, the old authorization block is not applicable.
Problem Description
Without any authorization rules in the nats-server, users can connect without authentication.
Before nats-server 2.2.0, all authentication and authorization rules for a nats-server lived in an "authorization" block, defining users. With nats-server 2.2.0 all users live inside accounts. When using the authorization block, whose syntax predates this, those users will be placed into the implicit global account, "$G". Users inside accounts go into the newer "accounts" block.
If an "accounts" block is defined, in simple deployment scenarios this is often used only to enable client access to the system account. When the only account added is the system account "$SYS", the nats-server would create an implicit user in "$G" and set it as the no_auth_user account, enabling the same "without authentication" logic as without any rules.
This preserved the ability to connect simply, and then add one authenticated login for system access.
But with an "authorization" block, this is wrong. Users exist in the global account, with login rules. And in simple testing, they might still connect fine without administrators seeing that authentication has been disabled.
The blind-spot on our part came from encouraging and documenting a switch to using only "accounts", instead of "authorization".
In the fixed versions, using an "authorization" block will inhibit the implicit creation of a "$G" user and setting it as the no_auth_user target. In unfixed versions, just creating a second account, with no users, will also inhibit this behavior.

At a minimum VulnerableCode needs to record the origin of the Summary text and the date the Summary text was posted.
Longer-term we may need to consider rules for picking the best text for the Summary based on the source.
Even longer-term this might be an area to experiment with machine learning to construct a Summary from multiple texts - this might need to be a recurring Improver process to incorporate new data after the initial posting of a VCID.

👍

Clarification of action to be taken:
At a minimum VulnerableCode needs to record an accurate source and the date the Summary text was posted.

Note: given correct severities, CVEs, etc. the summary is nice but not necessarily essential/urgent.
From another perspective: consider the real purpose and value of the summary in the first place.
Maybe ask a GPT/LLM to summarize a group of summary texts (specifying a maximum size)?

Closing this as a duplicate of:

https://github.com/aboutcode-org/vulnerablecode/issues/859


upgrade to HDF5-1.12.2

Upgrade the HDF5 version in the CI. Let's see how it does...

This is timing out in tst_remote3. I think that dap tests should be turned off in most of the CI runs.

I also turned off remote tests for the CMake build in the CI...

So I just tested this with 1.12.2 on Ubuntu Linux. I did not see
any dap test failures or hangs. What other ./configure options
did you use?

There are DAP timeouts when this is done from the CI, probably because there are so many different builds all trying to do remote tests.
So I have not found any remote test bugs here - just turning off remote tests so it does not overwhelm the CI system...


Ask for codefendant court contact info. Fixes #63. For #64, #59, #31.

Fixes #63. Addresses #64, #59, #31
Test:
(User has 2 codefendants)

User gives all court contact info for codefendant 1
User gives 0 court contact info for codefendant 2
User does not sign for codefs. Neither codef signs on user device.
User gets to preview.
Preview has correct court contact info for codefendants (second page of form)
At input fields to send signature links to codef:

Codef 1 should have default values for email and text equal to the info they put in
Codef 2 should have blank fields

The end.

@plocket and @mariahjr I have been away from this for a little while - so behind the times but with too many other things to do I diverted and started a small flow chart à la @maevemacglinchey given my understanding of the whole contact info.... maybe don't need contact info from other users?

@CaroRob : The flow chart looks great! From what I saw, it was pretty close to what Quinten had described to me in the meeting and in the thread that you saw. I'll talk about the differences between them at the bottom. First I want to lay this all out in more detail step-by-step. Sorry I wasn't able to articulate this better before now.
I was told that each signer had two pieces of contact information they would possibly need which should both be asked for:

Contact info for the court.
Contact info to get a signature.

Additional specs were:

The user will provide all information.
No information is absolutely required.
The court information would be the default for the signature information, but should be able to be customized.

I think the only two things that deviated from the flow you linked are:

The user is asked to give court contact info for the cosigner right after they give the cosigner name.
For the signature link, the user has to pick one of either the phone or email.

This PR is focused on that functionality. For now, no one can follow any links to following interviews because of a bug in da itself. This PR doesn't affect that anyway, though. It's just about the flow of these questions on the originating user's interview.
Thanks for letting me lay all that out. That said, what parts of this particular flow need to be changed/clarified to be sufficient for MVP?

Maybe this would be better discussed in the issue. I'll figure out which issue would be best for this.

Wrote these specs out in https://github.com/SuffolkLITLab/docassemble-MAEvictionMoratorium/issues/64#issuecomment-686853661 along with a link of the awesome flowchart


Option to override fetch

Is your feature request related to a problem? Please describe.
When using NextJS we use a patched fetch that enables automatic caching in NextJS. When using a library like cross-fetch, you opt-out of this behaviour.
Describe the solution you'd like
Option to pass a fetch method to the TMDB constructor. Basically what graphql-request also offers:.
Describe alternatives you've considered
Remove cross-fetch dependency as it shouldn't be needed anymore in Node.

Good call. What I'll do is bump the major version with the removal of cross fetch and then make the min node version >18.0.0


Update compileSdk version

Update make compatible with new android version

Please review my PR to fix build in new android version SDK @AbdoPrDZ @dragosholban


stream_list_sort: Fix stream marked as active on click.

Earlier, a stream in the inactive section was moved to the active section in the left sidebar on click.
Now, we mark a stream as active only when it has at least one message included in all_messages_data (home view).
Fixes #27009.
inactive-stream.webm

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Does the reworking of how we fetch message history make this simpler to complete at this point? I've sorta lost track of it.


Fixes #114 adds /api to appliance url

Desired Outcome
Removes the requirement to add /api to the end of appliance urls for Conjur Cloud support.
Implemented Changes
Describe how the desired outcome above has been achieved with this PR. In
particular, consider:

What's changed? Why were these changes made?
Added an additional line of code to append /api to the appliance_url variable.
How should the reviewer approach this PR, especially if manual tests are required?
Test, deploy, it will work successfully in all cases.
Are there relevant screenshots you can add to the PR description?
No.

Connected Issue/Story
Resolves #114
CyberArk internal issue ID: n/a
Definition of Done
At least 1 todo must be completed in the sections below for the PR to be
merged.
Changelog

[x] The CHANGELOG has been updated, or
[ ] This PR does not include user-facing changes and doesn't require a
CHANGELOG update

Test coverage

[ ] This PR includes new unit and integration tests to go with the code
changes, or
[x] The changes in this PR do not require tests

Documentation

[ ] Docs (e.g. READMEs) were updated in this PR
[ ] A follow-up issue to update official docs has been filed here: [insert issue ID]
[x] This PR does not require updating any documentation

Behavior

[ ] This PR changes product behavior and has been reviewed by a PO, or
[ ] These changes are part of a larger initiative that will be reviewed later, or
[x] No behavior was changed with this PR

Security

[ ] Security architect has reviewed the changes in this PR,
[ ] These changes are part of a larger initiative with a separate security review, or
[x] There are no security aspects to these changes

@jtuttle,
Added changes to CHANGELOG, bumped VERSION to v0.6.5, updated initial comment in PR #115 (above) to reflect changes to CHANGELOG made.


Demo link form NPM readme not available

Real: https://nodeca.github.com/js-yaml/ (404 There isn't a GitHub Pages site here.)
Expected: https://nodeca.github.io/js-yaml/

It seems like the one in npm is not updated to the latest one from github readme.


Allow user to set value that belongs to disabled range

Feature to set picker's date that belongs to disabled range (below start date or greater than end date), when it received as a server response, but user is still disallowed to set/select such date as input

I don't see why this should be a standard function in the datepicker lib. As this we have the startDate option just to block users to only select dates starting from a given date. If users should be able to pick an earlier date, imo the startDate should be changed
:-1:  on this. What do you guys think? \cc @hebbet, @vsn4ik, @Azaret

:-1:  from here, too.

Tho I'll be glad too hear an use case for this feature if you mind @elartix .


feat: add mongodb 1.17.1 release

update mongodb with release 1.17.1

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


Weekly scheduled job runs every day on production server

I have two jobs to run, one runs on Thursday every week, and one runs on Monday every week. On the development server, everything seems to be fine. On the production server, the Thursday job runs well, but the Monday 11:45 am job actually runs everyday at 11:45.
Here is the code:
SyncedCron.add({
  name: 'Send Baila Con Gusto coupons and birthday lists on Thursday 5pm',
  schedule: function(parser) {
    let date = new Date();
    date.setDate(date.getDate()+7); // next Thursday
    // get next week timezone offset
    const serverOffset = date.getTimezoneOffset();
    const mtl = moment.tz(date, "America/Montreal");
    const mtlOffset = mtl._offset;
    // get difference between server time and montreal time
    const offsetHours = Math.floor((mtlOffset - serverOffset)/60);
    // parser is a later.parse object
    return parser.text('at ' + (5 + offsetHours) + ':00 pm on Thursday');
  },
  job: function() {
    Meteor.call('sendClubEmailLists', new Date());
    return;
  }
});

SyncedCron.add({
  name: 'Send birthday email reminder on Monday 11:45am',
  schedule: function(parser) {
    let date = new Date();
    date.setDate(date.getDate()+7); // next Monday
    // get next week timezone offset
    const serverOffset = date.getTimezoneOffset();
    const mtl = moment.tz(date, "America/Montreal");
    const mtlOffset = mtl._offset;
    // get difference between server time and montreal time
    const offsetHours = Math.floor((mtlOffset - serverOffset)/60);
    // parser is a later.parse object
    return parser.text('at ' + (11 + offsetHours) + ':45 am on Mon');
  },
  job: function() {
    Meteor.call('sendBirthdayReminder', new Date());
    return;
  }
});

SyncedCron.start();

@jpdupere you should probably take a look at offsetHours, since unless it's 0 it will result in a parser error. Check it out at https://bunkat.github.io/later/parsers.html#text

@TheGame2500 thanks for the help, that was my problem the offset hours would go make the hours go ever 12 so the parser was trying to interpret ie 14:45 am.


Improve test utility header compilation speed

This PR reduces physical dependencies between headers for test utilities, resulting in 1-2s average compilation speedup on my machine.

Failures seem to be related to codecov -- how to proceed?

master (without running tests)
real    0m7.925s
user    0m56.337s
sys     0m6.599s

This PR (without running tests)
real    0m7.952s
user    0m56.119s
sys     0m6.551s

I'm not able to observe a build time reduction with this PR.

CI failures seem to be related to codecov -- how to proceed?

It fails all the time. Rerunning CI usually fixes it.

Looks mostly good -- I wonder if we should still define the vector typedefs, as we're using them in a few places? Just for consistency with the rest of the codebase.

You mean in SystemUtil, right? I'd rather avoid doing so, it's a bit of extra repetition that we need to maintain between the actual vector header and the test header.

SFMLBuildMaster: Build this please.

I'm failing to demonstrate any compile time improvements and even if I could show that it was faster for me, I'm still not keen on adding complexity for marginal compile time gains that aren't even relevant to the core library. I won't veto this PR if others like it but I'm still not excited by it.

Here are some measurements on my machine, using hyperfine "ninja clean; ninja", for a clean rebuild including all test drivers.
Before this PR:
  Time (mean ± σ):     15.025 s ±  0.531 s    [User: 120.985 s, System: 17.608 s]
  Range (min … max):   14.178 s … 15.642 s    10 runs

After this PR:
  Time (mean ± σ):     13.684 s ±  0.111 s    [User: 111.092 s, System: 16.656 s]
  Range (min … max):   13.537 s … 13.891 s    10 runs

I was unaware of hyperfine. Looks pretty useful for these things. I again commented out the command that runs the tests since I don't want those skewing the results. (I'm growing sour on SFML running tests automatically after the build and might prefer we switch to he more idiomatic approach where tests are only run on demand. If we care about incremental build time improvements that's an easy way to improve).
master:
Benchmark 1: ninja clean; ninja
  Time (mean ± σ):      9.657 s ±  0.209 s    [User: 62.755 s, System: 7.995 s]
  Range (min … max):    9.424 s …  9.974 s    10 runs

This PR:
Benchmark 1: ninja clean; ninja
  Time (mean ± σ):      9.423 s ±  0.115 s    [User: 62.471 s, System: 7.878 s]
  Range (min … max):    9.303 s …  9.722 s    10 runs

The difference is still imperceptible to me.

CI failures seem to be related to codecov -- how to proceed?

https://github.com/ChrisThrasher/SFML/commit/5f8b7bf4f0c40fe039d6bf08836f446b4815da3f
Unrelated to this PR but I propose we allow coverage jobs to fail. I'd rather have a rock-solid CI pipeline than perfect code coverage information.

Rebased on master. @ChrisThrasher, are you still against this PR given Bromeon's observation? We are very likely to not touch this code again, but it will continuously give us benefits in terms of compilation speed and CI usage over the course of the next years.

SFMLBuildMaster: Build this please.

@eXpl0it3r @ChrisThrasher: how do we proceed?
BTW, here's the latest benchmark after rebasing:
without PR:
Benchmark 1: ninja clean && ninja
  Time (mean ± σ):     16.227 s ±  0.570 s    [User: 169.491 s, System: 22.362 s]
  Range (min … max):   15.517 s … 17.353 s    10 runs

with PR:
Benchmark 1: ninja clean && ninja
  Time (mean ± σ):     15.539 s ±  0.481 s    [User: 161.124 s, System: 21.582 s]
  Range (min … max):   14.774 s … 16.092 s    10 runs

I stand by my previous comments. In case anything changed I remeasured and the build time improvement was about a tenth of a second. It's up to Exploiter to decide.

I stand by my previous comments. In case anything changed I remeasured and the build time improvement was about a tenth of a second. It's up to Exploiter to decide.

He approved the PR, but merging is blocked due to your review.


Add tests for WarnCaseSensitiveModulesPlugin

What kind of change does this PR introduce?

Add tests for WarnCaseSensitiveModulesPlugin
Did you add tests for your changes?

This PR is only tests
If relevant, link to documentation update:

N/A
Summary

Based on the coveralls report, the WarnCaseSensitiveModulesPlugin file has 86% test coverage. There is no WarnCaseSensitiveModulesPlugin specific test file - this is added in this PR and aims to achieve 100% test coverage.
https://coveralls.io/builds/9590222/source?filename=lib%2FWarnCaseSensitiveModulesPlugin.js
Does this PR introduce a breaking change?

No
Other information
The coverage of this file appears to depend on whether it is called in other tests (in other builds it has a coverage of 100%) - https://coveralls.io/builds/9584589/source?filename=lib%2FWarnCaseSensitiveModulesPlugin.js

Thank you 💯


setManipulations Watermark path

I am trying to add a watermark to my image:
$this->addMediaConversion('large')
    ->setManipulations(['fm' => 'jpg', 'mark' => 'watermark.png', 'markw' => '40', 'markh' => '40', 'markpad' => '15', 'markpos' => 'top-left'])
    ->performOnCollections('images');

Following the Glide doc (http://glide.thephpleague.com/1.0/api/watermarks/) I added a new filesystem for watermarks, in the laravel's config/filesystems.php file.
However, my generated thumb doesnt have any watermark on it. And there is no log error report.
Where should I place my watermark.png file ? I tried in storage/images and storage/watermarks and even modifying  'mark' => storage_path('images/watermark.png') but I can't get it working.

Could try using the absolute path to you watermark file?

Hi, I tried absolute path
GlideImage::create(public_path().'/uploads/posts/cropped-1555.jpg')
->modify(['mark' => '/home/vagrant/Code/mysite/public/uploads/posts/mark-100h.png'])
->save(public_path(). '/output.jpg');
with no luck.

This has been fixed in v.3.0.1. You can now use the absolute path in the mark parameter.

Tested it on local and production, works like a charm using public_path()
Thanks for the fix!


User Section's color does not change when user should be root.

The problem
So I'm trying to figure out why the color for the user section stays yellow instead of changing red, while I am running as root.
Using "whoami" will print out root, and there is only one root user.
The files and plugins are also saved in the /root/ directory.
However, the user color stays yellow, and will only change if I edit it to change into red, despite the variable to set root user's color to red, being enabled.
I also have an additional issue where trying to use SPACESHIP EDIT brings a "_spaceship::cli::edit:5: permission denied:" error.
But, I can create the spaceshiprc.zsh file and edit it manually, which spaceship will take into account.
I'm wondering if there's a reason why spaceship just assumes i'm not root.
Relevant Zsh configuration
(This is in the spaceshiprc.zsh file)
SPACESHIP_HOST_SHOW='always'
SPACESHIP_HOST_PREFIX='💀'
SPACESHIP_USER_SUFFIX=""
SPACESHIP_USER_COLOR="red"
SPACESHIP_DIR_TRUNC='0'
SPACESHIP_PROMPT_ORDER=(
  time
  user
  host
  dir           # Dir section
  git           # Git section (git_branch + git_status)
  hg            # Mercurial section (hg_branch  + hg_status)
  package       # Package version
  node          # Node.js section
  ruby          # Ruby section
  python        # Python isection
  elm           # Elm section
  elixir        # Elixir section
  xcode         # Xcode section
  swift         # Swift section
  golang        # Go section
  php           # PHP section
  rust          # Rust section
  haskell       # Haskell Stack section
  java          # Java section
  julia         # Julia section
  docker        # Docker section
  aws           # Amazon Web Services section
  gcloud        # Google Cloud Platform section
  venv          # virtualenv section
  conda         # conda virtualenv section
  dotnet        # .NET section
  kubectl       # Kubectl context section
  terraform     # Terraform workspace section
  ibmcloud      # IBM Cloud section
  exec_time     # Execution time
  async
  line_sep
  battery
  jobs
  exit_code
  char
)

What is version of Spaceship are you using?
v4.13.1
What is version of Zsh are you using?
5.9
What operation system are you running?
Kali GNU/Linux Rolling
Do you use any Zsh framework or plugin manager?
znap
Which terminal emulator do you use?
xterm-256color
Additional information
Root user runs on /bin/bash by default, but I believe that should be normal.

Are you trying to use Spaceship when logged in as a root?
It works as intended, when I am trying to login as root via sudo -s:

Hi, yeah I was running it as root back then. (albeit inside a docker container).
I have since then stopped using spaceship and developed my own ZSH theme, thanks for the comment though.
I will close this issue (Forgot to).


TypeError: undefined is not an object (evaluating 'Object.getOwnPropertyDescriptor(t,e)') in Safari at launch

Ionic version:  (check one with "x")
[ ] 2.x
[X] 3.x
[ ] 4.x
I'm submitting a ...  (check one with "x")
[X] bug report
[ ] feature request
Current behavior:
Safari displays a runtime error when starting the app:
TypeError: undefined is not an object (evaluating 'Object.getOwnPropertyDescriptor(t,e)')

Steps to reproduce:

start a project (ionic start newproject)
choose a template:  I tested with 'blank' and 'tabs'
serve it: (ionic serve)
use Safari to open the app.

Other information:
Ionic info:
cli packages: (/usr/local/lib/node_modules)

    @ionic/cli-utils  : 1.13.1
    ionic (Ionic CLI) : 3.13.2

global packages:

    cordova (Cordova CLI) : 7.1.0

local packages:

    @ionic/app-scripts : 3.0.0
    Cordova Platforms  : none
    Ionic Framework    : ionic-angular 3.7.1

System:

    Node  : v6.11.4
    npm   : 3.10.10
    OS    : macOS Sierra
    Xcode : Xcode 9.0.1 Build version 9A1004

Misc:

    backend : pro

Hello! Thank you for opening an issue with us!
I have tried your steps to duplicate, but I do not get the issue.
I have sometimes seen browser extensions cause issues like this where it looks like something I am developing has an issue but it is actually a problem with the extension. If you are using any Safari extensions, please disable them all and try again. If that fixes the issue, then the issue is with one of your extensions. You can then try enabling them one by one until you find the errant one.
If disabling all extensions has no effect or if you aren't using any browser extensions, would you be able to provide a sample application via GitHub that demonstrates the issue you are having? Thanks for using Ionic!

The issue was caused by extensions. Thank you.


Change path names and filenames to work with Windows containers

These modifications allow the ADK to work on Windows docker containers, too.  The output directory is changed from \output to C:\output, and the input directory is changed similarly.  The input parameters filepath is also modified to work on Windows.

Can you added unit tests for the changes you are bringing?

Can you added unit tests for the changes you are bringing?

My latest commit updated the unit tests to test for Windows paths, too.  I didn't add any new unit tests because there aren't any new "features" added to the ADK, just the existing functions working in a platform independent way.

Hey Arjun,
thank you for your contribution! We'll merge your PR and create a release for the SDK :)

Thanks Arjun for quick follow-up and thanks for your contribution!


idk what is this :)

30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO DiSky Internal Error (version: 4.15.1)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO Error type: IllegalStateException
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO This interaction has already been acknowledged or replied to. You can only reply or acknowledge an interaction once!
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO Full Stacktrace:
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO net.dv8tion.jda.internal.requests.restaction.interactions.InteractionCallbackImpl.tryAck(InteractionCallbackImpl.java:57)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO net.dv8tion.jda.internal.requests.restaction.interactions.InteractionCallbackImpl.submit(InteractionCallbackImpl.java:81)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO net.dv8tion.jda.internal.requests.RestActionImpl.complete(RestActionImpl.java:225)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO net.dv8tion.jda.api.requests.RestAction.complete(RestAction.java:632)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO info.itsthesky.disky.elements.effects.DeferInteraction.execute(DeferInteraction.java:76)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO ch.njol.skript.util.AsyncEffect.lambda$walk$1(AsyncEffect.java:60)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO org.bukkit.craftbukkit.v1_20_R4.scheduler.CraftTask.run(CraftTask.java:82)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO org.bukkit.craftbukkit.v1_20_R4.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:54)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO java.base/java.lang.Thread.run(Thread.java:1583)
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO READ THE ERROR CAREFULLY, and if you are sure about it,
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO you can report the error with the whole stacktrace on the GitHub repository:
30.04 09:28:35 [Server] Craft Scheduler Thread - 34/INFO https://github.com/DiSkyOrg/DiSky/issues/new

This interaction has already been acknowledged or replied to. You can only reply or acknowledge an interaction once!


⚠ Bofrost.at has degraded performance

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

HTTP code: 200
Response time: 1334 ms

Resolved: Bofrost.at performance has improved in 21ea6b6 after 6 minutes.


how to transfer values between redux and apollo-client ?

Hi
looking at the example with-redux-and-apollo, I can't figure out how to copy a store's value to props such that it is passed to a child component performing a graphql query.  Here's my current approach. I would greatly appreciate any hint, since using { connect } + MapStateToProps approach from 'react-redux' cannot access the store.
./lib/store.js
import Immutable from 'immutable'
const initialState = Immutable.fromJS({
    keyword: 'I want to query this sentence'
})
export default {
  search: (state = initialState, { type, payload }) => {
    switch (type) {
       default:
        return state
    }
}

./page/search.js
import SearchResult from '../containers/SearchResult'
import withData from '../lib/withData'
import App from '../components/App'

export default withData((props) => (

    <App>
      <SearchResult keyword={'I DON'T KNOW HOW TO PASS REDUX-STATE HERE'}/>
		</App>

))

./containers/SearchResult.js
import withData from '../lib/withData'
import { gql, graphql} from 'react-apollo';
import SearchResult from '../components/Search'

const search = gql`
  query search($keyword: String!, $size: Int!) {
    search(keyword: $keyword, size: $size){
      title
    }
}
`;

export default withData(graphql(search, {
  options: ({ keyword }) => ({
    variables: {
      keyword: { keyword },
      size: 10
    }
  }),
  props: ({ data }) => ({ data })
})(SearchResult))

@jpabbuehl I'd modify withData.js with
...await (Component.getInitialProps ? Component.getInitialProps({...ctx, store}) : {})
Notice that I added store to the parameters. Now in your search.js you can access Redux store to get the data like this
static async getInitialProps ({ store, isServer }) {
    await store.dispatch(yourDesiredAction())

Hope this helps

@tsupol
Thanks for your example. I tried the code below in /lib/withData.js with no joy. Any chance you have a handy repo I can peek at?  I've been struggling with this for two days now and it's time to seek help from more senior devs.
static async getInitialProps (ctx, store) {
      let serverState = {}

      // Evaluate the composed component's getInitialProps()
      let composedInitialProps = {}
      if (ComposedComponent.getInitialProps) {
        composedInitialProps = await ComposedComponent.getInitialProps({...ctx, store})
      }
...

@timneutkens:
I'm trying to get the exact example you link to working and I still can't mapStateToProps successfully. I'm sure it's simple, but I'm definitely missing how. I can get my dispatches working by wrapping connect (that's react-redux 'connect', not apollo), along with mapDispatchToProps but not state.
The Apollo examples detailing how to wire Apollo and Redux together are great but it's been difficult to adapt them to work with handling the composed component (which is an awesome implementation) in withData.js

@theednaffattack here is my quick code (not tested) that might help
Note: the rest are the same as @timneutkens's examples and you may have add your reducers and actions
import React from 'react'
// GQL
import { gql, graphql } from 'react-apollo'
// Redux
import { connect, compose } from 'react-redux'
import { bindActionCreators } from 'redux'
// Redux actions if needed
import { doReduxStuff } from '../../redux/filterActions'

class reactClass extends React.Component {

  constructor (props) {
    super(props)
  }

  onClick = (e) => {
    e.preventDefault()
    // dispatch a Redux action
    this.props.action.doReduxStuff({params: 'test'})
  }

  render () {
    // Note: no GQL code here for simplification
    return (

Data from Redux: {this.props.yourData}

        <button onClick={this.onClick}>Test Redux</button>

    )
  }
}

// You may need to pay attention here
const reduxWrapper = connect(
  // I think this is what you are looking for
  state => ({
    yourData: state.yourData
  }),
  // You can also map dispatch to props
  dispatch => ({
    actions: {
      doReduxStuff: bindActionCreators(doReduxStuff, dispatch),
    }
  }))

// Apollo!
const query = gql`
  query users($id: Int!) {
    users(id: $id) {
      id
      name
    }
  }
`

const gqlWrapper = graphql(query, {
  options: (ownProps) => ({
    variables: {
      id: ownProps.id,
    }
  }),
})

// `compose` makes wrapping component much easier and cleaner
export default compose(
  reduxWrapper,
  gqlWrapper,
)(reactClass)

@tsupol
You are the man (unless you are a woman, in which case you are supreme)!
I was actually just about to message that I'd found them (they were there under 'props.state'), but I really appreciate this example anyway as I don't know any devs getting into Apollo.  Seeing how others approach this issue is a huge help to my personal development.

@tsupol
Thank you very much, I ll give a try.
With the provided example, I was just able to use them both in parallel, without exchange.

@tsupol is this only working for react-apollo prior to their latest 2.0.x release or also for the latest one?

@natterstefan I think it should work also with Apollo 2, but do you really need Redux?

@johnunclesam hello, actually the answer is no. 9 days ago I was not aware of how to use Apollo 2.0 properly, but not I have a much better picture in my head. Also thanks to these two (link1 and link2) links and the people who participated in each of them. thanks though for your comment.


Nodes are always switching from connected to disconnected

Hi everyone! I made a node-red flow and it was working really well until a few days ago.
I can see that the nodes from the google home devices are always switching from connected to disconnected and then to connected again and so on...
What happens?
Thank yoU!

You need to make sure you only have one config node shared between all the device nodes.
That our you have the same user on multiple Node-RED instances, this is not allowed.

You need to make sure you only have one config node shared between all the device nodes.
That our you have the same user on multiple Node-RED instances, this is not allowed.

Yes, the problem was that I was using the same user in two Node-Red instances. Thank you so much!


Update helm.md - correcting swapped links.

Links to (1.) Helm Tool installer task and (2.) Helm package and deploy task were swapped.

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

ValidatePublishRequest
:warning:Warning

Details

[Error] Cannot sync git repo to specified commit because branch master has been deleted or has been force pushed: fatal: Could not parse object '1908f63791f06339a16f835daa5cb4c0547f7e62'.

ValidatePublishRequest

[Warning] Owner Pacort of repository https://github.com/MicrosoftDocs/vsts-docs has lost Admin permission. Please use Transfer Owner via OPS portal https://ops.microsoft.com to assign a new owner.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Thank you for your contribution. We have had an issue with the public vsts-docs repo, but they are resolved now and I am incorporating the outstanding changes. For some PRs (such as this one) that were opened after the issue began, I am closing the PR, and manually incorporating the changes in our private repo, with a link to this PR in the commit message. Any new PRs will be merged in the regular fashion. Thank you for your contribution.


Allow peer dependency of React 15

React 15 should be an allowed peer dependency version

Hi @coreylenertz , thanks for submitting this issue.
Unfortunately, I lack the time to maintain this project at the moment.
I will try and review any Pull Request if you can afford to send one.
Have you tried react-swipe-views with React 15? Does it work?
Best regards

I have it working with 15. I'll see if I can update anything that's required - it may have just worked though.


[terra-abstract-modal] Fix to prevent modal from closing on pressing escape to close select

Summary
Changes in abstract modal to prevent modal from closing on pressing escape to close select inside a modal.
Closes #1264
Deployment Link

https://terra-framework-deployed-pr-#.herokuapp.com/
Testing
Added wdio tests and updated jests.
Additional Details
Marking it as Do Not Merge because snapshot for this PR  has been used in pkg.json.

Thank you for contributing to Terra.
@cerner/terra

Looks good to me other than the dependency update

Functional review complete. No issues identified.


Used Collective instead of Illuminate in Html and Form extensions

Coverage decreased (-2.02%) to 28.34% when pulling 0435fc64472dcb193238f001c8d2eceb631dc257 on misterdesign:0.7 into 25c3556d98a312fdba2133b6cf1bf5675a99245b on rcrowe:0.7.

Coverage remained the same at 30.37% when pulling 133f3095b0625f2f35e2af7bdc7fda89a11fabee on misterdesign:0.7 into 25c3556d98a312fdba2133b6cf1bf5675a99245b on rcrowe:0.7.

Thanks


Updates for 0.13.0

hi @Arwalk nice project, just revised for 0.13.0 ; )

Wow, thank you for your interest in this project!


chore: add Controls components

Включает в себя #62

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


Flags can be updated in HTTP message updates

The SUPPRESS_EMBEDS flag can be updated in the HTTP's UpdateMessage request, but we don't currently allow updating flags.
Docs: https://discord.com/developers/docs/resources/channel#edit-message-json-params

Allowed mentions can also be edited, it says in the text but is for some reason not in the table