Using Windows, if you launch the REPL and type
~
abcde
~
then use left arrow, the cursor is quite slow, perhap one second per keystroke.
I am not sure if the cursor just blinks slower than normal or what the issue is.
I thought it might be because Julia REPL is in color, but modern Ruby REPL is in
color too so thats not it.
If my cursor is under e and I move left, the cursor should show under d
FAST. Like 1/10 of a second or similar. Otherwise its painful to do anything
beyond the most basic of task in the REPL and I will end up doing scripts for
even 2 line tasks, or perhaps string programs. Then this kills the whole point
of having a REPL.
can you post a gif or similar of the repl?
What terminal are you using? See #7267.
Strange, I definitely don't see this.
Which windows version (winver)
For me there's less of a delay but it is just barely slower than Python. I do see flickering of the current line in the Julia prompt that I don't see in the Python prompt. This only shows up when using the default Windows terminal; if I use ConEmu with cmd.exe as the shell, it doesn't happen. This is Windows 10 1809.
I see the exact same behavior as @iamed2
@cup Make sure you don't load any packages that rely on Gtk.jl; see https://github.com/JuliaGraphics/Gtk.jl/issues/325
FWIW, I also see a very slow REPL on cmd.exe in Windows 10, even without Gtk.jl loaded.
@mbaz uh, how would i even unload it?
im using a pristine Julia install, so unless its loaded by default, that aint it.
@cup Yeah, if you're not loading it, then it's not the cause of the slowdown you see.
I brought this up because many packages (which one may load from Julia's startup file) depend on Gtk.jl. using any of those packages brings Gtk.jl in.
In my case, I was trying to use ProfileView to profile some code. The results showed my code spending most of its time in Gtk functions, which was weird -- until I saw that ProfileView brings Gtk in and messes up the event loop.
I cannot repro on a freshly installed Windows 10 with julia 1.2-rc3.
@KristofferC can you clarify your terminal?
cmd.exe
@KristofferC are you able to test any other Windows versions? I can set up a Windows 10 virtual machine, but I would like to avoid that if possible
are you able to test any other Windows versions?
Unfortunately, no.
We would, of course like to provide a good experience on as many platforms as possible, but since this seems to be due to a CMD.exe bug (that we're expected to figure out a workaround for even though it's not our bug), that only happens on old Windows versions when using the known-to-be-crappy terminal, and there are alternative terminals that are much better in every way, this is a pretty low priority. If you or someone else who has one of these old systems doesn't investigate this, it seems unlikely that it will be fixed.
@StefanKarpinski that is a strange comment, considering these and others work
just fine in the situation youve described:
it seems like when you are saying this:
We would, of course like to provide a good experience on as many platforms as
possible
what you really mean is:
We would, of course like to provide a good experience on as many platforms as
possible, as long as that goal doesnt require any effort
I think you really need to reexamine your attitude about open source software. You are not entitled to anyone else fixing bugs for you. You either fix a bug yourself, pay for someone else to fix it, or wait until someone else decides to fix it. Since you seem to have a lot of enthusiasm for getting this particular issue fixed, I would suggest directing that energy towards investigating whether any of the above languages have had a similar bug in the past, and if so, how they fixed it.
I think you really need to reexamine your attitude about open source software.
as do you. windows 7 is proudly listed here:
https://julialang.org/downloads
but leadership seems to be unwilling or unable to take steps to ensure that
experience is actually usuable on that platform. it would be better to just be
honest and change it to Windows 10, or at least be clear that Windows 7 (and 8?)
users are going to have a degraded experience.
You are not entitled to anyone else fixing bugs for you.
correct
You either fix a bug yourself, pay for someone else to fix it, or wait until
someone else decides to fix it.
also correct, I am choosing to wait
Since you seem to have a lot of enthusiasm for getting this particular
issue fixed, I would suggest directing that energy towards investigating
whether any of the above languages have had a similar bug in the past, and if
so, how they fixed it.
i think better use of my time would be to continue to wait. as I am actively
using some of the other programming languages listed, it wont be a huge problem
if this goes several years without being fixed. obviously i would like to see
this fixed in a timely manner, but as youve said thats unlikely to happen with
the current leadership. thanks
I'm just trying to set expectations. Microsoft won't even support Windows 7 in five months.
Also, Julia is perfectly usable on Windows 7: you can use any of the various higher quality terminals that don鈥檛 have this problem, or use Juno which has a built in terminal, also without this problem. Is there some reason you are unable to use a real terminal?
x-ref previous issue analysis here and for NodeJS (which also uses libuv and also exhibits this issue on Windows 7):
the underlying node issue appears to be:
see also related discussion in:
Since we (and nodejs) have shown this is a bug with Windows 7 conhost.exe, and they've already reported this to be fixed in newer releases (https://github.com/microsoft/terminal/issues/269), I'm going to close this and suggest you file any new bug reports against the responsible entity (same link as previous: https://github.com/microsoft/terminal/issues/new?template=Bug_Report.md)
It seems I did not do enough testing. Previously I had only tested the Cygwin
versions. Retesting with native Windows versions yields this:
Julia is still slower than these listed, but not by much. I am not sure why the
Windows version would be slower than Cygwin version, or how PHP was able to keep
speed up.
Most helpful comment
x-ref previous issue analysis here and for NodeJS (which also uses libuv and also exhibits this issue on Windows 7):
the underlying node issue appears to be:
see also related discussion in: