plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] First proof-of-concept versions of PLplot "memory allocation" and "exception handling" topics

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

Just a note to say that as far as I can tell from the Visual Studio
memory tools, it appears that the memory leak is wxWidgets related and
not to do with the exception testing. The actual data in the leaked
memory appears to be class information text for wxWidgets dynamic
casting of pointers and occurs when using the null device, so I have a
feeling it is a wxWidgets bug, not a plplot bug. I'd be interested to
know what you see on Linux Alan.

Phil

On 17 July 2017 at 11:31, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan
> Please find attached a new patch series.
>
> I should have fixed the segfault issue. Note I have done some rebasing
> so you will probably need to create new branches. I think there is a
> memory leak somewhere. I will look into this.
>
> But you may have something you can play with to test a bit better now.
> I have added specific comments below.
>
>
>> I used "git am" apply your first two commits (which should be handled
>> as a separate topic) cleanly to a private topic branch I created here
>> called "memory_allocation".  That clean result was based on the tip of the
>> current
>> master branch.
>
> That's good, as I said I have quite old source and didn't want to risk
> introducing any changes in the build system that may have cost me time
> as I only had a few hours to set this up and send it to you. I will
> update once I get chance.
>
>>
>> I similarly applied your four commits cleanly to a private topic branch
>> which
>> I call "exception_handling".  i.e., I assumed for this topic branch
>> the memory_allocation topic would be merged before the exception
>> handling part of your commits, although I doubt that would be actually
>> necessary, i.e., both these topics are completely independent of each
>> other.
>
> Yes, the memory management is independent of exception handling, but
> exception handling requires memory management to avoid memory leaks.
>
>>
>> I extensively tested your "memory_allocation" topic as follows.
>>
>> I configured cmake with the option -DVALGRIND_ALL_TESTS=ON and built
>> the test_c_psc target (which builds all our c standard examples
>> for the psc device and runs them all using valgrind).  Those
>> valgrind reports were perfect, i.e., the list of such
>> reports without the phrases "no leaks are possible" and "0 errors from 0
>> contexts") is empty as can be seen from
>>
>> software@raven> ls examples/*.log
>> examples/valgrind.x00c.psc.log  examples/valgrind.x11c.psc.log
>> examples/valgrind.x22c.psc.log
>> examples/valgrind.x01c.psc.log  examples/valgrind.x12c.psc.log
>> examples/valgrind.x23c.psc.log
>> examples/valgrind.x02c.psc.log  examples/valgrind.x13c.psc.log
>> examples/valgrind.x24c.psc.log
>> examples/valgrind.x03c.psc.log  examples/valgrind.x14c.psc.log
>> examples/valgrind.x25c.psc.log
>> examples/valgrind.x04c.psc.log  examples/valgrind.x15c.psc.log
>> examples/valgrind.x26c.psc.log
>> examples/valgrind.x05c.psc.log  examples/valgrind.x16c.psc.log
>> examples/valgrind.x27c.psc.log
>> examples/valgrind.x06c.psc.log  examples/valgrind.x17c.psc.log
>> examples/valgrind.x28c.psc.log
>> examples/valgrind.x07c.psc.log  examples/valgrind.x18c.psc.log
>> examples/valgrind.x29c.psc.log
>> examples/valgrind.x08c.psc.log  examples/valgrind.x19c.psc.log
>> examples/valgrind.x30c.psc.log
>> examples/valgrind.x09c.psc.log  examples/valgrind.x20c.psc.log
>> examples/valgrind.x31c.psc.log
>> examples/valgrind.x10c.psc.log  examples/valgrind.x21c.psc.log
>> examples/valgrind.x33c.psc.log
>>
>> and the empty results from
>>
>> software@raven> grep -L "no leaks are possible"
>> examples/valgrind.x??c.psc.log
>> software@raven> grep -L "0 errors from 0 contexts"
>> examples/valgrind.x??c.psc.log
>
> This is not surprising. I Don't think the plmalloc or plrealloc
> functions are actually used anywhere yet :-D
>
>>
>> Furthermore, I like what you have done with plmalloc, plrealloc, and
>> plfree where if inside those routines malloc, realloc, or free
>> respectively fail, plexit is called with appropriate error message.
>> Assuming, then you want to replace all our current direct calls to
>> malloc, realloc and free with these pl* variants, this solves a major
>> problem we have which was all the wide range of different treatments
>> of how malloc, realloc and free errors were checked, i.e., in the best
>> cases plexit is called, but more usually no error checking is done at
>> all!
>
> Not quite. Any pointers which we store in the plstream must use the
> original malloc, otherwise they will be freed as soon as the API call
> exits.
> There are two options here.
> 1) Rely on developers to choose malloc or plmalloc as needed. But when
> I looked through the code, it wasn't always obvious because there are
> some places where memory is allocated in one bit of code, then the
> assignment of the pointer in the plstream occurs somewhere else. I
> think this is quite messy.
> 2) Have plfreeall check that the memory allocations do not correspond
> to the pointers in plstream. This only requires that developers modify
> plfreeall if they add a new heap pointer to plstream. it may be that
> this is easy to miss as it would be done infrequently, but it would
> probably very quickly generate a segfault or valgrind would spot it
> easily.
>
> My preference is I think for 2, but I welcome comments.
>
>>
>> So this is a most encouraging result.
>>
>> However, there are some issues with this topic branch that I noticed
>>
>> * This approach should be extended to calloc as well.
>
> This is my lack of C (vs C++ knowledge). I didn't know calloc existed.
> I'll add it.
>
>>
>> * You are not finished, e.g., I notice many direct calls to malloc
>>   still within our code base.
>
> I haven't even started the replacement of malloc with plmalloc.
>
>>
>> * The following two compile warnings need to be addressed:
>>
>> [ 18%] Building C object src/CMakeFiles/plplot.dir/plcore.c.o
>> cd /home/software/plplot/HEAD/build_dir/src && /usr/lib/ccache/cc
>> -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dplplot_EXPORTS -I/home/
>> software/plplot/HEAD/plplot.git/include
>> -I/home/software/plplot/HEAD/plplot.git/lib/qsastime
>> -I/home/software/plplot/HEAD/buil
>> d_dir -I/home/software/plplot/HEAD/build_dir/include  -O3
>> -fvisibility=hidden -Wuninitialized -fPIC    -I/usr/include -o CMake
>> Files/plplot.dir/plcore.c.o   -c
>> /home/software/plplot/HEAD/plplot.git/src/plcore.c
>> /home/software/plplot/HEAD/plplot.git/src/plcore.c: In function
>> ‘plinitialisememorylist’:
>> /home/software/plplot/HEAD/plplot.git/src/plcore.c:117:9: warning: ignoring
>> return value of ‘realloc’, declared with attribute warn_unused_result
>> [-Wunused-result]
>>          realloc( pls->memorylist, n * sizeof ( void* ) );
>>          ^
>> /home/software/plplot/HEAD/plplot.git/src/plcore.c: In function ‘plmalloc’:
>> /home/software/plplot/HEAD/plplot.git/src/plcore.c:140:9: warning: ignoring
>> return value of ‘realloc’, declared with attribute warn_unused_result
>> [-Wunused-result]
>>          realloc( pls->memorylist, n * sizeof ( void* ) );
>>          ^
>>
>
> Fixed
>
>> * Once you feel you have completed development of this private topic
>>   branch, then you should test it like I did above (assuming you have
>>   good access to a Linux box or I could do that testing if you like
>>   when the time comes), and assuming all the valgrind results are
>>   still clean, then you should merge it to the master branch
>>   completely independent of what happens with your exception handling
>>   topic branch.
>>
>> That finishes the memory allocation topic, and I now want to move
>> on to the exception handling topic.
>>
>> For that topic branch I built the x00c and ps targets OK (except for
>> the memory allocation branchh code warnings I mentioned above), but
>> that result segfaulted at run time, e.g.,
>>
>> software@raven> examples/c/x00c -dev psc -o test.psc
>> Segmentation fault
> Fixed
>
>>
>> Here are the valgrind results for this important memory management issue
>>
>> software@raven> valgrind examples/c/x00c -dev psc -o test.psc
>> ==24594== Memcheck, a memory error detector
>> ==24594== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>> ==24594== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
>> ==24594== Command: examples/c/x00c -dev psc -o test.psc
>> ==24594== ==24594== Conditional jump or move depends on uninitialised
>> value(s)
>> ==24594==    at 0x53F1EE5: longjmp (longjmp.c:32)
>> ==24594==    by 0x4E840B0: c_plenv (in
>> /home/software/plplot/HEAD/build_dir/src/libplplot.so.14.0.0)
>> ==24594==    by 0x400858: main (in
>> /home/software/plplot/HEAD/build_dir/examples/c/x00c)
>> ==24594== ==24594== Warning: client switching stacks?  SP change:
>> 0xffefffdc8 --> 0x3d8d115408920055
>> ==24594==          to suppress, use: --max-stackframe=4435220191945818765 or
>> greater
>> ==24594== Use of uninitialised value of size 8
>> ==24594==    at 0x53F1F52: __longjmp (__longjmp.S:60)
>> ==24594== ==24594== Jump to the invalid address stated on the next line
>> ==24594==    at 0x3D8D115408920055: ???
>> ==24594==  Address 0x3d8d115408920055 is not stack'd, malloc'd or (recently)
>> free'd
>> ==24594== ==24594== ==24594== Process terminating with default action of
>> signal 11 (SIGSEGV)
>> ==24594==  Bad permissions for mapped region at address 0x3D8D115408920055
>> ==24594==    at 0x3D8D115408920055: ???
>> ==24594== Use of uninitialised value of size 8
>> ==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
>> ==24594== ==24594== Invalid write of size 8
>> ==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
>> ==24594==  Address 0x3d8d11540892004d is not stack'd, malloc'd or (recently)
>> free'd
>> ==24594== ==24594== ==24594== Process terminating with default action of
>> signal 11 (SIGSEGV)
>> ==24594==  General Protection Fault
>> ==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
>> ==24594== ==24594== HEAP SUMMARY:
>> ==24594==     in use at exit: 76,682 bytes in 288 blocks
>> ==24594==   total heap usage: 360 allocs, 72 frees, 124,441 bytes allocated
>> ==24594== ==24594== LEAK SUMMARY:
>> ==24594==    definitely lost: 0 bytes in 0 blocks
>> ==24594==    indirectly lost: 0 bytes in 0 blocks
>> ==24594==      possibly lost: 0 bytes in 0 blocks
>> ==24594==    still reachable: 76,682 bytes in 288 blocks
>> ==24594==         suppressed: 0 bytes in 0 blocks
>> ==24594== Rerun with --leak-check=full to see details of leaked memory
>> ==24594== ==24594== For counts of detected and suppressed errors, rerun
>> with: -v
>> ==24594== Use --track-origins=yes to see where uninitialised values come
>> from
>> ==24594== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
>> Segmentation fault
>
> I think at least some of this is due to the realloc issue above.
> Hopefully some or all of this is fixed now. I would welcome another
> valgrind summary.
>
>>
>> So you need to address this before we can do any extensive run-time testing
>> of your exception handling ideas.  Of course, you did warn us that
>> this code was quite preliminary so issues like above are to be
>> expected. Furthermore, in my view, discussion of real code developers
>> can try for themselves always beats discussion of code that doesn't
>> exist yet. So I very much appreciate you supplying us with this
>> preliminary exception handling code to focus our further discussion.
>>
>> I do have some general points to make from just looking at the broad
>> picture of what you are trying to accomplish here with the exception
>> handling macros PLTRY, PLCATCH, PLENDTRY, and PLTHROW.
>>
>> * There is currently no ability for PLTHROW to propagate an error message.
>> Is
>>   that a fundamental limitation of setjmp/longjmp based C exception
>>   handling or could that feature be easily implemented?  If the latter,
>>   then that gives us the option to use PLTHROW wherever errors occur
>>   rather than always calling plexit which then prints the error
>>   message before it uses PLTHROW.  So for example in plmalloc,
>>   plcalloc, plrealloc, and plfree you could use PLTHROW directly
>>   rather than calling plexit. However, if implementation of handling
>>   error messages for PLTHROW is difficult/impossible, then I would be
>>   content to call plexit everywhere so that there would only be one
>>   PLTHROW (within plexit after printing out the error message) in our
>>   code as now on this topic branch.
>
> We could throw an error code, but I don't think an error message.
> However, I think it would be better to put an error message/code in
> the plstream. This would need to be on the heap rather than the stack
> otherwise it would be lost in the stack unwinding. I think we should
> maintain a function like plerror that would put the error code/message
> onto the stream, but maybe renamed to be called something like plthrow
>
>>
>> * Can you explain why you have implemented all the PLTRY blocks
>>   in src/plvpor.c (with presumably the idea in mind to use PLTRY
>>   in a lot more places?)  Wouldn't it be better to use just one
>>   PLTRY block?  For example, could you get away with just that one PLTRY
>>   block in the library initialization code? If so, the corresponding
>>   PLCATCH block there could write out a message saying you reached
>>   that catch block (to confirm that the whole exception handling system is
>>   fundamentally working within our C library), and then exit (for now)
>>   in just that one place rather than doing nothing about whatever
>>   PLplot library error was detected.
>
> I didn't check the API, but I thought that the naming convention was
> that every function beginning c_ is part of the public API. Is this
> not correct? EVERY public API function would need a PLTRY block. I
> only chose this file because it contains plenv, which was one of the
> first API functions called by x00c
>>
>> * I suggest you protect your exception handling code (but not the
>>   separate topic branch code concerning pl* versions of malloc,
>>   calloc, realloc, and free) with an PL_IMPLEMENT_EXCEPTION_HANDLING
>>   macro that is controlled (using #cmakedefine in plplot_config.h.in)
>>   by a cmake option in cmake/modules/plplot.cmake of the same name
>>   which defaults to OFF and which is self-documented as highly
>>   experimental. Once you do this, then it makes it possible to merge
>>   this topic quite rapidly to master (to facilitate further
>>   collaborative development of our exception handling system) since
>>   the user would have to go out of their way to set
>>   -DPL_IMPLEMENT_EXCEPTION_HANDLING=ON once they found
>>   PL_IMPLEMENT_EXCEPTION_HANDLING in CMakeCache.txt. And that file
>>   includes the self-documentation of each option so it should be
>>   obvious to such users that turning that option ON is highly
>>   experimental.
>
> Would you be happy to add this variable to the build system for me?
> Your cmake knowledge is  much better than mine. Or do I just use that
> macro and adding of -DPL_IMPLEMENT_EXCEPTION_HANDLING=ON to the
> command line automagically generate the equivalent #define.
>>
>> 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] First proof-of-concept versions of PLplot "memory allocation" and "exception handling" topics

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

Hi Alan
Please find attached a new patch series.

I should have fixed the segfault issue. Note I have done some rebasing
so you will probably need to create new branches. I think there is a
memory leak somewhere. I will look into this.

But you may have something you can play with to test a bit better now.
I have added specific comments below.


> I used "git am" apply your first two commits (which should be handled
> as a separate topic) cleanly to a private topic branch I created here
> called "memory_allocation".  That clean result was based on the tip of the
> current
> master branch.

That's good, as I said I have quite old source and didn't want to risk
introducing any changes in the build system that may have cost me time
as I only had a few hours to set this up and send it to you. I will
update once I get chance.

>
> I similarly applied your four commits cleanly to a private topic branch
> which
> I call "exception_handling".  i.e., I assumed for this topic branch
> the memory_allocation topic would be merged before the exception
> handling part of your commits, although I doubt that would be actually
> necessary, i.e., both these topics are completely independent of each
> other.

Yes, the memory management is independent of exception handling, but
exception handling requires memory management to avoid memory leaks.

>
> I extensively tested your "memory_allocation" topic as follows.
>
> I configured cmake with the option -DVALGRIND_ALL_TESTS=ON and built
> the test_c_psc target (which builds all our c standard examples
> for the psc device and runs them all using valgrind).  Those
> valgrind reports were perfect, i.e., the list of such
> reports without the phrases "no leaks are possible" and "0 errors from 0
> contexts") is empty as can be seen from
>
> software@raven> ls examples/*.log
> examples/valgrind.x00c.psc.log  examples/valgrind.x11c.psc.log
> examples/valgrind.x22c.psc.log
> examples/valgrind.x01c.psc.log  examples/valgrind.x12c.psc.log
> examples/valgrind.x23c.psc.log
> examples/valgrind.x02c.psc.log  examples/valgrind.x13c.psc.log
> examples/valgrind.x24c.psc.log
> examples/valgrind.x03c.psc.log  examples/valgrind.x14c.psc.log
> examples/valgrind.x25c.psc.log
> examples/valgrind.x04c.psc.log  examples/valgrind.x15c.psc.log
> examples/valgrind.x26c.psc.log
> examples/valgrind.x05c.psc.log  examples/valgrind.x16c.psc.log
> examples/valgrind.x27c.psc.log
> examples/valgrind.x06c.psc.log  examples/valgrind.x17c.psc.log
> examples/valgrind.x28c.psc.log
> examples/valgrind.x07c.psc.log  examples/valgrind.x18c.psc.log
> examples/valgrind.x29c.psc.log
> examples/valgrind.x08c.psc.log  examples/valgrind.x19c.psc.log
> examples/valgrind.x30c.psc.log
> examples/valgrind.x09c.psc.log  examples/valgrind.x20c.psc.log
> examples/valgrind.x31c.psc.log
> examples/valgrind.x10c.psc.log  examples/valgrind.x21c.psc.log
> examples/valgrind.x33c.psc.log
>
> and the empty results from
>
> software@raven> grep -L "no leaks are possible"
> examples/valgrind.x??c.psc.log
> software@raven> grep -L "0 errors from 0 contexts"
> examples/valgrind.x??c.psc.log

This is not surprising. I Don't think the plmalloc or plrealloc
functions are actually used anywhere yet :-D

>
> Furthermore, I like what you have done with plmalloc, plrealloc, and
> plfree where if inside those routines malloc, realloc, or free
> respectively fail, plexit is called with appropriate error message.
> Assuming, then you want to replace all our current direct calls to
> malloc, realloc and free with these pl* variants, this solves a major
> problem we have which was all the wide range of different treatments
> of how malloc, realloc and free errors were checked, i.e., in the best
> cases plexit is called, but more usually no error checking is done at
> all!

Not quite. Any pointers which we store in the plstream must use the
original malloc, otherwise they will be freed as soon as the API call
exits.
There are two options here.
1) Rely on developers to choose malloc or plmalloc as needed. But when
I looked through the code, it wasn't always obvious because there are
some places where memory is allocated in one bit of code, then the
assignment of the pointer in the plstream occurs somewhere else. I
think this is quite messy.
2) Have plfreeall check that the memory allocations do not correspond
to the pointers in plstream. This only requires that developers modify
plfreeall if they add a new heap pointer to plstream. it may be that
this is easy to miss as it would be done infrequently, but it would
probably very quickly generate a segfault or valgrind would spot it
easily.

My preference is I think for 2, but I welcome comments.

>
> So this is a most encouraging result.
>
> However, there are some issues with this topic branch that I noticed
>
> * This approach should be extended to calloc as well.

This is my lack of C (vs C++ knowledge). I didn't know calloc existed.
I'll add it.

>
> * You are not finished, e.g., I notice many direct calls to malloc
>   still within our code base.

I haven't even started the replacement of malloc with plmalloc.

>
> * The following two compile warnings need to be addressed:
>
> [ 18%] Building C object src/CMakeFiles/plplot.dir/plcore.c.o
> cd /home/software/plplot/HEAD/build_dir/src && /usr/lib/ccache/cc
> -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dplplot_EXPORTS -I/home/
> software/plplot/HEAD/plplot.git/include
> -I/home/software/plplot/HEAD/plplot.git/lib/qsastime
> -I/home/software/plplot/HEAD/buil
> d_dir -I/home/software/plplot/HEAD/build_dir/include  -O3
> -fvisibility=hidden -Wuninitialized -fPIC    -I/usr/include -o CMake
> Files/plplot.dir/plcore.c.o   -c
> /home/software/plplot/HEAD/plplot.git/src/plcore.c
> /home/software/plplot/HEAD/plplot.git/src/plcore.c: In function
> ‘plinitialisememorylist’:
> /home/software/plplot/HEAD/plplot.git/src/plcore.c:117:9: warning: ignoring
> return value of ‘realloc’, declared with attribute warn_unused_result
> [-Wunused-result]
>          realloc( pls->memorylist, n * sizeof ( void* ) );
>          ^
> /home/software/plplot/HEAD/plplot.git/src/plcore.c: In function ‘plmalloc’:
> /home/software/plplot/HEAD/plplot.git/src/plcore.c:140:9: warning: ignoring
> return value of ‘realloc’, declared with attribute warn_unused_result
> [-Wunused-result]
>          realloc( pls->memorylist, n * sizeof ( void* ) );
>          ^
>

Fixed

> * Once you feel you have completed development of this private topic
>   branch, then you should test it like I did above (assuming you have
>   good access to a Linux box or I could do that testing if you like
>   when the time comes), and assuming all the valgrind results are
>   still clean, then you should merge it to the master branch
>   completely independent of what happens with your exception handling
>   topic branch.
>
> That finishes the memory allocation topic, and I now want to move
> on to the exception handling topic.
>
> For that topic branch I built the x00c and ps targets OK (except for
> the memory allocation branchh code warnings I mentioned above), but
> that result segfaulted at run time, e.g.,
>
> software@raven> examples/c/x00c -dev psc -o test.psc
> Segmentation fault
Fixed

>
> Here are the valgrind results for this important memory management issue
>
> software@raven> valgrind examples/c/x00c -dev psc -o test.psc
> ==24594== Memcheck, a memory error detector
> ==24594== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==24594== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==24594== Command: examples/c/x00c -dev psc -o test.psc
> ==24594== ==24594== Conditional jump or move depends on uninitialised
> value(s)
> ==24594==    at 0x53F1EE5: longjmp (longjmp.c:32)
> ==24594==    by 0x4E840B0: c_plenv (in
> /home/software/plplot/HEAD/build_dir/src/libplplot.so.14.0.0)
> ==24594==    by 0x400858: main (in
> /home/software/plplot/HEAD/build_dir/examples/c/x00c)
> ==24594== ==24594== Warning: client switching stacks?  SP change:
> 0xffefffdc8 --> 0x3d8d115408920055
> ==24594==          to suppress, use: --max-stackframe=4435220191945818765 or
> greater
> ==24594== Use of uninitialised value of size 8
> ==24594==    at 0x53F1F52: __longjmp (__longjmp.S:60)
> ==24594== ==24594== Jump to the invalid address stated on the next line
> ==24594==    at 0x3D8D115408920055: ???
> ==24594==  Address 0x3d8d115408920055 is not stack'd, malloc'd or (recently)
> free'd
> ==24594== ==24594== ==24594== Process terminating with default action of
> signal 11 (SIGSEGV)
> ==24594==  Bad permissions for mapped region at address 0x3D8D115408920055
> ==24594==    at 0x3D8D115408920055: ???
> ==24594== Use of uninitialised value of size 8
> ==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
> ==24594== ==24594== Invalid write of size 8
> ==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
> ==24594==  Address 0x3d8d11540892004d is not stack'd, malloc'd or (recently)
> free'd
> ==24594== ==24594== ==24594== Process terminating with default action of
> signal 11 (SIGSEGV)
> ==24594==  General Protection Fault
> ==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
> ==24594== ==24594== HEAP SUMMARY:
> ==24594==     in use at exit: 76,682 bytes in 288 blocks
> ==24594==   total heap usage: 360 allocs, 72 frees, 124,441 bytes allocated
> ==24594== ==24594== LEAK SUMMARY:
> ==24594==    definitely lost: 0 bytes in 0 blocks
> ==24594==    indirectly lost: 0 bytes in 0 blocks
> ==24594==      possibly lost: 0 bytes in 0 blocks
> ==24594==    still reachable: 76,682 bytes in 288 blocks
> ==24594==         suppressed: 0 bytes in 0 blocks
> ==24594== Rerun with --leak-check=full to see details of leaked memory
> ==24594== ==24594== For counts of detected and suppressed errors, rerun
> with: -v
> ==24594== Use --track-origins=yes to see where uninitialised values come
> from
> ==24594== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
> Segmentation fault

I think at least some of this is due to the realloc issue above.
Hopefully some or all of this is fixed now. I would welcome another
valgrind summary.

>
> So you need to address this before we can do any extensive run-time testing
> of your exception handling ideas.  Of course, you did warn us that
> this code was quite preliminary so issues like above are to be
> expected. Furthermore, in my view, discussion of real code developers
> can try for themselves always beats discussion of code that doesn't
> exist yet. So I very much appreciate you supplying us with this
> preliminary exception handling code to focus our further discussion.
>
> I do have some general points to make from just looking at the broad
> picture of what you are trying to accomplish here with the exception
> handling macros PLTRY, PLCATCH, PLENDTRY, and PLTHROW.
>
> * There is currently no ability for PLTHROW to propagate an error message.
> Is
>   that a fundamental limitation of setjmp/longjmp based C exception
>   handling or could that feature be easily implemented?  If the latter,
>   then that gives us the option to use PLTHROW wherever errors occur
>   rather than always calling plexit which then prints the error
>   message before it uses PLTHROW.  So for example in plmalloc,
>   plcalloc, plrealloc, and plfree you could use PLTHROW directly
>   rather than calling plexit. However, if implementation of handling
>   error messages for PLTHROW is difficult/impossible, then I would be
>   content to call plexit everywhere so that there would only be one
>   PLTHROW (within plexit after printing out the error message) in our
>   code as now on this topic branch.

We could throw an error code, but I don't think an error message.
However, I think it would be better to put an error message/code in
the plstream. This would need to be on the heap rather than the stack
otherwise it would be lost in the stack unwinding. I think we should
maintain a function like plerror that would put the error code/message
onto the stream, but maybe renamed to be called something like plthrow

>
> * Can you explain why you have implemented all the PLTRY blocks
>   in src/plvpor.c (with presumably the idea in mind to use PLTRY
>   in a lot more places?)  Wouldn't it be better to use just one
>   PLTRY block?  For example, could you get away with just that one PLTRY
>   block in the library initialization code? If so, the corresponding
>   PLCATCH block there could write out a message saying you reached
>   that catch block (to confirm that the whole exception handling system is
>   fundamentally working within our C library), and then exit (for now)
>   in just that one place rather than doing nothing about whatever
>   PLplot library error was detected.

I didn't check the API, but I thought that the naming convention was
that every function beginning c_ is part of the public API. Is this
not correct? EVERY public API function would need a PLTRY block. I
only chose this file because it contains plenv, which was one of the
first API functions called by x00c
>
> * I suggest you protect your exception handling code (but not the
>   separate topic branch code concerning pl* versions of malloc,
>   calloc, realloc, and free) with an PL_IMPLEMENT_EXCEPTION_HANDLING
>   macro that is controlled (using #cmakedefine in plplot_config.h.in)
>   by a cmake option in cmake/modules/plplot.cmake of the same name
>   which defaults to OFF and which is self-documented as highly
>   experimental. Once you do this, then it makes it possible to merge
>   this topic quite rapidly to master (to facilitate further
>   collaborative development of our exception handling system) since
>   the user would have to go out of their way to set
>   -DPL_IMPLEMENT_EXCEPTION_HANDLING=ON once they found
>   PL_IMPLEMENT_EXCEPTION_HANDLING in CMakeCache.txt. And that file
>   includes the self-documentation of each option so it should be
>   obvious to such users that turning that option ON is highly
>   experimental.

Would you be happy to add this variable to the build system for me?
Your cmake knowledge is  much better than mine. Or do I just use that
macro and adding of -DPL_IMPLEMENT_EXCEPTION_HANDLING=ON to the
command line automagically generate the equivalent #define.
>
> 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] First proof-of-concept versions of PLplot "memory allocation" and "exception handling" topics

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

On 2017-07-16 11:43+0100 Phil Rosenberg wrote:

> Hi Alan et al
>
> Please find attached some patches that show some bare bones start to using
> setjmp and longjmp exception style error handling in plplot. Please have a
> look at the log for a detailed description of what is going on and how it
> works.
>
> What this is: A first start with enough code to show the basic principles
> of how this could work.
>
> What this isn't: A fully working version that should go anywhere near the
> actual repo. I have only tested to see if it compiles, builds and that x00c
> runs. In fact I get some tcl related exception on exit, which I'm not sure
> if I just caused or if it was there before.
>
> I am sending out this super early untested code that may still have major
> bugs and is based on whatever (quite old) plplot source I happened to have
> on my machine so that you can see the PRINCIPLES of how it works. And
> because I have other stuff on today so I might not get chance to look at
> this for a while and I know Alan was keen to see something asap. So feel
> free to be critical, but please not too critical :-)
>
> Alan, have a look, have a play. Thoughts welcome.

Hi Phil:

Thanks for responding so far beyond my request.

I used "git am" apply your first two commits (which should be handled
as a separate topic) cleanly to a private topic branch I created here
called "memory_allocation".  That clean result was based on the tip of the current
master branch.

I similarly applied your four commits cleanly to a private topic branch which
I call "exception_handling".  i.e., I assumed for this topic branch
the memory_allocation topic would be merged before the exception
handling part of your commits, although I doubt that would be actually
necessary, i.e., both these topics are completely independent of each
other.

I extensively tested your "memory_allocation" topic as follows.

I configured cmake with the option -DVALGRIND_ALL_TESTS=ON and built
the test_c_psc target (which builds all our c standard examples
for the psc device and runs them all using valgrind).  Those
valgrind reports were perfect, i.e., the list of such
reports without the phrases "no leaks are possible" and "0 errors from 0
contexts") is empty as can be seen from

software@raven> ls examples/*.log
examples/valgrind.x00c.psc.log  examples/valgrind.x11c.psc.log  examples/valgrind.x22c.psc.log
examples/valgrind.x01c.psc.log  examples/valgrind.x12c.psc.log  examples/valgrind.x23c.psc.log
examples/valgrind.x02c.psc.log  examples/valgrind.x13c.psc.log  examples/valgrind.x24c.psc.log
examples/valgrind.x03c.psc.log  examples/valgrind.x14c.psc.log  examples/valgrind.x25c.psc.log
examples/valgrind.x04c.psc.log  examples/valgrind.x15c.psc.log  examples/valgrind.x26c.psc.log
examples/valgrind.x05c.psc.log  examples/valgrind.x16c.psc.log  examples/valgrind.x27c.psc.log
examples/valgrind.x06c.psc.log  examples/valgrind.x17c.psc.log  examples/valgrind.x28c.psc.log
examples/valgrind.x07c.psc.log  examples/valgrind.x18c.psc.log  examples/valgrind.x29c.psc.log
examples/valgrind.x08c.psc.log  examples/valgrind.x19c.psc.log  examples/valgrind.x30c.psc.log
examples/valgrind.x09c.psc.log  examples/valgrind.x20c.psc.log  examples/valgrind.x31c.psc.log
examples/valgrind.x10c.psc.log  examples/valgrind.x21c.psc.log  examples/valgrind.x33c.psc.log

and the empty results from

software@raven> grep -L "no leaks are possible" examples/valgrind.x??c.psc.log
software@raven> grep -L "0 errors from 0 contexts" examples/valgrind.x??c.psc.log

Furthermore, I like what you have done with plmalloc, plrealloc, and
plfree where if inside those routines malloc, realloc, or free
respectively fail, plexit is called with appropriate error message.
Assuming, then you want to replace all our current direct calls to
malloc, realloc and free with these pl* variants, this solves a major
problem we have which was all the wide range of different treatments
of how malloc, realloc and free errors were checked, i.e., in the best
cases plexit is called, but more usually no error checking is done at
all!

So this is a most encouraging result.

However, there are some issues with this topic branch that I noticed

* This approach should be extended to calloc as well.

* You are not finished, e.g., I notice many direct calls to malloc
   still within our code base.

* The following two compile warnings need to be addressed:

[ 18%] Building C object src/CMakeFiles/plplot.dir/plcore.c.o
cd /home/software/plplot/HEAD/build_dir/src && /usr/lib/ccache/cc  -DPLPLOT_HAVE_CONFIG_H -DUSINGDLL -Dplplot_EXPORTS -I/home/
software/plplot/HEAD/plplot.git/include -I/home/software/plplot/HEAD/plplot.git/lib/qsastime -I/home/software/plplot/HEAD/buil
d_dir -I/home/software/plplot/HEAD/build_dir/include  -O3 -fvisibility=hidden -Wuninitialized -fPIC    -I/usr/include -o CMake
Files/plplot.dir/plcore.c.o   -c /home/software/plplot/HEAD/plplot.git/src/plcore.c
/home/software/plplot/HEAD/plplot.git/src/plcore.c: In function ‘plinitialisememorylist’:
/home/software/plplot/HEAD/plplot.git/src/plcore.c:117:9: warning: ignoring return value of ‘realloc’, declared with attribute warn_unused_result [-Wunused-result]
          realloc( pls->memorylist, n * sizeof ( void* ) );
          ^
/home/software/plplot/HEAD/plplot.git/src/plcore.c: In function ‘plmalloc’:
/home/software/plplot/HEAD/plplot.git/src/plcore.c:140:9: warning: ignoring return value of ‘realloc’, declared with attribute warn_unused_result [-Wunused-result]
          realloc( pls->memorylist, n * sizeof ( void* ) );
          ^

* Once you feel you have completed development of this private topic
   branch, then you should test it like I did above (assuming you have
   good access to a Linux box or I could do that testing if you like
   when the time comes), and assuming all the valgrind results are
   still clean, then you should merge it to the master branch
   completely independent of what happens with your exception handling
   topic branch.

That finishes the memory allocation topic, and I now want to move
on to the exception handling topic.

For that topic branch I built the x00c and ps targets OK (except for
the memory allocation branchh code warnings I mentioned above), but
that result segfaulted at run time, e.g.,

software@raven> examples/c/x00c -dev psc -o test.psc
Segmentation fault

Here are the valgrind results for this important memory management issue

software@raven> valgrind examples/c/x00c -dev psc -o test.psc
==24594== Memcheck, a memory error detector
==24594== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==24594== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==24594== Command: examples/c/x00c -dev psc -o test.psc
==24594== 
==24594== Conditional jump or move depends on uninitialised value(s)
==24594==    at 0x53F1EE5: longjmp (longjmp.c:32)
==24594==    by 0x4E840B0: c_plenv (in /home/software/plplot/HEAD/build_dir/src/libplplot.so.14.0.0)
==24594==    by 0x400858: main (in /home/software/plplot/HEAD/build_dir/examples/c/x00c)
==24594== 
==24594== Warning: client switching stacks?  SP change: 0xffefffdc8 --> 0x3d8d115408920055
==24594==          to suppress, use: --max-stackframe=4435220191945818765 or greater
==24594== Use of uninitialised value of size 8
==24594==    at 0x53F1F52: __longjmp (__longjmp.S:60)
==24594== 
==24594== Jump to the invalid address stated on the next line
==24594==    at 0x3D8D115408920055: ???
==24594==  Address 0x3d8d115408920055 is not stack'd, malloc'd or (recently) free'd
==24594== 
==24594== 
==24594== Process terminating with default action of signal 11 (SIGSEGV)
==24594==  Bad permissions for mapped region at address 0x3D8D115408920055
==24594==    at 0x3D8D115408920055: ???
==24594== Use of uninitialised value of size 8
==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
==24594== 
==24594== Invalid write of size 8
==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
==24594==  Address 0x3d8d11540892004d is not stack'd, malloc'd or (recently) free'd
==24594== 
==24594== 
==24594== Process terminating with default action of signal 11 (SIGSEGV)
==24594==  General Protection Fault
==24594==    at 0x4A236C0: _vgnU_freeres (vg_preloaded.c:58)
==24594== 
==24594== HEAP SUMMARY:
==24594==     in use at exit: 76,682 bytes in 288 blocks
==24594==   total heap usage: 360 allocs, 72 frees, 124,441 bytes allocated
==24594== 
==24594== LEAK SUMMARY:
==24594==    definitely lost: 0 bytes in 0 blocks
==24594==    indirectly lost: 0 bytes in 0 blocks
==24594==      possibly lost: 0 bytes in 0 blocks
==24594==    still reachable: 76,682 bytes in 288 blocks
==24594==         suppressed: 0 bytes in 0 blocks
==24594== Rerun with --leak-check=full to see details of leaked memory
==24594== 
==24594== For counts of detected and suppressed errors, rerun with: -v
==24594== Use --track-origins=yes to see where uninitialised values come from
==24594== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
Segmentation fault

So you need to address this before we can do any extensive run-time testing
of your exception handling ideas.  Of course, you did warn us that
this code was quite preliminary so issues like above are to be
expected. Furthermore, in my view, discussion of real code developers
can try for themselves always beats discussion of code that doesn't
exist yet. So I very much appreciate you supplying us with this
preliminary exception handling code to focus our further discussion.

I do have some general points to make from just looking at the broad
picture of what you are trying to accomplish here with the exception
handling macros PLTRY, PLCATCH, PLENDTRY, and PLTHROW.

* There is currently no ability for PLTHROW to propagate an error message. Is
   that a fundamental limitation of setjmp/longjmp based C exception
   handling or could that feature be easily implemented?  If the latter,
   then that gives us the option to use PLTHROW wherever errors occur
   rather than always calling plexit which then prints the error
   message before it uses PLTHROW.  So for example in plmalloc,
   plcalloc, plrealloc, and plfree you could use PLTHROW directly
   rather than calling plexit. However, if implementation of handling
   error messages for PLTHROW is difficult/impossible, then I would be
   content to call plexit everywhere so that there would only be one
   PLTHROW (within plexit after printing out the error message) in our
   code as now on this topic branch.

* Can you explain why you have implemented all the PLTRY blocks
   in src/plvpor.c (with presumably the idea in mind to use PLTRY
   in a lot more places?)  Wouldn't it be better to use just one
   PLTRY block?  For example, could you get away with just that one PLTRY
   block in the library initialization code? If so, the corresponding
   PLCATCH block there could write out a message saying you reached
   that catch block (to confirm that the whole exception handling system is
   fundamentally working within our C library), and then exit (for now)
   in just that one place rather than doing nothing about whatever
   PLplot library error was detected.

* I suggest you protect your exception handling code (but not the
   separate topic branch code concerning pl* versions of malloc,
   calloc, realloc, and free) with an PL_IMPLEMENT_EXCEPTION_HANDLING
   macro that is controlled (using #cmakedefine in plplot_config.h.in)
   by a cmake option in cmake/modules/plplot.cmake of the same name
   which defaults to OFF and which is self-documented as highly
   experimental. Once you do this, then it makes it possible to merge
   this topic quite rapidly to master (to facilitate further
   collaborative development of our exception handling system) since
   the user would have to go out of their way to set
   -DPL_IMPLEMENT_EXCEPTION_HANDLING=ON once they found
   PL_IMPLEMENT_EXCEPTION_HANDLING in CMakeCache.txt. And that file
   includes the self-documentation of each option so it should be
   obvious to such users that turning that option ON is highly
   experimental.

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] First proof-of-concept step requested to implement PLplot errorhandling

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

Hi Alan et al

Please find attached some patches that show some bare bones start to using
setjmp and longjmp exception style error handling in plplot. Please have a
look at the log for a detailed description of what is going on and how it
works.

What this is: A first start with enough code to show the basic principles
of how this could work.

What this isn't: A fully working version that should go anywhere near the
actual repo. I have only tested to see if it compiles, builds and that x00c
runs. In fact I get some tcl related exception on exit, which I'm not sure
if I just caused or if it was there before.

I am sending out this super early untested code that may still have major
bugs and is based on whatever (quite old) plplot source I happened to have
on my machine so that you can see the PRINCIPLES of how it works. And
because I have other stuff on today so I might not get chance to look at
this for a while and I know Alan was keen to see something asap. So feel
free to be critical, but please not too critical :-)

Alan, have a look, have a play. Thoughts welcome.

Phil



On 16 July 2017 at 00:24, <p.d...@gm...> wrote:

> Hi Alan
>
> Proof of concept was a little more than 20 or so lines 😉
>
>
>
> I'll pull out the code I started and check where is stands.
>
>
>
> Phil
>
>
>
> Sent from my Windows 10 phone
>
>
>
> *From: *Alan W. Irwin <ir...@be...>
> *Sent: *15 July 2017 21:50
> *To: *Phil Rosenberg <p.d...@gm...>; Ole Streicher
> <deb...@li...>
> *Cc: *Hazen Babcock <hba...@ma...>; and...@us...; PLplot
> development list <plp...@li...>
> *Subject: *First proof-of-concept step requested to implement PLplot
> errorhandling
>
>
>
> On 2017-07-15 11:49+0200 Ole Streicher wrote:
>
>
>
> > Another (probable longer-standing) topic would be the use of exit() in
>
> > several libraries in case of error. That usually has the disadvantage
>
> > that it makes debugging more complicated, since you don't get a
>
> > stacktrace; abort() may be the better solution here. Any thoughts about
>
> > that?
>
>
>
> To Phil and Ole (with CC to Hazen and Andrew):
>
>
>
> @Phil:
>
> There is a key question for you at the end.
>
>
>
> @Ole:
>
>
>
> Here is some background on the issue you brought up above.
>
>
>
> An even more important issue with exit that concerns PLplot developers
>
> is, for example, some poor guy has been working on some interactive
>
> session for 4 hours, (e.g., octave) and then attempts to finish up by
>
> plotting his results, but he makes a wrong PLplot call ==> exit, loses
>
> all those 4 hours of work!  Not pretty!
>
>
>
> The obvious solution is to implement a proper error handling system
>
> for the PLplot libraries, bindings libraries, and device drivers that
>
> avoids the use of exit and simply propagates an error condition to
>
> whatever library or user routine calls PLplot routines if something
>
> goes wrong anywhere in any of the PLplot-related source code.
>
>
>
> We have discussed here fairly recently the best way to implement such
>
> an error handling system. There have been two schools of thought about
>
> how we implement that which I will attempt to summarize here.
>
>
>
> 1. Implement our error handling using normal C methods.  That is,
>
> change our API to return an error code for each PLplot routine that
>
> can possibly have an error condition or which calls a PLplot routine
>
> that itself could have an error condition. (This turns out to be most
>
> PLplot-related routines).  Then those error conditions codes must be
>
> checked and propagated further if necessary after virtually all
>
> returns from PLplot routines that occur within the PLplot libraries,
>
> bindings libraries, and device drivers.
>
>
>
> 2. Implement our error handling system using longjmp and setjmp
>
>
>
> See <http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html>
>
> for an example of how to use those two C library routines (both
>
> available since c89 and also supported by Windows) to implement
>
> exception handling in C that is quite similar to exception handling in
>
> C++. I believe when Phil Rosenberg suggested a longjmp/setjmp based
>
> error handling system he was unaware of this example so his proposal
>
> likely varied in many details from this example.  But the overall
>
> principle was the same which is you can use these two functions to
>
> avoid the laborious process of having to propagate error codes via
>
> function return values.
>
>
>
> Andrew Ross and Hazen Babcock liked the first idea because it is the
>
> standard C way to implement error handling.  Phil and I liked the
>
> second idea because it is a lot less work (the PLplot call graphs are
>
> extraordinarily complex so there are potentially huge numbers of
>
> Plplot routine return values to check within the PLplot libraries,
>
> bindings libraries, and device drivers).
>
>
>
> The above reference on C exception handling mentioned an issue many C
>
> programmers have with longjmp/setjmp which is they are completely
>
> unfamiliar with their use.  And I think PLplot developers (including
>
> me) do indeed have such unfamiliarity concerns.  So to help us get
>
> more familiar with their use, I asked Phil the last time we discussed
>
> this to implement a simple proof of concept of his idea (e.g., a
>
> modification of plexit that unwinds the stack and delivers an error
>
> message to a single convenient place in our PLplot core library
>
> (likely our library initialization) where setjmp is called to set
>
> everything up.) I suspect Phil just plain forgot about that request
>
> due to other time pressures on him so I am taking this opportunity to
>
> make that request again.  :-)
>
>
>
> @Phil:
>
>
>
> I am still just as unfamiliar (except for what I read in man pages) as
>
> the rest of our developers with longjmp/setjmp. So are you game to
>
> implement such a simple proof-of-concept to help us become more
>
> familiar with those two routines?
>
>
>
> If so, how about dealing with it right away (after all, I think we are
>
> only dealing with something like ~20 lines of code) to avoid losing it
>
> again in your stack of PLplot e-mail? This variant of plexit should
>
> only be compiled if the user specifies the -DHAVE_ERROR_HANDLING=ON
>
> experimental CMake option which should default to NO to provide
>
> sufficient safety that if you act fast you can safely merge this with
>
> the master branch in time for the 5.13.0 release.
>
>
>
> The goal of such a simple proof of concept would merely be to confirm
>
> the stack was properly unwound by longjmp with a message right after
>
> the single place in the PLplot library that you call setjmp during
>
> library initialization.  If that call returns 0 (i.e., it is the
>
> initial call made during library initialization) then no message would
>
> be generated, but it it returns non-zero (i.e, the result of longjmp)
>
> then generate a "this proof-of-concept is working" message before (for
>
> now) exiting just like ordinary plexit does.  So this simple proof of
>
> concept would be restricted to inside the PLplot core library, and the
>
> gory details of how to propagate error reporting across the boundaries
>
> of our PLplot libraries, bindings library, and device drivers would be
>
> ignored for now.  Of course, this proof of concept would be far from a
>
> full solution for our much needed error handling system, but it could
>
> be a very important first step in achieving that important PLplot
>
> goal.  So how about taking that first step now?
>
>
>
> 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] First proof-of-concept step requested to implement PLplot errorhandling

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

On 2017-07-16 00:24+0100 p.d...@gm... wrote:

> Hi Alan
> Proof of concept was a little more than 20 or so lines 😉
>
> I'll pull out the code I started and check where is stands.

Sounds 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] First proof-of-concept step requested to implement PLplot errorhandling

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

Hi Alan
Proof of concept was a little more than 20 or so lines 😉

I'll pull out the code I started and check where is stands.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 15 July 2017 21:50
To: Phil Rosenberg; Ole Streicher
Cc: Hazen Babcock; and...@us...; PLplot development list
Subject: First proof-of-concept step requested to implement PLplot errorhandling

On 2017-07-15 11:49+0200 Ole Streicher wrote:

> Another (probable longer-standing) topic would be the use of exit() in
> several libraries in case of error. That usually has the disadvantage
> that it makes debugging more complicated, since you don't get a
> stacktrace; abort() may be the better solution here. Any thoughts about
> that?

To Phil and Ole (with CC to Hazen and Andrew):

@Phil:
There is a key question for you at the end.

@Ole:

Here is some background on the issue you brought up above.

An even more important issue with exit that concerns PLplot developers
is, for example, some poor guy has been working on some interactive
session for 4 hours, (e.g., octave) and then attempts to finish up by
plotting his results, but he makes a wrong PLplot call ==> exit, loses
all those 4 hours of work!  Not pretty!

The obvious solution is to implement a proper error handling system
for the PLplot libraries, bindings libraries, and device drivers that
avoids the use of exit and simply propagates an error condition to
whatever library or user routine calls PLplot routines if something
goes wrong anywhere in any of the PLplot-related source code.

We have discussed here fairly recently the best way to implement such
an error handling system. There have been two schools of thought about
how we implement that which I will attempt to summarize here.

1. Implement our error handling using normal C methods.  That is,
change our API to return an error code for each PLplot routine that
can possibly have an error condition or which calls a PLplot routine
that itself could have an error condition. (This turns out to be most
PLplot-related routines).  Then those error conditions codes must be
checked and propagated further if necessary after virtually all
returns from PLplot routines that occur within the PLplot libraries,
bindings libraries, and device drivers.

2. Implement our error handling system using longjmp and setjmp

See <http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html>
for an example of how to use those two C library routines (both
available since c89 and also supported by Windows) to implement
exception handling in C that is quite similar to exception handling in
C++. I believe when Phil Rosenberg suggested a longjmp/setjmp based
error handling system he was unaware of this example so his proposal
likely varied in many details from this example.  But the overall
principle was the same which is you can use these two functions to
avoid the laborious process of having to propagate error codes via
function return values.

Andrew Ross and Hazen Babcock liked the first idea because it is the
standard C way to implement error handling.  Phil and I liked the
second idea because it is a lot less work (the PLplot call graphs are
extraordinarily complex so there are potentially huge numbers of
Plplot routine return values to check within the PLplot libraries,
bindings libraries, and device drivers).

The above reference on C exception handling mentioned an issue many C
programmers have with longjmp/setjmp which is they are completely
unfamiliar with their use.  And I think PLplot developers (including
me) do indeed have such unfamiliarity concerns.  So to help us get
more familiar with their use, I asked Phil the last time we discussed
this to implement a simple proof of concept of his idea (e.g., a
modification of plexit that unwinds the stack and delivers an error
message to a single convenient place in our PLplot core library
(likely our library initialization) where setjmp is called to set
everything up.) I suspect Phil just plain forgot about that request
due to other time pressures on him so I am taking this opportunity to
make that request again.  :-)

@Phil:

I am still just as unfamiliar (except for what I read in man pages) as
the rest of our developers with longjmp/setjmp. So are you game to
implement such a simple proof-of-concept to help us become more
familiar with those two routines?

If so, how about dealing with it right away (after all, I think we are
only dealing with something like ~20 lines of code) to avoid losing it
again in your stack of PLplot e-mail? This variant of plexit should
only be compiled if the user specifies the -DHAVE_ERROR_HANDLING=ON
experimental CMake option which should default to NO to provide
sufficient safety that if you act fast you can safely merge this with
the master branch in time for the 5.13.0 release.

The goal of such a simple proof of concept would merely be to confirm
the stack was properly unwound by longjmp with a message right after
the single place in the PLplot library that you call setjmp during
library initialization.  If that call returns 0 (i.e., it is the
initial call made during library initialization) then no message would
be generated, but it it returns non-zero (i.e, the result of longjmp)
then generate a "this proof-of-concept is working" message before (for
now) exiting just like ordinary plexit does.  So this simple proof of
concept would be restricted to inside the PLplot core library, and the
gory details of how to propagate error reporting across the boundaries
of our PLplot libraries, bindings library, and device drivers would be
ignored for now.  Of course, this proof of concept would be far from a
full solution for our much needed error handling system, but it could
be a very important first step in achieving that important PLplot
goal.  So how about taking that first step now?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-15 14:43-0700 Alan W. Irwin wrote:

> There is
> <http://www.linux-magazin.de/ausgabe/1996/12/Plplot/plplot.html>, but
> that link is now broken, the linux magazin search function cannot find
> it, I never understood that article because it was written in German,
> and by now it would be completely out of date in any case. Note to
> self: remove that link from our documentation.

P.S.

Actually, if you can read German and are curious about what PLplot
looked like two (!) decades ago, I did find that broken link on the internet archive,
<http://web.archive.org/web/20020624083333/www.linux-magazin.de/ausgabe/1996/12/Plplot/plplot.html>.
But that is clearly not our preferred citation, and I do plan to remove
that broken link from our documentation and not replace it with
the internet archive version.

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-15 20:49+0200 Ole Streicher wrote:

> Hi Alan,
>
> On 15.07.2017 20:37, Alan W. Irwin wrote:
>> Sometimes our bindings libraries have the same core name (e.g.,
>> wxwidgets, qt) as the device driver, but bindings libraries and
>> device drivers are completely different and there is no chance of a
>> nameclash between them.  So there should be no issue of concern in
>> this case.
>
> My question here is mainly if they should reside in the same package. As
> far as I understand you, they should go into separate packages.

To explain further we have three major configuration modes

1. The default (-DBUILD_SHARED_LIBS=ON, -DENABLE_DYNDRIVERS=ON) which
builds shared PLplot libraries and dynamically
loaded (separate) devices.

2. Shared PLplot libraries (-DBUILD_SHARED_LIBS=ON) and nondynamic devices (-DENABLE_DYNDRIVERS=OFF)
where the C and C++ device driver
code is made part of our core library.

3. Static PLplot libraries (-DBUILD_SHARED_LIBS=OFF which forces
-DENABLE_DYNDRIVERS=OFF)

We continue to maintain 2 for historical reasons, and probably the
same could be said of 3.  But from your question I assume you are using
1.

Furthermore, your question inspired me to look at the
-DDEFAULT_NO_DEVICES=ON case (for 1 although case 2 and 3 should give
similar results).  For that case (and assuming you do not specify any
devices to build which is what I did) the library and examples build
without issues, but they are useless.  Here is an example of what
happens:

software@raven> examples/c/x00c

*** PLPLOT ERROR, IMMEDIATE EXIT ***
No device drivers found - please check the environment variable
PLPLOT_DRV_DIR
Program aborted

So it is your call as packager, but you should be aware for case 1 if
you do split up the library and dynamic devices, and a user installs
only the library, that library will be essentially useless.

Of course, I just noticed the above warning message when no device
drivers are installed is pretty useless/misleading, but I don't want
to deal with that now so if someone wants to send a patch....

> Another small question: We maintain some metadata about our packages,
> and one of the entries is the preferred citation. Is there a paper that
> should serve as a reference for plplot?

There is
<http://www.linux-magazin.de/ausgabe/1996/12/Plplot/plplot.html>, but
that link is now broken, the linux magazin search function cannot find
it, I never understood that article because it was written in German,
and by now it would be completely out of date in any case. Note to
self: remove that link from our documentation.

Another slightly better possibility (but still bad) is users have
created the Wikipedia article https://en.wikipedia.org/wiki/PLplot,
but that is already quite dated (e.g., it refers to our subversion
repository!) and is seriously incomplete, i.e., it simply copies a
small subset of an extremely dated copy of the plplot.sourceforge.net website
which I assume your metadata already refers to as our home page.

So I think the best answer to your question in the short term is no,
you should leave the "preferred citation" metadata empty.

But in the long-term I think it is important for one of the PLplot
developers or heavily interested users to write up PLplot in an
accessible article simply to give some much-needed publicity to this
quite useful plotting solution.  Any volunteers?

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] First proof-of-concept step requested to implement PLplot error handling

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

On 2017-07-15 11:49+0200 Ole Streicher wrote:

> Another (probable longer-standing) topic would be the use of exit() in
> several libraries in case of error. That usually has the disadvantage
> that it makes debugging more complicated, since you don't get a
> stacktrace; abort() may be the better solution here. Any thoughts about
> that?

To Phil and Ole (with CC to Hazen and Andrew):

@Phil:
There is a key question for you at the end.

@Ole:

Here is some background on the issue you brought up above.

An even more important issue with exit that concerns PLplot developers
is, for example, some poor guy has been working on some interactive
session for 4 hours, (e.g., octave) and then attempts to finish up by
plotting his results, but he makes a wrong PLplot call ==> exit, loses
all those 4 hours of work!  Not pretty!

The obvious solution is to implement a proper error handling system
for the PLplot libraries, bindings libraries, and device drivers that
avoids the use of exit and simply propagates an error condition to
whatever library or user routine calls PLplot routines if something
goes wrong anywhere in any of the PLplot-related source code.

We have discussed here fairly recently the best way to implement such
an error handling system. There have been two schools of thought about
how we implement that which I will attempt to summarize here.

1. Implement our error handling using normal C methods.  That is,
change our API to return an error code for each PLplot routine that
can possibly have an error condition or which calls a PLplot routine
that itself could have an error condition. (This turns out to be most
PLplot-related routines).  Then those error conditions codes must be
checked and propagated further if necessary after virtually all
returns from PLplot routines that occur within the PLplot libraries,
bindings libraries, and device drivers.

2. Implement our error handling system using longjmp and setjmp

See <http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html>
for an example of how to use those two C library routines (both
available since c89 and also supported by Windows) to implement
exception handling in C that is quite similar to exception handling in
C++. I believe when Phil Rosenberg suggested a longjmp/setjmp based
error handling system he was unaware of this example so his proposal
likely varied in many details from this example.  But the overall
principle was the same which is you can use these two functions to
avoid the laborious process of having to propagate error codes via
function return values.

Andrew Ross and Hazen Babcock liked the first idea because it is the
standard C way to implement error handling.  Phil and I liked the
second idea because it is a lot less work (the PLplot call graphs are
extraordinarily complex so there are potentially huge numbers of
Plplot routine return values to check within the PLplot libraries,
bindings libraries, and device drivers).

The above reference on C exception handling mentioned an issue many C
programmers have with longjmp/setjmp which is they are completely
unfamiliar with their use.  And I think PLplot developers (including
me) do indeed have such unfamiliarity concerns.  So to help us get
more familiar with their use, I asked Phil the last time we discussed
this to implement a simple proof of concept of his idea (e.g., a
modification of plexit that unwinds the stack and delivers an error
message to a single convenient place in our PLplot core library
(likely our library initialization) where setjmp is called to set
everything up.) I suspect Phil just plain forgot about that request
due to other time pressures on him so I am taking this opportunity to
make that request again.  :-)

@Phil:

I am still just as unfamiliar (except for what I read in man pages) as
the rest of our developers with longjmp/setjmp. So are you game to
implement such a simple proof-of-concept to help us become more
familiar with those two routines?

If so, how about dealing with it right away (after all, I think we are
only dealing with something like ~20 lines of code) to avoid losing it
again in your stack of PLplot e-mail? This variant of plexit should
only be compiled if the user specifies the -DHAVE_ERROR_HANDLING=ON
experimental CMake option which should default to NO to provide
sufficient safety that if you act fast you can safely merge this with
the master branch in time for the 5.13.0 release.

The goal of such a simple proof of concept would merely be to confirm
the stack was properly unwound by longjmp with a message right after
the single place in the PLplot library that you call setjmp during
library initialization.  If that call returns 0 (i.e., it is the
initial call made during library initialization) then no message would
be generated, but it it returns non-zero (i.e, the result of longjmp)
then generate a "this proof-of-concept is working" message before (for
now) exiting just like ordinary plexit does.  So this simple proof of
concept would be restricted to inside the PLplot core library, and the
gory details of how to propagate error reporting across the boundaries
of our PLplot libraries, bindings library, and device drivers would be
ignored for now.  Of course, this proof of concept would be far from a
full solution for our much needed error handling system, but it could
be a very important first step in achieving that important PLplot
goal.  So how about taking that first step now?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

Hi Alan,

On 15.07.2017 20:37, Alan W. Irwin wrote:
> Sometimes our bindings libraries have the same core name (e.g.,
> wxwidgets, qt) as the device driver, but bindings libraries and
> device drivers are completely different and there is no chance of a
> nameclash between them.  So there should be no issue of concern in
> this case.

My question here is mainly if they should reside in the same package. As
far as I understand you, they should go into separate packages.

Another small question: We maintain some metadata about our packages,
and one of the entries is the preferred citation. Is there a paper that
should serve as a reference for plplot?

For the other points, I will just wait until 5.13.0 is out.

Best regards

Ole

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-15 11:49+0200 Ole Streicher wrote:

Hi Ole:

I feel that most of the issues you have brought up such as
installation directories and spelling are ones we should be able to
address fairly quickly so expect to see some commits from me over
the next few days dealing with them.  So my responses here will
be limited to the topics you have brought up which I feel are not issues or which
are issues that will take a long time to resolve.

> Then, the qt and wxwidgets drivers contain *two* shared libraries: one
> in the drivers subdir, and one in the normal libdir:
>
> $INSTALL_LIBDIR/libplplotwxwidgets.so.1.2.0
> $INSTALL_LIBDIR/plplot5.12.0/drivers/wxwidgets.so

> What is the reason for that? Has the libplplotwxwidgets.so.1.2.0 an
> independent use case (and should therefore separate into its own
> package)? Or could they in principle both combined into wxwidgets.so?

We name our libraries with a "lib" prefix and install them in our
designated library location.  By default (although other options are
possible) we implement our device drivers as dynamically loaded shared
objects (dll's) whose names do not have the lib prefix, and which are
installed in our designated drivers location.  So the examples above
are our wxwidgets binding library (which allows a wxwidgets GUI to
call PLplot routines) and our wxwidgets device driver (which allows
our C library to dynamically load that device which uses a wxwidgets
GUI to display our plots).  Sometimes our bindings libraries have the
same core name (e.g., wxwidgets, qt) as the device driver, but
bindings libraries and device drivers are completely different and
there is no chance of a nameclash between them.  So there should be no
issue of concern in this case.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

Hi Alan,

thanks for the answers, and thanks for connecting with Orion. I hope to
keep everything together here.

> Yes.  We have long since implemented a CMake-based build system for
> the installed example source code + installed binary libraries that
> implements the test_diff_psc, etc., targets that also are implemented
> for our core build system.  See examples/CMakeLists.txt for details.

OK, thanks I will have a look. Should be solvable, and will help to get
early warnings in case of incompatibilities.

> Anyhow, if you and Ole don't want to mess with this issue, I will take it
> up myself once I get my hands on octave-4 (i.e., post-release).  And
> hopefully this time I will find octave developers who are more aware
> of the power of UTF-8.

I will contact the swig maintainers and probably open a bug for them.
For the UTF-8 problem, I would just wait for you (and re-enable the
ocave package when it is solved).

With the Debian specific nitpicker ("lintian"), I found a few more small
issues: First (again) tcl/tk: Currently, the shared libs are in
$INSTALL_LIBDIR, while for Debian they should be in the arch dependent
tcltk path (/usr/lib/tcltk/$ARCH/plplot5.12.0/). And for simplicity, the
tcl files themself could also live there. Is there a way to configure
that? (@orion: how is this done in Fedora?)

Then, the qt and wxwidgets drivers contain *two* shared libraries: one
in the drivers subdir, and one in the normal libdir:

$INSTALL_LIBDIR/libplplotwxwidgets.so.1.2.0
$INSTALL_LIBDIR/plplot5.12.0/drivers/wxwidgets.so

What is the reason for that? Has the libplplotwxwidgets.so.1.2.0 an
independent use case (and should therefore separate into its own
package)? Or could they in principle both combined into wxwidgets.so?

Another (probable longer-standing) topic would be the use of exit() in
several libraries in case of error. That usually has the disadvantage
that it makes debugging more complicated, since you don't get a
stacktrace; abort() may be the better solution here. Any thoughts about
that?

And, finally, there are a few spelling errors found by lintian:
 directorys -> directories
 Continous -> Continuous
 argment -> argument
 argments -> arguments

Best regards

Ole

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-14 14:48-0600 Orion Poplawski wrote:

>> @Orion:
>>
>> Can you confirm that PLplot now works well with Octave-4.2 on Fedora
>> or is there additional issues to deal with?
>
> Well, it compiles.  There are longstanding test failures though:
>
> 5:
> 5: *** PLPLOT ERROR, ABORTING OPERATION ***
> 5: UTF-8 string is malformed: ???M??????, aborting operation
>
> Check out a build log from:
> https://apps.fedoraproject.org/koschei/package/plplot?collection=f27

Hi Orion:

Just before sending this off, I looked in detail at the above error
log but could not find the above error there.  So it may be solved,
it may be obscured by another issue now, or I may have misread
the above build log.

Anyhow, the rest of this post assumes the above error is still an
issue for octave-4.2.x, but it would be interesting for Ole to confirm
that as well (once he gets the swig issue sorted out).

The PLplot core library assumes all user-supplied strings are encoded
in UTF-8, and then it converts those to UCS4 for internal use.  And
the above error message is a result of that converter tool detecting
some user input that is not encoded in UTF-8.

That process works fine for octave-3.8.2.  UTF-8 user strings are
passed from octave to our dynamically loaded octave binding shared
object which then passes those on to our own PLplot
library to do the conversion to UCS4 with success.

So I suspect that a backwards incompatibility was introduced into
octave-4.x.y (or perhaps octave-4.2.x if 4.0.x worked fine for Fedora)
so that it molests UTF-8 strings in some way so that whenever these
molested strings are transmitted to our octave binding shared
object/core PLplot library that latter library detects an invalid
UTF-8 input string (as above).

I have had troubles before with octave and UTF-8 (see
<http://octave.1599824.n4.nabble.com/utf8-does-not-appear-to-work-for-function-documentation-strings-generated-with-texinfo-td4663317.html>)
That issue was (eventually) satisfactorily resolved, but I was
surprised at how little Octave developers knew about UTF-8 back then
(3 years ago). For example, some of them felt you must use wide
characters to store UTF-8 which is completely incorrect; it is
designed to be stored as a string of 8-bit bytes.  Also, their
documentation translation teams seemed unaware of UTF-8.  For example,
they felt they had to be dependent on wide characters for their
translation of their English documentation strings into other human
languages.

Anyhow, if you and Ole don't want to mess with this issue, I will take it
up myself once I get my hands on octave-4 (i.e., post-release).  And
hopefully this time I will find octave developers who are more aware
of the power of UTF-8.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

Hello all

On 07/14/2017 02:18 PM, Alan W. Irwin wrote:
> To Ole and Orion:
> 
> @Ole:
> 
> To introduce Orion, he maintains the packaging of PLplot for Fedora,
> and he has been a big help to us when dealing with "library
> version" issues.
> 
> @Orion:
> 
> To introduce Ole, he is the new maintainer of PLplot packaging for
> Debian, and it appears he has been running into some "library
> version" issues (at least in the Octave-4.2 case) that you have also
> run into in the past.
> 
> On 2017-07-14 09:40+0200 Ole Streicher wrote:
> 
>> On 13.07.2017 21:49, Alan W. Irwin wrote:
>> [Octave bindings]
>>> So I suggest you try enabling it, and then follow up with a build of
>>> the test_diff_psc target. If that test works, i.e., it produces the
>>> good octave results above, then I think you can be pretty confident
>>> all is well with an octave4 binding of PLplot.
>>
>> I tried, but then I got many error about op_lshift:
>>
>> [ 10%] Building CXX object
>> bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
>> cd /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave &&
>> /usr/bin/c++   -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS
>> -I/build/plplot-5.12.0+dfsg/include -I/build/plplot-5.12.0+dfsg/lib/qsastime
>> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu
>> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/include
>> -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave
>> -I/usr/include/hdf5/serial -I/usr/include/octave-4.2.1
>> -I/usr/include/octave-4.2.1/octave
>> -I/build/plplot-5.12.0+dfsg/bindings/swig-support  -g -O2
>> -fdebug-prefix-map=/build/plplot-5.12.0+dfsg=. -fstack-protector-strong
>> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
>> -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave
>> -I/usr/include/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2
>> -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave
>> -I/usr/include/hdf5/serial -fPIC   -o
>> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c
>> /build/plplot-5.1!
> 2.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
>> In file included from
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0:
>>
>> /usr/include/octave-4.2.1/octave/toplev.h:28:2: warning: #warning "toplev.h
>> has been deprecated; use interpreter.h instead" [-Wcpp]
>> #warning "toplev.h has been deprecated; use interpreter.h instead"
>>  ^~~~~~~
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
>> In function 'void SWIG_InstallBinaryOps(int, int)':
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46:
>> error: 'op_lshift' is not a member of 'octave_value'
>> if
>> (!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \
>>                                              ^
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5:
>> note: in expansion of macro 'swigreg_binary_op'
>>     swigreg_binary_op(lshift);
>>     ^~~~~~~~~~~~~~~~~
>>
>> and a number of warnings about octave_value::octave_value:
>>
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
>> In function 'octave_value_list _wrap_plGetCursor(const octave_value_list&,
>> int)':
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:10770:60:
>> warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is
>> deprecated: note: IS_STRING argument is ignored [-Wdeprecated-declarations]
>>     retval4( 0 ) = octave_value( charMatrix( 80, 1 ), true );
>>                                                            ^
>> In file included from /usr/include/octave-4.2.1/octave/ovl.h:36:0,
>>                 from /usr/include/octave-4.2.1/octave/ov-fcn.h:33,
>>                 from /usr/include/octave-4.2.1/octave/ov-builtin.h:30,
>>                 from /usr/include/octave-4.2.1/octave/defun-int.h:30,
>>                 from /usr/include/octave-4.2.1/octave/defun-dld.h:32,
>>                 from /usr/include/octave-4.2.1/octave/oct.h:32,
>>                 from
>> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:173:
>>
>> /usr/include/octave-4.2.1/octave/ov.h:244:3: note: declared here
>>   octave_value (const charMatrix& chm, bool is_string, char type = '\'');
>>   ^~~~~~~~~~~~
>>
>> So it does not build in the moment.
> 
> It appears Orion has been here before you.  A google search for the
> above error message found <https://github.com/swig/swig/issues/847>
> where it appears this Octave-4.2 issue was fixed in swig-3.0.12.  In
> Fedora's case at that time, it appears they did not have access to
> swig-3.0.12 so they backported the fix to the version of swig they had
> at that time.  So if you can confirm (by building swig-3.0.12 for
> yourself) that swig-3.0.12 does fix the above issue, then you should
> talk to the Debian packagers for swig to see how they want to address
> this swig issue.
> 
> @Orion:
> 
> Can you confirm that PLplot now works well with Octave-4.2 on Fedora
> or is there additional issues to deal with?

Well, it compiles.  There are longstanding test failures though:

5:
5: *** PLPLOT ERROR, ABORTING OPERATION ***
5: UTF-8 string is malformed: �M��, aborting operation

Check out a build log from:
https://apps.fedoraproject.org/koschei/package/plplot?collection=f27

Octave tests are run at the end an errors ignored.

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

Re: [Plplot-devel] PLplot Debian package

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

To Ole and Orion:

@Ole:

To introduce Orion, he maintains the packaging of PLplot for Fedora,
and he has been a big help to us when dealing with "library
version" issues.

@Orion:

To introduce Ole, he is the new maintainer of PLplot packaging for
Debian, and it appears he has been running into some "library
version" issues (at least in the Octave-4.2 case) that you have also
run into in the past.

On 2017-07-14 09:40+0200 Ole Streicher wrote:

> On 13.07.2017 21:49, Alan W. Irwin wrote:
>> Excellent. However, too be sure all is well with Ada and the other
>> computer languages we support you should build the test_diff_psc
>> target (which compares the plot output files for our psc device for
>> all our standard examples for all our supported languages (including
>> octave) with the equivalent C results.
>

> I will do that. One question/proposal: is it possible to have the
tests also done on the _installed_ libraries? The rationale behind
this is that I would like to enable Continuous Integration Tests
> https://ci.debian.net/doc
> for the package. This would give a warning whenever an incompatible
upload for a language binding (or wherever) happens, not only when a
(occasional) rebuild is done. This early warning would also enable to
early discuss the problems with the maintainers of the other packages.

@Ole:

Yes.  We have long since implemented a CMake-based build system for
the installed example source code + installed binary libraries that
implements the test_diff_psc, etc., targets that also are implemented
for our core build system.  See examples/CMakeLists.txt for details.

One caveat is I have not yet implemented ctest for that install-tree
build system, but that is on my agenda since ctest is an excellent
way to do continuous integration testing.

Note that many years ago (even long before we ever looked at CMake) we
implemented a GNU-make + pkg-config "traditional" build system for the
installed examples, and we continue to maintain that in a minimal way.
However, for continuous integration testing you will likely want to
focus on our CMake-based build system for the installed examples.

>
> [Octave bindings]
>> So I suggest you try enabling it, and then follow up with a build of
>> the test_diff_psc target. If that test works, i.e., it produces the
>> good octave results above, then I think you can be pretty confident
>> all is well with an octave4 binding of PLplot.
>
> I tried, but then I got many error about op_lshift:
>
> [ 10%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
> cd /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave && /usr/bin/c++   -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS -I/build/plplot-5.12.0+dfsg/include -I/build/plplot-5.12.0+dfsg/lib/qsastime -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/include -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave -I/usr/include/hdf5/serial -I/usr/include/octave-4.2.1 -I/usr/include/octave-4.2.1/octave -I/build/plplot-5.12.0+dfsg/bindings/swig-support  -g -O2 -fdebug-prefix-map=/build/plplot-5.12.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave -I/usr/include/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave -I/usr/include/hdf5/serial -fPIC   -o CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
> In file included from /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0:
> /usr/include/octave-4.2.1/octave/toplev.h:28:2: warning: #warning "toplev.h has been deprecated; use interpreter.h instead" [-Wcpp]
> #warning "toplev.h has been deprecated; use interpreter.h instead"
>  ^~~~~~~
> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'void SWIG_InstallBinaryOps(int, int)':
> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46: error: 'op_lshift' is not a member of 'octave_value'
> if (!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \
>                                              ^
> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5: note: in expansion of macro 'swigreg_binary_op'
>     swigreg_binary_op(lshift);
>     ^~~~~~~~~~~~~~~~~
>
> and a number of warnings about octave_value::octave_value:
>
> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'octave_value_list _wrap_plGetCursor(const octave_value_list&, int)':
> /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:10770:60: warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is deprecated: note: IS_STRING argument is ignored [-Wdeprecated-declarations]
>     retval4( 0 ) = octave_value( charMatrix( 80, 1 ), true );
>                                                            ^
> In file included from /usr/include/octave-4.2.1/octave/ovl.h:36:0,
>                 from /usr/include/octave-4.2.1/octave/ov-fcn.h:33,
>                 from /usr/include/octave-4.2.1/octave/ov-builtin.h:30,
>                 from /usr/include/octave-4.2.1/octave/defun-int.h:30,
>                 from /usr/include/octave-4.2.1/octave/defun-dld.h:32,
>                 from /usr/include/octave-4.2.1/octave/oct.h:32,
>                 from /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:173:
> /usr/include/octave-4.2.1/octave/ov.h:244:3: note: declared here
>   octave_value (const charMatrix& chm, bool is_string, char type = '\'');
>   ^~~~~~~~~~~~
>
> So it does not build in the moment.

It appears Orion has been here before you.  A google search for the
above error message found <https://github.com/swig/swig/issues/847>
where it appears this Octave-4.2 issue was fixed in swig-3.0.12.  In
Fedora's case at that time, it appears they did not have access to
swig-3.0.12 so they backported the fix to the version of swig they had
at that time.  So if you can confirm (by building swig-3.0.12 for
yourself) that swig-3.0.12 does fix the above issue, then you should
talk to the Debian packagers for swig to see how they want to address
this swig issue.

@Orion:

Can you confirm that PLplot now works well with Octave-4.2 on Fedora
or is there additional issues to deal with?

>
>> The fundamental problem, of course, (since I am the person with
>> probably the most PLplot development knowledge) is I need to upgrade
>> from Debian Jessie to Debian Stretch (now that the latter has been
>> released as the stable version of Debian), and then tackle such
>> PLplot dependency version issues that remain. So I plan to do that
>> after the release of 5.13.0. But any help you can supply for more
>> modern Debian versions than the one I am using now would be quite
>> helpful.
>

> What I would recommend here is "schroot", which is a Debian package.
It allows you to test multiple versions of the OS at the same; for
example Stretch (or the Debian testing) on a Debian Jessie machine.
The home dir keeps mounted, and so one can easily switch between
different Debian versions quickly, and you don't destroy the main
setup for a test.

Thanks for that suggestion which looks like exactly what I need.

@Orion and Ole:

My principal focus right now is to get 5.13.0 out the door in a timely
manner. So my current plan is to make that release, install Debian
Stretch from scratch, and deal with any new PLplot "library version"
issues that show up for that distribution.  Then install schroot and
deal with any additional such issues that show up on Testing and
Unstable.  But help from you guys with such testing and fixing of
PLplot against the latest versions of libraries would be much
appreciated as well.  And we have not yet done a code freeze for
5.13.0 so your patches for fixes to get into 5.13.0 would be welcome.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

On 13.07.2017 21:49, Alan W. Irwin wrote:
> Excellent. However, too be sure all is well with Ada and the other 
> computer languages we support you should build the test_diff_psc 
> target (which compares the plot output files for our psc device for 
> all our standard examples for all our supported languages (including 
> octave) with the equivalent C results.

I will do that. One question/proposal: is it possible to have the tests also done on the _installed_ libraries? The rationale behind this is that I would like to enable Continuous Integration Tests

https://ci.debian.net/doc

for the package. This would give a warning whenever an incompatible upload for a language binding (or wherever) happens, not only when a (occasional) rebuild is done. This early warning would also enable to early discuss the problems with the maintainers of the other packages.

[Octave bindings]
> So I suggest you try enabling it, and then follow up with a build of
> the test_diff_psc target. If that test works, i.e., it produces the
> good octave results above, then I think you can be pretty confident
> all is well with an octave4 binding of PLplot.

I tried, but then I got many error about op_lshift:

[ 10%] Building CXX object bindings/octave/CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o
cd /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave && /usr/bin/c++   -DPLPLOT_HAVE_CONFIG_H -Dplplot_octave_EXPORTS -I/build/plplot-5.12.0+dfsg/include -I/build/plplot-5.12.0+dfsg/lib/qsastime -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/include -I/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave -I/usr/include/hdf5/serial -I/usr/include/octave-4.2.1 -I/usr/include/octave-4.2.1/octave -I/build/plplot-5.12.0+dfsg/bindings/swig-support  -g -O2 -fdebug-prefix-map=/build/plplot-5.12.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave -I/usr/include/hdf5/serial -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/octave-4.2.1/octave/.. -I/usr/include/octave-4.2.1/octave -I/usr/include/hdf5/serial -fPIC   -o CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
In file included from /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:181:0:
/usr/include/octave-4.2.1/octave/toplev.h:28:2: warning: #warning "toplev.h has been deprecated; use interpreter.h instead" [-Wcpp]
 #warning "toplev.h has been deprecated; use interpreter.h instead"
  ^~~~~~~
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'void SWIG_InstallBinaryOps(int, int)':
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2099:46: error: 'op_lshift' is not a member of 'octave_value'
 if (!octave_value_typeinfo::lookup_binary_op(octave_value::op_##name,tid1,tid2)) \
                                              ^
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:2147:5: note: in expansion of macro 'swigreg_binary_op'
     swigreg_binary_op(lshift);
     ^~~~~~~~~~~~~~~~~

and a number of warnings about octave_value::octave_value:

/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx: In function 'octave_value_list _wrap_plGetCursor(const octave_value_list&, int)':
/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:10770:60: warning: 'octave_value::octave_value(const charMatrix&, bool, char)' is deprecated: note: IS_STRING argument is ignored [-Wdeprecated-declarations]
     retval4( 0 ) = octave_value( charMatrix( 80, 1 ), true );
                                                            ^
In file included from /usr/include/octave-4.2.1/octave/ovl.h:36:0,
                 from /usr/include/octave-4.2.1/octave/ov-fcn.h:33,
                 from /usr/include/octave-4.2.1/octave/ov-builtin.h:30,
                 from /usr/include/octave-4.2.1/octave/defun-int.h:30,
                 from /usr/include/octave-4.2.1/octave/defun-dld.h:32,
                 from /usr/include/octave-4.2.1/octave/oct.h:32,
                 from /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:173:
/usr/include/octave-4.2.1/octave/ov.h:244:3: note: declared here
   octave_value (const charMatrix& chm, bool is_string, char type = '\'');
   ^~~~~~~~~~~~

So it does not build in the moment.

> The fundamental problem, of course, (since I am the person with 
> probably the most PLplot development knowledge) is I need to upgrade 
> from Debian Jessie to Debian Stretch (now that the latter has been 
> released as the stable version of Debian), and then tackle such
> PLplot dependency version issues that remain. So I plan to do that 
> after the release of 5.13.0. But any help you can supply for more
> modern Debian versions than the one I am using now would be quite
> helpful.

What I would recommend here is "schroot", which is a Debian package. It allows you to test multiple versions of the OS at the same; for example Stretch (or the Debian testing) on a Debian Jessie machine. The home dir keeps mounted, and so one can easily switch between different Debian versions quickly, and you don't destroy the main setup for a test.

> By the way, if you are interested in the history of the Debian
> packaging of PLplot from 2003 to 2014, then you should take a look at
> 
> git log --name-status -- debian
> 
> results.

Thank you! I will have a look.

Best regards

Ole

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-13 16:02+0200 Ole Streicher wrote:

> Dear Alan,
>
> On 13.07.2017 11:27, Alan W. Irwin wrote:
>>> I already have a few small questions. First language bindings: Currently
>>> the following are disabled:
>>>
>>> ENABLE_ada:             OFF
>>> ENABLE_d:               OFF
>>> ENABLE_octave:          OFF
>>> ENABLE_pdl:             OFF
>>> ENABLE_pyqt5:           OFF
>>>
>>> Would it be useful to (re-)enable any of them? And what would I need to
>>> add as dependencies then?
>>
>> You should _not_ disable the first 3 which are well supported (at least
>> on Linux).  On Debian Jessie, ENABLE_ada, ENABLE_d, and ENABLE_octave
>> require the gnat, gdc, and liboctave-dev packages be installed.
>
> ADA seems to work fine, I enabled it.

Excellent.  However, too be sure all is well with Ada and the other
computer languages we support you should build the test_diff_psc target (which compares
the plot output files for our psc device for all our standard examples
for all our supported languages (including octave) with the equivalent
C results.

The current summary of those comparisons on Debian Jessie are as follows:

Comparison test using psc device

c++
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
fortran
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
java
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
octave
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
python
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
tcl
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
adastandard
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
adatraditional
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
ocaml
   Missing examples            :
   Differing graphical output  :  16 19 33
   Missing stdout              :
   Differing stdout            : 
lua
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
d
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            : 
WARNING: Some graphical or stdout results were different
[100%] Built target test_diff_psc

So PLplot language support is almost perfect for this Debian Jessie platform
except for some long-standing issues with our ocaml support.  So
these results are what we should aspire to on Debian Stretch as well.


> With D, I also have to install libgphobos-dev (right?),
> but even then I get the following error (on newer Debian systems, f.e. Stretch,
> or unstable):
>
> -- D Compiler Install Prefix (use D_PATH env var to override): /usr
> -- Check for working D compiler: /usr/bin/gdc
> -- Check for working D compiler: /usr/bin/gdc -- works
> -- Check for working Phobos
> -- Check for working Phobos -- unavailable
> -- Check for working Tango
> -- Check for working Tango -- unavailable
> CMake Error at cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:175 (MESSAGE):
>  Phobos is required for this project, but it is not available!
> Call Stack (most recent call first):
>  cmake/modules/d.cmake:53 (enable_language)
>  cmake/modules/plplot.cmake:493 (include)
>  CMakeLists.txt:135 (include)
> [...]
> Determining if Phobos works failed with the following output:
> Change Dir: /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/bin/make" "cmTC_b0e79/fast"
> make[2]: Entering directory '/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
> /usr/bin/make -f CMakeFiles/cmTC_b0e79.dir/build.make CMakeFiles/cmTC_b0e79.dir/build
> make[3]: Entering directory '/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
> Building D object CMakeFiles/cmTC_b0e79.dir/testDCompiler.o
> /usr/bin/gdc   -fversion=Phobos    -o CMakeFiles/cmTC_b0e79.dir/testDCompiler.o -c /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CM
> Linking D executable cmTC_b0e79
> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_b0e79.dir/link.txt --verbose=1
> /usr/bin/gdc   -fversion=Phobos   -Wl,-z,relro -Wl,--as-needed  CMakeFiles/cmTC_b0e79.dir/testDCompiler.o -o cmTC_b0e79  -lgphobos2
> /usr/bin/ld: cannot find -lgphobos2
> collect2: error: ld returned 1 exit status
> [...]

> Do you have an idea what to do here? Did I use the wrong library?

Here is what I get on my Debian Jessie platform:

-- D Compiler Install Prefix (use D_PATH env var to override): /usr
-- Check for working D compiler: /usr/bin/gdc
-- Check for working D compiler: /usr/bin/gdc -- works
-- Check for working Phobos
-- Check for working Phobos -- works
-- Check for working Tango
-- Check for working Tango -- unavailable

So phobos (rather than tango) is the right library in general on Debian.  Furthermore,

irwin@raven> locate gphobos2
/usr/lib/gcc/x86_64-linux-gnu/4.9/libgphobos2.a
irwin@raven> dpkg --search /usr/lib/gcc/x86_64-linux-gnu/4.9/libgphobos2.a
libphobos-4.9-dev: /usr/lib/gcc/x86_64-linux-gnu/4.9/libgphobos2.a

However, from
<https://packages.debian.org/stretch/amd64/libgphobos-6-dev/filelist>
the name of the library has been changed to
/usr/lib/gcc/x86_64-linux-gnu/6/libgphobos.so (or
/usr/lib/gcc/x86_64-linux-gnu/6/libgphobos.a)

Finally,

software@raven> find cmake/modules/language_support/cmake/ -type f |xargs grep phobos
cmake/modules/language_support/cmake/CMakeDInformation.cmake:           SET(DSTDLIB_FLAGS "-L${D_PATH}/lib -ltango -lphobos")
cmake/modules/language_support/cmake/CMakeDInformation.cmake:           SET(DSTDLIB_FLAGS "-lgphobos2")
cmake/modules/language_support/cmake/CMakeDInformation.cmake:           SET(DSTDLIB_FLAGS "-L${D_PATH}/lib -lphobos")
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  CMAKE_FLAGS "-DLINK_LIBRARIES=${D_PATH}/lib/libphobos2.a"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  #CMAKE_FLAGS "-DLINK_LIBRARIES=gphobos"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  CMAKE_FLAGS "-DLINK_LIBRARIES=gphobos2"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  CMAKE_FLAGS "-DLINK_LIBRARIES=${D_PATH}/lib/libphobos.a"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:  CMAKE_FLAGS "-DLINK_LIBRARIES=${D_PATH}/lib/libtango.a;${D_PATH}/lib/libphobos.a"
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:# if both tango and phobos are selected try to choose which one is available

So I am virtually positive the issue is in our CMake D language
support logic (i.e., in one or both of the above files), and it also
appears those files have already gone through some changes between the
library name of gphobos and gphobos2.  But probably that was for an
earlier generation of a phobos library name change so that logic
likely needs changing for the latest generation of a phobos library
name change as well.  However, I am tied up with other PLplot release
issues at the moment, and have no way to quickly test phobos library
name changes so if you were willing to look further in those files and
come up with a patch that works for you, I would be happy to accept
that patch.

>
> I also tried octave, but get the warning
>
> -- OCTAVE = /usr/bin/octave
> -- MKOCTFILE = /usr/bin/mkoctfile
> -- OCTAVE_CONFIG = /usr/bin/octave-config
> -- OCTAVE_VERSION = 4.2.1
> -- WARNING: Octave-4 has been found which is likely to lead to build errors for PLplot.
> -- WARNING: Disabling Octave binding. If you want to use that component of PLplot you
>   should try installing Octave-3 (which works well with PLplot) or else try the
>   experimental cmake option -DTRY_OCTAVE4=ON
>
> Debian (Stretch and later) has Octave 4 only, so I am a bit worried enabling this
> for the moment. Would you recommend it despite of the warning?

I don't have access to octave4 so I am not sure. "git blame"
tells me that warning was initially put in coincident with the following
commit message:

commit 8cd0971dd17177d8baedcc03acdb5e1c6230167d
Author: Alan W. Irwin <ai...@us...>
Date:   Wed Jul 8 13:21:37 2015 -0700

     Build system: Implement WARNING message for the Octave-4 case

     Note that the WARNING message warns the users of potential build
     errors but does not actually disable Octave in case someone wants to
     experimentally try Octave-4 once the swig fix for Octave-4 #include
     issues becomes available.

So it appears to me the original problem was caused by some swig
issues (our octave binding is generated using swig), and my guess is
that swig issue has likely been fixed in the two years since.

So I suggest you try enabling it, and then follow up with a build of
the test_diff_psc target. If that test works, i.e., it produces the
good octave results above, then I think you can be pretty confident
all is well with an octave4 binding of PLplot.

The fundamental problem, of course, (since I am the person with
probably the most PLplot development knowledge) is I need to upgrade
from Debian Jessie to Debian Stretch (now that the latter has been
released as the stable version of Debian), and then tackle such PLplot
dependency version issues that remain.  So I plan to do that
after the release of 5.13.0.  But any help you can supply for
more modern Debian versions than the one I am using now
would be quite helpful.

By the way, if you are interested in the history of the Debian
packaging of PLplot from 2003 to 2014, then you should take a look at

git log --name-status -- debian

results.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

Dear Alan,

On 13.07.2017 11:27, Alan W. Irwin wrote:
>> I already have a few small questions. First language bindings: Currently
>> the following are disabled:
>>
>> ENABLE_ada:             OFF
>> ENABLE_d:               OFF
>> ENABLE_octave:          OFF
>> ENABLE_pdl:             OFF
>> ENABLE_pyqt5:           OFF
>>
>> Would it be useful to (re-)enable any of them? And what would I need to
>> add as dependencies then?
> 
> You should _not_ disable the first 3 which are well supported (at least
> on Linux).  On Debian Jessie, ENABLE_ada, ENABLE_d, and ENABLE_octave
> require the gnat, gdc, and liboctave-dev packages be installed.

ADA seems to work fine, I enabled it. With D, I also have to install libgphobos-dev (right?),
but even then I get the following error (on newer Debian systems, f.e. Stretch,
or unstable):

-- D Compiler Install Prefix (use D_PATH env var to override): /usr
-- Check for working D compiler: /usr/bin/gdc
-- Check for working D compiler: /usr/bin/gdc -- works
-- Check for working Phobos
-- Check for working Phobos -- unavailable
-- Check for working Tango
-- Check for working Tango -- unavailable
CMake Error at cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake:175 (MESSAGE):
  Phobos is required for this project, but it is not available!
Call Stack (most recent call first):
  cmake/modules/d.cmake:53 (enable_language)
  cmake/modules/plplot.cmake:493 (include)
  CMakeLists.txt:135 (include)
[...]
Determining if Phobos works failed with the following output:
Change Dir: /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_b0e79/fast"
make[2]: Entering directory '/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_b0e79.dir/build.make CMakeFiles/cmTC_b0e79.dir/build
make[3]: Entering directory '/build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
Building D object CMakeFiles/cmTC_b0e79.dir/testDCompiler.o
/usr/bin/gdc   -fversion=Phobos    -o CMakeFiles/cmTC_b0e79.dir/testDCompiler.o -c /build/plplot-5.12.0+dfsg/obj-x86_64-linux-gnu/CM
Linking D executable cmTC_b0e79
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_b0e79.dir/link.txt --verbose=1
/usr/bin/gdc   -fversion=Phobos   -Wl,-z,relro -Wl,--as-needed  CMakeFiles/cmTC_b0e79.dir/testDCompiler.o -o cmTC_b0e79  -lgphobos2 
/usr/bin/ld: cannot find -lgphobos2
collect2: error: ld returned 1 exit status
[...]

Do you have an idea what to do here? Did I use the wrong library?

I also tried octave, but get the warning

-- OCTAVE = /usr/bin/octave
-- MKOCTFILE = /usr/bin/mkoctfile
-- OCTAVE_CONFIG = /usr/bin/octave-config
-- OCTAVE_VERSION = 4.2.1
-- WARNING: Octave-4 has been found which is likely to lead to build errors for PLplot.
-- WARNING: Disabling Octave binding. If you want to use that component of PLplot you
   should try installing Octave-3 (which works well with PLplot) or else try the
   experimental cmake option -DTRY_OCTAVE4=ON

Debian (Stretch and later) has Octave 4 only, so I am a bit worried enabling this
for the moment. Would you recommend it despite of the warning?

Best regards

Ole

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-13 09:12+0200 Ole Streicher wrote:

> Dear Alan and all,
>
> On 12.07.2017 23:28, Alan W. Irwin wrote:
>> On 2017-07-12 11:00+0200 Ole Streicher wrote:
>> I think we are done here with all the current Debian-related topics,
>> but there will likely be more such topics we need to discuss in the
>> near future as you continue the process of updating the Debian
>> packaging for PLplot, and as we move closer to the release of 5.13.0.
>
> I already have a few small questions. First language bindings: Currently
> the following are disabled:
>
> ENABLE_ada:             OFF
> ENABLE_d:               OFF
> ENABLE_octave:          OFF
> ENABLE_pdl:             OFF
> ENABLE_pyqt5:           OFF
>
> Would it be useful to (re-)enable any of them? And what would I need to
> add as dependencies then?

You should _not_ disable the first 3 which are well supported (at least
on Linux).  On Debian Jessie, ENABLE_ada, ENABLE_d, and ENABLE_octave
require the gnat, gdc, and liboctave-dev packages be installed.

I recommend you leave ENABLE_pdl OFF.

We have no Perl/PDL bindings.  So all that happens when ENABLE_pdl is
ON is some Perl/PDL/PLplot examples that some of us wrote many years
ago are tested against a modified version of an externally developed
Perl/PDL/PLplot package where you must follow a rather complex
procedure (see examples/perl/README.perldemos) to set up that test.
So it is a lot of work to help test an external project so I am leaning toward
donating examples/perl to that external project and removing
it and the ENABLE_pdl option completely from PLplot.

With regard to ENABLE_pyqt4 and ENABLE_pyqt5, PLplot is either built
against Qt4 or Qt5, but not both.  Qt4 is currently preferred because it is a
higher quality library than Qt5 (in terms of, e.g., character
alignment bugs).  In the Qt4 case (which you have above), ENABLE_pyqt4
and ENABLE_pyqt5 are set to ON/OFF, while in the latter case they are
set to OFF/ON.  But you will never have both ON at once.


> Then, there is one remaining patch that may be interesting for you
> (attached). I have however no idea about it; it is a remnant from the
> past. Could you give me a hint whether it is needed for me or for you?
>
> Another point is that TCLDIR is currently set to
> /usr/share/plplot5.12.0/tcl, which is not in the package path for
> Tcl/Tk. Is there a way to change this to something like
> /usr/share/tcltk/plplot5.12.0 [1] with a cmake option so that I
> don't need a patch here?
>
> [1] https://pkg-tcltk.alioth.debian.org/tcltk-policy.html/ch-tcltk.html#s-paths
>

I will take a look at these last two issues (likely this weekend).

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

Dear Alan and all,

On 12.07.2017 23:28, Alan W. Irwin wrote:
> On 2017-07-12 11:00+0200 Ole Streicher wrote:
> I think we are done here with all the current Debian-related topics,
> but there will likely be more such topics we need to discuss in the
> near future as you continue the process of updating the Debian
> packaging for PLplot, and as we move closer to the release of 5.13.0.

I already have a few small questions. First language bindings: Currently
the following are disabled:

ENABLE_ada:             OFF
ENABLE_d:               OFF
ENABLE_octave:          OFF
ENABLE_pdl:             OFF
ENABLE_pyqt5:           OFF

Would it be useful to (re-)enable any of them? And what would I need to
add as dependencies then?

Then, there is one remaining patch that may be interesting for you
(attached). I have however no idea about it; it is a remnant from the
past. Could you give me a hint whether it is needed for me or for you?

Another point is that TCLDIR is currently set to
/usr/share/plplot5.12.0/tcl, which is not in the package path for
Tcl/Tk. Is there a way to change this to something like
/usr/share/tcltk/plplot5.12.0 [1] with a cmake option so that I
don't need a patch here?

[1] https://pkg-tcltk.alioth.debian.org/tcltk-policy.html/ch-tcltk.html#s-paths

Best regards

Ole

Re: [Plplot-devel] PLplot Debian package

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

On 2017-07-12 11:00+0200 Ole Streicher wrote:

[...]
> [This is] the collection of information [concerning Debian
packaging] you can somehow compile-in:

[...]

See commit 68e499b which removed the debian subdirectory and
placed the information you supplied in debian_packaging/README.

[...]
> Thank you again for the nice and effective cooperation! I am happy that
> plplot has such great authors!

You are welcome, and I really appreciated your practical help with the
license evaluation and update process as well.

I think we are done here with all the current Debian-related topics,
but there will likely be more such topics we need to discuss in the
near future as you continue the process of updating the Debian
packaging for PLplot, and as we move closer to the release of 5.13.0.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplot Debian package

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

Dear Alan,

On 12.07.2017 09:05, Alan W. Irwin wrote:
> On 2017-07-11 13:43-0700 Alan W. Irwin wrote:
>> I agree this confusion between upstream and Debian is not ideal.
>> However, Debian packaging is important to us since it does reveal some
>> deficiencies (at least from the Debian point of view) with the
>> upstream version.  And I do have sufficient Debian packaging knowledge
>> that I can interpret a debian subdirectory tree even if I don't have
>> sufficient knowledge to create one on my own.  So I think the best
>> thing to do is to replace everything in our now out-dated debian
>> subdirectory with a README that shows how to get convenient access to
>> the latest debian packaging information that you are working on. So I
>> would appreciate you supplying that information, and once I have that
>> from you, I will make that proposed change.
> 
> I am still waiting for that information from you to help finish
> off this topic between us.

Oh, yes. Sorry. I am not sure what exactly you want here; this is
however the collection of information you can somehow compile-in:

* The users page for the source package is
  https://packages.debian.org/source/unstable/plplot
  with links to all binary packages

* There is a page with developers information about the package:
  https://tracker.debian.org/pkg/plplot

* The development repository is
  https://anonscm.debian.org/cgit/debian-science/packages/plplot.git

* The source code of the released packages can also be found at
  https://sources.debian.net/src/plplot/unstable/

* plplot will be maintained collaboratively by the debian-science
  team, so packaging specific discussion shall go to
  deb...@li...
  We are happy about volunteers wanting to help us, send patches or
  join the mainenance team.

* Debian specific bugs shall be files with the "reportbug" tool in the
  Debian bug database

> The PLplot nn and csa library licensing topic:
> 
> See my recent post concerning this issue.  The upshot is this
> licensing problem appears to be completely resolved now thanks
> to your help and Pavel Sakov's kindly (and very quick) cooperation
> with my request for permission to do that licensing update.
> Time for a big celebration for both of us!

Yea!!! That was great! And I thank you very much for your efforts and
collaboration! If only any licensing issues could be solved so nicely!

> The PLplot release topic:
> 
> I should have stated before to you (since it is completely relevant to
> your packaging effort) that I am planning a PLplot-5.13.0 release
> "soon".  A lot of issues (such as the above licensing issue) appear to
> be falling into place pretty rapidly right now so "soon" might
> actually be some time this month, but stay tuned about that.

I already integrated the 5.12.0 sources (see the git repository link
above), but I will wait with a release until 5.13.0 is out, due to the
licensing issue. And I still need to fine-tune everything and to see
which Debian specific patches are still needed and forward them to you
if useful. You have have a look on your own in the debian/patches subdir:

https://anonscm.debian.org/cgit/debian-science/packages/plplot.git/tree/debian/patches

Thank you again for the nice and effective cooperation! I am happy that
plplot has such great authors!

Best regards

Ole

Re: [Plplot-devel] PLplot Debian package

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

Hi Ole:

Here are my further remarks on a variety of topics relevant to yur
packaging effort.

The upstream versus Debian topic:

On 2017-07-11 13:43-0700 Alan W. Irwin wrote:

> I agree this confusion between upstream and Debian is not ideal.
> However, Debian packaging is important to us since it does reveal some
> deficiencies (at least from the Debian point of view) with the
> upstream version.  And I do have sufficient Debian packaging knowledge
> that I can interpret a debian subdirectory tree even if I don't have
> sufficient knowledge to create one on my own.  So I think the best
> thing to do is to replace everything in our now out-dated debian
> subdirectory with a README that shows how to get convenient access to
> the latest debian packaging information that you are working on. So I
> would appreciate you supplying that information, and once I have that
> from you, I will make that proposed change.

I am still waiting for that information from you to help finish
off this topic between us.

The PLplot nn and csa library licensing topic:

See my recent post concerning this issue.  The upshot is this
licensing problem appears to be completely resolved now thanks
to your help and Pavel Sakov's kindly (and very quick) cooperation
with my request for permission to do that licensing update.
Time for a big celebration for both of us!

The PLplot release topic:

I should have stated before to you (since it is completely relevant to
your packaging effort) that I am planning a PLplot-5.13.0 release
"soon".  A lot of issues (such as the above licensing issue) appear to
be falling into place pretty rapidly right now so "soon" might
actually be some time this month, but stay tuned about that.

Best wishes,

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] Request to update the licensing for our stripped down and substantially modified 2003 versions of nn and csa to your modern licenses for nn and csa

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

On 2017-07-12 14:08+1000 Pavel Sakov wrote:

> Hi Alan,
>
> I agree with the changes in the libraries nn and csa used in PLplot as
> proposed in your message and quote below the first paragraph from your
> message as you requested to confirm my agreement.
>
> "On behalf of the PLplot developers I request your agreement for
> updating the licensing of our stripped-down and substantially modified
> versions of your 2003 version of the csa and nn libraries to be
> respectfully the same as your modern license for csa given at <
> https://github.com/sakov/csa-c/blob/master/csa/LICENSE> and your modern
> license for nn given at
> <https://github.com/sakov/nn-c/blob/master/nn/LICENSE> (with the last two
> note lines concerning triangle dropped because we use the free qhull
> library rather than non-free triangle software <
> http://www.cs.cmu.edu/~quake/triangle.html>)."
>
> Best regards,
> Pavel Sakov

Hi Pavel (with CC added to the plplot development list whose members
should be thrilled by this outcome).

Thanks very much for your quick positive reply to my request!

See
<https://sourceforge.net/p/plplot/plplot/ci/60bf759220062c19f8c74fba7eebecc5013b879b>
for the commit of the relevant licensing upgrade.

Best wishes,

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] The wxwidgets version you use for MSVC - solved (not quite though)

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, July 12, 2017 3:21 AM
>
> By the way, this is really good news that MSVC found this issue and you reported it
> because previously I was having trouble figuring out why that code was not
> producing correct superscript/subscript results.
> But I suspect once I fix this uninitialized variable bug, that other problem will
> become understandable and solveable as well.
>
Good luck with that one :). Of course, others may be surfacing as well when the logic is complex.

>
> So it sounds like you want to drop your previous commit to
> cmake/modules/FindwxWidgets.cmake.
>
Most definitely. This change would open up the same sort of trouble for others who make this mistake. Perhaps the error message can be made clearer - suggesting a solution as I found it. The list of packages is quite long, as for each version of MSVC that is supported there are at least four different choices and the link errors indicate nothing of the sort.

I will commit the reversal in the manner you advocate.

Regards,

Arjen

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.