plplot-devel — Technical discussion about PLplot development

[Plplot-devel] I am having trouble figuring out why the -eofill command-line option is being ignored for -dev wxwidgets

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

Hi Phil:

Just to remind you, all device drivers are supposed to use the
even-odd fill rule if pls->dev_eofill is 1 and the non-zero fill rule
otherwise where the differences between the two fill rules are
nicely illustrated in <https://en.wikipedia.org/wiki/Nonzero-rule>.
And if you look at the wxPLDevice::FillPolygon code in
drivers/wxwidgets_dev.cpp, all appears to be well, i.e., we
have the following logic:

if ( pls->dev_eofill )
    {
        m_dc->DrawPolygon( pls->dev_npts, points, xoffset, yoffset, wxODDEVEN_RULE );
    }
else
    {
        m_dc->DrawPolygon( pls->dev_npts, points, xoffset, yoffset, wxWINDING_RULE );
    }

Furthermore, pls->dev_eofill is by default 0, but it can be set to 1
using the -eofill command-line option.  And standard example 27 has lots
of nice pages where plfill is called for complex self-intersecting
paths.

So running that example using, e.g.,

examples/c/x27c -dev <device>

and

examples/c/x27c -dev <device> -eofill

illustrates the large differences between the two different fill rules
when the device is one of our interactive devices other than wxwidgets
(e.g., xwin, tk, xwin, xcairo, or qtwidget), but -dev wxwidgets has a
bug where the wxPLViewer app it communicates with only shows the
non-zero fill rule result regardless of whether -eofill is used or
not.

My recent attempt to debug that issue with gdb shows that 
wxPLDevice::FillPolygon does nothing other than to immediately return
because m_dc is NULL.  So although I was able to confirm with gdb that
pls->dev_eofill is set properly by the -eofill command-line option,
the routine never gets to the above m_dc->DrawPolygon calls and some
other wxwidgets-related PLplot logic appears to be responding to
the plfill calls in example 27 using a fixed non-zero fill rule, i.e.,
wxPLViewer rendered fill results use the non-zero fill rule for
that example.

<aside> I am pretty sure from these results that the non-zero fill
rule is likely the default provided by the wxWidgets libraries since
that is the default X, Qt, and pango/cairo library fill rule, and that
(fixed) fill rule is what we are currently getting out of -dev
wxwidgets (and wxPLViewer). Of course, that conclusion is completely
contradicted by <http://docs.wxwidgets.org/3.0/classwx_d_c.html> which
states the odd-even fill rule is the default for the wxWidgets
libraries, but I am fairly sure that documentation is just flat-out
wrong in this particular regard. </aside>

So given that background, here are two questions for you which I hope
will be easy for you to answer.

1. Why is m_dc always NULL for repeat calls to plfill effectively
making wxPLDevice::FillPolygon a no-op?

2. What alternative routine in our wxwidgets-related code actually responds to calls
to plfill?

Once you give me the answer to 2. I think there is a good chance it
will be a simple matter for me to install pls->dev_eofill testing logic
similar to the above to specify the fill rule we want to be used at
run-time as opposed to the fixed non-zero fill rule that is now being
used.

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] [Bug] Plmap omits lines at the left hand side of the map

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

On 2017-09-28 21:31+0100 Phil Rosenberg wrote:

> Hi Mark and anyone else who is listening
> I have just fixed the map plots. Apologies that this has taken
> sooooooo long. The changes have just been pushed to the development
> version and have been checked on my windows machine. Note that you
> were correct also about there being an issue with using plmapfill. It
> turned out that the type specified in the shapefile was overriding the
> render type specified by the user.
>
> While I was there I realised there was a problem with rendering
> polygons that wrap round the whole globe such as Antarctica so that
> should now be fixed too.
>

@Mark:

Thanks for spotting these issues that Phil just fixed.

For your information, the git master branch version (what Phil just
pushed) includes an earlier change by me where all the deprecated
plmap cruft was removed.

@Phil:

After fixing up some minor style and trailing space issues (commit
e60fba8 which I just pushed), I tested your changes in the build tree
and for the shared libraries case on Linux using the -DBUILD_TEST=ON
option.  My build of the test_noninteractive target (which build
PLplot libraries, bindings, devices, and examples and which executes
each of our file devices for each of our C examples as well as
comparing -dev psc results for all our supported languages) continues
to work well.  That is, there are no obvious configure, build, or
run-time issue, and no regressions on the remaining (OCaml) PostScript
differences with C example results. I also ran

examples/c/x19c -dev xcairo

, and there are no obvious rendering issues in those results (and
presumably also for all other devices/languages).  I also
built the "validate" target (which tests your DocBook documentation
changes for any validation errors) without issues.

In sum, your current set of changes looks fine to me, and thanks for
this effort!

> For those who may now how plfill works a bit better than me, something
> that is supported by shapefiles, but currently not by plmap, is holes.
> A polygon in a shapefile consists of multiple parts and clockwise
> parts are filled whereas anticlockwise parts are holes. Is this
> something we can do relatively easily with plfill or is it not really
> doable?

I don't think that such a major change to plfill would be a good idea.
For example, calls to plsurf3d (example 8) and plshades (example 16)
end up at the lowest level as many different calls to plfill where
presumably some end up as anti-clockwise fills and some end up
as clockwise fills in difficult-to-predict ways.

Therefore, would it be possible for you to honor this shapefile
convention by simply not calling plfill from inside the plmap*
routines whenever they run into an anticlockwise part and by
changing our DocBook documentation of those routines appropriately?

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] [Bug] Plmap omits lines at the left hand side of the map

[Mark de W. <m.d...@da...>]

Hi Phil,

On 28.9.17 22:31, Phil Rosenberg wrote:
> I have just fixed the map plots. Apologies that this has taken
> sooooooo long. The changes have just been pushed to the development
> version and have been checked on my windows machine. Note that you
> were correct also about there being an issue with using plmapfill. It
> turned out that the type specified in the shapefile was overriding the
> render type specified by the user.

Thanks for the fixes.

I just tested with HEAD and the polygon code no longer crashes.

Next I wanted to test with a map with lines and no fill. Unfortunately 
plmapline also draws filled polygons. I did this test with the same 
shapefiles [1] as the original test.

I assume it is caused by the code: src/plmap.c:324
     if ( shapetype == SHPT_NULL ) 

     { 

         shapetype = fileShapeType; 

     } 



The attached patch lets plmapline draw lines instead of filled polygons.

I tested HEAD+patch and the coastal lines no longer disappear, so that 
issue is also fixed.

I will do more testing next week, thanks again for the fixes.


[1] 
http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip

Regards,
Mark de Wever

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

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

Hi Mark, well spotted. Patch applied. Thanks for the contribution.

On 29 September 2017 at 11:00, Mark de Wever <m.d...@da...> wrote:
> Hi Phil,
>
> On 28.9.17 22:31, Phil Rosenberg wrote:
>>
>> I have just fixed the map plots. Apologies that this has taken
>> sooooooo long. The changes have just been pushed to the development
>> version and have been checked on my windows machine. Note that you
>> were correct also about there being an issue with using plmapfill. It
>> turned out that the type specified in the shapefile was overriding the
>> render type specified by the user.
>
>
> Thanks for the fixes.
>
> I just tested with HEAD and the polygon code no longer crashes.
>
> Next I wanted to test with a map with lines and no fill. Unfortunately
> plmapline also draws filled polygons. I did this test with the same
> shapefiles [1] as the original test.
>
> I assume it is caused by the code: src/plmap.c:324
>     if ( shapetype == SHPT_NULL )
>     {
>         shapetype = fileShapeType;
>     }
>
>
> The attached patch lets plmapline draw lines instead of filled polygons.
>
> I tested HEAD+patch and the coastal lines no longer disappear, so that issue
> is also fixed.
>
> I will do more testing next week, thanks again for the fixes.
>
>
> [1]
> http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/50m/cultural/ne_50m_admin_0_countries_lakes.zip
>
> Regards,
> Mark de Wever

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side of the map

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

Hi Mark and anyone else who is listening
I have just fixed the map plots. Apologies that this has taken
sooooooo long. The changes have just been pushed to the development
version and have been checked on my windows machine. Note that you
were correct also about there being an issue with using plmapfill. It
turned out that the type specified in the shapefile was overriding the
render type specified by the user.

While I was there I realised there was a problem with rendering
polygons that wrap round the whole globe such as Antarctica so that
should now be fixed too.

For those who may now how plfill works a bit better than me, something
that is supported by shapefiles, but currently not by plmap, is holes.
A polygon in a shapefile consists of multiple parts and clockwise
parts are filled whereas anticlockwise parts are holes. Is this
something we can do relatively easily with plfill or is it not really
doable?

Phil

On 18 November 2016 at 10:41, Mark de Wever <m.d...@da...> wrote:
> Hi,
>
> Recently I ran into an issue with the plplot 5.11.1 on Windows. The plmap
> code seems to omit lines entirely when a part of the line is not visible.
> This only occurs when the line is not visible on the left hand side of the
> plot. When a part is not visible on the right hand side it is properly
> shown.
>
> At my Debian Stable system I use the system's 5.10.0 version. There the
> issue doesn't occur. (I noticed the plmap code has been rewritten between
> 5.10.0 and 5.11.0.) I also tested the bug on Debian Stable with 5.11.1 and a
> recent master [d71e48], both have the issue.
>
> Attached a modified example 19 where the bug is shown. The first plot shows
> the entire coast of Ireland. The second plot should only omit a small part
> of the coast, but instead the entire coast has been removed. Only the
> internal border of Ireland remains visible. This seems to happen with all
> coast lines; I picked Ireland since it shows the bug nicely.
>
>
> Regards,
> Mark de Wever
>
> PS: It seems the old deprecated plmap code no longer shows a map (at least
> on Windows). I didn't investigate further, I just installed the shapelib
> library.
>
> PPS: There also seems to be another issue with a filled polygon map, but I'm
> still investigating. If it really is an issue, I'll report it.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] How to use plplot in my project using cmake ?

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

On 2017-09-26 10:43+0200 Laurent Berger wrote:

> Hi alan,
>
> Ok  in this folder http://perso.univ-lemans.fr/~berger/Afsd56/plplot/ you got 
> everything from git clone to wxopencv build
>
> In http://perso.univ-lemans.fr/~berger/Afsd56/plplot/ you can find result of 
> plplot install
> in http://perso.univ-lemans.fr/~berger/Afsd56/plplot/TXT_INFO/ you 've got 
> cmakecache and cmakeoutput for plplot and same file for wxopencv project 
> using plplot. In buildprocessplplot.txt you have results from git clone, 
> build plplot in debug and release and install process.
>
> In my wwxopencv project I use too ceres-solver glog and gflag and opencv and 
> openscenegraph lib
>
> my script command to install plplot and wxopencv are installplplot.sh and 
> installwxopencv.sh
>
> if something is missing tell me what

Hi Laurent:

I looked at
<http://perso.univ-lemans.fr/~berger/Afsd56/plplot/TXT_INFO/installPlplot.sh>.

>From my perspective alone, the major issue with that script
is you are attempting to use cmake in a way that is largely outside my
experience.  For example, I have no experience with the --build option
for cmake, only limited Windows experience (with the Wine version of
Windows) and no experience with the "Visual Studio 14 2015 Win64"
generator.

In order for me to help you further, here is what I would like you to
do.  Please switch to a more low-level PLplot configure and build
process that I have a better chance of understanding.  That is, you
should use the "NMake Makefiles" generator and do your build with
nmake like this without using the cmake --build option.

cmake -G"NMake Makefiles" $optCMAKE \
-DBUILD_SHARED_LIBS:BOOL=OFF \
-DwxWidgets_ROOT_DIR:PATH=G:/lib/wxWidgets-3.1.0 \
-DwxWidgets_LIB_DIR:PATH=G:/lib/wxWidgets-3.1.0/lib/vc_x64_lib \
../../"$RepoSource" 
nmake VERBOSE=1 install

So the only change from what you are currently doing is the choice of
generator for cmake and running nmake rather than several different
cmake --build commands to do the installation.  Note, that nmake
simply builds the named target ("install" in this case which also
builds the "all" target first). The VERBOSE=1 option outputs some
extra details that are sometimes useful. Then all I really need to see
for this PLplot case is the output (combined stderr and stdout) from
this slightly revised script which should include all output
from both the above cmake and nmake commands.

Once I understand what is going on with the PLplot configure (with
cmake) and build and install (with nmake), then we should follow up
with a similar analysis of the configure and build of your own
software.

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] How to use plplot in my project using cmake ?

[Laurent B. <lau...@un...>]

Hi alan,

Ok  in this folder http://perso.univ-lemans.fr/~berger/Afsd56/plplot/ 
you got everything from git clone to wxopencv build

In http://perso.univ-lemans.fr/~berger/Afsd56/plplot/ you can find 
result of plplot install
in http://perso.univ-lemans.fr/~berger/Afsd56/plplot/TXT_INFO/ you 've 
got cmakecache and cmakeoutput for plplot and same file for wxopencv 
project using plplot. In buildprocessplplot.txt you have results from 
git clone, build plplot in debug and release and install process.

In my wwxopencv project I use too ceres-solver glog and gflag and opencv 
and openscenegraph lib

my script command to install plplot and wxopencv are installplplot.sh 
and installwxopencv.sh

if something is missing tell me what



Le 26/09/2017 à 09:44, Alan W. Irwin a écrit :
> On 2017-09-26 09:01+0200 Laurent Berger wrote:
>
>> Hi Alan,
>>
>>
>> I tried this
>>
>> if (PLplot_FOUND)
>> message( " PATH0 ${PLplotwx_LIBS}" )
>> message( " PATH1  ${PLplot_INCLUDE_DIR}" )
>> message( " PATH3 ${PLplot_DIR}" )
>> message( " PATH4 ${PLplotcxx_LIBS}" )
>> get_target_property(PLplotwx_LIBS plplotwxwidgets 
>> INTERFACE_LINK_LIBRARIES)
>> get_target_property(PLplot_LIBS plplot INTERFACE_LINK_LIBRARIES)
>> get_target_property(PLplotcxx_LIBS plplotcxx INTERFACE_LINK_LIBRARIES)
>> message( " PATH0 ${PLplotwx_LIBS}" )
>> message( " PATH1  ${PLplot_INCLUDE_DIR}" )
>> message( " PATH3 ${PLplot_LIBS}" )
>> message( " PATH4 ${PLplotcxx_LIBS}" )
>> include_directories(${INCLUDE_DIR})
>>    include_directories(${PLplot_DIR}/../../../include/plplot)
>>    target_link_libraries( wxOpenCVMain ${PLplotwx_LIBS})
>> else (PLplot_FOUND)
>> message( " PROBLEME" )
>> endif(PLplot_FOUND)
>>
>> and and cmake output is :
>>
>> PATH0
>> PATH1
>> PATH3 C:/Program Files/plplot/lib/cmake/plplot
>> PATH4
>> PATH0 
>> plplot;plplotcxx;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31ud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31u.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31ud_core.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31u_core.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpngd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpng.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiffd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiff.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpegd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpeg.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlibd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlib.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexud.lib>;$<$<NOT:$<CONFIG:DE 
>> BUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexu.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpatd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpat.lib>;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32 
>>
>> PATH1
>> PATH3 
>> $<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31ud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31u.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31ud_core.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31u_core.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpngd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpng.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiffd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiff.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpegd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpeg.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlibd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlib.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWi 
>> dgets-3.1.0/lib/vc_x64_lib/wxregexu.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpatd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpat.lib>;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32;csirocsa;qsastime 
>>
>> PATH4 plplot
>> -- WINDOWS
>> -- G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: G:/Lib/build/wxOpenCV
>>
>> In my project I got only this libs
>> C:\Program Files\plplot\lib\plplot.lib
>> C:\Program Files\plplot\lib\plplotcxx.lib
>> C:\Program Files\plplot\lib\csirocsa.lib
>> C:\Program Files\plplot\lib\qsastime.lib
>>
>> plplotwxwidgets is missing
>>
>> I think I miss something because my cmakelist is too complicated
>
> Hi Laurent:
>
> Please put yourself in my position of not knowing exactly how you
> built and installed PLplot and not knowing the complete details of
> your own project's build system.  Then send me _all_ the information
> you think I might possibly need in order to help you further.
>
> For example,
>
> 1. What is the complete cmake stdout and stderr output from your
> PLplot configuration step?
>
> 2. What is the complete output when you built the "install" target
> for PLplot?
>
> 3. Above you have only given me a part of the CMake logic used to 
> configure your own project.  Please send me all of that
> logic (or give me a URL where I can browse it).
>
> Also, please send me any other information you think might be
> relevant.  Note, if you send too little information (as now), I cannot
> help you, but if you send too much, I can simply ignore the parts I
> don't need and use the rest to help you.
>
> In sum, limited information from you = current situation = bad, lots
> of information from you = future situation = good.  :-)
>
> 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] How to use plplot in my project using cmake ?

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

On 2017-09-26 09:01+0200 Laurent Berger wrote:

> Hi Alan,
>
>
> I tried this
>
> if (PLplot_FOUND)
> message( " PATH0 ${PLplotwx_LIBS}" )
> message( " PATH1  ${PLplot_INCLUDE_DIR}" )
> message( " PATH3 ${PLplot_DIR}" )
> message( " PATH4 ${PLplotcxx_LIBS}" )
> get_target_property(PLplotwx_LIBS plplotwxwidgets INTERFACE_LINK_LIBRARIES)
> get_target_property(PLplot_LIBS plplot INTERFACE_LINK_LIBRARIES)
> get_target_property(PLplotcxx_LIBS plplotcxx INTERFACE_LINK_LIBRARIES)
> message( " PATH0 ${PLplotwx_LIBS}" )
> message( " PATH1  ${PLplot_INCLUDE_DIR}" )
> message( " PATH3 ${PLplot_LIBS}" )
> message( " PATH4 ${PLplotcxx_LIBS}" )
> include_directories(${INCLUDE_DIR})
>    include_directories(${PLplot_DIR}/../../../include/plplot)
>    target_link_libraries( wxOpenCVMain ${PLplotwx_LIBS})
> else (PLplot_FOUND)
> message( " PROBLEME" )
> endif(PLplot_FOUND)
>
> and and cmake output is :
>
> PATH0
> PATH1
> PATH3 C:/Program Files/plplot/lib/cmake/plplot
> PATH4
> PATH0 
> plplot;plplotcxx;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31ud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31u.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31ud_core.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31u_core.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpngd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpng.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiffd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiff.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpegd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpeg.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlibd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlib.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexud.lib>;$<$<NOT:$<CONFIG:DE 
> BUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexu.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpatd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpat.lib>;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32
> PATH1
> PATH3 
> $<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31ud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31u.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31ud_core.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31u_core.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpngd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpng.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiffd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiff.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpegd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpeg.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlibd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlib.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWi 
> dgets-3.1.0/lib/vc_x64_lib/wxregexu.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpatd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpat.lib>;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32;csirocsa;qsastime
> PATH4 plplot
> -- WINDOWS
> -- G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib
> -- Configuring done
> -- Generating done
> -- Build files have been written to: G:/Lib/build/wxOpenCV
>
> In my project I got only this libs
> C:\Program Files\plplot\lib\plplot.lib
> C:\Program Files\plplot\lib\plplotcxx.lib
> C:\Program Files\plplot\lib\csirocsa.lib
> C:\Program Files\plplot\lib\qsastime.lib
>
> plplotwxwidgets is missing
>
> I think I miss something because my cmakelist is too complicated

Hi Laurent:

Please put yourself in my position of not knowing exactly how you
built and installed PLplot and not knowing the complete details of
your own project's build system.  Then send me _all_ the information
you think I might possibly need in order to help you further.

For example,

1. What is the complete cmake stdout and stderr output from your
PLplot configuration step?

2. What is the complete output when you built the "install" target
for PLplot?

3. Above you have only given me a part of the CMake logic 
used to configure your own project.  Please send me all of that
logic (or give me a URL where I can browse it).

Also, please send me any other information you think might be
relevant.  Note, if you send too little information (as now), I cannot
help you, but if you send too much, I can simply ignore the parts I
don't need and use the rest to help you.

In sum, limited information from you = current situation = bad, lots
of information from you = future situation = good.  :-)

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] How to use plplot in my project using cmake ?

[Laurent B. <lau...@un...>]

Hi Alan,


I tried this

if (PLplot_FOUND)
message( " PATH0 ${PLplotwx_LIBS}" )
message( " PATH1  ${PLplot_INCLUDE_DIR}" )
message( " PATH3 ${PLplot_DIR}" )
message( " PATH4 ${PLplotcxx_LIBS}" )
get_target_property(PLplotwx_LIBS plplotwxwidgets INTERFACE_LINK_LIBRARIES)
get_target_property(PLplot_LIBS plplot INTERFACE_LINK_LIBRARIES)
get_target_property(PLplotcxx_LIBS plplotcxx INTERFACE_LINK_LIBRARIES)
message( " PATH0 ${PLplotwx_LIBS}" )
message( " PATH1  ${PLplot_INCLUDE_DIR}" )
message( " PATH3 ${PLplot_LIBS}" )
message( " PATH4 ${PLplotcxx_LIBS}" )
include_directories(${INCLUDE_DIR})
     include_directories(${PLplot_DIR}/../../../include/plplot)
     target_link_libraries( wxOpenCVMain ${PLplotwx_LIBS})
else (PLplot_FOUND)
message( " PROBLEME" )
endif(PLplot_FOUND)

and and cmake output is :

  PATH0
  PATH1
  PATH3 C:/Program Files/plplot/lib/cmake/plplot
  PATH4
  PATH0 
plplot;plplotcxx;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31ud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31u.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31ud_core.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31u_core.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpngd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpng.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiffd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiff.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpegd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpeg.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlibd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlib.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexu.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpatd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpat.lib>;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32
  PATH1
  PATH3 
$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31ud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxbase31u.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31ud_core.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxmsw31u_core.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpngd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxpng.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiffd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxtiff.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpegd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxjpeg.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlibd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxzlib.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexud.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxregexu.lib>;$<$<CONFIG:DEBUG>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpatd.lib>;$<$<NOT:$<CONFIG:DEBUG>>:G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib/wxexpat.lib>;winmm;comctl32;oleacc;rpcrt4;shlwapi;version;wsock32;csirocsa;qsastime
  PATH4 plplot
-- WINDOWS
-- G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib
-- Configuring done
-- Generating done
-- Build files have been written to: G:/Lib/build/wxOpenCV

In my project I got only this libs
C:\Program Files\plplot\lib\plplot.lib
C:\Program Files\plplot\lib\plplotcxx.lib
C:\Program Files\plplot\lib\csirocsa.lib
C:\Program Files\plplot\lib\qsastime.lib

plplotwxwidgets is missing

I think I miss something because my cmakelist is too complicated


Le 20/09/2017 à 08:03, Alan W. Irwin a écrit :
> On 2017-09-19 19:36+0200 Laurent Berger wrote:
>
>> Hi Alan,
>>
>>
>> About lplot-devel posting issues : new subscribe solved problem
>>
>>
>> To install plplot I use install project (with admin right) to install 
>> plplot in C:\Program Files\plplot. A copy of my plplot folder is 
>> perso.univ-lemans.fr/~berger/Afsd56/plplot
>>
>>
> [...]
>>> But you need to give more details (i.e., the CMake logic you used to
>>> determine the values of ${PLplot_INCLUDE_DIR} and ${PLplot_LIBS}, and
>>> the actual locations on your disk for the PLplot headers and
>>> libraries) before we can help you determine _why_ those variables are
>>> empty.
>
>> I don't understand.
>
> Hi Laurant,
>
> From what you have said, my understanding is you have already built
> and installed PLplot, and now you want to use the PLplot installed
> headers and libraries in your own software project that you are
> configuring with CMake.
>
> PLplot solves a similar problem when it creates a CMake-based build
> system for our installed examples that uses the PLplot headers
> and libraries to build those examples.
>
> So you should be adapting our logic (see
> examples/CMakeLists.txt starting at
>
> else(CORE_BUILD)
>
> ) for your own needs.  For example, following our logic, your project 
> should set CMAKE_MODULE_PATH to get access
> to the installed PLplot locations .../cmake/modules and
> .../cmake/modules/language_support/cmake so that the commands
>
> include(plplot_configure)
> find_package(plplot)
>
> work correctly to import everything you need to know about the
> PLplot installation into your own project.
>
> Of course, in the future it would be helpful to users with your needs
> if one of the PLplot developers developed a simple tutorial example of
> a project that builds software that uses the PLplot headers and
> libraries.  But nobody has created such a tutorial example yet so all
> we have for you at the present time is to suggest you adapt our own
> logic as above to satisfy your own needs.
>
> 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] How to use plplot in my project using cmake ?

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

On 2017-09-19 19:36+0200 Laurent Berger wrote:

> Hi Alan,
>
>
> About lplot-devel posting issues : new subscribe solved problem
>
>
> To install plplot I use install project (with admin right) to install plplot 
> in C:\Program Files\plplot. A copy of my plplot folder is 
> perso.univ-lemans.fr/~berger/Afsd56/plplot
>
>
[...]
>> But you need to give more details (i.e., the CMake logic you used to
>> determine the values of ${PLplot_INCLUDE_DIR} and ${PLplot_LIBS}, and
>> the actual locations on your disk for the PLplot headers and
>> libraries) before we can help you determine _why_ those variables are
>> empty.

> I don't understand.

Hi Laurant,

>From what you have said, my understanding is you have already built
and installed PLplot, and now you want to use the PLplot installed
headers and libraries in your own software project that you are
configuring with CMake.

PLplot solves a similar problem when it creates a CMake-based build
system for our installed examples that uses the PLplot headers
and libraries to build those examples.

So you should be adapting our logic (see
examples/CMakeLists.txt starting at

else(CORE_BUILD)

) for your own needs.  For example, following our logic, your project should set CMAKE_MODULE_PATH to get access
to the installed PLplot locations .../cmake/modules and
.../cmake/modules/language_support/cmake so that the commands

include(plplot_configure)
find_package(plplot)

work correctly to import everything you need to know about the
PLplot installation into your own project.

Of course, in the future it would be helpful to users with your needs
if one of the PLplot developers developed a simple tutorial example of
a project that builds software that uses the PLplot headers and
libraries.  But nobody has created such a tutorial example yet so all
we have for you at the present time is to suggest you adapt our own
logic as above to satisfy your own needs.

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] How to use plplot in my project using cmake ?

[Laurent B. <lau...@un...>]

Hi Alan,


About lplot-devel posting issues : new subscribe solved problem


To install plplot I use install project (with admin right) to install 
plplot in C:\Program Files\plplot. A copy of my plplot folder is 
perso.univ-lemans.fr/~berger/Afsd56/plplot

I don't understand.


Le 19/09/2017 à 18:54, Alan W. Irwin a écrit :
> On 2017-09-18 21:23+0200 Laurent Berger wrote:
>
>> Hi,
>>
>> Thanks for new version (5.13.0). I have installed plplot and now I 
>> want to use it in my own project using cmake
>>
>> my cmakelist is
>>
>>
>> if (wxWidgets_FOUND)
>>    include_directories(${wxWidgets_INCLUDE_DIRS})
>>    target_link_libraries (wxOpenCVMain ${wxWidgets_LIBRARIES} )
>> endif (wxWidgets_FOUND)
>> if (PLplot_FOUND)
>> message( " PATH  ${PLplot_INCLUDE_DIR} ${PLplot_LIBS}" )
>> message( " PATH ${PLplot_DIR} ${PLplot_LIBS}" )
>>    include_directories(${PLplot_INCLUDE_DIRS})
>>    target_link_libraries( wxOpenCVMain ${PLplot_LIBS} )
>> else (PLplot_FOUND)
>> message( " PROBLEME" )
>> endif(PLplot_FOUND)
>>
>>
>> I can see  in cmake output
>> OPENCV = 
>> G:/Lib/install/opencv/include;G:/Lib/install/opencv/include/opencv
>> PATH
>> PATH C:/Program Files/plplot/lib/cmake/plplot
>> -- WINDOWS
>> -- G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: G:/Lib/build/wxOpenCV
>>
>>
>> but nothing in variable PLplot_INCLUDE_DIR .
>>
>> Where is my mistake ?
>
> Hi Laurent:
>
> I am glad you finally were able to figure out your plplot-devel posting
> issues.
>
> From your first message logic above, and the output shown, it appears
> _both_ ${PLplot_INCLUDE_DIR} and ${PLplot_LIBS} are empty, while
> ${PLplot_DIR} is filled with C:/Program Files/plplot/lib/cmake/plplot.
>
> But you need to give more details (i.e., the CMake logic you used to
> determine the values of ${PLplot_INCLUDE_DIR} and ${PLplot_LIBS}, and
> the actual locations on your disk for the PLplot headers and
> libraries) before we can help you determine _why_ those variables are
> empty.
>
> 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] How to use plplot in my project using cmake ?

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

On 2017-09-18 21:23+0200 Laurent Berger wrote:

> Hi,
>
> Thanks for new version (5.13.0). I have installed plplot and now I want to 
> use it in my own project using cmake
>
> my cmakelist is
>
>
> if (wxWidgets_FOUND)
>    include_directories(${wxWidgets_INCLUDE_DIRS})
>    target_link_libraries (wxOpenCVMain ${wxWidgets_LIBRARIES} )
> endif (wxWidgets_FOUND)
> if (PLplot_FOUND)
> message( " PATH  ${PLplot_INCLUDE_DIR} ${PLplot_LIBS}" )
> message( " PATH ${PLplot_DIR} ${PLplot_LIBS}" )
>    include_directories(${PLplot_INCLUDE_DIRS})
>    target_link_libraries( wxOpenCVMain ${PLplot_LIBS} )
> else (PLplot_FOUND)
> message( " PROBLEME" )
> endif(PLplot_FOUND)
>
>
> I can see  in cmake output
> OPENCV = G:/Lib/install/opencv/include;G:/Lib/install/opencv/include/opencv
> PATH
> PATH C:/Program Files/plplot/lib/cmake/plplot
> -- WINDOWS
> -- G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib
> -- Configuring done
> -- Generating done
> -- Build files have been written to: G:/Lib/build/wxOpenCV
>
>
> but nothing in variable PLplot_INCLUDE_DIR .
>
> Where is my mistake ?

Hi Laurent:

I am glad you finally were able to figure out your plplot-devel posting
issues.

>From your first message logic above, and the output shown, it appears
_both_ ${PLplot_INCLUDE_DIR} and ${PLplot_LIBS} are empty, while
${PLplot_DIR} is filled with C:/Program Files/plplot/lib/cmake/plplot.

But you need to give more details (i.e., the CMake logic you used to
determine the values of ${PLplot_INCLUDE_DIR} and ${PLplot_LIBS}, and
the actual locations on your disk for the PLplot headers and
libraries) before we can help you determine _why_ those variables are
empty.

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] How to use plplot in my project using cmake ?

[Laurent B. <lau...@un...>]

Hi,

Thanks for new version (5.13.0). I have installed plplot and now I want 
to use it in my own project using cmake

my cmakelist is


if (wxWidgets_FOUND)
     include_directories(${wxWidgets_INCLUDE_DIRS})
     target_link_libraries (wxOpenCVMain ${wxWidgets_LIBRARIES} )
endif (wxWidgets_FOUND)
if (PLplot_FOUND)
message( " PATH  ${PLplot_INCLUDE_DIR} ${PLplot_LIBS}" )
message( " PATH ${PLplot_DIR} ${PLplot_LIBS}" )
     include_directories(${PLplot_INCLUDE_DIRS})
     target_link_libraries( wxOpenCVMain ${PLplot_LIBS} )
else (PLplot_FOUND)
message( " PROBLEME" )
endif(PLplot_FOUND)


I can see  in cmake output
OPENCV = G:/Lib/install/opencv/include;G:/Lib/install/opencv/include/opencv
  PATH
  PATH C:/Program Files/plplot/lib/cmake/plplot
-- WINDOWS
-- G:/Lib/wxWidgets-3.1.0/lib/vc_x64_lib
-- Configuring done
-- Generating done
-- Build files have been written to: G:/Lib/build/wxOpenCV


but nothing in variable PLplot_INCLUDE_DIR .

Where is my mistake ?

thanks for your answer.

Re: [Plplot-devel] Can statically allocated z arrays be used as the z argument for plshade (and plshades, plcont, plimage, and plvect)?

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

Hi Phil:

I am not quite sure how I could absolutely prove yesterday's tentative
hypothesis that statically allocated 2D arrays reference a single
block of memory with no storage of pointers to each of the row vectors
because gdb and C compilers make certain hidden assumptions that only
those with complete knowledge of the C standards could figure out. But
having slept on it, I do think that tentative hypothesis is correct.

Therefore on that assumption here is a revision of the C example which
demonstrates how easy it is to make an Iliffe vector (which does
store those pointers) from a static 2D
array.

____________________________
// C programme to test casts of a statically allocated array

#include<stdio.h>
void main(void)
{
   int zStatic[2][3];
   int* zCast = (int*)zStatic;
   int (*zCast2)[3] = zStatic;
   int * zIliffe[2];
   zStatic[0][0] = 0;
   zStatic[0][1] = 1;
   zStatic[0][2] = 2;
   zStatic[1][0] = 3;
   zStatic[1][1] = 4;
   zStatic[1][2] = 5;
   zIliffe[0] = zStatic[0];
   zIliffe[1] = zStatic[1];

   printf("%d, %d, %d, %d, %d, %d\n", zStatic[0][0], zStatic[0][1], zStatic[0][2], zStatic[1][0], zStatic[1][1], zStatic[1][2]);
   printf("%d, %d, %d, %d, %d, %d\n", zCast[0], zCast[1], zCast[2], zCast[3], zCast[4], zCast[5]);
   printf("%d, %d, %d, %d, %d, %d\n", zCast2[0][0], zCast2[0][1], zCast2[0][2], zCast2[1][0], zCast2[1][1], zCast2[1][2]);
   printf("%d, %d, %d, %d, %d, %d\n", zIliffe[0][0], zIliffe[0][1], zIliffe[0][2], zIliffe[1][0], zIliffe[1][1], zIliffe[1][2]);
}
____________________________

The (perfect) valgrind results are

irwin@raven> gcc -g test_2d_static.c 
irwin@raven> valgrind ./a.out
==18848== Memcheck, a memory error detector
==18848== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
al.
==18848== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==18848== Command: ./a.out
==18848== 
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
==18848== 
==18848== HEAP SUMMARY:
==18848==     in use at exit: 0 bytes in 0 blocks
==18848==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==18848== 
==18848== All heap blocks were freed -- no leaks are possible
==18848== 
==18848== For counts of detected and suppressed errors, rerun with: -v
==18848== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

That conversion from static 2D array to Iliffe vector is so
straightforward, I plan to allow all our C (and C++) users to call
plshade, plshades, plcont, plimage, or plvect with an Iliffe vector
that is conveniently determined (like above) with one call to an
extremely simple routine (still to be implemented, but let's
tentatively call it plStatic2dGrid in analogy with plAlloc2dGrid) that
generates that Iliffe vector from a corresponding statically allocated
z array. And also following the plAlloc2dGrid analogy, wrap that
routine as Static2dGrid for the c++ binding, but do not propagate it
to any other binding. Then follow up by using plStatic2dGrid in
examples/c/x15c and Static2dGrid in examples/c++/x15.cc and also by
documenting these 2D array nuances for C, C++, and the rest of our
different bindings.

Development of (pl)Static2dGrid, of course, means there is little
purpose to plshade1 anymore even as a demonstration routine. 
Therefore, I have changed my plans for plshade1 back from converting
it to a C-only demonstration routine to deprecating it (and eventually
eliminating it) again.

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] Can statically allocated z arrays be used as the z argument for plshade (and plshades, plcont, plimage, and plvect)?

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

On 2017-09-15 09:10+0100 Phil Rosenberg wrote:

> The output [from C++ example code you provided] is
> 0,1,2,3
> 0,1,2,3
> 00000000,00000001
>
> So this shows that a static 2d array is really just a pointer, not a
> double pointer. One of the features of C is that you are permitted to
> cast a pointer to one type to a pointer to any other type. You need
> may need this to get to the bit level of binary data, e.g. swapping
> endianness - read in a word, cast a pointer to that word to a pointer
> to a char, swap the byte order. For zCast2 we are casting a pointer to
> an int, to a pointer to a pointer to an int. Prefectly acceptable to
> the compiler, but it is our responsibility to ensure this is sensible.
> In the commented out line, we go to zCast[0], find a value of
> 00000000, i.e. a NULL pointer, so by trying to get the zeroth element
> of this array we are trying to do *(NULL+0) which of course gives a
> segfault.
>
> I have no idea why the warning you have in GCC. You are right, it
> looks like it implies z is a pointer to an array. But I am certain
> that it won't be.

My understanding is that the semantics for pointers and arrays are
different for C than they are for C++ so I think we should stick to C
to draw any conclusions.

So here is a C version of your example code which confirms that
casting to int ** leads to an invalid read and segfault.
However, this same example also shows zStatic can be cast to a
pointer to an array with absolutely no issues!

// C programme to test casts of a statically allocated array

#include<stdio.h>
void main(void)
{
   int zStatic[2][3];
   int* zCast = (int*)zStatic;
   int (*zCast2)[3] = zStatic;
   int ** zCast3 = (int **)zCast2;
   zStatic[0][0] = 0;
   zStatic[0][1] = 1;
   zStatic[0][2] = 2;
   zStatic[1][0] = 3;
   zStatic[1][1] = 4;
   zStatic[1][2] = 5;

   printf("%d, %d, %d, %d, %d, %d\n", zStatic[0][0], zStatic[0][1], zStatic[0][2], zStatic[1][0], zStatic[1][1], zStatic[1][2]);
   printf("%d, %d, %d, %d, %d, %d\n", zCast[0], zCast[1], zCast[2], zCast[3], zCast[4], zCast[5]);
   printf("%d, %d, %d, %d, %d, %d\n", zCast2[0][0], zCast2[0][1], zCast2[0][2], zCast2[1][0], zCast2[1][1], zCast2[1][2]);
   printf("%d, %d, %d, %d, %d, %d\n", zCast3[0][0], zCast3[0][1], zCast3[0][2], zCast3[1][0], zCast3[1][1], zCast3[1][2]);
}

irwin@raven> gcc -g test_2d_static.c 
irwin@raven> ./a.out
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
Segmentation fault
irwin@raven> valgrind ./a.out
==15290== Memcheck, a memory error detector
==15290== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==15290== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==15290== Command: ./a.out
==15290== 
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
==15290== Invalid read of size 4
==15290==    at 0x400640: main (test_2d_static.c:20)
==15290==  Address 0x30000000a is not stack'd, malloc'd or (recently) free'd
==15290== 
==15290== 
==15290== Process terminating with default action of signal 11 (SIGSEGV)
==15290==  Access not within mapped region at address 0x30000000A
==15290==    at 0x400640: main (test_2d_static.c:20)
==15290==  If you believe this happened as a result of a stack
==15290==  overflow in your program's main thread (unlikely but
==15290==  possible), you can try to increase the size of the
==15290==  main thread stack using the --main-stacksize= flag.
==15290==  The main thread stack size used in this run was 8388608.
==15290== 
==15290== HEAP SUMMARY:
==15290==     in use at exit: 0 bytes in 0 blocks
==15290==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==15290== 
==15290== All heap blocks were freed -- no leaks are possible
==15290== 
==15290== For counts of detected and suppressed errors, rerun with: -v
==15290== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

If you comment out the last printf, then the valgrind result is

==15299== Memcheck, a memory error detector
==15299== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et
al.
==15299== Using Valgrind-3.10.0 and LibVEX; rerun with -h for
copyright info
==15299== Command: ./a.out
==15299== 
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
0, 1, 2, 3, 4, 5
==15299== 
==15299== HEAP SUMMARY:
==15299==     in use at exit: 0 bytes in 0 blocks
==15299==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==15299== 
==15299== All heap blocks were freed -- no leaks are possible
==15299== 
==15299== For counts of detected and suppressed errors, rerun with: -v
==15299== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

i.e., perfect!

So the conclusion appears to be a cast to a pointer to a pointer leads
to invalid reads/segfaults, but a cast to a pointer to an array works
fine.  It is the strong C distinction between array and pointer in this
context that I am trying to understand at this stage.

I am currently leaning towards the following tentative explanation:

int zStatic[2][3];

and

int (*zCast2)[3];

are actually identical types that describe a single block of memory
containing 6 ints and NOTHING else.  So the second version isn't
actually a pointer to an array in the Iliffe sense where there is a
block of memory containing the addresses of the various row vectors.
But for both types above the "3" does give the essential information
to the compiler so that subsequent references to zStatic[0][2] or
zCast2[0][2] "just work".

Does that explanation of what is going on make sense to you?

Anyhow, my best guess at this stage is I will be able to confirm this
tentative explanation (no block of memory that contains addresses with
the statically allocated array) with gdb results, but we will see.

>> There are two more related topics.

You appear not to feel strongly about either of these so here is
what I am going to do for each of them.
>>
>> I. Deprecation of plshade1?

Although we have not yet reached a final conclusion about the above
results, if gdb confirms my tentative explanation, then that means we
will never be able to use plshade with a statically allocated z array.
Therefore, in this case I am going to make plshade1 permanently into a
C-only function that is not part of our common API and which is mostly
there as an illustrative exercise for C alone that should not be
propagated to our bindings. Currently from find/grep results the only
bindings that mention (pl)shade1 are c++, ada, and possibly octave and
the only examples that mention it are c and ada. So once the
confirmation happens, I plan to drop (pl)shade1 from these remaining
bindings, and for our c and ada examples I plan to replace plshade1
calls with plshade.

>> II. Deprecation of historical C++ API variants [concerning the
distinction between PLINT and bool arguments]?

I am going ahead with this backwards-incompatible change as described previously.

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] This next release cycle should finish in early 2018

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

On 2017-09-15 10:06+0200 Ole Streicher wrote:

> Dear Alan,
>
> On 09.09.2017 20:35, Alan W. Irwin wrote:
>> I did take a quick look at the above URL but saw no obvious issues. So
>> it appears your Debian repackaging efforts have been a complete
>> success for our latest version of PLplot.  Congratulations on that
>> achievement!
>
> Yesterday, the package go accepted, and our autobuilders already
> successfully created binary packages for a number of platforms:
>
> * Intel 32 and 64 bit, both Linux and kfreebsd
> * ARM 64bit

Hi Ole (with CC to Hez because of the OCaml issues):

The Intel 32- and 64-bit platforms are obviously the most important
hardware platforms to get right so that is very encouraging news
indeed.

>
> On some platforms, the build however failed: on PowerPC 64 bit (both big
> and little endian), mips (32 bit, big endian) and s390x (64 bit, big
> endian) the ocaml test "x09ocaml" failes with an segmentation fault:
>
> <<BUILDDIR>>/plplot_test/test_ocaml.sh: line 27:
> 22680 Segmentation fault
> "$ocamldir"/x${index}ocaml -dev $device \
> -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error \
> >| "${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt
>
> On PowerPc 32 bit (an unofficial Debian Platform), I get an error when
> x00ocaml is built:
>
> «BUILDDIR»/examples/ocaml/x00ocaml: error while loading shared
> libraries: R_PPC_REL24 relocation at 0x20690ee8 for symbol
> `gettimeofday' out of range
>
> Could you have a short look, especially for the first failure? It is not
> necessarily a regression, since the ocaml bindings weren't built in the
> Debian package since quite a while.
>
> If it is a ocaml bug, I would write a bug report for the ocaml package
> and then disable the x09ocaml test until it is fixed.

I don't have the OCaml expertise to help you decide whether this is a
PLplot bug or an OCaml bug.  But I suspect the latter because of
the build success of our ocaml binding on other platforms.

@Hez:
Got any ideas about this?

@Ole:
To introduce you, Hez was the primary developer of our ocaml binding and
examples.  However, he has not been contributing to PLplot recently so
if he does not respond to the above question, I suggest you simply turn
off all OCaml-related packages on the hardware platforms where those
are failing to build.

By the way, thanks for the reference to
<https://buildd.debian.org/status/package.php?p=plplot&suite=experimental>
that you sent later.  I haven't had a chance to look at it yet for any
non-OCaml issues, but if you spot any of those, let me know.

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] This next release cycle should finish in early 2018

[Ole S. <deb...@li...>]

Ole Streicher <deb...@li...> writes:
[...]

I forgot to attach the URL with all build logs:

https://buildd.debian.org/status/package.php?p=plplot&suite=experimental

Cheers

Ole

Re: [Plplot-devel] This next release cycle should finish in early 2018

[Ole S. <deb...@li...>]

Dear Alan,

On 09.09.2017 20:35, Alan W. Irwin wrote:
> I did take a quick look at the above URL but saw no obvious issues. So
> it appears your Debian repackaging efforts have been a complete
> success for our latest version of PLplot.  Congratulations on that
> achievement!

Yesterday, the package go accepted, and our autobuilders already
successfully created binary packages for a number of platforms:

 * Intel 32 and 64 bit, both Linux and kfreebsd
 * ARM 64bit

On some platforms, the build however failed: on PowerPC 64 bit (both big
and little endian), mips (32 bit, big endian) and s390x (64 bit, big
endian) the ocaml test "x09ocaml" failes with an segmentation fault:

<<BUILDDIR>>/plplot_test/test_ocaml.sh: line 27:
 22680 Segmentation fault
 "$ocamldir"/x${index}ocaml -dev $device \
 -o "${OUTPUT_DIR}"/x${index}${lang}%n.$dsuffix $options 2> test.error \
 >| "${OUTPUT_DIR}"/x${index}${lang}_${dsuffix}.txt

On PowerPc 32 bit (an unofficial Debian Platform), I get an error when
x00ocaml is built:

«BUILDDIR»/examples/ocaml/x00ocaml: error while loading shared
libraries: R_PPC_REL24 relocation at 0x20690ee8 for symbol
`gettimeofday' out of range

Could you have a short look, especially for the first failure? It is not
necessarily a regression, since the ocaml bindings weren't built in the
Debian package since quite a while.

If it is a ocaml bug, I would write a bug report for the ocaml package
and then disable the x09ocaml test until it is fixed.

For the architectures that are still waiting to be built (ARM 32 bit,
MIPS little endian 32 and 64 bit, Alpha, PA-RISC), I will give an update
when they are ready.

Best regards

Ole

Re: [Plplot-devel] Can statically allocated z arrays be used as the zargument for plshade (and plshades, plcont, plimage, and plvect)?

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

On 2017-09-14 19:59+0100 p.d...@gm... wrote:

> Hi Alan
> I don't have the plplot code here right now, so can't comment on plshade(1). But i can tell you about 2d arrays.
>
> Statically and dynamically allocated 2d arrays are very different in memory so you cannot do
>
> double z[10][10];
> double **z1=(double**)z;
>
> Or anything else that directly casts z to be a double**.
>
> A static 2d array is actually a pointer to a block of memory and the compiler knows that this block of memory represents a 2d array and how to find each element in that memory – presumably one row followed by the next, then the next.
>
> A dynamic 2d array is actually multiple separate vectors as you described. One vector for each row of the array – they do not need to be contiguous in memory. Then there is one vector (the double **) where each element points to the beginning of each row. This is literally an vector of pointers.
>
> So to summarise, a double** dynamic array is a vector of pointers to each row and a double[][] static array is actually a single vector that the compiler knows to interpret as a 2d array. So it should be clear now why casting between the two cannot be done.

Hi Phil:

Thanks for your reply.  To summarize what you have said, it appears it
should be impossible to use a statically allocated z array with
plshade (and presumably also for the plshades, plcont, plimage, and
plvect cases). So I should probably accept that statement and move on
by simply using a dynamically allocated z array with plshade in
examples/c/x15c.c. However, I also hope you are willing discuss this a
bit more so I have a chance to learn more from this situation and also
to amplify exactly why what I am trying to do is causing a segfault.

To give you some more background, my first try yesterday to use plshade
with a statically allocated array used statically allocated z as the argument without any
casting at all.  The resulting gcc compiler warning said the following:

/home/software/plplot/HEAD/plplot.git/examples/c/x15c.c:187:14: warning: passing argument 1 of ‘c_plshade’ from incompatible pointer type
      plshade( z, XPTS, YPTS, NULL, -1., 1., -1., 1.,
               ^
In file included from /home/software/plplot/HEAD/plplot.git/examples/c/plcdemos.h:13:0,
                  from /home/software/plplot/HEAD/plplot.git/examples/c/x15c.c:8:
/home/software/plplot/HEAD/plplot.git/include/plplot.h:1721:1: note: expected ‘PLFLT_MATRIX’ but argument is of type ‘PLFLT (*)[46]’
  c_plshade( PLFLT_MATRIX a, PLINT nx, PLINT ny, PLDEFINED_callback defined,
  ^
/home/software/plplot/HEAD/plplot.git/examples/c/x15c.c: In function ‘plot2’:
/home/software/plplot/HEAD/plplot.git/examples/c/x15c.c:238:18: warning: passing argument 1 of ‘c_plshade’ from incompatible pointer type
          plshade( z, XPTS, YPTS, NULL, -1., 1., -1., 1.,
                   ^
In file included from /home/software/plplot/HEAD/plplot.git/examples/c/plcdemos.h:13:0,
                  from /home/software/plplot/HEAD/plplot.git/examples/c/x15c.c:8:
/home/software/plplot/HEAD/plplot.git/include/plplot.h:1721:1: note: expected ‘PLFLT_MATRIX’ but argument is of type ‘PLFLT (*)[46]’
  c_plshade( PLFLT_MATRIX a, PLINT nx, PLINT ny, PLDEFINED_callback defined,
  ^

So that implies to me that the original type of

PLFLT z[35][46];

is interpreted (when uncast z is an argument to plshade as in this case) as

PLFLT (*z)[46]

i.e., z is interpreted as a pointer to a block of stack memory consisting of
46 PLFLT's (and incrementing that pointer 35-1 times points to 35-1
different blocks of stack memory consisting of 46 PLFLT's).

Have I drawn the correct conclusion here from that warning message?

If so, and if you consider what is created by

plAlloc2dGrid(&z, 35, 46);

(which is a pointer to a heap block of memory consisting of 35
pointers to heap blocks of memory containing 46 PLFLTS), there are
substantial similarities with the above interpretation of PLFLT
(*z)[46] (if you take into account that in C the concepts of pointers
and vectors are in many ways interchangable).  Furthermore, if you
accept all my above interpretations and given that the following cast

(const PLFLT * const *)z

completely suppresses the above compiler warning, can you be more explicit about
the exact explanation of why the result segfaults at run time?  I
suspect the answer has to do with actual differences between pointers
and vectors in C, but I would like to learn about that.

There are two more related topics.

I. Deprecation of plshade1?

I would also appreciate your response to my idea to deprecate (and
eliminate in a couple of more releases) plshade1.  My justification
for that proposed deprecation and eventual removal is there is
currently nothing similar to that variation in API for plshades,
plcont, plimage, and plvect.  So my guess is that plshade1 was
implemented way back when as an illustrative exercise of what a small
amount of extra code would be needed for a C programmer to implement
his own "1" variants of plshades, plcont, plimage, and plvect to allow
him to call those kinds of API with a statically allocated z array.
So assuming that plshade1 was just an illustrative exercise, I don't
think we actually need that exercise as part of our regular API so my
plan is to deprecate it now, and then eliminate it one or two more
releases down the road, but do that elimination with

#if 0
plshade1(...)
{
     ....
}
#endif

to keep this historical exercise without actually ever compiling it again.

But if considering the above information, you still think there is no
convenient way to use a statically allocated z array except through
such a "1" variant of our API for plshade, AND a significant fraction
of our C (and C++?) users would prefer to use that variant rather than
plshade with its dynamically allocated z, maybe you would recommend we
leave plshade1 in undeprecated form and also implement similar C-only
"1" forms for plshades, plcont, plimage, and plvect?

II. Deprecation of historical C++ API variants?

One further question for you to consider is what should I do
concerning all the variations on the C++ bindings API that have been
unofficially deprecated for a long time now?  These ~12 deprecations
were only noted via comments in the bindings/c++/plstrm.h and
bindings/c++/plstrm.cc with slight variations on the following comment

// Deprecated version using PLINT instead of bool

I assume most of our C++ users are not aware that all these "PLINT
instead of bool" variants have been unofficially deprecated this way,
but at the same time they are probably not using these variants much
if at all now because they are not documented in the slightest or used
in our examples. Therefore, I am considering officially deprecating
all of these "PLINT instead of bool" variants so the user would only
be able to access them using the -DPL_DEPRECATED=ON cmake option for
the next release, with the idea we will completely remove these
variants one or two releases after that. Is this proposed backwards
incompatible change to remove cruft in the C++ binding OK with you?

As you can likely tell from my recent commits, I am in a cruft-removal
mood so I hope you are willing to go along with my plans I. and II.
above (unless there is some strong reason you are aware of to hold
back from making one or both of these changes).

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] Can statically allocated z arrays be used as the zargument for plshade (and plshades, plcont, plimage, and plvect)?

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

Hi Alan
I don't have the plplot code here right now, so can't comment on plshade(1). But i can tell you about 2d arrays.

Statically and dynamically allocated 2d arrays are very different in memory so you cannot do

double z[10][10];
double **z1=(double**)z;

Or anything else that directly casts z to be a double**.

A static 2d array is actually a pointer to a block of memory and the compiler knows that this block of memory represents a 2d array and how to find each element in that memory – presumably one row followed by the next, then the next.

A dynamic 2d array is actually multiple separate vectors as you described. One vector for each row of the array – they do not need to be contiguous in memory. Then there is one vector (the double **) where each element points to the beginning of each row. This is literally an vector of pointers.

So to summarise, a double** dynamic array is a vector of pointers to each row and a double[][] static array is actually a single vector that the compiler knows to interpret as a 2d array. So it should be clear now why casting between the two cannot be done.

You could create a double ** from a static array something like

double z[10][10];
double z1 = malloc(10*sizeof(double*));
for( int i=0; i<10; ++i)
{
    z1[i] = &z[i][0];
}

Note that it is often regarded as faster to use static arrays or some method to treat a single block of memory as a 2d array, because adding the appropriate offset (row number * stride + column number) to the beginning of the block then dereferencing once is supposed to be faster than dereferencing twice. I've never tested this though, so i don't know if this is still true with modern compilers and hardware.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 14 September 2017 18:40
To: PLplot development list
Subject: [Plplot-devel] Can statically allocated z arrays be used as the zargument for plshade (and plshades, plcont, plimage, and plvect)?

This general question has come up because plshade1 only differs from
plshade in how the z 2D matrix argument is typed and handled inside
the routine, but there is no similar plshades1, plcont1, plimage1, and
plvect1 equivalents to plshades, plcont, plimage, and plvect.  So for
consistency with the rest, I would like to deprecate plshade1 and
encourage the use of plshade instead.  But part of that deprecation is
explaining to users how to use plshade, but I need help with that.

I could recommend to users to call plshade with a z argument that
follows how the z 2D matrix argument of plcont is typed and defined.
For example, in example 15 we currently use the statically defined z
matrix

PLFLT z[35][45];

z[i][j] = ....;

plshade1( &z[0][0], ...);

And I could replace that logic with logic where z is
defined as in example 9 with plcont, i.e., as a 2D Iliffe vector
(a vector of pointers to vectors of data, see
<https://en.wikipedia.org/wiki/Iliffe_vector>).  So in this
case examples/c/x15c.c would look like the following:

PLFLT **z;

plAlloc2dGrid( &z, 35, 45);

z[i][j] = ....;

plshade( (const PLFLT * const *) z, ...);

plFree2dGrid( z, 35, 45);

Because of the similarity with how the z argument of plcont is
handled, I am positive the above method would work, but I haven't
implemented that yet because I think there _might_ be a simpler
alternative where we use a combination of

PLFLT z[35][45];

z[i][j] = ....;

and a call to

plshade( (const PLFLT * const *) z, ...);

The assumption here is that this statically allocated z is a special case
of an Iliffe vector and should "just work".  But perhaps that assumption
is wrong?

The reason I am uncertain about that assumption, is I have already
tried the above combination of statically allocated z array and that
call to plshade, and it compiles without any warnings which is
encouraging. However, the result segfaults at run time.  So the
question is whether there is something extra I have to do to get the
above combination to work (and similarly for plshades, plcont,
plimage, and plvect) or do users _always_ have to call those routines
with z dynamically allocated with plAlloc2dGrid?

Help with this question from the C experts here would be much appreciated.

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
__________________________

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

[Plplot-devel] Can statically allocated z arrays be used as the z argument for plshade (and plshades, plcont, plimage, and plvect)?

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

This general question has come up because plshade1 only differs from
plshade in how the z 2D matrix argument is typed and handled inside
the routine, but there is no similar plshades1, plcont1, plimage1, and
plvect1 equivalents to plshades, plcont, plimage, and plvect.  So for
consistency with the rest, I would like to deprecate plshade1 and
encourage the use of plshade instead.  But part of that deprecation is
explaining to users how to use plshade, but I need help with that.

I could recommend to users to call plshade with a z argument that
follows how the z 2D matrix argument of plcont is typed and defined.
For example, in example 15 we currently use the statically defined z
matrix

PLFLT z[35][45];

z[i][j] = ....;

plshade1( &z[0][0], ...);

And I could replace that logic with logic where z is
defined as in example 9 with plcont, i.e., as a 2D Iliffe vector
(a vector of pointers to vectors of data, see
<https://en.wikipedia.org/wiki/Iliffe_vector>).  So in this
case examples/c/x15c.c would look like the following:

PLFLT **z;

plAlloc2dGrid( &z, 35, 45);

z[i][j] = ....;

plshade( (const PLFLT * const *) z, ...);

plFree2dGrid( z, 35, 45);

Because of the similarity with how the z argument of plcont is
handled, I am positive the above method would work, but I haven't
implemented that yet because I think there _might_ be a simpler
alternative where we use a combination of

PLFLT z[35][45];

z[i][j] = ....;

and a call to

plshade( (const PLFLT * const *) z, ...);

The assumption here is that this statically allocated z is a special case
of an Iliffe vector and should "just work".  But perhaps that assumption
is wrong?

The reason I am uncertain about that assumption, is I have already
tried the above combination of statically allocated z array and that
call to plshade, and it compiles without any warnings which is
encouraging. However, the result segfaults at run time.  So the
question is whether there is something extra I have to do to get the
above combination to work (and similarly for plshades, plcont,
plimage, and plvect) or do users _always_ have to call those routines
with z dynamically allocated with plAlloc2dGrid?

Help with this question from the C experts here would be much appreciated.

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] This next release cycle should finish in early 2018

[Ole S. <deb...@li...>]

"Alan W. Irwin" <ir...@be...> writes:
> I did take a quick look at the above URL but saw no obvious issues. So
> it appears your Debian repackaging efforts have been a complete
> success for our latest version of PLplot.  Congratulations on that
> achievement!

Hopefully. Maybe our ftp-masters find some issues (it will take a while
....), but I think they can be resolved quickly. After they give the OK,
we will see how it compiles on all our platforms; I will come back if
there are problems.

> Once your CI tests are implemented, will those test the master branch
> of PLplot against changes on that branch or will those test fixed
> PLplot-5.13.0 against any further packaging changes that you do and
> also general Debian Sid changes?

They will test the precompiled Debian package (in sid) against any
changes of the environment. So, if any of the bindings (f.e.) fails due
to some incompatible changes, we can see this immediately.

Best

Ole

Re: [Plplot-devel] This next release cycle should finish in early 2018

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

On 2017-09-09 14:21+0200 Ole Streicher wrote:

> Hi Alan,
>
>
> On 29.08.2017 19:48, Alan W. Irwin wrote:
>> To summarize, I think you should do multiple builds for python 2.7,
>> 3.5, and 3.6 (with relatively small extra build cost), but I agree you
>> should stick strictly to Qt5 for our Qt-related components because Qt4
>> is about to be removed from Debian.
>
> in the last days, I managed to create the Debian package for the new
> plplot version. Since there are changes in the Debian package structure
> (new and renamed packages), it has to be approved by our ftp-masters,
> and therefore I uploaded a pre-release to our "experimental" branch
> (also to prepare the required recompilation of the dependent packages).
> As long as the new package is not accepted, you will find the metadata here:
>
> https://ftp-master.debian.org/new/plplot_5.13.0%2Bdfsg-1~exp1.html
>
> For the Python stuff, I finally used a patch that builds for all
> available Python versions. The patch is Debian specific and
> straightforward, and I intend to maintain it together with the Debian
> package. For curiosity, I however attach it.
>
> The current upload is not the final version; I intend to still add f.e.
> Continuous Integration tests. So if you feel that we should still change
> things, we can.

Hi Ole:

I did take a quick look at the above URL but saw no obvious issues. 
So it appears your Debian repackaging efforts have been a complete
success for our latest version of PLplot.  Congratulations on that
achievement!

Once your CI tests are implemented, will those test the master branch
of PLplot against changes on that branch or will those test fixed
PLplot-5.13.0 against any further packaging changes that you do and
also general Debian Sid changes?

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] This next release cycle should finish in early 2018

[Ole S. <deb...@li...>]

Hi Alan,


On 29.08.2017 19:48, Alan W. Irwin wrote:
> To summarize, I think you should do multiple builds for python 2.7,
> 3.5, and 3.6 (with relatively small extra build cost), but I agree you
> should stick strictly to Qt5 for our Qt-related components because Qt4
> is about to be removed from Debian.

in the last days, I managed to create the Debian package for the new
plplot version. Since there are changes in the Debian package structure
(new and renamed packages), it has to be approved by our ftp-masters,
and therefore I uploaded a pre-release to our "experimental" branch
(also to prepare the required recompilation of the dependent packages).
As long as the new package is not accepted, you will find the metadata here:

https://ftp-master.debian.org/new/plplot_5.13.0%2Bdfsg-1~exp1.html

For the Python stuff, I finally used a patch that builds for all
available Python versions. The patch is Debian specific and
straightforward, and I intend to maintain it together with the Debian
package. For curiosity, I however attach it.

The current upload is not the final version; I intend to still add f.e.
Continuous Integration tests. So if you feel that we should still change
things, we can.

Best regards,

and already thank you for your help so far!

Ole

Re: [Plplot-devel] Missing pyqtconfig module issue should now be fixed

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

Hi Alan,



I can confirm that it works:



D:\plplot-svn\build-mingw-alt>cmake ..\plplot-git -G "MSYS Makefiles" -DBUILD_TEST=ON -DCMAKE_CXX_FLAGS="-fabi-version=8"



...

-- WARNING: PLPLOT_USE_QT5 is OFF so setting ENABLE_pyqt5 to OFF

-- pyqt: SIP_EXECUTABLE = C:/msys64/mingw64/bin/sip.exe

-- SIP_VERSION = 4.18

-- PYQT_SIP_DIR = C:/msys64/mingw64/share/sip/Py2-Qt4

-- PyQt4: PYQT_SIP_FLAGS = -x;VendorID;-t;WS_WIN;-t;Qt_4_8_7;-x;Py_v3



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, September 06, 2017 10:46 AM
>
> Thanks, Arjen.  I have now used the above information to update the NAMES and
> HINTS used to discover PYQT_SIP_DIR.
>
> Could you try the first stages again of the comprehensive test, but this time without
> specifying PYQT_SIP_DIR?  Our build system should now (commit e3e0f15)
> automatically be able to determine PYQT_SIP_DIR on MinGW-w64/MSYS2 without
> you needing to specify it, and I hope the above test will confirm that.
>


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.