plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] C++ help requested for step 1. (fwd)

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

On 2017-02-05 21:16-0000 Phil Rosenberg wrote:

[...]
> As it stands I don't see in your source code where you have called
> m_unamed_semaphore_MemoryMap.create( <add params here> );
>
> I think what is happening is that you construct your PLnamedMutex
> which constructs all the member variables using their default
> constructors (the ones which take no variables). The default
> constructor for PLMemoryMap just sets m_buffer to NULL. Your call to
> getwsem then takes m_buffer, which is NULL and tries to access some of
> it's data and I imagine that is the point that everything goes wrong.
>

OK. That completely explains my gdb results. All the members of the
shmbuf struct appear to well aligned so there is no padding.  So the
address of wsem (the first member) is exactly the same as the value of
m_buffer (the address of the struct) which is NULL according to your
above reasoning.  And on Linux, sem_t consumes 32 bytes for 64-bit
systems and size_t consumes 8 bytes.  So buf is offset from the start
of the struct by 2*32 + 8 = 72 bytes = 0x48 which is the (bad) gdb
result I got for the address of buf.  So it appears I am getting
consistently wrong results in the PLNamedMutex case for anything to do
with PLMemoryMap because of the default constructor used for
PLMemoryMap.

> Anyway, the fix is to either call m_unamed_semaphore_MemoryMap.create
> just before getwsem, or call this in the constructor of PLNamedMutex,
> or tell PLNamedMutext to use the non-default constructor for
> m_unamed_semaphore_MemoryMap. To do the last of these the syntax would
> be as follows in wxWidgets_comms.cpp
>
> PLMemoryMap::PLMemoryMap( const char *name, PLINT size, bool
> mustExist, bool mustNotExist )
> : m_unamed_semaphore_MemoryMap(<arguments for the constructor you want to use>)
> {
>

The issue with all these potential solutions is PLNamedMutex::create
needs access to name, size, etc. for the non-default PLMemoryMap
constructor.  So it appears that in all cases these solutions of this
inter-class communication issue involves passing additional arguments
to the PLNamedMutex so the non-default PLMemoryMap constructor can be
invoked with the right name, etc.  In which case I think the better
approach is not to invoke the PLMemoryMap constructor at all from
PLNamedMutex and instead pass the wsem address that is determined
(correctly according to gdb) from a call to m_outputMemoryMap.getswm()
in wxPLDevice::SetupMemoryMap.

Anyhow, thanks for your help pointing out the default constructor
issue for PLMemoryMap for my present code, and more later about
whether the alternative idea of passing the wsem address works out or
not.

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] C++ help requested for step 1. (fwd)

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

Hi Alan
Your ears must be burning! (not sure if you have that phrase
stateside?) I was just looking through the code and trying to
understand the issue. then when I came back to reply I found another
email :-)

As it stands I don't see in your source code where you have called
m_unamed_semaphore_MemoryMap.create( <add params here> );

I think what is happening is that you construct your PLnamedMutex
which constructs all the member variables using their default
constructors (the ones which take no variables). The default
constructor for PLMemoryMap just sets m_buffer to NULL. Your call to
getwsem then takes m_buffer, which is NULL and tries to access some of
it's data and I imagine that is the point that everything goes wrong.

I think it is actually impossible for your getwsem method to return
NULL. Because this function returns the address of member data of
m_buffer (which will just be the m_buffer pointer plus a few bytes)
then the only way it could return NULL would be if m_buffer was 2^64
minus a few and the memory locations wrapped round - but I'm sure that
can't happen.

Anyway, the fix is to either call m_unamed_semaphore_MemoryMap.create
just before getwsem, or call this in the constructor of PLNamedMutex,
or tell PLNamedMutext to use the non-default constructor for
m_unamed_semaphore_MemoryMap. To do the last of these the syntax would
be as follows in wxWidgets_comms.cpp

PLMemoryMap::PLMemoryMap( const char *name, PLINT size, bool
mustExist, bool mustNotExist )
: m_unamed_semaphore_MemoryMap(<arguments for the constructor you want to use>)
{


Hopefully email line breaks haven't messed that up. Just to be clear
after the method definition, but before the opening curly bracket ad a
colon followed by a comma separated list of all the non default
constructors you wish to call. this is called the constructor
initialiser list. You would need to add this for each of the
constructors of PLMemoryMap and of course you would need to add in
your #ifdef statements.


I hope this fixes it!

Phil


On 5 February 2017 at 20:27, Alan W. Irwin <ir...@be...> wrote:
> @everybody (other than Phil who has already been most helpful):
>
> I would really appreciate some timely help with my C++ questions.
>
> Although, my (fairly elementary) C++ question below was initially
> directed to Phil because he has been kind enough to answer such
> questions from me before, if you have some C++ knowledge please don't
> be hesitant about jumping in with your own answer to such questions.
> After all, Phil is not available 24x7 (in fact he appears not to be
> available at the moment) so if you do jump in with the answer, it
> should help me reach my wxwidgets development goals much quicker than
> if you don't.
>
> And, by the way, this "jumping in" attitude should be encouraged in
> general on this list if you have any relevant knowledge about the
> question being discussed.  So don't hold back out of some sense of
> politeness that you are interrupting someone else's conversation.
>
> @everybody (including Phil if someone else doesn't beat him to the
> answer):
>
> So to summarize the current status for _everybody_ here, gdb tells me
> that calls to m_outputMemoryMap.getBuffer() and
> m_outputMemoryMap.getswm() in, wxPLDevice::SetupMemoryMap obtains the
> address of the buf char array and wsem in the shared memory shmbuf
> struct without issues, and with the expected address 0x48 offset
> between the two.  However, a few steps later control passes to
> PLNamedMutex::create, and the m_unamed_semaphore_MemoryMap version of
> those calls produce incorrect addresses (0x48 for the first 0x0 for
> the second).  So why that difference considering that
> m_unamed_semaphore_MemoryMap is defined in a similar way for the
> PLNamedMutex class as m_outputMemoryMap is defined for the wxPLDevice
> class?
>
> I feel like I am on the edge of solving this, but I must be missing
> something that should be obvious to someone knowledgeable in C++.  From
> these gdb results I now expect more has to be done than the single statement
>
> PLMemoryMap  m_unamed_semaphore_MemoryMap;
>
> (see diff below) to set up access to the PLMemoryMap class methods from the PLNamedMutex class.
>
> But what is that "more"?
>
> 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
> __________________________
>
> ---------- Forwarded message ----------
> Date: Sun, 5 Feb 2017 02:18:28 -0800 (PST)
> From: Alan W. Irwin <ir...@be...>
> To: Phil Rosenberg <p.d...@gm...>,
>      PLplot development list <Plp...@li...>
> Subject: [Plplot-devel] C++ help requested for step 1.
>
> On 2017-02-04 19:41-0800 Alan W. Irwin wrote:
>
>> 1. Make the current one-semaphore approach work with unnamed
>> semaphores. The last commit put essentially all the infrastructure in
>> place to support this further change so this change should be a simple
>> matter of replacing (for this case) the calls to sem_open and
>> sem_close with sem_init and sem_destroy, and the rest of the current
>> one-semaphore code should work as is along with the mutex and sleep
>> API calls required by this method.
>
> Hi Phil:
>
> I need some help on another C++ issue which should be simple to figure
> out.
>
> I got the first pass at the coding done for (1) (see the diff
> below relative to current git master), and it builds without issues,
> but it is not working properly at run time.  The problem is (according
> to gdb) that
>
> m_mutex = m_unamed_semaphore_MemoryMap.getwsem();
>
> assigns a NULL pointer to m_mutex which leads to an immediate segfault
> for the subsequent sem_init(m_mutex, 1, 1);
>
> Can you give me the C++ help to figure out why this simple getwsem method is returning
> a NULL pointer rather than the address of wsem (an unnamed semaphore) within the shared
> memory struct as intended?
>
> Alan
>
> diff --git a/drivers/wxwidgets_comms.cpp b/drivers/wxwidgets_comms.cpp
> index 6b5c071..dfb607c 100644
> --- a/drivers/wxwidgets_comms.cpp
> +++ b/drivers/wxwidgets_comms.cpp
> @@ -1,4 +1,5 @@
> -// Copyright (C) 2015  Phil Rosenberg
> +// Copyright (C) 2015-2017 Phil Rosenberg
> +// Copyright (C) 2017 Alan W. Irwin
>    //
>    // This file is part of PLplot.
>    //
> @@ -171,6 +172,12 @@ void PLNamedMutex::create( const char *name, bool aquireOnCreate )
>    {
>    #ifdef WIN32
>        m_mutex = CreateMutexA( NULL, aquireOnCreate ? TRUE : FALSE, name );
> +#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
> +    if ( !isValid() )
> +    {
> +        m_mutex = m_unamed_semaphore_MemoryMap.getwsem();
> +        sem_init(m_mutex, 1, 1);
> +    }
>    #else
>        m_mutex = NULL;
>        char mutexName[251];
> @@ -232,6 +239,8 @@ void PLNamedMutex::clear()
>        release();
>    #ifdef WIN32
>        CloseHandle( m_mutex );
> +#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
> +    sem_destroy( m_mutex );
>    #else
>        sem_close( m_mutex );
>    #endif
> diff --git a/drivers/wxwidgets_comms.h b/drivers/wxwidgets_comms.h
> index a6798ee..90a9be8 100644
> --- a/drivers/wxwidgets_comms.h
> +++ b/drivers/wxwidgets_comms.h
> @@ -100,6 +100,7 @@ public:
>        bool isValid() { return m_buffer != NULL; }
>    #ifdef PL_HAVE_UNNAMED_POSIX_SEMAPHORES
>        char *getBuffer() { return ( (shmbuf *) m_buffer )->buf; }
> +    sem_t *getwsem() { return & ( ( (shmbuf *) m_buffer )->wsem); }
>        size_t getSize() { return PL_SHARED_ARRAY_SIZE; }
>    #else
>        char *getBuffer() { return (char *) m_buffer; }
> @@ -134,6 +135,9 @@ private:
>        bool   m_haveLock;
>    #ifdef WIN32
>        HANDLE m_mutex;
> +#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
> +    PLMemoryMap  m_unamed_semaphore_MemoryMap;
> +    sem_t  * m_mutex;
>    #else
>        sem_t  * m_mutex;
>    #endif
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] C++ help requested for step 1. (fwd)

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

@everybody (other than Phil who has already been most helpful):

I would really appreciate some timely help with my C++ questions.

Although, my (fairly elementary) C++ question below was initially
directed to Phil because he has been kind enough to answer such
questions from me before, if you have some C++ knowledge please don't
be hesitant about jumping in with your own answer to such questions.
After all, Phil is not available 24x7 (in fact he appears not to be
available at the moment) so if you do jump in with the answer, it
should help me reach my wxwidgets development goals much quicker than
if you don't.

And, by the way, this "jumping in" attitude should be encouraged in
general on this list if you have any relevant knowledge about the
question being discussed.  So don't hold back out of some sense of
politeness that you are interrupting someone else's conversation.

@everybody (including Phil if someone else doesn't beat him to the
answer):

So to summarize the current status for _everybody_ here, gdb tells me
that calls to m_outputMemoryMap.getBuffer() and
m_outputMemoryMap.getswm() in, wxPLDevice::SetupMemoryMap obtains the
address of the buf char array and wsem in the shared memory shmbuf
struct without issues, and with the expected address 0x48 offset
between the two.  However, a few steps later control passes to
PLNamedMutex::create, and the m_unamed_semaphore_MemoryMap version of
those calls produce incorrect addresses (0x48 for the first 0x0 for
the second).  So why that difference considering that
m_unamed_semaphore_MemoryMap is defined in a similar way for the
PLNamedMutex class as m_outputMemoryMap is defined for the wxPLDevice
class?

I feel like I am on the edge of solving this, but I must be missing
something that should be obvious to someone knowledgeable in C++.  From
these gdb results I now expect more has to be done than the single statement

PLMemoryMap  m_unamed_semaphore_MemoryMap;

(see diff below) to set up access to the PLMemoryMap class methods from the PLNamedMutex class.

But what is that "more"?

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
__________________________

---------- Forwarded message ----------
Date: Sun, 5 Feb 2017 02:18:28 -0800 (PST)
From: Alan W. Irwin <ir...@be...>
To: Phil Rosenberg <p.d...@gm...>,
     PLplot development list <Plp...@li...>
Subject: [Plplot-devel] C++ help requested for step 1.

On 2017-02-04 19:41-0800 Alan W. Irwin wrote:

> 1. Make the current one-semaphore approach work with unnamed
> semaphores. The last commit put essentially all the infrastructure in
> place to support this further change so this change should be a simple
> matter of replacing (for this case) the calls to sem_open and
> sem_close with sem_init and sem_destroy, and the rest of the current
> one-semaphore code should work as is along with the mutex and sleep
> API calls required by this method.

Hi Phil:

I need some help on another C++ issue which should be simple to figure
out.

I got the first pass at the coding done for (1) (see the diff
below relative to current git master), and it builds without issues,
but it is not working properly at run time.  The problem is (according
to gdb) that

m_mutex = m_unamed_semaphore_MemoryMap.getwsem();

assigns a NULL pointer to m_mutex which leads to an immediate segfault
for the subsequent sem_init(m_mutex, 1, 1);

Can you give me the C++ help to figure out why this simple getwsem method is returning
a NULL pointer rather than the address of wsem (an unnamed semaphore) within the shared
memory struct as intended?

Alan

diff --git a/drivers/wxwidgets_comms.cpp b/drivers/wxwidgets_comms.cpp
index 6b5c071..dfb607c 100644
--- a/drivers/wxwidgets_comms.cpp
+++ b/drivers/wxwidgets_comms.cpp
@@ -1,4 +1,5 @@
-// Copyright (C) 2015  Phil Rosenberg
+// Copyright (C) 2015-2017 Phil Rosenberg
+// Copyright (C) 2017 Alan W. Irwin
   //
   // This file is part of PLplot.
   //
@@ -171,6 +172,12 @@ void PLNamedMutex::create( const char *name, bool aquireOnCreate )
   {
   #ifdef WIN32
       m_mutex = CreateMutexA( NULL, aquireOnCreate ? TRUE : FALSE, name );
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+    if ( !isValid() )
+    {
+        m_mutex = m_unamed_semaphore_MemoryMap.getwsem();
+        sem_init(m_mutex, 1, 1);
+    }
   #else
       m_mutex = NULL;
       char mutexName[251];
@@ -232,6 +239,8 @@ void PLNamedMutex::clear()
       release();
   #ifdef WIN32
       CloseHandle( m_mutex );
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+    sem_destroy( m_mutex );
   #else
       sem_close( m_mutex );
   #endif
diff --git a/drivers/wxwidgets_comms.h b/drivers/wxwidgets_comms.h
index a6798ee..90a9be8 100644
--- a/drivers/wxwidgets_comms.h
+++ b/drivers/wxwidgets_comms.h
@@ -100,6 +100,7 @@ public:
       bool isValid() { return m_buffer != NULL; }
   #ifdef PL_HAVE_UNNAMED_POSIX_SEMAPHORES
       char *getBuffer() { return ( (shmbuf *) m_buffer )->buf; }
+    sem_t *getwsem() { return & ( ( (shmbuf *) m_buffer )->wsem); }
       size_t getSize() { return PL_SHARED_ARRAY_SIZE; }
   #else
       char *getBuffer() { return (char *) m_buffer; }
@@ -134,6 +135,9 @@ private:
       bool   m_haveLock;
   #ifdef WIN32
       HANDLE m_mutex;
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+    PLMemoryMap  m_unamed_semaphore_MemoryMap;
+    sem_t  * m_mutex;
   #else
       sem_t  * m_mutex;
   #endif
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

[Plplot-devel] C++ help requested for step 1.

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

On 2017-02-04 19:41-0800 Alan W. Irwin wrote:

> 1. Make the current one-semaphore approach work with unnamed
> semaphores. The last commit put essentially all the infrastructure in
> place to support this further change so this change should be a simple
> matter of replacing (for this case) the calls to sem_open and
> sem_close with sem_init and sem_destroy, and the rest of the current
> one-semaphore code should work as is along with the mutex and sleep
> API calls required by this method.

Hi Phil:

I need some help on another C++ issue which should be simple to figure
out.

I got the first pass at the coding done for (1) (see the diff
below relative to current git master), and it builds without issues,
but it is not working properly at run time.  The problem is (according
to gdb) that

m_mutex = m_unamed_semaphore_MemoryMap.getwsem();

assigns a NULL pointer to m_mutex which leads to an immediate segfault
for the subsequent sem_init(m_mutex, 1, 1);

Can you give me the C++ help to figure out why this simple getwsem method is returning
a NULL pointer rather than the address of wsem (an unnamed semaphore) within the shared
memory struct as intended?

Alan

diff --git a/drivers/wxwidgets_comms.cpp b/drivers/wxwidgets_comms.cpp
index 6b5c071..dfb607c 100644
--- a/drivers/wxwidgets_comms.cpp
+++ b/drivers/wxwidgets_comms.cpp
@@ -1,4 +1,5 @@
-// Copyright (C) 2015  Phil Rosenberg
+// Copyright (C) 2015-2017 Phil Rosenberg
+// Copyright (C) 2017 Alan W. Irwin
  //
  // This file is part of PLplot.
  //
@@ -171,6 +172,12 @@ void PLNamedMutex::create( const char *name, bool aquireOnCreate )
  {
  #ifdef WIN32
      m_mutex = CreateMutexA( NULL, aquireOnCreate ? TRUE : FALSE, name );
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+    if ( !isValid() )
+    {
+        m_mutex = m_unamed_semaphore_MemoryMap.getwsem();
+        sem_init(m_mutex, 1, 1);
+    }
  #else
      m_mutex = NULL;
      char mutexName[251];
@@ -232,6 +239,8 @@ void PLNamedMutex::clear()
      release();
  #ifdef WIN32
      CloseHandle( m_mutex );
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+    sem_destroy( m_mutex );
  #else
      sem_close( m_mutex );
  #endif
diff --git a/drivers/wxwidgets_comms.h b/drivers/wxwidgets_comms.h
index a6798ee..90a9be8 100644
--- a/drivers/wxwidgets_comms.h
+++ b/drivers/wxwidgets_comms.h
@@ -100,6 +100,7 @@ public:
      bool isValid() { return m_buffer != NULL; }
  #ifdef PL_HAVE_UNNAMED_POSIX_SEMAPHORES
      char *getBuffer() { return ( (shmbuf *) m_buffer )->buf; }
+    sem_t *getwsem() { return & ( ( (shmbuf *) m_buffer )->wsem); }
      size_t getSize() { return PL_SHARED_ARRAY_SIZE; }
  #else
      char *getBuffer() { return (char *) m_buffer; }
@@ -134,6 +135,9 @@ private:
      bool   m_haveLock;
  #ifdef WIN32
      HANDLE m_mutex;
+#elif defined(PL_HAVE_UNNAMED_POSIX_SEMAPHORES)
+    PLMemoryMap  m_unamed_semaphore_MemoryMap;
+    sem_t  * m_mutex;
  #else
      sem_t  * m_mutex;
  #endif
__________________________
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] Recent progress with wxwidgets IPC

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

Hi Phil:

You have probably noticed my recent push of commit 3da0c90.  That
commit contains my recent (fairly small amount of) wxwidgets IPC code
progress.  The unnamed semaphores method requires the shared memory
buffer be a struct (so that the buffer contains room for the required
semaphores as well as the data array).  So all I have done so far is
to adjust the IPC code so it can use a struct for the shared memory,
but at least this commit tests without issues.

N.B. the new IPC code is only exercised if the experimental cmake
option (which defaults to OFF) is set to ON using
-DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=ON.  And conditional compilation
will be used a lot for this development project.  So for the Windows
case the code that is compiled should be completely unaffected by any
of my changes, and for the non-Windows case by default the OLD IPC
method will be preserved and used unless and until the new IPC method
for that case is at least as efficient and reliable as the old one.

So in the ideal case (where all steps below ultimately work and there
are no efficiency reductions due to any of these steps) the remainng
planned steps in this development effort for the
-DPL_HAVE_UNNAMED_POSIX_SEMAPHORES=ON case are as follows:

1. Make the current one-semaphore approach work with unnamed
semaphores. The last commit put essentially all the infrastructure in
place to support this further change so this change should be a simple
matter of replacing (for this case) the calls to sem_open and
sem_close with sem_init and sem_destroy, and the rest of the current
one-semaphore code should work as is along with the mutex and sleep
API calls required by this method.

2. Move from the present one-semaphore approach (which necessarily
includes mutex and sleep activity) to the mutex- and sleep-free
two-semaphore model following the cmake/test_linux_ipc proof-of-concept
project.

3. Implement a two-semaphore version of (2) that uses named semaphores
instead of unnamed semaphores (because not all POSIX systems support
unnamed semaphores).  So this version should differ from 2 only by a
few lines of code (which are already conditionally in place) to use
sem_open and sem_close rather than sem_init and sem_destroy. N.B. like
(2) this approach should also not require any use of mutex or sleep
API.

4. Implement a build system change to test for unnamed semaphore
functionality and use approach (2) if that functionality is available
but otherwise use approach (3).  This should allow us to drop the
present one-semaphore approach that is used in the non-Windows case.

In sum, my work is cut out for me, but at least I have made some initial
progress toward the above goals, and I am beginning to get a bit more
comfortable with C++.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] C++ question

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

On 2017-02-05 00:01-0000 Phil Rosenberg wrote:

> It [initialization of private non-const member] should be done in the constructor, so in PlDevice::PlDevice ()

Hi Phil:

That idea makes perfect sense.  However, there was no explicit
constructor for PLDevice. So I had to implement that also, and it was
much tougher than it should have been because the top C++ tutorials
according to google about creating constructors that initialize values
are completely misleading about how to do that (see
<http://www.cplusplus.com/doc/tutorial/classes/> and
<https://www.tutorialspoint.com/cplusplus/cpp_constructor_destructor.htm>).
Using the style they advocated always created multiple
PlDevice::PlDevice symbol definition issues with the linker.  So
instead, I implemented a constructor using a much simpler style that I
guessed at, and it worked (i.e., no compiler warnings no valgrind
memory issues).

But because I guessed, will you please carefully review what I
did (commit d2218b3) to make sure I didn't screw up?

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] C++ question

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

Hi Phil:

What is the proper C++ way to initialize the private non-const member
m_prevSymbol of the PlDevice class to an invalue value (i.e., 0)?
valgrind is complaining about the uninitialized use of m_prevSymbol
for a test in PlDevice::DrawTextLine, and I am looking for a way to
shut it up.  And we want that test to always fail the first time
(hence the need for an assignment to an invalid value) before m_prevSymbol
is assigned a valid value later in the routine.

I tried replacing

PLUNICODE m_prevSymbol;

by

PLUNICODE m_prevSymbol = 0;

in the private area of the PlDevice class defined
in drivers/wxwidgets.h, and that indeed made valgrind
shut up, i.e., the summary line is

ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

but now I have the following compiler warning message:

In file included from /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:41:0:
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.h:103:30: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
      PLUNICODE m_prevSymbol = 0;

I tried using the static attribute for m_prevSymbol, but the compiler errored out in
that case because the const attribute was not used.  However, const is
inappropriate because m_prevSymbol does get updated in the above
routine.

So the question boils down to a simple one which is what is the proper
C++ way to initialize a private non-const data member such as
m_prevSymbol without generating compiler warnings or errors?

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] Error propagation

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

Hi Andrew
Thanks for adding to the discussion. Further additions below

On 3 February 2017 at 11:15, Andrew Ross
<and...@us...> wrote:
>
> Hi all,
>
> Sorry I have been silent for so long. Work and life have rather got in
> the way of plplot development. This is something I have raised a couple
> of times in the past and something I have thought about a fair bit.
>
> Comments on Phil's proposals below.
>
> Andrew
>
> On Mon, 2017-01-30 at 11:00 +0000, Phil Rosenberg wrote:
>> Hi all
>> We have had this discussion in the past. But I would like to reopen
>> it.
>>
>> We really really need to get id of the exit() calls in PLplot. I
>> don't
>> think that we can really make any recommendation that our library is
>> "industrial strength" while they are their and I would be very
>> nervous
>> about using PLplot in production software with them in - plus even
>> using PLplot for science work I have been caught out be these calls
>> in
>> the past.
>>
>> I think there are a few options we have got
>>
>> Firstly with our internal propagation we can either do
>> A1) Set up our functions so they return error codes and make sure we
>> check these. I feel there is a tendency for this to be bad because I
>> know that I am inherently lazy if I am frank (and I'm sure we all
>> have
>> our lazy moments) and tend to write code without these checks then
>> (try to) go back and add them later. Missing checks are likely to
>> cause segfaults or memory corruptions which are even worse than the
>> exit calls().
>
> Laziness is no excuse! The advantage of this proposal is that is allows
> the library to clean things up as we unwind the stack and so (if done
> properly) it will minimise any chance of problems down the line. Even
> if this is a fatal error from plplot's perspective (e.g. memory
> allocation failure), then we must return control to the calling
> programme in a clean and controlled manner.

I wasn't saying it's an excuse, and perhaps I am being flippant using
the term laziness. I guess that what I meant is that it is easy to
forget to do the checking and can be painful, error prone and take a
long time to implement/manage and the result of a single forgotten or
missed error check is equal to a single exit call - i.e. likely
segfault and immediate program termination. Currently a single memory
allocation imposes a single plexit() function call - so at least there
aren't many of them and we know where they are. In a returned error
code solution there will be many function calls to deal with for each
of our current exit calls. Is there a way we can manage this with code
style? Maybe could we label internal functions that can result in
failures with a prefix like plcf (for pl can fail - better prefix
suggestions welcome) Then only functions which have the plcf prefix or
API entry points are allowed to call other functions with the plcf
prefix? Could something like this be checked with a script?
Could we have a required format of checking that we can police with a
script? like if a plcf call is made, the next like should contain if(
err ) or something?

>> A2) Set up an error flag in PLStream which can be set on error and
>> checked after every function call. This would avoid having to change
>> functions that already return values, but still relies on manual
>> checks which I think will be a big weak point.
>
> I would agree that this is still subject to human laziness in checking
> return codes. The advantage of explicitly returning values is that it
> is at least more obvious you need to check them. On the other hand, if
> functions already return values this gets tricky. We probably need to
> do something of a code audit to see if this is likely to be an issue
> before making final decisions.

Same comment as above.
>
>> A3) Use setjmp/longjmp calls. In this case we call setjmp in the top
>> level of every API call and on error we call longjmp which returns
>> the
>> execution point back to the point setjmp was called. There is some
>> extra setup time here to avoid memory leaks and other resource leaks,
>> but once that is done we can all write code with almost no worry
>> regarding error propagation.
>
> This has advantages in terms of not requiring explicit error code
> checking. The bigger problem is making sure we tidy up properly to
> avoid leaks. As Phil says, it requires some care thinking about how we
> deal with non-C drivers as well. I can't say I'm too keen on
> setjmp/longjmp. It can be a lazy solution to the problem rather than
> writing better code in the first place, but given we have a fairly
> large heritage codebase it might be an easier solution.
I don't feel like it is a lazy solution - it is using a feature of the
language for exactly the purpose it was designed for. But I know there
are lots of caveats that come with it. One is that we must do some
book keeping to avoid memory leaks or other resource leaks (like
failure to close files properly). But that bookkeeping seems trivial
to me - Because we have a PLStream struct it is almost no more effort
than using exceptions in C++. The big issue for me is dealing with
drivers written in C++, that does seem like it could be hard work.
>
>> Once we decide on our internal method we need to decide how we can
>> inform the user. We have a number of options again:
>>
>> B1) An API change so that all our functions return an error code.
>
> Quite a C-like approach. Requires quite a lot of changes to user code
> to properly check for errors. Huge API change. Could cause problems for
> the few plplot functions which already return a value.
>
>> B2) Make use of our current plabort call and let the user pass in a
>> plabort handler.
>
> This could get messy with some of the bindings. Calling an abort
> handler also makes it hard for the programme to decide what to do. For
> some uses for example you might want to shut down the plot, but
> continue with the program. Harder with a handler. (I'm thinking about
> things like the interactive octave bindings where I find it exceedingly
>  annoying if plplot kills octave. In case of an error I might want to
> return control to octave and proceed to save my work or whatever in an
> orderly manner before choosing to exit or reinitialise plplot.)

Yes this is definitely what we should aim for - in some cases the host
program almost definitely wants to continue - Octave is a good
example.
>
>> B3) If we have an error, store an error code in PLStream and add an
>> API function called plgeterr or similar which allows the user to
>> check
>> for error after any other function call.
>
> Easier to implement in terms of API changes, but makes for ugly end
> user code if the end user really does need to call an additional
> function to check return codes every time. One plus of an internal
> plstream error flag is that we could internally check it whenever a
> function is called. This would prevent the user trying to continue
> after an error (or just failing to check the error code). We could then
> possible provide some mechanism for resetting the error flag and maybe
> reinitialising plplot at the same time depending on the error?

Yep, a bit messy, but probably less painful than the huge API change.
Not sure if people may be interested in this, but could we provide a
#define that users could put before their plplot #include that would
allow them to use either the existing API with a call to plgeterr or a
new API which returns an error code?

>
>> B4) In the C++ binding we could throw an error. Not sure if other
>> languages have similar throw/catch style options.
>
> Other more modern languages such as java and python have exception
> handling. I would very much like to see the bindings take advantage of
> these where possible. It would lead to much more natural, standard and
> cleaner code in these languages.

Agreed. I'm not sure in C++ if there are issues throwing over dll
boundaries. If so we could easily make the C++ binding header only as
there isn't very much code in it.
>
>> B5) Some combination of the above.
>
> I'd definitely say B4 for languages that support it and B3 or B1 where
> not.
>
> We might want to keep the option of a plabort handler (default to exit)
> for now to aid compatibility in the changes. Users who are happy with
> plplot exiting on error can carry on with that behaviour without having
> to change their code, beyond perhaps enabling the handler. Or is that
> just lazy?

I think probably once we have this sorted it will basically just work.
So if we fail during plot initialisation then the plot will act
likethe initialisation didn't happen. Otherwise the data won't get
plotted or something.
>
>> I will add there are some specific things we need to think about for
>> our C++ drivers. These are not so much options, but things we need to
>> deal with anyway.
>>
>> C1) Our C++ drivers cannot be allowed to throw an error out of the
>> driver code and into the main C code. That would potentially end up
>> with the throw going all the way out to the user's top level code
>> which may be in C, Fortran, or any other language that can't deal
>> with
>> it. Note that even if the driver doesn't call throw, it may call
>> either something in the stl or another driver (in Qt or wxWidgets for
>> example) that does throw. This is easy to avoid by wrapping the intry
>> points in try blocks. I have done this for wxWidgets, but haven't
>> checked the other C++ drivers to see if they are the same.
>>
>> C2) If we go for option A3, then we cannot allow longjmp over C++
>> code. This is because nontrivial destructors are not called when
>> longjmp is called and if objects with these destructors are jumped
>> over then the result is undefined behaviour - which again is worse
>> than exit calls.
>>
>> The fix for C2 - and I think this would be a good thing anyway -
>> would
>> be to have a specific driver API. This would allow us to have setjmp
>> calls when we enter that API and avoid jumping over drivers. I think
>> this would be nice in general as it is not well documented how to
>> write a driver and a proper driver API would address that.
>>
>> I am well aware that the use of setjmp and longjmp is very divisive.
>> So my intention is to work this code up only for the case of memory
>> allocation failures. This code will consist of:
>> D2)A set of plmalloc, plrealloc and plfree fuctions which will
>> replace
>> the usual versions. As well as allocating/freeing memory these
>> functions will record the allocations in the PLstream.
>> D1)PLTRY, PLENDTRY macros which will go in each API call. PLTRY will
>> have the setjmp call. This will be followed by the current code in
>> the
>> function as it is now then PLENDTRY will deal with what happens if
>> longjmp has been called - it will check for memory allocations
>> recorded in the PLStream and will free them. For now it will then
>> just
>> call exit() so we get the same behaviour but this can be changed
>> later
>> if we want to go down this route. Once we have this first look at how
>> setjmp/longjmp can work in our code then I think it will be easier
>> for
>> us to make an informed choice about the A options.
>>
>> Does that sound sensible to people? If anyone would like to look at
>> what would be involved in doing a similar thing using the other
>> options then it would be really nice to be able to compare the work
>> and admin/code practices needed for those too.
>>
>> Phil
>>
>> -------------------------------------------------------------------
>> -----------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Proposed eop/wait changes have now been committed

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

> On Feb 3, 2017, at 4:13 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Jim:
> 
> Since you were unable to answer my questions below in a timely manner,
> because it is early in the release cycle (so plenty of time to fix any
> errors introduced by commits), and because I would like to move on to
> other PLplot development; I decided to just go ahead and push these
> three commits (for the wxwidgets, tkwin, and wincairo devices).  When
> you have time I would still very much appreciate your review of these
> three commits (0ba44e87, 8354e461, and ed66632) to make sure my
> inferences about what should be changed in the drivers to correspond
> to your eop/wait split were correct.
> 

I will take a look at the commits and try to test the drivers.

[Plplot-devel] Proposed eop/wait changes have now been committed

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

Hi Jim:

Since you were unable to answer my questions below in a timely manner,
because it is early in the release cycle (so plenty of time to fix any
errors introduced by commits), and because I would like to move on to
other PLplot development; I decided to just go ahead and push these
three commits (for the wxwidgets, tkwin, and wincairo devices).  When
you have time I would still very much appreciate your review of these
three commits (0ba44e87, 8354e461, and ed66632) to make sure my
inferences about what should be changed in the drivers to correspond
to your eop/wait split were correct.

Also, you stated at the time (June 2015) when you made your eop/wait split

"The wxWidgets driver will need to be updated to work correctly because
it uses the plot buffer.  Without an updated, it will need an
extra keypress after a resize event."

I saw no need for such a keypress either before or after my commit
when resizing wxPLViewer results generated by -dev wxwidgets.  So it
is possible my commit is still missing something for the wxwidgets
device case (and even more possible I didn't understand what to look
for there).  Anyhow, please do your own intensive testing of resizing
of the wxPLViewer GUI to see whether you are now satisfied with
how the wxwidgets driver handles the eop/wait split.

Note my own testing revealed the wxwidgets device does have a resize
bug which is that in certain cirmcumstances a resize would always
respond to the mouse position of the _prior_ resize attempt. Those
circumstances were for the second page plotted and all subsequent
pages (even if you used PageUp to back up to the first page again).
The only case where this resize bug did not occur was if the "enter"
or "PageUp" keys had not been pressed to move forward or backward
between pages.  N.B. my tests showed this exact resize bug occurred
both before and after my commit.

Finally, with regard to my wincairo eop/wait implementation it
obviously cannot be tested in the slightest on my Linux platform.  So
I would appreciate you both build and run-time testing that device on
a Windows platform (MinGW-w64/MSYS2?) where native software packages
for the pango/cairo subset of the GTK+ suite of libraries are
available.

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
__________________________

---------- Forwarded message ----------
Date: Thu, 2 Feb 2017 13:50:57 -0800 (PST)
From: Alan W. Irwin <ir...@be...>
To: Jim Dishaw <ji...@di...>, Phil Rosenberg <p.d...@gm...>,
     PLplot development list <Plp...@li...>
Subject: [Plplot-devel] Proposed eop/wait change for -dev wxwidgets

On 2017-02-01 17:33-0800 Alan W. Irwin wrote:

> [...] But regardless of these speculations the most
> important point is this current inconsistency between plbuf and
> wxwidgets should be addressed soon since plbuf now distinguishes
> between wait states and eop states and until wxwidgets also follows
> that same model we won't know whether some wxwidgets issue we observe
> [...] is due to this current mismatch

Hi Jim:

> From Phil's ("I'll have a look as soon as I can") response to my post
that included the above remark amongst several others, I suspect he is
pretty tied up with other work.  And there are a whole host of other
issues (including wxPLViewer inefficiency for plots with large numbers
of graphical elements and implementing a native wxwidgets gradient)
that he might want to concentrate on instead.  Therefore, to take some
PLplot load off of him for at least the above issue, I have attempted
to tackle that issue myself (see the attached patch, but more on that
patch later).

When preparing for that I reviewed your wait/eop changes for other
devices, and it looks like in all cases you were attempting to move
all code that is executed for the pls->nopause false case from the
plD_eop_<devicename> function to a newly implemented
plD_wait_<devicename> function (without any check of pls->nopause
because plD_wait* is only called by plP_wait for the pls->nopause
false case which makes such checks in plD_wait_<devicename>
redundant).

If that is a correct summary of what you were attempting to do with
your driver changes I spotted some issues with those changes which are
the following:

1. drivers/cairo.c

You left the wincairo device untouched, and the current
plD_eop_wincairo is nothing but code that is executed in the
pls->nopause false case. It appears to me the solution is to move all
code from plD_eop_wincairo to a new plD_wait_wincairo function while
dropping the redundant check (in that case) for pls->nopause false. Do
you agree?

2. drivers/tkwin.c

Your change copied the pls->nopause false logic in plD_eop_tkwin to
the new routine plD_wait_tkwin (without dropping the redundant check
that pls->nopause was false). It appears to me this should have been a
move of the logic rather than the copy that you did.  Therefore, I
believe this should be followed up by removing the pls->nopause false
logic from plD_eop_tkwin and also removing the redundant check that
pls->nopause is false from plD_wait_tkwin.  Do you agree?

3. drivers/ntk.c

I think you made the right choice, here, i.e., don't touch this driver
at all with regard to wait versus eop, but "for the record" I would
like to remark on this decision here.  There currently is some
pls->nopause false logic used in plD_tidy_ntk (not plD_eop_ntk) to
execute the experimental waitforpage routine.  My guess is this call
to waitforpage should have originally been in plD_eop_ntk, and
therefore now it should be moved to a new plD_wait_ntk routine, but
because of this guesswork and because waitforpage is experimental
(from more than a decade ago by someone who is no longer actively
developing PLplot) your decision to not touch this code at all until
we know a lot more about it (in particular how to even test it!)
is likely correct.

I would now like to move to the topic of my proposed (see my attached
patch) wait/eop changes for the wxwidgets device driver. Here I have
followed the same general idea as your changes for the other drivers.
That is, I implemented a new PLD_wait_wxwidgets routine and moved all
code from PLD_eop_wxwidgets that was executed when pls->nopause was
false to that new routine.  Also, I dropped the redundant check that
pls->nopause was false in the new PLD_wait_wxwidgets routine. As a
result of my change, the only references to pls->nopause that are left
in the -dev wxwidgets code are some logic to exclude the pls->nopause
false case in the (revised) PLD_eop_wxwidgets and some existing logic
in the PLD_tidy_wxwidgets which was already only executed for the
pls->nopause true case.  So I am pretty sure the patch is correct
although it is based on some educated inferences on my part from your
previous eop/wait changes for other drivers rather than deep knowledge
of what is going on!  :-)

My tests of the patch shows it builds without issues, but there are no
changes at run time from it that I can discover. That is, the time
results I got yesterday for example 8 for both with and without the
-np option and the black rather than white color for the first page of
example 16 are the same.  So that is a somewhat disappointing result,
but at least there is no obvious harm that I can see if this patch is
applied.  Of course, that is not enough to justify pushing this patch,
but if in addition you feel confident this patch is correct we
_should_ push it simply to remove this source of uncertainty for
wxwidgets every time we encounter an issue that is associated with
waiting or end of page. Also, please let me know if you think I should
commit and push my suggested changes above for cairo and tkwin or do
you want to handle those yourself?

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] Error propagation

[Andrew R. <and...@us...>]

Hi all,

Sorry I have been silent for so long. Work and life have rather got in
the way of plplot development. This is something I have raised a couple
of times in the past and something I have thought about a fair bit.

Comments on Phil's proposals below.

Andrew

On Mon, 2017-01-30 at 11:00 +0000, Phil Rosenberg wrote:
> Hi all
> We have had this discussion in the past. But I would like to reopen
> it.
> 
> We really really need to get id of the exit() calls in PLplot. I
> don't
> think that we can really make any recommendation that our library is
> "industrial strength" while they are their and I would be very
> nervous
> about using PLplot in production software with them in - plus even
> using PLplot for science work I have been caught out be these calls
> in
> the past.
> 
> I think there are a few options we have got
> 
> Firstly with our internal propagation we can either do
> A1) Set up our functions so they return error codes and make sure we
> check these. I feel there is a tendency for this to be bad because I
> know that I am inherently lazy if I am frank (and I'm sure we all
> have
> our lazy moments) and tend to write code without these checks then
> (try to) go back and add them later. Missing checks are likely to
> cause segfaults or memory corruptions which are even worse than the
> exit calls().

Laziness is no excuse! The advantage of this proposal is that is allows
the library to clean things up as we unwind the stack and so (if done
properly) it will minimise any chance of problems down the line. Even
if this is a fatal error from plplot's perspective (e.g. memory
allocation failure), then we must return control to the calling
programme in a clean and controlled manner. 

> A2) Set up an error flag in PLStream which can be set on error and
> checked after every function call. This would avoid having to change
> functions that already return values, but still relies on manual
> checks which I think will be a big weak point.

I would agree that this is still subject to human laziness in checking
return codes. The advantage of explicitly returning values is that it
is at least more obvious you need to check them. On the other hand, if
functions already return values this gets tricky. We probably need to
do something of a code audit to see if this is likely to be an issue
before making final decisions.

> A3) Use setjmp/longjmp calls. In this case we call setjmp in the top
> level of every API call and on error we call longjmp which returns
> the
> execution point back to the point setjmp was called. There is some
> extra setup time here to avoid memory leaks and other resource leaks,
> but once that is done we can all write code with almost no worry
> regarding error propagation.

This has advantages in terms of not requiring explicit error code
checking. The bigger problem is making sure we tidy up properly to
avoid leaks. As Phil says, it requires some care thinking about how we
deal with non-C drivers as well. I can't say I'm too keen on
setjmp/longjmp. It can be a lazy solution to the problem rather than
writing better code in the first place, but given we have a fairly
large heritage codebase it might be an easier solution. 

> Once we decide on our internal method we need to decide how we can
> inform the user. We have a number of options again:
> 
> B1) An API change so that all our functions return an error code.

Quite a C-like approach. Requires quite a lot of changes to user code
to properly check for errors. Huge API change. Could cause problems for
the few plplot functions which already return a value. 

> B2) Make use of our current plabort call and let the user pass in a
> plabort handler.

This could get messy with some of the bindings. Calling an abort
handler also makes it hard for the programme to decide what to do. For
some uses for example you might want to shut down the plot, but
continue with the program. Harder with a handler. (I'm thinking about
things like the interactive octave bindings where I find it exceedingly
 annoying if plplot kills octave. In case of an error I might want to
return control to octave and proceed to save my work or whatever in an
orderly manner before choosing to exit or reinitialise plplot.) 

> B3) If we have an error, store an error code in PLStream and add an
> API function called plgeterr or similar which allows the user to
> check
> for error after any other function call.

Easier to implement in terms of API changes, but makes for ugly end
user code if the end user really does need to call an additional
function to check return codes every time. One plus of an internal
plstream error flag is that we could internally check it whenever a
function is called. This would prevent the user trying to continue
after an error (or just failing to check the error code). We could then
possible provide some mechanism for resetting the error flag and maybe
reinitialising plplot at the same time depending on the error? 

> B4) In the C++ binding we could throw an error. Not sure if other
> languages have similar throw/catch style options.

Other more modern languages such as java and python have exception
handling. I would very much like to see the bindings take advantage of
these where possible. It would lead to much more natural, standard and
cleaner code in these languages. 

> B5) Some combination of the above.

I'd definitely say B4 for languages that support it and B3 or B1 where
not. 

We might want to keep the option of a plabort handler (default to exit)
for now to aid compatibility in the changes. Users who are happy with
plplot exiting on error can carry on with that behaviour without having
to change their code, beyond perhaps enabling the handler. Or is that
just lazy?

> I will add there are some specific things we need to think about for
> our C++ drivers. These are not so much options, but things we need to
> deal with anyway.
> 
> C1) Our C++ drivers cannot be allowed to throw an error out of the
> driver code and into the main C code. That would potentially end up
> with the throw going all the way out to the user's top level code
> which may be in C, Fortran, or any other language that can't deal
> with
> it. Note that even if the driver doesn't call throw, it may call
> either something in the stl or another driver (in Qt or wxWidgets for
> example) that does throw. This is easy to avoid by wrapping the intry
> points in try blocks. I have done this for wxWidgets, but haven't
> checked the other C++ drivers to see if they are the same.
> 
> C2) If we go for option A3, then we cannot allow longjmp over C++
> code. This is because nontrivial destructors are not called when
> longjmp is called and if objects with these destructors are jumped
> over then the result is undefined behaviour - which again is worse
> than exit calls.
> 
> The fix for C2 - and I think this would be a good thing anyway -
> would
> be to have a specific driver API. This would allow us to have setjmp
> calls when we enter that API and avoid jumping over drivers. I think
> this would be nice in general as it is not well documented how to
> write a driver and a proper driver API would address that.
> 
> I am well aware that the use of setjmp and longjmp is very divisive.
> So my intention is to work this code up only for the case of memory
> allocation failures. This code will consist of:
> D2)A set of plmalloc, plrealloc and plfree fuctions which will
> replace
> the usual versions. As well as allocating/freeing memory these
> functions will record the allocations in the PLstream.
> D1)PLTRY, PLENDTRY macros which will go in each API call. PLTRY will
> have the setjmp call. This will be followed by the current code in
> the
> function as it is now then PLENDTRY will deal with what happens if
> longjmp has been called - it will check for memory allocations
> recorded in the PLStream and will free them. For now it will then
> just
> call exit() so we get the same behaviour but this can be changed
> later
> if we want to go down this route. Once we have this first look at how
> setjmp/longjmp can work in our code then I think it will be easier
> for
> us to make an informed choice about the A options.
> 
> Does that sound sensible to people? If anyone would like to look at
> what would be involved in doing a similar thing using the other
> options then it would be really nice to be able to compare the work
> and admin/code practices needed for those too.
> 
> Phil
> 
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Proposed eop/wait change for -dev wxwidgets

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

On 2017-02-01 17:33-0800 Alan W. Irwin wrote:

> [...] But regardless of these speculations the most
> important point is this current inconsistency between plbuf and
> wxwidgets should be addressed soon since plbuf now distinguishes
> between wait states and eop states and until wxwidgets also follows
> that same model we won't know whether some wxwidgets issue we observe
> [...] is due to this current mismatch

Hi Jim:

>From Phil's ("I'll have a look as soon as I can") response to my post
that included the above remark amongst several others, I suspect he is
pretty tied up with other work.  And there are a whole host of other
issues (including wxPLViewer inefficiency for plots with large numbers
of graphical elements and implementing a native wxwidgets gradient)
that he might want to concentrate on instead.  Therefore, to take some
PLplot load off of him for at least the above issue, I have attempted
to tackle that issue myself (see the attached patch, but more on that
patch later).

When preparing for that I reviewed your wait/eop changes for other
devices, and it looks like in all cases you were attempting to move
all code that is executed for the pls->nopause false case from the
plD_eop_<devicename> function to a newly implemented
plD_wait_<devicename> function (without any check of pls->nopause
because plD_wait* is only called by plP_wait for the pls->nopause
false case which makes such checks in plD_wait_<devicename>
redundant).

If that is a correct summary of what you were attempting to do with
your driver changes I spotted some issues with those changes which are
the following:

1. drivers/cairo.c

You left the wincairo device untouched, and the current
plD_eop_wincairo is nothing but code that is executed in the
pls->nopause false case. It appears to me the solution is to move all
code from plD_eop_wincairo to a new plD_wait_wincairo function while
dropping the redundant check (in that case) for pls->nopause false. Do
you agree?

2. drivers/tkwin.c

Your change copied the pls->nopause false logic in plD_eop_tkwin to
the new routine plD_wait_tkwin (without dropping the redundant check
that pls->nopause was false). It appears to me this should have been a
move of the logic rather than the copy that you did.  Therefore, I
believe this should be followed up by removing the pls->nopause false
logic from plD_eop_tkwin and also removing the redundant check that
pls->nopause is false from plD_wait_tkwin.  Do you agree?

3. drivers/ntk.c

I think you made the right choice, here, i.e., don't touch this driver
at all with regard to wait versus eop, but "for the record" I would
like to remark on this decision here.  There currently is some
pls->nopause false logic used in plD_tidy_ntk (not plD_eop_ntk) to
execute the experimental waitforpage routine.  My guess is this call
to waitforpage should have originally been in plD_eop_ntk, and
therefore now it should be moved to a new plD_wait_ntk routine, but
because of this guesswork and because waitforpage is experimental
(from more than a decade ago by someone who is no longer actively
developing PLplot) your decision to not touch this code at all until
we know a lot more about it (in particular how to even test it!)
is likely correct.

I would now like to move to the topic of my proposed (see my attached
patch) wait/eop changes for the wxwidgets device driver. Here I have
followed the same general idea as your changes for the other drivers.
That is, I implemented a new PLD_wait_wxwidgets routine and moved all
code from PLD_eop_wxwidgets that was executed when pls->nopause was
false to that new routine.  Also, I dropped the redundant check that
pls->nopause was false in the new PLD_wait_wxwidgets routine. As a
result of my change, the only references to pls->nopause that are left
in the -dev wxwidgets code are some logic to exclude the pls->nopause
false case in the (revised) PLD_eop_wxwidgets and some existing logic
in the PLD_tidy_wxwidgets which was already only executed for the
pls->nopause true case.  So I am pretty sure the patch is correct
although it is based on some educated inferences on my part from your
previous eop/wait changes for other drivers rather than deep knowledge
of what is going on!  :-)

My tests of the patch shows it builds without issues, but there are no
changes at run time from it that I can discover. That is, the time
results I got yesterday for example 8 for both with and without the
-np option and the black rather than white color for the first page of
example 16 are the same.  So that is a somewhat disappointing result,
but at least there is no obvious harm that I can see if this patch is
applied.  Of course, that is not enough to justify pushing this patch,
but if in addition you feel confident this patch is correct we
_should_ push it simply to remove this source of uncertainty for
wxwidgets every time we encounter an issue that is associated with
waiting or end of page. Also, please let me know if you think I should
commit and push my suggested changes above for cairo and tkwin or do
you want to handle those yourself?

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] Important new evidence concerning the remaining Linux inefficiencyissues for wxwidgets

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

Hi Alan
Good detective work. I'll have a look as soon as I can

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 02 February 2017 01:33
To: Phil Rosenberg; PLplot development list
Subject: Important new evidence concerning the remaining Linux inefficiencyissues for wxwidgets

Hi Phil:

The wxwidgets IPC (inter process communication) improvements I have
just started working on are suddenly less urgent because some new
evidence (see below) indicates the cause of the Linux inefficiency
issue has nothing to do with IPC!

To remind you of what that (remaining Linux inefficiency) problem is, here
are timing results for example 8 for current master.

I first built test_c_xcairo and test_c_wxwidgets to get all
prerequisites built properly.  Then

software@raven> time(examples/c/x08c -dev xcairo -np)

real    0m2.128s
user    0m1.896s
sys     0m0.040s
software@raven> time(examples/c/x08c -dev wxwidgets -np)

real    0m13.423s
user    0m0.224s
sys     0m0.024s

Note the ~13 seconds of time when my cpus were completely idle for the
-dev wxwidgets -np test, and my cpumeter confirmed that result (i.e.,
it barely twitched from dead idle through most of this time). Of
course, the above timing results just measures examples/c/x08c and
-dev wxwidgets and ignores wxPLViewer, but that widget is quite
inefficient for this example as well because it remained on my screen
for ~20
seconds after example 8 and -dev wxwidgets had completed.

My initial (naive) view was this order of magnitude inefficiency in both
-dev wxwidgets and wxPLViewer likely had to do with IPC, but that
extra 20 seconds where wxPLViewer continues on after examples/c/x08c
(and therefore -dev wxwidgets) completes indicates there is at least
one big inefficiency that must not have anything to do with IPC.
Furthermore if you drop the -np option you get the following result:

software@raven> time(examples/c/x08c -dev wxwidgets)

real    0m1.067s
user    0m0.236s
sys     0m0.020s

That is, without the -np (nopause) option -dev wxwidgets is faster (!)
than xcairo (as it should be since the rendering done by wxPLViewer is
not counted as part of this time).  That still leaves the order of
magnitude inefficiency of wxPLViewer for this case (it required 30
seconds or so to get this example rendered if I hit the "enter" key as
soon as the plot of one page was completed so this inefficiency
appears to be the same as in the -np case).  But this wxPLViewer
inefficiency _cannot_ have anything to do with IPC since
examples/c/x08c and -dev wxwidgets are completely done and dusted
after ~1 second when no -np option is used.

So it appears likely to me that what is going on for the -np case is
some of the large wxPLViewer inefficieny is slowing down -dev
wxwidgets, i.e., the real culprit is wxPLViewer inefficiency for the
-np case.  Note also that Jim's split of the wait and eop states that
I reinstated recently for -dev xcairo completely changed how the -np
option was handled for that device so addressing that split of wait
and eop for wxwidgets might also make a big difference to the above
-np timing results for -dev wxwidgets (although such a change should
have no effect on the order of magnitude inefficiency of wxPLViewer
itself).

@Phil:

As a result of the above new test results, I hope you agree your own
wxwidgets development plans should include the following two steps as
a matter of some urgency:

1. Implement the wait/eop split for wxwidgets following Jim's work
that was recently reinstated for xcairo.  I would do that myself, but
I don't understand the plbuf/xcairo nuances used by Jim (e.g., why
explicit nopause processing could be removed in xcairo yet the -np
option still clearly works properly for that device), and I don't
understand enough of the wxwidgets device driver to figure out exactly
what part of the current eop processing should be split off into the
new wait routine that must be implemented for -dev wxwidgets.

Anyhow, my feeling is dealing with this issue is a matter of some
urgency since it could potentially kill 3 birds with one stone, i.e.,
(i) the wxwidgets eop issue you were concerned about during the last
few days of the previous release cycle (although ultimately our joint
decision was not to delay the 5.12.0 release due to that issue), (ii)
the background color issue for the first page of example 16, and (iii)
the above order of magnitude inefficieny in -dev wxwidgets only when
the -np option is used. But regardless of these speculations the most
important point is this current inconsistency between plbuf and
wxwidgets should be addressed soon since plbuf now distinguishes
between wait states and eop states and until wxwidgets also follows
that same model we won't know whether some wxwidgets issue we observe
(such as any of the 3 issues above) is due to this current mismatch
between plbuf and wxwidgets or something else.

2. Solve the inefficient rendering (already demonstrated above to have
nothing to do with IPC) currently shown by wxPLViewer for examples
such as example 8 that have many graphical elements to plot. I feel
solving this issue is a matter of urgency since this lack of
wxPLViewer rendering speed (at least when there is anything
complicated to plot as in example 8) will tend to discourage most user
interest in wxwidgets regardless of platform until it is fixed.

Assuming you solve these two important issues in a timely manner, I
promise to follow up with a 5.12.1 release so that wxwidgets users can
quickly benefit from your work.

I have already invested some time in improved IPC for wxwidgets.  I
doubt (from the above evidence) it will improve efficiency very much,
but I still plan to finish this effort simply because the efficient
IPC algorithm I implemented for the cmake/test_linux_ipc miniproject
is much simpler (no mutex, no sleeping) then the IPC algorithm used
now for wxwidgets.

So I will continue updating you on my wxwidgets IPC effort, and I hope
to have it completed in a matter of a week or so.  However, I believe
now your timely resolution of the above two wxwidgets issues is much
more important than my own ongoing work on simplifying the wxwidgets
IPC.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Your development plans for this release cycle

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

Hi Alan,



Apologies for the late answer. The further strengthening of the Cygwin and MinGW-w64/MSYS2 platforms (the latter in its dual guises) is a goal worthwhile to pursue. A similar action could be taken for bare Windows and in conjunction (with perhaps a higher priority, a more extensive testing facility, based on bash and the comprehensive tests already available) - many packages are available but Windows simply does not make it easy to automatically find them, once installed. So that will be the main goal for me.



A secondary goal, which has been on my wishlist for a long time now and with the new Fortran binding nicely into place, is a modernisation of the Tcl binding. There we still use the string-based variant, rather than the Tcl_Obj-based one, which is more efficient.



The first thing for me to do is to reorganise the Windows-specific test facility, however ad-hockish in nature it currently is. I will probably not be able to do much though before next week (attending a conference abroad).



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, January 30, 2017 3:48 AM
> To: Arjen Markus; PLplot development list
> Subject: Your development plans for this release cycle
>
> Hi Arjen:
>
> Now that 5.12.0 has been released, I am writing a series of posts to our active
> developers with this subject line, and you are first in line!.  :-)
>
> If you have some further development in mind for this release cycle, please let us
> know.  In addition, I would appreciate you moving forward on the comprehensive
> testing front on (1) MinGW-w64/MSYS2
> (2) the MinGW-w64 part of MinGW/MSYS2, and (3) MSVC.
>
> 1. MinGW-w64/MSYS2 (using the "MSYS Makefiles" or "Unix Makefiles"
> generator).  This platform is the modern equivalent of the classic MinGW/MSYS
> platform (but with a far larger set of free software libraries available and likely many
> fewer platform bugs).  You have already had partial success with this platform, and
> the trick here is to update that platform with all the development tools (e.g. the
> MingGW-w64 version of cmake and the MSYS2 version of make) and all the
> MingGW-w64 libraries that add power to PLplot to make this test as comprehensive
> as possible.  There is no urgency about this, but nevertheless from my perspective
> (with no release distracting me) now would be and ideal time for you to go ahead
> with this so I can add your full-powered version of this Windows platform to our tally
> at <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> and
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Fortran%20Testing%20Repor
> ts>
>
> 2. MinGW-w64 alone (using the "MinGW Makefiles" generator).  This platform is
> the modern equivalent of MinGW.  Based on my historical experience with that
> platform under Wine, this should "just work" with CMake finding all the native
> libraries built by the MinGW-w64/MSYS2 platform that are needed by PLplot.  So
> this platform should in theory be just as complete as MinGW-w64/MSYS2 and also
> Cygwin.  N.B. The trick to get the testing of PLplot to "just work" on this platform is
> to copy the MSYS2 set of Unix tools (except for sh.exe) to a different directory and
> put that directory on your PATH AFTER the directory pointing to the MinGW-w64
> set of applications such as the MinGW-w64 version of make. The point of this is the
> MinGW-w64 version of make you should be using for this exercise acts quite
> differently if sh.exe is on your PATH.  That is, that version of make apparently does
> not work correctly in a CMD environment unless sh.exe is _not_ available.
> Therefore, the "MinGW Makefiles" generator only works with sh.exe removed from
> the path (as with the above trick).  Thus, this build is done completely under a CMD
> environment with the MinGW-w64 version of make from the
> MinGW-w64/MSYS2 platform rather than the MSYS2 version of make from that
> platform, but the tests are run using bash.exe and other MSYS2 Unix applications
> such as cmp.exe, etc. from the MinGW-w64/MSYS2 platform.
>
> 3. MSVC (using the "NMake Makefiles" generator).  I am virtually positive the
> approach described in 2. (which I _know_ works for the classic MinGW platform)
> should work fine also for this platform. (Note in my Wine days I even got jom, a
> parallel build version of nmake to work properly on the classic MinGW platform
> when using the "NMake Makefiles Jom" generator.) With this approach, the actual
> build is done with nmake.exe (or jom.exe) in the CMD environment but all the tests
> are run using bash.exe and other MSYS2 Unix applications such as cmp.exe, etc.,
> from the MinGW-w64/MSYS2 platform.
>
> You commented in December to the effect you think the suggested approach (for 2.
> or 3.) would be somewhat too exotic to be of much use to users.  I mostly agree
> unless you are a Windows user that likes Unix tools.  However, I still argue that you
> personally going to this extra trouble to make comprehensive tests for the MinGW-
> w64 and MSVC platforms will be a big help to PLplot development.  After all, those
> tests comprehensively check whether all components of native windows PLplot built
> (against the native windows MinGW-w64 free software libraries that give PLplot its
> power) and installed with CMake in a CMD environment work properly (at least
> under bash.exe at run time) for all our major configurations.  And if you supplement
> such comprehensive run-time tests under bash.exe with a smaller set of run-time
> tests under a CMD environment like you have done recently with the windows batch
> file, scripts/run_examples_windows.bat, then it could be argued you have a really
> strong test result since anything possible under bash.exe at run time should also
> work fine under CMD at run time. So that combined test result will be a big benefit
> to users of the MinGW-w64 platform who avoid using any of the MSYS2 unix
> components from the full MinGW-w64/MSYS2 platform.  And a similar argument
> can be made in the MSVC case assuming you can get comprehensive testing of
> what you build there with nmake in a CMD environment to work at run-time as
> outlined in 3.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux
> Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Important new evidence concerning the remaining Linux inefficiency issues for wxwidgets

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

Hi Phil:

The wxwidgets IPC (inter process communication) improvements I have
just started working on are suddenly less urgent because some new
evidence (see below) indicates the cause of the Linux inefficiency
issue has nothing to do with IPC!

To remind you of what that (remaining Linux inefficiency) problem is, here
are timing results for example 8 for current master.

I first built test_c_xcairo and test_c_wxwidgets to get all
prerequisites built properly.  Then

software@raven> time(examples/c/x08c -dev xcairo -np)

real    0m2.128s
user    0m1.896s
sys     0m0.040s
software@raven> time(examples/c/x08c -dev wxwidgets -np)

real    0m13.423s
user    0m0.224s
sys     0m0.024s

Note the ~13 seconds of time when my cpus were completely idle for the
-dev wxwidgets -np test, and my cpumeter confirmed that result (i.e.,
it barely twitched from dead idle through most of this time). Of
course, the above timing results just measures examples/c/x08c and
-dev wxwidgets and ignores wxPLViewer, but that widget is quite
inefficient for this example as well because it remained on my screen
for ~20
seconds after example 8 and -dev wxwidgets had completed.

My initial (naive) view was this order of magnitude inefficiency in both
-dev wxwidgets and wxPLViewer likely had to do with IPC, but that
extra 20 seconds where wxPLViewer continues on after examples/c/x08c
(and therefore -dev wxwidgets) completes indicates there is at least
one big inefficiency that must not have anything to do with IPC.
Furthermore if you drop the -np option you get the following result:

software@raven> time(examples/c/x08c -dev wxwidgets)

real    0m1.067s
user    0m0.236s
sys     0m0.020s

That is, without the -np (nopause) option -dev wxwidgets is faster (!)
than xcairo (as it should be since the rendering done by wxPLViewer is
not counted as part of this time).  That still leaves the order of
magnitude inefficiency of wxPLViewer for this case (it required 30
seconds or so to get this example rendered if I hit the "enter" key as
soon as the plot of one page was completed so this inefficiency
appears to be the same as in the -np case).  But this wxPLViewer
inefficiency _cannot_ have anything to do with IPC since
examples/c/x08c and -dev wxwidgets are completely done and dusted
after ~1 second when no -np option is used.

So it appears likely to me that what is going on for the -np case is
some of the large wxPLViewer inefficieny is slowing down -dev
wxwidgets, i.e., the real culprit is wxPLViewer inefficiency for the
-np case.  Note also that Jim's split of the wait and eop states that
I reinstated recently for -dev xcairo completely changed how the -np
option was handled for that device so addressing that split of wait
and eop for wxwidgets might also make a big difference to the above
-np timing results for -dev wxwidgets (although such a change should
have no effect on the order of magnitude inefficiency of wxPLViewer
itself).

@Phil:

As a result of the above new test results, I hope you agree your own
wxwidgets development plans should include the following two steps as
a matter of some urgency:

1. Implement the wait/eop split for wxwidgets following Jim's work
that was recently reinstated for xcairo.  I would do that myself, but
I don't understand the plbuf/xcairo nuances used by Jim (e.g., why
explicit nopause processing could be removed in xcairo yet the -np
option still clearly works properly for that device), and I don't
understand enough of the wxwidgets device driver to figure out exactly
what part of the current eop processing should be split off into the
new wait routine that must be implemented for -dev wxwidgets.

Anyhow, my feeling is dealing with this issue is a matter of some
urgency since it could potentially kill 3 birds with one stone, i.e.,
(i) the wxwidgets eop issue you were concerned about during the last
few days of the previous release cycle (although ultimately our joint
decision was not to delay the 5.12.0 release due to that issue), (ii)
the background color issue for the first page of example 16, and (iii)
the above order of magnitude inefficieny in -dev wxwidgets only when
the -np option is used. But regardless of these speculations the most
important point is this current inconsistency between plbuf and
wxwidgets should be addressed soon since plbuf now distinguishes
between wait states and eop states and until wxwidgets also follows
that same model we won't know whether some wxwidgets issue we observe
(such as any of the 3 issues above) is due to this current mismatch
between plbuf and wxwidgets or something else.

2. Solve the inefficient rendering (already demonstrated above to have
nothing to do with IPC) currently shown by wxPLViewer for examples
such as example 8 that have many graphical elements to plot. I feel
solving this issue is a matter of urgency since this lack of
wxPLViewer rendering speed (at least when there is anything
complicated to plot as in example 8) will tend to discourage most user
interest in wxwidgets regardless of platform until it is fixed.

Assuming you solve these two important issues in a timely manner, I
promise to follow up with a 5.12.1 release so that wxwidgets users can
quickly benefit from your work.

I have already invested some time in improved IPC for wxwidgets.  I
doubt (from the above evidence) it will improve efficiency very much,
but I still plan to finish this effort simply because the efficient
IPC algorithm I implemented for the cmake/test_linux_ipc miniproject
is much simpler (no mutex, no sleeping) then the IPC algorithm used
now for wxwidgets.

So I will continue updating you on my wxwidgets IPC effort, and I hope
to have it completed in a matter of a week or so.  However, I believe
now your timely resolution of the above two wxwidgets issues is much
more important than my own ongoing work on simplifying the wxwidgets
IPC.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Your development plans for this release cycle

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

To Phil and Pedro:

I was just reminded of an important wxwidgets component issue I forgot
to mention. That issue (see
<https://sourceforge.net/p/plplot/bugs/173/>) is the wxwidgets
component of our software is behind both our qt and cairo components
which use the gradient API of Qt and the pango/cairo suites of
libraries to render linear gradients.  So, for example, the qt and
cairo devices produce really nice-looking results wherever we use
plgradient (e.g., standard examples 25, 30, and (indirectly) 33).  On
the other hand, -dev wxwidgets produces a warning message for those
examples saying it is using our (necessarily lousy) software fallback
for gradients for those examples.  This wxwidgets limitation is not
necessary because the wxwidgets library does have a linear gradient
API.  So removing this limitation would be a very nice improvement for
our wxwidgets component and bring it much closer to the standard set
by our qt and cairo components.

I also suggest you both use the search tool for our bugtracker
<https://sourceforge.net/p/plplot/bugs/> for anything to do with
wxwidgets.  As stated above I think bug 173 should have high priority,
but dealing with any of the rest of the wxwidgets bugs that are still
open would be helpful as well.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Your development plans for this release cycle

[Pedro V. <ped...@sp...>]

Hi Alan
Congratulations on the release.

> For this release cycle I encourage both of you to continue your
> efforts to deal with obvious wxwidgets bugs

ok, will do, as my time permits
Regards

-Pedro

----- Original Message ----- 
From: "Alan W. Irwin" <ir...@be...>
To: "Phil Rosenberg" <p.d...@gm...>; "Pedro Vicente" 
<ped...@sp...>; "PLplot development list" 
<Plp...@li...>
Sent: Monday, January 30, 2017 12:36 AM
Subject: Your development plans for this release cycle


> To Phil and Pedro:
>
> Now that 5.12.0 has been released, I am writing a series of posts to
> our active developers with this subject line.
>
> If either of you has any additional wxwidgets development in mind beyond 
> what I
> discuss below, please let me know.
>
> For this release cycle I encourage both of you to continue your
> efforts to deal with obvious wxwidgets bugs (such as the unexpected
> black rather than expected white background color for the first page
> of example 16) to complement the work I plan to do deal with the last
> of the wxwidgets device driver efficiency issues on Linux. Your goal
> should be that each of our C examples with -dev wxwidgets should
> produce exactly the same results (except possibly for text size) as
> given at <http://plplot.sourceforge.net>/examples.php>.
>
> It would be great if one of you got the currently retired wxpng file
> device going again as an aid for such comparisons with other
> file-based plot results.  But even better would be if you implemented
> a wxwidgets-based SVG device (see
> <https://wiki.wxwidgets.org/WxSVGFileDC>).  The reason I particularly
> mention SVG as a file format is the generated results are written in
> XML and therefore are straightforward to interpret and debug by visual
> comparison of that XML result with other SVG (from -dev svg, -dev
> svgcairo, or -dev svgqt) results for the same standard example.
>
> @Phil: We were all agreed (see the February 2016 thread with the
> subject line "Error report system plus thread safety" that our current
> use of calls to exit() or the equivalent plexit whenever an error
> condition was encountered was an important issue for our
> users using interactive environments, i.e., one PLplot error ==> takes
> down entire interactive work without giving the user a chance to save
> anything ==> one less user interested in using PLplot!
>
> During that thread you were strongly recommending using a
> setjmp()/longjmp() C-based exception model because you are very
> comfortable with using exception handling in C++ and the amount of
> editing required to implement it would be much smaller than the return
> code method.  Although Hazen had a substantially more cautious
> attitude, I was happy to go along with that C exception approach
> rather than the alternative return code method because of my knowledge
> of the extreme length of many of our call/caller graphs and the large
> amount of the work it would be for us to check _all_ calls of _all_
> PLplot functions within our C library code for invalid return codes.
>
> <aside
>   A google search for the search terms <c error handling longjmp setjmp>
>   gives lots of hits.  Phil, I would appreciate you looking at the top
>   several and letting me know which you think is the best for learning
>   about exception handling in C.
> </aside>
>
> The final upshot of that thread was you planned to make a proof of
> concept for us to look at (and help you propagate it to everywhere
> else in our C code during this release cycle if we liked that proof of
> concept). Anyhow, could you please implement that proof of concept
> 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] A possible bug in the extXdrawable_demo application

[Jonathan W. <jw...@ju...>]

Hi Alan

On Mon, Jan 30, 2017 at 11:31:06PM -0800, Alan W. Irwin wrote:
> On 2017-01-30 22:06-0800 Alan W. Irwin wrote:
> 
> [...]
> >Here is the error message you get if you use the -DBUILD_TEST=ON cmake
> >option for the latest (at least commit 6589caa) git master branch
> >version of PLplot and build the test_extXdrawable target which builds
> >extXdrawable_demo and its prerequisites and then runs that
> >application.  The resulting run-time error messages are as follows:
> >
> >The program 'extXdrawable_demo' received an X Window System error.
> >This probably reflects a bug in the program.
> >The error was 'BadWindow (invalid Window parameter)'.
> >  (Details: serial 183 error_code 3 request_code 2 minor_code 0)
> >  (Note to programmers: normally, X errors are reported asynchronously;
> >   that is, you will receive the error a while after causing it.
> >   To debug your program, run it with the --sync command line
> >   option to change this behavior. You can then get a meaningful
> >   backtrace from your debugger if you break on the gdk_x_error() function.)
> >examples/CMakeFiles/test_extXdrawable.dir/build.make:57: recipe for target 'examples/CMakeFiles/test_extXdrawable' failed
> >make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
> >CMakeFiles/Makefile2:5428: recipe for target 'examples/CMakeFiles/test_extXdrawable.dir/all' failed
> >make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
> >CMakeFiles/Makefile2:5435: recipe for target 'examples/CMakeFiles/test_extXdrawable.dir/rule' failed
> >make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
> >Makefile:1846: recipe for target 'test_extXdrawable' failed
> >make: *** [test_extXdrawable] Error 2
> >
> >Would you be willing to take a look at this error to see if you can
> >figure out a fix?
> 
> To Jonathan and Phil:
> 
> @Jonathan:
> 
> Never mind.  I thought a bit more about this issue and concentrated
> specifically on how Jim's change to the xcairo device code could
> affect the extXdrawable_demo application alone, and after looking at
> the problem that way, the solution was easy.  It turned out that the
> split of handling of eop state and wait state had a easy-to-fix bug
> (see commit 5b52716 for details) that just affected extXdrawable_demo,
> and the net result is the above run-time error has now been completely
> addressed.

Our emails crossed in transit.  It's great that the problem turned out to be
so easily fixed.

> (It's amazing how often that happens; you take the time to explain the
> symptoms of a bug to someone else, and the brain keeps working on it
> subconciously and comes up with a fix as in this case.)

Absolutely.  I see (and experience) that sort of thing all the time. :-)

Thanks for letting me know.

Regards
  jonathan

Re: [Plplot-devel] A possible bug in the extXdrawable_demo application

[Jonathan W. <jw...@ju...>]

Hi Alan

On Mon, Jan 30, 2017 at 10:06:18PM -0800, Alan W. Irwin wrote:
> It has been a while since you have been in contact with the
> plplot-devel mailing list so I hope this email address for you
> still works.

All good.  I've been lurking on the list as a way of keeping an eye on
developments.

> An issue has emerged with the extXdrawable_demo application
> that you donated way back in 2008 to PLplot. What happened was Jim
> Dishaw made a significant plbuf change in 2015 such that interactive
> devices are supposed to distinguish between end of page and and wait
> states.  So every interactive device had to be adjusted for this
> change.  When that adjustment was done for xcairo, the results are
> good for -dev xcairo and the ext-cairo-test application you can build
> and run by building the test_extcairo target.  However, the
> extXdrawable_demo application that you can build and run by building
> the test_extXdrawable target does generate a run-time error that was not
> there before the cairo adjustment.

Interesting.  There are clearly a large number of variables in play here.
Tracking this down could be time consuming.

> However, I have now reinstated that change (commit 6589caa) because all
> seems well with xcairo and the ext-cairo-test application so I feel the
> chances are good there is a subtle bug in extXdrawable_demo.

There could be.  Other options (in no particular order, and by no means
exhaustive):
 - A GTK thing which happens to be tickled by whatever change was made
   to the xcairo plplot driver as a result of commit 6589caa.
 - A change in the way the xcairo driver handles the external_drawable
   driver option in light of 6589caa.
 - Altered timing as a result of 6589caa which invalidates assumptions
   made in extXdrawable_demo.c about the order of X resource creation during
   program start up.

I also note that ext-cairo-test uses the "extcairo" plplot device while
extXdrawable_demo uses the "xcairo" device.  It's too long ago for me to
remember what the differences are between these two and how much code they
share.  This means that at first glance the problem could be in the "xcairo"
device rather than extXdrawable_demo itself.  In other words:

 - ext-cairo-test with extcairo: ok
 - extXdrawable_demo with xcairo: not ok

> Here is the error message you get if you use the -DBUILD_TEST=ON cmake
> option for the latest (at least commit 6589caa) git master branch
> version of PLplot and build the test_extXdrawable target which builds
> extXdrawable_demo and its prerequisites and then runs that
> application.  The resulting run-time error messages are as follows:
> 
> The program 'extXdrawable_demo' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadWindow (invalid Window parameter)'.
>   (Details: serial 183 error_code 3 request_code 2 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() function.)

I'm not hugely familiar with low level X programming.  It seems most likely
that this is a timing problem: plplot is probably trying to use something
before it's ready.  Given that the error code is "BadWindow" it is most
likely plplot is trying to use a window (in the X sense) before it's been
created by the X server.  A request_code of 2 is X_ChangeWindowAttributes.

> Would you be willing to take a look at this error to see if you can
> figure out a fix?

I'll see what I can do, but it might be next week before I have an
opportunity to do so.

Regards
  jonathan

Re: [Plplot-devel] A possible bug in the extXdrawable_demo application

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

On 2017-01-30 22:06-0800 Alan W. Irwin wrote:

[...]
> Here is the error message you get if you use the -DBUILD_TEST=ON cmake
> option for the latest (at least commit 6589caa) git master branch
> version of PLplot and build the test_extXdrawable target which builds
> extXdrawable_demo and its prerequisites and then runs that
> application.  The resulting run-time error messages are as follows:
>
> The program 'extXdrawable_demo' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadWindow (invalid Window parameter)'.
>   (Details: serial 183 error_code 3 request_code 2 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() function.)
> examples/CMakeFiles/test_extXdrawable.dir/build.make:57: recipe for target 'examples/CMakeFiles/test_extXdrawable' failed
> make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
> CMakeFiles/Makefile2:5428: recipe for target 'examples/CMakeFiles/test_extXdrawable.dir/all' failed
> make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
> CMakeFiles/Makefile2:5435: recipe for target 'examples/CMakeFiles/test_extXdrawable.dir/rule' failed
> make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
> Makefile:1846: recipe for target 'test_extXdrawable' failed
> make: *** [test_extXdrawable] Error 2
>
> Would you be willing to take a look at this error to see if you can
> figure out a fix?

To Jonathan and Phil:

@Jonathan:

Never mind.  I thought a bit more about this issue and concentrated
specifically on how Jim's change to the xcairo device code could
affect the extXdrawable_demo application alone, and after looking at
the problem that way, the solution was easy.  It turned out that the
split of handling of eop state and wait state had a easy-to-fix bug
(see commit 5b52716 for details) that just affected extXdrawable_demo,
and the net result is the above run-time error has now been completely
addressed.  (It's amazing how often that happens; you take the time to
explain the symptoms of a bug to someone else, and the brain keeps
working on it subconciously and comes up with a fix as in this case.)

@Phil: I believe this only leaves the wxwidgets device driver that
still needs to be adjusted for Jim's plbuf change to split the
handling of the former eop state into handling of the new eop and wait
states.

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] A possible bug in the extXdrawable_demo application

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

Hi Jonathan:

It has been a while since you have been in contact with the
plplot-devel mailing list so I hope this email address for you
still works.

An issue has emerged with the extXdrawable_demo application
that you donated way back in 2008 to PLplot. What happened was Jim
Dishaw made a significant plbuf change in 2015 such that interactive
devices are supposed to distinguish between end of page and and wait
states.  So every interactive device had to be adjusted for this
change.  When that adjustment was done for xcairo, the results are
good for -dev xcairo and the ext-cairo-test application you can build
and run by building the test_extcairo target.  However, the
extXdrawable_demo application that you can build and run by building
the test_extXdrawable target does generate a run-time error that was not
there before the cairo adjustment.

Jim could not find the reason for the run-time issue for
extXdrawable_demo so we reverted his change to cairo for the 5.11.1
release of PLplot back in 2015.  However, I have now reinstated that
change (commit 6589caa) because all seems well with xcairo and the
ext-cairo-test application so I feel the chances are good there is a
subtle bug in extXdrawable_demo.  If that is the case, I feel it is
better to expose this bug to motivate fixing it rather than limping
along with having an xcairo device that was fundamentally inconsistent
in a subtle way with plbuf like we have done (probably in error) for
both the 5.11.1 and 5.12.0 releases of PLplot.

Here is the error message you get if you use the -DBUILD_TEST=ON cmake
option for the latest (at least commit 6589caa) git master branch
version of PLplot and build the test_extXdrawable target which builds
extXdrawable_demo and its prerequisites and then runs that
application.  The resulting run-time error messages are as follows:

The program 'extXdrawable_demo' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
   (Details: serial 183 error_code 3 request_code 2 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() function.)
examples/CMakeFiles/test_extXdrawable.dir/build.make:57: recipe for target 'examples/CMakeFiles/test_extXdrawable' failed
make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
CMakeFiles/Makefile2:5428: recipe for target 'examples/CMakeFiles/test_extXdrawable.dir/all' failed
make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
CMakeFiles/Makefile2:5435: recipe for target 'examples/CMakeFiles/test_extXdrawable.dir/rule' failed
make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
Makefile:1846: recipe for target 'test_extXdrawable' failed
make: *** [test_extXdrawable] Error 2

Would you be willing to take a look at this error to see if you can
figure out a fix?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Your development plans for this release cycle

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

Hi Jim:

On 2017-01-30 10:45-0500 Jim Dishaw wrote:

> I will rebaseline my driver with the newest release and push to the
git repository.  I now have a Windows Vista and a Windows 10 build
environments setup for development and testing.  I also have a high
DPI machine that will help test out the implementation on the
environment.

I look forward to seeing that push.

> I have not been using Freetype—I have been keeping it as pure windows API as I can.

Excellent.

>> I highly recommend that you use the same device driver (called
>> windows?) to implement both devices similarly to the way that the
>> cairo device driver implements so many different devices.  And I can
>> certainly help with all the CMake aspects of discovering whether the
>> current Windows platform supports GDI/Uniscribe and/or
>> Direct2D/DirectWrite and enabling/disabling these two devices and
>> their non-Hershey handling of fonts accordingly.  But we can work out
>> all those details later after an initial development with these
>> (experimental) devices disabled by default.
>>
>
> I have to think about this recommendation.  It sounds like a good idea.

> [out of order] I was planning on using wingdi.c as the filename.

That is fine for now for the driver name, and using "wingdi" for the
device name (in perpetuity) is fine as well.  I now realize that the
above recommendation from me was premature so let's just say the one
driver two devices possibility (along with a driver name and also
source code filename change but not the wingdi device name) is a
possibility to be considered in the future when you start developing
the Direct2D/DirectWrite device.  But for now the focus should be on
finishing the GDI/Uniscribe wingdi driver with just one device
implemented named "wingdi".

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] Error propogation

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

Hi Phil:

On 2017-01-30 11:00-0000 Phil Rosenberg wrote:

> [...] Once we have this first look at how
> setjmp/longjmp can work in our code then I think it will be easier for
> us to make an informed choice about the A options.
>
> Does that sound sensible to people?

Yes.  And to help us follow along with understanding that proof of
concept would you please recommend a good website concerning c error
handling with longjmp/setjmp?  There are an awful lot of hits when you
do a google search for the terms <c error handling longjmp setjmp> so
your help would be most appreciated in picking out which of those
websites (or some other website?) is the best reference for the
purpose of trying to understand your proof of concept.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Your development plans for this release cycle

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

Hi Phil:

On 2017-01-30 10:17-0000 Phil Rosenberg wrote:

> Hi Alan
>
> So I think here are my priorities, in no particular order:
>
> 1) wxWidgets Docs - the driver doc is currently well out of date and
> the binding docs are non-existent. I have rewritten the driver docs
> and started on the bindings. As you said in your release notes the
> docs are probably still a weak point and I'm a firm believer that a
> library is only as good as it's documentation - clever features are no
> god if the users don't know they exist or how to use them.

That is a really good way to express the documentation issue.  I think
we are now headed in the right direction there, but there is still lots
more to do, and I am glad you are planning to help with that task.

>
> 2) The fill bug where the whole plot gets accidentally filled - I
> can't remember if that still exits or if a workaround fix was added.

I will take responsibility for that issue (see my separate post on
that).

>
> 3) I have on my old to do list something about the selectable region
> in x03.3 not being implemented. I should look at that.
>
> 4) Plexit. I agree this really needs sorting. However I found at least
> one side effect that we would need to deal with - I'll send another
> email out immediately after this one.
>
> 5) I'll add that incorrect background colour to my list.
>
> 6) I would like to add some useful additional features to the
> wxPLplotstream API that are particularly wxWidgets relevant. This
> would be some additional overloaded constructors and perhaps some
> features for plotting - for example it would be nice to be able to set
> the actual font face so that in a wxWidgets application a programmer
> could use a font dialog to ask the user which font they would like to
> use and then use it. This isn't currently possible at the moment where
> we just set the family.

These remaining steps all sound good to me.

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-5.12.0 has been released so the push freeze is gone

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

Hi Phil:

On 2017-01-30 09:50-0000 p.d...@gm... wrote:

> Congratulations and well done for getting that out Alan.

Thanks!

The whole release process was more difficult than it normally had been
for me in the past because it had been much too long since the
previous release.  That is the work is typically proportional to the
number of commits since the last release so there are no economies of
scale in accumulating more commits before a release, and if you wait
too long you forget the release process and have to learn parts of it
all over again.  Therefore, assuming the current pace of development
for PLplot remains roughly what it has been, I plan to make at least
one bugfix release (5.12.1) and something like two more major releases
(5.13.0 and 5.14.0) within the next 12 months.

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
__________________________