ReferenceError: fetch is not defined on MacOS

I installed danger-swift with homebrew on my MacBookPro M3.
When I run e.g. danger-swift pr https://xxx/merge_requests/300 I receive the following error message.
The same error message appears in my Gitlab based CI pipeline with danger-swift ci --remove-previous-comments --verbose --trace-warnings
Any ideas what's going wrong?
Error:  ReferenceError: fetch is not defined
    at defaultRequestHandler (/snapshot/danger-js/node_modules/@gitbeaker/rest/dist/index.js:101:22)
    at Object.requester.<computed> [as get] (/snapshot/danger-js/node_modules/@gitbeaker/requester-utils/dist/index.js:53:16)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at process.runNextTicks [as _tickCallback] (node:internal/process/task_queues:65:3)
    at Function.runMain (pkg/prelude/bootstrap.js:1980:13)
    at node:internal/main/run_main_module:17:47
    at async /snapshot/danger-js/node_modules/@gitbeaker/core/dist/index.js:105:22

I also tested again the public repo mentioned in Getting Started with Danger - Test Locally. Same issue. Seems it has to do something with my macOS setup.
danger-swift pr https://github.com/danger/swift/pull/146

Not sure how you control your instance of Node - but it will need updating to get rid of this issue

I haven't installed Node at all. I just installed danger globally as I did it on my old MacBook a year ago. I followed these instructions.
https://danger.systems/swift/guides/getting_started#homebrew
I also tried to install latest node version vie brew. But without any effect.

Same issue when running danger-swift pr.
> node --version
v22.2.0
> which node
/opt/homebrew/bin/node
> danger-swift --version
3.18.1
> which danger-swift
/opt/homebrew/bin/danger-swift

The issue has been solved by https://github.com/danger/danger-js/issues/1448

The issue has been solved by https://github.com/danger/danger-js/issues/1448


Validate field value against the type

Is it possible to validate field value against the type. The following should produce an error:
class public Test
  field public BBjNumber DrawerBreakpoint! = "(max-width: 800px)"
classend

The value is a string but the type is BBjNumber

@hyyan
To fully support the type inference and validation we need a type system implementation. Implementing a type system is normally very time consuming. For simple or clear cases like above, we could provide a validation. Here we need to know that BBjNumber is a number type and a string literal is not convertible to a number.
What would probably help in some other cases is checking the variable name prefix, but for ! it will not work as java.lang.String is also an Object

For simple or clear cases like above, we could provide a validation. Here we need to know that BBjNumber is a number type and a string literal is not convertible to a number.
What would probably help in some other cases is checking the variable name prefix, but for ! it will not work as java.lang.String is also an Object

@dhuebner  That would be completely fine. We would like to cover only simple and obvious cases at the moment. Once we have a good understanding of the challenges involved, we can then start to work on more complex cases.


Use retworkx

Summary
This PR switches the graph library used for the DAGCircuit class to use retworkx[1] instead of networkx. This provides a significant speed up over networkx because retworkx is written in rust instead of pure python.
[1] https://github.com/mtreinish/retworkx
Details and comments
Co-Authored-By: Lauren Capelluto<EMAIL_ADDRESS>

I can see #2860 uses NetworkX max_weight_matching and floyd_warshall algorithms. Do you have any sense of how easy these are to implement?
#3762 (which is a restricted version of the above) also uses NetworkX's dfs_edges, floyd_warshall_numpy, find_cycle. Plus a bunch of other methods for building simple graphs for testing. Can it continue to use NetworkX (potentially taking the performance hit)?

I'll have to look into those algorithms to see how they work, but none of the algorithms I've looked at so far have been difficult to implement. We can open issues about those on the retworkx repo. dfs_edges  should be very easy to implement since there is builtin traverser in the dag library used in retworkx: https://docs.rs/petgraph/0.5.0/petgraph/visit/struct.Dfs.html . find_cycle doesn't really apply to the PyDAG class because at least for right now it's checking that we don't introduce a cycle whenever an edge is added.
You can continue to use networkx with this pr, if you want it from the dagcircuit class you can do to_networkx() and it will return a networkx MultiDiGraph object like what was there before using retworkx: https://github.com/Qiskit/qiskit-terra/pull/3810/files#diff-feb434f18758792899804d6e18c57707R85-R94 I added this for compatibility with the dag drawer (which uses network. It's a one way transformation right now so DAGCircuit->networkx.MultiDiGraph but there is no reverse method for going from networkx to DAGCircuit here.

Just for an idea of the speed up this provides the travis results for benchmarks show this pretty well: https://travis-ci.com/Qiskit/qiskit-terra/jobs/286130264#L1493

I'll have to look into those algorithms to see how they work, but none of the algorithms I've looked at so far have been difficult to implement. We can open issues about those on the retworkx repo. dfs_edges should be very easy to implement since there is builtin traverser in the dag library used in retworkx: https://docs.rs/petgraph/0.5.0/petgraph/visit/struct.Dfs.html . find_cycle doesn't really apply to the PyDAG class because at least for right now it's checking that we don't introduce a cycle whenever an edge is added.
You can continue to use networkx with this pr, if you want it from the dagcircuit class you can do to_networkx() and it will return a networkx MultiDiGraph object like what was there before using retworkx: https://github.com/Qiskit/qiskit-terra/pull/3810/files#diff-feb434f18758792899804d6e18c57707R85-R94 I added this for compatibility with the dag drawer (which uses networkx). It's a one way transformation right now so DAGCircuit->networkx.MultiDiGraph but there is no reverse method for going from networkx to DAGCircuit here.

I recently pushed out retworkx 0.3.0 to speed things up further by defaulting off the cycling checking, and adding a function to implement multigraph_layers(). Also, as part of that release @lcapelluto wrote an implementation of floyd_warshall for retworkx too (https://retworkx.readthedocs.io/en/stable/api.html and https://github.com/mtreinish/retworkx/pull/26).
However, looking at the 2 PRs adding new passes it looks like they're constructing additional directed and undirected graphs for tracking the coupling map and other aspects of the algorithms being added which are outside of the dagcircuit class. Right now retworkx only has PyDAG class which was written assuming being used by dagcircuit. However, in the future we're planning to add types for a generic directed and undirected graph (https://github.com/mtreinish/retworkx/issues/20 ) which could be used by the passes in those PRs once implemented. I was just prioritizing the dagcircuit to start because it has the bigger impact on performance.

Ok #3762 is going to merge soon, can you rebase after that? Hopefully not much needs changing. Then I'll take another look

Ok #3762 is going to merge soon, can you rebase after that? Hopefully not much needs changing. Then I'll take another look

Taking a quick look at #3762 I don't think there will be any changes needed, since it only interacts with the dagcircuit api which doesn't change here, but I'll rebase it after it merges and keep an eye on it.

I just ran the tests locally after rebasing and everything worked fine without any changes

After our discussion earlier today I've been thinking more about how we can provide a fallback for the next release in case something unforeseen comes up. Besides merging this sooner so we have time to test and debug any issues that arise, I was thinking  maybe adding a copy of the existing networkx DAGCircuit class and freezing changes to DAGCircuit's api for the rest of the release. Then when 0.13.0 is released we delete that fallback copy. So instead of having to keep up with changes and having a dual maintenance problem we just agree to not change the api until after the release (or an alternative abstraction layer on top of dagcircuit). Then if a user encounters an unforeseen issue with the new library they can just monkey patch circuit_to_dag and dag_to_circuit to use the fallback class until we get a bugfix release out. Thoughts @kdk @1ucian0 @ajavadia @ewinston ?

I'm on board with this idea. Two comments:

It would be better to have the networkx/retworkx toggle set by say an environment variable. Monkey patching the converters might not be entirely straightforward for users, and requires restarting a session. (We would have to check that the env variable propagates through e.g.  parallel_map across platforms.)

For the rollout, I'd vote for having 1) announce retworkx as opt-in, 2) default retworkx+deprecate networkx, and 3) remove networkx as separate steps, at one release each. This puts the process relatively on par with our standard deprecation policy and allows some time for issues to arise and be reported.

For the dual maintenance issue, I don't expect it will be a huge problem, DAGCircuit doesn't generally see a ton of activity: https://github.com/Qiskit/qiskit-terra/commits/master/qiskit/dagcircuit/dagcircuit.py . CI coverage would be more difficult though. Maybe convert current CI jobs to retworkx and add one compatibility job for networkx.

I'm on board with this idea. Two comments:
* It would be better to have the networkx/retworkx toggle set by say an environment variable. Monkey patching the converters might not be entirely straightforward for users, and requires restarting a session. (We would have to check that the env variable propagates through e.g.  `parallel_map` across platforms.)

Sure we can do this, monkey patching just seemed the easiest to me if we documented it in the release note (since it wouldn't require adding anything to the code).

* For the rollout, I'd vote for having 1) announce retworkx as opt-in, 2) default retworkx+deprecate networkx, and 3) remove networkx as separate steps, at one release each. This puts the process relatively on par with our standard deprecation policy and allows some time for issues to arise and be reported.

I still think making it opt-out is a better approach here. This isn't really a deprecation it's a new feature (significantly improved performance) and we don't normally go through such a conservative process for new features. There will always be bugs (and often are in new features), but I agree that since this is such a core piece of terra being a bit more conservative makes sense. So I'd rather we give users a relief valve in case we're missing something and they encounter a bug. So we don't push out a release that breaks someone with no alternative. If we make it opt-in I doubt most users will ever see it until we flip the switch for real and then we're just delaying finding any potential bugs we're missing until that future date.

For the dual maintenance issue, I don't expect it will be a huge problem, DAGCircuit doesn't generally see a ton of activity: https://github.com/Qiskit/qiskit-terra/commits/master/qiskit/dagcircuit/dagcircuit.py . CI coverage would be more difficult though. Maybe convert current CI jobs to retworkx and add one compatibility job for networkx.

The reason I'm concerned about dual maintenance is that there are at least 2 or 3 PRs open right now besides this one which touch the DAGCircuit API: https://github.com/Qiskit/qiskit-terra/pull/3772, https://github.com/Qiskit/qiskit-terra/pull/3503, and https://github.com/Qiskit/qiskit-terra/pull/3860 (or docs in the case of this one). It's true in general there aren't many changes but I'd rather just have us make sure we're agreeing to minimize changes during the period of having multiple copies. Otherwise we're basically making us duplicate all the work

* For the rollout, I'd vote for having 1) announce retworkx as opt-in, 2) default retworkx+deprecate networkx, and 3) remove networkx as separate steps, at one release each. This puts the process relatively on par with our standard deprecation policy and allows some time for issues to arise and be reported.

I still think making it opt-out is a better approach here. This isn't really a deprecation it's a new feature (significantly improved performance) and we don't normally go through such a conservative process for new features. There will always be bugs (and often are in new features), but I agree that since this is such a core piece of terra being a bit more conservative makes sense.

I think that's the key concern. Unlike adding a new feature, this is a restructuring that affects nearly every qiskit user.

So I'd rather we give users a relief valve in case we're missing something and they encounter a bug. So we don't push out a release that breaks someone with no alternative. If we make it opt-in I doubt most users will ever see it until we flip the switch for real and then we're just delaying finding any potential bugs we're missing until that future date.

The goal of a release of opt-in is increasing exposure beyond the terra development team, to the broader community and those with an active performance problem that could be addressed by retworkx.  True there will always be bugs, but a rollout helps us gauge rough scale and severity, and more importantly, to learn early in the transition if there are users or use cases for which the new structure is difficult or not viable.  From all the work on retworkx, we don't expect it will be, but there will always be unforeseen issues.

For the dual maintenance issue, I don't expect it will be a huge problem, DAGCircuit doesn't generally see a ton of activity: https://github.com/Qiskit/qiskit-terra/commits/master/qiskit/dagcircuit/dagcircuit.py . CI coverage would be more difficult though. Maybe convert current CI jobs to retworkx and add one compatibility job for networkx.

The reason I'm concerned about dual maintenance is that there are at least 2 or 3 PRs open right now besides this one which touch the DAGCircuit API: #3772, #3503, and #3860 (or docs in the case of this one). It's true in general there aren't many changes but I'd rather just have us make sure we're agreeing to minimize changes during the period of having multiple copies. Otherwise we're basically making ourselves duplicate all the work

There are a few ways we can manage dual implementations, but I wouldn't want to forgo a rollout to ease this process. (None of those three PRs are urgent.)

* For the rollout, I'd vote for having 1) announce retworkx as opt-in, 2) default retworkx+deprecate networkx, and 3) remove networkx as separate steps, at one release each. This puts the process relatively on par with our standard deprecation policy and allows some time for issues to arise and be reported.

I still think making it opt-out is a better approach here. This isn't really a deprecation it's a new feature (significantly improved performance) and we don't normally go through such a conservative process for new features. There will always be bugs (and often are in new features), but I agree that since this is such a core piece of terra being a bit more conservative makes sense.

I think that's the key concern. Unlike adding a new feature, this is a restructuring that affects nearly every qiskit user.

So I'd rather we give users a relief valve in case we're missing something and they encounter a bug. So we don't push out a release that breaks someone with no alternative. If we make it opt-in I doubt most users will ever see it until we flip the switch for real and then we're just delaying finding any potential bugs we're missing until that future date.

The goal of a release of opt-in is increasing exposure beyond the terra development team, to the broader community and those with an active performance problem that could be addressed by retworkx.  True there will always be bugs, but a rollout helps us gauge rough scale and severity, and more importantly, to learn early in the transition if there are users or use cases for which the new structure is difficult or not viable.  From all the work on retworkx, we don't expect it will be, but there will always be unforeseen issues.

For the dual maintenance issue, I don't expect it will be a huge problem, DAGCircuit doesn't generally see a ton of activity: https://github.com/Qiskit/qiskit-terra/commits/master/qiskit/dagcircuit/dagcircuit.py . CI coverage would be more difficult though. Maybe convert current CI jobs to retworkx and add one compatibility job for networkx.

The reason I'm concerned about dual maintenance is that there are at least 2 or 3 PRs open right now besides this one which touch the DAGCircuit API: #3772, #3503, and #3860 (or docs in the case of this one). It's true in general there aren't many changes but I'd rather just have us make sure we're agreeing to minimize changes during the period of having multiple copies. Otherwise we're basically making ourselves duplicate all the work

There are a few ways we can manage dual implementations, but I wouldn't want to forgo a rollout to ease this process. (None of those three PRs are urgent.)

This has been superseded by https://github.com/Qiskit/qiskit-terra/pull/3916 which makes the DAGCircuit switchable and defaults to retworkx. This will give users an option to fallback to networkx for the 0.13.0 release. So I'm closing this I won't delete the branch though to keep this as a reference.


Reflecting Kotlin Optionality

Hello! I'm using this library with Kotlin and I'd love a way to have the schema reflect whether or not a field is nullable based on whether or not the reflected type is maked as optional in Kotlin.
e.g.
data class User(val firstName: String, val lastName: String?, address: Address)

data class Address(address1: String, address2?: String, city: String, zip: String)

and have the schema be generated like so (note the placement of !s is inverse to placement of ?s):
type User {
  firstName: String!
  lastName: String
  address: Address!
}
type Address {
  address1: String!,
  address2: String,
  city: String!,
  zip: String!
}

My understanding is that this limitation is due to the fact that the type introspection is based on the Java types which don't support optionals. I think all that would be needed to implement this behavior myself would be a way to get at the KType for fields in a SchemaTransformer. Curious if anybody has run into that need as well
This library is great by the way, thanks!

sorry not sure how i opened 2 of these


chore(deps): update storybook monorepo to ^6.5.0-beta.6 (patch)

This PR contains the following updates:

Package
Type
Update
Change

@storybook/addon-a11y
devDependencies
patch
^6.5.0-beta.1 -> ^6.5.0-beta.6

@storybook/addon-actions
devDependencies
patch
^6.5.0-beta.1 -> ^6.5.0-beta.6

@storybook/addon-essentials
devDependencies
patch
^6.5.0-beta.1 -> ^6.5.0-beta.6

@storybook/addon-interactions
devDependencies
patch
^6.5.0-beta.1 -> ^6.5.0-beta.6

@storybook/addon-links
devDependencies
patch
^6.5.0-beta.1 -> ^6.5.0-beta.6

@storybook/addons
devDependencies
patch
6.5.0-beta.1 -> 6.5.0-beta.6

@storybook/builder-webpack5
devDependencies
patch
^6.5.0-beta.1 -> ^6.5.0-beta.6

@storybook/client-api
devDependencies
patch
6.5.0-beta.1 -> 6.5.0-beta.6

@storybook/manager-webpack5
devDependencies
patch
^6.5.0-beta.1 -> ^6.5.0-beta.6

@storybook/preview-web
devDependencies
patch
6.5.0-beta.1 -> 6.5.0-beta.6

@storybook/react
devDependencies
patch
^6.5.0-beta.1 -> ^6.5.0-beta.6

Configuration
📅 Schedule: "every weekend" in timezone Asia/Tokyo.
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: yarn.lock
sed: can't read /home/user/yarn-slim/2.4.3/lib/node_modules/yarn/lib/cli.js: No such file or directory


other: update sbt-java-formatter from 0.6.1 to 0.7.0

Updates com.lightbend.sbt:sbt-java-formatter from 0.6.1 to 0.7.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.lightbend.sbt", artifactId = "sbt-java-formatter" } ]

labels: sbt-plugin-update, early-semver-major, semver-spec-minor

Codecov Report

Merging #52 (2e08777) into master (7dfcf51) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff             @@
##              master       #52   +/-   ##
===========================================
  Coverage     100.00%   100.00%
  Complexity        29        29
===========================================
  Files              1         1
  Lines            114       114
  Branches           8         8
===========================================
  Hits             114       114

Continue to review full report at Codecov.

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


[New Feature]: Adding contributors section to the readme.md file.

Description of the new feature/enhancement
There is no Contributors section in readme file .
As we know Contributions are what make the open-source community such an amazing place to learn, inspire, and create.
Any contributions make are greatly appreciated, for that we need to add new section for contributors and adding to the readme file!
Proposed technical implementation details (optional)

@mtodd kindly assign me this #122859 issue I want to work on it.

@Kalyanimhala - This repo has over 2400 contributors. I'm not sure that it's reasonable to add a contributors section to the readme recognizing them all. Winget-Pkgs isn't quite like other open-source repositories

@Trenly  Ok thanks, no issues.

OK, I'll go ahead and close this issue as not planned.


Size of dropdown list with previously opened files

There is a dropdown list which contain previously opened files. But it is limited by 10 items. It will be
useful to have scrollbar or an option to specify a number of items in this dropdown list. If this is possible could you add this to config?

Great suggestion, I fixed the menu so it has a history of 20 and the dropdown combo location box now has a history of 1000, I also enabled auto-completion in the combobox so as you type the list is automatically filtered to show matching file names.   Hopefully these changes make the history more useful.  This is fix is available in version 2.8.012.

Thank you very much, much better now.


fix(ipfs-config): Removed ipfs-config directory for improved startup

:tada: This PR is included in version 1.1.2 :tada:
Your semantic-release bot :package::rocket:


Cannot running on iOS devices

Can't find variable: IntersectionObserve

Solution
Find a new way to implement anchor following feature

use scroll event instead of scrollma (intersection-observer) d7069e6


2.0 Cable availability

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
{ D435 }

Firmware Version
(-)

Operating System & Version
{Win (8.1/10) / Linux (Ubuntu 14/16/17) / MacOS

Kernel Version (Linux Only)
(e.g. 4.14.13)

Platform
-

SDK Version
{ legacy / 2.. }

Language
{- }

Segment
{Robot/Smartphone/VR/AR/others }

Issue Description
<Describe your issue / question / feature request / etc..>
Hello.
I have a few questions to ask
Is there no problem with the D435 camera if I use 2.0 cable?
Please let me know the recommended specifications

Hi @ky047  RealSense cameras are compatible with USB 2.1.  The range of supported resolution and FPS speed combinations is limited though compared to USB 3.2 and the Infrared 2 stream (right-side infrared) will be unavailable.  A USB2 connection also has a slower data transfer speed than USB3.

It only affects transmission speed and FPS,
Does the 2.0 cable not affect the recognition of the camera?

No, it does not affect recognition of the camera.

Is there any case where 3.0 cable has a high recognition rate or 2.0 cable has a low recognition rate?

The chances of the cable working successfully with RealSense cameras are reduced if:

The cable is low quality or is an inexpensive one designed only for device charging instead of data transfer.

A USB C to C cable is used instead of USB A to C (full size connector on one end and micro-sized connector on the other end, like the official cable supplied with the camera).

In general though, if a high quality USB A to C cable is being used then the success of the camera being correctly recognized when inserted into the USB port is likely to be more dependent on the computer that is being used with the camera and not the cable.

Thank you for checking it out
It doesn't matter if you close the case
Have a good day

You are very welcome.  As you suggested, I will close this case.  Thanks again!


Optionally pass link attributes to contact website

 Add off-site link tracking

Should probably add this same behavior to company website too, unless that doesn't apply with the custom company layouts?

@solocommand What does "same behavior to company website" refer to?


refactor!: Align CommandBody::{Search,Sort} with RFC

Closes #410
Note: This is a small but still breaking change.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 93.413%

Totals

Change from base Build<PHONE_NUMBER>:
0.04%

Covered Lines:
9232

Relevant Lines:
9883

💛  - Coveralls


Repository organisation for Flux?

Hi,
I am trouble understanding how flux is supposed to detect if there is a new version of an image.
We have a service called "fraas" that is made up of two containers "app" and "web". "app" is the app code and "web" is nginx webserver.
Suppose a developer makes a change to some code then pushes. This kicks off the CI pipeline to build the docker images they are pushed to:
{CUSTOMERID}.dkr.ecr.us-east-1.amazonaws.com/fraas:app
and
{CUSTOMERID}.dkr.ecr.us-east-1.amazonaws.com/fraas:web
So every time we make a change it builds new images and uses the same tags "app" and "web" is this correct?
Im guessing its not as it doesnt seem to auto-update the cluster for us.
How does flux know how to update the cluster?
I noticed that your flux helloworld example is using the image like:
quay.io/weaveworks/helloworld:master-a000001
and
quay.io/weaveworks/sidecar:master-a000001
So does that mean you have a separate image repository per sub-container then you tag based on the branch (e.g. "master") and the commit (e.g "a000001") ?
In which case our images should look like:
{CUSTOMERID}.dkr.ecr.us-east-1.amazonaws.com/fraas-app:master-a000001
and
{CUSTOMERID}.dkr.ecr.us-east-1.amazonaws.com/fraas-web:master-a000001
Is this correct? It shouldnt be too hard to have our CI do this but then im confused as to how flux knows which version to update the cluster with if the tag is continually changing?
Sorry for such a long-winded way of asking this question, I hope it makes sense I really appreciate all your hard work on flux and weaveworks cloud.

Hi @mikecann,
Your latter intuition is correct: the idea is to give each distinct image version its own tag. For our own use of flux, we use the branch and shortened git SHA1.
Flux looks at the image layer creation time to determine the ordering of images and selecting which is the most recent.
This is almost always fine but there are a couple of improvements that we will at some point make:

looking at a build time label to determine the ordering rather than using the layer creation time; this is because in some circumstances Docker will reuse an old image layer (if the contents are the same), and this upsets our ordering.
other modes of ordering and selecting the latest image, including using semver.
supporting image digests, which exactly identify an image, instead of tags

HTH!

This is the bit where lots of different approaches can work ..
You can filter the tags that are considered for automation, so you could have for example:

Dev gets fraas-web:dev-*
Prod gets fraas-web:prod-*

This is not super-well documented, but you can check fluxctl help policy for some details on how to set a filter. You would still have to have a script somewhere (e.g., CI) that's promoting the images by retagging them.
In the Weave Cloud infrastructure we use exactly the same set of image tags in dev and prod, and promote image versions manually. Each of the clusters has its own directory in the git repo (they might equivalently just have different git repos -- it would mean duplicating a bunch of stuff, but logically it wouldn't matter). One reason to prefer this is that it's easier to track problems with an image, since it's named the same everywhere.

Oh cool, thanks for those comments.
So I spent today experimenting a little more and cant seem to get flux to auto-update even though I think I have everything correctly configured.
So I started with a clean minkube and flux install with the following config:
---
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    flux.weave.works/automated: "true"
    flux.weave.works/tag.app: glob:app-kubernetes-*
    flux.weave.works/tag.web: glob:web-kubernetes-*
  name: fraas-deployment
spec:

  replicas: 1

  selector:
    matchLabels:
      app: fraas

  template:
    metadata:
      labels:
        app: fraas

    spec:

      containers:

        # This contains our laravel app, and the php runtime
        - name: app
          image:<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/fraas:app-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e
          ports:
            - containerPort: 9000

          # Our secret environment variables
          envFrom:
            - configMapRef:
                name: fraas.config

        # Web is the nginx webserver
        - name: web
          image:<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/fraas:web-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e
          ports:
            - containerPort: 80

      # To pull the docker images from a private repo
      # we need to supply AWS login credentials
      imagePullSecrets:
        - name: awsecr-cred
---
apiVersion: v1
kind: Service
metadata:
  name: fraas
spec:
  selector:
    app: fraas

  # Because we are running in minikube for now we
  # dont have a load balancer and are just using nodeport
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
      name: http

I also have a "gvweb" service but it looks pretty much the same as above.
When I deployed flux with it pointing to the repo that contained the above config we successfully had our cluster up and running, so far so good.
Now I made a change to the src for "fraas" and pushed it. The CI then built and pushed the image.
I waited some time expecting flux to now update but unfortunately it doesnt seem to have updated.
When I type fluxctl list-images I get the following:
± % fluxctl list-images                                                                                !1277
CONTROLLER                           CONTAINER  IMAGE                                                        CREATED
default:deployment/flux              flux       quay.io/weaveworks/flux
                                                |   master-3d56be4                                           23 Mar 18 16:00 UTC
                                                |   master-7f1b0fa                                           23 Mar 18 11:34 UTC
                                                |   master-0e970a1                                           22 Mar 18 15:14 UTC
                                                |   master-f220230                                           20 Mar 18 15:59 UTC
                                                |   master-866da34                                           20 Mar 18 00:52 UTC
                                                |   master-9da7c57                                           19 Mar 18 16:43 UTC
                                                '-> 1.2.5                                                    19 Mar 18 14:58 UTC
                                                    master-a3149f3                                           19 Mar 18 13:58 UTC
                                                    master-6576049                                           19 Mar 18 11:00 UTC
                                                    master-6492293                                           16 Mar 18 15:02 UTC
default:deployment/fraas-deployment  app<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/fraas
                                                |   web-kubernetes-effdbbaa4d5b9f14c0b8a6cf85799ab0b1205b58  28 Mar 18 04:07 UTC
                                                |   app-kubernetes-effdbbaa4d5b9f14c0b8a6cf85799ab0b1205b58  28 Mar 18 04:07 UTC
                                                |   web-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e  28 Mar 18 03:44 UTC
                                                '-> app-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e  28 Mar 18 03:44 UTC
                                                    web-kubernetes-d918e3865bd74516393a1ede8b26de67c8e0cc4d  28 Mar 18 03:07 UTC
                                                    app-kubernetes-d918e3865bd74516393a1ede8b26de67c8e0cc4d  28 Mar 18 03:07 UTC
                                                    web                                                      27 Mar 18 07:34 UTC
                                                    app                                                      27 Mar 18 07:34 UTC
                                     web<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/fraas
                                                |   web-kubernetes-effdbbaa4d5b9f14c0b8a6cf85799ab0b1205b58  28 Mar 18 04:07 UTC
                                                |   app-kubernetes-effdbbaa4d5b9f14c0b8a6cf85799ab0b1205b58  28 Mar 18 04:07 UTC
                                                '-> web-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e  28 Mar 18 03:44 UTC
                                                    app-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e  28 Mar 18 03:44 UTC
                                                    web-kubernetes-d918e3865bd74516393a1ede8b26de67c8e0cc4d  28 Mar 18 03:07 UTC
                                                    app-kubernetes-d918e3865bd74516393a1ede8b26de67c8e0cc4d  28 Mar 18 03:07 UTC
                                                    web                                                      27 Mar 18 07:34 UTC
                                                    app                                                      27 Mar 18 07:34 UTC
default:deployment/gvweb-deployment  app<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/gvweb
                                                |   web-kubernetes-45b3db01dd0713341a9f4ec6c70890ad51a296bb  28 Mar 18 03:06 UTC
                                                '-> app-kubernetes-45b3db01dd0713341a9f4ec6c70890ad51a296bb  28 Mar 18 03:06 UTC
                                                    web                                                      26 Mar 18 09:00 UTC
                                                    app                                                      26 Mar 18 09:00 UTC
                                     web<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/gvweb
                                                '-> web-kubernetes-45b3db01dd0713341a9f4ec6c70890ad51a296bb  28 Mar 18 03:06 UTC
                                                    app-kubernetes-45b3db01dd0713341a9f4ec6c70890ad51a296bb  28 Mar 18 03:06 UTC
                                                    web                                                      26 Mar 18 09:00 UTC
                                                    app                                                      26 Mar 18 09:00 UTC
default:deployment/memcached         memcached  memcached
                                                |   1                                                        14 Mar 18 06:26 UTC
                                                |   1.5                                                      14 Mar 18 06:26 UTC
                                                |   1.5.6                                                    14 Mar 18 06:26 UTC
                                                |   latest                                                   14 Mar 18 06:26 UTC
                                                |   1-alpine                                                 03 Mar 18 01:19 UTC
                                                |   1.5-alpine                                               03 Mar 18 01:19 UTC
                                                |   1.5.6-alpine                                             03 Mar 18 01:19 UTC
                                                |   alpine                                                   03 Mar 18 01:19 UTC
                                                |   1.5.5                                                    17 Feb 18 08:37 UTC
                                                |   1.5.5-alpine                                             13 Feb 18 22:48 UTC
                                                : (39 image(s) omitted)
                                                '-> 1.4.25                                                   24 May 16 03:02 UTC

So it looks like Flux successfully recognises that there are new images (effdbbaa4d5b9f14c0b8a6cf85799ab0b1205b58) but for some reason doesnt auto-update the cluster and im not sure why.
The only src change that was made to fraas is a one-line change of some HTML just so I can see a change on the screen. So I dont think its anything wrong with the container.
This is a few of the tail lines from the flux log:
ts=2018-03-28T05:14:43.282491733Z caller=images.go:18 component=sync-loop msg="polling images"
ts=2018-03-28T05:14:47.287226045Z caller=images.go:57 component=sync-loop service=default:deployment/gvweb-deployment container=app currentimage={AWSID}.dkr.ecr.us-east-1.amazonaws.com/gvweb:app-kubernetes-45b3db01dd0713341a9f4ec6c70890ad51a296bb repo=080666409137.dkr.ecr.us-east-1.amazonaws.com/gvweb pattern=app-kubernetes-*
ts=2018-03-28T05:14:47.287302442Z caller=images.go:57 component=sync-loop service=default:deployment/gvweb-deployment container=web currentimage=080666409137.dkr.ecr.us-east-1.amazonaws.com/gvweb:web-kubernetes-45b3db01dd0713341a9f4ec6c70890ad51a296bb repo=080666409137.dkr.ecr.us-east-1.amazonaws.com/gvweb pattern=web-kubernetes-*
ts=2018-03-28T05:14:47.287328667Z caller=images.go:57 component=sync-loop service=default:deployment/fraas-deployment container=app currentimage=080666409137.dkr.ecr.us-east-1.amazonaws.com/fraas:app-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e repo=080666409137.dkr.ecr.us-east-1.amazonaws.com/fraas pattern=app-kubernetes-*
ts=2018-03-28T05:14:47.287346637Z caller=images.go:62 component=sync-loop service=default:deployment/fraas-deployment container=app currentimage=080666409137.dkr.ecr.us-east-1.amazonaws.com/fraas:app-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e msg="added image to changes" newimage=080666409137.dkr.ecr.us-east-1.amazonaws.com/fraas:app-kubernetes-effdbbaa4d5b9f14c0b8a6cf85799ab0b1205b58
ts=2018-03-28T05:14:47.287664824Z caller=images.go:57 component=sync-loop service=default:deployment/fraas-deployment container=web currentimage=080666409137.dkr.ecr.us-east-1.amazonaws.com/fraas:web-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e repo=080666409137.dkr.ecr.us-east-1.amazonaws.com/fraas pattern=web-kubernetes-*
ts=2018-03-28T05:14:47.287710494Z caller=images.go:62 component=sync-loop service=default:deployment/fraas-deployment container=web currentimage=080666409137.dkr.ecr.us-east-1.amazonaws.com/fraas:web-kubernetes-36656675664820a24c5c4bce69d6dc6da999407e msg="added image to changes" newimage=080666409137.dkr.ecr.us-east-1.amazonaws.com/fraas:web-kubernetes-effdbbaa4d5b9f14c0b8a6cf85799ab0b1205b58
ts=2018-03-28T05:14:47.291973152Z caller=loop.go:102 component=sync-loop event=refreshed url=git@github.com:GenvisAU/FluxExperiments.git branch=master HEAD=9051480013109235dac1c7da19ba3a679a228fc5
ts=2018-03-28T05:14:47.29210873Z caller=loop.go:110 component=sync-loop jobID=eebc6a8e-54b6-7580-b1cf-483c563d4e66 state=in-progress
ts=2018-03-28T05:14:47.32092979Z caller=loop.go:120 component=sync-loop jobID=eebc6a8e-54b6-7580-b1cf-483c563d4e66 state=done success=false err="did not update expected containers: web"
ts=2018-03-28T05:15:41.9365045Z caller=release.go:61 component=cluster method=Sync cmd=apply args="--namespace default" count=4
ts=2018-03-28T05:15:42.93854736Z caller=release.go:100 component=cluster method=Sync cmd="kubectl --namespace default apply -f -" took=1.001850513s err=null output="service \"fraas\" unchanged\ndeployment \"fraas-deployment\" unchanged\ndeployment \"gvweb-deployment\" unchanged\nservice \"gvweb\" unchanged"
ts=2018-03-28T05:15:42.938616604Z caller=release.go:61 component=cluster method=Sync cmd=apply args= count=2
ts=2018-03-28T05:15:43.154901647Z caller=release.go:100 component=cluster method=Sync cmd="kubectl apply -f -" took=216.240087ms err=null output="configmap \"gvweb.config\" unchanged\nconfigmap \"fraas.config\" unchanged"

I think the interesting line in there is:
ts=2018-03-28T05:14:47.32092979Z caller=loop.go:120 component=sync-loop jobID=eebc6a8e-54b6-7580-b1cf-483c563d4e66 state=done success=false err="did not update expected containers: web"
Im not sure what did not update expected containers: web" means?

BTW, I would be happy to update the docs on tagging (https://github.com/weaveworks/flux/issues/912) once I understand how its supposed to work and ensure im not doing anything wrong

@mikecann There are a few caveats around the manifests that flux can update -- see https://github.com/weaveworks/flux/blob/master/site/requirements.md. In your case, I think the thing that preventing the updates is having the deployment and service in the same file. Simply putting the deployment in a separate file should be enough for flux to operate on it. Oh -- and outdent the containers one level, i.e., instead of
containers:
  - name: foo
    image: bar/v1

make it like
containers:
- name: foo
  image: bar/v1

Both are valid YAML, but for horrible regex-related reasons, flux is sensitive to the indentation of those specific blocks.
(Work is underway in #976 on removing some of these limitations, which arise because we try to preserve comments and whitespace.)

@squaremo Oh nice! Yes that fixed it, it now works as expected :+1:
I had read that requirements before but I guess I must have missed that point about them being in sepparate files.
Thank you very much for all your help.


Graph Ideas

I'd love anyone's ideas on what kinds of graphs baseball players desire that they currently do not have or do not have easy access to.

Here are some I've come up with:

Strike zone plotting like here (plotting where pitches fall using coordinates from Statcast data, plotting pitch speed zones, plotting pitch type zones)
A 3D view of a baseball field (to make a spray chart of a player's at-bats)
Swing plane to show the launch angle at which a batter swings like here

Each of the above ideas should be put into their own file and named as what their function is (ex: strike zone plotting file should be named as plotting.py).


Types-only support

This makes it possible to use this library with default-features = false and only get the openai types. This is useful for when you want to use it in environments that don't support tokio/reqwest (or when you just don't need them). My use case is storing ChatMessages in a database, which on the web front end can't run tokio.

Thanks!


[HOW-TO] First Example in Picamera2 Library Documentation Fails

Please only ask one question per issue!
What are the additional prerequisite packages to run the First Example in the Picamera2 Library user guide.
Describe what it is that you want to accomplish
I want to run A first example as documented on page 6.
Describe alternatives you've considered

from picamera2 import Picamera2, Preview
Glamor is enabled
Validated that v4l2-python3 is current:

$ python3 -m pip install v4l2-python3
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Requirement already satisfied: v4l2-python3 in /home/chowkidar/.local/lib/python3.9/site-packages (0.3.1)
$

Additional context
Traceback (most recent call last):
  File "/home/chowkidar/projects/picamera2/example1.py", line 27, in <module>
    from picamera2 import Picamera2, Preview
  File "/usr/lib/python3/dist-packages/picamera2/__init__.py", line 9, in <module>
    from .picamera2 import Picamera2, Preview
  File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 23, in <module>
    from picamera2.encoders import Encoder, H264Encoder, MJPEGEncoder, Quality
  File "/usr/lib/python3/dist-packages/picamera2/encoders/__init__.py", line 2, in <module>
    from .h264_encoder import H264Encoder
  File "/usr/lib/python3/dist-packages/picamera2/encoders/h264_encoder.py", line 5, in <module>
    from v4l2 import (V4L2_CID_MPEG_VIDEO_H264_I_PERIOD,
ImportError: cannot import name 'V4L2_CID_MPEG_VIDEO_H264_MAX_QP' from 'v4l2' (/home/chowkidar/.local/lib/python3.9/site-packages/v4l2.py)

------------------
(program exited with code: 1)
Press return to continue

Platform: Raspberry Pi 3 Model B Plus Rev 1.3
OS: Raspbian GNU/Linux 11 (bullseye)
Linux 14 6.1.32-v7+ #1656 SMP Wed Jun  7 11:31:19 BST 2023 armv7l GNU/Linux
$ sudo apt install python3-picamera2
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
python3-picamera2 is already the newest version (0.3.12-2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$

Hi, thanks for the report. Could you try fetching python-v4l2 from apt instead of pip? Or alternatively try a pip install from the git repo (using pip install git+https). I'm wondering if there's a problem with the maintenance of the pip package (this package was being maintained by the Foundation and the person who used to do it has since left, so maybe there's something that needs sorting out here). Thanks.

Will do as advised (fetch python3-v4l2 using apt instead of pip). Will report back here as a comment in due course. Thanks.
Regards.

Interim update:
Here is the console terminal window for basic detection of the v4l2 package:
>>> import v4l2
>>> import fcntl
>>> cp = v4l2.v4l2_capability()
>>> vd=open('/dev/video0', 'r')
>>> fcntl.ioctl(vd, v4l2.VIDIOC_QUERYCAP, cp)
0
>>> cp.driver
b'unicam'
>>> cp.card
b'unicam'

Will work on uninstall/reinstall shortly. Thanks.
Regards.

Hello @davidplowman,
Your suggestion worked flawlessly. I may have unwittingly done something that v4l2 was not comfortable in doing but now with:
Setting up python3-v4l2 (0.3.2-1) ...
Setting up python3-picamera2 (0.3.12-2) ...

I am back working with yet another deployment of picamera2 with slightly different hardware thanks again to your patience and understanding:
[0:24:02.885220866] [4411]  INFO Camera camera_manager.cpp:297 libcamera v0.0.5+83-bde9b04f
[0:24:02.937900392] [4418]  WARN RPI vc4.cpp:383 Mismatch between Unicam and CamHelper for embedded data usage!
[0:24:02.939100067] [4418]  INFO RPI vc4.cpp:437 Registered camera /base/soc/i2c0mux/i2c@1/imx219@10 to Unicam device /dev/media2 and ISP device /dev/media0
[0:24:02.939186473] [4418]  INFO RPI pipeline_base.cpp:1101 Using configuration file '/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml'
[0:24:02.959456427] [4411]  INFO Camera camera.cpp:1033 configuring streams: (0) 640x480-XBGR8888 (1) 640x480-SBGGR10_CSI2P
[0:24:02.960474437] [4418]  INFO RPI vc4.cpp:565 Sensor: /base/soc/i2c0mux/i2c@1/imx219@10 - Selected sensor format: 640x480-SBGGR10_1X10 - Selected unicam format: 640x480-pBAA

------------------
(program exited with code: 0)
Press return to continue

You may have mentioned elsewhere something about the WARN message in this output. I don't know what "Mismatch between Unicam and CamHelper for embedded data usage" means but it is definitely above my job grade.
Many, many thanks for helping me to move along albeit at a slower pace (and some outdated hardware) but it helps me to incrementally refine solutions with diverse uses of picamera2.
Regards.


[IBMQ Backend] The load_qasm_string() function is deprecated and will be removed in a future release. Instead use QuantumCircuit.from_qasm_str().

Qiskit specifications changed.

The load_qasm_string() function is deprecated and will be removed in a future release. Instead use QuantumCircuit.from_qasm_str().

#68


feat: implement quantize module

This PR contains all the code for the quantize module that I ported from the other implementations. The tests located in quantizer_celebi.rs were the only ones I saw for the quantizer module in other implementations. All 6 are passing. The implementation could be improved and I think it could use more tests, but it falls in line with the others.
I added 2 dependencies:

rand - There are a few parts of the quantizer that require generating random values. Using the rand crate seems to be the defacto way to do that in Rust, as far as I know.
num - Great for writing generic numeric functions. Could live without, but I'd prefer to keep it. Could suffice with slimming down to num_traits because that is all I import from.

If you have any issues with these, let me know and we can figure it out from there.

Thanks a lot for porting the quantize module!


Rename workflows, fix formatting, and OSS project list

Explanation and justification
Misc

6d27010ea45eea33be538d9ff2cab6d2325febe1 makes all vertical whitespace consistent across workflow files and removes some of the non-typical line breaks in the workflow definitions
dbf28f2943b07f382b6a4510da01d34e335d4729 fixes MicroStream file formatting
9bd3099be084b01b58d9661884147d55ebe1a9b2 cleans up list of OSS projects in README, e.g., ASF was missing

Workflow renaming
I changed the workflow file names to more closely resemble the project's being run, e.g., JHipster's workflow is actually just a sample JHipster app.
These changes will cause the run history to disappear.

2febaebe3f1036e795f01205a34561239dc2af83 renames AndroidX biometric to AndroidX Biometric
cc96831e47957f08cbd9ea4af1222fd48a062fa1 removes hyphen from all Apache project names – "The ASF prefers you use the full Apache ProjectName name for all our projects." (ref)
10f06d1092793c6cd3ff5b0fec5f077a494a96ad renames Apollo to Apollo Kotlin
7a0f0989d6b8a922ea8b8171c7d4d715a355ec9a renames JHipster to JHipster Sample
289bc3760f093b62d742589f7f1b84f95b5330c8 renames Microstream to MicroStream
bd98129a10c23147df66b87b69f2989d4931826a renames OrderedProperties to Misc - Java Ordered Properties
8b86997aa0338eea745ecb9bb9de734f083d2b3d renames WrapperUpgrade to Misc - Wrapper Upgrade Gradle Plugin
58edea32f3a92a5d5c3c9abdd0f50c5b89b86a0f renames OpenAPI to OpenAPI Generator
e38cd72dbc6ae699ddf226b603749d2788224938 appends -concourse to run-experiments-openrewrite.yml
4b591ae4219be6319e44557d6bb911bd24edce03 renames Testcontainers to Testcontainers Java
70953042b7bc935f96f49e8d7ebf8865b08e935f renames XWiki to XWiki Commons

curious what we gain with some of these renames, since (I think) they will show up as entirely new workflows.

Yes, they will. Valid question on what we gain from doing this. It's really just better consistency. Capitalizing things that should be capitalized and more appropriately naming some workflows.


Type safe JsonPointer.get

I made this type because I wanted a type safe way to pull properties from an object via a path, and I thought it might be useful to this library. I chose to make any properties not found in the object never, but you could use unknown to keep current functionality if you wanted. Just thought I'd share.
type TakeProp<T extends string> = T extends `${infer Prop}/${string}` ? Prop : never

type TakeRest<T extends string> = T extends `${string}/${infer Rest}` ? Rest : T

type PathExtract<Value, Path extends string> =
    TakeProp<Path> extends never //if path type is not a path, get the prop from Value
        ? Path extends keyof Value
            ? Value[Path]
            : never
        : TakeProp<Path> extends keyof Value //check if prop is in value
            ? PathExtract<Value[TakeProp<Path>], TakeRest<Path>> //recurse
            : never //failure

const num: number = PathExtract<{a: {b: number}}, "a/b">

This currently does not cover ~0 and ~1 but i think with a little more work that could be figured out.

Finalized version. This one can handle decoding as well. Also cleaned up the types
//This is a big utility type to let us path walk a type with a string
export type SplitPath<T extends string> = T extends `${infer Prop}/${infer Rest}` ? [Prop, Rest] : [unknown, T]

//Deal with json pointer encoding
export type Decode<T extends string> =
    T extends `${infer A}~0${infer B}` ? `${Decode<A>}~${Decode<B>}` :
    T extends `${infer A}~1${infer B}` ? `${Decode<A>}/${Decode<B>}` :
    T

export type ExtractProp<Value, Prop extends string> =
    //try to see if prop is a number
    Prop extends `${number}` ?
        number extends keyof Value ? Value[number] :
        unknown :
    //check if prop is in value
	Decode<Prop> extends keyof Value ? Value[Decode<Prop>] : unknown

export type PathExtract<Value, Path extends string> =
    Extract<Value, SplitPath<Path>[0], SplitPath<Path>[1]>

export type Extract<Value, Prop, Rest extends string> =
    Prop extends string ? PathExtract<ExtractProp<Value, Prop>, Rest> :
    ExtractProp<Value, Rest>

amazing job! so we have template literals now in TS? been waiting for soo long!

wow this is cool!


fix: remove class lock in task

What this PR does / why we need it:
fix: remove class lock in task

Does this PR need to be backport to the previous release branch?:

release/3.10

/cc @wanyaoqi @zexi @ioito

/lgtm


Resolve issue #2 - Use https

Thanks a lot @zstadler for your contribution. Really appreciate that.


Could not find any element matching selector '#app'

Hi @mingyaulee ,
Thank you for the amazing repo, and fast bug fix.
I would like to post the problem when loading content script with your sample repo. When upgrading to the latest version the extension couldn't load content script and throw the error Could not find any element matching selector '#app', but it worked with the version 1.4.0

Reproduce
Upgrade your package to version 1.5.1

Thanks for reporting this finding! It's weird to be broken, I'll look into it.

I am unable to reproduce it after upgrading to v1.5.1. I have tried to just publish and clean + publish, both loads the sidebar just fine. Are you loading the extension from the publish output (dist/browserextension) or the build output?

I have upgraded the packages in the sample repo and tried out all of them. You can try it out there.

Closing due to inactivity


How to open a module folder ?

Ctrl + left click can go to module file ,   Breadcrumbs  is show on the top, but can't be opened :
There is even not a copy option, I have to type the whole path in terminal , cd and open vscode in there.

@eromoe We don't control that in the extension. This would be a feature request on VSCode.

Closing this, since this should be handled by VSCode itself, and not in the extension. Please file the issue on VSCode.


feature/DBC22-593

Merge https://github.com/bcgov/DriveBC.ca/pull/21 and rebase before closing this.

LGTM


set angle via url parameter in filter view

Our Tensionboard is normally set to a fixed angle. With the current filter-view you couldn't preselect an angle via URL (for example as bookmark).
This PR selects the angle in /filter if a (valid) param.angle is set in the URL. This allows to bookmark a board URL with angle preselected. Value is only selected if the option is available, otherwise the "any" option stays selected.

Seems fine to me, but maybe we eventually want a way for the less technical user to access this functionality? I'll create an issue for it but get this deployed in the meantime.

True. Like a bookmark board or bookmark/share climb feature, like it was discussed in another issue.


CORS policy issue

Hi Guys,
Amazing editor based on the example and my almost-working code. This is probably not a problem with your package, but something I'm not doing in my Angular and/or hosting (Firebase) configuration. I am getting the following error when I run locally or from the live site:
Access to Image at 'https://firebasestorage.googleapis.com/...' from origin 'https://firebasestorage.googleapis.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https:// ... .firebaseapp.com' is therefore not allowed access.
I've searched SO and found a five page answer to the problem, but thought maybe you have run into this already and know precisely (that is to say, in less than five pages) how to fix the problem.
Thanks in advance,
Ashley

Per SO five-page answer, I added a cors proxy to my photo url and it removed the previous error, but is giving me a new error: "400 (Header required)"
The revised code based on your example code:
    openEditor(photo: Photo) {
        const proxyurl = "https://cors-anywhere.herokuapp.com/";
        const dialogRef = this.dialog.open(NgxImageEditorComponent, {
            width: '800px',
            height: 'auto',
            data: {
                name: photo.name,
                url: proxyurl + photo.url,
                type: 'image/jpeg'
            }
        });

        dialogRef.afterClosed().subscribe(result => {
            console.log('The editor was closed');
            console.log(result);
        });
    }

I will continue to work the problem and report back if I figure out anything.
Thanks,
Ashley

@Taulantdisha

@1wiseash if you are using firebase images they have a token and yes we had this issue before and as far as i remember you need to cors-json-file in your project see https://cloud.google.com/storage/docs/gsutil/commands/cors


Enable coverage report in PRs

Use github actions to report code coverage in PRs.
Run tests for all frameworks explicitly.

we can probably remove the test assemblies?

I tried a few different things in runsettings, etc. and other places that were all recommended by docs and community posts, but nothing seems to work.


Add additional shards/segment graphs to remote write dashboard.

2.13.0 added new metrics for min/max/desired shards as well as the TSDB current segment and WAL watcher current segment.
This PR adds panels to the remote write dashboard in the mixin so that you can at a glance check if desired shards is > min or > max shards for any queue, and how far behind (in segments) a given queue may be.
cc @csmarchbanks
Signed-off-by: Callum Styan<EMAIL_ADDRESS>

waiting to hear from grafana folks about any scale limits for the first panel re: max_shards

@beorn7 PTAL; I rewrote the dashboard using grafonnet and I've made the two separate panels you suggested. For now I've only made the first panel repeat on the cluster label.
I'm not sure how I feel about the repeat feature, we're always refining the dashboard when we view it via the template variables. I feel like I'd rather not have the repeat and now have to scroll as much when all the template variables are set to All, but I think we should proceed as is and see how we feel when using the dashboard and if we get feedback from anyone else.

Repeating on everything will blow up things way too much, indeed. But I would prefer to have queue as the one variable to repeat on. If I want to analyze queue sharding and capacity, I'm most likely looking at a specific Prometheus instance, for which I want to see the queues next to each other. Also, queue numbers are kind of limited by nature. (You won't have dozens or hundreds of queues on a single Prometheus server, and in particular the number of queues doesn't really grow with the size of your org.) While the number of clusters and number of Prometheus instances grows with your org size and can thus blow up the dashboard size easily if on repeat.
I generally agree we should let this bake and see how useful it is before discussing further details. But then again, I think repeating on queue is the more conservative choice here as this might be used by orgs with dozens of clusters and hundreds of Prometheus instances.


Plugins page dropdown filter alignment fix

In the Plugin market place the category filter have misalignment for the some of the options .
current screen :

After fix in font size:

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

@benjdlambert fixed it as per your suggestions, let me know if any further changes needed


[Feature Request] Allow retention config per scrape job

I searched existing issues and didn't see this anywhere. We would like to keep our metrics scraped from a dev kubernetes cluster for only maybe a day or a few days, since pod churn there is huge (we create upwards of 50k new pods per day, each with hundreds of time series associated with them). However, we would like to keep metrics from production clusters for much longer. We want to use the same Prometheus instance to hold all the metrics, and this instance has different scrape jobs set up for the different clusters. It would be nice to be able to configure a different retention policy per scrape job, similar to scrape_interval.

In this case you want two different Prometheus servers. In general dev and prod should have distinct monitoring setups, and usually you'd also want a Prometheus per k8 cluster.

In our current state we would like to not have to run multiple prometheus servers. Perhaps eventually we will split into multiple servers, but for now we would like to have all our metrics in one place. There are likely many other use cases where having different retentions would be helpful. Can you comment on whether or not you would consider implementing this?

Dupe of #1381, don't expect it anytime soon. The recommended architecture is as I described above.


fixed issue number 83:84 Error for attention state missing

The problem is in the _compute_attention() function in line: 52
The attention state is required for the computations in the attention wrapper which is missing.
The attention_state has not been accounted for when calling the function and therefore the missing value is actually this next_attention_state that has not been passed on to the AttentionWrapper.

Hi,
Kindly look at the fixes and let me know if any improvements in the same are required.
Regards


Nico dev

Added a more complete and generic way of storing friends!

contingent on adding missing dir its good to go


The default status of the new GW is halted instead of running

Description
The default status of the new GW is halted however, the expected result should be running
Steps
Create a new GW using the basic parameters
List the containers and check the GW status
Actual result
Halted
Expected result
It should be running
SW versions
master

SV
b1e44aedf4b81233242be700ed08ec6b129a89f0


adding footer.jsx

@rgoodie @meltedspork 1st pass for footer as jsx component. review when you're able.

Can we close this?


To Reproduce
Steps to reproduce the behavior:

Add few 5-10 experiments.
View the order. It should be as per descending name.

Expected behavior
Sorting order should be descending name.
Screenshots

@amurphy-cl @danoswaltCL This issue is resolved and merged in dev. Should we close this?

I need to QA this.

This issue doesn't seem to be resolved. As you can see, the experiments with lowercase names get sorted first, followed by those with uppercase names. The sorting should happen in a case-insensitive manner.

@zackcl Will check this again and let you know. There is a lot of code pushed after the PR for this ticket was merged in dev.

QA: Zak

QA: Passed


Function outlining with -O3

Bumping llvm-opt from O2 to O3 improves perf with function outlining so much, with O3 perf with function outlining is better than without! Hopefully CI doesn't say other workloads are going OOM.
Update: Summary of findings (WIP)
We saw a ~2x decline in performance (time to run matmul) in our 3 benchmark sizes ((M, N, K) in [(512, 512, 4096), (512, 4096, 512), (4096, 512, 512)]. This is illustrated in PR https://github.com/nod-ai/iree-amd-aie/pull/919 where for each of the (M, N, K) dimensions, there is a run with and without function outlining. For example, for (4096, 512, 512) the time to run increases from 18 [ms] to 40 [ms] when outlining is enabled.
So we initially thought that the function call overhead of AIE is for some reason very large, but then Jorn pointed out that the ukernel approach uses function calls, and performance there is decent -- indeed with ukernels here the time is 11 [ms] (see https://github.com/nod-ai/iree-amd-aie/pull/919). And there are presumably as many function calls with ukernels as function outlining, so it can't just be overhead of function calls which is causing the slow down.
As an experiment I tried increasing the optimization level from llvm-opt from -O2 to -O3. With outlining enabled this results in some functions calls being inlined (of course this isn't possible with ukernels).
To check this, I first count the number of function calls with grep -r "call void @generic_matmul_0_outlined" file.name.ll | wc -l
Before llvm-opt there are 32 calls (this is the input.ll). After llvm-opt with O2 there are 64 calls. With O3 there are 16 calls.
Doing the same for the matmul instruction, so counting llvm.aie2.bf.mac16.conf:
Before llvm-opt: 2 appearances. After O2: 33 appearances. After O3:  545 appearances.  As a reference without outlining, there are 1024 appearances if there is no outlining, for both O2 and O3 (O2 and O3 produce exactly the same code without outlining).
The sizes of the elf files are different with O2 and O3 as well. The file core_1_2.elf is 9.8 KB with O2 and 13 KB with O3. As a reference without outlining enabled, at O2 and O3 the memory is 16 KB (for both).
Summary for (512, 4096, 512) matmul (see https://github.com/nod-ai/iree-amd-aie/actions/runs/12015758500/job/33494886925)
Current ToM:
vanilla_matmul_512_4096_512_bf16_f32.mlir
[IREE_AMDAIE] Kernel time: 18.8055 [ms]
[IREE_AMDAIE] Kernel time: 18.1393 [ms]

vanilla_matmul_512_4096_512_bf16_f32_ukernel.mlir
[IREE_AMDAIE] Kernel time: 13.0724 [ms]
[IREE_AMDAIE] Kernel time: 13.33 [ms]

This PR
vanilla_matmul_512_4096_512_bf16_f32_outlining.mlir
[IREE_AMDAIE] Kernel time: 16.5064 [ms]
[IREE_AMDAIE] Kernel time: 16.4465 [ms]
[IREE_AMDAIE] Kernel time: 16.0052 [ms]

vanilla_matmul_512_4096_512_bf16_f32.mlir
[IREE_AMDAIE] Kernel time: 18.7304 [ms]
[IREE_AMDAIE] Kernel time: 19.48 [ms]
[IREE_AMDAIE] Kernel time: 18.7937 [ms]

So O3 and O2 are identical if there is no function outlining, but O3 helps performance if there is outlining.

Bumping llvm-opt from O2 to O3 improves perf with function outlining so much, with O3 perf with function outlining is better than without! Hopefully CI doesn't say other workloads are going OOM.

Nice find! Do you have an idea why the difference is so big? Imo, we shouldn't (in theory) have to bump to O3 to get reasonable function outlining perf. Are we sure this doesn't inline again after all? A couple of thoughts on things that could be tried:

What's the elf size difference between O2 and O3
What about explicitly disabling auto-inlining? Does  --auto_inline=0 work?

Before llvm-opt there are 32 calls (this is the input.ll). After llvm-opt with O2 there are 64 calls. With O3 there are 16 calls.

This result quite surprises me. Why would it double with O2 and half with O3?


Fix integration test cache

What is the purpose of the change
ignore cache.
recover if https://github.com/actions/toolkit/pull/1015 merged
Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #9795 (17db6d1) into 3.0 (b7b4993) will decrease coverage by 0.23%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                3.0    #9795      +/-   ##
============================================
- Coverage     65.70%   65.46%   -0.24%
+ Complexity      296      295       -1
============================================
  Files          1206     1208       +2
  Lines         52322    52562     +240
  Branches       7942     7961      +19
============================================
+ Hits          34378    34411      +33
- Misses        14212    14392     +180
- Partials       3732     3759      +27

Impacted Files
Coverage Δ

.../remoting/api/SingleProtocolConnectionManager.java
61.53% <0.00%> (-23.08%)
:arrow_down:

...apache/dubbo/registry/client/ServiceDiscovery.java
40.00% <0.00%> (-20.00%)
:arrow_down:

.../registry/multicast/MulticastServiceDiscovery.java
50.00% <0.00%> (-16.67%)
:arrow_down:

.../dubbo/registry/client/metadata/MetadataUtils.java
61.90% <0.00%> (-16.01%)
:arrow_down:

...ache/dubbo/rpc/proxy/InvokerInvocationHandler.java
68.00% <0.00%> (-16.00%)
:arrow_down:

...dubbo/common/status/support/LoadStatusChecker.java
46.15% <0.00%> (-15.39%)
:arrow_down:

...ache/dubbo/remoting/transport/AbstractChannel.java
75.00% <0.00%> (-12.50%)
:arrow_down:

.../apache/dubbo/rpc/protocol/tri/TripleProtocol.java
80.00% <0.00%> (-11.67%)
:arrow_down:

...che/dubbo/registry/client/NopServiceDiscovery.java
44.44% <0.00%> (-11.12%)
:arrow_down:

...mmon/threadpool/support/AbortPolicyWithReport.java
73.68% <0.00%> (-10.53%)
:arrow_down:

... and 79 more

Continue to review full report at Codecov.

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


[WIP] impl of where fusion

#742
Still has one issue need to figure out

Need a test case for fusion?


1.0rc1 - Config validation failure when reusing views configs

Ran into an interesting gotcha regarding the 1.0rc1 state configuration validation as I've been working on migrating from 0.x.
So I've got 2 states each having multiple views defined. For those views, they have the same config so I stored the object into a variable and plugged it into both. It's a simple config with a component and bindings. What I found is that a validation error would be raised on the second usage due to the presence of resolveAs on a component configuration. I tracked the issue down to ng1ViewsBuilder.js which modifies the input by applying a default value for resolveAs following the validation, thus making further usages invalid.
Obviously not a showstopper since the workaround is to simply apply a copy, but it was unexpected and may be worth looking at.
Otherwise the migration has been mostly smooth sailing! 1.0 addresses many of pain points of 0.x.

Otherwise the migration has been mostly smooth sailing! 1.0 addresses many of pain points of 0.x.

Lovely, that's great to hear!
I think in general it's a good idea not to share object references in state definitions.  We use object equality checks in various places in the code, so sharing references can be dangerous.
I thought through a few options such as making resolveAs a valid option for component views, but I think it's better to reject resolveAs on a component view during validation because it's most likely a developer mistake.  I appreciate the bug report, but I think we will close as WONTFIX.

I changed my mind. This is pretty easy to fix by making a shallow copy of the view declaration before processing it, and it seems pretty low risk.


Volume Rendering: Zoom inside the cube object

Description
Unable to zoom into the VR object. If the camera is inside the "cube", there's no rendering.
Live Demo
http://jsfiddle.net/gh/get/library/pure/fnndsc/ami/tree/master/lessons/06#run
Steps to Reproduce
Zoom into the VR "cube"
Expected Results
I'd like to be able to zoom the VR object without any limit
Actual Results
There's a limit about zooming distance
Browsers Affected

[x] All
[ ] Chrome
[ ] Firefox
[ ] Edge
[ ] Safari 9
[ ] Safari 8
[ ] IE 11

Versions

AMI: v0.0.20
THREEJS: r87

Sorry for the late answer I was traveling with no internet connection -
Yes I knew about this issue and there are 2 places I'd look into:
1- Ray direction got messed up
https://github.com/FNNDSC/ami/blob/dev/src/shaders/shaders.vr.fragment.js#L64
2- Start/end point are not correct
https://github.com/FNNDSC/ami/blob/dev/src/shaders/shaders.vr.fragment.js#L73-L74
I'll let you know when I have a chance to dig into it!


Add version comments to sample

If this is supported, add version comments in sample
Reference PR #488

I hope someone is able to do this - I'm yet to find any example where it has been achieved.  It's easy enough to get the comment for the current version but seems very difficult to get the matching comment for each version.

I'll have a go at this one, at least for PnP.PpowerShell :-)

Location of sample: https://github.com/pnp/script-samples/tree/main/scripts/spo-get-list-item-version-history

Done

Closing as done :-)


0d87d2a6 is ambiguous

In all three examples, the blue lines cut through the red boxes. But in the "correct" output, a box is colored blue, despite the fact that the blue line was merely adjacent.

This is an acceptable level of ambiguity. You can simply try both solutions (change on touch vs change on cross).

I would argue that this problem is unacceptably ambiguous, and request that this issue be reopened.
There are two questions left unanswered by the examples:

"Does a box become blue if a line merely "touches" it, rather than crossing through?" (mentioned above)
"Is a vertical line always drawn between blue squares which share a column, or is such a line only drawn when those squares also touch the top and bottom of the grid?"

Both questions are reasonable, as they verifiably satisfy the examples no matter how they're answered. However, they lead to four different potential answers for the test question. With only two guesses available, this question introduces an element of luck in getting the answer correct.
OpenAI's o3 made two reasonable guesses on this problem, but was marked "incorrect".

actually you cant say that you can just give both answers since you're given two tries because this question is 4 ways ambiguous there are 4 correct answers that work with the examples given this must be reopened

the 2 right answered could had been also the 2 different ways of creating a cross.
the official answer is more an example of human arbitrariness than of logic
and therefor implicit wrong and should be corrected.

There are two questions left unanswered by the examples:
1. "Does a box become blue if a line merely touches it, rather than crossing through?" (mentioned above)
2. "Is a vertical line always drawn between blue squares which share a column, or is such a line only drawn when those squares also touch the top and bottom of the grid?"

I disagree with your statement that the second question is left unanswered. Since the examples only ever show lines drawn across the grid (instead of along), that property should be implied.
Even if you argue there are four possible answers, two of them do something none of the examples show (connecting dots along the board). So with two possible responses those should be tried last since they divert from the examples the most.

There are two questions left unanswered by the examples:

"Does a box become blue if a line merely touches it, rather than crossing through?" (mentioned above)
"Is a vertical line always drawn between blue squares which share a column, or is such a line only drawn when those squares also touch the top and bottom of the grid?"

I disagree with your statement that the second question is left unanswered. Since the examples only ever show lines drawn across the grid (instead of along), that property should be implied.
Even if you argue there are four possible answers, two of them do something none of the examples show (connecting dots along the board). So with two possible responses those should be tried last since they divert from the examples the most.

there are also 0 examples of a blue line being adjacent to a red square and turning it blue however thats the """correct""" answer so the answer challet says is right also has none of the examples showing it

I agree, that is less likely to be the answer than not filling it in, so that would be my second try and not my first. My argument is that if you order the suggested solutions in increasing ambiguity, you will succeed with two tries.

Since the examples only ever show lines drawn across the grid (instead of along), that property should be implied.

This line of thinking requires that there's something unique about the edges of the grid. That's "open question #2" in my post, and it goes unanswered by the examples, and so we've looped back to the same issue.

I agree, that is less likely to be the answer than not filling it in, so that would be my second try and not my first. My argument is that if you order the suggested solutions by increasing ambiguity, you will succeed with two tries.

ok sure fine i guess you could do that except now you're just making excuses for why this question is ok this is unacceptably ambiguous even though you technically should be able to get the correct answer in at least one of your attempts maybe that doesn't mean this question should be a valid question on the test

@m-vz, this line of thinking requires that there's something unique about the edges of the grid. That's "open question #2" in my post, and it goes unanswered by the examples, so we've looped back to the same issue.

There doesn't need to be anything unique about the edges. In all examples, the lines connect two different edges, which implies a solution that only connects different edges is more likely and should be tried first. But maybe we can agree to disagree.

ok sure fine i guess you could do that except now you're just making excuses for why this question is ok this is unacceptably ambiguous even though you technically should be able to get the correct answer in at least one of your attempts maybe that doesn't mean this question should be a valid question on the test

As far as I understand it can be seen as part of the test whether the test-taker can prioritise more likely solutions in case of ambiguity, and if you do so you are able to get the correct answer without guessing.

@m-vz, this line of thinking requires that there's something unique about the edges of the grid. That's "open question #2" in my post, and it goes unanswered by the examples, so we've looped back to the same issue.

There doesn't need to be anything unique about the edges. In all examples, the lines connect two different edges, which implies a solution that only connects different edges is more likely and should be tried first. But maybe we can agree to disagree.

ok sure fine i guess you could do that except now you're just making excuses for why this question is ok this is unacceptably ambiguous even though you technically should be able to get the correct answer in at least one of your attempts maybe that doesn't mean this question should be a valid question on the test

As far as I understand it can be seen as part of the test whether the test-taker can prioritise more likely solutions in case of ambiguity, and if you do so you are able to get the correct answer without guessing.

There is nothing more likely about the intended solution compared to any other solution. The fact that this is even being discussed in the first place is bad for this question. It could be fixed so simply; you would literally need to add one line to one example to fix this question. The fact that you could technically get the """correct""" solution by guessing and trying to get into the mind of the test maker and think, "Oh, I think they would say this is the right answer," is not good. You should not have to play mind games because the question is ambiguous. You are simply making excuses.

implies a solution that only connects different edges is more likely

@m-vz, I think you'd struggle to justify this. It'd be just as valid to argue that the presence of two squares, rather than one, initiating a line is an implication that any two squares in a column should be connected by a line, and that alone is sufficient. To be clear, I don't think either implication is valid.


Is this dead, too?

It looks like the best of intentions has given way to the expediency of actually having other things to do. :)
Any plans for moving forward, or should I fork this for my team?

Yea, It never really took off in terms of contributions and external merges.
Also, as browser APIs matured and "next-gen" view libraries/frameworks like Vue, React, Angular 2 increased in popularity, this really lost its relevance

I've got some legacy applications which were built before the advent of frameworks so we're still relying on jQuery to support some of the more gnarly bits.  (ADA support is nothing if not gnarly.)  There won't be a rewrite any time soon.
So, taken under advisement...thanks!


Improve FilePicker UI

Describe the feature
The MR file picker sure looks ugly as it is right now! With some of the new UI tools and layout features coming in v0.3.6, this should definitely be a flagship showcase of the newly available tools.

This is great news :) I'd like to take the opportunity to share my wish list for the new version:
1) Use a traditional, scrollable list approach.
The current style of displaying each file / folder as a button causes large filenames to become unreadable because they are scaled down to fit on the button. Also when you have a large number of entries, the dialogue is massive and you can't see / reach the lower buttons.
2) Allow the current folder to be changed while the dialogue is open.
I would like to position my own window next to the dialogue with a list of favourite folders so they can quickly navigate to one of those folders with a single click, e.g. Downloads, Sample Assets, Music etc.
3) Expose a variable that shows which path+filename is currently highlighted (but not yet opened).
This will allow us to display previews along side the dialogue while they are browsing models / images and would make good use of your new asynchronous loading.
4) Display file timestamps and allow ordering by name or timestamp.
Users will often be looking for the most recent file so this improves the experience for them.
5) Allow a text style to be passed in.
This will allow us to change the font size as required for accessibility.
Thank you.

Thanks a bunch for the feedback here, this is really excellent! I'll definitely keep these in mind while updating it, and I think I should be able to satisfy most of these for you :)
Just to set some expectations, I consider the file picker that we're talking about here as a "fallback". Some platforms also provide ways of launching MR file pickers, much like the system file pickers in flatscreen, and I will always use those first! Right now I think that's just UWP. I may need to dig a little deeper into Android to make sure there is or isn't one there as well.
With that in mind, I don't want to add more functionality to the picker than the OS is likely to provide! So items 2 & 3 I'm likely to shy away from as described here. However, I'd love to add previews and recent folders/notable folders as a core functionality of the fallback picker!

Thanks for your response and I understand your reasoning. If the UWP file picker lets us pass in a suggested starting folder when launching it, that may be a useful compromise on number 2. Thanks.

Just collecting more file picker feedback here:
From ClonedPuppy:

When you do get around to having a look at the FilePicker, I was wondering if you could also make the Save feature able to autofill the text field when clicking on a existing file, for when you just want to overwite something.

Some initial improvements will be in v0.3.6, and it is a nice improvement! A bunch of the UI features are slipping to v0.3.7, so I'll slip the rest of this to v0.3.7 as well.

Hi!  I tried to use FilePicker but I encountered quite a few problems:

On Linux, files are seen as directories (with a toggle button).
On Android, it does not display any files (see the videos below)

https://youtu.be/iMp2gbVUQr8


[Deepstore by-passing]Introduce a subclasses SplitSegmentCommitter which will proceeds to commit even if the segment upload fails.

Description
Introduce a subclasses SplitSegmentCommitter which will proceeds to commit even if the segment upload fails. Design doc.
Upgrade Notes
Does this PR prevent a zero down-time upgrade? (Assume upgrade order: Controller, Broker, Server, Minion)

[ ] Yes (Please label as backward-incompat, and complete the section below on Release Notes)

Does this PR fix a zero-downtime upgrade introduced earlier?

[ ] Yes (Please label this as backward-incompat, and complete the section below on Release Notes)

Does this PR otherwise need attention when creating release notes? Things to consider:

New configuration options
Deprecation of configurations
Signature changes to public methods/interfaces
New plugins added or old plugins removed

[ ] Yes (Please label this PR as release-notes and complete the section on Release Notes)

Release Notes
If you have tagged this as either backward-incompat or release-notes,
you MUST add text here that you would like to see appear in release notes of the
next release.
If you have a series of commits adding or enabling a feature, then
add this section only in final commit that marks the feature completed.
Refer to earlier release notes to see examples of text
Documentation
If you have introduced a new feature or configuration, please add it to the documentation as well.
See https://docs.pinot.apache.org/developers/developers-and-contributors/update-document

@chenboat  please add some tests in another follow-up commit. Here is what I would suggest:

You can start a thread that behaves like deepstore, failing the commit. Start another thread, that starts only the committer, mocking everything else. Start a server fake server thread that in externalview seem online for the segment. Assert that the server gets a request for download, and assert the segment commit passes. This verifies only the server side.
Controller verificaton can be done independently, I think. All that we need to verify is that when a segment is committed with "PEER" in the URI, the metadata for segment URI is null. You can probably do this by starting a controller, mocking a realtime segment, and posting a consumed followed by commit call using http.


skiplist and dlist support Iterator

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

84 of 84 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 99.414%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
1188

Relevant Lines:
1195

💛  - Coveralls


Move gl-dotnet to start of custom header

(Also, update a test to check for gl-dotnet rather than just dotnet.)

I have one comment on the code to capture a recent change to show both gccl and gapic, because we want to report gapic across the board. For C#, it's fine to use the same version for both, since they're so tightly integrated.
Also, do you have PRs to update toolkit and google-cloud-dotnet?

One other question is do you use the "UNKNOWN" string anywhere? If so, it needs to be changed to the empty string (e.g. grpc/ rather than grpc/UNKNOWN).

@bjwatson:  I'll add in the gapic header, although it seems a bit pointless to me. We don't use "unknown" anywhere, and we don't need to update any other repos.

Thanks @jskeet. I know it seems pointless in the context of .NET, but I'm thinking in terms of having a high-level of consistency across all languages in our metrics. When constructing a query, we want to avoid special cases that we have to deal with, like C# really has a GAPIC layer even though the gapic field is NULL.


Links not url's

Fix #175

@dansvend

[ ] Remember to filter away the links in the canvas.

text.replace(
    /(\[((?:\[[^\]]*]|[^\[\]])*)]\([ \t]*()<?((?:\([^)]*\)|[^()\s])*?)>?[ \t]*((['"])(.*?)\6[ \t]*)?\))/g,
    "$2"
 );

Let's get it out to test environment

Building to test environment now🛠

@SjoenH Would be nice with another code review and a talk through now that the feature have been tested and approved by tester and PO's 👌


Add support for frame field type

Nested frame can be done by Time series to table transformation so the issue is not relevant


[BACKPORT-v1.14] random: Add syscalls for random subsystem

Create syscalls to make possible using random APIs from user mode
threads. These APIs can have different implementations, like using
entropy driver or Xoroshiro128. Some of these implementations also
have some globals to preserve state between calls.
Make it run entire in user space would require user adding these
globals to their memeory domains and/or grant access to entropy device.
Syscalls simplify its usage.
Signed-off-by: Flavio Ceolin<EMAIL_ADDRESS>

I'm really getting confused by distinctions between this PR, #25980, and #25890

I'm really getting confused by distinctions between this PR, #25980, and #25890

this one is basically #25980 backported to 1.14. Forget about #25890, I will close that, it was an attempt to have random subsys in usermode without syscalls.

I'm really getting confused by distinctions between this PR, #25980, and #25890

this one is basically #25980 backported to 1.14. Forget about #25890, I will close that, it was an attempt to have random subsys in usermode without syscalls.

Gotcha thanks!!

@ceolin  do we have a bug associated with this?

@ceolin do we have a bug associated with this?

nope, we don't have an issue associated.

nope, we don't have an issue associated.

then you need to create one and document what the problem is. see https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Change-Control-Board-(CCB)

nope, we don't have an issue associated.

then you need to create one and document what the problem is. see zephyrproject-rtos/zephyr/wiki/Zephyr-Change-Control-Board-%28CCB%29

#26499


CI automated  failed build caused by super_clipboard

Is there an existing issue for this?

[X] I have searched the existing issues

Use case
upgrade super_clipboard version from 0.8.13 to 0.8.14
Proposal
super_clipboard version from 0.8.13 to 0.8.14  https://github.com/superlistapp/super_native_extensions/issues/362

yup i think this would fix the problem i am facing

Is there an existing issue for this?

[x]  I have searched the existing issues

Use case
upgrade super_clipboard version from 0.8.13 to 0.8.14
Proposal
super_clipboard version from 0.8.13 to 0.8.14 superlistapp/super_native_extensions#362

Hi, I'm not sure what you mean by this. Do you mean the CI of the Flutter Quill repo? because it's succeeding without any issues

Sorry for the confusion. I meant to ask if you could please upgrade the version of super_clipboard to 0.18.5   https://github.com/superlistapp/super_native_extensions/issues/362

Published in<PHONE_NUMBER>2, you can now use 9.3.17


change "should" to "can"

Change the wording to make it more clear that a mac user can use either pip or homebrew to install dbt core.

hey @leoebfolsom sorry for the delay on this! thanks for opening this up and we've approved + merged this for you!

@mirnawong1 Tysm!! 🥳🕺


Shortcode scratch side-effects are lost during live reload

What version of Hugo are you using (hugo version)?

0.84.1

Does this issue reproduce with the latest release?
Yes
Issue Description
To reproduce:

In a shortcode, write to page scratch
Via a partial called from a layout file, read the scratch data
Run hugo server (i.e. with live reloading)
Modify some files, such as a layout file or partial for a page/post

Result:

The page’s scratch gets cleared, but side effects from shortcodes don’t get re-run, causing the partial to not see the scratch data until the next full build.

Expected:

Shortcodes and side effects should re-run, if scratch is cleared, or don't clear the scratch data

I made a simple repo for testing on the scratch_issue branch at: https://github.com/EmpireJones/hugoBasicExample/tree/scratch_issue

First Load (summary is generated from page's scratch):

After change occurs (summary is generated from page's scratch - but has no data):

https://github.com/gohugoio/hugo/issues/8255 seems similar, but I don't think it's discussing the exact same thing.

Had a "fight" with this problem in the last two days.
Want to use SVG sprites references in the page, saving the needed sprites in a scratch map, to include the sprite at the end of the page. Must set scratch deep in called partials and process it from baseof.html ( with a partial ).
Please don't push it to later versions, it is open  for 18 months.

So, I fighted with this myself some time ago, and figured out that I couldn't change the current behaviour without breaking stuff, so I added a new scratch variable.
Now there are:
.Store
.Scratch

On Page. The .Store will never be erased.

Thanks, nothing in the DOCS about .Store, looked in the source.
Seems not to work in lists templates.
This is the place where the sprites can have a big space impact.

Seems not to work in lists templates.

It's a new method on the Page interface, so it should work everywhere.
Also, I'm working on a revised documentation with a complete reference section as I'm writing this.

I made a simple repo for testing on the scratch_issue branch at:
https://github.com/EmpireJones/hugoBasicExample/tree/scratch_issue

I can reproduce the problem using this example with v0.101.0 and earlier.
With v0.102.0 and later there are no problems.
There were 3 commits in v0.102.0 that affected LiveReload:

commands: Fix embed in livereload.go https://github.com/gohugoio/hugo/commit/3fefea06b884ff905509f5854cb13bc54d092f38
livereload: Inject script without head or body tag https://github.com/gohugoio/hugo/commit/b017f7cb0136ee33f5d19749a15bf3365a991ac5
Externalise and embed livereload.js string https://github.com/gohugoio/hugo/commit/21562e3aad2ea461073f672fc83c5c897bfcf556

For anyone stumbling across this in the future...
1) Use .Page.Store  instead of .Page.Scratch

The Store method on a Page object creates a persistent scratch pad to store and manipulate data. In contrast with the Scratch method, the scratch pad created by the Store method is not reset on server rebuilds.

2) Make sure that the content is rendered before reading the Scratch/Store. For example, if you need a Scratch/Store value at the top of a template, before the content has been rendered, force content rendering with something like:
{{ $noop := .WordCount }}
{{ .Store.Get "foo" }}

There are several methods you can call to force content rendering. See this FAQ.


Channel edit4

Feature:
Channel page updates
Re: #561
Should be broken out of the channel page - probably requires useContext wrapper.
Not happy with upload function living in component.
Still a bug with updating and status messaging on submit.
Mostly unstyled.

This has been updated.


chore: change module homepage

Pull Request Test Coverage Report for Build 114735514

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Totals

Change from base Build 114690892:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls