cmd/list.rb: fix brew ls in verbose mode

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[ ] Have you successfully run brew tests with your changes locally?

Related issue: Homebrew/brew#6445
When HOMEBREW_VERBOSE is set, brew ls passes -v and --verbose
arguments to the system's ls command. This fails with:
ls: illegal option -- -

usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]

Error: Failure while executing; ls -v --verbose /Users/username/homebrew/Cellar exited with 1.

To circumvent this issue, we filter out -v and --verbose flags from the list of flags passed to ls.
There is probably a smarter way to do that... but looking at the Homebrew tests it looks like Homebrew/brew can't mutate Homebrew.args once they have been parsed.

@MikeMcQuaid, I see that you reverted the commit that introduced this bug, so I suggest we close this PR as I am sure @GauthamGoli will check that brew ls works in verbose mode in his next attempt.

I implemented your suggestions anyway -- I'm not sure how
that change to cli/parser.rb indeed turns out to be unnecessary...

Both -d and -v are legit options/flags for ls, so I suggest we pass long versions only and filter out --debug and --verbose.

ls -d -v is a valid command, but -d lists directory entries and -v sorts version numbers in text, which I think is unrelated to --debug and --verbose in the homebrew context. I think none of those flags should be passed to ls from homebrew.

-v does something else on a Mac but I agree with filtering out -v and -d.
If we decide that -v and -d should not be passed to ls... and given that --verbose and --debug are nor supported by ls, whould we remove switch :verbose and switch :debug from cmd/list.rb altogether?

If we decide that -v and -d should not be passed to ls and given that --verbose and --debug are not supported by ls, should we remove switch :verbose and switch :debug from cmd/list.rb altogether?

They should still be acceptable options because they control Homebrew's behaviour but we should strip them out.

We can merge this once #6479 gets reviewed and merged.

~We can merge this once #6479 gets reviewed and merged.~
Or I think it makes sense to release this in #6479 itself for the PR to be complete and correct.


update compute client to new api version

Hi @DeepakRajendranMsft, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, AZPRBOT;


Session issue

Hi! I have this issue, I dont know what's cause an issue.
request to the redirect_uri_path but there's no session state found
Also, intersting, when i set:
lua_code_cache off;
set $session_secret 623q4hR325t36VsCD3g567922IC0073T;

I get
unhandled request to the redirect_uri: /example/url

Or here, I did

  local err

  local session = require("resty.session").start()

then restart nginx and did:

  local err

  local session = require("resty.session").open()

I get
unhandled request to the redirect_uri: /example/url

You're not supposed to call resty.session directly, that is handled for you by including something like:
          local res, err = require("resty.openidc").authenticate(opts)

it would be good to show the error/access log as to see what the unhandled request looks like

I didn't call it directly, only change in openidc.lua, for test purpose. I think that session store or file not creating.

@alexandrst88 does it only happen when you have lua_code_cache off;

Not really, when my location match redirect_uri. When I changed location to / it's starts working fine.

I have this issue as well. Im using the basic Google OIDC example.
Im not a lua pro, do I just need to create a function to handle the oidc redirect uri, or is there a method already baked in for doing this ?

openidc is supposed to handle the redirect_uri location internally inside of oidc.authenticate.
@noqcks what exactly do you see as "the issue"? If you are using a recent version of openidc and you set nginx' log level to debug we should be able get some information that helps us tracking down what is happening on your side.

The redirect uri is a "vanity url", a special handler processed by lua-resty-openidc. You should not access it directly.


[FEATURE]-Improve Format of Joinmap Reporting

Is your feature request related to a problem? Please describe.
The joinmap reporting format is less than ideal for a human to parse.
Describe the solution you'd like
The data reporting should be arranged to front load data that has less variable length, and those fields should be a fixed width to align pipe characters.  Description Data should be the last piece of data reported because of the high variability in length
Describe alternatives you've considered
Ignoring the reportjoinmap completely, but that relies on people documenting their plugins.
Additional context
Perhaps we need to subvert the Debug.Console method here, because it provides additional context that manifests and uesless noise in the context of looking at the data you explicitly requested - perhaps we can leave the current "as is" and add some options to the command.

I've since implemented GetJoinmapMarkdown as an alternative to this that saves joinmap data to a markdown file on the processor that can be easily parsed, and even be used for rudimentary documentation of the joins.

I was able to leverage the existing GetJoinmapMarkdown implementation to clean up joinmap printing.
Here's some example output;

Merged to dev - marking closed


fastlane

Description
Fastlane
Tests

[x] can build and deploy to ipad

Documentation
n/a
Primary reviewers
If your change will take a long time to review, you can name at most two primary reviewers who are ultimately responsible for reviewing this request. @ mention them.

Validated without logging into master apple account 👍
Had to drive-by remove some packages from manifest


Create IPC and UTS namespace for containers

Unshare IPC and UTS by default for every container process.

#Fies #790


Requesting Flutter Feature for Speech to Text for windows Desktop

I am using Flutter to write a desktop application for Windows 10 and I am using speech to text module in the project but it's giving me this error.
I think the native method for speech to text is not available, any help is appreciated.
MissingPluginException (MissingPluginException(No implementation found for method initialize on channel plugin.csdcorp.com/speech_to_text))

You'll need to contact the developer of that plugin to request that they add Windows support; the Flutter project does not control third-party plugins.

Thanks for responding. I will contact the third-party plugin provider.


server::Builder stream/connection window size methods work by reference

All of the other setters on the builder type operate by-value, but http2_initial_connection_window_size and http2_initial_stream_window size work by-reference.

Ah man, that's an unfortunate mistake. I'll assign this breaking change to be done in 0.13.

As an interim, we could add new methods that are by-value, with an underscore prefix... 🤷♂


Improve CI Caching

Generally speaking, buildkit cache export/import is pretty limiting because it's not "shared": every export cache overwrites the previous one, therefore CI runs are overwriting each other's cache. Persistent cache dirs are not part of the cache. And caching outside of GHA requires setting up some infrastructure (e.g. pointing to a registry).
This is a broad issue, keeping track of CI caching related issues:

Using the GitHub Action, cache should work out of the box nicely

#1345
#2059
Ideally, without having to define a scope manually (can dagger or the GHA figure out a default scope?)
And without having to use crazy-max/ghaction-github-runtime (dagger GHA should do this? /cc @crazy-max)

We need to find a path forward to support other CIs

NOTE: The above issues are pretty narrow in scope. However, taking a step back, we could think of something more drastic to overhaul the caching sub-system.
/cc @sipsma

I have A LOT of thoughts here, many of which are intertwined given the connectedness of the problems. Starting for now with a brain dump just to get them out and see what thoughts others have. This will in time require a more organized design process given both its complexity and that it probably involves lots of collaboration with Buildkit.

Supporting other CIs:

Pluggable cache backends - One idea I brought up with @aluzzardi previously was to make cache export pluggable by adding support to Buildkit for exporting/importing remote cache using user-specified container images that serve an API to the buildkit daemon. This is essentially the same concept as LLB frontends but applied to the cache backend.

This offers a lot of flexibility and potentially close-to-best-case performance. Its main downside is it will take a while to design and implement.

Using local or registry exports as a proxy - The idea here to use either local or registry cache exports as the universal mechanism for plugging into some other cache backend.

E.g. a local dir can be marked as a GHA cache dir (and I'm sure similar concepts exist in other CI systems). This, as noted in the discussion, has performance problems currently. Even if we improve those, this solution inherently has the overhead of putting an extra hop (local dir) between Buildkit and the actual backend where data is actually stored. TBD at what scale that overhead becomes a true bottleneck. Use of a network filesystem partially addresses this, but those add lots of complexity and are likely not available in every CI system.
The idea of using a registry is intriguing too. In theory, you could deploy a registry local to the buildkit daemon (like a sidecar container), but the registry is some implementation that just proxies everything to another backend. I think I've heard of such things before, but have not investigated yet.

Persisting cache mounts:
To start with, Tonis's comment here is worth considering. Basically, most of the use cases for cache mounts are with downloaded package artifacts. In that case, is exporting them to a remote place and then re-downloading them actually faster than just re-downloading them from their original source (often a CDN, which is essentially a network cache)? It obviously depends on the use case, sometimes yes sometimes no. One compelling vote for yes in a particular case is here.

Explicitly converting cache mounts contents to layers - The workaround Tonis suggests in the comment linked above (adding build steps that explicitly tar and untar the cache contents, essentially converting them to layers) might unblock this case for Dagger. We are an abstraction above Buildkit, so we can potentially hide the details of packing/unpacking the cache from users.

This could provide a relatively quick solution to the problem. Main downside is that it has bad performance in many cases due to duplication of data, sometimes to the point where the overhead exceeds the performance benefits of the cache. There may be room for Buildkit to optimize this though, worth thinking about more.

The proposed mechanism for providing drivers that back cache mounts -  The examples there are drivers for a "docker volume" and a "bind mount" driver, but in theory more could be added.

The "driver model" is intriguingly similar to the proposal for pluggable cache backends above, though the interfaces are so different (cache backend imports/exports layer tarballs, cache mounts just provides filesystem mount points). It's also similar to the "use local export as a proxy" option mention above for supporting different CIs, e.g. we could use the "bind mount" driver to map the Buildkit cache mount to a GHA cache dir. These similarities make me wonder if there's a better way of unifying these problems.
One alternative idea might be to have a driver model that supports conversion of cache mount filesystems to layers. This allows you to plug cache mounts into the remote cache systems in a modular way. There would be a "dumb" driver that just converts the whole directory to a layer, but also smarter drivers that optimize layers for deduplication, or even use specialized knowledge of the layout (i.e. go cache dir, npm package dir, etc.) to create layers efficiently. This changes the interface enough that it could even just be combined with the idea of cache backends described above.

Merging Package DAGs - Another approach would be to solve the use case for combining package artifacts via MergeOp instead of cache mounts. Namely, MergeOp allows you to combine filesystem states together highly efficiently (i.e. hardlink trees). Instead of dumping package artifacts into a cache mount, builds can convert the package DAG into an LLB state per package, which then get combined together using MergeOp.

The advantage here is that this integrates with remote cache export and Buildkit's caching mechanisms in general seamlessly, so our solutions to the other problems (e.g. of supporting different CI backends) benefit this use case too. It also works better for use cases where parts of the cache need to be included in final "runtime" images (e.g. interpreted languages like js or python where you download packages and then include them at runtime too, shared object libraries, etc.)
The major downside is that this would need to be implemented per package system. I.e. you'd write a frontend that can convert an npm package.json to an LLB DAG that uses mergeop to combine everything together, but then you'd have to write another one for each other package manager.
Additionally, while I've only ever seen cache mounts used to store package artifacts, in theory the concept is more general and some use cases for it probably don't translate to mergeop

Additive caches (this problem I've thought the least about so far, needs fleshing out)

The current model used by Buildkit to export cache is not that far away from supporting this. I started working on Buildkit long after all this was added so I don't know the reasoning of the design well, but I have a vague memory that the main reason additive caching hadn't been done initially was just that there would be no Buildkit mechanism to manage the cache and it would grow forever. Need to confirm with Tonis though.

If that is the only issue, it's definitely something that we could address. It might also fit in well the idea of pluggable cache backends; we could add cache management features (like querying what's there, pruning, etc.) to the cache backend API.

I think the solution in #2120 is promising too, but I haven't had a chance yet to investigate more on how it can be generalized

I'll just add as a final note that another approach that potentially solves all of these problems at once is to find a way to make the Buildkit worker cache distributed (basically, share snapshotter and content store state at the lowest level rather than share cache via exports on the top level). There is some interesting preliminary work in this space involving distributed containerd content stores, but this would require much much more investigation.

One more addendum thought on the problem of wanting to share cache between CI runs. A relatively quick option that would require little to no changes to Buildkit would be to just cache the entirety of its state (i.e. /var/lib/buildkit) after the build is finished and Buildkit has shutdown. This obviously only works when Buildkit is being used by a single build at a time, but I think that's true of many CI cases (please correct me if wrong).
One issue here is that you might end up with a lot of duplication between packed data in the content store and unpacked snapshots. I suspect it could be fairly straightforward to add support to Buildkit's prune command to address this and allow you to trim the cached state to what you want before it shuts down though.
This is not exactly beautiful but it might be worth consideration as a stopgap given its simplicity relative to many other options.

Thank you @sipsma, really appreciate all the context!
There's a lot to unpack here, added some ideas/feedback
Supporting other CIs
Pluggable cache backends

Pluggable cache backends - One idea I brought up with @aluzzardi previously was to make cache export pluggable by adding support to Buildkit for exporting/importing remote cache using user-specified container images that serve an API to the buildkit daemon. This is essentially the same concept as LLB frontends but applied to the cache backend.

I love this idea. Not sure how big of an effort it is (I suspect quite a bit)
Local cache

Using local or registry exports as a proxy - https://github.com/dagger/dagger/discussions/1875 to use either local or registry cache exports as the universal mechanism for plugging into some other cache backend.

Did some testing here https://github.com/dagger/dagger/discussions/1875#discussioncomment-2445460, and it appears there's a huge overhead in using local exports.
I'm guessing it's because with registry, only the manifest plus modified layers get pushed, whereas with local it's a full blown export each time.

E.g. a local dir can be marked as a GHA cache dir

Another downside is in addition to paying the local export overhead, we'd pay the GHA cache dir import/export overhead every time.
Even if nothing changed (or just a couple of layers), we'd have to download every single blob for buildkit to say "cached"
Compared to registry which only requires downloading the manifest and then lazily pulling in only inputs for the changed nodes (at least, that's how I assume it works)
To put it in perspective, if we take our own CI plan, if you change something irrelevant (e.g. README.md), we'd be pulling 800MB of local cache, running dagger do, nothing happens, exporting back the cache (~30 seconds), and then uploading it back to GHA cache.
Registry Backend

The idea of using a registry is intriguing too. In theory, you could deploy a registry local to the buildkit daemon (like a sidecar container), but the registry is some implementation that just proxies everything to another backend.

Yeah that's definitely intriguing. It's more or less an alternative to the "pluggable cache backends" idea above, except instead of implementing it at the buildkit level, we'd implement it at the registry level.
Persisting cache mounts

To start with, Tonis's comment https://github.com/docker/buildx/issues/244#issuecomment-602750160 is worth considering. [...] In that case, is exporting them to a remote place and then re-downloading them actually faster than just re-downloading them from their original source

That's an interesting point of view for sure. It's true that many times, it's probably cheaper to just re-download. And perhaps a solution would be to "restrict" (e.g. through documentation / best practices) cache mounts to dependency downloading only.
Sometimes though, we've been using cache mounts for more than downloading. For instance, our go package uses a cache mount for build caching ($GOCACHE) -- e.g.  if a single go file changed, do not recompile all packages and dependencies.
I'm not sure how we could achieve the same result without cache mounts since any change in the code would invalidate the layer containing the cache.
The tricky part is how to "decouple" the inputs. Taking go as an example again, for go mod caching we'd need to only use go.mod / go.sum as inputs for the layer (not to invalidate the cache unless those files changed). For go build cache I don't know.
I think we need to take the time to profile how we're actually using the different types of cache and what we need from them. yarn is another interesting example where there's the yarn cache (CDN like) and then node_modules (which depends on package.json and yarn.lock -- pretty expensive to re-generate).
Still need some time to think through this :)
Buildkit State Caching

A relatively quick option that would require little to no changes to Buildkit would be to just cache the entirety of its state (i.e. /var/lib/buildkit) after the build is finished and Buildkit has shutdown. This obviously only works when Buildkit is being used by a single build at a time, but I think that's true of many CI cases (please correct me if wrong).

Thought about that in the past, however I think there's two pretty big downsides:

Requires to download the entire state before proceeding (similar to the "local dir" downside above)

Concurrency & Merging: For instance on dagger/dagger, there's one buildkit instance running per PR and one for main

To make this work, I guess we'd have to have a unique state per PR which means every PR starts from scratch
Similar issue as #2059, except with --cache-from we can merge multiple "states" together (whereas we can't merge two /var/lib/buildkit together, I think?)

Thank you for all those information! I'm actively working so may I can share my point of view

The idea of using a registry is intriguing too. In theory, you could deploy a registry local to the buildkit daemon (like a sidecar container), but the registry is some implementation that just proxies everything to another backend. I think I've heard of such things before, but have not investigated yet.

That's definitely a good idea but I'm curious how we could manage it in a CI context:

I'm not sure we can run a "sidecare registry" in GitHub action, so the user will need to provide his own so cache will not work out of the box.
Should we take advantage of GitHub package to store cache? Or deploy our own registry infrastructure shared by everyone so it's always available even in local?

On the other side, I think using a registry is the best way to ensure availability and performances are far more better than with local storage (as Andrea explained)

I think the solution in https://github.com/dagger/dagger/pull/2120 is promising too, but I haven't had a chance yet to investigate more on how it can be generalized

It's basically the same as your merging idea but with a lot of limitation because it's done manually in the CI.
I started to investigate and the problem is : how being CI agnostic?
With GitHub we can use PR number, but what about GitLab CI or Tekton?
That's why I fall back in the registry option, that could be agnostic and the manifest take care of referencing layers.

A relatively quick option that would require little to no changes to Buildkit would be to just cache the entirety of its state (i.e. /var/lib/buildkit) after the build is finished and Buildkit has shutdown. This obviously only works when Buildkit is being used by a single build at a time, but I think that's true of many CI cases (please correct me if wrong).

I thought it was a good solution when I start working on cache, but it's too slow and not scalable.
In my opinion, it would be worth to host your own Buildkit engine and share it in the CI  (like @gerhard did) than that.
And Andrea is right, it would be painful to merge /var/lib/buildkit, worth to create our own system.
But if I understand well, the main issue there is : https://github.com/dagger/dagger/issues/1345
Even with a registry or a new solution, since this issue exist, we will not be able to persist cache mount so all installation will not be cached and it will invalidate further steps? (Need a confirmation)
Something I do not understand is that in local with a simple dagger plan to build a go project : #CacheDir operation are exported in cache.
No cache
# With a clean buildkit daemon
dagger do build --log-level debug --log-format plain
0.92s user 0.42s system 5% cpu 24.393 total

Build log
12:30PM DBG actions.build.container._exec |
12:30PM DBG actions.build.container._exec | #5 Exec ["go", "build", "-v", "-tags", "", "-ldflags", "", "-o", "/output/", "."]
12:30PM DBG actions.build.container._exec | #5 sha256:d7f9b60bf47683f11a912d4cee73b82c168d5af48eadf07ac345fe721f10eb4c
12:30PM INF actions.build.container._exec | #5 0.061 go: downloading github.com/...
12:30PM DBG actions.build.container._exec | #5 DONE 2.3s

Import local cache
# With a clean buildkit daemon
time dagger do build --cache-to type=local,mode=max,dest=storage --cache-from type=local,src=storage
...
0.89s user 0.39s system 13% cpu 9.364 total

Build log
12:26PM DBG actions.build.container._exec |
12:26PM DBG actions.build.container._exec | #6 Exec ["go", "build", "-v", "-tags", "", "-ldflags", "", "-o", "/output/", "."]
12:26PM DBG actions.build.container._exec | #6 sha256:2efc91a4ce7f06f98667d788cff651de31741e412025c143526698d295c9d145
12:26PM DBG actions.build.container._exec | #6 CACHED

Why it's cached since go.#Build use core.#CacheDir, it should not be saved according to https://github.com/dagger/dagger/issues/1345?

Thank you for all those information! I'm actively working so may I can share my point of view

The idea of using a registry is intriguing too. In theory, you could deploy a registry local to the buildkit daemon (like a sidecar container), but the registry is some implementation that just proxies everything to another backend. I think I've heard of such things before, but have not investigated yet.

That's definitely a good idea but I'm curious how we could manage it in a CI context:

I'm not sure we can run a "sidecare registry" in GitHub action, so the user will need to provide his own so cache will not work out of the box.
Should we take advantage of GitHub package to store cache? Or deploy our own registry infrastructure shared by everyone so it's always available even in local?

On the other side, I think using a registry is the best way to ensure availability and performances are far more better than with local storage (as Andrea explained)

I think the solution in https://github.com/dagger/dagger/pull/2120 is promising too, but I haven't had a chance yet to investigate more on how it can be generalized

It's basically the same as your merging idea but with a lot of limitation because it's done manually in the CI.
I started to investigate and the problem is : how being CI agnostic?
With GitHub we can use PR number, but what about GitLab CI or Tekton?
That's why I fall back in the registry option, that could be agnostic and the manifest take care of referencing layers.

A relatively quick option that would require little to no changes to Buildkit would be to just cache the entirety of its state (i.e. /var/lib/buildkit) after the build is finished and Buildkit has shutdown. This obviously only works when Buildkit is being used by a single build at a time, but I think that's true of many CI cases (please correct me if wrong).

I thought it was a good solution when I start working on cache, but it's too slow and not scalable.
In my opinion, it would be worth to host your own Buildkit engine and share it in the CI  (like @gerhard did) than that.
And Andrea is right, it would be painful to merge /var/lib/buildkit, worth to create our own system.
But if I understand well, the main issue there is : https://github.com/dagger/dagger/issues/1345
Even with a registry or a new solution, since this issue exist, we will not be able to persist cache mount so all installation will not be cached and it will invalidate further steps? (Need a confirmation)
Something I do not understand is that in local with a simple dagger plan to build a go project : #CacheDir operation are exported in cache.
No cache
# With a clean buildkit daemon
dagger do build --log-level debug --log-format plain
0.92s user 0.42s system 5% cpu 24.393 total

Build log
12:30PM DBG actions.build.container._exec |
12:30PM DBG actions.build.container._exec | #5 Exec ["go", "build", "-v", "-tags", "", "-ldflags", "", "-o", "/output/", "."]
12:30PM DBG actions.build.container._exec | #5 sha256:d7f9b60bf47683f11a912d4cee73b82c168d5af48eadf07ac345fe721f10eb4c
12:30PM INF actions.build.container._exec | #5 0.061 go: downloading github.com/...
12:30PM DBG actions.build.container._exec | #5 DONE 2.3s

Import local cache
# With a clean buildkit daemon
time dagger do build --cache-to type=local,mode=max,dest=storage --cache-from type=local,src=storage
...
0.89s user 0.39s system 13% cpu 9.364 total

Build log
12:26PM DBG actions.build.container._exec |
12:26PM DBG actions.build.container._exec | #6 Exec ["go", "build", "-v", "-tags", "", "-ldflags", "", "-o", "/output/", "."]
12:26PM DBG actions.build.container._exec | #6 sha256:2efc91a4ce7f06f98667d788cff651de31741e412025c143526698d295c9d145
12:26PM DBG actions.build.container._exec | #6 CACHED

Why it's cached since go.#Build use core.#CacheDir, it should not be saved according to https://github.com/dagger/dagger/issues/1345?

I got back to looking into this more tonight. Started looking through our CI in depth to get a handle on everything we're doing, started playing around with runs locally and in CI to see what might make sense to cache and what not, etc.
My main thought is that there's just a lot of areas where it's not clear whether remotely caching data will provide benefit or not, and the only way to get answers will be to run experiments and gather data. This is going to require adding tooling for summarizing timing information (i.e. how long did this vertex take to run vs. how long did it take to upload and download its cached result) and for orchestrating complex workflows (i.e. running multiple buildkit daemons, exchanging cache between them).

The risk is obviously that making tooling like this can become its own rabbit hole, so we'll need to build it iteratively, biased towards quick value. I have an idea on a relatively easy path to orchestrating complex workflows here. Timing information I haven't dived into yet, but given Buildkit's support for tracing I'm sure we can find some open source tools to help us out here.

My immediate next steps are:

Continue getting a handle on everything our CI does and catalogue all the different things that could be remotely cached. I started tonight with just the Build workflow (and the associated actions), which is a good start but ultimately very simple (though still raises plenty of questions around go mod cache and go build cache). I suspect the integration tests will have a lot more to look into.

Along the way, if I see any opportunities for caching that are just obviously beneficial and straightforward, I'll implement them.

Look into tooling on gathering timing data and other information we'll need to start making actual decisions about what caching is worth improving. I just want something 1 step better than my current approach of running the build in plain progress mode and scrolling through the output to find how long each step ran :-). I'll start with tools built around tracing; I'm very open to suggestions here as I don't have a ton of prior experience with them.

Getting back on some comments:

Concurrency & Merging: For instance on dagger/dagger, there's one buildkit instance running per PR and one for main

Ah okay, yeah the use case is different than I was thinking. Any sort of merging is out of the question for this approach so we can forget it.

Sometimes though, we've been using cache mounts for more than downloading. For instance, our go package uses a cache mount for build caching ($GOCACHE) -- e.g. if a single go file changed, do not recompile all packages and dependencies.

Yeah these are the types of use cases that I think have the most potential for being beneficial when it comes to using remote caches: things that weren't just downloaded in the first place and have a very high ratio of time to create to  compressed file size (i.e. binaries, shared/static libs, etc.).
I've been refining my thoughts here a bit. There's two ways of approaching the caching of these artifacts. Let's say you are trying to build some binary by running make foo.

Cache Dir -  Just run make foo as an ExecOp with a Buildkit cache dir setup to hold all intermediate artifacts. This cache dir would be shared between every build and would be exported remotely for reimport by other builders (and CI runs).
DAG-ify - Break up the opaque make foo target into separate LLB vertices for each intermediate build step. I.e. in the Makefile it may turn out that make foo requires building 3 static libraries first before building the foo binary. Instead of implicitly doing that all in a single ExecOp, you could run 3 ExecOps for building the static libraries first and then combine those artifacts together and run the build for the make foo binary.

There are a lot of pros and cons to each approach. I started writing them out but it became a wall of text so I'll spare people now until my thoughts are more well formed and I have any data to back up my assertions. The gist is that the cache dir approach is simpler to setup but harder to manage, and the dag-ify approach is harder to setup but a much more robust solution once done.

I'm not sure we can run a "sidecare registry" in GitHub action, so the user will need to provide his own so cache will not work out of the box.

The idea here was to just use the registry API as a universal API that can be proxied into any number of backends, so we could run that implementation using the container engine that Buildkit is running in, as a container in Buildkit itself using the new AsyncExec I have a PR out for, or probably even in the dagger client binary itself. Not that I guarantee any of this is a remotely good idea, that was just the thought :-)

Something I do not understand is that in local with a simple dagger plan to build a go project : #CacheDir operation are exported in cache.

What's happening there is that the result of the ExecOp has been cached, not the cache dir. When you imported the cache, Buildkit saw that it already had the result of the ExecOp and thus didn't not to run anything. If anything in the ExecOp definition (or one of its dependencies in the LLB DAG) had changed, then you wouldn't see the same cachedir contents as before (unless they were still in Buildkit's internal cache from a previous run).

Had some promising ideas about the problems here which have resulted in more concrete plans. I like these ideas because they don't require any upstream Buildkit changes, which makes it faster to get experimenting and potentially get useful features if the ideas pan out.

Cache Dir Export
New idea: run anAsyncExec with the shared cache dir mounted, put a daemon in there that handles the syncing of the cache dir with an external backend. For example, if we want to sync a cache mount with GHA, we'd start a daemon in an AsyncExec that watches the dir and syncs it with the cache backend via the GHA API. We can start the daemon at the very beginning of the build to start populating the cache and later block the dagger client on it flushing everything before exiting.
The best part of this is that, unlike my previous ideas, it should already work today with no upstream changes.
The second best part of this is the modularity of being able to easily add different implementations for different backends. We can have implementations not only for other CI systems and storage backends, but even stuff like continuous syncing with a dir local to the client (using mutagen for example) which unlocks some interesting possibilities...
Only downside is that getting "continuous two-way syncing" right can be much easier said than done, but I think we can start rudimentary, e.g. just synchronous one-way push/pull at the beginning and end of a build session, may not even need AsyncExec.

Scopes+Additive Caches on Any Backend
Was thinking about ways of making this seamless+generic so that users can just get this caching working nicely with whatever backend they want and not having to construct complicated cache-from and cache-to arguments themselves (or use wrapper scripts we provide). My current favorite idea is to support setting cache-from and cache-to via cue, so users can import pre-baked, reusable solutions. Not sure yet, but I think this could be another top-level field under Plan (i.e. a sibling to client and actions called something like cache).
An example implementation is one that sets up GHA cache with scopes similar to #2120. But others would achieve the same end effect using different backends. As another example, here's a possible recipe for getting additive caching working a generic registry backend:

Builds can export cache to a repository using a tag unique to them (e.g. pr number) but grouped with other tags using prefixes (i.e. dagger-ci-build-foobar, with -foobar being the unique id).
Then, to setup cache imports we can query the registry for all tags (ListTags seems to be in the APIs I checked) and filter using prefixes to find the ones we want to import (very similar to how GHA cache restore keys work)
This will need some way of automatically evicting and/or manually pruning cache so it doesn't grow forever
I will also need to do some research and experiments to see how buildkit does when importing a lot of cache sources, i.e. what's the scale at which it slows down and how easy/hard is it to fix.

The idea is that users would just specify something high-level in their cue like what registry/repo to use and what unique ID to use, then all the cache import/export settings would get figured out for them.
Finally, there is still the problem of how to get this working on everything else people might want to export cache to besides GHA and a registry. I think the idea of using the registry API as a proxy to other backends may be the best way to start. It's ugly relative to the options that require upstream Buildkit changes, but it's possible to get going quickly (just run the proxy implementation via an AsyncExec) and can serve as a testing grounds for what we might want to upstream more cleanly someday.

TODOs
Combining these ideas with the next steps I mentioned in my previous comment, ordered roughly by my current priority:

Test idea of setting up cache-from and cache-to using cue (instead of command line flags/env vars)

I think this has the most potential to be valuable to users quickest

Test idea of syncing a cache dir with GHA using AsyncExec

It remains to be seen what cases this is actually beneficial in as discussed previously, but having this setup will at least let us start experimenting

Hook things up to a tracing API for getting timing metrics
Test idea of additive registry caches
Test idea of registry api as proxy to other backends

All of these tests will just start as basic proof-of-concepts, after which we can assess if they are promising on their own or if they indicate that we need to do something more time-consuming like upstream features to Buildkit.

Sounds like a solid plan!

Scopes+Additive Caches on Any Backend

cache-from / cache-to using CUE is a very interesting idea. I'm wondering how "involved" the user would need to be to set this up (e.g. would this require setting up some CI specific settings on the Plan such as repository etc).
Alternatively, we could split that logic between the CI specific integration code (e.g. GH Action, Circle CI ORB) and dagger itself.
Basically, the GH action code has all the data we need (repository, PR number, remote ref, etc). And dagger has the other "sub scope": action  (e.g. do <ACTION NAME>) and which project we're running (e.g. -p <file.cue>)
In theory, combining those two, we have everything we need to do scoping/additive zero-config caching (end up with something like dagger-cache-[PR / HEAD ID]-[PROJECT]-[ACTION]). And from the action we also know the target branch of the PR (to import cache).
But I do see the appeal of doing that in CUE -- we could implement those "drivers" as regular dagger packages rather than custom integrations like the action, definitely worth exploring.
Another TODO regarding the GHA: no matter the approach, I think we should "merge" the logic of crazy-max/ghaction-github-runtime@v1 inside the dagger GHA. That action exports some caching information to buildkit and right now users have to use both actions to get caching to work. I think it would be better if everything worked out of the box when using the dagger GHA.

Cache Dir Export

Yep that sounds great -- no upstream changes, we can experiment right away. I like that :)

Alternatively, we could split that logic between the CI specific integration code (e.g. GH Action, Circle CI ORB) and dagger itself.

True, both sides of this will need to be involved for sure, I guess it's just about where we draw the border exactly. My hope is that putting more of the logic in dagger packages would result in more generic and re-usable code across multiple integrations. Then the CI-specific code code just be used to setup env vars and other client state that can be read by the dagger package as args essentially (just using the existing client mechanisms).
Tough to say if this theory will work out in practice though, could just lead to more code if it ends up being hard to create re-usable code. I'll just keep an open mind about this when I start trying it out.

Another TODO regarding the GHA: no matter the approach, I think we should "merge" the logic of crazy-max/ghaction-github-runtime@v1 inside the dagger GHA.

Right, that should be an easy win too. I'll take a look at it.

Test idea of setting up cache-from and cache-to using cue (instead of command line flags/env vars)
I think this has the most potential to be valuable to users quickest

I think we could use the Client API to let user specify where store cache.
Here's a quick example from my mind
dagger.#Plan & {
  client: cache: "my-cool-plan": {
     type: "registry"
     ref: "localhost:6000/toto"
     auth: {...} // How should we manage authentication?
  }
}

And so this will be transform in --cache-to type=regsitry,ref=localhost:6000/toto:my-cool-plan
WDYT?

New idea: run anAsyncExec with the shared cache dir mounted, put a daemon in there that handles the syncing of the cache dir with an external backend

I really like that idea but may with time it will be complex to maintain those daemons, indeed, we should also find a way to prune.

I really like that idea but may with time it will be complex to maintain those daemons, indeed, we should also find a way to prune.

Agreed but I also can't think any way to avoid something that needs to be maintained. Even if we, say, upstream support for a particular backend to Buildkit (similar to how Buildkit supports GHA today), we will still need to maintain the code there. From that perspective, I'd actually rather maintain something more modular that can be upgraded on the fly without having to upgrade the entirety of Buildkit. This probably also makes it easier for external contributors to implement their own functionality.

WDYT?

Yeah I like it, this is along the lines of what I was imagining, couple minor thoughts:

Rather than using a type: string to switch between different implementations, I'd be interested in if we can use separate cue definitions that just output a common interface of from and to values
I wonder if it might make more sense to have cache be its own field on the same level as client and actions rather than under client. Just because cache doesn't necessarily involve resources local to the client. This is mostly a superficial issue though.

So, just iterating on your suggestion, maybe something like:
dagger.#Plan & {
  client: { ... }
  cache: {
    "my-registry-cache": #cache.Registry & {
        ref: "localhost:6000/toto"
        auth: { token: client.secret.token } // can read in stuff from the client
    }
    "my-s3-cache": #cache.S3 & {
        bucket: "foobar-bucket"
        aws_secret_key: {...}
     }
  }
  actions: {...} // all actions are now backed by the cache and new results will be uploaded
}

Each entry under cache can output both from and/or to values that are then passed to the Buildkit solver as the cache import/export values (though for now we will be limited to a single cache output as you know). If a particular implementation also needs to setup some extra state (such as an s3 backend needing to setup a container that translates registry API calls to S3 ones), then we can support that too by allowing an output of type daemon: #core.AsyncExec or something maybe.

I guess another nice thing about supporting cache settings like this inside dagger plans/actions is that you could potentially use dagger to setup the cache infra. I.e. I could provision a registry using Dagger (or just do a noop if it already exists) and then use that as the cache backend for the rest of my plan. This sounds like it could complicate our cue workflow, but probably something that can be done in the fullness of time if nothing else?

https://github.com/dagger/dagger/issues/2365 is related. Besides the immediate problems there, it also raises an interesting question in general: if the backing cache is sometimes fast, sometimes slow (due to throttling or anything else), how does a user determine if caching is actually beneficial?
Would it make sense to have the ability to simultaneously execute a vertex and import cache for it, basically letting the two race and choosing whichever is fastest? This might sometimes result in the most consistently fast behavior, but at the expense of resources (cpu time and network bandwidth). How would we guide users on whether they should do this or not?
Another possibility is to just allow the cache import to timeout (with a configurable value) and then fallback to executing the vertex, but how would we guide users to set an optimal timeout value (or automatically set it for them)?
I don't have any answers yet, just making sure these types of questions are tracked.

Should we fix it in Buildkit? It feels like a strong limitation for the future of dagger cache

Yes for sure. There is an open PR to add support for multiple non-cache exports. I think once that's merged it would make sense to add the same ability but for cache exports.

It opens a lot of possibility, but we should leave this for now, let's focus on cache

Agreed, I'm thinking long-term here, not proposing we do everything right away :-)

When Erik gets back from vacation, we can review this issue to see how we can break it down into smaller bitesize issues that can be tracked in an easier way.

A lot of this is still relevant in an abstract way but we've moved entirely off the previous CI system and will continue to, so closing this as no longer actionable. Can be revisited for ideas on CI caching in the future.


Do not log getPayload as INFO for security reasons.

The packet bodies may contain private information.
This getPayload should not be normally logged.
Change the logging to DEBUG or remove logging entirely.
see: https://github.com/folio-org/mod-camunda/blob/904057a162a0709d6bb551c3ef10cba5b4aa4d63/src/main/java/org/folio/rest/camunda/kafka/EventConsumer.java#L37

Shouldn't we be encrypting secrets for data at rest or in transit.


Onecond 1965 - Adding validations and making Workflow id as a separate field

Pull Request type
Feature
Changes in this PR
Adding workflowId as a separate field

This pull request has 2447 commits and changes in 412 files. As per the contribution guidelines, please create a discussion about the proposed change before creating a pull request. We encourage small, meaningful, bite-sized pull requests.


Fix for user template function

Fix the template so user functions are merged with the main function.
Also added a test

Seem to be getting different values for the tests and cannot work out why? Any ideas


@shaysw Work: Bug 2059 revert title string

@shaysw I can't push to your account

@shaysw I can't push to your account

sorry yeah that makes sense


Feature/costing with mapped requests

This means that date ranges are expanded and users can't cheat the costs so easily
MARS time convention is not expanded, so this does not defend against that, but if that is added to the mapping then this will allow that

Does apply_mapping raise errors? If yes, we need to make sure that this change does not cause 500s.

Does apply_mapping raise errors? If yes, we need to make sure that this change does not cause 500s.

Yes it does, but I made sure that my previous PR raised InvalidRequest at source (i.e. in apply_mapping) so that this PR also raises good errors:
https://github.com/ecmwf-projects/cads-adaptors/pull/229/files

FYI, it is possible that some 500s may be raised, but this will indicate an action for us to catch some errors we have not yet anticipated.


Missing step for Visual Studio 2019

If you following the directions for VS 2019, you will still get the following compile errors:
unexpected end of file while looking for precompiled header. Did you forget to add '#include "pch.h"' to your source?
To build successfully, I had to go into project properties and set the following option.
Project Properties --> C/C++ --> Precompile Headers --> Precompile Header: "Not Using Precompile Headers"
This step was included in the VS2017 directions, I think this is required for the VS2019 documentation too.

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

ID: d9992332-7b7b-d08a-704a-9fe928fdbd56
Version Independent ID: 181bf5b3-50bd-dd0b-d8ec-2cce408397a1
Content: Walkthrough: Creating and Using a Static Library (C++)
Content Source: docs/build/walkthrough-creating-and-using-a-static-library-cpp.md
Product: visual-cpp
Technology: cpp-tools
GitHub Login: @corob-msft
Microsoft Alias: corob

@akabeera
Thanks for pointing the issue out. I addressed this in the recent update to this topic.


How to stop the sound from playing in a functional component

:beetle: Description
In my react native application, I am trying to make a "shrill alarm" feature where on the press of a button, an alarm can be played repeatedly. So far I have been able to play the audio file that I want. I tied the sound function to a useEffect hook in which I was hoping I would be able to start and stop the audio from playing. When I set the state which is tied to the useEffect hook to true, I am able to get the sound to play. But when I set the state to false, the sound will not stop
:beetle: What have you tried?
The solutions from the other issues don't seem to help me because they are all class components.
:beetle: Please post your code:

const [alarmStatus, setalarmStatus] = useState(false);

//The intention here is that when I change the alarmStatus to false, I expect the
// Sound to stop playing. But it isn't in this case
useEffect(() => {
        Sound.setCategory('Alarm')
        let alarmtest = new Sound('smalarm.mp3', Sound.MAIN_BUNDLE, (error) => {
            if (error) {
                console.log('Failed to load sound', error)
            }
            else {
                if (alarmStatus) {
                    alarmtest.play((s) => {
                        if (s) {
                            console.log('Playback success')
                            alarmtest.release();
                        }
                        else {
                            console.log('Playback fail')
                        }
                    });
                }
                else{
                    alarmtest.stop();
                }
            }
        })
    }, [alarmStatus])

:bulb: Possible solution

[x] iOS
[x] Android

Are you using...

[x] React Native CLI (e.g. react-native run-android)

Which versions are you using?

React Native Sound:
React Native:
iOS:
Android:

Does the problem occur on...

[ ] Device

If your problem is happening on a device, which device?

Device: iPhone X and any generic android

Well remember the alarmtest variable "resets" on every rerender, so when you change state to stop the alarmtest variable is a newly initiated Sound class and it can't be used to stop the old one.
You are going to have to use something like useref to initialize the Sound class, because useref doesn't reset on rerender

The idea of @Hannes1 worked for me. You just need to do the initialization of the Sound in a useRef. With that the sound variable stays the same as well during rerender
const soundRef = useRef<Sound>(
    new Sound(soundFile, soundPath, error => {
      if (error) {
        console.error("error", error);
      }
    })
  );

Later in your code you can access the sound like this:
useEffect(() => {
  // playing
  shuttleSoundRef.current.play();
  // stopping after 2 seconds
  setTimeout(() => {
    shuttleSoundRef.current.stop();
  }, 2000);
}, []);

You can use this for checking the state of alarmStatus in a useEffect


Add arrow-left (or "Back") arrow

Add arrow-left (or "Back") arrow

Add arrow-left.svg file
Add arrow-left to icons.js

Resolves: https://github.com/helpscout/blue/issues/9

Coverage remained the same at 100.0% when pulling 33be6c7ee15f1ed76043a667999c0d6e07470507 on add-back-icon into 0bbe3dc399392459e89c372d31ed7848517120ac on master.


fix: flutter web crashes when autoDispose used

Issue: https://github.com/rrousselGit/riverpod/issues/1713
With https://github.com/dart-lang/sdk/issues/50119#issuecomment-1266044946
The dart compiler doesn't understand redefining class with mixin.
This fix can be a workaround until it's fixed from the dart side.

It looks like this patch might be missing some of the _family items, just by looking at the list of filenames.
Maybe that should be double checked to prevent a surprise?

It looks like this patch might be missing some of the _family items, just by looking at the list of filenames.
Maybe that should be double checked to prevent a surprise?

Not all providers have a _family file. :)

@leehack Thanks! Lgtm!

@rrousselGit Anyway to release the workaround version to pub.dev?
hooks_riverpod still depends on riverpod 2.02

Just tried to use flutter_riverpod master, hoping that I could use the riverpod generator, but I can't start the project with error
Waiting for connection from debug service on Chrome...
../../../../.pub-cache/git/riverpod-fe305c02f5cc502c628873401d82a693d56296dc/packages/flutter_riverpod/lib/src/change_notifier_provider/auto_dispose.dart:96:12: Error: The method 'FamilyOverrideImpl' isn't defined for the class 'AutoDisposeChangeNotifierProviderFamily<NotifierT, Arg>'.
 - 'AutoDisposeChangeNotifierProviderFamily' is from 'package:flutter_riverpod/src/change_notifier_provider.dart' ('../../../../.pub-cache/git/riverpod-fe305c02f5cc502c628873401d82a693d56296dc/packages/flutter_riverpod/lib/src/change_notifier_provider.dart').
Try correcting the name to the name of an existing method, or defining a method named 'FamilyOverrideImpl'.
    return FamilyOverrideImpl<NotifierT, Arg,
           ^^^^^^^^^^^^^^^^^^


data preparation support for Landsat (GA/USGS), Sentinel-2 (L1C, L2A), Himawari8 (BRF), MODIS (CSIRO).

Investigate how DataCube is going to support ingesting following datasets:

Landsat from GA (L1T, NBAR, PQ, FC)
Landsat from USGS (L1, SR)
Sentinel-2 L1C and L2A
Himawari-8 BRF
MODIS from CSIRO

GA LS *, Sentinel-2 L1C and Himawari-8 are done. For the rest separate issues will be created


feat: add consola 3.0.x

Goal
Update deps to Consola 3. Interface should be the same.
https://github.com/unjs/consola/releases
Design

Changeset

Testing

I could not run the test locally, the maze runner image was not be able to be pulled

Hi @JulianMar, Thanks for the PR, we will look to review as soon as priorities allow.

No worries, take your time!

Hey, any news on this?
The change isn't too big and it's only about consola. The newest version isn't working with nuxt 3, as it's using consola 3.

Hey, thanks for the feedback!
Take your time. I created a Fork in between.


Support merging pull requests

This involves configuring Copybara properly.
Should be ready soon!

Testing workflow for merging pull requests on https://github.com/google/gemma.cpp/pull/14.

Our workflow is working reasonably well now.
For maintainers:

Change pull requests to retarget the google:dev branch, if not already the target.
Add the copybara-import label on the pull request and wait for Copybara to import the pull request internally.
Approve the imported changelist.

Eventually, the Copybara service should automatically merge the pull request as well.
In the short-term, this is bugged, so manually merge the pull request instead (with a squash commit).


Implement netx.WrappedConn interface

This allows http-proxy-lantern to get at the underlying tcp connection.

If the proxy (and the client) are creating the TCP connections, they should be able to hang on to them and track BBR metrics directly, without the need to peer under the hood in each protocol library to ask for the TCP connection back. But I understand that this is long-standing practice.

Yeah, it's not my favorite either. In this particular case, we could solve the problem by eliminating the WrapListener API and replacing it with a ServerConn() api like this one. That doesn't work for all transports unfortunately, so it's not clear to me if we can completely get away from this pattern.

Thanks @hwh33 !


Emphysema not detected in some cases

In some cases of a serial COVID-19 evaluation, "Emphysema right" and "Emphysema left" was not detected when HU of the areas was below -1000.
The low value of the min threshold was adapted to -1050 for testing.
@lassoan  what would be the recommended way to automatically detect lowest voxel intensity in a CT volume so maybe min threshold is not needed ?

You can get minimum value of a volume by calling volumeNode.GetImageData().GetScalarRange()[0] (maximum is volumeNode.GetImageData().GetScalarRange()[1]).

You can get minimum value of a volume by calling volumeNode.GetImageData().GetScalarRange()[0] (maximum is volumeNode.GetImageData().GetScalarRange()[1]).

Thanks, works well, implemented ...

Thanks, works well, implemented ...

Thanks, works well, implemented ...

Thanks, works well, implemented ...


Typos and error? in doc

Some text appears in the previous section, instead of the correct one.
Table says user can't send an emoji to bots, but it's easily verified that the TEams UI lets you send emoticons and emojis to bots.

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

ID: afbc5b84-5be5-b5c4-30c0-58782a748a03
Version Independent ID: ef6b8aee-52e7-f5d4-7dfa-8f34a1698330
Content: Messages in bot conversations - Teams
Content Source: msteams-platform/bots/how-to/conversations/conversation-messages.md
Product: msteams
GitHub Login: @surbhigupta
Microsoft Alias: anclear

We are checking this issue, we will update you.

Hello @surbhigupta12 - Could you please help us to update the contents?


[PowerShell] Day One

A PowerShell Azure Function to return a json by Olivier Miossec @omiossec_med, linkedin

Hi @omiossec!
Once you have the challenge result, you will compare it to the challenge you created. And after make all the necessary changes in your code, we will close this PR.
Remember that all challenges must be developed in your repository. That's why is very important to fork this repository.
And thank you for your awesome contribution @omiossec !


Refactor link checker to use FileBatch class

In https://github.com/Qiskit/documentation/issues/495, we will start checking historical API docs. For performance, it's important that we don't load every single file in the project at once in memory. Instead, we want to operate in batches: e.g. check all of 0.44, then drop from memory and move on to 0.43.
This PR is a pre-factor to add a new FileBatch class. For now, we only have a single FileBatch, the same as before. This class still differentiates between files "to load" vs "to check", per https://github.com/Qiskit/documentation/pull/496.

I didn't add tests for FileBatch since it's too complex to test with needing actual files set up etc.


filename problem

filename problem.
when I download a image(starwars lego) with image-picka from this link:
http://gall.dcinside.com/board/view/?id=aviationfight&no=173421&page=1
filename is wrong "viewimage.php_id=2cabd927f1db37a868b6d1bd02&no=29bcc427bd8777a16fb3dab004c86b6fe0f25512895f218cee112a072de13719034a9a12382288641". proper filename is "1511319103.jpg".
I know it is by WE limitation.
but, QuickDrag WE (https://addons.mozilla.org/en-US/firefox/addon/quickdrag-we/)" workaround this problem with showing save window when drag image to download. so, I don't use image-picka anymore to download single image.
image-picka can do it too?

QuickDrag WE uses a link to trigger download:
https://github.com/kanap0nta/QuickDrag-WE/blob/bee4d34dd9378d9f7668b41a2f3d6b1c829d6aae/Firefox/quickdrag.js#L200-L206
Maybe we can try to extract the filename from the response header.

I've implemented this in #151. Currently, it only works with cached images. If the image is not cached, the download will fail.


zip url deploy not working beginCreateZipDeploymentForStaticSiteAndWait

@azure/arm-appservice: docs
13.0.3:
macOS:
[*] nodejs

version:

[ ] browser

name/version:

[ ] typescript

version:

I'm using the below code to deploy a static web app using the zip URL.
const { WebSiteManagementClient } = require("@azure/arm-appservice");
const { DefaultAzureCredential } = require("@azure/identity");

/**
 * This sample demonstrates how to Description for Deploys zipped content to a static site.
 *
 * @summary Description for Deploys zipped content to a static site.
 * x-ms-original-file: specification/web/resource-manager/Microsoft.Web/stable/2022-03-01/examples/StaticSiteZipDeploy.json
 */
async function deployASiteFromAZippedPackage() {
  const subscriptionId = ""; // made it empty for the issue
  const resourceGroupName = ""; // made it empty for the issue
  const name = "";
  const staticSiteZipDeploymentEnvelope = {
    appZipUrl: "myzipURL",
    deploymentTitle: "test",
    provider: "node",
  };
  const credential = new DefaultAzureCredential();
  console.log(credential);
  const client = new WebSiteManagementClient(credential, subscriptionId);
  const result =
    await client.staticSites.beginCreateZipDeploymentForStaticSiteAndWait(
      resourceGroupName,
      name,
      staticSiteZipDeploymentEnvelope
    );
  console.log(result);
}

deployASiteFromAZippedPackage().catch(console.error);

And getting the below error:
  "name": "RestError",
  "statusCode": 501,
  "request": {
    "url": "https://management.azure.com/subscriptions/dbb23b75-1396-4368-aa95-aac40adcd8b4/resourceGroups/appshare/providers/Microsoft.Web/staticSites/test5/zipdeploy?api-version=2022-03-01",
    "headers": {
      "content-type": "application/json",
      "accept": "application/json",
      "accept-encoding": "gzip,deflate",
      "user-agent": "azsdk-js-arm-appservice/13.0.3 core-rest-pipeline/1.10.0 Node/v16.17.1 OS/(arm64-Darwin-22.2.0)",
      "x-ms-client-request-id": "89b18f48-1d12-4f4f-9ce8-2985a1e179e9",
      "authorization": "REDACTED",
      "content-length": "274"
    },
    "method": "POST",
    "timeout": 0,
    "disableKeepAlive": false,
    "streamResponseStatusCodes": {},
    "withCredentials": false,
    "requestId": "89b18f48-1d12-4f4f-9ce8-2985a1e179e9",
    "allowInsecureConnection": false,
    "enableBrowserStreams": false
  },
  "details": {
    "Code": "NotImplemented",
    "Message": "The requested method is not implemented.",
    "Target": null,
    "Details": [
      {
        "Message": "The requested method is not implemented."
      },
      {
        "Code": "NotImplemented"
      },
      {
        "ErrorEntity": {
          "ExtendedCode": "51009",
          "MessageTemplate": "The requested method is not implemented.",
          "Parameters": [],
          "Code": "NotImplemented",
          "Message": "The requested method is not implemented."
        }
      }
    ],
    "Innererror": null
  }

Could please you let me know what I'm doing wrong?
Happy new Year and
Thanks in Advance.

@kazrael2119 Can you help take a look at this issue ? Thanks

duplicate with https://github.com/Azure/azure-rest-api-specs-examples/issues/1678

This seems to be a service issue add CXP Attention here.

Possibly the same issue as https://github.com/Azure/azure-rest-api-specs/issues/22267
Any update here? Is publishing SWA content via ZIP possible?

@Mike-Crowley  Our latest package version is 15.0.0 could you try to use this package?

@kazrael2119 , my issue was on 22 SEP 2024. Your link says its older than this.


State of this repo?

@jtomaszewski are you still maintaining it? I opened a PR a while back and still not merge. Do you need help maintaining it? We use it in our company and we would be ok to help provide resources if you give us Maintainer access

Hi, I got access to this repo for Elixir team at Allegro, I'll merge that PR. @epinault we will maintain this repo, if you need anything feel free to open PR.


Vertex color only when used

Export Vertex Color only when used in shader node tree
See #1740
Still WIP, need probably some adjustments

@emackey : Do you get time to have a look on this PR?

I tried this in 4.0.0 Beta, but I'm struggling to round-trip the VertexColorTest model.  It imports OK but the vertex colors appear lost on export.

@emackey : I understand why. I didn't manage yet the case where Color Attribute node keeps the layer name empty (will use the active color layer).
For now, you can test by setting the name in the node.
Working on an update for taking active VC into account

I was on it, should be fixed now

I second @Fenreliania , this has broken my workflows too.

The plan for Blender 4.2 is to bring back a way to export Vertex Color as COLOR_x in glTF.
But we will still need to export COLOR_0 only if used in material node graph, avoiding an exporting a glTF file that does not look as in Blender viewport because of VC.
More info on #2195

@julienduroure in my work, I export building models with lots of objects that our 3d preview up then loads. There's a lot of objects that share materials and some have VC while others don't. Till now I could export the whole thing and it would look as expected as the vertex colours would automatically show up, we use it for faking AO. This has been a key element in avoiding complexity in our set up on the app side (Babylon.js)
Given the new planned workflow, would this mean I'd have to duplicate all of the materials and make the vertex colours multiply a colour to get the same result? Will there be a way, perhaps a toggle to retain the previous functionality?
Thanks!

@lentsius-bark The previous functionality was causing a number of bug reports, because it would apply vertex coloring to models that didn't show such coloring in Blender's preview.  The exported model didn't look like the previewed model, and this understandably created problems for users.  In the glTF 2.0 format, by specification, COLOR_0 is always multiplied by the base color, and the previous functionality didn't reflect that.
If you have the "same" material on meshes with and without vertex colors, many glTF viewers treat these as separate materials internally.  In particular, GLSL-based shaders are different with and without the vertex color, so the engine has to separate the two even if it's not apparent to the end user.
So, I think it's not unreasonable to separate materials with vs. without vertex colors.  At worst it could double the number of materials if you indeed have with-and-without versions of each one.  But I think this is a far better solution than offering a checkbox to violate the glTF specification, and it's more explicit about what will happen in typical rendering engines.

@emackey I understand your points. Ultimately I will work with how it ends up being as you know best I also understand that my workflows aren't necessarily the most common, thank you for opening the discourse and letting me peek into the logic of it all.

So, I think it's not unreasonable to separate materials with vs. without vertex colors.

Aye, it does make sense in case the renderer creates separate materials anyway, the only issue being in iteration speed. (having to edit both materials instead of just one, although they look similar, easily leading to inconsistencies) I will probably see if I can write an export script that would automate this.

But I think this is a far better solution than offering a checkbox to violate the glTF specification

How would it violate the spec? From my understanding the spec only states that "COLOR_0 is multiplied by the base colour", so a checkbox that would be along the lines of "Base colour multiplied by Vertec Colours" wouldn't violate it rather communicate what will happen. (I can see how bad the name is 😅)
Again thank you for clearing this up, I appreciate it, for now I'll go ahead and start experimenting with workflows for separating the materials.

Additionally, before, i could have a material that used vertex colors that multiply a texture which multiplies a colour, however, I'm not sure how to get this to work, this material:

only exports the vertex colours multiplying the texture, ignoring the color.

I also want to join and say that it broke a number of workflows for multiple projects I work on.
It should be at least offered as an option in the export settings.

Same as above, really unhappy with this change. Having the exporter do this hidden behaviour is really bad UX in my opinion.

@lentsius-bark

before, i could have a material that used vertex colors that multiply a texture which multiplies a colour, however, I'm not sure how to get this to work, this material:

This is already reported in #2110 , should be fixed for 4.2

This also broke my gamedev workflow. Wouldn't it be better if on the export gltf settings vertex colors are toggleable?

@RPicster @Arnklit @TaraSophieDev
This should be back under option for Blender 4.2, see #2195 for more information

@Arnklit

Having the exporter do this hidden behaviour

For me, this is the opposite. The behavior before 4.1 export Vertex Color that are not shown in Blender viewport. This was an hidden exported feature.
Now data exported are inline with what Blender viewport shows.
Anyway, some option toggles (once again, more and more options...) will let you choose how to export VC in Blender 4.2

Oh THATs why stuff broke on my end! Yeah, hopeful the setting is a viable solution, this really introduced some unnecessary debugging time on my end.

For me, this is the opposite. The behavior before 4.1 export Vertex Color that are not shown in Blender viewport. This was an hidden exported feature.
Now data exported are inline with what Blender viewport shows.

I expect the data on the mesh to be exported, but what Blender displays in the viewport. UV2 is exported even if it isn't used in the material. Should that be stripped out now as well?

I expect the data on the mesh to be exported, not what Blender displays in the viewport. UV2 is exported even if it isn't used in the material. Should that be stripped out now as well?

Don't think this is the same case

TEXCOORD_X is exported, but without any consequences if no material texture uses it.
COLOR_0 must act as a multiplier of base color

Hello,
To all people reading this because they have issue on Blender 4.1 with Vertex Color export:
We know that the changes may break some workflow that use Vertex Color.
You can read all this conversation to understand why this change happen.
For a reminder: glTF use COLOR_0 as a multiplier for base color. If you are not using VC  in your node tree, Blender Viewport does not show it the same way glTF exported it in any Blender version prior to 4.1
I will stop answering individually on each request/remark/complain on this subject (once again, we hear you), in order to spend time on a solution itself.
Thanks again for using this I/O :)

Just needs to be an export option to enable or not. Blender is not an authority of a pipeline based on internal shaders. Thecnical work flows require control.
Just add a checkbox and force vertex if enabled with its type as needed. This way everyone wins.

Do you think it's okay to go around with that photo representing Blender while you mess with multiple industries?

Surprised you’d push this without a solution in place: like I understand why you’re making the change to not export COLOR_0 by default if it’s not being used as base color, but it’s honest sorta strange to push this when a lot of people NEED vertex colors for other reasons

This is how I use vertex color in a material, the change requires specific naming to it AND the attribute node in shader editor to be connected to multiply mix node, which is completely incompatible with how I use the material. (this is a blend 4 textures shader where each color represents a texture)
Not to mention I'd have to rename every attribute in every object to match the expected naming convention.
To export my meshes correctly I had to open the scene in version 4.0 and export from there.
I expect this to be fixed by allowing to export vertex color without need for specific nodes and without need for specific naming.

if this gets change gets undone//patched out;
i think its worth making a public hotfix/patched build of this while we wait for 4.2
beacuse more and more people are going to notice and get angry and post complains here.
without really understanding how open source works and it might be a headache for contributors

This change should be reverted as it conflicts with the established workflows of many people.
Under this logic, not using every UV channel in material should also delete unused UV channels. I see this as problematic.

this is the dumbest commit in the history of the game development industry

vertex color attributes arent only used for colors, most of the time theyre used for other stuff
even then, exported models actually rarely have materials setup in blender

Khronos along with committees like the C++ committee have slowly become batshit insane. Please, find common ground with the industries you're working with again, because you've lost it along the way.
I'm not sorry I went with fbx over gltf, despite being encouraged otherwise.

I just wanted to thank you for all your work, while this is an important feature and the concern from some people is understandable, open source development is often thankless work and you often only hear from people when something goes wrong rather than when things go right.
Your addon has provided immense value to me in my daily life and I sincerely appreciate it.

I think the drive for perfect PBR sometimes forgets the hacky and beautiful realities of day to day gamedev, I have some issues with how the glTF spec wants to ignore certain blendOps because "that wouldn't happen in the real world." I have hope the working group will change that with the proposed material graph and texture graph extensions, however.

Hello,
Let's try to summarize the situation here:

In the common usage / historically / simplicity of usage, Vertex Colors are used not only for Vertex Color, but also for transmission of other custom data.
The glTF Specification propose a way to transmit custom attributes, but seem for a number of reasons, this workflow is not commonly used:

Not very well know
Not perfect from Blender side yet (need to use name starting with underscore to avoid exporting internally used custom attributes)
Lack of implementation / easy way to retrieve data for some engine/viewer
This make the end to end workflow of custom attributes not very used (from what I know)

All of these make that VC are commonly used for custom attributes transmission too, even if this goes against the glTF Specification, that says that VC must act as multiplier of Base Color.
This PR proposed a change that make VC more accurate when VC are used the way glTF specification requests it, but breaks all other usage of the VC.
Setting some custom attributes in VC COLOR_0 will generate some valid glTF files, but a fully compliant glTF 2.0 viewer must use these data as a base color multiplier, probably resulting to weird shading.
We will come back to you later with more information about how we/you should solve this together.

@julienduroure can old behavior be opt-in in export options?

@julienduroure if I'm going to respond in this thread in a more civilized and constructive matter, to bring my experience into the issue:
I believe the glTF specification itself is really what becomes the core issue here. glTF does not simply specify data storage, but it also seems to specify how this data is supposed to be used, as well as how to render meshes that it stores. This makes it fully incompatible with the majority of game engines and games, except for the most simple ones that strictly will follow glTF in all of it's rendering (< 0.01% if I were to take a stab).
 The real issue is that game developers try to use, or simply condone using, glTF for game development. It doesn't seem to be designed for it.
Or, if glTF is designed to be used for game engines, then instead the problem becomes that the specification itself is fundamentally flawed.
So, to sum up; Don't blame this commit. Either blame the specification, or blame developers who want to use this format for game development.

Thus, I apologize for my misdirected anger. Thank you for supporting the open source ecosystem.

@perkele1989 It may be true that usage is not "to-spec", but I don't think breaking hundreds of peoples workflows just "to be right" is the right approach. It's disturbing users, especially when "settings to restore the current wildly used workflow" were not even in this PR.

Having coherence and a standardized way of doing things in the world of 3D has been lacking for decades. The limitations of other formats (such as fbx) are what have led to these kinds of "customs". GLTF is a 3D asset exchange format, it is neither intended for video games nor not intended for them. If complete compatibility with everything done in the 3D editor is sought, it's better to use USD. If GLTF allows for an alternative way of performing basic tasks such as having associated extra information, it's the logical path to take, which is what is intended, standardizing 3D exchange. Not allowing everyone to do as they please like an elephant in a china shop while wearing a funny hat as it seems every time I enter this forum... Anything that leads to standardization will be beneficial for everyone. Slow and perhaps traumatic but ultimately, beneficial.

For me, this is the opposite. The behavior before 4.1 export Vertex Color that are not shown in Blender viewport. This was an hidden exported feature.
Now data exported are inline with what Blender viewport shows.

Going by this definition only - if I export the model while in a non-material view the exported model should not have materials. If my armature modifier is temporarily hidden then it shouldn't export the bone weights, and so on.
If we apply this further to appearance, then if I prototype a shader in blender then I guess gltf should store some kind of universal shadercode so that when I import it to a game engine it will still try to match the blender viewport...
Since not exporting 'unused data' is what we're going for, If a mesh/object is entirely inside another let's not include it in the exported file since the user can't see it anyway. Surely the user just didn't know what they were doing. Why would the gltf file format decide this?
But this argument is wrong in the first place, It's already possible to view vertex colors in the viewport without any material set on the model, by setting the 'Viewport shading > Color' option to 'Attribute'. This would lead to a user viewing their model with vertex colors clearly visible in their blender viewport, then exporting it only to find them completely gone. So even users who were using this property as you intended, but didn't need to set up materials in their workflow and used vertex color to paint the model, now have to go through the extra step of adding a material to every object.
Regardless, it's crazy that this PR didn't include a fallback export setting. I've seen many more examples of using vertex colors for other uses than as actual colors by a large margin. You could put a blaring red outline around the option and describe that this is not how it's meant to be used, and I'm pretty sure everyone who does - still would.

@julienduroure Over a long enough timeframe custom attributes should do this job better, but I thought it'd be worth mentioning that one of the reasons artists use Vertex Colors to smuggle data is that it's a very standard feature in game engines, and if you don't have a programmer or engineer that's building pipeline tools for you then you have to use what's available.
For me working in Unity for example I can access Vertex Colors and UVs in shaders and do with them what I like (and I use both frequently to pass data to shaders), but I can't access custom attributes, not without messing with the community importer I use to try and plug the custom data into the model's UV or Vertex Color data.
It will take a long time for custom attribute support to make its way across the entire pipeline, but in the meantime artists need to use what they have available, and Vertex Colors are a very easy and visual way of getting that done.

For those using Godot, I've created a workaround for now, since this completely breaks an important part of our rendering...
https://github.com/Invertex/GODOT_Vertex-Color-Import-Swapper
Should show up on the AssetLib once approved though instead of getting it directly from there, so keep an eye out for it!

this also broke my lightmapping system for my game. I have preview materials setup in blender that use the vertex color in a way that allows me to preview what it will look like in game. looks like ill have to load up the old 4.0 exporter on 4.1 to keep working.

Dear all,
Here is a proposition for 4.2, where we give users an option to export active VC, even if not used in the node tree.
#2233

What is the correct way to use it in the node tree without affecting anything else?

Dear all, Here is a proposition for 4.2, where we give users an option to export active VC, even if not used in the node tree. #2233

What is the correct way to use it in the node tree without affecting anything else?


Improve json parsing for findStatus

The find status parsing in findStatus could use some cleanup.

Seems pretty straightforward, I would love to work on that one 😃


Feat: Explicitly label preview backfills in the plan summary

Maybe not in this PR, but are there tests we can write that expose the issues you listed above?

Maybe not in this PR, but are there tests we can write that expose the issues you listed above?

The only issue here that I'm not sure how to materialize is the wrong order of reseting missing intervals vs adding restatements. Once I fixed this issue the existing tests exposed the other _start / override_start related issue.
Unfortunately, I currently struggle to come up with a scenario in which this would matter. It should probably involve a combination of ignored snapshots, forward-only and partially backfilled DAG?

I'm hoping to refactor this whole logic soon and break up the loop that currently exists between missing intervals, plan start and restatements. This would eliminate the possibility of any issues of this sort.


Rubin Simulated Dataset

Goal: Find and download the full Rubin simulated observations dataset.
Resources:

Rubin simulations main page: https://www.lsst.org/scientists/understanding-simulations-and-data
Main page for CatSim: Database of stars, galaxies, and Solar System objects that can be queried as a function of position and survey time: https://www.lsst.org/scientists/simulations/catsim
Catalog Simulations (CatSim) Documentation: https://confluence.lsstcorp.org/display/SIM/Catalog+Simulations+Documentation
CatSim Tutorial: https://github.com/uwssg/LSST-Tutorials/blob/master/CatSim/CatSimTutorial_SimulationsAHM_1503.ipynb
Database Schema: https://confluence.lsstcorp.org/display/SIM/Database+Schema
Database: https://community.lsst.org/t/baseline-v3-2-released/7877

Plot visits from survey using astropy full sky vis. One night vs nights from different times of the year for idea of how much Rubin sees.

Histogram of visit obs times (obs start mjd, as function of 7 days)

Same thing as part 1, but using ecliptic instead (convert RA dec to ecliptic)

Idea: know how the visits are mapped out in the sky, know how many visits there are per week, compare that with visits over months, gain better understanding of how the telescope observes

https://github.com/lsst/rubin_sim_notebooks/tree/main/maf/tutorial


The picture does not match the data

🐛 Bug
I think the .by argument in vis is not fully working at least when a vector is provided (Version : immunarch_<IP_ADDRESS>05)
To Reproduce
This is what I get when looking at exp_vol

exp_vol$Volume
[1]  213 5647 1333 2658  528 1326
by_vec = factor(c("D","S","D","S","L","N"))
by_vec
[1] D S D S L N
Levels: D L N S
p = vis(exp_vol, .by = by_vec)
Warning: Ignoring unknown aesthetics: y
Warning: Ignoring unknown aesthetics: xmin, xmax, annotations, y_position
p

Expected behavior
As one can see first D value is 213 second D value is 1333 and not 5647 as in the picture.
Thank you for your help!

Hi @jeitziner ,
sorry for the late response. Can you please update to the latest immunarch versions 0.5.5 and try again? It's a known bug and we fixed it in the post-0.3.3 version. Let's keep this issue open until you confirm that everything works correctly.

Solved, thank you !
Le dim. 12 avr. 2020 à 16:27, Vadim Nazarov<EMAIL_ADDRESS>a
écrit :

Hi @jeitziner https://github.com/jeitziner ,
sorry for the late response. Can you please update to the latest immunarch
versions 0.5.5 and try again? It's a known bug and we fixed it in the
post-0.3.3 version. Let's keep this issue open until you confirm that
everything works correctly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/immunomind/immunarch/issues/46#issuecomment-612623824,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHU3N5LB66Z2NH7NLEQZKSLRMHFVBANCNFSM4MD5KAQQ
.


Improved chat input box: Upload, video, emoji picker, ...

I would like a redesign of the chat input box. Here are some issues ideas:

[x] The "video" button seems misplaced. I think it should be inside the input box, or close by.
[x] It's quite difficult to find the correct emoji.
[ ] There are some autocomplete issues, especially when trying to autocomplete emojis.
[x] Do we need a "send" button?
[ ] Audio button #473

Below is a screenshot of how Facebook's input field is designed. Don't want to copy it, but it has some interesting ideas.

Not directly related, but the video-icon in the top menu on small screens could be replaced with a "participants" icon, which again toggles the participant list.

Not directly related, but the video-icon in the top menu on small screens could be replaced with a "participants" icon, which again toggles the participant list.

v5.29 is out with a new chat input.

I'm going to close this issue, since I'm not too interested in the "Audio" part for now.


[6.x] Can't access session via Javascript

Laravel Version: 6.16.0
PHP Version: 7.4.0
Database Driver & Version: not relevent to issue.

Description:
I'm storing sessions in Redis and can see the session in Telescope and barryvdh/laravel-debugbar but when trying to access the session via Javascripts sessionStorage.getItem() I get null returned to me.
I can echo out the contents of the session from Laravels session() helper (also using it to create the session in the first place) but Javascript & Browser console just can't see the session.
I have config('session.http_only') set to false and strict_mode on lax
Steps To Reproduce:
Create route endpoint '/test'
Create session in closure.
Echo session out in return statement
See session in browser window.
Can't see session from javascript.

Minimum viable code
Route::get('/test', function() {
    session()->put(['test' => 'test!']);
    return "session key is test
contents are: " . session('test');
});

As far as I know the sessionStorage has nothing to do with the PHP session, which is completely server side and  (luckily) not directly accessible from the client. See here: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage
The "session.http_only" controls, if the cookie which Laravel uses for identifying the session on the server is accessable by javascript.
What are you trying to achieve? If you just want to specific data from the session, just use an ajax.

Hi there,
Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!
Thanks.


Added CODE_OF_CONDUCT

Thanks! But I thought that all TerminusDB projects were using the Berlin Code of Conduct. As mentioned in the documentation:
https://terminusdb.com/docs/ (scroll to the bottom)

@rrooij Shall I replace

Hi @gaushikmr, yes as @rrooij stated, the core team agree to use the Berline Code of Conduct to be our code of conduct. I think at this stage, there is no need for a separate code of conduct. If you would like to contribute, have a look at the issues here and see if you want to take any of those: https://github.com/terminusdb/terminusdb-client-python/issues?q=is%3Aissue+is%3Aopen+label%3A"help+wanted"
Thank you again for contributing.


Allowed submitting when submit errors exist

Fixes #2244 and addresses a comment left by @orfjackal in handleSubmit.js.
The problem was that it should still try to submit even if previous submission errors exist. Now it will only not submit if sync or async errors exist.

Current coverage is 100% (diff: 100%)

Merging #2246 into master will not change coverage

@@           master   #2246   diff @@
=====================================
  Files          59      59
  Lines        1196    1201     +5
  Methods         0       0
  Messages        0       0
  Branches        0       0
=====================================
+ Hits         1196    1201     +5
  Misses          0       0
  Partials        0       0

Powered by Codecov. Last update 83af3f2...4d3b8e4

Published in v6.3.1.


Add training loop

An optax training loop with an input pipeline will let us take the model code and run training with datasets.
https://github.com/deepmind/optax
Shouldn't be too terrible, especially once we've got a dataloading class set up.

Lucid is on the case! #22 begins this work

Closed by #22.


Intermittent issue with packages install

Intermittently Mantl deployment fails with the messages like:
TASK: [common | install distributive] *****************************************
failed: [mantl-andrii-control-03] => {"changed": false, "failed": true, "rc": 1}
msg: Package at https://bintray.com/artifact/download/asteris/mantl-rpm/distributive-0.2.4-1.x86_64.rpm could not be installed
failed: [mantl-andrii-control-02] => {"changed": false, "failed": true, "rc": 1}
msg: Package at https://bintray.com/artifact/download/asteris/mantl-rpm/distributive-0.2.4-1.x86_64.rpm could not be installed
changed: [mantl-andrii-worker-003]
changed: [mantl-andrii-control-01]
changed: [mantl-andrii-worker-002]
changed: [mantl-andrii-edge-01]
changed: [mantl-andrii-edge-02]
changed: [mantl-andrii-worker-001]

TASK: [common | create consul configuration directory] ************************
changed: [mantl-andrii-control-01]
changed: [mantl-andrii-worker-001]
changed: [mantl-andrii-edge-02]
changed: [mantl-andrii-edge-01]
changed: [mantl-andrii-worker-002]
changed: [mantl-andrii-worker-003]

This issue is not related to one specific package or a host but rather to all packages installed via the yum Ansible module.
Sometimes, package is not installed on all hosts and sometimes only on several of them.
Pay attention to the task following the failed one. Now, Ansible determines that there are only 6 hosts left instead of 8, so all further tasks will be applied for the remained 6 hosts.
I'm able to reproduce this problem in an Amsterdam-based OpenStack cloud. For example, in a Texas cloud this issue is not present.
It could be either a cloud network problem or a Bintray CDN problem, or something else. Although the hosts are accessible all of the time - they are not getting down or frozen.
I think we should handle such problems. A possible work around, which I've successfully tested:
In the common role add these yum repositories:
#bintraybintray-ciscocloud-rpm - packages by ciscocloud from Bintray
[bintraybintray-ciscocloud-rpm]
name=bintray-ciscocloud-rpm
baseurl=https://dl.bintray.com/ciscocloud/rpm
gpgcheck=0
enabled=1

#bintraybintray-asteris-mantl-rpm - packages by asteris from Bintray
[bintraybintray-asteris-mantl-rpm]
name=bintray-asteris-mantl-rpm
baseurl=https://dl.bintray.com/asteris/mantl-rpm
gpgcheck=0
enabled=1

Then for all packages:
   yum:
-    name: https://bintray.com/artifact/download/asteris/mantl-rpm/consul-template-0.12.2-1.x86_64.rpm
+    name: consul-template-0.12.2-1

So I've tested and this change works well for all environments.
There are some minor issues though. Why do some repos are in CiscoCloud and some in Asteris? There should be one company, in my opinion. Moreover, there are some packages that are installed from completely 3-rd party repos.
Also, looks like metadata is broken in some packages. I'm able to do:
yum install consul-template-0.12.2-1

but not:
yum install distributive-0.2.4-1

Thanks! This sorely needed.

Also see #1188. We'd like to get a single repo.

this is mostly addressed by #1204 and #1193. #1188 captures the singe repo issue. thanks!


How can I use "v-runtime-template" with "

I don't see how to set "components" ?

+1 to the above.
It seems to have trouble with ref variables in setup scripts, however interestingly it appears to be ok with props.
To test things out, I'm using the default vite / vue-ts setup, bringing in v-runtime-template, and then attempting to use the {{count}} variable which is defined as const count = ref(0) in the

<template>

{{ msg }}

  <v-runtime-template :template="template"></v-runtime-template>
</template>

The rest of the template renders, but the count does not display and the console shows the following error:
Property "count" was accessed during render but is not defined on instance.

If we could even bind variables directly against the <v-runtime-template /> element for use within the template (for example, <v-runtime-template :count="count" />) , that would go a long way.
By the way, thanks for providing this library -- it's something that I've looked around for in the past, and it's neat!

Hey @s5b,
I've found a workaround which is not mentioned in the documentation.
In the source for the component, there is a special property that is referenced named templateProps.
You seem to be able to supply an object with additional properties to pass through.
In your case, you should be able to do something like the code block below.
The important changes are the addition of the :template-props binding on the <v-runtime-template> component, and the addition of the const templateProps = {thing} in the script.
<template>

Product

    <v-runtime-template :template="productContent" :template-props="templateProps"></v-runtime-template>

</template>

I hope that's helpful!

Hello, @vector-kerr
That is great! And thanks for the reply.
My need for this code has been parked for a while, and just this coming week will be bringing that need back to the fore. What fabulous timing!
This week I was planning to have a closer read of the source for the component, but you appear to have saved me the effort. Thank you so very much; very helpful indeed.

hi i have used vue3 with sfc to, but when use @click on template (button), thats not fire


[GraphQL] Cache chain identifier & use ticks

Description
We cache the chain identifier & use ticks instead of sleep() on the loop (to keep our queries consistently on self.sleep duration, instead of self.sleep + query time, as suggested by @amnn !
Test plan
How did you test the new or updated feature?

Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

[ ] Protocol:
[ ] Nodes (Validators and Full nodes):
[ ] Indexer:
[ ] JSON-RPC:
[ ] GraphQL:
[ ] CLI:
[ ] Rust SDK:
[ ] REST API:

So following a rebase onto main, I think this PR will now need to incorporate @emmazzz's changes around indexing the chain identifier explicitly.


Hardcoded localhost prevents remote use

It appears that some things in the client are hardcoded to connect to "localhost", which means shader-school can't be used from a remote location. More specifically "localhost:12491/changes" is what it's trying to connect to.
This could probably be fixed by creating the url dynamically like this
var url = 'http://' + window.location.host + '/changes'
With a quick search I couldn't find anything related to "/changes" in this repo, so I'm not sure if this issue is relevant to shader-school itself.

Yep, this is a problem for me too, shall I submit a pull request?

This was being caused by a dependency of shader-school, glslify-live. I have submitted a pull request to the author of that package with the fix. https://github.com/hughsk/glslify-live/pull/6
Once that is merged, because it is not a breaking change it should only warrant a patch version bump and should get picked up by shader-school automatically. A simple npm install -g shader-school again will get the change.


Changed CONTRIBUTING.rst

As per setup.cfg, installation requires python>=3.5. So, 'pip3' should be used instead of 'pip'. At times using pip might throw an error.
Also, during my installation, I tried using relative path but it throws an error and when I tried with the absolute path everything worked fine. I don't know, if I made some blunder in relative path case, due to which I was getting the error. But, in similar scenarios, it is always a good practice to ask people to use an absolute path in the documentation. As this will be less prone to human error. So, I made changes corresponding to this also.

@Juanlu001 can you please review the changes?

Also, during my installation, I tried using relative path but it throws an error and when I tried with the absolute path everything worked fine. I don't know, if I made some blunder in relative path case, due to which I was getting the error.

Can you please describe which error? I normally do pip install -e .[dev] which works without problems.

Closing, but feel free to continue discussing here or in our chat.