Add remapping  to identifier when parsing argument label

Fixes the issue #829 by remapping the default keyword to identifier.

Awesome. There's probably a few other places we're failing to do the remapping but this will stamp out a whole class of bugs.
@swift-ci test

@swift-ci test Linux

@swift-ci test

@ibrahimoktay thanks for fixing this! The failure is because a dependent project (swift-stress-tester) had a test that now fails with your fix. It happened to have a FIXME there already, so I just updated it.
@CodaFi these need to be merged together.

@ibrahimoktay thanks for fixing this! The failure is because a dependent project (swift-stress-tester) had a test that now fails with your fix. It happened to have a FIXME there already, so I just updated it.
@CodaFi these need to be merged together.

Thanks for helping @bnbarham I tried to check the details but I was not able to understand what was failing. Is there a way to see where it fails ?

sourcekit-lsp uses token kinds for classification so I'll go update those tests as well.

Ah, this is a proper failure. This patch now makes us remap underscores as identifiers. They ought to remain as keywords.

Thanks for helping @bnbarham I tried to check the details but I was not able to understand what was failing. Is there a way to see where it fails ?

In the build logs, though they might not have been super easy to find if you looked after I started the tests again (you could find it by going to https://ci.swift.org/job/swift-syntax-PR-macOS/ and looking for the last failure for this PR)  - https://ci.swift.org/job/swift-syntax-PR-macOS/1075/console
Test Case '-[StressTesterToolTests.ActionGeneratorTests testCompletionExpectedResults]' started.
/Users/ec2-user/jenkins/workspace/swift-syntax-PR-macOS/branch-main/swift-stress-tester/SourceKitStressTester/Tests/StressTesterToolTests/ActionGeneratorTests.swift:97: error: -[StressTesterToolTests.ActionGeneratorTests testCompletionExpectedResults] : XCTAssertEqual failed: ("["data", "position", "default:"]") is not equal to ("["data", "position"]")
Test Case '-[StressTesterToolTests.ActionGeneratorTests testCompletionExpectedResults]' failed (0.518 seconds).

The latest failure is in sourcekit-lsp in testSemanticTokensForFunctionSignatures (search for "1 failure" in https://ci.swift.org/job/swift-syntax-PR-macOS/1080/consoleText). It's a little harder to understand in the format there, but if you split out the ranges onto lines then you'll see the difference is:
SourceKitLSP.SyntaxHighlightingToken(range: Range(Position(line: 0, utf16index: 15)..<Position(line: 0, utf16index: 16)), kind: SourceKitLSP.SyntaxHighlightingToken.Kind.identifier, ...),

vs
SourceKitLSP.SyntaxHighlightingToken(range: Range(Position(line: 0, utf16index: 15)..<Position(line: 0, utf16index: 16)), kind: SourceKitLSP.SyntaxHighlightingToken.Kind.keyword, modifiers: ...),

And if you look at the test case, that range is an _, which is what @CodaFi mentioned above. So parseArgumentLabel needs to leave underscore as a keyword rather than remapping to an identifier, which we should add a test for here as well.

I have kept the remapping and just excluded the .wildcard which seemed to be a better approach to me (might fix other possible issues). Would you prefer to remap only if it is .defaultKeyword so that It could be safer?  @CodaFi @bnbarham

I have kept the remapping and just excluded the .wildcard which seemed to be a better approach to me (might fix other possible issues). Would you prefer to remap only if it is .defaultKeyword so that It could be safer? @CodaFi @bnbarham

LGTM, thanks.

Thanks @ibrahimoktay!


Not training enough times

Stopped training after only running 6 times, although it displayed as RUING, there was no issue with memory usage.
Ubuntu 22.04.3 LTS
python 3.8.18
nni 3.0b2

nnimanager.log

The same in https://github.com/microsoft/nni/issues/5689


Database error after processing order

Hi. I thought everything was working great on this plugin but I'm getting an error (see attached) after it processes the order via PayPal. The order goes through but then when browsing back to the shop/products page, it is broken with the attached message. I'm not a developer so doesn't mean much to me but posting up so someone might be able to fix the bug.
I'm running Concrete <IP_ADDRESS> from the updates folder (would this make a difference?).
Apart from the error, it's looking like a fantastic product! I guess I shouldn't have tried using it on a live site yet :(
Thanks,
Nev

I think you might have hit the same issue as this one here, https://github.com/concrete5-community-store/community_store/issues/285, where a product list is displaying in 'Best Sellers' order.
Fortunately the fix is easy, it's just changing this line here:
https://github.com/concrete5-community-store/community_store/commit/2677facc3f01228e45e357250a7f55cd7bb219d1#diff-82f99f6e29e208e07ba4979e54841732R185

@Mesuva, I'm not a sql guru but isn't it weird that we're trying to assign a value to pID in an ORDER BY clause?
Why would it be ORDER pID = ? instead of just ORDER BY pID
Also it probably should be p.pID

Excellent! The fix worked. Thanks guys.


Unable to order context menu items for contributed tree

The ordering of the context menu items in my contributed tree view doesn't match the packages.json:

I saw in some other case that I can control them with @x in the group, so I changed them to the below, however this didn't make any difference.
{
	"command": "_flutter.outline.refactor.flutter.wrap.center",
	"title": "Wrap with Center",
	"category": "Flutter@1"
},
{
	"command": "_flutter.outline.refactor.flutter.wrap.padding",
	"title": "Wrap with Padding",
	"category": "Flutter@2"
},
{
	"command": "_flutter.outline.refactor.flutter.wrap.column",
	"title": "Wrap with Column",
	"category": "Flutter@3"
},
{
	"command": "_flutter.outline.refactor.flutter.wrap.row",
	"title": "Wrap with Row",
	"category": "Flutter@4"
},
{
	"command": "_flutter.outline.refactor.flutter.move.up",
	"title": "Move widget Up",
	"category": "Flutter@5"
},
{
	"command": "_flutter.outline.refactor.flutter.move.down",
	"title": "Move widget Down",
	"category": "Flutter@6"
},
{
	"command": "_flutter.outline.refactor.flutter.removeWidget",
	"title": "Remove widget",
	"category": "Flutter@7"
}

@DanTup You need to add a group property to the command placements.
For example:
            "view/item/context": [
                {
                    "command": "gitlens.openBranchesInRemote",
                    "when": "viewItem == gitlens:branches:remotes",
                    "group": "1_gitlens@1"
                },
                {
                    "command": "gitlens.openBranchInRemote",
                    "when": "viewItem =~ /gitlens:(branch\\b(.*?:tracking|:remote))/",
                    "group": "1_gitlens@1"
                },

Also your usage of category above is confusing it with group. The category is shown to users in the command palette.
Hope that helps!

@eamodio Right, group has to be used. I did not see that.
@DanTup Try with group and let me know if it works

Doh! group seems to work fine - my bad. Thanks!


deleted when editing time

What happened
when editing the time and saving the entry gets deleted
ideas

this happens in general when the time is edited

That's expected. Should have made clear that this is in the dev version. The issue originates from #44 (the problem you described).

Actually not a bug just me using the wrong display Intervall.


WIP: Feature/testng

Hi @atm1020,
I have added support for TestNG. There is still some refactoring and testing to do, but the happy path works. Let me know if you are interested and I'll finish up the work in the next couple days.

@rhilliges TestNG support is a planned feature, so yes, iam definitely interested. i will review your work shortly, but before that i have a bit of work to finish with the current version of this project (I mean with a junit 5 support etc)

Sounds good. I'll just keep on testing and might push some more fixes.


regenerate-certificates needs to address derivative resources

We need to make the client-ca correct or kubelets cannot connect to the kube-apiserver.

/retest

This is built on current head and holding up disaster recovery.


Update Overflown URLs - settings-data.blade.php

not really a coder, but fixed the overflow of URLs in data section which made the items go off the white background.

fixed -

@all-contributors please add @Woahai321 for bugs


Question about sub2 and sub4 share three phases convolution.

Thank you for your codes.
I run your code and get a better results,but when I check the code, I am confused ahout the following code:
# sub 2
x_sub2 = F.interpolate(x, scale_factor=0.5, mode='bilinear', align_corners=True)
_, x_sub2, _, _ = self.base_forward(x_sub2)
# sub 4
x_sub4 = F.interpolate(x, scale_factor=0.25, mode='bilinear', align_corners=True)
_, _, _, x_sub4 = self.base_forward(x_sub4)
In the paper and your discussion , it explains that sub2 and sub4 will share the weights and computation, but in your code, you just put the 1/2 and 1/4 image to the basemodel, am I right?
how do your share the weights and convolution or how do your understand the definition of the share.

@SecondLi  Hi, no thanks.
In my opinion, the definition of the "share" is:

Define the parameter once,  and update it repeatedly.


[PRODUCT] APRFC data products

Product Source (URL Preferred)
https://cbt.crohms.org/akgrids/
Product Description
ABRFC QPF, QPE, QTE, QTF
Product Format

[ ] Geotiff
[x] Grib2
[ ] NetCDF
[ ] Other (Please provide description below)

Format Description
APRFC Forcings for USACE (1).docx

ABRFC QPF, QPE deployed to stable.  Thanks to @Enovotny for working on the migrations and processors.

QPE and QPF values are suspicious, showing 60+ inches over 1 to 2 days

Fix by @msweier deployed to stable.  This can be closed if @FHanbali will test the downloaded results again.

@msweier I'm still seeing large precip values.   I cross checked a download from cumulus for a forecast starting at 09August2024-1200 against original grib files (which have "mm" units).   It seems that Cumulus is not converting from "mm" to "inches" properly.

Here are the test Cumulus download and original APRFC files
APRFC_QPF_Tests.zip

Also wanted to verify, once a fix is complete for this, will the entire archive for this product in Cumulus get corrected please?

We do not convert units as it goes from raw product to geotif (done by async_geoprocessor).  Original units should remain.
The fix attempted by @msweier was to change the units for the product in the database which the async_packager uses to create the dss download.
No files should need reprocessed. Once fixed the future downloads should e correct.
I'm not able to look deeper into this issue right now.

@msweier I'm still seeing large precip values. I cross checked a download from cumulus for a forecast starting at 09August2024-1200 against original grib files (which have "mm" units). It seems that Cumulus is not converting from "mm" to "inches" properly.
Btw, the DSS download from Cumulus has units of "inches" for the DSS records, but I'm pretty sure the values have not truly been converted to inches. Suggest writing out the records with units of "mm" anyway, that way you wouldn't have to worry about unit conversions.
@adamscarberry I'm curious if all the products in Cumulus are getting unit conversions?

Thanks for the test data @FHanbali. I'll take a look.


React Aria useButton mouse click triggers :focus-visible styles

🐛 Bug Report
When clicking on a <button> element using useButton that has :focus-visible styles, React Aria seems to apply focus-visible to the <button>.
🤔 Expected Behavior
Clicking on any element should not activate focus-visible on that element.
😯 Current Behavior
Clicking on a <button> which uses useButton will apply focus-visible to that element.
🔦 Context
Before implementing React Aria, we went out of our way to apply unique styles for elements that were focused using clicks/presses and elements that were focused using the keyboard. After implementing React Aria, all components based on useButton apply those :focus-visible styles on mouse click.
🌍 Your Environment

Software
Version(s)

react-spectrum
3.2.2

Browser
Google Chrome 86.0.4240.183

Operating System
MacOS 10.14.6

Can you provide a codesandbox to demonstrate this? I'm not quite following. Also, we don't have a @adobe/react-spectrum or a react-aria version 3.2.2, what version are you using?

@snowystinger Codesandbox link is below (and also added to original post). The example is using CSS modules for styling because that's what we are using in our app, but I don't think the styling method would make a difference.
https://codesandbox.io/s/react-aria-button-focus-visible-s29dz?file=/src/Btn.js
Not sure what you mean about the version - we're definitely using @react-aria/button at 3.2.2 (latest) as you can see in the Codesandbox. Maybe I'm just not understanding your versioning system.

This is possibly because we programmatically focus the button on mouse down. I'm not sure what the heuristic Chrome uses to determine when to show focus-visible styles. Also, fwiw, :focus-visible doesn't have 100% browser support yet - Safari doesn't support it. In Safari, neither of your focus styles seem to be applying for me. It also doesn't appear to be working in Firefox, though possibly you need to use their non-standard :moz-focusring pseudo class instead? Even then, there's no guarantee that browsers implement the same heuristic to determine when to apply these - the spec doesn't say what it should be.
Have you considered using React Aria's useFocusRing hook to apply your focus styles instead? This will ensure everything works consistently across browsers.

Also, fwiw, :focus-visible doesn't have 100% browser support yet - Safari doesn't support it. In Safari, neither of your focus styles seem to be applying for me.

We're aware of this. The CodeSandbox is a reduced test case that shows the issue, but our actual code uses fallback focus styles for browsers like Safari, etc.
Based on everything I've read about focus-visible and the official spec the current behavior of @react-aria/button and link do not seem to match the intent. I know it may seem like a small detail, but for people who put a lot of effort into the polish of their app design, this is an issue and we've opted to explore other options because of it.
React Aria is great, though. Thanks for your work on it.

Ok, I don't think there is anything we can do about it though 🤷. The behavior is entirely dependent on what browsers decide to implement. I think I would classify this as a Chrome bug - the element receives focus during mouse down so therefore Chrome shouldn't apply the focus visible styles. But then again, the spec only suggests a heuristic and leaves it up to browser vendors to decide what to do.
Again, for consistent behavior, I would suggest using useFocusRing. We've put a ton of effort into testing it across every device and dealing with all the edge cases. Given that you're already having to implement fallback styles (presumably using JS?), perhaps you could use this instead and avoid re-creating it on your own?

FWIW, if you're curious about why we preventDefault on mouse down and focus the element ourselves, you can read this section from our blog series on the complexities of building consistent buttons. If you want to read more, here's the first post in the series and you can follow the links to the rest.

Thanks for the clarifications @devongovett I really appreciate it. Everything you're saying makes sense, and I do think the application of the :focus-visible styles when focus is applied via JS is probably a Chrome bug. It's just unfortunate that Chrome applies :focus and :focus-visible styles in a consistent way when focus is being applied via standard keyboard and mouse events and not via javascript.
We're not using JS to apply any focus styles in the app currently - that's all being handled via CSS, including fallback styles - but I definitely get why applying them via JS would be more consistent if we went all in on it.
Thanks again for your thoughtful responses.


Add lapack link options to make travis work

Using intel compiler with mkl loaded in the environment this compilations works
FoBiS.py build -mode tests-intel-debug -cflags="-mkl" -lflags="-mkl"
but travis compiles using gfortran and does not work now. To be fixed.

@francescosalvadore using Intel on Travis is possible, but not simple and the license terms is not clear to me. In my starred repo-list I found one repo devoted to Intel compilers on Travis, but with only my dated smartphone I cannot link it.

@szaghi probably the best is just to add https://github.com/qsnake/lapack as submodule and setup the compilation using it. The linear solver used so far is just for testing since it uses very slow general matrixes.

@francescosalvadore ok, tomorrow I will be st office (for a while) I can do it, but you have to push :smile:

@francescosalvadore
other linear solvers implementation

https://github.com/Reference-LAPACK/lapack
https://github.com/xianyi/OpenBLAS

@szaghi I don't know. If it compiles and works it is ok with me...

Yes, I will play with some alternatives later today... I hope to push one reasonable solution. My concern is that lapack is about 80MB of data, I do not like to add it as git submodule...


Change the IRC interface for easier usage and channel selection

This PR adds support to select channels for the IRC bot, without introducing
a huge amount of additional bots.
The bot can now be configured to listen for certain patterns and to use
a certain channel to evaluate the code.
My current irc.yaml looks like:
- nickname: "playbot-dev"
  server: irc.mozilla.org
  port: 6667
  channels:
    - "#rust"
  keys: [null, "hunter2"]
  password: abc123abc
  triggers:
    #- [ "playbot:(.*)", "stable", True ]
    #- [ "rusti:(.*)", "stable", True ]
    #- [ "playbot-mini:(.*)", "stable", False ]
    #- [ "rusti-mini:(.*)", "stable", False ]
    - [ ">>(.*)", "stable", True ]
    - [ "n\\s*>>(.*)", "nightly", True ]
    - [ "nightly\\s*>>(.*)", "nightly", True ]
    - [ "b\\s*>>(.*)", "beta", True ]
    - [ "beta\\s*>>(.*)", "beta", True ]
    - [ "s\\s*>>(.*)", "stable", True ]
    - [ "stable\\s*>>(.*)", "stable", True ]

The commented triggers can be uncommented in order to continue listening
like it did before this change.
The only drawback I could find, is the loss of tab-completion for the
playbot-mini nickname, but that shouldn't be much of a problem, considering
this was the case for the rusti[-mini] names, and there now are new, shorter, ways
to invoke playbot.
I recommend the addition of short triggers for the "playbot-mini" mode.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

This looks like it's also adding some form of feature detection via the normal repo's feature detection script, could that be split off into a separate PR?

@alexcrichton If I was to split off into a separate PR, would I have to have a second branch and commit to that one, then PR that new branch?

Yeah you'll need to remove the commit from this branch and make a new branch with that commit on it to split it off. You can then force-push the branch of this PR to update the PR.

@alexcrichton I'm sorry, I tried and failed several times. It would be easier if the commit in question was the last commit, but it isn't. Why is that needed?

Right now I don't think we don't want to copy scripts from the main distribution and slightly modify them, as I believe there are known deficiencies for feature detection. Additionally it's not clear to me that the playpen should be dealing with features just yet. I'd prefer to consider all that independently of minor configuration changes.

@alexcrichton I deleted the feature detection stuff. Check again?

Thanks @tilpner!

@tilpner Are you still interested in finishing this? I am interested in this feature. I can try and finish it if you aren't anymore.

@crumblingstatue Yup, definitely am. For some reason, I forgot to finish this though, so thanks for reminding me. :)

@alexcrichton I updated for the password changes. Have another look now?

Oh dear this took me way longer than it should to have gotten to this, thanks @tilpner!

Er actually, sorry I had to revert this in #156 because there's some changes that I don't think were brought over. It looks like this removes the ability from one config file to start up multiple connections (e.g. this is just one nick/server combination) which we currently use to log in as playbot and playbot-mini on both mozilla IRC as well as freenode.
Also, could you let me know what the configuration is to migrate over from an old one? Our current configuration looks like:
- server: irc.mozilla.org
  port: 6667
  channels:
    - "#rust"
    - "#rust-fr"
    - "#rust-gamedev"
    - "#rust-internals"
    - "#rust-offtopic"
    - "#rust-osdev"
    - "#rust-webdev"
    - "#servo"
    - "#rustc"
    - "#rust-libs"
    - "#rust-lang"
    - "#cargo"
    - "#rust-de"
    - "#rust-beginners"
  keys: [null, null, null, null, null, null, null, null, null, null, null, null, null, null]
  password: password
- server: irc.freenode.net
  port: 6667
  channels:
    - "#rust"
  keys: [null]
  password: password

Yes, that is correct. This won't start multiple bots at once, but instead allow to listen for multiple configurable triggers.
This PR is so old, I'm unfortunately unable to test if this still works, because I'm not using Arch anymore.
Here's the adapated irc.yaml from a backup of this project.
nickname: "playbot"
server: irc.mozilla.org
port: 6667
channels:
    - "#rust"
    - "#rust-fr"
    - "#rust-gamedev"
    - "#rust-internals"
    - "#rust-offtopic"
    - "#rust-osdev"
    - "#rust-webdev"
    - "#servo"
    - "#rustc"
    - "#rust-libs"
    - "#rust-lang"
    - "#cargo"
    - "#rust-de"
    - "#rust-beginners"
keys: [null, null, null, null, null, null, null, null, null, null, null, null, null, null]
password: password
templates:
  - &template "
        #![allow(dead_code, unused_variables)]

        static VERSION: &'static str = \"%(version)s\";

        fn show<T: std::fmt::Debug>(e: T) { println!(\"{:?}\", e) }

        fn main() {
            show({
                %(input)s
            });
        }"
  - &no_template ""
default_template: *template
triggers:
  - template: *template
    channel: "stable"
    triggers:
        - "playbot:(.*)"
        - "rusti:(.*)"
        - ">>(.*)"
        - "s\\s*>>(.*)"
        - "stable\\s*>>(.*)"

  - template: *template
    channel: "beta"
    triggers:
        - "b\\s*>>(.*)"
        - "beta\\s*>>(.*)"

  - template: *template
    channel: "nightly"
    triggers:
        - "n\\s*>>(.*)"
        - "nightly\\s*>>(.*)"

  - template: *no_template
    channel: "stable"
    triggers:
        - "playbot-mini:(.*)"
        - "rusti-mini:(.*)"
        - ">(.*)"
        - "s\\s*>(.*)"
        - "stable\\s*>(.*)"

  - template: *no_template
    channel: "beta"
    triggers:
        - "b\\s*>(.*)"
        - "beta\\s*>(.*)"

  - template: *no_template
    channel: "nightly"
    triggers:
        - "n\\s*>(.*)"
        - "nightly\\s*>(.*)"

This setup will keep playbot and playbot-mini on stable, and should not break most peoples workflow,
including private messages. It will, however, break tab-completion for playbot-mini, but that should be an acceptable tradeoff for the channel selection feature.

Yeah I'm a little worried with the playbot-mini tab completion, and we also have playbot connected to freenode right now, so this would unfortunately break that as well :(

I've searched through 230M of IRC logs (Mozilla only), and found 10676 invocations of playbot, and only 168 invocations of playbot-mini.
People will still be able to use playbot-mini with the same functionality, even with the same trigger if they wish, their clients just won't tab-complete the -mini anymore.
This isn't new, people have been typing "rusti: " on their own, without tab-completion.
Given the rather infrequent usage of playbot-mini, is this really a problem?

I'd like to keep playbot-mini for now, and there's also the issue of how we're currently connected to both mozilla IRC as well as freenode IRC.


Rename from knot Options

Is your feature request related to a problem? Please describe.
Ability to remove the mention of the word Knot.
Describe the solution you'd like
An environment variable for the name of the deployment.
Possibly more options for changing colours etc
Additional context
This could be useful for people who want to use Knot without it being called Knot for confusion reasons.

you forgot the main page links to the cal/spreadsheet. :(

done ;)


Add extra WMTS properties

This PR follows #430, which added basic support for WMTS overlays. The goal of this PR was to achieve parity with Cesium for Unreal, which boasts many more settings on the WMTS overlay.
Here's a screenshot of the new UI:

There are some differences from the Unreal one:

Instead of the useWebMercatorProjection or useGeographicProjection flag, I made it formal enum so that the intent was much clearer.
I've prefixed the "West", "South", etc. variables so they now read "Rectangle West", "Rectangle South", etc. I'm open to better names, but I thought it was better to be explicit in this way.

I'd like to update the Unreal UI to match Unity's, namely the enum change, but it's not an urgent change that has to make it into the next release.

@tal952 since you originally implemented #430, let me know if you disagree with any of the additions or changes I've made here!

Code and UI look great, and I tested it successfully with the "USGS Shaded Relief" WMTS in the "Imagery Layers Manipulation" CesiumJS Sandcastle example.


Allow egulias/email-validator 3

See https://github.com/egulias/EmailValidator/releases/tag/3.0.0 for changelog

There is a BC break (see https://github.com/symfony/symfony/pull/39685).

There is a BC break (see https://github.com/symfony/symfony/pull/39685).

There is a BC break (see symfony/symfony#39685).

Indeed.
If I understand correctly the discussion, you're waiting for some changes in egulias/email-validator to allow it, isn't it ?

There is a BC break (see symfony/symfony#39685).

Indeed.
If I understand correctly the discussion, you're waiting for some changes in egulias/email-validator to allow it, isn't it ?


[Hint] Support multi query SQL hint.

What would you like to be added:
Why is this needed:

Partial dependency feature: https://github.com/arana-db/arana/pull/402

ref #585

Yes, @marioooo0 and I  discussed HINT this morning and found that only a few HINT capabilities have been implemented.
And we need more HINT-related content later, but for now it may not be the focus of the current version 0.2.0 I think.
And we have a problem.
For arana's HINT, the sharding method is specified, but for mysql's own HINT, it seems that it has not been parsed, or PARSER has not yet supported it? Not sure, so leave a message below the issue.


Update single-sign-on-saml-protocol.md

updating this line to specifically state that Entra ID will honor the ACS URL if it is present in the SAML request
| AssertionConsumerServiceURL | Optional | If provided, this parameter must match the RedirectUri of the cloud service in Microsoft Entra ID. Entra ID will honor the ACS URL if it is present in the SAML Request.|

@OwenRichards1
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


579 Contradictions checking for violations

Description
Previously we could not guarantee the running of violations for larger profiles. This change checks for more contradictions relating to the root node to try and minimise the number of contradictions.
Changes

A change to the simplifier to check if an existing constraint already exists on the node
A change to the reducer to check for contradictions against the root node

Additional notes
There were no tests for the simplifier so this test class heavily needs to be expanded to cover more test scenarios. There are likely more test scenarios for the changes here that need to be thought about.
Issue
Resolves #579

Blocked until additional tests have been written around new code


Admin App Config Creator

It seems to be a better idea to have config creation in the admin app rather than the website. Shoudn't need to look great, so should be possible to make relatively quickly, maybe clear up amelia for other work.

I will also tack on some kind of selector for the currently active config here. Preferably also display it in the main view so client can see what questions they are putting out based on the config name.

Delayed indefinitely in favour of formatting the project for a production server.


Shizoweb beta

Thanks for your contribution 🥰.
The next step is to wait for review and approval to merge it to main repository
The community can help reacting with a thumb up (👍🏻) for approval and rocket (🚀) for who has tested it.
To test this PR you can run the following command below:
# NPM
npm install @shizodevs/shizoweb@shizo-devs/shizoweb#shizoweb-beta
# YARN v2
yarn add @shizodevs/shizoweb@shizo-devs/shizoweb#shizoweb-beta

Regards & Loves from
shizoweb 🤭


MacOS No More Lenses

Just so I am clear...
There is now no longer a fix to have lenses in Snapcam on Mac OS.  The app itself is working fine but the lenses are no longer populating.
thank you

Correction.... go it to work!!


JOSS review thread

Hello! I'm reviewing this package/paper for JOSS (https://github.com/openjournals/joss-reviews/issues/7477), and following their recommendation, I'll leave comments and suggestions as comments here.

Super minor thing (and I can't find the LaTeX file that generates the paper in this repo—it likely lives elsewhere): Figures 1 and 2 in the paper aren't vector based. This is fine for Figure 1 since it uses a high enough resolution that it looks okay, but Figure 2 appears quite pixelated (almost unreadable) when printed. Including SVGs or PDFs in the paper manuscript (or higher resolution PNGs) would be helpful.

Everything installed just fine for me both via pip and through poetry—it was my first time using poetry and it was really neat that it automatically created a virtualenv and installed everything
I did get an error initially, since my system python is 3.13, and the project settings look for less than 3.13:
https://github.com/mggg/VoteKit/blob/1d739fef11699bcd8821c4d08a5958637b8d9eca/pyproject.toml#L9
…but poetry ended up automatically installing a 3.9 virtualenv for me. Perhaps allowing 3.13 could be helpful

The current repo uses Sphinx to build https://votekit.readthedocs.io/en/latest/, which seems to be the actual documentation. It uses the comprehensive ipynbs in https://github.com/mggg/VoteKit/tree/main/notebooks to provide a helpful tutorial, and for my part, running those notebooks interactively on my own was the best way for me to get familiar with the package and its functionality and output. These are great and should be kept as the main documentation tutorial.
There's a link to an older, less-organized and less-polished version of the documentation (https://mggg.github.io/VoteKit/) that I accidentally used as my initial entry to the documentation and it took a while to figure out why it didn't match what was in the current repo:
https://github.com/mggg/VoteKit/blob/1d739fef11699bcd8821c4d08a5958637b8d9eca/README.md?plain=1#L22

JOSS recommends having clear contributor guidelines:

Community guidelines: Are there clear guidelines for third parties wishing to 1. Contribute to the software 2. Report issues or problems with the software 3. Seek support

The project currently has a code of conduct, and the README states that "bug reports and feature requests, as well as contributions, are welcome", but it doesn't provide guidelines for how to do that (like issue templates, recommendations for contributors, style preferences, etc.)
It might be helpful to include a CONTRIBUTING.md file—see https://github.com/jessesquires/.github/blob/main/CONTRIBUTING.md for a good generic one that I've adapted from several times, or this shorter R-specific one, for examples.

Thank you for the super detailed feedback! We really appreciate it.


establish Technical Steering Committee

Please comment on this issue if you're interested in becoming a member of the TSC. Being a member involves attending the TSC meetings (which I believe would be fortnightly), where we will discuss project development.
Please respond with:

Your email address
The employer you represent, if any.

I can then include you in further correspondence as we get the TSC up and going.
For more info, see https://tac.aswf.io/process/tsc_faq.html
Thx,
A

<EMAIL_ADDRESS>.

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>

<EMAIL_ADDRESS>Platige Image S.A.
We're using Rez since the dawn of time.

<EMAIL_ADDRESS>Code CG

<EMAIL_ADDRESS>Walt Disney Imagineering

<EMAIL_ADDRESS>Pixomondo

<EMAIL_ADDRESS>DreamWorks

<EMAIL_ADDRESS>DreamWorks

<EMAIL_ADDRESS>Company 3 / Method

Hello all,
Let's get the ball rolling on this. I've moved to a discussion, please take part: https://github.com/AcademySoftwareFoundation/rez/discussions/1353

Closing since the TSC has been formed 6 months ago.


Discriminator mapping didn't work with component reference

https://github.com/kota65535/openapi-merger/commit/ac29f1501e0242a7d0a8a9eafc79824e7de9e08b
Please check this commit I made to demo the issue.
In test/petstore_15/Pet.yaml, discriminator mapping works fine:
discriminator:
  propertyName: type
  mapping:
    cat: Cat.yaml
    dog: Dog.yaml

But in test/petstore_16/Pet.yaml:
discriminator:
  propertyName: type
  mapping:
    cat: '#/components/schemas/Cat'
    dog: '#/components/schemas/Dog'

It throws this expection:
     TypeError: Cannot read properties of undefined (reading 'value')
      at /Users/joshua/Projects/openapi-merger/src/util.js:2:796
      at Array.every (<anonymous>)
      at sliceObject (/Users/joshua/Projects/openapi-merger/src/util.js:2:652)
      at ComponentManager.create (/Users/joshua/Projects/openapi-merger/src/components.js:2:1917)
      at ComponentManager.getOrCreate (/Users/joshua/Projects/openapi-merger/src/components.js:2:2423)
      at Merger.handleRef (/Users/joshua/Projects/openapi-merger/src/merger.js:14:381)
      at Merger.handleDiscriminator (/Users/joshua/Projects/openapi-merger/src/merger.js:22:994)
      at Merger.mergeRefs (/Users/joshua/Projects/openapi-merger/src/merger.js:13:1188)
      at async Merger.mergeRefs (/Users/joshua/Projects/openapi-merger/src/merger.js:13:1307)
      at async Merger.mergeRefs (/Users/joshua/Projects/openapi-merger/src/merger.js:13:1307)
      at async Merger.mergeRefs (/Users/joshua/Projects/openapi-merger/src/merger.js:13:1307)
      at async Merger.merge (/Users/joshua/Projects/openapi-merger/src/merger.js:13:103)
      at async main (/Users/joshua/Projects/openapi-merger/src/main.js:2:621)
      at async runMerger (test_merger.js:17:3)
      at async Context.<anonymous> (test_merger.js:99:5)

I was trying to debug this issue by myself, but turns out I have no idea how the merger work internally.
Hope the issue is clear enough, thanks for the library!

@tx-ba1666 Thank you for the contributing! I'm sorry my code is dirty and poor documentation.
I've released the fixed version, so please try it and let me know if there are any problems.


Support Qwen2-7b MLP in int4 and transpose_value_cache=True

Description
Support Qwen2-7b MLP in int4 and transpose_value_cache=True
Test: https://github.com/intel-analytics/ipex-llm-workflow/actions/runs/10623417029
Perf: https://github.com/analytics-zoo/nano/issues/1576#issuecomment-2319077118

Fixed conflict and merge it first.


Endless cycle of "Enter server credentials" ♾

Repro steps:

Expand a new postgres db
Enter correct credentials

Make an error happen (I turned my wifi off)

Enter correct credentials

The cycle continues

The point is not the error itself. The point is my credentials are correct so you should not prompt me to enter them again. This is a case where you should be checking parseError(error).errorType and only telling me to enter credentials for errors we're pretty sure are related to credentials.

Fixed in https://github.com/microsoft/vscode-cosmosdb/pull/1397


Modify to work with official Eigen

@runenordmo can you help reviewing this?

Ready for the next round. I haven't resolved all the comments.

Why can't I add Rune as a reviewer?

I've added him to the organisation now, so you can add him.

Ready for the next round.

Looks good to me too 👍

I've changed the commit message. Is it too long?
Ready for the next round.

I think it's very good! It tells me exactly what I need to know when I come back in two months and don't remember why this change was made.
The only thing I would change is adding a short header, and wrap it properly. Your editor can probably be set up to do this automatically.
How to Write a Git Commit Message is a great introduction to good commit messages, and there's also some info in the internal "Development Workflow" wiki.
Here's my suggestion:

Avoid depending on unreleased Eigen in Downsample
Modify the sample to make it compatible with the latest stable Eigen
release (3.3.7) instead of the latest unstable source code from the
development branch (3.3.90)

Done. Thanks.

I've just modified the Readme. Please review.

LGTM! :)


feat/timepicker

Initial PR for this issue https://github.com/probablykasper/date-picker-svelte/issues/4

I am still not sure how the keyboard input should work here. Seeking advice regarding this.

First of all thanks for reviewing @probablykasper  . Here are few questions I have,

What happens when you press 'Enter' while on an hour field. Does it go to minutes ?
And when it's on minutes should the next 'Enter' key close the calender ?
Should it blur(as in unfocus) the input field ?
Do you want the caret there ? If so, do you want any specific color ?

The whole field (for example the hour field) should always be selected, like this:
Ahh, could you please tell me if the selected hour should have a  specific styles to it?

As for lint issues, I will  look into it but any idea why this error is coming up ?
RangeError: Error while loading rule 'svelte/no-unused-svelte-ignore': Index out of range (requested index 16922, but source text has length 16878).

What happens when you press 'Enter' while on an hour field. Does it go to minutes ?
And when it's on minutes should the next 'Enter' key close the calender ?
Should it blur(as in unfocus) the input field ?

I prefer keeping the existing Enter handling, where Enter closes the popup (kinda like saving the value). So you can avoid doing any Enter handling

Do you want the caret there ? If so, do you want any specific color ?

No need for them, assuming you mean the up/down buttons

Ahh, could you please tell me if the selected hour should have a  specific styles to it?

I'd say just try making it fit in, I can do adjustments later on if needed

As for lint issues, I will look into it but any idea why this error is coming up ? RangeError: Error while loading rule 'svelte/no-unused-svelte-ignore': Index out of range (requested index 16922, but source text has length 16878).

Gotta be some weird eslint-plugin-svelte bug. It seems to be because of this unused CSS, pushed a fix

@probablykasper @nihanmubashshir any updates? would love to see this

Not sure, feel free to pick it up and finish it. I suspect there's not too much left

@probablykasper @nihanmubashshir any updates? would love to see this

Yah, sorry guys, had got stuck with something for the past 2 weeks,
I will wrap this up by tomorrow EOD...
Sorry again.

All good, take your time :)

No worries, thanks for implementing this!

👀

@Creative-Difficulty
Just going to clean up a few things and get it to pass the tests.. :)

@probablykasper
I believe I am done mostly,
there is an error coming from a function that was added a month ago, I am not sure if you want me to fix that.
Also, I don't know how you would want to organize type files, so for now, I have just added the full definition of timePrecision in different places.
Waiting for your review. Thanks

I noticed quite a few bugs and ended up rewriting most of it.

there is an error coming from a function that was added a month ago, I am not sure if you want me to fix that.

There were changes to the custom on:select event which you had merged in from master, but then later you reverted some of it in https://github.com/probablykasper/date-picker-svelte/pull/69/commits/8c651cb8c12970a0e45a3d54aecab9f18ede1c8e. That's the error you're talking about, right?

I noticed quite a few bugs and ended up rewriting most of it.

Hey, I have noticed that, I am sure I have made mistakes but can you give me a hint about one of those bugs?

I shouldn't have said bugs sorry, it's mostly missing behavior I added:

Fixed inputs not showing/hiding reactively when timePrecision is updated
Fix Shift+Tab
Added: Typing 80 results in 08 because the 0 is invalid
The up/down caret buttons were still visible and causing issues with the input widths
Making ↑↓ loop around
Make width dynamic by switching to contenteditable <span> elements
Accept more inputTypes using on:input instead of keydown
Design update

@probablykasper
Makes sense, sorry you had to rewrite this :cry: .
The new implementation is much cleaner. Thanks for dealing with me.
Take care

It's no problem, thank you for taking the time on it!

Released in v2.9.0

Thanks for letting me know..

I feel bad that you had to rewrite most of it but just to let you know this was a great experience. And this is my first time contributing to open source. Reading your code :) Thanks again!!!
@probablykasper

Ah that's awesome! Don't worry I enjoyed it, it's more fun to rewrite than to review anyway. I'm pretty picky about subtle things


[core] Bump React to 19

Part of https://github.com/mui/material-ui/issues/42381
This PR serves as a sandbox to check how many issues we have left to solve to support React 19.

@aarongarciah, we're working on the Emotion type fixes alongside the Emotion maintainers: https://github.com/emotion-js/emotion/pull/3206
The next issue I'm facing is with the following packages:

styled-components used in the @mui/styled-engine-sc package, used for integrating with styled-components
next@13 used in the @mui/material-nextjs package.

Neither of these are up to date, and I don't think it's worth it for us to to try and update them like we did with Emotion:

The styled-components package is outdated (@types/react: 17) and not very active, there's a two year old React 18 issue with no response 😅: https://github.com/styled-components/styled-components/issues/3738
Version 13 of next is their previous major and I don't think updating would be a priority. Also, @mui/material-nextjs already supports next@14

So I think we should deprecate @mui/styled-engine-sc as well as the next@13 version of @mui/material-nextjs (keeping next@14 support). What do you think about this approach? The only problem I'm having is that I don't know how to freeze the React 18 for these deprecated packages as we cannot remove React 19 from the resolutions.

Hey @Janpot, I need your help with this. Could you check the branch and see if you can figure it out?
We have two packages which are not compatible with React 19 types:

styled-components, dependency of @mui/styled-engine-sc
next@13, dependency of @mui/material-nextjs

Important note: Focus only on the styled-components/@mui/styled-engine-sc and next@13/@mui/material-nextjs packages. If you run typescript on the root, you'll see many emotion type errors. Those are being worked on separately on https://github.com/emotion-js/emotion/pull/3206.
Here are the errors I'm getting:
styled-components
(error reference)
../../node_modules/.pnpm/styled-components@6.1.11_react-dom@19.0.0-rc-100dfd7dab-20240701_react@19.0.0-rc-100dfd7dab-2_wix7kfhaaslmbrv34cmdpqmtmy/node_modules/styled-components/dist/types.d.ts(133,189): error TS2503: Cannot find namespace 'JSX'.

For this one, I would like to pin the @types/react version in @mui/styled-engine-sc, but I'm not able to achieve it. The things I tried are

Use resolutions in @mui/styled-engine-sc package.json. Doesn't work: resolutions` is for the root package only
Add specific package resolution as such: "@mui/styled-engine-sc>@types/react": "18.3.3",
 "@mui/styled-engine-sc>@types/react-dom": "18.3.0",

but it doesn't seem to work either.

next@13
(error reference)
../../node_modules/.pnpm/next@13.5.1_@babel+core@7.24.7_babel-plugin-macros@3.1.0_react-dom@19.0.0-rc-100dfd7dab-20240_eyrhw4xacy4nwuqjvaiwg3fsum/node_modules/next/dist/shared/lib/utils.d.ts(158,59): error TS2503: Cannot find namespace 'JSX'.

For this one, I think we should deprecate the next@13 version of the package and turn off the typescript check, unless you have any suggestions on how to keep it working. I don't 😅.

Also, I would expect this line to exclude the ../../node_modules/... from the typescript check, but it seems it doesn't 🤔

Going to sleep now, so can't help much, but got some points that might help you:

Also, I would expect this line to exclude the ../../node_modules/... from the typescript check, but it seems it doesn't 🤔

probably skipLibCheck: true on tsconfig can help here.

Use resolutions in @mui/styled-engine-sc package.json. Doesn't work: resolutions` is for the root package only

Resolutions is for yarn only, but we use pnpm, so you are probably looking at the wrong prop, you can use this instead
  "pnpm": {
    "overrides": {
      "@types/react": "18.3.3",
      "@types/react-dom": "18.3.0"
    }
  },

@JCQuintas resolutions gets merged with pnpm.overrides, and since we only use resolutions, it works.

Functionally identical to pnpm.overrides, this field is intended to make it easier to migrate from Yarn.
resolutions and pnpm.overrides get merged before package resolution (with pnpm.overrides taking precedence), which can be useful when you're migrating from Yarn and need to tweak a few packages just for pnpm.

Source: https://pnpm.io/package_json#resolutions

probably skipLibCheck: true on tsconfig can help here.

Yes, skipLibCheck: true removes the warnings. I'm unsure if we want to use it (@mui/code-infra?). If there's a way for us to skip only these two stale library dependencies checks, that would be better than disabling it altogether.

probably skipLibCheck: true on tsconfig can help here.

Yes, skipLibCheck: true removes the warnings. I'm unsure if we want to use it (@mui/code-infra?). If there's a way for us to skip only these two stale library dependencies checks, that would be better than disabling it altogether. Feels like "throwing the baby out with the bath water".

As far as I know there is no other way around this right now, since you can't select which libs to skip in typescript.
Since we are already doing the "resolutions" change, that is a "trust me" moment. Sure the lib check might help catching so issues, but if the types are different, then you will definitely get an error with the only opt out I know being skipLibCheck: true.
ref:
https://github.com/microsoft/TypeScript/issues/30511

The things I tried are

I'll try to take a look at this over the week, but what I can already say about resolutions is that I don't think of it as a tool we can use to solve this problem. As far as I'm aware, as a package author, you can't enforce how your transitive dependencies are resolved by the consumers of your package. So we'd fix the problem in our repo, but our users would still have it.

Thanks for taking a look @Janpot

I don't think of [resolutions] as a tool we can use to solve this problem

With this, do you mean that we shouldn't have @types/react and @types/react-dom in the resolutions? Or that we cannot use them for the styled-components issue in particular?

I tried the patch approach but I still get the same errors 😓
I think the issue here is that I'm not able to figure out how to make the pnpm workspace like this:

Use the React 19 types for most packages
Use React 18 types for mui-styled-engine-sc, or if not possible, do not test these types at all. We can deprecate this package or have a warning that it doesn't work with React 19, as I don't see them supporting react 19 anytime soon
Use React 18 types for next@13 inside the mui-material-nextjs package, or if not possible, do not test these types at all. We can deprecate can deprecate the next@13 version of mui-material-nextjsor have a warning that it doesn't work with React 19.

Do you see a way of making it work like that?

deprecate @mui/styled-engine-sc as well as the next@13 version of @mui/material-nextjs

This feels a bit too bold. I could see a lot of people using styled-components and not care about types, as well as upgrading Material UI to v6 without upgrading React or Next.js. If we can ignore the types for those packages, I think it would be good enough.

With this, do you mean that we shouldn't have @types/react and @types/react-dom in the resolutions?

Correct, in fact we shouldn't have resolutions at all, resolutions are a bad idea, especially for library authors like us. Basically packages declare which dependency range they are compatible with, and the resolutions field instructs package managers to ignore that and supply another version that may or may not be compatible. Moreover, this only happens inside of our repo, our users would get the transitive dependency installed the same way as if resolutions didn't exist. If pnpm dedupe doesn't dedupe it, something needs to be fixed at the dependency level.
@emotion/... related type problems: I'm assuming the, to be covered by https://github.com/emotion-js/emotion/pull/3206. What I'm further changing in this PR:

[x] Remove resolutions for @types/react. add a specific one that points @types/react inside of types-react-dom to<EMAIL_ADDRESS>To be removed after @types/react@19 is released.
[x] Add a resolution for @types/react in @types/hoist-non-react-statics. The latter has  dependency of @types/react: * so this should be fine, to be removed after @types/react@19 is released.
[x] patch styled-components to remove deprecated namespace. This patch needs to be applied to styled-components and published.

[ ] @mui/material-nextjs
[ ] docs

I pushed a commit to use the latest React 19 rc.

Tests run after rebasing to get the latest Emotion version and re-applying the patch to the latest styled-components version. 72 tests are failing though. I'll be looking at those.

Building the @mui/material-nextjs package results in this error:

cc @Janpot in case you have an idea of what's going on with the @mui/material-nextjs error

I reverted its next dependency to an earlier canary version. Looks like their latest canary has an inconsistency in the typings of its vendored webpack. The exact version doesn't matter that to us, as long as it supports React 19 types. We can install stable when it becomes available

Thanks @Janpot!
The pigment build fails should be solved with the next pigment release, PR is already merged: https://github.com/mui/pigment-css/pull/183

I found the actual root cause while investigating the failing build for https://github.com/mui/material-ui/pull/42998
Next.js internally depends on types accessed through next/... specifier. It actually has two declaration files for these webpack types. One that gets resolved from being adjacent to the javascript file, and one that is usually being pulled in your project by the next-env.d.ts file that its cli creates and which is referenced in the docs tsconfig. This is why it works fine in the docs, but in @mui/material-nextjs these extra types aren't referenced anywhere. By simply adding next to the types array these types come in the mix and next.js can resolve these extra declaration files which augment some of the webpack interfaces with extra properties. Their vendored in packages don't seem to work well when next is used just as a dependency.

Type checks are passing 🎉
The next step is fixing the unit and browser tests 🙌🏼 we're on it

Would it make sense to try to make this PR as light as possible? Maybe by moving whatever we can into HEAD so we could: 1. assert it works with React 18 too. 2. avoid PR conflicts.

@oliviertassinari yes, the idea is to move everything that doesn't require React 19 to separate PRs.

Still some more tests to fix (~55) related to:

Components accessing element.ref (we should move the getChildRef from @mui/material to a common package (@mui/utils ?))
Expected prop type errors that don't run because React 19 obviates prop types
"A component is changing the default value state of an uncontrolled"
Unexpected console.error calls

End of the week update on the tests fixes:

The element.ref test fixes were cherry-picked and merged to next in https://github.com/mui/material-ui/pull/43132. After that, next was merged into this branch, so those changes are no longer in this PR.
The majority of test-related fixes were cherry-picked to https://github.com/mui/material-ui/pull/43155. When that PR is merged, we need to merge next into this branch.
There's a fix related to autocomplete, which is solved in https://github.com/mui/material-ui/pull/42824/commits/cf9ba29cce8fc196445302dc21742bcf9960bb4c that needs to be cherry-picked.
Besides that, only 2 more tests need to be investigated and fixed (the Modal one and the media query one). The envinfo test that's failing is due to our setup to use the @types/react 19 packages.

 Did you look into those? I'll take a look if you haven't already.

@atomiks have you ever seen this error? https://github.com/mui/material-ui/actions/runs/10453616285/job/28944438856?pr=42824#step:7:443
Error: ../../node_modules/.pnpm/@floating-ui+react-dom@2.1.1_react-dom@19.0.0-rc-1eaccd82-20240816_react@19.0.0-rc-1eaccd82-2_aajkvhk4b2wxtvqterrfscyrh4/node_modules/@floating-ui/react-dom/dist/floating-ui.react-dom.d.ts(26,10): error TS2724: '"@floating-ui/dom"' has no exported member named 'LimitShiftOptions'. Did you mean 'ShiftOptions'?

It started to fail in this branch since I rebased on top of next after https://github.com/mui/material-ui/pull/43249 was merged in next. I haven't found any report in the floating-ui repo or anywhere else 🤔

Five website e2e tests are failing:

Using Next 15 (v15.0.0-canary.121 at the time of writing) in the docs makes the error go away. The experimental.workerThreads Next.js config needs to be set to false, otherwise the build fails with this error caused by a non-serializable message being sent to a worker:

@atomiks have you ever seen this error?
Error: ../../node_modules/.pnpm/@floating-ui+react-dom@2.1.1_react-dom@19.0.0-rc-1eaccd82-20240816_react@19.0.0-rc-1eaccd82-2_aajkvhk4b2wxtvqterrfscyrh4/node_modules/@floating-ui/react-dom/dist/floating-ui.react-dom.d.ts(26,10): error TS2724: '"@floating-ui/dom"' has no exported member named 'LimitShiftOptions'. Did you mean 'ShiftOptions'?

This has been solved by updating @floating-ui transitive deps: https://floating-ui.com/docs/misc#keeping-floating-ui-up-to-date

@DiegoAndai after updating to Next.js 15 (latest canary at the time of writing) and adapting the envinfo test to pass, everything is green.

@aarongarciah, that's great! About Argos, the dashboard one seems to be flaky, and the other one, as you suggest, might be related to speed load, but let's review it in more detail.

Not sure what's going on with this one, maybe is loading faster now? https://app.argos-ci.com/mui/material-ui/builds/31461/106147470

It looks wasteful to take a screenshot on a codesandbox iframe. How about we do what MUI X does?
diff --git a/docs/data/material/customization/shadow-dom/shadow-dom.md b/docs/data/material/customization/shadow-dom/shadow-dom.md
index fef01d7d69..ba4c564ee6 100644
--- a/docs/data/material/customization/shadow-dom/shadow-dom.md
+++ b/docs/data/material/customization/shadow-dom/shadow-dom.md
@@ -68,4 +68,4 @@ const theme = createTheme({

 In the example below you can see that the component outside of the shadow DOM is affected by global styles, while the component inside of the shadow DOM is not:

-{{"demo": "ShadowDOMDemo.js", "hideToolbar": true, "bg": true}}
+{{"demo": "ShadowDOMDemoNoSnap.js", "hideToolbar": true, "bg": true}}
diff --git a/test/regressions/index.js b/test/regressions/index.js
index 62a1fcdefe..314dc2e42c 100644
--- a/test/regressions/index.js
+++ b/test/regressions/index.js
@@ -33,6 +33,7 @@ importRegressionFixtures.keys().forEach((path) => {
 }, []);

 const blacklist = [
+  /^docs-(.*)(?<=NoSnap)\.png$/, // Excludes demos that we don't want
   // Blog template components and theme customizations
   'docs-getting-started-templates-blog/Blog.png',
   'docs-getting-started-templates-blog/TemplateFrame.png',

@oliviertassinari, PR created https://github.com/mui/material-ui/pull/43500

@DiegoAndai getReactElementRef was failing with React 19 types. I extracted https://github.com/mui/material-ui/pull/42824/commits/008547012073b14223b3168332116441d15166b1 to a separate PR https://github.com/mui/material-ui/pull/44034.
I'll have a look at this type errors: https://app.circleci.com/pipelines/github/mui/material-ui/140604/workflows/447f7cd0-c11d-4220-a27d-822a76ec6576/jobs/757885?invite=true#step-108-1810_45

Also extracted https://github.com/mui/material-ui/pull/42824/commits/c2f4ab48cd2399efe89b690270905b386bef1952 to https://github.com/mui/material-ui/pull/44035 to make createGrid compatible with React 19 types.

There are two type errors missing:

Cannot find namespace 'JSX' (see full error)
Comes from styled-components. Although @Janpot converted all of the JSX namespace references to React.JSX, styled-components uses @types/react@17 and the generated withTheme.d.ts file contains a JSX.LibraryManagedAttributes reference because of that. I generated the styled-components build locally using<EMAIL_ADDRESS>instead of @types/react@17 and the styled-components generated code was correct.
To solve it, we can apply a patch or open a PR on styled-components to add an explicit return type to the withTheme function (source code).
Wrong ref prop type passed to a Timeline internal component (see full error)
This started to happen after this change: https://github.com/mui/material-ui/pull/43555/files#diff-d1766035a961cf751130cde4ec63430a2a653f893a1ba43c5e81a411b3698e54L65 cc @DiegoAndai in case you're aware of an obvious fix I missed.

I just added a patch for styled-components types https://github.com/mui/material-ui/pull/42824/commits/ea0d9e7fe5a4a5d139825a3cda1f2399e6451c4d

There are two type errors missing:

Cannot find namespace 'JSX' (see full error)
Comes from styled-components. Although @Janpot converted all of the JSX namespace references to React.JSX, styled-components uses @types/react@17 and the generated withTheme.d.ts file contains a JSX.LibraryManagedAttributes reference because of that. I generated the styled-components build locally using<EMAIL_ADDRESS>instead of @types/react@17 and the styled-components generated code was correct.
To solve it, we can apply a patch or open a PR on styled-components to add an explicit return type to the withTheme function (source code).
Wrong ref prop type passed to a Timeline internal component (see full error)
This started to happen after this change: https://github.com/mui/material-ui/pull/43555/files#diff-d1766035a961cf751130cde4ec63430a2a653f893a1ba43c5e81a411b3698e54L65 cc @DiegoAndai in case you're aware of an obvious fix I missed.

Will you also open a PR with styled-components?

That's the idea, although I haven't looked into how to solve the issue on styled-component's side. I'll open an issue nevertheless.

https://github.com/mui/material-ui/pull/42824/commits/941e213cc9f250dc9c46f243aeb9cbb013a705d5 fixes the ref type error in the Timeline component. I extracted it to a separate PR: https://github.com/mui/material-ui/pull/44043

I opened an issue in the styled-components repo regarding the JSX deprecated namespace being used in the generated withTheme.d.ts file: https://github.com/styled-components/styled-components/issues/4359
I'll try to open a PR with a potential fix.

The patch is good to unblock this PR, but we can't merge it to master.

@Janpot what if React 19 releases before styled-components fixes the issue? Would you be against using the patch in that situation as well?

I wonder why.

Because end-users wouldn't get this patch, so they'd still see the typing errors. But yeah, we can probably relax as this is only a dependency of @mui/styled-engine-sc, let's not go overboard on this then and tell users to use skipLibCheck.

btw, for us I would do the same, instead of the patch, enable skipLibCheck on @mui/styled-engine-sc.

@Janpot should I enable skipLibCheck on @mui/styled-engine-sc and remove the patch?

If that works. The advantage would be that we isolate the hack a bit more to @mui/styled-engine-sc. If it doesn't work I wouldn't waste too much time on it for now.

Given the amount of dependency changes, medium sized containers receive the "killed" signal on CI. I temporarily changed the test_checkout to medium+ and it succeeded. With that, we can also run test_browser and test_types which already use medium+, and both are succeeding. I'll be using those for the moment.
When the time comes to merge this, we can change all test containers to medium+, and then change it back in a follow up PR. I don't know if there's an easier way to achieve this cc: @mui/code-infra, please let me know if there is.

Moved to https://github.com/mui/material-ui/pull/44672


cr: merge new, truncated files

A future commit will immediately truncate every newly-created file, in
order to mark it dirty.  To avoid unnecessary conflicts, we should
treat the same file name that's only been truncated as mergeable
everywhere in the CR code, not just during action computation.
Issue: KBFS-2076

I filed https://keybase.atlassian.net/browse/KBFS-2145 for the previous test run failure., I'm pretty sure it's a random, unrelated flake.


Correct typo in Development-Contributing.md.

Correct typo in Development-Contributing.md.

Thanks for fixing that :)


Add len function to session::SessionState

This is useful for tracking the number of in-flight requests.

This change is

Coverage remained the same at 94.068% when pulling d16ae45f451998aa51967763c18d9c1f8a93cbf7 on jwilm:add-sessionstate-len into f89bf426f871776b4cec024d02d6d2e84d479396 on mlalic:master.

Thanks


Add satisfy in AbstractIterableAssert

Check List:

Fixes #1621
Unit tests : YES
Javadoc with a code example (on API only) : NO

This PR is for iterables.satisfy. If this one is completely finished, I'll finish iterables.satisfyExactly, iterables.satisfyExactlyInAnyOrder, and then arrays. part.

I have completed my code, please review them at your convenience. @joel-costigliola

Thanks for your great effort!

Labeled as "not ready" as the assertion name is not clear enough and can lead to different behaviour interpretation.

I think we close this as satisfyExactly and satisfyExactlyInAnyOrder have been added

I think we close this as satisfyExactly and satisfyExactlyInAnyOrder have been added


Template release 0.6.0

Features to include:

[x] TF 0.13 support
[x] Healthcare features (FHIR stream config, HL7V2 parser config)
[x] Activate Identity API
[x] Automatic Group and membership management
[x] Multi env CICD with CSR
[x] Resource only deployment
[x] Upgrade to Project Factory module 10.0.0

Binary release 0.5.0 is also required to work with template 0.6.0

Project Factory module 10.0.0 will only work with TF >= 0.13

Will do some more testing

Template release https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite/releases/tag/templates-v0.6.0

Template release https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite/releases/tag/templates-v0.6.0

Binary release https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite/releases/tag/v0.5.0

Binary release https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite/releases/tag/v0.5.0


expose base and possibly other parts

I have a case when I need to know what base user selected. I know that internally there is a variable for that, but maybe we could expose this info to the outside?
While we are at it, perhaps it would be a good idea to also expose other potentially useful stuff.
What do you think about it?

If we come to an agreement about api for this, I could start working on a PR.
Let me know.

What other ideas do you have for what to expose and what ideas do you have for implementation?
I'd love to hear them.

perhaps the whole myFrequency object could be exposed since there might be a need to find out which value for a given input was selected.
As for the implementation, it is already on the scope. One would only have to add two-way binding property to the scope of the directive and call it done.

I will get this into the next push, hoping to  be caught up by Sunday.  Thanks!

@DmitryEfimenko are you still willing to make a PR for this?

@DmitryEfimenko awesome thanks, can you do me a favor and not commit the dist folder, I will build it and release new versions to bower and npm once I merge the source.
Thanks!


Add sandbox of ding dong bot to the examples basic section

Have added the Ding Dong bot CodeSandbox to the Examples - Basic section. Will be adding more information to this page as per the structure suggested here: #796

The Examples: Overview page will need an update as it is redundant to have the CodeSandbox of the bots in two pages. Will update it in a separate PR.

Thank you for the improvements!


your documentation is terrible

can you please fix it?

@harrythedev negative comments are not helpful. #107 is one PR that's attempting to improve the documentation.
If you'd like to make a PR, that'd be great! If you can make a request politely by filing an issue, great! Otherwise, please keep your comments to yourself.


chore: update mirror node explorer from 23.11.0 to 24.3.0

Description:
Update the mirror node explorer version from 23.11.0 to 24.3.0
Related issue(s):
Fixes #557
Notes for reviewer:
Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 51.02%. Comparing base (1822d4e) to head (6c98471).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #561   +/-   ##
=======================================
  Coverage   51.02%   51.02%
=======================================
  Files          24       24
  Lines        1172     1172
  Branches      131      131
=======================================
  Hits          598      598
  Misses        550      550
  Partials       24       24

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


[Bug]: FATAL: password authentication failed for user "testdb". I have tried so many things but i cant connect to my postgres (using pgadmin4)

Is there an existing issue already for this bug?

[x] I have searched for an existing issue, and could not find anything. I believe this is a new bug.

I have read the troubleshooting guide

[x] I have read the troubleshooting guide and I think this is a new bug.

I am running a supported version of CloudNativePG

[x] I have read the troubleshooting guide and I think this is a new bug.

Contact Details
<EMAIL_ADDRESS>Version
1.24.0
What version of Kubernetes are you using?
1.31
What is your Kubernetes environment?
Self-managed: kind (evaluation)
How did you install the operator?
YAML manifest
What happened?
I cannot login into my postgres using pgadmin4. Here is my yaml file:
apiVersion: v1
kind: Secret
type: kubernetes.io/basic-auth
data:
  username: dGVzdGRi
  password: dGVzdGRi
metadata:
  name: app-secret

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pg-block-storage
  namespace: db
provisioner: dobs.csi.digitalocean.com
parameters:
  fsType: ext4
reclaimPolicy: Retain
volumeBindingMode: Immediate
allowVolumeExpansion: true

---
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: pg
  namespace: db
spec:
  instances: 3
  imageName: ghcr.io/cloudnative-pg/postgis:14

  bootstrap:
    initdb:
      database: mydb
      owner: testdb
      secret:
        name: app-secret
      postInitTemplateSQL:
        - CREATE EXTENSION postgis;
        - CREATE EXTENSION postgis_topology;
        - CREATE EXTENSION fuzzystrmatch;
        - CREATE EXTENSION postgis_tiger_geocoder;

  storage:
    size: 1Gi
  walStorage:
    size: 1Gi
  postgresql:
    parameters:
      shared_buffers: 256MB
      work_mem: 64MB
      max_connections: "200"
    pg_hba:
      - hostssl all all <IP_ADDRESS>/0 scram-sha-256

  startDelay: 30 # Delay before starting the database instance
  stopDelay: 100 # Delay before stopping the database instance
  primaryUpdateStrategy: unsupervised # Strategy for handling primary updates

  backup:
    retentionPolicy: "30d" # Backup retention policy
    barmanObjectStore:
      destinationPath: "s3://plot-bucket/backup/" # Backup destination in S3
      endpointURL: "https://plot-bucket.ams3.digitaloceanspaces.com" # S3 endpoint URL
      s3Credentials: # Credentials for accessing S3
        accessKeyId:
          name: s3-creds # Secret name containing access key
          key: ACCESS_KEY_ID # Key for access key ID
        secretAccessKey:
          name: s3-creds # Secret name containing secret key
          key: ACCESS_SECRET_KEY # Key for secret access key

  monitoring:
    enablePodMonitor: true # Enable the PodMonitor for Prometheus
    tls:
      enabled: false # Set to true if TLS is enabled for metrics

---
apiVersion: postgresql.cnpg.io/v1
kind: Pooler
metadata:
  name: pgbouncer-rw
  namespace: db
spec:
  cluster:
    name: pg
  instances: 3
  type: rw
  pgbouncer:
    poolMode: session
    parameters:
      max_client_conn: "1000"
      default_pool_size: "50"

---
apiVersion: postgresql.cnpg.io/v1
kind: Pooler
metadata:
  name: pgbouncer-ro
  namespace: db
spec:
  cluster:
    name: pg
  instances: 5
  type: ro
  pgbouncer:
    poolMode: session
    parameters:
      max_client_conn: "1000"
      default_pool_size: "50"

Then, in order to connect in pgadmin4 to my postgres primary database i create a service like this in order to open a nodeport:
apiVersion: v1
kind: Service
metadata:
  name: pg-rw-nodeport
  namespace: db
spec:
  type: NodePort
  selector:
    role: primary
  ports:
    - name: pgadmin4
      port: 5432
      targetPort: 5432
      nodePort: 30001

Then get the node ip using "kubectl get nodes -o wide". i use port 30001 and testdb for everything else like shown in the image below.

Cluster resource
No response
Relevant log output
No response
Code of Conduct

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

after spending almost a day over this i found out i did not mention the namespace in the secret.. ! i added the namespace: db and now it works.
anyways, if someone could explain this part:
pg_hba:
  - hostssl all all <IP_ADDRESS>/0 scram-sha-256

i dont quiet understand what i should put here

You can find details about pg_hba.conf in the pg documentation. It's basically host-based authentication you can configure there. You probably don't have to change the default, so you could remove the given part from your config.
But in any case, if you don't have special requirements a swift look into the default config may be good to know what is set.

@ember11498 If this is resolved could you please close the issue?


This project is awesome, can i expect update?

Hoppscotch has add a bunch of features since last year.
I've create hoppscotch-backend-go. It's expect to be fully compatible with hoppscotch. It is open to collaboration and any contributions are welcome.
Can it be the successor of this project.

Hi! Afaik Hoppschotch now also has a self-hosted backend option, so I'm not quire sure what the advantage of such a project is? That is also the reason that this project has not been updated (+ Hoppschotch is/was lacking important functionality).


Docs/user documentation

Added a description of the fields, and a brief user guide to the README.md file.

Documentation for the end user should be in files in the docs/ directory. See https://docs.silverstripe.org/en/4/contributing/documentation/#editing-on-your-computer
The README.md at the top level should only have developer usage instructions.
Please move the documentation to the docs/ directory.

Also, in the README.md, before your documentation, in the JSON block, it says to require version "dev-master". Please change that to "^1".

Feedback from @sig-steve addressed.


Pass through unrecognised keys to input

This allows users to continue typing when they are focusing an option.

@edwardhorsford could I ask you to confirm if this is implemented correctly from a user's perspective? The input has the yellow border even when it's not the currently selected element, but no caret. Also, any key other than the recognised ones will set focus to the input, including modifier ones like cmd or option.

Theo points out with the current suggestion, using modifier keys will also move the focus, which may be weird. I'd like to try passing through just alpha-numeric keys (keycodes), and leaving all else. Would need to check that shift-k still passes through as "K" though...
Feels like it will need some good testing.

@edwardhorsford here's the list of accepted "printable characters" that the typeahead will forward: https://github.com/alphagov/accessible-typeahead/pull/47/files#diff-cd432b59e6c3f8e0579c8aad2b4eec7cR15
I have tested that this works how you would expect with modifier keys and I think it's good. 👍


How to disable/uninstall a plugin/mode? (eg. vim-go)

In README.md, we have Included Plugins and Included modes, but how to disable one of them?
For example, I want to disable vim-go mode in "Included modes".
I found https://github.com/amix/vimrc/issues/388 , but it isn't a general method. And there is someone complains that it doesn't work.

Not an elegant solution, but $ rm -r sources_non_forked/vim-go should always work :-)

I have already removed vim-go given how heavy it is 👍


saving model

hey i want to train on specific filter (dream or paint) and use it on different images without the need of training every time but i can't save model

Hey, this is the original neural style stransfer and not fast style transfer. So you don't train a model, but each image individually. If you want to train a model on a specific filter for arbitrary input images, take a look at some fast style transfer repos.

got it thanks
On Tue, Jun 21, 2022 at 9:03 AM Moritz Thüning @.***>
wrote:

Closed #4 https://github.com/moritztng/prism/issues/4 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/moritztng/prism/issues/4#event-6844657799, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXJYZDHPJN2U5ILDBNB5TD3VQFSMHANCNFSM5ZGTQMTA
.
You are receiving this because you authored the thread.Message ID:
@.***>


Implement Into<Response> for a number of types

Some simple convenience implementations should be added for types such as String and Vec<u8>, allowing a simple 200 OK response to be automatically generated using some_string.into() instead of Response::new(StatusCode::OK, some_string).

This is unnecessary and makes the code harder to read, so I'm closing this for now.


Commit error: Key not present in Dictionary: "t"

Description
I cannot find much information about what is causing this: I have an intermittent error pop up in the neogit status buffer. It shows up after writing my commit message and saving. I have to escape out of the status buffer and re-commit but not all of the time.
E716: Key not present in Dictionary: "t"
E116: Invalid arguments for function toupper

Does anybody have any ideas what could be going on here? Only different thing in my config is that I am committing using my signing GPG key via ssh-agent.
Neovim version
NVIM v0.9.2
Build type: RelWithDebInfo
LuaJIT 2.1.1692716794
Operating system and version
Linux fedora 6.5.11-300.fc39.x86_64
Steps to reproduce

Create commit
Write commit message in buffer.
:wq commit message buffer
Insert Yubikey to sign commit
Receive error and press ENTER to continue commit

Expected behavior
The error message should not display and should commit
Actual behavior
E716: Key not present in Dictionary: "t"
E116: Invalid arguments for function toupper
Minimal config
-- NOTE: See the end of this file if you are reporting an issue, etc. Ignore all the "scary" functions up top, those are
-- used for setup and other operations.
local M = {}

local base_root_path = vim.fn.fnamemodify(debug.getinfo(1, "S").source:sub(2), ":p:h") .. "/.min"
function M.root(path)
  return base_root_path .. "/" .. (path or "")
end

function M.load_plugin(plugin_name, plugin_url)
  local package_root = M.root("plugins/")
  local install_destination = package_root .. plugin_name
  vim.opt.runtimepath:append(install_destination)

  if not vim.loop.fs_stat(package_root) then
    vim.fn.mkdir(package_root, "p")
  end

  if not vim.loop.fs_stat(install_destination) then
    print(string.format("> Downloading plugin '%s' to '%s'", plugin_name, install_destination))
    vim.fn.system({
      "git",
      "clone",
      "--depth=1",
      plugin_url,
      install_destination,
    })
    if vim.v.shell_error > 0 then
      error(string.format("> Failed to clone plugin: '%s' in '%s'!", plugin_name, install_destination),
        vim.log.levels.ERROR)
    end
  end
end

---@alias PluginName string The plugin name, will be used as part of the git clone destination
---@alias PluginUrl string The git url at which a plugin is located, can be a path. See https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols for details
---@alias MinPlugins table<PluginName, PluginUrl>

---Do the initial setup. Downloads plugins, ensures the minimal init does not pollute the filesystem by keeping
---everything self contained to the CWD of the minimal init file. Run prior to running tests, reproducing issues, etc.
---@param plugins? table<PluginName, PluginUrl>
function M.setup(plugins)
  vim.opt.packpath = {}                      -- Empty the package path so we use only the plugins specified
  vim.opt.runtimepath:append(M.root(".min")) -- Ensure the runtime detects the root min dir

  -- Install required plugins
  if plugins ~= nil then
    for plugin_name, plugin_url in pairs(plugins) do
      M.load_plugin(plugin_name, plugin_url)
    end
  end

  vim.env.XDG_CONFIG_HOME = M.root("xdg/config")
  vim.env.XDG_DATA_HOME = M.root("xdg/data")
  vim.env.XDG_STATE_HOME = M.root("xdg/state")
  vim.env.XDG_CACHE_HOME = M.root("xdg/cache")

  -- NOTE: Cleanup the xdg cache on exit so new runs of the minimal init doesn't share any previous state, e.g. shada
  vim.api.nvim_create_autocmd("VimLeave", {
    callback = function()
      vim.fn.system({
        "rm",
        "-r",
        "-f",
        M.root("xdg")
      })
    end
  })
end

-- NOTE: If you have additional plugins you need to install to reproduce your issue, include them in the plugins
-- table within the setup call below.
M.setup({
  plenary = "https://github.com/nvim-lua/plenary.nvim.git",
  telescope = "https://github.com/nvim-telescope/telescope.nvim",
  diffview = "https://github.com/sindrets/diffview.nvim",
  neogit = "https://github.com/NeogitOrg/neogit"
})
-- WARN: Do all plugin setup, test runs, reproductions, etc. AFTER calling setup with a list of plugins!
-- Basically, do all that stuff AFTER this line.
require("neogit").setup({}) -- For instance, setup Neogit

local neogit = require('neogit')

neogit.setup {
  -- Hides the hints at the top of the status buffer
  disable_hint = false,
  -- Disables changing the buffer highlights based on where the cursor is.
  disable_context_highlighting = true,
  -- Disables signs for sections/items/hunks
  disable_signs = false,
  -- Do not ask to confirm the commit - just do it when the buffer is closed.
  disable_commit_confirmation = false,
  -- Uses `vim.notify` instead of the built-in notification system.
  disable_builtin_notifications = false,
  -- Changes what mode the Commit Editor starts in. `true` will leave nvim in normal mode, `false` will change nvim to insert mode, and `"auto"` will change nvim to insert mode IF the commit message is empty, otherwise leaving it in normal mode.
  -- When enabled, will watch the `.git/` directory for changes and refresh the status buffer in response to filesystem
  -- events.
  disable_insert_on_commit = true,
    filewatcher = {
    interval = 1000,
    enabled = true,
  },
  -- Used to generate URL's for branch popup action "pull request".
  git_services = {
    ["github.com"] = "https://github.com/${owner}/${repository}/compare/${branch_name}?expand=1",
    ["bitbucket.org"] = "https://bitbucket.org/${owner}/${repository}/pull-requests/new?source=${branch_name}&t=1",
    ["gitlab.com"] = "https://gitlab.com/${owner}/${repository}/merge_requests/new?merge_request[source_branch]=${branch_name}",
  },
  -- Allows a different telescope sorter. Defaults to 'fuzzy_with_index_bias'. The example below will use the native fzf
  -- sorter instead. By default, this function returns `nil`.
  telescope_sorter = function()
    return require("telescope").extensions.fzf.native_fzf_sorter()
  end,
  -- Persist the values of switches/options within and across sessions
  remember_settings = true,
  -- Scope persisted settings on a per-project basis
  use_per_project_settings = true,
  -- Table of settings to never persist. Uses format "Filetype--cli-value"
  ignored_settings = {
    "NeogitPushPopup--force-with-lease",
    "NeogitPushPopup--force",
    "NeogitPullPopup--rebase",
    "NeogitCommitPopup--allow-empty",
    "NeogitRevertPopup--no-edit",
  },
  -- Neogit refreshes its internal state after specific events, which can be expensive depending on the repository size.
  -- Disabling `auto_refresh` will make it so you have to manually refresh the status after you open it.
  auto_refresh = true,
  -- Value used for `--sort` option for `git branch` command
  -- By default, branches will be sorted by commit date descending
  -- Flag description: https://git-scm.com/docs/git-branch#Documentation/git-branch.txt---sortltkeygt
  -- Sorting keys: https://git-scm.com/docs/git-for-each-ref#_options
  sort_branches = "-committerdate",
  -- Change the default way of opening neogit
  kind = "tab",
  -- The time after which an output console is shown for slow running commands
  console_timeout = 2000,
  -- Automatically show console if a command takes more than console_timeout milliseconds
  auto_show_console = true,
  status = {
    recent_commit_count = 10,
    recent_commit_include_author_info = true,
  },
  commit_editor = {
    kind = "split",
  },
  commit_select_view = {
    kind = "tab",
  },
  commit_view = {
    kind = "vsplit",
  },
  log_view = {
    kind = "tab",
  },
  rebase_editor = {
    kind = "split",
  },
  reflog_view = {
    kind = "tab",
  },
  merge_editor = {
    kind = "split",
  },
  preview_buffer = {
    kind = "split",
  },
  popup = {
    kind = "split",
  },
  signs = {
    -- { CLOSED, OPENED }
    hunk = { "", "" },
    item = { "", "" },
    section = { "", "" },
  },
  -- Each Integration is auto-detected through plugin presence, however, it can be disabled by setting to `false`
  integrations = {
    -- If enabled, use telescope for menu selection rather than vim.ui.select.
    -- Allows multi-select and some things that vim.ui.select doesn't.
    telescope = nil,
    -- Neogit only provides inline diffs. If you want a more traditional way to look at diffs, you can use `diffview`.
    -- The diffview integration enables the diff popup.
    --
    -- Requires you to have `sindrets/diffview.nvim` installed.
    diffview = nil,
  },
  sections = {
    -- Reverting/Cherry Picking
    sequencer = {
      folded = false,
      hidden = false,
    },
    untracked = {
      folded = false,
      hidden = false,
    },
    unstaged = {
      folded = false,
      hidden = false,
    },
    staged = {
      folded = false,
      hidden = false,
    },
    stashes = {
      folded = true,
      hidden = false,
    },
    unpulled_upstream = {
      folded = true,
      hidden = false,
    },
    unmerged_upstream = {
      folded = false,
      hidden = false,
    },
    unpulled_pushRemote = {
      folded = true,
      hidden = false,
    },
    unmerged_pushRemote = {
      folded = false,
      hidden = false,
    },
    recent = {
      folded = true,
      hidden = false,
    },
    rebase = {
      folded = true,
      hidden = false,
    },
  },
  mappings = {
    finder = {
      ["<cr>"] = "Select",
      ["<c-c>"] = "Close",
      ["<esc>"] = "Close",
      ["<c-n>"] = "Next",
      ["<c-p>"] = "Previous",
      ["<down>"] = "Next",
      ["<up>"] = "Previous",
      ["<tab>"] = "MultiselectToggleNext",
      ["<s-tab>"] = "MultiselectTogglePrevious",
      ["<c-j>"] = "NOP",
    },
    popup = {
      ["?"] = "HelpPopup",
      ["A"] = "CherryPickPopup",
      ["D"] = "DiffPopup",
      ["M"] = "RemotePopup",
      ["p"] = "PushPopup",
      ["X"] = "ResetPopup",
      ["Z"] = "StashPopup",
      ["b"] = "BranchPopup",
      ["c"] = "CommitPopup",
      ["f"] = "FetchPopup",
      ["l"] = "LogPopup",
      ["m"] = "MergePopup",
      ["F"] = "PullPopup",
      ["r"] = "RebasePopup",
      ["v"] = "RevertPopup",
    },
    status = {
      ["q"] = "Close",
      ["I"] = "InitRepo",
      ["1"] = "Depth1",
      ["2"] = "Depth2",
      ["3"] = "Depth3",
      ["4"] = "Depth4",
      ["<tab>"] = "Toggle",
      ["x"] = "Discard",
      ["s"] = "Stage",
      ["S"] = "StageUnstaged",
      ["<c-s>"] = "StageAll",
      ["u"] = "Unstage",
      ["U"] = "UnstageStaged",
      ["d"] = "DiffAtFile",
      ["$"] = "CommandHistory",
      ["#"] = "Console",
      ["<c-r>"] = "RefreshBuffer",
      ["<enter>"] = "GoToFile",
      ["<c-v>"] = "VSplitOpen",
      ["<c-x>"] = "SplitOpen",
      ["<c-t>"] = "TabOpen",
      ["{"] = "GoToPreviousHunkHeader",
      ["}"] = "GoToNextHunkHeader",
    },
  },
}

This has been becoming more common and even results in commits not working unless I quit out of neovim an re-try until it works.

Hey - this is a bit tough for me to debug since I don't have a yubikey. I will say, it's a bit perplexing, since nowhere in the codebase do we call toupper() on any string. Is there somewhere in your config where you might have introduced that?

This is closed. The reason this was coming up was my statusline code. The magit buffer does not have a particular mode() so that was causing my statusline to tailspin. That has been fixed. Thanks for looking.


Vulkan synchronization

I'm trying to integrate the library into my vulkan game engine, but for it to fit nicely into the vulkan pipeline (and particularly since the library chooses to handle command buffer submission itself), can we please get a way to pass in vulkan semaphores to rrSubmitCommandStream?

It is not possible to use semaphores in frames of RadeonRays API. However, it is possible to use external to the library VkCommandBuffer, create RadeonRays command stream from it and then use for RadeonRays operation. After that you can use initial vulkan command buffer to submit all the tasks to vulkan queue.
VkCommandBuffer command_buffer;
// init command buffer
rrGetCommandStreamFromVkCommandBuffer(context, command_buffer, &command_stream);
// use command_stream for RadeonRays specific code
// add some other vulkan things to command_buffer, e.g
vkCmdCopyBuffer(command_buffer, hits_buffer, staging_hits_buffer, 1u, &copy_region);
vkEndCommandBuffer(command_buffer);
// fill vkSubmitInfo and submit queue where you can use semaphores

Ah, that did the trick!
Thanks for the help :)


GH-36154: [JS][CI] Use jest cache in CI

Rationale for this change

Use the cache of test to reduce test time.
What changes are included in this PR?

Use jest cache with actions/cache@v3.
Are these changes tested?

In GitHub Actions, test time was reduced.
Are there any user-facing changes?

Closes: #36154

@domoritz Thanks for the review.
Here is the link to the measurement results on GitHub Actions.
https://github.com/apache/arrow/issues/36154#issuecomment-1611331523

Great. The times seem faster although not by as much as I expected. Are we sure that caching doesn’t introduce issues where tests are stale? What is in the cache?

https://jestjs.io/docs/code-transformation

Jest will cache the result of a transformation and attempt to invalidate that result based on a number of factors, such as the source of the file being transformed and changing configuration.

Jest caches transformed codes.
In most cases, the cache should not cause problems.
The documentation notes the following.
https://jestjs.io/docs/cli#--cache

The cache should only be disabled if you are experiencing caching related problems.

So, it is not always possible to say that problems will not occur.

So should we use the cache across lock files as well then?

Do you mean to cache node_modules as well?
That seems better.

No, caching node modules is a separate issue and I don't think it'll help much. What I mean is that in https://github.com/apache/arrow/pull/36373/files#diff-9992b6f0e329a6dc49913c62f6efe2102f7a64f55d4bdab3d47df86292db5e87R97 we key by the lockfile but if the jest cache is automatically only used when its applicable, we can remove the restriction to specific node and lockfile versions.

At first, I too thought that the key was js-jest-cache-${{ runner.os }} would be enough.
However, if the key is the same, the cache stored on CI is not updated and the same cache is restored all the time.
So I thought it would be better to update the jest cache on CI when the lock file is updated, so I included the lock file in the key.

Why would it be an issue if the cache is not updated? It feels odd to update based on the lock file rather than some other test related property.

I agree that using a lock file is not the best way to do this.
I would like to be able to key in changes to files in src and test, but which is best?
Is it better to use github.sha?
If the cache is not updated, the cache will not be usable and the speed improvement will be less effective.

What are the inputs for jest's cache? We should use a hash value for them in key.

What we really want is a way to use a cache and still update it. Anything else will not catch many cases and the CI will still time out.

Since the cache for jest is a transformed code, it is created from the code in src and test.
I could not find a way to use those hash values for the key in a good way.
I thought github.sha seemed to be the most like it.

Then, we can use js-jest-cache-${{ runner.os }}-${{ hashFiles('js/**/*.ts', ''js/test/**/*.ts') }} for key like other our workflow files. If we can't reuse most cache when we update dependencies, we can also add js/yarn.lock like js-jest-cache-${{ runner.os }}-${{ hashFiles('js/**/*.ts', ''js/test/**/*.ts', 'js/yarn.lock') }}.
We should not use github.sha. If we use it, our cache is always updated even when we don't change js/{src,test}/**/*.ts. It will waste our available cache limit.

@kou Thanks for the information.
I did not know that you could use * in hashFiles or that you could specify more than one.
js-jest-cache-${{ runner.os }}-${{ hashFiles('js/src/**/*.ts', ''js/test/**/*.ts') }} looks good.
@domoritz What do you think?

What we really want is a way to use a cache and still update it.

This is not possible due to the way actions/cache works once a cache with a certain key is created it is immutable. But using the ts  file hashes in the key should work as you intend imo. (unless dependencies also come into play than you might want to ad the lock file as kou said)

Makes sense that caches are immutable. Do we have a way to check whether the cache is used? If it’s used even if dependencies change, I think we should not include the lock file in the hash.

I am not sure what you mean with if the cache is used? Used by jest? I don't know @abetomo? Though actions/cache sets an output value if there was a cache hit or not, if that is what you mean.

The existing cache is used even when dependencies are only changed because we have restore-keys: js-jest-cache-${{ runner.os }}-.
But the cache isn't updated if we don't have 'js/yarn.lock' in hashFiles(). Because the cache key isn't changed.
If jest's cache depends on dependencies too, we should add js/yarn.lock to hashFiles() too.

What I mean is that I’d like to make sure we know when the jest cache is actually used by jest or whether jest ignored it because the cache wasn’t applicable to the code.

The cache is generated in cacheDirectory.
If there is no cache (the cache is not used), a new cache file will be generated.
If the cache is used, no new file is generated.
This will help us determine if you used the cache or not.
There does not seem to be any option in jest to more easily know if the cache is used or not.

I tried it and when the package related to the code transform changes (when the lock file is updated), jest cache is also updated.
What about the key js-jest-cache-${{ runner.os }}-${{ hashFiles('js/src/**/*.ts', ''js/test/**/*.ts', 'js/yarn.lock') }}?

Thanks for the merge.


Fail to install deepspeed through ./install.sh : ModuleNotFoundError: No module named 'deepspeed'

Hello,
When on the master branch of Deepspeed, installing Deepspeed using ./install.sh in a virtual python environment fails.
I already tried to use the code at tag v0.3.0, but that failed too in another way, as reported here.
The result is :
...
Successfully installed Jinja2-2.11.2 MarkupSafe-1.1.1 Pygments-2.7.1 alabaster-0.7.12 appdirs-1.4.4 attrs-20.2.0 babel-2.8.0 certifi-2020.6.20 cfgv-3.2.0 chardet-3.0.4 clang-format-9.0.0 commonmark-0.9.1 distlib-0.3.1 docutils-0.16 filelock-3.0.12 identify-1.5.6 idna-2.10 imagesize-1.2.0 importlib-metadata-2.0.0 iniconfig-1.1.1 nodeenv-1.5.0 packaging-20.4 pluggy-0.13.1 pre-commit-2.7.1 py-1.9.0 pyparsing-2.4.7 pytest-6.1.1 pytest-forked-1.3.0 pytz-2020.1 pyyaml-5.3.1 recommonmark-0.6.0 requests-2.24.0 snowballstemmer-2.0.0 sphinx-3.2.1 sphinx-rtd-theme-0.5.0 sphinxcontrib-applehelp-1.0.2 sphinxcontrib-devhelp-1.0.2 sphinxcontrib-htmlhelp-1.0.3 sphinxcontrib-jsmath-1.0.1 sphinxcontrib-qthelp-1.0.3 sphinxcontrib-serializinghtml-1.1.4 toml-0.10.1 urllib3-1.25.10 virtualenv-20.0.34 zipp-3.3.0
Removed build tracker: '/tmp/pip-req-tracker-4_ygrx7k'
Traceback (most recent call last):
  File "basic_install_test.py", line 19, in <module>
    raise err
  File "basic_install_test.py", line 16, in <module>
    import deepspeed
ModuleNotFoundError: No module named 'deepspeed'
Error on line 204
Fail to install deepspeed

My machine runs Ubuntu:
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.4 LTS
Release:	18.04
Codename:	bionic

This is how I set up the virtual env.
$ which python3.7
/usr/bin/python3.7

$ virtualenv -p /usr/bin/python3.7 ~/.virtualenvs/deepspeed

$ source ~/.virtualenvs/deepspeed/bin/activate

Cloned Deepspeed:
$ git clone git@github.com:microsoft/DeepSpeed.git
$ cd DeepSpeed/

I'm at this commit:
$ git log HEAD^..HEAD
commit 7ddfda85263890615791b63955b9f5ed28ea2eff (HEAD -> master, origin/master, origin/HEAD)
Author: Jeff Rasley<EMAIL_ADDRESS>Date:   Wed Oct 14 10:44:16 2020 -0700

    Add support for p100 in transformer kernels (#470)

    add compute cap of 6.0, support p100

How can I resolve this?

@visionscaper, we have recently improved our installation. Can you please retry to see if this issue is now fixed? Thanks.