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

[Phil Rosenberg]

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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

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

x27c.c.gz
Description: Simplified source code to illustrate the bug
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

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

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Phil Rosenberg]

Fixed

My test for initialisation was incorrect.

On 1 October 2017 at 20:50, Alan W. Irwin  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.s

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

[Phil Rosenberg]

On 1 October 2017 at 21:01, Alan W. Irwin  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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

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


On 1 October 2017 at 21:01, Alan W. Irwin  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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Jim Dishaw]

> On Sep 30, 2017, at 2:35 PM, Alan W. Irwin  wrote:
> 
> On 2017-09-30 15:06+0100 Phil Rosenberg wrote:
> 
>> Hi Alan
>> 
>> 
>> On 30 September 2017 at 07:31, Alan W. Irwin  
>> wrote:
>>> On 2017-09-30 02:27+0100 p.d.rosenb...@gmail.com 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
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

[Alan W. Irwin]

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
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel