plplot-devel

[Plplot-devel] Release status

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

To get the ball rolling on the promised Monday discussion of the
current release status, and what that implies for the release date,
here is what I have been up to this weekend.

I decided to comprehensively test PLplot on Linux using the epa_build
procedure (documented in cmake/epa_build/README) for doing that.  That
procedure ran into memory management issues for Qt5 that happen
(according to valgrind) whenever an attempt is made to exit Plplot or
(curiously) whenever an attempt is made to exit the cursor-mode OK
button for qt_example.  These memory management issues do not occur at
all for Qt4 (which likely explains Andrew's reported success with
preliminary testing of PLplot for this release).  But for Qt5, these
issues resulted in at least one segfault which motivated the valgrind
investigation that showed these specific memory management issues. I
don't think we have changed our exit procedures since the last time I
tested Qt-5.3.1 this way so I suspect the memory management issues
were always there, but they only generated a segfault by luck just
this time.

I then shifted from epa_building Qt 5.3.1 to 5.4.1, but that version
of Qt5 would not even compile!  I then shifted to trying 5.3.2, and
that built without issues, but gave the same memory managment
valgrind-reported errors for the same specific PLplot situations plus the
segfault.  At this stage I don't know whether the issue is in Qt5.3.x or
my epa_build of that software or something else, but what I intend to
do about this for the rest of this release cycle is simply to avoid
(with a WARNING) all qt testing in my "comprehensive" tests when Qt5
is being used to allow me to complete such comprehensive testing.

So tomorrow (Monday my time) I will implement that constraint on no
comprehensive testing of Qt5, and then try the comprehensive test on
Linux of an epa_built PLplot version again.

At this stage it is already clear that at mimimum it is going to be
next weekend (March 7th) for the release date because of everything I
have to do to finish comprehensive testing and a number of other
pre-release steps.  Of course, that ETA is still quite uncertain and
could be even a wekk later.  But I will do another summary of the
situation late tomorrow (Monday) with results depending on whether I
can get all the way through a comprehensive test on Linux tomorrow,
and also depending on reports from Phil and Jim about how their
plwidgets/plbuf and plmeta/plbuf debugging efforts are proceeding.

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] Release status

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

Here is where I think we are.

The deep freeze is still in effect.

I have given up on the possibility of fixing the plend problems this
late in the release cycle which I thought might be a spin-off from
Norm's xwin plend fix that was being discussed.  We will also put off
dealing with that xwin fix itself until post release.

Phil has told me off list that he is swamped so it is unlikely he can
contribute further to this release effort.  Therefore, to deal
partially with that I will write the release notes for wxwidgets, and
let the other wxwidgets documentation issues slide. Also, Jim has
kindly agreed to at least look at the one last release-critical
wxwidgets issue which is to get OLD_WXWIDGETS=ON to work properly.

I am currently dealing with two build-system issues which are (1) the
remaining MSVC visibility issues that I became aware of yesterday (to
fix that all apps need the -DUSINGDLL COMPILE_FLAGS property set for
the shared library case), and (2) some target dependency logic that
doesn't work correctly for the installed examples build-system case
that is screwing up my attempts to do comprehensive testing on Linux.

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Release status

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

On 2015-03-19 09:23-0600 Orion Poplawski wrote:

> On 03/19/2015 12:41 AM, Alan W. Irwin wrote:
>> On 2015-03-18 21:26-0600 Orion Poplawski wrote:
>>
>>> On 03/18/2015 08:41 PM, Alan W. Irwin wrote:
>>>> Here is where I think we are.
>>>
>>> The issues in Fedora land are:
>>>
>>> - The octave+swig+UTF-8 issue I just reported
>>> - The move to the cairo2 ocaml bindings.  We'll need to get this packaged in
>>> Fedora to support it.
>>
>> Thanks for that report.  If you test 5.10.0 the same way do you get
>> similar results?  That additional test would help to sort out whether
>> these issues have been recently introduced in PLplot or whether the
>> latest Fedora environment is somewhow incompatible with PLplot
>> regardless of PLplot version.
>>
>> Alan
>
> Yeah, it's Fedora.  I also replied to Jim's email.

That is good to know from our perspective of just making a new
release, but I am also curious what could be causing the issue on
Fedora.  I think you have already mentioned a gcc-5 bug as a
possibility, but could it also be a regression in behaviour for some
new swig or octave version?

I have had several interactions with the octave developers, and in my
opinion they are somewhat blind to the possibilities with UTF-8.  For
example, our own octave plplot documentation is written in UTF-8 (for
the math symbols), and it turned out that just worked in octave, but
their internationalization team did not appear to be interested in the
slightest in that obvious possibility for translating their own
documentation strings to other languages.

Anyhow, in my opinion it is quite possible that octave developers have
introduced a UTF-8-related regression since they use UTF-8 so little
themselves.

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] Release status

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

On Mar 19, 2015, at 12:57 PM, "Alan W. Irwin" <ir...@be...> wrote:

> On 2015-03-19 09:23-0600 Orion Poplawski wrote:
> 
>> On 03/19/2015 12:41 AM, Alan W. Irwin wrote:
>>> On 2015-03-18 21:26-0600 Orion Poplawski wrote:
>>> 
>>>> On 03/18/2015 08:41 PM, Alan W. Irwin wrote:
>>>>> Here is where I think we are.
>>>> 
>>>> The issues in Fedora land are:
>>>> 
>>>> - The octave+swig+UTF-8 issue I just reported
>>>> - The move to the cairo2 ocaml bindings.  We'll need to get this packaged in
>>>> Fedora to support it.
>>> 
>>> Thanks for that report.  If you test 5.10.0 the same way do you get
>>> similar results?  That additional test would help to sort out whether
>>> these issues have been recently introduced in PLplot or whether the
>>> latest Fedora environment is somewhow incompatible with PLplot
>>> regardless of PLplot version.
>>> 
>>> Alan
>> 
>> Yeah, it's Fedora.  I also replied to Jim's email.

I am installing Fedora rawhide in a VM and will see if I can track down the bug.

> 
> That is good to know from our perspective of just making a new
> release, but I am also curious what could be causing the issue on
> Fedora.  I think you have already mentioned a gcc-5 bug as a
> possibility, but could it also be a regression in behaviour for some
> new swig or octave version?
> 

My hypothesis is that a unicode string that is encoded in a non UTF-8 format is being passed to plP_text()

Re: [Plplot-devel] Release status

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

To add to that regarding wxWidgets
The current master branch with wxWidgets still has some issues that I
would not be happy releasing. Most importantly is how we go about
selecting whether to use a user wxDC or use the wxPLViewer. After
Friday's discussion I have added a plsdevdata function which can be
used to pass the dc in. However somehow I appear to have broken
something else and when I tested on Ubuntu I got some very strange
issues when trying to select the wxWidgets device with an error
message that implied that the xwin device was selected instead
followed by some garbage characters.  So I now need to try and ppick
through my commit to work out what has caused this break. The moral
here being commit often then git bisect becomes your friend.

Also Alan I pulled down your character changes and they cause issues
on Windows. I now get a popup error message about fonts not supporting
utf8 encoding.

I'm sorry the description here isn't great. I'm also sorry in advance
that I probably won't be on email most of today as I have a very busy
day ahead. But the take home message unfortunately is that the
wxWidgets driver isn't ready yet.

Phil

On 2 March 2015 at 07:56, Alan W. Irwin <ir...@be...> wrote:
> To get the ball rolling on the promised Monday discussion of the
> current release status, and what that implies for the release date,
> here is what I have been up to this weekend.
>
> I decided to comprehensively test PLplot on Linux using the epa_build
> procedure (documented in cmake/epa_build/README) for doing that.  That
> procedure ran into memory management issues for Qt5 that happen
> (according to valgrind) whenever an attempt is made to exit Plplot or
> (curiously) whenever an attempt is made to exit the cursor-mode OK
> button for qt_example.  These memory management issues do not occur at
> all for Qt4 (which likely explains Andrew's reported success with
> preliminary testing of PLplot for this release).  But for Qt5, these
> issues resulted in at least one segfault which motivated the valgrind
> investigation that showed these specific memory management issues. I
> don't think we have changed our exit procedures since the last time I
> tested Qt-5.3.1 this way so I suspect the memory management issues
> were always there, but they only generated a segfault by luck just
> this time.
>
> I then shifted from epa_building Qt 5.3.1 to 5.4.1, but that version
> of Qt5 would not even compile!  I then shifted to trying 5.3.2, and
> that built without issues, but gave the same memory managment
> valgrind-reported errors for the same specific PLplot situations plus the
> segfault.  At this stage I don't know whether the issue is in Qt5.3.x or
> my epa_build of that software or something else, but what I intend to
> do about this for the rest of this release cycle is simply to avoid
> (with a WARNING) all qt testing in my "comprehensive" tests when Qt5
> is being used to allow me to complete such comprehensive testing.
>
> So tomorrow (Monday my time) I will implement that constraint on no
> comprehensive testing of Qt5, and then try the comprehensive test on
> Linux of an epa_built PLplot version again.
>
> At this stage it is already clear that at mimimum it is going to be
> next weekend (March 7th) for the release date because of everything I
> have to do to finish comprehensive testing and a number of other
> pre-release steps.  Of course, that ETA is still quite uncertain and
> could be even a wekk later.  But I will do another summary of the
> situation late tomorrow (Monday) with results depending on whether I
> can get all the way through a comprehensive test on Linux tomorrow,
> and also depending on reports from Phil and Jim about how their
> plwidgets/plbuf and plmeta/plbuf debugging efforts are proceeding.
>
> 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
> __________________________
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Release status

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

On 2015-03-02 09:33-0000 Phil Rosenberg wrote:

> [....]But the take home message unfortunately is that the
> wxWidgets driver isn't ready yet.

Hi Phil:

If it is any consolation, my comprehensive testing and other
pre-release items I have to do are in similar shape.  Also, note that
once Jim's new plmeta/plrender is text-simplified along the lines I
discussed with him, it should be a great tool for helping to find the
remaining plbuf issues which should simplify your life.

So for now, the release date target is still quite uncertain, i.e.,
next weekend at the earliest.  However, let's review that again near
the end of this week to see where we stand.

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] Release status

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

Hi Phil:

Your latest commit (f6dcf09703 = "Fixed reentrant behaviour in
wxPLViewer...") mostly works.  For example, it builds without
issues, and examples 1 and 4 (the first two run by the
test_c_wxwidgets target) appear to work at run-time with
no obvious issues.  However, example 8 now has a subtle
pattern superimposed on the surface that wasn't there
before (and which is not there for any other device), and example 14
segfaults, i.e.,

software@raven> examples/c/x14c -dev wxwidgets

*** PLPLOT ERROR, ABORTING OPERATION ***
Unkown error in plD_init_wxwidgets., aborting operation
Segmentation fault

The valgrind summary for examples 1, 4, and 8 is

ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

which is good.  But the equivalent result for example 14 is

ERROR SUMMARY: 1586 errors from 50 contexts (suppressed: 6 from 6)

I can give you the full report if you like, but for now I only
give you the first part of that report below since that is probably the
part of the report that you will find of most use for tracking down
the issue.
==23600== Memcheck, a memory error detector
==23600== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==23600== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==23600== Command: examples/c/x14c -dev wxwidgets
==23600==

*** PLPLOT ERROR, ABORTING OPERATION ***
Unkown error in plD_init_wxwidgets., aborting operation
==23600== Invalid read of size 8
==23600==    at 0x6E26914: wxPLDevice::BeginPage(PLStream*) (wxwidgets_dev.cpp:867)
==23600==    by 0x6E22848: plD_bop_wxwidgets(PLStream*) (wxwidgets.cpp:352)
==23600==    by 0x4E51FFC: plP_bop (plcore.c:211)
==23600==    by 0x4E56EC3: c_plinit (plcore.c:2271)
==23600==    by 0x4017B9: main (x14c.c:84)
==23600==  Address 0x6a6aba8 is 8 bytes inside a block of size 1,312 free'd
==23600==    at 0x4C279DC: operator delete(void*) (vg_replace_malloc.c:457)
==23600==    by 0x6E224BE: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
==23600==    by 0x4E51DEC: plP_init (plcore.c:144)
==23600==    by 0x4E56EBE: c_plinit (plcore.c:2270)
==23600==    by 0x4017B9: main (x14c.c:84)

Line 84, of course, is the plinit call, and the only difference there
with other examples use of plinit is the use of the geometry option.

Indeed, I get the same issue for example 1 when -geometry is specified
on the command line:

examples/c/x01c -dev xwin -geometry 800x600
PLplot library version: 5.10.0

*** PLPLOT ERROR, ABORTING OPERATION ***
Unkown error in plD_init_wxwidgets., aborting operation
Segmentation fault

In sum there are 4 issues here introduced or exposed by your recent series of
commits.

(1) Bad abort operation for the "Unkown error...." which causes
substantial memory managment issues.
(2) Error message itself needs a spelling change: Unkown --> Unknown
(3) regression for -geometry option
(4) regression of an added surface pattern artifact for example 8

I suspect issues (1) and (2) have been with us since the start of your
new wxwidgets development, and we are just lucky that issue (3)
provides the test case that exposes (1) and (2).  So to make sure that
the fixes for (1) and (2) are correct, I suggest you fix them before fixing
(3).

Also, please don't get too discouraged by these small but annoying
issues we both keep finding. Instead, just keep plugging away at the
fixes no matter how trivial (such as the above spelling fix).

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] Release status

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

Thanks for the heads up Alan, especially the Valgrind output and the
reproduction method. Very handy!

Regardign the surface pattern artefacts. I had already spotted them
and x08.1 is on the trello page. It appears to be a bad antiaiasing
issue or rounding issue, basically adjacent polygons don't quite fit
next to each other correctly and you are seeing through the gaps. To
be honest right now I don't have a good answer to this.

Regarding the old and new wxWidgets, I think that is an excellent idea.

Phil

On 4 March 2015 at 19:36, Alan W. Irwin <ir...@be...> wrote:
> Hi Phil:
>
> Your latest commit (f6dcf09703 = "Fixed reentrant behaviour in
> wxPLViewer...") mostly works.  For example, it builds without
> issues, and examples 1 and 4 (the first two run by the
> test_c_wxwidgets target) appear to work at run-time with
> no obvious issues.  However, example 8 now has a subtle
> pattern superimposed on the surface that wasn't there
> before (and which is not there for any other device), and example 14
> segfaults, i.e.,
>
> software@raven> examples/c/x14c -dev wxwidgets
>
> *** PLPLOT ERROR, ABORTING OPERATION ***
> Unkown error in plD_init_wxwidgets., aborting operation
> Segmentation fault
>
> The valgrind summary for examples 1, 4, and 8 is
>
> ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
>
> which is good.  But the equivalent result for example 14 is
>
> ERROR SUMMARY: 1586 errors from 50 contexts (suppressed: 6 from 6)
>
> I can give you the full report if you like, but for now I only
> give you the first part of that report below since that is probably the
> part of the report that you will find of most use for tracking down
> the issue.
> ==23600== Memcheck, a memory error detector
> ==23600== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==23600== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==23600== Command: examples/c/x14c -dev wxwidgets
> ==23600==
>
> *** PLPLOT ERROR, ABORTING OPERATION ***
> Unkown error in plD_init_wxwidgets., aborting operation
> ==23600== Invalid read of size 8
> ==23600==    at 0x6E26914: wxPLDevice::BeginPage(PLStream*)
> (wxwidgets_dev.cpp:867)
> ==23600==    by 0x6E22848: plD_bop_wxwidgets(PLStream*) (wxwidgets.cpp:352)
> ==23600==    by 0x4E51FFC: plP_bop (plcore.c:211)
> ==23600==    by 0x4E56EC3: c_plinit (plcore.c:2271)
> ==23600==    by 0x4017B9: main (x14c.c:84)
> ==23600==  Address 0x6a6aba8 is 8 bytes inside a block of size 1,312 free'd
> ==23600==    at 0x4C279DC: operator delete(void*) (vg_replace_malloc.c:457)
> ==23600==    by 0x6E224BE: plD_init_wxwidgets(PLStream*) (wxwidgets.cpp:174)
> ==23600==    by 0x4E51DEC: plP_init (plcore.c:144)
> ==23600==    by 0x4E56EBE: c_plinit (plcore.c:2270)
> ==23600==    by 0x4017B9: main (x14c.c:84)
>
> Line 84, of course, is the plinit call, and the only difference there
> with other examples use of plinit is the use of the geometry option.
>
> Indeed, I get the same issue for example 1 when -geometry is specified
> on the command line:
>
> examples/c/x01c -dev xwin -geometry 800x600
> PLplot library version: 5.10.0
>
> *** PLPLOT ERROR, ABORTING OPERATION ***
> Unkown error in plD_init_wxwidgets., aborting operation
> Segmentation fault
>
> In sum there are 4 issues here introduced or exposed by your recent series
> of
> commits.
>
> (1) Bad abort operation for the "Unkown error...." which causes
> substantial memory managment issues.
> (2) Error message itself needs a spelling change: Unkown --> Unknown
> (3) regression for -geometry option
> (4) regression of an added surface pattern artifact for example 8
>
> I suspect issues (1) and (2) have been with us since the start of your
> new wxwidgets development, and we are just lucky that issue (3)
> provides the test case that exposes (1) and (2).  So to make sure that
> the fixes for (1) and (2) are correct, I suggest you fix them before fixing
> (3).
>
> Also, please don't get too discouraged by these small but annoying
> issues we both keep finding. Instead, just keep plugging away at the
> fixes no matter how trivial (such as the above spelling fix).
>
>
> 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] Release status

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

Hi Phil:

>From all your commits last week it appears you are continuing to make
progress on fixing the wxwidgets bugs, but I have no idea how much
more (if anything) you want to do before release.  Also, I rely on you
to evaluate Jim's Saturday patch series to decide which of his commits
should be applied before the release and which should be applied
after.

I am looking forward to that feedback from you so I will be in a
better position to make a meaningful estimate of the release date.

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] Release status

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

Hi Alan
>>
>> (1) Bad abort operation for the "Unkown error...." which causes
>> substantial memory managment issues.
>> (2) Error message itself needs a spelling change: Unkown --> Unknown
>> (3) regression for -geometry option
>> (4) regression of an added surface pattern artifact for example 8
>>

Issue (4) is now solved. Issue (2) I will fix now.

Issue (1)/(3) turned out to be some bad cleanup of a thrown exception
which is a 1 line fix I am about to commit.

However, perhaps more important was why the exception was thrown. It
was an exception I coded in to be thrown when the user set the size of
the canvas, but failed to set the dpi. (On windows I get a rather more
specific error message, not sure why the default unknown error message
is displayed on linux). I guess pragmatically I should use the same
default dpi as if the size hasn't been set, but I thought that if the
user has set the size then the dpi should be also set to ensure
consistency. This however does make the PLStream::pageset variable
rather useless as it gets set whether or not the dpi is valid.

Anyway, there should be a new commit fixing these issues in about 10 mins.

Phil

Re: [Plplot-devel] Release status

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

Hi Alan

Here is a status update on wxWidgets, but the headline is that I now
feel that the wxWidgets driver is at an appropriate stage for release.

The issues that still exist are on trello, so you can view them is you
want. However I now think that the new driver is of generally the same
quality as the previous one.

Of the remaining issues the ones that I feel are of highest priority are

1) The preservation of the bop state in the buffer
2) 3d text is not quite correctly aligned.
3) Adding wxStream constuctors that mirror plstream constructors.
4) There are some aspect ratio issues with x03, but only when resized
and only on Linux. I think this is related to the rotated orientation.

My understanding is that Jim is doing 1), but if he is busy with other
stuff I'd be happy to sort that. 3) is straightforward and I will do
that this evening. 2) is a bit trickier as I don't really have a good
understanding of why it is wrong - it uses the same maths as the old
driver, but I wonder if the aspect ratio code has changed (for fixed
aspect) and there is some similar change required in the text. As
issue 4 is a rotated plot I consider this a bit of an edge case for an
interactive driver - it does need fixing, but I can live with it in
the short term.

If you can live with 2 and 4, then we are pretty well ready to go.

One question I had though, is there any different behaviour required
for the no pause state? Currently the driver does not pause at all
regardless of this state. It sends all its data to the viewer then
continues - for the examples it then exits as it reaches the end of
main(), but leaves the viewer open with the plots.

Phil


On 9 March 2015 at 11:37, Phil Rosenberg <p.d...@gm...> wrote:
> Hi Alan
>>>
>>> (1) Bad abort operation for the "Unkown error...." which causes
>>> substantial memory managment issues.
>>> (2) Error message itself needs a spelling change: Unkown --> Unknown
>>> (3) regression for -geometry option
>>> (4) regression of an added surface pattern artifact for example 8
>>>
>
> Issue (4) is now solved. Issue (2) I will fix now.
>
> Issue (1)/(3) turned out to be some bad cleanup of a thrown exception
> which is a 1 line fix I am about to commit.
>
> However, perhaps more important was why the exception was thrown. It
> was an exception I coded in to be thrown when the user set the size of
> the canvas, but failed to set the dpi. (On windows I get a rather more
> specific error message, not sure why the default unknown error message
> is displayed on linux). I guess pragmatically I should use the same
> default dpi as if the size hasn't been set, but I thought that if the
> user has set the size then the dpi should be also set to ensure
> consistency. This however does make the PLStream::pageset variable
> rather useless as it gets set whether or not the dpi is valid.
>
> Anyway, there should be a new commit fixing these issues in about 10 mins.
>
> Phil

Re: [Plplot-devel] Release status

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

Hi Alan
Unfortunately you can probably ignore that email.

On my work centos machine I tried running an example under the xwin
device - thinking that a buffer problem would be likely to show up
there as well as in the tk device. I then got just a black window and
a hang. Moving back in time I found that the commit I listed gave the
same black window and hang but the one before gave fine results.
I've just looked at this from home and both on my Ubuntu PC and my
Centos PC (both SSH'd in with x forwarding from Cygwin) ant the tip of
master runs fin in both cases.

So now I am utterly confused and have not got the tk driver running.

Phil

On 11 March 2015 at 19:27, Alan W. Irwin <ir...@be...> wrote:
> On 2015-03-11 12:32-0000 Arjen Markus wrote:
>
>> Hi Phil,
>
>
>> The message is due to a security problem in the X server if you use
>
> the default security settings. I know of it but I do not have a handy
> receipe to solve it. Tk's send command allows you to send any command
> to the X host, which is why this message pops up.
>
> Hi Phil:
>
> I think Arjen is right.  Hopefully Andrew (who uses Ubuntu a lot for
> testing) will know the recipe to properly authorize -dev tk on Ubuntu.  For
> some reason I have never run into this authorization issue on Debian
> stable, but that is probably because (by design) Debian default
> security settings are quite weak.
>
> I also noticed in another message that you presumably had solved that
> authorization issue and found a commit (id = 1e402417c1f) that your
> tests showed introduced a -dev tk rendering regression, but I cannot
> figure out what that regression might be so could you describe it?
>
> The issue is that both 1e402417c1f^ and 1e402417c1f give single GUI
> -dev tk results here that both look fine to me (other than the zoom
> issue) for example 1 while for master tip I get two GUI's (one with
> the Tk decorations and no plot, and the other an undecorated xwin-like
> plot).  I have attached a screenshot of that master tip result so you will
> know exactly what I am referring too.
>
> I will now do my own git bisects to find when the zoom issue was
> introduced and when the two-GUI issue was introduced.
>
>
> 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] Release status

[Andrew R. <and...@us...>]

Phil,

Try reading http://wiki.tcl.tk/1829 for the tk problem. It suggests an 
issue with your X security which you probably want to investigate anyway.

For me things "just work" with Ubuntu. Though I should perhaps be more
precise that it is Kubuntu (with KDE as the window manager) that I use 
rather than vanilla Ubuntu. I'd be very surprised if X was not set up 
securely by default though.

Andrew

On Wed, Mar 11, 2015 at 08:35:50PM +0000, Phil Rosenberg wrote:
> Hi Alan
> Unfortunately you can probably ignore that email.
> 
> On my work centos machine I tried running an example under the xwin
> device - thinking that a buffer problem would be likely to show up
> there as well as in the tk device. I then got just a black window and
> a hang. Moving back in time I found that the commit I listed gave the
> same black window and hang but the one before gave fine results.
> I've just looked at this from home and both on my Ubuntu PC and my
> Centos PC (both SSH'd in with x forwarding from Cygwin) ant the tip of
> master runs fin in both cases.
> 
> So now I am utterly confused and have not got the tk driver running.
> 
> Phil
> 
> On 11 March 2015 at 19:27, Alan W. Irwin <ir...@be...> wrote:
> > On 2015-03-11 12:32-0000 Arjen Markus wrote:
> >
> >> Hi Phil,
> >
> >
> >> The message is due to a security problem in the X server if you use
> >
> > the default security settings. I know of it but I do not have a handy
> > receipe to solve it. Tk's send command allows you to send any command
> > to the X host, which is why this message pops up.
> >
> > Hi Phil:
> >
> > I think Arjen is right.  Hopefully Andrew (who uses Ubuntu a lot for
> > testing) will know the recipe to properly authorize -dev tk on Ubuntu.  For
> > some reason I have never run into this authorization issue on Debian
> > stable, but that is probably because (by design) Debian default
> > security settings are quite weak.
> >
> > I also noticed in another message that you presumably had solved that
> > authorization issue and found a commit (id = 1e402417c1f) that your
> > tests showed introduced a -dev tk rendering regression, but I cannot
> > figure out what that regression might be so could you describe it?
> >
> > The issue is that both 1e402417c1f^ and 1e402417c1f give single GUI
> > -dev tk results here that both look fine to me (other than the zoom
> > issue) for example 1 while for master tip I get two GUI's (one with
> > the Tk decorations and no plot, and the other an undecorated xwin-like
> > plot).  I have attached a screenshot of that master tip result so you will
> > know exactly what I am referring too.
> >
> > I will now do my own git bisects to find when the zoom issue was
> > introduced and when the two-GUI issue was introduced.
> >
> >
> > 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] Release status

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

On 2015-03-09 12:22-0000 Phil Rosenberg wrote:

> Hi Alan
>
> Here is a status update on wxWidgets, but the headline is that I now
> feel that the wxWidgets driver is at an appropriate stage for release.

That is excellent news indeed!

I still have lots on my PLplot agenda so the headline from my
perspective is the release date is still not settled, but I
hope to firm up the date late this week.

There are, of course, still a lot of wxwidgets "would be nices" that
we jointly mention below, but nothing release critical as far as I am
concerned because of the USE_OLD_WXWIDGETS cmake option I discussed
with you (not implemented yet, but I plan to).

For the others here this option will give the users the chance to
choose the old wxwidgets device, associated library, etc., at cmake
time (not run time where there would be a lot of clash issues to sort
out between old and new wxwidgets device). So if one of the issues
below (or some other issue we are unaware of) is a showstopper for
them, we will have provided them a CMake option to go back to using
the old (deprecated) wxwidgets code for at least this release.

More below in context.

>
> The issues that still exist are on trello, so you can view them is you
> want. However I now think that the new driver is of generally the same
> quality as the previous one.
>
> Of the remaining issues the ones that I feel are of highest priority are
>
> 1) The preservation of the bop state in the buffer
> 2) 3d text is not quite correctly aligned.
> 3) Adding wxStream constuctors that mirror plstream constructors.
> 4) There are some aspect ratio issues with x03, but only when resized
> and only on Linux. I think this is related to the rotated orientation.
>
> My understanding is that Jim is doing 1), but if he is busy with other
> stuff I'd be happy to sort that.

Please take a look at his patch series he sent this weekend.  One of those patches
apparently was to fix a wxwidgets issue so part/all of that series may
be exactly what you need, but I am leaving it to you to evaluate which
of his commits should be applied to master now, and which should wait
until post-release (if they don't affect wxwidgets).

3) is straightforward and I will do
> that this evening. 2) is a bit trickier as I don't really have a good
> understanding of why it is wrong - it uses the same maths as the old
> driver, but I wonder if the aspect ratio code has changed (for fixed
> aspect) and there is some similar change required in the text. As
> issue 4 is a rotated plot I consider this a bit of an edge case for an
> interactive driver - it does need fixing, but I can live with it in
> the short term.
>
> If you can live with 2 and 4, then we are pretty well ready to go.

If you can live with them for now, then I can too.  However, I would
appreciate you figuring out what was wrong with my patch to fix the
wide legend box issues for the unicode case. At the time, you said you
were getting complaints from Windows about unicode fonts, but since my
patch simply used a facility you had already developed to determine
physical width and height of the string that would be rendered by the
wxwidgets libraries, I suspect that issue was attributable to other
Windows issues you were having at that exact same time so please take
another look.

> One question I had though, is there any different behaviour required
> for the no pause state? Currently the driver does not pause at all
> regardless of this state. It sends all its data to the viewer then
> continues - for the examples it then exits as it reaches the end of
> main(), but leaves the viewer open with the plots.

I think the fundamental issue here is that new wxwidgets launches a
viewer that runs in a completely detached state.  That can be good in
certain circumstances, but it obviously goes against the paradigm that
is used for every other interactive device.  So I believe the solution
here is to implement a wxwidgets driver option that allows detached
mode (as now), but by default operates in attached mode. Once attached
mode works, then that makes it possible to control the plot directly
from the example, e.g., by specifying the nopause option.  I assume
attached mode would also allow -locate mode to work for example 1,
sort out some of the example 17 issues, etc.

In sum, all of the above are "would-be-nices" in my opinion rather
than showstoppers.  So you are free to tackle as few or many of them
as you like in the next few days, and we should look again where we
jointly stand near the end of this week.

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] Release status

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

Phil said:

> Hi Alan
> Unfortunately you can probably ignore that email.

> On my work centos machine I tried running an example under the xwin
device - thinking that a buffer problem would be likely to show up
there as well as in the tk device. I then got just a black window and
a hang. Moving back in time I found that the commit I listed gave the
same black window and hang but the one before gave fine results.
I've just looked at this from home and both on my Ubuntu PC and my
Centos PC (both SSH'd in with x forwarding from Cygwin) ant the tip of
master runs fin in both cases.

> So now I am utterly confused and have not got the tk driver running.

My guess is that SSH with X forwarding has figured out all the X
authorization issues, while those may still occur whenever you try to
use direct access.  So I would encourage you to test that hypothesis
by trying -dev tk over an SSH X forwarded connection.  That may allow
you to verify the two-GUI issue for -dev tk for master tip.

Assuming that hypothesis is correct, the change (for direct access for
you) from working screen to black screen from 1e402417c1f^ to
1e402417c1f may not be a regression, but instead the result of
(inadvertently) tightening up the X security model with that plbuf
change.

@Andrew:
I hope you respond to this by advising Phil the best way
to have properly authorized X access when using Ubuntu
directly, checking whether the above plbuf change makes a difference
in your -dev xwin and -dev tk results on Ubuntu, etc.

For what it is worth, for the direct case I am just using the default
X authorization for Debian that you get with the traditional "startx"
method of starting my (KDE) desktop.  In other words, I don't use any
of the xdm, kdm, or gdm3 display-manager methods of starting X for the
direct case, but I am not sure whether that is relevant or not. But
apparently, X is properly authorized by this method at least for
Debian so the plbuf change referred to above has no effect on -dev tk
results for me.

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] Release status

[Andrew R. <and...@us...>]

On Wed, Mar 11, 2015 at 02:30:04PM -0700, Alan Irwin wrote:
> Phil said:
> 
> > Hi Alan
> > Unfortunately you can probably ignore that email.
> 
> > On my work centos machine I tried running an example under the xwin
> device - thinking that a buffer problem would be likely to show up
> there as well as in the tk device. I then got just a black window and
> a hang. Moving back in time I found that the commit I listed gave the
> same black window and hang but the one before gave fine results.
> I've just looked at this from home and both on my Ubuntu PC and my
> Centos PC (both SSH'd in with x forwarding from Cygwin) ant the tip of
> master runs fin in both cases.
> 
> > So now I am utterly confused and have not got the tk driver running.
> 
> My guess is that SSH with X forwarding has figured out all the X
> authorization issues, while those may still occur whenever you try to
> use direct access.  So I would encourage you to test that hypothesis
> by trying -dev tk over an SSH X forwarded connection.  That may allow
> you to verify the two-GUI issue for -dev tk for master tip.
> 
> Assuming that hypothesis is correct, the change (for direct access for
> you) from working screen to black screen from 1e402417c1f^ to
> 1e402417c1f may not be a regression, but instead the result of
> (inadvertently) tightening up the X security model with that plbuf
> change.
> 
> @Andrew:
> I hope you respond to this by advising Phil the best way
> to have properly authorized X access when using Ubuntu
> directly, checking whether the above plbuf change makes a difference
> in your -dev xwin and -dev tk results on Ubuntu, etc.
> 
> For what it is worth, for the direct case I am just using the default
> X authorization for Debian that you get with the traditional "startx"
> method of starting my (KDE) desktop.  In other words, I don't use any
> of the xdm, kdm, or gdm3 display-manager methods of starting X for the
> direct case, but I am not sure whether that is relevant or not. But
> apparently, X is properly authorized by this method at least for
> Debian so the plbuf change referred to above has no effect on -dev tk
> results for me.

Actually, dredging my memories I vaguely remember problems in the past 
with this. Lo and behold I searched the list archive and found the
following thread from 2009

http://sourceforge.net/p/plplot/mailman/plplot-general/thread/1258412677.12670.12.camel%40dventimi-laptop/#msg23989000

which documents a lot of this. Phil - which version of Ubuntu / Tcl / Tk 
are you using? It seems this was fixed in the Ubuntu Tcl 8.5 packages a 
long time ago.

Andrew
                                                                                                 
~                         

Re: [Plplot-devel] Release status

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

Hi Phil:

One thing I failed to cover in my prior post this morning is it sounds
like you have one more round of plbuf changes you would like to commit
to master (probably including some or all commits from Jim's series)
before release. That is fine, but you should also aim to put plbuf
changes into a deep freeze (no further changes allowed before release
except to sort out rendering regressions for all of PLplot) as early
as possible this week.  In other words, for the wxwidgets issues we
discussed, if you cannot get the fix done in the next day or so, and
the fix also involves plbuf changes, you should put off fixing the
issue until after the release.

The point of such a deep freeze is that plbuf changes have the
potential to introduce rendering regressions for all of PLplot (not
just wxwidgets) as was demonstrated by Andrew's fix for example 2.02.
Also, the zoom regression for -dev tk may also be another example of
such a plbuf-generated rendering regression, but I should know more
about that once I git bisect that issue.

So to get at least one foot on dry land we want to get to a state
where we _know_ there will be no more plbuf changes (except for PLplot
rendering regression fixes) in this release cycle in the next day or
so.  Once I hear that announcement from you that a deep freeze has
gone into effect for plbuf changes, then I plan to look very carefully
at every page of our examples for any recently introduced rendering
issues for, say, xcairo. But I would not want to do all the work
associated with such a test until I know there will be no further
plbuf changes other than rendering regression fixes.

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] Release status

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

On 9 March 2015 at 20:43, Alan W. Irwin <ir...@be...> wrote:
> Hi Phil:
>
> One thing I failed to cover in my prior post this morning is it sounds
> like you have one more round of plbuf changes you would like to commit
> to master (probably including some or all commits from Jim's series)
> before release. That is fine, but you should also aim to put plbuf
> changes into a deep freeze (no further changes allowed before release
> except to sort out rendering regressions for all of PLplot) as early
> as possible this week.  In other words, for the wxwidgets issues we
> discussed, if you cannot get the fix done in the next day or so, and
> the fix also involves plbuf changes, you should put off fixing the
> issue until after the release.

I will aim to do that asap

Re: [Plplot-devel] Release status

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

>
>
> Please take a look at his patch series he sent this weekend.  One of those
> patches
> apparently was to fix a wxwidgets issue so part/all of that series may
> be exactly what you need, but I am leaving it to you to evaluate which
> of his commits should be applied to master now, and which should wait
> until post-release (if they don't affect wxwidgets).

I will

>
> 3) is straightforward and I will do
>>
>> that this evening. 2) is a bit trickier as I don't really have a good
>> understanding of why it is wrong - it uses the same maths as the old
>> driver, but I wonder if the aspect ratio code has changed (for fixed
>> aspect) and there is some similar change required in the text. As
>> issue 4 is a rotated plot I consider this a bit of an edge case for an
>> interactive driver - it does need fixing, but I can live with it in
>> the short term.
>>
>> If you can live with 2 and 4, then we are pretty well ready to go.
>
>
> If you can live with them for now, then I can too.  However, I would
> appreciate you figuring out what was wrong with my patch to fix the
> wide legend box issues for the unicode case. At the time, you said you
> were getting complaints from Windows about unicode fonts, but since my
> patch simply used a facility you had already developed to determine
> physical width and height of the string that would be rendered by the
> wxwidgets libraries, I suspect that issue was attributable to other
> Windows issues you were having at that exact same time so please take
> another look.

I will look - the Unicode issue was related to you setting use of utf8
fonts which you said matched the wxWidgets example. I have now changed
(back?) to using default font encoding. I think that Windows font
files must generally use a different encoding. Note that this does not
affect the text encoding (which is dealt with on conversion from char
* to wxString) it only deals with font encodings - although I must
confess to not fully understanding how font encodings work.
>
>> One question I had though, is there any different behaviour required
>> for the no pause state? Currently the driver does not pause at all
>> regardless of this state. It sends all its data to the viewer then
>> continues - for the examples it then exits as it reaches the end of
>> main(), but leaves the viewer open with the plots.
>
>
> I think the fundamental issue here is that new wxwidgets launches a
> viewer that runs in a completely detached state.  That can be good in
> certain circumstances, but it obviously goes against the paradigm that
> is used for every other interactive device.  So I believe the solution
> here is to implement a wxwidgets driver option that allows detached
> mode (as now), but by default operates in attached mode. Once attached
> mode works, then that makes it possible to control the plot directly
> from the example, e.g., by specifying the nopause option.  I assume
> attached mode would also allow -locate mode to work for example 1,
> sort out some of the example 17 issues, etc.

Locate is already possible, I have a flag in the memory map which
indicates locate mode is on and halts execution of the calling
program. This should be reusable to pause execution of the calling
program, but this may have to wait until post release.

>
> In sum, all of the above are "would-be-nices" in my opinion rather
> than showstoppers.  So you are free to tackle as few or many of them
> as you like in the next few days, and we should look again where we
> jointly stand near the end of this week.
>
>
> 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] Release status

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

 Hi Alan and Jim
Right, well Jim's patch series is committed and I have just made one
more additional commit regarding the buffer which I think now gives us
a buffer which is (pretty close to, if not completely) bug free!!! Or
at the very least it is sufficient to allow the wxWidgets driver to
render as well as from direct commands.

Firstly I wanted to say a big thanks Jim for all your input with that
as well as with the plmeta driver. It's been much appreciated.

Secondly, I guess that means you can freeze the core code Alan. I'm
going to just make a couple of wxWidgets mods this evening and then I
am going to stop meddling until after the release. I do still need to
sort the docs out as well.

Phil

On 9 March 2015 at 21:09, Phil Rosenberg <p.d...@gm...> wrote:
>>
>>
>> Please take a look at his patch series he sent this weekend.  One of those
>> patches
>> apparently was to fix a wxwidgets issue so part/all of that series may
>> be exactly what you need, but I am leaving it to you to evaluate which
>> of his commits should be applied to master now, and which should wait
>> until post-release (if they don't affect wxwidgets).
>
> I will
>
>>
>> 3) is straightforward and I will do
>>>
>>> that this evening. 2) is a bit trickier as I don't really have a good
>>> understanding of why it is wrong - it uses the same maths as the old
>>> driver, but I wonder if the aspect ratio code has changed (for fixed
>>> aspect) and there is some similar change required in the text. As
>>> issue 4 is a rotated plot I consider this a bit of an edge case for an
>>> interactive driver - it does need fixing, but I can live with it in
>>> the short term.
>>>
>>> If you can live with 2 and 4, then we are pretty well ready to go.
>>
>>
>> If you can live with them for now, then I can too.  However, I would
>> appreciate you figuring out what was wrong with my patch to fix the
>> wide legend box issues for the unicode case. At the time, you said you
>> were getting complaints from Windows about unicode fonts, but since my
>> patch simply used a facility you had already developed to determine
>> physical width and height of the string that would be rendered by the
>> wxwidgets libraries, I suspect that issue was attributable to other
>> Windows issues you were having at that exact same time so please take
>> another look.
>
> I will look - the Unicode issue was related to you setting use of utf8
> fonts which you said matched the wxWidgets example. I have now changed
> (back?) to using default font encoding. I think that Windows font
> files must generally use a different encoding. Note that this does not
> affect the text encoding (which is dealt with on conversion from char
> * to wxString) it only deals with font encodings - although I must
> confess to not fully understanding how font encodings work.
>>
>>> One question I had though, is there any different behaviour required
>>> for the no pause state? Currently the driver does not pause at all
>>> regardless of this state. It sends all its data to the viewer then
>>> continues - for the examples it then exits as it reaches the end of
>>> main(), but leaves the viewer open with the plots.
>>
>>
>> I think the fundamental issue here is that new wxwidgets launches a
>> viewer that runs in a completely detached state.  That can be good in
>> certain circumstances, but it obviously goes against the paradigm that
>> is used for every other interactive device.  So I believe the solution
>> here is to implement a wxwidgets driver option that allows detached
>> mode (as now), but by default operates in attached mode. Once attached
>> mode works, then that makes it possible to control the plot directly
>> from the example, e.g., by specifying the nopause option.  I assume
>> attached mode would also allow -locate mode to work for example 1,
>> sort out some of the example 17 issues, etc.
>
> Locate is already possible, I have a flag in the memory map which
> indicates locate mode is on and halts execution of the calling
> program. This should be reusable to pause execution of the calling
> program, but this may have to wait until post release.
>
>>
>> In sum, all of the above are "would-be-nices" in my opinion rather
>> than showstoppers.  So you are free to tackle as few or many of them
>> as you like in the next few days, and we should look again where we
>> jointly stand near the end of this week.
>>
>>
>> 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] Release status

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

On 2015-03-10 21:41-0000 Phil Rosenberg wrote:

> Hi Alan and Jim
> Right, well Jim's patch series is committed and I have just made one
> more additional commit regarding the buffer which I think now gives us
> a buffer which is (pretty close to, if not completely) bug free!!! Or
> at the very least it is sufficient to allow the wxWidgets driver to
> render as well as from direct commands.

Note, to everybody.  There is an official deep freeze notice near
the end of this e-mail.

@ Andrew, Phil, and Jim:

Before getting to wxwidgets test results I regret to say that a recent
plbuf change has nailed us again.  There is now a release showstopper
where -dev tk produces really strange looking results.  I found this
issue via checking -dev tk for the zoom regression where hitting the
zoom button just produces a blank (black) plot.  I confirm that
regression as well as a newly introduced regression for that device
(two windows are displayed rather than one with one of them without a
plot but with the plframe decorations and the other showing an
xwin-like plot windows with no decorations). This new regression and
the zoom regression are showstoppers for the current release so your
confirmation and fix for these rendering regressions will be much
appreciated.  You should also look carefully at -dev wingcc to see
whether recent plbuf changes have introduced rendering regressions
there as well (assuming you have looked in detail before at wingcc
results for all examples, and therefore know what rendered nicely in
the old days).

If none of you beat me to it, I will follow up starting roughly 12 hours
from now with a git bisect to find out the first commit that caused
each of these regressions, and hopefully the fix for each regression
will be straightforward after that.

@Arjen:
Just in case you remember how well wingcc rendered before, I would
appreciate you double-checking how wingcc renders now.

@Phil:

Naturely, I found the above new rendering regression right at the end
of a very long series of tests of wxwidgets which I will probably have
to repeat once the above plbuf issue(s) are fixed (sigh).  So for what
it is worth, here is the current status of wxwidgets on Linux as of
commit id = afd37a9.

I did this long test with the following command:

for SEQ in $(seq -w 0 33); do
   examples/c/x${SEQ}c -dev wxwidgets
   read ANSWER
done

(where "read ANSWER" supplies a pause between examples
so you don't have one zillion instances of wxPLViewer going
at the same time).

There is a definite improvement compared to when I ran such a test
before, but I note the following large number of minor issues (mostly
rendering issues and non of them are release critical) that still
exist on Linux:

* text much too small for all examples.  Increasing
all text sizes by something close to a factor of two (say
to fill all the squares by the numbers in example 2.2 just like
for the xcairo, qtwidget, and xwin device) is needed.

* Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
of the pie chart, but the other slices are fine.

* Example 17 is extremely slow to display and the erases are not getting
done when the plot is rescaled.  Attached mode?

* Example 20 is extremely slow to display and does not have any
interactive capability (the third page should allow you to select a
region with the cursor).  Compare the cursor capability shown with
this example for -dev xwin.

Note -dev wxwidgets cursor capability is currently similar to
that of -dev xcairo and -dev qtwidget.  All three devices print
out cursor position results for example 1 with the -locate option,
but all three devices fail to allow the user to select
a region in example 3.03.  So all three have to be updated
to have the same cursor capabilities as -dev xwin.
In addition, I presume this capability would only work
for the qtwidgets case in attached mode (see below).

* Example 26.02 still has an issue with too large a legend for
the Cyrillic version of the plot.

* Example 28.04 has a strange colour change for certain ranges indicated
below of the rendering of the

"The future of our civilization depends on software freedom."
                 ^^^^^^^^                        ^^^^^^^

3D string.  Those colour changes occur when the letters in the string
are mostly reduced to the (expected) straight lines by the 3D affine
transformation.  This may be due to some strange issue with my Debian
stable wxwidgets software library and have nothing to do with PLplot.
If you cannot reproduce those colour changes, I will send a screen
shot.

* Example 28.05 affine transformation issues.

* Example 30.02 ugly looking gradient results are due to falling back
to core software emulation of a linear gradient.  Instead, as
discussed before a linear gradient based on the wxwidgets API should
be used instead to get very nice results for this example (such as
those from the cairo and qt devices).

* Example 34: the qtwidgets device does not support draw mode.
However, if you want to implement this someday you should follow what
is done for xcairo (which is the only device so far that has draw mode
capability).

* To get proper interactive capability, must implement an
attached driver option that does not launch a separate
wxPLViewer instance.

* There was also a the following warning being emitted by g++

/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp: In
function ‘void plD_init_wxwidgets(PLStream*)’:
/home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:186:23:
warning: converting to non-pointer type ‘PLINT {aka int}’ from NULL
[-Wconversion-null]

Did you really want to set the device id (which is just an integer) to
zero here?  If so, you should use 0 rather than NULL.  But I thought
that device id integer was supposed to be fixed and unique to each
device in which case it would generally not be a good idea to zero it.  But on
the other hand, I so far have not detected any issues from this
zeroing so I don't think there is any urgency here
(i.e., you can deal with this post-release).

> [....] I guess that [good results for wxwidgets] means you can freeze the core code Alan. I'm
> going to just make a couple of wxWidgets mods this evening and then I
> am going to stop meddling until after the release. I do still need to
> sort the docs out as well.
>

I think it is definitely time to be extremely conservative about all
commits to master because we just experienced a counter-example where
plbuf changes were committed without sufficient testing (in retrospect
something that is all-too-easy to do since plbuf has such a wide
impact). So I highly recommend dealing with all the above wxwidgets
issues on a topic branch and waiting until after the release to merge
those fixes to master while we focus on the master branch with dealing
with the regressions introduced by the plbuf changes. Also, note I
would be happy to make the next release cycle much shorter, i.e., have
another release just as soon as you finish the above list and want to
get those fixes quickly distributed to users.

@Everybody:

To make this decision official, this is notice from your release manager
that we are now in deep freeze until release.  That is, only
documentation changes and small and _very well tested_ fixes should be
pushed to master during this deep freeze. In particular, because
plbuf changes have such a wide impact, I ask everyone here to avoid
commits to master that involve any plbuf changes at all during deep
freeze unless such commit can be shown to fix a non-wxwidgets
rendering regression caused by an earlier plbuf change in this release
cycle.

Also, despite the extra effort we are going to need to deal with the
rendering regressions, I do honestly want to thank both Phil and Jim
for all their hard work on wxwidgets/plbuf that has finally gotten us
to the point where we can declare a deep freeze.  That's a really
important goal for late in a release cycle, and I am really glad we
have finally achieved that goal!

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] Release status

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

Hi Alan
Sorry I only just spotted your email.
I have just made a commit, but it was technically a bug fix (or at
least half of it was), but I won't make any further commits.

Phil

On 11 March 2015 at 10:49, Alan W. Irwin <ir...@be...> wrote:
> On 2015-03-10 21:41-0000 Phil Rosenberg wrote:
>
>> Hi Alan and Jim
>> Right, well Jim's patch series is committed and I have just made one
>> more additional commit regarding the buffer which I think now gives us
>> a buffer which is (pretty close to, if not completely) bug free!!! Or
>> at the very least it is sufficient to allow the wxWidgets driver to
>> render as well as from direct commands.
>
>
> Note, to everybody.  There is an official deep freeze notice near
> the end of this e-mail.
>
> @ Andrew, Phil, and Jim:
>
> Before getting to wxwidgets test results I regret to say that a recent
> plbuf change has nailed us again.  There is now a release showstopper
> where -dev tk produces really strange looking results.  I found this
> issue via checking -dev tk for the zoom regression where hitting the
> zoom button just produces a blank (black) plot.  I confirm that
> regression as well as a newly introduced regression for that device
> (two windows are displayed rather than one with one of them without a
> plot but with the plframe decorations and the other showing an
> xwin-like plot windows with no decorations). This new regression and
> the zoom regression are showstoppers for the current release so your
> confirmation and fix for these rendering regressions will be much
> appreciated.  You should also look carefully at -dev wingcc to see
> whether recent plbuf changes have introduced rendering regressions
> there as well (assuming you have looked in detail before at wingcc
> results for all examples, and therefore know what rendered nicely in
> the old days).
>
> If none of you beat me to it, I will follow up starting roughly 12 hours
> from now with a git bisect to find out the first commit that caused
> each of these regressions, and hopefully the fix for each regression
> will be straightforward after that.
>
> @Arjen:
> Just in case you remember how well wingcc rendered before, I would
> appreciate you double-checking how wingcc renders now.
>
> @Phil:
>
> Naturely, I found the above new rendering regression right at the end
> of a very long series of tests of wxwidgets which I will probably have
> to repeat once the above plbuf issue(s) are fixed (sigh).  So for what
> it is worth, here is the current status of wxwidgets on Linux as of
> commit id = afd37a9.
>
> I did this long test with the following command:
>
> for SEQ in $(seq -w 0 33); do
>   examples/c/x${SEQ}c -dev wxwidgets
>   read ANSWER
> done
>
> (where "read ANSWER" supplies a pause between examples
> so you don't have one zillion instances of wxPLViewer going
> at the same time).
>
> There is a definite improvement compared to when I ran such a test
> before, but I note the following large number of minor issues (mostly
> rendering issues and non of them are release critical) that still
> exist on Linux:
>
> * text much too small for all examples.  Increasing
> all text sizes by something close to a factor of two (say
> to fill all the squares by the numbers in example 2.2 just like
> for the xcairo, qtwidget, and xwin device) is needed.
>
> * Example 13; extra lines in "Maurice", "Vince", and "Rafael" parts
> of the pie chart, but the other slices are fine.
>
> * Example 17 is extremely slow to display and the erases are not getting
> done when the plot is rescaled.  Attached mode?
>
> * Example 20 is extremely slow to display and does not have any
> interactive capability (the third page should allow you to select a
> region with the cursor).  Compare the cursor capability shown with
> this example for -dev xwin.
>
> Note -dev wxwidgets cursor capability is currently similar to
> that of -dev xcairo and -dev qtwidget.  All three devices print
> out cursor position results for example 1 with the -locate option,
> but all three devices fail to allow the user to select
> a region in example 3.03.  So all three have to be updated
> to have the same cursor capabilities as -dev xwin.
> In addition, I presume this capability would only work
> for the qtwidgets case in attached mode (see below).
>
> * Example 26.02 still has an issue with too large a legend for
> the Cyrillic version of the plot.
>
> * Example 28.04 has a strange colour change for certain ranges indicated
> below of the rendering of the
>
> "The future of our civilization depends on software freedom."
>                 ^^^^^^^^                        ^^^^^^^
>
> 3D string.  Those colour changes occur when the letters in the string
> are mostly reduced to the (expected) straight lines by the 3D affine
> transformation.  This may be due to some strange issue with my Debian
> stable wxwidgets software library and have nothing to do with PLplot.
> If you cannot reproduce those colour changes, I will send a screen
> shot.
>
> * Example 28.05 affine transformation issues.
>
> * Example 30.02 ugly looking gradient results are due to falling back
> to core software emulation of a linear gradient.  Instead, as
> discussed before a linear gradient based on the wxwidgets API should
> be used instead to get very nice results for this example (such as
> those from the cairo and qt devices).
>
> * Example 34: the qtwidgets device does not support draw mode.
> However, if you want to implement this someday you should follow what
> is done for xcairo (which is the only device so far that has draw mode
> capability).
>
> * To get proper interactive capability, must implement an
> attached driver option that does not launch a separate
> wxPLViewer instance.
>
> * There was also a the following warning being emitted by g++
>
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp: In
> function ‘void plD_init_wxwidgets(PLStream*)’:
> /home/software/plplot/HEAD/plplot.git/drivers/wxwidgets.cpp:186:23:
> warning: converting to non-pointer type ‘PLINT {aka int}’ from NULL
> [-Wconversion-null]
>
> Did you really want to set the device id (which is just an integer) to
> zero here?  If so, you should use 0 rather than NULL.  But I thought
> that device id integer was supposed to be fixed and unique to each
> device in which case it would generally not be a good idea to zero it.  But
> on
> the other hand, I so far have not detected any issues from this
> zeroing so I don't think there is any urgency here
> (i.e., you can deal with this post-release).
>
>> [....] I guess that [good results for wxwidgets] means you can freeze the
>> core code Alan. I'm
>> going to just make a couple of wxWidgets mods this evening and then I
>> am going to stop meddling until after the release. I do still need to
>> sort the docs out as well.
>>
>
> I think it is definitely time to be extremely conservative about all
> commits to master because we just experienced a counter-example where
> plbuf changes were committed without sufficient testing (in retrospect
> something that is all-too-easy to do since plbuf has such a wide
> impact). So I highly recommend dealing with all the above wxwidgets
> issues on a topic branch and waiting until after the release to merge
> those fixes to master while we focus on the master branch with dealing
> with the regressions introduced by the plbuf changes. Also, note I
> would be happy to make the next release cycle much shorter, i.e., have
> another release just as soon as you finish the above list and want to
> get those fixes quickly distributed to users.
>
> @Everybody:
>
> To make this decision official, this is notice from your release manager
> that we are now in deep freeze until release.  That is, only
> documentation changes and small and _very well tested_ fixes should be
> pushed to master during this deep freeze. In particular, because
> plbuf changes have such a wide impact, I ask everyone here to avoid
> commits to master that involve any plbuf changes at all during deep
> freeze unless such commit can be shown to fix a non-wxwidgets
> rendering regression caused by an earlier plbuf change in this release
> cycle.
>
> Also, despite the extra effort we are going to need to deal with the
> rendering regressions, I do honestly want to thank both Phil and Jim
> for all their hard work on wxwidgets/plbuf that has finally gotten us
> to the point where we can declare a deep freeze.  That's a really
> important goal for late in a release cycle, and I am really glad we
> have finally achieved that goal!
>
>
> 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] Release status

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

On Mar 11, 2015, at 6:49 AM, "Alan W. Irwin" <ir...@be...> wrote:

> On 2015-03-10 21:41-0000 Phil Rosenberg wrote:
> 
>> Hi Alan and Jim
>> Right, well Jim's patch series is committed and I have just made one
>> more additional commit regarding the buffer which I think now gives us
>> a buffer which is (pretty close to, if not completely) bug free!!! Or
>> at the very least it is sufficient to allow the wxWidgets driver to
>> render as well as from direct commands.
> 
> Note, to everybody.  There is an official deep freeze notice near
> the end of this e-mail.
> 
> @ Andrew, Phil, and Jim:
> 
> Before getting to wxwidgets test results I regret to say that a recent
> plbuf change has nailed us again.  There is now a release showstopper
> where -dev tk produces really strange looking results.  I found this
> issue via checking -dev tk for the zoom regression where hitting the
> zoom button just produces a blank (black) plot.  I confirm that
> regression as well as a newly introduced regression for that device
> (two windows are displayed rather than one with one of them without a
> plot but with the plframe decorations and the other showing an
> xwin-like plot windows with no decorations). This new regression and
> the zoom regression are showstoppers for the current release so your
> confirmation and fix for these rendering regressions will be much
> appreciated.  You should also look carefully at -dev wingcc to see
> whether recent plbuf changes have introduced rendering regressions
> there as well (assuming you have looked in detail before at wingcc
> results for all examples, and therefore know what rendered nicely in
> the old days).
> 

I cannot replicate this problem.  I was able to zoom by pressing "z" and zoom out with "b" and nothing happened with "f".

> 
> @Everybody:
> 
> To make this decision official, this is notice from your release manager
> that we are now in deep freeze until release.  That is, only
> documentation changes and small and _very well tested_ fixes should be
> pushed to master during this deep freeze. In particular, because
> plbuf changes have such a wide impact, I ask everyone here to avoid
> commits to master that involve any plbuf changes at all during deep
> freeze unless such commit can be shown to fix a non-wxwidgets
> rendering regression caused by an earlier plbuf change in this release
> cycle.
> 
> Also, despite the extra effort we are going to need to deal with the
> rendering regressions, I do honestly want to thank both Phil and Jim
> for all their hard work on wxwidgets/plbuf that has finally gotten us
> to the point where we can declare a deep freeze.  That's a really
> important goal for late in a release cycle, and I am really glad we
> have finally achieved that goal!
> 
Attached is a patch series that reverses a change that Phil made to restore static to plhrsh.  I  recalled incorrectly on its use by plmetafile.c and it is needed to compile without error.  At this point there is no way around exposing plhrsh(). 

Sorry for the confusion.

Re: [Plplot-devel] Release status

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

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Wednesday, March 11, 2015 11:49 AM
> To: Andrew Ross; Phil Rosenberg; Jim Dishaw
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Release status
>
> @Arjen:
> Just in case you remember how well wingcc rendered before, I would appreciate you
> double-checking how wingcc renders now.
>


I just ran all the examples with the wingcc device under Cygwin (of course after having retrieved the latest version from git and building Plplot again) and as far as I can tell everything is looking fine. At the very least there are no strange gaps or oddly placed text strings or unexpected colours. Short of a formal comparison against previously saved screenshots (should I have had these) I cannot see any differences. Which is a good thing.

Regards,

Arjen



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

Re: [Plplot-devel] Release status

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

On 2015-03-11 11:33-0000 Arjen Markus wrote:

> I just ran all the examples with the wingcc device under Cygwin (of
course after having retrieved the latest version from git and building
Plplot again) and as far as I can tell everything is looking fine. At
the very least there are no strange gaps or oddly placed text strings
or unexpected colours. Short of a formal comparison against previously
saved screenshots (should I have had these) I cannot see any
differences. Which is a good thing.

Thanks, Arjen, for performing this most reassuring (at least for
wingcc) test.

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
__________________________