Do not require { ... } around variable names for null-conditional member access

Follow-up from #3240.
Null-conditional member access (?.) was implemented and will be available as an experimental feature in 7.0
However, in the interest of backward compatibility the implementation currently requires that the variable name be enclosed  in {...}, because ? is technically a legal character in a variable name whose use surprisingly doesn't require {...}.
That is, if you want to ignore an attempt to call$obj.Method() if $obj is $null (or undefined), you would expect the following, analogous to C#:
# Does NOT work as intended.
# 'obj?' as a whole is interpreted as the variable name.
$obj?.Method()

Instead, you must currently use:
# !! Must enclose 'obj' in {...} to signal that '?' is a syntactic element as part of '?.'
${obj}?.Method()

Update: Null-coalescing - $var??='default and $a??$b - and the ternary operator - $var?1:0 - are similarly affected (though there the use of whitespace before the ? resolves the issue).
This requirement is (a) unexpected and (b) cumbersome:

New users will not expect the need for {...} and won't necessarily know that it is what is required when the following fails (possibly undetected, unless Set-StrictMode -Version 2 or higher is in effect): $o = [pscustomobject] @{ one = 1 }; $o?.one

Even once users do know about the need for {...}:

They will forget to use it on occasion, because of the counter-intuitive need for it.
When they do remember, this seemingly artificial requirement will be an ongoing source of frustration, especially since {...} is hard to type.

Use of {...} shouldn't be necessary, and while not requiring it amounts to a breaking change, it arguably falls into bucket 3: Unlikely Grey Area.

Why this change should be considered acceptable:
Note: @rjmholt discusses why changing PowerShell's syntax is highly problematic in general in this comment, but for the reasons presented below I think it is worth making an exception here.
?. is a new syntactic feature; by definition scripts that use it cannot (meaningfully) run on older versions - unless you specifically add conditionals that provide legacy-version-compatible code paths, but that seems hardly worth it - you would then just stick with the legacy features.
Yes, the interpretation of $var?.foo in old scripts that used $var? as  a variable name would break, but:

? should never have been allowed as part of an identifier without enclosing it in {...}.

Since being able to do so is unexpected and probably even unknown to many, such variable names are exceedingly rare in the wild, speaking from personal experience, but @TheIncorrigible1's analysis provides more tangible evidence.

Even Ruby only allows ? (and !) at the end of identifiers, and there only of method identifiers, and I suspect that most Ruby users are aware that they should not assume that other languages support the same thing.

So, pragmatically speaking:

The vast majority of existing code will not be affected - a token such as $var?.foo will simply not be encountered.

If you write $var?.foo with the new semantics, then yes, running that on older versions could result in different behavior (rather than breaking in an obvious manner), depending on what strict mode is in effect - but you should always enforce the minimum version required to run your code as intended anyway (#requires -Version, module-manifest keys).

All in all, to me this a clear case of a bucket 3 change: a technically breaking change that breaks very little existing code while offering real benefits (or, conversely, avoiding perennial headaches due to unexpected behavior).

To clarify, the milestone just means it's something the team should discuss based on the feedback, not that we are committed to making this change.

@mklement0

? should never have been allowed as part of an identifier without enclosing it in {...}.

Ummm - the initial base language for PowerShell was the Posix Shell which uses $? for the exit code q.e.d '?' is allowed in variable names unquoted.

it cannot (meaningfully) run on older versions

Sure it can:
PS>  $abc?=@{a=1; b=2; c=3}
PS>  $abc?.b                                                                                1
PS>  2

Sure it can:

It cannot run meaningfully with the new semantics (null-conditional access) - that's all I meant to say.
Yes, your example currently works, but with different semantics (abc? including the ? being considered the variable name) - but for the reasons stated this corner case is worth abandoning for the sake of making ?. work as expected.

The initial base language for PowerShell was the Posix Shell which uses $? for the exit code

$? is an exception in POSIX-like shells; you can not do the following:
# sh, bash, ksh, zsh:
foo?='bar' # BOOM! E.g. "bash: foo?=bar: command not found"

And, as a matter of course, it should be mentioned, that all other automatic variables in the same space as $? (i.e., $^ and $$) are explicitly special-cased in the tokenizer. And, as a matter of fact, so is $?, even though it (currently) doesn't need to be.
It seems clear to me that it was expected at the time that code was written that ? would not be a valid identifier character.

I only know of one person who has used ? at the end of variable names in their scripts, and that's @StartAutomating. Since he's actually used that syntax, I thought it worth drawing his attention to this discussion.
Also @vexx32, the reason that $? is special cased in the tokenizer is because you cannot create a variable with a name that starts with ?. e.g. $??? = 'foo' will not parse. Variable names must start with alphanumeric characters or an underscore, and currently can contain alphanumeric characters, underscores, or, questionmarks. I'm in agreement that ?. should be parsed as the null-conditional member access token, but I wanted to clarify why ? is special-cased in the tokenizer.

Thanks for drawing my attention to this chat.
For what it's worth, I have a few thoughts:

While these variables are rare, no one want's to play whack-a-mole when back-compat breaks their scripts
Deeply geeky folks aside, I'd expect that ${obj}?.Method() or $obj?.Method() will get little uptick.  There's a decade of guidance out on the web of how to manage nulls out there, and I don't see that many people switching from if ($obj) { $obj.Method() } just to get on the v7 bandwagon
Additionally, most people who have problems with unexpected variable names learn the ${} syntax (you'd already hit it naturally with an underscore).  I'd expect the venn diagram overlap of "people who want to use this feature" to "people who know ${} syntax already" to be near 100%
Since said syntax isn't as powerful as a full subexpression, and full subexpressions work both in core and not, I'd expect that most people will continue to use this going forward.

So, running the math, there are several concrete reasons not to do this, and only one vague reason to do this (it might be easier, for some users).  Given the low prevalence of ? in variable names, you might be helping more people than you harm, but in my opinion it's a coin-toss.
Given such coin-toss potential of benefit, I will paraphrase Robert McNamara "If we're darned if we do and darned if we don't, I'll pick darned if we don't".

I suggest doing it so that $obj?.Method() works as $obj?.Method() by default, and only fall back to $obj?.Method() when $obj doesn’t exist in scope, but $obj? does and #requires ‑Version isn’t v7+.

@ExE-Boss, that seems like a lot of exceptions to make for this particular rule.
I repeat my questioning of the value of this particular rule.
Past that, the question is "what else do we not know about variable syntax that we might break?"

If the consensus is to force ${...} syntax for this, support for OptionalFeatures would be appreciated here, so that folks like myself who will use this syntax (I'll be using it a lot) can opt out of the noise.
Since we're paraphrasing here:
"Logic clearly dictates that the needs of the many outweigh the needs of the few." - Spock

So, running the math, there are several concrete reasons not to do this, and only one vague reason to do this (it might be easier, for some users).

@StartAutomating: There are multiple reasons, and they are concrete, not vague. Also, one of the goals of this is code simplicity. Having to wrap variable names with {} works directly against that goal.

I'm with @mklement0 and @KirkMunro on this. Personally I find the ${...}? syntax unnatural and unnecessary complex. We have had breaking changes already and in this case it is small price to pay in exchange for clarity.

@StartAutomating

3. Additionally, most people who have problems with unexpected variable names learn the ${} syntax (**you'd already hit it naturally with an underscore**).  I'd expect the venn diagram overlap of "people who want to use this feature" to "people who know ${} syntax already" to be near 100%

This doesn't hold up.  Underscores are valid characters in variable names.

@vexx32

It seems clear to me that it was expected at the time that code was written

Nope.

Swap the chars around? $foo.?Property looks non-clashing, because property names beginning with questions marks need quoting already:
PS C:\> $foo = [pscustomobject]@{'?'=1; '?name'=2}
PS C:\> $foo.?name
At line:1 char:6
+ $foo.?name
+      ~
Missing property name after reference operator.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : MissingPropertyName
PS C:\> $foo.'?name'
2

@HumanEquivalentUnit, unfortunately, that would invite everlasting confusion with the long-established ?. syntax used in C# and several other languages (also, you'd need to find an alternative form for the indexer (${arr}?[0]) as well, and something like $arr[0]? would invite confusion with the ternary operator)

There isn't a neat solution.

An unknown number of people use ? at the end of a variable names. While it is an optional feature one can say "Don't turn it on if you run those scripts" but the person turning it must check current and future scripts they get from whatever source.
Alternate syntax isn't a great option because it is importing something not-very-powershelly from C#
Changing behavior based on #requires doesn't work outside a saved script, and will fail as soon as someone copies some code from a long script without setting the tag.
4.(dir *.ps2)?.count and (dir *.ps1)?.count  show that it operand doesn't need to be a variable.
($Host)?.toString()  / ($null)?.toString()   removes the need to put braces around the name. It's still extra keystrokes, but it is more logical and less ugy.

Changing behavior based on #requires doesn't work outside a saved script, and will fail as soon as someone copies some code from a long script without setting the tag.

This applies to any code that uses features not supported in earlier versions.
If this were the overriding concern, no new language feature or new cmdlet / cmdlet parameter would ever be introduced.
(Hopefully, in older code you have at least Set-StrictMode -Version 1 in effect, in which case $var?.foo would fail loudly, due to no variable named var? existing).

removes the need to put braces around the name.

Substituting (...) for {...} is only a marginal improvement.
Whatever extra syntax is used, the problem here is the need for extra syntax - for something that should just work as-is - not just for typing convenience but also to meet sensible expectations.

Changing behavior based on #requires doesn't work outside a saved script, and will fail as soon as someone copies some code from a long script without setting the tag.

This applies to any code that uses features not supported in earlier versions.
If this were the overriding concern, no new language feature or new cmdlet / cmdlet parameter would ever be introduced.

That wasn't quite what I meant. Further up there was suggestion that if #requires specified pwsh 7 then the processing might be different. Lighting up a new behaviour only if you put #requires  isn't good .

(Hopefully, in older code you have at least Set-StrictMode -Version 1 in effect, in which case $var?.foo would fail loudly, due to no variable named var? existing).

In my experience not much uses Set-Strictmode. Because (a) there is an assumption that the default without it is "right" and (b) the frequency of using things which rely on it being off is too high.  It's a common use for these operators.  In any case the problem is older code where $var? does exist and does have a foo property, but now  the code looks for $var ... Possibly the new processing would cause an error IF strictmode is set because $var doesn't exist....

removes the need to put braces around the name.

Substituting (...) for {...} is only a marginal improvement.

Yes. ($x) is slightly better than ${x} but only slightly.  (Get-user "Bob")?.disable() is better than
$u = get-user "bob"
($u)?.disable

Whatever extra syntax is used, the problem here is the need for extra syntax - for something that should just work as-is - not just for typing convenience but also to meet sensible expectations.

Yes.
$var.   foo    With white-space works.  ${foo}   ?.bar() doesn't because ? is allowed in a function or alias name (?. is legal for both).  Lashing bits of C# syntax into existing syntax rules without breaking things isn't always practical  Sometimes, "This is available in C#..." really deserves the answer "Yes. You know where C# is if you want it".
:-)

To maintain SemVer compatibility, this should be done in a major release (preferably 7.0.0).
Also see my suggestion above (https://github.com/PowerShell/PowerShell/issues/11379#issuecomment-566756120).

@ExE-Boss Yes, it was your comment I was referring to when I said depending on #requires might not be the good idea it sound at first.
And yes, if one is to break any existing scripts the time to do is when the major version changes, so this needs to be done quickly or wait for V8
These are still an experimental feature and are off by default in RC-1 , which I assume is going to stay the same for a shipping product. That does allow the behaviour to be changed (or even be second experimental feature) - it also should  block/ warn when trying to create a variable ending with certain characters.  If I enable it and then want to use scripts with errant variable names that puts the responsibility on me - of course it means that scripts I download which do that just look "broken" which is more tolerable under the "experimental" banner.

I'm not a serious PowerShell developer; I came here in search of a solution to a bug and happened to stumble upon this issue.  For command line scripting, I mostly use bash.  I'm probably in the demographic that Microsoft is trying to convince to switch to PowerShell Core: cross-platform developer in need of a quick scripting language that's less of a pain than bash.
I've often found many of the decisions related to PowerShell's syntax unintuitive to people who aren't primarily PowerShell developers.  The last time I used PowerShell for something serious, I was appalled by the lack of a null coalescing operator, or even a ternary operate I could use instead--which resulted in me posting this popular PowerShell answer on Stack Overflow.  That was in 2013, and it's easily one of the top three reasons I've mostly avoided PowerShell ever since.  The whole point of a scripting language is that I want something quick and dirty with a lot of syntax sugar, not verbose if-else statements.
@StartAutomating said:

Deeply geeky folks aside, I'd expect that ${obj}?.Method() or $obj?.Method() will get little uptick. There's a decade of guidance out on the web of how to manage nulls out there, and I don't see that many people switching from if ($obj) { $obj.Method() } just to get on the v7 bandwagon

I'm just n=1, but as a non-PowerShell developer, I strongly disagree.  The new ? syntax is something I would find out about pretty quickly even as someone who touches PowerShell maybe once every few months, and it would definitely increase the odds of me using PowerShell in the future in place of alternatives.

First off, I believe my initial feedback has created a kerfuffle of misunderstanding.
My supposition was that ${} would not be that weird to PowerShell developers , because they would already have to know this syntax form if they had ever embedded a variable with a ? or and underscore in a string.
Thanks for the many reminders that this syntax might be awkward to non-PowerShell developers.
The second part of my feedback might have gotten lost in the mix:  Because other alternatives to null-coalescing have existed for more time in PowerShell and are widely used, I don't know how much uptick the feature would have with existing PowerShell users.  You want to come in and say "this is the one thing I need to start using PowerShell", and I can't argue with your opinion (though I might say you're missing a forest of cool features looking for a tree of language familiarity).
The third bit of my feedback seems to have been blown out of proportion.  Speaking as one of the people who has occasionally used variables named like $IsThisRight? = Test-Something , my first reaction to hearing the potential news about this variable restriction was "oh well, guess I'll have to rename some variables, I wasn't getting that much for it anyways."
So, to attempt to restate and end the thread:

IMHO, ${} will probably not be that weird of a syntax for existing PowerShell developers
You're welcome to think this feature is cool; to me it's a language familiarity gateway drug, and I'd highly recommend everyone reading this thread learn how to rock assigning ifs/foreaches/whiles etc.
As one of the impacted authors, I'm not getting something so mission critical from a ? at the end of my variables that I would be opposed to changing my code.

Or, to be pithily short:
Do this change if you want to.  I have little horse in this race.  If you do decide to do this, please broadcast the change clearly so that anyone else who has named variables with a ? can update accordingly.

The second part of my feedback might have gotten lost in the mix: Because other alternatives to null-coalescing have existed for more time in PowerShell and are widely used, I don't know how much uptick the feature would have with existing PowerShell users.

I do definitely agree with that, and I don't want to be dismissive of your opinion.  It's always hard to make breaking changes like that, especially when the alternative might be intuitive to people who are already heavy users of the language.

You want to come in and say "this is the one thing I need to start using PowerShell", and I can't argue with your opinion (though I might say you're missing a forest of cool features looking for a tree of language familiarity).

Well, I had a feeling that most non-PowerShell developers aren't really participating in these conversations--it's pure coincidence that I happened to stumble upon this.  My use of PowerShell will likely be very different from people who are writing libraries and open source tools.  I figured I'd just give the perspective of someone who's using PowerShell less as a fancy framework and more to get odd tasks done as fast as possible.  It's not meant to be dismissive of any other opinions--it's just another opinion from a perspective that probably isn't seen all that often here.
Better null handling isn't the one thing I need to start using PowerShell more: it's the second thing.  The first was cross-platform support, and I'm very impressed with how far that's come.  Personally, syntax sugar is a big deal for me when I'm choosing a language to do a given task: I want the syntax to make what I'm doing easier.  If I'm writing something that needs to be maintained by a lot of people, I'm probably going to want it to be more verbose; but if I'm writing a quick script for administrative or devops tasks, I just want a quick way to test for things like null.

The third bit of my feedback seems to have been blown out of proportion. Speaking as one of the people who has occasionally used variables named like $IsThisRight? = Test-Something , my first reaction to hearing the potential news about this variable restriction was "oh well, guess I'll have to rename some variables, I wasn't getting that much for it anyways."

Favoring backwards compatibility is always a fair argument.  However, in this particular case, it seems like a lot of PowerShell scripts are on the verge of breaking due to the transition to Core anyway.  When backwards compatibility breaks on a regular basis, it's frustrating, but I would be in favor of any breaking changes happening all at once, which means this is probably a good time.
In a scenario in which you're trying to target a whole new demographic--that is, non-Windows-centric developers--it might be necessary to make some breaking changes to compete with what's already out there.

If you do decide to do this, please broadcast the change clearly so that anyone else who has named variables with a ? can update accordingly.

To be clear, I'm fine with needing to opt into the feature--that wouldn't be deter me from using PowerShell.    I wouldn't consider it ideal, but it'd have little impact on my decision to use PowerShell as long as it's well-documented.

Personally, syntax sugar is a big deal for me when I'm choosing a language to do a given task

Then you've come to the right language!  PowerShell is positively sacchrine with syntactic sugar.
To educate those who don't know, you can "null coalese" several ways in PowerShell:
$ListWhereNotNull = $null, 1, 2, $null, 3 -ne $null # This will check that each item is not null, and return a list of 1,2,3
$FirstNonNull = @($null, 1, $null,2 -ne $null)[0]  # This will return the first non-null
$lastNonNull = @($null, 1, 2, $null -ne $null)[-1] # This will return the last non-null, using a negative index
$TheObjectPipelineWay = $null, 1, $null, 2 | Where-Object { $_ } | Select-Object -First 1
$TheAssigningForeachWay = foreach ($item in $null, 1, 2, $null, 3, 4) {
    if ($item -ne $null) { $item; break }
}
$FirstViaMultipleAssignment, $RestIDontCareAbout = $null, 1, $null, 2, 3,4, $null -ne $null

That's enough for now, but it should prove the point on the language syntax having much flexibility.  All of those demos will work all the way back to PowerShell 1.0

However, in this particular case, it seems like a lot of PowerShell scripts are on the verge of breaking due to the transition to Core anyway.

In this you are incorrect.  Core actually has very few syntax breaking changes, and more modules than you'd think work just fine on core (+- some issues with Linux vs Windows pathing/newlines).   In more practical terms, your module is less likely to work on Core if you have some sort of Windows platform specific API dependency (e.g. I'm not going to hold my breath to get my WPF wrappers working on Linux).
I still am fine either way with the syntax change:  I just felt that two of the assertions in the latest reply needed to be addressed and called out.
Re: Syntactic sugar, my sarcastic mind quotes the movie "Snatch": "I'm already sweet enough"
Re: breaking change potentials in Core: We have few now, and let's keep it that way as much as we can.

@StartAutomating : Are you saying i can't shoot? because there's still place for more sugar I think 😜

To educate those who don't know, you can "null coalese" several ways in PowerShell:

I did figure that out (that's my own answer that I wrote), but it felt like a kludge.  It's a cool idea with a lot of potential, but as one commenter on that Stack Overflow answer pointed out, evaluation doesn't short-circuit.  The ?. operator means that this is usually no longer an issue when chaining calls/properties.  Back in 2013, though, it wasn't available--and, even then, there's an awful lot going on in these examples, and you can see in the comments how people found that confusing.  I had to break down exactly what these examples do symbol-by-symbol.

In this you are incorrect. Core actually has very few syntax breaking changes, and more modules than you'd think work just fine on core (+- some issues with Linux vs Windows pathing/newlines). In more practical terms, your module is less likely to work on Core if you have some sort of Windows platform specific API dependency (e.g. I'm not going to hold my breath to get my WPF wrappers working on Linux).

I'm just speaking from experience in this regard, rather than actually going through and gathering proper statistics.  For example, pre-Core, I could generate a password with [System.Web.Security.Membership]::GeneratePassword(32, 6), but System.Web isn't available in Core.  (I know I could probably load the old System.Web.dll, but I'd rather not do that if I don't have to.)  Syntax changes are actually easier for me to resolve than missing APIs.  Generating a bunch of Docker secrets for a devkit seems like a great place to use a quick script, but it's surprisingly more verbose in PowerShell Core than bash.  Of course, bash's solutions often look pretty ugly.

Re: Syntactic sugar, my sarcastic mind quotes the movie "Snatch": "I'm already sweet enough"

It depends.  Sometimes I feel like PowerShell is extraordinarily pleasant.  Dealing with null is one of those key areas where I usually don't feel that way--although I'd say the same for a lot of languages.  I also find the traditional inline PowerShell if-else statement to be cumbersome compared to a ternary operator or bash's && and || chaining.  Since this is one of the key issues that caused me to drift away from PowerShell years ago, I figured it was worth mentioning.
On the other hand, I deal with a wide variety of languages on a daily basis, and no matter what I'm writing, I'm always thinking, "this would be so much easier in language X!"--and then when I'm using language X, I'm thinking, "this would be so much easier in language Y!"  But hey, if I get an opportunity to say that out loud and maybe sway the direction of the language, I'll take it.
I'm not really interested in changing any minds here, just adding another perspective.

@StartAutomating : Are you saying i can't shoot? because there's still place for more sugar I think 😜

I always love me some new syntax sugar!  I select programming languages like a kid going trick-or-treating on Halloween.

@Zenexer : I really like Powershell, I do. I'm fortunate enough to do PS extensively and daily at work. I love the flexibility, especially the symbiosis with .NET, oh man! That's why I care about its direction and that's why the ${...}. syntax is so hard to accept for me.

Good points, but let me clarify a few things.
For better or worse, PowerShell to date hasn't used semantic versioning.
A new major version only brought new features, with an ironclad commitment to backward compatibility.
Breaking changes started to creep in in Core, in part of necessity due to going cross-platform.
Major version v7.0 was chosen to signal an increase in backward-compatibility: an attempt to provide a viable replacement for Windows PowerShell.
While many historical problems cannot be fixed without seriously breaking existing code and can therefore only be offered as optional (opt-in) features,
bucket 3 breaking changes should always be an option: make a fix / improvement that has the potential to break existing code, but is unlikely to in practice; on balance, it is worth making to better the language.
As argued in the OP, the case at hand strikes me as a bucket 3 change; while we know that some scripts will break (@StartAutomating will know how to fix his scripts), the data suggests that such cases are quite rare.
Why is it rare?
Because using ? in variable names doesn't occur to most people altogether, and if it does,  they shouldn't expect it to work without {...}:  If all of the following work only with {...}, why would expect it to be different for ??: . , ; (: can't be used at all, because it is always interpreted as a drive separator
Allowing names  such as $var? or $va?r without also requiring {...} was a permissiveness that asked for trouble, and the trouble has arrived: it gets in the way of the evolution of the language, as in this case.
There are 3 new related features (at least related in syntactic form) inspired by C#:

Ternary conditionals - will be a bona fide feature in 7.0

(Get-Date).Second % 2 ? 'odd' : 'even'

Null-coalescing operator - will be a bona fide feature in 7.0

$var ?? 'default' and $var ??= 'default'

Null-conditional operator - the issue at hand - will be an experimental feature in 7.0

$possiblyNull?.ToString()

All of them have ? as part of their syntax, and all of them are affected by the burden of legacy $var? parsing, though ?. most obviously so:

While you could argue that something like $var?1:0 is only of interest to code golfers, it would work just fine if ? had syntactic function - currently you must use a space before the ?

By contrast, it strikes me as reasonable for someone to attempt $var??='bar' (perhaps less so $baz = $foo??$bar), which currently also require a space.

That is, if we stick with the current parsing of $var?, we're encumbering three new features (albeit to varying degrees), 2 of which are already generally available (not experimental).
The issue with requiring {...} is not just the inconvenience of typing: it is just as much about not expecting the need for it in the first place, and later forgetting the need for it (with potentially subtle malfunctioning) - because it so counter-intuitive.
@ExE-Boss, I agree with @jhoneill  that implementing version-conditional behavior would be problematic. I don't think there is need to encumber the engine with backward-compatibility special-casing in this case.

@mklement0 : It is unnatural/counter-intetactive/you-name-it. Brackets are hard, curly brackets even harder. There's no need for them in this case.

@mklement0  since agreement seems to be breaking out ... I think that's a good summary.
I'm yet to be completely won over by adding C# constructs to PowerShell.  We already have issues in many places that there just aren't enough symbols on the keyboard. Is ">" "Greater than", or "redirect to" ? Is "=" assignment or test-equality (different languages use := for assign or == for equality). People jumping between languages will forget to use -eq or -gt and we're stuck with that...  Is + arithmetic addition, or string/array concatenation. * is both multiplication and a wild card. % is Modulo and an alias forforEach-object.
Poor ? Is the alias for Where-Object. And is the name of an automatic variable. But try doing Get-Alias ? or Get-Variable ? ... and then it does the job of a wildcard.
Do Get-PSdrive and you see "variable" etc don't have a ":" on the end of the name, adding one : onto a name causes it to be treated as a drive.   Unless of course you refer have written "$drive="C"  and follow it with "$drive:temp" Anyone new to PowerShell (and the some old hands, when they're not thinking about it) will be baffled to know they've just invented a named scope "drive".
So against that ... one might say 'Create a new syntax with further uses for  ":" and "?" are you crazy?'
IIRC, on twitter @BrucePay  described the ternary operator as  "Not very PowerShelly" and I tend to agree. But the "Make it more like C#" voices won the day...
Most people would write $PSEdition.length     -gt    2
but  $PSEdition.         length-gt2  also works (you can even have a line break between the two halves.) "." is also overloaded serving as "current directory", "run in this scope" and "member"  However  in PS V1-V5 I can't think of any operators which require a leading  space;  "."  is odd in breaking if one is present.  But, in order to parse, the ternary operator might need a leading space
$host.debuggerEnabled?0:1    is OK because "?" assumed not to part of a property
$IsCoreCLR?0:1  isn't because "?" is assumed to be part of the variable name.
The same is true for the null coalescing operators
$null??   "default"   needs a space $true.length?? "default" doesn't.
Put the original use case at the top of the issue to one side for a moment. The above cases show that something isn't quite working. It would be fixed  if variable names containing "?" needed to be braced like names containing "." or "+" or ":" , and @StartAutomating  who is a main user of "?" in names thinks that is a break which could be handled. Before we even get to null-members, it sounds like 'find a way to do it already'
I think there is a short time window to put in an experimental feature requiring ? to be braced in names, and if that feature is ON - which should be the default - all the new ? operators should parse accordingly. Only if that feature is OFF would the parser require spaces or braces with these operators.. That is a breaking change, some scripts (a small unquantifiable number) would be broken unless an option was set (and disallowing the variable name should prevent $IsIt?.tostring() being the first error in a script, so the scripts should fail, not run dangerously). and ideally that should not happen with a point release (you're correct about  PowerShell not really using sem-ver, but it's still a good principle)

The issue with requiring {...} is not just the inconvenience of typing: it is just as much about not expecting the need for it in the first place, and later forgetting the need for it (with potentially subtle malfunctioning) - because it so counter-intuitive.

This is a good point and is largely what would annoy me about ${...?} in practice.  Even if I know to use {}, there's a strong chance that I'll eventually forget, and that might result in subtle bugs that aren't obvious at first, since it'll probably still be syntactically valid.  $var??='bar' is a good example of that, although I'm normally pretty careful about spacing.

Thanks, @jhoneill, that's a nice illustration of how many symbols do a lot of double (triple, ...) duty in PowerShell.
For the most part, once you are aware of all uses, that's not a problem, for the following reasons:

different contexts (e.g., * as an operator vs. * as a wildcard char.)

The different contexts for ? actually have something in common, at a certain level of abstraction: You can conceive of the ? in Get-ChildItem | ? Target, $var?.Target, $?, $var ?? 'none' as all involving a kind of question and therefore test or conditional behavior.

sensible polymorphic behavior (e.g., + performing concatenation with string).

A problematic example is & (call operator vs. background operator), which is used in the same context with different semantics, depending only on its position.

It would be fixed if variable names containing "?" needed to be braced like names containing "." or "+" or ":"

Indeed, and that bears repeating: the ability to use ? in variable names won't go away - but you'll  have to use {...} going forward: ${var?} = @{ foo=1 }; ${var?}?.foo
As you demonstrate, from the perspective of someone sensibly not expecting ? to be a valid char. in an unbraced variable reference, ?., ?? and ? : have effectively made the language (situationally) whitespace-sensitive for these operators, which I know the team wants to avoid - for good reasons, because PowerShell generally isn't whitespace-sensitive (at least not one a single line, . for dot-sourcing being the justifiable exception; ? as the Where-Object alias requiring a space after may be surprising (e.g., gci|?target doesn't work), but command names do need to be separated from their arguments with whitespace).
Being able to put whitespace between . and a member name ($obj.    foo) primarily makes sense in multi-line statements, though the arguably more readable form - familiar from other languages - is to (also) allow whitespace before the .:
# This does NOT work - the . must be *immediately after* the expression / member
(Get-Date)
  .ToUniversalTime()
  .TimeOfDay

Being able to do so would mirror the recently added ability to place | on the next line:
 # Already works in PS Core
Get-Date
  | % ToUniversalTime
  | % TimeOfDay

However, this would introduce unresolvable ambiguities with . as the dot-sourcing operator and command names that start with .  - however unlikely. (e.g., . foo on a new line could be a property access or a command that dot-sources a function or script named foo (which would have to be in $env:PATH); .foo could be the name of a command).
@KirkMunro's multi line continuation RFC, while focused on allowing commands to span multiple lines, would give us the next best solution - see https://github.com/PowerShell/PowerShell-RFC/pull/179#issuecomment-498734875.
As for the experimental feature being on by default: Fortunately, preview releases - but not release candidates - now turn all experimental features on by default; however, note that this is persistently overridden if you've ever run Enable-ExperimentalFeature either without -Scope or with -Scope CurrentUser with whatever features you enabled there.

@mklement0 While I agree with basically all of that, I fear we might be headed for derailing this particular discussion a little bit with the extra bits and pieces you have there; if you want to address the line-continuation around the dot-property operator, you may want to open a new issue for that if there isn't one already. 🙂
I agree that continuing to allow ? as a normal variable name character is at best extremely confusing for users, as the character's use suddenly makes things whitespace sensitive, and historically at least, I don't think variable names have ever been whitespace-sensitive in the past.
Introducing that ambiguity is, I think, more of a problem than making a breaking change and disallowing ? from use in a variable name.  With the breaking change, we can easily build a PSSA rule to alert authors that the syntax is no longer permitted. However, the reverse is not so easily true, and unlike the breaking change it will not necessarily error out; it can very easily end up with users accidentally referencing the wrong variable silently, without knowing that's what they're doing.

@PowerShell/powershell-committee discussed this, we had analyzed the PowerShell corpus of scripts and there was quite a bit of usage of variable names ending with the question mark.  As such, we cannot break those folks and braces around PowerShell variable names is an existing language feature to distinguish the variable name from other characters (like within a string).

we had analyzed the PowerShell corpus of scripts and there was quite a bit of usage of variable names ending with the question mark

Thanks, @SteveL-MSFT - can you please share the results of this analysis?

Yeah I'd be curious to see some of that, because I'm aware some community members did their own analysis and didn't get anything close to that kind of result.

I would also like to see the results and method used. I did my own analysis of the PowerShell Corpus last night using the AST which took almost 6 hours to complete on my machine. There were a small number of files not able to be parsed due to Windows Defender quarantining the file.
I found 11 unique variable names across 8 files ending in a question mark (excluding $? which showed up 8846 times). There were a total of 1,895,983, unique variables across 408,423 files. That means 0.0006% of all unique PowerShell variables in the corpus has a variable name ending with a question mark.
Here are the 8 files and 11 unique variables:
File                 : C:\Temp\PowerShellCorpus\Github\alanrenouf_PowerActions\Kill-VM.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\anthonywlee_PowerShell\Send_Notification.ps1
QuestionMarkVars     : To?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\aspear_My-PowerCLI-scripts\my-labotomize-vms.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\jlundstrom_Scripts\Powershell\7Zip SFX Creator\Build.ps1
QuestionMarkVars     : Title?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\pslaughter_Working\Setup-Host.ps1
QuestionMarkVars     : HostIp?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\stevenayers_PowerShell-Scripts\Random Functions\Add-OutlookConferenceRegionNumber.ps1
QuestionMarkVars     : {key1?, key2?, key3?, key4}
QuestionMarkVarCount : 4

File                 : C:\Temp\PowerShellCorpus\Github\unixboy_powershell-stufff\stopvm.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\PowerShellGallery\PsHg\0.6.2\PsHg.psm1
QuestionMarkVars     : PsHg?
QuestionMarkVarCount : 1

This is the script used to generate the report:
Get-ChildItem -Path C:\Temp\PowerShellCorpus -Include *.ps1, *.psm1 -File -Recurse | ForEach-Object -Parallel {
    try {
        $content = $PSItem | Get-Content

        $ast = [System.Management.Automation.Language.Parser]::ParseInput($content, [ref]$null, [ref]$null)
        $variables = $ast.FindAll({$args[0] -is [System.Management.Automation.Language.VariableExpressionAst ]}, $true)

        # First query because I forgot to exclude $? variables
        # $nonQuestionMark = $variables | Where-Object VariablePath -notmatch '\?$' | Select-Object -Unique
        # $QuestionMark = $variables | Where-Object VariablePath -match '\?$' | Select-Object -Unique

        $nonQuestionMark = $variables |
        Where-Object VariablePath -notmatch '\?$' |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $QuestionMark = $variables |
        Where-Object { $_.VariablePath -match '\?$' -and $_.VariablePath.UserPath -ne '?' } |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $output = [pscustomobject]@{
            File = $PSItem
            QuestionMarkVars = $QuestionMark
            QuestionMarkVarCount = $QuestionMark.Count
            NonQuestionMarkVars = $nonQuestionMark
            NonQuestionMarkVarCount = $nonQuestionMark.Count
        }

        $output
    }
    catch {
        throw
    }
}

Let me know if there is any issue with the method used to generate this report. Here is an example script used to test the audit.
$abc = 'test'
$isAwesome? = $true
$?

$test = {
	$?
	$isabc? = { $adce? = 'test' }
	${def?} = 123
	${is a bad var name?} = $isabc?
}

Results in:
File                    : C:\temp\variable.ps1
QuestionMarkVars        : {isAwesome?, isabc?, adce?, def?, is a bad var name?}
QuestionMarkVarCount    : 5
NonQuestionMarkVars     : {abc, true, test}
NonQuestionMarkVarCount : 3

As they say in math class, "please show your work" 😄

Excellent sleuthing, @ThomasNieto - thank you.
I think you can potentially eliminate even more cases, given that the form ${...} will continue to work with the proposed change - e.g., it's only $isAwesome? we need to worry about, not ${isAwesome?}
With your example file:
$variables.Where({ $_.Extent.Text -match '(?<!\$)\?$' }).ForEach('Extent').Text | Select-Object -Unique

we only get:
$isAwesome?
$isabc?
$adce?

That is, ${def?} and ${is a bad var name?} needn't be considered.

@mklement0 That's correct, I added those cases right before posting to ensure the script was not excluding variables with the curly brace notation all together.
After updating the script with your recommendations the test file produces the following output like we expect.
File                    : C:\temp\variable.ps1
QuestionMarkVars        : {isAwesome?, isabc?, adce?}
QuestionMarkVarCount    : 3
NonQuestionMarkVars     : {abc, true, test}
NonQuestionMarkVarCount : 3

I ran the updated script on those 8 files and none of them are using the curly brace notation so the result is still 11 unique variables would be impacted with the proposed change.
Updated script:
Get-ChildItem -Path C:\Temp\PowerShellCorpus -Include *.ps1, *.psm1 -File -Recurse | ForEach-Object -Parallel {
    try {
        $content = $PSItem | Get-Content -Raw

        $ast = [System.Management.Automation.Language.Parser]::ParseInput($content, [ref]$null, [ref]$null)
        $variables = $ast.FindAll({$args[0] -is [System.Management.Automation.Language.VariableExpressionAst ]}, $true)

        $nonQuestionMark = $variables |
        Where-Object VariablePath -notmatch '\?$' |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $QuestionMark = $variables |
        Where-Object { $_.VariablePath -match '\?$' -and $_.VariablePath.UserPath -ne '?' -and $_.Extent.Text -match '(?<!\$)\?$' } |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $output = [pscustomobject]@{
            File = $PSItem
            QuestionMarkVars = $QuestionMark
            QuestionMarkVarCount = $QuestionMark.Count
            NonQuestionMarkVars = $nonQuestionMark
            NonQuestionMarkVarCount = $nonQuestionMark.Count
        }

        $output
    }
    catch {
        throw
    }
}

Thanks, @ThomasNieto - I was hoping we could get the percentage down to 0.0005%... (just kidding).
So the committee must have used a different - private? - corpus.
So, in addition to deciding the issue at hand, the question arises: does the publicly available corpus need updating? Is it officially maintained (currently dated 26 July 2017)?
@SteveL-MSFT, can you please clarify?

@mklement0 I rounded up so if you want to feel just a bit better its actually 0.00058% 😄
In https://github.com/PowerShell/PowerShell-RFC/pull/223#discussion_r318340339 @adityapatwardhan did an analysis using the same public corpus I used and came up with 62% with variables ending with a question mark. I didn't see a response on how he came up with that percentage. Did the PS committee use that analysis to determine this request?

Looking at the linked comment, I think what @adityapatwardhan is saying that  among all variables that have ? in their name  62% have a ? as the name's last character.
By contrast, your analysis about the actual prevalence of (braceless) ?-ending variables seems much more relevant.

At this point, it sounds like the committee is just saying "we don't want to" and if that's the case, why even have this feature if it's going to be clunky and un-used?

@mburszley Thanks for doing your analysis. I wanted to use another method (ast vs regex) to confirm the results you got last year.

I hear you, @mburszley, but re:

the committee is just saying "we don't want to"

If this truly was a fiat decision - one not grounded in analysis of real-world usage -  it wouldn't bode well for the community at large, especially given that the stated reason was a grounding in such analysis.
Thus, we should give the committee a chance to show the real-world usage analysis the decision was based on - or to recognize that the analysis fell short and reconsider the decision.

What about my suggestion in https://github.com/PowerShell/PowerShell/issues/11379#issuecomment-566756120?

I suggest doing it so that $obj?.Method() works as $obj?.Method() by default, and only fall back to $obj?.Method() when $obj doesn’t exist in scope, but $obj? does and #requires ‑Version isn’t v7+.

@ThomasNieto
@mklement0 is correct, I did mean that among the variables using ?, 62% use it at the end.
From the results shown in comment here seems all of the variables which use ? use it at the end. Hence the proposal to make a non-breaking change.
If the requirement for {..} is removed then the script will still parse but the semantics will be different, which in my opinion is very dangerous.

Sure... but analysis shows literally almost nobody is using them.
Same as any other breaking change, it can be announced, introduced as an experimental feature for a time, and then documented and brought into stable.
I see no reason to recommend an esoteric syntax when ? as an identifier character is not actually being used in a remotely significant number of cases.

If the requirement for {..} is removed then the script will still parse but the semantics will be different, which in my opinion is very dangerous.

Aren't you also worried about folks using ?. the way they do in C/C++/C# and getting the wrong result with no indication they did anything wrong?  For example:
PS> $res = "My length is 15"
PS> $res?.Length
0

Sure, strict-mode will find this but I don't know that a lot of folks use strict mode.  So, to prevent a very small percentage of scripts from breaking, it seems we're setting up a lot of folks for failure using ?..  I'm not crazy about the trade-off.  That said, I definitely understand the desire to avoid breaking folks even if it's a very small number of folks.
Maybe PowerShell needs an equivalent of Enable-ExperimentalFeature  call it Enable-PSFeature, for features that are no longer in the experimental state but are not ready to be turned on by default.  For scripts that execute with code like this $?.GetType() you could start emitting warnings that in the future this will break and that you should use ${?}.GetType() instead.  Individual scripts could enable the feature with a #requires -version 7.1 -feature PSNullConditionalOperators.  Then maybe whenever PS 8 hits, the feature could be enabled by default.

@rkeithhill 's example goes to straight to the point.
Forget for a moment what you know about how PowerShell works today.  When you see
PS> $res?.Length

It looks like name, operator, name - which of course it is.
Which would make more sense: "?" is part of the operator , or "?" is part of the first name-element  ?
If these operators are needed (and I think they are "not PowerShelly") its a choice between something which will be used incorrectly and a small amount of breakage.
I would start putting rules into  psScriptAnalyzer  now to say it's bad style to use certain [legal] characters in variable names.
I don't like Enable-feature. Someone puts it in script to make something they want to use work, and an old script breaks if run after the new script, (but works the rest of the time). I've seen third party script X fails after running script Y because Y turns on strict mode and X relies on it being off; the authors of both scripts are in my bad books.

I would start putting rules into psScriptAnalyzer now to say it's bad style to use certain [legal] characters in variable names.

Here's the problem: if you change the way PowerShell tokenises variables, PSScriptAnalyzer will see them differently too. If you have a variable like $res?, then looking at something like this:
{
$res?.Length
}.Ast.EndBlock.Statements[0].PipelineElements[0].Expression.Expression.VariablePath.UserPath

gives you
res?

BUT, if you change the way PowerShell is parsed in, say, 7.2, then you will get
res

Now PSScriptAnalyzer can't see the ?, because it's no longer part of the variable name (by definition, since it's the change we're trying to test for). This is because PSScriptAnalyzer is a PowerShell module and reuses the same parser that ships in PowerShell. (And it would be totally unmaintainable and a recipe for disaster if it tried to reimplement it).
There are ways around this, like conditionally compiling PSScriptAnalyzer (and shipping a whole new assembly) to test the new 7.2 logic to supply the same diagnostic. But then you've increased complexity everywhere (or alternatively decreased your test surface) to service a somewhat cosmetic scenario.
Worse, all the other tools out there that also rely on the AST won't have the capacity to sustain this kind of complexity even if PSScriptAnalyzer does. Most people building AST-targeting tools out there aren't going to compile against individual minor versions of PowerShell for perfect correctness. They probably won't even know about such a small breaking change, especially since it's not an error in any version; it's the most insidious form of breaking change, where one behaviour quietly becomes another.
That's basically what makes parser/tokeniser-level changes like this one more dangerous. Even PSScriptAnalyzer must bend over backwards to service them correctly, meaning they must be weighed against such onerous changes.

@rjmholt, while I think we can all appreciate how tricky a change like this is in principle, in this particular case it doesn't matter in practice, and I don't think a PSSA rule is even needed:

@ThomasNieto's analysis has shown that  - if we believe the corpus to be representative of all PowerShell code out there - that virtually no one uses variables with names that end in ?.

If I were to guess, most people wouldn't even think to use such variable names, because they wouldn't expect them to work (me included), and probably don't even notice the exception that the automatic $?  variable constitutes (whose name is equally an exception in POSIX-compatible shells such as bash).

In fact, looking closer at @ThomasNieto's analysis reveals that, among the 8 files listed:

5 contain only false positives, namely variables uses inside strings such as "Are you sure you want to kill $vParam?" - in fact, these uses are broken, and reveal that the script authors did not expect ? to be part of the variable name.
2 of those files are no longer publicly available.
Only 1 of them is a bona fide use ?-ending variables - as Boolean variables (e.g., $key1?), which, as an aside, are therefore not combined with the member-access operator, . /cc @stevenayers.

Based on the above this strikes me as a textbook Bucket 3: Unlikely Grey Area change, which is therefore acceptable - and I think the benefits of this change have been argued persuasively.
Documenting the change in behavior (with a rationale) should suffice.
Of course:

this is predicated on (a) the analysis being correct and (b) the publicly available corpus being representative.

it is starkly at odds with the committee's claim that "there was quite a bit of usage of variable names ending with the question mark"

Proceeding on the assumption that 1. is true (we haven't heard anything to support 2.), we have two options:

Rip off the band-aid and simply disallow ? in variable names going forward, unless enclosed in {...} (with the obvious exception of $?) - this will break the vanishingly small proportion of scripts that currently rely on that.

That is, something like $key1? that is neither followed by . nor a ternary expression ($key1?1:0) would cause a parser error.

As the ternary operator example shows, it too would benefit from this change - currently, you either need  a space - $key1 ?1:0 - or {...} - ${key1}1:0

Inside expandable strings, ? would then no longer be considered part of a (non-{...})-enclosed variable name, so we would actually fix existing scripts that have mistakenly used strings such as "Are you sure you want to kill $vParam?". 😁

If we really feel we need to avoid breaking the vanishingly small proportion of existing scripts, we could consider the logic proposed by @ExE-Boss, but I don't think we want to introduce this conceptual complexity - let alone implementation complexity (which I can't really speak to).

@SteveL-MSFT
Thanks for discussing this issue in the September community call (https://aka.ms/PSCommunityCall; as of this writing, the September call has not been posted there, but is accessible at https://aka.ms/JoinPSCall, until the next call), starting at 46:00, based on @ThomasNieto's suggestion in the prior solicitation for discussion topics at   https://github.com/PowerShell/PowerShell-RFC/issues/260:
(I was hoping to provide a direct link to the relevant portion of the recording, but that will have to wait until it is posted to YouTube and linked to at https://aka.ms/PSCommunityCall.)
Based on your remarks in the recording:

Given that you indicated willingness to revisit this, please reopen this issue and re-tag it as Review - Committee.

As for your remarks that enclosing variable names in curly braces is a preexisting feature and that people object to having to use them in this case on aesthetic grounds:

I don't think anyone here isn't aware that {...} can and sometimes must be used to disambiguate variable names.
It is also not about aesthetics, it is primarily about not getting the expected behavior  in  manner that fails quietly, due to not expecting to have to use {...} in this case; a secondary concern is typing inconvenience.

I'm concerned that this issue - now seemingly indefinitely in a closed state - will fall through the cracks, so I've opened #14025 as a reminder to revisit it, and I invite everyone who's interested to show their support there.


[Monitor] az monitor log-analytics workspace table: Add new command create and delete to support table operations, az monitor log-analytics workspace update: Add a new parameter --data-collection-rule to support update defaultDataCollectionRuleResourceId

Description

Microsot.OperationalInsights: Required CLI changes https://github.com/Azure/azure-cli/issues/20903
close https://github.com/Azure/azure-cli/issues/20903
wait SDK release(done)
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Monitor

Edge build

/azprun

@PARADISSEEKR Overall LGTM, just a minor suggestion.

/azp run

PR title is so loooong. Better to move to History Notes part in PR description


Feat: Share Skill Feature on Skill Detail View Controller

Fixes #487
Share Skill feature ob skill detail view controller
Screenshots for the change:

@jogendra , updated SS


Small Readme changes

Summary of the Pull Request
Small change. I removerd the "...or later" part because that must be rudimentary from "requirements/pre-requisits", but an installer only installs one version at a time.

PR Checklist

[x] Closes: #19805
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

@Jay-o-Way
Can you plz update title to be more descriptive.

Could also move "What's Happening" down to merge with "What's being planned for..."

To link directly to a download of your latest release asset that was manually uploaded, link to /owner/name/releases/latest/download/asset-name.zip.

https://docs.github.com/en/repositories/releasing-projects-on-github/linking-to-releases
Note to self

I expect a new version soon. Is there anything holding this?


Incorrectly rejected trigger with #[verifier::broadcast_forall]

The following code:
#[verifier::broadcast_forall]
pub proof fn test(x: int, y: int, z: int)
    ensures
        #[trigger] (x % (y * z)) == 0
{
}

gives the surprising error message:
error: variable `x` in trigger cannot appear in both arithmetic and non-arithmetic positions

Implemented in 2ca47a27261732856597d69adae772607a1e85d6


"self is not defined error" in Next.js project

After some headaches, I got react-monaco-editor successfully working in a Next.js project. Now I would like to integrate monaco-yaml. I added it to the configuration of next-transpile-modules, but now get the following error:
ReferenceError: self is not defined
    at eval (webpack-internal:///include-loader!../../node_modules/monaco-editor/esm/vs/editor/editor.api.js:1:1)
    at Object.include-loader!../../node_modules/monaco-editor/esm/vs/editor/editor.api.js (/workspace/myproject/.next/server/pages/module-editor.js:5778:1)
    at __webpack_require__ (/workspace/myproject/.next/server/webpack-runtime.js:33:43)
    at eval (webpack-internal:///../../node_modules/monaco-yaml/lib/esm/monaco.contribution.js:6:96)
    at Module.../../node_modules/monaco-yaml/lib/esm/monaco.contribution.js (/workspace/myproject/.next/server/pages/module-editor.js:11596:1)
    at __webpack_require__ (/workspace/myproject/.next/server/webpack-runtime.js:33:43)
    at eval (webpack-internal:///./app/module-editor/components/ModuleEditor.tsx:7:69)
    at Module../app/module-editor/components/ModuleEditor.tsx (/workspace/myproject/.next/server/pages/module-editor.js:5746:1)
    at __webpack_require__ (/workspace/m/.nextyproject/server/webpack-runtime.js:33:43)
    at eval (webpack-internal:///./app/module-editor/pages/module-editor/index.tsx:14:99)

Now I am a bit stranded as I have no clue what to try next to solve this problem. Does someone have an idea what's the cause of this error?

I noticed you’re using monaco-webpack-plugin. I recently found one project which uses monaco-yaml combined with monaco-webpack-plugin as well. Does this help you?

Thanks, I guess this helps with a problem that would occur (loading the correct worker) after my problem is solved :-) The current error occurs when calling setDiagnosticsOptions. Maybe it's more a problem of getting it to work with react-monaco-editor, not sure.
import { dynamic } from "blitz"
import { setDiagnosticsOptions } from "monaco-yaml"
import { ComponentType } from "react"
import { MonacoEditorProps } from "react-monaco-editor"

const MonacoEditor: ComponentType<MonacoEditorProps> = dynamic(
  () => import("react-monaco-editor"),
  { ssr: false }
)

export const ModuleEditor = () => {
  return (

      <MonacoEditor
        height={300}
        language="yaml"
        editorWillMount={() => {
          setDiagnosticsOptions({
            enableSchemaRequest: true,
            hover: true,
            completion: true,
            validate: true,
            format: true,
            schemas: [
              {
                uri: "http://myserver/bar-schema.json",
                schema: {
                  type: "object",
                  properties: {
                    q1: {
                      enum: ["x1", "x2"],
                    },
                  },
                },
              },
            ],
          })
        }}
      />

  )
}

Ok, it seems I found a solution (even if I don't understand all details ;-))
Maybe it will help someone else or there is room for improvement:
// blitz.config.ts (cause I use Blitz.js, but next.config.js should work similarly)

import { sessionMiddleware, simpleRolesIsAuthorized } from "blitz"
import bundleAnalyzer from "@next/bundle-analyzer"
import nextTranspileModules from "next-transpile-modules"
import MonacoWebpackPlugin from "monaco-editor-webpack-plugin"

const enableBundleAnalyzer = process.env.npm_lifecycle_event === "build"

const withTM = nextTranspileModules(["monaco-editor", "monaco-yaml"])

const withBundleAnalyzer = bundleAnalyzer({
  enabled: enableBundleAnalyzer,
})

module.exports = withTM(
  withBundleAnalyzer({
    webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
      // Allows the modules to find their module name during build time
      config.node = {
        ...config.node,
        __dirname: true,
      }
      config.plugins.push(
        new MonacoWebpackPlugin({
          languages: ["yaml"],
          features: [],
          filename: "static/[name].worker.js",
          customLanguages: [
            {
              label: "yaml",
              entry: "/workspace/myproject/node_modules/monaco-yaml/lib/esm/monaco.contribution",
              worker: {
                id: "vs/language/yaml/yamlWorker",
                entry: "/workspace/myproject/node_modules/monaco-yaml/lib/esm/yaml.worker.js",
              },
            },
          ],
        })
      )
      return config
    },
  })
)

// my editor component

import { dynamic } from "blitz"
import { setDiagnosticsOptions as _ } from "monaco-yaml"

const MonacoEditor = dynamic(() => import("react-monaco-editor"), { ssr: false })

export const ModuleEditor = () => {
  return (

      <MonacoEditor
        height={300}
        language="yaml"
        editorWillMount={(monaco) => {
          monaco.languages.yaml.yamlDefaults.setDiagnosticsOptions({
            enableSchemaRequest: true,
            hover: true,
            completion: true,
            validate: true,
            format: true,
            schemas: [
              {
                // Id of the first schema
                uri: "http://myserver/bar-schema.json",
                schema: {
                  type: "object",
                  properties: {
                    q1: {
                      enum: ["x1", "x2"],
                    },
                  },
                },
              },
            ],
          })
        }}
      />

  )
}

yaml seems to be attached to monaco.languages by the MonacoWebpackPlugin loader. And setDiagnosticsOptions must be called by monaco.languages.yaml.yamlDefaults.setDiagnosticsOptions and not directly. I still have to import it (import { setDiagnosticsOptions as _ } from "monaco-yaml", but only to satisfy the Typescript god as otherwise monaco.languages.yaml will report a TS error (this was the most cumbersome thing about this solution).
Hope this helps.

Thanks for showing your solution! I hope this helps other users as well.
I would like to explain what I think is going on based on your solution.
You’re importing react-monaco-editor dynamically, but monaco-yaml statically. Both import monaco-editor. As a result, monaco-editor is included twice in your bundle, once in your main bundle and once in the chunk generated by the react-monaco-editor import. Because of this monaco-yaml is applied to another instance of monaco-editor than the one of react-monaco-editor, causing it to simply not work. This also increased your build output size by a lot.
monaco-editor-webpack-plugin makes sure that monaco-yaml is also included with the react-monaco-editor chunk, which causes monaco.languages.yaml.yamlDefaults.setDiagnosticsOptions to be available. I would like to remove this API in a major release though, so I recommend not to use this.
Instead of using import { setDiagnosticsOptions as _ } from "monaco-yaml" to please the TypeScript gods, you could also add monaco-yaml to the types array in tsconfig.json. Although this isn’t necessary with the solution below.
Instead of dynamically importing react-monaco-editor, you could create a small wrapper file which configures both monaco-yaml and react-monaco-editor.
// monaco-setup.ts
import { setDiagnosticsOptions } from 'monaco-yaml';

export { default } from 'react-monaco-editor';

setDiagnosticsOptions({
  enableSchemaRequest: true,
  hover: true,
  completion: true,
  validate: true,
  format: true,
  schemas: [
    {
      // Id of the first schema
      uri: "http://myserver/bar-schema.json",
      schema: {
        type: "object",
        properties: {
          q1: {
            enum: ["x1", "x2"],
          },
        },
      },
    },
  ],
})

Then inside your editor component:
// my editor component

import { dynamic } from "blitz"

const MonacoEditor = dynamic(() => import("./monaco-setup.ts"), { ssr: false })

export const ModuleEditor = () => {
  return (

      <MonacoEditor
        height={300}
        language="yaml"
      />

  )
}

Now you could set the entry for custom language setup in monaco-webpack-editor-plugin  to undefined.

Thanks so much for the help and the comprehensible explanations! I tried your solution and it works perfectly.


navbar added

Navbar added as per your requirments
=> Output

Great work @developer-irfan 🥳
Merging🚀
__
  Summary: :trophy: This code is awesome

@Jai-Solania-29 already merged.


Directus Credencials not working

I just installed it with SQLite and the credentials are not working.

Did you use the credentials that are at the bottom of the /server/.env file?

@inluxc haven't heard back from you. Were you able to log in to Directus?

Sorry, long weekend, yep I used the credentials in the file.

Same problem here. Following the guide you provide, I first tried using<EMAIL_ADDRESS>like indicated here.

This clearly should be<EMAIL_ADDRESS>

We've switched to using the directus default example<EMAIL_ADDRESS>I'll update that file in the next release.


Space does not enable / disable breakpoint

found by @jvesouza

The problem seems to be fixed but orca does not announce the new status of the chek when I press space bar.
I need to navigate in the list of breakpoints to confirm that the check is checked or not.

The problem seems to be fixed but orca does not announce the new status of the chek when I press space bar.
I need to navigate in the list of breakpoints to confirm that the check is checked or not.

@jvesouza thanks for trying it out, thus adding verified label.
I also tried it with Voice Over and Voice Over nicely reads the status of the checkmark once it is changed.
Maybe @joanmarie has an idea why Orca is not announcing.
On the VS Code side we properly update the aria-checked attribute on the element.

@jvesouza thanks for trying it out, thus adding verified label.
I also tried it with Voice Over and Voice Over nicely reads the status of the checkmark once it is changed.
Maybe @joanmarie has an idea why Orca is not announcing.
On the VS Code side we properly update the aria-checked attribute on the element.

@isidorn My guess is that there is a missing state-change event (which would likely be a chromium bug since you are properly updating the aria-checked attribute). I'll take a look. But where exactly is this checkbox? Orca announces the state changes for the checkboxes I find when I search settings for "breakpoint."

@isidorn My guess is that there is a missing state-change event (which would likely be a chromium bug since you are properly updating the aria-checked attribute). I'll take a look. But where exactly is this checkbox? Orca announces the state changes for the checkboxes I find when I search settings for "breakpoint."

@joanmarie add a breakpoint in any file, for example a .js file by clicking on the gutter, or pressing F9.
Press Ctrl + Shift + D to open the Debug Viewlet on the left. Notice the BREAKPOINTS view, in the breakpoints view every breakpoint has a checkbox. You can click on the brekapoint for it to get focus and press space to toggle the checkbox.

@joanmarie add a breakpoint in any file, for example a .js file by clicking on the gutter, or pressing F9.
Press Ctrl + Shift + D to open the Debug Viewlet on the left. Notice the BREAKPOINTS view, in the breakpoints view every breakpoint has a checkbox. You can click on the brekapoint for it to get focus and press space to toggle the checkbox.

Hmmmm. I think I'm still confused. :(
@isidorn: Now I see BREAKPOINTS at the bottom of the Viewlet on the left. And the breakpoints there have a checkbox as you've described. (Thanks for telling me where to look!) The thing is.... Orca presents them (which I'll detail in a moment). But @jvesouza stated "I need to navigate in the list of breakpoints to confirm that the check is checked or not." This suggests to me that perhaps @jvesouza is not in that list of breakpoints when he is pressing space, and that he is navigating to that list in order to verify what he had done before. So.... Where are you José when you are pressing space?
In the meantime.... In order to capture a less noisy debug.out, I gave the breakpoint in the list focus, then quit and restarted Orca. Some observations:

When I first Alt+Tabbed into VSCode (where the breakpoint I wanted to toggle was already focused), the "Breakpoints" list claimed focus; the item with the checkbox did not. As a result, Orca just said "Breakpoints."
The first time I pressed space, I got a state-changed:focused for the checkbox. That caused Orca to present the name and state of the checkbox:

foo.py 1, Disabled Breakpoint
check box not checked.

The second time I pressed space, I got a children-changed:add event for a section (a div with class monaco-list-rows). The section was adding a checkbox. Orca noticed that the currently-focused (according to Orca) object had been destroyed and that the newly-added child checkbox happens to be focused. So Orca updates the focus and presents it to the user:

foo.py 1, ~/foo.py
check box checked.

Orca then gets a state-changed:focused event for the newly-added checkbox, which it ignores because it had already figured that out from the children-changed:add event.

So I fear I still don't know how to reproduce this problem. Perhaps @jvesouza could give me a full debug.out, along with some steps to reproduce the problem so that I can figure out where he is pressing Space?
@isidorn Are you able to reproduce this issue yourself?
Also, independent of this bug, when the list first claims focus, would it make sense to instead have the currently-selected item claim focus instead? Screen readers typically announce the changed context/ancestry, so I would think they'd all announce the "breakpoints" list if focus moved from outside the list to an item inside the list.

Hmmmm. I think I'm still confused. :(
@isidorn: Now I see BREAKPOINTS at the bottom of the Viewlet on the left. And the breakpoints there have a checkbox as you've described. (Thanks for telling me where to look!) The thing is.... Orca presents them (which I'll detail in a moment). But @jvesouza stated "I need to navigate in the list of breakpoints to confirm that the check is checked or not." This suggests to me that perhaps @jvesouza is not in that list of breakpoints when he is pressing space, and that he is navigating to that list in order to verify what he had done before. So.... Where are you José when you are pressing space?
In the meantime.... In order to capture a less noisy debug.out, I gave the breakpoint in the list focus, then quit and restarted Orca. Some observations:

When I first Alt+Tabbed into VSCode (where the breakpoint I wanted to toggle was already focused), the "Breakpoints" list claimed focus; the item with the checkbox did not. As a result, Orca just said "Breakpoints."
The first time I pressed space, I got a state-changed:focused for the checkbox. That caused Orca to present the name and state of the checkbox:

foo.py 1, Disabled Breakpoint
check box not checked.

The second time I pressed space, I got a children-changed:add event for a section (a div with class monaco-list-rows). The section was adding a checkbox. Orca noticed that the currently-focused (according to Orca) object had been destroyed and that the newly-added child checkbox happens to be focused. So Orca updates the focus and presents it to the user:

foo.py 1, ~/foo.py
check box checked.

Orca then gets a state-changed:focused event for the newly-added checkbox, which it ignores because it had already figured that out from the children-changed:add event.

So I fear I still don't know how to reproduce this problem. Perhaps @jvesouza could give me a full debug.out, along with some steps to reproduce the problem so that I can figure out where he is pressing Space?
@isidorn Are you able to reproduce this issue yourself?
Also, independent of this bug, when the list first claims focus, would it make sense to instead have the currently-selected item claim focus instead? Screen readers typically announce the changed context/ancestry, so I would think they'd all announce the "breakpoints" list if focus moved from outside the list to an item inside the list.

Testing more closely, I noticed something very interesting. I have in the breakpoint view three breakpoints, one being placed by me and two placed probably by java extension.
If I press the space bar on the breakpoint I put, orca behaves as expected, but if I press the space bar on one of the breakpoints placed by the extension, orca does not announce the change in status.
@joanmarie Can I send the debugfile in pvt?
Thanks.

Testing more closely, I noticed something very interesting. I have in the breakpoint view three breakpoints, one being placed by me and two placed probably by java extension.
If I press the space bar on the breakpoint I put, orca behaves as expected, but if I press the space bar on one of the breakpoints placed by the extension, orca does not announce the change in status.
@joanmarie Can I send the debugfile in pvt?
Thanks.

Hmmmm. I think I'm still confused. :(
@isidorn: Now I see BREAKPOINTS at the bottom of the Viewlet on the left. And the breakpoints there have a checkbox as you've described. (Thanks for telling me where to look!) The thing is.... Orca presents them (which I'll detail in a moment). But @jvesouza stated "I need to navigate in the list of breakpoints to confirm that the check is checked or not." This suggests to me that perhaps @jvesouza is not in that list of breakpoints when he is pressing space, and that he is navigating to that list in order to verify what he had done before. So.... Where are you José when you are pressing space?

I believe in the list of breakpoints because I press the space bar right after hearing the state of the breakpoint.
Anyway, I think that you will not be able to reproduce the problem in the face of what was reported in my previous comment.
I am debugging a java application and the breakpoints that do not have the status reported when I press the space bar were not placed by me but by some extension.

Hmmmm. I think I'm still confused. :(
@isidorn: Now I see BREAKPOINTS at the bottom of the Viewlet on the left. And the breakpoints there have a checkbox as you've described. (Thanks for telling me where to look!) The thing is.... Orca presents them (which I'll detail in a moment). But @jvesouza stated "I need to navigate in the list of breakpoints to confirm that the check is checked or not." This suggests to me that perhaps @jvesouza is not in that list of breakpoints when he is pressing space, and that he is navigating to that list in order to verify what he had done before. So.... Where are you José when you are pressing space?

I believe in the list of breakpoints because I press the space bar right after hearing the state of the breakpoint.
Anyway, I think that you will not be able to reproduce the problem in the face of what was reported in my previous comment.
I am debugging a java application and the breakpoints that do not have the status reported when I press the space bar were not placed by me but by some extension.

@joanmarie Can I send the debugfile in pvt?

Of course! You know where to find me. :smile:

Thanks.

Thank you!!

@joanmarie Can I send the debugfile in pvt?

Of course! You know where to find me. :smile:

Thanks.

Thank you!!

@jvesouza Those might be exception breakpoints that are added my the java extension? Anyways I just checked and all works fine for me also for exception breakpoints with Voice over.

@jvesouza Those might be exception breakpoints that are added my the java extension? Anyways I just checked and all works fine for me also for exception breakpoints with Voice over.

So... When things work in this particular set of objects, they work because Orca is treating the children-changed:add event as an event for a "context replicant" (The context is where Orca thinks you are; the replicant is the replacement object when the browser or web app sees fit to destroy the object you're on which, alas, happens surprisingly often. But I digress....)
For some reason, in the case of the failing checkboxes, Orca doesn't treat the children-changed:add event as an event for a "context replicant". Not sure what the point of rejection is, so I just added debugging output to Orca to spew out its decision-making process for this condition. @jvesouza: Sorry, but I'm afraid I have to ask you for a new debug.out after you pull Orca master. Thanks!

So... When things work in this particular set of objects, they work because Orca is treating the children-changed:add event as an event for a "context replicant" (The context is where Orca thinks you are; the replicant is the replacement object when the browser or web app sees fit to destroy the object you're on which, alas, happens surprisingly often. But I digress....)
For some reason, in the case of the failing checkboxes, Orca doesn't treat the children-changed:add event as an event for a "context replicant". Not sure what the point of rejection is, so I just added debugging output to Orca to spew out its decision-making process for this condition. @jvesouza: Sorry, but I'm afraid I have to ask you for a new debug.out after you pull Orca master. Thanks!


Error when compile Editor on MAC

I get the error：
/freetype/freetype/include -Idrivers/unix/vorbis drivers/unix/os_unix.cpp
drivers/unix/os_unix.cpp:229:2: error: no matching function for call to
      'localtime'
        localtime(&tv_now.tv_usec);
        ^~~~~~~~~
/usr/include/time.h:112:12: note: candidate function not viable: no known
      conversion from '__darwin_suseconds_t *' (aka 'int *') to 'const time_t *'
      (aka 'const long *') for 1st argument
struct tm *localtime(const time_t *);
           ^
1 error generated.

I was able to bypass this error by commenting the function call. I do not know how to make the compiler see this function though.

@hugocm93 thanks. After comment it ,compile success.


Cannot compile the SampleGallery project

When I try to run the SampleGallery project, it gives me the following error:

Cannot resolve 'GenXbf.dll' under path 'C:\Program Files (x86)\Windows Kits\10'.  Please install the Windows Software Development Kit. The Windows 8.2 SDK is installed with Visual Studio.

Looks like it's trying to locate the Windows 8.2 SDK from the path above, but the actual path to the Windows 8.2 folder on my machine is:

C:\Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v14.0

I do have the latest SDK (14295) with Visual Studio 2015 Update 2.
Any idea what went wrong? Thanks.

OK this is weird. I just changed the Target version in both projects from 10586 to 14295 and ran it again - it worked! Then, I changed both versions back to 10586. That worked too... I have no idea what was causing the initial error...


Fixes date format to be ISO-8601.

From the specification:

In representations the following characters are used as separators:
[-]  (hyphen): to separate the time elements “year” and “month”, “year” and “week”, “year” and “day”, “month” and “day”, and “week” and “day”;
[:] (colon): to separate the time elements “hour” and “minute”, and “minute” and “second”;
[/] (solidus): to separate components in the representation of time intervals and recurring time intervals.

Codecov Report

Merging #259 (9929a4d) into master (ba3cd92) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #259   +/-   ##
=======================================
  Coverage   95.27%   95.27%
=======================================
  Files          18       18
  Lines        1122     1122
=======================================
  Hits         1069     1069
  Misses         53       53

Flag
Coverage Δ

unittests
95.27% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ba3cd92...9929a4d. Read the comment docs.


Cannot find WSL in the Store

I am on fast-track insider program, just did a clean installation of windows and updated to Build 16215. I switched to Developer Mode.  I turned on the "Subsystem..." in control panel. I restarted the system, and typed "bash" in cmd, which prompts me to download WSL from "https://aka.ms/wslstore". I tried to open the link, but it finds nothing in the store, as shown in the screenshot. I have restarted several times, and the result remains nothing.

The screenshot includes everything; no scrolling down anymore.

Until the apps make it to the store, you can install by running lxrun /install from a CMD.

@sunilmut By the way, for those of us with customized environments using different distros, will those continue to function (or still be able to be created) after the Windows Store change?

@fpqc - yes your existing setups will continue to work.

@sunilmut  Just to clarify, is the app not in store for everybody, or is it just my computer?

@PowerSnail - The apps have not made it to the store yet. You can expect some public announcement (blog post etc.) in some form when the apps are available.

Also @bitcrazed for visibility.

If you search for SUSE in the store, you will find both SUSE Enterprise and openSUSE as distros that you can install.
As announced, these can be installed side by side with the other distros.

Yep, I have it installed now.  Lowkey where on the harddrive is the SUSE rootfs?

Hi @fpqc,
Yes, with the store model, everything is part of the package, both the rootfs and the home folders. When you uninstall, everything that the package installed gets removed. You might just need to tar your home folder if you want to uninstall.
To configure the default distro, you can run wlsconfig:
C:\Git\OSS\vcpkg>wslconfig /?
Performs administrative operations on Windows Subsystem for Linux

Usage:
    /l, /list [/all] - Lists registered distributions.
        /all - Optionally list all distributions, including distributions that
               are currently being installed or uninstalled.
    /s, /setdefault <DistributionName> - Sets the specified distribution as the default.
    /r, /register <Appx> - Registers a new distribution.
    /u, /unregister <DistributionName> - Unregisters a distribution.

You can still install Ubuntu with lxrun /install, we're working with them to get their distro in the store, it should not be long.

Yeah, I noticed the lxrun /install thing. I hope in the future if we get lxfs mounting as well (right now we only have drvfs mounts), we'll be able to set up mountpoints like in the legacy version.  I bet we can already do it if we reverse engineer /init between legacy and opensuse WSL installations.

@fpqc - You are on the right track. LxFs mount points are created when we start a WSL instance.  Store distributions have been moved to a single LxFs mount point which more closely matches most native Linux configurations.  If you'd like to add support for creating arbitrary LxFs mount points that is probably better served as a separate GitHub or UserVoice request.

Hey @benhillis if the new AppX system is going to work like this, maybe you could add some snapshot management to wslconfig like
wslconfig /snap AppX snapshotname
wslconfig /listsnaps AppX
wslconfig /restore AppX snapshotname
wslconfig /delsnap AppX snapshotname

for creating snapshots of the environments externally in case of breakage (and also create an initial readonly snapshot on installation in case you break everything).  Also, maybe something like:
wslconfig /tarhome AppX /path/to/filename
wslconfig /restorehome AppX /path/to/filename

to be able to copy your home directory from machine to machine. On a real Linux distro, you would do these kinds of management operations from a live environment, but obviously this is not easy to do with WSL.

@onomatopellan said "Right now there are 2 distros on the Store: SUSE Linux Enterprise Server 12 and OpenSUSE Leap 42" on https://github.com/Microsoft/BashOnWindows/issues/2250#issuecomment-310906041 and I found this article "SUSE Linux Enterprise Server and openSUSE are now on the Windows Store".

openSUSE Leap 42 - http://www.microsoft.com/store/apps/9njvjts82tjx
SUSE Linux Enterprise Server 12 - http://www.microsoft.com/store/apps/9p32mwbh6cns

Important Note: The initial SUSE distro's are very early builds and require a couple of updates before we go-loud & recommend their use.
PLEASE BE WARNED: If you do install the SUSE distro's before we formally announce their availability, you'll likely need to nuke & re-install soon afterwards.
We're hoping to have SUSE, Ubuntu & Fedora in the store and ready for broader use around a week from now.
Please keep your eye on our Command-Line blog and on my Twitter account for the formal announcement.

Marking as a bug so this lands on Rich's plate.

Looks like Ubuntu is in the Store now: https://blogs.msdn.microsoft.com/commandline/2017/07/10/ubuntu-now-available-from-the-windows-store/

Closing this out since Ubuntu is now available on Windows Store.

What ever happened to the Fedora distribution?

@wholroyd - We are still finalizing the details, but hopefully soon.

@benhillis - Sweet! Was all thinking it got canceled and no one said anything.


Setup kamban board

Two people are working on this project
@SnakyMz
@JavierAybar
https://github.com/users/JavierAybar/projects/6/views/1

Changes Required ♻
Hi Team,
Nice job, you are almost there.

(Changes Required) Aspects to improve: ♻

[ ] As requested by the previous reviewer, Please make sure that all Kanban cards have a description because there is one left without a description and you mistakenly added a comment to it not a description.

[Optional] suggestions:

Nothing to mention.

Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear, and please remember to tag me in your question so I can receive the notification**
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Approved ✔
Hi Team,
Great job, Your project is complete!  There is nothing else to say other than... it's time to close this issue and start working on the project :shipit:
GOOD LUCK 🤞

(Changes Required) Aspects to improve: ♻

N/A

[Optional] suggestions:

N/A

Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better.
**Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear, and please remember to tag me in your question so I can receive the notification**
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


standardize descriptive stats

Currently, descriptive stats are quite inconsistent. This leads problems e.g. if we want to calculate the number of characters pr. task to estimate the number of compute tokens needed.
All of these calculations could be automated and are in the _calculate_metrics_from_split, however, it is not calculated for all datasets. It would be great to have a test that tests that these are calculated consistently across all tasks.
Additionally, this data is currently included in the metadata, which might not be ideal (often requiring copy-paste, which could lead to potential errors). A solution could be to write it to a json from which the data is fetched when needed. Tests can then fail if this cache is not full.

I've been considering improvements to metadata_metrics as well.

A solution could be to write it to a JSON file from which the data is fetched when needed. Tests can then fail if this cache is not complete.

That's a great suggestion! Are you suggesting storing a JSON file with all the metadata directly in the mteb repository?

Yep - packaged into the package.


Running Django Application with superzippy

I am trying to create an executable with django application.I am not able to start my server because since it is a executable and django checks for management commands in commands dir it is throwing  following error
OSError: [Errno 20] Not a directory: '/tmp/vkmobileexe/site-packages/django/core/management/commands'
for reference this is my main.py
import os
import sys
def runserver():
PROJECT_PATH = os.path.dirname(file)
print PROJECT_PATH
sys.path.append(PROJECT_PATH)
import pdb;pdb.set_trace()
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "vkmobile.vkmobile.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(['manage.py', 'runserver', '8000'])
if name=="main":
runserver()

A full Django application is probably not the best fit for Superzippy. It might be possible, but I haven't tried it and I'm not sure how to move you forward with what you've sent me.
If you try py2exe you might have better luck. That program solves the same problem via an entirely different and more powerful method.


Resolves ExpendableLightVisualizer is Obsolete

About the PR

Splits the ExpendableLightVisualizer into a component/system pair.
TODO:

[ ] Testing

Media

[ ] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Reopen when you come back to this.

@DrSmugleaf
Commits tested and pushed. Reopen at your leisure.


Silences warnings in the console window.

This PR silences all Python warnings in the console window. To test, check your console and make sure that none of the warnings are noted.
Closes #128

I think the goal of #128 was to address the warnings, not silence them?  Not sure why we'd want to hide warnings in general.

It specifically said in the issue "shush the warnings" as an option, but I'll go ahead and close this PR.


Fixed a typo in the README

propety -> property

Hi @flagbug, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

Can you pls send this PR to develop branch, not master. Thanks!

@SergeyKanzhelev Changed the base branch of the PR
You should probably also change the default branch of the repository in Github, so people send PRs to the correct branch by default

@flagbug That is an excellent idea.


[macOS] Keyboard Shortcuts windows incompatible with dark mode

Hi, I find that the Keyboard Shortcut windows doesn't seem to have be compatible with dark mode.
It's still bright under dark mode, please see screenshot below

I noticed it is a html, can we perhaps have a native swift implementation?

Thanks!在 2023年1月14日，07:16，Maurice Parker @.***> 写道：
Closed #3781 as completed via #3809.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>


Improve mobile-marketplace-3

Need to improve this component: mobile-marketplace-3
Improvements required :
Design is not as per the Figma file
Any reference image?

Please assign me @Rajdip019

This component is already built in the same folder, I will be removing this file

Same.


Merge lines that are next to each other with no text into one big field

When the form has multiple lines in a row but it's one field--can we use heuristics to help people catch this?

Fixed in #55, will close when it's merged. It's only a first pass, but there's not a lot of other low hanging fruit here. Notably, a lot of multiple lines in a row have a partial line on the first row, i.e.
Why is Ladybird iconic? _________
__________________________________
__________________________________

There's no PDF field (to my knowledge) that can have all of the lines in the same field; you have to split off the first line into a separate field, or just skip it.

Yeah, my practice when you have a field like that (with a short first line) is to just skip it. I'm inclined to have doing that automatically be on our roadmap, but it's not a big manual cleanup task either.


Update use-silent-account-configuration.md

Remove word "master" from article.

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@adeejoseph PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Stop button not shown during playing state

Describe the Bug
The "Stop" Button is not shown in playing state of the player in iOS playing now lockscreen.
It works correctly on Android.
Code To Reproduce
    await TrackPlayer.add({...});
    await TrackPlayer.updateOptions({
      capabilities: [Capability.Stop, Capability.Play],
      compactCapabilities: [Capability.Stop, Capability.Play],
    });

service.ts
export async function service() {
  TrackPlayer.addEventListener(Event.RemotePlay, () => TrackPlayer.play());
  TrackPlayer.addEventListener(Event.RemotePause, () => TrackPlayer.pause());
  TrackPlayer.addEventListener(Event.RemoteStop, () => TrackPlayer.pause());
}

Environment Info:
iOS on a real device.
"dependencies": {
    "@types/cheerio": "^0.22.31",
    "cheerio": "^1.0.0-rc.12",
    "react": "18.2.0",
    "react-native": "0.71.6",
    "react-native-track-player": "^3.2.0",
    "styled-components": "5.3.9"
  },

I am not sure ios supports the display of a stop button – @jspizziri @dcvz do you have an idea on this?

@puckey I'm not 100% sure, but to my knowledge I've never seen a stop button on iOS. If correct, I think this really points to the confusion caused by how capabilites currently work (which I know we've discussed at length).

Here's the stop button on iOS. This is in my app which uses RNTP.


Update Heresy info to new companies format

Checklist

[x] Company name
[x] Industry
[x] Company location
[x] Company description
[x] How Elixir is used
[x] GitHub / blog links
[x] Job listings

Thanks for keeping things up-to-date @svileng!


Cpod 1.21 can't find a url site inf audio

CPod version: 1.21
Description of the problem:
I am trying to find this site http://feeds.gracia.org/gavpodcast. The site appears in Cpod but the not the audios. I can not suscribe, I can not do nothing. With others I do well, as: "aviva nuestros corazones"

Hi Lvaskz, the problem seems to be that http://feeds.gracia.org/gavpodcast is not an RSS feed. It works fine if you use http://feeds.gracia.org/gavpodcast&x=1 (found in the page you linked).
Let me know if that doesn't solve the problem. Thanks.

yes, it works, thanks