plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] FW: Exponential labels - custom position

[Allen, A. J <a....@im...>]

Alan,

just to confirm, QSAS does not use your colour bar code, nor does it
use label_box_custom(). Alban wrote his own colour bar using plbox().

This means any change we made to label_box_custom is historical and nugatory, and only the
changes to plbox() are relevant ( the else{  } ).

In fact we do not include pllegend.c in our version of plplot at all, which is why I did
not see label_box_custom() being called.

All the best
Tony

Re: [Plplot-devel] FW: Exponential labels - custom position

[Allen, A. J <a....@im...>]

Hi Alan,

firstly, my apologies for leaving in some debug output.

The changes appear as I would have expected with just
the else {  } component and a couple of plmtex() calls.

These were originally implemented by Alban Rochel in our copy
so I don’t know the full history - he just left us instructions
on how to tweek plplot for QSAS.

I can’t actually see label_box_custom() being called anywhere in the latest version,
(either by you or us) just in the earlier version we used previously.
I’ll have to look at how we label colour bars, but I’m pretty certain we draw our own anyway!

I’m mostly retired now, I only work 1 day a week, but I’ll see if I can create a test
rig that does not involve running QSAS but uses our calls.

Regards,
Tony

> 
> Hi Steve and Tony:
> 
> @Steve:
> Thanks for passing along Tony's fix for a bug in PLplot that he noticed.
> 
> @Tony:
> 
> Most of this is addressed to you.  But before you respond please take
> a few minutes to subscribe to plplot-devel so everybody subscribed to
> that list (not just those you directly e-mail) and those looking at
> the list archive later can see what you say.  (See
> <https://sourceforge.net/projects/plplot/lists/plplot-devel> for the
> simple subscription directions and remember to always use your
> subscription address as the return address for your posts to this list
> or otherwise your message will be lost to everybody other than the
> list manager [who happens to be me].)
> 
> I took your version of plbox.c (as forwarded by Steve), changed from
> Windows to Unix line endings (git assumes native line endings, e.g.,
> Windows on Windows and Unix on Linux), commented out some debugging
> print statements, changed one comment reference from "qsas" to "QSAS"
> to be consistent with the same comment in another routine, and styled
> that result.  So after those further changes here are the differences
> with the PLplot HEAD version (from the "git diff --ignore-all-space
> --unified=10" command with that last-parameter used to give lots of
> context).
> 
> --------------------------------------
> diff --git a/src/plbox.c b/src/plbox.c
> index b2b25840f..01c5aee7b 100644
> --- a/src/plbox.c
> +++ b/src/plbox.c
> @@ -1470,21 +1470,21 @@ label_box( PLCHAR_VECTOR xopt, PLFLT xtick1, PLCHAR_VECTOR yopt, PLFLT ytick1 )
>     ldy = plP_stsearch( yopt, 'd' );
>     lfy = plP_stsearch( yopt, 'f' );
>     liy = plP_stsearch( yopt, 'i' );
>     lly = plP_stsearch( yopt, 'l' );
>     lmy = plP_stsearch( yopt, 'm' );
>     lny = plP_stsearch( yopt, 'n' );
>     lty = plP_stsearch( yopt, 't' );
>     lvy = plP_stsearch( yopt, 'v' );
>     loy = plP_stsearch( yopt, 'o' );
>     lxy = plP_stsearch( yopt, 'x' );
> -
> +    //printf( "=== yopt %d %d %d  \n", lny, lty, lvy );
>     plP_xgvpw( &vpwxmin, &vpwxmax, &vpwymin, &vpwymax );
> // vpwxmi always numerically less than vpwxma, and
> // similarly for vpwymi
>     vpwxmi = ( vpwxmax > vpwxmin ) ? vpwxmin : vpwxmax;
>     vpwxma = ( vpwxmax > vpwxmin ) ? vpwxmax : vpwxmin;
>     vpwymi = ( vpwymax > vpwymin ) ? vpwymin : vpwymax;
>     vpwyma = ( vpwymax > vpwymin ) ? vpwymax : vpwymin;
> 
>     // Write label(s) for horizontal axes.
>     if ( ( lmx || lnx ) && ( ltx || lxx ) )
> @@ -1819,21 +1819,24 @@ label_box( PLCHAR_VECTOR xopt, PLFLT xtick1, PLCHAR_VECTOR yopt, PLFLT ytick1 )
>         // Write separate exponential label if mode = 1.
> 
>         if ( !lly && !ldy && !loy && ymode )
>         {
>             snprintf( string, STRING_LEN, "(x10%su%d%sd)", esc_string, (int) yscale, esc_string );
>             if ( custom_exponent_placement )
>             {
>                 height = ( (PLLabelDefaults *) plsc->label_data )->exp_label_disp;
>                 pos    = ( (PLLabelDefaults *) plsc->label_data )->exp_label_pos;
>                 just   = ( (PLLabelDefaults *) plsc->label_data )->exp_label_just;
> +                plmtex( "t", height, pos, just, string ); // added for QSAS
>             }
> +            else
> +            {
>                 if ( lvy )
>                 {
>                     offset = 0.1;  // more space to clear labels in "v" mode
>                 }
>                 else
>                 {
>                     offset = 0.02;
>                 }
>                 // Left axis exponent
>                 if ( lny )
> @@ -1907,20 +1910,21 @@ label_box( PLCHAR_VECTOR xopt, PLFLT xtick1, PLCHAR_VECTOR yopt, PLFLT ytick1 )
>                         }
>                         else
>                         {
>                             plmtex( "r", height, pos, just, string );
>                         }
>                     }
>                 }
>             }
>         }
>     }
> +}
> 
> //--------------------------------------------------------------------------
> // void label_box_custom()
> //
> // Writes numeric labels on side(s) of box in custom locations
> //--------------------------------------------------------------------------
> 
> void
> label_box_custom( PLCHAR_VECTOR xopt, PLINT n_xticks, PLFLT_VECTOR xticks, PLCHAR_VECTOR yopt, PLINT n_yticks, PLFLT_VECTOR yticks )
> {
> @@ -1931,21 +1935,21 @@ label_box_custom( PLCHAR_VECTOR xopt, PLINT n_xticks, PLFLT_VECTOR xticks, PLCHA
>     PLFLT         vpwxmin, vpwxmax, vpwymin, vpwymax;
>     PLFLT         tn, offset;
>     PLCHAR_VECTOR timefmt;
>     PLINT         i;
>     PLINT         xdigmax, xdigits, xdigmax_old, xdigits_old;
>     PLINT         ydigmax, ydigits, ydigmax_old, ydigits_old;
>     PLINT         lxmin, lxmax, lymin, lymax;
>     PLINT         pxmin, pxmax, pymin, pymax;
>     PLFLT         default_mm, char_height_mm, height_mm;
>     PLFLT         string_length_mm = 0.0, pos_mm = 0.0;
> -
> +    //printf( "=== custom\n" );
>     // Assume label data is for placement of exponents if no custom
>     // label function is provided.
>     PLBOOL custom_exponent_placement = !plsc->label_func && plsc->label_data;
> 
>     // pos, height, and just are unnecessarily set to quiet
>     // -O3 -Wuninitialized warnings that are obvious false alarms from
>     // the clarity of the code associated with the true or false
>     // result for custom_exponent_placement.
>     PLFLT         pos        = 0.0, height = 0.0, just = 0.0;
>     PLCHAR_VECTOR esc_string = plgesc_string();
> @@ -2384,20 +2388,21 @@ label_box_custom( PLCHAR_VECTOR xopt, PLINT n_xticks, PLFLT_VECTOR xticks, PLCHA
>         // Write separate exponential label if mode = 1.
> 
>         if ( !lly && !ldy && !loy && ymode )
>         {
>             snprintf( string, STRING_LEN, "(x10%su%d%sd)", esc_string, (int) yscale, esc_string );
>             if ( custom_exponent_placement )
>             {
>                 height = ( (PLLabelDefaults *) plsc->label_data )->exp_label_disp;
>                 pos    = ( (PLLabelDefaults *) plsc->label_data )->exp_label_pos;
>                 just   = ( (PLLabelDefaults *) plsc->label_data )->exp_label_just;
> +                plmtex( "t", height, pos, just, string ); //added for QSAS
>             }
>             if ( lvy )
>             {
>                 offset = 0.1;  // more space to clear labels in "v" mode
>             }
>             else
>             {
>                 offset = 0.02;
>             }
>             // Left axis exponent.
> --------------------------------------
> 
> For the record, label_box_custom is a private function that is only
> called by the static function draw_box in src/pllegend.c, which in
> turn is only called by c_plcolorbar within that source file.  So
> label_box_custom is a misnomer, and I plan (after the current release
> is done) to address that issue by changing that name to
> label_box_colorbar.  But from now on in this e-mail I will refer to
> that function with its present name of label_box_custom.
> 
> (@ Everybody: Note that Tony's fix is limited to changes when custom_exponent_placement
> is true, i.e., when there is no custom label function but (custom?) label data
> are still provided to change the placement of the exponential label.)
> 
> @Tony:
> 
> We really do need a simple test case for both the revised label_box and label_box_custom
> functions.  Could you provide that?  I suggest that simple example doesn't need any
> data to plot, but it does need to contain a labelled box and a simple colorbar
> (see example 16 for an example of a simple colorbar) to exercise both label_box and
> label_box_custom.  And, of course, both the box and colorbar should have exponential
> labels and appropriate label data should be provided in each case to exercise
> the cases for both functions where custom_exponent_placement is true.
> 
> It has been a long time since I looked at plbox.c, but my impression
> now is label_box_custom is quite similar to label_box code so I am
> pretty sure label_box_custom badly needs documentation about exactly
> how and why it is changed from label_box for the special needs of
> plcolorbar.  So providing such documentation is on my post-release
> agenda, but in the absence of such documentation I am frankly
> currently ignorant of the designed differences between label_box and
> label_box_custom.  However, with that caveat I don't understand why
> your fix is so different in the two separate functions.
> 
> For example, prior to your fix label_box and label_box_custom had very
> similar custom_exponent_placement logic, but now they are quite different
> (e.g., the above added "else" in label_box that skips a huge amount
> of code is not present in label_box_custom).  Did you really mean
> to have such quite different logic in those two cases?  Even if
> the present fix works, it would be best for the logic in those two
> functions to be implemented as similarly as possible.
> 
> Assuming your reply to my questions includes another revised version
> of plbox.c, I don't care about the line endings and whitespace styling
> changes I made since those are easy to do again.  However, please do
> incorporate my further changes (commenting out of the print functions
> and the qsas ==> QSAS change) in your revised code.
> 
> N.B. I am happy to take a quick break (as now) from getting out the
> 5.14.0 release to discuss these changes with you, but we are in deep
> freeze now (i.e., it is obviously much too late in the present release
> cycle to get these or virtually any other code change into that
> release).  But once you provide a good simple test example to make
> sure all is well with these changes, it would be ideal to get these
> changes accepted for PLplot early in the release cycle for 5.15.0.
> 
> Best wishes,
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

Hi Alan,

"Alan W. Irwin" <Ala...@gm...> writes:
> On 2018-11-22 20:54+0100 Ole Streicher wrote:
>> "Alan W. Irwin" <Ala...@gm...> writes:
>>> On 2018-11-13 18:23+0100 Ole Streicher wrote:
>>> Upstream PLplot installs all examples configured in the core build in
>>> one place which contains a self-contained CMake-based build and test
>>> system for those examples.  Therefore, I have to agree splitting up
>>> those installed examples in various locations is not a good idea
>>> since that means you have to implement a build system for each
>>> component of the examples!
>>>
>>> Therefore, I suggest instead you create a plplot-examples
>>> package that contains only text files, which are *all* the example files
>>> that upstream currently installs in
>>> $PREFIX/share/plplot$VERSION/examples, but it sounds like instead
>>> for debian if you do this suggested reorganization
>>> you should install them in /usr/share/doc/plplot-examples/examples.
>>
>> OK, so I now moved all examples to the "examples" subdir of the
>> plplot-doc package, and now I am closer to a working test ;-)
>>
>> Next problem is that the Debian installation script renames the shared
>> libraries that are installed for the Python package:
>> On Python 2.7,
>> - _Pltk_init.so becomes _Pltk_init.x86_64-linux-gnu.so resp.
>> - _plplotc.so becomes _plplotc.x86_64-linux-gnu.so
>> On Python 3.6
>> - /usr/lib/python3.6/dist-packages/_Pltk_init.so becomes
>>   /usr/lib/python3/dist-packages/_Pltk_init.cpython-36m-x86_64-linux-gnu.so
>> - _plplotc.so similar
>> And Python 3.7 similar.
>
> Hi Ole:
>
> I am glad to hear you are making significant progress.
>
> I looked deeper at the names of the python *.so files for Debian
> Buster for one arbitrary python package (curses).
>
> irwin@merlin> find /usr/lib/python3.7/ -type f |grep 'curses' |grep -E
> '(.py|.so)$'
> /usr/lib/python3.7/curses/panel.py
> /usr/lib/python3.7/curses/__init__.py
> /usr/lib/python3.7/curses/has_key.py
> /usr/lib/python3.7/curses/textpad.py
> /usr/lib/python3.7/curses/ascii.py
> /usr/lib/python3.7/lib-dynload/_curses.cpython-37m-x86_64-linux-gnu.so
> /usr/lib/python3.7/lib-dynload/_curses_panel.cpython-37m-x86_64-linux-gnu.so
>
> And that relocation (to lib-dynload) and extra
> ".cpython-37m-x86_64-linux-gnu" description in the *.so file names
> made no difference to the *.py files.  For example, panel.py had the
> following import statement
>
> from _curses_panel import *
>
> with no mention of the location or extra name decoration of the
> corresponding *.so file.
>
> So from the results of that quick check, I don't understand why the
> installed PLplot example
> tests are complaining
> about the renaming (and even relocating to a different directory) of
> PLplot's installed
> python *.so files).  Which leads to the following response to your
> question....

It is the cmake command. When I start with an empty dir, and then do

$ cmake /usr/share/doc/plplot-doc/examples/

I get the following output:

--------------------------------8<----------------------------------------
-- The C compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMake version = 3.12.3
-- CMAKE_SYSTEM_NAME = Linux
-- CMAKE_PLATFORM_INFO_DIR = /home/ole/Projects/2011/debian/plplot/x/CMakeFiles/3.12.3
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29") 
-- Looking for pkg-config - found
-- cxx_compiler_library_pathname_list = 
-- A test cmake run with language = Ada enabled failed.
-- Specify -DENABLE_compiler_diagnostics=ON to see full CMake diagnostics concerning this failure.
-- WARNING: no working Ada compiler so disabling ada examples.
-- The CXX compiler identification is GNU 8.2.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The Fortran compiler identification is GNU 8.2.0
-- Check for working Fortran compiler: /usr/bin/gfortran
-- Check for working Fortran compiler: /usr/bin/gfortran  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
-- Found JNI: /usr/lib/jvm/default-java/lib/libjawt.so  
-- Could NOT find Qt5Svg (missing: Qt5Svg_DIR)
CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:5 (find_package):
  Found package configuration file:

    /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake

  but it set Qt5_FOUND to FALSE so package "Qt5" is considered to be NOT
  FOUND.  Reason given by package:

  Failed to find Qt5 component "Svg" config file at
  "/usr/lib/x86_64-linux-gnu/cmake/Qt5Svg/Qt5SvgConfig.cmake"

  

Call Stack (most recent call first):
  CMakeLists.txt:471 (find_package)


-- CORE_Qt5_FOUND = ON
-- CORE_Qt5_VERSION_MAJOR = 5
-- CORE_Qt5_VERSION_MINOR = 11
-- CORE_Qt5_VERSION_PATCH = 2
-- Qt5_FOUND = 0
-- Qt5_VERSION_MAJOR = 5
-- Qt5_VERSION_MINOR = 11
-- Qt5_VERSION_PATCH = 2
-- WARNING: Qt5 core build-tree and install-tree inconsistency
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake:279 (message):
  The imported target "_Pltk_init2.7" references the file

     "/usr/lib/python2.7/dist-packages/_Pltk_init.so"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake:20 (include)
  CMakeLists.txt:471 (find_package)


-- Configuring incomplete, errors occurred!

--------------------------------8<----------------------------------------

A Makefile is not produced then. The produced logfile is attached.

Any idea?

Best

Ole

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-11-22 20:54+0100 Ole Streicher wrote:

> Hi Alan,
>
> back from the US (ADASS), I found an hour to look further into the CI
> tests problem:
>
> "Alan W. Irwin" <Ala...@gm...> writes:
>> On 2018-11-13 18:23+0100 Ole Streicher wrote:
>> Upstream PLplot installs all examples configured in the core build in
>> one place which contains a self-contained CMake-based build and test
>> system for those examples.  Therefore, I have to agree splitting up
>> those installed examples in various locations is not a good idea
>> since that means you have to implement a build system for each
>> component of the examples!
>>
>> Therefore, I suggest instead you create a plplot-examples
>> package that contains only text files, which are *all* the example files
>> that upstream currently installs in
>> $PREFIX/share/plplot$VERSION/examples, but it sounds like instead
>> for debian if you do this suggested reorganization
>> you should install them in /usr/share/doc/plplot-examples/examples.
>
> OK, so I now moved all examples to the "examples" subdir of the
> plplot-doc package, and now I am closer to a working test ;-)
>
> Next problem is that the Debian installation script renames the shared
> libraries that are installed for the Python package:
> On Python 2.7,
> - _Pltk_init.so becomes _Pltk_init.x86_64-linux-gnu.so resp.
> - _plplotc.so becomes _plplotc.x86_64-linux-gnu.so
> On Python 3.6
> - /usr/lib/python3.6/dist-packages/_Pltk_init.so becomes
>   /usr/lib/python3/dist-packages/_Pltk_init.cpython-36m-x86_64-linux-gnu.so
> - _plplotc.so similar
> And Python 3.7 similar.

Hi Ole:

I am glad to hear you are making significant progress.

I looked deeper at the names of the python *.so files for Debian Buster for one arbitrary python package (curses).

irwin@merlin> find /usr/lib/python3.7/ -type f |grep 'curses' |grep -E '(.py|.so)$'
/usr/lib/python3.7/curses/panel.py
/usr/lib/python3.7/curses/__init__.py
/usr/lib/python3.7/curses/has_key.py
/usr/lib/python3.7/curses/textpad.py
/usr/lib/python3.7/curses/ascii.py
/usr/lib/python3.7/lib-dynload/_curses.cpython-37m-x86_64-linux-gnu.so
/usr/lib/python3.7/lib-dynload/_curses_panel.cpython-37m-x86_64-linux-gnu.so

And that relocation (to lib-dynload) and extra
".cpython-37m-x86_64-linux-gnu" description in the *.so file names
made no difference to the *.py files.  For example, panel.py had the
following import statement

from _curses_panel import *

with no mention of the location or extra name decoration of the corresponding *.so file.

So from the results of that quick check, I don't understand why the installed PLplot example
tests are complaining
about the renaming (and even relocating to a different directory) of PLplot's installed
python *.so files).  Which leads to the following response to your question....

> Is there a way to switch off the consistency check for Python?

Please clear up exactly what you mean here by giving me the
VERBOSE=1 output of the test target that is failing.  For example,
if you are building the test_noninteractive target, you could
extract that necessary output this way.

make VERBOSE=1 test_noninteractive >& test_noninteractive.out

Given that output file, I could probably figure out a quick patch for you to
get by whatever the error is because (as I found out above for curses)
renaming and relocating *.so should not matter.

My guess is that likely the PLplot build system is being much too
specific about a name and/or location in the installed python files
for PLplot.  But assuming that is the case, I can find out where that
is done a lot easier once I have your VERBOSE=1 test target build
output in hand.

> BTW, I would still keep the dependencies of the -doc package as they
> are, and only for the tests install everything.

Well, if you haven't done this already, I would suggest putting all
the names of the relevant binary packages into the Suggests: list for
the -doc package.  (I assume that will be the final form you want once
I get the upstream code properly factored since once that is done
those binary packages will add substantially to the functionality of
the -doc package which I believe is what Suggests: is for.)

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

Re: [Plplot-devel] FW: Exponential labels - custom position

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

On 2018-11-20 11:15-0700 Steve Schwartz wrote:

> Hi Plplot
>
>
>
> We have been pretty quiet, happily employing plplot in our QSAS software. We recently decided to update our plplot version, which we don’t do regurarly since it requires a few tweaks to work with/embed in our system.
>
>
>
> We (meaning my colleague and software person Tony Allen – in cc) have discovered a bug in the handling of exponential label placement. While we haven’t prepared a minimal example, the exchange below describes the symptoms. The attached plbox.c includes Tony’s correction.

Hi Steve and Tony:

@Steve:
Thanks for passing along Tony's fix for a bug in PLplot that he noticed.

@Tony:

Most of this is addressed to you.  But before you respond please take
a few minutes to subscribe to plplot-devel so everybody subscribed to
that list (not just those you directly e-mail) and those looking at
the list archive later can see what you say.  (See
<https://sourceforge.net/projects/plplot/lists/plplot-devel> for the
simple subscription directions and remember to always use your
subscription address as the return address for your posts to this list
or otherwise your message will be lost to everybody other than the
list manager [who happens to be me].)

I took your version of plbox.c (as forwarded by Steve), changed from
Windows to Unix line endings (git assumes native line endings, e.g.,
Windows on Windows and Unix on Linux), commented out some debugging
print statements, changed one comment reference from "qsas" to "QSAS"
to be consistent with the same comment in another routine, and styled
that result.  So after those further changes here are the differences
with the PLplot HEAD version (from the "git diff --ignore-all-space
--unified=10" command with that last-parameter used to give lots of
context).

--------------------------------------
diff --git a/src/plbox.c b/src/plbox.c
index b2b25840f..01c5aee7b 100644
--- a/src/plbox.c
+++ b/src/plbox.c
@@ -1470,21 +1470,21 @@ label_box( PLCHAR_VECTOR xopt, PLFLT xtick1, PLCHAR_VECTOR yopt, PLFLT ytick1 )
      ldy = plP_stsearch( yopt, 'd' );
      lfy = plP_stsearch( yopt, 'f' );
      liy = plP_stsearch( yopt, 'i' );
      lly = plP_stsearch( yopt, 'l' );
      lmy = plP_stsearch( yopt, 'm' );
      lny = plP_stsearch( yopt, 'n' );
      lty = plP_stsearch( yopt, 't' );
      lvy = plP_stsearch( yopt, 'v' );
      loy = plP_stsearch( yopt, 'o' );
      lxy = plP_stsearch( yopt, 'x' );
-
+    //printf( "=== yopt %d %d %d  \n", lny, lty, lvy );
      plP_xgvpw( &vpwxmin, &vpwxmax, &vpwymin, &vpwymax );
  // vpwxmi always numerically less than vpwxma, and
  // similarly for vpwymi
      vpwxmi = ( vpwxmax > vpwxmin ) ? vpwxmin : vpwxmax;
      vpwxma = ( vpwxmax > vpwxmin ) ? vpwxmax : vpwxmin;
      vpwymi = ( vpwymax > vpwymin ) ? vpwymin : vpwymax;
      vpwyma = ( vpwymax > vpwymin ) ? vpwymax : vpwymin;

      // Write label(s) for horizontal axes.
      if ( ( lmx || lnx ) && ( ltx || lxx ) )
@@ -1819,21 +1819,24 @@ label_box( PLCHAR_VECTOR xopt, PLFLT xtick1, PLCHAR_VECTOR yopt, PLFLT ytick1 )
          // Write separate exponential label if mode = 1.

          if ( !lly && !ldy && !loy && ymode )
          {
              snprintf( string, STRING_LEN, "(x10%su%d%sd)", esc_string, (int) yscale, esc_string );
              if ( custom_exponent_placement )
              {
                  height = ( (PLLabelDefaults *) plsc->label_data )->exp_label_disp;
                  pos    = ( (PLLabelDefaults *) plsc->label_data )->exp_label_pos;
                  just   = ( (PLLabelDefaults *) plsc->label_data )->exp_label_just;
+                plmtex( "t", height, pos, just, string ); // added for QSAS
              }
+            else
+            {
                  if ( lvy )
                  {
                      offset = 0.1;  // more space to clear labels in "v" mode
                  }
                  else
                  {
                      offset = 0.02;
                  }
                  // Left axis exponent
                  if ( lny )
@@ -1907,20 +1910,21 @@ label_box( PLCHAR_VECTOR xopt, PLFLT xtick1, PLCHAR_VECTOR yopt, PLFLT ytick1 )
                          }
                          else
                          {
                              plmtex( "r", height, pos, just, string );
                          }
                      }
                  }
              }
          }
      }
+}

  //--------------------------------------------------------------------------
  // void label_box_custom()
  //
  // Writes numeric labels on side(s) of box in custom locations
  //--------------------------------------------------------------------------

  void
  label_box_custom( PLCHAR_VECTOR xopt, PLINT n_xticks, PLFLT_VECTOR xticks, PLCHAR_VECTOR yopt, PLINT n_yticks, PLFLT_VECTOR yticks )
  {
@@ -1931,21 +1935,21 @@ label_box_custom( PLCHAR_VECTOR xopt, PLINT n_xticks, PLFLT_VECTOR xticks, PLCHA
      PLFLT         vpwxmin, vpwxmax, vpwymin, vpwymax;
      PLFLT         tn, offset;
      PLCHAR_VECTOR timefmt;
      PLINT         i;
      PLINT         xdigmax, xdigits, xdigmax_old, xdigits_old;
      PLINT         ydigmax, ydigits, ydigmax_old, ydigits_old;
      PLINT         lxmin, lxmax, lymin, lymax;
      PLINT         pxmin, pxmax, pymin, pymax;
      PLFLT         default_mm, char_height_mm, height_mm;
      PLFLT         string_length_mm = 0.0, pos_mm = 0.0;
-
+    //printf( "=== custom\n" );
      // Assume label data is for placement of exponents if no custom
      // label function is provided.
      PLBOOL custom_exponent_placement = !plsc->label_func && plsc->label_data;

      // pos, height, and just are unnecessarily set to quiet
      // -O3 -Wuninitialized warnings that are obvious false alarms from
      // the clarity of the code associated with the true or false
      // result for custom_exponent_placement.
      PLFLT         pos        = 0.0, height = 0.0, just = 0.0;
      PLCHAR_VECTOR esc_string = plgesc_string();
@@ -2384,20 +2388,21 @@ label_box_custom( PLCHAR_VECTOR xopt, PLINT n_xticks, PLFLT_VECTOR xticks, PLCHA
          // Write separate exponential label if mode = 1.

          if ( !lly && !ldy && !loy && ymode )
          {
              snprintf( string, STRING_LEN, "(x10%su%d%sd)", esc_string, (int) yscale, esc_string );
              if ( custom_exponent_placement )
              {
                  height = ( (PLLabelDefaults *) plsc->label_data )->exp_label_disp;
                  pos    = ( (PLLabelDefaults *) plsc->label_data )->exp_label_pos;
                  just   = ( (PLLabelDefaults *) plsc->label_data )->exp_label_just;
+                plmtex( "t", height, pos, just, string ); //added for QSAS
              }
              if ( lvy )
              {
                  offset = 0.1;  // more space to clear labels in "v" mode
              }
              else
              {
                  offset = 0.02;
              }
              // Left axis exponent.
--------------------------------------

For the record, label_box_custom is a private function that is only
called by the static function draw_box in src/pllegend.c, which in
turn is only called by c_plcolorbar within that source file.  So
label_box_custom is a misnomer, and I plan (after the current release
is done) to address that issue by changing that name to
label_box_colorbar.  But from now on in this e-mail I will refer to
that function with its present name of label_box_custom.

(@ Everybody: Note that Tony's fix is limited to changes when custom_exponent_placement
is true, i.e., when there is no custom label function but (custom?) label data
are still provided to change the placement of the exponential label.)

@Tony:

We really do need a simple test case for both the revised label_box and label_box_custom
functions.  Could you provide that?  I suggest that simple example doesn't need any
data to plot, but it does need to contain a labelled box and a simple colorbar
(see example 16 for an example of a simple colorbar) to exercise both label_box and
label_box_custom.  And, of course, both the box and colorbar should have exponential
labels and appropriate label data should be provided in each case to exercise
the cases for both functions where custom_exponent_placement is true.

It has been a long time since I looked at plbox.c, but my impression
now is label_box_custom is quite similar to label_box code so I am
pretty sure label_box_custom badly needs documentation about exactly
how and why it is changed from label_box for the special needs of
plcolorbar.  So providing such documentation is on my post-release
agenda, but in the absence of such documentation I am frankly
currently ignorant of the designed differences between label_box and
label_box_custom.  However, with that caveat I don't understand why
your fix is so different in the two separate functions.

For example, prior to your fix label_box and label_box_custom had very
similar custom_exponent_placement logic, but now they are quite different
(e.g., the above added "else" in label_box that skips a huge amount
of code is not present in label_box_custom).  Did you really mean
to have such quite different logic in those two cases?  Even if
the present fix works, it would be best for the logic in those two
functions to be implemented as similarly as possible.

Assuming your reply to my questions includes another revised version
of plbox.c, I don't care about the line endings and whitespace styling
changes I made since those are easy to do again.  However, please do
incorporate my further changes (commenting out of the print functions
and the qsas ==> QSAS change) in your revised code.

N.B. I am happy to take a quick break (as now) from getting out the
5.14.0 release to discuss these changes with you, but we are in deep
freeze now (i.e., it is obviously much too late in the present release
cycle to get these or virtually any other code change into that
release).  But once you provide a good simple test example to make
sure all is well with these changes, it would be ideal to get these
changes accepted for PLplot early in the release cycle for 5.15.0.

Best wishes,

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

Hi Alan,

back from the US (ADASS), I found an hour to look further into the CI
tests problem:

"Alan W. Irwin" <Ala...@gm...> writes:
> On 2018-11-13 18:23+0100 Ole Streicher wrote:
> Upstream PLplot installs all examples configured in the core build in
> one place which contains a self-contained CMake-based build and test
> system for those examples.  Therefore, I have to agree splitting up
> those installed examples in various locations is not a good idea
> since that means you have to implement a build system for each
> component of the examples!
>
> Therefore, I suggest instead you create a plplot-examples
> package that contains only text files, which are *all* the example files
> that upstream currently installs in
> $PREFIX/share/plplot$VERSION/examples, but it sounds like instead
> for debian if you do this suggested reorganization
> you should install them in /usr/share/doc/plplot-examples/examples.

OK, so I now moved all examples to the "examples" subdir of the
plplot-doc package, and now I am closer to a working test ;-)

Next problem is that the Debian installation script renames the shared
libraries that are installed for the Python package:
On Python 2.7, 
 - _Pltk_init.so becomes _Pltk_init.x86_64-linux-gnu.so resp. 
 - _plplotc.so becomes _plplotc.x86_64-linux-gnu.so
On Python 3.6
 - /usr/lib/python3.6/dist-packages/_Pltk_init.so becomes
   /usr/lib/python3/dist-packages/_Pltk_init.cpython-36m-x86_64-linux-gnu.so
 - _plplotc.so similar
And Python 3.7 similar.

Is there a way to switch off the consistency check for Python?

BTW, I would still keep the dependencies of the -doc package as they
are, and only for the tests install everything.

Cheers

Ole

[Plplot-devel] FW: Exponential labels - custom position

[Steve S. <ste...@gm...>]

(re-sending from my list subscription address…)

 

 

Hi Plplot

 

We have been pretty quiet, happily employing plplot in our QSAS software. We recently decided to update our plplot version, which we don’t do regurarly since it requires a few tweaks to work with/embed in our system.

 

We (meaning my colleague and software person Tony Allen – in cc) have discovered a bug in the handling of exponential label placement. While we haven’t prepared a minimal example, the exchange below describes the symptoms. The attached plbox.c includes Tony’s correction.

 

Best wishes

Steve

 

From: Allen, Anthony J <a....@im... <mailto:a....@im...> > 
Sent: Monday, November 19, 2018 10:55 AM
To: Steven Schwartz <Ste...@Co... <mailto:Ste...@Co...> >
Subject: Re: Exponential labels

 

OK, this is fixed, but I had to modify plbox.c (attached). 

 

They had kindly added a specific mod for QSAS (one of Alban’s that I noticed

didn’t need doing in the latest version) but they missed out the else{} part,

so it fell through to do their placement as well!

 

Can you forward this to them?

 

Thanks,

Tony

 

 

 

On 15 Nov 2018, at 21:26, Steven Schwartz <Ste...@Co... <mailto:Ste...@Co...> > wrote:

 

Hi Tony,

 

Make the plot from the attached session. If you look at the labels in, e.g,. the panel in the top frame you’ll notice two things:

 

1                     There are TWO y-axis exponential labels: one at the top, and one below the bottom left.

2                     I’ve set the panel’s exponential label horizontal displacement to be -1. You can see that the top label has been moved left while the bottom label has been moved down, by comparison to the bottom frame which has a panel exponential label horizontal displacement of 0.0

 

I think the bottom left exponential label shouldn’t be there at all. The horizontal axis has its own single exponential label, bottom right, that is properly controlled in the Frame tab. And if there’s some reason why it needs to be there, it should move horizontally with a horizontal offset value.

 

?

 

Thanks

Steve

 

 

Steve Schwartz

Research Associate

Laboratory for Atmospheric and Space Physics

University of Colorado Boulder

3665 Discovery Drive, UCB 600, Boulder, CO 80305, USA

 <mailto:ste...@la...> ste...@la...

 

 

<ExpLabelPosition.qss.zip>

 

Re: [Plplot-devel] 5.14.0 release status

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

The PLplot development freeze that started on October 27th contines, i.e.,
do not push any topics other than documentation updates or well-tested bug
fixes.

I am sorry to report that my pace for getting this release out has
frankly slowed to a crawl, but there is some hope I will be able
to restore a normal pace soon.

The reason for this delay is I have been distracted in the last week
by researching a chance to finally work around random lockups I have
been encountering for my new Ryzen 7 1700 Linux box since I bought it
in May.  (For background information about Ryzen instability problems
caused by a fundamentel AMD Ryzen hardware design flaw see
<https://community.amd.com/thread/225795> and
<https://bugzilla.kernel.org/show_bug.cgi?id=196683>.)  Those links
state one possible workaround requires building a specially configured
custom Linux kernel.  I finally managed to do that today after many
false starts, and I am running that custom kernel now.  And with luck
perhaps this lockup distraction will be considerably reduced or even
eliminated by this custom kernel.

In sum, time will tell, and in any case I will continue to keep you
informed about how the plplot-5.14.0 release process is going with status reports
like this one every week or so.

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-11-13 18:23+0100 Ole Streicher wrote:

> Hi Alan,
>
> On 11.11.18 03:17, Alan W. Irwin wrote:
>> Everything you have done above should work fine for building and
>> testing the installed examples using the CMake-based build system for
>> those examples.
>
> My problem is that I have actually split the examples by the language
> binding: C and C++ go to libplplot-dev, tcl goes to plplot-tcl-dev etc.
> It looks that this is not a really smart idea, right?
>
> It also implies that they are not all at the same place: Debian
> filesystem rules require that the examples are installed under
> /usr/share/doc/<package>/examples (and they are partially zipped in the
> moment).
>
> Can I re-create the cmake files required for the tests somehow from the
> source? Then I could avoid a bigger restructuration of the packages.

Hi Ole:

Upstream PLplot installs all examples configured in the core build in
one place which contains a self-contained CMake-based build and test
system for those examples.  Therefore, I have to agree splitting up
those installed examples in various locations is not a good idea
since that means you have to implement a build system for each
component of the examples!

Therefore, I suggest instead you create a plplot-examples
package that contains only text files, which are *all* the example files
that upstream currently installs in
$PREFIX/share/plplot$VERSION/examples, but it sounds like instead
for debian if you do this suggested reorganization
you should install them in /usr/share/doc/plplot-examples/examples.

Then *if* you install all binary PLplot packages (with those examples
removed from then) and that plplot_examples package, then the
test procedure I suggested before for those installed examples should
"just work".  So would you be willing to reorganize your packages that way and
verify the tests are working for that case?

That is a good "proof-of-concept first step to make sure we are at the same
starting point, but the obvious issue with that step is plplot-examples depends on all
plplot binary packages, i.e., it won't work unless all are installed.

The rest of this e-mail concerns two up-stream fixes which I plan to
work on after the 5.14.0 release to relax that constraint.

As I have said before, the key command in the top-level CMakeList.txt
file for the installed examples is

find_package(plplot)

That command uses the exported files (located for
the Debian Buster libplplot-dev package at

libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/plplotConfig.cmake
libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot.cmake
libplplot-dev: /usr/lib/x86_64-linux-gnu/cmake/plplot/export_plplot-none.cmake

) to implement imported targets such as PLPLOT:plplot,
PLPLOT:plplotcxx, etc., and our build system for the installed
examples then goes on to use those imported targets to build and test
the examples.

However, suppose a user only installs a subset of the configured
components of PLplot.  To get the installed examples build system to
work for that case I need to implement the following two upstream
upgrades:

1. I need to factor the exported target files, e.g., the two
export_plplot* files mentioned above.  Such factoring had already been
highly recommended to me by CMake gurus, and I think it should be
entirely straightforward.

Instead of using the "EXPORT export_plplot" signature for all library
and shared object installs and exporting all of that information to
just the two files export_plplot.cmake and export_plplot-none.cmake
using

install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot NAMESPACE ${PROJECT_NAMESPACE})

I simply use the "EXPORT export_<target_name>" signature for all
library and shared object installs, and for each of those I add a

install(EXPORT export_<target_name> DESTINATION ${LIB_DIR}/cmake/plplot NAMESPACE ${PROJECT_NAMESPACE})

The net result will be two files per target installed with names

export_<target_name>.cmake and export_<target_name>-none.cmake

where the first one automatically includes the second.

Also, I will need to change the plplotConfig.cmake file to use the
OPTIONAL signature of the cmake command "include" for a list of every
possible export_<target_name>.cmake file to include just those that
are currently installed.  But that change is completely
straightforward.

To take advantage of this factoring, you would also have to reorganize
what is in your binary packages a small amount.  For example,
libplplot15 which currently includes

libplplot15: /usr/lib/x86_64-linux-gnu/plplot5.13.0/drivers/svg.so

should also need to contain the export files export_svg.cmake and
export_svg-none.cmake that are now would be associated with that
shared object.  And similarly for all packages that contain installed
libraries and shared objects.

As a result of this factoring and your package reorganization to
include the many export_<target_name>.cmake and
export_<target_name>-none.cmake files generated by that factoring in
the correct binary packages, the "find_package(plplot)" command
mentioned above should just create the subset of the imported targets that
correspond to the subset of PLplot binary packages that are
installed by the user.

2. Currently the installed examples generally just check if a given
component has been configured in the core build, by, e.g., checking
ENABLE_cxx.  But with some of those configured components potentially
missing because a user did not install all plplot binary packages such
a check is not correct and needs to be replaced by a test for the
existence of the exported target, e.g., PLPLOT::plplotcxx.  These
sorts of changes should also be straightforward.

So since both upstream improvements are straightforward I plan to do
both some time relatively soon after the release of 5.14.0, and I hope
soon after that is your tests of the plplot-examples package (with the
Depends: in the proof-of-concept replaced by Suggested: in the final
package result) just work regardless of which suggested PLplot binary
packages are installed.

Best wishes,

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Help needed for plplot runtime tests

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

On 2018-11-09 23:16+0100 Ole Streicher wrote:

> Hi,
>
> in the Debian package, we usually try to run CI tests regularly on each
> dependency change. This gives us the opportunity to early find problems
> with the package or one of its dependencies.
>
> However, I have some difficulties to do that; this may be connected with
> my limited knowledge of cmake.
>
> The test is started with the binaries installed in the system and the
> sources unpacked.  The working dir is the root of the sources.
>
> What I basically do now is to run the following script:
>
> --------------------8<---------------------
> #!/bin/sh
>
> set -e
>
> SRC=$(pwd)
>
> test_dir=$(mktemp -d)
>
> cd $test_dir
> cmake $SRC/examples
>
> make test_diff_psc
> make test_noninteractive
> --------------------8<---------------------
>
> However, the "cmake" step fails with
>
> --------------------8<---------------------
> [...]
> -- CMAKE_SYSTEM_NAME = Linux
> -- CMAKE_PLATFORM_INFO_DIR = /tmp/tmp.TwEFoteIXX/CMakeFiles/3.12.3
> CMake Error at CMakeLists.txt:469 (include):
>  include could not find load file:
>
>    plplot_configure
> --------------------8<---------------------
>
> How could I fix this?


Hi Ole:

Everything you have done above should work fine for building and
testing the installed examples using the CMake-based build system for
those examples.  For example, similar tests here are normally
successful, and that error message has never occurred here.  So
looking deeper, it turns out that

include(plplot_configure)

is a command that occurs in the installed CMakeLists.txt file in the
top-level source directory for the installed examples,
SRC=/usr/share/plplot5.13.0/examples (although that 13 will change
to 14 when 5.14.0 is released).  That command is looking for
$SRC/cmake/modules/plplot_configure.cmake which normally is installed
by PLplot.  So since the error message says that installed file cannot
be found, I strongly suspect the problem is simply that your RPM needs
updating to include that installed file in the manifest.

So please let me know if (a) $SRC/cmake/modules/plplot_configure.cmake is
actually installed and if not (b) whether my guess is correct that the
incompleteness of the rpm manifest is the issue.

Best wishes,

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

[Plplot-devel] Help needed for plplot runtime tests

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

Hi,

in the Debian package, we usually try to run CI tests regularly on each
dependency change. This gives us the opportunity to early find problems
with the package or one of its dependencies.

However, I have some difficulties to do that; this may be connected with
my limited knowledge of cmake.

The test is started with the binaries installed in the system and the
sources unpacked. The working dir is the root of the sources.

What I basically do now is to run the following script:

--------------------8<---------------------
#!/bin/sh

set -e

SRC=$(pwd)

test_dir=$(mktemp -d)

cd $test_dir
cmake $SRC/examples

make test_diff_psc
make test_noninteractive
--------------------8<---------------------

However, the "cmake" step fails with

--------------------8<---------------------
[...]
-- CMAKE_SYSTEM_NAME = Linux
-- CMAKE_PLATFORM_INFO_DIR = /tmp/tmp.TwEFoteIXX/CMakeFiles/3.12.3
CMake Error at CMakeLists.txt:469 (include):
  include could not find load file:

    plplot_configure
--------------------8<---------------------

How could I fix this?

Best regards

Ole

[Plplot-devel] 5.14.0 release status

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

The ETA for the release of PLplot-5.14.0 is likely sometime next week.

The PLplot development freeze that started on October 27th contines, i.e.,
do not push any topics other than documentation updates or well-tested bug
fixes.

We have good comprehensive testing results for Arjen's Cygwin and
MinGW-w64/MSYS2 platforms and my Debian Buster platform so I doubt
there will be any further bug fixes before the release.  However, the
actual release has been somewhat delayed because I have added the task
of making a much-needed update to the wiki documentation of our test
procedure to the other release-related tasks (documented in
README.Release_Manager_Cookbook) that I still need to do to complete
this release.

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Finalized plans for 5.14.0 freeze date, testing period, and release

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

The current status is Arjen has come through with good comprehensive
testing results on Cygwin and (except for one issue that is likely not
release critical) also good comprehensive testing results on
MinGW-w64/MSYS2.  So we appear to be in good shape on both these
platforms as well as on my Linux platform (Debian Buster).  If
somebody volunteers by tomorrow (the freeze date) to do some much
needed comprehensive testing on the Mac OS X platform, I will delay
starting the release process to give them a chance to complete their
tests (and me a chance to make any required adjustments to our build
system for the Mac OS X case).  But if nobody cares enough about that
platform to volunteer to do such testing, then I plan to go ahead and
start the release process tomorrow without Mac OS X testing results.

N.B. Because of my new Debian Buster platform I cannot predict very
accurately how long the release process is going to take me, but
conceivably we might have a release of PLplot-5.14.0 as early as
tomorrow night.  However, more realistically it is likely going to be
several days later than that.

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Finalized plans for 5.14.0 freeze date, testing period, and release

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

On 2018-10-03 10:18-0700 Alan W. Irwin wrote:

> On 2018-09-23 18:56-0700 Alan W. Irwin wrote:
>
>> I continue have a large list of different topics I would like to work
>> on for PLplot, but, on the other hand, comprehensive tests are looking
>> good (at least on Debian Buster) right now, and it has been much too
>> long since our last release (mostly because of the "new computer" and
>> "new distro version" issues I have been encountering).  So I plan to
>> spend the next several weeks working on the most urgent development
>> topics I have a good chance of finishing before the soft freeze, with
>> a proposed date of the freeze near the end of October followed by a
>> testing and debugging period with the actual release of 5.14.0
>> occurring roughly in mid November.  Please let me know if the general
>> timing of that soft freeze, testing period, and subsequent release
>> will cause you any issues with development topics you would like to
>> push before the release of 5.14.0.  But if I don't hear any strong
>> objections along those lines, then later this week I plan to finalize
>> that soft freeze date as October 27th (to be definite and to place it
>> on the last Saturday in October).
>
> This is official notice that I will be going ahead with this plan.  In
> particular, the soft freeze date has now been finalized as of October
> 27th.

Current status:

This is a reminder that the soft freeze deadline is only 5 days away.
But I am going to stick to it (e.g., some of the small topics I am
currently working on may have to be put off until post release, but
such postponent is convenient to do with git since I am working on
these topics using topic branches.)

Comprehensive testing is going well.  With the current master tip
version I am getting essentially perfect results on Linux (Debian
Buster).  That is there are no obvious configure, build, or run-time
issues and there is a perfect test_diff_device report for the
(default) svg testing device.  Also Arjen is getting promising-looking
results for Cygwin.  There is one regression there (the octave binding
does not build) but a follow-up comprehensive test with octave
disabled worked without issues, and the solution for the octave build
difficulty may simply be a Cygwin system upgrade for one of the
octave-related components.  In any case, I am very happy with this
preliminary result since a lot of build-system development has
occurred since the last time that Cygwin was comprehensively tested.

Despite this complete comprehensive testing success on Linux and
almost-complete preliminary comprehensive testing success on Windows
some additional volunteers to help out with comprehensive testing
would add a lot to the value of this release. For example, we need
someone to comprehensively test the MinGW-w64/MSYS2 Windows platform
if Arjen does not have time to get to it, and we need someone to test
any or all of Mac OS X + fink, MacPorts, and/or HomeBrew.  In addition
"redundant" comprehensive testing on the already tested Cygwin and
Linux platforms would be useful since there are so many different
Windows platforms that underlie Cygwin, and so many different Linux
distributions that do things differently than my Debian Buster
platform.

N.B. the advantages of comprehensively testing this release on as many
different platform variants as possible are obvious from the PLplot
release integrity perspective, but I would also like to emphasize an
additional individual advantage for testers which is testing helps you
learn how to get the most out of PLplot (e.g., which packages to
install to enhance the power of PLplot) for your platform of choice.

Also once your particular system is set up properly for PLplot,
running the comprehensive testing script is pretty trivial if you
specify the "--do_test_interactive no" option so you don't have to
baby-sit the tests generated by the script.  But in any case, please
run "scripts/comprehensive_test.sh --help" to get an idea of what is
possible.

Just to give you an idea of what is involved with the
"--do_test_interactive no" case you do need access to 6 GB of spare
disk space to store the many plot files that are generated by these
tests, and my ~11-year old Intel box took something like ~5 hours to
complete this set of tests while my modern Ryzen 7 1700 box with
faster memory and CPUs and 4 times as many CPUs takes roughly ~one
hour to complete the noninteractive tests.  In my case for
"--do_test_interactive no", I simply use the bash source command to
set relevant environment variables, start the script, and then I do
something else until the tests complete. And it should be just that
simple for you as well once you have installed all relevant platform
packages and decided which components of PLplot have to be disabled if
they are not working on your particular platform.

In sum, comprehensive testing should be straightforward so I hope to
hear from *all* of you lurking on this list who have access to a
reasonably fast modern system where you normally build PLplot in any
case.  And if you want to comprehensively test PLplot on some low-end
hardware (e.g., a raspberry PI system), such comprehensive test
results would be most interesting as well!

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

[Plplot-devel] [RFC] Patch inplement plarc clipping

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

Hi,

In our application we draw a graph using an extcairo device. While 
testing on a 32 bit system I ran in an issue. When zooming in on a graph 
the cairo context got the status CAIRO_STATUS_INVALID_MATRIX. 
Reproducing the issue pointed to the function plP_wcpcx. The function 
returned a PLINT_MIN due to a the double result being too large. (It is 
implementation defined whether C returns the largest or the smallest 
value in this case.) This caused an 'a' of 0, which was where cairo got 
its CAIRO_STATUS_INVALID_MATRIX status. This issue was caused by circles 
drawn outside the clipping area of the plot.

The issue occurs both with plplot 5.10.0 as shipped with Debian Strech 
and the current git master.

I created a small patch which seems to fix the issue for me. It simply 
does not draw the arcs that are fully outside the clipping area. I'm not 
entirely sure whether this is the right solution, but it fixes the issue 
for me. The patch contains a debug printf for testing purposes. I 
modified example 3 to reproduce the issue. The x value becomes PLINT_MIN 
on a 32 bit system. The output of x03 on the console with the plarc 
patch applied is:
xscl[0] 2144687274, xscl[1] 2145210464
xscl[0] -2147483648, xscl[1] -2147483648

Is this patch the right approach?

Regards,
Mark de Wever

[Plplot-devel] Finalized plans for 5.14.0 freeze date, testing period, and release

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

On 2018-09-23 18:56-0700 Alan W. Irwin wrote:

> I continue have a large list of different topics I would like to work
> on for PLplot, but, on the other hand, comprehensive tests are looking
> good (at least on Debian Buster) right now, and it has been much too
> long since our last release (mostly because of the "new computer" and
> "new distro version" issues I have been encountering).  So I plan to
> spend the next several weeks working on the most urgent development
> topics I have a good chance of finishing before the soft freeze, with
> a proposed date of the freeze near the end of October followed by a
> testing and debugging period with the actual release of 5.14.0
> occurring roughly in mid November.  Please let me know if the general
> timing of that soft freeze, testing period, and subsequent release
> will cause you any issues with development topics you would like to
> push before the release of 5.14.0.  But if I don't hear any strong
> objections along those lines, then later this week I plan to finalize
> that soft freeze date as October 27th (to be definite and to place it
> on the last Saturday in October).

This is official notice that I will be going ahead with this plan.  In
particular, the soft freeze date has now been finalized as of October
27th.

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

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

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

On 2018-09-29 09:53+0100 Phil Rosenberg wrote:

[...]
> - Alan do you know if it [library suffix] is still implemented and if so what it is?
> There used to be a d suffix added to represent the fact that the
> library was built with double precision floating point variables, but
> I don't think this is the case any more.

We dropped library suffixes some time ago because of the much cleaner
solution you state below.

[...]
> Anyway, my solution was to install my debug libraries in a folder
> specific to debug libraries. Almost every library has a way to specify
> the install prefix. With plplot you can do this with the
> -DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX

Exactly.

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

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

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

In a small project https://github.com/LaurentBerger/AAPlus, I use this 
https://stackoverflow.com/questions/29971026/generator-expression-for-install-commands 



Le 29/09/2018 à 10:53, Phil Rosenberg a écrit :
> Hi Laurent
> Just a not about naming - I too expected a d suffix on the library
> name to represent debug when I first started using plplot. There used
> to be a cmake option to add a suffix to the name, but it is no longer
> listed on https://sourceforge.net/p/plplot/wiki/CMake_options_for_PLplot/
> - Alan do you know if it is still implemented and if so what it is?
> There used to be a d suffix added to represent the fact that the
> library was built with double precision floating point variables, but
> I don't think this is the case any more.
>
> I used to add the d suffix for debug builds, but in the end I stopped.
> I came across too many libraries that didn't do it. I have a feeling
> it is an inherently windows style thing (you only need debug libraries
> if they are static rather than shared and Linux users never seem to
> build static libraries), so many Linux-centric open source projects
> don't do it. Maybe I'm wrong in saying this, it's only my thoughts.
> Anyway, my solution was to install my debug libraries in a folder
> specific to debug libraries. Almost every library has a way to specify
> the install prefix. With plplot you can do this with the
> -DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX
>
> Whether you go for a prefix option or if a suffix is possible you will
> need to run cmake twice, once for release and once for debug and once
> for release by setting the -DCMAKE_CONFIGURATION_TYPES options to
> "Debug" or "Release".
>
> Phil
> On Tue, 25 Sep 2018 at 22:08, Alan W. Irwin <Ala...@gm...> wrote:
>> On 2018-09-25 22:05+0200 Laurent Berger wrote:
>>
>>> Hi,
>>>
>>> I want to use plplot in my own project using cmake and I miss something. my
>>> cmakelists.txt is see below and it works. But in include_directories cmake
>>> command I must write :
>>>
>>> include_directories(${plplot_DIR}/../../../include) and it is really weird.
>>> what's variable name for include ?
>> [...]
>>
>>> CMakeLists.txt
>>>
>> [...]
>>> find_package(plplot)
>> [...]
>>> ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
>> [...]
>>> if (plplot_FOUND)
>>>
>>>      include_directories(${plplot_DIR}/../../../include)
>>>      target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
>>> else (plplot_FOUND)
>>> message( " PROBLEME" )
>>> endif(plplot_FOUND)
>> Hi Laurent:
>>
>> I have reviewed the redacted version above, and all seems well.  For
>> example, our installed examples are similarly built against the
>> installed version of PLplot, and what you have implemented above
>> follows that same method.  For example, you can see
>> "find_package(plplot)" (in the non-CORE_BUILD part of
>> examples/CMakeLists.txt), and a combination of add_executable,
>> include_directories (which refers to the installed location of PLplot
>> for the non-CORE_BUILD case just like you apparently have
>> implemented), and target_link_libraries in examples/c/CMakeLists.txt.
>>
>> However, you were right to question that include_directories command
>> which is necessary now, but should not be necessary in future once I
>> set up the export of PLplot to handle compile options properly.  But
>> that implementation is a little tricky so although it is on my ToDo
>> list now, I am going to put it off until after the 5.14.0 release that
>> is coming soon.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>>
>>
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

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

Hi Laurent
Just a not about naming - I too expected a d suffix on the library
name to represent debug when I first started using plplot. There used
to be a cmake option to add a suffix to the name, but it is no longer
listed on https://sourceforge.net/p/plplot/wiki/CMake_options_for_PLplot/
- Alan do you know if it is still implemented and if so what it is?
There used to be a d suffix added to represent the fact that the
library was built with double precision floating point variables, but
I don't think this is the case any more.

I used to add the d suffix for debug builds, but in the end I stopped.
I came across too many libraries that didn't do it. I have a feeling
it is an inherently windows style thing (you only need debug libraries
if they are static rather than shared and Linux users never seem to
build static libraries), so many Linux-centric open source projects
don't do it. Maybe I'm wrong in saying this, it's only my thoughts.
Anyway, my solution was to install my debug libraries in a folder
specific to debug libraries. Almost every library has a way to specify
the install prefix. With plplot you can do this with the
-DCMAKE_LIBRARY_PATH or -DCMAKE_INSTALL_PREFIX

Whether you go for a prefix option or if a suffix is possible you will
need to run cmake twice, once for release and once for debug and once
for release by setting the -DCMAKE_CONFIGURATION_TYPES options to
"Debug" or "Release".

Phil
On Tue, 25 Sep 2018 at 22:08, Alan W. Irwin <Ala...@gm...> wrote:
>
> On 2018-09-25 22:05+0200 Laurent Berger wrote:
>
> > Hi,
> >
> > I want to use plplot in my own project using cmake and I miss something. my
> > cmakelists.txt is see below and it works. But in include_directories cmake
> > command I must write :
> >
> > include_directories(${plplot_DIR}/../../../include) and it is really weird.
> > what's variable name for include ?
>
> [...]
>
> > CMakeLists.txt
> >
> [...]
> > find_package(plplot)
> [...]
> > ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
> [...]
> > if (plplot_FOUND)
> >
> >     include_directories(${plplot_DIR}/../../../include)
> >     target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
> > else (plplot_FOUND)
> > message( " PROBLEME" )
> > endif(plplot_FOUND)
>
> Hi Laurent:
>
> I have reviewed the redacted version above, and all seems well.  For
> example, our installed examples are similarly built against the
> installed version of PLplot, and what you have implemented above
> follows that same method.  For example, you can see
> "find_package(plplot)" (in the non-CORE_BUILD part of
> examples/CMakeLists.txt), and a combination of add_executable,
> include_directories (which refers to the installed location of PLplot
> for the non-CORE_BUILD case just like you apparently have
> implemented), and target_link_libraries in examples/c/CMakeLists.txt.
>
> However, you were right to question that include_directories command
> which is necessary now, but should not be necessary in future once I
> set up the export of PLplot to handle compile options properly.  But
> that implementation is a little tricky so although it is on my ToDo
> list now, I am going to put it off until after the 5.14.0 release that
> is coming soon.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

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

On 2018-09-25 22:05+0200 Laurent Berger wrote:

> Hi,
>
> I want to use plplot in my own project using cmake and I miss something. my 
> cmakelists.txt is see below and it works. But in include_directories cmake 
> command I must write :
>
> include_directories(${plplot_DIR}/../../../include) and it is really weird. 
> what's variable name for include ?

[...]

> CMakeLists.txt
>
[...]
> find_package(plplot)
[...]
> ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )
[...]
> if (plplot_FOUND)
>
>     include_directories(${plplot_DIR}/../../../include)
>     target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
> else (plplot_FOUND)
> message( " PROBLEME" )
> endif(plplot_FOUND)

Hi Laurent:

I have reviewed the redacted version above, and all seems well.  For
example, our installed examples are similarly built against the
installed version of PLplot, and what you have implemented above
follows that same method.  For example, you can see
"find_package(plplot)" (in the non-CORE_BUILD part of
examples/CMakeLists.txt), and a combination of add_executable,
include_directories (which refers to the installed location of PLplot
for the non-CORE_BUILD case just like you apparently have
implemented), and target_link_libraries in examples/c/CMakeLists.txt.

However, you were right to question that include_directories command
which is necessary now, but should not be necessary in future once I
set up the export of PLplot to handle compile options properly.  But
that implementation is a little tricky so although it is on my ToDo
list now, I am going to put it off until after the 5.14.0 release that
is coming soon.

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

[Plplot-devel] How to use plplot in my own project?

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

Hi,

I want to use plplot in my own project using cmake and I miss something. 
my cmakelists.txt is see below and it works. But in include_directories 
cmake command I must write :

include_directories(${plplot_DIR}/../../../include) and it is really 
weird. what's variable name for include ?

Another strange behavior: in debug and release lib generated by cmake 
installation are the same plplot.lib  and it should be something like 
plplot.lib and plplotd.lib. I can find export_plplot-debug.cmake and 
export_plplot-release.cmake so i think it could be possible to add a d 
in export_plplot-debug.cmake for all libs


CMakeLists.txt

cmake_minimum_required(VERSION 3.0)

set(NomProjet examplePlplot)
PROJECT (${NomProjet})
find_package(OpenCV  REQUIRED)
find_package(wxWidgets COMPONENTS core base net adv aui html  qa 
richtext stc ribbon xml gl REQUIRED)
find_package(plplot)

file(GLOB Projet_SRCS
     "*.h"
     "*.cpp")

ADD_EXECUTABLE (${NomProjet} ${Projet_SRCS} )

if (wxWidgets_FOUND)
     include_directories(${wxWidgets_INCLUDE_DIRS} ${OpenCV_INCLUDE_DIRS})
     target_link_libraries (${NomProjet} LINK_PUBLIC ${OpenCV_LIBS} 
${wxWidgets_LIBRARIES} )
endif (wxWidgets_FOUND)
if (plplot_FOUND)

     include_directories(${plplot_DIR}/../../../include)
     target_link_libraries( ${NomProjet} PUBLIC PLPLOT::plplotwxwidgets)
else (plplot_FOUND)
message( " PROBLEME" )
endif(plplot_FOUND)


SET(wxWidgets_DEFINITIONS WXUSINGDLL)
set_target_properties(${NomProjet} PROPERTIES  COMPILE_DEFINITIONS 
"${wxWidgets_DEFINITIONS};__WXMSW__;_CRT_SECURE_NO_WARNINGS")
set_target_properties(${NomProjet} PROPERTIES LINK_FLAGS_DEBUG 
"/SUBSYSTEM:CONSOLE")
set_target_properties(${NomProjet} PROPERTIES LINK_FLAGS_RELEASE 
"/SUBSYSTEM:CONSOLE")




Le 23/09/2018 à 12:12, Laurent Berger a écrit :
> Hi,
>
> https://sourceforge.net/p/plplot/plplot/ci/4a5f94a70ac259d696dfaa8117cead7ad89b13f3/ 
> : It works thanks!
>
>
> New file is now
>
> // Headers needed for Rand
> #ifdef _WIN32
> // This include must occur before any other include of stdlib.h due to
> // the #define _CRT_RAND_S
> #define _CRT_RAND_S
> #include <stdlib.h>
> #else
> #include <fstream>
> #endif
>
> // wxwidgets headers
> #include <wx/wx.h>
> #include <wx/dir.h>
> #include <wx/ustring.h>
> // PLplot headers
> #include "plDevs.h"
> #include "wxwidgets.h" // includes wx/wx.h
>
>
> // std and driver headers
> #include <cmath>
> #include <limits>
>
>
> Le 23/09/2018 à 02:23, Alan W. Irwin a écrit :
>> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>>
>>> Hi Laurent
>>>
>>> I have implemented your first solution. If you could let me know that
>>> things now work for you that would be great.
>>
>> Hi Phil:
>>
>> Although your question was addressed to Laurent, it should interest
>> you to know your fix causes no issues for Linux (i.e., building the
>> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
>> or run-time issues).
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is there some important reason for using the -single-module linker option on modern Mac OS X?

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

On 2018-03-22 19:12-0700 Alan W. Irwin wrote:

> To those here with knowledge of Mac OS X linking:
>
> According to <http://www.manpages.info/macosx/ld.1.html> there exists
> the following ld options:
>
> "
> -single_module When building a dynamic library build the library so that it 
> contains only one module.
>
> -multi_module
> When building a dynamic library build the library so that it contains
> one module for each object file linked in. This is the default.
> "
>
> We currently use -single_module for linking on this platform
> (see CMAKE_USER_MAKE_RULES_OVERRIDE in the top-level CMakeLists.txt
> file).
>
> However that override was imposed 12 (!) years ago to address a
> linking issue that I suspect no longer exists.  For example, a google
> search for the terms <cmake "-single_module"> found nothing relevant
> beyond the CMake mailing-list discussion I generated about this issue
> back then.
>
> So unless I hear from Mac OS X experts here that there is some
> important reason for using the -single_module option for linking
> dynamic libraries on modern Mac OS X, I plan (on Sunday to give you a
> couple of days to respond) to drop this override completely to conform
> to how other CMake-based build systems configure linking of dynamic
> libraries on Mac OS X.

>From the "better late than never" department, I have indeed now
(commit d6a762704) removed this override that is specific to Mac OS X
"on Sunday", but frankly I forgot all about this until reminded of it
today by my ToDo list so it is a large number of Sundays later than I
anticipated in the above post!

N.B. This fundamental linking change for Mac OS X platforms needs to
be comprehensively tested on Mac OS X.  So I need a volunteer (with
lots of free disk space that is temporarily consumed by the test until
deletion of many plot files at the end of the test) to do that.  Just
run

scripts/comprhensive_test.sh --help

to see what is possible with that script.  However, be warned that if
you specify no options the default is *all* components of the
comprehensive test are run.  This means, for example, that you will be
doing a lot of babysitting as you work through the interactive
components of the test so at minimum for a first try you will likely
want to constrain the test with the

--do_test_interactive no

script option to make the test into something that can quietly be run
in the background with little interaction needed from you.

Also, note the test generates a report tarball with all the details of
the test whether it succeeds or not.  So please send me that report
tarball regardless of results since in case of failures that tarball
helps me to analyze the reason for the failures, and in case of
success that tarball helps me to assemble a report of your
comprehensive test success for our wiki.

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

[Plplot-devel] Tentative plans for 5.14.0 freeze date, testing period, and release

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

I continue have a large list of different topics I would like to work
on for PLplot, but, on the other hand, comprehensive tests are looking
good (at least on Debian Buster) right now, and it has been much too
long since our last release (mostly because of the "new computer" and
"new distro version" issues I have been encountering).  So I plan to
spend the next several weeks working on the most urgent development
topics I have a good chance of finishing before the soft freeze, with
a proposed date of the freeze near the end of October followed by a
testing and debugging period with the actual release of 5.14.0
occurring roughly in mid November.  Please let me know if the general
timing of that soft freeze, testing period, and subsequent release
will cause you any issues with development topics you would like to
push before the release of 5.14.0.  But if I don't hear any strong
objections along those lines, then later this week I plan to finalize
that soft freeze date as October 27th (to be definite and to place it
on the last Saturday in October).

To give you more details about the actual events leading up to the
release, the overall timing of the release depends critically on the
soft freeze date, i.e., the date where we ask our developers to quit
pushing new development topics and instead concentrate on fixing bugs
and updating the documentation until the release is completed.  What
that means practically is just after the freeze date I will call for intensive
testing and use those results to solve as many bugs as possible
without introducing any new development topics.  That process will
likely take one or two weeks after the freeze date before I can start
the official release process currently described for Debian Oldstable
= Jessie in README.Release_Manager_Cookbook.  But that release process
(which normally just takes a day or two) will likely get stretched out
a bit because that cookbook likely needs quite a bit of updating as I
encounter issues that are caused by my current platform of Debian
Buster.  In sum, the official release should occur something like two
to three weeks after the soft freeze date depending on the
participation from you guys in the testing, how difficult it is to
sort out the bugs found by that testing, and how much I have to
upgrade the release process for Debian Buster.  So that's how the
currently proposed freeze date of October 27th gets transformed into a
release date that is roughly in mid November.

Alan
__________________________
Alan W. Irwin

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Cannot compile plplot using VS 2017

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

Good news! Thanks for reporting the problem.

Phil

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

________________________________
From: Laurent Berger <lau...@un...>
Sent: Sunday, September 23, 2018 11:12:50 AM
To: Alan W. Irwin; Phil Rosenberg
Cc: PLplot development list
Subject: Re: [Plplot-devel] Cannot compile plplot using VS 2017

Hi,

https://sourceforge.net/p/plplot/plplot/ci/4a5f94a70ac259d696dfaa8117cead7ad89b13f3/
: It works thanks!


New file is now

// Headers needed for Rand
#ifdef _WIN32
// This include must occur before any other include of stdlib.h due to
// the #define _CRT_RAND_S
#define _CRT_RAND_S
#include <stdlib.h>
#else
#include <fstream>
#endif

// wxwidgets headers
#include <wx/wx.h>
#include <wx/dir.h>
#include <wx/ustring.h>
// PLplot headers
#include "plDevs.h"
#include "wxwidgets.h" // includes wx/wx.h


// std and driver headers
#include <cmath>
#include <limits>


Le 23/09/2018 à 02:23, Alan W. Irwin a écrit :
> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>
>> Hi Laurent
>>
>> I have implemented your first solution. If you could let me know that
>> things now work for you that would be great.
>
> Hi Phil:
>
> Although your question was addressed to Laurent, it should interest
> you to know your fix causes no issues for Linux (i.e., building the
> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
> or run-time issues).
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.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] Cannot compile plplot using VS 2017

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

Hi,

https://sourceforge.net/p/plplot/plplot/ci/4a5f94a70ac259d696dfaa8117cead7ad89b13f3/ 
: It works thanks!


New file is now

// Headers needed for Rand
#ifdef _WIN32
// This include must occur before any other include of stdlib.h due to
// the #define _CRT_RAND_S
#define _CRT_RAND_S
#include <stdlib.h>
#else
#include <fstream>
#endif

// wxwidgets headers
#include <wx/wx.h>
#include <wx/dir.h>
#include <wx/ustring.h>
// PLplot headers
#include "plDevs.h"
#include "wxwidgets.h" // includes wx/wx.h


// std and driver headers
#include <cmath>
#include <limits>


Le 23/09/2018 à 02:23, Alan W. Irwin a écrit :
> On 2018-09-22 23:16+0100 Phil Rosenberg wrote:
>
>> Hi Laurent
>>
>> I have implemented your first solution. If you could let me know that
>> things now work for you that would be great.
>
> Hi Phil:
>
> Although your question was addressed to Laurent, it should interest
> you to know your fix causes no issues for Linux (i.e., building the
> test_c_wxwidgets and test_wxPLplotDemo targets caused no obvious build
> or run-time issues).
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.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
> __________________________