New Doc Content Request - Detecting Optional Arguments

Problem or new feature
A recent conversation on the raku-beginner channel here
asks

03:55]pelevesque: Hey guys, I'm stumped
sub a ($scalar?) { say $scalar.defined }
a(1); # True
a(); # False
This works, but I need it for a list....
sub a (@list?) { say @list.defined }
That fails...
Is there a way to know if a list as an optional parameter was defined? It seems like it creates an empty list.
A clear and concise description of what the bug is, including links to the page where you have found it.

Suggestions
Then many ideas were proposed, but, at the end, the question remains Is there a way to know if a list as an optional parameter was defined? and I think that we could improve the docs with a good, standard example of this to add at the bottom of this section: https://docs.raku.org/language/signatures#Optional_and_mandatory_arguments
My "starter for 10" is:
Checking for the presence of an optional argument is complicated by the fact that the empty List (), Array [] and Hash %{} are .defined. It can be done like this for Scalar parameters:
sub is-scalar($x? = Nil) {
    with $x {say True}      #with uses .defined
    else    {say False}
}
is-scalar(42);  #True
is-scalar();    #False

For Positional parameters, you can introduce a constant ArrayAt for a specific Array, and use it like this:
constant ArrayAt = []; # a specific Array

sub is-positional(@a? = ArrayAt) {
    if @a =:= ArrayAt {say False}
    else              {say True}
}
is-positional([^42]);   #True
is-positional(());      #True
is-positional();        #False

And similarly, for Associative parameters with HashAt for a specific Hash:
constant HashAt = {}; # a specific Hash

sub is-associative(%h? = HashAt) {
    if %h =:= HashAt {say False}
    else             {say True}
}
is-associative({a=>1}); #True
is-associative({});    #True
is-associative();       #False

Note: you can use the tests [] ~~ Empty (True) and {} ~~ Empty (True) to test for the presence of elements within Positional and Associative parameters respectively.

Surpsisingly, we a default undefined value can be bound to a positional argument.
    constant NaA = Positional; # This is Not an Array.
    sub nice(@a? = NaA) { say [@a =:= NaA, @a.defined, @a.so]; }
    nice(); # [True False False]
    nice([]); # [False True False]

Same for Associative.
    constant NaH = Associative; # This is Not a Hash.
    sub nice(%h? = NaH) { say [%h =:= NaH, %h.defined, %h.so]; }
    nice();
    nice({});

I was just exploring the same thing. I'd written this so far:
Maybe:
sub a (@list = Positional ) { say @list.defined }
a # False

But then I was writing about maybe making a related change for 6.f (@? means @ = Positional etc.), and then began exploring some related destructuring results I found surprising, and... then your comment appeared.

@librasteve
sub a (Positional $list?) { say $list.defined }

I love that. But it changes the sigil, which might be an issue.

I also find myself having to rethink my idea of an optional parameter ? since it seems that a vanilla positional with a default is effectively optional in that the argument may be missing.

What's going on applies to any parameter (positional or non-positional, scalar or non-scalar, vanilla or fancy).
Either is optional (or ?) or a default (= default) direct Raku to bind a signature even if, for a parameter marked one of those ways, there is no corresponding argument.
(Indeed Raku(do) happily/silently lets you write both is optional (or ?) and = default if you want.)
If a signature successfully binds, then Raku must bind all parameters, even ones for which there was no corresponding argument. If there's an explicit default (= default) then it binds to that. Otherwise it binds to a new instance of a default type corresponding to the parameter's sigil. (And a new collection instance is .defined, hence @list.defined is guaranteed to fail to do what is desired.)

The verbiage "Detecting Optional Arguments" in this issue's title is ambiguous.
It could reasonably be read as meaning something like this:
sub a (@list?) { say &?BLOCK.signature.params[0].optional }
a; # True

This issue seems to be discussing something else.

It could be this issue is more like "Detecting Missing Arguments".
That could reasonably be read as meaning something like this:
sub a (|arguments (@list?)) { say arguments[0].defined }
a; # False

That might actually be desirable in some scenarios. So perhaps it ought be written up somewhere in the docs, and perhaps linked to or directly included in any doc written in response to this issue.

What this issue most seems to be about is sort of in between "Detecting Optional Arguments" and "Detecting Missing Arguments".
It seems to be about detecting whether the value that actually ends up being bound to a parameter, after signature binding has completed and all parameters have been bound, was or wasn't sourced from an argument.
And right now it seems to me that the best way to determine that is to add an explicit default that will be bound to a parameter if an argument isn't passed.

It may be appropriate to pick a default that cannot be passed, to avoid false positives -- thinking no argument was passed when one actually was:
sub a (@list = Positional) { say @list.defined }
a Positional; # False

If the above is a problem, then perhaps:
my role NoArg does Positional {}

sub a (@list = NoArg) is export { say @list.defined }
a; # False

The above ensures that no code that imports a can pass an argument that tricks a into a false positive.

Another case is slurpies, eg *@foo. In that case you'll need to analyze the capture (the list of arguments passed):
sub a ($foo, *@list (|args)) { say ?args }
a 42; # False

Sorry for the slow response.
I agree that this Issue should be renamed "Detecting Missing Arguments".
So far we have seen two good ways to express this, so I amend my initial "Starter for 10" as follows. Hopefully we have a consensus on this and can proceed to make the change.

Detecting Missing Arguments
Checking for the presence of missing arguments can be done like this for Scalars:
sub a($scalar = Nil) {  say $scalar.defined }
a      # False

For Positionals and Associatives, it is complicated by the fact that the empty List (), Array [] and Hash %{} are .defined.
A simple approach is to set an undefault value, such as a type class:
sub a (@list = Positional) { say @list.defined }
a       # False

Another approach, is to introspect the capture:
sub a (|arguments (@list?)) { say arguments[0].defined }
a; # False

The ? optional marker (or is optional trait) has no effect when a default is specified.
Note: you can use the tests [] ~~ Empty (True) and {} ~~ Empty (True) to test for the presence of elements within Positional and Associative parameters respectively.

TL;DR Perhaps "Detecting Omitted Arguments"?

Thank you for renaming the issue title; I think that's a useful step; but to be clear I meant that as a thought experiment, a step in a direction of travel, not a final destination.

One of the underlying problems related to this issue that I had in mind is the linguistic (English) mental models folk have (as opposed to technical mental models), as reflected in the following SO exchange I had with the poster of a question:
I wrote:

The "optional" in "optional parameter" doesn't mean the parameter is optional. Instead it means that passing an argument corresponding to that parameter is optional.

Their reply was:

That's why you shouldn't say "optional parameter". Remember that people who have no idea what any of this is will read this and think that the docs mean what they say.

Their reply ironically couples an implicit demonstration of my implicit point (English is ambiguous) with what appears to be total ignorance of the relatively explicit point (that they had misinterpreted "optional parameter", because English is inherently ambiguous no matter how hard you might try to eliminate it).
Why else would they declare we should change the doc to match their incorrect understanding? Did they really think we could arrive at some new phrasing that was less confusing about what is after all distilled in the parameter trait is optional?
Their reply seemed to reflect arrogance of the highest order, but still, what is one to do?

My current thinking is that "optional parameter" stays. (Unless someone comes up with a better term, and I'm not personally much interested in pursuing that. I think it will be challenging given that I can't imagine their being consensus that the is optional trait ought be deprecated, and I sure know I won't vote for that.)
But it does reflect subtle problems with ambiguous verbiage.
And while "detecting missing argument" is imo a significant improvement over "detecting optional arguments" (because what's being detected here is not the is optional), the switch to "detecting missing arguments" has its own problems.
What's being detected here isn't some kind of mistake -- and to me "missing" connotes a problem ("who lost that argument?!?").
So what might we do as a next thought experiment (still not as a final destination, though perhaps closer or close enough)?
Perhaps "detecting omitted arguments"?

TL;DR If the sketch you provided was just to further our understanding in this issue prior to thinking about a PR then that's great and it did the job for me. But "Starter for 10", "consensus", and "proceed to make the change", and the way you are writing things, makes me think you may have meant it as something akin to a PR draft. This comment is based on that interpretation and is push back about things I didn't like in that context. And then my next comment after this one will be my "Starter for 2c" about a PR draft.

Checking for the presence of missing arguments can be done like this for Scalars:

sub a($scalar = Nil) {  say $scalar.defined }
a      # False

Some things I don't like about that:

Starting with $scalar = Nil. I'd rather start with $scalar?, or $scalar is optional, or ($scalar is optional) { # \$scalar is optional` means the same as `$foo?`or($foo?) { # `$foo`? means the same as `$foo is optional``.

The = Nil is redundant. Again, I get that it can serve as a way to establish a pattern, but I still don't like it.

The use of Nil would fail to detect an omitted/missing argument if that argument is Nil.

Worse, the .defined test will fail to detect an omitted/missing argument if that argument is not .defined.

A simple approach is to set an undefault value, such as a type class:

I presume you're just sketching out how to think about things, rather than trying to nail down precise verbiage, right? Is "undefault" a typo, meant to be "default"? Or is touching on something else, like the fact that there's an implicit default default and what a user needs to do is set an explicit default? Is "type class" a slip, or because you don't like the existing term "type object", or something else?
Putting those questions aside, I don't like the formulation you sketch for roughly the same reasons as I the ones that meant I didn't like = Nil and .defined.

Another approach, is to introspect the capture:

Written exactly like that could be a very abrupt introduction of "capture" if the reader hasn't encountered, or at least studied/understood them, before.
So I would suggest two things.
First, some preamble text, a succinct version of the following distinction which I don't have time right now to reduce to something sufficiently brief:

Directly, laboriously, manually, introspecting the list of arguments passed, while thinking about the parameters they were to be bound to, and understanding the signature binding process. The strength and weakness of doing things this way is that one is dealing with the raw list of arguments passed, with complete disregard for the parameters, and how particular arguments ended up being paired up with particular parameters, other than one's own thinking about, and understanding of, that process. Given that the whole notion of "omitted" is relative to how individual arguments get bound to individual parameters, direct introspection of arguments is a very fragile and error prone way to detect omission of any particular argument. This approach is only mentioned for completeness sake, and to motivate the other (generally much more sensible) way to detect omission of arguments.

Establishing appropriate defaults for parameters (defaults are used if the signature binding process decides that a corresponding argument was omitted) and then appropriately introspecting and testing to see if a parameter has ended up bound to the default after the signature binding process is complete. The defaults need to be appropriate: they need to be something that cannot be passed as an argument. , (Otherwise you can't tell the difference between an omitted argument and an argument that just happens to match the default.) And the test also needs to be appropriate: it needs to yield True iff the parameter is bound to the default, and not otherwise.

Secondly, I think the word/concept "capture" should be generally avoided as far as possible, perhaps with some text (eg "passed arguments") that links to the capture doc.

sub a (|arguments (@list?)) { say arguments[0].defined }

That was from what I wrote. It was terribly sloppy both because of writing [0] (when it won't contain anything) and relying on .defined then returning False (and .defined being the wrong thing to test in the first place because one will get false positives).

The ? optional marker (or is optional trait) has no effect when a default is specified.

Hmm. I'd express that as something more like setting a default means the same thing as ? but sets an _explicit default rather than relying on the implicit default default.

Note: you can use the tests [] ~~ Empty (True) and {} ~~ Empty (True) to test for the presence of elements within Positional and Associative parameters respectively.

Yeah, it might make sense to mention that in the verbiage preceding a general approach.

An initial installment on a potential PR...
To detect an omitted argument
Simple solution
Give the parameter a default value. Test that the parameter ends up with the default value. If it did, assume the argument was omitted.
If the default value is one that can accidentally be passed, and you don't care about detecting that particular case, i.e. you are OK with assuming that the argument was not passed even though in fact it was, then this simple solution is ideal (because it's simple). For example:
sub foo ($_ = 'NoName') {
    when 'NoName' { say 'no name passed' }
    say "'$_' passed";
 }
foo 'Fred'; # 'Fred' passed
foo; # 'no name passed'

If the default value is one that cannot be passed, accidentally or deliberately, then this solution is again ideal, because it's simple and bullet proof. For example:
# SomeModule.rakumod;
unit module SomeModule;
my role ArgOmitted {}
sub foo ($_ = ArgOmitted) is export {
    when ArgOmitted { say 'no name passed' }
    say "'$_' passed";
 }

# main.raku
use lib '.';
use SomeModule;
foo 'Fred'; # 'Fred' passed
foo; # 'no name passed'
foo 'ArgOmitted'; # 'ArgOmitted' passed
foo ArgOmitted; # Compile time error
}

Complicated solutions
If the above simple solution isn't appropriate, things get more complicated fast.
To recap, the simple solution won't be appropriate in the rather rare case that you want to set a default for a parameter that a caller might pass as a value, but you're just not willing to accept that you then can't distinguish between whether the parameter ended up with that default value due to an argument corresponding to that parameter having actually been passed with that value, or that argument having actually been omitted.
And to add to that recap: are you really sure you want to make your life a lot more fraught? :)
...

To get this issue resolved, would really appreciate it if a PR can be submitted

TL;DR Some more verbiage that might belong in a Simple Solution section.

Raku allows routines to specify that one or more of its parameters (the variables that are in the routine's signature to be available for use in its body) are optional.
(NB. This doesn't mean that those parameters may or may not exist. They exist, no matter what, end of story. What "optional" means is that the designer of the routine is declaring that corresponding arguments may be omitted without that being an error.)
For example:
sub hi ($salutation = 'Hello', :$name = 'World') { say "$salutation $name" }
hi; # Hello World
hi 'Hello'; # Hello World
hi name => 'Gorgeous'; # Hello Gorgeous

Note that the first two invocations had the same result.
What if you wanted to detect whether $salutation was set from a passed argument, or the argument was omitted and the parameter was instead set to the default?
More generally, how do you detect whether an argument was passed in the call, or omitted from the call?
There are several ways to mark one or more parameters in a routine "optional":

Explicitly giving it a default as above. In that case the explicit default is used if an argument corresponding to the parameter is omitted.

Ending it with a ? or  is optional. In that case an implicit default default is used if an argument corresponding to the parameter is omitted.

For example, consider this routine:
sub bye ($salutation = 'Bye cruel', $name?) { say $salutation, " ", $name // 'World' }
bye; # bye cruel World
bye 'see ya', 'seniōre'; # see ya seniōre

In the first call no arguments were passed, so $name was given the implicit default default for a $foo parameter, which is to say (Any). That's why the $name // 'World' worked; it properly dealt with the fact that the $name parameter was optional and the corresponding argument was omitted.

TL;DR Is something like the simple solution verbiage I've posted above adequate as a PR? I think it's plausible that we should not be documenting the complicated case yet, and perhaps ever, other than perhaps briefly outlining options. This may, perhaps should, be coupled with posting a non-doc issue seeking relief through a new Raku(do) feature, in the hope that the new feature is implemented and properly puts this issue to bed, or at least that no one complains about the doc of this aspect for another year or five.
(The new feature would provide a way to introspect whether or not the signature binder bound a parameter to an argument from the call capture. I'd be personally loathe to suggest even filing such a request, and perhaps would downvote adding that complication to Raku(do) but that's just my current view which might change if folk demonstrate that the simple solution I've outlined, perhaps with some verbiage about more complicated solutions, is inadequate.)

I'm closing this issue because it is diverging from a PR.

I agree on the refinement to 'Omitted'.
I agree that Nil is too 'spiky' a default.
I agree that we are not proposing a change to the language at this point.
I see that there are a number of valid concerns implicit in your latest notes - to me the "bullet proof" one is the most material.
Since is past my bedtime, I will come back on your text specifics tomorrow.

Hi @librasteve,
TL;DR My "Final 2¢" response to your "Starter for 10". I'm off on a trip which may mean I barely do any Raku stuff for at least a couple weeks, maybe a month or more. Please feel free to use whatever you like in a real PR, or wait until I get back online. Thanks for pushing things forward and yet being patient while I figured out what feels to me like something close to a decent straw-dog "prePR" based on our exchange.
I've prepared the following "prePR" with the presumption it'll be inserted as a new section in the Signature literals page immediately after the existing Optional and mandatory arguments section. It may need adjusting if it's used, at least in part, but lands elsewhere.
I've written it in GH markdown. If you need to extract it as such but don't have rights to edit my comment, @coke or someone else should be able to get that for you.

Was an argument passed for a parameter?
Table showing tests of whether an argument was passed for a given parameter:

Parameter type
Comment
Idiomatic test

Slurpy, eg *@array
Don't test using .defined
Use eg if @array

Required, eg $foo
Can't be omitted
(not applicable)

Optional, eg @bar = default
Pick a suitable default¹
eg if @bar =:= NotPassed

Table showing results of testing if a parameter is set to its default value:

Default¹
Result of test
Argument was passed?

NotPassed¹
Parameter is not set to its default
Yes

NotPassed¹
Parameter is set to its default
No

'Passable'¹
Parameter is not set to its default
Yes

'Passable'¹
Parameter is set to its default
Maybe²

Footnotes:
¹ A passable default is a value that could actually be passed by a caller, thus partially defeating the ability to tell if an argument was passed via a default check. A not-passed default is a value that cannot be passed by a caller, thus ensuring that a check of it is guaranteed to determine whether or not an argument was passed.²
Example of a passable default value:
sub pass-check (Str $_ = 'Passable') is export {
    when 'Passable' { say 'Unsure if arg was passed' }
    say "$_ passed";
 }
pass-check 'Another string'; # Another string passed
pass-check;                  # Unsure if arg was passed
pass-check 'Passable';       # Unsure if arg was passed

² If you want a guarantee that you can tell for sure whether or not an argument corresponding to an "optional" parameter was passed, then use a not-passed default.¹
Example of a not-passed default value:
module not-passed-default {
  my class NotPassed is Str {}
  sub pass-check(Str $_ = NotPassed) is export {
      when NotPassed { say 'No arg passed, guaranteed' }
      say "$_ passed";
  }
 }
import not-passed-default;
pass-check 'Some string'; # Some string passed
pass-check;               # No arg passed, guaranteed
#pass-check NotPassed;    # Compile error. Code can't pass the module's NotPassed.

@raiph - this is good progress - thanks for providing a polished PR-ready proposal
I have two related points:

I gather that the inclusion of a module / export structure is to wrap the NotPassed value to avoid accidental use elsewhere. I think that this idea is quite complex and, noting that you employ =:= to check for identity, I think that there is a way to avoid that.
I see that you make a [valid] distinction between Passable and NonPassed, I hope that we can use identity to avoid that.

Here's a modified "prePR" with the presumption it'll be inserted as a new section in the Signature literals page immediately after the existing Optional and mandatory arguments section.

Was an argument passed for a parameter?
Table showing checks of whether an argument was passed for a given parameter:

Parameter kind
Example
Comment
Check for no arg passed

Slurpy
*@array
Don't check using .defined
if not @array

Required
$foo
Can't be omitted
(not applicable)

Optional
@bar = default¹
Pick, and check, a suitable default¹
if @bar === default {...}¹

A parameter with a default is always optional, so there is no need to mark it with a ? or the is optional trait.
¹A suitable default is an Object that has a distinct identity, as may be checked by the WHICH method. Then you can use the === value identity operator in the body of the routine to check whether this exact default was bound to the parameter.
In raku, Numeric, Stringy and type object items are identical so they are not suitable for this purpose. We need to pick a default that creates a new object and to declare it as a constant.
Table showing suitable default values for untyped parameters:

Sigil
Type
Default²
Check

$
Scalar
constant AnyAt² = Any.new
if $x === AnyAt {...}

@
Positional
constant PositionalAt² = Positional.new
if @x === PositionalAt {...}

%
Associative
constant AssociativeAt² = Associative.new
if %x === AssociativeAt {...}

²This example uses names like TypeclassAt to reflect that the .WHICH test returns an object of type ObjAt, you are free to make up you own names.
Example with a positional parameter:
constant PositionalAt = Positional.new;

sub a (@list = PositionalAt ) { say @list =:= PositionalAt }
a;              #True
a [1,2,3];      #False

Example with some scalar parameters:
constant AnyAt = Any.new;

sub b ($x=AnyAt, :$y=AnyAt) { say $x === AnyAt, $y === AnyAt }
b 1;            #FalseTrue
b 1,:2y;        #FalseFalse

If your parameters are typed, then the type smileys can be used  with multis like this:
multi sub c (Int:U $z)  { say 'Undefined' }
multi sub c (Int:D $z)  { say 'Defined'   }
multi sub c (Int   $z?) { say 'Omitted'   }
c;              #Omitted
c (Int);        #Undefined
c 42;           #Defined

@librasteve

inclusion of a module / export structure is to wrap the NotPassed value to avoid accidental use elsewhere.

It's to make the NotPassed variant do what it says on the tin. As I'll explain below, your alternate solution doesn't achieve that.
(NotPassed isn't just about "accidental use". It also eliminates abuse, ie malicious code trying to trick code that uses the 'Passable' variant. I'm presuming that, if someone really wants to bother with something as esoteric as checking if arguments got past, it's worth them thinking about protecting against abuse. Or not; they might instead want to allow for "useful abuse", ie benign code trying to trick code that uses the 'Passable' variant, at the risk of malign abuse -- which they might ensure is defended against if indeed it's even possible. Etc.)
But perhaps you knew all that anyway; I just wanted to be clear.

I think that [NotPassed] is quite complex

Yes, very.
In my "first installment" of this "PR" I almost balked at including the concept behind the NotPassed variant at all. That said, it is still conceptually way simpler than some other approaches I thought / suspect the doc might end up discussing.
So I totally get the reaction of "Oh, the children! Can we reduce this complexity?"
There are definitely ways to substantially alter the readers experience of complexity. But for this "Final prePR" I decided to switch to MegaWATT Light Bulb writing.¹ I may have ended up blinding unsuspecting readers! Whether that risk is taken just for this "PR" or an actual PR will be up to you (unless you choose to wait until I get back to this stuff).
That said, I do ask that you and others seriously ponder to what degree it is appropriate to try ratchet back the complexity in this particular case given that it's unavoidable (if someone wants what NotPassed does, even if it's done slightly differently), and mull this conundrum for a good week to see how things feel after that mulling.¹

you employ =:= to check for identity, I think that there is a way to avoid that.

Maybe that was one new thing too many, but to be clear, =:= is dead simple (iiuic).
Aiui it's the simplest of Raku's equality operators, indeed the simplest any PL could have. Aiui it compares the underlying value in RAM and quite literally can't get any simpler.
I may be wrong about that, but I still understand it to be just about the simplest equality operator Raku can support technically (even if, perhaps, not conceptually, because Raku is generally so high level).
But few Rakoons use it, so it becomes one more new thing to learn. "Oh, Raku has a bog standard basic low level equality operator? I didn't know that!". Each new thing to learn can be the straw that breaks the camel's back. (Even if they're a lambdacamel. If one ends up blind, even the best MegaWATT journey ends up sucking.)

Let's distinguish between two things.
First, why is NotPassed so darn complex overall, and why is it presented right out of the gate, in such a terse form? For that, see footnote 1.
Second, why =:=, given it's likely a new operator to a reader? Again, see footnote 1, and discussion of the MegaWATT journey.
So I grant that the whole thing seems super complex. And I get that =:= adds yet another thing.
But I also would like you to reflect on why a Rakoon who is not ready to learn advanced / new things, would have a problem with a section of the doc that's really about an advanced topic?
(I get that one might not think that detecting omitted arguments is an advanced topic, but in most ways it really it is, for reasons I've discussed in earlier comments.)

I see that you make a [valid] distinction between Passable and NonPassed, I hope that we can use identity to avoid that.

Do you mean avoid the distinction?
If so, I think that reflects something I didn't explicitly mention. Consciously. (But perhaps inadvisably? Perhaps I should have mentioned "it" in introducing the "PR"? Or perhaps in the verbiage of the "PR" itself?)
What I mean by "it" is one of the two motivations for covering 'Passable'.
One motivation was was as a stepping stone, or fallback, or starting point, for readers understanding NotPassed, especially if they find NotPassed very complicated.
But the other is that sometimes -- often in fact -- someone wants to set the default to some value that has nothing to do with whether an argument was passed or not. And you can't really set two defaults (one for testing whether an argument was passed, and the other to set the default value used for other purposes). For example, the default might be part of automatically generated API doc. So 'Passable' is going to be a common case.
But then you're inevitably subject to accidents and abuse that trick the 'Passable' variant.
So what to do about that? Well, use the NotPassed variant.
(But then you've lost the ability to use the default in the usual way. So what to do about that? Well, use a Passable variant. But then, well, then you'll ask on IRC and someone will point out that you can directly introspect the capture, but that's incredibly fraught and fragile. I really didn't want that in the doc if we could help it! If we reach the point there's pressure to put that in the doc in this section, it may be time to open an issue for a new Raku(do) feature...)

If you didn't mean "avoid the distinction" but rather avoid =:=, then I think you may have picked the wrong thing to tackle. Yes, it's a new thing, and might be the straw that broke the camel's back, but is it the right thing to focus on?
First, I think it would be better to remove one of the bigger pieces of burden. Perhaps my up-fronting of the NotPassed variant, rather than the 'Passable' variant (in a reversal of my treatment in the earlier "first installment" comment about what became this "PR"), needs to be rereversed.
And/or, perhaps you can come up with some technique that's simpler than a lexically hidden new type. I tried and failed to think of one. Now it's your turn to try!
But also I'm confused about (your view, or perhaps mine, about) =:=:

Also, when writing my examples, I noticed that === is what we want, not =:= ;-)

Why are you saying === is wanted and =:= isn't?
As I understand it === is for comparing a "value type", which is to say values that might not actually be the same, but compare the same nonetheless. I was thinking that that might open things up to spoofing.
(Though perhaps not. The values do have to be the same type, and that may mean =:= and === are ultimately about the same. Though I still think === is a ton more complex. Though it may be more familiar...)
Aiui, =:= just compares two values without interpreting them. Thus:
say 1 =:= 1; # True -- integers are interned, so the two `1`s are the same object reference.
say 'a' =:= 'a'; # True -- small strings are interned, so the two `'a'`s are again the same object.
say 'a' x 1000 =:= 'a' x 1000; # False -- aiui long strings and/or roped strings aren't interned
my $a = 42;
my $b := $a;
say $a =:= $b; # True -- `$a` and `$b` are aliases, and Scalars evaluate to their content

Note the difference:
say 'a' x 1000 === 'a' x 1000; # True -- they're actually different but value compare the same

In raku, Numeric, Stringy and type object items are identical so they are not suitable for this purpose.

I'm not following your logic here.
I do get the logic of the NotPassed variant seeming to be very complicated. Because it is. So I get there's a problem: it's complicated. What I mean is I don't follow your proposed approach to an alternate solution.
The key thing for the NotPassed variant is to introduce a unique value (object, anything Raku code can set as a default, and use in a comparison) that cannot be passed.
Consider your code:
constant PositionalAt = Positional.new;

sub a (@list = PositionalAt) { say @list =:= PositionalAt }
a;              #True
a [1,2,3];      #False

One can abuse this:
constant PositionalAt = Positional.new;

sub a (@list = PositionalAt) { say @list =:= PositionalAt }
a;              #True
a [1,2,3];      #False
a PositionalAt; # True

In the later case, the test says no argument was passed. But one was: PositionalAt.
That was the entire point of NotPassed. You cannot spoof it.

So I would say that's a red herring you pursued.
That said, if so, we should perhaps fall back to why you pursued it.
And that's because NotPassed is complex.
I reacted to all of it getting so complex by being bloody determined to see if I could keep the doc section short, accept the inherent complexity, reduced to its bare minimum, and whack readers with it all in a single fairly short sharp section.
After all, I reasoned, just about no Rakoon should ever want to do this (explicitly check whether an argument was passed), and in the very rare case they did, most should be fine with 'Passable', and in the even rarer case they weren't, they should be fine with the NotPassed variant, and in the incredibly rare case that even that isn't good enough, well, I was thinking we'd cross that bridge if we ever arrive at it.

BTW, in writing this monster comment I've realized I lost another comment I intended to post that outlined why Raku is so good in this respect, and how just about no Rakoon would ever need to even read this doc section, but ended up distilling it into the first table, which implicitly makes the point.
To make it more explicit:

Raku automatically takes care of managing arguments -> parameters so most Rakoons don't need to ever worry about "was an argument passed?".

If it's a slurpy, it gets 0 or more arguments. Just write if @foo if you care to test if any arguments were passed.

If it's a required non-slurpy, it'll get an argument, period.

Even if it's an optional, there should pretty much never be a reason to check if an argument was passed. If it was, the parameter is set to it. If it wasn't the parameter is set to some suitable default. Don't worry about it, and life is fine.

In the incredibly rare case you must know if an argument was passed, and it's a non-slurpy optional, then here's what you can do that's sane: Set default; compare parameter with default.

(And we hopefully avoid mentioning checking captures. Though I had decided we could perhaps reasonably include that. One would have to iterate a signature and capture in parallel, first pairing required positionals and nameds, and then optional positionals, and then optional nameds after first sorting both signature and capture keys. Or something like that.)

A final thing is you reintroducing code that varies between sigils. I think that just makes it seem like you had to introduce that extra stuff because it won't make sense without it, and I think that will make the reader experience worse because they won't realize that you didn't need to add that extra sigil specific stuff.
And to be clear, I don't think you did need to add it. I would expect that any Rakoon reading that section and deciding they wanted to understand it would have all the knowledge they need to figure out how to pick a default (which was distilled into NotPassed, which you'll see is Str, thus laying the intellectual ground for a NotPassed does Positional etc) and then test it via comparison.
That said, I get the impression you just don't see things as I do on that front, and it's time to wrap this Novella.
Peace and love to all, I gotta run and this should be my last word on this topic for the next few weeks at least!
Footnote
¹ First, my overall approach for this so-called "Final prePR" was to maximize the payoff of a "decision" to somewhat reverse what I'd done in my earlier "first installment". In that earlier installment I led the explanation with the 'Passable' variant, which then motivated the NotPassed variant. In this one I somewhat reversed that and/or presented it as one narrative.
Why the reversal / one combined narrative? Well let's assume it doesn't matter, because in a sense it doesn't. Instead what matters is that (it feels to me like) we ought document both.
(If we're going to document this aspect at all; frankly I think this is all pretty advanced stuff that doesn't fit well in doc I'd expose to newbies if I had my druthers. But this issue is predicated on requesting a new piece of doc, and I've chosen not to pushback on the very request itself and instead acquiesce on coming up with a PR to see whether it is ultimately rejected or evolved and merged.)
So then the question becomes, how should they be presented? Focus on 'Passable', which then motivates NotPassed, or vice-versa, or kind of combined as I've done them?
I thought I should take the opportunity to work it through somewhat reversed.
And once I'd done that, i.e. once I'd decided to introduce the fundamentally more complicated concept right up front, I wanted that to pay off for the reader. My hope was that, given that the concept of NotPassed was much more complicated (introduction of a new type, lexically scoping it, trying to convey the, er, import of the lexical scoping, where by "import" I mean "importance") I'd at least be able to keep the explanation of the concept as succinct as possible while still giving enough for a pay off I'll describe in a moment.
And I decided I'd be most likely to generate that payoff if I could guide readers who cared to understand to read code that then hit them up the side the head with not one but four aspects at once (new type, lexical scope, modules, =:=).
Then you and other Rakoons can decide what's best, if indeed y'all agree the overall approach (focus on setting the default to some special value, and testing for that special value) is the way to go.
Second, there's the payoff I'm talking about, the thing I was attempting to maximize. What am I getting at? How could hitting anyone upside the head with lots of concepts simultaneously, none of which seem to have anything to do with figuring out whether an argument was passed, ever be the right thing to do?
Well, I'm not going to go so far as to say it is the right thing to do in this case. One has to be very careful about giving folk a cognitive stretch goal when they didn't ask for it and just wanted a quick answer to their simple question ("Was an argument passed?"). I'm just saying it might be -- because it's important that one takes advantage of teachable moments.
If someone is motivated to read a section titled "Was an argument passed?", then either they're reading it casually, so can just move on if they don't really care, or they want an answer to that specific question, which should motivate them to try figure out what on earth is going on, either by thinking, or by searching around and reading, or by asking around.
So my goal was that pretty much anyone who tried to understand what the doc meant, and why the heck a module turned up of all things, would be in the middle of a "teachable moment" journey that could be, and hopefully is in this "PR", a MegaWATT Light Bulb Trip. That is, they would end up going through something like the following stages:

MegaWAT. "WAT? I thought I was just going to read about how to know if an argument had been passed!

"WTF is going on?" "I should be able to work this out!!!" "In like 10 seconds flat! "Grrr!"

If they know enough Raku, they figure it out. It might take a few minutes before the penny drops, or it might take longer or less time. But they figure it out, and it makes enough sense that they're fairly confident why it is as it is. (They might even think the doc could make that clearer. And they might be right. But there can be negative costs of making the doc more complete, in the mistaken belief that every WTF should be eliminated. But if they're motivated, they can create a PR.) So they figure it out, and a light bulb did eventually light up. It may have lit dimly or brightly, but it did, and then the WTF!?! feeling subsides, evolving into an "Ah, hmm, OK." or perhaps a "Yeah, hmm, that's fairly clean I guess", or maybe "Ah, cool, I get it, and can explain that to someone else".

Or, if they don't know enough Raku, they end up saying "WTF?" or asking WTF is going on.

All of this capitalizes on a teachable moment. In this case it's more complicated than I'd prefer. I introduce declaring a new type (class foo is bar {} declares a new type). And lexical scoping (what { ... } enforces). And modules/imports (controlling how identifiers do or don't escape from a lexical scope). I'm glad that this seemed (almost?) too much to you; it did to me. I pined after some way to simplify the identity aspect, like you did. I fully expect my NotPassed make many Rakoons, especially newbies, glaze over. But then why are they reading this section? If they don't really need to know they'll just move on, perhaps remarking on it to someone, and perhaps benefiting from point 4 above. Conversely, if they really do want or need to know then they are presumably already into fairly advanced Raku notions, and should hopefully be motivated and thus both willing to go on the journey of learning whichever of those three aspects (new type, lexical scope, module/import) they don't already know, and then enjoy the one, two, three, or four Light Bulb switch-on moments I packed into NotPassed.

Do you mean avoid the distinction?

yes

On =:= vs. ===

I looked at this again in a vacuum and I think that, for the examples I proposed, in  this distinction is moot
constant e = Any.new;
constant f = Any.new;

say e =:= f;    #False       \   ... either of these works and both apply `.WHICH` semantics for this sort of object
say e === f;    #False     /

Then I checked your latest and TIL about value internment. Again, in my examples, this is moot since I apply the comparison only to non-interned objects.
So, I agree that =:= is the best comparison operator for our purpose.

In raku, Numeric, Stringy and type object items are identical so they are not suitable for this purpose.

Thanks for your feedback, I will change this phrasing (see below)

On NotPassed

I think your example of possible abuse is at the crux of our disagreement. I repeat it here:
constant PositionalAt = Positional.new;

sub a (@list = PositionalAt) { say @list =:= PositionalAt }
a;              #True
a [1,2,3];      #False
a PositionalAt; # True    <== abuse

The question I am aiming to answer is "how can I detect that an argument was omitted when the sub was called". And not "how can I prevent malicious code from ever passing an argument without my being able to check for this". I am not saying that the latter would never be needed, just that this is an advanced topic that we do not need in the general docs.
My answer is somewhat resistant to this vector of abuse in that [if we use my constant] we can confine "access" to the information of the actual ID of our selected PositionalAt to the scope and then have a fairly robust way to prevent external code (eg. from a web frontend, API, file, external module) from being able to make the same PositionalAt.
I would be happy to see your NotPassed example in an SO question - but I do think it goes too far in terms of advancing the topic.

Updated (and hopfully final) PrePR in the next comment....

Updated (and hopfully final) PrePR...

Was an argument passed for a parameter?
Table showing checks of whether an argument was passed for a given parameter:

Parameter kind
Example
Comment
Check for no arg passed

Slurpy
*@array
Don't check using .defined
if not @array

Required
$foo
Can't be omitted
(not applicable)

Optional
@bar = default¹
Pick, and check, a suitable default¹
if @bar === default {...}¹

A parameter with a default is always optional, so there is no need to mark it with a ? or the is optional trait.
Footnotes:
¹A suitable default is an Object that has a distinct identity, as may be checked by the WHICH method. Then you can use the =:= container identity operator in the body of the routine to check whether this exact default was bound to the parameter.
Example with a positional parameter:
my constant PositionalAt = Positional.new;

sub a (@list = PositionalAt) { say @list =:= PositionalAt }
a;              #True
a [1,2,3];      #False

Example with some scalar parameters:
my constant AnyAt = Any.new;

sub b ($x=AnyAt, :$y=AnyAt) { say $x =:= AnyAt, $y =:= AnyAt }
b 1;            #FalseTrue
b 1,:2y;        #FalseFalse

If your parameters are typed, then the type smileys can be used  with multis like this:
multi sub c (Int:U $z)  { say 'Undefined' }
multi sub c (Int:D $z)  { say 'Defined'   }
multi sub c (Int   $z?) { say 'Omitted'   }
c;              #Omitted
c (Int);        #Undefined
c 42;           #Defined

The examples use names like TypeclassAt to reflect that the .WHICH test returns an object of type ObjAt, you are free to make up you own names.

@gfldex ... I have reopened the issue so we don't ignore you suggestion
in defence of the current "final prePR" [fppr] proposal:

a single method to detect omitted arguments across all sigil cases is desirable
the fppr doesn't initially introduce types since we need an answer for untyped parameters anyway
the solution is generally easier for typed parameters, as can be seen from the fppr multi examples
the multi example is close to yours - however ::T type captures are quite an advanced topic


[api-minor] Replaces UnsupportedManager with callback.

UnsupportedManager is only global variable we are using and blocks SharedWorker refactoring. This PR deprecated this API and (temporary?) replaces with PDFDocumentLoadingTask callback.
I don't think we need to use it at the error() function -- we need to pass or exception to the UI via promises, or handle them in the evaluator and send UnsupportedFeature message if needed.

/botio-linux preview

I've just tested the built (Firefox) extension, and the fallback bar is no longer shown for e.g. the PDF files in issues #3795 and #6342. Is that really intended, or does it point to a bug in the PR?

the fallback bar is no longer shown for e.g. the PDF files in issues #3795 and #6342.

I don't think we shall show a warning bar in this case, we know how to workaround those bad cases and we can resume properly. However, we might trigger that bar for cases, e.g. when fonts are corrupted, but in this case we know the reason.

TODO:

[ ] add fallback in #6697 case


Deleting a non-existing resource should succeed

Delete of run schedule should succeed if the schedule has somehow been directly removed from within Vertex AI.
Currently if schedule doesnt exist the delete workflow fails and the resource stays in a state of "deleting"

Tested deleting a pipeline after emptying gcs manually and delete is fine. It seams to just be the schedule issue.


Use minus for pagination when watching

This PR removes the home-grown machinery for showing the typst watch output and uses the minus pager instead.
That especially means scrolling the output is now possible.
I also added a new --pager option that behaves similarly to --color.
By default, the pager is only used for watching and when colors are enabled (implicitly or explicitly). Depending on preferences, users can use --pager=always or --pager=never.
With this PR, there is now a bar with the command displayed at the bottom:

It could be disabled via minus::Pager::show_prompt, but there is a slight display bug in that case, so I embraced it and put the entire command there.
Fixes #3613.

I have merged https://github.com/typst/typst/pull/3648 for 0.11 because this feels a bit too dangerous to add post-RC (with the amount of new code and new dependencies introduced). Let's proceed with this after the release and ship the alternate screen in 0.12 instead!

Closing due to inactivity. Feel free to reopen if you still want to work on this!


BUG: scipy==1.8.0 doesn't install on MacOS M1, because numpy==1.20.0 cannot be built

Describe your issue.
Installing scipy==1.8.0 fails on MacOS M1 with python3.9, because the build requires numpy 1.20.0 that doesn't build on M1 (https://github.com/scipy/scipy/blob/v1.8.0/pyproject.toml#L30)
Can someone please update this is make it really a minimum requirement to use 1.20.0 and not a hard requirement? So have numpy >= 1.20.0 and not numpy == 1.20.0. Even better would be 1.20.3, which does install on M1. At the moment, no matter if I pre-install the latest version of numpy, the install for scipy fails, because it is trying to get numpy==1.20.0 to be installed.
Reproducing Code Example
pip install scipy

Error message
Collecting scipy==1.8.0
  Using cached scipy-1.8.0.tar.gz (38.3 MB)
  Installing build dependencies ... error
  error: subprocess-exited-with-error

  × pip subprocess to install build dependencies did not run successfully.
  │ exit code: 1
  ╰─> [2270 lines of output]
      Looking in indexes: https://pypi.org/simple, https://artefact.skao.int/repository/pypi-internal/simple
      Ignoring numpy: markers 'python_version == "3.8" and platform_machine == "aarch64" and platform_python_implementation != "PyPy"' don't match your environment
      Ignoring numpy: markers 'python_version == "3.8" and platform_machine == "arm64" and platform_system == "Darwin"' don't match your environment
      Ignoring numpy: markers 'python_version == "3.8" and platform_machine == "s390x" and platform_python_implementation != "PyPy"' don't match your environment
      Ignoring numpy: markers 'python_version == "3.8" and (platform_machine != "arm64" or platform_system != "Darwin") and platform_machine != "aarch64" and platform_machine != "s390x" and platform_python_implementation != "PyPy"' don't match your environment
      Ignoring numpy: markers 'python_version == "3.9" and (platform_machine != "arm64" or platform_system != "Darwin") and platform_python_implementation != "PyPy"' don't match your environment
      Ignoring numpy: markers 'python_version == "3.10" and platform_python_implementation != "PyPy"' don't match your environment
      Ignoring numpy: markers 'python_version >= "3.11"' don't match your environment
      Ignoring numpy: markers 'python_version >= "3.8" and platform_python_implementation == "PyPy"' don't match your environment
      Collecting wheel<0.38.0
        Using cached wheel-0.37.1-py2.py3-none-any.whl (35 kB)
      Collecting setuptools<60.0.0
        Using cached setuptools-59.8.0-py3-none-any.whl (952 kB)
      Collecting Cython<3.0,>=0.29.18
        Using cached Cython-0.29.28-py2.py3-none-any.whl (983 kB)
      Collecting pybind11<2.9.0,>=2.4.3
        Using cached pybind11-2.8.1-py2.py3-none-any.whl (208 kB)
      Collecting pythran<0.11.0,>=0.10.0
        Using cached pythran-0.10.0-py3-none-any.whl (4.3 MB)
      Collecting numpy==1.20.0
        Using cached numpy-1.20.0.zip (8.0 MB)
        Installing build dependencies: started
        Installing build dependencies: finished with status 'done'
        Getting requirements to build wheel: started
        Getting requirements to build wheel: finished with status 'done'
        Preparing metadata (pyproject.toml): started
        Preparing metadata (pyproject.toml): finished with status 'done'
      Collecting gast~=0.5.0
        Using cached gast-0.5.3-py3-none-any.whl (19 kB)
      Collecting ply>=3.4
        Using cached ply-3.11-py2.py3-none-any.whl (49 kB)
      Collecting beniget~=0.4.0
        Using cached beniget-0.4.1-py3-none-any.whl (9.4 kB)
      Building wheels for collected packages: numpy
        Building wheel for numpy (pyproject.toml): started
        Building wheel for numpy (pyproject.toml): finished with status 'error'
        error: subprocess-exited-with-error

        × Building wheel for numpy (pyproject.toml) did not run successfully.
        │ exit code: 1
        ╰─> [2223 lines of output]

[... the error is very long but not really relevant for scipy ...]

                assert len(base_version) == 2
            AssertionError

            ########### EXT COMPILER OPTIMIZATION ###########
            Platform      :
              Architecture: aarch64
              Compiler    : clang

            CPU baseline  :
              Requested   : 'min'
              Enabled     : NEON NEON_FP16 NEON_VFPV4 ASIMD
              Flags       : none
              Extra checks: none

            CPU dispatch  :
              Requested   : 'max -xop -fma4'
              Enabled     : ASIMDHP ASIMDDP
              Generated   :
                          :
              ASIMDHP     : NEON NEON_FP16 NEON_VFPV4 ASIMD
              Flags       : -march=armv8.2-a+fp16
              Extra checks: none
              Detect      : ASIMD ASIMDHP
                          : numpy/core/src/umath/_umath_tests.dispatch.c
            CCompilerOpt._cache_write[796] : write cache to path -> /private/var/folders/3n/68py6wjs1t7dqlglcvwgvrcr0000gp/T/pip-install-pfa3d0mq/numpy_b0c1897da5564dec984ac45053f20aa5/build/temp.macosx-11-arm64-3.9/ccompiler_opt_cache_ext.py

            ########### CLIB COMPILER OPTIMIZATION ###########
            Platform      :
              Architecture: aarch64
              Compiler    : clang

            CPU baseline  :
              Requested   : 'min'
              Enabled     : NEON NEON_FP16 NEON_VFPV4 ASIMD
              Flags       : none
              Extra checks: none

            CPU dispatch  :
              Requested   : 'max -xop -fma4'
              Enabled     : ASIMDHP ASIMDDP
              Generated   : none
            CCompilerOpt._cache_write[796] : write cache to path -> /private/var/folders/3n/68py6wjs1t7dqlglcvwgvrcr0000gp/T/pip-install-pfa3d0mq/numpy_b0c1897da5564dec984ac45053f20aa5/build/temp.macosx-11-arm64-3.9/ccompiler_opt_cache_clib.py
            [end of output]

        note: This error originates from a subprocess, and is likely not a problem with pip.
        ERROR: Failed building wheel for numpy
      Failed to build numpy
      ERROR: Could not build wheels for numpy, which is required to install pyproject.toml-based projects
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error

SciPy/NumPy/Python version information
scipy 1.8.0, numpy 1.22.3, python 3.9.9

Hi @gabicca, I remember someone reporting this already. The issue is that your version of osx is too old.

Can you confirm it is the same issue as in gh-15861?

Hi @tupui
My error is different from the one reported in the link. The error is coming from the fact that scipy is forcing pip to install numpy 1.20.0 instead of allowing for the latest numpy. Numpy 1.20.0 doesn't install on M1.
The link I gave you indeed is about building scipy and that is exactly where the error is coming from. Scipy should allow for more recent versions of numpy, like it says in the comment ("# arm64 on Darwin supports Python 3.8 and above requires numpy>=1.20.0") not fixing the version of numpy at 1.20.0

@tupui , ok so that makes more sense then. I don't get the wheel because I'm on BigSur and hence pip is trying to build it, which then encounters the problem of the fixed numpy version.
Thanks for the help. I'll get to upgrading it at some point and then hopefully it'll work.

Ok thank you for confirming. I will close this issue as it's then a duplicate of gh-15861


Gradle is taking so long to get Rovovm

Hi the gradle is taking so long to setup because of that rovovm

Gradle will download dependencies when you import the project, you will not have to download them again. The speed naturally depends on your Internet connection.
This is not an actual issue.


405 error.. looks like malformed request url

hey
I've followed the instructions and deployed to production, but when I view it, there's a 405 error for the POST to the lambda endpoint. It doesn't look correct, see here:

I set the URL in security.env.prod correctly I think?
URL="https://k6e3zyqa61.execute-api.us-east-1.amazonaws.com/production/graphql"
What am I doing wrong?
cheers!

hey @str3tch - not sure if you have fixed it, but remove the ", so:
URL=https://k6e3zyqa61.execute-api.us-east-1.amazonaws.com/production/graphql < - should work.

@str3tch is this issue resolved? We have updated this repo. can you please try again?

Your apollo client must have the right remote URL.


Transparency

Can I disable the blurred effect and use a transparency effect instead?

I think that you're limiting this great control with blurred effect. I think this effect can be only a option. To disable the blurred effect I had to comment the lines 251-254.
/let visualEffectView = UIVisualEffectView(effect: UIBlurEffect(style: .Light)) as UIVisualEffectView
visualEffectView.frame = sideMenuContainerView.bound
visualEffectView.autoresizingMask = [.FlexibleHeight, .FlexibleWidth]
sideMenuContainerView.addSubview(visualEffectView)/
But this is not a good practice. Maybe you can put the blurred effect as a Boolean property in the controller.


Feature/game logic

First week sprint task: initial game logic for math section of game

TY y'all, looks great!


Settings for the folder Quick access

It seems that WinSetView settings in win10.ini are not taken into account by the powershell script WinSetView.ps1 to create the WinSetView2.reg.
Win.ini:
ColumnList=0,34,ItemNameDisplay;0,,ItemFolderPathDisplay
GroupBy=
WinSetView2.reg after execution of WinSetView.ps1:
"ColumnList"="prop:0(34)System.ItemNameDisplay"
"GroupBy"="System.Home.Grouping"
This results in an incorrect display of the columns and folders grouping in the explorer.exe
Column: Only name of the folders
Grouping: Most frequent folders
Manual intervention in the WinSetView2.reg with the correct settings gives the correct display in the explorer.exe:
"ColumnList"="prop:0(34)System.ItemNameDisplay;0System.ItemFolderPathDisplay"
"GroupBy"=""

Working as intended. As of version 2.72, grouping for Home/Quick Access is always set to "group". The latest version of File Explorer (available in Canary build) crashes if Home/Quick Access is not grouped. It's also kind of strange to not group that folder because then you'll have pinned items mixed with most recent items.

Your detailed use case convinces me that I should add an option. Ideally I should detect if the new File Explorer is in use, but I could find no way to do that, other than finding a redirected CLSID that is likely to change in the future. So, I think I'll add a check box in the Options menu (in Advanced mode) in the next update.

In the meantime, you can use version 2.73 by commenting out or removing the following lines (lines 434-437) in WinSetView.ps1:
      If ($FT -eq 'HomeFolder') {
        $GroupBy = 'Home.Grouping'
        $GroupByOrder = '+'
      }

Good workaround. I test it and it is ok. I think the new option in advanced mode is a good solution, so many people seeming to dislike the group by option of the explorer.exe. Thanks.

WinSetView 2.74 now includes the advanced mode option we discussed.


Add shape sensitivity to the thermal module

Adds shape displacement capabilities to the thermal module
Refactors the thermal module to use a single Functional residual object
Fixes a bug in the FiniteElementVector assignment operator to keep it from swapping out the associated FiniteElementSpace
Removes the redundant mesh input in the FiniteElementSpace-based FiniteElementVector constructor
Refactors the thermal materials to directly return heat capacity and thermal flux

Codecov Report

Merging #840 (a252844) into develop (a300c9c) will decrease coverage by 0.06%.
The diff coverage is 95.86%.

@@             Coverage Diff             @@
##           develop     #840      +/-   ##
===========================================
- Coverage    95.04%   94.97%   -0.07%
===========================================
  Files          142      143       +1
  Lines         9437     9526      +89
===========================================
+ Hits          8969     9047      +78
- Misses         468      479      +11

Impacted Files
Coverage Δ

src/serac/numerics/functional/tensor.hpp
93.40% <0.00%> (-2.37%)
:arrow_down:

src/serac/physics/heat_transfer.hpp
98.36% <97.10%> (-1.06%)
:arrow_down:

src/serac/physics/solid_mechanics.hpp
99.19% <100.00%> (ø)

src/serac/physics/tests/thermal_shape.cpp
100.00% <100.00%> (ø)

src/serac/physics/thermomechanics.hpp
98.14% <100.00%> (ø)

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

Static patch test is done and passing.

There is something weird going on in the CI, so I will investigate this afternoon.


How to test against UploadFile parameter

First check

[ ] I added a very descriptive title to this issue.
[ ] I used the GitHub search to find a similar issue and didn't find it.
[ ] I searched the FastAPI documentation, with the integrated search.
[ ] I already searched in Google "How to X in FastAPI" and didn't find any information.
[ ] I already read and followed all the tutorial in the docs and didn't find an answer.
[ ] I already checked if it is not related to FastAPI but to Pydantic.
[ ] I already checked if it is not related to FastAPI but to Swagger UI.
[ ] I already checked if it is not related to FastAPI but to ReDoc.
[ ] After submitting this, I commit to one of:

Read open issues with questions until I find 2 issues where I can help someone and add a comment to help there.
I already hit the "watch" button in this repository to receive notifications and I commit to help at least 2 people that ask questions in the future.
Implement a Pull Request for a confirmed bug.

Example
Here's a self-contained, minimal, reproducible, example with my use case:

from fastapi import FastAPI

router = FastAPI()

@router.post("/_config")
def create_index_config(upload_file: UploadFile = File(...)):

    config = settings.reads()
    created_config_file: Path = Path(config.config_dir, upload_file.filename)

    try:
        with created_config_file.open('wb') as write_file:
            shutil.copyfileobj(upload_file.file, write_file)

    except Exception as err:
        raise HTTPException(detail=f'{err} encountered while uploading {upload_file.filename}',
                            status_code=HTTPStatus.INTERNAL_SERVER_ERROR)
    finally:
        upload_file.file.close()

    return JSONResponse({"message": f'uploaded config {upload_file.filename}'})

Description
I'm just trying to test against an endpoint that uses uploadfile and I can't find how to send a json file to fastapi
def test_one():
  _test_upload_file = <path to file>
 with TestClient(app) as client:
        # TODO how to upload a file
        response = client.post('/_config',
                               data= <assuming something goes here ???> )
        assert response.status_code == HTTPStatus.CREATED

Environment

OS: [e.g. Linux / Windows / macOS]: OSX/docker
FastAPI Version [e.g. 0.3.0]: fastapi==0.54.1
Python version: Python 3.6.8

Additional context

data=_test_upload_file.open('rb') yields a 422 error
I have also tried this and get a 422 error

I've solved this yesterday on gitter. Could you search for "UploadFile" there? I'm busy now. I can post it here later if I remember.. or you can check there and post the solution here as well to help others.

Here you have: https://stackoverflow.com/questions/60783222/how-to-test-a-fastapi-api-endpoint-that-consumes-images
Example:
fpath = os.path.join("/tmp/upload", file.filename)
with open(fpath, "wb") as f:
    response = client.post(
        "/", files={"file": ("filename", f, "image/jpeg")}
    )

Here you have: https://stackoverflow.com/questions/60783222/how-to-test-a-fastapi-api-endpoint-that-consumes-images
Example:
with open(fpath, "wb") as f:
    response = client.post("/", files={"file": ("filename", f, "image/jpeg")})

I saw that but couldn't get it to work with my application
On gitter I found this
def test_upload(tmp_path):
    url = app.url_path_for("create_upload_files")
    with TestClient(app) as client:
        f = tmp_path / 'fileupload'
        with open(f, 'wb') as tmp:
            tmp.write(b'upload this')
        with open(f, 'rb') as tmp:
            files = {'files': tmp}
            response = client.post(url, files=files)
            assert response.status_code == 200

But that gives a 422 error when I try it in my code
    with TestClient(app) as client:
        # TODO how to upload a file
        with _test_upload_file.open('rb') as tmp:
            files = {'files': tmp}
            response = client.post('/_config',
                               files=files)
            assert response.status_code == HTTPStatus.CREATED

Big dumb on my part..
Working test:
_test_upload_file = Path('/usr/src/app/tests/files', 'new-index.json')
    _files = {'upload_file': _test_upload_file.open('rb')}
    with TestClient(app) as client:
        response = client.post('/_config',
                                files=_files)
        assert response.status_code == HTTPStatus.CREATED

    # remove the test file from the config directory
    _copied_file = Path('/usr/src/app/config', 'new-index.json')
    _copied_file.unlink()

I previously had the upload_file in the test named files -- FYSA that name must match the parameter of your endpoint, in my case it's upload_file so files wasn't working

Follow up with the code from Gitter also worked, thanks :)

Thanks for the help here @Kludex ! :clap: :bow:
Thanks for reporting back and closing the issue @mwilson8  :+1:

Here you have: https://stackoverflow.com/questions/60783222/how-to-test-a-fastapi-api-endpoint-that-consumes-images
Example:
with open(fpath, "wb") as f:
    response = client.post("/", files={"file": ("filename", f, "image/jpeg")})

This didn't work for me. I had to change the with open(fpath, "wb") as f to with open(fpath, "rb") as f:
Using read instead of write operation here works :)

A slight follow up, how do you test against the actual function as opposed to the endpoint?
Working test against the endpoint:
_test_upload_file = Path('filepath')
    _files = {'upload_file': _test_upload_file.open('rb')}
    with TestClient(app) as client:
        response = client.post('/_config',
                               files=_files,
                               )
    assert response.status_code == HTTPStatus.OK

But I also want to test with
response = service.function_within_endpoint(upload_file=<...what goes here...>)

Have you tried passing an instance of UploadFile?

Have you tried passing an instance of UploadFile?

I had to switch to the httpx.AsyncClient approach as specified here to pass an UploadFile instance, since reading an UploadFile is an async operation

A slight follow up, how do you test against the actual function as opposed to the endpoint?
Working test against the endpoint:
_test_upload_file = Path('filepath')
    _files = {'upload_file': _test_upload_file.open('rb')}
    with TestClient(app) as client:
        response = client.post('/_config',
                               files=_files,
                               )
    assert response.status_code == HTTPStatus.OK

But I also want to test with
response = service.function_within_endpoint(upload_file=<...what goes here...>)

This code doesn't work for me.
   def test_put(self):
       filepath = ".\\image.jpeg"
       with open(filepath, "rb") as f:
           response = self.client.put('/frame/',
                                      files={'upload_file': f},
                                      headers={'accept': 'application/json', 'Content-Type': 'multipart/form-data'})
       self.assertEqual(response.status_code, 200)

But my function should get a list of UploadFile:
async def add(files: List[UploadFile] = File(...), db: Session = Depends(get_db)):

Any ideas how can I test it?

Hi, I would like to test UploadFile with its extension. In my situation, sending an input file works fine but, its content_type is an empty string. How can I ensure that the content_type must exist?
Here is my code.

test_app.py

def test_validate_image(self):
  client = TestClient(app)
  files = {"image": open("path/to/image.jpg", "rb")}
  response = client.post("/validate/", files=files)

app.py

@app.post("/validate/")
async def validate_image(image: UploadFile = File(...)):
  # Some other code
  return {
        "filename": image.filename,
        "content_type": image.content_type,
    }

The result looks like the following below
{"filename": "image.jpg", "content_type":  ""}

Even I am facing the same problem
Code  to upload a tarred file
@router.post("/upload_container")
async def post_container(file: UploadFile):
    if file.content_type != "application/x-tar":
        raise HTTPException(status_code=400, detail="Can only accept tarred version of Docker file")
    return {"filename" : file.filename}

Test case for the code
def test_add_docker():
    _files = {'file.tar':open('file.tar', 'rb')}

    response = client.post("/upload_container", files=_files)
    assert response.status_code == HTTPStatus.OK

Error I received
`E       assert 422 == <HTTPStatus.OK: 200>
E        +  where 422 = <Response [422]>.status_code
E        +  and   <HTTPStatus.OK: 200> = HTTPStatus.OK

test/test_post_container.py:66: AssertionError`

A slight follow up, how do you test against the actual function as opposed to the endpoint?
Working test against the endpoint:
_test_upload_file = Path('filepath')
    _files = {'upload_file': _test_upload_file.open('rb')}
    with TestClient(app) as client:
        response = client.post('/_config',
                               files=_files,
                               )
    assert response.status_code == HTTPStatus.OK

But I also want to test with
response = service.function_within_endpoint(upload_file=<...what goes here...>)

A bit late, but I was just attempting to do this same thing as well and came across your comment.  This is how I accomplished what you had asked:
import os
import shutil
from tempfile import SpooledTemporaryFile
from fastapi import FastAPI, UploadFile

app = FastAPI()

async def upload_file(file_path: str):

	tmp_file = SpooledTemporaryFile()

	with open(file_path, "rb") as path:
		tmp_file.write(path.read())

	_ = tmp_file.seek(0)

	file = UploadFile(filename=os.path.split(file_path)[1], file=tmp_file)

	await upload(file)

@app.post("/upload")
async def upload(file: UploadFile):

	pkg_dir = os.path.abspath(os.path.join(os.path.abspath(os.path.dirname(__file__)), os.pardir))

	try:
		with open(f"{pkg_dir}/static/{file.filename}", "wb") as create_file:
			shutil.copyfileobj(file.file, create_file)
	finally:
		file.close()

	return { "results":  200, "file": file.filename }

This may not be the (most) correct way, but it works.  Hopefully it'll help someone else one day.

This code works for me, I am sending multiple csv's to an endpoint which receives a list of UploadFile 🥇 🥇 🥇
import json
import uvicorn
from fastapi.testclient import TestClient
from dotenv import load_dotenv

load_dotenv()
from main import app

client = TestClient(app)

def test_user_profiles_csv():
files = [("files", open("profiles_csv_1.csv", "rb")),
         ("files", open("profiles_csv_2.csv", "rb"))]

response = client.post(
    "/api/v1/profiles/csv",
    files=files,
    headers={"Authorization": f"Bearer {get_access_token()}"},
)
assert response.status_code == 201

if __name__ == "__main__":
    uvicorn.run(app, host="<IP_ADDRESS>", port=8000)

Thanks for the discussion everyone! With regards to @mwilson8's second question about testing the function directly, passing an instance of UploadFile as suggested by @Mause worked? I would imagine it did. Also, in that case, it would be just testing functions, it wouldn't really have much to do with FastAPI in that case. If your questions/use cases are solved now, then you can close the issue. 🤓
For other questions from others, if you still haven't found a solution to your questions, as they vary a bit, please create a new issue, with a self-contained example, etc. Thanks! ☕


Add IOBinding for ORTModelForVision2Seq

Feature request
Add IOBinding support for ORTModelForVision2Seq
Motivation
Priority model for inference
Your contribution
Will add the support

Also tagging @IlyasMoutawwakil, as he tested with it yesterday!

@mht-sharma wile trying to solve it I found that the problem was in an output axis name that couldn't be inferred and wasn't in the in dimensions. It's name is encoder_sequence_length. As a quick patch I added it to dimensions when possible here:
if ("height" in dimensions) and ("width" in dimensions) and hasattr(self.config, "encoder"):
    dimensions["encoder_sequence_length"] = dimensions["height"] * dimensions["width"] // self.config.encoder.hidden_size

Not sure this is the best way to do it.


Added artisan:optimize command and automatically optimize Laravel deployments

Q
A

Bug fix?
No

New feature?
Yes

BC breaks?
No

Deprecations?
No

Fixed tickets
N/A

This will add a artisan:optimize command and also automatically optimize deployments. Laravel has an internal list of classes which the framework will add in one file to optimize performance - this is separate from composer's optimize autoloader.

Which laravel version?

Which laravel version?

Laravel has always had the optimize command.

Suprisingly it's not very well documented, never has been but it's been there since 4.*. Here's the command as found in 5.1: https://github.com/laravel/framework/blob/5.1/src/Illuminate/Foundation/Console/OptimizeCommand.php#L19
It's recommended to run this when you deploy as it makes a big difference for performance.

Just FYI - this has been a composer post install / post update script since at least v5.0 (didn't check earlier).
https://github.com/laravel/laravel/blob/master/composer.json
So, explicit execution may not be needed and could actually cause issues if run after the symlink swap takes place.

@pdbreen that's true, on second thoughts for default Laravel installs this PR isn't really needed.


Update to 4.0.0

I've checked out cling-patches branch cern repo and rebased onto release_40 branch from the official mirror.
The result can be seen here: https://github.com/gqmelo/llvm/compare/release_40...gqmelo:cling-patches-4.0
The patches updated here were obtained from this rebased branch.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Gentle pinging mantainers ;)
@inducer @pitrou @jakirkham @mingwandroid @mattwala @SylvainCorlay

Are there corresponding PRs for clang and libcxx?

Looks good to me otherwise.

Are there corresponding PRs for clang and libcxx?

Not yet, as the packages that depend on llvm pin to 3.9 I thought about building llvm first. Also there are the cling patches applied to clang which are much more numerous and I don't know if it will as easy to port.
But I can try to build them locally before merging this PR.

Nah, let's get this moving and see what happens. Thanks for your contribution--and it would be fantastic if you could start on bringing the other packages (especially clang) up to 4.0.

Thanks!, I'll try to find some time next week to update clang


Import/Export world and rework MyLearningWorldsOverview

Closes #367
Closes #368
Closes #425
Fixes #252

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

72 of 94 (76.6%)  changed or added relevant lines in 14 files are covered.
22 unchanged lines in 4 files lost coverage.
Overall coverage increased (+0.5%) to 89.956%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

BusinessLogic/ErrorManagement/DataAccess/HashExistsException.cs
2
3
66.67%

DataAccess/API/DataAccess.cs
15
16
93.75%

BusinessLogic/Commands/World/SaveLearningWorld.cs
6
8
75.0%

DataAccess/Persistence/ContentFileHandler.cs
0
4
0.0%

Presentation/PresentationLogic/MyLearningWorlds/MyLearningWorldsProvider.cs
6
12
50.0%

BusinessLogic/API/BusinessLogic.cs
0
8
0.0%

Files with Coverage Reduction
New Missed Lines
%

Presentation/View/MyLearningWorlds/MyLearningWorldsOverview.razor
2
88.0%

Configuration/ApplicationPaths.cs
4
16.67%

Presentation/PresentationLogic/MyLearningWorlds/MyLearningWorldsProvider.cs
7
50.0%

Presentation/PresentationLogic/API/PresentationLogic.cs
9
96.23%

Totals

Change from base Build<PHONE_NUMBER>:
0.5%

Covered Lines:
12010

Relevant Lines:
13351

💛  - Coveralls


Custom root type ignores Field.alias on parse_obj and from_orm

Checks

[x] I added a descriptive title to this issue
[x] I have searched (google, github) for similar issues and couldn't find anything
[x] I have read and followed the docs and still think this is a bug

Bug
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
             pydantic version: 1.8.2
            pydantic compiled: True
                 install path: /home/alexandr/projects/examples/.venv/lib/python3.7/site-packages/pydantic
               python version: 3.7.9 (default, Oct  1 2020, 09:36:30)  [GCC 9.3.0]
                     platform: Linux-5.4.0-72-generic-x86_64-with-debian-bullseye-sid
     optional deps. installed: ['dotenv', 'email-validator', 'typing-extensions']

from pydantic import BaseModel, Field

class IdOnly(BaseModel):
    __root__: int = Field(..., alias='id')

    class Config:
        orm_mode = True

class Item:
    id = 1

if __name__ == '__main__':
    print(repr(IdOnly(id=1)))  # IdOnly(__root__=1)

    print(repr(IdOnly.parse_obj({'id': 1})))  # ValidationError(id missing)
    print(repr(IdOnly.from_orm(Item())))  # ValidationError(id missing)

@alk3mist thank you for the bug report. Could you please confirm that the bug is still relevant in Pydantic v2?


Using a pretrained model checkpoint for image classification

I want to use a pretrained model checkpoint for image classification.
The problem I am trying to solve has different classes and bounding boxes don't matter. In particular, I do not have that much training data.
This is why I want to define my own head but use a pretrained backbone and neck. I have a few questions about the model architecture and implementation in mmdet.
I am able to load a given model checkpoint, for example FCOS X-101 from here, with the high level api methods. Furthermore, I can get the features from the pretrained backbone and neck as follows:
model = init_detector(configFile, checkpointFile, device='cuda:0')
image = torch.randn(1, 3, 256, 256).cuda()
features = model.extract_feat(image)
# how to get from features to n class predictions?

Inspection of the feature object reveals that it is a list of five tensors. In a regular neural network, I would expect a single tensor instead of a list.
Is this because FCOS is a feature pyramid network? How is a single class prediction computed from this list?
How can I design my own head that just predicts class probabilities for n classes? Should I just delete the bbox and centerness properties from the fcos_head?
For example, would adding a pooling layer, flattening the results and using some kind of fully connected head be a valid alternative? How would I handle the features in that case, since I can not apply pooling to the list directly?

Please refer to the implementation of classifier in mmclassification.


Cannot get EnumServiceProvider to populate enums to frontend state

This is  a bug | feature request.

Prerequisites

[x ] Are you running the latest version?
[ x] Are you reporting to the correct repository?
(enso is made of many specialized packages: https://github.com/laravel-enso)
[ x] Did you check the documentation?
[ ] Did you perform a cursory search?

Description

Steps to Reproduce
<!--
1. First Step
<?php

namespace App\Providers;

use LaravelEnso\Enums\EnumServiceProvider as ServiceProvider;

use App\Enums\QuotationStatus;

class EnumServiceProvider extends ServiceProvider
{
    public $register = [

        'quotationStatus' => QuotationStatus::class,
    ];
}
--------------------------------------------------------------------------
namespace App\Enums;

use LaravelEnso\Enums\App\Services\Enum;

class QuotationStatus extends Enum
{

    public const new = 1;
    public const pending = 2;
    public const booked = 3;
    public const lost = 4;
    public const canceled = 5;

    protected static function data(): array
    {
        return [
            static::new => 'New',
            static::pending => 'Pending',
            static::booked => 'Booked' ,
            static::lost => 'Lost',
            static::canceled => 'Canceled',
        ];
    }
}

What steps did you take?

I created 2 files.
namespace App\Enums;
use LaravelEnso\Enums\App\Services\Enum;
class QuotationStatus extends Enum
{
public const new = 1;
public const pending = 2;
public const booked = 3;
public const lost = 4;
public const canceled = 5;

protected static function data(): array
{
    return [
        static::new => 'New',
        static::pending => 'Pending',
        static::booked => 'Booked' ,
        static::lost => 'Lost',
        static::canceled => 'Canceled',
    ];
}

}
 QuotationStatus::class,
    ];
}

Name your constants "New, Pending, Booked" etc and you don't need the data() method. You need that method only if the constants are different from the labels you want to display in places of the app.
What is the other file?
What is

QuotationStatus::class, ]; }

 QuotationStatus::class,
    ];
}

namespace App\Providers;
use LaravelEnso\Enums\EnumServiceProvider as ServiceProvider;
use App\Enums\QuotationStatus;
class EnumServiceProvider extends ServiceProvider
{
public $register = [
    'quotationStatus' => QuotationStatus::class,
];

}

Did you register the service provider?

that is probably what I need to know. HOw to do that ?

read the docs

very good. It works now

Thanks for your help


python311Packages.pycfdns: 2.0.1 -> 3.0.0

Diff: https://github.com/ludeeus/pycfdns/compare/refs/tags/2.0.1...3.0.0
Changelog: https://github.com/ludeeus/pycfdns/releases/tag/3.0.0
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

1 package failed to build:

home-assistant-component-tests.cloudflare

2 packages built:

python311Packages.pycfdns
python311Packages.pycfdns.dist


Use website locale as fallback for languages.

Magento has a multi-layer inheritance for the configuration going from default (global) to websites to store views. Languages were only fetched via default and store views. This PR fixes that by adding websites as an intermediate fallback.

Kindly apply this pull request. I just wrote the same request myself, but then I found out it already existed.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/PT-12049
Please use this issue to track the state of your pull request.

Hi kleinmann,
thank you for your contribution. Your change is committed in: https://github.com/shopwareLabs/SwagMigrationMagento/commit/f5538012830c060dca926d88996c415f80a12b49


Setting to format on save

https://github.com/neurocyte/flow/blob/0dc6fae7b74b554d905d3cd2524bfd00f346f4f3/src/config.zig#L19
thats already a thing though?

https://github.com/neurocyte/flow/blob/0dc6fae7b74b554d905d3cd2524bfd00f346f4f3/src/config.zig#L19
thats already a thing though?

Whoops didn't notice that, thanks


WIP: hack on keyboard

I wish there was a way to express the default scope, but maybe in keyboard world that's a job for macros / shortcuts whatever.
Perhaps we should start to have a shared keyboard prefix and grammar for modifiers.
This was mainly just me making sure I knew how to add something, figuring we could refactor and adjust keyboard shortcuts later.
Checklist

[x] I have added tests
[-] I have updated the docs and cheatsheet
[-] I have not broken the cheatsheet

Since this is building on a pile of unmerged commits, I'm just going to keep hacking away here. New commits:

add a test
tinker with the default key config
move "exitCursorlessMode" info to config (#2117)

Once the logjam breaks, I'll start submitting these for review. For now, I figure I may as well keep pushing publicly while I try to scratch my most pressing itches.

This work will come in a series of new small atomic PRs.


Both default autoformatting and user configured Clang have stopped working

VSCode Version: Code 1.16.1 (27492b6bf3acb0775d82d2f87b25a93490673c6d, 2017-09-14T16:38:23.027Z)
OS Version: Windows_NT x64 10.0.15063
Extensions:

Extension
Author (truncated)
Version

cpptools
ms-
0.13.0

Steps to Reproduce:

Create new folder
Open folder using VSCode
Create new file called foo.h
Add the following code to the new file (with bad whitespacing and everything)

#pragma once

class Foo {
                  public:
bool hi = false;
};

Press the auto format hotkeys (you will have to add these to your keybindings.json; I made mine ctrl+shift+f)

Expected: Formats class
Actual: Nothing happens
Note, I have also tried this using the following settings and placing a .clang-format file into the same directory as the header file:
{
    "window.zoomLevel": 0,
    "workbench.sideBar.location": "left",
    "terminal.integrated.cursorBlinking": true,
    "editor.tabCompletion": true,
    "editor.formatOnType": false,
    "editor.formatOnSave": true,
    "editor.formatOnPaste": true,
    "C_Cpp.intelliSenseEngine": "Default",
    "C_Cpp.clang_format_path": "C:/Program Files/LLVM/bin/clang-format.exe",
    "C_Cpp.clang_format_style": "file",
    "workbench.colorTheme": "Visual Studio Light",
    "editor.acceptSuggestionOnEnter": "smart",
    "git.enableSmartCommit": true
}

Please fix this (or let me know what I'm doing wrong).  It makes checking in code and having to check the formatting of everything very painful.  This was working just before I let VSCode update yesterday.
Thanks

Reproduces without extensions: Yes/No

Hmm...Seemed to be fixed with a reinstall of the vscode cpp tools. Closing this issue.


Can't send slack notification in freeStyleJob

Your checklist for this issue

[x] Jenkins version - 2.150.1

[x] Plugin version - 2.14

[x] OS - Debian

Description
This is my freeStyleJob:
freeStyleJob("") {
   steps {
        downstreamParameterized {

        }
   }
   publishers {
        postBuildScripts {
            steps {
                def summary = "FAILURE: Job '${JOB_NAME} [${BUILD_NUMBER}]' (${BUILD_URL})"
                slackSend (color: "#FF0000", channel: "eddie", message: summary)
            }
            onlyIfBuildSucceeds(false)
            onlyIfBuildFails(true)
        }
   }
}

I get error in Jenkins:
ERROR: (some_file.groovy, line 50) No signature of method: javaposse.jobdsl.dsl.helpers.step.StepContext.slackSend() is applicable for argument types: (java.util.LinkedHashMap) values: [[color:#FF0000, channel:eddie, message:FAILURE: Job 'some-job [25]'

I want to send slack notification in my freeStyleJob job, there is no good documentation about it, please assist.

It was solved by using:
    publishers {
        slackNotifier {
            notifySuccess(true)
            notifyFailure(true)
            room("#some_channel")
            sendAs(null)
            commitInfoChoice("NONE")
        }
    }


Remove version: WHONET.2023 version 23.13.23

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

URL: https://whonet.org/WHONET2023-Setup-x86.exe
Status Code: 200
(Automated message - build 694)

Automatic Validation ended with:

2024-02-01T15:28:48.2733533Z Processing manifest: manifests\w\WHONET\2023\23.13.23
2024-02-01T15:28:48.2742239Z -----------------------------------------------------
2024-02-01T15:28:48.2749893Z Status: Started
2024-02-01T15:28:48.2758576Z Manifest file is Deleted
2024-02-01T15:28:48.7998038Z Status: Completed
2024-02-01T15:28:48.8010266Z ##[error] Result: Failed
2024-02-01T15:28:48.8039864Z ##[error] Sequence contains no elements
2024-02-01T15:28:48.8669039Z ##[error]Manifest Validation Failed

(Automated response - build 694.)

Sequence contains no elements

https://github.com/microsoft/winget-pkgs/issues/133371

(Automated response - build 694.)

URL: https://whonet.org/WHONET2023-Setup-x86.exe
Status Code: 200
(Automated message - build 694)

Hi @drshtmstry,
This is the last remaining manifest version for this package. Is it available from another location?
(Automated response - build 694.)

Hi @drshtmstry,
This is the last remaining manifest version for this package. Is it available from another location?
(Automated response - build 694.)

That is because it is vanity url package. Submitted new version here https://github.com/microsoft/winget-pkgs/pull/137478.
Previously I used wingetcreate which automatically deleted old version in same PR.
But lately I have experienced those PRs are not being approved.
That is why I have switched to komac which only adds new version & manually deleted in separate PR.


Update Dockerfile to use debian base image, ensure all dependencies are in requirements.txt

Thanks for fixing this, wasn't expecting you to!


better bit-wrangling abstraction

In many places in the code you can see
    T = eltype(xzs)
    lowbit = T(1)
    ibig = _div(T,i-1)+1
    ismall = _mod(T,i-1)
    ismallm = lowbit<<(ismall)

where ibig is the index within the array of UIntx and ismall is the bit within that UIntx. This is getting too repetitive at this point. Find a better way to write it, abstract it away.
Consult the small symbolic Cliffords (e.g. sHadamard) as they have some more abstraction.

@amicciche  , this is related to your pull request

Keeping this open as there can still be additional cleanup even after #367.
#367 would be a good reference for future work on this as well.
In particular, now with #364 we consistently just get the small and big indices, but an abstraction that does not require the user to explicitly perform that step would still be useful. E.g. something like bi = BitIndexer(stabilizer); bi[i,j] == stabilizer.xzs[ibig] & imask (up to some typos in the example). But really, it would be much better if just writing stabilizer[i,j] ends up being as fast so we do not need this explicit indexing.


Exiting VR can result in messed up view

http://www.html5gamedevs.com/topic/39361-exiting-vr-can-result-in-messed-up-view/

Closing this, merged different changes with https://github.com/BabylonJS/Babylon.js/pull/4909 and that should be merged instead.


[wrt] Add EXTERNAL_STORAGE permissions

Impacted tests(approved): new 0, update 2, delete 0
Unit test platform: Crosswalk Project for Android 18.46.462.0
Unit test result summary: pass 2, fail 0, block 0
https://crosswalk-project.org/jira/browse/XWALK-6097

LGTM


feat(client): Support connect_or_create

Change Summary
Adds connectOrCreate to support #754
Please let me know if I should make write tests (and where to put them). Thanks @RobertCraigie for your work on this great library!
Checklist

[x] Unit tests for the changes exist
[ ] Tests pass without significant drop in coverage
[ ] Documentation reflects changes where applicable
[ ] Test snapshots have been updated if applicable

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

thanks @RobertCraigie - I moved the tests to the files you mentioned, and renamed the function to snake case. Any other feedback?

hi @RobertCraigie, looks like one test failed, but it’s a transient error (incomplete read while downloading node binary). the tests all passed on my fork, could we please retry?


Hydrogen CLI's env push command is released

WHY are these changes introduced?

We are ready to release the env push command for the Hydrogen CLI
We need to update the cli-kit and oclif to support multiline env vars in the .env file

WHAT is this pull request doing?

Hydrogen CLI's env push command is the counterpart for the env pull command. It is used to push environment variables found in the .env file to Admin. Refer to docs for full usage details.
Updated internal libraries for parsing .env file.

HOW to test your changes?

checkout code
npm ci && cd packages/cli && npm run build
npx shopify hydrogen env push --path=/path/to/repo (if you don't have a repo, create it using the npx shopify hydrogen init` command)

Post-merge steps
Checklist

[x] I've read the Contributing Guidelines
[x] I've considered possible cross-platform impacts (Mac, Linux, Windows)
[x] I've added a changeset if this PR contains user-facing or noteworthy changes
[x] I've added tests to cover my changes
[x] I've added or updated the documentation

@frandiox I am getting ERROR  run failed: io error: Operation not supported on socket (os error 102) when trying to run build or build:pkg 😞


Error: The getter 'hsFuture' isn't defined for the class '_EventStreamSubscription'.

Yesterday i got no problem when running my Flutter Web but today I got this error. I don't know what root cause of this error. Even I change the page and run the flutter web in blank page, i still got this error.
Thank you.
Launching lib/main.dart on Chrome in debug mode...
../../.pub-cache/hosted/pub.dev/web-0.5.1/lib/src/helpers/events/streams.dart:196:25: Error: The getter 'hsFuture' isn't defined for the class '_EventStreamSubscription<T>'.
 - '_EventStreamSubscription' is from 'package:web/src/helpers/events/streams.dart' ('../../.pub-cache/hosted/pub.dev/web-0.5.1/lib/src/helpers/events/streams.dart').
Try correcting the name to the name of an existing getter, or defining a getter or field named 'hsFuture'.
    final emptyFuture = hsFuture<void>.value();
                        ^^^^^^^^
../../.pub-cache/hosted/pub.dev/web-0.5.1/lib/src/helpers/events/streams.dart:196:25: Error: The static type of the explicit instantiation operand must be a generic function type but is 'dynamic'.
Try changing the operand or remove the type arguments.
    final emptyFuture = hsFuture<void>.value();
                        ^

flutter doctor -v result:
`[✓] Flutter (Channel stable, 3.19.6, on macOS 14.3.1 23D60 darwin-x64, locale en-US)
    • Flutter version 3.19.6 on channel stable at /Users/alif/src/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 54e66469a9 (6 days ago), 2024-04-17 13:08:03 -0700
    • Engine revision c4cd48e186
    • Dart version 3.3.4
    • DevTools version 2.31.1

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/alif/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15E204a
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.9+0-17.0.9b1087.7-11185874)

[✓] VS Code (version 1.88.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.86.0

[✓] Connected device (3 available)
    • iPhone 8 Plus (mobile) • 4C669F31-EC87-457C-B697-07078FB3B3A1 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-16-4 (simulator)
    • macOS (desktop)        • macos                                • darwin-x64     • macOS 14.3.1 23D60 darwin-x64
    • Chrome (web)           • chrome                               • web-javascript • Google Chrome 124.0.6367.62

[✓] Network resources
    • All expected network resources are available.

• No issues found!`

I'm not sure where that code is coming from. The related code is here: https://github.com/dart-lang/web/blob/main/lib/src/helpers/events/streams.dart#L196 which doesn't use "hsFuture", and the git blame doesn't show that code ever existing. Maybe try clearing your pub cache and trying again?

I had the same issue and clearing the pub cache was the fix. Thanks @srujzs


Updated version of credstash, for hmac buffer support

Credstash is getting the hmac back from Dynamo DB as a buffer, but the current version being used expects a string.  The new version checks if it is a string, and if not treats it as a buffer,

Coverage remained the same at 94.186% when pulling 306b532fe982fae8e4726dc5e13856e986f893ab on concon121:develop into 4c789ab78130278de1330c850a788cfa22b58066 on DopplerLabs:develop.

@concon121 Thanks for the PR!

Released as 1.0.2


Recommendation: Replacing grunt-contrib-sass with grunt-sass

The grunt-sass module (https://github.com/sindresorhus/grunt-sass) doesn't require ruby installed to compile CSS files to SASS and as such we gain:

Faster compilation time due to a C++ extension
Lowering our dependencies/pre-requisites count and not requiring anyone to install ruby

What do you think?

Is there a gulp equivalent?

gulp-sass already uses node-sass.

Right, was about to say that :)
I'll work on a PR for that so we can align it and remove dependencies for ruby.

Why are we doing grunt development though, we are deprecating grunt...

I don't think deprecating grunt will happen tomorrow and there is obviously some target users of MEAN.JS using grunt still so why not?