plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Error propogation

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

> On Jan 30, 2017, at 6:00 AM, Phil Rosenberg <p.d...@gm...> 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 have a patch that consolidated on the errors and warnings into a standardized function call.  I was able to eliminate almost all the exit() calls that were scattered throughout the code  (I think there were a couple that I left).  I was thinking about having an internal API that allowed a driver to hook into that function to override the display and user dialog.  For example, the GUI driver could display a dialog box instead of the I/O happening at the console.
 
> 
> 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().
> 
> 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.
> 
> 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.
> 

My vote is for option A1 or A2.  If the developer does not want to handle errors, then it might not be important.  I think getting all the unwiding done right for the setjmp/longjmp will need a lot of work.  The A2 option mimics the style used in the libc library, so it is a familar paradigm to developers.

> 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.
> 
> B2) Make use of our current plabort call and let the user pass in a
> plabort handler.
> 
> 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.
> 
> B4) In the C++ binding we could throw an error. Not sure if other
> languages have similar throw/catch style options.
> 
> B4) Some combination of the above.
> 
> 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] Your development plans for this release cycle

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

> On Jan 30, 2017, at 3:40 AM, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Jim:
> 
> Now that 5.12.0 has been released, I am writing a series of posts to
> our active developers with this subject line, and it is now your
> turn.  :-)
> 
> By all means please tell us of your plans for the current release
> cycle, but in any case I strongly encourage you to start working again
> on two development topics of yours that have intrigued us all in the
> past. Those are (1) your new interactive windows devices and (2)
> restoring the plmeta device and plrender.
> 
> (1) Your new interactive windows devices
> 
> My understanding is your new windows device driver has one interactive
> device implemented so far that is GDI (or GDI+) based (see
> <https://en.wikipedia.org/wiki/Graphics_Device_Interface> but with no
> Uniscribe (see <https://en.wikipedia.org/wiki/Uniscribe>) support for
> Unicode implemented yet.  Also, you have at least discussed plans to
> add another device to that device driver that would use Direct2D
> <https://en.wikipedia.org/wiki/Direct2D> rather than GDI. and which
> would use the DirectWrite <https://en.wikipedia.org/wiki/DirectWrite>
> approach to search system fonts and render unicode text.  And our
> build system goal would be to interrogate the system to see what was
> available out of all the GDI, Uniscribe, Direct2D, and DirectWrite
> possibilities and then present the available combinations out of the 4
> possibilities (e.g., GDI with and without Uniscribe and Direct2D with
> or without DirectWrite) by default.  But initially every combination
> would be OFF by default, i.e., a user would be forced to enable it
> using the appropriate cmake option (see discussion below).
> 
> Furthermore, it appears this device driver in its present form is at
> least buildable (since you have circulated some patches concerning
> that device).  So I strongly encourage you to go ahead and push your
> new windows device driver to SF master in exactly its present
> development state.  After all, we have a really nice PLplot
> architecture where device driver development can proceed without
> affecting the rest of PLplot so you might as well take advantage of
> that architecture so long as most git users are insulated from build
> errors due to your new device (see the second comment below about how
> to arrange that insulation).  And such a public development approach
> might attract some extra help for you (e.g., I would be happy to help
> with all build system issues.)

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.

> 
> Once you have pushed the current state of your new device driver code,
> I recommend the following further steps.
> 
> * Rename the existing code for the device driver some generic name
>  like windows.c or windows.cpp (depending on which of C or C++
>  you are using to develop it).  Also rename the actual device
>  implemented by that device driver as "winGDI”.

I was planning on using wingdi.c as the filename.

> 
> * Use the flag in cmake/modules/drivers-init.cmake to disable the winGDI
>  device by default.  That simply means that users who want to try it
>  as an experiment would have to enable it explicitly with
>  -DPLD_winGDI=ON.  That's a bit of extra insurance allowing you to
>  continue to develop that device without concerns about how it
>  will affect the rest of us using the git version of PLplot.  For
>  example, if you introduced a build error on some platforms for your
>  new device driver on initial push or after some further development
>  it would not be an urgent matter to fix it because it would not
>  affect that many PLplot git users.  And that "pass" extends to
>  releases as well so long as you keep the devices implemented by the
>  device driver disabled by default.
> 

Got it

> * Tear out any use of plfreetype if you are using it now for Unicode
>  support.  (The wingcc device currently uses that approach to attempt
>  to get access to Windows system fonts, and render them, but that
>  whole (pl)freetype approach is deprecated for very good reasons (see
>  <http://plplot.sourceforge.net/docbook-manual/plplot-html-5.12.0/FreeType-notes.html>)
>  so you should not propagate it to any further devices.
> 

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

> * Keep developing -dev winGDI until you are completely satisfied
>  with its results for the Hershey fonts (the only fonts you
>  would be able to use at this stage).  At that point you can
>  enable -dev winGDI by default.
> 
> * Give -dev winGDI optional (disabled by default) access to Unicode-enabled Windows system fonts
>  using the Uniscribe <https://en.wikipedia.org/wiki/Uniscribe>
>  approach.  Once that component of your winGDI device works enable it by default
>  if Uniscribe is available on the platform, but otherwise disable it.
> 
> * Based on your (then) existing experience with development of -dev winGDI
>  implement an additional device for your "windows" device driver called -dev winDirect2D which is
>  based on Direct2D <https://en.wikipedia.org/wiki/Direct2D> rather
>  than GDI. and which optionally (once Hershey fonts work) uses the
>  DirectWrite <https://en.wikipedia.org/wiki/DirectWrite> approach
>  rather than Uniscribe to give access to Unicode-enabled Windows
>  system fonts.
> 
> 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.

> N.B. The first 3 of these steps should be at most a few hours work, but
> the remaining steps will likely take considerably
> longer, and I emphasize all of these development steps should be done
> publicly using the SF facilities rather than privately since that will
> encourage others to try your new devices (and perhaps help you with
> development), AND there is no way you can
> seriously affect git users of PLplot so long as the devices and
> independently the unicode treatment for each device is disabled
> by default until it is stablized code rather than experimental.
> 
> N.B. Once you are completely happy with -dev winGDI with Uniscribe,
> and assuming that event occurs within this release cycle, I would plan
> to immediately deprecate wingcc for the forthcoming non-bugfix release
> 5.13.0 with the further plan for 5.14.0 to remove the deprecated
> wingcc, gd, and old wxwidgets device drivers and the whole deprecated
> plfreetype approach those deprecated devices depend on.  In other
> words the event of stable -dev winGDI with Uniscribe support will
> trigger a wonderful opportunity for me to remove a lot of cruft from
> PLplot! :-)
> 
> In sum I hope to see the first 3 steps above from you within a few
> days (assuming you have a few hours to work on PLplot right now), and
> I hope to see the 4th and fifth steps abpve completed before the
> release of 5.13.0 (mid 2017?) to start the clock on the cruft removal
> I hope to do for the 5.14.0 release (early 2018?).
> 

Sound reasonable

> 2. Restoring the plmeta device and plrender
> 
> The big complication here (if I am recalling correctly from your
> previous discussions of this topic) is you likely need substantial
> plbuf changes to move forward with this in a way that satisfies the
> "round trip test", i.e., (pl)rendering plmeta results to the plmeta
> form again should yield an identical plmeta result.  And such plbuf
> changes impact all interactive devices and likely most git PLplot
> users.
> 
> However, I think the general approach of making the plbuf change and
> adjusting all devices for that change is the best you can do. The only
> caveat is there must be plenty of testing time before the release to
> test your changes for each of the devices.  That was the approach you
> used last time for your last plbuf change and it generally worked.  Of
> course, for some reason wxwidgets slipped through the cracks and did
> not get adjusted but presumably Phil will be dealing with that issue
> shortly. And we had to temporarily remove the cairo adjustment because
> it clobbered one of the cairo special examples.  But the cairo device
> driver worked fine with that change and your best guess at the time
> was you were simply uncovering an existing bug in the cairo special
> example.  So I plan to put back the cairo adjustment shortly and
> simply disable the special cairo example instead (until somone figures
> out what the real issue is for that example).
> 
> But it is obviously a good idea to wait until Phil adjusts the
> wxwidgets device driver and I restore your adjustment for the cairo
> device driver before you change plbuf some more.
> 

I think it is best to wait until Phil finishes his work on wxwidgets

[Plplot-devel] Fill issue

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

To Phil:

You said:

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

Thanks for reminding me of that rather complex fill issue.  No fix has
been done yet so that issue
should still be with us.  I had already started to sort out some of the
preliminaries on a private topic branch, but I shut that down due to
lack of time leading up to 5.12.0, but I plan to restart that effort
early in this current (major) release cycle as promised back when I
had to shut it down. An additional constraint is we need lots of time
to test any solution to this issue to make sure we haven't turned a
fairly acceptable situation (only your two reports of fill issues for
rather special conditions over the many years since the fill code was
last changed) worse.  So ideally the definitive fill fix should be
implemented soon, but we should test it for a long time.  So my
initial plan is to leave this fill fix out of any quick bug fix
release (5.12.1) for wxwidgets fixes and other quick and simple fixes,
and only release this fill fix as part of the next major release
(5.13.0).

My first big priority (beyond some minor stuff) is the remaining Linux
inefficiency issues for wxwidgets, but very high on my priority list
after that comes restarting my fill branch and implementing a
definitive solution to the fill issue that is extremely well tested
and which we can all therefore trust.  By the way, one test I am
considering is for a rather complex and random fill pattern center a
small clip box in a random part of the space filled by that pattern.
Then make an animated GIF movie of the fill patterns that result as
that clip box is smoothly expanded.  The fills should mostly be
continuous as that clip box is expanded so I am pretty sure such a
movie would give the eye a chance to quickly evaluate whether our fill
algorithm is working properly for a given random pattern superimposed
on a clipping square of arbitrary size relative to the pattern. Then
move on to the next random fill pattern and run the test again, for
say 100 different random fill patterns.

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

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

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().

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.

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.

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.

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

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.

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

B4) Some combination of the above.

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

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

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

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.

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.

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.

I think that's most of it. We will see how fast I can make progress.

Phil

On 30 January 2017 at 05:36, Alan W. Irwin <ir...@be...> wrote:
> 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] PLplot-5.12.0 has been released so the push freeze isgone

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

Congratulations and well done for getting that out Alan.

Here’s to continuing to push PLplot to be as good as it can be.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 30 January 2017 01:22
To: PLplot development list
Subject: [Plplot-devel] PLplot-5.12.0 has been released so the push freeze isgone

I have made the official announcement concerning the PLplot-5.12.0
release on the plplot-general list, and I thank all of you who helped
during this last release cycle (with the total number of commits near
400!) to create and test this release.

Obviously, the push freeze required for the release has now been
removed so I highly encourage all of you to mature your various
development topics and (for official developers) push them to SF
master or (for other developers) create a patch or patches concerning
your topic using "git format-patch" (see README.developers) and send
that patch (or patches) to this list as a compressed attachment for
review.

What a mental relief to get this 5.12.0 release done! I am especially
proud of the work I did late in the release cycle of rewriting large
parts of the DocBook documentation for this release.  The issue that I
discovered time and again (with some outstanding exceptions such as
the Ada and Fortran documentation) was a lot of that documentation had
been written in the early 90's and therefore had little relevance any
more.  Even after all of that large rewriting effort (which was
equivalent to rewriting much of a 300-page [!] technical book), there
is still more to be done. So our documentation is likely still the
weakest part of PLplot and the largest barrier to adoption by new
users.  So _please_ if you care about attracting new PLplot users
(which you should do since that is where help for the next generation
of PLplot will be coming from) look over the rewritten documentation
(at <http://plplot.sourceforge.net/documentation.php>), and if you
spot any remaining issues (especially any obviously dated chapters)
please go ahead and update the relevant file in doc/docbook/src and
push the result or circulate the patch here as appropriate.

For my initial development work for this release cycle I plan to try
to solve the remaining Linux inefficiency issues for wxwidgets. (I am
giving top PLplot priority to that development topic because I think
once those Linux inefficiency issues are completely solved, then our
wxwidgets device will start competing with our other two high-quality
interactive devices (cairo and qt) and could potentially attract a lot
of new Linux wxwidgets users to PLplot.) Furthermore, if that
development topic is a success, I plan to create a bug-fix release
(5.12.1) containing that fix, any additional fixes concerning
wxwidgets that Phil and Pedro come up with, and any other PLplot bug
fixes that are made between now and then.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

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

Hi Jim:

Now that 5.12.0 has been released, I am writing a series of posts to
our active developers with this subject line, and it is now your
turn.  :-)

By all means please tell us of your plans for the current release
cycle, but in any case I strongly encourage you to start working again
on two development topics of yours that have intrigued us all in the
past. Those are (1) your new interactive windows devices and (2)
restoring the plmeta device and plrender.

(1) Your new interactive windows devices

My understanding is your new windows device driver has one interactive
device implemented so far that is GDI (or GDI+) based (see
<https://en.wikipedia.org/wiki/Graphics_Device_Interface> but with no
Uniscribe (see <https://en.wikipedia.org/wiki/Uniscribe>) support for
Unicode implemented yet.  Also, you have at least discussed plans to
add another device to that device driver that would use Direct2D
<https://en.wikipedia.org/wiki/Direct2D> rather than GDI. and which
would use the DirectWrite <https://en.wikipedia.org/wiki/DirectWrite>
approach to search system fonts and render unicode text.  And our
build system goal would be to interrogate the system to see what was
available out of all the GDI, Uniscribe, Direct2D, and DirectWrite
possibilities and then present the available combinations out of the 4
possibilities (e.g., GDI with and without Uniscribe and Direct2D with
or without DirectWrite) by default.  But initially every combination
would be OFF by default, i.e., a user would be forced to enable it
using the appropriate cmake option (see discussion below).

Furthermore, it appears this device driver in its present form is at
least buildable (since you have circulated some patches concerning
that device).  So I strongly encourage you to go ahead and push your
new windows device driver to SF master in exactly its present
development state.  After all, we have a really nice PLplot
architecture where device driver development can proceed without
affecting the rest of PLplot so you might as well take advantage of
that architecture so long as most git users are insulated from build
errors due to your new device (see the second comment below about how
to arrange that insulation).  And such a public development approach
might attract some extra help for you (e.g., I would be happy to help
with all build system issues.)

Once you have pushed the current state of your new device driver code,
I recommend the following further steps.

* Rename the existing code for the device driver some generic name
   like windows.c or windows.cpp (depending on which of C or C++
   you are using to develop it).  Also rename the actual device
   implemented by that device driver as "winGDI".

* Use the flag in cmake/modules/drivers-init.cmake to disable the winGDI
   device by default.  That simply means that users who want to try it
   as an experiment would have to enable it explicitly with
   -DPLD_winGDI=ON.  That's a bit of extra insurance allowing you to
   continue to develop that device without concerns about how it
   will affect the rest of us using the git version of PLplot.  For
   example, if you introduced a build error on some platforms for your
   new device driver on initial push or after some further development
   it would not be an urgent matter to fix it because it would not
   affect that many PLplot git users.  And that "pass" extends to
   releases as well so long as you keep the devices implemented by the
   device driver disabled by default.

* Tear out any use of plfreetype if you are using it now for Unicode
   support.  (The wingcc device currently uses that approach to attempt
   to get access to Windows system fonts, and render them, but that
   whole (pl)freetype approach is deprecated for very good reasons (see
   <http://plplot.sourceforge.net/docbook-manual/plplot-html-5.12.0/FreeType-notes.html>)
   so you should not propagate it to any further devices.

* Keep developing -dev winGDI until you are completely satisfied
   with its results for the Hershey fonts (the only fonts you
   would be able to use at this stage).  At that point you can
   enable -dev winGDI by default.

* Give -dev winGDI optional (disabled by default) access to Unicode-enabled Windows system fonts
   using the Uniscribe <https://en.wikipedia.org/wiki/Uniscribe>
   approach.  Once that component of your winGDI device works enable it by default
   if Uniscribe is available on the platform, but otherwise disable it.

* Based on your (then) existing experience with development of -dev winGDI
   implement an additional device for your "windows" device driver called -dev winDirect2D which is
   based on Direct2D <https://en.wikipedia.org/wiki/Direct2D> rather
   than GDI. and which optionally (once Hershey fonts work) uses the
   DirectWrite <https://en.wikipedia.org/wiki/DirectWrite> approach
   rather than Uniscribe to give access to Unicode-enabled Windows
   system fonts.

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.

N.B. The first 3 of these steps should be at most a few hours work, but
the remaining steps will likely take considerably
longer, and I emphasize all of these development steps should be done
publicly using the SF facilities rather than privately since that will
encourage others to try your new devices (and perhaps help you with
development), AND there is no way you can
seriously affect git users of PLplot so long as the devices and
independently the unicode treatment for each device is disabled
by default until it is stablized code rather than experimental.

N.B. Once you are completely happy with -dev winGDI with Uniscribe,
and assuming that event occurs within this release cycle, I would plan
to immediately deprecate wingcc for the forthcoming non-bugfix release
5.13.0 with the further plan for 5.14.0 to remove the deprecated
wingcc, gd, and old wxwidgets device drivers and the whole deprecated
plfreetype approach those deprecated devices depend on.  In other
words the event of stable -dev winGDI with Uniscribe support will
trigger a wonderful opportunity for me to remove a lot of cruft from
PLplot! :-)

In sum I hope to see the first 3 steps above from you within a few
days (assuming you have a few hours to work on PLplot right now), and
I hope to see the 4th and fifth steps abpve completed before the
release of 5.13.0 (mid 2017?) to start the clock on the cruft removal
I hope to do for the 5.14.0 release (early 2018?).

2. Restoring the plmeta device and plrender

The big complication here (if I am recalling correctly from your
previous discussions of this topic) is you likely need substantial
plbuf changes to move forward with this in a way that satisfies the
"round trip test", i.e., (pl)rendering plmeta results to the plmeta
form again should yield an identical plmeta result.  And such plbuf
changes impact all interactive devices and likely most git PLplot
users.

However, I think the general approach of making the plbuf change and
adjusting all devices for that change is the best you can do. The only
caveat is there must be plenty of testing time before the release to
test your changes for each of the devices.  That was the approach you
used last time for your last plbuf change and it generally worked.  Of
course, for some reason wxwidgets slipped through the cracks and did
not get adjusted but presumably Phil will be dealing with that issue
shortly. And we had to temporarily remove the cairo adjustment because
it clobbered one of the cairo special examples.  But the cairo device
driver worked fine with that change and your best guess at the time
was you were simply uncovering an existing bug in the cairo special
example.  So I plan to put back the cairo adjustment shortly and
simply disable the special cairo example instead (until somone figures
out what the real issue is for that example).

But it is obviously a good idea to wait until Phil adjusts the
wxwidgets device driver and I restore your adjustment for the cairo
device driver before you change plbuf some 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
__________________________

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

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

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
__________________________

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

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

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%20Reports>

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
__________________________

[Plplot-devel] PLplot-5.12.0 has been released so the push freeze is gone

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

I have made the official announcement concerning the PLplot-5.12.0
release on the plplot-general list, and I thank all of you who helped
during this last release cycle (with the total number of commits near
400!) to create and test this release.

Obviously, the push freeze required for the release has now been
removed so I highly encourage all of you to mature your various
development topics and (for official developers) push them to SF
master or (for other developers) create a patch or patches concerning
your topic using "git format-patch" (see README.developers) and send
that patch (or patches) to this list as a compressed attachment for
review.

What a mental relief to get this 5.12.0 release done! I am especially
proud of the work I did late in the release cycle of rewriting large
parts of the DocBook documentation for this release.  The issue that I
discovered time and again (with some outstanding exceptions such as
the Ada and Fortran documentation) was a lot of that documentation had
been written in the early 90's and therefore had little relevance any
more.  Even after all of that large rewriting effort (which was
equivalent to rewriting much of a 300-page [!] technical book), there
is still more to be done. So our documentation is likely still the
weakest part of PLplot and the largest barrier to adoption by new
users.  So _please_ if you care about attracting new PLplot users
(which you should do since that is where help for the next generation
of PLplot will be coming from) look over the rewritten documentation
(at <http://plplot.sourceforge.net/documentation.php>), and if you
spot any remaining issues (especially any obviously dated chapters)
please go ahead and update the relevant file in doc/docbook/src and
push the result or circulate the patch here as appropriate.

For my initial development work for this release cycle I plan to try
to solve the remaining Linux inefficiency issues for wxwidgets. (I am
giving top PLplot priority to that development topic because I think
once those Linux inefficiency issues are completely solved, then our
wxwidgets device will start competing with our other two high-quality
interactive devices (cairo and qt) and could potentially attract a lot
of new Linux wxwidgets users to PLplot.) Furthermore, if that
development topic is a success, I plan to create a bug-fix release
(5.12.1) containing that fix, any additional fixes concerning
wxwidgets that Phil and Pedro come up with, and any other PLplot bug
fixes that are made between now and then.

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] I plan to release on Saturday unless a few more days delay would help you

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

Hi Phil:

On 2017-01-28 10:46-0000 p.d...@gm... wrote:

> Hi Alan
> Sorry for taking so long to reply. Feel free to go ahead and release.

Now that I am awake again, I think it will only be a few more hours
until I get the release done.

> Earlier this week I had a bit more of a look at the replot issue and
I think that in reality the current behaviour is fine for now, but can
be sorted for next release. Everything works providing plreplot is
called before pladv. So I don't intend to do anything further there
right now.

Further wxwidgets changes are obviously post-release material now, but
it does bother me that the wxwidgets device has not yet been adjusted
for Jim's plbuf change while it was necessary to change every other
interactive device at that time.  So can you at least do that
adjustment now on a topic branch, and let me know whether it solves
the issue that was concerning you and/or the background color issue
(black rather than white) for the first page of example 16?

> I'm about half way through the documentation changes. I can commit
progress so far in the next hour or so if you think that is worth
doing.

Thanks for that offer, but I think it is better to finish up your
wxwidgets documentation effort completely on a private topic branch
and wait to push it until after this release.

Note, I have some urgent post-release plans of my own concerning
wxwidgets (moving to the POSIX unnamed semaphore method of IPC).  If
that idea works as I expect (i.e., solves the remaining Linux
inefficiency issues for our standard examples where relatively large
amounts of data are transferred with IPC), then I would be keen to
create a bug-fix release just for that change as well as any other
wxwidgets development you have finished by then including the
wxwidgets adjustment for the plbuf change and wxwidgets documentation
effort mentioned above.

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] I plan to release on Saturday unless a few more days delay would helpyou

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

Hi Alan
Sorry for taking so long to reply. Feel free to go ahead and release.

Earlier this week I had a bit more of a look at the replot issue and I think that in reality the current behaviour is fine for now, but can be sorted for next release. Everything works providing plreplot is called before pladv. So I don't intend to do anything further there right now.

I'm about half way through the documentation changes. I can commit progress so far in the next hour or so if you think that is worth doing.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 26 January 2017 18:49
To: Phil Rosenberg; PLplot development list
Subject: I plan to release on Saturday unless a few more days delay would helpyou

Hi Phil:

Since we have been delaying the release for your wxwidgets fix in any
case for the last several weeks, I decided to use that time to rewrite
the advanced chapter of our DocBook documentation.  However, yesterday
I finished a particularly tricky section of that (on color management)
and there are some more changes I need to do on the 3D plotting
section, but that is absolutely all I intend to do on the
documentation for this release.  I therefore hope to go ahead with
this release on Saturday in the interest of (a) getting it off our
collective backs, (b) dropping the push freeze so that normal
development can continue, and (c) making all the work we have done in
this release cycle readily available to our users.

So what progress have you made on the 4 wxwidgets areas you
were planning to work on for these last several weeks?

Those areas were (in decreasing order of how critical to the release
they are)

1. A paragraph in README.release summarizing the wxwidgets changes
since PLplot-5.11.1.

2. Adjust the wxwidgets device driver for the wait/eop split
in plbuffer that Jim implemented some time ago and circulate that
patch.

3. Thorough re-test of wxwidgets using that patch on all platforms
(with aid from Pedro and me) and push it if those tests are good.

4. Update our DocBook documentation with regard to wxwidgets.

If it turns out you cannot do anything on any of the above in a timely
manner because of other time pressures on you, I would strongly prefer
to just proceed on Saturday with the release without those wxwidgets
issues addressed. Then once you address at least the first three of
these, I would be willing to make a PLplot bug-fix release (although
there would be some significant git learning on my part required to
figure out how to use the required git cherry-pick command.)

So unless I hear from you that a few more days delay on the release
would be a significant benefit to you, I plan to just go ahead with the
release on Saturday.

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] I plan to release 5.12.0 tomorrow (Saturday)

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

Since Phil has not responded to my question concerning whether a few
more days would help him get his desired wxwidgets changes in, I
assume that sort of release delay would not help him.  Therefore, I am
going ahead with the release process for 5.12.0, and I plan to deal
with the remaining wxwidgets issue(s) post release (and likely with a
bug-fix release rather than full release in the interest of making
Phil's fixes available to wxwidgets users of PLplot in a timely manner
after he makes those fixes available for testing).

N.B. We are now in deep freeze, that is no pushes should be made to
our master branch except in consultation with the release manager
(i.e., yours truly).  And in most cases I will likely say no.  For
example, earlier today I debated about help string updates for our
python and octave bindings that would make those strings consistent
with the latest api.xml changes.  Eventually I decided to push those
(since api.xml is in much better shape now then it was for
plplot-5.11.1) but only after fairly extensive python and octave
testing using the test_diff_psc target (just in the extremely unlikely
event that the changed help strings could somehow screw up the
bindings) and also using the recently updated test procedure in
doc/docbook/README.developers to test those python and octave help
strings.

I still appear to be on schedule for the release of 5.12.0 tomorrow.
For example, I just now finished my last planned update to the release
notes (README.release) so I am roughly half way through the release
process now as detailed in README.Release_Manager_Cookbook.  So it is
going well, but this is a fundamentally unpredictable process so we
will see how soon I will be able to finish this.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] I plan to release on Saturday unless a few more days delay would help you

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

Hi Phil:

Since we have been delaying the release for your wxwidgets fix in any
case for the last several weeks, I decided to use that time to rewrite
the advanced chapter of our DocBook documentation.  However, yesterday
I finished a particularly tricky section of that (on color management)
and there are some more changes I need to do on the 3D plotting
section, but that is absolutely all I intend to do on the
documentation for this release.  I therefore hope to go ahead with
this release on Saturday in the interest of (a) getting it off our
collective backs, (b) dropping the push freeze so that normal
development can continue, and (c) making all the work we have done in
this release cycle readily available to our users.

So what progress have you made on the 4 wxwidgets areas you
were planning to work on for these last several weeks?

Those areas were (in decreasing order of how critical to the release
they are)

1. A paragraph in README.release summarizing the wxwidgets changes
since PLplot-5.11.1.

2. Adjust the wxwidgets device driver for the wait/eop split
in plbuffer that Jim implemented some time ago and circulate that
patch.

3. Thorough re-test of wxwidgets using that patch on all platforms
(with aid from Pedro and me) and push it if those tests are good.

4. Update our DocBook documentation with regard to wxwidgets.

If it turns out you cannot do anything on any of the above in a timely
manner because of other time pressures on you, I would strongly prefer
to just proceed on Saturday with the release without those wxwidgets
issues addressed. Then once you address at least the first three of
these, I would be willing to make a PLplot bug-fix release (although
there would be some significant git learning on my part required to
figure out how to use the required git cherry-pick command.)

So unless I hear from you that a few more days delay on the release
would be a significant benefit to you, I plan to just go ahead with the
release on Saturday.

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] We apparently now have floating-point consistency which we should take advantage of for testing purposes

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

I just made a wonderful discovery today as a result of a thread on the
MinGW/MSYS mailing list where a guy claimed that he generated
consistent unrounded floating-point results with gcc and other
compilers (Borland and MSVC?) for massive (many hours) floating-point
computations regardless of the optimizations for those compilers (so
long as he stuck with the usual simple numerical -O optimizations and
didn't use exotic optimization parameters).  That contradicted all I
"knew" from our experience several years ago where even changing the
simple optimization level from -O0 to -O1 affected our PostScript
results. So I made a new test today and indeed the -O0 and -O3 results
agree exactly for all our standard C examples using gcc (Debian
4.9.2-10).  So that result is consistent with his.  Furthermore, if
his more general result really does hold up for all C compilers
accessible to us, that is going to be a huge breakthrough in our
testing (i.e., we should be able to generate and distribute a tarball
of SVG or PostScript results that every platform should be able to
reproduce exactly).

Anyhow, after the current release is completed I plan to circulate
such a tarball to developers here to see whether we do really get the
same C results for all our standard examples for all compilers
accessible to us.  And if that consistency is confirmed, then some
substantial changes in our testing procedure should be implemented
that take advantage of that new floating-point consistency capability
of C compilers.

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] plreplot and clearing the page (jim please read if you'e around)

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

> On Jan 12, 2017, at 3:49 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2017-01-12 16:17-0000 Phil Rosenberg wrote:
>> 
>> I think I've found the issue with clearing the page when using plreplot.
>> Basically the issue is that the driver bop function is not being
>> called, because at the point of replaying the buffer, the stream is
>> already at the beginning of page. This means that the driver does not
>> clear the page.
>> 
>> There is a line in plFlushBuffer() which calls plP_eop() to avoid
>> exactly this behaviour, however it is commented out. Using git blame I
>> found the commit that commented the line out
>> 
>> commit 5867959e87e64e08ed2ed57bc66a3cfa6e22450f
>> Author: Jim Dishaw <ji...@di...>
>> Date:   Mon Jun 15 12:10:04 2015 -0400
>>   Fix to the multiple keypress bug on page advance
>>   - The "wait for user input" is not part of an EOP.
>>     -- A new function plP_wait() was created
>>     -- plP_wait() calls were added next to plP_eop() calls to generate
>>        a wait (if specified by nopause) after an EOP event
>>   - The plot buffer was modified to insert an EOP into the buffer
>>     -- No wait is inserted into the plot buffer because the plot buffer
>>        only regenerates plots
>>   - A new entry was added to the PLDispatchTable for the wait function
>>     -- The table initialization sets all function pointers to NULL via
>>        a memset
>>     -- If a driver does not specify a wait function, either it is not
>>        needed (e.g. the ps driver) or it is part of the EOP handler
>>        (legacy behavior)
>>   - The following drivers were modified to support the new
>> implementation: cairo, qt, tkwin, and xwin.  The wingcc update will be
>> in a seperate fix.
>> 
>> It's not entirely clear from the message, however it looks to me like
>> this line was commented out to avoid odd behaviour when nopause was
>> specified, but then Jim has fixed that issue in a different way and
>> then perhaps forgotten to uncomment this line???
>> 
>> Jim, I know it's a long time ago when we were fixing the buffer, I
>> don't suppose you have any memories of this? I have some vague ones
>> but nothing concrete.
>> 
>> Basically I'd like to put that line back for the upcoming release
>> because I have code that is using plreplot that is currently broken
>> because of this issue. I don't know what anyone thinks of that or what
>> anyone thinks is an appropriate set of tests to do to ensure there
>> isn't any odd side effects.
> 
> To Phil and Jim:
> 
> It would be great if Jim responded, but in addition this change was
> thoroughly discussed at the time.  To refresh your memories of that discussion
> both of you should look at the June 2015 plplot-devel mailing list threads
> entitled "The multiple keypress problem when using interactive
> drivers" and (especially) "Bug fix to plbuf.c".
> 
> I have just re-read those threads myself, and although I don't follow
> all the technical issues it looks like Phil agreed at that time this
> was a complex issue that Jim was facing.  Ultimately with Phil's and
> my encouragement Jim pushed his solution 2 (which he classified as the
> more elegant one).
> 
> That solution did require further device driver work for some of the
> the interactive devices.  Jim supplied those changes for wingcc,
> cairo, qt, xwin, and tkwin, but the implication was Phil would have to
> appropriately modify the wxwidgets driver (or wxPLViewer?) himself.
> 
> @Phil: Is the wxwidgets issue you have recently discovered simply because you
> never followed up with that required change?
> 

This is one of those whack-a-mole bugs and the correct fixed required some changes in the driver, as Alan pointed out.  At the time I didn't make changes to the wxwidgets driver because it was being reworked at the time.

The change for the driver entails implementing a wait for user input function, that is called by the plP_wait() function. 

> 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] plreplot and clearing the page (jim please read ifyou'e around)

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

Hi Phil:

On 2017-01-13 08:48-0000 p.d...@gm... wrote:

> Thanks Alan, I'll review those emails.

Good.

Here is my understanding from reviewing those e-mails and looking at
code.

I think the qt device driver is a good model for what has to be done.
So if you look at Jim's changes for it, via

git diff 5867959e^..5867959e drivers/qt.cpp

you will see no changes for any of the noninteractive devices, but for
the qtwidget device what happened previously in the eop code is now
split into an "eop" routine that only exercises "non-wait" code and a
"wait" routine that exercises all former eop code that waits.

Currently there is no such wait routine in drivers/wx*.cpp, but I
think you might need it since what is currently called
wxPLDevice::EndPage has logic that depends on pls->nopause. So it
appears that what you need to do is to follow what was done for qt and
split all such wait code that is currently exercised by the eop
routine into its own wait routine.

If you agree this is the right way to go, then please go ahead with
the implementation but also exercise extreme caution about pushing it,
i.e., wait until you, Pedro, and I have thoroughly tested it on all
platforms by building _both_ the test_c_wxwidgets (which exercises a
subset of the examples with -dev wxwidgets and the -np option) and
test_wxPLplotDemo targets on Linux and also by running one example
with -dev wxwidgets on that platform without the -np option, and by
doing the equivalent tests (running at least one example with -dev
wxwidgets with and without the -np option and running wxPLplotDemo)
for the MSVC case.  Given such testing, I would be happy to
see you push this in time for the 5.12.0 release because there
are no impacts of such wxwidgets driver changes on any other
part of PLplot.

However, the reason why I suggest extreme caution about pushing is
that Jim's equivalent change for cairo was a complete success for both
-dev xcairo and ext-cairo-test, but it appeared to have a side effect
of exposing a bug in extXdrawable_demo which we could not fix in a
timely manner for the release of 5.11.1.  Therefore, Jim and I made
the joint decision then to revert his change to cairo.c (see commit
d64d9c684) until someone could figure out that extXdrawable_demo
issue.  As of this date nobody has found such a solution so Jim's fix
for xcairo still remains reverted.  But if your equivalent change for
wxwidgets works, then post-release I plan to reinstate Jim's fix for
xcairo and simply drop extXdrawable_demo until someone can figure out
the issue with it.

In any case, in anticipation that you will be looking very carefully
at the eop versus wait distinction in plbuf, I suggest you document
that distinction clearly (in drivers/README.drivers or some other file
that document refers to) so no other interactive driver writers run
afoul of this issue.

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] plreplot and clearing the page (jim please read ifyou'e around)

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

Thanks Alan, I'll review those emails.

I will check if the issue is related, but it shouldn't be a keypress issue as I'm not using it in that way.

PS, I wasn't suggesting the commit was wrong. Just that I couldn't remember why it was as it was.

Perhaps also, I could be using plreplot wrong. I was using plclear wrong, as I was calling it before the first pladv() call so it was clearing no page. I'm not sure whether there should be a call to pladv before plreplot. I'll experiment.

I'm just thinking now whether the wxWidgets driver should clear the whole page to the background colour at bop. I guess it should.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 12 January 2017 20:50
To: Phil Rosenberg; Jim Dishaw; plp...@li...
Subject: Re: [Plplot-devel] plreplot and clearing the page (jim please read ifyou'e around)

On 2017-01-12 16:17-0000 Phil Rosenberg wrote:

> I think I've found the issue with clearing the page when using plreplot.
> Basically the issue is that the driver bop function is not being
> called, because at the point of replaying the buffer, the stream is
> already at the beginning of page. This means that the driver does not
> clear the page.
>
> There is a line in plFlushBuffer() which calls plP_eop() to avoid
> exactly this behaviour, however it is commented out. Using git blame I
> found the commit that commented the line out
>
> commit 5867959e87e64e08ed2ed57bc66a3cfa6e22450f
> Author: Jim Dishaw <ji...@di...>
> Date:   Mon Jun 15 12:10:04 2015 -0400
>    Fix to the multiple keypress bug on page advance
>    - The "wait for user input" is not part of an EOP.
>      -- A new function plP_wait() was created
>      -- plP_wait() calls were added next to plP_eop() calls to generate
>         a wait (if specified by nopause) after an EOP event
>    - The plot buffer was modified to insert an EOP into the buffer
>      -- No wait is inserted into the plot buffer because the plot buffer
>         only regenerates plots
>    - A new entry was added to the PLDispatchTable for the wait function
>      -- The table initialization sets all function pointers to NULL via
>         a memset
>      -- If a driver does not specify a wait function, either it is not
>         needed (e.g. the ps driver) or it is part of the EOP handler
>         (legacy behavior)
>    - The following drivers were modified to support the new
> implementation: cairo, qt, tkwin, and xwin.  The wingcc update will be
> in a seperate fix.
>
> It's not entirely clear from the message, however it looks to me like
> this line was commented out to avoid odd behaviour when nopause was
> specified, but then Jim has fixed that issue in a different way and
> then perhaps forgotten to uncomment this line???
>
> Jim, I know it's a long time ago when we were fixing the buffer, I
> don't suppose you have any memories of this? I have some vague ones
> but nothing concrete.
>
> Basically I'd like to put that line back for the upcoming release
> because I have code that is using plreplot that is currently broken
> because of this issue. I don't know what anyone thinks of that or what
> anyone thinks is an appropriate set of tests to do to ensure there
> isn't any odd side effects.

To Phil and Jim:

It would be great if Jim responded, but in addition this change was
thoroughly discussed at the time.  To refresh your memories of that discussion
both of you should look at the June 2015 plplot-devel mailing list threads
entitled "The multiple keypress problem when using interactive
drivers" and (especially) "Bug fix to plbuf.c".

I have just re-read those threads myself, and although I don't follow
all the technical issues it looks like Phil agreed at that time this
was a complex issue that Jim was facing.  Ultimately with Phil's and
my encouragement Jim pushed his solution 2 (which he classified as the
more elegant one).

That solution did require further device driver work for some of the
the interactive devices.  Jim supplied those changes for wingcc,
cairo, qt, xwin, and tkwin, but the implication was Phil would have to
appropriately modify the wxwidgets driver (or wxPLViewer?) himself.

@Phil: Is the wxwidgets issue you have recently discovered simply because you
never followed up with that required change?

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] plreplot and clearing the page (jim please read if you'e around)

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

On 2017-01-12 16:17-0000 Phil Rosenberg wrote:

> I think I've found the issue with clearing the page when using plreplot.
> Basically the issue is that the driver bop function is not being
> called, because at the point of replaying the buffer, the stream is
> already at the beginning of page. This means that the driver does not
> clear the page.
>
> There is a line in plFlushBuffer() which calls plP_eop() to avoid
> exactly this behaviour, however it is commented out. Using git blame I
> found the commit that commented the line out
>
> commit 5867959e87e64e08ed2ed57bc66a3cfa6e22450f
> Author: Jim Dishaw <ji...@di...>
> Date:   Mon Jun 15 12:10:04 2015 -0400
>    Fix to the multiple keypress bug on page advance
>    - The "wait for user input" is not part of an EOP.
>      -- A new function plP_wait() was created
>      -- plP_wait() calls were added next to plP_eop() calls to generate
>         a wait (if specified by nopause) after an EOP event
>    - The plot buffer was modified to insert an EOP into the buffer
>      -- No wait is inserted into the plot buffer because the plot buffer
>         only regenerates plots
>    - A new entry was added to the PLDispatchTable for the wait function
>      -- The table initialization sets all function pointers to NULL via
>         a memset
>      -- If a driver does not specify a wait function, either it is not
>         needed (e.g. the ps driver) or it is part of the EOP handler
>         (legacy behavior)
>    - The following drivers were modified to support the new
> implementation: cairo, qt, tkwin, and xwin.  The wingcc update will be
> in a seperate fix.
>
> It's not entirely clear from the message, however it looks to me like
> this line was commented out to avoid odd behaviour when nopause was
> specified, but then Jim has fixed that issue in a different way and
> then perhaps forgotten to uncomment this line???
>
> Jim, I know it's a long time ago when we were fixing the buffer, I
> don't suppose you have any memories of this? I have some vague ones
> but nothing concrete.
>
> Basically I'd like to put that line back for the upcoming release
> because I have code that is using plreplot that is currently broken
> because of this issue. I don't know what anyone thinks of that or what
> anyone thinks is an appropriate set of tests to do to ensure there
> isn't any odd side effects.

To Phil and Jim:

It would be great if Jim responded, but in addition this change was
thoroughly discussed at the time.  To refresh your memories of that discussion
both of you should look at the June 2015 plplot-devel mailing list threads
entitled "The multiple keypress problem when using interactive
drivers" and (especially) "Bug fix to plbuf.c".

I have just re-read those threads myself, and although I don't follow
all the technical issues it looks like Phil agreed at that time this
was a complex issue that Jim was facing.  Ultimately with Phil's and
my encouragement Jim pushed his solution 2 (which he classified as the
more elegant one).

That solution did require further device driver work for some of the
the interactive devices.  Jim supplied those changes for wingcc,
cairo, qt, xwin, and tkwin, but the implication was Phil would have to
appropriately modify the wxwidgets driver (or wxPLViewer?) himself.

@Phil: Is the wxwidgets issue you have recently discovered simply because you
never followed up with that required change?

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] plreplot and clearing the page (jim please read if you'e around)

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

I think I've found the issue with clearing the page when using plreplot.
Basically the issue is that the driver bop function is not being
called, because at the point of replaying the buffer, the stream is
already at the beginning of page. This means that the driver does not
clear the page.

There is a line in plFlushBuffer() which calls plP_eop() to avoid
exactly this behaviour, however it is commented out. Using git blame I
found the commit that commented the line out

commit 5867959e87e64e08ed2ed57bc66a3cfa6e22450f
Author: Jim Dishaw <ji...@di...>
Date:   Mon Jun 15 12:10:04 2015 -0400
    Fix to the multiple keypress bug on page advance
    - The "wait for user input" is not part of an EOP.
      -- A new function plP_wait() was created
      -- plP_wait() calls were added next to plP_eop() calls to generate
         a wait (if specified by nopause) after an EOP event
    - The plot buffer was modified to insert an EOP into the buffer
      -- No wait is inserted into the plot buffer because the plot buffer
         only regenerates plots
    - A new entry was added to the PLDispatchTable for the wait function
      -- The table initialization sets all function pointers to NULL via
         a memset
      -- If a driver does not specify a wait function, either it is not
         needed (e.g. the ps driver) or it is part of the EOP handler
         (legacy behavior)
    - The following drivers were modified to support the new
implementation: cairo, qt, tkwin, and xwin.  The wingcc update will be
in a seperate fix.

It's not entirely clear from the message, however it looks to me like
this line was commented out to avoid odd behaviour when nopause was
specified, but then Jim has fixed that issue in a different way and
then perhaps forgotten to uncomment this line???

Jim, I know it's a long time ago when we were fixing the buffer, I
don't suppose you have any memories of this? I have some vague ones
but nothing concrete.

Basically I'd like to put that line back for the upcoming release
because I have code that is using plreplot that is currently broken
because of this issue. I don't know what anyone thinks of that or what
anyone thinks is an appropriate set of tests to do to ensure there
isn't any odd side effects.

Phil

Re: [Plplot-devel] Follow ups for commit c27eff0

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

Hi Alan,



That definitely looks worth our while - makes it all more systematic, but as you said, this is post-release stuff :).



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, January 11, 2017 7:45 PM
> To: Arjen Markus; PLplot development list
> Subject: Follow ups for commit c27eff0
>
> Hi Arjen:
>
> After the release I suggest you use CMake to automate what you did for commit
> c27eff0 as follows:
>
> * Move scripts/compare.c to utils/compare.c (using "git mv") since this is code for a
> utility and not a script.
>
> * Build compare.exe using add_executable in utils/CMakeLists.txt.
>
> * Move run_examples_windows.bat run_examples_windows.bat.in (using "git mv")
> and use CMake to configure scripts/run_examples_windows.bat in the build tree
> from that template file to insert the build-tree location of compare.exe.
>
> If you like these build and configuration ideas to automate your work, then I
> emphasize you should not do anything about this now until after the release, i.e.,
> this is something for your post-release ToDo list.  But since I woke up this morning
> with these ideas I thought I had better mention them to you now before I forgot
> about them again!  :-)
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation for
> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net);
> PLplot scientific plotting software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux
> Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

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] Follow ups for commit c27eff0

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

Hi Arjen:

After the release I suggest you use CMake to automate what you did for commit
c27eff0 as follows:

* Move scripts/compare.c to utils/compare.c (using "git mv") since this is code for a
utility and not a script.

* Build compare.exe using add_executable in utils/CMakeLists.txt.

* Move run_examples_windows.bat run_examples_windows.bat.in (using
"git mv") and use CMake to configure scripts/run_examples_windows.bat in the build
tree from that template file to insert the build-tree location
of compare.exe.

If you like these build and configuration ideas to automate your work,
then I emphasize you should not do anything about this now until after the
release, i.e., this is something for your post-release ToDo list.  But
since I woke up this morning with these ideas I thought I had better mention them to you
now before I forgot about them again!  :-)

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] legend and label using wxWidgets

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

Hi Laurent
I'm glad the text alignment issues are fixed. :-)

In terms of the text size. We have had discussions on the list before about
this. The wxWidgets backend takes the text size given to it by Plplot in mm
and converts it to pt (assuming on pt is 1/72 of an inch) and requests that
size text from wxWidgets. So the text size requested should be consistent
with any other text requested from wxWidgets.

I have just followed some of the wxWidgets code through and it seems that
the height in points gets converted to logical units (pixels) using the
screen dpi and then I think (although I'm not sure) that the Windows API
function CreateFont get's called with this size. It seems that the text
size requested is the size of the cell the text resides in, i.e. it
includes leading.

So for the wxWidgetsDemo, The text size requested is 2.342mm, which is 7pt
(rounding to integer values) and is converted to 9 logical units
(pixels) by wxWidgets. This uses the screen dpi so round(7 * 96 / 72)
= 9. And I think this font size is requested using the CreateFont function
as the cell size. In fact when I do a screenshot, zoom in and look at the
text, the bracket in the title is 9 pixels from top to bottom. So it seems
everything is how it should be.

I don't know if other devices use similar metrics for the text, but I
assume they must be pretty similar. I guess that the issue really is that
the demo windows are rather small (at least on my system) because they use
the default window size. I could adjust this and make it some other fixed
size, but I'm a bit nervous to do so in case I make them larger than
somebodies screen. I'm happy to take suggestions?

Phil

On 8 January 2017 at 13:20, Laurent Berger <lau...@un...>
wrote:

> Hi phil,
>
>
> I have updated all my repo wxwidgetts and plplot and now everything is OK
> using VS 2015 or MSYS2-mingw64. Thanks you very much.
>
> Only one thing wxplplotdemo legend are small (may be tiny)
>
> Le 05/01/2017 à 15:58, Phil Rosenberg a écrit :
>
> Hi Laurent
> Although I haven't upgraded to wxWidgets 3.1. I think I have isolated
> and fixed the issue. It turned out to affect all wxDCs that support
> transformations so I was able to reproduce your bad results on a
> wxMemoryDc. If you grab the latest version from the Git repo then you
> should find everything is working correctly again. If not then please
> let me know.
>
> Phil
>
> On 5 January 2017 at 00:42,  <p.d...@gm...> <p.d...@gm...> wrote:
>
> Hi Alan
>
> I agree it would be good to look at this pre release. It's on my to do list
> for asap.
>
>
>
> Sent from my Windows 10 phone
>
>
>
> From: Alan W. Irwin
> Sent: 04 January 2017 20:37
> To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list
> Subject: Re: [Plplot-devel] legend and label using wxWidgets
>
>
>
> On 2016-12-28 23:19+0100 Laurent Berger wrote:
>
>
>
>
> wxwidgets commit 0bf38e1 x04 y axis label is good
>
> (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be)
>
> wxwidgets commit 49000def x04 y axis label is false
>
> (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3)
>
>
>
> Hi Phil:
>
>
>
> Assuming (subject to Pedro's further extensive testing) that you have
>
> found a good fix for that bug he had discovered, then the only
>
> remaining potentially release critical issue for the wxwidgets-related
>
> components of PLplot is the issue discovered by Laurent above.
>
>
>
> So to learn more about what Laurent reported above,
>
> I described those two commits as follows:
>
>
>
> software@raven> git clone https://github.com/wxWidgets/wxWidgets.git
> wxwidgets.git
>
> software@raven> cd wxwidgets.git
>
> software@raven> git branch
>
> * master
>
> software@raven> git describe 0bf38e1
>
> v3.1.0-620-g0bf38e1
>
> software@raven> git describe 49000def
>
> v3.1.0-621-g49000de
>
>
>
> So it is clear from these results that Laurent already bisected this
>
> issue with the 621st commit beyond the last official release (3.1.0)
>
> of wxwidgets showing the issue for the first time.  And since this is
>
> an issue that will not affect any user of an official wxwidgets
>
> release at this time, that gives us a good excuse to do nothing at
>
> this time if the potential fix is going to be intrusive.
>
>
>
> Of course, this issue will affect our users as soon as the next
>
> wxwidgets official release is out so it would be nice at this time for
>
> you to (a) confirm the above results for 0bf38e1 and 49000def from
>
> Laurent and figure out what the issue is.  If it turns out to be a
>
> wxwidgets regression introduced for 49000def it would be good for you
>
> to draw this quickly to the attention of the wxwidgets developers so
>
> they can fix that regression before their next official release to
>
> avoid making life difficult for PLplot wxwidgets users.  But if it
>
> turns out to be our problem, then please prepare the fix and use your
>
> best judgement (depending on, e.g., whether the fix is more or less
>
> intrusive than the fix you just made) whether to push it now or wait
>
> until after the release.
>
>
>
> 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] legend and label using wxWidgets

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

Hi phil,


I have updated all my repo wxwidgetts and plplot and now everything is 
OK using VS 2015 or MSYS2-mingw64. Thanks you very much.

Only one thing wxplplotdemo legend are small (may be tiny)

Le 05/01/2017 à 15:58, Phil Rosenberg a écrit :
> Hi Laurent
> Although I haven't upgraded to wxWidgets 3.1. I think I have isolated
> and fixed the issue. It turned out to affect all wxDCs that support
> transformations so I was able to reproduce your bad results on a
> wxMemoryDc. If you grab the latest version from the Git repo then you
> should find everything is working correctly again. If not then please
> let me know.
>
> Phil
>
> On 5 January 2017 at 00:42,  <p.d...@gm...> wrote:
>> Hi Alan
>>
>> I agree it would be good to look at this pre release. It's on my to do list
>> for asap.
>>
>>
>>
>> Sent from my Windows 10 phone
>>
>>
>>
>> From: Alan W. Irwin
>> Sent: 04 January 2017 20:37
>> To: Phil Rosenberg; Pedro Vicente; Laurent Berger; PLplot development list
>> Subject: Re: [Plplot-devel] legend and label using wxWidgets
>>
>>
>>
>> On 2016-12-28 23:19+0100 Laurent Berger wrote:
>>
>>
>>
>>> wxwidgets commit 0bf38e1 x04 y axis label is good
>>> (https://github.com/wxWidgets/wxWidgets/commit/0bf38e11a33005e289e30c8bc7c67563eae061be)
>>> wxwidgets commit 49000def x04 y axis label is false
>>> (https://github.com/wxWidgets/wxWidgets/commit/49000defcfb11b409d8935126981b14169ee62a3)
>>
>>
>> Hi Phil:
>>
>>
>>
>> Assuming (subject to Pedro's further extensive testing) that you have
>>
>> found a good fix for that bug he had discovered, then the only
>>
>> remaining potentially release critical issue for the wxwidgets-related
>>
>> components of PLplot is the issue discovered by Laurent above.
>>
>>
>>
>> So to learn more about what Laurent reported above,
>>
>> I described those two commits as follows:
>>
>>
>>
>> software@raven> git clone https://github.com/wxWidgets/wxWidgets.git
>> wxwidgets.git
>>
>> software@raven> cd wxwidgets.git
>>
>> software@raven> git branch
>>
>> * master
>>
>> software@raven> git describe 0bf38e1
>>
>> v3.1.0-620-g0bf38e1
>>
>> software@raven> git describe 49000def
>>
>> v3.1.0-621-g49000de
>>
>>
>>
>> So it is clear from these results that Laurent already bisected this
>>
>> issue with the 621st commit beyond the last official release (3.1.0)
>>
>> of wxwidgets showing the issue for the first time.  And since this is
>>
>> an issue that will not affect any user of an official wxwidgets
>>
>> release at this time, that gives us a good excuse to do nothing at
>>
>> this time if the potential fix is going to be intrusive.
>>
>>
>>
>> Of course, this issue will affect our users as soon as the next
>>
>> wxwidgets official release is out so it would be nice at this time for
>>
>> you to (a) confirm the above results for 0bf38e1 and 49000def from
>>
>> Laurent and figure out what the issue is.  If it turns out to be a
>>
>> wxwidgets regression introduced for 49000def it would be good for you
>>
>> to draw this quickly to the attention of the wxwidgets developers so
>>
>> they can fix that regression before their next official release to
>>
>> avoid making life difficult for PLplot wxwidgets users.  But if it
>>
>> turns out to be our problem, then please prepare the fix and use your
>>
>> best judgement (depending on, e.g., whether the fix is more or less
>>
>> intrusive than the fix you just made) whether to push it now or wait
>>
>> until after the release.
>>
>>
>>
>> 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] Proposed documentation and optional C example updates for the "arbitrary storage of 2D user data" commit

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

Hi David:

I have been doing a large review and update of our DocBook
documentation on a private topic branch with the goal of pushing it in
the next few days so that it will be part of the 5.12.0 release.  I
reviewed documentation of the plfsurf3d function this morning and
moved it from api.xml (documentation for our common API for all
languages) to api-c.xml (documentation of our C-only API) because this
is obviously a C-only function that should not be propagated to other
languages.  You created this function as part of your "support
arbitrary storage of 2D user data" patch which I committed (b035137)
back in 2010.

While making that documentation location change, I noticed that the
remaining functions you created in that patch (e.g., plfgriddata,
plfmesh, plfmeshc, plfplot3d, plfplot3dc, plfplot3dcl, plfshades,
plfshade, plfimagefr, plfimage, plfsurf3dl, and plfvect) are
completely ignored by our DocBook documentation and are not used in
our C examples. (None of these functions should be propagated to
languages other than C, but they might prove to be useful for our C
users. Also note in the above list of functions I deliberately ignored
plfshade1 because I plan to deprecate its non-"f" counterpart
plshade1.) Following what has been done for plfsurf3d do you think it is
worth publicizing this list of functions (after the current release is
out the door) by documenting them in api-c.xml and providing options
in our C examples to test these functions as replacements for their
non-"f" counterparts which we test 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
__________________________