Plotting broken?

adannenberg · October 9, 2019, 7:20pm

After upgrading (in Atom + Juno on Ubuntu 19.04 inside VirtualBox) julia-client from 0.10.1 to 0.11.2, uber-juno from 0.2.0 to 0.3.0 I find the following problem. Any help?

julia> using Plots

julia> plot(1:5)

Error showing value of type Plots.Plot{Plots.GRBackend}:

ERROR: ArgumentError: broadcasting over dictionaries and NamedTuples is reserved

Stacktrace:

[1] broadcastable(::Dict{String,Any}) at ./broadcast.jl:660

[2] broadcasted(::Function, ::Dict{String,Any}, ::Int64) at ./broadcast.jl:1213

[3] plotsize() at /home/alex/.julia/packages/Atom/BVajq/src/frontend.jl:21

[4] plotpane_io_ctx(::Base.GenericIOBuffer{Array{UInt8,1}}) at /home/alex/.julia/packages/Atom/BVajq/src/display/showdisplay.jl:

5

[5] displayinplotpane(::Plots.Plot{Plots.GRBackend}) at /home/alex/.julia/packages/Atom/BVajq/src/display/showdisplay.jl:55

[6] display(::Atom.JunoDisplay, ::Plots.Plot{Plots.GRBackend}) at /home/alex/.julia/packages/Atom/BVajq/src/display/showdisplay.jl:102

[7] display(::Any) at ./multimedia.jl:323

[8] #invokelatest#1 at ./essentials.jl:790 [inlined]

[9] invokelatest at ./essentials.jl:789 [inlined]

[10] print_response(::IO, ::Any, ::Bool, ::Bool, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:156

[11] print_response(::REPL.AbstractREPL, ::Any, ::Bool, ::Bool) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:141

[12] (::getfield(REPL, Symbol(“#do_respond#38”)){Bool,getfield(Atom, Symbol(“##178#179”)),REPL.LineEditREPL,REPL.LineEdit.Prompt})(::Any, ::Any, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:718

[13] #invokelatest#1 at ./essentials.jl:790 [inlined]

[14] invokelatest at ./essentials.jl:789 [inlined]

[15] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/REPL/src/LineEdit.jl:2306

[16] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:1038

[17] run_repl(::REPL.AbstractREPL, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.2/REPL/src/REPL.jl:201

[18] (::getfield(Base, Symbol(“##737#739”)){Bool,Bool,Bool,Bool})(::Module) at ./client.jl:390

[19] #invokelatest#1 at ./essentials.jl:790 [inlined]

[20] invokelatest at ./essentials.jl:789 [inlined]

[21] run_main_repl(::Bool, ::Bool, ::Bool, ::Bool, ::Bool) at ./client.jl:374

[22] exec_options(::Base.JLOptions) at ./client.jl:312

[23] _start() at ./client.jl:464

StevenWhitaker · October 9, 2019, 8:52pm

I just ran into the same problem on Windows 10 with heatmap.

Vova · October 10, 2019, 1:01am

The same problem…

adannenberg · October 10, 2019, 1:34am

I was able to fix the problem by deleting my ~/.julia directory and doing Pkg.add(“Plots”) after everything else rebuilt upon launching Julia. I’m sure there’s a better way to do it, but that worked for me.

jonniedie · October 27, 2019, 3:24pm

Same problem for me with macOS 10.14.6

Jon_Norberg · October 30, 2019, 2:23pm

Also happens using Images Gray.(rand(2,2))

pfitzseb · October 30, 2019, 3:01pm

Please make sure you’re on an up-to-date version of Atom.jl (0.11.3 is the latest version).

You should also be getting a warning that whatever version of Atom.jl you’re running is too old, but apparently that check doesn’t work for anyone.

Edit: Just tested it again and I’m getting
grafik

Jon_Norberg · October 30, 2019, 8:21pm

I apparently thought I had done that but hadn’t. Works now. Thanks

anon92994695 · October 30, 2019, 9:14pm

Update all software and packages, close Atom/Juno and rebuild Plots.

dpsanders · October 30, 2019, 10:13pm

Would be good to find a way to automate these updates if possible without everybody having to uninstall and reinstall and build by hand.

adannenberg · October 30, 2019, 10:36pm

Yup, the real issue is that Julia still has a number of glitchy features that makes it too idiosyncratic to be adopted by a Matlab-sized audience which, necessarily, would include many people without significant admin / command line / … skills.

Raf · October 31, 2019, 12:51am

@adannenberg to be fair users are paying a lot for the smoothness of the matlab experience, and lose a lot of other kinds of other flexibility by doing that. And “Julia” isn’t a single entity like you are describing, its a software ecosystem. There will always be idosyncratic messy corners (as there are in R and Python) where you need to use the command line to fix problems.

The real message here should be to feel free to jump in and fix whatever you think should work more smoothly

adannenberg · October 31, 2019, 2:02am

@Raf, I’m not competent to fix what doesn’t work in Julia, sadly :< I’m just a platform agnostic guy who has used Matlab and R extensively, Python moderately, but is a newbie to Julia. I can’t speak to the use cases that are not common to all four languages, but for the bread-and-butter number crunching that most users come for (I think), it is the case that Julia is much glitchier than R, Matlab or Python. Yes, there are always idiosyncratic, messy corners. But it matters how many there are! So, if Julia wants to increase its adoption by people like me, the core team needs to make the user experience smoother. For example, and very concretely, the fact that loop variables are scoped differently on Atom+Juno than on Jupyter is a huge problem. You just can’t have the language work differently for any program with a loop on the two main development platforms! Not if you want to become a mainstream product…

Don’t misunderstand me, please: I’m a Julia enthusiast and hope the language gains popularity and penetration, and that the toolset matures and expands. I’m just pointing out that for non-power users the fact that the edges are a bit ragged can outweigh the all the speed and flexibility stuff. Those ragged edges present no obstacle to the hardcore developers who actually push Julia forward, so I think they underestimate their importance to the broader group of users they want to attract to Julia. Fair enough?

Raf · October 31, 2019, 2:18am

You would be surprised! Julia is all in julia and the internals are often easy to understand. Seriously just jump in there, its not like R or python where you have to learn anything special.

Maybe try to outline how to fix the Juno/Jupyter issue? Make an issue with your proposed behaviors, try and work out why they are how they are and what it would take to solve them, and why it’s worth the effort. That would be a really helpful contribution.

pfitzseb · October 31, 2019, 10:39am

We’re not going to start Pkg.updating() for you (and I’m sure you wouldn’t want us to). Juno could probably ship all its dependencies so you’d never run into these kinds of problems (like the VSCode extension does), but that would require completely re-architecting everything – not really a short-term solution.

Less glitchy features and idiosyncrasis come with maturity; Julia 1.0 has been out for roughly a year now, so I wouldn’t quite call it (or the package ecosystem, for that matter) mature.

The outlier here is Jupyter with its own solution to the “soft-global-scope issue”. Juno can’t quite take the right approach, because a big part of Juno is that you evaluate code in files both interactively and “compiled” (for lack of a better word). No-one wants a situation where a loop written in a file is valid when executed block-by-block in Juno, but not when the file (or module) is included.

It’s super important to get feedback from newcomers and non-power-users, so thanks for chiming in here! Please do chime in whenever something is annoying/hard to grasp/broken.
Also, improving usability (especially for newcomers) is really difficult: In most cases you have to solely rely on feedback to a) figure out what should be improved and b) for every change, since developers usually have already gotten used to any “idiosyncratic messy corners”

One more thing: If applicable, use tags or post in a more specific category. I can’t/don’t want to monitor all of Usage, but a post is much more likely to get my attention if you tag it with “Juno” or post it in the “Juno” category.

adannenberg · October 31, 2019, 10:59am

Thanks @Raf and @pfitzseb for the feedback and suggestions. Noted Sorry about the lack of useful tags. Is there a way of adding tags after the fact? I can’t seem to find one…

carstenbauer · October 31, 2019, 11:05am

I don’t know how @dpsanders meant it, but for me the much more annoying (although also not super annoying) part is the apm uninstall julia-client and apm install julia-client. Not so much the ] up Juno Atom.

pfitzseb · October 31, 2019, 11:21am

Fair enough. That’s a completly different issue though.

dpsanders · October 31, 2019, 12:26pm

Yes one of the things I meant was the apm commands.
If only the “Juno-related” Julia packages are involved, which are only used for Juno, and there was an opt-in option, I think I would be happy for it to automatically ] up Juno Atom as well.

(Is it still the case that any package operation touches unrelated packages? It seems to be, but it shouldn’t be.)

nilshg · October 31, 2019, 3:13pm

I keep flogging this dead horse, but for non-command line users (like I am on most of my work machines where I can’t access apm commands through the command line), the re-install issue for julia-client can be solved through the Atom GUI, by just clicking “uninstall” and then two seconds later “install” in the packages menu.