nixosTests.pleroma: fix timeout

Description of changes

fix 'toot login_cli' password enter
add '--debug' to toot for additional logs
remove unused 'with pkgs;'

Fixes nixosTests.pleroma failing on 1 hour timeout:
https://hydra.nixos.org/job/nixos/trunk-combined/nixos.tests.pleroma.x86_64-linux/all
https://hydra.nixos.org/build/269171151
Logs:
client # ++ export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
client # ++ REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
client # ++ toot login_cli -i pleroma.nixos.test -e<EMAIL_ADDRESS>client # ++ echo jamy-password

Last successful run on hydra 2024-01-10:
https://hydra.nixos.org/build/245900473
toot login_cli does not accept password from stdin since https://github.com/ihabunek/toot/commit/d8c7084678a5c2018dbf00c2aecb494e2f6c5bf4
Now it could be done with -p/--password instead.
Before this fix toot login_cli in test requested password and waited in that state until 1h timeout.
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

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

@ofborg test pleroma

From failed ofborg run:
https://logs.ofborg.org/?attempt_id=49467058-feb0-420d-9795-7c2ad3cce214&key=nixos%2Fnixpkgs.334688
pleroma # ++ cp /nix/store/8ajixz4nnhlf1rrwza0nxgbin8h1azjv-secrets.exs /var/lib/pleroma/secrets.exs
pleroma # cp: cannot create regular file '/var/lib/pleroma/secrets.exs': No such file or directory

there might also be some race between creating /var/lib/pleroma (first run of systemd service)
and running provision-secrets

@ofborg test pleroma

@ofborg test pleroma


HTTPCORE-756: RFC 9110 conformance improvements

This PR contains several incremental RFC 9110 conformance improvements

Handling of HTTPS requests over insecure (non-TLS) connections
Support for handling connection specific headers
Expect header processing improvements

@arturobernalg Please take a look.


Application set not able to delete k8s resources of child application

Hi,
I, currently have a application set (parent), which creates a child argo application (child).
When i delete the argo parent app or application set it does not remove the child application k8s resources at all and leave them behind.
Argo cd details:
argocd: v2.0.1+33eaf11.dirty
BuildDate: 2021-04-21T18:44:13Z
GitCommit: 33eaf11e3abd8c761c726e815cbb4b6af7dcb030
GitTreeState: dirty
GoVersion: go1.16.3
Compiler: gc
Platform: darwin/amd64
argocd-server: v2.0.0+f5119c0
BuildDate: 2021-04-07T06:00:33Z
GitCommit: f5119c06686399134b3f296d44445bcdbc778d42
GitTreeState: clean
GoVersion: go1.16
Compiler: gc
Platform: linux/amd64
Ksonnet Version: v0.13.1
Kustomize Version: v3.9.4 2021-02-09T19:22:10Z
Helm Version: v3.5.1+g32c2223
Kubectl Version: v0.20.4
Jsonnet Version: v0.17.0

@jgwest @rtnpro pls have a look at above issue

Hi @mksha, what version of ApplicationSet controller?

I see here: https://github.com/argoproj-labs/applicationset/blob/master/pkg/controllers/applicationset_controller.go#L549 that ApplicationSet controller uses the Kubernetes Controller client to delete the Application specs it created.
@mksha Do you mean that the Application specs generated by ApplicationSet do not get removed when ApplicationSet is deleted? Or the k8s resources like deployment, service, etc. created by the ArgoCD Application do not get deleted?

Application Controller version :  https://raw.githubusercontent.com/argoproj-labs/applicationset/v0.1.0/manifests/install.yaml
@jgwest

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: myapp
namespace: argocd
Add a this finalizer ONLY if you want these to cascade delete.
A cascade delete, deletes both the app and its resources, rather than only the app.
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
generators:

git:
repoURL: ssh://git@git.something.com:8728/test/myapp.git
revision: feature/application-set-svc
files:

path: "apps/**/config.json"
template:
metadata:
name: '{{app.instance}}-interest'
spec:
project: my-project
source:
repoURL: 'https://artifactory.xxx..com/artifactory/helm/'
chart: java-webapp
targetRevision: 0.0.4
path: .
helm specific config
helm:
Values file as block file
values: '{{values}}'
destination:
namespace: my-namespace
name: '{{cluster.name}}'

Sync policy
syncPolicy:
automated: # automated sync by default retries failed attempts 5 times with following delays between attempts ( 5s, 10s, 20s, 40s, 80s ); retry controlled using retry field.
prune: true # Specifies if resources should be pruned during auto-syncing ( false by default ).
selfHeal: true # Specifies if partial app sync should be executed when resources are changed only in target Kubernetes cluster and no git change detected ( false by default ).
allowEmpty: true # Allows deleting all application resources during automatic syncing ( false by default ).
syncOptions:     # Sync options which modifies sync behavior
- Validate=true # disables resource validation (equivalent to 'kubectl apply --validate=false') ( true by default ).
- CreateNamespace=true # Namespace Auto-Creation ensures that namespace specified as the application destination exists in the destination cluster.
- PrunePropagationPolicy=foreground # Supported policies are background, foreground and orphan.
- ApplyOutOfSyncOnly=true # to skip syncing resources that are already in the desired state.
- PruneLast=true # Allow the ability for resource pruning to happen as a final, implicit wave of a sync operation
# The retry feature is available since v1.7
retry:
limit: 5 # number of failed sync attempt retries; unlimited number of attempts if less than 0
backoff:
duration: 5s # the amount to back off. Default unit is seconds, but could also be a duration (e.g. "2m", "1h")
factor: 2 # a factor to multiply the base duration after each failed retry
maxDuration: 3m # the maximum amount of time allowed for the backoff strategy

then in my repo i have apps/dev/config.json
@jgwest  @rtnpro

when i delete the dev folder from repo then application set deletes the app created for dev, but does not delete the k8s resources of that app.

You should not add this finalizer to the ApplicationSet:
  finalizers:
    - resources-finalizer.argocd.argoproj.io
``

This finalizer is only supported on Argo CD `Application` objects. It's likely this finalizer is preventing the ApplicationSet from being deleted.

is there any logs that i can see that is tries to delete the k8s resources .
in which deployment should i take a look in argo for debugging this issue

You should not add this finalizer to the ApplicationSet:
  finalizers:
    - resources-finalizer.argocd.argoproj.io

This finalizer is only supported on Argo CD Application objects. It's likely this finalizer is preventing the ApplicationSet from being deleted, which is what is causing your issue.

I also tried without that, but does not work

again, i am not deleting the application itself, i am delete one of the application created by application set.

You should not delete an individual application that is managed by an ApplicationSet; if you do, the ApplicationSet controller will immediately recreate it, eg I don't think deleting an individual Application will accomplish what you are looking for.
In any case, the actual deletion of an Application's child resources is handled by Argo CD, rather than the ApplicationSet controller.

again, i am not doing manually, as my application set is monitoring a repo where i have multiple app
apps
-- app1
---app2
---app3
so applciation set will create a argo app for each folder.
and if i add 4th folder and commit mhy code argo will automatically create the new argo app 4 using application set.
but when i delete the folder , then application set automatically deletes the argo app, but not the k8s resources.
@jgwest @rtnpro

Hi @mksha, I am not able to reproduce:
I create this example ApplicationSet, based on the one you specified:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp
  namespace: argocd
spec:
  generators:
  - git:
      repoURL: https://github.com/jgwest/applicationset.git
      revision: test
      files:
      - path: "examples/git-generator-files-discovery/cluster-config/**/config.json"
  template:
    metadata:
      name: '{{cluster.name}}-interest'
    spec:
      project: default
      source:
        repoURL: https://github.com/jgwest/applicationset.git
        targetRevision: test
        path: "examples/git-generator-files-discovery/apps/guestbook"
      destination:
        namespace: '{{cluster.name}}'
        server: https://kubernetes.default.svc
      # Sync policy
      syncPolicy:
        automated: # automated sync by default retries failed attempts 5 times with following delays between attempts ( 5s, 10s, 20s, 40s, 80s ); retry controlled using `retry` field.
          prune: true # Specifies if resources should be pruned during auto-syncing ( false by default ).
          selfHeal: true # Specifies if partial app sync should be executed when resources are changed only in target Kubernetes cluster and no git change detected ( false by default ).
          allowEmpty: true # Allows deleting all application resources during automatic syncing ( false by default ).
        syncOptions:     # Sync options which modifies sync behavior
        - Validate=true # disables resource validation (equivalent to 'kubectl apply --validate=false') ( true by default ).
        - CreateNamespace=true # Namespace Auto-Creation ensures that namespace specified as the application destination exists in the destination cluster.
        - PrunePropagationPolicy=foreground # Supported policies are background, foreground and orphan.
        - ApplyOutOfSyncOnly=true # to skip syncing resources that are already in the desired state.
        - PruneLast=true # Allow the ability for resource pruning to happen as a final, implicit wave of a sync operation
        # The retry feature is available since v1.7
        retry:
          limit: 5 # number of failed sync attempt retries; unlimited number of attempts if less than 0
          backoff:
            duration: 5s # the amount to back off. Default unit is seconds, but could also be a duration (e.g. "2m", "1h")
            factor: 2 # a factor to multiply the base duration after each failed retry
            maxDuration: 3m # the maximum amount of time allowed for the backoff strategy

I apply it, and see the ApplicationSet and Applications created.
I delete a config.json file from the test branch of https://github.com/jgwest/applicationset.git, which is what it is pointing to.
When the ApplicationSet generator reconciles the ApplicationSet, the Application is deleted, and so are the deployment resources that it created.

Hi @jgwest  are you right. It working on my local cluster. It seems like either its some issue on my dev cluster or some restriction in argocd config that is stopping argo to delete the k8s resources. But on local it works fine while i am using default project.
Thanks for taking a look and trying it out.
is there any idea what could stop the argo to delete the k8s resources. project ? role? or some other argo config?

@mksha You can check the Argo CD pod logs to make sure, for example, that Argo CD has permission to delete the resources, and/or if any other error messages are thrown, that would be my only guess.

Are there any plans implementing the ApplicationSet features in the ArgoCD project itself?


feat: Nontrivial instances for ExteriorAlgebra, CliffordAlgebra

Using methods suggested by @eric-wieser
Zulip discussion

Note that there is no need to force-push with mathlib; bors will squash your commits together anyway before merging.


Segmentation fault in AdjustStructureForPeriod when running on the fly in Swift

This has been observed in several simulations but one quick way to reproduce it is the examples/SmallCosmoVolume/SmallCosmoVolume_DM example in the Swift repository. The problem appears to have been introduced in VR commit b5e1a8c5adc9a7c4e637385a8ff77a5c3b643685.
I'm using the latest ICRAR VR master (a497fe32e16995771b0631c1eff47753e918b7b6) configured with:
cmake ..
To run it:
cd swiftsim/examples/SmallCosmoVolume/SmallCosmoVolume_DM
./getIC.sh
mpirun -np 1 ../../../build/examples/swift_mpi --cosmology --self-gravity --velociraptor --threads=16 small_cosmo_volume_dm.yml

It runs for a few minutes and crashes when it gets to a redshift ~3:
0: finished FOF search in total time of 3.17214
[login7c:219197:0:219197] Caught signal 11 (Segmentation fault: Sent by the kernel at address (nil))

/cosma7/data/dp004/jch/Swift/repro_bug/VELOCIraptor-STF/src/search.cxx: [ AdjustStructureForPeriod() ]
      ...
      976     for (i=0;i<nbodies;i++) {
      977         if (pfof[i]==0) continue;
      978         if (irefpos[pfof[i]] != -1) continue;
==>   979         refpos[pfof[i]] = Coordinate(Part[i].GetPosition());
      980         irefpos[pfof[i]] = i;
      981     }
      982 #ifdef USEOPENMP

==== backtrace (tid: 219197) ====
 0 0x000000000071d5c2 AdjustStructureForPeriod()  /cosma7/data/dp004/jch/Swift/repro_bug/VELOCIraptor-STF/src/search.cxx:979
 1 0x0000000000715e4b SearchFullSet()  /cosma7/data/dp004/jch/Swift/repro_bug/VELOCIraptor-STF/src/search.cxx:482
 2 0x000000000058e652 InvokeVelociraptorHydro()  /cosma7/data/dp004/jch/Swift/repro_bug/VELOCIraptor-STF/src/swiftinterface.cxx:615
 3 0x000000000058c837 InvokeVelociraptor()  /cosma7/data/dp004/jch/Swift/repro_bug/VELOCIraptor-STF/src/swiftinterface.cxx:398
 4 0x00000000005686ba velociraptor_invoke..0()  /cosma7/data/dp004/jch/Swift/repro_bug/swiftsim/build/examples/../../src/velociraptor_interface.c:1026
 5 0x00000000005824a0 engine_check_for_dumps()  /cosma7/data/dp004/jch/Swift/repro_bug/swiftsim/build/examples/../../src/engine.c:2974
 6 0x000000000041331a engine_step()  /cosma7/data/dp004/jch/Swift/repro_bug/swiftsim/build/examples/../../src/engine.c:2819
 7 0x000000000041331a engine_step()  /cosma7/data/dp004/jch/Swift/repro_bug/swiftsim/build/examples/../../src/engine.c:2828
 8 0x000000000040f1cd main()  /cosma7/data/dp004/jch/Swift/repro_bug/swiftsim/build/examples/../../examples/main.c:1490
 9 0x0000000000022555 __libc_start_main()  ???:0
10 0x000000000040cda9 _start()  ???:0
=================================

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   RANK 0 PID 219197 RUNNING AT login7c.pri.cosma7.alces.network
=   KILLED BY SIGNAL: 11 (Segmentation fault)
===================================================================================

The problem is that on line 979 pfof[i]=4627676946019562717, which is clearly not a valid array index. The index i=262144 at this point. This simulation has 262144 particles. The array pfof has more values than this (I think because particles are duplicated so that threads have whole groups to work on) and it seems to be the extra elements after the first 262144 which have problematic values.
I haven't been able to reproduce this running standalone VR on the same simulation.

Ok, I think my comment above is irrelevant. These functions only get called with >1 MPI rank but I can only make it crash when running on one rank.

This crash only happens if running from Swift on the fly, with MPI enabled, and with one MPI rank. I now think the cause is this chunk of code in search.cxx near line 459:
        // Delete exported particles
        for (i = Nlocal-1; i >= 0; i--)
          if (Part[i].GetPotential() ==1.0) Part.pop_back();
          else break;
        Nlocal = Part.size();

This is going to go wrong if the size of the vector Part is not initially equal to Nlocal. Part is initialized in main.cxx or swiftinterface.cxx depending on whether we're running on the fly or not. The Swift interface always allocates space for imported particles if we're using MPI, but main.c does not allocate the extra space if NProcs==1. So if we're running from Swift the block of code above leaves Nlocal larger than it should be and we get a crash in AdjustStructureForPeriod.

Thanks @jchelly for the great analysis and the proposed solution!

Part is initialized in main.cxx or swiftinterface.cxx depending on whether we're running on the fly or not. The Swift interface always allocates space for imported particles if we're using MPI, but main.cxx does not allocate the extra space if NProcs==1. So if we're running from Swift with one MPI rank the block of code above leaves Nlocal larger than it should be and we get a crash in AdjustStructureForPeriod.

This might be better suited to be discussed in the PR, but since I'm here... It wasn't obvious to me how adjusting Nmemlocal in main.cxx would fix the issue, but then I found these, which I think is what you meant?
https://github.com/ICRAR/VELOCIraptor-STF/blob/a4c0e004eacf05a7bd6c5d5a0a972d04b2be8f9b/src/search.cxx#L381-L384
https://github.com/ICRAR/VELOCIraptor-STF/blob/a4c0e004eacf05a7bd6c5d5a0a972d04b2be8f9b/src/search.cxx#L391

If NProcs>1 then line 391 resizes Part to just the right size and everything is ok. The problem is that with NProcs=1 the Swift interface makes Part too big and it doesn't get resized because line 391 is not executed. My solution is just ensuring that Part is the right size initially so we don't need to resize it. There are a couple of other ways to fix this that should also work:

Always do Part.resize(Nlocal) in search.cxx no matter how many MPI ranks are in use.
Rewrite the 'delete exported particles' block so it doesn't assume there are no extra unused elements in Part. I don't know if any later code relies on Part.size()==Nlocal so I don't like that one.

Right, I was slightly confused but almost on track... thanks for that clarification!


Missing Icon: Azure Machine Learning

Missing Icon: Azure Machine Learning

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

ID: 6624d44c-f9f6-02f8-2c67-0f0637fed62e
Version Independent ID: 9346a8ff-bab5-be2c-9dc1-d546fda1efa9
Content: Azure Icons - Azure Architecture Center
Content Source: docs/icons/index.md
Service: architecture-center
GitHub Login: @doodlemania2
Microsoft Alias: pnp

Thanks for reporting - this issue is under review. This is a Microsoft Internal DevOps Bug ID # 452931

Thank you for reporting this, @epomatti.
We've made several updates to the Azure Icons recently, and there are hundreds of new icons added.
The update is available for download here: https://learn.microsoft.com/en-us/azure/architecture/icons/
There are relevant Machine Learning icons added:

In the iot folder:

00030-icon-service-Machine-Learning-Studio-(Classic)-Web-Services.svg
10167-icon-service-Machine-Learning-Studio-Workspaces.svg
10168-icon-service-Machine-Learning-Studio-Web-Service-Plans.svg

Please open a new ticket if there are still icons you believe should be in the Icons pack.
Thanks!
#please-close


Ensure SQL queries required for the UI have higher priority than sync queries

Right now all db accesses are serialized by a mutex
https://github.com/electric-sql/electric/blob/435a2ad5295c6079355772c65130cb278976ddd1/clients/typescript/src/drivers/wa-sqlite/database.ts#L40C31-L40C46
This is ok when there is a few concurrent transactions. The problem is when
electric syncs a lot of small transactions using the satelite protocol and at the same time there is a really important select query which MUST finish within a few hundred ms or otherwise my app appears broken. Right now when there's a sync with a few hundred small transaction the queries for the UI take 10-20 seconds to finish .-.
I would expect for queries initiated by the UI to have priority against sync queries. The problem would also be mitigated when batching updates on the satelite protocol would be introduced.
Consider replacing the mutex with a priority mutex and introduce a distinction between "background queries" and "interactive queries". With background queries we don't care when they finish, with interactive queries we need them to finish asap.

Hi @gorbak25, prioritising the UI looks like a good idea. The async-mutex library we use does not seem to support priority-aware mutexes. If we want to support this efficiently we will need to implement the mutex ourselves (which should be relatively simple given JS' model (event loop, single threaded)).

We should 💯 do this.

Closing this one as i created a Linear issue https://github.com/electric-sql/electric/issues/674 to track this


Functor instance for Dynamic

As I'm very new to reflex, this may be a bad idea for reasons I don't understand. However, in my usage so far, such an instance would have been convenient (as an alternative to y <- mapDyn f x).

The problem with this instance is that it will evaluate f twice whenever the input dynamic changes: once to compute the new Event value, and once to compute the new Behavior value. With mapDyn, there is only a single computation, the result of both is shared. This is also why mapDyn is monadic.

@snoyberg It's great to get your feedback on this.
I completely agree with what you're saying - it would be way nicer to use fmap than mapDyn.  However, @bennofs basically covered it.  Currently, there's no way to implement Dynamic without potentially losing sharing.  This is something I plan to fix in the near future.

That reasoning makes more sense. A few thoughts from me (and, again, I realize these are very beginner-level questions):

In many of the cases where I would have wanted to use a Functor instance, I would not have expected the lost sharing to be an issue. For example, if I use dynText, I would have thought that the initial rendering would use the Behavior and all future updates would use the Event, ignoring the Behavior, meaning that no value is ever used from both the Behavior and Event.
Having this kind of information in the docs for Dynamic may be useful for people like me (used to Haskell typeclasses, and surprised when they aren't being used). Once we have clarity here, I'd be happy to update this PR with such a documentation change.

I think you're right that, usually, the lack of sharing would not be an issue.  dynText certainly would not be impacted.  However, I've made an effort to ensure that reflex doesn't have any weird corner cases where the performance gets really bad, and I think this is a situation where it could.  I definitely wouldn't want someone to spend a bunch of time profiling their code, only to find that something like this is at its core.
Adding documentation makes sense to me.  What do you think of adding something to Dynamic's docs saying something like "Although Dynamic logically has a Functor instance, currently it can't be implemented without potentially requiring the mapped function to be evaluated twice.  Instead, you can use mapDyn, which runs in a MonadHold instance, to achieve the same result."?

That sounds perfect. As a reader, that says to me:

Aha! My understanding of this concept is correct, I'm not crazy.
There's a deeper reason for the lack of this instance, which is rightfully beyond my ability to predict, but the docs have helpfully told me how to achieve the same thing in a different way.

Big :+1: :)

:+1:

I've updated the PR to include your suggested documentation.

Awesome!  Thanks, @snoyberg!


Update 02_segmentation_and_measuring.md fix error in first big cell

In the rendered website
https://scipy-2024-image-analysis.github.io/tutorial/02_segmentation_and_measuring.html#separating-an-image-into-one-or-more-regions-of-interest
there is an error:

This is already addressed in https://github.com/scipy-2024-image-analysis/tutorial/pull/3/files#diff-470579402ff32f5250c43957e22325d02453317f14df0d47a84b36082c6c53e0R43. Merging that one now and closing this one. :)

Sorry I missed that!


Uninstall existing driver if upgrade fails

We currently don't have a supported in-place upgrade path for users because of the way our packages are configured. There are a number of ways that the installed packages can get into bad states that apt (and even dpkg directly) refuses to work around without manual intervention.
To avoid this behavior, this commit adds limited retries to the package installation step that, in the instance of a failed client install, will attempt to unload any running Lustre modules, remove the installed packages, and retry the installation.
In addition, when the pod is terminated, it will attempt to unload the Lustre modules, but will not fail if it cannot unload them (such as when there are existing pods running which have active Lustre mounts).
If it cannot unload the existing modules, it will log a warning that the new version will likely not be running, but will not fail. Additionally, if it cannot install the desired packages, it will log a warning that it could not install correctly, but will continue to attempt to start the driver.

What type of PR is this?
/kind bug

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Tested this with:

upgrading and downgrading the SHA (succeeds after first failed try)
with a known bad state (succeeds after first failed try)
with an existing, correctly installed driver of the expected version (succeeds on first try with no retries)
from a clean state with no driver installed (succeeds on first try with no retries)

Release note:
none

@joe-atzinger I'd appreciate if you could get a chance to look at this one. This would be a nice quality of life improvement since customers seem to get stuck with bad upgrade states a lot


"generate operation" error "the required flag `-n, --name' was not specified"

Problem statement
$ ./swagger generate operation
the required flag `-n, --name' was not specified

According to --help this defaults to all, which suggests that this option should not be required.
Swagger specification
$ cat swagger.yml
consumes:
- application/json
info:
  title: Swagger
  version: 0.1.0
paths:
  /foo:
    get:
      responses:
        200:
          description: Successful response
          schema:
              type: object
              required:
                - data
              properties:
                data:
                  type: string
produces:
- application/json
schemes:
- http
swagger: "2.0"

$ ./swagger validate swagger.yml
2020/04/26 20:22:27
The swagger spec at "swagger.yml" is valid against swagger specification 2.0

Environment
$ ./swagger version
version: v0.23.0
commit: 3596b40bedd4f06cc918767098568456d2ec2370

$ go version
go version go1.14.2 linux/amd64

Yeah fixed that too with #2327. Thanks for reporting. These kinds of minor glitches are always annoying.

fixed by #2327


Make description of step more accurate

Why:
While learning about GitHub actions, I found it difficult to visualize the hierarchy of the various components.
Workflows -> Jobs -> Steps -> Commands (Actions or bash commands)
I find it important to mention early on that the leaf nodes of these workflow don't have to be actions, but could also be a bash command.
What's being changed:

Making the description of a step more accurate.
Also, added a link to the GitHub jobs runner (https://github.com/actions/runner)

Check off the following:

[x] All of the tests are passing.
[x] I have reviewed my changes in staging.
[x] For content changes, I have reviewed the localization checklist
[x] For content changes, I have reviewed the Content style guide for GitHub Docs.

Thanks so much for opening a PR @Deborah-Digges! I'll get this triaged for review 🎉

Commenting to prevent the stale action from closing this


fix(NODE-3252): state transistion from DISCONNECTED

Change the state change to a legal transition

Made NODE-3289 for us to look into that.


OCPBUGS-38967: [release-4.17] Remove go workspaces

What this PR does / why we need it:
Removes the go.work and go.work.sum files from the repository. Updates the Makefile to not use go workspaces.
Updates the vendored staticcheck so it won't fail on new style range statements.
Makes minor fixes flagged by staticcheck
Adds instructions for setting up a Go workspace in HACKING doc
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #OCPBUGS-38755
Checklist

[x] Subject and description added to both, commit and PR.
[x] Relevant issues have been referenced.
[x] This change includes docs.

/jira cherry-pick OCPBUGS-38755

/jira refresh

/lgtm

Backport of PR https://github.com/openshift/hypershift/pull/4582

/retest-required


in app purchase current plan status

hello devs.
i used in app purchase and want to know if user canceled subscription or ended.
i can't find any way to know the status of current subscription .
or any way to get grand transaction id or way to connect my server to google to know the updates
any one can help me please .

Hi @ahmedfayed29, thanks for filing the issue.
I see there's an open issue addressing the case you described #52522.
Also, you can find there a referenced issue #49110 that its OP provided implementation for Android: https://github.com/flutter/flutter/issues/49110#issue-551774799
Closing as a duplication, so please follow up on it for further updates.


Span is not closed & exported when returning Mono.empty in Spring Cloud Function

Describe the bug
We are facing problems when using sleuth auto-instrumentation for kafka messaging. Everything works fine as long as we do not return an empty Mono in our reactive function. We even see invalid parent span IDs warnings in jaeger.
Any ideas or suggestions?
Sample
@Bean
public Function<Flux<Message<KafkaMessage>>, Mono<Void>> messageProcessor(Tracer tracer) {
    return data -> data
            .flatMap(inbound -> {
                log.info("Auto-created span");
                Span child = tracer.nextSpan().start();
                log.info("Manual inner span");
                child.end();
                return Mono.empty();
            }).then();
}

Out of curiosity, why are you returning an empty Mono? I mean we may never accounted for this case, but just curious.
Also, keep in mind we are very limited with what we can do on reactive function, since we have absolutely no control of the stream or when user does with it. The function acts only as initialisation function and invoked once at the startup to connect user stream (e.g., Flux). Once connected it's as if s-c-stream didn't even exist.
This is fundamentally different than an imperative function that is a classic message handler fully controlled by the framework.

Thanks for your reply @olegz
We do have some business logic where we do not want to publish a message on some cases (but also don't error because it is expected), so we have solved this by returning an empty Mono in the past. If you have suggestions/examples how to solve this in another way, we'd be happy for some input.
Now that we introduce tracing with sleuth in our services, the cases that return an empty Mono won't be traced properly (because of an unclosed span). I do understand that scf is limited on accessing the function provided by the user, but any other solution/workaround would also be fine for us.

If you want to publish message optionally and you can consider moving to imperative approach you can do a combination of Consumer and StreamBridge
@Bean
public Consumer messageProcessor(StreamBridge bridge, Tracer tracer) {
   return message -> {
       // do whatever with message
       // use tracer etc. . .
       if (i want to send a message) {
          bridge.send(bindingName, message);
       }
   };
}

This way you have full control and in case of any errors we would do what we promise with retries etc. . .
Let us know
Cheers

Moving to imperative is not really an option as most of our code is in reactive already. Is there any way using reactive to achieve this?

Have you tried
public Consumer<Flux<Message<KafkaMessage>>> messageProcessor(Tracer tracer) {
. . .
}

https://docs.spring.io/spring-cloud-stream/docs/current/reference/html/spring-cloud-stream.html#_consumer_reactive

I think we are fine when building it that way. Therefore I will close the issue for now.
Thanks @olegz


Need to be able to add headers when calling authorize_redirect()

Is your feature request related to a problem? Please describe.
I am using your library with the Flask client for an OAuth 2.0 flow.
The resource I am using your library with is behind a security gateway that is expecting auth in the HTTP headers. This is fine when I call...
token = oauth.myapp.authorize_access_token(headers=headers)
I can pass in HTTP headers for the auth, so that when the token is requested, it is authenticated by the HTTP gateway infront of my token issuer.
However, when I call...
return oauth.myapp.authorize_redirect(redirect_uri)
It looks for the server metadata, and gets it from a URL I specify in the registration, i.e.
server_metadata_url='https://dash.staging.mycompany.com/.well-known/jwks.json'
and the authorize_redirect() makes the HTTP request, but fails. I need a way to pass HTTP headers into this function as well.
Describe the solution you'd like
I would like to be able to run...
return oauth.myapp.authorize_redirect(redirect_uri, headers=headers)
Where headers contains HTTP authentication data.
Describe alternatives you've considered
I tried passing in the headers, hoping that **kwargs would be passed through and at some point the headers respected. But it didn't work.
Additional context
None

+1 I am also interested in having this feature

A PR is welcome.


Fixed 1 misspelling and 2 grammartical errors in app/src/main/res/values-bn/strings.xml

There was a misspelling in this text. Which I fixed it.
also tomorrow means 'আগামীকাল' but not 'আগামী কাল' . They are pronounced and written together.
'আগামী কাল' is wrong
If you wanna check, I am giving you a few examples

also I forgot to mention it's 'প্রতিদিন' not 'প্রতি দিন'

Hi,
Thanks for your contribution, however Sunflower is going to be archived in favour of maintaining a smaller set of up-to-date set of compose-samples, that can be found here: https://github.com/android/compose-samples, as well as snippets that can be found here: https://github.com/android/snippets.
Please feel free to keep your fork up-to-date for your learning, but this repository will be archived shortly.


test/ec_internal_test: link with libapps.a too

Whenever the source from $target{apps_init_src} is added to the source
of a test program, it needs to be linked with libapps.a as well.  Some
init sources depend on that.
Without this, builds break on VMS because of the unresolved symbol
'app_malloc'.
On platforms that do not need anything from libapps.a, adding it is a
no-op.
This is for OpenSSL 1.1.1 only.  OpenSSL 3.0 and beyond have a
different solution.

This pull request is ready to merge

Merged
ed96022218e71efcf50c69cd6997ed85a2c37ffe test/ec_internal_test: link with libapps.a too


Autolinker plugin strips out percent signs and some digits in Java (and maybe others)

With the Autolinker plugin enabled, Prism mistakenly replaces some percent signs and digits. I've only seen this in Java but other languages might be affected as well.
("%010d")

would become:
("0d")

Here's a minimal reproduction: https://codesandbox.io/s/r5o7ny0x74
Something important to note here though, is that this doesn't happen if only the Java language is included in the Prism object. It's when you add all the others that this is reproducible, so I'm guessing it's some sort of conflict with the grammar or hooks for another language.
Reference: https://github.com/refined-bitbucket/refined-bitbucket/issues/264

Wow, that was really quick!
Thanks a lot guys!


Fix the issue with duplicate field methods

Purpose
Fix the duplication of field methods when a superclass has a public field with the same name as that of the class for which bindings are generated.
Fixes #24029
Approach

Describe how you are implementing the solutions along with the design details.

Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[X] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #24033 into ballerina-1.2.x will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           ballerina-1.2.x   #24033   +/-   ##
================================================
  Coverage            14.59%   14.59%
================================================
  Files                   51       51
  Lines                 1411     1411
  Branches               219      219
================================================
  Hits                   206      206
  Misses                1189     1189
  Partials                16       16

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 fc808fa...6a6fa49. Read the comment docs.


Control preserve_format settings per template

I'd like to provide this setting in the template rather than setting it globally. Is that possible?  If not I'm requesting that feature.  I attempted to pass preserve_format=True but had no effect.
http://sorl-thumbnail.readthedocs.org/en/latest/reference/settings.html#thumbnail-preserve-format
Thanks!

Note: this is in response to issue #12.  My transparent images are converted from PNG to JPG and background turns black.  I'd be satisfied if they had a white background instead.
But rather than force preservation of all images, I'd like to only do so for these which are logos.

Can someone please speak to my original question -- is this currently possible?  OR if someone has an alternative for me for what I'm trying to do (previous comment), that would be helpful too. Thank you.

I'm seeing this same issue. Given that this bug was reported 2.5 years ago without a response, is it safe to assume that sorl is a dead project? I don't particularly look forward to switching to another imaging app. 😔

@jaddison The last release on PyPi was last November, I wouldn't call sorl-thumbnail a dead project. Also, it's a Jazzband project, so anybody can commit a fix to the GitHub repo if they want.


Automation triggered at every boot of HA

Describe the bug
After upgraded to 2.22/2.23 release I have automation related to sensor.raccolta_indifferenziata was triggered every time I reboot HASSIO
Configuration
YAML or Config Flow (GUI):
  - name: raccolta_indifferenziato_mattino
    frequency: "weekly"
    collection_days:
    - mon
    move_country_holidays: IT
  - name: raccolta_organico_mattino
    frequency: "weekly"
    collection_days:
    - mon
    - thu
    move_country_holidays: IT

Error log/debug information
No error

To enable debug logging, add custom_components.garbage_collection: debug to your config under logger/logs.
Screenshots
If applicable, add screenshots to help explain your problem.
Version
Integration version, Home Assistant version and configuration
0.109.7 with HACS

If you enable debug, in the log it should say something like
2020-05-16 13:29:11 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (test) Calling update
2020-05-16 13:29:11 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (test) Found next date: 22-May-2020, that is in 6 days

Does that show the correct date there?

this are my debug logs:
garbage_collection
Version: 2.23
This is a custom integration
If you have any issues with this you need to open an issue here:
https://github.com/bruxy70/Garbage-Collection/issues
-------------------------------------------------------------------

2020-05-16 17:17:10 INFO (MainThread) [custom_components.garbage_collection]
-------------------------------------------------------------------
garbage_collection
Version: 2.23
This is a custom integration
If you have any issues with this you need to open an issue here:
https://github.com/bruxy70/Garbage-Collection/issues
-------------------------------------------------------------------

2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (raccolta_indifferenziato_mattino) Country Holidays with parameters: country: IT, prov: None, state: None, observed: True
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (raccolta_indifferenziato_mattino) Found these holidays:
  2020-06-02: Festa della Repubblica
  2020-08-15: Assunzione della Vergine
  2020-11-01: Tutti i Santi
  2020-12-08: Immacolata Concezione
  2020-12-25: Natale
  2020-12-26: Santo Stefano
  2021-01-01: Capodanno
  2021-01-06: Epifania del Signore
  2021-04-04: Pasqua di Resurrezione
  2021-04-05: Lunedì dell'Angelo
  2021-04-25: Festa della Liberazione
  2021-05-01: Festa dei Lavoratori
  2021-06-02: Festa della Repubblica
  2021-08-15: Assunzione della Vergine
  2021-11-01: Tutti i Santi
  2021-12-08: Immacolata Concezione
  2021-12-25: Natale
  2021-12-26: Santo Stefano
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (raccolta_organico_mattino) Country Holidays with parameters: country: IT, prov: None, state: None, observed: True
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (raccolta_organico_mattino) Found these holidays:
  2020-06-02: Festa della Repubblica
  2020-08-15: Assunzione della Vergine
  2020-11-01: Tutti i Santi
  2020-12-08: Immacolata Concezione
  2020-12-25: Natale
  2020-12-26: Santo Stefano
  2021-01-01: Capodanno
  2021-01-06: Epifania del Signore
  2021-04-04: Pasqua di Resurrezione
  2021-04-05: Lunedì dell'Angelo
  2021-04-25: Festa della Liberazione
  2021-05-01: Festa dei Lavoratori
  2021-06-02: Festa della Repubblica
  2021-08-15: Assunzione della Vergine
  2021-11-01: Tutti i Santi
  2021-12-08: Immacolata Concezione
  2021-12-25: Natale
  2021-12-26: Santo Stefano
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (garbage_collection) Calling update
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (garbage_collection) Found next date: 19-May-2020, that is in 3 days
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (raccolta_indifferenziato_mattino) Calling update
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (raccolta_indifferenziato_mattino) Found next date: 18-May-2020, that is in 2 days
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (raccolta_organico_mattino) Calling update
2020-05-16 17:17:25 DEBUG (MainThread) [custom_components.garbage_collection.sensor] (raccolta_organico_mattino) Found next date: 18-May-2020, that is in 2 days

I attach also other configurations, I hope these could be useful.
in configuration.yaml:
input_datetime:
# garbage collection addon entry to manage datetime
  only_time_organico:
    name: time_organico
    has_date: false
    has_time: true
    initial: '19:45'
  only_time_indifferenziata:
    name: time_indifferenziata
    has_date: false
    has_time: true
    initial: '19:55'
  datetime_organico:
    name: datetime_organico
    has_date: true
    has_time: true
  datetime_indifferenziata:
    name: datetime_indifferenziata
    has_date: true
    has_time: true

my automation for sensor indifferenziata:
automation:
  alias: "Notifica ritiro indifferenziata"
  trigger:
    platform: numeric_state
    entity_id: sensor.raccolta_indifferenziata_mattino
    value_template: "{{ state.attributes.days }}"
    below: 1
  condition: []
  action:
# Sets date and time to date and time from timestamp (current date and time in this example)
    - service: input_datetime.set_datetime
      data_template:
        entity_id: input_datetime.datetime_indifferenziata
        date: >
          {{ now().timestamp() | timestamp_custom("%Y-%m-%d", true) }}
        time: >
          {{ now().timestamp() | timestamp_custom("%H:%M:%S", true) }}

and automation notification 20 hours after midnight:
automation:
- alias: "notifica il giorno dopo il ritiro indifferenziata"
  trigger:
    platform: template
    value_template: "{{ states('sensor.date_time').replace(',', '')|as_timestamp >= state_attr('input_datetime.datetime_indifferenziata', 'timestamp') + 20*60*60 }}"
  condition: []
  action:
    - service: notify.famiglia
      data:
        message: "Attenzione: oggi è giorno di ritiro indifferenziata."
    - service: notify.alexa_media
      data:
        target:
          - media_player.echo_dot_di_daniele
        data:
          type: announce
        message: "Attenzione: oggi è giorno di ritiro indifferenziata."

the other automation of organic isn't triggered after HASSIO reboot...

Excellent info. So it looks like the initial update works correctly, so the automation is triggered even before that. I made a change of the initial value, that should fix that. Please install 2.23-beta2 (should have called that 2.24-beta2).
Weird thing is, that it happened with 2.22/23, this part of code was there since long time ago, I did not change that.

I can install it directly HACS?

Yes, just say you want to show beta under the ...

Hi,
I installed 2.23-beta2 (lastest version), but issue remain...

O have been testing this, but I cannot replicate that. I set-up the same automation, restarting HA, but it does not trigger it.
The integration does not set the value to 0 (as per the logs you sent). And it does not have 0 as default value either. Could there be something else that sets it to 0?
Did you say you had two sensors, one does it and the other does not? What is the difference between them?

Yes, I have 2 sensors: only only have this problem, but the 2 sensors have 2 different type of automation...I don’t have anything else that set it to 0...
I don’t understand what happen...

I do not know what is causing it.
But as a workaround, you can add a condition that Home Assistant is running for more than, let's say 2 minutes.
Add a sensor:
sensor:

platform: uptime
name: "HA runtime in minutes"
unit_of_measurement: minutes

And then in the automation add a condition:
- condition: numeric_state
entity_id: sensor.ha_runtime_in_minutes
above: 2

amazing trick!
thanks


ppd-generator.c: Check for urf-supported if we found image/urf

Some devices has AirPrint disabled by default/admins has disabled it, but the device reports image/urf in document-format-supported, but provides no urf-supported attribute, which breaks PPD generation.
We should check for urf-supported once we found image/urf, so in case the device is missing urf-supported and provides other driverless standard, the other standard is used for PPD generation.
Fixes Fedora issue

Thanks for the PR, I have merged it now.
In reality, all the 3 Raster output formats, not only Apple Raster, but also PWG Raster and PCLm have additional printer IPP attributes (pwg-... and pclm-...) describing which resolutions, color modes, ... are accepted when using the format. So to make it perfect one should also check for PWG Raster and PCLm whether these additional attributes are actually there and so raster data working on the printer can be generated.

@tillkamppeter sounds great!
I see pclm-source-resolution-supported as required for PCLm, and pwg-raster-document-resolution-supported for PWG Raster in the generator (the IPP Everywhere standard marks several other attrs as required, but I guess our generators want to be permissive...) - sounds good to add checks for them?

Yes, I would do so, so that the formats PWG Raster and/or PCLm are only accepted if there is sufficient info to generate them correctly.
For me it looks like that document-format-supported does not change with the settings done in the web admin interface of the printer, but the urf-supported, pwg-..., and pclm-... attributes are included or not included depending on which format are turned on and which are turned off by the web interface. It would be correct if document-format-supported also varies accordingly with the settings. But as this is not the case we have to check for the required attribute being present in order to accept a certain input format.


oci-arm-host-capacity/vendor/autoload.php.php is not found

Line 8 of index.php requires the file "autoload.php" but it does not exist
Causing error :
PHP Warning:  require(/home/ubuntu/oci-arm-host-capacity/vendor/autoload.php): Failed to open stream: No such file or directory in /home/ubuntu/oci-arm-host-capacity/index.php on line 8
PHP Fatal error:  Uncaught Error: Failed opening required '/home/ubuntu/oci-arm-host-capacity/vendor/autoload.php' (include_path='.:/usr/share/php') in /home/ubuntu/oci-arm-host-capacity/index.php:8
Stack trace:
#0 {main}
thrown in /home/ubuntu/oci-arm-host-capacity/index.php on line 8
Can anyone help ?

Sorry, I forgot to compose it
composer install


.key.js.example file

Required the .key.js file with the API keys in order to run the application. We do not know the structure of the file for now.
A .key.js.example file would be good to provide the structure without the actually data.

Whoops, good call. Just added it.


Adding Contributing guidelines

It contains more diversed contributing guidelines

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 6

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 6

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 9

See the complete overview on Codacy

https://github.com/rpotter12/whatsapp-play/issues/142 , this issue is assigned


Update Fargate README to include setup for accepting data on receivers

The current instructions provide basic details for gathering ECS Fargate infrastructure data:
https://github.com/signalfx/splunk-otel-collector/tree/main/deployments/fargate
Can this be updated to include examples of accepting traces from apps within the task, eg. include ports that need to be mapped to receive spans on.

The documentation points to the fargate default configuration file here:
https://github.com/signalfx/splunk-otel-collector/blob/main/cmd/otelcol/config/collector/fargate_config.yaml
It contains definitions of receivers with specific ports to target. Hopefully this is good enough to get you going.
Since this issue is rather old, I'm going to close it, please feel free to open new issues for any further work.


Adopt the memray trace leaks test markers

Will work through once https://github.com/bloomberg/pytest-memray/pull/52 is merged.
Also fixed leaks found whilst using this:

Logger->usesTime leaks const string
StreamHandler->hasFlush can use the "flush" const instead of initializing another string

Codecov Report

Merging #137 (ad6f8bf) into main (783acf1) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #137      +/-   ##
==========================================
+ Coverage   88.99%   89.00%   +0.01%
==========================================
  Files          11       11
  Lines        2108     2111       +3
==========================================
+ Hits         1876     1879       +3
  Misses        232      232

Impacted Files
Coverage Δ

src/picologging/formatstyle.cxx
84.72% <100.00%> (+0.16%)
:arrow_up:

src/picologging/streamhandler.cxx
94.80% <100.00%> (ø)

src/picologging/handlers.py
94.55% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


@rancher/shell 0.3.3 causing errors with extensions

Setup

Rancher version: v2.7.1
Kubernetes version: v1.24.10+k3s1
Browser type & version: FF 109.0.1

Describe the bug

For reference: https://github.com/kubewarden/ui/issues/247
After bumping the @rancher/shell package to 0.3.3, certain views from an extension remain blank with errors in the console. The errors include:
TypeError: e.$plugin.getUIConfig is not a function
TypeError: e.extensionData is undefined

To Reproduce

Install rancher on a k3s cluster
Add the Kubewarden extension 1.0.1
Follow the installation process of the kubewarden-controller
Add the kubewarden-defaults helm-chart
Navigate to the Policy Server list view

Result
The page will fail to load and will only show a blank screen with the resource masthead
Expected Result

Should be able to view the Policy Server in the sortable table
Screenshots

Policy server list view

Cluster admission policy list view

Errors in console

Additional context

These issues do not appear when running Rancher within a Docker container.

Thanks @richard-cox, I didn't catch that PR before making the issue.

Closing as this has been fixed with the release of @rancher/shell 0.3.4


error: could not find --path/ move-cli in registry crates-io with version *

While installing Cargo with Move it returns this error:
$ cargo install language/tools/move-cli
error: could not find tools/move-cli in registry crates-io with version *
anyway to fix this??
Thanks

What were you expecting it to do?

to install cargo, what else

The commands they provide are different from yours (as of move-language/move#10e921dd).

Installation
$ cargo install --path move/language/tools/move-cli

or
$ cargo install --git https://github.com/move-language/move move-cli --branch main

You need to use --path flag if you are going to install a binary from a local package. For more information, please see the manual of cargo install.
Those commands work on my machine, and it is more appropriate to file this kind of bug first to the project move-language/move before identifying it is a bug from Cargo. I am going to close this as there seems no bug and not related to Cargo. Thank you.

thanks


Charging status on battery

I was going to ask the same. The battery doesn't seem to update when the value changes. Is there a fix for that?


Replaced Bootstrap tour by IntroJs in EBook Activity

Migrated EBook Activity from Bootstrap Tour to IntroJs https://github.com/llaske/sugarizer/issues/1090

Hey @llaske , I have Migrated the EBook Activity's Tutorial to IntroJS. Can you please Review it.

Do not change indentation style in files. Only updated lines should be changed in files.
Check your IDE options.

Hey @llaske , sorry for the formatting issue will definately remember it from next time. can you review

No, sorry @ABHINAV-JHA-27 you need to update your PR to reset indentation.
For maintenance reason, it's very important to be able to see which PR impact which lines.


Remove stray metadata.textproto

This file looks like it was moved to feature/system/management/otg_tests/management_ha_test/metadata.textproto but the old file was not removed.

Pull Request Functional Test Report for #2849 / 12e1df0dd2454aa06d2c6fbfffa2aa347efc729f
No tests identified for validation.
Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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 54.484%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1847

Relevant Lines:
3390

💛  - Coveralls


added a -Dev for the chromebook change

Pull request checklist:

[x] CHANGELOG.md was updated, if applicable

Description

IF anything, it should be done in 1 PR, learn how to push to an existing branch.
This is not worth a changelog entry.


[2.x]: Add @Target(ElementType.METHOD) for annotation @MPTest

Javadoc for annotation @MPTest tells Test method annotation, but it can be in any place: parameter or class.
I think it's better to add some specific target.

/trigger


Parsing switch expression with when clause with closure

This is excerpt from language/patterns/guard_error_test.
Object f() {
  return switch (false) {
    var x when (){ return true; }() => x,
    _ => false,
  };
}

This reports
  Found but did not expect:
    ParserErrorCode.EXPECTED_TOKEN [56, 1, "Expected to find '=>'."]
    ParserErrorCode.UNEXPECTED_TOKEN [58, 6, "Unexpected text 'return'.", "Try removing the text."]
    ParserErrorCode.EXPECTED_TOKEN [69, 1, "Expected to find '}'."]
    ParserErrorCode.EXPECTED_TOKEN [75, 2, "Expected to find '}'."]
    CompileTimeErrorCode.NON_BOOL_CONDITION [54, 2, "Conditions must have a static type of 'bool'.", "Try changing the condition."]
    CompileTimeErrorCode.INVOCATION_OF_NON_FUNCTION_EXPRESSION [56, 16, "The expression doesn't evaluate to a function, so it can't be invoked."]
    CompileTimeErrorCode.NON_EXHAUSTIVE_SWITCH [22, 6, "The type 'bool' is not exhaustively matched by the switch cases.", "Try adding a default case or cases that match true."]
    HintCode.UNUSED_LOCAL_VARIABLE [47, 1, "The value of the local variable 'x' isn't used.", "Try removing the variable or using it."]

This is actually quite tricky, due to how we're handling a related grammar ambiguity.
As explained in the spec, constructs like this are ambiguous:
var x = switch (obj) {
  _ when a + (b) => (c) => body
};

(because either => could be interpreted as separating the guardedPattern from its corresponding expression, and the other => separates function literal parameters from a function literal body).
The spec says that "When => is encountered after when in a guard, if the code between forms a valid expression, then it is interpreted as such and the => is treated as the separator between the guard and case body."
But this is not precisely what I implemented (oops).  The rule I actually implemented was: a function expression cannot appear in a guard, unless it is inside grouping operators (parens, brackets, or curly braces).  This means that a parenthesized group appearing in a guard is always parsed as a parenthesized expression or a record literal, and never as function literal arguments.
This is my fault--I didn't realize at the time that there were user-visible differences between what I was doing and what was specified.  Looking at it now, I think there are two user-visible differences:

According to the spec, it should be possible to put a block-bodied function literal in a guard clause (because it's not ambiguous).  But this doesn't work, and the error messages the user gets from the parser aren't very helpful, because the parser tries to parse the parens as a parenthesized expression or record literal, and then it has no idea what to do with the { that follows.  That's what's happening in @scheglov's example.

According to the spec, it should be possible to put an expression-bodied function literal in a guard clause, provided that the text before the first => does not form a valid expression.  For example, the parser should accept the switch expression switch (...) { var x when y + (int z) => true => x, ...}.  (And indeed, for an appropriate definition of y, this could even have well-defined runtime semantics).  But this doesn't work, and again the error messages the user gets from the parser aren't very helpful, because the parser tries to intrepret the contents of the parentheses as an expression.

Unfortunately, implementing precisely what was specified would be very challenging, because the parser is event-based, and so it is not easy for it to determine whether a sequence of tokens forms a valid expression without committing to parsing that sequence of tokens.  (It's technically possible using the NullListener, but it's tricky to get right and carries performance penalties).
I'm considering a few alternatives:

Change the spec to match what I implemented, and add some error recovery logic to the parser to try to give a more useful error message for @scheglov's example.

Change the spec to say that only expression-bodied function literals are prohibited in guard clauses.  This would allow @scheglov's example to be accepted.  Unfortunately, it's non-trivial to implement, because in some circumstances the parser commits to parsing a function literal before it's seen the { or => token.

Before I do any coding, I'll gather opinions from some folks about what to do.

So the spec says:

When => is encountered after when in a guard, if the code between forms a valid expression, then it is interpreted as such and the => is treated as the separator between the guard and case body.

I'm actually a little surprised I wrote it that way because "forms a valid expression" feels very brittle and annoying to parse to me. I recall avoiding a similar formulation to resolve another ambiguity. I definitely wouldn't want a slight tweak to a guard that causes the stuff before => to step outside of the overlap between parameter list and expression to cause the entire thing to be reinterpreted:
// OK, could be an expression but also happens to be a parameter list:
case _ when (a, b, c, {e, f, g}) => true => body;

// Oops, now it must be a parameter list:
case _ when (a, b, c, {e, int f, g}) => true => body;

The rule I actually implemented was: a function expression cannot appear in a guard, unless it is inside grouping operators (parens, brackets, or curly braces).

I like that. My understanding of what you propose here is that there's basically two copies of the entire expression grammar. One allows function expressions and the other does not. All of the places in the grammar delimited by braces take you to the expression grammar that allows function expressions. The grammar rule for guards (and constructor initializers) take you to the one that doesn't. But within that function-less grammar, the rules for parenthesized expressions, argument lists, collection literals, etc. all hop you over back to the grammar where function expressions are allowed.
That would mean these are all OK (syntactically):
case _ when (() => true) => body; // Parenthesized.
case _ when [() => true] => body; // List literal.
case _ when {() => true} => body; // Set literal.
case _ when {k: () => true} => body; // Map literal.
case _ when foo(() => true) => body; // Argument list (including `assert`, `super`, method calls).
case _ when [() => true] => body; // List literal.
case _ when list[() => true] => body; // Index operator.

But these are parse errors:
case _ when () => true => body; // Bare.
case _ when !() => true => body; // Prefix operand.
case _ when a + () => true => body; // Infix operand.
case _ when a = () => true => body; // Assignment value.
case _ when c ? a : () => true => body; // Conditional operand.
case _ when c ? () => true : a => body; // Conditional operand.

Do I have that right?
If so, that sounds reasonable to me, though I worry about the complexity and how we specify it. ECMAScript has a whole thing around grammatical parameters and it would be nice to not have to go there.

Unfortunately, implementing precisely what was specified would be very challenging, because the parser is event-based, and so it is not easy for it to determine whether a sequence of tokens forms a valid expression without committing to parsing that sequence of tokens.

We already know it's going to be parsing an expression. We don't know whether that expression will turn out to be a function expression or something else, but the thing after when is definitely an expression. It's just a question of what kind or expression and whether the => is part of it.
We already resolve that parsing difficulty somehow, because you run into it basically everywhere:
var x = (a, b, c, d, e, f …

When the parser is at (, it doesn't know if that's going to ultimately be a function expression and those identifiers are parameters, or a record literal and those identifiers are expressions. (Even before record literals, it's possible to conjure up an arbitrarily long sequence of tokens that is both a valid parameter list and expression.)
Another approach I could see us taking is that we parse the guard expression with maximal munch: If it's possible for the => to be consumed and used as part of a function expression, then do so. If that's not what you want, then parenthesize it yourself to avoid it.
I think that's more or less how we handle function expression bodies when they have infix or postfix operators following them: the body eats them all so () => a + b is parsed as () => (a + b) and not (() => a) + b. Would that work here? How much churn would that cause?

I like the "only inside delimiters" rule too, like we do in initializer list expressions too. (So it's not a new idea).

So the spec says:

When => is encountered after when in a guard, if the code between forms a valid expression, then it is interpreted as such and the => is treated as the separator between the guard and case body.

I'm actually a little surprised I wrote it that way because "forms a valid expression" feels very brittle and annoying to parse to me. I recall avoiding a similar formulation to resolve another ambiguity. I definitely wouldn't want a slight tweak to a guard that causes the stuff before => to step outside of the overlap between parameter list and expression to cause the entire thing to be reinterpreted:
// OK, could be an expression but also happens to be a parameter list:
case _ when (a, b, c, {e, f, g}) => true => body;

// Oops, now it must be a parameter list:
case _ when (a, b, c, {e, int f, g}) => true => body;

The rule I actually implemented was: a function expression cannot appear in a guard, unless it is inside grouping operators (parens, brackets, or curly braces).

I like that. My understanding of what you propose here is that there's basically two copies of the entire expression grammar. One allows function expressions and the other does not. All of the places in the grammar delimited by braces take you to the expression grammar that allows function expressions. The grammar rule for guards (and constructor initializers) take you to the one that doesn't. But within that function-less grammar, the rules for parenthesized expressions, argument lists, collection literals, etc. all hop you over back to the grammar where function expressions are allowed.

Yes, that's a good description of what I implemented.  Incidentally, as @lrhn mentioned above, I didn't invent this rule from scratch--I repurposed what the parser was already doing for constructor initializers.  Curiously, I don't see anything in the spec prohibiting undelimited function expressions inside constructor initializers.  I guess this is a piece of technical debt for the spec (@eernstg I'd be curious what the spec parser does 😃).

That would mean these are all OK (syntactically):
case _ when (() => true) => body; // Parenthesized.
case _ when [() => true] => body; // List literal.
case _ when {() => true} => body; // Set literal.
case _ when {k: () => true} => body; // Map literal.
case _ when foo(() => true) => body; // Argument list (including `assert`, `super`, method calls).
case _ when [() => true] => body; // List literal.
case _ when list[() => true] => body; // Index operator.

But these are parse errors:
case _ when () => true => body; // Bare.
case _ when !() => true => body; // Prefix operand.
case _ when a + () => true => body; // Infix operand.
case _ when a = () => true => body; // Assignment value.
case _ when c ? a : () => true => body; // Conditional operand.
case _ when c ? () => true : a => body; // Conditional operand.

Do I have that right?

Yes, I belive so.

If so, that sounds reasonable to me, though I worry about the complexity and how we specify it. ECMAScript has a whole thing around grammatical parameters and it would be nice to not have to go there.

If you're worried about implementation complexity, you don't need to, because it's already implemented, and it's fairly simple (the parser just has a boolean that keeps track of whether we're in a context where function literals are allowed).  If you're worried about specification complexity, then yeah, I see where you're coming from.  But that horse has already fled the stables because we're already doing this for constructor initializers 😃.

Unfortunately, implementing precisely what was specified would be very challenging, because the parser is event-based, and so it is not easy for it to determine whether a sequence of tokens forms a valid expression without committing to parsing that sequence of tokens.

We already know it's going to be parsing an expression. We don't know whether that expression will turn out to be a function expression or something else, but the thing after when is definitely an expression. It's just a question of what kind or expression and whether the => is part of it.
We already resolve that parsing difficulty somehow, because you run into it basically everywhere:
var x = (a, b, c, d, e, f …

When the parser is at (, it doesn't know if that's going to ultimately be a function expression and those identifiers are parameters, or a record literal and those identifiers are expressions. (Even before record literals, it's possible to conjure up an arbitrarily long sequence of tokens that is both a valid parameter list and expression.)

Right.  And the way the parser currently disambiguates that is to look at the token after the matching ).  If it's =>, {, async, or sync, then parse the thing between parens as function literal arguments; otherwise parse it as expressions.  That works everywhere except in constructor initializers and pattern guards, hence the approach I took.

Another approach I could see us taking is that we parse the guard expression with maximal munch: If it's possible for the => to be consumed and used as part of a function expression, then do so. If that's not what you want, then parenthesize it yourself to avoid it.
I think that's more or less how we handle function expression bodies when they have infix or postfix operators following them: the body eats them all so () => a + b is parsed as () => (a + b) and not (() => a) + b. Would that work here? How much churn would that cause?

Unfortunately I don't think that works, because we need this unambiguous case to parse correctly: switch (...) { pattern when (...) => value, ... }.  With the "maximal munch" rule, after consuming the when token, we would see the (, skip to the matching ), see that the next token is =>, and incorrectly conclude that the thing between parens is a set of function literal arguments.  In this scenario, there's no way to get the parser to do the right thing by adding parens.

I don't see anything in the spec prohibiting undelimited function expressions inside constructor initializers

We know (even if we occasionally forget): https://github.com/dart-lang/sdk/issues/11509

I think we could make our spec-work easier if we introduce parameterized grammars, say something like:
<list>[element]{allowTrailingComma} ::= element (',' element)* <trailingCommaOpt>{allowTrailingComma}
                                                                | <empty>
<trailingCommaOpt>{allowTrailingComma} ::= ',' -- if allowTrailingComma
                                                                         | <empty>

where the [...] are production arguments and {...} are value arguments (usually Boolean flags).
Then we wouldn't have to have both expression and expressionNoCascade. It'd just be<expression>{allowCascade} ::= ....
That allows reuse, which avoids accidental drift.
And the we could have <expression>{allowFunctionExpression} ::= ... which would pass down the flag along the productions that can end up in a function expression, until | <functionExpression> -- if allowFunctionExpression.
I'm thinking that's effectively what you have implemented anyway.

If you're worried about implementation complexity, you don't need to, because it's already implemented, and it's fairly simple (the parser just has a boolean that keeps track of whether we're in a context where function literals are allowed).

I'm not particularly worried about implementation complexity because it's pretty easy to make a parametric recursive descent parser by just, well, passing around parameters.

If you're worried about specification complexity, then yeah, I see where you're coming from. But that horse has already fled the stables because we're already doing this for constructor initializers 😃.

This one. :)
Parametric grammars are sorely tempting but I can't help but feel like it leads to more syntactic complexity than we want. But in this case, we're already doing it, so I guess it's not harmful. Keeping guards consistent with constructor initializers sounds good to me.
Any thoughts on how I should specify this in the proposal? My understanding is that the spec doesn't actually specify constructor initializers correctly right now.

As of https://github.com/dart-lang/language/commit/46411cb4a9ec4cf3d2f0c9f756c51171ccac7e94, the specification has been updated to match what was implemented (function literals are now prohibited in guards unless enclosed in parentheses, square brackets, or curly braces).
So now the behaviour of the implementation is technically spec compliant.  I'm keeping this issue open because I would still like to improve the error reporting if I can, but I'm reducing the priority to P2 since it's no longer a correctness issue.

@stereotype441 wrote:

I'd be curious what the spec parser does

The spec parser does not include the => function literal as a <primary>, it is included directly as an alternative in <expression>.
expression
    :    patternAssignment
    |    functionExpression // <----- This one derives `=>` function literals.
    |    throwExpression
    |    assignableExpression assignmentOperator expression
    |    conditionalExpression
    |    cascade
    ;

primary
    :    thisExpression
    |    SUPER unconditionalAssignableSelector
    |    SUPER argumentPart
    |    functionPrimary  // <----- This one derives block function literals.
    |    literal
    |    identifier
    |    newExpression
    |    constObjectExpression
    |    constructorInvocation
    |    '(' expression ')'
    |    constructorTearoff
    |    switchExpression
    ;

The fact that => function literals when included in <primary> are wildly ambiguous causes me to recommend that we make this approach the official one, every time this comes up. Here we go again: Let's do that! ;-)
Here is the snippet of the spec parser's grammar that deals with initializer lists:
initializerListEntry
    :    SUPER arguments
    |    SUPER '.' identifierOrNew arguments
    |    fieldInitializer
    |    assertion
    ;

fieldInitializer
    :    (THIS '.')? identifier '=' initializerExpression
    ;

initializerExpression
    :    conditionalExpression
    |    cascade
    ;

Interestingly, I haven't seen any failures based on the fact that I've used the patterns feature spec grammar rule exactly as stated:
guardedPattern
    :    pattern (WHEN expression)?
    ;

The reason for this is probably that ANTLR disambiguates the grammar using some techniques that we don't use in the Dart parser. Hence, I changed expression to initializerExpression in the guardedPattern rule above. The resulting treatment of the examples is as follows:
int get body => 2;

void main() {
  var _ = switch (0) {
    1 when (() => true) => body, // Parenthesized.
    1 when [() => true] => body, // List literal.
    1 when {() => true} => body, // Set literal.
    1 when {k: () => true} => body, // Map literal.
    1 when foo(() => true) => body, // Argument list.
    1 when [() => true] => body, // List literal.
    1 when list[() => true] => body, // Index operator.

    // Agree on most error cases mentioned earlier in this issue:
    // Error: 1 when () => true => body, // Bare.
    // Error: 1 when !() => true => body, // Prefix operand.
    // Error: 1 when a + () => true => body, // Infix operand.
    // Error: 1 when a = () => true => body, // Assignment value.
    // Error: 1 when c ? a : () => true => body, // Conditional operand.
    1 when c ? () => true : a => body, // Conditional operand.

    _ => body,
  };
}

(Actually, looking at this, I believe initializerExpression should include throw and assignment expressions; but I've never seen any failures because they aren't currently included).

Not a big loss. We're talking an unconditional throw or assignment here. I guess if you wanted to remember the most recent argument in a static variable, you can do this.foo = _fooCache = foo, but ... why?

Thanks to https://github.com/dart-lang/language/commit/46411cb4a9ec4cf3d2f0c9f756c51171ccac7e94 I believe this issue is now resolved; the code from the initial bug report is now disallowed by the spec, so it's expected that it won't parse successfully.


Bdomen fixing react test

Didn't update a require path when moving files around. Fixing this so the react tests pass.

This change is


Add traffic_ops_ort.pl suuport for processing ##OVERRIDE## lines from…

fix to require space after ##OVERRIDE## keyword
What does this PR do?
Fixes #(issue_number)
Which TC components are affected by this PR?

[ ] Documentation
[ ] Grove
[ ] Traffic Analytics
[ ] Traffic Monitor
[ ] Traffic Ops
[x] Traffic Ops ORT
[ ] Traffic Portal
[ ] Traffic Router
[ ] Traffic Stats
[ ] Traffic Vault
[ ] Other _________

What is the best way to verify this PR?
Select any existing base DS.  Create ANY_MAP delivery service to override.
Create raw remap text with something like:
Short example:
##OVERRIDE## map http://from.foo http://to.bar
Make sure both the base DS and ANY_MAP are assigned to a server.  run ORT in report mode to check that the ##OVERRIDE## rule is uncommented and that the base DS rule is commented out via ##OVERRIDDEN##.
Select to queue that particular server.  Inspect the generated remap.config for the above conditions.
Select to queue again.  Ensure that remap.config is not tagged as changed to avoid unnecessary config reloads.
Check all that apply

[ ] This PR includes tests
[ ] This PR includes documentation updates
[x] This PR includes an update to CHANGELOG.md
[ ] This PR includes all required license headers
[ ] This PR includes a database migration (ensure that migration sequence is correct)
[ ] This PR fixes a serious security flaw. Read more: www.apache.org/security

Can one of the admins verify this patch?


Added Google Gemma Api and documentation

PR Description
Added Google Gemma API and documentation
Closes Issue #116
Screenshots

Program
Gssoc 24

Gemma is a model not an API.


Populate Grid with Static Data from JSON String

Hello,
How can I populate serenity grid from any static JSON String along with filtration options ?

this.view.setItems(items, true); should do the job

also you might need to override getGridCanLoad
       protected getGridCanLoad() {
            return false;
        }

Hello,
Thanks for the response. Sorry for the stupid question but where  to write this.view.setItems(items, true); and where to pass json string so that It will show in grid. If possible can you show example of it

will check and Let you know....{ Id: 1 }, { Id: 2 } this should be replaced by my json stuff......But filter will work with this


Add a wrapper for select()

Closes #31
Needs testing
The wrapper isn't made a public function as there are extra POLL* flags that it doesn't account for, so it's suitable for internal use only.

Maybe we should just switch back to select() instead 😄


PD etcd storage full and out of service when CDC changefeed with error to connect to downstream mysql

What did you do?

Change downstream mysql setting: set global max_connections = 20000;
Create 50 kafka changefeeds, 50 MySQL changefeeds
Running workload
Kill downstream MySQL, and wait it is created by K8S, change dowstream mysql setting: : set global max_connections = 150;

What did you expect to see?
Some mysql changefeed will run into error because of failing to connect to downstream mysql. PD should still be able to service.
  {
    "id": "cdc-large-number-changefeed-mysql7",
    "namespace": "default",
    "summary": {
      "state": "error",
      "tso":<PHONE_NUMBER>07596801,
      "checkpoint": "2023-03-03 04:14:25.950",
      "error": {
        "addr": "upstream-ticdc-0.upstream-ticdc-peer.cdc-testbed-tps-1653470-1-820.svc:8301",
        "code": "CDC:ErrMySQLConnectionError",
        "message": "[CDC:ErrMySQLConnectionError]fail to open MySQL connection: Error 1040: Too many connections"
      }
    }
  },

What did you see instead?
PD etcs storage consumption increases rapidly and reach the limit of 8GB, and finally PD is out of service.
etcd storage usage metric when the issue happens:

etcd storage usage metric previously (when downstream MySQL max_connections doesn't decrease to 150)

Versions of the cluster
TiCDC version (execute cdc version):
latest master, and be able to reproduce with 03/21commit 4dcf1396ff8fc9e20bd424e069195bf06442182e
4dcf1396ff8fc9e20bd424e069195bf06442182e

PD version:
Release Version: v6.7.0-alpha
Edition: Community
Git Commit Hash: a99ff9f67bbf8eb83b9aec5a3f3e7aa81c8796ab
Git Branch: heads/refs/tags/v6.7.0-alpha
UTC Build Time:  2023-03-02 11:32:29

/severity Critical

/found Automation

This issue does not affect any release and only be triggered when there are lots of changefeeds in error state.


Can't figure out how to use Relationships

Hey!
I've been working on this for a few days and can't really figure it out.
In general, my goal is to give gomusicbrainz a MBID and get returned the URL relationships (Wikipedia, official website, Spotify, etc..).
For instance, this is my best try:
    // Grab Musicbrainz artist
    musicbrainzArtist, err := musicbrainzClient.LookupArtist(
        gomusicbrainz.MBID(artist.MusicbrainzID), "url-rels",
    )
    if err != nil {
        log.Warn(err)
        continue
    }
    // List all url
    for _, url := range musicbrainzArtist.Relations["url"] {
        fmt.Println(gomusicbrainz.URLRelation(url).Target) // error, don't know what to do here
    }

My question is: How do I convert a gomusicbrainz.Relation to gomusicbrainz.URLRelation?

Hej and sorry for my late response.
The problem in your example is, you are trying to cast an interface type to a struct. gomusicbrainz.Relation is an interface type that requires the TypeOf() method to be implemented on the actual type.
type Relation interface {
    TypeOf() string
}

What you want to do is a type assertion. Whenever you have an interface and want to access it's 'underlying' type, you have to assert the actual type.
Here is a small example that requests an artist and prints it's URL relations
package main

import (
	"fmt"
	"gomusicbrainz"
)

func main() {

	client, _ := gomusicbrainz.NewWS2Client(
		"https://musicbrainz.org/ws/2",
		"A GoMusicBrainz example",
		"0",
		"http://github.com/michiwend/gomusicbrainz")

	artist, err := client.LookupArtist(
		gomusicbrainz.MBID("fe1a873d-2000-4789-a895-4187fe756203"),
		"url-rels")

	if err != nil {
		fmt.Println(err)
		return
	}

	if urlRels, ok := artist.Relations["url"]; ok {
		for _, rel := range urlRels {

			urlRelation := rel.(*gomusicbrainz.URLRelation)

			fmt.Printf("%s: %s\n", urlRelation.Type, urlRelation.Target)
		}
	}
}

Thank you! A little late and figured out another solution, but thanks for enlightening me!


Admin: Disaggregation "select by default" option

Issue
As a country level manager or M&E advisor, I am able to promote specific country disaggregations that I want all programs to use. These are disaggregations that are relevant to all programs regardless of sector -- similar to SADD at the global level.
As a program level M&E person setting up indicators in Tola, I am still able to exercise my professional judgment and unselect disaggregations on an indicator-by-indicator basis, based on the context.
Admin Lite > Country disaggregations form

[x] 1. Under the required Disaggregation field is a checkbox with the label "Selected by default".

[x] 2. This checkbox is UNselected by default.

[x] 3. Next to the field label is a question mark icon. When clicked, the tool-tip tells me:
When adding a program indicator, this disaggregation will be selected by default. (It can be unselected for specific indicators.)
This option is recommended for disaggregations that are required for all programs in a country, regardless of sector.

Effects on the indicator setup form

[x] 1. When the box is UNchecked, the disaggregation is unselected by default whenever I add an indicator.

[x] 2. When the box is CHECKED, the disaggregation is selected by default whenever I add an indicator.

[x] 3. Any changes I make to this field only affect NEW indicators. It has no effect on SAVED indicators.

Global disaggregation rule

[ ] The Global disaggregation SADD ought to be selected by default -- the Django equivalent of having the "select by default" box checked.

Housekeeping (where applicable)

[ ] Unit test/s written
[ ] i18n strings included
[ ] Is accessible to people using screen readers

Touches both the admin form and the indicator modal, and probably involves some database changes, so medium.

I realized I may not have called out that SADD needs to be selected by default. Added it to the original ticket.

Sorry, I just realized I made a hash out of the requirements for saved indicators. Please see updated criteria.

All criteria met. I am going to file a separate ticket for some refinements requested by Carly, involving confirmation warnings and an option to retro-apply disaggregations to already-saved indicators for specific programs.


Arguments for apply()

So there is a little "bug" in operator line 152.
        for argname in o_vals.keys():
            if not arguments[argname].shape == o_vals[argname].shape:
                raise InvalidArgument("Shapes must match")

The little problem with this is, any passed argument needs to have the exact same shape, including number of time steps. I kinda of defeat the purpose of generic dimensions if there sizes can't be changed.
AN example would be
u = TimeData(name='u', shape=(100, ), time_order=1, space_order=2, time_dim=100)
# Derive the stencil according to devito conventions
eqn = Eq(u.dt, u.dx)
stencil = solve(eqn, u.forward)[0]
op = Operator([Eq(u.forward, stencil)], subs={h: dx, s: dt})

# Execute the generated Devito stencil operator
op.apply()

the doing
u2 = TimeData(name='u', shape=(100, ), time_order=1, space_order=2, time_dim=200)
op.apply(u=u2)

produces
InvalidArgumentTraceback (most recent call last)<ipython-input-7-3e325d1513f1> in <module>()
      6 # stencil = solve(eqn, u2.forward)[0]
      7 # op = Operator([Eq(u2.forward, stencil)], subs={h: dx, s: dt})
----> 8 op.apply(u=u2)
/Users/mloubout/Dropbox/London/CodeGen/devito/devito/operator.pyc in apply(self, *args, **kwargs)
    478         """Apply the stencil kernel to a set of data objects"""
    479         # Build the arguments list to invoke the kernel function
--> 480         arguments, dim_sizes = self.arguments(*args, **kwargs)
    481
    482         # Invoke kernel function with args
/Users/mloubout/Dropbox/London/CodeGen/devito/devito/operator.pyc in arguments(self, *args, **kwargs)
    152         for argname in o_vals.keys():
    153             if not arguments[argname].shape == o_vals[argname].shape:
--> 154                 raise InvalidArgument("Shapes must match")
    155
    156             arguments[argname] = o_vals[argname]
InvalidArgument: Shapes must match

I wonder if this our usual caching @mlange05

Well actually, thinking of it, it would be odd and error prone to pass arguments with differet sizes to apply as there is other objects ,m, src,rec that may not be compatible with this size leading to segfaults or errors.

Can this be closed @mlange05 ?

This should be fixed by last week PRs

yes, but there's a new (smaller) issue now that is waiting for #271 ...

yes, but there's a new (smaller) issue now that is waiting for #273 ...

I closed #273 as it is supposed to be fixed in #273

@mlange05 we can probably close this now?

Yes, I think the relevant parts have been addressed. Closing.


feature/loeffel-io/v2.3.0

@ccoVeille maybe you want to review the pr
You can build the docs by running NODE_OPTIONS=--openssl-legacy-provider pnpm run docs:dev

Review made on a phone without a computer. I'm in holidays.

Amazing, thank you for the review! Will work on this before launch


jsk_3rdparty: 2.1.11-0 in 'lunar/distribution.yaml' [bloom]

Increasing version of package(s) in repository jsk_3rdparty to 2.1.11-0:

upstream repository: https://github.com/jsk-ros-pkg/jsk_3rdparty.git
release repository: https://github.com/tork-a/jsk_3rdparty-release.git
distro file: lunar/distribution.yaml
bloom version: 0.6.6
previous version for package: null

assimp_devel

No changes

bayesian_belief_networks

No changes

downward
* downward: compile with -Wno-maybe-uninitialized to avoid error for 18.04 (#154 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/154>)
* Contributors: Kei Okada

ff

No changes

ffha

No changes

jsk_3rdparty

No changes

julius

No changes

julius_ros

No changes

libcmt
* libcmt: opencv2/xfeatures2d.hpp only required between 3.1.0 <= OPENCV_VERSION_CODE < 3.2.0 (#154 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/154>)
* Contributors: Kei Okada

libsiftfast
* fix for melodic (#154 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/154>)
  * libsiftfast : add 02.cmake_warn_narrowing.patch 03.skip_python_bindings.patch.bak 04.boost_65_numpy_1_10.patch for 18.04
  * libsiftfast: patch all fiels within pathes directory
* Contributors: Kei Okada

lpg_planner

No changes

mini_maxwell

No changes

nlopt
* add nlopt-extras.cmake to set nlopt_INCLUDE_DIR for https://github.com/jsk-ros-pkg/jsk_control/issues/696 (#153 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/153>)
* Contributors: Kei Okada

opt_camera

No changes

pgm_learner

No changes

respeaker_ros
* Add respeaker_ros package (#152 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/152>)
* Contributors: Yuki Furuta

ros_speech_recognition

No changes

rospatlite

No changes

rosping
* run sudo -E and set LD_LIBRARY_PATH, because LD_LIBRARY_PATH is not passwed after sudo -E or suid, see set ld_library_path within (#154 <https://github.com/jsk-ros-pkg/jsk_3rdparty/issues/154>)
* Contributors: Kei Okada

slic

No changes

voice_text

No changes

CI is failing with:
======================================================================
ERROR: test.test_build_caches.test_build_caches
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python2.7.14/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/travis/build/ros/rosdistro/test/test_build_caches.py", line 57, in test_build_caches
    raise RuntimeError('\n'.join(errors))
RuntimeError: lunar: missing package.xml file for package "collada_urdf_jsk_patch"
lunar: missing package.xml file for package "rostwitter"

@k-okada How does this compare to #19064 ?

Sorry this old pr which the result of my changes in patch file of the release repository
https://github.com/tork-a/jsk_3rdparty-release/commit/2004c754808a2198ae4042358ca27ebfea967a8c#diff-ae318d5044ea7486c9c68c659cac1409
And #19064 was correct one
https://github.com/ros/rosdistro/pull/19052#issuecomment-418947047


Fix TX5 ambient light change to 0 mode. error https://github.com/AlexxIT/SonoffLAN/issues/1247

In TX5 the ambient light modes ("lightMode") are between 0 and 7. Mode 0 is one of them.

I have tested it on my TX5

And why previous condition don't work?

because it had the condition of != "0" then modes 1 to 7 worked, but 0 is also a valid option. The device has 8 modes, 0 to 7. To turn off the ambient light it is not mode 0, it is "lightSwitch" to "off"

Thanks!

https://github.com/AlexxIT/SonoffLAN/releases/tag/v3.6.0


add slsa verifier

What type of PR is this?
/kind documentation

What this PR does / why we need it:
refer to https://github.com/karmada-io/karmada/pull/5178, we need to guide users to use slsa to verify release assets
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:

*.intoto.jsonl is the format of SLSA provenance file, but the spell check failed.

*.intoto.jsonl is the format of SLSA provenance file, but the spell check failed.

so I add it to ./typos.toml to aviod false-positives