Re: [Plplot-devel] plP_bop() was killing functionality in wingcc

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

I will try building on my windows machine to see if I can track down the problem.  I think this might be a problem in the wingcc driver.

> On Jan 31, 2016, at 10:34 PM, Greg Jung <gv...@gm...> wrote:
> 
> Hi Alan,
> 
>   I don't program in plplot directly and so I'm pretty sure I'd be going through a month
> of debugging my own "example" before it would purport to show a plplot bug.
> I have put examples X02.cc and X20.cc together, removing the "delete plstream"s
>  and found that X20's failure does not affect the X02 display.  So I don't know how to target
> this symptom as it acts like a booby trap that gets tweaked by an innocent call.
>   What I've done now is build GDL based on 5.11.1 with a statically linked plplot/qhull/shapelib
> so I don't reconfigure the effects away.  This version has the mildest version of the "wrong" behavior
> so it looks like programming logic, better than the next worse behavior where all windows were 
> blanked at once.
>   I'll try to paste the screenshot in so it might get snuffed by the mailing list:
> <image.png>
> 
> So, the two large wine-colored windows are the second phase of the test that are supposed to
> have Saturn images (shown in screenshot of earlier post).  windows on the left were painted,
> with various color maps, from the same pyramidial distribution.  They are created by plplot
> but the image is put on directly by the GDL driver (which is a plstream:: class). 
> 
> The saturn images can be seen when the windows are being moved or resized.
>   Also in the upper left window where I've overplotted with line drawings,
> when I resize those windows the painted image is seen while the mouse button is pressed.
> 
> I can't capture this on screen because it reverts to the line drawing when I let go.
> o ok! now I see the reason for ::c_plclear() - I can erase the line drawing and the 
> bitmap-drawn painted background stays on-screen.  Because of my experiments with the
> GDL "erase" command which is
> 
> $ grep -B2 clear /f/gdl/src/gdlwinstream.cpp
>       plstream::scolbg(red0,green0,blue0); //overwrites col[0]
>         ::c_plbop();
>  //     ::c_plclear();
> 
> In this version I can erase the line-drawn but not the painted part.  So I've done that on windows 5 and 12
> and re-positioned for a partial screen snapshot:
> <image.png>
> 
> Now, this behavior is much healthier than the worst symptoms I've been having.
> 
> That wine colored background is actually the color of background in the Linux/X11 test.
> 
> Now I'll work on Phil's questions...
> 
> On Sun, Jan 31, 2016 at 3:24 AM, Alan W. Irwin <ir...@be... <mailto:ir...@be...>> wrote:
> On 2016-01-30 20:22-0800 Greg Jung wrote:
> 
> On Fri, Jan 29, 2016 at 12:58 PM, Alan W. Irwin <ir...@be... <mailto:ir...@be...>>
> wrote:
> So your best bet for getting help here is to show completely independent of
> GDL
> that there is actually an issue with the master tip version of PLplot
> that is unmodified by you other than possibly to modify one of our
> standard examples in order to demonstrate the problem.
> 
> 
> Ok I can simply build plplot without the bop() in rdbuf_bop and now I ask,
> which example does it affect in linux? linux runs x20.cc fine, but breaks
> in any case in  windows 7. Example x02.cc, which is the only example using
> bop() explicitly, also
> works as it should without the plP_bop() call in rdbuf_bop.
> I don't have a prejudice, I don't know why the call messes my GDL windows
> up,
> but it does - and only in windows, not in xwin.  Example x20.cc doesn't work
> on windows, but removing that call does not affect the example behavior.
> All I can
> do is report what I find, and there it is in terms of the examples.
> 
> 
> Hi Greg:
> 
> Your justification for a change to PLplot might be entirely valid (I
> don't have the expertise to comment on that), but it is also not what
> I was hoping for from you.  To clarify that, I would like a pure
> PLplot test case from you that demonstrates the same issue that you
> get with a combination of GDL and PLplot.
> 
> In sum, what I am suggesting you do here is follow the usual first
> rule of debugging a complex issue, i.e., keep simplifying your test
> case until others can easily reproduce it.  So the very first
> such simplification is to remove GDL completely from the mix while
> still demonstrating the same error.  Can you do that first step for
> us by implementing a simple self-contained C, C++, or Python test case
> that generates exactly the same data and makes the same calls to
> PLplot functions in the exact same order that one of your GDL examples
> does that gives you bad plotting results?
> 
> If that self-contained example does not demonstrate those bad plotting
> results that likely means (assuming the example uses the same data and
> PLplot calls) there is something wrong with the way that GDL
> interfaces with PLplot, and such an issue would be out of scope for
> us.
> 
> On the other hand, if we obtain a self-contained pure PLplot test case
> from you that demonstrates the same problem as you get in the GDL +
> PLplot case then we are much further forward since there is a lot more
> we can do to verify and ultimately debug that self-contained test case.
> 
> 
> Alan
> __________________________
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca <http://astrowww.phys.uvic.ca/>).
> 
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net <http://freeeos.sf.net/>); the Time
> Ephemerides project (timeephem.sf.net <http://timeephem.sf.net/>); PLplot scientific plotting
> software package (plplot.sf.net <http://plplot.sf.net/>); the libLASi project
> (unifont.org/lasi <http://unifont.org/lasi>); the Loads of Linux Links project (loll.sf.net <http://loll.sf.net/>);
> and the Linux Brochure Project (lbproject.sf.net <http://lbproject.sf.net/>).
> __________________________
> 
> Linux-powered Science
> __________________________
>