Unicode Display Error (discovered via npm STDOUT)

@vors Hi. I spoke with you yesterday in Gitter. Thanks for your reply.
Steps to reproduce
Have something to STDOUT try to use Unicode characters. (I don't know if this is actually STDOUT on Windows or whatever, but the equivalent if it's not.)
Expected behavior
Render Unicode Characters
Actual behavior
Wrong characters rendered.

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                               5.1.14393.1198
PSEdition                                Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                           10.0.14393.1198
CLRVersion                             4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion  2.3
SerializationVersion                <IP_ADDRESS>

I think this may be the issue?
http://stackoverflow.com/questions/379240/is-there-a-windows-command-shell-that-will-display-unicode-characters

Utf8 encoding problem. The performance of cmd under normal, powershell not normal.
Must let npm tell powershell:
1 raw string
2 string encoding (can not let powershell to guess)
in conclusion:
ANY garbled, are due to the sender, did not inform the coding type caused.
This has nothing to do with powershell. You need to submit the issue to npm (nodejs).

Node.js outputs UTF-8 by default, though what you're seeing doesn't look it; a program is free to change stdout's encoding.
Generally, here's what you need to do to make your PowerShell console window UTF-8 aware:

On Windows 8.1 or below, ensure that the window uses a TrueType font (in Windows 10, it is by default. This is the prerequisite for being able to display all Unicode characters.

Additionally:

The console window's code page must be switched to 65001, the UTF-8 code page (which is usually done with chcp 65001, but the PowerShell command below does that implicitly).

PowerShell must be instructed to use UTF-8 to communicate with external utilities, both when sending input and receiving output.

The following magic incantation in PowerShell does this (as stated, this implicitly performs chcp 65001):
$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding

Do note that legacy utilities that do not support Unicode may break in such a console window.
You can verify proper UTF-8 handling with the following test command:
> $captured = node -pe "process.argv[1]" €; $captured; $captured.Length
€  # '€' character (U+20ac; UTF-8 0xe2 0x82 0xac) was properly echoed.
1  # '€', despite being composed of *3* bytes in UTF-8, was properly recognized as a *single* char.

$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding Did the trick for me. Is this persistent? Do i need to run this every time I open a Powershell? Any info would be awesome, like if I need to stick it in a config file or something.
@mklement0 You're the best! Thanks!
@chuanjiao10 Hope you're feeling better today!

@412andrewmortimer:
My pleasure.

Do i need to run this every time I open a Powershell?

Just put the command in your $profile - I've also updated my previous comment.

Should allow nodejs to be compatible with powershell.
Love nodejs people should go to submit issue. The selfish person will use that command.

@chuanjiao10: I'm not entirely sure what you mean, but, yes, PowerShell should at least have a less obscure way of handling UTF-8 properly and ideally even default to UTF-8 in PowerShell Core.
There is a pending RFC about UTF-8 support; it is being debated here.

@mklement0 So that solution worked, but then I tried to use Docker, namely docker-compose and this is what it says.
  Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 470
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 470
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 470
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 470
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 470
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 470
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 470
Traceback (most recent call last):
  File "logging\__init__.py", line 872, in emit
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Logged from file service.py, line 470
Traceback (most recent call last):
  File "docker-compose", line 3, in <module>
  File "compose\cli\main.py", line 64, in main
  File "compose\cli\main.py", line 116, in perform_command
  File "compose\cli\main.py", line 888, in up
  File "site-packages\colorama\ansitowin32.py", line 40, in write
  File "site-packages\colorama\ansitowin32.py", line 141, in write
  File "site-packages\colorama\ansitowin32.py", line 169, in write_and_convert
  File "site-packages\colorama\ansitowin32.py", line 174, in write_plain_text
LookupError: unknown encoding: cp65001
Failed to execute script docker-compose

This SO answer may help.

I don't have Python installed on Windows at all. Compose is written in Python, so I'm assuming that there is something highly abstracted happening.

It sounds like Docker comes bundled with its own Python, used behind the scenes, as evidenced by your error output containing strings such as __init__.py and site-packages\colorama\ansitowin32.py.

@412andrewmortimer: You're right - I just installed Docker and setting $env:PYTHONIOENCODING='UTF-8' before calling docker-compose --version didn't help.
Note that the problem is not PowerShell-related, however: running chcp 65001 in a cmd.exe window and then running docker-compose --version breaks too.

@412andrewmortimer: It's a known Composer issue.

I don't understand. How do I fix it?

@412andrewmortimer:

It's a bug in docker-compose and has nothing to with PowerShell.

You'll have to wait for the team behind docker-compose to release a fix (or try to contribute one yourself).

Glancing at the linked issue, it sounds like they'll have to switch to Python 3.x, which is probably a nontrivial undertaking and would explain why the issue is still not fixed, despite first having been reported more than 1 year ago. That, and the fact that using UTF-8 on Windows is still an exotic and brittle proposition, unfortunately.

I still don't understand why.
Shouldn't this be something Powershell does? Isn't it a bug in docker-compose and Powershell? I mean... it's not like docker-compose is magically running without Powershell. Docker is a command line tool and Powershell is a command line. I don't think blaming docker-compose is a good thing to say unless the point is to sweep it under the rug. Maybe it's the fact that "using UTF-8 console windows on Windows is still an exotic and brittle proposition, unfortunately." Is there somewhere to find out why Windows command line is so this way when it's generally not at all like this in other terminals?
Unfortunately I have to use Windows as a host OS at the very least. Is there something I can do to fix this in this repository? Because Powershell and development on Windows is pretty painful in general and if I can fix some of these issues, I would love to be able to. Because I highly doubt that I am alone in this sentiment.
I think it's obvious when generally the first step in nearly any development I do on Windows is "figure out how to run one command to not have to deal with Windows abd that will virtualize or emulate an environment that actually works." It's just really perplexing.
Have you tried to develop with Docker, Ruby, and JavaScript on Windows?  It's a pretty painful experience in general. I mean Git on Windows even ships MINGW. I assume to avoid Powershell. I mean... why?
I know this has become larger than Powershell not rendering UTF-8... but it's all tied in as far as I'm concerned. Even if it requires other issues to be opened.
(I'm not trying to be snarky or entitled. I get it. All of this is very complex, and sometimes you can only have one or the other when it comes to some decisions. All in all I just want development (I suppose the type of development I do) to be better on Windows.)

I get your frustration, and while PowerShell itself has work left to do with respect to UTF-8 support - and getting it right is the aim of the yet-to-be-released v6 -  the problem is related to a layer below the shell and incomplete support for it in the Python version that the current docker-compose is built on:

Shells (such as cmd.exe or PowerShell) as well as console applications need to be told by the environment what character encoding to use.

In the world of Windows consoles (console windows), it is the active Windows code page that determines the character encoding, as reported by the chcp utility, for instance.

Code pages are identified by numbers, and the official Windows code page for UTF-8 is 65001.

The Python 2.x version that docker-compose is built on doesn't recognize this particular code page when printing to the console (it  doesn't know what encoding cp65001 means).

This is indicative of Python's own slow, painful evolution toward complete Unicode support.
In a stand-alone 2.x Python version you can fix the problem by setting the PYTHONIOENCODING environment variable, but this doesn't work for embedded versions, which is the case for docker-compose.
It seems that the problem was fixed in Python 3.5, so using that as the embedded version for docker-compose would probably fix the issue, but is a non-trivial effort.

There's nothing that any shell invoking docker-compose can do to fix that directly.

However, there is a workaround:
Seemingly, if you don't output to the console directly, the problem doesn't surface.
Using a pipeline in PowerShell that seemingly just passes the lines through seems to help:
Powershell decodes the input before sending it through the pipeline, and re-encodes it on output - and it does recognize code page 65001 as UTF-8 (but note that when you send output to  a file you need to be aware of PowerShell's quirky, cmdlet-dependent encoding defaults).
docker-compose --version | % ToString  # Doesn't break with code page 65001

You can define a function wrapper (be sure to invoke it without the .exe extension):
 function docker-compose { docker-compose.exe @args | ForEach-Object ToString }

@mklement0 I appreciate your help and understanding! You are awesome!


Need a simple way to navigate to interface implementation in TypeScript

I'd like to have an action which allows me to see all implementations of a particular method from an interface.
The same applies to overrides of a method in a class.

Yes, but it doesn't work everywhere.

Also, there's another use case. You want to see overrides of a particular implemented method and it isn't covered well.

Are you trying to use the context menu or running the Go to implementation command from the command palette? Also, please include the issue template information the bot mentioned (os version, vscode version, and extensions)

Here's the OS info:
Version: 1.38.0
Commit: 3db7e09f3b61f915d03bbfa58e258d6eee843f35
Date: 2019-09-03T21:47:00.464Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Darwin x64 18.7.0

@mjbvz Go to implementation really worked. I am really surprised, I missed this feature so much in vs.code :-)
Do you mind if I create a PR to include go to implementation into the menu to make it more discoverable as well as creating a shortcut for it? (I am thinking about Ctrl+Shift+F12 on Mac and Alt+Shift+F12 on other platforms)

I believe that we actually use to have it in the menu but removed it since we didn't want to make the context menu too long. Adding it as a configuration option falls under #9285


Performance monitoring?

If it is possible with current version to use Performance Monitoring can we have example with the traces_sampler?
I'd like to sent transactions but discard health endpoint transactions.
If it is not possible to use Performance monitoring with the current version then when this will be possible?

Probably duplicate of https://github.com/getsentry/sentry-symfony/issues/382, https://github.com/getsentry/sentry-symfony/issues/380 and https://github.com/getsentry/sentry-symfony/issues/374

traces_sampler gives you the opportunity to choose dynamically traces_sample_rate based on the transaction data. This is a new feature described here: https://docs.sentry.io/platforms/php/performance/#sample-specific-transactions
Adding new version 3.x of the Sentry SDK, in my opinion, will not be enough as we need to somehow set this in the sentry.yaml
which is managed by the Bundle.
Also will be nice to have this documented with an example of how.

Yes 3.x is not everything but is needed as the first step, and with 3.x the new traces_* options will become available. The PR for this is here: #385, it was merged yesterday so a release will be underway but it's possible there is still a bit of work to be done before a release will be made.
A little more patience!

Probably duplicate of #382, #380 and #374

Yes, absolutely. Keep a look onto the 4.0 milestone.

Yes 3.x is not everything but is needed as the first step, and with 3.x the new traces_* options will become available. The PR for this is here: #385, it was merged yesterday so a release will be underway but it's possible there is still a bit of work to be done before a release will be made.
A little more patience!

No problem :) - I can wait - at least in the Python Flask I have this done and already this new sentry feature is useful for me and was worth changing from the free plan  👍.


openMPI linux builds

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Should add openMPI builds for linux as both mpich and openMPI NEURON builds are available.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [46]

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


tree - support custom payload when selecting, focusing etc

blocks #64727
The outline depends on sending payloads when setting focus or selection. This prevent infinite event handling et al. The new tree doesn't support that, it only support an UIEvent

#64743


[Bug]: Password hash returned in token from the login response

Relevant scope
Deployed demo
Description
The bcrypt hash of the password is returned in the JWT token from the response of the login endpoint.
The payload of the JWT has a signature, but the payload is base64-encoded and everyone with a token can decode it to get the password hash.
There's no good reason to include the hash in the token payload.

Hi @kujirajuunigou, thanks for pointing it out.
It's fixed now8


add @rcompat/webview

using the webview library and ffi
bun: https://bun.sh/docs/api/ffi
deno: https://docs.deno.com/runtime/manual/runtime/ffi_api
node: ?
prior work
bun: https://github.com/tr1ckydev/webview-bun
deno: https://github.com/webview/webview_deno
node: https://github.com/Winterreisender/webview-nodejs

bun done in cb1efb0

@gedw99 Thanks. Indeed for long-term, I've been thinking how we can approach mobile, as we'd ideally be wanting to support Linux/Mac/Windows/Android/iOS.
Given that it's Go, and our Go support currently mostly on the backend in the form of Wasm, how would you go about integrating into Primate? What could a proof-of-concept look like?

That repo was basically inspiration, it itself being based on the deno webview library.
What I'm doing is my (similar) own implementation by loading the compiled webview shared library via Bun's ffi interface. I think it might be possible to do the same with the compiled Go shared library, provided we have access to a C ABI.
I see some people have tried the same with CGO, cf. https://github.com/oven-sh/bun/issues/369
Maybe this is the way to go? I'll try going that path. Might need to adapt this Go library though to export C functions.
What do you think?
-------- Original Message --------
On 10/7/24 03:13, ged  wrote:

Hey @.***(https://github.com/terrablue)
I just compile and use it. Fitting it into being able to be wrapped by nodejs / bun is possible though.
Which in do you currently use ? Maybe this ?
https://github.com/tr1ckydev/webview-bun
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Sounds good to me. I've created https://github.com/rcompat/go-webview and gave you write access.
Once we have steps 1-3, we could implement step 4 with your suggested simple wrapping:
import { execute } from "@rcompat/stdio";

await execute("path-to-go-binary");

Think you could start with that?

Closing this for now, as bun can build primate. deno/node support will be added in a later phase.