SinglaR 2.0

I tried your client with SignalR 2.0 server that should support older protocol versions. It seems to work for some parts, but time to time I get and error saying: "The ConnectionId is in the incorrect format."
There is pretty good example of the error on Stackoverflow: http://stackoverflow.com/questions/18978904/signalr-server-error-the-connectionid-is-in-the-incorrect-format-with-signalr
Far as my investigation got me about the issue is that it has something to do with IPrincipal. See more here: https://github.com/SignalR/SignalR/issues/1589

this was resolved in the beta1 branch which is now in master


Batch the sequences with ContrastiveSeqBatchScheduler

This PR succeeds PR #2547 #2509 #2557, which contains the benchmark outputs of the searching results.
The traced models can be downloaded here: https://d2l-java-resources.s3.amazonaws.com/tmp_model_unittest/model/nlp/text_generation/ai/djl/pytorch/gpt2/metadata.json and https://d2l-java-resources.s3.amazonaws.com/tmp_model_unittest/gpt2_decoder_model_merged.onnx.gz
Design
Overview
These PRs consists of the following three parts: LMAdapter, LMSearch and SeqBatchScheduler. There are three testing code corresponding to them: TestLMAdapter.java, TestLMSearch.java, TestSeqBatchScheduler.java. The TestSeqBatchScheduler.java utilizes all previous features.
New classes
/*
This is a scheduler, serving as an API to the consumer of the systme, allowing for three major actions: initForward, addBatch, fastForward, collectResults. An optimal
control sequence should be solved, after taking into the time consumption of each action, the batch size and
sequence length of queueing requests.  Such optimal control solver needs additional effort. Primitive policy is
setting several thresholds.
*/
SeqBatchScheduler {

    LMAdapter lmAdapter;

    SeqBatcher seqBatcher;

    public SeqBatchScheduler(LMAdapter lmAdapter) {
        this.lmAdapter = lmAdapter;
    }

    public abstract SeqBatcher initForward(
            NDArray inputIds, NDArray batchUids, SearchConfig config);

    public void incrementForward(int count) {}

    public void addRequest(NDArray inputIds, NDArray batchUids, SearchConfig config) {}

    public ConcurrentHashMap<Long, NDArray> collectResults() {}
}

// This stores the search state (BatchList), the control variables (eg seqLength, offSets, etc), and batch operations on BatchList.
public class SeqBatcher {

    NDManager manager;

    long batchSize;

    long seqLength;

    NDArray batchUid;

    NDArray offSets;

    BatchList data;

    ConcurrentHashMap<Long, NDArray> finishedSequences;

    List<Pair<Long, Long>> exitIndexEndPosition;

    SeqBatcher(BatchList data, NDArray batchUid, NDArray offSets, NDManager manager) {}

    /** Add new batch. Modify the batch dimension and the left padding. */
    public void addBatch(SeqBatcher seqBatcherNew) {   }

    /** Merge two batchers together. Modify the batch dimension and the left padding. */
    private void merge(SeqBatcher seqBatcher1, SeqBatcher seqBatcher2, long seqDelta) {}

    /** Check which batch needs to exit, according certain criteria like EOS or maxLength. */
    public void exitCriteria(NDArray outputIds, long maxLength, long eosTokenId) {}

    /** Collect the finished sequences and trim the left padding. */
    public void collectAndTrim() { }
}

// BatchList is a struct consisting of NDArrays, whose first dimension is batch, and also contains
// sequence dimension (whose position in tensor's shape is specified by seqDimOrder)
// It represents a search state, and the NDArrays inside are updated in each iteration of the autoregressive loop.
// The batch operators in SeqBatcher will be applied on them.
public abstract class BatchList {

    // [batch, seq_past]. seq-dim-size == |past_seq| + |inputIds|. Will grow.
    public NDArray pastOutputIds;

    // [batch, seq_past]
    // The cache of past attentionMask. seq-dim-size == |past_seq| + |inputIds|. Will grow.
    public NDArray pastAttentionMask;

    // (k, v) * numLayer,
    // kv: [batch, heads, seq_past, kvfeature]
    // The cache of past sequence. seq-dim-size == |past_seq| + |inputIds|. Will grow.
    public NDList pastKeyValues;

    // Sequence dimension order among all dimensions for each element in the batch list.
    public long[] seqDimOrder;

    BatchList() {}

    BatchList(NDList list, long[] seqDimOrder) {}

    BatchList(
            NDArray pastOutputIds,
            NDArray pastAttentionMask,
            NDList pastKeyValues,
            long[] seqDimOrder) {}

    public abstract BatchList fromList(NDList inputList, long[] seqDimOrder);

    // The pastOutputIds has to be the first in the output list
    public abstract NDList getList();

    public long[] getSeqDimOrder() {
        return seqDimOrder;
    }
   }
}

This is partly adapted from the searching algorithms in TestLMSearch.java. Currently only the contrastiveSearch has been adapted. The greedySearch and beamSearch will be similarly implemented. On top of that, batching operations are implemented. The system is designed as following, which contains the batching operations like addRequest() and collectAdnTrim()

Features have been merged in https://github.com/deepjavalibrary/djl/pull/2637


no redirect after sign_in

Environment

Ruby 2.4.3
Rails 5.2.0beta2
Devise [version]

Current behavior
no redirect after sign_in

Expected behavior
redirect to after_sign_in_path (screenshot taken with the same environment except devise 4.3.0 instead of 4.4.0)

@TheScarfix Can you provide a sample app which reproduces this behavior?

@nynhex created a new application and it works as intended, any ideas how to find the error in my app?

Having the same issue as @TheScarfix - upgraded to 4.4.0 to use Ruby 2.5.0 and app no longer redirects after a login, stays on sign_in path even though the user is now signed in. Refreshing the page at this point redirects you correctly to the root_path.
It seems that in Devise::SessionsController#create, respond_with resource, location: after_sign_in_path_for(resource) does not honour location - I can put any url in location: and it never redirects there.
If I just apply the Ruby 2.5.0 fix #4668 to Devise 4.3.0 it works OK.
I'm using Devise inside an engine.
I regenerated the devise initialiser and the only differences are
  config.parent_controller = "ApplicationController"
  config.router_name = :<engine name>

Env: Rails 5.1.4 Ruby 2.5.0 Devise 4.4.0

@tegon
This feels a bit like changing the contract; as far as I'm aware, Devise never previously required the resource to be valid during authentication.

[...] but personally, I think that the user should be valid during the sign in process

If there was previously an implicit assumption that the resource would be valid, that has now been made explicit by the change to Trackable. Would it not be sensible to add this as a proper constraint, rather than leaving invalid users in the broken state of being a) authenticated but b) still being redirected to the sign in page?
In our application, we've now got:
  def active_for_authentication?
    invalid? ? false : super
  end

  def inactive_message
    invalid? ? :record_invalid : super
  end

...I wonder if something like this shouldn't be added to the default behaviour in lib/devise/models/authenticatable.rb ?

I agree with @joshpencheon that this feels like a substantial change to the contract of sign-in.
In an old product whose validation rules have changed over time, it's reasonable to have legacy users who were valid at signup but are now invalid. Before 4.4.0 these users could still sign in to fix their accounts!
If invalid users can't sign in, any new validation which accidentally impacts a portion of the existing userbase becomes a showstopper.

@joshpencheon @gmcnaughton This wasn't an implicit assumption, it worked before without any validations until we found a problem with this approach.
We could handle this inside Trackable with some conditional, that's why I asked what were the errors to have a better understanding of the situation. And it turns out that most of the errors were password-related. I think that even with custom validations this can be handled at the application code, but let me know if that's not the case with your app. We can reconsider it.

Thanks @tegon, I appreciate you taking the time! 😄
I'm concerned about two issues: legacy accounts and future changes.

Legacy accounts. Over time we've added or changed validations on User -- say, requiring a field or changing limits -- in order to get cleaner data from new users. But we haven't gone back to fix up legacy users. These technically-invalid users could still log in; when they tried to update their account they would be prompted to fix the values. Now, we need to manually fix up all of these users or they will be blocked from the site.

Future changes. Going forward, if we add or change a validation on User, we could accidentally block a portion of our users from signing in without realizing it.

@gmcnaughton They seem to be the same issue, actually. Do you have any examples of this?
At least in the projects I've worked, we usually had to fix up the base before introducing some new column that is required. If it's a column that we can leave it nil for some users, then a validation isn't needed.
Also, if your users are invalid I think you can have issues with other parts of Devise, such as password reset and email confirmation.

This is still broken!
https://stackoverflow.com/questions/48913707/devise-after-sign-in-path-for-not-working-being-ignored
Devise should not validate upon sign in! If you had some problem before, then you should validate when  REGISTERING/CREATING a user, but not when SIGNING IN / UPDATING a user. That renders validate ... on: :update completely useless! As it is, your TRACKABLE is broken now as it still creates a session but doesn't update last_sign_in_at, current_sign_in_ip, etc.
Consider using #update_attribute or #update_columns instead to set the last_sign_in_at fields et al. The key to those methods being "Validations are skipped".
I'm going to have to downgrade to 4.3.

Another quick fix could be to override sessions_controller#create and use #sign_in_and_redirect instead of the current code especially if you use this method for omniauth_controller. Otherwise you get 2 different behaviour on sign_in.
While that issue enforces to have a valid record on sign_in, it is a bit weird behaviour because as @starrychloe mentioned it does create a session and when you refresh you are redirected to the correct path instead of being stuck sign_in like when the session is created.
Side note: What made my record invalid is that for Rails 5 belongs_to is now a required association. Without
belongs_to :association, optional: true

Your record will be invalid and #after_sign_in_path_for will not redirect to the correct url. This just one of the millions possibilities that could make a resource invalid.

We already removed the validations on https://github.com/plataformatec/devise/pull/4796, I'll release a version soon.


Tests fixes

fixes for Comment, Organization and Event tests

No changes to .github acion scrpits required, this time.


Port alerts job to run on windmill

Port our earth sensing alerts job to run as a windmill script.
Gotchas will include:

[x] Google credentials file
[ ] Initial DB table setup

Initial DB table setup

this worked out of the box!


Gradle: Fix prev built module "leaking" files into subsequent build

Same as #119 but for jib-layer-filter-extension-gradle

@elefeint @chanseokoh
Is there any change to have release v0.2.1 in the near future?
As fas as I can see all changes between v0.2.0 and current master is minor refactoring, code style, documentation and my bug-fix. Diff: https://github.com/GoogleContainerTools/jib-extensions/compare/v0.2.0-jib-layer-filter-extension-maven...master

We will release next week.

jib-layer-filter-extension-gradle:v0.3.0 released.


[WebAPI] Fix lint error in webgl tests

Fix TRAILING WHITESPACE
sed -i 's/[ \t]*$//' /path/to/file
Fix INDENT TABS
sed -i 's/	/ /g' /path/to/file
Fix CR AT EOL
sed -i 's/\r/\n/g' /path/to/file

BUG=https://crosswalk-project.org/jira/browse/CTS-1692

@zqzhang , @Honry
Ptal, thanks a lot!

@zqzhang , @Honry
Ptal, thanks a lot!

Too many files changed in one PR to review, it's better to split it into two by test suite.

PTAL, thanks a lot~!

LGTM


Generated constructor strips all annotations for parameters

Will it be possible to read annotations on property methods and include annotations for constructor parameters? auto-value-moshi currently strips all annotations rendering IDE inspections unusable on them. The constructors generated by auto-value on the other hand include them as expected.

Can do


Roles granted via group membership

A role can be assigned to user via group membership. I believe this scenario should also be covered here as it works on client side

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f4c1641c-57ec-caae-5c2a-eafd8d882290
Version Independent ID: 9cc2a0dc-6509-7d16-4433-c6260c9a5bfa
Content: Sample: Determine whether a user has a role (Developer Guide for Dynamics 365 for Customer Engagement)
Content Source: ce/developer/sample-determine-user-role.md
Service: crm-online
GitHub Login: @JimDaly
Microsoft Alias: jdaly

Sample was moved here:
https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/org-service/samples/determine-whether-user-has-role
This sample does detect if a user has been literally assigned a role. But I understand you are saying it doesn't matter in terms of the actual privileges they may enjoy because group membership isn't taken into account.
@phecke
What we need is to have that content about detecting security privileges completed.
Whether a user is associated with a role isn't really important any more as a way to detected whether they have particular privileges.
This sample should be dropped in favor of the messages to detect privileges.
Let me know if you aren't clear about what I'm talking about.


adds support for type discriminator during deserialization

Summary
fixes #648
What I thought would be a rather short PR ended up being much larger than anticipated. The background story is that because of the type system in Go, I add to introduce interfaces generation support in Kiota CodeDOM. Which led to a whole bunch of refactoring so we don't have to duplicate things like import statements, refiners logic, writing methods prototypes etc...
Because of the TypeScript limitations on static methods, I also had to introduce global functions and do a bunch of refactoring.
This PR is adding new capabilities to the Kiota engine, which is overall a good thing for Kiota to support additional scenarios and languages. Apologies to the reviewers, this is going to be large.
Generation diff
https://github.com/microsoft/kiota-samples/pull/513
using this description (see outlook item)
https://github.com/microsoftgraph/msgraph-sdk-powershell/pull/1060
Global todo

[x] move the discriminator mappings property from code class to code method
[x] introduce a new factory method type
[x] add a common refiner to add usings for discriminator mappings
[x] add a common refiner to add usings for factory methods in request executors
[ ] update conceptual documentation
[ ] ping php and python teams to reflect the updates
[ ] update the ruby checklist to reflect the updates

CSharp todo

[ ] update parse node interface to take the new factories as parameters
[ ] update deserializer method gen to pass the factory for the properties
[ ] remove the new constraint on generic types for request adapter
[ ] add factory to request adapter as parameter
[ ] update request executor to pass the factory + update unit tests
[ ] bump abstractions, http and serialization packages
[ ] implement factory method generation + unit tests
[ ] remove the get object value that relies on new generic type constraint in parse node
[ ] rename the get error value method into get object value
[ ] use refiner method to add reference to types in discriminator mapping
[ ] implement using the factory + discriminator property name in getObjectValue

Go todo

[x] update parse node interface to take the new factories as parameters
[x] update deserializer method gen to pass the factory for the properties
[x] add factory to request adapter as parameter
[ ] update request executor to pass the factory + update unit tests
[ ] bump abstractions, http and serialization packages
[x] implement factory method generation + unit tests
[x] use refiner method to add reference to types in discriminator mapping
[x] implement using the factory + discriminator property name in getObjectValue

Java todo

[ ] update parse node interface to take the new factories as parameters
[ ] update deserializer method gen to pass the factory for the properties
[ ] add factory to request adapter as parameter
[ ] update request executor to pass the factory + update unit tests
[ ] bump abstractions, http and serialization packages
[ ] implement factory method generation + unit tests
[ ] use refiner method to add reference to types in discriminator mapping
[ ] implement using the factory + discriminator property name in getObjectValue

TypeScript todo

[x] update parse node interface to take the new factories as parameters
[x] update deserializer method gen to pass the factory for the properties
[x] add factory to request adapter as parameter
[x] update request executor to pass the factory + update unit tests
[ ] bump abstractions, http and serialization packages
[x] implement factory method generation (read the discriminator value from parse node, switch case) + unit tests
[x] use refiner method to add reference to types in discriminator mapping
[x] implement using the factory + discriminator property name in getObjectValue

running into an issue with Go where the type system for structs doesn't allow for up casting of structs (because it's composition over inheritance). Here is the roadmap to solve it:

interfaces for all the models with inheritance structure
all the models implement their respective interfaces
properties of objects/collection of objects are interfaces
the deserializer infers to parent interface
the client does a type inferance
put the interfaces in their dedicated package structures

running into an issue with Go where the type system for structs doesn't allow for up casting of structs (because it's composition over inheritance). Here is the roadmap to solve it:

interfaces for all the models with inheritance structure
all the models implement their respective interfaces
properties of objects/collection of objects are interfaces
the deserializer infers to parent interface
the client does a type inferance
put the interfaces in their dedicated package structures

Can you elaborate on  put the interfaces in their dedicated package structures ? How would that look ? Would this be some pattern that we apply for typescript when we use model interfaces?

@nikithauc I'm still working with @darrelmiller to understand how much this is a requirement. But the gist of it is that interfaces for models would be in a sub namespace like so

mainnamespace -> contains the api client and the request builders
mainnamespace.models -> contains the model classes
mainnamespace.interfaces -> contains the model interfaces

Of course the infrastructure I'm laying out would leave that as a choice for each language (whether or not we have interfaces in this language and where they are placed).
Hopefully this clarifies the ongoing work here.

From conversation with Vincent, decisions is that we put interfaces and classes all in the same models folders.
We should use interfaces for request payload and responses payload in chained API.

@darrelmiller just implemented the last changes we talked about
@nikithauc now both interfaces for models and models will be in the same namespace

@andrueastman this is ready for review, thanks for your help during the design time
@nikithauc @ramsessanchez @jobala if you have time to look at the languages you contribute to, it'd be greatly appreciated
@jasonjoh if you have time to look at the markdown modifications, it'd be appreciated as well.
I'm aiming to merge this this in by Friday so we can start testing that in Go/Dotnet/TS previews as the newer conversion lib releases.

From conversation with Vincent, decision is that we put interfaces and classes all in the same models folders. We should use interfaces for request payload and responses payload in chained API.

TS does not append an I- to the interfaces. In cases like that, how would the class names and interface names for the same model be conflict free?

If we fix the problem with circular dependency, will we still need the new CreateDiscriminator classes right?

@nikithauc

TS does not append an I- to the interfaces. In cases like that, how would the class names and interface names for the same model be conflict free?

This PR still adds most of the infrastructure needed for that change, the only missing piece would be to create the interfaces into a different namespace/package. (which I reverted after my convo with Darrel)

If we fix the problem with circular dependency, will we still need the new CreateDiscriminator classes right?

They are functions but yes, this part would still be needed after models classes inheritance is broken up and interfaces are introduced (like Go).


The code released is not completely

Thanks for your work, I find some code is missing, could you implement it.
in rgbd_monodepth.cc, SLAM.densemap_frame_enqueue() and SLAM.densemap_request_finish() are defined in System.h, but you didn't provide the orb-slam2 source code that you modified for us.  Thanks!

We use the ORBSLAM as the pose calculator and only a little modification of the interface.
It's not suitable for us to provide the orb-slam2 code due to the ORBSLAM own license.

Hi, could you at least provide the information what kind of function  densemap_frame_enqueue, densemap_request_finish is?
Thank you for consideration in advance!

Please refer densemap.cc for pointcloud-fusion code. And DepthPredictor.cc is used for manager pointcloud-fusion thread,  all you need will be found in this file.

Furthermore, dense_map is used for the fusion phase.


fix(pfTableView): Fixed sort col when show/hiding checkbox col

Description
Fixes #715
@akieling
Previously, the sort column was 'hard coded' regardless of whether the first checkbox column was shown or hidden:
Initial View:

After Turn Off Checkbox Column:

After Fix, sort column does not change:

Tested and Works with multiple column sorts as well.

PR Checklist

[ ] Unit tests are included
[X] Screenshots are attached (if there are visual changes in the UI)
[ ] A Designer (@beanh66) is assigned as a reviewer (if there are visual changes in the UI)
[ ] A CSS rep (@cshinn) is assigned as a reviewer (if there are visual changes in the UI)

LGTM: This looks great, and def solves the problem with the checkbox display on or off. If we move to a design of user customizable columns (whether it be shifting order or toggling view state) we may need to use a key to id a column instead of the column order.

If we move to a design of user customizable columns (whether it be shifting order or toggling view state) we may need to use a key to id a column instead of the column order.

Agree, that would be more flexible.  -thanks


feat: restrict versioning by days

Thanks for submitting a PR! Please check the boxes below:

[x] I have added information to docs/ if required so people know about the feature!
[x] I have filled in the "Changes" section below?
[x] I have filled in the "How did you test this code" section below?
[x] I have used a Conventional Commit title for this Pull Request

Changes
Adjusts limiting of version history to date rather than number of versions
How did you test this code?
Manually set limitation in code against https://pr-4433-deployment-54847-flagsmith.app.uffizzi.com/
Disabled links in audit log

Disabled versions in history

I guess it's good to have the code there, but in theory we should never need the logic to blank out the link from the audit log, because the audit log visibility is also restricted for non-enterprise plans.

Some issues I've found in testing:

Since I'm running this self hosted, I would have expected the plan next to 'Version History' to say 'Enterprise' here, like it does for Audit Logs.

The only time that the API will return versions older than the limit is when the current live version is older than the limit. We shouldn't really blur this out.

If we want to blur things out, I could perhaps return a field that states that there are older versions, but I don't think this is necessary. I think we should just let the API handle the restrictions here.

@matthewelwell this has been resolved

I briefly played around with this but wasn't able to set up a fully representative local environment to test looking at older audit log entries or version history - is there a quick way I could do that?

q for @matthewelwell

@rolodato resolved button colour in dark mode. I think we're good to go on this ?

I briefly played around with this but wasn't able to set up a fully representative local environment to test looking at older audit log entries or version history - is there a quick way I could do that?

q for @matthewelwell

Sorry @rolodato - I missed this one. The BE has now been merged if that's helpful. In order to manually change the limit though you'll need to directly edit the organisations_organisationsubscriptioninformationcache table in the database and set the relevant fields (which should be fairly self explanatory).
Note that if you're using an organisation on the scale up plan you will also need to set the VERSIONING_RELEASE_DATE environment variable in the API to a date in the past to work around the logic which grandfathers unlimited audit log history for existing scale up customers.


Remote sessions targeting Windows machines unexpectedly use ANSI character encoding for external programs

Note: It is debatable what console encoding should apply when remoting into a Window machine - the caller's or the target machine's - but (effectively) using ANSI encoding  - rather than the OEM code page, as is still the default on Windows - seems like the wrong choice.
Curiously, Windows PowerShell behaves this way too.
Steps to reproduce
Run on (PS Core) on Windows:

from an elevated session, to enable "loopback" remoting
make sure that the calling version is enabled for remoting

& {
  # Target the local machine.
  $htParams = @{ ('HostName', 'ComputerName')[$env:OS -eq 'Windows_NT'] = '.' }
  # On Windows, determine what edition / version to target remotely: use the caller's.
  if ($env:OS -eq 'Windows_NT') {
    $htParams['ConfigurationName'] = (('PowerShell.' + $PSVersionTable.PSVersion), 'microsoft.powershell')[$PSVersionTable.PSEdition -ne 'Core']
  }
  Invoke-Command @htParams { if ($env:OS -eq 'Windows_NT') { chcp } else { $env:LANG }; [Console]::InputEncoding.WebName; [Console]::OutputEncoding.WebName, $OutputEncoding.WebName }
}

Expected behavior
Active code page: 437
ibm437   # [Console]::InputEncoding.WebName
ibm437   # [Console]::OutputEncoding.WebName
utf-8       # $OutputEncoding

Actual behavior
Active code page: 437
windows-1252   # !! *ANSI* code page
Codepage - 0   # !! *0* - but in effect seems to behave like ANSI
utf-8

Environment data
PowerShell Core 7.2.0-preview.4

While the behaviour definitely isn't helpful the reason why this is the case is because your PSSession does not have a console/conhost.exe allocated to the process. When .NET goes to get the codepage GetConsoleCP (Input) and GetConsoleOutputCP (Output) both return 0 meaning an error occurred.
This value isn't checked at all and is just passed straight into [Text.Encoding]::GetEncoding where the docs state https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.getencoding?view=net-5.0#System_Text_Encoding_GetEncoding_System_Int32_

0 (zero), to use the default encoding.

The reason why running chcp.com returns the correct codepage is because the act of starting a spawning a new console process without an existing conhost will result in one being spawned automatically and it now has the correct value.
Try it out
Invoke-Command -ComputerName localhost -ScriptBlock {

    $getConsoleCP = {
        Add-Type -Namespace Kernel32 -Name NativeMethods -MemberDefinition @'
[DllImport("Kernel32.dll")]
public static extern uint GetConsoleCP();

[DllImport("Kernel32.dll")]
public static extern uint GetConsoleOutputCP();
'@

        [PSCustomObject]@{
            ConsoleCP = [Kernel32.NativeMethods]::GetConsoleCP()
            InputEncoding = [Console]::InputEncoding.WebName

            ConsoleOutputCP = [Kernel32.NativeMethods]::GetConsoleOutputCP()
            OutputEncoding = [Console]::OutputEncoding.WebName
        }
    }

    Write-Host "In PSSession"
    &$getConsoleCP | Format-Table

    Write-Host "In sub process"
    $encCommand = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($getConsoleCP.ToString()))
    powershell.exe -EncodedCommand $encCommand
}

Outputs
In PSSession

ConsoleCP InputEncoding ConsoleOutputCP OutputEncoding
--------- ------------- --------------- --------------
        0 Windows-1252                0 Windows-1252

In sub process

ConsoleCP InputEncoding ConsoleOutputCP OutputEncoding
--------- ------------- --------------- --------------
      437 IBM437                    437 IBM437

Now the question is what should be the correct behaviour, some of the options I can think off right now

.NET fixes their logic to fallback to the registry setting if the Win32 APIs return 0
PowerShell first checks if a console is present

If present then it acts like it does today
If not it could fallback to the registry

PowerShell could automatically allocate a new conhost whenever a native process is started and set the cp to 65001 (or fallback to the registry default)

If PowerShell spawns a console then any child processes it creates should use that same console/cp settings

For the latter it will have the same restrictions that exist today for a normal process session but it at least solves this problem.

Thanks, @jborean93, that's helpful background information.
I explicitly included the chcp call in order to force allocation of a console first, followed by querying [Console]::InputEncoding and [Console]::OutputEncoding.
The curious thing that the chcp calls assigns a value to [Console]::InputEncoding, it doesn't do so for [Console]::OutputEncoding
By contrast, in Windows PowerShell both values are set to the ANSI encoding, and even without running a console application first - does it always, automatically allocate a console?

As for what the correct behavior should be:

.NET should definitely fix their fallback behavior to fall back to the OEM code page, not the ANSI code page.

Separately, we should decide what makes more sense for PowerShell remoting: inherit the caller's code page, or defer to the targeted machine's code page?

If the latter case, 65001 (UTF-8) would certainly be convenient, but only appropriate if we officially we decide to make PowerShell Core sessions on Windows UTF-8 by default, as proposed in https://github.com/PowerShell/PowerShell/issues/14945#issuecomment-800503184; otherwise, the target machine's OEM code page should be used.

I explicitly included the chcp call in order to force allocation of a console first, followed by querying [Console]::InputEncoding and [Console]::OutputEncoding.

The conhost is created and tied to the lifetime of the chcp process. It won't persist beyond that life of that process and tie itself to your PSSession so that codepage will still be 0. So regardless of the order the fact that you called chcp won't affect (or at least I don't see how) the .NET Console encoding values of your PSSession itself. The same thing applies to any other console subprocess you spawn. For example I've got a blank PSSession open I can see it's running as wsmprovhost.exe with no conhost.exe attached.

I spawn powershell.exe with a lifetime time to keep it running and I can see it now has a console associated with it

When that ends I'm now back with just wsmprovhost.exe with the conhost.exe no longer there

The curious thing that the chcp calls assigns a value to [Console]::InputEncoding, but not to [Console]::OutputEncoding

This is what doesn't make sense to me, both InputEncoding and OutputEncoding depend on the Win32 APIs to get the values. They both should be returning 0 and thus set the encoding to the default encoding on the host. Even when I test that assumption I cannot replicate what you see (even when targeting PowerShell v7).

By contrast, in Windows PowerShell both values are set to the ANSI encoding, and even without running a console application first - does it always, automatically allocate a console? Or does it simply take an extra step to translate 0 into the default == ANSI code page?

I'm not 100% sure what you mean with Windows PowerShell here, the encoding values come from .NET and it's the behaviour of [Text.Encoding]::GetEncoding(0) to return the default encoding (whatever that actually is) which in this case is the "ANSI" encoding.

The conhost is created and tied to the lifetime of the chcp process. It won't persist beyond that life of that process and tie itself to your PSSession so that codepage will still be 0. So regardless of the order the fact that you called chcp won't affect (or at least I don't see how) the .NET Console encoding values of your PSSession itself.

Good to know, thanks. Yes, it is curious thing that (only) [Console]::InputEncoding is set after running chcp, but the fact that  reported code page differs from what chcp reports confirms your larger point that chcp's console is no longer active.

I'm not 100% sure what you mean with Windows PowerShell here

Run the same command from Windows PowerShell, which targets itself (configuration microsoft.powershell) as the endpoint, and you'll see the difference.
It may come down to the difference between .NET Framework (Windows PowerShell) and .NET (Core) 5+ (PowerShell Core).
The above applies to the Invoke-Command invocation scenario; when entering an interactive session with Enter-PSSession, I do consistently see both [Console]::InputEncoding  and [Console]::OutputEncoding  set to the ANSI encoding.
To simplify the Invoke-Command calls and show the difference (it doesn't make a difference what edition you call from):
# Target the current PS Core preview (I get the same behavior with 7.0.3)
PS> icm -cn . -config PowerShell.7.2.0-preview.4 { [console]::InputEncoding.CodePage; [console]::OutputEncoding.CodePage }
0
0

# Target WinPS
PS> icm -cn . -config microsoft.powershell { [console]::InputEncoding.CodePage; [console]::OutputEncoding.CodePage }
1252
1252

The above applies to the Invoke-Command invocation scenario; when entering an interactive session with Enter-PSSession, I do consistently see both [Console]::InputEncoding and [Console]::OutputEncoding set to the ANSI encoding.

Ah ok, I'm running with just Enter-PSSession, weird that there is a difference though, I wouldn't have thought it would matter.

I'm currently looking into how [Text.Encoding]::GetEncoding(0) returns windows-1252. The definition of this function for .NET Core is at https://github.com/dotnet/runtime/blob/99d6215ef2336b8fa51fe19b2e8e782df62959df/src/libraries/System.Private.CoreLib/src/System/Text/Encoding.cs#L215. Briefly browsing the logic is somewhat similar to .NET Framework but not exactly the same
It first checks if the encoding is in the registered provider (more on that later on) and then falls back to a hardcoded switch statement. In that statement 0 is set to be [Text.Encoding]::Default which in .NET Core is set to UTF-8 without a BOM. On .NET Framework the Default encoding it is dependent on GetACP.
So this explains why [Text.Encoding]::GetEncoding(0) returns windows-1252 on Windows PowerShell but not PowerShell (I would expect that to be utf-8). In .NET Core there has to be a registered encoding provider that supports 0 overriding the default behaviour of 0 being [Text.Encoding]::Default.
We can use reflection to test this out on PowerShell:
$encProvType = [AppDomain]::CurrentDomain.GetAssemblies().DefinedTypes | Where-Object {
    $_.FullName -eq 'System.Text.EncodingProvider'
} | Select -First 1

$getMeth = $encProvType.GetMethod('GetEncodingFromProvider', [Reflection.BindingFlags]'NonPublic, Static', $null, [Type[]]@([int]), $null)
$getMeth.Invoke($null, @(0))

Outputs
IsSingleByte      : True
EncodingName      : Western European (Windows)
WebName           : windows-1252
HeaderName        : windows-1252
BodyName          : iso-8859-1
Preamble          :
WindowsCodePage   :
IsBrowserDisplay  :
IsBrowserSave     :
IsMailNewsDisplay :
IsMailNewsSave    :
EncoderFallback   : System.Text.InternalEncoderBestFitFallback
DecoderFallback   : System.Text.InternalDecoderBestFitFallback
IsReadOnly        : True
CodePage          : 1252

So this explains why GetEncoding(0) returns windows-1252. When looking at the GetEncodingFromProvider method the logic is pretty simple; it looks through the registered providers (s_providers) and returns the first match it finds for the codepage.
We can also use reflection to get these registered providers
$encProvType = [AppDomain]::CurrentDomain.GetAssemblies().DefinedTypes | Where-Object {
    $_.FullName -eq 'System.Text.EncodingProvider'
} | Select -First 1

$sProvidersField = $encProvType.GetField('s_providers', [Reflection.BindingFlags]'NonPublic, Static')
$providers = [Text.EncodingProvider[]]$sProvidersField.GetValue($null)

$providers | % GetType

Outputs
IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    CodePagesEncodingProvider                System.Text.EncodingProvider

The docs for the CodePagesEncodingProvider state it

Provides access to an encoding provider for code pages that otherwise are available only in the desktop .NET Framework.

Looking at the PowerShell codebase it looks like it is being registered there https://github.com/PowerShell/PowerShell/blob/3ba61069b8e8d027dbbe11f69a85c871359291f9/src/System.Management.Automation/utils/ClrFacade.cs#L143-L149. I just don't have much of an idea of what the purpose of this particular code is for. It looks like some sort of shim to implement some .NET Framework behaviour that is missing in .NET Core. This could even be a red herring and not at all related to the problem but I thought it interesting enough to share.

Alas I have no idea why Invoke-Command differs from Enter-PSSession here, they both don't have a console associated with the remote process so the raw Win32 values make sense but I don't know why PowerShell returns 0 (I'm seeing it on OutputEncoding on my host)
$getConsoleCP = {
    param ([string]$Scenario, [bool]$RunChcp)

    if ($RunChcp) {
        chcp.com
    }

    Add-Type -Namespace Kernel32 -Name NativeMethods -MemberDefinition @'
[DllImport("Kernel32.dll")]
public static extern uint GetConsoleCP();

[DllImport("Kernel32.dll")]
public static extern uint GetConsoleOutputCP();
'@

    $inputEncoding = [Console]::InputEncoding
    $outputEncoding = [Console]::OutputEncoding

    [PSCustomObject]@{
        Scenario = $Scenario
        ConsoleCP = [Kernel32.NativeMethods]::GetConsoleCP()
        InputEncodingCP = $inputEncoding.CodePage
        InputEncoding = $inputEncoding.WebName

        ConsoleOutputCP = [Kernel32.NativeMethods]::GetConsoleOutputCP()
        OutputEncodingCP = $outputEncoding.CodePage
        OutputEncoding = $outputEncoding.WebName
    }
}

Invoke-Command localhost -ScriptBlock $getConsoleCP -ArgumentList 'WinPS', $false

Invoke-Command localhost -ScriptBlock $getConsoleCP -ArgumentList 'WinPS + proc', $true

Invoke-Command localhost -ConfigurationName PowerShell.7 -ScriptBlock $getConsoleCP -ArgumentList 'PS', $false

Invoke-Command localhost -ConfigurationName PowerShell.7 -ScriptBlock $getConsoleCP -ArgumentList 'PS + proc', $true

Scenario         : WinPS
ConsoleCP        : 0
InputEncodingCP  : 1252
InputEncoding    : Windows-1252
ConsoleOutputCP  : 0
OutputEncodingCP : 1252
OutputEncoding   : Windows-1252

Scenario         : WinPS + proc
ConsoleCP        : 0
InputEncodingCP  : 1252
InputEncoding    : Windows-1252
ConsoleOutputCP  : 0
OutputEncodingCP : 1252
OutputEncoding   : Windows-1252

Scenario         : PS
ConsoleCP        : 0
InputEncodingCP  : 1252
InputEncoding    : windows-1252
ConsoleOutputCP  : 0
OutputEncodingCP : 1252
OutputEncoding   : windows-1252

Scenario         : PS + proc
ConsoleCP        : 0
InputEncodingCP  : 1252
InputEncoding    : windows-1252
ConsoleOutputCP  : 0
OutputEncodingCP : 0
OutputEncoding   : Codepage - 0

WinPS is consistent and makes sense because it's really just using [Text.Encoding]::Default when the cp returned by the Win32 API is 0. Pwsh is interesting as it uses the registered CodePagesEncodingProvider to get the "ANSI" codepage but when a console process had run that provider seems to be a bit screwed up and only for [Console]::OutputEncoding.
Maybe PSReadLine or some other mechanism is setting [Console]::OutputEncoding = $someBackupValue after the native process had exited and $someBackupValue was derived in some other way from 0.

As for what the correct behavior should be:

.NET should definitely fix their fallback behavior to fall back to the OEM code page, not the ANSI code page.

Is there an issue for reference?

Separately, we should decide what makes more sense for PowerShell remoting: inherit the caller's code page, or defer to the targeted machine's code page?

If the latter case, 65001 (UTF-8) would certainly be convenient, but only appropriate if we officially we decide to make PowerShell Core sessions on Windows UTF-8 by default, as proposed in #14945 (comment); otherwise, the target machine's OEM code page should be used.

Of course, I would like to avoid a situation when we receive a message from a remote host in a different language and in wrong double re-encoding.
If we connect to WinPS we should follow old behavior.
If we connect to new PowerShell Core it is best to be Utf8 (maybe excluding old Windows) as it will cause fewer side effects and reflects the modern trend, and it would nice to have a parameter to set explicitly encoding to address specific scenarios.

This is all happening on the remote side,

I say about another - if our local session has English  locale and remote one - Russian, then we see follow:
 Invoke-Command -ComputerName titlin -ScriptBlock { ping localhost }

ЋЎ¬Ґ Ї ЄҐв ¬Ё б testhost [::1] б 32 Ў ©в ¬Ё ¤ ле:
ЋвўҐв ®в ::1: ўаҐ¬п<1¬б
ЋвўҐв ®в ::1: ўаҐ¬п<1¬б
ЋвўҐв ®в ::1: ўаҐ¬п<1¬б
ЋвўҐв ®в ::1: ўаҐ¬п<1¬б

‘в вЁбвЁЄ  Ping ¤«п ::1:
    Џ ЄҐв®ў: ®вЇа ў«Ґ® = 4, Ї®«гзҐ® = 4, Ї®вҐап® = 0
    (0% Ї®вҐам)
ЏаЁЎ«Ё§ЁвҐ«м®Ґ ўаҐ¬п ЇаЁҐ¬ -ЇҐаҐ¤ зЁ ў ¬б:
    ЊЁЁ¬ «м®Ґ = 0¬бҐЄ, Њ ЄбЁ¬ «м®Ґ = 0 ¬бҐЄ, ‘аҐ¤ҐҐ = 0 ¬бҐЄ

Expected:
Обмен пакетами с testhost [::1] с 32 байтами данных:
Ответ от ::1: время<1мс
Ответ от ::1: время<1мс
Ответ от ::1: время<1мс
Ответ от ::1: время<1мс

Статистика Ping для ::1:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
ping.exe exited on titlin with error code 0.

Great sleuthing, @jborean93.
@iSazonov, re:

Is there an issue for reference?

I couldn't find anything (except an ancient issue, which shows that at some point the default with an allocated console was UTF-8(!) - https://github.com/dotnet/runtime/issues/17849).
When accessing  Console.In/OutputEncoding without a console present:

It is only .NET Framework (not .NET Core) that falls back to ANSI (which is definitely not appropriate - but I doubt they'll fix that).

.NET Core now returns an encoding object with code page 0  and web name Codepage - 0- I don't know if that's by design or a bug, but it certainly isn't helpful.

By contrast, if you call Encoding.GetEncoding(0) explicitly, you get UTF-8, which is consistent with Encoding.Default in .NET Core - which makes sense, given that this call in isolation isn't console-related.
As @jborean93 has found out, with the Windows code-page encoding provider registered, which apparently happens automatically when a console is attached (in a console application), it preempts the default meaning of 0 and returns the system's ANSI code page instead.

@jborean93, the explanation for the discrepancy between Invoke-Command and Enter-PSSession is therefore as follows:
Invoke-Command doesn't call [System.Text.Encoding]::RegisterProvider([System.Text.CodePagesEncodingProvider]::Instance), whereas Enter-PSSession does:
If register the code-page encoding provider explicitly, you get the same symptom as with Enter-PSSession:
# !! Without the `[System.Text.Encoding]::RegisterProvider([System.Text.CodePagesEncodingProvider]::Instance)`
# !! call, the output is (0, 0)
PS>  icm -cn . -config PowerShell.7.2.0-preview.4 { [System.Text.Encoding]::RegisterProvider([System.Text.CodePagesEncodingProvider]::Instance); [console]::InputEncoding.CodePage; [console]::OutputEncoding.CodePage }
1252
1252

Curiously, running any console application in lieu of registering the code-page provider manages to make Console.InputEncoding - only - reflect the system's ANSI code page:
PS>  icm -cn . -config PowerShell.7.2.0-preview.4 {
  cmd /c exit
  [console]::InputEncoding.CodePage; [console]::OutputEncoding.CodePage
}
1252 # Console.InputEncoding
0    # Console.OutputEncoding

What it seems to come down is that calling the underlying WinAPI functions at least once  - even though they themselves keep returning 0(!) - then makes Console.In/OutputEncoding return the system's active ANSI code page:
PS>  icm -cn . -config PowerShell.7.2.0-preview.4 {
  Add-Type -Namespace Util -Name WinApi -MemberDefinition '[DllImport("Kernel32.dll")] public static extern uint GetConsoleCP(); [DllImport("Kernel32.dll")] public static extern uint GetConsoleOutputCP();';
  [Util.WinAPI]::GetConsoleCP(); [Util.WinAPI]::GetConsoleOutputCP()
  [console]::InputEncoding.CodePage; [console]::OutputEncoding.CodePage
}
0    # GetConsoleCP()
0    # GetConsoleOutputCP()
1252 # Console.InputEncoding
1252 # Console.OutputEncoding

As for what PowerShell should do:
It seems like the caller's settings should determine the behavior:

In terms of culture ([cultureinfo]::CurrentCulture / $PSCulture), the caller's settings already apply, irrespective of the target-machine settings.

It therefore also makes sense to use the caller's console encoding.

However, that is problematic in cross-platform remoting:

Windows -> Unix: The Windows code page may not even be available on the target machine.
Unix -> Windows: This would (most likely) make the console use UTF-8

Generally, agreeing on UTF-8 as the "lingua franca" would make the most sense - certainly more than the current Windows behavior of using the ANSI code page.

@dhowett Have you any thoughts?

. I just don't have much of an idea of what the purpose of this particular code is for. It looks like some sort of shim to implement some .NET Framework behaviour that is missing in .NET Core. This could even be a red herring and not at all related to the problem but I thought it interesting enough to share.

Before we added the "Encoding.RegisterProvider(CodePagesEncodingProvider.Instance); " users could not use OEM and ANSII encoding names in cmdlets (Get-Content -Encoding windows-1251)

Invoke-Command doesn't call [System.Text.Encoding]::RegisterProvider([System.Text.CodePagesEncodingProvider]::Instance), whereas Enter-PSSession does:

If I understand right  Invoke-Command should follow Enter-PSSession behavior and both should have correct default that should be rather Utf8 then OEM in modern Windows 10 (I would not worry about old Windows 7). And we need a fix in Console class (no workaround could be in PowerShell itself?). Yes?

users could not use OEM and ANSII encoding names in cmdlets (Get-Content -Encoding windows-1251)

Indeed; [System.Text.Encoding]::RegisterProvider([System.Text.CodePagesEncodingProvider]::Instance) is the prerequisite for access to all codings based on Windows code pages, notably including the active OEM and ANSI code pages; that is, without registering the provider, something like Encoding.GetEncoding(437) (the OEM code page used in the en-US culture, for instance) wouldn't work.

both should have correct default that should be rather Utf8 then OEM in modern Windows 10

Agreed, but to that end we should also commit to making  regular, local console windows default to UTF-8 - which is long overdue - as originally proposed in  #7233 and fleshed out in https://github.com/PowerShell/PowerShell/issues/14945#issuecomment-800503184
The only thing that could break is calls to very old CLIs that cannot handle code page 65001 (UTF-8) and its variable-length encoding aspect - but my guess is that such CLIs are pretty rare these days.

And we need a fix in Console class (no workaround could be in PowerShell itself?). Yes?

No, if the intent is to do "our own thing" with unconditional use of UTF-8, I don't think we need a fix in Console (as debatable as code page 0 in the absence of the Windows code-page encoding provider is, and as debatable as use of the ANSI code page is in its presence, but that's a separate issue).
Instead, we should do what @jborean93 has mentioned as an option above:

Allocate a console on entering the remote session and set its encoding to UTF-8, and which is kept around for the lifetime of the session for all console applications (if any) to run in.

I think doing so on entering  rather than on demand is preferable, so that someone executing [Console]::OutputEncoding, for instance,  before calling a console application in the session gets the correct information.

Agreed, but to that end we should also commit to making regular, local console windows default to UTF-8 - which is long overdue - as originally proposed in #7233 and fleshed out in #14945 (comment)
The only thing that could break is calls to very old CLIs that cannot handle code page 65001 (UTF-8) and its variable-length encoding aspect - but my guess is that such CLIs are pretty rare these days.

Yeah, hello Oracle! :-))) I guess there are a lot of old business applications using OEM encoding.
When I looked at this earlier I was thinking about the Native cmdlet concept to be able to annotate native applications accurately and personally.

Even if there is an older legacy API the caller can still set [Console]::OutputEncoding to something else to change the code page.

@iSazonov, note that use of OEM encoding per se isn't the problem, as long as:

programs do not use a fixed OEM encoding and instead - as they should - respect the console's encoding (code page), which defaults to system's OEM code page, as determined by the legacy system locale, aka "Language for non-Unicode programs), such as 437 on US systems.

and such programs know how to handle  the case when the console code page happens to be 65001, i.e. UTF-8 (older programs may not be able to deal with the variable-length encoding aspect of UTF-8 (1-4 bytes per character)).

In short: If we switch PowerShell consoles from the system's OEM code page to 65001 == UTF-8, only the following cases will amount to a breaking change:

Legacy programs that use a fixed OEM code page (other than 65001).
Legacy program that respect the console's code page but cannot handle UTF-8.

For "rogue" programs that do their own thing (e.g., Node.js, Python, sfc.exe - though note that Python can be configured to use UTF-8), the temporarily-setting-Console]::OutputEncoding workaround is already necessary.

Remoting working group:  The issues was filed with a description of a behavioral difference with no description of why the desired behavior is needed, what the scenario would be.  We understand that ideally this would be something else, but it is not clear from the issue what the behavior should be.

It's simply someone opens up a remote PSSession and runs an external command that returns non-ASCII characters. Doing so will mean the string is incorrect when it is read by PowerShell because of the codepage difference. Not sure why you would close the issue as this is behaviour in PowerShell that should be corrected.

Very simple reproducer that shows when a native application writes non-ASCII characters the values are screwed up, é becomes ‚ due to the encoding mismatch.

If PowerShell was to run AllocConsole when it starts up when there is no console present we can see the correct behaviour returns back to us

You don't even need to change the codepage to utf-8 by default, although I would recommend doing that as a follow up PR due to other reasons as stated in https://github.com/PowerShell/PowerShell/issues/14945.

@TravisEz13, /cc @SteveL-MSFT:

The issues was filed with a description of a behavioral difference with no description of why the desired behavior is needed

A reasonable expectation to have of a working group is a deep understanding of the issues involved, so that not every detail needs to be spelled out; thankfully, @jborean93 has since done so, leaving no doubt that things are broken.

it is not clear from the issue what the behavior should be.

See my previous point.

seems like the only clear issue is on .NET

No, that issue is incidental, as explained above.

you can work around this by setting up the remote console how you want it to be.

No, you can't, and it should have been obvious from the previous comments that you cannot (leaving impractical solutions involving ad-hoc compiled C# code that calls the Windows API to allocate a console aside).
In short: The working group's cursory and dismissive response is deeply concerning; it is something I first got a taste of in https://github.com/PowerShell/PowerShell/issues/11698, but Steve assured me that the experience wasn't representative of what working groups would bring to the table.
Certainly, this experience leaves me unconvinced.

The trouble with the 2nd point and identifying the codepage that the subprocess will use is a reason why I think PowerShell itself should just spawn it's own console when it starts (or when the first process is spawned). The first option also has the added benefit of allowing PowerShell to set the codepage to UTF-8 in the future in case that's something to be desired.

Is it always permissible to create a console? Are there any unwanted side effects?

A reasonable expectation to have of a working group is a deep understanding of the issues involved, so that not every detail needs to be spelled out; thankfully, @jborean93 has since done so, leaving no doubt that things are broken.

It's reasonable to have issue filed with the required information which include what you are trying to accomplish.  Issues without that information, are NOT issues at all but merely discussions and not actionable by the working group.  The primary action of the working group is to prioritize an issue.  An issue without a scenario has no priority and in an area as complex as remoting, I don't believe we (Including the community) should fix any issue like that.

In reply to

The working group's cursory and dismissive response is deeply concerning

and

It's simply someone opens up a remote PSSession and runs an external command that returns non-ASCII characters. Doing so will mean the string is incorrect when it is read by PowerShell because of the codepage difference. Not sure why you would close the issue as this is behaviour in PowerShell that should be corrected.

This was not put in the issue description.  This type of information should be included in the issue description to help the working group understand the impact of the issue.  If it is discovered later, please update the initial issue.

@TravisEz13

While the full picture only emerged in the course of the discussion, it should be obvious that the behavior is broken, so the answer to "what are you trying to accomplish" is: fix broken behavior.

Perhaps we need clarity on the duties of working groups; here's what I think they should not do: Close issues:

without having taken the time to understand the issue at hand.
based on arguments that do not apply ("you can work around this by setting up the remote console how you want it to be")

If the problem isn't fully understood yet and / or you don't want to spend the time gleaning it from the discussion, ask for clarification or an update (as you now have), or even ask for a new, focused proposal / bug report to be created.

I can appreciate the problem of not wanting to wade through a lengthy discussion, but to dismiss it summarily without even having understood the problem at hand is the disconcerting part.

If working groups routinely behave the way they did in this case, we've made no progress: it is reminiscent of similar committee decisions, where - understandable - a stretched-way-too-thin, small group of individuals had to make all the decisions. My hope was that working groups would address that very problem: subject-matter experts that have the time to engage in relevant discussions (which, again,  doesn't preclude asking for a tl;dr first).

In other words:

Yes, this is an ongoing discussion.
It even led to a concrete, focused proposal for how to fix the issue.
No one asked for the discussion to end yet, if there's no consensus yet or if the issue must be further clarified.

This was not put in the issue description.

Is it really official policy that the only thing working groups are required to read is the issue description?
I generally try to keep the initial post updated, but in an ongoing discussion that's not always practical.
My understanding - and hope - is that working groups are meant to work with the community rather than handing down 2-minute-deliberation fiat decisions.
By contrast, if the intent is indeed to have working groups only come in once a discussion has settled down and a focused proposal has been made, we need a different process: currently, issue are tagged for the relevant workgroup shortly after creation, so there's no control over the stage of the discussion at which the working group comes in.

@iSazonov

Is it always permissible to create a console? Are there any unwanted side effects?

As far as I know, always creating a console should be fine, and I'm not aware of any side effects, but perhaps @jborean93 has further insights.

Will this be enough to solve this problem, or is something else absolutely necessary?

Yes, allocating a console at the start of the session should be enough to solve the problem:

Even without switching to UTF-8, it restores expected console behavior - albeit based on the target machine's active OEM code page when targeting a Windows machine.

That said, I fully agree with @jborean93 that defaulting PowerShell consoles to UTF-8 is the right thing to do.

Once a console is available, [Console]::OutputEncoding can be set (temporarily) as usual in order to handle nonstandard encoding behavior, such as the always-UTF-8 output from Node.js applications.

Here's an example that emulates the proposed fix, similar to @jborean93's example:
# Target a Windows machine.
# E.g., from that machine itself, from an ELEVATED session:
PSELEV> Invoke-Command -cn . {
  # Allocate a console for the lifetime of this session. THIS IS WHAT POWERSHELL SHOULD DO AUTOMATICALLY.
  $null = (Add-Type -Name Aux -Namespace WinApi -Passthru -MemberDefinition '[DllImport("kernel32.dll")] public static extern bool AllocConsole();')::AllocConsole()
  # Now you can set [Console]::OutputEncoding to control how external-program output is decoded:
  # E.g., Node.js always output UTF-8
  # !! Without a console, this assignment would FAIL.
  [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()
  # Now Node.js output is captured correctly.
  ($output = node -pe "'eé'")
}

eé  # OK

Note that in the "loopback" remoting scenario you actually do see the allocated console actually becomes visible, in mangled form - I haven't looked into how to prevent that.

Is it always permissible to create a console? Are there any unwanted side effects?

As far as I know, always creating a console should be fine, and I'm not aware of any side effects, but perhaps @jborean93 has further insights.

I'd want to get confirmation from @TravisEz13 that we do not fall in a security issue here.  (I vaguely remember an old story with shadow window for system account  on Windows)

Do we want to fix both scenario - Enter-PSSession and Invoke-Command?

Absolutely - calling console applications should be supported in both scenarios.

@mklement0 We have an open PR in RFC repo for WG - please move your feedback to the PR.

@mklement0 After we get a confirmation for my question https://github.com/PowerShell/PowerShell/issues/15128#issuecomment-816373098 I suggest you to open new issue with clean and short description (with references to posts in that issue) and proposed solution. Thanks you and @jborean93 for great discussion!

Thanks, @iSazonov.
As for the security question: note that consoles already are being created if you call console applications, namely transient ones, on a per-call basis - but with misinterpreted-by-PowerShell output, and with no way to fix that (except via the WinAPi call shown above).

note that consoles already are being created if you call console applications

The consoles are created by OS for subprocesses. My question is about root WinRM process.

This can have a side effect #15229

This can have a side effect #15229

In this cases these 2 issues are unrelated and is no indication that allocating a console for WSMan is going to be a problem. For WSMan the PSRP exchanges occur on the WSMan transport (see SOAP/HTTP exchange) which is totally unrelated to the console stdio pipes. In the case of SSH there is already a console allocated which is fine but the problem is that the existing stdio referenced in PowerShell is now the sharing the same pipe as what PowerShell is using to exchange the PSRP messages. So by writing to stdout you are sending a message back to the client which isn't a correct PSRP packet causing a failure. For WSMan by writing to the allocated console nothing happens, it's just written to the conhost buffer that was allocated and not seen anywhere which is exactly what happens today with no console being there.

wg-remoting
@mklement0  It looks like this has evolved over time through this discussion, and I am confused as to the final problem.  It is not clear to me if there is an issue in PowerShell Core or PowerShell Windows or both.  Can you please update this issue (at the beginning and including issue title) for clarity and provide a summary of the problem including scenario based repro?
To clarify, I realize that remoting session does not set the console encoding, but I am unclear of a scenario where this causes a problem.

@PaulHigin I can't update the title but essentially it's a problem in both WinPS and PSCore, the end result just might be different even if they are still both wrong.
Essentially for WSMan based remoting sessions there is no conhost.exe assigned to the process so when PowerShell goes to determine the encoding that is used to encode the bytes received from a native app invocation it will most likely use the wrong encoding. The reason why it will most likely be the wrong encoding is because:

The native application is spawned with a new console (there's no console on the ps process to inherit from) and the default output encoding is most likely to be the console codepage

The only exceptions to this rule are things like python, node which don't respect the console codepage settings and use their own logic
python, node, and others are still a problem but unrelated to this particular issue

When PowerShell reads the raw bytes on that native apps stdout pipe it essentially uses [Console]::OutputEncoding

This may in fact be logic in .NET but the logic is still the same

[Console]::OutputEncoding somewhat "fails" because the remote PowerShell session does not have an actual console associated with it

It doesn't actually throw an exception but fails because there is no console in the ps session to get the output encoding values for
The underlying Win32 API will return a codepage of 0 in this case
This typically corresponds to the "ANSI" codepage which is not the same as the console codepage
This behaviour might be an issue but it would be up to dotnet to decide if they want to change that behaviour
Even if they do I don't see a nice way to solve it as there is some complex logic that decides what the console codepage will be

Because the output is decoded using the "ANSI" codepage but the native app encoded it using the console codepage we get the wrong string value in PowerShell

To test this out you can run the following on either WinPS or PSCore.
$cmd = {
    [Console]::Out.WriteLine('café')
}
$encCommand = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($cmd.ToString()))

# This works because [Console]::OutputEncoding is set for a normal process
powershell.exe -EncodedCommand $encCommand

# This doesn't work because the remote process started by the WSMan plugin doesn't have a console process
'Microsoft.PowerShell', 'PowerShell.7' | ForEach-Object -Process {
    $session = New-PSSession -ComputerName localhost -ConfigurationName $_
    try {
        Write-Host "The output with Invoke-Command PSSession $_"
        Invoke-Command $session -ScriptBlock {
            powershell.exe -EncodedCommand $using:encCommand
        }

    }
    finally {
        $session | Remove-PSSession
    }
}

For me this outputs caf‚ because PowerShell will output café using the 437 codepage (0x63 0x61 0x66 0x82) but PowerShell is reading it using my "ANSI" codepage (windows-1252); 0x82 in windows-1252 is ‚. Note the string iterpretation happens on the remote side so this isn't a CLIXML serialization over PSRemoting but how PowerShell itself decodes bytes from a native app if there is no console associated with the PowerShell process.
My proposed fix for this in PowerShell is to always ensure that a console is associated with the process so that [Console]::OutputEncoding actually has a correct value just like it does for a native app. I'm sure there are some edge cases that need to be tested but as per https://github.com/PowerShell/PowerShell/issues/15128#issuecomment-815282724 it does fix the issue.

Thank you, @jborean93, for succinctly summarizing the issue.
Re:

When PowerShell reads the raw bytes on that native apps stdout pipe it essentially uses [Console]::OutputEncoding

This may in fact be logic in .NET but the logic is still the same

It is actually PowerShell's decision (see #10824), albeit a sensible one.
Two asides:

The behavior deserves documenting, as suggested in the proposed about_Native_Calls conceptual help topic - see https://github.com/MicrosoftDocs/PowerShell-Docs/issues/5152

Defaulting all console contexts to UTF-8 is called for: see https://github.com/PowerShell/PowerShell/issues/14945#issuecomment-800503184

@PaulHigin, if you'll excuse the mixed metaphor, I'm personally tired of shouting at windmills, so I'm unsubscribing from this thread.
I'll leave any follow-up in the capable hands of @jborean93, who - I hope - has the stamina to keep going.

@jborean93  Thanks for the clarification.
I feel the title for this issue should be:
WinRM remote sessions do not set Console code page to that of client, affecting remote native command execution
@TravisEz13 I don't have permissions to update the Issue title, can you do it?
I feel a better repro scenario would be something like:
# Create WinRM session from client with non-default codepage
# Run script executing native command in remote session

Expected Results:
"text"

Actual Results:
"garbled text"

@jborean93, @mklement0
The first thing the working group does is triage the issue, and this means understanding the issue and trying to determine user impact for prioritization.  So it is critical to have this information at the very beginning and be as clear and concise as possible.  Discussion, and proposed solutions are very welcome but only after the issue is clearly defined.   In this case the issue was more like a discussion but without any clear conclusion summary.  This is why guidelines require a specific format ... to help working groups quickly understand impact and triage issues.  In hindsight, I feel this should have started as a discussion, eventually culminating into an Issue once the problem was fully understood.

I feel the title for this issue should be: WinRM remote sessions do not set Console code page to that of client, affecting remote native command execution

@PaulHigin that is not the problem here, strings returned from a remote session are serialized in CLIXML using utf-8 and aren't a problem here. The remote session also does not need to match with the console code page of the client, in fact you don't want that as it will exacerbate the problem in case they do mismatch.
The issue is the WinRM remote session doesn't have a console associated with it so the [Console]::OutputEncoding value isn't correct. This causes the problem where any spawned console processes will use the actual console codepage but PowerShell is using a different encoding when getting the output causing the mismatch values for non-ASCII characters.

I feel a better repro scenario would be something like:

If you really think so, personally I don't as you can't see what script can actually replicate this problem, at least with mine it showed you the problem exists on both WinPS and PSCore and how to replicate this exact problem.

@jborean93  Thanks again for the clarification.  What I am looking for is real world impact of a lack of correct console code page in a remote session.  Why would anyone use console write APIs in a remote script?  If you can provide a real world example that will help us assess impact.  But at this point it seems to be a low impact issue.  Sorry if I am missing something obvious.

What I am looking for is real world impact of a lack of correct console code page in a remote session

The impact is whenever a native application outputs a non-ASCII characters (0-127), there's a very high chance that because of the encoding mismatch the string stored in PowerShell is not the same as the one the native application outputted.

Why would anyone use console write APIs in a remote script?

They wouldn't, or if they do PowerShell won't capture it in any scenario (even locally) because it bypasses the stdout pipe and writes directly to the screen buffer. On the remote side this screen buffer is not the local one so it is lost to the world, locally this bypasses the PowerShell stdout capturing and the console codepage doesn't apply. This is unrelated to the problem and not something that PowerShell can really fix unless it starts delving into the ConPTY stuff that WT uses.

If you can provide a real world example, that will help us assess impact.

It's hard to as for myself personally I rarely deal with non-ASCII characters, most of my tools is based on en-US and these diacritics isn't very common to encounter in native tools. Essentially any native app that outputs a non-ASCII character will most likely be affected.
One other example where this is probably even more problematic is the tree command someone might be doing to get a snapshot of what a directory looks like:
# Run on a WSMan remote PSSession
> tree 'C:\Program Files\WindowsPowerShell\Modules'

Folder PATH listing for volume Windows 2019
Volume serial number is 08B0-E145
C:\PROGRAM FILES\WINDOWSPOWERSHELL\MODULES
ÃÄÄÄImpliedReflection
³   ÀÄÄÄ0.2.1
³       ÀÄÄÄen-US
ÃÄÄÄMicrosoft.PowerShell.Operation.Validation
³   ÀÄÄÄ1.0.1
³       ÃÄÄÄDiagnostics
³       ³   ÃÄÄÄComprehensive
³       ³   ÀÄÄÄSimple
³       ÀÄÄÄTest
³           ÀÄÄÄModules
³               ÃÄÄÄExample1.Diagnostics
³               ³   ÀÄÄÄDiagnostics
³               ³       ÀÄÄÄSimple
³               ÃÄÄÄExample2.Diagnostics
³               ³   ÀÄÄÄ1.0.1
³               ³       ÀÄÄÄDiagnostics
³               ³           ÀÄÄÄSimple
³               ÀÄÄÄExample3.Diagnostics
³                   ÃÄÄÄ1.1.1
³                   ³   ÀÄÄÄDiagnostics
³                   ³       ÀÄÄÄSimple
³                   ÀÄÄÄ2.0.1
³                       ÀÄÄÄDiagnostics
³                           ÀÄÄÄSimple
ÃÄÄÄPackageManagement
³   ÀÄÄÄ<IP_ADDRESS>
³       ÃÄÄÄDSCResources
³       ³   ÃÄÄÄen-US
³       ³   ÃÄÄÄMSFT_PackageManagement
³       ³   ³   ÀÄÄÄen-US
³       ³   ÀÄÄÄMSFT_PackageManagementSource
³       ³       ÀÄÄÄen-US
³       ÀÄÄÄen
ÃÄÄÄPackerWindoze
ÃÄÄÄPester
³   ÀÄÄÄ5.1.1
³       ÃÄÄÄbin
³       ³   ÃÄÄÄnet452
³       ³   ÀÄÄÄnetstandard2.0
³       ÀÄÄÄen-US
ÃÄÄÄPInvokeHelper
³   ÀÄÄÄ0.1.0
ÃÄÄÄplatyPS
³   ÀÄÄÄ0.14.1
³       ÃÄÄÄdocs
³       ÃÄÄÄen-US
³       ÀÄÄÄtemplates
ÃÄÄÄPowerShellGet
³   ÀÄÄÄ<IP_ADDRESS>
³       ÀÄÄÄen-US
ÃÄÄÄpsprivilege
³   ÀÄÄÄ0.1.0
³       ÃÄÄÄPrivate
³       ÀÄÄÄPublic
ÀÄÄÄPSReadline
    ÀÄÄÄ2.0.0
        ÀÄÄÄen

As you can see the characters that tree uses to denote the structure are all non-ASCII chars and are affected by the wrong encoding.
Here is some details on those non-ASCII chars used in the output

437 Char
437 Decimal
Windows-1252 Char

│
179
³

└
192
À

─
196
Ä

But at this point it seems to be a low impact issue

That's understandable, my intention is to just really document the problem so that either;

People can understand what is happened - obviously I've failed at that with the numerous posts
A workaround if no fix has been merged into PowerShell - Call AllocConsole using PInvoke

This is exactly what I said before is it not?  A native console command that returns text and runs in a remote session may return garbled text if the console code page is incorrect.  Right?  If so, we can update the Issue title and proceed with triage.

My apologies I misinterpreted it but after rereading it does sound like we are on the same page. I can open another issue under my name if we want to start without all this history here with a different title if you wish.

Thanks @jborean93 , I think the history is valuable so let's keep it.  I just wanted a clearer understanding of the problem.  We'll update this issue at the next working group meeting.

First, thanks @mklement0 and @jborean93 for the detailed investigation.  A couple of questions:

Is this only a problem with WinRM based remoting or is SSH also equally affected?
Is the ask to have pwsh.exe call AllocConsole() on startup?  Note that we are not making changes to powershell.exe that aren't security or other compliance issues

Is this only a problem with WinRM based remoting or is SSH also equally affected?

Just WinRM, the process that is spawned by the WinRM service seems to be done in a way that there's no console associated with it (wsmprovhost.exe). SSH calls pwsh.exe like a normal process and has a conhost associated with it so isn't affected.

Is the ask to have pwsh.exe call AllocConsole() on startup?

Or at least allocate it if there is no console that exists already. This at least solves the issue in testing but I'm unsure if it will start to affect things like the $host.UI.WriteLine behaviour or not. I assume it wouldn't but it's hard to tell. I also don't know if this should be done in pwsh.exe as a WinRM based remote session doesn't seem to call that executable. It uses wsmprovhost.exe and pwrshplugin.dll so maybe that's what needs to be touched.

Note that we are not making changes to powershell.exe that aren't security or other compliance issues

That's understandable, the comparisons with WinPS and PSCore are mostly to show it's an existing problem and not something new added since WinPS.

Maybe changing pwsrhplugin.dll is the way to go.  That code is here.
@jborean93 would you be willing to build a private validating that AllocConsole() solves the problem?
If we agree the change is in that dll, I'll move this issue over to that repo.

I can try but I can't guarantee I'll be able to look at where it needs to go and build it anytime soon.

@jborean93 take a look at the referenced PR.  Did some manual validation with tree and your encoded command example and works correctly.

Thanks for the PR, I've been able to test it and can also confirm it fixes this particular problem. I also couldn't find any side affects and things acted like they did before.

Thanks all for sticking to this and working on a solution.

@jborean93 your detailed investigation made this easy :)

@jborean93 Thanks for working with @PaulHigin to help the Working group and PowerShell understand the issue.  This is vital part of the process.


(log) fix wrong print introduced by 49fecd2a6dae

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 34.45 seconds
load time: 452 seconds
storage size:<PHONE_NUMBER>3 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221114173858_clickbench_pr_45939.html


feat: add listDevices method

Expose a listDevices() method which will list all of the connected devices.
This will make it much easier to handle multiple devices connected to a single machine, without having to write the scanning logic manually.
Example output:
[
  {
    type: 'serial',
    path: '/dev/ttyACM0',
    vendorId: '2ec2',
    productId: '0004',
    serialNumber: 'LDD2001014021480700360B0010'
  }
]

Websocket devices do not provide any additional data, as I do not know where to source it and would not be able to test it

@Julusian are you still interested in merging this PR?

Merged in 2827c89. Thank you for contributing!

Sorry, Ive been distracted on other things recently. Thanks for finishing this up


The question of "Refresh active schema after SQL execution" in preference

I select the checkbox "Refresh active schema after SQL execution" in preference.But I can't find the different places.

So I want to know the function of this button.

DBeaver will determine active schema after each SQL execution. E.g. if your SQL contains something like
USE schema_name

Then active schema will be changed to schema_name, DBeaver will check this and reflect this in UI.
Works only for databases which support current/default schema.


Libreddit update

Hi,
I'm a Libreddit maintainer and the original repo has largely stalled. I forked it due to a lack of maintenance and added a fix for the too many requests error and so it would probably be best to transition to Redlib instances (once there is any!). This is kind of a placeholder until we get a good amount of instances.
https://github.com/redlib-org/redlib

I'm not sure how much should be changed with regards to the URLs (I think leaving libreddit as the URL slug or leaving it as an option alongside "redlib" would be good) but the main change would be changing this line: https://github.com/benbusby/farside/blob/09a9b00ca9f191c57a1146007d9e0c5c8e43eb66/.github/workflows/update-instances.yml#L202
The new URL is "https://raw.githubusercontent.com/redlib-org/redlib-instances/main/instances.json". There's a handful of instances there but those are more likely to work versus the Libreddit instances are iffy when it comes to rate limits

OK, I think I've made all of the necessary changes for switching to redlib. The auto updater pulls instances from the redlib link you provided, and libreddit URLs will link to redlib instances now. Thank you!

Thanks!


Learner 552

Description
LEARNER-552
Add accessibility label for share course button

@saeedbashir please review the pull request. thanks


Fix auto launch

Codecov Report

Merging #60 (bb19d60) into master (d734b9c) will increase coverage by 0.09%.
The diff coverage is 23.28%.

@@            Coverage Diff             @@
##           master      #60      +/-   ##
==========================================
+ Coverage   32.33%   32.43%   +0.09%
==========================================
  Files          61       61
  Lines       11503    11538      +35
  Branches      183      188       +5
==========================================
+ Hits         3720     3742      +22
- Misses       7600     7608       +8
- Partials      183      188       +5

Impacted Files
Coverage Δ

src/clj/skylobby/fx/replay.clj
59.93% <0.00%> (-0.76%)
:arrow_down:

src/clj/spring_lobby.clj
13.31% <0.00%> (ø)

src/clj/spring_lobby/fs.clj
25.32% <12.50%> (-0.17%)
:arrow_down:

src/clj/spring_lobby/fs/sdfz.clj
33.92% <28.00%> (+2.29%)
:arrow_up:

src/clj/spring_lobby/client/handler.clj
33.01% <60.00%> (+0.88%)
:arrow_up:

src/clj/skylobby/fx/battle.clj
66.99% <100.00%> (+0.16%)
:arrow_up:

src/clj/spring_lobby/client/util.clj
100.00% <0.00%> (+29.16%)
:arrow_up:

Continue to review full report at Codecov.

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


[bug]: visual issue

Environment
Arch Linux proot inside Termux, zsh 5.9 (armv7l-unknown-linux-gnueabihf), zi git commit 75929e8
Reproduction steps
`zi -h` or `exec zsh` to install plugins/snippets

Expected behavior
1. No error is shown while showing command usage.
2. Git clone progress bar not printed every line.

Current behavior
1. Errors about `character not in range` printed when executing zi with `-h` flag. (See screenshot)
2. The Git clone progress bar printed every
line. (See screenshot)

Code snippet
{# OMZ plugins
}

{# plugins
    zi load "agkozak/agkozak-zsh-prompt"; {
        bindkey -v

        AGKOZAK_CMD_EXEC_TIME=3

        AGKOZAK_COLORS_CMD_EXEC_TIME=117
        AGKOZAK_COLORS_EXIT_STATUS=196
        AGKOZAK_COLORS_PATH=69
        AGKOZAK_COLORS_BRANCH_STATUS=76
        AGKOZAKTIDE_COLORS_PROMPT_NORMAL=76
        AGKOZAKTIDE_COLORS_PROMPT_VI=45
        AGKOZAKTIDE_COLORS_PROMPT_NONZERO=196
        AGKOZAKTIDE_COLORS_CLOCK=default

        AGKOZAK_CUSTOM_PROMPT=$'\n'
        # Directory
        AGKOZAK_CUSTOM_PROMPT+=$'%B%F{$AGKOZAK_COLORS_PATH}%2v%f%b'
        # Exec time
        AGKOZAK_CUSTOM_PROMPT+=$'%(9V.\n%F{$AGKOZAK_COLORS_CMD_EXEC_TIME}%9v :: %f.)'
        # Exit code & Job
        AGKOZAK_CUSTOM_PROMPT+=$'%(?..%(9V..\n)[%F{$AGKOZAK_COLORS_EXIT_STATUS}:%?%f%(1j..]))%(1j.%(?.\n[. )%F{$AGKOZAK_COLORS_BG_STRING}*%j%f].)'
        # Prompt
        AGKOZAK_CUSTOM_PROMPT+=$'\n%(?.%(4V.%F{$AGKOZAKTIDE_COLORS_PROMPT_VI}≈>%f.%F{$AGKOZAKTIDE_COLORS_PROMPT_NORMAL}=>%f).%F{$AGKOZAKTIDE_COLORS_PROMPT_NONZERO}=>%f) '

        AGKOZAK_CUSTOM_RPROMPT=""
        # Git status
        AGKOZAK_CUSTOM_RPROMPT+=$'%(3V.%F{${AGKOZAK_COLORS_BRANCH_STATUS}}%6v%(7V. %7v.)%f.)

Have you read the Contributing Guidelines?

[X] I have read the Contributing Guidelines.

Are you familiar with the Contributor Covenant Code of Conduct?

[X] I have read the Contributor Covenant Code of Conduct.

Contact Details
No response
### Tasks

Hi @UrNightmaree,
Thank you for opening an issue report :handshake: I have scheduled a triage and will update you on the progress :dart:
Please provide information about your terminal emulator :grey_question:
Thanks.

Hello @ss-o, thank you for responding my issue. 🙏

Please provide information about your terminal emulator ❔

It's Termux.

I tried above but still complain about character not in range.

Pretty sure that the error is shown because of the locale and multiple scenarios may cause this, e.g. lack of configuration, misconfiguration, corrupted files, etc.
Try the following:
Open the /etc/locale.gen file and ensure there is a line as below and it is not prepended with a #, then run locale-gen (usually requires root access and executed with sudo)
en_US.UTF-8 UTF-8

Add at the top of your .zshrc, then run exec zsh.
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

If the issue is not solved then check if it is caused by something in .zshrc:
mv ~/.zshrc ~/.zshrc.backup
touch ~/.zshrc
exec zsh
echo '\u2603'

If the character not in range error does not appear then recover .zshrc with cp -i ~/.zshrc.backup ~/.zshrc and remove components one by one while each time running exec zsh and echo '\u2603' afterward to identify what exactly causes the error.

Oh now it works, seems like I haven't setup locale.


Dark mode button and top view button collab each other

Describe the bug
IN THE RIGHT SECTION OF THE WEBSITE IN BUTTOM YOU CAN SEE DARK MODE AND TOP ARROW OVERLAP EACH OTHER SO PLEASE FIXED THSI ISSUE .
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.

I would like fix it.

I have fixed it. reply me please

I have fixed it. reply me please

That's great but i suggest u to point this on top of the website in nav bar

ok working on it.

but the best place for those buttons are bottom.....?

Moved the buttons to the top. Shall i make a pull request...?

Shall i create a pull request....???

and also assign me.....

yes

Thank You For Your Contribution


Prefer synced lyrics, options to allow only plain/synced

Prefer synced lyrics, but allow plaintext as fallback (default behaviour) (fixes #45 )
to not break backwards compatibility, the --allow-plain option still exists as an alias for the new (more concise) --plaintext-only
new --synced-only option
Documented behaviour of --enhanced: If no word-by-word sync is available, synced lyrics are used as a fallback. (Behaviour didn't change, but updated README for clarity)
if no translation is found it raises an exception (that is caught above). This is in my opinion better than checking if the translation worked later
small fix / enhancement: added __str__ method to LRCProvider, to avoid repeated provider.__class__.__name__()

uhmmm... well that's unfortunate xD
I just removed the print statement, now apparently they couldn't reach deezer?
Can you somehow restart the tests or do they only run on commits?

Seems Deezer doesn't work anymore lol. I wanted to comment out Deezer calls in search function and also put a help comment in readme but I don't know what happens if I change the main branch and your updates are based on previous version. I appreciate it if you can do it (also comment the Deezer test) so the tests pass and I will merge the changes.

Ok, I used black to reformat, and changed the functions back to lambdas.
Also commented out Deezer. Are we sure yet whether this broke permanently (due to an api change of theirs or sth) or if it's only temporarily down?
If there's anything else you want to change before merging, let me know :)

Great. Thanks again!


docs: Document core-dump-handler in the application catalog

I forgot to document it in #126 😕
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

no worries ... thanks for adding!


WIP: Reduce to energy sector

This seems more complicated than I thought: All over the code things have to be commented...

I found ways to make it simpler. Noe, just the last commit actually disables the other sectors. The other commits prepare for that step.


CORS issue

Hi, I published my versatiles server on Google Cloud like described here: https://github.com/versatiles-org/versatiles-documentation/blob/main/guides/deploy_in_google_cloud.md .
Except for the load balancer point, there may be a Google Cloud issue currently. Every time I try to create a load balancer, I get an error message.
I used the frontend version and it works pretty well. For my next step, I wanted to style my map using: https://maplibre.org/maputnik After adding the tile URL as a data source, nothing happened. In the console, I can see MapLibre throwing a CORS error when requesting the tiles from https://.../tiles/map/{z}{x}{y}.
I searched on Google, but with no results. Maybe someone can help me here. How can I enable CORS on my Google Cloud Run?

Hi, CORS can be set by sending a HTTP header "Access-Control-Allow-Origin" with a value of "*" to allow all origins or a specific domain. By default CORS only allows AJAX requests from the same domain. So if you are using Maputnik from a different domain, CORS will prevent any tiles from being served.
Unfortunately we haven't implemented CORS in the server yet, so you need to add the HTTP header to the "Backend Service" in the "Load Balancer".
Hopefully we can add CORS to the server implementations in the next few weeks.


fix kubectl config view to respect serialization formats

The scheme wasn't being passed through to a versioned printer, so the in-memory format of kubeconfig was being serialized.  Since the formats are significantly different, this didn't allow round tripping.  See: https://github.com/GoogleCloudPlatform/kubernetes/pull/3275#discussion_r22724773 for why the serialization format uses arrays and the in-memory version uses maps.
@derekwaynecarr This allows the round tripping you wanted to make with kubectl config view > my/new/.kubeconfig

@googlebot Why do you persecute me?
@smarterclayton Any advice for negotiating with a bot?

Does this impact how the go templates would work on the data?
For example, does this still work in cluster/kubectl.sh?
echo "current-context: \"$(${kubectl} "${config[@]:+${config[@]}}" config view -o template --template='{{index . "current-context"}}')\"" >&2

I suspect if there is a more complicated template processing the output that it may have to change?

Does this impact how the go templates would work on the data?

No.  The template isn't considered a generic printer: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/kubectl/resource_printer.go#L50

rebased

Can you add a test for the new behavior?

example added that checks for v1 serialization.

Excellent

Shippable was a transient

LGTM

Just in case you don't see an email notification for it, this was reverted in #4786 because it broke GCE cluster creation.


CDN Links not populated

This page in the documentation:
https://foundation.zurb.com/sites/docs/installation.html
refers to CDN links at jsDelivr, but the links referenced for the 6.3 code are not actually there.

https://github.com/zurb/foundation-sites/pull/9538

This is only a very minor thing, but the page
https://foundation.zurb.com/sites/docs/installation.html
under the heading 'CDN Links' states "The folks at jsDelivr host the compressed Foundation CSS and JavaScript for us."
Since the links have been changed to point to Cloudflare you should probably give them the credit now.

You are right. I'll update this.


CASMTRIAGE-7199 : supply options -sv and/or -bpcd or -rv during IUF deliver-product stage to install SLURM or PBS

Description
CASMTRIAGE-7199 : supply options -sv and/or -bpcd or -rv during IUF deliver-product stage to install SLURM or PBS
Checklist

[ ] If I added any command snippets, the steps they belong to follow the prompt conventions (see example).
[ ] If I added a new directory, I also updated .github/CODEOWNERS with the corresponding team in Cray-HPE.
[x] My commits or Pull-Request Title contain my JIRA information, or I do not have a JIRA.

I pushed a change to reformat the table.

I don't see why we need alternatives for each step, the -sv and -bpcd arguments should be safe to use regardless of whether a WLM is being installed or not.

/backport release/1.5


Adopt the Jupyter Releaser

We were already using the releaser to generate the changelog.
This change removes the previous config and workflow that was used to automated releases.
Next releases will be done with the Jupyter Releaser: https://github.com/jupyter-server/jupyter_releaser

This should be ready to go. The follow-up will be to cut a new release with the releaser!


Update cw dependencies from 0.13 to 016

Hi!
cw dependencies are getting old, could it be possible to update them from 0.13 to 0.16 on Cargo.toml?
Thanks!

Yes will do a bit later today

done, i will publish to crates.io shortly: https://github.com/mars-protocol/cw-asset/releases/tag/v2.4.0


feat: Add optional path var for instance level bucket path

Terraform will perform the following actions:

  # module.wandb.data.google_compute_forwarding_rules.all will be read during apply
  # (depends on a resource or a module with changes pending)
 <= data "google_compute_forwarding_rules" "all" {
      + id    = (known after apply)
      + rules = (known after apply)
    }

  # module.wandb.module.wandb.helm_release.wandb will be updated in-place
  ~ resource "helm_release" "wandb" {
        id                         = "wandb-cr"
      ~ metadata                   = [
          - {
...
              - values         = jsonencode(
                    {
                      - name = "wandb"
                      - spec = <<-EOT
...
                                "bucket":
                                  "name": "andrew-levin-gcp-intense-goblin"
                                  "path": ""
                                  "provider": "gcs"
                                "cloudProvider": "gcp"
 ...

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

The new helm release spec wasn't shown when running terraform apply, but the updates are propagated to the deployment as expected:

when bucket_path was NOT specified, when I exec'd to the wandb-app pod, I saw

wandb@wandb-app-65d8cb96-m7jb5:~$ env | grep -i bucket
BUCKET=gs://andrew-levin-gcp-intense-goblin

when bucket_path was specified as `"nested/path/test", I saw

wandb@wandb-app-7cbb475896-79266:~$ env | grep -i nested
BUCKET=gs://andrew-levin-gcp-intense-goblin/nested/path/test
    "store": "gs://andrew-levin-gcp-intense-goblin/nested/path/test",
OVERFLOW_BUCKET_ADDR=gs://andrew-levin-gcp-intense-goblin/nested/path/test
GORILLA_FILE_STORE=gs://andrew-levin-gcp-intense-goblin/nested/path/test

This PR is included in version 5.3.0 :tada:


midiOutOpen fails for Microsoft GS Wavetable Synth for Packaged app

Describe the bug
Bug is created by suggestion from https://github.com/dotnet/maui/issues/12368.
Looks like WinUI has a bug which causes midiOutOpen system function return 1 (MMSYSERR_ERROR) for Microsoft GS Wavetable Synth built in Windows Synth when an app is in Packaged mode. So it means it's impossible to use the synth in this case.
Please note that midiOutOpen works for any different type of a project (.NET Framework, .NET Core, .NET).
Steps to reproduce the bug

Just open the solution from the sample repo: https://github.com/melanchall/maui-midioutopen-bug.
Run the app.
Click 'Click me' button.

Actual: midiOutOpen fails with the result of 1 (I throw an exception to make it clear).

Expected behavior
midiOutOpen returns 0 which means no errors occurred.
Screenshots
No response
NuGet package version
None
Windows version
Windows 10 (21H2): Build 19044
Additional context
No response

I had referenced a similar issue  : #2337
in this test sample : WinUI3_Midi

@gabbybilka Is there any chance someone will look into the issue in the near term?


Populate workflow readmes

also updates main readme with row-wise workflow table
also renames neurodatagen imaging to ca_imaging

merging now.. will continue with the remaining workflows at a later time


Issue #492: Add support for multiple simultaneous environments

Add support for multiple environments, separated by space, ; or ,
This makes it possible to create orhotogonal environments, and run scripts
that are specific to a combination of environments.

Then, you can combine any of these environments to create a specific environment, to avoid
having to create an environment for each combination.
E.g.:
  --env Customer1;Azure
  --env Customer2,Azure
  --env Customer3
  --env Customer1 AWS Dev
  --env Customer1,AWS,Test
  --env Customer2;AWS;QA
  --env Customer2 AWS QA

etc.

Btw Erik you've done amazing steps to push grate forward. I've been very happy since then. Keep it up.
Thanks.
Thanh Tran.

Thanks, @hoangthanh28. I'm very happy with the contributions you have made, too! :)


[Add] Add 8 projects of MMDet

Thanks for the contribution. We have added your mentioned projects manually to resolve the conflict


Convert coverUrl to object and add cover.ratio

Merge this after api/telegram-bot/preliminary-frontend support this

This is a draft PR since i want to wait for the other projects, feel free to review already though @BjoernPetersen.


Report actual list of transfers that will be tried from git lfs env

I found this useful when debugging transfers, above and beyond just showing the booleans or having to dig into the actual JSON that was sent.
@technoweenie would be great if this could make it into 1.3 but no big deal if not.

This looks good. Well, lfs.Environ() needs to be rethought, but you know what I mean :)

Doh, I missed the same tests you did when adding the tus setting!