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 (resizing issues)

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

On 2015-07-04 14:57-0400 Jim Dishaw wrote:

> As for example 17, what should the behavior be on a resize event? 
Right now I play the back the entire buffer, which shows all the
rescalings. I think the correct behavior on a resize would be to
render the most recent frame.

Hi Jim:

I have (slightly) changed the subject line for this subtopic of your
post.

The answer to your question is you should model resizes for your new
device on what happens for -dev xwin.  In that case, a resize during
the course of example 17 resizes the current version of the plot
(which is what I assume you mean by "the most recent frame") and then
continues from there.

As I have mentioned before there is still a long-standing resize
scaling bug for -dev xwin where the scaling is appropriate to the size
of the last resize rather than the current resize.  So small resizes
look OK, but large ones do not. We can continue to live with this
long-standing bug if necessary in -dev xwin, but I hope your new
device does not have this issue so you will know the right fix for
-dev xwin and be able to get that fix into the forthcoming 5.11.1.

The other resizing issue I have remarked on before concerns the xcairo
device. The plD_eop_xcairo function currently reads as follows:


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 my concern is the last two statements in this function since they
make no difference, i.e., the return occurs regardless of whether
aStream->xdrawable_mode is true or not.

Note, that plD_bop_xcairo has a similar test of
aStream->xdrawable_mode, but in that case if aStream->xdrawable_mode
is true there is an immediate return and otherwise there is a call to
XFlush( aStream->XDisplay ) before the return.  I am pretty sure that
same logic should be used in the above case as well so I tried that
change in hopes that it would solve the current resizing issues with
xcairo, but it made no difference and resizing for xcairo continues to
leave the scale and origin of the rendered graphics completely
unaffected.  Nevertheless, I think this fix should be part of the
complete cure for this issue so I hope you will consider it when you
go ahead with your plan to fix this issue.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

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

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

The behavior with the -np flag is something I have grappled with while implementing the new windows driver. Example 17 is particularly challenging because of the way the stripchart function is implemented.

Splitting out the wait for user input from the EOP handler is part of the fix. If that function is not defined, that might be part of the problem. 

As for example 17, what should the behavior be on a resize event?  Right now I play the back the entire buffer, which shows all the rescalings. I think the correct behavior on a resize would be to render the most recent frame. 



> On Jul 4, 2015, at 1:51 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> Hi Phil:
> 
> Your recent efficiency improvements means it is now a lot more
> convenient to test the wxwidgets device.  So I have done that and
> noticed the following issues that appear to be caused by your
> efficiency improvements.
> 
> * The -np option no longer works properly.  For example, before these
> efficency improvements
> 
> examples/c/x08c -dev wxwidgets -np
> 
> would (extremely slowly) render each page of that example and then exit.
> 
> Now, the rendering for each page simply presents a a black screen
> before the exit occurs.  Sometimes, just as the example exits you will
> see a quick flash of the last page, but usually not.
> 
> In addition, the example now produces the following WARNING message
> for 5 of the pages
> 
> *** PLPLOT WARNING ***
> Failed to get text size from wxPLViewer - timeout
> 
> Without the -np option, none of these problems occur, and the
> time to render all the example 8 pages has a noticeable efficiency
> improvement consistent with the length of time the black screen
> is rendered when the -np option is used.
> 
> * examples/c/x17c -dev wxwidgets shows huge efficiency improvements,
> but it has changed from an interactive plot showing all the
> intermediate results to a black screen until the very end which then
> shows the final results. In other words, the interactive nature of
> this example has been lost.
> 
> * examples/c/x26c -dev wxwidgets shows something is wrong with the
> delivery of string-length calculations between -dev wxwidgets and
> wxPLViewer.  (For this case I am not sure whether this issue was
> introduced right when you implemented the new string-length
> calculation for wxwidgets or is the result of your recent efficiency
> changes.) The delivery of string-length information should be done
> independently for each page of this example (since the Russian text of
> the second page is longer than the English text of the first page).
> 
> What goes on here is that _for each page of the example_ the pllegend
> call internally calls plstrl which then requests the wxwidgets device
> to deliver plsc->string_length (used by pllegend to adjust legend-box
> size) before wxwidgets actually renders the string.  Of course, the
> complication is that -dev wxwidgets measures string lengths and
> renders those strings indirectly via wxPLViewer.  So obviously there
> has to be communications between -dev wxwidgets and wxPLViewer for
> every different page of example 26 to get that done properly.
> 
> Instead what happens now is that examples/c/x26c -dev wxwidgets 
> incorrectly finishes (i.e., you get a command-line prompt and/or time
> results if requested) as soon as the first page of that example has 
> been rendered by wxPLViewer. And when the second page is viewed by
> hitting the enter key for the wxPLViewer GUI, the legend box (which
> should be controlled by the string-length calculation for the Russian
> text of that page) appears to be the same size as the first page so
> that the longer Russian text for the second page overflows the legend
> box for that page.
> 
> 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
> __________________________
> 
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

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

Hi Phil:

Your recent efficiency improvements means it is now a lot more
convenient to test the wxwidgets device.  So I have done that and
noticed the following issues that appear to be caused by your
efficiency improvements.

* The -np option no longer works properly.  For example, before these
efficency improvements

examples/c/x08c -dev wxwidgets -np

would (extremely slowly) render each page of that example and then exit.

Now, the rendering for each page simply presents a a black screen
before the exit occurs.  Sometimes, just as the example exits you will
see a quick flash of the last page, but usually not.

In addition, the example now produces the following WARNING message
for 5 of the pages

*** PLPLOT WARNING ***
Failed to get text size from wxPLViewer - timeout

Without the -np option, none of these problems occur, and the
time to render all the example 8 pages has a noticeable efficiency
improvement consistent with the length of time the black screen
is rendered when the -np option is used.

* examples/c/x17c -dev wxwidgets shows huge efficiency improvements,
but it has changed from an interactive plot showing all the
intermediate results to a black screen until the very end which then
shows the final results. In other words, the interactive nature of
this example has been lost.

* examples/c/x26c -dev wxwidgets shows something is wrong with the
delivery of string-length calculations between -dev wxwidgets and
wxPLViewer.  (For this case I am not sure whether this issue was
introduced right when you implemented the new string-length
calculation for wxwidgets or is the result of your recent efficiency
changes.) The delivery of string-length information should be done
independently for each page of this example (since the Russian text of
the second page is longer than the English text of the first page).

What goes on here is that _for each page of the example_ the pllegend
call internally calls plstrl which then requests the wxwidgets device
to deliver plsc->string_length (used by pllegend to adjust legend-box
size) before wxwidgets actually renders the string.  Of course, the
complication is that -dev wxwidgets measures string lengths and
renders those strings indirectly via wxPLViewer.  So obviously there
has to be communications between -dev wxwidgets and wxPLViewer for
every different page of example 26 to get that done properly.

Instead what happens now is that examples/c/x26c -dev wxwidgets 
incorrectly finishes (i.e., you get a command-line prompt and/or time
results if requested) as soon as the first page of that example has 
been rendered by wxPLViewer. And when the second page is viewed by
hitting the enter key for the wxPLViewer GUI, the legend box (which
should be controlled by the string-length calculation for the Russian
text of that page) appears to be the same size as the first page so
that the longer Russian text for the second page overflows the legend
box for that page.

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] patch 31 which contains wincairo fixes

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

Hi Hazen:

A PLplot user has created a patch containing wincairo fixes (see
<http://sourceforge.net/p/plplot/patches/31/>).  As the originator of
the wincairo device could you please evaluate this 3-line change to
see whether we should apply it now to master so it will be included in
the planned 5.11.1 bugfix release?

Thanks in advance.

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

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

To Phil and Andrew:

@Andrew: I am addressing you directly (in addition to Phil) because I
have questions for you below concerning whether you can replicate my
weird timing results for wxwidgets and also concerning the issue of
shared memory leaks on Linux.

On 2015-07-03 13:53+0100 Phil Rosenberg wrote:

> Hi Alan
> So I think you should now find the wxPLViewer speed has significantly
> improved. The item I have dealt with now was that there is a timer at
> the OS level (initiated by wxWidgets) which sends a message to the
> viewer which initiates checking for new commands from the console app.
> At this point I used to check for a single message and return after
> dealing with it. However it seems that for whatever reason (different
> OS, different wxWidgets version?) on some systems the minimum time
> between the timer calls was quite long. This meant that when we were
> dealing with text which required a lot of small transmissions to the
> viewer there was a huge overhead. I have now modified things so that
> on every timer event I check for new transmissions at least 100 times
> with a 1 millisecond sleep between each. This means that for many
> small transmissions in a short time we remove most of the overhead.
>
> On my CentOS machine the execution time reported by time x08c -dev
> wxWidgets -np has dropped from 40s to about 2 s. Note that this only
> times the console part, not the viewer, but still we have clearly
> moved to something I would call acceptable.
>
> Note that there will always be a significant overhead for the
> transmission so this will never compete with Cairo, but this is
> unavoidable because wxWidgets cannot be run in a library without
> running it as a separate thread and PlPlot isn't thread safe. Note
> also that when using the wxWidgets driver via the wxWidgets binding
> (I.e. from within a wxWidgets app) this all becomes irrelevant as the
> viewer is not used.
>
> Anyway I hope this fix closes the issue and you are happy Alan.

@Phil:

The timing results for current master tip (commit id 5e74b6a6,
"Modification to previous wxPLViewer optimisation") are much improved
on first execution of examples.  So big congratulations on that result!

However, an important issue still remains as shown by the following
repeated timing results for both xcairo (as a typical benchmark) and
wxwidgets:

software@raven> time examples/c/x00c -dev xcairo -np

real    0m0.168s
user    0m0.008s
sys     0m0.016s
software@raven> time examples/c/x00c -dev xcairo -np

real    0m0.129s
user    0m0.020s
sys     0m0.004s
software@raven> time examples/c/x00c -dev xcairo -np

real    0m0.114s
user    0m0.020s
sys     0m0.008s

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

real    0m0.365s
user    0m0.008s
sys     0m0.012s
software@raven> time examples/c/x00c -dev wxwidgets -np

real    0m1.231s
user    0m0.008s
sys     0m0.012s
software@raven> time examples/c/x00c -dev wxwidgets -np

real    0m5.587s
user    0m0.008s
sys     0m0.012s

So the xcairo case has subsequent time results that are up to 1.5
times faster (in real time which is the most important component) then
the first execution of the example while the wxwidgets case has
subsequent time results that are up to 15 (!) times slower.  The
initial fast wxwidgers result seems guaranteed if you wait a minute or
so since your last attempt to use wxwidgets.  I mostly tested the
above wxwidgets time results with the -np option (for convenience),
but I also tried the test a few times without -np and got the fast,
slow, slow,... pattern for that case as well.  Also, I usually get a
consistent fast, slow, slow,.... pattern for wxwidgets, but just now I
tried it again, and I got the fast result for something like 10 times
in a row, then the slow result. So the wxwidgets inconsistency in time
results is sometimes inconsistent. :-)

The above results for the xcairo case are quite typical of all
non-wxwidgets cases I have ever investigated before, where real time
results are significantly shorter on second and subsequent
execution because of the well-known effect on Linux of the system
caching all reasonably small files in memory to improve small file
access times for subsequent use.

The very unusual much longer times that often but not always
immediately appear on second and subsequent executions that occur for
the wxwidgets case above strongly suggest to me a system resource is
not being properly released by the first execution of the example so
getting that resource back again often takes a lot of extra time on
the second and subsequent runs.

I brought up this issue with you off list much earlier this week, but
you did not respond at that time, but I hope you do that now.  The
first step in your response should be to try the above bash commands
for at least the wxwidgets case on your Windows and Linux platforms.
to (a) see if this issue also occurs on Windows, and (b) see if this
issue occurs on all Linux systems accessible to you.

@Andrew: could you please try the above time tests as well
on your Linux platforms?

@Both:

If the issue is a Linux resource which I am chronically short of
because of my prior wxwidgets testing and a shared memory leak (see
discussion below) in wxwidgets, then you might not be able to
replicate the issue on Linux until you do sufficient wxwidgets
testing.  My Linux up time is currently 42 days, and if I reboot
(which I won't do lightly because there are two users on the system
and it is a bit of a pain for us to reset all desktops the way we like
them), I might find the issue goes away for a while.

@Phil:

If the issue is a Linux-only one, then an obvious candidate for a
system resource grabber is the shm_open calls in
drivers/wxwidgets_comms.cpp that helps to allow shared memory access
between the wxwidgets device driver and wxPLViewer.  I have just now
read the shm_overview and shm_open/shm_unlink man pages, and it
appears that shm_unlink must be called by _both_ the wxwidgets device
driver and wxPLViewer to properly release the shared memory.  So a
code review for those two cases to make sure that _always_ happens
(i.e., there is no shared memory leak) is indicated.

@Andrew: will you comment further here please about whether we should
be concerned about possible shared memory leaks?  I now realize, for
example, that both Phil's and my calling the IPC method that is used
"shared memory" is likely not specific enough because it does not
distinguish the old-fashioned shmget method (which we do not use) with
the modern mmap-based method that we do use.  See
<http://stackoverflow.com/questions/5656530/how-to-use-shared-memory-with-linux-in-c>
for comments on this important "shared-memory" distinction. 
Furthermore, from the discussion at
<http://stackoverflow.com/questions/22691621/how-to-avoid-shared-memory-leaks>
it appears the mmap-based method cannot actually leak memory.  Is that
your interpretation of those remarks as well?

@Phil:

One thing I noticed from reading those man pages is it is suggested
the name used for shm_open should always start with a "/" for the most
portable results.  It appears our current wxwidgets code does not
follow that suggestion so this may affect Unix platforms that are not
Linux.  So I suggest you will want to address that issue (even though
it has nothing to do with timing.

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

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

 Hi Alan
So I think you should now find the wxPLViewer speed has significantly
improved. The item I have dealt with now was that there is a timer at
the OS level (initiated by wxWidgets) which sends a message to the
viewer which initiates checking for new commands from the console app.
At this point I used to check for a single message and return after
dealing with it. However it seems that for whatever reason (different
OS, different wxWidgets version?) on some systems the minimum time
between the timer calls was quite long. This meant that when we were
dealing with text which required a lot of small transmissions to the
viewer there was a huge overhead. I have now modified things so that
on every timer event I check for new transmissions at least 100 times
with a 1 millisecond sleep between each. This means that for many
small transmissions in a short time we remove most of the overhead.

On my CentOS machine the execution time reported by time x08c -dev
wxWidgets -np has dropped from 40s to about 2 s. Note that this only
times the console part, not the viewer, but still we have clearly
moved to something I would call acceptable.

Note that there will always be a significant overhead for the
transmission so this will never compete with Cairo, but this is
unavoidable because wxWidgets cannot be run in a library without
running it as a separate thread and PlPlot isn't thread safe. Note
also that when using the wxWidgets driver via the wxWidgets binding
(I.e. from within a wxWidgets app) this all becomes irrelevant as the
viewer is not used.

Anyway I hope this fix closes the issue and you are happy Alan.

Phil

On 21 June 2015 at 00:32, Alan W. Irwin <ir...@be...> wrote:
> On 2015-06-20 11:46+0100 Phil Rosenberg wrote:
>
>> 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?
>
>
> Hi Phil:
>
> I did some timing tests for 5.11.0 for comparison purposes which you
> should be able to replicate at least in part (the wxwidgets part) on
> your own Linux boxes.  In each case after building x00c (one of the
> simplest examples), wxwidgets, and other device drivers I ran
>
> time examples/c/x00c -dev <device> -np
>
> twice (where I used the second timing result since that tends to be
> more reliable with everything required loaded from disk into memory
> for that second try) for device = wxwidgets, xcairo, qtwidget, and
> xwin.
>
> The 5.11.0 results when run directly on my principal box (no ssh) were
>
> wxwidgets:
> real    0m0.421s
> user    0m0.032s
> sys     0m0.036s
>
> In this (5.11.0) case, the -np option is ignored (I think), but the
> wxPLViewer
> app seems to disconnect as soon as the page is displayed so
> the above time corresponds pretty closely to the time required to
> display that one page example.
>
> xcairo:
> real    0m0.163s
> user    0m0.016s
> sys     0m0.008s
>
> qtwidget:
> real    0m0.323s
> user    0m0.060s
> sys     0m0.024s
>
> xwin:
> real    0m0.097s
> user    0m0.004s
> sys     0m0.000s
>
> If I did the same timing tests from a thin client over ssh, the times
> went up by roughly a factor of two, and in no case did the time exceed
> 1 second for any of these devices.
>
> In sum, wxwidgets is a bit slow for
> 5.11.0, but still acceptable in comparison with other heavy-duty
> interactive devices, and all of those heavy-duty ones are substantially
> slower than -dev xwin.
>
> I also tested the current (2db68f6 Impliment use of nopause in the wxWidgets
> driver) master tip in the same way for the direct method of display.
> The timing results were similar (as expected) for xcairo, qtwidget, and
> xwin.  However, the command
>
> time examples/c/x00c -dev wxwidgets -np
>
> ended up with the wxPLViewer application frozen with no signs of life
> for up to 30 seconds before I gave up and killed it.
>
> If this test works for you on Windows and also your CentOS box then
> you should double check that you are really testing commit 2db68f6
> rather than some local version with added changes, and if you are,
> perhaps this issue is due to some wxWidgets version issue?  (I am
> currently testing the Debian wheezy version 2.8.12.1-12 of WxWidgets.)
>
> Anyhow, I am anxious to complete the timing test on Linux for master
> tip -dev wxwidgets once you can figure out how to unfreeze the
> wxPLViewer application for my version of WxWidgets.
>
> In any case you should be doing similar timing tests yourself between
> master tip and 5.11.0 on the Windows and CentOS boxes accessible to
> you to make sure there have been no serious timing regressions
> introduced during the current release cycle for our wxwidgets device
> driver.  (The additional timing results I reported above for the xcairo,
> qtwidget, and xwin devices are just to give context for these
> wxwidgets timing results, and there is no necessity for you to time
> any device other than wxwidgets on your various boxes for
> 5.11.0 and master tip.)
>
> 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-24 11:10+0100 Phil Rosenberg wrote:

> Hi Alan

> I will try to do this. Unfortunately the fail case of mine was very
well wrapped in my own wrapper code so it might be a challenge to
generate a simple test.

I was afraid of that, but I hope you can overcome that challenge
because a strong test case would be most helpful to make sure I have
fixed all the issues that I have spotted during my review of
the fill code that directly or indirectly uses notcrossed results.

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] Status report on remaining issues to be addressed for theforthcoming 5.11.1 release (wxwidgets issues)

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

On 2015-06-24 12:47+0100 Phil Rosenberg wrote:

> Hi Alan
>
> I've done two quick tests.
>
> The first was to call on valgrind to do some profiling using valgrind
> --tool=callgrind examples/c/x03c -dev wxwidgets. This indicated that
> the executable spent 75% of its time searching for the wxPLViewer
> executable. I must confess that the method I used to hunt it out was
> pretty slapdash in that I enumerate the entire build directory. I have
> restricted the search to just the utils directory and this is hugely
> improved.
>
> However, I can only assume that the time reported by valgrind doesn't
> includes time "doing nothing" for example if I have called sleep and
> the OS does something else for a while then I'm not sure valgrind
> recognises this as time within the executable. I assume this because
> most of the wall clock time of the examples occurs after the viewer
> has appeared and functions called after this point are only negligibly
> represented by the valgrind results.
>
> So I did a few more things to work out what was taking so long and the
> short story is that most of the time is spent by the console part of
> the executable asking the viewer how long the rendered text is.
>
> Unfortunately there is always going to be some delay when we have the
> inter-process communications so this is always going to be a bottle
> neck. However I have removed a mutex which was not needed and have
> introduced a delay before the viewer reduces its poling frequency.
> This has sped things up significantly. The mutex in particular has
> helped a lot so probably explains the speed difference between Windows
> and Linux.
>
> I'm not sure there is much else I can do to improve things further.

Hi Phil:

I have tested your changes, and I can now at least get the standard
examples to finish, but there is still a large efficiency regression
compared with what is possible with 5.11.0.

Also, my previous timing numbers for both master tip and 5.11.0 were spuriously
long for some reason.  I suspect I was not actually running directly
on our principal box (a 8-year old computer which was high-end when we
bought it).  But I am doing that now directly from my wife's desktop
on that computer as indicated by the "barbara@raven" tag below.

In all cases the PLplot software was built using the
following compiler options:

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

5.11.0:

barbara@raven> time examples/c/x00c -dev xcairo -np

real    0m0.048s
user    0m0.012s
sys     0m0.016s

barbara@raven> time examples/c/x00c -dev qtwidget -np

real    0m0.119s
user    0m0.064s
sys     0m0.016s

barbara@raven> time examples/c/x00c -dev wxwidgets -np

real    0m0.222s
user    0m0.024s
sys     0m0.044s

For this case the -np option is a no-op for -dev wxwidgets and x00c
relenquishes control of wxPLViewer and finishes the timing when the
first (and only page) of this example has been displayed.  So it is a
pretty realistic timing result that can be compared directly with
the equivalent master tip result where the -np option works.  But, of
course, multipage examples would give spurious timing results for
5.11.0 because the application finishes just as soon as the first page
is displayed by wxPLViewer.

master tip:

barbara@raven> time examples/c/x00c -dev xcairo -np

real    0m0.043s
user    0m0.016s
sys     0m0.008s

barbara@raven> time examples/c/x00c -dev qtwidget -np

real    0m0.108s
user    0m0.060s
sys     0m0.016s

barbara@raven> time examples/c/x00c -dev wxwidgets -np

real    0m3.474s
user    0m0.012s
sys     0m0.016s

So as expected the xcairo and qtwidget efficiency doesn't change that
much from 5.11.0 to master tip.  However, the efficiency drops by a
factor of 16 for -dev wxwidgets and changes wxwidgets timing from a
factor of 2-5 slower than the rest for 5.11.0 to a factor of 30-80
slower than the rest.

For master tip (where the -np option works for wxwidgets so we can
obtain reliable timings even for multipage examples) the slow speed of
wxwidgets is also confirmed for x08c:

barbara@raven> time examples/c/x08c -dev xcairo -np

real    0m1.453s
user    0m1.392s
sys     0m0.024s

barbara@raven> time examples/c/x08c -dev qtwidget -np

real    0m0.508s
user    0m0.424s
sys     0m0.016s

barbara@raven> time examples/c/x08c -dev wxwidgets -np

real    0m41.480s
user    0m0.148s
sys     0m0.084s

I looked at the top command results during that ~42 seconds, and
x08c and wxPLViewer rarely exceeded 10 per cent of cpu usage.  In
other words they are spending the vast majority of that real time
interval waiting for each other.

I strongly recommend that your next step should be to confirm the above
time results for wxwidgets on your Linux box for both 5.11.0 and master
tip to prove they aren't some artifact of my own test environment.

Once confirmed, then it seems to me the most promising avenue for you
to explore is to try and figure out why both the application and
wxPLViewer spend such a large fraction of their time waiting according
to the above "top" results.  Do you really think such long waits are
inevitable with the shared memory IPC method you are currently using
(which sounds like it should be quite efficient)?  Or is there some
small detail of your current IPC method that needs to be tweaked to
substantially drop those wait times?

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] Status report on remaining issues to be addressed for theforthcoming 5.11.1 release (wxwidgets issues)

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

Hi Alan

I've done two quick tests.

The first was to call on valgrind to do some profiling using valgrind
--tool=callgrind examples/c/x03c -dev wxwidgets. This indicated that
the executable spent 75% of its time searching for the wxPLViewer
executable. I must confess that the method I used to hunt it out was
pretty slapdash in that I enumerate the entire build directory. I have
restricted the search to just the utils directory and this is hugely
improved.

However, I can only assume that the time reported by valgrind doesn't
includes time "doing nothing" for example if I have called sleep and
the OS does something else for a while then I'm not sure valgrind
recognises this as time within the executable. I assume this because
most of the wall clock time of the examples occurs after the viewer
has appeared and functions called after this point are only negligibly
represented by the valgrind results.

So I did a few more things to work out what was taking so long and the
short story is that most of the time is spent by the console part of
the executable asking the viewer how long the rendered text is.

Unfortunately there is always going to be some delay when we have the
inter-process communications so this is always going to be a bottle
neck. However I have removed a mutex which was not needed and have
introduced a delay before the viewer reduces its poling frequency.
This has sped things up significantly. The mutex in particular has
helped a lot so probably explains the speed difference between Windows
and Linux.

I'm not sure there is much else I can do to improve things further.

Phil

Phil

On 24 June 2015 at 09:24, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan
> As far as the method is concerned I am using shared memory which should
> scale very well. The implementation is as a circular buffer, but for most
> examples the first circuit is enough. I imagine that the issue is related to
> the use of global semaphores to lock that memory and prevent concurrent
> access. These are likely to have very different instantiations on Linux and
> windows or even different Linux flavours or kernel versions. I may have been
> over cautious with their use as finding race condition bugs fan be very
> painful. I will look to see if this is the issue and if i can reduce their
> use.
>
> Phil
> ________________________________
> From: Alan W. Irwin
> Sent: ‎23/‎06/‎2015 17:01
> To: Phil Rosenberg
> Cc: PLplot development list
> Subject: Re: Status report on remaining issues to be addressed for
> theforthcoming 5.11.1 release (wxwidgets issues)
>
> On 2015-06-22 10:21+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>> I now see times close to a minute to render both pages of example 2,
>> which is clearly a problem. This is the case with or without -np. I'm
>> not sure why . I will look into it.
>
> Hi Phil:
>
> I am glad you were able to verify the efficiency problem there since
> issues that are only seen on platforms not accessible to the original
> developer are a real devil to fix.
>
> I wonder if the current efficiency regressions are due to the IPC
> <https://en.wikipedia.org/wiki/Inter-process_communication> method you
> currently use between applications and wxPLViewer not scaling well for
> the extra burdens you are placing on that IPC method since 5.11.0?  In
> particular I would appreciate your comments on whether switching from
> your current IPC method (whatever it is) to one of the many other
> possibilities in that article might completely solve these efficiency
> regressions.
>
> 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...>]

Hi Alan
I will try to do this. Unfortunately the fail case of mine was very well wrapped in my own wrapper code so it might be a challenge to generate a simple test.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎24/‎06/‎2015 04:03
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "plp...@li..." <plp...@li...>
Subject: Re: [Plplot-devel] Bug in notcrossed() function of plfill.c

Hi Phil:

I have been looking carefully at the parts of the fill code that are
affected by notcrossed, and I think we are dealing with a fairly
complex issue here that is larger than just the criterion that is used
to decide on the PL_NEAR_PARALLEL status.  So to make sure that the
final fix really addresses the PLplot failure you discovered that
started this thread, I would greatly appreciate it if you sent me a
test case that replicates that failure for the current master tip
version of PLplot.  Ideally, if your original test case requires
access to data files and/or data processing to determine the data that
are being plotted, it would be good to figure out (say with a debugger
or appropriate print statement) the exact arguments to plfill that
cause the issue, and simply use those exact arguments for a
self-contained test case that triggers the exact same failure
that you originally discovered.

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] Status report on remaining issues to be addressed for theforthcoming 5.11.1 release (wxwidgets issues)

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

Hi Alan
As far as the method is concerned I am using shared memory which should scale very well. The implementation is as a circular buffer, but for most examples the first circuit is enough. I imagine that the issue is related to the use of global semaphores to lock that memory and prevent concurrent access. These are likely to have very different instantiations on Linux and windows or even different Linux flavours or kernel versions. I may have been over cautious with their use as finding race condition bugs fan be very painful. I will look to see if this is the issue and if i can reduce their use.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎23/‎06/‎2015 17:01
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "PLplot development list" <Plp...@li...>
Subject: Re: Status report on remaining issues to be addressed for theforthcoming 5.11.1 release (wxwidgets issues)

On 2015-06-22 10:21+0100 Phil Rosenberg wrote:

> Hi Alan
> I now see times close to a minute to render both pages of example 2,
> which is clearly a problem. This is the case with or without -np. I'm
> not sure why . I will look into it.

Hi Phil:

I am glad you were able to verify the efficiency problem there since
issues that are only seen on platforms not accessible to the original
developer are a real devil to fix.

I wonder if the current efficiency regressions are due to the IPC
<https://en.wikipedia.org/wiki/Inter-process_communication> method you
currently use between applications and wxPLViewer not scaling well for
the extra burdens you are placing on that IPC method since 5.11.0?  In
particular I would appreciate your comments on whether switching from
your current IPC method (whatever it is) to one of the many other
possibilities in that article might completely solve these efficiency
regressions.

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

Hi Phil:

I have been looking carefully at the parts of the fill code that are
affected by notcrossed, and I think we are dealing with a fairly
complex issue here that is larger than just the criterion that is used
to decide on the PL_NEAR_PARALLEL status.  So to make sure that the
final fix really addresses the PLplot failure you discovered that
started this thread, I would greatly appreciate it if you sent me a
test case that replicates that failure for the current master tip
version of PLplot.  Ideally, if your original test case requires
access to data files and/or data processing to determine the data that
are being plotted, it would be good to figure out (say with a debugger
or appropriate print statement) the exact arguments to plfill that
cause the issue, and simply use those exact arguments for a
self-contained test case that triggers the exact same failure
that you originally discovered.

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

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

On 2015-06-22 10:21+0100 Phil Rosenberg wrote:

> Hi Alan
> I now see times close to a minute to render both pages of example 2,
> which is clearly a problem. This is the case with or without -np. I'm
> not sure why . I will look into it.

Hi Phil:

I am glad you were able to verify the efficiency problem there since
issues that are only seen on platforms not accessible to the original
developer are a real devil to fix.

I wonder if the current efficiency regressions are due to the IPC
<https://en.wikipedia.org/wiki/Inter-process_communication> method you
currently use between applications and wxPLViewer not scaling well for
the extra burdens you are placing on that IPC method since 5.11.0?  In
particular I would appreciate your comments on whether switching from
your current IPC method (whatever it is) to one of the many other
possibilities in that article might completely solve these efficiency
regressions.

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-22 14:34-0400 Jim Dishaw wrote:

>
>
>> On Jun 22, 2015, at 1:50 PM, Alan W. Irwin <ir...@be...> wrote:
>>
>>> On 2015-06-21 23:50-0400 Jim Dishaw wrote:
>>>
>>> I fixed the compilation error on cairo.c and I am working on a fix to cairo so that it actually resizes the plot (at least for xcairo, not sure when I can fix wincairo) when the window changes size.
>>>
>>> I will also take a look at xwin when I get a chance.  I think the problem has to do with the sequencing of the events.
>>>
>>> I pushed the changes to the repository.
>>
>> Hi Jim:
>>
>> Thanks very much for that work, and I am looking forward to your further
>> work on cairo.c and xwin.c.
>>
>> There are three minor issues with your current push which you will
>> likely want to address for your future pushes.
>>
>> 1. The results needed to be styled which I did (8025ebe).  I emphasize
>> that is no trouble for me, and I am willing to do that indefinitely,
>> but it does mean your rebasing in future can get complicated if any of
>> those white space styling changes I make are in an area of the file
>> you are working on.  Therefore, to avoid that potential issue I
>> suggest you contact Phil to figure out how to style your further
>> commits on Windows (and me if you want to style your further commits
>> on your OS X box).
>
> I ran scripts/style_sources.sh on my Mac. I do all my commits from that machine. I see it list the files that I have changed. Perhaps it is silently failing?  I will try to single-step the script.

Try scripts/style_sources.sh  --help

to find documentation of all options for the script.

With no arguments that script simple lists the files that would be
changed (which is likely the results you saw) without actually
changing any of the files.

With the --apply argument, and if you answer the further question with
"yes" it will do the wholesale style change to all files that it lists.

I designed the script this way (opt-in twice) because it potentially is extremely
intrusive.  So you might also want to try the --diff -au option to see
what the style changes would be.

In the last couple of years of experience with this script, I have
rarely seen any problems introduced by it, but there has been at least
one of those in the last 6 months due to an uncrustify bug so I always
try to make it a habit to test styled results rather than results
before styling.

>
>>
>> 2. The commit message had no separate short initial line summarizing
>> the commit. That style of commit message is recommended in both
>> <http://who-t.blogspot.be/2009/12/on-commit-messages.html> and [Pro
>> Git Book](http://git-scm.com/book). The reason for that recommendation
>> is many git tools make use of the first separate line of the commit
>> message to help identify commits for humans.
>
> The browse tool shows my commit message. Do I need to make it more descriptive?

Oh. Sorry. That style commit message style is fine.  I just completely
misread the ascii markdown format feed data although now it is obvious
in those ascii results (and also their html equivalent) that you have
followed the recommended style with an initial separate summary line.

>
>>
>> 3. When I styled your changes, my git software recognized there was
>> a permissions issue on one of the files you changed, i.e.,
>>
>> mode change 100755 => 100644 drivers/wingcc.c
>>
>
> I think that is an artifact of moving the file from the windows machine to the mac.

OK.  Glad that is explained, and I believe that terminates this topic.

However, on the different topic of incorrect permissions set
by commits other than your recent ones, I have decided to follow up by
checking all our current file permissions to make sure nothing else
like this has crept in from any of our historical commits.

So from

find $(ls | grep "/") -type f -a '!' -name "*.sh*"  -a '!' \
-perm u=rw,go=r |less

I find 183 files in our source tree that are not named "*.sh" and
which do not have rw-r--r-- permissions.  Some of those have
obviously wrong permissions (such as one of our README files).

Tonight or tomorrow I plan to improve those find stanzas to eliminate
files that should have permissions different than rw-r--r-- in any
case (such as the *.sh* files I have already eliminated from
consideration), and then go through the remaining files that are found
and manually fix any bad permissions that turn up.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Status report on remaining issues to be addressed for the forthcoming 5.11.1 release (pkgIndex.tcl concatenation logic bug?)

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

On 2015-06-22 09:54+0100 Phil Rosenberg wrote:

> Hi Alan
> It seems you were correct, I deleted the cache, but obviously that
> wasn't enough. A full clean build directory solved the problem so you
> can tick that off.

Good.  I think a pretty good rule of thumb is if you have to remove
the cache whenever there is a build-system fix, then you might as well
remove the whole build tree as well.  I am pretty casual about the
extra compile time required when starting with an empty build tree,
but the reason for that is I use ccache.  Which likely doesn't do you
any good with MSVC (although there might be a Windows equivalent), but
I do highly, highly recommend ccache for all gcc users here (including
the Windows variants of gcc).  What it does is keep track of all
compilations in a database, and if the compiler, options, source file,
and headers are all identical, it delivers the cached result of the
previous compilation rather than running gcc to generate that.  ccache
is lightening quick and so far extremely reliable which is why I
recommend it.

To give you some idea of how fast ccache is, here are my time results
for building the plplot library.

software@raven> make clean
software@raven> time make -j4 plplot >& plplot.out

real    0m0.970s
user    0m0.684s
sys     0m0.424s

The first time you see such results (less than a second to rebuild the
plplot library) you hardly believe them, but it is true, ccache is
really that fast.

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 22, 2015, at 1:50 PM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-06-21 23:50-0400 Jim Dishaw wrote:
>> 
>> I fixed the compilation error on cairo.c and I am working on a fix to cairo so that it actually resizes the plot (at least for xcairo, not sure when I can fix wincairo) when the window changes size.
>> 
>> I will also take a look at xwin when I get a chance.  I think the problem has to do with the sequencing of the events.
>> 
>> I pushed the changes to the repository.
> 
> Hi Jim:
> 
> Thanks very much for that work, and I am looking forward to your further
> work on cairo.c and xwin.c.
> 
> There are three minor issues with your current push which you will
> likely want to address for your future pushes.
> 
> 1. The results needed to be styled which I did (8025ebe).  I emphasize
> that is no trouble for me, and I am willing to do that indefinitely,
> but it does mean your rebasing in future can get complicated if any of
> those white space styling changes I make are in an area of the file
> you are working on.  Therefore, to avoid that potential issue I
> suggest you contact Phil to figure out how to style your further
> commits on Windows (and me if you want to style your further commits
> on your OS X box).

I ran scripts/style_sources.sh on my Mac. I do all my commits from that machine. I see it list the files that I have changed. Perhaps it is silently failing?  I will try to single-step the script. 

> 
> 2. The commit message had no separate short initial line summarizing
> the commit. That style of commit message is recommended in both
> <http://who-t.blogspot.be/2009/12/on-commit-messages.html> and [Pro
> Git Book](http://git-scm.com/book). The reason for that recommendation
> is many git tools make use of the first separate line of the commit
> message to help identify commits for humans.

The browse tool shows my commit message. Do I need to make it more descriptive?

> 
> 3. When I styled your changes, my git software recognized there was
> a permissions issue on one of the files you changed, i.e.,
> 
> mode change 100755 => 100644 drivers/wingcc.c
> 

I think that is an artifact of moving the file from the windows machine to the mac. 

> Note, as far as I am aware we (including Arjen and Phil on Windows and
> me on Linux) are all just using the default configuration of git on
> our various platforms, and this is the first time a permissions issue
> has occurred. I think the reason permission bits are normally not an
> issue with git is it is quite smart about default permissions for
> various file types.  In particular files with a ".c" suffix should
> never have an execute permission assigned by default with git unless
> the user does something specific to override that default.
> 
> 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-21 23:50-0400 Jim Dishaw wrote:

> I fixed the compilation error on cairo.c and I am working on a fix to cairo so that it actually resizes the plot (at least for xcairo, not sure when I can fix wincairo) when the window changes size.
>
> I will also take a look at xwin when I get a chance.  I think the problem has to do with the sequencing of the events.
>
> I pushed the changes to the repository.

Hi Jim:

Thanks very much for that work, and I am looking forward to your further
work on cairo.c and xwin.c.

There are three minor issues with your current push which you will
likely want to address for your future pushes.

1. The results needed to be styled which I did (8025ebe).  I emphasize
that is no trouble for me, and I am willing to do that indefinitely,
but it does mean your rebasing in future can get complicated if any of
those white space styling changes I make are in an area of the file
you are working on.  Therefore, to avoid that potential issue I
suggest you contact Phil to figure out how to style your further
commits on Windows (and me if you want to style your further commits
on your OS X box).

2. The commit message had no separate short initial line summarizing
the commit. That style of commit message is recommended in both
<http://who-t.blogspot.be/2009/12/on-commit-messages.html> and [Pro
Git Book](http://git-scm.com/book). The reason for that recommendation
is many git tools make use of the first separate line of the commit
message to help identify commits for humans.

3. When I styled your changes, my git software recognized there was
a permissions issue on one of the files you changed, i.e.,

mode change 100755 => 100644 drivers/wingcc.c

The 755 permission bits mean rwxr-xr-x for user, group, and other, and the
644 permission bits mean rw-r--r-- for user, group, and other, where r
is read permission, w is write permission, and x is execute permission.
I double checked and the permissions for this file were rw-r--r-- for
5.11.0.  Therefore, as a result of something you did or your git
application did, the permissions on drivers/wingcc.c were incorrectly
updated to execute for all of user, group, and other by your editing,
commit, or push.

The interesting thing is every other file you edited and pushed had no such
permission problems.  So can you think of anything special you did for
drivers/wingcc.c that may have caused this permissions issue?

Note, as far as I am aware we (including Arjen and Phil on Windows and
me on Linux) are all just using the default configuration of git on
our various platforms, and this is the first time a permissions issue
has occurred. I think the reason permission bits are normally not an
issue with git is it is quite smart about default permissions for
various file types.  In particular files with a ".c" suffix should
never have an execute permission assigned by default with git unless
the user does something specific to override that default.

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

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

Hi Alan
I now see times close to a minute to render both pages of example 2,
which is clearly a problem. This is the case with or without -np. I'm
not sure why . I will look into it.

Phil

On 21 June 2015 at 00:32, Alan W. Irwin <ir...@be...> wrote:
> On 2015-06-20 11:46+0100 Phil Rosenberg wrote:
>
>> 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?
>
>
> Hi Phil:
>
> I did some timing tests for 5.11.0 for comparison purposes which you
> should be able to replicate at least in part (the wxwidgets part) on
> your own Linux boxes.  In each case after building x00c (one of the
> simplest examples), wxwidgets, and other device drivers I ran
>
> time examples/c/x00c -dev <device> -np
>
> twice (where I used the second timing result since that tends to be
> more reliable with everything required loaded from disk into memory
> for that second try) for device = wxwidgets, xcairo, qtwidget, and
> xwin.
>
> The 5.11.0 results when run directly on my principal box (no ssh) were
>
> wxwidgets:
> real    0m0.421s
> user    0m0.032s
> sys     0m0.036s
>
> In this (5.11.0) case, the -np option is ignored (I think), but the
> wxPLViewer
> app seems to disconnect as soon as the page is displayed so
> the above time corresponds pretty closely to the time required to
> display that one page example.
>
> xcairo:
> real    0m0.163s
> user    0m0.016s
> sys     0m0.008s
>
> qtwidget:
> real    0m0.323s
> user    0m0.060s
> sys     0m0.024s
>
> xwin:
> real    0m0.097s
> user    0m0.004s
> sys     0m0.000s
>
> If I did the same timing tests from a thin client over ssh, the times
> went up by roughly a factor of two, and in no case did the time exceed
> 1 second for any of these devices.
>
> In sum, wxwidgets is a bit slow for
> 5.11.0, but still acceptable in comparison with other heavy-duty
> interactive devices, and all of those heavy-duty ones are substantially
> slower than -dev xwin.
>
> I also tested the current (2db68f6 Impliment use of nopause in the wxWidgets
> driver) master tip in the same way for the direct method of display.
> The timing results were similar (as expected) for xcairo, qtwidget, and
> xwin.  However, the command
>
> time examples/c/x00c -dev wxwidgets -np
>
> ended up with the wxPLViewer application frozen with no signs of life
> for up to 30 seconds before I gave up and killed it.
>
> If this test works for you on Windows and also your CentOS box then
> you should double check that you are really testing commit 2db68f6
> rather than some local version with added changes, and if you are,
> perhaps this issue is due to some wxWidgets version issue?  (I am
> currently testing the Debian wheezy version 2.8.12.1-12 of WxWidgets.)
>
> Anyhow, I am anxious to complete the timing test on Linux for master
> tip -dev wxwidgets once you can figure out how to unfreeze the
> wxPLViewer application for my version of WxWidgets.
>
> In any case you should be doing similar timing tests yourself between
> master tip and 5.11.0 on the Windows and CentOS boxes accessible to
> you to make sure there have been no serious timing regressions
> introduced during the current release cycle for our wxwidgets device
> driver.  (The additional timing results I reported above for the xcairo,
> qtwidget, and xwin devices are just to give context for these
> wxwidgets timing results, and there is no necessity for you to time
> any device other than wxwidgets on your various boxes for
> 5.11.0 and master tip.)
>
> 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] Status report on remaining issues to be addressed for the forthcoming 5.11.1 release (pkgIndex.tcl concatenation logic bug?)

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

Hi Alan
It seems you were correct, I deleted the cache, but obviously that
wasn't enough. A full clean build directory solved the problem so you
can tick that off.

Phil

On 20 June 2015 at 21:00, Alan W. Irwin <ir...@be...> wrote:
> Hi Phil:
>
> I have changed the subject line for this particular topic to something
> less general.  I am hoping my hypothesis that you are the victim of
> stale build results (see below) is correct so we can put this topic
> finally to rest.
>
> On 2015-06-20 11:46+0100 Phil Rosenberg wrote:
>
>> 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".
>
>
>> [...]Perhaps if you try to build in a directory with a space you will be
>> able to see more easily what the problem is?
>
>
> I looked at that as follows (as you should be able to verify on your Linux
> machines):
>
> software@raven> mkdir build\ dir
> software@raven> cd build\ dir/
> software@raven> cmake \
> -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake \
> -DENABLE_ada=OFF -DENABLE_ocaml=OFF \
> -DBUILD_TEST=ON ../plplot.git >& cmake.out
> software@raven> make -j4 install >& install.out
>
> I had to drop Ada and Ocaml because there are "spaced" pathname issues with
> those components which I don't have time to deal with
> at the present time.  But otherwise everything worked perfectly (thanks
> mostly to your work on spaced pathname issues in the past, but also
> because of my recent fixes).  For
> example,
>
> software@raven> grep pkgIndex install.out
> Scanning dependencies of target concatenate_pkgIndex.tcl
> Generating pkgIndex.tcl
> Built target concatenate_pkgIndex.tcl
> -- Installing:
> /home/software/plplot/installcmake/share/plplot5.11.0/pkgIndex.tcl
>
> Since all the pkgIndex.tcl concatenation logic is working fine with a spaced
> build
> tree on Linux, I wonder if you are the victim of stale cached results.
> So please try the master tip version with an absolutely fresh build to
> see if that proves to be the case.  Note you normally don't have
> to do a fresh build to get reliable results especially when there is
> just a source code change, but sometimes it makes a difference if there
> are build-system changes (as in this case).
>
> 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...>]

I fixed the compilation error on cairo.c and I am working on a fix to cairo so that it actually resizes the plot (at least for xcairo, not sure when I can fix wincairo) when the window changes size.

I will also take a look at xwin when I get a chance.  I think the problem has to do with the sequencing of the events.

I pushed the changes to the repository.

> On Jun 20, 2015, at 3:45 AM, Alan W. Irwin <ir...@be...> wrote:
> 
> 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] Status report on remaining issues to be addressed for the forthcoming 5.11.1 release (wxwidgets issues)

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

On 2015-06-20 11:46+0100 Phil Rosenberg wrote:

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

Hi Phil:

I did some timing tests for 5.11.0 for comparison purposes which you
should be able to replicate at least in part (the wxwidgets part) on
your own Linux boxes.  In each case after building x00c (one of the
simplest examples), wxwidgets, and other device drivers I ran

time examples/c/x00c -dev <device> -np

twice (where I used the second timing result since that tends to be
more reliable with everything required loaded from disk into memory
for that second try) for device = wxwidgets, xcairo, qtwidget, and
xwin.

The 5.11.0 results when run directly on my principal box (no ssh) were

wxwidgets:
real    0m0.421s
user    0m0.032s
sys     0m0.036s

In this (5.11.0) case, the -np option is ignored (I think), but the wxPLViewer
app seems to disconnect as soon as the page is displayed so
the above time corresponds pretty closely to the time required to
display that one page example.

xcairo:
real    0m0.163s
user    0m0.016s
sys     0m0.008s

qtwidget:
real    0m0.323s
user    0m0.060s
sys     0m0.024s

xwin:
real    0m0.097s
user    0m0.004s
sys     0m0.000s

If I did the same timing tests from a thin client over ssh, the times
went up by roughly a factor of two, and in no case did the time exceed
1 second for any of these devices.

In sum, wxwidgets is a bit slow for
5.11.0, but still acceptable in comparison with other heavy-duty
interactive devices, and all of those heavy-duty ones are substantially
slower than -dev xwin.

I also tested the current (2db68f6 Impliment use of nopause in the wxWidgets
driver) master tip in the same way for the direct method of display.
The timing results were similar (as expected) for xcairo, qtwidget, and
xwin.  However, the command

time examples/c/x00c -dev wxwidgets -np

ended up with the wxPLViewer application frozen with no signs of life
for up to 30 seconds before I gave up and killed it.

If this test works for you on Windows and also your CentOS box then
you should double check that you are really testing commit 2db68f6
rather than some local version with added changes, and if you are,
perhaps this issue is due to some wxWidgets version issue?  (I am
currently testing the Debian wheezy version 2.8.12.1-12 of WxWidgets.)

Anyhow, I am anxious to complete the timing test on Linux for master
tip -dev wxwidgets once you can figure out how to unfreeze the
wxPLViewer application for my version of WxWidgets.

In any case you should be doing similar timing tests yourself between
master tip and 5.11.0 on the Windows and CentOS boxes accessible to
you to make sure there have been no serious timing regressions
introduced during the current release cycle for our wxwidgets device
driver.  (The additional timing results I reported above for the xcairo,
qtwidget, and xwin devices are just to give context for these
wxwidgets timing results, and there is no necessity for you to time
any device other than wxwidgets on your various boxes for
5.11.0 and master tip.)

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] Status report on remaining issues to be addressed for the forthcoming 5.11.1 release (pkgIndex.tcl concatenation logic bug?)

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

Hi Phil:

I have changed the subject line for this particular topic to something
less general.  I am hoping my hypothesis that you are the victim of
stale build results (see below) is correct so we can put this topic
finally to rest.

On 2015-06-20 11:46+0100 Phil Rosenberg wrote:

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

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

I looked at that as follows (as you should be able to verify on your Linux machines):

software@raven> mkdir build\ dir
software@raven> cd build\ dir/
software@raven> cmake \
-DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake \
-DENABLE_ada=OFF -DENABLE_ocaml=OFF \
-DBUILD_TEST=ON ../plplot.git >& cmake.out
software@raven> make -j4 install >& install.out

I had to drop Ada and Ocaml because there are "spaced" pathname issues with
those components which I don't have time to deal with
at the present time.  But otherwise everything worked perfectly (thanks
mostly to your work on spaced pathname issues in the past, but also
because of my recent fixes).  For
example,

software@raven> grep pkgIndex install.out
Scanning dependencies of target concatenate_pkgIndex.tcl
Generating pkgIndex.tcl
Built target concatenate_pkgIndex.tcl
-- Installing: /home/software/plplot/installcmake/share/plplot5.11.0/pkgIndex.tcl

Since all the pkgIndex.tcl concatenation logic is working fine with a spaced build
tree on Linux, I wonder if you are the victim of stale cached results.
So please try the master tip version with an absolutely fresh build to
see if that proves to be the case.  Note you normally don't have
to do a fresh build to get reliable results especially when there is
just a source code change, but sometimes it makes a difference if there
are build-system changes (as in this case).

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

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

On 2015-06-20 13:33+0100 Phil Rosenberg wrote:

> Oh there is the fill issue that I reported previously too. Once you
> have had a chance to consider if the change is okay let me know.

Hi Phil:

That is (buried) on my agenda already as

>> On 19 June 2015 at 21:02, Alan W. Irwin <ir...@be...> wrote:
>>> [...]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 on-going discussion of the
>>>   notcrossed functionality with Phil.

The ball is in my court on that one, but I have had no chance to look at it yet
due to everything else on my PLplot agenda.

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] Working around the bug in the -np option for -dev wxwidgets

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

Hi Alan (and Jim)
This just was never implemented so nothing to do with the eop calls.

I have implemented it now. Note that I haven't included any pause at
all between the displaying of the final plot and the exit. The viewer
exits as soon as the driver tidy function is called. This is
consistent with the plpause documentation, but I'm not sure if it is
what you want for testing Alan?

Phil

On 26 May 2015 at 22:17, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan
> I think this one had escaped my to do list. It is now back on and I
> will let you know.
>
> Phil
>
> On 26 May 2015 at 21:52, Jim Dishaw <ji...@di...> wrote:
>> I believe this bug is due to extra EOP (or BOP I can't remember now) call that I mentioned in email several months ago. I can't search the mailing list right now, but I can do it later if needed.
>>
>>
>>
>>> On May 26, 2015, at 4:35 PM, Alan W. Irwin <ir...@be...> wrote:
>>>
>>> Hi Phil:
>>>
>>> A known bug for the new wxwidgets device is that the -np option
>>> (which should automatically display all the pages of the example and
>>> exit without any user intervention) does not work.
>>>
>>> This bug especially impacts interactive testing since manually
>>> clicking on the wxPLViewer GUI to see all the pages and exit the GUI
>>> for each tested example gets really old really fast.  It's for this
>>> reason of convenience I have recently (commit id 818b93a) temporarily
>>> excluded testing wxwidgets as part of the test_interactive targets of
>>> our three different build systems.
>>>
>>> When you do fix -np for the wxwidgets device please give me a heads up
>>> so I can include tests of wxwidgets again in the test_interactive
>>> targets.
>>>
>>> Alan
>>> __________________________
>>> Alan W. Irwin
>>>
>>> Astronomical research affiliation with Department of Physics and Astronomy,
>>> University of Victoria (astrowww.phys.uvic.ca).
>>>
>>> Programming affiliations with the FreeEOS equation-of-state
>>> implementation for stellar interiors (freeeos.sf.net); the Time
>>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>>> software package (plplot.sf.net); the libLASi project
>>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>>> and the Linux Brochure Project (lbproject.sf.net).
>>> __________________________
>>>
>>> Linux-powered Science
>>> __________________________
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

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

Oh there is the fill issue that I reported previously too. Once you
have had a chance to consider if the change is okay let me know.

Phil

On 20 June 2015 at 11:46, Phil Rosenberg <p.d...@gm...> wrote:
>  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
>> __________________________