Thanks for being so patient with my questions. I’m using JuliaPro v0.6.2 on an Ubuntu machine at the moment. What am I supposed to do to have the bundled Juno executable replaced by the new Juno? Thanks!!
I am not a big fan of the new update. First of all, eit gives a lot of warnings and my Atom is updated to 1.23.3 and I have run Pkg.update(). But the following warning still come up:
WARNING: Atom.jl: unrecognised message changemodule.
And is there a way to get the old console back, I do not like the new?
Please update the Julia packages with Pkg.update() as well.
Edit: Read over the part where you said you’d run it already. What does Pkg.status("Atom") return?
And yes, you can re-enable the old console in the julia-client settings. What don’t you like about the new console, btw?
What don’t you like about the new console, btw?
I don’t really see any need for all that noise introduced by julia> and printing of the banner.
Btw, the “code eval” symbol sometimes stops rotating before finishing (it actually rarely rotates at all, and if it does, it doesn’t rotate around it’s center).
Sometimes it also stays after finishing - and sometimes the code doesn’t actually finish evaling in cases where I’m pretty sure that the code should actually finish evaling 
3 Likes
Hm, I guess we could have an option to start Julia with --quiet. And if you really want you could use OhMyREPL to change the prompt to only > or something like that.
Wait, that should never rotate
Seems similar to Juno freezes intermittently when running code from script · Issue #103 · JunoLab/Juno.jl · GitHub.
This guy isn’t supposed to rotate??
No, unless you are on an old ink version or use custom css.
So it was rotating previously, right? I really miss that… Especially together with the bug, that sometimes the symbol stays there after finishing, or evaluation stops all together. I can’t really tell anymore if julia is still working, or if something just froze.
By popular request (@ChrisRackauckas, @sdanisch):
You can paste the following into ~/.atom/styles.less to get animations back for the inline cog thingies and the progess bar respectively:
.ink.inline.loading .icon:before{
animation: spin 4s linear infinite;
@keyframes spin { 100% { transform: rotate(1turn); } }
}
progress.ink:indeterminate {
-webkit-animation: progress-buffering 5s linear 12,
progress-buffering 5s 60s steps(10) 108;
}
@-webkit-keyframes progress-buffering {
100% { background-position: -100px 0px; }
}
9 Likes
Hi I am fairly new to Julia so please forgive any naive questions. I have both a linux system and winodws 10 system. This last update seems to have totally broken my windows 10 Juno. The console (REPL) give’s this when trying to start a julia session
Press Enter to start Julia.
Julia has exited. Press Enter to start a new session.
ERROR: could not open file C:\Users\Dustin
Stacktrace:
[1] include_from_node1(::String) at .\loading.jl:576
[2] include(::String) at .\sysimg.jl:14
[3] process_options(::Base.JLOptions) at .\client.jl:305
[4] _start() at .\client.jl:371
I have done Pkg.update() and made sure I am on the latest version of Atom. Any help would be great. Until this works I will revert to vs code.
One thing that comes to mind is there space between my first and last name for my user directory.
That error should be fixed with julia-client 0.6.8, which I’ve just published. Sorry for the inconvenience. 
1 Like
I must say that after trying Atom + Juno again after the last couple of updates, I’m thoroughly impressed. From what I experienced in a relatively short period of using, the speed is waaaaaay better than before, at least the same, if not better, than vscode . Together with the large set of very useful features + easily extendable behaviour I think I won’t be changing any time soon again.
Thank you so much for the hard and awesome work!
7 Likes
Thanks for the hard work. I really appreciate! But the embedded debugger is a little buggy.
(1). In debugging mode, the prompt at REPL changes to >debug, as expected. But after exiting debugging, the prompt doesn’t return to >julia, but stays with >debug. Sometimes I even got a double prompt >debug >debug in a same line.
(2). When (1) happens, i.e. prompt remains >debug, if re-call @enter, it hangs forever. In fact, sometimes it hangs despite what you do next.
(3). The finish button (the middle one) doesn’t work often. Clicking returns nothing.
(4). In debugging mode, REPL hangs for any command. This means that I’m even unable to quit debugging (I guess the only wait to quit debugging mode is by typing q at REPL).
(5). All kinds of internal errors are thrown, while no problem at all if debugging the same code with command-line based debugger. Here are two examples:
Julia Client – Internal Error
argument is an abstract type; size is indeterminate
argument is an abstract type; size is indeterminate
sizeof(::Type{T} where T) at essentials.jl:159
localvars(::ASTInterpreter2.JuliaStackFrame) at stepper.jl:185
contexts(::DebuggerFramework.DebuggerState) at stepper.jl:175
(::Atom.##127#132)(::String) at eval.jl:234
handlemsg(::Dict{String,Any}, ::String, ::Vararg{String,N} where N) at comm.jl:163
(::Atom.##11#13)() at event.jl:clock730:
Also I have a few suggestions:
(1). I wonder if the five debugger buttons can be labelled by text. Or, at least, a text hint shows when the cursor is placed over the button. Also, it would be nice to have a clear documentation somewhere detailing which button is for what.
(2). There are more than 5 different commands (n, s, finish, bt, f n, nc, se, si, sg) with the command-line-based version. I wonder if the missing functions can be added in the future.
(3). It’ll be thrilling, if the debugging can be done using the function keys, like in Matlab. It’s always quicker without having to use the mouse.
Thanks a lot for the great work!
@pfitzseb why you decided to remove the good old Juno console, what were the reasons?
I’m asking because I totally enjoyed it, and the today’s REPL is clearly inferior to what we have in the previous version. I would be happy if we could have REPL and Console (good old) simultaneously.
Thanks for the thorough feedback!
(1). In debugging mode, the prompt at REPL changes to >debug, as expected. But after exiting debugging, the prompt doesn’t return to >julia, but stays with >debug. Sometimes I even got a double prompt >debug >debug in a same line.
(2). When (1) happens, i.e. prompt remains >debug, if re-call @enter, it hangs forever. In fact, sometimes it hangs despite what you do next.
Yeah, that’s a bug that only happens when calling @enter in the REPL. Until it’s fixed please call it in an editor instead.
(3). The finish button (the middle one) doesn’t work often. Clicking returns nothing.
That’s not the finish button – I suppose our iconography could be better
(4). In debugging mode, REPL hangs for any command. This means that I’m even unable to quit debugging (I guess the only wait to quit debugging mode is by typing q at REPL).
I suspect this is related to (1) and (2) – at least I can’t reproduce it in a not bugged debugger session.
(5). All kinds of internal errors are thrown, while no problem at all if debugging the same code with command-line based debugger. Here are two examples: …
Can’t say I have seen those before. Are you on ASTInterpreter master?
Regarding your suggestions:
-
Tooltips will be live shortly (once I tag a new ink version):
I agree that more thorough docs might be nice though. -
I’m not sure if the missing commands are really useful in Juno:
bt: Should be covered by having the stepper in the source code.fr v: Just use the workspace instead.f n: Might be useful I guess?si: Same asse+s, so would save you one click/keypress I guess?sg: Would probably be useful.
- Sure, you can do that – just bind the following commands to a key (see here for instructions on how to do that):
julia-debug:finish-function(defaultShift+F11)julia-debug:step-to-next-linejulia-debug:step-into-function(defaultF11)julia-debug:step-to-selected-linejulia-debug:step-to-next-expression(defaultF10)
The old console is fundamentally incompatible with all command-line based Julia interfaces (of which there are quite a few) and it’s slow.
You can get the old console back by switching the Console Style in julia-client’s settings to “Legacy”, but it’d require quite a bit of effort to have both consoles active at the same time.
1 Like
Just to flag up that I found my Atom.jl installation (from the latest JuliaPro) was pinned at v0.6.6 by the package manager but I couldn’t find any package that was actually preventing it from upgrading. It wasn’t until I wiped package directory from my JuliaPro installation that it allowed me to upgrade to v0.6.8 - it’s possible that this is the source of some of the errors that people keep finding. (It was particularly annoying since Pkg.update() silently ignored the update!)
Alright, the new ink version (0.8.2) is out and introdcues tooltips for the debugger. I’ve also pushed Atom.jl v0.6.9 to METADATA.jl which should fix most (hopefully all) of the debugger related REPL bugs – please Pkg.update() as soon as that PR is merged.
In general it’s a bad idea to update any of the packages shipped with JuliaPro, which includes the Atom packages (and IIRC that will be impossible with the next release).
Please update to the latest version of Atom.jl and Juno.jl as indicated in the first post.
Haha it took me a minute to realize, but you mean update those packages within julia, not within atom. So julia> Pkg.update().
Thanks!
Are you saying that I can call or trigger @enter somewhere else, not necessarily in the REPL? How can I do that?
Yes, I am. I’m debugging a really complicated package. So these issues might also related to the bugs in the debugger. I really appreciate if the reported debugger bugs can be fixed.
Thanks very much!!
I think so.
I think so.
Personally, I seldom use sg. But I guess at this early stage it’s better to have everything we had with the command-line-based version before dropping some of them, if it is not too much work for you folks.
By ‘selected line’, do you mean that I can select a line so that I can step to? How can I do that? It’ll be great if the usage of the debugger can be documented to some extent. The animated GIF is just too fast for me to see any detail I want to see.
Also I wonder if all commands can be shipped with default key bindings so that one doesn’t have to spend time binding the keys every time Juno/JuliaPro is freshly installed. It’ll also be great if the most commonly used ones (the current five, probably) (i) are bound with default keys free of shift key and (ii) have the bound keys clustered in the row of function keys. This can significantly speed up debugging and enhance the debugging experience for sure.
I have a couple of further suggestions (Sorry for being annoying!!):
-
Do you think it’s a good idea to always open a file in a new tab when stepping into it and at the same time keep the tab of the file which the debugger just leaves. (The cute bug symbol at the tab tag travels with the debugger, indicating the location of the current debugger.) This way one can always look around and check a few files of successive levels simultaneously. This is exactly what Matlab does. I’m not saying that Julia debugger should do everything Matlab does. But most of the design of Matlab’s debugger is very neat and very user-friendly, though Matlab itself is not as nice. It’ll be great if the Julia debugger one day can give a user experience close to that of Matlab.
-
It also might be a good idea to just ban debugging commands from the REPL when in debugging mode and the debugging commands are instructed via the keyboard only, so that in the debugging mode everything you type is assumed to be an evaluation, i.e. in the
`mode. Again, this is exactly what Matlab does and it is very very efficient. With the key binding working properly, I doubt if people would like to take time to put in debugging commands in the REPL (the same action would cost you at least two keys, e.g.n+enterversus a singleFkey). Then it’s more or less useless to support debugging commands in the REPL on the one hand. On the other hand, when the REPL is left only for evaluation purpose, one doesn’t bother to type the back tick`every time when trying to evaluate something.
Thanks once more for the fabulous work!! I really really really appreciate!!
2 Likes
By typing @enter foo(bar) in an editor and pressing Ctrl-Enter
That said, the issues with starting debugging in the REPL should be fixed with the latest version of Atom.jl, so please Pkg.update() if you haven’t done so already.
Alright – in theory Juno is only a thin wrapper around the debugger, so it seems likely that you’re running into ASTInterpreter bugs.
It’s a question of what to have in the default UI, I suppose. I’m very hesitant to add more buttons to the toolbar, but it’d be pretty easy to just add Atom commands for those unmapped incanations.
“Selected line” means the line the cursor is on.
Sure, I’m open for suggestions as to which keybindings to use. F10 and F11 were inspired from matlab IIRC.
Hm, I suppose you can make a case for both behaviours. I kind of like not having that many editors open while debugging…
That’s how it’s handled already – you can only evaluate in the REPL, not use any ASTInterpreter commands.
Consider opening issues over here for those points you bring up as well.
Once again, I really appreciate your feedback!