plplot-devel — Technical discussion about PLplot development

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

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

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

Re: [Plplot-devel] test-drv-info

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

On 2019-09-12 17:59+0100 Phil Rosenberg wrote:

> Hi Alan
> I think I have found a problem with test-drv-info. I think it is
> unaware of the CMake flag CMAKE_DEBUG_POSTFIX. I've started using
> -DCMAKE_DEBUG_POSTFIX=d as part of my cmake commands to add d to the
> end of all debug libraries. But this causes test-drv-info to report:
> Could not open the driver module <module>
> If I go onto the command line ant try running test-drv-info myself,
> adding d to the module name, I get
> Could not read symbol plD_DEVICE_INFO_<module>d in driver module <module>d
>
> Is it possible to pull the postfix into the test-drv-info source? It
> would simply need concatenating at line 76 of test-drv-info.c

Hi Phil:

I have no objection to such a change so long as it is completely
general (any postfix string of any length that the user has specified
for any possible CMAKE_BUILD_TYPE).  For example, it should work
(to take an absurd example) if the user specifies

-DCMAKE_BUILD_TYPE=Release -DCMAKE_RELEASE_POSTFIX="_my_release_version_of_this_library"

and also, of course, the case that interests you

-DCMAKE_BUILD_TYPE=Debug -DCMAKE_DEBUG_POSTFIX="d"

Please try the following change on line 176 of
drivers/CMakeList.txt where CMake does the necessary concatanation:

- "${WRITEABLE_TARGET}" ${SOURCE_ROOT_NAME}
+ "${WRITEABLE_TARGET}" ${SOURCE_ROOT_NAME}"${CMAKE_${CMAKE_BUILD_TYPE}_POSTFIX}"

If that works for the two CMAKE_BUILD_TYPES and corresponding CMAKE...POSTFIX variables
above, please go ahead and commit that change.

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] test-drv-info

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

Hi Alan
I think I have found a problem with test-drv-info. I think it is
unaware of the CMake flag CMAKE_DEBUG_POSTFIX. I've started using
-DCMAKE_DEBUG_POSTFIX=d as part of my cmake commands to add d to the
end of all debug libraries. But this causes test-drv-info to report:
Could not open the driver module <module>
If I go onto the command line ant try running test-drv-info myself,
adding d to the module name, I get
Could not read symbol plD_DEVICE_INFO_<module>d in driver module <module>d

Is it possible to pull the postfix into the test-drv-info source? It
would simply need concatenating at line 76 of test-drv-info.c

Phil

Re: [Plplot-devel] Font issues for -dev plm and plrender

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

On 2019-09-11 21:41-0400 Jim Dishaw wrote:

>
>
>> On Sep 11, 2019, at 9:30 PM, Alan W. Irwin <Ala...@gm...> wrote:
>>
>> Hi Jim:
>>
>> My understanding is plbuf supports unicode-aware system fonts.  But
>> my recent test (for details of the test, see the commit message for the commit git-decribed
>> as plplot-5.15.0-31-g3af0b2cf1) showed the combination of -dev plm (which I presume writes
>> plbuf information to a file) and plrender (which I presume reads that information) is
>> still using Hershey fonts!
>>
>> Could you please figure out a fix for this issue?
>>
> I’ll take a look at it this weekend.  I think the font support may need to be cleaned up because there is a lot of duplicated code.

Thanks for being willing to try to fix this and good luck with that effort!

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] Font issues for -dev plm and plrender

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

> On Sep 11, 2019, at 9:30 PM, Alan W. Irwin <Ala...@gm...> wrote:
> 
> Hi Jim:
> 
> My understanding is plbuf supports unicode-aware system fonts.  But
> my recent test (for details of the test, see the commit message for the commit git-decribed
> as plplot-5.15.0-31-g3af0b2cf1) showed the combination of -dev plm (which I presume writes
> plbuf information to a file) and plrender (which I presume reads that information) is
> still using Hershey fonts!
> 
> Could you please figure out a fix for this issue?
> 
I’ll take a look at it this weekend.  I think the font support may need to be cleaned up because there is a lot of duplicated code.

[Plplot-devel] Font issues for -dev plm and plrender

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

Hi Jim:

My understanding is plbuf supports unicode-aware system fonts.  But
my recent test (for details of the test, see the commit message for the commit git-decribed
as plplot-5.15.0-31-g3af0b2cf1) showed the combination of -dev plm (which I presume writes
plbuf information to a file) and plrender (which I presume reads that information) is
still using Hershey fonts!

Could you please figure out a fix for this 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] [Plplot-general] Problem with LNK2019 error unresolved external

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

Here are a set of instructions that seem to work for me to build a set of
dlls. I created a new user on my machine and a fresh directory structure
and from this clean setup I got good build results.

1. Download wxWidgets-3.0.4 to C:\test\src\ and use 7zip to extract to a
folder called wxWidgets-3.0.4
   C:\test\src\wxWidgets-3.0.4 now contains files called configure,
.gitattributes, etc
2. Open C:\test\src\wxWidgets-3.0.4\build\msw\wx_vc12.sln, I get asked
about retargetting projects. I leave everything ticked and hit OK
3. Select DLL Debug and x64 configurations. Hit f7 to build.
4. Change DLL Debug to DLL Release and keep x64. Hit f7 to build again.
5. Add C:\test\bin;C:\test\src\wxWidgets-3.0.4\lib\vc_x64_dll; to the path
variable.
6. Create a variable WXWIN with a value of C:\test\src\wxWidgets-3.0.4\
7. Download plplot-5.15.0 to C:\test\src\ and use 7zip to extract to a
folder called plplot-5.15.0. The folder C:\test\src\plplot-5.15.0 now
contains the ABOUT and INSTALL files etc.
8. Start a developer command prompt for VS 2017 and execute these commands
(if you started this already, close it and reopen to see the new
environment variables)
   cd C:\test\src\plplot-5.15.0
   mkdir build
   cd build
   set CXXFLAGS=/DUNICODE /D_UNICODE
   set CFLAGS=/DUNICODE /D_UNICODE
   cmake .. -G "Visual Studio 15 2017 Win64"
-DCMAKE_DINSTALL_PREFIX="C:\test" -DCMAKE_DEBUG_POSTFIX=d
   NOTE THE DEBUG POSTFIX IS TO ENABLE RELEASE AND DEBUG LIBS TO INHABIT
THE SAME DIRECTORY AS IT ADD d TO THE FILENAMES
9. Open the file C:\test\src\plplot-5.15.0\build\plplot.sln
10. Ensure Dubug and x64 configuration are selected. Right click the
INSTALL project and select build.
11. Change to Release, sticking with x64 configuration. Right click the
INSTALL project and select build.


I have never built the examples in the share/plplot/examples directory. But
Let me know how you get on with this setup.

Phil



On Mon, 9 Sep 2019 at 20:38, David Bergman <stu...@gm...>
wrote:

> No it is not.
>
>
> On 9/9/2019 3:33 PM, Phil Rosenberg wrote:
>
> Is the directory containing your old dlls listed in your path variable. If
> so, the old ones can be found by mistake and erroneously used.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* stuntguitar1969 <stu...@gm...>
> <stu...@gm...>
> *Sent:* Monday, September 9, 2019 7:37:47 PM
> *To:* Phil Rosenberg <p.d...@gm...> <p.d...@gm...>;
> plp...@li...
> <plp...@li...>
> <plp...@li...>
> *Subject:* Re: [Plplot-general] Problem with LNK2019 error unresolved
> external
>
> I will double check everything.   Past issues in the thread have resolved
> by rebuilding and making sure x64 is chosen everywhere.   I cannot rule out
> that something might be 32 bit but I tried to be thorough in the last build
> and install of everything.   I do have my old libs and dlls but they are in
> a different dir which is not used in the project.  I'll try the example
> again just to be sure.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
> -------- Original message --------
> From: Phil Rosenberg <p.d...@gm...> <p.d...@gm...>
> Date: 9/9/19 2:20 PM (GMT-05:00)
> To: plp...@li..., David Bergman
> <stu...@gm...> <stu...@gm...>
> Subject: Re: [Plplot-general] Problem with LNK2019 error unresolved
> external
>
> Corrupt file error sounds like you are mixing 64 and 32 bit exes and dlls.
> I think I've had that error with some libraries before and found that was
> my mistake.
>
> Is your install bin directory on your path? Do you have any old dlls
> somewhere that might be on your path?
>
> I usually use static libs. I used a dll version of wxwidgets about 6
> months ago, so I know things worked back then. But I'm back to using static
> libs again. I will build a dll version of plplot this evening and send you
> exactly the commands I used.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* David Bergman <stu...@gm...>
> <stu...@gm...>
> *Sent:* Monday, September 9, 2019 6:31:00 PM
> *To:* Phil Rosenberg <p.d...@gm...> <p.d...@gm...>;
> plp...@li...
> <plp...@li...>
> <plp...@li...>
> *Subject:* Re: [Plplot-general] Problem with LNK2019 error unresolved
> external
>
>
> Phil,
>
> I've gotten a little further.  I tried to run one of the examples building
> a VS project and sln.  Making sure everything was aligned w/r to he choice
> x64 I got a corrupted file error.
>
> Error    LNK1107    invalid or corrupt file: cannot read at 0x310
> plplotExamples    C:\build-plplot-new-man\dll\csirocsa.dll    1
>
> I am not sure what to do.  Looking through some of the old blog posts of
> the issues I had last year it seems that is was also an issue then.
>
> When you do your build were you able to get everything using the sln or
> did you have to install at the command prompt too.  That rings a bell and I
> think I wound up using nmake.
>
> Can you confirm your build/install procedure and perhaps shed some light
> on why csirocsa.dll would be corrupted?
>
> Thank you for your help.
>
> David
>
>
>
> On 9/7/2019 3:34 AM, Phil Rosenberg wrote:
>
> Hi David
> Sounds like either one of the libs has been forgotten, or you are building
> a 32bit exe and trying to link to the 64 bit libs you just built.
>
> Might be worth noting that I think the naming convention of the libs
> changed at some point. They used to have a d suffix to indicate using
> double precision. This has been dropped I think. So you might need to
> update the lib names in your project.
>
> Phil
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* David Bergman <stu...@gm...>
> <stu...@gm...>
> *Sent:* Friday, September 6, 2019 9:20:57 PM
> *To:* Phil Rosenberg <p.d...@gm...> <p.d...@gm...>;
> plp...@li...
> <plp...@li...>
> <plp...@li...>
> *Subject:* Re: [Plplot-general] Problem with LNK2019 error unresolved
> external
>
>
> Phil,
>
> As per our last correspondence I had succeeded in getting the widgets
> headers and drivers built when I changed from Win64 to no Win64.  But I
> still got an install error in the IDE (sent in a previous email).  You had
> suggested that perhaps I didn't build widgets using 64bit so I decided to
> purge everything and start over.  I built the widgets files using their sln
> with x64 set.  Then built plplot with cmake no problem and widgets was
> declared ON as expected.  Using the IDE and the sln to INSTALL led to
> hanging and errors three times in a row.  After the 3rd time I just looked
> in the folders and figured if I can find everything I might be okay.  My
> recollection is that this happened last time too (back in 2017).
>
> The example I was trying to run was a simple one of my own that plotted
> various 3-dim mesh surfaces.
>
> I did not try to build the official plplot examples yet.  Perhaps I should
> try that first.
>
> I don't know if what I've written is helpful in helping you help me get it
> working.
>
> David
>
>
>
> On 9/6/2019 3:44 PM, Phil Rosenberg wrote:
>
>
> Is this building the examples? Sounds like the libs are not being linked
> to properly.
>
> Did you get past the wxwidgets problem?
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* David Bergman <stu...@gm...>
> <stu...@gm...>
> *Sent:* Friday, September 6, 2019 6:17:59 PM
> *To:* plp...@li...
> <plp...@li...>
> <plp...@li...>
> *Subject:* [Plplot-general] Problem with LNK2019 error unresolved external
>
> All,
>
> I have made some progress with building and installing the new plplot
> with a new wxwidets using VS 2017.
>
> I still have not gone past the install process in the IDE w/o an error
> but I seem to have all the headers and dll I need (though I'm not sure
> if they are corrupted).
>
> At present I've decided to move forward with what I have and try a
> simple example I wrote that worked with my previous config.
>
> I get unresolved externals, 14 to be exact.  Basically every plplot
> function I call seems to cause this.  A few example are provided.
>
> plAlloc2dGrid
>
> and all the plstream functions like box3, col0, font, etc.
>
> Typically what I cause this it's due to a function declaration in a
> class that is not defined elsewhere.
>
> It "seems like" my new build has the same files as the old one and the
> projects are comparable (with only diffs being the location of the new
> folders).
>
> Thanks in advance for your help.
>
> David
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>
> --
> David Bergman
> David R Bergman Music LLC
> "Have Guitar Will Travel"
> Morristown NJ
> 551...@gm...
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>
> --
> David Bergman
> David R Bergman Music LLC
> "Have Guitar Will Travel"
> Morristown NJ
> 551...@gm...
>
> --
> David Bergman
> David R Bergman Music LLC
> "Have Guitar Will Travel"
> Morristown NJ
> 551...@gm...
>
>

Re: [Plplot-devel] Tentative plan for removing our support of Qt4

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

On 2019-09-07 16:46+0930 Jonathan Woithe wrote:

> Hi Alan
>
> On Mon, Sep 02, 2019 at 01:36:30PM -0700, Alan W. Irwin wrote:
>> As someone here with a large familiarity with Qt, I would appreciate
>> you letting me know if you forsee any trouble with this overall plan
>> to remove our Qt4 support.  And comments on this plan from the other
>> PLplot developers here are also encouraged.
>
> Depending on the timing between the versions which make up the plan, I
> suspect this will be fine.  FYI Slackware does not (yet) ship Qt5 (there are
> various reasons for this, the discussion of which is outside the scope of
> this thread).  There is a third-party source of Qt5 for Slackware though
> which users can install if they have a need for Qt5.
>
> Therefore once PlPlot 5.18.0 rolls around, plplot will no longer be usable
> under a standard Slackware installation unless the Qt5 packages from the
> AlienBob repository are installed.  The other option (which I'm personally
> *really* hoping for) is that Qt5 ships in Slackware by that time.  If this
> happens, the yet to be released Slackware 15 will be the first Slackware
> version to ship Qt5 as part of the distribution.
>
> Given the low number of users of plplot on Slackware I don't believe your
> plan should be changed as a result of the above information, especially
> since there is a viable workaround.  I mention it only for completeness so
> people are aware of the possible impact and the steps needed to circumvent
> it.

Hi Jonathan:

Thanks for this information about the current lack of Qt5 on official
Slackware.  My gut feeling is Qt4 has become dated and Qt5 is its
worthy successor.  Therefore, I would be surprised if this lack of Qt5
on Slackware persists much longer, i.e., I think it is likely you will
get your wish sooner rather than later.

But if that doesn't happen for some reason, PLplot-5.18.0 would still
be usable on official Slackware if a user decided not to use the
workaround you mentioned above.  Of course, Qt-related components of
PLplot such as the devices provided by our "qt" device driver would be
automatically dropped by our build system when it did not find Qt5,
but other excellent choices for devices such as those provided by our
"cairo" device driver would still be available (assuming our build
system finds on Slackware the Pango and Cairo libraries upon which our
"cairo" device driver depends).

By the way, Slackware was my very first Linux distribution (in 1996 on
a pentium-133).  Happy days!

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] Tentative plan for removing our support of Qt4

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

On 2019-09-06 21:33-0400 Hazen Babcock wrote:

>
>> 
>> @Hazen: In light of the smoke binding issue we should discuss this
>> still tentative roadmap further.
>> 
>> That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed
>> when we drop support for Qt4 because [smoke is not available for
>> Qt5](https://news.ycombinator.com/item?id=20636312).  You apparently
>> implemented the PLplot smoke binding because that binding was needed
>> by another independent project of yours.
>
> No problem, go ahead and remove the smoke bindings.

Hi Hazen:

Thanks for that clarification.  As a result, the timing of the roadmap
for removing everything to do with Qt4 (including our smoke and pyqt4 bindings)
from PLplot is much more certain and now reads as follows:

Revised roadmap:

* PLplot-5.17.0.  Officially deprecate everything in PLplot that is
   related to Qt4 in our release notes and also mention there the
   planned dropping of everything in PLplot that is related to Qt4 in
   PLplot-5.18.0.  Despite those planned remarks in the release notes,
   the only change from the Qt-related build system logic for 5.16.0
   that has just been committed will be a deprecation warning to the
   user when they specify -DPLPLOT_USE_QT5=OFF.

* PLplot-5.18.0.  Drop everything in PLplot that is related to Qt4.
   That essentially means removing all logic stanzas in our build
   system that are currently only exercised when -DPLPLOT_USE_QT5=OFF.
   The removal of our smoke binding and our pyqt4 binding (only
   available when -DPLPLOT_USE_QT5=OFF) will be part of this change.
   The result of this change should be a substantial simplification of
   our build system.  Also, our current lack of testing of the
   -DPLPLOT_USE_QT5=OFF case (because I don't have time to test both
   -DPLPLOT_USE_QT5=ON and -DPLPLOT_USE_QT5=OFF) obviously will no
   longer be a concern after this change.

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] Tentative plan for removing our support of Qt4

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

Hi Alan

On Mon, Sep 02, 2019 at 01:36:30PM -0700, Alan W. Irwin wrote:
> As someone here with a large familiarity with Qt, I would appreciate
> you letting me know if you forsee any trouble with this overall plan
> to remove our Qt4 support.  And comments on this plan from the other
> PLplot developers here are also encouraged.

Depending on the timing between the versions which make up the plan, I
suspect this will be fine.  FYI Slackware does not (yet) ship Qt5 (there are
various reasons for this, the discussion of which is outside the scope of
this thread).  There is a third-party source of Qt5 for Slackware though
which users can install if they have a need for Qt5.

Therefore once PlPlot 5.18.0 rolls around, plplot will no longer be usable
under a standard Slackware installation unless the Qt5 packages from the
AlienBob repository are installed.  The other option (which I'm personally
*really* hoping for) is that Qt5 ships in Slackware by that time.  If this
happens, the yet to be released Slackware 15 will be the first Slackware
version to ship Qt5 as part of the distribution.

Given the low number of users of plplot on Slackware I don't believe your
plan should be changed as a result of the above information, especially
since there is a viable workaround.  I mention it only for completeness so
people are aware of the possible impact and the steps needed to circumvent
it.

Regards
  jonathan

Re: [Plplot-devel] Tentative plan for removing our support of Qt4

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

> 
> @Hazen: In light of the smoke binding issue we should discuss this
> still tentative roadmap further.
> 
> That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed
> when we drop support for Qt4 because [smoke is not available for
> Qt5](https://news.ycombinator.com/item?id=20636312).  You apparently
> implemented the PLplot smoke binding because that binding was needed
> by another independent project of yours.

No problem, go ahead and remove the smoke bindings.

-Hazen

Re: [Plplot-devel] Tentative plan for removing our support of Qt4

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

On 2019-09-02 13:36-0700 Alan W. Irwin wrote:

> Hi António:
>
> Your fix of the serious Qt5 font configuration bug for PLplot made our
> Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results
> for the first time ever.  So ever since that release it has been on my
> mind to greatly reduce the complexity of our build-system *and*
> testing of our Qt and PyQt components by only supporting Qt5 (i.e.,
> dropping our support for Qt4).
>
> The current build-system situation is Qt4 is looked for first, but if
> it is not found Qt5 is used as a backup with the exception that Qt5 is
> forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to
> OFF).  So my proposed plan to reach the above goal with minimum
> disruption for users is the following:
>
> * PLplot-5.16.0.  Use the exact same build system logic except that 4
>  and 5 are swapped.  That is Qt5 is looked for first, but if it is
>  not found Qt4 is used as a backup with the exception that Qt4 is
>  forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to
>  OFF).  Warn in the release notes of this change and the
>  corresponding replacement of the PLPLOT_USE_QT5 option with
>  PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4
>  support in the next release and remove it in the next release
>  after that.
>

To Hazen and António:

@António: Thanks for your support (in a different post) for my preliminary
roadmap for dropping Qt4.

@Both: In the event, the above "5.16.0" step was much easier than the
intrusive change I described above.  Instead, all I essentially did
was to change the default value for PLPLOT_USE_QT5 from OFF to ON.
(See the Qt-related change in the new (commit 24d0bdf70) version of
README.release for the details.)

Revised rest of the roadmap.

* PLplot-5.17.0.  Officially deprecate Qt4 in the release notes and
   also say we intend to drop it for 5.18.0 there.  The only change
   from the above build system logic is an additional deprecation warning to
   the user when they specify -DPLPLOT_USE_QT5=OFF and no
   fall back to Qt5 if Qt4 cannot be found.

  * PLplot-5.18.0 (or whenever we decide to pull the plug on Qt4
    support considering the smoke issue below).  Completely remove
    support for Qt4 (which will finally achieve the desired
    build-system and test simplifications which is the fundamental
    motivation for this change).

@Hazen: In light of the smoke binding issue we should discuss this
still tentative roadmap further.

That smoke binding issue is bindings/qt_gui/smoke/ needs to be removed
when we drop support for Qt4 because [smoke is not available for
Qt5](https://news.ycombinator.com/item?id=20636312).  You apparently
implemented the PLplot smoke binding because that binding was needed
by another independent project of yours.

Assuming you do want to develop a Qt5-based binding which would
satisfy the needs of your independent project in the same way the your
current Smoke Qt4-based binding does, from the "history lesson" in the
above URL it appears one possible way forward for Qt5 bindings of any
kind is [Shiboken](https://wiki.qt.io/Qt_for_Python/Shiboken).  For
example, Shiboken is used to implement pyside2 (python binding for
Qt5), but I have no clue how difficult it would be for you to replace
your smoke binding with a corresponding Shiboken binding.  Anyhow,
please let me know whether you plan to replace the above smoke binding
once it is removed as part of dropping our Qt4 support.  And your
input on the timing of dropping our Qt4 support is needed as well.

By the way, when that support is dropped our pyqt4 binding will have
to be removed as well, but that should not be an issue at least for
now since our current pyqt5 binding seems to work OK.  But that pyqt5
binding does depend on the external pyqt5 project which depends on
another external project (sip).  So our pyqt5 binding will become
vulnerable if either the external projects pyqt5 or sip becomes
unmaintained.

The above pyside2 project is a recent competitor to pyqt5.  And
contrary to the expectations of the above 2017 discussion, pyside2 has
been released and is apparently going strong.  (For example, Debian
Buster has many pyside2 packages and the necessary shiboken packages
to support pyside2.)  Therefore, if you were interested, I would
encourage you to implement a pyside2 binding and pyside2_example
corresponding to pyqt5_example just in case it turns out that external
pyqt5 of sip ever goes the same way that smoke has gone.

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

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

Hi Alan,

I have the first results from this exercise. I will send the details in an off-list message, but the short story is that CMake seems to choke on generating the makefiles when support for D is included. From my inspection of the output files the reason for the failure is not at all clear. The D bindings are turned on but then CMake tells me something went wrong during the last stage, writing the actual makefiles.

Regards,

Arjen

-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: 02 September 2019 12:27
To: Arjen Markus <Arj...@de...>
Cc: Takeshi Enomoto <ten...@us...>; PLplot development list <Plp...@li...>
Subject: RE: [Plplot-devel] D language support topic

On 2019-09-02 07:47-0000 Arjen Markus wrote:

> Hi Alan,
>
> I will have a look at this - I have built CMake before, that should not be a problem 😊. I have no experience, however, with the D compiler you mention.

Hi Arjen:

Thanks for your willingness to do the requested test_d tests on MSYS2 with dmd.  The results of those tests should help me to get our CMake D language support working correctly for the Windows-dmd case for both test_d and PLplot.

Alan

>
> -----Original Message-----
> From: Alan W. Irwin <Ala...@gm...>
> Sent: 01 September 2019 01:40
> To: Takeshi Enomoto <ten...@us...>; Arjen Markus
> <Arj...@de...>; PLplot development list
> <Plp...@li...>
> Subject: Re: [Plplot-devel] D language support topic
>
> To Takeshi and Arjen:
>
> I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this
> topic to the PLplot master branch at SourceForge.  This new D language
> support (see README.release for details) works perfectly on Linux (all
> comprehensive tests have passed perfectly on my Debian Buster
> platform), and I hope Takeshi (who contributed part of the changes
> that have gone into this push) would be willing to test this new D
> language support for PLplot on the MacPorts platform and Arjen on the
> MSYS2 platform.
>
> @Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts.
> But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly.
>
> @Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.html&amp;data=02%7C01%7C%7C109db2fc5d8c42715d0308d72f90094d%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637030167988327359&amp;sdata=ZWqaEu0F4OLFU0m6yjhdjTn%2FuyI3KvPd1WUdGKGGdaI%3D&amp;reserved=0).
> I would appreciate you testing our new D language support on MSYS2 with that compiler.
> As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself.
>
> 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
> __________________________
> 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.
>

__________________________
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
__________________________
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] Tentative plan for removing our support of Qt4

[António R. T. <ar...@gm...>]

Hi Allan,
I really think that is safe to remove qt4 support. Sooner or later qt4 will
not be available by default in  a normal linux distribution.

So I agree with your proposed roadmap.

cheers,


On Mon, Sep 2, 2019 at 9:36 PM Alan W. Irwin <Ala...@gm...>
wrote:

> Hi António:
>
> Your fix of the serious Qt5 font configuration bug for PLplot made our
> Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results
> for the first time ever.  So ever since that release it has been on my
> mind to greatly reduce the complexity of our build-system *and*
> testing of our Qt and PyQt components by only supporting Qt5 (i.e.,
> dropping our support for Qt4).
>
> The current build-system situation is Qt4 is looked for first, but if
> it is not found Qt5 is used as a backup with the exception that Qt5 is
> forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to
> OFF).  So my proposed plan to reach the above goal with minimum
> disruption for users is the following:
>
> * PLplot-5.16.0.  Use the exact same build system logic except that 4
>    and 5 are swapped.  That is Qt5 is looked for first, but if it is
>    not found Qt4 is used as a backup with the exception that Qt4 is
>    forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to
>    OFF).  Warn in the release notes of this change and the
>    corresponding replacement of the PLPLOT_USE_QT5 option with
>    PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4
>    support in the next release and remove it in the next release
>    after that.
>
> * PLplot-5.17.0.  Deprecate Qt4, i.e., use it as a fall back from
>    Qt5 *only* if the users sets -DPLPLOT_QT4=ON.  Warn in the release
> notes of
>    this change and also warn we plan to remove support for Qt4 in
>    the next release.
>
> * PLplot-5.18.0.  Completely remove support for Qt4 which will finally
> achieve the
>    desired simplifications mentioned above.
>
> As someone here with a large familiarity with Qt, I would appreciate
> you letting me know if you forsee any trouble with this overall plan
> to remove our Qt4 support.  And comments on this plan from the other
> PLplot developers here are also encouraged.
>
> I will likely implement the 5.16.0 part of the above plan late this
> week if there are no strong disagreements expressed here in the
> next several days.
>
> 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
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

[Plplot-devel] Tentative plan for removing our support of Qt4

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

Hi António:

Your fix of the serious Qt5 font configuration bug for PLplot made our
Qt5 results in PLplot-5.15.0 essentially as good as our Qt4 results
for the first time ever.  So ever since that release it has been on my
mind to greatly reduce the complexity of our build-system *and*
testing of our Qt and PyQt components by only supporting Qt5 (i.e.,
dropping our support for Qt4).

The current build-system situation is Qt4 is looked for first, but if
it is not found Qt5 is used as a backup with the exception that Qt5 is
forced if the user specifies -DPLPLOT_USE_QT5=ON (which defaults to
OFF).  So my proposed plan to reach the above goal with minimum
disruption for users is the following:

* PLplot-5.16.0.  Use the exact same build system logic except that 4
   and 5 are swapped.  That is Qt5 is looked for first, but if it is
   not found Qt4 is used as a backup with the exception that Qt4 is
   forced if the user specifies -DPLPLOT_USE_QT4=ON (which defaults to
   OFF).  Warn in the release notes of this change and the
   corresponding replacement of the PLPLOT_USE_QT5 option with
   PLPLOT_USE_QT4 and also mention we plan to deprecate Qt4
   support in the next release and remove it in the next release
   after that.

* PLplot-5.17.0.  Deprecate Qt4, i.e., use it as a fall back from
   Qt5 *only* if the users sets -DPLPLOT_QT4=ON.  Warn in the release notes of
   this change and also warn we plan to remove support for Qt4 in
   the next release.

* PLplot-5.18.0.  Completely remove support for Qt4 which will finally achieve the
   desired simplifications mentioned above.

As someone here with a large familiarity with Qt, I would appreciate
you letting me know if you forsee any trouble with this overall plan
to remove our Qt4 support.  And comments on this plan from the other
PLplot developers here are also encouraged.

I will likely implement the 5.16.0 part of the above plan late this
week if there are no strong disagreements expressed here in the
next several days.

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

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

Hi Alan,

I will have a look at this - I have built CMake before, that should not be a problem 😊. I have no experience, however, with the D compiler you mention.

Regards,

Arjen


-----Original Message-----
From: Alan W. Irwin <Ala...@gm...>
Sent: 01 September 2019 01:40
To: Takeshi Enomoto <ten...@us...>; Arjen Markus <Arj...@de...>; PLplot development list <Plp...@li...>
Subject: Re: [Plplot-devel] D language support topic

To Takeshi and Arjen:

I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this topic to the PLplot master branch at SourceForge.  This new D language support (see README.release for details) works perfectly on Linux (all comprehensive tests have passed perfectly on my Debian Buster platform), and I hope Takeshi (who contributed part of the changes that have gone into this push) would be willing to test this new D language support for PLplot on the MacPorts platform and Arjen on the
MSYS2 platform.

@Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts.
But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly.

@Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.html&amp;data=02%7C01%7C%7Ca962fd3984664e88519308d72e6c7d4b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637028915813958706&amp;sdata=Q5GbOISrDsA%2Fyxn16s2s4FeEor02in2aGUIFKRSkRLA%3D&amp;reserved=0).
I would appreciate you testing our new D language support on MSYS2 with that compiler.
As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself.

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
__________________________
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] D language support topic

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

On 2019-09-02 07:47-0000 Arjen Markus wrote:

> Hi Alan,
>
> I will have a look at this - I have built CMake before, that should not be a problem 😊. I have no experience, however, with the D compiler you mention.

Hi Arjen:

Thanks for your willingness to do the requested test_d tests on MSYS2
with dmd.  The results of those tests should help me to get our CMake
D language support working correctly for the Windows-dmd case for both
test_d and PLplot.

Alan

>
> -----Original Message-----
> From: Alan W. Irwin <Ala...@gm...>
> Sent: 01 September 2019 01:40
> To: Takeshi Enomoto <ten...@us...>; Arjen Markus <Arj...@de...>; PLplot development list <Plp...@li...>
> Subject: Re: [Plplot-devel] D language support topic
>
> To Takeshi and Arjen:
>
> I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this topic to the PLplot master branch at SourceForge.  This new D language support (see README.release for details) works perfectly on Linux (all comprehensive tests have passed perfectly on my Debian Buster platform), and I hope Takeshi (who contributed part of the changes that have gone into this push) would be willing to test this new D language support for PLplot on the MacPorts platform and Arjen on the
> MSYS2 platform.
>
> @Takeshi: as MacPorts maintainer of the plplot package for that distribution, this push cannot help you immediately with dmd because the push only works for that compiler if you have first built an extremely recent version of CMake, and it will take quite a while until that recent version of CMake propagates officially to MacPorts.
> But if you are still interested in testing for your future dmd MacPorts benefit (or want to test gdc instead which should work with the current official MacPorts version of CMake), then please follow the directions in cmake/test_d/README (which include building an extremely recent version of CMake to use for all testing) to generate a report tarball in the two ways requested so I can analyze those results and adjust the "Darwin" Platform files accordingly.
>
> @Arjen: the only D compiler you have access to on Windows is one you download for yourself [from Digital Mars](https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdlang.org%2Fdownload.html&amp;data=02%7C01%7C%7Ca962fd3984664e88519308d72e6c7d4b%7C15f3fe0ed7124981bc7cfe949af215bb%7C0%7C0%7C637028915813958706&amp;sdata=Q5GbOISrDsA%2Fyxn16s2s4FeEor02in2aGUIFKRSkRLA%3D&amp;reserved=0).
> I would appreciate you testing our new D language support on MSYS2 with that compiler.
> As in Takeshi's case I suggest you start with the test_d project for an extremely recent version of CMake from its git master branch that you have built yourself.
>
> 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
> __________________________
> 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.
>

__________________________
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

[Takeshi E. <ta...@ma...>]

Dear Alan,

Thank you for you message.

I confirmed that all the updated D examples are built successfully
including x16d
with current plplot-5.15.0 +dmd variant.

I will wait for the update (increment of the version number)
to test with the MacPorts build system.

Note that among D compilers, dmd has the better support in MacPorts.
gdc is outdated and doesn't work well with plplot.
gcc9 does not yet provide gdc.
Nobody is interested in maintaining ldc port yet.

Regards,

Takeshi

Re: [Plplot-devel] D language support topic

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

To Takeshi and Arjen:

I have now (git described as plplot-5.15.0-21-gf7d9bec36) pushed this
topic to the PLplot master branch at SourceForge.  This new D language
support (see README.release for details) works perfectly on Linux (all
comprehensive tests have passed perfectly on my Debian Buster
platform), and I hope Takeshi (who contributed part of the changes
that have gone into this push) would be willing to test this new D
language support for PLplot on the MacPorts platform and Arjen on the
MSYS2 platform.

@Takeshi: as MacPorts maintainer of the plplot package for that
distribution, this push cannot help you immediately with dmd because
the push only works for that compiler if you have first built an
extremely recent version of CMake, and it will take quite a while
until that recent version of CMake propagates officially to MacPorts.
But if you are still interested in testing for your future dmd
MacPorts benefit (or want to test gdc instead which should work with
the current official MacPorts version of CMake), then please follow
the directions in cmake/test_d/README (which include building an
extremely recent version of CMake to use for all testing) to generate a report tarball in
the two ways requested so I can analyze those results and adjust the
"Darwin" Platform files accordingly.

@Arjen: the only D compiler you have access to on Windows is
one you download for yourself [from Digital Mars](https://dlang.org/download.html).
I would appreciate you testing our new D language support on MSYS2 with that compiler.
As in Takeshi's case I suggest you start with the test_d project for
an extremely recent version of CMake from its git master branch
that you have built yourself.

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

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

This topic is being rapidly matured.  The current status for
the remaining work to be done is as follows:

* Implement a simple standalone "test_d" project (in cmake/test_d)
   which is designed to allow rapid testing of D language support (that
   has been updated from the cmake-d project) for all available D
   compilers on all platforms with a simplified (compared to the PLplot
   project) comprehensive test script.  This work is almost completed.
   For example, the simplified test script for test_d gives perfect
   results on my Debian Buster=Stable platform for gdc, ldc, and dmd.
   However, there is a bit more to do to finish the work on this
   test_d project.

* Replace our ancient fork of CMakeD with a modern fork of cmake-d.
   This work is almost completed.

* Fix any issues for our traditional (Makefile + pkg-config) build of
   the installed examples for both dmd and ldc without compromising the
   good gdc results we currently have for that particular build system.
   Once this is done the comprehensive test of the PLplot project
   itself (which includes tests of this traditional build system)
   should work properly for all three D compilers for the first time
   ever.

An important caveat for the above good CMake language support results
for ldc and dmd is those depend on a small fix to CMake general
language support which I have applied to my own locally built version
of CMake.  Brad King is currently shepherding this fix through the
[mostly automatic
process](https://gitlab.kitware.com/cmake/cmake/merge_requests/3747)
to make this fix part of a future CMake release.  The current estimate
is this fix should get into the CMake-3.16.0 release (likely due out
in November), but [see this
discussion](https://gitlab.kitware.com/cmake/cmake/issues/19631), this
CMake fix is also available right now as a [simple patch that should
apply to any recent version of CMake source
code](https://gitlab.kitware.com/cmake/cmake/uploads/92e4545dc691a0760a52656acaea9607/0001-linking-Support-language-specific-variants-of-CMAKE_.patch.gz).

In sum, in comparison to my last status report for this topic, I am
much closer to reaching the goal that comprehensive testing for both
test_d and PLplot itself is working correctly on Debian Buster for all
three D compilers.

More later....

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

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

On 2019-08-14 18:29-0700 Alan W. Irwin wrote:

> So replacing our ancient fork of CMakeD with a modern fork of cmake-d
> currently looks like the proper way forward.  However, before implementing
> that I need to do more comparisons between the two CMake D language
> support projects for dmd, and assuming I can get dmd to work correctly
> for our needs for cmake-d using modest changes to cmake-d, I also need
> to try out ldc (not available for our ancient fork of CMakeD) using
> cmake-d.

The current status is I am making good progress with bug fixes for the
cmake-d D language support so that it works for our needs.  So for
example, I have gotten dmd to work well enough for our CMake-based
core build of the D binding and examples on Debian Buster (for a dmd
compiler I built for myself since Debian does not package that
compiler) that I was able to build the D binding and compile (but not
yet link because of at least one remaining issue with cmake-d) all the
(updated) D examples with dmd.

The results of that dmd compilation of the examples confirmed all of
the example fixes (other than x16d.d) that Takeshi Enomoto donated via
our patch tracker, and I was also able to solve the remaining dmd
compilation errors (which occurred only for x16d.d).

My plan for maturing this topic before I push it to master
includes the following general steps:

* Fix the remaining cmake-d issues for the dmd compiler (as far as I
   know there is only one such issue left which is the current bad
   linking of the D examples).  And confirm this cmake-d change does
   not compromise the current good cmake-d results with the gdc
   compiler.

* Fix any cmake-d issues with the ldc compiler without compromising
   the good gdc results and the (now) good dmd results.

* Fix any issues for our traditional (Makefile + pkg-config) build of
   the installed examples for both dmd and ldc without compromising the
   good gdc results we currently have for that particular build system.

* Replace our ancient fork of CMakeD with a modern fork of cmake-d.
   In other words, all the above steps will be done with external (patched)
   cmake-d, and this step will integrate that patched version into
   PLplot source code for the convenience of our users.

The test of whether this topic has truly been matured will continue to
be our comprehensive test script (which tests our three build systems
for all our library and device variants) should produce perfect
results for D for each D compiler (gdc, dmd, and ldc).

More later....

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] D language support topic

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

Some essential background information for this post is "D" is an
interesting and distinct computer language that is a re-engineered
version of C++.  Presumably because of all the programmer interest in
"D", there are three well-known D compilers with free software
licenses.  They are

1. dmd (the fundamental D compiler from "Digital Mars" which
effectively sets the D syntax standards);

2. ldc (a D compiler with dmd front-end [the part of the compiler that
transforms D syntax to a language-independent intermediate
representation] and LLVM back-end); and

3. gdc (the GNU-implemented D compiler which has its own unique
    front-end and gcc backend).

My own Debian Buster platform gives me access to official ldc and gdc
packages, and I have built a working dmd on that platform from the
Digital Mars source code for that compiler.  So I think with some work
all developers here with access to Unix platforms and an interest in
"D" should be able to gain access to all three compilers.

The D compiler choice is more limited on Windows.  For example, there
are no official packages for ldc and gdc on Cygwin or MSYS2 so I
suspect both compilers would need a lot of work before they worked on
Windows.  However, dmd is apparently available for all Windows
platforms as a free download from Digital Mars so developers here who
are limited to just Windows platforms can still try out our D binding
and examples once I make dmd one of the compilers that are correctly
supported for the PLplot needs by our CMake D language support logic.

I started this development topic a few days ago in response to
<https://sourceforge.net/p/plplot/patches/35/> where the poster's
commentary indicated the installed D examples would not traditionally
compile with dmd, and his substantial patch to the source code for the
D examples fixed all such issues except for x16d (where his issue for
that example may have been due to the differences between the
gdc-built plplotdmd library that was presumably installed and the
dmd-built examples).  I have since been able to update our D examples
(on a private topic branch which I plan to push in due course) with
that patch and show that gdc D compiler was able to compile and run
those updated examples without run-time or diff-report issues in our
build tree.

So that (examples that now work locally for me with gdc and externally
for someone else with dmd) is a promising start to this topic, but to
finish it I want to generalize our CMake D language support logic and
overall logic so that the ldc and dmd D compilers work as well for me
as the gdc compiler currently does for our 3 different D builds (the
CMake-based build of our D binding and examples, the CMake-based build
of our installed D examples that are linked to our installed D
binding, and the traditional (Makefile + pkg-config) build of our
installed D examples that are linked to our installed D binding).

Our current CMake D language support (located in
cmake/modules/language_support/cmake) was forked by Werner Smekal from
the (now defunct) CMakeD project in 2009.  My comprehensive tests show
our fork does support gdc well on Linux (except for some known
limitations such as being forced to use a static version of the
plplotdmd library).  Our fork does have dmd support which might have
been tested by Werner in 2009, but I don't think anyone has tested it
since with dmd.  Our fork has no support for ldc.

Our changes to the 2009 version of CMakeD have been fairly small but
significant, but since then there have been other more substantial
changes and forks of that project culminating with the cmake-d project
at <https://github.com/dcarp/cmake-d> which continues to be actively
developed.  Note that project advertises that it supports all three of
dmd, ldc, and gdc.  That ldc support is just not available with our
fork of CMakeD, and I think it is quite likely (modulo a few modest
changes like the rpath one below) that cmake-d has better support for
dmd than our fork.

So I tried gdc with cmake-d language support (accessed externally),
and I ran into an rpath issue which should easily be fixed (since our
fork of CMakeD does handle rpath well) but which I temporarily worked
around with LD_LIBRARY_PATH.  They results of that experiment were
perfect (no run-time or diff report issues with the updated D
examples).

So replacing our ancient fork of CMakeD with a modern fork of cmake-d
currently looks like the proper way forward.  However, before implementing
that I need to do more comparisons between the two CMake D language
support projects for dmd, and assuming I can get dmd to work correctly
for our needs for cmake-d using modest changes to cmake-d, I also need
to try out lcd (not available for our ancient fork of CMakeD) using
cmake-d.

More later.

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] Plans for a last Python2 versus Python3 fix, Python2 deprecation by 5.16.0 and removal by 5.17.0

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

On 2019-08-06 13:18+0100 Phil Rosenberg wrote:

> Sorry, my last email wasn't sent to the list - see below.
>
> I think I have found the solution, by changing the shebang to python2
> rather than python.
>
> I'm going to commit this change as it is a change that only affects us
> developers. Alan - if you could test to check it works on your linux
> system, that would be great.

Hi Phil:

Sorry for my own delay in answering you which was caused by gmail
troubles (started by a bad recovery) that has finally been
straightened out yesterday (Thursday) after 5 days of no gmail access
for me.

Glad you found a solution for the scripts/convert_comment.py issue.
That's a good solution in the short term but unfortunately not in the
long term.  The problem is Python2 is near its end of life (see, for
example, the discussion in <https://lwn.net/Articles/756628/>).  And
in any case very likely due to anticipation by Python developers of
that end of life, my experience is Python2 is buggy and not as well
supported as Python3.  So in any case I planned to deprecate the
PLplot Python2 support soon and remove it completely fairly soon
after.  So I will need to generalize your above solution for the
Python3 case.

[The essential documentation for this general
solution](https://portingguide.readthedocs.io/en/latest/exceptions.html)
shows there are both "except" and "raise" differences in Python2
versus Python3 syntax for handling exceptions.  Furthermore, there are
a number of different places in our Python code where we use "except"
and "raise", and apparently they are all currently implemented in
Python2 syntax (as you discovered for the case of the raise command in
scripts/convert_comment.py).

My plan for dealing with this issue is to change all "except" and
"raise" Python commands to Python3 syntax only (this will include
scripts/convert_comment.py and therefore changing your shebang from
python2 to python3 and testing that change works here under python3)
and deprecation of Python2 (meaning users will have to go out of their
way to specify -DPL_DEPRECATED_PYTHON=ON in order to still access
Python2).  This planned deprecation in the current release cycle
should propagate to the forthcoming 5.16.0 release, and the further
plan is to remove Python2 completely early in the next release cycle
that will lead to 5.17.0.

If you or anyone else here has concerns about any aspect of the above
general plans (but especially the timing of the Python2 deprecation
and/or removal), please let me know soon.

Alan


>
> On Tue, 6 Aug 2019 at 12:50, Phil Rosenberg <p.d...@gm...> wrote:
>>
>> Hi Alan
>> The error message I gave is the complete error message, there is no
>> output of the line variable. This, combined with the fact that the
>> carat is pointing to the end of the line of python code, made me think
>> this was a syntax error in the python code itself.
>>
>> When I opened convert_comment.py in visual studio, the error
>> highlighting underlined all instances of raise RuntimeError. Hovering
>> the mouse over displayed the following error
>>
>> invalid syntax, only exception value is allowed in 3.x
>>
>> Googling this error lead me to
>> https://stackoverflow.com/questions/34463087/valid-syntax-in-both-python-2-x-and-3-x-for-raising-exception
>>
>> So I think, basically the syntax for raise has changed between 2.x and
>> 3.x and for whatever reason, on my system the script is being executed
>> using 3.x
>>
>> Any fix suggestions? I don't really know python at all.
>>
>> Phil
>>
>> On Wed, 31 Jul 2019 at 19:49, Alan W. Irwin <Ala...@gm...> wrote:
>>>
>>> On 2019-07-31 12:44+0100 Phil Rosenberg wrote:
>>>
>>>> Thanks Alan
>>>> I've just tried again with the style_source script, but I'm hitting
>>>> another problem. I now get the error:
>>>>
>>>> File "scripts/convert_comment.py", line 72
>>>>    raise RuntimeError, "Cannot interpret trailing character(s) after
>>>> */ for this line"
>>>>                      ^
>>>> SyntaxError: invalid syntax
>>>> ERROR: scripts/convert_comment.py failed for file plplot_config.h.in
>>>>
>>>>
>>>> Any suggestions? I have both python 2 and 3 installed.
>>>
>>> That error message comes from this logic in scripts/convert_comment.py
>>> which hasn't been changed (from git blame -w) since 2010.
>>>
>>>      # Note trailing "\n" has not (yet) been removed from line so
>>>      # that the next to last character is at position len(line) - 3.
>>>      if end_comment >=0 and end_comment !=  len(line) - 3:
>>>          if ifsingleline and start_comment >=0:
>>>              # Skip most further processing for a line with embedded
>>>              # comments outside of multiline blocks of comments.
>>>              start_comment = -1
>>>              end_comment = -1
>>>          else:
>>>              sys.stderr.write(line)
>>>              raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line"
>>>
>>> So that error message should have included the results from sys.stderr.write(line)
>>> from the line in plplot_config.h.in that is stored in the Python "line" variable
>>> that appears to be causing this python logic problem.
>>>
>>> The usual interpretation of this error message is you have commentary
>>> in plplot_config.h.in which is not in legitimate form.  For example,
>>> you might have forgotten the trailing "*/" on a comment.  So I would
>>> test that possibility by attempting to build the plplot target before
>>> styling, which would necessarily attempt to compile the configured
>>> plplot_config.h.
>>>
>>> However, if that "easy" answer is not the correct one, please send the
>>> complete error message including the output of the Python "line" variable
>>> that is causing the issue.
>>>
>>> Of course, the above Python logic only works if there are no
>>> line-ending issues in Python, i.e., the Python "line" variable
>>> contains a string that is terminated simply by \n rather than
>>> \r\n. And note that by git default plplot_config.h.in will have \r\n
>>> line endings on MSYS2.  But the discussion in
>>> <https://stackoverflow.com/questions/10785131/line-endings-in-python>
>>> seems to imply that on Python automatically converts all \r and \r\n
>>> line endings for text files to \n.  Also, my impression is you have
>>> exercised the above scripts/convert_comment.py logic from 2010 with no
>>> issues in the past on Cygwin (where again, the checked out
>>> plplot_config.h.in should have \r\n line endings.) So I would only
>>> look at this potential line ending issue (by dumping out each raw byte
>>> of the above line) only as a last resort (i.e., only if the line that
>>> is causing this error compiles with no issues).
>>>
>>> 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
>>> __________________________
>

__________________________
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] uncrustify msys2

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

Sorry, my last email wasn't sent to the list - see below.

I think I have found the solution, by changing the shebang to python2
rather than python.

I'm going to commit this change as it is a change that only affects us
developers. Alan - if you could test to check it works on your linux
system, that would be great.

On Tue, 6 Aug 2019 at 12:50, Phil Rosenberg <p.d...@gm...> wrote:
>
> Hi Alan
> The error message I gave is the complete error message, there is no
> output of the line variable. This, combined with the fact that the
> carat is pointing to the end of the line of python code, made me think
> this was a syntax error in the python code itself.
>
> When I opened convert_comment.py in visual studio, the error
> highlighting underlined all instances of raise RuntimeError. Hovering
> the mouse over displayed the following error
>
> invalid syntax, only exception value is allowed in 3.x
>
> Googling this error lead me to
> https://stackoverflow.com/questions/34463087/valid-syntax-in-both-python-2-x-and-3-x-for-raising-exception
>
> So I think, basically the syntax for raise has changed between 2.x and
> 3.x and for whatever reason, on my system the script is being executed
> using 3.x
>
> Any fix suggestions? I don't really know python at all.
>
> Phil
>
> On Wed, 31 Jul 2019 at 19:49, Alan W. Irwin <Ala...@gm...> wrote:
> >
> > On 2019-07-31 12:44+0100 Phil Rosenberg wrote:
> >
> > > Thanks Alan
> > > I've just tried again with the style_source script, but I'm hitting
> > > another problem. I now get the error:
> > >
> > > File "scripts/convert_comment.py", line 72
> > >    raise RuntimeError, "Cannot interpret trailing character(s) after
> > > */ for this line"
> > >                      ^
> > > SyntaxError: invalid syntax
> > > ERROR: scripts/convert_comment.py failed for file plplot_config.h.in
> > >
> > >
> > > Any suggestions? I have both python 2 and 3 installed.
> >
> > That error message comes from this logic in scripts/convert_comment.py
> > which hasn't been changed (from git blame -w) since 2010.
> >
> >      # Note trailing "\n" has not (yet) been removed from line so
> >      # that the next to last character is at position len(line) - 3.
> >      if end_comment >=0 and end_comment !=  len(line) - 3:
> >          if ifsingleline and start_comment >=0:
> >              # Skip most further processing for a line with embedded
> >              # comments outside of multiline blocks of comments.
> >              start_comment = -1
> >              end_comment = -1
> >          else:
> >              sys.stderr.write(line)
> >              raise RuntimeError, "Cannot interpret trailing character(s) after */ for this line"
> >
> > So that error message should have included the results from sys.stderr.write(line)
> > from the line in plplot_config.h.in that is stored in the Python "line" variable
> > that appears to be causing this python logic problem.
> >
> > The usual interpretation of this error message is you have commentary
> > in plplot_config.h.in which is not in legitimate form.  For example,
> > you might have forgotten the trailing "*/" on a comment.  So I would
> > test that possibility by attempting to build the plplot target before
> > styling, which would necessarily attempt to compile the configured
> > plplot_config.h.
> >
> > However, if that "easy" answer is not the correct one, please send the
> > complete error message including the output of the Python "line" variable
> > that is causing the issue.
> >
> > Of course, the above Python logic only works if there are no
> > line-ending issues in Python, i.e., the Python "line" variable
> > contains a string that is terminated simply by \n rather than
> > \r\n. And note that by git default plplot_config.h.in will have \r\n
> > line endings on MSYS2.  But the discussion in
> > <https://stackoverflow.com/questions/10785131/line-endings-in-python>
> > seems to imply that on Python automatically converts all \r and \r\n
> > line endings for text files to \n.  Also, my impression is you have
> > exercised the above scripts/convert_comment.py logic from 2010 with no
> > issues in the past on Cygwin (where again, the checked out
> > plplot_config.h.in should have \r\n line endings.) So I would only
> > look at this potential line ending issue (by dumping out each raw byte
> > of the above line) only as a last resort (i.e., only if the line that
> > is causing this error compiles with no issues).
> >
> > 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] What more steps do you need to do to finish up your part of the PLplot error handling topic?

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

Hi Phil:

There are a number of unresolved topics between us including getting
styling and comprehensive testing to work on MSYS2 and to fix up the
remaining "interactive" errors for the wxwidgets device (e.g., making
examples 17 and 20 display "interactively" like they currently do for
xwin).  But this post is about yet another unresolved topic between us
concerning the steps necessary to finish up all but the tedious final
editing work (which I can take responsibility for)
on your PLplot exception handling topic.

If I remember the status of that topic correctly, you got your
setjmp/longjmp C exception handling to work well in a proof-of-concept
way with at least one public API function providing the TRY and CATCH
blocks with plexit changed to throw exceptions with THROW.

Assuming that summary is correct as far as it goes, can you comment on
whether you handled the problem of one public API function calling one
or more other public API functions? (plbox calling plaxes is a trivial
example of this, but there are many more such examples.)  In other
words, can you propagate the exception introduced by plexit back
through one or more public API calls until you reach the first public
API call in the chain that has been called by an
external library or app?

Assuming the solution to that propagation problem is straightforward
(or has been implemented already) are all the remaining steps simply
editing ones, e.g., putting the appropriate TRY and CATCH blocks of
code at the start of each public API function and replacing all calls
to exit by calls to plexit?  If so, I would be willing to do those
necessary editing steps and conclude this project by merging all our
combined work (in a private topic branch shared between us) to the
master branch.  But I don't know how much effort it will take you to
get to the stage with this topic where I can take over by finishing it
that way.  I also don't know whether you think your work on this topic
is higher or lower priority than your work on the other unresolved
PLplot topics I have mentioned above.  So please let me know what your
PLplot priorities are so I have some idea what to expect from you by
the time 5.16.0 is released (which should ideally occur before
December 1st, i.e., we are already roughly one third of the way
through the current release cycle).

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
__________________________