ci(): use next-gen convenience image; update npm version without sudo

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[x] CI related changes
[ ] Other... Please describe:

What is the current behavior?

The build page at circleci displays the following notice:

You’re using a deprecated Docker convenience image. Upgrade to a next-gen Docker convenience image.

Following the article we can see that the current images are no longer supported and no updates will be published.

Dec 31, 2021 - Legacy Convenience Images are no longer supported. This will be the last publishing day of these images. Existing tags will still exist on Docker Hub but will remain unchanged. There will be no support for bug or security fixes for existing tags. No new tags will be published after this day.

Issue Number: N/A
What is the new behavior?
The recommended convenience images are used and the deprecation warning is no longer displayed.
The previous image was pinned on Node.js v16.*. The new images don't support major-only version pinning and require an explicit minor version, 16.15 as of now (see github repo).
I couldn't find a list of changes between circleci/node and cimg/node, the only reference I found says it's a direct replacement.
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Note: this repository didn't run the CircleCI pipeline. It probably isn't configured?


Add rake task to reprocess failed deposits.

Rake task should set failed deposits to 'waiting' and re-process them.

Made some small tweaks:

trigger the DepositJob on the transition
run a background job for the rake task
automatically reprocess deposits stuck in working state for 24 hours


dataset preprocess

Hello, Dr Wei. Thanks for providing the source code of the KI_GAN project, which is a very valuable work for trajectory prediction. I have encountered some issues while trying to run the project code， i.e., the code stops at the read_file() function-trajectories.py . Could you please provide the source code to process the raw SIND dataset or provide me an example of the processed data?. Thank you in advance. I am looking forward to your early reply。

Hello, Dr Wei. Thanks for providing the source code of the KI_GAN project, which is a very valuable work for trajectory prediction. I have encountered some issues while trying to run the project code， i.e., the code stops at the read_file() function-trajectories.py . Could you please provide the source code to process the raw SIND dataset or provide me an example of the processed data?. Thank you in advance. I am looking forward to your early reply。

Thank you for your reminder. I will add more explanatory documents to this project in the future, and you are welcome to follow updates. Based on your request, I've updated the dataset folder to include a csv file. However, due to the copyright restrictions of the SinD dataset, which I do not have direct access to, I have only included a status id. I hope you understand.


Fix typo in Readme.md

I assume this is a typo. It says "cleaver" rather than "clever".

You are right, merged! Thanks @markgdawson!


should circuits using symbols suggest that the user implement flattening?

Would it make sense for a param resolver containing many sympy expressions to warn the user of potential slowdowns and point the user towards the flattening utilities?
Looking at @dstrain115's fix in #1899 (comment) a user can potentially improve the simulation time of circuits containing symbols by orders of magnitude using flattening utilities from study.flatten_expressions. I was unaware of this until recently, and I imagine general users may be puzzled by the slowdown incurred by (un-flattened) sympy parameterization.

Is there a reason we shouldn't just flatten for users?  User has original parameters and circuits with formulas.  We calculate new parameters where there are no formulas.  Use that for simulation or execution.  All user cares about is associating original parameters with these results, or am I missing something?

Discussed at Cirq Cynque:

there is no really a good place to warn the user about this
maybe we could introduce an analyze method that could tell whether the circuit would benefit from flattening or not
autoflattening: we have to look into this if it would actually add value/benefit  -- marking as needs-feasibility

Yea its worth checking whether flattening makes as much of a difference after #3205


Proxy: Add a failing test which replicates #763

2 websocket connections are made instead of one

 You should sign our Contributor License Agreement in order to get your pull request merged.

Ooo, nice catch. Will look into this soon, thanks!

It appears that the first connection comes from the RoundTrip of the initial request, which is needed to find out it is a websocket connection. Then we dial in as a websocket client to establish the websocket connection.
Are we doing it wrong? O.o

i'm looking into this

I'm looking into this

I found two client implementations that actually do the handshake.
github.com/gorilla/websocket Dials the connection first and then passes it to req.Write
golang.org/x/net/websocket#NewClient skips the http package and just writes everything out directly.
I'll probably look into doing what Gorilla does in the morning. This should be fixed right away, but maybe eventually using one of these client implementations would be a good idea?

It's also interesting how they set the header names to be careful about casing
I'd be fine with using gorilla. But remember, we're first an HTTP proxy -- we can't assume that all requests are websocket connections. Only the responses with the proper Upgrade header should be turned into websockets.

The main obstacle to a quick fix is that the RoundTripper interface doesn't expose the net.Conn it creates. It seems like the interface would have to change to take a Dial function and any other values needed to construct the RoundTripper.
Another possibility would be to move websocket proxying into the websocket directive, possibly with an upstream param taking ws:// and wss:// URLs, but that would be a breaking change.

@edrex We could use a type assertion to get our concrete type out of the RoundTripper if needed...

I pushed up a refactor which concretizes the type of ReverseProxy#Transport, hopefully preparing to dial manually etc. Test still fails at this point.

Hey Eric, nice work so far. Any luck bringing it full circle to make the test pass?

I tried to get something working using github.com/koding/websocketproxy, intending to pull out the needed logic once it worked, but I never got the test to pass. Sorry to drop the ball on this, just haven't had a chance to dig in and get it working. I pushed up my WIP, so if anyone wants to continue this let me know. If not I will likely come back to it in a week or two.

Nice start!! I'm not in a hurry for this, as I've still got my hands tied up with 0.9 work. The fix is definitely important but don't feel rushed. Of course I encourage other contributors to help out if they want this fix sooner than later. :+1:

Hi. :smile: Should we keep this PR open?

Feel free to close, since I haven't gotten back to it. Currently I don't have the slack to context switch. I can always request reopen :)

I'll close, since I haven't gotten back to it. Currently I don't have the slack to context switch.

Sounds good to me. Thanks!


The script debugger is totally broken after thread started from gdscript

Godot version:

Godot 3.1 compiled with 07af826051ffe5b8500e60ed1a6d53d24a1771cd
OS/device including version:

Arch Linux x64
Issue description:

The debugger client cannot send any kind of message to the remote debugger after breakpoint triggered.

Empty stack dump. No error meessage.
It do nothing with step into and step out or continue button.
Steps to reproduce:

Press F9 in script editor to set a breakpoint
Click run button in godot editor to start the debugger

Minimal reproduction project:

With debug the C++ code for both the debugger client and the remote debugger.
The remote debugger can't recive any message from the debugger client.
https://github.com/godotengine/godot/blob/68f7cf13c7326c077cc6ff8a6a267ae2610c4519/core/script_debugger_remote.cpp#L183-L192
The packet_peer_stream->get_available_packet_count() always returns 0.

Is this a recent thing? It works for me but my build is a bit old.

Multi threaded GDScript debugging is yet again kicked forward :(

Duplicate of #2446.


Delete obsolete Containers MainPage index file

Description
No occurrence of import MainPage from 'Containers/MainPage';

src/index.tsx: import AppPage from 'Containers/AppPage';
src/Containers/AppPage.tsx: import AuthenticatedRoutes from 'Containers/MainPage/AuthenticatedRoutes';
src/Containers/MainPage/AuthenticatedRoutes.tsx: import MainPage from './MainPage';

Checklist

[x] Investigated and inspected CI test results
[x] ~Unit test and regression tests added~

Testing Performed

yarn build in ui
wc build/static/js/*.chunk.js in ui

branch - master: 0 = 5999821 - 5999821 confirms that is was not referenced

Dave, did you notice delta build size from webpack 5 upgrade included in react-scripts 5 upgrade?
Although I forgot to compare before and after, here is a similar measurement from #2437

branch - master: -4300 = 10410170 - 10414470

In case there is more to lose, let’s investigate next week what is the project browserslist configuration.
https://webpack.js.org/configuration/target/

If a project has a browserslist config, then webpack will use it to determinate ES-features that may be used to generate runtime-code.

Webpack 5 opens the door to review "target": "es5" in tsconfig.json file.
https://www.typescriptlang.org/tsconfig#target

Modern browsers support all ES6 features, so ES6 is a good choice.

@dvail Thank you for the careful analysis of the upgrade, far beyond what I would have thought to do!

if we dynamically build TW class names from strings in any place in the app

Yeah, that seems likely. Finding and fixing seems like good exercise to break that habit. It will hurt us with globalization and was a subtle source of problem in search links when policies path changed.


Implementing POW expression support

This pull request implements POW expression support, unit tests and updates workspace service model builders.

We've significantly changed Ballerina execution logic. These changes are not compatible now. Hence closing the PR. Thank you for your contribution. Please send a new PR, if you have time.
I will keep this issue open.
https://github.com/ballerinalang/ballerina/issues/1243


Is there any way to send system data to all or several participant from backend?

I don't want to create additional websocket connection to send system data to users, can i use something from livekit to solve this?

yes! you can use data messages to broadcast to participants: https://docs.livekit.io/realtime/client/data-messages/


feat(side by side embedding): UI/UX Stretch Goals

Stretch

[ ] Move old panels into new side sub-panel

[ ] move cell info
[ ] move dataset info

Figma:
https://www.figma.com/design/eJ3acPxG04PKVlom6eS8ft/Spatial?node-id=0-1&t=yAWU6j6wSLKV9eIJ-0

@kaloster This ticket can be broken out from the side by side work and is unblocked if you have room to add to next sprint


kbx support ?

Does pgpainless have support for use of .kbx files down into the bouncycastle API?  I checked the sources and didn't see that.

PGPainless currently does not support GnuPG KeyBox files.
I know that Bouncy Castle has some support for it, but I have not looked into that too much, so I cannot give any guidance on how to extract keys from the kbx format.

It appears there are some tests which demonstrate how to the BCs KeyBox support.
Notably, you can extract PGPPublicKeyRing objects from the keybox as shown here.
Support for kbx files natively in PGPainless is not on my roadmap, so unless there is serious interest to have this implemented inside PGPainless, you need to do away with a wrapper that extracts PGPPublicKeyRings from the keybox file and passes them to PGPainless.


Hamburger Menu does not work on Ghost 0.7.x

Hamburger Menu button is unclickable. Tested in Chrome on Android and Chrome on Desktop.

Because Ghost 0.7.x don't provide jQuery by default... I want to prepare the update.

will be resolved in 2.5.0.


/users/login route broken when accessed via curl

The rest route /users/login from rest-accounts-password now fails when accessed via curl.  To replicate this issue you can clone the project and run the test with meteor test-packages ./packages/rest-accounts-password.  The tests pass and set up a web app that  you can test with curl.  You can successfully use the /users/register route, i.e.
curl http://localhost:3000/users/register -d "username=test1&password=test1"
{
  "token": "zNPRB8c72B8uNwdOo-8vQQ-xEPd21vq5oSDSkJJUl5q",
  "tokenExpires": "2023-01-18T09:27:33.701Z",
  "id": "CsXQfo4HFSNBAHwgS"
}

however if you try /users/login then you will see a server error
curl http://localhost:3000/users/login -d "username=test1&password=test1"
{
  "error": "internal-server-error",
  "reason": "Internal server error"
}

which wasnt there in previous versions.  Im pretty sure it fails on the options.hasOwnProperty call here: https://github.com/meteor-compat/meteor-rest/blob/3f86a467c6d86f790f4d5eeea1e4a33bf6e5d4f3/packages/rest-accounts-password/rest-login.js#L16
because the passed req data parameter object doesnt have a prototype and therefore doesnt have the hasOwnProperty function.

Hey @mattsouth loved that you have created this issue.
You think that making that snippet into:
 if (options?.hasOwnProperty('email')) {

would solve ?

That doesnt solve the problem but you can fix it if you change that line to:
     if (options.email) {

though I wonder if it might be wise to be more defensive than that though.

Published in v1.2.2


Switched to JAVA_HOME environmental variable

Changed the path to the keytool.exe from a hard link to use the JAVA_HOME Environmental variable, allowing non-default installs of Java to work with the script.
For Example: the Eclipse Adoptum install of OpenJDK installs to C:\Program Files\Eclipse Adoptium\jdk-8.0.###.#-hotspot, and has the install option to set %JAVA_HOME% to that path.

Thanka


fix Remediate Static Scan Findings

issue: https://github.com/open-cluster-management/backlog/issues/5093

/assign @qiujian16

/approve
/lgtm


ScottPlot 4 Image: GetAxisLimits() returns incorrect value fix

Hi @swharden !
Following your recommendation, here is a PR. I tested shortly, and it seems to work fine with the Image Plottable Mona Lisa...
thanks! :)
link for the issue: https://github.com/ScottPlot/ScottPlot/issues/3515

Thanks @bukkideme! I'm glad my hunch turned out to work as expected 🚀


Chore/nvm support

Support for nvm helps people like me on their first install.
It will automatically use node v12 if you are using nvm.
Updated engines to 12 because otherwise you get i.e.:
error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version ">=12". Got "10.22.0"
error Found incompatible module.

Everything works like before if you don't use nvm. It's fine.
Minor format changes on the README due to prettier-plugin. I can revert these if wanted.

Thaks for the pull request. I am using nodenv myself.
With the nvmrc file we force people to use node 12? is that a good practice? or can we somehow say something like >=12 ?

I am using nodenv myself.

Ah ok, haven't used it. How does it infer the noder version from this repo?

With the nvmrc file we force people to use node 12? is that a good practice? or can we somehow say something like >=12 ?

Most projects using nvm I know are using it to indicate the version which is being used in production/testing/project runs stable. Not necessarly the lowest or highest supported version. I.e. https://github.com/facebook/react/blob/main/.nvmrc
Using 12 indicates that in general this project should work with node anything node 12. When running nvm install latest v12 should be installed. Running only nvm use will use whatever v12 you have installed already.
nvm users can always switch to a different version or not run nvm use to keep using their global version.
Does this help?

@escapedcat sorry I forgot about this.
thanks for the explanation. I think 14 is better than 12 (12 is pretty old). The issue I have with a fixed version is that it makes it hard for people to use other versions even though other versions are supported.
I for example run node version 16.
nodenv uses a .node-version file. So it is actually pretty similar it seems.
Guess the only question is if those files should be in git?

The issue I have with a fixed version is that it makes it hard for people to use other versions even though other versions are supported. I for example run node version 16.

Got it. In my experience .nvmrc is indicating the minimum version. People using nvm are used to this. I'm not worried there anything hard to it for these people. They know they can run i.e. nvm use 16 or have set a global version.
Looking at the nvm-docs we could also use i.e.:

to default to the latest LTS version

lts/*

nodenv uses a .node-version file. So it is actually pretty similar it seems.
Guess the only question is if those files should be in git?

Yeah, I think this would be helpful for other people using nodenv.

indicating the minimum version.

ok, that sound good to me. I just dislike forcing people to use a very specific version (e.g. if having 16.11.1 installed but the version file says 16.11.0)

Added node-version as well and update general node version to indicate >=16

fyi this is how react is using it https://github.com/facebook/react/blob/main/.nvmrc

fyi this is how react is using it https://github.com/facebook/react/blob/main/.nvmrc

so also 14. - but they force a specific patch level, which I think is not so nice if not needed
thank.

If people run into any issues with this we can adjust or remove


updates 'imagePrefix' in jenkins file

Updates the 'imagePrefix' in Jenkins file

@ahsan-storm Image is available for testing. docker pull docker.io/stakater/maven-centos:3.5.4-jdk1.8-centos7-SNAPSHOT-PR-18-1


[RFC]: introduce "absolutePath" keyword for config schema validation

This PR creates a custom ajv keyword
called absolutePath which can be set to true or false depending on
whether the value must or must not be an absolute path.

@jhiode URI support is built-in: https://json-schema.org/understanding-json-schema/reference/string.html#resource-identifiers


view_labels: Change 'Direct messages' to 'All direct messages'.

This PR changes the top-navbar title from "Direct messages" to "All direct messages."
Developer documentation (apparently the only docs that mention this view by name) has also been updated to reflect this change.
CZO discussion
Screenshots and screen captures:

All DMs view, before
All DMs view, after

Dev docs, before
Dev docs, after

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Looks great, marked to merge once CI passes. The screenshots for developer documentation changes are perhaps not necessary, but I guess they're pretty fast to generate.

Looks great, marked to merge once CI passes. The screenshots for developer documentation changes are perhaps not necessary, but I guess they're pretty fast to generate.

Thanks!
The docs do generate fast, but mostly I hadn't done any in awhile and just wanted to remind myself of how that's done with the dev docs, and likewise the ReadTheDocs build in CI.


How to remove the heart/spade/clover (♥ ♠ ♣) symbols from theorems?

you need remove these symbols code from elegantbook.cls, which you can find them in the tcb math environment settings, for the latest version, please refer to the code

This is exactly what I needed, thank you :blush:, BTW, how could I change them for a little SVG image? (ie: instead of viewing a :heart:, viewing let's say Overleaf's logo).

You can search online for the question: include svg image latex.

Sorry if I didn't explain myself correctly, I know how to embed SVG files with \includegraphics, but I'm not sure if this could be done in this specific LaTeX template (I'm kind of noob with it) and what line should I change. Would it be possible to just exchange $heartsuit$ by that or do I need to do something else? Thank you so much for replying!

If I understand correctly, you can try two things:

convert svg to tikz code (for example svg2tikz), then define the tikz code as a user command \newcommand{\usrcmd}{tikz code}, then include \usrcmd in your file.
specific LaTeX template means latex pkg? you can browser the CTAN center for related pkgs which may solve your problem.

I am not familiar with svg image, and little experience with that format except converting svg img to base64 code in order to embed it in html/css, so you may find the correct answers by yourself.

Awesome, thank you :)


Meal import

Include an import instructions page with an example CSV file that folks can work from, and a list of which columns are required and which can be left blank to get the default value

GET /meals/import for instructions page
POST /meals/import to submit

Importable fields

Date/Time (required, any parseable datetime string)
Locations (required, semicolon separated, location full name)
Capacity (optional, integer)
Formula (optional, formula name)
Head Cook (optional, person full name, email, or alternate ID (prefixed with "alt:"))
Extra roles (optional)
* See community 'extra roles' setting (community.settings.meals.extra_roles)
* One column for each extra role, optional, semicolon separated, people full names

Processing

Make sure headers are found for all required fields, else error without trying to save meals (pointless). Pull header names from I18n.
Report any missing or ambiguous named entities
Save in transaction, and show parsing and validation error line numbers and messages, and ask for resubmit

Add validation to Reservation::Resource models forbidding semicolon in name field
Add validation to User models forbidding colon, semicolon, and @ in first name and last name fields

Specs:

Model

Test clean import
Test various error reports

Feature

Test happy path of upload and success
Test one error case

Originally created by Tom Smyth at 2016-09-08 02:56, migrated from redmine-#5080

Preferably this would be implemented as an interactive API endpoint so that
errors can be identified and corrected immediately.
I would also be happy if this were to support data in JSON format although
this is not required... just less potential for ambiguity.
By Willie Northway at 2017-12-11 01:00

Description updated (diff)

Estimate changed from 5.00 h to 8.00 h

By Tom Smyth at 2017-12-12 17:51

Description updated (diff)

By Tom Smyth at 2017-12-12 17:54

Description updated (diff)

By Tom Smyth at 2017-12-13 18:12

Description updated (diff)

By Tom Smyth at 2017-12-12 17:55

Description updated (diff)

Assignee set to Ijeoma Arisah

By Tom Smyth at 2018-01-30 16:32

Status changed from New to In Progress

By Ijeoma Arisah at 2018-02-05 11:50

Importer works on brute force
Needs refactoring then working out kinks for edge cases
By Ijeoma Arisah at 2018-09-26 14:50

Assignee deleted ( ~~ Ijeoma Arisah~~ )

By Tom Smyth at 2018-11-06 21:22

Update:

Time (datetime; required)
Resources (IDs or exact names; semicolon separated list; required)
Formula (ID or exact name; optional; defaults to default formula)
Communities (IDs or exact names or exact abbrvs, semicolon separated; optional; defaults to all in cluster)
Role (ID or exact name; optional)
User (ID or exact name; optional)
Role (ID or exact name; optional)
User (ID or exact name; optional)
Role (ID or exact name; optional)
User (ID or exact name; optional)
... (and so on listing out all roles for the meal)

if a row in the CSV has the exact same time and resources as an existing meal (i.e. it's very likely the same meal), it updates instead of creating new.


PhantomJS does not implement SVGAnimatedLength.

@LiamKarlMitchell writes in d3/d3#2991:
Getting an error with SVGSVGElement not having a width property implemented with PhantomJS, (I'll probably lodge an issue with them as well).
I figure it gets the width and height of the parent SVG element.
In Google Chrome the SVG node has a .width property as an instance of SVGAnimatedLength
One thing that comes to mind is that this might be used for the case of SVG inside SVG with animation/translation on them?
function defaultExtent() {
  var e = this, w, h;
  if (e instanceof SVGElement) {
    e = e.ownerSVGElement || e;
    w = e.width.baseVal.value;
    h = e.height.baseVal.value;
  } else {
    w = e.clientWidth;
    h = e.clientHeight;
  }
  return [[0, 0], [w, h]];
}

I ended up wrapping it in a try catch.
Tried to add properties to the SVGSVGElement object for width and height but it just would not use them.
  function defaultExtent() {
    var e = this, w, h;
    if (e instanceof SVGElement) {
      e = e.ownerSVGElement || e;
      try {
        w = e.width.baseVal.value;
        h = e.height.baseVal.value;
      } catch (e) {
        w = this.clientWidth;
        h = this.clientHeight;
      }
    } else {
      w = e.clientWidth;
      h = e.clientHeight;
    }
    return [[0, 0], [w, h]];
  }

Maybe not an ideal fix.

D3 is not a compatibility layer. If a platform (such as PhantomJS) does not correctly implement the standard, it’s the responsibility of the platform to fix itsself and not D3 to implement a workaround.
That said, I might be willing to make a small change if it’s not overly burdensome. Perhaps this:
function defaultExtent() {
  var e = this, w, h;
  if (e instanceof SVGElement) {
    e = e.ownerSVGElement || e;
    w = +e.getAttribute("width");
    h = +e.getAttribute("height");
  } else {
    w = e.clientWidth;
    h = e.clientHeight;
  }
  return [[0, 0], [w, h]];
}

However, I’m not sure whether this will work if width and height attributes are not specified (and left as their default value), and whether it will work if the width and height attributes are specified with units (if that’s even possible according to the specification).

An interim workaround would be for you to specify a zoom.extent explicitly (that uses clientWidth and clientHeight, or whatever) rather than relying on the default implementation for PhantomJS.

Fair enough,
Thanks for your input.

It's the same issue on Chrome Launcher. The quick fix for now works for me as well.

Closing to inactivity, plus the fact that D3 is not a compatibility layer.


Fix App title init in #79

This should fix #79 - looks like a typo. I just added a little test (there's another issue with titles I think that I wanted to check later so this might be useful), but please change if it doesn't make sense :)

Looks good, thanks!


[WIP] Gradients with the primitives

Summary
This PR adds Finite Difference/Parameter Shift/Linear Comb. of Unitaries gradients with the primitives.
Details and comments
There are 3 types of gradient methods for a sampler and estimator

[x] FiniteDiffSamplerGradient
[x] ParamShiftSamplerGradient
[x] LinCombSamplerGradient
[ ] FiniteDiffEstimatorGradient
[ ] ParamShiftEstimatorGradient
[ ] LinCombEstimatorGradient

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 614 (0.0%)  changed or added relevant lines in 12 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.8%) to 83.282%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/algorithms/gradient/estimator_gradient_result.py
0
10
0.0%

qiskit/algorithms/gradient/sampler_gradient_job.py
0
10
0.0%

qiskit/primitives/factories.py
0
12
0.0%

qiskit/algorithms/gradient/base_sampler_gradient.py
0
19
0.0%

qiskit/algorithms/gradient/base_estimator_gradient.py
0
22
0.0%

qiskit/algorithms/gradient/finite_diff_estimator_gradient.py
0
53
0.0%

qiskit/algorithms/gradient/finite_diff_sampler_gradient.py
0
58
0.0%

qiskit/algorithms/gradient/lin_comb_sampler_gradient.py
0
67
0.0%

qiskit/algorithms/gradient/lin_comb_estimator_gradient.py
0
68
0.0%

qiskit/algorithms/gradient/param_shift_estimator_gradient.py
0
69
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.8%

Covered Lines:
56311

Relevant Lines:
67615

💛  - Coveralls

I will make a new PR since this has too many commit history.


Adapter should not preload next page

I am loading Facebook native Ads and Mostly 10 at a time. So first time it's showing ad at 0 position and also preload ad position 1. and when I click on ad which is showing means at position but problem is ad at position 1 is load and it open that ad on click


Pcap as fast as possible

We are parsing PCAP files and we don't really need the time to be the same as the Velodyne, we would to parse it as fast as possible.  For this reason, we have added the HAVE_FAST_PCAP macro in this PR to disable the sleeping time whilst reading data packets.
I am also a bit concerned as the queue gets filled without any restrictions. Is this the desired behavior?. If the queue is not emptied with >> the buffer grows a lot and hogs a lot of memory. In the past I have controlled this externally with the method getQueueSize() but perhaps a more desirable solution would be to limit the size of the buffer by:

Not accepting more data packets after the buffer is full.
By popping the last element on the queue (automatically) and inserting a new one-
Maybe this is the desired behavior and do nothing.

Removed a run since it is now set to true before the thread creation since the fix of #14

I think it's good. Thanks!

Cool!
But still, what do you think about the possibility of adding a limit to the buffer?

I agree "Maybe this is the desired behavior and do nothing.".
Anyway, Let's see how it goes awhile. If there is a problem, Let's discuss that problem at that time.
Thank you for your contribution.
BTW, What do you think need to add std::move() in here?
https://github.com/UnaNancyOwen/VelodyneCapture/blob/master/VelodyneCapture.h#L509

Yes, it should. I have pushed the changes directly to master. As of the limit to the queue, i don't think it affects our case too much (we split the PCAP files to be less than 100MB) but somebody else might have problems. We'll see in the future!


Update MB record url

Updates the url for links to MB by RecordNumber
MycoBank restored this form of link today.
The restored url goes directly to the record, rather than to a search for the record.
###Manual Test

Add a ICN Registration Identifier to a Name.
On the resulting show_name page, follow the link to the MB record (it looks like [#nnnnnn] MycoBank)
Result: You land on the MycoBank record for that name.

Delivers https://www.pivotaltracker.com/story/show/175247423

Coverage remained the same at 92.633% when pulling 29f315cefce15937fb2b9080d688327d252d5853 on 175247423-MB-record-url into 0138ec81c00a832a898066c1b8cde97410db72bb on master.

This is a one-liner, simply changing a string that's the url for an MB record.


Misleading log message when forgetting to pass API Key in

When attempting to use the environment variables HONEYCOMB_API_KEY and HONEYCOMB_DATASET (using wrapModule({}, handler)  but forgetting to set them in the Workers console, rather than an error explaining this the only error given is a misleading deprecated endpoint - please upgrade logged to console (but not thrown).
Reproduction:

Install workers-honeycomb-logger normally.
Wrap a module but using wrapModule({}, handler) (normally you would pass in API Key and Dataset to the first argument but when using environment variables you shouldn't).
Forget to set in environment variables for API Key and Dataset 😆.
View the logs, where the deprecated endpoint error will be shown.

Fixed in 2d6806a142d5ac9186f168869a5da7360dff1dcc. Will release as 2.2.1 once my npm privileges are fixed :)


Are you interested in upstreaming this to rustdoc?

I haven't looked in detail how roogle currently works, but I would love for it to be the default search rustdoc uses for the standard library and docs.rs :) would you be interested in working on that if I help out with the rusrdoc-specific parts?

I think that the upstreaming is feasible if not straightforward. We need to host another dedicated API server or upgrade the existing instance. Latterly, I'll go bankrupt though.
However, I and 2 rust-dev-tools members had privately (in hindsight, we should've done this publicly) discussed this 2 months ago, and we concluded that roogle and rustdoc will be served for different purposes; roogle for multi-crate function search, and rustdoc for single-crate general search. One thing to note is that if we were to again discuss this, perhaps we'll end up with another conclusion because 2 months ago roogle was naive in some aspects.

Maybe worth opening a thread on Zulip on this?

Docs.rs has access to (more or less) all crates, it'd be interesting to try and make roogle work with something like rustdoc's json output to allow it to operate over all documentation.
This is a pretty far out idea, but still interesting to think about

it'd be interesting to try and make roogle work with something like rustdoc's json output to allow it to operate over all documentation.

Luckily enough, the index is the output of rustdoc's json backend now.
I think the most realistic approach here is that, add index and WASM of roogle to the resulting files of cargo doc.

Yah, that definitely sounds good to me. In fact, it's much easier and could still provide cross-crate searches with some sort of "add crate" functionality (that is, you select crates to add to your search pool) and the site sends across the extra indices to be searched.
Best of both worlds imo, user flexibility and light on the host server

I need some elaboration on the "add crate" feature. Is this something like users requests a crate to be added to the search index?
IIUC that's definitely nice.
By the way, roogle now partially achieves the cross-crate search so please check that out (cf. b0ff61b31bc9129f6301f0895984b9a52e074143).


I just added my name

I added my name

Hello Stephen!
Your PR is about to be merged and you will be able to see your name on this url.
Please fix the merge conflicts so that I can merge your branch into main. You can refer to the updated README.md


macros/display: allow variants with #[from] to skip writing a string in their #[error(...)] attr

all #[from] conversions come from Error implementors, so all of them implement Display for us!
when macros/display supports format strings with internal variant fields, it'll be possible to use #[from()] when `#[error("...")] has a string.

completed in e304f68. (use #[error(transparent)])


Issue 17

Aiding to address issue-17 as well formatting.

https://github.com/rahulg/treexml-rs/issues/17


The projects tab disappears when using Refined Github

The projects tab (kanban board) is not visible in Refined Github.
Referring to this -

@anvil008 This is intentional. It is removed when there are no projects. There is a link in the settings to add one. See #596 and #560.


Debugger catches breakpoint before 'for' loop completed its iterations

Godot version:

3.0.6
OS/device including version:

Windows 7 Pro SP1
Issue description:

Breakpoint was caught after one out of three 'for' loop's iterations. Expected it to be caught after all three.
Steps to reproduce:
Open Node.gd and place breakpoint at 'pass'. Run project and look at Console output.
Minimal reproduction project:

https://github.com/hilfazer/Projects/tree/master/Godot/EngineIssues/DebuggerCatchesBreakpointTooSoon

seems like fixed

seems like fixed

In which version(s)?

In which version(s)?

v3.2.1-stable debugger working as expected

Thanks, closing as fixed then.


Fixes issue #14: Unlike all controls, WebView has 'fn did_load(&self, …)' with self as non-mutable

Appreciate it!


NAS-130812 / 24.10-RC.1 / Fix core.get_jobs output (by themylogin)

Original PR: https://github.com/truenas/ixdiagnose/pull/214
Jira URL: https://ixsystems.atlassian.net/browse/NAS-130812

This PR has been merged and conversations have been locked.
If you would like to discuss more about this issue please use our forums or raise a Jira ticket.


Remove Modulefile fixture

914f35d2054591f50708912c9500351b775fe3a3 removed Modulefile support, but left in this fixture that's now unused.

Looks like the build is failing because of https://github.com/puppetlabs/pdk/issues/770 and is fixed in https://github.com/puppetlabs/puppetlabs_spec_helper/pull/295
Tested by adding
gem 'puppetlabs_spec_helper', :git => 'https://github.com/puppetlabs/puppetlabs_spec_helper.git'

to the Gemfile


ruby: build native Darwin gems using rake-compiler-dock

Please note that this is a speculative PR to solicit feedback.
Summary of changes:

add x86_64-darwin ~and arm64-darwin~ native platforms
bump dev dependency on rake-compiler-dock to ~> 1.1 and stop setting no_native on the extension task
add shared object files to the Rake CLEAN file list, and remove those files between native gem builds
use bundle exec in the RCD container

The first five commits are small prefactors or cleanup; the interesting bit is in the final commit.
Using rake-compiler-dock ("RCD") for these platforms unifies the Darwin native gem build process with the Linux native gems, which should help avoid inconsistencies in packaging that result in issues like the missing Ruby 3.0 binaries in #25060.
Please note that this change leaves the "universal-darwin" platform native gem untouched, but provides a path forward if the project ever decides to drop "universal" binary support.
Related to:

#25429
#25755
#25756

(Update 2021-04-16: Note that arm64-darwin support has been moved to a separate PR at #25992)

in issues
like #25060,

I suppose you meant o link my comment? https://github.com/grpc/grpc/issues/25060#issuecomment-804132905 (darwin packages not containing the 3.0 .bundle)

This PR now is purely additive: it adds the capability to generate x86_64-darwin and arm64-darwin native gems. The capability still exists for building the universal-darwin native gem ... err, natively ... on a Darwin system; as well as the ability for all supported platforms to compile the gem from source. The PR description has been updated with more details.

I've kicked off a package build in https://fusion2.corp.google.com/invocations/b10cd119-1278-4530-888d-5d70120ef3b3/targets - after that's done, we should be able to download the new macos packages and test.

@apolcyn The docker images grpctesting/rake_x86_64-darwin and grpctesting/rake_arm64-darwin need to be created (by push_testing_images.sh). I looked but couldn't see a place where this is automated -- is it possible that this is a manual step?
The failure messages I saw were all variations of:
Unable to find image 'grpctesting/rake_x86_64-darwin:e738cc1e6f4dd11445590a3ab81022fd70282395' locally
docker: Error response from daemon: pull access denied for grpctesting/rake_x86_64-darwin, repository does not exist or may require 'docker login'.

@apolcyn The docker images grpctesting/rake_x86_64-darwin and grpctesting/rake_arm64-darwin need to be created (by push_testing_images.sh). I looked but couldn't see a place where this is automated -- is it possible that this is a manual step?

Yes, this is a manual steo done via the tools/dockerfile/push_testing_images.sh script. One needs to have write access to the docker repo though to run that script -- I've ran it, so the docker images should be there now.
Kicked off another package build in https://fusion2.corp.google.com/invocations/b6c8f76a-6d10-4815-9f28-9ce8c5e4e5db/targets

Looks like I needed to also update templates/grpc.gemspec.template with the rake-compiler-dock dependency upgrade. I've pushed that change now.

@apolcyn Would you mind kicking CI again to see if it's green after yesterday's additional fix to the gemspec template?

I don't think the remaining failure is related (it appears to be an issue building csharp artifacts).

To update, I've tested one of the packages in https://fusion2.corp.google.com/invocations/684801ca-5bca-4ae1-90b7-8f296300ef00 manually and it looks good.
I'm prioritizing getting https://github.com/grpc/grpc/pull/25429 in first though, in order to add ruby 3.0 support without risking regression for older ruby platform support (since binary packages for older platforms isn't affected by that PR). My plan is to try to get this PR in afterwards to subsequently simply things.

Circling back on this, in general I think this looks good, and it will allow us to get rid of a lot of the pain associated with building native macos packages on macos hosts - e.g. this will allow us to eventually get rid of https://github.com/grpc/grpc/blob/c4b77ca0fe8a27a2f57567e94b81130d257bd54f/tools/distrib/build_ruby_environment_macos.sh#L1 entirely.
The main issue is just that while we are adding an arm64 macos binary package, grpc doesn't have arm testing yet. I'd like to get thoughts from @jtattermusch and @nicolasnoble about this. Also note that another possibility could be to remove the binary arm packages from this PR, but keep everything else.

@flavorjones sorry can we actually remove the addition of arm packages from this PR, and, if you'd like, open a second PR that adds arm packages so that the arm addition can be considered separately from the overall build system changes?

@apolcyn On it.

@apolcyn I've pulled out the arm64 config from this PR and rebased it onto master.
I have a second branch ready to go with a PR to add arm64 config back in whenever you're ready for it.

@flavorjones not sure if you can see the log, but the failed "Artifact build linux" package build job failed with this at the bottom of the log:
1 warning generated.
linking shared-object grpc/grpc_c.bundle
ld: illegal thread local variable reference to regular symbol __ZN4absl12lts_2021032413base_internal19thread_identity_ptrE for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile:264: grpc_c.bundle] Error 1
rake aborted!
Command failed with status (2): [/usr/bin/make...]
/usr/local/rvm/gems/ruby-2.5.8/gems/rake-compiler-1.1.1/lib/rake/extensiontask.rb:167:in `block (2 levels) in define_compile_tasks'
/usr/local/rvm/gems/ruby-2.5.8/gems/rake-compiler-1.1.1/lib/rake/extensiontask.rb:166:in `block in define_compile_tasks'
/usr/local/rvm/gems/ruby-2.5.8/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
/usr/local/rvm/gems/ruby-2.5.8/bin/ruby_executable_hooks:24:in `eval'
/usr/local/rvm/gems/ruby-2.5.8/bin/ruby_executable_hooks:24:in `<main>'
Tasks: TOP => native:x86_64-darwin => native:grpc:x86_64-darwin => tmp/x86_64-darwin/stage/src/ruby/lib/grpc/3.0/grpc_c.bundle => copy:grpc_c:x86_64-darwin:3.0.0 => tmp/x86_64-darwin/grpc_c/3.0.0/grpc_c.bundle
(See full trace by running task with --trace)
rake aborted!
 I've reproduced this in my development environment and will dig into it.

A git bisect reveals that the error we're seeing:
ld: illegal thread local variable reference to regular symbol __ZN4absl12lts_2021032413base_internal19thread_identity_ptrE for architecture x86_64

was introduced in cb9889d35d29b29de8192d1c8431f93e7dc8f5b9 related to #25841, so I'm ccing @veblush who might be able to help us understand why this is happening when we cross-compile for Darwin.

A git bisect reveals that the error we're seeing:
ld: illegal thread local variable reference to regular symbol __ZN4absl12lts_2021032413base_internal19thread_identity_ptrE for architecture x86_64

was introduced in cb9889d35d29b29de8192d1c8431f93e7dc8f5b9 related to #25841, so I'm ccing @veblush who might be able to help us understand why this is happening when we cross-compile for Darwin.

@flavorjones TLS support wasn't that great on OSX. https://github.com/grpc/grpc/pull/24479 might be helpful to investigate the TLS issue. What we've done to address it was basically setting the minimum version of OSX supporting TLS.

@veblush Thanks for the comment, but I will admit to not understanding the nature of this linker error or how to resolve it. If I un-define GPR_ABSEIL_SYNC then cross-compiling works; but other than that I honestly don't know where I would start to diagnose this or propose an alternative solution.
If anybody could provide some assistance in how you'd like me to try to resolve this problem (which is not obviously related to the point of this PR), I'd be very grateful.

@veblush @apolcyn I need help unblocking this PR. The only two options I have in my toolbox are to undefine GPR_ABSEIL_SYNC or close this PR, and I could use your help to discern a third path that would allow merging without breaking anything.
I think this PR is a long-term benefit to the project in that it improves the reproducibility of darwin native builds, and allows for a simple extension to support arm64 builds, but I simply don't know how to move it forward given the current state of the codebase.

@flavorjones I guess you can merge this if there is no test failure. https://github.com/grpc/grpc/pull/25841 was reverted for a different reason so this GPR_ABSEIL_SYNC issue shouldn't block you.

I've rebased onto master, if someone could kick off the tests to see if this is green after https://github.com/grpc/grpc/pull/26115, I'd greatly appreciate it!

I've rebased again. Would appreciate someone kicking CI, please.

@apolcyn CI is green, would you mind taking a look at the changes here and approving?

I'm waiting for a CI issue to be resolved so that I can kick off another full package build

@apolcyn It's been a couple of weeks, I was wondering if you were still planning on merging this?

Ok, I've kicked off another full package build with this PR in https://fusion2.corp.google.com/invocations/a3e39570-3262-48f0-aeec-5d0ec2922f46

Hi @flavorjones, can you please merge the latest master branch into your pull request branch and re-push?
The full package builds based off of your branch have been failing with:
++ KEYSERVER_IPV4_ADDRESS=
++ gpg --keyserver hkp:// --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
gpg: could not parse keyserver URL

... which is an error that's been fixed on the head of the master branch.
Sorry for the slowness in this review

@apolcyn :+1: I've rebased! Thanks again for your time.

@apolcyn I've updated this PR to work with templates/src/ruby/ext/grpc/extconf.rb.template which should fix the failures I was able to see from the previous run.

I've rebased again. I'd be thankful if @apolcyn or @jtattermusch would kick CI.

Looks like the linux artifact build now creates the grpc-1.41.0.dev-x86_64-darwin.gem:
https://console.cloud.google.com/storage/browser/grpc-testing-kokoro-prod/test_result_public/prod/grpc/core/pull_request/linux/grpc_build_artifacts/27493/20210910-024653
The grpc-1.41.0.dev-universal-darwin.gem built on by the macos/grpc_build_artifacts is still being built.
@apolcyn since the tests are looking good, do you want to do the final review of this PR?


Aligned links is not worked in bootstrap v4-alpha v4

"Aligned links" is vague. Please clarify what feature you're referring to.

Closing until we hear any clarification.


hydrogen-react: Cart currency does not update after changing countryIsoCode of ShopifyProvider

What is the location of your example repository?
No response
Which package or tool is having this issue?
Hydrogen
What version of that package or tool are you using?
<EMAIL_ADDRESS>What version of Remix are you using?
No response
Steps to Reproduce
I'm using hydrogen-react to manage a storefront that has multiple currencies setup. The app is wrapped like so:
<ShopifyProvider
  storeDomain={
    'https://' + process.env.SHOPIFY_STORE_ID + '.myshopify.com'
  }
  storefrontToken={process.env.SHOPIFY_STOREFRONT_API_TOKEN}
  storefrontApiVersion={process.env.SHOPIFY_STOREFRONT_API_VERSION}
  countryIsoCode={router.locale.toUpperCase()} // 👈 countryIsoCode is set dynamically when user selects a different currency
  languageIsoCode="EN"
>
  <CartProvider cartFragment={cartFragment}>
    // Rest of the app...
  </CartProvider cartFragment={cartFragment}>
</ShopifyProvider>

Starting with countryIsoCode="SE", I'm following these steps:
1. I add an item to the cart and cartCreate gets called to create a cart with country: SE
Request:
{
	"query": `
		mutation CartCreate(
			$input: CartInput!
			$numCartLines: Int = 250
			$country: CountryCode = ZZ
		) @inContext(country: $country) {
			cartCreate(input: $input) {
			cart {
				...CartFragment
			}
			}
		}

		fragment CartFragment on Cart {
			id
			checkoutUrl
			totalQuantity
			buyerIdentity {
			countryCode
			customer {
				id
				email
				firstName
				lastName
				displayName
			}
			email
			phone
			}
			lines(first: $numCartLines) {
			edges {
				node {
				id
				quantity
				attributes {
					key
					value
				}
				cost {
					totalAmount {
					amount
					currencyCode
					}
					subtotalAmount {
					amount
					currencyCode
					}
					compareAtAmountPerQuantity {
					amount
					currencyCode
					}
				}
				merchandise {
					... on ProductVariant {
					id
					availableForSale
					compareAtPrice {
						...MoneyFragment
					}
					price {
						...MoneyFragment
					}
					requiresShipping
					title
					image {
						...ImageFragment
					}
					product {
						handle
						title
						id
					}
					selectedOptions {
						name
						value
					}
					}
				}
				}
			}
			}
			cost {
			subtotalAmount {
				...MoneyFragment
			}
			totalAmount {
				...MoneyFragment
			}
			totalDutyAmount {
				...MoneyFragment
			}
			totalTaxAmount {
				...MoneyFragment
			}
			}
			note
			attributes {
			key
			value
			}
			discountCodes {
			code
			applicable
			}
		}

		fragment MoneyFragment on MoneyV2 {
			currencyCode
			amount
		}
		fragment ImageFragment on Image {
			id
			url
			altText
			width
			height
		}
	`,
	"variables": {
		"input": {
			"lines": [{ "merchandiseId": "gid://shopify/ProductVariant/42757387387068", "quantity": 1 }],
			"buyerIdentity": { "countryCode": "SE" }
		},
		"country": "SE"
	}
}

Response:
{
    "data": {
        "cartCreate": {
            "cart": {
                "id": "gid://shopify/Cart/c1-a3671628a918268f5bd2afb59f6fc29f",
                "checkoutUrl": "https://elvstroem.myshopify.com/cart/c/c1-a3671628a918268f5bd2afb59f6fc29f",
                "totalQuantity": 1,
                "buyerIdentity": {
                    "countryCode": "SE",
                    "customer": null,
                    "email": null,
                    "phone": null
                },
                "lines": {
                    "edges": [
                        {
                            "node": {
                                "id": "gid://shopify/CartLine/e6ad395e-0823-423d-9c1f-98db07e4ba4a?cart=c1-a3671628a918268f5bd2afb59f6fc29f",
                                "quantity": 1,
                                "attributes": [],
                                "cost": {
                                    "totalAmount": {
                                        "amount": "1175.0",
                                        "currencyCode": "SEK"
                                    },
                                    "subtotalAmount": {
                                        "amount": "1175.0",
                                        "currencyCode": "SEK"
                                    },
                                    "compareAtAmountPerQuantity": null
                                },
                                "merchandise": {
                                    "id": "gid://shopify/ProductVariant/42757387387068",
                                    "availableForSale": true,
                                    "compareAtPrice": null,
                                    "price": {
                                        "currencyCode": "SEK",
                                        "amount": "1175.0"
                                    },
                                    "requiresShipping": true,
                                    "title": "Navy / Large",
                                    "image": {
                                        "id": "gid://shopify/ProductImage/35671878107324",
                                        "url": "https://cdn.shopify.com/s/files/1/0626/4504/3388/files/COPENHAGEN67-12212301-NAVY_1.jpg?v=1693499120",
                                        "altText": null,
                                        "width": 2400,
                                        "height": 3000
                                    },
                                    "product": {
                                        "handle": "copenhagen-67",
                                        "title": "Copenhagen 67",
                                        "id": "gid://shopify/Product/7910661292220"
                                    },
                                    "selectedOptions": [
                                        {
                                            "name": "Color",
                                            "value": "Navy"
                                        },
                                        {
                                            "name": "Size",
                                            "value": "Large"
                                        }
                                    ]
                                }
                            }
                        }
                    ]
                },
                "cost": {
                    "subtotalAmount": {
                        "currencyCode": "SEK",
                        "amount": "1175.0"
                    },
                    "totalAmount": {
                        "currencyCode": "SEK",
                        "amount": "1175.0"
                    },
                    "totalDutyAmount": null,
                    "totalTaxAmount": null
                },
                "note": null,
                "attributes": [],
                "discountCodes": []
            }
        }
    },
    "extensions": {
        "context": {
            "country": "SE",
            "language": "EN"
        }
    }
}

I change countryIsoCode from "SE" to "DK", so cartBuyerIdentityUpdate gets called to update the cart with country: DK
Request:
{
	"query": `
		mutation CartBuyerIdentityUpdate(
			$cartId: ID!
			$buyerIdentity: CartBuyerIdentityInput!
			$numCartLines: Int = 250
			$country: CountryCode = ZZ
		) @inContext(country: $country) {
			cartBuyerIdentityUpdate(cartId: $cartId, buyerIdentity: $buyerIdentity) {
			cart {
				...CartFragment
			}
			}
		}

		fragment CartFragment on Cart {
			id
			checkoutUrl
			totalQuantity
			buyerIdentity {
			countryCode
			customer {
				id
				email
				firstName
				lastName
				displayName
			}
			email
			phone
			}
			lines(first: $numCartLines) {
			edges {
				node {
				id
				quantity
				attributes {
					key
					value
				}
				cost {
					totalAmount {
					amount
					currencyCode
					}
					subtotalAmount {
					amount
					currencyCode
					}
					compareAtAmountPerQuantity {
					amount
					currencyCode
					}
				}
				merchandise {
					... on ProductVariant {
					id
					availableForSale
					compareAtPrice {
						...MoneyFragment
					}
					price {
						...MoneyFragment
					}
					requiresShipping
					title
					image {
						...ImageFragment
					}
					product {
						handle
						title
						id
					}
					selectedOptions {
						name
						value
					}
					}
				}
				}
			}
			}
			cost {
			subtotalAmount {
				...MoneyFragment
			}
			totalAmount {
				...MoneyFragment
			}
			totalDutyAmount {
				...MoneyFragment
			}
			totalTaxAmount {
				...MoneyFragment
			}
			}
			note
			attributes {
			key
			value
			}
			discountCodes {
			code
			applicable
			}
		}

		fragment MoneyFragment on MoneyV2 {
			currencyCode
			amount
		}
		fragment ImageFragment on Image {
			id
			url
			altText
			width
			height
		}
	`,
	"variables": {
		"cartId": "gid://shopify/Cart/c1-a3671628a918268f5bd2afb59f6fc29f",
		"buyerIdentity": { "countryCode": "DK" },
		"country": "DK"
	}
}

Response:
{
    "data": {
        "cartBuyerIdentityUpdate": {
            "cart": {
                "id": "gid://shopify/Cart/c1-a3671628a918268f5bd2afb59f6fc29f",
                "checkoutUrl": "https://elvstroem.myshopify.com/cart/c/c1-a3671628a918268f5bd2afb59f6fc29f",
                "totalQuantity": 1,
                "buyerIdentity": {
                    "countryCode": "DK",
                    "customer": null,
                    "email": null,
                    "phone": null
                },
                "lines": {
                    "edges": [
                        {
                            "node": {
                                "id": "gid://shopify/CartLine/e6ad395e-0823-423d-9c1f-98db07e4ba4a?cart=c1-a3671628a918268f5bd2afb59f6fc29f",
                                "quantity": 1,
                                "attributes": [],
                                "cost": {
                                    "totalAmount": {
                                        "amount": "1141.0",
                                        "currencyCode": "SEK"
                                    },
                                    "subtotalAmount": {
                                        "amount": "1141.0",
                                        "currencyCode": "SEK"
                                    },
                                    "compareAtAmountPerQuantity": null
                                },
                                "merchandise": {
                                    "id": "gid://shopify/ProductVariant/42757387387068",
                                    "availableForSale": true,
                                    "compareAtPrice": null,
                                    "price": {
                                        "currencyCode": "DKK",
                                        "amount": "700.0"
                                    },
                                    "requiresShipping": true,
                                    "title": "Navy / Large",
                                    "image": {
                                        "id": "gid://shopify/ProductImage/35671878107324",
                                        "url": "https://cdn.shopify.com/s/files/1/0626/4504/3388/files/COPENHAGEN67-12212301-NAVY_1.jpg?v=1693499120",
                                        "altText": null,
                                        "width": 2400,
                                        "height": 3000
                                    },
                                    "product": {
                                        "handle": "copenhagen-67",
                                        "title": "Copenhagen 67",
                                        "id": "gid://shopify/Product/7910661292220"
                                    },
                                    "selectedOptions": [
                                        {
                                            "name": "Color",
                                            "value": "Navy"
                                        },
                                        {
                                            "name": "Size",
                                            "value": "Large"
                                        }
                                    ]
                                }
                            }
                        }
                    ]
                },
                "cost": {
                    "subtotalAmount": {
                        "currencyCode": "SEK",
                        "amount": "1141.0"
                    },
                    "totalAmount": {
                        "currencyCode": "SEK",
                        "amount": "1141.0"
                    },
                    "totalDutyAmount": null,
                    "totalTaxAmount": null
                },
                "note": "",
                "attributes": [],
                "discountCodes": []
            }
        }
    },
    "extensions": {
        "context": {
            "country": "DK",
            "language": "EN"
        }
    }
}

Expected Behavior
After calling cartBuyerIdentityUpdate with a new country, I would expect the cart to display all line items and totals/subtotals in the currency of the new country.
Actual Behavior
The cart displays all line items and totals/subtotals in the currency with which the cart was originally created.

I am not using Hydrogen, but its the same issue using the graphql API (using Nuxt3 with the Shopify Graphql API).. This is an API issue I am pretty sure.

I am not using Hydrogen, but its the same issue using the graphql API (using Nuxt3 with the Shopify Graphql API).. This is an API issue I am pretty sure.

The bug can be reproduced on the demo store without any change:

Go here : https://hydrogen.shop/
Add anything to the cart
Change the locale to another country with a different currency
Go to the cart. The prices are displayed in the original currency and doesn't match the current locale.

Any multi-currency store is affected.

Can confirm, same thing happening with our store, this is having a huge impact on all multi-currency stores.

Can confirm, same thing happening with our store, this is having a huge impact on all multi-currency stores.

I see that it now works for your demo. But it still doesn't work for us (haven't changed anything in the codebase). Please see here: https://contrebande.co

@contrebande-labs I've added an item to cart and switching between the available currencies and I am seeing the prices are changing to the expected currencies for the product list and cart items using the link you have provided

@wizardlyhel @contrebande-labs can confirm that the issue is still impacting sessions that were set during this window, so the only way to get those working is to clear the cart cookie, new sessions were indeed fixed though.

@wizardlyhel @contrebande-labs  Can You guys share any github code or process how this currency changing demo store was developed in hydrogen?
Specially I really like this one https://contrebande.co/ . Can you guys help me by sharing this"?


Provide CLI flag to continue interactive REPL usage after processing standard input

Kuzu CLI can read Cypher commands from standard input, but REPL closes after execution. It would be nice to optionally continue in interactive REPL mode after this script has been executed. This would help with interactive testing, Kuzu experimentation  and database pre-initialization in more complex cases.
So, what about -i, which is the name of the equivalent Python CLI flag? Like
kuzu -i /path/to/db < init_script.schema

This looks doable to me. We can put this into our roadmap, though i'm not sure who might pick it up. Thanks for the suggestion.

Cool. One thing forgotten: Input direction in above  kuzu -i /path/to/db < init_script.schema already blocks standard input, so  terminal REPL cannot use it anymore. What Python CLI does is to pass the schema or script file as command line argument (or -c), not via standard input:
python -i myscript.py

Carried over to kuzu:
kuzu path/to/db -i -f myscript.py
# or via keyword db argument for extensibility
kuzu -d path/to/db -i -f myscript.py


Project: SharePoint Page toolkit

Project name
SPPage toolkit
Description
About
SPPage toolkit is an simple toolset for basic CRUD operations for SharePoint site pages.
Type of app?
Solution is built on .NET MAUI, since the subject was new to me (only a tiny bit of WPF knowledge prior) and cross platform possiblities are always exiting.
Built on Graph Beta endpoint, since Pages is still in beta as of 3/2023.
What does it do?
It allows the user to:

Search for a SharePoint site with given term
List all the pages that are inside that site
Gives possibilities to create, update and delete pages as needed

What problem does it solve?
You know the feeling when you're solving a client issue and for each demo, test or repro, you create a new site page? And they keep cluttering up your sitepages list?
So do I.
But quite rarely, since my dev tenant is a graveyard of sitepages.
So this toolkit was created to easily manage your site pages, and click away pages that are no longer needed, or to create a bunch of new ones or to even rename that silly old Dog named page to a Cat page!
Repo URL
https://github.com/tarzzi/msoft-hack-together-2023
Team members
Tarzzi

Thank you for your submission @tarzzi! Would you be willing to record a short video to demonstrate the app? It's not required for the hackathon but it would help us showcase your work internally at Microsoft and publicly in the community 😊

Of course, will do! 😊 Is youtube fine or are there any preferences? @waldekmastykarz

YouTube, here or in the repo, anything will work. Thank you!

Demo available at repo! 📺


Running into an issue for parsing a really long string.

In the following situation:
        println!("input: {}", input);
        let val = match BigFloat::parse(input) {
            Some(s) => s,
            None => return None,
        };
        println!("val: {}", val.to_string());

The following are being treated as though they are identical:
input:<PHONE_NUMBER>00000000000000000000000000000000000.00000000000000000000000000000000000000001
val: 1.000000000000000000000000000000000000000e+39
input:<PHONE_NUMBER>00000000000000000000000000000000000.00000000000000000000000000000000000000002
val: 1.000000000000000000000000000000000000000e+39
When I compare them using .cmp() it returns 0.

Actually here it is more succinctly:
fn main() {
    let input1 = "100000000000000000000000000000000000000000000.00000000000000000000000000000000000000002";
    let input2 = "100000000000000000000000000000000000000000000.00000000000000000000000000000000000000001";

    let bigfloat1 = BigFloat::parse(input1).unwrap();
    let bigfloat2 = BigFloat::parse(input2).unwrap();

    println!("The comparison value of these is: {}", bigfloat1.cmp(&bigfloat2).unwrap())
}

output:
$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target\debug\decimal.exe`
The comparison value of these is: 0

BigFloat in num-bigfloat can only provide precision of 40 decimal digits. For greater precision you can take a look at astro-float.

Ah okay, thanks for pointing me there.


SET MEMORY in a .ferret file causes lots of error messages.

Reported by ansley b manke on 19 May 2009 17:25 UTC
Reported 5/19/2009 Serena Illig
http://www.pmel.noaa.gov/maillists/tmap/ferret_users/fu_2009/msg00291.html
If the Ferret init file .ferret contains
message/continue **************
set memory/size=30

Then starting Ferret causes many repetitions of
message/continue **************
**************
set memory/size=30
 Cached data cleared from memory
GO "$HOME/.ferret"
message/continue **************
**************

finally ending in
**ERROR: $HOME/.ferret: Network is unreachable
GO "$HOME/.ferret"
Command file, command group, or REPEAT execution aborted

The SET MEM command has worked, and Ferret can continue.
yes? show memory
 Current size of FERRET memory cache: 30 MegaWords  (1 word = 4 bytes)

This behavior seems to go back to at least Ferret v5.22 (07/27/00)  How on earth did this not come up before??!  It looks to be in ferret_c.c, routine command_line_run, in the code for "ferret -script".
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1662

Comment by ansley.b.manke on 20 May 2009 16:03 UTC
Fixed in command_line_run, in ferret_c.c

Comment by ansley.b.manke on 20 May 2009 16:17 UTC
Note: I also added a test of .ferret startup files to the Ferret benchmarks.  The file sets memory, MODE nlevels, renames the journal file name and metafile name, and a couple of graphics modes and runs a few Ferret tests.


Add loading modal during bulk operations

Towards: #2975
What's Changed

TODO

[ ] Explanation of Change(s)
[ ] Added change log fragment(s) (for more information see the documentation)
[ ] Attached Screenshots, Payload Example
[ ] Unit, Integration Tests
[ ] Documentation Updates (when adding/changing features)
[ ] Example Plugin Updates (when adding/changing features)
[ ] Outline Remaining Work, Constraints from Design

This is a part of https://github.com/nautobot/nautobot/issues/2459

If you go to /dcim/device-types/import/ and enter no data you get a constantly spinning modal:

Can this also be added to generic/object_bulk_import.html? DeviceType is the only model that uses object_import.html for its bulk import page.

Yeah I think DeviceType import does not need a loading modal either cause it is only single object. The problem of a constantly spinning modal still remains for CSV file import hmm

Can this also be added to generic/object_bulk_create.html? DeviceType is the only model that uses object_import.html for its bulk import page.

Yeah I think DeviceType import does not need a loading modal either cause it is only single object. The problem of a constantly spinning modal still remains for CSV file import hmm


Documentation not up-to-date

Overall great job so far. But please revise your documentation. For example the following code sniped with FirebaseTableViewDataSource in swift:
self.dataSource = FirebaseTableViewDataSource(ref: firebaseRef cellClass: YourCustomClass.self cellReuseIdentifier: @"<YOUR-REUSE-IDENTIFIER>" view: self.tableView)

self.dataSource.populateCellWithBlock { (cell: YourCustomClass, obj: NSObject) -> Void in
  // Populate cell as you see fit, like as below
  cell.yourCustomLabel.text = snap.key;
}

self.tableView.dataSource = self.dataSource;

There are some mistakes in this code...

Parameters are separated with commas in swift ( FirebaseTableViewDataSource(...) )
Swift not using @ for strings (Objective C stuff...)
Initialization of the variable "snap" is missing
Semicolons not necessary in swift
...

Valid swift code could look like this:
self.dataSource = FirebaseTableViewDataSource(ref: firebaseRef, cellClass: YourCustomClass.self, cellReuseIdentifier: "<YOUR-REUSE-IDENTIFIER>", view: self.tableView)

self.dataSource.populateCellWithBlock { (cell: YourCustomClass, obj: NSObject) -> Void in
  let snap = obj as! FDataSnapshot
  // Populate cell as you see fit, like as below
  cell.yourCustomLabel.text = snap.key
}

self.tableView.dataSource = self.dataSource

...But nevertheless, this code doesn't work

Looks like all the swift documentation is incorrect.

Yes it's all out of which :cry: . I'll be working on this soon, so sit tight.

Cool, thanks for your reply. Looking forward for your alterations!

Hi @davideast do you have a timeline for these updates? The above code simply doesn't work anymore and it would be great to actually use this.

I am currently new to iOS and have been learning swift only. I am unable to find any documentation on how to use the FirebaseUI. I have managed to install it but completely stuck on how to even use this. The manual method of calling methods on the firebase website seems to be more properly documented and user friendly for a swift dev. Can you either provide a sample/steps if possible on how the firebaseUI should help me ! Thanks

Hi .. did anyone manage to get this snippet work? Xcode is giving error on this line. I can't reference it to my custom class
self.dataSource.populateCellWithBlock { (cell: YourCustomClass, obj: NSObject) -> Void in
Thanks!

@Blankarsch I've just merged a PR updating all these readme docs (#98); if you still have trouble with this feel free to reopen this.


p8b pinetime-mcuboot-app-dfu-1.9.0.zip gatt error 133 in recovery

Can't connect via nrf connect (two different phones) or linux getting gatt error 133 or
[CHG] Device XX:XX:XX:XX:XX:XX Connected: yes
Failed to connect: org.bluez.Error.Failed
I think LFRC doesn't get calibrated properly.

Are you able to connect to the watch and list its services using NRF Connect, or does the connection end immediately?

No connection using using NRF Connect. Connection attempt takes 14s and ends with 133, turned off/on phone and blue tooth.
Opened watches so I can investigate.

Okay, thanks for the test. The LF clock calibration should work, but there might be an issue with the binaries on GitHub. I'll recompile from the new branch (a lot of refactoring is currently taking place in order to upstream P8 support into the official InfiNitime source code, see https://github.com/InfiniTimeOrg/InfiniTime/pulls?q=is%3Apr+author%3AStarGate01 ).

I've seen a similar problem with P8b FW on my P8(a) watch that HAS LF.
@LoriLori you should use P8a FW if it works. Bootloader features should
save you in case of the non-working FW.

Please note that on LF crystal builds, the recovery uses the LF crystal as well. In theory, the LFRC builds should run on devices which have a crystal just as well, but I have seen the contention issues @ildar is describing.
I will be updating the device names to MOY-*, to hopefully reduce confusion on what firmware to use.

Sorry, I can't test. Opening a watch I caused damage.


Add artifacts to CI

The CI should produce artifacts with all of the log files so that it's easier to debug when something fails.
https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts

#192 Is the first step toward having meaningful artifacts.  It only does log file artifacts for the fasm2bels environment setup.


[Vehicle] Update the enum list of vehicleType attribute

According to the datamodel's documentation, the vehicleType attribute allows values defined by VehicleTypeEnum a  DATEX 2 version 2.3.
But not all the vehicle types in DATEX 2 version 2.3 are allowed on vehicleType attribute. Only a subset is allowed. This is even enforced in the schema.json. For instance twoWheeledVehicle (a simple scooter, i believe) is not there.
So, im asking to update this.
I volunteer do work on this and issue a pull request, if there's an agreement in the update of such list.

Im closing this issue in favor of this one.


Fix SCARS wiki page to remove SHARI and update the commands etc

Fix SCARS wiki page to remove SHARI and update the commands etc

done


Ctrl + Click not Working

Issue Type: Bug
Ctrl + Click for Go To Navigation is not working. Also, on selection of a variable/entity I cannot find the go to definition option as well.
VS Code version: Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523, 2020-12-16T16:34:46.910Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-8350U CPU @ 1.70GHz (8 x 1896)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onprotected_video_decode: enabledrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.84GB (6.47GB free)

Process Argv
--crash-reporter-id 0c538646-0e1c-4d40-a811-53943707891c

Screen Reader
no

VM
0%

Extensions (7)

Extension
Author (truncated)
Version

beautify
Hoo
1.5.0

java
red
0.73.0

vscodeintellicode
Vis
1.2.10

vscode-java-debug
vsc
0.30.0

vscode-java-dependency
vsc
0.16.0

vscode-java-pack
vsc
0.12.1

vscode-maven
vsc
0.27.0

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
openlogontheside:30221877
python763:30178808
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
python504:30227505
vswsl492cf:30211402
wsl2prompt:30224612
pythonvsdeb440cf:30237828
unusedpromptcf:30224611
folderexplorercf:30224615
openfilemenu:30224647
pythonvsded773:30236629

/needsMoreInfo
Could you provide more info about workspace configuration and what is language of the file where you are trying to use Go to...?

/needsMoreInfo
Could you provide more info about workspace configuration and what is language of the file where you are trying to use Go to...?

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!


FLAKE: Kokoro - cloud_to_prod_auth:default:php7:oauth2_auth_token

Might be similar to https://github.com/grpc/grpc/issues/11967 and https://github.com/grpc/grpc/issues/11995, but this test failed with an Unknown status
Call did not complete successfully. Status object:
object(stdClass)#197 (3) {
  ["metadata"]=>
  array(0) {
  }
  ["code"]=>
  int(2)
  ["details"]=>
  string(0) ""
}

2017-07-28 17:47:29,422 FAILED: cloud_to_prod_auth:default:php7:oauth2_auth_token [ret=1, pid=22735]

Dupe of #10763


Should we keep the Inject/Extract extension methods for formats?

Analogous to known tags ( #18 ), we currently also have ITracer extension methods for the built-in formats.
Examples:
public static void InjectTextMap(this ITracer tracer, ISpanContext spanContext, IDictionary<string, string> data)
{
    tracer.Inject(spanContext, Formats.TextMap, new DictionaryCarrier(data));
}

public static ISpanContext ExtractTextMap(this ITracer tracer, IDictionary<string, string> data)
{
    return tracer.Extract(Formats.TextMap, new DictionaryCarrier(data));
}

// usage

var data = new Dictionary<string, string>();

tracer.InjectTextMap(existingSpanContext, data);

var extractedSpanContext = tracer.InjectTextMap(data);

The main advantages are:

Users can pass the actual object instead of having to manually wrap it in a carrier

This means, they don't need to know/search for the wrapper types

People who write their own formats/carrier types can also create their own extension methods so they will show up in the same IntelliSense tooltip.

Are you ok with this or do you see any concerns?
/cc @bensigelman @dawallin @yurishkuro

I don't have a strong opinion on these. I do have misgivings in general about overloading the lib with helper functions, and from the past experience with C# I remember that extension methods are a bit hard to follow when reading the code as they are often imported inconspicuously.

I can see advantages here, but my personal opinion is that any convenience functions should be kept out of the OT layer until there's a clear pattern/problem emerging in actual production calling code. My two cents.

Extension methods have been removed with #26 - thank you for your feedback!


Allow defining persistent command options in pyproject.toml

I’m wishing for a way to specify persistent options for uv commands in pyproject.toml.
This is a generalized solution to issues such as #5737.
Example
[tool.uv.options]
venv = [ "--relocatable" ]
pip = { install = [ "--offline", "--no-build-isolation" ] }

Invoking uv venv would then implicitly pass the option  --relocatable.
Perhaps it could print a message to let the user know that options were collected from pyproject.toml to respect the principle of least astonishment.

Thinking out loud…
How would this feature handle options that take arguments (such as --find-links) or options that could be used multiple times (such as -e/--editable)?

I feel like it'd probably be better to just provide these as configuration options, e.g. tool.uv.pip.offline or tool.uv.venv.relocatable. Why set this per-command using CLI flags?

I think it comes down to style and ease of maintenance.
The kv pair approach is verbose. The array approach seems tidier to me and uses fewer lines of TOML.
Setting it per command is mostly for flexibility and consistency. Would you rather make this work for all commands (both current and future) or have to manually maintain config options?

Basically, yeah I think we'd rather maintain an explicit configuration schema that applies for all commands or follows a clear hierarchy for sections of commands (as with uv.pip) rather than have a way to dynamically inject untyped arguments in front of commands — it's more aligned with the user experience we typically deliver.
I see the benefits of your suggestion though.


Twig 3

Hi,
I'm not sure how do go about this, but I've upgraded Pico 3 alpha to use Twig 3 would you be interested in the patch?

See #535. You can check whether you incorporated any other changes, feel free to open a pull request then. Thank you! :+1:


chore(RingTheory/TensorProduct/Basic): relax the condition of Subalgebra.finite_sup to CommSemiring

I missed that when I was submitting #12025.

Thanks!
bors merge


Several address handling fixes

Now copying pretty account address to clipboard instead of plain
Removed spaces before and after the address in account details
Now saving contact addresses as plain and therefore preventing creation of duplicate contacts
Always display pretty contact addresses instead of saved one

@cryptoBeliever told me that most exchanges don't work with pretty addresses (with hyphens), so I guess the first point (Now copying pretty account address to clipboard instead of plain) should not be done.

@cryptoBeliever told me that most exchanges don't work with pretty addresses (with hyphens), so I guess the first point (Now copying pretty account address to clipboard instead of plain) should not be done.

@cryptoBeliever told me that most exchanges don't work with pretty addresses (with hyphens), so I guess the first point (Now copying pretty account address to clipboard instead of plain) should not be done.
On the other hand we do work with pretty addresses (for good reasons!). So users could get the pretty addresses from other places (if they don't use the copy-button) and then they still have this problem with the exchange... It could be extra confusing if they sometimes get the pretty address and sometimes the plain address.

The pretty format is for displaying only. All address operation should be plain. Buth 'pretty' helps when 2 addresses come with similar strings. Personally I would prefer showing pretty (with copying the plain format). It is the same as NIS1 nano wallet.
@cryptoBeliever @bassemmagdy @AdriaCarrera ?

@cryptoBeliever told me that most exchanges don't work with pretty addresses (with hyphens), so I guess the first point (Now copying pretty account address to clipboard instead of plain) should not be done.
On the other hand we do work with pretty addresses (for good reasons!). So users could get the pretty addresses from other places (if they don't use the copy-button) and then they still have this problem with the exchange... It could be extra confusing if they sometimes get the pretty address and sometimes the plain address.

The pretty format is for displaying only. All address operation should be plain. Buth 'pretty' helps when 2 addresses come with similar strings. Personally I would prefer showing pretty (with copying the plain format). It is the same as NIS1 nano wallet.
@cryptoBeliever @bassemmagdy @AdriaCarrera ?

@cryptoBeliever told me that most exchanges don't work with pretty addresses (with hyphens), so I guess the first point (Now copying pretty account address to clipboard instead of plain) should not be done.
On the other hand we do work with pretty addresses (for good reasons!). So users could get the pretty addresses from other places (if they don't use the copy-button) and then they still have this problem with the exchange... It could be extra confusing if they sometimes get the pretty address and sometimes the plain address.

The pretty format is for displaying only. All address operations should be plain. But 'pretty' help when 2 addresses come with similar strings. Personally, I would prefer showing pretty (with copying the plain format). It is the same as NIS1 nano wallet.
@cryptoBeliever @bassemmagdy @AdriaCarrera ?

@rg911 yes showing pretty and copying plain format is fine for me. In NIS1 it work in this way (if user using copy button)

@cryptoBeliever told me that most exchanges don't work with pretty addresses (with hyphens), so I guess the first point (Now copying pretty account address to clipboard instead of plain) should not be done.
On the other hand we do work with pretty addresses (for good reasons!). So users could get the pretty addresses from other places (if they don't use the copy-button) and then they still have this problem with the exchange... It could be extra confusing if they sometimes get the pretty address and sometimes the plain address.

The pretty format is for displaying only. All address operations should be plain. But 'pretty' help when 2 addresses come with similar strings. Personally, I would prefer showing pretty (with copying the plain format). It is the same as NIS1 nano wallet.
@cryptoBeliever @bassemmagdy @AdriaCarrera ?

@rg911 yes showing pretty and copying plain format is fine for me. In NIS1 it work in this way (if user using copy button)

Alright, you convinced me.

Alright, you convinced me.

@myxmaster  any chance you could have a look at the conflicts?

Conflicts resolved


[MB-6926] Update node to 12.21.0 to match version in docker image

Description
Our docker container currently installs the latest version of node 12.x as part of its setup.  That's version 12.21.0 at the time of this writing.  However, the local version we have in .node-version is 12.16.3 and appears to have been that way since we introduced nodenv to manage our node versions locally.  In addition, we appear to use 12.16.3 in some GitHub actions and in pre-commit too.  This PR attempts to sync all the versions up (at least for now).
For a future PR, we may want to consider pinning our image to a specific node version similar to what we do for golang versions.  That way, we always can be in sync (in theory), but that does mean we have to manually ensure our containers are updated with new versions (and new node releases happen quite often).  I don't think dependabot can help us with this as it currently stands because node is brought into the image via curl.  But this PR at least fixes the sync issue for now.
Reviewer Notes
Just try some node-related things out (building, running the client, running pre-commit checks, etc.) and make sure you don't see any obvious problems.  The containers have been running with 12.21.0, so hopefully it's not a big leap to make the change in the other places.
Setup
You'll need to install node 12.21.0:
nodenv install 12.21.0
Once you've done that, check that the node version used when in your repo's directory is 12.21.0:
nodenv version (to show current version)
nodenv versions (to show all versions with current version noted)
If you run into problems doing something with pre-commit (like a pre-commit run -a), then you may want to try clearing out your pre-commit cache (should be in ~/.cache/pre-commit) and then installing hooks again (pre-commit install-hooks).
Code Review Verification Steps

[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change

Messages

:book:
:link: MB-6926

  Generated by :no_entry_sign: dangerJS against d0b00de8daae89e4ca889710ddc63f20905efc16


ng-particles: Cannot find module 'tsparticles' or its corresponding type declarations.

Which version are you using?
ng-particles: 2.12.2
tsparticles: 1.29.2

Is the latest version affected?

[x] Yes
[ ] No

Which library are you using?

[x] Vanilla JS (tsparticles)
[x] Angular (ng-particles)

Describe the bug
The problem exists when compiling an Angular application that uses ng-particles and tsparticles without "skipLibCheck": true in the tsconfig.json.
The error is:
Error: node_modules/ng-particles/lib/ng-particles.component.d.ts:2:38 - error TS2307: Cannot find module 'tsparticles' or its corresponding type declarations.

2 import type { Container, Main } from 'tsparticles';
                                       ~~~~~~~~~~~~~

Error: node_modules/ng-particles/lib/ng-particles.module.d.ts:1:37 - error TS2307: Cannot find module 'tsparticles' or its corresponding type declarations.

1 import type { ISourceOptions } from 'tsparticles';
                                      ~~~~~~~~~~~~~

Error: node_modules/ng-particles/lib/ng-particles.module.d.ts:9:15 - error TS2307: Cannot find module 'tsparticles' or its corresponding type declarations.

9 export * from 'tsparticles';
                ~~~~~~~~~~~~~

With ng-particles: 2.12.2 and  tsparticles: 1.27.0 the problem does not exist, but I would like to update my application to the newest version. Furthermore setting "skipLibCheck": true in the tsconfig.json does solve it as well (but I don't think this is a good solution). Maybe it's related to https://github.com/matteobruni/tsparticles/issues/1472?

Hi @j0nm1,
The other issue was fixed, it was an error in the react component type definition.
What is your TypeScript version? I had some issues with TypeScript <=4.0 and I’m working on a fix that will be out soon (I don’t know how soon yet)

Hi, thanks for the quick reply. I'm using typescript: 4.0.8

Ok that’s the issue, there are broken types definitions for TypeScript <4.1, you can try with 1.29.0, this version should work, the 1.29.2 has some changes that didn’t work as expected

Downgrading to version 1.29.0 did not work. But after updating typescript to 4.1.6 it works with 1.29.2.
For me, the problem is resolved with this solution. Thank you!

Thank you @j0nm1 for the test, I’ll investigate more about that before releasing an update


Migrate to Kotlin DSL

Upgraded to latest versions similar to PR https://github.com/google-developer-training/basic-android-kotlin-compose-training-juice-tracker/pull/17


toplology.cu is slow to compile

As it says in title. In particular on Juwels it takes more than 30 mins with
module load CUDA/11.0
module load GCC/9.3.0
module load OpenMPI/4.1.0rc1
module load CMake/3.18.0
I will update with a more precise time whenever it finishes compiling.

This is solved by using a CUDA version >= 11.4.


polymer init is not working please help me

D:\3rd>polymer init
'uname' is not recognized as an internal or external command,
operable program or batch file.
? Which starter template would you like to use? shop
info:    Running template shop...
info:    Downloading latest release of Polymer/shop
error:   Could not download release from Polymer/shop
error:   Uncaught exception: unable to verify the first certificate
error:   Error: # unable to verify the first certificate
at __dirname.sendError (C:\Users\karan\AppData\Roaming\npm\node_modules\polymer-cli\node_modules\github\lib\index.js:780:19)
at C:\Users\karan\AppData\Roaming\npm\node_modules\polymer-cli\node_modules\github\lib\index.js:789:29
at callCallback (C:\Users\karan\AppData\Roaming\npm\node_modules\polymer-cli\node_modules\github\lib\index.js:665:17)
at ClientRequest. (C:\Users\karan\AppData\Roaming\npm\node_modules\polymer-cli\node_modules\github\lib\index.js:737:17)
at emitOne (events.js:96:13)
at ClientRequest.emit (events.js:188:7)
at TLSSocket.socketErrorListener (_http_client.js:308:9)
at emitOne (events.js:96:13)
at TLSSocket.emit (events.js:188:7)
at emitErrorNT (net.js:1272:8)

Please ask such questions on the Polymer Slack (https://polymer-slack.herokuapp.com/) or on Stackoverflow (http://stackoverflow.com/questions/tagged/polymer)

This issue was moved to Polymer/polymer-cli#450


Prioritize ignored paths when linting

As discussed in #1124
A common workflow is running oxlint automatically via something like lint-staged, which passes all changed file paths explicitly as CLI arguments. The ignore crate auto-whitelists explicit paths, overriding anything defined in an ignore file, leading to files that should be ignored causing CI and VC hooks to fail.
eslint avoids this issue by giving precedence to .eslintignore unless you pass --no-ignore.
Since ignore doesn't really give much control over this, the most effective solution seems to be filtering. Once we've got a list of files to be linted, we can compare each against the .eslintignore and see if it really truly should be linted.
Unfortunately, this is sort of a naive solution. Ignored directories will still be walked, then filtered out after the fact. Changing this behavior at the walker level would affect the formatter, which probably isn't desirable. (edit: The performance impact has been mostly resolved.)

I like the overall direction of this PR, it's just that eslint + lint-staged caused so much configuration confusion and wasted time for people, I have a feeling first-class support (via a cli flag) will be better than some random combinations of configuration options.
What do you think?

You're right that this introduces a performance regression, it definitely does. In most cases, the paths will be iterated a second time, filtered, and re-Veced. I think the pathological case might be overstated, though. For the overhead to be truly significant, the user would have to have passed a parent path to a significant number of ignored paths. Think something like oxlint node_modules/. This could be avoided by pushing the ignore filtering up into Walk, probably.
Adding the check for explicit paths is an easy win, though. I'll definitely do that, which should avoid the overhead for the common case.

...eslint + lint-staged caused so much configuration confusion and wasted time for people, I have a feeling first-class support (via a cli flag) will be better than some random combinations of configuration options.

The confusion is definitely real, and ultimately I'd really defer to your judgement. My preference would be to stick with this direction and not implement git-specific logic. For what it's worth, this behavior (.{tool}ignore file taking precedence over provided paths) is how most of the common tools in this corner of the world (git, eslint, prettier) work.

Shall we try the following logic:
for each provided path,
if the path is a file (not a directory)
check against ignore logic

FYI oxlint is designed to lint huge monorepos, with 10,000+ files being the norm.

I've approximated the requested logic, I think. Notably, it is now possible to pre-filter all paths, skipping linting altogether.
There's an outstanding question of user feedback. At no point during this process is the user informed that paths or filtered. eslint yields linter warnings, which doesn't seem perfect, but better than silence.

Thank you!

There's an outstanding question of user feedback. At no point during this process is the user informed that paths or filtered. eslint yields linter warnings, which doesn't seem perfect, but better than silence.

We can have another issue / PR for this.


Add german translations

Just hooking into your PR adding some german translations

superseded by https://github.com/ryangjchandler/filament-navigation/pull/35


Add a "Streamer Mode" hiding sensible information

This mode should hide the host from the bottom-left box in the UI and from the message logged when connecting.

Do you think we should hide player names in Hints tab as well ?

Added in #88


Vagrant build cleanup

Added an option to select the branch to be built
Limit the git clone to depth of 3
cleaned up package list for ubuntu14

@timburrow , you mentioned there's a box available for testing.  Would you be interested to get this stuff setup for nightly (or even better: pull-request) builds?
What it does:

creates vagrant "box" templates for the supported OSs
for each build, clones the box, then downloads and runs the build in the VM

Both centos6 and trusty tahr are working, havent tried centos7 yet.
The install doesn't work yet, but it's close.

Just cleaned up the commit history on this and added Xenial.

Thanks for fast response, sir.
I'm having hard time figuring out how to install JDK 6 which is an old version.
Do you know any link that leads to a page explaining how to install JDK 6 on Ubuntu?

Is there a reason you're commenting on this merge request?
Are you trying to use the Vagrant builds on the development branch?  It would be better if you would open a new ticket with more information about the error you're getting.