plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] CMake

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

On 2015-12-10 10:54-0000 Phil Rosenberg wrote:

> Hi Alan
> This is just a note about cmake version bumping. You have been
> increasing the required CMake version lately, which I generally have
> no problem with, however CMake 3.4.1 seems to have a major issue on
> Windows, in that it cannot seem to find the latest visual studio
> compiler (which happens to be the version I am using). I reported a
> bug and it has been marked as a duplicate of another bug reported
> early November (https://cmake.org/Bug/view.php?id=15831). Therefore
> can I ask that until this bug is fixed we do not bump up any further.

Agreed.

In fact, for the whole of the 3.x.y series of releases, I have noticed
that the 3.x.0 and 3.x.1 versions typically have problems so
individual users have to be cautious about using those, and I
typically wait for the y value (the so-called patch number) to get to
version 2 (e.g., to 3.3.2, the last release in the 3.3.x series)
before bumping to that minimum version.  Note, it is still early
days for the 3.4.y series; only 3.4.0 and 3.4.1 have been released so far.

So the present status is that outside of Linux and Cygwin where we are
sticking with 3.0.2 as our minimum version (probably for the next
year), the minimum version is currently 3.3.2, and I will stick with
that minimum until you give the OK that bugs 15831 and 15875 have been
resolved to your satisfaction for a finalized release (i.e., not a release
candidate).

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 Source Error

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

Alan
I have pushed my work so far as it fixes the bug. The only side effect
is that it stops the shapefile example building in x19. At least this
way you can see my work and where I might be going wrong with the
cmake stuff

Phil

On 10 December 2015 at 12:36, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan
> Sorry this has taken me a while to look at.
>
> I just want to check what you think the behaviour should be id
> shapelib is off, deprecated is on and the user passes in a map name
> other than one of the ones we supply? The behaviour before we began
> using shapefiles was the same as it is now: If a file with that name
> existed then plplot attempted to read it, if not then plplot reported
> the warning you saw. I think that is still correct behaviour.
> What should probably happen is that the final page of the example
> should not be drawn unless shapelib support is on. To do this we need
> either a compile time or runtime check for whether plplot was built
> with shapelib support. Not wanting to touch the public API I guess a
> #define PL_USE_SHAPEFILES in plConfig.h is required. However I'm not
> sure how to do that. I tried adding
>
> set(PL_USE_SHAPEFILES, TRUE)
>
> In shapelib.cmake and
>
> #cmakedefine PL_USE_SHAPEFILES
>
> in plConfig.h.in, but this doesn't work. You might have to look at
> this to get it to work or give me some idea what I am doing wrong. I
> suspect that shapelib.cmake is not called until after plConfig.h is
> generated. If so then sorting that would be a significant change to
> the build system that is beyond my skill.
>
>
> Phil
>
> On 1 December 2015 at 09:46, Phil Rosenberg <p.d...@gm...> wrote:
>> Hi Alan I'll look at this today
>> ________________________________
>> From: Alan W. Irwin
>> Sent: ‎30/‎11/‎2015 21:30
>> To: Phil Rosenberg; Peter Williams
>> Cc: PLplot development list
>> Subject: Re: [Plplot-devel] Plplot Source Error
>>
>> On 2015-11-30 19:39-0000 Peter Williams wrote:
>>
>>> I have done a plplot build using cmake  with the 'deprecated' flag set
>>> on. The mingw make comes with an error message:
>>>
>>> C:\PlplotSource-5.11.1\src\plmap.c: In function 'drawmap':
>>>
>>> C:\PlplotSource-5.11.1\src\plmap.c:530:25: error: 'appendresult'
>>> undeclared (first use in this function)
>>> appendresult += appendfltptr( &splitx, nsplitsections, bufx + i );
>>> ^
>>> I do not get this error with the deprecated flag set off. It seems a
>>> simple error to correct (merely initialise appendresult =0)
>>> but I am loath to tamper with complex code which is not mine.
>>
>> To Phil and Peter:
>>
>> I confirm this issue on Linux if I use the combination of cmake options
>> -DPL_DEPRECATED=ON -DHAVE_SHAPELIB=OFF.
>>
>> As expected, this build issue does go away if the appendresult declaration
>> and
>> initialization is moved to where it will be compiled in general.
>> However, that is not all the story, because if you also compile
>> example 19 for that case and any device driver (I chose cairo), then
>> there is a long series of warnings issued for that example when
>> you run it, e.g., with
>>
>> examples/c/x19c -dev xcairo
>>
>> Those warning messages start with
>>
>> *** PLPLOT WARNING ***
>> Could not find ss/ss64ne_Landform_Area.map file.
>>
>> That makes no sense.  If -DHAVE_SHAPELIB=OFF why in the world
>> should this example (or more likely the core library) be looking for
>> shapelib files?  I also tested the case where -DPL_DEPRECATED=OFF
>> -DHAVE_SHAPELIB=OFF, and the code does the right thing there
>> which is emit the following warning
>>
>> *** PLPLOT WARNING ***
>> Use of the old plplot map file format is deprecated.
>> It is recommended that the shapelib library be used to provide map
>> support.
>>
>> @Phil: As original author of this code, would you please fix the
>> -DPL_DEPRECATED=ON -DHAVE_SHAPELIB=OFF case so that the first pages of
>> example 19 come out right (like they do now) using the deprecated way
>> of doing things, but the last page should simply emit the same message
>> as for the -DPL_DEPRECATED=OFF -DHAVE_SHAPELIB=OFF case, i.e., the
>> last WARNING message above?
>>
>> 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 Source Error

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

Hi Alan
Sorry this has taken me a while to look at.

I just want to check what you think the behaviour should be id
shapelib is off, deprecated is on and the user passes in a map name
other than one of the ones we supply? The behaviour before we began
using shapefiles was the same as it is now: If a file with that name
existed then plplot attempted to read it, if not then plplot reported
the warning you saw. I think that is still correct behaviour.
What should probably happen is that the final page of the example
should not be drawn unless shapelib support is on. To do this we need
either a compile time or runtime check for whether plplot was built
with shapelib support. Not wanting to touch the public API I guess a
#define PL_USE_SHAPEFILES in plConfig.h is required. However I'm not
sure how to do that. I tried adding

set(PL_USE_SHAPEFILES, TRUE)

In shapelib.cmake and

#cmakedefine PL_USE_SHAPEFILES

in plConfig.h.in, but this doesn't work. You might have to look at
this to get it to work or give me some idea what I am doing wrong. I
suspect that shapelib.cmake is not called until after plConfig.h is
generated. If so then sorting that would be a significant change to
the build system that is beyond my skill.


Phil

On 1 December 2015 at 09:46, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan I'll look at this today
> ________________________________
> From: Alan W. Irwin
> Sent: ‎30/‎11/‎2015 21:30
> To: Phil Rosenberg; Peter Williams
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Plplot Source Error
>
> On 2015-11-30 19:39-0000 Peter Williams wrote:
>
>> I have done a plplot build using cmake  with the 'deprecated' flag set
>> on. The mingw make comes with an error message:
>>
>> C:\PlplotSource-5.11.1\src\plmap.c: In function 'drawmap':
>>
>> C:\PlplotSource-5.11.1\src\plmap.c:530:25: error: 'appendresult'
>> undeclared (first use in this function)
>> appendresult += appendfltptr( &splitx, nsplitsections, bufx + i );
>> ^
>> I do not get this error with the deprecated flag set off. It seems a
>> simple error to correct (merely initialise appendresult =0)
>> but I am loath to tamper with complex code which is not mine.
>
> To Phil and Peter:
>
> I confirm this issue on Linux if I use the combination of cmake options
> -DPL_DEPRECATED=ON -DHAVE_SHAPELIB=OFF.
>
> As expected, this build issue does go away if the appendresult declaration
> and
> initialization is moved to where it will be compiled in general.
> However, that is not all the story, because if you also compile
> example 19 for that case and any device driver (I chose cairo), then
> there is a long series of warnings issued for that example when
> you run it, e.g., with
>
> examples/c/x19c -dev xcairo
>
> Those warning messages start with
>
> *** PLPLOT WARNING ***
> Could not find ss/ss64ne_Landform_Area.map file.
>
> That makes no sense.  If -DHAVE_SHAPELIB=OFF why in the world
> should this example (or more likely the core library) be looking for
> shapelib files?  I also tested the case where -DPL_DEPRECATED=OFF
> -DHAVE_SHAPELIB=OFF, and the code does the right thing there
> which is emit the following warning
>
> *** PLPLOT WARNING ***
> Use of the old plplot map file format is deprecated.
> It is recommended that the shapelib library be used to provide map
> support.
>
> @Phil: As original author of this code, would you please fix the
> -DPL_DEPRECATED=ON -DHAVE_SHAPELIB=OFF case so that the first pages of
> example 19 come out right (like they do now) using the deprecated way
> of doing things, but the last page should simply emit the same message
> as for the -DPL_DEPRECATED=OFF -DHAVE_SHAPELIB=OFF case, i.e., the
> last WARNING message above?
>
> 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] CMake

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

Hi Alan
This is just a note about cmake version bumping. You have been
increasing the required CMake version lately, which I generally have
no problem with, however CMake 3.4.1 seems to have a major issue on
Windows, in that it cannot seem to find the latest visual studio
compiler (which happens to be the version I am using). I reported a
bug and it has been marked as a duplicate of another bug reported
early November (https://cmake.org/Bug/view.php?id=15831). Therefore
can I ask that until this bug is fixed we do not bump up any further.

Phil

Re: [Plplot-devel] Plplot Source Error

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

Hi Alan I'll look at this today

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎30/‎11/‎2015 21:30
To: "Phil Rosenberg" <p.d...@gm...>; "Peter Williams" <pet...@nt...>
Cc: "PLplot development list" <plp...@li...>
Subject: Re: [Plplot-devel] Plplot Source Error

On 2015-11-30 19:39-0000 Peter Williams wrote:

> I have done a plplot build using cmake  with the 'deprecated' flag set
> on. The mingw make comes with an error message:
>
> C:\PlplotSource-5.11.1\src\plmap.c: In function 'drawmap':
>
> C:\PlplotSource-5.11.1\src\plmap.c:530:25: error: 'appendresult'
> undeclared (first use in this function)
> appendresult += appendfltptr( &splitx, nsplitsections, bufx + i );
> ^
> I do not get this error with the deprecated flag set off. It seems a
> simple error to correct (merely initialise appendresult =0)
> but I am loath to tamper with complex code which is not mine.

To Phil and Peter:

I confirm this issue on Linux if I use the combination of cmake options
-DPL_DEPRECATED=ON -DHAVE_SHAPELIB=OFF.

As expected, this build issue does go away if the appendresult declaration and
initialization is moved to where it will be compiled in general.
However, that is not all the story, because if you also compile
example 19 for that case and any device driver (I chose cairo), then
there is a long series of warnings issued for that example when
you run it, e.g., with

examples/c/x19c -dev xcairo

Those warning messages start with

*** PLPLOT WARNING ***
Could not find ss/ss64ne_Landform_Area.map file.

That makes no sense.  If -DHAVE_SHAPELIB=OFF why in the world
should this example (or more likely the core library) be looking for
shapelib files?  I also tested the case where -DPL_DEPRECATED=OFF
-DHAVE_SHAPELIB=OFF, and the code does the right thing there
which is emit the following warning

*** PLPLOT WARNING ***
Use of the old plplot map file format is deprecated.
It is recommended that the shapelib library be used to provide map
support.

@Phil: As original author of this code, would you please fix the
-DPL_DEPRECATED=ON -DHAVE_SHAPELIB=OFF case so that the first pages of
example 19 come out right (like they do now) using the deprecated way
of doing things, but the last page should simply emit the same message
as for the -DPL_DEPRECATED=OFF -DHAVE_SHAPELIB=OFF case, i.e., the
last WARNING message above?

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 Source Error

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

On 2015-11-30 19:39-0000 Peter Williams wrote:

> I have done a plplot build using cmake  with the 'deprecated' flag set
> on. The mingw make comes with an error message:
>
> C:\PlplotSource-5.11.1\src\plmap.c: In function 'drawmap':
>
> C:\PlplotSource-5.11.1\src\plmap.c:530:25: error: 'appendresult'
> undeclared (first use in this function)
> appendresult += appendfltptr( &splitx, nsplitsections, bufx + i );
> ^
> I do not get this error with the deprecated flag set off. It seems a
> simple error to correct (merely initialise appendresult =0)
> but I am loath to tamper with complex code which is not mine.

To Phil and Peter:

I confirm this issue on Linux if I use the combination of cmake options
-DPL_DEPRECATED=ON -DHAVE_SHAPELIB=OFF.

As expected, this build issue does go away if the appendresult declaration and
initialization is moved to where it will be compiled in general.
However, that is not all the story, because if you also compile
example 19 for that case and any device driver (I chose cairo), then
there is a long series of warnings issued for that example when
you run it, e.g., with

examples/c/x19c -dev xcairo

Those warning messages start with

*** PLPLOT WARNING ***
Could not find ss/ss64ne_Landform_Area.map file.

That makes no sense.  If -DHAVE_SHAPELIB=OFF why in the world
should this example (or more likely the core library) be looking for
shapelib files?  I also tested the case where -DPL_DEPRECATED=OFF
-DHAVE_SHAPELIB=OFF, and the code does the right thing there
which is emit the following warning

*** PLPLOT WARNING ***
Use of the old plplot map file format is deprecated.
It is recommended that the shapelib library be used to provide map
support.

@Phil: As original author of this code, would you please fix the
-DPL_DEPRECATED=ON -DHAVE_SHAPELIB=OFF case so that the first pages of
example 19 come out right (like they do now) using the deprecated way
of doing things, but the last page should simply emit the same message
as for the -DPL_DEPRECATED=OFF -DHAVE_SHAPELIB=OFF case, i.e., the
last WARNING message above?

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] Plplot Source Error

[Peter W. <pet...@nt...>]

I have done a plplot build using cmake  with the 'deprecated' flag set 
on. The mingw make comes with an error message:

C:\PlplotSource-5.11.1\src\plmap.c: In function 'drawmap':

C:\PlplotSource-5.11.1\src\plmap.c:530:25: error: 'appendresult' 
undeclared (first use in this function)
appendresult += appendfltptr( &splitx, nsplitsections, bufx + i );
^
I do not get this error with the deprecated flag set off. It seems a 
simple error to correct (merely initialise appendresult =0)
but I am loath to tamper with complex code which is not mine.
Best Wishes

-- 
         Peter Williams
   pet...@nt...

Re: [Plplot-devel] Font problems

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

On 2015-11-27 16:57-0000 Peter Williams wrote:

> Hi Alan & Arjen
>
> Thanks for your attention. Hope I am posting this correctly. One of the first 
> things I did when I built Plplot5.11.1 was to run the c code examples. 
> Example x07c.c runs fine and displays the character #(855) – an  arrow  head 
> in a Postscript file. All very jolly! So, the fonts must be built into the 
> library. My program shows nothing. But maybe the comparison is false because 
> I plot using plptex while x07c.c uses a different method, which I confess I 
> am not clear about.  It does print some characters correctly e.g. #(766) - 
> the infinity symbol.
>
> I have been using Plplot for a long time starting with an ARM  Acorn 
> Archimedes.  I built Plplot5.00 back in the 90's using a collection of .bat 
> files.  I still have it and it plots #(855) fine. I thought it was time to 
> upgrade... I build using CMAKE 3.4.0-rc2 in its GUI form. It didn't seem to 
> want to left me build a pdf device. Maybe I am not using it correctly.
>
> A simplified version of my program is:
>
> /*
>  FontTest
> */
> #include <math.h>
> #include <plplot.h>
>
> int main()
> {
>    int i;
>    PLFLT x,y,dx,dy,theta,dTheta,xMin,xMax,yMin,yMax;
>
>    xMin = -4.0; xMax = 1.0; yMin = -2.0; yMax = 2.0;
>
> /* Set up viewport and window, but do not draw box */
>
>   " plinit();
>    plenv( xMin, xMax, yMin, yMax, 0, 0 );
>    plfontld(1);plfont(1);
>
>    x = -2.0; y = 2.0*exp(-x*x/4.0); dy = -x*exp(-x*x/4.0); /* Find arrow 
> slope */
>    plptex(x, y,1.0,dy,0.5,"#(855)"); /* C2 Arrow */
>    plptex(x,-y,dx,dy,0.5,"#(855)");  /* C1 Arrow */
>    plptex(x,0,-1.0,0.0,0.5,"#(855)"); /* Gamma Arrow */
>
>    plend();
>    return 1;
> }
>
> Best Wishes, Peter
>

Hi Peter:

Thanks very much for this more detailed report.  Including a simple
test like you did above is always a good motivator for us.  :-)

As far as I can tell there is nothing wrong with your above test
programme (aside from uninitialized dx which I fixed by setting that
variable to 0.).  With that fix in place, I have confirmed the issue
(arrow not rendered) on Linux (Debian Jessie) with the psc device.
After the dx fix, valgrind shows an absolutely clean result so the bad
rendering issue is unlikely to be caused by memory management
problems.

To investigate further I modified examples/c/x10c.c (which is our
simplest example that uses plptex) as follows:

--- a/examples/c/x10c.c
+++ b/examples/c/x10c.c
@@ -28,7 +28,7 @@ main( int argc, const char *argv[] )
      plsvpa( 50.0, 150.0, 50.0, 100.0 );
      plwind( 0.0, 1.0, 0.0, 1.0 );
      plbox( "bc", 0.0, 0, "bc", 0.0, 0 );
-    plptex( 0.5, 0.5, 1.0, 0.0, 0.5, "BOX at (50,150,50,100)" );
+    plptex( 0.5, 0.5, 1.0, 0.0, 0.5, "Hershey code #(855)" );
      plend();
      exit( 0 );
  }

The advantage of working with slightly modified standard examples like
this is our build system makes them extremely convenient to build and
run.

With the above change to standard example 10, I again confirmed the
issue (arrow not rendered) for -dev psc and -dev ps, but the following
devices did properly render the arrow: xwin, tk, xcairo, wxwidgets, qtwidget,
and even psttfc (which has similarities to -dev psc).  For the -dev
svg case (which is another device without external library
prerequisites which is convenient for you to also try on Windows) the
arrow was rendered as a question mark.

The conclusion is there is a specific bug for the ps device
driver for PostScript fonts, and also a specific bug for the svg device
(which is probably not related).  I will look into both of those.

Meanwhile for the psc (or ps) device there is a driver option which
allows you to replace the PostScript fonts with Hershey fonts. If you
have command-line parsing in place (which your above example does not,
but look at any of the example/c/x??c.c files to see how to implement
that with a change to the main arguments and inserting a call to
plparseopts), then use the -drvopt text=0 command-line option to try
the Hershey font possibility.  That works fine here (arrow rendered)
although the results are generally not as pretty as those rendered
with PostScript fonts.

Thanks again for reporting this bug.

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] Font problems

[Greg J. <gv...@gm...>]

> It didn't seem to want to left me build a pdf device.

To get pdf device you will need the libharu library
https://github.com/libharu/libharu/archive/RELEASE_2_3_0.zip
which should build without issue.

On Fri, Nov 27, 2015 at 8:57 AM, Peter Williams
<pet...@nt...> wrote:
> Hi Alan & Arjen
>
> Thanks for your attention. Hope I am posting this correctly. One of the
> first things I did when I built Plplot5.11.1 was to run the c code
> examples. Example x07c.c runs fine and displays the character #(855) –
> an  arrow  head in a Postscript file. All very jolly! So, the fonts must
> be built into the library. My program shows nothing. But maybe the
> comparison is false because I plot using plptex while x07c.c uses a
> different method, which I confess I am not clear about.  It does print
> some characters correctly e.g. #(766) - the infinity symbol.
>
> I have been using Plplot for a long time starting with an ARM  Acorn
> Archimedes.  I built Plplot5.00 back in the 90's using a collection of
> .bat files.  I still have it and it plots #(855) fine. I thought it was
> time to upgrade... I build using CMAKE 3.4.0-rc2 in its GUI form. It
> didn't seem to want to left me build a pdf device. Maybe I am not using
> it correctly.
>
> A simplified version of my program is:
>
> /*
>    FontTest
> */
> #include <math.h>
> #include <plplot.h>
>
> int main()
> {
>      int i;
>      PLFLT x,y,dx,dy,theta,dTheta,xMin,xMax,yMin,yMax;
>
>      xMin = -4.0; xMax = 1.0; yMin = -2.0; yMax = 2.0;
>
> /* Set up viewport and window, but do not draw box */
>
>      plinit();
>      plenv( xMin, xMax, yMin, yMax, 0, 0 );
>      plfontld(1);plfont(1);
>
>      x = -2.0; y = 2.0*exp(-x*x/4.0); dy = -x*exp(-x*x/4.0); /* Find
> arrow slope */
>      plptex(x, y,1.0,dy,0.5,"#(855)"); /* C2 Arrow */
>      plptex(x,-y,dx,dy,0.5,"#(855)");  /* C1 Arrow */
>      plptex(x,0,-1.0,0.0,0.5,"#(855)"); /* Gamma Arrow */
>
>      plend();
>      return 1;
> }
>
> Best Wishes, Peter
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Font problems

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

The PS driver has support for unicode, though it relies on the fonts installed in the postscript device that is rendering the file.  There is no reliable method for plplot to know which fonts are available to the postscript device.  When the PLplot ps driver was converted to unicode, I think the default use of Hershey fonts for symbols was ended.

The behavior of postscript files can be unexpected under Windows.  Depending on whether you are viewing (third-party viewer or Windows provided) or printing the files, there could be differences in the output due to available fonts.

There is an option that will enable Hershey symbols in the PS driver, so you can set that if you do not have the fonts available.

> On Nov 27, 2015, at 11:57 AM, Peter Williams <pet...@nt...> wrote:
> 
> Hi Alan & Arjen
> 
> Thanks for your attention. Hope I am posting this correctly. One of the 
> first things I did when I built Plplot5.11.1 was to run the c code 
> examples. Example x07c.c runs fine and displays the character #(855) – 
> an  arrow  head in a Postscript file. All very jolly! So, the fonts must 
> be built into the library. My program shows nothing. But maybe the 
> comparison is false because I plot using plptex while x07c.c uses a 
> different method, which I confess I am not clear about.  It does print 
> some characters correctly e.g. #(766) - the infinity symbol.
> 
> I have been using Plplot for a long time starting with an ARM  Acorn 
> Archimedes.  I built Plplot5.00 back in the 90's using a collection of 
> .bat files.  I still have it and it plots #(855) fine. I thought it was 
> time to upgrade... I build using CMAKE 3.4.0-rc2 in its GUI form. It 
> didn't seem to want to left me build a pdf device. Maybe I am not using 
> it correctly.
> 
> A simplified version of my program is:
> 
> /*
>   FontTest
> */
> #include <math.h>
> #include <plplot.h>
> 
> int main()
> {
>     int i;
>     PLFLT x,y,dx,dy,theta,dTheta,xMin,xMax,yMin,yMax;
> 
>     xMin = -4.0; xMax = 1.0; yMin = -2.0; yMax = 2.0;
> 
> /* Set up viewport and window, but do not draw box */
> 
>     plinit();
>     plenv( xMin, xMax, yMin, yMax, 0, 0 );
>     plfontld(1);plfont(1);
> 
>     x = -2.0; y = 2.0*exp(-x*x/4.0); dy = -x*exp(-x*x/4.0); /* Find 
> arrow slope */
>     plptex(x, y,1.0,dy,0.5,"#(855)"); /* C2 Arrow */
>     plptex(x,-y,dx,dy,0.5,"#(855)");  /* C1 Arrow */
>     plptex(x,0,-1.0,0.0,0.5,"#(855)"); /* Gamma Arrow */
> 
>     plend();
>     return 1;
> }
> 
> Best Wishes, Peter
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Font problems

[Peter W. <pet...@nt...>]

Hi Alan & Arjen

Thanks for your attention. Hope I am posting this correctly. One of the 
first things I did when I built Plplot5.11.1 was to run the c code 
examples. Example x07c.c runs fine and displays the character #(855) – 
an  arrow  head in a Postscript file. All very jolly! So, the fonts must 
be built into the library. My program shows nothing. But maybe the 
comparison is false because I plot using plptex while x07c.c uses a 
different method, which I confess I am not clear about.  It does print 
some characters correctly e.g. #(766) - the infinity symbol.

I have been using Plplot for a long time starting with an ARM  Acorn 
Archimedes.  I built Plplot5.00 back in the 90's using a collection of 
.bat files.  I still have it and it plots #(855) fine. I thought it was 
time to upgrade... I build using CMAKE 3.4.0-rc2 in its GUI form. It 
didn't seem to want to left me build a pdf device. Maybe I am not using 
it correctly.

A simplified version of my program is:

/*
   FontTest
*/
#include <math.h>
#include <plplot.h>

int main()
{
     int i;
     PLFLT x,y,dx,dy,theta,dTheta,xMin,xMax,yMin,yMax;

     xMin = -4.0; xMax = 1.0; yMin = -2.0; yMax = 2.0;

/* Set up viewport and window, but do not draw box */

     plinit();
     plenv( xMin, xMax, yMin, yMax, 0, 0 );
     plfontld(1);plfont(1);

     x = -2.0; y = 2.0*exp(-x*x/4.0); dy = -x*exp(-x*x/4.0); /* Find 
arrow slope */
     plptex(x, y,1.0,dy,0.5,"#(855)"); /* C2 Arrow */
     plptex(x,-y,dx,dy,0.5,"#(855)");  /* C1 Arrow */
     plptex(x,0,-1.0,0.0,0.5,"#(855)"); /* Gamma Arrow */

     plend();
     return 1;
}

Best Wishes, Peter

Re: [Plplot-devel] Font problems

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

Hi Alan, Peter,



I have ran example x07c under bare Windows - there was no problem with the PostScript output. Both symbols appear in the PostScript file, just as in the graphical window.



The symbols appear to be drawn though as Hershey symbols, the arrow head is a triangle made opaque with a couple of lines, not a filled triangle. I have not studied the actual rendering in any deep way (a trifle involved for the morning of a busy day), but I suspect that this might be the underlying cause.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, November 26, 2015 7:21 PM
> To: Peter Williams; Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Font problems
>
> On 2015-11-26 14:24-0000 Peter Williams wrote:
>
> > I am using plplot5.11.1 under Windows 7. There seems to be an
> > inconsistency between the plots using wingcc (the Win32 GCC device)
> > and PostScript. The libaries were build using cmake and MinGW. I plot
> > with plptex and pllab.
> >
> > Under wingcc: "#(855)" correctly appears as an arrow head, "#(2243)"
> > appears as the symbol "less than or equal to" .
> > Under Postscript nothing appears at all for both symbols.
>
> Hi Peter:
>
> Please run the following commands using the -DBUILD_TEST=ON cmake option.
>
> make ps #Create both -dev ps and -dev psc make x07c #Build the 7th standard C
> example examples/c/x07c -dev psc -o test.psc
>
> When you view those test.psc PostScript results are the 855 and 2243 symbols
> missing from pages 9 and 13 of the results?
>
> On Linux those symbols are rendered well (see the two attached screenshots).  So if
> your Windows results do not look like the Linux ones, then I think you need to install
> the 35 fonts which constitute the standard set of PostScript fonts.  I don't have any
> direct Cygwin experience, but for what it is worth, these fonts are packaged with the
> package name ghostscript-fonts-std-8.11-1 on Cygwin (at least that was the result
> when I searched the Cygwin package index for one of the
> 35 standard font file names).  I don't know how this standard set of fonts should be
> installed for non-Cygwin Windows platforms (which is the platform I assume you are
> using). It is these standard fonts that the ps device driver uses for rendering text.  If
> you are getting any text rendered at all from the above result then it appears -dev
> psc is finding at least some of the standard set of 35 PostScript fonts, but the
> problem may be that you have not installed all such fonts on your non-Cygwin
> Windows platform.
>
> @Arjen: I have noticed you already responded once, but could you do so again with
> your own results from the above test for both the Cygwin and non-Cygwin cases?  If
> you can replicate the Linux results for both your Cygwin and non-Cygwin Windows
> platforms then I hope you can give some advice to Peter about how you install the
> standard set of PostScript fonts on that latter platform.
>
> 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
> __________________________

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] Font problems

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

On 2015-11-26 14:24-0000 Peter Williams wrote:

> I am using plplot5.11.1 under Windows 7. There seems to be an
> inconsistency between the plots using wingcc (the Win32 GCC device) and
> PostScript. The libaries were build using cmake and MinGW. I plot with
> plptex and pllab.
>
> Under wingcc: "#(855)" correctly appears as an arrow head, "#(2243)"
> appears as the symbol "less than or equal to" .
> Under Postscript nothing appears at all for both symbols.

Hi Peter:

Please run the following commands using the
-DBUILD_TEST=ON cmake option.

make ps #Create both -dev ps and -dev psc
make x07c #Build the 7th standard C example
examples/c/x07c -dev psc -o test.psc

When you view those test.psc PostScript results are the 855 and 2243
symbols missing from pages 9 and 13 of the results?

On Linux those symbols are rendered well (see the two attached
screenshots).  So if your Windows results do not look like the Linux
ones, then I think you need to install the 35 fonts which constitute
the standard set of PostScript fonts.  I don't have any direct Cygwin
experience, but for what it is worth, these fonts are packaged with
the package name ghostscript-fonts-std-8.11-1 on Cygwin (at least that
was the result when I searched the Cygwin package index for one of the
35 standard font file names).  I don't know how this standard set of
fonts should be installed for non-Cygwin Windows platforms (which is
the platform I assume you are using). It is these standard fonts that
the ps device driver uses for rendering text.  If you are getting any
text rendered at all from the above result then it appears -dev psc is
finding at least some of the standard set of 35 PostScript fonts, but
the problem may be that you have not installed all such fonts on your
non-Cygwin Windows platform.

@Arjen: I have noticed you already responded once, but could you do so
again with your own results from the above test for both the Cygwin
and non-Cygwin cases?  If you can replicate the Linux results for both
your Cygwin and non-Cygwin Windows platforms then I hope you can give
some advice to Peter about how you install the standard set of
PostScript fonts on that latter platform.

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] Font problems

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

Hi Peter,



As far as I can tell, PostScript does not do non-ASCII characters at all - it is simply not part of PostScript (instead of being a problem in PLplot). I suggest you use a more modern output format instead, like PDF.



Regards,



Arjen



> -----Original Message-----
> From: Peter Williams [mailto:pet...@nt...]
> Sent: Thursday, November 26, 2015 3:24 PM
> To: plp...@li...
> Subject: [Plplot-devel] Font problems
>
> I am using plplot5.11.1 under Windows 7. There seems to be an inconsistency
> between the plots using wingcc (the Win32 GCC device) and PostScript. The
> libaries were build using cmake and MinGW. I plot with plptex and pllab.
>
> Under wingcc: "#(855)" correctly appears as an arrow head, "#(2243)"
> appears as the symbol "less than or equal to" .
> Under Postscript nothing appears at all for both symbols.
>
> --
>          Peter Williams
>    pet...@nt...
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing
> mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
> _______________________________________________
> 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.

[Plplot-devel] Font problems

[Peter W. <pet...@nt...>]

I am using plplot5.11.1 under Windows 7. There seems to be an 
inconsistency between the plots using wingcc (the Win32 GCC device) and 
PostScript. The libaries were build using cmake and MinGW. I plot with 
plptex and pllab.

Under wingcc: "#(855)" correctly appears as an arrow head, "#(2243)" 
appears as the symbol "less than or equal to" .
Under Postscript nothing appears at all for both symbols.

-- 
         Peter Williams
   pet...@nt...

[Plplot-devel] New Ada language support

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

I thought it was time to say something on list about the replacement
of the old Ada language support with new Ada language support that I
have just committed, and I would also like to take this opportunity to
publicly thank Greg Jung for his extensive testing assistance for
these changes.

This new Ada language support is based as closely as possible on the
CXX (C++) language support in CMake-3.4.0-rc3 to make debugging it as
straightforward as possible (as opposed to the old Ada language
support that was based on decade-old C/CXX/Fortran language support
that ignores all the useful language-support infrastructure that has
been developed for modern CMake).

The status of this project on Linux is all my tests of this new Ada
language support pass without issues. This includes the simple tests
in cmake/test_ada/README (cmake/test_ada is a self-contained Ada
project which builds a simple Ada library and a simple executable that
links to that library) and a comprehensive test of the corresponding
new Ada language support that I have integrated (as of my last commit,
cbaa084) into the PLplot project from the test_ada project.

That complete Linux success with the new Ada language support gives me
a fair degree of confidence that everything will also work on Mac OS X
(just like it did for the old Ada language support), but that Mac OS X
testing still needs to be done to confirm that (see below).

The status on Cygwin is in flux; we now do better there with the new
Ada language support compared to the old. However, the very last stage
of linking the "hello" executable finds some Ada inconsistencies.  I
may have discovered the solution for that issue, and I am currently
waiting for Greg to test that fix.

Because of the Linux success, I now call for additional testing on all
Unix platforms accessible to you guys (especially Mac OS X because I
do not want to have a support regression for that platform).  Start
with the simple tests in cmake/test_ada/README, and if those work
please move on to comprehensive testing.

For all Windows platforms, I suggest you hold off on testing Ada
unless and until Greg demonstrates that my fixes will yield good
(test_ada and comprehensive) test results on Cygwin.

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] Freeze date and release date have been delayed

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

My plans to actuate the freeze for merging large changes to master,
testing for a month or so and releasing before Christmas went up in
smoke because I was dealing with a number of issues such as a sick
computer and an extremely interesting and distracting baseball season
(for Blue Jays fans like me who suddenly had an interesting team
to watch after 20 years of mediocrity). But my computer is fine again and the
baseball season is finished (unfortunately without Jays winning the
World series, "but maybe next year") so I am now working on PLplot again.
Therefore, it is time to discuss once again when we should make that
freeze and release.

@Phil, Jim, and Arjen:

This discussion is primarily addressed to you guys because you have
wxwidgets fixes and extensions (Phil), new Windows device and plbuf
and plmeta upgrades (Jim), and a new Fortran interface (Arjen) that
are all "works in process".  And I would like to encourage all of
you to finish off those efforts rather than having them drag on
much longer.

>From my recent comprehensive testing results on Debian Jessie, I feel
the tip of the PLplot git master branch is in fairly good shape (aside
from the wxwidgets issues I mentioned), but I don't feel it is urgent
to immediately release the current set of bug fixes that have been
developed so far in this release cycle, and ideally I would like to
see a lot more merged to master before we release it. So my
inclination is to delay the release substantially (say until some time
in the first quarter next year) to give one of you/all of you the
chance to greatly improve wxwidgets (Phil) or merge something new that
is significant (Jim and Arjen) to master.  That delay might also allow
me to land a major fill fix and a major upgrade to epa_build that I
have been contemplating.

Anyhow, your input on the ideal release date (and freeze date roughly
one month before that release date) from the perspective of your
current PLplot development plans would be most welcome.

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] The D component of PLplot

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

On 2015-11-10 10:00-0700 Orion Poplawski wrote:

> On 11/09/2015 09:49 PM, Alan W. Irwin wrote:
>> On 2015-11-01 19:54-0700 Orion Poplawski wrote:
>>
>> [...]
>>> I don't enable D support on the Fedora package [....]
>>
>> Hi Orion:
>>
>> Our D results with the gdc compiler on the Debian Jessie Linux
>> platform are perfect right now as measured by comparing C and D
>> results for all our standard examples.  See the commit message giving
>> those latest test details at
>> <http://sourceforge.net/p/plplot/plplot/ci/16fe6dcb1e5acc3284f265af366eccc1b2099bfc>.
>>
>> Therefore, I encourage you to go ahead and package the D component of
>> PLplot for Fedora assuming gdc is packaged for that platform.
>
> Thanks for the detailed message.  However, gdc is not packaged for Fedora.

Hi Orion:

I suggest you draw attention concerning this gdc deficiency to the
Fedora group that maintains packaging of the gcc suite of compilers.
After all, this D compiler has been readily available as a package for
Debian and Debian based distributions for a long time so there should
be no barrier to Fedora making the D computer language available to
Fedora users via gdc.  Apparently (see
<http://www.digitalmars.com/d/archives/digitalmars/D/GDC_and_Fedora_20_220464.html>)
there is already a gdc specfile available for Fedora so it might not
be that much additional work for the "official" Fedora packagers of
gcc to automatically include gdc as well.

My understanding is gdc is in a similar situation to Ada; they both
are independent compiler efforts which strongly use gcc suite
capabilities to help with compilation (respectively of D and Ada
source code). Both efforts hope to become fully integrated with the
gcc suite eventually.  Obviously, the Ada community have pushed most
of the Linux, Mac OS X, and Windows distributions of free software to include gnatmake (the Ada compiler that
uses gcc suite capabilities), but it appears the D community advocacy
has not been as strong for gdc.  For example Greg Jung has found gdc
is missing for openSUSE, and it appears from the on-line package
search tools that gdc is missing from both Cygwin and
MinGW-w64/MSYS2.  Nevertheless, following the Debian packaging
efforts and also the already existing spec file, it may not be that
much extra work for Fedora to package gdc so I hope the Fedora
maintainers of gcc are willing to do that.

@Greg: same remarks about getting in contact with openSUSE gcc
packagers to see if they will consider packaging gdc as well.

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] The D component of PLplot

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

On 2015-11-09 20:49-0800 Alan W. Irwin wrote:

> On 2015-11-01 19:54-0700 Orion Poplawski wrote:
>
> [...]
>> I don't enable D support on the Fedora package [....]
>
> Hi Orion:
>
> Our D results with the gdc compiler on the Debian Jessie Linux
> platform are perfect right now as measured by comparing C and D
> results for all our standard examples.  See the commit message giving
> those latest test details at
> <http://sourceforge.net/p/plplot/plplot/ci/16fe6dcb1e5acc3284f265af366eccc1b2099bfc>.
> Therefore, I encourage you to go ahead and package the D component of
> PLplot for Fedora assuming gdc is packaged for that platform.
>
> It's possible that you dropped D in the past because for a long time
> we supported D version 1 and newer versions of gdc only supported D
> version 2.  However, this should no longer be a problem since Andrew
> has long since upgraded us from D version 1 to D version 2.
>
> I have emphasized gdc above since other D compiler choices (see
> <https://en.wikipedia.org/wiki/D_(programming_language)> are currently
> problematic on Linux.
>
> The dmd compiler is effectively eliminated by its closed-source nature
> from Linux distribution.  There is at least one dmd emulator (a
> wrapper for gdc) that is available on Linux (see
> <http://manpages.ubuntu.com/manpages/oneiric/man1/gdmd.1.html>). I
> have a report from Greg Jung that "dmd" (which I assume was such a
> wrapper) failed on openSUSE, and I attribute that problem to that
> wrapper not supporting all dmd command line options required by
> cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake. Our
> CMake language support favors dmd above gdc so when both the dmd
> wrapper and gdc are available and the wrapper does not work then you
> should specify gdc instead by setting the environment variable
>
> export DC=gdc
>
> In principal by copying
> cmake/modules/language_support/cmake/Platform/Linux-gdc.cmake to
> cmake/modules/language_support/cmake/Platform/Linux-ldc.cmake and
> changing option names from the gdc name and format to the equivalent
> ldc options our CMake language support for D could be extended to ldc,
> and I plan to try that at some point if nobody else beats me to it.
>
>
> In sum, dmd is proprietary, dmd wrappers might not support all the dmd
> options required by
> cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake, and
> there is currently no
> cmake/modules/language_support/cmake/Platform/Linux-ldc.cmake. Which
> currently essentially just leaves gdc as the only choice of D compiler
> on Linux that is suitable for building the D component of PLplot.

I followed up by looking carefully at our (inherited) D language
support code, and what it does at the moment is look at the compiler
identity and if that is gdc, it uses gcd PLatform packages such as
cmake/modules/language_support/cmake/Platform/Linux-gdc.cmake and
otherwise it assumes whatever D compiler that has been chosen by the
user is dmd compatible and uses dmd Platform packages such as
cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake.
Furthermore, I was interested to find that
the ldc package that is available from Debian Jessie includes
what appears to be a dmd wrapper (called ldmd2) so I tried that
(using export DC=ldmd2), but it proved to be incompatible with
cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake.
For example, the -version=whatever flag is allowed by ldmd2, but
-version=Posix (which appears in Linux-dmd.cmake) cannot be
used by ldmd2 because it is reserved.  I got further if I removed
-version=Posix from Linux-dmd.cmake, but then I ran into a problem
with finding the libphotos.a library and gave up at that point.

In sum, this dmd wrapper from the ldc project does not seem to be
exactly equivalent to dmd itself and/or/ Linux-dmd.cmake (written 8
years ago!) is incompatible with modern dmd.  So our effective D
compiler support continues to be limited to just gdc.  Note also that
a further look at
cmake/modules/language_support/cmake/CMakeDetermineDCompiler.cmake
shows that gdc is favored above dmd so if gdc and dmd are installed on
the system, cmake will find and use gdc.  Therefore, my remark above
concerning the user having to specify "export DC=gdc" when both
gdc and dmd are available was incorrect.

@Greg and Orion:

Now that you know gdc is absolutely necessary and dmd wrappers are
unlikely to cut it, have you both been able to find rpms that contain
the gdc compiler for openSUSE (Greg) and Fedora (Orion)?

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] I plan to bump the minimum CMake version to 3.3.2 for everybody but Linux and Cygwin users

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

On 2015-09-20 13:15-0700 Alan W. Irwin wrote:

> CMake 3.3.2 solves a fundamental and quite nasty CMake find regression
> that occurred from 3.2.0 through 3.3.1.
[...]
> The current status is our minimum version of CMake is 3.0.2 for Linux
> and Cygwin and 3.2.3 for everybody else. Once my computer is healthy
> again, and I can demonstrate no problems with CMake-3.3.2 on Linux, I
> plan to change our build system to issue a warning message about using
> any version of CMake from 3.2.0 through 3.3.1 if any of those versions
> are detected for our Linux and Cygwin users.  For everybody else I
> plan to avoid the issue altogether by bumping our minimum CMake
> version to 3.3.2.

My computer is healthy again, comprehensive testing of PLplot
using CMake-3.3.2 on my Debian Jessie platform works fine, and there
have been no objections to the above plan.  Therefore, I have made this change (see
<http://sourceforge.net/p/plplot/plplot/ci/747984161a74f785c5eade60bc9d53d43fdcbde4>).

Please let me know if you encounter any difficulties with CMake-3.3.2
on any platform accessible to you.

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] The D component of PLplot

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

On 11/09/2015 09:49 PM, Alan W. Irwin wrote:
> On 2015-11-01 19:54-0700 Orion Poplawski wrote:
> 
> [...]
>> I don't enable D support on the Fedora package [....]
> 
> Hi Orion:
> 
> Our D results with the gdc compiler on the Debian Jessie Linux
> platform are perfect right now as measured by comparing C and D
> results for all our standard examples.  See the commit message giving
> those latest test details at
> <http://sourceforge.net/p/plplot/plplot/ci/16fe6dcb1e5acc3284f265af366eccc1b2099bfc>.
> 
> Therefore, I encourage you to go ahead and package the D component of
> PLplot for Fedora assuming gdc is packaged for that platform.

Thanks for the detailed message.  However, gdc is not packaged for Fedora.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                   http://www.nwra.com

[Plplot-devel] The D component of PLplot

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

On 2015-11-01 19:54-0700 Orion Poplawski wrote:

[...]
> I don't enable D support on the Fedora package [....]

Hi Orion:

Our D results with the gdc compiler on the Debian Jessie Linux
platform are perfect right now as measured by comparing C and D
results for all our standard examples.  See the commit message giving
those latest test details at
<http://sourceforge.net/p/plplot/plplot/ci/16fe6dcb1e5acc3284f265af366eccc1b2099bfc>.
Therefore, I encourage you to go ahead and package the D component of
PLplot for Fedora assuming gdc is packaged for that platform.

It's possible that you dropped D in the past because for a long time
we supported D version 1 and newer versions of gdc only supported D
version 2.  However, this should no longer be a problem since Andrew
has long since upgraded us from D version 1 to D version 2.

I have emphasized gdc above since other D compiler choices (see
<https://en.wikipedia.org/wiki/D_(programming_language)> are currently
problematic on Linux.

The dmd compiler is effectively eliminated by its closed-source nature
from Linux distribution.  There is at least one dmd emulator (a
wrapper for gdc) that is available on Linux (see
<http://manpages.ubuntu.com/manpages/oneiric/man1/gdmd.1.html>). I
have a report from Greg Jung that "dmd" (which I assume was such a
wrapper) failed on openSUSE, and I attribute that problem to that
wrapper not supporting all dmd command line options required by
cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake. Our
CMake language support favors dmd above gdc so when both the dmd
wrapper and gdc are available and the wrapper does not work then you
should specify gdc instead by setting the environment variable

export DC=gdc

In principal by copying
cmake/modules/language_support/cmake/Platform/Linux-gdc.cmake to
cmake/modules/language_support/cmake/Platform/Linux-ldc.cmake and
changing option names from the gdc name and format to the equivalent
ldc options our CMake language support for D could be extended to ldc,
and I plan to try that at some point if nobody else beats me to it.


In sum, dmd is proprietary, dmd wrappers might not support all the dmd
options required by
cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake, and
there is currently no
cmake/modules/language_support/cmake/Platform/Linux-ldc.cmake. Which
currently essentially just leaves gdc as the only choice of D compiler
on Linux that is suitable for building the D component of PLplot.

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] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

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

On 2015-10-22 13:30-0400 Brad King wrote:

[...]
> Plplot's Ada support uses CMake internal APIs so it is plplot's
> responsibility to adapt to our changes:
[...]
> Where Plplot currently writes:
>
>  SET(CMAKE_Ada_COMPILE_OBJECT
>    "<CMAKE_Ada_COMPILER> <FLAGS> -c <SOURCE> -o <OBJECT>
>    ")
>
> try:
>
>  if(NOT CMAKE_VERSION VERSION_LESS 3.4)
>    set(CMAKE_Ada_COMPILE_OBJECT
>      "<CMAKE_Ada_COMPILER> <INCLUDES> <FLAGS> -c <SOURCE> -o <OBJECT>")
>  else()
>    set(CMAKE_Ada_COMPILE_OBJECT
>      "<CMAKE_Ada_COMPILER> <FLAGS> -c <SOURCE> -o <OBJECT>")
>  endif()

To bring this thread to conclusion, Orion implemented Brad's idea for
PLplot's Ada language support (see
<http://sourceforge.net/p/plplot/plplot/ci/5722b1754e384b62a18e20dc45d41785c1b40cbb/>),
and I just did the same thing for PLplot's D language support (see
<http://sourceforge.net/p/plplot/plplot/ci/16fe6dcb1e5acc3284f265af366eccc1b2099bfc>)
with good test results for Ada and D examples for both shared and
static libraries and both CMake-3.3.2 and CMake-3.4.0-rc3.

Thanks, Brad, for your essential help in solving these PLplot Ada and
D issues caused by the internal changes in CMake's language support
infrastructure for CMake-3.4.

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] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

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

On 2015-11-01 19:54-0700 Orion Poplawski wrote:

> On 10/31/2015 11:10 AM, Alan W. Irwin wrote:
>> Hi Orion:
>> 
>> Thanks for implementing Brad's suggestion to fix the PLplot Ada
>> language support issue for CMake-3.4.  To help give you PLplot git
>> credit for your work, would you please put the patch in "git
>> format-patch" form?
>
> Attached.

Hi Orion:

Tested (with cmake-3.3.2 and cmake-3.4.0-rc3) and applied
(<http://sourceforge.net/p/plplot/plplot/ci/5722b1754e384b62a18e20dc45d41785c1b40cbb/>)
with thanks!

>> I also notice substantial use of <FLAGS> in the PLplot D language
>> support case.
[...]
> I don't enable D support on the Fedora package, so I haven't looked at this.

It turns out there are indeed similar D example build problems with
CMake-3.4.0-rc3 so making the equivalent fix to PLplot's CMake
language support for D is next on my agenda.

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] More on wxwidgets issues on Linux

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

Hi Phil:

I just finished comprehensive testing of PLplot on my new (Debian
Jessie) platform after making a fairly large number of changes (see
series of commits leading up to "5fde587 Build system: Complete
rewrite of file and target dependency logic for test targets"). There
appear to be no major problems (i.e., build issues or run-time
segfaults) with these tests.  However, these results have reminded me
of following on-going wxwidgets issues that do need to be addressed.

1. The -np option currently only allows you to see example pages for
an extremely short time for the wxwidgets device.  So effectively the
page is a useless blank. We previously discussed a fix for this
issue(don't blank screen until ready to plot each new page).  That, of
course, does not deal with the problem for a single page or last page
of a series of pages for a given example.  So maybe a better thing to
try would be a ~one-second display period for each page if the -np
option is on.  Anyhow, I hope you create a good fix for this problem
soon which should make it possible to (briefly) check for any
wxwidgets rendering issues as the pages automatically fly by.

2. 79 timeout warnings distributed fairly evenly (somewhere between
7 and 10 for each of the tests) among the
comprehensive tests, i.e.,

software@raven> find ../comprehensive_test_disposeable/*/interactive/output_tree -name "*.out" |xargs grep "Failed to get text size from wxPLViewer - timeout" |sort |wc -l
79

software@raven> find ../comprehensive_test_disposeable/*/interactive/output_tree -name "*.out" |xargs grep "Failed to get text size from wxPLViewer - timeout" |sort |uniq --count
       9 ../comprehensive_test_disposeable/nondynamic/interactive/output_tree/installed_make_interactive.out:Failed to get text size from wxPLViewer - timeout
       8 ../comprehensive_test_disposeable/nondynamic/interactive/output_tree/make_interactive.out:Failed to get text size from wxPLViewer - timeout
       9 ../comprehensive_test_disposeable/nondynamic/interactive/output_tree/traditional_make_interactive.out:Failed to get text size from wxPLViewer - timeout
      10 ../comprehensive_test_disposeable/shared/interactive/output_tree/installed_make_interactive.out:Failed to get text size from wxPLViewer - timeout
       9 ../comprehensive_test_disposeable/shared/interactive/output_tree/make_interactive.out:Failed to get text size from wxPLViewer - timeout
       7 ../comprehensive_test_disposeable/shared/interactive/output_tree/traditional_make_interactive.out:Failed to get text size from wxPLViewer - timeout
       9 ../comprehensive_test_disposeable/static/interactive/output_tree/installed_make_interactive.out:Failed to get text size from wxPLViewer - timeout
       9 ../comprehensive_test_disposeable/static/interactive/output_tree/make_interactive.out:Failed to get text size from wxPLViewer - timeout
       9 ../comprehensive_test_disposeable/static/interactive/output_tree/traditional_make_interactive.out:Failed to get text size from wxPLViewer - timeout

Is this large number of timeouts expected or is some timeout period
being set too short for the Linux case?

3. The wxwidgets device on Linux has just barely adequate speed, i.e.,
it is the slowest interactive device by far.  My (two) cpu's are
essentially idle through all wxwidgets tests so both your
implementation of the new wxwidgets device and the wxwidgets library
are not locking up the cpu at all. Therefore, my working hypothesis to
explain this issue is your IPC method for Linux forces the originating
app and wxPLViewer to wait long periods of time for each other's
response.  So it appears to me substantial experimentation with your
Linux IPC method and tuning of that method is required to address this
issue.

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
__________________________