plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Status report on remaining issues to be addressed for the forthcoming 5.11.1 release

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

 Hi Alan

Regarding the tcl cmake bug it is still there. Just to reiterate the
problem does not seem to be that the file that is being looked for has
a space - the problem is that the file genuinely does not exist. So
the problem must be elsewhere in the CMake logic, which could be due
to speces still I guess.

Here is the error I get from trying to build INSTALL

102> CMake Error at bindings/cmake_install.cmake:39 (file):

102> file INSTALL cannot find "D:/usr/local/src/plplot-plplot/build/Visual

102> Studio 11 64sd/bindings/pkgIndex.tcl".

102> Call Stack (most recent call first):

102> cmake_install.cmake:61 (include)

102>

102>

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: The command "setlocal

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: "C:\Program Files (x86)\CMake\bin\cmake.exe"
-DBUILD_TYPE=Debug -P cmake_install.cmake

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: if %errorlevel% neq 0 goto :cmEnd

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: :cmEnd

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto
:cmDone

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: :cmErrorLevel

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: exit /b %1

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: :cmDone

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: if %errorlevel% neq 0 goto :VCEnd

102>C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(134,5):
error MSB3073: :VCEnd" exited with code 1.

Perhaps if you try to build in a directory with a space you will be
able to see more easily what the problem is?

Regarding the speed on Linux.I have a problem which I will describe
below with my Ubuntu machine, but I have just quickly tested example 3
with ssh over the internet connecting to my work CentOS PC. I think
was the example you used to highlight the problem. On Windows it takes
about 3 seconds from selecting the wxWidgets driver and pressing enter
to running the wxViewer and displaying the plot. By comparison the ssh
over the internet test takes about 10 seconds. 6 of those seconds are
the time up to the window being initially displayed so they are
probably the time required to load the executable and for wxWidgets to
do its initial window setup. This leaves about 4 seconds to transfer
the data to wxViewer and render. While I agree that this isn't
brilliant, given all the extra overheads going on with that connection
I think that is acceptable. What sort of rendering times do you see
running on an actual Linux machine?

Now for my Ubuntu machine. I have hit a snag that has come from the
checking text length. I think from the limited debugging I have done
that when I try to get the font metrics in the console part of the
device this causes a segfault within wxWidgets. This is therefore
going to have to be rewritten. For some reason there is no problem on
my CentOS machine, I think this is running wxWidgets 2.8 rather than
3.0. If anyone else can confirm this behaviour then it would be
appreciated.

Regarding other bugs. Please see my trello page where I am currently
tracking everything
https://trello.com/b/xBv7SJco/plplot-wxwidgets-plus-related-buffer-issues.

One item I would appreciate confirmation on - it seems like fixing the
text size problem has fixed the bad transform of 3d text, at least to
my eyes. If you could take a quick look and confirm you are happy that
would be good.

Phil

On 19 June 2015 at 21:02, Alan W. Irwin <ir...@be...> wrote:
> As release manager for the forthcoming release of 5.11.1, I would
> appreciate those who have further bug fixing projects in mind for this
> release cycle leading up to 5.11.1 inform me of those projects.
>
> @ Phil: specifically what is on your agenda for wxwidgets bug fixing
> for the next several weeks? For example, I would dearly like to see
> the extreme slowness regression (introduced since 5.11.0) for
> wxwidgets on Linux fixed for this release, and the last I heard on
> that topic from you was you could not build PLplot on Linux to
> investigate the matter further.  At which point I asked for a
> comprehensive test report on that situation (see below), but I have
> not received that yet from you.  Also, with regard to the concatenated
> file bug you found in our build system for a "spaced" build tree, I
> committed a second version of that fix after you reported the first
> one did not completely work, and I am currently waiting for your
> report of whether that second fix works.
>
> My own agenda items for the remainder of this release cycle are as follows:
>
> * Keep up with on-going resolution of bugs in our C/C++ source code.
>   Those currently include the wxwidgets extreme slowness regression on
>   Linux mentioned above, Jim's series of patches fixing the eop
>   problem for interactive devices, and the on-going discussion of the
>   notcrossed functionality with Phil.  Please let me know if I forgot
>   anything here that should be on my agenda during the rest of this
>   release cycle.
>
> * Fix build-system issues that are discovered via comprehensive
>   testing by everyone that is lurking on this list that routinely
>   builds PLplot from our git version.  Arjen has been extremely
>   helpful in this regard, and future builds of 5.11.1 on Cygwin should
>   be much easier for our users as a result of his many tests, but I
>   strongly encourage the rest of you to start running
>
>   scripts/comprehensive_test.sh --do_test_interactive no
>
>   on all platforms accessible to you on a routine basis.  (That option
>   is a convenience to make that script run without the babysitting
>   required for the interactive comprehensive testing part of the
>   script.) That script automatically collects a report tarball in
>   ../comprehensive_test_disposeable/comprehensive_test.tar.gz that you
>   should send to this list if you have any difficulties on a platform
>   since that tarball generally gives all the information I need to
>   analyze the issue and find a build-system fix for it.  Also, please
>   send that report tarball in the case when you have a (partial)
>   success you want to see reported on our wiki since the report
>   tarball generally includes all necessary information for that wiki
>   entry. Such comprehensinve test results from a lot of you here will go a
> long way
>   to insure that 5.11.1 will have good build behaviour on all
>   platforms.
>
> * Remove everything to do with long-retired device drivers since the
>   outdated information in those files simply confuses those who want
>   to develop a modern PLplot device driver.
>
> * Extend the TEST_DEVICE concept, e.g., for the svg device from ctest
>   to the test_noninteractive target for the build tree, install tree,
>   and traditional install tree.
>
> * Improve exporting of PLplot targets following
>   <http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html>.
>
> * Update epa_build to the latest versions of cmake and all libraries.
>
> * Investigate a report on plplot-general that "MinGW Makefiles" fails to
>   build for 5.11.0 although it was fine for 5.10.0.
>
> * One more try at a MinGW-w64/MSYS2 install on Wine to see if the latest
>   development version of Wine has fixed the bugs that did not allow that
>   before.  However, because Wine is incredibly slow, I am hoping I
>   will never have to do this and someone else here will adopt that
>   platform for comprehensive testing (see above agenda item concerning
>   comprehensive testing on all accessible platforms).
>
> * Fix Ada language support for Cygwin.
>
> In the interests of getting 5.11.1 out roughly a month from now rather
> than considerably later, I will likely have to put off the last three
> items until later.  But I am pretty sure I can get everything else on
> the above agenda into 5.11.1 especially with cooperation from everyone
> lurking on this list on doing comprehensive testing and sending the
> report tarballs that are automatically generated by that script to
> this list.
>
> 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] Bug fix to plbuf.c

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

On 2015-06-15 12:24-0400 Jim Dishaw wrote:

> Attached is a patch series that implements the second solution.  I
tested the changes to xwin driver; however, I was not able to test
tkwin, qt, or cairo.  I will provide an update to wingcc separately. 
I didn’t touch the wxwidgets driver.

> The xwin driver occasionally misses some resizes, but I think that is
some quirky behavior that existed prior to 5.10.

> If someone could test the tkwin, qt, and cairo (specifically xcairo)
that would be greatly appreciated.

Hi Jim:

As promised I finally have had a chance to test this patch series. It
applies cleanly (aside for some white space issues that are
automatically cleaned up by git) to a private topic branch based on
git master tip.  Also, I encountered no obvious issues with builds
(other than the easily fixed cairo issue below).

N.B. So once you have fixed the cairo build issue please go ahead and
push this result as well as your other result involving wingcc
(assuming you have testing resizing with that device).

Here are some specific comments with respect to resize issues still
encountered with the various device drivers I tested typically using the

examples/c/x08c -dev <interactive device>

command for various interactive devices.

* qtwidget

The resizing results seem _almost_ perfect to me.  No black screen,
graphical and text results scaled properly no matter how much I
dragged the corner of the qtwidget GUI around my desktop.  However, if
I drag from a large size _rapidly to a small one, there is often no
response, and I had to repeat the process with a slower drag.  I
believe this is what you referred to above (for the xwin device) as
missing some resizes.  Presumably this is a long-standing issue we
should address some day. Aside from this one issue, in my opinion the
behavior of this device on resize events should be the paradigm for
all other interactive devices.

In particular, for me text scaling on resize events is the right thing
to do, but from recent list traffic I am still in the process of
convincing Phil on that issue for the wxwidgets device and you on that
issue for the new GDI device.  :-) But if either of you try qtwidget,
I think those nice scaled text results should convince you to at least
provide a (default) option to do text scaling on resize events for the
wxwidgets and new GDI device cases.

* tk

This device (although it uses ugly Hershey fonts rather than system
fonts like qtwidget) has perfect resizing of graphics and text. And
despite maximum violence of my mouse moves, I could not get it to miss
any resizes (unlike qtwidgets above).  However, it is not a good
candidate for a paradigm of a typical interactive device driver
because of all the complex interactions with Tcl, Tk, and the xwin
device.

* xwin

Your fix has solved the black screen issue I reported for this device.
and like the tk device (which is not surprising because they share
access to some xwin features) I cannot get it to miss resizes (unlike
what you reported above unless I am misinterpreting what you said).
However, the scaling and centering of graphics and text is out of
synch with the resize event, i.e., it reflects the size of the last
GUI rather than present GUI as you should be able to prove by making a
single large change in GUI size and releasing the mouse without
further movement.  I presume the problem here is the xwin device is
updating the scale and size of the result using data collected prior
to the resizing event rather than at the correct time after that event
so the results always reflect those incorrect prior GUI sizes.  If you
can quickly figure out a fix for this specific xwin bug (presumably in
existence for a long time), please push it, but otherwise we can
continue to live with it.

* tkwin
The only way you can exercise this "device" is with the wish technique
for the runAllDemos example documented in examples/tk/README.tkdemos
and which is also run automatically (and with all dependencies
satisfied) using

make test_wish_runAllDemos

There has been something wrong with this example for a while now (it
warns about, e.g.,

x08 invalid command name

when you hit the button for the 8th example).  So although the GUI
exists and you can resize it, the plot window subset of that GUI
remains blank so you cannot currently see if there are any issues with
plot resizing with the tkwin "device".

* xcairo

Your change produces the following build error

/home/software/plplot/HEAD/plplot.git/drivers/cairo.c: In function ‘plD_wait_xcairo’:
/home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2149:5: error: ‘event_mask’ undeclared (first use in this function)
/home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2149:5: note: each undeclared identifier is reported only once for each function it appears in
/home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2154:41: error: ‘event’ undeclared (first use in this function)
/home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2158:13: error: ‘number_chars’ undeclared (first use in this function)
/home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2158:65: error: ‘event_string’ undeclared (first use in this function)
/home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2158:84: error: ‘keysym’ undeclared (first use in this function)
/home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2158:93: error: ‘cs’ undeclared (first use in this function)
/home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2177:13: error: ‘expose’ undeclared (first use in this function)
make[3]: *** [drivers/CMakeFiles/cairo.dir/cairo.c.o] Error 1
make[2]: *** [drivers/CMakeFiles/cairo.dir/all] Error 2
make[1]: *** [drivers/CMakeFiles/cairo.dir/rule] Error 2
make: *** [cairo] Error 2

I believe the problem is you left your declarations in the wrong function.  This
patch fixes that issue:
diff --git a/drivers/cairo.c b/drivers/cairo.c
index c3e949a..c7f2ba9 100644
--- a/drivers/cairo.c
+++ b/drivers/cairo.c
@@ -2084,13 +2084,6 @@ void plD_bop_xcairo( PLStream *pls )

  void plD_eop_xcairo( PLStream *pls )
  {
-    int            number_chars;
-    long           event_mask;
-    char           event_string[10];
-    KeySym         keysym;
-    XComposeStatus cs;
-    XEvent         event;
-    XExposeEvent   *expose;
      PLCairo        *aStream;

      aStream = (PLCairo *) pls->dev;
@@ -2139,6 +2132,13 @@ void plD_tidy_xcairo( PLStream *pls )

  void plD_wait_xcairo( PLStream *pls )
  {
+    int            number_chars;
+    long           event_mask;
+    char           event_string[10];
+    KeySym         keysym;
+    XComposeStatus cs;
+    XEvent         event;
+    XExposeEvent   *expose;
      PLCairo *aStream;

      aStream = (PLCairo *) pls->dev;

After that change, the cairo device built without issues.  However,
after applying the above patch to your work, the plD_eop_xcairo function is reduced
just to

void plD_eop_xcairo( PLStream *pls )
{
     PLCairo        *aStream;

     aStream = (PLCairo *) pls->dev;

     // Blit the offscreen image to the X window.
     blit_to_x( pls, 0.0, 0.0, pls->xlength, pls->ylength );

     if ( aStream->xdrawable_mode )
         return;
}

and I assume you want to do more than the default return at the end of
the function when that last if condition is NOT satisfied.

The most important problem with the response to resize events for
xcairo is that it is essentially nonexistent.  The same plot with
exactly the same size gets replotted so either it is smaller than the
GUI window if you have resized larger or else it is too large for the
GUI window (and clipped off at the edges of the GUI) if you have
resized smaller.  If you can find an easy fix for this apparently
long-standing issue, that would be great, but otherwise we can just
live with it until some regular user of xcairo gets fed up with this
poor resize result.

* wincairo

This is a windows equivalent of xcairo so I was unable to test it, but
presumably it needs work to deal with resizing events.  I am not sure
whether wincairo will be available on Cygwin, but it should be available
on MSVC if you download and install GTK+ for Windows on that platform.

*ntk

This is an important Tk device because it is completely independent of
X (and, for example, therefore executes much faster than the tk device
on Cygwin which does depend on X).  The ntk device obviously needs
work to deal properly with resizing events since, for example, there
is the same lack of resizing capability as for xcairo.

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] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk

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

On 2015-06-19 08:02-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> Thanks for hunting down the logic bugs you mentioned yesterday.
>
>
>
> I did some investigation using nm on the build I had and reported the results from the other day, but it turns out that the libplplottcltk_Main.dll.a library contains only a few symbols, none of them __imp_Pltcl_Init. That symbol is found in libplplotcltk.dll.a in the "shared" build, but that library is not created in the "nondynamic" build.
>
>
>
> (I compared the "main" libraries for the two cases - they differ only in the timestamps for the .o files contained in there - they are in "ar" format)
>
>
>
> Hope this may shed some light.

Hi Arjen:

Thanks for that additional information.  It confirms my analysis of
the issue and the fix I came up with for the

-DPLD_tk=OFF -DPLD_tkwin=OFF

case (which is the case you reported the other day because
-DENABLE_tk=OFF automatically forces -DPLD_tk=OFF and -DPLD_tkwin=OFF).

Once you get a chance to permanently fix your X configuration, rename
/usr/local so that no longer interferes with your Cygwin PLplot
builds, install all relevant Tcl/Tk/Itcl/Itk/Iwidgets Cygwin packages,
and drop the -DENABLE_itk=OFF option, then you should be good to go
for your next comprehensive test with --do_test_interactive no.

And once everything is perfect for that case, you should attempt to
finish up this Cygwin testing effort by running the script again
without that --do_test_interactive no option (although that last test
will require some babysitting from you to click all the GUI's to get
through all the interactive tests.)

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] Status report on remaining issues to be addressed for the forthcoming 5.11.1 release

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

As release manager for the forthcoming release of 5.11.1, I would
appreciate those who have further bug fixing projects in mind for this
release cycle leading up to 5.11.1 inform me of those projects.

@ Phil: specifically what is on your agenda for wxwidgets bug fixing
for the next several weeks? For example, I would dearly like to see
the extreme slowness regression (introduced since 5.11.0) for
wxwidgets on Linux fixed for this release, and the last I heard on
that topic from you was you could not build PLplot on Linux to
investigate the matter further.  At which point I asked for a
comprehensive test report on that situation (see below), but I have
not received that yet from you.  Also, with regard to the concatenated
file bug you found in our build system for a "spaced" build tree, I
committed a second version of that fix after you reported the first
one did not completely work, and I am currently waiting for your
report of whether that second fix works.

My own agenda items for the remainder of this release cycle are as follows:

* Keep up with on-going resolution of bugs in our C/C++ source code.
   Those currently include the wxwidgets extreme slowness regression on
   Linux mentioned above, Jim's series of patches fixing the eop
   problem for interactive devices, and the on-going discussion of the
   notcrossed functionality with Phil.  Please let me know if I forgot
   anything here that should be on my agenda during the rest of this
   release cycle.

* Fix build-system issues that are discovered via comprehensive
   testing by everyone that is lurking on this list that routinely
   builds PLplot from our git version.  Arjen has been extremely
   helpful in this regard, and future builds of 5.11.1 on Cygwin should
   be much easier for our users as a result of his many tests, but I
   strongly encourage the rest of you to start running

   scripts/comprehensive_test.sh --do_test_interactive no

   on all platforms accessible to you on a routine basis.  (That option
   is a convenience to make that script run without the babysitting
   required for the interactive comprehensive testing part of the
   script.) That script automatically collects a report tarball in
   ../comprehensive_test_disposeable/comprehensive_test.tar.gz that you
   should send to this list if you have any difficulties on a platform
   since that tarball generally gives all the information I need to
   analyze the issue and find a build-system fix for it.  Also, please
   send that report tarball in the case when you have a (partial)
   success you want to see reported on our wiki since the report
   tarball generally includes all necessary information for that wiki
   entry. Such comprehensinve test results from a lot of you here will go a long way
   to insure that 5.11.1 will have good build behaviour on all
   platforms.

* Remove everything to do with long-retired device drivers since the
   outdated information in those files simply confuses those who want
   to develop a modern PLplot device driver.

* Extend the TEST_DEVICE concept, e.g., for the svg device from ctest
   to the test_noninteractive target for the build tree, install tree,
   and traditional install tree.

* Improve exporting of PLplot targets following
   <http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html>.

* Update epa_build to the latest versions of cmake and all libraries.

* Investigate a report on plplot-general that "MinGW Makefiles" fails to
   build for 5.11.0 although it was fine for 5.10.0.

* One more try at a MinGW-w64/MSYS2 install on Wine to see if the latest
   development version of Wine has fixed the bugs that did not allow that
   before.  However, because Wine is incredibly slow, I am hoping I
   will never have to do this and someone else here will adopt that
   platform for comprehensive testing (see above agenda item concerning
   comprehensive testing on all accessible platforms).

* Fix Ada language support for Cygwin.

In the interests of getting 5.11.1 out roughly a month from now rather
than considerably later, I will likely have to put off the last three
items until later.  But I am pretty sure I can get everything else on
the above agenda into 5.11.1 especially with cooperation from everyone
lurking on this list on doing comprehensive testing and sending the
report tarballs that are automatically generated by that script to
this list.

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] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Alan,



Thanks for hunting down the logic bugs you mentioned yesterday.



I did some investigation using nm on the build I had and reported the results from the other day, but it turns out that the libplplottcltk_Main.dll.a library contains only a few symbols, none of them __imp_Pltcl_Init. That symbol is found in libplplotcltk.dll.a in the "shared" build, but that library is not created in the "nondynamic" build.



(I compared the "main" libraries for the two cases - they differ only in the timestamps for the .o files contained in there - they are in "ar" format)



Hope this may shed some light.



Regards,



Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 17, 2015 9:51 PM
> To: Arjen Markus
> Cc: plp...@li...
> Subject: Re: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk
>
> Hi Arjen:
>
> After some further investigations of details in your report it turns out the error you
> found was due to a build system inconsistency when ENABLE_tk is forced to OFF.  I
> will work on solving that inconsistency.
>
> However, you do not have to wait for that fix.  So whenever convenient please move
> ahead with dropping -DENABLE_itk=OFF and getting rid of the /usr/local issues and
> the X display issue I mentioned that are currently present for your Cygwin platform.
> Once the X display issue is permantly solved, ENABLE_tk should not be forced to
> OFF which should make the missing Pltcl_Init symbol problem disappear so you
> should get a clean result with --do_test_interactive no (and with luck when you drop
> that restriction to do a full interactive comprehensive test).
>
> Also, note that when the Pltcl_Init symbol problem is fixed would be a good
> opportunity to try the "nm" experiments I suggested.  "nm" is a livesaver in these
> situations so it would be good for you to learn how to use that tool on Cygwin.
>
> 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] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk

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

On 2015-06-17 12:51-0700 Alan W. Irwin wrote:

>
> After some further investigations of details in your report it turns
> out the error you found was due to a build system inconsistency when
> ENABLE_tk is forced to OFF.  I will work on solving that inconsistency.

Hi Arjen:

Your comprehensive tests with some Cygwin Tcl/Tk/Itcl/Itk/Iwidgets
packages missing exercised our build system in a new and unique way
and found a whole bunch of logic bugs for the -DPLD_tk=OFF and
-DPLD_tkwin=OFF case which I have now fixed as of commit 12f1c93. In
that commit I also solved another build-system logic bug concerning
the -DENABLE_itk=OFF case that I noticed along the way.

There is no need to test those corner cases further since I have done
so already by other means (namely by testing for the -DPLD_tk=OFF and
-DPLD_tkwin=OFF case and also the -DENABLE_itk=OFF case).  So please
continue with the Cygwin comprehensive (and nm) testing when
convenient after you have solved your current Cygwin configuration
issues and missing package installs that I have mentioned.

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] Improving the quality of our commit messages and commits

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

Very useful. I will try to take it onboard.

Phil

On 17 June 2015 at 21:37, Alan W. Irwin <ir...@be...> wrote:
> I just ran across some really useful advice concerning git commit
> messages and organizing git commits at
> <http://who-t.blogspot.be/2009/12/on-commit-messages.html>.  I think
> that would be a worthwhile read for everyone here, and I have inserted
> (de4e65f) that URL into README.developers for future reference 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
> __________________________
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Improving the quality of our commit messages and commits

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

I just ran across some really useful advice concerning git commit
messages and organizing git commits at 
<http://who-t.blogspot.be/2009/12/on-commit-messages.html>.  I think
that would be a worthwhile read for everyone here, and I have inserted
(de4e65f) that URL into README.developers for future reference as
well.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk

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

Hi Arjen:

After some further investigations of details in your report it turns
out the error you found was due to a build system inconsistency when
ENABLE_tk is forced to OFF.  I will work on solving that inconsistency.

However, you do not have to wait for that fix.  So whenever convenient
please move ahead with dropping -DENABLE_itk=OFF and getting rid of
the /usr/local issues and the X display issue I mentioned that are
currently present for your Cygwin platform. Once the X display issue
is permantly solved, ENABLE_tk should not be forced to OFF which
should make the missing Pltcl_Init symbol problem disappear so you
should get a clean result with --do_test_interactive no (and with luck
when you drop that restriction to do a full interactive comprehensive
test).

Also, note that when the Pltcl_Init symbol problem is fixed would be a
good opportunity to try the "nm" experiments I suggested.  "nm" is a
livesaver in these situations so it would be good for you to learn
how to use that tool on Cygwin.

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] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and Ada

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

On 2015-06-17 10:39-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> Hm, something is failing in the non_dynamic tests:
>
> CMakeFiles/pltcl.dir/pltcl.c.o:pltcl.c:(.text+0x20e): undefined reference to `__imp_Pltcl_Init'
>
> CMakeFiles/pltcl.dir/pltcl.c.o:pltcl.c:(.text+0x20e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp_Pltcl_Init'
>
> So your latest changes regarding the reduction of the llibraries for the non-dynamic drivers seem to have introduced a bug. I have attached the complete tarball.

Hi Arjen:

Thanks for this test.

I. Comments on your setup of this test.

For some reason there was a regression in your X setup so that
you are now encountering that DISPLAY issue again.  The message (in
cmake.out) was

Application initialization failed: no display name and no $DISPLAY
environment variable

I encourage you to automate your X setup to avoid this regression in
behaviour in future.

Also please drop the -DENABLE_itk=OFF workaround which should not be
necessary if you have all Tcl/Tk/Itcl/Itk/Iwidgets packages properly
installed on Cygwin.  And if those are not properly installed, please
fix that.

Also, in retrospect it was a good idea for you to be cautious and test
first with --do_test_interactive no.  But once the current issue is
fixed, I will encourage you to drop that restriction so that all
the Tcl, etc., interactive results can also be run-time tested.

II. Comments on the bug you found.

The link command that is failing above is (after line wrapping at each
white space to help clarify the command and redacting the many irrelevant
parts)

/usr/bin/cc
-Wl,--enable-auto-import
CMakeFiles/pltcl.dir/pltcl.c.o
-o
pltcl.exe
-Wl,--out-implib,libpltcl.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
../../dll/libplplottcltk_Main.dll.a
/usr/lib/itcl3.4/libitcl3.4.dll.a
-ltcl
../../dll/libplplot.dll.a
[...]
/usr/local/lib/libLASi.dll.a
[...]
/usr/local/lib/libshp.a
[...]

II A.  The /usr/local issue.

Sorry I did not notice this issue before.  My assumption is that anything in /usr/local cannot be due to an
official Cygwin install so should be avoided (at least for now). So to follow up on this
I looked for "local" in cmake.out and found the following:

-- TCL_INCLUDE_PATH = /usr/local/include

-- FindShapelib: Found shapelib header directory, /usr/local/include,
and library, /usr/local/lib/libshp.a.

libplplot_LINK_FLAGS =
/usr/lib/libltdl.dll.a;/usr/lib/libdl.a;/usr/local/lib/libshp.a;/usr/lib/libfreetype.dll.a;-lcsirocsa;-lcsironn;-lqhull;-lqsastime

So please do the appropriate /usr/local renaming (perhaps of all of
/usr/local) to force CMake to find the official Cygwin versions of
Tcl, shapelib, and libLASi which I presume you have long-since already
installed.  The result should be no mention of /usr/local in cmake.out
the CMake cache files or any of your build commands.

I suspect all those /usr/local results are leftovers from an epa_build
attempt you did long ago.  At some point you might want to try
epa_build again (but with an install prefix other that /usr/local so
the results don't necessarily take CMake precedence over all others),
but only after you make sure all the official Cygwin packages work.

II B. The linking issue with pltcl that you discovered above.

The above link command for pltcl shows that libplplot
is properly linked.  So one
possibility to explain this is either Pltcl_Init is not defined in the
plplot library or it is defined in that library but not visible.  To
check that, please use the nm command (which likely is already
installed, but if not you should be able to find it in
binutils-2.25-2) as follows:

# Change to _nondynamic_ build directory
cd ../comprehensive_test_disposeable/nondynamic/build_tree/
# Build plplot library (which was cleaned by the script) in the
# nondynamic case
make plplot
# Test for definition of Pltcl_Init in that library
nm --defined-only <library_name> |grep Pltcl_Init

where <library_name> is the appropriate name of the plplot library you
just built.  Here that is src/libplplot.so, but I am aware there are
two locations (in src and in dll) of the plplot library for Cygwin,
and I don't know which one you should be using with the nm command so
you will have to experiment to find which to use with nm.

The result of the above command here is

000000000008f120 T Pltcl_Init

which indicates that symbol is defined in the plplot library
and you should be getting something similar there.

Once you have proved that symbol is defined in the plplot library
the next issue is whether that symbol is externally
visible.  "nm" tests symbol visibility with the --extern-only
option, e.g.,

nm --extern-only --defined-only <library_name> |grep Pltcl_Init

and if Pltcl_Init is externally visible you should get the
same result whether --extern-only is used or not.  And that proved
to be the case here when I compiled with

CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
CFLAGS=-O3 -fvisibility=hidden -Wuninitialized

which should make gcc act very similarly on Linux to the way it handles
visibility issues for C or C++ library on Windows.

So from my good visibility results here, I am pretty sure visibility
should not be an issue for you there, but please get back to me with
the Pltcl_Init definition and visibility results via the "nm" command
for the plplot library for the nondynamic case to confirm that (or
not), and we can take it from there.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] A patch series to fix an off by 1 error when calling check_buffer_size()

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

I will read up and push the patch



> On Jun 17, 2015, at 1:12 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-06-17 10:56-0400 Jim Dishaw wrote:
>> 
>> Greg Jung pointed out that the call to check_buffer_size() could be
> 1 byte smaller than required.  It most cases this will not be a
> problem due to the way memory is allocated, but it is possible that an
> edge case could result in a memory access error.
> 
> Hi Jim:
> 
> This small off-by-one bug fix appears the perfect opportunity for you
> to learn how (as a new core PLplot developer) to push bug fixes to our
> SF server.  So please do that following our rebase workflow rules in
> README.developers. Of course, if you run into any trouble with
> our workflow rules, we are here to help.
> 
> I can see why you would be a bit more cautious about your more
> intrusive bug-fix patch series concerning the eop problems, but in
> that case as soon as I have completed the promised resize testing of
> the qt, etc., cases (probably later today) I will strongly encourage
> you to push that more intrusive bug fix as well.
> 
> Of course, you should hold off pushing any of your new work (such as
> your new GDI device driver) until the start of the next release cycle,
> but bug fix pushes from all our core developers including you are very
> welcome right now since there is still sufficient time to test those
> bug fixes before our forthcoming release.
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
> 
> Linux-powered Science
> __________________________

Re: [Plplot-devel] A patch series to fix an off by 1 error when calling check_buffer_size()

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

On 2015-06-17 10:56-0400 Jim Dishaw wrote:

> Greg Jung pointed out that the call to check_buffer_size() could be
1 byte smaller than required.  It most cases this will not be a
problem due to the way memory is allocated, but it is possible that an
edge case could result in a memory access error.

Hi Jim:

This small off-by-one bug fix appears the perfect opportunity for you
to learn how (as a new core PLplot developer) to push bug fixes to our
SF server.  So please do that following our rebase workflow rules in
README.developers. Of course, if you run into any trouble with
our workflow rules, we are here to help.

I can see why you would be a bit more cautious about your more
intrusive bug-fix patch series concerning the eop problems, but in
that case as soon as I have completed the promised resize testing of
the qt, etc., cases (probably later today) I will strongly encourage
you to push that more intrusive bug fix as well.

Of course, you should hold off pushing any of your new work (such as
your new GDI device driver) until the start of the next release cycle,
but bug fix pushes from all our core developers including you are very
welcome right now since there is still sufficient time to test those
bug fixes before our forthcoming release.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

[Plplot-devel] A patch series to fix an off by 1 error when calling check_buffer_size()

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

Greg Jung pointed out that the call to check_buffer_size() could be 1 byte smaller than required.  It most cases this will not be a problem due to the way memory is allocated, but it is possible that an edge case could result in a memory access error.

I will need to check the PLESC_IMPORT_BUFFER/PLESC_APPEND_BUFFER calls to make sure they are maintaining alignment.  That is not a bug, just a performance issue that can wait until after the release.

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

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

Hi Alan,



Hm, something is failing in the non_dynamic tests:

CMakeFiles/pltcl.dir/pltcl.c.o:pltcl.c:(.text+0x20e): undefined reference to `__imp_Pltcl_Init'

CMakeFiles/pltcl.dir/pltcl.c.o:pltcl.c:(.text+0x20e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp_Pltcl_Init'

So your latest changes regarding the reduction of the llibraries for the non-dynamic drivers seem to have introduced a bug. I have attached the complete tarball.

Regards,

Arjen


From: Arjen Markus [mailto:Arj...@de...]
Sent: Wednesday, June 17, 2015 9:48 AM
To: Alan W. Irwin
Cc: plp...@li...
Subject: Re: [Plplot-devel] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and Ada


Hi Alan,



Yes, updating that list is on my TODO list. I have been rather preoccupied with other things, so have not had the opportunity to sit down for it. I should be able to redo the tests with the latest changes today, though.



Regards,



Arjen


> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 17, 2015 9:27 AM
> To: Arjen Markus
> Cc: Phil Rosenberg; plp...@li...
> Subject: Re: Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and Ada
>
> Hi Arjen:
>
> On 2015-06-09 09:24-0700 Alan W. Irwin wrote:
>
> > 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 haven't heard from you on this question yet, but I do hope you are willing to do this
> since it is really important information.
>
>
> > 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.
>
> I have just (commit id f4db3e8) completed my long-promised large set of build
> system changes for Tcl/Tk/Itcl/Itk that I would appreciate you testing as above on
> Cygwin when you get the chance.
>
> > 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.
>
> I am going to put off Ada language support changes for at least a little while and
> maybe indefinitely because there is so much other PLplot build-system changes I
> would like to complete for this release cycle.
>
> 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.
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] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and Ada

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

Hi Alan,



Yes, updating that list is on my TODO list. I have been rather preoccupied with other things, so have not had the opportunity to sit down for it. I should be able to redo the tests with the latest changes today, though.



Regards,



Arjen



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, June 17, 2015 9:27 AM
> To: Arjen Markus
> Cc: Phil Rosenberg; plp...@li...
> Subject: Re: Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and Ada
>
> Hi Arjen:
>
> On 2015-06-09 09:24-0700 Alan W. Irwin wrote:
>
> > 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 haven't heard from you on this question yet, but I do hope you are willing to do this
> since it is really important information.
>
>
> > 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.
>
> I have just (commit id f4db3e8) completed my long-promised large set of build
> system changes for Tcl/Tk/Itcl/Itk that I would appreciate you testing as above on
> Cygwin when you get the chance.
>
> > 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.
>
> I am going to put off Ada language support changes for at least a little while and
> maybe indefinitely because there is so much other PLplot build-system changes I
> would like to complete for this release cycle.
>
> 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] Comprehensive testing on Cygwin with Tcl/Tk/Itcl/Itk and Ada

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

Hi Arjen:

On 2015-06-09 09:24-0700 Alan W. Irwin wrote:

> 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 haven't heard from you on this question yet, but I do hope you
are willing to do this since it is really important information.


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

I have just (commit id f4db3e8) completed my long-promised large set
of build system changes for Tcl/Tk/Itcl/Itk that I would appreciate
you testing as above on Cygwin when you get the chance.

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

I am going to put off Ada language support changes for at least a
little while and maybe indefinitely because there is so much other
PLplot build-system changes I would like to complete for this release
cycle.

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

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

> On Jun 16, 2015, at 5:27 PM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> Okay, so it sounds like there is basically no change for drivers that are waiting to be updated.
> If you need me to have a look at the patches I will try to do so tomorrow.

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

Extra eyes on the patches is appreciated.  Thanks.

> 
> Phil
> From: Jim Dishaw <mailto:ji...@di...>
> Sent: ‎16/‎06/‎2015 16:11
> To: Phil Rosenberg <mailto:p.d...@gm...>
> Cc: Alan W. Irwin <mailto:ir...@be...>; PLplot development list <mailto:Plp...@li...>; Andrew Ross <mailto:and...@us...>
> Subject: Re: [Plplot-devel] Bug fix to plbuf.c
> 
> 
> > On Jun 16, 2015, at 4:58 AM, Phil Rosenberg <p.d...@gm...> wrote:
> > 
> > So how should we go about applying all this? Will we break some
> > drivers when it is applied? If so do we need to have all drivers
> > prepared so that we can apply all the fixes together?
> > 
> 
> All function pointer are set to NULL during the dispatch table initialization, thus the wait pointer remains NULL if a device does not set it.  The plP_wait() function checks nopause and for a non-NULL wait function pointer before calling the wait function pointer.  Thus no action is taken if a driver does not support the wait function.
> 
> For non-interactive drivers, no further action is required because they don’t wait for input.
> 
> For interactive drivers, the key factor is if the driver uses plRemakePlot().  If it does, it will need to provide a wait function otherwise multiple keypresses will be required after a resize.  If it does not use plRemakePlot(), the change is not critical because having a wait for input in the driver’s EOP handler will not break anything.  The driver should be updated to keep the internal API consistent.  For example, the tek driver is in an unsupported state and there is no need to update it.  The Qt driver, on the other hand, should be updated to stay consistent with the internal API even though it does not use plRemakePlot().  If during testing we discover Qt behaves badly with this change, we can leave the changes out until a later release.
> 
> > Phil
> > 
> > On 16 June 2015 at 02:55, Jim Dishaw <ji...@di...> wrote:
> >> And here is the wingcc patch series.  I tested with cygwin and msvc and did
> >> not have the problem with multiple keypresses.  The wingcc driver does seem
> >> to have a problem when the window is made small.  It cuts off part of the
> >> plot.
> >> 
> >> 
> >> 
> >> 
> >> On Jun 15, 2015, at 12:24 PM, Jim Dishaw <ji...@di...> wrote:
> >> 
> >> 
> >> On Jun 14, 2015, at 1:40 PM, Jim Dishaw <ji...@di...> wrote:
> >> 
> >> 
> >> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@be...>
> >> wrote:
> >> 
> >> On 2015-06-13 22:29-0400 Jim Dishaw wrote:
> >> 
> >> 
> >> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
> >> 
> >> 
> >> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm...
> >> <mailto:p.d...@gm...>> wrote:
> >> 
> >> Hmmm
> >> Then hmmmm some more
> >> Followed by an ummm or two.
> >> 
> >> As you say Jim, clearly things are more complicated than I realised. I'm not
> >> sure what the requirements really are here now. Now you have brought this up
> >> I can imagine the issues associated with entering the message loop after an
> >> eop.
> >> 
> >> In terms of dealing with it, I'm not at my computer right now, but I think
> >> probably a bop_forced function which forces a bop irrespective of where we
> >> are in the page cycle would work. But I'm not sure if that might have some
> >> potential subtle effects elsewhere so it is a bit of a hack really. Perhaps
> >> instead it would be better to assess what is being done in a bop and ensure
> >> those actions end up in the buffer so a bop event is not required.
> >> 
> >> 
> >> I think that is a good approach for reasons beyond this issue, but a BOP and
> >> EOP of some type is still required to support the drivers adequately (e.g
> >> double buffering, printing from the windows API).
> >> 
> >> The solution I'm going to test is one where the driver does not enter into a
> >> wait for input state on a redraw event from the callback.
> >> 
> >> 
> >> I came up with two solutions, one of which I tested.
> >> 
> >> Solution 1 (Tested)
> >> 
> >> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
> >> now an EOP is written to the buffer.  This will cause an EOP to be generated
> >> when the plot buffer is replayed.  I like the symmetry of having an EOP in
> >> the buffer to match the BOP.
> >> 
> >> Drivers will be responsible for determining if a “wait for user input”
> >> should be performed during an EOP.  For the wingdi driver I track the state
> >> of a “page_state” that changes outside of the BOP/EOP calls.
> >> 
> >> This solution feels a bit kludgy, but it works.
> >> 
> >> Solution 2
> >> 
> >> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
> >> now an EOP is written to the buffer.  This will cause an EOP to be generated
> >> when the plot buffer is replayed.
> >> 
> >> Add a new driver function to the dispatch table (e.g. pl_wait) that calls
> >> the "wait for user input between pages" function.
> >> 
> >> Remove from all drivers the “wait for input” from the EOP handler.
> >> 
> >> The PLplot core library will call the wait for input between pages function
> >> (if not null).
> >> 
> >> This solution strikes me as a more elegant solution because the logic for
> >> deciding about the wait for input is one spot.
> >> 
> >> 
> >> Regardless of the solution, some changes to the drivers will be
> >> 
> >> required.  Solution 2 will touch all the drivers (at a minimum to add
> >> a NULL to the dispatch table).  Solution 1 adds code to the drivers
> >> while solution 2 removes some code from the drivers.
> >> 
> >> Hi Jim:
> >> 
> >> Thanks for your effort working through possible solutions to the
> >> problem.
> >> 
> >> @Phil and Andrew:
> >> 
> >> Assuming you guys agree with Jim's analysis, do you prefer solution 1
> >> or 2?  Elegant and "removes some code from the drivers" (i.e.,
> >> solution 2) seems like the better choice to me from an overview
> >> perspective, but I would be happy to go along with whatever you all
> >> decide since I do not have the driver expertise you guys have.
> >> 
> >> Assuming whatever solution is decided upon here can be implemented
> >> in a reasonably timely way, then I think we should be able to fit
> >> it into the forthcoming bug-fix release since this is obviously a
> >> bug fix, albeit a rather intrusive one.
> >> 
> >> With regard to timing for that release there is still quite a bit I
> >> plan to do to work through the bugs in the build system revealed by
> >> previous tests on Linux and Arjen's current tests on the Cygwin
> >> platform. And the new tarball report that is automatically collected
> >> by scripts/comprehensive_test.sh should make reporting of tests and
> >> figuring out build-system issues from those reports _much_ easier.
> >> Which likely means this release will be tested on a lot more platforms
> >> than the last one and a significant amount of time will be required to
> >> deal with any build system bugs that are turned up by such tests. So
> >> my current guestimate is the forthcoming release is likely more than a
> >> month away (although hopefully not longer than two months away).
> >> 
> >> 
> >> Attached is a patch series that implements the second solution.  I tested
> >> the changes to xwin driver; however, I was not able to test tkwin, qt, or
> >> cairo.  I will provide an update to wingcc separately.  I didn’t touch the
> >> wxwidgets driver.
> >> 
> >> I didn’t have to touch the drivers that do not need the wait function
> >> pointer (e.g. postscript).  The way the driver dispatch table is
> >> initialized, I was able to set all the function pointers to NULL in the
> >> plcore.c file.  The drivers set each member individually, thus the wait
> >> function pointer is left NULL.
> >> 
> >> The xwin driver occasionally misses some resizes, but I think that is some
> >> quirky behavior that existed prior to 5.10.
> >> 
> >> If someone could test the tkwin, qt, and cairo (specifically xcairo) that
> >> would be greatly appreciated.
> >> 
> >> 
> >> <0001-Fix-to-the-multiple-keypress-bug-on-page-advance.patch>
> >> 
> >> 
> >> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Plplot-devel mailing list
> >> Plp...@li...
> >> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >> 
> >> 
> >> 
> >> ------------------------------------------------------------------------------
> >> 
> >> _______________________________________________
> >> Plplot-devel mailing list
> >> Plp...@li...
> >> https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >> 
> 

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

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

Okay, so it sounds like there is basically no change for drivers that are waiting to be updated.
If you need me to have a look at the patches I will try to do so tomorrow.

Phil

-----Original Message-----
From: "Jim Dishaw" <ji...@di...>
Sent: ‎16/‎06/‎2015 16:11
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "Alan W. Irwin" <ir...@be...>; "PLplot development list" <Plp...@li...>; "Andrew Ross" <and...@us...>
Subject: Re: [Plplot-devel] Bug fix to plbuf.c


> On Jun 16, 2015, at 4:58 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> So how should we go about applying all this? Will we break some
> drivers when it is applied? If so do we need to have all drivers
> prepared so that we can apply all the fixes together?
> 

All function pointer are set to NULL during the dispatch table initialization, thus the wait pointer remains NULL if a device does not set it.  The plP_wait() function checks nopause and for a non-NULL wait function pointer before calling the wait function pointer.  Thus no action is taken if a driver does not support the wait function.

For non-interactive drivers, no further action is required because they don’t wait for input.

For interactive drivers, the key factor is if the driver uses plRemakePlot().  If it does, it will need to provide a wait function otherwise multiple keypresses will be required after a resize.  If it does not use plRemakePlot(), the change is not critical because having a wait for input in the driver’s EOP handler will not break anything.  The driver should be updated to keep the internal API consistent.  For example, the tek driver is in an unsupported state and there is no need to update it.  The Qt driver, on the other hand, should be updated to stay consistent with the internal API even though it does not use plRemakePlot().  If during testing we discover Qt behaves badly with this change, we can leave the changes out until a later release.

> Phil
> 
> On 16 June 2015 at 02:55, Jim Dishaw <ji...@di...> wrote:
>> And here is the wingcc patch series.  I tested with cygwin and msvc and did
>> not have the problem with multiple keypresses.  The wingcc driver does seem
>> to have a problem when the window is made small.  It cuts off part of the
>> plot.
>> 
>> 
>> 
>> 
>> On Jun 15, 2015, at 12:24 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>> On Jun 14, 2015, at 1:40 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@be...>
>> wrote:
>> 
>> On 2015-06-13 22:29-0400 Jim Dishaw wrote:
>> 
>> 
>> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm...
>> <mailto:p.d...@gm...>> wrote:
>> 
>> Hmmm
>> Then hmmmm some more
>> Followed by an ummm or two.
>> 
>> As you say Jim, clearly things are more complicated than I realised. I'm not
>> sure what the requirements really are here now. Now you have brought this up
>> I can imagine the issues associated with entering the message loop after an
>> eop.
>> 
>> In terms of dealing with it, I'm not at my computer right now, but I think
>> probably a bop_forced function which forces a bop irrespective of where we
>> are in the page cycle would work. But I'm not sure if that might have some
>> potential subtle effects elsewhere so it is a bit of a hack really. Perhaps
>> instead it would be better to assess what is being done in a bop and ensure
>> those actions end up in the buffer so a bop event is not required.
>> 
>> 
>> I think that is a good approach for reasons beyond this issue, but a BOP and
>> EOP of some type is still required to support the drivers adequately (e.g
>> double buffering, printing from the windows API).
>> 
>> The solution I'm going to test is one where the driver does not enter into a
>> wait for input state on a redraw event from the callback.
>> 
>> 
>> I came up with two solutions, one of which I tested.
>> 
>> Solution 1 (Tested)
>> 
>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
>> now an EOP is written to the buffer.  This will cause an EOP to be generated
>> when the plot buffer is replayed.  I like the symmetry of having an EOP in
>> the buffer to match the BOP.
>> 
>> Drivers will be responsible for determining if a “wait for user input”
>> should be performed during an EOP.  For the wingdi driver I track the state
>> of a “page_state” that changes outside of the BOP/EOP calls.
>> 
>> This solution feels a bit kludgy, but it works.
>> 
>> Solution 2
>> 
>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
>> now an EOP is written to the buffer.  This will cause an EOP to be generated
>> when the plot buffer is replayed.
>> 
>> Add a new driver function to the dispatch table (e.g. pl_wait) that calls
>> the "wait for user input between pages" function.
>> 
>> Remove from all drivers the “wait for input” from the EOP handler.
>> 
>> The PLplot core library will call the wait for input between pages function
>> (if not null).
>> 
>> This solution strikes me as a more elegant solution because the logic for
>> deciding about the wait for input is one spot.
>> 
>> 
>> Regardless of the solution, some changes to the drivers will be
>> 
>> required.  Solution 2 will touch all the drivers (at a minimum to add
>> a NULL to the dispatch table).  Solution 1 adds code to the drivers
>> while solution 2 removes some code from the drivers.
>> 
>> Hi Jim:
>> 
>> Thanks for your effort working through possible solutions to the
>> problem.
>> 
>> @Phil and Andrew:
>> 
>> Assuming you guys agree with Jim's analysis, do you prefer solution 1
>> or 2?  Elegant and "removes some code from the drivers" (i.e.,
>> solution 2) seems like the better choice to me from an overview
>> perspective, but I would be happy to go along with whatever you all
>> decide since I do not have the driver expertise you guys have.
>> 
>> Assuming whatever solution is decided upon here can be implemented
>> in a reasonably timely way, then I think we should be able to fit
>> it into the forthcoming bug-fix release since this is obviously a
>> bug fix, albeit a rather intrusive one.
>> 
>> With regard to timing for that release there is still quite a bit I
>> plan to do to work through the bugs in the build system revealed by
>> previous tests on Linux and Arjen's current tests on the Cygwin
>> platform. And the new tarball report that is automatically collected
>> by scripts/comprehensive_test.sh should make reporting of tests and
>> figuring out build-system issues from those reports _much_ easier.
>> Which likely means this release will be tested on a lot more platforms
>> than the last one and a significant amount of time will be required to
>> deal with any build system bugs that are turned up by such tests. So
>> my current guestimate is the forthcoming release is likely more than a
>> month away (although hopefully not longer than two months away).
>> 
>> 
>> Attached is a patch series that implements the second solution.  I tested
>> the changes to xwin driver; however, I was not able to test tkwin, qt, or
>> cairo.  I will provide an update to wingcc separately.  I didn’t touch the
>> wxwidgets driver.
>> 
>> I didn’t have to touch the drivers that do not need the wait function
>> pointer (e.g. postscript).  The way the driver dispatch table is
>> initialized, I was able to set all the function pointers to NULL in the
>> plcore.c file.  The drivers set each member individually, thus the wait
>> function pointer is left NULL.
>> 
>> The xwin driver occasionally misses some resizes, but I think that is some
>> quirky behavior that existed prior to 5.10.
>> 
>> If someone could test the tkwin, qt, and cairo (specifically xcairo) that
>> would be greatly appreciated.
>> 
>> 
>> <0001-Fix-to-the-multiple-keypress-bug-on-page-advance.patch>
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 

Re: [Plplot-devel] Tcl build error

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

On 2015-06-16 12:01+0100 Phil Rosenberg wrote:

> Hi Alan
> Unfortunately I now get a different error when I do my install build
>
> CMake Error at bindings/cmake_install.cmake:39 (file):
>
> 13> file INSTALL cannot find "D:/usr/local/src/plplot-plplot/build/Visual
>
> 13> Studio 11 64s/bindings/pkgIndex.tcl".
>
> I presume that the splitting onto two lines of the path is just to do
> with the length of the terminal screen in visual studio, but I can
> confirm that the file it is looking for does not exist.

Hi Phil:

I forgot to also quote the pathname of the resulting concatenated file.
So please try commit 73fd9a4 to see if that now fixes the issue.

Alan

__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

> On Jun 16, 2015, at 4:58 AM, Phil Rosenberg <p.d...@gm...> wrote:
> 
> So how should we go about applying all this? Will we break some
> drivers when it is applied? If so do we need to have all drivers
> prepared so that we can apply all the fixes together?
> 

All function pointer are set to NULL during the dispatch table initialization, thus the wait pointer remains NULL if a device does not set it.  The plP_wait() function checks nopause and for a non-NULL wait function pointer before calling the wait function pointer.  Thus no action is taken if a driver does not support the wait function.

For non-interactive drivers, no further action is required because they don’t wait for input.

For interactive drivers, the key factor is if the driver uses plRemakePlot().  If it does, it will need to provide a wait function otherwise multiple keypresses will be required after a resize.  If it does not use plRemakePlot(), the change is not critical because having a wait for input in the driver’s EOP handler will not break anything.  The driver should be updated to keep the internal API consistent.  For example, the tek driver is in an unsupported state and there is no need to update it.  The Qt driver, on the other hand, should be updated to stay consistent with the internal API even though it does not use plRemakePlot().  If during testing we discover Qt behaves badly with this change, we can leave the changes out until a later release.

> Phil
> 
> On 16 June 2015 at 02:55, Jim Dishaw <ji...@di...> wrote:
>> And here is the wingcc patch series.  I tested with cygwin and msvc and did
>> not have the problem with multiple keypresses.  The wingcc driver does seem
>> to have a problem when the window is made small.  It cuts off part of the
>> plot.
>> 
>> 
>> 
>> 
>> On Jun 15, 2015, at 12:24 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>> On Jun 14, 2015, at 1:40 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>> On Jun 14, 2015, at 5:19 AM, Alan W. Irwin <ir...@be...>
>> wrote:
>> 
>> On 2015-06-13 22:29-0400 Jim Dishaw wrote:
>> 
>> 
>> On Jun 13, 2015, at 2:11 PM, Jim Dishaw <ji...@di...> wrote:
>> 
>> 
>> On Jun 13, 2015, at 1:13 PM, Phil Rosenberg <p.d...@gm...
>> <mailto:p.d...@gm...>> wrote:
>> 
>> Hmmm
>> Then hmmmm some more
>> Followed by an ummm or two.
>> 
>> As you say Jim, clearly things are more complicated than I realised. I'm not
>> sure what the requirements really are here now. Now you have brought this up
>> I can imagine the issues associated with entering the message loop after an
>> eop.
>> 
>> In terms of dealing with it, I'm not at my computer right now, but I think
>> probably a bop_forced function which forces a bop irrespective of where we
>> are in the page cycle would work. But I'm not sure if that might have some
>> potential subtle effects elsewhere so it is a bit of a hack really. Perhaps
>> instead it would be better to assess what is being done in a bop and ensure
>> those actions end up in the buffer so a bop event is not required.
>> 
>> 
>> I think that is a good approach for reasons beyond this issue, but a BOP and
>> EOP of some type is still required to support the drivers adequately (e.g
>> double buffering, printing from the windows API).
>> 
>> The solution I'm going to test is one where the driver does not enter into a
>> wait for input state on a redraw event from the callback.
>> 
>> 
>> I came up with two solutions, one of which I tested.
>> 
>> Solution 1 (Tested)
>> 
>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
>> now an EOP is written to the buffer.  This will cause an EOP to be generated
>> when the plot buffer is replayed.  I like the symmetry of having an EOP in
>> the buffer to match the BOP.
>> 
>> Drivers will be responsible for determining if a “wait for user input”
>> should be performed during an EOP.  For the wingdi driver I track the state
>> of a “page_state” that changes outside of the BOP/EOP calls.
>> 
>> This solution feels a bit kludgy, but it works.
>> 
>> Solution 2
>> 
>> Remove the plP_eop() call in plRemakePlot().  Add an EOP to plbuf_eop() so
>> now an EOP is written to the buffer.  This will cause an EOP to be generated
>> when the plot buffer is replayed.
>> 
>> Add a new driver function to the dispatch table (e.g. pl_wait) that calls
>> the "wait for user input between pages" function.
>> 
>> Remove from all drivers the “wait for input” from the EOP handler.
>> 
>> The PLplot core library will call the wait for input between pages function
>> (if not null).
>> 
>> This solution strikes me as a more elegant solution because the logic for
>> deciding about the wait for input is one spot.
>> 
>> 
>> Regardless of the solution, some changes to the drivers will be
>> 
>> required.  Solution 2 will touch all the drivers (at a minimum to add
>> a NULL to the dispatch table).  Solution 1 adds code to the drivers
>> while solution 2 removes some code from the drivers.
>> 
>> Hi Jim:
>> 
>> Thanks for your effort working through possible solutions to the
>> problem.
>> 
>> @Phil and Andrew:
>> 
>> Assuming you guys agree with Jim's analysis, do you prefer solution 1
>> or 2?  Elegant and "removes some code from the drivers" (i.e.,
>> solution 2) seems like the better choice to me from an overview
>> perspective, but I would be happy to go along with whatever you all
>> decide since I do not have the driver expertise you guys have.
>> 
>> Assuming whatever solution is decided upon here can be implemented
>> in a reasonably timely way, then I think we should be able to fit
>> it into the forthcoming bug-fix release since this is obviously a
>> bug fix, albeit a rather intrusive one.
>> 
>> With regard to timing for that release there is still quite a bit I
>> plan to do to work through the bugs in the build system revealed by
>> previous tests on Linux and Arjen's current tests on the Cygwin
>> platform. And the new tarball report that is automatically collected
>> by scripts/comprehensive_test.sh should make reporting of tests and
>> figuring out build-system issues from those reports _much_ easier.
>> Which likely means this release will be tested on a lot more platforms
>> than the last one and a significant amount of time will be required to
>> deal with any build system bugs that are turned up by such tests. So
>> my current guestimate is the forthcoming release is likely more than a
>> month away (although hopefully not longer than two months away).
>> 
>> 
>> Attached is a patch series that implements the second solution.  I tested
>> the changes to xwin driver; however, I was not able to test tkwin, qt, or
>> cairo.  I will provide an update to wingcc separately.  I didn’t touch the
>> wxwidgets driver.
>> 
>> I didn’t have to touch the drivers that do not need the wait function
>> pointer (e.g. postscript).  The way the driver dispatch table is
>> initialized, I was able to set all the function pointers to NULL in the
>> plcore.c file.  The drivers set each member individually, thus the wait
>> function pointer is left NULL.
>> 
>> The xwin driver occasionally misses some resizes, but I think that is some
>> quirky behavior that existed prior to 5.10.
>> 
>> If someone could test the tkwin, qt, and cairo (specifically xcairo) that
>> would be greatly appreciated.
>> 
>> 
>> <0001-Fix-to-the-multiple-keypress-bug-on-page-advance.patch>
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Plplot-devel mailing list
>> Plp...@li...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>> 

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

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

Okay, no worries

On 16 June 2015 at 11:53, Alan W. Irwin <ir...@be...> wrote:
> On 2015-06-16 10:30+0100 Phil Rosenberg wrote:
>
>> I have just looked and it seems that notcrossed is only used for
>> point-in-polygon checks. Therefore based on the arguments in my
>> previous email I would suggest that the following patch should give
>> the desired results. If anyone has any particular objections to this
>> please let me know, otherwise I will commit this.
>
>
> Hi Phil:
>
> Please hold off until I have time to consider this.  It has been quite
> a while so I don't remember details, but I had what I felt were good
> reasons for using the fuzzy logic way back when so let me try to
> resurrect those reasons from discussion on the plplot-devel list at
> the time and from my commit messages in that era, and then look
> carefully at your arguments in light of those reasons. But it is going
> to take a while before I can do that because there is a lot of other
> PLplot stuff I am involved with at the moment.
>
>
> 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] Tcl build error

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

 Hi Alan
Unfortunately I now get a different error when I do my install build

CMake Error at bindings/cmake_install.cmake:39 (file):

13> file INSTALL cannot find "D:/usr/local/src/plplot-plplot/build/Visual

13> Studio 11 64s/bindings/pkgIndex.tcl".

I presume that the splitting onto two lines of the path is just to do
with the length of the terminal screen in visual studio, but I can
confirm that the file it is looking for does not exist.

Phil

On 15 June 2015 at 17:45, Alan W. Irwin <ir...@be...> wrote:
> On 2015-06-15 15:34+0100 Phil Rosenberg wrote:
>
>> So I can see where the lines appear to be written from the
>> CMakeLists.txt, but I don't know how to split that block to output the
>> individual ${index} list items. I might have to rely on you to have a
>> look.
>
>
> Hi Phil:
>
> I have taken a look at this, and I believe commit id 32c5cf8 will fix
> the "spaced" build-tree pathname issue you discovered, but I have only
> superficially tested this fix so please let me know if it solves the
> issue.
>
>
> Alan
>
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

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

On 2015-06-16 10:30+0100 Phil Rosenberg wrote:

> I have just looked and it seems that notcrossed is only used for
> point-in-polygon checks. Therefore based on the arguments in my
> previous email I would suggest that the following patch should give
> the desired results. If anyone has any particular objections to this
> please let me know, otherwise I will commit this.

Hi Phil:

Please hold off until I have time to consider this.  It has been quite
a while so I don't remember details, but I had what I felt were good
reasons for using the fuzzy logic way back when so let me try to
resurrect those reasons from discussion on the plplot-devel list at
the time and from my commit messages in that era, and then look
carefully at your arguments in light of those reasons. But it is going
to take a while before I can do that because there is a lot of other
PLplot stuff I am involved with at the moment.

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

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

On 2015-06-15 12:24-0400 Jim Dishaw wrote:

> [...] Attached is a patch series that implements the second
[elegant] solution.  I tested the changes to xwin driver; however, I
was not able to test tkwin, qt, or cairo.  I will provide an update to
wingcc separately.  I didn’t touch the wxwidgets driver.

> I didn’t have to touch the drivers that do not need the wait
function pointer (e.g. postscript).  The way the driver dispatch table
is initialized, I was able to set all the function pointers to NULL in
the plcore.c file.  The drivers set each member individually, thus the
wait function pointer is left NULL.

> The xwin driver occasionally misses some resizes, but I think that is some quirky behavior that existed prior to 5.10.

> If someone could test the tkwin, qt, and cairo (specifically xcairo) that would be greatly appreciated.

Hi Jim:

Thanks for this effort and the later effort you posted for the wingcc
device driver.

@Jim and Phil:

I am in the middle of another PLplot issue at the moment, but I will test
Jim's fix for all of tkwin, qt, and cairo once I am done with that
issue.

I noticed above that Jim have no plans for the wxwidgets driver.  But
I assume we will need that device fixed and also the old wxwidgets
device you get when using -DOLD_WXWIDGETS=ON before we can push these
changes. So I hope if the bug fix is simple for both forms of wxwidgets
that Jim just goes ahead with it, but if it is more complex, I hope
both you guys are collaborating on making the fix.

Anyhow, once I see a patch series for the two forms of wxwidgets from
one or the other of you, I would be happy to test both those forms.

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] Bug in notcrossed() function of plfill.c

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

I have just looked and it seems that notcrossed is only used for
point-in-polygon checks. Therefore based on the arguments in my
previous email I would suggest that the following patch should give
the desired results. If anyone has any particular objections to this
please let me know, otherwise I will commit this.

Cheers

Phil

On 16 June 2015 at 09:55, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan, Maurice and Arjen
>
> Arjen - yes you are correct FLT_MIN was the incorrect number to use. I
> should have used  PLFLT_EPSILON*MAX(xA2A1 * yB2B1, yA2A1 * xB2B1 ) for
> my test. Here PLFLT_EPSILON is about 1e-16 for a double so we have
> something that is much more sensible as a test.
>
> Alan - yes you were correct I missed the second part of your email. If
> only you top posted ;-).
>
> So I think I understand the maths now. If each parameter has an
> uncertainty of +/- 2 pixels then when factor should be zero, its
> maximum value can be
> ( xA2A1 + 2 ) * ( yB2B1 +2 ) - ( yA2A1 + 2 )* ( xB2B1 + 2 )
> which when expanded out gives
> xA2A1 * yB2B1 - yA2A1 * xB2B1 + 2( xA2A1 + yB2B1 + yA2A1 + xB2B1 ).
> = factor + factor_NBCC
>
> So the uncertainty in factor is factor_NBCC so if abs(factor) is less
> than factor_NBCC then it is within the uncertainty of zero. This
> explains the dimension inconsistency - actually PL_NBCC has units of
> length so that makes it work.
>
> Is this all correct?
>
> So in this case with the numbers I give above the line does indeed
> fall within the uncertainty of zero.
>
> However I am going to state that for this problem the initial
> definition of uncertainty is incorrect. We are doing a point in
> polygon test so we actually don't care at all about the rounding
> precision of real numbers to integers. The actual points are exact -
> even to within epsilon because all the numbers are integers and a
> float can hold all integers exactly. Therefore it would actually be
> safe to just test against zero. Despite this it would be worth having
> an epsilon test.
>
> In case that isn't clear let me state it like this. The points are not
> scientifically exact in that when we go from the data we are plotting
> onto out contour plot, we have some rounding uncertainty due to our
> grid size. However, at the point of checking whether the corner of a
> plot is within one of our fill regions we are no longer interested in
> the original data. By this time we begin our fill function we have
> divided our plot into a perfectly tessellating pattern of polygons.
> And these really are perfectly tessellating. It is these polygons that
> we are interested in for our fill algorithm, not the original data.
> Therefore as far as the fill algorithm is concerned they are perfect
> with zero uncertainty.
>
> Therefore at the most for the fill function we might need an epsilon
> test but to assume 2 pixel uncertainty is actually wrong.
>
> Does that make sense?
>
> Phil
>
> On 16 June 2015 at 07:43, Arjen Markus <Arj...@de...> wrote:
>> Hi Phil, Alan, Maurice,
>>
>>
>>
>> I have had a look at the code (both Phil’s patch and the original). I am a
>> bit uncomfortable here:
>>
>> -        The original, using factor_NBCC cannot be correct, if only for
>> dimensional reasons. “factor” is clearly a signed surface area, so that its
>> dimension is L^2, whereas “factor_NBCC” has the dimension length (L).
>>
>> -        Phil’s patch uses FLT_MIN or DBL_MIN as a threshold for indicating
>> nearly parallel lines, but FTL_MIN is 1e-38 and DBL_MIN is even smaller.
>> Given that the incoming arguments are integer, these thresholds will simply
>> never be triggered.
>>
>>
>>
>> My understanding is that the code tries to determine whether the angle
>> between the two lines is very small by calculating the area spanned by the
>> vectors defining the direction of the lines (this is “factor”) and comparing
>> it to a small value. But that value should be related to the length of both
>> these vectors. I would say something like this ought to work:
>>
>> factor = … ; /* This is sin(angle) * length vector 1 * length vector 2 –
>> plane geometry */
>>
>> limit = 0.01 * length vector 1 * length vector 2; /* This means an angle of
>> 0.01 radians or 1 degree */
>>
>>
>>
>> if ( fabs(factor) < limit ) {
>>
>>    status = status | NEAR_PARALLEL;
>>
>> }
>>
>>
>>
>> Alas, no time right now to elaborate further.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Arjen
>>
>>> -----Original Message-----
>>> From: Alan W. Irwin [mailto:ir...@be...]
>>> Sent: Monday, June 15, 2015 11:59 PM
>>> To: Phil Rosenberg
>>> Cc: Arjen Markus; plp...@li...
>>
>>> Subject: RE: [Plplot-devel] Bug in notcrossed() function of plfill.c
>>>
>>> On 2015-06-15 21:07+0100 Phil Rosenberg wrote:
>>>
>>> > I will have to try out git blame then. I imagined that something so
>>> well embedded would predate our git usage, but I guess our svn history was
>>> brought
>>> in too.
>>>
>>> Yes, Hazen and I were careful to preserve our history back to the start in
>>> ~1992 which in retrospect was really a smart idea because of facilities
>>> like "git
>>> blame".
>>>
>>> > I guess you have as little idea as me then about how it is intended to
>>> > work?
>>>
>>> Hi Phil:
>>>
>>> Actually, if "it" refers to the notcrossed function, I do think I
>>> understand exactly what
>>> it is supposed to do, and I tried to explain it on my previous post which
>>> you quoted
>>> and which I quote again below.
>>>
>>> I suspect you may have just read my first comment below and then quit.
>>> :-)
>>>
>>> Alan
>>>
>>> >
>>> > -----Original Message-----
>>> > From: "Alan W. Irwin" <ir...@be...>
>>> > Sent: ‎15/‎06/‎2015 19:18
>>> > To: "Phil Rosenberg" <p.d...@gm...>
>>> > Cc: "Arjen Markus" <Arj...@de...>;
>>> > "plp...@li..."
>>> > <plp...@li...>
>>> > Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c
>>> >
>>> > Hi Phil:
>>> >
>>> > "git blame" is your friend for figuring out who authored what, and it
>>> > turns out I am virtually (except for a change by Hez) the sole author
>>> > of notcrossed, but IIRC, that built on top of what Arjen had done
>>> > before with (embedded logic rather than a function) which built on top
>>> > of what Maurice had done before....
>>> >
>>> >
>>> > On 2015-06-15 11:10+0100 Phil Rosenberg wrote:
>>> >
>>> >> Hi Arjen
>>> >>
>>> >> I've just copied the code below as I don't just have time at the
>>> >> moment to sort a git patch (The plot I was making is for a
>>> >> presentation this afternoon!).  The old code has been commented out
>>> >> with /* */ and my new code is directly above that from the #ifdef
>>> >> onwards.
>>> >>
>>> >> Basically I get that the variable factor will be zero for parallel
>>> >> lines and I get that there is a precision limit on that due to
>>> >> floating point rounding. However I don't understand how factor_NBCC
>>> >> works as a test.
>>> >>
>>> >> For the bug in question the inputs were xA1=20994, yA1=12219,
>>> >> xA2=4915, yA2=12561 xB1=20979, yB1=12219, xB2=20979, yB2=12221.
>>> >> Although perhaps the As and Bs were reversed, but the flagging should
>>> >> be identical.
>>> >
>>> > I (and presumably the rest here) were having a hard time figuring out
>>> > whether those two lines mathematically intersected or not. So I have
>>> > prepared a plot (see attached) that demonstrates that the two lines
>>> > _do_ mathematically intersect (where the red line is a clipped portion
>>> > of the A line segment and the yellow line is the B line segment in
>>> > totality.)
>>> >
>>> > Note however, that all the xA1, etc. values have a precision of +/- 2
>>> > because of rounding issues so the purpose of the PL_NBCC = 2 fuzz
>>> > factor is to make sure that the result are not subject to such
>>> > rounding issues, i.e., notcrossed only returns 0 status if the
>>> > crossing would occur regardless of shifts of +/- 2 in each of the xA,
>>> > yA, xB, and yB coordinates.  And of course, in this case when the
>>> > second line segment only has a length of 2, the crossing result is
>>> > never going to be definite so you will always get a non-zero return
>>> > code from notcrossed.
>>> >
>>> > If that explanation makes sense to you, but you still feel noncrossed
>>> > needs a fix, please send that in git format-patch form so I can
>>> > conveniently evaluate your proposed logic change.  But I suspect the
>>> > noncrossed logic is fine, and the fix for the issue you found needs to
>>> > be made in another part of our code to deal correctly with non-zero
>>> > return values from notcrossed.
>>> >
>>> > By the way, I hope your presentation went well despite the distraction
>>> > introduced by this PLplot bug you discovered at the last minute.
>>> >
>>> > 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
>>> > __________________________
>>>
>>> __________________________
>>> 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.