Suppressing plot windows by default - is this purposeful?

[David Parks]

The following examples will fail to open a plot window in the REPL (notably without warning or error, making it devilishly hard to troubleshoot).

using Plots                               # This is common to all plotting platforms as far as I know
function test(); plot(); print(); end
test()                                    # Fails to plot, returns with no result

plot();                                   # Fails to plot, returns with no result

The solution is to do:

display(plot())                           # Works in all cases

I understand and support the desire to provide output suppression (I code in matlab most often and am very familiar with that feature).

However to default to UI windows being blocked seems like very un-intuitive behavior to me. And this is not the way matlab handles UI windows, semicolon or not, UI windows are displayed.

Furthermore, the result of simply adding a semicolon to plot, or adding a print statement after it in a function is that it silently fails, and in an unexpected/unintuitive way.

Is there a good reason for UI functions to be blocked like this? Or is it something that should be a feature request?

[Tom Breloff]

Hi David.  I didn't realize you posted here as well.  I'll copy/paste my response from gitter in case it helps anyone else:

this is certainly a feature that matches julia style. Just as with any other type, when a Plot object is returned to the REPL it is displayed. A semicolon suppresses this. If building a Plot object is part of a function call or script and not explicitly returned, the assumption is that you don't want the display side effects (again this is a feature... Many times you really don't want to display on every call to plot/plot!)
All that said, there is the 'show = true' option that you can pass in, and you can always set that default value when you load in: using Plots; pyplot(show = true)
This should give you the behavior you're looking for

[David Parks]

Hey there Tom, great to hear from you!

Yeah, after the earlier conversation on Gitter I posted here since this sounded like more of a Julia issue than Plots specifically. I hadn't noticed your response there.

My main experience with a REPL is Matlab, so I come with that bias. I would argue that I can't think of a time you would want to suppress a plot window, or UI window in general. I agree on suppressing console output, but not so much with UIs. Matlab defaults to displaying with an explicit option to disable that.

At the very least I would think that having show=true as a default makes much more sense than not. At least more often than not I suspect that you'd want a window open, and certainly on first use.

The problem I see is, as a new user to the language, the results seemed very arbitrary. Sometimes a plot window showed up, sometimes it didn't, and it was hard to decipher why. 

Adding a print statement after a plot generated different behavior. I think that is fair to classify as a gotcha, it sure got me. 

The second issue is that the command executes/fails silently with no result, which is extremely hard to troubleshoot. I spent many hours today trying to track down what was going on before I finally understood the issue. I think defaulting to UIs being displayed would be a benefit to overall adoption, it would feel like things "just work", which was a big part of the reason I really like matlab, things just work in that environment, there are very few gotchas. I think that's a fair comparison to draw in this case. 

This is the most mind boggling of the cases, I had simply added a print statement for debugging purposes and had no concept that it was drastically changing the execution flow:

function test(); plot(); end; test()            # UI window opens
function test(); plot(); println(); end; test() # Silently fails

Of course now I understand that I can wrap it in display() or enable the show=true setting. But I'll bet a lot of people following me will run into this too.

 

[David Parks]

function test(); for i=1:2; plot(); end; end; test()    # Another favorite gotcha, plot in a loop mysteriously and silently acted differently than plot outside of a loop

[Tom Breloff]

If you have suggestions for the docs, I'm all ears, but I think the default behavior is here to stay. There are too many scenarios where a gui window is not what you want... Writing to a png, inline plotting in IJulia, etc, and it already displays automatically when returned to the repl. 

[STAR0SS]

I thought for like one year that plotting was bugged/broken in Julia because of this. I only understood the current behavior while reading a github issue.

One issue with the doc is that there's not a centralized one since plotting is done via so many different packages (it's not an issue specific to Plots). It's not super clear where this information

should be.

>There are too many scenarios where a gui window is not what you want... Writing to a png, inline plotting in IJulia, etc

The issue with these kind of statements is that without a way to measure what people actually do, they are not very useful. For all we know 

90% of the actual use case could be that the user want a plot to display. That said I don't mind the current behavior that much.

[David Parks]

Hi Tom, thanks for the reply, and just to be clear, I love your work on Plots, not trying to complain, just discussing a long-term usability point.

I don't fully understand the mechanisms under the covers that open a UI window. This is via Electron I presume?

You're certainly correct that a UI window popping up in an IJulia context would constitute very unexpected behavior.

But is there no way to distinguish between plotting to a file vs. plotting within an IJulia context. vs. REPL vs. command line execution (which might best default to REPL behavior)?

It seems like plotting to a file would require a save-to-file argument, and the difference between an IJulia context and otherwise could be detected.  But I'm pretty new to this, so I don't know what is or isn't possible.

I also meant this question to address all such UI windows. For example, with the Images module, I would hope for a consistent "standard" approach across Julia packages, which is context aware. For example, I would hope that both `view(myimage)` and `view(myimage);` from the ImageView module would pop up a window in the REPL, and command line, and automatically display in-line in IJulia (I think save-to-file isn't relevant in that case).

After installing the ImageView, Image, and TestImage package, it does in fact work in the REPL as I suggested, but unexpectedly pops up a UI window in IJulia, so in that case the user gets the unexpected behavior that you're commenting on. However even that is many times better than a silent failure, as far as unexpected behavior goes. If there's a switch in there to display inline in IJulia it's now clear to me that I need to go find it, but with silent failure, troubleshooting is many times harder. And as STAR0SS mentioned, it ends up feeling buggy to a an uninitiated user.

Dave

[Steven G. Johnson]

PyPlot (by default) opens a window in the REPL, plots inline in IJulia, and is non-interactive (waits for an explicit, blocking show() call to open a window) when run via "julia somescript.jl" ... is that what you want?

[Tom Breloff]

I still think this is a documentation issue, if anything. Julia is not Matlab (in a good way) and we shouldn't be forced to match their conventions. If you have suggestions for documentation language, please post it!

[Chris Rackauckas]

As I noted when I explained this solution to him in the Gitter, I think this should be explained here: http://docs.julialang.org/en/release-0.4/manual/noteworthy-differences/. This is a feature for a good reason. It's the same feature that makes it so that you don't have to add semicolins everywhere, i.e. that there are environments where things are not printed to the REPL by default (plots are printed via sending the object to the REPL). For example, if you execute an entire script (either via Juno, or by julia script.jl), it doesn't print your non-semicolon'd text (thank god), and for the same reason it won't make the plots. To show either, you have to display with with display(), show(), print(), etc.

I think you'll learn to love this feature because it makes everything uniform and predictable. Everything is treated the same. In MATLAB, if you use a nested function vs not a nested function, there are differences as to whether it will show for a reason, because there's hardcoded workaround for if it's not a nested function, or nested in a parfor, etc. However, I agree that coming from MATLAB it can be a bit odd since MATLAB chose the "obvious way a newbie would expect it to work" (until it doesn't, nested in loops / functions too far, prints to fast, etc...) whereas Julia chose the "maybe non-obvious but uniform" approach with plots being treated the same way as everything else. Again, this same feature also allows you to not have to put semicolons at the end of every line of a script, which I enjoy.

[NotSoRecentConvert]

I agree with Dave. Having come from working with Matlab myself I liked that I could interactively build up plots from the REPL. My experience in plotting with Julia is only with PyPlot but I found it frustrating and time consuming to figure out why it behaved differently in different situations and in unexpected ways. In Julia I have to make a script to do a quick plot or repeat a bunch of lines in the REPL if I get any part of it wrong because the REPL is unusable while a plot is open.

From a design perspective I would expect that issuing a plot() command would result in a plot window to open. This is part of the syntax of programming. for every element in this loop do this. print() this string to the REPL. write() this information to a file. plot() this data so I can visualize it.

This isn't meant to force Julia to be like Matlab but to make it make sense. Not having to add a semicolon to every line to suppress its output is nice. I don't care to look at the object plot() returns but the plot that it is supposed to create.

[Chris Rackauckas]

But it does plot it, and use display() to display it. And I didn't know the REPL doesn't let you edit plots. It works just fine (i.e. like MATLAB) in Juno.

[NotSoRecentConvert]

Looks like we're interpreting the same sentence to mean different things. When I use plot as a verb I mean to create and show a visual representation of the data. It's like if I were to ask you to draw something. I don't mean imagine drawing it and then physically drawing when I ask you to show it to me.

[Tom Breloff]

When I think of the verb "plot", I think "contruct a visualization of the input data". This does not necessarily include building/opening a GUI window, which is just one method of using that visualization. I understand that in your mind: "But I would never want to do anything else with it!"  But that's just not a very nice perspective for such an insanely flexible language like Julia. 

Also, like I mentioned earlier, you CAN have the behavior you want in Plots, just by setting the default value for the keyword "show". So you can have your way without forcing your perspective on everyone else. Certainly this info could be more prominent in the docs... I'm happy to hear suggestions on that. 

[Chris Rackauckas]

I still think the Julia way matches better to reality. You can go up to a kid and ask "can you draw me a cow?", and they draw it, and later ask "can you show me the cow?" and they'll show it to you. If you're standing right there (i.e. using the iterative REPL at its highest scope) you'll see it just cause you're standing there.

For many longer codes, I don't want to see all of the plots. Some longer calculations may generate hundreds of plots. I want those plotted and saved, not displayed. And I think it's safe to say that if someone is running something non-iterative (i.e. a script where displaying is off by default) they don't want it to throw a bunch of junk to the screen, just what they ask for. 

(In fact, one of the biggest issues I see with newcomers running compiled MATLAB batch scripts is the fact that they don't tell it to close every plot at the bottom of the script. Thus the scripts keep running because they accidentally have windows open... even though you can't see them. This causes infinite runtimes and having to cancel scripts.)

While I agree Julia is not perfect, this is something that MATLAB has trained people to think the unintuitive way (and it causes problems when it doesn't work, like in the batch scripts), not the other way around.

[David Parks]

My argument here is really for consistency.

The beauty of a REPL, for a new user, is being able to hack through a few lines of code, see how they work in practice, and then use them confidently. It really speeds learning a new package, understanding a language feature, or just coding something new.

I'd be perfectly happy if, in the REPL, when I call `myplot = plot(x,y)`, I get back a plot object that I then need to display with `display(myplot)`, or by adding `plot(x,y,show=true)`, or by explicitly defaulting show=true with `pyplot(show=true)`. If that happened in the REPL, I'd quickly learn Tom's paradigm, `plot` "constructs a visualization of the input data" - and I would be benefiting from the REPL as part of my toolkit, and I'd be happy. But when there's a difference between how the REPL works and how the same command works in a code block, then I lose the benefit of the REPL, worse, the REPL teaches me one way of doing things that I then have to unlearn in an non-intuitive way. 

Whether it's done by default one way or another isn't important if consistency is maintained.  I think the disconnect in this discussion is rooted in the inconsistency of behavior between REPL and code block. And I believe that will be a pain point for an untold number of future users.

In any case, lovely discussion here. :)

[Chris Rackauckas]

But it is consistent. If you type 2+2 in the REPL you get 4, and if you put the same code in a loop it won't display 4 anymore. This is highlighted in the documentation. Julia just treats plots like any other type.

I think it's just a documentation issue. Somehow it should be noted in the spots where the documentation describes the behavior of printing/non-printing to the REPL and the use of semicolon. However, that would also be kind of odd because plotting is not part of Julia's base... so other than in the "Noteworthy Differences from Other Languages" I don't know where else it should go.

[NotSoRecentConvert]

plt[:show](), display(), or whatever is a minor nuisance so if it's the developers' wishes that it is so then so be it. I would feature it prominently in the documentation of the various plotting packages though.

plot()  -  Create a plot object in the background which can be later displayed with display()

A note about the differences between environments would also be important.

The coding environment will also effect the usage of plot(). In the REPL or using Atom/Juno plot() creates a plot in the background whereas IJulia immediately displays the results inline. If an environment is not displaying a plot as expected try using display() or checking the defaults of the plotting package.

Chris' suggestion about putting something in "Noteworthy Differences from Other Languages" is good too.

Tom, in what way am I forcing my perspective? Some portion of the Julia community will see it this way so it's important to take it into consideration.

[CrocoDuck O'Ducks]

Just a couple of cents from a newbie. I come from Matlab as well and I really love the way Julia works actually. There are many cases in Matlab where I get plots when I don't really ask for them and I end up with slow code and the need to close programmatically windows on the screen to avoid to have it covered with stuff. I am not sure I can find an example right now (I have few somewhere in my stuff) but functions like thd(), freqz() and so on generate plots that I too often have to deal with. I prefer to be able to programmatically decide whether or not display stuff instead to work around a default that easily slows things down and makes code less clean and harder to read, with "plotting correction" lines just in the middle of the ones doing the actual computations... Just my preference.

[Penn Taylor]

In addition to differing interpretations of the verb "plot", as Tom mentioned, this discussion may also be rooted in a difference between how one would expect this to work in a functional- versus an imperative paradigm. That would help explain why the same behavior appears to be consistent to one group and inconsistent to the other.

FWIW, I came to Julia from Mathematica; the plotting/displaying behavior here is consistent with that. I have yet to run up against what I would consider to be unintuitive behavior around plotting.