@est31 I now have some more time to write more specifically to your points on editions

How much first-hand experience do you have with the "cargo script" feature in nightlies, as of July 11th or so? I encourage anyone wanting to discuss edition default + warning to make good use of the feature (and not trial it). From my experience using the feature (all of my scripts are running cargo from `HEAD`) and from talking to Josh who was heavily involved in editions is that the warning is strong enough to help drive our intended behavior with editions. As Josh put it for the long-term script users: "[the warning] effectively makes an explicit edition mandatory (for anything except toys and bug-reproductions)".

For me, a priority is being able to have a file without any manifest. Technically you could then change to the `#!` to `rustc` but I don't want users to have to think about that.

We also need to keep in mind MVP vs where we eventually end up. I think re-inventing a new syntax or schema in the first version is the wrong direction to go. For manifests, we should have an actual manifest, even if its a more heavily-defaulted version. To that end, I'm also concerned about requiring fields that aren't required today because that can be surprising. As we see how this feature evolves, we can have more targeted discussions on how to improve specific parts of the syntax. Right now, we are trying to design a lot; we need to cut somewhere to ever get this stable.

I think those scripts do need the edition. Maybe not always but in enough cases that we would be making life for our users harder. Most people will likely be using and thinking in terms of the current edition and behavior outside of that will be surprising, possibly making a bug reproduction more of a hassle (or surprising) or by making someones syntax/std experiments meaningless to the production code they'll use.

I feel this is just as bad as defaulting to 2015 edition but just delays the consequences for a few years.


@skreborn

Explicitness is not a goal but a tool to help reach goals. Cargo and rust can be implicit at times, including all of the defaulting in `Cargo.toml` or type inference in Rust. This is an important distinction so we make sure we don't over-index on things being explicit but we keep in mind why we want to be explicit and why explicitness could damage our efforts.

As has been noted several times in this thread, the manifest format is our biggest open issue. We have a plan for determining our path forward which I will soon document but I would recommend us not discussing this too much until we have more information.

Jumping a tiny bit ahead, I do find the proposal of using a doc comment on `main` interesting. The downside is if we want to support libraries.

Keep in mind, if they are using a default, we'll be warning them on every script run that its in place. Like I mentioned in my previous post, I would recommend using the feature out as-is if you haven't already. First-hand experience is a big help for these conversations.


In the same conversation, joshtriplett and I talked about cargo-new

My main concern with supporting it out of the box is that I want downward pressure on the syntax by not allowing people to bypass it. However, I can be guilty of just copy/pasting my existing scripts just for some annoyances independent of Rust (`chmod` + writing the `#!`) plus I reuse the same deps over-and-over again.

When creating a "script", we expect it to
- Add a standard `#!` line
- `chmod +x` the file
- Include a manifest with an edition and empty `dependencies` table
- Include a `main`
- If nightly cargo is being used, warn that any `+` needs to be added to the script `#!` as well if it will be invoked directly
 - Maybe restrict this warning to not-windows since `#!` is meaningless on Windows

The question is how to invoke it
- A flag could work, but what do we name it? I've been avoiding committing to calling these "scripts" in the CLI and user-facing documentation but a lot of people will see it that way, e.g. Single-file scripts that download their dependencies
- We could do it based on a `.rs` extension (`cargo new foo.rs`)
 - This doesn't help if someone wants an extension-less script
 - This might be confusing if someone wanted to name their package that since they will get a file and not the error guiding them on proper syntax (though -rs suffixes are discouraged)
 - Speaking of, multi-file `cargo new` could warn about `-rs` suffixes...


Thank you!

Not much, to be honest. But I have plenty of experience with technology breaking as I upgrade it.
I also have a lot of experience of using older editions, it's not the end of the world.

My fear is that if we don't make it really easy to specify the edition, the top requested feature around cargo script will be that there to be a way for the warning to be turned off, which is the opposite of what we'd like.

I've also been in the threads when editions were originally discussed, and the big goal there was to not repeat the python2/3 situation. With python, it's comparatively easy to specify the version right in the shebang, with some distributor worries. And I agree that the 40 years concerns rule out that option for us, but something really simple and easy would be great.

See my `#![edition = "2021"]` proposal, it would be the best yet. Yeah it's another way of specifying the edition but I think we can spend some learning budget on making things require less characters. I think for script files, the edition key is the main user of the `[package]` section.

Your point about practical experience is noted though, and I will do some evaluation of the nightly feature. I have a bunch of throwaway projects that would benefit from being in a single file.

That's a fair demand, and something I also share. `#![edition = "2021"]` would solve that.

To use your argument about not wanting a default, specifying the edition is practically required today already in multi file projects because cargo is defaulting to 2015 :). Also, people could perceive it as surprising that multi file projects have a different default from single file ones.

IMO, it's the best situation to do that because you have a green field. When you introduce a new feature you have a huge design space. I think one shouldn't be cautious with ideas as long as they provide benefit to the users, and they fit in well with existing features. For me, my proposal to treat the first block comment in the file specially (or only the first block comment that is directly after the shebang), is that.

Wrt to your points about introducing special comment syntax e.g. `/*% ... */` or `////` possibly requiring a new edition, if you do that from the start, or at least reserve it via erroring if that syntax is encountered, then you don't need a new edition at all. Also, to be clear, it's more or less what I've been asking for, and such a feature would totally satisfy my demands for more brevity :).

IMO this is not much of a concern, in general, because syntax highlighting will follow what languages introduce, especially as features get used a lot. Yes, it might take years for it to be adjusted, but shrug, so do new keywords, or removals of such. In general, I think the main concern for language designers wrt syntax highlighting is that it should be easy to express the syntax in the domain specific languages used by syntax highlighters. But I think so far, all proposals support it well.

Yeah, ideally one brings improvements to both multi-file and embedded manifests. Having toml somewhere in the .rs file is a good idea I think. However, for single things, like the edition, I think it might make sense to add another way, e.g. `#![edition = "2021"]`.

Personally I'm not the *greatest* fan of this, because of the many special characters. But it's certainly lower overhead than the rustdoc idea.


Thank you, I would appreciate it!

To be clear, I was talking about manifest syntax (TOML) and schema (`Cargo.toml` layout) here. Just because we have a wide design space doesn't mean its wise to use it. I'm watching the PEP 722 discussions and they are looking at inventing a new format that is a subset of requirements.txt's syntax when they also have `pyproject.toml`, `setup.py`, and many other ways of doing these things. And yes, I'm not thrilled that we support a subset of the `Cargo.toml` schema and I'm not thrilled that we have defaults beyond `Cargo.toml` but I feel that is better than a completely new format.

And following the syntax and schema doesn't mean we can't later introduce shorthands but I think those shorthands should have a direct correlary to the existing syntax and schema. For example, if we offer a deps shorthand, it should use TOML syntax and Cargo.toml schema within that shorthand rather than inventing a new syntax like cargo script did with cargo-deps

Yes, we do have some flexibility because this is a new place where it can be used.

However
- rustc does not know the context nor should it really to handle that syntax
- rust-analyzer support is still unclear for how it will detect single-file packages and having the embedded manifest as one indicator could be useful. This means it needs to work with code from both systems
- At least Josh and I felt that we shouldn't just be inventing some new semantically meaningful comment syntax proprietary to cargo with regex parsers for it but that this should start as an attribute that gets comment rust syntax support if needed

This reply is to a subset of my comment. We specifically called out "on the web". Yes, dedicated IDE support will handle syntax highlighting for whatever syntax we throw at it but I doubt most random website syntax highlighting systems will unless you happen to be in the fraction of users who use a treesitter based syntax highlighting for your blog or book (or you go through the hassle of manually highlighting the code).

I've typed out the cargo-script syntax many times and I've written many attributes in other context (and without raw strings), all on US keyboard. For me, attributes feel like a lot more of a hassle because the syntax is so disjoint.


I agree that toml is the best way to specify manifests, and that one should not do non-toml stuff in single file scripts. That being said, for the edition one could make an exception IMO, via `#![edition = "..."]` (and still allowing toml-specified editions, but never allowing both at the same time).

My comment was more in response to your points about alternative syntaxes to the rustdoc markdown toml snippets being potentially surprising to users, and a challenge for syntax highlighters/ downstream tooling etc.

That being said, the specific use of toml commonly seen in `Cargo.toml` might not be optimal for builtin manifests, e.g. in the a recent single file script experiment I made the following snippet, which I really liked:

`rust
/*!

cargo
package = { edition = "2021"}
dependencies = { toml = "0.7.6" }

*/

`

This uses inline tables, and saves two lines compared to the approach with `[package]`, `[dependencies]`, etc. It is not as scalable, but one can mix it like:

cargo
package = { edition = "2021"}
[dependencies]
toml = "0.7.6"
syn = "2.0"
serde = "1.0"

Especially for `[package]` I feel it can be turned into an inline table. Most people probably don't want to add repo or docs.rs links to their one-file packages. Maybe the `cargo new` template should use an inline table for `[package]`.

How much of that is motivated by rust parsing library limitations (syn, etc)? IIRC most of the rust parsing libraries don't let you inspect the content of comments. So yeah it's harder to implement, but personally I think that design considerations, aka what the impact of the feature is for the end user is, should have priority over "is it possible to use syn without modifying it".

Also, given that rustc doesn't really need to concern itself with the syntax, why do an attribute first? Rustdoc comments only associate with their respective attributes because of an implementation detail of how the compiler lowers them (exposed to stable, but still, mostly an implementation detail). I don't think one needs to have an attribute first. You could also equally start with the rustdoc+backtick syntax (it would be sad but it would also provide good parsing library support).

I agree that that rendering on websites should be a major priority for the design of the feature, because of one of the intended use cases of the feature: sharing of snippets, which happens via the web. Good point that you pointed that out!

But I also feel that quick editing and brevity of those shared snippets is important, which is where custom comment syntaxes shine. But I doubt that supporting "is this `/**/` at the start of the file, if yes then treat it as toml" is harder to add than support for arbitrary markdown in rustdoc comments, then adding snippet support to that, and adding special cases for `cargo` annotated snippets. For me, "`/**/` but at the start of the file" comments or `/*% */` ones seem easier to support.

E.g. github's highlighter doesn't support markdown snippets at all, it just treats rustdoc as random rust comment.

I have a german keyboard, and yeah `[]` is a bit tough to type. But I still think it's easier to type a bunch of special characters than to type out `cargo` and another slightly easier to type set of special characters :). Also, in most instances one doesn't need raw string literals for the toml, as toml supports ' strings, another possible deviation of what multi file toml projects are doing that is still within valid toml syntax.


@est31 The rationale for not having semantically meaningful ordinary comments had nothing to do with parsing, and everything to do with user expectations. Users are used to doc comments being parsed, having doctests in them, etc. *Regular* comments are completely ignored with no semantic effect, and that creates user expectations that comments are *their* space, not to be impinged on by compiler expectations.

Regarding the edition, I've been hoping we can allow omitting `package`, which makes the syntax less verbose:

rust
//!
cargo
//! edition = 2024
//!

Shortening that to just `#![edition = 2024]` feels like it special-cases *one* attribute in a way that invites people to assume they can do the same for all the other package attributes, which will then produce an error unless we make all of those work too.


You don't even need an inline table for this

toml
package.edition = "2021"
[dependencies]
toml = "0.7.6"
syn = "2.0"
serde = "1.0"


I`ve given your trick a try, and it works!
Swapped MISO from GPIO12 to GPIO16 and now the MISO reading remains 0!
Reimplementing the MISO check on boot and everything is okay now.

Cudos to @SmOeL-swdev!
Of course I live and work in probably the same country, the Netherlands :)


I don't see this as an exception to the syntax/schema guidance i gave but aligns with the "but we can allow shorthands that align opon syntax/schema in the future". The future being a key part.

In addition to wanting to defer shorthands, my other concern is that the "edition" concept is also present in Rust. I think a proposal for an `edition` attribute has to make sense in at the rust level, independent of cargo.

---

we could consider `package.edition = "2021"` for `cargo new`. The main question I would have is if/when we add support for libs where there might be other fields, like enabling publishing, would we instead want `[package]` and should we be consistent in style.


About using doc comments: if it's not meant to be used by rustdoc, I don't think it should use this syntax.

I personally like the `cargo` attribute approach.

The logic is good but I don't agree with the origin of this logic: doc comments are used by rustdoc and that's it. This new content will be used by cargo, therefore using doc comments to handle this feature is not the right approach in my opinion.


@GuillaumeGomez They're also used by doctests, which from a user's perspective are just an integrated part of `cargo test`.

I agree that if we want rustdoc to ignore and not process them, we shouldn't use doc comments. But I don't think we want rustdoc to ignore them.


From user's perspective, doc comments are used by `cargo doc`, so that's not a good argument. But in any case, doctests and doc comments are handled by rustdoc.

I don't see why: we don't display cargo information directly, only a small subset provided through command line arguments. Therefore, it wouldn't be coherent in this regard.


@joshtriplett

That's an interesting proposal. I think it makes a lot of sense. I guess your proposal is to make it possible to specify *all* keys in the `[package]` table at the top level? Still makes sense IMO.

They might think that but IMO the benefit of being able to specify it without having to specify a manifest is worth this cost.

Personally, to me it seemed like a rough edge of this proposal that users have to include the manifest in the documentation output of their crate, in a way separate from multi-file crates (in general I think that rustdoc displaying the manifest and especially the cargo features is a good idea, but it should be something that multi-file crates support, and it should not automatically be at the main page). It seemed only like a rough edge though as one can always add syntax to not display it, or just not make rustdoc process it at all. But IMO, any toml display feature of `cargo doc` should also include multi file crates. I felt and feel much more strongly about the verbosity though.

@epage

I think outside of the edition and github links, most of the required stuff can be inferred. Authors aren't a thing we suggest any more, and crate descriptions can be inferred from the rustdoc (take the first line of the crate-level rustdoc).

Fair point. Personally I'm concerned less about the impact the edition behaviour has on the cargo part but about the impact it has on the Rust part: from my POV, cargo doesn't have as many breaking changes on edition boundaries as Rust has, and is also a major source of breakage of its own through crate updates (not cargo's fault obv). The edition is controlled via cargo though as cargo passes the edition flag.

And yeah, if one adds an `#![edition = "..."]` attr to cargo-script, it should also be added to Rust, and vice versa, cargo-script should probably understand `#![edition = "..."]` attrs. I suppose this means that rustc should forbid hiding it behind `cfg_attr` like is being proposed for crate_name and crate_type.

Thanks for giving me the pointers, I guess I should be knocking the doors of T-lang and/or T-compiler about this attr.


I'm introducing a dedicated `TransactionListener` contract, with such listeners to be registered on the transaction manager itself. There are before/afterBegin, before/afterCommit and before/afterRollback callbacks which are being triggered by the transaction manager whenever it operates on an actual transaction.

This is effectively a callback interface for stateless listening to transaction creation/completion steps in a transaction manager. It is primarily meant for observation and statistics, not for resource management purposes where stateful transaction synchronizations are still the way to go. In contrast to transaction synchronizations, the transaction listener contract is commonly supported for thread-bound transactions as well as reactive transactions, with a common registration facility in the new `ConfigurableTransactionManager` interface.


I've settled on the term "transaction execution listener" for it, also naming the contract `TransactionExecutionListener` which goes nicely with the provided `TransactionExecution` argument in the callback methods. A more general "transaction listener" term can be confused with `TransactionalApplicationListener` and `@TransactionalEventListener`.


I'm all in favour of displaying more information. However I think it should be passed through arguments to rustdoc instead of having rustdoc to retrieve the information from the toml file.

It's very strange to try to hide a doc comment only for this use case. What if users use the same code block syntax and suddenly it doesn't appear anymore because of this feature? Sounds like a very bad user experience and a very weird corner case.


@snicoll @wilkinsona I suppose Boot could automatically inject any `TransactionExecutionListener` beans in the context into a `PlatformTransactionManager` or `ReactiveTransactionManager` that it configures, along the following lines:

@Bean
public JdbcTransactionManager transactionManager(DataSource dataSource, Collection transactionExecutionListeners) {
 JdbcTransactionManager tm = new JdbcTransactionManager();
 tm.setDataSource(dataSource);
 tm.setTransactionExecutionListeners(transactionExecutionListeners);
 return tm;
}


see. Here are some things you can try to fix the performance issue with Visual Studio Code:

Disable hardware acceleration. This can sometimes help to improve performance. To do this, open the Command Palette (Ctrl+Shift+P) and run the Preferences: Configure Runtime Arguments command. In the argv.json file that opens, add the following line:
"disable-hardware-acceleration": true
Disable extensions. If you have a lot of extensions installed, they can sometimes slow down Visual Studio Code. To disable extensions, open the Extensions pane (Ctrl+Shift+X) and uncheck the boxes next to the extensions you want to disable.

Reset Visual Studio Code. This will restore Visual Studio Code to its default settings. To do this, open the Command Palette (Ctrl+Shift+P) and run the Reset Visual Studio Code command.

Update Visual Studio Code. There may be a newer version of Visual Studio Code available that fixes the performance issue. To check for updates, open the Command Palette (Ctrl+Shift+P) and run the Check for Updates command.

If you have tried all of these things and the performance issue is still happening, you can try contacting Microsoft support for help.

Here are some additional troubleshooting tips that you can try:

Check your CPU and memory usage to see if there is anything else that is running that is using up a lot of resources.
Make sure that you have enough disk space available.
Try restarting your computer.
Update your graphics card drivers.
I hope this helps! Let me know if you have any other questions.


Thank you for providing the information. I understand that Visual Studio Code can slow down when McAfee software is installed. This is because the Real-Time Scanner in McAfee scans a specific Visual Studio program file, which can cause a delay when opening or using Visual Studio Code.

To work around this issue, you can exclude the Visual Studio file from being scanned by McAfee. To do this, follow the steps below:

Open LiveSafe or Total Protection.
On the left menu, click the My Protection Widgets icon in McAfee security software for Windows tab.
Click Real-Time Scanning.
Click Add file.
Browse to find the code.exe file. This file can usually be found in the following location:
C:\Users\(USERNAME)\AppData\Local\Programs\Microsoft VS Code\code.exe
With code.exe selected, click Open. The file is now excluded.
Open Visual Studio Code to confirm that it opens without a delay.
If your installation of Visual Studio is updated before McAfee fixes this issue, you will need to exclude the code.exe file again. This is because when code.exe is updated, your McAfee software sees it as a new executable file that has not yet been excluded.

I hope this helps!


Thanks for the suggestion, @jhoeller. I've opened URL Sorry for the noise of #31001 which I opened in the wrong tracker.


Guys, do you have any plans on how to continue with this? Either get into consensus or conclusion or closing, maybe modify the scope to be more accurate?


@dumb0002 @clubanderson could you folks work on an ADR proposing this integration before we proceed too far down the implementation path? Thanks!


Shouldn’t `Ctrl–Shift–Left` select only to the beginning of the current word? Anyway, to me this would indicate your fn key still submits fn, because `fn–Left` submits HOME on some hardware, which goes to the beginning of the line and Shift selects. Use the keyd monitor functionality to find out what the output really is.


@HeadCrash66 have you solved it already or found a workarround, you might want to look into #151


Or if not, we could make it `compileOnly` for non-native targets only, I imagine.

Annoying that end-consumers will have to download the Poko deps for no reason, but I agree it's not a deal-breaker and can be a future optimization. Closing!


@luetage It's swapped already, and `fn` acts as `ctrl`. It's the 2 observations that I'm concerned to report. As for #401, it holds true for certain OEMs like Lenovo. However, for Apple, I think that's not available unfortunately except from within MacOS itself (the first thing I did after getting my M1 😃).


Can you please direct me to the pull request where it is implemented? Before marking this issue as completed, I wanted to ensure that the second part of this issue has been fixed as well.


I'd like to fix #36801 before going forward as I implemented it as a customizer which make the problem more apparent.


@anishasthana We're still flush out the details of what this integration would be. Once we have a good handle on it we can generate an ADR. For now I'm good with closing this work item until we complete our investigation/evaluation of the KubeStellar technology.

@dumb0002 do you concur with my recommendation to close this work item for now and reopen once the initial investigation/evaluation is complete?


Taxonomy is correct — the thing I'm worried about is the overlap between semantic template parts and pattern categories, specially given they are separate objects (`wp_template_part` and `wp_block`). Which would render a term of "header" associated only with wp_block ambiguous. We might need to share the taxonomy.


@dmatch01 yes, I agree! I am going to close this issue for now and let's reopen it later once our initial investigation is completed as you suggested.


@reta With #2411 [1] merged, I think a large part of this issue is resolved - I am closing. If there are there other features that are not accessible, could you file issues on them or reopen with more details?

- [1] #2411


@peternied From what I understand, the original intent of this request is to disable Transport level TLS (instead of REST-level TLS which the security plugin already supports disabling)

At one point it looks like this feature may have been under development (See URL but I'm not sure of the status of that.

The major concern pointed out here is that disabling Transport TLS has consequences for the logic around nodes joining the cluster securely. A major feature of the security plugin is either the static `nodes_dn` setting in `opensearch.yml` or the dynamic `nodes_dn.yml` file which is part of the security index. In order for a node to join the cluster securely it must present a certificate that matches a known node_dn.


QOI might be worth a look. It is not widespread as exchange format, but quite popular as internal image format in many apps. It has okish compression and is really fast for its small code footprint.


That would be nice to have, indeed. Since it's so little code, it would be easy to audit and fuzz test too.


Thanks for raising the concern about the crossover with template parts. This overlap was already an issue with the pattern categories that are assigned to .org/theme patterns. This is one of the main reasons the `Template parts` heading was put back in the `Patterns` section of the site editor as there were two entries of `header` and `footer` one for patterns and one for template parts, and no clear indication to users why they were duplicated.

<img width="336" alt="Screenshot 2023-08-10 at 4 05 11 PM" src=" URL

In the short term giving users the ability to add their own patterns to a `header` or `footer` category won't add any additional ambiguity to what is already there (the user pattern categories will be merged with the .org/theme pattern categories).

I agree though that it would be good to have a shared taxonomy so users just see one `Header` or `Footer` category, which would then show them all the template parts & patterns related to headers and footers. Exactly how this might be achieved depends on how/when/if template parts might merge with patterns.

While we could reuse the existing `wp_template_part_area` taxonomy for patterns it is an odd fit name-wise, and I am not sure about the risks of a rename in terms of database migrations, backwards compat with plugins, etc.

It seems like the lower-risk option is to proceed with adding the `wp_patterns_category`. Then the first step of removing the ambiguity could be to merge the template and pattern category results in the patterns page. Once the future of template parts in relation to patterns is decided decisions could then be made on how taxonomies could be further merged, and based on recent changes it seems like this is more likely to be template parts merging to patterns rather than the other way around, so the `wp_patterns_category` is more likely to be the taxonomy that is still needed.

Let me know if you have any different views/thoughts on this.


@aaemnnosttv Sure, I can ask someone to pick this up for IB so I can try to get it into the next sprint – will depend on what kind of launch blockers we have from the KMW Bug Bash, though. Thanks!


@fishjojo , thanks for raising this issue. Has it been resolved?


I have to add a small description in ivy\ivy\functional\ivy\experimental\set.py for the function, i'll create a PR after that, can you assign the task back again, Tysm.


Marking this as high impact, as it is a recurring pain. Resolving this would lower the load on clusters experiencing problems where timers, buffered messages, or job timeouts play a role. This would help in the investigation as well as ease recovery.


Vu qu'il n'y a pas de fonctionnalité de recherche sur ce module, est-ce qu'il serait préférable de masquer la barre de recherche ? (js + css) car sûrement pas possible via MapEntity view.


There are also examples where it is possible to use an "adjective noun" combo, but it is unusual and the compound would be preferable: e.g. "diagonal matrix" could be translated as "diagonale Matrix", but this would be odd, the usual translation is "Diagonalmatrix".


Here's another complication: "value" is "Wert" in German. But "absolute value" is "Betrag", or sometimes "Absolutbetrag", but never "absoluter Wert" or anything else involving "Wert".


the way this is handled is that every concept corresponds exactly to an entry on wikidata (almost always, modulo a few edge cases, and these will eventually have wikidata tags too), so for example lattice in the former sense is Q595364 and in the latter sense it is Q1096885 — the fact that they happen to have the same translation into English is then something that the database doesn't care about :-)


however, at the moment there is no entry for lattice in either sense, and there is no way for users to add entries via the submission tool, but I'm hoping to do a massive restructure of the entire project soon (see the comments that I'm just about to write on URL that will fix this


Great questions, and first of all thank you for your interest in contributing!

As for an actual answer, it basically boils down to "with how poorly the database is currently structured, this is impossible" *but* I'm hoping to get do a complete restructure over the next week or so (if I find the time) which would solve this issue entirely — I'll post on this thread when that's done!


OK, it turned out to be a lot easier than I thought to make a temporary fix: for now, there is no distinction between adjectives and nouns; e.g. the term "diagonal matrix" is simply its own entry, separate from "matrix". This should solve this problem.


Oh, that's great!

Unfortunately it also means I have to redo this PR I was preparing to add a bunch of German translation... :-(. But I'll manage, no worries ;-)


URL - ERR_CONNECTION_CLOSED
Only up for 10 of 42 Uptrends checkpoints.


Si en effet tu as raison, on pourrait carrément cacher la barre de recherche car ça n'a pas de sens dans ce module.


I tried in URL
But it didn't worked: URL

[2023-08-14 05:27:22] Waiting for /dev/xvda* devices...

[2023-08-14 05:27:22] Qubes: Doing R/W setup for TemplateVM...

[2023-08-14 05:27:23] [ 2.836815] xvdc: xvdc1 xvdc3

[2023-08-14 05:27:23] Setting up swapspace version 1, size = 1073737728 bytes

[2023-08-14 05:27:24] [ 3.052640] random: crng init done

[2023-08-14 05:27:24] UUID=50685a9b-25ff-4cb6-b107-7170602a08e6

[2023-08-14 05:27:24] Qubes: done.

[2023-08-14 05:27:24] mount: mounting /dev/mapper/dmroot on /sysroot failed: Invalid argument

[2023-08-14 05:27:24] Waiting for /dev/xvdd device...

[2023-08-14 05:27:24] [ 3.086464] /dev/xvdd: Can't open blockdev

[2023-08-14 05:27:24] [ 3.086937] EXT4-fs (xvdd): mounting ext3 file system using the ext4 subsystem

[2023-08-14 05:27:24] [ 3.089277] EXT4-fs (xvdd): mounted filesystem with ordered data mode. Quota mode: none.

[2023-08-14 05:27:24] mount: mounting none on /sysroot/lib/modules failed: No such file or directory

[2023-08-14 05:27:24] [ 3.172895] EXT4-fs (xvdd): unmounting filesystem.

[2023-08-14 05:27:24] mount: can't read '/proc/mounts': No such file or directory

[2023-08-14 05:27:24] BusyBox v1.36.0 (2023-01-10 00:00:00 UTC) multi-call binary.

[2023-08-14 05:27:24]
[2023-08-14 05:27:24] Usage: switch_root [-c CONSOLE_DEV] NEW_ROOT NEW_INIT [ARGS]

[2023-08-14 05:27:24]
[2023-08-14 05:27:24] Free initramfs and switch to another root fs:

[2023-08-14 05:27:24] chroot to NEW_ROOT, delete all in /, move NEW_ROOT to /,

[2023-08-14 05:27:24] execute NEW_INIT. PID must be 1. NEW_ROOT must be a mountpoint.

[2023-08-14 05:27:24]
[2023-08-14 05:27:24] -c DEV Reopen stdio to DEV after switch

[2023-08-14 05:27:24] [ 3.193656] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100

I think I did set it correctly:

root# cryptsetup luksDump /dev/nvme0n1p3; echo efDdj-$?-
LUKS header information
Version: 2
Epoch: 3
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: c51bf27f-c7e1-443b-917d-b95db5145101
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)

Data segments:
 0: crypt
 offset: 16777216 [bytes]
 length: (whole device)
 cipher: aes-xts-plain64
 sector: 512 [bytes]
...

Any ideas?


@marmarek:

The test had `HDDMODEL` configured with `physical_block_size=4096,logical_block_size=4096`, so it's emulating a 4Kn drive. To test 512e (in the sense that's causing the R4.2 regression due to new cryptsetup) it should be `physical_block_size=4096,logical_block_size=512`

(Hardcoding `--sector-size=512` doesn't help with 4Kn drives, because dm-crypt cannot shrink the logical block size, it can only avoid enlarging it.)


Is it only partition table issue? What about the filesystem?
But also, the remark about dynamic resize is a valid one. Only one partition table will be updated, so if you migrate to a disk with a different logical block size, you'll get truncated partition.
But if that's _just_ about partition table, maybe we can do the conversion in initramfs before mounting anything? Assuming everything is 4k-aligned, it should be technically possible, right?


Yup, it’s just about partition table, and we can avoid the dynamic resize problem by changing the partition table with our own tools that understand the different layout.


@rustybird what do you think about adjusting partition table in initramfs?


I like the simplicity of it, especially compared to my 4-phase slog of a proposal.

The adjustment script should probably bail out early if the root volume looks too nonstandard? E.g. if xvda3 is not an ext4 filesystem (or another filesystem type that's whitelisted as known to be logical-block-size agnostic).


@rvem Can we use crossSystem(instead of emulatedSystems) here?


Kevin, peut on savoir à quel stade en est la validation du déploiement ?


@albanD:

I'm not available to review your PR. Maybe @pitrou can review it.


@eleanorjboyd I'm assuming this fix is in the latest version of the plugin? I'm still not seeing all my tests discovered. Haven't tried against the skeleton repo I sent you yet, but our actual project is only showing me one test package.

Also, it no longer shows all my subpackages as top-level elements in the test view. Instead, I have the root of our project and have to drill down our folder structure to see the tests. With the multi-root worksapce, I would still expect to see each root module as a test parent.


Still seeing the same issue with Insiders build and pre-release versions of Python/Pylance.


@ElSamhaa Can you test this too and verify you're seeing what I'm seeing?
- #comment your rules (/etc/keyd/default.conf)
- sudo keyd -m
- press (and hold) the `fn` key
- press `backspace`
- press `left`
- release `fn`

I get the following output ("delete" instead of "backspace", "home" instead of "left"), which would indicate that the macbook is not sending the original keys for backspace and arrow keys when `fn` is held down (I'm using Fedora Asahi Remix on an M1 MacBook Air)

keyd virtual keyboard 0fac:0ade fn down
keyd virtual keyboard 0fac:0ade delete down
keyd virtual keyboard 0fac:0ade delete up
keyd virtual keyboard 0fac:0ade home down
keyd virtual keyboard 0fac:0ade home up
keyd virtual keyboard 0fac:0ade fn up


@AnnaTz @hirwa-nshuti the implementation of log_poisson_loss is implemented wrong and tests are failing for it..can u assign that to me ?
I will implement that in the correct way.


@rxhfcy yep, exactly the same with me. I'm on the fedora Asahi remix too btw.


@ElSamhaa great, so this issue can be closed then (not a keyd bug but a feature of the Asahi Linux kernel)

PS. About your earlier comment:

Luckily, that's not true. Here's a pretty easy way to swap `fn` and `control` in Fedora Asahi Remix (permanently, you can later undo this by using `hid_apple.swap_fn_leftctrl=0` instead of `hid_apple.swap_fn_leftctrl=1` if you want):

shell
sudo grubby --update-kernel=ALL --args="hid_apple.swap_fn_leftctrl=1"

...and then reboot. Or if you want to see the effect immediately, you can do this too (not permanent):

shell
echo 0 | sudo tee /sys/module/hid_apple/parameters/swap_fn_leftctrl


@Repechinskyi the first time you initialise formBuilder you don't use the promise

`fbInstances.push($(".build-wrap").formBuilder(fbOptions));`

and then further on you use do

javascript
var formBuilder_load = await $(newPage).formBuilder(fbOptions).promise;
fbInstances.push(formBuilder_load);

Fix up the first initialisation and it should work for you.

@kirykr The recursive method works well too.


@lurch Talking to @jehlers42 right now and this part of the docs (highlighted in red) still seem to be present on the `bookworm` branch. Shouldn't all this stuff be deleted from the branch at this point. The tutorials still need to be written but I thought you'd told me you'd deleted the text from the branch at this point? If not everything in the red box needs to go.

@jehlers42 can you figure out what text needs to go, and get rid of it from the `bookworm` branch. Post the commit back to this thread, and leave the issue open, 'cause we still need to write the updated tutorial(s) which will end up in Wordpress.


...and they are no longer in the branch. Leaving this issue open because someone (me, @tobybroberts, Nate perhaps when he joins) needs to write replacement tutorials (in Wordpress).


Nope, I don't ever remember claiming that. I was leaving the text in-situ in case it'd be a useful reference for whoever ends up writing the replacement tutorials? But you're right, they should definitely be removed from the `bookworm` branch before it gets merged :+1:

On a vaguely-related note, I wonder if it'd be useful to have a "link-to-tutorial boxout" (like @nelliemckesson has done for PIP and the RPi Press books) that we could use to link from the documentation to the tutorials? :thinking:


Still persists.. But I found a solution using the image package:

dart
import 'package:image/image.dart' as img;

 late CameraController _controller;
 late bool _isRearCameraSelected;
 late bool confirm;
 late bool isFlash;
 late XFile image;
 late img.Image flippedImage;

 Future initCamera(CameraDescription cameraDescription) async {
 _controller = CameraController(
 cameraDescription,
 ResolutionPreset.high,
 enableAudio: false,
 );
 try {
 await _controller.initialize();

 if (!mounted) return;

 setState(() {});
 } on CameraException catch (e) {
 debugPrint("camera error $e");
 }
 }

 @override
 void initState() {
 super.initState();
 _isRearCameraSelected = true;
 confirm = false;
 isFlash = false;
 initCamera(widget.camera[0])
 .whenComplete(() => _controller.setFlashMode(FlashMode.off));
 }

 @override
 void dispose() {
 _controller.dispose();
 super.dispose();
 } Future initCamera(CameraDescription cameraDescription) async {
 _controller = CameraController(
 cameraDescription,
 ResolutionPreset.high,
 enableAudio: false,
 );
 try {
 await _controller.initialize();

 if (!mounted) return;

 setState(() {});
 } on CameraException catch (e) {
 debugPrint("camera error $e");
 }
 }

 @override
 void initState() {
 super.initState();
 _isRearCameraSelected = true;
 confirm = false;
 isFlash = false;
 initCamera(widget.camera[0])
 .whenComplete(() => _controller.setFlashMode(FlashMode.off));
 }

 @override
 void dispose() {
 _controller.dispose();
 super.dispose();
 }

// This is the OnTap function of an InkWell widget
 () async {
 try {
// we take the picture using the camera package
 image = await _controller.takePicture();
 if (!_isRearCameraSelected) {
 flippedImage =
 img.decodeJpg(await image.readAsBytes())!; // we fill in the image in memory for manipulation
 flippedImage = img.flipHorizontal(flippedImage); // we flip it
 await img.encodeJpgFile(
 image.path, flippedImage); // and finally override the original image with the corrected one
 }
 // display the confirm
 setState(() {
 confirm = !confirm;
 });
 } catch (e) {
 developer.log(e.toString(),
 name: "exception in takePicture");
 }
 }


I found a workaround involving a third party library: `package:image`

dart
import 'package:image/image.dart' as img; // import the library

// Then in your *Stateful* widget:

 late CameraController _controller;
 late bool _isRearCameraSelected; // have some variable to handle the state of switching between cameras...
 late XFile image; // the image file, managed by the controller
 late img.Image flippedImage; // the flipped image, gonna use this as a temp variable
...

// This is our version of initializing the camera with settings, feel free to modify as needed:
 Future initCamera(CameraDescription cameraDescription) async {
 _controller = CameraController(
 cameraDescription,
 ResolutionPreset.high,
 enableAudio: false,
 );
 try {
 await _controller.initialize();

 if (!mounted) return;

 setState(() {});
 } on CameraException catch (e) {
 debugPrint("camera error $e");
 }
 }

 @override
 void initState() {
 super.initState();
 _isRearCameraSelected = true;
 confirm = false;
 isFlash = false;
 initCamera(widget.camera[0])
 .whenComplete(() => _controller.setFlashMode(FlashMode.off));
 }

 @override
 void dispose() {
 _controller.dispose();
 super.dispose();
 }

...

// Down into the function callback for when you click on a button to switch cameras:
 () async {
 try {
 image = await _controller.takePicture();
 if (!_isRearCameraSelected) {
 flippedImage =
 img.decodeJpg(await image.readAsBytes())!;
 flippedImage = img.flipHorizontal(flippedImage);
 await img.encodeJpgFile(
 image.path, flippedImage);
 }
 // display the confirm
 setState(() {
 confirm = !confirm;
 });
 } catch (e) {
 developer.log(e.toString(),
 name: "exception in takePicture");
 }
 }


formRender does not have the promise interface, only multiple formBuilder instances need to be created via awaiting the promise interface.


@Sosannah Do we know when this can be added to the live database? All looks good from my end.


Update from McAfee: the fix got delayed and is now planned for the release at end of September.


Today I noticed this indexer is working again. Can anyone else confirm?

I am getting successful tests in Jackett dashboard and successful searches/downloads in sonarr.


I think I'm struggling with the same issue. I have to use lifecycle policy to delete untagged images. They are produced when using caching mechanism and size of image is the same as tagged image.


Now it's been added to the Vascular Plants collection in the live database.
Should I modify the Entomology collection also?


This is for all collections and all museums
________________________________
From: ZsuzsannaPapp ***@***.***>
Sent: 25 August 2023 14:42:10
To: NHMDenmark/DanSpecify
Cc: Pip Brewer; Mention
Subject: Re: [NHMDenmark/DanSpecify] Consequences / support for access policy (Issue #222)

Now it's been added to the Vascular Plants collection in the live database.
Should I modify the Entomology collection also?

—
Reply to this email directly, view it on GitHub


I see. Then I need some more time - it will be done by Wednesday at the latest.


What is the status of the separate pipeline to test node 14 backward compatibility? There are going to be users using old linux versions who can't go past node 14 yet, and it would be useful to know what fixes we can do so as to not unnecessarily break things for those users.


I can confirm they are RGB, because when the XL detects a crash, they turn red. :-)


Patch apparently caused regression for nested multiprocessing calls in 11.5. #108520


Thanks for the trick! A permanent solution would even better :)


My company is also interested in this, i see this as one basic feature. And i really hope this will be implemented..


@wbeckler We do not have plans to create a separate pipeline in public Jenkins infra for EOL versions of Node. If needed, this needs to be tackled at repo level.


Having tested this I am actually not happy about the way it works currently and feel we should spend more time on it to really fix the rough edges:
* why does this only apply to text editors and terminals but for example not notebooks?
* why does it apply to terminals in the panel but not other panels?
* why does it not apply to the sidebar?

I guess I am not really understanding what we want to solve here: if the idea is to make the focussed part stand out more from other parts, then I would argue we should consistently highlight the "thing" that has keyboard focus and dim everything else. The current solution seems half-baked.


I guess this is because I rarely use editors other than the text editor 😅. I don't expect editors other than the webviews to be hard to implement.

@bpasero let's discuss this in URL


That is the opinion of one user, do we have consensus that this is what we want to build? I personally would at least want other panels that accept keyboard focus to participate as well because these can show lots of output and even may look like an editor.


It's 3/3 users that commented on it recently (see URL URL plus the requestor of the feature ( URL - "Dim or otherwise indicate "inactive" editor/terminal"). Additionally, almost all comments on the issue mention only terminals and editors.

Dimming all other views would make the feature less useful imo, the reason users want this is to dim less relevant editors and terminals (primary work areas), dimming other parts of the UI that show auxiliary information would harm the user experience as they often augment the active editor. I understand it seems somewhat arbitrary, but it's solving a targeted problem.

We can expand it later if needed `(accessibility|workbench.view).dimUnfocused.views: { terminal: true, ... }`, but right now that's solving a problem that no one is asking for and I wanted to solve the issue efficiently for those requesting it.


I'd be interested in hearing about end-to-end workflow descriptions. Those of you who expressed interest, how would you envision that this worked from start to finish?

Say you are an org with a couple hundred or thousand repos and teams. You want to start adopting Backstage. What would you like the journey to be like, for your end users to start getting things into the catalog and get all of the right metadata into place, from that blank slate? How would permissions and the lifecycle of things work?


On the company that i work now, we divided the implementation on stages...

- 1 Stage (we are on this stage right now BTW):
Techdocs + Software Catalog + Users + Groups
We took 2 teams and they are in-charge to catalog and adding they own entities on a catalog repository.

- 2 Stage:
Expand from 2 teams to a tribe.

- 3 Stage:
Expand to all our 6 tribes.

- 4 Stage:
Implementing software templates, CI-CD, centralize all the solicitations of services on backstage.

For now. Stage 1 we encounter some issues.
Th adoption is running really slow, the dev's must clone the backstage service as well the catalog, running both on the machine and fixing entity errors... THEN creating a branch, making a pull request, and other team testing and validating if the PR is ok.
In the future all this entities must have some changes, updates etc.. and this process is slow and not that user intuitive even for the dev's.

Will be really nice to have a interface to help with..

I imagine working something like this..
1 - Developer logging on backstage.
2 - He have a button to CREATE a entities (user, system, api etc..) OR he can select a existing one and just editing that.
3 - The interface will be very similar to CREATE or UPDATE a entities.
will be nice if this will be a complete interface, with selects for choosing TEAMS, APIS from other entities, like form interface, maybe using the entities APIS to bring existing data of the database, like: "i'm creating a new API, this api has a part on a System, or consumes other api, is own by the the team" something like this..
4 - the dev click on save, then backstage makes sure that the entity is all ok.
5 - The dev save the changes directly on the YAML file and the database,( or only the database)

OR maybe like this..

1 - Developer logging on backstage.
2 - He have a button to CREATE a entities (user, system, api etc..) OR he can select a existing one and just editing that.
3 - Brings him to a online text editor, so he can make the changes, with help of ta intelisense, auto-complete, with all the tools need to facilitate this step.. if the user are Creating a new entities maybe given the option to use a template..
4 - the dev click on save, then backstage makes sure that the entity is all ok.
5 - The dev save the changes directly on the YAML file and the database,( or only the database)

On both cases i saw the permissions like this..
Devs/TechLeads can edit and create entities of their own SQUAD.
PrincipalEngineer can edit and create entities of multiple SQUADS from his tribe
Coordenators can edit and create entities of ALL tribes..

BTW all teams can SEE all the entities from other teams..

This is how i saw on the company that i work... maybe this will not be 100% to other people on this thread..

(i'm not native to English language so, forgive-me if i wrote something not 100% clear.. )


Some of these may have been mentioned, but no unfocus on some other views in the workbench including gitlens, ports, comments, refactor preview.

Other than that it looks solid in a bunch of the themes I tried it in as well.


Just to add confirmation to what has already been documented here and to document for others using the gcloud cli and finding this in search, I'm on python3.11.5 as well (`Python 3.11.5 (main, Aug 24 2023, 15:09:45) [Clang 14.0.3 (clang-1403.0.22.14.1)]`) and am encountering this error with the `gcloud` cli tools.

A search for the following error message brought me here:

sh
$ gcloud storage cp gs://bucket/file ./ --verbosity debug
DEBUG: Running [gcloud.storage.cp] with arguments: [--verbosity: "debug", DESTINATION: "./", SOURCE:1: "['gs://bucket/file']"]
DEBUG: Starting new HTTPS connection (1): storage.googleapis.com:443
DEBUG: URL "GET /storage/v1/b/bucket/o/data%2Ffile?alt=json&projection=noAcl HTTP/1.1" 200 896
Copying gs://bucket/file to file://./file
INFO: Using high CPU count, single-file workload config.
⠛ERROR: gcloud crashed (AttributeError): 'Lock' object has no attribute 'is_fork_ctx'

This happens regardless of which gcloud version I upgrade or downgrade to:

$ gcloud version
Google Cloud SDK 444.0.0
beta 2023.08.22
bq 2.0.97
core 2023.08.22
gcloud-crc32c 1.0.0
gsutil 5.25

And I can successfully execute the command if I tell gcloud to use an older python version before 3.11.5, e.g.:

sh
$ CLOUDSDK_PYTHON=python3.10 gcloud storage cp gs://bucket/file ./
# (executes just fine)


Since it would be a general modification for all of them, it would make sense to modify the global.views, but it's not so obvious. After several dead-ends, I've contacted Kansas - until they answer, I should put this on hold.


I get graphical glitches, video desync, and signal loss from my N64 Digital via HDMI using Blue Retro. Is this problem related?


Thanks for the issue, looks to be fixed :) URL

(also the nuxt-og-image bug)


Any updates on this? Such functionality would be of major use for a great number of app ideas. I can understand that there is currently no bijection between the functionalities of the native ground overlays for Android and iOS, for example the fact that the iOS implementation has no constructor allowing the specification of a target location and a width. However, this is not something that basic math can't get around.

Some existing forks of the `plugins` library are of good quality in Android. However, iOS is still rather flaky and unsuitable for production code when attempting more powerful functionality.

Thanks again for all the hard work.


@belech I was inspired by your reference material and built a clone for myself to help learn React. That monaco-yaml library seems to force me into the low-level javascript event listeners and it felt very difficult to use React other than a way to import a component. Did you experience the same?

I dont know if I just lack some React experience, but for the life of me, l just couldnt get Jest to instrument the monaco-yaml editor.

What was really interesting about this effort was that I didnt realize monaco is the VSCode engine and that IDEs use language-server-protocols (LSP). So the monaco-yaml shims the YAML LSP built by Red Hat and so I built a rudimentary VSCode web editor for backstage files. Anyways, really cool experience!

@freben, I kind of like this plugin because I can reuse a full json schemastore which works beyond just backstage files. However, if I try to contribute this feature back, do you have any ideas where should it be located? I just threw mine on the left nav bar, but I'm wondering if it should be an optional drop-down where people typically select the github ingestion tool


Hmm, what about the `title`? It becomes `null` on client hydration if it's set using `useServerHeadSafe`: URL
Using `useHeadSafe` keeps the title intact.


First step would be to see if HttpClientFactory provides a solution to this.


That's right.

Yep, spread them out to where they belong, and leave their management up to their respective owners.

I am again a bit confused by the wording "catalog repo". :) There should be no catalog repo. You should have catalog-info files spread out all across your version control system, and the catalog (the catalog SERVICE, running in your infrastructure) holds a list of URLs pointing to those files. It updates its internal state all the time, in the background, based on the contents of those files.

If an end user changes a catalog-info file in their own repo, that's already registered in the catalog backend, there's no more action to take. You don't re-register. A short while later, the updated info will just automatically be reflected in the catalog.


I am seconding the call for httr2 code snipper support! It is more state-of-the-R-art because it is pipe-able and provides really good support for oauth flows and caching!


Have quick talk with OSD @AMoo-Miki about core, and we are planning to switch 2.x to 18.16.0 next week to start testing on the 2.10.0 build with newer nodejs.

Thanks.


Having the same issue with `nuxt-seo-kit` v1.3.10 and Nuxt 3.6.5 - the title is `null`


Hmm.. there seems to be no better way than `#pragma ` .

Note:
C# does not make extension methods a warning until after UniTask was released.
If extension method is in a different namespace, it may be possible to control the use of extension method only when you want to wait, but it is difficult to change it now.


I've realised that this test is for ROS 1 only. Are there any plans to add examples for ROS 2 with scan matching algoritms without the need for wheel odometry?

Tried the test again with ROS1, scanner, hector and rviz starts up but Global status, Pointcloud and TF are not happy. Complains about:
Global status > Fixed frame > Unknown frame map

Pointcloud2 > Status error > Transform > For frame [cloud]: Fixed frame [map] does not exist

TF: No transform from [xxxx] to frame[map]

Launch file looks like this:


Thanks for your feedback. We will analyze hector_slam support for NAV-350 on ROS-1 and possibilities for a migration to ROS-2.


Hi, can you see if you're using Unhead v1.4. `npm why unhead`, if not can you delete lock file + re-install.


Deleted lockfile, node_modules and installed dependencies again. No luck so far.

`pnpm why unhead`:

@nuxt/devtools 0.8.2
├─┬ @nuxt/devtools-kit 0.8.2
│ └─┬ nuxt 3.6.5 peer
│ └─┬ @unhead/vue 1.4.1
│ └── unhead 1.4.1
└─┬ nuxt 3.6.5 peer
 └─┬ @unhead/vue 1.4.1
 └── unhead 1.4.1
@vueuse/nuxt 10.4.1
└─┬ nuxt 3.6.5 peer
 └─┬ @unhead/vue 1.4.1
 └── unhead 1.4.1
nuxt 3.6.5
└─┬ @unhead/vue 1.4.1
 └── unhead 1.4.1
nuxt-seo-kit 1.3.10
├─┬ nuxt-schema-org 2.2.0
│ └─┬ @unhead/schema-org-vue 0.6.0
│ └─┬ @unhead/vue 1.4.1 peer
│ └── unhead 1.4.1
└─┬ nuxt-unhead 1.4.17
 ├─┬ @vueuse/head 1.3.1
 │ └─┬ @unhead/vue 1.4.1
 │ └── unhead 1.4.1
 └── unhead 1.4.1


Apologies for confusion, this is working correctly on Nuxt 3.6.5! :)


this will still fail if strict is set to false in the tsconfig.json


I can confirm that with nuxt `3.6.5` everything works as expected. I start to have this issue only with `3.7`


this will still fail if strict is set to false in the tsconfig.json... example on the left is without strict mode enabled
image

Took me a second to figure that out. You may end up introducing new TS errors when changing the config, though.

also posted here: #1389


Can you confirm that you're upgrading using `npx nuxi upgrade --force` (should delete lock file + node_modules) and the unhead version `npm why unhead`

I've tried replicating with Nuxt 3.7 and Unhead 1.4.1 and it _seems_ to be working.


Yes, I always upgrade Nuxt with `npx nuxi upgrade --force` because it is the recommended way.

This is my unhead

npm why unhead
unhead@1.4.1
node_modules/unhead
 unhead@"^1.1.26" from nuxt-unhead@1.4.17
 node_modules/nuxt-unhead
 nuxt-unhead@"^1.4.17" from nuxt-seo-kit@1.3.11
 node_modules/nuxt-seo-kit
 nuxt-seo-kit@"^1.3.11" from the root project
 unhead@"1.4.1" from @unhead/vue@1.4.1
 node_modules/@unhead/vue
 @unhead/vue@"^1.3.7" from nuxt@3.7.0
 node_modules/nuxt
 nuxt@"^3.7.0" from the root project
 peer nuxt@"^3.6.5" from @nuxt/devtools@0.8.2
 node_modules/@nuxt/devtools
 dev @nuxt/devtools@"^0.8.2" from the root project
 peer nuxt@"^3.6.5" from @nuxt/devtools-kit@0.8.2
 node_modules/@nuxt/devtools-kit
 @nuxt/devtools-kit@"0.8.2" from @nuxt/devtools@0.8.2
 node_modules/@nuxt/devtools
 dev @nuxt/devtools@"^0.8.2" from the root project
 peer nuxt@"^3.0.0" from @zadigetvoltaire/nuxt-gtm@0.0.13
 node_modules/@zadigetvoltaire/nuxt-gtm
 @zadigetvoltaire/nuxt-gtm@"^0.0.13" from the root project
 peer @unhead/vue@">=1.1.9" from @unhead/schema-org-vue@0.6.0
 node_modules/@unhead/schema-org-vue
 @unhead/schema-org-vue@"^0.6.0" from nuxt-schema-org@2.2.0
 node_modules/nuxt-schema-org
 nuxt-schema-org@"^2.2.0" from nuxt-seo-kit@1.3.11
 node_modules/nuxt-seo-kit
 nuxt-seo-kit@"^1.3.11" from the root project
 @unhead/vue@"^1.3.1" from @vueuse/head@1.3.1
 node_modules/@vueuse/head
 @vueuse/head@"^1.1.26" from nuxt-unhead@1.4.17
 node_modules/nuxt-unhead
 nuxt-unhead@"^1.4.17" from nuxt-seo-kit@1.3.11
 node_modules/nuxt-seo-kit
 nuxt-seo-kit@"^1.3.11" from the root project

And the problems is still here :/

Please let me know if I have to provide more info


The fix appears to be merged and backported. Shouldn't this be closed?


Hmm, interesting. I thought that the auto-merge feature would also auto-close the issue, but it didn't.


quic-go now enables GSO by default. This should bring down CPU load quite a bit, and improve throughput on connections that were previously CPU-limited.


Yes, strict nulls is a required typescript setting for types to work, as mentioned in the docs


Closing this out as the original issue reported here has been fixed with #67664. If there are any additional functional issues with this rule, kindly file separate issues. Thanks!


Status:
Unfortunately, at this time, it should be done at the discipline (collection) level. The global or common view form definitions cannot be replaced directly, though there is an issue on GitHub (#3780) open aiming to address this problem at Kansas.

The suggested come-around should be tested, then implemented in each collections and museums.


Here is a reproduction for `v2.0.0-beta.24` and nuxt `3.7.0`: URL
I think it's the same issue or very related.


Please find attached launch and rviz configuration files adapted for NAV-350 and SLAM support. Just unzip file sick_scan_xd_slam_launch.zip into folder sick_scan_xd.

**NAV-350 ROS-1 SLAM example**

Build hector_slam and sick_scan_xd:

cd src
git clone URL
git clone URL
cd ..
catkin_make_isolated --install --cmake-args -DROS_VERSION=1 -DCMAKE_ENABLE_EMULATOR=1 -Wno-dev

Run rviz, sick_scan_xd and hector_slam:

source /opt/ros/noetic/setup.bash
source ./devel_isolated/setup.bash
rosrun rviz rviz -d ./src/sick_scan_xd/test/emulator/config/rviz_slam_nav350.rviz &
roslaunch sick_scan sick_nav_350.launch hostname:=192.168.0.1 &
roslaunch sick_scan test_200_slam_ros1_hector.launch scan_topic:=/sick_nav_350/scan &

The following rviz screenshot shows an example of a NAV-350 pointcloud created by sick_scan_xd and its map generated by hector_slam on ROS1:
image

**NAV-350 ROS-2 SLAM example**

Install the ROS2 slam-toolbox with `sudo apt install ros-foxy-navigation2 ros-foxy-nav2-bringup ros-foxy-slam-toolbox` (replace `foxy` by your ros distribution).

Build sick_scan_xd for ROS-2 as described in INSTALL-ROS2.md

Run rviz2, sick_scan_xd, slam_toolbox and static transforms:

source /opt/ros/foxy/setup.bash
source ./install/setup.bash
ros2 run rviz2 rviz2 -d ./src/sick_scan_xd/test/emulator/config/rviz2_slam_nav350.rviz &
ros2 launch sick_scan sick_nav_350.launch.py hostname:=192.168.0.1 &
ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 base_link cloud &
ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 base_footprint base_link &
ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 odom base_footprint &
ros2 launch nav2_bringup navigation_launch.py &
ros2 launch slam_toolbox online_async_launch.py &

Note: Laserscan messages need to be remapped to topic `/scan` (default is `/sick_nav_350/scan`). Use `remappings=[ ('/sick_nav_350/scan', '/scan'), ]` in the launchfile, e.g.:

node = Node(
 package='sick_scan',
 executable='sick_generic_caller',
 output='screen',
 remappings=[ ('/sick_nav_350/scan', '/scan'), ], # remap laserscan messages to topic /scan
)

The following rviz2 screenshot shows an example of a NAV-350 laserscan created by sick_scan_xd and its map generated by slam_toolbox on ROS2:
image

sick_scan_xd_slam_launch.zip


@nathan-contino So this is us yanking tutorial content that shouldn't live here and writing a new one in Wordpress (and then we can use that tutorial macro stuff, see #3082 to link back to it the documentation in the right place)


Thanks for the continued effort in helping me debug this, this seems to be fixed with Unhead 1.5.1.

The issue is basically that the client-side doesn't know what the original title is but is rendering a title template.


Fixed with Unhead 1.5.1 hopefully :pray:

Thanks for the issue!


Thank you! I will give it a try.

I see that you are using slam_toolbox for ROS2 instead of Hector slam. I thought it was not possible to use slam_toolbox without wheel odometry feedback?


Fixed in release 2.100.0

It is now possible to filter the list by searching directly for the id of an object.


You are probably right. According to URL and URL you can use URL to create an odometry feedback. But I have not tested it (it is a bit beyond the scope of the driver).

Nevertheless, you can use the slam_toolbox to create an initial map. In navigational mode, the NAV-350 lidar generates pose- and landmark data, which are translated to TF messages. Using these TF messages, you can see in rviz, how the lidar moves on the map.


I tried the ROS 1 example but I get the following when launching hector:
[ INFO] [1694066953.126533259]: lookupTransform base_link to cloud timed out. Could not transform laser scan into base_frame.


I've not identified a need for any Test Coverage additions herein, please let me know if anyone is in disagreement with this. Existing tests should fail (unit and/or visual) should the change have any negative side effects.


Bonjour,

Idem chez moi depuis ce matin avec la mise à jour HA Core en 2023.9.0.

linkytic: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'ENEDIS', 'default_model': 'Compteur communiquant Linky', 'default_name': 'Linky', 'identifiers': {('linkytic', 'XXXXXXXXXXXXXXXXXXXXX')}, 'manufacturer': 'ITRON', 'model': 'Compteur monophasé 60 A généralisation Linky G3 - arrivée puissance haute'} for 'linkytic' config entry: device info needs to either describe a device, link to existing device or provide extra information.

Merci


@10upsimon Can you please add an estimate here? Thanks much!


Hi @10upsimon, thanks for your further investigation on this one.

As discussed on Slack, it does sound likely that the case whereby you manually construct a chart via the JS console is not really representative of a real-world scenario, particularly as you've noted that copying the same code into the page body does not result in an error. That said, if you do have those snippets to hand and can paste them here, I'd be interested to see the code just for a clearer picture of things.

I'm also interested to know if you've verified the proposed fix works when using the Google Translate extension in addition to G Translate, it would be good to have this assurance that it's a general purpose fix.

With regard to your question about testing, I'd agree, this isn't a case that we need to add any additional test coverage for. Our existing tests should provide coverage for general chart rendering, and it's probably not worth adding an E2E test for the integrated case with Google Translate.


@techanvil I can confirm that using the Google Translate Extension is a success as well as using the GTranslate plugin. Both work when the default/fallback value is updated to `{}`;

As for the snippet I was inserting, here it is:

const script = document.createElement('script');
script.src = ' URL
document.body.appendChild( script );

function drawChart() {

 // Create the data table.
 var data = new window.google.visualization.DataTable();
 data.addColumn('string', 'Topping');
 data.addColumn('number', 'Slices');
 data.addRows([
 ['Mushrooms', 3],
 ['Onions', 1],
 ['Olives', 1],
 ['Zucchini', 1],
 ['Pepperoni', 2]
 ]);

 // Set chart options
 var options = {'title':'How Much Pizza I Ate Last Night',
 'width':400,
 'height':300};

 // Instantiate and draw our chart, passing in some options.
 var chart = new window.google.visualization.PieChart(document.getElementById('wpbody'));
 chart.draw(data, options);
 }

script.onload = () => {
 console.log('Script loaded successfuly');
 // Load the Visualization API and the corechart package.
 google.charts.load('current', {'packages':['corechart']});

 // Set a callback to run when the Google Visualization API is loaded.
 google.charts.setOnLoadCallback(drawChart);
};

Here are the console errors that arise (in the SK dashboard) as a result:

<img width="705" alt="image" src=" URL

It is an odd error given that `new` is clearly used in the code, but I also suspect this is somewhat totally disconnected to the SK app and somewhat irrelevant, it was merely an observation while testing.


Effectivement chez moi aussi les entités sont toujours là, mais plus dans l'appareil. L'appareil est toujours là mais sans entités.

On dirait que la manière de déclarer l'identifiant de l'appareil n'est plus valide. Il faut que je regarde, pas certain de pouvoir faire ca dans l'immédiat mais merci d'avoir remonté le problème.

---

Il s'agit d'une erreur différente d'une mauvaise ligne lue sur le lien TIC qui peut être "normale" et non liée à l'intégration en elle même. Un exemple sur URL (1ère erreur).


Hello, je confirme je viens de voir le même souci exactement immediatement après maj core


I've update the issue with estimate of 3, given that the change itself is minimal, as would be the QAB.


La première erreur dans mes logs lié à l'appareil invalide date du 25 Août. On dirait que le problème existait avant la .9 mais est devenu visible que récemment.


Oui j'ai deja notice ce pb dans la version 2023.8.3 mais c'était revenu en faisant un refresh
jai d'ailleur essayé un downgrade de HA en cette version et j'ai toujours le pb.


Thank you @techanvil , I've updated to state that no additional tests are required, as IMO they do not seem warranted. Handing this over for IBR.


Bon j'ai désormais les certitudes suivantes :

- Depuis la version du mois d'Août, Home Assistant n'aime plus la manière de déclarer l'appareil agrégeant les entités
- Ce n'était alors pas un problème bloquant : l'appareil était bien créé mais vide, sans entités rattachées et les entités continuaient de fonctionner dans leur coin (ce qui explique que je n'ai pas vu le problème plus tôt)
- Depuis la version 9 (de septembre) ce problème de déclaration d'appareil est devenu bloquant : les entités ne sont plus créés par Home Assistant à cause de leur lien invalide vers l'appareil

Par contre, je n'ai pas encore mis le doigt sur qu'est-ce qui fait que la déclaration de l'appareil n'est plus considérée comme valide... Je continue de chercher.


je viens d'ouvrir ma console ESX et je vois ca..
screen

je pense pas que ca t'aide mais sait on jamais


Cela devrait être corrigé avec la v2.0.6.

Pour ceux qui voudraient plus de détails :

- Les appareils sont maintenant catégorisés en 3 types par Home Assistant et chacun de ces types ont un ensemble de propriétés à respecter. C'est à dire qu'il n'est plus possible de renseigner celles qui nous arrangent et d'en mélanger certaines.
- La déclaration précédente de l'appareil définissait à la fois un `default_manufacturer` et un `manufacturer` ainsi qu'un `default_model` et un `model`. Les defaults étant des constantes au cas où l'ADCO dont le vrai constructeur et modèle sont dérivés une fois la ligne lue sur le lien série (voir entité "Adresse du compteur").
- Mélanger les 2 n'est plus permis et la correction a été de définir les `manufacturer`, `model` et `name` (afin de correspondre à la définition de type `Primary`) et de retirer les `default_manufacturer`, `default_model` et `default_name` qui ne sont pas accepté en type `Primary` mais seulement `Secondary`.

Merci d'avoir porté le problème à mon attention et pour votre patience.

En attente de vos retours pour fermer (ou non) cette issue !


cela semble bon de mon coté ! Merci encore Hekmon !
je pense me creer une instance HA differente specialement pour l'energie qui ne serait pas mise a jour, pour justement eviter cela... qu'en penses tu ?


Bonsoir,
Même problème en faisant la mise à jour ce matin.

Plusieurs traces dans les logs :

`Détails du journal (ERREUR)
Logger: homeassistant.components.binary_sensor
Source: helpers/entity_platform.py:621
Integration: Capteur binaire (documentation, issues)
First occurred: 21:01:06 (1 occurrences)
Last logged: 21:01:06

linkytic: Not adding entity with invalid device info: Invalid device info {'default_manufacturer': 'ENEDIS', 'default_model': 'Compteur communiquant Linky', 'default_name': 'Linky', 'identifiers': {('linkytic', '91352f6da5a194c179aae1534d533446')}, 'manufacturer': 'SAGEM / SAGEMCOM', 'model': None} for 'linkytic' config entry: device info needs to either describe a device, link to existing device or provide extra information.`

`Détails du journal (ERREUR)
Logger: root
Source: helpers/entity.py:876
First occurred: 21:01:06 (1 occurrences)
Last logged: 21:01:06

Uncaught thread exception
Traceback (most recent call last):
 File "/usr/local/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
 self.run()
 File "/config/custom_components/linkytic/serial_reader.py", line 144, in run
 notif_callback(forced_update)
 File "/config/custom_components/linkytic/sensor.py", line 807, in update_notification
 self.schedule_update_ha_state(force_refresh=True)
 File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 876, in schedule_update_ha_state
 self.hass.create_task(
 ^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'create_task'`


Que cela représente plus de travail de maintenance pour vous @ToyNBoys :D
Après si la fiabilité et la disponibilité des informations liées à l'énergie est importante voir critique, cela peut s'entendre j'imagine !

Mais mon avis est certainement biaisé car si quelque chose se casse... je n'ai qu'à le réparer sans forcément dépendre de quelqu'un d'autre. C'est un plus ;)

---

@wkup vous semblez utiliser la version 2.0.5, avez-vous essayé la version 2.0.6 mis en ligne il y a quelques minutes et indiqué 2 messages plus haut ?


Merci pour votre avis ! Je vais ptet juste faire un snapshot avant de faire une Maj HA et voila...
Oui cest important pour suivre ma conso et production et si vous etes en vacances ca peux etre chiant, nayant pas vos compétences dans ce domaine...
Merci encore en tout cas encore beau boulot !


Adding `tailscale0` to `networking.networkmanager.unmanaged` on my system that's currently experiencing this issue did not resolve the problem.


@hekmon La 2.06 marche pour moi, merci pour la rapidité de la mise en place d'une solution


@kickbk @marvinklein I'm afraid for not responding to this request for a long time.

Our React Native project uses native code, so we didn't consider Expo. But we noticed the official document that contained this sentence has been updated. So we are investigating this matter again, taking into account the hints we received from everyone.

We would like to thank everyone for their cooperation, and please wait a little longer to find out whether Expo will be possible or not, and if so, how we can respond.


Bonjour,
Les données redescendent bien dorénavant sur les entités. Merci @hekmon pour cette réactivité et ce travail correctif de qualité.
Une remarque toutefois. La carte "Energie" de HA ne s'alimente pas de mon côté. Avez-vous constaté la même chose de votre côté ?
Merci


Salut, c'est ok de mon coté, regarde dans la "configuration de l'energie" voir si ton entité a pas sautée


Hi everyone, apologies for such a long delay replying to this issue. I've just put an update on the issue tagged above, which I hope is helpful.

 URL

I don't think there is a bug here, but definitely a UX improvement we can make. The ECR console shows all content - images, artifacts, indexes, etc. And we show it whether it's tagged or untagged content. So in this case, a multiplatform image with two supported ISAs shows up as three things in the view: one index and two images. Whether the underlying images are tagged or not is up to you - using BuildKit image are by default untagged.

All this said, we would like to make this a nicer and more obvious experience. We are considering making a change which would nest the related images under the index in the view, so you would by default see the tagged index, and then click to expand and see the referred images. We hope this will clarify things and make it easier to reason about.

I'm going to close this one as a duplicate of #1596 since this isn't a bug related to PTC, but an enhancement for a better console view. Thanks!


Vu que le problème semble corrigé, je clos cette issue. Mais vous pouvez bien entendu continuer à discuter dessus si nécessaire.


I updated everything, but the problem is still there, at least for me.

Maybe there is something wrong with my specific configuration, but I still have this issue with nuxt `3.7.1`. unhead `1.6.2` and nuxt-seo-kit `1.3.13`


Hey @zutigrm, this looks good and I've merged the PR. I've also added a couple of additional points to the QAB myself, in order to spare a round trip and move this along to the QA column.


Hi,

Thank you very much for developing this awesome software.

While we're on the subject of on-screen keyboard and when and how to open it, I just wanted to share my experience here:
- when I'm using AVNC on my phone, for quick sessions, then, the two-finger-tap to open keyboard works well, although I do need to tap and tap and tap to get it right (maybe this action could be backed up by a hardware key, volume-up or volume-down or something)
- when I'm using AVNC on my tablet, which has a mouse attached to it, for longer sessions, then, I always need android keyboard + virtual keyboard open, so I find myself two-finger-tap-tapping all the time and then I realized that it would be super useful if we could have a global option "auto open keyboard on session start"

So I found this thread and figured, best to join in here.

Thanks.

AVNC rocks!


I was just thinking about the same problem.
For safety reasons, I would like to treat CS4014 as an error, but it is difficult to correct all the parts that use DOTween.
Is it possible to provide a define symbol for disable the `GetAwaiter` extension method?


I believe this ticket is in review:
- Hazard SMEs and Champions on Wednesday, Sept 13
- Forecaster feedback

Once we get feedback, we can then finalize our definition for the MVP Hazard flow.


### QA Update: ✅

**Verified:**

- Installed GTranslate chrome extension and WordPress plugin verified the extension works.
- Visited a page on frontend, and the gtranslate extension is translating page.
- Tested gtranslate plugin, you can add shortcode [gtranslate] into any page, and the gtranslate widget shows and translation works.
- Tested with the Google Translate extension as well as GTranslate.
- No console or front end error messages.
- Completed a regression test on the behaviour fixed in URL

 Screenshots

image
image
image
image
image


@facelessuser apologies if I missed it but I couldn't find any further references to this. Was this ever brought out of beta? I tried searching for how to enable this feature but couldn't find anything. If the answer is custom CSS that is fine, just wanted to check. Thank you!


Thank you! Looking forward to seeing it as I have some lengthy code blocks which this feature would be extremely helpful for.


This would be great, and help clean up some Caddy Config code I've had to implement in order to abstract and "fix" this.

I've seen many end users struggle with this too and make the common mistake of using the wrong header.


Using this custom extension: URL to wrap a single code block, paired with the following CSS should be all that is needed.

 Minimum Required CSS

css
.md-typeset .collapse-code{
 position:relative;
 margin-top:1em;
 margin-bottom:1em
}
.md-typeset .collapse-code pre,
.md-typeset .collapse-code .highlighttable {
 margin-top:0;
 margin-bottom:0
}
.md-typeset .collapse-code input{
 display:none
}
.md-typeset .collapse-code input~.code-footer{
 width:100%;
 margin:0;
 padding:.25em .5em .25em 0
}
.md-typeset .collapse-code input~.code-footer label{
 position:relative;
 margin:.05em;
 padding:.15em .8em;
 color:var(--md-primary-bg-color);
 font-size:90%;
 background-color:var(--md-primary-fg-color);
 -webkit-mask-repeat:no-repeat;
 mask-repeat:no-repeat;
 -webkit-mask-size:contain;
 mask-size:contain;
 border-radius:.1rem;
 cursor:pointer;
 content:""
}
.md-typeset .collapse-code input~.code-footer label:hover{
 background-color:var(--md-accent-fg-color)
}
.md-typeset .collapse-code input~.code-footer label::before{
 position:absolute;
 top:.15em;
 left:.15em;
 display:block;
 box-sizing:border-box;
 width:1.25em;
 height:1.25em;
 background-color:var(--md-primary-bg-color);
 background-size:1.25em;content:""
}
.md-typeset .collapse-code input~.code-footer label.expand{
 display:none
}
.md-typeset .collapse-code input~.code-footer label.expand::before{
 -webkit-mask-image:url('data:image/svg+xml;charset=utf-8, ');
 mask-image:url('data:image/svg+xml;charset=utf-8, ')
}
.md-typeset .collapse-code input~.code-footer label.collapse::before{
 -webkit-mask-image:url('data:image/svg+xml;charset=utf-8, ');
 mask-image:url('data:image/svg+xml;charset=utf-8, ')
}
.md-typeset .collapse-code input:checked~.code-footer label.expand{
 display:inline
}
.md-typeset .collapse-code input:checked~.code-footer label.collapse{
 display:none
}
.md-typeset .collapse-code input:checked+div.highlight code,
.md-typeset .collapse-code input:checked+div.highlight .linenodiv{
 max-height:9.375em;
 overflow:hidden
}
.md-typeset .collapse-code input:checked~.code-footer{
 position:absolute;
 bottom:0;
 left:0;
 padding:2em .5em .5em .8rem;
 background-image:linear-gradient(to bottom,transparent,var(--md-default-bg-color) 80% 100%)
}

.md-typeset .tabbed-block>.collapse-code:first-child,
.md-typeset .tabbed-block>.collapse-code:first-child {
 margin: 0;
}

@media screen and (max-width:44.9375em){
 .md-typeset>.collapse-code{
 margin-right:-.8rem;
 margin-left:-.8rem
 }
 .md-typeset>.collapse-code label.collapse{
 left:.8rem
 }
}

<img width="878" alt="Screenshot 2023-09-13 at 11 56 52 AM" src=" URL

If you were to wrap anything other than code blocks or you were to wrap more than a singular code block, it is likely you would get odd styling. This is styled to mimic how Material handles singular code blocks with the added interface to expand them.

For Material to integrate this, I would need to officially release the custom plugin. And to do that, I'd like to get feedback from @squidfunk first. Once in the wild, it is unlikely I would make any large changes to it.

Currently, I just place the custom plugin in my projects `tools` folder and configure it like so:

 URL


Duplicate of #452 .

Unfortunately it seems difficult to support anything officially.
There is an option to use `#pragma warning disable CS4014` . And if you want to convert to UniTask you can use `.Forget()`.


I'm increasing the priority of this issue/feature to 'upcoming' since there is a support case waiting for it.
Still, it is highly unlikely to be able to work on this before 8.4. However, we will update the issue once we plan to work on it.


Just for the record: in #7053 we added ability to place namespace declaration in the same line as `<?php` or to enforce it in consequent lines. Probably we need similar flexibility for `declare()` 🙂.


Hi @SquupS . We do show metrics if the metrics-server is installed in the cluster which does show the current utilization. Can you check if this is what you mean?
We're also working on time based charts, powered by Prometheus.


Yeah, not impossible, but breaking changes with significant impact.
Apparently, when this library was created, the compiler did not warn about the extension methods. So at the time, the API seemed reasonable. However, making a major change to this is a big deal.

I wonder if this is a method provided by DOTWeen. This uses System.Threading.Task; UniTask provides a more optimized implementation than Task.

`SendWebRequest()` has exactly the same problem as this issue. It returns Unity's AsyncOperation, which Unity is not designed to await, but UniTask provides an extension that allows it to await.
If an object representing an asynchronous operation has been created and is running, being able to await it as is is certainly easier to use. I think the problem is that tween is used in a way that does not wait for completion. Your suggestion is one way to do it, but I think it has a lot of impact and is something to consider.


Have you had a chance to get the way how to extract some values from original request body?


That should be in its own issue but I'd be against it because:

- it makes the url brittle (a schema is an implementation detail and a rename would break the url)
- would make impossible to do resource embedding across different schemas (if we ever want to)
- will make custom urls harder to implement later on ( URL


Hmm, yeah that makes sense. I wonder how many people use this package with DOTween enabled? I didn't even realize it could be enabled and I've been using this for awhile. Sometimes breaking changes for the betterment of the package is necessary... sometimes I wish Unity would just break some things to make their APIs better, like the fact that actions (like OnClick) don't return the sender as the first parameter (which is what Microsoft recommends for events). But I could see an argument for not breaking it... but honestly my preference would be to break it with a major version update.

Yes, this is a function that DOTween provides that can be directed awaited. I usually call `AsUniTask()` on it, not really sure if that's needed it makes it more optimized or not, so it looks something like `await aCanvasGroup.DOFade(1, 0.75f).AsyncWaitForCompletion().AsUniTask();`. Right now, since I don't have the DOTween part enabled, if I want to add a cancellation token to it, I then chain `.AttachExternalCancellation(token);` to it, and in the `catch` part I kill the tween manually (since the cancellation doesn't cancel it itself, I'm assuming because it's an "external" cancellation). If I enable DOTween support, I can do just the regular `WithCancellation(token)` (I think) and it will kill the tween without me having to do it.

Hmmm, I think Unity's AsyncOperations are allowed to be awaited. I've done `await www.SendWebRequest()` even without UniTask installed and it works as expected. With UniTask installed, I don't know if it's better to leave it like that or do `.ToUnitTask()` on it and await that. If I need to add a cancellation token to it, I do `await await www.SendWebRequest().WithCancellation(token);`

But in general, I would still support just breaking it and letting people know it's going to change/break. As an alternative, I wonder if a fork could be created that has these breaking changes in it? I don't know if there's another solution. Maybe a different scripting define? So you have two versions of the DOTween extensions, one that is the original and one that changes the way it works and then the scripting define can be like UNITASK_DOTWEEN_SUPPORT_ALT or something. So people can choose to stick with what they are using or use the new one.


It doesn't seem like a fix has been released for Mac yet. I'm still hitting this issue after running `brew upgrade` since it's still using python 3.11.5. I did confirm the workaround provided by @carbocation works correctly.


Is there the ability to translate Memory to `Mi` as opposed to the raw value?


Can we unblock the `lib` section in `cargo script`? Maybe with some limitations.

My main use case for this - is a scripting system for game engine. Currently using rust with wasm target for use cases like this is not very comfortable. You need to create a separate crate for every game entity (player crate, enemy crate, etc.) and compile to wasm `cdylib` to use it with `wasmtime` (or any other runtime).

Just for example, if you select `lua` for scripting purposes, only what you need is to create a .lua file.

Single file library with dependency will greatly improve the user experience for scripting use cases.

Maybe this use case is out of scope for `cargo-script`?


Correct, the fix version will be 3.11.6 which doesn't exist yet.


Lib support will be interesting however a lot of people have their own pet feature they want for this (lib, workspace support, doctest support, example support, etc). We decided it was important to narrow our focus on an MVP so we can get this through faster, particularly to keep to a minimum the number of decisions we have to make at once as this is already a very large (by decision count) feature and a good number involve a high amount of discussion.


We made progress on syntax for embedding manifests. See the T-lang thread for more details.


Run this as a startup script:

#!/bin/sh
sleep 10 &
killall xembedsniproxy

Happily running polybar under KDE with the systray


As was discussed in the mentioned Zulip thread, we should leave the door open for embedding files other than `Cargo.toml`. By "leave the door open", I mean that we should leave ourselves the *option* to support this later in a consistent way.

It's important to leave this door open because we'll likely learn things after we stabilize this. We may learn, e.g., that the ability to inline the `build.rs` or `.cargo/config.toml` file is critical to some important use-cases that we had not sufficiently considered. If we close this door, then fixing it later becomes more difficult and may result in a worse or less consistent end result.

Concretely, I propose that we include the name of the file with each frontmatter section. Using the Markdown-like syntax that has been proposed, this might look like this:

`rust
#!/usr/bin/env cargo

cargo file="Cargo.toml"
[dependencies]
foo = "1.2.3"

fn main() {}

`

Even aside from its purpose in leaving the door open for future evolution, this seems net-better today in terms of clarity.

---

In the thread, it was proposed that we could spell this as follows:

`rust
#!/usr/bin/env cargo

Cargo.toml
[dependencies]
foo = "1.2.3"

fn main() {}

`

This would be slightly worse in terms of supporting possible future evolution. For one thing, it's conceivable that other tools may want to use frontmatter sections (e.g. `rustup` or third-party tools), so there should be some way to unambiguously distinguish the tool for which the frontmatter section is intended.

Secondly, it's conceivable that someday `cargo` could want to use such a section to accept data other than a source or config file. E.g., it could use this to accept arguments to `cargo` (something that was earlier discussed on this thread) or arguments to be passed to `rustc`. E.g.:

`rust
#!/usr/bin/env cargo

cargo rustc-arguments
-C target-cpu=native

cargo file="Cargo.toml"
[dependencies]
foo = "1.2.3"

fn main() {}

`

----

Again, I want to reiterate, I'm not proposing that any of these features necessarily be included in the RFC or in the initial stabilization. I'm proposing only that we choose a syntax that's expressive and flexible enough to allow us the *option* of adding these later in a consistent and graceful way.


@annezazu Can you please add this issue to the Polish board ? Cheers!


If you use the `remote` authorizer the full request body is sent to this service so you can use the request body for authZ. We built a small service that handle authZ so it also handles this part.


@wolfgangwalther I've opened a new issue for the schema path idea: URL

I guess we can have both? I don't see why one would exclude the other. This issue is mostly about improving the current header way.


Separate from that is the question as to the infostring that cargo should be using.

We need to keep in mind our motivating use cases and that a solution does not run counter to that. Requiring `cargo file="Cargo.toml"` feels a lot more bloated and more places to get things wrong. I give that not to shutdown the conversation but as an example of the constraints we have to work in.

So far, the cargo team has been most interested in leaving the door open for `Cargo.lock`, so I will focus on that case so we don't get side tracked with other potential features that we may or may not want to close the door on as that is a separate conversation.

The main problem with using `Cargo.lock` with frontmatter syntax is it bloats the "header" of the source; people have generally wanted this boilerplate at the bottom.

I see a couple different ways of leaving the door open with the code fence frontmatter

### Info strings

File names

`md

Cargo.toml

`

Attribute, defaulted for `Cargo.toml`

`md

cargo,file=Cargo.toml

cargo

`

Generally infostrings describe a format using a name. From that lens, I dislike both approaches.

The question is whether the initial RFC / implementation should use `cargo` or `Cargo.toml`. Anything past that can be handled in future change proposals or RFCs.

### Syntax

Distinct blocks, maybe with newlines

`md

Cargo.toml

Cargo.lock

`

Continuous blocks

`md

Cargo.toml

Cargo.lock

`

Distinct blocks is more like the source inspiration, markdown, though has more noise, places to get things wrong, and syntax questions (newlines).

Both can be added at a later point and don't need to be in the initial RFC / implementation.


cargo script (#12207) is defaulting the version to `0.0.0` for scripts. To close the gap between a cargo script and `Cargo.toml`, I think it'd be worthwhile to implement this issue. My main concern is with the implications through the rest of cargo, mostly pkgid. For `CARGO_PKG_VERSION` and friends, I would just not populate them.


@CodyCBakerPhD @h-mayorquin @weiglszonja @alessandratrapani Please let me know what you all think!


@pauladkisson Thanks for writing this all up, I'll look deeper and leave more comments over next couple days

Not sure which is better, but we should be consistent.

Strongly against having it in the `get_video` call because it leads to the 4D ambiguity; much clearer to have separate objects for each channel if you want to do anything with them side-by-side, which makes it a field specified at `__init__`

So totally on board with that solution

Yes and no - their code will have to be changed, but it was also code that was never tested or used perhaps outside of the `.sbx` case? Which we've also not seen used in quite a while

👍

Yeah, been talking with @h-mayorquin about this lately. It's purposely ambiguous to also allow any other type of future formatting distinction we might need to add while remainig universal across the API

It's also flatter and simpler, though what it really does is shift the complexity of structure to the string itself, but as long as we have a convenient fetcher `get_stream_names` that is less complicated than breaking the approach into separate calls per plane/channel option.

Multiple optic channels found? It shows up as a series of structured strings. Multiple planes found? They show up as another part of the string structure. Want to initialize an extractor? Just specify a single string that matches one of the selections.

Strongly against the ID/index route. Neo supports both at the same time and the ID is the annoying one, the bane of many a stream index issue. Strongly recommend using a human-readable identifier. Less strongly against splitting `stream_name` into `channel_name` + `plane_name` if others think that is worth it compared to my 'single argument is simpler' point above


I agree with @pauladkisson that we should break streams. As a note, Streams are not about different types of preprocessing. It is basically stuff that can be processed together in the context of spikeitnerface and raw.io in neo (same sampling_rate, start and duration). The concept is not documented but you can find somedetails here.

How to break depth, channel and whatever else might come?
* I think that depth (moving across planes) is a natural category. Space is there and is not moving anywhere. This should be a thing on its own and be addressed as an index/number. Moreover, this is dimension that the `PhotonSeries` in pynwb accepts and other related modalities take for granted (e.g. brain imaging). I think is a solid well defined concept so it gets a specification.
* Channel is probably better addressed with a string. Sometimes is going to be a number but I also think that the concept of channel is less defined in ophys. In the current conversion that me and @alessandratrapani are working, this is used to describe two different filters (and therefore two molecules) but this does feel less stable and way more ad-hoc than space. Therefore, I think it should get a very (the most?) general type.
* Whatever else might come? I feel that the instinct of @CodyCBakerPhD is right in trying to future proof here. We don't know how ophys will change and we might not want to commit ourselves to some specific categories. In that light, creating a common API which is now called streams to reflect this diversity (channel, modality, preprocessing or whatever else) is a good way of building resilient structure that we can move forward as technology changes. With the exception of deph for the reasons mentioned above, I would be fine with having optical channel dumped in streams along anything else that might come in the future specified as keyword argument with type string. This could be stream as we currently have it, could be modality, mode or any other word that we find and agree is better.

As for this:

MultiImagingExtractor was designed to concatenate ImagingExtractors along the frames axis, but here we want to combine multiple IEs along a separate depth axis.

This is not true:
 URL
But I think it was changed here:
 URL

I agree that we are conflating a tool to concatenate data extractors in time with some internal machinery to assemble extractors from channels, planes or sub-extractors in time. We came to need the latter because some formats provide multiple files and we judged (corrrectly?) that composing in this way is easier than ad-hoc parsing. I think it makes sense separting assembling in time, channels and depth.

The analgous in spikeinterface are concatenation and channel agregation.

Can you point out to where does this show up and also add other wonky stuff / difficulties? I feel this point should be more descriptive of existing problems.

I will add something about the third point later.


my comment to work on binary cross entropy has vanished? Is someone already working on it? @hirwa-nshuti


why I am not getting assigned to binary cross entropy? @hirwa-nshuti


Thanks for your suggestion.

Some sort of customization should be possible in the future.

Michele Moramarco
Prusa Research


Thanks for your suggestion.

Some sort of customization should be possible in the future.
Also, this issue partially duplicates URL

Michele Moramarco
Prusa Research


Michele, is it intentional that the light strips dim at 120 seconds even when printing?


Thanks @stolsvik! With your input I at least have a workaround.


@thepaulmacca Can you show a screenshot so I know exactly which part of the UI we're talking about?