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

[Arjen Markus]

Hi Alan,



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



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



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



Regards,



Arjen



> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, January 30, 2017 3:48 AM
> To: Arjen Markus; PLplot development list
> Subject: Your development plans for this release cycle
>
> Hi Arjen:
>
> Now that 5.12.0 has been released, I am writing a series of posts to our 
> active
> developers with this subject line, and you are first in line!.  :-)
>
> If you have some further development in mind for this release cycle, please 
> let us
> know.  In addition, I would appreciate you moving forward on the comprehensive
> testing front on (1) MinGW-w64/MSYS2
> (2) the MinGW-w64 part of MinGW/MSYS2, and (3) MSVC.
>
> 1. MinGW-w64/MSYS2 (using the "MSYS Makefiles" or "Unix Makefiles"
> generator).  This platform is the modern equivalent of the classic MinGW/MSYS
> platform (but with a far larger set of free software libraries available and 
> likely many
> fewer platform bugs).  You have already had partial success with this 
> platform, and
> the trick here is to update that platform with all the development tools 
> (e.g. the
> MingGW-w64 version of cmake and the MSYS2 version of make) and all the
> MingGW-w64 libraries that add power to PLplot to make this test as 
> comprehensive
> as possible.  There is no urgency about this, but nevertheless from my 
> perspective
> (with no release distracting me) now would be and ideal time for you to go 
> ahead
> with this so I can add your full-powered version of this Windows platform to 
> our tally
> at 
> and
>  ts>
>
> 2. MinGW-w64 alone (using the "MinGW Makefiles" generator).  This platform is
> the modern equivalent of MinGW.  Based on my historical experience with that
> platform under Wine, this should "just work" with CMake finding all the native
> libraries built by the MinGW-w64/MSYS2 platform that are needed by PLplot.  So
> this platform should in theory be just as complete as MinGW-w64/MSYS2 and also
> Cygwin.  N.B. The trick to get the testing of PLplot to "just work" on this 
> platform is
> to copy the MSYS2 set of Unix tools (except for sh.exe) to a different 
> directory and
> put that directory on your PATH AFTER the directory pointing to the MinGW-w64
> set of applications such as the MinGW-w64 version of make. The point of this 
> is the
> MinGW-w64 version of make you should be using for this exercise acts quite
> differently if sh.exe is on your PATH.  That is, that version of make 
> apparently does
> not work correctly in a CMD environment unless sh.exe is _not_ available.
> Therefore, the "MinGW Makefiles" generator only works with sh.exe removed from
> the path (as with the above trick).  Thus, this build is done completely 
> under a CMD
> environment with the MinGW-w64 version of make from the
> MinGW-w64/MSYS2 platform rather than the MSYS2 version of make from that
> platform, but the tests are run using bash.exe and other MSYS2 Unix 
> applications
> such as cmp.exe, etc. from the MinGW-w64/MSYS2 platform.
>
> 3. MSVC (using the "NMake Makefiles" generator).  I am virtually positive the
> approach described in 2. (which I _know_ works for the classic MinGW platform)
> should work fine also for this platform. (Note in my Wine days I even got 
> jom, a
> parallel build version of nmake to work properly on the classic MinGW platform
> when using the "NMake Makefiles Jom" generator.) With this approach, the 
> actual
> build is done with nmake.exe (or jom.exe) in the CMD environment but all the 
> tests
> are run using bash.exe and other MSYS2 Unix applications such as cmp.exe, 
> etc.,
> from the MinGW-w64/MSYS2 platform.
>
> You commented in December to the effect you think the suggested approach (for 
> 2.
> or 3.) would be somewhat too exotic to be of much use to users.  I mostly 
> agree
> unless 

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

[Alan W. Irwin]

To Phil and Pedro:

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

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

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Pedro Vicente]

Hi Alan
Congratulations on the release.

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

ok, will do, as my time permits
Regards

-Pedro

- Original Message - 
From: "Alan W. Irwin" 
To: "Phil Rosenberg" ; "Pedro Vicente" 
; "PLplot development list" 

Sent: Monday, January 30, 2017 12:36 AM
Subject: Your development plans for this release cycle


> To Phil and Pedro:
>
> Now that 5.12.0 has been released, I am writing a series of posts to
> our active developers with this subject line.
>
> If either of you has any additional wxwidgets development in mind beyond 
> what I
> discuss below, please let me know.
>
> For this release cycle I encourage both of you to continue your
> efforts to deal with obvious wxwidgets bugs (such as the unexpected
> black rather than expected white background color for the first page
> of example 16) to complement the work I plan to do deal with the last
> of the wxwidgets device driver efficiency issues on Linux. Your goal
> should be that each of our C examples with -dev wxwidgets should
> produce exactly the same results (except possibly for text size) as
> given at /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
> ).  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.
>
>A google search for the search terms 
>   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.
> 
>
> 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
> __
> 


--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

Hi Jim:

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

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

I look forward to seeing that push.

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

Excellent.

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

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

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

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

Hi Phil:

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

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

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

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

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

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

These remaining steps all sound good to me.

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__

--
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Jim Dishaw]

> On Jan 30, 2017, at 3:40 AM, Alan W. Irwin  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
>  but with no
> Uniscribe (see ) support for
> Unicode implemented yet.  Also, you have at least discussed plans to
> add another device to that device driver that would use Direct2D
>  rather than GDI. and which
> would use the 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
>  
> )
>  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 
>  approach.  Once that component 

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

[Phil Rosenberg]

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  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 /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
> ).  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.
>
>A google search for the search terms 
>   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.
> 
>
> 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