Question: how would you renew a token?

Hi all,
I'm just started with JWT and it looks very promising!
I have backend (npm) and frontend (angular2) too. When the user logs in I create a JWT and send it to frontend. I use your angular2-jwt module to store the token in localStorage.
So user uses the webpage without any issues and then suddenly he gets an error telling him his token is expired. This is valid, because, lets say, he logged in 2 hours ago and the JWT is configured to expire after 2 hours. But in the meantime the user used the website so the JWT should have been continuously updated with an expiry time of "last activity + 2 hours".
Am I right? If so, how would you do that?
Thank you!

@papaiatis some questions to understand context:

Login to backend which generates the JWT with 2h expiration. How do you login the user (ajax, full render)?
User plays around the website. What do you use the JWT token for? Does the frontend send it in each request to the backend? Is it only to be stored in the browser and check the time when the token expires?

@ziluvatar

User logs in through ajax, token is sent back with the response and stored in localStorage
Right now, the payload holds the roles of the user, so some of the pages, links, content are hidden when user does not have permission for it. The token is only sent once when the user logs in. (I guess that's the problem). The token expiration is checked each time the user initiates an ajax request back to the server.

Thanks!

The token expiration is checked each time the user initiates an ajax request back to the server.

Who checks that? frontend or backend?
Frontend: You may not need that, just keep in your js code a "timer", it gets restarted/checked on every action (timer > exp - iat (or custom claim saying 2 hours) => force login)
Backend: You would need to renew the token and send it back on each server action (cookie? header?)
renew the token: maybe with something like: https://github.com/auth0/node-jsonwebtoken/pull/172

Who checks that? frontend or backend?
Actually both. In frontend I'm using this module: https://github.com/auth0/angular2-jwt which checks the token on each request. In backend, I check it manually.

Thanks for the tip, I'll take a look at the mentioned issue ASAP.

Sorry for the late reply. So I ended up creating a "renew token" API endpoint which I call when my angular 2 application starts up and then every 5 minutes. The server then returns me back a renewed token which I store in local storage.

Thanks for letting us know your final solution!

@papaiatis
@ziluvatar
Requesting new token from client-side in your case Angularjs will cause swquirty issue.
If your token gets leaked your application may get compromised completely.
And if we provide the functionality to the client to request fresh token it will allow an attacker to use the token for an indefinite time. And this will make the exp value of 2hours in token useless.
From security perspective, the token should be pushed from the server site instead of client-side to
so that if your valid token gets leaked attacker can not use the same token for more than exp time here it is 2 hrs.
I'm not sure how can we do it as it will conflict with the stateless property of JWT.


constexpr variable 'p' must be initialized by a constant expression

I'm trying to build a simple compiler for another language.
I've managed to add rules and AST for declaration statements successfully.
    )
);

The weird thing I found was, for the five rules where I applied MulOperatorAST, DivOperatorAST, ModOperatorAST, AddOperatorAST and SubOperatorAST, when I comment out whichever one of the five rules, the compiler would work fine and generate the ideal code. But when I use these five lines of rules altogether, I would receive an error message like this:
./include/parser.hpp:127:18: error: constexpr variable 'p' must be initialized by a constant expression
constexpr parser p(
                 ^~
./include/ast/../ctpg.hpp:1339:17: note: constexpr evaluation hit maximum step limit; possible infinite loop?
                if (tr_from == uninitialized16)
                ^

I've defined the five operators' AST in the same way. The only difference between them is inside the codegen() function:
class Expression
{
public:
    virtual ~Expression() = default;
    virtual Value *codegen() const
    {   throw std::runtime_error("Not implemented."); }

    virtual Value *initgen(ExpressionPtr init) const
    {   throw std::runtime_error("Not implemented."); }

    virtual Value *initgen(std::string_view spec, ExpressionPtr init) const
    {   throw std::runtime_error("Not implemented."); }

    virtual Type *get_type() const
    {   return Type::getInt32Ty(TheContext); }

    virtual std::string_view get_name() const
    {   throw std::runtime_error("Not implemented."); }

    virtual std::string_view get_spec() const
    {   throw std::runtime_error("Not implemented."); }

    virtual Value *get_AllocaInst() const
    {   throw std::runtime_error("Not implemented."); }
};

class AddOperatorAST
    : public Expression
{
private:
    ExpressionPtr left;
    ExpressionPtr right;
public:
    AddOperatorAST(ExpressionPtr _left, ExpressionPtr _right)
        : left(_left)
        , right(_right)
    {}
    virtual Value *codegen() const
    {
        Value *vl = left->codegen();
        Value *vr = right->codegen();
        Value *add = Builder.CreateFAdd(vl, vr, "add");
        return add;
    }
};

At this point I really don't understand why this problem occurs. Have I passed anything not compatible to the constexpr parser? If possible, do you think I could modify my code to solve it?

PS: I have noticed that any terminal/nonterminal symbols missing in the term/nterm list would also give the same error message, but for that the note message would be:
./include/parser.hpp:127:18: error: constexpr variable 'p' must be initialized by a constant expression
constexpr parser p(
                 ^~
./include/ast/../ctpg.hpp:480:13: note: subexpression not valid in a constant expression
            throw std::runtime_error("string not found");
            ^

sorry for disturbing, I solved this problem by adding -fconstexpr-steps=1000000000 to my compile command.
also many thanks for writing this lib!


Svix does not work with Cloudflare Worker

Bug Report
Version
^1.24.0
Platform
Darwin Bernardos-MacBook-Pro.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64
Description
I'm not able to use Svix with Cloudflare Workers.
You can reproduce it doing the following steps:

Start a cloudflare worker project: https://developers.cloudflare.com/workers/get-started/guide/
Try to do the first step from svix quickstart: https://docs.svix.com/quickstart#creating-a-consumer-application
You'll see the following error: The 'credentials' field on 'RequestInitializerDict' is not implemented

I think the error is related to this issue: https://github.com/cloudflare/workers-sdk/issues/2514

The Fetch API on CF's worker didn't support the credentials field. So the SDK from svix cause the issue by set it to same-origin.
https://github.com/svix/svix-webhooks/blob/e5dbc7556f699e5f62092d2f57e979333f775534/javascript/src/openapi/http/isomorphic-fetch.ts#L40
The fix can be easy like the last comment on that issue:
https://github.com/cloudflare/workers-sdk/issues/2514#issuecomment-2178070014

The Fetch API on CF's worker didn't support the credentials field. So the SDK from svix cause the issue by set it to same-origin.
https://github.com/svix/svix-webhooks/blob/e5dbc7556f699e5f62092d2f57e979333f775534/javascript/src/openapi/http/isomorphic-fetch.ts#L40
The fix can be easy like the last comment on that issue: cloudflare/workers-sdk#2514 (comment)

I don't have access to fetch functions because I'm using svix SDK. Right now I removed svix sdk and add my own fetch functions to access svix api.
I was wondering if it makes sense to add this fix you mentioned inside svix sdk and not on our (svix customer) side. CloudFlare workers are getting more and more famous nowadays and it would increase the developer experience if I could start a CF worker and add svix with no errors.

Yeah, I think it's probably a good idea to do it. Though it's annoying that this needs to be done in the first place.


[OJ] OJ benchmark not refreshed

Related module
Benchmark
What happened
Hi. I modified my code and in local benchmark, it seemed that I had passed all the points in deleteVideo(). No debugs or wrong answers displayed in the log.

In short, I get correct result in local testbench, but not in OJ. I ensure that the uploaded jar is the correct version.
Thanks.
What you expected to happen
OJ grade get updated
How to reproduce
No response
Anything else
No response

please provide the first 8 chars of the submissions you want to compare, if you believe you've submitted the right things
i've downloaded the log of your latest 4 submissions and seems they are identical, since it's unlikely that two jars built from different source code would share a same size

please provide the first 8 chars of the submissions you want to compare, if you believe you've submitted the right things
i've downloaded the log of your latest 4 submissions and seems they are identical, since it's unlikely that two jars built from different source code would share a same size

Task ID
Latest versoin:  [3af17daf]
Earlier version: [73f0ae3d]
If these two submissions are identical, there must be some problems with the submitJar application.
Thank you.

yes, these two submissions have different jar files, you may

download the latest small dataset and run again
add some System.out.print or log.fatal in your service method to print the arguments and return values, then check the oj's benchmark-stdout.log attachment

yes, these two submissions have different jar files, you may

download the latest small dataset and run again
add some System.out.print or log.fatal in your service method to print the arguments and return values, then check the oj's benchmark-stdout.log attachment

Here is what I have done:

Download the latest small dataset and run again.
Result: still get correct feedback, no debug record in the log.
Add some System.out.print in my method (it seems that log.fatal not supported...).
Result: I can see the sout message in local benchmark, but not in the OJ's benchmark-stdout.log. (I am sure I submitted the correct jar)

If I cannot get practical in feedback in local benchmark, I cannot improve my method. Thanks.

that's weird.. @WhatWEat is it possible for you to take some time tracking on it? i'm having an urgent task and hardly have time recently, many thanks

@dequeueing by the way, can you ask your teammate (if there's one) to submit the work (build jar, zip, and upload to oj) and see compare the report and logs with your submission? we may be hard to fix this without more info since no any other has reported this issue

I think one of my problems is that I cannot see the debug info in my terminal though the benchmark is incorrect.

My application.yml:

Another problem is that, in some cases I get all correct result in local benchmark,but oj fails. This makes me feeling hard where to debug.
Thank you.

are you use the professional version of IDEA?

@dequeueing please confirm that the sql file you submitted could properly init the db, we found that some students update their table/function definitions in ide's console, then forget to update the sql file. if the problem still exists, please send your code to me by email for a further inspection

@dequeueing please confirm that the sql file you submitted could properly init the db, we found that some students update their table/function definitions in ide's console, then forget to update the sql file. if the problem still exists, please send your code to me by email for a further inspection

Thank you very much.


read: change from/to for optimized reduce -every

If we're doing an optimized reduce -every live program, we should only make one query per
batch. We start by going from from to the end of the first batch, then each
subsequent query is made over a full batch.
Will fix https://github.com/juttle/juttle-elastic-adapter/issues/108
@demmer @VladVega

@davidvgalbraith would there need to be additional code in the adapters for this to be used?

Updated, with the latest change it'll magically work without changes to the adapters.

Added such a check.

looks good. +1


.idea (personal) project files not all ignored

I noticed not all of the .idea project file directory is ignored. Is there a reason for this?
Some of the not-ignored files contain personal or machine-specific settings.

Hi @HoldYourWaffle, the include/exclude comes from here: https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
so that it includes common files but excludes sensitive/generated files. What are you seeing that covers personal settings?


Add callout that some contexts aren't available for use in the jobs.<job_id>.if conditional

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif
What part(s) of the article would you like to see updated?
Please add a callout that certain contexts are not available for use in the jobs.<job_id>.if conditional.  If you attempt to use them, you get an Unrecognized named-value: '<context>'. error.
Adding links to issues where people on the internet have learned about this the hard way:

https://github.com/actions/runner/issues/1985
https://github.com/actions/runner/issues/1189

Additional information
No response

@MarkIannucci Thanks for opening an issue and linking it to your PR! ✨

This is a necro-post, but I wanted to point out, in case anyone sees this later, that I don't think that PR #22437 addresses issue #1189 at all -- it is now completely vague as to whether or not one can refer to variables in env from the job context.

@cognitiaclaeves 👋 - Would you mind opening your concern as a new issue? That way I can triage it and make sure someone gets eyes on it for review 👀


streaming command

just doesnt work

? When you use the command, you wont see the streaming status, only other people will. The person that is using the selfbot can't see his own game change. Just use the command and after you get :+1: just ask other people if they see you streaming. If that doesn't work then I will look into it.


Remove unused serde deps

Fixes https://github.com/Granola-Team/mina-indexer/issues/640

Looks like multiple concerns got into same PR?


apis: make PCIEID of DeviceTopology as string type

Ⅰ. Describe what this PR does
Currently, DeviceInfo in Device CRD is insufficient for AI/Data Computing Scenarios. Some device such as NICs support SR-IOV virtualization. The DeviceInfo lack of such information. In addition, every pcie device has its own topology such as cpu socket, NUNANode, bdf and the pcie switch to which the device is connected.
Ⅱ. Does this pull request fix one issue?
NONE
Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[X] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

/approve


[SwiftLanguageRuntime] Remove code accidentally copypasted.

Presumably from the C++ backend.

@swift-ci please test


Dataset Structure

Hi~ Thx for your excellent work!
I now have some problems when running the test code.It may be caused by the wrong file structure.
In fact, I'm not familiar with the structure of the two data sets of scannet and megadepth. I don't know where to download the megadepth_test_1500.txt file
https://github.com/jamycheung/MatchFormer/blob/5f40637d2dff0035e19624caf9258df5bd6ae781/config/data/megadepth_test_1500.py#L8
Could you give me some help on downloading and  organizing the dataset structure? Or modify the readme file to make the data format configuration easier?
Looking forward to your reply, and wish you have a nice day!

You can find it here.
https://drive.google.com/drive/folders/1SrIn9WJ1IuG08yh2nEvIsLftXHLrrIwh


from django.views import View in django1.9 do not inport

On mine eviroment (dj 1.9.13) I had to change row 10 in view.py to import View from views.generic.
I find the change from django.views.generic.base.View to from django.views import View in 1.10 release notes.
Am I missing something?

Django changed their rule for importing View from 1.10.
So we have https://github.com/summernote/django-summernote/blob/master/django_summernote/views.py#L8-L11 to determine the way how to import it.
If you're still using under Django 1.10, it should use from django.views.generic import View.

right!
So, maybe line 8 of django-summernote/django_summernote/views.py have to be changed from:
if django.VERSION <= (1, 9):     from django.views.generic import View else:     from django.views import View
to
if django.VERSION < (1, 9):     from django.views.generic import View else:     from django.views import View


Propose implicit named arguments for formatting macros

Rendered
Proposes the ability to pass implicit named arguments to formatting macros, for example:
let person = "Charlie";
print!("Hello, {person}!");    // implicit named argument `person`

A follow up to internals discussion https://internals.rust-lang.org/t/println-use-named-arguments-from-scope/10633 and WIP PR https://github.com/rust-lang/rust/pull/65338

An alternative syntax is to clearly distinguish the interpolated variable from named arguments,
println!("Hello, {(person)}!");
//                ^      ^

and it allows all expressions can be naturally used
format_args!("Hello {(get_person())}")
//                   ^~~~~~~~~~~~~^

println!(r#"{("Hello"):~^33}\n{(self.person):~^33}"#);

println!("Hello, {(if self.foo { &self.person } else { &self.other_person })}");

println!(
    "variable-person = {(person1)}, named-person = {person2}, positional-person = {}",
    person3,
    person2=person2,
);

and it allows all expressions can be naturally used

First: this is backwards compatible to add on top of the "single Ident special case". Most languages with string interpolation have a special case for single Ident, so we wouldn't be out of line to make that easier. It's also by far the most common case.
Second: allowing arbitrary expressions opens a whole separate can of worms around nesting. Just as a few edge case examples: "{("a")}", "{(\"a\")}", r#"{(")}")}"#. You can make rules for how these resolve (it'd have to be "standard string token first, then work on the content of the string literal"), but this adds a huge number of edge cases that just plain don't exist for the ""{name}" is a shortcut for "{name}", name=name" simple case.
So we definitely should stick to the simple, fairly obvious case that eliminates that stutter, and worry about generalizing it to more expressions later if desired.

@CAD97

Most languages with string interpolation have a special case for single Ident

Half of the languages with string interpolation have special case for single ident.
Firstly, many of them do support interpolating arbitrary expressions, without any special case for single idents:

Python's f-string f"{expr}"
C#/VB's interpolated strings $"{expr}"
JavaScript/TypeScript's template literals `${expr}`
Swift's string interpolation "\(expr)"

Furthermore, when the string interpolation syntax is special-cased for single idents, it is often because there is no closing sigil, which is not the case for Rust

Kotlin, Groovy, PHP: "$ident ${expr}"
Ruby: "#@xxx #@@yyy #$zzz #{expr}" (note: local variables (no sigils) won't work, must use "#{ident}")
Scala: s"$ident ${expr}"

Finally, string interpolation is a feature built into the language itself, which often live independently from the "format" facility, e.g. in Python you write f"{ident}" or "{}".format(ident), but "{ident}".format() is meaningless. This RFC fuses string formatting and interpolation, so the experiences from other languages are not reliable, e.g. they can't express format!("{a} {b}", b=123).
And hence I disagree with this criticism:

Second: allowing arbitrary expressions opens a whole separate can of worms around nesting. Just as a few edge case examples: "{("a")}", "{(\"a\")}", r#"{(")}")}"#. You can make rules for how these resolve (it'd have to be "standard string token first, then work on the content of the string literal"), but this adds a huge number of edge cases that just plain don't exist for the ""{name}" is a shortcut for "{name}", name=name" simple case.

"{("a")}" is simply syntax error. Remember we're talking about a macro format!("...") here, the format string literal is not special in the Rust tokenizer/parser, it is not an interpolated string. To the proc macro format_args!(), the format strings "{(\")}\")}" and r#"{(")}")}"# are equivalent. The format string parser could,

If we see {,

If we see {, unescape as {
If we see an integer, it's a positional argument
If we see an identifier, it's a named argument
If we see : or }, it's an (implicit) positional argument
If we see (, step back one character then parse a Rust token tree
Otherwise, emit an error

I don't see "huge number of edge cases" syntactically. IMO it has less edge cases than the current RFC because when you see an ident, you don't need to determine whether {ident} is a named argument or interpolated variable!
And to clarify, introducing the "stutter" is the primary purpose of my comment above even if we reject interpolating arbitrary expressions. It's to ensure {ident} is always a named argument, which leads to

this is backwards compatible to add on top of the "single Ident special case".

Indeed we accepted this RFC as-is, {ident:?} can also be forward extended to {(expr):?}. But you'll need to consider what to do with {expr:?} — either reject all non-ident expressions (thus {self.prop:?} is invalid), or accept some expressions (which leads to "why is my particular expression not accepted?" and true edge cases involving numbers and : and {). So I'd avoid even allowing that in the first place.

It's also by far the most common case.

Yes. But stuff like self.stuff or path.display() is also quite common. Grepping format!, panic! and (e)print(ln)! (including docs) from https://github.com/BurntSushi/ripgrep we get

Type
Count

Single ident (e.g. format!("error: {}", err))
147

Properties (e.g. format!("value {}", self.x.y.z)
22

Other expressions (e.g. format!("{}", xyz[0].replace("\n", "\n\n")))
61

Expression with return branch (e.g. println!("{}", foo()?);)
2

Expression involving macros (e.g. format!("{} {}", $e, crate_version!()))
3

So non-single-ident covers 40% of all usages, which I won't brush them off simply as can-of-worms opener.
Also, when these expressions are interpolated, they are quite readable unlike the RFC's constructed example.
https://github.com/BurntSushi/ripgrep/blob/8892bf648cfec111e6e7ddd9f30e932b0371db68/tests/util.rs#L403-L414
// Current
            panic!("\n\n==========\n\
                    command failed but expected success!\
                    {}\
                    \n\ncommand: {:?}\
                    \ncwd: {}\
                    \n\nstatus: {}\
                    \n\nstdout: {}\
                    \n\nstderr: {}\
                    \n\n==========\n",
                   suggest, self.cmd, self.dir.dir.display(), o.status,
                   String::from_utf8_lossy(&o.stdout),
                   String::from_utf8_lossy(&o.stderr));

// Interpolated
            panic!("\n\n==========\n\
                    command failed but expected success!\
                    {(suggest)}\
                    \n\ncommand: {(self.cmd):?}\
                    \ncwd: {(self.dir.dir.display())}\
                    \n\nstatus: {(o.status)}\
                    \n\nstdout: {(String::from_utf8_lossy(&o.stdout))}\
                    \n\nstderr: {(String::from_utf8_lossy(&o.stdout))}\
                    \n\n==========\n");

https://github.com/BurntSushi/ripgrep/blob/8892bf648cfec111e6e7ddd9f30e932b0371db68/ignore/src/lib.rs#L287-L299
// Current
                write!(f, "{}", msgs.join("\n"))
...
                write!(f, "File system loop found: \
                           {} points to an ancestor {}",
                          child.display(), ancestor.display())

// Interpolated
                write!(f, r#"{(msgs.join("\n"))}"#)
...
                write!(f, "File system loop found: \
                           {(child.display())} points to an ancestor {(ancestor.display())}")

https://github.com/BurntSushi/ripgrep/blob/8892bf648cfec111e6e7ddd9f30e932b0371db68/src/search.rs#L244-L264
// Current
        write!(
            self.get_mut(),
            "
{matches} matches
{lines} matched lines
{searches_with_match} files contained matches
{searches} files searched
{bytes_printed} bytes printed
{bytes_searched} bytes searched
{search_time:0.6} seconds spent searching
{process_time:0.6} seconds
",
            matches = stats.matches(),
            lines = stats.matched_lines(),
            searches_with_match = stats.searches_with_match(),
            searches = stats.searches(),
            bytes_printed = stats.bytes_printed(),
            bytes_searched = stats.bytes_searched(),
            search_time = fractional_seconds(stats.elapsed()),
            process_time = fractional_seconds(total_duration)
        )

// Interpolated
        write!(
            self.get_mut(),
            "
{(stats.matches())} matches
{(stats.matched_lines())} matched lines
{(stats.searches_with_match())} files contained matches
{(stats.searches())} files searched
{(stats.bytes_printed())} bytes printed
{(stats.bytes_searched())} bytes searched
{(fractional_seconds(stats.elapsed())):0.6} seconds spent searching
{(fractional_seconds(total_duration)):0.6} seconds
")

As a use-case, there is a PoC of this feature already available in stable with ::fstrings, featuring deliberately limited interpolation (c.f., https://github.com/danielhenrymantilla/fstrings-rs/pull/1#issuecomment-541133376), or for the extreme opposite, ::ifmt with "arbitrary" formatting.
In the linked PR, we are considering extending fstrings interpolation to field access, but nothing more (e.g., no method calls a priori).

Could you also state whether format!("{x}, {y}", y = 42) would be accepted or rejected? (it would avoid having let declarations used only for one "fstring" interpolation)

I would expect it would be accepted: it seems perfectly valid to me that one named parameter can be implicit and the other explicit.

Also, when these expressions are interpolated, they are quite readable unlike the RFC's constructed example.

I think there's value in separating the computing of results and how they are rendered (so that the former can be separated into functions eventually). With the {binding} case, I think a good balance is struck where things don't get too intermingled.
Also, given that 60% of the cases in the data in question were for single-ident cases, it seems to me that {binding} is right to optimize for those cases whereas {{binding}} optimizes for the minority.
The rustc compiler has a lot of diagnostics so it is probably a better data set to dig into if you want more of those.
All in all, I think this RFC finds a well-struck balance.

Would this involve any changes to the language syntax, or can this be implemented entirely in a macro?
I realise that format_args! is not currently implemented as a true macro, but i think it's a good idea to maintain the fiction that it is, or at least could be. format_args! shouldn't do anything a user-written macro can't.

Would this involve any changes to the language syntax, or can this be implemented entirely in a macro?

The fstrings crate implements a PoC of this functionality using proc_macro (and proc_macro_hack, I believe).
Also, the test PR I wrote needed just a tiny adjustment to the internals of format_args! without any changes anywhere else.

I'd love to have this. I find myself writing name=name, another_name=another_name all the time.
I fully support the rationale in this RFC to only support single identifiers, and defer any more complex interpolation. I do think we'll want dotted fields in the future, but I added a comment about one bit of complexity even that level of extended interpolation would produce.

I have a couple of reasons to not support arbitrary expressions without require parenthesis ( "{(expr)}"):

There is ambiguity between an integer expression and number indicating a positional argument
There could potentially be ambiguity, or at least confusing with format arguments, since the colon is used both in rust syntax and as the delimiter before format arguments.

I have a couple of reasons to not support arbitrary expressions without require parenthesis ("{(expr)}"):

Fully agree with your arguments. For anything beyond {ident}, I agree {(expr)} is much better than {expr}.

A new version of ::fstrings has just been released, that supports interpolation of field accesses / dotted.paths (but not after the :, which is currently just left as is).
It can be useful for those wanting to get a feeling of what the ergonomic improvements this RFC and a future one could provide.

Another possible alternative: No special case for identifiers, but allow arbitrary expressions within parenthesis. So, {ident} means, use the keyword argument named ident and {(ident)} means use the variable ident, and {(expr)} works for any expression.

One thing to consider with identifier, or arbitrary expression in string literal, is how it plays with tools. Will operations like "find symbol" and automated refactoring to rename or cargo fix be able to "see through" the macro? What will be the span of the expanded token taken out of a string literal?
Will error message be able to point to the right location within the string?

Will operations like "find symbol" and automated refactoring to rename or cargo fix be able to "see through" the macro?

Once they've been updated to do so, yes. It will complicate integrations, however, as they will have to implement some amount of macro expansion to discover the format_args! macro invocation to know to do the format string parsing.
This is only worse than status quo macro usage (e.g. serde's derive's code-in-strings) because it would be in the standard library rather than in an external crate.

Will error message be able to point to the right location within the string?

This is equivalent to the span question.

What will be the span of the expanded token taken out of a string literal?

As of current, proc macros have to point to the entire string for any tokens extracted from a string. It is possible on nightly, however, to produce subspans that point to a substring of a literal.

Another possible alternative: No special case for identifiers, but allow arbitrary expressions within parenthesis

Yep this is the interpolation alternative described in the RFC

@CAD97

It will complicate integrations, however, as they will have to implement some amount of macro expansion to discover the format_args! macro invocation to know to do the format string parsing.

Such mechanisms already need to understand macros that take format strings enough to know about the named argument syntax they support (name=value) that Rust doesn't otherwise use.
Also, I'd expect most such parsers to contain a list of macros likely to accept format strings.

On a different note: I don't think this needs to be tagged T-lang. This seems entirely within the scope of the libs team to evaluate.
(If we were talking about something like Python's f-strings, that would definitely fall under lang, but this proposal only affects formatting macros, not anything innate to the language.)

On a different note: I don't think this needs to be tagged T-lang. This seems entirely within the scope of the libs team to evaluate.
(If we were talking about something like Python's f-strings, that would definitely fall under lang, but this proposal only affects formatting macros, not anything innate to the language.)

The addition of the language team is entirely intentional as was bringing it up on the language team meeting. The format_args! macro is defined in the compiler (libsyntax_ext), depends on equivalents like the unstable Span::def_site, the diagnostics infra of the compiler, and etc. While it could be theoretically defined as a library (still using unstable stuff), it is not, and so it is not entirely within the scope of the libs team to evaluate.

I think this RFC is great, well-balanced, and well-motivated. While one might consider more expansive changes like {{expr}}, this proposal provides an easy win in the most common case. This subset also seems uncontroversial and doesn't in any way create problems for the extensions. As a compiler engineer, I know that we have a tonne of cases in rustc, especially when it comes to diagnostics, where this RFC would be useful. So with all that said:
@rfcbot merge

Just to reiterate (though I don't hold this view myself), the one dissenting opinion that I've gotten from this thread is along the lines of "if we want {(expr)} or some similar more powerful syntax, then perhaps {ident} should remain unambiguously meaning named argument." This position is stronger when considering the case of format arguments such as {x:.precision$}: if a interpolation syntax allows writing e.g. {x:.(precision)}, then it might be more internally consistent to have it be written {(x):.(precision)}.
@joshtriplett

It will complicate integrations, however, as they will have to implement some amount of macro expansion to discover the format_args! macro invocation to know to do the format string parsing.

Such mechanisms already need to understand macros that take format strings enough to know about the named argument syntax they support (name=value) that Rust doesn't otherwise use.

Not quite: macros already accept arbitrary syntax. A simple IDE could just not attempt any introspection of macros. (Though that would mean that rename-item would either never work inside macro calls or be super brittle as a textual replace within macros.)

(@Centril

While one might consider more expansive changes like {{expr}}

Nit-pick: it is {(expr)} not {{expr}}, the latter already means printing out "{expr}" as {{ and }} are escaping sequences 🙃)

To also note the unresolved questions, and comments I have seen so far in this discussion:

Should implicit named arguments be accepted for formatting parameters? YES
The argument was made that we should accept implicit named arguments everywhere named arguments can be accepted, for consistency. Also, the test PR found that the implementation was simpler if we took this path.

Should we improve the error for invalid expressions in format strings? Future work?
I haven't seen any commentary regarding this as yet. I believe it would be backwards-compatible future work to implement an improved error message if users criticise the existing error as an ergonomic issue. I expect it would most likely affect new users rather than experienced Rustaceans. I haven't attempted to implement this improved error message, though suspect it may complicate parsing somewhat.

@rfcbot concern panic-may-not-work
At a cursory glance of the discussion I haven't seen a mention of this, but we have a longstanding bug that panic!("{}") compiles and works today. This is due to the fact that you can do panic!(arbitrary_expression) and a single string literal is interpreted as an arbitrary expression. This means that the following would not work as expected:
let msg = "foo"
panic!("{msg}");

it would panic with "{msg}" rather than "foo" as a value.
I wanted to bring this up as a concern for merging because it runs a risk of creating an inconsistency with a pretty commonly used macro, panic!

I wanted to bring this up as a concern for merging because it runs a risk of creating an inconsistency with a pretty commonly used macro, panic!

Ouch, I wasn't aware of this. Thanks for raising. If I understand correctly you're saying the bug is panic!("{}") should be a compile-fail, because a positional format argument is missing. Instead, this is currently accepted code and the resulting panic message is simply "{}"?
If I read this correctly, we need to fix panic first before this RFC would be implemented? I completely agree panic!("{msg}") as per your example should behave identically to format!("{msg}") etc.
Is there a blocking reason why this bug with panic hasn't been fixed? I can see that it might break some existing code. If it's desirable, I can volunteer to take that bug on 😄

I'm not really saying there's a bug per se, this has come up before and we've not dealt with it because there hasn't really been motivation to do so. It's a continued papercut, however!
Whether or not it's a bug though is somewhat orthogonal to the point I was making, I mostly wanted to bring up how panic!("{msg}") will not work as expected given this RFC, and that does not seem to have been considered so far in the discussion. I don't really have a preference one way or the other, nor do I know how this would be fixed one way or another, I just wanted to make sure that it was brought up and addressed in the RFC one way or another.

Thanks, understood. In that case my opinion is that panic!("{msg}") should be "fixed" as part of this RFC. Otherwise, we're just making the papercut you refer to even more likely to trip users up.
I'll add it and some deeper thoughts as an "unresolved question" - expect I'll find time to write up later in the week.

Also to be clear, I think this looks like a pretty awesome RFC. I personally think it'd be great to develop a rough idea of how we might solve this problem with panic! and then go ahead and land the RFC and start experimenting with an implementation. Stabilization is the only thing I would block on resolving panic! one way or another.
Put another way, I would like to see at least inklings of an idea about how to solve the panic! issue before I resolve my rfcbot concern, but I don't think it needs a fully-fleshed out solution.

I'm happy with the RFC proposal and excited about having this feature - I also agree with the RFC as written that interpolation of more complex expressions should wait for now, and would quickly approach a limit where it becomes a misfeature.
As it relates to panic, it seems pretty important that panics formatting work like other macros that take format strings. I wonder if we have any information on how many people are relying on the current behavior of panic, and how? Possibly we can modify the behavior of panic in an edition so that this works?

Put another way, I would like to see at least inklings of an idea about how to solve the panic! issue before I resolve my rfcbot concern, but I don't think it needs a fully-fleshed out solution.

The way fstrings, for instance, solves this, is by having a layer of indirection:
panic_f!("Some {stuff}")

expands to:
panic!("{}", format_args!("Some {stuff}", stuff = stuff))

So, if we are the stdlib, we can have a a __panic__internal__! macro doing what the current panic! macro does, and have panic! become what panic_f! in my example does.

With the added optimization that if no interpolation is detected in the string literal, then format_args! interpolation is not used at all.

This would change the current (surprising?) behavior of panic!("{stuff}"), which would remain doable by using double braces: panic!("{{stuff}}").
As a slightly related note, this discussion reminds me of people using panic!(err) rather than panic!("{}", err), and in such a world panic!("{err}") seems like the best option.

People are saying "maybe we shouldn't have a 2021 edition" but this panic! thing sounds exactly like the kind of thing that editions are supposed to handle, at least if we can get a library change gated on the edition.
The "fix" would be to in the new edition, have panic_with! for panicking with an object and panic!(..) always means panic_with!(format!(..)) (or equivalent).

people using panic!(err) rather than panic!("{}", err), and in such a world panic!("{err}") seems like the best option.

panic!(err) is not the same as panic!("{err}"). With the former, the original error can be inspected in a panic hook with PanicInfo::payload(), with the latter you would need some other mechanism (like storing the error in global variable before panicing).
I think there could be minimal breakage if the following pattern was added to the definition of panic! if it treated the single argument as a format string only if it is a string literal. However, afaik, there isn't a way to do that with macros by example. (It would be possible to just match a literal but that would also match literal numbers and characters, but I don't know if those are ever passed to panic! in practice.
Another option is to create two new panic macros, one that takes a single argument to use as the payload for the panic, and another that always performs formatting, and deprecate the existing panic macro.

However, afaik, there isn't a way to do that with macros by example. (It would be possible to just match a literal but that would also match literal numbers and characters, but I don't know if those are ever passed to panic! in practice.

Seems like we could solve this pretty easily by making panic! a built-in.

change the behavior of panic! in a new edition

I'm not sure if this can be allowed by the edition mechanism, since a "2021" crate can use a macro exported from a 2018 crate, and vice-versa. So if the 2018 macro writes panic!($literal) it's not clear which behavior it should use.

adding an unstable :strlit matcher.

We already have :literal.

I'm not sure if this can be allowed by the edition mechanism, since a "2021" crate can use a macro exported from a 2018 crate, and vice-versa. So if the 2018 macro writes panic!($literal) it's not clear which behavior it should use.

If #[macro_export(local_inner_macros)], the local one, if not, then the one in scope. This could be slightly problematic, but given the relative rarity of the panic!(err) form (where err is not a string literal), this wouldn't be too big of an issue in practice. The more interesting case is 202X to 2018 or 2015, where panic!("{name}") would change behavior. But still, it's a standard "what's in scope" problem that macro authors have to be aware of anyway.

adding an unstable :strlit matcher.

We already have :literal.

The idea was to add a new matcher that only takes string literals (unlike :literal which takes any literal, e.g. string, number), so that panic! could "specialize" its single-arg form for string literals.

I like the restriction to simple idents here.  With struct field init shorthand I often just make local variables for everything; I could easily see myself doing the same for formatting.
@rfcbot reviewed

Guess we can use ($lit:literal) => { ... } then and route that to a macro defined in libsyntax_ext which will, if given something other than a string literal expand to the input (identity), and otherwise do analysis on the format string to find {stuff}; if found, format_args! is used, otherwise it expands to the input (identity). Hopefully no one is relying on having the literal output with {stuff} here. We should be able to check that with crater.

Here's a way to handle it with the edition: prelude::v2!
I.e. edition 2018 or earlier imports prelude::v1::*, which includes today's panic!. Editions later than 2018 import prelude::v2::*, which includes a "fixed" panic! and panic_with!.
That's not to say it should be done that way, but it could be handled "simply" with a new prelude.

I haven't read the entire discussion but Ctrl+F hygiene finds nothing, so this is my take on it:
This feature would be fine, except for one fatal flaw: there's no Ident token nested in the string Literal token to allow macro hygiene to operate correctly.

If we had a general syntax for interpolating expressions, e.g. Swift's
"Hello \(capitalize("world"))"

which could desugar into something like this, perhaps:
format_args!("Hello {}", capitalize("world"))

then the macro system would already be aware of this and we could add a special-case for single identifiers without introducing any new issues.
However, that's not the case today - AFAIK, at least, maybe @petrochenkov has some clever ideas.

Hygiene was not discussed given the fstrings PoC that works on stable Rust, thanks to @dtolnay 's [::proc_macro_hack::proc_macro_hack(fake_call_site)]. Perhaps they can provide more information bout how they circumvented this issue.

I haven't read the entire discussion but Ctrl+F hygiene finds nothing, so this is my take on it:
This feature would be fine, except for one fatal flaw: there's no Ident token nested in the string Literal token to allow macro hygiene to operate correctly.

There is an (admittedly short) discussion of hygiene in the RFC: https://github.com/davidhewitt/rfcs/blob/format-args-implicit-identifiers/text/0000-format-args-implicit-identifiers.md#macro-hygiene
Based on my test PR implementation, the hygiene is fine. I was able to create a new Ident which inherited the span from the format string literal. This was consistent with @petrochenkov's comments when reviewing the PR.

So "{foo}" would preserve the right hygiene but concat!("{", stringify!(foo), "}") wouldn't - I suppose that's an acceptable compromise?
The main downside I see then is that it might be possible to bypass hygiene using only builtin macros and no proc-macro, but maybe we can make strings that weren't written by the user verbatim, unusable with this feature (e.g. the concat!(...) example above would never work).

I was expecting that format_args!(concat!(..), foo=0) would never work, because the macro requires that the first argument is a string literal. In actuality, however, format_args! allows the first argument to be concat! if and only if all arguments to concat! are themselves string literals (or, recursively, concat! that meet this requirement). playground
This means concat!("{", stringify!(foo), "}") isn't accepted, but concat!("{", concat!("f", "o", "o"), "}") is. This actually breaks the "format_args! is a proc macro" illusion, as this behavior does rely on resolving the macro call to std::concat! and even allows interceding user-defined macros-by-example!

Is this behaviour of format_args! resolving concat! calls intentional?
I haven't ever come across it before in code or documentation. Your nested-concat example concat!("{", concat!("f", "o", "o"), "}") is particularly suprising to me. My mind is totally blown that format_args!(concat!("{", concat!("f", "o", "o"), "}"), foo=3) compiles.
(I, possibly incorrectly, thought that macros are expanded from the outermost call first.)

This means concat!("{", stringify!(foo), "}") isn't accepted,

How did you test this? This compiles and prints 123:
fn main() {
    println!(concat!("{", stringify!(foo), "}"), foo = 123);
}

AFAIK format_args! (and possibly asm! as well, can't think of any others) takes an expression and attempts to expand it to a string literal.

I also think there are other libraries subject to similar issues as the panic macro. For example, I believe failure's macro for creating an error avoids formatting the string if it gets no additional arguments. It seems like this would be an idiom change not only for users of format_args but for people writing macros based on format_args, exactly the sort of change an edition would make sense for coordinating around.

The main downside I see then is that it might be possible to bypass hygiene using only builtin macros and no proc-macro, but maybe we can make strings that weren't written by the user verbatim, unusable with this feature (e.g. the concat!(...) example above would never work).

Having just tested the concat! example on my experimental PR implementation, it actually already rejects it! This is the code I tried:
fn main() {
    let target = "world";
    println!("hello {target}");
    println!(concat!("hello {", "target", "}"));
    println!(concat!("hello {", "target", "}"), target=target);
}

Both the first and third println! invocations compile fine, but the second fails:
 error[E0425]: cannot find value `target` in this scope
  --> scratch/test.rs:4:14
  |
4 |     println!(concat!("hello {", "target", "}"));
  |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope

I guess the hygienic context of the concat!-ed format string must be different to that of the literal. But of course this behavior is a result of concat!'s implementation, rather than defensive programming by me. A more robust solution would be for format_args! to only enable implicit named arguments if the format string was written by the user verbatim, as @eddyb suggests.

I also think there are other libraries subject to similar issues as the panic macro. For example, I believe failure's macro for creating an error avoids formatting the string if it gets no additional arguments. It seems like this would be an idiom change not only for users of format_args but for people writing macros based on format_args, exactly the sort of change an edition would make sense for coordinating around.

Having just checked the failure docs, this is indeed the case (for the bail! and ensure! macros at least).

Accepting implicit arguments it a pretty big change. It would be possible to eliminate foo=foo style repetitive named arguments by allowing to omit the foo= part from (still explicit) single-identifier arguments, like this: format!("{foo}", foo).

@H2CO3 that would be ambiguous. What should format!("{foo} {0}", foo, foo=1) do?

@H2CO3 that would be ambiguous. What should format!("{foo} {0}", foo, foo=1) do?

You're right, although that's not specific to the form I'm proposing. If foo is a variable in scope, then how should the same expression behave?

You're right, although that's not specific to the form I'm proposing. If foo is a variable in scope, then how should the same expression behave if single-identifier arguments are used implicitly?

Explicit named arguments would always take precedence over implicit ones.
This allows users greater control: they can eliminate all implicit capture if they provide all arguments explicitly. It also ensures that this RFC won't break existing code, as no existing code will suddenly start capturing identifiers in scope which collide with existing named arguments.
So if this RFC were implemented format!("{foo} {0}", foo, foo=1) would still expand the same as it already does today: {foo} would be substituted for the explicit named argument foo=1.
(This precedence is implied in the RFC text as-is because the search for an implicit named argument won't occur if a named argument already exists. I will update the RFC text to declare this precedence explicitly.)

@H2CO3

If foo is a variable in scope, then how should the same expression behave if single-identifier arguments are used implicitly?

The explicit named argument always take precedence, since it is "closer" to the format!() call. The problem with your proposal is that foo and foo=2 both appear at the same level, so there isn't a clear disambiguation rule.

I think by the way that the means of dealing with ambiguity should be to emit a compile error.

That means breaking change, which I don't think is justified (even if edition allowed that) since there exists alternative (this RFC) won't require the breakage.

@rfcbot resolved panic-may-not-work
Thanks for the updates to the text @davidhewitt!

Actually I noticed there's prior art with the same title: https://tools.ietf.org/html/rfc2795
Seems related...

Seems like using concat!() for format strings is not uncommon: https://github.com/search?l=Rust&q=format_args concat&type=Code
For example, the hprintln!() macro of cortex-m-semihosting uses concat!() to append a newline. This would mean that users of this hprintln!() macro cannot use implicit named arguments.
(However, in the case of appending a newline character, the (still unstable) format_args_nl!() could be used instead.)

As the author of ::fstrings, I find myself not using that crate that much just because it does not support concat! (I'll try to fix that when I have the time): not supporting concat! may thus be an important usability blocker.

Based on that nice github evidence (good idea to use the search like that) and that feedback it sounds like the concat! question should perhaps be addressed in a better way than just disabling the feature. Let me take a think on that...

Ping for checkboxes from @Kimundi @nikomatsakis @pnkfelix @sfackler

The problem that was mentioned about panic!() specializing for the single argument case also happens regularly outside the standard library:

In cortex-m-semihosting's print macros: here
In the liftoff crate for the logging macros: here
In one of my own crates, to prevent allocation in a log/print macro: here
In the sos_kernel project: here
In the bobbin-sdk project: here
Probably quite a few more. (It's hard to search for.)

All of these now accept literal { and } when called with only a string literal. Not only would parsing the string literal as a format string in the no-arguments case be a breaking change, but also prevent certain optimizations/shortcuts.
None of the suggested solutions for panic!() in the RFC would help here.
Maybe core::fmt::Arguments needs to have a fn as_str(&self) -> Option<&str>, to allow for a separate non-allocating case when there are no arguments to a format string?
In any case, it might be good to mention that not only panic!() is expected to change, but all providers of log/print-like macros are expected to re-evaluate how they deal with the no-arguments case.

All of these now accept literal { and } when called with only a string literal. Not only would parsing the string literal as a format string in the no-arguments case be a breaking change, but also prevent certain optimizations/shortcuts.

Yes, and probably all these crates will want to go through format_args! parsing in the single argument case if this change were to land, so that they can also support implicit named arguments fully. That's why the RFC believes this probably needs an edition change to stabilise.

Maybe core::fmt::Arguments needs to have a fn as_str(&self) -> Option<&str>, to allow for a separate non-allocating case when there are no arguments to a format string?

This seems like a very nice solution to me! I think that would work for panic! too. I wonder whether we could somehow use that to support a switch between 2018 and 2021 edition behavior for all crates.
I think this could work like so:

Downstream macros which want to use the single-argument optimisation do something like match format_args!(...).as_str(). Then:

On 2018 as_str would always succeed for the single-argument, to maintain current behavior.
On 2021 as_str would only succeed if the single argument didn't contain any formats.

This seems like a very nice solution to me! I think that would work for panic! too.

It'd work for core's panic macro. For std's panic macro, there still needs to be a way to differentiate between a string literal and throwing some other expression or literal, as panic!(5) now just happily boxes up the 5i32 in a Box<Any>.

For std's panic macro, there still needs to be a way to differentiate between a string literal and throwing some other expression or literal,

Yes. I think adding an unstable :strlit macro matcher would be able to solve this. (Or perhaps using the existing :lit with some smart thinking.)

Downstream macros which want to use the single-argument optimisation do something like match format_args!(...).as_str(). Then:

On 2018 as_str would always succeed for the single-argument, to maintain current behavior.

That'd imply that format_args!("{}") would have to be accepted instead of giving an error like it does now. That'd make things worse for the macros that don't have a problem (format!(), print!(), etc).

I've reflected on the concat! case a bit more. Supporting it (and presumably other macros) for implicit named arguments seems undesirable to me because:

It relies on expanding the inner macro, which is already very unusual for the Rust macro system.
It depends on the hygiene of the generated format string, which is dependent on the inner macro implementation.
It seems undesirable to try to implicitly capture a foo variable in scope from the following invocation: print!(concat!("{fo", "o}")).
I would argue nobody would ever want implicit argument capture for things like include_str! which produce format strings originating from outside the current source code. It certainly would be quite suprising to any readers of the code if any variables got captured in this way, as they wouldn't be visible anywhere in the macro invocation. (If someone really does want to capture some variables with include_str!, pass them as explicit named arguments!)

So I'd strongly argue against enabling implicit named arguments for inner macros.
However, what about if format_args! could accept a "tuple" of format strings in it's first argument? Each would go through the parser separately before being merged into a single fmt::Arguments struct. E.g.
print!(("foo ", "bar"))   // prints the literal "foo bar"
print!(("{foo} ", "{bar}"))  // implicit named arguments `foo` and `bar`
print!(("{foo} ", "{bar}"), bar=3)  // implicit named argument `foo`, explicit named argument `bar`
print!(("{fo", "o}") // ERROR: neither "{fo" or "o}" are valid format strings

The double-brackets syntax isn't delightful, but I imagine that it would really only be used by macro writers who need the concat!-like behavior. I see the following upsides:

By parsing each format string separately, it ensures implicit named arguments don't get conjured out of thin air by merging two format strings.

Downstream macros could easily expand to this syntax. E.g. for  the hprintln!() macro of cortex-m-semihosting:
($s:expr, $($tt:tt)*) => {
    $crate::export::hstdout_fmt(format_args!(($s, "\n"), $($tt)*))
};

Rather than attaching this syntax to format_args!, this could also be a new macro e.g. fmt_args_concat!.

That'd imply that format_args!("{}") would have to be accepted instead of giving an error like it does now. That'd make things worse for the macros that don't have a problem (format!(), print!(), etc).

Sorry, yes, you're right. We'd have to be careful to ensure that any behaviour of this fashion only applied for panic!-like macros.
Maybe a better solution would be create a macro format_args_or_literal!(), which expands to a variant of an enum:
enum ArgsOrLiteral<'a> {
    Literal(&'a str),
    Args(core::fmt::Arguments<a'>)
}

Then macros which need the panic-like behaviour could use this format_args_or_literal! macro instead of format_args!, and handle the literal case explicitly.
Names all to be bikeshed ofc.

Very excited to see this given a chance! I'm happy to do the implementation work for this going forward.

Checklist for the tracking issue:
Steps:

[ ] Implementation for format_args! behind format_implicit_args feature (name to be bikeshed?)
[ ] Implement alternative solution for format_args!(concat!(...)) case that doesn't risk spurious macro hygiene
[ ] Implementation for panic!. Behind feature gate and / or edition switch (see unresolved question)
[ ] Stabilize (may depend on new edition)
[ ] Documentation

Unresolved Questions:

[ ] Solution for those that want concat! - perhaps try out a new unstable macro as per this comment
[ ] Final design of the panic solution panic! - perhaps based off this comment

Huzzah! The @rust-lang/lang and @rust-lang/libs teams have decided to accept this RFC.
To track further discussion, subscribe to the tracking issue here:
https://github.com/rust-lang/rust/issues/67984

The RFC doesn't document how it interacts with raw idents, so for posterity:
let r#type = 5;

// Before this feature
assert_eq!("5", format!("{}", r#type));
assert_eq!("6", format!("{type}", type = 6)); // Named explicit does not need to be raw.
assert_eq!("5", format!("{type}", type = r#type));
assert_eq!("5", format!("{type}", r#type = r#type)); // Named explicit can be raw and maps to cooked version in the format string.

println!("{type}", type = type); // Error. RHS is an invalid expr.
println!("{r#type}", r#type = r#type); // Error. Named explicit can be raw but the format string can only use the cooked version.

// New after this feature
assert_eq!("5", format!("{type}")); // Format string references cooked ident and value is from raw ident.
                                    // ie compiler is smart enough to treat this as `type = r#type` and not `type = type`

println!("{r#type}"); // Still an error. Format string can only use the cooked version.
                      // So `"{type}"` is the *only* way to write this.


Add enums to schema.

Rendered
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The feature proposed in this RFC will have a negative impact on the analyzability of Cedar.
The RFC lets users specify attribute types that are ad-hoc subtypes of existing (primitive) types.  There is no effective way to encode these ad-hoc constraints into the multi-sorted first-order logic supported by SMT solvers.  Subtypes aren't supported natively in the logic, and there is no efficient way to express them---specifically, we'd need to use quantifiers to do so.
If we use quantifiers to enforce subtyping constraints, the resulting encoding falls out of the decidable fragment, and the analysis is likely to become brittle, suffering from timeouts and increased sensitivity to small changes in the encoding.
If we omit subtyping constraints, then the analysis becomes incomplete:  it can produce spurious counterexamples that violate the subtyping constraints.
There is a variant of this proposal that is encodable.  The variant would involve creating explicit enumerated types that are distinct from all other types, similarly to how this would be done in language like Rust.  For example, the schema could declare enum color { red, green, blue } and we'd have to add syntax that lets policies refer to literals of type color, e.g., color#red.
This alternative design is unsatisfying because it won't have some of the nice properties that enums have in statically typed languages (e.g., an implicit ordering on the literals).  This is because Cedar is dynamically typed, and the enum definitions wouldn't be available at runtime. In fact, it would be perfectly fine to write color#yellow in a policy, and this wouldn't result in a runtime error.
It is unclear that this alternative design brings sufficient benefit to justify the cost of implementing and supporting it.
I suggest that we reject this RFC for the time being, and revisit if there is substantial demand for it in the future.

The resolution implied by @emina's message above leaves me unsatisfied.  This RFC represents real user problems -- we've been asked about the possibility for this feature by multiple folks -- and I don't think we should reject it without brainstorming real alternative solutions for those users.

Update: we've decided to archive this RFC in favor of other options like #53

Closed as being unworkable from a typing perspective. A different enums proposal was accepted: https://github.com/cedar-policy/rfcs/blob/main/text/0053-enum-entities.md


Synchronized DbContext is not synchronized in data loaders

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
Have a data loader tha uses DbContext:
public class EntityByIdDataLoader<TEntity>: BatchDataLoaderWithDbContext<int, TEntity>
    where TEntity : class, IEntity
{
    public EntityByIdDataLoader(CommonDbContext dbContext, IBatchScheduler batchScheduler, DataLoaderOptions? options = null)
        : base(dbContext, batchScheduler, options)
    {
    }

    protected override async Task<IReadOnlyDictionary<int, TEntity>> LoadBatchAsync(IReadOnlyList<int> keys,
        CommonDbContext dbContext, CancellationToken cancellationToken)
        => await dbContext.Set<TEntity>().Where(e => keys.Contains(e.Id)).ToDictionaryAsync(k => k.Id, k => k, cancellationToken);
}

Have a resolver that uses two of these loaders:
    [GraphQLType(typeof(UserNoteRelatedEntityUnionType))]
    public async Task<object?> GetRelatedEntityAsync([Parent] UserNote parent,
        [DataLoader] EntityByIdDataLoader<Instrument> instrumentLoader,
        [DataLoader] EntityByIdDataLoader<Instruction> instructionLoader,
        [Service] IMapper mapper,
        CancellationToken token)
        => parent.RelatedEntityType switch
        {
            UserNoteRelatedEntityType.Instrument => await instrumentLoader.LoadAsync(parent.RelatedEntityId!.Value, token),
            UserNoteRelatedEntityType.Instruction =>
                mapper.Map<ViewInstruction>(await instructionLoader.LoadAsync(parent.RelatedEntityId!.Value, token)),
            _ => null,
        };

Occasionaly get:
A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext. For more information on how to avoid threading issues with DbContext, see https://go.microsoft.com/fwlink/?linkid=2097913.

on path
[
  "userNotes",
  "nodes",
  2,
  "relatedEntity"
]

Steps to reproduce

See above

Relevant log output
No response
Additional Context?
DbContext is registered as synchronized:
services.AddGraphQLServer().RegisterDbContext<CommonDbContext>(DbContextKind.Synchronized);

I thought I could enforce synchronization by adding DbContext explicitly as a parameter of the resover. However, this leads to endlessly running query.
Product
Hot Chocolate
Version
12.9.0

Changing resolver to this might work as a quick but performance costly fix:
    [GraphQLType(typeof(UserNoteRelatedEntityUnionType))]
    public async Task<object?> GetRelatedEntityAsync([Parent] UserNote parent,
        //TODO: https://github.com/ChilliCream/hotchocolate/issues/5328
        //[DataLoader] EntityByIdDataLoader<Instrument> instrumentLoader,
        //[DataLoader] LongEntityByIdDataLoader<Instruction> instructionLoader,
        CommonDbContext dbContext,
        [Service] IMapper mapper,
        CancellationToken token)
        => parent.RelatedEntityType switch
        {
            UserNoteRelatedEntityType.Instrument => await dbContext.Set<Instrument>().SingleAsync(i => i.Id == parent.RelatedEntityId),
            UserNoteRelatedEntityType.Instruction =>
                mapper.Map<ViewInstruction>(await dbContext.Set<Instruction>().SingleAsync(i => i.Id == parent.RelatedEntityId)),
            _ => null,
        };

Synchronization only works on a resolver level. We could probably introduce a way to also run DataLoaders sequentially. You are probably better of just creating and disposing a new dbcontext instance in the dataloader method. In essence this https://chillicream.com/docs/hotchocolate/integrations/entity-framework#dataloaders but instead of the factory you create a new service scope and resolve the dbcontext from there. then dispose the scope and return the items.

Okay, but documentation heavily implies otherwise. In "Working with a pooled DbContext" docu states "You also need to access your DbContext differently. In the following chapters we will take a look at some of the changes you have to make." In conjunction that the next chapter being "DataLoaders" it heavily implies that DbContext should work even with data loaders and the next chapter "DataLoaders" describe how they should be changed in case of pooled DbContext. It should be clearly stated that this is not the case.
However, this does not explain why this makes it endless:
[GraphQLType(typeof(UserNoteRelatedEntityUnionType))]
public async Task<object?> GetRelatedEntityAsync([Parent] UserNote parent,
    [DataLoader] EntityByIdDataLoader<Instrument> instrumentLoader,
    [DataLoader] EntityByIdDataLoader<Instruction> instructionLoader,
    [Service] IMapper mapper,
    CancellationToken token)
{
    await _semaphor.Wait();

    object? result = parent.RelatedEntityType switch
    {
        UserNoteRelatedEntityType.Instrument => await instrumentLoader.LoadAsync(parent.RelatedEntityId!.Value, token),
        UserNoteRelatedEntityType.Instruction =>
            mapper.Map<ViewInstruction>(await instructionLoader.LoadAsync(parent.RelatedEntityId!.Value, token)),
        _ => null,
    };

    _semaphor.Release();

    return result;
}

[GraphQLType(typeof(UserNoteRelatedEntityUnionType))]
public async Task<object?> GetRelatedEntityAsync([Parent] UserNote parent,
    [DataLoader] EntityByIdDataLoader<Instrument> instrumentLoader,
    [DataLoader] EntityByIdDataLoader<Instruction> instructionLoader,
    CommonDbContext _,
    [Service] IMapper mapper,
    CancellationToken token)
    => parent.RelatedEntityType switch
        {
            UserNoteRelatedEntityType.Instrument => await instrumentLoader.LoadAsync(parent.RelatedEntityId!.Value, token),
            UserNoteRelatedEntityType.Instruction =>
                mapper.Map<ViewInstruction>(await instructionLoader.LoadAsync(parent.RelatedEntityId!.Value, token)),
            _ => null,
        };

I suppose both deadlock as under the hood second case is just the first case (implicitly). But why do they deadlock?

Can you point to the chapter?
The short version is .... if you synchronize do not use DataLoader. While there is some sync logic we do (executing the DataLoader one after the other) it in the best case will make your API super slow.
If you do EF Core and you want a fast API use one of the following:

Pooling
Resolver Scoping

if you go for the latter one make sure to scope the context for DataLoader.

we do not use a semaphore ... we have an execution plan that marks certain nodes as serial and makes sure that they are executed one after the other.

OK ... I see the issue you have. So, you marked the DbContext serial but we do not have an knowledge that the DataLoader need synchronous execution. Mark the resolvers as serial.
[Serial]
[GraphQLType(typeof(UserNoteRelatedEntityUnionType))]
public async Task<object?> GetRelatedEntityAsync([Parent] UserNote parent,
    [DataLoader] EntityByIdDataLoader<Instrument> instrumentLoader,
    [DataLoader] EntityByIdDataLoader<Instruction> instructionLoader,
    CommonDbContext _,
    [Service] IMapper mapper,
    CancellationToken token)
    => parent.RelatedEntityType switch
        {
            UserNoteRelatedEntityType.Instrument => await instrumentLoader.LoadAsync(parent.RelatedEntityId!.Value, token),
            UserNoteRelatedEntityType.Instruction =>
                mapper.Map<ViewInstruction>(await instructionLoader.LoadAsync(parent.RelatedEntityId!.Value, token)),
            _ => null,
        };

bit it should not deadlock... can you create a small repro for us?

Why aren't you using pooled? instead of synchronized?

@michaelstaib The issue in doc I see in https://chillicream.com/docs/hotchocolate/integrations/entity-framework/#working-with-a-pooled-dbcontext the last paragraph implies that if u are using pooled, change data loaders this way, otherwise use let them access DbContext directly. The phrase "a look at some of the changes you have to make" in conjuction with chapter "DataLoaders" implies that you already have a data loader that uses DbContext (directly) and that you have to change it this way to work with pooled DbContext.

I do not want to use factory as there is a single DbContext that tracks everythin in the current operation and auto-saves it at the end. Auto-save happens after GQL (in ASP NET Core middleware) and thus if any other DbContext materialized the entities it would materialize them as unchaged based on fetched data instead of reusing tracked instances.

I faced the same problem yesterday. After several experiments I've managed to reproduce it on a simple case.
Code:
public class DataQuery
{
	[GraphQLName("multiple-data")]
	[GraphQLNonNullType]
	public async Task<DataQuery[]> GetMultipleDataAsync()
	{
		return new[]
		{
			new DataQuery(),
			new DataQuery(),
		};
	}

	[GraphQLName("data")]
	[GraphQLNonNullType]
	public async Task<int> GetDataAsync(
		IResolverContext resolverContext,
		[Service(ServiceKind.Synchronized)] IServiceScopeFactory serviceScopeFactory)
	{
		return await resolverContext
			.BatchDataLoader<int, int>(fetch: async (ints, _) => ints.ToDictionary(i => i, i => i))
			.LoadAsync(Random.Shared.Next());
	}
}

Query:
query {
  multiple_data {
    data
  }
}

Important things to reproduce the deadlock:

Resolver must have at least one Synchronized service (or implicitly disabled parallel execution in parameter expression builder / e.t.c.).
Resolver with DataLoader must be called at least twice.
DataLoader must be loaded with unique CacheKeys (if we replace Random.Shared.Next() with static number, it will work).

Deadlock happens because we call await ....LoadAsync(...). We stuck here until end of the query.
Here is hypothetical situation (in the case above with two data rows):

DataLoader waits for the 2nd "data" resolver's call completion.
The 1st "data" resolver's call waits for DataLoader's LoadAsync because of await.
The 2nd "data" resolver's call waits the 1st "data" resolver's call completion because of Synchronized service.

Thank you for providing a repro ... I will have a look at it tomorrow.

Thank you for providing a repro ... I will have a look at it tomorrow.

@michaelstaib do you have any updates?

I'm not using Entity Framework, but would like to leverage SQL Server's snapshot isolation transaction to ensure that all the data loaded from the database is internally consistent. Executing multiple queries concurrently may speed up single request latency and look good on performance benchmarks, but concurrent execution makes it impossible to share the same snapshot isolation transaction throughout a single GraphQL query, potentially causing inconsistent results. Due to this issue, is it currently impossible to do what I want, which is to service all requests with the same connection and transaction? I also thought that I could serialise access to my connection/unit of work using Serial, but are data loaders not serialisable at all?

@nzbart we have a transaction abstraction that wraps around the whole request ... you can implement this.

While we do not synchronize them we now scope them ... so this issue is fixed.


Kiota should add kiota-{lang}/version to the UserAgent string on platforms where it is allowed

Having API providers see that their API is being called by Kiota generated code will be a signal that they don't need to go build SDKs for languages they don't currently have support for.
This can be done in Kiota core libraries.  If someone replaces core library, they can choose whether to send the identifier or not.

What should we do in the case of JavaScript running in browser? (Might also impact dotnet wasm)

As long as it doesn't fail we should write it too.  I discussed with folks from the chromium project and we should be able to get that bug onto their todo list next year.

implemented in most languages. no changes to this repo. added issues to other languages. closing.


Code support for clinical trials

Several classes need to be parametrised to support clinical trials.
Add support for it when #6 is solved.

@plopezgarcia has suggested to join this subtask. Let's keep track of code changes on this issue.

Partially implemented on #78 .

Maybe use decay functions to rank age.

Blocked on #92 .


EDGEPOD-317 - separate procedure context for attach and s1 release

This activity involves the following change:
1. Separation of Attach and S1 Release Procedure Contexts

Can one of the admins verify this patch?

Can one of the admins verify this patch?


Bump abseil to LTS 20240722.0.

Also add one additional patch to CEL to handle absl::StrCat and friends moving to absl/string/str_cat.h.
Risk Level: low
Testing: CI

Carving off more of #36167.

/retest

/retest

/retest

/retest


Request: Right-click menu staying when mouse is moved away

Haven't seen this done before in other clients. Might be quite useful for some users.
This is a feature request. Couldn't find where to add the appropriate label for it.

Labels are added by administrators, so you're fine as far as that goes.
That sounds like a pretty unique feature, but I wouldn't want that to be a default. How would this be managed? (modifier key, or some other control to toggle this behavior?)

Yeah definitely not active by default, as very few users would like it. It's something that anybody who would benefit from, would probably want to be able to toggle regularly. Probably an enable/disable in settings with config to add a toggle key like alt. Idk which keys are used for stuff already.


[Possibly] memory leak in BulkIndex writing when going from v5 to v6 of this library

Hello - I use this library through another project: https://github.com/pwillie/prometheus-es-adapter
I recently deployed a new version of that project, which bumped its version of this elastic client from v5 to v6.
To be clear, I'm not representing the author of that project in any way - I just noticed, when doing pprof heap dumps of the memory leak, that the BulkIndexRequest of this library was appearing to dominate lots of memory.
I have pastes of pprof heap top and pngs of allocs and in_use in the issue I made in the other project: https://github.com/pwillie/prometheus-es-adapter/issues/22
Here's an in_use space snapshot:
Please let me know if I can be more helpful.

Hmm... this could and could not be a bug. It depends on how large the bulk index requests are, and if the problem worsens over time. I'm not aware of a leak yet, I only acknowledge that Bulk API may use large amounts of memory (it's copying byte buffers largely).
Can you see a leak, or did you just notice that it took large amounts of memory?

The memory use by this library on the server grows until it runs out of memory. Probably a leak? Do you have suggestions of other measurements I can take to help track this down better?

I would also say it's a memory leak.
I am also using the same software as @sevagh, and so far my Prometheus doesn't send a lot of metrics. It's configured to collect and send metrics every 30 seconds, but I do notice the RAM usage keeps increasing until it fills the whole memory available (10GB+ in under 24H).
Thanks for your help

I haven't got any further report about leaks in the last 2 years. So closing for inactivity.


getOwnedApps  How to filter out many free games returned by getOwnedApps

getOwnedApps  How to filter out many free games returned by getOwnedApps

See the docs: https://github.com/DoctorMcKay/node-steam-user?tab=readme-ov-file#getownedappsfilter


Eight-character SHAs not properly highlighted in UI views

Occasionally, a Git SHA is displayed with eight characters instead of seven. For example, in the Rebase view:

I’m not sure if the bug is the length of the SHA or the lack of highlighting for the extra character, but there’s obviously something wrong.

Hi @sentience, Git short refs are the shortest unambiguous prefix of the full 40 character SHA1 ref of a commit, with a minimum length of 7. Seeing a longer one here isn't a git bug, it means you have two or more refs starting with 49090f1. The fact that it isn't syntax highlighted correctly is a GitSavvy bug.


NetworkServer.Disconnect() never calls NetworkServer.Cleanup() and NetworkServer.Active remains true

Describe the bug
Upon calling Server.Disconnect() on an active server, Server.Active is never set to false. Internal Server.Cleanup() is never called.
Repro project
MirrorNG Server Disconnect Test.zip
To Reproduce
Steps to reproduce the behavior:

Open the attached project.
Open 'Example' scene.
Enter play mode.
Note "Server Active: False" in the middle of the game view.
Press "Start Host".
Note "Server Active: True".
Press "Stop network".
Note "Server Active: True" still.

Expected behavior
Label should read "Server Active: False" since Server.Active should return false after the server has been disconnected.
Desktop:

OS: Windows 10
Build target: Editor
Unity version: 2020.1
Mirror branch: master

Additional context
I'm using KCP Transport.
You get the same result from "Start Server Only".
The server bug could not be reproduced with v51.1.4 using TCP Transport.
Similarly, using "Start Client Only" and then disconnecting, you still get "Client Active: True". But that only happens in Client-Only mode, not in Host mode. This one, however, could be reproduced with TCP Transport. This one is most likely a separate issue.

Fixed 3d06e8aa9b21c667b231a609cf194e517b75438c.


[OSSM-2221 | OSSM-2340] Ensure injection in SMCP ns disabled below v2.4

This PR:

Ensures that the ignore-namespace label is still applied to the SMCP namespace when creating SMCPs below version 2.4.
Modifies the v2.4 MutatingWebhook ObjectSelector to never attempt to inject into the istiod pod [OSSM-2340]
Modifies the v2.4 kiali_cr to label the kiali pod to not inject, fixing the problem when an SMCP was created with auto-inject.
Adds another namespaceLabels unit test to test labels added/removed pre v2.4 and post v2.4.

Tested on CRC by:

Creating a v2.4 SMCP, deleting istiod pod and seeing it self heal.
Creating a v2.4 SMCP with auto-inject enabled and seeing kiali created successfully with no proxy container.
Creating v2.3, v2.2 SMCPs and making sure the ignore-namespace label is applied, and deleted when smcp is deleted.

/test all


custom/ not loading?

I tried to put some scripts (.zsh) containing just some simple alias inside $ZSH_CUSTOM and restarted the terminal, but the custom scripts (even example.zsh) don't seem to load.
Is there some configurations I am missing?

Never mind, the path was wrong. The scripts load normally. Sorry


bug in tf.Print summarized formatting

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): YES
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): MacOS
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 1.8
Python version: 3.6
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A
Exact command to reproduce: N/A

If you print a tensor of shape [n, 4] with tf.Print, by default (summarize=3 is the default value), you get:
[[9 21 55]...]
which wrongly looks like your tensor is of shape [n, 3].
The correct output should be:
[[9 21 55...]...]
Here is what you get with tf.Print(summarize=10):
[[9 21 55 30][190 -42 236 4][89 -5]...]
Now the vectors of size 4 are visible although the last one is still wrong (looks like a vector of size 2
)

Added a PR #20768 for the fix.

Nagging Assignee @poxvoculi: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.


storage: Add missing file for package-2019-06

storage.json references privatelinks.json which is missing from the input-file list
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of “no breaking changes
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

/azp run automation - sdk

Can one of the admins verify this patch?

/azp run

@stuartleeks please help fix the CI failure to get this PR ready to merge.

I've taken a look at the build failures and I'm not sure what they are referring to - can you help me understand the error?

(for context, this is intended to address #10505)


Question on PDFS and links

First off: love the platform.
So I'm working on creating a document management site but I was wondering something. How can I add a pdf to a record and have it where a user can click on it and it either A) opens in a new tab, or B) pops up to where they can view the PDFs pages or page.
Also is there a way to add a static href link to the platform? Say I want a link that goes to google.com somewhere, is this possible?
Thanks again for your work on the platform!

Where would you want to place the link?

If you want to place link in navigation, its already possible with Url parameter of navigation links. Otherwise you could put them in Page.cshtml files anywhere you like. Or append to grid.Toolbar.
UrlFormatter is possibly what you are looking for PDF links.

Awesome. I'll look into putting it on the page.cshtml, but will the PDFs be
stored in the database like the images of Keanna Reaves are stored in your
Movie dB tutorial?
On Sun, Mar 13, 2016, 11:34 Volkan Ceylan<EMAIL_ADDRESS>wrote:

If you want to place link in navigation, its already possible with Url
parameter of navigation links. Otherwise you could put them in Page.cshtml
files anywhere you like. Or append to grid.Toolbar.
UrlFormatter is possibly what you are looking for PDF links.
—
Reply to this email directly or view it on GitHub
https://github.com/volkanceylan/Serenity/issues/400#issuecomment-195979884
.

I used the url: paramater but it error-ed due to not https://www.google.com is not a relative virtual path. How can I get to external sites?

Try this code in your NavigationModel.cs:
        public NavigationModel()
        {
            Items = TwoLevelCache.GetLocalStoreOnly("LeftNavigationModel:NavigationItems:" + (Authorization.UserId ?? "-1"), TimeSpan.Zero,
                UserPermissionRow.Fields.GenerationKey, () =>
                    NavigationHelper.GetNavigationItems(x =>
                        x != null && x.StartsWith("~/") ? VirtualPathUtility.ToAbsolute(x) : x));

            SetActivePath();
        }

Sweet, I'll give it a go and report my findings.

That works!!


Update Hub Mobile and Desktop Layouts

Overview
The breakpoint changes have impacted the layout -- we need to adjust so that the desktop view shows as well. As it is, the mobile view is used on the desktop as well.

https://github.com/HausDAO/daohaus-monorepo/pull/311

Closed by https://github.com/HausDAO/daohaus-monorepo/pull/311


Create Nuget package and publish it during release runs.

Since we have onboarded to vcpkg and conan, NuGet is no longer needed to consume this library from MSBuild.


how to deploy the project with 'npm run build'

Great work! so there is a question, if I want to run 'npm run build' cmd to build a static folder and use nginx to serve, looks like the css isn't loaded when I open the url, so do you know how to deploy it with build cmd? Thanks!

solved already, thanks anyway!


Trap errors when instantiating CSW repo

Did this start happening to a repo we're already crawling?


Prevent collisions between entities with the same root parent

Blocked by #334.

@fallenatlas this also needs some explaining. Ig what we want is for there to be a way to avoid collisions between entities which are part of the same rigidbody/staticbody.


Big Sur menu bar text alignment is too high

Under macOS version 11.0 (20A5364e) which is the latest public beta, my BitBar items are too close to the top of the menu bar.
If you use the red line as a ‘baseline’ guide, and note that the items marked in yellow are all BitBar, you can see they are higher (closer to the top / further from the bottom) than the other icons.

Does #513 helps?

Grëat.
I wish I had realized that this project was effectively dead even for bug-fixes before I bothered getting involved with it.
Never should have stopped using TextBar.


Touch devices

Out of curiosity, I tested TB on my iPad and iPhone, and I found out the only thing not working is drop menus. They won't open.
I found this commit by @cam-intel :
https://github.com/cam-intel/bootstrap/commit/ea16b3bf0fdf2f62ceefefeb93a11036b1eff86a

Shouldn't we include this in the forecoming 1.4 release?

Actually it seems to work fine in the TB demo, not on RailsAdmin. I'll investigate a bit more.

interesting - keep me posted if you come across any mobile weirdness :)


perf setup feedback

Thanks @PiotrSikora  for feedback:
Few notes on the perf setup:

All functions assume that setup_perf_cluster.sh was sourced from Istio's main directory and not from within tools - doing so breaks ton of things (IMHO, incorrectly).
Since the file is sourced and not executed, all variables are (or at least seem to be) evaluated at sourcing time, so changing directory (to fix #1) doesn't help, and requires re-sourcing files again.
There is no error checking (set -e, pipefail?), so the script continues even if early commands fail (e.g. on a fresh setup, k8s APIs are disabled, so creating cluster always fails).
Delete operations don't check if object exist before trying to delete it, which means that cleanup after bad init looks terrible. FWIW, I used to do something like "if [ -n "gcloud compute instances list --filter="name=fortio-vm" 2>&1 | grep fortio-vm" ]; then delete; fi".
Inject script tries to add sidecars from docker.io/istio/proxy:a7b0ddb83f235bafa5871f557ba97620da6a4afe, but that doesn't exist (the commit is 0.5.1 and that's the tag in Docker).

cc @danehans

Summarizing our chat offline:
First thanks a lot for giving this early/rough script a try ! please keep trying

yes for interactive runs you need to exactly source tools/setup_perf_cluster.sh but let's fix it / make it check if the dir isn't where it needs to be
update_gcp_opts is needed to change any env but I don't think indeed it deals with path/dir issues - can be improved
the script used to exit on error when it was ran instead of sourced but I just dropped it to avoid exiting your interactive shell - I have to think how to do this right and not too many changes (maybe only in Execute with a flag to say if errors are ok or not - like creating namespace is ok to error with already exist if you rerun some functions...)
@danehans - I didn't read carefully that part (and I don't use it myself, my bad)
that's because your istioctl is the wrong one (see https://github.com/istio/istio/tree/master/tools#prepare-the-istio-deployment-manifest-and-istio-client )

cc @ozevren who also encountered some issues with the script (and again super thanks to both of you for trying and your patience) and cc @andraxylia who wanted to try it too

issues addressed I believe


Audio stops working after pausing and resuming

Running on Arch Linux with PipeWire for audio, using KDE and Wayland.
When psst-gui is first started, I'm able to click on a song to play it, but after doing certain things related to playback, (i.e. pausing and resuming the song or manually switching to another song) the audio fails to play. Strangely, while pausing and resuming kills the playback, skipping through it via the playback bar or letting it continue to another song automatically doesn't.
Here are the logs, although they don't seem to give any notable information:
[2021-09-07T02:34:04Z INFO  psst_gui::data::config] loading config: "/home/maxwell/.config/Psst/config.json"
[2021-09-07T02:34:04Z INFO  psst_core::cache] using cache: "/home/maxwell/.cache/Psst"
[2021-09-07T02:34:04Z INFO  psst_gui::data::config] saved config: "/home/maxwell/.config/Psst/config.json"
[2021-09-07T02:34:04Z INFO  psst_core::access_token] access token expired, requesting
[2021-09-07T02:34:06Z INFO  psst_core::access_token] access token expired, requesting
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9214096
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9218070
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9219441
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9226296
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9234454
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9241309
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9252277
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9260503
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9267358
[2021-09-07T02:34:07Z INFO  psst_core::audio_file] blocked at 9272842
[2021-09-07T02:34:07Z INFO  psst_core::audio_player] starting playback
[2021-09-07T02:34:07Z INFO  psst_gui::controller::playback] playing
<- this is where I clicked on another song, audio stops playing here ->
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5646820
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5656159
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5673914
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5680769
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5686253
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5695731
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5697102
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5699844
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5705328
[2021-09-07T02:34:13Z INFO  psst_core::audio_file] blocked at 5708070
[2021-09-07T02:34:13Z INFO  psst_core::audio_player] starting playback
[2021-09-07T02:34:13Z INFO  psst_gui::controller::playback] playing```

Looks like error using pipewire due it controls alsa in different ways than pulseaudio

We will rework the audio output soon, and probably switch to cpal, which should help with PipeWire configs.

We will rework the audio output soon, and probably switch to cpal, which should help with PipeWire configs.

https://github.com/H-M-H/psst/tree/cpal This would be a great branch to start with.

Closing as we're using cpal already.


create, delete, rename and move files silently?

It's more of a question actually rather than an issue..
I just want to know if its possible to crud operation in nerdtree without firing up the NERDTree menu?

Currently, it's not possible, but it's not hard to add this. For example, add these lines to your .vimrc:
augroup NERDTreeSetup
    autocmd!
    autocmd VimEnter * call NERDTreeAddKeyMap({'key': '<F2>', 'scope': 'all', 'callback': 'NERDTreeDeleteNode'}) |
                     \ call NERDTreeAddKeyMap({'key': '<F3>', 'scope': 'all', 'callback': 'NERDTreeAddNode'}) |
                     \ call NERDTreeAddKeyMap({'key': '<F4>', 'scope': 'all', 'callback': 'NERDTreeMoveNode'})
augroup END

The hard part is coming up with keys that make sense and aren't already being used. The same changes (minus the autocmd pieces) can be made in nerdtree_plugin/fs_menu.vim, if someone wants to take on a bigger challenge that includes these issues.


UseUsingScopeModifierInNewRunspaces: Fix ThrowAddingDuplicateWithKeyArgumentException

PR Summary
Fixes #1511
TODO: write test
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

Hmm. .Net 4.5.2 doesn't have ContainsKey. Will have to use Contains

Closed as I already did the fix in PR #1493, my fork just wasn't up to date


Move content in /opt to /usr/lib/opt when importing container image if state overlays enabled

As part of https://github.com/ostreedev/ostree/pull/3120 and https://github.com/coreos/rpm-ostree/pull/4728, packages which install to /opt are converted to /usr/lib/opt/ by the importer. To mesh with this, imported container images need to also do this translation. It can know if a system is configured for state overlays on /opt by checking if<EMAIL_ADDRESS>is defined.
(Or alternatively, the code can automatically enables this service if it detects content in /opt. That way, users can leverage this stuff before the base image compose actually enables the opt-usrlocal-overlay knob).

Or alternatively, the code can automatically enables this service if it detects content in /opt.

That would conflict though with the existing logic in https://github.com/ostreedev/ostree-rs-ext/pull/570/commits/495988e5115311703aed00eabc67807e0a79bb56

Querying systemd units while fetching, or when deploying an image feels...a bit icky.  A layering violation in a way.
I would perhaps lean a bit towards doing this as part of RUN ostree container commit - i.e. the container content is fixed up at build time, not client side.

I would perhaps lean a bit towards doing this as part of RUN ostree container commit - i.e. the container content is fixed up at build time, not client side.

Sounds good to me. I guess if we start assuming this in the future (because it's just always on in the base compose), we could move it to the tar processing step. At that point, it'd purely a mechanical move, just like the /var to /usr/share/factory/var move.

Obsoleted by https://github.com/ostreedev/ostree-rs-ext/issues/607#issuecomment-1973476187. We don't need to move the content to /usr/lib/opt if we don't care about the non-composefs case.


docs(readme): mention -- when passing options

:tada: This PR is included in version 2.0.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Possibly switch to ISBN and tags

This will let the books be automatically linked to and can resolve the correct author
and title information.
Possibly use:  https://developers.google.com/books/

Could be interesting, but makes it so offline development/viewing can't be done.