plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] One development topic left for memqt_example [there appear to be two possible solutions to choose from!]

[Alan W. I. <Ala...@gm...>]

>>> On Tue, Jul 14, 2020 at 2:35 AM Alan W. Irwin <Ala...@gm...>
>>> wrote:
>>>
>>>> Hi António:
>>>>
>>>> [...] I have just
>>>> found
>>>> <https://stackoverflow.com/questions/51010194/qt-5-10-semi-transparent-background-on-qmainwindow-using-stylesheet>
>>>>> .
>>>> Could you please take a careful look at this reference which mentions
>>>> two possible solutions?

On 2020-07-14 11:47+0100 António Rodrigues Tomé wrote:

> Amazingly simple.
>
> here the code

Hi António:

After running

scripts/style_source.sh --apply

to style your changes, I tested them and pushed
them (git commit 3876b262c, described as plplot-5.15.0-77-g3876b262c).

It is really great you followed up on that reference and found a solution that
satisfies my long-standing semi-transparency dream for Qt5.

@others on list:

If any of the rest are interested in what we accomplished, try building
the "test_memqt_example" target and clicking on the "actions" menu for the
resulting GUI that is displayed.

@António:

For the time being, at least, I think we are done with memqt_example development,

Best wishes,

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] FindLua

[Alan W. I. <Ala...@gm...>]

On 2020-07-13 18:03-0600 Orion Poplawski wrote:

> Is cmake/modules/FindLua.cmake useful anymore?

No, and thanks for this reminder which I have just acted on.  For
further details concerning this change, see the git commit 096358394
(described as plplot-5.15.0-76-g096358394).

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] FindLua

[Orion P. <or...@nw...>]

Is cmake/modules/FindLua.cmake useful anymore?  For Fedora rawhide with 
Lua 5.4 I'm removing it so that we use the patched system version from 
cmake that can find 5.4.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[Plplot-devel] One development topic left for memqt_example

[Alan W. I. <Ala...@gm...>]

Hi António:

Please take a look at my most recent push.  The highlights are I have
committed the changed version of aurora.png that you donated, done a
substantial code cleanup, moved to linking with the plplotcxx library
rather than the plplot library, fixed some build issues, and figured
out how to enable *and* use plscolbg(a) properly for the memqt device
without compromising functionality.  Please try this method (using a
transparent Qt5 image initialization or transparent PLplot background
as needed) also for your own private examples to confirm my claim of
no compromise of functionality for this method is true.  I am pretty
sure you will like what I have done, but if you feel there is any
problem with my changes, I will try and figure it out to your
satisfaction.

Assuming you like what I have done, that leaves only one remaining
memqt_example issue as far as I am concerned.  That issue is the
proper display of the actions which are supposed to contain
semi-transparent results.  Currently, they are plotted as
semi-transparent on a white background imposed by Qt5, but that is not the correct
result as we have recently discovered by looking at pqiv results.

@everybody: for the others here I have recently discovered a method of
displaying semi-transparent PLplot plots correctly which is to use the
--transparent-background option of pqiv (that option name is a
misnomer which should have been called something like --honor-alpha since
all it does is honor the alpha channel information contained in the
image that is being displayed).

To see what this option can do, try the following to
build the relevant pngqt device and C example 11, create a
semi-transparent version of that example, and display that result
properly:

make qt
make x11c
examples/c/x11c -dev pngqt -o test.png -bg FFF_0.4 -fam
pqiv -i --transparent-background test.png.8

This works well on my Debian Buster KDE compositing desktop where the
composited result is 40 per cent PLplot result and 60 per cent
whatever is below that plot on the desktop.  However, this nice result
is not what is delivered by Qt5 because its default action is to
insert an opaque white layer as an additional background for the
semi-transparent memqt_example actions.

@António: I am not sure whether you have tried the above pqiv example
yet on your own (openSUSE) KDE compositing desktop, but I think it
should "just work" for you as well as it did for me.  Which leaves the
development topic of how to convince Qt5 to do similar correct
rendering of the semi-transparent actions of memqt_example?  Google is
no help (because of an enormous number of irrelevant hits for the
search terms "qt5 semi-transparent" (without the quotes) which discuss
creating semi-transparent results [which we already have done with
memqt_example] but those hits typically do not discuss rendering those
results properly with Qt5).  So can you use your Qt5 expertise to help
me figure out how to do this?

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] #include <QPainterPath> needed in qt.h by newer qt versions

[Alan W. I. <Ala...@gm...>]

On 2020-06-30 11:43+0100 António Rodrigues Tomé wrote:

> Hi alan
>
> Everything seems to work fine.
> In the future I'll extend the memqt example to do interesting things, this
> was only a little program i used to test the driver.
> I will also  try to replace QLinkedList in the qt drivers as  it is now
> deprecated, it will still be around for quite a while to keeping old code
> working but better to replace it, I'l do that without compromising the
> build of the drivers in older versions of qt.
>
> Thanks for the changes
>
> best regards,

Hi António:

I am glad the present test_memqt_example and memqt_example targets
that I implemented work well for you, and I look forward to your
planned future "interesting" changes to memqt_example, and any other
help you can give to keep the Qt-related parts of PLplot up to date
with Qt5.

My Qt skills are limited so my own plans for the Qt-related parts of
PLplot are simple, and I think I have mentioned them on list before.
But just to remind you (and the list), my plan is to deprecate our Qt4
support (likely for the forthcoming release) and remove it altogether
for the release after that which should very much simplify the
Qt-related part of our build system (since for Qt4 all the CMake logic
is hand-generated, while Qt5 CMake support is much better automated).
And, of course, I am quite happy to support with any CMake logic (as I
have just done) anything new for the Qt5-related parts of PLplot that
you want to implement.

Best wishes,

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] plplot fails to build with ocaml 1.08

[Orion P. <or...@nw...>]

On 5/22/20 11:32 AM, Richard W.M. Jones wrote:
> On Fri, May 22, 2020 at 10:09:31AM -0700, Alan W. Irwin wrote:
>> On 2020-05-22 16:31+0100 Richard W.M. Jones wrote:
>>
>>>
>>> Xavier changed cpp -traditional back to cpp
>>> (https://github.com/xavierleroy/camlidl/issues/18), and I have added
>>> the new camlidl 1.09 to Rawhide.
>>>
>>> I will rebuild plplot against this shortly.
>>
>> Thanks, Orion, for initiating camlidl bug 18 and Richard (and Xavier)
>> for following up on it.  From the discussion there, it sounds like all
>> is now well with unit testing of the problem, and I therefore assume
>> the above test with a full PLplot build will confirm that.  And if so,
>> kudos to everybody for figuring out this issue so swiftly.
> 
> Build here:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=44826613
> 
> Seems to be going OK so far.
> 
> Rich.
> 

Awesome, thanks Rich and everyone.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] plplot fails to build with ocaml 1.08

[Alan W. I. <Ala...@gm...>]

On 2020-05-22 16:31+0100 Richard W.M. Jones wrote:

>
> Xavier changed cpp -traditional back to cpp
> (https://github.com/xavierleroy/camlidl/issues/18), and I have added
> the new camlidl 1.09 to Rawhide.
>
> I will rebuild plplot against this shortly.

Thanks, Orion, for initiating camlidl bug 18 and Richard (and Xavier)
for following up on it.  From the discussion there, it sounds like all
is now well with unit testing of the problem, and I therefore assume
the above test with a full PLplot build will confirm that.  And if so,
kudos to everybody for figuring out this issue so swiftly.

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] plplot fails to build with ocaml 1.08

[Orion P. <or...@nw...>]

On 5/21/20 2:01 PM, Alan W. Irwin wrote:
> Hi Orion:
> 
> Thanks for your report.
> 
> On 2020-05-20 21:28-0600 Orion Poplawski wrote:
> 
>> With the update from ocaml 1.05 to 1.08 plplot now fails to build:
> 
> The ocaml versions on Debian Buster are 4.0.5* while the camlidl
> version there is 1.0.5*, and it is camlidl that failed below.
> Therefore, I assume you meant camlidl rather than ocaml above.

Indeed, sorry for the confusion.

>> [  4%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml, 
>> plplot_core_stubs.c, plplot_core.h
>> cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && 
>> /usr/bin/cmake -E copy 
>> /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml/plplot_core.idl 
>> /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml/plplot_core.idl
>> cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && 
>> /usr/bin/camlidl -I /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml 
>> -header plplot_core.idl
>> File plplot_core.idl, line 369, column 13: Illegal character #
>>
>> This line is:
>>
>> RAW_ML(external plgriddata : float array -> float array -> float array 
>> -> float array -> float array -> plplot_grid_method_type -> float -> 
>> float array array = "ml_plgriddata_bytecode" "ml_plgriddata")
>>
>> The macros involved are:
>>
>> #define QUOTEME(x) #x
>> #define RAW_ML(x) quote(mlmli, QUOTEME(x));
>>
>> Now, I know nothing about ocaml so I'm hoping Richard can clue us in 
>> on what has changed.
> 
> For your information, here is the effect of the RAW_ML macro (as 
> generated by
> camlidl Version: 1.05-15.1 on Debian Buster = Stable).
> 
> software@merlin> grep -i plgriddata plplot_core* |grep -iv binary
> plplot_core.idl:// Hand-translated PL_GRID_* flags for use with plgriddata
> plplot_core.idl:RAW_ML(external plgriddata : float array -> float array 
> -> float array -> float array -> float array -> plplot_grid_method_type 
> -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata")
> plplot_core.ml:external plgriddata : float array -> float array -> float 
> array -> float array -> float array -> plplot_grid_method_type -> float 
> -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata"
> plplot_core.mli:external plgriddata : float array -> float array -> 
> float array -> float array -> float array -> plplot_grid_method_type -> 
> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata"
> 
> So RAW_ML appears to do what its name implies (generate an exact copy in 
> the relevant output files
> generated by camlidl).  But my OCaml (and camlidl) knowledge is pretty 
> limited as well so
> I don't understand (at all) how that simple result is implemented with
> the macros
> 
> #define QUOTEME(x) #x
> #define RAW_ML(x) quote(mlmli, QUOTEME(x));
> 
> So I also hope you can get help from Richard on how this result is
> generated, but since the result is so simple, my best guess is this
> issue is due to a bug in the particular pre-release 1.0.8 version that
> Fedora has decided to package.
> 
> I am tied up with a large number of different projects for the next
> month or so.  But when I get a free moment (and if this Fedora issue
> has not been resolved by then), I will attempt to obtain the latest
> camlidl from <https://github.com/xavierleroy/camlidl> to see if I can
> replicate the issue you have found.
> 
> N.B. from the latest commit message there, 1.0.8 hasn't actually been
> released yet.  Therefore, if the issue is because of a bug in the
> particular pre-release version of camlidl that Fedora has packaged,
> then it is alway possible that Xavier Leroy has already fixed this bug
> in a later pre-release version.  But if changing the Fedora package to
> the latest pre-release version does not fix the current issue, then I
> would recommend you contact Xavier Leroy about this issue to see if he
> can fix it before he releases 1.0.8.
> 
> Good luck, and let me know how it goes.
> 
> Alan

I've filed this with camlidl:

https://github.com/xavierleroy/camlidl/issues/18

hopefully they can help.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] plplot fails to build with ocaml 1.08

[Orion P. <or...@nw...>]

On 5/21/20 3:01 AM, Richard W.M. Jones wrote:
> On Wed, May 20, 2020 at 09:28:10PM -0600, Orion Poplawski wrote:
>> With the update from ocaml 1.05 to 1.08 plplot now fails to build:
> 
> 4.05 -> 4.08 ?

Sorry, ocaml-camlidl 1.05 -> 1.08 .  No ocaml change directly.


> 
>> [  4%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml,
>> plplot_core_stubs.c, plplot_core.h
>> cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml &&
>> /usr/bin/cmake -E copy
>> /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml/plplot_core.idl /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml/plplot_core.idl
>> cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml &&
>> /usr/bin/camlidl -I
>> /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml -header
>> plplot_core.idl
>> File plplot_core.idl, line 369, column 13: Illegal character #
>>
>> This line is:
>>
>> RAW_ML(external plgriddata : float array -> float array -> float
>> array -> float array -> float array -> plplot_grid_method_type ->
>> float -> float array array = "ml_plgriddata_bytecode"
>> "ml_plgriddata")
>>
>> The macros involved are:
>>
>> #define QUOTEME(x) #x
>> #define RAW_ML(x) quote(mlmli, QUOTEME(x));
>>
>> Now, I know nothing about ocaml so I'm hoping Richard can clue us in
>> on what has changed.
> 
> I compiled plplot from git fine using OCaml 4.11 prerelease, so
> probably the easiest thing is to move to the latest git version.
> 
>    mkdir build
>    cd build
>    CFLAGS="%{optflags}" cmake .. -DENABLE_ocaml:BOOL=ON
>    make
> 
> Nothing has changed significantly under bindings/ocaml/ for a long
> time, so I don't know why specifically it works from git and not from
> the Fedora build.  Maybe one of the huge number of cmake flags?
> 
> Rich.
> 

I suspect without ocaml-camlidl-devel installed it won't build the above 
code.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] plplot fails to build with ocaml 1.08

[Alan W. I. <Ala...@gm...>]

On 2020-05-21 10:01+0100 Richard W.M. Jones wrote:

> On Wed, May 20, 2020 at 09:28:10PM -0600, Orion Poplawski wrote:
>> With the update from ocaml 1.05 to 1.08 plplot now fails to build:
>
> 4.05 -> 4.08 ?

Hi Richard:

Your messages are being rejected by the list for obvious reasons (no subscription),
but I do have access to them as list coordinator so I will answer (with
a copy to the list).

No, the above problem in version numbers was because Orion misidentified
the package which is camlidl and not ocaml.
[...]
> Nothing has changed significantly under bindings/ocaml/ for a long
> time, so I don't know why specifically it works from git and not from
> the Fedora build.  Maybe one of the huge number of cmake flags?

The issue was with the camlidl command.  But according to Debian
packaging information that application depends on the ocaml-nox
package that "contains everything needed to develop OCaml applications".
Also, I have the following result:

irwin@merlin> file /usr/bin/camlidl 
/usr/bin/camlidl: a /usr/bin/ocamlrun script executable (binary data)

And ocamlrun is the OCaml byte-code interpreter.

So from your further result that everything works fine for the latest
git version of ocaml (where I assume you are still using the same
pre-release version of camlidl), it appears the issue is caused
(indirectly) by some Fedora inconsistency between their packaged
pre-released versions of camlidl and ocaml.

Anyhow, it appears the issue does not have a lot to do with PLplot (except as a platform
that exposes the issue).  So good luck solving it, and let me know how you progress.

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] plplot fails to build with ocaml 1.08

[Alan W. I. <Ala...@gm...>]

Hi Orion:

Thanks for your report.

On 2020-05-20 21:28-0600 Orion Poplawski wrote:

> With the update from ocaml 1.05 to 1.08 plplot now fails to build:

The ocaml versions on Debian Buster are 4.0.5* while the camlidl
version there is 1.0.5*, and it is camlidl that failed below.
Therefore, I assume you meant camlidl rather than ocaml above.
>
> [  4%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml, 
> plplot_core_stubs.c, plplot_core.h
> cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && 
> /usr/bin/cmake -E copy 
> /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml/plplot_core.idl 
> /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml/plplot_core.idl
> cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && 
> /usr/bin/camlidl -I /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml 
> -header plplot_core.idl
> File plplot_core.idl, line 369, column 13: Illegal character #
>
> This line is:
>
> RAW_ML(external plgriddata : float array -> float array -> float array -> 
> float array -> float array -> plplot_grid_method_type -> float -> float array 
> array = "ml_plgriddata_bytecode" "ml_plgriddata")
>
> The macros involved are:
>
> #define QUOTEME(x) #x
> #define RAW_ML(x) quote(mlmli, QUOTEME(x));
>
> Now, I know nothing about ocaml so I'm hoping Richard can clue us in on what 
> has changed.

For your information, here is the effect of the RAW_ML macro (as generated by
camlidl Version: 1.05-15.1 on Debian Buster = Stable).

software@merlin> grep -i plgriddata plplot_core* |grep -iv binary
plplot_core.idl:// Hand-translated PL_GRID_* flags for use with plgriddata
plplot_core.idl:RAW_ML(external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata")
plplot_core.ml:external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata"
plplot_core.mli:external plgriddata : float array -> float array -> float array -> float array -> float array -> plplot_grid_method_type -> float -> float array array = "ml_plgriddata_bytecode" "ml_plgriddata"

So RAW_ML appears to do what its name implies (generate an exact copy in the relevant output files
generated by camlidl).  But my OCaml (and camlidl) knowledge is pretty limited as well so
I don't understand (at all) how that simple result is implemented with
the macros

#define QUOTEME(x) #x
#define RAW_ML(x) quote(mlmli, QUOTEME(x));

So I also hope you can get help from Richard on how this result is
generated, but since the result is so simple, my best guess is this
issue is due to a bug in the particular pre-release 1.0.8 version that
Fedora has decided to package.

I am tied up with a large number of different projects for the next
month or so.  But when I get a free moment (and if this Fedora issue
has not been resolved by then), I will attempt to obtain the latest
camlidl from <https://github.com/xavierleroy/camlidl> to see if I can
replicate the issue you have found.

N.B. from the latest commit message there, 1.0.8 hasn't actually been
released yet.  Therefore, if the issue is because of a bug in the
particular pre-release version of camlidl that Fedora has packaged,
then it is alway possible that Xavier Leroy has already fixed this bug
in a later pre-release version.  But if changing the Fedora package to
the latest pre-release version does not fix the current issue, then I
would recommend you contact Xavier Leroy about this issue to see if he
can fix it before he releases 1.0.8.

Good luck, and let me know how it goes.

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] plplot fails to build with ocaml 1.08

[Orion P. <or...@nw...>]

With the update from ocaml 1.05 to 1.08 plplot now fails to build:

[  4%] Generating plplot_core.idl, plplot_core.mli, plplot_core.ml, 
plplot_core_stubs.c, plplot_core.h
cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && 
/usr/bin/cmake -E copy 
/builddir/build/BUILD/plplot-5.15.0/bindings/ocaml/plplot_core.idl 
/builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml/plplot_core.idl
cd /builddir/build/BUILD/plplot-5.15.0/fedora/bindings/ocaml && 
/usr/bin/camlidl -I /builddir/build/BUILD/plplot-5.15.0/bindings/ocaml 
-header plplot_core.idl
File plplot_core.idl, line 369, column 13: Illegal character #

This line is:

RAW_ML(external plgriddata : float array -> float array -> float array 
-> float array -> float array -> plplot_grid_method_type -> float -> 
float array array = "ml_plgriddata_bytecode" "ml_plgriddata")

The macros involved are:

#define QUOTEME(x) #x
#define RAW_ML(x) quote(mlmli, QUOTEME(x));

Now, I know nothing about ocaml so I'm hoping Richard can clue us in on 
what has changed.


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[Plplot-devel] Expanding the PLplot contract test to more platforms

[Alan W. I. <Ala...@gm...>]

CMake contract tests are a useful but obscure possibility with CMake.
They implement an informal test contract between CMake developers and
some software package developer to test the latest development version
of CMake every night in the standard way supplied by cmake with one
additional "contract" test added that that downloads, configures,
builds, and installs the software package using that latest
development version of CMake.  The results are automatically collected
by the ctest component of CMake as a dashboard that is uploaded to the open.cdash.org dashboard server
with results displayed at
<https://open.cdash.org/index.php?project=CMake>.

What CMake developers get out of such contracts is an integrated test
of CMake for a whole build system (as opposed to their normal "unit"
tests that just test tiny bits and pieces of CMake functionality).
What developers for a given package get out of such contracts is
nightly confirmation that a certain version of their software
identified by commit id works for the latest development version of
CMake.  The joint advantage for CMake and software package developers
is this contract process finds early in the CMake development process
bad CMake development ideas that would break the software package's
build system even if the unit tests are succeeding.

Currently, CMake implements contract tests for PLplot and two other
software packages as can be seen from

software@merlin> ls Tests/Contracts/
Home.cmake  PLplot/  Trilinos/  VTK/

And if you check the above dashboard for "merlin" (the name of my
computer) you will see that the PLplot contract test is currently
succeeding for the commit id "plplot-5.15.0" (i.e., the latest release
of PLplot) on my Debian Buster=Stable platform.  However, if you
explore the calendar options at that site you will also discover that
the "merlin" PLplot contract test failed in recent times for several
weeks due to what turned out to be a faulty cable modem for my home
computer.  But once that modem was replaced the "merlin" PLplot
contract test started succeeding again just like it has done ever since
the release of 5.15.0 and also (with commit-id "plplot-5.14.0") between
the 5.14.0 and 5.15.0 releases.

And just like in those previous release cycles I plan late in this current
plplot-5.16.0 release cycle to do a preliminary contract test for some
near-release commit id that will be changed to "plplot-5.16.0" just
after that release.

Of course, the PLplot contract test I am running only tests our build
system against the latest CMake development version for just my
platform, and expanding that test to more platforms would be
substantially strengthen this test of both PLplot and CMake.

So if you are interested in helping out with that desired expansion, I
have attached my notes (README.gz) (and also the key configuration
file, my_dashboard.cmake.gz, referred to by those notes) on how I set
up (with a lot of initial help from Brad Kind) the above "merlin" PLplot
contract test on my own computer.  Assuming you understand those notes
and the documentation referred to by those notes, then then all you
really need to participate further is network connectivity and the
ability to build and install PLplot automatically at the time you
choose in the (24-hour) day to perform this "Nightly" test (typically
with crontab on Unix computers and the equivalent of that on Windows
systems that is referred to by the contract test documentation.) And,
of course, you should make sure that the name you choose to describe
your computer in my_dashboard.cmake does not name-clash with all the
other computer names (including "merlin") that show up at the above
dashboard URL.

If you are interested in helping out with both PLplot and CMake
testing in the way I have described above for any platform
for PLplot that interests you, I would be happy to help
you with any further questions you may have.

Alan
__________________________
Alan W. Irwin

Research affiliation with the Department of Physics and Astronomy,
University of Victoria, Victoria, BC, Canada.

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] ndiff software commit

[Alan W. I. <Ala...@gm...>]

On 2020-03-02 10:02-0500 Hazen Babcock via Plplot-devel wrote:

>
> Hello,
>
> The ndiff software commit (a974e9802cc0b54ed33d9078b7767b29286c5684 I
> believe) added a lot of files and directories in the utils/ndiff
> directory that appear to be output files (checkXYZ.xyz). Perhaps this
> was a mistake?

Hi Hazen:

I implemented the CMake-based build system for ndiff years ago so to
answer your question I needed to take a quick look at the test part of
that build system again to confirm all was well.  If you look at the
test logic in ndiff/CMakeLists.txt the bash script ndiff_check.sh that
is configured refers to $1.xyz where xyz takes on the values "err",
"out", "opt", "in1", "in2".  Furthermore, if you look further at
ndiff/CMakeLists.txt that $1 argument to the script takes on the
values check001 through check009, and check010 through check026.

So from this quick check it appears the files you refer to are a
legitimate part of the test system so including them in the
commit was the right thing to do.

But thanks for asking because two heads are much better than
one, and you will likely catch one of my commits that needs fixing
some day.  But just not today.  :-)

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] ndiff software commit

[Hazen B. <hba...@ma...>]

Hello,

The ndiff software commit (a974e9802cc0b54ed33d9078b7767b29286c5684 I
believe) added a lot of files and directories in the utils/ndiff
directory that appear to be output files (checkXYZ.xyz). Perhaps this
was a mistake?

best,
-Hazen

Re: [Plplot-devel] D language support topic

[Alan W. I. <Ala...@gm...>]

I have just pushed plplot-5.15.0-46-gd6670a304

The principal change here is I have improved the test_d implementation
to make it conform more closely to what I have planned for -pthread
handling for the plplot project case.  In addition, I have updated
the test_d README file to reflect the fact that the -Xcc feature
for dmd that we need for -pthread handling for that D compiler has
evolved from an experimental dmd feature to mainstream (on the dmd git
master branch and scheduled to be part of the dmd 2.089.0 release on
November 1st).  In addition, I have substantially updated the instructions
concerning how to build that master branch version of dmd.

This version of test_d shows no regressions compared to the previous
version and like that version continues to force use of -pthread on
most platforms (e.g., Linux, Mac OS X, and MSYS2) to provide a strong
test with this project that truly reflects the -pthread handling needs
of the plplot project.

@Takeshi: I am sorry it took me so long to mature test_d, but now that
has occurred could you please test the (updated) test_d project on your
Mac OS platform following what the (updated) cmake/test_d/README file
says?  Note in order to do this test (and also to test the plplot
project later) you will need a CMake version built from a recent
master branch (I think you already have that) and similarly for dmd.

For your convenience I have attached my current bash script for
building dmd.  I suggest (after looking through it to confirm that
what it does is consistent with the build instructions in the above
README file) you run it in a dedicated directory (so the git clones
that occur and the creation of the install subdirectory that contains
the install tree don't mess up anything else) as follows:

./dmd_git_build.sh HEAD

to build dmd and associated libraries for the HEAD of the master
branch of the set of four repositories that are required.  Note, the
script takes a lot of care so that you can run the same command days
later (to get access to the latest HEAD master branch result on that
day) without stale file issues from the previous build within
the same dedicated directory.

Good luck, and let me know how it goes with the required dmd build
(unless you want to wait for (a) the dmd 2.089.0 release on November
1st and (b) the MacPorts packaging of that release that will
presumably be finished substantially later).  And once that build
is done, I am, of course, interested in your comprehensive test
results for the (substantially updated) test_d project.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] D language support topic (success for test_d on Darwin!)

[Alan W. I. <Ala...@gm...>]

On 2019-09-24 17:24-0700 Alan W. Irwin wrote:

> But the other issue (where our various thread library needs are met by
> the -pthread *compiler* option used for linking which neither dmd nor
> ldc2 understands) has proved much more difficult to solve (even though it
> is extremely easy to solve the issue by hand) *within the current
> constraints imposed by CMake*.

See <https://gitlab.kitware.com/cmake/cmake/issues/19757> for a CMake
feature request that would elegantly solve this issue.  But meanwhile,
I have implemented (commit ab8a90546 git-described as
plplot-5.15.0-44-gab8a90546) for the test_d project a workaround for
the current lack of am implementation for the 19757 feature
request. That workaround gives good results for dmd and ldc2 for an
updated test_d project and gdc (which does not require the workaround)
continues to work well for that updated test_d where (as in the plplot
project case) the test_d C library is linked with the -pthread option.
So this commit is a considerable step forward for test_d and
implements a workaround for the above issue that should also work
(once I implement it) for the plplot project case.

@Takeshi: would you please test the (updated) test_d project on your
Mac OS platform following what the (updated) cmake/test_d/README file
says?  Note, that file tells you how to build an extremely specific
version of dmd that has the -Xcc capability that my current D language
support for dmd needs.  This variant of dmd is being considered for
the next release of dmd, and likely the dmd developers will favor it
for inclusion the more platforms we use to test it (see the latter
part of the discussion at <https://github.com/dlang/dmd/pull/10438>
and also the on-going discussion at
<https://github.com/dlang/dmd/pull/10441>).  So we are right at the
"cutting edge" of dmd development now with a lot of care required to
build the dmd versions that we need, but in a year from now I am
hoping that the -Xcc dmd capability is just part of mainstream dmd
versions that are being released with no special version of dmd being
required for our D language support.

More later as I transfer from the test_d project to the plplot project
what I have learned about a solution to the above -pthread issue.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Issue with ocaml in tree tests

[Orion P. <or...@nw...>]

On 9/23/19 8:51 PM, Alan W. Irwin wrote:
> On 2019-09-22 20:06-0600 Orion Poplawski wrote:
> 
>> I'm trying to update the Fedora plplot package to 5.15.0 but running 
>> into the problem that the build tree rpath is not being set:
>>
>> plplot-5.15.0/fedora/examples/ocaml/CMakeFiles/target_x13ocaml.dir/build.make: 
>> cd /home/orion/fedora/plplot/plplot-5.15.0/fedora/examples/ocaml && 
>> /usr/bin/ocamlopt.opt -g -I 
>> /home/orion/fedora/plplot/plplot-5.15.0/fedora/bindings/ocaml -ccopt 
>> "-L /home/orion/fedora/plplot/plplot-5.15.0/fedora/src -Wl,-rpath -Wl, 
>> " plplot.cmxa -o x13ocaml x13.ml
>>
>>
>> The problem is we build with USE_RPATH=OFF but the ocaml_RPATH 
>> variables are only set with USE_RPATH=ON.  I think we want a special 
>> case to always set the build_*_RPATH variables.
> 
> Hi Orion:
> 
> Good catch.  This build-system bug for the combination of ocaml and
> -DUSE_RPATH=OFF in the core build tree is now fixed in the git commit
> described (using "git describe master") as
> plplot-5.15.0-37-g6b215267e.
> 
> Alan


Thanks.  That does the trick.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] D language support topic (success for test_d on Darwin!)

[Alan W. I. <Ala...@gm...>]

On 2019-09-15 15:35-0700 Alan W. Irwin wrote:

> Hi Takeshi:
[...]
> I would appreciate you
> testing that result [plplot-5.15.0-34-g6b47c717e] for the test_d project (to make sure my further
> one-line change I committed beyond what you have tested already did
> not screw anything up) and also (if that test is a success) the plplot
> project itself.

For the others here I subsequently contacted Takeshi (and Arjen for
the MSYS2 case) off list to put those tests on hold because I wanted
to fix some additional issues I discovered when I attempted to
comprehensively test ldc2 and dmd on Linux for a PLplot with all
possible Linux components configured (as opposed to the good
comprehensive tests results on my Linux platform that I get
for a PLplot where only the C and D components were
configured).

The rest of this post is a status report on the remaining D build-system
issues for a fully configured PLplot on Linux.

I solved one of the issues (where Qt5 was polluting the D builds in
the static case with the -fPIC compile option which ldc2 did not
understand) by using the target_link_libraries PRIVATE option for the
static library build.

But the other issue (where our various thread library needs are met by
the -pthread *compiler* option used for linking which neither dmd nor
ldc2 understands) has proved much more difficult to solve (even though it
is extremely easy to solve the issue by hand) *within the current
constraints imposed by CMake*.  For those interested, I have just
posted a detailed report about this CMake-based build-system limitation
and a possible feature request to solve it at
<https://cmake.org/pipermail/cmake-developers/2019-September/031239.html>.

As part of writing up that post today, I thought up a workaround for
the issue that is a bit messy (since part of the workaround requires
an extra library called PLPLOT::plplot_nothread to be built that is
exactly the same as PLPLOT::plplot except for its modified
INTERFACE_LINK_LIBRARIES property), but I think it will work until the
day (if it ever comes) when the CMake developers decide to implement
the above possible feature request.

In sum, at least I finally have a plan to work around this issue,
and (because a fair amount of build-system changes will be required) I
hope to implement that plan (unless the CMake developers advise me of
a simpler way to do the same thing) by (very roughly) the end of this
week.  Furthermore, the hold on non-Linux platform testing of D language
support should continue for both Takeshi and Arjen until I demonstrate
that the three D compilers all pass comprehensive testing of a fully
configured PLplot on my platform.

So until then...

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Issue with ocaml in tree tests

[Alan W. I. <Ala...@gm...>]

On 2019-09-22 20:06-0600 Orion Poplawski wrote:

> I'm trying to update the Fedora plplot package to 5.15.0 but running into the 
> problem that the build tree rpath is not being set:
>
> plplot-5.15.0/fedora/examples/ocaml/CMakeFiles/target_x13ocaml.dir/build.make: 
> cd /home/orion/fedora/plplot/plplot-5.15.0/fedora/examples/ocaml && 
> /usr/bin/ocamlopt.opt -g -I 
> /home/orion/fedora/plplot/plplot-5.15.0/fedora/bindings/ocaml -ccopt "-L 
> /home/orion/fedora/plplot/plplot-5.15.0/fedora/src -Wl,-rpath -Wl, " 
> plplot.cmxa -o x13ocaml x13.ml
>
>
> The problem is we build with USE_RPATH=OFF but the ocaml_RPATH variables are 
> only set with USE_RPATH=ON.  I think we want a special case to always set the 
> build_*_RPATH variables.

Hi Orion:

Good catch.  This build-system bug for the combination of ocaml and
-DUSE_RPATH=OFF in the core build tree is now fixed in the git commit
described (using "git describe master") as
plplot-5.15.0-37-g6b215267e.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Issue with ocaml in tree tests

[Orion P. <or...@nw...>]

I'm trying to update the Fedora plplot package to 5.15.0 but running 
into the problem that the build tree rpath is not being set:

plplot-5.15.0/fedora/examples/ocaml/CMakeFiles/target_x13ocaml.dir/build.make: 
  cd /home/orion/fedora/plplot/plplot-5.15.0/fedora/examples/ocaml && 
/usr/bin/ocamlopt.opt -g -I 
/home/orion/fedora/plplot/plplot-5.15.0/fedora/bindings/ocaml -ccopt "-L 
/home/orion/fedora/plplot/plplot-5.15.0/fedora/src -Wl,-rpath -Wl, " 
plplot.cmxa -o x13ocaml x13.ml


The problem is we build with USE_RPATH=OFF but the ocaml_RPATH variables 
are only set with USE_RPATH=ON.  I think we want a special case to 
always set the build_*_RPATH variables.


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Plplot-devel] D language support topic (success for test_d on Darwin!)

[Alan W. I. <Ala...@gm...>]

On 2019-09-15 09:48-0000 榎本 剛 wrote:

> Alan,
>
> The test was a success.

Hi Takeshi:

I am now taking this discussion back to the plplot-devel mailing list.

Thanks for all your work in obtaining this good D language support
test result for the test_d project for your Darwin dmd (MacPorts)
platform.  I made one additional (untested) change to Darwin-dmd.cmake
for the reasons discussed in the commit message for
plplot-5.15.0-34-g6b47c717e.  Please update your local git repository
to the latest master branch version (so you have access to that commit
and there will be no need to patch PLplot).  I would appreciate you
testing that result for the test_d project (to make sure my further
one-line change I committed beyond what you have tested already did
not screw anything up) and also (if that test is a success) the plplot
project itself.

The rest of this post concerns that further comprehensing testing of the plplot project.

That is done by changing directory to the top-level directory of the PLplot source
tree (so NOT cmake/test_d) and running

scripts/comprehensive_test.sh --help

to get a sense of what is available for that much more sophisticated comprehensive
testing script than you ran for the test_d case.

Now the thing to remember about this script is it really is
comprehensive by default.  So usually you constrain it to avoid doing
tests that are currently not relevant to some topic such as D language
support for the plplot project.

So please look in the PLplot git log for commit f7d9bec368f3 where I
demonstrate how to limit that comprehensive test to just the D
binding and examples, the svg device, and (by default since these
components are always part of testing) the core C library and the
C examples.  Of course, for that test I did a lot of special things
relevant to my own platform such as testing blanks in source-, build-,
and install-tree pathnames.  So you don't want to repeat exactly
what I did.  So instead, here is my best (informed by what you
did for test_d) guess concerning how you would modify that plplot
comprehensive test invocation for your own needs:

# Important
cd <top-level directory of PLplot source tree>

# Important, set DC environment variable to select D compiler and
# options for that compiler and set PATH environment variable to
# access a CMake version >= 3.15.20190829-g3ec986c that has (on your
# platform) the essential CMake master branch fix needed so that D
# language support works for dmd.  Also drop the interactive
# component of comprehensive testing since that is not relevant
# to D.
env DC="/opt/local/bin/dmd -v" PATH=/usr/local/cmake/bin:$PATH scripts/comprehensive_test.sh --cmake_added_options "-DDEFAULT_NO_BINDINGS=ON -DENABLE_d=ON -DDEFAULT_NO_DEVICES=ON -DPLD_svg=ON" --build_command "make -j18" --ctest_command "ctest -j18" --do_test_interactive no)

Note that script run will be noticeably longer (but likely not too bad
because of all the above constraints limiting the test) compared to
the test_d script run because this script does much more than happens
for test_d (for example running all the PLplot C and D examples and
comparing those results for 15 different combinations of 2
test_noninteractive tests + 2 ctests + 1 traditional test (for 5 tests
in all) for our 3 different major configurations.

As with test_d, regardless of whether that script run is a success or
not, please collect the report tarball (which by default will be
stored in a different prefix area than in the test_d case) and send it
to me for further analysis.

Good luck with this (PLplot) constrained comprehensive test which when
it is a success will demonstrate improved D language support for both
the upstream version of PLplot that I have been helping to maintain
and ultimately the MacPorts port of PLplot that you have been
maintaining.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Patch set for postscript driver

[Alan W. I. <Ala...@gm...>]

On 2019-09-15 14:12-0400 Jim Dishaw wrote:

> While fixing the plm render bug, I’m working on how text is handled in general.  I’ve made some minor changes to the postscript driver in preparation for the bigger changes.
>
> I’m in a bit of a hobbled development environment right now and running the test suite and pushing the change is not really practical (I’m doing the work entirely on Windows and using Visual Studio Express).  So, if someone is willing to test and push, it would be greatly appreciated.

Hi Jim:

I would be happy to help you this way.

Using "git am" to apply your commit worked, but there were the following minor formatting issues:

* "git am" detected some trailing blanks on some of your changed lines.

* The resulting commit message did not separate paragraphs properly (with an end of line).  So
the git log result looks like this:

     Cleanup of the postscript driver -- Changed unnecessary calls of fprintf() to fputs. -- The fputs() call is more efficient with fixed strings -- Changed the TRMFLT() from a macro to an inline static function -- Preprocessor macros can have unintended side effects -- Eliminated the the shared ouput buffer (outbuf) variable -- Dynamically allocating the output buffer variable on the stack on function entry has negligible performance impact -- The shared output buffer would cause problems when threads are implemented

Instead of what you likely intended which was

     Cleanup of the postscript driver

     -- Changed unnecessary calls of fprintf() to fputs.
     -- The fputs() call is more efficient with fixed strings
     -- Changed the TRMFLT() from a macro to an inline static function
     -- Preprocessor macros can have unintended side effects
     -- Eliminated the the shared ouput buffer (outbuf) variable
     -- Dynamically allocating the output buffer variable on the stack on function entry has negligible performance impact
     -- The shared output buffer would cause problems when threads are implemented

where "git log" has inserted the leading spaces so you should not do that in your commit message.

Note that both of these formatting issues are easy for me to deal with here, but for your next iteration
(which is necessary, see below) you may want to address these issues yourself.

I tested your code changes by comparing the results of test_c_psc
between the ps device driver for the master branch and your patched
version of same, and there are two issues in the PostScript results
for each of the examples, but I will just show you those issues for
the 00 example:

diff -Naur ../test_examples_output_dir_psc/x00c.psc examples/test_examples_output_dir/x00c.psc
--- ../test_examples_output_dir_psc/x00c.psc    2019-09-15 12:01:58.435910736 -0700
+++ examples/test_examples_output_dir/x00c.psc  2019-09-15 12:09:36.511559691 -0700
@@ -3,7 +3,7 @@
  %%%%%%%%%%%%%%%%%%%%%%
  %%Title: PLplot Graph
  %%Creator: PLplot Version 5.15.0
-%%CreationDate: Sun Sep 15 12:01:58 2019
+%%CreationDate: Sun Sep 15 12:09:36 2019
  %%Pages: (atend)
  %%EndComments

@@ -342,7 +342,7 @@
  397 3228 D 356 3256 D 315 3284 D S
  eop

-%%Trailer
+%%%%Trailer
  %%Pages: 1
  @end
-%%EOF
+%%%%EOF

Of course, the %%CreationDate changes are expected, but your change
currently creates incorrect %%Trailer and %%EOF directives by
prepending "%%" to them for every example.

So please fix those code update issues so that the PostScript results are
identical to what is produced by the present code from the master
branch except for the %%CreationDate date/time stamp.  And optionally
fix the above formatting issues.  And we can take it from there.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Patch set for postscript driver

[Jim D. <ji...@di...>]

While fixing the plm render bug, I’m working on how text is handled in general.  I’ve made some minor changes to the postscript driver in preparation for the bigger changes.

I’m in a bit of a hobbled development environment right now and running the test suite and pushing the change is not really practical (I’m doing the work entirely on Windows and using Visual Studio Express).  So, if someone is willing to test and push, it would be greatly appreciated.

Re: [Plplot-devel] Which cmake do I need to modify?

[Alan W. I. <Ala...@gm...>]

On 2019-09-14 22:04-0400 Jim Dishaw wrote:

> I need to add comctl32.lib as one of the libraries when building Windows executables.  Which cmake file should be modified such that the examples are built correctly?  The wingdi driver needs that library.  Thanks

A search for the comctl32 library is already occurring in
cmake/modules/wingdi.cmake.  If it is found you should be
getting a cmake message "Looking for gdi32 header and library - found"
and your CMakeCache.txt should show the actual location of that library.

That library location becomes part of wingdi_LINK_FLAGS which should
be used appropriately in the rest of the build system so everything
(dynamic driver or else plplot library if dynamic drivers are not
used) and the examples link correctly.

It sounds like something is currently interfering with this process
that worked before for you so please send me a complete
bug report with all the details so that I can help you
find what the problem is.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________