plplot-devel — Technical discussion about PLplot development

[Plplot-devel] javac warnings for Java example 20

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

Hi Andrew:

A build of the test_noninteractive target generates the following java warnings

cd /home/software/plplot/HEAD/build_dir/examples/java && /usr/bin/javac -classpath /home/software/plplot/HEAD/build_dir/bindings/java -d /home/software/plplot/HEAD/build_dir/examples/java -encoding UTF-8 /home/software/plplot/HEAD/plplot.git/examples/java/x20.java
/home/software/plplot/HEAD/plplot.git/examples/java/x20.java:328: warning: Resource leak: 'in' is never closed
         in  = new BufferedReader( new FileReader( fname ) );
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/home/software/plplot/HEAD/plplot.git/examples/java/x20.java:329: warning: Resource leak: 'in2' is never closed
         in2 = new DataInputStream( new DataInputStream( new BufferedInputStream( new FileInputStream( fname ) ) ) );
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2 problems (2 warnings)

Those are the only java warnings I get so we are in pretty good shape
with regard to the Java examples, but it would be nice to get rid of
these warnings completely.

For my Debian stable platform, javac refers to a gcj wrapper, i.e.,

software@raven> ls -l /etc/alternatives/javac
lrwxrwxrwx 1 root root 24 Oct  4 12:56 /etc/alternatives/javac -> /usr/bin/gcj-wrapper-4.9*

You can also generate these specific java example 20 warnings with the following much simpler
test:

software@raven> make VERBOSE=1 x20j >| x20j.out 2>&1

I have attached a compressed version of x20j.out to give you full
context.

Would you be willing to take a look at this?

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] Licencing and AGG

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

On 2015-11-07 19:39-0000 Phil Rosenberg wrote:

> Hi all

> Now that the wxWidgets AGG device is removed are there any other AGG
dependencies? I ask because AGG 2.5 has been released with a GPL
licence istead of the previous more permissive BSD licence. This means
that any version of Plplot built with AGG 2.5 must use the GPL
licence, not the LGPL licence. I don't know if we need to make this
clear anywhere?

Hi Phil:

The only AGG dependency left is for the -DOLD_WXWIDGETS=ON case.  I
think we will likely want to support that case for at least one more
release since my understanding is there are still some important wxwidgets
issues that you are working on for the default -DOLD_WXWIDGETS=OFF
case.  But however the decision goes about exactly what release we
decide to retire the -DOLD_WXWIDGETS=ON case, it is pretty obvious
that retirement will be relatively soon so I don't think we need to
worry that much about AGG 2.5 licensing issues.

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] Licencing and AGG

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

Hi all
Now that the wxWidgets AGG device is removed are there any other AGG dependencies? I ask because AGG 2.5 has been released with a GPL licence istead of the previous more permissive BSD licence. This means that any version of Plplot built with AGG 2.5 must use the GPL licence, not the LGPL licence. I don't know if we need to make this clear anywhere?

Phil

Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

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

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.

> I also notice substantial use of <FLAGS> in the PLplot D language
> support case. I assume your tests did not reveal any issues for D
> because you were not trying any D compiler flags, but I predict if you
> do that, you will encounter the same problem.  For example, if you try
>
> export DFLAGS=-Iwhatever
>
> I assume that (harmless) compile flag will correctly propagate to the D
> compile step (as seen
> by the VERBOSE=1 option for make) for older versions of CMake but will
> not propagate correctly for CMake-3.4.
>
> Anyhow, I am virtually positive there is also a PLplot <FLAGS> D
> language support issue for CMake-3.4 so if you don't beat me to it, I
> plan (likely late next week because I am currently tied up with
> something else) to expose that issue with a test like the one I
> suggested above and also plan to fix the issue following Brad's
> suggestion.

I don't enable D support on the Fedora package, so I haven't looked at this.

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

Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

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

On 2015-10-30 19:59-0600 Orion Poplawski wrote:

> On 10/22/2015 11:30 AM, Brad King wrote:
[...]
>> 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()
>> 
>> -Brad
>> 
>
> Ah, thank you very much.  The attached patch fixes this.

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?

I also notice substantial use of <FLAGS> in the PLplot D language
support case. I assume your tests did not reveal any issues for D
because you were not trying any D compiler flags, but I predict if you
do that, you will encounter the same problem.  For example, if you try

export DFLAGS=-Iwhatever

I assume that (harmless) compile flag will correctly propagate to the D compile step (as seen
by the VERBOSE=1 option for make) for older versions of CMake but will
not propagate correctly for CMake-3.4.

Anyhow, I am virtually positive there is also a PLplot <FLAGS> D
language support issue for CMake-3.4 so if you don't beat me to it, I
plan (likely late next week because I am currently tied up with
something else) to expose that issue with a test like the one I
suggested above and also plan to fix the issue following Brad's
suggestion.

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!

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

On 10/22/2015 11:30 AM, Brad King wrote:
> On 10/22/2015 11:28 AM, Orion Poplawski wrote:
>>>> This appears to have broken plplot's ada build on Fedora.
>>
>> FYI - builds still fail with cmake 3.4.0-rc2.  Have had time to look at it
>> closer.  plplot issue seems to be triggered by a change in Ada_FLAGS:
>>
>> -Ada_FLAGS =
>> -I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada
>> -I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada
>> +Ada_FLAGS =
>>
>> but plplot I believe has custom Ada cmake platform support.  I am still
>> concerned about possible regressions here.
>
> Plplot's Ada support uses CMake internal APIs so it is plplot's
> responsibility to adapt to our changes:
>
>   https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeAddNewLanguage.txt;hb=v3.4.0-rc2
>   Maintainers of external language support are responsible for porting
>   it to each version of CMake as upstream changes are made.
>
> Our 3.4.0-rc2 release notes point out a change likely causing this problem:
>
>   https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/3.4.rst;hb=v3.4.0-rc2#l271
>   * The internal "CMAKE_<LANG>_COMPILE_OBJECT" rule variable now
>     substitutes compiler include flags in a separate "<INCLUDES>"
>     placeholder instead of the main "<FLAGS>" placeholder.
>
> 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()
>
> -Brad
>

Ah, thank you very much.  The attached patch fixes this.

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

Re: [Plplot-devel] gnatmake: cannot specify a single executable for several mains

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

On 2015-10-22 17:08-0400 Tom Kacvinsky wrote:

> I have CMAKE_BUILD_TYPE set to DEBUG and I get the error message in the
> subject line.  I thought the Ada support from PLPlot was set up so that it
> could handle several different build types.  I guess this is not the case.

As far as I know, Ada language support has always just been limited to
the case where CMAKE_BUILD_TYPE was not set.

> What would it take to handle this?  I need at least a working debug
> configuration so I can find the debug Qt libraries (which is keyed off
> CMAKE_BUILD_TYPE).

Hi Tom:

Ada language support was written by me many years ago based on the
unsophisticated C and C++ language support available then for CMake.
So I strongly suspect what has to be done now to get language support
capabilities for Ada that are comparable to modern C/C++ capabilities
(e.g., full support for setting CMAKE_BUILD_TYPE) is to rewrite the
Ada language support based on the Modern C/C++ language support.

This is a non-trivial project since CMake language support is so badly
documented that developers who like to expand it to other languages
such as Ada must try a long series of essentially reverse-engineering
experiments to figure out what to do.  So modernizing CMake language
support for Ada is on my agenda but likely not in the near future
because of all the work involved.

For now, can you avoid the problem by simply disabling Ada (using
-DENABLE_ada=OFF) or do you really need access to the combination of
Ada and Qt?  For example, can you debug the Qt case for some other
language binding, e.g., C++?

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] gnatmake: cannot specify a single executable for several mains

[Tom K. <tom...@ve...>]

I have CMAKE_BUILD_TYPE set to DEBUG and I get the error message in the
subject line.  I thought the Ada support from PLPlot was set up so that it
could handle several different build types.  I guess this is not the case.
What would it take to handle this?  I need at least a working debug
configuration so I can find the debug Qt libraries (which is keyed off
CMAKE_BUILD_TYPE).

Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

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

In the past I had problems with the Ada module. Even though I don't have Ada installed the find module corrupted some build parameters. Since then I have always built with Ada switched off as I could never find the cause. Perhaps the two issues are linked.

Phil

-----Original Message-----
From: "Orion Poplawski" <or...@co...>
Sent: ‎22/‎10/‎2015 16:29
To: "CMake Mailing List" <cm...@cm...>; "Plplot-devel mailing list" <plp...@li...>
Subject: Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

On 10/07/2015 10:45 AM, Orion Poplawski wrote:
> On 10/06/2015 09:00 PM, Orion Poplawski wrote:
>> On 10/06/2015 09:42 AM, Robert Maynard wrote:
>>> I am proud to announce the first CMake 3.4 release candidate.
>>
>> This appears to have broken plplot's ada build on Fedora. Previous good (cmake
>> 3.3.2):
>>
>> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o
>> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && /usr/bin/gnatgcc
>> -I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada
>> -I/builddir/build/BUILD/plplot-5.11.1/bindings/ada    -c
>> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o
>> CMakeFiles/x00a.dir/x00a.o
>>
>> New bad:
>>
>> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o
>> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada &&
>> /usr/bin/gnatgcc   -c
>> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o
>> CMakeFiles/x00a.dir/x00a.o
>> x00a.adb:28:05: file "plplot_auxiliary.ads" not found
>> x00a.adb:29:05: file "plplot_traditional.ads" not found
>> examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target
>> 'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed
>>
>> So we're now missing the -I include dir options.
>>
>> That's all I have for now, I'll try to take a closer look later.
>>
> 
> There also appears to be a similar issue with building Paraview where the
> MPI_INLCUDE_PATH is no longer being passed to the compile line.
> 

FYI - builds still fail with cmake 3.4.0-rc2.  Have had time to look at it
closer.  plplot issue seems to be triggered by a change in Ada_FLAGS:


-Ada_FLAGS =
-I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada
-I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada
+Ada_FLAGS =

but plplot I believe has custom Ada cmake platform support.  I am still
concerned about possible regressions here.

-- 
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 mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

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

On 10/07/2015 10:45 AM, Orion Poplawski wrote:
> On 10/06/2015 09:00 PM, Orion Poplawski wrote:
>> On 10/06/2015 09:42 AM, Robert Maynard wrote:
>>> I am proud to announce the first CMake 3.4 release candidate.
>>
>> This appears to have broken plplot's ada build on Fedora. Previous good (cmake
>> 3.3.2):
>>
>> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o
>> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && /usr/bin/gnatgcc
>> -I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada
>> -I/builddir/build/BUILD/plplot-5.11.1/bindings/ada    -c
>> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o
>> CMakeFiles/x00a.dir/x00a.o
>>
>> New bad:
>>
>> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o
>> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada &&
>> /usr/bin/gnatgcc   -c
>> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o
>> CMakeFiles/x00a.dir/x00a.o
>> x00a.adb:28:05: file "plplot_auxiliary.ads" not found
>> x00a.adb:29:05: file "plplot_traditional.ads" not found
>> examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target
>> 'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed
>>
>> So we're now missing the -I include dir options.
>>
>> That's all I have for now, I'll try to take a closer look later.
>>
> 
> There also appears to be a similar issue with building Paraview where the
> MPI_INLCUDE_PATH is no longer being passed to the compile line.
> 

FYI - builds still fail with cmake 3.4.0-rc2.  Have had time to look at it
closer.  plplot issue seems to be triggered by a change in Ada_FLAGS:


-Ada_FLAGS =
-I/home/orion/fedora/plplot/plplot-5.11.1/build-3.3.2/examples/ada
-I/home/orion/fedora/plplot/plplot-5.11.1/bindings/ada
+Ada_FLAGS =

but plplot I believe has custom Ada cmake platform support.  I am still
concerned about possible regressions here.

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

Re: [Plplot-devel] [CMake] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

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

On 2015-10-06 21:00-0600 Orion Poplawski wrote:

> On 10/06/2015 09:42 AM, Robert Maynard wrote:
>> I am proud to announce the first CMake 3.4 release candidate.
>
> This appears to have broken plplot's ada build on Fedora. Previous good
> (cmake 3.3.2):
>
> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o
> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada &&
> /usr/bin/gnatgcc
> -I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada
> -I/builddir/build/BUILD/plplot-5.11.1/bindings/ada    -c
> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o
> CMakeFiles/x00a.dir/x00a.o
>
> New bad:
>
> [ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o
> cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada &&
> /usr/bin/gnatgcc   -c
> /builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o
> CMakeFiles/x00a.dir/x00a.o
> x00a.adb:28:05: file "plplot_auxiliary.ads" not found
> x00a.adb:29:05: file "plplot_traditional.ads" not found
> examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target
> 'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed
>
> So we're now missing the -I include dir options.
>
> That's all I have for now, I'll try to take a closer look later.

Hi Orion:

Thanks for your report of the above regression for the
CMake 3.4 release candidate.

To help make further progress with this regression, please provide the
complete set of commands that build the Ada wrapper library and the
Ada example rather than the above snippets.

The requested information can be determined using

cmake -DBUILD_TEST=ON ....
make VERBOSE=1 x00a >& x00a.out

Please execute those two commands for both cmake 3.3.2 and the 3.4
release candidate. Then attach compressed versions of the two x00a.out
files to a post to the plplot-devel mailing list, and I will attempt
to take it from there.

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!

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

On 10/06/2015 09:42 AM, Robert Maynard wrote:
> I am proud to announce the first CMake 3.4 release candidate.

This appears to have broken plplot's ada build on Fedora. Previous good 
(cmake 3.3.2):

[ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o
cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && 
/usr/bin/gnatgcc 
-I/builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada 
-I/builddir/build/BUILD/plplot-5.11.1/bindings/ada    -c 
/builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o 
CMakeFiles/x00a.dir/x00a.o

New bad:

[ 22%] Building Ada object examples/ada/CMakeFiles/x00a.dir/x00a.o
cd /builddir/build/BUILD/plplot-5.11.1/fedora/examples/ada && 
/usr/bin/gnatgcc   -c 
/builddir/build/BUILD/plplot-5.11.1/examples/ada/x00a.adb -o 
CMakeFiles/x00a.dir/x00a.o
x00a.adb:28:05: file "plplot_auxiliary.ads" not found
x00a.adb:29:05: file "plplot_traditional.ads" not found
examples/ada/CMakeFiles/x00a.dir/build.make:65: recipe for target 
'examples/ada/CMakeFiles/x00a.dir/x00a.o' failed

So we're now missing the -I include dir options.

That's all I have for now, I'll try to take a closer look later.

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

[Plplot-devel] OpenGL driver starter kit

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

Hello,

I am still interested in the idea of an OpenGL driver, however I am not 
that familiar with OpenGL myself. So, in the hopes that this will happen 
I am providing a branch of PLplot with a skeleton for the driver here:

https://github.com/HazenBabcock/PLplot/tree/opengl_driver_2015_10_06

This branch is up to date with PLplot as of today. This driver is 
incorporated into the PLplot build system, it should be able to find the 
OpenGL libraries on your system using cmake, and it will appear in the 
list of drivers available to PLplot. However it lacks any actual OpenGL 
code, all it does it print some messages when called by PLplot. If 
anyone is interested in filling this in that would be great.

-Hazen

[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...>]

CMake 3.3.2 solves a fundamental and quite nasty CMake find regression
that occurred from 3.2.0 through 3.3.1. See threads entitled "[BUG]
HINTS not correctly handled in find_program" and "find_program HINTS
no longer preferred over PATH" on the cmake-devel list.  I think this
regression will not affect users who only have the system versions of
libraries to find in the standard locations, but more sophisticated
users who are perhaps building their own sets of libraries that are
not installed in system locations could run into find trouble.  So it
is not a showstopper regression, but still it makes any bug report
specified for that range of CMake versions somewhat suspect in case
the error reported is a result of this find regression so to simplify
my life I prefer not to support the above CMake version range at all.

I have not yet had a chance to try 3.3.2 because of some computer
troubles I am still diagnosing (although it is likely a new disk
drive, Debian install, and restore from backup is in my near future).
However, Greg does report success with CMake-3.3.2 on MinGW-w64/MSYS2
so I encourage everyone here to give it a try also.

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.

Let me know if there are any strong objections to this plan for
dealing with the above regression.

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] Software package version support decisions

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

On 2015-09-13 21:25+0100 Phil Rosenberg wrote:

> [...]wxWidgets 3.0 has been around nearly two years and the
> "development precursor" wxWidgets 2.9 has been around 5 years. So
> maybe it is a good time to move up.

Yeah, I think bumping our minimum wxwidgets version to 3.0.0 (which I
have actually done already, see commit b4245b3f) was the best
decision.

It is extra work to support multiple versions of PLplot prerequisites
so the rule of thumb I normally use for such decisions is we support
only the latest version that appears in Debian stable (wxwidgets-3.0.x
in this case). Debian stable is fairly conservative about adopting new
versions so the latest version of any software in that distro is
likely to be available in Cygwin, MinGW-w64/MSYS2, and all major
modern Linux distros.  For example, it turns out that both Cygwin and
MinGW-w64/MSYS2 provide wxwidgets-3.0.x packages.  From previous
experience, I am sure modern versions of Ubuntu and other Debian
derivatives, Fedora, and openSUSE will also provide wxwidgets-3.0.0 or
later.

The above rule of thumb typically does not work for the so-called
enterprise class Linux distros such as RedHat (and its derivatives
like CentOS and Scientific Linux) which go out of their way to avoid
modern versions of software packages.  But users of such distros are
likely well aware of that limitation for them and will either use old
PLplot versions or build the modern Linux packages they need (e.g.,
with epa_build) which are prerequisites for their build of the latest
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] git blog

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

By the way, if you are interested in keeping to wxWidgets to 2.8, then
the wxUString is just used to convert from the utf32 format used by
plplot into wxWidgets wxString format.

I guess we could do that another way if we wanted?

That said wxWidgets 3.0 has been around nearly two years and the
"development precursor" wxWidgets 2.9 has been around 5 years. So
maybe it is a good time to move up.

Phil

On 12 September 2015 at 20:55, David MacMahon <da...@as...> wrote:
> Hi, Alan,
>
> I don't know of any such option, but perhaps a newer version of git has added this feature?
>
> Another option might be to "go rogue" and use the patch utility to apply the patch in the working copy, then "git add" and "git commit" manually.  Maybe patch will be able to ignore the whitespace changes?
>
> Wish I had a better answer for you,
> Dave
>
> On Sep 10, 2015, at 4:46 AM, Alan W. Irwin wrote:
>
>> I have a question for the git gurus here.
>>
>> I just ran into difficulty with git apply (as wrapped by git am)
>> because the patch file was created before a styling change that
>> changed whitespace not only for the context lines but also the
>> single line (in this case) that was replaced by several lines.
>>
>> "git help apply" says the following:
>>
>>  --ignore-space-change, --ignore-whitespace
>>    When applying a patch, ignore changes in whitespace in context lines if necessary.
>>
>> As documented this does work for style changes for the context lines, but not the
>> replacement line(s).
>>
>> Is there some other option (perhaps not yet documented in git help)
>> which is the equivalent of --ignore-all-space, i.e., ignore whitespace
>> changes in replaced lines as well?
>>
>> I also tried patch --ignore-whitespace --dry-run to see if that would
>> work, but it did not since from that documentation a run of whitespace
>> is treated effectively as a single blank, and in some cases styling
>> adds blanks where there were none before.
>>
>> In the present case, I worked around the issue by editing the single
>> replaced line to match the new styling, but that method is cumbersome
>> if there are a lot of replaced lines, and a git apply option to simply
>> --ignore-all-whitespace in both context and replaced lines would be
>> much better.  Is such an option out there for git apply?
>>
>> 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
>> __________________________
>>
>> ------------------------------------------------------------------------------
>> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
>> Get real-time metrics from all of your servers, apps and tools
>> in one place.
>> SourceForge users - Click here to start your Free Trial of Datadog now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] git blog

[David M. <da...@as...>]

Hi, Alan,

I don't know of any such option, but perhaps a newer version of git has added this feature?

Another option might be to "go rogue" and use the patch utility to apply the patch in the working copy, then "git add" and "git commit" manually.  Maybe patch will be able to ignore the whitespace changes?

Wish I had a better answer for you,
Dave

On Sep 10, 2015, at 4:46 AM, Alan W. Irwin wrote:

> I have a question for the git gurus here.
> 
> I just ran into difficulty with git apply (as wrapped by git am)
> because the patch file was created before a styling change that
> changed whitespace not only for the context lines but also the
> single line (in this case) that was replaced by several lines.
> 
> "git help apply" says the following:
> 
>  --ignore-space-change, --ignore-whitespace
>    When applying a patch, ignore changes in whitespace in context lines if necessary.
> 
> As documented this does work for style changes for the context lines, but not the
> replacement line(s).
> 
> Is there some other option (perhaps not yet documented in git help)
> which is the equivalent of --ignore-all-space, i.e., ignore whitespace
> changes in replaced lines as well?
> 
> I also tried patch --ignore-whitespace --dry-run to see if that would
> work, but it did not since from that documentation a run of whitespace
> is treated effectively as a single blank, and in some cases styling
> adds blanks where there were none before.
> 
> In the present case, I worked around the issue by editing the single
> replaced line to match the new styling, but that method is cumbersome
> if there are a lot of replaced lines, and a git apply option to simply
> --ignore-all-whitespace in both context and replaced lines would be
> much better.  Is such an option out there for git apply?
> 
> 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
> __________________________
> 
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Build error for your recent commit "Rewrite of the wxWidgets text processing methods"

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

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

> On 2015-09-09 14:30-0700 Alan W. Irwin wrote:
>
>> Hi Phil:
>>
>> I just discovered that commit 9dc7393d = "Rewrite of the wxWidgets
>> text processing methods" does not build on Debian oldstable with
>> wxwidgets version 2.8.12.1.  The reason is that version of wxwidgets
>> does not contain wx/ustring.h, i.e., your rewrite depends on
>> wxwidgets-3.0.0 or later.  That is fine with me since I generally
>> don't think we should go out of our way to support old versions of
>> software libraries (and in any case I will likely be moving to Debian
>> stable with wxwidgets version 3.0.2 in the near future).
>>
>> Anyhow, I am preceding on the assumption that the minimum version of
>> wxwidgets we support is now 3.0.0 (see my recent commit b4245b3 to
>> that effect).
>>
>> Please commit a change to README.release saying we only support
>> wxwidgets-3.0.0 or later so this change does not give a nasty surprise
>> to users who still are attempting to use wxwidgets-2.x.
>
> To Phil, Arjen, and Greg:
>
> @Phil:
> There are some build issues with this commit on Linux that I found
> once I switched to epa_built wxwidgets-3.0.2.
>
> Here are the relevant error messages for the build.  Note the location
> /home/wine/newstart/build_script/install-linux is the install prefix
> for epa_built software such as wxwidgets since I use my wine user
> account both for general wine testing and also epa_building on Linux.
>
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp: In member function ‘void wxPLDevice::DrawTextLine(PLUNICODE*, int, wxCoord,
>  wxCoord, PLFLT, PLFLT, bool, PLINT&, PLFLT&, PLFLT&, bool&, PLUNICODE&, wxCoord&, wxCoord&, wxCoord&)’:
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:984:47: error: call of overloaded ‘wxUString(PLUNICODE&)’ is ambiguous
[...]
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp: In member function ‘void wxPLDevice::DrawTextSection(wxString, wxCoord, wxCoord, PLFLT, PLFLT, bool, bool, PLUNICODE, wxCoord&, wxCoord&, wxCoord&)’:
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:1088:115: error: taking address of temporary [-fpermissive]
> make[2]: *** [drivers/CMakeFiles/wxwidgets.dir/wxwidgets_dev.cpp.o] Error 1
> make[1]: *** [drivers/CMakeFiles/wxwidgets.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs....

Greg sent me a git format-patch commit off-list which solved all the
above build issues for me.

Pushed (commit id a6d2a43) with thanks!

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] git blog

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

I have a question for the git gurus here.

I just ran into difficulty with git apply (as wrapped by git am)
because the patch file was created before a styling change that
changed whitespace not only for the context lines but also the
single line (in this case) that was replaced by several lines.

"git help apply" says the following:

  --ignore-space-change, --ignore-whitespace
    When applying a patch, ignore changes in whitespace in context lines if necessary.

As documented this does work for style changes for the context lines, but not the
replacement line(s).

Is there some other option (perhaps not yet documented in git help)
which is the equivalent of --ignore-all-space, i.e., ignore whitespace
changes in replaced lines as well?

I also tried patch --ignore-whitespace --dry-run to see if that would
work, but it did not since from that documentation a run of whitespace
is treated effectively as a single blank, and in some cases styling
adds blanks where there were none before.

In the present case, I worked around the issue by editing the single
replaced line to match the new styling, but that method is cumbersome
if there are a lot of replaced lines, and a git apply option to simply
--ignore-all-whitespace in both context and replaced lines would be
much better.  Is such an option out there for git apply?

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] What are your current plans for the plmeta device?

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

On 2015-09-09 22:12-0400 Jim Dishaw wrote:

> I'm still working on plmeta, though my progress is slow right now do
to some other commitments. If you want to temporarily disable, that
would be fine with me. I will try to see if I can get something
finished by the deadline. Thanks and sorry for the delay.

Hi Jim:

It is good to hear that you anticipate finishing something large by
the deadline for pushing large changes to master despite your other
time commitments.  I am sure we all look forward to testing whatever
you can come up with.

Just to clarify, as release manager I like our release deadlines to be
fairly flexible to keep the release process reasonably friendly and
encouraging for our developers.  So if you have something that is
honestly almost ready to go, I am not going to be too hard-nosed about
that deadline which is supposed to be September 19th IIRC.  Thus, if
we delayed that deadline to September 26th it would not kill us.
However, if it turns out you cannot be done with some big change by
that date I will probably say "mature your work on a private topic
branch and be ready to push it to master at the very start of the next
release cycle" in the interest of getting this next release out the
door with sufficent time allowed to do the required iterated bug
fixing and comprehensive testing for all the big changes (such as the
recent wxwidgets changes) already in this release.

After the official freeze on large changes being pushed to master is
in effect (likely either September 19th or 26th from the above
discussion) then if plmeta still does not build at that stage, I will
completely disable plmeta (by commenting it out of
cmake/modules/drivers-init.cmake).  For now as a matter of convenience
for you in getting rid of this plmeta build issue I will leave it as
disabled by default (i.e., you can still attempt to build plmeta if
you specify -DPLD_plmeta=ON or -DDEFAULT_ALL_DEVICES=ON).

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] Your recent commit "Rewrite of the wxWidgets text processing methods"

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

On 2015-09-09 18:01-0700 Greg Jung wrote:

> I think I hit on a few discrepancies in the use of that wx/ustring.h --
>
> /d/bld/opensuse/plplot-gitclone/drivers/wxwidgets_dev.cpp: In member
>> function ‘void wxPLDevice::DrawTextLine(PLUNICODE*, int, wxCoord, wxCoord,
>> PLFLT, PLFLT, bool, PLINT&, PLFLT&, PLFLT&, bool&, PLUNICODE&, wxCoord&,
>> wxCoord&, wxCoord&)’:
>> /d/bld/opensuse/plplot-gitclone/drivers/wxwidgets_dev.cpp:984:47: error:
>> call of overloaded ‘wxUString(PLUNICODE&)’ is ambiguous
>>                  section += wxUString( ucs4[i] );
>>                                                ^
>> /d/bld/opensuse/plplot-gitclone/drivers/wxwidgets_dev.cpp:984:47: note:
>> candidates are:
>> In file included from
>> /d/bld/opensuse/plplot-gitclone/drivers/wxwidgets_dev.cpp:48:0:
>> /usr/include/wx-3.0/wx/ustring.h:63:5: note:
>> wxUString::wxUString(wxUniChar)
>>      wxUString( wxUniChar ch )                                   {
>> assign(ch); }
>>      ^
>
> etc. .. test output is attached

Hi Greg:

Let's keep this discussion on the plplot-devel mailing list.

Thanks for that openSUSE report.  I just sent off a post to the
plplot-devel mailing list (before reading the above off-list post to
Phil and me) where I described exactly the same issue for my own Linux
testing.  Until a fix is found I imagine this issue (now confirmed by
you on a completely different Linux platform) will also affect your
comprehensive tests for the Cygwin and MinGW-w64/MSYS2 platforms.

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] Build error for your recent commit "Rewrite of the wxWidgets text processing methods"

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

On 2015-09-09 14:30-0700 Alan W. Irwin wrote:

> Hi Phil:
>
> I just discovered that commit 9dc7393d = "Rewrite of the wxWidgets
> text processing methods" does not build on Debian oldstable with
> wxwidgets version 2.8.12.1.  The reason is that version of wxwidgets
> does not contain wx/ustring.h, i.e., your rewrite depends on
> wxwidgets-3.0.0 or later.  That is fine with me since I generally
> don't think we should go out of our way to support old versions of
> software libraries (and in any case I will likely be moving to Debian
> stable with wxwidgets version 3.0.2 in the near future).
>
> Anyhow, I am preceding on the assumption that the minimum version of
> wxwidgets we support is now 3.0.0 (see my recent commit b4245b3 to
> that effect).
>
> Please commit a change to README.release saying we only support
> wxwidgets-3.0.0 or later so this change does not give a nasty surprise
> to users who still are attempting to use wxwidgets-2.x.

To Phil, Arjen, and Greg:

@Phil:
There are some build issues with this commit on Linux that I found
once I switched to epa_built wxwidgets-3.0.2.

Here are the relevant error messages for the build.  Note the location
/home/wine/newstart/build_script/install-linux is the install prefix
for epa_built software such as wxwidgets since I use my wine user
account both for general wine testing and also epa_building on Linux.

/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp: In member function ‘void wxPLDevice::DrawTextLine(PLUNICODE*, int, wxCoord,
  wxCoord, PLFLT, PLFLT, bool, PLINT&, PLFLT&, PLFLT&, bool&, PLUNICODE&, wxCoord&, wxCoord&, wxCoord&)’:
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:984:47: error: call of overloaded ‘wxUString(PLUNICODE&)’ is ambiguous
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:984:47: note: candidates are:
In file included from /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:48:0:
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:63:5: note: wxUString::wxUString(wxUniChar)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:62:5: note: wxUString::wxUString(wxChar32)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:61:5: note: wxUString::wxUString(wxChar16)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:60:5: note: wxUString::wxUString(char)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:58:5: note: wxUString::wxUString(const wxString&)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:57:5: note: wxUString::wxUString(const wxCStrData*) <near match>
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:57:5: note:   no known conversion for argument 1 from ‘PLUNICODE 
{aka unsigned int}’ to ‘const wxCStrData*’
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:54:5: note: wxUString::wxUString(const wxChar16*) <near match>
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:54:5: note:   no known conversion for argument 1 from ‘PLUNICODE {aka unsigned int}’ to ‘const wxChar16* {aka const short unsigned int*}’
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:49:5: note: wxUString::wxUString(const char*) <near match>
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:49:5: note:   no known conversion for argument 1 from ‘PLUNICODE {aka unsigned int}’ to ‘const char*’
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:46:5: note: wxUString::wxUString(const wxChar32*) <near match>
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:46:5: note:   no known conversion for argument 1 from ‘PLUNICODE {aka unsigned int}’ to ‘const wxChar32* {aka const wchar_t*}’
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:41:47: note: wxUString::wxUString(const wxUString&)
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:1043:43: error: call of overloaded ‘wxUString(PLUNICODE&)’ is ambiguous
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:1043:43: note: candidates are:
In file included from /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:48:0:
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:63:5: note: wxUString::wxUString(wxUniChar)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:62:5: note: wxUString::wxUString(wxChar32)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:61:5: note: wxUString::wxUString(wxChar16)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:60:5: note: wxUString::wxUString(char)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:58:5: note: wxUString::wxUString(const wxString&)
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:57:5: note: wxUString::wxUString(const wxCStrData*) <near match>
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:57:5: note:   no known conversion for argument 1 from ‘PLUNICODE {aka unsigned int}’ to ‘const wxCStrData*’
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:54:5: note: wxUString::wxUString(const wxChar16*) <near match>
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:54:5: note:   no known conversion for argument 1 from ‘PLUNICODE {aka unsigned int}’ to ‘const wxChar16* {aka const short unsigned int*}’
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:49:5: note: wxUString::wxUString(const char*) <near match>
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:49:5: note:   no known conversion for argument 1 from ‘PLUNICODE {aka unsigned int}’ to ‘const char*’
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:46:5: note: wxUString::wxUString(const wxChar32*) <near match>
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:46:5: note:   no known conversion for argument 1 from ‘PLUNICODE {aka unsigned int}’ to ‘const wxChar32* {aka const wchar_t*}’
/home/wine/newstart/build_script/install-linux/include/wx-3.0/wx/ustring.h:41:47: note: wxUString::wxUString(const wxUString&)
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp: In member function ‘void wxPLDevice::DrawTextSection(wxString, wxCoord, wxCoord, PLFLT, PLFLT, bool, bool, PLUNICODE, wxCoord&, wxCoord&, wxCoord&)’:
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets_dev.cpp:1088:115: error: taking address of temporary [-fpermissive]
make[2]: *** [drivers/CMakeFiles/wxwidgets.dir/wxwidgets_dev.cpp.o] Error 1
make[1]: *** [drivers/CMakeFiles/wxwidgets.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

@Arjen and Greg: Note, I am pretty sure from the above results this
issue will show up for your comprehensive testing on Cygwin and
MinGW-w64/MSYS2. It also obviously blocks me from doing further wxwidgets
testing until it is fixed.

@Phil: Do you confirm the above build issues on one of the gcc
platforms (Cygwin, MinGW-w64/MSYS2, and/or Linux) accessible to you? I
assume some casts will take care of the wxUString overloading issues,
but I don't have a clue how to fix the last build error "error: taking
address of temporary [-fpermissive]" so I leave all of this to you to
figure out.

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] What are your current plans for the plmeta device?

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

I'm still working on plmeta, though my progress is slow right now do to some other commitments. If you want to temporarily disable, that would be fine with me. I will try to see if I can get something finished by the deadline. Thanks and sorry for the delay. 



> On Sep 9, 2015, at 5:48 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Jim:
> 
> I believe you have discussed what you wanted to do with the plmeta device
> before, but I am having difficulty finding that dicussion so could you summarize
> again what your plans are?
> 
> This is especially relevant now because the mid-September deadline for
> pushing large changes to the master branch is fast approaching.
> (Although the deadline is a little soft so if you need a week or so
> extra, we can negotiate when that freeze occurs.)
> 
> The plmeta device was recently brought to my attention because it
> currently does not build when I use the option
> -DDEFAULT_ALL_DEVICES=ON. That is obviously a far from ideal result so
> I hope you will be able to fix this issue in the near future.
> 
> As I recall, you are developing command-line options that contain
> essentially all the historical plmeta device capability. If that is
> the case, maybe the way to fix the build issue is simply to comment
> out plmeta from cmake/modules/drivers-init.cmake?  That change would
> temporarily or indefinitely retire that device so
> -DDEFAULT_ALL_DEVICES=ON ignores it.
> 
> 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] What are your current plans for the plmeta device?

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

Hi Jim:

I believe you have discussed what you wanted to do with the plmeta device
before, but I am having difficulty finding that dicussion so could you summarize
again what your plans are?

This is especially relevant now because the mid-September deadline for
pushing large changes to the master branch is fast approaching.
(Although the deadline is a little soft so if you need a week or so
extra, we can negotiate when that freeze occurs.)

The plmeta device was recently brought to my attention because it
currently does not build when I use the option
-DDEFAULT_ALL_DEVICES=ON. That is obviously a far from ideal result so
I hope you will be able to fix this issue in the near future.

As I recall, you are developing command-line options that contain
essentially all the historical plmeta device capability. If that is
the case, maybe the way to fix the build issue is simply to comment
out plmeta from cmake/modules/drivers-init.cmake?  That change would
temporarily or indefinitely retire that device so
-DDEFAULT_ALL_DEVICES=ON ignores it.

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] Your recent commit "Rewrite of the wxWidgets text processing methods"

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

Hi Phil:

I just discovered that commit 9dc7393d = "Rewrite of the wxWidgets
text processing methods" does not build on Debian oldstable with
wxwidgets version 2.8.12.1.  The reason is that version of wxwidgets
does not contain wx/ustring.h, i.e., your rewrite depends on
wxwidgets-3.0.0 or later.  That is fine with me since I generally
don't think we should go out of our way to support old versions of
software libraries (and in any case I will likely be moving to Debian
stable with wxwidgets version 3.0.2 in the near future).

Anyhow, I am preceding on the assumption that the minimum version of
wxwidgets we support is now 3.0.0 (see my recent commit b4245b3 to
that effect).

Please commit a change to README.release saying we only support
wxwidgets-3.0.0 or later so this change does not give a nasty surprise
to users who still are attempting to use wxwidgets-2.x.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________