Storing objects (non-string things) in TempDataDictionary does not round trip correctly

Scenario
public class FeedbackController : Controller
{
    private const string _userKey = "user-data";

    [HttpPost]
    public IActionResult SubmitApplication(string name, int age)
    {
        // Do db stuff
        var user = new User { Id = 100, Name = name, Age = age };
        TempData[_userKey] = user;
        return RedirectToAction("WelcomeUser");
    }

    public string WelcomeUser()
    {
        var user = (User)TempData[_userKey];
        return "Welcome " + user.Name;
    }
}

Expected (per behavior in Mvc 5)
Ouputs Hello {userName}
Actual
Unable to cast object of type 'Newtonsoft.Json.Linq.JObject' to type 'User'.

It looks like we Json serialize values in TempDataDictionary as opposed to using binary serialization in Mvc 5. Consequently complex types don't deserialize correctly. Perhaps we should consider disallowing storing non-primitive value types + strings in our default implementation if the (totally reasonable) intention is to avoid binary serialization.

Minor note: In-memory session state is simply holding on to the object in memory, not serializing them. Consequently, you can store objects that cannot be deserialized in it
public class User
{
   public User(int id) {}
   public string Name { get; set; }
}

This is to counter @danroth27's suggestion to use Json.Net's type name handling behavior to serialize types.

@pranavkm Consider restricting to only primitives, dictionaries of primitives and arrays of primitives for now.

I think this was meant to be assigned to @ajaybhargavb. Let's talk about this before you start working on it.

In some early beta it was working as expected
var messages = TempData[PageMessagesKey] as IList<PageMessageModel>;
then in beta4 I had to deserialize objects from TempData like this
var messages = (TempData[PageMessagesKey] as Newtonsoft.Json.Linq.JArray)?.ToObject<List<PageMessageModel>>();
but it was working. And in beta5 it is not working at all. I don't think it's going to the right direction. How can I use TempData to store objects in beta5?

cc @Eilon. Could you respond to @Fido789 on what the suggested approach is if a user wants to stash complex data types?

@Fido789 can you log a new bug with the exact case that isn't working? We can have @ajaybhargavb take a look at that - he's the guy who wrote the codes.

@Eilon, I believe we made a design decision to not support serialization of complex data types by default. We currently throw an exception saying it can't be serialized.

Oh, right. We might still want to document some guidance on this then.

So how would you save complex data types, at least until the request is ended?
Is there any other way to do that without using TempData?

@Muchiachio I believe you can store the data in a dictionary as key/value pairs, and then re-assemble the object on the way out.

No @Eilon, as I understand this was made deliberately
[HttpGet]
public ActionResult Index()
{
    object value = new { Type = "Success", Message = "You got successfully redirected" };
    TempData["messages"] = value;

    return RedirectToAction("New");
}

throws and exception
System.InvalidOperationException
The 'Microsoft.AspNet.Mvc.SessionStateTempDataProvider' cannot serialize
an object of type 'System.Object' to session state.

I would be fine with that, if there is a way to pass these type of objects around without using TempData?

I mean a real Dictionary<string, string> etc.

Or you can do whatever serialization you want and store the data as a string or bytes.

I want to believe it is the worse kind of design. How do we store complex data then? Any alternative?

@she2 the recommendation is to serialize it yourself using a serializer that you know has the correct fidelity. The problem with doing this automatically is that there is no serializer that can serialize completely arbitrary data with full fidelity. And only the person writing the app knows what serializer matches the data structure that needs to be serialized. Once you have a string, you can stash that in the state.


use xorm builder for models.getReviewers()

as title
-> https://github.com/go-gitea/gitea/pull/19030#discussion_r821995716

... this way we could re-use the condition if needed at some point ...
and first and it should dedup code and be better redable

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@c21735b). Click here to learn what that means.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main   #19033   +/-   ##
=======================================
  Coverage        ?   46.60%
=======================================
  Files           ?      854
  Lines           ?   122911
  Branches        ?        0
=======================================
  Hits            ?    57286
  Misses          ?    58706
  Partials        ?     6919

Impacted Files
Coverage Δ

models/repo.go
54.27% <100.00%> (ø)

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 c21735b...cb894d5. Read the comment docs.


Allow PRs to delete files, fix error passing

An effect of #761 was to make PRs fail if they ever deleted a file, no matter where. This means PRs like my PR that deletes scripts fails because deleting files is now banned, which doesn't feel right.
Also, fix a case where errors were not propagated upward, which was the root cause of the tooling hiding the error for the script PR. I think we may want to consider using a real generic result type; working with these error arrays and ensuring they're nonempty is getting a little fickle...

So generally I think that this part of the infra may be overkill:

If someone deletes a package, the tooling needs to check the git diff to inform which packages we run as pnpm won't see the deletion.
If someone modifies another package, it'll trigger owners and the "modifies multiple packages" check.
If someone touches any other file, then it's an infra change and gets maintainer review.

I think this PR improves things, though doesn't remove the complexity, so it's hard to say if I've really fixed it.


Add building and installation instructions to README/Wiki

Should include how to install a novel
How to set up VNDS LOVE
How to build it locally and create a pull request
And some images of it working

Started work on this: development instructions and a high level description should go in the readme, while installation/"user" instructions will be located in the wiki.

Finished with the developer setup. I am thinking of moving the "user guide" to a google doc. The main benefit is that it becomes much easier for anyone to edit, and adding images also becomes easy.
For sharing it, we would use the web published link. That way the output is just a plain html doc/website.

Added all the basic information needed; missing screenshots and in depth tutorials but I don't have enough time to do that :disappointed:


Prep files for next release

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 26.87%. Comparing base (b574682) to head (8da7a55).
Report is 58 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #483      +/-   ##
==========================================
- Coverage   28.59%   26.87%   -1.72%
==========================================
  Files          85       85
  Lines        2301     2396      +95
==========================================
- Hits          658      644      -14
- Misses       1643     1752     +109

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


Abstract product computations

Codecov Report

Merging #46 (b1dc20f) into main (96972e7) will decrease coverage by 0.10%.
The diff coverage is 54.54%.

@@            Coverage Diff             @@
##             main      #46      +/-   ##
==========================================
- Coverage   72.28%   72.17%   -0.11%
==========================================
  Files          21       21
  Lines         765      780      +15
  Branches       63       60       -3
==========================================
+ Hits          553      563      +10
- Misses        202      207       +5
  Partials       10       10

Impacted Files
Coverage Δ

sarsen/geocoding.py
97.29% <ø> (-0.08%)
:arrow_down:

sarsen/apps.py
11.82% <40.00%> (+2.21%)
:arrow_up:

sarsen/datamodel.py
56.81% <45.83%> (-14.62%)
:arrow_down:

sarsen/sentinel1.py
81.18% <69.23%> (-3.35%)
:arrow_down:

sarsen/__init__.py
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


[BUG] Actor Naming does not respect " - "

Describe the bug
Create an actor with a dash in the name, and try to build.
Could not find compiled wasm file to sign: target/wasm32-unknown-unknown/release/actor-name.wasm
To Reproduce
Steps to reproduce the behavior:

Run command wash new actor actor-name -t hello
Run other command wash build
See error

Expected behavior
Wash respects dash in an actor name, and build without needing to change the name in wasmcloud.toml to use an underscore (@jordan-rash discovered this workaround).
Screenshots
If applicable, add screenshots to help explain your problem.
**Environment (please complete the following information) **

OS: Manjaro 22.0.0
Shell: zsh
wash Version: 13

Some additional background information and how I think we could fix it:
There are a couple limitations that restrict how we can handle hyphens:

cargo won't compile a library name with a hyphen in it, so the project name needs to be changed to have an underscore. The generated wash file name will have an underscore in the name.
it is possible to have a actor name that contains a dash, even though the wasm file contains underscores, by using the --name parameter to wash sign. That would let the actor show up in host inventory and the washboard with a hyphen, but that's a bit limited: Call aliases also can't have underscores (currently), so if you were planning to call the actor with a friendly name you'd have to change the hyphens to underscores.

Options:
(1) replace the project name with underscore, so at least wash new && wash build don't fail.  This can be done with a change to the project templates: Use  name = {{to_snake_case project-name}} (whoever implements this, it should be done for all project templates). We may want to print a notice on wash's output to tell the user that the name was changed.
(2) change the project name and also rename the actor at signing time. In addition to the change (1) on the template, this would require a change to the wasmcloud.toml parser and adding the --name parameter to wash sign.
(3) reject project names with hyphens and make the user re-submit the wash new command with a non-hyphenated name.
IMO (1) is preferable to (3) since (3) is an abrupt failure and (1) succeeds with a minor change, plus a notice to train the user how to do it right the next time.

I also like (1), especially with notice and auto-renaming to underscore.

Agreed with above, 1 sounds like a built-in way to handle the problem!

Another case to be handled that seems related:
wash new actor blobs3
cd blobs3
wash build

Compiles but then this error:

Could not find compiled wasm file, please ensure target/wasm32-unknown-unknown/release/blobs3.wasm exists

ls target/wasm32-unknown-unknown/release
blobs_3.wasm

Something added an underscore because the name is postfixed with a number.

Another case to be handled that seems related:
wash new actor blobs3
cd blobs3
wash build

Compiles but then this error:

Could not find compiled wasm file, please ensure target/wasm32-unknown-unknown/release/blobs3.wasm exists

ls target/wasm32-unknown-unknown/release
blobs_3.wasm

Something added an underscore because the name is postfixed with a number.

I have also experienced this and have had to manually rename. I did not onow if it was by design.

The problem is evident for numbers in more than 1 place, but they all have to do with files that I have seen. I personally have not looked at JWT.

Hey all I think I want to take a stab at this -- as I see it, the issue is that no
But this makes me think of a few more things:
Right now we only use a single template name -- can we explicitly specify the programming language the template is for? As what actors can be called is not limited, the restriction we're running into is actually language specific, and we don't have a transparent way to represent that complexity.
Rather than trying to solve the problem at the template level I think it might be a good idea to change the name at the wash level, print the message then go about the rest of the process as normal?
I've got a sketch of what I'd like to do here -- there's some room for improvement but I think it's a good starting point for discussion if there is any!

can we explicitly specify the programming language the template is for?

IMO this gets very complicated very quickly especially as the number of supported languages grows and they all have their own naming conventions. I think we just need to define what the convention is for a wasmCloud actor (and provider?) name. The most obvious pick is snake_case given that most actors right now are in Rust, so it would cause the least churn.
So then a user would just need to create a name that matches the wasmCloud naming convention. If a supported language requires us to write the name differently (ex. if we supported Java it would be CamelCase) we just make that transformation for the language-specific files of that particular template.

I'm working on templates for Go providers and more actors right now and most everything is MixedCaps

@mattwilkinsonn Hmm, yeah going with snake case feels like it would work for most other languages. I want to avoid over-specializing on Rust because wash should enable all WASM-ready languages, eventually...
I personally think that knowing the target language of the template/what you're generating for is useful and would open doors in the future (as templates proliferate, what if we want to limit which are shown by language?)
Can we do a bit of both? There's an Unknown case in there where most things can fall in, and we can require snake case as the default there, but make language specific changes when necessary. I'm a bit worried about painting ourselves into a corner and having to make a change to the naming scheme for some other language later.
Let's say we did go for one standardized naming scheme -- One case I haven't covered yet is the the number issue (that blobs3 example) -- it looks to be a rust-only thing, so should we add this rule for all languages?
The Golang example brought up by @jordan-rash is interesting -- gophers use MixedCaps names and likely the template might expect a MixedCaps name to come through? This means people who write templates need to ensure the case is MixedCaps (to they'd need to use a helper in their template to ensure conformity (don't know if it's an error to name it differently there).
I'm generally a fan of very explicit behavior, a kind of add-on choice we're making is whether to actually separate the wasmcloud actor name and the generated module name, should we make that explicit? Printing a message is good, but generating a module name to the best of our ability (but including a way to override it specifically) might be good.

My pitch is that the wasmCloud actor name is the "source of truth", and what the template names its' files and puts in the language config files is an implementation detail. So we would never change the wasmCloud naming scheme for different languages, Rust or not. When using a template, the actor/provider name can be transformed into a version friendly to the language for all of the language specific files and configs, but remain as the original version in wasmcloud.toml.
I'm also afraid of adding too much customization to the templates for the sake of both the template authors and the end users. As long as we can transform all valid wasmCloud names to a version that is accepted by the language and successfully compiles, we don't need any customization options for module/file names. If the user then wants to modify the module/package/crate/wheel (etc etc) name or the generated file name(s) to something else, that's totally fine, they are then taking on the overhead of making sure it still compiles with their changes.

My pitch is that the wasmCloud actor name is the "source of truth", and what the template names its' files and puts in the language config files is an implementation detail. So we would never change the wasmCloud naming scheme for different languages, Rust or not. When using a template, the actor/provider name can be transformed into a version friendly to the language for all of the language specific files and configs, but remain as the original version in wasmcloud.toml.

I agree with this, but the problem is right now there is no wasmCloud actor naming scheme -- this issue has evolved to to introduce one, right?
Maybe I am misunderstanding your point -- would you like to keep the wasmCloud side naming completely unfiltered (just a string, with no limitations AFAIK, with comments in this issue), and leave it up to template writers to make all necessary changes per-language? If this is the case, then there's no need to change wash at all, right?
What I thought we were discussing is that since wash's functionality is affected (i.e. when we try to build & run the generated WASM) by language toolkit choices, we needed to be more strict about what we allowed because language toolkits (in this limited case Rust) can change naming underneath us, and in addition be broken by our choices.
So far we identified the following issues with not enforcing a naming scheme:

replacing hyphens with underscores
replacing places where numbers are next to letters with _<num>

Taking a step back -- we can either solve this in wash, or leave it up to template writers.
These above issues are rust-specific (at present) so my proposal is a language-dependent solution. We have the option of defining a standard that is likely to work across languages, by severely restricting the subset of possible names, which is fine too.
At the high level, there is one crucial question and one follow on:

Do we make an attempt to solve this in wash, or leave it to template writers to take the unfiltered string?
(optional) If we've chosen to solve it in wash, do we make the changes language-specific or the common denominator that's likely to work across all languages (underscores over hyphens + some specific changes like the number thing)

IMO If wash takes the input, the program should build & run. wash should do the work to make sure that future washsteps work properly.

I'm also afraid of adding too many customization options to the templates for the sake of both the template authors and the end users. As long as we can transform all valid wasmCloud names to a version that is accepted by the language and successfully compiles, we don't need any customization options for module/file names.

Well on this issue I think I'm a little bit on the other side -- well used customization enables flexibility for both users and template authors. There can be vastly different ways to template out code (ex. should some generated rust code use libx or liby?), and as an intermediary wash should be negotiating this/doing interchange, so users get what they want and template authors get the information they need to function properly.
That aside though, I agree that this issue does not need to include customization options for module names -- my point was that making the difference explicit might be beneficial but we can decide that in the future when someone walks up with a use case/need.

If the user then wants to modify the module/package/crate/wheel (etc etc) name or the generated file name(s) to something else, that's totally fine, they are then taking on the overhead of making sure it still compiles with their changes.

I think wash (and transiently template authors) ought to take some more responsibility here -- wash exists to save users time (as opposed to just pulling down a zip file and going in and making edits), and IMO offering clarity/removing the need to fuss around with files after templating is within the purview.
With regards to your point, I do agree that we can't include every kind of non-functional change in wash as configuration, but the problem is that this particular issue currently breaks wash.

I agree with this, but the problem is right now there is no wasmCloud actor naming scheme -- this issue has evolved to to introduce one, right?

Yeah, at least I am of the opinion that we should.

Maybe I am misunderstanding your point -- would you like to keep the wasmCloud side naming completely unfiltered (just a string, with no limitations AFAIK, with comments in this issue), and leave it up to template writers to make all necessary changes per-language? If this is the case, then there's no need to change wash at all, right?

No - i'm thinking that the wasmCloud names have a specific style that is enforced by wash. This can be snake_case or CamelCase or any other convention, I just think we should pick one and stick to it. It resolves issues like the original one from this issue and also makes it easier for people to find/type actor & provider names if they know what pattern all of them will follow.

What I thought we were discussing is that since wash's functionality is affected (i.e. when we try to build & run the generated WASM) by language toolkit choices, we needed to be more strict about what we allowed because language toolkits (in this limited case Rust) can change naming underneath us, and in addition be broken by our choices.

Agreed on this. My resolution to this is that: If we have a specific style that we're conforming to, it's easy to then transform all names of that style to another one.

Do we make an attempt to solve this in wash, or leave it to template writers to take the unfiltered string?
(optional) If we've chosen to solve it in wash, do we make the changes language-specific or the common denominator that's likely to work across all languages (underscores over hyphens + some specific changes like the number thing)

The template specifies what style transformation they want, IMO. We already do this in some places: https://github.com/wasmCloud/project-templates/blob/main/actor/echo/Cargo.toml

IMO If wash takes the input, the program should build & run. wash should do the work to make sure that future washsteps work properly.

Agreed. If we have a specific naming convention then we can logically ensure that all names from that convention can be transformed into valid names for the language. Generally this would just be by going from snake_case to UpperCamelCase or lowerCamelCase in most cases. I can't think of another transformation we'd need to do at the moment.

Well on this issue I think I'm a little bit on the other side -- well used customization enables flexibility for both users and template authors. There can be vastly different ways to template out code (ex. should some generated rust code use libx or liby?), and as an intermediary wash should be negotiating this/doing interchange, so users get what they want and template authors get the information they need to function properly.

I don't think templates should be going this far. They are primarily a way to get people started on wasmCloud development so they can then learn the ropes, so should be kept as simple as possible with as small a setup time as possible. Advanced changes (like, IMO, your customizing generated code libraries example), should just be something a user can do after the template has been created, along with documentation on how to do it.
This is a bit of a philosophical difference though - I personally dislike template "wizards". I'd rather the command do as little as possible to accomplish the task and then link me to documentation that tells me ways I can change and modify things later.

I think wash (and transiently template authors) ought to take some more responsibility here -- wash exists to save users time (as opposed to just pulling down a zip file and going in and making edits), and IMO offering clarity/removing the need to fuss around with files after templating is within the purview.

I'm envisaging most users just copy/pasting a command that pulls down a template and running it. Adding a feature that renames files is just kinda overkill IMO, for our implementation side and for the user to use. Specifically for the user - Why go figure out what CLI flag you need to pass, or deal with an interactive CLI prompt, when you could just create the template and then rename the file(s) in the way that you are used to?

Thanks for the detailed response, I think we're mostly in agreement on actual implementation here, but I want to make it really explicit the choice being made, so a bit more rehash:

No - i'm thinking that the wasmCloud names have a specific style that is enforced by wash. This can be snake_case or CamelCase or any other convention, I just think we should pick one and stick to it. It resolves issues like the original one from this issue and also makes it easier for people to find/type actor & provider names if they know what pattern all of them will follow.
Agreed on this. My resolution to this is that: If we have a specific style that we're conforming to, it's easy to then transform all names of that style to another one.
Agreed. If we have a specific naming convention then we can logically ensure that all names from that convention can be transformed into valid names for the language. Generally this would just be by going from snake_case to UpperCamelCase or lowerCamelCase in most cases. I can't think of another transformation we'd need to do at the moment.

Leaning into these points, the proposal sounds like it would shape up to the following in practice:

all lower case
underscores as separation (no hyphens)
no numbers next to letters (blob3 case)

Does that sound right to you? The last point is rust-specific, but it currently breaks wash -- we either add it as a rule, or require every template to include a some sort of {{space_numbers_with_underscore ...}} handlebars helper.
This ruleset represents what we know to be issues and likely tolerable right now, but even if this were the solution, there's a problem, here's the scenario:

wash new takes MixedCaps3 as input, alerts and changes to mixed_caps_3
golang template takes mixed_caps_3 and turns it into MixedCaps3 (possibly producing MixedCaps3.wasm, MixedCapsThree.wasm etc)
wash crashes because it expected mixed_caps_3.wasm (the name in common config) to be the name of the generated executable

The core problem is that wash needs to know (optionally, control) the resulting generated wasm module name. If the template changes that out from under us, wash needs to find it out somehow, but this requires not allowing template writers to do anything they want with it.
In fact, perusing some of the wash-lib code encourages the language-dependent leaning I had -- we're already dispatching based on language specifics.

Other things worth saying, but less important than the above

The template specifies what style transformation they want, IMO. We already do this in some places: https://github.com/wasmCloud/project-templates/blob/main/actor/echo/Cargo.toml

I did see that -- but my thing is that the choices we make either add or remove work for tens/hundreds of template maintainers, so I'd err on the side of putting in the work to have something that "just works".
Also as a reference, cargo acts an example -- they solve this by accepting all applicable crate-level names and leaving an override point for library names.

I don't think templates should be going this far. They are primarily a way to get people started on wasmCloud development so they can then learn the ropes, so should be kept as simple as possible with as small a setup time as possible. Advanced changes (like, IMO, your customizing generated code libraries example), should just be something a user can do after the template has been created, along with documentation on how to do it.
This is a bit of a philosophical difference though - I personally dislike template "wizards". I'd rather the command do as little as possible to accomplish the task and then link me to documentation that tells me ways I can change and modify things later.
I'm envisaging most users just copy/pasting a command that pulls down a template and running it. Adding a feature that renames files is just kinda overkill IMO, for our implementation side and for the user to use. Specifically for the user - Why go figure out what CLI flag you need to pass, or deal with an interactive CLI prompt, when you could just create the template and then rename the file(s) in the way that you are used to?

I see your point, and I think we look at this differently. I see this as the end-user copying or pasting one command versus two.
To expand: from whatever documentation/blogpost/resource the end-user reads, they either copy and paste one command with toggles to get the functionality they want, or they copy paste one command then do <1-n extra commands> to get up to a ready-to-go state with the template they want.
With proper customization outlets, it is possible for template providers who are obsessed with smooth user experience to write templates that do the right thing in one properly toggled invocation. Without these affordances, it is impossible, and the user must do extra work. While I agree that minimalism in tooling is preferred, requiring more work by default seems like leaving potential ux gains on the table.
That said, I agree it's a philosophical argument that we can (and should) punt to later so I'm happy to punt it here.

I've titled each section here to help us keep track of the different discussions.
Example scenario

This ruleset represents what we know to be issues and likely tolerable right now, but even if this were the solution, there's a problem, here's the scenario:

wash new takes MixedCaps3 as input, alerts and changes to mixed_caps_3
golang template takes mixed_caps_3 and turns it into MixedCaps3 (or MixedCaps3.wasm, MixedCapsThree.wasm etc)
wash crashes because it expected mixed_caps_3.wasm (the name in common config) to be the name of the generated executable

This isn't how it works - when compiling a TinyGo actor, we explicitly tell the compiler where we want it to put the output by passing a -o flag, which we fill in with the wasmcloud.toml name. Relevant wash code and TinyGo docs.
So in your example, there would never be a MixedCaps3.wasm file, it will always be mixed_caps_3.wasm.
Let me know if this makes sense or I'm missing a wrinkle here!
Style proposal

Leaning into these points, the proposal sounds like it would shape up to the following in practice:

all lower case
underscores as separation (no hyphens)
-no numbers next to letters (blob3 case)

Yeah, that sounds reasonable to me. However we should probably make this as a seperate RFC to narrow down what the exact style is. The 3rd point is probably one people might have feedback on, I'd personally lean towards not including it and just having a handlebar transform for all Rust-specific names, but I'm not overly worried about which path we go down for that.
Knowing the wasm module names

The core problem is that wash needs to know (optionally, control) the resulting generated wasm module name. If the template changes that out from under us, wash needs to find it out somehow, but this requires not allowing template writers to do anything they want with it.

It already does, at least for Go. This code for Rust is actually buggy, if the wasmcloud.toml name and crate name didn't match up it would fail to find the compiled actor, which is actually the cause of the original issue here 😂. Need to change this to fetch the crate's name directly from the Cargo.toml file.
Dispatch based on language

In fact, perusing some of the wash-lib code encourages the language-dependent leaning I had -- we're already dispatching based on language specifics.

We have to do that on some level in the control flow because Rust and Go don't have the same compiler. That's why we split up them up there, and then we just hand the path of the compiled WASM actor to the rest of the function.
Transforming names at wash level or template level

The template specifies what style transformation they want, IMO. We already do this in some places: https://github.com/wasmCloud/project-templates/blob/main/actor/echo/Cargo.toml
I did see that -- but my thing is that the choices we make either add or remove work for tens/hundreds of template maintainers, so I'd err on the side of putting in the work to have something that "just works".
Also as a reference, cargo acts an example -- they solve this by accepting all applicable crate-level names and leaving an override point for library names.

I don't think it is difficult for a template author to write {{to_camel_case ...}} or similar when they want to transform the name. I think that also allows for greater flexibility when creating templates, and makes it clear to the users of the template what is happening. Also I don't think cargo is a good comp because it doesn't deal with multiple language ecosystems. Something like Bazel or another cross-language build toolchain may be useful to compare here.
Templates

I see your point, and I think we look at this differently. I see this as the end-user copying or pasting one command versus two.
To expand: from whatever documentation/blogpost/resource the end-user reads, they either copy and paste one command with toggles to get the functionality they want, or they copy paste one command then do <1-n extra commands> to get up to a ready-to-go state with the template they want.
With proper customization outlets, it is possible for template providers who are obsessed with smooth user experience to write templates that do the right thing in one properly toggled invocation. Without these affordances, it is impossible, and the user must do extra work. While I agree that minimalism in tooling is preferred, requiring more work by default seems like leaving potential ux gains on the table.
That said, I agree it's a philosophical argument that we can (and should) punt to later so I'm happy to punt it here.

I think boils down to that we disagree on what a template should provide. I'm seeing it as setting up the minimal things needed to build a wasmCloud actor. In my eyes, 100% of the time the user should be able to create a new actor from the template and then immediately run wash build and see it working.
If we add UX features / code transformations / dependency swaps etc to this process the chances of something breaking multiplies with each one. This is really bad because when something does break, the user never even got to the "success" state, and then they just come away with an impression that wash is a bad tool that generates broken code.  If this is a first-time wasmCloud user, we could lose them for good off of something like this.
Instead, we give them as small a template as possible that we are certain always compiles right off the bat. They create their actor from the template, run wash build, and see a successfully compiled and signed actor. Inside the templates we can add comments about stuff they could change and also link them to documentation in the CLI output to encourage them to add & change whatever they'd like to.
If they then want to go rename some files, change out a dependency, or follow the documentation's guide to set up foobar -  they know that if the actor fails to compile afterwards, it was because of the specific change they made. This also puts them into a typical software development pattern of having a working build, changing something, seeing it break, and then figuring out what broke and how they can fix it.
Sorry, that was a lot of text! Let me know what you think on this.

Thanks for the detailed response -- I've combined some sections since I think they're related, and to keep the issue-related discussion a bit tighter:
Example scenario / Dispatch based on language

This isn't how it works - when compiling a TinyGo actor, we explicitly tell the compiler where we want it to put the output by passing a -o flag, which we fill in with the wasmcloud.toml name. Relevant wash code and TinyGo docs.
So in your example, there would never be a MixedCaps3.wasm file, it will always be mixed_caps_3.wasm.
Let me know if this makes sense or I'm missing a wrinkle here!
It already does, at least for Go. This code for Rust is actually buggy, if the wasmcloud.toml name and crate name didn't match up it would fail to find the compiled actor, which is actually the cause of the original issue here :joy:. Need to change this to fetch the crate's name directly from the Cargo.toml file.

Thanks for informing me on the difference in how TinyGo works versus Rust -- this actually changes my understanding of wash drastically!
What I realize now is that the (slightly unequally held) implicit assumption is wash don't trust the actor name to persist, if it can't control the build process -- so assuming that our actor name has anything to do with the generated wasm module name in the first place was wrong.
Reading your comment I was originally thinking I should do two things:

Write an RFC for pinning down actor naming rules
Implement the ruleset as discussed

But it looks like what I should actually to solve this is:

Dynamically pull the module name from generated cargo.toml

It looks like actor naming is related but separate from this bug -- this is a problem with the Rust compilation code not controlling the build process explicitly enough and trying to guess, essentially. It can just read from what is generated.
I'll have an updated PR for this before long.
There's still a mismatch in the what actor names are expected (theoretically... we could have an actor that just has a single emoji for a name, right?), but the immediate problem is definitely that we try to guess the name for Rust.

Worth saying, but less important than the above
Dispatch based on language

We have to do that on some level in the control flow because Rust and Go don't have the same compiler. That's why we split up them up there, and then we just hand the path of the compiled WASM actor to the rest of the function.

Rust and Golang also don't have the same naming rules :wink: . We haven't found any bugs in the TinyGo implementation because we haven't happened upon the names that break the compiler options we're passing yet.
This interestingly brings up another point -- it's weird that wash invokes the compiler at all. Pushing language-specific work/building/fiddling out of wash by having the template provide a consistent build point seems like a better approach. AFAIK This is how most composable multi-ecosystem build systems work (ex. buildpacks, bazel) -- rather than reaching "in" to do the compilation, it's completely contained in the extension point (in our case templates), and the extension provides a standardized thing.
Sounds like more fodder for an RFC :smiley: .
Getting back to the task at hand though -- IMO what we're giving up on here is certainty while telling someone what the compiled WASM will be named. We have control over this for TinyGo because we reach in and do the build, but the place where we don't (Rust), we don't have control, and thus the bug.
Rehashing a bit: If we make a name that is known good for the compiler and give that to the template, we can have some certainty, but if we don't then we must either run their build (and specify the name) or read their build dir for the answer (searching cargo.toml).
Transforming names at wash level or template level

I don't think it is difficult for a template author to write {{to_camel_case ...}} or similar when they want to transform the name. I think that also allows for greater flexibility when creating templates, and makes it clear to the users of the template what is happening.

True, it's not too difficult, but IMO the problem is them knowing they'd have to. They don't want to transform the name, they have to transform it to match the rules of their language, after having been given a name that could be anything (it could be a string of emojis!).
So the work in the template is not just to_camel_case, it's any other diff between what actor names allow and what their platform allows -- in the simpler cases this is to_camel_case, and in more complex cases it's convert_emoji or convert_utf8.
To be fair the work is only done once, so maybe it's negligible.

Also I don't think cargo is a good comp because it doesn't deal with multiple language ecosystems. Something like Bazel or another cross-language build toolchain may be useful to compare here.

As far as I can see Bazel errs on the side of leaving the option in. While Bazel does have a strict naming scheme for packages (this is great fodder for the RFC), at the language level the default isn't the Bazel package name, it's what it expects rust to handle. In fact Bazel's package naming rules definitely allow for invalid crate names -- rather than pick the least common overlap, it seems that Bazel just side-steps the problem entirely by requiring it to be set explicitly.
I haven't used Bazel for anything substantial so I'd really appreciate corrections in my understanding :bow:  (I really want to use it in the future).
Templates
Hmnn I'm conflicted because I agree with you on the minimal setup point, and things building out of the box, but that power (and responsibility) should lie with template writers.
Giving template writers power/flexibility to build something that gets it right without cruft/tweaking seems like a win. If we want to enforce quality on template builders, then we can easily test their templates before marking them with some quality indicator.
As a template writer, I'd be less concerned with wash wanting a minimal repo and more concerned with creating the repo that has the code I want to provide baked in given what I know the user wants/has specified.
If wash chooses not to carry user preferences through to me, then my hands are tied but that doesn't really spark joy. I either:

Write comments/README/etc for every customization point
Write custom templates that are slightly different for each case (example-x vs example-y)

I do understand that your stance is that (1) is a good way forward there, and there's no one clamoring for this yet, so that's the last I'll say on that to avoid taking up any more of your time!

My 2 cents

I'm seeing it as setting up the minimal things needed to build a wasmCloud actor. In my eyes, 100% of the time the user should be able to create a new actor from the template and then immediately run wash build and see it working.

💯 this.  IMO, templates (that are provided by wash out of the box) are a bare minimum, functional, actor or provider that use standard practices for the selected language.

that power (and responsibility) should lie with template writers.

Also this.  If a user wants something more then the minimum, we have to give them the power to do that.  I think of helm charts at this point.  They give me the power to write my own handlebar shortcodes and if i want something special, I take it from there.

I don't think it is difficult for a template author to write {{to_camel_case ...}} or similar when they want to transform the name. I think that also allows for greater flexibility when creating templates, and makes it clear to the users of the template what is happening

Agree. I do not think that we should make any hard decisions on how things are or are not named.  We start out with opinions based on language specific paradigms and let the enduser take it from there.  I have a company with a certain naming convention for artifacts, if I have to go rename everything after is comes out the back of a code/template generator, I am less inclined to use that generator and I just hand role things.
TLDR:
Implement language best practices, give the end user the power to change what they want, provide bare minimum (but compilable) examples as wash defaults.

Just as a user note :
I have converted all naming in my Rust-based projects to_snake_case (this also aligns better with rust web), and some include number5_in_name which was desired by me and I had to go through and manually change names because of the out-of-the-box number handling in a name (e.g. oauth_2 to oauth2).
One of the friction points for me entering the ecosystem was seeing a mix of dashes and underscores and predefined number handling notions within the project's various points of name representation, and this resulted in significant wasted time in determining why things wouldn't work at points.
I am not sure how a lowest common denominator for naming could be investigated for multiple languages, but I do believe that mixed naming formats are highly tedious for any language, and a solution decision may consider that such that for a specific language, naming was consistent wherever it was represented.

@mattwilkinsonn
Appreciate the pointer and the lively discussion, giving that RFC a read!
@stephenandary
Thanks for the input! Let me try and filter the discussion so far to what you've run into:

One of the friction points for me entering the ecosystem was seeing a mix of dashes and underscores and predefined number handling notions within the project's various points of name representation, and this resulted in significant wasted time in determining why things wouldn't work at points.

I'd love to hear more about this -- if you could point me to somewhere we use dashes and underscores in a name I can definitely try and get rid of that (that really should be an bug/issue).

I am not sure how a lowest common denominator for naming could be investigated for multiple languages, but I do believe that mixed naming formats are highly tedious for any language, and a solution decision may consider this such that for a specific language, naming is consistent wherever it is represented.

Agreed! However consensus so far seems to be that language specific fixes aren't the way going forward, see the RFC.
It seems like we could get away with that lowest common denominator (and it would happen to fix the rust case).

It may also be nice to know as a user where the points of representation should be verified per language as there are many files and blocks of config that display a name. This part may relate to versions as well (e.g. how wasmcloud.toml version is used when cargo.toml version is not - how does this sync easily for a user in various languages?)

Maybe it makes sense to write some documentation on the plugin/template flow and have it be more concretely spelled out somewhere or more prominently.
Adding documentation (FAQ/Cookbook at least) could make the contract between wash and the templates that are being used really obvious (and answer questions of versions). Also makes it clear what's supposed to happen versus what does.

@mattwilkinsonn
I think you misunderstood what I was saying. It is not about a mix in a single case of -'s and _'s, it is about some names using dashes and some using underscores. E.g. A project name could be some-project, then the binary name could be some_project. When you factor in numbers that can become some2-project and some2_project and some_2_project.  (Makefiles, cargo.toml, wasm binaries, wasmcloud.toml, and test files are some of the places a project name is used, and there are often multiple representations in a single file for binary, directory, or project name).
I am not saying that there should be language-specific solutions, I am saying that whatever solution is decided upon should try to be as consistent as possible with naming wherever there is name representation (I don't really care in the discussion of _'s vs -'s, but from my experience in wasmcloud _'s would be the better choice). I also personally think it is better to be divergent with language naming if it means consistency within a project.
When I am referring to a lowest common denominator, I mean settling on a naming structure that satisfies the most languages out of the gate, and then being able to convert names for other languages. snake_case seems to satisfy a lot - https://simple.wikipedia.org/wiki/Snake_case - especially of foundational languages in wasmcloud. Hopefully, by categorizing languages, the mapping of snake_case to CamelCase et al. becomes easier to post-process. and it would not be language-specific but naming convention specific. Kind of like postprocessing g-code for a specific machine - have a matrix of languages that require a specific post process for names.

@stephenandary I see what you meant, it looks like I misunderstood what you meant!
The good news is your points almost perfectly encapsulate what's in the RFC, I think it's got just about everything you're hoping for, so your comments would be greatly appreciated there as well.

Oops @vados-cosmonic , I @'d the wrong person in previous lol, it is late. I will look at the RFC tomorrow, but I am not sure if the link to rfc is correct. When I click it is just bring me back to this issue I created. Would it be in wasmCloud repo? Or is the RFC this issue?

Hey @stephenandary Ah gotcha -- I saw that the link was back to this PR (meant to point to the comment from Matt earlier!), I've updated the links now, but juuuust in case:
https://github.com/wasmCloud/wasmCloud/issues/271

Resolved by #390


[Synapse] AddAndRemoveRoleAssignmentSync failing in nightly runs

Synapse test runs are failing with:

Error message
System.InvalidOperationException : Sequence contains no matching element
Stack trace
at System.Linq.ThrowHelper.ThrowNoMatchException()
at System.Linq.Enumerable.Single[TSource](IEnumerable1 source, Func2 predicate)
at Azure.Analytics.Synapse.AccessControl.Samples.Sample1_HelloWorld.AddAndRemoveRoleAssignmentSync() in /Users/runner/work/1/s/sdk/synapse/Azure.Analytics.Synapse.AccessControl/tests/samples/Sample1_HelloWorld.cs:line 37

For more details check here:

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=1166378&view=results

@jsquire for notification.

Given the age of this issue, closing as stale.  If tests are still failing, please file a new issue.


Training Code

Thank to your great job, by the way, may I ask when will you publicate the training code, waiting for your reply

A great work indeed! Kindly share the training code too.
Thanks

We are expanding the journal these days, and the training code will release after that.


python312Packages.motionblindsble: init at 0.1.0

Module to interface with Motionblinds motors using Bluetooth Low Energy (BLE)
https://github.com/LennP/motionblindsble
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 321757 run on x86_64-linux 1

5 packages built:

home-assistant-component-tests.motionblinds_ble
python311Packages.motionblindsble
python311Packages.motionblindsble.dist
python312Packages.motionblindsble
python312Packages.motionblindsble.dist


move dev docs to folder

we have 3 dev docs files now, so thought it may help things if we started a folder
i wasn't sure on the folder name, would dev-docs be better?

will maybe come back to this in some made up future


ISR table (_sw_isr_table) generation is fragile and can result in corrupted binaries

Describe the bug
If CONFIG_GEN_ISR_TABLES=y, drivers can use IRQ_CONNECT() to register an ISR with the arch IRQ handling core. IRQ_CONNECT() parameters are used to initialize a static variable stored in a special section named .intList. This data includes the address of the ISR function.
There is a global _sw_isr_table variable. The goal is to fill it with the IRQ_CONNECT() data.
During the build, Zephyr is linked for the first time, producing an ELF binary with a weak value for _sw_isr_table that has the correct size (CONFIG_NUM_IRQS) but garbage data, along with a final .intList section that has the data we want.
The .intList data are extracted into a blob, which gen_isr_tables.py uses to create the real _sw_isr_table in a generated C file. This file and the other Zephyr objects are linked again. The real _sw_isr_table overrides the weak symbol. This is the final ELF file. As long as the first and second link result in ISRs at the same addresses, everything works fine.
The problem is that this assumption is not valid in general. In particular, on RISC-V, unusually aggressive linker relaxation (https://www.sifive.com/blog/all-aboard-part-3-linker-relaxation-in-riscv-toolchain) -- whose implementation details vary by toolchain version -- can and do produce different binaries depending on random things.
The one that bit me in particular was that the RV32M1 toolchain (for a RISC-V SoC being added in https://github.com/zephyrproject-rtos/zephyr/pull/11853) chooses to emit a compressed instruction when loading the address of a strong symbol, but not a weak one.
Now, _sw_isr_table itself is a weak symbol in the first link and a strong one in the second. This SoC port involved a multi-level interrupt driver, which needs to get the addresses of level 2 interrupt handlers from _sw_isr_table, and thus needs to load the _sw_isr_table address. Due to the linker relaxation details on my toolchain, the second binary had different-sized code for getting this address, bumping the addresses of the ISRs themselves backwards by a couple of bytes, resulting in a corrupted binary which jumped to the wrong addresses when calling level 2 interrupt handlers.
I was able to work around this for my toolchain, but issues like this are likely to happen again -- potentially  on other architectures as we add non-GCC toolchains, or as a result of future GCC changes. This issue asks that the IRQ_CONNECT() and gen_isr_tables.py implementation be re-worked to be less fragile in the face of different emitted code in the first and second link.
A RISC-V expert I spoke to recommended putting the symbols of the ISRs in _sw_isr_table instead of their addresses (presumably with declarations before the table generated by gen_isr_tables.py). This would seem to require reworking IRQ_CONNECT to save the names of the ISRs rather than just their addresses as well.
To Reproduce
See this gist for an illustration of the behavior related to weak and strong symbols:
https://gist.github.com/mbolivar/e2704c48e92f13a0a731198603093dbc
In particular, loading the upper bits of the global_symbol address uses a 2 byte compressed lui instruction for a strong symbol:
   10074:	67c5                	lui	a5,0x11

And a 4-byte non-compressed instruction for a weak symbol:
   10074:	000117b7          	lui	a5,0x11

The binaries are correct and semantically equivalent, but they differ in size. Instruction addresses for any code after this function would be offset by 2B between the two, even if nothing else changed.
Expected behavior
Generated IRQ handling code should correctly access driver-specified ISRs.
Impact
Zephyr binaries on RISC-V can be corrupted due to "phase of the moon" implementation details in the linker.
Screenshots or console output
See above gist.
Environment (please complete the following information):

OS: any
Toolchain (e.g Zephyr SDK, ...): RISC-V GCC toolchain for RV32M1 SoC. Note Zephyr SDK RISC-V toolchain behaves differently! (It emits uncompressed instructions for both links)
Commit SHA or Version used: any since gen_isr_tables.py was added

Additional context
N/A

I'm not able to reproduce with any toolchain I have access to.  Checking your toolchain, I see that you are using ancient versions of the tools from mid 2017.  The tools weren't stable until about January 2018.
rohan:2037$ riscv32-unknown-elf-gcc --version
riscv32-unknown-elf-gcc (GCC) 7.1.1 20170509
Copyright (C) 2017 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.

rohan:2038$ riscv32-unknown-elf-ld --version
GNU ld (GNU Binutils) <IP_ADDRESS>70505
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
rohan:2039$

I wouldn't recommend using anything before FSF gcc-7.3 and FSF binutils-2.30.
I suspect that the linker problem you are seeing was fixed sometime last year, possibly before the port was contributed to the FSF, which makes it difficult to figure out what exactly changed that fixed this.
By the way, your "source file" releases contain pdfs, and appear to be identical to your documentation release.  That is probably a bug on your web site.

It's not quite clear to me from reading this whether this is a toolchain or a zephyr problem. Can we establish whether generating different code depending on whether weak symbols are used or not is permissible behavior, before we rework the interrupt code?

The compiler doesn't know if a weak has zero or non-zero address, so must emit a generic sequence.  If a non-weak is not defined in the module where it is used, then this must also be a generic sequence.  I'd expect these to be the same.
A non-weak defined in the same module where it is used might be optimized by the compiler.  But whether this affects instruction length depends on the hardware addressing modes, and the code models  and ABIs in use by the compiler.  It probably ends up the same length anyways.
If you are doing link-time-optimization, then a reference to a weak may be optimized away, or maybe optimized to a trap instruction if your target doesn't support reads from a 0 address.  This is very likely to change code size.
The RISC-V port does aggressive linker relaxation by default, which like link-time-optimization, can change code size.  The specific example shown in this bug report I'd call a toolchain bug though, as you should have gotten the same code at the end, and I do get the same code size with all supported toolchains versions I tried.
The testcase given here defines the weak variable in the same module where it is referenced though.  If you change the example to make it an extern, then it gets more interesting.  I get
lui	a5,0x0
lw	a0,0(a5)

which could be optimized at link time to just "lw a0,0(x0)".  We may add a linker relaxation for this some day, and then you could have a problem again, as the code size would be different for the weak and non-weak references.
Incidentally, the RISC-V linker relaxation can be turned off temporarily.  You can do
.option push
.option norelax
...
.option pop

and the section in the middle won't be subject to linker relaxation.  This could be used to work around this problem.  This is a lot easier to use in an assembler file than a C file, but you try using volatile asms to put this in C file.  You can also compile the C file with -mno-relax if you have an up-to-date compiler, or you can just use -Wa,-mno-relax with an older toolchain.

I wouldn't recommend using anything before FSF gcc-7.3 and FSF binutils-2.30.

Hi there @jim-wilson! I unfortunately don't control the toolchain and cannot implement this recommendation, even though I wish I could.

It's not quite clear to me from reading this whether this is a toolchain or a zephyr problem. Can we establish whether generating different code depending on whether weak symbols are used or not is permissible behavior, before we rework the interrupt code?

I think this is a case of Zephyr's two-stage link being a bit too chummy with the implementation.
Generating different code depending on whether weak symbols are used is perfectly permissible as far as I can tell. The RISCV binutils maintainer (Palmer Dabbelt) I spoke with said that in general it's not safe to rely on two links even with slightly different code producing the same results. He told me Linux was also doing two-pass linking and also had to make similar changes.

and the section in the middle won't be subject to linker relaxation. This could be used to work around this problem. This is a lot easier to use in an assembler file than a C file, but you try using volatile asms to put this in C file. You can also compile the C file with -mno-relax if you have an up-to-date compiler, or you can just use -Wa,-mno-relax with an older toolchain.

I am aware of and did consider that. As I said, I was able to work around this for this toolchain.
My concern is to avoid future driver authors running into issues like this based on what to me seems like invalid assumptions in the Zephyr build system.

I spoke with said that in general it's not safe to rely on two links even with slightly different code producing the same results. He told me Linux was also doing two-pass linking and also had to make similar changes.

Hmm, fair enough.
For the ISR tables, it won't be too bad to change it to save symbols instead of addresses, I think that will fix this.
We have some other stuff on x86 where this becomes more of a problem. Building the GDT and IDT at build time can't be done with symbols since its a binary blob that gets built, not C code, and due to way the addresses are split around in various ways in these descriptor data structures, you can't statically define them in C. But perhaps since this is just x86 we can leave it alone.
I think the privileged stack generation mechanism used on ARM/ARC might also rely on memory addresses staying the same, but I need to double-check.

Perhaps instead of using weak symbols we should use different object files in different linker passes.

I might have said this wrong during the summit, but the two-pass link in Linux was doing something different: it didn't expect stable symbol addresses, but instead used weak undefined symbols that later become defined.  The Linux code was legal, it was just triggering a linker bug.
I can't figure out a better way to deal with the harder problems :)

Perhaps instead of using weak symbols we should use different object files in different linker passes.

I tried this at one point. Unfortunately, the objects would appear in different places in the binary, which broke stuff. They have to be guaranteed to be in the same place or it falls over. Might still be possible but everything would have to be linked in the same order. This might be the best route actually, see below:

For the ISR tables, it won't be too bad to change it to save symbols instead of addresses, I think that will fix this, since the output of the scripts is just more C code which gets built.

Hmm. I may have spoke to soon. We can use symbols for the ISR addresses, but it gets more complicated when it comes to the argument passed to the ISR, this gets stored too and can be anything, a constant, a symbol, NULL, etc.

I think it's probably just simplest to revert 140863f6a753f3ab169e0faee79463e977c1364f
and go back to using .gnu.linkonce.

I think it's probably just simplest to revert 140863f
and go back to using .gnu.linkonce.

@andrewboie:
I saw this and appreciate the fix for the issue with my (ancient) toolchain.
More generally, would it be worth it to do a post-processing step on the final zephyr binary to make sure that ISR addresses didn't change, and at least fail fast if they did?

I have similar issue (#24291) on cortex. The generated source code isr_tables.c is correct, but _sw_isr_tables in the final linked image is not correct. When button gpio interrupt occurred, it entered the default spurious handler instead of the button handler.


PUSH on WiFi only, scheduled poll on mobile data

Hi,
unless I'm missing something in the options, is it possible to implement a switch to allow PUSH exclusively on WiFi and a scheduled poll (with an user selected interval) when on mobile data? I ask this because of the infamous "Mobile data active" bug in latest android versions...
Thanks a lot in advance and keep up the good work!

See #617


Centralize the way the sample apps yaml are being set to be deployed

What type of PR is this?

[X] Enhancement / New Feature
[ ] Bug Fix
[X] Refactor
[ ] Optimization
[ ] Test
[ ] Documentation Update

What this PR does / why we need it:
This PR addresses these needs:

Centralize the way that the pod yaml URL is being used across all the e2e tests to simplify the deployment of the sample application
Stop using bookinfo app to validate sidecar injection
Adding POD_SAMPLE_YAML_BASE_URL to enable a way to set custom yaml string that will allow user to use their own yaml with custom images

Which issue(s) this PR fixes:

Fixes #467
Additional information:

@fjglira: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

e2e-kind-dualstack_sail-operator_main
51958f7b76c775bf6131e50382425de80511eb8c
link
true
/test e2e-kind-dualstack

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-sigs/prow repository. I understand the commands that are listed here.

@fjglira: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

e2e-kind-dualstack_sail-operator_main
51958f7b76c775bf6131e50382425de80511eb8c
link
true
/test e2e-kind-dualstack

e2e-kind-multicluster_sail-operator_main
51958f7b76c775bf6131e50382425de80511eb8c
link
true
/test e2e-kind-multicluster

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-sigs/prow repository. I understand the commands that are listed here.

I'll check tomorrow morning the failure in the suites: dual-stack and multicluster. For sure, I left some errors in the new way of setting the sample apps


Error: TypeError: issubclass() arg 1 must be a class

I installed from the source. And got this error:
TypeError: issubclass() arg 1 must be a class

I am getting the same error, I installed using pip

Update: I was able to get around it by creating a new virtualenv with 3.11.3.  The Python version that was getting an error was 3.9.6


Please remove test directory from packaged files (if possible)

Normally adapters should NOT install test scripts at user systems. Do the test directory is normally not delivered.
Please check and remove (if theres no special reason to keep) the test entry at pacakge.json:
https://github.com/baerengraben/ioBroker.swiss-weather-api/blob/82276c9d7fb6dda69499c3d6e193a682eaabf7d0/package.json#L82

cancelled


Doesn't follow window resize

Using version 1.1.0 (-- Wow!! Great improvement in functionality and UI --) on Chrome 48.0.2564.109m
When resizing the browser window, the interface doesn't react to that event and as a result some controls (e.g. the tool/statusbar at the bottom of the window, scrollbar on the right, etc.) become unusable if the new window is shorter or narrower, since the UI seems to suppress native browser scrollbars.
Workaround:
If the window is narrower but not shorter and the file tree was hidden at the time of the window narrowing, the hide/unhide tree button at the bottom left will repaint the (tabs-container) file list to match the current window width but will not adjust the outer element (div.container-fluid) size to conform to the new body height.
Note also that if the body window is resized to be narrower than it was at initial load and the file tree is visible, the tabs-container element reflows to below filemin-tree.

Yep, I spend a lot of time syncing different tab types to be same width/height. Treeview caused a lot of trouble, bottom status bar was jumping up and down, that was fun :D
So I did not add window.onresize event handling cause I was exhausted.
That will be added in next minor release, of course, cause leaving it like so is no good.
For root user you'll get notification about available update on Filemin launch when that happens  (Webmin main window, not Filemin one) .
Until that time I got a better advice how to bypass this issue: if you don't have any of 'Search' or 'Editor' tabs open, then you can just hit F5, all your 'Navigator' tabs will be restored and Filemin will adjust it metrics to browser viewport.

Yes, that works also, since you have the persistence across sessions
implemented (very nice, that :) )
On Wed, Feb 17, 2016 at 10:25 AM, Real-Gecko<EMAIL_ADDRESS>wrote:

Yep, I spend a lot of time syncing different tab types to be same
width/height. Treeview caused a lot of trouble, bottom status bar was
jumping up and down, that was fun :D
So I did not add window.onresize event handling cause I was exhausted.
That will be added in next minor release, of course, cause leaving it like
so is no good.
For root user you'll get notification about available update on Filemin
launch when that happens (Webmin main window, not Filemin one) .
Until that time I got a better advice how to bypass this issue: if you
don't have any of 'Search' or 'Editor' tabs open, then you can just hit F5,
all your 'Navigator' tabs will be restored and Filemin will adjust it
metrics to browser viewport.
[image: 6]
https://cloud.githubusercontent.com/assets/2231969/13116218/3afe9a86-d5c5-11e5-8f6b-a12e5d261328.png
[image: 7]
https://cloud.githubusercontent.com/assets/2231969/13116227/4077098a-d5c5-11e5-8395-709fc11f5553.png
—
Reply to this email directly or view it on GitHub
https://github.com/Real-Gecko/filemin/issues/92#issuecomment-185282276.

Cool ideas come during testing routine :D

Fixed in version 1.1.1.
Login as root and go to Filemin page, you'll be prompted for update.


Add support for dark mode

velo has https://github.com/StaffEngineer/velo/blob/main/src/themes.rs
To implement dark mode the following steps can be taken:

[ ] adjust colour palette for dark theme in themes.rs
[ ] create button that switching the theme and writes user_preferences theme– to pkv
[ ] create system that updates colours based on chosen theme in runtime
[ ] on button click run that system

This is duplicate of https://github.com/StaffEngineer/velo/issues/158


Performance degradation with large point clouds and show condition on M1 Mac

Hello!
I observed a performance degradation when rendering large points clouds that use the conditional show attribute. I'm certain that the performance was much better, in a project I'm using such a technique to filter for attributes from the tileset's batch table and now the framerate drops a lot when the filters are applied. Maybe it only affects macOS / arm architecture — on a Linux / Intel workstation with NVIDIA GPU it works fine.
A quick performance monitoring in the dev tools showed that readPixels consumes a lot of time which is called for scene picking. Is there a way to turn off picking for Cesium3DTileset ? That might help in my case.
I can reproduce this in a sandcastle with the Melbourne point cloud, and you can see the framerate drops from ~100 fps to ~10 fps when zooming in:
https://user-images.githubusercontent.com/449600/236436953-c1d84f1b-3a67-4a1e-a663-8de8214e834a.mov
Sandcastle example:
https://sandcastle.cesium.com/#c=hVNha9swEP0rRxiNA0FO10K71AkbKYyMjkBT9slfFPkai8m6IJ2TuiX/vXJsZ0nZmMFg3b33dO9JjmP47qRlmKHXZfFjCVIp9B6YoKLSgSYL0ntkn1pF1jNsNe7QwQQs7lqa+HWoRWlPHdYzsiy1RZf2BnepTW0kfWUVRAOYTOEttQDsquYDWkGBL4w2i1rFptgsru6ftEE/t36Disn91C/a1sI1uxmKawBymErupO7siDM+snh2VMzJfqsNzbPo+urLzW0n1EqIDWnLM0Nltsxlpu06iLaThkdymLKUHHIZBxMlDo8trPCeCnzQ65wD7T/tJTu0a87HcPlPzGPYv/R/EPu7s8S8Qoti43ShWW/RC5llUWujc9XE0RJeiYon+gjpjHuuDJ6f62l+y7odHZM4xLTUrziG66MBRYbcGPpuvYo+j0bD9h30jwif0y4APr3NFg+Lx71wMIWRuIGLCzipJaF2229NN3PuQUlWOUToHLlBdyT18ZNBYWjddhp0aveDqP7uDXvJwdm0rn/VxYYcQ+lMJETMWGyMZPTxqlS/QwbK+5qUxB0lyfQWdDb5y9UGZcKfETrPpTF1EmlvmsQBf0YzdLhEiy06I6sAqcdI8svpQ9MQQiRxWNabfuQykVlJd6L7Dg
Browser: Google Chrome Version 113.0.5672.63 (Official Build) (arm64)
But similar experience with Safari / Firefox
Operating System: macOS 13.3.1 (a) on M1 Max

Thanks for the report @ulrichson!

I'm certain that the performance was much better

Do you mean in a previous release, or just when an M1 machine is not being used?
We have seen some rendering problems on M1 machines, but they tend to be rendering artifacts rather than degraded performance.
In general, readPixels is an expensive operation, and we'd (hopefully soon) like to optimize picking to avoid it as much as possible.

I mean with a previous Cesium release. To verify I just ran an older version of my project where Cesium 1.91.0 was used and here the performance is good on M1.  I don't know between which versions the performance drop happened. If it helps, I can try to figure it out.

Thanks for clarifying! And we'd definitely appreciate the help. 1.97 would be the first release I'd suspect that this began occurring. There was a major 3D Tiles and model refactor that went out as a part of that release.

Is there a way to disable picking for Cesium3DTileset (assuming it then wouldn't call the expensive readPixels)? I wouldn't use it for point clouds anyway.

Not through the public API. If you're willing to modify the source code, it's possible to skip the 3D Tiles pass when picking.

There was a fairly large refactor that went in with that change. @j9liu would you be able to recommend a place to start looking regarding changes from ModelExperimental related to performance picking point clouds?

@j9liu @ggetz any updates, on how to disable point cloud picking in the cesium code? thanks!

Hey @ulrichson,
Sorry about the delay. This completely slipped my radar. I'm happy to take a look -- I should have a moment by the end of this week.

Thanks @j9liu 😊

Hi @ulrichson,
I don't have an M1 Mac, and I can't reproduce this behavior on Windows. But I'm curious to see the debug profile that demonstrates the difference with / without this condition. readPixels has always been slow, so I'd want to know why the function read is slower with the show condition on (if that's what you claim). It'd be different if the time leading up to the readPixels is slower -- I imagine the buildDrawCommands in Model could be slowing things down, since it's called every time a style is applied.
In any case, there's an individual allowPicking on the individual Model level. Even though there's no equivalent
on Cesium3DTileset, it itself uses Model to render tile content. You can experiment with setting it false in the constructor and seeing if it helps. Let us know how it goes so we can try to troubleshoot from there

Hi @j9liu, thanks, I'll give it a try!
Here's a snapshot of the profile on my M1 machine when the show is set as in the sandcastle example above:

Update: maybe it's not related to the readPixels (and picking) as I thought. The project I'm working on is using the show attribute, and here readPixels doesn't seem to be an issue. Did possibly change something in the shaders that could cause this?

In 1.97 we switched to a completely different Model implementation, so yes. But I have a hard time understanding what in the new architecture could be slowing things down.
Here's the state of CesiumJS in the 1.96 release. You can see how PointCloud.js was used to render point cloud content, instead of Model. Here is where the point cloud shaders were created.
In the new Model architecture, the shaders of a Model are built incrementally using various "pipeline stages". So the pipeline stage responsible for adding point cloud styling code is PointCloudStylingPipelineStage.js. But you can see at line 290, the show condition function is derived the same way as it was in PointCloud.js.
So that's why I'm confused. If the new Model architecture was slower as a whole, I would understand, because it takes more time to construct / reconstruct shaders for a model, and that can get exacerbated by picking. But I don't see how simply adding a show styling condition makes everything slower. If you're able to save the performance profiles you gather in Chrome (both with the show condition and without), and attach them, I can look at them more closely.

Sure, thanks for looking into it!
Here's the profile with show: trace-with-show.json.zip
And without: trace-without-show.json.zip

Thanks @ulrichson ! I'll try to take a look by the end of this week :)

@ulrichson
Thanks for your patience. I took a look at the profiles and could also see that the readPixels function was taking 3x as much time with the show condition, vs. without.
I'm trying to think of why this could be. Picking actually involves re-rendering the scene in a small area, then sampling that rectangle for an object. So technically, with picking, the scene (and all of its models) is updated and drawn twice. This is definitely not the most efficient method for picking, but perhaps picking is exacerbated by things that slow down the render loop itself.
I've looked at these parts of the profile, and it does seem like the biggest offender is PickFrameBuffer.end (which then calls readPixels, but the time that render takes with the show condition is strangely less than the time without the condition. Granted, these profiles could be changed based on how much the mouse is actually wiggling across the screen during the time of recording. But it's hard to tell why that's happening and what's actually going on.

Without condition
With

Unfortunately, in the profiles I can't go any level deeper than "Animation Frame Fired" -- I can't see if there's any bottleneck in particular when the scene renders. But the GPU performance is definitely worse with the show condition. It looks like the longest time it takes on the GPU without the show condition is 6ms, where the GPU sometimes goes above 100ms with the show condition.
If I could reproduce this myself, I would go through the Model architecture and try to leave out extraneous parts of the pipeline, like the PickingPipelineStage or the PointCloudStylingPipelineStage, and see what happens. This part of the shader code is what is responsible for the show condition in point clouds: I also wonder if it makes a difference if the show condition is always set to true. In other words, is it the presence of the show condition that slows things down? Or is it the evaluation of the condition itself?

Update: maybe it's not related to the readPixels (and picking) as I thought. The project I'm working on is using the show attribute, and here readPixels doesn't seem to be an issue. Did possibly change something in the shaders that could cause this?

Does this imply that the show attribute still causes issues, even with picking disabled for point clouds?

We are experiencing the same performance issue , see #11196 . Our tilesets are generated with Agisoft Metashape. Prior to version 1.97 there were no problems but starting from 1.97 we observe the same behavior as reported in this issue the only difference is that we do not apply any styling.

@j9liu Thanks! I tested with show: 'true' (and also an expression that always evaluates to true, i.e. show: '${COLOR}.r > -1 && ${COLOR}.r < 2' and then there's no performance drop. Same observation as without the show.

Does this imply that the show attribute still causes issues, even with picking disabled for point clouds?

It seems so, I made the following change in packages/engine/Source/Scene/Model/ModelRuntimePrimitive.js:
if (model.allowPicking) {
  console.warn('Disabled PickingPipelineStage')
  // pipelineStages.push(PickingPipelineStage);
}

With the disabled PickingPipelineStage the performance still drops - so it's really not related to picking.
I did another test and tried to fake the show behavior with a conditional color style, i.e. color: '${COLOR}.r > 0.7 && ${COLOR}.r < 0.8 ? rgb(200,200,200) : rgba(0,0,0,0)' (see Sandcastle example). Now, the performance doesn't drop, so I think it can be narrowed down to the show-behavior. Unfortunately, I can't use this workaround since the pointCloudShading doesn't work with transparent colors.

Another observation: I checked if pointCloudShading together with show causes the performance drop - but that's not the case.

I have a similar observation with a large performance hit on integrated Intel graphics (in particular Intel® UHD Graphics for 10th Gen Intel® Processors as in the i7-10510U). The issue does not show on the dedicated GPUs I have access to.
I have found a one-line fix, that improves the performance a lot in my case:
In packages/engine/Source/Shaders/Model/CPUStylingStageVS.glsl in cpuStylingStage(), comment out the following line:
void cpuStylingStage(inout vec3 positionMC, inout SelectedFeature feature)
{
    float show = ceil(feature.color.a);
    //positionMC *= show; // this line causes the performance hit

    #if defined(HAS_SELECTED_FEATURE_ID_ATTRIBUTE) && !defined(HAS_CLASSIFICATION)
    filterByPassType(positionMC, feature.color);
    #endif
}

Note that you may need to re-build Cesium to re-generate the CPUStylingStageVS.js file. Otherwise the changes won't take effect.
To anyone who is able to reproduce this performance issue, please check if this improves the performance for you.
My theory is as follows:

the line sets positionMC to zero, in case it is hidden (i.e. show is zero)

I think this was intended to move it off-screen, skipping the rasterizer and making it invisible
however, this is the wrong place to do it: positionMC is in model coordinates (not screen space yet), so we just move the points to the origin of the tile / tileset, which is likely to still be in view

the "hidden" points all get rasterized in one position, causing significant overdraw, which causes the performance hit
the "hidden" points finally get discarded in the fragment shader

A proper fix for that would be to actually move the hidden points off-screen, i.e. setting gl_Position accordingly.

be great to address

Any updates, we are no changing our data as a workaround but love to get this back

@katSchmid did you ever find any resolution to this?


Add a "Read more ..." link to post summaries

Currently, list pages display a summary of posts. It is not obvious if there is more content to read beyond the summary. This can be fixed by adding a "Read more ..." link at the bottom of a post summary, in case there is additional content in the post that is not shown in the summary. The link can point to the post's single page.
After playing around a bit, I get this desired feature by adding the following code to the end of layouts/partials/post/excerpt.html
{{- if or .Truncated .Description -}}

    Read More...

{{- end -}}

Could this be added to the code of the official theme template? I am sure others will find this useful.
Note that I am not sure about the .Description in the IF condition in the code above. It seems that if the summary is created from the description field of the frontmatter, instead of truncating the post content, then .Truncated may return false. To avoid that, I added .Description in the IF condition, assuming that code is the correct way to say "If the content has been truncated OR if the summary is generated from the description front matter field, then.." . See more here
https://github.com/gohugoio/hugo/issues/6252

The description option was introduced by #140.
I decided to use the second parameter of truncate function for doing this.


register

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/106338
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" ced6523b27422fb5ae2201edccf3bbaddfaa75fe
git push origin v0.1.0

@JuliaRegistrator register()

Registration pull request created: JuliaRegistries/General/106340
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" 677cb1fcec7ba4a0337572a9e1940afa45762ef5
git push origin v0.1.0


Error Initiating the Generator: You don't appear to have Python installed. - Python 3.7

Error
I attempted to follow the quickstart example running inside a pipenv shell.
I DO have Python 3.7 installed.
# yo flask-api my-cool-api

     _-----_     ╭──────────────────────────╮
    |       |    │    Welcome to the most   │
    |--(o)--|    │ cromulent Flask REST API │
   `---------´   │        generator!        │
    ( _´U`_ )    ╰──────────────────────────╯
    /___A___\   /
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `

? Which flavor of database will you be using with your API?
Make sure you've got it installed first, of course! (Use arrow keys)
> PostgreSQL
  MySQL
  SQLite
  None / Other
You don't appear to have Python installed. You should fix that post-haste! Try running me again when you have that sorted out.

Error flask-api my-cool-api

Aborting generation.

Environment Info
OS: Windows10
Python: 3.7.0
NPM Version:
{ npm: '6.2.0',
  ares: '1.10.1-DEV',
  cldr: '32.0',
  http_parser: '2.8.0',
  icu: '60.1',
  modules: '57',
  napi: '3',
  nghttp2: '1.32.0',
  node: '8.11.3',
  openssl: '1.0.2o',
  tz: '2017c',
  unicode: '10.0',
  uv: '1.19.1',
  v8: '6.2.414.54',
  zlib: '1.2.11' }

Python 3.7 Environment
Package      Version
------------ -------
click        6.7
flake8       3.5.0
Flask        1.0.2
itsdangerous 0.24
Jinja2       2.10
MarkupSafe   1.0
mccabe       0.6.1
pip          10.0.1
pycodestyle  2.3.1
pyflakes     1.6.0
setuptools   40.0.0
Werkzeug     0.14.1
wheel        0.31.1

Did you fix it?  I am having the same problem.

I was attempting to run this in a container. The container does not have "which" installed. I got around this error by a) making sure I had /usr/bin links to python & pip b) making sure I had which installed (the app uses which to find python)

pls fix


Bug/hero banner cta tooltip

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Test URLs:

Before: https://main--aldevron--hlxsites.hlx.page/
After: https://bug-hero-banner-cta-tooltip--aldevron--hlxsites.hlx.page/test/sample-page

what issue doe this map to?


mqtt-kafka-bridge not starting

Current Behavior
{"level":"info","ts":1637759551.8524628,"caller":"mqtt-to-postgresql/main.go:74","msg":"This is mqtt-to-postgresql build date: 2021-11-24 10:51:37"}
panic: open /SSL_certs/.pem: no such file or directory

goroutine 1 [running]:
main.newTLSConfig({0x0, 0x0})
	/build/cmd/mqtt-to-postgresql/mqtt.go:48 +0x36b
main.SetupMQTT({0x0, 0x0}, {0x0, 0x0}, {0xc00002c00b, 0x2}, {0xb8c398, 0xc000240070}, {0xc00002608c, 0x33})
	/build/cmd/mqtt-to-postgresql/mqtt.go:245 +0x2e5
main.main()
	/build/cmd/mqtt-to-postgresql/main.go:107 +0x72b

Possible solution
Is it using mqtt-to-postgresql?

@JeremyTheocharis unitedmanufacturinghub/mqtt-kafka-bridge:0.9.0-prerelease downloads mqtt-to-postgres.
Is docker hub setup correctly ?


url.Parse() doesn't set Host if the scheme is missing in the input URL.

What version of Go are you using (go version)?
Answer:  1.11.5

$ go version

Does this issue reproduce with the latest release?
Answer: Should be.
What operating system and processor architecture are you using (go env)?
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
go env Output
$ go env

What did you do?
package main

import (
    "fmt"
    "net/url"
)

func main() {

    s := "f123.mail.yahoo.com/login/ash.html"

    u, err := url.Parse(s)
    if err != nil {
        panic(err)
    }

    fmt.Println("Input url (scheme is missing):", s)
    fmt.Printf("\nurl.Parse(s) output:%#v\n",u)

    s = "http://f123.mail.yahoo.com/login/ash.html"

    u, err = url.Parse(s)
    if err != nil {
        panic(err)
    }

    fmt.Println("\nInput url (scheme is present in the URL):", s)
    fmt.Printf("\nurl.Parse(s) output:%#v\n",u)

}

What did you expect to see?
&url.URL{Scheme:"http", Opaque:"", User:(*url.Userinfo)(nil), Host:"f123.mail.yahoo.com", Path:"/login/ash.html", RawPath:"", ForceQuery:false, RawQuery:"", Fragment:""}
What did you see instead?
&url.URL{Scheme:"", Opaque:"", User:(*url.Userinfo)(nil), Host:"", Path:"f123.mail.yahoo.com/login/ash.html", RawPath:"", ForceQuery:false, RawQuery:"", Fragment:""}

Can I take a look at the issue? Or is it the expected behaviour?


feat: Add n1.medium instancetype

What this PR does / why we need it:
Add the n1.medium instancetype which still provides 4 guest cpus but only 4Gi of memory.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

Added the n1.medium instancetype which still provides 4 guest cpus but only 4Gi of memory

Thanks @0xFelix!
/lgtm

/approve


Is playwright inspector‘s default language modifiable？

Hi, is it possible to change default language of the  playwright inspector to pytest?

I love your crx and I believe it can help a lot on improving our efficiency in recording test cases.
But our automation project is based pytest and it would be great if there is a way to change the default language to pytest instead of having to manually switch to pytest every time.
I read your code in crxRecorderApp.ts and I'm wondering if I can change the default language by change this line's javascript to python?
    this._onMessage({ type: 'recorderEvent', event: 'fileChanged', params: { file: 'javascript' } });

thx~

Hi Adrianna.
I'll do a configuration option for that, similar to the TestID Attribute Name as described here:
https://github.com/ruifigueira/playwright-crx/releases/tag/v0.5.0

I implemented a new configuration to pick the default recording language:
https://github.com/ruifigueira/playwright-crx/assets/1374559/33af1c42-c0eb-46e7-81e8-27ef81a1cf6a
I'll align its release with playwright 1.45

I just released playwright-crx 0.7.1. it now has the ability to pick the default language.
https://github.com/ruifigueira/playwright-crx/releases/tag/v0.7.1


Liveview 0.18.0?

Is it possible to support Liveview 0.18.0?

Yes, very soon!

Yes, very soon!

🎉  Woohoo!!!!

@aselder The mc-lv018 branch supports LiveView 0.18.0– if you are able to try it please let me know how it goes! :)

i could only find main and mc-endpoint branches otherwise i would have tested :)

It has already been merged :)
v0.2.0 of the profiler supports LiveView 0.18+

what a rookie! thank you :)


ec gates for snarkyrs

This is #1764 but directly merging on master, the comments from #1764 still need to be addressed but the interface should remain the same.

@fabrizio-m If we decide to go forward, I suggest to close this PR, because the other one (https://github.com/o1-labs/proof-systems/pull/1764) already targets master and it has comments, while this is a clone. What do you think?


Introduce a Registry class to hold implementation mapping

Summary
Registry is a Singleton class that can hold all implementation mappings like system parses or test strategies. All default implementations are registered in CloudAI's __init_.py file, but users can easily extend the mapping or even replace default implementation with a custom one.
Test Plan
CI
Additional Notes
—

LGTM. Let's discuss further with @srinivas212.

Potential improvement (out of scope for this PR): add GHA summary for pytest results (e.g. https://github.com/marketplace/actions/pytest-summary)