feat: "dependsOn" for release dependencies

I know Helmfile can already do release dependencies by ordering releases manually via naming conventions for helmfiles or limiting concurrency.
Ability to explicitly declare dependencies would be a major step towards making Helmfile more declarative.
My initial idea was to base it on release names like so:
releases:

- name: prometheus
  dependsOn: ["nginx-ingress"]
  chart: stable/prometheus
  values: []

- name: nginx-ingress
  chart: stable/nginx-ingress
  values: []

It would be even nicer to base it on release labels:
releases:

- name: prometheus
  dependsOn:
    group: core
  namespace: prometheus
  chart: stable/prometheus
  values: []

- name: nginx-ingress
  labels:
    group: core
  chart: stable/nginx-ingress
  values: []

@ilyasotkov Thx!
Just curious but how do you like helmfile to process dependsOn across helmfiles? Are you ok if it works only within each helmfile?

@mumoshu It would be ideal if Helmfile would merge everything into a single Helmfile and then resolve dependencies.

Interesting idea! But doesn't it defeat the purpose of helmfiles:? Are you referring to bases: then?

Somewhat similar to bases: but it would also merge the list of releases: across helmfiles and then run all in parallel if there's no dependsOn but resolve dependencies between releases if there is.
The feature is definitely a major one and I don't know if implementing it in a backwards-compatible manner is even possible.
When running helmfile -l label=value sync the default behavior could be to only resolve dependecies that match label=value, or resolve all dependencies regardless of label if we add a flag like --resolve-all-deps.

Thanks! Much appreciated.

all dependencies regardless of label if we add a flag like --resolve-all-deps.

Just curious but why and when you need this?

Merging releases should be possible. Actually we have a dedicated issue for that #684

But doesn't it defeat the purpose of helmfiles: where each sub-helmfile can be run independently?

It could still work quite cleanly when running independent helmfiles:
# helmfile1.yaml
releases:
- name: my-release
  dependsOn:
    group: core
  chart: ./charts/app

# helmfile2.yaml
releases:
- name: my-core-app
  labels:
    group: core
  chart: ./charts/app

If we run only helmfile1.yaml, we could give a warning that no dependencies were found matching group=core label.

Just curious but why and when you need this?

The idea comes from Terragrunt's apply-all when run on a sub-directory of live.
It could be useful if you have a massive helmfile.d and want to deploy only a single release that depends on many other releases but you don't want to think about dependencies (which could be a long chain).

@ilyasotkov Interesting! So you leave users the responsibility to label releases consistently across all the involved helmfiles?
In case the user had mistakenly added the same label to two different releases in separate helmfiles, maybe they have no easy way to notice that?

It could be useful if you have a massive helmfile.d and want to deploy only a single release that depends on many other releases but you don't want to think about dependencies (which could be a long chain).

Still trying to understand - How is it different from running helmfile -f helmfile.d/ without selectors?

Still trying to understand - How is it different from running helmfile -f helmfile.d/ without selectors?

If we have a massive helmfile.d where one file would be:
releases:
- name: my-app
  labels:
     app: my-app
  dependsOn:
    app: ["storage", "ingress"]
  chart: ./charts/app

Running helmfile -f helmfile.d/ would deploy 1000 releases.
Running helmfile -l app=my-app would deploy only that application and would warn about unresolved dependencies for labels app: ["storage", "ingress"].
Running helmfile -l app=my-app --resolve-all-deps would deploy all releases matching app=ingress and app=storage, then deploy app=my-app.

So you leave users the responsibility to label releases consistently across all the involved helmfiles?

I think that if a user is syncing a collection of helmfiles, it's totally the user's responsibility to make sure he knows what that collection contains. That includes knowing how each release in the collection is labelled.

@mumoshu Regarding possible implementation, this type of functionality would almost certainly require building a DAG and topologically sorting the list of releases to deploy. Circular dependencies would lead to critical failure.

Running helmfile -l app=my-app would deploy only that application and would warn about unresolved dependencies for labels app: ["storage", "ingress"].
Running helmfile -l app=my-app --resolve-all-deps would deploy all releases matching app=ingress and app=storage, then deploy app=my-app.

I see!
I'd prefer helmfile -l app=myapp "fails" due to unresolved dependencies, while helmfile -l app=myapp --resolve-all-deps and helmfile -l app=myapp -l app=ingress -l app=storage succeeds.
But I agree with the necessity of --resolve-all-deps.

I think that if a user is syncing a collection of helmfiles, it's totally the user's responsibility to make sure he knows what that collection contains. That includes knowing how each release in the collection is labelled.

I imagine I would get a lot of support tickets from users due to that :) But I have no better idea.

I'd prefer helmfile -l app=myapp "fails" due to unresolved dependencies

I meant that Helmfile would give a warning that it didn't try to resolve dependencies (because no --resolve-all-deps was specified) and the release would probably fail but could also succeed if the dependencies were deployed earlier.

In case the user had mistakenly added the same label to two different releases in separate helmfiles
I imagine I would get a lot of support tickets from users due to that :) But I have no better idea.

Not sure I understand, what would be the harm (besides the surprise factor)? If a user accidentally adds a label to a random application, then adds a dependsOn for that label to some other release declaration, then both the intended dependency and the random application would get deployed. It's not such a bad a thing unless the random application includes some other unintended changes.
And it's not all that different from accidentally adding a label in the current version of Helmfile and wondering why 2 applications were deployed instead of 1 :)

And it's not all that different from accidentally adding a label in the current version of Helmfile and wondering why 2 applications were deployed instead of 1 :)

Good point. True 😄

I meant that Helmfile would give a warning that it didn't try to resolve dependencies

If we were to allow that behavior, I'd prefer requiring an explicit flag for it like --allow-unresolved-deps. So in overall we may have:

Running helmfile -l app=my-app would fail due to unresolved dependencies for labels app: ["storage", "ingress"].
Running helmfile -l app=my-app --allow-unresolved-deps would warn about unresolved dependencies for labels app: ["storage", "ingress"].
Running helmfile -l app=my-app --resolve-all-deps would deploy all releases matching app=ingress and app=storage, then deploy app=my-app.

@mumoshu Regarding possible implementation, this type of functionality would almost certainly require building a DAG and topologically sorting the list of releases to deploy. Circular dependencies would lead to critical failure.

@ilyasotkov Noted. Thanks!
I am to work on this after #688 and #684 because dependsOn would work with bases, not helmfiles. I'd appreciate it if you could also comment on those issues, too.
I'll give you an example usage of this feature based on what we've discussed so far.
Any feedback is welcomed 😃
Let's start by creating your helmfile.yaml:
bases:
- path: logging.yaml
   inheritValues: true
- path: telemetry.yaml
  inheritValues: true
- path: servicemesh.yaml
  inheritValues: true

releases:
- name: mymainapp
  dependsOn:
  - servicemesh

logging.yaml:
releases:
- name: filebeat
   labels:
    group: logging
    env: prod
  values:
  - filebeat.prod.values.yaml
- name: filebeat
   labels:
    group: logging
    env: preview

telemetry.yaml:
releases:
- name: prometheus
  labels:
    group: telemetry
    env: prod
- name: prometheus
  labels:
    group: telemetry
    env: preview

servicemesh.yaml:
releases:
- name: istio
  labels:
    group: servicemesh
    env: prod
  dependsOn:
  - telemetry
- name: istio
  labels:
    group: servicemesh
    env: preview
  dependsOn:
  - telemetry

Now let's run helmfile:

helmfile env=preview would deploy everything including mymainapp, istio, prometheus, filebeat whose env is preview.
helmfile -l name=mymainapp,env=preview would fail due to missing dependency(istio
helmfile -l name=mymainapp,env=preview --allow-unresolved-deps would install mymainapp while warning about missing dependency(istio
helmfile -l name=myapp,env=preview --resolve-all-deps would deploy mymainapp, its dependency istio and the transitive dependency prometheus.

How do we filter istio and prometheus? Ideally, onlyenv=preview in -l name=myapp,env=preview should be used for filtering istio and prometheus. But it seems a bit confusing.

This isn't how the selector works today, but I'm considering to extend -l to be a OR operation when two or more of them are provided. Then:

 helmfile -l name=myapp,env=preview -l servicemesh,env=preview -l telemetry,env=preview would deploy mymainapp, istio, and prometheus for env=preview without errors. Here you resolved all the deps manually.

Alternatively you can just put the same label to all the releases involved in a deployment scenario so that:

helmfile -o deploy-myapp-and-deps=true would deploy myapp istio telemetry assuming these 3 releases has deploy-myapp-and-deps=true.

@ilyasotkov Please see above ⬆ I'm not sure how --resolve-all-deps should work when you've provided two or more kvs in a selector.

I'd prefer helmfile -l app=myapp "fails" due to unresolved dependencies, while helmfile -l app=myapp --resolve-all-deps and helmfile -l app=myapp -l app=ingress -l app=storage succeeds.

I think that's a good alternative 👍

Let's start by creating your helmfile.yaml

In your example dependsOn: is a list of strings. Is your suggestion to refer to bases, not labels (with .yaml suffix removed)? Or are you implicitly referring to group labels?

helmfile env=preview mwould deploy everything including mymainapp, istio, prometheus, filebeat whose env is preview.

How so? 🤔 In your example mymainapp is doesn't have env=preview label.

This isn't how the selector works today, but I'm considering to extend -l to be a OR operation when two or more of them are provided. helmfile -l name=myapp,env=preview -l servicemesh,env=preview -l telemetry,env=preview would deploy mymainapp, istio, and prometheus for env=preview without errors. Here you resolved all the deps manually.

This part is super confusing to me 😕 As a new user I'd assume

-l key=value -l key2=value2 and
l key=value,key2=value2

are the same thing.

helmfile -o deploy-myapp-and-deps=true would deploy myapp istio telemetry assuming these 3 releases has deploy-myapp-and-deps=true.

That part makes sense.

@mumoshu Maybe it's best to keep it simple and have dependsOn as a list of strings where each string must refer to a valid Helm release (must keep in mind that in Helm 3 releases are namespaced).
releases:

- name: myapp
  dependsOn:
  - release: prometheus
    namespace: telemetry

- name: prometheus
  namespace: telemetry

dependsOn would be allowed

within the same helmfile OR
in one of the bases

Implementation details:

Parse all available releases: (after merging in all of the bases:). Each Helm release is a DAG vertex/node.
Parse dependsOn for all available releases, validate that they can be found from the available releases. If not found, only proceed if --allow-unresolved-deps flag is specified).
Add each valid dependsOn item as a directed edge in the DAG.
Topologically sort the DAG, end up with a two-dimensional array.
Loop over the resulting array, deploying all items of the inner arrays (Helm releases) in parallel.

That way, it would be

Easier for users to understand how dependencies are meant to work.
Easier to implement: if a users specifies a --selector, dependencies not matching the selector are ignored, unless --resolve-all-deps flag is specified.

@ilyasotkov Thanks for the suggestion! It looks feasible. But on the other hand it blurs the whole purpose of this feature to me.
If it works only within a single helmfile, why you need this?
Can't you just split your helmfile to two or more and order them under helmfiles:, cuz helmfiles: is a declarative way to order groups of helmfiles.
Or is it just that you want a simpler(or a more declarative - you feel so?) way than that?

have dependsOn as a list of references to Helm releases (not labels). In Helm 3 releases are namespaced, so namespace should be part of the reference to a Helm release.

That would be simpler to start. Sounds good.
Also, I love the config syntax you proposed as it is concise while being extendable to support labels or other things in the future 😄

dependsOn would be allowed

within the same helmfile OR

OK. Each helmfile is isolated so that would be natural.

in one of the bases

This one is hard. bases is for including other helmfiles(as modules) before processing releases in the caller helmfile as you'd also taken into account in:

Parse all available releases: (after merging in all of the bases:). Each Helm release is a DAG vertex/node.

all available releases naturally contain all the releases loaded from bases, which affects dependsOn. Are you ok with that?
A possible upside of it would be that you can extract a dependency into a helmfile module and switch implementation by using go template in bases. Downside? No idea yet.
And,

Implementation details:

It looks great! Thanks for all the suggestions and proposals again.

If it works only within a single helmfile, why you need this?

Can't you just split your helmfile to two or more and order them under helmfiles:, cuz helmfiles: is a declarative way to order groups of helmfiles.
Or is it just that you want a simpler(or a more declarative - you feel so?) way than that?

I really like purely declarative tools (like Terraform and CloudFormation) where the order of declaration doesn't matter. It's a bit more pleasant to reason about (arguably, of course).

all available releases naturally contain all the releases loaded from bases, which affects dependsOn. Are you ok with that?

That's exactly my

cuz helmfiles: is a declarative way to order groups of helmfiles.

With helmfiles: order of items is vitally important, so in my view it's not really declarative. If we implemented dependsOn with bases: instead of helmfiles:, order of bases doesn't matter at all as long as you declare all necessary dependencies.
Instead of thinking:

I'm adding a new release myapp, it must be deployed after which releases? 🤔 (Is my otherapp, a dependency, declared in helmfile1.yaml or helmfile3.yaml or helmfile5.yaml, I forgot?)

I prefer this:

I'm adding a new release myapp, I know it depends on myotherapp, so I just add myotherapp to dependsOn.

I really like purely declarative tools (like Terraform and CloudFormation) where the order of declaration doesn't matter. It's a bit more pleasant to reason about (arguably, of course).

Understood 👍

That's exactly my proposal.

Okay. Thanks for confirming 👍

In your example dependsOn: is a list of strings. Is your suggestion to refer to bases, not labels (with .yaml suffix removed)? Or are you implicitly referring to group labels?
Ah nope, my mistake. I meant e.g. name=prometheus as helmfile has a convention that automatically put name=<RELEASE NAME> label to every release.

How so? 🤔 In your example mymainapp is doesn't have env=preview label.
Good catch! My mistake. I should have created two mymainapp releases with varying env labels.

This part is super confusing to me 😕 As a new user I'd assume

Okay then let's omit this part :) FWIW, it was also based on my frustration that kubectl -l foo=bar -l foo=baz doesn't work cuz the latter silently overrides the former.

In Helm 3 releases are namespaced, so namespace should be part of the reference to a Helm release.
releases:

- name: myapp
  dependsOn:
  - release: prometheus
    namespace: telemetry

- name: prometheus
  namespace: telemetry

Sounds correct! I believe it should be tillerNamespace for helm v2 though, as helm2 releases are isolated per tiller ns.

...And the gotcha is that even helm v2 allows isolating releases per tiller namespace, helmfile doesn't allow having two or more releases with the same name across different tiller namespaces.
So regarding this feature, we'd better start without namespace or tillerNamespace, that is:
releases:

- name: myapp
  dependsOn:
  - release: prometheus

So here's the plan for the first version of this feature based on @ilyasotkov's awesome proposal above:
Goal
Make helmfile even more declarative regarding release dependencies
Enhancement to the config syntax
The configuration syntax is enhanced to accept dependsOn per each release under releases. Each dependsOn item receives solely release.name.
releases:
- name: myapp
  dependsOn:
  - release:
      name: prometheus
- name: prometheus
  namespace: telemetry

From within dependsOn you can refer to releases defined in the same helmfile and its bases only. You can't refer to other releases defined in sub-helmfiles, as each sub-helmfile is isolated by design.
Helm v2 release is isolated per tiller namespace. Helm v3 release is isolated per namespace. But this syntax, for its first version, doesn't account that - helmfile as of today doesn't support two or more releases with the same name regardless of the tiller namespace and it remains so. Please submit an another feature request to enhance helmfile to accept two or more releases per (tiller) ns, which should also address this.
Implementation details

helmfile parses all available releases: (after merging in all of the bases:). Each Helm release is a DAG vertex/node.
It then parses dependsOn for all available releases, validate that they can be found from the available releases. If not found, only proceed if --allow-unresolved-deps flag is specified.
Add each valid dependsOn item as a directed edge in the DAG.
Topologically sort the DAG, end up with a two-dimensional array.
Loop over the resulting array, deploying all items of the inner arrays (Helm releases) in parallel.

Future plans

Add --resolve-all-deps that is used like -l labelkey=val --resolve-all-deps, so that you can deploy releases whose labels contain labelkey=val, along with its dependencies.

The configuration syntax is enhanced to accept dependsOn per each release under releases. Each dependsOn item receives solely release.name.

I like that enhancement as it makes things a bit more clear and a lot more extensible 👍

So here's the plan for the first version of this feature based on @ilyasotkov's awesome proposal above

Great summary of the proposal, thank you @mumoshu for your amazing work and exceptional communication ❤

A possibly unavoidable limitation to this feature is that helmfile diff and helmfile apply would still fail due to missing CRDs in a case like https://github.com/roboll/helmfile/issues/538#issuecomment-499296083
Are you okay with that? I'd appreciate it if you could share your insights to resolve it fully. I'm thinking that we'd need:
helmfiles:
- crds.yaml

releases:
- name: something-depends-on-crd-to-exist-in-the-cluster-before-diffing

Instead of the below, which would certainly fail while helm diffing due to that at the time of running it there's no crds installed:
releases:
- name: crds
- name: something-depends-on-crd-to-exist-in-the-cluster-before-diffing
  dependsOn:
    release:
      name: crds

Missed to mention you @ilyasotkov :)

@mumoshu I'm not currently a user of those features (apply and diff) so I am not able to offer any real insight until I try them out and understand how they work :)

So here's the DAG implementation I'll be integrating into Helmfile.
https://github.com/mumoshu/dag

The pull request for this is live at #914.
A few notes:

I've chosen needs instead of dependencies to avoid ambiguity for chart's dependencies
needs are just an array of IDs of releases. Each ID is formatted [TILLER_NS/][NS/]NAME where [TILLER_NS/] and [NS/] can be omitted(and can't be specified when the target release has no tillerNamespace and/or namespace declared.) This turned out easier to read/write and flexible enough to support expected use-cases the latter idea considered in https://github.com/roboll/helmfile/issues/715#issuecomment-506100658


Java: have a future cache

We recreate future on every request, there is no reason to do so.

I don't understand this patch at all :-( Not it's motivation - is creating a future slow? - nor the implementation... Is it really ok in Java to return the same future twice? In Seastar, for example, it is a faux pas.
If you didn't like the idiom used in the existing code,
CompletableFuture<Endpoint> f = new CompletableFuture<Endpoint>();
f.complete(ret);
return f;

how about using
return CompletableFuture<Endpoint>.completedFuture(ret);

This is a built-in idiom to return a ready value that is presumably implemented in the most efficient way possible - why do we need something more efficient that has dubious correctness?

I don't understand this patch at all :-( Not it's motivation - is creating a future slow?

It depends, creating future allocates memory, if code works in normal circumstances it does not do much, but if it is CPU or memory bound, it causes performance degradation, if we can, we need to avoid that.
resolveEndpoint is called on every request, so it is definitely worth that.

nor the implementation... Is it really ok in Java to return the same future twice? In Seastar, for example, it is a faux pas.

It is ok, in java future is just a class instance, final state of which to hold an instance of underlying type or exception.
It does not matter how many times you wait it, or obtain it's result.

If you didn't like the idiom used in the existing code,
CompletableFuture<Endpoint> f = new CompletableFuture<Endpoint>();
f.complete(ret);
return f;

how about using
return CompletableFuture<Endpoint>.completedFuture(ret);

This is a built-in idiom to return a ready value that is presumably implemented in the most efficient way possible - why do we need something more efficient that has dubious correctness?

It is still allocates and deallocates memory.

I don't understand this patch at all :-( Not it's motivation - is creating a future slow?

It depends, creating future allocates memory, if code works in normal circumstances it does not do much, but if it is CPU or memory bound, it causes performance degradation, if we can, we need to avoid that. resolveEndpoint is called on every request, so it is definitely worth that.

You may be more up-to-date than me, as I said it's been 15 years since my last "serious" work in Java, but did work in Java heavily for 5 years before that so I have some experience that seems to contradict what you're saying and I wonder what I am missing. My experience is that much of Java code keeps creating objects that are just returned once and then abandoned. There is no "deallocation cost" - the "generational" GC is written with the knowledge that in Java most objects in the will be abandoned and not survive their first GC, and makes this use case very efficient (and in particular - NOT proportional to the amound of allocations done in the young generation).
You are suggesting that return CompletableFuture<Endpoint>.completedFuture(ret); is wasteful. If so, why does it exist? What doesn't its documentation suggest it is inefficient?
Moreover, your alternative to completedFuture() isn't free either - in the best case it involves a hash table lookup. Are you sure that the memory allocation done by completeFuture() (not much more than a pointer increment!) is more expensive than this hash lookup? Is it so much more efficient that it's worth making the code more complex?

* nor the implementation... Is it really ok in Java to return the same future twice? In Seastar, for example, it is a faux pas.

It is ok, in java future is just a class instance, final state of which to hold an instance of underlying type or exception. It does not matter how many times you wait it, or obtain it's result.

Is this documented anywhere? It's not at all obvious to me whether this approach is supposed to work or not - in Seastar it wouldn't have worked. I found a package https://github.com/jmnarloch/completable-future-cache that also uses this idea of returning a multiple reference to the same CompletableFuture object ("all of them will gain access to the same instance of CompletableFuture that they can observe for completion") so I guess you are correct, and it's not a wrong approach.
I still wonder if it's worth it. Could you do me a favor and try some sort of loop or something to measure if completedFuture() is really as slow as you assume it to be?

how about using
return CompletableFuture<Endpoint>.completedFuture(ret);

This is a built-in idiom to return a ready value that is presumably implemented in the most efficient way possible - why do we need something more efficient that has dubious correctness?

It is still allocates and deallocates memory.

Java has no "deallocation" of memory. It uses a generational GC, where allocation is O(1) but very efficient (basically, just increment a pointer) and deallocation is, believe it or not, less than O(1) - i.e., deallocation is (more-or-less) free, it is the memory that is not deallocated - i.e., lives for a significant amount of time - which takes cycles.
So I doubt the completedFuture() function is inefficient as you think it is. It might even be a tiny bit faster than the hash-table lookup you replaced it with... And certainly easier to understand.

I don't understand this patch at all :-( Not it's motivation - is creating a future slow?

It depends, creating future allocates memory, if code works in normal circumstances it does not do much, but if it is CPU or memory bound, it causes performance degradation, if we can, we need to avoid that. resolveEndpoint is called on every request, so it is definitely worth that.

You may be more up-to-date than me, as I said it's been 15 years since my last "serious" work in Java, but did work in Java heavily for 5 years before that so I have some experience that seems to contradict what you're saying and I wonder what I am missing. My experience is that much of Java code keeps creating objects that are just returned once and then abandoned. There is no "deallocation cost" - the "generational" GC is written with the knowledge that in Java most objects in the will be abandoned and not survive their first GC, and makes this use case very efficient (and in particular - NOT proportional to the amound of allocations done in the young generation).
You are suggesting that return CompletableFuture<Endpoint>.completedFuture(ret); is wasteful. If so, why does it exist? What doesn't its documentation suggest it is inefficient?
Moreover, your alternative to completedFuture() isn't free either - in the best case it involves a hash table lookup. Are you sure that the memory allocation done by completeFuture() (not much more than a pointer increment!) is more expensive than this hash lookup? Is it so much more efficient that it's worth making the code more complex?

* nor the implementation... Is it really ok in Java to return the same future twice? In Seastar, for example, it is a faux pas.

It is ok, in java future is just a class instance, final state of which to hold an instance of underlying type or exception. It does not matter how many times you wait it, or obtain it's result.

Is this documented anywhere? It's not at all obvious to me whether this approach is supposed to work or not - in Seastar it wouldn't have worked. I found a package https://github.com/jmnarloch/completable-future-cache that also uses this idea of returning a multiple reference to the same CompletableFuture object ("all of them will gain access to the same instance of CompletableFuture that they can observe for completion") so I guess you are correct, and it's not a wrong approach.
I still wonder if it's worth it. Could you do me a favor and try some sort of loop or something to measure if completedFuture() is really as slow as you assume it to be?

how about using
return CompletableFuture<Endpoint>.completedFuture(ret);

This is a built-in idiom to return a ready value that is presumably implemented in the most efficient way possible - why do we need something more efficient that has dubious correctness?

It is still allocates and deallocates memory.

Java has no "deallocation" of memory. It uses a generational GC, where allocation is O(1) but very efficient (basically, just increment a pointer) and deallocation is, believe it or not, less than O(1) - i.e., deallocation is (more-or-less) free, it is the memory that is not deallocated - i.e., lives for a significant amount of time - which takes cycles.
So I doubt the completedFuture() function is inefficient as you think it is. It might even be a tiny bit faster than the hash-table lookup you replaced it with... And certainly easier to understand.

It is not about deallocation per say, it is more about sheer amount of objects that GC needs to track, less objects to track, less problem GC has.
Let's say that you have 6 nodes, and send 1000 rq/s.
Old code will allocate 1000 futures plus 1000 endpoints a second and they are going to finalized at young or at s0.
New code will allocate 6 futures and 6 endpoints once, all of them end up in old gen where GC spends minimal possible resources on reclamation.
Even if you don't take GC part into account new code looks good and if you consider that in order to pass an object from one genertion to another it spends CPU cycles for every object in the original generation, it looks even better.


fatal:Number of subscripts do not match number of dimensions of variable,(2) Subscripts used, (3) Subscripts expected
fatal:["Execute.c":8637]:Execute: Error occurred at or near line 180 in file /mnt/lustre01/pf/b/b309143/ESMValTool-public/esmvaltool/diag_scripts/eyring06jgr/eyring06jgr_fig12b.ncl
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/ESMValGroup/ESMValTool/pull/1593#issuecomment-613321574, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGGMESZVC7PD7AKGDVHX4QTRMQSATANCNFSM4LQEOUQQ.

Ok I’ll check today. I hope to close recipe_eyring06jgr.yml by today. I’ve recipe_eyring13jgr. 01 and 02 nearly ready to be uploaded.

Il giorno 15 apr 2020, alle ore 17:30, Birgit Hassler<EMAIL_ADDRESS>ha scritto:
Same as 12a try to add zonal mean in the namelist preprocessor
[…]
I did.
I get the following error message:
"month_to_annual: some points have missing data: nt=0 nyr=0 num(nGood)=21
month_to_annual: some points have missing data: nt=12 nyr=1 num(nGood)=22
month_to_annual: some points have missing data: nt=24 nyr=2 num(nGood)=22
month_to_annual: some points have missing data: nt=36 nyr=3 num(nGood)=22
month_to_annual: some points have missing data: nt=48 nyr=4 num(nGood)=22
month_to_annual: some points have missing data: nt=60 nyr=5 num(nGood)=22
month_to_annual: some points have missing data: nt=72 nyr=6 num(nGood)=22
month_to_annual: some points have missing data: nt=84 nyr=7 num(nGood)=22
month_to_annual: some points have missing data: nt=96 nyr=8 num(nGood)=22
month_to_annual: some points have missing data: nt=108 nyr=9 num(nGood)=22
fatal:The result of the conditional expression yields a missing value. NCL can not determine branch, see ismissing function
fatal:["Execute.c":8637]:Execute: Error occurred at or near line 255 in file /mnt/lustre01/pf/b/b309143/ESMValTool-public/esmvaltool/diag_scripts/eyring06jgr/eyring06jgr_fig12a.ncl"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/ESMValGroup/ESMValTool/pull/1593#issuecomment-614109687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGGMESYAVXGEG6BDZ4DEV4TRMXHKTANCNFSM4LQEOUQQ.


term api

monitor functionality is broken now

eval doesn't use overridden functions, this should also be fixed

Everything (except eval) is working now, we can fix eval later, but this is overall ready

DON'T MERGE THIS I AM ADDING NESTED SHELLS

style: no


Fixed frontend URL Error

Fixed the issue described here:
https://github.com/Marktawa/blog-strapi/issues/2

Thanks, @AbeezUrRehman!
Looks good.


[BUG] Output panel sometimes empty when opening a link

Describe the bug
When loading a shared link, Output views may sometimes be detached from their associated compiler, and appear empty.
To Reproduce
Add a second Compiler panel, and open its associated Output panel. Close the first Compiler panel, leaving you with Compiler #2 and Output #2. Create a shortlink for the page and visit it. When the page opens, the Compiler #2 panel will now be labeled as Compiler #1, and the Output panel will be labeled "#2" and have no contents.
Expected behavior
Compiler #2 to remain named as such, and for the Output #2 panel to maintain its association and display the output from Compiler #2.
Link
https://gcc.godbolt.org/z/5MAB8D

Thank you for taking the time to find a way to reproduce this, it is going to be super useful! :)

The linked commit should have fixed the issue. Thanks for the report and for taking the time to find a reproducible step by step guide :)
It should hit the live site shortly


[SyntaxCollections] Add a reversed Sequence for SyntaxCollections

This is similar to what we do for other sequences.

@swift-ci Please test


App for Windows32 too?

Hi, may your app work on Windows32 too?
I dont find any download link.
thanks.

Yes - read the READme on how to download/install.
Follow issue templates or join Discord for support.


Feature request : ability to enable/disable showing which user took which line

Currently displays "taken"
Not a priority but ability to enable or disable public display to bidding users of the user's first initial and last name below might be useful should need arise.

Added this option - controlled on settings page


Support for PostgreSQL 16

In issue #218 there is a mention to upgrading the parser to PostgreSQL 16: is there a plan for that?
See also https://github.com/lelit/pglast/issues/137
Thanks&bye!

Debian wants to finish the transition to PG16 and would profit from libpg-query being upgraded. Thanks!

We're working on this currently, and hope to have a release out in the next week or two 🙂

Completed via https://github.com/pganalyze/libpg_query/pull/225 last week and tagged as 16-5.0.0.


Adding a webApp example using Dash

Added a Webapp example for Dash with PyMapdl : 1 file ,1 "assets" folder with four files and a README.txt

@germa89, leaving this for you to review.
We can also consider a separate repo for this.

Hi @rs-bh-n
Thank you for this contribution.
I did have a look at the example.

And I couldn't make it work, terminal was complaining about:

[2022-09-21 16:35:14,305] ERROR in app: Exception on /_dash-update-component [POST]
Traceback (most recent call last):
  File "C:\ProgramData\Miniconda3\envs\pymapdl_0\lib\site-packages\flask\app.py", line 2525, in wsgi_app
    response = self.full_dispatch_request()
  File "C:\ProgramData\Miniconda3\envs\pymapdl_0\lib\site-packages\flask\app.py", line 1822, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "C:\ProgramData\Miniconda3\envs\pymapdl_0\lib\site-packages\flask\app.py", line 1820, in full_dispatch_request
    rv = self.dispatch_request()
  File "C:\ProgramData\Miniconda3\envs\pymapdl_0\lib\site-packages\flask\app.py", line 1796, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
  File "C:\ProgramData\Miniconda3\envs\pymapdl_0\lib\site-packages\dash\dash.py", line 1259, in dispatch
    ctx.run(
  File "C:\ProgramData\Miniconda3\envs\pymapdl_0\lib\site-packages\dash\_callback.py", line 439, in add_context
    output_value = func(*func_args, **func_kwargs)  # %% callback invoked %%
  File "C:\Users\gayuso\Others_pymapdls\pymapdl_0\pymapdl\examples\07-webapps\dash-vm35\BimetallicStrip.py", line 571, in start_pymapdl
    p_run = pyMapdl_vm35(float(L), float(t), float(tr), float(ta), float(e1), float(e2), float(c1), float(c2))
  File "C:\Users\gayuso\Others_pymapdls\pymapdl_0\pymapdl\examples\07-webapps\dash-vm35\BimetallicStrip.py", line 77, in pyMapdl_vm35
    with open(data_file, 'a', newline='\n') as f:
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\gayuso\\Others_pymapdls\\pymapdl_0\\pymapdl\\assets\\data.csv'
<IP_ADDRESS> - - [21/Sep/2022 16:35:14] "POST /_dash-update-component HTTP/1.1" 500 -

I think you are not referencing correctly the location of data.csv:
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\gayuso\\Others_pymapdls\\pymapdl_0\\pymapdl\\assets\\data.csv'

In the meantime, I'm thinking what to do with this example. Because it is mean to have a running MAPDL (docker image probably) on the background to perform the calculations.
I don't think we have that capability in the current documentation implementation, and that suppose a cost (keeping the MAPDL running) and a complication (because of the required infrastructure).
I'm a bit short of manpower at the moment, so I cannot spend as much time as I would like on this. So I would say to create its own repository, so we can make it installable, and someone can run it locally easily. We can upload images of the websites, even gifs, .... I will reference it in the PyMAPDL documentation website.
I think this is a good compromise between complexity and available time. What do you think @rs-bh-n ??

Hi @germa89 ,
Thanks for checking .

The py file expects the assets folder in the same directory (as the py file) .
a) Can you check with the assets folder in place?
b) Should the files (py_file and assets_folder) be zipped to avoid this confusion ?

I did not intend to run a webapp on our server that anybody can access anytime , I understand the complications .
This example  is just a simple demonstration of :
- how pymapdl can be used as a backend (for a webapp created by user with  dash as front end)  and
- how to launch the webapp and interact with  backend server (this uses his/her local mapdl installation )

The users can later, with their IT team's help,  probably explore webApp deployment(which is out of scope for us)  for his/her  team. What do you say , @germa89  ?

I'm moving this to the example repo: https://github.com/pyansys/pymapdl-examples

Actually no... in that repo there is no general examples. Keeping it here.

Merging. Comments or feedback will be added on a later PR.


Fix retry policy for HttpError's

One of the recently merged PRs:
changed the retry Policy for 4xx status codes. Previously ApiException was only thrown on 5xx status codes, therefore 4xx status codes were immediately propagated back to user - which is expected behavior. But now that HttpError is thrown on 4xx status codes as well, the policy is retrying 5 times before actually throwing exceptions (i.e. with 404 errors) back to user.
This PR returns the previous behavior back.

Just for posterity, want to note this:
I actually don't like the original code and this change is an improvement but it makes no sense to always retry HTTP calls on even 5xx errors. Really only specific ones, probably Only 502/3/4. However this PR is an improvement on the situation and resolves a client perf issue

@torkins @NRHelmi is this ready to go? If so could you please get this released?

@torkins @NRHelmi is this ready to go? If so could you please get this released?

@stanislav-bedunkevich will merge and release, thanks @Zlata-Zueva again for the fix


[Bug] ValueError: 'Back up.' is not in list

Thanks for the excellent work and auto-driving challenge. I have a bug when I run convert_data.py under "./challenge".
ValueError: 'Back up.' is not in list
I check the function and find that in line 7 of "challenge/convert_data.py". There is no "Back up" option. What should I do about it?
def rule_based1(question, answer):
rule = ["Going ahead.", "Turn right.", "Turn left.", "Stopped."]
question += f" Please select the correct answer from the following options: A. {rule[0]} B. {rule[1]} C. {rule[2]} D. {rule[3]}"
idx = rule.index(answer)
mapping = {0: "A", 1: "B", 2: "C", 3: "D"}
return {"Q": question, "A": mapping[idx]}

Thanks for pointing out the issue. We're looking into it. @DevLinyan

btw could you provide the detail of the running? like which part of the data and specific frame id.

Could you please furnish more specific information? I'm particularly interested in obtaining the input question and answer related to 'Back up.'
Additionally, during my search for a matching answer, the identified answer for 'Back up' cannot be passed into this function due to its failure to satisfy the if condition specified in line 51.

Thanks! This issue has been solved.


Add 'Mandatory JUnit XML Attributes' section

PIE-1252
https://linear.app/buildkite/issue/PIE-1252/document-mandatory-junit-properties
A customer, Robinhood were having issues with uploading their JUnit
XML file. They were missing the mandatory attributes from the
testcase element.
https://3.basecamp.com/3453178/buckets/20365997/messages/5611360141#__recording_5459384344
https://3.basecamp.com/3453178/buckets/20365997/card_tables/cards/5611354161

Preview site https://bk-docs-pr-1804.onrender.com/docs/test-analytics/importing-junit-xml#mandatory-junit-xml-attributes

Thanks @olyism and @mbelton-buildkite, I've incorporated the changes you both have suggested.
In regards to a better source on the XML JUnit, I made a comment about it in the thread above. I have also consulted the TA team on Linear https://linear.app/buildkite/issue/PIE-1252/document-mandatory-junit-properties#comment-3b7e43bd


NDRS-1104: Emitting Event::PutBlockResult after putting execution results to storage

Fixes the block_completion_duration metric

bors merge


Add Tuple.from, Tuple#from, NamedTuple.from and NamedTuple#from

Similar arguments as for values_at(*args) back then, except it can handle
mixed types.
In general I thought it might be a generally useful and a neat trick. It can also
provide a nice way to parse mixed JSON or YAML arrays.
thing, n = {String, Int64}.from(JSON.parse(%(["world", 2])) as Array)

But you can do:
require "json"

thing, n = Tuple(String, Int64).from_json(%(["world", 2]))

I'm not sure about the from methods, I'd like to see more use cases.

It was just an example usage, as an obvious source of mixed, union typed arrays. This is much more general.
I believe this is one of the things that provide some general functionality that only gets useful when composed with other things. Querying databases, parsing CSV, a library that takes an array or tuple where the other one would have fit your usecase better and things I can't even imagine yet.
I don't think this adds any maintenance overhead, it's something we can provide people to play with. Remember when you were surprised how I used generics for be_a or whatever it was? I expect similar things to happen here.
Arguably I'm not 100% confident about the name, but using new for this would have made the spec I added for it fail.

Also note that this was motivated by a question IRC how one could turn an array into a tuple. While I didn't ask for the usecase, that question didn't come up the first time.

This is pretty similar to how I'm doing things in crystal-pg https://github.com/will/crystal-pg/blob/master/src/pg/result.cr#L73-L76

Still not giving this up, added NamedTuple variants too ;)

I think this is useful :-)
I want to test it a bit, so I'll probably merge this in 0.18.0

My usecase: turn String.split(limit: 2) into {String, String}`
I would really like to see this added.

Given the new splat type restrictions, any changes desired here?

@jhass I'll take a look at this tomorrow, and probably merge

Dropped TODOs since #2607 was fixed.

I just reviewed this, it looks good. I'm not sure about the name from, but it reads well, and we can't use new because that expects the types of the tuple. So 👍  from me, and merge if you want :-)


renode-unstable: 1.15.2+20240823gitc4eea992a -> 1.15.2+20240829gitfedcdbdaf

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for renode-unstable is: Virtual development framework for complex embedded systems
meta.homepage for renode-unstable is: https://renode.io
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.15.2+20240829gitfedcdbdaf in filename of file in /nix/store/dyhl1zlysbvgnh9sbcyam9xc6f8639jm-renode-unstable-1.15.2+20240829gitfedcdbdaf

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

renode-unstable

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/dyhl1zlysbvgnh9sbcyam9xc6f8639jm-renode-unstable-1.15.2+20240829gitfedcdbdaf \
  --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 renode-unstable https://github.com/r-ryantm/nixpkgs/archive/ca915c95a4ee9491c18d5b7f6a95bad00ae7e80e.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/ca915c95a4ee9491c18d5b7f6a95bad00ae7e80e#renode-unstable

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/dyhl1zlysbvgnh9sbcyam9xc6f8639jm-renode-unstable-1.15.2+20240829gitfedcdbdaf
ls -la /nix/store/dyhl1zlysbvgnh9sbcyam9xc6f8639jm-renode-unstable-1.15.2+20240829gitfedcdbdaf/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

1 package built:

renode-unstable

Maintainer pings
cc @otavio for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


Parameterize Salesforce Refresh Token

Closes PROD-1535
Description Of Changes
Parameterizes the token refresh url for Salesforce, as it is different for Sandbox accounts (test.salesforce.com) as noted by many users have found when doing some early testing with sandbox accounts
Production and Dev accounts use the same refresh url (login.salesforce.com)
Additionally, some default data category updates are required that are included here which:

remove some fields that cannot be updated as they are derived from others
includes some other minor fields that were not being updated on erasure by default

I'm not sure how much I like having to label the categories as system.operations for fields that reflect personal data. It feels as if we are having a collision between identification of where personal data exists and the policy to erase said data. It would be interesting if something like the skip attribute of a Collection could be used at the Field level as well when derived or non-updatable on a Collection. That being said, I can sort of argue it both ways
Code Changes

[x] parameterize refresh_token_url
[x] update default data categories for Salesforce

Steps to Confirm

[x] The salesforce connector is created as needed for both scenarios

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated

@MarcGEthyca @galvana - adding a reference to the docs changes here as well, curious about your thoughts -> https://github.com/ethyca/fidesdocs/pull/313


The getter method of Scores class needs to be public

The getter methods of Scores class properties need to be public. This is required for a custom implementation of RepairerDestroyerManager interface.

This issue is fixed as part of release 1.0.1


Project setup update phase2

@saeedmb8 @nathanbegbie please review.

@Mitso Could you please give a brief description for this PR? It's a bit difficult to get a sense of what's going on here

@nathanbegbie thanks for the review.
Apply  SASSLINT  convention 'hyphenatedbem':  rules, currently not following config rules
Restructure SASS file imports using Gulp sassGlob, as well as workaround for cascade rules where applicable.

Cleanup SASS files, variables, mixins.
Cleanup html pattern files where SASS update is applicable.

🍰 🍰 🍰


fix Log encoding at initial file creation

--- Logging error --- Traceback (most recent call last):   File "x__init__.py", line 994, in emit     stream.write(msg)   File "xcp1252.py", line 19, in encode     return codecs.charmap_encode(input,self.errors,encoding_table)[0] UnicodeEncodeError: 'charmap' codec can't encode character '\u2023' in position 77: character maps to <undefined>

fixed in next release


Documentation

I'm thinking of starting the documentation for EnvShare (docs.envshare.com or envshare.com/docs) that'll host information pertaining to the service.
It will have

A little more indepth information on how the front end client works/how data is stored
A bit more insight to the cryptography flow used to help garner trust for anyone using the service
Information for the CLI (coming soon) when it launches
Information about the API (with the caveat of not using it to share unencrypted secrets) so people can create their own clients that utilize the API
Changelogs so people can keep up to date with additions/modifications to changes in API/CLI

Any other thoughts/ideas?
I tend to use mintlify/docusaurus for documentation so it can be easily hosted on Vercel or GH Pages.

I'd prefer /docs, for no good reason other than Personal preference.
I'm not a huge fan of docusaurus tbh and I'd prefer nextra as it integrates nicely into the nextjs app.
There's a nextjs13 compatible repo/guide by github.com/shadcn/taxonomy
I'll have to check out mintlify

But either way it'll be markdown I suppose, so we can start on content.
Your suggestion make a lot of sense, let's do those first and then see what's missing

I'll check out nextra, it does seem like it integrates nicer with Next13 (and yeah content is the most important)
I prefer MDX content as well especially for Storybook/Docs!

If you want I can setup the docs and you start on actual content

That'll work for me! I have a notion doc where I'm working on the content, I havent had the time to spin up the actual doc implementation so if you can get it up, I'll fill it out

This Notion doc I have is a running list of the content that the documentation will have:
https://lofty-coelurus-7e3.notion.site/Documentation-MDX-76ac99db2b2f492f80aaf44512bfe46e
Feel free to leave comments (I was going to allow it to be editable but the problem is that this gh issue is publicly viewable and I worry about people finding it and editing the notion doc 😂 )


Automated Synthesis of Syndrome Extraction Circuits for CSS codes

Description
Finding optimal scheduling for the CNOTs in a syndrome extraction (SE) circuit is a computationally difficult scheduling task. This PR introduces methods for creating such schedules for any CSS code.
Features:

[x] Optimal synthesis of SE schedules for any CSS code instance.
[x] Optimal synthesis of SE schedules for CSS code families based on regular plane tilings if the dependencies between qubits in the tiling are provided.
[ ] Automated construction of dependencies given a tiling.

Checklist:

[ ] The pull request only contains commits that are related to it.
[ ] I have added appropriate tests and documentation.
[ ] I have made sure that all CI jobs on GitHub pass.
[ ] The pull request introduces no new warnings and follows the project's style guidelines.

@pehamTom Would be nice to merge the main branch in here to clean up the commit history.


How can I get position?

Hi! I'd like to get some info by using this library and stuck so much.
1: Set my face position first, and if it's bigger (for example 120%),  show alert.
OR
2: Set my eye position first, and if it goes lower(for example 2cm), show alert.
Can I set and get coordinates by using this library?  Any suggestions would be appreciated. Thank you!

1: Not that I'm aware of, but you could build something like this yourself. Say you have detected a Faces like this:
// Load your models fist:
// https://github.com/justadudewhohacks/face-api.js#loading-the-models

const singleResult = await faceapi
  .detectSingleFace(sourceImage)
  .withFaceLandmarks()
  .withFaceDescriptor();

const box = singleResult.detection.box;

box has a couple of Properties as can be seen here, there's also it's Area somewhere. This way you could figure out what your "100%"-should be and compare that to another value as you like.
2: There are some Methods you can use to acheive something like this. But I'd guess that using cm wont work here, you've to use Pixels or Percentages.
Good Luck!


change from tojson to to_json - for systems where newer version of jinja is not available.

On systems where it is not possible to upgrade jinja2 installer will fail as module
tojson is not part of jinja installation. This is case for RHEL 7/Centos 7 which deliver
python36-jinja2-2.8.1-2.el7.noarch
python-jinja2-2.7.2-4.el7.noarch
eg ansible issue : https://github.com/ansible/ansible/issues/25381
Fedora 30 is not affected with this problem

@akrzos @chaitanyaenr installer fails on rhel7 due to this ( with jinja as above ), so either change per PR, or some other solution to provide tojson module

LGTM, Thanks @ekuric


Fix SEO tags for Home Page

Right now it's just taking the featured article as we're not sharing anything

 Fix SEO tags for home page


How to build when I can't add pico_sdk_init() to existing project?

Normally, you'd just specify a CMAKE_TOOLCHAIN_FILE when invoking cmake. Why does the Pico SDK require modifying the CMakeLists.txt? Is there another way?

I'm not entirely sure what you're asking, but perhaps some of the comments in https://github.com/raspberrypi/pico-feedback/issues/210 will point you in the right direction? (But if they don't, please excuse my ignorance!)

Yeah, that's the same problem. For my use-case I can solve it like that. But in general it'd be nice to be able to build third party libraries without modifying them or adding them as submodules to a parent project that pulls in the pico stuff. Feel free to close this if that's not something you want to do.

One issue with using CMAKE_TOOLCHAIN_FILE is that the SDK build also builds native tools used by the build (which was deemed easier for the majority of users/platforms). We may revisit this in the future.
Note also that today, libraries that depend on the SDK tend to be INTERFACE libraries (again we may make it easier to build static libraries dependent on the SDK in the future). if however you are building a pre-existing non Pico specifc static library (without pulling it into your project as a submodule), then surely you can just build it. why do you need to do pico_sdk_init() at all?

@parbo I replaced project with a macro to work around this

@ooxi could you elaborate?

seems like there is a workaround here


CI improvements

Adds static analysis with cargo fmt and cargo clippy, adds codecov.io and MSRV build.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@ac039d7). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #7   +/-   ##
=======================================
  Coverage        ?   97.57%
=======================================
  Files           ?        1
  Lines           ?      494
  Branches        ?        0
=======================================
  Hits            ?      482
  Misses          ?       12
  Partials        ?        0

Continue to review full report at Codecov.

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


Runtime builder implementation

We're going to change how to generate Dockerfile for App Engine Flexible applications. Now gcloud sdk is running some python code to generate Dockerfile locally. This builder implementation is to replace this functionality with a cloudbuild step.
The create-dockerfile docker image just creates Dockerfile and .dockerignore if not present. The generated Dockerfile must have an environment variable based on the value of runtime_config -> document_root of users' app.yaml.

What's the overall goal this is trying to solve? It looks like it's trying to create a cloud build step for autogenerating a Dockerfile/.dockerignore if the files aren't present.

@chingor13 Alright, updated the description

@chingor13 Just added unit tests. PTAL

The failure
1) Google\Cloud\tests\EndToEndTest::testExec
GuzzleHttp\Exception\ServerException: Server error: `GET https://circle-306-dot-php-mvm-a.appspot.com/exec.php` resulted in a `503 Service Unavailable` response:
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, w (truncated...)

The failure seems to be an issue within App Engine frontend (again) since there are no logs on the server.

Tests keep faling, sorry, but good thing is the test caches all the mistake I made ;P
I think this time it will pass


Refactor: Encapsulate move in process logic in domain service

Description
Refactor: Encapsulate move in process logic in domain service

@cla-bot check


Use unminified sources as "main"

Having minified sources be the "main" makes things much harder to debug. Minification should be an issue for the end client and how they want to setup webpack or similar, not the individual libraries.

Just ran into this when trying to troubleshoot #931. Isn't this a trivial change to make?

One thing I noticed is that the minified and unminified sources seem to differ slightly in the objects/classes they expose. This was a bit hard to tackle while also trying to debug. Definitely should be changed for 2.0 due to that.
Making this change would allow packaging utilities to apply tree shaking to eliminate unused code in the library too.

I agree that exposing the minified version is not good for integration and troubleshooting.
However, the /lib/oidc-client.js is already transpiled and changed.
I think that the library should have:

main (code transpiled to CommonJS)
module (ejs code)>
browser (transpiled browser compatible code).

Then most modern bundlers can automatically pick up the right one.
Since this issue and the related PR have been stuck for more than 6 months, I'd like to ask the maintainers if implementing a new build like this is something that you'd take as a PR or you want to keep things as they are, @brockallen .

Using the minified version as main renders the lib practically un-debuggable in a dev env.
As a workaround, you can manually edit node_modules/oidc-client/package.json, but you'll have to do it every time it is overwritten.

Had to do what OP did today.  This user did too: https://github.com/IdentityModel/oidc-client-js/issues/1044#issuecomment-591625560
This is quick to fix yourself when you know where to look, but otherwise it's another hurdle you need to jump over to debug your app.

ping @brockallen
did you see my comment above?

Honestly speaking, https://github.com/manfredsteyer/angular-oauth2-oidc is much-much better for Angular.


cli: drop the apply subcommand

This removes torcx apply subcommand, which has now been fully
replaced by the generator.

/cc @squeed


Error while getting Updates: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running

1. Error while getting Updates: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running
2. AttributeError: 'NoneType' object has no attribute 'effective_chat'
Mar 8 12:21:32 PM  Error while getting Updates: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running
Mar 8 12:21:32 PM  Exception while handling an update:
Mar 8 12:21:32 PM  Traceback (most recent call last):
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/ext/_updater.py", line 607, in _network_loop_retry
Mar 8 12:21:32 PM      if not await action_cb():
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/ext/_updater.py", line 335, in polling_action_cb
Mar 8 12:21:32 PM      raise exc
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/ext/_updater.py", line 327, in polling_action_cb
Mar 8 12:21:32 PM      allowed_updates=allowed_updates,
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/ext/_extbot.py", line 533, in get_updates
Mar 8 12:21:32 PM      api_kwargs=api_kwargs,
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/_bot.py", line 331, in decorator
Mar 8 12:21:32 PM      result = await func(*args, **kwargs)  # skipcq: PYL-E1102
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/_bot.py", line 3517, in get_updates
Mar 8 12:21:32 PM      api_kwargs=api_kwargs,
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/_bot.py", line 425, in _post
Mar 8 12:21:32 PM      pool_timeout=pool_timeout,
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/ext/_extbot.py", line 312, in _do_post
Mar 8 12:21:32 PM      read_timeout=read_timeout,
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/_bot.py", line 456, in _do_post
Mar 8 12:21:32 PM      pool_timeout=pool_timeout,
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/request/_baserequest.py", line 172, in post
Mar 8 12:21:32 PM      pool_timeout=pool_timeout,
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/request/_baserequest.py", line 330, in _request_wrapper
Mar 8 12:21:32 PM      raise Conflict(message)
Mar 8 12:21:32 PM  telegram.error.Conflict: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running
Mar 8 12:21:32 PM  An error was raised and an uncaught error was raised while handling the error with an error_handler.
Mar 8 12:21:32 PM  Traceback (most recent call last):
Mar 8 12:21:32 PM    File "bot/bot.py", line 236, in error_handle
Mar 8 12:21:32 PM      await context.bot.send_message(update.effective_chat.id, message_chunk, parse_mode=ParseMode.HTML)
Mar 8 12:21:32 PM  AttributeError: 'NoneType' object has no attribute 'effective_chat'
Mar 8 12:21:32 PM
Mar 8 12:21:32 PM  During handling of the above exception, another exception occurred:
Mar 8 12:21:32 PM
Mar 8 12:21:32 PM  Traceback (most recent call last):
Mar 8 12:21:32 PM    File "/opt/render/project/src/.venv/lib/python3.7/site-packages/telegram/ext/_application.py", line 1617, in process_error
Mar 8 12:21:32 PM      await callback(update, context)
Mar 8 12:21:32 PM    File "bot/bot.py", line 238, in error_handle
Mar 8 12:21:32 PM      await context.bot.send_message(update.effective_chat.id, "Some error in error handler")
Mar 8 12:21:32 PM  AttributeError: 'NoneType' object has no attribute 'effective_chat'

@xawwnee how did you resolve this error? I have the same errors while building, can u help me please?

Though I am not using it anymore.
You can try modifying as following in (ln 233):
        # split text into multiple messages due to 4096 character limit
        message_chunk_size = 4000
        message_chunks = [message[i:i + message_chunk_size] for i in range(0, len(message), message_chunk_size)]
        for message_chunk in message_chunks:
            await context.bot.send_message(update.effective_chat.id, message_chunk, parse_mode=ParseMode.HTML)
    except:
        await context.bot.send_message(update.effective_chat.id, "Some error in error handler")

@xawwnee how did you resolve this error? I have the same errors while building, can u help me please?

This error means you use the same Telegram API key in different running services.
So you have to stop service and use different Telegram API key.
If you can't find the service, you can revoke the API key on botfather
Ref: https://stackoverflow.com/questions/69870914/conflict-terminated-by-other-getupdates-request-make-sure-that-only-one-bot-in


Atomic wallet integration

As a user, I can use Atomic wallet to buy, sell, atomically swap, and pay in BOA in order to use my coins.
Definition of Done:

[ ] I can send coins to another BOA holder
[ ] I can atomically swap BOA for BTC
[ ] I can atomically swap BOA for ETH

This will be postponed at a later phase as we moved to have our own wallet solution.


[Outrun-electric] vertical border face invisible

In outrun-electric, the vertical-border foreground has the same colour as the background, making a vertical split border invisible. A dark violet (#3f3863) would perhaps be more suitable.

@ianpan870102 can you show me a screenshot?

Sure thing. In both screenshots below, I'm splitting the scratch buffer vertically:
Before

After

I used the theme's base5 color, I don't know if that's alright.


Allow registering custom request-response protocols

Just like one can register notifications protocols, one should be able to register targeted request-response protocols.
I'm opening this issue to keep track of that feature.
cc'ing @mxinden @rphmeier as we discussed this in a meeting a couple of weeks ago (when the world was not on lockdown)

For what it's worth, this issue is low-priority to me, but if there's an urgent need I can probably open a properly-tested PR in a day or two.

We haven't had issues so far emulating request/response over notifications-based protocols, so I also don't view this as high-priority.

Can now be done after #6559
The major obstacle to this now is to design an API.

I briefly wanted to highlight that request-response protocols would show up in Grafana similar to this:

(one section like that per protocol)
Which is going to be very useful to figure out if things are working as expected.

In #6634, starting a request to a node we're not connected to immediately fails. However, after chatting with Rob, there is a need for a function that tries to dial the node if we happen to not be connected to it.

Reopening to address this comment:

In #6634, starting a request to a node we're not connected to immediately fails. However, after chatting with Rob, there is a need for a function that tries to dial the node if we happen to not be connected to it.

Note-keeping: the reason for being able to perform requests to nodes we're not connected to is because we are not necessarily guaranteed a peer slot on the target node.
If, instead, there exists a system that guarantees a peer slot, then this isn't needed.

Last comment addressed through https://github.com/paritytech/substrate/pull/8008
Closing


Fix recursion error for deep diagrams

When diagrams get too deep, composition will raise a RecursionError.
This PR fixes this by replacing the recursion call of Arrow.then by a for loop.

replaced by PR https://github.com/discopy/discopy/pull/142


Tabs content empty with chrome

I was testing your plugin on the demo size with chrome (newest version). Just resize the browser, then change a tab and you see the new tab empty.

It's hardly a browser issue,( especially a newest version, there can be problems with some old versions ), if you are talking about accordion mode, opening a blank tab, then if I understood propertly, that's an rendering error that occurred  in transition from tabs, to accordion, where transition animation hasn't disabled, (when tabs shifts to accordion, transition animation will be turned off, so that kind of stuff wouldn't happen), but on the first demo page, the one with controls previewer, it can happen sometime, because I had to "hack" the preview tab to include live preview of  all the options that are applied instantly as you change them. Check any other demo in same browser, and there should be no such problems.

a) Yep, but the rendering error only happens with chrome (maybe also in opera, who knows), on other browsers it's fine.
b) This happens also  if you click on the "just another tab" demo, same issue.
c) There's a fixed height in the main wrapper (like => http://goo.gl/q7RbJ3). If you resize the browser, the fixed height remains, and the overflow of the  is hidden. Maybe it would be better to set the height to "auto", 'cause a fixed height isn't really responsive.
d) There are also other minor bugs with this plugin, e.g. HERE transition between tabs is not running smoothly.
My way of thinking is:  "keep things simple but functional".
If people want something more, they could add it by themselves.

Wrong fixed height in main demo, is probably due to, like I mentioned, 'hacked' approach of producing that live previewer, and every other issue that shows on that page, is most probably caused by that. If same error shows on other examples, than it is a plugin bug. Height isn't fixed by default, it is produced by means of javascript that measures  the highest tab height and apply it to a parent container, every time window is resized, which actually makes it "responsive". It cannot be set to auto because it is holding absolutely positioned chilldren elements.
I will fix rendering errors when I find some time to release next version that will include few fixes and some additions.

Issues fixed in new version 1.2 release. Transition between tabs is now running smoothly and new tabs are not empty when resized.


Stacks test data

For the much anticipated Stacks module :wink:

@ewels. Random thought. Should I perhaps name this module stacks2? Theres maybe only 1/3 log files from Stacks v1 that are even remotely similar to v2.

Oops, saw this just as I merged. I think keep it all stacks, but subfolders by version number are helpful 👍

No problem. Don't worry, I have no plans on writing a module that support Stacks v1. 😀
I guess they haven't change the name of stacks,  I should at lease be very clear in the documentation about version is supported


feat: add google analytics

Add google analytics to mainnet.
How did you manage with vercelAnalytics on mainnet and testnet ? I need to give you a .env file

Illegal in Europe + bad web3 ethose ==> Close


member unsubscribing from newsletter erases their membership labels

member unsubscribing from newsletter erases their membership labels
ghost 3.40.5
apply label(s) to a member and have them unsubscribe from newsletter (by clicking on link in newsletter email, didn't test via portal)
-> label(s) have disappeared

I've reproduced this issue to confirm it. @os72 in future please use the issue template provided. Thanks!

Hey @os72! 👋🏻 We've just released 3.41.4 which contains the fix for this, so please update with Ghost-CLI 🙂

Thanks! I use a managed service so they control the upgrades. But I report whatever I find as a user :)


Transformers don't deploy with ModelMesh InferenceService in RawDeployment mode

/kind bug
What steps did you take and what happened:
When defining an InferenceService with the modelmesh annotation it's suppose to be able to handle transformers by delegating the reconciling of it to the kserve controller instead of the modelmesh serving one. One issue I'm hitting is that it is currently only working if the underlying deployment mode is Serverless and not RawDeployment. This appears to be only a problem of the logic "falling through" an if statement here: https://github.com/kserve/kserve/blob/master/pkg/controller/v1beta1/inferenceservice/components/transformer.go#L171
Since the inferenceService is using ModeMesh as it's deployment mode, it's not covered in the check for creating the service for the transformer. That seems to be a mistake and not intentional as there's no hard dependency to using serverless for modelmesh.
Instead the controller should fall back on the defaultDeploymentMode entry in the configmap to figure out which deployment mode should be used to create the transformer deployment and services.
What did you expect to happen:
Transformers should not try and create a knative service when using a ModelMesh predictor and KServe is deployed using RawDeployment mode.
What's the InferenceService yaml:
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  annotations:
    serving.kserve.io/deploymentMode: ModelMesh
  name: resnet
  namespace: kserve
spec:
  predictor:
    model:
      modelFormat:
        name: onnx
      name: ""
      storage:
        key: localMinIO
        path: resnet
  transformer:
    containers:
    - args:
      - --model_name
      - resnet
      - --predictor_protocol
      - grpc-v2
      command:
      - python
      - -m
      - custom_transformer.model_grpc
      image: custom-image-transformer-grpc:v0.1.5
      name: kserve-container
      ports:
      - containerPort: 8081
        name: h2c
        protocol: TCP
      resources:
        limits:
          cpu: "1"
          memory: 2Gi
        requests:
          cpu: "1"
          memory: 2Gi

Anything else you would like to add:
I've got a working fix locally that I will create a PR for and attach to this issue shortly.
Environment:

Istio Version: N/A
Knative Version: N/A
KServe Version: v0.12.0
Kubeflow version: N/A
Cloud Environment: kubernetes on prem
Minikube/Kind version: N/A
Kubernetes version: (use kubectl version): 1.28
OS (e.g. from /etc/os-release): rhel8

Cc @ckadner


Distribute s3 wait_objects

Feature or Bugfix

Feature

Detail

Modified the S3 wait_objects functions to distribute across Ray
Refactored current functions to make use of the thread pool definition

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: a7f74c3cc56bef7e7d6c83032aeb824b4c9870d7
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubLoadTests5656BB24-s6u9F3qN9oFy
Commit ID: a7f74c3cc56bef7e7d6c83032aeb824b4c9870d7
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: a7f74c3cc56bef7e7d6c83032aeb824b4c9870d7
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Due to some offline discussion regarding how suitable Ray is for this, I'm changing this CR to only include the refactor to reuse _ThreadPoolExecutor. From this point on, adding support for Ray merely involves replacing _ThreadPoolExecutor with _get_executor, and adding Ray annotations.

AWS CodeBuild CI Report

CodeBuild project: GitHubLoadTests5656BB24-s6u9F3qN9oFy
Commit ID: 4eeddefcd8280e142304243b6625608b5b0ff68d
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: 4eeddefcd8280e142304243b6625608b5b0ff68d
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 4eeddefcd8280e142304243b6625608b5b0ff68d
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: d69849a3d2f1d64016204ca6e07b603febd32fd4
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubLoadTests5656BB24-s6u9F3qN9oFy
Commit ID: d69849a3d2f1d64016204ca6e07b603febd32fd4
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: d69849a3d2f1d64016204ca6e07b603febd32fd4
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: a3aa719e79f7c6eaf6bf5d62084f69187ff8ec8b
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubLoadTests5656BB24-s6u9F3qN9oFy
Commit ID: a3aa719e79f7c6eaf6bf5d62084f69187ff8ec8b
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: a3aa719e79f7c6eaf6bf5d62084f69187ff8ec8b
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: cbdec692c89d48cfc259b5b2ff5a4f45ded66abc
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubLoadTests5656BB24-s6u9F3qN9oFy
Commit ID: cbdec692c89d48cfc259b5b2ff5a4f45ded66abc
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: cbdec692c89d48cfc259b5b2ff5a4f45ded66abc
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 9f70ab0999be13475df9e5aa5ed4ef218d5697f9
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubLoadTests5656BB24-s6u9F3qN9oFy
Commit ID: 9f70ab0999be13475df9e5aa5ed4ef218d5697f9
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: 9f70ab0999be13475df9e5aa5ed4ef218d5697f9
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Phalcon

Phalcon is a web framework implemented as a C extension offering high performance and lower resource consumption.
http://phalconphp.com/en/

Array to string conversion in app\config\services.php on line 57
please help me solve it

queued up


13: Add e2e integration tests

resolves #13

The docker image first needs to be updated to include ginkgo..

For the commit messages if you want to link to the issue you have to prefix it with GH-. Just the number is not a valid issue reference.


Have something changed in the last few months?

Comments have stopped working.
I never was hosting my own staticman and was using public staticman-net[bot].

https://github.com/yalov/yalov.github.io

It's recommended to use your own API instance in #317 by @alexwaibel.  The setup on Heroku free tier requires merely a personal account—no installation is needed: you may view https://hajekj.net/2020/04/15/staticman-setup-in-app-service/ or my illustrated version: https://github.com/pacollins/hugo-future-imperfect-slim/wiki/staticman.yml.
Successful examples:

mlsdpk/mlsdpk.github.io#2
VincentTam/TestStaticmanLab#95
VincentTam/beautiful-jekyll#/35


"react-hot-loader": "^4.0.0" breaks tabs and radio buttons

Hi
After swithching to "react-hot-loader": "^4.0.0" I cannot work in dev env with radio buttons and tabs.
Tabs are not visible.
Radio buttons I can see only as read only.

It's fixed if copy from git.
So we are waiting a new release.


Creating meeting-notes-apac.md for tracking APAC meeting

Description
Create a file meeting-notes-apac.md for tracking APAC meetings.
Outcome
Create a file meeting-notes-apac.md for tracking APAC meetings.
To-Do
Create a file meeting-notes-apac.md for tracking APAC meetings.
Code of Conduct

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

Comments
cc @leo

PR - https://github.com/cncf/tag-env-sustainability/pull/433


Add templating

Add templating
Current behavior
The app currently has two separate pages, the map page and the university list page. Right now, the map and university pages have different headers, accidentally. Templating will allow us to use a common page layout.
Suggested behavior

After improving speed on the back-end (see #36 ), we will remodel the front-end with templating.
We're considering:

Flask/Jinja if we want to template through Python. This could be the best option if we build a Python back-end. Jinja can be slow if functions are included in the templates.
Jekyll if we want to stick with GitHub Pages.
Vue.js or React Router for templating on the front-end with JavaScript. If templating with VueJS and building our own back-end API, we could pipe in our API to the front-end.

I have created Flask page templates, and will submit a pull request from the flaskifying branch once pull request #39 has been reviewed and accepted.

Can I do some nitpicking and recommend the creation of a new branch for templating? I am trying to avoid potential conflicts with both of us making edits within the same branch. If you've already started working in the branch, I will wait until you've submitted all your changes to make any new edits.

Sure thing @AbdouSeck . Should I make a new branch off of flaskifying or dev? Either way, I'll be sure to submit a pull request before merging.

@br3ndonland I would recommend making a branch from the dev branch after flaskifying has been merged. I just pushed minor edits to the flaskifying branch, so if you like, you can merge it to the dev branch before making your own branch. Sorry about the delay in getting back to you. I am also going to write unit tests for app.py and utilities.py tonight.
I will only be working from the flaskifying branch and using dev as a base.
Thanks,
Abdou

Sounds great @AbdouSeck . I'll branch off of dev after we merge in flaskifying from PR #39 .
It was great that you requested reviews on PR #39 . I was thinking we could let @jethridge13 merge PR #39 once he has a chance to test out the changes. It would be great to have his eyes on the new code as well. I'll follow up over Slack in the next day or two.

Templates added with merge of PR #40.


Add wait_for_deployment

Add support for wait_for_deployment variable. It has been added to the 2.5.0 AWS terraform provider.
https://github.com/terraform-providers/terraform-provider-aws/blob/master/CHANGELOG.md#250-april-05-2019

Sorry! Just fixed it.


Revert "Update README.md for sec"

Reverts wadhah101/GL5-2022-deadlines#3
@wadhah101 BI section was cut through

cc @medbensalah

Woops didn't notice


share_mnt not upgraded when upgrading rancher server from v2.4.0

Rancher server version - v2.4.0
Steps to reproduce the problem:
Fresh install of v2.4.0 ( or upgraded from any 2.3.x)
Create a RKE cluster ( or it can be an existing cluster from previous rancher server version).
Upgrade to 2.4.2-rc2.
After rancher server gets upgraded , notice that the cattle-cluster-agent and cattle-node-agent get upgraded successfully to rancher/rancher-agent:v2.4.1-rc2 but share-mnt fails to upgrade.
docker ps -a | grep agent
7731efa05499        rancher/rancher-agent                             "run.sh"                 16 minutes ago      Up 16 minutes                                   k8s_agent_cattle-node-agent-bxsn5_cattle-system_58726ef0-470b-4c80-8783-c19734eb6fdf_0
bcdf88d20f22        rancher/pause:3.1                                 "/pause"                 17 minutes ago      Up 17 minutes                                   k8s_POD_cattle-node-agent-bxsn5_cattle-system_58726ef0-470b-4c80-8783-c19734eb6fdf_0
f41d19c329ab        rancher/rancher-agent:v2.4.0                      "run.sh -- share-roo…"   26 minutes ago      Exited (0) 26 minutes ago                       share-mnt

Will be addressed by dropping share-mnt and update the logic to no longer rely on it: https://github.com/rancher/rancher/issues/25702

This only affects clusters that are being upgraded from v2.4.0 and will get upgraded when the cluster upgrades to a new k8s version

rancher/rancher:master-head bcc8261

We are not doing any cleanup on this container
Tested via resolution of #25702


1.0.0: added Makefile

Create Makefile and Release. See https://github.com/FS-make-simple/libsais/releases/tag/1.0.0

Thank you (спасибо)!


Update V1.9

Game was working perfectly till now, A prompt showed up to auto update to the latest of Re4Tweaks. Accepted it. Restart, now this happened

cant play the game anymore pass the Oversized "LOADING"

After the update, after loading a save the screen goes black, audio and inputs still works, but the screen is just black,

Do you have a fully updated version of the RE4 HD Project installed? Can you check if the files doorse012.xsb and doorse012.xwb exist in your \Resident Evil 4\BIO4\snd directory?

Yes, recently bought the game on monday/ or last saturday. Downloaded the
most recent version available in their official website and the re4 tweaks
(v1.8 at that time) game worked flawlessly until today, a prompt pop up for
the v1.9 accepted it. Game starts normaly, starting screen menu is normal
size but sub menu are huge Same as loading screen which will just hang and
cause the game to not respond.
On Wed, Mar 22, 2023, 9:13 AM Bruno Russi @.***> wrote:

Do you have a fully updated version of the RE4 HD Project installed? Can
you check if the files doorse012.xsb and doorse012.xwb exist in your \Resident
Evil 4\BIO4\snd directory?
—
Reply to this email directly, view it on GitHub
https://github.com/nipkownix/re4_tweaks/issues/505#issuecomment-1478787668,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATKFXZ5AUZNCKRGNBDRDI53W5JG2RANCNFSM6AAAAAAWDFKV7U
.
You are receiving this because you authored the thread.Message ID:
@.***>

Have you checked the two files I mentioned?

I'm glad it is working now. Thanks for letting me know!


Provide alternatives to BuildCacheEntryWriter#writeTo API

Expected Behavior
BuildCacheEntryWriter#writeTo does not play well with APIs like Amazon S3 and Google Cloud Storage.
The problem is when dealing with large files, APIs want to implement partial uploads + retries.
When that happens, writeTo does not really work (there's no way to ask Gradle to retry wring a part of the entry)
Do you think it might be possible to expose BuildCacheEntryWriter#getFile?
Both S3 and GCS can upload an object from a file natively:
https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/AmazonS3.html#putObject-java.lang.String-java.lang.String-java.io.File-
https://googleapis.dev/java/google-cloud-storage/latest/com/google/cloud/storage/Storage.html#createFrom-com.google.cloud.storage.BlobInfo-java.nio.file.Path-com.google.cloud.storage.Storage.BlobWriteOption...-
https://github.com/kordamp/oci-gradle-build-cache-plugin/blob/dd7e6bf4e7394ba196b7dcb1ccbc8b9e0ab0e3f9/src/main/groovy/org/kordamp/gradle/plugin/buildcache/OCIBuildCacheService.groovy#L91-L101
An alternative option could be to expose chunking API so the clients can request ByteBuffer starting at offset X with length Y or something like that.
Current Behavior
Currently, the only way to store a build cache entry is to use writeTo(OutputStream) which results in awkward implementations, and OutOfMemory errors when the implementation buffers the file.
Context
See https://github.com/myniva/gradle-s3-build-cache/issues/26

We are thinking about some improvements around the build cache protocol, but nothing is planned at this point.


why jacob of depth is set to ones?

Thanks for your excellent work!
I have a little confusion about the calculation of jacob of depth below:
https://github.com/princeton-vl/DROID-SLAM/blob/92027b31c06f42e4471706bbb46e7eb3cb3a5dd0/droid_slam/geom/projective_ops.py#L34
why the jacob is set to ones, I think it might be a function of intrinsics and image coordinates.
Please help me figure it out, thank you very much in advance!

According to my understanding, the 3D coordinates are set to:
X=[(u-cx)/fx, (v-cy)/fy, 1, disp]
so differential with respect to disp is:
[0,0,0,1]
However, you seem to set it to [1,1,1,1].


upgrade-lb-explorer

Change loopback-explorer to loopback-component-explorer

@crandmck Hi Rand, I did lb-explorer related changes according to your guideline, can you review it? Thanks!

LGTM.  I ran the branch, but I don't have Google or FaceBook client IDs, so I didn't test that part, but I'm assuming it works.

LGTM!

Connect to https://github.com/strongloop/loopback-example-xamarin/issues/1


[Backport release-23.11] signal-desktop: 7.0.0 -> 7.2.1, -beta: 6.44.0-beta.1 -> 7.3.0-beta.1

Description of changes
Backports #293952 manually to release-23.11 branch

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixosTests.signal-desktop hangs at waiting for File Edit View Window Help to appear on screen, but this is also the case on release-23.11: https://hydra.nixos.org/build/254321770. I tested it manually and it seems to open successfully.


fix: throw more useful error if OAuthClientCredentialsApiClient fails to authenticate

Fixes #52

:tada: This PR is included in version 1.1.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update Owners

I think this is long overdue. WDYT?

This change is

With great power comes great responsibility!? :)

/approve

/lgtm
/approve


Fix msgpack issues and warnings

This PR addresses a couple of issues relating to the new msgpack codec (codec ID "msgpack2") being introduced in numcodecs version 0.6.0:

The encoding argument to packb and unpackb is being deprecated and is generating a PendingDeprecationWarning. The arguments have been changed as recommended to use raw=False instead, with raw=True being available as an option. Two other relevant options, use_bin_type and use_single_float have also been surfaced from msgpack. Resolves #85.
Round-trip encoding/decoding of an array of Python bytes objects was broken in the legacy msgpack codec, and works correctly in the new msgpack2 codec with new arguments set to defaults. Some tests have been added to verify the behaviour of old and new codecs with respect to both bytes and str (unicode) objects. This resolves an issue in zarr (https://github.com/zarr-developers/zarr/issues/324) where the tests currently expect broken behaviour from msgpack for an array of bytes objects.

N.B., because default values for some arguments being passed through to msgpack in the newer codec have changed in this PR, the fixture for the "msgpack2" codec has been regenerated. This is OK because the codec has not actually been released yet.
For reference, the initial work to add the new msgpack2 codec was done in PR #77.
TODO:

[ ] Unit tests and/or doctests in docstrings
[ ] tox -e py37 passes locally
[ ] tox -e py27 passes locally
[ ] Docstrings and API docs for any new/modified user-facing classes and functions
[ ] Changes documented in docs/release.rst
[ ] tox -e docs passes locally
[x] AppVeyor and Travis CI passes
[x] Test coverage to 100% (Coveralls passes)

Any objections @zarr-developers/core-devs?

Thanks @jakirkham.


Add repository consolidation

Consolidating jobs using the same repository into single build directory
The idea here is that with large repositories, we waste a lot of space on our nodes when we have numerous pipelines. This is because the agent creates build dirs based on the pipeline-slug. We could save a lot of space and not need to limit the amount of pipelines we make by having all builds of the same repo use the same build directory
This would be really helpful for our org so I imagine other teams with large repositories could benefit as well
Things I'd like feedback on

[ ] Language: specifically around "Consolidate all builds using identical repositories into a single build directory" being the language convention to use for this functionality
[ ] Hashing: This approach ensures the dir is alphanumeric, but certainly obscures what the build dir is. Thoughts? If this is the right approach we could also move it into utils.
[ ] Protected Env: I currently have this as a protected ENV variable, I think this is the right approach so it must be configured at the agent level. Open to discussion though.

Next steps

If we get sign off on this, I'd of course like to add tests.

@pda Would you mind reviewing this?

Sorry it's taken us so long to get back to you @pyasi! My main concern with this is that it limits concurrent access by lots of pipelines to the one checkout 🤔
Given that the git-mirrors experiment uses a reference clone of a single repository folder, does that mitigate some of the concerns, or are there other factors?

@lox all pipelines using the same repo will use the same checkout, correct, but since it's still PATH/TO/BUILDS_DIR/BUILDKITE_AGENT-1/repo wouldn't there never be concurrent workloads running on the same checkout dir? Unless the a single agent can run two jobs concurrently for multiple pipelines.
The git-mirrors experiment doesn't quite solve this because it still requires a "clone" of the repo for each pipeline. So let's say you have a 1 gig repo with 10 pipelines, that adds up quite fast.
We've solved this internally through a hook so no rush on this. But let me know if the above makes sense as a response to the concurrency issue you spotted.

The git-mirrors experiment doesn't quite solve this because it still requires a "clone" of the repo for each pipeline. So let's say you have a 1 gig repo with 10 pipelines, that adds up quite fast.

Interesting, you have a repo that is 1gb checkout out? (e.g not including the git history)

We used reference repos and would pull from them instead of from remote. This was to reduce traffic on GHE and speed up clone times, so it's not identical to the git-mirrors experiment. I vaguely remember looking into the experiment a while back and it wasn't solving our primary problem IIRC. I'd have to dig up the reason again though.


firebase_analytics version solving failed.

Running "flutter packages get" in FlutterWithFirebase...
The current Dart SDK version is 2.1.0-dev.9.4.flutter-f9ebf21297.
Because flutfire depends on firebase_analytics >=0.0.2 <0.3.0 which requires SDK version >=1.8.0 <2.0.0, version solving failed.
pub get failed (1)

Please consider asking support questions in one of the other channels listed at http://flutter.io/support .
This just means your pubspec.yaml contains a dependency that is incompatible with another dependency or the Dart version you are using.
Recent firebase_analytics version is 1.0.6, you project depends on 0.0.2 which is not compatible with Flutter/Dart2 (requires SDK version >=1.8.0 <2.0.0).
Please consider asking support questions in one of the other channels listed at http://flutter.io/support .


Update sbt, scripted-plugin to 1.10.6

About this PR
📦 Updates

org.scala-sbt:sbt
org.scala-sbt:scripted-plugin

from 1.5.8 to 1.10.6
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-sbt" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, version-scheme:early-semver, commit-count:1

Superseded by #98.