Portal: Bulk Delete Configuration

How does one delete config keys in bulk? Or clear/reset the entire config store?
I tried importing a blank file but it did not work.
Can we have a documented way to do this either via portal or REST API?

Thanks for the feedback @Abhra1992.
You can use Azure CLI (install with az extension add -n appconfig) to delete in bulk. For example, the command below clear the entire config store.
az appconfig kv delete --name [YourConfigStoreName] --key * --label *

You can use --key and --label parameters to filter a subset of key-values you want to delete.
The Azure portal currently does not provide a way to delete key-values in bulk.

Is this something planned to be in UI? e.g. Checkboxes to select what I would like to delete?

Not planned, but we could if people find it useful to have the bulk deletion in the portal too.

Yes, it is difficult to say in the early stage if this is going to be desired. I am learning how this App Configuration works so I am adding and deleting. But once I learnt/set it up all as I want then probably I might not bother about deleting too much.
However, in this case I saw in App Service that you can edit All by clicking on Advanced Edit which opens configuration in json editor, so I could do bulk updates and bulk delete there :)
So maybe it makes sense to have also here Advance Edit? :)

Just tried the service and find out there is no bulk delete feature. You should really consider bulk delete and bulk edit in order to make config management easier.
You should also let the user to edit all configs via json editor which is already available in webapp configuration page (advanced edit like below).

It would be very useful to have a bulk-delete option. Having not known the CLI command before this post, I had to delete the entire store to start over.

It would be very useful to have a bulk-delete option. Having not known the CLI command before this post, I had to delete the entire store to start over.

Same situation, any kind of bulk operations would be useful like bulk delete or add a label for all records, currently, you have to add labels manually on each record or rely on import/export functionality which is not always helpful.

Thanks for the feedback @Abhra1992.
You can use Azure CLI (install with az extension add -n appconfig) to delete in bulk. For example, the command below clear the entire config store.
az appconfig kv delete --name [YourConfigStoreName] --key * --label *

You can use --key and --label parameters to filter a subset of key-values you want to delete.
The Azure portal currently does not provide a way to delete key-values in bulk.

Trying this in the azure cloud cli and I get this very strange error:

UnrecognizedArgumentError: unrecognized arguments: nginx.conf

@avanigupta is what @crhistianramirez reported expected?

Hello @crhistianramirez, thanks for bringing this to our attention. This issue is confined to only Azure Cloud Shell and we are working with them to resolve this. Meanwhile, you can install any local Azure CLI client to run the bulk delete command:
az appconfig kv delete --name [YourConfigStoreName] --key * --label *

Any news on the development of this feature? it's been sat in planned for quite some time now?

I think this functionality should be available in the UI. Seems pretty UX-unfriendly at least for me...

We have included the bulk delete functionality in the UI in the latest Portal version. Please give it a try and feel free to reach out in case of anything.

Nice, Yeah I have the checkboxes :) Happy Days

Such a great feature! This will be heavily used in environments, especially like dev where configuration may change drastically.

Well done guys. It's very nice to see that this feature is implemented almost after 3 years 👍 better late than never 😁


delete debug output; fixed style

I fixed up some conflicts.  Putting it into master now.

I fixed some conflicts too. Why did you merge master to my branch?


meta fields are lost after importing

Describe the bug
We are importing our tasks using pre-annotated data and we are including some metadata on meta field which is a dictionary with two string values. On the original file we have this meta field with data, but after importing if we export or look on the Target Storage we see that the meta field is empty.
To Reproduce
Steps to reproduce the behavior:

Import JSON task/s with some data in meta field
Export data as JSON file

Expected behavior
There should appear the metadata information on the exported file
Environment (please complete the following information):

OS: Linux
Most updated Label Studio Version from pip install

@lluissalord Where do you place meta ? In a task or in a prediction?
I recommend to put meta in a task.data:
{
 data: {
  meta: { ... }
 },
 predictions: [{...}]
}

@makseq I place the meta at task level as it is specified on the API https://labelstud.io/api#tag/Tasks
{
 data: {
   text: "",
 },
 predictions: [{...}]
 meta: { ... }
}

I understand that inside task.data will work because that field is intent to remain, however I would recommend to fix the issue or modify the API in order to not confuse.

@lluissalord Thank you for your feedback, I hope we remove it soon.

@lluissalord Just checked this issue, in the latest master the export json file contains meta field with all subfields. However, we will remove meta from task in the future.
https://github.com/heartexlabs/label-studio/pull/1307


Add a new storage format - ORC

Pull request for new storage format - ORC of Data Factory.
Already done ship room, Server side capability is already deployed on prod, All backend/schema/EC is already checked in and waiting for next deploy.

Can one of the admins verify this patch?

Hi @melode11, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (yuxyao). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

@azuresdkci add to whitelist


Add support for yarn-berry lockfiles

Added support for parsing yarn-berry lockfiles (they are pure yaml).
We can no longer look up dependencies by package@version because berry adds additional things like a protocol (e.g. package@protocol:version), so there's now a regex (with tests) that strips out the protocol.
An argument could be made that this should be a separate command, like npm and yarn. Let me know what feels best.
Also, maybe this could be a berry plugin? I'm not sure what the capabilities are.

Been a whike since i looked into berry, but yes i think it can be solved to some degree with config instead, although at potentially higher maintenance cost.
Btw, have you looked into this package that seems to support both formats? https://www.npmjs.com/package/@yarnpkg/parsers

That works even better, good idea!

@mikeduminy Need to update lock file too.

@oblador done


Upload code coverage reports using the Codecov GitHub Action

Summary
This PR replaces the codecov package, which has been deprecated, with the Codecov GitHub Action to hopefully report the uploaded coverage statuses.
Requirements

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

@filmaj Totally right that we're uploading reports for each version! Honestly not sure what coverage was being reported with this, so nice catch.
Updated this to only upload with the latest version as I agree this is a good call. Tests will still pass or fail on any version, and coverage should be similar between versions, but no more uploading coverage for each version!


Option to list rendering backends

would need to use --rendering-backends-list (plural) to match --readers-list and --bindings-list
However I believe the singular is grammatically correct so the other 2 would need to change instead/eventually?


Linxiao/vsl 48 adding test

added TestTransferNonFungibleTokensToAccountActions test block, including

proposing an action that transfers NFT from treasury to account
singers sign the action
executing the action

closing this PR because I've applied the changes to the quantstamp branch quantstamp-audit/VSL-56_QSP-3


Testing newer version of crayon

travis is failing on testthat install, trying to install crayon first so it's more up to date than mran version

Coverage remained the same at 98.82% when pulling 4e3c41b3490a3419e3fad00ba9ee406e31bdec30 on mhines-usgs-patch-3 into 75419b07e050bb26e6e1a23acbe95235ded7f0af on master.


Implement space-time resource step 1 functionality

This involves

Settle the resource content model. This implies specification of the name for the resource type and documentation of the storage format. The detail of the documentation is case specific. Specify the scientific metadata.
Add capability to upload and download resource files that are already in the specified storage format through web interface. Edit metadata through web interface. Serialize metadata.
An assumption here is that a space-time resource will involve only one content file in netCDF format. The step 2 capability handles that raw file and may parse metadata out of it but does not support loading of entire resources in the bagit packaging format.

Phase 2 and beyond are not part of this step and include the following that should be incrementally added later

Tools for creating the ncdump text file and show the text info in resource landing page.
Tools for data subsetting and create new netcdf file
Tools for metadata editing in netcdf file based on core and extended metadata
Add capability to upload and download resource files already is specified storage format through API. Set and get metadata through API.
Visualization tool
Tools for importing from other formats (e.g. XML or CDL representations)
Tools for exporting to other formats (e.g. CSV or time series of a time series at a single cell "rod")
Tools for establishing a web service endpoint to serve this resource content (e.g. THREDDS)
Tool to import resource packages as a complete resource data model bag. This involves a reflector function to generate the metadata in Django from the XML format metadata and will support direct exchange of this resource type with iRODS and with other clients.

We now have the Multidimensional (NetCDF) Resource


Allow subclasses with no properties

As it is now, when trying to generate a class without properties, it is simply skipped.
In our project we have a schema as follows:
{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title": "SensorModule",
  "javaType": "dk...SensorModule",
  "extends": { "$ref": "datamodule.schema.json" },
  "properties": {
    "empty": { "type": "string", "description": "This is a hack to force class to be generated" }
  },
  "additionalProperties": false
}

Where we've added a dummy-property to force generation. Without the "empty" property, it is skipped by the generator.

This should work, you just need "type": "object"in your schema.

Oh, thanks, will try this tomorrow. :+1:


Prevent the android bubble saying "swipe down from the top to exit full screen"

I'd like to prevent that android bubble saying "swipe down from the top to exit full screen" that appears when in immersive or full screen modes. My goal is to have that bubble not appear.
I tried this plugin, and unfortunately the bubble still appears (only once though, but I want it prevented always). My game can start non-immersive and non-full screen, whatever it takes to get that bubble to not appear.  I wonder if the cause is the splash screen setting fullscreen = true.
Would it be possible to adapt this plug-in to prevent that bubble appearing? I thought the plugin was going to work, because it clears all the immersive/full screen flags.
Many thanks, Kevin.

Do I understand this correctly:

You are using the plugin to show the status bar on KitKat+ devices
You added Screen.fullScreen = false; to your scripts
You still see an immersive mode popup?
What device are you using?
Need some more details.

The reminder bubble is a security mechanism built into Android to prevent other apps from "mimicking" the system interface, and you can't disable it on a standard Android. There are options to get rid of it on custom ROMs though.
More details:
http://android.stackexchange.com/questions/113333/is-there-a-way-to-block-the-immersive-mode-prompt-swipe-down-from-the-top-to-ex
http://stackoverflow.com/questions/20075041/immersive-mode-instructions-reappear-every-time-the-device-enters-this-mode

You are using the plugin to show the status bar on KitKat+ devices

Yes (although this behaviour happens both with and without the plugin there)

You added Screen.fullScreen = false; to your scripts

Yes

You still see an immersive mode popup?

Yes, but only once the first time the app is ever run.  If the popup is dismissed just once by pressing OK then it never appears again, even if device powered off/on.  It takes an uninstall to cause it to appear again.
I am wondering, is it the Unity Splash Screen that is sending a "full screen = true" and triggering the OS to issue the message. If I buy a license for Plus, and disable the splash screen entirely, and just have "full screen = false" in my script, might that make the message go away?

What device are you using?

I am testing on an Android Virtual Device via Visual Studio, a Nexus 5 Android 4.4.2 API 19.

And thanks for explanation as to why Android OS issues the message, it makes sense.
I suppose my question can be worded a different way also - how can I deploy a Unity Android application that does NOT go into immersive/full-screen mode, even for a single frame.
I want my app to be non-full screen non-immersive always and not cause that message to be triggered by the OS, even once.
Many thanks for looking into this, Yuri, it is really appreciated.

@KevinSmall just to be sure - what's the Unity version you are using?
This is true that IMMERSIVE flag is set on startup by Unity, so until the Start() method in the script is executed, it stays immersive.
However, when testing, I never saw this bubble notification on any device - maybe it's emulator specific. Will recheck it and let you know.

@Over17 I did some mores testing and got these results:
Unity      Android 5.1.1        Android 4.4.2 API 19
Version    Samsung s5 mini      Nexus 5 Emulator
5.5.0f3       NO BUBBLE             BUBBLE
5.3.4f1       NO BUBBLE             BUBBLE

I know it also shows a bubble on a physical device running 4.4.2.  This makes it look like the Android OS version is also involved, or maybe even the sole cause.  Unfortunately for me my target devices are running 4.4.2 and I can't change that.
When you say that the IMMERSIVE flag is set on startup by Unity, is that in the splash screen part?  So if I were to disable splash screen entirely it might be ok?

Hi @Over17 I have more information on this.
The fix of setting fullscreen = false as soon as the game loads has worked on the actual device running Android 4.4.4, so there is NO BUBBLE on the actual device with this fix.
Therefore we can close this issue, as although the problem exists still on my emulators, it does NOT occur on the actual device.  So perhaps it is just an Emulator thing like you said.
Thanks for looking into it.

@KevinSmall thanks for getting back!


Hammer/mutex group table

What's new

simple table showing mutex group information
mechanism to manually unlocking of mutex

Self-checks

[ ] I have prototyped this new feature (if necessary) on Figma
[ ] I'm familiar with and follow this Typescript guideline
[ ] I added unit-tests for new components
[ ] I tried testing edge cases
[ ] I tested the behavior of the components that interact with the backend, with an e2e test

Closing this in favor of https://github.com/open-rmf/rmf-web/pull/933


"Failed to save" dialog with compare option is missing a settings gear/icon/option

When trying to save a file that is older than what's already on disk, VSCode throws up the following error:

However, there is nothing in that error that allows users to search the settings in order to disable this (often unwanted) dialog, and the dialog itself does not offer the usual gear icon to quick-change its settings.
On that note: where are its settings? There should absolutely be a way to disable this "helpful" feature, and there should absolutely be a way for users to find those settings based on the information presented in the dialog (e.g. if the settings for this are something about "dirty files", the dialog should at the very least use those terms so that users can search for those settings themselves)

@bpasero can you please mention which issue this is supposedly a duplicate of? Because I don't see a single one that talks about the fact that this dialog is missing settings and a corresponding settings option.

I already upvoted that one - I can add more details but it doesn't look like anyone even triaged that issue yet? If we're flagging this as duplicate, can that issue be labeled etc.?

@Pomax I can assure you that the issue is not lost if it is still open and was not closed as "out of scope". But we have probably thousands of feature requests that fall into this category, so they may not get a lot of attention in the near term (12-24 months).

Is there a way to sponsor an issue, then?
I don't have time to work on this, but I'll happily pitch in a few donation bucks if it means fixing a workflow-breaking-ly bad bit of UI.

There is a reason the notification appears in the first place and it should absolutely be the exception. If a file has changed on disk while it is open and dirty in VSCode, we alert you that saving will overwrite whatever state there was on disk. If we would not have such an experience, there would be a large number of users complaining that VSCode caused data loss because it just overwrote changes that were made outside of VSCode.
And there is a straight forward flow for getting out of the situation: you compare the changes on disk with yours and click "Overwrite" button to accept them. Does that not work for you?

yes, but this will pop up even when _as the person working on this file, I know my copy is not dirty, and instead something outside of VSCode changed the file on disk and I want what I have open to save.
Having to do a compare view for every one of those files is not "straight forward", it's workflow breakingly annoying, and not even having the option to say "force save" so I can continue instead of interrupt my work really should be base line, not "a nice to have".

yes, but this will pop up even when as the person working on this file, I know my copy is not dirty, and instead something outside of VSCode changed the file on disk and I want what I have open to save.

So how exactly do you get into that state? The file is dirty in VSCode to begin with right? A good option is to enable auto-save in VSCode so that you never get into the state of the working copy in VSCode being out of sync with disk.

Dude, you tell me. If the dialog popping up had anything predictable about it, I wouldn't be complaining about it. VSCode will literally for seemingly no reason at all pop up this dialog, when I'm working on a branch with 100 file changes, and not being able to say "I don't give an f, save my file because I know that nothing else should have touched this while I was working on it" is infuriating when it keeps happening, and I keep not being able to just click "force save".
As for auto-save: no thanks, that interferes too much while running dev/debug tasks that have an "rebuild on file changes" aspect to them (which is quite a few fo the tasks in quite a few of the projects I work on in my day job).
I don't know why I keep getting this dialog, but it's heavily interfering with your work when it pops up without anything happening that should cause it to pop up, and for those people, that "force save" option is critical. It won't make things worse for anyone else, but it will make things better for quite a lot of folks (especially the ones who don't file issues but run into this quite a lot. That's four people in my team alone, at least).


connections only work in debug mode

Since we need to store the connection response codes in order to complete the connection, and we only do that debug mode, people not using debug mode cannot use SlackMC.
Introduced in 1.4.1.

Fixed in 1.4.4.

I had to re-enable debug in order to send messages to Slack in 1.5.0-beta1

That's weird because debug mode was removed in 1.5.0. I'll look into it.

I just searched the code and there was no mention of debug. What happens when you remove the debug-mode line all together?


Use environment variables for trusted certificate store

OpenSSL allows to use SSL_CERT_FILE and SSL_CERT_DIR to point to trusted root CA certificates. This is extremely useful when trying to connect to sites secured with enterprise internal root CA on hosts where one does not manage system certificate store. It would be good to have such possibility with Go as well.

I second this as it would also allow programs to run easier under nontypical environments. I recall seeing issues with nonstandard cert locations on certain NAS devices and similar for example.
I'd be happy to contribute this if it's accepted as an idea.

Duplicate, merged into #14311.


Add breadcrumbs

Signed-off-by: HichamELBSI<EMAIL_ADDRESS>Add breadcrumbs
Description
This is a draft for the breadcrumbs component. Let's check the API before going forward 😄
Demo
Example on : https://design-system-git-breadcrumbs-strapijs.vercel.app/?path=/story/breadcrumbs--base
API
<Breadcrumbs>
   <BreadCrumbItem>Home</BreadCrumbItem>
   <BreadCrumbItem>first</BreadCrumbItem>
   <BreadCrumbItem>second</BreadCrumbItem>
</Breadcrumbs>

Screenshot

@mfrachet Do you think Crumb will be understandable for the DS users? I understand the logic behind it anyway 👍🏽 .
@soupette any thoughts on this?

I let you decide, I kinda like Crumb

I'm having one concern concerning navigating with a screen reader. The breadcrumb itself does not mean anything significant in term of experience. I mean, what information does it provide to the user? Right now, it's "just" a list of items with no meaning at all.
What kind of information should this non-navigable breadcrumb provide to the users? (this is not a question specifically targetting @HichamELBSI but the broader team cc @rgesulfo @maevalienard @soupette )

I'm having one concern concerning navigating with a screen reader. The breadcrumb itself does not mean anything significant in term of experience. I mean, what information does it provide to the user? Right now, it's "just" a list of items with no meaning at all.
What kind of information should this non-navigable breadcrumb provide to the users? (this is not a question specifically targetting @HichamELBSI but the broader team cc @rgesulfo @maevalienard @soupette )

I don't really know what to answer to be honest, I agree that it does not mean anything in term of experience.


Revert .yamllint to match lineage; fix issues flagged by yamllint.

🗣 Description

Remove duplicate github-actions entry and commented out code from dependabot.yml
Revert .yamllint changes made in PR #5
Fix all issues flagged by the pre-commit hook, yamllint

Fix lines that are too long
Add --- to beginning of all *.yml files
Remove extra spaces in brackets

Refactor yml files for consistency.

Remove quotes from strings unless needed
Convert double quotes to single quotes when possible (single quotes don't process escape characters like "\n")

Convert .eslintrc files to pure yaml
Remove steps from .github/workflows/build.yml related to Packer and Go formatting.

💭 Motivation and context
Closes issue #26

🧪 Testing
All  jest tests pass.
Running npx eslint --print-config .eslintrc.yml before and after my changes produces the same output.
Run pre-commit locally to test: pre-commit yamllint --all-files
To setup pre-commit, run ./setup-env.
If it fails to run, follow the instructions returned in the console. This includes installing pyenv pyenv-virtualenv, and adding its path to .zhrc.
To run the check-case-conflict hook, run pre-commit run check-case-conflict --all-files.
To run a different hook, replace check-case-conflict with the name of the hook. The list of available hooks is in .pre-commit-config.yaml

✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] All future TODOs are captured in issues, which are referenced
in code comments.
[x] All relevant type-of-change labels have been added.
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[x] All relevant repo and/or project documentation has been updated
to reflect the changes in this PR.
[ ] Tests have been added and/or modified to cover the changes in this PR.
[ ] All new and existing tests pass.

✅ Pre-merge checklist

[ ] Revert dependencies to default branches.
[ ] Finalize version.

✅ Post-merge checklist

[ ] Create a release.

What would it take to get to the point where this PR shows the GitHub "build / lint" action passing the yamllint pre-commit check?  I'd be ok with other pre-commit checks failing still (presumably those will be tackled in other PRs), as long as we can see pre-commit passing the thing you are fixing in this PR (the yamllint check).

@dav3r This one needs approval from you or one of the other .github/ codeowners.


Add list of median inputs

Useful for debugging (or eventually changing logic) to identify cases where only estimate is relevant for PFF.

Should we also add logic to clear out everything else for these variables?

Should we also add logic to clear out everything else for these variables?

@SPTKL I added this logic. The rooms variables are an exception, since they are both median inputs and displayed variables.


VCV Rack: Create texture or style for plugin faces

Tasks:

[x] Look at black vintage gear, especially old Moog modular units
[ ] Create a custom texture based upon any good finds from image searches
[ ] Read https://vcvrack.com/manual/Panel

So I did do a first pass at this ... with some black and grey metal textures. Now I want to explore something PDP-11-inspired ;-)


fix: Site module app insight and customDomainVerificationId

Description

This PR fixes two issues in site module:

Currently, if user of the module does not specify any appSettingsKeyValuePairs but only appInsightResourceId, the relevant app settings for configuring app insights is not created by the module since the bicep code only checks for appSettingsKeyValuePairs emptiness.
Remove misleading customDomainVerificationId as param. This is a read only property and set after app service instance is created. Exposed the same as output instead.
https://stackoverflow.com/questions/69382365/setting-the-customdomainverificationid-property-on-an-appservice-in-a-bicep-de

Pipeline Reference

Pipeline

Type of Change

[x] Update to CI Environment or utilities (Non-module affecting changes)
[x] Azure Verified Module updates:

[x] Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:

[x] Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
[ ] The bug was found by the module author, and no one has opened an issue to report it yet.

[x] Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
[ ] Breaking changes and I have bumped the MAJOR version in version.json.
[x] Update to documentation

Checklist

[ ] I'm sure there are no other open Pull Requests for the same update/change
[x] I have run Set-AVMModule locally to generate the supporting module files.
[x] My corresponding pipelines / checks run clean and green without any errors or warnings

@tsc-buddy Have a look. I closed this PR https://github.com/Azure/bicep-registry-modules/pull/2465 and instead combined two issues and refreshed branch etc.

Hi Team,
Can some one review this and progress further? cc @tsc-buddy

Hi Team,
Can some one review this and progress further? cc @tsc-buddy

Hey @pankajagrawal16,
I just pinged @tsc-buddy on the side. If bad comes to worse, one of us maintainers can certainly review the PR. However, I can see that there is a conflict in the main.json which I'd need to ask you to resolve. I'd recommend to get whatever change into your PR and then just re-run the Set-AVMModule script to make sure the contained templateHash etc. is definitely representing your version of the code 💪


Add CLI tool to build Operator Bundle image

Add top level CLI command operator-cli
Add bundle command to generate annotations.yaml and Dockerfile
Add bundle command to build Bundle image

The build command will generate annotations.yaml and Dockerfile
as well

Signed-off-by: Vu Dinh<EMAIL_ADDRESS>
Description of the change:
Motivation for the change:
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /docs
[ ] Commit messages sensible and descriptive

/retest

This PR is moved and replaced by another PR in operator-registry. Closed.


RetryHandler should add more information on failures

Sourced from https://github.com/microsoftgraph/msgraph-beta-sdk-dotnet/issues/816

The default retry handler simply throws an InvalidOperationException exception when it reaches the maximum retry count. The error message is simply set to: «Too many retries performed.» and the inner exception simply states: «More than {retryCount} retries encountered while sending the request.»
There is no way to know why retries have been performed. What were the error codes and error messages?

The retry handler should return an AggregateException (or a specific exception like TooManyRetriesException) with one exception per retry specifying the HTTP status and the error code returned by the server.

This was resolved via https://github.com/microsoft/kiota-http-dotnet/pull/223


Support remove blocks on worker for pagestore when free/delete file

What changes are proposed in this pull request?
Support removeBlock for pagestore.
Why are the changes needed?
To remove metadata and data of blocks and pages on worker when free or delete a file.
Does this PR introduce any user facing changes?
N/A

@dbw9580 As this is the first PR from @fffanyang , she has been submit a cla signed mail to [cla@alluxio.org](mailto:cla@alluxio.org), PTAL.

@dbw9580 As this is the first PR from @fffanyang , she has been submit a cla signed mail to [cla@alluxio.org](mailto:cla@alluxio.org), PTAL.

Thanks to @fffanyang for submitting PR and contributing to Alluxio.

@maobaolong Could you help re-run the unit test, this may be a flaky test. Thank you in advance!

alluxio-bot, merge this please


Improve the UI error message if user does not have permissions to list repositories

What happened?
Current Behavior:
if user does not have permissions to list repositories then they get hard to decipher error message (see screenshot below)
Steps to Reproduce:

Create a user in lakeFS but don't give any permissions to that user.
Login as a new user. Use get following error message on home page.

Expected Behavior
Expected Behavior:
How you expected thing to work.
Would be good to improve the UI error message to something like "You do not have permissions to list repositories" or something like that.
lakeFS Version
0.96.1
Deplyoment
lakeFS Cloud
Affected Clients
No response
Relevant logs output
No response
Contact Details
<EMAIL_ADDRESS>

@kesarwam is this still happening?
I checked on master with ACL and With RBAC, wasn't able to reproduce

@guy-har Thanks. I don't see weird error message in new version anymore:

@guy-har I tested this with lakeFS Cloud on AWS while Miguel/APEX reported this issue in Azure. I hope it is same code base.

@guy-har They would like to improve the UI error message to something like "Your user does not have permissions to list repositories".


Looking for new maintainers

Originally I stepped in to fill a gap when @JakeGinnivan was looking for people that help to keep the project alive and kicking. That has already been since around 2016, time flies. Now I'm looking for a way to step out of the project gradually if possible.
Is anyone interested in moving things forward like keep on maintaining the lib, triaging issue, and eventually built-in support for new language features?

Pinging @jnm2 @sungam3r @stakx @atifaziz @adamralph to see if anyone of you is interested (since you contributed quite a bit to this library)

@danielmarbach, first of all, thank you for having maintained this library—which we at castleproject/Core have been using for a while—for the last few years! You were always very quick to respond and put out patch releases for us, which is greatly appreciated! 👌
As to your request, I can see myself lending a hand here. What's holding me back from committing fully at this moment is the fact that this library might get increasingly harder to maintain and keep up-to-date, being based on CodeDOM as it is; the gap between Roslyn's and CodeDOM's capabilities is likely to widen as time goes on. I remember seeing a discussion contemplating a complete rewrite and the back-compat problems that would likely come with it; while this might eventually become inevitable, I'm not sure if I'd be ready to tackle that—at least not just on my own. I'll give it some more thought, though.
Having said that, I am happy to help out. If you're willing to give me (and others) access to this repository along with some onboarding instructions (well, as far as they are needed), I'll humbly accept. 🙃

Unfortunately, I also believe that CodeDom is a dead end way. Its use is the main problem in the evolution of the project. It is already clear how much had to be done to bypass its restrictions. Just look at the magic string replacements. It's funny and sad at the same time.

Sorry, I'm afraid I can't take it on.

As to your request, I can see myself lending a hand here. What's holding me back from committing fully at this moment is the fact that this library might get increasingly harder to maintain and keep up-to-date, being based on CodeDOM as it is; the gap between Roslyn's and CodeDOM's capabilities is likely to widen as time goes on. I remember seeing a discussion contemplating a complete rewrite and the back-compat problems that would likely come with it; while this might eventually become inevitable, I'm not sure if I'd be ready to tackle that

Honestly, I also did abandon any efforts to rewrite things due to lack of time as well as interest on my side even though the test coverage would probably allow the guts of it to be rewritten while keeping the public-facing results compliant.  Is it nice, hell no? Does it work, hell yes ;) Do I like it, no but I also have limited time to keep things moving so 🤷

Having said that, I am happy to help out. If you're willing to give me (and others) access to this repository along with some onboarding instructions (well, as far as they are needed), I'll humbly accept.

Sure. Will do soon. As far as it comes to onboarding I'm not sure it requires much. If you feel it is required I'm happy to hop on a call if necessary. That being said I won't be removed from planet earth (at least I hope) so I can still react to pings and such if necessary.

@sungam3r

Unfortunately, I also believe that CodeDom is a dead end way. Its use is the main problem in the evolution of the project. It is already clear how much had to be done to bypass its restrictions. Just look at the magic string replacements. It's funny and sad at the same time.

You realize that could be changed if enough people believe in the project and push it forward. Like I explained above I never had enough time to do so. I mostly focused to keep it alive and working while bolting on a few things.

I understand it. I myself have enough time for a maximum of only 10% of everything planned. As for this project, it seems to me that somewhere I saw (or at least it seemed to me so) an alternative to this project, something based on the Roslyn possibilities. If this is true, then perhaps the problem has already been solved by another team using more modern tools. In this case, there may already be no need to support anything here.

@sungam3r Microsoft created this
https://github.com/dotnet/arcade/tree/master/src/Microsoft.DotNet.GenAPI
as well as https://github.com/dotnet/arcade/tree/master/src/Microsoft.DotNet.ApiCompat
and yes it is indeed also a possibility to let this project die.

@stakx can you reach out to me over Twitter DM so that I can give you the rights for uploading nuget packages?

https://github.com/dotnet/arcade/tree/master/src/Microsoft.DotNet.GenAPI

Most likely this is exactly what I saw. I have not tried it and I cannot tell if this is a worthy replacement.

I agree that putting this project to rest should be an option if there is an officially supported Microsoft or .NET Foundation project with comparable capabilities. I'll definitely keep those on my radar.
Though I've noticed before that there's lots of (sorely needed) tools at the edges of .NET Core that have seemingly resulted from someone's single coding spike, then don't get much further investment. A closer look & time will tell whether the projects linked above belong in that category or not. Until then it seems reasonable to me to keep PublicApiGenerator going at least at maintenance level (if not more than that).

Do you realize that could be changed if enough people believe in the project and push it forward?

Another thought along those lines occurred to me a while back, regarding CodeDOM: This project has had to work around certain of its restrictions. What if an attempt were made to lift those restrictions, by contributing back directly to CodeDOM? Then this project would stand on fairly solid ground.
(I don't have any particular love for CodeDOM, but it would be good for .NET as a whole if its distinct parts (I'm thinking mostly of the C# language, Reflection, and CodeDOM) were brought back closer to feature parity.)

I spent several hours trying to figure out how to use Microsoft.DotNet.GenAPI and Microsoft.DotNet.ApiCompat. They are not normal NuGet packages. They have a special type, and I gave up. Of course they're open source.
For spitting out source code, I prefer the ease and control of IndentedTextWriter. For reading metadata, I prefer Roslyn. The ISymbol model does so much of the legwork of decoding all the attributes and exposing a simple property to tell you e.g. if a struct is a ref struct. C# is only growing in concept count, so by using Roslyn, I'm counting on letting it do more and more legwork for me without me having to lift a finger. I'm sure we all remember decoding nullable reference types. :D
I've been playing with my own experimental (currently ugly) thing with two real-world use cases: https://github.com/jnm2/GenerateRefAssemblySource/tree/master/GenerateRefAssemblySource
It generates a solution and projects that are dotnet build-able and which spit out proper reference assemblies. I'm working towards using it for https://www.nuget.org/packages/jnm2.ReferenceAssemblies.net35 and to generate reference assemblies for a third-party platform we use at my day job.

I'm sure we all remember decoding nullable reference types

I forgot the details, but I remember the general feeling 😄

@adamralph just mentioned this
https://github.com/dotnet/roslyn-analyzers#microsoftcodeanalysispublicapianalyzers
pretty nifty

I've switched to Microsoft.CodeAnalysis.PublicApiAnalyzers for all my projects. The analyser runs on every build and tells me if something has changed in the public API.
So long PublicApiGenerator, and thanks for all the fish. 🙂 👋

@adamralph any noticeable build time overhead? Does it only run on the release build?

any noticeable build time overhead?

None that I've noticed.

Does it only run on the release build?

It's a regular analyser, so it will run according to however you set it up. By default: all builds. Violations show as warnings, and like any other analyser, they can be treated as errors if required.

Looks interesting. I couldn't tell from the documentation how one would set up several .Shipped.txt files for a multi-targeting project, will try that out.

@stakx it's here — https://github.com/dotnet/roslyn-analyzers/blob/master/src/PublicApiAnalyzers/PublicApiAnalyzers.Help.md#conditional-api-differences

<ItemGroup>
  <AdditionalFiles Include="PublicAPI/$(TargetFramework)/PublicAPI.Shipped.txt" />
  <AdditionalFiles Include="PublicAPI/$(TargetFramework)/PublicAPI.Unshipped.txt" />
</ItemGroup>

@adamralph — ah, I missed that. Excellent! Thanks for the pointer!

I tried this analyzer. While it still has drawbacks, moving APIs from unshipped to shipped does not work. See https://github.com/dotnet/roslyn-analyzers/issues/3226 . In addition, from the point of view of ease of perception, PublicApiGenerator wins against PublicApiAnalyzers. Maybe it's a matter of habit.

I also noticed that after juggling with two shipped/unsipped files, the analyzer errors remain even after successfully building the project. Maybe VS caching issue but it bothers me a lot.

So long PublicApiGenerator, and thanks for all the fish. 🙂 👋

Well, I can't say that. So far, at least for me, PublicApiGenerator is easier and more convenient to use.

The workflow works for me so far:

Install Microsoft.CodeAnalysis.PublicApiAnalyzers
Build the project(s)
Fix all violations of RS0016 by right clicking one and fixing all violations in "Project" (or "Solution")
Move all content from PublicAPI.Unshipped.txt to PublicAPI.Shipped.txt

Then, during development, warnings appear if I change the public API. Some are by design (deliberate changes to the public API) and some are accidental. I fix the accidental ones by reverting the changes. I fix the deliberate ones with the the RS0016 code fix.
Later, I take a checkpoint of any deliberate changes by deleting both PublicAPI.Unshipped.txt and PublicAPI.Shipped.txt and repeating the above process starting at step 2. Then I review the changes to PublicAPI.Shipped.txt in a similar wys to reviewing the "expected" and "actual" output from PublicApiGenerator.
Having two files (PublicAPI.Unshipped.txt and PublicAPI.Shipped.txt) instead of one is slightly annoying, and overkill for most projects. There's an issue for that - https://github.com/dotnet/roslyn-analyzers/issues/3281
I would also prefer an option to simply delete and recreate the API file on every build, so that I can just review the diff to it along with any other changes, rather than see warnings about changes. Maybe I'll raise a feature request for that.
BTW - Microsoft.CodeAnalysis.PublicApiAnalyzers is not just about monitoring diffs to the public API. It also inspects your public API for other problems. See https://github.com/dotnet/roslyn-analyzers/blob/master/src/PublicApiAnalyzers/Microsoft.CodeAnalysis.PublicApiAnalyzers.md

Thanks for the detailed description. It confirmed my guesses. I followed the same sequence of steps when experimenting with the analyzer.

Having two files (PublicAPI.Unshipped.txt and PublicAPI.Shipped.txt) instead of one is slightly annoying, and overkill for most projects

Exactly. That is why I say that now it is more convenient to work with PublicApiGenerator than with Microsoft.CodeAnalysis.PublicApiAnalyzers. If the authors of the latter work on eliminating these shortcomings, then obviously it will become more powerful than PublicApiGenerator .

@danielmarbach I would close this. @stakx granted me with admin permission here so I can move things on.
In the next month, I am going to work on CI/CD workflows and for some cosmetic changes across codebase. No actual changes in code.

I was also thinking about closing this issue, but @sungam3r beat me to it! 😄
Welcome @sungam3r (even though you've probably been participating here for longer than I have)! You've demonstrated more involvement in this project than I could recently, so I'm happy that you want to help out looking after it, too!
I've been a little busy elsewhere lately, but am slowly getting back to open-source work... so I'll still be around. Looking forward to working together.


WP8 splash screen flickers on load

I have a feeling that one of perhaps some of the config preferences are causing a flicker on load. Will have to look into this.

My Device

Lumia 920 WP 8.1

App Configuration
Cordova WP 3.8.1
<preference name="AutoHideSplashScreen" value="false" />

We call navigator.splashscreen.hide(); after the app is fully initialized.
Problem Description
When compiled in release mode and run with the VS debugger attached:

I see our black splash screen (correct)
I see a quick flicker of a white screen or our app - varies (incorrect)
I see the black splash screen (correct)
I see splash screen disappear and display the app (correct)

When compiled in release and run detached from USB debugger:

I see our black splash screen (correct)
I see a quick flicker our app that is half faded out (incorrect)
I see the black splash screen (correct)
I see splash screen disappear and display the app (correct)

Debugging Attempts

I've downgraded the splash screen and tried:

2.1.0
2.0.0
1.0.0
0.3.5
0.3.4
0.3.3
0.3.2
0.3.1
0.3.0

If I downgrade to 0.3.0 then the AutoHideSplashScreen preference is not supported by WP.

At this point, the splash screen acts correctly.

I've removed the navigator.splashscreen.hide();

The splash screen remains displayed. This is correct.

I think we will need @purplecabbage to investigate whether this is a WP8 Splash Screen issue.

Short-term fixes:

Copy the splashscreen image you want to use to platforms/wp8/SplashScreenImage.jpg ( make sure it is jpg and 768x1280 )
modify splashscreen.cs to return null from GetSplashScreenImageResource(). You can do this by forking the repo and installing from the fork, or you can modify the file in your WP8 build scripts.

The flash happens because WP8 has a default handling of a splashscreen using the image "SplashScreenImage.jpg" which is shown before any of our code loads.
Then our code looks thru config for the file path ( or uses default ) creates an image and puts it on screen.
We have no control over the gap in time from OS splashscreen to our code and splashscreen.
As an alternative to 2. You may want to simply make the build script remove the splashscreen plugin on the wp8 platform.

Nice, thanks @purplecabbage.
We went with your short-term fix, which was to manually copy the SplashScreenImage.jpg and modify SplashScreen.cs to return null. We were able to accomplish this with a small hook that runs quick.


Extremely slow conda install step (--tools) during upgrade

As the subject says, it stayed up almost 24 hours and kept on being in the "solving" phase. I can't upgrade bcbio until this step terminates, so it's kind of a problem.
 What can I try as I do not want to wipe the installation?

FTR, the list of inconsistent pacakges:
The environment is inconsistent, please check the package plan carefully
The following packages are causing the inconsistency:

  - defaults/linux-64::_nb_ext_conf==0.3.0=py27_0
  - conda-forge/linux-64::ansible==2.7.10=py36_0
  - bioconda/linux-64::bcbio-nextgen-vm==0.1.0a=py27_87
  - <unknown>/linux-64::r-rmpi==0.6_9=r351h96ca727_1000
  - bioconda/linux-64::dx-cwl==0.1.0a20180119=py27_0
  - bioconda/linux-64::arvados-cwl-runner==1.0.20160502202716=py27_0
  - defaults/linux-64::nb_conda==2.0.0=py27_0
  - conda-forge/linux-64::shade==1.28.0=py27_0
  - bioconda/linux-64::toil==3.14.0=py27_1
  - defaults/linux-64::pymc==2.3.6=np111py27_nomkl_2
  - conda-forge/linux-64::azure-mgmt==0.20.1=py27_0
  - conda-forge/linux-64::python-ironicclient==2.3.0=py27_0
  - <unknown>/linux-64::cnv_facets==0.12.1=r351_0
  - defaults/linux-64::nbpresent==3.0.2=py27_0
  - bioconda/noarch::sbg-cwl-runner==2018.11=py_0
  - bioconda/linux-64::elasticluster==0.1.3bcbio=py27_11
  - conda-forge/linux-64::azure==1.0.3=py27_0

(A couple aren't part of bcbio, they were installed as extras)

Luca;
Apologies for the slowness. We don't have a lot of control over this from the bcbio side, if things get in an inconsistent state it can take the solver a long time to resolve. The options are to wait it out, re-install just the tools from scratch, or to try custom bcbio_conda installs for problematic packages. It looks like your bcbio environment has a lot of extra packages and specifically having bcbio-vm in the same environment with bcbio will introduce a number of extra dependencies. Is it possible to remove bcbio-vm and the associated dependencies from the base environment and either install it into a custom environment or separate conda repository (https://bcbio-nextgen.readthedocs.io/en/latest/contents/cwl.html?highlight=bcbio-nextgen-vm#install-bcbio-vm-with-a-local-bcbio)? Sorry about the conda issues and hope this helps.

bcbio_vm is likely a leftover from my early experiments with CWL, before the separate environment. I'll try to clean it up and report.

Thanks, there have been a bunch of speedups with conda dependency resolutions, so upgrading, while painful, isn't as bad as it was.


Caching not available on GitHub Enterprise

Hello, I am looking to run Cypress tests within GitHub Actions, but having trouble due to the action trying to use caching. GitHub Enterprise does not yet have caching support like github.com - at least as far as I'm aware. This is what I see in the logs,
Saving NPM cache error: Unable to reserve cache with key npm-linux-x64-2357f551dce11df77e14a37071ec71d0bdf8256d8ca499fe6b748ad5e23eee3ac0d117cddd6f056417169ff5f0ab194ad00ef7a754ea993cc1a08a8d4de005a0, another job may be creating this cache.
Saving Cypress cache error: Unable to reserve cache with key cypress-linux-x64-2357f551dce11df77e14a37071ec71d0bdf8256d8ca499fe6b748ad5e23eee3ac0d117cddd6f056417169ff5f0ab194ad00ef7a754ea993cc1a08a8d4de005a0, another job may be creating this cache.

Is there any way to disable caching, or could support be added?
Thanks,
Weldon

Hello,
Did you find any solution to the problem, even I face the same issue as given below,
/opt/hostedtoolcache/node/14.19.2/x64/bin/npx cypress verify
[STARTED] Task without title.
[SUCCESS] Task without title.
Saving NPM cache error: Unable to reserve cache with key npm-linux-x64-4a6c6fc5c44b866ced8c46034c0130244a7124faa06d238d9923c45049[56]
check_suite_focus=true#step:6:57)a5230c76dda314cd2831966a07dc7b6e[60]check_suite_focus=true#step:6:61)cacdb42561674e47c0765bbe8e4a2f88f3, another job may be creating this cache.
Saving Cypress cache error: Unable to reserve cache with key cypress-linux-x64-4a6c6fc5c44b866ced8c46034c0130244a7124faa06d238d9923c4504956a5230c76dda314cd2831966a07dc7b6e60cacdb42561674e47c0765bbe8e4a2f88f3, another job may be creating this cache.
Error: Not Found
Regards,
Amitabh

Same here. Any updates?

Me three...
E.g. https://github.com/PostHog/posthog/runs/7151150940?check_suite_focus=true

The same:
Saving Cypress cache error: Unable to reserve cache with key cypress-linux-x64-15c5ba12d0b61fc47cf969b2bdd88312defa6e69d27875579c4d36e427f84bdc2600db432a458b919867a37c04b0777e85762eeb09f79e212ed18d70c5dec5b8, another job may be creating this cache.

Do we have any clue why is this happening?

cypress-io/github-action v5.0.2 uses "@actions/cache": "3.0.6".
@actions/cache v3.0.9 added "Enhanced the warning message for cache unavailability in case of GHES."
Perhaps cypress-io/github-action could be  updated to use @actions/cache v3.2.2 to at least take advantage of a better warning message?
There is a long discussion in https://github.com/actions/cache/issues/505 about this and the release notes for GHES 3.5.0 from May 31, 2022 state "Cache support for GitHub Actions on GitHub Enterprise Server is now generally available".
I don't personally have access to GitHub Enterprise, but perhaps the above research may throw some light on the problem?
Which version of GitHub Enterprise are people have problems with? GitHub Enterprise Cloud or GitHub Enterprise Server? If GitHub Enterprise Server, the supported releases are currently 3.3 to 3.7.

@adiqa

Do we have any clue why is this happening?

See https://github.com/cypress-io/github-action/issues/513#issuecomment-1368080092
Could you say which version of GitHub Enterprise you are using?

cypress-io/github-action@v5 was updated in v5.0.5 through PR https://github.com/cypress-io/github-action/pull/716 to use "@actions/cache": "3.1.2" from https://github.com/actions/cache.
Are there still cache issues on GitHub Enterprise when using the latest v5 version of cypress-io/github-action?

@wsams
Do you still have questions or an open issue surrounding this topic? If not, perhaps you would like to close the issue, since nobody else has contributed with any further details.

@MikeMcC399 I am facing this issue while running cypress on Github Enterprise Cloud.

@merrcury
I don't believe that this issue is specific to GitHub Enterprise Cloud as I have seen it occurring on regular GitHub-hosted runners. Does the error clear if you wait for 24 hours?
Since the original title of this issue is "Caching not available on GitHub Enterprise" and this is no longer true, I would suggest closing this issue and starting a new one.

Make sense @MikeMcC399. Let me dig more deeper. Thanks, I am not original author, can't close this.

I am going to close this issue at this time.


Demo: startup failed

docker run
--name pgvecto-rs-demo
-e POSTGRES_PASSWORD=mysecretpassword
-p 5432:5432
-d tensorchord/pgvecto-rs:pg16-v0.1.14-beta
Startup is failed. The log is:
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

    pg_ctl -D /var/lib/postgresql/data -l logfile start

waiting for server to start....2024-01-21 18:50:56.269 UTC [48] FATAL:  called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }
2024-01-21 18:50:56.269 UTC [48] LOG:  database system is shut down
pg_ctl: could not start server
Examine the log output.
 stopped waiting

cc @usamoi @cutecutecat

Thanks you for your report!
To debug it further, you could recreate the container with RUST_BACKTRACE=full environment to get further information and paste the logs again:
docker run --name pgvecto-rs-demo \
-e POSTGRES_PASSWORD=mysecretpassword 、
-e RUST_BACKTRACE=full \
-p 5432:5432 -d tensorchord/pgvecto-rs:pg16-v0.1.14-beta

Here it is:
`The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgresql/data -l logfile start

initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
waiting for server to start....2024-01-23 19:31:07.015 UTC [48] FATAL:  called Result::unwrap() on an Err value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }
2024-01-23 19:31:07.015 UTC [48] DETAIL:
0: pgrx_pg_sys::submodules::panic::register_pg_guard_panic_hook::{{closure}}::{{closure}}
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-pg-sys-0.11.2/src/submodules/panic.rs:312:39
1: std::thread::local::LocalKey::try_with
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/thread/local.rs:270:16
2: std::thread::local::LocalKey::with
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/thread/local.rs:246:9
3: pgrx_pg_sys::submodules::panic::register_pg_guard_panic_hook::{{closure}}
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-pg-sys-0.11.2/src/submodules/panic.rs:309:24
4: <alloc::boxed::Box<F,A> as core::ops::function::Fn>::call
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/alloc/src/boxed.rs:2021:9
5: std::panicking::rust_panic_with_hook
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/panicking.rs:783:13
6: std::panicking::begin_panic_handler::{{closure}}
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/panicking.rs:657:13
7: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/sys_common/backtrace.rs:170:18
8: rust_begin_unwind
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/panicking.rs:645:5
9: core::panicking::panic_fmt
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/core/src/panicking.rs:72:14
10: core::result::unwrap_failed
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/core/src/result.rs:1649:5
11: core::result::Result<T,E>::unwrap
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/core/src/result.rs:1073:23
12: vectors::ipc::transport::mmap::init
at /home/runner/work/pgvecto.rs/pgvecto.rs/src/ipc/transport/mmap.rs:17:17
13: vectors::ipc::init
at /home/runner/work/pgvecto.rs/pgvecto.rs/src/ipc/mod.rs:51:5
14: vectors::_PG_init::_PG_init_inner
at /home/runner/work/pgvecto.rs/pgvecto.rs/src/lib.rs:30:9
15: vectors::_PG_init::{{closure}}
at /home/runner/work/pgvecto.rs/pgvecto.rs/src/lib.rs:21:1
16: std::panicking::try::do_call
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/panicking.rs:552:40
17: std::panicking::try
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/panicking.rs:516:19
18: std::panic::catch_unwind
at /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/std/src/panic.rs:142:14
19: pgrx_pg_sys::submodules::panic::run_guarded
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-pg-sys-0.11.2/src/submodules/panic.rs:408:11
20: pgrx_pg_sys::submodules::panic::pgrx_extern_c_guard
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pgrx-pg-sys-0.11.2/src/submodules/panic.rs:385:11
21: _PG_init
at /home/runner/work/pgvecto.rs/pgvecto.rs/src/lib.rs:22:1
22:
23: load_file
24:
25: process_shared_preload_libraries
26: PostmasterMain
27: main
28:
29: __libc_start_main
30: _start
2024-01-23 19:31:07.015 UTC [48] LOG:  database system is shut down
pg_ctl: could not start server
stopped waiting
`

What it does when:
fixing permissions on existing directory /var/lib/postgresql/data ... ok

In short, this is a process of uid/gid mapping by postgres, it would use 999 as user postgres, which only shows up at the host as openmediavault-webgui/openmediavault-config.
As a reference: https://stackoverflow.com/a/56188924

Back to the question, we could see that there is little discussion about it:
Failed to create UnixStream · dani-garcia/vaultwarden · Discussion #3800 (github.com)
It's due to UnixStream failed to create, and there could be many infra reasons for that. Since it is not easy to reproduce, things are more complicated.
We will do our best to dig it out, but success is not guaranteed. It would be much helpful if you could provide the same information as in the discussion above.
#Kernel/Host info:
uname -a

# CPU Info:
cat /proc/cpuinfo | grep -m1 -i "model name"

#Docker info:
docker info

# Storage space:
df -h

#Kernel/Host info:
Linux nas 5.15.131-2-pve #1 SMP PVE 5.15.131-3 (2023-12-01T13:42Z) x86_64 GNU/Linux
CPU Info:
model name      : Intel(R) Celeron(R) J4105 CPU @ 1.50GHz

#Docker info:
Client: Docker Engine - Community
 Version:    25.0.0
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.12.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.24.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 7
  Running: 1
  Paused: 0
  Stopped: 6
 Images: 7
 Server Version: 25.0.0
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: a1496014c916f9e62104b33d1bb5bd03b0858e59
 runc version: v1.1.11-0-g4bccb38
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.131-2-pve
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.567GiB
 Name: nas
 ID: SKTX:TBIW:KK2W:CDXR:SQJJ:RWC6:DIFQ:V53E:M4H2:EYXU:B4ZH:VFSU
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

Storage space:
Filesystem                    Size  Used Avail Use% Mounted on
udev                          3.8G     0  3.8G   0% /dev
tmpfs                         775M  5.0M  770M   1% /run
/dev/nvme0n1p3                442G   32G  389G   8% /
/dev/nvme0n1p2                511M  288K  511M   1% /boot/efi


V3.0 Universal Adapter creates inappropriate device for Philips Hue<PHONE_NUMBER>

This is a newish Philips Hue dimmable white bulb.
For our purposes it is identical to older ones like<PHONE_NUMBER>147.
Unlike the older ones, this one isn't in adapter_by_model so its creation is handled by the UniversalAdapter code.
That code is creating only an _effect device. It should be creating a _light device.
Zigbee2MQTT exposes the following for both this new bulb and its older cousins: -
[{'features': [{'access': 7, 'description': 'On/off state of this light', 'name': 'state', 'property': 'state', 'type': 'binary', 'value_off': 'OFF', 'value_on': 'ON', 'value_toggle': 'TOGGLE'}, {'access': 7, 'description': 'Brightness of this light', 'name': 'brightness', 'property': 'brightness', 'type': 'numeric', 'value_max': 254, 'value_min': 0}], 'type': 'light'}, {'access': 2, 'description': 'Triggers an effect on the light (e.g. make light blink for a few seconds)', 'name': 'effect', 'property': 'effect', 'type': 'enum', 'values': ['blink', 'breathe', 'okay', 'channel_change', 'finish_effect', 'stop_effect']}, {'access': 1, 'description': 'Link quality (signal strength)', 'name': 'linkquality', 'property': 'linkquality', 'type': 'numeric', 'unit': 'lqi', 'value_max': 255, 'value_min': 0}]

Could you please update the plugin and try again

Will do, but I’m currently not seeing a v3.0 branch.

It is now part of master one

No change, the plugin still creates an _effec device for this bulb.

No change, the plugin still creates an _effec device for this bulb.

I also have this for the Philips Hue white ambiance E14 (with Bluetooth)<PHONE_NUMBER>.
@stas-demydiuk, It looks like this only happens to Color and White Ambiance bulbs, because I also added a Hue Filament Standard A60/E27 bluetooth Bulb<PHONE_NUMBER>820...this creates the device properly.

I don't think this is confined to colour / ambiance bulbs - mine is neither, it's just a warm white dimmable.
I believe the common factor is "new" bulbs which are handled by the new Universal Adapter code.
Your bulb, like mine, falls into that category.
My feeling is the Universal Adaptor code should still be in a beta-test branch, not the main one.

I don't think this is confined to colour / ambiance bulbs - mine is neither, it's just a warm white dimmable.
I believe the common factor is "new" bulbs which are handled by the new Universal Adapter code.
Your bulb, like mine, falls into that category.
My feeling is the Universal Adapter code should still be in a beta-test branch, not the main one.

I think you are right.
When I look in my log the following error is shown:
2020-12-21 15:32:18.867 Error: (Zigbee2MQTT) Hoek_Lamp1: can not process feature type "light"
2020-12-21 15:32:18.868 Error: (Zigbee2MQTT) Hoek_Lamp2: can not process feature type "light"
2020-12-21 15:32:18.868 Error: (Zigbee2MQTT) Hoek_Lamp3: can not process feature type "light"

I am not a programmer, but is seems the feature 'type': 'light' is not declared in this part of adapter.py:
def _add_devices(self, items):
        for item in items:
            if item['type'] == 'binary':
                self.add_binary_device(item)
                continue

            if item['type'] == 'enum':
                self._add_selector_device(item['name'][0: 5], item)
                continue

            if item['type'] == 'numeric':
                self.add_numeric_device(item)
                continue

            if item['type'] == 'switch':
                self._add_devices(item['features'])
                continue

            if item['type'] == 'lock':
                self._add_devices(item['features'])
                continue

            if item['type'] == 'climate':
                self._add_devices(item['features'])
                continue

            domoticz.error(self.name + ': can not process feature type "' + item['type'] + '"')
            domoticz.debug(json.dumps(item))

The access property in exposes.md is not easy to understand.
https://github.com/Koenkk/zigbee2mqtt.io/blob/develop/docs/information/exposes.md#exposes
Access
The access property is a 3-bit bitmask.
Bit 1: The property can be found in the published state of this device.
Bit 2: The property can be set with a /set command
Bit 3: The property can be retrieved with a /get command (when this bit is true, bit 1 will also be true)
Examples:
A Xiaomi WSDCGQ01LM climate sensor exposes a numeric temperature sensor. Since the device is sleeping most of the time it cannot be retrieved with a /get command. Access will be 1 (binary: 0b001).
 This can be /get, /set and is also in the published state.  This can only be /set. Access will be 2 (binary: 0b010)
A Xiaomi ZNCZ02LM power plug exposes a numeric power sensor. This can be /get and is published in the state. Access will be 5 (binary: 0b101)
I also can’t figure out how this is implemented in adapter.py
In the exposes.md the access value of numeric and binary types is 7 and the enum (effect) type is 2
In adapter.py access values are declared here (I guess)
ACCESS_STATE = 0
ACCESS_WRITE = 1
ACCESS_READ = 2

but I wonder how the access value 7 is calculated if you look at this snippet of adapter.py:
def _has_access(self, access, access_type):
        mask = 1 << access_type
        return bool(access & mask)

    def add_binary_device(self, feature):
        state_access = self._has_access(feature['access'], ACCESS_STATE)
        write_access = self._has_access(feature['access'], ACCESS_WRITE)

or

def add_numeric_device(self, feature):
        state_access = self._has_access(feature['access'], ACCESS_STATE)
        write_access = self._has_access(feature['access'], ACCESS_WRITE)

Forgive me if I'm telling you something obvious, but while we wait for a solution, the quickest way to fix this and other problems with the Universal Adapter code is to add "new" devices into the appropriate adapters file, in our case adapters/philips/init.py.
That way it gets handled by the old, tried-and-tested, code.

It looks like the 2 underscores at both sides assume it is a bold text just like ** **
3 underscores at both sides is cursive bold cursive

Guys, could you please update plugin and try again

It's better but it's not usable yet.
It's better because a _light device is now created. It's  not usable yet because when the bulb changes to an "Off" state this is not reflected in the Domoticz device.
So, using the _light device to change the bulb's brightness works. Using it to turn the bulb off works too, but that status change is not reflected back to the Domoticz device. So it still shows as "On" when it is in fact now "Off".
The result of that you then can't turn the bulb back on by tapping/clicking the _light device - doing so just sends another "Off" command.

Support for light feature has been significantly improved in scope #548. Please upgrade the plugin to the latest version and check. Please post there in case of any issues.

Support for light feature has been significantly improved in scope #548. Please upgrade the plugin to the latest version and check. Please post there in case of any issues.

@stas-demydiuk in Z2M 1.17.0, the new_api is mandatory so in the configuration.yaml it is not needed anymore to add:
experimental:
new_api: true

Therefor you can remove this also in the read.me file of the plug-in I guess?

@stas-demydiuk in Z2M 1.17.0, the new_api is mandatory so in the configuration.yaml it is not needed anymore to add:
experimental:
new_api: true

Therefor you can remove this also in the read.me file of the plug-in I guess?


Fix plain body encoding

Before this bodies would appear in JSON as "Optional(\"Some text\")". Now they appear as "Some text".

Tabs to spaces, then :green_apple:. Thanks @soffes!

Closing since this is part of #31


Are all tokens supported?

Admittedly I'm not super strong with python. I've gotten this script to pull prices for coins like eth and dai but I really want to monitor the price (in USD) for a brand new token on uniswap that i want to swing trade
I don't need to code to execute trades, I'll do that manually for now, but whenever I swap out the contract address I just get errors

Mind kindly sharing the errors you're seeing? Shouldn't be a problem if there is a valid pool/pair.


Request: ability to change hint textSize

I use a 20sp textSize for my toolbar title.
It looks weird when the searchView opens and the hint's textSize is only 16sp.
Thanks!

Seems legit.
Could you please implemented and send a PR?

You can have a look at PR #64


Allow override of the path to SettingsFileGenerator.xml

Currently the path to SettingsFileGenerator.xml is fixed within the project structure to $(MSBuildProjectDirectory)\EnvironmentSettings\SettingsFileGenerator.xml. It would be beneficial to allow this to be overridden in the .btdfproj.
Add new property SettingsSpreadsheetPath.
This work item was migrated from CodePlex
CodePlex work item ID: '7348'
Assigned to: 'tfabraham'
Vote count: '1'

[UnknownUser@10/20/2010]
Resolved with changeset 51120.

[UnknownUser@2/21/2013]

[UnknownUser@5/16/2013]


RangeError in /clan/zhong-guo-bu-luo-rplcj0u2

Error in ClashLeaders
RangeError in /clan/zhong-guo-bu-luo-rplcj0u2
Maximum call stack size exceeded
View on Bugsnag
Stacktrace
webpack:///node_modules/vue/dist/vue.esm.js:891 - we.walk

View full stacktrace
Created automatically via Bugsnag

An error linked to this issue has been marked as fixed in Bugsnag
RangeError in /clan/req-n-go-8p2qg08p


GDExtension classes can easily crash the editor on startup due to always having @tool semantics

Godot version
4.0-dev
System information
System independent
Issue description
GDExtensions classes will crash the editor if their built in functions (_process, _ready) contain references to nodes that do not exist in the editor's scene tree.
I believe this is because they are now treated like core classes, which run _process and _ready in the editor since the editor is godot, as far as they're concerned. So if users have code in _process or _ready that reference non-existent nodes (from the editor's perspective), they will segfault and prevent the editor from opening.
Possible work arounds are using an ifdef macro to disable the offending portions of code when the editor needs to be open, or using if Engine::get_singleton()->is_editor_hint().
I realize this is not a bug, per se, since it's how the core classes work. However, GDNative did not work like this, and GDExtensions is intended to replace GDNative, so at the very least, the documentation should reflect this, in my opinion, major change. I'm sure people will be assuming this is a bug as more GDNative users migrate to GDExtensions, so it will be good to have a bug report that documents the issue.
Steps to reproduce
Create a GDExtension, and set up a reference to a node in the scene tree that doesn't exist in the editor, but will exist at runtime. It will crash.
Minimal reproduction project
No response

Why close?

I guess because it's not a bug, technically. It's expected behavior based on the design of core classes and thus GDExtensions. But it will be seen as a bug and so people searching for the bug will be able to find the solution. You can reopen if you wish.

Won't be an ifdef but we definately need access to is_editor_hint, I'm surprised we haven't got access to this.
Your classes running both in the editor and in runtime is a bonus to the system, but yes it does mean that you have to keep that in mind when writing extensions in the same way you would need to do this with modules.

Note btw that the initialiser you define with register_editor_initializer will only be called if you're in the editor, so it would be possible to set a flag so you know if you're in the editor or not. Feel workaround-ish, is_editor_hint is definitely better.

However, GDNative did not work like this (...)

How did this work with GDNative?
Is this issue about GDExtension types behaving similarly like tool scripts? (where instances are created withing the editor and callbacks are invoked).

For the record, related issues:

https://github.com/godotengine/godot-cpp/issues/709
https://github.com/godot-rust/gdextension/issues/70

Would it be possible to register an extension to have "run at runtime only" semantics entirely? Littering the code with lots of manual is_editor_hint checks is ugly and error prone. It also feels odd that the finally released game contains lots of logical branches that were only introduced for development purposes.

Would it be possible to have a dedicated _process_editor for GDExtensions, separated from the regular _process? If the extension does not need to be run in the editor, the member function is simply omitted.

As it already be considered to just reproduce the behavior of GDScripts?

assume by default that Node-inheriting classes are all not-a-tool (not the current behavior)
allow classes to expose a bool is_editor_tool() that will be querried by the engine at entity init, if returning true it behaves as it does currently, like a GDSCript having @tool - otherwise it behaves like a GDScript which do not have @tool
Engine::get_singleton()->is_editor_hint() still usable exactly the same way it would be usable in a GDScript which is marked @tool, therefore no need to duplicate code.

Also, what was the reasonning behind making GDExtension Node-inheriting types behave differently by default than a default GDScript?

Cross-posting from https://github.com/godotengine/godot-cpp/issues/709#issuecomment-1591995717:

GDExtensions are ideally meant to work like Godot modules. In a Godot module, nodes always run as if they are marked with @tool, and they use Engine::get_singleton()->is_editor_hint() (as mentioned by Calinou in the first comment) to check if they are currently running in the editor. Yes, this is different than GDScript, but I believe this is by design.

Something that has been discussed on this one is maybe making a "CPPScript" (which could still be part of godot-cpp) that allows making scripts in C++, which would work closer to how GDScript works (and how GDNative worked in Godot 3).
This could potentially help by splitting up the use cases of (1) wanting to make a GDExtension that's like a Godot module (but doesn't require recompiling Godot) and (2) wanting to do game scripting in C++ (something closer to GDScript)

Ok so the CPPScript solution would work to solve both this issue and the issue hot-reloading issue.
If I understand correctly, if we go that route it would mean that C++ Node inheriting classes which are not C++Script (so for example inheriting directly from Sprite2D) will act like @tool marked scripts, while other C++ CPPScript inheriting classes would act like GDScripts.
I suspect that it might be a big difference, just for checking a static condition, but I'm not against it.


[0006-static-lifecycle-methods] How does getDerivedStateFromProps access the current props?

state-derived-from-propsstate
In Before example, it uses this.props.someValue. But in After, it uses prevState.someMirroredValue.
I do not understand how the this.props(current props) can be accessed in the new static method getDerivedStateFromProps
Here are my questions based on the sample code

Does it mean we need to put the props in the state in every stage?
We are going to return a new state rather than call this.setState. After that, this.state will have the props. If my understanding is correct, do you feel odd because of the duplicated info.
Sometime, I do not want to put everything into the state except something will affect the component rendering. For example, I will store some pre-computed array results as the data member in the React.Component class. There will be an attribute, index in the state for accessing this array. Currently, componentWillReceiveProps is the place for recomputing part of the results. With the static method getDerivedStateFromProps, where should I put this logic?

@wood1986 current props cannot be accessed in getDerivedStateFromProps lifecycle. It's pure function. You just need to store new prop in state.
You can read this thread for more information.

@TrySound this sounds odd because inside the component there will be two versions of props
state.props and this.props Yes, as long as you know what you are doing, this is fine. But I do not feel well with two versions of props

@wood1986 You have two version of props when you use componentWillReceiveProps and componentDidUpdate. It's not different, except you save that data explicitly by yourself.
And what is wrong for you to keep previous props in state? Do you think it may introduce performance regression or something else?

I think my issue is not about the performance. It's main about the code migration from 16 to 17 and the code consistency.
In the Basic example, the comment inside gDSFP says

Called after a component is instantiated or before it receives new props.

Regardless of *context, does it means starting from 17
shouldComponentUpdate(nextProps, nextState) -> shouldComponentUpdate(nextState)
componentDidUpdate(prevProps, prevState) -> componentDidUpdate(prevState)?
If so, I am totally fine. If no, then this is odd part because shouldComponentUpdate and componentDidUpdate still hold nextProps and prevProps.

@wood1986 The problem with prevProps in gDSFP is that is does not exists on first call. So you need to extra check if it's not null and one of it's prop is not changed. This is overhead. State solves that problem via initial value.

I get this part. If this.state will have props information via the implementation ofgetDerivedStateFromProps, what is the point of having nextProps and prevProps in shouldComponentUpdate and componentDidUpdate respectively?

They just wasn't touched yet.

Hey @bvaughn,

Could you tell us that if we have to put the props into state via getDerivedStateFromProps, do you need the argument nextProps and prevProps in shouldComponentUpdate and componentDidUpdate?

How can I update the data member inside the getDerivedStateFromProps before giving the next state which depends on updated data member?
Currently I have a scenario that I need to re-compute some elements of an array which is the data member of the React.Component on nextProps is received in componentWillReceiveProps. The next state depends on the result of this array. this.state.index is for accessing the result of this array. I do not want to put the whole array into the state and this array cannot be static.

Could you tell us that if we have to put the props into state via getDerivedStateFromProps, do you need the argument nextProps and prevProps in shouldComponentUpdate and componentDidUpdate?

We have no current plans to change the signature for methods like shouldComponentUpdate and componentDidUpdate with regard to next/prev props.

How can I update the data member inside the getDerivedStateFromProps before giving the next state which depends on updated data member?

I don't really understand your question. Can you provide an example?
What inputs (in your current componentWillReceiveProps) determine whether you "re-compute" elements or not. Can you just mirror those inputs in prevState so that you can access them in getDerivedStateFromProps (as shown here)?
It sounds like you may be mutating an array (or objects within an array) that's passed in via props. This is not particularly safe. Generally we would suggest you store a filtered or mapped version of that array in your component's state and work with it.

As for the answer 1, nextProps and prevProps will become redundant. I want to know whether it is  a valid statement? If so, I hope you guys consider to remove it in the future.
As for the answer 2, I am not directly mutating  an array from props. Here is an example
class extends React.Component {
  constructor(props) {  // props.keys = [1, 2, 3]
    super(props);
    this.cache = [0];
    this.fn0(props.keys); // this.cache = [0, 1, 3, 6]
    this.state = {};
    this.state.index = 0;
  }

  fn0(keys) {
    for (let i = 0; i < keys.length; i++) {
      this.cache.push(this.cache[this.cache.length - 1] + keys[i]); // this.cache[n] = this.cache[n - 1] + keys[i]
    }
  }

  componentWillReceiveProps(nextProps) {
    // this.props.keys will keep growing and existing elements will never change
    // nextProps.keys = [1, 1, 2, 3] will never happen
    // nextProps.keys = [1, 2, 3, 1, 4]; is valid and this.cache = [0, 1, 3, 6 ,7 ,11]
    let i = 0;

    while (i < nextProps.keys.length && this.props.keys[i] === nextProps.keys[i]) {
      i++;
    }

    fn0(nextProps.keys.slice(0, i));
    const nextState = Object.assign({}, this.state);
    this.state.index = fn1(this.cache);
    this.setState(nextState);
  }
}

And you suggest that I should move this.cache to this.state. Am I correct?
Anyway, this is what I have observed you guys try to force us to get rid of all data members with that small static method.

// nextProps.keys = [1, 1, 2, 3] will never happen
// nextProps.keys = [1, 2, 3, 1, 4]; is valid and this.cache = [0, 1, 3, 6 ,7 ,11]

I don't understand this.

this.state.index = fn1(this.cache);

You should not directly mutate state like this. You should use setState. (I assume this may have been a typo and you may have meant to write nextState.index = ...)

And you suggest that I should move this.cache to this.state. Am I correct?

Maybe.
Since you're mutating cache, it would actually be safer to move what you're currently doing into componentDidMount/componentDidUpdate. If you were to move it to getDerivedStateFromProps (or leave it inside of componentWillReceiveProps) it's possible that you will mutate the cache unnecessarily. (This is explained in more detail in RFC 6 as well as my comment here.)
If you need to update cache before rendering, then a safer approach would be something like this:
class extends React.Component {
  state = {
    cache: [],
    index: 0,
    prevKeys: [],
  };

  static getDerivedStateFromProps(nextProps, prevState) {
    if (nextProps.keys !== prevState.prevKeys) {
      // Figure out 'i' by comparing nextProps.keys to prevState.prevKeys
      let i = 0;
      while (i < nextProps.keys.length && prevState.prevKeys.keys[i] === nextProps.keys[i]) {
        i++;
      }

      const cache = this.fn0(nextProps.keys, i);
      const index = this.fn1(cache);

      // Update state
      return {
        cache,
        index,
        prevKeys: nextProps.keys
      }
    }

    // Nothing to update in state
    return null;
  }

  fn0(keys, max) {
    // Don't mutate cache
    const cache = this.cache.slice(0);
    for (let i = 0; i <= max; i++) {
      cache.push(cache[cache.length - 1] + keys[i]);
    }
    return cache;
  }
}

That being understand, I don't really understand what the partial code snippet you shared is doing so I'm just taking a guess.

Yes you are right. It was a typo. It should be ‘nextState.index = this.fn1(this.cache)’
Anyway, thanks for your answer! I need to prepare for that change. I hope I can share the real code with you in the future because it is related to “react-virtualized”.

You are welcome. Good luck!

I don't get it. I want to compute some state from the props, but unless I know what the current props are, I'm not sure how I can avoid performing a potentially expensive operation.
e.g. I have some data coming in as a prop (an array with many elements). I want to to normalize this data and then put it in the state.
getDerivedStateFromProps sounds like it would be perfect for this, however, if some other prop changes, I really don't want to run this normalization step again because my data hasn't changed.
Previously I could check if(this.props.data === nextProps.data) in componentWillReceiveProps but now I can't.
Why do I have to store two copies in my state now? One for the normalized data, and another one for the unnormalized data so that I can check against the unnormalized data in the props This seems like a common use-case that used to be easy and now is hard, and now I have this dangling unormalizedData state that I don't even care about.

Hey @mnpenner, I am not giving you an advice. I just want to share my experience and I am not saying they make a good or bad move.
In my scenario, props.data is a simple int array and is used to compute a lookup table.
Before 16.3, I stored this lookup table in this instead of this.state. The reason of putting it in this was any changes to this lookup did not need to trigger a rendering immediately. I had a theory was any parameters affecting the rendering should be in this.state. Here is the sample and this.lookup also has contained the props.data.
this.props = [1, 2, 4];
this.lookup = [
  { "key": 1, "value": 1},
  { "key": 2, "value": 3},
  { "key": 4, "value": 7}
]

As I am doing the 16.3 migration for my lib, I have to move this.lookup table to this.state in order to have a similar 16.2 comparison between prevProps and nextProps. Luckily, this.lookup has contained the props information and my comparison has not been a simple reference check at the very beginning (before 16.2). So I still survive.
I guess your normalization process from this.props.data to normalizedData is irreversible (my scenario is reversible). This means if you only have normalizedData, you cannot get the original this.props.data. If it is reversible, you should be able to do the comparison without introducing the this.state.unormalizedData. But the downside is you need have some special logic for the comparison.

If the goal is not necessarily handling state but wanting to reduce the performance cost of an expensive one-way computation ny not executing it when data has not changed. Perhaps rather than using getDerivedStateFromProps a better fit for this use case is something like reselect's memoized selectors in render.

@mnpenner You don't have to store two copies of your state. You just store references for the next comparing. And it's do not introduce to you any cost except probably more characters for it. For me this api is much better than any other because it's explicit and allows to type code well.
"Why can't I use prevProps" question already was asked many times. Before there is not previous props then component is initialized. Passing any value will require additional check which makes code less readable. With state you have defaults in initial state which you may compare with new props. So the problem is solved.
There is not any special code here. It's dead simple I'd say.
class MyComponent extends React.Component {
  state = {
    prevData: [],
    normalizedData: {}
  }

  static getDerivedStateFromProps(props, state) {
    let state = null
    if (state.prevData !== props.data) {
      state =  {
        ...state,
        prevData: props.data,
        normalizedData: normalizeData(props.data)
      }
    }

    return null
  }
}

"Why can't I use prevProps" question already was asked many times. Because there is not previous props then component is initialized.

Couldn't prevProps just be null or undefined in this scenario? Why does there need to be an "additional check"? If developers want to ignore prevProps they can.
Your example will work AFAICT, it just feels like a downgrade from componentWillReceiveProps though. prevData shouldn't even be in the state IMO. Also, we can't defer setting the state with getDerivedStateFromProps, which means if normalizeData is async, we're out of luck, not even reselect will save us. With componentWillReceiveProps we could call this.setState whenever we were ready.
I guess the only choice is to use componentDidUpdate then? Seems strange to me to have to wait until after the component is rendered before I'm allowed to to start processing the new props.

Just an FYI, somebody opened an RFC to add prevProps to the getDerivedStateFromProps API over at #40.
They're looking for real use cases to justify adding it, so perhaps you can share over there if interested.

It's better to discuss the "why no prevProps param" issue in #40- but I think there's a couple of misunderstandings in the above thread that are worth addressing separate from that argument.
From comment:

I used to store things that don't affect rendering under this. too, but since getDerivedStateFromProps is static, we can't really do that anymore either.

Assuming these things are derived from (or otherwise related to) props - storing them on the class instance is usually not safe. This is the main reason why getDerivedStateFromProps is static.
This section of the React docs explains the difference between "render" and "commit" phases as does this lovely diagram. Computing and storing values on the instance from a render phase method (like componentWillReceiveProps) is usually unsafe because React may invoke render phase lifecycles without committing at all (because of an error or a higher priority interruption). In this case, your instance values could be based off of the wrong props. React manages this.props and this.state for you though, and always resets them to the correct values before calling your component lifecycles.
From comment:

e.g. This feels simpler to me but it has a silly caveat:

Sync rendering behavior for setState calls made from componentDidMount/componentDidUpdate  is actually a very important feature for libraries that need to do things like measure or position an element after rendering.

I am sorry if I have overlooked this, but to summarize, reading through this and linked comments, what I understand is that main reason for not having the current props as the third argument is that it will be a potential memory consumption/leak (and prevProps may even be included from other lifecycle methods for some reason, not sure why though). Is there any other reason?


Edit Public dashboard

The public dashboard:
https://wallet.gooddollar.org/AppNavigation/Dashboard/Statistics
The data should be edited based on the following information
https://docs.google.com/document/d/1kxg5Ba9KcdVq_91vt3oUjomoi7ske6n-SRd8c7K6kLw/edit
All designs should be based on the existing template.

moved details dashboard epic


Getting Insufficient Matic error when trading Matic to Eth on Eth

Overview
When trying to trade a token on Matic to Eth on Eth, it says there is insufficient matic to cover fees even if the wallet has enough to cover fees.
References and additional details

Log into app.shapeshift and connect to wallet of choice
Navigate to trade page and enter a trade with input asset being a polygon token
Enter the output asset as Eth on Eth
Note the error "insufficient MATIC on Polygon for fees" appears
**note it does not happen if the output asset is eth on op or eth on arbitrum

Acceptance Criteria
Should be able to trade token on polygon to eth on eth
Need By Date
No response
Screenshots/Mockups
No response
Ownership

[X] If my bounty needs engineering or needs product I have added the respective labels on the right
[X] As the sponsor of this bounty I will review the changes in a preview environment (ops/product) or review the PR (engineering)

Estimated effort
No response
Sponsor / Stakeholder
No response
Bounty Hunters

Join our discord
Include an expected timeline for you to complete work in the work plan when you apply for this bounty!
Please refer to this link for some basic info
Please do not start work on this issue until you are approved in Gitcoin.

will have to wait until polygon is synced but will test once its good again @0xean

Not getting the insufficient funds error anymore, just "unsupported trade pair" which is probably likely

lifi timeouts might be the cause of unsupported trade pair.


tweet embed options not being passed

I'm using the latest version 2.1.0 but I'm having trouble getting multiple options working:
{% twitter https://twitter.com/moyix/status/1486860078477156355 dnt=true width=350 conversation=none cards=hidden %}

Produces:

Wow, this looks like a big step forward for Binary Ninja! Congrats to @vector35, I'm looking forward to trying it out (especially the new Pseudo-C decompiler)! https://t.co/4GiBoS8NhP
— Brendan Dolan-Gavitt (@moyix) January 28, 2022

Notice that the width, conversation, and cards options are not being passed.
If I manually replace the liquid with the HTML and add the data-conversation, data-width, data-cards fields, the embed works as expected.

If anyone comes across this in the future, these are the embed options you want: https://developer.twitter.com/en/docs/twitter-for-websites/oembed-api#Embedded. These will work and are part of the API this plugin uses under the hood.


Image import: Support OVAs where enclosed vmdk has spaces.

Prior to this fix, if a user imported an OVA that contained "The Image Name.vmdk", they'd see the following logs and errors:
Import: Unpacking VMDK files from ova.
tar: The: Not found in archive
tar: Image: Not found in archive
tar: Name.vmdk: Not found in archive
tar: Exiting with failure status due to previous errors
Import: New source file is The Image Name.vmdk
...
Could not open '/daisy-scratch/The Image Name.vmdk': No such file or directory

Testing

Ran the new integration test

/gobuild

/flake8

/gocheck

/gobuild
/flake8
/gocheck


kubelet node watch should work in all api versions

My #6423 broke it for v1beta3, then #6442 fixed it for v1beta3 and broke it for v1beta1. I'm working on a fix.

Honestly I'm very surprised that more people aren't complaining-- integration test logs are full of noise because of this.

Exact text of error log is "Failed to watch *api.Node: field label not supported: metadata.name"

cc @wojtek-t


update script behavior section

Description (required)
Reworks the Scripts section of view-transitions.mdx, relativey significantly. Adds documentation for new attribute of <script> tags data-astro-rerun
Related PR
https://github.com/withastro/astro/pull/9977
For Astro version: 4.5
Would love your review on this @martrapp

As for the broken link: It is mdx. You could replace the ## with an <h2> and the old id or insert an anchor with the old id right in front of the ##, see suggestion.

As for the broken link: It is mdx. You could replace the ## with an <h2> and the old id or insert an anchor with the old id right in front of the ##, see suggestion.

Thank you that's brilliant

Sorry for the nitpicking. The main reason for the suggested changes are scripts like this:
<script type="module" data-astro-reload>...</script>

which are module scripts (= deferred loading) but not bundled (instead inlined) and can be re-executed without problems.

I appreciate the nitpick especially when its as easy as hitting commit suggestions haha and I really do want this section of the docs to be as clear as possible because this is a huge part of the view tranistions experience
haha at least running a module will run when its meant to (deffered) but yeah the whole any attribute creates is:inline is weird

@sarah11918  Could you take another look at this when you get a chance?

Yup! These 4.5 docs are on deck for this week! 🙌

Thank you! Great catch

@sarah11918 brilliant suggestions thank you