text:
Customizing and adding colorful and informative pathway tracks.

Describe the issue
Hello, I would like to add colorful tracks underneath top 10 genes. Can I modify the pathway tracks to 1) show how the sample was sequenced (Illumina vs. IonTorrent vs. Both)? Would like to do that for top 10 genes for 100+ patients oncoplot
oncoplot(maf = laml, pathways = "auto", gene_mar = 8, fontSize = 0.6)
Session info
Run sessionInfo() and post the output below
R version 3.6.3 (2020-02-29)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] grid      stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
 [1] VennDiagram_1.6.20  futile.logger_1.4.3 forcats_0.5.1       stringr_1.4.0       dplyr_1.0.5         purrr_0.3.4         readr_1.4.0         tidyr_1.1.3
 [9] tibble_3.1.0        tidyverse_1.3.0     devtools_2.3.2      usethis_2.0.1       ggplot2_3.3.3       maftools_2.8.05

loaded via a namespace (and not attached):
 [1] httr_1.4.2           pkgload_1.2.0        jsonlite_1.7.2       splines_3.6.3        modelr_0.1.8         assertthat_0.2.1     cellranger_1.1.0
 [8] remotes_2.2.0        sessioninfo_1.1.1    pillar_1.6.0         backports_1.2.1      lattice_0.20-41      glue_1.4.2           digest_0.6.27
[15] RColorBrewer_1.1-2   rvest_0.3.6          colorspace_2.0-0     Matrix_1.3-2         pkgconfig_2.0.3      broom_0.7.5          haven_2.3.1
[22] scales_1.1.1         processx_3.4.5       farver_2.1.0         generics_0.1.0       ellipsis_0.3.1       cachem_1.0.4         withr_2.4.1
[29] cli_2.4.0            survival_3.2-7       magrittr_2.0.1       crayon_1.4.1         readxl_1.3.1         memoise_2.0.0        ps_1.6.0
[36] fs_1.5.0             fansi_0.4.2          xml2_1.3.2           pkgbuild_1.2.0       tools_3.6.3          data.table_1.14.0    prettyunits_1.1.1
[43] hms_1.0.0            formatR_1.7          lifecycle_1.0.0      munsell_0.5.0        reprex_1.0.0         lambda.r_1.2.4       callr_3.5.1
[50] compiler_3.6.3       rlang_0.4.10         rstudioapi_0.13      labeling_0.4.2       testthat_3.0.2       gtable_0.3.0         DBI_1.1.1
[57] curl_4.3             R6_2.5.0             lubridate_1.7.10     knitr_1.31           fastmap_1.1.0        utf8_1.2.1           rprojroot_2.0.2
[64] futile.options_1.0.1 desc_1.2.0           stringi_1.5.3        Rcpp_1.0.6           vctrs_0.3.7          dbplyr_2.1.0         tidyselect_1.1.0
[71] xfun_0.21

Hi,
Sure, you can add this info as a bottom annotation bar. Just create a table of sample names and sequencing platform, and pass it to the oncoplot command.
> head(seq_platform)
  Tumor_Sample_Barcode   Platform
1         TCGA-AB-2802   Illumina
2         TCGA-AB-2803    Complex
3         TCGA-AB-2804 IonTorrent
4         TCGA-AB-2805   Illumina
5         TCGA-AB-2806   Illumina
6         TCGA-AB-2807    Complex

oncoplot(
  maf = laml,
  pathways = "auto",
  annotationDat = seq_platform,
  clinicalFeatures = "Platform",
  sortByAnnotation = TRUE)

source: gharchive/issue

authors: PoisonAlien erikagedvilaite

repo: PoisonAlien/maftools

license: MIT

license_type: permissive

license_source: github-api


text:
"Keep_best_custom" preventing from transferring all pokemon selected

Running latest dev, notice I was pokemon slots full but had free slots set to 200.
After troubleshooting with slack I removed this line
"Magikarp": {"keep_best_custom": "iv, cp, hp_max", "amount":5}
And it allowed the bot to then transfer out over 100 karp instead of the five I wanted to keep.
Win10 latest dev build.
Thanks!

I do not really understand your problem, it might be helpful, if you filled out the Issue/Feature request template, that appears when you create a new issue. Keep that in mind for next time at least.
So, what was the expected behaviour, and what happened?

#4689 keep_best_custom doesn't work right now.

authors: doctordo0m mjmadsen sfbakin

repo: PokemonGoF/PokemonGo-Bot


text:
Allow UpdateTitleStats to emit events instead of rewriting the console

@douglascamata, please review.

👍

source: gharchive/pull-request

authors: TheSavior douglascamata mmnsgo


text:
Split payload body into two variables (latitude/longitude)

Just the coords for now ;) may parse JSON object later instead.

updated - for sessionID from encounter_id. merging..


text:
add a new hook useInfo

const  {chain, decimal, formatted, name, token } = useInfo(address);

Should I start working on this issue @Nick-1979 ??

repo: PolkaGate/polkagate-extension


text:
End turn button

some buttons generated by https://dabuttonfactory.com/
expanded game area to include place for a toolbar on the bottom
updated license to allow external art

#20

Please take a look if the license changes makes sense. This is to enable extranal art.

repo: PolyGD/TBFights


text:
Can unsafeCss and lit-html's unsafeHTML share a case convention?

Minor gripe. I can submit a PR if there's agreement on which is "right"

Fixed by #524

authors: sorvell stevvvn

repo: Polymer/lit-element

license_source: bigquery


text:
Polymer 2.2.0 not working in IE11

Description
None of the code samples from https://www.polymer-project.org/2.0/start/quick-tour work on IE11.
Live Demo
http://plnkr.co/edit/Q4E8zO?p=preview
http://plnkr.co/edit/buPxSJ?p=preview
Steps to Reproduce

Open any of the plunkers in IE11
Check the console output (10 errors)

Expected Results
The component renders in IE11.
Actual Results

Browsers Affected

[ ] Chrome
[ ] Firefox
[ ] Edge
[ ] Safari 9
[ ] Safari 8
[X] IE 11

Versions

Polymer: v2.2.0
webcomponents: v1.0.0-rc.5

There seem to be 2 issues:

You are not transpiling. As IE11 does not support ES6, you have to transpile. polymer serve does this automatically for you. Else you have to run babel or use polymer build with es5-bundled
Your polyfill version is quite old. Please upgrade to 1.0.17

What @TimvdLippe says is correct, IE 11 requires transpiling your code to ES5. This can be done with the Polymer command line tool, or any number of other tools.

These are the samples in the quick tour, so this should really be a doc bug.

Currently we don't have a good way to transpile the plunkers for IE11. We're working on a fix for that.

But we can (and should) add a note that the samples don't work on IE11, because they need to be transpiled.

And we should update the plunkers to use a released version of the polyfill. (The polyfill line in all of these plunkers should probably just be: <script src="https://polygit.org/components/webcomponentsjs/webcomponents-loader.js"></script>)

This issue was moved to Polymer/docs#2384

authors: EnzoEghermanne TimvdLippe arthurevans azakus

repo: Polymer/polymer


text:
Fix broken test:unit gulp task.

gulp dependencies run in parallel, so this recent change broke the test script.

gulp dependencies run in parallel?!?!
🤯

Yikes! I had no idea they were parallelized. Nice find. There may be others... Will keep my eyes peeled.

Yeah: https://github.com/gulpjs/gulp/blob/v3.9.1/docs/API.md#gulptaskname--deps-fn
Looks like the new API (still @next) makes this much more clear by introducing .parallel and .series: https://github.com/gulpjs/gulp/blob/master/docs/API.md

I needed to fix this one and a few others in my https://github.com/Polymer/tools/pull/157 branch as well.  Commit: https://github.com/Polymer/tools/pull/157/commits/4f615eb43a749dcde720dde2a1823b7ec8c7a671

authors: aomarks usergenic

repo: Polymer/tools


text:
Web component tester with ECMAScript 6

Hi there
I'm trying to use web component tester with ECMAScript 6 code for my polymer app. I downloaded the polymer starter kit and migrated the code to ECMAScript 6. When I try to run the tests I get the following error:
Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
Is there a workaround for this?
Kind regards
Marc

So, what I did (for now) is following these steps:
http://stackoverflow.com/questions/32957704/how-do-you-test-polymer-components-written-in-es6-es2015-with-web-component-test
Basically the ECMAScript Code is being transpiled before launched. Is there another solution?
Kind regards

repo: Polymer/web-component-tester


text:
Add syntax support for field-level claims.

No DFA support, no proto encoding, just manifest parsing. Only for claims, not checks.
Let me revise my earlier estimate. I think this will take several days, not just 1 or 2.

Thanks, Cameron. I will take a look at this PR shortly.

Let me revise my earlier estimate. I think this will take several days, not just 1 or 2.

Given the revised estimate, is it still worth doing now?  I believe most of the work (except syntax) will carry over when we implement the full-blown proposal for field-level checks and claims. WDYT?
We could implement the full blown proposal directly, but that will take even more time.

Given the revised estimate, is it still worth doing now? I believe most of the work (except syntax) will carry over when we implement the full-blown proposal for field-level checks and claims. WDYT?

Yes I think it's still worth doing. It's not actually the syntax that is the slow bit, it's updating the data structures and subsequent processing to support the new concept. We'll have to do that regardless of what the syntax looks like (and I don't expect it will need to change much if at all if we change the syntax).
It'll take longer than I thought just because there are so many different variations to update: claims in particles, claims on stores, plus a bunch of checks variations I haven't investigated yet.

authors: bgogul csilvestrini

repo: PolymerLabs/arcs


text:
Performance

Is the stamp of a lit-html element faster then the stamp of a polymer element?

Aye, would be nice to know how it compares. I've recently started converting a few components to lit, I'm thinking of converting a few more very tiny components that repeat like crazy in my app to lit if performance is much better :)

Has anyone any performance results?

I have created a benchmark for web components librairies : https://github.com/vogloblinsky/web-components-benchmark
I will publish a blog post about that this week, but before i want to be sure my implementation is correct. I found very strange the result about deleting 50 items in my scenario.

Did i implemented something wrong ?

Are you using 'repeat'? You might want to try the PR for 'repeat-splice'

Yes i use repeat (https://github.com/vogloblinsky/web-components-benchmark/blob/master/lit-element/js/my-todo.js#L51)
I didn't the repeat-slide PR in this repository.

Potentially that could be much faster as it's ports over the same diffing algorithm that Polymer uses, though I haven't profiled it or attempted to optimize it any further

It is a PR for lit-html itself

ok thanks i found it : https://github.com/Polymer/lit-html/pull/260

The repeat directive is basically a placeholder implementation; it currently uses a simple/naive algorithm for updating based on changes to an array that has some degenerate cases, and we intend to improve that.  So from that point of view, it should still be considered work-in-progress and not ready for this type of performance bake-off yet.
Re: Polymer/lit-html#260, We need to explore the cost/benefit tradeoff of using ArraySplice, since it adds a lot of code and doesn't itself have stellar big-O perf characteristics (it has other degenerate cases).

Yes, i will remove WIP projects from this benchmark: lit-html, lit-element & Polymer 3

FWIW I don't think you should remove the WIP projects, since this info is still very useful to early adopters. You SHOULD however clearly mark them as WIP, perhaps with a background and a badge, or in a separate section of the page

Ok i will clearly sepearate them inside the graph for example.

Closing this in favor of https://github.com/Polymer/lit-html/issues/242. This is also on the lit-html 1.0 roadmap https://github.com/Polymer/lit-html/issues/333.

authors: AndreasGalster bennypowers jogibear9988 kenchris kevinpschaaf sorvell vogloblinsky

repo: PolymerLabs/lit-element


text:
shouldSendFeatureFlags can make lose events

In PostHog.java:479
if (shouldSendFeatureFlags) {
  ValueMap flags = featureFlags.getFlagVariants();
  List<String> activeFlags = featureFlags.getFlags();

An exception happens if PostHogFeatureFlags.reloadFeatureFlagsRequest() did not finish when featureFlags.getFlags() was called.
Although this does not make my app crash, it makes lose my very early events before reloadFeatureFlagsRequest() finishes.

We're currently reworking the Android SDK and this will be taken care of, will move this to WIP, so stay tuned.

https://github.com/PostHog/posthog-android/releases/tag/3.0.0-alpha.4 should fix this.
If the reloadFeatureFlags isn't finished, feature flags will just return null.
You can choose to listen for a callback once feature flags are fully reloaded.
Check out https://github.com/PostHog/posthog-android/blob/main/USAGE.md

authors: BattleShipPark marandaneto

repo: PostHog/posthog-android


text:
RPC Helper - semaphore wrapper returning None on exception

Describe the bug
If an exception is raised in a function wrapped by rpc helper's acquire_rpc_semaphore, then that exception will not be propagated, and a value of None will be returned instead:
result = None
try:
    result = await fn(self, *args, **kwargs)
except Exception as e:
    logger.opt(exception=True).error('Error in asyncio semaphore acquisition decorator: {}', e)
finally:
    sem.release()
    return result

This causes issues downstream in situations where the request is expected to raise an exception on failure. For example, system_event_detector expects get_current_block() to return a valid block number if no exception is raised. This behavior is seen in recent error logs after a chain re-org caused rpc request failures. Relevant snippets:
August 14, 2024 > 11:36:24 | ERROR | Error in asyncio semaphore acquisition decorator: {"request": "get_current_block_number", "response": null, "extra_info": "RPC_GET_CURRENT_BLOCKNUMBER ERROR: 500, message='Internal Server Error' ...

File "/snapshotter/system_event_detector.py", line 321, in _detect_events
    if current_block - self._last_processed_block >= 10:
       │               │    └ 796141
       │               └ <EventDetectorProcess name='Powerloom|SystemEventDetector' parent=97 started>
       └ None

TypeError: unsupported operand type(s) for -: 'NoneType' and 'int'

The semaphore wrapper should be changed to re-raise any exceptions, or the dependent processes should be updated to expect None on failure.

I've added a fix to all use cases: https://github.com/PowerLoom/pooler/commit/873f8cd1c872b6924d4595ee89852e2f6432dc34
Deployed changes to all instances.

Update has been running across all instances for a few days. Nodes are handling RPC issues much better.
Added PR into nms_master:

[ ] https://github.com/PowerLoom/pooler/pull/98

repo: PowerLoom/pooler


text:
PSCore: Linux - Clear-Host injects data into function return value

Steps to reproduce
Function Get-SomeData {
    Clear-Host
    $somedata="somedata"
    return $somedata
}

$myData = Get-SomeData

$myData[0]     # will clear the screen
$myData[1]     # "somedata"
$myData.Count  # will be 2

Expected behavior
Function should return a single value ("somedata")

Actual behavior
Function returns an array with the Clear-Host command as the first object

Environment data
Verified in:

Name
Value

PSVersion
6.2.0

PSEdition
Core

GitCommitId
6.2.0

OS
Linux 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019

Platform
Unix

PSCompatibleVersions
1.0 2.0 3.0 4.0 5.0 5.1.10032.0 6.2.0

PSRemotingProtocolVersion
2.3

SerializationVersion
1.1.0.1

WSManStackVersion
3.0

(BTW this works as expected in PSCore - Windows)

Clear-Host on Linux calls the native command /usr/bin/clear,
// Porting note: non-Windows platforms use `clear`
return @"
& (Get-Command -CommandType Application clear | Select-Object -First 1).Definition

which works by outputting a string with ANSI escape codes:
<esc>3;J<esc>H<esc>2J

They are: clear screen including scrollback, move cursor to top left corner, clear screen. Source.
#8554 and #8603 and #8606 and #8609 are related issues, and it looks like there's some debate about whether it's PowerShell or .Net's responsibility, what the default bahviour should be, and how it should interact with "clearing" remote sessions or newly implemented hosts.
As a Linux-specific workaround, you could write that string (or the output of clear) to the host yourself:
Function Get-SomeData {
    $Host.UI.Write("`e[3;J`e[H`e[2J")
    $somedata="somedata"
    return $somedata
}

$myData = Get-SomeData

Sure, I could also (as I've done) fork the logic:
If ($isLinux) { etc }
... but that kind of obviates the point of a cross-platform language, doesn't it?
I think what's more concerning to me is why Clear-Host is messing with my variable stack. Whatever the subtle differences (clear screen, clear buffer+screen, etc) it definitely shouldn't be returning a value.
But that seems to be what's happening here.

Actually the more elegant fix, in case anyone runs across this, is simply:
$null = Clear-Host
Which will clear the call stack so everything behaves as expected. But it's still code behaving badly.

When I try that fix on Ubuntu 16, the screen is not cleared?

why Clear-Host is messing with my variable stack. Whatever the subtle differences (clear screen, clear buffer+screen, etc) it definitely shouldn't be returning a value.

All command output or free values anywhere in a PowerShell function become part of the return value of the function (that decision was taken to copy sh/bash/ksh/etc. behaviour). Clear-Host particularly returns a value because it wraps /user/bin/clear a native command which works by returning a value.
clear doesn't clear the screen directly, it prints a string expecting the display terminal to clear itself. If you do something to block that, the screen doesn't clear and you get the string instead. The same thing happens in Bash; at a shell prompt:
clear     # screen is cleared
clear 1>/tmp/test    # screen is not cleared, reset string written to file

result=`clear`    #screen is not cleared, output captured into variable
echo $result     # screen is cleared.

function test { clear; echo "123"; }
test    # screen is cleared and 123 is output
result=`test`    # screen is not cleared, no visible output
echo $result | wc -c    # result variable has 16 characters, not 3
16

echo $result    # screen is cleared, 123 is output

that kind of obviates the point of a cross-platform language, doesn't it? :)

It seems to behaves like the platform it's running on. Whether that's badly or not, depends on what behaviour you want 🤔

I think it should be a bug because script behavior varies between platforms.
Clear command issues escapes and PowerShell intercepts this. Perhaps we could re-send by raw interface API.
/cc @mklement0

I agree, @iSazonov.
@HumanEquivalentUnit: True, but since PowerShell, unlike Bash, is able to distinguish between to-terminal output and success-stream output, the fix is to write directly to the terminal:
${function:Clear-Host} prints the function definition, and on Unix-like platforms you get:
& (Get-Command -CommandType Application clear | Select-Object -First 1).Definition

The above writes implicitly to the success output stream, so wrapping it in [Console]::Write() fixes the problem:
function Clear-Host {
  [Console]::Write((
    & (Get-Command -CommandType Application clear | Select-Object -First 1).Definition
  ))
}

Test:
& { Clear-Host; 'hi' } | Should -Be 'hi'

(Note: In PowerShell Core 7.0.0-preview.4 I get a spurious Suggestion [4,General]: The most similar commands are: New-Object, Tee-Object. message the first time Should is run in the session, but this is unrelated and can be ignored).

@mklement0 Many thanks! I pulled PR with your suggestion.

Thanks for the quick turnaround, @iSazonov.
Taking a step back: By unconditionally delegating to /usr/bin/clear on Unix-like platforms, we've actually already made Clear-Host terminal-specific, which means that it may malfunction / not do anything meaningful in other types of hosts.
To quote @BrucePay from one of the linked issues, at https://github.com/PowerShell/PowerShell/pull/8603#discussion_r246132597:

This isn't going to work for non-console hosts [...] and remoting. On those platforms, you still need to use the $RawUI portability APIs. A nice solution would be to actually add a new RawUI.Clear() API and then implement that using Console.Clear() in the console host but that may end up being a bunch of work...

Case in point: If you currently execute Clear-Host in a remoting session connected to a Unix machine, it prints the following message to stderr (and does nothing else).
TERM environment variable not set.

@mklement0 I see we have some issues with Clear-Host. but I still don't have the ability to test on Unix-s and can not grab this. (Although we could do RawUI.Clear() step by step).

authors: HumanEquivalentUnit iSazonov mklement0 tescales

repo: PowerShell/PowerShell


text:
Cannot Import Microsoft.PowerShell.Archive to InitialSessionSpace

Steps to reproduce
PSModuleTest.csproj
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.PowerShell.SDK" Version="6.2.3" />
  </ItemGroup>

</Project>

Program.cs
using System;
using System.Management.Automation;
using System.Management.Automation.Runspaces;
using System.Threading.Tasks;

namespace PSModuleTest
{
    class Program
    {
        static async Task Main(string[] args)
        {
            var iss = InitialSessionState.CreateDefault();
            iss.ImportPSModule("Microsoft.PowerShell.Archive");

            using var rs = RunspaceFactory.CreateRunspace(iss);
            rs.Open();

            using var ps = PowerShell.Create();
            ps.Runspace = rs;

            await ps.AddScript("Get-Command Expand-Archive")
                .InvokeAsync();

            if (ps.HadErrors)
            {
                foreach (var error in ps.Streams.Error)
                {
                    Console.WriteLine(error.Exception.Message);
                }
            }
            else
            {
                Console.WriteLine("Expand-Archive is available");
            }
        }
    }
}

Expected behavior
Expand-Archive is available

Actual behavior
The term 'Expand-Archive' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.3
PSEdition                      Core
GitCommitId                    6.2.3
OS                             Microsoft Windows 10.0.18362
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

You could use  ps.AddScript("Import-Module Microsoft.PowerShell.Archive")

@iSazonov this defeats the purpose of having an ImportPSModule function.

I suggest this only for diagnostics. You could try "Get-Module -ListAvailable". I guess your application cannot find the module by paths.

authors: JaimeStill iSazonov


text:
Add a Join-Object cmdlet to the standard PowerShell equipment

As the verb-noun convention suggests, I think that there are a lot of developers looking for a common way to join objects (lists), actually it appears a decennia old quest: as shows from the PowerShell Team Join-Object article and StackOverflow issues along with: In Powershell, what's the best way to join two tables into one?
Personally, I am convinced that a Join-Object cmdlet will generally result in a better syntax were an object (list) join is required (in comparison with alternative cmdlets along with Group-Object) and better performance (then using obvious iterators like ForEach-Object together with Where-Object or similar cmdlets and methods).
For that reason I am maintaining a Join-Object script/module for more than 3 years now. I don't think that my Join-Object version should be added to the standard PowerShell package (for one thing, it is written in PowerShell and not C# 🤔), but it might serve as an example for what I would expect from a syntax that comes together with a Join-Object cmdlet.
What do I expect from a "internal" Join-Object cmdlet?

An intuitive idiomatic PowerShell syntax
The syntax should be PowerShell like and include features similar to the SQL Join clause where it basically joins (a list of) objects or items based on related properties (-On parameter) or a simple side-by-side list join (by omitting the -On parameter) as a specific PowerShell cmdlet feature (see: #14732) .
Ability to do similar Join types as SQL, along with InnerJoin, LeftJoin, RightJoin, FullJoin
Ability to join based on multiple property relations, e.g.: -On Column1, Column2
Smart property merging (e.g. if a properly is defined as related, it should only appear ones in the result)
Respect the PowerShell pipeline (for the left object supplied through pipeline)
A reasonable performance by using a binary search (HashTable) on the right object (knowing that it needs to be iterated multiple times).
Also note the Linq Join-Object solution by @ili101
Calculated properties
...

An aside re:

And it could even prevent to invest too much in traditional operators as shown here.

As I've argued in detail in https://github.com/PowerShell/PowerShell/issues/14724#issuecomment-777801399, there is no reason to pit cmdlet-based solutions against expression / statement-based solutions: both are necessary, and in certain cases use of one over the other is the only option. Instead, we should strive for feature parity, to the extent that is feasible.

vote for this feature

It would be a highly useful addition to the suite. There is actually even another maintained version: https://github.com/ili101/Join-Object. This goes to show that there is a realistic need for such a feature.

@iRon7
Regarding the performance points you mentioned, I just run some tests to check. on 100k rows test data:
JoinModule LeftJoin-Object took 16s.
Join-Object Join-Object took 4s, and 2s when selecting DataTable output.
Regarding Laziness my module is not Lazy, it will only return once everything executed as I wanted to return the simple objects that everyone know and not the Linq lazy objects.
Regarding memory I didn't log the results as it never was a limitation for me but from opening task manager my module seems to consume much less (or Task manager was too slow to show it before it finished?).
Regarding "end-to-end solution" well this is depended on the user use case, I tend to not pipe the output usually. For example a lot of the time I will pass the data to ImportExcel Export-Excel, in this case NOT piping the data and providing it as DataTable type will result in multiple orders of magnitude faster export.

In note that Join-Object is in the PowerShell Gallery.
I don't see any need for it being added to the default install. Doing that prevents it being extended independently of the PowerShell releases.
It means you can run a new version of the module on an older version of PowerShell.

I don't see any need for it being added to the default install. Doing that prevents it being extended independently of the PowerShell releases.
It means you can run a new version of the module on an older version of PowerShell.

Adding it to the standard equipement doesn't exclude the possibility to have a independent corresponding version available on the PowerShell Gallery. In fact, including it in future PowerShell versions will lead to more consistent solutions for this more than a decennia old PowerShell desire.
A huge number of PowerShell questions on StackOverflow are about joining objects and could have a more common answer then the above outdated (Google top ranked) document or any of the Join-Object modules available on the PowerShell Gallery which all have different parameters and features.

PowerShell is about mechanism, not policy. It originated from the idea from UNIX of do one thing and do it well. People often make the comparison between PowerShell and bash, but bash does not include any of the POSIX tools, cat/ls/grep etc.
Compare with somebody on Slashdot asking how to write a shell script to use JSON or XML, it does not mean that bash or zsh have to change. Instead, the suggestion is to use "jq" or whatever, if that is not installed, then make it a dependency/requirement for your script and add it to your system.
The locked/restricted down environment is often brought up as a reason why PowerShell must include everything. I suggest it demonstrates the complete opposite. With a locked down environment you have the minimal installed tool set to do the job. If the tool is not required to do the job it is not installed. If it is required, then it is installed. That allows you to have the smallest surface are. If the requirements of the system change and new capabilities are required then go through the change request process.

@rhubarb-geek-nz,

PowerShell is about mechanism, not policy.

Agree, yet I wouldn't gather joining objects under "PowerShell must include everything".
As I see it, a Join-Object cmdlet would come close after the ForEach-Object, Where-Object and Select-Object cmdlets where you might even consider a PowerShell Object array method similar to the .foreach() and the .where(scriptblock expression[, WhereOperatorSelectionMode mode [, int numberToReturn]]):
`.Join(<array> [,On property[,Join mode]])`

Which by default does a side-by-side join (see also: #14732, similar to the Unix Paste command) and optionally bases a join on a related property (and/or a specific join type).

Certainly there is demand for Join-Object ( this is not an exhaustive list )

PSGallery
Author
Total Downloads
Version
Date
Current Downloads

PoshFunctions
riedyw
18,993
2.2.10
30/10/2023
9,925

JoinModule
iRon
149,522
3.8.3
10/06/2023
44,753

Join
iRon
17,412
3.8.3
10/06/2023
17,412

Join-Object
illy
114,887
2.0.3
05/04/2022
81,965

PSExcel
ramblingcookiemonster
623,341
1.0.2
09/08/2016
623,341

WFTools
ramblingcookiemonster
24,545
0.1.58
04/06/2018
21,099

Yet in that popularity lies a problem.
I note that they all are variations on a theme buit often with very few command line arguments in common.
The PowerShell team are very sensitive about breaking changes, be it interpretation of a command line argument or how a particular file is parsed. Unlike a compiled language, a change to PowerShell itself can break every installation, especially with automatic updates.
Now if PowerShell did adopt one of the above (or write a new Core only standards conforming Join-Object) it would potentially break anyone using any of the un-choosen implementations.
You would then have further incompatibility when new scripts assume that the new standard Join-Object exists and this usage is incompatible with any of the other implementations. Something will break, it does not matter which module gets the priority, the gallery one or the one in c:\program files\powershell\7\Modules.
As the Whopper said in War Games, the only way to win is to not play the game. So let people choose the one they want from the PSGallery.

Now if PowerShell did adopt one of the above (or write a new Core only standards conforming Join-Object) it would potentially break anyone using any of the un-choosen implementations.

Afaik, systems that already have  a custom module/function ("any of the un-choosen implementations") installed won't break if a future PowerShell would include a common Join-Object cmdlet:

The cmdlet of the Microsoft.PowerShell.Core library will be loaded first.
Any custom module/function with a command with the same name as an existing command in the session. The newly imported command replaces takes precedence over the existing command.

Users have the option to move to the core version by removing the module that includes "any of the un-choosen implementations" (they are in control).
Users of any custom module/function that would like to use both (custom - and core Join-Object). Might use the qualified name: Microsoft.PowerShell.Core\Join-Object.

Unfortunately, I am well known with how standard proliferate as it happens a lot in organizations that do not have control, but the PowerShell team is in fact the leader here and the entity that might take control of this Join-Object clutter knowing that there can only be one Microsoft.PowerShell.Core\Join-Object.
Besides, with my next JoinModule update, I will hide/archive the Join function version (one down), and if the PowerShell Team decides to equipe PowerShell with a standard Join-Object cmdlet with similar features as proposed in this issue, I will stop further development of my own implementation and happily refer to this standard PowerShell Join-Object instead (along with a migration document if required).

Ironically I found this post because I wanted a general mechanism to combine output from a pipeline, and the existing versions of Join-Object were not want I wanted. I wanted something that was like the existing joins.
PS> get-command -verb Join

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Join-Array                                         1.0.0      rhubarb-geek-nz.Joinery
Cmdlet          Join-DtcDiagnosticResourceManager                  1.0.0.0    MsDtc
Cmdlet          Join-Path                                          7.0.0.0    Microsoft.PowerShell.Management
Cmdlet          Join-String                                        7.0.0.0    Microsoft.PowerShell.Utility

So hence Join-Array.

I wanted a general mechanism to combine output from a pipeline

Isn't that just Foreach-Object { $_ }?
@( @(1,2) , @(3,4,5) ) | Foreach-Object { $_ } | ConvertTo-Json
[
  1,
  2,
  3,
  4,
  5
]

I wanted a general mechanism to combine output from a pipeline

Isn't that just Foreach-Object { $_ }?

No. I have some GZip tools that encode and decode GZip and work in a pipeline and a single file may be broken into multiple byte [] during the process
PS> Get-Content -LiteralPath bin\Release\netstandard2.0\publish\RhubarbGeekNz.GZip.dll -AsByteStream -Raw | ConvertTo-GZip | ForEach-Object { $_.Length }
10
8192
2997

The output is multiple byte[].
PS> Get-Content -LiteralPath bin\Release\netstandard2.0\publish\RhubarbGeekNz.GZip.dll -AsByteStream -Raw | ConvertTo-GZip | Join-Array -Type ([byte])  | ForEach-Object { $_.Length }
11199

So that efficiently combines them into a single record.

This would be a highly useful addition to PowerShell!

Seems like this should exist, along with the other LINQ equivalents like Any / Single / First / FirstOrDefault / Single / SingleOrDefault / etc..
While i think the heart of this issue is truly worthwhile i think we should be stressing the need for  parity with the rest of the .NET ecosystem and we need the ability to handle both IEnumerable and IQueryable in a robust and powerful way. I've  professionally spent 10's or 100's of hours building commandlets manually that would have been trivial if powershell handled IQueryable correctly.
I will take a leap and suggest most people using powershell care about the .NET ecosystem, so parity of features is paramount. Join-Object should have an exact 1-1 parity with system.linq.enumerable.join() And all the other features of LINQ should be fully supported.

@hannasm,
Thank you for supporting this PowerShell enhancement request. I agree with you that Linq is very powerful and there should be a possibility to boost the a join cmdlet where both element lists have strict properties and reside already in memory.
But I personally think that the general vision should be a cmdlet that supports idiomatic PowerShell (see the introduction of: PowerShell scripting performance considerations). Meaning that a recent StackOverflow question as Map csv content with Powershell table output [closed] from a novice PowerShell author could be answered with a single command line but also means that the cmdlet should:

support the PowerShell pipeline (One-at-a-time processing for one of the element sides
keep the element properties loosely, meaning: support for the general PSCustomObject class.

Pipeline
In a common situation, the initial source of the object lists will not be resident in memory but require to be retrieved from a (slower) long term storage (as the file system or a database) and the same applies for the target storage. This make the PowerShell pipeline very useful where you might just load one (the smaller) element list into memory and do One-at-a-time processing on the (larger) element list. As for the example StackOverflow question:
                               Import-Csv <data file>
                                         ↓
Import-Csv <large data file> | Join-Object (-on Alias) | Export-Csv <output data file>

The will safe memory (knowing that the PowerShell objects are quiet heavy by design as they are actually optimized for the pipeline) and would hardly impact the performance if you measure the whole end-to-end solution.
Loosely
PowerShell is a loosely scripting language by design where each object property might contain a different type as apposed to  Linq which pushes for strict element properties (as in a DataTable where each property in a column needs to be of the same type to be joined upon), this means that you might need to cast a whole column to a specific data type (as a [string]) where it might be desired to keep the individual types (along with a simple $Null, rather than empty string)

where both element lists have strict properties and reside already in memory

Technically Linq does not require the data to be in memory. When working with database result sets you can use Linq and the actual select can be delayed until the last moment and the select performed on the database can be very efficient where an Any() can become a count(*) and the results are streamed through the result set. So in theory the database command result set streaming could be paralleled to a cmdlet's output pipeline. That said, there is a lot of infrastructure code that works with the different databases to make that happen.

Loosely
Linq which pushes for strict element properties

You can set the type to object, so it accepts practically any type. like here where the "table" is an object and the compare "column" is also an object. it's not fun to use in Powershell as anything Linq/System.Func is very verbose but it's supported.

I don't believe the linq compatibility should be in conflict with
conforming to idiomatic powershell. I mostly just think there is a clear
feature set  to base the design on.
Enumerable.Join() uses separate lambdas to specify the join keys for inner
and outer collections being joined and then a final lambda to project the
result. Something like this would seem an appropriate starting point.
If the collections implement Iqueryable they should delegate to an
IQueryable implementation (I'm sure this will be very tricky because you
have to convert the lambdas to expression trees). If the collections
support IEnumerable they should delegate to an IEnumerable implementation.
If there is a need for special cases against powershell collections that
should certainly receive further attention.
Creating PSCustomObject instead of what frequently would be an anonymous
type in C# seems completely reasonable. Supporting pipelines / cancellation
/ etc... would still be mandatory
On Mon, Jun 3, 2024, 12:33 rhubarb-geek-nz @.***> wrote:

where both element lists have strict properties and reside already in
memory
Technically Linq does not require the data to be in memory. When working
with database result sets you can use Linq and the actual select can be
delayed until the last moment and the select performed on the database can
be very efficient where an Any() can become a count(*) and the results
are streamed through the result set. So in theory the database command
result set streaming could be paralleled to a cmdlet's output pipeline.
That said, there is a lot of infrastructure code that works with the
different databases to make that happen.
—
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/14994#issuecomment-2145654895,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AASHZJHPOWF3JWK7AU37AQTZFSLGPAVCNFSM4ZAJMQP2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJUGU3DKNBYHE2Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

I don't believe the linq compatibility should be in conflict with conforming to idiomatic powershell..

I would rather Join-Object does PowerShell well rather than Linq. Linq is just a technology to achieve goals. The goal is to provide a consistent Join-Object.
On a similar vein I would rather that Join-Object does not become part of the core product but remains separately available via the PSGallery. Independence will give it greater freedom to evolve without being tied to the PowerShell delivery cycle.


text:
Improve the error messages resulting from attempting to modify read-only .NET types

Summary of the new feature/enhancement
Attempting to modify an instance of a read-only .NET data type should indicate in the error message resulting from the failed attempt that the data type is indeed read-only.
From the current error messages (as of PowerShell Core 7.2.0-preview.4) this is hard to infer:
Given the following dictionary:
$readOnlyDict =
    [System.Collections.ObjectModel.ReadOnlyDictionary[string, string]]::new(
      [System.Collections.Generic.Dictionary[string, string]]::new()
    )

Here are the - unhelpful - error message currently being emitted:
# Note that *getting* a value works fine.
PS> $readOnlyDict['foo'] = 'bar'
InvalidOperation: Unable to index into an object of type "System.Collections.ObjectModel.ReadOnlyDictionary`2[System.String,System.String]".

# Note that the .method *does* exist, due to interface implementations.
PS> $readOnlyDict.Add('foo', 'bar')
MethodException: Cannot find an overload for "Add" and the argument count: "2".

# Note that the .method *does* exist, due to interface implementations.
PS> $readOnlyDict.Clear()
MethodException: Cannot find an overload for "Add" and the argument count: "2".

Only using dot notation, which uses a different code path, currently provides a helpful error message:
PS> $readOnlyDict.foo = 'bar'
OperationStopped: Collection is read-only.

For $readOnlyDict['foo'] = 'bar', I agree the error message could be improved. The C# compilation error for the same statement is

Property or indexer 'ReadOnlyDictionary<string, string>.this[string]' cannot be assigned to -- it is read only

But for the other 2 examples $readOnlyDict.Add('foo', 'bar') and $readOnlyDict.Clear(), they are explicit interface implementation and thus are not directly available on the class. Therefore, powershell cannot find them and the error message is appropriate. The C# complication error is also essentially "cannot find it":

'ReadOnlyDictionary<string, string>' does not contain a definition for 'Add' and no accessible extension method 'Add' accepting a first argument of type 'ReadOnlyDictionary<string, string>' could be found (press F4 to add an assembly reference or import a namespace)

Glad to hear you agree on the first message, but let me revisit your argument regarding the other two:
PowerShell surfaces the methods of even explicit interface implementations implicitly, and note that the error message doesn't indicate that it cannot find the method(s) (it can, as $readOnlyDict.Add reveals), but (falsely) suggests that there's a problem with either the count or the type of the arguments, which is not true.
This is analogous to calling the IList.Add() method implicitly available on arrays, where a meaningful error message is provided:
# OK (meaningful error message "Collection was of a fixed size.")
@(1, 2).Add(3)


text:
when I use 'get-command', the path of the command display incompletely when the path are long.

Summary of the new feature / enhancement
when I use 'get-command' to get the path of the command. However the command can't display completely if they are long!!

i hope the path can automatically use another line to display it 🤔
Proposed technical implementation details (optional)
No response

You can pipe to Format-Table -Wrap or Select-Object -ExpandProperty Source.

authors: Michaelzhouisnotwhite SeeminglyScience


text:
Provide a way to exclude cmdlets from some modules from completions in a concrete powershell session

Summary of the new feature / enhancement
As a user I want to configure my powershell profile to exclude completion from certain modules that I'm not using on a given context. For example, as a developer when I'm on a powershell session and type Remove-I for (remove-item) the first result I get on autocompletion is Remove-InitiatorId.
In many scenarios like these, some commands that won't ever be used in this context lead to a poor experience where you need to either type more characters to disambiguate or tab through.
It's great that by default you can get commands from all installed modules for discoverability, but with the growing number of modules it becomes painful to use on a regular session.
To provide an analogy, this is similar to importing all namespaces by default on C#, each type is readily available, but searching through the types becomes much more problematic because they are way more irrelevant types in scope.
Proposed technical implementation details (optional)
Ideally this would be either an allow list or a block list (possibly an allow list), where you can set your preferences for the session via a cmd-let to filter completions to the modules you've defined.
Set-CommandCompletion Microsoft.PowerShell.Utility, Microsoft.PowerShell.Management
That will make only commands in those modules to be considered for completions and you can put this on your $Profile so that it happens every time you create a new session.

At the very least, prioritizing  commands from loaded modules over those in available modules would help.

I would like to ask a similar question.
I have developed a multi-process powershell automatic management tool [kasini3000].
I want to know how to get a powershell with the least functions, the smallest memory footprint, and the smallest powershell without loading most .net dlls. Only powershell engine,
how should I do it?

You can (mostly) do this today. If you set $PSModuleAutoLoadingPreference = "None" PowerShell won't find commands from modules that haven't been imported so instead of running Set-CommandCompletion Microsoft.PowerShell.Utility, Microsoft.PowerShell.Management to limit completions to commands from those modules you instead use Import-Module Microsoft.PowerShell.Utility, Microsoft.PowerShell.Management to explicitly import the modules you want to use in your session.

Thank you for the feature suggestion!  The WG reviewed this and feels that by having an allow list, could create even more confusion. The above suggestion from @MartinGC94 to disable autoloading of the modules would be a benefit -- also note that you can create a custom expansion to filter the results.  There are multiple examples on the PSGallery that may be of interest. https://teams.microsoft.com/l/message/19:meeting_OTE4MDhkYzAtMmM0Ni00MjRjLWEwMjEtNTJhOTM1OTZhMTFi@thread.v2/1691007155506?context={"contextType"%3A"chat"}

Well, this is awkward. I actually have 2 pending PRs to fix this particular issue. One for adding the option to Get-Command: https://github.com/PowerShell/PowerShell/pull/18955 and another to add commands to manage various completion options: https://github.com/PowerShell/PowerShell/pull/19518
I know I was initially against the idea, but I changed my mind after installing some modules that added literally thousands of commands to my command completion, many of which I have no use for when I'm in the shell. In an editor it can also be nice to filter out commands from for example VMware if you are working on a Hyper-V script and vice versa without disabling autoloading of modules.


text:
Azure uses YAML. Please finally add ConvertFrom-Yaml, ConvertTo-Yaml

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Start using PowerShell and Azure Pipelines with YAML
Now Microsoft expects that customers have to install uncontrolled opensource modules just so PowerShell can work with YAML
For us, this is extremely unexpected
And it's a pain for many years that M$ has no inner motivation to keep the PowerShell technology stack up to date.

Expected behavior
Get-Content 'config.yaml' | ConvertFrom-Json
# of course, ConvertTo-Yaml is missing too.

# It's a shame that we have to explain it.

Actual behavior
# 1. Search an open Source PowerShell module that handles yaml
# 2. make a review to be sure it has no security issues
# 3. Install and test the module
# 4. Search the next module, test it
# 5. If you finally have a Module, install and use it.
# 6. For each Modul-Update, restart at step 3.

Error details
No response
Environment data
# Rel. 7.x must have yaml support
# Rel. 5.x should have yaml support

Name                           Value
----                           -----
PSVersion                      5.1.19041.1023
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.1023
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Visuals
No response

Conclusion "Won't fix" was made by WG-Cmdlets in Aug,2021
It seems .Net hasn't plans to implement YAML so close as duplication.

To  put  everything  in one place here is what was said in 3607

@PowerShell/wg-powershell-cmdlets has been discussing this issue, and despite the extremely high demand (and my own personal desire to have strong, canonical YAML cmdlets), we're unfortunately going to have to close it (for now) as Won't Fix. The reasoning is two-fold:

(1) While the PowerShell package is already fairly large, we're doing our best not to add new dependencies to the package so that we don't continue to grow our size unfettered, and because we believe that pulling modules from the PowerShell Gallery (or an internal trusted Gallery, having been vetted appropriately by an enterprise) should be a standard part of a PS7 workflow.
(2)  As a team, we simply don't have the capacity to build a .NET YAML parser from scratch, nor do we have the capacity to vet, support, and service a 3rd party library for which the security implications are high-stakes.
If .NET were to officially support a YAML library, we (as Microsoft) could potentially look into supporting a YAML module on the Gallery. But until that point, the existing community modules will have to suffice.

The community module referred to has been downloaded 18 million times. It is based on  YamDotNet has been download from Nuget 36 Million times.   But as the quote above says the team don't have the capacity to "vet support and service"  it (I'm not sure what happened with NewonSoftJson before .NET added native JSON support).
We have a classic case of different Microsoft teams ignoring each other

Azure Pipelines team  YAML Is new and shiny let's be the first to use it!!!
** PowerShell team **  Customers want us to do more things than Microsoft gives resource for.  We can't write parsers for JSON, XML, YAML etc. (or validate 3rd party ones)  we need .NET to do that. A module which uses a community parser needs to be a community module.
** .NET team **  We don't see the need to support every markup as it is invented, and there are good community libraries.

and customers like the OP say they don't want "community"  stuff they want everything to come from Microsoft. (Though from the use of "M$"  I assume the OP doesn't like paying for it).

authors: iSazonov jhoneill schittli


text:
Cannot stop StartupScript set in PSSessionConfiguration with CTRL+C

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
This question was transferred from discussions
Consider following setup:

Computer "A":

Register-PSSessionConfiguration -Name 'Test' -StartupScript 'C:\Test.ps1'

with following content of the Test.ps1 script (a loop):
for($i=1;;$i++){$i; Start-Sleep 1}

Computer "B":

Enter-PSSession -Computer 'A' -ConfigurationName 'Test'

When you enter the session on computer A the CTRL+C does not stop the startup script execution. The only way is to restart WinRM service on computer A.
Questions:

Is there a way (workaround) to stop the startup script?
When registering PSSessionConfiguration the StartupScript is executed immediately, why? (is it a bug or design choice?)

Expected behavior
1. CTRL+C should stop StartupScript set in PSSessionConfiguration
2. StartupScript should not be executed when registering new PSSessionConfiguration

Actual behavior
1. Cannot stop StartupScript with CTRL+C
2. StartupScript is executed immediately when registering PSSessionConfiguration

Error details
N/A

Environment data
PSVersion                      7.3.0
PSEdition                      Core
GitCommitId                    7.3.0
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0, 5.0, 5.1.10032.0, 6.0.0, 6.1.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals
No response

I'm fairly sure this is by design. The script is used to set restrictions on the remote environment for things like JEA. If it were possible to break the script it would be possible to make a JEA session a full admin one.
Testing the script before configuring it as the one to run for a PSSessionConfiguration would seem to be the solution to the case you've described.

That makes sense. Thanks for the insight.

authors: jhoneill kborowinski


text:
7.5.0-preview.5: Crashin' @startup

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
$ pwsh -nop -nol
Fatal error. Internal CLR error. (0x80131506)
   at System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(System.RuntimeMethodHandle, System.RuntimeTypeHandle[])
   at A.E.d(System.RuntimeMethodHandle[])
   at A.a.D(A, System.String, System.Type, System.Reflection.MethodBase, Boolean)
   at A.a.B(System.Reflection.Assembly, A)
   at A.a.a(System.Reflection.Assembly)
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at System.Management.Automation.Runspaces.PSSnapInHelpers.GetAssemblyTypes(System.Reflection.Assembly, System.String)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzeModuleAssemblyWithReflection(System.Reflection.Assembly, System.String, System.Management.Automation.PSSnapInInfo, System.Management.Automation.PSModuleInfo, System.String, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateCmdletEntry> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Collections.Generic.List`1<System.Management.Automation.Runspaces.SessionStateAliasEntry>> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateProviderEntry> ByRef)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzePSSnapInAssembly(System.Reflectioemedve@lus-pw00njlz:~ $ pwsh -nop
PowerShell 7.5.0-preview.5
Fatal error. Internal CLR error. (0x80131506)
   at System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(System.RuntimeMethodHandle, System.RuntimeTypeHandle[])
   at A.E.d(System.RuntimeMethodHandle[])
   at A.a.D(A, System.String, System.Type, System.Reflection.MethodBase, Boolean)
   at A.a.B(System.Reflection.Assembly, A)
   at A.a.a(System.Reflection.Assembly)
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at System.Management.Automation.Runspaces.PSSnapInHelpers.GetAssemblyTypes(System.Reflection.Assembly, System.String)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzeModuleAssemblyWithReflection(System.Reflection.Assembly, System.String, System.Management.Automation.PSSnapInInfo, System.Management.Automation.PSModuleInfo, System.String, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateCmdletEntry> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Collections.Generic.List`1<System.Management.Automation.Runspaces.SessionStateAliasEntry>> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateProviderEntry> ByRef)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzePSSnapInAssembly(System.Reflection.Assembly, System.String, System.Management.Automation.PSSnapInInfo, System.Management.Automation.PSModuleInfo, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateCmdletEntry> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Collections.Generic.List`1<System.Management.Automation.Runspaces.SessionStateAliasEntry>> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateProviderEntry> ByRef, System.String ByRef)
   at System.Management.Automation.Runspaces.InitialSessionState.ImportCmdletsFromAssembly(System.Reflection.Assembly, System.Management.Automation.PSModuleInfo)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadBinaryModule(System.Management.Automation.PSModuleInfo, System.String, System.String, System.Reflection.Assembly, System.String, System.Management.Automation.SessionState, ImportModuleOptions, ManifestProcessingFlags, System.String, Boolean ByRef, System.String, Boolean)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModule(System.Management.Automation.PSModuleInfo, System.String, System.String, System.String, System.Management.Automation.SessionState, System.Object, ImportModuleOptions ByRef, ManifestProcessingFlags, Boolean ByRef, Boolean ByRef)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleNamedInManifest(System.Management.Automation.PSModuleInfo, Microsoft.PowerShell.Commands.ModuleSpecification, System.String, Boolean, System.String, System.Management.Automation.SessionState, ImportModuleOptions, ManifestProcessingFlags, System.Object, Boolean ByRef, System.String, System.Nullable`1<System.Management.Automation.PSLanguageMode>)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(System.String, System.Management.Automation.ExternalScriptInfo, System.Collections.Hashtable, System.Collections.Hashtable, ManifestProcessingFlags, System.Version, System.Version, System.Version, System.Nullable`1<System.Guid>, ImportModuleOptions ByRef, Boolean ByRef)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModule(System.Management.Automation.PSModuleInfo, System.String, System.String, System.String, System.Management.Automation.SessionState, System.Object, ImportModuleOptions ByRef, ManifestProcessingFlags, Boolean ByRef, Boolean ByRef)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadUsingExtensions(System.Management.Automation.PSModuleInfo, System.String, System.String, System.String, System.String, System.String, System.Management.Automation.SessionState, ImportModuleOptions, ManifestProcessingFlags, Boolean ByRef, Boolean ByRef)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadUsingModulePath(System.Management.Automation.PSModuleInfo, System.Collections.Generic.IEnumerable`1<System.String>, System.String, System.Management.Automation.SessionState, ImportModuleOptions, ManifestProcessingFlags, System.Management.Automation.PSModuleInfo ByRef)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName(ImportModuleOptions, System.String)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName_WithTelemetry(ImportModuleOptions, System.String)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()
   at System.Management.Automation.CommandProcessorBase.DoExecute()
   at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(System.Object)
   at System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper()
   at System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()
   at System.Management.Automation.Runspaces.PipelineThread.WorkerProc()
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

Expected behavior
Start successfully

Actual behavior
$ pwsh -nop -nol
Fatal error. Internal CLR error. (0x80131506)
   at System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(System.RuntimeMethodHandle, System.RuntimeTypeHandle[])
   at A.E.d(System.RuntimeMethodHandle[])
   at A.a.D(A, System.String, System.Type, System.Reflection.MethodBase, Boolean)
   at A.a.B(System.Reflection.Assembly, A)
   at A.a.a(System.Reflection.Assembly)
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at System.Management.Automation.Runspaces.PSSnapInHelpers.GetAssemblyTypes(System.Reflection.Assembly, System.String)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzeModuleAssemblyWithReflection(System.Reflection.Assembly, System.String, System.Management.Automation.PSSnapInInfo, System.Management.Automation.PSModuleInfo, System.String, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateCmdletEntry> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Collections.Generic.List`1<System.Management.Automation.Runspaces.SessionStateAliasEntry>> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateProviderEntry> ByRef)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzePSSnapInAssembly(System.Reflectioemedve@lus-pw00njlz:~ $ pwsh -nop
PowerShell 7.5.0-preview.5
Fatal error. Internal CLR error. (0x80131506)
   at System.Runtime.CompilerServices.RuntimeHelpers.PrepareMethod(System.RuntimeMethodHandle, System.RuntimeTypeHandle[])
   at A.E.d(System.RuntimeMethodHandle[])
   at A.a.D(A, System.String, System.Type, System.Reflection.MethodBase, Boolean)
   at A.a.B(System.Reflection.Assembly, A)
   at A.a.a(System.Reflection.Assembly)
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at System.Management.Automation.Runspaces.PSSnapInHelpers.GetAssemblyTypes(System.Reflection.Assembly, System.String)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzeModuleAssemblyWithReflection(System.Reflection.Assembly, System.String, System.Management.Automation.PSSnapInInfo, System.Management.Automation.PSModuleInfo, System.String, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateCmdletEntry> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Collections.Generic.List`1<System.Management.Automation.Runspaces.SessionStateAliasEntry>> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateProviderEntry> ByRef)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzePSSnapInAssembly(System.Reflection.Assembly, System.String, System.Management.Automation.PSSnapInInfo, System.Management.Automation.PSModuleInfo, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateCmdletEntry> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Collections.Generic.List`1<System.Management.Automation.Runspaces.SessionStateAliasEntry>> ByRef, System.Collections.Generic.Dictionary`2<System.String,System.Management.Automation.Runspaces.SessionStateProviderEntry> ByRef, System.String ByRef)
   at System.Management.Automation.Runspaces.InitialSessionState.ImportCmdletsFromAssembly(System.Reflection.Assembly, System.Management.Automation.PSModuleInfo)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadBinaryModule(System.Management.Automation.PSModuleInfo, System.String, System.String, System.Reflection.Assembly, System.String, System.Management.Automation.SessionState, ImportModuleOptions, ManifestProcessingFlags, System.String, Boolean ByRef, System.String, Boolean)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModule(System.Management.Automation.PSModuleInfo, System.String, System.String, System.String, System.Management.Automation.SessionState, System.Object, ImportModuleOptions ByRef, ManifestProcessingFlags, Boolean ByRef, Boolean ByRef)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleNamedInManifest(System.Management.Automation.PSModuleInfo, Microsoft.PowerShell.Commands.ModuleSpecification, System.String, Boolean, System.String, System.Management.Automation.SessionState, ImportModuleOptions, ManifestProcessingFlags, System.Object, Boolean ByRef, System.String, System.Nullable`1<System.Management.Automation.PSLanguageMode>)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(System.String, System.Management.Automation.ExternalScriptInfo, System.Collections.Hashtable, System.Collections.Hashtable, ManifestProcessingFlags, System.Version, System.Version, System.Version, System.Nullable`1<System.Guid>, ImportModuleOptions ByRef, Boolean ByRef)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModule(System.Management.Automation.PSModuleInfo, System.String, System.String, System.String, System.Management.Automation.SessionState, System.Object, ImportModuleOptions ByRef, ManifestProcessingFlags, Boolean ByRef, Boolean ByRef)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadUsingExtensions(System.Management.Automation.PSModuleInfo, System.String, System.String, System.String, System.String, System.String, System.Management.Automation.SessionState, ImportModuleOptions, ManifestProcessingFlags, Boolean ByRef, Boolean ByRef)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadUsingModulePath(System.Management.Automation.PSModuleInfo, System.Collections.Generic.IEnumerable`1<System.String>, System.String, System.Management.Automation.SessionState, ImportModuleOptions, ManifestProcessingFlags, System.Management.Automation.PSModuleInfo ByRef)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName(ImportModuleOptions, System.String)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName_WithTelemetry(ImportModuleOptions, System.String)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()
   at System.Management.Automation.CommandProcessorBase.DoExecute()
   at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(System.Object)
   at System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper()
   at System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()
   at System.Management.Automation.Runspaces.PipelineThread.WorkerProc()
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

Error details
No response
Environment data
$ pwsh -c '$PSVersionTable'

Name                           Value
----                           -----
PSVersion                      7.5.0-preview.5
PSEdition                      Core
GitCommitId                    7.5.0-preview.5
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

Duplicate of #24435

See https://github.com/PowerShell/PowerShell/issues/24435#issuecomment-2464295579
Sentinel One is hard at work.


text:
Investigate why InitialSessionState.CreateDefault2() is slower than CreateDefault()

CreateDefault2() should only be loading the Core cmdlets module while CreateDefault() loads more, yet CreateDefault2() is 3-8 times slower.
'CreateDefault','CreateDefault2' | %{  (measure-command {
$iss = [InitialSessionState]::$_();
1..100 | % { $ps = [powershell]::Create($iss).AddCommand('echo').AddArgument(1); $ps.Invoke(); $ps.Dispose() } }).TotalMilliseconds }

1190.377
3268.448

Formally 'CreateDefault2' is faster 'CreateDefault':
'CreateDefault','CreateDefault2' | %{  (measure-command {
$iss = [InitialSessionState]::$_();
1..100 | % {  } }).TotalMilliseconds }

5.1233
2.0122

Just creating an InitialSessionState is not interesting.
Opening a runspace that uses it is more interesting, bug I get ambiguous results, possibly other factors like garbage collection interfere with definitive results.
But running a command in that runspace - that's a typical scenario, and in theory, in that scenario, CreateDefault2 should do less work, so it should be measurably slower.

What seems to be happening is that during Invoke() Microsoft.PowerShell.Utility\Write-Output (aka. echo) triggers CommandDiscovery.TryModuleAutoDiscovery. While CreateDefault() returns with that module already loaded.
I've tried to explicitly import "C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Utility\Microsoft.PowerShell.Utility.psd1" before Write-Output but it didn't yield the expected results - AddCommand('Write-Output').AddArgument(1).Invoke() is now fast, but most of the time is being spent before that in Import-Module. Seems like it's loading more slowly than in CreateDefault, I must be doing something wrong.

authors: SteveL-MSFT Tadas iSazonov lzybkr


text:
Add support for cd (Set-Location) to path with spaces without requiring quotes

We should consider updating Set-Location to not require quotes for paths.  If I fire up CMD.exe I can do this:
C:\Users\hillr>cd c:\program files

c:\Program Files>

but in PS Core this fails:
06-26 15:56:33 1> cd c:\program files
Set-Location : A positional parameter cannot be found that accepts argument 'files'.

Set-Location takes only a single path.  It would be nice if a user could type the path without having to quote the path.
I imagine this would have to be its own parameter set as I'm not sure how this feature would work in the presence of parameters like -PassThru or -StackName.  But I think far and away the common use case is someone wanting to cd c:\program files, cd c:\program files (x86) or cd ~\Visual Studio 2017.  Not sure how that (x86) bit would work out given that PS will think that starts an expression.  Hmm...

While I'm personally always happy to throw off the shackles of unnecessary quotes, I don't think it's a good idea in this case:

It encourages "fuzzy thinking" with respect to argument-mode syntax, which can get in the way when using other cmdlets.

As time goes on, the need to make seasoned cmd.exe users comfortable will go away.

As for easing the pain:

Tab-completion helps to an extent - e.g., cd C:\Program<tab> - but if you want to type a prefix that includes spaces before pressing <tab>, there is no way around knowing that you need to `-escape such spaces, e.g., cd C:\Program` <tab>

For special folders such as C:\Program Files and C:\Program Files (x86), a namespace with symbolic identifiers (which by definition do not contain spaces and therefore do not need quoting) could help; e.g.,
cd $sf:ProgramFiles or cd $sf:ProgramFilesX86 for changing to the locations that are C:\Program Files and C:\Program Files (x86), respectively, in a default Windows installation.

As it turns out, someone has already suggested that: #6966

I would prefer consistency with other cmdlets and parameters. If I discovered I could pass a Path to cd without quotes, then I would think it would be ok to do that with other cmdlets that take a Path parameter. For that matter, why not be able to do it with passing arguments to executables or when using Start-Process.
Mastering of quotes is so crucial to those other functions that I think adding a special case just makes things more confusing.

Upon further reflection (and reading over issue feedback), I believe I should just close this.  The biggest mitigation is tab-completion supplying the quotes.  Plus I'm really not sure how you'd handle an unquoted (x86)  That would be interpreted as an expression which tries to invoke the command x86.  No bueno.


text:
Module with incorrect case of files

Steps to reproduce
PS /home/lipkau> Install-Module Configuration -MaximumVersion 1.3.0 -Scope CurrentUser -Force
PS /home/lipkau> get-module -list

Expected behavior
  Directory: /home/lipkau/.local/share/powershell/Modules

ModuleType Version  Name                ExportedCommands
---------- -------  ----                ----------------
Script   1.3.0   Configuration            {Import-Configuration, Export-Configuration, Get-StoragePa...

Actual behavior
ModuleType Version  Name                ExportedCommands
---------- -------  ----                ----------------

Environment data
Ubuntu 16.04
> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.17134.112
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17134.112
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Description
Powershell fails to find a module if the manifest file is not in the same case as the folder.
This does not happen on Windows.
This fixes the example above:
# rename the psd1 file to match the case of the folder
PS /home/lipkau> mv "/home/lipkau/.local/share/powershell/Modules/Configuration/1.3.0/configuration.psd1" "/home/lipkau/.local/share/powershell/Modules/Configuration/1.3.0/Configuration.psd1"

# list folder content
PS /home/lipkau> ls "/home/lipkau/.local/share/powershell/Modules/Configuration/1.3.0/"
Configuration.psd1 Configuration.psm1 en-US Metadata.psm1 PSGetModuleInfo.xml

Given the current behavior, it seems that it should look for an exact match first.  If that fails, do a case-insensitive match.  In the case of multiple manifests, it seems like it should be an error as we don't want to arbitrarily pick one.  Manifests already have priority over script modules if the extension is not given.

authors: SteveL-MSFT lipkau


text:
Generic type definitions should be included in TypeNames for PSObject

In the same vein as #7649, it would be great if you could assign type data to generic definitions of constructed generic types.
For example, List<int> would contain the type names:
System.Collections.Generic.List`1[[System.Int32, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]
System.Collections.Generic.List`1
System.Object

And would allow Update-TypeData to target any constructed version of List<T>
Environment data
PS> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.0-rc.1
PSEdition                      Core
GitCommitId                    6.1.0-rc.1
OS                             Microsoft Windows 10.0.15063
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

@SeeminglyScience The concrete generic types are already included in TypeNames, but use the raw reflection type name:
PS[1] (8) >   $x = [system.collections.generic.list[object]]::new()
PS[1] (9) > $x.psobject.typenames
System.Collections.Generic.List`1[[System.Object, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
System.Object
PS[1] (10) > update-typedata -force -typename 'System.Collections.Generic.List`1[[System.Object, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]' -MemberType scriptmethod -membername doit -value {"doit"}
PS[1] (11) > $x.doit()
doit
PS[1] (12) >

Using the raw name in TypeNames is arguably a bug but correcting it would be a breaking change. As a non-breaking alternative,  we could allow the the use of the sanitized name when specifying extensions converting it to the raw name in the type table.

@BrucePay I'm asking for the generic definition to be added to the list.  For example List<T> is the generic definition of List<object>.  Not sure if my terminology here is technically correct, just going by the naming of Type.GetGenericTypeDefinition()
The example you gave works, but only if you want to target List<object> explicitly.  Put more simply I'd like to be able to do something like this:
using namespace System.Collections.Generic

Update-TypeData -Force -TypeName 'System.Collections.Generic.List`1' -MemberType ScriptMethod -MemberName DoIt -Value { 'doit' }

[List[object]]::new().DoIt()
[List[int]]::new().DoIt()
[List[System.IO.FileSystemInfo]]::new().DoIt()

@vexx32: The `<n> suffix is .NET's notation for indicating a generic type's number of type parameters.
It is required for an open generic type (one whose type parameter(s) have not been bound yet; e.g., [System.Collections.Generic.List`1]), but optional for a closed generic type (a generic type with all its type parameters instantiated with specific types; e.g., both [System.Collections.Generic.List`1[int]] and [System.Collections.Generic.List[int]] work).

@SeeminglyScience: The term that applies to what you're looking for is open generic type.
I haven't looked too hard, but here's a definition from https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-and-attributes (emphasis added):

[...] open generic types, which are generic types for which no type arguments are supplied, and closed constructed generic types, which supply arguments for all type parameters.

@mklement0 @vexx32 The raw form of the typename is what .NET returns when you ToString() a type. In PowerShell V1, the native .NET representation is the only form we used. In V2 we added type name sanitization. The <backtick><number> in the type name is the generic arity i.e. how many type parameters there are on a given generic type.

Thanks, @BrucePay; it's what I meant to say with "indicating a generic type's number of type parameters", but it's good to know the official - and more concise - name for it, generic arity.

In V2 we added type name sanitization

Are you referring to the option of omitting, e.g.,

`1 from [System.Collections.Generic.List`1[int]] (1..10)
and not requiring assembly-qualified type names for the type arguments (just [int] rather than [System.Int32, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e])?

Because Get-Member and .pstypenames still reflect the raw type name (only).
A tangent, for sure, but perhaps you happen to know:
In the raw .NET string representation, what is the benefit of mixing the full-type-name-only generic-type name (e.g., System.Collections.Generic.List) with the assembly-qualified names of the type arguments (e.g., [System.Int32, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e])? Why not consistently use either assembly-qualified type names or full type names only?

Just to fully flesh out that yikes, I'd really like the same to be possible with open generic interfaces (bringing your issue into the fold).  So [System.Collections.Generic.List[string]]::new().PSTypeNames would be this monstrosity
System.Collections.Generic.List`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
System.Collections.Generic.List`1
System.Collections.Generic.IList`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
System.Collections.Generic.IList`1
System.Collections.Generic.ICollection`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
System.Collections.Generic.ICollection`1
System.Collections.Generic.IEnumerable`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
System.Collections.Generic.IEnumerable`1
System.Collections.IEnumerable
System.Collections.IList
System.Collections.ICollection
System.Collections.Generic.IReadOnlyList`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
System.Collections.Generic.IReadOnlyList`1
System.Collections.Generic.IReadOnlyCollection`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
System.Collections.Generic.IReadOnlyCollection`1
System.Object

I don't know how much of an issue that would end up being, perhaps the solution lies outside of PSTypeNames.  To again put it more simply, it would be great if this was possible:
using namespace System.Collections.Generic

Update-TypeData -Force -TypeName 'System.Collections.Generic.IEnumerable`1' -MemberType ScriptMethod -MemberName DoIt -Value { 'doit' }

[List[object]]::new().DoIt()
[List[int]]::new().DoIt()
[List[System.IO.FileSystemInfo]]::new().DoIt()
[string[]]::new(0).DoIt()
[System.Collections.ObjectModel.Collection[int]]::new().DoIt()

@SeeminglyScience:
I think we should consider a separate .psinterfacenames  property that paralles the .pstypenames property.

It would provide a clean separation between non-interface types and interfaces.

As a separate, new property, neither  raw type names nor closed constructed types need be included (as there is no need for backward compatibility).

If type-argument-specific behavior is desired, though, the type-arguments could be included as well, such as System.Collections.Generic.IList[string] in addition to System.Collections.Generic.IList1`

ETS definitions  would then have to consult .psinterfacenames too.

For instance, [System.Collections.Generic.List[string]]::new().psinterfacenames would then be limited to this (still sizable) list (without type-argument-specific variants):
System.Collections.Generic.IList`1
System.Collections.Generic.ICollection`1
System.Collections.Generic.IEnumerable`1
System.Collections.IEnumerable
System.Collections.IList
System.Collections.ICollection
System.Collections.Generic.IReadOnlyList`1
System.Collections.Generic.IReadOnlyCollection`1

@lzybkr: But If the .ToString() method returns this arity notation too (e.g., [System.Collections.Generic.List`1].ToString() yielding System.Collections.Generic.List`1[T]), doesn't that imply that it's not (just)  a C# convention?

@mklement0 - the value returned from Type.ToString() may or may not have any correlation with what a compiler generates. The Type.FullName property is the name the compiler generates.
The convention that C# introduced and every language I know of is to append the arity, but the CLR does not require this.
I'll leave it as an exercise for the reader, but you could use ilasm or the reflection apis to create a generic type with any name you like. Other language might or might not be capable of consuming this type, but the CLR has no problems with such types.

Good to know, @lzybkr, thanks. So how, specifically, does a PowerShell expression such as [System.Collections.Generic.List`1].FullName yield System.Collections.Generic.List`1? Is there a behind-the-scenes C# detour?

@mklement0 I believe what he's saying is that the compiler adds the arity to the type name directly as a convention.  And that if you manually create a generic type you can skip that if you'd like.  e.g.
using namespace System.Reflection
using namespace System.Reflection.Emit

$assemblyBuilder = [AssemblyBuilder]::DefineDynamicAssembly(
    [AssemblyName]::new('TestAssembly'),
    [AssemblyBuilderAccess]::Run)

$moduleBuilder = $assemblyBuilder.DefineDynamicModule('TestModule')
$typeBuilder = $moduleBuilder.DefineType(
    'MyGeneric',
    [TypeAttributes]'Public, Class, Abstract',
    [object])

$null = $typeBuilder.DefineGenericParameters('T')
$null = $typeBuilder.CreateType()

[MyGeneric[int]].FullName
# MyGeneric[[System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]

Thanks for the detailed and illuminating example, @SeeminglyScience. I realize that this tangent may be primarily for my own edification, but if you'll indulge me:
I gather that it's PowerShell - perhaps the sanitizing that @BrucePay referred to -  that ignores a `<n> suffix if it aligns with the actual arity, so that even if you passed a name of 'MyGeneric`1' as the type name to $moduleBuilder.DefineType() you could still instantiate that type later as, for instance, [MyGeneric[int]] from PowerShell, correct?
Does PowerShell itself explicitly implement the arity-suffix convention when it evaluates expressions such as [System.Collections.Generic.List[int]].FullName?

@mklement0 The parser creates a TypeExpressionAst to represent a type literal expression.  That AST has a property TypeName that represents the type with an implementation of ITypeName.  When it creates a TypeExpressionAst for a constructed generic type, the TypeName is of the type GenericTypeName.
When PowerShell goes to actually resolve the type, it calls ITypeName.GetReflectionType().  The implementation of that for  GenericTypeName will first attempt to resolve the name as is, then it will append the arity if that was unsuccessful. Here's that method.

I appreciate the explanation, @SeeminglyScience.
The way the method is written, you can accidentally thwart the implicit arity-suffix logic with a type name such as MyGeneric`Foo`1, but that's probably not a real-word concern.

@mklement0 There is a ToStringCodeMethods class with a string Type(Type type, bool dropNamespaces = false, string key = null) member that pretty-prints typenames.

Thanks, @powercode, good to know how to get a friendly type representation even for generic types, but note the specific overload you mention is internal. There is a public overload - public static string Type(PSObject instance), expecting a type, which actually breaks with @SeeminglyScience's code ("'length' must be non-negative), but for CoreFx types it works well, e.g., [Microsoft.PowerShell.ToStringCodeMethods]::Type([System.Collections.Generic.List`1[[System.Object, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]]) returns System.Collections.Generic.List[System.Object]
But I'm happy to close this tangent now.

@mklement0

The way the method is written, you can accidentally thwart the implicit arity-suffix logic with a type name such as MyGeneric`Foo`1, but that's probably not a real-word concern.

Shouldn't really be an issue unless there's a CLR language out there that parses it in a class name (neither PowerShell nor C# do).  Other than that, if someone is using emit to generate a type with a class name that contains `, they probably don't really intend for the type to be resolvable.

authors: BrucePay SeeminglyScience lzybkr mklement0 powercode


text:
Sort-Object inappropriately sacrifices stability for performance

PR #2518 by @KirkMunro adds the ability to select the top or bottom N items of a sorted set, introducing stability to the sorting method. However, this behavior is undermined whenever N equals or exceeds the input size.
This deviance can be observed when sorting by congruence modulo for example:
Steps to reproduce
1..20 |Sort-Object {$_ % 3} -Top 20

Expected behavior
3
6
9
12
15
18
1
4
7
10
13
16
19
2
5
8
11
14
17
20

Actual behavior
18
3
15
6
12
9
1
16
13
10
7
4
19
11
8
14
5
17
2
20

The culprit seems to be the last two conditions in this branch: https://github.com/KirkMunro/PowerShell/blob/master/src/Microsoft.PowerShell.Commands.Utility/commands/utility/sort-object.cs#L247
            // If -Top & -Bottom were not used, or if -Top or -Bottom would return all objects, invoke
            // an in-place full sort
            if ((Top == 0 && Bottom == 0) || Top >= dataToProcess.Count || Bottom >= dataToProcess.Count)
            {
                sortedItemCount = FullSort(dataToProcess, comparer);
            }
            // Otherwise, use an indexed min-/max-heap to perform an in-place sort of all objects
            else
            {
                sortedItemCount = Heapify(dataToProcess, comparer);
            }

Suggested fix would be to either add a -Stable switch parameter that forces Sort-Object to use the stable min/max heap sort implementation, or change the branch above to only default to FullSort() when -Top/-Bottom are omitted completely.
My personal preference would be to go for both changes - -Stable would be nice for when you don't know input size up front but want to maintain input order for equal items
Environment data

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.0
PSEdition                      Core
GitCommitId                    6.1.0-57-g0f0c46dfe51440470b86f67b258e14aea32fa0aa
OS                             Microsoft Windows 10.0.17134
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

@KirkMunro LGTM!
Had originally solved this with a Stable parameter across all sets, but as mentioned above I like your approach better since it also means consistent behavior regardless of input size.


text:
Fix CategoryInfo.Activity so that it has the specified value

Fixes #846 CategoryInfo.Activity of Write-Error does not honor the value for
'activity' but uses the hard-coded string 'write-error'. The change sets
the value if specified by Write-Error cmdlet or set 'write-error'.

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

It looks like you're a Microsoft contributor (Aditya Patwardhan). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

authors: adityapatwardhan msftclas