Azure IIoT Platform version switches during runtime

Describe the bug
I've deployed on the 17th of April the Azure IIoT Platform using the deployment script, following the description from here It started up with version 2.7.11.
After a few days when I visited the page in the header it said 2.7.14 and also the layout of the navigation pane has changed.
And also till this date it's kind of random which version waits for me when I visit the page.
To Reproduce
Steps to reproduce the behavior:

Deployt the Azure IIot Platform according to the description frmo here
Visit the Engineering Tool home page of the application
The version number is sometimes 2.7.11 and sometimes it's 2.7.14

Expected behavior
I would expect that the version stays stable, if version 2.7.11 was deployed it should stay that way, or if there's a possibility to do on the fly updates I should get somehow notified.
Screenshots
With version 2.7.11:

With version 2.7.14:

Both these screenshot were taken today at a few F5 presses apart.
Desktop (please complete the following information):

OS: Windows 10 Pro Version 1903
Browser: Chrome
Version: 81.0.4044.122 (Official Build) (64-bit)

By default the deploy.ps1 deploys images with the "preview" tag.   These are floating and represent the latest state of master.   Thus when the app service restarts new images are pulled if they have changed.   It is possible to deploy a specific version using the -version argument of the deploy.ps1 script, e.g. "latest" or "2.7.11" in your case.   You can get the version of the master using the "get-version.ps1" script in tools/scripts.

To fixate a deployment to a version you can use the -version argument of the deploy.ps1 script and specify a particular version (as long as this version tag exists on mcr.microsoft.com).  E.g. ./deploy.ps1 -version 2.7.11 deploys this particular version.
Caveat:  The services in 2.7.11 might require a slightly different set of services than are deployed by the arm templates in e.g. master branch if run from master.   E.g. -version 2.6.146 would require the script to be run from release/2.6.x branch to deploy the services as they are required for 2.6 release.


If training with GUI, the speed is very slow.

Hello,
I find if training with GUI, the speed is very slow. How to solve? if training with terminal, the speed is normal.
The instruction is
CUDA_VISIBLE_DEVICES=0 python train_gui.py --source_path YOUR/PATH/TO/DATASET/jumpingjacks --model_path outputs/jumpingjacks --deform_type node --node_num 512 --hyper_dim 8 --is_blender --eval --gt_alpha_mask_as_scene_mask --local_frame --resolution 2 --W 800 --H 800 --gui

I ran the project on a remote server and visualized the GUI through X11 Forwarding.

Have U solve it？ I met with the same problem...


How to make  part of the list of children did not collapse?

How to make  part of the list of children did not collapse?
-parent (up)
--child1
--child2
to
-parent (down)
--child1
--child2
--child3
--child4

Hmm interesting @ulx, currently that is not possible with the library. Best I can think of is to fake this behaviour by having the parent view holder look like Parent + child1 + child 2 no matter the expand or collapse state.


support environments that lack ArrayBuffer.isView; remove old shims

5.0.6

Added back the Number.isNaN shim for IE


Kick off inclusive content principles research

What
We need to understand the research to be done on the inclusive content principles.
Why
So we can:

write the research questions
write the hypotheses
understand what we want to learn by doing this research

Done when

[x] Draft research questions
[x] Draft hypotheses

Would be good to invite:

Rich Kelly
Rhiannon Smith
Chloe Philippou
as they've helped draft the doc.

Research questions

Do people understand the principles?
Do people find the principles useful?
Is there something missing that people would find useful?
How do people feel about the amount of principles? Are they overwhelming?
Are the examples provided useful? Do they make sense to people?
How do people think they compare to the design principles?
In what situations could people see themselves using these principles?
How do people external to NHS Digital feel about them?
What do people think "inclusive content" is? What does it cover and how does that work for them?

Research plan

Invite people, both internal and external to NHS Digital, to give feedback on the principles in a session
Invite people to use version 0 of the principles for approx. 2 weeks and feed back to us (similar to a diary study)

Participants

People who are creating content in a health context (content designers, internal and external to NHS Digital)
People who are managing teams creating this content (product and delivery managers)
Sara, Rich, Chloe and Rhiannon to help with finding people to recruit

Hi @amyj2110, might be worth seeing how they respond to the idea of a checklist versus principles - and/or.


add support for GET user/activities #248

Adds support for GET user/activities #248
Since the response of GET user/activities contains a date format (YYYY-MM-DD) that cannot be unmarshalled into a time.Time automatically, additional logic was added to to cover the un-marshalling of the timestamps:
UserActivityTime.UnmarshalJSON()
UserActivityTime.MarshalJSON()
UserActivityTime.IsSet()
see https://stackoverflow.com/questions/25087960/json-unmarshal-time-that-isnt-in-rfc-3339-format

Hi @svanharmelen - I merged your PR and recreated this one. As you mentioned, I changed the type of ExpiresAt to the new ISOTime and fixed a small typo in the const name for the date layout.
Thanks again for your quick response!

I cherry picked the commits from this PR, so they are now in master and this PR can be closed. Thank again for your work!


added config option git.cloneDirectory, defaulting to os.homedir()

Fixes #17671.
Added a new option called git.cloneDirectory, to be used as the base path for the git.clone command. When it is not set by the user, it will use the current default - os.homedir().

@ihalip,
Thanks for having already signed the Contribution License Agreement. Your agreement has not been validated yet. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Thanks! 🍻
Changed the setting to git.defaultCloneDirectory.


Handle Monorepo Releases

This PR is a follow up for #711.
This is a first sketch.
Overview
The overall goal of this feature is an improvement to the Greenkeeper User Experience when depending on packages that are part of a monorepo. At the moment, users receive a separate update notification for each sub-package in a monorepo. This is less than ideal, because generally, without updating all packages to the same release version, the dependency update doesn’t work fully, so users have to go through sub-packages.length potentially broken CI builds/PRs before they have updated from a monorepo dependency.
We want to change this so updates to packages that are part of a monorepo are handled in unison. For example, package wibble-wobble consists of two sub-packages wibble-wobble-core and wibble-wobble-extra that are always released together and on the same version number. With this update, we’d like Greenkeeper to open a single issue/branch/PR that includes the package.json update for both packages.
How it works
Greenkeeper updates go through two jobs:

registry-change handles update notifications from npm (both the public registry as well as from web  hooks for private packages). This runs once per version update.
create-version-branch creates a branch for a monitored repository that has the dependency that is handled in registry-change. This runs for every repo that is enabled for our users.

We are changing these with the help of code in lib/monorepo.js to handle the above scenario. In addition util/monorepo-definitions.js includes a static list of the structure of monorepos. With that, we can decide if a given registry-change is:

part of a monorepo, and
the last of the updates required for a combined update.

If it is not the last, registry-change simply exits and waits for a future incarnation to issue the actual create-version-branch-es. In addition, it writes a monorepo release info doc into the npm database that includes the timestamp of the latest monorepo release that didn't cause any create-version-branch jobs to be created.
This, together with a view that sorts these docs by timestamp, we are introducing one more component: the monorepo-supervisor. It runs periodically (every 5 minutes) and checks if the aforementioned view returns any documents for the last >= 30 minutes. If it finds any, it re-issues the last registry-change job again, with a force: true parameter, that makes registry-change not bail out. In addition, we receive a Slack/Email notification, that a new monorepo release happened and we can check if our static definition is still up to date.
The following failure scenarios for out of date monorepo definitions are considered:

a new package was added:

this is not a failure, because being a new package, nobody has a dependency on it yet, so we don’t have to send updates.
however, we should update our monorepo definition because the next update will require us to do updates.

a package was deleted:

without the monorepo-supervisor job, we’d wait for this update forever.
we also get a notification so we can update our definition

a package was renamed:

from our point of view, this is a package delete and an unrelated add, so we can’t really offer a good update experience. We can still create a branch so users can do the fix manually (this is no different from today).

create-version-branch will require a few modifications, too: instead of handling a single package update, it now needs to detect a monorepo and update all dependencies that are updated by the monorepo release for the current package. It will create a single package.json transform with all required changes. The same will have to be done to create-group-version-branch.

We want to make updating the monorepo definitions a matter of updating our database, so that we can do the update without full stage/production deploy cycles.
Enterprise?
There are three possible scenarios:

Enterprise installation with DMZ access and lazy admin

Here, we can add a periodic auto-updater that fetches the latest monorepo definitions from our service.

Enterprise installation with DMZ access and eager admin

Here, we can notify the admin via email, that a monorepo definition might require a manual update, and we’ll explain how to make the edit in the GKE database. Even allow definition of private monorepo structures.

Enterprise installation without DMZ access

Like 2, and no updates.

ToDo:

[x] Write More Tests
[x] Handle updates in create[-group]-version-branch
[x] adapt lib/get-infos
[x] adapt lib/get-diff-commits
[x] adapt lib/handle-branch-status
[x] Add the monorepo definitions to the database for easier updating, and customisation for Enterprise users.
[x] Add Slack notifications
[x] ~Add Email notification~ not in this PR
[x] ~decide whether and how we want to handle monorepos that do not assign the same version number to all packages.~ -> not in this PR
[x] figure out all places after create[-group]-version-branch that need adjustment, like branch-cleanup etc.
[x] decide whether the release update info doc gets deleted in create-version-branch or in registry-update
[x] discuss: reduce wait period to 5 or 10 minutes

great work on this. this has really cleaned up the process that used to require a fair amount of manual handling because of conflicts with each package being so close together in the package file(s).
keep up the great work!

Thank you @travi <3 :)


Development: Setup build server for project

Add job for building a release package, tagging the repository and uploading it directly. So it only has to be linked on the release page (https://github.com/npruehs/slash-framework/releases).
Add job to update API documentation
Add continuous job to run after each commit that runs unit tests and checks if everything still compiles

Unit Tests: Create NUnit Test Project (https://github.com/nunit/nunit/wiki/NUnit-Test-Projects)

Continuous integration job running now on Jenkins server:

Check out new commit(s)
Building the framework dlls
Running all unit tests
Sending out mails if any unit tests failed

Moved "Add job to update API documentation" to own issue: https://github.com/npruehs/slash-framework/issues/21

Moved "Add job for building a release package,..." to own issue: https://github.com/npruehs/slash-framework/issues/22

CI job runs successfully including running the unit test projects.


Missing u2fval.conf under ./conf folder

The setup process need the file to continue.
However it failed to reach the file.
because there wasn't any file named u2fval.conf.
Any suggestion? thanks

Duplicate of #1.


Create endpoint for lost account recovery

I just started poking around the auth implementation, aiming for a quick integration with the existing frontend.
So far I only explored the endpoints, looking for all the thing I might need in order to provide a full user experience. One issue I found is that there is no endpoint for recovering an account (e.g. "lost password" endpoint).
The desired user story would be:

user has an unauthenticated endpoint where she can POST something like this: { "email"<EMAIL_ADDRESS>}
server registers the request and generates a one time password refresh token
user receives an email with the password refresh token

user POSTs back the password refresh token together with the new password

server processes this as:

validates token
expires the token
changes user password
returns HTTP 200 for the request

@edgarmarkosov This is something very important that we forgot.

@georgiana-b I agree with you.


let upstream phases send keepalives to their downstreams

so their downstream contexts won't be killed by the reaper when the upstream phase takes very long to produce a result

ack

This has been merged/commited to master some time ago. So closing the PR


HTTP error occurred during file upload (error status: 400)

Can not upload image everything is as in example

As I found the problem is in CSRF and can not attach CSRF token by $.ajaxsetup

Which example application are you using? If you want to enable CSRF protection, you have to uncomment line 15, line 23 and line 29 in image-upload example.

Thanks but it is not working in flask admin

Please try a minimal app and flask admin together and see if CSRF is problem

OK, I will try to add an example for Flask-Admin with image upload.

Example app added here, you can uncomment the related 3 lines in app.py to enable CSRF protection.

this is same problem??

AimanMRT

Were you able to find resolution for this, I am facing the same issue.


Add CONTRIBUTING.md

Note: let's consider adding a /docs/contributing section to the website and link to this in CONTRIBUTING.md, so we have a single source of truth.


Mfix DEM example and LSD model

Problem description

The previous linear spring-head model was not linear. The constant k_n depended on the relative normal velocity in the code (and not on the characteristic impact velocity as written in Lethe's theoretical section).
The variables k_n and k_t were modified for the linear model of particle-particle and particle-wall collisions.
Previously, tangential damping was neglected in particle-wall collisions.

Solution description

A new definition of k_n was used according to equation 2.46 of "Coupling CFD-DEM, Hamid Reza Norouzi" . The same definition was used for particle-particle collisions.
A new definition of k_t was used following the MFIX definition ( Documentation of open-source MFIX-DEM software for gas-solids flows1).

How was this tested?

A new example has been implemented. This is the same example as MFIX, DEM02. ( https://mfix.netl.doe.gov/doc/vvuq-manual/main/html/dem/dem-02.html)
The results of the previous example agree with ours.

Documentation

lethe/doc/source/theory/dem/dem.rst --> Modifies to comply with the new equations.

Future changes

Particle-particle collision has not yet been tested against a reference. Section "4.3. DEM03: Two stacked, compressed particles" of MFIX could be a good option.
The tangential component of the linear model has not yet been tested quantitatively. Example "4.5. DEM05: Oblique collision of particles" from MFIX could be a good option.

Comments

@OGaboriault Can you "resolve" in the GUI the comments which have been addressed :) ?

@tonielgeitani if you are ok, I will merge after CI


pythonPackages.pytest-localserver: 0.3.5 -> 0.3.7

Warning
This patch is based on the nixos-unstable branch.
Motivation for this change
Closes #26237
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Artificially tested (by building). Going to rebuild my system with this patch now and reporting back then.

I'd be happy to do these changes, but I'd prefer to open another PR for them. This is simply a pkg update PR to fix the build on unstable.


Response code 500 for mistyped or missing license in the Compatibility Matrix.

@tmortagne
Dear Thomas, I noticed most of the API Endpoints for Maven projects  provide 400 and 404 as error messages, and none of them has 500.
LCV REST APIs provide 500 response codes when a mistyped or missing license in the Compatibility Matrix is POSTed, in both inbound or outbound licenses.
From your perspective, should this be an issue to address?
Small update, I am working on adapting the LCV to read the full OSADL matrix .

LCV REST APIs provide 500 response codes when a mistyped or missing license in the Compatibility Matrix is POSTed, in both inbound or outbound licenses.

Unknown resources are generally reported with 404 errors and not 500 which is generally used more for really invalid input (which is not the case here since the license is most probably a valid one, but the server can hardly know all the licenses that exist) or unexpected server side problems.
Now for this specific use case I feel that not taking into account that license for the validation but report in the response the list of licenses that are unknown (so not taken into account in the received results) would be much more valuable.
That means that on Maven plugin side I could print a warning about the licenses that could not be taken into account in the result instead of totally making it impossible to validate at least the known ones.

That means that on Maven plugin side I could print a warning about the licenses that could not be taken into account in the result instead of totally making it impossible to validate at least the known ones.

@tmortagne
What about printing a warning showing the licenses that are taken into account?
The plan is to support 66 OSS licenses.
This list could be retrieved directly from the matrix, which wouldn't require you to update the warning after a Matrix update.

What about printing a warning showing the licenses that are taken into account?

Not really sure what you mean by print.
What is need:

do license validation on the licenses known by the service (but if the outbound license itself is unknown you cannot really do much obviously do you should return a 404 error for example)
some way in the response to be able to deduce which license were used, taken into account

That means that on the Maven plugin side, I could print a warning about the licenses that could not be taken into account in the result instead of totally making it impossible to validate at least the known ones.

@tmortagne Sorry, I didn't mention pint a warning in the Maven plugin side. I was just following your reasoning.
My point is that we can provide the list of the supported licenses just by looking at the compatibility matrix.
It could be hard to print a list of unsupported licenses (they are unsupported because they are not present in the Matrix, so it would also be difficult to list those).
Printing a warning (as you mentioned in the first reply), including the licenses supported, would make more sense. Furthermore, as I explained, if the Matrix is updated with new licenses, the warning will follow the new Matrix structure.
Does this sound to you?

It could be hard to print a list of unsupported licenses (they are unsupported because they are not present in the Matrix, so it would also be difficult to list those).

I don't think you understand what I suggested. I'm not asking the REST API to indicate the list of all the licenses that it does not support since that's obviously not possible, I'm just asking the REST API to indicate in the response which of the licenses that were sent in the request were taken or not into account.

Now I got it.
I will create a 404 response with the name of the license that is not supported by the matrix.
Sorry for the misunderstanding @tmortagne
I will do my best to try to address your request.

Dear Thomas @tmortagne,
I managed to check upon missing or mistyped inbound and outbound licenses, providing the verbose endpoints with a log also related to these licenses.
Still is open the issue to provide a 404 in some cases. But honestly, at the moment, I don't have in mind what other cases could be generating an error.
I will close this issue whenever we are sure that, in any case, the REST APIs will provide an error.
Thanks for your kind suggestions.
Michele

But honestly, at the moment, I don't have in mind what other cases could be generating an error.

I cannot think of anything else that an unknown outbound license.
Looking forward to testing the new license validation API !

Also, the outbound license is handled.
Well, as I mentioned before, these controls are made upon verbose REST API endpoints, namely, where details regarding each inbound are given.
A few flag endpoints just provide True, False, or DUC. So I didn't cover those endpoints.
Here there are two ideas about those endpoints:

providing a response including only the name of the not included license explaining that is not supported, without providing the assessment (probably easier at this point for me).
providing a 404 error probably specifying that one (or more) of the licenses are not included in the Matrix.

I would go for the first point, but please feel free to provide your suggestion.
Sincerely,
Michele
PS for testing the new APIs, I am waiting for @mir-am to deploy the lcv-restapi  in a way that you can use it.
So far is reachable only from the internal network ( I tried it using monster)

This issue should be fixed by introducing a few functions that verify if a license is in the Matrix or not.
More detailed upon this approach are provided in:
https://github.com/fasten-project/LCV-CM/issues/4


Fix typo in mvc filters doc

Hi @sgwatgit, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

aspnetcore/mvc/controllers/filters.md
:white_check_mark:Succeeded

Details

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

Thanks!


added copy button issue 337 omesh-omg

Description
this PR adds a copy-button icon to code blocks in documentation
This PR fixes #337
Notes for Reviewers
I have added the button using javascript dom manipulation by searching all the code blocks and
adding the button to them in the code and than there is a CSS file for button, and also imported clipboard.min.js for copy function.
https://github.com/layer5io/getnighthawk/assets/64972958/b5590516-8114-4d19-8ba8-4cd831d987b7
Signed commits

[x] Yes, I signed my commits.

@Savio629
The scroll issue is also resolved
use of icon instead of text

@abhijeetgauravm Thanks, 😄
sure if it is required I will do it.

I have added the horizontal scrolling for the code blocks @abhijeetgauravm @Savio629

Hey @omesh-omg  Let's discuss this on website call tomorrow at 6:30 PM IST / 7 AM Central time. Please add this as an agenda item in the meeting minutes.

Okay

hey @saurabh100ni  can u mention the colors to use for the copy button in highlighted state and normal state as You mentioned it during the meeting it's been a long it I will add those colors and push it, Let's finish this

@omesh-omg I guess @ritiksaxena124 already told you to update it with the caribbean green color.
for more details, please refer to this part of the recording to checkout the feedback in detail.

Okay thankyou @saurabh100ni

I think everything is okay now all the required changes are resolved

I assume both code blocks are different, but they lack spacing, OR you can merge them into one and add copy button for individual codeblock.

Hi @MUzairS15  I have implemented the required changes adding the margin for better readability


Did a lot of work password authenticaiton

Made most of the backend files for password authentication and functionality. Made the front-end files for starting off.

looks good

Reviewed and approved


Ignores files in __MACOSX folder

Fixes #3817

“Contains” is probably fine, but is there a method for StartsWith? And maybe starts with “__MACOSX/“ with the slash?


Column description set in WDC is ignored by Tableau

Checked this in Tableau 10.2,10.4&10.5 so this is a longstanding problem.
I checked that column description existed in TableSchema in the getSchema function immediately prior to the SchemaCallback returning it to Tableau.
I also used the Simulator and can see the Column description there.
Tableau also has no problem handling Table description.

I've come up against this problem with Tableau 2018.1.6 too.

@maxrandolph Please also check the other attributes for columns as I don't think all of them work.


Pushing my data to the GDSC-Lead Map

Fixes #
Proposed Changes

Thanks, @JuliusKanneh for submitting your profile. Thanks, @aravindvnair99 for reviewing.
Sorry for the late response.


Add more test coverage for org.apache.dubbo.rpc.protocol.dubbo.pu

What is the purpose of the change
add test case https://github.com/apache/dubbo/issues/14502
Brief changelog
add some test case
This work is done by Tongyiling code:

Unit test class generation
Revise the test case with each adjustment question
Remove Chinese comments and generate English comments

Verifying this change
all test is success

Checklist

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

@AlbumenJ Please Take A Look


feat: adds roles to service account

Adds roles to terraform

Added BigQuery Job User
Added BigQuery Data Viewer
Added Cloud Datastore User
Added Storage Object User

LGTM


Migrate schema validation to io-ts

Instead of using GraphQL for validation of contract calls, we'll instead look to use io-ts.
This will:

Update the structure of our bundle
Enfore io-ts types from the contract server for each call
Create an addition to the client module that enforces the io-ts types

We could use https://github.com/taion/graphql-type-json to enforce a json structure in the client submission


⚠ Bofrost.fr has degraded performance

In e7ad618, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 960 ms

Resolved: Bofrost.fr performance has improved in 6632ad5 after 10 minutes.


Master branch README sets NVM_DIR to root of $XDG_CONFIG_HOME !!

Operating system and version:
RHEL 7.7

nvm debug output:

$SHELL: /bin/bash
$HOME: /home/lousyd
$NVM_DIR: '$HOME/.config'

How did you install nvm? (e.g. install script in readme, Homebrew):
install script in readme

What steps did you perform?
I ran https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh.

What happened?
It installed NVM, but to the wrong NVM_DIR. It installed to the root of $XDG_CONFIG_HOME, i.e. $HOME/.config.

What did you expect to happen?
I expected it to install to a subdirectory of $XDG_CONFIG_HOME called "nvm".

Is there anything in any of your profile files (.bashrc, .bash_profile, .zshrc, etc) that modifies the PATH?
No.

The README in the master branch says to install nvm using the install script in the 0.34.0 branch. That branch's install script has a bug. It sets NVM_DIR directly to $XDG_CONFIG_HOME, not to a subdirectory of $XDG_CONFIG_HOME. It looks like that install script bug has been fixed in the master branch, but the README for the master branch is still referring users to the buggy install script in the 0.34.0 branch.
I would suggest that either you make a new release from the master branch (0.34.1 or 0.35.0 or whatever) and update the master branch README to point to that, or fix the master branch README to refer users to the master branch install script.
This is an urgent issue because this bug installs nvm files to the root of $XDG_CONFIG_HOME, potentially overwriting already existing files or directories with names identical to what nvm installs, and potentially putting nvm files and directories at risk of being overwritten by other programs that create their own config in $XDG_CONFIG_HOME using names identical to the files and directories nvm has written there.
An aside while I'm here: I just want to say thank you for being XDG aware. Thank you for using XDG_CONFIG_HOME in the first place. It annoys me to no end that so much software treats my home directory as its dumping ground like it's still 1999 instead of 2019. Thumbs up to nvm for that.

yeah, i just tried doing this to avoid having nvm installed to my home directory directly, and took me a few minutes to double check it didn't accidentally overwrite anything... This is a pretty serious bug as it can break people's user directories.

A new release would be warranted; it hasn't been considered  urgent because XDG usage seems to be vanishingly low, but I'll get to  it as soon as I can.

Why do you say that? I'm on Ubuntu 18.04 and by default it sets the $XDG_CONIFG_HOME variable.
IMHO I would consider this a bug to be fixed asap. You've got a rather important node tool like nvm polluting the main configuration directory of one's machine.

@bergercookie i'm not saying that to impugn that standard, i'm saying that in my experience, most posix users do not know about XDG, do not set it, and thus have no expectations for it to be supported. (see the last paragraph in the OP).
I plan to get a release out in the next day or two.

v0.35.0 has been released.


allow ratioMetric to support single query

Currently, the ratioMetric requires two separate queries, one for good responses, the other for total.  In some circumstances, it would be desirable to have a single query where good and total are inferred based on the query response.  The spec would need to support both the tallying of the total number, as well as mapping of the values to the appropriate group e.g. true maps to good and increments the total, and false simply maps to total

A strong argument in favour of this is when your monitoring system collects, or derives, metrics at different times. If your numerator and denominator are not perfectly in sync, you run into issues like (number of good events) > (total number of events), and SLI performance outside the [0%, 100%] range, negative burn rates (we're saving error budget), and so on.


Can't push code on MacBook

Whenever I try to push code wirelessly I get two errors with the new 10.1 Controller. This is the error, Unknown host 'repo.maven.apache.org: nodename nor servname provided, or not known'. You may need to adjust the proxy settings in Gradle. I also get this error, Task :FtcRobotController:compileDebugLibraryResources FAILED. I need help trying to figure this out

The first error can be resolved by disconnecting from the robot, connecting to some normal wifi (school wifis can block things, so if you're connected to school wifi and it fails, try your home wifi, or a hotspot) and hitting the hammer button. There's a dependency or two that needs to be downloaded on the first build, that doesn't get downloaded when you sync.
It sounds like the second issue is caused by the change in default Gradle JDK that upgrading to the newest version of Android Studio causes, or some other similar Gradle issue. Check out the two articles in the Gradle section of cookbook on how to ensure that you haven't changed the wrong Gradle setting, and that your Gradle JDK is the correct version. Once you've made changes to gradle settings, I recommend restarting Android Studio, then building your project again.

Android Studio Ladybug Gradle issues are addressed in 10.1.1.
If you still have problems, please reopen a new issue and provide complete build logs.


suggest removing temporal_radius >= 1 restriction

Temporal_radius could be 0, which means that DSM will be computed for each time point. This seems also useful, especially for cross-time RSA analysis in EEG.

Great suggestion!


active go111module

This PR is raised during the development of GreenCloud.
Fixes #57

You can set this fairly easily via a build arg. See the openfaas docs for more.

/lock: invalid


Pass environment variables through to xcodebuild

Description
Allow developers to pass in arbitrary Xcode build settings via environment variables prefixed with FLUTTER_XCODE_.  This will prevent the need for a new flutter flag for every build setting a developer may want to change.
We can use this in our device lab to override code signing Xcode settings without needed to edit every integration test Xcode project, for example.
Removes the need for patterns like FLUTTER_DEVICELAB_XCODE_PROVISIONING_CONFIG that inject xcconfig files into Generated files (https://github.com/flutter/flutter/pull/10736/files)
Related Issues
See proposal in https://github.com/flutter/flutter/issues/37231#issue-474518955.
Tests
Added a few xcodebuild commands tests.
Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I signed the [CLA].
[x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change

[ ] Yes, this is a breaking change (Please read [Handling breaking changes]). Replace this with a link to the e-mail where you asked for input on this proposed change.
[x] No, this is not a breaking change.

Do you guys have suggestions for where to document this?

\cc @godofredoc

Do you guys have suggestions for where to document this?

Good question. Maybe a new wiki page for Xcode configuration?


Fixed Delimiter Injection Vulnerability in exportVariable

Describe the summary:
The Electron Website provides a set of packages to make creating actions easier. The core.exportVariable function uses a well known delimiter that attackers can use to break out of that specific variable and assign values to other arbitrary variables. Workflows that write untrusted values to the GITHUB_ENV file may cause the path or other environment variables to be modified without the intention of the workflow or action author. Users should upgrade to @actions/core v1.9.1. If you are unable to upgrade the @actions/core package, you can modify your action to ensure that any user input does not contain the delimiter _GitHubActionsFileCommandDelimeter_ before calling core.exportVariable.
CVE-2022-35954
CWE-74
CWE-77
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N

For security reasons the Electron team does not accept dependency bumps or lockfiles changes from external collaborators.
I have performed the minimal required bump myself here --> https://github.com/electron/website/pull/317


useTitleAsClassname ignores character

Schema definition:
{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title": "myTestClassV1_0",
}

This will generate a class with the name myTestClassV10 instead of myTestClassV1_0

This is because of the default 'property word delimiters'. Underscore is assumed to separate words, and is then used to create camel case names.
If you set property word delimiters to only space and hyphen (something like that) then you should see the underscore is retained.

That did it, many thanks :)


cannot load scanpy after updating to 1.4.6 via miniconda

I have upgraded to scanpy 1.4.6 in a conda environment. Since then I cannot load the package into python, as it gives me the following error: AttributeError: module 'cairo' has no attribute 'version_info'

import scanpy

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/scanpy/__init__.py", line 38, in <module>
    from . import plotting as pl
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/scanpy/plotting/__init__.py", line 1, in <module>
    from ._anndata import scatter, violin, ranking, clustermap, stacked_violin, heatmap, dotplot, matrixplot, tracksplot, dendrogram, correlation_matrix
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/scanpy/plotting/_anndata.py", line 16, in <module>
    from matplotlib import pyplot as pl
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/matplotlib/pyplot.py", line 2349, in <module>
    switch_backend(rcParams["backend"])
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/matplotlib/__init__.py", line 833, in __getitem__
    plt.switch_backend(rcsetup._auto_backend_sentinel)
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/matplotlib/pyplot.py", line 204, in switch_backend
    switch_backend(candidate)
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/matplotlib/pyplot.py", line 221, in switch_backend
    backend_mod = importlib.import_module(backend_name)
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/matplotlib/backends/backend_gtk3agg.py", line 4, in <module>
    from . import backend_agg, backend_cairo, backend_gtk3
  File "/home/tsztank/.miniconda3/envs/brandeis/lib/python3.7/site-packages/matplotlib/backends/backend_cairo.py", line 15, in <module>
    if cairo.version_info < (1, 11, 0):
AttributeError: module 'cairo' has no attribute 'version_info'
>>>

I have scanpy==1.4.6, matplotlib==3.1.2

Could you try running:
from matplotlib import pyplot as plt

in this environment?

Hi! so when installing via pip this is not an issue... somehow with conda it doesnt work

Ok so it doesnt work, again, even with pip... @ivirshup I tried the code you wrote, and it gives me the same error:
`` AttributeError: module 'cairo' has no attribute 'version_info'

So, it looks like the conda environment has a broken install of Matplotlib, which I don't think I can help with too much.
Are you able to create an environment with just Matplotlib, where you're able to import pyplot? Does adding scanpy to this environment break matplotlib?


qualifiers for factbook not part of output

YAML:
# irrigated_land
statementMapping:
  region:
    - left: CB
      right: CB
      top: 9
      bottom: 26
  template:
    item: item[B, $row]
    property: P1082
    value: value[$col, $row]
    unit: Q712226 # sq km
    qualifier:
      - property: P585
        value: value[CD, 9]
        calendar: Q1985727
        precision: year
        time_zone: 0
        format: "%Y"
    #reference:
    #  - property: P246 # stated in
    #    value: Q11191 # The World Factbook

by commit a13a69c this was fixed (it's possible part of the fix was in commit db6dd41)


no exe file available

Cannot find the exe file, please help.

Yeah they expired. I made a new commit: https://github.com/skyte/momentum/actions/runs/5164554526


useRef for creation of objects?

I've been seeing a common pattern of creating an object that is an instance of a class in a useRef call:
const mapRef = useRef(new Map());

Can we maybe come up with a version of useRef that works a bit similarly to useMemo, but that it only executes the function the first time?:
const mapRef = useCreationRef(()=>new Map());

Looking at this comparatively on jsperf, it seems quite clear that the second version would always be faster when it involves creation of class objects. Especially when considering custom class objects, which could have constructors that do a lot more than just initialization.
If it's welcome, I'm happy to put up a PR for this.

why you could not store data in the state?
why you could not transfer data from the state?
 useRef(useState(() => new Map())[0]);

why you could not store data in the state?
why you could not transfer data from the state?
 useRef(useState(() => new Map())[0]);

I didn't say I did it, so I'm not sure why you're asking me. There's a ton of cases I'm seeing like this at Facebook.
Looks like Dan already gave an answer like this on a similar thread https://github.com/facebook/react/issues/14490#issuecomment-454990990.


Update community-plugins.json

Provide concise output given limited app space

Same about this one @RwnQ8


bug: potentially flaky dialog box function

see: https://github.com/lino-levan/astral/actions/runs/6501910122/job/17660034750

I think this was fixed by marvin


Fitted paramers reloaded from NC lead to errors in standardized index, and setting multiple indexers leads to inconsistent behaviour

Setup Information

Xclim version: 0.51.0
Python version: 3.11.8
Operating System: Ubuntu 20.04

Description
The time indexer in the xc.indices.stats.standardized_index_fit_params was not correctly stored in the attributes, leading to errors in different cases:

When there is no indexer, the indexer in the xc.indices.stats.standardized_index_fit_params was changed after to_netcdf and reloaded from xr.open_dataset(), leading to an error when running standardized_precipitation_index(pr, params=params);
When the value of indexer is a non-array single value, there will be an error when encoding the attribute params.attrs["time_indexer"] in stats.standardized_index_fit_params;
When there are multiple indexers, only one indexer is saved, leading to inconsistent behaviour when running standardized_precipitation_index(pr, params=params).

Steps To Reproduce
Load dataset:
import xarray as xr
import xclim.indices as xci
from xclim.testing import open_dataset

ds = open_dataset("sdba/CanESM2_1950-2100.nc").isel(location=1)
pr = ds.pr.sel(time=slice("1998", "2000"))
pr_cal = ds.pr.sel(time=slice("1950", "1980"))
params = xci.stats.standardized_index_fit_params(
    pr_cal, freq="MS", window=1, dist="gamma", method="APP", fitkwargs={"floc": 0}, zero_inflated=True)

For the first issue,
params.to_dataset(name="params").to_netcdf("params.nc")
params = xr.open_dataset("params.nc").params

spi = xci.standardized_precipitation_index(pr, params=params)  # this line leads to the error

For the second issue,
params = xci.stats.standardized_index_fit_params(
    pr_cal, freq="MS", window=1, dist="gamma", method="APP", fitkwargs={"floc": 0}, zero_inflated=True, month=2)
# executable only when an array is assigned to `month`

For the third issue,
params = xci.stats.standardized_index_fit_params(
    pr_cal, freq="MS", window=1, dist="gamma", method="APP", fitkwargs={"floc": 0}, zero_inflated=True, drop=True, month=[2, 3])  # `drop=True` is not saved in params.attrs["time_indexer"]`
xci.standardized_precipitation_index(pr, params=params)  # the months other than 2 & 3 were not dropped

Additional context
The error logs are attached here.
For the first issue,
File ~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:882, in standardized_index(da, freq, window, dist, method, zero_inflated, fitkwargs, cal_start, cal_end, params, **indexer)
    [880](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:880) # Unpack attrs to None and {} if needed
    [881](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:881) freq = None if freq == "" else freq
--> [882](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:882) indexer = {} if indexer[0] == "" else {indexer[0]: indexer[1:]}
    [883](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:883) if cal_start or cal_end:
    [884](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:884)     warnings.warn(
    [885](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:885)         "Expected either `cal_{start|end}` or `params`, got both. The `params` input overrides other inputs."
    [886](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:886)         "If `cal_start`, `cal_end`, `freq`, `window`, and/or `dist` were given as input, they will be ignored."
    [887](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:887)     )

IndexError: string index out of range

For the second issue,
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[3], [line 1](vscode-notebook-cell:?execution_count=3&line=1)
----> [1](vscode-notebook-cell:?execution_count=3&line=1) params = xci.stats.standardized_index_fit_params(
      [2](vscode-notebook-cell:?execution_count=3&line=2)     pr_cal, freq="MS", window=1, dist="gamma", method="APP", fitkwargs={"floc": 0}, zero_inflated=True, month=2)

File ~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:801, in standardized_index_fit_params(da, freq, window, dist, method, zero_inflated, fitkwargs, offset, **indexer)
    [791](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:791) params.attrs = {
    [792](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:792)     "calibration_period": cal_range,
    [793](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:793)     "freq": freq or "",
   (...)
    [798](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:798)     "units": "",
    [799](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:799) }
    [800](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:800) method, args = ("", []) if indexer == {} else indexer.popitem()
--> [801](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:801) params.attrs["time_indexer"] = (method, *args)
    [802](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:802) if offset:
    [803](~/.conda/envs/syncfuture/lib/python3.11/site-packages/xclim/indices/stats.py:803)     params.attrs["offset"] = offset

For the third issue, the attributes in the params are like

and the obtained SPI would be like
.
Contribution

[X] I would be willing/able to open a Pull Request to address this bug.

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Thanks for the issue @Hem-W ! Indeed, we only tested this mechanic by loading the params in-memory, and forgot about all these issues when going through netCDF!


Error coming

Ig its a dpy error if you can fix please fix it

Ig its a dpy error if you can fix please fix it

Can you give any other info on this error? Your "image" is just a link back to this issue

Can you give any other info on this error? Your "image" is just a link back to this issue

Nvm i forgot something btw can you add more features like end,reroll etc

I'll have a look into it and see what I can add in the next few weeks when I have some time :)


HIP 83: Restore First to Respond Witness Rewarding

HIP 83: Restore First to Respond Witness Rewarding

Author(s): @BFGNeil, @mawdegroot
Start Date: 2023-05-05
Category: Economic, Technical
Original HIP PR: #605
Tracking Issue: #632
Voting Requirements: veIOT Holders

Summary
Currently, the Proof-of-Coverage Oracles collect all the witnesses for a beacon and randomly reward a selection of 14 witnesses. This HIP proposes to revert to rewarding the first 14 Hotspots responding to a beacon, incentivizing the most useful Hotspots to sensor traffic by prioritizing the low latency connections that sensors need for uplinks, downlinks, and join requests to work correctly.
Motivation
Rewarding witnesses that are the first to respond will incentivize Hotspots to provide the low-latency connection that the sensors desperately need.
Sensors use uplinks to transfer their data over the Helium network. For a sensor to join the Helium network, it must perform a handshake that requires both an uplink and a downlink. As a power-saving measure, a sensor often has a limited time window to listen for the downlink.
Because the sensor only listens for the downlink for a limited time, the Helium LNS and the Hotspots must minimize latency to ensure the Hotspot can deliver downlinks to sensors within the narrow sensor listening window.
The Helium network originally rewarded the fastest witnesses and moved to a random selection for several technical reasons that no longer apply to the Oracle-based POC architecture introduced as part of HIP 70.
Technical limitations included, but are not limited to:

Regular retransmissions on the libp2p network left Hotspot unable to deliver witness reports.
Hotspots struggled to sync the Helium blockchain before Validators and needed more time to determine which challenger to deliver a witness to.

Rendered View
https://github.com/helium/HIP/blob/main/0083-restore-first-to-witness.md
Supporting Code
https://github.com/helium/oracles/compare/main...mawdegroot:oracles:mg/first-to-respond-witnessing

Don't really see the relation with the expected behavior:

hotspot connectivity is a consequence, not really a choice
hotspot response time to witness is more related to the distance to Oracle than the connectivity type.
witness response time is not involved in packet selection
router should get best packet, not first packet, router is time constrained on reception, whatever is the hotspot response time
Join Accept windows is 5s .... so this Hip about ms is non sense for this.
Downlink windows is 2s, tens of Ms don't change anything, wait windows is about 500ms
This will make some hotspot not earning due to good but not enought fast connectivity and will conduct these hotspot owner to disconnect miner. The second hand market is already flooded so the only consequence of this will be a reduction of the coverage.
High latency HS are usually 4G, most of 4G are well placed hotspot (ohtehrwise you have wifi) so this will basically impact some of the best Hotspot in term of coverage

Reward Systems in general are implemented to drive the behaviour/expansion of a system in the direction which is in the best interests of that system.
Therefore I would suggest the Reward System should be structured to match the best outcome for the network and that would be to maximise the coverage area.  To to do this would be to maximise the number of Hotspots and to reduce the overlap (one way to think of this would be to reduce the number of Hotspots per Hex).
With the creation of HIP84, this HIP(83) is now redundant and the Rewards System should be proposed on HIP84 to match the outcomes which are determined in that HIP.

the low-latency connection that the sensors desperately need.

Do you have any evidence to support this?

Because the sensor only listens for the downlink for a limited time, the Helium LNS and the Hotspots must minimize latency to ensure the Hotspot can deliver downlinks to sensors within the narrow sensor listening window.

Do you have any evidence to show that this is a problem on a wider scale? If high latency hotspots are dropping sensor packets, wouldn't be better to reduce the PoC window to match the network timeout? That way these hotspots will not be rewarded, according to the network timeout configuration.
Most developed countries have low latency fibre to the premises available in high population density areas, so is this really a problem?
I think this is a bad change that will result in rewards being centralised to those that can configure low latency networks, hardware overclocking, etc. Some manufacturers who cheap out on low spec hardware may lose rewards, when these units are still fit for purpose. The casual users who don't know anything about this will eventually turn their perfectly fine hotspots off, resulting in power coverage and a poorer network.

This HIP would be a massive step backwards in coverage. It skews rewards towards hotspots with the highest internet speed / lowest latency available - typically urban areas, which are already oversaturated and should experience a disincentive rather than additional incentives.
Conversely, the hotspots doing the most for extending coverage - those further away from urban centres, hex "pioneers", etc. - usually have less fancy internet connections, e.g. 4G. They also typically invested a lot more in their setups. We need those hotspots in particular in order to grow the network in the right places, yet, their rewards would massively suffer.
This is counterproductive and feels like an attempt to concentrate rewards towards a few, super-connected hotspots, with little regard for what that means for the network.

I have this miner in London, UK. The miners is with a 8 DBI antenna. I use this HeliumGeek app which shows what my miner is doing. I think and believe that I am not being treated very well because of this useless random selection. My miner is there and antenna is there. It is there to be used and to provide service which it is doing. My internet is 1GB download and 150 Mb upload. Miner is connected to the modem via cable. When I test the speed, it's 50 upload and 40 download. Latency is 30 and this can change every time I test. I have this app called Helium Geek. It has 3 important icons. Beaconed, Witnessed and Unselected. The Beacon I sent is always being picked up by 14 other hotspots.  The unselected icon, which is in grey is never above 10-15 minutes. This means my hotspot is seeing many many other hotspots but I don't get selected to be rewarded. This is what you guys need to address. People with good hotspots should get good rewards. My antenna is up on 30 m high. It is seeing up to 700 other hotspots but does not get rewarded.
So HIP 83 can and should be good.

So … basically there is 700 hotspots around you and you would like to be selected more often than the other one … because you are really important and the other are useless if i understand well.
i don’t understand your arguments ? You have a standard setup, a standard ISP connection but you think it is better than the 700 other hotspot around ..
My two cents, with a such density of hostpot, if HIP83 where applied, you will never see a witness anymore …

There is a reason for that, it is meant to be low power, not low latency....
Have the authors any idea of LoRa in general? Then they should be aware of the fact that latency is not a problem.

There is a reason for that, it is meant to be low power, not low latency.... Have the authors any idea of LoRa in general? Then they should be aware of the fact that latency is not a problem.

Hi, thats not true, remember Join Confirmations, Downlinks and ACK's are an important part. These need to be fast to work.
We also have Class C support now with chirp stack, bidirectional is an important part

This HIP would be a massive step backwards in coverage. It skews rewards towards hotspots with the highest internet speed / lowest latency available - typically urban areas, which are already oversaturated and should experience a disincentive rather than additional incentives.
Conversely, the hotspots doing the most for extending coverage - those further away from urban centres, hex "pioneers", etc. - usually have less fancy internet connections, e.g. 4G. They also typically invested a lot more in their setups. We need those hotspots in particular in order to grow the network in the right places, yet, their rewards would massively suffer.
This is counterproductive and feels like an attempt to concentrate rewards towards a few, super-connected hotspots, with little regard for what that means for the network.

This is actually a really good point. I'm still getting shafted by not having many hotspots around me purely because I'm in a mountain valley. Now I'll get shafted for not many neighboring hotspots AND slot latency to the collectors.
Glad I diverted my spending money away from this even more after reading this HIP.

This is actually a really good point. I'm still getting shafted by not having many hotspots around me purely because I'm in a mountain valley. Now I'll get shafted for not many neighboring hotspots AND slow latency to the collectors.
Glad I diverted my spending money away from this even more after reading this HIP.

If the beacons you witness have 14 or fewer witnesses (common in unsaturated, rural areas), then HIP 83 will not affect you at all. If the beacons you witness have more than 14 witnesses, then that's not as unsaturated an area as you may think.

This is actually a really good point. I'm still getting shafted by not having many hotspots around me purely because I'm in a mountain valley. Now I'll get shafted for not many neighboring hotspots AND slow latency to the collectors.
Glad I diverted my spending money away from this even more after reading this HIP.

If the beacons you witness have 14 or fewer witnesses (common in unsaturated, rural areas), then HIP 83 will not affect you at all. If the beacons you witness have more than 14 witnesses, then that's not as unsaturated an area as you may think.

o cool, I'm still rewarded less regardless

o cool, I'm still rewarded less regardless

Ok, so you're in an oversaturated area with more than 14 hotspots different providing coverage for a single sensor in that area. It'd benefit the network for some of those hotspots to be redeployed to less saturated areas anyway, to expand total network coverage.

o cool, I'm still rewarded less regardless

Ok, so you're in an oversaturated area with more than 14 hotspots providing coverage for a single sensor in that area. It'd benefit the network for some of those hotspots to be redeployed to less saturated areas anyway, to expand total network coverage.

I didn't know less than 8 meant more than 14 - thanks for the quick maths

I didn't know less than 8 meant more than 14 - thanks for the quick maths

If HIP 83 would negatively affect your earnings if implemented, that means the beacons you witness necessarily have to have more than 14 witnesses.

I'm a little late to the game here, but was it ever considered starting a cut-off 1 (or 2) seconds after the first receipt?
I think this would mirror the LoRaWAN spec better as the first RX window is 1 second for roundtrip. So anyone that shows up a full second later would be "useless" from a coverage perspective due to latencies.
Currently, this cutoff feels too arbitrary.

Join request are 5s - 6s windows so basically you currently wait more than a single second for this type of packets ( around 2s) and uplink with no ack (most common type of packets) does not have time constraints. Also 2s wait is a standard windows for reception of a larger amount of packets.

Seeing this modification in action, it is apparent that good placements are not rewarded any more. In other words, in my area: mediocre placements with low-latency internet are up 2x (taking almost any beacon they can "hear") and near-excellent placements with medium-latency internet are 2x down ("hearing" much more beacons but being selected for almost none, due to the latency). I have very high and rare placements (e.g. 100m and 60m) that used to perform outstandingly but I cannot change the connection latency.

people are complaining about the effects while the status of this HIP is approved and not deployed.
So is it deployed by now and status tracking is out of date or is it still in the pipeline and when will it arrive?

people are complaining about the effects while the status of this HIP is approved and not deployed.
So is it deployed by now and status tracking is out of date or is it still in the pipeline and when will it arrive?

It's live, been live for a few days now, it went live the day after the hip vote ended.

@FieserKiller
I actually thought that had been updated.
Yes it is active, I will create a change request for that to be updated.

So HIP 83 can and should be good.

@Blue-S0ul how's your London hotspot performing now that this change has been implemented, out of interest.

I already invested a lot on my setup and location to reach max possible hotspots so I ended up having very bad ROI. Each time I say fine, we are hear to support the project espicially in the initial phase. But each time I feel more none is caring about us, people who invested a lot for a good network coverage. After this HIP my rewards reduced to half. Do u know why? This is because I've chosen the location carefully for best coverage and didn't conecntrate on the internet connection. And now who has normal location but good internet connection are being higher rewarded. Frustrating :-/

This is my neighbour, from 300-400 meters away in a saturated urban area: 10x times increase!

Mine was mining around 450-500, now it mines 5x lower, ie around 120-140

HIP 83 was approved by the community on 12th July 2023 with a passing rate of 70.3%
https://realms.heliumvote.com/dao/iot/proposal/H5mGJg9927DBRr1NH64VVk6hoSTJdnAC5kngGxgvumUS

Honestly, I find the voting system unfair as one wallet has 25% of the whole votig power! The community is not only who is holding the currency but also who is participating in the network as well. This part of the community has been always neglected in the Helium voting system :-/

Honestly, I find the voting system unfair as one wallet has 25% of the whole votig power! The community is not only who is holding the currency but also who is participating in the network as well. This part of the community has been always neglected in the Helium voting system :-/ Moreover, can you please give us one example of a HIP had not passed in the authority (sorry "the cummunity") voting system?

Yes, just like anything else in the world, who has the more money pulls the strings...
i just manage to get my lattency under 2ms, and still i am far away from my previous rewards..

And what would be your proposed solution? This has been discussed ad infinitum on the Helium Discord. The one alternative proposal that keeps coming up is "one hotspot one vote", and all that would do is give control of the Helium network to hotspot hosting companies and/or anyone willing to buy up a large quantity of hotspots.
It's easy to point out problems and difficult to propose a good solution that doesn't cause more problems than it causes.

@RuDee-BG
HIPs 72,80 and 81 all failed to be voted in, see
https://github.com/helium/HIP/blob/main/README.md
Usually HIPs go up to vote because we think they will pass or we don't know if they will pass or fail. Its unlikely we will put forward to vote HIPs we think will fail to get passed. Usually the evidence they would fail is apparent.
HIP 72 and 83 were both unknowns.
Most bad ideas that probably would fail don't get as far as the voting stake, some are withdrawn as a newer "better" HIP is released eg HIP 78 was replaced with 80/81 and they were replaced with 88/89
There is already a proposal to change this HIP and another proposal to enable hotspots to compete on a more level speed and response time.

Most bad ideas that probably would fail don't get as far as the voting stake, some are withdrawn as a newer "better" HIP is released eg HIP 78 was replaced with 80/81 and they were replaced with 88/89
There is already a proposal to change this HIP and another proposal to enable hotspots to compete on a more level speed and response time.

So should someone have introduced a HIP better than this one, earlier? Who's responsible for doing this? Numerous people, myself included, detailed in this github issue what was going to happen when this HIP went live, but were essentially ignored. We don't all have time to be writing better HIPs.

Most bad ideas that probably would fail don't get as far as the voting stake, some are withdrawn as a newer "better" HIP is released eg HIP 78 was replaced with 80/81 and they were replaced with 88/89
There is already a proposal to change this HIP and another proposal to enable hotspots to compete on a more level speed and response time.

So should someone have introduced a HIP better than this one, earlier? Who's responsible for doing this? Numerous people, myself included, detailed in this github issue what was going to happen when this HIP went live, but were essentially ignored. We don't all have time to be writing better HIPs.

I fully agree with your statement. Fortunately i found some hours during my vacations for that and you can take a look on my github on the hip starting XX that is a proposal for having a reception windows.

Hello? Why FreedomFi gateways got banished with this undertested HIP and literally nobody gives a rat's behind?

I have decided to disconnect 12 of my 14 hotspots with very good placements (almost all higher than 30 metres), as the rewards were decreased by 40% (stable internet but latency a bit over 15ms). I am fed up and will not invest any more. I will start dismounting the antennas tomorrow.

I have decided to disconnect 12 of my 14 hotspots with very good placements (almost all higher than 30 metres), as the rewards were decreased by 40% (stable internet but latency a bit over 15ms). I am fed up and will not invest any more. I will start dismounting the antennas tomorrow.

The low latency is really is good, but even thou i manage to get my latency under 2 ms. Have a good hex, and my earnings are 40% still down. The neighbour with super bad hex and ok latency has 10X increase/1000%

@RuDee-BG it could be down to your hardware which is what @Delitants shows in their chart.
This is the reason I am interested in the approach being worked on by @disk91 which avoids these millisecond optimizations that end up being out of the users control to some extent.

@lthiery Well, ur right, but that big of difference?! Between bobcat and kerlink?

I was investigating with my hotspots (different brands) the last 10 days via swapping the locations and I think it's a mix of all.

Internet connection speed.
Internet provider.
Router and connection to router (Wifi/ cable).
Brand of your Hotspot.
At the end still wondering, why would a LoraWan network seek for such a very low latency network!? Are we going to host Gamers in our network!!!?
I agree quicker is better but not at the cost of other aspects like location etc. (Installing a Ferrari engine for a Mini Hatch car won't improve the overal performance)

For folks who haven't been seeing this work, there's an update to the rules of witness selection being worked on here: https://github.com/helium/HIP/pull/749

Basically ALL LoraWAN Applications do not care about latency!
There is a reason for that, it is meant to be low power, not low latency.... Have the authors any idea of LoRa in general? Then they should be aware of the fact that latency is not a problem.

nope they don't, they are just basic skill sensor providers. most of them in the Helium team also think ''amplifiers etc.'' are a method to cheat the network, had you been following Sorin you would see that's not the case of ''cheating'' but rather making your signal, as strong/efficient and clean as possible it can get for the particular area, this way that creates a unique valid coverage.
the Hip 83 doesn't talk anything about selected sensors picking up all of sudden the fast low latency hotspots, it has no methods to do it because they will always pick the low latency ones regardless of who thinks rewarding a particular hotspot more or not.
there are so many red flags in this HIP 83 that you can point anything at and it all leads to centralisation of rewards. nothing about improving anything.

I was investigating with my hotspots (different brands) the last 10 days via swapping the locations and I think it's a mix of all.

Internet connection speed.
Internet provider.
Router and connection to router (Wifi/ cable).
Brand of your Hotspot.
At the end still wondering, why would a LoraWan network seek for such a very low latency network!? Are we going to host Gamers in our network!!!?
I agree quicker is better but not at the cost of other aspects like location/ power consumption/ costs etc. (Installing a Ferrari engine for a Mini Hatch car won't improve the overal performance)

that would all drasticaly change, if they went to their original claims for the originality of the HIP 83 that supposedely claims ''to return to original proof of coverage''
if you go back in time, they had witness selection of 25 HOTSPOTS, yeah read that well, TWENTY FIVE.
the only reason they went to 14 was because the network had problems keeping up with the blockchain and on top too many hotspots were onboard so they had to take measures temporary.
moving forward and we come back to this HIP 83, we see that if they had changed it to 25 selected hotspots on top remove the 200-300ms ECC chip obstacle by the makers, you would see things change dramaticaly for the better.
the HIP 83 was done with no data to test if its good for the network or not, they slapped a heliumgeek map(showing who gets the big juicy pie and who is not ) and called it a day.
yeah -30k hotspots, thats what we got, most of them gone offline in unique coverage areas like rural/suburban.

so who made you the police to what's gonna be voted or not?
since when we allow central figures ''their opinions of what might pass or might fail'' in a democratic voting system?
or don't tell me it isn't democratic but dictatorial in a sense, because that's how it sounds. REDICULOUS.
disk91 does fantastic job trying to modify the fraudelent hip 83 that caused more damage than good.

@waveform06 so who made you the police to what's gonna be voted or not?
since when we allow central figures ''their opinions of what might pass or might fail'' in a democratic voting system?
or don't tell me it isn't democratic but dictatorial in a sense, because that's how it sounds. REDICULOUS.
disk91 does fantastic job trying to modify the fraudelent hip 83 that caused more damage than good.

@HeliosHyperion1111
Police don't decide what is to be voted on, I don't decide what will or wont.
I am doing some governance admin though.
We do straw polls of people and we take advice of experts, as I said there is no point sending thru a HIP to vote that the community thinks will fail to pass or is impossible/illegal to implement. If the HIP author cannot persuade a few community members how can they persuade a majority?
HIP 83 moved what people like Sorin (https://www.youtube.com/watch?v=BRO7ziKL7-U) called "Proof of Luck" back to a form of "Proof of Coverage", Disk91's proposal looks to modify that to a mix of both scenarios.

yes Sorin did say its proof of luck, but the way the network was back then, had 25 witnesses not 14 and surely didn't implement so strict latency selection of the witnesses like HIP 83 does.
in fact back then it was much more balanced/fair because the witnessing was more focused to the RF signal itself rather the latency.
and we didn't have oracles to tell us who is fast and who is not.

Coincidence or pure luck...just not fair. My hotspot is the unlucky one, the other one i can see from my balcony ...
Yeah, just bad luck.

A fix has been found!~
All will be right again soon!~
All thanks to  @mawdegroot  @nosmaster89

A fix has been found!~ All will be right again soon!~ All thanks to @mawdegroot @nosmaster89

What's found? Where is it?

???

A fix has been found!~ All will be right again soon!~ All thanks to @mawdegroot @nosmaster89

What's found? Where is it?

i guess nothing has been found, looks like this guy is biased towards groot who is so against these fair changes.

Several changes to the code have significantly improved the signing speed for the majority of makers. In preliminary testing the majority of makers now show a very similar signing performance. These changes will be included in the new gateway-rs v1.1.0 release which has been released to makers for testing. The new gateway-rs release will also include session keys which will significantly increase data transfer throughput and should free up time on the ECC chip for further improvements in high traffic areas.

Several changes to the code have significantly improved the signing speed for the majority of makers. In preliminary testing the majority of makers now show a very similar signing performance. These changes will be included in the new gateway-rs v1.1.0 release which has been released to makers for testing. The new gateway-rs release will also include session keys which will significantly increase data transfer throughput and should free up time on the ECC chip for further improvements in high traffic areas.

great news, so how about we also open up the 14 only selected witnesses to 25? original choices need original choices not half original half w/e we want.

From past night something have been changed, my witnesses increased and the nearby miners with 3000-4000 iot per day has been decreased from its original state before hip83.
Something is cooking

From past night something have been changed, my witnesses increased and the nearby miners with 3000-4000 iot per day has been decreased from its original state before hip83.
Something is cooking

Nothing has increased at all

Where is the fix?

So far no improvement at all at least for the three miners I own.

I have fiber and I tell you what, it makes ZERO improvement on this HIP. So forget it.On Sep 14, 2023, at 5:17 AM, HeliosHyperion1111 @.***> wrote:
So far no improvement at all at least for the three miners I own.
same, feels like i have to wait for fiber infrastructure for my area to buy one program, all thanks to the number 1 culprit who pushed the hip 83 that was not needed. did more damage to the network than good, usage is dogsht. i look everyday the usage and its nowhere near what those pump n dump flactuations happened before the halving, seems like it was all just cuz of price volatility nothing else.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I have fiber and I tell you what, it makes ZERO improvement on this HIP. So forget waiting for it.

do u have the fiber cable connected straight into the hotspot? have you tried that? cuz i think that will fix majority of the latency.
also to add, switch DNS. <IP_ADDRESS> is by far the lowest latency that gives me.

I have fiber and I tell you what, it makes ZERO improvement on this HIP. So forget waiting for it.

do u have the fiber cable connected straight into the hotspot? have you tried that? cuz i think that will fix majority of the latency. also to add, switch DNS. <IP_ADDRESS> is by far the lowest latency that gives me.

Fiber is connected to my router. You can't stick a fiber in the hotspot directly. Whatever they done here in this HIP is suppresses certain brands of the hotspots, especially those which have 5G function like FreedomFI.  So far nothing changed

there is a way, if you do POE you can basicaly use 2 fiber cables, 1 for electricity and 1 for internet, converted into a POE with a male into female (ethernet) adaptor or w/e its called u know what i mean

I have fiber and I tell you what, it makes ZERO improvement on this HIP. So forget waiting for it.

do u have the fiber cable connected straight into the hotspot? have you tried that? cuz i think that will fix majority of the latency. also to add, switch DNS. <IP_ADDRESS> is by far the lowest latency that gives me.

Fiber is connected to my router. You can't stick a fiber in the hotspot directly. Whatever they done here in this HIP is suppresses certain brands of the hotspots, especially those which have 5G function like FreedomFI.  So far nothing changed

there is a way, if you do POE you can basicaly use 2 fiber cables, 1 for electricity and 1 for internet, converted into a POE with a male into female (ethernet) adaptor or w/e its called u know what i mean

You don't make any sense. PoE has nothing to do with fiber. And fiber at home is usually PON, which is locked to provider's ONT. You can't just plug it in wherever you want.

@HeliosHyperion1111 @RuDee-BG @Delitants
Have you taken a look at https://github.com/helium/HIP/blob/main/0094-response-time-windows-for-witness-rewarding.md
https://discord.com/channels/404106811252408320/1144746781071130795

@HeliosHyperion1111 @RuDee-BG @Delitants Have you taken a look at https://github.com/helium/HIP/blob/main/0094-response-time-windows-for-witness-rewarding.md https://discord.com/channels/404106811252408320/1144746781071130795

yeah i wait for this HIP to be released, but for the time being we all try to find a way to reduce our latency, most people don't find any other way other than upgrading to fiber network with fiber lines connected straight to our hotspots, most think you need the antenna as high as possible, well mine is at the highest point in the outskirts of the capital( omni directional ) in case some think that i have a directional ''stealing'' all the rewards. this HIP 83 has impacted my hotspot significantly cuz i provide very good coverage, i connect the capital city, with islands on the south + 1 small port city behind me and 1 small sub urban town on the north, and guess what? i got punished for it! haha thanks to HIP 83.

@waveform06 What’s completed?  There is nothing changed.

@waveform06 What’s completed?  There is nothing changed.

poc ingest streams will go live shortly which will help with security chip performance across all hotspots, including the FF hotspots because of the use of session keys
a FF update will include this gateway-rs upgrade as well as a faster security chip (TPM) interface

@Delitants Its completed in the sense that the HIP process is complete.
Its now down to the hotspot vendors to improve their products response times and the core-devs to make any improvements to the system to provide an even playing field where possible for all vendors.
https://github.com/helium/HIP/issues/764 is an alternative that is being evaluated

I’m seeing a 200% increase today, looks like it’s getting back to normal. Thanks!On Oct 24, 2023, at 2:16 AM, Adrian @.***> wrote:
@Delitants Its completed in the sense that the HIP process is complete.
Its now down to the hotspot vendors to improve their products response times and the core-devs to make any improvements to the system to provide an even playing field where possible for all vendors.
#764 is an alternative that is being evaluated
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


implementing prior bounding boxes as keras layers?

is there any particular reason to implement the bounding box priors as a layer in the keras model?  if i'm reading this correctly, it only ever gets used again during post-processing of the prediction.  is it to 'auto-configure' the priors based on input size etc... by detecting input from previous layer?
j

@BenMacKenzie yep, it's for auto-configuring priors based on a layers' outputs.

Make PriorBox a keras layer, will it compute input gradient in backward?


Avoid allocations in string.IsNullOrWhitespace calls

We were doing some browser memory profiling / optimisation here and saw the following numbers that surprised us:

.. it didn't seem like "isNullOrWhiteSpace" should be something that should allocate if it's just comparing a string using a reg ex - the reason looks to be because the reg ex is instantiated for every call, rather than being created once and reused.
The reg ex in question is in System.Char and I noticed the pattern in some other methods in there, so I changed them all.
I've used the Runner project to execute the unit tests in the browser and 12 failures are reported but the same failure were reported before my changes.

I thought that I should add some more info in case you want to confirm the impact of the changes. If I run the following JS:
setTimeout(
	function () {
		console.log("Starting..");
		var s = "abc";
		for (var i = 0; i < 1000000; i++) {
			System.String.isNullOrWhiteSpace(s);
		}
		console.log("DONE!");
	},
	3000
);

.. and use the "start recording heap profile" functionality in Chrome's Memory tab then before the changes the results look like this:

After the changes, the results look like this:

Hello @ProductiveRage, have you used private/proprietary tooling to extract these results? I don't seem to find a view like your screenshots in either chrome or firefox developer tools.
I've logged issue #4036 and am cross-pointing issue and pull requests -- so that this gets to changelog when merged upstream.
Thanks for the finding and contribution!

Sorry, I didn't leave the most detailed instructions there!
I used Chrome. In the Dev Tools, there is a Memory tab. In that, I selected "Allocation instrumentation on timeline" and checked the "Record allocation stacks (extra performance overhead)" option. Then I reloaded the page and pressed the record button at the top left of the Memory tab and waited for the page to do its work (I went to the Console tab and waited for the "DONE!" message). Then I went back into the Memory tab and clicked the record button again to stop the recording.
This produces a snapshot. The default view is "Summary", which I changed to "Allocation" to see the information attached to this case.

Got it, thanks for the quick howto! :)

Hi! I'm closing your pull request.
But falter not, I've cherry picked your commit, and squashed your second commit with also another change from myself in which we turned the $<variable> local variables you created into _<variable>.
The commits rebuild to keep a clean history, and the variable renaming to keep using the conventions I've seen around in other js files within Bridge/resources directory.


fading_child_animation_perf__timeline_summary 99th_percentile_frame_build_time_millis regression

Looks like it went up at https://github.com/flutter/flutter/pull/58230.

@flar Could this be related to https://github.com/flutter/engine/pull/17914?

We saw this in local testing, but went with the fix for several reasons:

The red you see there is an anomaly in the first place. The benchmark has so much noise that the thresholds were a compromise. Really we need to understand why it varies by more than 2x on a run to run basis and then once we discover that we should rebaseline to match. The existing baselines were chosen to just keep it from being red even though what we really care about is the shorter bars which may have taken a hit as well, but it is hard to tell from this data. We could rebaseline again to just apply a bandaid to keep the graph from going red.

The slight regression here is offset by a bigger gain in the average and 90% rasterizer times which was the point of the fix.

The fix was entirely in the C++ code of the engine which shouldn't have affected the build times at all, but since the build occasionally makes native calls there could be side effects.

@flar since it sounds like this was intentional after evaluating the trade-offs, I'm going to remove the TODAY label, and drop the priority down, but leave the issue open to investigate the benchmark behavior. Could you rebaseline it to something reasonable in the meantime? Thanks!

@zanderso I rebased shortly after writing that comment and consulting with @liyuqian. The new baselines should be visible on the benchmark dashboard now.

Note these related improvements in the average and 90% frame rasterization times:

Thanks @flar for the rebaseline! Closing this issue now.


Post release fixes

Minor changes after the 1.5.1 release.

Codecov Report

Merging #46 (6a9268d) into master (183784d) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##           master      #46   +/-   ##
=======================================
  Coverage   96.55%   96.56%
=======================================
  Files           5        5
  Lines         377      378    +1
=======================================
+ Hits          364      365    +1
  Misses         13       13

Flag
Coverage Δ

unittests
96.56% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pygitguardian/__init__.py
100.00% <100.00%> (ø)

pygitguardian/client.py
91.24% <100.00%> (+0.06%)
:arrow_up:

pygitguardian/models.py
99.50% <100.00%> (ø)

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


upgrade node and npm in Dockerfile

The Copyright Check has failed!
The files listed below do not have a valid copyright statement:

version


How to debug Hygieia ?

Hello all,
I've successfully set up Hygieia. Thanks.Now, I'd like to debug Hygieia from the controller to Angular. Please can someone advise how to start the server in debug mode and how to configure debugger in eclipse please ?

if you are using some IDE, you can launch API module as Java Application giving command arguments for properties name and location (same command that is used for running API module from console). For Angular, you can take help of developer tools in browser.

Hi. I am using the ide:-STS for  Hygieia. I can run the application from command prompt successfully, But I wanted to debug from ide aswel. I tried debug as ->java application, but cudnt do it, as it is looking for a main-class.
@nitin1706.  could you please elaborate the step, if possible with a screenshot?


[SPARK-46012][CORE][FOLLOWUP] Invoke fs.listStatus once and reuse the result

What changes were proposed in this pull request?
This PR is a follow-up of #43914 and aims to invoke fs.listStatus once and reuse the result.
Why are the changes needed?
This will prevent the increase of the number of listStatus invocation .
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass the CIs with the existing test case.
Was this patch authored or co-authored using generative AI tooling?
No.

Thank you, @yaooqinn !

Merged to master/3.5/3.4/3.3.

late LGTM

Thanks for fixing this @dongjoon-hyun  !


chore: qe-tools moved to konflux-ci org

Description
update the org of qe-tools repo to konflux-ci
Issue ticket number and link
Type of change

[X] chore

How Has This Been Tested?
❯ gh release download v0.1.0 -R konflux-ci/qe-tools
❯ echo $?
0

/lgtm


Only log k8s connection exceptions if they persist for 1 minute

It's not uncommon for k8s watch exceptions to occur since it uses long
polling and the connection can get interrupted. Only log an error if
this persists for a minute.

not sure how to test this, since the k8s client is not an interface and difficult to mock :(


Return control flow separately from branch instructions

This gives access to the value even when branching multiple times, such as selectNearest which has 3 branches and a return value

Perhaps the old syntax is preferable when the instruction only has two branches. Please let me know what you think.

I realized that if #44 were to be merged, we would likely also be able to support syntax like this instead, which might be the best of both worlds:
declare function selectNearest(unit_a: Value, unit_b: Value): Value & ("next" | "A" | "B");

function test(p1: Value, p2: Value) {
    const nearest = selectNearest(p1, p2);
    switch(nearest) {
        case "A":
            notify("A", nearest);
            break;
        case "B":
            notify("B", nearest);
            break;
        case "next":
            notify("Next");
            break;
    }
}

@ribrdb Please disregard my previous comment. I think this implementation is the best it's going to get:
export function foo(v:Value) {
    let [branch, nearest] = selectNearest(v, signal);
    switch(branch) {
        case "A":
            notify("A is closest", nearest);
            break;
        case "B":
            notify("B is closest", nearest);
            break;
        default:
            notify("Default branch");
            break;
    }
}

We should probably also add another override that only returns the nearest entity without the branching value.

Adding an overload would require naming the two functions differently, since they have different return types. Easy enough to do via an override, but do you have a suggestion for the naming? I suppose selectNearest and selectNearestBranch could work, but personally I don't think this is all that confusing or unnatural.
Perhaps it would help if the control flow argument came last? That way the user could write the following when they are not interested in the control flow argument:
let [nearest] = selectNearest(a, b);

We should probably also add another override that only returns the nearest entity without the branching value.

Adding an overload would require naming the two functions differently, since they have the same arguments but different return types. Easy enough to do via an override, but do you have a suggestion for the naming? I suppose selectNearest and selectNearestBranch could work, but personally I don't think this is all that more clear than just having a single function that returns an array, which other functions do as well.

How about closest(a,b) to just return the nearest value, and selectNearest to return both? That naming matches the dom api, so might be more familiar to js users. I guess we could also just have nearest and selectNearest.

Perhaps it would help if the control flow argument came last? That way the user could write the following when they are not interested in the control flow argument:
let [nearest] = selectNearest(a, b);

Thanks for taking a look!

What's weird about this function is that it's basically returning the data in two different formats. That kind of makes sense in the visual programming environment, although it's also pretty different from every other Desynced instruction. I can't think of any commonly used function in any standard programming language that returns a single value in multiple formats like that, and it seems to me that the typical use case is that you want one or the other. So needing to add brackets to get out a single value still feels awkward.
That said, I don't think figuring out the other variant needs to block this pr.

How about closest(a,b) to just return the nearest value, and selectNearest to return both? That naming matches the dom api, so might be more familiar to js users. I guess we could also just have nearest and selectNearest.

These names are fine in principle, but personally I'd prefer for the desynced instruction names to somewhat resemble the in-game instruction names. I assume most users come from manually programming behaviors, and thus will be looking for those names as functions. It would also be awkward if the game ever did introduce a closest instruction for something else (I'm not sure what, but it could happen)
What about:
declare function selectNearest(unit_a: Value, unit_b: Value): ["next" | "A" | "B", Value];
declare function selectNearestEntity(unit_a: Value, unit_b: Value): Value;

interface BaseValue {
  isNearer(other: Value): boolean;
}

This would let selectNearest match the game behavior, as it does in the PR currently. It would also introduce two ergonomic functions: selectNearestEntity, which simply returns the closest of the two and the Value method isNearer which returns a boolean where true maps to the A branch, and false to B and None.

That said, I don't think figuring out the other variant needs to block this pr.

If you agree with the above, I would indeed like to merge this PR now and introduce selectNearestEntity and isNearer in a future PR.

What's weird about this function is that it's basically returning the data in two different formats. That kind of makes sense in the visual programming environment, although it's also pretty different from every other Desynced instruction

I understand the feeling, and while it's true this is the only current instruction the game has that behaves this way, it would not surprise me at all if more appeared in the future. The behavior engine is fine with any instruction having an arbitrary number of variables and outputs.
But yes, it's unusual. It is also the target of the compiler, and especially considering that I'd love to add support for modded instructions at some point, it would be good to be able to support as much of the behavior engine as possible.

I can't think of any commonly used function in any standard programming language that returns a single value in multiple formats like that, and it seems to me that the typical use case is that you want one or the other

Me neither, but I don't see desynced-tools as a general purpose programming language. I see it as a DSL to generate Desynced behaviors, so I'm willing to tolerate a bit of weirdness.

What about:
declare function selectNearest(unit_a: Value, unit_b: Value): ["next" | "A" | "B", Value];
declare function selectNearestEntity(unit_a: Value, unit_b: Value): Value;

interface BaseValue {
  isNearer(other: Value): boolean;
}

That looks good. Is there a reason you prefer isNearer over the current nearerThan?

If you agree with the above, I would indeed like to merge this PR now and introduce selectNearestEntity and isNearer in a future PR.
👍

Me neither, but I don't see desynced-tools as a general purpose programming language. I see it as a DSL to generate Desynced behaviors, so I'm willing to tolerate a bit of weirdness.

I guess. But I feel like since we're already running a compiler that does optimizations, we should let the compiler worry about the exactly which instructions get output and the "dsl" just expresses the ideas as naturally as possible. But mods is a good point, that's not really feasible to do when you consider mod instructions.

Is there a reason you prefer isNearer over the current nearerThan?

Not really, either is fine with me. I typically call functions that return a boolean is, and perhaps it could be confusing if the same function exists both in the global namespace and as a method on a Value, but I don't mind.

I guess. But I feel like since we're already running a compiler that does optimizations, we should let the compiler worry about the exactly which instructions get output and the "dsl" just expresses the ideas as naturally as possible.

Fair point. Onboarding is somewhat of a concern, but some good examples can solve that.

Sorry, I completely blanked on the fact that nearerThan already exists in the global scope. It had been a while since I worked on this PR :D
That method is fine, but I do feel it would perhaps be more natural to write if(a.isNearer(b)), but either is fine.


Remove entryPoint if not required

See https://github.com/gpuweb/gpuweb/pull/4387/
⚠ Do not merge this PR until Chrome 121 reaches stable channel.

FYI @jimblandy @mwyrzykowski this will simplify samples a bit but will require entryPoint name defaulting.

Converting to draft to make the PR harder to accidentally merge.

We can now merge it as Chrome 121 is stable.

ps: Firefox still requires entryPoint as of nightly 124.0a1 (2024-01-25) (64-bit)
@kdashg @jimblandy

So, we agree this is a sweet readability hack, and would like to see it deployed in the examples - but since it will break Firefox, we would like to wait to merge this PR until https://github.com/gfx-rs/wgpu/issues/5145 is closed.

Note that we need both https://github.com/gfx-rs/wgpu/issues/5145 (the wgpu-side work) and Bugzilla Bug 1877488 (the Firefox bindings work) fixed before Firefox will be able to handle omitted entry point names. @erichdongubler is actively working on these.

Firefox Nightly now handles omitted entry point names (I've checked locally).
Since Safari Tech Preview and Chrome also handle them properly, I believe we can now merge this PR.
Note that I've just rebased it due to merging conflicts.

As the person who worked on this support in Firefox, I'm excited to see this land. 😁

I've had to update the PR again. Please review and merge ;)

@kainino0x Can you merge?

I'll merge


Fix ONES not defined error in clifford benchmarking

Resolves #623

ZEROS are the new ONES

Oops. Maybe I should have finished my coffee before committing


Release Request

Sorry for the request, but might you finish another minor release in the near future? I know, not that much changed since December 2016, but Request #384 fixes an ugly bug in ownCloud and Nextcloud (https://github.com/nextcloud/contacts/issues/206) and some of us'd like to see that fix being applied there, too. Thanks and much appreciation.

In case you PR a proper changelog I might find time to merge and tag something