Unable to open inline window for plotting

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

@GillesDuvert

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

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

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.

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

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.

@GillesDuvert

@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" />

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)

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.

@ShamrockLee

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

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

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

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

@vit1-irk

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

@GillesDuvert

@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?

@olebole

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

I compiled GDL v1.0.0-rc.3 on Archlinux. The old Debian patch is included here, but nothing else changed, situation still like that:

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.

To solve this issue, it's needed to reproduce the whole build process (also with all package versions described) from Debian workflow. Maybe connect here both AUR and Debian packagers. I'd like to see gdl_kernel functional in every distribution and to have clear description how to make it work well

Any help in improving the package freshness very welcome, see: gnudatalanguage/gdl#761

All options I use on Debian are here (so, not explicit *MAGICK=ON), and the build dependencies (above essentials like gcc) are here. I don't know whether the inline window works here; this would need to be tested.

The most I achieved with Archlinux and GDL 1.0 is this build config:

 cmake -DCMAKE_INSTALL_PREFIX=/usr \
		-DHDF5=NO \
		-DHDFDIR=/opt/hdf4 \
                -DFFTW=YES \
                -DLIBPROJ4=YES \
                -DGRAPHICSMAGICK=ON -DMAGICK=ON \
                -DGLPK=YES \
		-DPYTHON=YES \
		-DPYTHONVERSION=3 \
		-DPYTHON_MODULE=NO \
		-DWXWIDGETS=YES \
		-DGRIB=YES \
		-DQHULL=YES \
		-DUDUNITS=YES \
		-DPSLIB=YES ..

and this dependency config:

depends=('python'
         'python-numpy'
         'plplot'
         'glpk'
         'shapelib'
         'gsl'
         'readline'
         'hdf4'
         'hdf5'
         'netcdf'
         'netcdf-cxx'
         'wxgtk'
         'fftw'
         'pslib'
         'eccodes-git'
         'udunits'
         'eigen-git'
         'libtirpc'
         'libmagick6'
         'libgeotiff')

One note: when compiling with -DPYTHON_MODULE=YES, gdl doesn't create executable, it overrides it with some symlink (there is a bug in gdl_symlink target in cmake config, it should just copy the file on every platform, not deal with buggy symlinks when it's not needed), so I had to switch the setting from NO to YES several times to make it build.

It turned out that default --use-wx config for gdl_kernel works perfectly, still no inline window support and no results with /pixmap windows

IDK what to do for now

Remove .txt extension and test the build with makepkg -fi

PKGBUILD.txt
cmake-patch.patch.txt
gdl.profile.txt

Navigation Menu

Repository navigation

Unable to open inline window for plotting #8

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unable to open inline window for plotting #8

Description

Activity

slayoo commented on Dec 15, 2020

vit1-irk commented on Dec 15, 2020

GillesDuvert commented on Dec 15, 2020

vit1-irk commented on Dec 16, 2020

GillesDuvert commented on Dec 16, 2020

ShamrockLee commented on Dec 17, 2020

GillesDuvert commented on Dec 17, 2020

GillesDuvert commented on Dec 17, 2020

vit1-irk commented on Dec 17, 2020

GillesDuvert commented on Dec 17, 2020

vit1-irk commented on Dec 18, 2020

vit1-irk commented on Dec 18, 2020

GillesDuvert commented on Dec 18, 2020

vit1-irk commented on Dec 19, 2020

slayoo commented on Dec 19, 2020

vit1-irk commented on Dec 19, 2020

slayoo commented on Dec 19, 2020

olebole commented on Dec 20, 2020

vit1-irk commented on Dec 31, 2020

vit1-irk commented on Dec 31, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions