feat(next): keep original string on unknown variants

Summary
This PR aims to keep the original values for unknown variants, if they are generated.
This allows downstream crates to act on them, for example logging the unexpected value. This is useful for example on the ApiVersion for the webhook versioning, in order to be able to properly determine if the event comes from a newer api version.
Checklist

[x] using conventional commits to hightlight user-facing fixes and features

Thanks for doing this. I am for it but I will let @mzeitlin11 pull the trigger

Thanks @lasantosr! Main initial question is both the purpose of the From<String> impl and its implementation. There should already be a FromStr impl for each enum - best if the raw string to enum variant logic doesn't get duplicated (since some of these enums are so giant, the FromStr impls are already the heaviest functions according to cargo bloat).

The purpose of From<String> is to have the infallible version taking directly the owned String instead of duplicating it.
I thought about replacing the implementation, removing FromStr instead of duplicating for enums with the unknown variant, which can't fail.
I didn't consider timing, so I can update the PR with one of the following, or any other you might consider (for enums with unknown variant only):

removing From<String> impl
removing FromStr impl
updating FromStr impl to call From<String>
updating From<String> impl to call FromStr

I think it is reasonable to clone in the exceptional case of encountering an unknown string. When calling stripe apis the bottleneck will be the network (meaning the additional resource cost of a clone is negligible). So my vote is #1.

I also like 1 for the reasons given above too. The FromStr impl for these types also already uses std::convert::Infallible for the error, so the inability to fail is already represented

@lasantosr ping me here when you have removed the impl and I will get it released :)

@arlyon I've updated the PR removing the From<String> impl, but tests are failing for another reason (I've run them locally and they're fine)

Hey @arlyon it's been a while, ¿could you have a look at this and the other next PRs?

Sorry for the delay @lasantosr, if Alexander doesn't get to it by next weekend I should have more time then to review. For now, I just reran the CI jobs to see if happens again

Thanks @mzeitlin11!
It was by bad, it's fixed now.


CssManager class

New class: CssManager (or something like that) that extracts common style properties from a formed DOM, creates the Css instance and adds it in the . Extra feature: dumps the css to a versioned file in the static folder and adds a link to this file in the page.
In general, TemPy does not care much about styling, it would be nice to have a dedicated api for css.

@Hrabal I would like to work on it, can you please brief me about it more?

@Hrabal  Sorry for taking so long was a lil busy.
Hypothetical "Sample":
Input:
body_dict = {"margin-top":"30px" , "padding":"10px", "background-color":"powderblue"}
h1_dict = {"color":"red" , "height":"55px"}
css = CssManager().add("body", body_dict).add("h1", h1_dict)

Output:

@mkhalid-s sorry too for late response, work is a lot lately :)
Anyway, I like that api, I'd just add an explicit method to produce the style tag, like so:
manager = CssManager().add("body", body_dict).add("h1", h1_dict)
manager.render()   # <- this produces the string

Please go on and work on that if you are still interested.
My original idea was to make CssManager a bit dynamic, and your api is a good start. That's what I had in mind: if added to a Html or Head tag, il would add the style to the page, and if added to other tags it would add style property on the html tag, something on those lines:
# bind to "page"
manager = CssManager().add("h1", {"color": "goldenrod"})
Html().bind_css(manager).render()
>>>

# bid to "normal" tag
manager = CssManager().add("h1", {"color": "goldenrod"})
H1().bind_css(manager).render()
>>>
<\h1>
H2().bind_css(manager).render()
>>>
<\h2>   # <- no style applied for manager does not contain a rule for h1


[systemd] add systemd integration (meta data)

What does this PR do?
Add new systemd integration as corecheck to monitor systemd itself and the units it manages.
This PR only contains the metadata. This implementation PR is here: https://github.com/DataDog/datadog-agent/pull/3584
Motivation
This integration has been requested by users.
Additional Notes
/
Review checklist (to be filled by reviewers)

[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached
[ ] Feature or bugfix must have tests
[ ] Git history must be clean
[ ] If PR adds a configuration option, it must be added to the configuration file.

@ruthnaebeck Thx for all the updates. I added few more units: https://github.com/DataDog/integrations-core/pull/3830/commits/a8e78696be60dca5d3c7c65c6da03c0c7d6bf301

@ruthnaebeck Thx for all the updates. I added few more units: a8e7869
Is there a suitable unit for boolean metrics like:
systemd.unit.active,gauge,,,,Whether the unit is currently in active state,0,systemd,unit.active
systemd.unit.loaded,gauge,,,,Whether the unit is currently in loaded state,0,systemd,unit.loaded

Can't find any in this list: https://github.com/DataDog/dogweb/blob/prod/integration/system/units_catalog.csv

The changes look good.
There isn't a suitable unit for boolean metrics. Those are just left blank.


how to use this module with multiple resources?

I started using this module recently, but I am struggling to understand how it handles random instance numbers when dealing with multiple resources of the same type.
I have the following code, and all I want to do is to have 2 resource groups, with a random instance number at the end (as a suffix).
module "websiteNaming" {
source  = "Azure/naming/azurerm"
suffix = [ "n", "web", "dev" ]
prefix = [ "xyz" ]
unique-length = 2
unique-include-numbers = true
}
resource "azurerm_resource_group" "xyz_website" {
name     = module.websiteNaming.resource_group.name_unique
location = "West US"
}
resource "azurerm_resource_group" "dof_website2" {
name     = module.websiteNaming.resource_group.name_unique
location = "West US"
}
but what I end up with, is 2 resource groups with the same name.
resource "azurerm_resource_group" "xyz_website" {
id         = "/subscriptions/xxx-xxxx-xxx/resourceGroups/xyz-rg-n-web-dev-xe"
location   = "West US"
managed_by = null
name       = "xyz-rg-n-web-dev-xe"
}
resource "azurerm_resource_group" "xyz_website2" {
id         = "/subscriptions/xxx-xxxx-xxx/resourceGroups/xyz-rg-n-web-dev-xe"
location   = "West US"
managed_by = null
name       = "xyz-rg-n-web-dev-xe"
}
All I want to have is something like xyz-rg-n-web-dev-87 and xyz-rg-n-web-dev-76 where the instance numbers are randomly generated.
How can I do this with this module? it sounds strange to have a different naming module for each same type resource - what if I wanted to create a 100 web apps with this module, where the names of the web apps are unique (unique instance number)?
Please help me.
thanks.

It can't generate random characters each time you reference the name_unique property as it's not a method.  The unique value has been generated once and then assembled with each resource type available in the format Azure expects for that resource.  Wrap your resource group in a module with the naming module and then you can call it as many times as you want.

I have the same issue. I built a helper module around this to provide a set of naming conventions depending on the way the resource is being used. My preferred naming convention is to append a random ID that is specific to each instance of each resource.
This allows for create_before_destroy to work properly in Azure along with other similar workflows. If a specific resource needs to be replaced with a new unique name, the random_string is shared across all resources named with that module call. This is a problem for a couple of reasons:

This makes it very difficult to in-place rebuild a subset of resource as the random_string resource must be tainted to generate a new result.
The compromise workaround encourages single-resource modules (the naming module call and the resource itself) to provide a unique suffix, which creates unnecessary overhead and complexity.
I considered adding a random_string to my helper module that runs for_each based on each resource output from this module, but that would create (at current count) 247 additional resources. Each random_string would also only be specific to a resource type, which doesn't provide any benefit to the workflows described above as that suffix would be identical between multiple instances of the same resource.
Additionally, for those of us using HCP Terraform or other services, the pricing structure is per resource. Even with the most efficient usage of random_string, that would DOUBLE the number of resources under management. This is cost prohibitive and creates inflated states.
I considered using Terraform functions or other approaches to accomplish this as they aren't resources, but the options are either:

Some variation of a hash or namespace-based UUID, but since these outputs are predictable this has the same limitations resulting in naming collisions with create_before_destroy.
Using something like uuid(), which is not a resource and is randomized each time it's called but is not persisted to state so every resource would need an ignore_changes = [ name ] lifecycle.
Maybe some kind of terraform_data with triggers and keepers?
A really long random_id that's sliced up? This sounds overly complex to properly correlate.
ephemeral resources were just GA'd in 1.10.0, but I'm having trouble imagining how to use them in a way that doesn't have the same limitations as other approaches, and this also feels like an abuse of a resource type intended for secrets management.

...you get the point.
The AWS provider gets around this by providing a name_prefix parameter in addition to name, which handles the random suffix for you. I don't think the Azure provider has an equivalent.
I realize this isn't really a problem specific to this module, but if there were a solution, I would love to see it reflected here.
Has anyone thought of something that overcomes this?

Similar issue #71


project description not up to date

Pocok will help you to organise and manage Docker, Docker-Compose, Kubernetes projects of any
complexity using simple YAML config files to shorten the route from finding your project to initialising it
in your local environment. https://pocok.io

s/Pocok/Proco/g

Done:)


Fix pubsub context manager exit error

Possible fix for #1955, checking the length of self.messages before __exit__.

@daspecster I think a more comprehensive fix would be to check self.messages inside Batch.commit, and exit early.  We do document the imperative Batch API, which would still be broken otherwise.

LGTM


Latte.exe - receiver should not run with -c parameter (which is reserved for the client)

Run latency tests
Start latte.exe on the RECEIVER (run from CMD, not from PowerShell):
latte -a : -i
Around 65k iterations is long enough to return representative results.
Any available port number is fine.
If the VM has an IP address of <IP_ADDRESS>, it would look like this
latte -c -a <IP_ADDRESS>:5005 -i 65100

The example in the last line shown above should not include -c parameter (which is reserved for the client).

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

ID: c5a77eb3-1f6d-0fee-7d77-44a56fdb78b0
Version Independent ID: 66f67a40-fcb3-9549-63fc-295e330a9c56
Content: Validate VPN throughput to a virtual network - Azure VPN Gateway
Content Source: articles/vpn-gateway/vpn-gateway-validate-throughput-to-vnet.md
Service: vpn-gateway
GitHub Login: @cherylmc
Microsoft Alias: radwiv

@Surfen, Thanks for reaching out. We will investigate and update this thread.

@surfen, Appreciate your patience. The doc has been edited accordingly and it would take some time for the changes to get reflect over the doc.
We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


[FR] Let user paste in the code.

fill all box with ctrl + v on desktop or paste on mobile

This would be a great feature!

Created a pull request for this #9

Supported in v2.1.0


Unable to login into Auth0 account after signup

I have added your package in  my meteor application and i am able to see the Auth0 popup.When I click on signup and enter all the details, then click on submit button, User created in Auth0 account but unable to login.It's ended with below error
signed up successful but couldn't log in
What could be the wrong? AM I missing anything here?.
Could you please help me on this .

I'd like to help you. However, I don't have enough information to give you suggestion.

What's your Meteor version and xcv58:auth0-lock version?
Do you have a reproduce repo?
Could you please make sure your Auth0 client settings are correct, i.e. allowed web origins, callbacks, etc.?

And there is an example in this repo: https://github.com/xcv58/meteor-auth0/blob/master/README.md#example
Please let me know whether you can reproduce the problem with the example app.

Thanks for the replay.
Below are the details and versions which I am using in my local .
meteor --version
Meteor 1.6.1
xcv58:auth0-lock                         6.0.2* Auth0 Lock for Meteor
ClientSettings:
weborigins URL: http://localhost:3000
CallBack URL    : http://localhost:3000
Did I missed out anything?
Do you want me to check anything else.I'M able to see the created users in the Auth0 users list.
please help me.

The v6.0.2 is really old with outdated auth0-lock version. Could you please upgrade to 7.1.0 and try again?

Hi I'M very new to meteor, How can i add 7.1.0. When I'M trying to add the package like below by default it is giving v6.0.2
meteor add xcv58:auth0-lock.

Thanks for the help, After upgrade my package to 7.1.0, It is working perfectly fine.Thank you so much

You are welcome!


2.10: AnyHttpUrl is no longer subclass of pydantic_core.Url (according to mypy)

Initial Checks

[X] I confirm that I'm using Pydantic V2

Description
Using pydantic<2.10.0, mypy says AnyHttpUrl is subclass of Url. With pydantic 2.10.0, it's not anymore.
Is that intended?
Example Code
from pydantic import AnyHttpUrl
from pydantic_core import Url

foo = AnyHttpUrl("https://www.google.com/")

print(isinstance(foo, Url))
# True in 2.9
# False in 2.10

Python, Pydantic & OS Version
pydantic version: 2.10.0
        pydantic-core version: 2.27.0
          pydantic-core build: profile=release pgo=false
                 install path: /home/userx/proj/internal/task_runner/.virtualenv/lib/python3.10/site-packages/pydantic
               python version: 3.10.8 (main, Oct 10 2023, 11:46:07) [GCC 9.4.0]
                     platform: Linux-<IP_ADDRESS>-microsoft-standard-WSL2-x86_64-with-glibc2.31
             related packages: mypy-1.6.1 typing_extensions-4.12.2
                       commit: unknown

Hi!
Thanks for your question. This is indeed intended. All single host url variants are now subclasses of AnyUrl, and the pydantic_core Url structure will just be used internally.
You can read more here about the URL changes 👍


[Donate-GiveOnce] No proper error message on entering negative amount.

Title
[Donate-GiveOnce] No proper error message on entering negative amount.
Platform / OS
Windows
Browser
Google Chrome
Description
Navigates to the PayPal screen and displays  message "Things don't appear to be working at the moment. Please try again later."
Steps to Reproduce

Browse "https://dev.sleepbus.org/".
Hover over "Donate".
Click "Give Once".
Scroll to "Give Safe Sleeps" section.
Input negative amount.
Click "Give by PayPal".

Expected Behavior

Should not navigate to the PayPal screen.
Instead, it should give an error message "Please enter a valid amount" in "Give Safe Sleeps" section only right above the amount text field.

Additional Info
Branch: 0b650b07369f1e40f3df170a90fc2b82e13df2d4
dev Build: https://circleci.com/gh/sleepbusorg/sleepbus.org/125

Related Issue: Entering comma on the field gives the same result as this issue


Add SkyWalking go SDK as a trace plugin

Issues associated with this PR
#1027
Your PR should present related issues you want to solve.
Solutions
You should show your solutions about the issues in your PR, including the overall solutions, details and the changes. At this time, Chinese is allowed to describe these.
UT result
Unit Test is needed if the code is changed, your unit test should cover boundary cases, corner cases, and some exceptional cases. And you need to show the UT result.
Benchmark
If your code involves the processing of every request, you should give the Benchmark Result.
Code Style

Make sure Goimports has run
Show Golint result

TODO list

[x] go2sky releases an exclusive version of mosn
[x] Add the componentId and UI icon to skywalking repo
[x] test with skywalking

Codecov Report

Merging #1061 into master will decrease coverage by 0.31%.
The diff coverage is 61.37%.

@@            Coverage Diff             @@
##           master    #1061      +/-   ##
==========================================
- Coverage   56.38%   56.07%   -0.32%
==========================================
  Files         242      250       +8
  Lines       22913    23218     +305
==========================================
+ Hits        12920    13019      +99
- Misses       8837     9024     +187
- Partials     1156     1175      +19

Impacted Files
Coverage Δ

pkg/trace/skywalking/span.go
0.00% <0.00%> (ø)

pkg/trace/skywalking/tracer.go
62.16% <62.16%> (ø)

pkg/trace/skywalking/http/tracer.go
72.30% <72.30%> (ø)

pkg/trace/skywalking/driver.go
79.16% <79.16%> (ø)

pkg/variable/api.go
43.63% <0.00%> (-1.65%)
:arrow_down:

pkg/stream/xprotocol/stream.go
29.23% <0.00%> (-1.42%)
:arrow_down:

pkg/module/http2/transport.go
78.47% <0.00%> (-0.44%)
:arrow_down:

pkg/module/http2/server.go
81.55% <0.00%> (-0.37%)
:arrow_down:

pkg/server/handler.go
41.34% <0.00%> (-0.23%)
:arrow_down:

pkg/proxy/var.go
6.02% <0.00%> (ø)

... and 13 more

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 2ea7c63...e3f84ea. Read the comment docs.

Screenshot
Service

Endpoint

Instance

Topo

Trace

@wu-sheng @taoyuanyuan @rootsongjc please review :)

@taoyuanyuan @rootsongjc Did I miss any documentation?

@arugal Thank you for adding this quickly.

@taoyuanyuan @rootsongjc Did I miss any documentation?

Do you have any usage instructions or manual?

@taoyuanyuan @rootsongjc Did I miss any documentation?

Do you have any usage instructions or manual?

Hi @rootsongjc , I have improved the sample document, please review :)

This PR has been merged. It will be released in the next version of MOSN.


Does not show transmog status checkmarks from CanIMogIt

Addon Version
v0.1.6
World of Warcraft Version
Retail
Describe the bug
CanIMogIt and Adibags (v1.10.24) work together to show all my items in the one bag with the tiny checkboxes in on the item icons to show if I have the transmog.
I recently moved to BetterBags since the latest AdiBags update told me to.
However, the BetterBags display does not show the checkbox from CanIMogIt - which removes my ability to look at a sorted portion of my bag and determine what to mail to my alts for transmog collection.
Steps to reproduce

Install AdiBags v1.10.24 from Curse
Install "Can I Mog It?" v10.1.5v1.53 from Curse
Launch WoW retail, log into character and view bag: armour had the green-checkmark/other icons from Can I Mog It?
Disable/Uninstall AdiBags
Install BetterBags v0.1.6 from Curse
Launch WoW retails, log into character and view bag.  Same armour icons will be missing checkmarks.

I'm not sure if it matters but initially came to this github to make this bug report. It sucks that it's happening but I am glad I'm not the only one that noticed.

CIMI has a specific plugin just for AdiBags: https://github.com/TorelTwiddler/CanIMogIt/blob/master/Plugins/adibags.lua
This is something the CIMI author needs to implement. We'll leave this bug open to track it on our end.

I also came here to point this out. I really hope the passionate team coding BetterBags sort this out soon, as I do like BetterBags's general look.

Here is a small update the team from "Can i mog it" is working on this =)
https://gitlab.com/toreltwiddler/CanIMogIt/-/issues/314

It's working for me with the latest release of each addon, can someone confirm and if so should this be closed/marked as completed?

This has been working correctly for me for a while now, But I don't really make more than cursory use of CanIMogIt.
So not sure what work is missing still.


Consider adding section to Readme about git ignore

I think it would be beneficial if the readme talked about different methods of ignoring the justfile, or at least linked out to here, because:

Some developers may not know about .gitignore and may commit the justfile.
Most developers (myself included until today) do not know that you can specify a global .gitignore, so that you do not need to repetitively add justfile to every repos's .gitignore.

Point 2 is the one that I feel most users would find really interesting.

This is really interesting, I always commit my justfiles. What's the use-case for not committing them? Is it common?

I don't know how common it is -- it may just be me. I don't really want to commit my justfile when contributing to a project because it would require an explanation and a case for why it's there. Since just is still rather niche, I feel like maintainers may not want an extra file in their project, and users would not know what it is or how to use it. So I've mainly been using just for personal commands, and not committing the justfile, and make for commands that should be committed.
Perhaps I misunderstood the intention behind this utility. But I don't think it's a viable replacement for make in all cases due to the latter's ubiquity. (It's a really sweet project by the way. Love the attention to detail, even the grammar is included. 🤯)

I don't know how common it is -- it may just be me. I don't really want to commit my justfile when contributing to a project because it would require an explanation and a case for why it's there. Since just is still rather niche, I feel like maintainers may not want an extra file in their project, and users would not know what it is or how to use it. So I've mainly been using just for personal commands, and not committing the justfile, and make for commands that should be committed.

Thanks for the background! That makes perfect sense.
I would definitely encourage you to open PRs adding justfiles to projects, I sometimes do. I always make it clear that it's just a suggestion, and the maintainer should feel free to close the PR unceremoniously if they don't see it as a value add.

Perhaps I misunderstood the intention behind this utility. But I don't think it's a viable replacement for make in all cases due to the latter's ubiquity.

You have the right idea. I'd like just to become as widely used as make, although it's definitely not there yet. It'll probably take a 1.0 where I commit to long-term stability, as well as making it into the Debian repositories, so Debian and Ubuntu users can easily use it.

(It's a really sweet project by the way. Love the attention to detail, even the grammar is included. 🤯)

Thank you so much! I definitely sweat the details, so it's nice when people notice.
As far as what to do with this issue, here's an idea:

Make just look for a justfile called local.justfile, in addition to justfile
If you have a justfile you don't want to commit, call it local.justfile
Add local.justfile to your global gitignore

That way, when you want a justfile in a repo that doesn't have one, you can create and use local.justfile, without having to do anything to prevent it from being comitted.
What do you think? Critical feedback welcome! I think for me, the downside would be adding a new file that just looks for, which could be confusing, although the cost is pretty low.

The following is my personal opinion

The README for just should only contain that is closely related to ro integrated with the project.
What should be covered in the project description doc (README) should be helpful for the future of the project. It should be promoted and encouraged to be used.
When adding features, they should be evaluated carefully, especially when it comes to changes in default behavior.

The issues raised so far do not justify local.justfile as the default.
I think the best solution to the current question is to use .justfile and add it to the corresponding version control software ignore rule.
~/.gitconfig or ~/.config/git/config
[includeIf "gitdir:~/path/to/projects-dir/"]
    path = ~/.config/git/my-projects.gitconfig

~/.config/git/my-projects.gitconfig
[core]
    excludesFile = ~/.config/git/my-projects.gitignore

~/.config/git/my-projects.gitignore
# git ignore rules for all projects under ~/path/to/projects-dir/
.justfile

I look forward to a better official website with multi-page documentation in the future just. It's also a good way to get more people to recognize it and reflect what a mature project should be.
The docs source is divided into separate files by chapter. Generate single page help, multi-page documentation or official website by static generator.
I'm willing to contribute the above via PR if appropriate, but certainly not in the README.

@page-down Thank you for your feedback. I've been thinking about splitting the readme up, but I'm not sure what the benefit would be. Feel free to comment in #451 on why you think this would be a good idea.

Thanks for the heads up. Just to clarify, I really like the way it is now, because it is very easy to use the search that comes with the browser or editor in a single page.
Maybe leave it like this for now and reconsider in the future before the 1.0 release. :)

Unsure about the naming but in principle I like the idea of a local.justfile.

Like @casey said I'd open an issue to quickly discuss the addition of Justfile to the project if I was going to contribute to the project and wanted to use just. Either for official usage or to update the .gitignore or what have you for the version control system the project uses. That way it can be officially accepted or ignored and will avoid unintentional addition of Justfiles to the project. No need for a new special name. Though if a new special name is added I vote for .justfile.


Require a legacy_url_path when creating a Whitehall asset via Asset Manager API

Although we have validation to check the format & uniqueness of Asset#legacy_url_path, we should change WhitehallAssetsController#create so that it requires the presence of a legacy_url_path parameter.

I've opened #228 to fix this.


Nick: Watch maindiads.com

Nick requests the watch of the watch_keyword maindiads\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

maindiads\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Makyen in Charcoal HQ


Add docker-based ROS prerelease test.

Ok prerelease tests run and now it's ready for PR to upstream. Closing.


Improve Odin bindings, DLL support

This PR is closely linked to https://github.com/floooh/sokol/pull/1023, it contains all the info

See my comments in the sokol PR. I'll try to take care of the PRs on the weekend.

Don't worry about the merge conflict. I'll try to do the merge locally, and hopefully it's enough to rerun the code generation with your changes in both repos.

And merged. I also did:

add a changelog file (similar to the one in sokol-zig)
made the .sh files to build the library executable

Interestingly I didn't see any merge conflicts when doing the merge locally (while the Github PR UI said there would be conflicts).
Thanks!


Clarify News Feed

Remove un-necessary stuff from news feed, showing only the news items we want.  Right now we want to remove

Updates to photos
Links

Maybe mark the ones we want to show as highlights, then only those items will show up (if that is an option in the API)

This isnt an option in the FB API, so need another way to do this


[sil-serializer] Do not use RPOT order for serializing SIL basic blocks

What's in this pull request?

Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[x] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is build incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

My earlier patch started serializing SIL basic blocks using the RPOT order. While it works, changing the existing order of BBs during the serialization may be very surprising for users. After all, serialization is not supposed to transform the code.
Therefore, this patch follows a different approach. It uses the existing order of BBs during the serialization. When it deserializes/parses SIL and detects a use of an opened archetype before its definition, it basically introduced a forward definition of this opened archetype. Later on, when the actual definition of the opened archetype is found, it replaces the forward definition. There is a correctness check at the end of a SIL function deserialization, which verifies that there are no forward definitions of opened archetypes left unresolved.

@swift-ci Please test

@swift-ci Please test

Linux failure is unrelated and seems to be addressed by #3627. OS X failure is also unrelated.


kusto -> Kusto

The 'K' in package name "Microsoft.Azure.Management.Kusto" should be upper case.

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

Thanks @zhiliangxu for noticing that. #sign-off
Please continue to contribute to our docs and help us improve them!

@YaelSchuster: I'm sorry - only the author of this article, @orspod, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


List of ContentDefinition Metadata Item Keys

Hello,
is it possible to get a list of content definition metadata keys?
This example only shows one, which is DisplayName. However, sample policies use another "language.intro". Can we please have a list of metadata keys so we can further enhance the experience.
[Enter feedback here]

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

ID: 5da541cb-72b5-7971-3c58-8bd3fe546369
Version Independent ID: 377d8d53-cf44-5a3a-d431-1823bdd17be0
Content: ContentDefinitions - Azure AD B2C
Content Source: articles/active-directory-b2c/contentdefinitions.md
Service: active-directory
Sub-service: b2c
GitHub Login: @msmimart
Microsoft Alias: mimart

@Norrch2
Thanks for your feedback! I have assigned this issue to the author who will investigate and update as appropriate.

Although there are some policies that define metadata in the content definition, it's not supported, and there is no impact on the UX.

#please-close


Fix auth integration test on Mac

Fixes a problem we were hitting with a failing volume mount on Mac.

Closing this in favor of #836


Fix listing block in SSR, now it is fully variations aware, and the…

… config is passed to the SSR querystring action

This seems correct in my view, though I have no way to effectively evaluate it.  Tests seem to pass.
The fact that the promise of rendering a site to nonjs visitors / search engines was broken... and this seems to be the direction that the stewards of Plone are going with... breaks my heart.
It is the obvious unspoken conclusion that a client-side rendering strategy was eventually going to get us all to the point that client rendering (= js) turned off will net visitors no (or broken) client rendering, no matter how much we want to render for the client server-side.  We just can't test for that on every individual Web site.    RMS is busy reading email from 1989.
This should probably be merged anyway.
Sad.

@Rudd-O Your response to someone fixing a server-side rendering issue is to criticize the team for not caring enough about server-side rendering? Wow, I bet that doesn't help motivate the people that are volunteering time to work on it.
I think there are feasible strategies for testing that server-side rendering isn't broken. i.e. load key pages as an anonymous user with cypress and test that the DOM is the same before and after client-side rendering. If you care about it, it'd be more effective to work on making it better than complain about the current situation not meeting your needs.
I hope this doesn't come across as disrespectful. To some extent, I can understand your frustration. But your comment struck a bit of a nerve because I know the Volto team cares about and has put effort into this.

https://2022.ploneconf.org looks great to me!

@stevepiercy The listing of talks is missing key text though (speaker and abstract). I think that is what this will help with...

@Rudd-O I want to point out that it's not "Volto developers don't care about JS disabled", as @sneridagh and I worked hard to make that happen. It's a bug due to a rather new / uncommon feature that was added to Volto. All this is rather fresh stuff, probably around 6 months. There's a ton of development to do in Volto world, we're trying to make a really attractive platform for developers.

@Rudd-O Thanks for report this bug on Discord, good catch!
First of all, I have to state in case of someone reach this PR at some point, and reads it, that Volto in SSR rendering works well, as the many projects developed by the community that are currently in production since years ago.
This piece of code is probably one of the more complex in Volto, as usually happens when talking about SSR features. It's one that @tiberiuichim and myself spent quite a few time to figure it out and find the right implementation. Finally we come up with a solution inspired in how NextJS is doing things and we manage to address it. Yes, it had an issue, you identified it and pointed it out in the Discord channel and it got fixed within the day... This says a lot about this community, right?
It's true that this community still haven't found time to test and assess these edge cases (since plain page SSR works since years ago), but we will eventually do. Maybe you could take a look and help with it?
I wish we could do something to cheer you up. Volto is not the default UI for Plone 6 because "the stewards of Plone" decided so. It's because the Plone community decided so. Plone 6 Volto is a proven solution that powers dozens of websites nowadays and renew its prowess every day. Are you attending the conference? I'd like to be able to address and convince you of these points and dissipate any concern you could have about the future of Plone.

@Rudd-O Your response to someone fixing a server-side rendering issue is to criticize the team for not caring enough about server-side rendering? Wow, I bet that doesn't help motivate the people that are volunteering time to work on it.
I think there are feasible strategies for testing that server-side rendering isn't broken. i.e. load key pages as an anonymous user with cypress and test that the DOM is the same before and after client-side rendering. If you care about it, it'd be more effective to work on making it better than complain about the current situation not meeting your needs.
I hope this doesn't come across as disrespectful. To some extent, I can understand your frustration. But your comment struck a bit of a nerve because I know the Volto team cares about and has put effort into this.

No disrespect taken.  I am frustrated, but I recognize that the Volto team puts effort in ensuring that both alternatives work fine.
Totally stoked, however, at how quickly the issue was remedied.  Yes, that does say a lot about the community, and it's only positive things.  Let's figure out a way to never have this issue crop up in the future ever again.


Logging EC2 memory metrics (via Cloudwatch)

Start Date
ETA
Project Lead
Actual Ship Date

2023-02-20
2023-02-24
@sarayourfriend
TBD

Description

Install the Cloudwatch agent for memory metrics.
Openverse is (in the beginning of 2023) moving away from EC2 with the exception of the Elasticsearch Cluster, Ingestion server and Catalog. Currently, we don’t have memory metrics for EC2 instances.
Documents

This is a project that does not require project documentation.
Issues

Prior Art

This was shipped with https://github.com/WordPress/openverse-infrastructure/pull/357 but shouldn't be considered success until https://github.com/WordPress/openverse-infrastructure/issues/380 is complete.


fix compile error after poi bump

Description
fix compile error after poi bump
Related Issue :
How Has This Been Tested?

Need additional checks?
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] I have read the CONTRIBUTING document.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have added tests to cover my changes.

Additional Context

deploy to 2


Refactr

hi. It's possible to refactor code? so exists def, which makes new JS file from text file. (Separate ST3 code, separate code which makes file)
def get_new_text(text, option_indent)

Just to be clear @Alexey-T, do you mean the code generated when using Jasmine Scaffold being created in a new file rather than overwriting the current file?
If that is the case I wonder how this would be best implemented to allow people to choose their preference, any ideas?

eh..i don't get u. What file. i only suggest def.
to get text of file. other code will write text.

Ok sorry, you mean refactor some of the logic out into a separate file?
I do plan on tidying the code up as things progress but I'm more than happy for others to contribute any refactoring they see fit.

ye. I mean refactor to def into new file `work.py'

what for? for Synwrite plugin.

This is still on my radar but right now I don't have the knowledge or incentive to recfactor. I'm happy to accept PR's or guidance to help with this though.


moment().week() and moment().year() behaving inconsistently during this week

Describe the bug
Using moment().week() returns week 1, but moment().year() still returns 2018, creating a lot of issues in our code
To Reproduce
Steps to reproduce the behavior:

Go to node console with moment installed
Use moment().week() and see that it returns 1st week of the year
Use moment().year() and see that it returns 2018 still

Expected behavior
Honestly, I'm not sure, I don't think the week number should change before the year has changed. Changing the year beforehand would be unexpected behaviour on itself, so I think the solution should be to allow for week 53 to exist in these cases
Desktop (please complete the following information):

Server: NodeJS using Typescript
Version 10.8.0

Moment-specific environment
Default settings, happening since yesterday 30/12/2018

I have the same problem..
console.log(moment().format('YYYY_WW')); //prints 2018_01
I would expect it to print 2019_01, since it is the first week of 2019 (eventhough it started on dec 31).
Is there a way/workaround to get 2019_01 instead?

What we've done is updated our code so that if it's week 1, month 11 (We've checked and it returns month 11 correctly), hardcode year 2019.
Not ideal but does the job and we need to release a hotfix to production.

It's possible to get the week-year using gggg/GGGG(ISO) instead of YYYY. I think this would fix most problems in this case.
moment('2018-12-31').format('GGGG_WW'); // "2019_01"

https://momentjs.com/docs/#week-year-week-and-weekday-tokens

@Kylar13 year() is not locale or week-aware.
For locale-dependent week + year, use week() with weekYear().
For ISO standard, use isoWeek() with isoWeekYear().


Experienced

What other languages do you have experience with?
Significant amounts of Ruby, Javascript/Typescript and Python. Small amounts of many others.

Related proposals

Has this idea, or one like it, been proposed before?
Yes, #35093 is the clearest other version of this (and a few other linked issues are also similar)

If so, how does this proposal differ?
It limits the change to lexically visible places, and shows how this might interact with other Go features in more detail.

Does this affect error handling?
Somewhat

If so, how does this differ from previous error handling proposals?
It is similar to #35093. The primary focus is a new control flow mechanism. While it is not an error-handling proposal per-se, it would help with error handling in currently hard-to-support contexts.

Is this about generics?
Not as such, but generic code would benefit from this change particularly.

If so, how does this relate to the accepted design and other generics proposals?

Proposal

What is the proposed change?
Go should add a new keyword/builtin returnFrom(fn, ...retArgs) that lets you return early from a surrounding function or function call.

Who does this proposal help, and why?
The primary case it would be helpful is for iterating over custom collections.
Iteration in go is today handled using a for loop that looks something like this:
i := collection.Iter()
defer i.Close()
for i.Next() {
  if doSomething(i.Current()) { break }
}

It is currently necessary in go to use a for loop to iterate if you know in advance that you may not want to iterate over the entire collection; because break and return let you end iteration early.
This has two problems:

The implementation of the iterator cannot use for loops. As each call to Next() happens on a different stack, and implementors must manually track and update progress.
The caller has to do any necessary cleanup (in the example here, calling i.Close()).

Both of these problems could be solved by allowing the implementor of the iteration to own the control flow. That would mean that the lifetime of the iterator is tied to a function, and so implementors could use for loops, and defer statements to clean up as necessary. (This was proposed in the context of extending for range loops to custom types at #47707). With returnFrom() this proposal is easier to implement, and doesn't suffer the "forget to check the return value" problem.
Two examples of this API:
  func example() error {
      // used as an equivalent to `break` to move function control out of the loop
      collection.Range(func(u *Unicorn) {
          if doSomething(u) {
              returnFrom(collection.Range) // control flow jumps to fmt.Print call
          }
      })
      fmt.Print("done")
      // used as an equivalent to `return` to end the enclosing function early
      collection.Range(func(u *Unicorn) {
          if err := doSomethingElse(u); err != nil {
              returnFrom(example, err) // example() returns the value err
          }
      })
      return nil
  }

With this support in the language, the implementor of collection.Range() can defer the cleanup
required itself; and if the collection used something like a slice under the hood, the implementation of the iterator would be very simple (something like this):
  func (c *Collection) Range(fn func(u *Unicorn)) {
      s := c.getResults()
      defer s.Close()
      for _, u := range s.slice {
          fn(u)
      }
  }

This would also pave the way for generic helper functions like slices.Map that are common in other
languages (particularly those that use exceptions for error related control flow), but which are hard to implement in go because there is currently no idiomatic way to end iteration early if something goes wrong.
  func lookupHosts(hosts []string) ([]string, error) {
      return slices.Map(hosts, func(s string) string {
          ret, err := lookupHost(s)
          if err != nil {
              returnFrom(lookupHosts, nil, err)
          }
          return ret
      }), nil
  }

  // package slices
  func Map[T, U any](s []T, fn func(T) U) []U{
    r := make([]U, len(s))
    for i := range s {
      r[i] = fn(s[i])
    }
    return r
  }

That said, there are a few other cases it would also help with. You could use it to clarify returning from the parent function in a deferred function.
  func before() (i int) {
      defer func() { i = 10 }()
      return 5
  }

  func after() int {
      defer func() { returnFrom(after, 10) }()
      return 5
  }

There are also a few cases where a nested function is used outside of the context of iteration. One example is errgroup (though until #53757 is fixed, this will not work).
// returns a match, or if no matches, the first error encountered
func find(needle string) (int, error) {
  g := errgroup.Group{}

  for _, c := range collections {
      bound := c
      g.Go(func () error {
          result, err := bound.Seek(needle)
          if err != nil {
              return err
          }
          returnFrom(example, result, nil)
      })
  }

  return 0, g.Wait()
}

In terms of prior art, a similar keyword return-from exists in lisp. The problem is solved in Ruby by differentiating between methods and blocks (return returns from the enclosing method even when called in a block; and break returns control to the next statement in the enclosing method when called in a block). The distinction between methods and blocks seems unnecessarily subtle for a language like go. In Python this problem was solved by adding generators to the language, but that seems very heavy-handed for a language like go.

Please describe as precisely as possible the change to the language.
A new builtin would be added returnFrom(label, ...retArgs). The first argument label
identifies a funtion call, that is either the call to the function named label that lexically encloses the function literal containing returnFrom, or a call to a function named label that contains the function literal in its argument list.
A new type would be added to the runtime package, type EarlyReturn { } which contains unexported fields; and which implements the error interface.
When returnFrom is called, it creates a new instance of runtime.EarlyReturn that identifies which function call to return from, and with which arguments; and then calls panic with that instance.
When panic is called with an instance of runtime.EarlyReturn it unwinds the stack, calling deferred functions as normal until it reaches the identified function call. At that point, stack unwinding is aborted and execution is resumed as if the called function had executed return ...retArgs.
If the identified function call is not found on the stack, then the stack is unwound and the program terminates as it would with an unhandled panic. This would happen if the closure in which returnFrom is called was returned from the function it was defined in, or run on a different goroutine. The error message would be: panic: call to returnFrom(<label>) outside of <label>.
If recover is called while unwinding in this way, then the instance of runtime.EarlyReturn is returned. If the deferred function calls does not panic then execution is resumed as it is when recovering from a panic; and the returnFrom behavior is abandoned. Similarly if a deferred function panics with a different value, then the returnFrom is abandoned and the panic happens as normal. If the instance of runtime.EarlyReturn is later passed to panic, then it works as though returnFrom had been called.
If returnFrom is called in a deferred function while the current goroutine is panicking (either with an un-recovered panic, or another returnFrom) it does not do an early return, but instead continues panicking as though you'd run panic(recover()).

What would change in the language spec?
A new section under Builtins
Return from
The built in function returnFrom(label, ...args) takes the name of a function as the first argument and the remaining arguments correspond to the return values of that function. returnFrom can be called in two places: within a nested function literal defined inside a function named label, or in a function literal in the argument list of a call to a function named label.
When returnFrom(label, …) is called, it creates an instance of runtime.EarlyReturn that identifies which function call to return from and with what values, and then calls panic() with the instance of runtime.EarlyReturn.
When panic() is called with an instance of runtime.EarlyReturn it runs all deferred functions on the current stack that were added after the function call, and then acts as though return …args was run in fn immediately returning to the caller of fn. If any of those deferred functions calls recover() then the panic is aborted, and execution resumes as it normally would. If returnFrom is called in a deferred function while the current goroutine is panicking, it instead resumes stack unwinding with the current panic.

Please also describe the change informally, as in a class teaching Go.
When using loops you can use break or return to exit early. When using nested functions use returnFrom instead.
If you are implementing a function that accepts a callback, then you must be aware that it could panic() or returnFrom(). As such, any cleanup that must happen after you run the callback should be scheduled using a defer statement.

Is this change backward compatible?
Yes

Orthogonality: how does this change interact or overlap with existing features?
This feature iteracts heavily with panic() and recover(), and introduces a new case for functions that defer a call recover() across a user-provided callback to consider. In most cases this will not be an issue as code should not swallow unexpected panics; though it could exacerbate a problem if this is not the case (e.g. encoding/json before 2017).
This feature also interacts heavily with iteration. Although not in scope for this proposal, an obvious extension would be to allow for x := range collection loops if collection implements either
 type Ranger[T any] interface { Range(f func(T)) }
 type Ranger2[T, U any] interface { Range(f func(T, U) }

The compiler would convert break/return statements within the loop to calls to returnFrom() as appropriate.
Given that, I considered proposing that the syntax was break fn, ...retArgs; but I think that is more confusing in the case you're trying to return from the current function, and it is less obvious that this feature interacts with panic() and recover().
This feature also interacts with defer as it introduces a new way for deferred functions to set the return arguments of the enclosing function. Instead of using named arguments, code can now just use returnFrom(enclosingFn, ...retArgs).
This feature also interacts with function literals. Currently in go it is not possible to name function literals; and this proposal does not suggest changing that. This means that returnFrom will not be able to return from an enclosing function literal directly. I don't think this is likely to be a problem in practice, as if you want to name a function you can move it's definition to the top level.
func badExample() {
  func notSupported() { ... }
}

Is the goal of this change a performance improvement?
No.

If so, what quantifiable improvement should we expect?
How would we measure it?

Costs

Would this change make Go easier or harder to learn, and why?
Harder, it adds surface area to the language. Although the behaviour is easy to describe in the common case, it is still more than not having it.

What is the cost of this proposal? (Every language change has a cost).
The primary cost is an additional powerful keyword that programmers are unlikely to have encountered before. That said, it worked for go statements :).

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
All tools would need to learn about the new builtin. As the syntax resembles a function call (albeit one that handles the first argument specially), and the semantics resemble a panic() (control flow is aborted) I think the changes would be minor. Generics may complicate things, as this would be a place you're allowed to "pass" a generic function with no type parameter.
Go vet could be updated to add handling for obviously broken calls to returnFrom as discussed below.

What is the compile time cost?
The compiler must identify which calls can be returned from early, and ensure that there's a mechanism to do that. This would need two parts: one to identify which stack frame to unwind to, likely by inserting a unique value onto the stack in a known place in the frame; and secondly a mechanism to resume execution at that point; possibly with a code trampoline.
As any modifications are scoped within a single function, this change would not slow down linking, or require changes to functions that do not lexically enclose returnFrom() statements.

What is the run time cost?
I would imagine that it has similar performance to a panic/defer, as the stack must be unwound explicitly instead of using normal returns.

Can you describe a possible implementation?
To identify which call returnFrom targets, stack-frames that may be targetted by returnFrom will need a unique identifier. I had initially hoped to reuse the frame pointer, but that may not be sufficient as a given frame pointer may be re-used for later calls after the current call has returned. The combination of a frame pointer and a per-goroutine counter value stored at a known offset in the frame should be sufficient.
To actually implement returnFrom it may be necessary to add a small trampoline, either at the end of the function if the enclosed function is identified; or after the function call if a function call is identified, that copies the values passed to returnFrom into the right place. That said, if go's scheduler is able to resume a goroutine at any point, it may be possible to set up the state of the stack and registers and then just jump back into the existing code.

Do you have a prototype? (This is not required.)

Yes, I have implemented a version of this by syntax rewriting at https://github.com/ConradIrwin/return-from
Examples
To help understand how this could work:
// OK, returning from named enclosing function
// f() == 10
func f() int {
  func () { returnFrom(f, 10) }()
  return 5
}

// OK, returning from enclosing function call
func f(s []int) {
  slices.Range(s, func (i int) { returnFrom(slices.Range) })
}

// OK, returning from (doubly) nested enclosing function call
func f(s []int) {
  slices.Range(s, func (i int) {
    inTransaction(func () { returnFrom(slices.Range) })
  })
}

// OK, returning from a enclosing instance method
func (s *T) f () {
    func () { returnFrom(s.f) }()
}

// OK, showing why panic/recover can be helpful
// f() == 10
func f() int {
  c := make(chan interface{})
  go func () {
    defer func () { c <- recover() }()
    returnFrom(f, 10)
  }()
  panic(<-c)
}

// OK, showing how it can be used with defer
// f() == 10
func f() int {
  defer func () { returnFrom(f, 10) }()
  return 5
}

// OK, showing how it could be used with function pointers
// f() == 10
func f() int {
    g := func() { returnFrom(f, 10) }
    g()
    return 5
}

// compile time error, f does not enclose returnFrom(f)
func f() { }
func g() { returnFrom(f) }

// compile time error, nested is a function pointer (not a named function)
func f() {
  nested := func () { func () { returnFrom(nested) }() }
}

// unhandled panic, could be added to go vet
func f() func() {
  return func() { returnFrom(f) }
}
f()()

// unhandled panic, could be added to go vet
func f() {
  go func () { returnFrom(f) }()
}
f()

// unhandled panic, the call to f(true) is over before f(false) calls the callback
func f(a bool) func() {
  if a {
    return func() { returnFrom(f, func() { }) }
  }
  f(true)()
  return func() { }
}
f(false)

// OK, but may be confusing, the first argument to returnFrom
// identifies the call to the function nested; not the function
// pointed to by the variable called nested.
func f() {
   nested := func(f func()) { f() }
   nested2 := func (f func()) { }
   nested(func () { nested = nested2; returnFrom(nested) })
}
f()

// OK, example of showing why returnFrom() ignores subsequent different calls.
func wrapper(fn func()) int {
    defer func() { returnFrom(wrapper, 5) }()
    fn()
}
func f() {
  x := wrapper(func () {
      returnFrom(wrapper, 10)
  })
  fmt.Println(x == 10)
}

It's quite common in Go to have anonymous function literals.
    f := func() { returnFrom(f) }

What happens if the label is ambiguous, due to a recursive call?  Do we return from the innermost instance?  That seems potentially quite confusing.
In general the notion of labelling a function call by naming the function being called seems confusing and non-orthogonal.  What about variables of function type?  Recall that Go explicitly does not permit using == on values of function type.

Thanks for taking the time to read through this!
I don't think returnFrom would work with anonymous function literals. Two further tweaks to the language that could make this better would either be: 1) allow nesting function statements within functions; or 2) use the same approach as javascript where assignment to a variable implicitly names functions (so the code you wrote would work).
For recursive functions I think the inner-most call would be the most obvious choice (it seems possible to further extend returnFrom(label) to allow labelled calls, but when I was writing up the proposal it seemed like it would add even more complexity for not that much reason).
function f () {
  outer: slices.Range(s, func () {
    slices.Range(r, func () {
      returnFrom(outer)
    })
  })
}

Definitely agree that naming a function call can be confusing (it looks like you are passing a function, but you aren't); but requiring every function call to be labelled seemed not great either...

From reading the proposal I understand this as more-or-less some syntactic sugar over panic and recover, where the panic call is replaced with a returnFrom call, and the recover call is implicit in some hidden generated code at the call site of the function.
Do you anticipate that every function call would generate code to approximate the effect of calling recover() and returning early if it returns a runtime.EarlyReturn instance? Or do you imagine the compiler quietly "coloring" all functions to record whether they contain a (direct or indirect) returnFrom so that it can generate the additional code only where a downstream caller (direct or indirect) makes use of this facility?
The details of how runtime.EarlyReturn would be defined aren't clear to me:

When returnFrom(label, …) is called, it creates an instance of runtime.EarlyReturn that identifies which function call to return from and with what values, and then calls panic() with the instance of runtime.EarlyReturn.

This suggests that there are two fields of this type: some sort of identifier for the function, and some return values. Your definition of label suggests that the compiler would search up the enclosing functions lexically until it finds one of the given name. Discussion above already considered how that would interact with anonymous functions, but I wonder also about generic functions: if I have a func Example[T](), would I need to returnFrom(label[SomeType], ...), or would returnFrom(label, ...) match any instantiation of that generic function?
I'm also curious about the subsequent arguments representing return values. If the compiler knows from the first argument exactly which function we're returning from then I suppose it can statically check that there's the appropriate number of additional arguments and that they are assignable to the function's return types, in which case we wouldn't need to consider the situation where the types mismatch at runtime. In the implementation details, is there a field inside runtime.EarlyReturn of type []any that captures the return values as interface values? Or do you imagine the compiler generating an anonymous hidden type per function which captures directly its return values?

Stepping away from the implementation and into the programmer-visible effect, it seems like a key consideration of this proposal is that now any function call can potentially be an early return. That is admittedly already true in the presence of panic, but we ask Go programmers to understand that only as an exceptional return path used in "should never happen" cases where code is somehow buggy, and consequently that pattern is not commonly used for happy-path control flow.
I have some difficult-to-substantiate concerns about that situation. I personally currently use panic only with the intention of intentionally crashing the program, and so when I'm writing happy-path code I'm accustomed to considering only the locally-visible control flow. I can see that, due to the restriction of lexical nesting, this is restricted to situations that could also be described using goto, break, and continue within a single named function. In those cases however we do explicitly label the places where control flow might arrive, which then serves as a prompt to the reader that something special is going on. If the intent here is to support a sort of "cross-function goto" (so that function calls can behave as loops) then I think I'd lean towards your later variant of explicitly labeling the calls, so that there's at least an explicit mark at the call site that something unusual is happening.
If you haven't seen it already, it might interest you that there's an active discussion about defining a standard iterator interface that might integrate with for ... range: https://github.com/golang/go/discussions/54245.

Do you anticipate that every function call would generate code to approximate the effect of calling recover() and returning early if it returns a runtime.EarlyReturn instance? Or do you imagine the compiler quietly "coloring" all functions to record whether they contain a (direct or indirect) returnFrom so that it can generate the additional code only where a downstream caller (direct or indirect) makes use of this facility?

No, I expect only calls that are statically determined to need it will get it (because we're re-using panic/recover this is determinable by looking lexically locally; there's no need for this information to move between compilation units).

This suggests that there are two fields of this type: some sort of identifier for the function, and some return values. Your definition of label suggests that the compiler would search up the enclosing functions lexically until it finds one of the given name. Discussion above already considered how that would interact with anonymous functions, but I wonder also about generic functions: if I have a func ExampleT, would I need to returnFrom(label[SomeType], ...), or would returnFrom(label, ...) match any instantiation of that generic function?

Either way; one of the reasons the prototype doesn't work well with generics right now is exactly this ambiguity. As a user of the feature, I'd prefer to use returnFrom(label), but we could also make returnFrom(label[SomeType]) work.

I'm also curious about the subsequent arguments representing return values. If the compiler knows from the first argument exactly which function we're returning from then I suppose it can statically check that there's the appropriate number of additional arguments and that they are assignable to the function's return types, in which case we wouldn't need to consider the situation where the types mismatch at runtime. In the implementation details, is there a field inside runtime.EarlyReturn of type []any that captures the return values as interface values? Or do you imagine the compiler generating an anonymous hidden type per function which captures directly its return values?

In the prototype version this is a hidden type per call-site; I imagine it depends what's easiest to compile, but I agree there will be no runtime-type mismatches as the compiler will check.

I have some difficult-to-substantiate concerns about that situation. I personally currently use panic only with the intention of intentionally crashing the program, and so when I'm writing happy-path code I'm accustomed to considering only the locally-visible control flow. I can see that, due to the restriction of lexical nesting, this is restricted to situations that could also be described using goto, break, and continue within a single named function. In those cases however we do explicitly label the places where control flow might arrive, which then serves as a prompt to the reader that something special is going on. If the intent here is to support a sort of "cross-function goto" (so that function calls can behave as loops) then I think I'd lean towards your later variant of explicitly labeling the calls, so that there's at least an explicit mark at the call site that something unusual is happening.

Yeah; there's some discussion related to this on making errgroup "panic-safe". In general one thing that go is not good at is expectations around panics() (other than that they might crash your program). In the kind of code I write, I think it's important that even unhandled programmer errors do not terminate programs (one web request shouldn't be able to kill others in flight for example), so I am careful that panics are handled appropriately and error logging is tied to the request that was made. This is not uniformly how the go community works (I've heard people express the ideal that panics should always cause programs to exit), so there's some tension there. It gets particularly gnarly when using go-routines, but we have internal libraries that let you start a new goroutine and ensures that panics are propagated correctly.

If you haven't seen it already, it might interest you that there's an active discussion about defining a standard iterator interface that might integrate with for ... range: https://github.com/golang/go/discussions/54245.

Thanks for the pointer! I'll wade in in a bit – in general (as described in this proposal) I find the idea of an iterator interface described there to be a bit backwards. It may let you make the syntax on the consumer side shorter in the common case, but it puts a lot of burden on the implementor to do things right; I think the iterator proposal from https://github.com/golang/go/issues/47707 makes a lot more sense, and if we had returnFrom too it would be easier for implementors and consumers alike.

It seems very difficult to make this fully orthogonal.  Consider
func F() func() {
    return func() { returnFrom(F) }
}

func G() {
    f := F()
    f() // what happens here?
}

As written right now it would panic at runtime: "panic: call to returnFrom(F) outside of F" (or similar). I'd expect go vet to catch this case as there is no call to the function from within F (though there may be more subtle variations that are harder to catch statically).
Similarly to a send/recv on a closed channel; trying to return from a function that has already returned is a programmer error.

OK, but what we aim for in Go is that, as much as possible, language features simply work.  That's why, for example, it's fine (today) to return a function closure out of a function.
Consider also code like this:
var C1 = make(chan func())
var C2 = make(chan bool)

func F() {
    go G()
    C1 <- func() { returnFrom(F) }
    <-C2
}

func G() {
    f := <-C1
    f()
    C2 <- true
}

What happens here?  Presumably F doesn't return twice.

Thank you for continuing to explore the ideas here with me!
Your example would also panic with "panic: call to returnFrom(F) outside of F".
G is running on a different goroutine, so when returnFrom unwinds the stack (it's implemented as a panic under the hood) it will not find the call to F on the stack and will terminate the program with an unhandled panic.
I think this is "as much as possible, the feature just works" – it doesn't make sense to allow a function call to return more than once. There's definitely an editorial question of whether the benefits brought by the feature make up for the confusion – but that's why this is a proposal not a pull request after all :D.
As mentioned in the proposal I think the benefits are surprisingly far reaching for a comparatively small language change:

You can have functions like a generic func Map[A,B any](a []A, func (A) B) b []B and have a consistent mechanism to stop iteration if an error occurs (without needing an additional func MapErr[A, B any](a []A, func (A) (B, error)) (b []B, error))
You can implement an iterator proposal like #47707 (but better because there's less chance the iterator forgets to handle the boolean return)
You can clarify editing the surrounding functions return values in a deferred func (maybe a taste thing, but assigning to named return values still reads a bit odd after many years of using go)

One example from nested in the proposal that is related to the example you just gave, it is possible (with the proposal as written currently) to do some amount of go-routine work, for example (if contrived):
// f() == 10
func f() int {
  c := make(chan interface{})
  go func () {
    defer func () { c <- recover() }()
    returnFrom(f, 10)
  }()
  panic(<-c)
  return 5
}

it will not find the call to F on the stack

I don't understand how to implement that in the general case.

Sorry about that, it took a while to think through, and I'm not sure I'm explaining it clearly.
In order for returnFrom to work you need a way to identify a particular stack-frame. There are two cases to consider:

When F identifies  an enclosing function literal
func F() { func () { returnFrom(F) } }
When G identifies an enclosing function call
func F() { G(func () { returnFrom(G) } }

In both cases the stack-frame we need to identify is the stack-frame created by the call to F that was active when the nested function literal (which contains returnFrom()) was evaluated. returnFrom will unwind the stack until it encounters that frame, and then either (in the case of returnFrom(F)) start returning from the function; or (in the case of returnFrom(G)) will resume execution in that frame after the call to G.
The simplest approach to identifying stack frames is a global counter, but that is not ideal because you have to make all access to that counter atomic. A slightly more lock friendly version (proposed above) would be to use a counter attached to the current go-routine, as a go-routine can (presumably) not race with itself no locks are needed.
Using syntax rewriting as a way to try and explain this, if you start with a function that has an early return inside it:
func F() {
  func () {
    returnFrom(F)
  }()
}

You end up compiling something that behaves like:
func F() {
  g := runtime.getg()
  gid := g.goid
  frame := g.returnFromCounter++

  defer func () {
    r := recover()
    if y, ok := r.(*runtime.EarlyReturn); ok && y.gid == gid && y.frame == frame {
      // handle early return
    } else {
      panic(r)
    }
  }()

  func () {
    panic(runtime.EarlyReturn{g, frame}) // returnFrom(F)
  }()
}

Handling the second case is a little trickier to demonstrate as it can't be expressed easily using the current semantics of defer; but you can use the same mechanism to identify the correct frame, but then resume execution at the right point instead of returning.
In the prototype I resolved the problem by adding an intermediate function and then using the first case solution on that, so I'm convinced that it is possible to implement it (and also convinced that this is not the most efficient way!)
func F() {
 G(func () { returnFrom(G) })
 fmt.Print("a")
}

// is equivalent to:

func F() {
  tmp1()
  fmt.Print("a")
}

func tmp1() {
  G(func () { returnFrom(tmp1) })
}

In reality I don't think an implementation in the runtime would need to add extra functions, a better solution would be to customize how stack unwinding works so you're not restricted by the current semantics of defer.
The other subtle point to reinforce is that it is always possible to statically identify which frames may targeted by returnFrom() – in the case of func F () { G(func () { returnFrom(G) }) }, the frame to identify is the one created by the call to F. This has two nice properties: the implementation of G does not need to care about returnFrom (from its perspective it's just the same as a panic); and the returnFromCounter only needs to be incremented in frames that may be targeted.
I hope that answers the question, and please let me know if I can clarify further.

OK, thanks.
I still don't see this as being particularly orthogonal, but I believe that it could be implemented.
Another issue that comes to mind is code like
func F() int {
    fns := []func() {
        func() { returnFrom(fns[0], 0) },
        func() { returnFrom(fns[1], 1) },
    }
    fns[0], fns[1] = fns[1], fns[0]
    fns[0]()
    return 2
}

I want to be clear that I'm poking at the concept, but personally I think it's very unlikely that we will add this to the language.  I think there are too many oddities about it, and it doesn't seem to add any functionality that is not already available via panic and recover.

Based on the discussion above, and the emoji voting, this seems like a likely decline.
Leaving open for four weeks for final comments.
-- for @golang/proposal-review

No further comments.


Update reportedLevels prior to monitoring bits

This patch allows reportedLevel to be in sync with pin states just prior to starting alert notifications.  In my testing this seems to only be a problem in the first minute from starting the pigpio daemon - perhaps because the keep-alive packets have started the monitoring of pin levels.
The change seems innocuous but it would be appreciated if you could run a regression test to make sure it doesn't break anything.  I didn't provide a test script to validate results before and after applying the patch as it isn't easily extracted from my project.  I'll do so if you require a script before accepting this PR.

I have no problems with this. It is in my local git. Not sure when I'll get time to complete the other needed changes.


Different icons for each collapsible-item.

I need put different icons for each collapsible-item. Do you have any idea as i make this? Currently it's possible?

Currently its not possible, cause this is specified in the parent of all items. To be able to specify it for each item, you can move this param to the collapsible items and use its value in rendering.


GDExtension/SurfaceTool crash on commit.

 I don't know if this is a problem with Ref, with the bridge or with SurfaceTool itself. It sounds a little similar to https://github.com/godotengine/godot/issues/53191 but seems to be distinct.
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.alpha.custom_build (9904a9db5a90f2f1896b6b7e1603ca2dd2745bad)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
[1] 1   libsystem_platform.dylib            0x00000001862c34a4 _sigtramp + 56
[2] godot::SurfaceTool::commit(godot::Ref<godot::ArrayMesh> const&, unsigned int)
[3] godot::SurfaceTool::commit(godot::Ref<godot::ArrayMesh> const&, unsigned int)
[4] Game::Ground::_ready()
[5] void godot::call_with_ptr_args_helper<Game::Ground>(Game::Ground*, void (Game::Ground::*)(), void* const*, IndexSequence<>)
[6] void godot::call_with_ptr_args<Game::Ground>(Game::Ground*, void (Game::Ground::*)(), void* const*, void*)
[7] void godot::Node::register_virtuals<Game::Ground>()::'lambda0'(void*, void* const*, void*)::operator()(void*, void* const*, void*) const
[8] void godot::Node::register_virtuals<Game::Ground>()::'lambda0'(void*, void* const*, void*)::__invoke(void*, void* const*, void*)

or
Process 34791 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
    frame #0: 0x000000012b60a12c libresort.osx.debug`godot::ArrayMesh* godot::internal::_call_native_mb_ret_obj<godot::ArrayMesh, void*, long long*>(mb=0x000000014a92c840, instance=0x000000014ab5ab80, args=0x0000000000000008, args=0x000000016fdfc8d0) at engine_ptrcall.hpp:49:90 [opt]
   46   template <class O, class... Args>
   47   O *_call_native_mb_ret_obj(const GDNativeMethodBindPtr mb, void *instance, const Args &...args) {
   48           GodotObject *ret = nullptr;
-> 49           std::array<const GDNativeTypePtr, sizeof...(Args)> mb_args = { { (const GDNativeTypePtr)args... } };
   50           internal::gdn_interface->object_method_bind_ptrcall(mb, instance, mb_args.data(), &ret);
   51           if (ret == nullptr) {
   52                   return nullptr;
Target 0: (Godot) stopped.
Process 34791 launched: '/Users/me/devel/godot/Godot.app/Contents/MacOS/Godot' (arm64)
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
  * frame #0: 0x000000012b60a12c libresort.osx.debug`godot::ArrayMesh* godot::internal::_call_native_mb_ret_obj<godot::ArrayMesh, void*, long long*>(mb=0x000000014a92c840, instance=0x000000014ab5ab80, args=0x0000000000000008, args=0x000000016fdfc8d0) at engine_ptrcall.hpp:49:90 [opt]
    frame #1: 0x000000012b609fd8 libresort.osx.debug`godot::SurfaceTool::commit(this=<unavailable>, existing=<unavailable>, flags=<unavailable>) at surface_tool.cpp:257:49 [opt]

depending on your preferred backtrace style.
Steps to reproduce
In _ready on a class inheriting MeshInstance3D, created with auto ground = memnew(Ground()); and inserted into the tree with parentForScenes->call_deferred("add_child", ground);
    godot::Ref<godot::SurfaceTool> surfaceTool;
    surfaceTool.instantiate();

    surfaceTool->begin(godot::Mesh::PRIMITIVE_TRIANGLES);
//    ...assorted times...
    surfaceTool->add_vertex(godot::Vector3(x * cellSize_ + xOffset_, z * cellSize_ + yOffset_, y * cellSize_ + zOffset_));
//    etc.

    surfaceTool->add_index(topLeftIndex(x, y));
    surfaceTool->add_index(topRightIndex(x, y));
    surfaceTool->add_index(midIndex(x, y));
//    etc.

    surfaceTool->generate_normals();
    set_mesh(surfaceTool->commit());

It only crashes if I use the return style, rather than passing in a mesh. The following does not crash
    surfaceTool->generate_normals();
    godot::Ref<godot::ArrayMesh> arrayMesh;
    arrayMesh.instantiate();
    surfaceTool->commit(arrayMesh); // Crash here
    set_mesh(arrayMesh);

Minimal reproduction project
No response

Apologies, a screwup on my side meant I was running old code.
It only crashes if I use the return style, not if I use the pass style.
i.e.
set_mesh(surfaceTool->commit());

crashes and
    godot::Ref<godot::ArrayMesh> arrayMesh;
    arrayMesh.instantiate();
    surfaceTool->commit(arrayMesh);
    set_mesh(arrayMesh);

does not. Possibly lending weight to Zylann's theory on Discord that this could be down to Ref being freed early through the bridge.

The following happens:

Calling surfaceTool->commit() creates a Ref<ArrayMesh> with an internal nullptr as reference.

Ref<ArrayMesh> commit(const Ref<ArrayMesh> &existing = nullptr, uint32_t flags = 0);

Variable existing of type Ref<ArrayMesh> contains (as said before) a nullptr but is still being accessed by existing->_owner.  operator()-> is overriden in class Ref<> and returns the internal pointer (variable reference) which is a nullptr.
So this is simply a nullpointer access. In step 3 it will finally crash.

Ref<ArrayMesh> SurfaceTool::commit(const Ref<ArrayMesh> &existing, uint32_t flags) {
	static GDNativeMethodBindPtr ___method_bind = internal::gdn_interface->classdb_get_method_bind("SurfaceTool", "commit",<PHONE_NUMBER>);
	CHECK_METHOD_BIND_RET(___method_bind, Ref<ArrayMesh>());
	int64_t flags_encoded;
	PtrToArg<int64_t>::encode(flags, &flags_encoded);
	return Ref<ArrayMesh>::___internal_constructor(internal::_call_native_mb_ret_obj<ArrayMesh>(___method_bind, _owner, existing->_owner, &flags_encoded));
}

Now call_native_mb_ret_obj<ArrayMesh>(...) is called. The std::array creation leads to a segmentation fault.

template <class O, class... Args>
O *_call_native_mb_ret_obj(const GDNativeMethodBindPtr mb, void *instance, const Args &...args) {
	GodotObject *ret = nullptr;
	std::array<const GDNativeTypePtr, sizeof...(Args)> mb_args = { { (const GDNativeTypePtr)args... } };
	internal::gdn_interface->object_method_bind_ptrcall(mb, instance, mb_args.data(), &ret);
	if (ret == nullptr) {
		return nullptr;
	}
	return reinterpret_cast<O *>(internal::gdn_interface->object_get_instance_binding(ret, internal::token, &O::___binding_callbacks));
}

Solution (for engine devs):
In step 2 has to be a nullpointer check on the internal reference of variable existing. If the internal pointer is null, then avoid the operator->() access and pass a null pointer.
Something like: existing.is_valid() ? existing->_owner : nullptr)
As far as I have seen, this also affects other functions that work with default arguments.

Can you still reproduce this in 4.0.3 and 4.1-beta3 or later?

Can you still reproduce this in 4.0.3 and 4.1-beta3 or later?

Yes, can still reproduce this issue with Godot 4.2.1-stable (Arch Linux) in combination with Rust/Gdext.
Not (yet) tested with GDScript or C++.


XAML example incorrect

There are two issues with the XAML.

The line

xmlns:behaviors="using:Microsoft.Toolkit.Uwp.UI.Animations.Behaviors"/>
should be
xmlns:behaviors="using:Microsoft.Toolkit.Uwp.UI.Animations.Behaviors">

The line

</behaviors:Rotate>
should be deleted.

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

ID: 7f216015-9d2e-c0e3-1e40-297c54e39400
Version Independent ID: ff8da80d-57ee-c069-2673-b912e0413e0f
Content: Rotate animation behavior - Windows Community Toolkit
Content Source: docs/animations/Rotate.md
Product: community-toolkit
GitHub Login: @nmetulev
Microsoft Alias: nikolame

Thanks @GrantMeStrength. Feel free to open a PR to fix these in the meantime

I will!
From: Nikola Metulev<EMAIL_ADDRESS>Reply-To: MicrosoftDocs/WindowsCommunityToolkitDocs<EMAIL_ADDRESS>Date: Tuesday, November 6, 2018 at 2:34 PM
To: MicrosoftDocs/WindowsCommunityToolkitDocs<EMAIL_ADDRESS>Cc: John Kennedy<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/WindowsCommunityToolkitDocs] XAML example incorrect (#145)
Thanks @GrantMeStrengthhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGrantMeStrength&data=02|01|jken%40microsoft.com|9fd8704aad464af68aeb08d64438071d|72f988bf86f141af91ab2d7cd011db47|1|0|636771404763796091&sdata=cDXrO40RQwDKN19vGTI2I8Q%2F0kdYrMc2KmamPV99jLM%3D&reserved=0. Feel free to open a PR to fix these in the meantime
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2FWindowsCommunityToolkitDocs%2Fissues%2F145%23issuecomment-436434114&data=02|01|jken%40microsoft.com|9fd8704aad464af68aeb08d64438071d|72f988bf86f141af91ab2d7cd011db47|1|0|636771404763796091&sdata=FjRmh6AYB4qIn3w60MHLM4EUiu%2FK70Mgtszm%2Bv9SvI0%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB1ul1yQgHcJsNLahtPgIJw0DGAiDXxcks5usg56gaJpZM4YRQOh&data=02|01|jken%40microsoft.com|9fd8704aad464af68aeb08d64438071d|72f988bf86f141af91ab2d7cd011db47|1|0|636771404763806096&sdata=pdd%2FujaL61eIsnUwKTDqTl1Fv8CzTwyIbwb%2BIx%2Fa9ew%3D&reserved=0.


older versions of tail don't support the -F flag

C:\wildfly\domain\servers\xyz\log>frontail .\server.log
tail: invalid option -- F
Try `tail --help' for more information.

C:\wildfly\domain\servers\claire1\log>tail --version
tail (GNU textutils) 2.0
Written by Paul Rubin, David MacKenzie, Ian Lance Taylor, and Jim Meyering.

Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

From the newer, v2.1 tail docs:
Mandatory  arguments  to	 long  options are mandatory for short options
       too.

       --retry
	      keep trying to open a file even if it is inaccessible when  tail
	      starts  or if it becomes inaccessible later; useful when follow-
	      ing by name, i.e., with --follow=name

       -c, --bytes=N
	      output the last N bytes

       -f, --follow[={name|descriptor}]
	      output appended data as the file grows; -f, --follow, and --fol-
	      low=descriptor are equivalent

       -F     same as --follow=name --retry

Recommendation is to use --follow=name --retry vice -F to support these versions, if practicable.

I guess that this is some kind of tails version for Windows, isn't it?

Well, I generally don't want to do something specific for Windows and instead of that I'm planning to remove dependency to system binary and use node tail implementation. It's reported https://github.com/mthenw/frontail/issues/38.

FYI, for anyone with this issue I installed Git for Windows 2.5.2 with the installer option to include Unix tools on my path and it seems to include a newer tail that supports -F.

Thanks @ChristianWilkie :)


Update jquery and nodejs

This is a manual cherry-pick of #24304
This updates the nodejs and jquery versions used in bookinfo. This is the master version of #24289
1.4, 1.5, and 1.6 are all based on bookinfo 1.15.0. Master advances to 1.16.0.
Testing done:
Manually tested that all three star versions show up when viewing the website
make test passes
No errors in the browser console.
Note that many tests expect the bookinfo images to already exist and the images do not get built in the pull request process.
This fixes:
NodeJS

CVE-2019-15606: HTTP header values do not have trailing OWS trimmed.
CVE-2019-15605: HTTP request smuggling using malformed Transfer-Encoding header.
CVE-2019-15604: Remotely trigger an assertion on a TLS server with a malformed certificate string.
CVE-2020-11080: HTTP/2 Large Settings Frame DoS
CVE-2020-10531: ICU-20958 Prevent SEGV_MAPERR in append
CVE-2020-81720: TLS session reuse can lead to host certificate verification bypass

jQuery

CVE-2016-9251 jQuery before 3.0.0 is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain Ajax request is performed without the dataType option, causing text/javascript responses to be executed.
CVE-2019-11358 jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable proto property, it could extend the native Object.prototype.
CVE-2020-11022: Potential XSS vulnerability in jQuery
CVE-2020-8174: napi_get_value_string_*() allows various kinds of memory corruption

@brian-avery: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-tests_istio_release-1.6
46c5f782430abc8878bc28aa9bd115e4624a8ae7
link
/test integ-mixer-k8s-tests_istio_release-1.6

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@brian-avery: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-tests_istio_release-1.6
46c5f782430abc8878bc28aa9bd115e4624a8ae7
link
/test integ-mixer-k8s-tests_istio_release-1.6

integ-telemetry-k8s-tests_istio_release-1.6
46c5f782430abc8878bc28aa9bd115e4624a8ae7
link
/test integ-telemetry-k8s-tests_istio_release-1.6

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

In response to a cherrypick label: new pull request created: #24406

In response to a cherrypick label: new pull request created: #24407


java.nio.file.FileSystemException: D:<path-to-project>.gogradle\project_gopath\src<package-name>: A required privilege is not held by the client.

My OS is Windows 10. Project files are on drive D: (system drive - C:)
I'm getting this exception:
java.nio.file.FileSystemException: D:\<path-to-project>\.gogradle\project_gopath\src\<package-name>: A required privilege is not held by the client.
	at com.github.blindpirate.gogradle.build.DefaultBuildManager.createSymbolicLink(DefaultBuildManager.java:132)

I've heart smth about UAC, but my system admin forbided security changes.

Gogradle will make a symbolic link in project directory and treat it as project-level GOPATH, it seems your OS security strategy forbids to do this. So you have two choice:

Give it the privilege. See https://stackoverflow.com/questions/23217460/how-to-create-soft-symbolic-link-using-java-nio-files.

Try to use a global GOPATH in canonical way.

I would close this issue. Hope you've already solved it.


Devcontainer

Features

Devcontainer Setup
Emulator update (run_drcf , install_emulator shell)
fix servo off

@song-ms


Resolution problem

Microsoft PowerToys version
0.65.0
Installation method
Microsoft Store
Running as admin
Yes
Area(s) with issue?
PowerRename
Steps to reproduce
The default size of the PowerRename was so big . In an low-res screen ( 1360 * 768 ) , it was too large to display on my screen . Although I set it to a smaller size manually , It will return to the default size when it restart .

I could not close it or do something like this except from taskbar .
✔ Expected Behavior
I hope it could remember the size that I set manully .
❌ Actual Behavior
It will return to the default resolution when restart .
Other Software
No response

cc: @niels9001

/dup https://github.com/microsoft/PowerToys/issues/19700


How do we send data to another State when activating it?

Consider two states StateA and StateB. StateA has a transition inside which a method mA1 is executed and it produces some object o1. After, mA1 is executed, we set the current state to StateB. On entering StateB, we need to call another method mA2 with the previously produced object o1.
How do I achieve this? I think this can be achieved using Streams, but is that the best solution?

This library doesn't enforce a specific way to model or pass data.
The most strait-forward way would be if you stored the object in a variable that both handlers have access to.
A more generic way would be to use custom state objects, and use a transition handler to propagate the value from the previous state to the next one.

Can you please give me an example of the transition handler approach?

class Data {
  String? input;
  String? output;
}

void main() {
  final machine = Machine<Data>();
  machine.onBeforeTransition.forEach((event) =>
      event.target?.identifier.input = event.source?.identifier.output);

  final stateA = machine.newState(Data());
  final stateB = machine.newState(Data());

  stateA.enter();
  stateA.identifier.output = 'Hello';

  stateB.enter();
  print(stateB.identifier.input); // Prints 'Hello'
}

What do you think about state.enter() accepting an argument? Something along these lines,
State<Data, Custom?> stateA = machine.newState<Custom?>();
Custom? customObject;
stateA.enter(customObject);

That sounds like a useful idea, if the typing doesn't get too messy. I have to think about this a bit more.

State<I, C> where I is the type for the identifier (present today), and C is the type of the context (or mutable data).

Adding C per State would make the API really ugly. At many places where the type would not know the return value would be State<I, dynamic>.

Adding C per Machine would make the API slightly less ugly, but much more restrictive. Probably not useful to force all states have the same context?

In either case the API would not be backward compatible (adding a generic type is breaking this).

I agree that this would be not backwards compatible. Adding C per State would make the API more useful, but like you said, things like machine.current would have to return State<I, dynamic> which kind of defeats the purpose.


Independent Component Analysis (ICA)

This PR is for the port of sklearn's FastICA.

lets merge this then :tada: the failure is unrelated to fastica, will fix this in a separate commit


Video analysis flops question.

Hi, thanks for your great work.
I have some questions about the vit flops.
If I have a image with vit encoder flops "im_flops", what is the video encoder vit flops with same resolution but 10 frames?
Is it 100im_flops or 10 im_flops.

@Yao990x16 @yangapku @JialinWangPKU