Time for training PWC net with dataset Flying chairs

Hi,
Thank you again for your code and your answer for my former questions. Now I am trying to train from initialization a PWC net with dataset Flying chairs, but I found that the EPE doesn't decrease (always about 11~12), do you have the same problem when training PWC net with dataset Flyingchairs or Sintel. If so, could you please tell me how to solve this problem? Thank you very much for your attention.
Yours sincerely,
Jinglei

Thanks, I also see the same problem at the training on FlyingChairs dataset in my environment.
I'm sorry that I have not figure out the cause for this, but I also confirmed that fine-tuning from the model_3007.ckpt seems to adapt to the FlyingChairs dataset.
If I found the solution, I will immediately update this repository.
Kindly regards.

@daigo0927  how is this problem solved?

@daigo0927 Thanks for your excellent job!
how is this problem solved? How the performance of PWCDCnet? How to  train FlyingChairs for a good result? Thanks a lot!

@LiuzhuForFun it seems that the net is easy to get stuck in local minimum at the beginning. Try to train from different initial states. That's my solution.

@xianshunw,Thanks for your suggestion.Do you mean that train a lot times to find a suitable optimum？

@LiuzhuForFun I mean that if your net doesn't convergence after thousands of iterations then train from scratch again. This will help your net escape from this local minimum. This problem is mentioned in the original paper, see Optical flow estimator of Ablation Experiments(Section 4.2) in the original paper. The authors said that the

deeper optical flow estimator might may get stuck at poor local minima

But in my experience, the original optical flow estimator also have this problem.

@xianshunw Thank you very much.How about the performance of the net your trained?

@LiuzhuForFun without so many data argumentations as the original implementation, the training epe error can reduce to 1.1~(probably, I forget) and the validating epe can drop below 2 on FlyingChairs.

@xianshunw Thanks again! I got into trouble: the model performed well in the dataset I trained(for example FlyingChairs 1.23),but the result didn't perform in other dataset as well as the orgin paper put.Dou you have the same problem?

@LiuzhuForFun which dataset? FlyThings? Sintel or KITTI?

@xianshunw Sintel and Kitti

@xianshunw Thanks,do you have the same problem? What is the final epe on Kitti or SIntel.Thanks again! My wechat ID is chinasdlz. If you had some time,I hope I could discuss some idea about optical flow.

For testing on other data set, you have to train it on FlyingChairs dataset.

@Choneke interesting, how is your model performing on sintel when it's only trained on chairs?

@xianshunw  Thanks for your sharing, I just reimplement the PWCnet using mxnet, During the training on MPI-Sintel, the flow_6 (the smallest scale) did not convergence, and remains in constant. while the optic flow from other scales seems good. Did you noticed this in your training?

@lelelexxx hope this issue helps you. https://github.com/NVlabs/PWC-Net/issues/30


[stable/openebs] Add the opportunity to change docker registry

Signed-off-by: olivier beyler<EMAIL_ADDRESS>Is this a new chart
no
What this PR does / why we need it:
In case of airgap, it's frequent to use a private docker registry and not neither docker.io or quay.io
It give the opportunity to change the docker repository from quai.io to private repository in one shot
and evict to have to change all docker image in the helm chart
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test


style: use VS Code file nesting to nest test files

Closing this as we don't want this as the default. Anybody can set this by themselves either locally (for workspace) or globally.


ci(actions): update renovatebot/github-action action to v39.1.1

This PR contains the following updates:

Package
Type
Update
Change

renovatebot/github-action
action
patch
v39.1.0 -> v39.1.1

Release Notes

renovatebot/github-action (renovatebot/github-action)
v39.1.1
Compare Source
Documentation

update references to renovatebot/github-action to v39.1.0 (3190dfa)

Miscellaneous Chores

deps: lock file maintenance (9f450cc)
deps: update commitlint monorepo to v17.8.0 (70714dc)
deps: update dependency @types/node to v16.18.59 (2e0b422)
deps: update linters to v6.7.5 (e008b4b)
deps: update linters to v6.8.0 (f1066ae)

Build System

deps: update dependency @vercel/ncc to v0.38.1 (b0e244a)

Continuous Integration

deps: update actions/setup-node action to v3.8.2 (b7131c2)
deps: update renovate docker tag to v37.22.0 (65c6e7f)
deps: update renovate docker tag to v37.23.0 (ea2fb9f)
deps: update renovate docker tag to v37.26.1 (94e0554)
deps: update renovate docker tag to v37.26.4 (96f75b9)
deps: update renovate docker tag to v37.27.0 (3a7c5ff)
deps: update renovate docker tag to v37.27.1 (1b5e186)
deps: update renovate docker tag to v37.28.0 (e3ab740)
deps: update renovate docker tag to v37.28.1 (486591b)
deps: update renovate docker tag to v37.29.0 (4c76d09)
deps: update renovate docker tag to v37.31.1 (d98d73c)
deps: update renovate docker tag to v37.31.2 (94d8cbd)
deps: update renovate docker tag to v37.31.3 (840ba9e)
deps: update renovate docker tag to v37.31.4 (507e77b)
deps: update renovate docker tag to v37.31.5 (bfa1402)
deps: update renovate docker tag to v37.31.7 (196f852)
deps: update renovate docker tag to v37.33.1 (a03423b)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

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


Incorrect window size obtained from WindowResolution in version 0.12

Bevy version
latest(0.12)
What you did
I'm a archlinux and tiling window manager user, also used to coding in neovim.
To reproduce, just write the following program and run it:
// main.rs

use bevy::prelude::*;
use bevy::window::PrimaryWindow;

fn init_system(
  window: Query<&mut Window, With<PrimaryWindow>>,
) {
  let window = window.single_mut();
  let size = Vec2::new(window.width(), window.height());
  println!("Size: {}", size);
  window.set_cursor_position(Some(size / 2.0));
}

fn main() {
  App::new()
    .add_plugins(DefaultPlugins)
    .add_systems(Startup, init_system)
    .run()
}

What went wrong
Expected:

Correct input in terminal to report the window size.
Since the bevy window split in half the 1920 * 1080 screen, so the correct size must be that divided by 2.

The cursor should be at the center of the window.
As the window.set_cursor_position(Some(size / 2) showed.

That was what I expected but in newer version bevy, I get these:

In terminal I got the size of 1280 * 720
Notice that 1280 * 720 is the default value in window.rs

Since that I got incorrect cursor position in my window.

That is very strange because the same program act normally in 0.11.3 bevy, that I find out.
Additional information
Before running this program I executed sudo pacman -Syu in my archlinux system.
That is to say, I already have the latest system environment.
I chose wezterm as my default terminal, and bash as my main shell.
In my project, I have dynamic_linking feature enabled, and naturally, have resolver = "2" in [workspace] entry.
Can anyone give me a help hand? Thanks a lot!

this is probably the same issue as #10407
for the first run of your systems, the window size / scale is not updated with the actual window but has the default values

Thanks! I solved that, close this soon.


index.html

Overview
TL;DR

Questions
<If relevant, write a list of questions that you would like to discuss related to the changes that you have made.>
Next Steps
<If incomplete, create a task list of items that are still being worked on within the Pull Request.>
Review
<If complete, or ready for :eyes:, use @mentions for quick questions, specific feedback, and progress updates.>

@Ashmita08 thank you for submitting this change. This should in fact remain page.title so I'm closing this pull request. Thank you for taking a look at this project and we look forward to future contributions.


[Tracker][Multi-AIL] Multi-AIL telemetry related PRs

[ ] BR's external route publish status

https://github.com/openthread/openthread/pull/10199

no needed


Exclude environment variables which are not defined

Addresses #1

Nice catch, thanks.

You was too fast :)


Propose adding iteration as a value

TL;DR - where does being iterative fit within our values? I miss having that as a principle.
I really love our values, and they help me make decisions and build good habits day to day. For example, when we moved to customer first, it was great because it instantly aligned everybody on that principle and helped resolve discussions much more quickly. That change of value was 10x more impactful than a change of plan because it was instantly clear what it meant.
As we grow, we are planning more, and getting more structured. This is great! We have the chance to be at scale now and that means we can do ambitious things to help our customers.
One thing I've started to notice though is, given our scale and the more intense coordination required, we are tempted to produce bigger chunks at a time. Some of this is the way we build things (build and release big pieces), some of this is the way we market (hide features for a long time), some of this is the way we plan. Paired with a long release and upgrade cycle, it means that we sometimes don't get things to customers as fast as we used to. It also means that we are increasing our feedback cycle time and slowly getting farther away from customers.
In practice, this results in people at Sourcegraph more and more often asking themselves "is this sufficiently good to share/ship"? For everything communication-related, this is solved by being eagerly transparent, which is included in our Open and Transparent value. But for anything output/product-related, nothing in our values encourages us to build iteratively.
In the High Quality section, we briefly touch upon why high quality does not prevent us from being iterative. But nothing encourages us to be iterative either (emphasis mine).

High-quality isn’t the opposite of iterative. You can keep quality high while still being iterative by narrowing the scope (for example, by solving a smaller problem at first, or by solving it only for certain customers initially).

So bottom line, sometimes I feel like we miss something that guides us about how big should a unit of value be before we build/release it and how much we spend on planning vs iterating. I don't know if this means we miss a value, or if this should be included in another value (eg. high agency).
Be iterative sounds like something we want to (a) avoid being too planning focused (b) avoid deadlocks (c) make sure what we do is de-risked ASAP.
This is strongly inspired by GitLab's Iteration value

@malomarrec I am very much in favor of adding this as one of our guiding principles. As we grow larger I believe being iterative is the antidote to slowing down and allowing us to stay nimble.
My only reservation in the current form of the diff is that I don't believe we should be adding more top-level values. We probably need to reduce them if anything.
As such, I'd highly recommend we add it as a sub-value of one of the existing ones. I think high-agency is the right value to add it under as it also reduces the risk of acting with high-agency if you do it in an iterative manner.

Agreed with the general idea of breaking work down to reduce time to value.
Where I see "be iterative" being problematic is for initiatives impacting large parts of any organization. Take planning for example – imagine we're iterating rapidly with our planning process and expecting folks to keep up with small incremental changes every day. In a scenario like that, it's with almost certainty that change fatigue will ensue. Communicating and keeping up with change is work in and of itself. And being iterative without the right change management processes in place can end up overwhelming people and have the opposite effect of slowing us down.

Personally, I favor very much "iterative shipping", as for planning, kinda agree that sometimes we do want to plan ahead enough until we can start building, depending on whether the decision is easily reversible or not.

@yinquanteo that's a good point. I guess even for planning, Open and Transparent would point towards eagerly sharing by default, but providing clear guidelines that nobody has to contribute or look at it until a set time, and avoid overcomunicating in short cycles (so not being too iterative).
What do you propose? Do you think this proposal should just be dropped, or can you suggest a short amendment?

@malomarrec:
"Do you think this proposal should just be dropped". No! There's value in moving forward if we included some caveats.
Taking the planning process example we discussed,

Iterating successfully to me could look like: Having a small planning working group iterating on the planning process and batching up changes before informing/announcing to the broader population.
Iterating unsuccessfully could look like: Big planning planning working group iterating on the process and expecting the broader population to iterate with them.

In practice, we keep project groups small and provide clear guidelines on who should be involved when (as you mentioned).
Have you seen these slides? https://komoroske.com/slime-mold/. I love the ideas around coordination and organizational headwinds.

I like @jeanduplessis 's idea of having iteration be a sub-value under high agency. Iteration helps you get things done because small changes avoid getting blocked in committee.
To @yinquanteo 's point, iteration worked pretty well at GitLab because the changes really were kept small, and people knew to make changes that were resilient such that the whole company didn't have to instantly adopt it in order for it to be successful. When I think about how we have iterated on planning, it has felt like throwing away much of the existing process and rewriting a big chunk, and then publishing that as a new iteration, and then doing that again. That is of course unsustainable and not really what I'd describe as iteration (some other things people think of as iteration but aren't really are listed here: https://about.gitlab.com/blog/2021/12/01/dont-confuse-these-twelve-shortcuts-with-iteration/).
I think the other thing that we had in our favor at GitLab was a handbook-first focus, so before anyone executed a process that was documented, you'd go read the latest version of the page that docuemnts it. No big change management or education process was needed, because the handbook was always the current documentation and you didn't need to keep up until you actually needed to do something. I don't think we exactly have that habit today.. but that said, you don't ever acquire that habit if you don't ever set the expectation.

Another thought is I don't think that working iteratively (when we are talking about product features, rather than planning) is compatible with embargoes so we'd need to work with marketing and product leadership (@christinaforney @amieroth and @abschu) to make sure we figure out how that process is going to work going forward.

@yinquanteo I thought about your point about planning and discussed this with @jyavorska. Do you think your concern is addressed by the last version?

We should avoid iterating in a way where it requires change management or large company-wide communication (for example, changing planning processes in the middle of planning).

Because we're a handbook first company, anyone can rapidly get caught up on recent changes by reading the handbook page.

@malomarrec interestingly (well, at least to me), I could also see this fitting with continuously grow. I leave it you decide how to best reflect what you are seeking to accomplish with this, of course. My thought is that iteration is inherently what drives anything that is continuous (maybe I have too many hears doing LEAN in factories to not think this way). I also think that this living as part of continuously grow allows for a more healthy tension between values. High agency without teamwork is just bulldozing others. Or, in this case, it could be ... high agency without continuously grow is just doing something quickly and never thinking about it again.  Again, please do proceed as you see fit -- these are just the thoughts that came to mind.

Thanks for the thought @virginiaulrich, and I agree. This subvalue fits under multiple top-level values, and continuously grow is a good one (I think @sqs said something like "this is also about 'learn in the open'").

Another thought that came up in a conversation with @mrnugget (but I am not representing his opinion here, just my own, so  credits to Thorsten if he agrees with it, all responsibility on me for being a poor scribe if not):
It seems to me that high quality alone is not very useful as a value because it is quite low signal-to-noise. Shipping high quality is not controversial, nor is defining what good quality is.
By contrast, other values are high signal-to-noise in the sense that they help to make sense out of situations where the course of action is unclear:

Be iterative is pretty clear: you just ship small things until there is a clear business reason to do so. This is high signal-to-noise: it's not natural to be that way.
Open and transparent: you make things public until there is a clear business reason to do so. This is controversial: it's not natural to be that way. High signal again.

That's an interesting point @malomarrec but I wouldn't add it to the PR or it might become too complex.

I'm wondering whether this newly proposed value isn't better version and replacement of "High Quality".
The first sentence describing the "High Quality" value:

High Quality
You are responsible for finding out what high-quality work looks like and delivering that high-quality work iteratively.

Emphasis mine.
As Malo wrote in the previous comment: I do think "High Quality" is a low-signal name for this value.
Because what we mean with "High Quality" ("finding out what high-quality work looks like", meaning it's subjective) is counter to common ideas of "high quality" (if we'd ask a 100 people what "high quality" means, I bet a lot would say "something's perfect", "really good", etc.). We use "High Quality" to also include ideas like minimal-viable products, prototypes, experiments, making trade-offs, etc. What exactly is of high quality depends on the context and what we're trying to do - that's what this value says to me, in its description, not in the name.
So, yes, I'm being completely unhelpful here by disagreeing with the previous ideas of grouping it under "high agency" or "continuously grow" and adding another opinion: I think we should rethink the "High Quality" value and possibly merge it with the description here and rename it. Sorry! 😄

GitLab specifically calls out iteration as a reason for success in their latest earning call

Another reason for our fast innovation is our value of iteration. Iteration means reducing the scope of the next piece of work with the smallest valuable thing possible, so it can be delivered fast. Our innovation is also predictable as we shipped on the 22nd day of every month for 124 months in a row as of January. This allows our customers to benefit from new innovation every month and it allows us to get feedback very rapidly.
To provide some examples of this innovation, in the fourth quarter, we delivered enhancements in the following areas. First, software supply chain security continues to be a key focus for enterprises and providing controls that empower teams is critical as this helps everyone be more secure. With this in mind, we improved fine-grained security approval controls and merge request approval controls by enabling every software change to be reviewed by at least two people. This allows organizations to better manage their security risk. Second, digital transformations continue to drive cloud-native adoption and we see this as a key enterprise initiative for quite some time. To support this, we are continuing to expand our cloud-native capabilities, including improving the user experience for a GitLab agent for Kubernetes and infrastructure as code security scanning capabilities. Third, we recognize that GitLab is a critical business application for our customers, whether they are new start-up with a small team or enterprise customers with tens of thousands of users. Thus, we continue to invest in improving both the performance and scalability of our DevOps platform. We recently made improvements to our GitLab container registry to enable better performance while also reducing storage costs. Additionally, we made sure that our geo capabilities work seamlessly worldwide with better performance. Fourth, we improved our core functionality, including source code management, CI/CD and security features. These investments support our typical customer journey. As to date, our customers tend to start with source code in CI, then expand to use secure package and release.

Just want to share some historical context on this. When Christina and I originally drafted these values, our thinking was high quality through iteration.
You can see the definition of high quality already mentions iteration:

High quality: You are responsible for finding out what high-quality work looks like and producing that high-quality work iteratively.

At one point we did have an intention of changing high quality to be iterative and you can see the PR here:
https://github.com/sourcegraph/about/pull/1738
That part of the PR was reverted because we couldn't find wording that we were happy with and we wanted to push through the other changes.
The follow-up PR to actually reconsider changing high quality to be iterative never left the draft state for reasons I can't remember (I assume we got busy with other things and forgot about it).
In any case, I agree that:

We should avoid net-adding new values if possible
A value about being iterative is more valuable than one about quality (as evidenced by those previous PRs) so I would be in favor of doing that replacement.

@nicksnyder - thanks for the added context. I took your suggestion and proposed merging high quality with being iterative, reusing the "High quality through iteration" wording.
The benefit of that is that the key problem @mrnugget identified, which is that the hard part is figuring out what quality is, is now better defined: you can do that through iteration.
I propose merging that.

I really like where this has ended up @malomarrec @nicksnyder

I like this change a lot (high quality through iteration). I think this captures what we ideally want better than what exists today in the high quality value. It would also have been useful for me to refer people to several times in the last few weeks alone. Thank you for your work iterating on our values to make them higher quality. :)
I want to share this proposed change (this PR) with the company at next company meeting. It seems like a change to values should be mentioned there before being merged, to make sure as many people as possible are aware of it and can give feedback. Along with that we will post to #announcements. Then a few days later we can merge (unless serious issues are raised). @madisongclark Can you please add this to the next company meeting (working with @malomarrec)?
This week I will make a PR to the handbook documenting how I think values changes should go (basically open a PR, get feedback from anyone interested, then w/my approval share it in company meeting and #announcements and wait a few more days for feedback, then merge--which is exactly what is going on here).

Noted, we'll add this to the agenda for the next company meeting. I'll connect with you directly @malomarrec so we can align on the talking points.

I am updating the summary line here: https://github.com/sourcegraph/handbook/pull/3045


chore(codemagic_app_preview): release v0.0.3

⬇ Generated builds by Codemagic for commit b47171cc8e21bd57652890a625392920984f2fc3 ⬇
This is a custom message.

iOS
Android

  Download link
  Download link


Clean up in ExpectingFailureRuleStatement - cherry-pick of #30944 to release

As requested by @blindpirate
Original PR:

#30944

@bot-gradle merge


All code is now PEP8 Compliant

Ran the tests to ensure that all changes work

Thank you 😄

No problem :D
We'll be using your library extensively so thought I'd help out a little :D
Also, I made a small mistake in the commit message. it says, "All code is
not PEP8 compliant".
Please changmake another commit so that it says "All code is now PEP8
compliant"
Regards,
Rahul JR
On Fri, Dec 30, 2016 at 2:03 PM, Jiangge Zhang<EMAIL_ADDRESS>wrote:

Merged #6 https://github.com/tonyseek/simple-rbac/pull/6.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tonyseek/simple-rbac/pull/6#event-907932673, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIHna-Jy-_njyFkr_Oog9YP33EyZ4Nzmks5rNMG8gaJpZM4LYD-t
.


Update README.md

Add chmod command section for the linux binary.

Added little amendments and merged.


feat(version): add --skip-bump-only-release to avoid empty gh releases

Description
When using independent mode, a GitHub/GitLab release is created for each package and very often some of the package will only have a "Version bump only for package x" added to the changelog and a release is created even for these simple bump only package. However these kind of release are not very useful and could be skipped, this is what this option flag will provide to the user when the package is detected to be a version bump only, with this flag enabled, it will not create a release for that package
Note this will be available only under the new major v2.0.0 version and higher of Lerna-Lite
Motivation and Context
Avoid creating too many releases with info that are not that useful, most users are interested in "what changed?" and not so much in "nothing changed in package x"
How Has This Been Tested?
unit tests only
Types of changes

[ ] Chore (change that has absolutely no effect on users)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

@StarpTech I believe this PR and feature could be useful for you and it would be nice to have a review if you get a chance. I'm not using the independent mode and apart from the unit tests that are included, it's a bit hard for me to test it more.

Hi @ghiscoding, thank you for the update. Unfortunately, I had no time to test it.

@StarpTech no problem, it should be ok and it's now released under v2.0.0


[CARBONDATA-2614] Fix the error when using FG in search mode and the prune result is none

the prune result is none, and can not set datamapWritePath, which will not generate bitSegGroup in org.apache.carbondata.core.scan.filter.executer.RowLevelFilterExecuterImpl#applyFilter(org.apache.carbondata.core.scan.processor.RawBlockletColumnChunks, boolean), it mean the bitSetGroup is null. It will throw Fix the error when using FG in search mode and the prune result is none

[x] Any interfaces changed?
No
[x] Any backward compatibility impacted?
No
[x] Document update required?
No
[x] Testing done
run the test case
[x] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.
NO

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/6355/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/5305/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/6358/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/5196/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/5307/

LGTM


Add Thanos Ruler service monitor

This PR,

adds Thanos Ruler service monitor
refactors others to use templating

xref: #123

As a follow up to this, I'll create another PR to refactor out service monitors as we did in #144, then we won't need additional templating.

ping @metalmatze @squat Let's merge this and create another one to move service monitors as #144

rock on


CI: Comment out Vue tests for jump links temporarily to prevent unrelated failures

Temporarily adding a skip to Vue tests on pfe-jump-links because these continue to fail on unrelated PRs.  These will be resolved in https://github.com/patternfly/patternfly-elements/pull/1278.
Ready-for-merge Checklist

[x] Expected files: all files in this pull request are related to one request or issue (no stragglers or scope-creep).
[x] Tests have been updated to cover these changes.
[x] Repository compiles and tests pass.

Merging
Please squash when merging and ensure your commit message uses conventional commit formatting.
Be sure to share your updates with the<EMAIL_ADDRESS>mailing list!

@kylebuch8 Would love your feedback on this - it's a patch that skips Vue on jump links until we can debug the issue.  There's already a PR open that will address this.


I have a transaction stalled pending

Copied from https://github.com/nomiclabs/buidler/issues/686:
I have a transaction started by Buidler Deployer stalled pending and don't know what to do.
I don't know how to find its nonce. I don't know how to make it unstalled after I would find the nonce.
When I try to deploy again:
npx buidler deploy --network rinkeby
All contracts have already been compiled, skipping compilation.
Extracting ABIs...
An unexpected error occurred:

TypeError: Cannot read property 'toHexString' of undefined
    at isHexable (/home/porton/Projects/bounties/cryptozon/eth/node_modules/@ethersproject/bytes/lib/index.js:8:21)
    at Object.arrayify (/home/porton/Projects/bounties/cryptozon/eth/node_modules/@ethersproject/bytes/lib/index.js:65:9)
    at Object.decode (/home/porton/Projects/bounties/cryptozon/eth/node_modules/@ethersproject/rlp/lib/index.js:115:25)
    at Object.parse (/home/porton/Projects/bounties/cryptozon/eth/node_modules/@ethersproject/transactions/lib/index.js:124:27)
    at DeploymentsManager.dealWithPendingTransactions (/home/porton/Projects/bounties/cryptozon/eth/node_modules/buidler-deploy/src/DeploymentsManager.ts:284:18)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at DeploymentsManager.runDeploy (/home/porton/Projects/bounties/cryptozon/eth/node_modules/buidler-deploy/src/DeploymentsManager.ts:519:9)
    at Environment._runTaskDefinition (/home/porton/Projects/bounties/cryptozon/eth/node_modules/@nomiclabs/buidler/src/internal/core/runtime-environment.ts:196:14)
    at SimpleTaskDefinition.action (/home/porton/Projects/bounties/cryptozon/eth/node_modules/buidler-deploy/src/index.ts:144:7)
    at Environment._runTaskDefinition (/home/porton/Projects/bounties/cryptozon/eth/node_modules/@nomiclabs/buidler/src/internal/core/runtime-environment.ts:196:14)

It is on https://github.com/vporton/cryptozon/tree/105ae3e4da93c164c86b67817793b583e9211193 sources.

Thanks for the report, the issue should be fixed in 0.5.x


add PostgreSQL support

add PostgreSQL support

 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.yingzhi.lhb 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.

add PostgreSQL support


#76 styled error message into ul on signup page

Description of changes
Styled error message to give a better user experience.
Issue Resolved
Fixes #76

@lebilly Do you mind attaching a screenshot of what this looks like?

Sure thing. I couldn't produce any errors when filling out the form so I turned the state.error to false to get these warnings.
iPhone 4

iPhone 6 Plus

Desktop

Looks great!


⚠ Spryr has degraded performance

In cdd2381, Spryr (https://spryr.com) experienced degraded performance:

HTTP code: 200
Response time: 10102 ms

Resolved: Spryr performance has improved in f9e91b1 after 15 minutes.


Bug: get empty polygon and line layers

Eg from http://export.hotosm.org/en/exports/1082ca10-c404-4560-bc6d-c3df0ca5c0bf/
Whatever the SIG file format, only the points are correctly extracted

may be a duplicate of #129

This should be resolved by fix applied in #129. I have re-ran the export linked above:
http://export.hotosm.org/en/exports/1082ca10-c404-4560-bc6d-c3df0ca5c0bf/
The Shapefiles created include polygons and lines:

@severinmenard please inspect the new result of the export job and re-open this issue if there is still missing data. Closing for now.

Works for me as well now


Implemented public suffix list.

public suffix list can be cached but after talking with @h-m-f-t it seems small enough to not need caching (197K) and is only downloaded once per run.

public suffix list can be cached but after talking with @h-m-f-t it seems small enough to not need caching (197K) and is only downloaded once per run.

I think this should still be cacheable, very similar to the preload list JSON we also can download once per run. We do that for the preload list integration so that tools which don't rely on pshtt's built-in batching, but rather perform their own batching around pshtt (such as domain-scan), aren't re-downloading the file over and over again.
This does require tools like domain-scan to appropriately manage the cached file (and I recently fixed a bug around that in https://github.com/18F/domain-scan/pull/131), but it's pretty necessary to avoid a large number of network requests.
197KiB isn't a lot on its own, but running pshtt 100,000 times to scan 100,000 domains (which is an ordinary volume for GSA's use of domain-scan) would result in 18.7GiB of data transfer, which is a non-trivial cost of time and money.
Could you model the integration of the PSL after the preload-list based approach?
The documentation for the publicsuffixlist module describes how to cache downloaded data, under the Module content header.
In a lower section on backwards compatibility, the module encourages users to do this, saying:

This module ships with an out-dated copy of the Public Suffix List for compatiblity with older versions. Use of this list is deprecated since it encouraged applications that never updated the Public Suffix List data. The built-in list will be removed in a future version.
If you are using the PublicSuffixList constructor without any arguments, please use the fetch() function and implement an appropriate cache, as shown above.

So that is another reason to download and cache the file locally, to avoid relying on an outdated copy.

@konklone, that only makes sense! Thanks for your help working through this.

@ultiferrago 2f7e6a5 looks good! Is this ready for re-review and merge?

@konklone Yes I believe it is ready.

:+1: Thank you!


refactor to avoid use of globally defined variables

Please fill in this pull request template before submitting
1. This pull request resolves #11
2. Description
Removed use of global variables.
Config file reading performed in a function.
Variables are now passed into each function as needed.
3. Fill in checklist by marking [x]

[X] I've read the CONTRIBUTING.md
[X] I was assigned to this issue
[X] My code is formatted using required linting
[X] I've run my code locally and checked it works

That looks good, my one small suggestions would be to make the file configurable and default to your standard value.

@Stedders Thanks for the review! I'll be making the file configurable in a separate PR 👍🏿


About the reference score

Hi @baeseongsu, apologies for bothering you again, but I have a few detailed questions that I hope you can help me with.

What does "VQA grounding" refer to in section E.1.3?
Could you explain in more detail how DINO is used as mentioned in E.1.3? Is the input anatomical regions? For example, is the input the bbox of the left lung, and the output the answer to questions related to the left lung? Does the training process involve anatomical region bboxes, or is it just based on MIMIC CXR JPG?
Regarding the design of the reference score in Section 6.1, I want to clarify the motivation behind it. For example, with two questions like "Is there {attributeA} in {objectA}" and "Is there {attributeB} in {objectB}," is the reference score used because the answer to each sentence might not be entirely accurate? However, in Table E18, the performance of the ref model is often not as good as M3AE, so does it still serve as a useful guide in such cases?

Thank you in advance!

Hi @Eldo-rado,
You had great questions :), and I would like to share my thoughts about them. Before getting into each detail, I would first like to overview the underlying motivation of section E.1.3, and then respond to your questions.
When creating a benchmark, it's essential to have reference scores (e.g., naive random guessing, human/expert performance score) that give meaning to the performance. Comparing these reference scores with your model's score can indicate how well your model is performing. For our MIMIC-CXR-VQA dataset, we built baselines such as Prior (Most) and Prior (Question), which are powerful in closed-set answer scenarios. Comparing these baseline scores with trained VQA models suggests that the trained models are not just random guessing and have learned to answer the questions to some degree.
We also wanted to estimate the achievable performance (i.e., upper bound) of our MIMIC-CXR-VQA dataset. We know that 100% accuracy cannot be the upper bound because even radiologists aren't perfect at CXR interpretation, so QA performance can't reach 100%. Obtaining a reliable upper bound score (i.e., medical expert score) for all test data through dozens of radiologists was not feasible for us. However, simply reporting performance without context lacks meaning.
Therefore, we aimed to estimate a reference model/score to show the potential performance ceiling for VQA models in the MIMIC-CXR-VQA dataset. To design this reference model, we leveraged the almost ground-truth grounding information (i.e., bounding box of object, binary label of attribute existence) from the Chest ImaGenome dataset. We built a reference model by designing an architecture with an inductive bias and providing grounding information directly during training. Note that VQA models are trained with (image, question, answer) triples, so they learn indirectly and without any inductive bias in the model architecture. Given fair experimental settings, this reference model might have more powerful perception ability compared to the VQA model due to its additional inductive bias.
To illustrate the significance of this reference model/score, consider this example: Given the same dataset, a VQA model trained on the VQA dataset achieves a performance of 0.7 when evaluating verification questions like "Is there lung cancer in the left lung?" across multiple samples. Our reference model, using the left lung as image input and employing a lung cancer prediction head for binary classification, achieves a performance of 0.8 on the same number of VQA samples. This 0.8 score serves as the reference score achievable with correct perception, suggesting that the current VQA model has room for improvement.

What does "VQA grounding" refer to in section E.1.3?

As mentioned in the middle of Section 6.1, we realized that the core perception of VQA models hinges on the question template "Is there {attribute} in {object}?". When a VQA model has good core perception skills, it can solve more complex questions by employing a combination of logical operations. We broadly term this core perception skill of VQA models as "VQA grounding". I acknowledge this may be vague terminology without concrete context; apologies for any confusion.

Could you explain in more detail how DINO is used as mentioned in E.1.3? Is the input anatomical regions? For example, is the input the bbox of the left lung, and the output the answer to questions related to the left lung? Does the training process involve anatomical region bboxes, or is it just based on MIMIC CXR JPG?

Let me illustrate with an example:
For a verify sample (image=X, question="Is there lung opacity in right lower lung zone?", answer="no"), this is transformed into the format (input="right lower lung zone (RLLZ) part of X", classification head="lung opacity", answer="absent(0)"). The reference model then takes the bounding RLLZ box as input and classifies binary labels on the lung opacity classification head. For the training procedure, we incorporated anatomical region bounding boxes. I will add diagrams comparing the reference model and VQA model with the same sample for clarity.

Regarding the design of the reference score in Section 6.1, I want to clarify the motivation behind it. For example, with two questions like "Is there {attributeA} in {objectA}" and "Is there {attributeB} in {objectB}," is the reference score used because the answer to each sentence might not be entirely accurate? However, in Table E18, the performance of the ref model is often not as good as M3AE, so does it still serve as a useful guide in such cases?

There are several reasons for this: (a) Vision-language pretrained (VLP) models like MedViLL and M3AE, while not receiving direct grounding information, can learn implicit correlations between images and questions during training. For example, anatomical finding A1 in region O1 might relate to anatomical finding A2 in region O2, as most physical findings in our body are not entirely independent; (b) VQA models can see the entire image, while the reference model only sees the targeted area (though it's a clearly informative region for classifying the existence of attributes).
Therefore, we conclude that our reference score can act as an achievable performance metric, indicating where VQA models can potentially improve, not explicit upper bound score. However, in cases where VQA models outperform the reference score, as you mentioned, we can't draw definitive conclusions about the VQA model's performance based on the reference score alone. This limitation is part of why we consider it an "achievable" rather than an "upper bound" score.

@Eldo-rado,
If my claims are not incorrect or vague, please feel free to discuss them :) Thank you for asking.

Fully understood, thank you for your explanation! This is very helpful to me. ❤
By the way, perhaps we can try using both the image and region as inputs for DINO. After all, DINO only used the full image during training, and providing only the region during testing may likely lead to a drop in performance. Additionally, when using DINO for inference, CTR and MTR might also need to be considered as mentioned in B 2.2 Question template construction. This is my rough idea; I wonder if it is correct. 😂

Thank you for your sharing. If possible, could you provide me with the DINO-related code and the trained weights? I would like to give it a try. We will cite EHRXQA in our work!

@Eldo-rado,
I will check the DINO-related code and trained weights, and then let you know about them together. I am happy to share our work with you to help you develop better ideas.

@baeseongsu
Thank you for your generosity; I have learned a lot.

@Eldo-rado
Now, you can review the entire code we used for the reference experiment at the github repo link. This includes: (1) How to build a MIMIC-DINO (pre-training MIMIC-CXR-JPG images for the ViT backbone initialized with original DINO v1 weights); (2) How to fine-tune DINO to build a reference model.
We've also shared the pre-trained and fine-tuned weights for these models via dropbox.
While the code might be a bit messy in places, you could use it to understand how to load and use the models.
Best,
Seongsu

Thank you, I will try it. If I discover anything new, I will share it with you. ☺

hi @baeseongsu
Regarding Appendix 2.2, I have a few questions to confirm😂:
1.In Image selection (b), the instruction "select one representative CXR image based on the earliest study datetime" — is this step intended to avoid having different images corresponding to the same report?
2.In Label refinement (b), the instruction to "propagate the presence of attributes from a child object to its parent object" — does this require additional action? I noticed that in the Chest ImaGenome Dataset, it seems this has already been done.
3.Similarly, in Label refinement (c), does "propagate the presence of a child attribute to its parent attribute" require additional steps?
4.In Label refinement (d), is it necessary to "exclude any relationships between an object and its associated attributes that are not allowed by the ontology"? I found in the Chest ImaGenome Dataset paper that they seem to mention, "Using a CXR ontology constructed by radiologists, a scene graph assembly pipeline corrected obvious attribute-to-anatomy assignment errors."
Thx！

Hi @Eldo-rado,

1.In Image selection (b), the instruction "select one representative CXR image based on the earliest study datetime" — is this step intended to avoid having different images corresponding to the same report?

For simplicity, we use one representative CXR image, but you can consider all different CXR images corresponding to the same report if you prefer.

2.In Label refinement (b), the instruction to "propagate the presence of attributes from a child object to its parent object" — does this require additional action? I noticed that in the Chest ImaGenome Dataset, it seems this has already been done.
3.Similarly, in Label refinement (c), does "propagate the presence of a child attribute to its parent attribute" require additional steps?
4.In Label refinement (d), is it necessary to "exclude any relationships between an object and its associated attributes that are not allowed by the ontology"? I found in the Chest ImaGenome Dataset paper that they seem to mention, "Using a CXR ontology constructed by radiologists, a scene graph assembly pipeline corrected obvious attribute-to-anatomy assignment errors."

Regarding Q2, Q3, and Q4: Yes, we did post-processing for those parts. Although Chest ImaGenome has well-defined ontologies including parent-child relationships between objects and attributes, we refined these relationships further under the guidance of medical experts for better ontologies. However, I guess our further label refinement is not crucial, so you can ignore it if you want. But if you want to look deeper into that, I recommend referring to my code about postprocessing labels in the current GitHub repository.

Best,
Seongsu


Error message too unspecific

Bug report
The validation error messages are too unspecific. It would help to know the path to the field that has errors.
Describe the bug
Example query
SELECT jsonschema_validation_errors(
            '{
                "type": "object",
                "properties": {
                    "tags": {
                        "type": "array",
                        "items": {
                            "type": "string",
                            "maxLength": 16
                        }
                    }
                }
            }'::json,
            '{"tags": [1,2,3]}'
        )

produces the error message
{"1 is not of type \"string\"","2 is not of type \"string\"","3 is not of type \"string\""}

It would be great to see a json-path to the field. Something like so:
{
  "$.tags[0]": "1 is not of type \"string\",
  "$.tags[1]": "2 is not of type \"string\",
  "$.tags[2]": "3 is not of type \"string\",
}

Otherwise the error message if not actionable.

pg_jsonschema is a very light weight wrapper around jsonschema-rs. This project bubbles up error messages from that underlying library so I'd recommend opening this on the jsonschema-rs issue tracker if you have thoughts on how he error messages could be improved


Change mumps seq to mpi version

Codecov Report
Attention: Patch coverage is 0% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 99.24%. Comparing base (f47a43a) to head (38a7ecd).
Report is 145 commits behind head on main.

Files
Patch %
Lines

russell_sparse/src/solver_mumps.rs
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##             main     #105    +/-   ##
========================================
  Coverage   99.23%   99.24%
========================================
  Files         175      183     +8
  Lines       39928    40109   +181
========================================
+ Hits        39623    39806   +183
+ Misses        305      303     -2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


React Router website api/hooks documentation internal links do not work

I appologize upfront if this is not the right place to report bugs for React Router documentation website.

Version
Production React Router website Hooks Documentation
Steps to reproduce

Clicking links on the left side menu works fine, but clicking links under Hooks header redirects to the home page. This is true for any link inside this section that isn't external.
Expected Behavior
Scroll down to the section of the page for the clicked link.
Actual Behavior
Redirects to Home page.

Duplicate of https://github.com/ReactTraining/react-router/issues/7484


[FEATURE] evaluation node should evaluate entries in the WHERE clause

The Selection node contains a chunk of code from the Evaluation node because the functions in the WHERE are not evaluated ahead of this node.

Closed by #42


Pull request to merge with master

Story card: chXXXX
Because
Enter the reason for raising this PR...
This addresses
Enter the details of what all this covers...
Test instructions
Enter detailed instructions for how to test this PR...

Commit


Upgrading from 1.6 to 1.8 is not caching our own docker images

Hello All,
First of all, great job.
I have an issue after upgrading from 1.6 to 1.8. For some reason, Kuik does not provide our own images from DockerHub. (Images with imagePullPolicy: Always)
I can see this message for example 2024-05-12T18:19:05.672Z	INFO	webhook.pod	rewriting pod images	{"rewrittenImages": [{"Original":"frontegg/signals-service:master-latest","Rewritten":"","NotRewrittenBecause":"container is configured with imagePullPolicy: Always"}]}
I am guessing it's some kind of configuration that changed yet all other images (like mongo) are working as expected.
Thank you

is this what has changed ?
controllers.webhook.ignorePullPolicyAlways to false


Long term solution for gold files

As the title says. I am starting to spin up implementing the Parthenon regression testing framework into Phoebus. It's basically done, but we are going to need a long term solution for gold files for accepted solutions. Parthenon bakes them into github releases -- are there size limits on that? i.e., would we run into issues far down the line? Thoughts?

I strongly prefer not switching to the release based gold model used in
Parthenon. It requires manually syncing PRs with gold releases which I find
awkward and laborious to set up for the developer, and to review for the
reviewer. I believe golds should be in plaintext and included in PRs as
they are now. The compression option we have in Phoebus where only a sparse
sampling of the gold file can be included in the repository for large files
was supposed to make this workable long-term. Is there a looming problem
with what we have now in Phoebus?
Best
Ben
On Sat, Dec 2, 2023, 9:33 AM Brandon Barker @.***>
wrote:

As the title says. I am starting to spin up implementing the Parthenon
regression testing framework
https://parthenon-hpc-lab.github.io/parthenon/develop/src/tests.html#regression-tests
into Phoebus. It's basically done, but we are going to need a long term
solution for gold files for accepted solutions. Parthenon bakes them into
github releases -- are there size limits on that? i.e., would we run into
issues far down the line? Thoughts?
—
Reply to this email directly, view it on GitHub
https://github.com/lanl/phoebus/issues/187, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQ27SFZMVJIPMLEQ5TLHI3YHNJ67AVCNFSM6AAAAABAEDV5Y6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDEMJRGQ3TMNY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Ah I see. I  missed the process for creating the gold files -- I like this far more than the release model. Should've looked closer. As for looming problems, none. What are thoughts on wrapping the existing infrastructure into the Parthenon tooling for running the tests, so that they e.g., hook into the cmake testing?

I am concerned about the long-term viability of plaintext gold files but they've worked for us up until now, so I'm fine keeping that machinery in place. I do like the idea of hooking into Parthenon's testing machinery other than that.

The Parthenon testing machinery does support plaintext gold files as it just reads whatever you tell it to in the python script.
IMO catch and our regression tests serve different needs, and we’re already using catch for our unit tests.
Parthenon’s regression test suite is actually very similar to what we wrote forever ago for firelink/MOCMC. (And In fact the design is informed by that).
That said, I don’t feel strongly either way, except that it would be nice to be running Phoebus on more hardware than GitHub provides.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Ben Ryan @.>
Sent: Monday, December 4, 2023 8:23:16 AM
To: lanl/phoebus @.>
Cc: Subscribed @.***>
Subject: [EXTERNAL] Re: [lanl/phoebus] Long term solution for gold files (Issue #187)
For some context, I work on a software project with ~5-10 develoeprs that's had ~1000 plaintext goldfiles in the repository for ~10 years that get upgolded regularly and it's never been an issue.
I have a preference (rather than a strong preference) for keeping the test machinery as-is because it works currently and is simple and extensible. Maybe I'm not a power user but I also never found much value in Catch2, I never used it as something other than a wrapper around bool (test passed or failed), and it has had issues in the past with appropriately handling printf/std::cout output, although maybe these are fixed now.
I also don't see any need to give cmake an opinion about how we run tests though I could be missing a useful feature.
One potential issue with the parthenon testing machinery -- does it support plaintext gold files?
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/lanl/phoebus/issues/187*issuecomment-1838873748__;Iw!!Bt8fGhp8LhKGRg!HOXBt-62q9g9qjfovL3Xow5xqV8ViOjgPgqFBrcTlGms5KNry485AKthDuWzm1rva0mVL7AhsDkTMRe2QzYOW2bb$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOO5OJ4FM5AVOBHPXT5URFLYHXTGJAVCNFSM6AAAAABAEDV5Y6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZYHA3TGNZUHA__;!!Bt8fGhp8LhKGRg!HOXBt-62q9g9qjfovL3Xow5xqV8ViOjgPgqFBrcTlGms5KNry485AKthDuWzm1rva0mVL7AhsDkTMRe2QyTbBrsZ$.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

it would be nice to be running Phoebus on more hardware than GitHub provides.

Yeah I strongly agree with this. If parthenon's regression test gets us to this point then it would be quit e useful for development. Thanks for pointing that out.

Not sure Parthenon's regression suite will get us there... someone just needs to set up some CI on the re-git mirror again. Which probably has to be one of LANL staff...

If you want a place to start on Darwin, I could also use more eyes on this: https://github.com/AFD-Illinois/kharma/blob/kharma-next/scripts/ci/darwin.yml
It's pretty basic, no containers or anything, should work with Jacamar.  I use three different downstream pipelines to run on different hardware, and control what runs where with tags.


Fix scalapack: incorrect package name in octopus spack package

This MR renames the incorrect dependency  scalapack to netlib-scalapack.
Fixes #83

Looks like the tests fail at the moment. I'll wait with looking at this until you have fixed or tell me that you would like help.

This is not needed at the moment as the root problem was soled in https://github.com/fangohr/octopus-in-spack/pull/91


Include streaming link in navbar?

Just throwing an idea out there.
At the moment, we're only announcing our twitch streams on discord but I think it should also be accessible via our website.
I'm not sure if this can be included in the upcoming revision but it would be nice to have a link in the navbar that leads either directly to our twitch page or have an embedded page on our website.
I don't know how much traffic we actually get on our website but I feel like the right people will come across our streams much more efficiently.

Thanks Min! this is a great point, I'll add it to our website. The stream wasn't really a thing while I was structuring these pages but it does make a lot of sense to add it now.


Puppet cannot be re-run on master without damaging Jenkins configuration.

At the very least, I think this needs some additional documentation.
Right now re-running puppet on master hosts breaks Jenkins in strange ways due to changes in configuration file formats and the removal of additions made after the initial puppet run.
Using either the facilities in the jenkins puppet API as suggested in https://github.com/ros-infrastructure/buildfarm_deployment/issues/31 or some other means to run scripts against the Jenkins master I would like to make it possible to re-run puppet on master without damaging the buildfarm data.
I'm not sure this is something that we'll be able to do all at once but any new changes to the master profile should make every attempt to be idempotent so we can make headway on the existing code without causing new problems.

This issue has been mentioned on ROS Discourse. There might be relevant details there:
https://discourse.ros.org/t/work-in-progress-chef-cookbooks-for-ros-build-farm-configuration/16371/1


how to optimize Poem's performance (Req/sec)?

Hello,
I find Poem a very ergonomic framework, I've even migrated several projects to Poem, mainly because it offers very good support for OpenAPI 3, but there is one small point that bothers me, it can be optimized to rival the TOP 3 web frameworks (Req/sec performance) that dominate the Rust universe.
it's in the TOP 10, which is already a very good ranking, but the difference with the TOP 3 is approximately ~15,000 Req/sec.
https://web-frameworks-benchmark.netlify.app/result?asc=0&l=rust&order_by=level512
my question is, how to optimize Poem to gain a little performance :

doesn't poem use all threads?
should we add the possibility of tuning the Tokio runtime?
is it related to the code? due to the use of Arc and Mutex?

I'd like to participate in the optimization of this beautiful framework, the first thing I notice is that Poem doesn't let you configure the number of Workers, like ActixWeb for example. Is there any way of adding this feature?
in any case, you've done a great job, and the beauty of this framework fills the small performance gap.

I believe the gap comes from the async-trait, which requires boxing every call to an async method.

I believe the gap comes from the async-trait, which requires boxing every call to an async method.

do you think rust "1.74" with native support for async traits will have a positive impact on performance?

absolute😁


update nan

nan 2.4.0 fails to build with Node 10, because v8::Object#ForceSet has been removed.

node-celt version 0.1.12 published, thanks!


Fix array_transform to not recompute the argument

This fixes https://github.com/NVIDIA/spark-rapids/issues/9472
Thanks to @razajafri for doing the majority of the debugging on this.

build

build

build

@razajafri and @jlowe please take another look


Improve create attestation + nftAttestation flow

I suggest to upgrade NFT attestation flow to improve user experience and ask to sign single message. We can use that update for AutographNFT and other flows, where user create attestaion, based on simple message + web2.0 auth (looks like Ta! flow have same senseless double signature)
Lets see example of AutographNFT
Currently:

User signs simple text message and send signature+web2 auth data to create IDattestation (it can be reused because it doesnt have variable part, message to sign always the same)
User signs "IDattestation + additional data(NFTs in our example)" to create signedNFTAttestation.
Its required for the current flow, becayse signedNFTAttestation based on the signature of IDattestation, what is variable and cant be predefined.

My suggestion:

we create  payloadObject "additional data(NFTs in our example) + timestamps(to avoid signature reuse)" and hash it.
User signs Message "Please sign message 0xff897da6799..  to create your TwitterID attestation."
Dapp sends to server payloadObject + web2 auth data to create signedNFTAttestation.(without additional step)

benefits: User signs single user-friendly text message, not 2 messages.
then user take attestaion +nfts and sign it
does it make sense? @colourful-land , @jot2re
cc: @zhangzhongnan928 @foxgem @AW-STJ

Thinking a bit more about the details of this I believe it is also needed for the user to sign they twitter ID along with a hash of the NFTs and the time stamp. Otherwise a leakage of the signature could be used in a mix-and-match attack (combining it with another twitter handle) in the short time the signature will be valid.
Another minor detail is that the there should also be a message linking the signature to this specific use-case (just to avoid misuse or multiple use if we end up with other settings that require a signature of the NFTs and time stamp)
Finally, instead of using a time-stamp we might want to consider using an unpredictable number like we did with our initial Devcon ticket proof-of-concept.

@jot2re, It makes sense.
unpredictable number contains timestamp and webdomain, so we limit usage to the specific website and add expiration.
so object have to contain

user identifier
unpredictable number
NFTs

I think would be good to add domain name to the message to sign to avoid sign some data from hidden iframe (Metamask dispalys domail, but I am not sure about all other wallets)
so user hashes that object , creates string prefix+hash + "(" + domain + ")" +postfix and send to the server:

object
prefix
postfix
signature
identifier_auth_data (for attestation.id to check identifier validity)

and based on that info attestation.id creates signedNFTAttestation/CoAttestation/etc... and send it to the dapp for use with SmartContract/other

I have to add another comment:
currently signedNFTAttestation signed by user, but in the new flow it will be signed by attestation.id, so it will need small update to the VaidationSmartContract.

@jot2re , @colourful-land , can we make final decision on then flow and implement it?
it will improve UX, because users try to use wallets carefully and every signature can look challenging for wallet with some funds.
cc @AW-STJ

@jot2re, It makes sense. unpredictable number contains timestamp and webdomain, so we limit usage to the specific website and add expiration. so object have to contain

user identifier
unpredictable number
NFTs

I think would be good to add domain name to the message to sign to avoid sign some data from hidden iframe (Metamask dispalys domail, but I am not sure about all other wallets)
so user hashes that object , creates string prefix+hash + "(" + domain + ")" +postfix and send to the server:

object
prefix
postfix
signature
identifier_auth_data (for attestation.id to check identifier validity)

and based on that info attestation.id creates signedNFTAttestation/CoAttestation/etc... and send it to the dapp for use with SmartContract/other

I believe that in a situation as this it makes sense that all the data that is humanly readable is presented in a readable format to the user. This ensures that they have a better understanding of what they sign and don't have to trust the hex data. This is basically what we worked on in issue #201.
In relation to the changes suggested by @oleggrib I think it makes sense that what is signed in readable format is:

Hidden identifier
unpredictable number (including expiration time, domain, randomness)
hash of NFTs
Context information

Besides that, the user sends a proof that the hidden identifier contains their email, and shares this email in plain with attestation.id. This allows attestation.id to verify the mail via OPT (assuming everything happens in one session over TLS).
Then attestation.id co-signs the bundle signed by the user. Thus the user's mail still remain hidden and we ensure that a malicious attestation.id cannot impersonate a user without the user's private key.
However we now end up having to have the user sign lots of different pieces of information that is readable in plain, so maybe it makes sense to do this flow as EIP712?

then user take attestaion +nfts and sign it

I am a bit unsure if this is actually what you mean @oleggrib since then both the attestation request and the usage of it is still signed, right? Or maybe I am misunderstanding.
Is my understanding as I wrote it above correct?

@jot2re , I am trying to find best way to allow user sign single message. Current problem - recursive signature.
userSignature1->identifierAttestation->nftAttestation->secondUserSignature
if we will change object to avoid recursive signatures then we can use payloadSignature to verify users address.
I suggest split signedIdentifierAttestation to the 2 objects:

PayloadObject(timestamp, domain, nfts, identifier) signed by user
IdentifierAttestation based on twitter Auth info + PayloadObject signature

@colourful-land , any suggestions?

I don't think it is necessary to have two signatures. Consider the following flow (in line with what @oleggrib suggest):

User requests UN from attestation.id and an OTP to their email.
User constructs and signs PayloadObject(UN (including expiration and domain in plain), hash( hidden identifier, NFTs, OTP), context information.
The user then sends  PayloadObject along with email, ZKP of hidden identifier to email, NFTs, OTP
Attestation.id validates the PayloadObject, ZKP and OTP and if it is okay, then it co-signs PayloadObject and returns it to the user.
The user can then post this co-signed PayloadObject to the smart contract
The smart contract validates attesation.id's signature and that expiration has not passed. It can then do its thing with the user's address which it can extract from the user's signature.

This way the user only signs once and the usage of a UN protects against future signings. The email is never revealed to the smart contract, yet what is signed is actually linked to the email verification via the OTP
Note: Even better we can have the OTP can simply be used as part of the randomness/context in the ZKP.
@colourful-land what do you think about this flow?

@jot2re , in case if we want to use IdentifierAttestation multiple times (per 1 hour or per 1 day ...) then we have to skip OTP from PayloadObject, because on next usage we will not have saved OTP and it can be not very good user experience if user have to enter OTP on each request.
And in case of twitter attestation we dont have OTP, but auth token. So better send OTP/twitterAuth/etc... in raw format to the attestation.id ( time to time attestation.id can add new auth type or update existing, so better separate it from PayloadFlow and let attestation.id deside format of the auth data )

@oleggrib :

I have to add another comment: currently signedNFTAttestation signed by user, but in the new flow it will be signed by attestation.id, so it will need small update to the VaidationSmartContract.

Why? I feel much was lost in the communication, attestation.id is a shared service to issue identifier attestations, hence the name, that is, it's not attetation.com or attestation.xyz, it is attestation.id so that it is for identifier attestations. why should it sign nft attestations? Why should a user trust a 3rd party service to dictate what happens to their NFT? I will be pretty upset as an NFT holder to know that there exists a key that is not in my wallet that can do things to my nft.

@jot2re @oleggrib I'm afraid we forgot why NFT attestation and the signature to obtain identifier attestation was created in the first place.
First, there is a size limit on how much data we can send to a smart contract and we should not waste it, since additional data easily gets denied by eth nodes or cost gas. we learned this the hard way in 2017 when a user buys too many FIFA tickets and the transaction can't go through. I remember even 9 tickets is too many. With the bag of goods @oleggrib is proposing I think we will hit the same problem again. Byte length was also the main reason why we used ASN.1 instead of plain text json file for attestations. (the secondary reason was to make the format extensible).
Second, that this statement is incorrect. If it is implemented that way, it must change:

User signs simple text message and send signature+web2 auth data to create IDattestation (it can be reused because it doesnt have variable part, message to sign always the same)

The reason is the message must not be reusable, since the user is expected to recreate identifier attestation once it expires, and there is an attack model to capture this message and reuse it.
Third, attestation.id is a 3rd party identifier attestation issue, for god sake, the name was chosen to reflect that (.id), if you make it an authority in token ownership or derivation right no one is going to trust it as a 3rd party service.
Finally, the signature (2 times) is only for the first time user, for the sequential transactions they only needed to sign nftAttestation. It's not impossible to combine these two (the signature for attestation.id to grant identifier attestation and the signature to create nftattestation), but it's going to be nearly impossible, without breaking the design, as the data needed for the 2 signature has no cross section! NFT data is not needed when user try to get identifier attestation, and it is actually harmful for it to be there, since attestation.id should only learn about user's identifier and not what the user is going to do with it. Imagine a user wants to sell a $10m USD worth of NFT and now attestation.id knows what the user is going to do with it. Again, identifier attestation is needed as part of NFTAttestation, so how do you get that before it is granted?
Signing messages 2 times is not good, but leaking privacy to attestation.id and/or making attestation.id an authority on anything but identity (therefore killing its reusability for other NFT projects) is even worse. remember we are building attestation.id with the view for them to be directly used as an identifier attestation issuer, not as a client-deployed micro component for each client to issue their own identifier. I just don't see how every token project issuing their own identifier attestation will work in the long run, since the result is not interoperatable, token projects already know identifier data therefore can just issue tokens based on them without any need to attest in the first place, and the network is centralised around projects.

Second, that this statement is incorrect. If it is implemented that way, it must change:

User signs simple text message and send signature+web2 auth data to create IDattestation (it can be reused because it doesnt have variable part, message to sign always the same)

The reason is the message must not be reusable, since the user is expected to recreate identifier attestation once it expires, and there is an attack model to capture this message and reuse it.

Currently (as least when reading the java code) the AttestationRequest is based on a nonce, consisting of the address of the user, attestation.id and a timestamp. Hence reuse of the original AttestationRequest is not possible since the timestamp is only valid for 20 min (current configuration).

@colourful-land in relation to the other point you make, I totally understand the desire to segregate roles. However, consider the flow mentioned above:

I don't think it is necessary to have two signatures. Consider the following flow (in line with what @oleggrib suggest):

User requests UN from attestation.id and an OTP to their email.
User constructs and signs PayloadObject(UN (including expiration and domain in plain), hash( hidden identifier, NFTs, OTP), context information.
The user then sends  PayloadObject along with email, ZKP of hidden identifier to email, NFTs, OTP
Attestation.id validates the PayloadObject, ZKP and OTP and if it is okay, then it co-signs PayloadObject and returns it to the user.
The user can then post this co-signed PayloadObject to the smart contract
The smart contract validates attesation.id's signature and that expiration has not passed. It can then do its thing with the user's address which it can extract from the user's signature.

This way the user only signs once and the usage of a UN protects against future signings. The email is never revealed to the smart contract, yet what is signed is actually linked to the email verification via the OTP
Note: Even better we can have the OTP can simply be used as part of the randomness/context in the ZKP.

Here attestation.id does not need to learn about the NFTs. It only learns a hash digest (which can easily be hiding by adding some salt). All attestation.id learns is that the user wish to create a single-use attestation to be used for NFTs.
However, I also understand if that might be too much, because in that case attestation.id could block all requests of this nature if it wants to not allow attestations to be used for NFTs.


Fixed #35645, Refs #35558 -- Made H1 styling visually stronger than other headings in the admin.

Trac ticket number
ticket-35645
ticket-35558
Branch description
Following the review of PR #18308, it was noticed that since the inline H3 header was set to --body-loud-color, in the light theme this color (black) is stronger than the page's H1, which is --body-quiet-color (#666, dark-ish gray).
Once approved I'll update the relevant docs screenshots.

Before:

After:

Checklist

[X] This PR targets the main branch.
[X] The commit message is written in past tense, mentions the ticket number, and ends with a period.
[X] I have checked the "Has patch" ticket flag in the Trac system.
[ ] I have added or updated relevant tests.
[ ] I have added or updated relevant docs, including release notes if applicable.
[X] I have attached screenshots in both light and dark modes for any UI changes.

Solution looks good to me!
We would need to update the images docs/ref/contrib/admin/_images and docs/intro/_images for this change

Solution looks good to me! We would need to update the images docs/ref/contrib/admin/_images and docs/intro/_images for this change

Thank you! Yes, I added a small disclaimer in the description saying this. Considering that you are on board with the changes, I'll proceed to take new screenshots. :framed_picture:

This is a good improvement.
A bit weird to me that the fidlset headers are still quieter than the labels that live under them, but not sure if I'm just nitpicking at this point.

Hmm not really a big fan of that, because I find it quite hard to distinguish between required and non-required inputs now.

Hmm not really a big fan of that, because I find it quite hard to distinguish between required and non-required inputs now.

Would it help if we make them #444 as well using --body-medium-color?

@knyghty Specifically, this would be the result for:

label required with medium color:

label required same color as non required with bold:

@knyghty @sarahboyce I have created an alternative solution (which I like better) in https://github.com/django/django/pull/18439
I have added a bunch on non required fields, both in tables and regular stacked forms to better evaluate the visuals. LMKWYT!

Closing in favor of #18439.


Added description for Installation process

Hi! I want to first thank you for such an amazing project! As a windows user, when I started using openlrc I encountered an error for missing the cuBLAS library, I eventually found in the faster-whisper repo installation guide that cuBLAS for CUDA11 is also needed. So I made a small change to the first step for installation to include this. I also added a little section (folded for more readability) for windows users to conveniently download the correct version of libraries from an archive. I can also help to write a detail guide on how to include the libraries into PATH variable if needed. I was hoping that these changes could help people who are new to CUDA and Whisper (like me) to better get started! Thanks again for the great project and I hope you can consider this PR!

Thanks for PR!


Add note using CA issuer as intermediate

Add documentation (note) on how to use CA issuer as intermediate. This was already missing from the docs, but the note is now reflecting the behavior suggested in https://github.com/jetstack/cert-manager/pull/3847.
English is not my native language, so feel free to suggest wording improvements... 😄 And used PKI terms may also be scrutinized.
Blocked by https://github.com/jetstack/cert-manager/pull/3847
/hold

/assign @munnerz

@uncc @munnerz
@cc @SgtCoDFish
It seems like @munnerz is not very active atm, but feel free to take a look. 😄 Hoping to get some feedback on the PKI wording from @SgtCoDFish.

/uncc @munnerz
/cc @SgtCoDFish

/unhold

/approve
/lgtm


Crash in genCodeWithContents:machineReadableCodeObjectType:

I keep seeing a LOT of crashes in my beta build of an app I'm doing and all stack traces point to some part of your library (which, is awesome, btw).
Here's a screenshot of it:

Any idea how I can fix this?

Could you provide me the code in EOTViewController viewDidLoad and the context variables?


Support UWP and fix some small issues (take 2)

First cut to switch to FrameRenderer;
CornerRadius -> CornerRadii;
implement UWP PancakeViewRenderer;
fixed iOS border/clip mismatch using same path for both;
Implemented BackgroundColor for iOS;
much verification to do!
NOTE: integration into csproj files NOT done.
Addresses #10

Hey @craigwi - I'm fixing pretty much most of the current rendering issues that it has on a separate branch: https://github.com/sthewissen/Xamarin.Forms.PancakeView/tree/feature-improve-rendering
This has one small bug left in it before I would probably merge that into master. How would that play with your stuff? 🤔

I'll check.

The only substantial overlap in areas I changed with your recent changes was in the iOS renderer.  It looks like you addressed some if not all of the issues I did (albiet differently).  I'll move my changes forward when you integrate into master.

#49 Should introduce basic UWP support. Check the matrix on the README to see what isn't in yet.


idream -getting poor results

HI
thank you for idream implementation
i used DeepFashion dataset to check if i can use change human pose ( like the paper show )
unfortunately i didn't succeed to get good generated images
for example :
source image

after trying to change  posture (“A person with crossed arms”)
i got bad results ( for different levels of alpha )
0.6:

0.8

0.9:

i tried with more images and more text prompt and increase alpha range but nothing works for me
did someone succeed getting good results ?
thanks

Yeah it seems quite sensitive to parameters, I found sometimes that doing the first stage training, (training the embedding) for longer helps.


404 at /docker-for-windows/wsl/%20for%20details

I found a broken link : https://docs.docker.com/docker-for-windows/wsl/ for details

Hi @dslzuha
Thanks for reporting the broken link issue. Could you let us know how you arrived at the broken link?

Thanks for reporting; the correct URL is now https://docs.docker.com/desktop/windows/wsl/
I found where the "faulty" URL is coming from; more details in https://github.com/docker/docker.github.io/pull/13382.
I'm closing this ticket, because the broken link is not in the docs itself, but will be fixed in Docker Desktop.


docs(style-guide): add the image width attribute

Adding the width attribute to the gif image of visual studio extension for supporting mobile phones.

Why? Why is it a problem for this image and not every image in the docs?

@wardbell because every other image's width is smaller than mobile screen size, but the size of this image is bigger than 700px.
I think that the "%" width attribute of it for supporting mobile is need.
Thanks.

LGTM

Thanks. Merged.


User type selector

Description
Create the component as shown in the video attached below.
Animation Preview

Screenshot/Video:

https://github.com/user-attachments/assets/4f4ba07b-5160-4810-88ce-e2dbf925023c

[!NOTE]
Please refer to the Animata contributing guidelines available here for rules on how to contribute to the project. Let us know in the comments if you’re working on this issue, and feel free to ask any questions!

Requirements

Create a new animated component that matches the provided design.
Add example usage of the component in the documentation or storybook.

 Guidelines & Best Practices

Write reusable and clean code following the project’s style guide.
The component should be fully customizable. The user should be able to modify props such as duration, easing, color, and size where applicable.
Follow the Contributing Guidelines before submitting your pull request.

[!IMPORTANT]
To ensure more contributors have the opportunity to participate, we kindly request that:

Each contributor submits only one pull request related to this issue.
If you're interested in working on this issue, please comment below. We will assign the issue on a first-come, first-served basis.

Additional Resources
Posted on X by: https://x.com/djordjevanjek/status/1825873503096287567

[!Tip]
Join our Discord community if you need help or have any questions. We're here to help you get started and guide you through the process. Join now

@sudhashrestha @hari Hey I want to work on this feature

@sudhashrestha @hari if he is not active. Can i work on it ?

@Rish1369 are you working on this?

@sudhashrestha  can you assign it to me ?