Unable to open inline window for plotting

[vit1-irk]

After displaying this message, 2 windows opens, one from wxWidgets, another GDL native. But both are empty and don't show anything. !inline=1 also doesn't help, displays the same message

[slayoo]

@GillesDuvert Would it mean that plplot wx driver was compiled against different wx version than GDL itself?

[vit1-irk]

Btw, I compiled all the dependencies including plplot and GDL itself from AUR. Other dependencies are latest from Arch repositories.

[GillesDuvert]

I've done a few tests.
launching a jupyter-notebook on my laptop, I can have plots in the notebook but I see a regular GDL x11 window flashing. This is silly, we just have to create /PIXMAP windows in the GDL code when !inline==1 .
This can be tested by asking in the notebook window,0,/pixmap & plot,dist(32) . No trouble anymore.

Now, as jupyter GDL opens a window, and not a pixmap, then we're back to the old big problem of not correctly updated distributions, where the plplot driver insists on making its own window.

[vit1-irk]

When I try window,0,/pixmap, GDL prints the same error and shows wxWidgets window which freezes and doesn't respond. Plotting then takes no effect. X11 window is absent this time

[GillesDuvert]

Mmmm, I do not have this behaviour. But also, I do not have the same configuration.
I see the default WINDOW (say, device) is wxWidgets. this because at line 69 in the python code there is
self._child = spawn(self._executable+' --use-wx ',timeout = 300, encoding='utf-8')
by removing the --use-wx you may have a better result.
self._child = spawn(self._executable,timeout = 300, encoding='utf-8')

The intent about forcing the wxWidgets use is that thewxWidgets device makes better plots than the X11, with antialiasing etc. But of course this was under condition the wxWidgets plplot driver and GDL would work together smoothly. Which is probably the case only with GDL 1.0rc and wxWidgets3.

Could you try with this patch?
Obviously the plot should be directly made with the SVG driver when !inline==1 not using a silly interactive X11 or wxWidgets driver but that's another story.

[ShamrockLee]

@GillesDuvert It is plotted successfully after applying the patch, but the result isn't inline anyway.

Workaround:

GDL cell

imgName = "path/to/img.png"
plot, your, graph
writePng, imgName, tvrd()

Markdown cell

<img src="path/to/img.png" />

[GillesDuvert]

Hello,
Sorry for the double comment. The last part was about doing it better inside GDL, as a suggestion to anyone willing to spend a few hours doing this in the GDL code. I'll develop this idea (using SVG instead of a complicated X11 to PNG transformation) further below.
My temporary patch was to remove the +' --use-wx ' in the gdl_kernel.py file.
This, I guarantee, will enable inline plots (unless there is another problem with plpot X11 or WIN drivers)

[GillesDuvert]

Now, for the record, the kernel uses GDL with the default window type (SET_PLOT="X") which is somehow converted to a png 'screen copy' and inserted in the browser page below the code line that made it.
This is ugly because the default driver is plplot's X11 driver, very oldstyle, the png makes pixels and the vector structure is lost in the process. Using wxWidgets amounts to the same.
If, by detecting the !inline value, GDL is persuaded to use as device a SVG device (must be redefined internally as a multi-window device, but this is just a simple object inheritance trick), then the output is directly in an ebeddable format, that has the advantage to be vectorial (one can zoom, change the browser page size etc) and the looks will be ten times better.
Incidentally, if wxWidgets was persuaded to have a browser-widgets version, GDL widgets could get an equivalent in a jupyter.

[vit1-irk]

Removing --use-wx does the trick and allows to plot something, but if I try to plot in inline mode, Jupyter output is just empty

Also, I tried to use tvrd and write_png as @ShamrockLee suggested a workaround, but no luck either. GDL produces no output, the same code written in command line mode shows that:

% Compiled module: WRITE_PNG.
% WARNING: your version of the ImageMagick library will truncate images to 16 bits per pixel
gdl: magick/image.c:3215: SetImageOpacity: Assertion `image->signature == MagickCoreSignature' failed.

After that GDL crashes (with emergency stop or segmentation fault). My Imagemagick is version 7.0.10.48-1

[GillesDuvert]

Works for me.
Must be some other reason.
Did you get the very last version of the kernel from this GitHub pages?

[vit1-irk]

Sure, it's the latest kernel from this repository.

I attempted to run the example on different distribution (Debian sid) where GDL is precompiled and it's precompiled against GraphicsMagick 1.3.35 instead of ImageMagick (Archlinux AUR), and it works for inline plots

I will try to build GDL on Archlinux with GraphicsMagick and will tell the result

[vit1-irk]

So, I tried to recompile GDL with options -DGRAPHICSMAGICK=ON -DMAGICK=ON. Plotting in separate window works, as well as saving to PNG works. Still no inline plots are displayed. If I try to plot with !inline=1 or /pixmap, the Jupyter outputs are empty.

// Also, on Archlinux, you need to include this Debian patch, otherwise GDL will crash

It appears that for now GDL in combination with gdl_kernel is fully functional only on Debian configurations

[GillesDuvert]

@vit1-irk , thanks for these returns. I'm confused because the above patch is already in GDL since May 1, 2019.

[vit1-irk]

@GillesDuvert

I'm confused because the above patch is already in GDL since May 1, 2019.

Both Debian and Archlinux AUR versions use GDL 0.9.9, which was released earlier. Are you suggesting to try latest release candidate?

[slayoo]

Debian does have newer versions (thanks to @olebole !):
https://metadata.ftp-master.debian.org/changelogs//main/g/gnudatalanguage/gnudatalanguage_1.0.0~rc.3-1_changelog