[OUDS] Docs: add 'Getting Started > JavaScript' page

[!WARNING]
This PR stays valid but is on hold until we actually have our first official JavaScript components for OUDS Web

Related issues
Listed in https://github.com/Orange-OpenSource/Orange-Boosted-Bootstrap/issues/2589
Description
This PR adds the "Getting Started > Contribute" page based on:

the previous corresponding Boosted page (see code source)
the corresponding Bootstrap page (see code source)

[!IMPORTANT]
Everything that is described in this page must be tested!
To help you do the review, I've created some CodePens:

OUDS Web - Toast - ouds-web.bundle.min.js
OUDS Web - Popover - ouds-web.esm.min.js

Types of change

New documentation (non-breaking change which adds functionality)

Live previews

https://deploy-preview-2648--boosted.netlify.app/docs/0.0/getting-started/javascript/

In the importmap, shouldn't it be @ouds/web instead of ouds-web? anyway it has no impact.

Hum, should be the name of the library, shouldn't it? So "ouds-web".

In the importmap, shouldn't it be @ouds/web instead of ouds-web? anyway it has no impact.

Yes, you're right, it's done like this for Popper. I've updated the CodePens and the PR with https://github.com/Orange-OpenSource/Orange-Boosted-Bootstrap/pull/2648/commits/94fc64cc5a3e6b5f8f7383be846907376ad39174


WIP: Shutdown immediately if there isn't a running sub process

Release note:
NONE

I moved this to a branch against master and made further improvements to the tests.
See #174


Working docker demo on python 3.9 with the AWS X-Ray daemon installed in the docker image. also includes a script that fires off many API (curl) requests that are used to verify your AWS X-Ray IAMs are correct.

Issue #, if available:
The master branch failed to build the Docker image on python 3.6 due to urllib3 pip versioning conflicts.
Description of changes:
Included build works on python 3.9 with the docker image using:

Runs as a non-root user (driver)
A python virtualenv
AWS CLI v2 installed
AWS X-Ray daemon installed (enabled/disabled on startup with the environment variable XRAY_DAEMON_ENABLED)

Added a docker build script, a docker compose start script, and a readme showing how to:

Set up the demo (build.sh + start.sh)
Run the demo script that fires off curl tests (run-xray-demo.sh)
Debug issues

General fixes

Demo uses docker compose with AWS environment variable installation to verify IAM access
Removed pinned python pip versions in the requirements.txt
Added flake8/pep8
Colorized logging
Support for additional logging using an environment variable VERBOSE=1 on container startup

Assuming the flask application and the AWS X-Ray daemon are running correctly, the test script's API calls will show up in the AWS X-Ray UI for review.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks for this change! I can confirm that the Docker Sample App does not work on master:
$ docker build -t aws-xray-python-demo-app .
…
#9 5.161 ERROR: Cannot install -r requirements.txt (line 10) and urllib3==1.26.5 because these package versions have conflicting dependencies.
#9 5.161
#9 5.161 The conflict is caused by:
#9 5.161     The user requested urllib3==1.26.5
#9 5.161     requests 2.23.0 depends on urllib3!=1.25.0, !=1.25.1, <1.26 and >=1.21.1
#9 5.161
#9 5.161 To fix this you could try to:
#9 5.161 1. loosen the range of package versions you've specified
#9 5.161 2. remove package versions to allow pip attempt to solve the dependency conflict
#9 5.161
#9 5.161 ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies
#9 5.348 WARNING: You are using pip version 21.2.4; however, version 21.3.1 is available.
#9 5.348 You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command.
------
executor failed running [/bin/sh -c pip install -r requirements.txt]: exit code: 1

And I can see that building it using your branch fixes the problem and the app runs well 🙂
I really enjoyed reading your PR because your bash scripts are really useful and I learned a lot of neat things about them! However, I'm thinking we shouldn't take them on in this repo at this time because the goal is to just show a quick demo of how you might use the AWS X-Ray SDK and these scripts and extra packages would increase our technical debt quite a bit 😕
I'm not sure why it was pinned to that version originally, but I noticed that if we change
urllib3==1.26.5

to
urllib3~=1.25

then the Dockerfile works for both python3.6 and python3.9! If that's okay with you, would you be willing to make this PR only have this one line change? 🙂 It's a great call out and hopefully this way we can make the experience better for new users.
One other thing that I think your PR does great is that it adds a README to this folder! We could definitely benefit from that, but perhaps we could just mention using the regular docker build -t aws-xray-python-demo-app . command just to help get users started?
Let me know what you think!


inference.ipynb audio output silent

Hi, I'm trying to run the inference.ipynb with the published models, neither model got errors.

Also there are no problems with the plot results:

But when I try to play the audio output, there is no voice, my speakers are definitely detecting a sound but it's just white noise, and yet again there are no explicit errors.

I'm very new to voice synthesis, there might be something I overlooked, but I followed the indications to the t, so I'm not sure what could have gone wrong.
I have looked through other issues but I haven't seen any problem similar to this, if I have missed it, thank you for redirecting me to those issues.
any help would be appreciated.

I also have this problem, have you solved it？

@holynova-SD  No, not yet, sorry. I access it by remote server. I was thinking maybe it had an impact on the ability to get the output back? (not sure why it would though, but I don't see what else could be the problem)
Are you running notebook locally?

Probably waveglow is producing ndarrat of Nans.
to debug try: print(audio[0].data.cpu().numpy())
Change loading model to this, it worked for me: waveglow = torch.hub.load('nvidia/DeepLearningExamples:torchhub', 'nvidia_waveglow')

Hi
Avoid to transfer waveglow weights to fp16 will solve the issue.
regards

just remove .half() twice on ipynb will solve this problem

just remove .half() twice on ipynb will solve this problem

Hi，inferece code still generates empty outpt(0.00s)  after I remove the .half() twice ,could you give me other advice? (I run the code in docker,I don't know whether it's the main reason.)

hi,I run inference.ipynb  directly on colab，but，But I made this mistake. How can I solve it

just remove .half() twice on ipynb will solve this problem

Thank you very much.i have succeeded

just remove .half() twice on ipynb will solve this problem

Thank you very much.i have succeeded

Thank you, I'm also succeeded. ：）

Probably waveglow is producing ndarray of NaNs.
to debug try: print(audio[0].data.cpu().numpy())
Change loading model to this, it worked for me: waveglow = torch.hub.load('nvidia/DeepLearningExamples:torchhub', 'nvidia_waveglow')

Genuis！！！


chore: speakeasy migrate workflows

Migrations to speakeasy workflow which enables speakeasy run : https://www.speakeasyapi.dev/docs/workflow-migration

@bgroff - Looks okay to me but you're more familiar with this repo. I'll let you make the call to merge.


Impact: Research on ways to implement basic version

The current Impact page uses a lot of Elementor plugins and widgets to format the page. However, this approach can't be extended to Ghost as easily, since it does not offer a drag-and-drop editing experience. Research needs to be done to identify possible approaches to implementing an Impact page (which need not necessarily follow the original format, but should be able to showcase metrics nicely).

As discussed, a MVP that replicates the content on https://advisory.sg/our-impact/ should be implemented.


Encountered an installation issue

I tried to install ScreenToGif on my macOS with ./build.sh.  Everything looks good.
$ ./build.sh
Feeds used:
  https://api.nuget.org/v3/index.json

Restoring NuGet package Cake.0.34.1.
  GET https://api.nuget.org/v3-flatcontainer/cake/0.34.1/cake.0.34.1.nupkg
  OK https://api.nuget.org/v3-flatcontainer/cake/0.34.1/cake.0.34.1.nupkg 971ms
Installing Cake 0.34.1.

After a while, I encountered the following issue.
Controls/VideoSourceKindList.xaml.cs(1,22):` error CS0234: The type or namespace name 'Controls' does not exist in the namespace 'System.Windows' (are you missing an assembly reference?) [/Users/sparkandshine/Downloads/Captura/src/Captura/Captura.csproj]
ImageEditor/DynamicRenderers/ArrowDynamicRenderer.cs(4,22): error CS0234: The type or namespace name 'Ink' does not exist in the namespace 'System.Windows' (are you missing an assembly reference?) [/Users/sparkandshine/Downloads/Captura/src/Captura/Captura.csproj]
ImageEditor/DynamicRenderers/ArrowDynamicRenderer.cs(6,28): error CS0234: The type or namespace name 'StylusPlugIns' does not exist in the namespace 'System.Windows.Input' (are you missing an assembly reference?) [/Users/sparkandshine/Downloads/Captura/src/Captura/Captura.csproj]
ImageEditor/DynamicRenderers/IDynamicRenderer.cs(1,22): error CS0234: The type or namespace name 'Ink' does not exist in the namespace 'System.Windows' (are you missing an assembly reference?) [/Users/sparkandshine/Downloads/Captura/src/Captura/Captura.csproj]
ImageEditor/Strokes/ArrowStroke.cs(2,22): error CS0234: The type or namespace name 'Ink' does not exist in the namespace 'System.Windows' (are you missing an assembly reference?) [/Users/sparkandshine/Downloads/Captura/src/Captura/Captura.csproj]
ImageEditor/DynamicRenderers/EllipseDynamicRenderer.cs(3,22): error CS0234: The type or namespace name 'Ink' does not exist in the namespace 'System.Windows' (are you missing an assembly reference?) [/Users/sparkandshine/Downloads/Captura/src/Captura/Captura.csproj]

I'm sorry, but I could not understand what's happening.
ScreenToGif was built with WPF, which is not supported in macOS, so I'm not sure if it works with Cake.
Also, your exception messages point to the Captura project, not to ScreenToGif.

I'm going to close this because of inactivity.


HikariJNDIFactory should not throw a NamingException when !"javax.sql.DataSource".equals(ref.getClassName())

The JavaDoc of ObjectFactory.getObjectInstance(Object, Name, Context, Hashtable) : Object specifies this behaviour:
"An object factory should only throw an exception if it is sure that it is the only intended factory and that no other object factories should be tried. If this factory cannot create an object using the arguments supplied, it should return null."
So if one configured multiple ObjectFactories to be asked if they can create a specific type by setting  java.naming.factory.object to a list of object factories HikariJNDIFactory will prevent other factories from being consulted.
org.apache.commons.dbcp2.BasicDataSourceFactory does it this way:
    if (!"javax.sql.DataSource".equals(ref.getClassName())) {
        return null;
    }

Can you please submit a pull request?


Macbook Pro Early 2011: Question

Is it possible to activate CAT without a dongle? CompatibilityChart says i need hardware upgrade BUT i only need Universal Clipboard

OS Version: 10.12.5 (16F73)
Mac model: Macbook Pro Early 2011
Dongle or replaced card?: NO
Used dongle/card: NO

Thank you for your answer

I'm currently not aware of any way this is possible.


Improve Portuguese translation of Build Measure Learn guide

Fixed mistakes and improved some wording and punctuation.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉


[Ops] Support for conv_transpose2d op (ttnn.conv_transpose2d)

Related to : #13639

FYI @nvukobratTT , ttnn.conv_transpose2d is supported now in ttnn

Blocked by this issue for the metal side: https://github.com/tenstorrent/tt-metal/issues/15551


Reconcile difference between dynamic tags, literal tags, and manual creation

Problem
With the introduction of dynamic tags in #1266 there are now three different ways of constructing HTML tags:

Using literal tags in the html! macro ()
Dynamic tags in the macro (<@{"span"}></@>)
Creating VTag instances manually (VTag::new("span"))

All three of these have different restrictions with the third option (manually constructing) having virtually none at all.
Dynamic tags try to have the same restrictions as literal ones using runtime checks but there are still a few differences:

dynamic tags are always converted to lower case. While  and <@{"sPAN"}></@> produce equivalent HTML, Yew currently stores the former as "sPAN" internally and the latter as "span".
literal tags must be valid rust identifiers with the exception that they may contain hyphens (-) anywhere in the middle. Dynamic tags can use any ASCII character at any position.
void elements must be self closing using literal tags
 but dynamic tags can do <@{"br"}></@>. I think this one is actually a good thing because it gives dynamic tags more flexibility without any downside.

There's another issue that currently plagues both macro methods. They only allow tag names containing characters in the ASCII range. This is too broad for normal tag names which only allow for alphanumerics[1] but it's also too narrow for custom elements which support a big range of characters outside of the ASCII range[2].
Somewhat related to this issue is that Yew currently preserves the casing for tag names. This can easily lead to bugs like this:
let vtag = VTag::new("dIV");
if vtag.tag == "div" {
  println!("it's a div!");
}

Proposal
All three methods should have exactly the same rules. For the literal case these rules should be enforced during compilation while the other two need runtime checks.
Valid Tag Names
The VTag constructor ensures the given tag name is valid.
It might be a good idea to use a wrapper type TagName internally. This type could be treated just like a normal string but it can only contain valid tag names. It would also make it easier to ignore casing when comparing names.
Void Element
Void elements must not have any children. To guard against this we store a allow_children flag in VTag which is set in the constructor by comparing the tag name against the list of void elements.
The add_child method is modified to check this flag first.
Special Attributes
The attribute value needs to be handled differently depending on the tag name.
This can be done by adding a check to the set_value method which forwards the value to the attributes instead if the tag isn't input or textarea.

In all these cases the literal tags in macros should already perform the checks during compilation.
To avoid the performance penalty there should be "private" methods which avoid the checks entirely which can then be used by the macro.
There should also be equivalent methods that return a Result instead of panicking.
This gives us a structure like this:
// used by normal users
fn do() -> T {
  try_do().expect("appropriate message")
}

// can be used by libraries and cases where an error is expected
fn try_do() -> Result<T, E> {
  // perform the various checks

  Ok(unchecked_do())
}

// used by macro
fn unchecked_do() -> T {
  // do the thing
}

Per the discussion we had on #1344 , I would question why we need dynamic strings as tag values at all. For HTML, MathML, and SVG elements, these should be easy to represent as some built-in Yew enum which could be represented as a &'static str in code but converted to an enum value through macros.
In the case of custom elements, maybe that could be declared via some configuration, possibly in Cargo.toml or just in Yew config, stored as a type inside App or in some other Yew config location. That way we can avoid checking every tag name is valid at runtime as well as needing to bundle a list of valid tags in the main bundle.

That said, I could see a use case for this type of pattern as well which could be good to keep in mind when we are implementing a solution for this Issue:
let z = if some_condition {
  Box
} else {
  Circle
};

return <@{z}></@>

After doing some more research, a couple of modifications to my stance:

The branching on types I suggested in the above comment seems unwise / out of scope, since it would be moving type resolution to runtime, escaping Rust's type safety. A generic could achieve the same result.
Sorry, I didn't realize dynamic tags are basically brand-new. I can understand the want for them if regular HTML-style tag instantiation isn't working for custom tags with non-ASCII names, although still not sure about the differences long-term between those two styles. Was access to custom elements the main motivation for creating them?
Although WhatWG specifies that custom tags should be lowercase, browsers still let you reference them with uppercase versions. However, not all upper/lower case variants are defined the same. For instance, Chrome lets you define a custom tag called image-a and then when you instantiate it as <image-A />, it works. However, if you define it as image-ê and reference it as image-Ê, it doesn't work. So we must be mindful of the different notions Unicode has of capitalization and make sure we don't stray beyond actual browser behavior.

One more observation- although SVG has some elements that are defined as having capital letters in them such as <linearGradient />, the browsers I tested (Chrome, Firefox, Safari) all respond to <lineargradient /> as well.

Using an enum which contains all possible tag names isn't a terrible idea. We can use it in conjunction with a tag_name! macro that returns the appropriate variant from a string. Custom element names could be stored in a special variant:
enum TagName {
  Div,
  // ...
  Custom(String),
}

Using this dynamic tag names would no longer accept a String but instead a variant of TagName.

That way we can avoid checking every tag name is valid at runtime as well as needing to bundle a list of valid tags in the main bundle.

In most cases this doesn't apply anyway. The most common case is creating a tag name through the macro where the names are verified at compile-time. The only case where we need to check tag names at runtime is for dynamic tag names (be it through the macro or using VTag::new). As long as we have the ability to create dynamic tags there's no way to avoid a runtime check. Even if we have an enum we would have to implement From<String> on it.

Was access to custom elements the main motivation for creating them?

No, it sure is a nice side-effect but the primary reason for them is to create dynamic tag names. There are cases where using a match statement would be needlessly verbose. It also works for higher order components that allow you to pass the tag type.

To summarise: I'm not against the idea of using an enum for tag names. In fact I've thought about it a lot myself. However, I think we need to make a strong case as to why it's beneficial in the long run.
I feel like this is something @jstarry would need to weigh in on.

Although WhatWG specifies that custom tags should be lowercase, browsers still let you reference them with uppercase versions.

That's exactly what the standard dictates:

In the HTML syntax, tag names, even those for foreign elements, may be written with any mix of lower- and uppercase letters that, when converted to all-lowercase, matches the element's tag name; tag names are case-insensitive.

if you define it as image-ê and reference it as image-Ê, it doesn't work.

Custom element names aren't case-insensitive in the same way. They're not allowed to use ASCII upper alpha but they any other character is case-sensitive.

One more observation- although SVG has some elements that are defined as having capital letters in them

Although tag names are case-insensitive the standard sometimes defines a canonical representation. This isn't really relevant to us because the representation doesn't matter for the lookup.

Been thinking about this some more...

All three methods should have exactly the same rules

I'm not sure whether this is possible. It seems like macros are not able to parse arbitrary UTF8 sequences from files... which some custom tag names have (within restriction). That said, the capitalization issues are probably at least something we can fix.

Dynamic tags can use any ASCII character at any position.

This isn't quite true, dynamic tags have to begin with a non-hyphen. There is some question though about whether we could expand the definition of a dashed name to be more inclusive, although I suspect it would only be by a little, such as having a hyphen at the end perhaps.

We can use it in conjunction with a tag_name! macro that returns the appropriate variant from a string. Custom element names could be stored in a special variant

I assume by this it was meant that in the normal case, one would not have to use this macro?
I suppose we could have the HTML tag macro accept any of div, span, table, etc. which are actually Rust symbols imported from a prelude somewhere, corresponding to say yew::tags::{div, span, table}. And then, if someone wanted to specify a custom tag, they could import yew::tags::{Custom} and do
<Custom("my-custom-tag")>{ "foo" }</Custom("my-custom-tag")>
Assuming this works, would the tag_name! macro still be needed?

@philip-peterson Just a quick clarification:

Dynamic tags can use any ASCII character at any position.

This isn't quite true, dynamic tags have to begin with a non-hyphen. There is some question though about whether we could expand the definition of a dashed name to be more inclusive, although I suspect it would only be by a little, such as having a hyphen at the end perhaps.

I was talking about how it's currently implemented, not how it should be. You can see the runtime check that is inserted here: https://github.com/yewstack/yew/blob/151b5b7db954e6d3f5f6ad5be0c0991131adde26/yew-macro/src/html_tree/html_tag/mod.rs#L110-L124

All three methods should have exactly the same rules

I'm not sure whether this is possible. It seems like macros are not able to parse arbitrary UTF8 sequences from files... which some custom tag names have (within restriction). That said, the capitalization issues are probably at least something we can fix.

You're right, I mentioned that literal tags need to consist of valid rust identifiers. If you try to use invalid characters then compilation fails even before the macro comes into play so there's really nothing we can do about this.
In these rare cases dynamic tag names should come in handy.

We can use it in conjunction with a tag_name! macro that returns the appropriate variant from a string. Custom element names could be stored in a special variant

I assume by this it was meant that in the normal case, one would not have to use this macro?
I suppose we could have the HTML tag macro accept any of div, span, table, etc. which are actually Rust symbols imported from a prelude somewhere, corresponding to say yew::tags::{div, span, table}. And then, if someone wanted to specify a custom tag, they could import yew::tags::{Custom} and do
<Custom("my-custom-tag")>{ "foo" }</Custom("my-custom-tag")>
Assuming this works, would the tag_name! macro still be needed?

The tag_name! macro I have in mind actually works to enhance the setup you mentioned.
Let's look at the syn crate. Syn has a Token! macro which is very similar to what I have in mind.
There is a module syn::token that contains various Rust tokens and keyword (very similar to your tags module). Instead of accessing the members of said module directly syn recommends you use the Token macro.
Token![static] then resolves to syn::token::Static.
Here's a few benefits of doing it this way:

No need to bring the tags into scope or memorise the struct name. We can just use the tags exactly like we would write them in HTML.
We can easily detect custom element names and verify their validity at compile time (Of course there's still the problem with unicode characters  but this is easily solved by allowing literal strings in the macro).
Using the macro we can provide more detailed feedback to the developer.
We can integrate this macro directly into the html! macro. html! {
 } -> VTag::new(tag_name!(div)) -> VTag::new(yew::tags::Div).

I personally think that dynamic tags aren’t necessary and are just unnecessarily increase binary sizes.
IMO they’re a “solution in search of a problem.”
They make Yew unsafe because the statics of a program don’t line up with the dynamics (by their nature) which makes it easy for mistakes to creep in (this isn’t really idiomatic Rust which I think is fundamentally about being safe – safe in the sense of having aligning statics and dynamics).
It would be nice to see some examples of why dynamic tags are needed and use cases in which a problem can be better solved by using a dynamically computed tag name than using the features Rust already provides.
Please let me know if I’ve misunderstood anything.

On 7 Jul 2020, at 12:31, Simon<EMAIL_ADDRESS>wrote:
@philip-peterson https://github.com/philip-peterson Just a quick clarification:
Dynamic tags can use any ASCII character at any position.
This isn't quite true, dynamic tags have to begin with a non-hyphen. There is some question though about whether we could expand the definition of a dashed name to be more inclusive, although I suspect it would only be by a little, such as having a hyphen at the end perhaps.
I was talking about how it's currently implemented, not how it should be. You can see the runtime check that is inserted here: https://github.com/yewstack/yew/blob/151b5b7db954e6d3f5f6ad5be0c0991131adde26/yew-macro/src/html_tree/html_tag/mod.rs#L110-L124 https://github.com/yewstack/yew/blob/151b5b7db954e6d3f5f6ad5be0c0991131adde26/yew-macro/src/html_tree/html_tag/mod.rs#L110-L124
All three methods should have exactly the same rules
I'm not sure whether this is possible. It seems like macros are not able to parse arbitrary UTF8 sequences from files... which some custom tag names have (within restriction). That said, the capitalization issues are probably at least something we can fix.
You're right, I mentioned that literal tags need to consist of valid rust identifiers. If you try to use invalid characters then compilation fails even before the macro comes into play so there's really nothing we can do about this.
In these rare cases dynamic tag names should come in handy.
We can use it in conjunction with a tag_name! macro that returns the appropriate variant from a string. Custom element names could be stored in a special variant
I assume by this it was meant that in the normal case, one would not have to use this macro?
I suppose we could have the HTML tag macro accept any of div, span, table, etc. which are actually Rust symbols imported from a prelude somewhere, corresponding to say yew::tags::{div, span, table}. And then, if someone wanted to specify a custom tag, they could import yew::tags::{Custom} and do
<Custom("my-custom-tag")>{ "foo" }</Custom("my-custom-tag")>
Assuming this works, would the tag_name! macro still be needed?
The tag_name! macro I have in mind actually works to enhance the setup you mentioned.
Let's look at the syn https://docs.rs/syn/1.0.33/syn/ crate. Syn has a Token! https://docs.rs/syn/1.0.33/syn/macro.Token.html macro which is very similar to what I have in mind.
There is a module syn::token https://docs.rs/syn/1.0.33/syn/token that contains various Rust tokens and keyword (very similar to your tags module). Instead of accessing the members of said module directly syn recommends you use the Token macro.
Token![static] then resolves to syn::token::Static https://docs.rs/syn/1.0.33/syn/token/struct.Static.html.
Here's a few benefits of doing it this way:
No need to bring the tags into scope or memorise the struct name. We can just use the tags exactly like we would write them in HTML.
We can easily detect custom element names and verify their validity at compile time (Of course there's still the problem with unicode characters but this is easily solved by allowing literal strings in the macro).
Using the macro we can provide more detailed feedback to the developer.
We can integrate this macro directly into the html! macro. html! {  } -> VTag::new(tag_name!(div)) -> VTag::new(yew::tags::Div).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/yewstack/yew/issues/1269#issuecomment-654791395, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKFSTPMZELK5ZF6NKG7PG63R2MBQFANCNFSM4NNFF4SQ.

@teymour-aldridge Just to clarify: I don't particularly care whether Yew supports dynamic tag names or not - I'm playing the devil's advocate here. This discussion also isn't only about dynamic tag names. The same thing is possible with VTag::new but with even less restrictions.
Here's an example of something that dynamic tags make possible:
Let's say we have a typography component for headings which accepts the level (h1 - h6) as a prop.
This is what it looks like using dynamic tag names:
// ensure that 1 <= level <= 6
let h_tag = format!("h{}", level);
<@{h_tag}>{ contents }</@>

And here's the same without:
match level {
  1 => html! {
{ contents }
 },
  2 => html! {
{ contents }
 },
  3 => html! {
{ contents }
 },
  4 => html! {
{ contents }
 },
  5 => html! {
{ contents }
 },
  6 => html! {
{ contents }
 },
  _ => panic!("invalid header level"),
}

This isn't terribly bad but I'm doing it a lot of favours such as not using any attributes. Just imagine what it would look like if we wanted to add an onclick listener to this.
Dynamic tags are only really useful for higher order components. It's important that we support this because it makes it a lot easier to create component libraries.
Let's try to abstract this problem a bit more. The underlying problem here is that we're unable to propagate tag names. There's no way for our hypothetical component to accept h1 - h6 as a value without going using an opaque representation like a string or a number representing the level.
In the macro tag names work like types but outside of it they don't exist; they're just strings. In a way, dynamic tag names are a patch solution for the inability to pass tag names around transparently.
All of this could be solved if we adopted a solution where each tag name is assigned a type. It would give us the ability to transparently pass tag names to components with type checking.
Here's what the same component might look like with statically typed tag names:
use yew::tags::{H1, H2, H3, H4, H5, H6};

// this is just a marker trait to ensure that `Heading` is only used with heading tags.
trait HTag {}
impl HTag for H1 {}
impl HTag for H2 {}
impl HTag for H3 {}
impl HTag for H4 {}
impl HTag for H5 {}
impl HTag for H6 {}

struct Props<T> {
    tag: T,
    text: String,
}
struct Heading<H: HTag> {
    props: Props<H>,
}
impl<H: HTag> Component for Heading<H> {
    type Props = Props<H>;

    fn view(&self) -> Html {
        let Props { tag, text } = &self.props;
        html! {
            <@{tag}>{ text }</@>
        }
    }
}

Note that in this example the syntax for dynamic tag names no longer accepts strings, only members from the yew::tags. How this is to be achieved is still up for discussion but either way, this accomplishes type safety and doesn't depend on any runtime checks.

Thanks for this explanation – it’s really helpful!
I also now see why dynamic tags can be useful.

On 7 Jul 2020, at 13:31, Simon<EMAIL_ADDRESS>wrote:
@teymour-aldridge https://github.com/teymour-aldridge Just to clarify: I don't particularly care whether Yew supports dynamic tag names or not - I'm playing the devil's advocate here. This discussion also isn't only about dynamic tag names. The same thing is possible with VTag::new but with even less restrictions.
Here's an example of something that dynamic tags make possible:
Let's say we have a typography component for headings which accepts the level (h1 - h6) as a prop.
This is what it looks like using dynamic tag names:
// ensure that 1 <= level <= 6
let h_tag = format!("h{}", level);
<@{h_tag}>{ contents }</@>
And here's the same without:
match level {
1 => html! { { contents } },
2 => html! { { contents } },
3 => html! { { contents } },
4 => html! { { contents } },
5 => html! { { contents } },
6 => html! { { contents } },
_ => panic!("invalid header level"),
}
This isn't terribly bad but I'm doing it a lot of favours such as not using any attributes. Just imagine what it would look like if we wanted to add an onclick listener to this.
Dynamic tags are only really useful for higher order components. It's important that we support this because it makes it a lot easier to create component libraries.
Let's try to abstract this problem a bit more. The underlying problem here is that we're unable to propagate tag names. There's no way for our hypothetical component to accept h1 - h6 as a value without going using an opaque representation like a string or a number representing the level.
In the macro tag names work like types but outside of it they don't exist; they're just strings. In a way, dynamic tag names are a patch solution for the inability to pass tag names around transparently.
All of this could be solved if we adopted a solution where each tag name is assigned a type. It would give us the ability to transparently pass tag names to components with type checking.
Here's what the same component might look like with statically typed tag names:
use yew::tags::{H1, H2, H3, H4, H5, H6};
// this is just a marker trait to ensure that Heading is only used with heading tags.
trait HTag {}
impl HTag for H1 {}
impl HTag for H2 {}
impl HTag for H3 {}
impl HTag for H4 {}
impl HTag for H5 {}
impl HTag for H6 {}
struct Props {
tag: T,
text: String,
}
struct Heading<H: HTag> {
props: Props,
}
impl<H: HTag> Component for Heading {
type Props = Props;
fn view(&self) -> Html {
    let Props { tag, text } = &self.props;
    html! {
        <@{tag}>{ text }</@>
    }
}

}
Note that in this example the syntax for dynamic tag names no longer accepts strings, only members from the yew::tags. How this is to be achieved is still up for discussion but either way, this accomplishes type safety and doesn't depend on any runtime checks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/yewstack/yew/issues/1269#issuecomment-654823209, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKFSTPKPGEO4JDMAANZ2MBDR2MIRRANCNFSM4NNFF4SQ.

I agree with what you say @siku2 , having the macro would be useful for construction using VTag::new. If we do have a tags module though it would be best IMO to have the tag names lowercased, because then when you see an title cased symbol you’ll know it’s a type / component.
For the example provided with the dynamic tag name, would that value passed into @{} not be a string currently? If in the new world, literal tag names are types, you could just construct a tag using the literal syntax but also the generic param, so it could be like <H>{ “foo” }</H> and you wouldn’t need a dynamic tag name. Dynamic tag construction could still be useful for H{1,2,...,6} construction though, as you say, or using a prop to determine what kind of element will be the root of a component’s return value.

One more observation- although SVG has some elements that are defined as having capital letters in them such as , the browsers I tested (Chrome, Firefox, Safari) all respond to  as well.

This might be a recent regression in browsers but it seems that this no longer holds true.

I have a somewhat different view on treating browser-behavior: We shouldn't try to get in the way, except for debug_assertions and compile time checks. When running in release mode, all bets can be off. At this point, we shouldn't insert a check if a dynamic void element contains children. Let the browser handle that. A custom defined element that contains illegal characters? Also let the browser handle this.
I also don't think a enumeration of "allowable" tag names will do much good, if it's for more than debug-assertions and linting. It will eventually get out of date, besides the number of svg elements already being rather large. This list doesn't have to leak into the final binary.
For capitalization, I'm not even sure about the rules the browsers currently implement. For example, an inline <svg> without a xml namespace declaration currently seems to follow normal HTML rules for contained elements, in Firefox. I don't think we can or should reproduce this rule set in yew. Just try our best to warn the programmer, follow an internal standard (i.e. all tag names are lowercase when coming from the literal macro) and reconcile in a straight-foward way, without attempting to normalize input we have no control over - at least in production mode.
Now, the special casing for "input" and "textarea" et al should stay and work regardless of casing.


ROX-24119: Configure node-inventory container to be privileged

Description
This should prevent the node-inventory container triggering SELinux violations on OpenShift with SELinux enabled.
This has already been tested with an overlay in ACSCS in the integration environment.
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
Testing in ACSCS integration environment.
The Grafana dashboard shows no SELinux violations.

I've been involved in the whole process and have seen the Grafana Dashboards before the change.
Looks great, thank you for the PR!

/retest

Please merge if the failing test are flakes.

/retest

/retest

I didn't do in depth analysis of the tests failing here, but they look unrelated. Do you maybe want to merge this @mclasmeier ?


Question: How are post URLs determined?

With the minima theme (https://github.com/jekyll/minima), anything in my _posts dir named 2019-09-19-ubuntu-18-post-install-steps.md automatically gets placed at the URL /2019/09/19/ubuntu-18-post-install-steps.html. However, with the minimal-mistakes theme it seems to go to /ubuntu-18-post-install-steps/ instead. This means I need to set up redirects (https://github.com/mmistakes/minimal-mistakes/issues/551#issuecomment-249037145) as I migrate to your theme.

How does the automatic URL get set?

Can we change this if we like? How?

What advantages does it have over the minima style which is categorized by year/month/day, and ends in .html instead of just /?

You can always set your permalink style in _config.yml. Check the Jekyll documentation for more information.


Forward references

Hello, there's some food for thought. Imagine a class referencing itself.
@attr.s
class A:
    a: 'A' = attr.ib()

This is the proper way of doing this as per mypy. In the case of attrs though:
>>> attr.fields(A).a
Attribute(name='a', default=NOTHING, validator=None, repr=True, cmp=True, hash=None, init=True, convert=None, metadata=mappingproxy({}), type='A')

The string just gets copied into the type attribute. A.__annotations__ has the same problem. Ideally the type would be the actual class object. Mypy deals with this by having more than one pass when parsing.
The first question to answer if whether we should deal with this here, in attrs, or let code making use of the type attribute deal with it. Maybe instead of expecting higher levels to deal with this, Python itself should handle it (although good luck waiting for this :). I think it's worth trying to deal with this problem in attrs, to make it easier for others.
Dealing with just a class referencing itself is very doable. Now imagine circular references.
@attr.s
class A:
    b: 'B' = attr.ib()

@attr.s
class B:
    a: A = attr.ib()

Not really sure what to do here.

This issue was initially motivated by https://github.com/Tinche/cattrs/issues/13.

GitHub doesn't have enough Emojis for this one.

As I understand it, and especially with PEP 563 in the picture, I'd argue the current behaviour is the most correct one. Especially as performance was one of the motivations for the change:

type hints are executed at module import time, which is not computationally free

typing.get_type_hints() already works as expected on attr classes.

Is this still relevant with from __future__ import annotations @Tinche? My gut feeling is that if we start doing our own thing, it’s gonna fall on our feet.

Yeah, I haven't really looked into this in depth again yet but I think this is out of scope for attrs now.

FYI we have attr.resolve_types() now.


Added missing direct dependencies to install_requires

Found in https://github.com/conda-forge/trading-calendars-feedstock/pull/1

I actually don't think we should have -e as part of the requirements.

I'd lean to either (c) or (a) - apologies, should have mentioned that in my original comment.

Ok, let's go with (a) the simplest choice. If it ever becomes an actual burden to update both locations, we can rethink it.


Handle deprecated NSCalendar Date Units When Compiled Under iOS 8

Handle deprecated NSCalendar Date Units

This pull request fixes commit  203f72d by taking into account support version lower than iOS 8


shisho: init at 0.5.2

Description of changes

Package shisho for nixpkgs
It's an engine for finding certain code and potentially changing it similar to semgrep, written in rust, and powered in part by treesitter
Things done

Built on platform(s)

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

[X] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[X] 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

[X] 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
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

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

1 package built:

shisho

Nice, thank you for contributing!


Bug: Extractor doesn't parse the HTML files for Angular v19

Is there an existing issue for this?

[X] I have searched the existing issues

Is this a regression?
Yes
Current behavior
when I run "npm run i18n:extract" as "transloco-keys-manager extract" it doesn't read my keys in HTML files. I have attached the link to reproduce the error.

Expected behavior
it should extract the keys in json files
Please provide a link to a minimal reproduction of the bug
https://stackblitz.com/edit/stackblitz-starters-5dhmqs?file=src%2Fapp%2Fapp.component.ts
Transloco Config
No response
Debug Logs
No response
Please provide the environment you discovered this bug in
Transloco: 7.5.0
Transloco Keys Manager: 6.0.0
Angular: 19.0.0
Node: 22.11.0
Package Manager: npm
OS: MAcOs

Additional context
No response
I would like to make a pull request for this bug
No

@shaharkazaz I found out to just update the package.json with v19 for Angular. Here is a PR that fix the issue! Thanks

While #210 is not released, you can workaround this issue by adding the following to your package.json:
"overrides": {
  "@jsverse/transloco-keys-manager": {
    "@angular/compiler": "^19.0.0"
  }
}

Released in v6.1.0


Responder should remove the previously appended request message in error handling of appending response

This is a follow-up issue of #24 and #99.
In #99, it also mentioned that:
For the Responder, the error handling of appending response should also remove the previously appended request message
But this seems not implemented.
Take the code below for example, the responder should shrink message buffer A within the second if (RETURN_ERROR(status)) at line 249 to remove the request message cached at line 239.
https://github.com/DMTF/libspdm/blob/d9d646b9b226c595fba5f61acbe5ffaac4749b67/library/spdm_responder_lib/libspdm_rsp_capabilities.c#L237-L253

Currently, it is hard to remove or shrink, because we use hash extend to save memory space. We need a robust way to append message.
On the other hand, I think VCA must be appended successfully. Otherwise, the connection can never be established.
@steven-bellock, @taprinz, what do you think? Do we really need error handling here? Or just assert?

I would argue against assert - I think getting an invalid message is a possibility that the Responder should be prepared to handle at runtime, whereas assert seems to be for finding configuration issues in development.
Is it possible for us to complete request and response processing, then only append the request & response if successful? And additionally, ensuring that we have room for both request and response before appending either? This would minimize any possible scenario in which we might have to "rollback" a transcript append.
There are a few corner cases - like if a SHA hash fails, or append to transcript fails even when there's room. However, in scenarios like that, I think there are some limits that we could say that the SPDM context is unrecoverable, and return error that a reset is required. We can determine when to make the tradeoff of resiliency versus code complexity for those scenarios.

ensuring that we have room for both request and response before appending either

That may need another API to query the available size. It is possible.
Could you take it and make a proposal?

I think the cleanest possible way would be to make appending the request and the response the same function call. Then, in buffer case, we can know there is enough size before we append either. In SHA case, we can store the prior hash locally, before committing a new hash at the end of a successful operation. If failed, we restore the original hash.
Will draft up proposal for above - we can continue discussion there.


just-scripts pulls in a dependency that is being marked as "Malicious component found" by component governance

Affected component:
es5-ext
0.10.60
Security Review (CST-E)
This package prints a protest message (in support of Ukraine) upon installation, when the package is installed on a system located in or around Russia. Downgrade to 0.10.53 or an earlier version.

Unfortunately I don't think there's a good way to fix this in just-task directly until https://github.com/gulpjs/undertaker/pull/97 is merged (removing the es6-weak-map dep, since it's not needed in modern Node versions). In the meantime, the most reliable workaround is to add resolutions on the consumer's end.

undertaker finally released a new version, so this is fixed in just-scripts 2.3.0 and just-task 1.10.0.


Issue with Schema.Types.ObjectId

Hello Sparpik,
I tried tongoose, it works pretty well but on schemas with relationships, mongoose does not work...
export const UserSchema = new Schema({   address: {     ref: "Address",     type: Schema.Types.ObjectId   }, ...
Output:
undefined:4     type: "Schema".Types."ObjectId"

Two years later.
You should've used ObjectId from bson's module:
import { ObjectId } from "bson";
Anyway, this module seems to be deprecated 😢

Anyway, this module seems to be deprecated 😢

yeah i have no clue how anyone's using it, i made a hella hacky regex and called it a day, didn't even use it that much myself, and wasn't even good at typescript nor compilers in general:D
i don't think there's much demand so i don't feel any motivation to work on it 😅


Make able to be used as a cmake subproject

This commit replaces CMAKE_SOURCE_DIR/CMAKE_BINARY_DIR occurrences with PROJECT_SOURCE_DIR/PROJECT_BINARY_DIR.
It should not change anything for those who are working directly on FreeRDP, but it enables using FreeRDP as a CMake subproject (which seems relevant as FreeRDP is a library)

No, it's not. (But my changes could be integrated to #7082 as it is almost the same topic.
Anyway, it's different, it's only about PROJECT_{BINARY,SOURCE}DIR vs CMAKE{BINARY,SOURCE}_DIR.
Let say I have a project MyProject that include FreeRDP inside (so we have the path MyProject/FreeRDP), and MyProject/CMakeLists.txt does add_subdirectory(FreeRDP).
Then if you look at your CMakeLists.txt line 42: set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/)
CMAKE_MODULE_PATH will equal MyProject/cmake (which is wrong)
By replacing CMAKE_SOURCE_DIR by PROJECT_SOURCE_DIR, CMAKE_MODULE_PATH will be MyProject/FreeRDP/cmake which is what we want.

I precise that if we use FreeRDP as top-level project, CMAKE_SOURCE_DIR and PROJECT_SOURCE_DIR will always be the same.

@Pollux42 ah, ok. Will add that to the pr.


Tune chroma DC at low rates

Make the low rate chroma QM explicit so that it is clear that rounding effects are significant. Adjust the largest block-size DC one step. Given there isn't much room to move in Q4 at this scale and after trying a few perturbations of the coefficients, I think this is as good as it gets at this end of the quantizer range.
Luma BD rate (ntt-short-1):
         RATE (%)  DSNR (dB)
    PSNR 0.03191  -0.00100
 PSNRHVS 0.01400  -0.00068
    SSIM 0.00776  -0.00019
FASTSSIM 0.06020  -0.00169

Color BD rate (subset1):
            RATE (%) DSNR (dB)
CIEDE2000 -0.878958 -0.0363742

In combination with https://github.com/xiph/daala/commit/27e3704d919b8b987ecfe513f083cbaf6eaa2d4f ntt-short-1 luma-only regression, 3.596%, subset1 color improvement, 11.53%.

Luma BD rate (ntt-short-1):
         RATE (%)  DSNR (dB)
    PSNR 0.03191  -0.00100
 PSNRHVS 0.01400  -0.00068
    SSIM 0.00776  -0.00019
FASTSSIM 0.06020  -0.00169

This was an interesting angle but I realized that there was a much larger tuning error in the position of low-rate point of this 3-segment linear interpolation. I failed to fully account for rounding effects when translating my smooth quantization offset curve to this one. After fixing that, this tweak is no longer a net win.


Cyan color of ts.formatDiagnosticsWithColorAndContext is hard to read on white background

Search Terms

colors

Suggestion
Darken cyan color used by ts.formatDiagnosticsWithColorAndContext as it is currently hard to read on a white background.
Use Cases
I am having this problem when debugging Angular CLI errors. File names are hardly readable. I was redirected here after I filed an issue to their repository. I haven't verified this scientifically using contrast checkers, but I'm pretty sure it wouldn't pass:

Checklist
My suggestion meets these guidelines:

[ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[ ] This wouldn't change the runtime behavior of existing JavaScript code
[ ] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

Keep up the great work !

These are ANSI color references; we have no ability to tweak them (it's just "cyan", which terminals decide how they want to render in terms of an actual color). Your console program may have some option for changing how "cyan" is displayed. Pass --pretty false if you'd like no colorization at all.

Colorization is a very useful feature, turning it off would be worse than leaving it on as is. Couldn't you use another ansi color ?


Failed to be enabled for Godot 4.1.2

Hi,
Thanks for the great tool. but it won't be enabled for Godot 4.1.2, Godot will report:
Unable to load addon script from path: 'res://addons/deyu_atlas_texture_creator_window/UnityAtlasTextureCreatorBoot.cs'. This might be due to a code error in that script.
Disabling the addon at 'res://addons/deyu_atlas_texture_creator_window/plugin.cfg' to prevent further errors.

Godot Version: 4.1.2 stable, with c# support.
Thank you.

And the debugger says:
E 0:00:02:0316   can_instantiate: Cannot instance script because the associated class could not be found. Script: 'res://addons/deyu_atlas_texture_creator_window/UnityAtlasTextureCreator.cs'. Make sure the script exists and contains a class definition with a name that matches the filename of the script exactly (it's case-sensitive).
  <C++ Error>    Method/function failed. Returning: false
  <C++ Source>   modules/mono/csharp_script.cpp:2388 @ can_instantiate()

Let me see

It looks like in order for any .Net-based plugins to work you need to first build the .Net project once, I have added additional instructions to the readme documentation.

Configure the .Net runtime according to the Prerequisites section of the Godot Engine Docs.
...
If you have not yet create a C# solution, select Project/Tools/C#/Create C# solution, then click the Build button at top right corner.


[VirtualBox] Trying to start an already started machine message isn't helpful

$ ./docker-machine_darwin-amd64 start dev
ERRO[0000] exit status 1

Let's be sure to at least tell the user "what went wrong" (the machine is already started).

submitted #597 for the fix -- ideally we will have a better logging solution for the providers so we can get more detailed logs around these types of errors but at least this will prevent the error when trying to start a running machine.


Support multiple ADS configuration to allow distinct control-planes to serve parts of the configuration

Support multiple ADS configuration to allow distinct control-planes to serve parts of the configuration
Description:
We do use distinct control-planes to provide distinct parts of the xDS configuration used by envoy (currently mostly to split EDS and RtDS from the main LDS/RDS/CDS). As envoy currently only supports a single ADS configuration, we do configure each upstream cluster with a specific EDS configuration. As a consequence we end up with hundreds (sometimes more than a thousand) streams from a single envoy instance to our control-plane, duplicating parts such as extensions, metadata and more.
While we managed to scale our control-planes through optimizations or dirty workarounds (e.g. redefining the DiscoveryRequest protobuf to drop unused fields that ended up taking a lot of CPU to deserialize and remain unused), this is very inefficient and leads to increase resource usage and harder to maintain configuration. It also makes it unrealistic to use LEDS for instance.
The solution provided by https://github.com/envoyproxy/envoy/issues/2943 and its associated PRs looked promising, but it ends up confronted to a few issues:

EDS requires keeping a local cache (addressed through https://github.com/envoyproxy/envoy/issues/26749 to ADS muxes)
the new factory model would make this implementation more invasive
in my opinion, this hash-based choice can be confusing to users, with multiplexing of watches occurring based on a hash of a sub-part of the resources.
opting it all by default is risky, as some control-planes might not support it, and it changes the behavior of running instances.

A distinct proposal (associated draft PR coming) is to allow defining multiple ADS instances in the bootstrap configuration, and extending the ADS config_source to allow providing a specific ADS instance to use. The draft PR shows a surprisingly limited code surface impacted, while also unlocking more features like LEDS support, native reuse of the eds cache and potentially more (e.g. for ECDS). This is also in my opinion aligned with the grpc xDS configuration direction and could be reused directly through xdstp using the authority as the ADS instance to use.
As a further advantage, this is an opt-in change for users, and control-planes supporting ADS for EDS will natively support this.
Could you indicate if the draft PR could be considered? I may have missed major blockers or concerns with such an approach
[optional Relevant Links:]

Any extra documentation required to understand the issue.

cc @adisuissa

Thanks for raising this issue! It is an important feature and we'd like to see the support there.
There's been ongoing design and preliminary work in the domain of supporting multiple xDS servers. This is called xDS-Federation.
To give a bit of a background, please see the xDS-TP doc. It is likely that we'd need to redesign the xDS layer in Envoy (see #24773) to support this use-case.
Feel free to reach out directly, and we can discuss how we can proceed with this work.

I think this is a duplicate of #13951, which maps out in detail the changes we need to support this in Envoy.


[CardSectionImages]: CTA Copy does not render

Description
When using the <CardSectionImages /> component, and we provide a Card's cta copy as a string, nothing renders.
(In the <Card /> component, this property works as expected.)
Since the CardSectionImages uses an array of Card components, I would expect the copy to render.
Component(s) impacted
CardSectionImages
Carbon for IBM.com version
"@carbon/ibmdotcom-react": "latest"
Severity
Severity 3 = The problem is visible or noticeable to users but does not impede the usability or functionality. Affects minor functionality, has a workaround.
Application/website
https://ibm.com/quantum
Package
@carbon/ibmdotcom-react
CodeSandbox example
https://codesandbox.io/s/competent-hooks-ukjdrg?file=/src/index.js
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

This is no longer an issue for us - feel free to close this


feat(Data/ZMod/Defs): Topological structure on ZMod

Added a discrete topology structure to ZMod n for all n

Thanks @jcommelin ! I have added both changes to the code. I am happy to delete this controversial lemma with two topologies on it as of now, and come back to it when needed. For now, having the topology on ZMod is crucial to my project.

@laughinggas can you please add docstrings for the two new defs, and move the lemma about embeddings between discrete spaces to a lower level file?

ZMod.instTopologicalSpace now exists. Do you want to salvage the rest of the PR?


Actor sheet issue with upscaled resolutions.

Bug confirmed on my 4k laptop.
I can help with the debug if you can't reproduce the issue on your screen, Edmund.


feat: add support for examples

Some libraries like cobra allow you to set examples for commands.
This PR extends the mango.Command with an example which will be added to the man page automatically.
The placement of the examples is roughly according to https://linux.die.net/man/7/man-pages
An example implementation for a mango adapter can be found here: https://github.com/muesli/mango-cobra/compare/main...jon4hz:mango-cobra:main

My pleasure! Will add a PR for mango-cobra and mango-coral when the next release is out :)


command classes

[x] RookCommand: Base command class

[ ] AdminCommand: Administrator privs

[x] ModCommand: Mod privs

[x] BotDevCommand: BotDev role

fixed by 0bd354092593dd61012eb4c02629619c581e2488


build(releaserc.json and package.json): deprecated gulp release notification plugin in favour of semantic release notify plugin

:tada: This PR is included in version 4.0.22 :tada:
The release is available on:

v4.0.22
GitHub release

Your semantic-release bot :package::rocket:


Is there a when expression detecting whether the cursor is at the beginning of a cell?

Thanks for the nice extension!
I want to custom the notebook.cell.quitEdit with keybinding left arrow when the cursor is at the beginning of a cell. Is there a when expression for this purpose or is it possible to add this functionality?

This is a good idea !
Also for keybinind up arrow, so you don't go through the lines, but rather through cells. Wish they provide a context

I would like this too. I don't see any existing expression that would work. I suspect it would have to be a feature request on the main repo however: https://github.com/microsoft/vscode.


Automated Package Upgrade

:tada: This PR is included in version 13.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Consecutive jatos.batchSession.add fail

Hi  I am trying to setup my experiment in JATOS.
In my index.html
I am trying to add consecutively 2 variables in the batch session data.
The first succeeds , the second fails.
Here is the code in question:
==================================
 var blockInfo = { "lastBlock": 1 };

//---------
var promise1 = jatos.batchSession.add("/XXX1", blockInfo);
if (jatos.batchSession.test("/XXX1/lastBlock", 1) == true) { console.log("Test1: SUCCESS"); } else { console.log("Test1: FAILED"); }
//---------
blockInfo = { "lastBlock": 2 };
var promise2 = jatos.batchSession.add("/XXX2", blockInfo);
if (jatos.batchSession.test("/XXX2/lastBlock", 2) == true) { console.log("Test2: SUCCESS"); } else { console.log("Test2: FAILED"); }
//--------
==================================
After I ran this the batch session data is:
{
"XXX1": {
"lastBlock": 1
}
}
So the second entry was not added .
In Firefox's Web console I get:

A quick look in the "sendBatchSessionPatch" part of jatos.js hints that the Batch channel used by jatos.batchSession remains busy after the first entry is uploaded.
The funny thing is that if I place an "alert" popup as:
alert("I just sent the first entry");
just before
var promise2 = jatos.batchSession.add("/XXX2", blockInfo);
in the code above then also the second entry is succesfully added in the batch session data which then is:
{
"XXX1": {
"lastBlock": 1
},
"XXX2": {
"lastBlock": 2
}
}
Could someone please enlighten me how i could add subsequent entries in batch session data without having to use dummy alert messages?
Thank you very much in advance.
Best
Giorgos

Hi Giorgos, please don't write in several forums (or GitHub issues) the same question. It cost us some time to answer them or at least reference the already given answer.
Please see https://forum.cogsci.nl/discussion/6316/consecutive-jatos-batchsession-add-fail


Concatenate multiple environment files

Is there a way to concatenate multiple environment files?
I have two libraries that I want to compile in the CI, both with their own dependencies, both listed in their respective environment files. I do have https://github.com/tdegeus/conda_envfile for that, but that already requires python and
https://github.com/tdegeus/conda_envfile/blob/372dc49138c8f2c7c6783c05a791f7d22de32662/pyproject.toml#L7C16-L7C17

Multiple environment files are currently not supported by setup-micromamba and I don't think that we will add support for this since this is kind of niche.
You could install a separate environment in an extra step or use a matrix to spawn multiple runners.
See #51

The micromamba docs now explicitly refer to the option of adding multiple environment files to the micromamba create command, see https://mamba.readthedocs.io/en/latest/user_guide/micromamba.html#conda-yaml-spec-files :

You can pass multiple YAML spec files by repeating the -f,--file argument.

It would be great if this option could be added to the GitHub action, because otherwise one needs additional build steps for the following spec files, and only the initial environment can be cached.

@peanutfun does something like this work?
- uses: mamba-org/setup-micromamba@v1
  with:
    name: my-env
    environment-file: environment.yml
    create-args: -f environment2.yml

@pavelzw Thank you! Your suggestions appears to result in a valid micromamba create command, but even when I explicitly request the latest version of micromamba, I get the error
  critical libmamba Can only handle 1 yaml file!
  info     libmamba ****************** Backtrace End ********************
  Error: The process '/home/runner/micromamba-bin/micromamba' failed with exit code 1

I can replicate this error locally. It seems like the docs of micromamba are incorrect.

yeah this was just merged into micromamba not long ago, maybe the new version is just not released yet (or they wait for micromamba 2.0 to release this feature)

Thanks for the background info and the support! Then I'll be patient. I just raised an issue on the topic: https://github.com/mamba-org/mamba/issues/3196


Unable to add MHD footprints to shared object store - potentially issue with memory usage

What is your issue?
I'm unable to add any MHD footprints to the shared object store (/group/chemistry/acrg/ES_store/openghg_store), potentially because of an issue with memory usage.
When I try to run the standardise_footprint() function in a Jupyter notebook, the function just hangs indefinitely.
When I run the same function in a script on the BP1 compute nodes, the run fails out even when I set the memory to 60GB.
I haven't had any issues when adding any other footprints from other sites to this object store (and these scripts have run correctly on the compute nodes when setting the memory allocation to 10GB) so it must be something to do with these MHD files.
Here's an example footprint month that doesn't work for me, but I'm unable to add any MHD files from any dates:
standardise_footprint(filepath='/group/chemistry/acrg/LPDM/fp_NAME/EUROPE/MHD-10magl_UKV_EUROPE_202102.nc', site='MHD',height='10magl',domain='EUROPE',model='NAME',metmodel='UKV',overwrite=False)

This looks like something that could maybe be fixed using a caching
strategy similar to the method we used in the name_processing repo.

I'm unable to add any MHD footprints to the shared object store (
/group/chemistry/acrg/ES_store/openghg_store), potentially because of an
issue with memory usage.
When I try to run the standardise_footprint() function in a Jupyter
notebook, the function just hangs indefinitely.
When I run the same function in a script on the BP1 compute nodes, the run
fails out even when I set the memory to 60GB.
I haven't had any issues when adding any other footprints from other sites
to this object store (and these scripts have run correctly on the compute
nodes when setting the memory allocation to 10GB) so it must be something
to do with these MHD files.
Here's an example footprint month that doesn't work for me, but I'm unable
to add any MHD files from any dates:
standardise_footprint(filepath='/group/chemistry/acrg/LPDM/fp_NAME/EUROPE/MHD-10magl_UKV_EUROPE_202102.nc',
site='MHD',height='10magl',domain='EUROPE',model='NAME',metmodel='UKV',overwrite=False)
—
Reply to this email directly, view it on GitHub
https://github.com/openghg/openghg/issues/676, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACEAR3VTPUM7IPIE33TVTGTXKCKMNANCNFSM6AAAAAAY6ARYMM
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I've followed this issue through to where the actual problem is occuring:
standardise/_standardise.py line 275: Footprints.read_file()
store/_footprints.py line 384: assign_data()
store/_segment.py line 46: Datasource.load()
The Datasource.load() line just hangs until it runs out of memory.
Line 41 in _segment.py says:
If we have a UUID for this Datasource load the existing object
from the object store
I'm not sure how the objectstore works behind the scenes, but does this mean that it reads in an object that already contains similar data (in this case MHD footprints) and then the new file is added to this?
If this is the case, could the issue be that the data that's aready associated with MHD footprints is either corrupt or too large to read in? So it's getting stuck at that point, before it tries to add the new data?

Yes you're right that it'll look for an existing data source with the keywords supplied and load in any existing data it finds.
So we likely need to tread carefully and understand what data is present and why but in principle data which already exists in the object store can be deleted - Modifying_and_deleting_data

Depending on the data being added as well, it may also be that we're not using enough of the supplied keywords to categorise the footprint data. So we may need to put in a fix to distinguish using more keywords e.g. met_model etc.
Really we need to determine whether the data you're adding should be being grouped together with the data already stored.

I've tried to add the same set of MHD footprint files (e.g. '/group/chemistry/acrg/LPDM/fp_NAME/EUROPE/MHD-10magl_UKV_EUROPE_202102.nc') to a new empty object store and this has worked without any issues. openghg.standardise.standardise_footprint() adds the file to the new object store without any problem, and I can then retrieve the data as expected.
So I think this confirms that the issue above is due to the current shared object store, or how these files in particular (MHD 2021 footprints) are interacting with the shared object store.

I've tried to add the same set of MHD footprint files (e.g. '/group/chemistry/acrg/LPDM/fp_NAME/EUROPE/MHD-10magl_UKV_EUROPE_202102.nc') to a new empty object store and this has worked without any issues. openghg.standardise.standardise_footprint() adds the file to the new object store without any problem, and I can then retrieve the data as expected.
So I think this confirms that the issue above is due to the current shared object store, or how these files in particular (MHD 2021 footprints) are interacting with the shared object store.

Ok thanks for doing that Alice - one thing to note is that I am currently working on setting up a new object store which changes some of the ways the data is stored internally. Work on this is completed as part of a separate milestone - https://github.com/openghg/openghg/milestone/13 with the current updates on PR #680 . As a part of this it would really helpful if you could add the details of scripts/notebooks/files you're adding to the object store to https://github.com/ACRG-Bristol/populate that would make this smoother.
Having said all that, if there needs to be an update for the current object store then that's fine. Are you able to work around this at the moment or is this still a blocker?

I've tried to add the same set of MHD footprint files (e.g. '/group/chemistry/acrg/LPDM/fp_NAME/EUROPE/MHD-10magl_UKV_EUROPE_202102.nc') to a new empty object store and this has worked without any issues. openghg.standardise.standardise_footprint() adds the file to the new object store without any problem, and I can then retrieve the data as expected.
So I think this confirms that the issue above is due to the current shared object store, or how these files in particular (MHD 2021 footprints) are interacting with the shared object store.

Ok thanks for doing that Alice - one thing to note is that I am currently working on setting up a new object store which changes some of the ways the data is stored internally. Work on this is completed as part of a separate milestone - https://github.com/openghg/openghg/milestone/13 with the current updates on PR #680 . As a part of this it would really helpful if you could add the details of scripts/notebooks/files you're adding to the object store to https://github.com/ACRG-Bristol/populate as that would make this transition smoother.
Having said all that, if there needs to be an update for the current object store then that's fine. Are you able to work around this at the moment or is this still a blocker?

Ok, it sounds like that new object store setup could solve this issue then. For now, I can continue using my new separate object store for the PARIS work that needs completing soon. So this issue isn't a blocker for this anymore.
I don't think I've been adding anything notable to the shared object store (only footprints for 2021) and I've been using the populate functions already contained in that repository, but I can check through and see if there's anything missing.

The fix by @brendan-m-murphy in #513 may help with this.
A full fix will come with the special release #591.

This should be addressed as part of #561 (and #867 , #908 ) and this will be closed when the overall new_object_store branch is merged into devel #831 .


When deploying the agent to the final step, the Gradio page has already appeared, but an error is reported when starting a conversation.

Self Checks

[X] This template is only for bug reports. For questions, please visit Discussions.
[X] I have thoroughly reviewed the project documentation (installation, training, inference) but couldn't find information to solve my problem. English 中文 日本語 Portuguese (Brazil)
[X] I have searched for existing issues, including closed ones. Search issues
[X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
[X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
[X] Please do not modify this template and fill in all required fields.

Cloud or Self Hosted
Self Hosted (Source)
Environment Details
windows,   python 3.10 ,  gpu3060 12g,  model quantited int8(model.pth),   (firefly-gan-vq-fsq-8x1024-21hz-generator.pth)no change.
Steps to Reproduce
Terminal 2
response = await iterator.anext()
File "E:\PythonProject1\fish-speech\tools\e2e_webui.py", line 125, in process_text_input
async for event in process_audio_input(
File "E:\PythonProject1\fish-speech\tools\e2e_webui.py", line 100, in process_audio_input
async for event in agent.stream(
File "E:\PythonProject1\fish-speech\tools\fish_e2e.py", line 131, in stream
sys_codes = await self.get_codes(system_audio_data, sample_rate)
File "E:\PythonProject1\fish-speech\tools\fish_e2e.py", line 118, in get_codes
codes = encode_response_data["tokens"][0]
TypeError: 'int' object is not subscriptable
Terminal 1
from .intervals import INTERVALS
File "C:\Users\Administrator.conda\envs\fish-speech\lib\site-packages\librosa\core\intervals.py", line 18, in
INTERVALS = msgpack.load(fdesc, strict_map_key=False)
File "C:\Users\Administrator.conda\envs\fish-speech\lib\site-packages\msgpack_init.py", line 58, in unpack
return unpackb(data, **kwargs)
File "C:\Users\Administrator.conda\envs\fish-speech\lib\site-packages\msgpack\fallback.py", line 118, in unpackb
unpacker = Unpacker(None, **kwargs)
TypeError: Unpacker.init() got an unexpected keyword argument 'strict_map_key'
INFO:     <IP_ADDRESS>:52395 - "POST /v1/vqgan/encode HTTP/1.1" 500 Internal Server Error
✔ Expected Behavior
No response
❌ Actual Behavior
No response

please roll back to v1.4.3 to use the agent.


mbedtls_ssl_set_hostname returned -0x7F00 (IDFGH-9533)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
ESP32-S3
IDF v4.4.4
Running OTA there are times where we get this:
E (14:50:52.751) esp-tls-mbedtls: mbedtls_ssl_set_hostname returned -0x7F00
E (14:50:52.752) esp-tls-mbedtls: Failed to set client configurations, returned [0x8012] (ESP_ERR_MBEDTLS_SSL_SET_HOSTNAME_FAILED)
E (14:50:52.761) esp-tls: create_ssl_handle failed
E (14:50:52.766) esp-tls: Failed to open new connection
E (14:50:52.772) TRANSPORT_BASE: Failed to open a new connection
E (14:50:52.779) HTTP_CLIENT: Connection failed, sock < 0

It doesn't happen always, but once it happens the error seems to last for many retries.
We thought we had resolved the issue by setting CONFIG_MBEDTLS_EXTERNAL_MEM_ALLOC=y following https://github.com/espressif/esp-idf/issues/9078 but I don't know if I have to enable anything else but we don't seem to stop the issue for good.
It should be noted that we are using LTE via the esp_modem component. But we have also experienced this issue with WIFI and, moreover, the issue seems to be coming from TLS (lack of memory).
The OTA task is ran in a freertos task with a stack size of 16384, so I don't think this is the issue.
We also do other ordinary http calls which also fail. So I don't think it is the server (the OTA server and the http calls servers are different). And when the OTA works the other http calls work too.

I cannot reproduce the issue now.
I'm going to assume that the sdkconfig.defaults did me dirty and the CONFIG_MBEDTLS_EXTERNAL_MEM_ALLOC wasn't getting applied


PollUntilCompleted throws "Method not found: '!!0 Google.Api.Gax.Polling.PollRepeatedly"

Hi guys,
We do simple select queries to a few tables in BigQuery:
connection.ExecuteQuery(command).PollUntilCompleted().GetRows();
and for some small tables we have an exception:
Method not found: '!!0 Google.Api.Gax.Polling.PollRepeatedly(System.Func2,!!0>, System.Predicate1, Google.Api.Gax.IClock, Google.Api.Gax.IScheduler, Google.Api.Gax.PollSettings)'. at Google.Bigquery.V2.BigqueryClientImpl.PollQueryUntilCompleted(JobReference jobReference, GetQueryResultsOptions options, PollSettings pollSettings) at Google.Bigquery.V2.BigqueryQueryJob.PollUntilCompleted(PollSettings pollSettings)
Could you explain what does it mean and how can we fix it?
Thanks

That suggests you've got version mismatch between the libraries somehow. Could you let me know which version of Google.Cloud.BigQuery.V2 you're using, and which version of Google.Api.Gax?

Hi @jskeet
Google.Cloud.BigQuery.V2: <IP_ADDRESS>5
Google.Api.Gax: 1.0.0-beta12

Ah - that's a very old version of the BigQuery library. We changed the name back in December for consistency... we stopped "advertising" the Google.Bigquery.V2 library, but if you already had a Nuget reference to it, it would still be fetchable.
Please update to Google.Cloud.BigQuery.V2 instead - I'm afraid you'll need to change all your code that refers to "Bigquery" to refer to "BigQuery", and change your imports, but I think everything else should move very easily.

Hi @jskeet ,
Thanks, it works

Wonderful, thanks - closing this issue.


🐛 BUG: r2 object put Duplex option required

Which Cloudflare product(s) does this pertain to?
R2
What version of Wrangler are you using?
2.11.0
What operating system are you using?
MAC
Describe the Bug
I'm trying to run the command below to upload a file to r2:
wrangler r2 object put cccc/main.js -f main.js
and this error is happening:

I've done a lot of research and haven't found a solution for this.
what should I do?

I wonder if this is being caused by a recent Undici upgrade we did. Could you try to reproduce this with an older version of Wrangler, just a few versions back?

I tested version 2.10.0.. and it worked. so the problem is in version 2.11.0


Use atomic way of acquiring database lock

Issue:
Fixes #47
Changes:
When there is a race condition, where multiple processes try to create a lock file then only one process should obtain and others should be pulled backed to the waiting area.

@TomasTomecek Please review!


Update the translation

Update some wrong expressions and words.

[X] I have read freeCodeCamp's contribution guidelines.
[X] My pull request has a descriptive title (not a vague title like Update index.md)
[X] My pull request targets the master branch of freeCodeCamp.
[X] None of my changes are plagiarized from another source without proper attribution.
[X] My article does not contain shortened URLs or affiliate links.

@maikelsperandio Thank you for  creating this PR.  However, since it was created, the underlying document has changed.  Can you please review and resolve the current merge conflicts?  It could be the changes to the underlying document are so significant that your changes are no longer relevant.  If the latter is the case, it might be easier to just close this PR and create a new PR with any changes you still feel are important to make.
If you need any assistance or have questions about resolving the merge conflicts, please reply back or contact someone in the Contributors Room on Gitter.
Thank you.

We are restructuring a lot of the code and learning resources referenced in your pull request, so for now I am going to go ahead and close this pull request. Thanks again for opening this pull request and for contributing to the community.


routing error with summernote.js

I'm using the cdn to grab summernote.js and i keep getting this error whenever i open my console https://prnt.sc/t3hdrg

It was the last line in the js file.


Use the new Framework API?

Hey @bissolli!
I'm one of the Storybook maintainers. I focus primarily on documentation and community outreach. I'm opening up this issue and letting you know that the Storybook API for building addons is currently being updated to factor in the changes introduced by the upcoming 7.0 release. If you're interested in making the required changes to help the community from benefiting from using your addon, we've prepared an abridged guide for the required changes here, and if you have any questions or issues, please reach out to us in the #prerelease channel in our Discord Server.
Hope you have a great day!
Stay safe

@bissolli sorry for the late response, but it's been some hectic times getting everything ready for the upcoming release. Appreciate the follow-up on this and looking forward to it.
Hope you have a great week.
Stay safe

Will this be compatible with v7? 🙏

Hey guys, I will find some time to work on it this week - it should definitely be compatible.

Hey @jonniebigodes, does this new Framework API allow any sort of integration between addons?
Let's say i want the default values in the css props tab of this addon to react to theme changes, somehow display different values depending on the selected theme.
Is this anyway possible?
Another case is, css controls affect rendering if the selected theme is the default, but the values do not affect rendering when another theme is selected.


Update storage-use-azcopy-v10.md

delete duplication of azcopy jobs in list of commands

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

I agree with this PR. Technically, you can use "azcopy jobs" to see a list of jobs-related commands, but I don't think we need this ref file. Thx for the suggestion!
#sign-off

Hi Norm,
When I raised the PR, it was more so because of the duplication:

But what you are saying definitely makes sense ask well. Thank you! :)


Fix broken candlestick

Fixed Candlestick data disappearing issue #27

When I click on «Line» or «Candlestick» I get the error:

@yivo, Thanks for the review. I have fixed this. Please review again.


Idea: QueryBuilder

I have started to tinker around with a basic query builder example.
The objective I am thinking about is a tooling which gets a DB model as its generic input (ie. the output of https://github.com/surrealdb/surrealdb/issues/248) and then lets you generate SELECT SurrealQL queries with a typed result.

Regarding this. I have always liked how https://knexjs.org/ builds it's queries. If a query builder feature were to be implemented, I suggest:

It be inspired by knex
That it requires explicit imports to use because some people might want to just manually build their queries.

Take a look at this type-safe typescript SQL query builder also: https://github.com/koskimas/kysely


Properly yield navbar links and allow overriding route

Purpose

Summary of Changes

Side Effects

Feature Flags

QA Notes

Ticket

https://openscience.atlassian.net/browse/EMB-
Reviewer Checklist

[ ] meets requirements
[ ] easy to understand
[ ] DRY
[ ] testable and includes test(s)
[ ] changes described in CHANGELOG.md

Pull Request Test Coverage Report for Build 1502

7 of 8 (87.5%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 62.016%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/osf-components/addon/components/hyper-link/component.ts
7
8
87.5%

Totals

Change from base Build 1501:
0.04%

Covered Lines:
2501

Relevant Lines:
3807

💛  - Coveralls


1.0.0

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

ℹ The recipe is not parsable by parser conda-recipe-manager. Your recipe may not receive automatic updates and/or may not be compatible with conda-forge's infrastructure. Please check the logs for more information and ensure your recipe can be parsed.

can we do qt6 as a variant but still use qt5 for the default build? I'm hesitant about publishing with qt6 if we can avoid it. It has had very little testing and I believe there are still unresolved bug when using qt6. The development team had decided because of this to stick with qt5 for 1.0.0 and target 1.1.0 for the qt6 transition and I would prefer to not go against that.
To get it to to solve the environment I had to make new vtk and pcl builds with qt5 though

Hi adrian, I would like to offer both qt5/qt6 via two seperated branches. So  keeping qt6 as the main branch and creating a new qt5 branch which basically mirrors the freecad/freecad-feedstock main branch. Keeping them both in the same branch adds too much overhead in my eyes. It's easier to keep the qt6-branch updated with the latest migrations (py3.13...) I don't think py3.12 support for pyside2 is coming soon, so at one point the qt5-branch will be outdated. But as it has been proven, we still can build the qt5 branch with older dependencies for some time. Is this approch ok for you?

That would be ok, how would one choose which to use at installation?

Congratulations on this huge milestone! 🥳

thanks @h-vetinari, this wouldn't be possible without your help and the help of all the people from conda-forge. And for sure all the great work developer do for FreeCAD and all the maintainers. Especially thanks to @oursland and @adrianinsaval who do a fantastic job.


refactor Generalise temporary directory structure

temp folder could probably be reused for a lot more things, like extracting Northstar before moving files into the correct place.

@GeckoEidechse can you remind me why we're using a folder inside Northstar's directory, and not creating a temporary folder (e.g. in /tmp on UNIX) using something like std::filesystem::temp_directory_path in cpp?

@GeckoEidechse can you remind me why we're using a folder inside Northstar's directory, and not creating a temporary folder (e.g. in /tmp on UNIX) using something like std::filesystem::temp_directory_path in cpp?

Cause when I wrote that code, I didn't know that https://doc.rust-lang.org/std/env/fn.temp_dir.html existed and thought I had to find temp dir myself ^^"

Ignore my misclick

Cause when I wrote that code, I didn't know that https://doc.rust-lang.org/std/env/fn.temp_dir.html existed and thought I had to find temp dir myself ^^"

Let's keep this for another issue then :)

Having the temp Dir be in the game folder is actually good.
Exctracting Northstar and possible preprocessing it could take some time and moving files on the same fs is cheap, so is the best way to do things.

Having the temp Dir be in the game folder is actually good.
Exctracting Northstar and possible preprocessing it could take some time and moving files on the same fs is cheap, fast and atomic, so is the best way to do things.

I'll argue using a "real" temporary directory hides what's happening under the hood to users, which prevents them from deleting the ___flightcore-temp dir they don't know is useful for, for instance.
But again, it's not the point of this PR :)

I'll turn it into an issue to discuss possible changing as well as up- and downsides of all variants.


Grid table

Hi, any clue how to config the grid(table) to have input or link as type of field like on screen shot

check our demo example:

https://formly.dev/examples/advanced/datatable-integration
https://formly.dev/examples/advanced/grid-integration


How to disable loading when load data?

Hi
I want to set a custom loading for load data.

Use EndlessRecyclerViewAdapter#setPendingViewHolder if you want to customize the loading view.

I didn't get, can you explain more about it.
Thanks.

@asaeid use the method setPendingViewHolder of class EndlessRecyclerViewAdapter to set a custom ViewHolder. Inside that ViewHolder you can do whatever you want, i.e use a custom view for loading view.


semver crate doesn't compile with default features disabled in 1.0.1

A simple cargo check --no-default-features from the 1.0.1 tag fails with:
   Compiling semver v1.0.1 (/home/nt/tmp2/semver)
error[E0433]: failed to resolve: use of undeclared type `Vec`
   --> src/impls.rs:152:27
    |
152 |         let comparators = Vec::from_iter(iter);
    |                           ^^^ not found in this scope
    |
help: consider importing one of these items
    |
1   | use alloc::vec::Vec;
    |
1   | use crate::Vec;
    |

error: aborting due to previous error

For more information about this error, try `rustc --explain E0433`.
error: could not compile `semver`

To learn more, run the command again with --verbose.

Other simple repro: cargo init; cargo add semver --no-default-features; cargo check
Doesn't happen on the 1.0.0 tag. This probably doesn't get used much for this crate, but we hit this on a repository where we were trying to reduce feature use all over to speed up compiles.

Thanks — I've released 1.0.2. with a fix.


Fetching status for Repository model

adds the new "Fetching" status to the Repository model

Just updated the PR to add the type FetchStatus to all statuses. Setting the type only on the first const works only with iota declarations.


Update go version to 1.19

Update go version to 1.19

already covered by https://github.com/hyperledger/firefly-signer/pull/32


edge_index has edges across different data objects in a batch

Hello, I really like the proteinworkshop codebase. It's really handy to load and featurize structures.
I tried to featurize my protein batches but found the batch.edge_index contains edges across multiple different Protein data objects in my batch. In my use case, the edges should be within each Data object. I've included a simplified example of my current usage. Could you give me some guidance on how to avoid this?
https://github.com/a-r-j/ProteinWorkshop/blob/61294d4bafab7779121cf4eaa4435742b61b709a/proteinworkshop/features/factory.py#L112
import torch
from graphein.protein.tensor.data import Protein, ProteinBatch
from proteinworkshop.features.factory import ProteinFeaturiser

# one structure data object
data = Protein().from_pdb_code(pdb_code="1a14")
data
"""
Protein(
    fill_value=1e-05,
    atom_list=[37],
    residue_type=[600],
    id='1a14',
    residues=[600],
    residue_id=[600],
    chains=[600],
    coords=[600, 37, 3]
)
"""

batch = ProteinBatch().from_pdb_codes(pdb_codes=["1a14", "1a14"])
batch.edge_index
"""
batch =>
DataProteinBatch(
    fill_value=[2],
    atom_list=[2],
    residue_type=[1200],
    id=[2],
    residues=[2],
    residue_id=[2],
    chains=[1200],
    coords=[1200, 37, 3]
)
"""

# featurizer
featurizer_config = dict(
    representation="CA",
    scalar_node_features=[
        "amino_acid_one_hot",
    ],
    vector_node_features=[
        "orientation",
    ],
    edge_types=[
        "knn_16",
    ],
    scalar_edge_features=[
        "edge_distance",
    ],
    vector_edge_features=[
        "edge_vectors",
    ],
)
featurizer = ProteinFeaturiser(**featurizer_config)
featurizer(batch)
"""
batch after featurization =>
DataProteinBatch(
    fill_value=[2],
    atom_list=[2],
    residue_type=[1200],
    id=[2],
    residues=[2],
    residue_id=[2],
    chains=[1200],
    coords=[1200, 37, 3],
    x=[1200, 23],
    pos=[1200, 3],
    x_vector_attr=[1200, 2, 3],
    edge_index=[2, 19200],
    edge_type=[1, 19200],
    num_relation=1,
    edge_attr=[19200, 1],
    edge_vector_attr=[19200, 1, 3]
)
"""
batch.edge_index
# examine if there are edges from data 1 to data 2
idx = torch.where(batch.edge_index[0, :] < 600)[0]
edge_index = batch.edge_index[:, idx]
idx = torch.where(edge_index[1, :] > 600)[0]
edge_index = edge_index[:, idx]
edge_index
"""
tensor([[   1,    2,    0,  ...,  595,  594,  568],
        [ 601,  601,  601,  ..., 1199, 1199, 1199]])
"""

Each data object, in this case, 1a14, has only 600 residues. However, in the batch.edge_index, there are edges between residues from different data objects. For example, the edge [595, 1199] denotes an edge between the 596th residue from the first Protein and the 1199th residue, i.e., the 600th residue in the second Protein.
I guess this may not be the correct way of using the featurizer, but would appreciate it a lot if you could give an example of its usage in this case.

Hi @biochunan I think you need to check if batch.batch is set correctly prior to computing the edges.

Hi @a-r-j, thanks for your reply! That's indeed the cause of the problem. After manually adding an attribute that the collate function can can_infer_num_nodes, and it solved the issue.


spiderpoolctl or some debug tools

1 show an IP, taken by which subnet , ippool, pod ,  which helps to add ip to ippol etc..
2 trigger gc
3  multiple cli command to get log information for the IPAM of a pod ,  to get subnet'ippool information for  a deployment ,
4 ......

Is spiderpoolctl a long-term plan, or will it not be done?

For a long time, we will not consider providing debugging tools, such as spiderpoolctl
This is an outdated issue and is temporarily closed. We will open it again if necessary.

/cc @Icarus9913


finalizing-install

https://github.com/Start9Labs/embassy-os/issues/861

why was this closed instead of merged? I'm getting reports that the problem this was supposed to fix still isn't fixed.


How to download a file using cloud-init.yaml file?

Hello,
I am trying to deploy my war application using cloud-init.yaml file. I created a cloud-init.yaml file and it could install tomcat but my war application is present in the Azure storage account and the cloud-init file is not able to download the file.
I tried to download the file manually from the VM but am getting the error.
wget https://xxxxxxxx.blob.core.windows.net/cluster-files/myapp.war --2021-02-16 06:26:48--  https://xxxxxx.blob.core.windows.net/cluster-files/myapp.war Resolving xxxxxx.blob.core.windows.net (xxxxxx.blob.core.windows.net)... <IP_ADDRESS> Connecting to xxxxxxx.blob.core.windows.net (xxxxxx.blob.core.windows.net)|<IP_ADDRESS>|:443... connected. HTTP request sent, awaiting response... 403 This request is not authorized to perform this operation. 2021-02-16 06:26:48 ERROR 403: This request is not authorized to perform this operation..
From the VM terminal, I have logged in to the Azure cli with the "az login command" and the file download started working. But can someone help me how can I download this file using cloud-init.yaml file and without login to azure?
Thanks
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0d3da20d-57c3-1dcf-ada6-e9ded556e028
Version Independent ID: bc6f80e2-38c9-aafe-cbe9-2eaf94117474
Content: Tutorial - Customize a Linux VM with cloud-init in Azure - Azure Virtual Machines
Content Source: articles/virtual-machines/linux/tutorial-automate-vm-deployment.md
Service: virtual-machines-linux
GitHub Login: @cynthn
Microsoft Alias: cynthn

Thanks for brining this to our attention. We will investigate it further and update you shortly.

@Rinshad - We are so sorry that you are having issues.
In order to find the root cause of it, we would need you to send us an email at<EMAIL_ADDRESS>by providing below details.
Subject : ATTN:Monika

Subscription ID
A link to this thread.
Please email us these details and we will work with you closely to get this issue taken care of and also post any findings here in the thread so the community can benefit from it.
Thanks in advance. Looking forward for your email.

@Rinshad - I have received your email and will work with offline going further. At this moment, since there is no doc update required,  We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.
After, you receive a resolution for the issue offline, I will post the updates here so it can be beneficial to the community.


Adding code-of-conduct File to the repo !

code-of-conduct:- We propose adding a comprehensive Code of Conduct to our repository to ensure
a safe, respectful, and inclusive environment for all contributors and users. This code will
serve as a guideline for behavior, promoting diversity, reducing conflicts, and attracting a
wider range of perspectives.
Issue type

[✅] Docs

@ kindly assign this issue to me ! I would love to work on it ! Thank you !

@stellaHSR  kindly assign this issue to me ! I would love to work on it ! Thank you !

Hi, thank you! We would like to have the code of conduct document included in our repository.

@stellaHSR I have made the changes kindly review it !


Push actual source code to npm

As said here, source code isn't being pushed to npm at all.

Hahaha what??? Damn it. That was my mistake, I forgot to run build before publish. Just switched to a new machine

Fixed in 0.1.5. Added yarn build to prepublishOnly script so this won't happen again in the future. Hopefully.