Merge/Rebase ng into develop

Is there a plan on adding rebar3 support to the develop branch?

Yes, when I have some time
Carlos Gonzalez
Founder
ErlNETS Technologies SL
Navarro Ledesma 134, 29010 Malaga, Spain
+34674186274
On Thu, Sep 22, 2016 at 5:54 AM, Eric des Courtis<EMAIL_ADDRESS>wrote:

Is there a plan on adding rebar3 support to the develop branch?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/NetComposer/nksip/issues/69, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABEBoUcy5ug2m-sgKryijSoebqglbd9Mks5qsfv8gaJpZM4KDgWU
.

Do you need any help with this project? I have been working with SIP and Erlang for the last 8 years.

Sure, anything you can do towards making it rebar3-compatible (while passing tests) would be great.
I plan to work on that in the following weeks.

I am guessing I should make the changes on the develop branch.

ng would be better... I plan to be there in a week or so

I just tagged v0.5.0 with all tests passing
I plan now to merge into ng a continue to R19/rebar3

Hi, Carlos:
Is ng branch the updated branch with rebar integrated?
How do I proceed with the bugs/issues found in this branch?
I can't start the "make shell".
nksip_app.erl: line 80:
ServiceDefaults = nklib_util:extract(Parsed, ServiceKeys),
should be
ServiceDefaults = nklib_util:extract(maps:to_list(Parsed), ServiceKeys),


Error: A Yjs Doc connected to room "#room-name" already exists

Describe the bug
I'm getting an error when reconnecting and calling new WebrtcProvider() on a page refresh or after a disconnect.
To Reproduce
Steps to reproduce the behavior:
  const provider = new WebrtcProvider(name, doc, {
    password,
    signaling: servers,
    awareness,
  });

Then call provider.disconnect() or provider.destroy(), or just try connecting again with the same code and params as above.

Get error: Error: A Yjs Doc connected to room "#room-name" already exists

Expected behavior
A new provider can be created and sync to the existing room without error. Should return the provider.
Environment Information

Happens both in Browser [Chrome] and Node [Vitest]
"y-webrtc": "^10.2.5"
"yjs": "^13.5.16"

Sorry not sure why sourcemaps aren't working, but I've found where it originates:
// src/y-webrtc.js
const openRoom = (doc, provider, name, key) => {
  // there must only be one room
  if (rooms.has(name)) {
    throw error.create(`A Yjs Doc connected to room "${name}" already exists!`)
  }
  const room = new Room(doc, provider, name, key)
  rooms.set(name, /** @type {Room} */ (room))
  return room
}

Sorry. I realized I new WebRtcrRovider was getting called twice elsewhere in the code!


Lets get the task names from Cognitive Atlas

We want a list of task names that we can offer to our users as values for cognitive tasks. There is this project to harmonize task tames run by Valentina: https://docs.google.com/spreadsheets/d/1_f6M5ompblVKOxYbRQLmEi4PMHtFO40J/edit#gid=97866687
We should make a list of things to do for this. One of them is probably to see what the CogAtlas API has to offer us in terms of metadata: https://cognitiveatlas.org/api/task

@surchs Any thoughts as to what release to put this into?

I think this could go in with the (re-) addition of assessment tool annotation in (one of) the next release.

Noted for Milestone Cycle 4 (March)


[base-ui][docs] Remove "Styled" noise

A continuation of #37029. This feels much better. Open https://mui.com/base-ui/react-autocomplete/#hook, I can't imagine developers would want to use "Styled" in their actual implementation.

If developers use the hooks, by default, every component present in the file is styled, so styled is noise.
If they use the unstyled component, I think they should rename them all to be suffixed with Base.
const Button = styled(ButtonBase)({}) makes a lot more sense to me than the opposite. The button comes first, then it's nature. I think it's easier to read when the component is first.
So in https://mui.com/base-ui/react-button/#component, I think that we should rename the alias as well, the same way Radix suffix them with Primitive https://github.com/radix-ui/themes/blob/300260e3c3ed5fc491129b192760aad6f96c38ac/packages/radix-ui-themes/src/components/slider.tsx#L5.

Preview: https://deploy-preview-40478--material-ui.netlify.app/base-ui/react-autocomplete/#hook

Agree, I think that we should agree on one of the components as the gold standard and have these types of PRs to update it.

Adding @colmtuite to the loop as it's related to the docs experience for the demos of Base UI.

I agree on all changes. I have an open PR #40742 which focuses just on improving the functional CSS for the button demo. I'm planning to get back to that PR this afternoon.
Once that is merged, I'm planning to open another PR on the Button component to address imports/aliases and how to handle theme values and theming. We could then review that and potentially use it as a guide for updating other component docs.


No exports from module

Hi, I'm trying to do import/require on your module, but it does not provide anything. Could you please do module.exports for node environment?

Would you mind implementing it? It seems easy enough, you've got the environment set up and can verify that it works. It would be appreciated

Of course I don't think we should break compatibility for people who are using the global object as well.

I'm thinking something at the bottom like:
if (typeof module !== 'undefined' && typeof module.exports !== 'undefined') {
	module.exports = PrintHAF;
}

I suggest using an already existing pattern, like this one: https://github.com/umdjs/umd/blob/master/templates/commonjsStrict.js

@just-paja I appreciate the contribution, thanks again!


Add influx command shell hint

Closes #329

This is fine from a code perspective, tagging @samhld to review the screenshot.


fixFix external table show column stats type bug.

backport: https://github.com/apache/doris/pull/26910

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Question regarding tg_act.py file

Thank you for sharing this nice work!
I have a question regarding the tg_act.py. I encounter error when trying to run the train_act.py script. I encountered error points towards the following two lines.
  File "xxx/trafficgen/trafficgen/act/model/tg_act.py", line 105, in training_step
    loss_dict = {'train/' + k: v for k, v in loss.items()}
AttributeError: 'Tensor' object has no attribute 'items'

Seems to me that loss is a tensor that indeed does not have .items field, and the loss_dict is already returned by the act_loss function.
I commented out these two lines and I was able to run the script.
I wonder if these two lines are redundant?
https://github.com/metadriverse/trafficgen/blob/162add314dc0a1f63a4e39c2d51159349df8baef/trafficgen/act/model/tg_act.py#L105
https://github.com/metadriverse/trafficgen/blob/162add314dc0a1f63a4e39c2d51159349df8baef/trafficgen/act/model/tg_act.py#L112

Thank you for sharing this nice work! I have a question regarding the tg_act.py. I encounter error when trying to run the train_act.py script. I encountered error points towards the following two lines.
  File "xxx/trafficgen/trafficgen/act/model/tg_act.py", line 105, in training_step
    loss_dict = {'train/' + k: v for k, v in loss.items()}
AttributeError: 'Tensor' object has no attribute 'items'

Seems to me that loss is a tensor that indeed does not have .items field, and the loss_dict is already returned by the act_loss function.
I commented out these two lines and I was able to run the script. I wonder if these two lines are redundant?
https://github.com/metadriverse/trafficgen/blob/162add314dc0a1f63a4e39c2d51159349df8baef/trafficgen/act/model/tg_act.py#L105
https://github.com/metadriverse/trafficgen/blob/162add314dc0a1f63a4e39c2d51159349df8baef/trafficgen/act/model/tg_act.py#L112

Hello, have you resolved the problem? There are “items()” in dict in Python, and I guess the “loss. items()” here should be “loss_ dict. items()”, but I'm not sure. But after I made the changes, the code did run successfully.


Fix broken specs and deprecations

Fix for https://github.com/chef/supermarket/issues/1056
Also fixes these warnings we were seeing throughout the run:
6:00:39-nshamrell~/Projects/omnibus-supermarket/cookbooks/omnibus-supermarket (fix-broken-specs-dec)$ bundle exec rspec
.[DEPRECATION] `ChefSpec::Runner' is deprecated. Please use `ChefSpec::SoloRunner' or `ChefSpec::ServerRunner' instead. (called from spec/recipes/app_spec.rb:3
:in `block (2 levels) in <top (required)>')
.[DEPRECATION] `ChefSpec::Runner' is deprecated. Please use `ChefSpec::SoloRunner' or `ChefSpec::ServerRunner' instead. (called from spec/recipes/app_spec.rb:3
:in `block (2 levels) in <top (required)>')
.[DEPRECATION] `ChefSpec::Runner' is deprecated. Please use `ChefSpec::SoloRunner' or `ChefSpec::ServerRunner' instead. (called from spec/recipes/app_spec.rb:3
:in `block (2 levels) in <top (required)>')
.[DEPRECATION] `ChefSpec::Runner' is deprecated. Please use `ChefSpec::SoloRunner' or `ChefSpec::ServerRunner' instead. (called from spec/recipes/config_spec.r
b:3:in `block (2 levels) in <top (required)>')
.[DEPRECATION] `ChefSpec::Runner' is deprecated. Please use `ChefSpec::SoloRunner' or `ChefSpec::ServerRunner' instead. (called from spec/recipes/config_spec.r
b:3:in `block (2 levels) in <top (required)>')
.[DEPRECATION] `ChefSpec::Runner' is deprecated. Please use `ChefSpec::SoloRunner' or `ChefSpec::ServerRunner' instead. (called from spec/recipes/config_spec.r
b:3:in `block (2 levels) in <top (required)>')
.[DEPRECATION] `ChefSpec::Runner' is deprecated. Please use `ChefSpec::SoloRunner' or `ChefSpec::ServerRunner' instead. (called from spec/recipes/config_spec.r
b:3:in `block (2 levels) in <top (required)>')

:+1: I'd thought about doing these.

Ty!


Upgrade dependencies for v0.14.2

Updates

[x] follow-redirects>=1.15.4 (Vue app)
[x] django==3.2.24
[x] cubi-isa-templates==0.1.2

Notes
TBA

No new security issues reported, preparing release in #1861, closing this issue.


[ES6] Use import over require

Following https://github.com/callemall/material-ui/pull/2253, this PR update the src folder.

@oliviertassinari What do you think about all the indexes?

What do you think about all the indexes?

Could you be more specific?

Can't we use es6 export style for this without having to require things?

Oh, looks like I have forgotten this file.

No just this one, all the index of each folder follow this pattern

@Apercu You are right, thanks for noticing.

@oliviertassinari I don't know if webpack can prune the tree or under what conditions it can. But it would be great if it was possible. it will need research.

Yeah I was wondering about that since my material-ui is taking 40% of my project bundle loading all the svg icons while I'm only using a couple. Will do a bit of tests and can submit a PR

I have opened an issue to continue the conversation https://github.com/callemall/material-ui/issues/2558.

Yeah I was wondering about that since my material-ui is taking 40% of my project

We advise people to directly require the needed component, but that would be better if we can use the index.js (for code clarify and modifying the file name without introducing breaking changes)


Error when "corsPolicy" spec is added

Description
As per Kyma documentation here, corsPolicy is supported. However, I'm getting the following error:
strict decoding error: unknown field "spec.corsPolicy"

Expected result
'corsPolicy' spec should be supported

Actual result
Getting the error:
strict decoding error: unknown field "spec.corsPolicy"

Steps to reproduce

Use the following K8s file:

apiVersion: gateway.kyma-project.io/v1beta1
kind: APIRule
metadata:
  labels:
    app: approuter
  name: approuter
spec:
  gateway: kyma-gateway.kyma-system.svc.cluster.local
  host: vehicle-service-approuter.c7faf5c.kyma.ondemand.com
  corsPolicy:
    allowCredentials: 'true'
  rules:
    - path: /.*
      methods: ["GET", "POST", "PUT", "DELETE", "PATCH"]
      service:
        name: approuter
        port: 5000
      accessStrategies:
        - handler: noop

Getting the error:
strict decoding error: unknown field "spec.corsPolicy"

Troubleshooting

Hey @tonymathew17sap, I cannot reproduce the issue. Is the issue still relevant on your side? If so, what is the api-gateway module version you are using?

I will close the issue for now, @tonymathew17sap if you happen to come across it again, please re-open


Increase field should support decreases

It's not possible to enter negative # into the "Percent increase in positive..." fields, when you override location data

@turtlecrk: Thanks for reporting this!
I think the reason for this is that microCOVID tries not to be too optimistic and so doesn't use negative trends to project ahead and create a 'now-cast' of current COVID conditions.
See the whitepaper here:

If cases are flat or falling, it’s fine to use this number as is.

That said, perhaps there's a better way to indicate this in the UI.


Update eye-tracking.md

removing high pri loc tag

Docs Build status updates of commit 1462416:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/eye-tracking.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Make pin times sync correctly

When pin is not pressed, it should show the time but when it is, it should show X min until next bus.

Merged in 8cf273e


Add macro_use for extern crate structopt

Polonius does not compile with the latest nightly rustc:
error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
  --> src/cli.rs:27:5
   |
27 |     #[structopt(long = "graphviz_file")]
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: add #![feature(custom_attribute)] to the crate attributes to enable

Adding #[macro_use] before extern crate structopt fixes it.
See also: https://github.com/TeXitoi/structopt/issues/125

It seems adding the attribute is not needed anymore on the 2018 edition ?

Yes, it seems so


How to use LSP to complet code

I couldn't find any information about this anywhere, so I might be missing something obvious - sorry if that's the case.
I want to use LSP to implement a snippets
in lsp-sample But this is the simplest example
https://github.com/microsoft/vscode-extension-samples/blob/fbdb9c5bc40f64489db00148d7f3bf6e161d9a8c/lsp-sample/server/src/server.ts#L190
But how can I implement alternative snippets of code  like pick color ？I checked the type of  completionitem . But I didn't find any
more examples to understand what these fields mean.

Can the extension display only three red green blue colors instead of all colors when I enter color?

There are separate messages for color picking. See https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_documentColor


Moving background-sync from draft to features

Edge support version is 79, even though Chrome support is 49. I believe the discrepancy comes from Edge moving to Chromium but since webkit hasn't implemented it, so we don't have a Baseline support the discrepancy between Edge and Chrome is not meaningful.

@ddbeck tagging you as a reviewer until we get github write access I can't add you via the interface.

@tropicadri do you plan to come back to this, or would you like someone to take it over?


Incorrect Course Connection Tooltips

Note: FOR INTERNAL USE ONLY. For support questions, please use the EDA Chatter group in The Power of Us Hub.
For feature requests, please use the Ideas tab in The Power of Us Hub.

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
The description and help texts for the following fields are inaccurate.

Contact's Academic Program
Course Offering
Affiliation
Contact

What is the expected behavior?
The description and help texts for the fields listed above should be inclusive of Student and Faculty Course Connection.

What is the motivation / use case for changing the behavior?
Accurate documentation

**lurch: attach W-036779

Tracking W-036779

**lurch: detach

**lurch: attach W-037065

Tracking W-037065


error: examples/basic/deleteMeshPoints.py

AttributeError: 'Mesh' object has no attribute 'deleteCellsByPointIndex'
vedo.version is  2022.2.0

you should do:
pip install vedo -U

thanks
2022.2.3 is right


Asciidoctor PDF theme inline content error

I have a theme with the following footer:
footer:
  recto_content:
    left: '1/2'

It seems the '1/2' is being evaluated as a mathematical expression instead of being rendered as plain text as desired.
Failed to execute goal org.asciidoctor:asciidoctor-maven-plugin:1.5.3:process-asciidoc (generate-pdf) on project docs: Execution generate-pdf of goal org.asciidoctor:asciidoctor-maven-plugin:1.5.3:process-asciidoc failed: org.jruby.exceptions.RaiseException: (NoMethodError) undefined method ``include?' for 0.5:Float -> [Help 1]
I tried escaping with a backslash '1\/2' but then both slashes are rendered as text.

I found a workaround. I defined a custom document attribute, and then referred to it in the theme. Now I can have forward slashes in the pdf footer between numbers without it being evaluated as a mathematical expression.
my asciidoc:
= Document Title
:footerContent: 1/2

my theme:
footer:
  recto_content:
    left: '{footerContent}'

I believe this has since been fixed if you use the latest version of Asciidoctor PDF.
footer:
  recto:
    right:
      content: 1/2

We now explicitly bypass mathematical expressions in content values. If you still need the mathematical expression, you can use a custom theme variable:
custom_value: 1 / 2
footer:
  recto:
    right:
      content: $custom_value

However, that raises an error because we aren't coercing the content value to a string (which is actually the original bug). I'll address that issue.


disable ifd by default

also added --allow-ifd/--allow-import-from-derivation to renable ifd

tests got rate limited :thinking:

Do use the github token from the github actions runner there?
This is what nixpkgs-review would use:
  token = os.environ.get("GITHUB_OAUTH_TOKEN", os.environ.get("GITHUB_TOKEN"))

github actions exposes this via ${{ secrets.GITHUB_TOKEN }}

addressed in https://github.com/Mic92/nixpkgs-review/pull/289

bors merge

bors merge


Move to file should be returned when on part of a const or function

Bug Report

🔎 Search Terms

refactor
refactoring

🕗 Version & Regression Information
5.1.0-dev.20230509
Repo

Try running the move to file refactoring by explicitly requesting itwhen the cursor on const or function in:

const a = 1;
function foo() { }

bug
The move to file refactorings  are not returned in this case. You can only move these by selecting the entire statement: const a = 1; or function foo() { }
I'd expect:

When refactorings are automatically requested (by moving the cursor around the file) we do not return these refactorings
However when the refactorings are manually requested, we should try to expand the current selection the the nearest enclosing symbol and return a move to file refactoring for it (if it can be moved)

This may or may not be the same bug, but I noticed that Move to file and Move to new file only show up in the list of refactorings if I select the whole statement including the semicolon, e.g. |const x = 1;|. If I select everything but miss the semicolon, it doesn't show up, e.g. |const x = 1|;


feat: Upgrade RH-SSO to v7.5.1 and support kube:admin, ocp groups and proxy env

What type of PR is this?

/kind enhancement

What does this PR do / why we need it:
This PR adds the below enhancements.

Upgrades the default version of RH-SSO to 7.5.1

Adds support to login with kube:admin OpenShift User.

With this PR, RH-SSO can fetch the group details of OpenShift Users(You should see the group details of the logged in user in the Argo CD console). This will help admins define Group Level RBAC for their OpenShift groups.
NOTE: I have noticed some limitations of this feature. RHSSO v7.5.1 is only able to fetch the default groups
(groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

RHSSO works in proxy enabled/disconnected cluster with no additional or manual configuration.

Upgrades Keycloak version to 15.0.2. People who are using the Operator(with Keycloak) on their kubernetes clusters, will see a Keycloak version upgrade from 9.0.3 to 15.0.2

Upgrades
Whether you are using the Operator on Kubernetes or OpenShift, Version upgrades mentioned above are smooth and does not require any manual intervention other than upgrading the operator to new version(0.3.0) once it's released.
Have you updated the necessary documentation?

[x] Documentation update is required by this PR.
[x] Documentation has been updated.

How to test changes / Special notes to the reviewer:
Kubernetes:

Deploy the below catalog source

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: argocd-catalog
spec:
  sourceType: grpc
  image: quay.io/aveerama/argocd-operator-index@sha256:bb0db86d3e6e27fe9d9e6891027db62e3b15f2947d65b059de8c7aae3a582eda
  displayName: Argo CD Operators
  publisher: Argo CD Community

Run the make target to install the CRDs make install
kubectl create namespace argocd
kubectl create -n argocd -f deploy/operator_group.yaml
kubectl create -n argocd -f deploy/subscription.yaml
kubectl create -n argocd -f examples/argocd-keycloak-k8s.yaml

OpenShift:

Deploy the below catalog source into openshift-operators namespace.

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: argocd-catalog
spec:
  sourceType: grpc
  image: quay.io/aveerama/argocd-operator-index@sha256:bb0db86d3e6e27fe9d9e6891027db62e3b15f2947d65b059de8c7aae3a582eda
  displayName: Argo CD Operators
  publisher: Argo CD Community

Move to Operator Hub to install the Operator.
kubectl create namespace argocd
kubectl create -n argocd -f examples/argocd-keycloak-openshift.yaml

Testing upgrade:

Install the 0.2.0 of operator(same for k8s and OpenShift).
Create an Argo CD Instance with Keycloak as shown above.
Delete the operator but keep the Argo CD Instance and workloads as is.
Now, Install the new version of operator and see if the Keycloak pod is recreated and updated.

How to test login with kube:admin
On your OpenShift cluster, Go to Networking -> Routes -> Click on the Argo CD route.

Click on Login Via Keycloak -> Login with OpenShift -> Provide kubeadmin credentials.
Once you login to Argo CD, you can also confirm this by looking into the user profile section.

Please provide the following info

what does this PR add/change?
how to test/how did you test it?
any upgrade impact?
Thanks

Please provide the following info

what does this PR add/change?
how to test/how did you test it?
any upgrade impact?
Thanks

Please provide the following info

what does this PR add/change?
how to test/how did you test it?
any upgrade impact?
Thanks

Sorry, I did not realise that this PR moved from Draft to Ready state. I will add all the required including catalog source and get back to you.

@saumeya can you please test this PR and let me know how it goes ?

Please provide the following info

what does this PR add/change?
how to test/how did you test it?
any upgrade impact?
Thanks

added :)

@iam-veeramalla @wtam2018 @jopit
It seems like keycloak currently still requires users to enter information such as username, email, first and last name before they can login via kubeadmin
I think this must be an avoidable overhead for users considering dex is able to reduce login via kubeadmin to a single click event, and we are aiming to make keycloak/rhsso more appealing to users
Could we consider removing the need for this extra information input from keycloak? Let me know what you think

@iam-veeramalla @wtam2018 @jopit
It seems like keycloak currently still requires users to enter information such as username, email, first and last name before they can login via kubeadmin I think this must be an avoidable overhead for users considering dex is able to reduce login via kubeadmin to a single click event, and we are aiming to make keycloak/rhsso more appealing to users Could we consider removing the need for this extra information input from keycloak? Let me know what you think (This can be a separate PR if everyone agrees we should pursue it)

Thats a nice point.
we should be able to get rid of this. Lets take this in a different PR as it is not introduced by this and I need to check with keycloak team on how to achieve this :)

Based on my local testing, it seems like keycloak may not be recognizing custom openshift groups, it seems to only be pulling in the default openshift groups

Any chance you can add some tests to validate what was fixed?

How do you test the new support kube:admin, ocp groups and proxy env?  ( currently , "how to test" only shows how to deploy and install the operator.

@iam-veeramalla please resolve conflicts.

Done

Please provide the following info

what does this PR add/change?
how to test/how did you test it?
any upgrade impact?
Thanks

Added.

How do you test the new support kube:admin, ocp groups and proxy env? ( currently , "how to test" only shows how to deploy and install the operator.

Added steps to the PR How to Test section.

Based on my local testing, it seems like keycloak may not be recognizing custom openshift groups, it seems to only be pulling in the default openshift groups

Thanks @jaideepr97 Yes, I added that to the limitation.
I have noticed some limitations of this feature. RHSSO v7.5.1 is only able to fetch the default groups
(groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

Can you elaborate on the limitation znd add it to user documentation? What the users should know about the limiation?
NOTE: I have noticed some limitations of this feature. RHSSO v7.5.1 is only able to fetch the default groups
(groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

Can you elaborate on the limitation znd add it to user documentation? What the users should know about the limiation?
NOTE: I have noticed some limitations of this feature. RHSSO v7.5.1 is only able to fetch the default groups (groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

@wtam2018 required information is already part of the documentation. Please refer to the changes made to the docs/usage/keycloak/openshift.md file as part of this PR.
Note: Currently, group based RBAC only works with the default OpenShift groups(groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

Did you test in disconnected cluster?
@wtam I have tested it on the Proxy cluster. Wouldn't it be difficult to test on a Disconnected cluster without an IIB image ?

Any chance you can add some tests to validate what was fixed?

@wtam2018 Since most of these changes are related to login through UI, I dont think we can add any new e2e tests.

@jaideepr97 @wtam2018 updated the PR to allow openshift-v4 identity broker to fetch group details of logged in users.
which means, there is no limitation or workarounds required to set up group based RBAC.

Can you elaborate on the limitation znd add it to user documentation? What the users should know about the limiation?
NOTE: I have noticed some limitations of this feature. RHSSO v7.5.1 is only able to fetch the default groups (groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

@wtam2018 required information is already part of the documentation. Please refer to the changes made to the docs/usage/keycloak/openshift.md file as part of this PR.
Note: Currently, group based RBAC only works with the default OpenShift groups(groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

This is fixed

Can you elaborate on the limitation znd add it to user documentation? What the users should know about the limiation?
NOTE: I have noticed some limitations of this feature. RHSSO v7.5.1 is only able to fetch the default groups (groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

@wtam2018 required information is already part of the documentation. Please refer to the changes made to the docs/usage/keycloak/openshift.md file as part of this PR.
Note: Currently, group based RBAC only works with the default OpenShift groups(groups that are created at bootstrap like system:masters, system:cluster-admins, system:authenticated, system:admin .....)

This is fixed

You still have the note in your description.

Did you test in disconnected cluster?
@wtam I have tested it on the Proxy cluster. Wouldn't it be difficult to test on a Disconnected cluster without an IIB image ?

Then please don't claim that it has been tested in disconnected cluster. Proxy cluster and disconnected cluster are two different things.


nested field extraction

The documentation is not clear whether one can use nested fields (a.b.c) for the various components used in mapping. Further more when they don't work, the resulting exception can be confusing.

Available in 2.1.x and 2.2


Quickstart for ACCESS TURN RELAY is BS

This documentation is like bulls---.
First,
mkdir access-tokens-quickstart && cd relay-tokens-quickstart
What the f--- is this, 'access' and then 'relay'?????
Second,
from azure.identity import DefaultAzureCredential
And ,
pip install azure.communication.networktraversal```
It won't work.
You will need
```pip install azure.identity```

Third,
```#You can also authenticate using your connection string
identity_client = CommunicationIdentityClient.from_connection_string(self.connection_string)
relay_client = CommunicationRelayClient.from_connection_string(self.connection_string)

What the motherf---ing on earth is this 'self.'??
This is bulls---.

Like I just pull it from the air?

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

ID: 75184d05-84c4-2d8f-2cbf-026c6ba868da
Version Independent ID: 4515183d-0ad8-8961-3802-7deec49a12c7
Content: Quickstart - Access TURN relays
Content Source: articles/communication-services/quickstarts/relay-token.md
Service: azure-communication-services
GitHub Login: @shahen
Microsoft Alias: shahen

@orange2008, Thanks for the feedback! We are taking a look into this and will get back to you soon.

orange2008, Apologies for any frustrating experiencing with this.  I have assigned the issue to the content author to review further and update the doc as appropriate.

#reassign:rahulva-msft

#reassign: rahulva-msft

https://azure.microsoft.com/en-us/updates/retirement-notice-azure-communication-services-network-traversal-turn-public-preview-is-retiring/
please refer to this article.


Dependency update of test_requirements

Description
When trying to run tests you need to install the test requirements for django-2.2.
This also includes the pyenchant package, which at the current official version created an error, which is discussed here
I updated the test_requirement.txt to the current pre-release and it is working now, though it should be changed as soon as the pre-release becomes an official release.
Related resources
ImportError: The 'enchant' C library was not found. Please install it via your OS package manager, or use a pre-built binary wheel from PyPI. #164
Checklist

[x] I have opened this pull request against develop
[x] I have updated the CHANGELOG.rst
[x] I have added or modified the tests when changing logic

@MLK97 @FinalAngel this has been fixed in #6796 by pinning 3.0.1 which apparently solves the bug


Emitter callbacks with off removed incorrectly

I noticed a small bug with Emitter off implementation. It is using forward traversing and inline splice modification of the same array it is traversing. This causes element skips and if the same callback is attached twice in a row, it skips check of the latter one. Fix is to traverse the array in reverse so the array is nudged on already traveled elements.
https://github.com/Tonejs/Tone.js/blob/ed0d3b08be2b95220fffe7cce7eac32a5b77580e/Tone/core/util/Emitter.ts#L75-L79
Normally you would just have attached the same callback only once, so the bug does not appear even though element check is skipped. And it does remove multiple instances of the same callback fine if they are not attached next to each other.

thanks for the detailed bug report. Happy to accept a PR so you can get contributor credit for your find, otherwise i'll push a fix when i have a spare moment.


feat: Support operationId property

@ShogunPanda hey! Could you please review?

Sure, I can do that. But what's the reason? When I install dependecies locally, both node_modules and lock file are highlighted as untracked files

Done. Also fixed failed pipeline

Sure, I can do that. But what's the reason? When I install dependecies locally, both node_modules and lock file are highlighted as untracked files

I have it in my global .gitignore_global.

Yeah, makes sense. In general it is good practice to locally host ignores, since third-party contributors may also work with the repository. Also, the repository should have a lock file with package versions, so that all contributors and CI have consistent behavior. What do you think?

I don't like to submit lockfile as they add a lot of problems when rebasing branches. I rely on semver adoption from packages maintainers.


ktlint format throws exception

./ktlint --format "foo//*.kt" "!foo//generated/**"
Exception in thread "main" java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class org.jetbrains.kotlin.com.intellij.openapi.util.objectTree.ThrowableInterner
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at com.pinterest.ktlint.KtlintCommandLine.parallel(Main.kt:575)
at com.pinterest.ktlint.KtlintCommandLine.parallel$default(Main.kt:547)
at com.pinterest.ktlint.KtlintCommandLine.lintFiles(Main.kt:298)
at com.pinterest.ktlint.KtlintCommandLine.run(Main.kt:262)
at com.pinterest.ktlint.Main.main(Main.kt:70)
The same command without format works (shows warnings)
0.42.1 command line, MacOS

I have tried to reproduce your problem, but failed at it.  I put content below into a file with name 'Bar.kt' inside directory 'foo' and a copy of it in directory 'foo/generated'.
package foo

    val x =1000

The command ktlint --format "foo/*.kt" "!foo/generated/**" formats the file in directory 'foo' but does not modify 'foo/generated'. Can you replicate this on your machine? If this example works on your machine, the problem is most likely caused by a specific file in your directory.  Please run with option '--debug' and see whether you can identify the file that is causing the problem.

I'm getting a very similar but little different stacktrace when setting it up in /tmp.
./ktlint --format "foo/*.kt"
Exception in thread "main" java.util.concurrent.ExecutionException: java.lang.ExceptionInInitializerError
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at com.pinterest.ktlint.KtlintCommandLine.parallel(Main.kt:575)
at com.pinterest.ktlint.KtlintCommandLine.parallel$default(Main.kt:547)
at com.pinterest.ktlint.KtlintCommandLine.lintFiles(Main.kt:298)
at com.pinterest.ktlint.KtlintCommandLine.run(Main.kt:262)
at com.pinterest.ktlint.Main.main(Main.kt:70)
Caused by: java.lang.ExceptionInInitializerError
at org.jetbrains.kotlin.com.intellij.util.exception.FrequentErrorLogger.report(FrequentErrorLogger.java:46)
at org.jetbrains.kotlin.com.intellij.util.exception.FrequentErrorLogger.info(FrequentErrorLogger.java:42)
btw I downloaded it as follows, don't have it in my path, but locally in the project. Maybe that's a difference?
curl -sSLO https://github.com/pinterest/ktlint/releases/download/0.42.1/ktlint

I can only reproduce this when java16 (see below) is installed.
openjdk version "16.0.1" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-16.0.1+9 (build 16.0.1+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-16.0.1+9 (build 16.0.1+9, mixed mode, sharing)

Can you confirm that you have java16 installed as well?

Confirmed

Closing in favour of #1195


[Stepper] Migrate Stepper to emotion

[x] I have followed (at least) the PR section of the contributing guide.

One chunk of #24405

I got this in my local machine after run yarn test:unit. What's the fix?

I got this in my local machine after run yarn test:unit. What's the fix?

@siriwatknp I have never seen this issue before. Sebastian work on this test case. If you have a bit more details on the fail, we could ping him (not sure there is enough information to action it).

@siriwatknp Thanks


Missing MIME Format Path for SendMail action

The API supports sending mail using MIME format by specifying the MIME content as a base64-encoded string in the request body as shown in the example at https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0&tabs=powershell#example-4-send-a-new-message-using-mime-format:

POST https://graph.microsoft.com/v1.0/me/sendMail
Content-type: text/plain

RnJvbTogQWxleCBXaWxiZXIgPEFsZXhXQGNvbnRvc28uY29tPgpUbzogTWVnYW4gQm93ZW4gPE1l
Z2FuQkBjb250b3NvLmNvbT4KU3ViamVjdDogSW50ZXJuYWwgUmVzdW1lIFN1Ym1pc3Npb246IFNh
bGVzIEFzc29jaWF0ZQpUaHJlYWQtVG9waWM6IEludGVybmFsIFJlc3VtZSBTdWJtaXNzaW9uOiBT
YWxlcyBBc3NvY2lhdGUKVGhyZWFkLUluZGV4OiBjb2RlY29kZWNvZGVoZXJlaGVyZWhlcmUKRGF0
ZTogU3VuLCAyOCBGZWIgMjAyMSAwNzoxNTowMCArMDAwMApNZXNzYWdlLUlEOgoJPE1XSFBSMTMw
MU1CMjAwMDAwMDAwRDc2RDlDMjgyMjAwMDA5QUQ5QTlASFdIUFIxMzAxTUIwMDAwLmNvZGVudW0u
cHJvZC5vdXRsb29rLmNvbT4KQ29udGVudC1MYW5ndWFnZTogZW4tVVMKWC1NUy1IYXMtQXR0YWNo
OgpYLU1TLVRORUYtQ29ycmVsYXRvcjoKWC1NUy1Fe

This representation is currently absent in the metadata which leads to downstream tooling and SDKs not generating paths for sending mail in MIME format. Here is the current representation of the OData action in metadata:
<Action Name="sendMail" IsBound="true">
  <Parameter Name="bindingParameter" Type="graph.user" />
  <Parameter Name="Message" Type="graph.message" Nullable="false" />
  <Parameter Name="SaveToSentItems" Type="Edm.Boolean" />
</Action>

Originally reported at https://github.com/microsoftgraph/msgraph-sdk-powershell/issues/844.

Including the createReply action as well here.
https://learn.microsoft.com/en-us/graph/api/message-createreply?view=graph-rest-1.0&tabs=csharp#example-2-create-a-draft-message-in-mime-format-to-reply-to-an-existing-message
Originally reported at https://github.com/microsoftgraph/msgraph-sdk-dotnet/issues/1802


[WIP] Ats9440 driver

Should probably try to reduce code duplication
@nulinspiratie Did you have a local driver for this card too?

@jenshnielsen Yeah I do, compared them and they're nearly the same. Only thing I noticed is that for channel selection we have:
                           byte_to_value_dict={1: 'A', 2: 'B', 3: 'AB', 4:'C',
                                               5: 'AC', 6: 'BC',8:'D', 9: 'AD',
                                               10: 'BD', 12: 'CD', 15: 'ABCD'})

While in your driver the byte is linearly increasing. I can't test which one is correct, but I think it should be the one above.

@jenshnielsen close/merge/leave alone ? :)

We still have some of these cards. So hopefully I will eventually have time to come back to this


Dev/rd 34040/react native first launch fix

Can we expect a new release with this change soon?

@shzhng
This change was released in version 5.1.1. However, please note, that mostly this change was aiming to solve the issue for those who use https://www.npmjs.com/package/@segment/analytics-react-native-appsflyer
Though, we are not sure if the Segment Team has yet updated its dependency version to 5+ or not. Please feel free to check with the Segment Team regarding that.


Error showing error

julia> f(x) = sqrt(x)
f (generic function with 1 method)

julia> f(-1)
ERROR: DomainError with -1.0:
sqrt will only return a complex result if called with a complex argument. Try sqrt(Complex(x)).
Stacktrace:
 [1] throw_complex_domainerror(f::Symbol, x::Float64)
   @ Base.Math ./math.jl:33
 [2] sqrt
   @ ./math.jl:591 [inlined]
 [3] sqrt
   @ ./math.jl:1372 [inlined]
 [4] f(x::Int64)
   @ Main ./REPL[1]:1
 [5] top-level scope
   @ REPL[2]:1

julia> using ClearStacktrace

julia> f(-1)
ERROR: DomainError with -1.0:
sqrt will only return a complex result if called with a complex argument. Try sqrt(Complex(x)).
SYSTEM (REPL): showing an error caused an error
ERROR: UndefVarError: LAST_SHOWN_LINE_INFOS not defined
SYSTEM (REPL): caught exception of type UndefVarError while trying to handle a nested exception; giving up

I have no intention of doing anything with this repo anymore, after the gist got merged into Julia. You're free to fork though if you're interested in an improved version

I have no intention of doing anything with this repo anymore, after the gist got merged into Julia.

@jkrumbiegel how about adding a notice to the README explaining this (or even a repostatus.org badge)?


Add support for Base64Url primary type in generator

We haven't implemented support for Base64Url types, we simply emit them as strings.  This leads to confusion about the contents of such fields, see https://github.com/Azure/azure-rest-api-specs/pull/3286 for an example.

Looks like keyvault data-plane swaggers are the only ones affected.

Today this is generated as:
// KeyOperationsParameters - The key operations parameters.
type KeyOperationsParameters struct {
	// REQUIRED; algorithm identifier
	Algorithm *JSONWebKeyEncryptionAlgorithm `json:"alg,omitempty"`

	// REQUIRED; an unpadded, url-encoded, base-64 string
	Value []byte `json:"value,omitempty"`
}

That is a []byte now, not a string as mentioned. @jhendrixMSFT does that make this fixed, or is there something deeper I'm missing?

This is fixed in track2 and will not be backported to the previous generator.


Kaira Villanueva HW - Unit-2-HW-2

Instructions:

It is best if you use the camera in your phone

Purpose: I wanted to make this for people who are researchers or anyone interested in studying certain subjects that requires field work. So now, the researcher can walk around and take a picture with whatever they find and it will mark where they have taken the picture. If the crocodile hunter were still alive, he probably would have used this-- bless his soul.


Use standard webpack.config.js

Is it possible to use the standard webpack.config.js? I'm not sure how I'd go about doing something like merging config files for different environments (example: different loader when building for production), or using js keywords like new (example: new PluginName).

I don't know how to pass regex value in loader test property in yaml. This is the reason why I had to fork this repo.


Fix #2582: Sample data ingestion fails with Role not found error

Describe your changes :
see #2582

Type of change :

[x] Bug fix

Frontend Preview (Screenshots) :
For frontend related change, please link screenshots of your changes preview! Optional for backend related changes.

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have performed a self-review of my own.
[ ] I have tagged my reviewers below.
[ ] I have commented on my code, particularly in hard-to-understand areas.
[ ] My changes generate no new warnings.
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] All new and existing tests passed.

Reviewers

@ayush-shah this should've been caught by the tests but didn't see any test failing in our current setup.
Are we checking if the workflow is finishing without any errors?

@ayush-shah this should've been caught by the tests but didn't see any test failing in our current setup. Are we checking if the workflow is finishing without any errors?

Hey @harshach, I am not facing any errors as of now with out code in the main branch, not sure why it was failing, but I think #2554 PR might have fixed the above.

Closing this PR as the error is not being reproduced and most likely fixed.


Iron out DROAN conservative collision bugs

Think fixed by reducing disparity expansion expansion_radius as well as accurately setting robot_radius


Create Meetup/Event Small Drop Ship in Printfection

This won't be the right solution for larger events where we have a booth but will be suitable for meetups and socials.
Create a Drop Ship in Printfection that we can use whenever we host or attend a meetup.

Ideas
Will likely pick two or three of the following for a drop.

Eco-friendly socks with custom design https://www.printfection.com/swag/conscious-step-crew-socks/
Custom cut stickers https://www.printfection.com/swag/custom-cut-sticker/
Moleskin notebook https://www.printfection.com/swag/moleskine-volant-lined-large-journal-5quot-x-825quot/
Eco-friendly sun glasses (orange?) https://www.printfection.com/swag/wheat-straw-malibu-sunglasses/
Eco-friendly tote bag https://www.printfection.com/swag/recycled-cotton-convention-tote/ or https://www.printfection.com/swag/econscious-hemp-market-tote/
Sprout Pencil (not available in Printfection but have requested) https://sproutworld.com/plant-a-green-mindset-with-a-sproutpencil/
Eco-friendly (apple pulp) notebook https://www.printfection.com/swag/appeel-apple-scented-notebook-525quot-x-838quot/
Eco-friendly water bottle:

25oz https://www.printfection.com/swag/mira-cascade-bottle-25-oz/
Other options available via https://www.printfection.com/swag/category/drinkware/ or we could ask Printfection to stock Chilly's water bottles

T-shirt tri-blend: straight cut (listed as men's) and fitted (listed as women's) with brand being one of:

Next Level
BELLA+CANVAS
American Apparel

Other swag options can be found via https://www.printfection.com/swag/

I think that the socks and pencil are probably a more exciting alternative to books or water bottles -

Updates
Tote Bag
Mockup here:

This is still in the process of being mocked up/processed by Printfection so this will be ready within the next month.
Foldable Hog Origami
This hasn't finished its initial testing stage yet (aka internal company testing -thanks Joe and Paul who have given feedback). But I have begun to make some changes. I am aware that our hog style could potentially be changing so I am keen not to force this out too quickly if that is so (as the hog will be outdated pretty quickly.
You can get a sense of the design though from the pages below.


Multiple devices notification

In RNChat system is that possible to send notification for multiple logged-in devices on every new message received ?
Can you please explain this with any examples

Each device with the same user will get message that was sent to this user via chat. Explain what you mean


add travis ci for movealarm server ( spring boot project)

Add travis ci to movealarm server. #3

seem travis-ci not detect file

In order for your application as a repository in git to be detected it is necessary to create the .yam file according to the travis-ci documentation in the project root folder. Add the file in Move-Alarm_ORCA instead of add in movealarm server.

solved

solved


Updating clarity-js version and logo updates

Updating clarity version
Updating icons and logo

{

How come package-lock has so many changes?

Refers to: package-lock.json:1 in 6b19243. [](commit_id = 6b1924343bee2c116f6007607a4bd81cd498ee7a, deletion_comment = False)


ViewportTextures that are created programmatically don't work.

Godot version
3.4.2-stable
System information
Windows 10
Issue description
I've found that that new viewport textures created with ViewportTexture.new() simply don't connect to the viewports that are defined in its viewport_path parameter. The texture is shown to be black as if no viewport is attached.
Steps to reproduce
here is a code sample containing what I've tried:
onready var viewport = get_node("Viewport")

#using the existing material from "Test Mesh Instance"
onready var viewport_mat = get_node("Test Mesh Instance").get("material/0")

func _ready():

	var x = viewport_mat.albedo_texture.viewport_path
	print(x)

	#set to false if testing the current existing scene setup
	var SETUP_PROGRAMMATICALLY = true

	#basically setting up the  material>viewport_texture (that already exists in the scene) programatically
	#this doesn't work and shows the textures as being completely black despite the viewport being entirely red
	if SETUP_PROGRAMMATICALLY:

		#create new viewport texture
		var vp_texture = ViewportTexture.new()
		vp_texture.resource_local_to_scene = true

		#direct viewport texture to viewport in this scene (THIS DOES NOT WORK)
		#(i'm using the value that it is in the scene so this should work)
		vp_texture.viewport_path = x
		#other versions of the line above that do not work:
			#vp_texture.viewport_path = NodePath("Viewport")
			#vp_texture.viewport_path = viewport.get_path()
			#vp_texture.viewport_path = NodePath("root/Spatial/Viewport")
			#vp_texture.set_viewport_path_in_scene(...)
		print(vp_texture.viewport_path)

		viewport_mat.albedo_texture = vp_texture

Minimal reproduction project
Mesh Bug.zip

The ViewportTexture is more or less a "dummy" as the functionality to register proxy textures for updates is done by the Viewport Node when you call Viewport.get_texture() and the VisualServer. In Godot 4.x you can create proxy textures with GDScript code but not in Godot 3.x.  as the function(s) are not available without a custom build, see #54682.


Drop all partial indexes and replace them with full indexes

Context: Please see this slack discussion.

Such partial indexes can lead to sub-optimal query plans in unexpected ways.
For example, imagine a query like -
SELECT *
FROM metadata_v3
WHERE flow_id = ?
    AND run_id = ?
    AND step_name = ?

While we would like the query planner to choose an index scan, we will find
that query planner chooses to perform a sequential scan instead. The reason
is that the query doesn't constrain task_name to be non-null (and neither
does the table schema). Thus, from query planner's perspective the index is
effectively useless because it will not yield the full search space. These claims
are not theoretical or hypothetical, but verified. And such queries are not
artificial either but real queries constructed and executed by metaflow's
metadata and ui-backend service. At our scale (~10M rows in artifact_v3 table),
this directly led to extremely slow response times from metaflow dashboard.
With this PR, we propose to eliminate all partial indexes and replace
them with complete indexes instead. Although I would have liked to keep
everything else the same, along the way I discovered that certain indexes
specifically the one showed above incorrectly indexes the id column as
well (which is essentially a pkey column) rendering the whole index useless.
For such indexes we slightly edit them during re-creation to remove such
inefficiencies.
Caveat: For very large-scale metaflow deployments this migration might
be expensive (at our scale each index creation takes anywhere between
1-4 minutes depending upon load at the DB). I am worried that this might
cause our migrator lambda function to timeout. Looking for community's
opinion on this.
Test Plan
Locally I tested that migration works by doing
docker-compose -f docker-compose.development.yaml up migration

and verifying that it is able to successfully apply the migration.
In my organisation's metaflow deployment we've also applied this
migration in production with no observed issues so far.

Tested the migration on a fresh instance. Confirmed that it worked.
Tested the migration on an older service and it failed - likely not related to this PR.

With the feedback from testing, I'm leaning heavily towards solving this issue with the proposed full indices as well.
Sidenotes:
I had a quick stab at an alternative solution to utilizing the existing partial indices to see if a smaller fix would suffice (https://github.com/Netflix/metaflow-service/pull/363). By appending the constraint to queries where necessary, effectively nudging the query planner to use the correct index this way. There are some big drawbacks to this:

changes are non-trivial and introduce a lot of unnecessary boilerplate.
affected areas span both metadata and ui services.
forgetting to add the partian index constraints to any future query will lead to the same issue.


[GAPRINDASHVILI] Update @manageiq/ui-components to 1.0.16 for gaprindashvili

Contains:
ManageIQ/ui-components#258
ManageIQ/ui-components#265
Cc @chalettu

bz here: https://bugzilla.redhat.com/show_bug.cgi?id=1531677

@himdel are we good to merge. :+1:

@JPrause not quite... almost... almost....
:point_right: February 21, 2018 1:35 PM

@AllenBW , you can remove the WIP part.  This is good to go.  My other PR we are working on is apparently unrelated.  I tested and validated this one and it is good to go.

If good for nothing else, I sure can WIP unWIP it 😏

Looks good to me.

BZ that is resolved once this is merged: https://bugzilla.redhat.com/show_bug.cgi?id=1548562

@AllenBW can this be merged at this time?

@JPrause yeah! its assigned to @simaishi


Usersets endpoint doesn't work

It seems that the /usersets endpoint is not working, as any request to https://www.rijksmuseum.nl/api/usersets?key=key&format=json returns a 404 error

My bad, this issue is already covered by https://github.com/Rijksmuseum/api-issues/issues/1, the url needs to contain culture information.

You do have a point that it should return a 400 instead of a 404. But good that you got it working!

Hmm I was looking to change this, but on second thought it is appropriately a 404 because the culture parameter is in the URL itself, not in the querystring. So will leave it as it is.


After deleting an account and re-login, getAccounts contains no accounts anymore

Bug description
After deleting an account and re-login, getAccounts contains no accounts anymore.
Version
Which version of the library are you using?

2.0.2-alpha.11 in Firefly

Steps To reproduce the bug
Explain how the maintainer can reproduce the bug.

Have a profile with multiple accounts
Delete last account with 0 balance
Logout
Login
getAccounts binding returns [ ] even though there are some accounts left

Expected behaviour
getAccounts should return the remaining accounts
Actual behaviour
getAccounts return no accounts.

Can you provide an example to reproduce it?
I tried this
require('dotenv').config({ path: '../.env' });
const { AccountManager, CoinType } = require('@iota/wallet');

async function run() {
    try {
        const manager = await createAccountManager();

        const account = await manager.createAccount({
            alias: 'Alice',
        });
        console.log('Account created:', account);

        const secondAccount = await manager.createAccount({
            alias: 'Bob',
        });
        console.log('Account created:', secondAccount);

        await manager.removeLatestAccount();

        const accounts = await manager.getAccounts();
        console.log('Accounts', accounts);
    } catch (error) {
        console.log('Error: ', error);
    }
    process.exit(0);
}

async function createAccountManager() {
    const accountManagerOptions = {
        storagePath: './alice-database',
        clientOptions: {
            nodes: ['https://api.testnet.shimmer.network'],
            localPow: true,
        },
        coinType: CoinType.Shimmer,
        secretManager: {
            Stronghold: {
                snapshotPath: `./wallet.stronghold`,
                password: `${process.env.SH_PASSWORD}`,
            },
        },
    };

    const manager = new AccountManager(accountManagerOptions);
    await manager.storeMnemonic(process.env.MNEMONIC);
    return manager;
}

run();

and it's working. Output:
Account created: Account {
  meta: {
    index: 0,
    coinType: 4219,
    alias: 'Alice',
    publicAddresses: [ [Object] ],
    internalAddresses: [],
    addressesWithUnspentOutputs: [],
    outputs: {},
    lockedOutputs: [],
    unspentOutputs: {},
    transactions: {},
    pendingTransactions: [],
    incomingTransactions: {}
  },
  messageHandler: MessageHandler { messageHandler: [External: 52e9980] }
}
Account created: Account {
  meta: {
    index: 1,
    coinType: 4219,
    alias: 'Bob',
    publicAddresses: [ [Object] ],
    internalAddresses: [],
    addressesWithUnspentOutputs: [],
    outputs: {},
    lockedOutputs: [],
    unspentOutputs: {},
    transactions: {},
    pendingTransactions: [],
    incomingTransactions: {}
  },
  messageHandler: MessageHandler { messageHandler: [External: 52e9980] }
}
Accounts [
  Account {
    meta: {
      index: 0,
      coinType: 4219,
      alias: 'Alice',
      publicAddresses: [Array],
      internalAddresses: [],
      addressesWithUnspentOutputs: [],
      outputs: {},
      lockedOutputs: [],
      unspentOutputs: {},
      transactions: {},
      pendingTransactions: [],
      incomingTransactions: {}
    },
    messageHandler: MessageHandler { messageHandler: [External: 52e9980] }
  }
]

you need to simulate a logout -> login before manager.getAccounts().
Not sure what exactly is needed on wallet.rs side for that, but maybe
manager.destroy()
manager = new AccountManager()


"Spawn UNKNOWN" when Ctrl-Shift-F

VSCode Version: Code 1.18.0 (dcee2202709a4f223185514b9275aa4229841aa7, 2017-11-08T21:19:36.079Z)
OS Version: Windows_NT ia32 6.1.7601
Extensions: none

Steps to Reproduce:
1.Open any folder with couples of .C and .H
2.Search any word in folder by Ctrl-Shift-F
3."spawn UNKNOWN" shown in the text box and search cannot start

This is https://github.com/Microsoft/vscode/issues/37863, it's fixed in Insiders


RFC: Use np.int64 by default for CSR matrices' indices and indptr

Context
When creating a scipy.sparse.csr_matrix (for instance using a numpy array), the underlying indices and indptr arrays either use np.int32 or np.int64 depending on nnz, the number of non zeros elements (namely int64 are used when nnz >= 2**31):
https://github.com/scipy/scipy/blob/935d537feeb5ff2940f50de75bda01dd21350cb9/scipy/sparse/_sputils.py#L134-L185
This mechanism has been introduced in https://github.com/scipy/scipy/pull/442 to support np.int64 while conserving the previous implementation which was using np.int32 when possible based on discussions among maintainers. It has latter been adapted and propagated in sparse matrices' creation via other contributions, notably https://github.com/scipy/scipy/pull/3468, https://github.com/scipy/scipy/pull/4678/.
Problem
Unfortunately, some algorithms which directly work on CSR arrays necessitate typing indices and indptr. This is for instance the case of some algorithms implemented in Cython in scikit-learn.
Supporting both np.int32 and np.int64 comes with complex code adaptation (and potentially performance regressions) that downstream libraries might not want to maintain (this is the case of scikit-learn for instance).
Moreover, this restricts some algorithms working on sparse matrices in SciPy (namely scipy.sparse.csgraph's, implemented in Cython) to only work on small problems.
Ideally, the dtype of indices and indptr could be set at CSR matrices' creation, but this is not controllable by downstream libraries. The only possible control is to cast indices and indptr to use the dtype chosen by the downstream library and hence create a copy of them.
Proposed solution
The creation of SciPy CSR matrices could be changed to use int64 by default for indices and indptr while still being able to specify using int32 if needed. This would allow avoiding to copy and have a better range representation and the cost of a slightly larger memory footprint for CSR matrices for with nnz < 2**31.
Also np.uints could be used over np.uint because indices and their pointers are positive numbers. This would allow saving memory (as unsigned integers takes twice as less memory than integers) but would also corrupt serialized sparse matrices.
Past discussions in https://github.com/scipy/scipy/pull/442, https://github.com/scipy/scipy/pull/3468 and https://github.com/scipy/scipy/pull/4678/ somewhat mentioned part of the first solution, but I think making this choice might break someone's else usage of sparse matrices.
Before doing any UX and adaptation work, I think it is worth imagining potential scenarios beyond SciPy (and scikit-learn) where this solution is inadequate and I would welcome @pv, @wnbell and @rgommers's experience and expertise on sparse matrices (not required, not a urgency).
I am willing to work on a solution.
References
Relevant issues and discussions linked to this issue not exhaustively include:

[Scientific python Discourse] Scientific python and sparse arrays (scipy summary + future directions)
https://github.com/scikit-learn/scikit-learn/issues/23653
https://github.com/scipy/scipy/issues/16569

The creation of SciPy CSR matrices could be changed to use int64 by default for indices and indptr while still being able to specify using int32 if needed. This would allow avoiding to copy and have a better range representation and the cost of a slightly larger memory footprint for CSR matrices for with nnz < 2**31.

Using int64 by default, even when nnz < np.iinfo(np.int32).max seems like a performance regression (from a memory usage point of view to me).
I think it would be convenient to make to possible to pass an index dtype explicitly at sparse matrix creation time but I don't think we should change the default "automatic" logic based on actual contents.

I think it would be convenient to make to possible to pass an index dtype explicitly at sparse matrix creation time but I don't think we should change the default "automatic" logic based on actual contents.

I sorta agree with this. I think the main work to be done is removing steps which automatically downcast the array. For example:
>>> type(X), X.indptr.dtype
(scipy.sparse._csr.csr_matrix, dtype('int64'))
>>> Y = X * 1.5
>>> type(Y), Y.indptr.dtype
(scipy.sparse._csr.csr_matrix, dtype('int32'))

That the values of indices and indptrs were checked to see if they could be coerced to int32 is a performance problem.

One more wrinkle to add here. What about uints? pydata/sparse and GraphBLAS use unsigned integers for their indices and indptrs. There are upsides and downsides to this.
The most obvious upside being a doubling of addressable coordinates. One use case I've run into here is using a sparse array to store bloom filters.
The biggest downside being numpy's type promotion rules for unsigned integers being unintuitive. Though I thought I heard this might change?

I think there's two separate topics: what's the better design, and what should we actually do given backwards compatibility constraints.
Regarding the design, I agree with @jjerphan that the current behavior is problematic. I think there''s a by now well-established consensus that it's a bad idea to have output dtype depend on input values rather than input dtypes (for multiple reasons, from code complexity to predictable behavior for users to issues for a JIT compiler like Numba to support a feature).
Regarding backwards compatibility, it's less clear whether we should only add a new option or whether we should try to change the default behavior. I'm not yet convinced one way or the other. Let's see what others think. @perimosocordiae do you have an opinion on this?

I think the main work to be done is removing steps which automatically downcast the array.

Oof, that does look bad indeed.

The biggest downside being numpy's type promotion rules for unsigned integers being unintuitive. Though I thought I heard this might change?

Yes, this should improve, but that's not a fast process (see NEP 50).

I'm open to making more broad ranging changes for the new sparse array types, as the need for backward compatibility there is as yet minimal.
For sparse matrices, changing the default index dtype is more difficult. We definitely have users for which 64-bit indices would be a breaking change due to the increased RAM requirement. Removing the down casting behavior should be doable, though.

I have also been annoyed by the changing index dtype. I would favor switching to np.int64 as default, since having a fix dtype everywhere is much simpler. In my case, I use numba to construct sparse matrices and np.int64 is the default int dtype. If the matrix dimension is below 2**31, one can reasonably expect it to be lighter than a larger one which will need int64 anyway.

One more wrinkle to add here. What about uints? pydata/sparse and GraphBLAS use unsigned integers for their indices and indptrs. There are upsides and downsides to this.

That does not seem like a good idea to me. Like for dense arrays, the expectation is signed integers for indexing. Aside from it being a large break, people use negative indices like:
>>> row = np.array([0, 0, 1, 2, 2, 2])
... col = np.array([0, 2, 2, 0, 1, 2])
... data = np.array([1, 2, 3, 4, 5, 6])
... x = csr_array((data, (row, col)), shape=(3, 3))
>>> x[0, -1]
2

I think it would be convenient to make to possible to pass an index dtype explicitly at sparse matrix creation time

All the constructors like csr_matrix as well as most functions that construct matrices like sparse.block_diag already have a dtype argument. The functions that are missing it should indeed get that keyword added - that could be a first PR here.

Removing the down casting behavior should be doable, though.

That could be PR number two.

I'm open to making more broad ranging changes for the new sparse array types,

That'd be PR number three.

For sparse matrices, changing the default index dtype is more difficult. We definitely have users for which 64-bit indices would be a breaking change due to the increased RAM requirement.

Okay, so that seems to be the one hairy one. It's not easy to do a deprecation here, because we don't want to force everyone to use a dtype= argument everywhere I'd think. And a global setting doesn't have a precedent in SciPy. So it seems like this should stay as it is, unfortunately.

All the constructors like csr_matrix as well as most functions that construct matrices like sparse.block_diag already have a dtype argument. The functions that are missing it should indeed get that keyword added - that could be a first PR here.

Regarding that dtype argument, isn't that only for the underlying data array, not the index, indptr arrays? So we would need an orthogonal keyword, e.g. idx_dtype as mentioned here: https://github.com/scipy/scipy/pull/16628#discussion_r969998018

Regarding that dtype argument, isn't that only for the underlying data array, not the index, indptr arrays? So we would need an orthogonal keyword, e.g. idx_dtype as mentioned here: #16628 (comment)

@Micky774 yes, you're correct.

All the constructors like csr_matrix as well as most functions that construct matrices like sparse.block_diag already have a dtype argument. The functions that are missing it should indeed get that keyword added - that could be a first PR here.

Regarding that dtype argument, isn't that only for the underlying data array, not the index, indptr arrays? So we would need an orthogonal keyword, e.g. idx_dtype as mentioned here: #16628 (comment)

@Micky774: are you interested experimenting with exposing idx_dtype?

@Micky774: are you interested experimenting with exposing idx_dtype?

Indeed I am. I'll hopefully start on this soon

One more point on index dtypes I'd like to bring up, can the indptr a indices have different dtypes? E.g. indices_dtype and indptr_dtype?
Where I've run into the need for 64 bit values, it's typically only been on the indptr. However, the indices array will be quite large, so it would be nice to keep it 32 bit. I imagine there are cases where intptr could be kept low bitwidth, while a higher width is needed for indices.

One more point on index dtypes I'd like to bring up, can the indptr a indices have different dtypes? E.g. indices_dtype and indptr_dtype?
Where I've run into the need for 64 bit values, it's typically only been on the indptr. However, the indices array will be quite large, so it would be nice to keep it 32 bit. I imagine there are cases where intptr could be kept low bitwidth, while a higher width is needed for indices.

As it stands right now, I don't believe so, since the templated C code regarding these matrices and their operations assumes the same type for both. It shouldn't be impossible to decouple their types, but it would be a pretty comprehensive change since it is coupled throughout a bunch of code iirc.

As it stands right now, I don't believe so, since the templated C code regarding these matrices and their operations assumes the same type for both.

Yes, and supporting different types would mean generating a lot of concrete handle functions in thunk. This would in turn makes the sizes of the shared library larger, which was (and still is?) a concern based comments from @perimosocordiae, IIRC.

Currently working on a solution in: https://github.com/scipy/scipy/pull/18509
I'm starting with what I think is a fairly narrowly scoped idea.

Never downcast indices types based on values in the indices array
This is only done for array-api sparse arrays, NOT the matrix classes (e.g. no breaking changes for matrix api classes)

This is not doing anything new to resolve having different dtypes for indices and indptr. So no passing an indices dtype, no new attribute.

That does not seem like a good idea to me. Like for dense arrays, the expectation is signed integers for indexing. Aside from it being a large break, people use negative indices like:

I've also come around on this. I agree using uints here would likely have unintended consequences.

Thank you for starting this work, @ivirshup.
I think we need to keep the current behavior identical as the default one (that is preserving downcasting) and provide a way for users to specify the type of indices they want to use.
In terms of UX and UI, might this be specifiable as follows?
from scipy.sparse import csr_matrix

# X.indices and X.indptr will use the smallest bitwidth when possible.
# This would preserve the current behavior (i.e. downcast is still present to save memory
# when possible, and upcast is performed when higher precision is needed). Hence users
# delegate the management of `indices` and `indptr`'s type to SciPy.
X = csr_matrix([1., 2,, 3.])

# X.indices and X.indptr will use the specified type during the whole lifetime of X:
# Users are or can be responsible for the management of `indices` and `indptr`'s type; in this
# case SciPy would not perform any check for representability or potential integer overflow.
X = csr_matrix([1., 2., 3.], indices_dtype=np.int64)

What do you think?

Never downcast indices types based on values in the indices array

I wonder if we could preserve that as existing behavior with e.g. indices_dtype=None
It is helpful in many cases I think.

I believe the current idea from @ivirshup is to leave the spmatrix behavior unchanged, and only for sparse arrays update the get_index_dtype behavior to avoid checking the index array values and rely solely on the existing index dtype and shape information. This will result in some cases staying in 64-bit land where they technically could fit in 32 bits, but it has some important benefits: we'd no longer perform an expensive scan over the index array(s), and wouldn't trigger a copy either.

I see, I think I had misunderstood the scope of the change. So to cement my understanding, this is meant as a first-step which essentially enforces that sparse arrays "trust maxval" when calculating the index dtype right? This is separate from being able to directly specify the dtype, which is what my original comment was (incorrectly) providing feedback for.

this is meant as a first-step

Yes. I have left resolving if we can do different dtypes for different indices arrays and any additional arguments to a later PR.

enforces that sparse arrays "trust maxval"

One minor clarification here:
Arrays only look at maxval and the current index dtypes (if those are passed). E.g. if you pass in int64 row, col indices for a (3, 3) coo array, the result will have int64 row, col indices.
So really it's "no down casting of passed indices".
You can "specify" the dtype by setting the dtypes of the passed indices.

The PR is also now ready for review if you want to take a look.

With https://github.com/scipy/scipy/pull/18509 merged, now we have
from scipy import sparse
import numpy as np

coo = sparse.coo_array(
    (
        np.ones(10),
        (
            np.arange(10, dtype=np.int64),
            np.arange(10, dtype=np.int64)
        )
    )
)

coo.row.dtype
# np.int64

🎉
This was accomplished by never downcasting based on the values in the index arrays, so it's also a big performance boost for instantiation of large sparse arrays.
The behaviour for the matrix classes is unchanged.
Unresolved topics
The PR leaves a few issues discussed here unresolved
Mixed index dtype support
The PR doesn't change anything about supporting mixd types of index (e.g. having int64 indptr, int32 indices). I would really like to see this (as mentioned above: https://github.com/scipy/scipy/issues/16774#issuecomment-1276486248). I think this can have big performance impacts for:

Large csr, csc arrays, where indptr needs to be 64 bit due to the number of values stored, but indices does not (common in my field)
Sparse arrays which are very large along one dimension, so only one of indices/ row/ col needs the wider bit type

@jjerphan made a case against this here: https://github.com/scipy/scipy/issues/16774#issuecomment-1277123128

Yes, and supporting different types would mean generating a lot of concrete handle functions in thunk. This would in turn makes the sizes of the shared library larger, which was (and still is?) a concern based on comments from @perimosocordiae, IIRC.

I don't know how big of an issue this is, and would defer to @perimosocordiae on that.
Argument to set index dtype
I didn't add any argument for setting the index dtype. Right now, you "specify" the dtype by setting the dtypes of the passed indices.
Being able to set the index dtype with an argument at construction could be quite useful. Some examples where you can't control the dtype, but maybe you'd want to:
# Using the matrix defined above:
coo.tocsr()

sparse.eye(100)

Desired semantics here could intersect with mixed index dtype support.

Currently, int32 and int64 are the only types supported for indices and indices pointers:
https://github.com/scipy/scipy/blob/6c4a3f3551f9ee52a75c8c3999a57bed8ea67deb/scipy/sparse/_generate_sparsetools.py#L136-L141
If we want to support mixed index dtypes with the currently supported index types, this will double the number of concrete functions that will be generated, roughly doubling the size of the shared object (from 3.8MioB to 7.6MioB on Linux). This seems doable.

The situation is slightly worse than that: https://github.com/scipy/scipy/blob/6000091cef20f0025465d2943b0367f546a5a17b/scipy/sparse/sparsetools/csr.h#L691-L696
We have a number of C++ functions that operate on two sparse inputs, so to fully support mixed index dtypes we'd need to generate 16 different versions (all combinations of 32/64 for 4 input arrays) instead of the 2 we currently generate.
Even then I'm not sure if this would push the sparsetools shared library size to unacceptable levels, but it's worth mentioning I think.

Roughly doubling the size of the shared object (from 3.8MioB to 7.6MioB on Linux).

This would be fairly painful. scipy.sparse is already the largest submodule we have, taking (for a manylinux x86-64 wheel):

9.3 MB out of 67.6 MB for an installed release build
3.5 MB out of 22.2 MB for the scipy/ contents of a wheel
143 MB out of 695 MB for a default development build

In addition, and probably a worse impact, is on build times. The _sparsetools C++ files already take by some distance the most build time. bsr.cxx alone is the single-file bottleneck for the overall build time of a parallel build (with csr.cxx not far behind), see for example the ninjatracing graph at the top of https://labs.quansight.org/blog/2021/07/moving-scipy-to-meson.
If mixed-integer support would indeed double the build time in addition to the extension module size, as I'd expect, I think that's a no-go. If it's binary sizes alone, I think it's still painful but we can consider it.

We have a number of C++ functions that operate on two sparse inputs, so to fully support mixed index dtypes we'd need to generate 16 different versions (all combinations of 32/64 for 4 input arrays) instead of the 2 we currently generate.

That would definitely not work.

#5230 gives examples in favor of mixed index type support.

I agree with #5230. 64-bit indices are often unnecessary and cause large memory overhead.


add virDomainInterfaceAddresses

As discussed in https://github.com/rgbkrk/libvirt-go/issues/50 , here is the implementation of virDomainInterfaceAddresses.
Requires libvirt 1.2.14.
As this call is not implemented in the test and lxc drivers, and even for QEMU would require booting an OS with DHCP client, the test currently only tests that the call succeeds and returns 0 addresses.
I am preparing another PR with an alternative vagrant file that allows to run the integration tests on openSUSE Leap 42.1, that uses libvirt-<IP_ADDRESS>.

Merged #83, should we close this one for now?

Yes, IIRC the other included this one.


Allow returning an array from the parse function.

We implemented this change due to how we parse for emojis in Discord. This allows you to return an array of nodes to be appended to the result from a parser.

This looks reasonable to me, but I think I'm missing some of the context around it – is there any way i could see the emoji rule code (i've found some on discordapp.com, but it doesn't seem to return arrays; maybe it's not live?). My personal email is<EMAIL_ADDRESS>or I'm @ariabuckles on twitter if you'd like to talk in private.
I would usually recommend returning a single node from parse, and then having react return the array as output (this could potentially cause issues with react keys, however, so maybe that's what's going on?). It should also be possible to return an array from parse without this change, it just ends up nested in the react output (and is maybe less than elegant, and could have the same key issues).
Just to explain what I'm thinking with code, here's an example of what I mean by returning a single node from parse:
    emoji: {
        match: //...
        parse: (capture, parse, state) => {
            return { content: [ 1, 2, 3 ] };
        },
        react: (node, output, state) => {
            return node.content.map((elem, i) => {elem});
        },
    },

And what I mean by returning an array from parse and rendering it as a nested array in react:
    emoji: {
        match: //...
        parse: (capture, parse, state) => {
            return [
                { type: 'em', content: "1" },
                { type: 'strong', content: "2" },
                { type: 'em', content: "3" },
            ];
        },
    },

which should render as [1, 2, 3].
Otherwise this looks like a reasonable change, and I'd be happy to merge it and write some tests for it once I better understand the problem it's solving.
Aside: I notice you have several rules at the same order level as text, and I'd recommend making them a step lower than text, i.e. SimpleMarkdown.defaultRules.text.order - 0.5, so that each rule has a unique order. (Currently, they're lexicographically smaller, they'll run before text).
To solve some italics/bold issues, I was looking into having rules at the same order run at the same time and return whichever matches the longest string, but I wouldn't want to create a breaking change that's not compatible with what you have now ^_^.

Also, thanks for contributing back Discord's changes, I appreciate it 😄.

We post-process emoji parsing on Discord in that at the end of matching the final text rule converts emojis to their parsed form (because we have to avoid issues with emoji replacements happening within certain other markdown parsers, like code blocks). But to do so we recursively call parse on the capture string with emojis converted, which results in returning an array from a parse.
You are totally correct in that react itself will handle the nested array just fine, but we also use the raw parsed content tree for other uses within our app. It just made sense that we wanted to preserve a sane expectation of the parsed content tree output, which is why we ended up making this change.

Aside: I notice you have several rules at the same order level as text, and I'd recommend making them a step lower than text, i.e. SimpleMarkdown.defaultRules.text.order - 0.5, so that each rule has a unique order. (Currently, they're lexicographically smaller, they'll run before text).
To solve some italics/bold issues, I was looking into having rules at the same order run at the same time and return whichever matches the longest string ( PR #19 ), but I wouldn't want to create a breaking change that's not compatible with what you have now ^_^.

Yes, we are currently using the default lexicographic sorting but are aware how/why it works. If you made a change requiring a unique order that seems like it would be fine (it should be an easy change for us to make regardless), although it does sound a bit strange to use order alone to do this. I would imagine there being a boolean property of the rule enabling a "compete for max length" functionality rather than making that the default case. Doing this would also allow you to remain backwards compatible, since lexicographical sorting could remain.

Thanks for the detailed response! I can't say I follow all of what you're doing, but it seems pretty reasonable.
I'll merge this and add some tests (and probably change instanceof Array to Array.isArray).
Will continue the thoughts on order on PR #19 ; I think I need to think about it a bit more.

(For posterity: see efd4cd45db6be85d6d6acc2bb5237655f987c5e1 for Array.isArray and a test case)


[UseDotNet][DotNetCoreInstaller] Can't install SDK 2.2.205

Type: Bug
Enter Task Name: UseDotNet@2/DotNetCoreInstaller@1
Environment

Server - Azure Pipelines: https://dev.azure.com/warhub/wham/_build?definitionId=1

https://dev.azure.com/warhub/wham/_build/results?buildId=13
https://dev.azure.com/warhub/wham/_build/results?buildId=14
https://dev.azure.com/warhub/wham/_build/results?buildId=15

Agent - Hosted: Hosted Windows 2019 with VS2019

Issue Description
Trying to install .NET Core SDK v2.2.205. Fails, because the task inspects only the "newest" version of SDK for a given "release". Current release (v2.2.6) has the additional sdks element that contains newest sdks. This list is not inspected by the task code:
https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/UseDotNetV2/versionfetcher.ts#L148-L161
Release Metadata: https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/2.2/releases.json
Error logs
##[section]Starting: DotNetCoreInstaller
==============================================================================
Task         : .NET Core sdk/runtime installer
Description  : Acquire a specific version of the .NET Core SDK from the internet or local cache and add it to the PATH
Version      : 1.0.4
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/tool/dotnet-core-tool-installer
==============================================================================
Tool to install: .NET Core sdk version 2.2.205.
No matching sdk version could be found for specified version: 2.2.205 Kindly note the preview versions are only considered in latest version searches if Include Preview Versions checkbox is checked.
Version 2.2.205 could not be found in its channel, will now search in adjacent channels.
Searching for version in channel 2.2
No matching sdk version could be found for specified version: 2.2.205 Kindly note the preview versions are only considered in latest version searches if Include Preview Versions checkbox is checked.
Searching for version in channel 2.1
No matching sdk version could be found for specified version: 2.2.205 Kindly note the preview versions are only considered in latest version searches if Include Preview Versions checkbox is checked.
Searching for version in channel 2.0
No matching sdk version could be found for specified version: 2.2.205 Kindly note the preview versions are only considered in latest version searches if Include Preview Versions checkbox is checked.
##[error]sdk version matching: 2.2.205 could not be found
##[section]Finishing: DotNetCoreInstaller

The addition of "sdks" property in release object  is new and wasn't expected, hence the task looked in property "sdk".
We shall work on this, meanwhile can you try to use DotNetCoreInstallerV1 task for downloading the version, or you can use this scripts here (linux/windows) to get unblocked: https://github.com/dotnet/cli/tree/master/scripts/obtain

This is fixed and will start rolling out, this week. It shall reach all customers by end of next week


Fix LSPTestDiscovery tests on Windows

@award999 I can't push directly to https://github.com/swiftlang/vscode-swift/pull/1195 due to this ruleset on your PRs: https://github.com/award999/vscode-swift/rules?ref=refs%2Fheads%2Fwin-gh-actions


Include CODE_OF_CONDUCT file

I would like to add code of conduct file in your repository
@Alitindrawan24 Could you please assign me this issue?

@PragyaTripathi990 already assigned


[manifests] add $comments to features object

fixes microsoft/vcpkg#22037

Thanks for adding tests!


Feature: Add test mode support for Config PutEvaluations

Resolves #2765

Coverage increased (+0.002%) to 94.111% when pulling c3581dbd0b1287d8a0e7fe5c5dba8a64223fd159 on jrbeilke:feature-config-putevaluations into a89c150627c55d218acfb9c227e49019e3d86d7d on spulec:master.

Looks great; thanks!


[FEAT] Retrieve Data for Transaction History Implementation

Description
Fetch and display the necessary data to provide users with a comprehensive view of their transaction history. This includes deposit, transfer, withdrawal, and received transfers for each user's note account across all networks. In addition, we need to display the input and output notes used in each transaction and redirect user to view the transaction on the respective block explorer.
Screenshot

@vutuanlinh2k2 @AtelyPham please update who is working on this task if it has changed.

@drewstone I'm working on the frontend and Tin is working on the backend of this!

Created a new issue for the backend data, https://github.com/webb-tools/webb-dapp/issues/1820.

Closed in this PR


feat: mixed conditions

Closes https://github.com/chakra-ui/panda/discussions/1216
📝 Description
Add a way to create config conditions with nested at-rules/selectors
export default defaultConfig({
  conditions: {
    extend: {
      supportHover: ['@media (hover: hover) and (pointer: fine)', '&:hover'],
    },
  },
})

import { css } from '../styled-system/css'

css({
  _supportHover: {
    color: 'red',
  },
})

will generate the following CSS:
@media (hover: hover) and (pointer: fine) {
  &:hover {
    color: red;
  }
}

💣 Is this a breaking change (Yes/No):
no

We probably want to update this:


add entity classes for image model settings

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

Test Jobs
Standalone Jobs
SDK OD - https://ml.azure.com/experiments/id/d0340b2e-84b4-4891-b3ff-e00633c66df0/runs/khaki_monkey_bl2h0ptq26_HD?wsid=/subscriptions/381b38e9-9840-4719-a5a0-61d9585e1e91/resourceGroups/automlimage_eastus2_rg/providers/Microsoft.MachineLearningServices/workspaces/risha-ws-eastus2&tid=72f988bf-86f1-41af-91ab-2d7cd011db47
SDK Classification - https://ml.azure.com/experiments/id/d0340b2e-84b4-4891-b3ff-e00633c66df0/runs/sad_cheetah_rgs3j4yhtw_HD?wsid=/subscriptions/381b38e9-9840-4719-a5a0-61d9585e1e91/resourceGroups/automlimage_eastus2_rg/providers/Microsoft.MachineLearningServices/workspaces/risha-ws-eastus2&tid=72f988bf-86f1-41af-91ab-2d7cd011db47
SDK Segmentation - https://ml.azure.com/experiments/id/d0340b2e-84b4-4891-b3ff-e00633c66df0/runs/jolly_berry_86xcfbzgsg?wsid=/subscriptions/381b38e9-9840-4719-a5a0-61d9585e1e91/resourceGroups/automlimage_eastus2_rg/providers/Microsoft.MachineLearningServices/workspaces/risha-ws-eastus2&tid=72f988bf-86f1-41af-91ab-2d7cd011db47
CLI OD - WIP
CLI Classification - WIP
CLI Segmentation - WIP
Pipeline Jobs
SDK OD - https://ml.azure.com/experiments/id/59233221-a799-46ed-b3d7-aa910dc9a3ea/runs/8cadde89-60f3-4b56-a898-c39c7a886959_HD?wsid=/subscriptions/381b38e9-9840-4719-a5a0-61d9585e1e91/resourceGroups/automlimage_eastus2_rg/providers/Microsoft.MachineLearningServices/workspaces/risha-ws-eastus2&tid=72f988bf-86f1-41af-91ab-2d7cd011db47#hyperdriveChildRuns
SDK Classification -
SDK Segmentation -
CLI OD - WIP
CLI Classification - WIP
CLI Segmentation - WIP


Channels mechanism not robust to /var/run/snabb/PID already existing

Kat was just running a test and started to get bizarro segfaults doing simple things like:
./snabb-lwaftr bench \
   program/lwaftr/tests/data/icmp_on_fail.conf \
   program/lwaftr/tests/data/tcp-frominet-bound.pcap \
   program/lwaftr/tests/data/tcp-fromb4-ipv6.pcap

Unfortunately we don't know what git revision the build corresponds to because reasons.  Anyway, the snabb runs were failing with:
zsh: bus error (core dumped)  ./snabb-lwaftr bench ...

Removing the contents of /var/run/snabb "fixed" the problem.
Relatedly, we have seen exceptions on startup if the channels directory for a PID was already there.  I suspect channels somehow in this issue, as we haven't seen this failure mode in other contexts, and in this one, we got this error before we started seeing the segfaults:
apps/lwaftr/channel.lua:51: error creating file "/var/run/snabb/2876/channels/lwaftr/control": File exists

This bug, then, is to first reproduce the issue simply by running a lot of snabb check processes, until we get the error creating the file.  Then see if we can reproduce the segfault.  It's probably due to the file not being mapped correctly or something.  Then we fix.

The revision was e525074bc82627b36dcc02752fb064eab95ef911 - this was after I'd built on your code from #266 .
Possibly unrelated, possibly not, here's an intermittent error I had several snabb launches before this appeared:
Testing: from-to-b4 IPv6 packet, with hairpinning
apps/lwaftr/channel.lua:51: error creating file "/var/run/snabb/2876/channels/lwaftr/control": File exists
stack traceback:
	core/main.lua:122: in function <core/main.lua:120>
	[C]: in function 'error'
	apps/lwaftr/channel.lua:51: in function 'create_ring_buffer'
	apps/lwaftr/channel.lua:169: in function 'create'
	apps/lwaftr/lwaftr.lua:205: in function 'new'
	core/app.lua:165: in function <core/app.lua:162>
	core/app.lua:201: in function 'apply_config_actions'
	core/app.lua:110: in function 'configure'
	program/lwaftr/check/check.lua:29: in function 'run'
	program/lwaftr/lwaftr.lua:17: in function 'run'
	core/main.lua:41: in function <core/main.lua:32>
	[C]: in function 'xpcall'
	core/main.lua:151: in main chunk
	[C]: at 0x0044ff50
	[C]: in function 'pcall'
	core/startup.lua:1: in main chunk
	[C]: in function 'require'
	[string "require "core.startup""]:1: in main chunk
cmp: /tmp/endoutv4.pcap: No such file or directory
-rw-rw-r-- 1 me me 24 Feb 10 23:36 ../data/empty.pcap
ls: cannot access /tmp/endoutv4.pcap: No such file or directory
Failure: ../../../../snabb-lwaftr check ../data/no_icmp.conf ../data/empty.pcap ../data/tcp-fromb4-tob4-ipv6.pcap ../data/empty.pcap ../data/recap-ipv6.pcap

After that, I re-ran the end-to-end tests, and several ran successfully before a failure occurred. After that failure, all invocations of snabb-lwaftr that did more than show help failed, presumably with the bus error shown above.

Closing as the bug refers to an use of channels that it's no longer supported.
In v2, a channel was used to send actions to the lwAFTR data-plane via the "control" subcommand (for instance, reload-binding-table or dump-binding-table). A lwAFTR had access to a ring-buffer (channel) exposed as shared memory. The bug happened when creating a channel in the lwAFTR data-plane.
In v3, the channel code has been refactored and it's now used only for leader/follower communication. Since the data-plane no longer features a channel, this error doesn't happen anymore when running the end-to-end tests.


Refactor storage batches to use StorageBatchRequest and BatchResult

This refactors Storage batches to mimic the one in DNS. This makes use of the common BatchResult. This also fixes #364.
Now building a batch and getting the result looks like:
StorageBatch batch = storage.batch();
BlobId firstBlob = BlobId.of("bucket", "blob1"));
BlobId secondBlob = BlobId.of("bucket", "blob2"));
// Users can either register a callback
batch.delete(firstBlob).notify(new BatchResult.Callback<Boolean, StorageException>() {
  @Override
  public void success(Boolean result) {
    // deleted successfully
  }

  @Override
  public void error(StorageException exception) {
    // delete failed
  }
});
batch.update(BlobInfo.builder(secondBlob).contentType("text/plain").build());
StorageBatchResult<Blob> result = batch.get(secondBlob);
batch.submit();
// Or get the result
Blob blob = result.get(); // returns get result or throws StorageException

@Capstan I was wondering: is the limit of 100 deletes per batch call still required?
/cc @jgeewax

Coverage increased (+0.04%) to 85.78% when pulling e104bdeae19bcf419d91c655f33107ac0361bbf0 on mziccard:storage-batch into 0a6c6f703802e0c336a4158f17f178b94e74acf0 on GoogleCloudPlatform:master.

Coverage increased (+0.05%) to 85.79% when pulling 30fee0abf171e37def00c3487b6690165eff8cb0 on mziccard:storage-batch into 0a6c6f703802e0c336a4158f17f178b94e74acf0 on GoogleCloudPlatform:master.

Coverage increased (+0.04%) to 85.78% when pulling 6ceb59fc8c1ca66663a06e224ccaf8e382efe204 on mziccard:storage-batch into 0a6c6f703802e0c336a4158f17f178b94e74acf0 on GoogleCloudPlatform:master.

@mziccard The 100 deletes per batch is not a strong requirement; it is a guideline. There is a maximum size of 10MB on the batch request payload, in which you could logically fit in more deletion requests. That said, due to some current service implementation details, the service performs better if the batches are split for better distribution. There are also some current scaling implications if you do a quick QPS ramp-up by issuing many simultaneous batches in parallel, so it's better to either slow-start or limit the number of outstanding batches in flight.

@Capstan Just to make sure I understand: following a previous comment we limited the number of deletes per batch to 100, if the user adds more we split them into more batches. Are you suggesting we should limit the overall number of operations on each batch (not only deletes)? If so, could you suggest a reasonable number of operations at which it would be better to create a new batch?

@mziccard Yes, I think limiting the overall number of operations on each batch is, at the moment, useful, and for the same reasons mentioned previously. We have not done specific analysis to find out the break-even point for various types of queries. If pressed, I'd say that, in the absence of further information, I would suggest 100. Batch size is about a limitation in load balancing within the batch. The number of in-flight batches is also related to limitations in load balancing across the service… going from zero QPS to millions of (virtual) QPS in a very short span from a narrow geographic location (e.g., one single client) can result in degrade performance.

Coverage decreased (-0.03%) to 85.71% when pulling 23f4f2314d7063d37a12cab51f8155c0c6dde560 on mziccard:storage-batch into 0a6c6f703802e0c336a4158f17f178b94e74acf0 on GoogleCloudPlatform:master.

Coverage decreased (-0.02%) to 85.72% when pulling e9dbb7c3172b72784256e34f7278dcc7823bcc37 on mziccard:storage-batch into 121783ac3b346abafb5d568be794cde1c941a47c on GoogleCloudPlatform:master.