Weird corner case - URL and chicklet display disagree

The attached screenshot shows a recordset page in which there are no filters showing in the chicklet area, but the results are filtered (there are many world-readable entries in that table), and the browser's URL bar shows a filter.
I got there by visiting a RNASeq:Study record page, scrolling down to the Files area (which was empty), doing some other stuff for a while, and then coming back and clicking Explore. I was able to reproduce it by logging in, visiting a restricted Study file, manually invalidating my session, and then clicking Explore again.
You can sort of reproduce it by visiting https://dev.rebuildingakidney.org/chaise/recordset/#2/RNASeq:File/*::facets::N4IghgdgJiBcDaoDOB7ArgJwMYFM6JHQBcAjdafEAJQDkBBAZRwEcQAaEAMQEsAbHAPoMiaKAE8BVAJIARAQDMA1jjEgAugF8O0meo5YAFim64klAIwB2ALQA2ABoAWABzqNmoA@sort(Replicate_RID::desc::,File_Type,RID) -- you'll see the chicklet if you're logged in; you won't if you're not.
One other thing that might be relevant: the column being searched on is the Study RID; the additional information in the chicklet (the Study title) comes from a query of the Study table, and the result set of that query would be empty for an unauthenticated user. If that's the problem, then I think the best solution is to just show the RID alone in the chicklet when the Study query returns no results (either because of auth issues or because that record just doesn't exist).

As you mentioned this is happening because the user cannot see that row in the study table.
When you navigate to a page with facet, what's encoded in the facet is just the scalar value. In this case, it's the RID value. So we're doing an extra read to get the "row name" of that Study. But since the user cannot see that record, the response returns empty and ermrestjs is not properly handling this case.
I agree that the best solution would be showing the underlying scalar value to the users.

I pushed the following change to ermrestjs for this: https://github.com/informatics-isi-edu/ermrestjs/commit/d161d8c2d0056e2771110f62e645cb22090ba45d
I added a new test case and testing the changes on my user directory works in rbk.
I think hourly updates are turned off in rbk, so I couldn't test the original link in the issue. @ljpearlman Can you please verify and close this issue?

I am going to close this issue due to inactivity. We should create a new issue in case this bug is still not resolved.


Update go and fyne versions

Description:

Updates Docker base to Go v1.18.2, Fyne v2.1.4
Checklist:

Note: develop branch was already testing on Go v1.18.X in ci.yml

[x] Tests included.
[x] Lint and formatter run with no errors.
[x] Tests all pass.

Thanks for the PR. I think we were talking about getting Go 1.18 rolled out together with some other larger work but I’m not sure. Cc @lucor.

Yes, the plan was to release a new version of fyne-cross with Go 1.18.x when fyne 2.2.0 is out.

It is time :) Plus an update with some important fixes followed, so this should now use Fyne v2.2.1

@lucor Updated per suggestions


Consensus error when syncing from an old snapshot

Issue summary
Forest 0a85621ddcccda981c566e92e0321cc710639474 fails to sync from an older snapshot forest_snapshot_calibnet_2024-06-25_height_1732055 link
All goes well, until it reaches recent epochs and then it starts failing:
2024-08-07T10:55:22.021060Z  INFO forest_filecoin::chain_sync::tipset_syncer: Validating tipset: EPOCH = 1823977, N blocks = 2
2024-08-07T10:55:22.028158Z  INFO forest_filecoin::chain_sync::tipset_syncer: Validating tipset: EPOCH = 1823978, N blocks = 3
2024-08-07T10:55:22.036197Z  INFO forest_filecoin::chain_sync::tipset_syncer: Validating tipset: EPOCH = 1823979, N blocks = 3
2024-08-07T10:55:22.048367Z  INFO forest_filecoin::chain_sync::tipset_syncer: Validating tipset: EPOCH = 1823980, N blocks = 2
2024-08-07T10:55:22.058184Z  INFO forest_filecoin::chain_sync::tipset_syncer: Validating tipset: EPOCH = 1823981, N blocks = 3
2024-08-07T10:55:22.068021Z  INFO forest_filecoin::chain_sync::tipset_syncer: Validating tipset: EPOCH = 1823982, N blocks = 3
2024-08-07T10:55:22.093961Z  WARN forest_filecoin::chain_sync::tipset_syncer: Validating block [CID = bafy2bzaceappribw33awrgwuwdm3zvcvjd7a3mwur4f3ir3mlw7qi3so2pgu2] in EPOCH = 1823982 failed: Validation error: Validation error: Consensus error: Failed to verify winning PoSt: Unsupported mapping from Invalid(18) to PoSt-winning RegisteredProof
2024-08-07T10:55:22.094253Z ERROR forest_filecoin::chain_sync::tipset_syncer: Sync messages check state failed for tipset range
2024-08-07T10:55:22.095226Z ERROR forest_filecoin::chain_sync::chain_muxer: Bootstrapping failed, re-evaluating the network head to retry the bootstrap. Error = TipsetRangeSyncer(Validation("Validation error: Consensus error: Failed to verify winning PoSt: Unsupported mapping from Invalid(18) to PoSt-winning RegisteredProof"))
2024-08-07T10:55:22.095235Z  INFO forest_filecoin::chain_sync::chain_muxer: Evaluating network head...
2024-08-07T10:55:22.095252Z  INFO forest_filecoin::chain_sync::chain_muxer: local head is behind the network, local_epoch: 1823981, now_epoch: 1856724
2024-08-07T10:55:30.123933Z  INFO forest_filecoin::chain_sync::chain_muxer: Local node is behind the network, starting BOOTSTRAP from LOCAL_HEAD = 1823981 -> NETWORK_HEAD = 1856725
2024-08-07T10:55:30.535866Z  INFO forest_filecoin::chain_sync::network_context: Decreased chain exchange timeout to 2000ms. Current average: 12ms
2024-08-07T10:55:30.643191Z  INFO forest_filecoin::chain_sync::tipset_syncer: Validating tipset: EPOCH = 1823982, N blocks = 3
2024-08-07T10:55:30.646183Z  WARN forest_filecoin::chain_sync::tipset_syncer: Validating block [CID = bafy2bzaceappribw33awrgwuwdm3zvcvjd7a3mwur4f3ir3mlw7qi3so2pgu2] in EPOCH = 1823982 failed: Validation error: Validation error: Consensus error: Failed to verify winning PoSt: Unsupported mapping from Invalid(18) to PoSt-winning RegisteredProof
2024-08-07T10:55:30.646959Z ERROR forest_filecoin::chain_sync::tipset_syncer: Sync messages check state failed for tipset range
2024-08-07T10:55:30.648172Z ERROR forest_filecoin::chain_sync::chain_muxer: Bootstrapping failed, re-evaluating the network head to retry the bootstrap. Error = TipsetRangeSyncer(Validation("Validation error: Consensus error: Failed to verify winning PoSt: Unsupported mapping from Invalid(18) to PoSt-winning RegisteredProof"))
2024-08-07T10:55:30.648184Z  INFO forest_filecoin::chain_sync::chain_muxer: Evaluating network head...

Note that the snapshot is pre-waffle upgrade.
Other information and links

It's likely a regression, d00361ccc3d01264acdae8cc8a22938f5f24716b works fine.


Support math functions?

If we want to support common statistical tests as models, or support logged variables, we might want to add the ability to do stuff like this:
mod_log <- lm(log(mpg) ~ cyl + disp, mtcars)
extract_eq(mod_log)

Right now, it drops the log, but it'd be cool to have it return \log \text{mpg}
BUT this is probably going to be really hard / impossible, since there's not a one-to-one mapping between R functions and LaTeX functions. I guess we could wrap any R function in \operatorname{blah} for stuff like lm(signed_rank(y) ~ 1)?

I think this is a good idea but I'd vote we hold off on this for the time being. Maybe this is a version 0.2 feature after we get it an initial version on CRAN?
One option to get the mapping to work would be to build up a table that has the r code in one column and the corresponding LaTeX code in a second column, then we could use match or similar to do the cross-walking. Just a thought...

This is also related to https://github.com/datalorax/equatiomatic/issues/1#issuecomment-496776981 . We can have some specific math functions to look up in a table, like logit, probit, log, etc. and anything else that appears can just go in \operatorname{}, like \operatorname{signed_rank} or \operatorname{exp}

With https://github.com/datalorax/equatiomatic/pull/73, functions no longer disappear, so we could do some math operator replacement, but it has a lot of strange edge cases (\log and \exp are easy enough, but fractions will get complicated, and any arbitrary functions will need to be ignored). We can probably wait for the next release for the math


Pin actions to commit SHA

A best practice for using third-party actions is to always pin to a specific commit SHA.
One of the purposes of this repository is to provider a collection of secure, reusable workflows. Since the abstraction of our workflows removes the need for users to update actions, migrating from version tags to commit SHAs should increase the security of our workflows without requiring any actions from our users.
Internally, we use Dependabot to keep actions updated, anyway.
For each action call in this repository, go to the repository for that action and grab the corresponding commit SHA for the currently used release tag. Replace the release tag with that commit SHA.
Update best practices as well to clarify that you should pin to commit SHA for all actions, not just user-created actions.
Tasks

[x] #522
[x] #523
[x] #524

All tasks complete 😊


Exams by Anton Dovzhenko, IM-22 group

Good job, code indeed became better

Do not commit a bunch of IDE and environment files, just sources


docs: Update svar access documentation.

Should doc/source/user_guide/index.rst also be updated from solver.field_data to solver.fields.field_data?

Yes, Thank you @raph-luc.


Feature Request: Go Formatting in Docker Info

Howdy.
I think it would be super-awesome-neato-kean if docker info supported -f {{data stuff}}.
Right now my use case is simply having a quick and easy way to check the number of stopped containers, and I'd like to do something like docker info -f {{.Containers.Stopped}}   rather than docker info |cut/awk/whatevs.
Thanks.

docker ps --filter status=exited  -q | wc -l?

Yeah, I can do it, I mean the task I would use it for is already written and in use. I was just thinking long-term it might be nice to have everything following  the same formatting system to provide information.

@DamionWaltermeyer I'm pretty sure https://github.com/docker/docker/pull/23808 implements what you need — It will be available in 1.13.0 :wink: .

So it will, my apologies, I didn't see it when I was searching earlier.    Thank you very much.


Firmware version in LoRa payload

A LoRa packet on startup (perhaps at intervals as well) should contain the firmware version (e.g. v1.0.1).
Perhaps this should contain firmware from both sensor micro and telemetry micro.

If we make this periodic, such as daily, we can use a confirmed uplink to check the session is still valid.
We could also include known sensor info in this message, based upon an SDI-12 bus query. That won't cover analogue and digital inputs though.
We also need to think how this fits with other transports.

We decided against including LoRaWAN.


support reference_time for duckling

Proposed changes:
Duckling module also supports passing a context using reference_time argument. We can pass a string in RFC3339 format (Eg: '2008-09-08T22:47:31-07:00').
Example: Parsing "tomorrow" with reference_time set to 2008-09-08T20:30:00-07:00 gives back
2008-09-09T00:00:00.000-07:00
Since Rasa supports duckling in the pipeline, I think this will be a useful addition.
Status:

[ ] ready for code review
[ ] there are tests for the functionality
[ ] documentation updated
[ ] changelog updated

The emulator tests are failing. I shall make the corrections.
But I noticed thats there is an issue with duckling. It doesnt handle timezone offsets with non-zero minutes (https://github.com/wit-ai/duckling_old/issues/209)
So will this feature be useful?

The usefulness of this feature is that the duckling can parse the input string by using the desired context (time with timezone) and we get the exact timestamp as the parsed output. I think we should pass the timezone info somehow for parsing. If we just pass the timestamp in milliseconds, the zone info is lost.
We can also take timezone info separately!
time for time in milliseconds and timezone for taking the offset in minutes like the below request.
http://localhost:5000/parse?text=Call%20me%20tomorrow%20morning%20at%208&time=1496055692128&timezone=-330
Then we also have to validate the timezone offset value.

Another way to standardise would be to take just time in millis and always assume timezone as UTC. So that the users can convert the parsed time to whatever zone they want in their applications.

Alright, lets use a UTC ISO time string then. :+1:

Coverage decreased (-0.2%) to 92.549% when pulling 4db7ec4d45f95b0bb4b865b84aec96b6e90f7c10 on verloop:duckling_ref_time into 48a3dece9cca4a27381c4b3926586a20bf565a15 on RasaHQ:master.

Sorry @vinvinod I totally forgot about this one. If you don't mind fixing the merge conflicts with master, I could merge it afterwards.

nice work 😃 :+1:

👍


Block import from paths that contain the repo storage namespace

It makes no sense to import lakeFS metadata and data to lakeFS.
It causes errors in S3 due to keys not being sorted:

Writing range from entry iterator: writing record: setting key and value: pebble: keys must be added in order: #0,DEL #0,SET

Dup of #4018


data: add profile

Hey there! Exciting news! I've created an open source project called "devFind" where you can add your profile and others can search by skills. Join in and contribute to make it better!
You can start with adding your profile. Check the Readme file if you are a beginner.

Good day @shyamtawli
I made a PR after adding my profile to the specified files. Please have a look at it. Thank you.

@Lansa-18 I will check it out, thanks for the contribution.

Please do
Thank you @shyamtawli .


Add Sunlu Elite Series PETG in Black

Add Sunlu Elite Series PETG in Black

The material field should be set to just "PETG", then you can put e.g. "Elite {color_name}" as the filament name if you want to specify that it's a Elite series filament.


Balder/correct reserialization

@vekterli and @toregge PR
The first commit has no sematics, the latter is the important one.

I will just let factory give it a go to see if any stuff breaks. Please review at earliest convenience.


Add more padding/margin after Text field and Chips

How can i add padding / margin between textfield and chips?

Package Revived #8


hooks moved to /hooks dir

IMHO there is a better and more elegant way to install hooks.
I think that you could consider a small refactoring on your project and move hooks to /hooks dir.
Then your hooks could be installed with git init --template=<template_directory> where <template_directory> is folder with this project repo cloned from github.
In this way there is no need to delete or symlink hooks folder (this is safe for other hooks in existing project). git init is safe for existing repositories.

I'm not going to merge this:

Moving all hooks to a sub-directory is an unnecessary BC break, anyone pulling this change will need to change the symlinked/configured hooks directoy. Although I agree that a dedicated sub-directory is a bit cleaner, it isn't worth the BC break IMHO.

There's some logic introduced in https://github.com/marcinant/git-flow-hooks/commit/98a6dffe7d5912d070de1ac8fe9bbf338bd4a225, which seams to initialize git-flow when it hasn't been initialized yet. This would enforce the usage of git-flow, which I do not agree with. That choice belongs to the user.

I do agree that the installation procedure an be simplified. I think we can go even simpler: The latest version of git-flow (avh) will ask for a hooks and filters directory. If git-flow is already initialized, you can still configure the path: git config gitflow.path.hooks /path/to/git-flow-hooks.

Ok. So, I'm going to merge these features to master on my fork and maintain this as separate project.
However few comments:

Personally I don't care about existing users. If they followed your readme and performed primitive procedure to install hooks then it's their and your choice.

I'm going to use this project with hooks in separate directory. Then I can configure git:
git config --global init.templatedir '~/git-flow-hooks
Every time I clone repository all hooks I need are installed automatically and gitflow is initialized. No need to symlink etc. The same applies for installation on existing repo. I described this earlier. (git init --template=~/git-flow-hooks)

With logic introduced in marcinant@98a6dff I can create and initialize an empty repository which is automatically prepared to work with gitflow.

I also don't agree with this opinion: "This would enforce the usage of git-flow, which I do not agree with. That choice belongs to the user."
User who symlinks your hooks or use my fork as git template is going to use gitflow.
This is the moment when user performed his choice.
If user still needs your hooks but doesn't want to initialize gitflow automatically, then simple solution is to delete post-checkout hook.

Personally I don't care about existing users.

I initially created this project for the pure benefit of me and colleagues that work at the same company as I do. Now that it became somewhat popular, my aim is to be flexible and try to provide something that is usable for a wide range of cases/people.

User who symlinks your hooks or use my fork as git template is going to use gitflow. This is the moment when user performed his choice.

I meant this choice on a repo basis. I personally don't use git-flow for every repo. Some are too small and only maintained by me, so I don't need it there. Git-flow was thought up as a solution for a certain problem. When I don't have that problem, I don't need the solution.

Ok. So, I'm going to merge these features to master on my fork and maintain this as separate project.

Please do! If you are going to use git-flow for every repo, I can imagine the setup can become bothersome.
I didn't mention it explicitly, but I've updated the readme with a simpler installation/activation procedure.
Also note that all the git-flow configuration options can be set at a global level.

I understand. If you have strong user base then you need to take care of them.
However I think that my fork is just better and this is why I'm going to use it on my daily basis :)
I just prefer git template option instead of symlinking.
If I want to use gitflow on project then I clone repo with --template=./.config/git/git-flow-hooks.
If I don't want to use gitflow then I just simple clone without template or with another template dir.
It's simple and elegant. No symlinks (which can be broken). No need to initialize gitflow manually on each clone.

@marcinant There is another way for every project to use these hooks. Simply execute
git config --global --add gitflow.path.hooks d:\Path\to\git-flow-hooks\


Emit typescript types on build

Is your feature request related to a problem? Please describe.
While using this library there is absolutely 0 typing information available on import. There is a constant need to have the docs open or div into the source code itself to be able to use this library.
Most of the code is written in typescript why wouldn't types be emitted?
Describe the solution you'd like
Typescript definition files should be emitted on build.
Describe alternatives you've considered
I suppose I could generate my own and commit them to DT but I feel that wouldn't be the right approach.

After importing the types it also seems that they're incorrect.

Thought it'd be simple fixes but this library seems like it's dynamically created and promisified, will need more work to get definitions working correctly.


Questions about equation (10) in the paper

Dear authors,
Really nice work!
I tried to read the code, and found an issue that the implementation is a little different from that in equation (10).

In the repo, it's
def _std(self, t):
        # This is a full solution to the ODE for P(t) in our derivations, after choosing g(s) as in self.sde()
        sigma_min, theta, logsig = self.sigma_min, self.theta, self.logsig
        # could maybe replace the two torch.exp(... * t) terms here by cached values **t
        return torch.sqrt(
            (
                sigma_min**2
                * torch.exp(-2 * theta * t)
                * (torch.exp(2 * (theta + logsig) * t) - 1)
                * logsig
            )
            /
            (theta + logsig)
        )```

 in `sgmse/sdes.py`.

Can you explain the differences? Thanks!

这个公式的代码  好像确实和paper中的公式（10）对应不上，你当时是怎么理解的？


Re-enable previously failing FT to test in preview

Change description
It was failing due to a move to CDAM causing issues with us using fake ccd cases and document generation. Testing if this is still an issue

Although some tests were fixed, it seems many are still broken. This is due to cdam needing a real ccd case id for documents. I've tried creating another branch which uses a real ccd case id but the pre-made request we fire into the FTs which contain existing documents, fail as they don't technically belong to the case.
Closing this PR. Going forward we will likely move to playwright and make these tests priority for first written tests.


hotfix CORS

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.tarokkk seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Feature request: increase max # files which can be opened by the leader key (V2)

environment
vim: vim8
vim-airline: latest
OS: Linux/Mac/Win
Have you reproduced with a minimal vimrc: feature request
What is your airline configuration: feature request
Currently, the max # of files which can be opened with the leader key is only nine, which too small for a practical use on large project.
Is it possible to provide two modes (controlled by a flag maybe):
Mode #1: which is the current style. The count # is from 1-9.
Mode #2: The count # is from 11-99.
When in mode #2, user always need press  and 2 number keys to switch. So there will be no delay issue.
I posted this suggestion on the previous request link. But I don't hear from you. So I posted a V2 suggestion. Wish this would not make you feel too mad ^_^

The only diff between mode #1 and #2 is the # range. The # always increases sequentially.
In mode #1, 1st file-> 1, 2nd file -> 2, 3rd file -> 3 .... 9th file -> 9 (arrow means map)
In mode #2, 1st file-> 11, 2nd file -> 12, 3rd file -> 13, ....., 89th file -> 99.
I understand that mapping 1st file -> 11 looks bit weird. But it's handy when switching file. What do you think?

But how do you know, that you need to press e.g. <leader>21 and not <leader>22? Where do you get the number from. Surely you cannot remember for each buffer its buffernumber.

BTW, in the above image, after BL, it shows E541. Is it a bug? I though it should show BM, then BN, then BO .....

Also please note, according to the documentation, you can already map
nmap <leader>- <Plug>AirlineSelectPrevTab
nmap <leader>+ <Plug>AirlineSelectNextTab

That supports v:count1 so using that you can use any number you need to switch buffers/tabs.

is not good, because it requires you to  either remember or run "ls" to figure out the buffer # of the buffer you want to switch to, before you switch.

Regarding E541, that is a limitation of Vim. As mentioned in the documentation, it only allows 80 items inside the statusline/tabline. I thought there was a wishlist issue already open for vim, to increase this limit, but I cannot find it. You might open a new one and explain your usecase (4k monitor, many buffers, etc) and show the screenshot. For the other thing, I'll have to reconsider.

Though 9 is small # when working on a large project, 80 should be fine to me.
Anyway, whether you approve the feature request or not, I appreciate your reconsideration.

Hi chrisbra, May I ask you a quick question? Do you know if anyone is working on this feature request? And do you have a draft idea when it could be implemented? Thanks.

just included the feature experimentally.

Thank you very much. I really appreciate!!!
Just tried.
One minor request: could you please adjust the 1st file number from 10 to 11? Reason: assuming 1st file is the most commonly used file, to type "10", you need use little finger from two hands. But to type "11", you only need little finger from one hand.
What do you think?

okay, I have just pushed a slight modification.

Thanks. Really appreciate.


InvalidAddr warning reported and non-working advertisements with empty scan_data and recent rustc

We'd been pinned to rust v1.75 (nightly 2023-08-08) with code that worked fine when passing in scan_data: &[] when it built a ConnectableAdvertisement::ScannableUndirected advertisement.  We used only the adv_data portion, and didn't want any scan data.
Once we tried going to rust versions starting around 2024, including with the recent rust v1.85 (nightly-2024-12-01), this code still compiled but led to the advertise_connectable() call logging a warning, and no advertisements showing up.
220.121 WARN : nrf_softdevice::ble::peripheral || sd_ble_gap_adv_set_configure err InvalidAddr
220.121 WARN : nrf_softdevice::ble::peripheral || sd_ble_gap_adv_stop: InvalidState

After experimentation we found a viable workaround, apparently without negative side-effects, by passing in scan_data: &[0u8] instead.
I don't understand the cause yet.  It appears consistent with the SoftDevice applying an unnecessary check that any non-NULL pointer must have non-zero length data.  The nrf-softdevice code provides no way to ensure that an actual NULL pointer is passed into the sd_ble_gap_adv_set_configure() routine, however, as we can't directly supply a RawAdvertisement with None for the scan_data field, but only the ScannableUndirected which requires a valid slice.
I get the impression using .as_ptr() to get an address for an empty slice may produce bogus values that are never meant to be used, such as 0x1, or really anything other than a NULL.  It seems possible that the SoftDevice is applying some checks to those addresses before noticing that the length is zero.  Possibly it insists that it be a valid RAM or flash address, or above its own region of memory. In any case, it seems that it may be a latent bug if we ever supply an address to the SoftDevice produced by as_ptr() on an empty slice, so I would suggest possibly the map_data() closure in start_adv() should check the length first, and always supply ptr::null_mut() as the address if the length is zero. Does that make any sense?

A better workaround is to do it as I just saw some examples do, with a static SCAN_DATA: [u8; 0] = [];.
This appears to work because it provides an address in flash memory.  If you use const SCAN_DATA: [u8; 0] = []; instead, the as_ptr() produces a 1, which since it's definitely not a valid place for actual data seems to be why the SoftDevice complains about it.

Long story short: despite the workaround appearing to work fine, I'd propose changing map_data() to check the length and substitute an explicit null_ptr() in the event the length is zero.  I believe that will avoid the issue in all cases, with no downsides.


Making alpha diversity boxplots in R using .qza files

Dear,
I am trying to import the following files faith_pd_vector.qza, shannon_vector.qza and observed_features_vector.qza from the core-metrics-results folder into R to make box plots as shown below.
Can someone please help me import my files into R and make box plots?
Thank you!

Please reach out to the QIIME 2 community for this.


Update site design

This PR updates the entire frontend with a new design.  The landing page is styled after our redesigned landing page file minus the signup form.  All other pages are styled after a previous design with modifications made to more closely match the theme of the landing page.
The following updates have been made in the process:

Bootstrap has been removed in favor of Tailwind
Glyphicons have been replaced with SVGs
The Form facade has been removed in favor of Laravel 7 Blade components
Added a featured column to the users table to feature speakers on the landing page
Added a featured column to the conferences table to feature conferences on the landing page
The unused AuthorsController has been removed

Screenshots

Landing page
Desktop

Mobile

Guest pages
How it works

Speaker list

Public speaker profile

Public speaker profile mobile

Public speaker talk

Public speaker bio

Public conference list

Public conference list without matching filters

Mobile conference list

Public conference show page

Nav open

Mobile nav open

Login

Auth pages
Dashboard

Bios list

Bios list mobile

Edit bio

Conferences list

Conferences list mobile

Calendar

Talks list

User menu

Account details

Edit account

Delete account

oAuth settings

Deployment

composer install
php artisan migrate
npm install
npm run production

Future improvements

The calendar and oAuth settings pages have had few changes outside of colors
The My Talks section of the authenticated user's conference show page has not had any changes other than colors and spacing
The flash messages still use bootstrap styles placed inside of app.scss

Goodness. This PR is:

Welcome
Exhaustive
WELL-described! What a fantastic body of a PR description
SCREEN-SHOTTED!

Just look at this!!

Bootstrap has been removed in favor of Tailwind
YESSS THANK YOU JESUS

Glyphicons have been replaced with SVGs
Oh yahhhhh

The Form facade has been removed in favor of Laravel 7 Blade components
Oooo I haven't had much chance to play with components. Can't wait to read it.

Added a featured column to the users table to feature speakers on the landing page
CLEVER!

Added a featured column to the conferences table to feature conferences on the landing page
CLEVER!

The unused AuthorsController has been removed
👌🏻

I'm going to work through the design and make some notes that I think we can save for a later PR.
Then I'll review the code.

Design notes for a later PR update, not to hold up this PR:

I think we can update the style of these a bit. Different line height, maybe a different type treatment on the metadata.

I think this can be "CFPs"

I think this body text background color should be something other than the normal background color.

I think it'd be nice to get an actual layout here, maybe a right float and/or some kind of special treatment

I think we should use a different color here than this blue bg
But this is so good. Again, don't worry about these items now. off to the code review!

Hey Matt, thank you for your kind words about the PR :) I went ahead and made the CFP's -> CFPs change and I'll note the other design changes you mentioned for a future PR.

@mattstauffer Thanks for the feedback 😄 I just made the changes you suggested 👍

Thanks so much for your amazing hard work on this!!


Help needed

Hi, I tried to implement this lib in an empty project with react router, but I did not succeed is there an example anywhere ? (with or without router).
Thanks

@JiDai Hi! Can you give me more details, please, what problems did you have with setup? All you need to do is to add middleware to your store builder, as described here.

Hi,
I don't understand how the fetched data is injected in the store.
I have made a little project to test the case : https://github.com/JiDai/redux-async-initial-state-example
At the line :https://github.com/JiDai/redux-async-initial-state-example/blob/master/src/main.js#L27 : how I can pass the data to the store ?
For now I have the following error :
Unexpected keys "id", "name", "username", "email", "address", "phone", "website", "company" found in previous state received by the reducer. Expected to find one of the known reducer keys instead: "asyncInitialState". Unexpected keys will be ignored.
Thanks

@JiDai I've created a pull request in your example with explanation and fix. Let me know if you need something else!


Rephrase thing to identifier

While defining type annotations to entities like variables, functions, etc., I feel it makes much more sense to use the terminology identifier instead of simply calling it a thing.

I personally don't think that it's an improvement as-is; this page is mainly a page for beginners and doesn't use the word "identifier" at all except in one error message. It's also inaccurate for destructurings like const { foo } = ..., because a colon after the identifier renames the variable, it doesn't type it.
I think this sentence is mainly trying to indicate the "general scheme" of TS's typing where the type annotations for everything go after, i.e. return types too, and not be too specific about one particular syntax.


Unable to build main following "Move to PGO Nuget" change

Windows Terminal version
main 8dfdfc4
Windows build number
10.0.22000.376
Other Software
Visual Studio 2019
Steps to reproduce
Attempt to build the project in Visual Studio.
Expected Behavior
The project builds.
Actual Behavior
Lots of errors, referencing Microsoft.PGO-Helpers.Cpp.0.2.22
Severity	Code	Description	Project	File	Line	Suppression State
Error	MSB4019	The imported project "F:\windows-terminal\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" was not found. Confirm that the expression in the Import declaration "F:\windows-terminal\build\PGO\..\..\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" is correct, and that the file exists on disk.	Microsoft.Terminal.Remoting	F:\windows-terminal\build\PGO\Terminal.PGO.props	44
Error	MSB4019	The imported project "F:\windows-terminal\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" was not found. Confirm that the expression in the Import declaration "F:\windows-terminal\build\PGO\..\..\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" is correct, and that the file exists on disk.	Microsoft.Terminal.Control.Lib	F:\windows-terminal\build\PGO\Terminal.PGO.props	44
Error	MSB4019	The imported project "F:\windows-terminal\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" was not found. Confirm that the expression in the Import declaration "F:\windows-terminal\build\PGO\..\..\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" is correct, and that the file exists on disk.	TerminalAzBridge	F:\windows-terminal\build\PGO\Terminal.PGO.props	44
Error	MSB4019	The imported project "F:\windows-terminal\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" was not found. Confirm that the expression in the Import declaration "F:\windows-terminal\build\PGO\..\..\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" is correct, and that the file exists on disk.	Microsoft.Terminal.Settings.Model.Lib	F:\windows-terminal\build\PGO\Terminal.PGO.props	44
Error	MSB4019	The imported project "F:\windows-terminal\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" was not found. Confirm that the expression in the Import declaration "F:\windows-terminal\build\PGO\..\..\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" is correct, and that the file exists on disk.	TerminalAppLib	F:\windows-terminal\build\PGO\Terminal.PGO.props	44
Error	MSB4019	The imported project "F:\windows-terminal\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" was not found. Confirm that the expression in the Import declaration "F:\windows-terminal\build\PGO\..\..\packages\Microsoft.PGO-Helpers.Cpp.0.2.22\build\Microsoft.PGO-Helpers.Cpp.props" is correct, and that the file exists on disk.	TerminalAppLib	F:\windows-terminal\build\PGO\Terminal.PGO.props	44

If I attempt to do a nuget restore OpenConsole.sln I get a warning stating it can't read the project configuration.
F:\windows-terminal>nuget restore OpenConsole.sln
MSBuild auto-detection: using msbuild version '<IP_ADDRESS>704' from 'D:\Microsoft Visual Studio\2019\Community\MSBuild\Current\bin'.
WARNING: Error reading msbuild project information, ensure that your input solution or project file is valid. NETCore and UAP projects will be skipped, only packages.config files will be restored.
All packages listed in packages.config are already installed.

Yeah, we should not depend on this package outside of CI or local PGO testing.
For now, does it unblock you to nuget restore build/packages.config?

Sorry @ianjoneill. I didn't notice because my machine already had the package from screwing around trying to set it up. I believe I fixed it quick and tried with a fresh repo in #11981.

Thanks for the explanation and the quick fix. Happy holidays!


Allow selected pods to prevent reboots

This PR adds functionality to block individual nodes from rebooting in the presence of specific pods, as determined by a label selector:
--blocking-pod-selector=runtime=long,cost=expensive

see documentation in the commit for more details.

Good spot. It's because I updated the entire flags block by cut and pasting the output of kured -h...


Collapsing doesn't work after release v2.0.5

After this release, collapsing doesn't work.

I think you mean the same issue as in here: https://github.com/dcasia/collapsible-resource-manager/issues/120 which is now fixed


How can I get error?

After I called below method I cannot catch error message when the error occurred.
await eos.CreateTransaction(new Transaction()
How can I catch error message when the error occur?

you just try catch eos.CreateTransaction and handle the ApiErrorException.


Running On Raspberry Pi 4

Hii, I am really new to the community, and I have hit rock bottom on this
I have been trying for weeks to test the model on the Raspberry Pi 4 but to no avail. From what I understand, I am suppose to run the engine.py file and specify the model file. However, the engine.py requires the torch, torchaudio, and several other packages which are not in the rpi-requirement.txt file.
So I have tried to download the packages with the requirements.txt file, but there are always errors such as (unable to locate version). This also happens when I try it with the rpi-requirements.txt file. I have suspected that it was my OS version, and python issue. But after going through multiple versions and even ubuntu versions, I still cannot get it to work.
I just wanted to ask if there is any specific raspbian OS, python, or pip version that I need? Or maybe am I on the wrong track?
I have finished training the model and optimizing it on my PC, I just cant get it to work on the Raspberry
Edit:
I have solved the problem. The engine.py file runs okay if you are using torchaudio 0.7.2 with torch 1.7.1.
Or you could use newer torch and torchaudio versions, but you will need to change the code from normalization to normalize. Downloading torchaudio 0.7.2 was done using pip install with reference to the pytorch website.

[UPDATE]
After further testing, it is found that performance may be better with versions of torchaudio 0.5.0 and torch 1.5.0.  Additionally, training the Model with a 50/50 split for Wake Word and Non Wake Word class may not yield the best results. From my experience, 10/90 split works better.


vimPlugins.fidget-nvim: switch to legacy branch

Description of changes

fidget.nvim is currently going through a complete rewrite. In the meantime, the users are expected to use the legacy branch.
bitbake.vim's source is now missing from github. Hence I removed it from the plugin list

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 244652 run on x86_64-linux 1 78 packages built:  vimPlugins.ChatGPT-nvim vimPlugins.LazyVim vimPlugins.LeaderF vimPlugins.SchemaStore-nvim vimPlugins.YouCompleteMe vimPlugins.barbecue-nvim vimPlugins.bufferline-nvim vimPlugins.catppuccin-nvim vimPlugins.chadtree vimPlugins.codeium-vim vimPlugins.completion-treesitter vimPlugins.coq-artifacts vimPlugins.coq_nvim vimPlugins.dart-vim-plugin vimPlugins.denops-vim vimPlugins.deol-nvim vimPlugins.diffview-nvim vimPlugins.dropbar-nvim vimPlugins.elixir-tools-nvim vimPlugins.executor-nvim vimPlugins.eyeliner-nvim vimPlugins.fidget-nvim vimPlugins.flash-nvim vimPlugins.flatten-nvim vimPlugins.gitsigns-nvim vimPlugins.goto-preview vimPlugins.lazy-lsp-nvim vimPlugins.lazy-nvim vimPlugins.lean-nvim vimPlugins.leap-ast-nvim vimPlugins.lspsaga-nvim-original vimPlugins.luasnip vimPlugins.mason-lspconfig-nvim vimPlugins.mini-nvim vimPlugins.monokai-pro-nvim vimPlugins.neo-tree-nvim
vimPlugins.neodev-nvim
vimPlugins.neogit
vimPlugins.neorg
vi

I added bitbake.vim back manually to overrides.nix since the cached version still works

Maybe, the rewrite has done.


Final results of collaboration with Google and The Forge

As previously announced we have been working with Google and The Forge to bring a bunch of performance improvements and other enhancements to our mobile renderer.
The work has concluded so it is time to share the results, test it, and integrate it into upstream Godot. This PR is huge and touches a lot of areas. I expect that this branch will not be merged as-is. Instead this serves as a place for us to test the full work product, and cherry-pick safe commits. This branch was rebased on upstream recently and should not be too far out of date. Given its tremendous size though, I expect that it will fall out of date quickly. So we should aim to start merging what we can sooner rather than later.
Results
We tracked performance using two devices (Samsung S23 and Google Pixel 7) and using two test scenes (a modified version of the Sun temple scene and a modified version of the TPS demo)
TPS_demo.zip
Sun_temple.zip
Most importantly, GPU time has reduced across the board which is our biggest bottleneck on mobile devices.
Pixel 7
  | Sun Temple OPT | Sun Temple (UNOPT) | Third Person Shooter (OPT) | Third Person Shooter (UNOPT)
-- | -- | -- | -- | --
Frame time | 26.1 ms | 29.1 ms | 36.4 ms | 37.1 ms
GPU frame time | 25.81 | 28.60 ms | 35.03 ms | 35.81 ms
CPU frame time | 4.85 ms | 5.01 ms | 3.67 ms | 3.53 ms
Vk Memory | 2487.53 MB | 2488.47 MB | 554.64 MB | 555.93 MB
Samsung S23
  | Sun Temple OPT | Sun Temple (UNOPT) | Third Person Shooter (OPT) | Third Person Shooter (UNOPT)
-- | -- | -- | -- | --
Frame time | 16.0 ms | 22.1 ms | 38.3 ms | 41.4 ms
GPU frame time | 19.6 | 24.74 | 42.6 ms | 46.6 ms
CPU frame time | 4.2 | 5.27 | 3.72 ms | 3.30 ms
Vk Memory | 995MB | 980MB | 593.8 MB | 593.18 MB
Conclusion
Thank you very much to Google and The Forge who made this work possible! The results are very exciting and we are looking forward to getting everything integrated into upstream Godot

Was the benchmark compared to 4.3 or 4.2?
If it was compared to 4.3 then would the difference be bigger when tested with 4.2?

I only took a very mild glance over the changes.
I noticed they got rid of push constants for regular UBOs. I think that's something we really want to adapt into v4.3.
This also means that code that previously was directional_light_buffer became directional_light_buffer[RD::get_singleton()->get_current_frame_index()] which is how things should've been done in the first place. We'll want to adapt that too (it's probably tied hand in hand with the push constants changes).
The real question is how hard it will be to port over.

This would benefit from being broken up into dedicated areas, there's a lot to clean up and review and it's a bit huge at the moment

Is there someone who is really expert at git?
The commits have diverged so much that the diff that both Github and git are showing is useless.
For reference, if I undo all the changes to thirdparty folder and try to manually merge the code, the diff is nowhere near that scary:

Very few merge conflicts; and that's the actual changes to Godot.
However if I try either:
git diff master..TF_final
git diff master...TF_final

In both instances I get a diff that contains garbage changes in the diff that are not in the merge.
It is very distracting.
Does anyone know a way to get a useful, user-friendly diff with only the relevant changes?
I can do that locally in git-cola of course; but I'd like to put them online so that everyone can put their eyes on.

In both instances I get a diff that contains garbage changes in the diff that are not in the merge.

That's because this branch is behind by over a thousand commits, nothing wrong

That's because this branch is behind by over a thousand commits, nothing wrong, you need to check against the base of the branch

I get that "this is how git works" and "technically there is nothing wrong", but it makes the diff shown in Github impossible to review online. It needs to be done offline.
I'm asking if there is a way to publish online something user friendly that everyone can take a look at. Because right now Github (and git) says there's 300k LOC to review, but the actual amount is nowhere remotely close to that.

the actual amount that needs reviewing is nowhere remotely close to that.

What are you basing that on? It's right there, the changes in the list here is the changes, it's not different

What are you basing that on? It's right there, the changes in the list here is the changes, it's not different

If I type (using my fork which stripped thirdparty changes):
git merge-base master TF_final
# Yields bb6b06c81343073f10cbbd2af515cf0dac1e6549
git diff bb6b06c81343073f10cbbd2af515cf0dac1e6549..TF_final

I get lots of irrelevant stuff in the diff like this:
diff --git a/thirdparty/thorvg/update-thorvg.sh b/thirdparty/thorvg/update-thorvg.sh
index 2811a43339..7a754c09b9 100755
--- a/thirdparty/thorvg/update-thorvg.sh
+++ b/thirdparty/thorvg/update-thorvg.sh
@@ -1,6 +1,6 @@
 #!/bin/bash -e

-VERSION=0.12.5
+VERSION=0.12.9

In both latest master and latest TF_final VERSION=0.12.9 so I don't really care about reviewing this change.
And as expected, git-cola does not ask me to review this change when trying to merge (see picture I uploaded. Changes to update-thorvg.sh are nowhere to be seen).
The same problem happens if I type:
git diff master..TF_final

That change to update-thorvg.sh also appears, despite being just noise for reviewers.
I get that "technically" update-thorvg.sh was changed by both master and TF_final in the same way ever since they've diverged from their shared ancestor; but it's just noise. And there's a lot of noise to filter out.

I brute-forced the problem!!!
THESE ARE THE ACTUAL CHANGES THAT NEED REVIEWING.
75 files, 4366 additions, 717 deletions.
Much cleaner.

Well that still requires this PR to be cleaned up, there's no ability to review that, you can't review on that

Well that still requires this PR to be cleaned up, there's no ability to review that, you can't review on that

The PR will likely not be merged "as is" but rather split up into smaller chunks for integration.
I know that the link I posted can't be reviewed using Github's interface; but it gives an overview of what to expect: The changes are nowhere that scary. In fact very reasonable. But right now GH is showing 10:1 of noise to signal ratio.

The PR will likely not be merged "as is" but rather split up into smaller chunks for integration.

And that's why I asked for it for the purposes of reviewing :)

Was the benchmark compared to 4.3 or 4.2?

The reported performance numbers are compared to 4.3. Essentially it is Godot with/without these changes.

If it was compared to 4.3 then would the difference be bigger when tested with 4.2?

There are other performance improvements coming to 4.3, so yes, the difference is bigger when compared to 4.2 as it would include all the performance improvements made by others.

Shared Changes
Memory Allocation code. Lots of changes interact in one way with GPU memory allocation. The most prominent one is for debug tracking.
Specific Changes

Debug-only memory allocation tracking code. It adds quite a lot of lines of code but they're all trivial and only used in debug builds.

I would suggest integrating this first, because it paves the way for shared memory allocation changes.
It has controversial changes that have already been pointed out:

Docs generation would be messed up because of the ifdefs, so it'd be better if we provide a stub implementation when not using dev builds.
It causes otherwise-isolated components to be aware of Vulkan (abstractions are broken). Since it's Debug only, this is acceptable, while a stub version could be written that doesn't have to be aware of anything.

Device Fault extension: An extension to leave "breadcrumbs" to make diagnosing GPU crashes easier.

This can be isolated and made into its own PR.
Unlike the previous point, it's not debug only (although its main use is aiding debugging).
I recommend including them in the same PR as "Debug-only memory allocation tracking code" because of their similarity: the lines of code live next to each other, and this is a trivial change.
It would make "Device Lost" reports much more detailed.

Swappy integration for Android.

This can be isolated and made into its own PR.
Swappy has a bug where the ANativeWindow will be leaked if SwappyVk_destroySwapchain is called without unsetting the ANativeWindow handle first. This is very easy to workaround, but we will have to do it.

Optimization - Transient / Lazy render targets: It improves memory (and possibly performance) by having RenderTargets that are never sampled (like the main window's depth buffer) have no actual backing memory (it only ever lives in the TBDR cache).

This can be isolated and made into its own PR.
Depends on allocation code changes.

Optimization - ASTC decode mode extension: A very simple change that potentially improves performance and/or battery consumption by requesting the GPU to use lower precision for decoding when available.

This can be isolated and made into its own PR.
Although it does not depend on allocation code changes, its code lives right next to these changes thus it could cause merge conflicts, which is virtually the same thing as saying it depends on alloc. code changes.

Optimization - Persistent Mapping: Adds the BUFFER_USAGE_PERSISTENT_BIT, BUFFER_CREATION_PERSISTENT_BIT and BUFFER_CREATION_LINEAR_BIT flags. Prefers memory pools the CPU can see but live in the GPU.

To the best of my analysis, this is buggy. It cannot be integrated as is (see Bugs section much fruther below).

It'd be great to get feedback from TheForge on this.
They introduced some interesting ideas, so if TheForge refuses to fix this, I may be able to salvage some of it.

Mostly intended for mobile (which are UMA).
Can be turned on/off at runtime (or init time?), but right now the PR left it always on.
Needs more research because I'm worried it will be used in NUMA too. Lately Vulkan drivers will expose memory pools the CPU can see and live in the GPU (when SAM / ReBar is enabled in BIOS, but sometimes 256MB of this pool is still exposed when disabled on BIOS). There are cases where this can improve performance, but we an also shoot ourselves in the foot.

If SAM / ReBAR is disabled and we try to consume all of the measly 256MB of VRAM available, bad things happens (specially because those 256MB are precious and shared by the driver and other apps GLOBALLY). We definitely don't want to enable BUFFER_USAGE_PERSISTENT_BIT in this case.
I also need to check if VMA is not already preventing these cases. VMA is the one who ultimately decides what memory pool to use and it is very difficult to follow its logic.

Unsure how it can be split into its own PR yet. I need more time analyzing.
Probably one of the most important changes IMO.
Heavily depends on allocation code changes (the change itself is about allocations!).

Optimization - Immutable Samplers: It affects shader code, PSO generation, descriptor sets code, and samplers. Rather than setting them from C++ dynamically, they're hard-coded in the shader. This may boost performance on certain GPUs.

This can be isolated and made into its own PR together with the next item.
Depends on allocation code changes.
This may not work out of the box because these changes were made before the merge of Reverse Z. However the fixes would be one-liners (i.e. change swap GREATER for LESS and viceversa)

Optimization - Linear allocation of descriptor set pools: TheForge identified various calls to uniform_set_create() and identified which ones can avoid setting the VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT flag; and are kept in a different set of pools which get reset every frame. Hats off for that monumental task (TBH I'm trusting they did a good job at that).

This can be isolated and made into its own PR together with immutable samplers, since both touch the same areas of code (it'd be possible to split them, but it makes merging tasks much harder unnecessarily).
This code also deals with a workaround for Adreno 730 where linear pools are disabled because they leak.
Personal remark: A code comment (probably from Juan says) VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT; // Can't think how somebody may NOT need this flag.. Ironically I think he just didn't understand how pools were supposed to be used. Because I can not think of ways one would WANT to use this flag on purpose unless you're dealing with retrofitting Vulkan to a legacy engine.

Optimization - PreTransformed Swapchains: An Android-specific optimization to avoid the phone's driver rotating the screen in phones that did not come with a HW rotator.
Optimization - Replace Push Constants with UBOs: It's what it says.

This is higher level changes to non-Vulkan code.
Affects shader code too.
It depends on Optimization - Persistent Mapping and Optimization - Linear allocation of descriptor set pools. Possibly other low level changes.

Misc - Thermal Support: TheForge added monitoring of Thermal Events on Android, logging those changes and shows an alert via OS::get_singleton()->alert if the thermal state is > THERMAL_STATE_MODERATE.

This can be isolated and made into its own PR. It doesn't even need a Vulkan expert. It has nothing to do with Vulkan (other than debugging "why is the perf going down?? ah... the device is getting hot").

I am strongly leaning in submitting these as a single PR due to how close they are to each other:

Optimization - Persistent Mapping
Optimization - Linear allocation of descriptor set pools
Optimization - Immutable Samplers
Optimization - Replace Push Constants with UBOs

For example "Persistent Mapping" could be made into its own PR. However such PR would be criticized for just adding being dead code; because it's not until "Replace Push Constants with UBOs" gets integrated that it would be used.
And "Replace Push Constants with UBOs" depends on the first three. Although it could be broken down; it would be a lot more effort.
Noteworthy or slightly controversial changes
Previously device lost were handled generically by ERR_FAIL_COND_V(err != VK_SUCCESS, FAILED);.
Now extra info is added and crashes immediately.
The purpose of print_lost_device_info is to print the breadcrumbs that will aid in debugging, which is important info.
   		device_queue.submit_mutex.lock();
		err = vkQueueSubmit(device_queue.queue, 1, &submit_info, vk_fence);
		device_queue.submit_mutex.unlock();

		if (err == VK_ERROR_DEVICE_LOST) {
			print_lost_device_info();
			CRASH_NOW_MSG("Vulkan device was lost.");
		}
		ERR_FAIL_COND_V(err != VK_SUCCESS, FAILED);

It think it may be controversial because Godot convention is to use ERR_FAIL_COND_V().
I'm not sure how Godot Team wants to handle integrating this block of code, but what is for sure is that really want to call print_lost_device_info(); on device lost. It would make bug reports much more detailed.
Bugs / Oddities
shader_destroy_modules
TheForge introduced RenderingDeviceDriverVulkan::shader_destroy_modules which is used in various places but:
In RenderingDeviceDriverVulkan::shader_free it performs the same operation twice and will cause a double free:
void RenderingDeviceDriverVulkan::shader_free(ShaderID p_shader) {
	ShaderInfo *shader_info = (ShaderInfo *)p_shader.id;

	for (uint32_t i = 0; i < shader_info->vk_descriptor_set_layouts.size(); i++) {
		vkDestroyDescriptorSetLayout(vk_device, shader_info->vk_descriptor_set_layouts[i], VKC::get_allocation_callbacks(VK_OBJECT_TYPE_DESCRIPTOR_SET_LAYOUT));
	}

	vkDestroyPipelineLayout(vk_device, shader_info->vk_pipeline_layout, VKC::get_allocation_callbacks(VK_OBJECT_TYPE_PIPELINE_LAYOUT));

	for (uint32_t i = 0; i < shader_info->vk_stages_create_info.size(); i++) {
		vkDestroyShaderModule(vk_device, shader_info->vk_stages_create_info[i].module, VKC::get_allocation_callbacks(VK_OBJECT_TYPE_SHADER_MODULE));
	}
	// <TF>
	// @ShadyTF unload shader modules
	// Was :
	//for (uint32_t i = 0; i < si.vk_stages_create_info.size(); i++) {
	//	if (si.vk_stages_create_info[i].module) {
	//		vkDestroyShaderModule(vk_device, si.vk_stages_create_info[i].module, nullptr);
	//	}
	//}
	shader_destroy_modules( p_shader );
	// </TF>

	VersatileResource::free(resources_allocator, shader_info);
}

// <TF>
// @ShadyTF unload shader modules

void RenderingDeviceDriverVulkan::shader_destroy_modules(ShaderID p_shader) {
	auto *E = (RBSet<ShaderInfo>::Element *)p_shader.id;
	ShaderInfo &si = E->get();

	for (uint32_t i = 0; i < si.vk_stages_create_info.size(); i++) {
		if (si.vk_stages_create_info[i].module) {
			vkDestroyShaderModule(vk_device, si.vk_stages_create_info[i].module, nullptr);
			si.vk_stages_create_info[i].module = VK_NULL_HANDLE;
		}
	}
	si.vk_stages_create_info.clear();
}

// </TF>

I think the vkDestroyShaderModule block of code in RenderingDeviceDriverVulkan::shader_free is meant to be replaced by shader_destroy_modules(). TBH it looks like a git merge error. Easy to fix.
Another problem is that the function shader_destroy_modules() they introduced calls vkDestroyShaderModule without the get_allocation_callbacks they introduced. Also easy to fix.
Unused dynamic uniform sets
They added:

RenderingDeviceGraph::add_draw_list_bind_uniform_set_dynamic
DrawListInstruction::TYPE_BIND_UNIFORM_SET_DYNAMIC
RenderingDeviceDriverVulkan::command_bind_render_uniform_set_dynamic
RenderingDeviceCommons::UNIFORM_TYPE_UNIFORM_BUFFER_DYNAMIC

But unless I made a mistake, it doesn't appear like it's actually being used. i.e. it's dead code.
Unknown initialization of max_descriptor_sets_per_pool
TheForge added the following to RenderingDeviceDriverVulkan::RenderingDeviceDriverVulkan constructor:
max_descriptor_sets_per_pool = GLOBAL_GET("rendering/rendering_device/vulkan/max_descriptors_per_pool");

But this exact same line of code is already part of RenderingDeviceDriverVulkan::initialize.
It's not clear why they did it, nor if it's necessary. Perhaps it was meant to be moved out of RenderingDeviceDriverVulkan::initialize ?
Or perhaps it needs to live in both places?
Changed the default value of window_orientation in main.cpp
// Before:
DisplayServer::ScreenOrientation window_orientation = DisplayServer::SCREEN_LANDSCAPE;
window_orientation = DisplayServer::ScreenOrientation(int(GLOBAL_DEF_BASIC("display/window/handheld/orientation", DisplayServer::ScreenOrientation::SCREEN_LANDSCAPE)));

// After:
DisplayServer::ScreenOrientation window_orientation = DisplayServer::SCREEN_SENSOR;
window_orientation = DisplayServer::ScreenOrientation(int(GLOBAL_DEF_BASIC("display/window/handheld/orientation", DisplayServer::ScreenOrientation::SCREEN_SENSOR)));

I don't know why, I don't know if it matters (i.e. if it later gets overwritten anyway), I don't know what SCREEN_SENSOR is (this enum value predates TheForge's changes).
I also don't know if this is relevant for backwards compatibility.
Thermal
The PR adds functions like get_thermal_state and get_thermal_headroom which are not being used at all (i.e. dead code), but I feel like that's under-utilizing them.
The new screen_get_current_rotation() mixes internal state with public state
TheForge adds a new function:
int screen_get_current_rotation(int p_screen) const override;

User bruvzg mentioned:

This should be implemented for the rest of platforms (should be easy to do an all except Web).

Well, the problem is that this function is poorly named. It should be renamed to something like:
// For internal use.
int screen_get_internal_current_rotation(int p_screen) const override;

This is because the return value has deep impact in internal implementation details and in most other platforms (e.g. Windows, Linux, probably iOS too, etc) the return value must be 0.
Race condition in BUFFER_CREATION_PERSISTENT_BIT usage
The biggest for last.
Every time the new code does something like this, it is in principle, safe:
RID* directional_light_buffer;
directional_light_buffer = (RID *)memalloc(sizeof(RID) * RD::get_singleton()->get_frame_delay());
for (uint32_t i=0; i<RD::get_singleton()->get_frame_delay(); i++)
  directional_light_buffer[i] = RD::get_singleton()->uniform_buffer_create(...,
RD::BUFFER_CREATION_LINEAR_BIT | RD::BUFFER_CREATION_PERSISTENT_BIT);

RD::get_singleton()->buffer_update(directional_light_buffer[RD::get_singleton()->get_current_frame_index()], ...);

In short: It creates N buffers (where N = get_frame_delay(), that value is usually 2 or 3), then every frame it cycles through them.
The idea is that while GPU is reading from buffer i, the CPU is writing to buffer i + 1. Otherwise it would cause a race condition because the CPU would be overwriting with new data a buffer that the GPU is still reading from.
This works very well for code that promises to wholy fill from scratch every frame. Thus for buffers like directional_light_buffer, this is ideal.
However, there are other sections of code updated by TheForge that do the following:
bool MaterialStorage::MaterialData::update_parameters_uniform_set(...)
{
  uniform_buffer = RD::get_singleton()->uniform_buffer_create(ubo_data.size(), Vector<uint8_t>(), RD::BUFFER_CREATION_PERSISTENT_BIT | RD::BUFFER_CREATION_LINEAR_BIT);
}

Notice that only one uniform_buffer is created, not N ones. This is only OK in the following scenarios:

The buffer is only populated once, before being used (i.e. after creation).
Before the buffer is updated, we perform a stall.

Since these buffers rarely change, it's a bug that's probably going to go unnoticed for a long time; until there is a project that changes material data very often.
Note that this also affects RenderSceneDataRD::create_uniform_buffer. It probably goes unnoticed because it's mostly used for per-pass data, and the data filled every frame is very similar.
But it also affects volumetric_fog.volume_ubo and volumetric_fog.params_ubo which use RD::BUFFER_CREATION_PERSISTENT_BIT without RD::BUFFER_CREATION_LINEAR_BIT. Data updated there is a WAR (Write After Read) Hazard unless I missed a stall.
BUFFER_CREATION_LINEAR_BIT: Weird internal cycling
The flag BUFFER_CREATION_LINEAR_BIT is confusing me because it appears to be solving two common problems that appear when dealing with persistent buffers yet it is bad at solving both (I'll go into detail on this later).
When the new code does the following:
bool MaterialStorage::MaterialData::update_parameters_uniform_set(...)
{
  uniform_buffer = RD::get_singleton()->uniform_buffer_create(ubo_data.size(), Vector<uint8_t>(), RD::BUFFER_CREATION_PERSISTENT_BIT | RD::BUFFER_CREATION_LINEAR_BIT);
}

As I mentioned in the previous point, this code causes a race condition. But it doesn't stop here.
If we dug deeper, we find out that there is an internal cycle already going on! (but that cycling... doesn't fix the race condition).
First, let me start with this highly misleading variable name:
RID_Owner<PersistentBuffer> persistent_buffer_owner;

Unlike what the name suggests, it doesn't hold the RIDs of all persistent buffers, it holds all RIDs of "linear" buffers (all linear buffers are persistent, but not all persistent buffers are linear).
Linear buffers are put into persistent_buffer_owner and have an internal cycle. There is a function RenderingDevice::persistent_uniform_buffer_advance in charge of doing this:
void RenderingDevice::persistent_uniform_buffer_advance(RID p_buffer) {
	PersistentBuffer *linear_buffer = persistent_buffer_owner.get_or_null(p_buffer);
	if (linear_buffer) {
		if (linear_buffer->buffers.size() <= (linear_buffer->usage_index + 1)) {
			Buffer buffer;
			buffer.size = linear_buffer->size;
			buffer.usage = linear_buffer->usage;
			buffer.driver_id = driver->buffer_create(buffer.size, buffer.usage, RDD::MEMORY_ALLOCATION_TYPE_GPU);
			buffer_memory += buffer.size;
			linear_buffer->buffers.append(buffer);
		}
		linear_buffer->usage_index++;
	}
}

Then when retrieving the buffer via RID, the usage_index is taken into account:
RenderingDevice::Buffer *RenderingDevice::_get_buffer_from_owner(RID p_buffer) {
	if( /*...*/ )
	{

	}
	else if (persistent_buffer_owner.owns(p_buffer)) {
		PersistentBuffer* linear_buffer = persistent_buffer_owner.get_or_null(p_buffer);
		DEV_ASSERT(linear_buffer->usage_index != -1);
		buffer = linear_buffer->buffers.ptrw() + linear_buffer->usage_index; // ! NOTICE: linear_buffer->usage_index.
		// </TF>
	}
}

RID RenderingDevice::uniform_set_create( ... )
{
  // ! NOTICE: linear_buffer->usage_index.
  // ! NOTICE: The MAX() call because usage_index can be -1.
  buffer = linear_buffer->buffers.ptrw() + MAX(0, linear_buffer->usage_index);
}

And finally RenderingDevice::persistent_uniform_buffers_reset is called at the start of each frame to set usage_index back to -1:
void RenderingDevice::persistent_uniform_buffers_reset() {
	List<RID> owned;
	persistent_buffer_owner.get_owned_list(&owned);
	for (const RID& curr : owned) {
		PersistentBuffer* curr_linear_buffer = persistent_buffer_owner.get_or_null(curr);
		curr_linear_buffer->usage_index = -1;
	}
}

Remember that I said..?

it appears to be solving two common problems that appear when dealing with persistent buffers yet it is bad at solving both

The two common problems are:

Preventing Race Conditions between multiple frames (i.e. normally solved by cycling 2 frames in double buffer, 3 frames in triple buffer).
Updating the same buffer twice within the same frame.

Common Problem I: Preventing Race Conditions between multiple frames
OK so if the main problem usage_index (i.e. the new feature when adding the BUFFER_CREATION_LINEAR_BIT flag) is solving is to internally perform double (or triple) buffering to avoid race conditions between multiple frames, then directional_light_buffer[i] could simply be changed back to directional_light_buffer.
However if that's what is trying to achieve, then the call to persistent_uniform_buffers_reset must be modified. Because right now, it means that every frame we will start by using linear_buffer->buffers[0] instead of linear_buffer->buffers[last_updated]:
// Frame 0
rd->persistent_uniform_buffers_reset(); // buff->usage_index = -1
rd->buffer_update( buff, data );        // Send data to GPU. buff->usage_index = 0
draw(); // Draw reading from buff->usage_index = 0
// Frame 1
rd->persistent_uniform_buffers_reset(); // buff->usage_index = -1
rd->buffer_update( buff, data );        // Send data to GPU. buff->usage_index = 0 OOPS!
draw(); // Draw reading from buff->usage_index = 0

Uh oh, in Frame 1 the buffer_update() call updated the buffer with usage_index = 0, which is still in use by frame 0.
This is the race condition I described in the previous section.
Common Problem II: Updating the same buffer twice within the same frame.
The other common problem is when we update the buffer twice within the same frame when we have already issued rendering commands (or a variation of this problem: knowing when we haven't yet issued rendering commands).
Consider the following scenario, all happening within the same frame:
// Frame 0
rd->persistent_uniform_buffers_reset(); // buff->usage_index = -1
rd->buffer_update( buff, offset =   0, size =  512, data ); // buff->usage_index = 0
draw(); // Draw reading from buff
rd->buffer_update( buff, offset = 512, size = 1024, data ); // buff->usage_index = 1
draw(); // Draw reading from buff
rd->buffer_update( buff, offset = 1024, size = 128, data ); // buff->usage_index = 2
draw(); // Draw reading from buff
rd->buffer_update( buff, offset = 1152, size = 256, data ); // buff->usage_index = 3
draw(); // Draw reading from buff
rd->buffer_update( buff, offset = 1408, size = 400, data ); // buff->usage_index = 4
draw(); // Draw reading from buff

// Frame 1
rd->persistent_uniform_buffers_reset(); // buff->usage_index = -1

Question for the audience!
At the end of frame 0 what do you expect to find in buff ?

Valid data in byte range [0; 1808)
Valid data in byte range [1408; 1808)

The answer is "2. Valid data in byte range [1408; 1808)"! As long as the GPU shader only needs that small region, everything will be good; but if it expects to also be able to read [0; 1408), then I'm afraid it will be either uninitialized garbage or old values from a previous buffer_update() call.
This is because when usage_index gets incremented, we get a different buffer! (see RenderingDevice::persistent_uniform_buffer_advance again, I already posted the code). This could be fixed if the new buffer were to be prepopulated with the contents of buffer[buff->usage_index-1] every time persistent_uniform_buffer_advance gets called, though that's probably slower.
The alternative is to not do any sort of internal cycling, but perform internal debug validation to make absolute sure that further calls to buffer_update() do not overlap within the same frame.
If the purpose of usage_index / BUFFER_CREATION_LINEAR_BIT is to prevent overlapped buffer updates within the same frame, then I guess it's doing the job, but it comes with the caveat that it assumes the GPU shader will not read the data already written... which is the problem it's trying to prevent!
Conclusion
Unless I made a mistake (which is plausible), I can only conclude the logic behind this code is buggy. And whatever was intended for usage_index / BUFFER_CREATION_LINEAR_BIT to do is broken.

I saw some conversation somewhere that was confused by the extremely large positive line count (340,000 ish) on this PR, and had to scroll down and skim the thread to learn that it's not actually that large of a changeset, the diff is just a bit busted because the main branch has diverged so much, and the real changeset is more like +4000. I think adding a note to this effect in the opening post (in bold!) would be a good idea and slow down confusion in the peanut gallery.

Would be good to just get this rebased cleaned up so it's easier to review, it's unmergable in its current state anyway

I'm already splitting it into a new PR with all the misc stuff that can be merged right away.
I think it's going to be the right call. There's a lot of trivial stuff that can be analyzed separately, and once that's in, the mental load is a lot lower.
Furthermore my goal is that by having 2-4 separate commits, it becomes easier to bisect.
Otherwise any regression in these changes caused by one giant commit is going to be next to impossible to narrow down.

OK TheForge fixed the issues regarding "BUFFER_CREATION_LINEAR_BIT: Weird internal cycling". Now it's clear what it is supposed to do. As I suspected the actual fix was only a couple of lines.
BUFFER_CREATION_LINEAR_BIT is supposed to cycle within an internal pool of buffers (ideally one per frame, cycling 3 buffers when using triple buffer and 2 buffers when using double buffer).
In other words, it solves the "Common Problem I: Preventing Race Conditions between multiple frames" from my previous report.
Now that BUFFER_CREATION_LINEAR_BIT is clear we have the following oddities:
directional_light_buffer[i] change is redundant.
Having RD::get_singleton()->get_frame_delay() directional_light_buffer[] buffers is pointless. Because we can keep just one and let BUFFER_CREATION_LINEAR_BIT do its job.
Updating the same buffer twice within the same frame is not safe
This is "Common Problem II" and remains unaddressed.
I can implement two solutions:

Forbid updating the same buffer twice in the same frame. Assert when this happens. If we're lucky, this is enough.

If the assert triggers, the assert must be specifically disabled. When disabled, ALL the data range must be completely uploaded again by caller (or else we still assert).

Track dirty regions and only assert when the updated regions within the same frame overlap.

If they overlap, assert.

Option 1 is the easiest to implement so I will go with that. However Option 2 is the most efficient if many (non-overlapping) partial updates happen too often per frame.
Always p_uniform_dirty = true;
User @tavurth discovered this problem.
It would seem a simple merge error that should be undone (i.e. not merged). However suspiciously, if we mark the buffer as always dirty, it workarounds the old buggy code BUFFER_CREATION_LINEAR_BIT that has now been fixed.
This will need deeper debugging from me to ensure everything works as expected.

Possible Fix Queue Synchronization could fix https://github.com/godotengine/godot/issues/94177

@darksylinc is my understanding correct that we can call the buffer_get_persistent_address, in order to write directly to the GPU buffer.
This will be a huge win for the batch 2D rendering optimisations I've been working on, when UMA is available, as I'll be able to write the instance data directly to the buffer and avoid:

write instance data to CPU buffer
call buffer_update, which schedules potentially multiple BLITs from CPU to GPU

This is a potentially significant win for CPU (and GPU) when running on UMA systems.

I had to splice the persistent mapping stuff into its own branch because it was riddled with race conditions.
I still want to add it but it's not easy
I've discussed it with other Godot team members and the problem boils down to:

Safety guarantees that are needed for the kind of arbitrary uses that Godot users can perform require too much overhead. Negating any performance improvement.
I'm evaluating adding a "YOLO mode" where persistent mapping acces would be enabled for internal components (but not available to users). However this still needs a lot of debug mode tracking because Godot design is too flexible, which means even experienced devs could make mistakes and introduce race conditions when writing in YOLO mode, that would be very hard to track down (and Vulkan Validation layers can NOT detect these errors). A good interface would blow in debug mode, to indicate YOLO mode is incorrectly used.

By race conditions I mean CPU writes to areas of memory currently in use by the GPU.
At best such data races cause small glitches, at worst it cause device lost (e.g. imagine if a shader gets stuck in an infinite loop because its input data is in an inconsistent state)

However this still needs a lot of debug mode tracking because Godot design is too flexible, which means even experienced devs could make mistakes and introduce race conditions when writing in YOLO mode

Those scenario sounds entirely reasonable for YOLO mode – an advanced feature with appropriate warnings. I wouldn't expect any guard rails, and understand there would be limited tooling to assist me when I use the APIs incorrectly. The upside is potentially significant performance benefits.
Race conditions aren't new to Godot devs, who are exposed to those issues with GDScript and multi-threading.
Are you are eluding to something more subtle which I am missing?

Race conditions aren't new to Godot devs, who are exposed to those issues with GDScript and multi-threading.
Are you are eluding to something more subtle which I am missing?

CPU race conditions will result in wrong data that can be observed with simple printf().
If it crashes, you can use a debugger to see what's going wrong.
Some CPU race conditions are really hard to find because the error manifested very far away from when the problem occurred, but ultimately you can trace your way backwards.
There are also tools like Clang's ThreadSanitizer.
Another important thing is that nobody doubts CPU HW if faulty or compilers are faulty. They do happen, but they're rare and when it does happen, it is pretty obvious the crashes come from a specific platform/compiler or from a specific CPU model.
Another important issue is that if you are able to turn multi-threaded code into single-threaded and the problem goes away, then you know the problem is a race condition.
On CPU -> GPU race conditions, it's MUCH harder to spot:

For starter driver and HW bugs are extremely common. So blaming the vendor instead of our own code is far more common. Specially if the code happens to work e.g. on AMD and NVIDIA due to scheduling or cache coherency woes, but breaks on Intel GPUs: we'll end up blaming Intel when the fault is on us.
A race condition that results in a GPU crash will look like every other crash: You get a device lost error with no other information of what went wrong. You'll end up in ticket 71929 (I'm not linking to it to avoid adding noise to it) which has become a dumpster for generic GPU crashes. We recently added support for breadcrumbs and device lost reports, which should help a lot in understanding what the GPU was doing when it crashed; however it will be hard to track down due to the next point.
You have 4 places to look for: the CPU code, the GPU code, and the CPU -> GPU synchronization, and the GPU -> GPU synchronization. The GPU crash (or glitch) could be happening because the shader code is faulty. You have to analyze it, dissect it, understand it. And then when you find nothing wrong with it, you theorize "this could happen if this uniform variable num_lights is wrong". So you go to the CPU code. Analyze it, dissect it, understand it. Find ways to see how num_lights could end up with an invalid value. But you don't see how. That's because the problem is that you're writing to the buffer when you were not supposed to.
If you force aggressive synchronization (e.g. place vkDeviceWaitIdle everywhere) and the problem goes away, it's a synchronization problem. But is it a GPU -> GPU synchronization problem? Or is it a CPU -> GPU one? Luckily most GPU -> GPU sync errors can be detected by Vulkan's Validation layer (sync validation is off by default, you need to turn it on in vkconfig.exe), but CPU -> GPU are on you.

Ultimately the problem is that it boils down to 2 rules:

You can only write to the buffer once per frame.
You must fill it from scratch every time.
You must fill the buffer every frame (lifting this rule is possible but it requires a ton of work not done yet), even if nothing changed. You can skip this rule if you're not planning to issue draws or compute dispatches that use this buffer at all.

If you follow those three rules, then you're safe.
But Godot is incredibly flexible. If the user has multiple passes, or stereo rendering is involved; we may break the first rule (write to the buffer once); but it will only happen in specific scene settings.
It's even harder to approach because Godot by default in many places tries to only update dirty regions. For example in material or mesh updates, it only updates materials/meshes that were modified. This breaks the second rule.

Firstly, my questions are not doubting your reasoning – primarily out of curiosity and to better understand the problem.
Are we only talking about UMA architecture?

You can only write to the buffer once per frame.

Presumably we can write to the buffer incrementally, but this rule is stating you can't write to it after you've submitted the command that uses the buffer?

You must fill it from scratch every time.

Not questioning it, but why is this the case? What would be overwriting the memory that requires this rule?

You must fill the buffer every frame

Seems like 2. and 3. are related, suggesting that the contents of the buffer are invalidated by something at some point after the frame? Curious why that is?


Update Process

Actually, this not Issue its Suggest
what is Update Process?
should I remove the full Code to run a new code?

hi Sajibekanti,
In the documentation section of NERVE, there are instructions how to upgrade.
However, we now also added this under the repository's README. for your convenience.


How do I disable alchemist's flying potion

Nice setup but too unbalanced for me

Need to add a config option for this.

the mod is perfect but also need custom config and more balance

What about the mod would you consider unbalanced? Please let me know ;)

flying potion and unbreakable are like op's power,don't you think so?Maybe can replace these with other superpower？

Depends on the modpack you play. I think gaining Smith level 100 is not easy, so you deserve unbreakable tools. And obtaining a nether star for 10 mins of flight seems fair. If it is too easy to get nether stars, your modpack probably contains a ring of flight anyway 🤷♂. But I'm working on a config option for them right now.

取决于你玩的模组包。 我认为获得史密斯 100 级并不容易，所以你应该拥有牢不可破的工具。 并且获得一个 10 分钟飞行的下界之星似乎是公平的。 如果太容易获得下界之星，那么您的模组包可能无论如何都包含一个飞行环 🤷♂ . 但我现在正在为他们设计一个配置选项。

Okay you are right, Thank you for developing this mod

取决于你玩的模组包。 我认为获得史密斯 100 级并不容易，所以你应该拥有牢不可破的工具。 并且获得一个 10 分钟飞行的下界之星似乎是公平的。 如果太容易获得下界之星，那么您的模组包可能无论如何都包含一个飞行环 🤷♂ . 但我现在正在为他们设计一个配置选项。

Can  you add a configuration to disable a job?


bug: golang configuration needed on M1 Mac

To support real Zero-Config for golang on M1 Mac  these environment variables have to be set. Otherwise go will use the current systems architecture which is ARM instead of AMD64 on an M1 Mac.
Currently there is only one supported golang runtime (go1.x) which only has amd64 Processors. But after #1271 there will be the possibility to use ARM runtimes. So #1271 should change this to include logic based on real architecture. Not needed for now.
This fixes issue #1757

Thanks @dennistruemper!
I made a minor change so that GOARCH is only set to amd64 when bundling to deploy (ie. sst deploy). When building locally (ie. sst start), it should still respect ur local machine. Does that sound right?

thanks for the correction @fwang , like mentioned seconds ago the comment might be misleading. But you already fixed it, awesome :-)


HarfBuzzSharp: Add buffer UTF overloads

This PR adds some missing overloads for the hb_buffer to add text with UTF-16 and UTF-32 encoding.
I have also added some overloads that make it possible to only shape some portion of an encoded sequence.
Leave me comments if you have questions or find any mistake.

OPS Build status updates of commit 075bd0c:
:clock10: Preparing: average preparing time is 1 min(s) 50 sec(s)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Gillibald sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

OPS Build status updates of commit 075bd0c:
:clock10: Incremental building: average incremental building time is 22 sec(s)

@Gillibald initially the harfbuzz binding was more of a test, so it does not really have a nice workflow. I actually just downloaded the source tar as part of the steps:
https://github.com/mono/SkiaSharp/blob/master/cake/BuildExternals.cake#L715-L739
After downloading, I manually created project files (MSBuild, Xcode, Tizen, Makefile) for each platform to compile. I haven't gotten around to updating and using the CMake targets. The actual version that gets pulled in is read from this file:
https://github.com/mono/SkiaSharp/blob/master/VERSIONS.txt#L5
Just another thing: if this layout is not practical, or you need to get it to build another way, then go ahead and make the adjustments. Due to poor reasoning, it is the way it is now because that is how it was then 😄 Also, the harfbuzz repo has come a long way since 2017.

The reason I used the source tar instead of the code/submodule was - at the time - there was a few extra files that were generated that I didn't want to regenerate on CI. I believe this was because i didn't want to have to depend on cygwin and things like that. As a result, I just downloaded the files and used the platform project files.

OPS Build status updates of commit 3d11954:
:clock10: Preparing: average preparing time is 1 min(s) 50 sec(s)

I will update HarfBuzz in a different PR. My current approach adds a submodule to the repository but still uses custom build scripts. This works great so far and gives us the most control.

Looks like this signature doesn't work:
public extern static void hb_buffer_add_utf16(hb_buffer_t buffer, byte[] text, int text_length, uint item_offset, int item_length);
This works:
public extern static void hb_buffer_add_utf16(hb_buffer_t buffer, ushort[] text, int text_length, uint item_offset, int item_length);
Using ushort[] isn't very practical because it involves some copy. Can we somhow marshall the byte array as an array of ushort?

OPS Build status updates of commit deb1977:
:clock10: Preparing: average preparing time is 1 min(s) 50 sec(s)

OPS Build status updates of commit deb1977:
:clock10: Incremental building: average incremental building time is 22 sec(s)

OPS Build status updates of commit deb1977:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

binding/HarfBuzzSharp.Shared/Buffer.cs
:white_check_mark:Succeeded

source/SkiaSharp.HarfBuzz/SkiaSharp.HarfBuzz.Shared/SKShaper.cs
:white_check_mark:Succeeded

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


ICA Controller Side Middleware

Description

closes: #313

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Nice! Excited to see what this looks like. I'll review properly in the morning :)

Codecov Report

Merging #417 (9f0f495) into interchain-accounts (7c7bf8e) will increase coverage by 0.24%.
The diff coverage is 75.00%.

@@                   Coverage Diff                   @@
##           interchain-accounts     #417      +/-   ##
=======================================================
+ Coverage                77.65%   77.90%   +0.24%
=======================================================
  Files                      129      128       -1
  Lines                    10110    10086      -24
=======================================================
+ Hits                      7851     7857       +6
+ Misses                    1864     1833      -31
- Partials                   395      396       +1

Impacted Files
Coverage Δ

...dules/apps/27-interchain-accounts/keeper/keeper.go
81.70% <ø> (+2.18%)
:arrow_up:

...odules/apps/27-interchain-accounts/keeper/relay.go
36.70% <66.66%> (+4.91%)
:arrow_up:

...es/apps/27-interchain-accounts/keeper/handshake.go
100.00% <100.00%> (ø)

modules/apps/27-interchain-accounts/types/keys.go
75.00% <100.00%> (+8.33%)
:arrow_up:

Nice work!
From my understanding, the primary benefit of making ICA middleware on the controller side is to replace the previously existing hooks functionality which allowed for custom logic on timeout/recv/ack effectively.
I'm thinking it would be good to have some tests using the mock module infrastructure you created and test out some custom logic for each of these steps to ensure the middleware is working as intended.
wdyt?


Catchup recover dlc dialog is shown when settled channel got force closed

Force close settled dlc channel
Restart app
Recovery dialog is shown

The problem here is that the app thinks we are in an intermediate state and we show a catch-up/recover dialog but we never do.


HDDS-3058. OzoneFileSystem should override unsupported set type FileS…

What changes were proposed in this pull request?
OzoneFileSystem overrides unsupported set type FileSystem API.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-3058
How was this patch tested?
Just the unsupported API overriding, seems don't need to have a test.

Seems there is a test failure, Can you give a check once


retrieve partial id

Hi !
Is there anyway we could retrieve the temporary generated id "new_id" inside the partial ? Or another way would be to send dynamic datas into the partial each time link_to_add_association is triggered ?
Thanks!

Could you explain to me why you would need this? Is this related to #362 (e.g. use callbacks to manipulate html before insert) or do you need the wrap_object: option to set specific values (although this is server side).

Hi nathan! Thanks for your answer and your work.
Callbacks work perferctly for what I need however it has to be outside of the partial. I just wanted to know if there was a tricks to access to the js context when an association is added.
My issue is kind of related to #362 so i'm closing it.
Merci !


Automatic tool for project license

License badge can be obtained via shields.io as
However, most of the projects seems not to have license specified recognizably ( )
Licensechcek can be used to extract licence(s) directly from code https://metacpan.org/dist/App-Licensecheck
EDIT: Last commit date already extracted via shields.io

@lzaoral the issue for future fix once licence detection is working


build(fix) travis deploy/release

build(fix) travis deploy/release
Fix the travis deploy/release process
* current semantic-release requires current node and current OS
* update golangci-lint
* update golang indirect deps

PR summary
as above
Fixes: none
PR Checklist
Please make sure that your PR fulfills the following requirements:

[x] The commit message follows the Angular Commit Message Guidelines.
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] New tests
[x] Build/CI related changes
[ ] Documentation content changes
[ ] Other (please describe)

What is the current behavior?
no behavior change
What is the new behavior?
no behavior change
Does this PR introduce a breaking change?

[x] Yes
[ ] No

Other information
This release requires golang 1.18.x
(incremented in 2 previous commits which were not released)

:tada: This PR is included in version 0.0.17 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


CASMINST-2951-1.2 Correct large DNS and FIXME sections which were mistakenly removed

Summary and Scope
CASMINST-2951-1.2 Correct large DNS and FIXME sections which were mistakenly removed
The previous mod to CASMINST-2951 mistakenly removed major DNS and FIXME sections and had used the old dtr.dev.cray.com URL in many places.
Issues and Related PRs
Testing
Tested on:
Test description:
Risks and Mitigations
Pull Request Checklist

@haroldlongley is this PR still needed?

This PR is no longer needed. Closing it out.


Add initial code field for Questions table

There should be a initial code field that lets you fill in the question's answer text at first upon initiation

Possible duplicate of #48?


:fire::truck::building_construction: remove pigeon.default and move functionality elsewhere

default error fallback is now also used in views.ErrorHandler

possible wontfix @raspitim since default error fallback has grown in size tremendously ever since debug mode has been implemented


Use large count in the boundFunction call

We can get large count in the boundfunction new instance. We should be using the large count variant API to get the count (OS#17406027)

@aneeshdk please have a look

@dotnet-bot test OSX static_osx_osx_debug please

@dotnet-bot test OSX _no_jit_shared_osx_osx_test please

@dotnet-bot test OSX static_osx_osx_release please

@dotnet-bot test OSX _no_jit_shared_osx_osx_test please


SDL_JOYDEVICEADDED is not supported

testjoystick application doesn't work at the moment.

Closing with 2.0.14 RC1.

Closing with 2.0.14 RC1.


Set up lint-staged and husky to format files on pre-commit hook

Closes #1

Good work so far @eigengravy, it would be great if you also include json files for formatting

Done @riskycase


Update README.md

I have made diligent efforts to rectify any grammatical and sentence errors, striving for improved clarity and precision.
Resolves # .
Description

What is the purpose of this pull request?

This pull request:

a
b
c

Related Issues

Does this pull request have any related issues?

This pull request:

resolves #
fixes #

Questions

Any questions for reviewers of this pull request?

No.
Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.
Checklist

Please ensure the following tasks are completed before submitting this pull request.

[ ] Read, understood, and followed the contributing guidelines.

@stdlib-js/reviewers

@Parag003 The changes introduced in this PR are largely unnecessary and don't significantly enhance README readability. As such, I am going to close this PR.


New EU tyre label requirements from May 2021

Effective May 2021 a new version of the tyre label will be mandatory.
References:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32020R0740
https://ec.europa.eu/info/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/energy-label-and-ecodesign/energy-efficient-products/tyres_en
Are there any plans of implementing the required changes?

I will implement these changes as soon as possible. Hopefully before May 2021. Thank you for providing me with the information - its very much appreciated.
If you wish to provide any help in the form of code updates I'd be happy to accept any pull requests but I will be starting work myself on the new design starting this evening.
Vielen Dank mein österreichischer Freund. Ich habe auch dafür gestimmt, in der EU zu bleiben!

I'm sorry but I've recently switch3ed jobs and therefore the project is stallinng. I'll aim to get this back on track soon.