New REPL can't handle as much text as the old console?

[cormullion]

I've been having some Atom/Juno hangs with the REPL. I think the new REPL may not be as robust as the old (Legacy) one, but I've only scratched the surface so far.

dict = Dict(n => "I musn't keep breaking this $(isodd(n) ? "damn" : "nice") REPL"
   for n in 1:2000)

for key in sort(collect(keys(dict)))
    println("$key $(dict[key])")
end

This code either gets truncated, or hangs the REPL. Can't spot a pattern yet.

In this screen shot the cursor is stuck on the last line and I'll probably have to force-quit Atom/Juno now to get the REPL or Console back.

julia-client version 0.6.8, Atom 1.23.3, macOS High Sierra

[pfitzseb]

Huh. Works without an issue for me with 200k entries (on Windows and Linux).
Are you on Atom.jl 0.6.9? There might have been a bug that could have caused something like that in 0.6.8 and earlier, but not sure.

[cormullion]

Yes, I'm using Atom.jl 0.6.9. I can't detect much of a pattern, but I can trigger the bug reliably with any largish value in the above code. There are two different ways in which the REPL can respond:

• hang the Julia session (like in the picture above)
• truncate and continue

ie, it gives up somewhere arbitrarily, but doesn't hang, living to fight another day.

It may just be that my relatively old computer isn't handling the Atom system perfectly...

[pfitzseb]

Can you try two three things for me?

1. Execute the printing loop in the REPL instead of the editor.
2. Pkg.checkout("Atom") and try again in an editor. I've refactored the code I suspect causes those problems yesterday, so maybe it's magically fixed.
3. What happens if you interrupt the julia process while it hangs (with Ctrl-C I think)?

[cormullion]

1. Execute the printing loop in the REPL instead of the editor.

Always works properly... :)

3. What happens if you interrupt the julia process while it hangs (with Ctrl-C I think)?

REPL hangs. (Although I'm not sure about the difference between all the Stop/Interrupt/Ctrl-C actions...)

2 . Pkg.checkout("Atom") and try again in an editor. I've refactored the code I suspect causes those problems yesterday, so maybe it's magically fixed.

I couldn't make it go wrong again, so your magic has worked!

[cormullion]

Belay that - it went wrong again this morning, so the problem hasn't completely gone away. But it is much better with Atom master...

[pfitzseb]

Can you try again with latest master? Might be better (or not)...

Also, one observation I made: If you do something in the editor that requires interaction with Julia (searching in the docpane, switching editor so Julia needs to find out the current module etc) then the printing/execution of the loop will stall until that request has been handled. It does resume afterwards for me though, and I have never seen a simple loop not finish printing. In your case it is possible that some silent error occurs that kills julia and is unrelated to printing, although that would be pretty weird.

[pfitzseb]

Just FYI, I could pretty reliably reproduce this on my linux box last night. It's definitely some issue with deadlocking when reading from one pipe and writing to another, but I'm not sure why that happens :/

[cormullion]

I was just trying to get it to go wrong this morning... (I'm not working hard enough yet, it seems, to make Atom-ic fission happen. Will keep at it... :)

[pfitzseb]

What worked for me is to use Cycler mode, immediately kill the first session and try to print in the second one.

[pfitzseb]

Possibly caused by JuliaLang/julia#22832 and fixed by JuliaLang/julia#22886.

[pfitzseb]

I htink I've finally squashed this one with JunoLab/Atom.jl@8ed0264 and JunoLab/atom-julia-client@78fb03d.

Handling things like this also has the benefit of speeding up printing by a factor of 2-5; on the other hand, it makes the REPL more noisy since the julia> prompt will flash more. Currently I don't see any way around that unless we a) get a backport of the fix I mentioned above to Julia 0.6.3 and b) that actually solves this problem.