plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Bug fix to plbuf.c

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

On 2015-06-09 18:18-0400 Jim Dishaw wrote:

> Attached is a patch series that corrects a NUL termination bug in
the plot buffer that I discovered while working on the windows GDI
driver.

Hi Jim:

I applied this result to a private branch using "git am", styled this
result (which was very easy to do, see previous comment), amended your
commit with those style changes using "git add" and "git commit
--amend", and then pushed that result using the normal procedure in
README.developers as commit id = 868f790.

Note, I did not test this commit in the slightest, but I assumed you
had done that already.

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] Styling of commits

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

On 2015-06-09 18:18-0400 Jim Dishaw wrote:

> I apologize that [the patch series] has not been uncrustified.

Hi Jim:

This really is no problem, i.e., styling of results is a slight
convenience for the rest of us but not a requirement.  After all, it
is very easy to run the script for those of us here with access to the
required tools which are bash, python, and a build of uncrustify-0.60
(no other version than that one is currently allowed).

However, if you do decide to style your commits, the above requirements
can easily be met on Linux, and I believe Phil found that to be so
on Cygwin.  Furthermore, I assume those same requirements would be easy
to meet on any version of MinGW, and also on Mac OS X.  So there is a
lot of choice for you here.

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] Bug fix to plbuf.c

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

Attached is a patch series that corrects a NUL termination bug in the plot buffer that I discovered while working on the windows GDI driver.

I apologize that it has not been uncrustified.  Is cygwin required to run the script?

[Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and Ada

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

Hi Arjen:

I have changed the subject line for obvious reasons.

On 2015-06-09 07:14-0000 Arjen Markus wrote:

> Hi Alan,

> I adjusted the text on the Wiki page - I removed the remarks that Tk
would not compile on Cygwin. That at least is no longer true :). Some
things to add: a convenient window manager, I guess.

I have just made further changes to that page to remove all
references to historicial workarounds which are no longer required
(as shown by your recent comprehensive tests).  I also replaced the
2008 (!) tag with 2015.

Could you also take this opportunity to update
<https://sourceforge.net/p/plplot/wiki/Setup_cygwin/>? That page
already has some information (last updated in 2013) concerning
packages to install, but it is obviously far from complete.  The goal
here should be to document complete information about Cygwin packages
so that it would be a straightforward for you (or anybody else) to use
this Wiki documentation to install Cygwin from scratch with the same
packages you have been installing over the last few weeks to provide a
complete PLplot environment on Cygwin.

> I include the report from the latest tests - all seems to be going well.

Yes, those non-interactive results look good.

Of course, for the next time (after I finish my Tcl and related
changes) you will want to install the iwidgets package I mentioned and
change

--cmake_added_options "-DENABLE_octave=OFF -DENABLE_ada=OFF -DENABLE_itk=OFF"

to

--cmake_added_options "-DENABLE_octave=OFF -DENABLE_ada=OFF"

and also completely drop the

--do_test_interactive no

option.  Those changes should allow you to do complete comprehensive
interactive testing of PLplot on Cygwin including the Tcl/Tk/Itcl/Itk
components of PLplot.

With regard to the further possibility of dropping the above
-DENABLE_ada=OFF, for Cygwin, the current Ada language support is so
ancient it is not maintainable.  Therefore, I have decided to attempt
to rewrite Ada language support from scratch over the next few days
using the approach of making minimal changes to existing modern C (or
C++) language support.  That is the approach I used ~10 years ago to
implement Ada language support, and hopefully that same approach will
work again now (and also automatically solve the Ada language support
issue you found on Cygwin). But we will see how that goes, and if I
run into any issue I cannot straightforwardly figure out, I will
likely put Ada language support changes off indefinitely.

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 and C++

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

Hi Alan,



I adjusted the text on the Wiki page - I removed the remarks that Tk would not compile on Cygwin. That at least is no longer true :). Some things to add: a convenient window manager, I guess.



I include the report from the latest tests - all seems to be going well.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Monday, June 08, 2015 11:38 PM
> To: Arjen Markus
> Cc: Phil Rosenberg; plp...@li...
> Subject: RE: [Plplot-devel] PLplot and C++
>
> On 2015-06-08 18:52-0000 Arjen Markus wrote:
>
> > Itk is causing a link problem - I will turn it off for the moment to see what the rest of
> tests are doing now.
> > See the report.
>
> Hi Arjen:
>
> Thanks for that test, and I am really pleased the DISPLAY issue was so easy to fix.
>
> N.B. please take the time right now to do a wiki entry about possible pitfalls in setting
> up X on Cygwin to help our Cygwin users in future.
>
> Getting back to the specifics of your report, the first Tcl/Tk/Itcl/Itk WARNING
> message is
>
> -- WARNING: Iwidgets could not be found so disabling Itcl and Itk
>
> To fix that install issue, you should install the package
> tcl-iwidgets-4.0.1-2 which I found with the search term "iwidgets".
>
> It turned out that corner case where iwidgets was not installed exercised a real build
> system bug which in turn caused the build error shown in your report.
>
> I will fix the build-system logic of that corner case and test it as part of the rest of the
> current set of Tcl/Tk/Itcl/Itk changes I mentioned before that I am working on and
> which I hope to commit by tomorrow.
>
> Meanwhile, if you install the above package you should be able to avoid that corner
> case and thus finish this first attempt of interactive testing on Cygwin that you have
> tried for a while.
> However, I acknowledge interactive testing is inconvenient (because you have to
> babysit the test to click buttons, etc.,) so you may want to hold off on doing any more
> interactive testing on Cygwin until my Tcl/Tk/Itcl/Itk changes (and possibly also the
> Ada changes if those prove to be easy for me) are completed.
>
> 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.

Re: [Plplot-devel] PLplot and C++

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

On 2015-06-08 18:52-0000 Arjen Markus wrote:

> Itk is causing a link problem - I will turn it off for the moment to see what the rest of tests are doing now.
> See the report.

Hi Arjen:

Thanks for that test, and I am really pleased the DISPLAY issue was so
easy to fix.

N.B. please take the time right now to do a wiki entry about possible
pitfalls in setting up X on Cygwin to help our Cygwin users in
future.

Getting back to the specifics of your report, the first
Tcl/Tk/Itcl/Itk WARNING message is

-- WARNING: Iwidgets could not be found so disabling Itcl and Itk

To fix that install issue, you should install the package
tcl-iwidgets-4.0.1-2 which I found with the search term "iwidgets".

It turned out that corner case where iwidgets was not installed
exercised a real build system bug which in turn caused the build error
shown in your report.

I will fix the build-system logic of that corner case and test it as
part of the rest of the current set of Tcl/Tk/Itcl/Itk changes I
mentioned before that I am working on and which I hope to commit by
tomorrow.

Meanwhile, if you install the above package you should be able to
avoid that corner case and thus finish this first attempt of
interactive testing on Cygwin that you have tried for a while.
However, I acknowledge interactive testing is inconvenient (because
you have to babysit the test to click buttons, etc.,) so you may want
to hold off on doing any more interactive testing on Cygwin until my
Tcl/Tk/Itcl/Itk changes (and possibly also the Ada changes if those
prove to be easy for me) are completed.

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 and C++

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

Hi Alan,



Itk is causing a link problem - I will turn it off for the moment to see what the rest of tests are doing now.



See the report.



Regards,



Arjen



From: Arjen Markus [mailto:Arj...@de...]
Sent: Monday, June 08, 2015 8:46 PM
To: Phil Rosenberg; Alan W. Irwin
Cc: plp...@li...
Subject: Re: [Plplot-devel] PLplot and C++


Hi Alan, Phil,



I was just looking at the Tk/X Window problem myself. It would seem that having the X Window Server running and setting the DISPLAY variable to :0.0 (that is the name of the X Window Server that Cygwin runs), wish and Tk are happy and so is Cmake. The tests are now running, so that will take a while.



(I thought I had Itk installed, but apparently not - installing that too and restarting the tests ...)



Regards,



Arjen



> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]
> Sent: Monday, June 08, 2015 8:36 PM
> To: Alan W. Irwin
> Cc: Arjen Markus; plp...@li...
> Subject: Re: [Plplot-devel] PLplot and C++
>
>  Hi Alan and Arjen
> My X problems were just because I updated Cygwin with X running so some dlls
> couldn't upgrade until reboot - but I had too much stuff open on my laptop to reboot
> just then.
>
> If it helps I have the following in my .bashrc to ensure X11 is running whenever I start
> a terminal
>
> #start and connect to X
> export DISPLAY=:0.0
> XPROC=$(ps aux | egrep /usr/bin/XWin)
> if [[ -z "$XPROC" ]]; then
> cygstart xwin -multiwindow
> fi
> unset XPROC
>
> Looking at it I must have copied it from somewhere as it is definitely not my style of
> scripting, but I'm not sure where I got it from.
> Anyhow it works well for me.
>
> Phil
>
>
> On 8 June 2015 at 19:20, Alan W. Irwin <ir...@be...> wrote:
> > On 2015-06-08 08:55-0000 Arjen Markus wrote:
> >
> >> See the new results. They seem almost perfect. Only the Ada problem is left at a
> superficial examination of the reports.
> >
> > Thanks very much for doing these two tests (with and without Ada).  I
> > agree these results are the best Cygwin results (outside your DISPLAY
> > issues where I think I have found a solution below) we have ever seen.
> > For example, because you are now using lua-5.2, you are getting a
> > clean Lua run-time result, e.g.,
> >
> > lua
> >    Missing examples            :
> >    Differing graphical output  :
> >    Missing stdout              :
> >    Differing stdout            :
> >
> > And you similarly have clean results for c++, f95, python, and tcl.
> > To see all of these voluminous diff results for every configuration, I
> > suggest you try
> >
> > grep -B1 -A3 "Missing examples" */output_tree/*.out |less
> >
> > If you run that command, you will notice that Python and Lua results
> > are missing for the static case, but that is by design; those bindings
> > only work for the shared library case.
> >
> > With regard to the on-going Ada problems, thanks to your first report
> > I have now tracked the issue down to an incomplete link command for
> > the Ada library, i.e., my CMake Ada language support is incomplete on
> > Cygwin.  I am going to take a quick look at that now, but if it looks
> > like the fix is going to be complicated, I will likely put off working
> > on it until after this forthcoming release has been made.
> >
> > I also am just in the process of revising Tcl/Tk linking to eliminate
> > redundant linking of libtclmatrix, libplplottcltk, and libplplot when
> > ENABLE_DYNDRIVERS=OFF.  (For that case all the libtclmatrix and
> > libplplottcltk code is already in libplplot so the first two libraries
> > should not even be built, and all links should be made solely to
> > libplplot rather than those first two libraries.) I think this change
> > is going to sort out some memory management issues we have
> > historically had with interactive testing of Tcl/Tk on both Cygwin and
> > Linux in the past for the ENABLE_DYNDRIVERS=OFF case.  We worked
> > around those issues by dropping such testing, but I am also going to
> > reinstate that testing to make sure this elimination of redundant
> > linking cures all these problems.
> >
> > Meanwhile, so that you can start interactive testing again you have to
> > sort out the DISPLAY issues that are currently prohibiting your
> > interactive tests of Tcl and Tk.  For example, in the present results
> > for cmake.out you have the following error/warning set of messages:
> >
> > -- TK_WISH = /bin/wish
> > Application initialization failed: no display name and no $DISPLAY
> > environment variable Error in startup script: couldn't load file "/usr/bin/tk85.dll": No
> such file or directory
> >      while executing
> > "load /usr/bin/tk85.dll Tk"
> >      ("package ifneeded Tk 8.5.18" script)
> >      invoked from within
> > "package require Tk"
> >      invoked from within
> > "puts -nonewline [package require Tk]"
> >      (file
> > "/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tr
> > ee/CheckTK_VERSION.tcl" line 1)
> > -- Looking for Tk version with wish - not found
> > -- WARNING: setting ENABLE_tk to OFF
> >
> > I did a google search for the terms
> >
> > <cygwin "Application initialization failed: no display name">
> >
> > and came up with
> > <http://stackoverflow.com/questions/9393462/cannot-launch-git-gui-usin
> > g-cygwin-on-windows>
> >
> > The most popular answer implies that since 2012 or so Cygwin made an
> > important Tcl/Tk and X change so a different procedure must be used to
> > get X working properly.  That answer and its discussion gives the
> > exact details about what has to be done. I hope those instructions
> > work for you (and also Phil who is also having trouble getting X to
> > work on modern Cygwin).  If those instructions work for you could you
> > please put them on our Wiki so all our Cygwin users can get access to
> > X?
> >
> > 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 mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
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.
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.

Re: [Plplot-devel] PLplot and C++

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

Hi Alan, Phil,



I was just looking at the Tk/X Window problem myself. It would seem that having the X Window Server running and setting the DISPLAY variable to :0.0 (that is the name of the X Window Server that Cygwin runs), wish and Tk are happy and so is Cmake. The tests are now running, so that will take a while.



(I thought I had Itk installed, but apparently not - installing that too and restarting the tests ...)



Regards,



Arjen



> -----Original Message-----
> From: Phil Rosenberg [mailto:p.d...@gm...]
> Sent: Monday, June 08, 2015 8:36 PM
> To: Alan W. Irwin
> Cc: Arjen Markus; plp...@li...
> Subject: Re: [Plplot-devel] PLplot and C++
>
>  Hi Alan and Arjen
> My X problems were just because I updated Cygwin with X running so some dlls
> couldn't upgrade until reboot - but I had too much stuff open on my laptop to reboot
> just then.
>
> If it helps I have the following in my .bashrc to ensure X11 is running whenever I start
> a terminal
>
> #start and connect to X
> export DISPLAY=:0.0
> XPROC=$(ps aux | egrep /usr/bin/XWin)
> if [[ -z "$XPROC" ]]; then
> cygstart xwin -multiwindow
> fi
> unset XPROC
>
> Looking at it I must have copied it from somewhere as it is definitely not my style of
> scripting, but I'm not sure where I got it from.
> Anyhow it works well for me.
>
> Phil
>
>
> On 8 June 2015 at 19:20, Alan W. Irwin <ir...@be...> wrote:
> > On 2015-06-08 08:55-0000 Arjen Markus wrote:
> >
> >> See the new results. They seem almost perfect. Only the Ada problem is left at a
> superficial examination of the reports.
> >
> > Thanks very much for doing these two tests (with and without Ada).  I
> > agree these results are the best Cygwin results (outside your DISPLAY
> > issues where I think I have found a solution below) we have ever seen.
> > For example, because you are now using lua-5.2, you are getting a
> > clean Lua run-time result, e.g.,
> >
> > lua
> >    Missing examples            :
> >    Differing graphical output  :
> >    Missing stdout              :
> >    Differing stdout            :
> >
> > And you similarly have clean results for c++, f95, python, and tcl.
> > To see all of these voluminous diff results for every configuration, I
> > suggest you try
> >
> > grep -B1 -A3 "Missing examples" */output_tree/*.out |less
> >
> > If you run that command, you will notice that Python and Lua results
> > are missing for the static case, but that is by design; those bindings
> > only work for the shared library case.
> >
> > With regard to the on-going Ada problems, thanks to your first report
> > I have now tracked the issue down to an incomplete link command for
> > the Ada library, i.e., my CMake Ada language support is incomplete on
> > Cygwin.  I am going to take a quick look at that now, but if it looks
> > like the fix is going to be complicated, I will likely put off working
> > on it until after this forthcoming release has been made.
> >
> > I also am just in the process of revising Tcl/Tk linking to eliminate
> > redundant linking of libtclmatrix, libplplottcltk, and libplplot when
> > ENABLE_DYNDRIVERS=OFF.  (For that case all the libtclmatrix and
> > libplplottcltk code is already in libplplot so the first two libraries
> > should not even be built, and all links should be made solely to
> > libplplot rather than those first two libraries.) I think this change
> > is going to sort out some memory management issues we have
> > historically had with interactive testing of Tcl/Tk on both Cygwin and
> > Linux in the past for the ENABLE_DYNDRIVERS=OFF case.  We worked
> > around those issues by dropping such testing, but I am also going to
> > reinstate that testing to make sure this elimination of redundant
> > linking cures all these problems.
> >
> > Meanwhile, so that you can start interactive testing again you have to
> > sort out the DISPLAY issues that are currently prohibiting your
> > interactive tests of Tcl and Tk.  For example, in the present results
> > for cmake.out you have the following error/warning set of messages:
> >
> > -- TK_WISH = /bin/wish
> > Application initialization failed: no display name and no $DISPLAY
> > environment variable Error in startup script: couldn't load file "/usr/bin/tk85.dll": No
> such file or directory
> >      while executing
> > "load /usr/bin/tk85.dll Tk"
> >      ("package ifneeded Tk 8.5.18" script)
> >      invoked from within
> > "package require Tk"
> >      invoked from within
> > "puts -nonewline [package require Tk]"
> >      (file
> > "/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tr
> > ee/CheckTK_VERSION.tcl" line 1)
> > -- Looking for Tk version with wish - not found
> > -- WARNING: setting ENABLE_tk to OFF
> >
> > I did a google search for the terms
> >
> > <cygwin "Application initialization failed: no display name">
> >
> > and came up with
> > <http://stackoverflow.com/questions/9393462/cannot-launch-git-gui-usin
> > g-cygwin-on-windows>
> >
> > The most popular answer implies that since 2012 or so Cygwin made an
> > important Tcl/Tk and X change so a different procedure must be used to
> > get X working properly.  That answer and its discussion gives the
> > exact details about what has to be done. I hope those instructions
> > work for you (and also Phil who is also having trouble getting X to
> > work on modern Cygwin).  If those instructions work for you could you
> > please put them on our Wiki so all our Cygwin users can get access to
> > X?
> >
> > 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 mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel

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.

Re: [Plplot-devel] PLplot and C++

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

 Hi Alan and Arjen
My X problems were just because I updated Cygwin with X running so
some dlls couldn't upgrade until reboot - but I had too much stuff
open on my laptop to reboot just then.

If it helps I have the following in my .bashrc to ensure X11 is
running whenever I start a terminal

#start and connect to X
export DISPLAY=:0.0
XPROC=$(ps aux | egrep /usr/bin/XWin)
if [[ -z "$XPROC" ]]; then
cygstart xwin -multiwindow
fi
unset XPROC

Looking at it I must have copied it from somewhere as it is definitely
not my style of scripting, but I'm not sure where I got it from.
Anyhow it works well for me.

Phil


On 8 June 2015 at 19:20, Alan W. Irwin <ir...@be...> wrote:
> On 2015-06-08 08:55-0000 Arjen Markus wrote:
>
>> See the new results. They seem almost perfect. Only the Ada problem is left at a superficial examination of the reports.
>
> Thanks very much for doing these two tests (with and without Ada).  I
> agree these results are the best Cygwin results (outside your DISPLAY
> issues where I think I have found a solution below) we have ever seen.
> For example, because you are now using lua-5.2, you are getting a
> clean Lua run-time result, e.g.,
>
> lua
>    Missing examples            :
>    Differing graphical output  :
>    Missing stdout              :
>    Differing stdout            :
>
> And you similarly have clean results for c++, f95, python, and tcl.  To see all of these
> voluminous diff results for every configuration, I suggest you try
>
> grep -B1 -A3 "Missing examples" */output_tree/*.out |less
>
> If you run that command, you will notice that Python and Lua results are missing for
> the static case, but that is by design; those bindings only work
> for the shared library case.
>
> With regard to the on-going Ada problems, thanks to your first report
> I have now tracked the issue down to an incomplete link command for
> the Ada library, i.e., my CMake Ada language support is incomplete on
> Cygwin.  I am going to take a quick look at that now, but if it looks
> like the fix is going to be complicated, I will likely put off working
> on it until after this forthcoming release has been made.
>
> I also am just in the process of revising Tcl/Tk linking to eliminate
> redundant linking of libtclmatrix, libplplottcltk, and libplplot when
> ENABLE_DYNDRIVERS=OFF.  (For that case all the libtclmatrix and
> libplplottcltk code is already in libplplot so the first two libraries should
> not even be built, and all links should be made solely to libplplot
> rather than those first two libraries.) I think this change is going
> to sort out some memory management issues we have historically had
> with interactive testing of Tcl/Tk on both Cygwin and Linux in the
> past for the ENABLE_DYNDRIVERS=OFF case.  We worked around those issues
> by dropping such testing, but I am also going to reinstate that testing
> to make sure this elimination of redundant linking cures all these
> problems.
>
> Meanwhile, so that you can start interactive testing again
> you have to sort out the DISPLAY issues that are
> currently prohibiting your interactive tests of Tcl and Tk.  For
> example, in the present results for cmake.out you have the following
> error/warning set of messages:
>
> -- TK_WISH = /bin/wish
> Application initialization failed: no display name and no $DISPLAY environment variable
> Error in startup script: couldn't load file "/usr/bin/tk85.dll": No such file or directory
>      while executing
> "load /usr/bin/tk85.dll Tk"
>      ("package ifneeded Tk 8.5.18" script)
>      invoked from within
> "package require Tk"
>      invoked from within
> "puts -nonewline [package require Tk]"
>      (file "/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/CheckTK_VERSION.tcl" line 1)
> -- Looking for Tk version with wish - not found
> -- WARNING: setting ENABLE_tk to OFF
>
> I did a google search for the terms
>
> <cygwin "Application initialization failed: no display name">
>
> and came up with
> <http://stackoverflow.com/questions/9393462/cannot-launch-git-gui-using-cygwin-on-windows>
>
> The most popular answer implies that since 2012 or so Cygwin made an
> important Tcl/Tk and X change so a different procedure must be used to
> get X working properly.  That answer and its discussion gives the
> exact details about what has to be done. I hope those instructions
> work for you (and also Phil who is also having trouble getting X to
> work on modern Cygwin).  If those instructions work for you could you
> please put them on our Wiki so all our Cygwin users can get access to
> X?
>
> 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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] The multiple keypress problem when usinginteractive drivers

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

Unfortunately you are correct, you get poor results and even when drawing you need to store your coordinates with subpixel resolution by telling plplot that your window is bigger than it really is. My understanding is that wxWidgets is mostly similar to the windows API so you might find checking what is done there helps. Any questions just ask.

Good luck
Phil

-----Original Message-----
From: "Jim Dishaw" <ji...@di...>
Sent: ‎08/‎06/‎2015 12:54
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "PLplot development list" <Plp...@li...>
Subject: Re: [Plplot-devel] The multiple keypress problem when usinginteractive drivers


On Jun 8, 2015, at 7:24 AM, Phil Rosenberg <p.d...@gm...> wrote:

>> 
>> I agree.  In the new wingdi I tried to minimize the use of the stream.
> Out of curiosity, how do you deal with redraws then - or do you just
> not scale anything and store the bitmap for refreshing?
> 

I looked at using the stretched blit, but I didn't think it would give good results of the plot was small and the maximized. I'm still using the plRemakePlot, which is why I'm having problems with the extra plP_eop call. 

Re: [Plplot-devel] PLplot and C++

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

On 2015-06-08 08:55-0000 Arjen Markus wrote:

> See the new results. They seem almost perfect. Only the Ada problem is left at a superficial examination of the reports.

Thanks very much for doing these two tests (with and without Ada).  I
agree these results are the best Cygwin results (outside your DISPLAY
issues where I think I have found a solution below) we have ever seen.
For example, because you are now using lua-5.2, you are getting a
clean Lua run-time result, e.g.,

lua
   Missing examples            :
   Differing graphical output  :
   Missing stdout              :
   Differing stdout            :

And you similarly have clean results for c++, f95, python, and tcl.  To see all of these
voluminous diff results for every configuration, I suggest you try

grep -B1 -A3 "Missing examples" */output_tree/*.out |less

If you run that command, you will notice that Python and Lua results are missing for
the static case, but that is by design; those bindings only work
for the shared library case.

With regard to the on-going Ada problems, thanks to your first report
I have now tracked the issue down to an incomplete link command for
the Ada library, i.e., my CMake Ada language support is incomplete on
Cygwin.  I am going to take a quick look at that now, but if it looks
like the fix is going to be complicated, I will likely put off working
on it until after this forthcoming release has been made.

I also am just in the process of revising Tcl/Tk linking to eliminate
redundant linking of libtclmatrix, libplplottcltk, and libplplot when
ENABLE_DYNDRIVERS=OFF.  (For that case all the libtclmatrix and
libplplottcltk code is already in libplplot so the first two libraries should
not even be built, and all links should be made solely to libplplot
rather than those first two libraries.) I think this change is going
to sort out some memory management issues we have historically had
with interactive testing of Tcl/Tk on both Cygwin and Linux in the
past for the ENABLE_DYNDRIVERS=OFF case.  We worked around those issues
by dropping such testing, but I am also going to reinstate that testing
to make sure this elimination of redundant linking cures all these
problems.

Meanwhile, so that you can start interactive testing again
you have to sort out the DISPLAY issues that are
currently prohibiting your interactive tests of Tcl and Tk.  For
example, in the present results for cmake.out you have the following
error/warning set of messages:

-- TK_WISH = /bin/wish
Application initialization failed: no display name and no $DISPLAY environment variable
Error in startup script: couldn't load file "/usr/bin/tk85.dll": No such file or directory
     while executing
"load /usr/bin/tk85.dll Tk"
     ("package ifneeded Tk 8.5.18" script)
     invoked from within
"package require Tk"
     invoked from within
"puts -nonewline [package require Tk]"
     (file "/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/CheckTK_VERSION.tcl" line 1)
-- Looking for Tk version with wish - not found
-- WARNING: setting ENABLE_tk to OFF

I did a google search for the terms

<cygwin "Application initialization failed: no display name">

and came up with
<http://stackoverflow.com/questions/9393462/cannot-launch-git-gui-using-cygwin-on-windows>

The most popular answer implies that since 2012 or so Cygwin made an
important Tcl/Tk and X change so a different procedure must be used to
get X working properly.  That answer and its discussion gives the
exact details about what has to be done. I hope those instructions
work for you (and also Phil who is also having trouble getting X to
work on modern Cygwin).  If those instructions work for you could you
please put them on our Wiki so all our Cygwin users can get access to
X?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

On Jun 8, 2015, at 7:24 AM, Phil Rosenberg <p.d...@gm...> wrote:

>> 
>> I agree.  In the new wingdi I tried to minimize the use of the stream.
> Out of curiosity, how do you deal with redraws then - or do you just
> not scale anything and store the bitmap for refreshing?
> 

I looked at using the stretched blit, but I didn't think it would give good results of the plot was small and the maximized. I'm still using the plRemakePlot, which is why I'm having problems with the extra plP_eop call. 

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

>
> I agree.  In the new wingdi I tried to minimize the use of the stream.
>
Out of curiosity, how do you deal with redraws then - or do you just
not scale anything and store the bitmap for refreshing?

Phil

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



> -----Original Message-----
> From: Arjen Markus [mailto:Arj...@de...]
> Sent: Monday, June 08, 2015 9:29 AM
> To: Alan W. Irwin
> Cc: plp...@li...
> Subject: Re: [Plplot-devel] PLplot and C++
>
> Hi Alan,
>
>
> I have turned it off again (using the Cmake variable) and continuing with the other
> stuff.
>
> Cmake is a lot happier though - see the attached tar-ball.
>

See the new results. They seem almost perfect. Only the Ada problem is left at a superficial examination of the reports.

Regards,

Arjen



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

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,

>> 1. Ada
>>
>> I think I have now fixed that issue (commit id = 63bdf93) so please try again.  There
>> is a library naming inconsistency issue for Ada on MinGW which I previously fixed in
>> a way that screws up Ada on Cygwin.
>> From your report there is no such naming convention inconsistency for Ada on
>> Cygwin so the fix was simply to exclude Cygwin from the previous library naming
>> convention inconsistency fix.
>>
> Yes, as you saw later, I merely removed the definition of the CMAKE_LIBRARY_PATH variable. With
> the recent changes in the code for finding the Ada libraries it should work again. So I put it back.

Making the examples failed:
make[2]: Entering directory '/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree'
/usr/bin/cmake.exe -E cmake_progress_report /cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/build_tree/CMakeFiles
make[2]: *** No rule to make target 'dll/libplplotada.dll.a', needed by 'examples/ada/x00a.exe'.  Stop.

I have turned it off again (using the Cmake variable) and continuing with the other stuff.

Cmake is a lot happier though - see the attached tar-ball.

Regards,

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

Re: [Plplot-devel] PLplot and C++

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

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Friday, June 05, 2015 10:00 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: RE: [Plplot-devel] PLplot and C++
>
> On 2015-06-05 12:08-0000 Arjen Markus wrote:
>
> > Here is the result (I had to switch off Ada and I need to reinstall
> Tcl as bits and pieces required for the development of extensions are missing), but
> PyQt4 worked now. The various components are getting fairly complete.
>
> Hi Arjen:
>
> Thanks for the two comprehensive_test.tar.gz tarballs you sent me to analyze. Let
> me designate the first one (the one that failed for Ada) as I, and the one that
> succeeded as II.
>
> ===========================
> Remarks concerning I alone:
> ===========================
>
> 1. Ada
>
> I think I have now fixed that issue (commit id = 63bdf93) so please try again.  There
> is a library naming inconsistency issue for Ada on MinGW which I previously fixed in
> a way that screws up Ada on Cygwin.
> From your report there is no such naming convention inconsistency for Ada on
> Cygwin so the fix was simply to exclude Cygwin from the previous library naming
> convention inconsistency fix.
>

Yes, as you saw later, I merely removed the definition of the CMAKE_LIBRARY_PATH variable. With the recent changes in the code for finding the Ada libraries it should work again. So I put it back.

> =================================
> Remarks concerning both I and II:
> =================================
>
> 1. Lua
>
> Two days ago your Lua result in cmake.out was
>
> -- LUA_VERSION = 5.1
> -- LUA_INCLUDE_DIR = /usr/include
> -- LUA_LIBRARIES = /usr/lib/liblua5.1.dll.a;/usr/lib/libm.a
> -- Found Lua: /usr/bin/lua.exe
>
> Now for both I and  II you have
>
> -- LUA_VERSION = 5.2
> -- LUA_INCLUDE_DIR = LUA_INCLUDE_DIR-NOTFOUND
> -- LUA_LIBRARIES =
> -- Could NOT find Lua (missing:  LUA_LIBRARIES LUA_INCLUDE_DIR)
> -- WARNING: Lua library and/or header not found. Disabling Lua bindings
>
> I suspect what is going on here is you removed lua-5.1 and tried to replace it with
> lua-5.2.  But the package name scheme is a little different for 5.2.  For example, I did
> a search for the regex "include.*/lua\.h"
> and the result was
>

I cannot remember doing that on purpose, I must say. I wonder if this could have been an action from the setup program?

> By the way, my package searches the other day did not find the 5.2 version of lua at
> all, and other evidence (i.e., the dates on the files which are 2015-06-04) also
> indicate 5.2 is very new. So if you requested packaging that version on the Cygwin
> mailing list, I have to congratulate you for getting really fast action!
>
Well, this definitely had nothing to do with me.

> 2. wxwidgets
>
> The only information is
> -- WARNING: wxWidgets or its libraries not found so setting all wxwidgets devices to
> OFF.
> -- WARNING: PLD_wxwidgets is OFF so setting ENABLE_wxwidgets to OFF.
>
> In the master tip version there should have been more information.  So please
> remember to update to master tip before your next try.

I almost always first update the master and I did so on this occasion as well. Odd.
>
> Also, you have remarked you have already installed libwx_gtk2u2.8-devel-2.8.12.1-5.
> And <https://www.cygwin.com/cygwin-ug-net/setup-net.html#setup-packages>
> says "setup.exe automatically selects dependencies".  However, there could be a
> packaging error (we already encountered that for one package whose name I have
> forgotten where the package dependencies were not specified correctly).  So I
> searched using the term "libwx"
> and came up with the following 2.8.12.1-5 results:
>
> libwx_baseu2.8-devel-2.8.12.1-5 - libwx_baseu2.8-devel: Obsolete package
> (installed binaries and support files)
> libwx_baseu2.8_0-2.8.12.1-5 - libwx_baseu2.8_0: wxWidgets C++ application
> framework (base unicode runtime) (installed binaries and support files)
> libwx_gtk2u2.8-devel-2.8.12.1-5 - libwx_gtk2u2.8-devel: wxWidgets C++ application
> framework (development) (installed binaries and support files)
> libwx_gtk2u2.8-doc-2.8.12.1-5 - libwx_gtk2u2.8-doc: wxWidgets C++ application
> framework (documentation) (installed binaries and support files)
> libwx_gtk2u2.8_0-2.8.12.1-5 - libwx_gtk2u2.8_0: wxWidgets C++ application
> framework (GTK+ unicode runtime) (installed binaries and support files)
>
> The first of those is described as obsolete so I assume you should not have it
> installed, and you may not have the doc package installed either, but installation of
> libwx_gtk2u2.8-devel-2.8.12.1-5 should pull in the rest of those, and if not you are
> going to have to follow up by installing the missing ones individually.
>
I was missing the doc package only. I have installed that now as well and I am waiting for the results.

>
> So if you cannot get 2.8.12.1-5 to work, I would remove all the above
> 2.8.12.1-5 packages and instead install libwx_gtk2u3.0-devel-3.0.2.0-1 (which
> should pull in the rest of the 3.0.2.0-1 packages other than the doc one unless there
> is a dependency issue in the packaging).

That is something I can do when the 2.8 stuff does not work, indeed.

>
> 3. Tcl and friends:
>
> With the rename of your /usr/local version you are obviously not finding any
> Tcl/Tk/Itcl/Itk library now, but I think that is simply a matter of installing the Cygwin
> packages I recommended before, i.e., "the consistent set of Cygwin development
> packages, e.g., tcl-devel-8.5.18-1, tcl-tk-devel-8.5.18-1, tcl-itcl-3.4.1-1, and
> tcl-itk-3.3-2 (found respectively by using the search strings "tcl-devel", "tk-devel",
> itcl.h, and itk.h)."  You might have to dig deeper if there is a dependency issue in the
> packaging of any of these packages.
>
Reinstalled it. Should be correct in the next batch of tests.

Regards,

Arjen



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

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

> On Jun 7, 2015, at 9:53 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> The eop call is required because there is some code in bop that needs
> to be called, but if bop is called before eop then that function just
> returns.
> 
> I am sure that you will find the same thing for the Windows driver too.
> 

The extra plP_eop() causes problems on the new wingdi driver that I wrote.  Nothing insurmountable, but I will dig around for a solution that also fixes the multiple keypress bug.

> To be honest I was recently thinking that the buffer is fast
> approaching a rather uncomfortable midway point between either
> representing only graphics operation or representing pllot commands.
> This comes from the fact that drivers also sit in this uncomfortable
> midway point. A good example is the clear operation. The clear
> operation should clear the subpage, but that requires the driver to
> know the subpage geometry so instead of the driver receiving the
> graphics operation of "fill this rectangle with the background colour)
> it is left for the drivers to fish that geometry from the stream. I
> can understand why this is done because some drivers may be able to
> actually clear regions rather than just draw a box.
> 
> For now I think we just have to live with it and work the buffer as
> best we can, in this uncomfortable zone. But in the long term I would
> suggest that the drivers should not be given access to the stream.
> This will put them solidly in the graphics device region and make the
> buffer way simpler.
> 

I agree.  In the new wingdi I tried to minimize the use of the stream.

> But at the same time we have plenty of other stuff to do so I don't
> think this is anything like a priority at the moment.
> 
> Phil
> 
> On 7 June 2015 at 05:25, Jim Dishaw <ji...@di...> wrote:
>> While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.
>> 
>> In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.
>> 
>> I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to “do the right thing” that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().
>> 
>> @Aaron & Alan (and others who might be interested)
>> I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?
>> 
>> Once I finish with wingdi, I will implement the Direct2D version.
>> 
>> 
>> @Alan
>> 
>> I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

On 2015-06-07 00:25-0400 Jim Dishaw wrote:

> While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.
>
> In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.
>
> I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to “do the right thing” that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().
>

> @Aaron & Alan (and others who might be interested) I have attached
two sets of patches.  One fixes some build problems I was having with
MSVC and the second implements the new windows GDI driver (which is
mostly done).  I need to add some features that I had in my old driver
(coordinate point picking, optional tab interface, saving plots into
files, optional menu bar).

@Arjen and Phil:

Will you two please take a close look at Jim's patch series concerning
MSVC build problems?  If you try them out and they definitely improve
the build on MSVC, then I think we should push them now as a bug fix
so they will be part of the forthcoming release.

> Should I add Freetype back in?
> Once I finish with wingdi, I will implement the Direct2D version.

Aaron responded to this by asking

"Is it not possible to eliminate it [the plfreetype approach] and still get nice looking
anti-aliased text with GDI/GDI+/Uniscribe?"

@Aaron and Jim:

Here is my response to both of you on these interesting questions.

@Jim:

The quick answer is no, don't bother with the currently deprecated
plfreetype approach and instead move forward with your plans to
implement a Direct2D approach for your successor to the wingcc
device driver.

@Aaron: I encourage you to add to Jim's planned Direct2D approach by 
implementing a Uniscribe approach as well for the case where the user
has an older Windows system with no Direct2D available.

@Jim and Aaron: I hope that division of the labour works for you.

You should also note that in earlier parts of this discussion Phil
mentioned the possibility of modifying the currently deprecated
plfreetype approach to take care of its known issues with finding
glyphs in system fonts and rendering those glyphs properly for complex
text layout languages.  Specifically, he proposed we should deal with
those issues by using the capabilities of the GTK+ components,
fontconfig, pango, and harfbuzz which are available on both Unix and
Windows platforms.  I think that would be a very useful project if
someone wants to take that on.  However, such an approach would have
some obvious dependencies on GTK+ components that are going to
irritate some Windows users.  So if/when the plfreetype approach is
modified as above would be the time to add it back into the successor
to wingcc as an alternative to the Uniscribe and Direct2D alternatives
that should also be available.

> @Alan
>
> I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.

@Jim:

No problem.

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 and C++

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

On 2015-06-07 14:41+0100 Phil Rosenberg wrote:

> Hi Alan
> Just tried to build on Linux, but I'm getting the following error during make
>
> Linking Fortran static library libplf95demolib.a
> Error running link command: No such file or directory
> make[2]: *** [examples/f95/libplf95demolib.a] Error 2
> make[1]: *** [examples/f95/CMakeFiles/plf95demolib.dir/all] Error 2
> make: *** [all] Error 2
>
> Any suggestions?
>
> Phil my cmake command was just
>
> cmake .. -DENABLE_TEST=ON

Hi Phil:

What version of PLplot (i.e, what commit id on master, or if this is some private branch
what was the commit id on master before the branch)?  What Linux distribution?

Your bad build result is obviously contrary to all other recent good
testing results so I am likely going to need a lot more details then
the answers to the two questions above.  Currently, the best way to
generate those details for me is to do the following:

Change directory to the top directory of the source tree and then run

scripts/comprehensive_test.sh --do_test_interactive no

and regardless of the results you get (error out or test completely
finishes) send me the details of the comprehensive test which should
all be captured in

../comprehensive_test_disposeable/comprehensive_test.tar.gz

The --do_test_interactive no option above is simply a matter of
convenience for you so you do not have to babysit the test.  If the
test results are perfect (i.e., the test goes through to completion) it
will probably take an hour, but it will be much shorter than that if,
say, the fortran aspects of the test are not working for some reason.

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

No real reason for adding Freetype back in. I thought some people might like it. I can keep it a pure windows API driver--easier for me. 



> On Jun 7, 2015, at 10:40 AM, Aaron Hexamer <he...@co...> wrote:
> 
> Jim,
> 
> Thanks for providing these patches.  I'll try to steal some time to try them out.  I'm not sure I understand the reason you're asking about adding Freetype back.  Is it not possible to eliminate it and still get nice looking anti-aliased text with GDI/GDI+/Uniscribe?
> 
> Thanks,
> 
> Aaron.
> 
> -----Original Message-----
> From: Jim Dishaw [mailto:ji...@di...] 
> Sent: Saturday, June 06, 2015 11:26 PM
> To: PLplot development list
> Cc: Aaron Hexamer
> Subject: The multiple keypress problem when using interactive drivers
> 
> While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.
> 
> In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.
> 
> I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to  do the right thing  that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().
> 
> @Aaron & Alan (and others who might be interested) I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?
> 
> Once I finish with wingdi, I will implement the Direct2D version.
> 
> 
> @Alan
> 
> I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.
> 
> 
> 

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

[Aaron H. <he...@co...>]

Jim,

Thanks for providing these patches.  I'll try to steal some time to try them out.  I'm not sure I understand the reason you're asking about adding Freetype back.  Is it not possible to eliminate it and still get nice looking anti-aliased text with GDI/GDI+/Uniscribe?

Thanks,

Aaron.

-----Original Message-----
From: Jim Dishaw [mailto:ji...@di...] 
Sent: Saturday, June 06, 2015 11:26 PM
To: PLplot development list
Cc: Aaron Hexamer
Subject: The multiple keypress problem when using interactive drivers

While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.

In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.

I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to  do the right thing  that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().

@Aaron & Alan (and others who might be interested) I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?

Once I finish with wingdi, I will implement the Direct2D version.


@Alan

I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.

Re: [Plplot-devel] The multiple keypress problem when using interactive drivers

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

The eop call is required because there is some code in bop that needs
to be called, but if bop is called before eop then that function just
returns.

I am sure that you will find the same thing for the Windows driver too.

To be honest I was recently thinking that the buffer is fast
approaching a rather uncomfortable midway point between either
representing only graphics operation or representing pllot commands.
This comes from the fact that drivers also sit in this uncomfortable
midway point. A good example is the clear operation. The clear
operation should clear the subpage, but that requires the driver to
know the subpage geometry so instead of the driver receiving the
graphics operation of "fill this rectangle with the background colour)
it is left for the drivers to fish that geometry from the stream. I
can understand why this is done because some drivers may be able to
actually clear regions rather than just draw a box.

For now I think we just have to live with it and work the buffer as
best we can, in this uncomfortable zone. But in the long term I would
suggest that the drivers should not be given access to the stream.
This will put them solidly in the graphics device region and make the
buffer way simpler.

But at the same time we have plenty of other stuff to do so I don't
think this is anything like a priority at the moment.

Phil

On 7 June 2015 at 05:25, Jim Dishaw <ji...@di...> wrote:
> While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.
>
> In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.
>
> I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to “do the right thing” that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().
>
> @Aaron & Alan (and others who might be interested)
> I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?
>
> Once I finish with wingdi, I will implement the Direct2D version.
>
>
> @Alan
>
> I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] PLplot and C++

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

 Hi Alan
Just tried to build on Linux, but I'm getting the following error during make

Linking Fortran static library libplf95demolib.a
Error running link command: No such file or directory
make[2]: *** [examples/f95/libplf95demolib.a] Error 2
make[1]: *** [examples/f95/CMakeFiles/plf95demolib.dir/all] Error 2
make: *** [all] Error 2

Any suggestions?

Phil my cmake command was just

cmake .. -DENABLE_TEST=ON

On 6 June 2015 at 19:44, Alan W. Irwin <ir...@be...> wrote:
> On 2015-06-06 13:56+0100 Phil Rosenberg wrote:
>
>> I sent my previous email to just alan rather than reply all - Arjen
>> and others see below.
>>
>> I've just uploaded a commit which means FindwxWidgets.cmake looks for
>> wx-config-3.0 and wx-config-2.8. This will work for now while we only
>> have those two versions to check for, but frustratingly this means
>> that we will have to update when each new version comes out. Alan your
>> better CMAKE skill might mean you can come up with a better solution.
>
>
> Hi Phil:
>
> Good catch on the versioned wx-config names for Cygwin!
>
> I did find a slicker solution for those various names, see commit 215a6f6.
> Furthermore,
> it turns out that CMake-3.3.0-rc1 has already started to deal with
> this issue (they search for
>
> wx-config-3.0 wx-config
>
> ), but obviously
> that is not enough so I have just posted to the CMake developer list
> asking them to change that list of aliases to
>
> wx-config-3.0 wx-config-2.9 wx-config-2.8 wx-config
>
> which is what we are adopting locally for PLplot.
>
>> This change allows wxWidgets to be found on my Cygwin install. I can
>> build the library and examples, but unfortunately the Cygwin upgrade
>> that occurred alongside my wxWidgets install appears to have stuffed
>> up my X11 setup so I can't test it running right now.
>>
>> Arjen if you are testing this immediately you might need to include
>> -DPLD_wxwidgets=ON until Alan is happy to reenable wxWidgets by
>> default after my Linux build issue the other day.
>
>
> @Phil and Arjen:
>
> I can now build the wxwidgets device driver on Linux against
> wxwidgets-2.8 so I have now changed our build system (commit ID
> 354bffe) so that PLD_wxwidgets=ON by default.
>
> @Phil:
>
> However, the wxwidgets device is still extraordinarily slow on Linux,
> e.g.,
>
> software@raven> time examples/c/x00c -dev wxwidgets
>
> real    0m8.755s
> user    0m0.028s
> sys     0m0.068s
>
> You should be able to verify this slowness yourself (using the time
> application [which comes with bash] as above) when you try master tip
> on your Linux platform.  Note also, the actual cpu time as measured by
> user and sys is quite small. I also verify that during mass testing of
> -dev wxwidgets via the test_c_wxwidgets target, the actual CPU use is
> negligible with a GUI I have that measures overall CPU usage.  So
> something else than CPU usage is slowing down the app. You have
> mentioned before that there is a polling interval you can set so I
> assume some adjustment of that will reduce the real time to something
> much more reasonable.  I wonder, for example, whether this trouble is
> caused by the units of that polling interval being different on Linux
> versus Windows?
>
> @Arjen:
>
> If the current wxwidgets slowness on Linux is also true on Cygwin, it
> will not affect your comprehensive testing even if you do the
> interactive part of it.  The reason is that I have deliberately
> removed wxwidgets tests from overall testing targets such as
> test_interactive until these slowness issues and in particular the -np
> issue can be fixed.  However, you and Phil can build the test_c_wxwidgets
> target by itself from the build tree on Cygwin to evaluate how
> fast a fairly wide subset of the examples will render with the wxwidgets
> device.
>
>
> 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] The multiple keypress problem when using interactive drivers

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

While working on my old Windows GDI based driver (see attached patches), I stumbled across the problem that prompted Phil to add plP_eop() in plRemakePlot(). This is related to the issue that Andrew raised on 3/29 on problems with -np when running automated testing.

In plbuf.c, the EOP is never inserted into the plot buffer while the plot is being generated.  The obvious issue to having an EOP in the plot buffer is that it would trigger the device EOP handler (e.g. plD_eop_xw) and in a GUI driver that could cause problems (i.e. the WaitForPage() in the xwin driver would be called multiple times). While working on wxwidgets, Phil added a call to plP_eop() in the plRemakePlot() function in plbuf.c, which triggers the EOP handler and results in the need for a keypress.  I thought eliminating the call to plP_eop() would be the simple fix (it does fix the bug) but having the EOP is handy when redrawing the plot.

I looked at the possibility of keeping the EOP in the plot buffer, but there is all sorts of messy code on trying to “do the right thing” that I think might cause more problems.  In the ideal world, I like the symmetry of having both a BOP and EOP in the plot buffer.  However, to support that correctly in the GUI drivers might be tricky.  Instead, I think the best solution is to eliminate the plP_eop() call that was added into plRemakePlot. That will fix the issue that Andrew raised.  The downside is that Phil might need to make some changes to wxwidgets.  It took some effort to get the new windows GDI driver working without the plP_eop() call, but it does work.  I can make a fix for plbuf.c that removes the plP_eop().

@Aaron & Alan (and others who might be interested)
I have attached two sets of patches.  One fixes some build problems I was having with MSVC and the second implements the new windows GDI driver (which is mostly done).  I need to add some features that I had in my old driver (coordinate point picking, optional tab interface, saving plots into files, optional menu bar).  Should I add Freetype back in?

Once I finish with wingdi, I will implement the Direct2D version.


@Alan

I was not able to uncrustify.  I have not had time to set it up on my Windows machine.  Sorry.

Re: [Plplot-devel] PLplot and C++

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

On 2015-06-06 13:56+0100 Phil Rosenberg wrote:

> I sent my previous email to just alan rather than reply all - Arjen
> and others see below.
>
> I've just uploaded a commit which means FindwxWidgets.cmake looks for
> wx-config-3.0 and wx-config-2.8. This will work for now while we only
> have those two versions to check for, but frustratingly this means
> that we will have to update when each new version comes out. Alan your
> better CMAKE skill might mean you can come up with a better solution.

Hi Phil:

Good catch on the versioned wx-config names for Cygwin!

I did find a slicker solution for those various names, see commit 215a6f6.  Furthermore,
it turns out that CMake-3.3.0-rc1 has already started to deal with
this issue (they search for

wx-config-3.0 wx-config

), but obviously
that is not enough so I have just posted to the CMake developer list
asking them to change that list of aliases to

wx-config-3.0 wx-config-2.9 wx-config-2.8 wx-config

which is what we are adopting locally for PLplot.

> This change allows wxWidgets to be found on my Cygwin install. I can
> build the library and examples, but unfortunately the Cygwin upgrade
> that occurred alongside my wxWidgets install appears to have stuffed
> up my X11 setup so I can't test it running right now.
>
> Arjen if you are testing this immediately you might need to include
> -DPLD_wxwidgets=ON until Alan is happy to reenable wxWidgets by
> default after my Linux build issue the other day.

@Phil and Arjen:

I can now build the wxwidgets device driver on Linux against
wxwidgets-2.8 so I have now changed our build system (commit ID
354bffe) so that PLD_wxwidgets=ON by default.

@Phil:

However, the wxwidgets device is still extraordinarily slow on Linux,
e.g.,

software@raven> time examples/c/x00c -dev wxwidgets

real    0m8.755s
user    0m0.028s
sys     0m0.068s

You should be able to verify this slowness yourself (using the time
application [which comes with bash] as above) when you try master tip
on your Linux platform.  Note also, the actual cpu time as measured by
user and sys is quite small. I also verify that during mass testing of
-dev wxwidgets via the test_c_wxwidgets target, the actual CPU use is
negligible with a GUI I have that measures overall CPU usage.  So
something else than CPU usage is slowing down the app. You have
mentioned before that there is a polling interval you can set so I
assume some adjustment of that will reduce the real time to something
much more reasonable.  I wonder, for example, whether this trouble is
caused by the units of that polling interval being different on Linux
versus Windows?

@Arjen:

If the current wxwidgets slowness on Linux is also true on Cygwin, it
will not affect your comprehensive testing even if you do the
interactive part of it.  The reason is that I have deliberately
removed wxwidgets tests from overall testing targets such as
test_interactive until these slowness issues and in particular the -np
issue can be fixed.  However, you and Phil can build the test_c_wxwidgets
target by itself from the build tree on Cygwin to evaluate how
fast a fairly wide subset of the examples will render with the wxwidgets
device.

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
__________________________