Thanks!
Nice work! When do you sleep?
2 Likes
Taking power naps during precompilation I guess. 
9 Likes
I’d like to report an issue with updating - I could not get Juno to update to 0.8 until I removed DiffEqFlux (it was a bit painful removing packages one at a time…)
As soon as I removed DiffEqFlux I got the following output below indicating the update finally worked (sadly I went in reverse alphabetical order with my installed packages )
When I add DiffEqFlux back after updating Juno, I get DiffEqFlux v0.10.2 (before updating Juno it was DiffEqFlux v1.3.2 so I’ve had to go backwards).
Maybe Chris Rackauckas knows why? Or the Juno authors?
(v1.3) pkg> up Juno
Updating registry at `~/.julia/registries/General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
Resolving package versions...
Installed Juno ───────────── v0.8.0
Installed Compat ─────────── v3.5.0
Installed SpecialFunctions ─ v0.10.0
Updating `~/.julia/environments/v1.3/Project.toml`
[e5e0dc1b] ↑ Juno v0.7.2 ⇒ v0.8.0
Updating `~/.julia/environments/v1.3/Manifest.toml`
[34da2185] ↑ Compat v2.2.0 ⇒ v3.5.0
[e5e0dc1b] ↑ Juno v0.7.2 ⇒ v0.8.0
[276daf66] ↑ SpecialFunctions v0.9.0 ⇒ v0.10.0
I read here Is Pkg's dependency resolution order-dependent? - #2 by kristoffer.carlsson that this is improved in 1.4, so the order shouldn’t matter then.
This is useful to know; however it seems like there is additional issue beyond order - right now it seems impossible to use the current DiffEqFlux with Juno.
It’s not obvious why the version of development environment is tied to version of computational tasks.
This is because of Flux. See https://github.com/FluxML/Flux.jl/issues/1036
Today I’ve updated the Julia and Atom packages for Juno 0.12 in a Linux machine, and every time I start Atom, it asks me to enter the password to unlock the keyring. This didn’t happen before the update, so I think it may be a related issue, although I’m not fully sure. Anybody else experience this?
(I know that this happens due to starting the session with autologin, but this was also the case before the update. If I cancel the request for the password everything seems to work fine, but it’s a bit annoying anyway.)
I’m using Ubuntu 16.04, Atom 1.44.0
Atom community packages installed:
indent-detective 0.4.0
ink 0.12.0
julia-client 0.12.0
language-julia 0.19.2
language-weave 0.6.7
latex-completions 0.3.6
tool-bar 1.2.0
uber-juno 0.3.0
Juno-related packages for Julia are Atom v0.12.3 and Juno v0.8.0
Is there a way to figure out why that happens (e.g. a “need sudo to foo the bar” message)?
1 Like
It’s only a popup window asking “Enter the password to unlock the default keyring - An application wants to access the default keyring, but it is locked” (translated from the message that I see in Spanish). I guess that it is related to Atom and Juno’s recent update, because it happens systematically after starting Atom, and it was not happening before updating the packages (the Atom app version is the same), but I don’t know how to find more details.
Well, maybe it’s not related to the Juno update, at least directly. After working a while without having entered the password, it asked me about it again just in the moment I was pushing a commit from Atom.
This makes sense. Perhaps I changed something in my Atom configuration without knowing, when I was in the process of updating (I got trapped in https://github.com/JunoLab/Atom.jl/issues/282 and https://github.com/FluxML/Flux.jl/issues/1036, and had to fix things manually).
Apologies if I caused some confusion.
It is really cool both looks and feels, thank you, an exellent work!
1 Like
Hey everybody,
we’ve just released Juno 0.12.1, which mainly fixes a bunch of bugs:
- Fixed an unrecoverable error when Julia was force closed on Windows (#687, fixed by #261).
- Prevent in-editor profile lines to be shown when no corresponding line exists in the editor (#481, fixed by #260).
- Updated version of the terminal library Juno uses (#258).
- In-editor breakpoints stay attached to the correct line now (#259).
- Detecting the REPL’s current module is now much faster (#288 and #691).
- Improved in-editor evaluation so that e.g.
readline()looks a lot better now (#288,#286, and #694). - Massive speed improvement for big HTML objects being send to the plot pane (#287).
- Fixed a regression in Juno’s block finding mechanism (#685).
- Fixed a bug where cell evaluation results would always be displayed in-editor, even when a different setting is selected (#486, fixed by #689).
- Fixed display of big (>2MB) HTML objects in the plot pane (#488, fixed by #690).
- Various improvements to the process cycler (#692):
- Changing e.g. the number of threads now invalidates cached processes, so it’s no longer necessary to kill a bunch of processes to get the updated settings.
- A warning about mismatched versions of julia-client and Atom.jl is now displayed more consistently.
- Prettier buttons for the debugger toolbar (#693, thanks to @jules).
As always, please follow the update instructions in the first post and keep reporting any issues you might find – all feedback is much appreciated.
Enjoy!
15 Likes
that’s an amazing number of quality-of-life improvements in a couple days. Amazing!
4 Likes
I am encountering the following error with the new version when I execute code via highlighting.
MWE:
using Revise
Executed via highlighting
Error:
TypeError: non-boolean (Nothing) used in boolean context
hideprompt(::Atom.var"#184#188"{String,Int64,String,Bool}) at repl.jl:126
macro expansion at eval.jl:71 [inlined]
macro expansion at dynamic.jl:24 [inlined]
eval(::String, ::Int64, ::String, ::String, ::Bool) at eval.jl:67
(::Atom.var"#182#183")(::Dict{String,Any}) at eval.jl:62
handlemsg(::Dict{String,Any}, ::Dict{String,Any}) at comm.jl:166
(::Atom.var"#19#21"{Array{Any,1}})() at task.jl:333
Version:
(v1.3) pkg> st Atom
Status `~/.julia/environments/v1.3/Project.toml`
[c52e3926] Atom v0.12.4
[cd3eb016] HTTP v0.8.8
[682c06a0] JSON v0.21.0
[e5e0dc1b] Juno v0.8.0
1 Like
Did you update to the latest version of julia-client?
1 Like
My mistake. Atom usually notifies me when a new package is available. That solved it.
Great work by the way!
2 Likes
There does seem to be a problem with this latest release. I upgraded Atom/Juno through Julia and then did
apm update
to get the latest version of ink and julia-client.
When I try to execute the first line of my Julia program using ctrl-enter, it just hangs in execution showing nothing but the running indicator.
I am on Windows 10 and Julia v1.4.0-rc1.
The first post update instructions were:
There is a File menu displayed on my Atom top level, but no Files menu. The File menu has no Settings sub-menu. This is on Ubuntu 19.10 with Atom 1.41. Do the Atom menues vary between platforms? Did I do something to alter the standard menues?
There is a Packages -> Juno -> Settings menu entry which did display Update buttons for julia-client and ink, though it hasn’t picked up the 0.12.1 release yet. The Packages -> Juno menu is so long that it has to be scrolled to show the Settings entry. I didn’t see a menu entry to refresh the package meta-data, but my attention wavers after scanning the first few dozen menu entries.
Honestly, I’d just use