Mouse hover only works when mouse pointer is outside browser area [bug, Chrome only]

Bug report
I created a bug based on @csanthoshi 's original comment on this issue: https://github.com/angular/protractor/issues/159#issuecomment-242356184
In short mouse hover event won't happen in Chrome if you left the mouse pointer over the browser area (while it works on FireFox). Even if Chrome is not the active window of your OS. Without a fix testing all hover-based functionality (like a hover activated dropdown menu) is basically luck-based: either someone left the mouse pointer over the browser in one of the test-automation virtual machines or not.

I am unable to hover over an element( hyper link). I observed that when I placed my physical mouse pointer on the browser( launched through automation ) the element did not hovered but once I moved the physical pointer outside of the browser as soon as run gets triggered, the hovering action is passing successfully. I am running the script in chrome browser using protractor
The code snippet that I used is
browser.sleep( 8000 );
var ele = element( by.xpath( '//tf-infobox//[normalize-space(.)="Error 1"]/following-sibling:://a' ) );
browser.actions().mouseMove( ele ).perform();
browser.sleep( 5000 );
Additional Info: hover event is not fired.
Chrome-driver version: 2.21

My test setup to reproduce the issue:

Node Version: 7.0.0
Protractor Version: 4.0.11
Angular Version: 1.5.x
Browser(s): Chrome (only)
Steps to reproduce the bug

Start your test
(Manual step) Move your physical mouse pointer into the Chrome browser area
browser.actions().mouseMove(yourElement.getWebElement()).perform();

Expected result: hover event should be fired (it works on FireFox and Chrome if the physical mouse is outside the browser area).

If it works on Firefox and not on Chrome, this issue should be filed against the chromedriver project.

@cnishina Hi Craig, I have opened an issue: https://bugs.chromium.org/p/chromedriver/issues/detail?id=1634 . Thanks for the tip.


Clipboard Filtering Bug

Oscar, thanks so much for implementing the clipboard history filtering! It's working well, and quite fast. I check for Sol updates almost first thing every day.
I just wanted to report a small bug in the new functionality, which is that the selection index/offset is not updated logically during filtering.
For example, if my clipboard history is:

Foo

Bar
Baz

When I type "ba" in the filter field, then the list correctly shows (with updated highlight):

Bar

Baz

But then, when I press enter to paste "Bar", it actually outputs "Foo". I assume this is because the visual indicator updates to point to Bar, but internally there is another cursor that is still pointing to Foo that it uses to actually paste.
Using the arrow keys to move the cursor also doesn't seem to help. That is, if I press "down" to highlight Baz, and then "up" to highlight Bar, and then "enter" to paste, I still get Foo.
Hope this makes sense. This is in Sol v1.1.52.

You are right :) will take care of it later

Will be there soon

Should be there 1.1.52


java.lang.UnsupportedOperationException: sun.misc.Unsafe unavailable while using '-Dio.netty.noUnsafe=true'

Expected behavior
when using -Dio.netty.noUnsafe=true the following exception should not be thrown:
java.lang.UnsupportedOperationException: sun.misc.Unsafe unavailable
	at io.netty.util.internal.CleanerJava9.<clinit>(CleanerJava9.java:68)
	at io.netty.util.internal.PlatformDependent.<clinit>(PlatformDependent.java:193)

Actual behavior
So as i understand this is a debug log and does not impact functionality (only optimization) but when using -Dio.netty.noUnsafe=true the following exception is thrown, its unclear if this can be ignored and if it can be why not catch it, as we already explicitly say to not use unsafe:
java.lang.UnsupportedOperationException: sun.misc.Unsafe unavailable
	at io.netty.util.internal.CleanerJava9.<clinit>(CleanerJava9.java:68)
	at io.netty.util.internal.PlatformDependent.<clinit>(PlatformDependent.java:193)

Steps to reproduce
start java with property -Dio.netty.noUnsafe=true
Minimal yet complete reproducer code (or URL to code)
n.a.
Netty version
Netty 4.1.92.Final
JVM version (e.g. java -version)
11.0.3
OS version (e.g. uname -a)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"

@T3P0X I am not sure why you say this exception is thrown... its only logged in debug mode as the usage of sun.misc.Unsafe is not supported .

Please reopen if you still think there is a problem


running 'fable' fails

fable-compiler 0.5.10: Start compilation...
ERROR: F# project contains errors:
> This expression was expected to have type
    'JustifyContent'
but here has type
    'Alignment'     (L63,33-L63,49) (Styles.fs)
> This expression was expected to have type
    'JustifyContent'
but here has type
    'Alignment'     (L82,45-L82,61) (CheckLocationScene.fs)
> This expression was expected to have type
    'JustifyContent'
but here has type
    'Alignment'     (L49,57-L49,73) (LocationListScene.fs)

fixed see #8


MySQL Connection Issue

Description
Hi-- I'm trying to get started with Vessel but I'm unable to get the database working.  My .env file looks like:
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=testsite
DB_USERNAME=root
DB_PASSWORD=

Attempting to tail the mysql log shows:
$ ./vessel logs mysql
Attaching to testsite_mysql_1
mysql_1  | error: database is uninitialized and password option is not specified
mysql_1  |   You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD
mysql_1  | error: database is uninitialized and password option is not specified
mysql_1  |   You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD
mysql_1  | error: database is uninitialized and password option is not specified
mysql_1  |   You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD
mysql_1  | error: database is uninitialized and password option is not specified
mysql_1  |   You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD

OS
My OS is:

[x] MacOS El Capitan

Docker
The output of docker version:
Docker version 17.09.0-ce, build afdb6d4

The output of docker-compose version:
docker-compose version 1.16.1, build 6d1ac21

Sorry, read some more docs and see that a blank password can cause issues. I'll add that and rebuild the images.
Thanks

Or just set  MYSQL_ALLOW_EMPTY_PASSWORD

I’ll make a note to add that option to the docs too, thanks @cringer
On Fri, Nov 10, 2017 at 17:44 Jeremy Schaffer<EMAIL_ADDRESS>wrote:

Or just set MYSQL_ALLOW_EMPTY_PASSWORD
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/shipping-docker/vessel/issues/39#issuecomment-343616144,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAch0x-IDztkIwhUjT5ZlxGQFiZZ0AeMks5s1N_jgaJpZM4QaNNB
.


When describing a Work or Instance in the PCC template can the Sinopia editor dynamically suggest possible hasInstance/instanceOf URIs from Sinopia?

Describe the feature you'd like
Penn Catalogers are interested in streamlining the Work and Instance description. We primarily test the PCC templates and from our recent study of the editor we wondered if the system might auto-suggest the hasInstance/InstanceOf URI from Sinopia?
Give an example
A cataloger has already made the Instance description and in a new tab is now about to complete the Work description. The editor suggests a URI which could be clicked on to add as the hasInstance URI.
Vice versa for the Instance, if a cataloger has completed the Work description and is filling out the Instance -- can the instanceOf URI be suggested by the Sinopia editor, the cataloger can select or confirm the choice it by clicking.
In either case, If the suggested one is not the one desired, the cataloger still has the option to search.
Describe alternatives you've considered
The current way of searching for the instance or work in Sinopia, then selecting to add.

see also #2766


Startup Performance Challenge

Follow the directions found here: https://github.com/JonDouglas/AndroidPerformanceAndAppSizeChallenge

Startup Performance (Activity Displayed)

Before Startup Tracing:

+6s174ms
ActivityManager: Displayed com.wecodeteam.wecatalog/md568005e2ee5c7688cb55592014e6bc3cf.MainActivity: +6s174ms

After Startup Tracing:

+6s135ms
ActivityManager: Displayed com.wecodeteam.wecatalog/md568005e2ee5c7688cb55592014e6bc3cf.MainActivity: +6s135ms

Any comments / feedback for how we can improve this experience?
There´s no difference between both
Version Information (Help -> About Visual Studio -> Copy Information)
=== Visual Studio Community 2019 for Mac ===
Version 8.2.4 (build 17)
Installation UUID: 3bca4462-8ff0-4006-9932-97d349526284
GTK+ 2.24.23 (Raleigh theme)
Xamarin.Mac <IP_ADDRESS> (d16-2-fix-mac-updates / 86973979)
Package version: 600000327

=== Mono Framework MDK ===
Runtime:
Mono <IP_ADDRESS>7 (2019-02/f8ea05bddcb) (64-bit)
Package version: 600000327
=== NuGet ===
Version: <IP_ADDRESS>13
=== .NET Core ===
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
2.2.6
2.1.12
2.1.11
SDK: /usr/local/share/dotnet/sdk/2.2.401/Sdks
SDK Versions:
2.2.401
2.1.701
2.1.700
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/6.0.0/lib/mono/msbuild/Current/bin/Sdks
=== Xamarin.Profiler ===
Version: 1.6.11
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Updater ===
Version: 11
=== Apple Developer Tools ===
Xcode 10.3 (14492.2)
Build 10G8
=== Xamarin.Mac ===
Xamarin.Mac not installed. Can't find /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Version.
=== Xamarin.iOS ===
Version: <IP_ADDRESS> (Visual Studio Community)
Hash: c6691164
Branch: d16-2
Build date: 2019-07-29 15:54:05-0400
=== Xamarin Designer ===
Version: <IP_ADDRESS>9
Hash: 3f0652957
Branch: remotes/origin/d16-2
Build date: 2019-08-01 17:32:50 UTC
=== Xamarin.Android ===
Version: <IP_ADDRESS> (Visual Studio Community)
Commit: xamarin-android/d16-2/ebd65c9
Android SDK: /Users/mookiefumi/Library/Android/sdk
Supported Android versions:
8.0 (API level 26)
8.1 (API level 27)
SDK Tools Version: 25.2.3
SDK Platform Tools Version: 29.0.2
SDK Build Tools Version: 29.0.2
Build Information:
Mono: mono/mono/2019-02@e6f5369c2d2
Java.Interop: xamarin/java.interop/d16-2@d64ada5
LibZipSharp: grendello/LibZipSharp/d16-2@caa0c74
LibZip: nih-at/libzip/rel-1-5-1@b95cf3f
ProGuard: xamarin/proguard/master@905836d
SQLite: xamarin/sqlite/3.27.1@8212a2d
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-2@6f6c969
=== Microsoft Mobile OpenJDK ===
Java SDK: /Users/mookiefumi/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_<IP_ADDRESS>
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL
=== Android Device Manager ===
Version: <IP_ADDRESS>
Hash: 686c817
Branch: remotes/origin/d16-2
Build date: 2019-08-07 15:49:58 UTC
=== Xamarin Inspector ===
Version: 1.4.3
Hash: db27525
Branch: 1.4-release
Build date: Mon, 09 Jul 2018 21:20:18 GMT
Client compatibility: 1
=== Build Information ===
Release ID: 802040017
Git revision: 9b155edbf23e9fe8b477b3236a342164fabf5f6b
Build date: 2019-08-16 00:21:01+00
Build branch: release-8.2
Xamarin extensions: 9f2598b5f2371ba2903988c2cd87a9759d0255f2
=== Operating System ===
Mac OS X 10.14.6
Darwin 18.7.0 Darwin Kernel Version 18.7.0
Thu Jun 20 18:42:21 PDT 2019
root:xnu-4903.270.47~4/RELEASE_X86_64 x86_64
=== Enabled user installed extensions ===
Xamarin.HotReload <IP_ADDRESS>10000

@MookieFumi Thank you so much for your submission! To claim your swag, please fill out this quick survey!
http://aka.ms/androidappchallenge


WIP: Support Poetry in Paketo Python buildpack

Summary

Proposes the addition of implementation buildpacks which enable support for poetry dependency manager in the Python buildpack.
Use Cases

Users with apps using poetry as a dependency management tool will be able to build OCI images using the Python buildpack.
Checklist

[x] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[x] I have reviewed the styleguide for guidance on my code quality.
[ ] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

+1 for this. I'd also be happen to help with the implementation and / or testing.

Hi, @tclasen. That's great to hear! Please feel free to leave comments with any specific features that you'd like to see in the eventual implementation.


NO SEMANTIC DIFFERENCE: this is a troundtrip commit to restore canoni…

…cal ordering

So these look like they are from what I added yesterday but I saved out of Protege; shouldn't that have re-ordered them.
My workflow: add several stanzas at end of file ahead of first [Typedef] stanza after last real go term, using vi.  Save, then load into protege. Do a little checking that things are ok, then save file to my branch, then commit... then push;

So I just did a load and save as from my copy from yesterday and it resorted; I could have sworn I did a save from protege


Exception generator has no attribute next

Hi
I encounter the following error on line 265 of train_frcnn.py
Exception generator has no attribute next
due to
X, Y, img_data = data_gen_train.next()    on line 167
Could you please help me out  :)

I even tried this
X, Y, img_data = next(data_gen_train)
instead of
X, Y, img_data = data_gen_train.next()
but get an Exception error
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "train_frcnn.py", line 265, in
print('Exception: {}'.format(e))
KeyboardInterrupt

Have you solved this problem?

I meet the same problme, have you solved it?

try data_get_train.next(),
but I meet another exception when cal roi

try  data_get_train.__next__()
but I meet another exception when cal roi

this repository has some problems, there is a fixed one, https://github.com/you359/Keras-FasterRCNN

thx a lot ，and I also fixed this repo and it now works well on my own dataset


Is it time for "PowerShell vZeroTechnicalDebt" and/or for an opt-in mechanism into new/fixed features that break backward compatibility?

Note that the term technical debt is used loosely here to mean "accumulated broken behavior that can't be fixed without breaking backward-compatibility"; strictly speaking the term has a different, specific meaning.

Update: @rjmholt has started a discussion about how to implement and manage breaking changes: #13129.

Note: This issue, which arose out of https://github.com/PowerShell/PowerShell/issues/5551#issuecomment-380522712, is just to get the discussion started to see if there's a fundamental willingness to entertain such changes. Eventually, RFC(s) are needed.
PowerShell's steadfast commitment to backward compatibility has served the community very well over the years.
On the flip side, the inevitable by-product was the accumulation of technical debt that requires memorizing exceptions and is a barrier to newcomers.
Certain fundamental problems that exist today can only be solved at the expense of backward compatibility, and there are two - not mutually exclusive - ways to handle that:

Implementation of a "PowerShell vZeroTechnicalDebt" edition that sheds all technical debt, but forfeits backward compatibility (possibly with future versions using semantic versioning to indicate compatibility)

Integration of backward-compatibility-breaking features / fixes into the existing code base, available strictly on an opt-in basis only.

Which approaches, if any, are we willing to consider?
Once we have clarity on that, we can flesh out the processes.
Here are some of the existing fundamental problems that can only be solved at the expense of backward compatibility; I'm sure others will think of more:

The complexity and inconsistency of current error handling and problematic [lack of] integration with "native" (external) programs - #3996

Inconsistent, hard-to-predict preference-variable / common-parameter inheritance - #4568

Performance issues due to [object[]] being the fundamental collection type - https://github.com/PowerShell/PowerShell/issues/5643#issuecomment-378467986

While PowerShell understandably will never match the speed of Unix utilities, it is all the more important to make interop with them predictable and as painless as possible - see remaining issues re quoting and parsing.

Problematic dynamic features that should work lexically: https://github.com/PowerShell/PowerShell/issues/3879#issuecomment-304940545 re break and continue, https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC0003-Lexical-Strict-Mode.md re Set-StrictMode (though the latter may be fixed without breaking compatibility)

[psobject]-related problems (though perhaps they can be fixed without breaking compatibility):  #5551, #5579, #4343, #5763

The unfortunate -LiteralPath / -Path split - brief rationale at https://github.com/PowerShell/PowerShell/issues/6714#issuecomment-383992749 and escaping woes at https://github.com/PowerShell/PowerShell/issues/6714#issuecomment-384353966 (not sure there's a good solution)

Broken quoting for external programs - #3734, #5576 (and others) and the related languishing RFC

-Command and -File CLI argument parsing - https://github.com/PowerShell/PowerShell/issues/4024#issuecomment-311541803, #3223 - and general misalignment with the CLI of POSIX-like shells - #3743 - including user profiles getting loaded by default even in non-interactive (script) invocations - #992

Inconsistent and surprising parsing of compound command-line arguments - #6467 - and non-parameter tokens that look like parameters - #6291, #6292, and #6360

Broken handling of ValueFromRemainingArguments parameters, as argued in https://github.com/PowerShell/PowerShell/issues/2035#issuecomment-323816221, with broken behavior shown in  #5955 and #5122 - going back to https://github.com/PowerShell/PowerShell/pull/2038

Environment data
Written as of:
PowerShell Core v6.0.2

Interesting.   I've always wondered why the 1 in .ps1 would be used to add a sort of semantic versioning to PowerShell scripts, allowing a script to indicate if it was adapted to possible breaking changes.

There many expensive to fix problems which I think of as the technical debt of PowerShell not adopting new .NET concepts as they came along

Language syntax for type parameters for generics methods #5146

Engine support for Extension Methods to automatically surface in the type system (like they do in compiled .Net languages). #2226

Language support for async APIs #6716 (and RFC)

There are a few regrettable features:

Could we do something based on on type hints (like @KirkMunro's FormatPx) instead of cmdlets that output formatting objects? #4594 #4237 #3886

Would you normalize the Registry provider to be content based -- instead of feeling like a demo of how a property provider could work? #5444

Would you refactor PSProviders deeply to make them easier to write? It's a shame that it takes two layers of abstraction to arrive at "SHiPS" and finally give people a way to write providers that they're willing to use

How about a bigger question:
Would we be willing to reconsider the "many ways is better" approach and work on a "pit of success" approach? I mean, would we be willing to remove features that are considered "the easy way" but which are fundamentally worse, in favor of having only "the right way" to do things? E.g.:

Make CmdletBinding always on
Make @() notation mean a List
Make @{} notation mean a Dictionary<PSObject, PSObject>(or Dictionary<string, PSObject> 😲)
Make Process the default block
Maybe even make ValueFromPipelineByPropertyName the default ;-)

All great suggestions, @Jaykul.
Re making @() notation mean a List[PSObject]:  I think we can take this further and use an efficiently extensible collection type as PowerShell's fundamental collection type, so that it it used wherever [object[]] currently is (and is used internally as well as when returning collections, with no type-conversion performance penalty); there are challenges around + use, but @PetSerAl has suggested a custom list implementation to deal with that.
Re making Process {} the default block in functions, as an aside: it's what Filter currently does, but it is limited to the - implied - Process block, and this function variant seemingly never really caught on; unifying the two in the context of Function makes sense to me.

Funny, on the Azure PowerShell community standup call right now, and they're going to move from AzureRm to a new Az module that is cross platform (no separate AzureRm.Core), and with all command prefixes changed from AzureRm to Az. The two will be side by side for a while, but they're moving to the new command set. Too bad PowerShell hasn't had an opportunity yet to create a new executable that would run side-by-side with Windows PowerShell, but that could break away from some of the legacy crud that drags it down.

Just imagine what would happen should we go for it:
Realistically speaking it would take at least 6 months of focussed effort to come up with a 'no regrets' version and another 6 months to reiterate on it. Then 3rd party modules need to adapt to it as well in order for this version to be useful, which will take at least another 6 months to get a reasonable coverage... Then account for delay and unexpected problems, etc... So, no, I think it is only wishful thinking that one can get rid of all technical debt in one version in one go (and still develop and not just maintain the old version).
As much as I wished that such a version existed, I think it will only be possible to get to it slowly one breaking change at a time. With v6 a lot of breaking changes were already accepted but I think if one includes too many breaking changes in one version, it will become too complex to upgrade existing scripts/modules. It's good to discuss the most valuable breaking changes but until there isn't an LTS version of pwsh, I do not think it is time to think about having a 2nd train of pwsh with more substantial changes in parallel to the existing mainstream version.

Python 3 is certainly the horror show, has it really caught on yet?  I'm still running 2.7, and don't plan on upgrading any time soon.
I think the lessons to learn from Python there are to separate breaking changes to the language from a version change to the engine.    Hypothetically, a PS 7 engine could still run earlier scripts (.PS1) files in a no-breaking changes mode, while if the script were marked as 7 aware (say with a .PS7 extension) they could declare they have been updated and that the require at-least PS 7 to run.      Hope that makes sense.

Perhaps the best success story is JavaScript/TypeScript.

Javascript is a special case. You're pretty much stuck with it so transpiling is really the only option. Typescript is "just" Javascript with extensions so it's easy for people to adopt. Any javascript program is a typescript program so you start with what you have and  just add annotations from there. Dart, on the other hand, is it's own language but transpiles to either javascript or a native runtime in Chrome (at least that was the plan at one point). Dart doesn't seem to have picked up much adoption outside of Google, likely because it is its own language..
@BurtHarris

Python 3 is certainly the horror show, has it really caught on yet?

I was reading an article last week where the author was claiming critical mass had been achieved for Python 3.  That all the core modules were available and now people where migrating in droves. We shall see..

Interesting. I've always wondered why the 1 in .ps1 would be used to add a sort of semantic versioning to PowerShell scripts, allowing a script to indicate if it was adapted to possible breaking changes..

WRT .ps1, we reserved the right to change the extension in case we got the language completely wrong resulting in  catastrophic changes to the runtime  such that scripts for the previous version just wouldn't work. But changing the extension also leads to a huge pile of work because so many things in the ecosystem are tied to an extension.  So it's not something to do lightly. And of course, being part of Windows, if we forked the extension, we'd still have to maintain both versions (kind of like Python 2/3).

@bergmeister:
Valid concerns, but in the spirit of:

It's good to discuss the most valuable breaking changes

please share any that you may have in mind.

slowly one breaking change at a time

While a (lexically scoped) opt-in mechanism for incompatible changes is a solution, I'm concerned about two things:

Piecemeal introduction can lead to no one being able to remember which version is required for what feature; Perl (v5-) comes to mind.

The code base becoming bloated and hard to maintain, and the resulting binary being equally bloated, which hurts (at least) startup performance.

I've said it before: to me - and this is just a hunch - the v6 GA was an unfortunate compromise between making old-timers unhappy with breaking changes while carrying forward enough baggage to hinder adoption In the Unix[-like] world.
That said, given PowerShell's relative youth in the Unix[-like] world, perhaps there is (still) more of a willingness to work out problems by way of incompatible changes. As @BrucePay states, Windows PowerShell will have to be maintained anyway, and it can remain the safe haven for backward compatibility.

I think the scale of the negative consequences of such breaking changes has already been covered, and I agree with most of those points.  I am writing this because I am doubtful that, in the greater context, these changes would yield significant benefits in the first place.  At least for the way I use PowerShell.
The OP includes the following statement:

On the flip side, the inevitable by-product was the accumulation of technical debt that requires memorizing exceptions and is a barrier to newcomers.

The implied premise of this statement seems to be that making these various breaking changes would alleviate the burden of memorizing exceptions.  Indeed that would be a great outcome.  However, I am skeptical that that would be the result.  PowerShell's behavior is deliberately rich.  This makes it both expressive and unpredictable.  Expressiveness and predictability seem to work against one another, at least amongst the languages I am familiar with.
While I agree that many of the breaking changes mentioned above would improve predictability somewhat in some cases, many unpredictable and surprising aspects of the language will remain.  Despite spending years writing PowerShell, I am still frequently surprised by PowerShell behavior that seems to be by design and probably shouldn't be changed.  Some recent examples that come to mind are as follows:

conditional delayed binding of [scriptblock] arguments (#6419)
when, exactly, implicit enumeration occurs (#5832)
conversion of [AutomationNull]::Value to $null during parameter binding (#6357 is related)
the impact of break and continue on flow of control in the pipeline (#5811)
what happens when you splat $null (SO)
how using scriptblocks across session states affects $_ (SO 1, SO 2)

I expect that these examples are just a small fraction of the many other carefully-designed but surprising nuances I have not yet discovered.  I selected these examples because

they represent behavior that probably can't be improved upon in PowerShell, and
I have no hope of reliably spotting all of their implications when reading or writing PowerShell.

I'm fine with this.  The overwhelming majority of surprising PowerShell behavior does not have lasting impact on my success with PowerShell.  Surprising behavior is almost always caught immediately by testing during development.  I learn from the things that slip through and use that to improve my testing strategy.  This is true whether those surprising behaviors are the kind that could be eliminated or the kind that must remain.
Whether the proposed breaking changes above are made to or not, PowerShell will never become so predictable that I can significantly reduce test coverage.  In other words, the way I use PowerShell, I don't think there's much of an upside that's even possible by making the breaking changes proposed above.
(BTW, thank you @mklement0 for directly asking this question.  This has been in the back of my mind for a while.  It's good to see the opportunity for everyone to say their piece.)

Thanks, @alx9r.
I think it's important to distinguish between intrinsic complexity and extrinsic complexity:

Intrinsic complexity stems from the inherent complexity of the concepts being implemented and, in the case of PowerShell has two primary sources: internal complexity from introducing a new paradigm (object-base pipeline) and marrying two distinct worlds (shell syntax and programming-language syntax), and external complexity from interfacing with multiple, disparate outside worlds.

Intrinsic complexity is managed by documenting concepts and features properly and also given them names.

#6419 is a prime example: a powerful and widely useful feature underlies it, but it is presently not documented at all, as far as I know, and it has no established name; see https://github.com/PowerShell/PowerShell-Docs/issues/2338

The member enumeration feature similarly lacks an established name and focused documentation - see https://github.com/PowerShell/PowerShell-Docs/issues/2198

An extrinsic aspect of member enumeration is discussed in #6802.

#5832 is another candidate for proper conceptual documentation.

However, you've discovered two extrinsic aspects of the current behavior: giving all scalars not just a .Count, but also a .Length property and parameter-binding enumeration behavior being subtly different from pipeline/operator behavior.

Extrinsic complexity stems from leaky abstractions and inconsistencies.

Such complexity should be eliminated .

If that is not an option due to backward-compatibility concerns, such complexity should be documented as known problems.

The script-module variable scoping behavior (which you reference in the context of $_) is more than just a quirk: it is the root cause of a major problem, the previously mentioned #4568.

All other issues you mention strike me as falling into the extrinsic category (rather than being the result of careful design), because they all present as inconsistencies that have no obvious (documented) rationale or benefit:

It makes more sense for splatting with $null to pass no arguments rather than a positional $null argument.
Why would [System.Management.Automation.Internal.AutomationNull]::Value be converted to $null during parameter binding, even though you the type is preserved in direct variable assignment?
What benefit is there to the dynamic scoping of break and continue, across the call stack, with quiet termination if no enclosing loop is found?

While the wealth of features and the joining of disparate worlds alone makes it hard to remember all requisite intrinsic complexity, minimizing the extrinsic one is still important.
Having to test your intended approach first without just knowing and trusting that it will work - or to have things break unexpectedly due to surprising behavior - is a serious productivity (and enjoyment) hindrance (even though PowerShell commendably makes it very easy to interactively test behavior).
It comes down to solid concepts (that don't contravene intuitive expectations), descriptive naming, and good documentation:
If I don't know it / not sure if I remember correctly, I need to know where to look it up, and have faith that known problems and edge cases  are also documented (either as part of the regular help topics or via links from there).
So even if we decide that eliminating extrinsic complexity is not an option, we can at least document it systematically - and the discussion here can serve as the starting point for compiling a "pitfall gallery" (which may also include cases of unavoidable intrinsic complexity that may be surprising).

we can at least document it systematically - and the discussion here can serve as the starting point for compiling a "pitfall gallery"

Roman Kuzmin has been collecting such a gallery for a while, here: https://github.com/nightroman/PowerShellTraps

Thanks, @HumanEquivalentUnit - that looks like a great collection.
Along with the issues collected in this thread, it could form the basis for a gallery that is part of the official documentation, witch each entry augmented with, as appropriate:

a design rationale that explains why the behavior, though perhaps surprising, is justified after all (a properly framed explanation may make the element of surprise may go away)

an acknowledgement of the problem, stating that:

either: it won't be fixed in the interest of backward compatibility.
or: that a future change is being considered
or: that the issue is already fixed in PS Core

It's strange that it has to be asked if it's time for "PowerShell vZeroTechnicalDebt"
Exactly for this there is a required version command.
If something breaks in a new version, the only pain we get is that we have to study and learn the usually small differences.
But we (finally) get a platform, which really gets better with each iteration in the core. And much easier to maintain.
No, it's never a question to kick off bad designs and decisions by new knowhow and technology.

Also, to flog the living s**t out of a dead horse, it's still stupendously hard to write a well-behaved function or cmdlet that deals with the magical differences between the host's native filesystem and the filesystemprovider. Such nuanced code is difficult to write and often gotten wrong. Here's a post on stackoverflow I answered about seven or eight years ago that's still valid:
https://stackoverflow.com/questions/8505294/how-do-i-deal-with-paths-when-writing-a-powershell-cmdlet

Ref: #8495
There are some strange operator precedence rules that deserve revisions:
PS> 1, 2, 2 + 1, 4, 4 + 1
1
2
2
1
4
4
1

In most languages, one would more commonly expect this to be the output:
1
2
3
4
5

One option that has its own pros and cons is a new feature flag to enable all of the "ideal" behavior so that it's opt-in.  If we had some telemetry indicating that most of the usage has moved to the new behavior, we could flip it so it's opt-out.  This might all just be a pipe dream as I haven't seen any real world case where such a model worked...

Indeed that would be nice, but given the rather... thorough... nature of some of these revisions in this thread, it risks potentially completely splitting compatibility of scripts between "normal" and "experimental", and potentially into several pieces, depending on which flags an individual has enabled.
This means we can't really rely on anything that is an experimental feature in that way, nor write scripts and modules that rely on them, unless we attach a huge warning to the docs pages, or potentially prevent them from being imported unless certain flags are enabled.
This might be avoidable, however... if we can, at will, enable and disable specific experimental features on a per-each-module-scope basis. But, given that that only further complicates matters, I'm not even sure if that's a particularly great solution, either.

@vexx32 just to be clear, I wasn't suggesting an experimental flag which would eventually become non-experimental.  I was thinking something different (perhaps more like Enable-PSFeature as it would be officially supported (and thus protected from breaking changes unlike experimental features)).  I was also thinking it would be a single flag where you opt into these new breaking changes as a set rather than individually.

Oh, in that case... Yeah, absolutely. That would let us neatly package everything together under a single umbrella, and actually use it. Much better than what I was thinking! 😄

@jszabo98's addition to the list of issues compiled here, based on #8512:
-and and -or unexpectedly have the same precedence, whereas in most languages (including C#) -and has higher precedence than -or.
Example expression that contravenes expectations:
PS> $true -or $true -and $false
False

Due to left-associativity and -and and -or having the same precedence, the above is evaluated as ($true -or $true) -and $false rather than the expected $true -or ($true -and $false)

This might all just be a pipe dream as I haven't seen any real world case where such a model worked...

In fact, we already have a model that works all over the world - LTS. MSFT uses this to develop Windows 10. The model is used to develop Unix distributions.
For us, this means that we could release LTS PowerShell Core versions every two years and include them in Windows 10 LTS versions and Unix LTS version. (One problem is to sync Windows and Unix release dates for LTS versions. I guess MSFT can negotiate with the main Unix companies.)
During these two years, we are collecting minor breaking changes, transferring more significant breaking changes to the next cycle.
For each new LTS version, the ScriptAnalyzer should get a set of new rules to facilitate script migration.
With this model, critical products and scripts will only have to jump from the previous version to the next after thorough testing and migration.
I used this approach when I migrated step by step (version by version) an old system from PHP 4 version to next PHP version until I reached the supported PHP 5.x version.  At each step, I had to make relatively small and quick changes, after which the system continued to work for some time until the next step.

Regarding having multiple versions of powershell which have different feature sets and breaking changes:  We already have this with legacy and core.  Which seems bad at first glance but may provide a working model for the future.  Stay with me...
We have to set almost all processes which use powershell to call the core pwsh.exe before running the actual scripts because Windows scheduled tasks, jenkins, and many environments are not powershell core aware.  We do this because we are using features which are only available in a particular PS version.
In cases where we cannot force a call to core we have to have every script check which version of PS it is running under and then call itself using the appropriate PS version on the host system.   Whatever trick we use to get the right code to run in the right environment we often are passing all of the environment and parameters to the same script that was already running.
That is the UNIX philosophy.  Make a tool do one thing and do it well.  Then combine tools to create a whole that is greater than the sum of its parts.  This is the world of scripting where we make subshell calls to other utilities all the time and process results.  Historically that is scripting.   Powershell trends toward a strange convention by trying to keep all the code native but that is only a convention--not a requirement.  PS runs with access to the OS and all the utilities available just like unix shell scripts.
This would be much easier if the file extension for core had been updated to .ps6 so the powershell engine could be doing the work for us.   Each binary version of powershell can remain independent of the others as long as every call to one passes environments and returns the outputs, errors, warnings, exceptions, to the other--which we have to do manually right now at great effort.  It is not necessary to have backward compatible flags in the engine as long as the engine knows which version to run.  The context switching involved is already happening so we are already at worst case scenario.
We will be forced to use awful hacks in powershell forever UNLESS we go ahead and break things in a well defined manner.  Breaking changes are not going to make our lives any more difficult than they already are.  Alternatively, if we use incremental, continuous improvement and have the engine do the heavy lifting of switching context then our code (and lives) will be better.

@jtmoree-kahalamgmt-com Thanks for your feedback! Fill free to open new issues to share your experience and feedback and ask new helpful features.

This would be much easier if the file extension for core had been updated to .ps6 so the powershell engine could be doing the work for us.

See https://github.com/PowerShell/PowerShell/issues/2013#issuecomment-247987977
And I created https://github.com/PowerShell/PowerShell/issues/9138 based on your feedback.

Python 3 is certainly the horror show, has it really caught on yet? I'm still running 2.7, and don't plan on upgrading any time soon. But I haven't heard much about Perl 6 recently either...
I think the lessons to learn from Python there are to separate breaking changes to the language from a version change to the engine. Hypothetically, a PS 7 engine could still run earlier scripts (.PS1) files in a no-breaking changes mode, while if the script were marked as 7 aware (say with a .PS7 extension) they could declare they have been updated and that the require at-least PS 7 to run. Hope that makes sense.

I think calling Python 3 a horror show is overly dramatic.  If I look at PyPl top downloaded packages, and grab the individual package metadata about v2 vs v3 downloads, I see v3 has now broken 33% penetration for pretty much all the top packages, and for newer libraries like Ken Reitz' requests library, it's nearly 50/50 split: yesterday there was 685k downloads of v3, vs 875k of v2.
The major thing holding Python 3 back for a long time was scientific community support for pandas and pysci.  But, in the latest stats, the scientific community now prefers Python 3 to Python 2: https://pypistats.org/packages/pandas 231k v3 downloads, vs 175k v2 downloads.
As the famous Dr. W. Edwards Deming would say, "In God we trust; all others, bring data!"  Maybe you can write a PowerShell script to analzye the PyPl data set and tell me how horrific Python 3 is using data: https://packaging.python.org/guides/analyzing-pypi-package-downloads/

I would be happy with:

Easier to use module system that produces good stack traces.

For example, psm1 file allows to describe arbitrary rules for how functions are loaded, but this causes cryptic stack traces where all functions are globbed into the psm1 file logically. This means line numbers on stack traces are about as useful as a chocolate teapot.

Replace PowerShell default Error object string formatting that swallows 99% of the usefulness of programming in a stack-based von Neumann architecture.

C# more or less gets this right. PowerShell is too clever by half.

Fix null redirection so that the three different ways to redirect output streams to the null device are equivalent in performance.

Rewrite PowerShellGet. It's AWFUL. Functions with hundreds of lines of code, swallowed exceptions, no test coverage.

Get rid of how module caching works.

Provide "compiled modules" similar to how Py files compile to pyc files for performance improvement.

@jzabroski Regarding ErrorRecord formatting, there's a separate issue used to discuss that: https://github.com/PowerShell/PowerShell/issues/3647, since formatting is not considered a breaking change, we can make improvements there.
Some of your other requests are potentially additive and not breaking so those should be separate issues.  This specific issue is discussing requests for breaking changes if we had an opportunity and could justify doing a new major version of PS.

Which ones do you think are potentially additive?  I can create issues for them so we don't derail this discussion, but I carefully put together this list this morning.    PowerShell is a bowling ball with a butcher knife.  My top 5 most embarrassing moments as an engineer all happened while using PowerShell.  I'll never get that time back.

Output accumulates; return does not do the same thing as other languages; fix it.

return does behave as you expect it to within a class method.  The way "output accumulates" in a regular/advanced PS function is pretty typical for shell scripting environments e.g Korn shell and Bash.  That is, copy several commands from the console and put them in a function.  When you invoke that function, it outputs from each command just as when you executed those commands from the console.
My primary gripe with PowerShell is this that in the regular/advanced function case, return should have never taken arguments. Because something like:
return $foo

is really executed as:
$foo
return

This gives folks a sense that they can control the output by using return and they can't.

return does behave as you expect it to within a class method. The way "output accumulates" in a regular/advanced PS function is pretty typical for shell scripting environments e.g Korn shell and Bash.

I hear people say this, including @BrucePay , but the bottom line is:

In Korn Shell, return exits a function, period.
In Bash, return exits a function, period.

Only in PowerShell do we have this illogical "return does not return" non-sense and output accumulates.  This is a glorified memory leak, and you should think of it as such.
To be honest, everywhere in PowerShell In Action I search for the phrase "problems", I can add something to the vZeroTechnicalDebt list.  Here is what Bruce writes about return statement:

7.3 RETURNING VALUES FROM FUNCTIONS
Now it’s time to talk about returning values from functions. We’ve been doing this all along, but there’s something we need to highlight. Because PowerShell is a shell, it doesn’t return results—it writes output or emits objects. As you’ve seen, the result of any expression or pipeline is to emit the result object to the caller. At the command line, if you type three expressions separated by semicolons, the results of all three statements are output:
[...]
In the traditional approach, you have to initialize a result variable, $result, to hold the array being produced, add each element to the array, and then emit the array:
PS (16) > function tradnum

{
$result = @()
$i=1
while ($i -le 10)
{
$result += $i
$i++
}
$result
}

This code is significantly more complex: you have to manage two variables in the function now instead of one. If you were writing in a language that didn’t automatically extend the size of the array, it would be even more complicated, as you’d have to add code to resize the array manually. And even though PowerShell will automatically resize the array, it’s not efficient compared to capturing the streamed output. The point is to make you think about how you can use the facilities that PowerShell offers to improve
your code. If you find yourself writing code that explicitly constructs arrays, consider looking at it to see if it can be rewritten to take advantage of streaming instead.

I think the motivation behind this feature is nice, but there are much cleaner, easier-to-read ways to achieve the same goal: Implicit promotion from a single object to a collection of objects.

In Bash, return exits a function, period.

Huh?  Bash accumulates output just the same:
hillr@Keith-Dell8500:~$ function foo() {
> echo "Hello"
> ls ~
> date
> return
> echo "World"
> }
hillr@Keith-Dell8500:~$ foo
Hello
bar.ps1  date.txt   test.ps1
baz.ps1  dotnet    powershell-preview_6.2.0-rc.1-1.ubuntu.16.04_amd64.deb
Tue Mar 26 16:06:18 DST 2019

Just like PowerShell, Bash still outputs everything from each command up until the return statement.

Yes.  return has only one purpose.  In PowerShell, it is mixed with output.  Mixing return values and output streams is a bad idea.  It can also lead to memory leak-like performance woes.

Well, PowerShell is based on .NET which is garbage collected, so it shouldn't suffer memory "leaks". That doesn't mean you can't have a memory hoard though. So you do have to be a bit careful when handling large output/collections that it assigned to a variable or put in a hashtable of some sort.
I think PowerShell's return statement should only have a single purpose and that is to return early - nothing else.  But when someone does do return 42 it has no bearing on $?. It is just another item output (yielded) to the output stream.
Like I mentioned before $? is managed by PowerShell and has nothing to do with what a function outputs/returns.  $? is set based on generated errors (or the lack thereof).   This means that when you execute $res = foo - $res will contain every object output by the function foo.  If you want to know if the function "failed" you can inspect $?~ on every single command you execute OR you can wrap a bunch of commands in a try/catch` block.  I find the former much less typing.

hear people say this, including @BrucePay (see emphasis mine, below, quoting him) , but the bottom line is:
In Korn Shell, return exits a function, period.
In Bash, return exits a function, period.

In PowerShell, return exits a function, too:
PS C:\> function test { "hello"; return "!"; "world"}
PS C:\> test
hello
!

Mixing return values and output streams is a bad idea. It can also lead to memory leak-like performance woes

There is no mixing because there is no difference between the output stream and the return value in PowerShell. You're talking as if the function writes the strings to stdout and separately returns an exclamation mark to the caller, but it doesn't. Pointing to write-output seems like the same mistake; all of these: write-output 'x', 'x', return 'x' send something down the same output path, to the pipeline. There is no separate return value.

What you really want is co-routines or "yield return", or generators, generator-builders and scanners (as in Icon). T

That would mean that if you wrote a command on the command line, then put it in a script or function, it would behave differently:
PS C:\> robocopy /whatever
PS C:\> "robocopy /whatever" | set-content test.ps1; .\test.ps1
PS C:\> function test { robocopy /whatever }

I like seeing the same output in all three cases, not have the output swallowed in two cases because I didn't yield return for no reason. The way PowerShell does it is consistent and convenient for a shell and writing shell / batch scripts - taking something you wrote on the command line and putting it somewhere you can call it over and over. Doing that shouldn't completely change how the code behaves.

The reason being is that input consumption is lazy and failure suspends computation while allowing the portion of computation generated so far to be disposed of.

The PowerShell pipeline is controlled by the runtime, if I understand what you're saying, it's already able to to do that:
PS D:\> 1..1mb |foreach { write-verbose -Verbose "incoming number: $_"; $_ } |select -first 3
VERBOSE: incoming number: 1
1
VERBOSE: incoming number: 2
2
VERBOSE: incoming number: 3
3

the select will terminate the pipeline as soon as it has three things The rest of the million numbers weren't fed into foreach. Information moving down the pipeline is a "push" model, but it's controlled by the PowerShell engine.
Although, being a shell, it's not clear what it would mean for "input failure to suspend computation" if the input is coming from a native command or something outside a PS cmdlet.

Provide "compiled modules" similar to how Py files compile to pyc files for performance improvement.

I think the intended solution for more performance is to write modules in C#. PowerShell code does get JIT compiled, in some situations, but PS team members have said before they have no plan to expose this to end users for customisation, e.g. IIRC Dongbo Wang's PS Conf Asia talk on the PS Engine internals Nov 2018. (I guess that could change).

Fix null redirection so that the three different ways to redirect output streams to the null device are equivalent in performance.

Desirable, but it seems unlikely; $null = 4 is a simple variable bind, 4 | out-null needs the overhead of starting up a pipeline and doing command resolution - what if someone had intentionally made out-null  a proxy-wrapper which added logging code? Is that technical debt, that asking for a pipeline and cmdlet to run is slower than an expression?

Fix dynamic scoping:

If you mean "don't use dynamic scoping", it was a deliberate choice, e.g. Bruce Payette here saying "dynamic scoping, this is almost never used before. Like 30 years ago LISP had dynamic scoping, but it's very very rarely used now. The reason that we're using it is: that's what shells use. Shells use the equivalent of dynamic scoping, even Bash, and the Unix shells use the equivalent of dynamic scoping, where the variables from the caller's context - in their case the variables from the caller's context are copied into the child context. [..] With one modification, normally in dynamic scoping you look up the call chain and set the variable where it exists, we don't do that, we set the variable in the current scope all the time, and again that emulates the behaviour of shells".
That might be annoying, but is that "technical debt" for a shell, and would be "zeroTechnicalDebt" if it was changed?

Well, PowerShell is based on .NET which is garbage collected, so it shouldn't suffer memory "leaks". That doesn't mean you can't have a memory hoard though. So you do have to be a bit careful when handling large output/collections that is assigned to a variable or put in a hashtable of some sort.

I had a system administrator, who is not an engineer, write some logic to try to tabulate metadata on all files on a 8 TB file share.  That did not end well: It ate up a lot of memory, and also pegged the system at 100% cpu... we could not even log in to the box after the script started, and the only solution in production to save the server was to hard reboot it.
In my experience, PowerShell makes it easy to write such rubbish.  You can do with, and critique, my feedback however you wish.  It will not change the fact PowerShell makes it easy to write scripts that can effectively crash production machines.

@jzabroski can you share any details of the script?
Powershell people try to encourage pipeline streaming (get-childitem | foreach-object {}) instead of pre-loading a dataset ($files = get-childitem; $files | foreach-object) deliberately to reduce memory use. Did it do that up-front loading?
Was there a use of Group-Object to collect up the similar files? There have been improvements in Group-Object performance recently which would reduce CPU use, if not memory use.
PowerShell is single-core by default, was there jobs/runspaces code in there, was it a single core server? PS 6.1 has Start-ThreadJob which allows multiple jobs with way less overhead and throttling to help control CPU use.

In my experience, PowerShell makes it easy to write such rubbish

All the tutorials and books which tell you to write $files = @();  $files += $f must have cost the world a small fortune in cpu cycles and memory. That's a pattern which is slow, expensive of processor and memory, and distressingly common. I'm curious if that pattern was in the script at all? (And if there's any way we could block it without breaking backwards compatibility, or make += invalid on arrays in future breaking-changes?).
But, there is a tradeoff here. Get-ChildItem -Recurse is 22 characters and eats 800+MB of RAM on just my C: drive, the C# to do that without using tons of memory is 50+ lines and doesn't get file metadata at all, and will be more like 80MB. That's not PS leaking memory, that's PS using it to gain user convenience.
Is there any language where you don't have to care about the details of how it works, can write useful code, can't write bad code, and don't have to be a skilled programmer? (And which is also a shell?)
Would any of your earlier proposed changes have made it so the script worked?
You can write a Bash script to list files, spawn a process for each one, until your server falls over and you can't even SSH into it. You can write a Python script which os.walk()s the file tree and calls os.stat() for each file and uses less memory and finishes faster - but takes 10 lines instead of 1 and you still have to care about OS and care about code details (and it still isn't a shell, and won't work with PS Providers).
I would like PS to have more "pits of success" and fewer trip hazards. Fast filename listing being one of them that I see a lot of use for. Radically changing it to be a completely different language, and hobbling the areas it does well, won't do that.
You want Python, Python exists, it's a beautiful language, it's not hobbled by trying to fit in two different worlds and keep scoping and function return semantics of a thirty year old shell from a different OS (why, Microsoft), or by Microsoft's commitment to backwards compatibility (and obsession with .Net), so it gets to dodge all those questions, rather than face them.

I would like PS to have more "pits of success" and fewer trip hazards.

If I could add twenty thumbs up for that alone, I would. This is exactly the pattern and approach PowerShell needs to take.

Here is another example of why PowerShell is my 1,535,343 most favorite language:
For-EachObject is a PowerShell function for taking PowerShell collections and converting it into unreadable stack traces.
Today, I took a script written my Amazon to list EC2 Windows Disks: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-volumes.html#windows-list-disks
Guess what?  I didn't have Initialize-AWSDefaults set-up on this PC, and since the script author used ForEach-Object, my stack trace looked like this garbage:
PS C:\Windows\system32> D:\Installs\PowerShell\List-EC2Disks.ps1
Could not access the AWS API, therefore, VolumeId is not available.
Verify that you provided your access keys.
ForEach-Object : You cannot call a method on a null-valued expression.
  The stack traces are always terrible.  Re-writing this is painful.  Thankfully, it's just a script I copy-paste into a random file, save, and run.  If it's a problem in a large module, I have to get the source code for the module, re-write the script, hope to god in refactoring it I didn't break anything across the module by converting the ForEach-Object expression AND hope I can figure out where the REAL error is just so I can do my job.  And now I have some custom code I forked from some major repository, just to figure out why I'm getting some error because PowerShell's Write-Error IS AWFUL compared to C# simple idiom of throw new Exception("message", ex).
Re-writing this to use a for ($var in $list), accumulating the results in a variable $results, I get the following error:
PS C:\Windows\system32> D:\Installs\PowerShell\List-EC2Disks.ps1
Could not access the AWS API, therefore, VolumeId is not available.
Verify that you provided your access keys.
You cannot call a method on a null-valued expression.
At D:\Installs\PowerShell\List-EC2Disks.ps1:58 char:26
+ ... lDevice = If ($VirtualDeviceMap.ContainsKey($BlockDeviceName)) { $Vir ...
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

Oh, and by the way, every time I have to do this I can't remember PowerShell's stupid rules for adding items to lists, so I have to Google https://www.google.com/search?q=powershell+append+to+list and read a blog post about someone explaining how non-intuitive PowerShell's list operations are.

@jzabroski can you share any details of the script?

Sadly (and happily), I don't remember it.  It was a fileshare, so it was almost certainly one or two cores at most.  If it was two cores, the remaining CPU was likely taken by Windows Defender.

There is no mixing because there is no difference between the output stream and the return value in PowerShell.

I have yet to see people use this correctly on the first try.  Again, this is not what bash does or any other shell.  While it was an interesting experiment to unify the two concepts, it was a complete and utter disaster from a readability standpoint.  It doesn't help that Write-Output was broken in PowerShell v6 for 16 months.

@jzabroski from your output of For-EachObject it looks like you are not using Powershell Core (that is what this repository is dedicated to) could you please try Powershell core and see if you can reproduce it. Make sure to use the latest version. Be mindful, that windows specific functionality (such as Get-Disk) is not part of Powershell Core, you will need to take this into account, while doing your tests.

I have yet to see people use this correctly on the first try. Again, this is not what bash does or any other shell.

$ test () { ls /tmp; ls /etc/pm; return 5; ls /v*; } ; x=$(test)
$ echo "$x"
tmux-1000
sleep.d
$ echo $?
0

That is both output of two separate commands accumulating in a Bash function, and Bash return not functioning as return functions in C#. What, specifically, "isn't what Bash does"?

You are not capturing the return value correctly for the bash example.  the return is lost because the $? is always the last command. in this case 'echo'
$ test () { ls /tmp; ls /etc/pm; return 5; ls /v*; } ; x=$(test)
$ echo $?
5
$ echo $x
tmux-1000
sleep.d

POWERSHELL does this differently
> function test() { ls; return 5 ; ls } ; $x=test
> echo $?
True
> echo $x
    Directory: c:\foo\bar

Mode                LastWriteTime         Length Name
----                -------------         ------ ----

More PowerShell oddities:
Chocolatey adds a RefreshEnv.cmd which is a GODSEND.  Why doesn't this just ship with PowerShell?

Create a standard object model for PowerShell providers: https://github.com/PowerShell/SHiPS/issues/66#issuecomment-368924485
In the link on SHiPS issue 66, I outline possible candidate cmdlets.  It's not clear to me why we can't implement something like Haskell typeclass behavior for these core cmdlets.

This APIs is already in PowerShell.

@iSazonov Can you please edit and quote what you are replying to, and add some context, such as a hyperlink to documentation of said APIs? TYVM

@jzabroski Look files in src\System.Management.Automation\namespaces\ folder.

POWERSHELL does this differently

It's bash that's doing it differently - return can only set the (integer) process exit code (that's not what "return" means in other programming languages, that's an exit).
PowerShell can do that too, with exit 5
It's just that we don't use exit codes very often in PowerShell (pretty much only for scheduled tasks and interop with other OSes), because it isn't a process-based shell, and functions should not exit.
At the end of the day, it's the same reason why detecting the stdout handle type isn't useful in PowerShell (and why "redirecting" to out-null isn't the same as casting to [void] or assigning to $null)

I recommend people file new issues if they actually have feedback they want acted on -- since the team has clearly and unequivocally ruled out a not-backward-compatible version of PowerShell, I don't know why this thread just keeps going...

since the team has clearly and unequivocally ruled out a not-backward-compatible version of

That is news to me.  How is this clear?  Please provide links to posts or other documentation.
It's a bit frustrating for some of us to hear "we'll never break compatibility"  while we wrestle with some breakage every day.  The point of this thread is so that the free market of ideas can solve some of these problems when upstream won't.
Someone might find it advantageous enough to fork powershell and create a version with minimal technical debt.  That group will benefit from the ideas presented in this thread.  (This is how the world works now.  May the best powershell win.)
I'll reiterate that the team has already produced a 'not-backward compat' version of powershell by renaming the command from powershell to pwsh.  Power(SHELL) is a shell.  the job of a shell is to be the glue for humans that ties digital systems together.  It's not a compiled binary with minimal external dependencies.  Even traditional programming languages plan for and make breaking changes.

POWERSHELL does this differently

It's bash that's doing it differently - return can only set the (integer) process exit code (that's not

I'm curious about other shells.  What do they do?  korn, csh, etc.

My team has a variety of scripts that only run in PowerShell 5 even though we use PowerShell 6 as much as possible.  In my experience, the premise that PowerShell is completely backward-compatible is definitely false.  There are at least some extreme cases (ex: ErrorActionPreference not behaving intuitively) that should definitely be addressed as a breaking change.

@chriskuech is there an issue detailing your issue with ErrorActionPreference?

@SteveL-MSFT I believe the Mosaic that @KirkMunro  linked to directly below @chriskuech comments is the issue you are looking for.  And yes, I squeeze the word Mosaic into a tech conversation.
That said, @iSazonov closed @chriskuech original issue on October 1, 2018: See https://github.com/PowerShell/PowerShell/issues/7774
It seems this stuff keeps coming up, in different forms, and the Committee keeps closing issues around it.

@jzabroski found my main issue targeting the root cause.
I also filed an issue in the past around one of the symptoms: Invoke-WebRequest throwing a terminating error.  I have personally witnessed multiple people completely dumbfounded around the whole try/catch boilerplate for handling failed HTTP requests, which occurs because the internal .NET methods throw terminating errors.  In each of the three different cases, the engineer responded with an expletive when I explained the underlying behavior and why the issue would allegedly never be fixed.
To summarize, terminating errors terminate the script because PowerShell creators believe the script cannot logically proceed beyond the error, but I don't think that is literally ever anyone but the scripter's decision to make on a case-by-case basis.  Only the scripter can decide if they want the script to Stop, SilentlyContinue, Continue, etc.

(Tangential to the issue above)
If PowerShell implements an opt-in "ZeroTechDebt" mode, I definitely think that $ErrorActionPreference = "Stop" should be set by default.  Obviously, this setting does not make sense in a REPL and should therefore not be set by default for all scenarios, but literally all of my scripts are prefixed with $ErrorActionPreference = "Stop" to enable "defensive programming" and behave like a "normal" programming language.

@chriskuech If you haven't already, please give this collection of RFCs a look: https://github.com/PowerShell/PowerShell-RFC/pull/187. They speak directly to what you're talking about here without needing a new zero tech debt version of PowerShell.
You can also find the four RFCs in separate issues on the Issues page in that repo if that makes them easier to read/digest. Just look for open issues posted by me and you'll find them

@SteveL-MSFT  Here is a similar issue that ANNOYS THE HECK OUT OF ME.  It's not $ErrorActionPreference but $ConfirmPreference:
Below is an ugly script I wrote for setting SQL Server disk volumes to 64kb.
Import-Module Storage;

function Format-Drives
{
    # See https://stackoverflow.com/a/42621174/1040437 (Formatting a disk using PowerShell without prompting for confirmation)
    $currentconfirm = $ConfirmPreference
    $ConfirmPreference = 'none'

    Get-Disk | Where isOffline | Set-Disk -isOffline $false
    # The next line of this script is (almost) copy-pasted verbatim from: https://blogs.technet.microsoft.com/heyscriptingguy/2013/05/29/use-powershell-to-initialize-raw-disks-and-to-partition-and-format-volumes/
    Get-Disk | Where partitionstyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -Confirm:$false -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize -IsActive | Format-Volume -FileSystem NTFS -AllocationUnitSize 64kb -Confirm:$false

    # See https://stackoverflow.com/a/42621174/1040437 (Formatting a disk using PowerShell without prompting for confirmation)
    $ConfirmPreference = $currentconfirm
}

Format-Drives

Couple of side points:

The documentation for Format-Volume is wanting for more.  Only two examples?  And the official documentation is not in sync with the website: https://github.com/MicrosoftDocs/windows-powershell-docs/issues/1170
Why do I need to go to StackOverflow to learn how to avoid a GUI for a scripting language?
The fact this is so error prone/stupidly hard to get write "without thinking" just underlines related issues like https://github.com/PowerShell/PowerShell-RFC/issues/198 - it's another example of how Bruce Payette's promise in "PowerShell In Action" that you just type what you think is write and it works... is completely and utterly false.

#Requires -Version has no way to specify a max version
See: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-6
This is annoying when you are writing Advanced Functions that load .NET Framework libraries where the API is completely different between .NET Framework and .NET Core, such as how AccessControl API works.

@jzabroski You can specify the edition, however, to separate that:
#requires -PSEdition Desktop
# versus
#requires -PSEdition Core

Just a quick note that @rjmholt has officially started a discussion about how to implement and manage breaking changes: #13129.
Plus, #10967 is another behavior worth revisiting once breaking changes are allowed.

The fact that , is stronger than + is logical, as PowerShell is more about lists than about numbers.  IMHO.

@rjmholt has officially started a discussion

I should say it's no more official than any other discussion

I would love to have strict checking on imports and function signatures editing-time.
Are you considering to introduce new importing semantics such as EcmaScript modules provide?
No more global namespace polution. Slow import mechanics.

Can pwsh just follow standard sematic versioning rules?  Does pwsh publish it's versioning rules anywhere?
I don't see why breaking backwards compatibility is such an issue--that's precisely what bumping the major version is supposed to communicate to users.

Can pwsh just follow standard sematic versioning rules?

It does now, though iirc they have stated they're not incrementing the major version after 7.

I don't see why breaking backwards compatibility is such an issue--that's precisely what bumping the major version is supposed to communicate to users.

Communication is one part for sure.  Adoption is also a big consideration though.

I don't see why breaking backwards compatibility is such an issue--that's precisely what bumping the major version is supposed to communicate to users.

You can find more information in .Net Runtime repository - they think about this some years :-) It is not easy to move huge ecosystem to new standard.

Can pwsh just follow standard sematic versioning rules?

It does now, though iirc they have stated they're not incrementing the major version after 7.

Since when is PowerShell following semantic versioning? As far as I know, they explicitly refused to do so. It doesn't even support semver in module versions, never mind in PowerShell itself. The current release plan revs the "minor" version annually, and every other release will be supported for an extra "long" term (i.e. 25 months instead of 13). All releases between those will rev the "patch" and will probably only have security patches and bug fixes.
There's simply no plan for breaking changes even though they are introduced in every release. This isn't semantic versioning. This is old-school Windows 95 style versioning: make something up and just do whatever you feel like, as long as the numbers go up, we can explain what we mean.

Since when is PowerShell following semantic versioning? As far as I know, they explicitly refused to do so.

I think I saw it stated in a blog post that they intended to.  No longer 100% sure.

It doesn't even support semver in module versions, never mind in PowerShell itself.

You can follow the rules of semantic versioning without also providing an API around semantic versioning.

There's simply no plan for breaking changes even though they are introduced in every release.

Would you increment a whole major version for those though? They seem pretty unlikely to affect a whole ton of folks, unlike some of the changes discussed ITT.
Either way, even if you make the assumption that a major version increase is enough warning for the existing user base, I would guess it doesn't address the big reasons they are adverse to them. Note that I'm not saying the changes here should or shouldn't be implemented, only that semantic versioning probably isn't a super big part of answering that.

I would guess it doesn't address the big reasons they are adverse to them.

Adverse' or 'Averse'?

I am utterly supportive of as much improvement as is possible, because I am a user of Linux, and am desiring conversion of most of my scripts to PowerShell, so if it is able to improve quickly rather than slowly, that shall be incredibly beneficial for me. The inconsistency because of backward compatibility is the only reason that I am hesitant to do so.

Isn't Set-StrictMode already a "breaking" change for most scripts? Yet many people put it at the top of every file to avoid things like access to non-existent variables, while only applying to local scope without affecting other code. So just whack it under 4.0 and call it a day.
It would be very valuable to provide tooling checking code for potential breaking changes. Especially for changes related to operator precedence, such tool should emit a warning for all cases where logic changes. Set-StrictMode -Compatibility OperatorPrecedence sounds good to me, as it would also allow writing code compatible with both options.

Apologies for this, but commenting to prevent never-shuts-up bot from spamming this thread any more than it's already doing. I suppose you can say I'm fighting fire with fire, the nerdiest manner possible.

Another undesirable behavior worth revisiting in the context of allowing breaking changes:

[string]-typed parameters unexpectedly and unhelpfully accept arrays in certain scenarios - see https://github.com/PowerShell/PowerShell/issues/21367#issuecomment-2016947667


red/green line markers (err/warn) in wrong position with non-full-height source window

Dragging another window down to the bottom (so it's full width, and makes the others partial-height) breaks the position of the error/warning line markers.
example

Hi! Sorrry this took so long to get addressed. I can't seem to reproduce now the error you describe. Is it still bad on your side?


Persisting data

Hi, I was spending some time trying to decide which vue i18n project to choose, when I've found this one. I think it's by far the easiest approach.
I was wondering if there is a way to make data persistent in localstorage. I've been using vuex-localstorage for my modules and works pretty well. Some of the info in my app needs to be persistent. Also current language.
Is there a way to solve that?
Thank you for your fantastic job!

Hi there,
Thank you for your feedback. The vuex-i18n plugin basically does intentionally not specify where the localization information should come from. You may specify it directly in the code (as in the example in the readme), load it via an ajax-request or – as you intend – fetch it from local storage.
Basically you just need to load the data from local storage (use json.stringify to put your whole localization object into the storage and json.parse to retrieve the whole object from local storage).
Afterwards you can use Vue.i18n.add(locale, translations) or $i18n.add(locale, translations) inside a component to add the locale information. The $i18n.set(locale) method will allow you to set the current locale (which could also be saved in the local storage and be retrieved again from there).
Please let me know, if you need any more help to get it working.

Hi again! And thank you for your answer!
The point is, I have GET http queries to get the info from a json file. To get info is not the problem. I have vuex-i18n working perfectly, and it was pretty easy. The point is that I want to save this i18n state into local storage. For other states i'm using vuex-localstorage, which works like a charm.
That's the point. 1 GET petition, then save to local storage, and avoid to lose the info when the user reloads...

Ah ok.. I understand your idea.
Please keep in mind, that doing this could cause problems, if you decide to update your locale information at a point in the future ;-) - also known as the caching problem.
So I would suggest this workflow:

Prevent the user interface from rendering until all locale data is available - i.e. using v-if or something similar
Check in the local storage if the locale information is provided - i.e localStorage.getItem('locale')
Check if the translations for this locale are available - i.e. localStorage.getItem('translations-en')
Download the translations from the server if locale or translation is not available
Store the translation and locale in the local storage - i.e. localStorage.setItem('locale')
Hand the locale to the vuex-i18n plugin Vue.i18n.add(locale, translations)
Set the current locale with Vue.i18n.set(locale)
Render the user interface

Yeah, i was thinking about why there is no localstorage in vuex. Maybe this "caching problem" is the answer for my question...
Thank you for this workflow, I think I'm going to re-focus the way i'm working with localstorage.
Cheers!

For anyone looking to persist the locale easily using vuex-persistedstate, it's actually fairly trivial to do.
First, you'll want to either whitelist paths for persistence or use the reducer function to remove paths that shouldn't be persisted (the i18n.tranlsations object should not be persisted).  You'll want to make sure the i18n.locale object is going to be persisted however.  For my particular instance, that looked like this:
const store = new Vuex.Store({
  modules: {
    settings,
    i18n: VuexI18n.store
  },
  plugins: [createPersistedState({ paths: ['settings', 'i18n.locale'] })],
  strict: true
})

Vue.use(VuexI18n.plugin, store)

Then, wherever you initialize your i18n plugin, simply check for the existence of a locale prior to calling set locale so that you don't overwrite the persisted data.
export default function () {
  Vue.i18n.add('en', en)
  Vue.i18n.add('fr', fr)

  if (!Vue.i18n.locale()) {
    Vue.i18n.set('en')
  }
}

Hi @bayssmekanique,
Thank you for posting these instructions. Very helpful


Page Search - performing multiple searches will sometimes incorrectly link the second set of results

This is in version 8.1.0 and it only happens once in a while... probably 1 in 10 times.
Steps to recreate:

Go to Page Search in the dashboard.
Click on any page and visit.
Back in the browser to return to Page Search.
Enter a search term and press enter.
Click a result and visit.

Most of the time this second click+visit will take you to the correct page.  Once in a while it takes you to the page you arrived at in step 2.  Anecdote, but it seems like the faster you click a result after step 4, the more likely it is to take you to the wrong page.  I inspected the elements during this process and I'm pretty sure data-page-id is always correct in the HTML, so it seems more likely related to the jQuery.

Yeah, this is a DOM issue. Basically if you find yourself hovering over a
search result but that search result isn't highlighted, there's a chance
it's hovering over one of the old page object search result table rows. Or
something like that.
On Tue, Mar 21, 2017 at 1:14 PM, Scott Zsori<EMAIL_ADDRESS>wrote:

This is in version 8.1.0 and it only happens once in a while... probably 1
in 10 times.
Steps to recreate:

Go to Page Search in the dashboard.
Click on any page and visit.
Back in the browser to return to Page Search.
Enter a search term and press enter.
Click a result and visit.

Most of the time this second click+visit will take you to the correct
page. Once in a while it takes you to the page you arrived at in step 2.
Anecdote, but it seems like the faster you click a result after step 4, the
more likely it is to take you to the wrong page. I inspected the elements
during this process and I'm pretty sure data-page-id is always correct in
the HTML, so it seems more likely related to the jQuery.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/concrete5/concrete5/issues/5236, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAgNwSpMhgwTOiH_UJWb9GWGme1yxaukks5roC-JgaJpZM4MkV-0
.

This has been fixed with the new non-JS version of the search tools we have in the v9 Dashboard.


[json] faster, lighter JSON enconding/decoding

What does this PR do?
It introduces jsoniter, a faster, leaner json encoder/decoder alternative (https://github.com/json-iterator/go). After exploring a few options decided to go with this alternative (as opposed to easyjson or ffjson) due to its simple drop-in replacement nature and great numbers compared to some of the other projects. It is still actively maintained. Most of our heavy-lifting is in encoding so the benefits are not going to be as massive as they'd be with a more heavily decoding application, that said the number of allocations should be reduced helping our footprint and garbage collection.
Motivation
Just trying to improve agent performance in general, starting with low hanging fruit like JSON encoding.
Additional Notes
Anything else we should know when reviewing?

Some actual relevant gains seen in our prod environment, so this is probably worth it. Rebasing and removing the hold tag. If possible, I'd like to merge this soon, so we have a nice long run before the 6.5.0 RCs are built.

We can give them the heads-up, that's fine. But trust me, they'll know when they have to rebase every single PR in progress 😊

Previously approved, removed commit 0bae8ce, will merge in a different PR. Merging. This will cause a lot of PRs some pain with the need to rebase. I will make sure I notify people via slack.


[CSM-275] Dummy endpoint for transaction fees

Fix fee api: passphrase isn't required anymore

@pva701 doesn't build in prod mode. Builds in dev mode. Note that 0.5-rc builds in both modes

doesn't build in prod mode. Builds in dev mode. Note that 0.5-rc builds in both modes
@georgeee said this is because we don't have staging run with master yet


⚠ Bofrost.at has degraded performance

In 0319ce9, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2523 ms

Resolved: Bofrost.at performance has improved in 6983819.


fix cdata bug

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 89.02%. Comparing base (8d5eec6) to head (3d9e14a).
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #36      +/-   ##
==========================================
+ Coverage   87.50%   89.02%   +1.52%
==========================================
  Files           7        7
  Lines        1064     1066       +2
==========================================
+ Hits          931      949      +18
+ Misses        133      117      -16

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[SourceKit] Fix placeholder expansion not working inside #if

Update the PlaceholderFinder ASTWalker to walk into the clauses of IfConfigDecls. It wasn't previously, resulting in any placeholders there not being expanded.
Also update CallExprFinder (used to determine if expansions should use trailing closure syntax) to walk into inactive if-config clauses. Previously it only walked into active regions, so expansions never used trailing closure syntax in inactive regions.
Resolves rdar://problem/51995648

@swift-ci please test


Rework - Sensors build test

This is first step in getting improved coverage on the sensors.  Want to get this merged, than will look at getting ALL sensor drivers actually building as part of this test.

This is first step in getting improved coverage on the sensors. Want to get this merged, than will look at getting ALL sensor drivers actually building as part of this test.

I'll take a closer look tomorrow (Monday). It looks somehow interesting...

I already approved, but what happens if we merge it like this?

I already approved, but what happens if we merge it like this?

I don't understand your question. Are you ok with this getting merged?

I already approved, but what happens if we merge it like this?

I don't understand your question. Are you ok with this getting merged?

I am, but I would like @galak to comment more on this statement:
This is first step in getting improved coverage on the sensors. Want to get this merged, than will look at getting ALL sensor drivers actually building as part of this test.
Does it mean that after merging the CI will fail until job will be completed? I think it is just my misunderstanding, that's why I still approve. But maybe some more clarification is required here.

Does it mean that after merging the CI will fail until job will be completed? I think it is just my misunderstanding, that's why I still approve. But maybe some more clarification is required here.

CI should still pass with this change.  My comment was that I wanted this merged before making a number of changes on top of this as I expect we'll starting see more failures with sensors not building in different configs.
The follow PR(s) will do:

Add all current sensors to build all - will start with sensors.build
Add configs for the 3 common configs for trigger mode - None, global thread, and own thread.


Add Machine Learning at VS2019 solution does nothing

System Information (please complete the following information):

Model Builder or CLI Version:
Visual Studio Version 2019 Enterprise: 16.8.2

Describe the bug

On which page of the tutorial did you run into an issue (URL):
Clear description of the problem:

To Reproduce
Steps to reproduce the behavior:

Go to Solution Explorer
Right click on console application
Scroll down to Add > Machine Learning
Nothing happens

Expected behavior
ML.NET Builder screen shows up

@raphael-dossantos  Did you enable the Preview feature from Tools | Options page? If not, there should be a very small notice in Visual Studio asking to do it, but it is easy to miss.

Console Application probably needs to use .NET Core or .NET 5.0 framework (according to issue https://github.com/dotnet/machinelearning-modelbuilder/issues/1511 )

@raphael-dossantos In addition to Antti's suggestions, are you trying to add to VB project? We only support C#.

Thanks for repplies, I really appreciate. I'm using C# not VB and I did enabled Preview Tools. Let me try .NET 5, because I was using 3.1.
I'll try and let you know.
Thanks for all kind repplies.

I once had disabled the extension by accident. Probably from the notice telling it caused X seconds of unresponsiveness. I think it did the same as you describe. That could be one cause also.

Any update here @raphael-dossantos?

I have same issue with Visual Studio 2022, just now trying. Same project works on VS 2019. I'll still try on another machine.
After right-clicking on project, Add > Machine Learning it asks me to select file type without Machine Learning.

@torronen Thanks for your help diagnosing this issue. I've added this problem to our troubleshooting document here.  If you want to take a look you can let me know if you have suggestions/improvements.
We're working to get VS 2022 available now. The VS Marketplace blocks installing into VS 2022. It seems like the version available in 2022 is the older build that ships with VS? @LittleLittleCloud FYI, looks like the menu option is available in 2022.

Oh, I see. So the VS 2022 is unrelated to problem reported by @raphael-dossantos
Not sure if you mean this, but my installation got a pretty recent version (<IP_ADDRESS>2901 dated 17/16/2021) of ML.NET Model Builder installed in VS 2022 Enterprise just installed a few days ago. Trying to uninstall it takes to VS installer so it is probably the one that ships with the installer

I have the same problem with the latest VS2022 v 2.1 on a fresh new windows server.

@torronen @raphael-dossantos
While we are looking into this issue, (it looks quite similiar with #1511). Since ModelBuilder wizard will be used for file with extension as .mbconfig so if "Add machine learning" doesn't work, a work-around is creating a file with .mbconfig as extension directly.
@acrigney
which model builder version do you have on VS2022

My model builder version on VS2022 is
<IP_ADDRESS>1904
and its set to auto update.
And the project type is .net 6
And what does he mean when he says "create a file with the .mbconfig
extension? Where and please explain more?
On Tue, Aug 3, 2021 at 8:57 AM Xiaoyun Zhang @.***>
wrote:

@torronen https://github.com/torronen @raphael-dossantos
https://github.com/raphael-dossantos
While we are looking into this issue, (it looks quite similiar with #1511
https://github.com/dotnet/machinelearning-modelbuilder/issues/1511).
Since ModelBuilder wizard will be used for file with extension as
.mbconfig so if "Add machine learning" doesn't work, a work-around is
creating a file with .mbconfig as extension directly.
@acrigney https://github.com/acrigney
which model builder version do you have on VS2022
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/machinelearning-modelbuilder/issues/1542#issuecomment-891386230,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABCSC7N5F46ZKL6C3E73TZLT24PETANCNFSM47QFZN4Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

I have the same issue on:

ML.Net Model Builder (Preview): <IP_ADDRESS>0201 (Main Branch)
Microsoft Visual Studio Enterprise 2022 Preview: 17.0.0 Preview 2.1
.Net: 5.0.302

Found that can add model builder by the following steps, @LittleLittleCloud please take a look, if this is the expected behavior?

Right click to select Add> Machine Learning;
Navigate to "Visual C# Items" on the "Add New Item - xxx" dialog;
Select Machine Learning Model (ML.NET);
Click "Add" button.

I tried the VS2022 preview3 and it seems this issue no longer exists. Maybe it's a bug from VS add to item window and has been fixed already/ In that case,  I suggest we don't fix this bug as it's not a blocking issue and will be fixed once the next VS2022 preview comes out.


Push Purchase Order Receipt from OMS to NetSuite

We need to prepare a CSV file that will contain the following information for received purchase orders.

ORDER_ID
LINE_ID
QUANTITY

Data model entities:
a) OrderHeader
b) Shipment
c) ShipmentReceipt
EntityCondition:
a) orderTypeId = PURCHASE_ORDER
b) shipmentTypeId = PURCHASE_SHIPMENT
c) shipment statusId = PURCH_SHIP_RECEIVED
If any order doesn't receive at OMS, please add zero(0) in the quantity column with order_id and line_id.
Note: We need to make sure that PurchaseOrderReceipt CSV file should not contain any record which has been already pushed to NetSuite. It will be similar to the implementation, we did for sales order fulfillment for Shopify.

Purchase_Order_Receipt.csv

@rehan3586
Some comments and questions from my end, can you let me know your inputs on these.

The field mapping for the CSV format with HC data will be as follows, please confirm.

ORDER_ID - OrderHeader.externalId
LINE_ID - OrderItem.externalId
QUANTITY - sum(ShipmentReceipt.quantityAccepted)

For the quantity field in the CSV, if for a PO item with 10 quantity, 8 qty is accepted and 2 rejected, do we send 8 as the quantity in the CSV, or we still send 10?

For the below statement, do we always send all PO order items irrespective of whether it is received or not?

If any order doesn't receive at OMS, please add zero(0) in the quantity column with order_id and line_id.

How will below scenarios work if above is true?

A PO with 3 Order Items, 2 items received today, do we send all 3 items in the CSV with third item quantity as 0?
If the third item is received the next day, do we need to send all 3 items again in the CSV, wouldn't this create incorrect data at NetSuite end?

For below, discussed with @dixitdeepak , we will not maintain the history records, instead use the saved last run time concept and prepare CSV for the update in POs after it was last sent to NetSuite.
We will check the use of ShipmentReceipt.datetimeReceived field for this.

Note: We need to make sure that PurchaseOrderReceipt CSV file should not contain any record which has been already pushed to NetSuite. It will be similar to the implementation, we did for sales order fulfillment for Shopify.

Hello @gurveenbagga,
Here are the details:

Field Mapping for the CSV file will be

ORDER_ID -> OrderHeader.externalId
PRODUCT_ID -> Product.internalName
QUANTITY -> sum(ShipmentReceipt.quantityAccepted)

Now we don't need to send LINE_ID, we will identify the line_id in NS suitescript on the basis of product_id.

We have to send only accepted qty i.e. 8.

Please refer to the below example for the 3rd and 4th points.
i. If HC creates a PO with 4 items, we receive 2 items today then we will send all 4 items with the first 2 received items and the last two items with zero qty as these are not received or not available in the ShipmentReceipt entity.
ii. Now, we receive only the 3rd item by the next day, we will send the 3rd item with the received qty and the 4th item with zero qty. Here we will not send the first two items as we have already sent them to NS.
iii. If we receive the 4th Item, will send only 4th item with the received qty.

Looks good to me and will confirm with Aditya Patel. If there are any changes in the solution, will get back to you. For now, we can start the implementation with this solution.

@rehan3586
Some comments and questions from my end, can you let me know your inputs on these.

The field mapping for the CSV format with HC data will be as follows, please confirm.

ORDER_ID - OrderHeader.externalId
LINE_ID - OrderItem.externalId
QUANTITY - sum(ShipmentReceipt.quantityAccepted)

For the quantity field in the CSV, if for a PO item with 10 quantity, 8 qty is accepted and 2 rejected, do we send 8 as the quantity in the CSV, or we still send 10?

For the below statement, do we always send all PO order items irrespective of whether it is received or not?

If any order doesn't receive at OMS, please add zero(0) in the quantity column with order_id and line_id.

How will below scenarios work if above is true?

A PO with 3 Order Items, 2 items received today, do we send all 3 items in the CSV with third item quantity as 0?
If the third item is received the next day, do we need to send all 3 items again in the CSV, wouldn't this create incorrect data at NetSuite end?

For below, discussed with @dixitdeepak , we will not maintain the history records, instead use the saved last run time concept and prepare CSV for the update in POs after it was last sent to NetSuite.
We will check the use of ShipmentReceipt.datetimeReceived field for this.

Note: We need to make sure that PurchaseOrderReceipt CSV file should not contain any record which has been already pushed to NetSuite. It will be similar to the implementation, we did for sales order fulfillment for Shopify.

Just an update here, for point 5 , we will go by history creation records as we already have an entity "ShipmentItemHistory" whjch includes receiptId and can be used here to not send the same records again in multiple feeds.

Adding the required JSON format for NetSuite
[
  {
    "order_id": "36352",
    "items": [
      {
        "line_id": "1",
        "quantity": "2"
      },
      {
        "line_id": "2",
        "quantity": "3"
      },
      {
        "line_id": "3",
        "quantity": "5"
      }
    ]
  },
  {
    "order_id": "36353",
    "items": [
      {
        "line_id": "1",
        "quantity": "5"
      },
      {
        "line_id": "2",
        "quantity": "20"
      }
    ]
  }
]

We have verified the purchase order receipt feed and it is working fine. So we are closing the ticket


feat(biome_css_analyze): noDuplicateSelectors

Summary

This PR aims to implement no-duplicate-selectors from the recommended Stylelint rules. See here:
https://github.com/stylelint/stylelint/tree/main/lib/rules/no-duplicate-selectors

Caveats

This PR does not implement support for SCSS and LESS

resolves #2514
Test Plan

Passes tests from Stylelint: https://github.com/stylelint/stylelint/blob/main/lib/rules/no-duplicate-selectors/tests/index.mjs

I don't know why you requested a review from a rust noob but here you go.

Thank you for the feedback! Since you were providing helpful feedback before, I wanted to do a final check that your feedback was adequately addressed. Anything that can help improve the experience provided by this rule is good I guess 👍

@abidjappie As for now, I just did a dumb review of your code. However, I noticed that the logic of the code is quite lengthy, so we would appreciate it if you explained how you tackled the problem and the logic of your code in the description of the PR.
Without this information, it will be very difficult to get a sensible review, and it will take a long time to merge this.

@ematipico thank you for the feedback so far.
I added some documentation and comments, as well as addressing the feedback from before as best as I could.
I would like to make this as easy as possible to review, so if the documentation is lacking or if there is any additional content I should prepare please let me know! 🙇

@ematipico thank you for the explanations! It's super insightful. 🙇
I think my next steps will be to set this PR back to draft or close it (I would like to use it a reference though) and prepare some more manageable smaller PR's.
My previous attempt using the visitor was doing something like this:
        match event {
            WalkEvent::Enter(node) => {
                if let Some(node) = CssDeclarationOrRuleBlock::cast_ref(node) {
                    self.stack.push(node);
                }
            }
            WalkEvent::Leave(node) => {
                if let Some(_node) = CssRuleList::cast_ref(node) {
                    ctx.match_query(DeclarationOrRuleBlockList(self.stack.clone()));
                    self.stack.clear();
                }
            }
        }

But still resolving it using recursion, I think I need to wrap my head around solving this from a parent -> child rather than from child -> parent 🤔