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

[Greg J. <gv...@gm...>]

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: Inline image 1]

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: Inline image 2]

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