plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Slave displays

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

I think I see how this works now.
Basically the example plots to both streams then execution halts while
it waits for the page to advance on the "master" plot. But this isn't
specifically due to coms between any of the streams, it is simply
because without setting plspause(0) execution hangs until the page
advances. Once enter is hit, the next page for both streams gets
rendered.

With wxWidgets however, when we reach the end of a page execution
doesn't stop. The plplot core code continues to execute and send the
commands to the wxPLViewer ready for rendering. This means the
execution just runs all the way through and the slave plot basically
disappears as it gets plotted.

I'm not sure this behaviour is documented specifically anywhere. We
can force execution to pause while we wait for a page advance to
happen I guess. It's just a question of whether we want that or
whether we would prefer to just plough through all the commands and
have them sat ready to execute.

Phil

On 2 October 2017 at 23:30, Alan W. Irwin <ir...@be...> wrote:
> On 2017-10-02 16:10+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>> I've been going through the various wxWidgets bugs on the bug tracker.
>> The ones that remain are the rather more technical ones or the ones
>> that I'm not sure what the correct behaviour should be.
>>
>> In particular the slave display thing is a bit of a puzzle to me.
>> Searching for slave in the documentation doesn't yield any results and
>> all I see in example 14 is two streams used, the second of which has
>> had plspause( 0 ) called on it. Is that what sets up a slave display.
>> If so it really needs some documentation indicating what triggers a
>> slave display and how they should work.
>
>
> To Phil, Maurice, Hazen, Hez, and Andrew:
>
> @Phil:
>
> I don't understand the details about exactly what plspause does, but
> it does depend on an implementation in each individual interactive
> device driver so you are going to have to read the plspause parts of
> the source code for one or more other devices to make further progress
> on this bug.
>
> However, to help you to choose what to look at I did some further
> experiments.
>
> For the new wxwidgets device I still get the same incorrect behaviour
> as reported in the bug report.  That is, the slave plot GUI first
> displays a blank plot rather than the actual slave plot and then
> immediately dies.  Meanwhile, the primary plot GUI displays
> fine, and moves to the second page and exits if the user hit the enter
> key twice.  This result is the same both for -DPL_WXWIDGETS_IPC3=ON
> and OFF.  For the old wxwidgets device (-DOLD_WXWIDGETS=ON) the
> behaviour is exactly the same as -dev xwin. That is both primary and
> secondary master and slave GUI's display their respective plots, and
> if you hit the enter key on either of those two GUI's, BOTH plots
> advance a page (which is actually also incorrect behaviour, but at
> least you don't have the "blank page and die" behaviour for
> the slave that you get with new wxwidgets).
>
> So the xwin and old wxwidgets models are not quite the best ones to
> follow here for master/slave behaviour.  And I suspect that is also
> true of -dev wingcc and -dev wingdi because I think they modelled
> their plspause on -dev xwin.  But you should double-check that.
>
> Instead, you should be attempting to implement the same behaviour as
> demonstrated by any of the tk, qtwidget and xcairo
> devices;
> both master and slave GUI plots are displayed, but the enter key is a no-op
> for the slave
> GUI, and only for the master GUI does the enter key advance the pages
> for both GUI's and eventually exit the example.
>
> In sum, I suggest you look carefully at the old wxwidgets device code
> to solve the "blank plot and die" issue with the slave plot for new
> wxwidgets. Once that bug is solved, then I would follow exactly
> however either of our qtwidget or xcairo devices implement plspause to
> obtain the correct master/slave behaviour.  I am not suggesting you
> attempt to understand plspause parts of the -dev tk code because that
> device driver logic is tough to follow in my opinion.  But it is
> interesting that although the -dev tk logic uses important parts of
> the -dev xwin code it gets the master/slave behaviour correct while
> pure -dev xwin code does not achieve that.
>
> @Maurice:
>
> I believe plspause was implemented by you long ago and presumably tested
> by you on the interactive devices available to you (i.e, -dev xwin
> and -dev tk since our cairo and qt device drivers hadn't been
> implemented back then).  I would appreciate you commenting further
> and especially about the differences between master/slave behaviour
> between -dev xwin and the closely related -dev tk.
>
> @Hazen, Hez, and Andrew:
> It is very likely that one of you made the master/slave relationship work
> so well for xcairo and/or qtwidget.  If so I would appreciate you
> commenting further.
>
> 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] Is it time to remove some IPC cruft from our wxwidgets-related code?

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

Alan
I have made a quick couple of changes that makes locate work correctly
again with wxWidgets by simply halting checking for new data while
doing a locate, then starting again when locate is complete.

However I don't want to commit anything that may clash with any
changes that you are making. Let me know if you have started making
any changes in wxplframe in the wxPLViewer and if so I'll just send
you a patch to avoid any clashes.

I had a quick skim through the 3sem code, but you might be the best
person to add a timeout to that code.

Phil

On 2 October 2017 at 21:22, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan
> I literally just logged onto my email to say stop whatever you are
> doing on this the locate mode is broken!!! :-D
>
> I think there may be a couple of different issues here. One is that
> the viewer is checking for more data being sent and the core code is
> waiting for the location information so we have a form of deadlock.
> The receiveBytes functions needs a timeout otherwise it will hang the
> viewer if there is a problem at the other end. Also with the 3sem
> method it probably makes no sense to keep checking for data once we
> have received a locate request. This is set by the m_locateMode
> variable.
>
> I also noticed that you have #ifdefed out the keypress code. Please
> don't remove this as it will need reinstating with the new method.
>
> Phil
>
> On 2 October 2017 at 19:29, Alan W. Irwin <ir...@be...> wrote:
>> On 2017-10-02 08:02+0100 p.d...@gm... wrote:
>>
>>> Hi Alan
>>
>>
>>> I haven't really en through that code, but yes I have been using t
>>
>> and yes I'm happy for that cleanup to occur. The joy of git is that
>> the code history is still here if needed.
>>
>>> So yes, feel free to clean up as you wish.
>>
>>
>> Well, I did one last check, and it turns out I got ahead of myself in
>> making this request, but I do appreciate the keeness you share with me
>> to get this code cleaned up as soon as warranted.  But that time has
>> not (quite) arrived yet.
>>
>> The issue I spotted that currently (for the current HEAD of master)
>> has critically different results for -DPL_WXWIDGETS_IPC3=ON versus OFF
>> is -locate mode for example 1.
>>
>> If you run
>>
>> examples/c/x01c -dev wxwidgets -locate
>>
>> on Linux you get a blank screen with both the above configurations
>> which is a bug for both configurations.  But now that I have looked
>> further, if you click blindly on the location of one of the 4
>> subpages, you get some cursor position information printed to stdout
>> for the -DPL_WXWIDGETS_IPC3=OFF case and eventually the screen is
>> actually displayed for that case.  In contrast for
>> -DPL_WXWIDGETS_IPC3=ON there is no response to mouse clicks for a
>> cursor position I know is in the right place, and therefore the
>> code is apparently in an infinite loop which never displays
>> anything other than a blank screen.
>>
>> Could you take a look at the above screen display issue, and also at
>> why there is no response to mouse clicks in locate mode for just the
>> -DPL_WXWIDGETS_IPC3=ON case?
>>
>> To familiarize yourself with how locate mode should work for this
>> example, you should try other interactive devices as well.  For example,
>>
>> examples/c/x01c -dev wingcc -locate
>>
>> and/or
>>
>> examples/c/x01c -dev wingdi -locate
>>
>> should give good locate mode results (which is that if the mouse [or
>> some keyboard key if the driver supports keyboard clicking] is
>> clicked when the cursor corresponds to one of the 4 viewports, the
>> cursor position and other information is dumped to stdout; and if the
>> mouse [or keyboard key] is clicked when the cursor corresponds to a location
>> outside one
>> of the 4 viewports, locate mode terminates, and then hitting the enter
>> key will terminate the example.)  I just checked, and the
>> old wxwidgets device you can still get access to using
>> -DOLD_WXWIDGETS=ON still builds and
>>
>> examples/c/x01c -dev wxwidgets -locate
>>
>> gives the good locate mode results (both with mouse clicks and
>> keyboard key clicks) described above.
>>
>> [out of order]:
>>>
>>> One question i did have though – I remember my code being set up
>>
>> like a ring buffer, and you saying yours wasn't. But I presume it can
>> still cope with large transfers bigger than the shared memory block?
>>
>> Yes, transferring large blocks of bytes in either direction is what
>> two of the three semaphores control.  This works without any timed
>> waits at all.  (The other semaphore controls use of the entire
>> transfer method similar to your mutex).  My speed tests showed that
>> method of transferring bytes stopped being significantly dependent on
>> shared memory buffer size as soon as that shared memory size (+ a
>> small overhead) was 1KB or greater.  So to be absolutely safe
>> concerning efficiency I set it to 10KB (+ a small overhead).  See the
>> note concerning PL_SHARED_ARRAY_SIZE in drivers/wxwidgets_comms.h.
>> That value is significantly smaller than the ring buffer size which is
>> set to 1024K (in drivers/wxwidgets_dev.cpp) for the case when
>> PL_WXWIDGETS_IPC3 is not #defined.
>>
>>
>> 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] Slave displays

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

On 2017-10-02 16:10+0100 Phil Rosenberg wrote:

> Hi Alan
> I've been going through the various wxWidgets bugs on the bug tracker.
> The ones that remain are the rather more technical ones or the ones
> that I'm not sure what the correct behaviour should be.
>
> In particular the slave display thing is a bit of a puzzle to me.
> Searching for slave in the documentation doesn't yield any results and
> all I see in example 14 is two streams used, the second of which has
> had plspause( 0 ) called on it. Is that what sets up a slave display.
> If so it really needs some documentation indicating what triggers a
> slave display and how they should work.

To Phil, Maurice, Hazen, Hez, and Andrew:

@Phil:

I don't understand the details about exactly what plspause does, but
it does depend on an implementation in each individual interactive
device driver so you are going to have to read the plspause parts of
the source code for one or more other devices to make further progress
on this bug.

However, to help you to choose what to look at I did some further
experiments.

For the new wxwidgets device I still get the same incorrect behaviour
as reported in the bug report.  That is, the slave plot GUI first
displays a blank plot rather than the actual slave plot and then
immediately dies.  Meanwhile, the primary plot GUI displays
fine, and moves to the second page and exits if the user hit the enter
key twice.  This result is the same both for -DPL_WXWIDGETS_IPC3=ON
and OFF.  For the old wxwidgets device (-DOLD_WXWIDGETS=ON) the
behaviour is exactly the same as -dev xwin. That is both primary and
secondary master and slave GUI's display their respective plots, and
if you hit the enter key on either of those two GUI's, BOTH plots
advance a page (which is actually also incorrect behaviour, but at
least you don't have the "blank page and die" behaviour for
the slave that you get with new wxwidgets).

So the xwin and old wxwidgets models are not quite the best ones to
follow here for master/slave behaviour.  And I suspect that is also
true of -dev wingcc and -dev wingdi because I think they modelled
their plspause on -dev xwin.  But you should double-check that.

Instead, you should be attempting to implement the same behaviour as
demonstrated by any of the tk, qtwidget and xcairo
devices;
both master and slave GUI plots are displayed, but the enter key is a no-op for the slave
GUI, and only for the master GUI does the enter key advance the pages
for both GUI's and eventually exit the example.

In sum, I suggest you look carefully at the old wxwidgets device code
to solve the "blank plot and die" issue with the slave plot for new
wxwidgets. Once that bug is solved, then I would follow exactly
however either of our qtwidget or xcairo devices implement plspause to
obtain the correct master/slave behaviour.  I am not suggesting you
attempt to understand plspause parts of the -dev tk code because that
device driver logic is tough to follow in my opinion.  But it is
interesting that although the -dev tk logic uses important parts of
the -dev xwin code it gets the master/slave behaviour correct while
pure -dev xwin code does not achieve that.

@Maurice:

I believe plspause was implemented by you long ago and presumably tested
by you on the interactive devices available to you (i.e, -dev xwin
and -dev tk since our cairo and qt device drivers hadn't been
implemented back then).  I would appreciate you commenting further
and especially about the differences between master/slave behaviour
between -dev xwin and the closely related -dev tk.

@Hazen, Hez, and Andrew:
It is very likely that one of you made the master/slave relationship work
so well for xcairo and/or qtwidget.  If so I would appreciate you
commenting further.

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] Some remaining wxwidgets inefficiency concerns for examples 17 and 08

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

Hi Phil:

I just ran

examples/c/x17c -dev wxwidgets

for the HEAD of master (commit 124a0c3), and I very much like that
that commit implements "interactive" look
for the new wxwidgets device as illustrated by this example.
However, the rendering is slow (i.e., 2.5
minutes) compared to the similar "interactive" plot you get with the
old wxwidgets device (which can be accessed using -DOLD_WXWIDGETS=ON
and which renders in 0.5 minutes).  The xcairo device (which serves as
a good comparison because on this Linux platform wxwidgets is a
wrapper for the same pango/cairo suite of libraries that are used
directly for our cairo device driver) requires 0.9 minutes for this
same test and xwin requires only 0.2 minutes for this test. So there
is likely room to improve the efficiency of the xcairo device for this
example.  But whatever approach the old wxwidgets device is taking for
example 17 certainly has reasonable efficiency, and the issue is to
get the new wxwidgets device driver to match that efficiency for
example 17. (Note that the old IPC method does not render example 17
with an interactive nature.  I don't think we should worry about that
issue since that part of the code is headed to the dustbin.  But it
does make efficiency comparisons between -DPL_WXWIDGETS_IPC3=ON and
OFF problematic for example 17).

To start the process of figuring out the source of this factor of five
inefficiency for example 17 for the new wxwidgets device (and new IPC
method) when compared with the old wxwidgets device, note that example
17 calls plstripa->plstrip_gen/plline a lot. So there are a very large
number of graphical line elements being rendered for this example.

In contrast, example 8 renders a lot of graphical fills, and
presumably because of that the pattern of inefficiency is different
for that example compared to example 17. For example 08, here are the
relevant timing results (as measured by the time it takes from the
launch of

examples/c/x08c -dev wxwidgets

to when wxPLViewer has completely rendered all pages of example 8 for
the new wxwidgets case (with either of the two IPC methods available
for that case) and when -dev wxwidgets has finished rendering in the
the old wxwidgets case).

1. Default configuration, new device with new IPC method:
-DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=ON 
32 seconds

2. New device with old IPC method: -DOLD_WXWIDGETS=OFF -DPL_WXWIDGETS_IPC3=OFF
33 seconds

3. Old device (no IPC required since -dev wxwidgets does its own
rendering in this case): -DOLD_WXWIDGETS=ON
32 seconds

4. xcairo device (which serves as a good comparison for wxwidgets speed
on Linux because the wxWidgets libraries are a wrapper for the pango/cairo libraries
that our cairo device uses directly on that platform).
~3 seconds or less.

So in this x08c case, the first two results illustrate the new IPC
configuration is at least as efficient as the old IPC configuration (as
expected from all my other measurements concerning this issue), and
comparison of the first 3 results with the 4th result shows whatever
is causing this order of magnitude slowdown for this example compared
to xcairo is common to all wxwidgets configurations.

In sum, experimenting with how lines are rendered for new wxwidgets
versus old wxwidgets may help to figure out why new wxwidgets is so
slow compared to old wxwidgets for example 17, and experimenting with
how fills are rendered (likely in a similar way for both old and new
wxwidgets) when compared to xcairo or any other interactive device may
help to figure out why both the old and new versions of wxwidgets
render fills so slowly compared with other interactive devices for
example 8.

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] Is it time to remove some IPC cruft from our wxwidgets-related code?

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

Hi Alan
I literally just logged onto my email to say stop whatever you are
doing on this the locate mode is broken!!! :-D

I think there may be a couple of different issues here. One is that
the viewer is checking for more data being sent and the core code is
waiting for the location information so we have a form of deadlock.
The receiveBytes functions needs a timeout otherwise it will hang the
viewer if there is a problem at the other end. Also with the 3sem
method it probably makes no sense to keep checking for data once we
have received a locate request. This is set by the m_locateMode
variable.

I also noticed that you have #ifdefed out the keypress code. Please
don't remove this as it will need reinstating with the new method.

Phil

On 2 October 2017 at 19:29, Alan W. Irwin <ir...@be...> wrote:
> On 2017-10-02 08:02+0100 p.d...@gm... wrote:
>
>> Hi Alan
>
>
>> I haven't really en through that code, but yes I have been using t
>
> and yes I'm happy for that cleanup to occur. The joy of git is that
> the code history is still here if needed.
>
>> So yes, feel free to clean up as you wish.
>
>
> Well, I did one last check, and it turns out I got ahead of myself in
> making this request, but I do appreciate the keeness you share with me
> to get this code cleaned up as soon as warranted.  But that time has
> not (quite) arrived yet.
>
> The issue I spotted that currently (for the current HEAD of master)
> has critically different results for -DPL_WXWIDGETS_IPC3=ON versus OFF
> is -locate mode for example 1.
>
> If you run
>
> examples/c/x01c -dev wxwidgets -locate
>
> on Linux you get a blank screen with both the above configurations
> which is a bug for both configurations.  But now that I have looked
> further, if you click blindly on the location of one of the 4
> subpages, you get some cursor position information printed to stdout
> for the -DPL_WXWIDGETS_IPC3=OFF case and eventually the screen is
> actually displayed for that case.  In contrast for
> -DPL_WXWIDGETS_IPC3=ON there is no response to mouse clicks for a
> cursor position I know is in the right place, and therefore the
> code is apparently in an infinite loop which never displays
> anything other than a blank screen.
>
> Could you take a look at the above screen display issue, and also at
> why there is no response to mouse clicks in locate mode for just the
> -DPL_WXWIDGETS_IPC3=ON case?
>
> To familiarize yourself with how locate mode should work for this
> example, you should try other interactive devices as well.  For example,
>
> examples/c/x01c -dev wingcc -locate
>
> and/or
>
> examples/c/x01c -dev wingdi -locate
>
> should give good locate mode results (which is that if the mouse [or
> some keyboard key if the driver supports keyboard clicking] is
> clicked when the cursor corresponds to one of the 4 viewports, the
> cursor position and other information is dumped to stdout; and if the
> mouse [or keyboard key] is clicked when the cursor corresponds to a location
> outside one
> of the 4 viewports, locate mode terminates, and then hitting the enter
> key will terminate the example.)  I just checked, and the
> old wxwidgets device you can still get access to using
> -DOLD_WXWIDGETS=ON still builds and
>
> examples/c/x01c -dev wxwidgets -locate
>
> gives the good locate mode results (both with mouse clicks and
> keyboard key clicks) described above.
>
> [out of order]:
>>
>> One question i did have though – I remember my code being set up
>
> like a ring buffer, and you saying yours wasn't. But I presume it can
> still cope with large transfers bigger than the shared memory block?
>
> Yes, transferring large blocks of bytes in either direction is what
> two of the three semaphores control.  This works without any timed
> waits at all.  (The other semaphore controls use of the entire
> transfer method similar to your mutex).  My speed tests showed that
> method of transferring bytes stopped being significantly dependent on
> shared memory buffer size as soon as that shared memory size (+ a
> small overhead) was 1KB or greater.  So to be absolutely safe
> concerning efficiency I set it to 10KB (+ a small overhead).  See the
> note concerning PL_SHARED_ARRAY_SIZE in drivers/wxwidgets_comms.h.
> That value is significantly smaller than the ring buffer size which is
> set to 1024K (in drivers/wxwidgets_dev.cpp) for the case when
> PL_WXWIDGETS_IPC3 is not #defined.
>
>
> 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] Is it time to remove some IPC cruft from our wxwidgets-related code?

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

On 2017-10-02 08:02+0100 p.d...@gm... wrote:

> Hi Alan

> I haven't really en through that code, but yes I have been using t
and yes I'm happy for that cleanup to occur. The joy of git is that
the code history is still here if needed.

> So yes, feel free to clean up as you wish.

Well, I did one last check, and it turns out I got ahead of myself in
making this request, but I do appreciate the keeness you share with me
to get this code cleaned up as soon as warranted.  But that time has
not (quite) arrived yet.

The issue I spotted that currently (for the current HEAD of master)
has critically different results for -DPL_WXWIDGETS_IPC3=ON versus OFF
is -locate mode for example 1.

If you run

examples/c/x01c -dev wxwidgets -locate

on Linux you get a blank screen with both the above configurations
which is a bug for both configurations.  But now that I have looked
further, if you click blindly on the location of one of the 4
subpages, you get some cursor position information printed to stdout
for the -DPL_WXWIDGETS_IPC3=OFF case and eventually the screen is
actually displayed for that case.  In contrast for
-DPL_WXWIDGETS_IPC3=ON there is no response to mouse clicks for a
cursor position I know is in the right place, and therefore the
code is apparently in an infinite loop which never displays
anything other than a blank screen.

Could you take a look at the above screen display issue, and also at
why there is no response to mouse clicks in locate mode for just the
-DPL_WXWIDGETS_IPC3=ON case?

To familiarize yourself with how locate mode should work for this
example, you should try other interactive devices as well.  For example,

examples/c/x01c -dev wingcc -locate

and/or

examples/c/x01c -dev wingdi -locate

should give good locate mode results (which is that if the mouse [or
some keyboard key if the driver supports keyboard clicking] is
clicked when the cursor corresponds to one of the 4 viewports, the
cursor position and other information is dumped to stdout; and if the
mouse [or keyboard key] is clicked when the cursor corresponds to a location outside one
of the 4 viewports, locate mode terminates, and then hitting the enter
key will terminate the example.)  I just checked, and the
old wxwidgets device you can still get access to using
-DOLD_WXWIDGETS=ON still builds and

examples/c/x01c -dev wxwidgets -locate

gives the good locate mode results (both with mouse clicks and
keyboard key clicks) described above.

[out of order]:
> One question i did have though – I remember my code being set up
like a ring buffer, and you saying yours wasn't. But I presume it can
still cope with large transfers bigger than the shared memory block?

Yes, transferring large blocks of bytes in either direction is what
two of the three semaphores control.  This works without any timed
waits at all.  (The other semaphore controls use of the entire
transfer method similar to your mutex).  My speed tests showed that
method of transferring bytes stopped being significantly dependent on
shared memory buffer size as soon as that shared memory size (+ a
small overhead) was 1KB or greater.  So to be absolutely safe
concerning efficiency I set it to 10KB (+ a small overhead).  See the
note concerning PL_SHARED_ARRAY_SIZE in drivers/wxwidgets_comms.h.
That value is significantly smaller than the ring buffer size which is
set to 1024K (in drivers/wxwidgets_dev.cpp) for the case when
PL_WXWIDGETS_IPC3 is not #defined.

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] ocaml and antialiased gtk embedding (cairo)

[Philippe S. <phi...@ya...>]

Hello plplot devs,
I'm an ocaml user using plplot in one of my pet project.The plcairo layer seems not usable anymore, what happened?I have some spare time to tackle the issue under guidance in case.
I use plplot embedded in a gtk windows from within ocaml like the xgtk_interface example.
I have ocaml cairo and cairo2 bindings.
regards.



--Philippe Strauss

[Plplot-devel] Slave displays

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

Hi Alan
I've been going through the various wxWidgets bugs on the bug tracker.
The ones that remain are the rather more technical ones or the ones
that I'm not sure what the correct behaviour should be.

In particular the slave display thing is a bit of a puzzle to me.
Searching for slave in the documentation doesn't yield any results and
all I see in example 14 is two streams used, the second of which has
had plspause( 0 ) called on it. Is that what sets up a slave display.
If so it really needs some documentation indicating what triggers a
slave display and how they should work.

Phil

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

>
> The eofill setting is saved by the plbuf at a bop (see line 176 and 359 in plbuf.c).
>
Hi Jim - These are changes I made over the weekend. I guess you're not
subscribed to get code change notifications or maybe you missed them
:-)


>
> I have noticed some inconsistencies in the mash-up of plbuf and drivers when it comes to handling state and escape (e.g. plD_esc) functions.  Based on my recollection of old graphics devices, I think I understand the difference (state has to do with internal plplot and escape has to do with commands to the graphic device) but with the way graphics devices have evolved we may want to revisit the implementation (e.g. make sure no settings are getting lost on a replot).

My understanding is the same. state commands change something that
plplot remembers - usually something that is saved in the PLStream,
whereas escapes are commands sent to the drivers to perform an action
- usually rendering. Always thought that was an odd name, when I think
of escape I think of escape sequences in text etc. I guess there is a
historical reason. I also guess that a number of things like setting
the rotation or clipping region or subpage or other things are really
changes of state, but don't go through that code. Again I guess these
are for historical reasons.

>
> The biggest weakness in plbuf is that what it thinks should be saved may not match what is needed.  When working on the core and drivers, it is easy to add a bit of state and not update plbuf.  There might be a way to make plbuf be more aggressive in saving state information and restoring it when replaying the buffer.  I can make the aggressiveness be a setting that a driver can set it if it wants the current behavior—I am concerned that some of the older drivers might have issues.

I actually think that now that the wxWidgets interactive driver (i.e.
the one that gets called from a command line application, rather than
what gets called when you pass in a wxDC) uses the buffer for all its
rendering, we now do rather a good job of keeping on top of these
things. The biggest problems have turned out to be, things that are
stored in PLStream, but don't go through the Plp_State code. The
things that I think still pose challenges are
1) Initialisation and beginning the first page - it can be that when
passing a buffer around we end up initialising more than once and this
has caused issues. I these are mostly sorted now though.
2) Resizing - the buffer stores the coordinates for rendering and the
sizes of text. But if we resize then we may want to scale the text
size, or keep the text size the same and keep the distance of labels
from the axis the same. Currently we keep the text size the same, but
they move relative to the axes.
3) Changes of aspect ratio - This can cause a big mess, especially for
rotated text on plots, axis label positioning and tick mark length.

Actually now that I have listed these, I am going to add 2 and 3 to
the bug tracker so they don't get totally forgotten.

Phil

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

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

Hi Alan
I haven't really en through that code, but yes I have been using t and yes I'm happy for that cleanup to occur. The joy of git is that the code history is still here if needed.

One question i did have though – I remember my code being set up like a ring buffer, and you saying yours wasn't. But I presume it can still cope with large transfers bigger than the shared memory block?

So yes, feel free to clean up as you wish.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 02 October 2017 06:25
To: Phil Rosenberg; PLplot development list
Subject: Is it time to remove some IPC cruft from our wxwidgets-related code?

Hi Phil:

Thanks for all the testing and bug-fixing for wxwidgets that you have
being charging through this weekend.

During the course of that testing (presumably on Windows) I am going
to assume you just used the default given by

option(PL_WXWIDGETS_IPC3 "Use the three-semaphores approach for wxwidgets IPC" ON)

(i.e., you did not specifically use -DPL_WXWIDGETS_IPC3=OFF). That
default case corresponding to -DPL_WXWIDGETS_IPC3=ON is what I
constantly use on Linux for wxwidgets, and I am happy with it.

Are you happy with your recent experience with the three-semaphores
IPC approach on Windows, i.e., has everything worked as well as with the old
IPC approach with no noticeable slowdowns?  If so and whenever you give
the OK, I propose to remove from our wxwidgets-related code your
original IPC approach which involved a circular buffer code and a
mutex, i.e., all code which is currently compiled only if the
PL_WXWIDGETS_IPC3 macro is NOT #defined.  That change should make both
the -dev wxwidgets code and wxPLViewer code much easier to understand
which is why I am pushing for this change.

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] Is it time to remove some IPC cruft from our wxwidgets-related code?

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

Hi Phil:

Thanks for all the testing and bug-fixing for wxwidgets that you have
being charging through this weekend.

During the course of that testing (presumably on Windows) I am going
to assume you just used the default given by

option(PL_WXWIDGETS_IPC3 "Use the three-semaphores approach for wxwidgets IPC" ON)

(i.e., you did not specifically use -DPL_WXWIDGETS_IPC3=OFF). That
default case corresponding to -DPL_WXWIDGETS_IPC3=ON is what I
constantly use on Linux for wxwidgets, and I am happy with it.

Are you happy with your recent experience with the three-semaphores
IPC approach on Windows, i.e., has everything worked as well as with the old
IPC approach with no noticeable slowdowns?  If so and whenever you give
the OK, I propose to remove from our wxwidgets-related code your
original IPC approach which involved a circular buffer code and a
mutex, i.e., all code which is currently compiled only if the
PL_WXWIDGETS_IPC3 macro is NOT #defined.  That change should make both
the -dev wxwidgets code and wxPLViewer code much easier to understand
which is why I am pushing for this change.

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] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

> On Sep 30, 2017, at 2:35 PM, Alan W. Irwin <ir...@be...> wrote:
> 
> On 2017-09-30 15:06+0100 Phil Rosenberg wrote:
> 
>> Hi Alan
>> 
>> 
>> On 30 September 2017 at 07:31, Alan W. Irwin <ir...@be...> wrote:
>>> On 2017-09-30 02:27+0100 p.d...@gm... wrote:
>>> 
>>>> I suspect this will be a bug in the render buffer, where the fill
>>> 
>>> method is not correctly stored in or read from the buffer. You can
>>> check this by doing a plreplot with and device and seeing if the
>>> correct behaviour is maintained.
>>> 
>>> To Phil and Jim:
>>> 
>>> @Jim:
>>> 
>>> I am specifically also addressing you in this discussion because of
>>> your knowledge of the plbuf code so I hope you will be able to reply
>>> to the final question below.
>>> 
>>> 
>>> Also, I have some contradictory evidence regarding what you suspect
>>> above.  For example when I search src/plbuf.c for "eofill" there is
>>> nothing.  Also, when I search that code for anything to do with fills,
>>> the fill state appears to only include information concerning discrete
>>> fills (with line patterns as in example 15) rather than information
>>> like pls->dev_eofill that is needed for solid fills.  So I suspect
>>> adding that information to the fill state might solve this issue.
>>> 

The eofill setting is saved by the plbuf at a bop (see line 176 and 359 in plbuf.c).

>>> However, without attempting to make such a change (yet) if I run
>>> 
>>> examples/c/x27c -dev qtwidget -eofill
>>> 
>>> or
>>> 
>>> examples/c/x27c -dev xwin -eofill
>>> 
>>> I get the correct behaviour (an odd-even rule fill) regardless of
>>> whether I resize the GUI or call plreplot after each call to
>>> spiro in examples/c/x27c.c.  Aren't both of those actions supposed
>>> to use the plbuf code to replot the buffer?  And from the above
>>> search of the src/plbuf.c code how is it possible that pls->dev_eofill is
>>> used properly by this code when no
>>> reference to that exists within that code.


I’m confused because plbuf is saving the dev_eofill setting.

>>> 
>>> @Phil and Jim:
>>> 
>>> I obviously must be missing something about the plbuf code, but what?
>>> 
>> 

I have noticed some inconsistencies in the mash-up of plbuf and drivers when it comes to handling state and escape (e.g. plD_esc) functions.  Based on my recollection of old graphics devices, I think I understand the difference (state has to do with internal plplot and escape has to do with commands to the graphic device) but with the way graphics devices have evolved we may want to revisit the implementation (e.g. make sure no settings are getting lost on a replot).

The biggest weakness in plbuf is that what it thinks should be saved may not match what is needed.  When working on the core and drivers, it is easy to add a bit of state and not update plbuf.  There might be a way to make plbuf be more aggressive in saving state information and restoring it when replaying the buffer.  I can make the aggressiveness be a setting that a driver can set it if it wants the current behavior—I am concerned that some of the older drivers might have issues.


> @Phil and Jim:
> 
> Anyhow, I strongly encourage you to try anything you like here with
> streams and src/plargs.c with the obvious caveats that the resulting
> code should be easier to understand and give as good or better results
> than the current code when comprehensive tests are applied.  It also
> "would be nice" if these changes solved the original problem that
> started this discussion which is to get the -eofill option to work
> properly for -dev wxwidgets, but we don't have the knowledge at this
> stage to decide whether that fix is orthogonal or not to the discussed
> changes in streams and src/plargs.c so "time will tell" on that issue.
> Alan
> __________________________
> Alan W. Irwin
> 

Re: [Plplot-devel] Helping you to collect evidence to support a fill-rule bug report for wxWidgets on Windows

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

On 2017-10-02 00:19+0100 Phil Rosenberg wrote:

> Ah, okay, so a single "interior loop" should fill with the winding
> rule, but not with the odd-even rule.
> That's what I needed to know. I
> can generate a simple wxWidgets chunk of code totally independent of
> PLplot to show that this doesn't work.

That's good, and good luck with getting a quick fix from the wxWidgets
developers to your bug report.

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] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

On 2017-10-02 00:14+0100 Phil Rosenberg wrote:

> On 1 October 2017 at 21:01, Alan W. Irwin <ir...@be...> wrote:
>> On 2017-10-01 09:49+0100 Phil Rosenberg wrote:
>>
>> [Alan said]
>>>>
>>>> With regard to your remark concerning writing a plsfillrule() function
>>>> and systematically using it throughout src/plargs.c, I wouldn't want
>>>> to do that myself, but if you or Jim want to make such a change and it
>>>> passes comprehensive testing, I certainly would not object.
>>>
>>>
>> [Phil responded]
>>>
>>> I can add a new API function if you think it is useful, but I can only
>>> propagate it as far as the C and C++ APIs, someone else would have to
>>> propagate it to other languages as needed.
>>>
>>
>> From what has been said, my impression is a plsfillrule() function is
>> C-only functionality to make src/plargs.c easier to understand and use
>> correctly. If that impression is correct there should be no need to
>> propagate this functionality even to our C++ binding since all our bindings
>> simply wrap the C plparseopts routine without knowing its
>> internal implementation details. But please educate me if that
>> impression is incorrect.
>>
>
> Hi Alan
> I actually meant, do we want to add plsfillrule as an API function? It
> feels more like it should be an API function rather than a command
> argument. It would be little trouble to allow users to swap back and
> forward between the two rules. But I have a feeling this functionality
> is not used that often so maybe it's not worth the effort.

Hi Phil:

Sorry, but I think I have misunderstood this subset of this thread
from the beginning since I assumed you were talking about some general
capability rather than something specific to -eofill (which is obvious
from the name of the "plsfillrule" function, but I simply missed the
significance of that name until now).

So to start over, it would be worthwhile to be able to set
pls->dev_eofill to true or false at any time.  But I don't think we
need to add API to do that.  Instead, we need to modify src/plargs.c
such that -eofill takes a true (non-zero) or false (0) argument.
with pls->dev_eofill being set appropriately to true or false.

Then users in any language can call

plsetopt("eofill", "1");

plsetopt("eofill", "0");

as needed.  Of course, demanding that -eofill requires an argument is
backwards incompatible, but if we mention that in the release notes I
think that would be sufficient since my judgement is -eofill is not a
heavily used option.

If you agree with the above idea to add an argument to -eofill, then I
would be willing to take responsibility for implementing that and
documenting that backwards-incompatible change in README.release.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

On 1 October 2017 at 21:01, Alan W. Irwin <ir...@be...> wrote:
> On 2017-10-01 09:49+0100 Phil Rosenberg wrote:
>
> [Alan said]
>>>
>>> With regard to your remark concerning writing a plsfillrule() function
>>> and systematically using it throughout src/plargs.c, I wouldn't want
>>> to do that myself, but if you or Jim want to make such a change and it
>>> passes comprehensive testing, I certainly would not object.
>>
>>
> [Phil responded]
>>
>> I can add a new API function if you think it is useful, but I can only
>> propagate it as far as the C and C++ APIs, someone else would have to
>> propagate it to other languages as needed.
>>
>
> From what has been said, my impression is a plsfillrule() function is
> C-only functionality to make src/plargs.c easier to understand and use
> correctly. If that impression is correct there should be no need to
> propagate this functionality even to our C++ binding since all our bindings
> simply wrap the C plparseopts routine without knowing its
> internal implementation details. But please educate me if that
> impression is incorrect.
>

Hi Alan
I actually meant, do we want to add plsfillrule as an API function? It
feels more like it should be an API function rather than a command
argument. It would be little trouble to allow users to swap back and
forward between the two rules. But I have a feeling this functionality
is not used that often so maybe it's not worth the effort.

Phil

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

Fixed

My test for initialisation was incorrect.

On 1 October 2017 at 20:50, Alan W. Irwin <ir...@be...> wrote:
> On 2017-09-30 19:22-0700 Alan W. Irwin wrote:
>
>> Anyhow, thanks very much for this fix, and I have changed the status
>> of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.
>
>
> I have just discovered a really strange problem with your recent
> -eofill fix (commit b603fd22). The issue is that valgrind results on C
> and Fortran standard examples show no memory-management issues, and
> you would expect that good result would continue with all bindings
> since your commit made changes only to C language files associated
> with our core C library and not the bindings. However, for some
> strange reason your change does cause segfaults for all C++ examples
> and all devices that I have tried for those examples whenever the
> -eofill option is used.  There are no such issues when the -eofill
> option is not used.
>
> Here are typical valgrind results for the two cases where I
> have chosen to use one of our simpler C++ examples (x00)
> and one of our simpler devices (svg).
>
> software@raven> valgrind examples/c++/x00 -dev svg -o test.svg
> ==1930== Memcheck, a memory error detector
> ==1930== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==1930== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==1930== Command: examples/c++/x00 -dev svg -o test.svg
> ==1930== ==1930== ==1930== HEAP SUMMARY:
> ==1930==     in use at exit: 0 bytes in 0 blocks
> ==1930==   total heap usage: 463 allocs, 463 frees, 148,933 bytes allocated
> ==1930== ==1930== All heap blocks were freed -- no leaks are possible
> ==1930== ==1930== For counts of detected and suppressed errors, rerun with:
> -v
> ==1930== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> software@raven> valgrind examples/c++/x00 -dev svg -o test.svg -eofill
> ==1931== Memcheck, a memory error detector
> ==1931== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==1931== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==1931== Command: examples/c++/x00 -dev svg -o test.svg -eofill
> ==1931== ==1931== Invalid read of size 8
> ==1931==    at 0x5C3656E: plP_state (plcore.c:257)
> ==1931==    by 0x5C24C42: opt_eofill (plargs.c:2845)
> ==1931==    by 0x5C22BED: ProcessOpt (plargs.c:1140)
> ==1931==    by 0x5C22A1D: ParseOpt (plargs.c:1068)
> ==1931==    by 0x5C22779: c_plparseopts (plargs.c:935)
> ==1931==    by 0x4E40719: plstream::parseopts(int*, char**, int)
> (plstream.cc:1283)
> ==1931==    by 0x400C4C: x00::x00(int, char**) (x00.cc:59)
> ==1931==    by 0x400D92: main (x00.cc:79)
> ==1931==  Address 0x48 is not stack'd, malloc'd or (recently) free'd
> ==1931== ==1931== ==1931== Process terminating with default action of signal
> 11 (SIGSEGV)
> ==1931==  Access not within mapped region at address 0x48
> ==1931==    at 0x5C3656E: plP_state (plcore.c:257)
> ==1931==    by 0x5C24C42: opt_eofill (plargs.c:2845)
> ==1931==    by 0x5C22BED: ProcessOpt (plargs.c:1140)
> ==1931==    by 0x5C22A1D: ParseOpt (plargs.c:1068)
> ==1931==    by 0x5C22779: c_plparseopts (plargs.c:935)
> ==1931==    by 0x4E40719: plstream::parseopts(int*, char**, int)
> (plstream.cc:1283)
> ==1931==    by 0x400C4C: x00::x00(int, char**) (x00.cc:59)
> ==1931==    by 0x400D92: main (x00.cc:79)
> ==1931==  If you believe this happened as a result of a stack
> ==1931==  overflow in your program's main thread (unlikely but
> ==1931==  possible), you can try to increase the size of the
> ==1931==  main thread stack using the --main-stacksize= flag.
> ==1931==  The main thread stack size used in this run was 8388608.
> ==1931== ==1931== HEAP SUMMARY:
> ==1931==     in use at exit: 29,775 bytes in 265 blocks
> ==1931==   total heap usage: 314 allocs, 49 frees, 74,436 bytes allocated
> ==1931== ==1931== LEAK SUMMARY:
> ==1931==    definitely lost: 0 bytes in 0 blocks
> ==1931==    indirectly lost: 0 bytes in 0 blocks
> ==1931==      possibly lost: 0 bytes in 0 blocks
> ==1931==    still reachable: 29,775 bytes in 265 blocks
> ==1931==         suppressed: 0 bytes in 0 blocks
> ==1931== Rerun with --leak-check=full to see details of leaked memory
> ==1931== ==1931== For counts of detected and suppressed errors, rerun with:
> -v
> ==1931== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> Segmentation fault
>
> 1930 (without -eofill) shows perfect valgrind results while 1931 shows
> shows showstopping (segfault) memory management issues with -eofill.
>
> I hope you can figure out this peculiar issue with your fix because
> it has me completely stumped!
>
>
> 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] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

On 2017-10-01 09:49+0100 Phil Rosenberg wrote:

[Alan said]
>> With regard to your remark concerning writing a plsfillrule() function
>> and systematically using it throughout src/plargs.c, I wouldn't want
>> to do that myself, but if you or Jim want to make such a change and it
>> passes comprehensive testing, I certainly would not object.
>
[Phil responded]
> I can add a new API function if you think it is useful, but I can only
> propagate it as far as the C and C++ APIs, someone else would have to
> propagate it to other languages as needed.
>

>From what has been said, my impression is a plsfillrule() function is
C-only functionality to make src/plargs.c easier to understand and use
correctly. If that impression is correct there should be no need to
propagate this functionality even to our C++ binding since all our 
bindings simply wrap the C plparseopts routine without knowing its
internal implementation details. But please educate me if that
impression is incorrect.

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] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

On 2017-09-30 19:22-0700 Alan W. Irwin wrote:

> Anyhow, thanks very much for this fix, and I have changed the status
> of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.

I have just discovered a really strange problem with your recent
-eofill fix (commit b603fd22). The issue is that valgrind results on C
and Fortran standard examples show no memory-management issues, and
you would expect that good result would continue with all bindings
since your commit made changes only to C language files associated
with our core C library and not the bindings. However, for some
strange reason your change does cause segfaults for all C++ examples
and all devices that I have tried for those examples whenever the
-eofill option is used.  There are no such issues when the -eofill
option is not used.

Here are typical valgrind results for the two cases where I
have chosen to use one of our simpler C++ examples (x00)
and one of our simpler devices (svg).

software@raven> valgrind examples/c++/x00 -dev svg -o test.svg
==1930== Memcheck, a memory error detector
==1930== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1930== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1930== Command: examples/c++/x00 -dev svg -o test.svg
==1930== 
==1930== 
==1930== HEAP SUMMARY:
==1930==     in use at exit: 0 bytes in 0 blocks
==1930==   total heap usage: 463 allocs, 463 frees, 148,933 bytes allocated
==1930== 
==1930== All heap blocks were freed -- no leaks are possible
==1930== 
==1930== For counts of detected and suppressed errors, rerun with: -v
==1930== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
software@raven> valgrind examples/c++/x00 -dev svg -o test.svg -eofill
==1931== Memcheck, a memory error detector
==1931== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1931== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==1931== Command: examples/c++/x00 -dev svg -o test.svg -eofill
==1931== 
==1931== Invalid read of size 8
==1931==    at 0x5C3656E: plP_state (plcore.c:257)
==1931==    by 0x5C24C42: opt_eofill (plargs.c:2845)
==1931==    by 0x5C22BED: ProcessOpt (plargs.c:1140)
==1931==    by 0x5C22A1D: ParseOpt (plargs.c:1068)
==1931==    by 0x5C22779: c_plparseopts (plargs.c:935)
==1931==    by 0x4E40719: plstream::parseopts(int*, char**, int) (plstream.cc:1283)
==1931==    by 0x400C4C: x00::x00(int, char**) (x00.cc:59)
==1931==    by 0x400D92: main (x00.cc:79)
==1931==  Address 0x48 is not stack'd, malloc'd or (recently) free'd
==1931== 
==1931== 
==1931== Process terminating with default action of signal 11 (SIGSEGV)
==1931==  Access not within mapped region at address 0x48
==1931==    at 0x5C3656E: plP_state (plcore.c:257)
==1931==    by 0x5C24C42: opt_eofill (plargs.c:2845)
==1931==    by 0x5C22BED: ProcessOpt (plargs.c:1140)
==1931==    by 0x5C22A1D: ParseOpt (plargs.c:1068)
==1931==    by 0x5C22779: c_plparseopts (plargs.c:935)
==1931==    by 0x4E40719: plstream::parseopts(int*, char**, int) (plstream.cc:1283)
==1931==    by 0x400C4C: x00::x00(int, char**) (x00.cc:59)
==1931==    by 0x400D92: main (x00.cc:79)
==1931==  If you believe this happened as a result of a stack
==1931==  overflow in your program's main thread (unlikely but
==1931==  possible), you can try to increase the size of the
==1931==  main thread stack using the --main-stacksize= flag.
==1931==  The main thread stack size used in this run was 8388608.
==1931== 
==1931== HEAP SUMMARY:
==1931==     in use at exit: 29,775 bytes in 265 blocks
==1931==   total heap usage: 314 allocs, 49 frees, 74,436 bytes allocated
==1931== 
==1931== LEAK SUMMARY:
==1931==    definitely lost: 0 bytes in 0 blocks
==1931==    indirectly lost: 0 bytes in 0 blocks
==1931==      possibly lost: 0 bytes in 0 blocks
==1931==    still reachable: 29,775 bytes in 265 blocks
==1931==         suppressed: 0 bytes in 0 blocks
==1931== Rerun with --leak-check=full to see details of leaked memory
==1931== 
==1931== For counts of detected and suppressed errors, rerun with: -v
==1931== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

1930 (without -eofill) shows perfect valgrind results while 1931 shows
shows showstopping (segfault) memory management issues with -eofill.

I hope you can figure out this peculiar issue with your fix because
it has me completely stumped!

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] Helping you to collect evidence to support a fill-rule bug report for wxWidgets on Windows

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

On 2017-10-01 09:49+0100 Phil Rosenberg wrote:

>>> Note that I have tested this up to the point of checking in the
>>> debugger that the correct fill rule is recognised by the viewer and
>>> the correct parameter is passed in to the wxWidgets fill function.
>>> This definitely works correctly both with and without -eofill
>>> specified for example 27. However I didn't spot a difference in the
>>> output. Maybe you can check it if you know how it should look
>>
>>
>> Hi Phil:
>>
>> I suspect you didn't go far enough into the pages of the example to
>> encounter the fill results for the more complex figures. If you do
>> that, e.g., page 19 of the example (see
>> <http://www.plplot.org/examples-data/demo27/x27.19.png> which was
>> generated with -dev pngcairo and the -eofill option), the result
>> should have many holes in the fill region relative to the same page
>> generated without the -eofill option.  If you don't see that
>> difference on Windows, I feel that is likely due to a wxWidgets
>> library bug on Windows since that difference does show up in the Linux
>> case.
>>
>> Anyhow, thanks very much for this fix, and I have changed the status
>> of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.
>
> I get output just like that image without the -eofill parameter. I
> suspect that as you said this is a bug in wxWidgets on Windows. I'm
> not exactly sure how the differences are supposed to manifest. If you
> could send me a relatively simple polygon that should give different
> output depending upon which rule is used and a description of what
> should be different then I will generate a test case and submit a bug
> report.

I think the best test case is a considerably simplified version of C
standard example 27 with the lowest-order figure that shows the
difference.  I therefore as requested have attached source code for
such a test case, and associated screenshots for -dev wxwidgets in the
two fill-rule cases (snapshot1.png for the default case without
-eofill and snapshot2.png for the case with -eofill).  If you compare
those screenshots with the figure in
<https://en.wikipedia.org/wiki/Nonzero-rule> you will see (as
expected) that snapshot1.png follows the non-zero fill rule and
snapshot2.png follows the even-odd fill rule.  These results were
produced on a Linux platform, but from what you say on a Windows
platform you would always get for this simplified test case the
equivalent of the -eofill result.  So once you confirm that, it would
be pretty good evidence of a wxWidgets library bug in the Windows
case.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

>> Note that I have tested this up to the point of checking in the
>> debugger that the correct fill rule is recognised by the viewer and
>> the correct parameter is passed in to the wxWidgets fill function.
>> This definitely works correctly both with and without -eofill
>> specified for example 27. However I didn't spot a difference in the
>> output. Maybe you can check it if you know how it should look
>
>
> Hi Phil:
>
> I suspect you didn't go far enough into the pages of the example to
> encounter the fill results for the more complex figures. If you do
> that, e.g., page 19 of the example (see
> <http://www.plplot.org/examples-data/demo27/x27.19.png> which was
> generated with -dev pngcairo and the -eofill option), the result
> should have many holes in the fill region relative to the same page
> generated without the -eofill option.  If you don't see that
> difference on Windows, I feel that is likely due to a wxWidgets
> library bug on Windows since that difference does show up in the Linux
> case.
>
> Anyhow, thanks very much for this fix, and I have changed the status
> of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.

I get output just like that image without the -eofill parameter. I
suspect that as you said this is a bug in wxWidgets on Windows. I'm
not exactly sure how the differences are supposed to manifest. If you
could send me a relatively simple polygon that should give different
output depending upon which rule is used and a description of what
should be different then I will generate a test case and submit a bug
report.

>
> With regard to your remark concerning writing a plsfillrule() function
> and systematically using it throughout src/plargs.c, I wouldn't want
> to do that myself, but if you or Jim want to make such a change and it
> passes comprehensive testing, I certainly would not object.

I can add a new API function if you think it is useful, but I can only
propagate it as far as the C and C++ APIs, someone else would have to
propagate it to other languages as needed.

Re: [Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

On 2017-10-01 01:11+0100 Phil Rosenberg wrote:

> On 30 September 2017 at 19:35, Alan W. Irwin <ir...@be...> wrote:
>> [...] By the way, other command-line options such as
>>
>> examples/c/x27c -dev wxwidgets -geometry 300x200
>>
>> do work fine for -dev wxwidgets so the issue with the -eofill option
>> with -dev wxwidgets is likely not a general command-line option issue
>> with -dev wxwidgets but something specific about how the -eofill
>> option is handled for the -dev wxwidgets case.
>


> Does geometry set the size of the canvas?

Yes.

> This is specifically transmitted to
> the viewer as it is not recorded in the buffer anywhere. But is you
> check plbuf_bop you can see the state parameters that are recorded at
> the beginning of each page. I have now added the dev_eofill variable
> to that list. I have also set the function opt_eofill to call
> plP_State so that if a change occurs later in the execution it will
> get picked up.  Should you feel the need to write a plsfillrule()
> function then all the stuff is there so that if you just duplicated
> opt_eofill then all the code is there so that the buffer would catch
> it.

> Note that I have tested this up to the point of checking in the
> debugger that the correct fill rule is recognised by the viewer and
> the correct parameter is passed in to the wxWidgets fill function.
> This definitely works correctly both with and without -eofill
> specified for example 27. However I didn't spot a difference in the
> output. Maybe you can check it if you know how it should look

Hi Phil:

I suspect you didn't go far enough into the pages of the example to
encounter the fill results for the more complex figures. If you do
that, e.g., page 19 of the example (see
<http://www.plplot.org/examples-data/demo27/x27.19.png> which was
generated with -dev pngcairo and the -eofill option), the result
should have many holes in the fill region relative to the same page
generated without the -eofill option.  If you don't see that
difference on Windows, I feel that is likely due to a wxWidgets
library bug on Windows since that difference does show up in the Linux
case.

Anyhow, thanks very much for this fix, and I have changed the status
of https://sourceforge.net/p/plplot/bugs/174/ to closed-fixed.

With regard to your remark concerning writing a plsfillrule() function
and systematically using it throughout src/plargs.c, I wouldn't want
to do that myself, but if you or Jim want to make such a change and it
passes comprehensive testing, I certainly would not object.

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] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

Hi Alan

On 30 September 2017 at 19:35, Alan W. Irwin <ir...@be...> wrote:
> On 2017-09-30 15:06+0100 Phil Rosenberg wrote:
>
>> Hi Alan
>>
>>
>> On 30 September 2017 at 07:31, Alan W. Irwin <ir...@be...>
>> wrote:
>>>
>>> On 2017-09-30 02:27+0100 p.d...@gm... wrote:
>>>
>>>> I suspect this will be a bug in the render buffer, where the fill
>>>
>>>
>>> method is not correctly stored in or read from the buffer. You can
>>> check this by doing a plreplot with and device and seeing if the
>>> correct behaviour is maintained.
>>>
>>> To Phil and Jim:
>>>
>>> @Jim:
>>>
>>> I am specifically also addressing you in this discussion because of
>>> your knowledge of the plbuf code so I hope you will be able to reply
>>> to the final question below.
>>>
>>>
>>> Also, I have some contradictory evidence regarding what you suspect
>>> above.  For example when I search src/plbuf.c for "eofill" there is
>>> nothing.  Also, when I search that code for anything to do with fills,
>>> the fill state appears to only include information concerning discrete
>>> fills (with line patterns as in example 15) rather than information
>>> like pls->dev_eofill that is needed for solid fills.  So I suspect
>>> adding that information to the fill state might solve this issue.
>>>
>>> However, without attempting to make such a change (yet) if I run
>>>
>>> examples/c/x27c -dev qtwidget -eofill
>>>
>>> or
>>>
>>> examples/c/x27c -dev xwin -eofill
>>>
>>> I get the correct behaviour (an odd-even rule fill) regardless of
>>> whether I resize the GUI or call plreplot after each call to
>>> spiro in examples/c/x27c.c.  Aren't both of those actions supposed
>>> to use the plbuf code to replot the buffer?  And from the above
>>> search of the src/plbuf.c code how is it possible that pls->dev_eofill is
>>> used properly by this code when no
>>> reference to that exists within that code.
>>>
>>> @Phil and Jim:
>>>
>>> I obviously must be missing something about the plbuf code, but what?
>>>
>>
>>
>> Having just had a quick look at the code, args.c has no mention of the
>> buffer at all. I suspect that what is happening with your test case is
>> that even when the buffer is parsed the same plStream struct is used
>> with the flag correctly set. The buffer will never overwrite this flag
>> because it never recorded it in the first place.
>
>
> Hi Phil:
>
> Your reply inadvertently dropped Jim and the list from the addressees so
> I have reinstated those for obvious reasons.  I have also changed the
> subject line to the current topics that have been raised during this
> discussion.

Sorry, must have forgot to hit reply all

>
> Your above remark does appear to give a rational explanation of why
> the above experiments worked. Therefore, there must be something else
> special to the -dev wxwidgets case that makes that case not work.  By
> the way, other command-line options such as
>
> examples/c/x27c -dev wxwidgets -geometry 300x200
>
> do work fine for -dev wxwidgets so the issue with the -eofill option
> with -dev wxwidgets is likely not a general command-line option issue
> with -dev wxwidgets but something specific about how the -eofill
> option is handled for the -dev wxwidgets case.

Does geometry set the size of the canvas? This is specifically transmitted to
the viewer as it is not recorded in the buffer anywhere. But is you
check plbuf_bop you can see the state parameters that are recorded at
the beginning of each page. I have now added the dev_eofill variable
to that list. I have also set the function opt_eofill to call
plP_State so that if a change occurs later in the execution it will
get picked up. Should you feel the need to write a plsfillrule()
function then all the stuff is there so that if you just duplicated
opt_eofill then all the code is there so that the buffer would catch
it.

Note that I have tested this up to the point of checking in the
debugger that the correct fill rule is recognised by the viewer and
the correct parameter is passed in to the wxWidgets fill function.
This definitely works correctly both with and without -eofill
specified for example 27. However I didn't spot a difference in the
output. Maybe you can check it if you know how it should look

>
>>
>> Something that I often wondered with regards to these options - why
>> are they not dealt with via plP_state? These are things that change
>> the state of the stream and then all the buffer recording would be
>> performed in one location. Also I tend to feel that a function
>> plsfillrule( PLINT rule ) would be much more intuitive than messing
>> around with strings and calling plparseopts(). Similarly with other
>> options like setting the driver etc.
>>
>> So, I think the best way to fix this is to have the various args.c
>> routines call plP_state() to pass the information in question to the
>> drivers and get it recorded to the buffer.
>
>
> If I remember correctly, Andrew Ross tried (way back when) to
> implement what he thought were some important yet simplifying changes
> to the src/plargs.c code, but he could not get them to work so had to
> reluctantly abandon that development effort despite his huge
> familiarity with the PLplot code at that time.  So that is
> simultaneously a warning about the complexity of the plargs.c
> implemention and a huge motivation to reimplement it in a way that is
> much easier to understand.  And if it turns out the -eofill issue with
> wxwidgets is because of some subtle issue with src/plargs.c that is
> another big motivation to reimplement that code.
>
> Also, if you are going to tackle this project you (and Jim) should
> probably also look hard at Maurice's historical suggestion concerning
> streams which was as follows:
>
> ___________________________
> Date: Tue, 10 Dec 2002 02:52:43 -0600 (CST)
> From: Maurice LeBrun <mj...@ga...>
> To: Alan W. Irwin <ir...@be...>
> Cc: PLplot development list <Plp...@li...>
> Subject: Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I
> am having second thoughts
>
> I can't tell you the specific answer to your questions due to how maniacally
> busy I am these days (having just joined Lightspeed Semiconductor), but I
> can
> elucidate some of the plplot design ideas that have historically been
> un-documented.  And, I can give it in an object-oriented context, which
> (because it is "canonical") is a lot nicer than the "this is the way it
> should
> work" approach I've used historically. :)
>
> This also includes proposals for change to how we do it now -- i.e. the
> behavior of plinit().  I've always been somewhat bothered by the way stream
> 0
> vs stream N is handled (this bugged me back in '94 but I wasn't exactly
> swimming in free time then either).
>
> When plplot starts, you have the statically pre-allocated stream, stream 0.
> Yes the stream 0 that I hate b/c it's not allocated on the heap like a
> proper
> data-structure/object (in the plframe widget I automatically start from
> stream
> 1).
>
> So stream 0 is like a class definition and an instance rolled into one.
> What
> I think we need to do is get rid of the "instance" part of this and leave
> stream 0 as a "class definition" only.  In this case all the command line
> arguments and initial pls...() calls (before plinit) serve to override the
> default initializion of the class variables, i.e. set stream 0 parameters
> only
>
> In other words, stream 0 becomes the template for all plplot streams.  You
> can
> use it, but once you've called plinit() you have your own "instance" of the
> plplot "object" -- i.e. you have a new stream with all the relevant state
> info
> copied from stream 0.  If you change it, it dies when your stream dies with
> plend1().
> If you really want to change stream 0 (i.e. the "plplot object" "class
> data")
> you can always set your stream number to 0 and fire away.
>
> To summarize:
>
> plinit() creates a new stream, copied from stream 0
> plend1() deletes that stream
> plend() deletes all streams, except of course stream 0 which is "class data"
>
> ___________________________
>
> Maurice's idea was never implemented, but if this idea excites you and
> you would feel it would simplify rewriting src/plargs.c, then you (or
> Jim) should do the streams change first, and if that passes all
> comprehensive tests (which I would be happy to help with), then do the
> rewrite of src/plargs.c afterwards.
>
> @Phil and Jim:
>
> Anyhow, I strongly encourage you to try anything you like here with
> streams and src/plargs.c with the obvious caveats that the resulting
> code should be easier to understand and give as good or better results
> than the current code when comprehensive tests are applied.  It also
> "would be nice" if these changes solved the original problem that
> started this discussion which is to get the -eofill option to work
> properly for -dev wxwidgets, but we don't have the knowledge at this
> stage to decide whether that fix is orthogonal or not to the discussed
> changes in streams and src/plargs.c so "time will tell" on that issue.

Hmm, I do think the initialisation is a bit messy, but I am unlikely
to find the time soon to look at this. I think the best strategy long
term would be to pass the PLStream out to the user as an opaque void
*, then have them pass it back in for each API call. This would remove
the global plsc variable which I think is important long term if we
ever want to be intrastream thread safe but this would be a huge API
change. This is the way libcurl works by the way.

[Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

On 2017-09-30 15:06+0100 Phil Rosenberg wrote:

> Hi Alan
>
>
> On 30 September 2017 at 07:31, Alan W. Irwin <ir...@be...> wrote:
>> On 2017-09-30 02:27+0100 p.d...@gm... wrote:
>>
>>> I suspect this will be a bug in the render buffer, where the fill
>>
>> method is not correctly stored in or read from the buffer. You can
>> check this by doing a plreplot with and device and seeing if the
>> correct behaviour is maintained.
>>
>> To Phil and Jim:
>>
>> @Jim:
>>
>> I am specifically also addressing you in this discussion because of
>> your knowledge of the plbuf code so I hope you will be able to reply
>> to the final question below.
>>
>>
>> Also, I have some contradictory evidence regarding what you suspect
>> above.  For example when I search src/plbuf.c for "eofill" there is
>> nothing.  Also, when I search that code for anything to do with fills,
>> the fill state appears to only include information concerning discrete
>> fills (with line patterns as in example 15) rather than information
>> like pls->dev_eofill that is needed for solid fills.  So I suspect
>> adding that information to the fill state might solve this issue.
>>
>> However, without attempting to make such a change (yet) if I run
>>
>> examples/c/x27c -dev qtwidget -eofill
>>
>> or
>>
>> examples/c/x27c -dev xwin -eofill
>>
>> I get the correct behaviour (an odd-even rule fill) regardless of
>> whether I resize the GUI or call plreplot after each call to
>> spiro in examples/c/x27c.c.  Aren't both of those actions supposed
>> to use the plbuf code to replot the buffer?  And from the above
>> search of the src/plbuf.c code how is it possible that pls->dev_eofill is
>> used properly by this code when no
>> reference to that exists within that code.
>>
>> @Phil and Jim:
>>
>> I obviously must be missing something about the plbuf code, but what?
>>
>
>
> Having just had a quick look at the code, args.c has no mention of the
> buffer at all. I suspect that what is happening with your test case is
> that even when the buffer is parsed the same plStream struct is used
> with the flag correctly set. The buffer will never overwrite this flag
> because it never recorded it in the first place.

Hi Phil:

Your reply inadvertently dropped Jim and the list from the addressees so
I have reinstated those for obvious reasons.  I have also changed the
subject line to the current topics that have been raised during this
discussion.

Your above remark does appear to give a rational explanation of why
the above experiments worked. Therefore, there must be something else
special to the -dev wxwidgets case that makes that case not work.  By
the way, other command-line options such as

examples/c/x27c -dev wxwidgets -geometry 300x200

do work fine for -dev wxwidgets so the issue with the -eofill option
with -dev wxwidgets is likely not a general command-line option issue
with -dev wxwidgets but something specific about how the -eofill
option is handled for the -dev wxwidgets case.

>
> Something that I often wondered with regards to these options - why
> are they not dealt with via plP_state? These are things that change
> the state of the stream and then all the buffer recording would be
> performed in one location. Also I tend to feel that a function
> plsfillrule( PLINT rule ) would be much more intuitive than messing
> around with strings and calling plparseopts(). Similarly with other
> options like setting the driver etc.
>
> So, I think the best way to fix this is to have the various args.c
> routines call plP_state() to pass the information in question to the
> drivers and get it recorded to the buffer.

If I remember correctly, Andrew Ross tried (way back when) to
implement what he thought were some important yet simplifying changes
to the src/plargs.c code, but he could not get them to work so had to
reluctantly abandon that development effort despite his huge
familiarity with the PLplot code at that time.  So that is
simultaneously a warning about the complexity of the plargs.c
implemention and a huge motivation to reimplement it in a way that is
much easier to understand.  And if it turns out the -eofill issue with
wxwidgets is because of some subtle issue with src/plargs.c that is
another big motivation to reimplement that code.

Also, if you are going to tackle this project you (and Jim) should
probably also look hard at Maurice's historical suggestion concerning
streams which was as follows:

___________________________
Date: Tue, 10 Dec 2002 02:52:43 -0600 (CST)
From: Maurice LeBrun <mj...@ga...>
To: Alan W. Irwin <ir...@be...>
Cc: PLplot development list <Plp...@li...>
Subject: Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

I can't tell you the specific answer to your questions due to how maniacally
busy I am these days (having just joined Lightspeed Semiconductor), but I can
elucidate some of the plplot design ideas that have historically been
un-documented.  And, I can give it in an object-oriented context, which
(because it is "canonical") is a lot nicer than the "this is the way it should
work" approach I've used historically. :)

This also includes proposals for change to how we do it now -- i.e. the
behavior of plinit().  I've always been somewhat bothered by the way stream 0
vs stream N is handled (this bugged me back in '94 but I wasn't exactly
swimming in free time then either).

When plplot starts, you have the statically pre-allocated stream, stream 0.
Yes the stream 0 that I hate b/c it's not allocated on the heap like a proper
data-structure/object (in the plframe widget I automatically start from stream
1).

So stream 0 is like a class definition and an instance rolled into one.  What
I think we need to do is get rid of the "instance" part of this and leave
stream 0 as a "class definition" only.  In this case all the command line
arguments and initial pls...() calls (before plinit) serve to override the
default initializion of the class variables, i.e. set stream 0 parameters only

In other words, stream 0 becomes the template for all plplot streams.  You can
use it, but once you've called plinit() you have your own "instance" of the
plplot "object" -- i.e. you have a new stream with all the relevant state info
copied from stream 0.  If you change it, it dies when your stream dies with
plend1().
If you really want to change stream 0 (i.e. the "plplot object" "class data")
you can always set your stream number to 0 and fire away.

To summarize:

plinit() creates a new stream, copied from stream 0
plend1() deletes that stream
plend() deletes all streams, except of course stream 0 which is "class data"

___________________________

Maurice's idea was never implemented, but if this idea excites you and
you would feel it would simplify rewriting src/plargs.c, then you (or
Jim) should do the streams change first, and if that passes all
comprehensive tests (which I would be happy to help with), then do the
rewrite of src/plargs.c afterwards.

@Phil and Jim:

Anyhow, I strongly encourage you to try anything you like here with
streams and src/plargs.c with the obvious caveats that the resulting
code should be easier to understand and give as good or better results
than the current code when comprehensive tests are applied.  It also
"would be nice" if these changes solved the original problem that
started this discussion which is to get the -eofill option to work
properly for -dev wxwidgets, but we don't have the knowledge at this
stage to decide whether that fix is orthogonal or not to the discussed
changes in streams and src/plargs.c so "time will tell" on that 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] I am having trouble figuring out why the -eofill command-line optionis being ignored for -dev wxwidgets

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

On 2017-09-30 02:27+0100 p.d...@gm... wrote:

> I suspect this will be a bug in the render buffer, where the fill
method is not correctly stored in or read from the buffer. You can
check this by doing a plreplot with and device and seeing if the
correct behaviour is maintained.

To Phil and Jim:

@Jim:

I am specifically also addressing you in this discussion because of
your knowledge of the plbuf code so I hope you will be able to reply
to the final question below.

@Phil:

Thanks for your explanation of why rendering operations would be
no-ops when using gdb on an example such as

examples/c/x27c

for the -dev wxwidgets case.

Also, I have some contradictory evidence regarding what you suspect
above.  For example when I search src/plbuf.c for "eofill" there is
nothing.  Also, when I search that code for anything to do with fills,
the fill state appears to only include information concerning discrete
fills (with line patterns as in example 15) rather than information
like pls->dev_eofill that is needed for solid fills.  So I suspect
adding that information to the fill state might solve this issue.

However, without attempting to make such a change (yet) if I run

examples/c/x27c -dev qtwidget -eofill

or

examples/c/x27c -dev xwin -eofill

I get the correct behaviour (an odd-even rule fill) regardless of
whether I resize the GUI or call plreplot after each call to
spiro in examples/c/x27c.c.  Aren't both of those actions supposed
to use the plbuf code to replot the buffer?  And from the above
search of the src/plbuf.c code how is it possible that 
pls->dev_eofill is used properly by this code when no
reference to that exists within that code.

@Phil and Jim:

I obviously must be missing something about the plbuf code, but what?

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] [Bug] Plmap omits lines at the left hand side ofthe map

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

On 2017-09-30 02:39+0100 p.d...@gm... wrote:

>
>
> Sent from my Windows 10 phone
>
> From: Alan W. Irwin
> Sent: 29 September 2017 20:31
> To: Phil Rosenberg
> Cc: Mark de Wever; plplot-dev
>
>
>> For those who may now how plfill works a bit better than me, something
>> that is supported by shapefiles, but currently not by plmap, is holes.
>> A polygon in a shapefile consists of multiple parts and clockwise
>> parts are filled whereas anticlockwise parts are holes. Is this
>> something we can do relatively easily with plfill or is it not really
>> doable?
>
> I don't think that such a major change to plfill would be a good idea.
> For example, calls to plsurf3d (example 8) and plshades (example 16)
> end up at the lowest level as many different calls to plfill where
> presumably some end up as anti-clockwise fills and some end up
> as clockwise fills in difficult-to-predict ways.
>
> I didn't mean to suggest changing plfill behaviour, just wondered if there was some way already to do this.
>
> Therefore, would it be possible for you to honor this shapefile
> convention by simply not calling plfill from inside the plmap*
> routines whenever they run into an anticlockwise part and by
> changing our DocBook documentation of those routines appropriately?
>

> I don't think this works as we have to not render the holes in the
first instance. E.g imagine an island with a lake. We want to fill
just the land, it the lake. This would be a clockwise polygon for the
island and an anticlockwise one for the lake. I think the only way to
do this would be to convert the polygon with its holes to a single
polygon, kind of like a c shape outline but with the ends of the c
touching to make it like an o.

Hi Phil:

It sounds like you are asking if we have the ability to fill a simple
(i.e. non self-intersecting, see
<https://en.wikipedia.org/wiki/Simple_polygon>) polygon A
everywhere other than where it intersects with a simple polygon B.

(For your example A would be the polygon describing the island
outline, and B would be the polygon describing the lake outline within
that island.)

If I have described that "not-intersect" case correctly, then the
answer to your question is we do not currently have the ability to
solve that problem.  Which is another example of the truism
that dealing with fill issues always seems to be difficult.

However, that described problem could be solved
with logic rather similar to that needed for solving the general
problem of filling the intersection of two simple polygons.  And we
already do have that capability almost entirely implemented
with the fill_intersection_polygon
routine in src/plfill.c that I implemented back in 2009. That logic
was compiled only if the USE_FILL_INTERSECTION_POLYGON macro is
#defined, and the last commit message that mentioned
USE_FILL_INTERSECTION_POLYGON is as follows:

commit b8be9fcf8de6f5263bdd356a8745ba5878fc3036
Author: Alan W. Irwin <ai...@us...>
Date:   Mon Dec 28 17:41:45 2009 +0000

     Fix cases where split 1/split 2 encompasses all/none of the polygon 2
     vertices.  This -DUSE_FILL_INTERSECTION_POLYGON=ON change finally gives good
     results for the first four pages of example 25, if the clip limits are
     shifted around to avoid the case (not implemented yet) where polygon
     crossings occur at vertices.

     So it appears I have the basic recursive algorithm working correctly, but
     there are some details (e.g., polygon crossings at vertices) still to be
     implemented.

However, I think that is near the last commit where
I worked on fill_intersection_polygon, because if I recall correctly
if that logic was used for the large number of plfill calls we
generate with our standard examples 8 and 16, I ran into bugs in the
PL_NEAR_* logic.  Therefore, I "temporarily" suspended working on that
logic and never got back to it.

However, two years ago (see your posts with the subject line "Bug in
notcrossed() function of plfill.c" you discovered that our ordinary
fill logic (used when USE_FILL_INTERSECTION_POLYGON is not #defined)
also sometimes fails because of a PL_NEAR_PARALLEL bug.  I have been
putting off solving that bug (although it is certainly on my ToDo list
for this release cycle). However, once that is solved, and the case of
polygon crossings at vertices solved, then it is certainly possible
that fill_intersection_polygon would just work as designed for all our
examples.

Of course, getting this all straightened out is going to take some
substantial time.  So for now, I think you should ignore this shapelib
"hole" convention in the plmap routines while documenting this
limitation as well.  But after the current PL_NEAR_PARALLEL bug is
definitively fixed, you might want to take a look at the
fill_intersection_polygon routine again to see whether you think it is
worth reviving and modifying for the "not-intersect" case that appears
to sometimes be important for shapelib maps.

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
__________________________