Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Julia nightly has ASCII salad for prompt in Windows CMD #56073

Open
KristofferC opened this issue Oct 9, 2024 · 9 comments · May be fixed by #57132
Open

Julia nightly has ASCII salad for prompt in Windows CMD #56073

KristofferC opened this issue Oct 9, 2024 · 9 comments · May be fixed by #57132
Labels
bisect wanted regression Regression in behavior compared to a previous version system:windows Affects only Windows
Milestone
1.12

Comments

@KristofferC
Copy link
Member

Image
@KristofferC KristofferC added the regression Regression in behavior compared to a previous version label Oct 9, 2024
@KristofferC KristofferC added this to the 1.12 milestone Oct 9, 2024
@KristofferC
Copy link
Member Author

Even in VSCode the REPL on nightly acts really weird

Screen.Recording.2024-10-09.130708.mp4

@inkydragon

This comment has been minimized.

Sign in to view
@vtjnash
Copy link
Member

vtjnash commented Oct 22, 2024

I hit this once also, and it was very weird, and affected every terminal and Julia version, then went away just as abruptly

@inkydragon
Copy link
Member

inkydragon commented Nov 3, 2024 •
edited
Loading

Using the Win64 version built by buildkite, this problem can be reproduced stably.
But if I build julia from source, REPL works well...

  • Version 1.12.0-DEV.1539 (2024-11-02) 9d1cedb

Terminals:

  • cmd with clean Windows Sandbox
    Image
  • Win Terminal, look bad
  • mintty.exe from cygwin, looks good, but REPL still cannot be used.
    Image

@inkydragon
Copy link
Member

inkydragon commented Jan 9, 2025 •
edited
Loading

My System env:

  • Win 11 24H2 26100.2605
  • Win Terminal 1.21.3231.0

Partially work around, REPL still produces abnormal output

@nsajko nsajko added the system:windows Affects only Windows label Jan 9, 2025
@giordano giordano marked this as a duplicate of #57008 Jan 10, 2025
@joa-quim
Copy link

joa-quim commented Jan 10, 2025 •
edited
Loading

Tried Tabby and it doesn't work either.
And neither does Cmder.

@KristofferC
Copy link
Member Author

KristofferC commented Jan 21, 2025 •
edited
Loading

Completely broken now on any terminal I try now on windows... Running with --color=no does not help.

VERSION = v"1.12.0-DEV.1912"

@joa-quim
Copy link

Confirm that. Installed the portable version and it's broken.

@topolarity
Copy link
Member

topolarity commented Jan 22, 2025 •
edited
Loading

This appears to be related to REPL.LineEdit's handling of the console mode:

$ julia +nightly -e "using REPL: LineEdit; println((LineEdit.default_console_mode_assigned[], LineEdit.get_default_console_mode()))"
(true, 0x00000000)

vs. Julia 1.11:

$ julia +1.11 -e "using REPL: LineEdit; println((LineEdit.default_console_mode_assigned[], LineEdit.get_default_console_mode()))"
(false, 0x00000007)

Bad logic is

julia/stdlib/REPL/src/LineEdit.jl

Lines 1640 to 1664 in 61e8f1d

if Sys.iswindows()
function _console_mode()
hOutput = ccall(:GetStdHandle, stdcall, Ptr{Cvoid}, (UInt32,), -11 % UInt32) # STD_OUTPUT_HANDLE
dwMode = Ref{UInt32}()
ccall(:GetConsoleMode, stdcall, Int32, (Ref{Cvoid}, Ref{UInt32}), hOutput, dwMode)
return dwMode[]
end
const default_console_mode_ref = Ref{UInt32}()
const default_console_mode_assigned = Ref(false)
function get_default_console_mode()
if default_console_mode_assigned[] == false
default_console_mode_assigned[] = true
default_console_mode_ref[] = _console_mode()
end
return default_console_mode_ref[]
end
function _reset_console_mode()
mode = _console_mode()
if mode !== get_default_console_mode()
hOutput = ccall(:GetStdHandle, stdcall, Ptr{Cvoid}, (UInt32,), -11 % UInt32) # STD_OUTPUT_HANDLE
ccall(:SetConsoleMode, stdcall, Int32, (Ptr{Cvoid}, UInt32), hOutput, default_console_mode_ref[])
end
nothing
end
end

The console mode accidentally got measured during pre-compilation / build time, where it returned 0 and then REPL.LineEdit is blindly restoring the 0 consolemode repeatedly.

You can confirm this is the problem by putting this in your startup.jl

using REPL: LineEdit
LineEdit.default_console_mode_ref[] = LineEdit._console_mode()

topolarity added a commit to topolarity/julia that referenced this issue Jan 22, 2025
@topolarity
REPL: Hard-code ConsoleMode flags on Windows
9705026 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

Instead of trying to fix that up, this PR replaces the existing logic
with a simple "reset to a hard-coded ConsoleMode" behavior. Since all
of the console mode flags require changes in our printing behavior to
accommodate, this should lead to much better behavior.

Resolves JuliaLang#56073.
topolarity added a commit to topolarity/julia that referenced this issue Jan 22, 2025
@topolarity
REPL: Hard-code ConsoleMode flags on Windows
7e36b17 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

Instead of trying to fix that up, this PR replaces the existing logic
with a simple "reset to a hard-coded ConsoleMode" behavior. Since all
of the console mode flags require changes in our printing behavior to
accommodate, this should lead to much better behavior.

Resolves JuliaLang#56073.
@topolarity topolarity linked a pull request Jan 22, 2025 that will close this issue
Open
topolarity added a commit to topolarity/julia that referenced this issue Jan 22, 2025
@topolarity
REPL: Hard-code ConsoleMode flags on Windows
468be4f 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

Instead of trying to fix that up, this PR replaces the existing logic
with a simple "reset to a hard-coded ConsoleMode" behavior. Since all
of the console mode flags require changes in our printing behavior to
accommodate, this should lead to much better behavior.

Resolves JuliaLang#56073.
topolarity added a commit to topolarity/julia that referenced this issue Jan 23, 2025
@topolarity
REPL: Query libuv for virtual terminal support
44a6644 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

`ENABLE_VIRTUAL_TERMINAL_PROCESSING` is the only flag that we're
agnostic about. It was added relatively recently (Windows 10 version
1511), and `libuv` has support to emulate its behavior when it's not
available natively.

Otherwise this PR resets ENABLE_PROCESSED_OUTPUT and
ENABLE_WRAP_AT_EOL_OUTPUT always, since we output ASCII control
sequences unconditionally.

Resolves JuliaLang#56073.
topolarity added a commit to topolarity/julia that referenced this issue Jan 23, 2025
@topolarity
REPL: Query libuv for virtual terminal support
5ef9f00 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

`ENABLE_VIRTUAL_TERMINAL_PROCESSING` is the only flag that we're
agnostic about. It was added relatively recently (Windows 10 version
1511), and `libuv` has support to emulate its behavior when it's not
available natively.

Otherwise this PR resets ENABLE_PROCESSED_OUTPUT and
ENABLE_WRAP_AT_EOL_OUTPUT always, since we output ASCII control
sequences unconditionally.

Resolves JuliaLang#56073.
topolarity added a commit to topolarity/julia that referenced this issue Jan 23, 2025
@topolarity
REPL: Query libuv for virtual terminal support
37e0f88 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

`ENABLE_VIRTUAL_TERMINAL_PROCESSING` is the only flag that we're
agnostic about. It was added relatively recently (Windows 10 version
1511), and `libuv` has support to emulate its behavior when it's not
available natively.

Otherwise this PR resets ENABLE_PROCESSED_OUTPUT and
ENABLE_WRAP_AT_EOL_OUTPUT always, since we output ASCII control
sequences unconditionally.

Resolves JuliaLang#56073.
topolarity added a commit to topolarity/julia that referenced this issue Jan 23, 2025
@topolarity
REPL: Query libuv for virtual terminal support
eaee38c 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

`ENABLE_VIRTUAL_TERMINAL_PROCESSING` is the only flag that we're
agnostic about. It was added relatively recently (Windows 10 version
1511), and `libuv` has support to emulate its behavior when it's not
available natively.

Otherwise this PR resets ENABLE_PROCESSED_OUTPUT and
ENABLE_WRAP_AT_EOL_OUTPUT always, since we output ASCII control
sequences unconditionally.

Resolves JuliaLang#56073.
topolarity added a commit to topolarity/julia that referenced this issue Jan 23, 2025
@topolarity
REPL: Query libuv for virtual terminal support
3468c0e 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

`ENABLE_VIRTUAL_TERMINAL_PROCESSING` is the only flag that we're
agnostic about. It was added relatively recently (Windows 10 version
1511), and `libuv` has support to emulate its behavior when it's not
available natively.

Otherwise this PR resets ENABLE_PROCESSED_OUTPUT and
ENABLE_WRAP_AT_EOL_OUTPUT always, since we output ASCII control
sequences unconditionally.

Resolves JuliaLang#56073.
topolarity added a commit to topolarity/julia that referenced this issue Jan 24, 2025
@topolarity
REPL: Query libuv for virtual terminal support
12e6584 
The query-and-restore logic here was pretty flawed:
  - it had no way to guarantee when the "default" mode is available to
    query, so it could easily save a "bad" mode
  - it did not ensure / check whether the "default" mode is compatible
    with the output generated by REPL (esp. ASCII escape codes / color)
  - it persisted the "default" mode from pre-compilation to runtime,
    causing JuliaLang#56073

`ENABLE_VIRTUAL_TERMINAL_PROCESSING` is the only flag that we're
agnostic about. It was added relatively recently (Windows 10 version
1511), and `libuv` has support to emulate its behavior when it's not
available natively.

Otherwise this PR resets ENABLE_PROCESSED_OUTPUT and
ENABLE_WRAP_AT_EOL_OUTPUT always, since we output ASCII control
sequences unconditionally.

Resolves JuliaLang#56073.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bisect wanted regression Regression in behavior compared to a previous version system:windows Affects only Windows
Projects
None yet
Milestone
1.12
Development

Successfully merging a pull request may close this issue.

REPL: Query libuv for virtual terminal support topolarity/julia
6 participants
@vtjnash @joa-quim @KristofferC @nsajko @inkydragon @topolarity