0.7 is using Plots v0.19.3 whereas 1.0 is using Plots v0.20.2

[JeffFessler]

I am using 0.7 because the deprecation warnings are helpful, but I just noticed that some issues that have been fixed with Plots under 1.0 are still broken in 0.7 because 0.7 is using Plots v0.19.3 whereas 1.0 is using Plots v0.20.2. (I did ]rm Plots and ]add Plots in both to make sure I was starting fresh).

I am not sure if this is the right forum for asking this question, but does anyone know why 0.7 is using such an older version of Plots? I would have expected them to be more in sync...

[mkborregaard]

Simply because we drop support for older julia versions on principle when a new version comes up. It's a very nice and unintrusive way to ensure that all the components of the juliaPlots ecosystem are in sync (version sync problems, in particular with backends, is one of our biggest headaches).

[JeffFessler]

Thanks for the reply. I thought that 0.7.0 and 1.0.0 were going to be in sync indefinitely (other than deprecation warnings)) but that was probably wishful thinking. Time to wean from 0.7 then...

[brenhinkeller]

Sounds like word from @JeffBezanson is indeed that both versions should be supported together due to the special nature of the 0.7 release.

Is there any technical reason to prevent this? I can testify that I also would have been able to benefit more from the deprecations in 0.7 if Plots worked as well in Atom/Juno in 0.7 as it does in 1.0

[mkborregaard]

Yes there's a technical reason, which is that RecipesBase had a major breaking change on the 0.7/1.0 transition. And, 0.7 IS supported, we're just not developing Plots actively for it. If you run into one of those improvements that has come to Plots since the 1.0 update you may notice a difference, though I'm not sure which Juno issue you are referring to.

[brenhinkeller]

For me it's that figures in the Plots pane are about one square inch and can't be enlarged. I just ran this to make sure it's still the case - here's a screenshot:

This seems to occur whether or not I specify default(fmt = :svg) or default(fmt = :png). Maybe there's a fix for this that I couldn't find at the time though. For reference versioninfo is

Julia Version 0.7.0
Commit a4cb80f3ed (2018-08-08 06:46 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin14.5.0)
  CPU: Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, haswell)
Environment:
  JULIA_EDITOR = atom -a
  JULIA_NUM_THREADS = 4

and

  [c52e3926] Atom v0.7.6
  [91a5bcdd] Plots v0.19.3
  [28b8d3ca] GR v0.35.0
  [e5e0dc1b] Juno v0.5.3

[mkborregaard]

wow, I really don't see why that should happen for the fmt = :png case, but I take it you are sure? You only get this with gr(), right?

[brenhinkeller]

Let me check

[brenhinkeller]

Hmm, not even unique to gr(); for me

using Plots; plotly(); default(fmt = :png)
plot(1:10,rand(10),seriestype=:scatter)

gives

edit: this just wasn't refreshing the plots pane at all.

using Plots; plotly(); default(fmt = :png)
h = plot(1:10,rand(10),seriestype=:scatter)
display(h)

works fine, but opens the plot in the browser rather than the plots pane

[brenhinkeller]

I also get:

but

using Plots; gr(); default(fmt = :png)
h = plot(1:10,rand(10),seriestype=:scatter)
savefig(h,"test.pdf")

is ok (screen is still tiny, but saved pdf is fine)

also

julia> @which default
Plots

so that's ok

[mkborregaard]

Weird. The plotly error is different, it's just the backend not being fully 1.0 compliant yet.
@pfitzseb do you have any idea what could cause the tiny plot in Juno, backend-independent?

[brenhinkeller]

Ah! This is different. After adding PyPlot and dependencies

using Plots; pyplot(); default(fmt = :png)
plot(1:10,rand(10),seriestype=:scatter)

and

using Plots; pyplot(); default(fmt = :svg)
plot(1:10,rand(10),seriestype=:scatter)

are both fine (normal-size in plots window) albeit with a warning

julia> 'c' argument looks like a single numeric RGB or RGBA sequence, which should be avoided as value-mapping will have precedence in case its length matches with 'x' & 'y'.  Please use a 2-D array with a single row if you really want to specify the same RGB or RGBA value for all points.
'c' argument looks like a single numeric RGB or RGBA sequence, which should be avoided as value-mapping will have precedence in case its length matches with 'x' & 'y'.  Please use a 2-D array with a single row if you really want to specify the same RGB or RGBA value for all points.
'c' argument looks like a single numeric RGB or RGBA sequence, which should be avoided as value-mapping will have precedence in case its length matches with 'x' & 'y'.  Please use a 2-D array with a single row if you really want to specify the same RGB or RGBA value for all points.

gr(); still tiny though on both :png and :svg

[brenhinkeller]

Also tried restarting everything from scratch and trying again in case there was some sort of memory but

using Plots; gr(); default(fmt = :png)
plot(1:10,rand(10),seriestype=:scatter)

still gives me tiny-Plots

[brenhinkeller]

The size of the tiny-plot also scales with the dimension of the plot pane at the time of plotting, so for instance