Fix confusion with layer start/end bounds and duplicates

See commit messages for details
Fixes #517.
Note: this applies on top of PR #560

I debugged the 'performance' test failure, analysis here: https://github.com/zenithdb/zenith/issues/567. In short, I believe it's a pre-existing bug that this PR happened to uncover.

Pushed, thanks for the review!

Looks like I'm running a newer Rustc/Clippy than CircleCI, but warnings still make sense to me, although nitpicky.
I will downgrade to be in sync with CI versions.


Also reconcile destination prefixes

This needed metal-networker from the current master; v0.8.3 was too old. So we'll need to release metal-networker too.

@mreiger is this PR still relevant, e.g. which issue is supposed to solved ?


fix a typo

There is a typo at toaster.scss file.

Coverage remained the same at 100.0% when pulling 7af69e6b3538071e9f7b5d1652787e3dac5e66fb on chatii2412:fix/typo into 77de356234250e523f07586c7a7a1636bbac712a on jirikavi:master.

Coverage remained the same at 100.0% when pulling 68468c649b6e7e1fbc34a2933bd43d2a0fbcfdef on chatii2412:fix/typo into 77de356234250e523f07586c7a7a1636bbac712a on jirikavi:master.


platform.netbeans.org resources

Some missing resources so that platform.netbeans.org works properly after the netbeans.org rerouting.

Awesome.

Hi @geertjanw,
I think I'll add all these other resources at https://cwiki.apache.org/confluence/display/NETBEANS/netbeans.org+migration during the day.

Excellent. Also the DTDs, would be good.

@geertjanw @JaroslavTulach DTDs will follow in another PR, as these require adding APLv2 license headers.


Serializing as Json produces invalid Json for numeric types depending on culture

This is the follow up on the original issue (https://github.com/microsoft/OpenAPI.NET/issues/396) that had been fixed in 1.1.3. I believe the problem still exists with example numeric values.
Input JSON (read)
"properties": {
"weightTotalMax": {
"type": "number",
"format": "float",
"description": "Максимальна загальна вага відправлення, кг",
"example": 29.992
}
}
Output JSON (write)
"properties": {
"weightTotalMax": {
"format": "float",
"description": "Максимальна загальна вага відправлення, кг",
"type": "number",
"example": 29,
992
}
}

I just switched my machine to French and confirmed that numbers were rendering with commas.  I then tried your example using the code in the vnext branch and it behaved as expected.
I am going to release the 1.2 version.  Could you check with that version that you are still seeing the issue?

Thanks, Darrel. There can I get v 1.2? Is it published to NuGet?
Regards,
Alex
On May 24, 2020, at 18:26, Darrel<EMAIL_ADDRESS>wrote:

I just switched my machine to French and confirmed that numbers were rendering with commas. I then tried your example using the code in the vnext branch and it behaved as expected.
I am going to release the 1.2 version. Could you check with that version that you are still seeing the issue?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/OpenAPI.NET/issues/478#issuecomment-633309606, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADLM2QXRSEZ5FU5V2WIR42TRTGNIXANCNFSM4NEIO6DA.

Hi Darrel, I can confirm that the issue is fixed in 1.2. I'm going to close the issue now. Thanks!


Issue Adding Images

Hello,
I've been having an issue with the anchore engine scanning a local image in my local registry.  I'm getting the following error.
Error: cannot fetch image digest/manifest from registry
HTTP Code: 400
Detail: {u'raw_exception_message': u'could not get manifest/digest for image (localhost:5000/textron:latest) from registry (https://localhost:5000) - error: Error encountered in skopeo operation. cmd=/bin/sh -c skopeo  inspect --raw --tls-verify=false  docker://localhost:5000/textron:latest, rc=1, stdout=None, stderr=b'time="2019-03-28T16:28:14Z" level=fatal msg="pinging docker registry returned: Get http://localhost:5000/v2/: dial tcp <IP_ADDRESS>:5000: connect: connection refused" \n''}
The image is not one that I created but one that has been provided to me.
Leets

Just a heads up. I resolved this issue now by creating dns records in my private dns servers (Active Directory in this case). What is strange is that there were valid dns entries in a public dns zone (though A records were private IPs). Our admin is new to AWS and created the r53 zone as public. Curl to the private registry from anchore succeeded but the image add thru the skopeo error- same as above.
Creating the private dns zone AD resolved this issue immediately. Any idea why??


feat(osmoutils): helper to find ith smallest min or max

Closes: #XXX
UPD: related to #5365
What is the purpose of the change
This is a passion-project to review some divide-and-conquer algorithms.
This introduces a helper to efficiently find the ith min or max (determined by the less function) in O(n).
More info can be found here:

https://brilliant.org/wiki/median-finding-algorithm/
https://www.youtube.com/watch?v=EzeYI7p9MjU

There is not use case for this at this time but might be a good helper to have in osmoutils.
Testing and Verifying
This change added tests.
Documentation and Release Note

Does this pull request introduce a new feature or user-facing behavior changes? no
Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md?  no
How is the feature or change documented? not applicable

Closing for staleness. @pysel please don't remove stale labels for something not actively being worked on!
If work is restarted, lets re-open PR at that time :)


Rewrite Draft

Had a few minutes so have updated the tox and pyproject config

Fixes #37

This is not the final version of the Cassandra rewrite but I think it is a good checkpoint with lots of improvements

@sed-i can you please have a look at the integration test?

The most recent failed test says Unit in error: cassandra-k8s/0, which means the charm's status was not idle/active but error.

Yeah I see this and I haven't been able to figure out why. It always passes when run locally. Also, I briefly looked at some other repos and they seem to be having the same error.

Yeah I see this and I haven't been able to figure out why.

In your [testenv:integration], change the command to
pytest -v --tb native --log-cli-level=INFO -s {posargs} {toxinidir}/tests/integration
and you will be able to see more log messages


[Refactor] Add: SWAG,RACE,Arithmetic,Winogrande,PubmedQA

This PR ports over the following tasks: SWAG,RACE,Arithmetic,Winogrande,PubmedQA
Progress:

[x] SWAG
[x] Arithmetic
[x] Pubmed QA
[x] Winogrande
[ ] RACE

Update: This PR also adds a new task type winograd_schema for use with Winogrande and other "multiple contexts same continuation" type tasks.
Results from master:

Task
Version
Metric
Value

Stderr

arithmetic_1dc
0
acc
0.0000
±
0.0000

arithmetic_2da
0
acc
0.0035
±
0.0013

arithmetic_2dm
0
acc
0.0125
±
0.0025

arithmetic_2ds
0
acc
0.0075
±
0.0019

arithmetic_3da
0
acc
0.0010
±
0.0007

arithmetic_3ds
0
acc
0.0015
±
0.0009

arithmetic_4da
0
acc
0.0005
±
0.0005

arithmetic_4ds
0
acc
0.0000
±
0.0000

arithmetic_5da
0
acc
0.0000
±
0.0000

arithmetic_5ds
0
acc
0.0000
±
0.0000

pubmedqa
0
acc
0.4340
±
0.0157

race
1
acc
0.2947
±
0.0141

swag
0
acc
0.4052
±
0.0035

acc_norm
0.5378
±
0.0035

winogrande
0
acc
0.5162
±
0.0140

Run with:
python main.py     --model hf-causal     --tasks race,swag,arithmetic_*,pubmedqa,winogrande     --device cuda:0     --no_cache     --batch_size auto

Results from this PR:
hf (), limit: None, num_fewshot: 0, batch_size: 4

Task
Version
Filter
Metric
Value

Stderr

arithmetic_1dc
Yaml
none
acc
0.0000
±
0.0000

arithmetic_2da
Yaml
none
acc
0.0035
±
0.0013

arithmetic_2dm
Yaml
none
acc
0.0125
±
0.0025

arithmetic_2ds
Yaml
none
acc
0.0075
±
0.0019

arithmetic_3da
Yaml
none
acc
0.0010
±
0.0007

arithmetic_3ds
Yaml
none
acc
0.0015
±
0.0009

arithmetic_4da
Yaml
none
acc
0.0005
±
0.0005

arithmetic_4ds
Yaml
none
acc
0.0000
±
0.0000

arithmetic_5da
Yaml
none
acc
0.0000
±
0.0000

arithmetic_5ds
Yaml
none
acc
0.0000
±
0.0000

pubmed_qa
Yaml
none
acc
0.434
±
0.0157

race
Yaml
none
acc
0.2947
±
0.0141

swag
Yaml
none
acc
0.4052
±
0.0035

none
acc_norm
0.5378
±
0.0035

winogrande
Yaml
none
acc
0.5162
±
0.0140

Run with:
python main.py \
    --model hf \
    --tasks winogrande,swag,race,pubmed_qa,arithmetic_*\

PR is ready! Just one note: on master branch, the RACE dataset is post-processed with a custom function that just groups all questions from the same article together. Since this requires some custom code and is pretty easy to do once, I just reprocessed the dataset and uploaded it to my hf here. Once we're sure the PR is ready to go, let me know, and I'll transfer it over to Eleuther's account and update the task config

@lintangsutawika Done.

Overall, I'm still not sure if we should have winograd_schema as another output type. There doesn't seem to be much different to multiple_choice other than how context and choices are derived. My guess is both context and choices should be able to be built in create_choices.

After a discussion with @haileyschoelkopf I think it's okay to go through with this PR.

Could this PR have significant impact on Winogrande metric? I am experiencing discrepancy when using v0.4.0 and the version that HuggingFace uses for Open LLM Leaderboard (commit b281b09).
For two Llama2 models (quantized and unquantized), the Winogrande metric on v0.4.0 is significantly lower than what was produced using an older version of the harness, as shown below:

Model
Harness Version
Winogrande

meta-llama/llama-2-7b-chat-hf
v0.4.0
66.38**

meta-llama/llama-2-7b-chat-hf
b281b09
73.01

TheBloke/Llama-2-7B-Chat-GPTQ
v0.4.0
65.43**

TheBloke/Llama-2-7B-Chat-GPTQ
b281b09
70.80


BT discharge thresholds

No discharge thresholds are currently provided for BT spawning/rearing in the parameters.
@NewGraphEnvironment - is this an issue? Just use CW everywhere for BT for now?
I'm surprised this issue hasn't already popped up, I am not sure what BT spawning/rearing would currently look like in Fraser watersheds where discharge is used, with the null parameters I'd guess it would be empty.
confirmed - no modelling of BT in Fraser/Peace in current output.
Options:

modify param to use CW everywhere
add discharge param for BT
modify BT model to use CW only

Let's modify param to use CW everywhere for now until we can understand both the accuracy of MAD estimates in streams small enough for culverts as well as why certain thresholds are being applied to specific species.
My understanding is that our ability to use real data for channel width as well as calibrate estimates on small streams with real data far far exceeds that for deriving MAD.


user docs: Write user docs for emoji reactions.

We could add a doc on emoji reactions, specifically:

how to add a reaction
using the search box
limits on the number of reactions per message
un-reacting

Good point!
(There aren't any limits to number of reactions on a message, BTW...)

Are we not limiting it to 6 emoji per message? I do vaguely remember reading that somewhere :)

Nope.  We are limiting it to like 1000 (however many emoji there are).

I would like to work on it.

Theres already a doc available on emoji. In zullip/doc/emoji.md

That's a developer-facing doc.  We're talking about user-facing docs, i.e. templates/zerver/help/ stuff.
See http://zulip.readthedocs.io/en/latest/user-docs.html

Wrote a user doc for this in PR #3714!


Migrate web interface to OpenPoGoUI

Short Description
OpenPoGoWeb is deprecated
Possible solution
Output events like OpenPoGoBot
How it would help others
Better UI with active support & development.

How about moving to OpenPoGoBot ?

Web interface is being worked on, we will not be moving to OpenPoGoWeb

k4n30
An update regarding web ui?


Can electron cgi work with an already built and obfuscated C# executable?

Hello, I'm working with a friend on making a modding tool for games.
My friend makes the entire pointer system and game modding code in C# and I need to take care of the UI;
I want to make clear that both the c# .exe and electron will run on the same machine and I cannot just add the C# project source to the electron project because It needs to be closed source and obfuscated to avoid misuse of our code.
So, can electron-cgi work with an already built and obfuscated C# executable?

Hi @mxswat
If you can make a C# console application that uses the C# code you already have, then yes, and that can be obfuscated too, really doesn't matter.

Hi @ruidfigueiredo Thanks for the quick answer I have another question
this means that I can just do
const connection = new ConnectionBuilder()         .connectTo('dotnet', 'run','Editor.exe')
Without having to load the project?

@mxswat Actually, less than that:
const connection = new ConnectionBuilder() .connectTo(Editor.exe')
Don't really know what you mean by loading the project. The thing is, Editor must be be using with the ElectronCgi.DotNet nuget package and have the appropriate configuration for receiving the type of requests you need from node

Oh, this is amazing, also is there any docs for the entire project?

Hi @mxswat thanks!
There are a few blog posts:
https://www.blinkingcaret.com/2020/03/25/electroncgi-1-0-cross-platform-guis-for-net-core/
https://www.blinkingcaret.com/2019/11/27/electroncgi-a-solution-to-cross-platform-guis-for-net-core/
And there are a few examples apps, the latest one I built was this: https://github.com/ruidfigueiredo/MemorizeADeck
There's also a podcast episode about ElectronCgi if you are interested in the story behind it: https://www.automator.show/18

@ruidfigueiredo thank you so much for the time you are using to help me

I was able to make electron cgi launch the .exe by doing a simple trick of putting the .exe into dist_electron
When I added  connection.Send("greetingx", "hello from c#"); on the C# file I got this error

What can be the cause of the problem?

"Hello World from MessageService!" that was written to the stdout stream (there's a Console.WriteLine with that somewhere in C#).
ElectronCGI uses the stdout and stdin streams to build a communication channel between the two processes, if you write to those yourself you'll get those errors.

So, I went in Debug inside the file tab-separated-input-stream-parser.js and I noticed it just now!

My brain completely ignored "Hello World from MessageService!"
This is what happens when I keep coding at 2AM lol

So I guess I should attach a custom console to have console logs in the C# project, not a big deal

It works perfectly now


wrap webkitRTCPeerConnection

this wraps the webkitRTCPeerConnection in a JS object. This should be implementing all important properties and methods. Obviously, any new methods (e.g. ontrack) exposed by the native peerconnection need to be added here before they can become available.
For now, this should allow shimming ontrack and promise-based SLD/SRD. Still need some code to prove that.

This should make some changes to the external behavior - the most obvious one should be that the class of the returned object is RTCPeerConnection, not WebkitRTCPeerConnection (I think).
Can you add a test verifying that this change happened?
(I always want a test that failed before the change was made...)

@alvestrand hah, "scribbling over" those fields (i.e.overriding webkitRTCPeerConnection.prototype.createOffer et al) will be much simpler, thanks! New PR incoming...

Heh - the RTCPeerConnection prototype isn't exposed to Javascript, so it has to be done more circuitously.....
The thing I was worried about was that the way you wrote it, I was worried that the first time, it would go "wrap underlying RTCPeerConnection.xxx in my own RTCPeerConnection.xxx", and if called a second time, it would do the same, leading to an extremely long prototype chain of RTCPeerConnection.xxx ... is that a worry, or is it something we don't worry about?


Change merge strategy to preserve Plugins when importing Configs

Hi guys,
Hope you are all doing well. At work we ran into the following issue. Which is also being discussed here: https://github.com/containerd/containerd/issues/5837. This PR tries to propose a solution.
Example
Given the following config.toml for containerd:
# cat /cm/local/apps/containerd/var/etc/config.toml
version = 2
imports = ["/cm/local/apps/containerd/var/etc/conf.d/*.toml"]

With multiple files that match this import:
# cat /cm/local/apps/containerd/var/etc/conf.d/cri.toml
[plugins."io.containerd.grpc.v1.cri".cni]
    bin_dir = "/cm/local/apps/kubernetes/current/bin/cni"

# cat /cm/local/apps/containerd/var/etc/conf.d/registry.toml
[plugins."io.containerd.grpc.v1.cri".registry]
    config_path = "/cm/local/apps/containerd/var/etc/certs.d"

The current merge strategy for imports will overwrite the entire plugin io.containerd.grpc.v1.cri.
This means that depending on the filenames, containerd ends up with either just the cni config, or just the registry config. This was a conscious decision in the past. I hope however we can slightly modify this behavior in containerd, to merge the Plugin configuration instead? :innocent:
Current behavior
The two imports from the example effectively result in containerd having this configuration for the plugin:
[plugins."io.containerd.grpc.v1.cri".registry]
    config_path = "/cm/local/apps/containerd/var/etc/certs.d"

Note the absence of the cni bin_dir configuration, that was overwritten.
New proposed behavior
The change in this PR will have the merge result in the following configuration instead:
[plugins."io.containerd.grpc.v1.cri".cni]
    bin_dir = "/cm/local/apps/kubernetes/current/bin/cni"

[plugins."io.containerd.grpc.v1.cri".registry]
    config_path = "/cm/local/apps/containerd/var/etc/certs.d"

There are also two extra unit tests that attempt to demonstrate the change.
Why this change?
Whether the proposed behavior is better is probably subjective, but reasons why I am in favor of it ...
Let's say we have three configurations, cni.toml (for cni bin), registry.toml (for cert config path) and nvidia.toml (for changing the default runtime to nvidia).
Then it's nice to have separate smaller files, also arguably easier to get rid of certain configuration (get rid of nvidia being default runtime, rm -rf nvidia.toml). The problem now is that they all add something to the io.containerd.grpc.v1.cri plugin, and the last one wins.
If you have existing configuration files, it's in my opinion extra burden for the user to have the user first figure out which of the files already configures something for the same plugin before they can add their configuration without removing existing config.
In our case we try to automate this, so our code becomes more complex because of this as well :stuck_out_tongue:
How the old merge works
The following function seems to take care of the merging:
https://github.com/containerd/containerd/blob/455127859b70eb0e06d426be9ebb42ebd8c8674a/services/server/config/config.go#L291
The config.Config being merged, has Plugins map[string]toml.Tree and is the only field in the struct that includes the toml.Tree struct. The above mentioned merge function will handle the actual merging of this struct here:
https://github.com/containerd/containerd/blob/455127859b70eb0e06d426be9ebb42ebd8c8674a/vendor/github.com/imdario/mergo/merge.go#L90-L96
This will already have the effect of overwriting the whole io.containerd.grpc.v1.cri plugin, which surprised me! Because that means that the following for loop is unnecessary (which is why I removed it in this PR):
https://github.com/containerd/containerd/blob/455127859b70eb0e06d426be9ebb42ebd8c8674a/services/server/config/config.go#L296-L299
How the new merge works
In my PR I used the Transformer feature from mergo (see https://github.com/imdario/mergo#transformers)
With that feature we can hook into toml.Tree's merge from src to dst with a callback function. Since it will overwrite the struct completely, the best idea I could come up with is to preserve the values that would have been discarded by copying them from destination to source. This is slightly confusing, but knowing that mergo.merge will overwrite destination with source later, the values need to be present in source :smiley:
How I tested this code change
In order to avoid cluttering this already long PR description, I will add a text document as an attachment that shows a "real" example, how I tested if this code is also working on a real machine, and not just in unit tests.
Please let me know if this approach makes sense, and if not, how to do it differently.
It would make my life quite a bit easier if this would be the merge behavior for importing configs, but would be even better if others agree and see it as an improvement as well.
Thanks,
Ray
manual_testing.txt

Thanks for the detailed description and extra tests to validate behavior. Overall I understand what is being improved here and it seems valuable.
I guess one (lazy) question: does this now mean that load order is important for imports which may all have defined settings for the same entry? I haven't ever looked closely at mergo or our specific use of it, but I guess the open question in my mind is whether we now have a potential ordering/"race", and if so, maybe more importantly, is that ordering reliable or random (if I run merge one time and file 3 wins over file 2, will that always be true, or will sometimes file 2 win over file 3 for the same setting)? Mostly I just want to understand so we know whether or not we need to define expected behavior. I think with our current less "intelligent" implementation this just wasn't an issue as a single file could only impact an entire plugin and there was no true merging of line-by-line settings within a tree branch.

Hi Phil, thanks for the feedback!
You're right, it depends on the order in which the files are listed in the "imports" array. Luckily everything is all sorted and deterministic. The following in config.toml:
imports = ["/path/data1.toml", "/path/data2.toml"]
Will have data1.toml merge over config.toml, and then data2.toml over (already updated) config.toml.
Globs can also be used in this imports array. Those are luckily expanded to files in lexicographical order, I confirmed it with a debugger and some extra tests. This function (resolveImports) is where the glob is handled when loading the config:
https://github.com/containerd/containerd/blob/455127859b70eb0e06d426be9ebb42ebd8c8674a/services/server/config/config.go#L260-L267
Zooming in on filepath.Glob eventually a sort is found to guarantee lexicographical order:
https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/path/filepath/match.go;l=347;drc=ccab2fbc30b0553fce54646a4da0a8645eda40a3
One combined example to demo all the behavior:
imports = ["/foo/data1.toml", "/bar/*.toml", "/aaa/a.toml"]
Let's say there are a few files in /bar: a.toml, b.toml and c.toml. Then the result becomes:
imports = ["/foo/data1.toml", "/bar/a.toml", "/bar/b.toml", "/bar/c.toml", "/aaa/a.toml"]
The code that is responsible for merging each config can be seen in the caller of resolveImports here:
https://github.com/containerd/containerd/blob/455127859b70eb0e06d426be9ebb42ebd8c8674a/services/server/config/config.go#L215

@estesp Is there anything I can do to help get this PR merged? I think it's an important one generally for configuration, it's important to me at least!

This looks like a great change, we have very similar usecases adding nvidia and registry drop in files at runtime and this would enable us to remove old-standing workarounds.

@elezar @klueska @shivamerla @fidencio FYI

Sorry if the history of this PR now looks a little messy/verbose, it's because in the meantime the code base has changed.
I removed my transformer (I'll keep it as a text file in this comment just for the sake of archiving), in favor of the existing sliceTransformer that was recently introduced here:
https://github.com/containerd/containerd/commit/15713014d698fcd3e5a56b720af320e3a00d3eae
I've left the minimally required fix needed at this point + unit tests. This makes at least the diff for this PR much simpler.
I'll also include the output for the tests without and without the fix (just to show how the added tests would fail without the change), for convenience. Please let me know if I need to change something more!
TomlTreeTransformer.txt
make_test_with_fix.txt
make_test_without_fix.txt

@rayburgemeestre since cri-o already supports drop-in files for overriding the config, does following a similar mechanism here work too? See https://github.com/cri-o/cri-o/blob/e0e17ee187c9f52d870b80cee9116c4fd5ca279e/pkg/config/config.go#L699
I haven't dug too much into whether only leaves of the config tree are replaced this way, but I know that this is commonly used to configure the NVIDIA runtime through a drop-in file, for example.

@elezar You can specific an import path or glob for loading configurations files which can override the base config. This is just changing the logic to merge the plugin configs rather than overriding the entire config. We also support dynamic drop in files for stuff like registry host configuration and cni.
I think this change is fine to accept as is. There are probably some surprise cases which we should make sure we document. I also found that the equal check in arrays of structs didn't work as well as I would have hoped. We can probably add more tests around that.
A separate put related change to this, we discussed changing config_path = "/cm/local/apps/containerd/var/etc/certs.d" to an actual array type. This would fit well with this feature if you were to drop in a whole configuration with its own directory of registry configs. Currently it uses a string split on a path separator, which is not great and doesn't allow anyway to merge.

After quite a bit of confusion because of switching back and forth between version 1.7.13 for work and 'master' for this PR. It turned out that containerd config dump did not seem to give reliable output for me. I tried to address it in my second/latest commit, I'm curious if my change makes sense to you as well @dmcgowan.
Some changes I made are:

outputConfig was always writing to os.Stdout. I added a unit test so I wanted to assert on the output, so I changed it to use generateConfig under the hood, which takes an io.Writer for the customizing the output.
generateConfig (in my PR, previously outputConfig) did some plugin loading and overwriting. However that would result in basically removing previously loaded stuff (LoadConfigs done in "dump" and "migrate" commands). My suggested fix is to do the loading and registration of plugins as it pleases, but then after that, we should merge the config that was read from disk on top of that, using the existing mergeConfig logic. Which I had to make public by renaming to MergeConfig for this reason, because it came from a different package.

The original change from earlier commits is still there and needed in my opinion.
Restoring for example this block of replacing entire plugins will nicely show what the effect is now with the unit tests, see: test_fails.txt
The simplest failure is from the first test here: https://github.com/containerd/containerd/pull/7347/files#diff-9dcf619ce07838a6db58d9519023dc77b0e4356c8e3e56ddea8029e43b937d93R257-R276. The [cni] part would be gone without it, as it is overwritten when the config for [registry] was merged.

It turned out that containerd config dump did not seem to give reliable output for me.
...
My suggested fix is to do the loading and registration of plugins as it pleases, but then after that, we should merge the config that was read from disk on top of that, using the existing mergeConfig logic.

Calling merge config after plugin decode seems like it may cause issues with the types not matching. The Decode takes the map[string]interface{}, marshals it into bytes then unmarshals it into the config struct provided by the plugin. One side of the merge would have had this extra processing while the other did not. If this behavior was needed, then the same marshal/unmarshal back into map[string]interface{} would likely be need to make the merge consistent.

I see, I think I did overlook that something changed. When trying to 'demo' in a concise manner I see that the original code gives warnings that are no longer shown after my changes. I will dig deeper into into. But in the meantime I'll share what was my motivation for the change.
This is my containerd config that I'll use to test:
root@nvidia:~# cat /etc/containerd/config.toml
version = 2
imports = ["/cm/local/apps/containerd/var/etc/conf.d/*.toml"]

root@nvidia:~# ls -1 /cm/local/apps/containerd/var/etc/conf.d
cni-bin-dir.toml
cni-conf-dir.toml

root@nvidia:~# cat /cm/local/apps/containerd/var/etc/conf.d/cni-bin-dir.toml
[plugins."io.containerd.grpc.v1.cri".cni]
    bin_dir = "/easily/greppable"

root@nvidia:~# cat /cm/local/apps/containerd/var/etc/conf.d/cni-conf-dir.toml
[plugins."io.containerd.grpc.v1.cri".cni]
    conf_dir = "/easily/greppable"

Then the original behavior of config dump doesn't show these customizations at all:
root@nvidia:/mnt/work# containerd config dump | grep imports
WARN[0000] Ignoring unknown key in TOML for plugin       error="strict mode: fields in the document are missing in the target struct" key=cni plugin=io.containerd.grpc.v1.cri
imports = ['/cm/local/apps/containerd/var/etc/conf.d/*.toml']

root@nvidia:/mnt/work# containerd config dump|grep easily -B 1
WARN[0000] Ignoring unknown key in TOML for plugin       error="strict mode: fields in the document are missing in the target struct" key=cni plugin=io.containerd.grpc.v1.cri

My theory was that it is because it would be overwritten, hence why I was merging back the user config, so after my change the same config dumps result in:
root@nvidia:~# containerd config dump | grep imports
imports = ['/cm/local/apps/containerd/var/etc/conf.d/*.toml']

root@nvidia:~# containerd config dump|grep easily -B 1
    [plugins.'io.containerd.grpc.v1.cri'.cni]
      bin_dir = '/easily/greppable'
      conf_dir = '/easily/greppable'

I've also just noticed that in v1.7.x the config dump results seem more correct. And also it seems like it has been evaluated... the import line looks expanded:
imports = ["/etc/containerd/config.toml", "/cm/local/apps/containerd/var/etc/conf.d/cni-bin-dir.toml", "/cm/local/apps/containerd/var/etc/conf.d/cni-conf-dir.toml"]

And also at least it did apply those imports:
root@nvidia:/mnt/work# /tmp/containerd config dump | grep easily -B 2
    [plugins."io.containerd.grpc.v1.cri".cni]
      bin_dir = "/opt/cni/bin"
      conf_dir = "/easily/greppable"

This 1.7.2 is vanilla and it still has the original overwrite plugins behavior (and no sliceTransformer)

Hi all, I've rebased my changes, and all the CI checks seem to succeed again

Closing in favor of https://github.com/containerd/containerd/pull/9982


Validate k8s 1.12 for 2.x

Scheduled release: September 25

Merging into https://github.com/rancher/rancher/issues/15872


Exporter endpoint doesn't send traces

Describe the bug
Are not sent any trace to the exporter endpoint when lambda receives many requests per second but in the case of sending logs all works as expected.
Steps to reproduce
The application I'm using for this test is based on ab Api Gateway integrated with a Lambda (store a record in dynamodb table). It's a simple API endpoint to create a resource in the database.
If I create an isolated request, all work as expected, and logs and traces are shown in New Relic.
The problem was when I tried to use AWS Load Testing Tool to generate some Requests per second, and in this case, logs arrives at New Relic but nothing about traces.
What did you expect to see?
All the traces in New Relic (exporter endpoint)
What did you see instead?
No traces are shown in New Relic.
What version of collector/language SDK version did you use?
Version: (v0.70)
What language layer did you use?
Config: (dotnet)
The collector configuration is shown below:
receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  logging:
    loglevel: debug
  otlp:
    endpoint: ${NEW_RELIC_OPENTELEMETRY_ENDPOINT}
    headers:
      api-key: ${NEW_RELIC_LICENSE_KEY}

service:
  telemetry:
    logs:
      level: debug
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [logging,otlp]
    metrics:
      receivers: [otlp]
      exporters: [logging,otlp]
    logs:
      receivers: [otlp]
      exporters: [logging,otlp]

Additional context

It was an internal issue about how I was generating the ActivityContext (not recorded flag)

It was an internal issue about how I was generating the ActivityContext (not recorded flag)


[WIP] ClusterClass support in CAPX

What this PR does / why we need it:

 deepak.muley@C02ZG5BMLVDL  ~/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix   clusterclassv4  kubebuilder create api --group infrastructure --version v1beta1 --kind NutanixClusterTemplate
INFO Create Resource [y/n]
y
INFO Create Controller [y/n]
y
INFO Writing kustomize manifests for you to edit...
INFO Writing scaffold for you to edit...
INFO api/infrastructure/v1beta1/nutanixclustertemplate_types.go
INFO api/infrastructure/v1beta1/groupversion_info.go
INFO internal/controller/infrastructure/suite_test.go
INFO internal/controller/infrastructure/nutanixclustertemplate_controller.go
INFO Update dependencies:
$ go mod tidy
INFO Running make:
$ make generate
GOBIN=/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin /Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/scripts/go_install.sh k8s.io/code-generator/cmd/conversion-gen conversion-gen v0.23.6
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/controller-gen-v0.8.0 object:headerFile="hack/boilerplate.go.txt" paths="./..."
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/conversion-gen \
	--input-dirs=./api/infrastructure/v1alpha4 \
	--input-dirs=./api/infrastructure/v1beta1 \
	--build-tag=ignore_autogenerated_core \
	--output-file-base=zz_generated.conversion \
	--go-header-file=./hack/boilerplate.go.txt
Next: implement your new API and generate the manifests (e.g. CRDs,CRs) with:
$ make manifests

 kubebuilder create webhook --group  infrastructure --version v1beta1 --kind NutanixClusterTemplate --defaulting --programmatic-validation --force
INFO Writing kustomize manifests for you to edit...
ERRO Unable to find the target #- path: manager_webhook_patch.yaml to uncomment in the file config/default/kustomization.yaml.
INFO Writing scaffold for you to edit...
INFO api/infrastructure/v1beta1/nutanixclustertemplate_webhook.go
INFO api/infrastructure/v1beta1/webhook_suite_test.go
INFO Update dependencies:
$ go mod tidy
go: finding module for package sigs.k8s.io/controller-runtime/pkg/metrics/server
go: found sigs.k8s.io/controller-runtime/pkg/metrics/server in sigs.k8s.io/controller-runtime v0.16.3
go: finding module for package gotest.tools/v3/skip
go: finding module for package gotest.tools/v3/assert
go: finding module for package gotest.tools/v3/env
go: finding module for package gotest.tools/v3/assert/cmp
go: found gotest.tools/v3/assert in gotest.tools/v3 v3.5.1
go: found gotest.tools/v3/assert/cmp in gotest.tools/v3 v3.5.1
go: found gotest.tools/v3/env in gotest.tools/v3 v3.5.1
go: found gotest.tools/v3/skip in gotest.tools/v3 v3.5.1
INFO Running make:
$ make generate
GOBIN=/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin /Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/scripts/go_install.sh k8s.io/code-generator/cmd/conversion-gen conversion-gen v0.23.6
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/controller-gen-v0.8.0 object:headerFile="hack/boilerplate.go.txt" paths="./..."
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/conversion-gen \
	--input-dirs=./api/infrastructure/v1alpha4 \
	--input-dirs=./api/infrastructure/v1beta1 \
	--build-tag=ignore_autogenerated_core \
	--output-file-base=zz_generated.conversion \
	--go-header-file=./hack/boilerplate.go.txt
Next: implement your new Webhook and generate the manifests with:
$ make manifests

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
How Has This Been Tested?:

 ✘ deepak.muley@C02ZG5BMLVDL  ~/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix   clusterclassv4  make manifests
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/controller-gen-v0.8.0 "crd:crdVersions=v1" rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=config/crd/bases
 deepak.muley@C02ZG5BMLVDL  ~/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix   clusterclassv4  make cluster-templates
GOBIN=/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin /Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/scripts/go_install.sh sigs.k8s.io/kustomize/kustomize/v4 kustomize v4.5.4
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/kustomize-v4.5.4 build templates/base > templates/cluster-template.yaml
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/kustomize-v4.5.4 build templates/csi > templates/cluster-template-csi.yaml
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/kustomize-v4.5.4 build templates/ccm > templates/cluster-template-ccm.yaml
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/kustomize-v4.5.4 build templates/clusterclass > templates/cluster-template-clusterclass.yaml
 deepak.muley@C02ZG5BMLVDL  ~/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix   clusterclassv4  make all
GOBIN=/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin /Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/scripts/go_install.sh k8s.io/code-generator/cmd/conversion-gen conversion-gen v0.23.6
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/controller-gen-v0.8.0 object:headerFile="hack/boilerplate.go.txt" paths="./..."
 Please use 'patches' instead. Run 'kustomize edit fix' to update your Kustomization automatically.

Fixed fields:
  patchesJson6902 -> patches
  patchesStrategicMerge -> patches
  commonLabels -> labels

To convert vars -> replacements, run the command `kustomize edit fix --vars`

WARNING: Converting vars to replacements will potentially overwrite many resource files
and the resulting files may not produce the same output when `kustomize build` is run.
We recommend doing this in a clean git repository where the change is easy to undo.

 deepak.muley@C02ZG5BMLVDL  ~/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix   clusterclassv4 ±  make cluster-templates
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/kustomize-v5.2.1 build templates/base > templates/cluster-template.yaml
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/kustomize-v5.2.1 build templates/csi > templates/cluster-template-csi.yaml
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/kustomize-v5.2.1 build templates/ccm > templates/cluster-template-ccm.yaml
/Users/deepak.muley/go/src/github.com/deepakm-ntnx/cluster-api-provider-nutanix/hack/tools/bin/kustomize-v5.2.1 build templates/clusterclass > templates/cluster-template-clusterclass.yaml

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration and test output
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
Release note:

@deepakm-ntnx I'm going to look at this on Monday, but is there any chance you could split this PR up into smaller, logical chunks? It would make reviewing much easier, especially coming at it with little context like me 😅 I was thinking it could be broken down into: kustomization edit fixes; kubebuilder plugin v4 layout changes (including moving api package); adding ClusterClass template API kinds. WDYT?

@deepakm-ntnx I'm going to look at this on Monday, but is there any chance you could split this PR up into smaller, logical chunks? It would make reviewing much easier, especially coming at it with little context like me 😅 I was thinking it could be broken down into: kustomization edit fixes; kubebuilder plugin v4 layout changes (including moving api package); adding ClusterClass template API kinds. WDYT?

Sure, but its still WIP. will do that once tests are working. wasn't planning to add reviewers yet


Food purchase and pickup responsibilities

Lunch: Every lunch is catered.
Breakfast :
Coffee from Starbucks
First need to check Costco pricing for what to bring

Sat Breakfast
Sat Lunch
Sun Breakfast
Sun Lunch
Mon Breakfast
Mon Lunch

Items
-----
-----
-----
-----
-----
-----

Purchasers
-----
-----
-----
-----
-----
-----

Helpers for pickup
-----
-----
-----
-----
-----
-----

Santina and I got item prices for foodstuff we think are appropriate for a light breakfast and snacks. We also came up with a plan for what to buy for the three days. See the Google Spreadsheet below.
https://docs.google.com/spreadsheets/d/1DQLlcboxWgMup3e3zbsMZLaeWlcVcSpnj_bKtqtVGTE/edit?usp=sharing

@minisciencegirl @brunogrande Should we split the list? @minisciencegirl maybe you could get the packaged goods and @brunogrande the fruits?
@brunogrande do you need me to go with you to buy the food or could you go with Santina?
I will arrange coffee for breakfast
Remember to save your receipts for parking and add them in the reimbursement form

I added a new column in the Googleform to list the bulky stuff that I can purchase. Are the muffins the giant muffins made by Costco bakery? I can pick those up too.
@adrisua: Since I will drive in all the bulky stuff, I probably won't meet you at your condo in the morning. However, if someone could meet me at LSI in the morning to help unload, that will be great.

@minisciencegirl Sounds good. What about Sunday and Monday? Since we can't leave stuff at LSI, would you like to do the same each day? Thanks!

@adrisua: No problem. Do you think the baked goods will stay fresh on Monday if I pick things up on Friday? I was thinking of leaving a bit early on Sunday (Costco closes at 5pm) to pick up stuff for Monday.
@brunogrande: let me know if there's any other bulky item that you want me to pick up from Costco.

Santina and I don't mind doing a Costco run. However, we need to rent a car to buy the stuff from Costco (Modo: ~$8) and then rent another car to bring the stuff to UBC (Evo: ~$16) on Saturday morning (total: ~$24).
If the organizers are okay with covering the car sharing cost, then Santina and I can go. Otherwise, I can go with @adrisua. What do people think?
Santina also made a good point. It's hard to gauge how much people are going to eat during the event. If Amy is going to do a second Costco run on Sunday night, I recommend we buy all food items for the first two days on the first run, and we adjust the quantity Amy will buy on Sunday based on leftovers.

Great idea. I added the car rental to the budget. Thanks!

Works for me. Thanks @brunogrande and @santina. Also did we budget in the increased number of participants on Monday?

@minisciencegirl GA4GH have moved to the Marriott, so it's only us

Final setup: Santina and I will do a Costco run on Friday morning and get everything for the first two days. Amy will do a second Costco run Sunday afternoon based on what's left over.


SAML ticket validation in 5.x

CAS server version: 5.1.2
Container: Tomcat
I believe I've come across a bug in the SAML ticket validation feature as of version 5.x. In 4.x there was a 30 second interval between the NotBefore and NotOnOfAfter conditions in the SAML assertion, like the one below:
<Conditions NotBefore="2008-12-10T14:12:14.817Z" NotOnOrAfter="2008-12-10T14:12:44.817Z">

As of version 5.x, the two timestamps are the same by default, which is causing an application we use to see the assertions as expired. From what I've been able to determine, the SAML object builder is expecting an issueLength parameter (see here) but the value is set by the skewAllowance property (see here). I'm assuming this is a mistake since the skewAllowance property is set to zero by default.
I've been able to work around this issue temporarily by hardcoding a value of 30000 for the intervalLength (30 secs), and I can confirm this results in correct values for the NotBefore and NotOnOfAfter conditions. My apologies for not including a pull request with this, but I'm not much of a Java developer and don't know how this should be handled going forward. Maybe add a cas.samlCore.intervalLength property?

I'm assuming this is a mistake since the skewAllowance property is set to zero by default.

If you adjust skewAllowance, does the problem go away?

Added defaults for skewAllowance up to 5 seconds.

I did try the skewAllowance, but that just controls how many seconds (forward or backward) to shift the assertion validity period. The intervalLength also uses milliseconds (with a default of 30000 in 4.x), so I can't use this property to adjust that effectively.

The skewAllowance that is passed to the Saml10SuccessResponseView builds the conditions block:
final Conditions conditions = this.samlObjectBuilder.newConditions(issuedAt, service.getId(), this.skewAllowance);

And as you note, the allowance is used to skew the NotOnOrAfter:
conditions.setNotOnOrAfter(DateTimeUtils.dateTimeOf(issuedAt.plus(issueLength, ChronoUnit.MILLIS)));

You can try changing the above line to:
conditions.setNotOnOrAfter(DateTimeUtils.dateTimeOf(issuedAt.plus(issueLength, ChronoUnit.SECONDS)));

and that should allow you to keep both consistent. Would that work?

Unfortunately that still wouldn't work - the skewAllowance is currently used to shift the validity period backwards by the number of seconds specified (and forwards for negative values). For example, a value of 30 would set NotBefore to 30 seconds in the past. The NotOnOrAfter value would be 30 seconds later as expected, but the assertion would still end up with an expired validity period.

Excellent diagnosis; so in addition to making time units consistent, how about we ensure the assertion validity period uses the same sort of logic as the conditions block?
Meaning both:

Use seconds
Positive skew shifts the period forward.
Negative skew pushes the period backward.

This seems like the better approach altogether and it's less confusing overall (and I cant think of a case where you want to be able to control these things individually and separately, that is the issue length and the condition), but if you feel like a separate property is easier to do and understand, by all means please do.

I agree completely about making that consistent - using seconds and making positive values shift that forward instead of backward would be much more intuitive. That being said, I think the validity interval should be independent from the skewAllowance property, which has a completely different purpose. Ideally I'd like to see the default behavior restored back to what was in 4.x - meaning a default validity interval of 30 seconds by default and a skewAllowance of zero. The application we use with this feature (Ellucian Banner) is expecting 4.x behavior and I'm guessing this would make it easier for Ellucian to certify 5.x in the future.

Sounds very reasonable. In fact, there is no reason why we can't do both options and in the meanwhile, restore the behavior back to what 4.1 is doing in terms of defaults, etc.
Given we have consensus here (and thank you very much for reporting this and sticking with me throughout this brainstorming session) I am going to tag this appropriately. Feel free to submit the PR when and where you can.

Thanks all for your good work on this, which got us up and running with Ellucian Banner 9 SSO.  We upgraded our production CAS server yesterday to v5.1.3, then discovered that CAS authentication for our Banner 9 instance (not yet in production) failed due to the SAML ticket validation failure resulting from an invalid SAML assertion (i.e., because it was immediately expired).  As pointed out in this thread, CAS 4.x allowed for a 30 second interval for which the SAML assertion, so Banner 9 SSO worked with the older CAS.  CAS 5.1.x up through 5.1.3 allowed zero seconds, leaving Banner 9 SSO broken.
The good news is that, since you implemented the cas.samlCore.issueLength property in CAS v5.1.4, Banner 9 SSO works like a charm without our having to configure anything else.  Thank you!


⚠ DesiTorrents has degraded performance

In f57616a, DesiTorrents ($DST) experienced degraded performance:

HTTP code: 200
Response time: 6996 ms

Resolved: DesiTorrents performance has improved in 319c72f after 27 minutes.


Add set detection to the highlighting state machine

Set detection should be fairly straightforward by adding a branch in the state machine for the character #

The highlighting engine can't handle ambiguous characters that are only differentiable through their initial state.
The fact that sets and maps in clojure use the same character to denote the end of the structure, we can't
differentiate between them in later states of the highlighting state machine.
Whilst we can detect the beginning of a set quite accurately, the completion of one becomes a tad bit harder due
what we might encounter during the highlighting of its contents.
Example:
#{1, 2, 3}

We can detect the set fine after the #, but once we reach a number, which represents different state, we lose all information
about what the previous state was and thus don't know that the finishing curly brace pertains to a set and not to a map.

;(comment
;  Every state has:
;  1. Entry transition:
;    -> Tells me which state I should go in once I see a character
;  2. Consumption condition:
;    -> Tells me how to stay in that state. This should either be:
;      a. Explicit: Only stay here if you see the following chars in this order
;      b. Implicit: Stay here as long as your exit transition doesn't kick in
;  3. Exit transition:
;    -> Tells me how to conclude the state and when to emit
;  4. Container:
;    -> Tells me if it's a state that may go over other states until it completes its emission
;  )
;; Almost every state is "contextual"
;; It defines a context of consumption
;; Algorithm:
;; Given state stack s, emission accumulate acc
;; For next char c
;; Take top state s0 and look at what states it can transition to:
;; s1 = get (:transitions s0) c
;; if s1
;; then push s1 on s,
;;      push c on acc,
;;      recur
;; else
;;  completed = get (:completions s0) c
;;  if completed
;;  then push c on acc,
;;       emit acc,
;;       pop s0 from s,
;;       recur
;;  else push c on acc,
;;       recur


Bug: pnpm install 报错：postinstall:   x missing tasks in project

Version
Vben Admin V5
Describe the bug?
拉的最新版本，5.4.2，本地install后提示：
postinstall$ turbo run stub
. postinstall: turbo 2.2.1
. postinstall:   x missing tasks in project
. postinstall: Error:   x could not find task stub in project
. postinstall: Failed
 ELIFECYCLE  Command failed with exit code 1.
Reproduction
pnpm install
System Info
windows, node v20.16.0

Relevant log output
No response
Validations

[X] Read the docs
[X] Ensure the code is up to date. (Some issues have been fixed in the latest version)
[X] I have searched the existing issues and checked that my issue does not duplicate any existing issues.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

检查看看你的代码，是不是改了什么。看起来是你动了文件内容


codegen_level="min" and broadcasting with function arguments result in runtime instability check

Consider the following:
using DispatchDoctor: @stable

@stable default_codegen_level="min" function mymap!(f, y, x)
    for i in eachindex(y, x)
        y[i] = f(x[i])
    end
    return nothing
end

mymap! should be a fast, stable, and allocation-free function. Not so:
julia> using BenchmarkTools: @benchmark

julia> include("mymap.jl")

julia> @benchmark mymap!(identity, $(zeros(1000)), $(zeros(1000)))
BenchmarkTools.Trial: 10000 samples with 8 evaluations.
 Range (min … max):  3.670 μs …  24.436 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     4.278 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):   4.451 μs ± 885.102 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

  ▃▄▁▃█▇▄▇█▆▃▄▄▃               ▁                              ▂
  ███████████████▇▇▆▅▅▄▄▄▄▅▇██████▇▇▇▆▇▆▆▇██████▆▅▇▆▅▅▅▄▄▄▂▄▅ █
  3.67 μs      Histogram: log(frequency) by time      8.25 μs <

 Memory estimate: 1.27 KiB, allocs estimate: 16.

The allocations disappear and performance improves by a factor of 40 in either of the following conditions:

Removing @stable
Using default_codegen_level="debug"
Adding a type variable for f, as in function mymap!(f::F, y, x) where {F}

The culprit is likely that the generated mymap! implementation does not specialize on the type of f, since it's never called in mymap!'s body but only passed to other functions (specializing_typeof; mymap!_simulator`). Hence the stability check must be performed at runtime, leading to the observed performance and allocation penalty.

If the function argument is only used in a broadcasting expression, the problem persists when default_codegen_level="debug", since the broadcast syntax only lowers to various higher-order calls with no direct calls to f, so the explicit inlining of the function body due to "codegen_level="debug" doesn't help:
using DispatchDoctor: @stable

@stable default_codegen_level="debug" function mymap!(f, y, x)
    y .= f.(x)
    return y
end

julia> using BenchmarkTools: @benchmark

julia> include("mymap.jl")

julia> @benchmark mymap!(identity, $(zeros(1000)), $(zeros(1000)))
BenchmarkTools.Trial: 10000 samples with 7 evaluations.
 Range (min … max):  4.436 μs … 27.096 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     4.610 μs              ┊ GC (median):    0.00%
 Time  (mean ± σ):   5.052 μs ±  1.282 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

  ▆█▃▅▄▂▂▄▁         ▁                                        ▁
  ███████████▇▅▅▅▄▅████▇▆▆▇▇▇▇▆██▆▇▆▇▇▆▆▆▆▅▅▆▅▅▅▄▅▄▅▄▃▅▅▂▅▄▅ █
  4.44 μs      Histogram: log(frequency) by time       11 μs <

 Memory estimate: 1.41 KiB, allocs estimate: 20.

Once again, removing @stable or adding a type variable f::F fixes the problem. (The four extra allocations compared to the previous case remain if @stable is removed, as they are due to the dynamic dispatch incurred by the calls to the broadcasting machinery. They disappear when adding f::F, as they are ultimately caused by the same lack of specialization.)

I think this is a real issue, not the fault of DispatchDoctor, no? Julia does not specialize to functions unless you declare a type variable like f::F: https://docs.julialang.org/en/v1/manual/performance-tips/#Be-aware-of-when-Julia-avoids-specializing.

These will not specialize:
f_func(f, num) = ntuple(f, div(num, 2))
g_func(g::Function, num) = ntuple(g, div(num, 2))

but this will:
h_func(h::H, num) where {H} = ntuple(h, div(num, 2))

If it the function is getting inlined by the compiler, then performance will be saved (since it will know what f is), but otherwise, I think it's a real instability, and DispatchDoctor.jl is correct here. If you expect inlining to always be performed then you could add an @unstable to it?

The problem is the runtime instability check, tanking performance and adding allocations to a function that would otherwise be fast and allocation-free. It's not an instability; @code_warntype, DispatchDoctor, and every other mechanism agree that these functions are type stable.

Inlining can fix it, but you have to be explicit about it, the compiler doesn't inline even this tiny example by default:
@stable default_codegen_level="min" function mymap!(f, y, x)
    for i in eachindex(y, x)
        y[i] = f(x[i])
    end
    return y
end

f!(f::F, y, x) where {F} = mymap!(f, y, x)
g!(f::F, y, x) where {F} = @inline mymap!(f, y, x)

julia> @benchmark f!(identity, $(zeros(1000)), $(zeros(1000)))
BenchmarkTools.Trial: 10000 samples with 8 evaluations.
 Range (min … max):  3.325 μs … 53.729 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     3.999 μs              ┊ GC (median):    0.00%
 Time  (mean ± σ):   4.530 μs ±  1.657 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

  ▄▂▆▅█▆▇▄▂▂    ▁ ▁▁▁▁▁▁▁▁▁                                  ▂
  ██████████▇▇▇▇███████████████▇▇██▇▇▆▆▆▆▅▇▇▇▆▅▆▅▅▆▆▆▆▆▄▅▅▅▆ █
  3.33 μs      Histogram: log(frequency) by time     11.5 μs <

 Memory estimate: 1.27 KiB, allocs estimate: 16.

julia> @benchmark g!(identity, $(zeros(1000)), $(zeros(1000)))
BenchmarkTools.Trial: 10000 samples with 972 evaluations.
 Range (min … max):  74.403 ns … 186.966 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     76.914 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   82.468 ns ±  15.298 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

  █▃▅▆▅▁     ▂▂ ▁ ▁▁         ▁ ▁                               ▁
  ██████▇▆▄▃▅█████████▆▇▇██▇▆████▇▆▆▆▃▆▆▆▅▄▆▅▅▃▇▇▇▇▇▆▅▅▄▃▄▇▄▆▄ █
  74.4 ns       Histogram: log(frequency) by time       149 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

I still think this is a real type instability, it's just that it occurs outside the purview of the analysis tools. Basically, you are calling a function that is unknown to the compiler, so the return value of the function could be a Tuple{} (indicating it threw an error) or Nothing. But each time DispatchDoctor or @code_warntype are given a particular instance of a function f, they can validate that the return value is indeed Nothing.
At runtime, DispatchDoctor and @code_warntype are given the precise value of f – and therefore are able to eliminate the Tuple{}. But since the value of f isn't known to the compiler, it has to do runtime dispatch.

In the non-broadcasting case, the instability is caused by the extra layer of indirection that DispatchDoctor inserts when codegen_level="min". The function mymap! would otherwise specialize since f is called within it's body.
The broadcasting case is perhaps a bit more nuanced, but DispatchDoctor certainly adds a massive overhead due to the runtime stability check.

From the docs you linked: "Julia will always specialize when the argument is used within the method, but not if the argument is just passed through to another function."

On my machine, before adding the f::F to mymap!:
julia> @benchmark f!(identity, $(zeros(1000)), $(zeros(1000)))
BenchmarkTools.Trial: 10000 samples with 9 evaluations.
 Range (min … max):  2.088 μs …   7.153 μs  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     2.245 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):   2.276 μs ± 177.738 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

        █▇▅▇▁▁▂█▂▁▃  ▂  ▂
  ▁▁▁▁▂▄██████████████▇▇█▆▆▅▆▄▃▄▂▂▂▂▂▁▂▂▁▂▁▂▂▂▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁ ▃
  2.09 μs         Histogram: frequency by time        2.72 μs <

 Memory estimate: 1.27 KiB, allocs estimate: 16.

and after adding it:
julia> @benchmark f!(identity, $(zeros(1000)), $(zeros(1000)))
BenchmarkTools.Trial: 10000 samples with 943 evaluations.
 Range (min … max):  100.256 ns … 316.631 ns  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     112.583 ns               ┊ GC (median):    0.00%
 Time  (mean ± σ):   114.974 ns ±  20.494 ns  ┊ GC (mean ± σ):  0.00% ± 0.00%

    ▆▇█
  ▃▃████▄▃▂▂▂▂▂▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▂ ▃
  100 ns           Histogram: frequency by time          297 ns <

 Memory estimate: 0 bytes, allocs estimate: 0.

Yes. And if you remove both @stable and f::F, or remove just f::F and set codegen level to debug, those also look like the second case.

Oh I see what you mean. Yeah that's weird. Any idea why?

I think so... Even without f::F, the function does specialize if f is actually called within the body of the method. That happens in all these cases except the original one, with codegen level "min" and no f::F

I mean, I guess I wouldn't expect mymap!(f, x, y) = ... to be fast in the first place, due to the specialization rules. I feel like we are getting lucky that it's fast, but usually you would have to do the f::F where {F} trick to not incur runtime dispatch.
Sometimes the compiler is so smart it doesn't matter though. I guess on DispatchDoctor.jl's side it would be good to not get in the way of the compiler here though (hence this issue).
Also, the quote you noted above doesn't refer to function objects as far as I am aware (otherwise we wouldn't need to use f::F ever). But I'm still a bit confused about this (maybe I just need sleep). Note that @code_warntype is known to lie sometimes: https://github.com/JuliaLang/julia/issues/32834

Also, the quote you noted above doesn't refer to function objects as far as I am aware

The way I read that paragraph I think it does refer to function arguments, which is why I assume mymap!(f, y, x) to be reliably performant. The lack of specialization is relevant when mymap! only passes f through to another function, for example, mymap!(f, y, x) = myactualmap!(f, y, x), and that function is not inlined. This is effectively what's happening in the broadcasting example.

Very weird. That does make sense to me though, thanks for explaining it.
So I guess maybe Expr(:call, :map, :f, :x) doesn't count as "using" it whereas, e.g., Expr(:call, :f, :x) does? It feels like this shouldn't be true though, because sometimes functions are types... and the type might just get passed between functions rather than called explicitly. Weird indeed.
It does look like Julia is actually specializing here:
julia> function mymap!(f, y, x)
           for i in eachindex(y, x)
               y[i] = f(x[i])
           end
           return y
       end
mymap! (generic function with 1 method)

julia> Base.specializations(@which mymap!(identity, zeros(1000), zeros(1000)))
Base.MethodSpecializations(MethodInstance for mymap!(::typeof(identity), ::Vector{Float64}, ::Vector{Float64}))

(which doesn't lie, unlike @code_warntype).
Ok, so, I guess this is the issue? When using codegen_level="min", Julia thinks the function object is not "used" and therefore the function should not specialize to it.
So really what we need is a way to have the caller function have the exact same specializations as the simulator function...

One idea:
The first iteration of DispatchDoctor.jl used closures, like:
function f(a, b, c)
    closure() = $body
    Base.promote_op(closure) && ....
    return closure()
end

The problem with this is that due to https://github.com/JuliaLang/julia/issues/15276, if the closure modifies a, b, or c, you will create a type instability.
However, maybe the simulator function could just get stuck inside the main function, arguments and all. It's just tricky because we need to sanitize all arguments so there is no shared arguments between the main function and closure – it should be like
function f(a, b, c)
    function closure(_a, _b, _c)
        return ...
    end
    Base.promote_op(closure, type.((a, b, c))...)
    return closure(a, b, c)
end

which might work. But it would require extreme care with the arguments and also type parameters. Maybe doable...
We'd also need to verify that this actually eliminates the problems discussed in the issue, or maybe specialization of the closure wouldn't affect specialization of the wrapper, so we'd be back to square one.

Ok, so, I guess this is the issue?

Thinking a bit more, an ideal DispatchDoctor would never alter anything about specialization behavior or inlining, and never add extra runtime work. However, as a matter of priority, maybe the most important thing is to preserve inlining heuristics as much as possible? In practice, that might take care of the most common cases where this issue is encountered.

function f(a, b, c)
    function closure(_a, _b, _c)
        let (a, b, c) = (_a, _b, _c)
            $body
        end
    end
    type_instability(Base.promote_op(closure, type.((a, b, c))...)) && ...
    return closure(a, b, c)
end

I don't think it's necessary to generate new names here. closure only shares names with the outer function if they arent' defined locally through the argument list or an assignment, so reusing names is not a problem (other than for readability, but macro-generated code could be excused for lacking in that department).
Technically speaking, this isn't a closure, since it doesn't capture any variables. It's just a regular function whose name is only defined in a local scope.
However, I think I tried doing exactly this in a potential DispatchDoctor contribution that never went anywhere, and I think the problem was that the instability check could never be compiled away. Perhaps a world-age issue of some sort?

My first thought was to inject a type variable for every argument to the outer function that doesn't already have one, to force specialization there. That should solve static inference of the instability check, and as long as f_simulator preserves the original signature, the overall specialization behavior should be unchanged for codegen level "min". However, this would sometimes change specialization behavior for codegen level "debug".
Another idea is to factor out the instability check and error path into a separate function where specialization for every argument is always enforced. Perhaps this could increase the chance of having the stability check compiled away, and it might also reduce the effect of @stable on inlining heuristics since the net change is now only a single extra line in the method body (just spitballing here, I have no idea how the inlining heuristics actually work). I don't know how this would affect overall specialization behavior.
One thing that does not work is adding @inline to the simulator call site for codegen level "min". Somehow that makes everything worse.


update seata version

Describe what this PR does / why we need it
update seate version to 1.6.1 in 2021.x branch

Do you run the example module to verify the compatibility?

I got such a warning when installing dependencies
[WARNING] The POM for com.alibaba:druid:jar:1.2.6 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details
This should be an issue with druid, but it doesn't affect use. So I ignored the warning.

Do you run the example module to verify the compatibility?

Please wait a minute, I found the problem and I'm fixing it


fix(curriculum): minor indentation for readability

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Fixed minor indentation error noticed when doing tutorial
Before
function lookUpProfile(name, prop){
// Only change code below this line

// Only change code above this line
}

After
function lookUpProfile(name, prop) {
    // Only change code below this line

    // Only change code above this line
}

Congrats on your first pull request (PR)! 🎉
Thank you, for your contribution to the page! 👍
We are happy to accept these changes and look forward to future contributions. 📝


Catkin_make error

Hi,
I am installing visual studio code with ROS on Windows 10 machine.
Error:

catkin_make : The term 'catkin_make' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

I am new to the VS code. So, can you please suggest how to solve this error?

Hi,
sorry for the late response. Somehow I wasn't notified about the issue and I'm not that often on github :)
The catkin_make command is part of the ROS build system. You would need to follow the ROS installation steps first.
I tested this repo with a Ubuntu system.
You would first need to instlal ROS:
http://wiki.ros.org/Installation/Ubuntu
and then setup the workspace for the catkin build system:
http://wiki.ros.org/catkin/Tutorials/create_a_workspace
But it's been a while since I worked with ROS, so maybe I'm forgetting a thing or two. Hope this helps.

Closing due to inactivity. A section on installing ros was added to the readme


Split project into separate app, config, lib and tasks packages

This PR implements:

https://github.com/alphagov/govuk-frontend/issues/2886

Where each package directory is set up with:

Separate package.json to manage dependencies
Separate tsconfig.json for type checking "squiggles" including tests
Separate npm workspace, e.g. import { npm } from 'govuk-frontend-tasks'

Before
Everything at project level
├── app
│   ├── src
│   └── dist
├── bin
├── config
├── dist
├── docs
├── lib
├── package
├── src
└── tasks

After
Some dependencies (app, config, lib, tasks) moved to ./packages
├── bin
├── dist
├── docs
├── package
├── packages
│   ├── app
│   │   ├── src
│   │   └── dist
│   ├── examples
│   │   └── webpack
│   │       ├── src
│   │       └── dist
│   └── shared
│       ├── config
│       ├── lib
│       └── tasks
└── src

Maybe
All dependencies including govuk-frontend moved to ./packages
├── bin
├── docs
└── packages
    ├── app
    │   ├── src
    │   └── dist
    ├── examples
    │   └── webpack
    │       ├── src
    │       └── dist
    ├── frontend
    │   ├── src
    │   └── dist
    └── shared
        ├── config
        ├── lib
        └── tasks

It would be useful to add some light commentary on why moving to this folder structure would be useful, but we can merge it once that has been added and the other squad has been notified.

@stevenjmesser It's largely to make GOV.UK Frontend easier to contribute to, but also lets us use govuk-frontend (the npm package) internally in the same way our users do to catch issues sooner
This particular PR splits up the project into bite size easier-to-digest pieces
Until recently our review app has has tapped into govuk-frontend in ways our users can't (avoiding bugs we've missed) but we're slowly taking steps to resolve this via:

https://github.com/alphagov/govuk-frontend/issues/2886

Some recent work has included: https://github.com/alphagov/govuk-frontend/pull/3050, https://github.com/alphagov/govuk-frontend/pull/3223, https://github.com/alphagov/govuk-frontend/pull/3370, https://github.com/alphagov/govuk-frontend/pull/3383, https://github.com/alphagov/govuk-frontend/pull/3384

I agree with the overall goal, but could we achieve the same result whilst keeping app, examples, shared, src at the root level?
Are there benefits to moving everything under the packages folder, other than it being a convention for (some?) node packages?
I think the main reason I dislike putting everything under packages is that:

having 2 folders with the names package and packages seems confusing
calling them 'packages' may imply that we publish each of the folders underneath it to npm

I'd generally like to keep it easy to find the 'source code' for GOV.UK Frontend and try and keep the tooling out of the way, so would be hesitant to move everything into packages.

@36degrees Yeah it'd be exactly the same at root level
The directory structure is up for discussion, we can keep ours as it is
I've only suggested ./packages since it's the npm workspaces default which we see a lot in tools:
dequelabs/axe-core-npm/packages
babel/babel/packages
cssnano/cssnano/packages
eslint/eslint/packages
facebook/jest/packages
webdriverio/webdriverio/packages
Although perhaps not as far as exporting individual packages via workspaces:
coopdigital/coop-frontend/packages
material-components/material-components-web/packages
uswds/uswds/packages
Would be good to document if ./package or ./dist are needed in source control

I've split this PR into separate commits with the directory structure changes last
With each package having a separate package.json, tsconfig.json and npm workspace we can move packages anywhere and JSDoc-powered code autocomplete will continue to work
Before
import { paths } from '../../../../../config/index.js'

After
import { paths } from 'govuk-frontend-config'

Move to workspace makes imports so much tidier without the ../../... Splitting helpers and lib is also a nice way to distinguish what's build/test code and what's not 🙌🏻  Two little things for me:

As I've mentioned in this comment, I think index.js files just add more steps for using the lib and helpers. They're one extra file to maintain and lead to extra destructuring to access the actual functions. I'd prefer we use your proposition for named package exports, @colinrotherham, as it both clarifies where the code lies (for people that may not be looking at it in an IDE with shortcuts to move around) and simplifies the access to the function.
I'm not sure of the benefits of moving things into shared. We don't have that much complexity in the folders of the project that our root directory is crowded. Having everything at the root of the repository makes it easier to have a view of what's in the repository.

Documentation wise, would it be worth having a little README file in each workspace to complement the docs/application-architecture.md with a quick description of what we want to set in each package?

@romaricpascal Brill, I'll add those named entries
Do you want READMEs as a blocker for this PR or something we can improve later?
Using shared came from @36degrees in https://github.com/alphagov/govuk-frontend/pull/3399#issuecomment-1494118320 instead of npm workspaces packages:

https://github.com/alphagov/govuk-frontend/pull/3490

I wasn't super strongly against shared so happy to keep it and save moving more code around.
We can add READMEs later, I think, but a line in application-architecture.md to describe shared and more importantly shared/helpers would be good for that PR (had missed that it was missing looking at things commit by commit 😬 ).

@romaricpascal I've added commit https://github.com/alphagov/govuk-frontend/commit/6304ca1cb378bc3650663618e6fc058ce36363cd for subpath package exports
Let me know if you're happy with the application-architecture.md edits
Thanks 😊


Getting data from latent z-space

Hello,
I have run "scvae train" and "scvae evaluate" on a dataset. Evaluation returned many .png images, including the plot of the latent z-space, but I am interested in getting the actual points in the latent z-space (i.e. in a tsv/csv file). How can I get this data?
Thank you

I will add a way to do this in the next version.


Which version of windows works

Hello
First of all, excellent project friend, I have been using yowsup for some time and I found out that your project existed and I want to try it.
My question is, what version of Windows works? I have Windows 10 and the truth is giving me many errors, I have installed the Node 8, python 2.7.15 64 bits.
The error that most presents is:

gcc exited with status 1

Thank you.

The Windows support merely originated from #22 a few weeks ago, as I don't use Windows myself. Do you use npm run win to launch it? Or is there some other meaningful gcc error output?


remove annotations

Also, is there a way to query for the status of all of the downloads in a batch?

Good call on the query batch by status. Ill work on that feature.


Placement conn fix

This  PR addresses daprd not being able to connect to placement on k8s after placement leader failover.

Is there an integration test we can add for this?

Is there an integration test we can add for this?
Unfortunately, the issue is only reproducible on k8s so an integration test wouldn't have helped here.
As @artursouza suggested, we should probably start thinking about investing in chaos testing.


PI: Fix Winlogs to show Debugoutput when the user has enabled it and changed targetapp.

Summary of the pull request
DebugOutput were not captured when the user changed the targetapp since we had disabled them at Start by default.
Fixed this by passing the enabled/disabled state for all the log helpers when we start winlogs for the new target app.
Also, changed all helpers to add log entry using Application.Current.GetService.AddNewEntry. This helps in not having 2 copies of Observablecollection object and having to pass it around. Did the same for Watson page.
Also, added an ObservableCollectionExtensions Add method, which ensures that the Winlogs will be sorted based on their time of generation.
Validation steps performed

launch PI
Go to winlogs page
enable Debugoutput
change target app
Verified that debugout is visible
Also, all logs are in ascending order.

PR checklist

[ ] Closes #3245

Prefer using UTCNow internally and converting to the date and time of the current culture.  This can help to avoid weird timing errors during DST or moving between Time Zones.

Could you provide videos of the before and after so we can see what the change looks like?

Abandoning this PR


VTK data for turbines randomly not well saved when using FAST.Farm

Bug description
When running FAST.Farm simulations with several turbines, I try to save the VTK vizualisation animation data for turbines. However, some of those files are randomly bad saved, here "randomly" means:

For the same turbine, it can be the blade not saved at one time step, and then the tower not saved at another time step.
At the same time step, it can be the nacelle not saved for one turbine, and the blade surface not saved for another turbine.

This problem exists at least in OpenFAST v3.3.0, v3.4.1 (other versions not tested)
To Reproduce
Steps to reproduce the behavior:

Run a FAST.Farm case with more than 9 turbines with "OPENMP on", I provide a demo case here based on OpenFAST v3.3.0.
Save the VTK animation data for turbines

Expected behavior
You will see that:

some files are empty (no data saved at all)
some files are partially saved (only part of data is saved, file size smaller than other regular files)
some files are over saved (file size larger than other regular files)

Screenshots, if applicable
The file TSinflow.T1.TowerSurface.0502.vtp is empty here

The file TSinflow.T1.Blade3Surface.0574.vtp is only saved partially (only head info is saved in this case)

The file TSinflow.T1.TowerSurface.0176.vtp is over saved (probably it write two tower surfaces in this file)

OpenFAST Version
 **************************************************************************************************
 FAST.Farm
[demo.zip](https://github.com/OpenFAST/openfast/files/11627441/demo.zip)

 Copyright (C) 2023 National Renewable Energy Laboratory
 Copyright (C) 2023 Envision Energy USA LTD

 This program is licensed under Apache License Version 2.0 and comes with ABSOLUTELY NO WARRANTY.
 See the "LICENSE" file distributed with this software for details.
 **************************************************************************************************

 FAST.Farm-v3.3.0-dirty
 Compile Info:
  - Compiler: GCC version 8.4.0
  - Architecture: 64 bit
  - Precision: double
  - OpenMP: Yes, number of threads: 32/32
  - Date: Jan  5 2023
  - Time: 06:28:31

System Information (please complete the following information):

OS: RedHat 7, centos
Compiler: gcc 8.3.0 or 8.4.0
OPENMPI: 4.0.3 or 4.0.5
OPENMP: on

Additional context

demo.zip


Minifier should inline property assignments into an object literal (in reverse direction)

Describe the feature

swc vs terser
Babel plugin or link to the feature description
No response
Additional context
No response

Closing as stale


Description formatting for pre-packaged constraints (example for #195)

That could make sense.  Here's an attempt at it: the formatting should give either a KeyError (keyword not found, in which case the user may well have been trying to use the formatting) or ValueError (for parsing).

Do you want to leave this PR as a draft, or is it ready to merge?

Actually, some things should probably change, for example adding this feature to other functions that create constraints.

Yes, this isn't done yet, I need to do the same thing elsewhere, and add some tests.

Yes, this isn't done yet, I need to do the same thing elsewhere, and add some tests.

Maybe merge the current dev into this branch. I've just added two new functions (described in https://github.com/UC-Davis-molecular-computing/nuad/issues/191#issuecomment-1177958182) that would also have their description fields altered. (Or in this case, descriptions)


tour: [REPLACE WITH SHORT DESCRIPTION]

Context: https://tour.golang.org/flowcontrol/8
Change the title above to describe your issue and add your feedback here, including code if necessary
package main
import (
"fmt"
)
func Sqrt(x float64) float64 {
}
func main() {
fmt.Println(Sqrt(2))
}

Not an issue, closing.


Add support for auto precision in 'number' template

The 'auto' precision option is not working as expected when using the 'number' template. It would be great if the 'number' template could support the 'auto' precision mode similar to how it works with the 'usd' template, just without the '$' sign. This would provide more flexibility and consistency in number formatting across different templates.

We've fixed the 'auto' precision in the 'number' template in v1.3


fix: Ruff v0.5.0 linting errors

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.87%. Comparing base (b51094e) to head (efc925a).
Report is 30 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##            master     #154      +/-   ##
===========================================
- Coverage   100.00%   99.87%   -0.13%
===========================================
  Files           56       56
  Lines         2452     2416      -36
===========================================
- Hits          2452     2413      -39
- Misses           0        3       +3

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


remove user   problem

Delete users can also log in

Need to restart service
systemctl restart<EMAIL_ADDRESS>

Duplicate of #764


python310Packages.miniaudio: 1.51 -> 1.52

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.miniaudio is: "Python bindings for the miniaudio library and its decoders"
meta.homepage for python310Packages.miniaudio is: "https://github.com/irmen/pyminiaudio"
meta.changelog for python310Packages.miniaudio is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 1.52 with grep in /nix/store/hk6h43z27v70m5lfv1l0c3cy21gh68zy-python3.10-miniaudio-1.52
found 1.52 in filename of file in /nix/store/hk6h43z27v70m5lfv1l0c3cy21gh68zy-python3.10-miniaudio-1.52

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

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath
home-assistant-component-tests.apple_tv
python310Packages.miniaudio
python310Packages.pyatv
python39Packages.miniaudio
python39Packages.pyatv

Instructions to test this update (click to expand)

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

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

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/hk6h43z27v70m5lfv1l0c3cy21gh68zy-python3.10-miniaudio-1.52
ls -la /nix/store/hk6h43z27v70m5lfv1l0c3cy21gh68zy-python3.10-miniaudio-1.52/bin

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

5 packages built:

home-assistant-component-tests.apple_tv
python310Packages.miniaudio
python310Packages.pyatv
python39Packages.miniaudio
python39Packages.pyatv

Maintainer pings
cc @dotlambda for testing.

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

1 package failed to build:

python39Packages.pyatv

4 packages built:

home-assistant-component-tests.apple_tv
python310Packages.miniaudio
python310Packages.pyatv
python39Packages.miniaudio

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

5 packages built:

home-assistant-component-tests.apple_tv
python310Packages.miniaudio
python310Packages.pyatv
python39Packages.miniaudio
python39Packages.pyatv


chore: add javadoc, maven-central, release, gitter badges

I can't find redis-watcher in javadoc.io and maven-central. But if they are uploaded, the badges will automatically update.

@hsluoyz I add secrets for semantic-release and codecov, and use OSSRH_USERNAME and OSSRH_PASSWORD in organization secrets. Please review and merge pr to build.


Allow lintable JSON output

As mentioned in #12, when passing the output of jsome(...) into a utility which expects validate JSON (for example, jq) or a JSON linter, errors are thrown as keys are expected to bring wrapped in double quotes as per the JSON spec (members have pairs; pairs have strings on the left size of : and strings have " around them).
This adds quotes is jsome.params.lintable is set to true, and added a cli option for the cli util.

Thanks for the PR.
Let's make the repo alive again


TXT record escape character

TXT records content are being created with the following : "\"blabla"\"  when now only "blabla" is needed as I believe this might have been a bug fixed by terraform

Same behavior here.

See this :
https://github.com/hashicorp/terraform/issues/8423

I'm not familiar with this project or ruby, but it does seem that the resource record value is obtained directly from the ruby aws sdk, which does include \"\".

Thank you for reporting, and sorry for late review.
Could you tell me the below?

how to reproduce
expected value and actual value

How to reproduce
terraforming r53r
Expected value
resource "aws_route53_record" "example-com-TXT" {
    zone_id = "REDACTED"
    name    = "example.com"
    type    = "TXT"
    records = ["AAAAAA", "BBBBBB"]
    ttl     = "28800"

}

Actual value
resource "aws_route53_record" "example-com-TXT" {
    zone_id = "REDACTED"
    name    = "example.com"
    type    = "TXT"
    records = ["\"AAAAAA\"", "\"BBBBBB\""]
    ttl     = "28800"

}


Renaming on the main page becomes effective after closing and reopening Altme

Description: I did a complete reset of my Altme wallet. Afterward, I imported a Tezos account with PK and accepted T&C. I renamed the imported account to "DL Ventures" using the down arrow on the top right. The change did not become effective once I returned to the landing screen. However, when clicking the down arrow again, the account was renamed to "DL Ventures". After closing and reopening the app (completely closed it), the account was renamed to "DL Ventures" also on the main screen of Altme.
Desired Behaviour: It would be great if the change directly becomes visible on the main screen.

This is the main page in my description:

@hawkbee1 can you open a ticket for this ?

Same as #2623 ?

done in 2.8.3


FBC pipeline config update

Description
FBC pipeline run only when FBC related file changes. Avoid excessive runs that produce the same FBC image.
Remove deprecated BASE_IMAGES_DIGESTS argument and upgrade buildah task image.
Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[x] Configuration Update
[ ] Bump-up dependent library

Related Tickets & Documents

Related Issue #
Closes #

Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] PR has passed all pre-merge test jobs.
[ ] If it is a core feature, I have added thorough tests.

Testing

Please provide detailed steps to perform tests related to this code change.
How were the fix/results from this change verified? Please provide relevant screenshots or results.

/lgtm

test should pass after merging this fix in dockerfile https://github.com/openshift/lightspeed-operator/pull/289

/retest

/approve

/override "Red Hat Konflux / fbc-v4-16-on-pull-request"
/override "Red Hat Konflux / fbc-v4-15-on-pull-request"

docker file fix is merged now.


Bug(ccf-rui): Organ input should accept an iri

Expected
It should be possible to pass an iri as the organ, ex:

http://purl.org/ccf/latest/ccf.owl#VHFRightPalatineTonsil
https://purl.humanatlas.io/ref-organ/palatine-tonsil-female-right/v1.1#primary

Actual
No organ is selected
Cause
The comparison between the entity label and organ name in reference-data.state.ts:181 is case sensitive preventing the correct organ from matching.

We already have support for them selecting by ontologyId (the uberon term for kidney for instance) plus sex and side. Doesn't that still work? See https://github.com/hubmapconsortium/hra-ui/blob/develop/apps/ccf-rui/src/app/core/store/model/model.state.ts#L531 . If it doesn't work, we need to fix it.
I'm hesitant to have people set the reference organ IRIs as they change fairly frequently and would require them to use string manipulation to create if they were trying to change sex / side. One case where it might make sense is when editing existing registrations, BUT the RUI should automatically switch to the right organ anyway (if not, that's a bug).


Support of Other AWS CodeBuild Containers

Describe the Feature
AWS Code Build supports multiple "Environment Types" as listed on the AWS API Documentation under Project Environment
From this we can find that the valid values are:
WINDOWS_CONTAINER | LINUX_CONTAINER | LINUX_GPU_CONTAINER | ARM_CONTAINER
Additionally the Terraform aws_codebuild_project exposes the ability for this value to be set as well, albeit in the example they have it set to one of the valid types.
I would propose that this element be exposed in the cloudposse terraform-aws-codebuild as:
build_environment_type
Expected Behavior
When this new element is set it will impact the AWS CodeBuild Environment type.
Use Case
Will enable the ability to have AWS CodeBuild to run as:

WINDOWS
LINUX
LINUX_GPU
ARM

Describe Ideal Solution
The module supports setting build_environment_type or exposes this via some other similar element name.
Alternatives Considered
The ability to run builds that require windows specific features (i.e. PowerShell) are not supported using the CloudPosse version of Terraform AWS CodeBuild module.

Happy to submit a PR to attempt to add this, sorry if missed where to request to make a PR or failing to follow any other process.
Big fan of the work CloudPosse is doing.

Hi bnippercg,
I've added build_environment_typesupport. It also adds many other lacking features such as private repository authorization, git clone depth secret manager access.
You may find it at my fork which is waiting to be reviewed.
https://github.com/brcnblc/terraform-aws-codebuild


Allow custom model when given by the user.

The user can provide a custom pytorch model.
Avoid repeating code on a few places.

This looks very reasonable. Any plans to merge this request, @SJ001 ?


CI for Node

Added workflow node.js.yml CI for Node

› 1 snapshot failed.
Snapshot Summary
› 1 snapshot failed from 1 test suite. Inspect your code changes or run npm test -- -u to update them.
Test Suites: 1 failed, 1 total
Tests:       4 failed, 7 passed, 11 total
Snapshots:   1 failed, 1 total
Time:        0.807 s
Ran all test suites.
npm ERR! Test failed.  See above for more details.
Error: Process completed with exit code 1.


Fix typo in query projection example

Merged to v1.0 in https://github.com/mongodb/mongo-php-library/commit/214b08888be3015ba5164e1375f453caff2de97d. Thanks!


fix: renovate process on fork

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


Enable weighted fitting for both single and multi eval tree

@mjohnson541 Thanks, done

@mjohnson541 I have rebased, please review and merge!


Clang complains about precision loss in trace.hpp when using -Wshorten-64-to-32

When attempting to use complete_trace with clang version 18.1.8 and -Wshorten-64-to-32 option:
/usr/include/tao/pegtl/contrib/trace.hpp:87:34: fatal error: implicit conversion loses integer precision: 'std::size_t' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
   87 |          std::cerr << std::setw( indent() ) << ' ' << TracerTraits::ansi_position << "position" << TracerTraits::ansi_reset << ' ' << m_position << '\n';
      |                       ~~~        ^~~~~~~~

Quick fix is in 3.2.8, fixes for the main and work branches will follow soon.


fix build scope in docfx.json

@TianqiZhang @dend

@herohua,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot


Bad syntax in expression causes index out of bounds exception

For example, trying to parse:
h1 #{variable'}

Throws index out of bounds exception.
Fixed by #5

Just release 2.0.0-alpha4. I ported some of the error handling from pug.js over to java. You should now have some nicer error output. Don't mind that I don't need to merge your PR anymore.

Awesome! thanks.


MODEXPW-509 - Support Eureka permissions model for bulk operations (read operations)

MODEXPW-509 - Support Eureka permissions model for bulk operations (read operations)
Purpose

Implement logic to support permissions from mod-roles-keycloak and integrate it in existing approach.
Approach

Introduce an environment variable in the module configuration that will be specifically depend to the environment to switch logic between mod-permissions and mod-roles-keycloak.
TODOS and Open Questions

Learning

Pre-Merge Checklist:
Before merging this PR, please go through the following list and take appropriate actions.

Does this PR meet or exceed the expected quality standards?

[x] Code coverage on new code is 80% or greater
[x] Duplications on new code is 3% or less
[x] Check logging
[ ] There are no major code smells or security issues

Does this introduce breaking changes?

[ ] Were any API paths or methods changed, added or removed?
[ ] Were there any schema changes?
[ ] Did any of the interface versions change?
[ ] Were permissions changed, added, or removed?
[ ] Are there new interface dependencies?
[x] There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

What other modules will these changes impact?
Do JIRAs exist to update the impacted modules?

[ ] If not, please create them
[ ] Do they contain the appropriate level of detail?  Which endpoints/schemas changed, etc.
[ ] Do they have all they appropriate links to blocked/related issues?

Are the JIRAs under active development?

[ ] If not, contact the project's PO and make sure they're aware of the urgency.

Do PRs exist for these changes?

[ ] If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment.  Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.
While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

Hi @khandramai please take a look.

Hi @khandramai please take a look on updates.

LGTM, go ahead. Thanks.


Activity mode like in KDE

KDE has workspaces (seperate desktops) but this is already supported.
It also has an "activity", which is essentially a whole new set of desktops/workspaces. This is useful because it allowws one to seperate work and gaming/miscellaneous things and have windows and programs open in seperate activities without interfering with one another.
Would it be possible to add? Clicking a button combo (like Meta + Tab) will switch activities and give access to a whole new set of empty workspaces to be able to seperate workflows in this way?

do you mean something like this?
don't forget to add another entry in actvities in hyprkool.toml

yes. i know what kde activities are.
hyprkool activities are a group of workspaces. kinda like kde activities.
look at this video https://youtu.be/tim5r6Yo6TA
the buttons on the top bar show both hyprkool activities and workspaces on that activity

closing this as it's not clear what the issue is.


Add button color, return URL and billing details to JS and iOS #1

Adds button color, return URL and billing details in JS and iOS, Android will come later once we have a snapshot of the GA candidate
This is going into a feature branch in my fork, then eventually into master. For now I don't have permissions to the react native repo.
TODO: Android stuff, allowsDelayedPaymentMethods

CI is gonna fail since it can't pull in our internal pods.

@yuki-stripe correct, once iOS and Android GA I'll throw up a quick change pointing to the latest versions, then we'll publish the RN package!
Merging this into a feature branch for now...


Add vtysh.conf file to image

Add vtysh.conf file to image
Signed-off-by: Michael Cambria<EMAIL_ADDRESS>

/lgtm

/approve