plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Correct implementation of key and button events in the interactive drivers

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

On 2016-01-12 08:18-0000 Phil Rosenberg wrote:

> Hi Alan and all
> To answer Alan's specific question near the end, on Windows (I don't
> have a Cygwin build handy) with wxWidgets a right click is button3,
> not button 2 as I may have said in my first reply.
>
> Alan, more generally:
> It seems very clear that you have a well defined idea about exactly
> what should happen with the locate mode and what should be filled in
> where.

Actually I am no expert at this, but I have used an empirical approach
with -locate mode for example 01 and cut and pasted what xwin delivers
versus the rest in my report.  So you will want to review those xwin
results to see what the other devices should aspire to.  I emphasize
xwin here because that is the only device that seems to have proper
interactivity.  Probably what that really means is the interactive
parts of example 01 and 20 were implemented a long time ago to work
with exactly what xwin (and I assume -dev tk since that uses xwin
capabilities quite a bit, although I did not bother to check) could
deliver.  Because xwin and tk were the only interactive devices that
existed at that time.  But what they delivered was quite a rich
interactive capability.  (Note I am considering some of the really
nice-looking interactive results that are delivered by the xwin device
for octave as well as the interactive parts of example 01 and 20 when
I am claiming that xwin has a rich interactive capability.) So our
initial goal should be to make sure our other interactive devices
deliver the same events (and not a whole bunch more as in the xcairo
case) with the same fields filled in as in the xwin case and also
implement xor mode properly to gain that rich interactive capability
for themselves.

Also, it is important that you look at the interactive code in
those two examples to see what is going on.  For example,
in example 20 there is some specific logic in get_clip
that depends on exact details delivered via plGetCursor( &gin );
by the device.  I am referring to the code fragments

gin.state & 0x100

gin.button == 3

etc.  (By the way, that 0x100 numerical constant should obviously be
replaced by PL_MASK_BUTTON1 in that example.  Do you want to do the
honors there?)

The important point here is that if your device driver is not filling
in those parts of PLGraphicsIn gin the way xwin does, then you are
hosed.  Also notice that from reading that logic you are hosed if
there is no xor mode implemented for your device (qtwidgets) or it is
not thoroughly debugged (apparently the case for xcairo and wxwidgets
from the lack of any sort of response to the -xor mode of example 1).

> I think it would be very good to condense this into a single
> description, either in the documentation or just in an email to this
> list so that all the device developers know what they should be
> working to.

The above is just a minimal start that is the current extent of my
knowledge.  I do agree a lot more expertise is needed as people look
carefully at what xwin delivers and how that is used in the
interactive parts of examples 1 and 20 that do not yet work for any
other device.

Also, I think it is important to avoid considering large interactive
design questions at the moment.  Instead, we have a working and quite
rich interactive model with xwin, and we should think of ourselves as
in emergency fixup mode to get our "interactive" devices to deliver
what xwin does. After that goal is reached, then we can think of
larger design questions about enhancing that already rich interactive
experience for all interactive devices.

Also note that with time and interest someone should be able to follow
the xwin code to see how it produces the cut and pasted results that I
posted.  That device waits for events and interprets them with X calls
which are straightforward to figure out by consulting man pages on a
Linux system and also available over the net.  I am not advocating
that you personally do that analysis yourself (although it is a "would
be nice"), but that possibility for deeper analysis exists if we
really need to understand why xwin is deliverying specific data for a
certain well-chosen subset of events and ignoring the rest.

A similar analysis is definitely required for each of our other
interactive devices by their maintainers but obviously in each case
you need to interpret "interactive" calls for just the relevant
library (e.g., the wxwidgets library for the wxwidgets device case) to
figure out how to mask certain events (the same ones ignored by xwin)
and how to determine the same data for the needed events that is
determined by xwin. So a fairly good knowledge of the library involved
(such as you already have for the wxwidgets library) should be a big
help to quickly figure out how to get an interactive device to act the
same way (i.e., fill in all the PLGraphicsIn struct fields dumped out
in example 1 for -locate mode and implement xor mode) as
the xwin device.

> Some things that aren't entirely clear to me from your reply, or even
> if they are there it would be good to summarise them in one place:
>
> 1) Should we report mouse movements (i.e. hovers), I think probably
> that would be good?
> 2) How do we distinguish a key press and a key release?
> 3) How do we distinguish mouse drags from mouse movements with no
> buttons pressed?
> 4)Should we report keyboard key release
> 5) Do we need to (or can we) do anything about repeat keyboard keys
> when keys are pressed and held?
> 6) We need a really good definition of what string, state and button
> should contain for each event, especially for "special" keys (shift,
> ctrl, etc) and special keys combined with each other, regular
> characters or mouse clicks.
> 7) I only have access to a UK keyboard on a UK English windows
> install. What (if anything) should we do about international
> keyboards?
> 8) What about clashes with page advance keyboard shortcuts?

In the spirit of my preliminary remarks above, here are my quick
answers to the questions above.

1 to 4.  This is empirical again, but if you ever run the xev
application under X you will realize it reports many more events (such
as mouse movement with no button pressed) then are reported by xwin.
So I am virtually positive that xwin sets a mask to ignore certain
kinds of events such as moving mouse without key or button pressed
(hovers).  I agree we should document what it ignores, but the start
of that is what I cut and pasted before for the xwin device (for those
who could not run it themselves) and that empirical result may be all
we need.  However, if that is not sufficient diving into the xwin code
to figure out the X-related event loop there in detail so as to copy
that same overall event loop model for a higher level library such as
wxwidgets is always an option.

5. No.

6. Play with -locate mode of example 01 to find that out.  xwin masks
out lots of this stuff which xcairo does not (yet).  wxwidgets
currently masks out too much; for example, it currently ignores key
events completely.

7. Internationalization of keyboards is too big to consider now.
Instead, I think we should focus on the case of a keyboard with
(possibly modified) ascii characters.

8. We should mask out anything we don't like to respond to such as
special keys.  After all, the only reason we want to handle key events
is to provide a simple mechanism (e.g. q for quit, m for menu, etc.,)
for the user to communicate with an interactive application that is
waiting for certain letters to be struck to take certain actions.  So
we likely just want to do something for regular ordinary letters but
probably with shift, ctrl, and alt imposed on top of them as modifying
keys. But again, we should probably look first at how xwin has masked
off keys it wants to ignore.  My preliminary experience is xwin
probably does not mask off sufficient keys (for example, it reacts in
a peculiar way with -locate mode for example 01 if you hit the enter
key).  But we can start with what xwin masks off now and then take it
from there.

Of course, your overall point is an excellent one that we should
concisely document what a PLplot interactive device should deliver. So
once someone gains better knowledge of that with making the changes to
just one additional device so that it delivers the same rich
interactive experience as xwin, they should follow up by putting
together such documentation to make life much easier for other
interactive device developers who will need to update their
device the same way.

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] Correct implementation of key and button events in the interactive drivers

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

Hi Alan and all
To answer Alan's specific question near the end, on Windows (I don't
have a Cygwin build handy) with wxWidgets a right click is button3,
not button 2 as I may have said in my first reply.

Alan, more generally:
It seems very clear that you have a well defined idea about exactly
what should happen with the locate mode and what should be filled in
where. I think it would be very good to condense this into a single
description, either in the documentation or just in an email to this
list so that all the device developers know what they should be
working to. When I do bits of programming consultancy work I tell my
clients that I need a tick list that is detailed enough that if I put
a tick next to every item then I know the job is done.

Some things that aren't entirely clear to me from your reply, or even
if they are there it would be good to summarise them in one place:

1) Should we report mouse movements (i.e. hovers), I think probably
that would be good?
2) How do we distinguish a key press and a key release?
3) How do we distinguish mouse drags from mouse movements with no
buttons pressed?
4)Should we report keyboard key release
5) Do we need to (or can we) do anything about repeat keyboard keys
when keys are pressed and held?
6) We need a really good definition of what string, state and button
should contain for each event, especially for "special" keys (shift,
ctrl, etc) and special keys combined with each other, regular
characters or mouse clicks.
7) I only have access to a UK keyboard on a UK English windows
install. What (if anything) should we do about international
keyboards?
8) What about clashes with page advance keyboard shortcuts?


Regarding wxWidgets, I didn't capture down clicks of mouse buttons
because I saw some reports that this can interfere with window
selection, but I can investigate further.

Phil

On 12 January 2016 at 06:09, Alan W. Irwin <ir...@be...> wrote:
> On 2016-01-11 19:41-0000 Arjen Markus wrote:
>
>> Hi everyone,
>>
>>
>>
>> I am trying to get example x20f to work properly with the new Fortran bindings and the wingcc driver. The first part is working: I see the various fields of the structure PLGraphicsIn being filled with plausible values - so the Fortran bindings are working. However, there are two fields that are not set in line with the xwin driver:
>>
>> -        The button field: it seems the left button has value 1 and the right button should be value 3 - in the window the somewhat confusing message says to press "button 2". I guess this is due to mice classically used on UNIX/X Window systems have/had three buttons. That is a simple change to the wingcc driver.
>>
>> -        The state field: this is a bit more troublesome. I have no idea what it means. Nor what values it can assume. Can anyone enlighten me?
>
> Hi Arjen:
>
> You have opened up a whole lot of issues here, but I am glad you have
> done so.  Furthermore, I suggest you keep the issues as separated
> as possible from each other by, for example, debugging wingcc
> interactive issues with C examples only, and debugging the interactive
> issues of the new Fortran examples/binding using -dev xwin alone
> since that is our only device that has implemented interactivity
> correctly so far, i.e., it is the only interactive device
> on Linux that operates C example 20 and C example 01 with -xor example
> option correctly.
>
> @Phil (wxwidgets), @Jim (wingcc and your new extended version of that
> you are developing), @ Arjen (wingcc if Jim does not get to it), and
> those volunteers willing to support interactivity properly on xcairo
> and qtwidgets.  This is a long post because of many cut and pasted
> results from modified example 1 which are quite informative
> netherless.  But please especially notice where the device you are
> interested in is mentioned below, and please fix the several issues I
> have identified for all such devices (other than xwin where the issues
> are fairly minor).
>
> Here are the issues that need to be dealt with.
>
> I. C example 20 and the -xor example option for C example 01 are not
> working correctly for most of our interactive devices.
>
> For current master tip (commit 3f05b0b which includes all of Phil's
> latest wxwidgets efforts), I find that with any of the xcairo,
> qtwidget, or wxwidgets devices that examples/c/x20c simply skips
> through the interactive part of the example with no chance to drag and
> drop to select a part of the image to view like you get with the xwin
> device.  Similarly, I find the -xor example option for examples/c/x01c
> appears to be a nop-op for the xcairo, qtwidget, or wxwidgets devices
> while the xwin device provides some interactive results (a symbol
> visibly moving along one of the lines plotted).  Both these cases
> depend critically on whether an interactive device has implemented xor
> capability or not, but that may not be all the story because of
> the push and release and push, drag, and drop issues that I
> also note below.
>
> If you search all driver code this way
>
> grep -i xor drivers/* |less
>
> then it appears that some attempt has been made to support xor mode
> for cairo, wingcc, wxwidgets, and xwin, and it appears this
> functionality does work properly for xwin but not for cairo and
> wxwidgets, and I have not been able to test wingcc or Jim's device.
> Note also, there currently seems to be not even an attempt
> to support xor with our qtwidget device.
>
> So implementation of working xor mode needs to be addressed by those
> wanting to support proper device interactivity for wxwidgets, wingcc
> (likely), Jim's device (likely), xcairo, and qtwidget.
>
> II. Metadata returned by interactive events being processed by our
> various interactive devices.
>
> I have just now (commit 406d8cf) modified the -locate mode of C
> example 01 to return complete information about all the fields in the
> PLGraphicsIn struct returned by plGetCursor. This should vastly
> improve our ability to diagnose interactive issues.
>
> The results below also verify and enhance what Phil has said
> in response to Arjen's question about state.
>
> Here are results for a simple button push and release (without
> dragging) for my left mouse, middle mouse (where you depress the
> scroll wheel on a generic mouse that uses the Microsoft protocol), and
> right mouse buttons followed by a simple push and release of the a, B,
> C, and d buttons. I have confirmed in every case that the correct
> subwindow was identified by these results.
>
> xwin push and release:
>
> software@raven> ./x01c -dev xwin -locate
> PLplot library version: 5.11.1
> subwin = 0, wx = 2.155642,  wy = 18.765058, dx = 0.214087,  dy = 0.756677
> keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x00
> subwin = 1, wx = 0.355375,  wy = 0.019289, dx = 0.712697,  dy = 0.770030
> keysym = 0x20, button = 0x02, string = '', type = 0x00, state = 0x00
> subwin = 2, wx = 2.085808,  wy = 0.313648, dx = 0.211307,  dy = 0.232938
> keysym = 0x20, button = 0x03, string = '', type = 0x00, state = 0x00
> subwin = 0, wx = 1.547419,  wy = 15.049218, dx = 0.177943,  dy = 0.724036
> keysym = 0x61, button = 0x00, string = 'a', type = 0x00, state = 0x00
> subwin = 0, wx = 1.547419,  wy = 15.049218, dx = 0.177943,  dy = 0.724036
> keysym = 0x42, button = 0x00, string = 'B', type = 0x00, state = 0x01
> subwin = 0, wx = 1.547419,  wy = 15.049218, dx = 0.177943,  dy = 0.724036
> keysym = 0x43, button = 0x00, string = 'C', type = 0x00, state = 0x01
> subwin = 0, wx = 1.547419,  wy = 15.049218, dx = 0.177943,  dy = 0.724036
> keysym = 0x64, button = 0x00, string = 'd', type = 0x00, state = 0x00
>
> Evidently, xwin only pays attention to one of button/key press or
> button/key release events but not both, and does not pay any attention
> to the actual event corresponding to the push or release of the shift
> key.  The shift key being pressed while a letter is pressed does
> modify both the state result (which is changed to PL_MASK_SHIFT), the
> keysym, and the resulting string of the event associated with
> the non-modifying key.  And similarly when capslock is on
> you get a corresponding change in the state to PL_MASK_CAPS and
> corresponding changes in keysym and string.  I think all these
> constraints are a good model of what other devices should do since
> enough information is delivered that xwin knows how to handle the
> interactive aspects of example 01 and 20 while the other devices do
> not because they deliver information about too many events (xcairo)
> or too few events (qtwidget, wxwidgets).
>
> However, that said, I would like to see a minor xwin change so that it
> always fills in string and state for the button case like xcairo does
> instead of the current result for that case where string is empty and
> state is 0x00.
>
> xcairo push and release:
>
> software@raven> ./x01c -dev xcairo -locate
> PLplot library version: 5.11.1
> subwin = 0, wx = 2.292135,  wy = 20.790289, dx = 0.225000,  dy = 0.775926
> keysym = 0x20, button = 0x01, string = 'button 1', type = 0x00, state = 0x00
> subwin = 0, wx = 2.292135,  wy = 20.790289, dx = 0.225000,  dy = 0.775926
> keysym = 0x20, button = 0x01, string = 'button 1', type = 0x00, state = 0x100
> subwin = 1, wx = 0.329669,  wy = 0.019185, dx = 0.706944,  dy = 0.746296
> keysym = 0x20, button = 0x02, string = 'button 2', type = 0x00, state = 0x00
> subwin = 1, wx = 0.329669,  wy = 0.019185, dx = 0.706944,  dy = 0.746296
> keysym = 0x20, button = 0x02, string = 'button 2', type = 0x00, state = 0x200
> subwin = 2, wx = 5.603909,  wy = 0.612271, dx = 0.313889,  dy = 0.294444
> keysym = 0x20, button = 0x03, string = 'button 3', type = 0x00, state = 0x00
> subwin = 2, wx = 5.603909,  wy = 0.612271, dx = 0.313889,  dy = 0.294444
> keysym = 0x20, button = 0x03, string = 'button 3', type = 0x00, state = 0x400
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0x61, button = 0x26, string = 'a', type = 0x00, state = 0x00
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0x61, button = 0x26, string = 'a', type = 0x00, state = 0x00
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0xffe1, button = 0x32, string = 'Shift_L', type = 0x00, state = 0x00
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0x42, button = 0x38, string = 'B', type = 0x00, state = 0x01
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0x42, button = 0x38, string = 'B', type = 0x00, state = 0x01
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0xffe1, button = 0x32, string = 'Shift_L', type = 0x00, state = 0x01
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0xffe1, button = 0x32, string = 'Shift_L', type = 0x00, state = 0x00
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0x43, button = 0x36, string = 'C', type = 0x00, state = 0x01
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0x43, button = 0x36, string = 'C', type = 0x00, state = 0x01
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0xffe1, button = 0x32, string = 'Shift_L', type = 0x00, state = 0x01
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0x64, button = 0x28, string = 'd', type = 0x00, state = 0x00
> subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
> keysym = 0x64, button = 0x28, string = 'd', type = 0x00, state = 0x00
>
> N.B. Evidently xcairo marks both push and release events for buttons,
> character keys and even modifying keys like Shift_L, and the only
> difference for buttons is the state which on release is set to the
> correct PL_MASK_BUTTON[1-3].  There is no difference in push and
> release events for both ordinary and modifying keys.  I believe there
> are way too many events being reported here, and that may be confusing
> interactive results for -dev xcairo.  Therefore, I would strongly
> advise our volunteer supporter of xcairo that the noted events should
> be masked down to just one of push or release (with state set to
> PL_MASK_BUTTON[1-3] for events involving those mouse buttons) and
> modifying character push or release should have no event reported for
> it all. It is good that xcairo makes a special effort to fill in
> string and state (at least on release) for button events, and I urge
> that be done for all other devices as well.
>
> qtwidget push and release:
>
> software@raven> ./x01c -dev qtwidget -locate
> PLplot library version: 5.11.1
> subwin = 0, wx = 2.789786,  wy = 17.775337, dx = 0.252969,  dy = 0.747899
> keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x100
> subwin = 1, wx = 0.464964,  wy = 0.019220, dx = 0.752969,  dy = 0.754622
> keysym = 0x20, button = 0x02, string = '', type = 0x00, state = 0x200
> subwin = 2, wx = 4.343026,  wy = 0.565404, dx = 0.277910,  dy = 0.284034
> keysym = 0x20, button = 0x03, string = '', type = 0x00, state = 0x400
> subwin = 0, wx = 2.973587,  wy = 12.998339, dx = 0.263658,  dy = 0.704202
> keysym = 0x00, button = 0x00, string = '', type = 0x00, state = 0x00
> subwin = 0, wx = 2.994009,  wy = 12.814608, dx = 0.264846,  dy = 0.702521
> keysym = 0x00, button = 0x00, string = '', type = 0x00, state = 0x00
> subwin = 0, wx = 3.014431,  wy = 12.630877, dx = 0.266033,  dy = 0.700840
> keysym = 0x00, button = 0x00, string = '', type = 0x00, state = 0x00
> subwin = 0, wx = 3.014431,  wy = 12.630877, dx = 0.266033,  dy = 0.700840
> keysym = 0x00, button = 0x00, string = '', type = 0x00, state = 0x00
>
> This does follow the same limits as xwin in terms of what events are
> noted which is good, but the amount of information supplied for each
> event needs to be increased to what is supplied by xwin (supplemented
> by the extra information I have asked for in that case).
>
> wxwidgets push and release:
>
> software@raven> ./x01c -dev wxwidgets -locate
> PLplot library version: 5.11.1
> subwin = 0, wx = 1.110958,  wy = 29.386613, dx = 0.155242,  dy = 0.854008
> keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x100
> subwin = 1, wx = 0.435386,  wy = 0.019594, dx = 0.742608,  dy = 0.842557
> keysym = 0x20, button = 0x02, string = '', type = 0x00, state = 0x200
> subwin = 2, wx = 0.948778,  wy = 0.218958, dx = 0.180780,  dy = 0.212786
> keysym = 0x20, button = 0x03, string = '', type = 0x00, state = 0x400
>
> Note, I started with a black window with no plots on it, but I guessed
> at the first upper left location of the subwindow to push the left
> mouse button and got the above good first event from that and so
> forth.  By the last event the plot window was actually plotting.
> Obviously, these symptoms indicate there is a rendering bug here in
> locate mode that needs to be addressed.
>
> That said, these limited button results are good except for the empty
> string returned for these events (note that same comment for all other
> devices than xcairo which does return a proper string for button
> events).  However, key events (as opposed to button events) are masked
> out for this device, and that substantial limitation should be
> addressed.  (I have noted this deficiency before, but I keep
> mentioning it each time I run into it for wxwidgets because
> interactive astronomical research programmes I am familiar with do
> heavily use key events as well as mouse button events, and I assume
> there are a lot of other interactive programmes that do that as well.)
>
> That terminates my push and release data for mouse buttons and a few
> selected keys, but now I would like to follow up with push,
> redacted drag and drop results for the left mouse button for each of the
> interactive devices I have mentioned, where the redacted part is every
> drag event after the first one which are identical to the first one
> except for position.
>
> xwin push, redacted drag and drop:
>
> software@raven> ./x01c -dev xwin -locate
> PLplot library version: 5.11.1
> subwin = 0, wx = 1.282297,  wy = 23.832113, dx = 0.162187,  dy = 0.801187
> keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x00
> subwin = 0, wx = 1.297892,  wy = 23.663212, dx = 0.163114,  dy = 0.799703
> keysym = 0x20, button = 0x00, string = '', type = 0x00, state = 0x100
> [....]
>
> Evidently, xwin identifies the button during the initial push, but
> sets the button result to 0 during the subsquent drag event, but does
> signal that event is going on with button 1 (the left mouse button in
> my case) by producing the state result of 0x100 = PL_MASK_BUTTON1 for
> a drag event.  (Just to satisfy my curiosity, I have also confirmed
> state is PL_MASK_BUTTON2, and PL_MASK_BUTTON3 if the dragging is done
> with button 2 [by pressing the scroll wheel for my mouse downward
> without rotating it] or button 3 [the right mouse button in my case].)
> Note that the final drop event is masked out.  I think that is a mistake
> and the xcairo result below that includes that is what we should aim
> for here.
>
> xcairo push, redacted drag, and drop:
>
> software@raven> ./x01c -dev xcairo -locate
> PLplot library version: 5.11.1
> subwin = 0, wx = 1.470581,  wy = 25.565071, dx = 0.177778,  dy = 0.820370
> keysym = 0x20, button = 0x01, string = 'button 1', type = 0x00, state = 0x00
> subwin = 0, wx = 1.494744,  wy = 25.366122, dx = 0.179167,  dy = 0.818519
> keysym = 0x20, button = 0x00, string = 'button 0', type = 0x00, state = 0x100
> [....]
> subwin = 0, wx = 1.591398,  wy = 24.570325, dx = 0.184722,  dy = 0.811111
> keysym = 0x20, button = 0x01, string = 'button 1', type = 0x00, state = 0x100
>
> The three kinds of events here are the push, the drag (repeated many
> times but redacted down to one) and the drop (the last record above).
>
> I actually like this better than the xwin result above because it does
> include the final drop event.  But for just push and release in the
> same place you just want one event.  So some care would be required to
> make push and release and push, drag, and drop report correctly for
> both -dev xwin and -dev xcairo.
>
> qtwidget push, redacted drag, and drop:
>
> software@raven> ./x01c -dev qtwidget -locate
> PLplot library version: 5.11.1
> subwin = 0, wx = 1.176425,  wy = 26.226949, dx = 0.159145,  dy = 0.825210
> keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x100
>
> For this case, only the push event is shown because the drag part and
> the final drop had all events masked out so the above was all the
> output there was.  So clearly some work needs to be done here to allow
> push, drag, and drop for -dev qtwidget to be reported similarly to
> what is available for -dev xcairo.
>
> wxwidgets push, redacted drag, and drop:
>
> software@raven> ./x01c -dev wxwidgets -locate
> PLplot library version: 5.11.1
> subwin = 0, wx = 0.487317,  wy = 33.354515, dx = 0.118952,  dy = 0.890267
> keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x100
>
> For this case, only the push event is shown because the drag part and
> the final drop had all events masked out so the above was all the
> output there was.  So clearly some work needs to be done here to allow
> push, drag, and drop for -dev wxwidgets to be reported similarly to
> what is available for -dev xcairo.
>
> III. Button identification codes mentioned by example 20.
>
> I think those are wrong since the second button mentioned in the
> example 20 message is actually button 3 (the right button) on my
> generic mouse with default mouse button identification according to
> the results contained in the PLGraphicsIn struct returned by
> plGetCursor.  And most people who think they only have a two button
> mouse forget that depressing the scroll wheel without spinning
> it constitutes button 2 while the right-hand button is button
> 3.
>
> @ Phil, Arjen, and Jim:
>
> To help explore the possibilities here, what does C example 1 in
> -locate mode tell Cygwin users about the 3 mice buttons I have
> described on most generic mice?  If the middle button (consisting of
> depressing the scroll wheel) has no effect on Cygwin with -dev xwin,
> then it means the Cygwin developers have not been able to extract any
> information about the mouse button from the Windows system, and it is
> possibly just not available there. On the other hand, if that
> experiment shows that -dev xwin on Cygwin notices events from that
> middle mouse button, then it means that information must be available
> on bare Windows (for the Cygwin X developers to harvest and pass on to
> -dev xwin), and so that means that same event information should be
> available to -dev wingcc for both the Cygwin and MSVC cases.
>
> My apologies this post was so long, but there was a lot of cut and
> paste information from C example 1 -locate mode to convey which I hope
> will be a big help in implementing proper interactivity for all our
> interactive devices.
>
> 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
> __________________________
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Correct implementation of key and button events in the interactive drivers

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

On 2016-01-11 19:41-0000 Arjen Markus wrote:

> Hi everyone,
>
>
>
> I am trying to get example x20f to work properly with the new Fortran bindings and the wingcc driver. The first part is working: I see the various fields of the structure PLGraphicsIn being filled with plausible values - so the Fortran bindings are working. However, there are two fields that are not set in line with the xwin driver:
>
> -        The button field: it seems the left button has value 1 and the right button should be value 3 - in the window the somewhat confusing message says to press "button 2". I guess this is due to mice classically used on UNIX/X Window systems have/had three buttons. That is a simple change to the wingcc driver.
>
> -        The state field: this is a bit more troublesome. I have no idea what it means. Nor what values it can assume. Can anyone enlighten me?

Hi Arjen:

You have opened up a whole lot of issues here, but I am glad you have
done so.  Furthermore, I suggest you keep the issues as separated
as possible from each other by, for example, debugging wingcc
interactive issues with C examples only, and debugging the interactive
issues of the new Fortran examples/binding using -dev xwin alone
since that is our only device that has implemented interactivity
correctly so far, i.e., it is the only interactive device
on Linux that operates C example 20 and C example 01 with -xor example
option correctly.

@Phil (wxwidgets), @Jim (wingcc and your new extended version of that
you are developing), @ Arjen (wingcc if Jim does not get to it), and
those volunteers willing to support interactivity properly on xcairo
and qtwidgets.  This is a long post because of many cut and pasted
results from modified example 1 which are quite informative
netherless.  But please especially notice where the device you are
interested in is mentioned below, and please fix the several issues I
have identified for all such devices (other than xwin where the issues
are fairly minor).

Here are the issues that need to be dealt with.

I. C example 20 and the -xor example option for C example 01 are not
working correctly for most of our interactive devices.

For current master tip (commit 3f05b0b which includes all of Phil's
latest wxwidgets efforts), I find that with any of the xcairo,
qtwidget, or wxwidgets devices that examples/c/x20c simply skips
through the interactive part of the example with no chance to drag and
drop to select a part of the image to view like you get with the xwin
device.  Similarly, I find the -xor example option for examples/c/x01c
appears to be a nop-op for the xcairo, qtwidget, or wxwidgets devices
while the xwin device provides some interactive results (a symbol
visibly moving along one of the lines plotted).  Both these cases
depend critically on whether an interactive device has implemented xor
capability or not, but that may not be all the story because of
the push and release and push, drag, and drop issues that I
also note below.

If you search all driver code this way

grep -i xor drivers/* |less

then it appears that some attempt has been made to support xor mode
for cairo, wingcc, wxwidgets, and xwin, and it appears this
functionality does work properly for xwin but not for cairo and
wxwidgets, and I have not been able to test wingcc or Jim's device.
Note also, there currently seems to be not even an attempt
to support xor with our qtwidget device.

So implementation of working xor mode needs to be addressed by those
wanting to support proper device interactivity for wxwidgets, wingcc
(likely), Jim's device (likely), xcairo, and qtwidget.

II. Metadata returned by interactive events being processed by our
various interactive devices.

I have just now (commit 406d8cf) modified the -locate mode of C
example 01 to return complete information about all the fields in the
PLGraphicsIn struct returned by plGetCursor. This should vastly
improve our ability to diagnose interactive issues.

The results below also verify and enhance what Phil has said
in response to Arjen's question about state.

Here are results for a simple button push and release (without
dragging) for my left mouse, middle mouse (where you depress the
scroll wheel on a generic mouse that uses the Microsoft protocol), and
right mouse buttons followed by a simple push and release of the a, B,
C, and d buttons. I have confirmed in every case that the correct
subwindow was identified by these results.

xwin push and release:

software@raven> ./x01c -dev xwin -locate
PLplot library version: 5.11.1
subwin = 0, wx = 2.155642,  wy = 18.765058, dx = 0.214087,  dy = 0.756677
keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x00
subwin = 1, wx = 0.355375,  wy = 0.019289, dx = 0.712697,  dy = 0.770030
keysym = 0x20, button = 0x02, string = '', type = 0x00, state = 0x00
subwin = 2, wx = 2.085808,  wy = 0.313648, dx = 0.211307,  dy = 0.232938
keysym = 0x20, button = 0x03, string = '', type = 0x00, state = 0x00
subwin = 0, wx = 1.547419,  wy = 15.049218, dx = 0.177943,  dy = 0.724036
keysym = 0x61, button = 0x00, string = 'a', type = 0x00, state = 0x00
subwin = 0, wx = 1.547419,  wy = 15.049218, dx = 0.177943,  dy = 0.724036
keysym = 0x42, button = 0x00, string = 'B', type = 0x00, state = 0x01
subwin = 0, wx = 1.547419,  wy = 15.049218, dx = 0.177943,  dy = 0.724036
keysym = 0x43, button = 0x00, string = 'C', type = 0x00, state = 0x01
subwin = 0, wx = 1.547419,  wy = 15.049218, dx = 0.177943,  dy = 0.724036
keysym = 0x64, button = 0x00, string = 'd', type = 0x00, state = 0x00

Evidently, xwin only pays attention to one of button/key press or
button/key release events but not both, and does not pay any attention
to the actual event corresponding to the push or release of the shift
key.  The shift key being pressed while a letter is pressed does
modify both the state result (which is changed to PL_MASK_SHIFT), the
keysym, and the resulting string of the event associated with
the non-modifying key.  And similarly when capslock is on
you get a corresponding change in the state to PL_MASK_CAPS and
corresponding changes in keysym and string.  I think all these
constraints are a good model of what other devices should do since
enough information is delivered that xwin knows how to handle the
interactive aspects of example 01 and 20 while the other devices do
not because they deliver information about too many events (xcairo)
or too few events (qtwidget, wxwidgets).

However, that said, I would like to see a minor xwin change so that it
always fills in string and state for the button case like xcairo does
instead of the current result for that case where string is empty and
state is 0x00.

xcairo push and release:

software@raven> ./x01c -dev xcairo -locate
PLplot library version: 5.11.1
subwin = 0, wx = 2.292135,  wy = 20.790289, dx = 0.225000,  dy = 0.775926
keysym = 0x20, button = 0x01, string = 'button 1', type = 0x00, state = 0x00
subwin = 0, wx = 2.292135,  wy = 20.790289, dx = 0.225000,  dy = 0.775926
keysym = 0x20, button = 0x01, string = 'button 1', type = 0x00, state = 0x100
subwin = 1, wx = 0.329669,  wy = 0.019185, dx = 0.706944,  dy = 0.746296
keysym = 0x20, button = 0x02, string = 'button 2', type = 0x00, state = 0x00
subwin = 1, wx = 0.329669,  wy = 0.019185, dx = 0.706944,  dy = 0.746296
keysym = 0x20, button = 0x02, string = 'button 2', type = 0x00, state = 0x200
subwin = 2, wx = 5.603909,  wy = 0.612271, dx = 0.313889,  dy = 0.294444
keysym = 0x20, button = 0x03, string = 'button 3', type = 0x00, state = 0x00
subwin = 2, wx = 5.603909,  wy = 0.612271, dx = 0.313889,  dy = 0.294444
keysym = 0x20, button = 0x03, string = 'button 3', type = 0x00, state = 0x400
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0x61, button = 0x26, string = 'a', type = 0x00, state = 0x00
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0x61, button = 0x26, string = 'a', type = 0x00, state = 0x00
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0xffe1, button = 0x32, string = 'Shift_L', type = 0x00, state = 0x00
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0x42, button = 0x38, string = 'B', type = 0x00, state = 0x01
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0x42, button = 0x38, string = 'B', type = 0x00, state = 0x01
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0xffe1, button = 0x32, string = 'Shift_L', type = 0x00, state = 0x01
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0xffe1, button = 0x32, string = 'Shift_L', type = 0x00, state = 0x00
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0x43, button = 0x36, string = 'C', type = 0x00, state = 0x01
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0x43, button = 0x36, string = 'C', type = 0x00, state = 0x01
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0xffe1, button = 0x32, string = 'Shift_L', type = 0x00, state = 0x01
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0x64, button = 0x28, string = 'd', type = 0x00, state = 0x00
subwin = 0, wx = 2.485441,  wy = 20.989239, dx = 0.236111,  dy = 0.777778
keysym = 0x64, button = 0x28, string = 'd', type = 0x00, state = 0x00

N.B. Evidently xcairo marks both push and release events for buttons,
character keys and even modifying keys like Shift_L, and the only
difference for buttons is the state which on release is set to the
correct PL_MASK_BUTTON[1-3].  There is no difference in push and
release events for both ordinary and modifying keys.  I believe there
are way too many events being reported here, and that may be confusing
interactive results for -dev xcairo.  Therefore, I would strongly
advise our volunteer supporter of xcairo that the noted events should
be masked down to just one of push or release (with state set to
PL_MASK_BUTTON[1-3] for events involving those mouse buttons) and
modifying character push or release should have no event reported for
it all. It is good that xcairo makes a special effort to fill in
string and state (at least on release) for button events, and I urge
that be done for all other devices as well.

qtwidget push and release:

software@raven> ./x01c -dev qtwidget -locate
PLplot library version: 5.11.1
subwin = 0, wx = 2.789786,  wy = 17.775337, dx = 0.252969,  dy = 0.747899
keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x100
subwin = 1, wx = 0.464964,  wy = 0.019220, dx = 0.752969,  dy = 0.754622
keysym = 0x20, button = 0x02, string = '', type = 0x00, state = 0x200
subwin = 2, wx = 4.343026,  wy = 0.565404, dx = 0.277910,  dy = 0.284034
keysym = 0x20, button = 0x03, string = '', type = 0x00, state = 0x400
subwin = 0, wx = 2.973587,  wy = 12.998339, dx = 0.263658,  dy = 0.704202
keysym = 0x00, button = 0x00, string = '', type = 0x00, state = 0x00
subwin = 0, wx = 2.994009,  wy = 12.814608, dx = 0.264846,  dy = 0.702521
keysym = 0x00, button = 0x00, string = '', type = 0x00, state = 0x00
subwin = 0, wx = 3.014431,  wy = 12.630877, dx = 0.266033,  dy = 0.700840
keysym = 0x00, button = 0x00, string = '', type = 0x00, state = 0x00
subwin = 0, wx = 3.014431,  wy = 12.630877, dx = 0.266033,  dy = 0.700840
keysym = 0x00, button = 0x00, string = '', type = 0x00, state = 0x00

This does follow the same limits as xwin in terms of what events are
noted which is good, but the amount of information supplied for each
event needs to be increased to what is supplied by xwin (supplemented
by the extra information I have asked for in that case).

wxwidgets push and release:

software@raven> ./x01c -dev wxwidgets -locate
PLplot library version: 5.11.1
subwin = 0, wx = 1.110958,  wy = 29.386613, dx = 0.155242,  dy = 0.854008
keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x100
subwin = 1, wx = 0.435386,  wy = 0.019594, dx = 0.742608,  dy = 0.842557
keysym = 0x20, button = 0x02, string = '', type = 0x00, state = 0x200
subwin = 2, wx = 0.948778,  wy = 0.218958, dx = 0.180780,  dy = 0.212786
keysym = 0x20, button = 0x03, string = '', type = 0x00, state = 0x400

Note, I started with a black window with no plots on it, but I guessed
at the first upper left location of the subwindow to push the left
mouse button and got the above good first event from that and so
forth.  By the last event the plot window was actually plotting.
Obviously, these symptoms indicate there is a rendering bug here in
locate mode that needs to be addressed.

That said, these limited button results are good except for the empty
string returned for these events (note that same comment for all other
devices than xcairo which does return a proper string for button
events).  However, key events (as opposed to button events) are masked
out for this device, and that substantial limitation should be
addressed.  (I have noted this deficiency before, but I keep
mentioning it each time I run into it for wxwidgets because
interactive astronomical research programmes I am familiar with do
heavily use key events as well as mouse button events, and I assume
there are a lot of other interactive programmes that do that as well.)

That terminates my push and release data for mouse buttons and a few
selected keys, but now I would like to follow up with push,
redacted drag and drop results for the left mouse button for each of the
interactive devices I have mentioned, where the redacted part is every
drag event after the first one which are identical to the first one
except for position.

xwin push, redacted drag and drop:

software@raven> ./x01c -dev xwin -locate
PLplot library version: 5.11.1
subwin = 0, wx = 1.282297,  wy = 23.832113, dx = 0.162187,  dy = 0.801187
keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x00
subwin = 0, wx = 1.297892,  wy = 23.663212, dx = 0.163114,  dy = 0.799703
keysym = 0x20, button = 0x00, string = '', type = 0x00, state = 0x100
[....]

Evidently, xwin identifies the button during the initial push, but
sets the button result to 0 during the subsquent drag event, but does
signal that event is going on with button 1 (the left mouse button in
my case) by producing the state result of 0x100 = PL_MASK_BUTTON1 for
a drag event.  (Just to satisfy my curiosity, I have also confirmed
state is PL_MASK_BUTTON2, and PL_MASK_BUTTON3 if the dragging is done
with button 2 [by pressing the scroll wheel for my mouse downward
without rotating it] or button 3 [the right mouse button in my case].)
Note that the final drop event is masked out.  I think that is a mistake
and the xcairo result below that includes that is what we should aim
for here.

xcairo push, redacted drag, and drop:

software@raven> ./x01c -dev xcairo -locate
PLplot library version: 5.11.1
subwin = 0, wx = 1.470581,  wy = 25.565071, dx = 0.177778,  dy = 0.820370
keysym = 0x20, button = 0x01, string = 'button 1', type = 0x00, state = 0x00
subwin = 0, wx = 1.494744,  wy = 25.366122, dx = 0.179167,  dy = 0.818519
keysym = 0x20, button = 0x00, string = 'button 0', type = 0x00, state = 0x100
[....]
subwin = 0, wx = 1.591398,  wy = 24.570325, dx = 0.184722,  dy = 0.811111
keysym = 0x20, button = 0x01, string = 'button 1', type = 0x00, state = 0x100

The three kinds of events here are the push, the drag (repeated many
times but redacted down to one) and the drop (the last record above).

I actually like this better than the xwin result above because it does
include the final drop event.  But for just push and release in the
same place you just want one event.  So some care would be required to
make push and release and push, drag, and drop report correctly for
both -dev xwin and -dev xcairo.

qtwidget push, redacted drag, and drop:

software@raven> ./x01c -dev qtwidget -locate
PLplot library version: 5.11.1
subwin = 0, wx = 1.176425,  wy = 26.226949, dx = 0.159145,  dy = 0.825210
keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x100

For this case, only the push event is shown because the drag part and
the final drop had all events masked out so the above was all the
output there was.  So clearly some work needs to be done here to allow
push, drag, and drop for -dev qtwidget to be reported similarly to
what is available for -dev xcairo.

wxwidgets push, redacted drag, and drop:

software@raven> ./x01c -dev wxwidgets -locate
PLplot library version: 5.11.1
subwin = 0, wx = 0.487317,  wy = 33.354515, dx = 0.118952,  dy = 0.890267
keysym = 0x20, button = 0x01, string = '', type = 0x00, state = 0x100

For this case, only the push event is shown because the drag part and
the final drop had all events masked out so the above was all the
output there was.  So clearly some work needs to be done here to allow
push, drag, and drop for -dev wxwidgets to be reported similarly to
what is available for -dev xcairo.

III. Button identification codes mentioned by example 20.

I think those are wrong since the second button mentioned in the
example 20 message is actually button 3 (the right button) on my
generic mouse with default mouse button identification according to
the results contained in the PLGraphicsIn struct returned by
plGetCursor.  And most people who think they only have a two button
mouse forget that depressing the scroll wheel without spinning
it constitutes button 2 while the right-hand button is button
3.

@ Phil, Arjen, and Jim:

To help explore the possibilities here, what does C example 1 in
-locate mode tell Cygwin users about the 3 mice buttons I have
described on most generic mice?  If the middle button (consisting of
depressing the scroll wheel) has no effect on Cygwin with -dev xwin,
then it means the Cygwin developers have not been able to extract any
information about the mouse button from the Windows system, and it is
possibly just not available there. On the other hand, if that
experiment shows that -dev xwin on Cygwin notices events from that
middle mouse button, then it means that information must be available
on bare Windows (for the Cygwin X developers to harvest and pass on to
-dev xwin), and so that means that same event information should be 
available to -dev wingcc for both the Cygwin and MSVC cases.

My apologies this post was so long, but there was a lot of cut and
paste information from C example 1 -locate mode to convey which I hope
will be a big help in implementing proper interactivity for all our
interactive devices.

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] Correct implementation of key and button events in the interactive drivers

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

Hi Arjen
I sorted the wxWidgets version of this out just before Christmas and
updated the rather deficient documentation. If you build the latest
docs, you will find a description of PlGraphicsIn on page 175. I also
added demonstration functionality of mouse capture to the wxWidgets
demo, so if you have a look at that then it will probably help. Look
at wxPLplotwindow<WXWINDOW>::OnMouse which is called when a mouse
button is released over the window or when the mouse moves over the
window, although I didn't process just movement anywhere yet, but I
thought it would be useful to put plot coordinates in a status bar at
the bottom of the window as you move the mouse over points.

To answer your specifics the state variable should be filled with
details of not only the mouse buttons, but also any special keys that
are pressed or locks that are on (e.g. shift, ctrl, num lock, caps
lock etc). I added a series of masks to ensure these were defined
internally rather than relying on comments referring to x11.h, they
all begin PL_MASK_. It appears to me that the button field is not
really needed as there is a PL_MASK_BUTTON1, PL_MASK_BUTTON2, etc in
the state field - these were already being filled in by the x11 driver
based on values from X11.h

By the way there are up to 5 mouse buttons I think. left, right middle
(1, 2, 3) and two extra - I've never had a mouse with them, but I
think they are usually by your thumb. I'm not sure if plgetcursor is
also supposed to capture key presses. This might interfere with
keyboard shortcuts for page advances etc. The docs for plgetcursor
says captures "graphics input events" which isn't exactly clear. But I
guess that is what the keysym field is for?

Phil

Phil

On 11 January 2016 at 19:41, Arjen Markus <Arj...@de...> wrote:
> Hi everyone,
>
>
>
> I am trying to get example x20f to work properly with the new Fortran
> bindings and the wingcc driver. The first part is working: I see the various
> fields of the structure PLGraphicsIn being filled with plausible values – so
> the Fortran bindings are working. However, there are two fields that are not
> set in line with the xwin driver:
>
> -        The button field: it seems the left button has value 1 and the
> right button should be value 3 – in the window the somewhat confusing
> message says to press “button 2”. I guess this is due to mice classically
> used on UNIX/X Window systems have/had three buttons. That is a simple
> change to the wingcc driver.
>
> -        The state field: this is a bit more troublesome. I have no idea
> what it means. Nor what values it can assume. Can anyone enlighten me?
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
>
>
>
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is strictly
> prohibited. The foundation 'Stichting Deltares', which has its seat at
> Delft, The Netherlands, Commercial Registration Number 41146461, is not
> liable in any way whatsoever for consequences and/or damages resulting from
> the improper, incomplete and untimely dispatch, receipt and/or content of
> this e-mail.
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] Correct implementation of key and button events in the interactive drivers

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

Hi everyone,



I am trying to get example x20f to work properly with the new Fortran bindings and the wingcc driver. The first part is working: I see the various fields of the structure PLGraphicsIn being filled with plausible values - so the Fortran bindings are working. However, there are two fields that are not set in line with the xwin driver:

-        The button field: it seems the left button has value 1 and the right button should be value 3 - in the window the somewhat confusing message says to press "button 2". I guess this is due to mice classically used on UNIX/X Window systems have/had three buttons. That is a simple change to the wingcc driver.

-        The state field: this is a bit more troublesome. I have no idea what it means. Nor what values it can assume. Can anyone enlighten me?



Regards,



Arjen






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

Re: [Plplot-devel] Uisng plplot with wxwidgets and vs 2015

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

Hi Laurent
I am unfortunately so far unable to reproduce your error. I have tried
checking out the same commit that you have and still I do not see the
same error

I can only think that this must be something to do with the new
version of wxWidgets. I will try to look into it further, but I am not
sure exactly when I will be able to upgrade to that version. Hopefully
later this week.

However, later on the 22nd Dec - the same day you checked out your
version of PLPlot, I changed the destructor of wxPLplotwindow to
virtual, which it should have been all the time, because wxWidgets is
probably deleting it via a wxWindow * pointer. There is a chance this
may have fixed your issue. Can you please check out the latest version
of from the git repo and let me know if you still have the same
problem.

If the problem persists can I just confirm that you are getting the
second stack trace twice identically? If you are then that is very
strange as it means that  plend() is getting called twice somehow.

Also it is worth noting that I have just made some commits that fix
some not quite correct aspect ratio problems that the wxWidgets driver
was having (although I'm not sure if they existed when you pass a wxDC
in, maybe just when run from non-wxWidgets apps).

Phil

On 9 January 2016 at 09:11, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Laurent
> I am working with wxWidgets 3.0.2. Perhaps there have been some changes.
>
> However, looking at your two stack traces I think there is a plplot problem.
> It looks like the wxPlplotwindow destructor is being called twice, once by
> plplot and once by wxWidgets.
>
> I will look at this today and get back to you asap.
>
> Phil
> ________________________________
> From: Laurent Berger
> Sent: ‎08/‎01/‎2016 21:35
> To: Phil Rosenberg
> Subject: Re: [Plplot-devel] Uisng plplot with wxwidgets and vs 2015
>
> Hi phil
>
> i use git from git://git.code.sf.net/p/plplot/plplot
> Using git log I have got this :
> commit b90635d9fcba816f5bdd75c547c18bfe25d67ec0
> Author: Phil Rosenberg <p.d...@gm...>
> Date:   Tue Dec 22 11:52:17 2015 +0000
> I'm working too with windows 10
>
> my wxWidgets is 3.1.0 with last commit from 8 jan 2016
>
> Le 08/01/2016 22:24, Phil Rosenberg a écrit :
>
> Hi Laurent
> Are you using the latest development version or the latest release version?
>
> I have also just swapped to VS2015 and the current development version I
> working for me on Windows 10.
> ________________________________
> From: Laurent Berger
> Sent: ‎08/‎01/‎2016 20:23
> To: plp...@li...
> Subject: [Plplot-devel]  Uisng plplot with wxwidgets and vs 2015
>
> Hi,
>
> I want to use VS2015 now with wxwidgets and plplot. When I wxPlplotDemo
> It works fine until I press close box. An exception occurs at line 273
> wxWidgets-3.1.0/src/common/dcgraph.cpp stack. When I set a breakpoint at
> line 273 in dcgraph.cpp stack trace for first call
>>    wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
>       [Code externe]
>       wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
>       wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
>       [Code externe]
> wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>()
> Ligne 110    C++
>       [Code externe]
>       wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne
> 637    C++
>       wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
>       wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
>       wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
>       wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
>       wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
>       wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
>       wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
>       wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
>       wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne
> 503    C++
>       wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne
> 181    C++
>       wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
> __formal, char * __formal, int nCmdShow) Ligne 290    C++
>       wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
> hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
>       [Code externe]
>
> If i go on debugging I reach break point twice with this statck trace
>
>>    wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
>       [Code externe]
>       wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
>       wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
>       [Code externe]
>       wxPLplotDemo.exe!wxPLDevice::~wxPLDevice() Ligne 543    C++
>       [Code externe]
>       wxPLplotDemo.exe!plD_tidy_wxwidgets(PLStream * pls) Ligne 383    C++
>       wxPLplotDemo.exe!plP_tidy() Ligne 235    C
>       wxPLplotDemo.exe!c_plend1() Ligne 2528    C
>       wxPLplotDemo.exe!plstream::~plstream() Ligne 347    C++
>       wxPLplotDemo.exe!wxPLplotstream::~wxPLplotstream() Ligne 91 C++
> wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>()
> Ligne 111    C++
>       [Code externe]
>       wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne
> 637    C++
>       wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
>       wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
>       wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
>       wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
>       wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
>       wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
>       wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
>       wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
>       wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne
> 503    C++
>       wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne
> 181    C++
>       wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ *
> __formal, char * __formal, int nCmdShow) Ligne 290    C++
>       wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ *
> hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
>       [Code externe]
>
> An if press step exception occurs this->m_graphicContexthas been
> 0xFFFFFFFFFFF7...
>
> With VS 2013 there is no problem and setting breakpoint at same point
> this breakpoint is reach only once.
> I have build plplot with static lib and shared  lib  using release or
> debug mode and that's change nothing.
>
> Have you got an idea to help me solving  this problem?
>
> Thanks in advance
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
>

Re: [Plplot-devel] Example 19 differences for Tcl

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Sunday, January 10, 2016 4:06 AM
> To: Arjen Markus; PLplot development list
> Subject: Example 19 differences for Tcl
>
> Hi Arjen:
>
> I was just now able to complete a comprehensive test of master tip using
>
> scripts/comprehensive_test.sh --cmake_added_options \ "-
> DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -
> DDEFAULT_NO_BINDINGS=ON \ -DENABLE_cxx=ON -DENABLE_f95=ON -
> DENABLE_java=ON -DENABLE_python=ON \ -DENABLE_tcl=ON -
> DENABLE_lua=ON" --do_test_interactive no
>
> (I limited the test this way in the interests of speed.)  For all
> 12 components of this comprehensive test, the PostScript diff results were
> consistent.  They were also perfect for all the above bindings other than the Tcl one
> which had the following summary (12 different
> times):
>
> tcl
>    Missing examples            :
>    Differing graphical output  :  19
>    Missing stdout              :
>    Differing stdout            :
>
> Further investigation showed those example 19 differences were primarily due to
> missing contour lines and roads? on the fifth
> (shapelib) page of the Tcl plot.  I do know the other above bindings produce the
> same as the C result for example 19 for the recent plmap library changes so I don't
> see how the Tcl result could be affected differently than the others. Anyhow, once
> you do install shapelib on Cygwin (probably after we finish the new Fortran binding
> since it is probably not a good idea to change your platform right in the middle of
> working on that), I would appreciate you (a) attempting to verify this issue, and (b)
> debugging this issue assuming you verify it.
>

That is odd, because nothing has changed as far as I know since the last release in this area.

> But also note that the master tip Fortran binding and Fortran example
> 19 do produce the same result as C so that will be my goal also when finishing up
> the new Fortran binding (in the next few days I hope).
>


Yes, I will have a look at this once the Fortran work is done. Right now on my machine such differences are hidden by the fact that Cygwin installation is currently missing the shapelib library.

Regards,

Arjen

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

[Plplot-devel] Comprehensive noninteractive test results

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

For those of you aware I was having some hardware difficulties with my
computer those now all seem to be sorted.  For example, I just now
completed on my Debian jessie platform a comprehensive noninteractive
test of the tip of the git master branch for PLplot using

scripts/comprehensive_test.sh --do_test_interactive no

which took 81 minutes to complete.

Every noninteractive component of PLplot that is possible on Linux was
tested by this command and the results for the 12 different
combinations of 3 overall configurations and 4 different kinds of
comprehensive tests per configuration gave consistent results (which
was not the case when my hardware was wonky).  The only non-perfect
set of consistent results for the PostScript differences were the Tcl
ones for example 19 that I have already mentioned this evening and
also the following ones which have all been with us for a long time:

ada
   Missing examples            :
   Differing graphical output  :  08 19
   Missing stdout              :
   Differing stdout            : 
x28c
adathick
   Missing examples            :
   Differing graphical output  :  08 19
   Missing stdout              :
   Differing stdout            : 
ocaml
   Missing examples            :
   Differing graphical output  :  08 16 19 33
   Missing stdout              :
   Differing stdout            :

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] Example 19 differences for Tcl

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

Hi Arjen:

I was just now able to complete a comprehensive test of master tip
using

scripts/comprehensive_test.sh --cmake_added_options \
"-DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON  -DDEFAULT_NO_BINDINGS=ON \
-DENABLE_cxx=ON -DENABLE_f95=ON -DENABLE_java=ON -DENABLE_python=ON \
-DENABLE_tcl=ON -DENABLE_lua=ON" --do_test_interactive no

(I limited the test this way in the interests of speed.)  For all
12 components of this comprehensive test, the PostScript diff results
were consistent.  They were also perfect for all the above bindings
other than the Tcl one which had the following summary (12 different
times):

tcl
   Missing examples            :
   Differing graphical output  :  19
   Missing stdout              :
   Differing stdout            :

Further investigation showed those example 19 differences were
primarily due to missing contour lines and roads? on the fifth
(shapelib) page of the Tcl plot.  I do know the other above bindings
produce the same as the C result for example 19 for the recent plmap
library changes so I don't see how the Tcl result could be affected
differently than the others. Anyhow, once you do install shapelib on
Cygwin (probably after we finish the new Fortran binding since it is
probably not a good idea to change your platform right in the middle
of working on that), I would appreciate you (a) attempting
to verify this issue, and (b) debugging this issue assuming you
verify it.

But also note that the master tip Fortran binding and Fortran example
19 do produce the same result as C so that will be my goal also when
finishing up the new Fortran binding (in the next few days I hope).

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Plplot Source Error

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

On 2015-12-11 14:12-0800 Alan W. Irwin wrote:

> On 2015-12-11 12:59-0000 Phil Rosenberg wrote:
>
>> Hi Alan
>> My latest commit has fixed the missing plot. Your option 3 will need
>> some work. Currently shapelib is used if it is available regardless of
>> the situation with PL_DEPECATED.
>
> Hi Phil:
>
> I am sorry, but what I said before was misleading and therefore
> lead you into the following language propagation issue:
>
> The current examples/c/x19.c has conditionally compiled code in it,
> e.g.,
>
> #ifdef PL_USE_SHAPEFILES
>
> But that macro approach obviously only works for C and C+, and cannot
> be propagated to the rest of our supported languages.  So instead
> of using macros in the examples, we need the core library to
> handle all of this.

Hi Phil:

I have decided to go ahead and fix this issue since it affects all
platforms where shapelib is not available.  The result is all warning
messages are now emitted by the library rather than the examples, and
example 19 results for all languages should be the same as the
corresponding C results. For details please consult the commit message
at
<http://sourceforge.net/p/plplot/plplot/ci/aab6dd1adf692f7031643948dcb2d8ef7881cef1>.

Actually, I ask everyone here to read that commit message carefully to
make sure you are all willing to go along with the present new
build-system design for the three configuration cases that are
discussed.  Also, this commit needs testing on platforms other than
mine to make sure the results follow the new configuration design on
all platforms.

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] Uisng plplot with wxwidgets and vs 2015

[Laurent B. <lau...@un...>]

Hi,

I want to use VS2015 now with wxwidgets and plplot. When I wxPlplotDemo 
It works fine until I press close box. An exception occurs at line 273 
wxWidgets-3.1.0/src/common/dcgraph.cpp stack. When I set a breakpoint at 
line 273 in dcgraph.cpp stack trace for first call
 >    wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
      [Code externe]
      wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
      wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
      [Code externe]
wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>() 
Ligne 110    C++
      [Code externe]
      wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne 
637    C++
      wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
      wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
      wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
      wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
      wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
      wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
      wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
      wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
      wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne 
503    C++
      wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne 
181    C++
      wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ * 
__formal, char * __formal, int nCmdShow) Ligne 290    C++
      wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * 
hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
      [Code externe]

If i go on debugging I reach break point twice with this statck trace

 >    wxPLplotDemo.exe!wxGCDCImpl::~wxGCDCImpl() Ligne 273    C++
      [Code externe]
      wxPLplotDemo.exe!wxDC::~wxDC() Ligne 742    C++
      wxPLplotDemo.exe!wxGCDC::~wxGCDC() Ligne 122    C++
      [Code externe]
      wxPLplotDemo.exe!wxPLDevice::~wxPLDevice() Ligne 543    C++
      [Code externe]
      wxPLplotDemo.exe!plD_tidy_wxwidgets(PLStream * pls) Ligne 383    C++
      wxPLplotDemo.exe!plP_tidy() Ligne 235    C
      wxPLplotDemo.exe!c_plend1() Ligne 2528    C
      wxPLplotDemo.exe!plstream::~plstream() Ligne 347    C++
      wxPLplotDemo.exe!wxPLplotstream::~wxPLplotstream() Ligne 91 C++
wxPLplotDemo.exe!wxPLplotwindow<wxFrame>::~wxPLplotwindow<wxFrame>() 
Ligne 111    C++
      [Code externe]
      wxPLplotDemo.exe!wxAppConsoleBase::DeletePendingObjects() Ligne 
637    C++
      wxPLplotDemo.exe!wxAppConsoleBase::ProcessIdle() Ligne 445 C++
      wxPLplotDemo.exe!wxAppBase::ProcessIdle() Ligne 373    C++
      wxPLplotDemo.exe!wxEventLoopBase::ProcessIdle() Ligne 98    C++
      wxPLplotDemo.exe!wxEventLoopManual::DoRun() Ligne 263    C++
      wxPLplotDemo.exe!wxEventLoopBase::Run() Ligne 76    C++
      wxPLplotDemo.exe!wxAppConsoleBase::MainLoop() Ligne 380    C++
      wxPLplotDemo.exe!wxAppConsoleBase::OnRun() Ligne 302    C++
      wxPLplotDemo.exe!wxAppBase::OnRun() Ligne 312    C++
      wxPLplotDemo.exe!wxEntryReal(int & argc, wchar_t * * argv) Ligne 
503    C++
      wxPLplotDemo.exe!wxEntry(int & argc, wchar_t * * argv) Ligne 
181    C++
      wxPLplotDemo.exe!wxEntry(HINSTANCE__ * hInstance, HINSTANCE__ * 
__formal, char * __formal, int nCmdShow) Ligne 290    C++
      wxPLplotDemo.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * 
hPrevInstance, char * __formal, int nCmdShow) Ligne 129    C++
      [Code externe]

An if press step exception occurs this->m_graphicContexthas been 
0xFFFFFFFFFFF7...

With VS 2013 there is no problem and setting breakpoint at same point 
this breakpoint is reach only once.
I have build plplot with static lib and shared  lib  using release or 
debug mode and that's change nothing.

Have you got an idea to help me solving  this problem?

Thanks in advance

Re: [Plplot-devel] New Fortran binding: current statust

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

On 2016-01-08 08:21-0000 Arjen Markus wrote:

> Hi everyone,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:ir...@be...]
>> Sent: Thursday, January 07, 2016 3:50 AM
>>
>> That report has now been changed to
>>   f95
>>     Missing examples            :  19
>>     Differing graphical output  :  16
>>     Missing stdout              :
>>     Differing stdout            :
>>
>> where we are still evaluating why and where one of our recent commits introduced
>> a rendering bug (a small number of missing fills) in example 16.
>>

> Like I just mailed to Alan, the problem with example 16 has been
solved - you might say it was a one-off error, as a 1 should have been
a 0, but since C uses zeros and non-zeros as logical values, it was
actually an error in the logic. Since it was so small a mistake, it
took me a considerable time to actually spot it.

Hi Arjen:

I completely agree it is always the simple things that are the most
difficult to debug. So many thanks for finding and correcting the
source of 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] New Fortran binding: current status

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

Hi everyone,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Thursday, January 07, 2016 3:50 AM
>
> That report has now been changed to
>   f95
>     Missing examples            :  19
>     Differing graphical output  :  16
>     Missing stdout              :
>     Differing stdout            :
>
> where we are still evaluating why and where one of our recent commits introduced
> a rendering bug (a small number of missing fills) in example 16.
>
Like I just mailed to Alan, the problem with example 16 has been solved - you might say it was a one-off error, as a 1 should have been a 0, but since C uses zeros and non-zeros as logical values, it was actually an error in the logic. Since it was so small a mistake, it took me a considerable time to actually spot it.

Regards,

Arjen



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

Re: [Plplot-devel] New Fortran binding: current status

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

On 2016-01-01 14:29-0800 Alan W. Irwin wrote:

> Just to give you an update, that report now reads like this for the
> new Fortran binding project:
>
>  f95
>    Missing examples            :  16 19 20 21 22
>    Differing graphical output  :
>    Missing stdout              :
>    Differing stdout            :
>
> with perfect valgrind results for all non-missing examples as well.


That report has now been changed to
  f95
    Missing examples            :  19
    Differing graphical output  :  16
    Missing stdout              :
    Differing stdout            :

where we are still evaluating why and where one of our recent commits
introduced a rendering bug (a small number of missing fills) in
example 16.

But the big news is we have just discovered how to implement
full-blown callback functions in modern Fortran with a generic
user-defined type included in the argument lists to carry all the
extra data that is sometimes needed in a callback.  That model of
Fortran callback arguments (see the fifth kind of callback argument
processing in <http://www.fortran90.org/src/best-practices.html> is
exactly parallel to our current C practice and thus straightforward to
interoperate with what is done at the C level.  So that has huge
implications for all Fortran API whose corresponding C API has
callback arguments (i.e., plcont, plshade, plshades, plmap*,
plmeridian, plslabelfunc, plimagefr, plvect, and plstransform).
Before, (i.e., plcont, plshade, plshades) where we simply had extra xg
and yg arrays as arguments and hooked that up with the C pltr1 or
pltr2 callbacks, we can now have a proper Fortran callback where the
user has complete control of what data is part of the defined type
argument. And before (the rest of the callback functions) where users
were very limited in what data could be carried in Fortran callback
argument lists, now they have the prospect of including any data that
they need in a user-defined type argument.

So due to this realization that full callback capability is available
for modern Fortran, we are going to end up with a much more powerful
Fortran binding of PLplot.  And I don't think it will take me more than
a few extra days to get this all working.

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] Linux wxwidgets idle issue not solved for text- or line-dominatedplots

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

Oops. Here are the attachments which I meant to attach to the last post.

__________________________
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] Linux wxwidgets idle issue not solved for text- or line-dominatedplots

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

On 2016-01-06 16:35-0000 Phil Rosenberg wrote:

> You should now have a working version on Linux. It certainly seems to
> work on my CentOS machine.

Yep. Works fine here with no build or run-time problems other than the
idle issue(s) which I document below for this (commit 4677df1) version
of wxwidgets.

Here are the additional local changes I made to make example 00 pure
line graphics with no text, example 23 pure ascii text with no
graphics, and a given example (in this case example 00, but I
modified it to example 23 for the example 23 tests) is repeated 19
times (10 times for the example 23 case) when building the
test_c_<interactive device> target.

==================
diff --git a/examples/c/x00c.c b/examples/c/x00c.c
index aa4683c..1aaa4f2 100644
--- a/examples/c/x00c.c
+++ b/examples/c/x00c.c
@@ -44,8 +44,8 @@ main( int argc, const char *argv[] )
      plinit();

      // Create a labelled box to hold the plot.
-    plenv( xmin, xmax, ymin, ymax, 0, 0 );
-    pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
+    plenv( xmin, xmax, ymin, ymax, 0, -2 );
+    //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );

      // Plot the data that was prepared above.
      plline( NSIZE, x, y );
diff --git a/examples/c/x23c.c b/examples/c/x23c.c
index 5dddf3b..3b67a60 100644
--- a/examples/c/x23c.c
+++ b/examples/c/x23c.c
@@ -229,6 +229,7 @@ main( int argc, const char *argv[] )

      plinit();

+#if 0
      for ( page = 0; page < 11; page++ )
      {
          pladv( 0 );
@@ -292,6 +293,7 @@ main( int argc, const char *argv[] )
      printf( "For example 23 prior to page 12 the FCI is 0x%x\n", fci_old );
      printf( "For example 23 prior to page 12 the font family, style and weight are %s %s %s\n", family[ifamily], style[istyle], weight[iweight] );

+#endif
      for ( page = 11; page < 16; page++ )
      {
          PLFLT dy = 0.030;
diff --git a/plplot_test/test_c_interactive.sh.in b/plplot_test/test_c_interactive.sh.in
index 6e6ceea..3736a0a 100755
--- a/plplot_test/test_c_interactive.sh.in
+++ b/plplot_test/test_c_interactive.sh.in
@@ -27,12 +27,12 @@
  lang="c"
  export index lang

-if [ "$device" = "xcairo" -o "$device" = "qtwidget" ] ; then
+if [ "$device" = "xcairo1" -o "$device" = "qtwidget1" ] ; then
      # Temporarily drop example 17 for xcairo and qtwidget because those drivers are
      # so horribly slow for such interactive plots.
      INDEX="01 04 08 14 16 24 30"
  else
-    INDEX="01 04 08 14 16 17 24 30"
+    INDEX="00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "
  fi
  for index in $INDEX; do
      if [ "$verbose_test" ] ; then
==================

Please look at the attached screenshots of results from my system
monitor.  The only relevant part to look at is the cpu history, and
all these results were obtained by running X on the same computer
where the desktop software was running.

I. Pure line graphics results from 19 repetitions of modified example 00.

Ia. Comments on screenshot_others00.png

The three major peaks here correspond to building the three separate
targets test_c_xwin, test_c_xcairo, and test_c_qtwidget.  Each of
these targets completes the 19 runs of modified example 00 in
respectively 2.5, 2.9, and 4.0 seconds.  These numbers are confirmed
by the relative width of each of the major 3 peaks.

Ib. Comments on screenshot_wxwidgets00.png

This is my primary evidence of the idle problem(s) for a pure line
graphics case (modified 00 example).

This cpu history corresponds to several minutes of building the
test_c_wxwidgets target for the second time (so that all prerequisites
are built, and everything relevant is in memory).

The initial large peak corresponds to the cpu time that cmake requires
to run through all the dependencies of the target to insure they have
all been built.  That peak is then followed by 11 more peaks as -dev
wxwidgets runs through 11 of the 19 example 00 repetitions before I
had to take the screenshot so as not to miss the first peak.  You can
see for each of these examples both my cpus are engaged, and a given
repetition consists of mostly idle time of wildly different durations
with one modest peak of cpu(s) activity per repetition.  It turns out
these modest peaks correspond to exactly when the wxPLViewer GUI is
visible on the screen (although it just displays a black screen during
that time because of the -np issue with wxPLViewer). From the random
duration of the idle times for each repetition the figure for the
total time that all 19 repetitions take is quite variable. However,
the one time I had the patience to measure the time required for the
full 19 the result was 467 (!) seconds which is more than two orders
of magnitude larger than corresponding example 00 results for three
other interactive devices that I give above.

II. Pure ascii text results from 10 repetitions of modified example 23.

IIa. Comments on screenshot_others23.png

The three major peaks here correspond to building the three separate
targets test_c_xwin, test_c_xcairo, and test_c_qtwidget.  Each of
these targets completes 10 runs of modified example 23 in
respectively 3.3, 4.3, and 5.4 seconds.  These numbers are confirmed
by the relative width of each of the major 3 peaks.

Comments on screenshot_wxwidgets23.png

This is my primary evidence of the idle problem(s) for a pure ascii text
case (modified 23 example).

This cpu history corresponds to several minutes of building the
test_c_wxwidgets target for the second time (so that all prerequisites
are built, and everything relevant is in memory).

The initial large peak (all of which is clipped off on the left except
for the trailing part) corresponds to the cpu time that cmake requires
to run through all the dependencies of the target to insure they have
all been built.  That peak is then followed by 8 more peaks as -dev
wxwidgets runs through 8 of the 10 example 23 repetitions before I had
to take the screenshot so as not to miss all of the first peak.  The
remarks I made concerning variability of idle time, coincidence of the
peaks with GUI display for screenshot_wxwidgets00.png all apply for
this case as well. The one time I measured the time required for the
full 10 repetitions the result was 113 seconds or more than an order
of magnitude more than the corresponding example 23 results for three
other interactive devices that I give above, but almost an order of
magnitude less than the modified example 00 case for wxwidgets.

In sum, it appears that we may have at least two separate idle issues
left on Linux for -dev wxwidgets since the time required to get
through the repeated modified x00 example is roughly equivalent to the
corresponding time taken for the repeated x23 example for the other
interactive devices, but almost an order of magnitude slower for
repeated x00 versus repeated x23 for the wxwidgets device.

So the biq question is can you replicate these results (at least the
one or two order of magnitude differences in relative total times
involved to run these various targets) on your own two Linux systems
or are they idiosyncratic to my Debian jessie platform?

Assuming you can replicate, then good luck on the bug hunt to find
the source of these Linux idle issues.

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] Linux wxwidgets idle issue not solved for text- or line-dominatedplots

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

On 2016-01-05 14:13-0000 Phil Rosenberg wrote:

> Hi Alan
> After posting on the wx forum, I realised I had the full wx sourcecode
> (including wxGTK) on my system from their Git repo. A quick scan seems
> to have revealed the issue. Could you try the following test for me?
> In wxWidgets_dev.cpp on line 443, could you change wxBITMAP_SCREEN_DEPTH to 24.
>
> I think the problem is that when creating the bitmap on Linux,
> wxWidgets tries to get the screen depth from the top level window,
> which doesn't exist in this case, whereas on Windows it creates a
> screen dc and uses this to get the depth. If the fix above works I'll
> report it as a wxWidgets bug.
>

Sorry, but that temporary fix did not work.  Here is the valgrind
result (in case you spot anything different from this change).

software@raven> valgrind examples/c/x00c -dev wxwidgets
==13810== Memcheck, a memory error detector
==13810== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==13810== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==13810== Command: examples/c/x00c -dev wxwidgets
==13810==

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_width: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_height: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_width_mm: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_height_mm: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_width: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_height: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_width_mm: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_height_mm: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:13810): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:13810): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:13810): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed

(process:13810): Gdk-CRITICAL **: IA__gdk_window_new: assertion 'GDK_IS_WINDOW (parent)' failed
==13810== Invalid read of size 8
==13810==    at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==13810==    by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==13810==    by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==13810==    by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==13810==    by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==13810==    by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==13810==    by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7C54469: wxNativeFontInfo::GetFamily() const (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7C85650: wxFont::wxFont(wxNativeFontInfo const&) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7C93903: wxSystemSettingsNative::GetFont(wxSystemFont) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7DEACE9: wxStockGDI::GetFont(wxStockGDI::Item) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7C757E2: wxGTKDCImpl::wxGTKDCImpl(wxDC*) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==13810== 
==13810== 
==13810== Process terminating with default action of signal 11 (SIGSEGV)
==13810==  Access not within mapped region at address 0x18
==13810==    at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==13810==    by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==13810==    by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==13810==    by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==13810==    by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==13810==    by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==13810==    by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7C54469: wxNativeFontInfo::GetFamily() const (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7C85650: wxFont::wxFont(wxNativeFontInfo const&) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7C93903: wxSystemSettingsNative::GetFont(wxSystemFont) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7DEACE9: wxStockGDI::GetFont(wxStockGDI::Item) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==    by 0x7C757E2: wxGTKDCImpl::wxGTKDCImpl(wxDC*) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==13810==  If you believe this happened as a result of a stack
==13810==  overflow in your program's main thread (unlikely but
==13810==  possible), you can try to increase the size of the
==13810==  main thread stack using the --main-stacksize= flag.
==13810==  The main thread stack size used in this run was 8388608.
==13810== 
==13810== HEAP SUMMARY:
==13810==     in use at exit: 430,557 bytes in 3,390 blocks
==13810==   total heap usage: 5,092 allocs, 1,702 frees, 1,206,877 bytes allocated
==13810== 
==13810== LEAK SUMMARY:
==13810==    definitely lost: 0 bytes in 0 blocks
==13810==    indirectly lost: 0 bytes in 0 blocks
==13810==      possibly lost: 42,408 bytes in 554 blocks
==13810==    still reachable: 373,069 bytes in 2,737 blocks
==13810==         suppressed: 0 bytes in 0 blocks
==13810== Rerun with --leak-check=full to see details of leaked memory
==13810== 
==13810== For counts of detected and suppressed errors, rerun with: -v
==13810== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

One issue with your temporary fix on my system could be if the X server does not
actually have a color depth of 24.  But I double-checked that by
running the xwininfo command which gave "Depth: 24" both when
running on a thin client (X-terminal) with the local X server
interacting with desktop software running on a remote fast computer
OR when running the local X server on the same computer where
the desktop software is running.

Note the above segfault result was for the direct use of desktop
software, but I also got a segfault for the remote case as well.

I am perfectly happy to help out as much as possible by running tests
like this for you, but it is an inherently clumsy and slow process
(especially with the time zone difference between us which virtually
guarantees a day's delay between question and answer).  And there are
likely many more Linux tests you will want to run in the immediate
future as you gradually figure out the Linux idle issue(s).  And some
of the Linux issues I report to you may be because of some inadequacy
of my Debian jessie system.

So I suggest you would probably be much better served by taking the
time now to fix both your home Linux networking as well as getting
wxwidgets-3.0 built on the Linux box you have access to at work so
you have two Linux boxes where you can get essentially instant
feedback on your changes.

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] Linux wxwidgets idle issue not solved for text- or line-dominatedplots

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

On 2016-01-05 13:17-0000 Phil Rosenberg wrote:

> This is obviously a wxWidgets thing. In order to determine the size
of the text I need a device context to do the calculation with. On
windows there seems to be no problem creating a memory device context
within a console application. But on Linux gdk obviously doesn't like
it.

> I'll ask on the wxWidgets board if there is a workaround.

Hi Phil:

The wxWidgets library does purport to be cross-platform so I would 
be surprised if there was not some easy way of doing what you
want to do that works on both Windows and Linux.

[out of order]
> Do you want me to revert the commit?

Not urgently, but probably by this weekend if no solution can be found.

The effect of the commit on Linux is interactive tests will not be
able to finish unless wxwidgets is specifically disabled.  So this
does have some impact on those attempting to use master tip (although
it is not nearly as severe as a build issue). For build issues that
cannot be instantly resolved, I would revert the offending commit
almost immediately. For run-time issues like this, we can be a little
more relaxed about the urgency of reverting the change.

By the way, the "git diff" command (to create a patch) and "git am
--reverse" command to remove the change in that patch should help you
make that public commit that removes your change.  That method allows
you to preserve the patch (or even commit it on a private topic branch
with the aid of "git am") for future reference in case a method is
found in the long term to make a slightly modified version of this
approach work on Linux.

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] Linux wxwidgets idle issue not solved for text- or line-dominatedplots

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

Hi Alan
After posting on the wx forum, I realised I had the full wx sourcecode
(including wxGTK) on my system from their Git repo. A quick scan seems
to have revealed the issue. Could you try the following test for me?
In wxWidgets_dev.cpp on line 443, could you change wxBITMAP_SCREEN_DEPTH to 24.

I think the problem is that when creating the bitmap on Linux,
wxWidgets tries to get the screen depth from the top level window,
which doesn't exist in this case, whereas on Windows it creates a
screen dc and uses this to get the depth. If the fix above works I'll
report it as a wxWidgets bug.

If this fix works then please feel free to commit it so we get things
working again as soon as possible.


Phil


On 5 January 2016 at 13:17, Phil Rosenberg <p.d...@gm...> wrote:
> Thanks Alan
> Do you want me to revert the commit?
>
> This is obviously a wxWidgets thing. In order to determine the size of the
> text I need a device context to do the calculation with. On windows there
> seems to be no problem creating a memory device context within a console
> application. But on Linux gdk obviously doesn't like it.
>
> I'll ask on the wxWidgets board if there is a workaround.
>
> Phil
> ________________________________
> From: Alan W. Irwin
> Sent: ‎04/‎01/‎2016 20:13
> To: Phil Rosenberg
> Cc: PLplot development list
> Subject: Re: Linux wxwidgets idle issue not solved for text- or
> line-dominatedplots
>
> On 2016-01-04 12:46-0000 Phil Rosenberg wrote:
>
>> Hi Alan
>> I have just committed a change that deals with getting text size
>> without two-way communication between the viewer and the driver. The
>> text size is now performed entirely within the driver.
>>
>> This significantly improves the qualitative responsiveness of running
>> the examples. To compare, on my Windows system I created a shell
>> script that just ran examples  01, 04, 08, 14, 16, 24 and 30 using
>> -dev wxWidgets -np and another script that was identical but used -dev
>> null Running these under Cygwin bash using time ./nameofscript.sh gave
>> the following
>>
>> pre commit with -dev wxwidgets
>> real    0m17.248s
>> user    0m0.060s
>> sys     0m0.262s
>>
>> post commit with -dev wxWidgets
>> real    0m7.709s
>> user    0m0.076s
>> sys     0m0.260s
>>
>> with -dev null
>> real    0m4.060s
>> user    0m0.061s
>> sys     0m0.292s
>>
>> So this has given more than a factor of two improvement for those
>> examples and results in a time which is approximately a factor of two
>> longer than doing no rendering at all. I would personally be quite
>> happy with that given the overheads involved in executing the extra
>> process and setting up the shared memory.
>>
>> I still haven't got easy access to my home Linux system as for some
>> reason it will no longer connect to the internet (but will connect to
>> the lan e.g. to load my router's setup page). I think I only have
>> wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a
>> sensible comparison. If you want to check things out on your Linux box
>> then please let me know the results.
>
> The above timing results seem promising indeed, but the changed
> version for current master tip (commit 10973c88c) segfaults here at
> run time.  Here are the relevant valgrind results for the compile flags
>
> software@raven> printenv |grep FL
> CXXFLAGS=-g
> CFLAGS=-g
> FFLAGS=-g
>
> to help improve line number feedback from valgrind
>
> software@raven> valgrind --num-callers=40 examples/c/x00c -dev wxwidgets
> ==2403== Memcheck, a memory error detector
> ==2403== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==2403== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==2403== Command: examples/c/x00c -dev wxwidgets
> ==2403==
>
> (process:2403): GLib-GObject-WARNING **: invalid (NULL) pointer instance
>
> (process:2403): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion
> 'G_TYPE_CHECK_INSTANCE (instance)' failed
>
> (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap:
> assertion 'GDK_IS_SCREEN (screen)' failed
>
> (process:2403): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion
> 'GDK_IS_COLORMAP (colormap)' failed
>
> (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap:
> assertion 'GDK_IS_SCREEN (screen)' failed
>
> (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion
> 'GDK_IS_SCREEN (screen)' failed
>
> (process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion
> 'GDK_IS_SCREEN (screen)' failed
>
> (process:2403): Gdk-CRITICAL **: IA__gdk_window_new: assertion
> 'GDK_IS_WINDOW (parent)' failed
> ==2403== Invalid read of size 8
> ==2403==    at 0x90D0859: gdk_window_enable_synchronized_configure (in
> /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
> ==2403==    by 0x8C6E1DD: ??? (in
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
> ==2403==    by 0x9CB8473: ??? (in
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
> ==2403==    by 0x9CD2086: g_signal_emit_valist (in
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
> ==2403==    by 0x9CD29DE: g_signal_emit (in
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
> ==2403==    by 0x8C62063: gtk_widget_realize (in
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
> ==2403==    by 0x7C5C0D9: ??? (in
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
> ==2403==    by 0x7C622A8: ??? (in
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
> ==2403==    by 0x7C6266D: wxBitmap::Create(int, int, int) (in
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
> ==2403==    by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int)
> (wxwidgets_dev.cpp:443)
> ==2403==    by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
> ==2403==    by 0x4E571E9: plP_init (plcore.c:144)
> ==2403==    by 0x4E5C6C7: c_plinit (plcore.c:2345)
> ==2403==    by 0x400A01: main (x00c.c:44)
> ==2403==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
> ==2403==
> ==2403==
> ==2403== Process terminating with default action of signal 11 (SIGSEGV)
> ==2403==  Access not within mapped region at address 0x18
> ==2403==    at 0x90D0859: gdk_window_enable_synchronized_configure (in
> /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
> ==2403==    by 0x8C6E1DD: ??? (in
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
> ==2403==    by 0x9CB8473: ??? (in
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
> ==2403==    by 0x9CD2086: g_signal_emit_valist (in
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
> ==2403==    by 0x9CD29DE: g_signal_emit (in
> /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
> ==2403==    by 0x8C62063: gtk_widget_realize (in
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
> ==2403==    by 0x7C5C0D9: ??? (in
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
> ==2403==    by 0x7C622A8: ??? (in
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
> ==2403==    by 0x7C6266D: wxBitmap::Create(int, int, int) (in
> /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
> ==2403==    by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int)
> (wxwidgets_dev.cpp:443)
> ==2403==    by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
> ==2403==    by 0x4E571E9: plP_init (plcore.c:144)
> ==2403==    by 0x4E5C6C7: c_plinit (plcore.c:2345)
> ==2403==    by 0x400A01: main (x00c.c:44)
> ==2403==  If you believe this happened as a result of a stack
> ==2403==  overflow in your program's main thread (unlikely but
> ==2403==  possible), you can try to increase the size of the
> ==2403==  main thread stack using the --main-stacksize= flag.
> ==2403==  The main thread stack size used in this run was 8388608.
> ==2403==
> ==2403== HEAP SUMMARY:
> ==2403==     in use at exit: 417,068 bytes in 3,235 blocks
> ==2403==   total heap usage: 4,711 allocs, 1,476 frees, 849,590 bytes
> allocated
> ==2403==
> ==2403== LEAK SUMMARY:
> ==2403==    definitely lost: 0 bytes in 0 blocks
> ==2403==    indirectly lost: 0 bytes in 0 blocks
> ==2403==      possibly lost: 41,636 bytes in 541 blocks
> ==2403==    still reachable: 363,912 bytes in 2,619 blocks
> ==2403==         suppressed: 0 bytes in 0 blocks
> ==2403== Rerun with --leak-check=full to see details of leaked memory
> ==2403==
> ==2403== For counts of detected and suppressed errors, rerun with: -v
> ==2403== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> Segmentation fault
>
> For what it is worth, this was all done with the C 00 example modified
> as follows to remove all text from the plot (because I decided to
> check your new commit with this non-text case first).
>
> index aa4683c..1aaa4f2 100644
> --- a/examples/c/x00c.c
> +++ b/examples/c/x00c.c
> @@ -44,8 +44,8 @@ main( int argc, const char *argv[] )
>       plinit();
>
>       // Create a labelled box to hold the plot.
> -    plenv( xmin, xmax, ymin, ymax, 0, 0 );
> -    pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
> +    plenv( xmin, xmax, ymin, ymax, 0, -2 );
> +    //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
>
>       // Plot the data that was prepared above.
>       plline( NSIZE, x, y );
>
>
> Let me know if there is any other experiment (i.e., a specific gdb run)
> that you need me to do to help you find and 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] Linux wxwidgets idle issue not solved for text- or line-dominatedplots

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

Thanks Alan
Do you want me to revert the commit?

This is obviously a wxWidgets thing. In order to determine the size of the text I need a device context to do the calculation with. On windows there seems to be no problem creating a memory device context within a console application. But on Linux gdk obviously doesn't like it.

I'll ask on the wxWidgets board if there is a workaround.

Phil

-----Original Message-----
From: "Alan W. Irwin" <ir...@be...>
Sent: ‎04/‎01/‎2016 20:13
To: "Phil Rosenberg" <p.d...@gm...>
Cc: "PLplot development list" <Plp...@li...>
Subject: Re: Linux wxwidgets idle issue not solved for text- or line-dominatedplots

On 2016-01-04 12:46-0000 Phil Rosenberg wrote:

> Hi Alan
> I have just committed a change that deals with getting text size
> without two-way communication between the viewer and the driver. The
> text size is now performed entirely within the driver.
>
> This significantly improves the qualitative responsiveness of running
> the examples. To compare, on my Windows system I created a shell
> script that just ran examples  01, 04, 08, 14, 16, 24 and 30 using
> -dev wxWidgets -np and another script that was identical but used -dev
> null Running these under Cygwin bash using time ./nameofscript.sh gave
> the following
>
> pre commit with -dev wxwidgets
> real    0m17.248s
> user    0m0.060s
> sys     0m0.262s
>
> post commit with -dev wxWidgets
> real    0m7.709s
> user    0m0.076s
> sys     0m0.260s
>
> with -dev null
> real    0m4.060s
> user    0m0.061s
> sys     0m0.292s
>
> So this has given more than a factor of two improvement for those
> examples and results in a time which is approximately a factor of two
> longer than doing no rendering at all. I would personally be quite
> happy with that given the overheads involved in executing the extra
> process and setting up the shared memory.
>
> I still haven't got easy access to my home Linux system as for some
> reason it will no longer connect to the internet (but will connect to
> the lan e.g. to load my router's setup page). I think I only have
> wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a
> sensible comparison. If you want to check things out on your Linux box
> then please let me know the results.

The above timing results seem promising indeed, but the changed
version for current master tip (commit 10973c88c) segfaults here at
run time.  Here are the relevant valgrind results for the compile flags

software@raven> printenv |grep FL
CXXFLAGS=-g
CFLAGS=-g
FFLAGS=-g

to help improve line number feedback from valgrind

software@raven> valgrind --num-callers=40 examples/c/x00c -dev wxwidgets
==2403== Memcheck, a memory error detector
==2403== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2403== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2403== Command: examples/c/x00c -dev wxwidgets
==2403==

(process:2403): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:2403): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_window_new: assertion 'GDK_IS_WINDOW (parent)' failed
==2403== Invalid read of size 8
==2403==    at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==2403==    by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403==    by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403==    by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7C622A8: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7C6266D: wxBitmap::Create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) (wxwidgets_dev.cpp:443)
==2403==    by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==2403==    by 0x4E571E9: plP_init (plcore.c:144)
==2403==    by 0x4E5C6C7: c_plinit (plcore.c:2345)
==2403==    by 0x400A01: main (x00c.c:44)
==2403==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==2403== 
==2403== 
==2403== Process terminating with default action of signal 11 (SIGSEGV)
==2403==  Access not within mapped region at address 0x18
==2403==    at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==2403==    by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403==    by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403==    by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7C622A8: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7C6266D: wxBitmap::Create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) (wxwidgets_dev.cpp:443)
==2403==    by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==2403==    by 0x4E571E9: plP_init (plcore.c:144)
==2403==    by 0x4E5C6C7: c_plinit (plcore.c:2345)
==2403==    by 0x400A01: main (x00c.c:44)
==2403==  If you believe this happened as a result of a stack
==2403==  overflow in your program's main thread (unlikely but
==2403==  possible), you can try to increase the size of the
==2403==  main thread stack using the --main-stacksize= flag.
==2403==  The main thread stack size used in this run was 8388608.
==2403== 
==2403== HEAP SUMMARY:
==2403==     in use at exit: 417,068 bytes in 3,235 blocks
==2403==   total heap usage: 4,711 allocs, 1,476 frees, 849,590 bytes allocated
==2403== 
==2403== LEAK SUMMARY:
==2403==    definitely lost: 0 bytes in 0 blocks
==2403==    indirectly lost: 0 bytes in 0 blocks
==2403==      possibly lost: 41,636 bytes in 541 blocks
==2403==    still reachable: 363,912 bytes in 2,619 blocks
==2403==         suppressed: 0 bytes in 0 blocks
==2403== Rerun with --leak-check=full to see details of leaked memory
==2403== 
==2403== For counts of detected and suppressed errors, rerun with: -v
==2403== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

For what it is worth, this was all done with the C 00 example modified
as follows to remove all text from the plot (because I decided to
check your new commit with this non-text case first).

index aa4683c..1aaa4f2 100644
--- a/examples/c/x00c.c
+++ b/examples/c/x00c.c
@@ -44,8 +44,8 @@ main( int argc, const char *argv[] )
      plinit();

      // Create a labelled box to hold the plot.
-    plenv( xmin, xmax, ymin, ymax, 0, 0 );
-    pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
+    plenv( xmin, xmax, ymin, ymax, 0, -2 );
+    //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );

      // Plot the data that was prepared above.
      plline( NSIZE, x, y );


Let me know if there is any other experiment (i.e., a specific gdb run)
that you need me to do to help you find and 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] Linux wxwidgets idle issue not solved for text- or line-dominated plots

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

On 2016-01-04 12:46-0000 Phil Rosenberg wrote:

> Hi Alan
> I have just committed a change that deals with getting text size
> without two-way communication between the viewer and the driver. The
> text size is now performed entirely within the driver.
>
> This significantly improves the qualitative responsiveness of running
> the examples. To compare, on my Windows system I created a shell
> script that just ran examples  01, 04, 08, 14, 16, 24 and 30 using
> -dev wxWidgets -np and another script that was identical but used -dev
> null Running these under Cygwin bash using time ./nameofscript.sh gave
> the following
>
> pre commit with -dev wxwidgets
> real    0m17.248s
> user    0m0.060s
> sys     0m0.262s
>
> post commit with -dev wxWidgets
> real    0m7.709s
> user    0m0.076s
> sys     0m0.260s
>
> with -dev null
> real    0m4.060s
> user    0m0.061s
> sys     0m0.292s
>
> So this has given more than a factor of two improvement for those
> examples and results in a time which is approximately a factor of two
> longer than doing no rendering at all. I would personally be quite
> happy with that given the overheads involved in executing the extra
> process and setting up the shared memory.
>
> I still haven't got easy access to my home Linux system as for some
> reason it will no longer connect to the internet (but will connect to
> the lan e.g. to load my router's setup page). I think I only have
> wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a
> sensible comparison. If you want to check things out on your Linux box
> then please let me know the results.

The above timing results seem promising indeed, but the changed
version for current master tip (commit 10973c88c) segfaults here at
run time.  Here are the relevant valgrind results for the compile flags

software@raven> printenv |grep FL
CXXFLAGS=-g
CFLAGS=-g
FFLAGS=-g

to help improve line number feedback from valgrind

software@raven> valgrind --num-callers=40 examples/c/x00c -dev wxwidgets
==2403== Memcheck, a memory error detector
==2403== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2403== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2403== Command: examples/c/x00c -dev wxwidgets
==2403==

(process:2403): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(process:2403): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed

(process:2403): Gdk-CRITICAL **: IA__gdk_window_new: assertion 'GDK_IS_WINDOW (parent)' failed
==2403== Invalid read of size 8
==2403==    at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==2403==    by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403==    by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403==    by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7C622A8: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7C6266D: wxBitmap::Create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) (wxwidgets_dev.cpp:443)
==2403==    by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==2403==    by 0x4E571E9: plP_init (plcore.c:144)
==2403==    by 0x4E5C6C7: c_plinit (plcore.c:2345)
==2403==    by 0x400A01: main (x00c.c:44)
==2403==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==2403== 
==2403== 
==2403== Process terminating with default action of signal 11 (SIGSEGV)
==2403==  Access not within mapped region at address 0x18
==2403==    at 0x90D0859: gdk_window_enable_synchronized_configure (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.25)
==2403==    by 0x8C6E1DD: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403==    by 0x9CB8473: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x9CD2086: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x9CD29DE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==2403==    by 0x8C62063: gtk_widget_realize (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.25)
==2403==    by 0x7C5C0D9: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7C622A8: ??? (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7C6266D: wxBitmap::Create(int, int, int) (in /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==2403==    by 0x7105092: wxPLDevice::wxPLDevice(PLStream*, char*, int, int) (wxwidgets_dev.cpp:443)
==2403==    by 0x7102754: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==2403==    by 0x4E571E9: plP_init (plcore.c:144)
==2403==    by 0x4E5C6C7: c_plinit (plcore.c:2345)
==2403==    by 0x400A01: main (x00c.c:44)
==2403==  If you believe this happened as a result of a stack
==2403==  overflow in your program's main thread (unlikely but
==2403==  possible), you can try to increase the size of the
==2403==  main thread stack using the --main-stacksize= flag.
==2403==  The main thread stack size used in this run was 8388608.
==2403== 
==2403== HEAP SUMMARY:
==2403==     in use at exit: 417,068 bytes in 3,235 blocks
==2403==   total heap usage: 4,711 allocs, 1,476 frees, 849,590 bytes allocated
==2403== 
==2403== LEAK SUMMARY:
==2403==    definitely lost: 0 bytes in 0 blocks
==2403==    indirectly lost: 0 bytes in 0 blocks
==2403==      possibly lost: 41,636 bytes in 541 blocks
==2403==    still reachable: 363,912 bytes in 2,619 blocks
==2403==         suppressed: 0 bytes in 0 blocks
==2403== Rerun with --leak-check=full to see details of leaked memory
==2403== 
==2403== For counts of detected and suppressed errors, rerun with: -v
==2403== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

For what it is worth, this was all done with the C 00 example modified
as follows to remove all text from the plot (because I decided to
check your new commit with this non-text case first).

index aa4683c..1aaa4f2 100644
--- a/examples/c/x00c.c
+++ b/examples/c/x00c.c
@@ -44,8 +44,8 @@ main( int argc, const char *argv[] )
      plinit();

      // Create a labelled box to hold the plot.
-    plenv( xmin, xmax, ymin, ymax, 0, 0 );
-    pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );
+    plenv( xmin, xmax, ymin, ymax, 0, -2 );
+    //pllab( "x", "y=100 x#u2#d", "Simple PLplot demo of a 2D line plot" );

      // Plot the data that was prepared above.
      plline( NSIZE, x, y );


Let me know if there is any other experiment (i.e., a specific gdb run)
that you need me to do to help you find and 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] Fwd: [Bug 1295175] New: plplot contain problematic content

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

On 2016-01-04 13:26-0000 Phil Rosenberg wrote:

> Sorry I appear to be filling this conversation with chaff. Can anyone
> enlighten me as to the (intended) meaning of this statement in our
> Copyright file
>
> Any file that has a explicit copyright notice may be distributed under
> the terms of both the LGPL and whatever stated conditions accompany the
> copyright.
>
> I have a feeling that this no longer applies and needs removing,
> perhaps it did apply when (if?) plplot only contained files that
> plplot contributors had written.

I have no idea why that phrase was included.  I think it is best that
you remove it.

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] Fwd: [Bug 1295175] New: plplot contain problematic content

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

Sorry I appear to be filling this conversation with chaff. Can anyone
enlighten me as to the (intended) meaning of this statement in our
Copyright file

Any file that has a explicit copyright notice may be distributed under
the terms of both the LGPL and whatever stated conditions accompany the
copyright.

I have a feeling that this no longer applies and needs removing,
perhaps it did apply when (if?) plplot only contained files that
plplot contributors had written.

Phil

Re: [Plplot-devel] Fwd: [Bug 1295175] New: plplot contain problematic content

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

> Assuming that legal theory is correct, then the only question for the
> data file is do we have the right to distribute it in modified (PPM,
> gray-scale) form?  And the CC license for the data file gives us that
> right assuming we note the licensing terms for that image file in our
> Copyright file.

Agreed. In fact I realised afterwards that the map example uses data
files that are freely distributable, but not GPL. I just checked and
these are actually not mentioned in our Copyright file, so I am about
to edit that so they are noted.

Re: [Plplot-devel] Linux wxwidgets idle issue not solved for text- or line-dominated plots

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

Hi Alan
I have just committed a change that deals with getting text size
without two-way communication between the viewer and the driver. The
text size is now performed entirely within the driver.

This significantly improves the qualitative responsiveness of running
the examples. To compare, on my Windows system I created a shell
script that just ran examples  01, 04, 08, 14, 16, 24 and 30 using
-dev wxWidgets -np and another script that was identical but used -dev
null Running these under Cygwin bash using time ./nameofscript.sh gave
the following

pre commit with -dev wxwidgets
real    0m17.248s
user    0m0.060s
sys     0m0.262s

post commit with -dev wxWidgets
real    0m7.709s
user    0m0.076s
sys     0m0.260s

with -dev null
real    0m4.060s
user    0m0.061s
sys     0m0.292s

So this has given more than a factor of two improvement for those
examples and results in a time which is approximately a factor of two
longer than doing no rendering at all. I would personally be quite
happy with that given the overheads involved in executing the extra
process and setting up the shared memory.

I still haven't got easy access to my home Linux system as for some
reason it will no longer connect to the internet (but will connect to
the lan e.g. to load my router's setup page). I think I only have
wxWidgets 2.8 on my work Linux machine so I need to build 3.0 to do a
sensible comparison. If you want to check things out on your Linux box
then please let me know the results.

Phil