plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

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

On 2018-08-13 08:41-0000 Arjen Markus wrote:

> Hi Alan,
>
>> However, I hope those comments (such as the possibility mentioned above of
>> building an octave MinGW-w64/MSYS2 package for yourself using the pacman
>> packaging information at
>> <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>)
>> are still of some use to you.
>>
> I have tried to build Octave under MinGW-w64/MSYS2 using that webpage. However:
> - I had to remove the references to the patches, as these do not seem to be available. No idea what the effect is
> - The build failed on a mismatch in the checksums:
>
> $ makepkg -sCLf
> ==> Making package: mingw-w64-octave-hg r19590.6d75f1683ce8-1 (Sun, Aug 12, 2018 15:56:07)
> ==> Checking runtime dependencies...
> ==> Checking buildtime dependencies...
> ==> Retrieving sources...
>  -> Updating gnulib git repo...
> Fetching origin
>  -> Found tip.tar.bz2
> ==> ERROR: Integrity checks (sha256) differ in size from the source array.
>
> This is the point where I stopped. I have no clue as to whether this is a serious issue or not.

Let's ignore octave for a bit and look at the more general picture.
If you like the goal (in its own right) of learning to build packages
for the MinGW-w64/MSYS2 platform, then I suggest you follow the
package build documentation examples under the heading "Re-building a
package" at <https://github.com/msys2/msys2/wiki/Creating-packages>.
Can you use those steps to build both their examples (flex and
python3)?  If not, then you should take the problem to the MSYS2
mailing list to get help with that documentation.  But if that general
procedure works for you, then the next obvious step is to help out
with the PLplot packaging at
<https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-plplot>
by first building that package as is, fixing it according to your own
experience (e.g., by moving to Python 3, and by enabling qt), and
drawing Alex's attention to your improvements (likely via a pull
request) so they will be made part of the official Plplot package for
this platform.

Moving back to the octave case, I am pretty sure unless that
semi-official package is completely broken, that the same procedures
used to build flex, python3, and PLplot should also work fine for
octave without all the issues you encountered above.  Assuming you can
build that octave package, then the next steps would be to evaluate
the result for our needs, and assuming it does work for those needs
(or can easily be fixed), advocate making it an official package
that the PLplot package depends on.

> I guess an alternative could be to simply build Octave and install it without pacman, but I have not tried that yet.

I would advise against that since unofficial octave builds are not
going to help our octave users that much on this particular platform
and may turn out to be a black hole sucking up a lot of your time.
Instead, I think it would be better in the long-run to help get an
official octave package running for this platform as I have outlined
above.

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.sf.net); 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] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen M. <Arj...@de...>]

Hi Alan,

> However, I hope those comments (such as the possibility mentioned above of
> building an octave MinGW-w64/MSYS2 package for yourself using the pacman
> packaging information at
> <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>)
> are still of some use to you.
>
I have tried to build Octave under MinGW-w64/MSYS2 using that webpage. However:
- I had to remove the references to the patches, as these do not seem to be available. No idea what the effect is
- The build failed on a mismatch in the checksums:

$ makepkg -sCLf
==> Making package: mingw-w64-octave-hg r19590.6d75f1683ce8-1 (Sun, Aug 12, 2018 15:56:07)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating gnulib git repo...
Fetching origin
  -> Found tip.tar.bz2
==> ERROR: Integrity checks (sha256) differ in size from the source array.

This is the point where I stopped. I have no clue as to whether this is a serious issue or not.

I guess an alternative could be to simply build Octave and install it without pacman, but I have not tried that yet.

Regards,

Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen M. <Arj...@de...>]

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> Sent: Thursday, August 09, 2018 1:07 AM
>
> Thanks for that confirmation on Cygwin.  That is the first time in a long time (if
> ever?) that octave has worked on that platform for us which I regard as a big step
> forward.
>

:)

> And as far as MinGW-w64/MSYS2 is concerned, my guess is the information at
> <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>
> is for a pacman package for octave that has not matured yet so the package build
> results are not included in the official pacman packages for MinGW-w64/MSYS2.
> But the small part of that package that we use for our octave binding build and tests
> might work well.  So if you want to follow up further, I suggest you build the pacman
> package for octave following the cookbook located at
> <https://github.com/msys2/msys2/wiki/Creating-packages>.
>

I guess it is worth a try ... Will keep you informed on progress.

> As you know, my long-term dream has been to use Wine to help you out more with
> both Cygwin and MinGW-w64/MSYS2 testing so recently I looked into that again.
> But currently it does not look good.  For example, both Cygwin and MinGW-
> w64/MSYS2 upgraded from Windows XP to Windows Vista functionality a couple of
> years back, but according to discussion at <https://github.com/Alexpux/MSYS2-
> packages/issues/682>
> Wine has a lot of missing Vista functionality that has to be implemented before
> either of those two distributions will work on Wine again.  So until that happens, I
> am limited to just commenting from the sidelines concerning those distributions.
> However, I hope those comments (such as the possibility mentioned above of
> building an octave MinGW-w64/MSYS2 package for yourself using the pacman
> packaging information at
> <https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>)
> are still of some use to you.
>

Pity about Wine, but it seems quite difficult to keep up with a moving target like Windows.

Regards,

Arjen
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

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

On 2018-08-07 06:37-0000 Arjen Markus wrote:

> Hi Alan,
>
> I can confirm clean test results for Octave 4.2.2 on Cygwin - I cannot do the same for MinGW-w64/MSYS2 as that does not provide an octave package as far as I can tell. There is an Octave pacakge on github (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg) but its status is completely unclear to me. As is how it should be installed (pacman does not recognise it)

Hi Arjen:

Thanks for that confirmation on Cygwin.  That is the first time in a
long time (if ever?) that octave has worked on that platform for us
which I regard as a big step forward.

And as far as MinGW-w64/MSYS2 is concerned, my guess is the
information at
<https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>
is for a pacman package for octave that has not matured yet so the
package build results are not included in the official pacman packages
for MinGW-w64/MSYS2.  But the small part of that package that we use
for our octave binding build and tests might work well.  So if you
want to follow up further, I suggest you build the pacman package for
octave following the cookbook located at
<https://github.com/msys2/msys2/wiki/Creating-packages>.

As you know, my long-term dream has been to use Wine to help you out
more with both Cygwin and MinGW-w64/MSYS2 testing so recently I looked
into that again.  But currently it does not look good.  For example,
both Cygwin and MinGW-w64/MSYS2 upgraded from Windows XP to Windows
Vista functionality a couple of years back, but according to
discussion at <https://github.com/Alexpux/MSYS2-packages/issues/682>
Wine has a lot of missing Vista functionality that has to be
implemented before either of those two distributions will work on Wine
again.  So until that happens, I am limited to just commenting from
the sidelines concerning those distributions.  However, I hope those
comments (such as the possibility mentioned above of building an
octave MinGW-w64/MSYS2 package for yourself using the pacman packaging
information at
<https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg>)
are still of some use to you.

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.sf.net); 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] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen M. <Arj...@de...>]

Hi Alan,

I can confirm clean test results for Octave 4.2.2 on Cygwin - I cannot do the same for MinGW-w64/MSYS2 as that does not provide an octave package as far as I can tell. There is an Octave pacakge on github (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-octave-hg) but its status is completely unclear to me. As is how it should be installed (pacman does not recognise it)

Regards,

Arjen

> -----Original Message-----
> From: Arjen Markus [mailto:Arj...@de...]
> Sent: Monday, August 06, 2018 2:33 PM
> To: Alan W. Irwin; Orion Poplawski
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Status of our octave binding and examples for version
> 4.4.0 of octave
>
> Hi Alan,
>
> I am back from my holiday, so I should have the opportunity to test the new binding.
>
> Regards,
>
> Arjen
>
> > -----Original Message-----
> > From: Alan W. Irwin [mailto:Ala...@gm...]
> > Sent: Thursday, August 02, 2018 12:40 AM
> > To: Orion Poplawski; Arjen Markus
> > Cc: PLplot development list
> > Subject: Re: Status of our octave binding and examples for version
> > 4.4.0 of octave
> >
> > On 2018-07-31 21:10-0700 Alan W. Irwin wrote:
> >
> > > To Orion and Arjen:
> > >
> > > As of
> > > <https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f393
> > > 23 c9daf593ae0765/> our octave binding and all
> > > examples/octave/x??c.m examples give a perfect PostScript difference
> > > report for Octave 4.4.0 for Debian Buster == Debian Testing.  Please
> > > do equivalent checks (i.e., by simply building the
> > > test_noninteractive target in the build
> > > tree) for Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well
> > > on platforms other than Debian Buster.  I emphasize build-tree
> > > checks because install-tree checks currently won't work [....]
> >
> > That request for testing help still applies, but I can now report (see
> > the log for commit 391ec0ad0 for the details) that I have been able to
> > replace the cellstr-based workaround with an actual fix for the issue
> > which should work for late octave-3 as well as all versions of octave-4.
> >
> > 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.sf.net); 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
> > __________________________
> DISCLAIMER: This message is intended exclusively for the addressee(s) and may
> contain confidential and privileged information. If you are not the intended recipient
> please notify the sender immediately and destroy this message. Unauthorized use,
> disclosure or copying of this message is strictly prohibited. The foundation 'Stichting
> Deltares', which has its seat at Delft, The Netherlands, Commercial Registration
> Number 41146461, is not liable in any way whatsoever for consequences and/or
> damages resulting from the improper, incomplete and untimely dispatch, receipt
> and/or content of this e-mail.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most engaging tech
> sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

[Arjen M. <Arj...@de...>]

Hi Alan,

I am back from my holiday, so I should have the opportunity to test the new binding.

Regards,

Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:Ala...@gm...]
> Sent: Thursday, August 02, 2018 12:40 AM
> To: Orion Poplawski; Arjen Markus
> Cc: PLplot development list
> Subject: Re: Status of our octave binding and examples for version 4.4.0 of octave
>
> On 2018-07-31 21:10-0700 Alan W. Irwin wrote:
>
> > To Orion and Arjen:
> >
> > As of
> > <https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f39323
> > c9daf593ae0765/> our octave binding and all examples/octave/x??c.m
> > examples give a perfect PostScript difference report for Octave 4.4.0
> > for Debian Buster == Debian Testing.  Please do equivalent checks
> > (i.e., by simply building the test_noninteractive target in the build
> > tree) for Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well on
> > platforms other than Debian Buster.  I emphasize build-tree checks
> > because install-tree checks currently won't work [....]
>
> That request for testing help still applies, but I can now report (see the log for
> commit 391ec0ad0 for the details) that I have been able to replace the cellstr-based
> workaround with an actual fix for the issue which should work for late octave-3 as
> well as all versions of octave-4.
>
> 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.sf.net); 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
> __________________________
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Status of our octave binding and examples for version 4.4.0 of octave

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

On 2018-07-31 21:10-0700 Alan W. Irwin wrote:

> To Orion and Arjen:
>
> As of
> <https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f39323c9daf593ae0765/>
> our octave binding and all examples/octave/x??c.m examples give a
> perfect PostScript difference report for Octave 4.4.0 for Debian
> Buster == Debian Testing.  Please do equivalent checks (i.e., by
> simply building the test_noninteractive target in the build tree) for
> Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well on platforms
> other than Debian Buster.  I emphasize build-tree checks because
> install-tree checks currently won't work [....]

That request for testing help still applies, but I can now report (see
the log for commit 391ec0ad0 for the details) that I have been able to
replace the cellstr-based workaround with an actual fix for the issue
which should work for late octave-3 as well as all versions of
octave-4.

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.sf.net); 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] rgb colourscale interpolation

[Phil R. <p.d...@gm...>]

Hi Again Alan

>>
>> I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3
>> changed member names] in the PLControlPt struct are likely a good idea
>> since h,l,s was a misnomer.  Nevertheless, those changes did cause
>> important build problems in the Tk-related part of the build which I
>> have now fixed (commit 94e2e5b01).
>
> Is this struct really part of our public API? It is not mentioned
> anywhere in the docs as far as I can tell so I presumed this was an
> internal use only structure.

I take it back - just found it in the docs regarding ABI

Re: [Plplot-devel] rgb colourscale interpolation

[Phil R. <p.d...@gm...>]

Hi Alan

On 31 July 2018 at 19:21, Alan W. Irwin <Ala...@gm...> wrote:
> Hi Phil:
>
> I am moving this discussion to plplot-devel where it belongs.

Sorry, I hadn't realised we'd gotten off list. Thanks for moving it back.

>
> I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3
> changed member names] in the PLControlPt struct are likely a good idea
> since h,l,s was a misnomer.  Nevertheless, those changes did cause
> important build problems in the Tk-related part of the build which I
> have now fixed (commit 94e2e5b01).

Is this struct really part of our public API? It is not mentioned
anywhere in the docs as far as I can tell so I presumed this was an
internal use only structure.

>
> Example 12 (which uses RGB interpolation) shows the effect of your
> change.  The old code produced
> <http://plplot.org/examples-data/demo12/x12.01.png> which shows fairly
> discontinous colour results from 1982 to 1986, while the new code
> produces much smoother colour changes in that date range.  So from
> this evidence I feel your change is a nice win.
>
> I previously said (in response to your question about how you
> should edit README.release):
>
>> I assume you will want to insert a paragraph concerning
>
> your change in a new section 2.8 of "Improvements relative to the
> previous release".  Also, since you changed the semantics of the two
> functions (although not their API) for the RGB case you should
> probably specifically warn the users of this forthcoming release about
> that semantics change by adding a one-sentence new section 1.10 in
> "OFFICIAL NOTICES FOR USERS" that refers to your new section 2.8 for
> the details.
>
> Since your backwards-incompatible API change to the PLControlPt struct is
> going
> to cause build problems (just like it did in our Tk-related code)
> for the minority of our users who actually use that struct
> in their code, you should expand that suggested single sentence in 1.10 to
> warn users of this specific change to PLControlPt.
>
> I look forward to your commit with the suggested changes in README.release.

They'll arrive this afternoon all being well.

>
>
> 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.sf.net); 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] Status of our octave binding and examples for version 4.4.0 of octave

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

To Orion and Arjen:

As of
<https://sourceforge.net/p/plplot/plplot/ci/d7310aa9864ce1676177f39323c9daf593ae0765/>
our octave binding and all examples/octave/x??c.m examples give a
perfect PostScript difference report for Octave 4.4.0 for Debian
Buster == Debian Testing.  Please do equivalent checks (i.e., by
simply building the test_noninteractive target in the build tree) for
Cygwin, MinGW-w64/MSYS2, and Fedora to check all is well on platforms
other than Debian Buster.  I emphasize build-tree checks because
install-tree checks currently won't work until I finish another
project that was half-completed when I discovered the octave-4 cell array
workaround described below.

The way I got the previously dropped octave examples 26 and 33 to work
was to use cell arrays at those points in the examples where Octave
non-cell arrays were not working due to an upstream bug in Octave 4.4
for the transformation method used to determine C strings from an
Octave non-cell array of strings.  For a long time I thought the issue
was UTF-8, but I discovered when testing the recent commit that pure
ascii strings could also cause issues.

Since that commit I have discovered (with my hex_print private test
project) the issue is a simple one which is the transformation method
that used to work fine for octave 3.8 no longer works for octave-4.4
*if* there are more than 15 bytes in the character strings in the
non-cell arrays.  (Of course, UTF-8 strings tend to have more bytes
which is why they tend to expose this upstream bug more than ascii
strings, but with hex_print I found in every case whether using the
ascii subset of UTF-8 or more general UTF-8 strings that short strings
worked, but when the number of bytes in the Octave string (excluding the NULL
byte) exceeded 15, the result was an invalid UTF-8 C string.

I have just submitted this issue to the upstream octave developers
(see <https://savannah.gnu.org/bugs/index.php?54415>).  That bug
report is based on the hex_print experience summarized above, and
since that experience proves there is now an explicit length limit of
15 imposed by the octave code, the issue should be easy to find and
fix (I hope).

But meanwhile, the cellstr workaround in the above commit for long
strings avoids this issue so with luck the PLplot testers lurking here
will now get perfect octave-4 results when building the
test_noninteractive target on all platforms of interest to them.

Also note in the subsequent commit 95f823ec0, I have changed our
octave detection method so that octave-4 is no longer a special case
with warnings attached.  Which finally (from the better late than
never department) answers Orion's question about those warnings from
long ago.  :-)

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.sf.net); 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] rgb colourscale interpolation

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

Hi Phil:

I am moving this discussion to plplot-devel where it belongs.

I think your backwards-incompatible changes [h,l,s ==> c1,c2,c3
changed member names] in the PLControlPt struct are likely a good idea
since h,l,s was a misnomer.  Nevertheless, those changes did cause
important build problems in the Tk-related part of the build which I
have now fixed (commit 94e2e5b01).

Example 12 (which uses RGB interpolation) shows the effect of your
change.  The old code produced
<http://plplot.org/examples-data/demo12/x12.01.png> which shows fairly
discontinous colour results from 1982 to 1986, while the new code
produces much smoother colour changes in that date range.  So from
this evidence I feel your change is a nice win.

I previously said (in response to your question about how you
should edit README.release):

> I assume you will want to insert a paragraph concerning
your change in a new section 2.8 of "Improvements relative to the
previous release".  Also, since you changed the semantics of the two
functions (although not their API) for the RGB case you should
probably specifically warn the users of this forthcoming release about
that semantics change by adding a one-sentence new section 1.10 in
"OFFICIAL NOTICES FOR USERS" that refers to your new section 2.8 for
the details.

Since your backwards-incompatible API change to the PLControlPt struct is going
to cause build problems (just like it did in our Tk-related code)
for the minority of our users who actually use that struct
in their code, you should expand that suggested single sentence in 1.10 to
warn users of this specific change to PLControlPt.

I look forward to your commit with the suggested changes in README.release.

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.sf.net); 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] Intermittent Ada example build failures are now back again

[Jerry B. <lis...@ic...>]

> On Jul 16, 2018, at 10:10 AM, Alan W. Irwin <Ala...@gm...> wrote:
> 
> On 2018-06-09 13:30-0700 Alan W. Irwin wrote:
> 
>> On 2018-04-15 11:15-0700 Alan W. Irwin wrote:
>> 
>>> Hi Jerry:
>> [...]
>>> So once this Ada build issue appeared again for me yesterday after all
>>> those previous successful hardware checks, I did a google search for
>>> the terms (without the quotes) "gnatmake intermittent build error" and
>>> found
>>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451>
>>> which was a bug report in 2015 about intermittent Ada build issues
>>> which was immediately fixed back then.  However, my gnat version (=
>>> 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure
>>> at this stage that bug 65451 is the issue that is causing the
>>> intermittent Ada build issues for me. Therefore, I plan to use the
>>> -DENABLE_ada=OFF option for my further testing until I can get access
>>> to a later version of the Ada build tools myself, and I suggest others
>>> who currently don't have access to Ada build tools with bug 65451
>>> fixed should do the same.
>> 
>> Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that I
>> was using for Debian Jessie) the first test of Ada has been a complete success.
>> See commit 994723471 for the details of the tests I ran.
> 
> Hi Jerry:
> 
> I just ran into this issue for the first time for my new hardware and
> latest Ada/gnat (version 7.3.0) from Debian Buster (sigh).  I was
> doing a parallel build (with -j10 for my new system with 8 real
> cores), when the following error was encountered:
> 
> ./plplot_standard.o: file not recognized: File truncated
> collect2: error: ld returned 1 exit status
> gnatlink-7: error when calling /usr/bin/gcc-7
> gnatmake: *** link failed.
> examples/ada/CMakeFiles/xstandard30a.dir/build.make:77: recipe for target 'examples/ada/xstandard30a' failed
> make[3]: *** [examples/ada/xstandard30a] Error 4
> 
> A google search found
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857831> which
> appears to be a similar (or the same bug) for 7.1.  At the time, the
> Debian packagers thought they had a fix, but it seems from my
> experience either that was not true or else the fix has not been
> propagated to 7.3. I have just now privately reported the situation to
> Matthias Klose (the author of the bug 857831 report, and they guy who
> decided that bug was fixed), and we will see what he says.  But to
> work around this problem until it is fixed for Debian Buster, I plan
> to use -DENABLE_ada=OFF for my testing.
> 
> Alan

Thanks for the update, Alan. Keep me posted.
Jerry

Re: [Plplot-devel] Intermittent Ada example build failures are now back again

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

On 2018-06-09 13:30-0700 Alan W. Irwin wrote:

> On 2018-04-15 11:15-0700 Alan W. Irwin wrote:
>
>> Hi Jerry:
> [...]
>> So once this Ada build issue appeared again for me yesterday after all
>> those previous successful hardware checks, I did a google search for
>> the terms (without the quotes) "gnatmake intermittent build error" and
>> found
>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451>
>> which was a bug report in 2015 about intermittent Ada build issues
>> which was immediately fixed back then.  However, my gnat version (=
>> 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure
>> at this stage that bug 65451 is the issue that is causing the
>> intermittent Ada build issues for me. Therefore, I plan to use the
>> -DENABLE_ada=OFF option for my further testing until I can get access
>> to a later version of the Ada build tools myself, and I suggest others
>> who currently don't have access to Ada build tools with bug 65451
>> fixed should do the same.
>
> Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that I
> was using for Debian Jessie) the first test of Ada has been a complete 
> success.
> See commit 994723471 for the details of the tests I ran.

Hi Jerry:

I just ran into this issue for the first time for my new hardware and
latest Ada/gnat (version 7.3.0) from Debian Buster (sigh).  I was
doing a parallel build (with -j10 for my new system with 8 real
cores), when the following error was encountered:

./plplot_standard.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status
gnatlink-7: error when calling /usr/bin/gcc-7
gnatmake: *** link failed.
examples/ada/CMakeFiles/xstandard30a.dir/build.make:77: recipe for target 'examples/ada/xstandard30a' failed
make[3]: *** [examples/ada/xstandard30a] Error 4

A google search found
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857831> which
appears to be a similar (or the same bug) for 7.1.  At the time, the
Debian packagers thought they had a fix, but it seems from my
experience either that was not true or else the fix has not been
propagated to 7.3. I have just now privately reported the situation to
Matthias Klose (the author of the bug 857831 report, and they guy who
decided that bug was fixed), and we will see what he says.  But to
work around this problem until it is fixed for Debian Buster, I plan
to use -DENABLE_ada=OFF for my testing.

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.sf.net); 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] Long-standing '\0' issue fixed + development news

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

I am happy to report that with some help from Nils Gladitz on the
CMake list a long-standing PLplot issue where parallel builds of test
targets (e.g., test_noninteractive) had groups of ascii nul ('\0')
characters inserted into the output has now been fixed.  The fix (see
the log message for commit a4bada0048 for more details) was to address
name clashes in the plplot_test test scripts that I had introduced
more than a decade (!) ago in commit 7e39e59f2b.

Other PLplot development news is I have been using my new computer
with Debian Buster installed to solve a number of issues like this
current one that I have been reminded of by my recent
test_noninteractive results in the build tree for the shared libraries
case.  For example, later today I plan to make the final commit in
this series that will solve all valid warning messages that have shown
up with the latest versions (from Debian Buster) of software libraries
that PLplot depends on.  I then plan to follow up by doing the same
thing for ctest, the test_interactive target, and all major
configurations and build trees covered by the comprehensive_test.sh
script.  Then push upstream octave and lua to fix some obvious
upstream regressions I have discovered during these tests to achieve
on the new computer the perfect PostScript difference reports that I
was achieving on my old computer that had (very) old versions of
software libraries installed from Debian Jessie.  And finally, I plan
to go back to the PLplot ToDo list I was pursuing before the advent of
this new computer interrupted everything in a good way.

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.sf.net); 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] Status of examples/c/extXdrawable_demo.c

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

On 2018-06-22 08:56+0930 Jonathan Woithe wrote:

> Hi Alan
>
> On Wed, Jun 20, 2018 at 04:51:04PM -0700, Alan W. Irwin wrote:
>> As far as I can tell from
>>
>> git log --follow examples/c/extXdrawable_demo.c
>>
>> Jonathan Woithe implemented that example a decade ago ...
>
> I did.  The purpose of the example was to show how the external X drawable
> device could be used to integrate into toolkits for which there was no
> native PLplot device.
>
>> This example is really dated because it contains calls to the GTK+ API
>> that were already deprecated for GTK+ version 2 and non-existent for
>> GTK+ version 3.  And it is not a good idea to mix this GTK+ version 2
>> example with a PLplot core library that can depend directly (in the
>> non-dynamic drivers case) on GTK+ version 3 which has long been the
>> standard version of GTK+.  So I have effectively disabled the build of
>> examples/c/extXdrawable_demo.c in my recent commit 9893349d1.
>
> These are all valid points, and disabling the build of the code seems like a
> sensible step at this point.  Although it hasn't been mentioned, I would be
> reluctant to see the example removed completely though, since it still
> serves to show one possible way that the External X Drawable device can be
> used.
>
> With that said, it would be good to update it for gtk3.
>
> I would be willing to take a look at this myself, but it might be a few
> months before I have the time to do so due to an elevated workload.  I am by
> no means an expert on gtk but I might be able to get something functional
> happening.
>
> It's also worth noting that there was nothing special about choosing gtk for
> this demo.  At the time I was working on an internal company tool which
> needed to plot data in a GUI context.  It was a simple program and it ended
> up using gtk (Qt wasn't an option at that point for various unrelated
> reasons).  Since the demo came out of that work, the demo ended up using
> gtk.
>
> Feel free to ping me in about 3 months if you haven't heard from me by then.

Hi Jonathan:

I was glad to see that you are still lurking on the PLplot devel list and also
willing to take a look at updating/replacing this example later on
when you anticipate more free time to work on this topic.

>From what you have said, it appears this "external X" method should
transcend individual toolkits.  So any toolkit (e.g., Qt5 or GTK+
version 3) you decide to use in an implementation of a modern
"external X" example would be fine and also feel free to implement
this example in whichever of the C or C++ languages you prefer for the
task.  When the time comes I encourage you to call on me for any
PLplot build/test system help that you might need to integrate your
work into PLplot.

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.sf.net); 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] Status of examples/c/extXdrawable_demo.c

[Jonathan W. <jw...@ju...>]

Hi Alan

On Wed, Jun 20, 2018 at 04:51:04PM -0700, Alan W. Irwin wrote:
> As far as I can tell from
> 
> git log --follow examples/c/extXdrawable_demo.c
> 
> Jonathan Woithe implemented that example a decade ago ...

I did.  The purpose of the example was to show how the external X drawable
device could be used to integrate into toolkits for which there was no
native PLplot device.

> This example is really dated because it contains calls to the GTK+ API
> that were already deprecated for GTK+ version 2 and non-existent for
> GTK+ version 3.  And it is not a good idea to mix this GTK+ version 2
> example with a PLplot core library that can depend directly (in the
> non-dynamic drivers case) on GTK+ version 3 which has long been the
> standard version of GTK+.  So I have effectively disabled the build of
> examples/c/extXdrawable_demo.c in my recent commit 9893349d1.

These are all valid points, and disabling the build of the code seems like a
sensible step at this point.  Although it hasn't been mentioned, I would be
reluctant to see the example removed completely though, since it still
serves to show one possible way that the External X Drawable device can be
used.

With that said, it would be good to update it for gtk3.

I would be willing to take a look at this myself, but it might be a few
months before I have the time to do so due to an elevated workload.  I am by
no means an expert on gtk but I might be able to get something functional
happening.

It's also worth noting that there was nothing special about choosing gtk for
this demo.  At the time I was working on an internal company tool which
needed to plot data in a GUI context.  It was a simple program and it ended
up using gtk (Qt wasn't an option at that point for various unrelated
reasons).  Since the demo came out of that work, the demo ended up using
gtk.

Feel free to ping me in about 3 months if you haven't heard from me by then.

Regards
  jonathan

Re: [Plplot-devel] Status of examples/c/extXdrawable_demo.c

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

On 06/20/2018 07:51 PM, Alan W. Irwin wrote:
> 
> If you try the -DGTK_DISABLE_SINGLE_INCLUDES flag that is recommended
> in the above URL that works, but as soon as you try the additional
> recommended -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED flags a
> whole host of issues show up, i.e., porting this example is not going
> to be trivial.  Therefore I abandoned that idea for myself, but I
> encourage you to take a look at porting this example because I believe
> your GTK+ skills/experience are a lot more extensive than mine.

I'm sorry, I can't help with this. I also know very little about GTK.

-Hazen

[Plplot-devel] Status of examples/c/extXdrawable_demo.c

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

Hi Hazen:

As far as I can tell from

git log --follow examples/c/extXdrawable_demo.c

Jonathan Woithe implemented that example a decade ago, you did
the actual commit, and we have been (minimally) maintaining it
ever since.

This example is really dated because it contains calls to the GTK+ API
that were already deprecated for GTK+ version 2 and non-existent for
GTK+ version 3.  And it is not a good idea to mix this GTK+ version 2
example with a PLplot core library that can depend directly (in the
non-dynamic drivers case) on GTK+ version 3 which has long been the
standard version of GTK+.  So I have effectively disabled the build of
examples/c/extXdrawable_demo.c in my recent commit 9893349d1.

I did take a look at porting this example to GTK+ version 3 following
the precepts in
<https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html>.
For example, after PLplot was built, I built the example directly
using

cd examples/c
gcc ../../../plplot.git/examples/c/extXdrawable_demo.c -DUSINGDLL -I/home/software/plplot/HEAD/plplot.git/include -I/home/software/plplot/HEAD/build_dir/include -I/home/software/plplot/HEAD/plplot.git/lib/qsastime -I/home/software/plplot/HEAD/build_dir/lib/qsastime  -O3 -fvisibility=hidden -Wuninitialized $(pkg-config  --cflags --libs gtk+-x11-2.0) ../../src/libplplot.so |& less

If you try the -DGTK_DISABLE_SINGLE_INCLUDES flag that is recommended
in the above URL that works, but as soon as you try the additional
recommended -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED flags a
whole host of issues show up, i.e., porting this example is not going
to be trivial.  Therefore I abandoned that idea for myself, but I
encourage you to take a look at porting this example because I believe
your GTK+ skills/experience are a lot more extensive than mine.

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.sf.net); 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 on Debian Buster looking fairly good so far

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

It's a long story involving a new graphics card that I by mistake
bought for my new computer.  That card is only (partially) supported
by the cutting-edge Linux graphics stack so the upshot is I have
decided to run Debian Buster on my (new) principal computer that I use
for PLplot testing.  Buster is a constantly changing rolling release
that stays fairly close (but likely not quite as close as Fedora and
MinGW-w64/MSYS2) to the cutting edge of free software packages.  So
this is a huge change compared to my previous testing environment
(Debian Jessie) which was at least 3 years away from the cutting edge.
So by using this Debian Buster test environment I should be some help
to Orion (Fedora) and Arjen (MinGW-w64/MSYS2) in changing PLplot so it
will work properly with cutting-edge free software.

Commit 994723471 contains the first tranche of fixes that get PLplot
more-or-less working on Debian Buster (including perfect results for
Ada, see my previous post to this list).  See the associated commit
message for all the details of what was changed, what was tested, and
any remaining regressions in the configuration and test results.

I want to get all these regressions fixed before the next PLplot
release so that means it will likely be several more months before I
can even start to plan that release.  So this period continues to be
an excellent opportunity for the rest of the PLplot developers to
pursue the development topics that interest them.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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.sf.net); 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] Intermittent Ada example build failures are now gone again!

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

On 2018-04-15 11:15-0700 Alan W. Irwin wrote:

> Hi Jerry:
[...]
> So once this Ada build issue appeared again for me yesterday after all
> those previous successful hardware checks, I did a google search for
> the terms (without the quotes) "gnatmake intermittent build error" and
> found
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451>
> which was a bug report in 2015 about intermittent Ada build issues
> which was immediately fixed back then.  However, my gnat version (=
> 4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure
> at this stage that bug 65451 is the issue that is causing the
> intermittent Ada build issues for me. Therefore, I plan to use the
> -DENABLE_ada=OFF option for my further testing until I can get access
> to a later version of the Ada build tools myself, and I suggest others
> who currently don't have access to Ada build tools with bug 65451
> fixed should do the same.

Just to follow up for Debian Buster with gnat-7 (as opposed to gnat-4 that I
was using for Debian Jessie) the first test of Ada has been a complete success.
See commit 994723471 for the details of the tests I ran.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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.sf.net); 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] Intermittent Ada example build failures are now gone again!

[Alan W. I. <ir...@be...>]

Hi Jerry:

On 2018-04-10 14:15-0700 lis...@ic... wrote:

> Thanks for your work on trying to figure this out. I really have no
idea what the problem could be. I’ve never had a problem with gnatmake
but you recall a problem from the past that pretty much escapes me by
now.

I was referring to your attempts to get the test_ada project to work
on Mac OS X.  I have forgotten the details, but as I recall you never
had complete success with that test.  But on the other hand, the issue
you discovered was consistent and that was also true for the issue
that Arjen discovered for Cygwin.  Therefore, it is likely the issues
you guys discovered on two different platforms don't have anything in
common with the issue I am dealing with.

[...]
> I don’t know if you will find this useful, but on
>
> https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/building_executable_programs_with_gnat.html
>
> at the end of "4.1. Building with gnatmake" appears this:
>
> "Note that for advanced forms of project structure, we recommend
creating a project file as explained in the GNAT_Project_Manager
chapter in the GPRbuild User’s Guide, and using the gprbuild tool
which supports building with project files and works similarly to
gnatmake.”

[...]
Thanks for pointing out the gprbuild possibility.  From my further
reading in
<https://docs.adacore.com/gprbuild-docs/html/gprbuild_ug/building_with_gprbuild.html>
it appears gprbuild is designed to handle more project complexity than
gnatmake, but it is not of sufficient generality to implement complete
build systems like is possible with CMake.  Furthermore, it appears
that gprbuild does not use gnatmake but provides the same
functionality at the build level, i.e., it uses the same building
blocks (gcc to compile, gnatbind to bind, and gnatlink to link) that
gnatmake does.  Note it is the gnatlink step where the intermittent
errors occur for me.  So it is useful to know about the gprbuild
possibility, but since CMake has everything covered at the build
system level (i.e., does not need to use gprbuild) and gnatmake has
everything covered at the detailed (gcc, gnatbind, and gnatlink)
building block level I plan to stick with that combination.

Here is some recent news about these intermittent Ada build errors.

They disappeared for me for several comprehensive tests after a reboot
3 days ago, but yesterday they came back again!  That is, I built the
test_diff_psc target by hand from scratch and it failed due to Ada.
Then I repeated the exact test again, and it succeeded with perfect
(PostScript) results and no Ada build issues at all! So rebooting the
system may have nothing to do with these errors.

Of course, the possibility always exists that intermittent results are
due to hardware issues, and the gnat building process may be
particularly sensitive to such hardware issues.  So after the first
encounter with these intermittent Ada build failures, I did some
detailed comparisions of rsync results using the --checksum option
(which checked that 4 trillion bits on two rsynced disks were the
same), RAM tests, disk filesystem checks, and git filesystem checks to
see if any hardware issue shows up via such detailed checks, but none
did.  So those results pretty much restored my confidence that my
hardware was fine.

So once this Ada build issue appeared again for me yesterday after all
those previous successful hardware checks, I did a google search for
the terms (without the quotes) "gnatmake intermittent build error" and
found
<https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=65451>
which was a bug report in 2015 about intermittent Ada build issues
which was immediately fixed back then.  However, my gnat version (=
4.9.2) is from 2014 so I don't have that bugfix and I am pretty sure
at this stage that bug 65451 is the issue that is causing the
intermittent Ada build issues for me. Therefore, I plan to use the
-DENABLE_ada=OFF option for my further testing until I can get access
to a later version of the Ada build tools myself, and I suggest others
who currently don't have access to Ada build tools with bug 65451
fixed should do the same.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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.sf.net); 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] Intermittent Ada example build failures are now gone again!

[Alan W. I. <ir...@be...>]

My last commit message (for commit 0df4e30) contained the following
paragraph concerning intermittent Ada example build failures during
various comprehensive tests that I encountered:

"These checks showed intermittent failures for certain parts
(xtraditional28a, xtraditional33a) of the Ada part of the build with
two separate complaints about various files written by the gnat
compiler.  At this stage I cannot figure out the source of this issue
since it comes and goes and is hard to reproduce.  But at one point I
got through the entire test above without Ada failures, and found an
obvious issue with the static OCaml binding library which I fixed and
which has absolutely nothing to do with Ada.  I then tried the test
above again, which failed for the nondynamic case for the build of one
of the Ada examples.  I then followed up by a specific static build of
the ocaml binding library that exercised the fixed build-system CMake
code for that case, and all was well.  Therefore, I think from these
piecemeal results that all is well with the current commit, but
further testing needs to be done as above once I figure out the source
of the intermittent Ada build errors."

One possibility to explain intermittent failures like this is some
hardware issue.  But after the above result I hammered my box with all
sorts of hardware tests which it passed with flying colours.  Part of
those tests involved a system reboot, and after that the comprehensive
test that previously was failing in different places due to different
Ada example build issues on successive runs completed with perfect
results!  Which is a nice result since it confirms the intrusive
changes I made for commit 0df4e30 are valid.  Furthermore, because the
Ada results were perfect for this comprehensive test after a reboot,
and many prior tests except for the ones used for this particular
commit for a Linux operating system that had been up for a long time,
there is a possibility that the gnatmake issue on Linux is it becomes
unreliable if the Linux platform is up too long.

So those good hardware tests, the good Ada example builds (and all
other builds and tests) that occurred in the comprehensive test
*after* a reboot, and the intermittent failures before the reboot just
for this commit occurring just for Ada example builds argues strongly
these intermittent failures are not due to hardware issues.  So that
leaves some issue with one or all of the components (gnatlink, etc.)
of my system gnatmake Ada build tool or the software stack those
components depend on as the likely culprit for the intermittent Ada
example build failures in this case.  And one possibility is the Linux
kernel itself was beginning to get wonky after many days up, and
gnatmake is peculiarly sensitive to such issues.

Anyhow, if you combine that bad gnatmake experience on Linux with
Arjen's known difficulties with gnatmake on Cygwin and Jerry's known
difficulties with gnatmake on Mac OS X, I get the impression that
gnatmake is pretty unreliable regardless of platform (perhaps through
no fault of its own other than possibly a design that depends on the
underlying operating system working perfectly). Anyhow, the observed
gnatmake unreliability is something to keep in mind going forward for
those of you who run into issues with gnatmake.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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.sf.net); 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] Is there some important reason for using the -single-module linker option on modern Mac OS X?

[Alan W. I. <ir...@be...>]

To those here with knowledge of Mac OS X linking:

According to <http://www.manpages.info/macosx/ld.1.html> there exists
the following ld options:

"
-single_module 
When building a dynamic library build the library so that it contains 
only one module.

-multi_module
When building a dynamic library build the library so that it contains
one module for each object file linked in. This is the default.
"

We currently use -single_module for linking on this platform
(see CMAKE_USER_MAKE_RULES_OVERRIDE in the top-level CMakeLists.txt
file).

However that override was imposed 12 (!) years ago to address a
linking issue that I suspect no longer exists.  For example, a google
search for the terms <cmake "-single_module"> found nothing relevant
beyond the CMake mailing-list discussion I generated about this issue
back then.

So unless I hear from Mac OS X experts here that there is some
important reason for using the -single_module option for linking
dynamic libraries on modern Mac OS X, I plan (on Sunday to give you a
couple of days to respond) to drop this override completely to conform
to how other CMake-based build systems configure linking of dynamic
libraries on Mac OS X.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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.sf.net); 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] Namespaced ALIAS library targets which are the first step in planned CMake best-practice upgrades

[Alan W. I. <ir...@be...>]

Recently (commit 593c07f) I have introduced namespaced ALIAS library
targets (e.g., the target PLPLOT::plplot created by the

add_library(PLPLOT::plplot ALIAS plplot)

command where plplot is an ordinary library target created previously)
into our build system, and I plan to extend their use to modules
(CMake speak for dll's) as well.  I am also planning to use namespaced
library and module targets for our install-tree build system (by using
the NAMESPACE PLPLOT:: argument of the install(EXPORT ...) command).

N.B. these namespaced versions of the targets associated with our
libraries and dll's are read only (i.e., you cannot change their
properties).  And they do not change the actual names of the
associated library and dll files.  But according to recent help I have
gotten on the CMake mailing list, use of namespaced versions of
targets for libraries and modules are considered to be CMake best
practice because they make it possible to be safer when using the
target_link_libraries command.  For example, consider

target_link_libraries(mycode.c plplot)

versus

target_link_libraries(mycode.c PLPLOT::plplot)

The "plplot" in the former potentially could refer to the plplot
target (if that exists).  But if that target does not exist (because
the user forgot to find the PLplot package which creates that imported
target), then CMake will happily find the plplot system library (if
that exists) and use that instead. Such subtle errors are not possible
for the latter form since CMake recognizes that any item in
target_link_libraries that has a "::" in the name must be a read-only
IMPORT or ALIAS target so if that target does not exist an immediately
obvious CMake error occurs which should be easy to diagnose and fix.

In sum, I consider this commit to be the first in a long series trying
to upgrade our build system (whose implementation style is roughly
consistent with the CMake bad practices that existed a decade ago) to
modern CMake best practices.  For an extremely useful introduction to
those good practices see the simple build-system example and
associated description of it at
<https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>.
That article had several examples of bad practice and the
corresponding good practice. So because those bad practices occur
extensively in our build system it appears that article is is going to
be my build-system bible for quite some time to come!

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

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.sf.net); 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-general] More questions about install

[Phil R. <p.d...@gm...>]

Hmm, not sure.

Are you rebuilding the whole library? Did you clean out the old build
directory? How did you download? Are any cygwin binary directories on your
path?

Phil

On Feb 4, 2018 11:32, "David Bergman" <dav...@ya...> wrote:

I am building on windows, DOS cmd build instructions as per

https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_Visual_CXX_CLI/

as before. cmake, nmake, nmake install.

I downloaded from the link you sent, not sure what happened.






On Sunday, February 4, 2018, 4:45:29 AM EST, Phil Rosenberg <
p.d...@gm...> wrote:


Hi David
Can I as what toolset you are using to build with?
Libltdl appears to be gnu related, but I thought you were building with the
standard windows toolset.

Phil

Get Outlook for Android <https://aka.ms/ghei36>



From: David Bergman
Sent: Sunday, February 4, 03:41
Subject: Re: [Plplot-general] More questions about install
To: Phil Rosenberg


Scratch this last email, I discovered a typo in my cmake command.  However,
after getting past this I am now getting the following,

Could not open driver module wxwidgets
libltdl error: No error information
NMAKE : fatal error U1077: '..\dll\test-drv-info.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return
code '
0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return
code '
0x2'
Stop.



On Saturday, February 3, 2018, 8:59:14 PM EST, David Bergman <
dav...@ya...> wrote:


Phil,

I have the latest but I'm getting new build errors.
The IDE install failed for most projects and eventually hung.  This
occurred before but restarting usually fixes.
The DOS install failed on the nmake command,

NMAKE : fatal error U1073: don't know how to make 'C:\\all'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio\2017
\Community\VC\Tools\MSVC\14.11.25503\bin\HostX86\x86\nmake.exe"' : return
code '
0x2'
Stop.

There were no errors in the cmake command and I'm doing this the same as
before (after help from Arjen to turn off cairo devices).

Could I manually add the code snippet to the header or do the libs need to
be rebuilt with the change?

Thanks,
David




On Saturday, February 3, 2018, 4:12:57 PM EST, Phil Rosenberg <
p.d...@gm...> wrote:


Hi David
I just had another look at the code comparing to the release you are using
and you were absolutely right, there is a bug there. I have just fixed that
and pushed the resulting code up to our git repo. You can pull the latest
code from there at https://sourceforge.net/p/
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>plplot
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>plplot
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>ci
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>/master/tree/
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/> in your browser,
or using git using the command

git clone git://git.code.sf.net/p/plplot/plplot

Let us know if you are having any difficulties grabbing it.

Phil
*From:* David Bergman <dav...@ya...>
*Sent:* Saturday, February 3, 2018 6:49:13 PM
*To:* Phil Rosenberg
*Subject:* Re: [Plplot-general] More questions about install

Phil,
Would the bug be in the header or the the call in the test code *.cpp?
If it's the header then I'd like the new version.  But if it's the driver
then would the documentation on wxWidgets classes be informative?
I notice typical declarations have wxTemplate<Type> * x = something(NULL),
to initialize the variable.
No such input appears in the driver.
Thanks,
David


On Saturday, February 3, 2018, 11:20:08 AM EST, Phil Rosenberg <
p.d...@gm...> wrote:


Hi David
Can I just confirm which version of PLplot you are using or if it is a
version grabbed from the git repo?

I ask because the line numbers don't seem to match up with the version I
have. But looking at my code I have a feeling that bug has been fixed.

Phil


On Feb 3, 2018 15:56, "David Bergman" <davidrbergman
<dav...@ya...>@yahoo.com <dav...@ya...>> wrote:

I tried running the wxPLplotDemo example and got the following compilation
error:

error C4703: potentially uninitialized local pointer variable 'drawDc' used
on line 378 of wxplplotwindow.h

Looking through the code it appears that every declaration of drawDC is as
follows

wxDC *drawDc = m_memoryDc;

except the last function

void wxPLplotwindow<WXWINDOW>:: setUseGraphicsContext( bool
useGraphicsContext )
{
    wxDC *drawDc;
...
}

I am not familiar with the details of the code but it appears that the
variable is set to something before it is used.  This is not modified code.

Please advise.
Thanks,
David








On Saturday, February 3, 2018, 4:01:05 AM EST, Phil Rosenberg <
p.d...@gm...> wrote:


Hi David
Yes, that's exactly what you need to do. <Type> can be pretty much any
wxWidget window class, although I suggest using wxPanel. Using wxFrame
works on Windows, but is apparently not good practice and some things don't
work properly if you render directly to a wxFrame on Linux.

In terms of a demo, check out wxPLplotDemo.cpp in the PLplot source code.
It is in examples/c++

Phil

*From:* David Bergman <davidrbergman <dav...@ya...>@yahoo.com
<dav...@ya...>>
*Sent:* Saturday, February 3, 2018 1:59:39 AM
*To:* plplot <plp...@li...>-
<plp...@li...>devel
<plp...@li...>@lists. sourceforge.net
<plp...@li...>; Phil Rosenberg
*Subject:* Re: [Plplot-general] More questions about install

Phil,

I am at the point where I have been able to successfully build new projects
for wxWidgets and PLplot independently from scratch, compile-link-run.
I copied some code from a wxPLplotDemo into a new GUI I've developed.

The following declaration gives an error,

wxPLplotwindow* plotwindow;

"argument list missing"

Should the format be

wxPLplotwindow<type> etc

or is there still an issue with the wx drivers?  I have header, lib, and
dll for wxwidgets functions, and enable_wxwidgets = ON was present in the
cmake output.

Thanks in advance for our help.
David


On Friday, February 2, 2018, 12:14:04 PM EST, Phil Rosenberg <
p.d...@gm...> wrote:


Hi David
Integrating wxWidgets into PLplot should be as simple as defining the WXWIN
system variable before running cmake. Cmake should see that and
automagically find wxWidgets and build that backend for the library along
with the example.

Where things may get complicated is matching the library settings for
Unicode, static vs dynamic runtimes and debug vs release builds. I'm not
sure if these only need matching for static libraries or if dlls need these
matching too.

If you have any trouble just drop us an email.

Phil

On Feb 2, 2018 14:37, "David Bergman" <davidrbergman
<dav...@ya...>@yahoo.com <dav...@ya...>> wrote:

Phil,

Thanks for reaching out.
At this point the VS IDE build and install has never worked right, without
massive errors.  The latest trial produced the release version without
error but not the debug.

Following the instructions for a command line build, with help from Arjen,
in windows (not Cygwin) produced a directory without errors.  The IDE build
and the command prompt build are significantly different in the content (in
my opinion).

I've been able to build a VS project from scratch using PLplot headers and
dll and it worked.  So, I'm counting that as a success.  I have not yet had
a chance to do more complex plots, fully test the functions, or integrate
with widgets which is my intent.  I may need more help in the future.

I will say that there was one dll that the VS compiler/linker said was
corrupted but I don't recall which one.
Just to get past it and get something working I deleted this from the
project.  It may come back to bite me later.

David



On Friday, February 2, 2018, 9:23:06 AM EST, Phil Rosenberg <
p.d...@gm...> wrote:


Hi David
I would have gotten involved in this thread earlier if I had realised it
had moved to Visual Studio an wxWidgets and away from Cygwin. Sorry for
just reading the title and not the text.

I always use the visual studio IDE, I don't know if that is the route you
ended up going down. Have you found the instructions at
https://sourceforge.net/p/
<https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/>
plplot
<https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/>/wiki/Configure_PLplot_
for_the_Visual_Studio_IDE/
<https://sourceforge.net/p/plplot/wiki/Configure_PLplot_for_the_Visual_Studio_IDE/>?
They are a little out of date, but I don't think much has changed.

Phil

On 26 January 2018 at 14:57, David Bergman via Plplot-general <plplot
<plp...@li...>-general@lists. sourceforge.net
<plp...@li...>> wrote:

That worked.  Are there any good tutorials for using this with wxWidgets
and VC++?
I think I need to set up the wxWidgets driver.
You may hear from me again...
David


On Friday, January 26, 2018, 9:38:32 AM EST, Arjen Markus <
Arj...@de...> wrote:


Hi David,

That is easier – did you install the stuff via “nmake install” or are you
working from the build directory?

That is what I usually do and then I have to expand the PATH environment
variable:

set PATH=d:\plplot-build-dir\dll;% PATH%
cd examples\cxx
x01.exe

Fill in the right directory for “plplot-build-dir” above.

Regards,

Arjen

*From:* David Bergman [mailto:davidrbergman@yahoo. com
<dav...@ya...>]
*Sent:* Friday, January 26, 2018 3:34 PM
*To:* Arjen Markus
*Cc:* Plplot <Plp...@li...>-general@lists.
sourceforge.net <Plp...@li...> (plplot
<plp...@li...>-general@lists. sourceforge.net
<plp...@li...>)
*Subject:* Re: RE: RE: [Plplot-general] More questions about install

Arjen,
Thanks, that worked to get past this hurdle.  nmake and nmake install
worked.
Frankly, I'm not sure what state plplot is in but I tried running an
example exe and got an error message that plplotcxx.dll is not installed on
my computer.
However, this *.dll does exists in the dll folder.
How does that work?
David


On Friday, January 26, 2018, 8:15:24 AM EST, Arjen Markus <
Arj...@de...> wrote:


Hi David,

I was a bit hasty, I think – the cairo device driver actually consists of a
whole slew of them and you would have to set all of them to off to avoid
the cairo device (things like PLD_wincairo and PLD_epscairo). If I read the
CMake files correctly, then you should be able to turn off that family of
devices by -DDEFAULT_NO_CAIRO_DEVICES=ON. (I hope I am right this time)

Regards,

Arjen


*From:* David Bergman [mailto:davidrbergman@yahoo. com
<dav...@ya...>]
*Sent:* Thursday, January 25, 2018 2:12 PM
*To:* Arjen Markus
*Cc:* Plplot <Plp...@li...>-general@lists.
sourceforge.net <Plp...@li...> (plplot
<plp...@li...>-general@lists. sourceforge.net
<plp...@li...>)
*Subject:* Re: RE: [Plplot-general] More questions about install

Arjen,
Thanks.  I tried again with your suggestion but the following warning.

CMake Warning:
  Manually-specified variables were not used by the project:

PLD_cairo

I tried variant, e.g. all cap, etc, just in case there was a typo.  No luck.

Any other suggestions would be appreciated.
On another note, not sure is you saw my other email status.  Installing
from the IDE seemed to work for the Release build but not the Debug,
several projects failed to build.  I cannot decipher why one would build
and the other not.  Additionally the *.exe for the examples did not get
created as in previous installs.  It seems that each try produces a
different state.

Thank you in advance.
David



On Thursday, January 25, 2018, 2:44:51 AM EST, Arjen Markus <
Arj...@de...> wrote:


Hi David,

Wrt your message (it got caught in my spam filter for reasons best known to
itself):

“Arjen,

I just installed CMake 3.9.4 and tried the build from a DOS command prompt
(not using VS INSTALL).  Same issues, partial output is attached.
It crashes at ciaro [26%].  Do I need ciaro to use plplot?

David”

Apparently the build system is finding libraries that are connected to the
cairo device. Unfortunately, they are not truly compatible. The best way to
take care of that is to use the option –DPLD_cairo=OFF, forcing the build
system to ignore that device. This kind of things sometimes happens.

Regards,

Arjen



*Arjen** Markus*
Sr. Adviseur/Onderzoeker
T
+31(0)88 335 8559 <+31%2088%20335%208559>
E
Arj...@de...


* www.deltares.com* <http://www.deltares.com/>
Postbus <http://www.deltares.com/>
177 <http://www.deltares.com/>
2600 MH Delft <http://www.deltares.com/>


Please consider the environment before printing this email
<http://www.deltares.com/>
DISCLAIMER: This message is intended exclusively for the addressee(s) and
may contain confidential and privileged information. If you are not the
intended recipient please notify the sender immediately and destroy this
message. Unauthorized use, disclosure or copying of this message is
strictly prohibited. The foundation ' <http://www.deltares.com/>Stichting
<http://www.deltares.com/> <http://www.deltares.com/>Deltares
<http://www.deltares.com/>', which has its seat at Delft, The Netherlands,
Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
<http://www.deltares.com/>
DISCLAIMER: This message is intended exclusively for the addressee(s) and
may contain confidential and privileged information. If you are not the
intended recipient please notify the sender immediately and destroy this
message. Unauthorized use, disclosure or copying of this message is
strictly prohibited. The foundation 'Stichting Deltares', which has its
seat at Delft, The Netherlands, Commercial Registration Number 41146461, is
not liable in any way whatsoever for consequences and/or damages resulting
from the improper, incomplete and untimely dispatch, receipt and/or content
of this e-mail.
DISCLAIMER: This message is intended exclusively for the addressee(s) and
may contain confidential and privileged information. If you are not the
intended recipient please notify the sender immediately and destroy this
message. Unauthorized use, disclosure or copying of this message is
strictly prohibited. The foundation 'Stichting Deltares', which has its
seat at Delft, The Netherlands, Commercial Registration Number 41146461, is
not liable in any way whatsoever for consequences and/or damages resulting
from the improper, incomplete and untimely dispatch, receipt and/or content
of this e-mail.

------------------------------ ------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
______________________________ _________________
Plplot-general mailing list
Plplot <Plp...@li...>-general@lists. sourceforge.net
<Plp...@li...>
https://lists.sourceforge.net/ lists/
<https://lists.sourceforge.net/lists/listinfo/plplot-general>listinfo
<https://lists.sourceforge.net/lists/listinfo/plplot-general>/
<https://lists.sourceforge.net/lists/listinfo/plplot-general>plplot
<https://lists.sourceforge.net/lists/listinfo/plplot-general>-general
<https://lists.sourceforge.net/lists/listinfo/plplot-general>