Build PLPLOT with patches !!!

[GillesDuvert]

GDL is definitely hampered by plplot limitations and bugs.
PLPLOT seems to be deaf to our demands of corrections.
It would be quite a task to replace PLPLOT by someting of our own. Not impossible but not a true priority either.
We already have replaced buggy plplot drivers by our own patched version, at the expanse of needing plplot to be compiled with a -DYNDRIVERS option not generally used by plplot providers. On OSX for example we install ourselves our PLPLOT with dyndrivers.
It is quite easy to provide patches for plplot for the known bugs and defects. We must compile a local version of a patched plplot library with our cmake procedure and use it in GDL.
I list here the main points:

• dyndrivers, only a handful of options (no fortran, lua, ada, strange drivers, etc)
• number of windows from 100 to 1000
• all the bugs signaled by us on the plplot sourceforge patched.
• static strings length ported from 40 (!!) to 1000.

[alaingdl]

Hi @GillesDuvert

Not sure it is an issue or a discussion ! 😺

Let' be clear : on my side, with a very very limited amount of time for contributing to GDL last years but using it on a daily basis for processing data, PLPLOT is not a big problem as long as the X11 version is reliable & fast. (the quality of the wxwidget output is not good on my screen, I don't know why)

The problems or limitations I have/see :

• SHADE_SURF is broken (but may just not OK/not possible within PLPLOT)
• size & quality of the PostScript outputs :(

The good points :

• working through the network
• fast
• SVG outputs (very very good !)

If you consider to have a local version as we have now in the script for QHULL, it would be great that it is possible
to put it in a given place (with a PLPLOT_DIR) to compile it only one time. I have several (large) versions of GDL around and it is very convenient for looking for regressions, but I don't want to compile each time the same version of PLPLOT (and it would be great to have that for QHULL too ...)

[GillesDuvert]

SHADE_SURF is impossible with current plplot. A plplot patch could provide it.
Size and quality of the PS outputs have been well improved by the last PR.
SVG output is indeed good but at the time, confidential.
X11 is alas deprecating.

[opoplawski]

PLplot fails to build with Python 3.13, and so has not been built for the upcoming Fedora 41 release - breaking GDL as well. I might be able to get a bit of time to fix it (it doesn't seem too bad) - but this is likely just the tip of the iceberg. There have been no replies to my messages on the PLplot devel list and no other activity since Aug 2023.

If GDL wants to continue to use it, I think you may be forced to fork and maintain it.

[GillesDuvert]

Thanks Orion,
Separately I envisioned to make a very light version of plplot that would be maintainable by us. Gdl using only the most basic functions of plplot. Your message is a great incentive.

[brandy125]

yeah, would be nice if plplot would come with gdl already.

…

On 14. Sep 2024, at 12:45, Giloo ***@***.***> wrote: Thanks Orion, Separately I envisioned to make a very light version of plplot that would be maintainable by us. Gdl using only the most basic functions of plplot. Your message is a great incentive. — Reply to this email directly, view it on GitHub <#1654 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOC5K6A6KRT3XUIRTBL55N3ZWRKYLAVCNFSM6AAAAAA6KBAYIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJRGAZTQMBXGY>. You are receiving this because you are subscribed to this thread.

[opoplawski]

FWIW - it was relatively easy to fix plplot to build with Python 3.13 (https://sourceforge.net/p/plplot/plplot/merge-requests/5/), but it does seem like plplot is pretty dead upstream.

[GillesDuvert]

#1886 will do the job