PLplot

Alban,

Thanks again. Patch committed to svn.

Andrew

On Fri, May 15, 2009 at 10:16:22AM +0100, Alban Rochel wrote:
> Hello,
> 
> Here is another patch for the Qt driver, based on revision 9979. I've
> rewritten the way commands are buffered in the interactive drivers,
> which should:
> - Fix the "blank screen" issue on Mac: not tested (I don't have one to
> test), but very close to the driver we use in QSAS, which has been
> thoroughly tested on Macs
> - Make the lines widths constant independantly of the display size,
> meaning that increasing the size of the window allows to see more
> details on the plots
> 
> This should end my "to-do" list relatively to these drivers, so if I
> have forgotten anything or if anything does not work as expected, please
> notify me, as I have no other update planned.
> 
> Cheers,
> 
> Alban


> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables 
> unlimited royalty-free distribution of the report engine 
> for externally facing server and web deployment. 
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Hello all,

Here is a patch for the Qt driver. It fixes a couple of minor bugs, and it also adds the possibility to pass PLplot command line arguments to the qtext driver (embedded widget in a Qt application) and handles flush and clear for the interactive devices. However, there still are issues with these implementations:

- Command line arguments for the qtext driver:
The user has to pass argc and argv to plsetqtdev (the function that associates the widget to the device). But in order to create a QApplication, the user has to pass argc and argv to the QApplication constructor before, which filters out the arguments it recognizes, including the "-bg" argument (conflict between Qt and PLplot). I believe the only way to fix this other than changing "-bg" into something else in PLplot is to make a deep copy of argv before passing it to the QApplication constructor and passing this copy to plsetqtdev. Thus, it's up to the application developer to handle such matters. You can see this issue with qt_example:
"qt_example -bg FF000" will display a Qt warning message and go on with the default bg colour
"qt_example -cmap0 _whatever_" will work properly

- flushing: it works, but example x17c is *slow* (about 30 times slower than xwin on my system!). This is because the Qt driver will replot everything from the last clear() everytime the flush is done. This is linked to the way the driver was designed, and despite my efforts, I haven't found a quick and easy way to fix this. I still plan to fix this, but it will require some redesign. In the meantime, people who wish to use the Qt driver to animate stuff may be happy to use the new "lines_antialiasing" command-line option which allows to (dis/en)able lines antialiasing (enabled by default), which makes the driver about 5 times slower than xwin.

Despite these flaws, as this update adds features and should not break anything, I believe it's worth adding to the svn trunk.

Alban

Hi Alban,

Thanks for this. I've committed it to svn. 

Andrew

On Thu, Aug 20, 2009 at 11:50:34AM +0100, Rochel, Alban wrote:
> Hello all,
> 
> Here is a patch for the Qt driver. It fixes a couple of minor bugs, and it also adds the possibility to pass PLplot command line arguments to the qtext driver (embedded widget in a Qt application) and handles flush and clear for the interactive devices. However, there still are issues with these implementations:
> 
> - Command line arguments for the qtext driver:
> The user has to pass argc and argv to plsetqtdev (the function that associates the widget to the device). But in order to create a QApplication, the user has to pass argc and argv to the QApplication constructor before, which filters out the arguments it recognizes, including the "-bg" argument (conflict between Qt and PLplot). I believe the only way to fix this other than changing "-bg" into something else in PLplot is to make a deep copy of argv before passing it to the QApplication constructor and passing this copy to plsetqtdev. Thus, it's up to the application developer to handle such matters. You can see this issue with qt_example:
> "qt_example -bg FF000" will display a Qt warning message and go on with the default bg colour
> "qt_example -cmap0 _whatever_" will work properly
> 
> - flushing: it works, but example x17c is *slow* (about 30 times slower than xwin on my system!). This is because the Qt driver will replot everything from the last clear() everytime the flush is done. This is linked to the way the driver was designed, and despite my efforts, I haven't found a quick and easy way to fix this. I still plan to fix this, but it will require some redesign. In the meantime, people who wish to use the Qt driver to animate stuff may be happy to use the new "lines_antialiasing" command-line option which allows to (dis/en)able lines antialiasing (enabled by default), which makes the driver about 5 times slower than xwin.
> 
> Despite these flaws, as this update adds features and should not break anything, I believe it's worth adding to the svn trunk.
> 
> Alban

> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Hi Alban:

The first part of this addressed to you, but there are some comments about
the animated octave examples that are addressed to Andrew at the end.

On 2009-08-20 11:50+0100 Rochel, Alban wrote:

> Hello all,

> Here is a patch for the Qt driver. It fixes a couple of minor bugs, and it
also adds the possibility to pass PLplot command line arguments to the qtext
driver (embedded widget in a Qt application) and handles flush and clear for
the interactive devices.

Thanks for this, and thanks to Andrew for committing it.

> However, there still are issues with these implementations:

> - Command line arguments for the qtext driver:

> [...]I believe the only way to fix this other
than changing "-bg" into something else in PLplot is to make a deep copy of
argv before passing it to the QApplication constructor and passing this copy
to plsetqtdev. Thus, it's up to the application developer to handle such
matters. You can see this issue with qt_example:

> "qt_example -bg FF000" will display a Qt warning message and go on with
the default bg colour

> "qt_example -cmap0 _whatever_" will work properly

It appears from what you have said that there is a way for application
developers to get around this issue.  If that "deep copy" method is
straightforward, would you be willing to implement that for qt_example since
that is probably the first place other developers will look for inspiration
for their own qt/PLplot GUI's?

> - flushing: it works, but example x17c is *slow* (about 30 times slower
than xwin on my system!). This is because the Qt driver will replot
everything from the last clear() everytime the flush is done. This is linked
to the way the driver was designed, and despite my efforts, I haven't found
a quick and easy way to fix this. I still plan to fix this, but it will
require some redesign. In the meantime, people who wish to use the Qt driver
to animate stuff may be happy to use the new "lines_antialiasing"
command-line option which allows to (dis/en)able lines antialiasing (enabled
by default), which makes the driver about 5 times slower than xwin.

For what it is worth, with the default line antialiasing (same as -drvopt
lines_antialiasing=1) it is almost exactly 10 times slower here.  With
-drvopt lines_antialiasing=0 it is roughly two times slower here than -dev
xwin.  This general trend makes sense since there is a built-in time delay
with example 17 which will make the cpu time consumed by the driver less and
less important as the cpu power of the hardware increases.

Nevertheless a factor of 10 or more is still most annoying for antialiased
animation so I had a look at the Qt documentation of repaint at
http://doc.trolltech.com/4.4/qwidget.html#repaint.  (For the others here,
this function is called to deal with plflushes for qtwidget).  It appears
there are overloaded forms of repaint that allow you to repaint rectangular
subregions of the widget.  So if plflush is modified to pass a rectangular
subregion to the device driver (which all devices would ignore except for
qtwidget) then you might get a major increase in speed for the normal case
where you are just adding one more x,y value to be plotted for the
animation.  IOW a small change to the PLplot core here (and I think it would
be possible to do that without changing the plflush API) might be better
than a complete qt driver redesign. :-)

The rest of this is addressed to Andrew as octave maintainer.

There a quite a few animated examples associated with octave (i.e., many of
the high-level "p" examples as opposed to the standard low-level "x"
examples).  Joao was still actively working on the "p" examples when he
retired as a core PLplot developer, and as far as I know nobody has touched
them since. Right now, our ctest tests ignore p1[0124789] and p20
(presumably because they don't yet work properly for -dev psc).  It would be
great if you would be willing to get all of those working properly both with
-dev psc (to give a snapshot at the end of the animation like x17 does now)
and also the interactive devices.  As I recall in the old days some of those
animated examples were quite spectacular with -dev xwin, and it would be
great to see them working now with xcairo and eventually with qtwidget as
well (once the animation speed issue for qt is fixed).

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hello Andrew,

I will modify qt_example to show the deep copy in the next patch, no problem.

As for your suggestion of using an overloaded repaint(), I'm afraid it's not that easy, as any call to the plot function will cause the whole buffer to be "replayed" anyway. I think about using a pointer to the last plotted element in the buffer and "replay" the buffer from this point, rather than from start, between 2 flushes. But even though this could seem simple, it will require some redesign for the other parts of the QtPLDriver class: iit will have to decide when to replot everything from scratch - after a resize for example -, when to replot from the last flush - after a flush()-, and when to keep the old plot and add information over this - the crosshairs from the interactive selection example in qt_example.

I'm not going to work on this now (I'm working on QSAS), maybe next week or the week after.

Alban
________________________________________
De : Alan W. Irwin [irwin@...]
Date d'envoi : jeudi 20 août 2009 20:47
À : Rochel, Alban; Andrew Ross
Cc : PLplot development list
Objet : Re: [Plplot-devel] Qt driver update

Hi Alban:

The first part of this addressed to you, but there are some comments about
the animated octave examples that are addressed to Andrew at the end.

On 2009-08-20 11:50+0100 Rochel, Alban wrote:

> Hello all,

> Here is a patch for the Qt driver. It fixes a couple of minor bugs, and it
also adds the possibility to pass PLplot command line arguments to the qtext
driver (embedded widget in a Qt application) and handles flush and clear for
the interactive devices.

Thanks for this, and thanks to Andrew for committing it.

> However, there still are issues with these implementations:

> - Command line arguments for the qtext driver:

> [...]I believe the only way to fix this other
than changing "-bg" into something else in PLplot is to make a deep copy of
argv before passing it to the QApplication constructor and passing this copy
to plsetqtdev. Thus, it's up to the application developer to handle such
matters. You can see this issue with qt_example:

> "qt_example -bg FF000" will display a Qt warning message and go on with
the default bg colour

> "qt_example -cmap0 _whatever_" will work properly

It appears from what you have said that there is a way for application
developers to get around this issue.  If that "deep copy" method is
straightforward, would you be willing to implement that for qt_example since
that is probably the first place other developers will look for inspiration
for their own qt/PLplot GUI's?

> - flushing: it works, but example x17c is *slow* (about 30 times slower
than xwin on my system!). This is because the Qt driver will replot
everything from the last clear() everytime the flush is done. This is linked
to the way the driver was designed, and despite my efforts, I haven't found
a quick and easy way to fix this. I still plan to fix this, but it will
require some redesign. In the meantime, people who wish to use the Qt driver
to animate stuff may be happy to use the new "lines_antialiasing"
command-line option which allows to (dis/en)able lines antialiasing (enabled
by default), which makes the driver about 5 times slower than xwin.

For what it is worth, with the default line antialiasing (same as -drvopt
lines_antialiasing=1) it is almost exactly 10 times slower here.  With
-drvopt lines_antialiasing=0 it is roughly two times slower here than -dev
xwin.  This general trend makes sense since there is a built-in time delay
with example 17 which will make the cpu time consumed by the driver less and
less important as the cpu power of the hardware increases.

Nevertheless a factor of 10 or more is still most annoying for antialiased
animation so I had a look at the Qt documentation of repaint at
http://doc.trolltech.com/4.4/qwidget.html#repaint.  (For the others here,
this function is called to deal with plflushes for qtwidget).  It appears
there are overloaded forms of repaint that allow you to repaint rectangular
subregions of the widget.  So if plflush is modified to pass a rectangular
subregion to the device driver (which all devices would ignore except for
qtwidget) then you might get a major increase in speed for the normal case
where you are just adding one more x,y value to be plotted for the
animation.  IOW a small change to the PLplot core here (and I think it would
be possible to do that without changing the plflush API) might be better
than a complete qt driver redesign. :-)

The rest of this is addressed to Andrew as octave maintainer.

There a quite a few animated examples associated with octave (i.e., many of
the high-level "p" examples as opposed to the standard low-level "x"
examples).  Joao was still actively working on the "p" examples when he
retired as a core PLplot developer, and as far as I know nobody has touched
them since. Right now, our ctest tests ignore p1[0124789] and p20
(presumably because they don't yet work properly for -dev psc).  It would be
great if you would be willing to get all of those working properly both with
-dev psc (to give a snapshot at the end of the animation like x17 does now)
and also the interactive devices.  As I recall in the old days some of those
animated examples were quite spectacular with -dev xwin, and it would be
great to see them working now with xcairo and eventually with qtwidget as
well (once the animation speed issue for qt is fixed).

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alban said:

> As for your suggestion of using an overloaded repaint(), I'm afraid it's
not that easy, as any call to the plot function will cause the whole buffer
to be "replayed" anyway.

I did an experiment replacing the call to repaint() by a call to update().
The result was that example 17 with -dev qtwidget was as fast as with -dev
xwin.  Of course, you lose all animation then and only get a snapshot of the
last completed result because unlike repaint (which is specifically for the
animation case), update drops intermediate results.  So to me that
experiment proves repaint is the sole bottleneck that causes the animation
speed issue (at least with the present design).

I don't understand your argument above concerning replaying the whole buffer
since the whole point of repainting just the relevant rectangle is to avoid
changing anything else in the plot that is displayed. Thus, it seems to me
if you use the overloaded variation of repaint supplied by Qt4 that only
repaints what has changed (i.e., it limits itself to just a small rectangle
that you specify when there is only one added point) the result has to be a
lot faster.  However, you know a lot more about Qt4 than I do so if I am
missing something (and repainting a small region is no faster than
repainting the whole plot) please explain where my analysis is going wrong.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hello Alan,

I am well aware that repaint is the bottleneck. What repaint does is ultimately to call QtPLWidget::plot() (via QtPLWidget::paintEvent()). Plot() does replay the whole buffer, it was never designed to be "region-aware". So no matter what region/rectangle is given to the overloaded repaint(...), everything would be redrawn.

An easy way to fix that would be to allow it to draw within a QRegion mask only, using QPainter::clipRegion. And I believe this would improve performance. However, I think we can do better than this as:
- The whole buffer would be unrolled anyway, only the actual painting would be clipped
- we would have the overhead of updating the region at every line, polyline, polygon command received from PLplot.

The solution I propose is to keep in memory an iterator ("pointer") to the last plotted element in the memory buffer, at each plot() call. This costs very little, and would allow to unroll and draw only the part of the buffer that has been added since the last flush(). No region merging, no clipping tests, just flushing what has not been flushed yet.

I haven't tried any of the solutions yet and I may realise that my approach is not feasible or harder than I expect, but I believe this would be faster in the end.

Alban

________________________________________
De : Alan W. Irwin [irwin@...]
Date d'envoi : vendredi 21 août 2009 23:31
À : Rochel, Alban; Andrew Ross
Cc : PLplot development list
Objet : Re: [Plplot-devel] Qt driver update

Alban said:

> As for your suggestion of using an overloaded repaint(), I'm afraid it's
not that easy, as any call to the plot function will cause the whole buffer
to be "replayed" anyway.

I did an experiment replacing the call to repaint() by a call to update().
The result was that example 17 with -dev qtwidget was as fast as with -dev
xwin.  Of course, you lose all animation then and only get a snapshot of the
last completed result because unlike repaint (which is specifically for the
animation case), update drops intermediate results.  So to me that
experiment proves repaint is the sole bottleneck that causes the animation
speed issue (at least with the present design).

I don't understand your argument above concerning replaying the whole buffer
since the whole point of repainting just the relevant rectangle is to avoid
changing anything else in the plot that is displayed. Thus, it seems to me
if you use the overloaded variation of repaint supplied by Qt4 that only
repaints what has changed (i.e., it limits itself to just a small rectangle
that you specify when there is only one added point) the result has to be a
lot faster.  However, you know a lot more about Qt4 than I do so if I am
missing something (and repainting a small region is no faster than
repainting the whole plot) please explain where my analysis is going wrong.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-08-22 08:38+0100 Rochel, Alban wrote:

> Hello Alan,
>
> I am well aware that repaint is the bottleneck. What repaint does is ultimately to call QtPLWidget::plot() (via QtPLWidget::paintEvent()). Plot() does replay the whole buffer, it was never designed to be "region-aware". So no matter what region/rectangle is given to the overloaded repaint(...), everything would be redrawn.
>
> An easy way to fix that would be to allow it to draw within a QRegion mask only, using QPainter::clipRegion. And I believe this would improve performance. However, I think we can do better than this as:
> - The whole buffer would be unrolled anyway, only the actual painting would be clipped
> - we would have the overhead of updating the region at every line, polyline, polygon command received from PLplot.
>
> The solution I propose is to keep in memory an iterator ("pointer") to the last plotted element in the memory buffer, at each plot() call. This costs very little, and would allow to unroll and draw only the part of the buffer that has been added since the last flush(). No region merging, no clipping tests, just flushing what has not been flushed yet.
>
> I haven't tried any of the solutions yet and I may realise that my approach is not feasible or harder than I expect, but I believe this would be faster in the end.
>

Hi Alban:

Thanks for your patience with my question.  Your explanation (with
QtPLWidget::plot replaced by QtPLWidget::doPlot) makes sense to me now.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Alban,

I actually don't understand why you need to "replot" everything. In  
the wxWidgets driver I draw into a memory canvas and from time to time  
I copy the canvas to the screen, so that the user can see how the plot  
evolves. This makes the driver slower but a little bit nicer to look  
at and example 17 works right away for that reason (Maybe I only  
update the screen if there is a flush, this would improve speed and  
give the user control about the plot update - I didn't know about this  
function). In addition to make the plot faster, I only copy the parts  
of the memory canvas which were changed to the screen. If this is of  
any help to you, I use the method wxPLDevBase::AddtoClipRegion() for  
that, which determines the minimal size of the region which must be  
copied. wxWidgets on its own provides similar functionality but back  
then I wasn't successful in using that.

HTH,
Werner


On Aug 22, 2009, at 9:38 AM, Rochel, Alban wrote:

> Hello Alan,
>
> I am well aware that repaint is the bottleneck. What repaint does is  
> ultimately to call QtPLWidget::plot() (via  
> QtPLWidget::paintEvent()). Plot() does replay the whole buffer, it  
> was never designed to be "region-aware". So no matter what region/ 
> rectangle is given to the overloaded repaint(...), everything would  
> be redrawn.
>
> An easy way to fix that would be to allow it to draw within a  
> QRegion mask only, using QPainter::clipRegion. And I believe this  
> would improve performance. However, I think we can do better than  
> this as:
> - The whole buffer would be unrolled anyway, only the actual  
> painting would be clipped
> - we would have the overhead of updating the region at every line,  
> polyline, polygon command received from PLplot.
>
> The solution I propose is to keep in memory an iterator ("pointer")  
> to the last plotted element in the memory buffer, at each plot()  
> call. This costs very little, and would allow to unroll and draw  
> only the part of the buffer that has been added since the last  
> flush(). No region merging, no clipping tests, just flushing what  
> has not been flushed yet.
>
> I haven't tried any of the solutions yet and I may realise that my  
> approach is not feasible or harder than I expect, but I believe this  
> would be faster in the end.
>
> Alban
>
> ________________________________________
> De : Alan W. Irwin [irwin@...]
> Date d'envoi : vendredi 21 août 2009 23:31
> À : Rochel, Alban; Andrew Ross
> Cc : PLplot development list
> Objet : Re: [Plplot-devel] Qt driver update
>
> Alban said:
>
>> As for your suggestion of using an overloaded repaint(), I'm afraid  
>> it's
> not that easy, as any call to the plot function will cause the whole  
> buffer
> to be "replayed" anyway.
>
> I did an experiment replacing the call to repaint() by a call to  
> update().
> The result was that example 17 with -dev qtwidget was as fast as  
> with -dev
> xwin.  Of course, you lose all animation then and only get a  
> snapshot of the
> last completed result because unlike repaint (which is specifically  
> for the
> animation case), update drops intermediate results.  So to me that
> experiment proves repaint is the sole bottleneck that causes the  
> animation
> speed issue (at least with the present design).
>
> I don't understand your argument above concerning replaying the  
> whole buffer
> since the whole point of repainting just the relevant rectangle is  
> to avoid
> changing anything else in the plot that is displayed. Thus, it seems  
> to me
> if you use the overloaded variation of repaint supplied by Qt4 that  
> only
> repaints what has changed (i.e., it limits itself to just a small  
> rectangle
> that you specify when there is only one added point) the result has  
> to be a
> lot faster.  However, you know a lot more about Qt4 than I do so if  
> I am
> missing something (and repainting a small region is no faster than
> repainting the whole plot) please explain where my analysis is going  
> wrong.
>
> 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); PLplot scientific plotting  
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

Werner,

The main reason why the Qt driver works that way is just an inheritance
of its origins in our QSAS software. In this software, we don't need
animation, and we only rely on Qt to do the plotting when it has time to
do so. Qt allows to either call an immediate replot or schedule a replot
"when it has time to do so". We chose the latter. We could not just plot
on a canvas in memory and display it, as we want to be able to rescale
the window and the plot without losing precision. So we store the plot
in memory as a commands buffer rather than a canvas.

But now I will have to make the driver evolve so that I can update only
the changed part of the plot, as you suggest, but I think slightly
differently.

Alban

Werner Smekal wrote:
> Hi Alban,
>
> I actually don't understand why you need to "replot" everything. In  
> the wxWidgets driver I draw into a memory canvas and from time to time  
> I copy the canvas to the screen, so that the user can see how the plot  
> evolves. This makes the driver slower but a little bit nicer to look  
> at and example 17 works right away for that reason (Maybe I only  
> update the screen if there is a flush, this would improve speed and  
> give the user control about the plot update - I didn't know about this  
> function). In addition to make the plot faster, I only copy the parts  
> of the memory canvas which were changed to the screen. If this is of  
> any help to you, I use the method wxPLDevBase::AddtoClipRegion() for  
> that, which determines the minimal size of the region which must be  
> copied. wxWidgets on its own provides similar functionality but back  
> then I wasn't successful in using that.
>
> HTH,
> Werner
>
>
> On Aug 22, 2009, at 9:38 AM, Rochel, Alban wrote:
>
>   
>> Hello Alan,
>>
>> I am well aware that repaint is the bottleneck. What repaint does is  
>> ultimately to call QtPLWidget::plot() (via  
>> QtPLWidget::paintEvent()). Plot() does replay the whole buffer, it  
>> was never designed to be "region-aware". So no matter what region/ 
>> rectangle is given to the overloaded repaint(...), everything would  
>> be redrawn.
>>
>> An easy way to fix that would be to allow it to draw within a  
>> QRegion mask only, using QPainter::clipRegion. And I believe this  
>> would improve performance. However, I think we can do better than  
>> this as:
>> - The whole buffer would be unrolled anyway, only the actual  
>> painting would be clipped
>> - we would have the overhead of updating the region at every line,  
>> polyline, polygon command received from PLplot.
>>
>> The solution I propose is to keep in memory an iterator ("pointer")  
>> to the last plotted element in the memory buffer, at each plot()  
>> call. This costs very little, and would allow to unroll and draw  
>> only the part of the buffer that has been added since the last  
>> flush(). No region merging, no clipping tests, just flushing what  
>> has not been flushed yet.
>>
>> I haven't tried any of the solutions yet and I may realise that my  
>> approach is not feasible or harder than I expect, but I believe this  
>> would be faster in the end.
>>
>> Alban
>>
>> ________________________________________
>> De : Alan W. Irwin [irwin@...]
>> Date d'envoi : vendredi 21 août 2009 23:31
>> À : Rochel, Alban; Andrew Ross
>> Cc : PLplot development list
>> Objet : Re: [Plplot-devel] Qt driver update
>>
>> Alban said:
>>
>>     
>>> As for your suggestion of using an overloaded repaint(), I'm afraid  
>>> it's
>>>       
>> not that easy, as any call to the plot function will cause the whole  
>> buffer
>> to be "replayed" anyway.
>>
>> I did an experiment replacing the call to repaint() by a call to  
>> update().
>> The result was that example 17 with -dev qtwidget was as fast as  
>> with -dev
>> xwin.  Of course, you lose all animation then and only get a  
>> snapshot of the
>> last completed result because unlike repaint (which is specifically  
>> for the
>> animation case), update drops intermediate results.  So to me that
>> experiment proves repaint is the sole bottleneck that causes the  
>> animation
>> speed issue (at least with the present design).
>>
>> I don't understand your argument above concerning replaying the  
>> whole buffer
>> since the whole point of repainting just the relevant rectangle is  
>> to avoid
>> changing anything else in the plot that is displayed. Thus, it seems  
>> to me
>> if you use the overloaded variation of repaint supplied by Qt4 that  
>> only
>> repaints what has changed (i.e., it limits itself to just a small  
>> rectangle
>> that you specify when there is only one added point) the result has  
>> to be a
>> lot faster.  However, you know a lot more about Qt4 than I do so if  
>> I am
>> missing something (and repainting a small region is no faster than
>> repainting the whole plot) please explain where my analysis is going  
>> wrong.
>>
>> 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); PLplot scientific plotting  
>> software
>> package (plplot.org); 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
>> __________________________
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and  
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Plplot-devel mailing list
>> Plplot-devel@...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>     
>
>
> --
> Dr. Werner Smekal
> Institut fuer Allgemeine Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> Austria
> DVR-Nr: 0005886
>
> email: smekal@...
> web:   http://www.iap.tuwien.ac.at/~smekal
> phone: +43-(0)1-58801-13463 (office)
>        +43-(0)1-58801-13469 (laboratory)
> fax:   +43-(0)1-58801-13499
>
>

Hi Alban,

> The main reason why the Qt driver works that way is just an  
> inheritance
> of its origins in our QSAS software. In this software, we don't need
> animation, and we only rely on Qt to do the plotting when it has  
> time to
> do so. Qt allows to either call an immediate replot or schedule a  
> replot
> "when it has time to do so". We chose the latter. We could not just  
> plot
> on a canvas in memory and display it, as we want to be able to rescale
> the window and the plot without losing precision. So we store the plot
> in memory as a commands buffer rather than a canvas.

In case of resizing I use the plplot replot() function. Plplot on it's  
own buffers all called functions and you can recall them on demand. So  
in case of resize I delete the memory buffer, allocated a new one,  
replot everything using the PLplot replot() function and copy the  
memory buffer to the screen. I didn't know that you have your own  
command buffer.

>
> But now I will have to make the driver evolve so that I can update  
> only
> the changed part of the plot, as you suggest, but I think slightly
> differently.

Sure, I just wanted to point out how it's done in other drivers.

All the best,
Werner

>
> Alban
>
> Werner Smekal wrote:
>> Hi Alban,
>>
>> I actually don't understand why you need to "replot" everything. In
>> the wxWidgets driver I draw into a memory canvas and from time to  
>> time
>> I copy the canvas to the screen, so that the user can see how the  
>> plot
>> evolves. This makes the driver slower but a little bit nicer to look
>> at and example 17 works right away for that reason (Maybe I only
>> update the screen if there is a flush, this would improve speed and
>> give the user control about the plot update - I didn't know about  
>> this
>> function). In addition to make the plot faster, I only copy the parts
>> of the memory canvas which were changed to the screen. If this is of
>> any help to you, I use the method wxPLDevBase::AddtoClipRegion() for
>> that, which determines the minimal size of the region which must be
>> copied. wxWidgets on its own provides similar functionality but back
>> then I wasn't successful in using that.
>>
>> HTH,
>> Werner
>>
>>
>> On Aug 22, 2009, at 9:38 AM, Rochel, Alban wrote:
>>
>>
>>> Hello Alan,
>>>
>>> I am well aware that repaint is the bottleneck. What repaint does is
>>> ultimately to call QtPLWidget::plot() (via
>>> QtPLWidget::paintEvent()). Plot() does replay the whole buffer, it
>>> was never designed to be "region-aware". So no matter what region/
>>> rectangle is given to the overloaded repaint(...), everything would
>>> be redrawn.
>>>
>>> An easy way to fix that would be to allow it to draw within a
>>> QRegion mask only, using QPainter::clipRegion. And I believe this
>>> would improve performance. However, I think we can do better than
>>> this as:
>>> - The whole buffer would be unrolled anyway, only the actual
>>> painting would be clipped
>>> - we would have the overhead of updating the region at every line,
>>> polyline, polygon command received from PLplot.
>>>
>>> The solution I propose is to keep in memory an iterator ("pointer")
>>> to the last plotted element in the memory buffer, at each plot()
>>> call. This costs very little, and would allow to unroll and draw
>>> only the part of the buffer that has been added since the last
>>> flush(). No region merging, no clipping tests, just flushing what
>>> has not been flushed yet.
>>>
>>> I haven't tried any of the solutions yet and I may realise that my
>>> approach is not feasible or harder than I expect, but I believe this
>>> would be faster in the end.
>>>
>>> Alban
>>>
>>> ________________________________________
>>> De : Alan W. Irwin [irwin@...]
>>> Date d'envoi : vendredi 21 août 2009 23:31
>>> À : Rochel, Alban; Andrew Ross
>>> Cc : PLplot development list
>>> Objet : Re: [Plplot-devel] Qt driver update
>>>
>>> Alban said:
>>>
>>>
>>>> As for your suggestion of using an overloaded repaint(), I'm afraid
>>>> it's
>>>>
>>> not that easy, as any call to the plot function will cause the whole
>>> buffer
>>> to be "replayed" anyway.
>>>
>>> I did an experiment replacing the call to repaint() by a call to
>>> update().
>>> The result was that example 17 with -dev qtwidget was as fast as
>>> with -dev
>>> xwin.  Of course, you lose all animation then and only get a
>>> snapshot of the
>>> last completed result because unlike repaint (which is specifically
>>> for the
>>> animation case), update drops intermediate results.  So to me that
>>> experiment proves repaint is the sole bottleneck that causes the
>>> animation
>>> speed issue (at least with the present design).
>>>
>>> I don't understand your argument above concerning replaying the
>>> whole buffer
>>> since the whole point of repainting just the relevant rectangle is
>>> to avoid
>>> changing anything else in the plot that is displayed. Thus, it seems
>>> to me
>>> if you use the overloaded variation of repaint supplied by Qt4 that
>>> only
>>> repaints what has changed (i.e., it limits itself to just a small
>>> rectangle
>>> that you specify when there is only one added point) the result has
>>> to be a
>>> lot faster.  However, you know a lot more about Qt4 than I do so if
>>> I am
>>> missing something (and repainting a small region is no faster than
>>> repainting the whole plot) please explain where my analysis is going
>>> wrong.
>>>
>>> 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); PLplot scientific plotting
>>> software
>>> package (plplot.org); 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
>>> __________________________
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Plplot-devel mailing list
>>> Plplot-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>>
>>
>>
>> --
>> Dr. Werner Smekal
>> Institut fuer Allgemeine Physik
>> Technische Universitaet Wien
>> Wiedner Hauptstr 8-10
>> A-1040 Wien
>> Austria
>> DVR-Nr: 0005886
>>
>> email: smekal@...
>> web:   http://www.iap.tuwien.ac.at/~smekal
>> phone: +43-(0)1-58801-13463 (office)
>>       +43-(0)1-58801-13469 (laboratory)
>> fax:   +43-(0)1-58801-13499
>>
>>
>

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Hello all,

First of all, sorry for the previous empty e-mail!

You will find attached a patch for the Qt driver. The main feature is a better implementation of flushing, resulting in x17c running about as fast as the other drivers (11 to 13 seconds on my system depending on anti-aliasing, where xwin runs in 11 seconds, wxwidgets in 13 and xcairo in 25).

I have removed driver support for PLESC_CLEAR, as it was ill-implemented. It cleared all the screen and the plot buffer whereas it should only clear the sub-page. In this case, from the driver point of view, it would have required me to do the same as the built-in fallback in PLplot, so I prefer to rely on the fallback. I've improved the qt_example to show how to deep-copy the command-line arguments passed to the software so that Qt does not filter out the "bg" commands.

I've only tested all this on Linux. I remember having issues with the way Macs handled events to refresh display (and it seems that they haven't been totally fixed). As this update changes refresh, I wouldn't be surprised if problems occurred. So, just tell me and I'll see what I can do.

Alban

On 2009-08-26 10:01+0100 Rochel, Alban wrote:

> You will find attached a patch for the Qt driver.

It applies and builds without errors and the speedup in -dev qtwidget for
animations like example 17 is extraordinary.  I also get a x17c -dev
qtwidget time that is comparable with the -dev xwin one.

If I try

./qt_example -bg ffffff

I do get the specified white background to the GUI.

However, I also get the error message

QColor::setNamedColor: Unknown color name 'ffffff'

Can that error message be suppressed or are we stuck with it?

That's the last qt issue (and an extremely minor one at that) that I am aware
of on Linux.

Thanks very much for all your efforts to make the qt devices some of the
best that we have on Linux, and I am sure that with some additional work
(especially with lots of test reports from our developers to help you narrow
down the issues) the same will be true on Mac OS X and Windows.

I have committed your patch as revision 10346.  I am really happy to see
this go in before our 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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan,

The error message (or rather warning) is due to the QApplication trying to process the "-bg" argument, which is among the accepted arguments for a QApplication (try "qt_example -bg red" for instance). There is obviously a conflict, but nothing that would stop the software to work, so it is a choice for the developer to filter out or not the "-bg" arguments or make them available to either QApplication or the widget. Maybe we should add a comment there?

Alban
________________________________________
De : Alan W. Irwin [irwin@...]
Date d'envoi : mercredi 26 août 2009 17:04
À : Rochel, Alban
Cc : Plplot-devel mailing list
Objet : Re: [Plplot-devel] Qt driver update

On 2009-08-26 10:01+0100 Rochel, Alban wrote:

> You will find attached a patch for the Qt driver.

It applies and builds without errors and the speedup in -dev qtwidget for
animations like example 17 is extraordinary.  I also get a x17c -dev
qtwidget time that is comparable with the -dev xwin one.

If I try

./qt_example -bg ffffff

I do get the specified white background to the GUI.

However, I also get the error message

QColor::setNamedColor: Unknown color name 'ffffff'

Can that error message be suppressed or are we stuck with it?

That's the last qt issue (and an extremely minor one at that) that I am aware
of on Linux.

Thanks very much for all your efforts to make the qt devices some of the
best that we have on Linux, and I am sure that with some additional work
(especially with lots of test reports from our developers to help you narrow
down the issues) the same will be true on Mac OS X and Windows.

I have committed your patch as revision 10346.  I am really happy to see
this go in before our 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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-08-26 17:11+0100 Rochel, Alban wrote:

> The error message (or rather warning) is due to the QApplication trying to
process the "-bg" argument, which is among the accepted arguments for a
QApplication (try "qt_example -bg red" for instance). There is obviously a
conflict, but nothing that would stop the software to work, so it is a
choice for the developer to filter out or not the "-bg" arguments or make
them available to either QApplication or the widget. Maybe we should add a
comment there?

I have fixed this issue in revision 10347.  I set argc (but not Argc) to 1
so that QApplication sees only an empty command line (other than the
command, itself).

I prefer the simplicity of this approach for our qt_example, and I assume
most Qt/PLplot GUI application developers will stick with that model where
the command-line options are completely ignored by Qt and only interpreted
by PLplot.  However, I put additional commentary in so that if application
developers want to allow both Qt options and PLplot options (say by
splitting the two kinds of options by a special "--" option like startx does
for its two kinds of options), and putting one kind into argc for
QApplication and the other kind into Argc for PLplot, it should be
straightforward for them to do so.

We are now down to zero qt issues on Linux that I am aware of.  :-)

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Alban,
>
> I have committed your patch as revision 10346.  I am really happy to  
> see
> this go in before our release.

I tried the latest plplot code from svn with Qt 4.5.1 on Mac Os X and  
the issues still remain:

* if I start an example (qtwidget device) from the terminal a window  
pops up in the background which is just grey. After I click on it, the  
plot updates.
* example 17 doesn't update even if it gets the focus. Instead it  
remains grey and after some time I'll get only the last plot of  
example 17
* example 16 has wrong colors. The following warning messages are  
print to the screen:

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0

HTH,
Werner


>
> 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); PLplot scientific plotting  
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Hello Werner,

For your issue with example 17, can you try changing QtPLWidget::flush() in bindings/qt_gui/plqt.cpp (line 594) into:
void QtPLWidget::flush()
{
    repaint();
   QApplication::processEvents();
}

I hope this will help...

Alban
________________________________________
De : Werner Smekal [smekal@...]
Date d'envoi : jeudi 27 août 2009 08:05
À : Alan W. Irwin
Cc : Rochel, Alban; Plplot-devel mailing list
Objet : Re: [Plplot-devel] Qt driver update

Hi Alban,
>
> I have committed your patch as revision 10346.  I am really happy to
> see
> this go in before our release.

I tried the latest plplot code from svn with Qt 4.5.1 on Mac Os X and
the issues still remain:

* if I start an example (qtwidget device) from the terminal a window
pops up in the background which is just grey. After I click on it, the
plot updates.
* example 17 doesn't update even if it gets the focus. Instead it
remains grey and after some time I'll get only the last plot of
example 17
* example 16 has wrong colors. The following warning messages are
print to the screen:

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0

HTH,
Werner


>
> 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); PLplot scientific plotting
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Hi Alban,

yes, that makes example 17 update regularily. The window opens still  
in the background but stuff is plotted without getting the focus. The  
other examples still remain grey. Would a  
"QApplication::processEvents();"-call for eop/end help? I didn't find  
the corresponding functions in the qt driver, so I couldn't try.

Thanks,
Werner

On 27.08.2009, at 09:31, Rochel, Alban wrote:

> Hello Werner,
>
> For your issue with example 17, can you try changing  
> QtPLWidget::flush() in bindings/qt_gui/plqt.cpp (line 594) into:
> void QtPLWidget::flush()
> {
>    repaint();
>   QApplication::processEvents();
> }
>
> I hope this will help...
>
> Alban
> ________________________________________
> De : Werner Smekal [smekal@...]
> Date d'envoi : jeudi 27 août 2009 08:05
> À : Alan W. Irwin
> Cc : Rochel, Alban; Plplot-devel mailing list
> Objet : Re: [Plplot-devel] Qt driver update
>
> Hi Alban,
>>
>> I have committed your patch as revision 10346.  I am really happy to
>> see
>> this go in before our release.
>
> I tried the latest plplot code from svn with Qt 4.5.1 on Mac Os X and
> the issues still remain:
>
> * if I start an example (qtwidget device) from the terminal a window
> pops up in the background which is just grey. After I click on it, the
> plot updates.
> * example 17 doesn't update even if it gets the focus. Instead it
> remains grey and after some time I'll get only the last plot of
> example 17
> * example 16 has wrong colors. The following warning messages are
> print to the screen:
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0
>
> HTH,
> Werner
>
>
>>
>> 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); PLplot scientific plotting
>> software
>> package (plplot.org); 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
>> __________________________
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Plplot-devel mailing list
>> Plplot-devel@...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> --
> Dr. Werner Smekal
> Institut fuer Allgemeine Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> Austria
>
> email: smekal@...
> web: http://www.iap.tuwien.ac.at/~smekal
> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469  
> (laboratory)
> fax: +43-(0)1-58801-13499
>

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Good news, thanks for testing!

I'll try and add it in eop() with the next patch.

Alban

________________________________________
De : Werner Smekal [smekal@...]
Date d'envoi : jeudi 27 août 2009 13:01
À : Rochel, Alban
Cc : Alan W. Irwin; Plplot-devel mailing list
Objet : Re: RE : [Plplot-devel] Qt driver update

Hi Alban,

yes, that makes example 17 update regularily. The window opens still
in the background but stuff is plotted without getting the focus. The
other examples still remain grey. Would a
"QApplication::processEvents();"-call for eop/end help? I didn't find
the corresponding functions in the qt driver, so I couldn't try.

Thanks,
Werner

On 27.08.2009, at 09:31, Rochel, Alban wrote:

> Hello Werner,
>
> For your issue with example 17, can you try changing
> QtPLWidget::flush() in bindings/qt_gui/plqt.cpp (line 594) into:
> void QtPLWidget::flush()
> {
>    repaint();
>   QApplication::processEvents();
> }
>
> I hope this will help...
>
> Alban
> ________________________________________
> De : Werner Smekal [smekal@...]
> Date d'envoi : jeudi 27 août 2009 08:05
> À : Alan W. Irwin
> Cc : Rochel, Alban; Plplot-devel mailing list
> Objet : Re: [Plplot-devel] Qt driver update
>
> Hi Alban,
>>
>> I have committed your patch as revision 10346.  I am really happy to
>> see
>> this go in before our release.
>
> I tried the latest plplot code from svn with Qt 4.5.1 on Mac Os X and
> the issues still remain:
>
> * if I start an example (qtwidget device) from the terminal a window
> pops up in the background which is just grey. After I click on it, the
> plot updates.
> * example 17 doesn't update even if it gets the focus. Instead it
> remains grey and after some time I'll get only the last plot of
> example 17
> * example 16 has wrong colors. The following warning messages are
> print to the screen:
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0
>
> HTH,
> Werner
>
>
>>
>> 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); PLplot scientific plotting
>> software
>> package (plplot.org); 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
>> __________________________
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Plplot-devel mailing list
>> Plplot-devel@...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> --
> Dr. Werner Smekal
> Institut fuer Allgemeine Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> Austria
>
> email: smekal@...
> web: http://www.iap.tuwien.ac.at/~smekal
> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469
> (laboratory)
> fax: +43-(0)1-58801-13499
>

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

On 2009-08-27 09:05+0200 Werner Smekal wrote:

> * example 16 has wrong colors. The following warning messages are print to 
> the screen:
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0

These warnings are evidence of more floating-point comparison issues that
ocurred in plspal1 which I should have spotted when I fixed a similar issue
that Valery Pipin found for cmap1_default.cmap.

I believe I have now solved all these plspal1 floating-point comparison
issues completely using a macro for the needed and oft-used programme
fragment to deal with such issues (revision 10353).  Also, I have made a
much better fallback (gray scale rather than segfault) when the requested
cmap1 palette file is completely wrong. Could you try again, please, to see
if the above warnings are gone?

Out of curiosity, what hardware were you using when you ran into the above
warnings?  I suspect it wasn't Intel/AMD. (That hardware uses 80-bit rather
than 64-bit registers to store intermediate floating-point results.  That
leads to higher than normal floating-point precision and fewer
floating-point comparison issues.  The downside is that if you test
exclusively on Intel/AMD, you may not notice the effects of problematic code
which is subject to floating-point comparison issues.)

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-08-27 12:57-0700 Alan W. Irwin wrote:

> On 2009-08-27 09:05+0200 Werner Smekal wrote:
>
>> * example 16 has wrong colors. The following warning messages are print to
>> the screen:
>>
>> *** PLPLOT WARNING ***
>> Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0
>>
>> *** PLPLOT WARNING ***
>> Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0
>>
>> *** PLPLOT WARNING ***
>> Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0
>
> These warnings are evidence of more floating-point comparison issues that
> ocurred in plspal1 which I should have spotted when I fixed a similar issue
> that Valery Pipin found for cmap1_default.cmap.
>
> I believe I have now solved all these plspal1 floating-point comparison
> issues completely using a macro for the needed and oft-used programme
> fragment to deal with such issues (revision 10353).  Also, I have made a
> much better fallback (gray scale rather than segfault) when the requested
> cmap1 palette file is completely wrong. Could you try again, please, to see
> if the above warnings are gone?
>
> Out of curiosity, what hardware were you using when you ran into the above
> warnings?  I suspect it wasn't Intel/AMD. (That hardware uses 80-bit rather
> than 64-bit registers to store intermediate floating-point results.  That
> leads to higher than normal floating-point precision and fewer
> floating-point comparison issues.  The downside is that if you test
> exclusively on Intel/AMD, you may not notice the effects of problematic code
> which is subject to floating-point comparison issues.)

I have now (revision 10354) in plctrl.c implemented a fuzzy range check in
cmap0_palette_read (to complement the one in plspal1), implemented some code
cleanup and reorganization, and implemented a better job of freeing fs in
plLibOpenPdfstrm that is allocated by plGetName.  The valgrind results are
perfect (*) (no memory errors, all heap blocks were freed) for a large range
of wacko conditions for cmap0 and cmap1 palette files.  (* Of course you
only achieve this perfection if you use one of our devices such as -dev psc
or -dev svg which does not call external libraries which often leave some
blocks allocated after the external library is closed).

This code should now be flame proof regardless of what blunders users might
think up when editing palette files and regardless of floating-point errors
in palette calculations. (Hmm, sounds like "famous last words".... :-) )

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Alan,
>
> These warnings are evidence of more floating-point comparison issues  
> that
> ocurred in plspal1 which I should have spotted when I fixed a  
> similar issue
> that Valery Pipin found for cmap1_default.cmap.
>
> I believe I have now solved all these plspal1 floating-point  
> comparison
> issues completely using a macro for the needed and oft-used programme
> fragment to deal with such issues (revision 10353).  Also, I have  
> made a
> much better fallback (gray scale rather than segfault) when the  
> requested
> cmap1 palette file is completely wrong. Could you try again, please,  
> to see
> if the above warnings are gone?

No, colors changed, but I still get warnings, and the colors are also  
still wrong:

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0

I attached a zip file with the output of the pdfqt driver so you can  
see, what I'm talking about.
>
> Out of curiosity, what hardware were you using when you ran into the  
> above
> warnings?  I suspect it wasn't Intel/AMD. (That hardware uses 80-bit  
> rather
> than 64-bit registers to store intermediate floating-point results.   
> That
> leads to higher than normal floating-point precision and fewer
> floating-point comparison issues.  The downside is that if you test
> exclusively on Intel/AMD, you may not notice the effects of  
> problematic code
> which is subject to floating-point comparison issues.)

No, it's an Intel Core 2 Duo. Running Mac OS X 10.5.7.

Regards,
Werner

>
> 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); PLplot scientific plotting  
> software
> package (plplot.org); 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
> __________________________

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

On 2009-08-28 08:22+0200 Werner Smekal wrote:

> Hi Alan,
>> 
>> These warnings are evidence of more floating-point comparison issues that
>> ocurred in plspal1 which I should have spotted when I fixed a similar issue
>> that Valery Pipin found for cmap1_default.cmap.
>> 
>> I believe I have now solved all these plspal1 floating-point comparison
>> issues completely using a macro for the needed and oft-used programme
>> fragment to deal with such issues (revision 10353).  Also, I have made a
>> much better fallback (gray scale rather than segfault) when the requested
>> cmap1 palette file is completely wrong. Could you try again, please, to see
>> if the above warnings are gone?
>
> No, colors changed, but I still get warnings, and the colors are also still 
> wrong:
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0
>
> I attached a zip file with the output of the pdfqt driver so you can see, 
> what I'm talking about.

First, I cannot reproduce any of the difficulties/warning messages you are
seeing.  So finding the solution to this issue is going to require some
more experimentation/debugging on your part.

Second, please use revision 10355 (or later) for all further investigation.
I just now made changes for that revision to output more information in the
warning messages to make it easier to identify exactly which part of the
code is generating the warning message.

Looking at your attached files, as expected, pages 2, 3, and 5 replace the
desired colours with red scale (put in by revision 10354) as a fallback and
to give a visual warning to accompany the above text warnings for
respectively cmap1_blue_yellow.pal, cmap1_blue_red.pal, and cmap1_gray.pal.
The above warning messages correspond to the 3rd line (the first data line)
in all three files.

By the way, I am pretty sure (unless a device driver is really screwed up)
that cmap1 palette reading troubles should be device independent. Could you
confirm that by trying -dev psc for example 16?

The above warning message seem to be only related to the palette files I
identified and cmap1_default.pal (used for page 4 of example 16) doesn't
appear to be giving you any trouble. On the other hand, the (very) strange
thing is example 16 also uses cmap1_gray.pal for the first page, and you
didn't report any warning messages for that page.

Could you please try some experiments with

examples/c/x10c -cmap1 cmap1_*.pal -dev psc -o test.psc

to see if you have any problems with the above palette files in that case?

>> 
>> Out of curiosity, what hardware were you using when you ran into the above
>> warnings?  I suspect it wasn't Intel/AMD. (That hardware uses 80-bit rather
>> than 64-bit registers to store intermediate floating-point results.  That
>> leads to higher than normal floating-point precision and fewer
>> floating-point comparison issues.  The downside is that if you test
>> exclusively on Intel/AMD, you may not notice the effects of problematic 
>> code
>> which is subject to floating-point comparison issues.)
>
> No, it's an Intel Core 2 Duo. Running Mac OS X 10.5.7.
>

Hmm. That would seem to indicate the trouble you are having reading
the palette files on Mac OS X has nothing to do with floating-point errors,
and in any case the present code is pretty fire-proof against those.

So to summarize the experiments I would like you to try, please see whether
-dev psc also produces the example 16 warning messages and please see
whether can you reproduce similar issues for example 10 using -cmap1.

Once the new warning messages have identified exactly where in the code the
problem is occurring, could you please try a gdb session (or printf's
scattered around plspal1) to see exactly what is going wrong?

I am sorry so much of the work tracking down this issue is on your
shoulders, but there is not much I can do here except make suggestions for
experiments since I am getting perfect (valgrind-clean and heap-clean)
results here.  My guess is there is something in the plspal1 code that
depends on some assumption that is only true on Linux, but I don't know
what that could be.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

To Werner, Hazen, and Jerry:

Without decent colour maps, PLplot is pretty useless so colour issues are
release critical by definition.  Therefore, I hope all three of you with
access to OS X will give the current plspal1 issues on Mac OS X that were
discovered by Werner your immediate attention.

Hazen and Jerry, do you confirm the issues Werner is seeing on Mac OS X? As
far as I know he has only tested for qt, but I assume this issue is device
independent.  Could you make sure your experiments (with revision 10358, see
below) include the following experiments I asked Werner to try?

On 2009-08-28 10:29-0700 Alan W. Irwin wrote:

> So to summarize the experiments I would like you to try, please see whether
> -dev psc also produces the example 16 warning messages and please see
> whether can you reproduce similar issues for example 10 using -cmap1.
>
> Once the new warning messages have identified exactly where in the code the
> problem is occurring, could you please try a gdb session (or printf's
> scattered around plspal1) to see exactly what is going wrong?
>

There have been two changes recently which I assume will not affect the
issue that Werner discovered, but I mention them for completeness and just
in case that assumption is incorrect.

* At Arjen's suggestion, I changed the fuzz factor for floating point
comparisons from 1.d-12 to 1.d-4.  However, for the default "typedef double
PLFLT" case, I expect floating point errors in quantities read in from
palette files will be of order 1.d-16.  Thus, this change should make no
difference in that case.  For the "typedef float PLFLT" you get when you
specify -DPL_DOUBLE=OFF to cmake, I expect the floating-point errors in
quantities read in from palette files will be of order 1.d-6.  So for
-DPL_DOUBLE=OFF this change will make an important difference (which is why
Arjen suggested it), but otherwise not.

* This morning I found four palette files (cmap0_alternate.pal,
cmap0_white_bg.pal, cmap1_blue_yellow.pal, and cmap1_radar.pal) which had no
svn:eol-style property assigned at all and others had native line endings
(meaning they would have different line endings depending on what platform
those files were checked out on).  I think it is best that these PLplot
input files have the exact same form whether obtained from our release
tarball or svn so I have changed the svn:eol-style property to LF (Unix line
endings) for all of them as of revision 10358.

Regardless of platform, I don't see how line endings will make any
difference to either cmap0_palette_read or plspal1 since they both use fgets
from the C library.  On Linux, fgets reads everything up to and including
the line feed corresponding to the line end.  I think Mac OS X line endings
are also Unix (so the above property change should make no difference in any
case) and I assume fgets act there the same as on Linux.  For Windows, I
assume fgets also reads everything up to and including the line feed
regardless of whether that line feed is proceeded by a CR or not.
Therefore, as far as I know changing to the LF property should generate the
same results for cmap0_pallette_read and plspal1 on all platforms.

So my assumption is the above two changes should make absolutely no
difference to Werner's bad OS X results, but I need confirmation of that
assumption from Werner and also confirmation of Werner's bad results on OS X
by our other developers for revision 10358.  If you do get differences from
Werner's results, then it is important to see what is different about his
Mac OS X system (Darwin version, etc., compared to yours) so give plenty of
details if you cannot confirm his (bad) result.

I believe I have done everything possible from this end to make it
straightforward to debug this plspal1 issue on OS X, but ultimately one of
you guys with access to Mac OS X has to sit down and actually debug the
issue until you come up with a fix.  Hopefully that will be in a timely
manner (i.e., in the next few days) so we don't have to hold the release for
the 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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Alan W. Irwin wrote:
> To Werner, Hazen, and Jerry:
> 
> Without decent colour maps, PLplot is pretty useless so colour issues are
> release critical by definition.  Therefore, I hope all three of you with
> access to OS X will give the current plspal1 issues on Mac OS X that were
> discovered by Werner your immediate attention.
> 
> Hazen and Jerry, do you confirm the issues Werner is seeing on Mac OS X? As
> far as I know he has only tested for qt, but I assume this issue is device
> independent.  Could you make sure your experiments (with revision 10358, 
> see
> below) include the following experiments I asked Werner to try?
> 
> On 2009-08-28 10:29-0700 Alan W. Irwin wrote:
> 
>> So to summarize the experiments I would like you to try, please see 
>> whether
>> -dev psc also produces the example 16 warning messages and please see
>> whether can you reproduce similar issues for example 10 using -cmap1.
>>
>> Once the new warning messages have identified exactly where in the 
>> code the
>> problem is occurring, could you please try a gdb session (or printf's
>> scattered around plspal1) to see exactly what is going wrong?

I'm not exactly sure what tests you wanted, but I ran examples 10 and 16 
using both the psc driver and the xwin driver and everything was as 
expected w/ no warning messages.

I have a pretty old mac now. It is a PowerPC running OS-X 10.4.11.

uname -a
Darwin hazen-babcocks-imac-g5.local 8.11.0 Darwin Kernel Version 8.11.0: 
Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power 
Macintosh powerpc

gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure 
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ 
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib 
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)

-Hazen

On 2009-08-30 11:51-0400 Hazen Babcock wrote:

> Alan W. Irwin wrote:
>> To Werner, Hazen, and Jerry:
>> 
>> Without decent colour maps, PLplot is pretty useless so colour issues are
>> release critical by definition.  Therefore, I hope all three of you with
>> access to OS X will give the current plspal1 issues on Mac OS X that were
>> discovered by Werner your immediate attention.
>> 
>> Hazen and Jerry, do you confirm the issues Werner is seeing on Mac OS X? As
>> far as I know he has only tested for qt, but I assume this issue is device
>> independent.  Could you make sure your experiments (with revision 10358, 
>> see
>> below) include the following experiments I asked Werner to try?
>> 
>> On 2009-08-28 10:29-0700 Alan W. Irwin wrote:
>> 
>>> So to summarize the experiments I would like you to try, please see 
>>> whether
>>> -dev psc also produces the example 16 warning messages and please see
>>> whether can you reproduce similar issues for example 10 using -cmap1.
>>> 
>>> Once the new warning messages have identified exactly where in the code 
>>> the
>>> problem is occurring, could you please try a gdb session (or printf's
>>> scattered around plspal1) to see exactly what is going wrong?
>
> I'm not exactly sure what tests you wanted, but I ran examples 10 and 16 
> using both the psc driver and the xwin driver and everything was as expected 
> w/ no warning messages.

If you review the e-mail on this, Werner got error messages and warning
colours (red scale) meaning he could not read some of the cmap1 palette
files for example 16 on his particular OS X and hardware platform. The
devices he used for the tests were qtwidget and pdfqt. However, palette file
reading is done by the PLplot core and should largely be independent of the
device driver used (unless there is some nasty side effect between the two
that I am unaware of).  I would like that assumption (that he gets warning
messages and colours for all devices) confirmed by Werner by the tests
requested above, but he hasn't reported back on that request yet.

It appears you _can_ read those cmap1 palette files with no problems on your
particular OS X and hardware platform for -dev psc and -dev xwin, but I
would appreciate you also trying qtwidget and pdfqt (and other devices as
well) to show that on your platform at least there are no side effects
between cmap1 palette file reading success and the device used.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Alan,

weekend is family time, so no work from my side on this issue here. I  
just updated to the last plplot version and I get now little different  
warnings.

>>
>> No, colors changed, but I still get warnings, and the colors are  
>> also still
>> wrong:
>>
>> *** PLPLOT WARNING ***
>> Unrecognized cmap1 format 0.0   1.0   1.0   1.0   1.0 0
>>
>> *** PLPLOT WARNING ***
>> Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0
>>
>> *** PLPLOT WARNING ***
>> Unrecognized cmap1 format 0.0   0.0   0.0   0.0   1.0 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items for version 2 of  
format) 0.0   1.0   1.0   1.0   1.0 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items for version 2 of  
format) 0. 240. 0.5 1.0 1. 0

*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items for version 2 of  
format) 0.0   0.0   0.0   0.0   1.0 0

>
> First, I cannot reproduce any of the difficulties/warning messages  
> you are
> seeing.  So finding the solution to this issue is going to require  
> some
> more experimentation/debugging on your part.

Sure, I'll try to debug that, but have limited time to do so.
>
> Second, please use revision 10355 (or later) for all further  
> investigation.
> I just now made changes for that revision to output more information  
> in the
> warning messages to make it easier to identify exactly which part of  
> the
> code is generating the warning message.

That explains the more verbose warning messages.

> By the way, I am pretty sure (unless a device driver is really  
> screwed up)
> that cmap1 palette reading troubles should be device independent.  
> Could you
> confirm that by trying -dev psc for example 16?

Nope, this warnings only occur with the qt devices. All other drivers  
I tried (wxwidgets, xwin, ps, pdf) worked as expected.
>
> The above warning message seem to be only related to the palette  
> files I
> identified and cmap1_default.pal (used for page 4 of example 16)  
> doesn't
> appear to be giving you any trouble. On the other hand, the (very)  
> strange
> thing is example 16 also uses cmap1_gray.pal for the first page, and  
> you
> didn't report any warning messages for that page.
>
> Could you please try some experiments with
>
> examples/c/x10c -cmap1 cmap1_*.pal -dev psc -o test.psc
>
> to see if you have any problems with the above palette files in that  
> case?

Will do that now.
>
> Once the new warning messages have identified exactly where in the  
> code the
> problem is occurring, could you please try a gdb session (or printf's
> scattered around plspal1) to see exactly what is going wrong?
>
> I am sorry so much of the work tracking down this issue is on your
> shoulders, but there is not much I can do here except make  
> suggestions for
> experiments since I am getting perfect (valgrind-clean and heap-clean)
> results here.  My guess is there is something in the plspal1 code that
> depends on some assumption that is only true on Linux, but I don't  
> know
> what that could be.

The problem must be somehow related to the qt driver (though as you, I  
can't imagine what the problem might be) and I try to debug it. Since  
I have not much experience with qt and also not much time, this might  
take a little.

Regards,
Werner

>
> 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); PLplot scientific plotting  
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Hi Werner:

Most of this is directed to you but there is also a request for Hazen and
Jerry at the end.

On 2009-08-31 08:27+0200 Werner Smekal wrote:

> Hi Alan,
>
> weekend is family time, so no work from my side on this issue here.

Understood.  We are all volunteers here with limited (and variable) spare
time so we should all expect that responses to questions on this list are
sometimes delayed.

> I just 
> updated to the last plplot version and I get now little different warnings.
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0 
> 1.0   1.0   1.0   1.0 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format (wrong number of items for version 2 of format) 0. 
> 240. 0.5 1.0 1. 0
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0 
> 0.0   0.0   0.0   1.0 0
>

>> By the way, I am pretty sure (unless a device driver is really screwed up)
>> that cmap1 palette reading troubles should be device independent. Could you
>> confirm that by trying -dev psc for example 16?
>
> Nope, this warnings only occur with the qt devices. All other drivers I tried 
> (wxwidgets, xwin, ps, pdf) worked as expected.

That is a really strange result.

The relevant code from plctrl.c (subject to line rewrap) is identified
exactly by the unique error message above.

fgets(color_info, 160, fp);
if (sscanf(color_info, "%lf %lf %lf %lf %lf %d",
&pos_d, &r_d, &g_d, &b_d, &a_d, &rev_i) != 6) {
snprintf(msgbuf,1024,
"Unrecognized cmap1 format (wrong number of items for version 2 of format) %s\n",
color_info);

So the above warning message outputs exactly the color_info which sscanf
cannot interpret properly.  But if we look at the data in that warning
message above it is perfect; five floating point variables in a row, then an
integer just like the above sscanf format directives and corresponding
pointers.  In particular, we already know there is no hidden null characters
embedded in the middle of color_info because then that would affect the
output of color_info in an obvious way (truncated early).  It is hard to
tell from e-mail, but I suppose there could be a line ending or other
non-printing characters embedded in the middle of color_info.

Just to be sure that is not the case, could you run example 16 again and
capture the warning message directly into a file (using ">&" and not cut and
paste to make this test as direct as possible), then analyze that file with
something like od to see whether there are any non-printing characters in
color_info?  This is improbable (since color_info is read immediately before
in the code with fgets above), but it would be good to have rock-solid
confirmation that this improbability is not true.

If you confirm the color_info output is perfect yet sscanf cannot read it,
this is a second very strange result (after the very strange result that the
problem only occurs for qt devices).

The third very strange result is that the 3rd message above corresponds to
cmap1_gray.pal which is read without issues for the first page of the same
example 16!

One hypothesis that might explain (more or less) all three strange results
is that dynamic loading of qt devices is linking in a Qt4 library that
breaks sscanf (or fgets if color_info turns out to have some embedded
non-printing characters) on your system in some way.  I know that hypothesis
is quite speculative/improbable so if somebody here can come up with some
more probable hypothesis to explain these strange results, please speak up.

Werner: here are the next steps I would appreciate you doing to help figure
this out.

* Check color_info by directly capturing the above error message into a file
and binary dump that file with something like the od application to make
sure there are no non-printing characters embedded in the middle of
color_info. (I have done that already with this e-mail, and the color_info
output above was clean of embedded characters, but some of the applications
used in the long e-mail chain between us could have filtered out those
non-printing characters, and the right way to do this is by immediate file
capture on the platform where the warning message is generated.)

* Experiment with different Qt4 versions to see if the problem goes away
for one of them.

Hazen and Jerry: would you do similar experimentation (running example 16
with a number of different Qt4 versions) to see if you can replicate the
issue that Werner found?  To switch from one Qt4 version to another, simply
put the appropriate qmake on your path before a fresh build and cmake does
the rest.

If by such experiments from Werner, Hazen, and Jerry we establish that the
cmap1 palette file reading problems for example 16 occurs only for one Qt4
version on OS X but not others, then we only have to warn about that bad Qt4
version for OS X in the release notes, and we are (finally) done with this
issue.

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On Aug 29, 2009, at 10:30 AM, Alan W. Irwin wrote:

> To Werner, Hazen, and Jerry:
>
> Without decent colour maps, PLplot is pretty useless so colour  
> issues are
> release critical by definition.  Therefore, I hope all three of you  
> with
> access to OS X will give the current plspal1 issues on Mac OS X that  
> were
> discovered by Werner your immediate attention.

My working copy is in a state where it won't build because I'm working  
on getting example 19 fixed. I could swap my copy out and look at  
these color issues but I'd rather get 19 fixed first.

Jerry

On 2009-08-31 22:09-0700 Jerry wrote:

>
> On Aug 29, 2009, at 10:30 AM, Alan W. Irwin wrote:
>
>> To Werner, Hazen, and Jerry:
>>
>> Without decent colour maps, PLplot is pretty useless so colour
>> issues are
>> release critical by definition.  Therefore, I hope all three of you
>> with
>> access to OS X will give the current plspal1 issues on Mac OS X that
>> were
>> discovered by Werner your immediate attention.
>
> My working copy is in a state where it won't build because I'm working
> on getting example 19 fixed. I could swap my copy out and look at
> these color issues but I'd rather get 19 fixed first.

It's looking now like this is a little less urgent since the problem seems
confined (for some really strange reason that nobody seems to understand!)
to just when qt devices are used on example 16 on OS X (and maybe only
Werner's version of OS X?).  So if you get a chance before the release to
try out example 16 with a qt device and at least one Qt4 version (and
hopefully more) that would be great, but I think you are right to give the
Ada example 19 fix a higher priority.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Alan,

>
> Just to be sure that is not the case, could you run example 16 again  
> and
> capture the warning message directly into a file (using ">&" and not  
> cut and
> paste to make this test as direct as possible), then analyze that  
> file with
> something like od to see whether there are any non-printing  
> characters in
> color_info?  This is improbable (since color_info is read  
> immediately before
> in the code with fgets above), but it would be good to have rock-solid
> confirmation that this improbability is not true.

I only see text, spaces and linefeeds, so it should be ok (see  
attached png).

>
> If you confirm the color_info output is perfect yet sscanf cannot  
> read it,
> this is a second very strange result (after the very strange result  
> that the
> problem only occurs for qt devices).
>
> The third very strange result is that the 3rd message above  
> corresponds to
> cmap1_gray.pal which is read without issues for the first page of  
> the same
> example 16!

Yup, that also puzzles me :)
>
> One hypothesis that might explain (more or less) all three strange  
> results
> is that dynamic loading of qt devices is linking in a Qt4 library that
> breaks sscanf (or fgets if color_info turns out to have some embedded
> non-printing characters) on your system in some way.  I know that  
> hypothesis
> is quite speculative/improbable so if somebody here can come up with  
> some
> more probable hypothesis to explain these strange results, please  
> speak up.

Just to make it more strange. Nokia actually provides two packages of  
Qt - cocoa and carbon, whil cocoa is the "new" API (use for Mac OS X  
10.6). I actually have two Macs here (both latest 10.5.8 and xcode)  
and on one I installed the carbon binary package and on the other  
cocoa binary package (see http://qt.nokia.com/downloads/mac-os-cpp).  
While the Qt carbon leads to this strange cmap results, does Qt cocoa  
not print out this warnings - so the file qt devices work regarding  
the color. But qtwidget is messed up again, since the first plot  
appears (for multipage examples and after I click on the plot, before  
only grey window), but the following plots are not shown only the  
background color. I really have to say that Qt on Mac OS X is quite  
buggy as it seems.

>
> Werner: here are the next steps I would appreciate you doing to help  
> figure
> this out.
>
> * Check color_info by directly capturing the above error message  
> into a file
> and binary dump that file with something like the od application to  
> make
> sure there are no non-printing characters embedded in the middle of
> color_info. (I have done that already with this e-mail, and the  
> color_info
> output above was clean of embedded characters, but some of the  
> applications
> used in the long e-mail chain between us could have filtered out those
> non-printing characters, and the right way to do this is by  
> immediate file
> capture on the platform where the warning message is generated.)

done, see picture.
>
> * Experiment with different Qt4 versions to see if the problem goes  
> away
> for one of them.

I even installed the latest Qt version 4.5.2 (cocoa and carbon) - see  
the results above.
>
> Hazen and Jerry: would you do similar experimentation (running  
> example 16
> with a number of different Qt4 versions) to see if you can replicate  
> the
> issue that Werner found?  To switch from one Qt4 version to another,  
> simply
> put the appropriate qmake on your path before a fresh build and  
> cmake does
> the rest.

I used the binary packages, where a switch is not that easy. I just  
don't have the time to download the 450Mb source package and compile  
qt in different versions, which I assume will really take a long time,  
if this 450MB monster is uncompressed.
>
> If by such experiments from Werner, Hazen, and Jerry we establish  
> that the
> cmap1 palette file reading problems for example 16 occurs only for  
> one Qt4
> version on OS X but not others, then we only have to warn about that  
> bad Qt4
> version for OS X in the release notes, and we are (finally) done  
> with this
> issue.

I'll now try to set a breakpoint in plctrl.c and see if I find  
something with gdb. Regarding the grey window/not shown plots I would  
like to give Alban direct access to my Mac(s), but I need to establish  
a ssh tunnel to this macs since they are behind a firewall. Let's see  
if I can do this, but since I have no experience here, this may need  
some time.

Regards,
Werner

>
> 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); PLplot scientific plotting  
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Hi Werner,
________________________________________
De : Werner Smekal [smekal@...]
Date d'envoi : mardi 1 septembre 2009 08:12
À : Alan W. Irwin
Cc : Hazen Babcock; Jerry; Plplot-devel mailing list; Rochel, Alban
Objet : Re: [Plplot-devel] Qt driver update

I'll now try to set a breakpoint in plctrl.c and see if I find
something with gdb. Regarding the grey window/not shown plots I would
like to give Alban direct access to my Mac(s), but I need to establish
a ssh tunnel to this macs since they are behind a firewall. Let's see
if I can do this, but since I have no experience here, this may need
some time.

Regards,
Werner

>

Having access to one of your Macs could help, indeed, thank you. However, for your "grey plot" issues, could you just try the following:
- In bindings/qt_gui/plqt.cpp, change QtPLWidget::flush as follows (as I previously asked you to)
void QtPLWidget::flush()
{
    repaint();
    QApplication::processEvents(); // add this
}

- In drivers/qt.cpp, change plD_eop_qtwidget as:
void plD_eop_qtwidget(PLStream *pls)
{
    QtPLWidget* widget=((QtPLWidget*)pls->dev);
    int currentPage=widget->pageNumber;
    widget->flush(); // add this
    while(currentPage==widget->pageNumber && handler.isMasterDevice(widget) && ! pls->nopause)
    {
        qApp->processEvents(QEventLoop::WaitForMoreEvents);
    }
}

As for the colour issues, I suspect we have the same kind of issue as we have with getenv() on Linux. Qt, as we use it, seems to mess up something in the system environment (and I have no idea what). I've not had getenv() issues with Qt 4.4. Is it possible for you to try this version of Qt?

I am currently starting to work on Windows for Tuomas Seppala's issues. I have no experience on cmake on Windows, so I hope it won't take me too long. I'll be away (part of) this afternoon. To tell you everything, my wife and I are expecting a baby within 3 weeks, we have to go to the hospital this afternoon, and don't be surprised if I appear to be away unexpectedly some time in the next weeks. However, I'll try to work as much as possible on fixing the issues before the release.

Alban

Werner,

I have the "grey plot/refresh" issue on Windows, so it will be easier for me to fix this one.

Alban

Hi Alban,

> Having access to one of your Macs could help, indeed, thank you.  
> However, for your "grey plot" issues, could you just try the  
> following:
> - In bindings/qt_gui/plqt.cpp, change QtPLWidget::flush as follows  
> (as I previously asked you to)
> void QtPLWidget::flush()
> {
>    repaint();
>    QApplication::processEvents(); // add this
> }

This I already did and wrote an email to the list - this fixes example  
17 but not the other examples.
>
> - In drivers/qt.cpp, change plD_eop_qtwidget as:
> void plD_eop_qtwidget(PLStream *pls)
> {
>    QtPLWidget* widget=((QtPLWidget*)pls->dev);
>    int currentPage=widget->pageNumber;
>    widget->flush(); // add this
>    while(currentPage==widget->pageNumber &&  
> handler.isMasterDevice(widget) && ! pls->nopause)
>    {
>        qApp->processEvents(QEventLoop::WaitForMoreEvents);
>    }
> }

This solves the problems for the grey page. After you run a program  
the first plot will be shown (after a short while if there are  
multiplots). This is for the carbon qt binary, but I expect this to  
work also for the cocoa qt binary. The only thing left now (apart from  
this color crazyness) is that the window is in the background when you  
start it. Is it possible in Qt to bring the window into the  
foreground, since this is something the user would await? I'll commit  
these changes.
>
> As for the colour issues, I suspect we have the same kind of issue  
> as we have with getenv() on Linux. Qt, as we use it, seems to mess  
> up something in the system environment (and I have no idea what).  
> I've not had getenv() issues with Qt 4.4. Is it possible for you to  
> try this version of Qt?

It must be something like that since the cocoa library of the same qt  
version doesn't have these problems. That's really strange that Qt  
somehow overloads the stdlib functions with buggy functions.
>
> I am currently starting to work on Windows for Tuomas Seppala's  
> issues. I have no experience on cmake on Windows, so I hope it won't  
> take me too long. I'll be away (part of) this afternoon. To tell you  
> everything, my wife and I are expecting a baby within 3 weeks, we  
> have to go to the hospital this afternoon, and don't be surprised if  
> I appear to be away unexpectedly some time in the next weeks.  
> However, I'll try to work as much as possible on fixing the issues  
> before the release.

It's actually not much a problem, maybe the wiki helps you a bit: http://www.miscdebris.net/plplot_wiki/index.php?title=Qt

Congratulations to you and your wife about the upcoming birth! I wish  
you all the best and I'm sure it will be a great time for all of you.

Regards,
Werner

>
> Alban

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Werner,

Good news for the flush() issue. It works on Windows too (I just had forgotten to save the changes I told you to do). To bring the window to front, try to add widget->raise() after widget->flush() in plD_eop_qtwidget.

Alban
________________________________________
De : Werner Smekal [smekal@...]
Date d'envoi : mardi 1 septembre 2009 08:58
À : Rochel, Alban
Cc : Alan W. Irwin; Hazen Babcock; Jerry; Plplot-devel mailing list
Objet : Re: RE : [Plplot-devel] Qt driver update

This solves the problems for the grey page. After you run a program
the first plot will be shown (after a short while if there are
multiplots). This is for the carbon qt binary, but I expect this to
work also for the cocoa qt binary. The only thing left now (apart from
this color crazyness) is that the window is in the background when you
start it. Is it possible in Qt to bring the window into the
foreground, since this is something the user would await? I'll commit
these changes.
>
> As for the colour issues, I suspect we have the same kind of issue
> as we have with getenv() on Linux. Qt, as we use it, seems to mess
> up something in the system environment (and I have no idea what).
> I've not had getenv() issues with Qt 4.4. Is it possible for you to
> try this version of Qt?

It must be something like that since the cocoa library of the same qt
version doesn't have these problems. That's really strange that Qt
somehow overloads the stdlib functions with buggy functions.
>
> I am currently starting to work on Windows for Tuomas Seppala's
> issues. I have no experience on cmake on Windows, so I hope it won't
> take me too long. I'll be away (part of) this afternoon. To tell you
> everything, my wife and I are expecting a baby within 3 weeks, we
> have to go to the hospital this afternoon, and don't be surprised if
> I appear to be away unexpectedly some time in the next weeks.
> However, I'll try to work as much as possible on fixing the issues
> before the release.

It's actually not much a problem, maybe the wiki helps you a bit: http://www.miscdebris.net/plplot_wiki/index.php?title=Qt

Congratulations to you and your wife about the upcoming birth! I wish
you all the best and I'm sure it will be a great time for all of you.

Regards,
Werner

>
> Alban

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Hi Alban,

this works as well. Very good, so apart from this color issue, the qt  
drivers on Mac work quite well. I'll commit this as well. Please test  
on Linux if these changes did mess something up.

Thanks,
Werner

On 01.09.2009, at 10:03, Rochel, Alban wrote:

> Werner,
>
> Good news for the flush() issue. It works on Windows too (I just had  
> forgotten to save the changes I told you to do). To bring the window  
> to front, try to add widget->raise() after widget->flush() in  
> plD_eop_qtwidget.
>
> Alban
> ________________________________________
> De : Werner Smekal [smekal@...]
> Date d'envoi : mardi 1 septembre 2009 08:58
> À : Rochel, Alban
> Cc : Alan W. Irwin; Hazen Babcock; Jerry; Plplot-devel mailing list
> Objet : Re: RE : [Plplot-devel] Qt driver update
>
> This solves the problems for the grey page. After you run a program
> the first plot will be shown (after a short while if there are
> multiplots). This is for the carbon qt binary, but I expect this to
> work also for the cocoa qt binary. The only thing left now (apart from
> this color crazyness) is that the window is in the background when you
> start it. Is it possible in Qt to bring the window into the
> foreground, since this is something the user would await? I'll commit
> these changes.
>>
>> As for the colour issues, I suspect we have the same kind of issue
>> as we have with getenv() on Linux. Qt, as we use it, seems to mess
>> up something in the system environment (and I have no idea what).
>> I've not had getenv() issues with Qt 4.4. Is it possible for you to
>> try this version of Qt?
>
> It must be something like that since the cocoa library of the same qt
> version doesn't have these problems. That's really strange that Qt
> somehow overloads the stdlib functions with buggy functions.
>>
>> I am currently starting to work on Windows for Tuomas Seppala's
>> issues. I have no experience on cmake on Windows, so I hope it won't
>> take me too long. I'll be away (part of) this afternoon. To tell you
>> everything, my wife and I are expecting a baby within 3 weeks, we
>> have to go to the hospital this afternoon, and don't be surprised if
>> I appear to be away unexpectedly some time in the next weeks.
>> However, I'll try to work as much as possible on fixing the issues
>> before the release.
>
> It's actually not much a problem, maybe the wiki helps you a bit: http://www.miscdebris.net/plplot_wiki/index.php?title=Qt
>
> Congratulations to you and your wife about the upcoming birth! I wish
> you all the best and I'm sure it will be a great time for all of you.
>
> Regards,
> Werner
>
>>
>> Alban
>
> --
> Dr. Werner Smekal
> Institut fuer Allgemeine Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> Austria
>
> email: smekal@...
> web: http://www.iap.tuwien.ac.at/~smekal
> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469  
> (laboratory)
> fax: +43-(0)1-58801-13499
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Hi Alan,
>
> That is a really strange result.
>
> The relevant code from plctrl.c (subject to line rewrap) is identified
> exactly by the unique error message above.
>
> fgets(color_info, 160, fp);
> if (sscanf(color_info, "%lf %lf %lf %lf %lf %d",
> &pos_d, &r_d, &g_d, &b_d, &a_d, &rev_i) != 6) {
> snprintf(msgbuf,1024,
> "Unrecognized cmap1 format (wrong number of items for version 2 of  
> format) %s\n",
> color_info);
>
> So the above warning message outputs exactly the color_info which  
> sscanf
> cannot interpret properly.  But if we look at the data in that warning
> message above it is perfect; five floating point variables in a row,  
> then an
> integer just like the above sscanf format directives and corresponding
> pointers.  In particular, we already know there is no hidden null  
> characters
> embedded in the middle of color_info because then that would affect  
> the
> output of color_info in an obvious way (truncated early).  It is  
> hard to
> tell from e-mail, but I suppose there could be a line ending or other
> non-printing characters embedded in the middle of color_info.

I think I found out what the problem is. The first page reads okay,  
but then qt takes over to show the plot and somehow changes the locale  
or something. This is on a Mac, English version, but Austrian locale -  
so after that scanf expects floating point numbers to be written  
numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I  
assume that this is the problem, since I printed the out the numbers  
with printf in case  sscanf fails and the output is:

0: 0.0   0.0   0.0   0.0   1.0 0
1: 1.0   1.0   1.0   1.0   1.0 0
0: 0.0   1.0   1.0   1.0   1.0 0
0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440

*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items (1) for version 2 of  
format) 0.0   1.0   1.0   1.0   1.0 0

I'll try now to play around with my locale. The other Mac has also  
Austrian locale, but obviously Qt cocoa doesn't mess around here.

I'll keep you informed.

Regards,
Werner


>
> Just to be sure that is not the case, could you run example 16 again  
> and
> capture the warning message directly into a file (using ">&" and not  
> cut and
> paste to make this test as direct as possible), then analyze that  
> file with
> something like od to see whether there are any non-printing  
> characters in
> color_info?  This is improbable (since color_info is read  
> immediately before
> in the code with fgets above), but it would be good to have rock-solid
> confirmation that this improbability is not true.
>
> If you confirm the color_info output is perfect yet sscanf cannot  
> read it,
> this is a second very strange result (after the very strange result  
> that the
> problem only occurs for qt devices).
>
> The third very strange result is that the 3rd message above  
> corresponds to
> cmap1_gray.pal which is read without issues for the first page of  
> the same
> example 16!
>
> One hypothesis that might explain (more or less) all three strange  
> results
> is that dynamic loading of qt devices is linking in a Qt4 library that
> breaks sscanf (or fgets if color_info turns out to have some embedded
> non-printing characters) on your system in some way.  I know that  
> hypothesis
> is quite speculative/improbable so if somebody here can come up with  
> some
> more probable hypothesis to explain these strange results, please  
> speak up.
>
> Werner: here are the next steps I would appreciate you doing to help  
> figure
> this out.
>
> * Check color_info by directly capturing the above error message  
> into a file
> and binary dump that file with something like the od application to  
> make
> sure there are no non-printing characters embedded in the middle of
> color_info. (I have done that already with this e-mail, and the  
> color_info
> output above was clean of embedded characters, but some of the  
> applications
> used in the long e-mail chain between us could have filtered out those
> non-printing characters, and the right way to do this is by  
> immediate file
> capture on the platform where the warning message is generated.)
>
> * Experiment with different Qt4 versions to see if the problem goes  
> away
> for one of them.
>
> Hazen and Jerry: would you do similar experimentation (running  
> example 16
> with a number of different Qt4 versions) to see if you can replicate  
> the
> issue that Werner found?  To switch from one Qt4 version to another,  
> simply
> put the appropriate qmake on your path before a fresh build and  
> cmake does
> the rest.
>
> If by such experiments from Werner, Hazen, and Jerry we establish  
> that the
> cmap1 palette file reading problems for example 16 occurs only for  
> one Qt4
> version on OS X but not others, then we only have to warn about that  
> bad Qt4
> version for OS X in the release notes, and we are (finally) done  
> with this
> issue.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and  
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state  
> implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting  
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Werner,

Could you try editing qt.cpp (line 99):
bool initQtApp(bool isGUI)
{
    QMutexLocker locker(&QtPLDriver::mutex);
    bool res=false;
    ++appCounter;
    if(qApp==NULL && appCounter==1)
    {
        argc=1;
        argv=new char*[2];
        argv[0]=new char[10];
        argv[1]=new char[1];
        snprintf(argv[0], 10, "qt_driver");
        argv[1][0]='\0';
        new QApplication(argc, argv, isGUI);
        QLocale::setDefault(QLocale::c()); // add this
        res=true;
    }
    return res;
}

I'm surprised that Qt affects the system configuration that way, but I hope that forcing it to use the "universal" C locale will help ensure we won't get these kinds of issues any more.

Alban
________________________________________
De : plplot-devel-bounces@... [plplot-devel-bounces@...] de la part de Werner Smekal [smekal@...]
Date d'envoi : mardi 1 septembre 2009 09:28
À : Alan W. Irwin
Cc : Plplot-devel mailing list; Hazen Babcock
Objet : Re: [Plplot-devel] Qt driver update

Hi Alan,
>
> That is a really strange result.
>
> The relevant code from plctrl.c (subject to line rewrap) is identified
> exactly by the unique error message above.
>
> fgets(color_info, 160, fp);
> if (sscanf(color_info, "%lf %lf %lf %lf %lf %d",
> &pos_d, &r_d, &g_d, &b_d, &a_d, &rev_i) != 6) {
> snprintf(msgbuf,1024,
> "Unrecognized cmap1 format (wrong number of items for version 2 of
> format) %s\n",
> color_info);
>
> So the above warning message outputs exactly the color_info which
> sscanf
> cannot interpret properly.  But if we look at the data in that warning
> message above it is perfect; five floating point variables in a row,
> then an
> integer just like the above sscanf format directives and corresponding
> pointers.  In particular, we already know there is no hidden null
> characters
> embedded in the middle of color_info because then that would affect
> the
> output of color_info in an obvious way (truncated early).  It is
> hard to
> tell from e-mail, but I suppose there could be a line ending or other
> non-printing characters embedded in the middle of color_info.

I think I found out what the problem is. The first page reads okay,
but then qt takes over to show the plot and somehow changes the locale
or something. This is on a Mac, English version, but Austrian locale -
so after that scanf expects floating point numbers to be written
numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I
assume that this is the problem, since I printed the out the numbers
with printf in case  sscanf fails and the output is:

0: 0.0   0.0   0.0   0.0   1.0 0
1: 1.0   1.0   1.0   1.0   1.0 0
0: 0.0   1.0   1.0   1.0   1.0 0
0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440

*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items (1) for version 2 of
format) 0.0   1.0   1.0   1.0   1.0 0

I'll try now to play around with my locale. The other Mac has also
Austrian locale, but obviously Qt cocoa doesn't mess around here.

I'll keep you informed.

Regards,
Werner


>
> Just to be sure that is not the case, could you run example 16 again
> and
> capture the warning message directly into a file (using ">&" and not
> cut and
> paste to make this test as direct as possible), then analyze that
> file with
> something like od to see whether there are any non-printing
> characters in
> color_info?  This is improbable (since color_info is read
> immediately before
> in the code with fgets above), but it would be good to have rock-solid
> confirmation that this improbability is not true.
>
> If you confirm the color_info output is perfect yet sscanf cannot
> read it,
> this is a second very strange result (after the very strange result
> that the
> problem only occurs for qt devices).
>
> The third very strange result is that the 3rd message above
> corresponds to
> cmap1_gray.pal which is read without issues for the first page of
> the same
> example 16!
>
> One hypothesis that might explain (more or less) all three strange
> results
> is that dynamic loading of qt devices is linking in a Qt4 library that
> breaks sscanf (or fgets if color_info turns out to have some embedded
> non-printing characters) on your system in some way.  I know that
> hypothesis
> is quite speculative/improbable so if somebody here can come up with
> some
> more probable hypothesis to explain these strange results, please
> speak up.
>
> Werner: here are the next steps I would appreciate you doing to help
> figure
> this out.
>
> * Check color_info by directly capturing the above error message
> into a file
> and binary dump that file with something like the od application to
> make
> sure there are no non-printing characters embedded in the middle of
> color_info. (I have done that already with this e-mail, and the
> color_info
> output above was clean of embedded characters, but some of the
> applications
> used in the long e-mail chain between us could have filtered out those
> non-printing characters, and the right way to do this is by
> immediate file
> capture on the platform where the warning message is generated.)
>
> * Experiment with different Qt4 versions to see if the problem goes
> away
> for one of them.
>
> Hazen and Jerry: would you do similar experimentation (running
> example 16
> with a number of different Qt4 versions) to see if you can replicate
> the
> issue that Werner found?  To switch from one Qt4 version to another,
> simply
> put the appropriate qmake on your path before a fresh build and
> cmake does
> the rest.
>
> If by such experiments from Werner, Hazen, and Jerry we establish
> that the
> cmap1 palette file reading problems for example 16 occurs only for
> one Qt4
> version on OS X but not others, then we only have to warn about that
> bad Qt4
> version for OS X in the release notes, and we are (finally) done
> with this
> issue.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Hi,

> I think I found out what the problem is. The first page reads okay,
> but then qt takes over to show the plot and somehow changes the locale
> or something. This is on a Mac, English version, but Austrian locale -
> so after that scanf expects floating point numbers to be written
> numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I
> assume that this is the problem, since I printed the out the numbers
> with printf in case  sscanf fails and the output is:
>
> 0: 0.0   0.0   0.0   0.0   1.0 0
> 1: 1.0   1.0   1.0   1.0   1.0 0
> 0: 0.0   1.0   1.0   1.0   1.0 0
> 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format (wrong number of items (1) for version 2 of
> format) 0.0   1.0   1.0   1.0   1.0 0
>
> I'll try now to play around with my locale. The other Mac has also
> Austrian locale, but obviously Qt cocoa doesn't mess around here.

Ok, this is the problem. Qt carbon changes the locale and sscanf  
doesn't work as expected any more. If I add

setlocale(LC_NUMERIC, "C");

just before the sscanf call, everything works as expected. This is  
obviously not the correct solution but at least we know what is going  
wrong. Also if I change my locale to UK the example works as expected.

Regards,
Werner

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Oops, I forgot: add "#include <QLocale>" somewhere at the top (e.g. below #include <QMutexLocker>)
________________________________________
De : plplot-devel-bounces@... [plplot-devel-bounces@...] de la part de Werner Smekal [smekal@...]
Date d'envoi : mardi 1 septembre 2009 09:47
À : Alan W. Irwin
Cc : Plplot-devel mailing list; Hazen Babcock
Objet : Re: [Plplot-devel] Qt driver update

Hi,

> I think I found out what the problem is. The first page reads okay,
> but then qt takes over to show the plot and somehow changes the locale
> or something. This is on a Mac, English version, but Austrian locale -
> so after that scanf expects floating point numbers to be written
> numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I
> assume that this is the problem, since I printed the out the numbers
> with printf in case  sscanf fails and the output is:
>
> 0: 0.0   0.0   0.0   0.0   1.0 0
> 1: 1.0   1.0   1.0   1.0   1.0 0
> 0: 0.0   1.0   1.0   1.0   1.0 0
> 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440
>
> *** PLPLOT WARNING ***
> Unrecognized cmap1 format (wrong number of items (1) for version 2 of
> format) 0.0   1.0   1.0   1.0   1.0 0
>
> I'll try now to play around with my locale. The other Mac has also
> Austrian locale, but obviously Qt cocoa doesn't mess around here.

Ok, this is the problem. Qt carbon changes the locale and sscanf
doesn't work as expected any more. If I add

setlocale(LC_NUMERIC, "C");

just before the sscanf call, everything works as expected. This is
obviously not the correct solution but at least we know what is going
wrong. Also if I change my locale to UK the example works as expected.

Regards,
Werner

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Hi Alban,

yes it compiles now, but it doesn't work. Still the same problem (I  
reverted all my changes to plctrl.c). Any other ideas?

Regards,
Werner

On 01.09.2009, at 10:53, Rochel, Alban wrote:

> Oops, I forgot: add "#include <QLocale>" somewhere at the top (e.g.  
> below #include <QMutexLocker>)
> ________________________________________
> De : plplot-devel-bounces@... [plplot-devel-bounces@... 
> ] de la part de Werner Smekal [smekal@...]
> Date d'envoi : mardi 1 septembre 2009 09:47
> À : Alan W. Irwin
> Cc : Plplot-devel mailing list; Hazen Babcock
> Objet : Re: [Plplot-devel] Qt driver update
>
> Hi,
>
>> I think I found out what the problem is. The first page reads okay,
>> but then qt takes over to show the plot and somehow changes the  
>> locale
>> or something. This is on a Mac, English version, but Austrian  
>> locale -
>> so after that scanf expects floating point numbers to be written
>> numbers like 3,1415 and not 3.1415. scanf fails then on the  
>> numbers. I
>> assume that this is the problem, since I printed the out the numbers
>> with printf in case  sscanf fails and the output is:
>>
>> 0: 0.0   0.0   0.0   0.0   1.0 0
>> 1: 1.0   1.0   1.0   1.0   1.0 0
>> 0: 0.0   1.0   1.0   1.0   1.0 0
>> 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440
>>
>> *** PLPLOT WARNING ***
>> Unrecognized cmap1 format (wrong number of items (1) for version 2 of
>> format) 0.0   1.0   1.0   1.0   1.0 0
>>
>> I'll try now to play around with my locale. The other Mac has also
>> Austrian locale, but obviously Qt cocoa doesn't mess around here.
>
> Ok, this is the problem. Qt carbon changes the locale and sscanf
> doesn't work as expected any more. If I add
>
> setlocale(LC_NUMERIC, "C");
>
> just before the sscanf call, everything works as expected. This is
> obviously not the correct solution but at least we know what is going
> wrong. Also if I change my locale to UK the example works as expected.
>
> Regards,
> Werner
>
> --
> Dr. Werner Smekal
> Institut fuer Allgemeine Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> Austria
>
> email: smekal@...
> web: http://www.iap.tuwien.ac.at/~smekal
> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469  
> (laboratory)
> fax: +43-(0)1-58801-13499
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

Hi Alban,

yes this works. I'll commit this as well. We may have to discuss, if  
this doesn't break anything else, e.g. if someone wants to use the  
driver in her Qt application, but as I understand it will initQtApp()  
only called if there is no existing qt app (or at least the specific  
lines), so this should be not much trouble.

Thanks for your help,
Werner

On 01.09.2009, at 10:58, Rochel, Alban wrote:

> Hi Werner,
>
> I'm not sure when Qt makes this change to the system settings, but I  
> suppose it's during the QApplication creation. So, can you try  
> changing
> QLocale::setDefault(QLocale::c())
> into
> setlocale(LC_NUMERIC, "C");
> in qt.cpp (line ~100)?
>
> I hope this will work because I'm out of ideas...
>
> Alban
> ________________________________________
> De : Werner Smekal [smekal@...]
> Date d'envoi : mardi 1 septembre 2009 09:56
> À : Rochel, Alban
> Cc : Alan W. Irwin; Plplot-devel mailing list; Hazen Babcock
> Objet : Re: RE : [Plplot-devel] Qt driver update
>
> Hi Alban,
>
> yes it compiles now, but it doesn't work. Still the same problem (I
> reverted all my changes to plctrl.c). Any other ideas?
>
> Regards,
> Werner
>
> On 01.09.2009, at 10:53, Rochel, Alban wrote:
>
>> Oops, I forgot: add "#include <QLocale>" somewhere at the top (e.g.
>> below #include <QMutexLocker>)
>> ________________________________________
>> De : plplot-devel-bounces@... [plplot-devel-bounces@...
>> ] de la part de Werner Smekal [smekal@...]
>> Date d'envoi : mardi 1 septembre 2009 09:47
>> À : Alan W. Irwin
>> Cc : Plplot-devel mailing list; Hazen Babcock
>> Objet : Re: [Plplot-devel] Qt driver update
>>
>> Hi,
>>
>>> I think I found out what the problem is. The first page reads okay,
>>> but then qt takes over to show the plot and somehow changes the
>>> locale
>>> or something. This is on a Mac, English version, but Austrian
>>> locale -
>>> so after that scanf expects floating point numbers to be written
>>> numbers like 3,1415 and not 3.1415. scanf fails then on the
>>> numbers. I
>>> assume that this is the problem, since I printed the out the numbers
>>> with printf in case  sscanf fails and the output is:
>>>
>>> 0: 0.0   0.0   0.0   0.0   1.0 0
>>> 1: 1.0   1.0   1.0   1.0   1.0 0
>>> 0: 0.0   1.0   1.0   1.0   1.0 0
>>> 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440
>>>
>>> *** PLPLOT WARNING ***
>>> Unrecognized cmap1 format (wrong number of items (1) for version 2  
>>> of
>>> format) 0.0   1.0   1.0   1.0   1.0 0
>>>
>>> I'll try now to play around with my locale. The other Mac has also
>>> Austrian locale, but obviously Qt cocoa doesn't mess around here.
>>
>> Ok, this is the problem. Qt carbon changes the locale and sscanf
>> doesn't work as expected any more. If I add
>>
>> setlocale(LC_NUMERIC, "C");
>>
>> just before the sscanf call, everything works as expected. This is
>> obviously not the correct solution but at least we know what is going
>> wrong. Also if I change my locale to UK the example works as  
>> expected.
>>
>> Regards,
>> Werner
>>
>> --
>> Dr. Werner Smekal
>> Institut fuer Allgemeine Physik
>> Technische Universitaet Wien
>> Wiedner Hauptstr 8-10
>> A-1040 Wien
>> Austria
>>
>> email: smekal@...
>> web: http://www.iap.tuwien.ac.at/~smekal
>> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469
>> (laboratory)
>> fax: +43-(0)1-58801-13499
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and
>> focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Plplot-devel mailing list
>> Plplot-devel@...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> --
> Dr. Werner Smekal
> Institut fuer Allgemeine Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> Austria
>
> email: smekal@...
> web: http://www.iap.tuwien.ac.at/~smekal
> phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469  
> (laboratory)
> fax: +43-(0)1-58801-13499
>

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: smekal@...
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499

On 2009-09-01 09:12+0200 Werner Smekal wrote:

>> This is improbable (since color_info is read immediately 
>> before
>> in the code with fgets above), but it would be good to have rock-solid
>> confirmation that this improbability is not true.
>
> I only see text, spaces and linefeeds, so it should be ok (see attached png).

I agree that is completely clean of special characters (except for linefeeds
in the right place).  Thanks for that confirmation.


>> One hypothesis that might explain (more or less) all three strange results
>> is that dynamic loading of qt devices is linking in a Qt4 library that
>> breaks sscanf (or fgets if color_info turns out to have some embedded
>> non-printing characters) on your system in some way.  I know that 
>> hypothesis
>> is quite speculative/improbable so if somebody here can come up with some
>> more probable hypothesis to explain these strange results, please speak up.
>
> Just to make it more strange. Nokia actually provides two packages of Qt - 
> cocoa and carbon, whil cocoa is the "new" API (use for Mac OS X 10.6). I 
> actually have two Macs here (both latest 10.5.8 and xcode) and on one I 
> installed the carbon binary package and on the other cocoa binary package 
> (see http://qt.nokia.com/downloads/mac-os-cpp). While the Qt carbon leads to 
> this strange cmap results, does Qt cocoa not print out this warnings - so the 
> file qt devices work regarding the color. But qtwidget is messed up again, 
> since the first plot appears (for multipage examples and after I click on the 
> plot, before only grey window), but the following plots are not shown only 
> the background color. I really have to say that Qt on Mac OS X is quite buggy 
> as it seems.

I have to agree.  Thanks for all these tests.

>> Hazen and Jerry: would you do similar experimentation (running example 16
>> with a number of different Qt4 versions) to see if you can replicate the
>> issue that Werner found?  To switch from one Qt4 version to another, simply
>> put the appropriate qmake on your path before a fresh build and cmake does
>> the rest.
>
> I used the binary packages, where a switch is not that easy. I just don't 
> have the time to download the 450Mb source package and compile qt in 
> different versions, which I assume will really take a long time, if this 
> 450MB monster is uncompressed.

I don't believe compilation will be necessary so using the SDK may be a lot
more straightforward than you think.

Just to give my own experience, on Linux I downloaded the Qt4 SDK (software
development kit) from https://edit.qt.troll.no/downloads).  I have forgotten
where I got the subsequent instructions, but here are my notes of exactly
what I did.

chmod u+x qt-sdk-linux-x86_64-opensource-2009.02.bin
./qt-sdk-linux-x86_64-opensource-2009.02.bin

i.e., I changed the permission to execute and then ran that downloaded
installer binary application.  That installer then gave you a GUI where you
could choose the installation prefix.  By default that was a non-system
location (/home/software/qtsdk-2009.02 for me where "software" is the name
of the user account where I did the install). After that, the installation
was quite fast with lots of disk activity but no cpu activity consistent
with just getting a binary installed from the downloaded SDK rather than
actually compiling it.

I suspect if you download the 442MB Qt4 SDK for Mac OS X (see
https://edit.qt.troll.no/downloads) it will also result in a binary install
to a non-system location.  After that, if you put that binary installs
version of qmake (/home/software/qtsdk-2009.02/qt/bin/qmake in my case) on
your PATH, then a fresh build of PLplot will just use that version of Qt4
with no interference from your system version.

To Werner, Hazen, and Jerry: There is no mention on the above trolltech site
whether the downloaded SDK for Mac OS X is packaged with Carbon or Cocoa or
neither, but since the Carbon and Cocoa system packages for Qt4 seem to be
broken in various ways for Werner regardless of Qt4 version, you might want
just avoid those and use the downloadable trolltech Qt4 SDK instead.

I also have the same advice (use the trolltech Qt4 SDK) on both Linux and
Windows platforms.  On Linux, that SDK version was certainly the most
reliable version of Qt4 for me.  That makes a lot of sense since Trolltech
is the world's expert on building Qt4, and, of course, the SDK is their
recommended version of Qt4.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-09-01 12:08+0200 Werner Smekal wrote:

> Hi Alban,
>
> yes this [setting locale in qt] works.

Hi Werner:

Thanks very much for thinking of locale as a possibility for messing up
sscanf.  That was a stroke of debugging genius, and it is wonderful news
that we now have the reason for all the strange results you were getting
when attempting to read palette files.

However, I don't think the current solution (revision 10363) to this problem
is correct. Instead of forcing the C locale whenever we use qt, the user
should be allowed to use any locale they like for _user_ input to PLplot
regardless of device driver. Of course, our palette files absolutely require
setlocale(LC_NUMERIC, "C"); in order to be read properly as you have
discovered. Thus, I think our best solution to this whole issue is to save
the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then
restore the user locale in both cmap0_palette_read and plspal1.  This method
absolutely guards against any locale issue (say for a different library than
qt) ever again screwing up palette file reading so this is what I like.

What do you think of this idea?  If you agree, would you be willing to help
with the implementation and testing?  (I don't know how to get the current
locale [there appears to be no function called getlocale, although
localeconv might be a possibility on Linux], and we have to insure that
setlocale [and whatever you recommend for getting the current locale
information] works on all our platforms.)

Alan
__________________________
Alan W. Irwin

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

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); 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
__________________________

I have assigned a new subject because this topic deserves its own thread.

On 2009-09-01 11:24-0700 Alan W. Irwin wrote:

> [...]  Thus, I think our best solution to this whole issue is to save
> the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then
> restore the user locale in both cmap0_palette_read and plspal1.  This method
> absolutely guards against any locale issue (say for a different library than
> qt) ever again screwing up palette file reading so this is what I like.
>
> What do you think of this idea?

I have continued to think some more about LC_NUMERIC issues in PLplot, and
to give some context to further discussion of this, have a look at
http://en.wikipedia.org/wiki/File:DecimalSeparator.png.  My own country of
Canada has different decimal separators depending upon whether you are
located in Quebec or otherwise, and a substantial fraction of the countries
in the world use the comma for the separator rather than a period.

The current status is our plots all correspond to

setlocale(LC_NUMERIC, "C");

That is they use the period as the decimal separator on axis labels. This is
probably consistent with the policy of many scientific publishers out there,
but there are almost guaranteed to be some publishers that accept a decimal
separator in plots that is whatever the author likes and even some that
demand the comma separator regardless of the locale of the author. In
addition, although we advertise PLplot as a scientific plotting library, it
is also used in other contexts as well where there may be a need to follow
the local locale with a comma decimal separator. Thus, for maximum PLplot
usefulness, I think we should have a global variables local_locale set to 0
or 1 at user option so that plinit calls either

setlocale(LC_NUMERIC, "C");

for local_locale = 0

or

setlocale(LC_NUMERIC, "");

for local_locale = 1,

where the first one should be the default, and the latter one gives complete
flexibility since it obtains LC_NUMERIC from the environment (which can be
set to anything by the user).

Furthermore, this would fit in with my proposed solution to the above issue
if we always setlocale(LC_NUMERIC, "C"); before reading palette files
regardless of local_locale and restore to either of the above two choices
depending on local_locale. Finally, in qt.cpp we should change back to the
PLplot locale specified by local_locale just in case the Qt4 libraries
change it.

I hope to implement all of this later today or early tomorrow so please let
me know quickly your comments on my proposal to deal with LC_NUMERIC issues
in PLplot.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Alan,

much as I appreciate the use of commas instead of periods (living in
a country where commas are used - or should be - as the decimal
separator), I do see a number of problems:
- If a user sets the locale in his/her program before a call to
   plinit(), a default enforced by PLplot might cause a different
   behaviour than expected.
- If PLplot sets the locale, does this have consequences for
   functions like fscanf()? I have never dug into the specifics,
   but it might all of a sudden read "1,2" as the number 1.2.

The effect of introducing setlocale() in PLplot should, in my
opinion, be limited entirely to calls to the PLplot library.
Otherwise there could be all manner of trouble that is difficult
to hunt down.

Maybe I am pessimistic, but I have seen too many bizarre consequences
from half-hearted implementations of locale settings. (Older versions
of MS Excel made spreadsheets written in one locale unuseable in
another locale, because "1.2" suddenly was a literal string instead
of a number. Even more troublesome: current versions use function
names that are specific to the human language the operating system
is set to. At home I need to type SOM(A1:A10) instead of SUM(A1:A10),
as the OS is set to Dutch.)

Regards,

Arjen

On 2009-09-03 21:48, Alan W. Irwin wrote:
> I have assigned a new subject because this topic deserves its own thread.
> 
> On 2009-09-01 11:24-0700 Alan W. Irwin wrote:
> 
>> [...]  Thus, I think our best solution to this whole issue is to save
>> the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then
>> restore the user locale in both cmap0_palette_read and plspal1.  This method
>> absolutely guards against any locale issue (say for a different library than
>> qt) ever again screwing up palette file reading so this is what I like.
>>
>> What do you think of this idea?
> 
> I have continued to think some more about LC_NUMERIC issues in PLplot, and
> to give some context to further discussion of this, have a look at
> http://en.wikipedia.org/wiki/File:DecimalSeparator.png.  My own country of
> Canada has different decimal separators depending upon whether you are
> located in Quebec or otherwise, and a substantial fraction of the countries
> in the world use the comma for the separator rather than a period.
> 
> The current status is our plots all correspond to
> 
> setlocale(LC_NUMERIC, "C");
> 
> That is they use the period as the decimal separator on axis labels. This is
> probably consistent with the policy of many scientific publishers out there,
> but there are almost guaranteed to be some publishers that accept a decimal
> separator in plots that is whatever the author likes and even some that
> demand the comma separator regardless of the locale of the author. In
> addition, although we advertise PLplot as a scientific plotting library, it
> is also used in other contexts as well where there may be a need to follow
> the local locale with a comma decimal separator. Thus, for maximum PLplot
> usefulness, I think we should have a global variables local_locale set to 0
> or 1 at user option so that plinit calls either
> 
> setlocale(LC_NUMERIC, "C");
> 
> for local_locale = 0
> 
> or
> 
> setlocale(LC_NUMERIC, "");
> 
> for local_locale = 1,
> 
> where the first one should be the default, and the latter one gives complete
> flexibility since it obtains LC_NUMERIC from the environment (which can be
> set to anything by the user).
> 
> Furthermore, this would fit in with my proposed solution to the above issue
> if we always setlocale(LC_NUMERIC, "C"); before reading palette files
> regardless of local_locale and restore to either of the above two choices
> depending on local_locale. Finally, in qt.cpp we should change back to the
> PLplot locale specified by local_locale just in case the Qt4 libraries
> change it.
> 
> I hope to implement all of this later today or early tomorrow so please let
> me know quickly your comments on my proposal to deal with LC_NUMERIC issues
> in PLplot.
> 
> 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); PLplot scientific plotting software
> package (plplot.org); 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
> __________________________
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Hi Alan,

I have looked at the locale behaviour with the small program below:

/* chklocale.c --
        Check the behaviour of the locale - printf() and friends
*/

#include <stdio.h>
#include <locale.h>

int main( int argc, char *argv[] ) {

     float x = 1.2;

     setlocale(LC_NUMERIC, "");

     printf( "Number: %f\n", x );

     if ( argc > 1 ) {
         sscanf( argv[1], "%f", &x );
         printf( "Read: %f\n", x );
     }
}

Setting LC_NUMERIC to "nl_NL.UTF-8" gives the following
results:

 > chklocale 1.3
chklocale 1.3
Number: 1,200000
Read: 1,000000

 > chklocal 1,3
chklocale 1.3
Number: 1,200000
Read: 1,300000

So indeed - as was to be expected, the comma is used on input and
output instead of a period. If PLplot's setting of the locale is visible
outside the PLplot functions, this may give very nasty errors!

Regards,

Arjen

On 2009-09-04 08:59, Arjen Markus wrote:
> Hi Alan,
> 
> much as I appreciate the use of commas instead of periods (living in
> a country where commas are used - or should be - as the decimal
> separator), I do see a number of problems:
> - If a user sets the locale in his/her program before a call to
>    plinit(), a default enforced by PLplot might cause a different
>    behaviour than expected.
> - If PLplot sets the locale, does this have consequences for
>    functions like fscanf()? I have never dug into the specifics,
>    but it might all of a sudden read "1,2" as the number 1.2.
> 
> The effect of introducing setlocale() in PLplot should, in my
> opinion, be limited entirely to calls to the PLplot library.
> Otherwise there could be all manner of trouble that is difficult
> to hunt down.
> 
> Maybe I am pessimistic, but I have seen too many bizarre consequences
> from half-hearted implementations of locale settings. (Older versions
> of MS Excel made spreadsheets written in one locale unuseable in
> another locale, because "1.2" suddenly was a literal string instead
> of a number. Even more troublesome: current versions use function
> names that are specific to the human language the operating system
> is set to. At home I need to type SOM(A1:A10) instead of SUM(A1:A10),
> as the OS is set to Dutch.)
> 
> Regards,
> 
> Arjen
> 
> On 2009-09-03 21:48, Alan W. Irwin wrote:
>> I have assigned a new subject because this topic deserves its own thread.
>>
>> On 2009-09-01 11:24-0700 Alan W. Irwin wrote:
>>
>>> [...]  Thus, I think our best solution to this whole issue is to save
>>> the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then
>>> restore the user locale in both cmap0_palette_read and plspal1.  This method
>>> absolutely guards against any locale issue (say for a different library than
>>> qt) ever again screwing up palette file reading so this is what I like.
>>>
>>> What do you think of this idea?
>> I have continued to think some more about LC_NUMERIC issues in PLplot, and
>> to give some context to further discussion of this, have a look at
>> http://en.wikipedia.org/wiki/File:DecimalSeparator.png.  My own country of
>> Canada has different decimal separators depending upon whether you are
>> located in Quebec or otherwise, and a substantial fraction of the countries
>> in the world use the comma for the separator rather than a period.
>>
>> The current status is our plots all correspond to
>>
>> setlocale(LC_NUMERIC, "C");
>>
>> That is they use the period as the decimal separator on axis labels. This is
>> probably consistent with the policy of many scientific publishers out there,
>> but there are almost guaranteed to be some publishers that accept a decimal
>> separator in plots that is whatever the author likes and even some that
>> demand the comma separator regardless of the locale of the author. In
>> addition, although we advertise PLplot as a scientific plotting library, it
>> is also used in other contexts as well where there may be a need to follow
>> the local locale with a comma decimal separator. Thus, for maximum PLplot
>> usefulness, I think we should have a global variables local_locale set to 0
>> or 1 at user option so that plinit calls either
>>
>> setlocale(LC_NUMERIC, "C");
>>
>> for local_locale = 0
>>
>> or
>>
>> setlocale(LC_NUMERIC, "");
>>
>> for local_locale = 1,
>>
>> where the first one should be the default, and the latter one gives complete
>> flexibility since it obtains LC_NUMERIC from the environment (which can be
>> set to anything by the user).
>>
>> Furthermore, this would fit in with my proposed solution to the above issue
>> if we always setlocale(LC_NUMERIC, "C"); before reading palette files
>> regardless of local_locale and restore to either of the above two choices
>> depending on local_locale. Finally, in qt.cpp we should change back to the
>> PLplot locale specified by local_locale just in case the Qt4 libraries
>> change it.
>>
>> I hope to implement all of this later today or early tomorrow so please let
>> me know quickly your comments on my proposal to deal with LC_NUMERIC issues
>> in PLplot.
>>
>> 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); PLplot scientific plotting software
>> package (plplot.org); 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
>> __________________________
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
>> trial. Simplify your report design, integration and deployment - and focus on 
>> what you do best, core application coding. Discover what's new with 
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Plplot-devel mailing list
>> Plplot-devel@...
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>>
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

On 2009-09-04 13:43+0200 Arjen Markus wrote:

> Hi Alan,
>
> I have looked at the locale behaviour with the small program below:
>
> /* chklocale.c --
>        Check the behaviour of the locale - printf() and friends
> */
>
> #include <stdio.h>
> #include <locale.h>
>
> int main( int argc, char *argv[] ) {
>
>     float x = 1.2;
>
>     setlocale(LC_NUMERIC, "");
>
>     printf( "Number: %f\n", x );
>
>     if ( argc > 1 ) {
>         sscanf( argv[1], "%f", &x );
>         printf( "Read: %f\n", x );
>     }
> }
>
> Setting LC_NUMERIC to "nl_NL.UTF-8" gives the following
> results:
>
> > chklocale 1.3
> chklocale 1.3
> Number: 1,200000
> Read: 1,000000
>
> > chklocal 1,3
> chklocale 1.3
> Number: 1,200000
> Read: 1,300000
>
> So indeed - as was to be expected, the comma is used on input and
> output instead of a period. If PLplot's setting of the locale is visible
> outside the PLplot functions, this may give very nasty errors!

Hi Arjen:

I was hoping you would respond to my post since you live in a country
where the decimal separator is a comma rather than period.

However, now I have slept on this idea I don't like my suggested
implementation any more.  I don't think it is a good idea for the PLplot
library to set locale since that might conflict with what is assumed by
libraries or applications that use the PLplot library. (We were the victim
of this ourselves when one form of Qt4 library on OS X set locale without
restoring it to whatever PLplot assumed after it was done.)

My new idea is it is perfectly legitimate for applications such as
examples/c/x01c.c to contain

setlocale(LC_NUMERIC, "");

So I now lean toward making that call as a special option for that example
(implemented the same general way as the xor option for that example).  That
should give those who prefer the comma separator for the axis label a
specific example of how their applications should be set up to do just that.
Note such an example option would also demand the comma separator be used
consistently for user input, e.g., "-fsiz 0,5G" rather than "-fsiz 0.5G" for
specifying PLplot floating point values on the command line, but I think
that is okay since if a user specifically demands comma separators via his
locale, but then fails to use them for his command-line input, he probably
gets what he deserves.  :-)

Demonstrating the possibility of using the user's locale as an option for
example 1 is probably the correct way to show this possibility for PLplot,
but it still leaves the issue of protecting PLplot library file reads (such
as the palette file reads which require a period decimal separator) from
whatever locale other libraries and applications have set.  My reading of
the man page for setlocale indicates we can store the current locale in an
opaque character string using a NULL locale string as an argument, and then
after executing

setlocale(LC_NUMERIC, "C");

to protect the read, we can restore back the original locale using the
opaque character string.  Anyhow, today I will try implementing the example
1 -use_locale option and see whether I can get that to work with my suggested
method of protecting the file reads.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-09-04 11:00-0700 Alan W. Irwin wrote:

> My reading of
> the man page for setlocale indicates we can store the current locale in an
> opaque character string using a NULL locale string as an argument [...]

As far as I know, nobody has tested qt on windows so I am not even sure
Werner's setlocale fix would even build in that case, much less work
properly.  Any more general fix for the locale issue necessarily must use
the setlocale function (just like Werner's fix did).  Thus, until setlocale
is actually tested on Windows I am extremely uncomfortable inserting
untested (in a cross-platform sense) calls to that function into our code
this close to our release.

Accordingly just for this release (revision 10370) I have commented out all
the recent locale changes (which means setlocale will never be called by
PLplot for this release just as for all previous releases).  The downside of
this conservative approach is that our palette colour file won't be readable
if _any_ application or library that calls PLplot, fiddles with the
LC_NUMERIC locale in such a way to change the decimal separator from period
to commma and similarly if any library that PLplot calls (such as Qt4)
fiddles with the LC_NUMERIC locale in the same way.  Thus, if some user uses
the Carbon packages for Qt4 on OS X (which apparently does mess with the
LC_NUMERIC locale although the corresponding cocoa packages apparently do
not) that user will get a warning message and will have warning colours (red
on white for cmap0 and red scale for cmap1) used for the default palettes.

This is not a particularly satisfactory solution (in fact it is no solution)
to the issue of external library or application LC_NUMERIC locale changes
screwing up PLplot, but I think that is the best I can come up with this
close to release.  Just after the release I intend to do a good
implementation of this (saving and restoring locale appropriately) using
setlocale.  This should give us plenty of time to test the implementation
(i.e., make sure setlocale works as intended) on all our platforms before
the next release.

I plan to do a bit more testing tommorrow, but basically I should be done
making commits for this 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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

I have a fairly urgent question (since release reliability might be
affected) for Maurice (or anyone else who feels they might have a chance to
understand plLibOpen) at the end.  This question came up as a natural
outgrowth of my setlocale investigations which I am reporting here
for everybody.

While waiting for the release I am still trying to figure out a solid way to
restore locale, but I am running into some really strange results.

The recommended method of saving and restoring locale is the following (see
http://developers.sun.com/dev/gadc/educationtutorial/creference/locale/locale.html):

/* Save original locale name */
char * locale_string_ptr=setlocale(LC_NUMERIC, NULL);

... do other specific setlocale commands, e.g.,

setlocale(LC_NUMERIC, "C");

/* Restore original locale using original locale name. */

setlocale(LC_NUMERIC, locale_string_ptr);

If I use the above idea in a simple test programme it works.  However,
valgrind reports invalid read errors for that final setlocale command so the
Linux implementation is problematic and at minimum will add a lot of
unacceptable noise to every single one of our valgrind reports.

If I use the above in cmap0_palette_read to save and restore whatever the
calling application uses for locale while using the "C" locale for the file
read, it works the first time, but on the second time cmap0_palette_read is
called, the string pointed to by locale_string_ptr is filled with garbage
(probably because of the problematic implementation noted above) and as a
result setlocale fails.  I debugged this with gdb, and the library call that
appears to generate the garbage is "fclose(fp);" in cmap0_palette_read.  If
I comment that out, then the logic succeeds, locale_string_ptr points to an
empty string and the setlocale call that restores locale succeeds (although
there are still a lot of serious valgrind errors reported for that call or
if I simply output the string).

Maurice (or somebody else here who understands the plLibOpen logic): could
you review the plLibOpen logic and confirm it is correct to close a file
opened that way with fclose?  The plLibOpen logic has been sitting around
as part of PLplot for ages, but it appears cmap0_palette_read and
plspal1 are our first attempts to ever use that logic which is why it
needs review by an expert (ideally before the release on Sunday).

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-09-05 16:39-0700 Alan W. Irwin wrote:

> The recommended method of saving and restoring locale is the following (see
> http://developers.sun.com/dev/gadc/educationtutorial/creference/locale/locale.html):

> [...]If I use the above idea in a simple test programme it works.  However,
> valgrind reports invalid read errors for that final setlocale command so the
> Linux implementation is problematic and at minimum will add a lot of
> unacceptable noise to every single one of our valgrind reports.

Finally figured this out this morning.  The suggestion in the above URL was
oversimplified since subsequent setlocale commands were messing with the
string pointed to by setlocale(LC_NUMERIC, NULL).  If you immediately copy
that string instead, and use the copied string to restore locale later on,
the result on Linux always works (no garbarge in string) and is valgrind
clean both for my test programme and a similar test in my local version of
cmap0_palette_read.  So finally, I think I am on the right track for the
correct way to save and restore locale.  There are some more implementation
details to do, but it should not be too long after the release today before
I can commit this, and get it tested on all our platforms.

> Maurice (or somebody else here who understands the plLibOpen logic): could
> you review the plLibOpen logic and confirm it is correct to close a file
> opened that way with fclose?  The plLibOpen logic has been sitting around
> as part of PLplot for ages, but it appears cmap0_palette_read and
> plspal1 are our first attempts to ever use that logic which is why it
> needs review by an expert (ideally before the release on Sunday).

The result is now valgrind clean (no errors, no leaks possible) and seems to
work so I think using fclose to close the file opened by plLibOpen is
probably OK.  Neverthess, a code review would be worthwhile just to make
sure all is well since this is the first time (for a long while at least)
that plLibOpen has actually been used from within PLplot.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-09-06 09:09-0700 Alan W. Irwin wrote:

> So finally, I think I am on the right track for the
> correct way to save and restore locale.  There are some more implementation
> details to do, but it should not be too long after the release today before
> I can commit this, and get it tested on all our platforms.

DONE as of revision 10380 (aside from the non-Linux testing part which I
leave to those with access to such platforms).  The implementation of the
locale saving and restoring infrastructure (plsave_set_locale and
plrestore_locale) uses the setlocale function from the C library.  I assume
that is present and works the same way on OS X and Windows, but please check
that assumption by attempting to build PLplot and running example 16 on
those platforms.  The palette file reading routines already use the new
infrastruture and will automatically be exercised by that example.

After you establish plsave_set_locale and plrestore_locale work as expected
on your platform using example 16 further testing would be a good idea.

The ability of PLplot to handle external locale changes is tested with the
-locale option for example 1.  This currently works well for me
(comma-separated [!] decimal separators for the axis labelling and valgrind
clean) for qt devices, e.g.,

LC_NUMERIC='nl_NL.utf8' examples/c/x01c -locale -cmap1 \
cmap1_gray.pal -cmap0 cmap0_black_on_white.pal -dev epsqt -o test.psc

This also works for the interactive devices I have tried such as qtwidget
and xwin, but not for any cairo device (both interactive and file cairo
devices just plot the box of the first subplot of example 1 when the -locale
option is used for that example).  I have also found the psc device craps
out with -locale for C example 1. The PostScript file is filled with commas
rather than periods for all floating-point PostScript quantities for -dev
psc (as you would expect if you think about how ps.c is implemented.) This
vulnerability against locale changes in apps that call the PLplot library
(such as occurs for the -locale option for C example 1) is nothing new, and
it is going to take some effort to sort out these issues for all our
devices. We are not alone in being vulnerable this way. Our competitor,
gnuplot, has garnered a number of bug reports concerning locale issues.

The obvious fix for ps.c is to protect all the file writes in ps.c against
external locale changes by surrounding them with plsave_set_locale(); and
plrestore_locale();.  I have applied that pair of functions to my local
version of ps.c before the file open and after the file close, and that
works, but it also suppresses PLplot's ability to to use comma separators
for axis labels.  Thus, using those functions in a finer-grained way is
indicated (probably from the PLplot core library to deal with all file
devices at once).

BTW, plsave_set_locale and plrestore_locale are the antithesis of functional
programming because they have no arguments and return nothing.  That is,
they cause nothing but side effects.  However, that is the name of the game
when dealing with POSIX locale issues.  plsave_set_locale simply saves the
original locale string (set by external code such as x01c.c) in a global way
and sets locale to "C". plrestore_locale restores the original locale, and
frees the memory where the original global locale string was stored.

I think this is the best way to implement this pair of functions because I
think we will always need them to communicate with each other between
different routines. (Note, the file open and close are in different routines
in ps.c if we want to block all locale changes when writing the output
PostScript file from ps.c as above.) However, my C skills are not as good as
I would like them to be so I would be interested in discussing changes in
the implementation of these two functions if someone has some better ideas.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-09-06 18:36-0700 Alan W. Irwin wrote:

> BTW, plsave_set_locale and plrestore_locale are the antithesis of functional
> programming because they have no arguments and return nothing.  That is,
> they cause nothing but side effects.  However, that is the name of the game
> when dealing with POSIX locale issues.  plsave_set_locale simply saves the
> original locale string (set by external code such as x01c.c) in a global way
> and sets locale to "C". plrestore_locale restores the original locale, and
> frees the memory where the original global locale string was stored.
>
> I think this is the best way to implement this pair of functions because I
> think we will always need them to communicate with each other between
> different routines. (Note, the file open and close are in different routines
> in ps.c if we want to block all locale changes when writing the output
> PostScript file from ps.c as above.) However, my C skills are not as good as
> I would like them to be so I would be interested in discussing changes in
> the implementation of these two functions if someone has some better ideas.

Well, practical experience with plsave_set_locale and plrestore_locale today
showed me that these are always called from the same routine so I didn't
need the global variable approach. Dropping that allowed me to change these
to reentrant routines (which was required for some situations [i.e., the
-debug option which recursively called these routines] in any case).

I have now protected all PLplot core device driver calls with these routines
(revision 10383), and the result is all devices appear to work fine
for the -locale option for example 1.  That is,

LC_NUMERIC=nl_NL.utf8 examples/c/x01c -locale

appears to give a comma decimal separator for axis labels for every device I
have tried with no obvious valgrind or other issues.

So this looks quite promising, and I plan to follow up by expanding the
testing of this new PLplot feature to all devices and all examples to see if
there are any limitations for this new feature. The test of locale for all
examples will be made possible by replacing the limited example 1 -locale
option by a general -locale option that executes

setlocale(LC_NUMERIC, "");

to establish the basic PLplot locale and thus make PLplot generally portable
to all LC_NUMERIC locales depending on how users set the LC_NUMERIC
or LC_ALL environment variables.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Alan,

I have been experimenting a bit with the test program I sent earlier
to see how this works on Windows. Well, the short version is:
setlocale() doesn't have effect.

The long version is:
With both MSVC/C++ 6.0 and MSVC/C++ 2008 I have been unable to get
a comma to work as a decimal separator. The online help uses quite
different names from nl_NL and the like (Dutch_netherlands and
similar names for other countries/languages), but there is no
effect whatsoever.

This is the program:

// chklocale.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "locale.h"


int _tmain(int argc, _TCHAR* argv[])
{
	float x = 1.2;
	char *pstr;

     pstr = setlocale(LC_NUMERIC, "");

     printf( "Number: %f -- %s\n", x, pstr );

     if ( argc > 1 ) {
         sscanf( (char *)argv[1], "%f", &x );
         printf( "Read: %f\n", x );
     }
	if ( argc > 2 ) {
		pstr = setlocale(LC_ALL, (char *)argv[2]);
         sscanf( (char *)argv[1], "%f", &x );
         printf( "Read: %f -- %s\n", x, pstr );
     }
}

It writes the return string from setlocale() and produces:

chklocale 1,3 English
Number: 1.200000 -- Dutch_Netherlands.1252
Read: 1.000000
Read: 1.000000 -- (null)

(I expected the first 1.0 to read 1,3)

... I remembered suddenly that on Windows you can set the regional
settings. That contained a period ... So setting that to a comma,
I get:

chklocale 1,3 Dutch_Netherlands.1252
Number: 1,200000 -- Dutch_Netherlands.1252
Read: 1,000000
Read: 1,000000 -- (null)

Note: the comma is apparently not recognised on input, it is used
on output!

(I should check this with gcc too ...)

Regards,

Arjen


On 2009-09-08 05:50, Alan W. Irwin wrote:
> On 2009-09-06 18:36-0700 Alan W. Irwin wrote:
> 
>> BTW, plsave_set_locale and plrestore_locale are the antithesis of functional
>> programming because they have no arguments and return nothing.  That is,
>> they cause nothing but side effects.  However, that is the name of the game
>> when dealing with POSIX locale issues.  plsave_set_locale simply saves the
>> original locale string (set by external code such as x01c.c) in a global way
>> and sets locale to "C". plrestore_locale restores the original locale, and
>> frees the memory where the original global locale string was stored.
>>
>> I think this is the best way to implement this pair of functions because I
>> think we will always need them to communicate with each other between
>> different routines. (Note, the file open and close are in different routines
>> in ps.c if we want to block all locale changes when writing the output
>> PostScript file from ps.c as above.) However, my C skills are not as good as
>> I would like them to be so I would be interested in discussing changes in
>> the implementation of these two functions if someone has some better ideas.
> 
> Well, practical experience with plsave_set_locale and plrestore_locale today
> showed me that these are always called from the same routine so I didn't
> need the global variable approach. Dropping that allowed me to change these
> to reentrant routines (which was required for some situations [i.e., the
> -debug option which recursively called these routines] in any case).
> 
> I have now protected all PLplot core device driver calls with these routines
> (revision 10383), and the result is all devices appear to work fine
> for the -locale option for example 1.  That is,
> 
> LC_NUMERIC=nl_NL.utf8 examples/c/x01c -locale
> 
> appears to give a comma decimal separator for axis labels for every device I
> have tried with no obvious valgrind or other issues.
> 
> So this looks quite promising, and I plan to follow up by expanding the
> testing of this new PLplot feature to all devices and all examples to see if
> there are any limitations for this new feature. The test of locale for all
> examples will be made possible by replacing the limited example 1 -locale
> option by a general -locale option that executes
> 
> setlocale(LC_NUMERIC, "");
> 
> to establish the basic PLplot locale and thus make PLplot generally portable
> to all LC_NUMERIC locales depending on how users set the LC_NUMERIC
> or LC_ALL environment variables.
> 
> 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); PLplot scientific plotting software
> package (plplot.org); 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
> __________________________
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

On 2009-09-09 13:59+0200 Arjen Markus wrote:

> Hi Alan,
>
> I have been experimenting a bit with the test program I sent earlier
> to see how this works on Windows.

> #include "stdafx.h"
> #include "locale.h"

>    pstr = setlocale(LC_NUMERIC, "");

Hi Arjen:

Your continued testing on Windows has been most helpful.

Those are exactly the setlocale function arguments used by the general (not
just an example 1 option any more as of revision 10388) -locale command-line
option for PLplot. I am very pleased to hear that the setlocale function
exists on Windows and has the same arguments.  Is the #include "stdafx.h"
actually necessary? Please try a windows build of PLplot to see whether it
is necessary.  If so, the place to put #include <stdafx.h> it is right
before the

#include <locale.h>

in plplotP.h surrounded by preprocessor logic so #include <stdafx.h> does
not happen for non-windows platforms.

I am also pleased to hear that those setlocale arguments have an effect on
Windows (at least for output).  That means you should be able to see comma
separators for all axis labels and contour interval labels when you run
example 9 (just like I do when I use the nl_NL.utf8 locale). Can you confirm
that?

> ... I remembered suddenly that on Windows you can set the regional
> settings. That contained a period ... So setting that to a comma,
> I get:
>
> chklocale 1,3 Dutch_Netherlands.1252
> Number: 1,200000 -- Dutch_Netherlands.1252
> Read: 1,000000
> Read: 1,000000 -- (null)
>
> Note: the comma is apparently not recognised on input, it is used
> on output!

>From my perspective, the principal locale issues are (1) allowing PLplot
users to control the LC_NUMERIC locale used for PLplot via the -locale
command-line option rather than just leaving it up to external applications
and libraries and (2) protecting critical areas of PLplot against any locale
chosen via the -setlocale mechanism or external libraries. It looks like
both of these issues have now been dealt with for Linux and (from your
simple tests) Windows as well, although more testing is obviously required
on both platforms (and also OS X).

To my mind, the additional issue of recognizing the comma separator for our
floating-point options for the command line is not as important as the other
two issues.  The complete (as far as I can tell) list of such options is
-mar, -a, -jx, -jy, -ori, -bg, -wplt,-fsiz, and -dpi.  All of those use atof
to determine the floating-point values of the options. It does make sense
from the consistency point of view to support comma separators for these
options if you are specifying for plots generated by PLplot, but the result
is dependent on how scanf/atof is implemented for each different platform
version.  For Linux, my sense (from all the Linux locale reading I have been
doing the last few days, although I cannot now find a specific reference) is
support of the LC_NUMERIC locale for scanf/atof has been fairly recent.  You
may have a similar situation for Windows with earlier platforms not
supporting LC_NUMERIC locale for scanf/atof and later ones supporting it.

Anyhow, could you add your experience to the locale notes in README.release
(especially about the regional setting you had to change to get LC_NUMERIC
recognized on output for your particular Windows platform)? Once such
experience has been collected for all platforms, then I will put the result
in our wiki and also in our DocBook form of documentation.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Alan,

On 2009-09-09 21:23, Alan W. Irwin wrote:
> On 2009-09-09 13:59+0200 Arjen Markus wrote:
> 
>> Hi Alan,
>>
>> I have been experimenting a bit with the test program I sent earlier
>> to see how this works on Windows.
> 
>> #include "stdafx.h"
>> #include "locale.h"
> 
>>    pstr = setlocale(LC_NUMERIC, "");
> 
> Hi Arjen:
> 
> Your continued testing on Windows has been most helpful.
> 
> Those are exactly the setlocale function arguments used by the general (not
> just an example 1 option any more as of revision 10388) -locale 
> command-line
> option for PLplot. I am very pleased to hear that the setlocale function
> exists on Windows and has the same arguments.  Is the #include "stdafx.h"
> actually necessary? Please try a windows build of PLplot to see whether it
> is necessary.  If so, the place to put #include <stdafx.h> it is right
> before the

Sorry for the confusion: the line '#include "stdafx.h"' is a consequence
of Visual Studio creating a default source file for you, if you are not
careful. (I find it a nuisance, but then I never use the associated
functionality.)

> 
> #include <locale.h>
> 
> in plplotP.h surrounded by preprocessor logic so #include <stdafx.h> does
> not happen for non-windows platforms.
> 
> I am also pleased to hear that those setlocale arguments have an effect on
> Windows (at least for output).  That means you should be able to see comma
> separators for all axis labels and contour interval labels when you run
> example 9 (just like I do when I use the nl_NL.utf8 locale). Can you 
> confirm
> that?

I will try that. I may be able to do that tonight.

> 
>> ... I remembered suddenly that on Windows you can set the regional
>> settings. That contained a period ... So setting that to a comma,
>> I get:
>>
>> chklocale 1,3 Dutch_Netherlands.1252
>> Number: 1,200000 -- Dutch_Netherlands.1252
>> Read: 1,000000
>> Read: 1,000000 -- (null)
>>
>> Note: the comma is apparently not recognised on input, it is used
>> on output!
> 
>> From my perspective, the principal locale issues are (1) allowing PLplot
> users to control the LC_NUMERIC locale used for PLplot via the -locale
> command-line option rather than just leaving it up to external applications
> and libraries and (2) protecting critical areas of PLplot against any 
> locale
> chosen via the -setlocale mechanism or external libraries. It looks like
> both of these issues have now been dealt with for Linux and (from your
> simple tests) Windows as well, although more testing is obviously required
> on both platforms (and also OS X).
> 

I agree, the current implementation confines the effects of PLplot's
-locale to PLplot routines and that is what you really need. Locale
settings are messy enough as they are.

> To my mind, the additional issue of recognizing the comma separator for our
> floating-point options for the command line is not as important as the 
> other
> two issues.  The complete (as far as I can tell) list of such options is
> -mar, -a, -jx, -jy, -ori, -bg, -wplt,-fsiz, and -dpi.  All of those use 
> atof
> to determine the floating-point values of the options. It does make sense
> from the consistency point of view to support comma separators for these
> options if you are specifying for plots generated by PLplot, but the result
> is dependent on how scanf/atof is implemented for each different platform
> version.  For Linux, my sense (from all the Linux locale reading I have 
> been
> doing the last few days, although I cannot now find a specific 
> reference) is
> support of the LC_NUMERIC locale for scanf/atof has been fairly recent.  
> You
> may have a similar situation for Windows with earlier platforms not
> supporting LC_NUMERIC locale for scanf/atof and later ones supporting it.
> 

Hm, I used both MSVC 6.0 and MSVC 2008 (more or less the latest
release). MicroSoft have always been keen on localisation, so I am a
bit surprised that such basic functions as scanf() do not adhere to
the settings. The asymmetry actually causes problems, as you can not
write a file with comma separators and read it back again. But that
is a different discussion.

> Anyhow, could you add your experience to the locale notes in README.release
> (especially about the regional setting you had to change to get LC_NUMERIC
> recognized on output for your particular Windows platform)? Once such
> experience has been collected for all platforms, then I will put the result
> in our wiki and also in our DocBook form of documentation.
> 

Sure.

Regards,

Arjen

Hi Alan,

I have added my experiences so far to the Wiki 
(http://www.miscdebris.net/plplot_wiki/index.php?title=Using_PLplot#Localization).

I can now at least confirm that the regional settings as they are called
on Windows do work correctly as far as PLplot output is concerned:
"x09c -locale" gives axes with number like 0,1, whereas "x09c" gives
axes with periods in the labels.

I have not tested with Cygwin or MingW yet.

By the way: I have the same failure wrt example 19 (snprintf is not
defined) as David Aldrich.

Regards,

Arjen


On 2009-09-09 21:23, Alan W. Irwin wrote:

> Anyhow, could you add your experience to the locale notes in README.release
> (especially about the regional setting you had to change to get LC_NUMERIC
> recognized on output for your particular Windows platform)? Once such
> experience has been collected for all platforms, then I will put the result
> in our wiki and also in our DocBook form of documentation.
>

On 2009-09-11 08:54+0200 Arjen Markus wrote:

> By the way: I have the same failure wrt example 19 (snprintf is not
> defined) as David Aldrich.

Hi Arjen:

I have given this a new subject.  First, I would like to discuss
a possible technical solution for this issue, then the implications with
regard to our platform testing.

I. Possible technical solution

Since you have a fairly up-to-date Windows platform, I guess this means
snprintf is unequivocally not available on any "bare" Windows platform.
I don't know the situation for Cygwin and MinGW.

Hez, Andrew: is replacing snprintf with sprintf (just as in all other
examples) what should be done? Or would you like to do something more
general here like configuring plcdemos.h to take advantage of the CMake
variables, PL_HAVE_SNPRINTF and _PL_HAVE_SNPRINTF to implement essentially
the same solution as in plplotP.h?

II. Platform testing implications

I am afraid this result means at least the bare Windows platforms did not
get tested with ctest since August 5th, the last time example 19 was
changed.  That lack of testing during the last month before our release of
5.9.5 could have had pretty serious implications for that release, but I
believe we got off fairly lightly this time (assuming that once we
straighten out the issue, the rest of the examples do work on bare Windows).

The problem with attempting to deal with this Windows testing issue in
future is there are many bare Windows platforms as well as Cygwin and MinGW
(with and without MSYS) to test.  So our three active developers with access
to Windows are unlikely to have time, disk space, and Windows compiler
licenses to test all variations.

To help deal with this issue for all future releases let's do some specific
coordination of which developers will take firm responsibility for running
at least ctest on the Windows platforms that are accessible to them.  That
coordination will probably reveal some Windows platforms that won't be
tested, but it would be good to identify those.

In any case, I think we should formally ask for some testing help on the
plplot-general list a week before each release from now on for all platforms
but especially for the Windows platforms where we don't have good testing
coverage.  (A week should give us time to deal with most issues that come
up). From our download statistics and number of questions asked on
plplot-general there appears to be more and more interest in PLplot so
encouraging the new users to help out with testing on all our platforms
(especially for the many different Windows platforms where our developer
coverage is thin) makes a lot of sense.  If there is general consensus this
is a good idea, and Hazen is willing to send such an e-mail the week before
each release, I will put a reminder in README.Release_Manager_Cookbook.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On Fri, Sep 11, 2009 at 8:52 AM, Alan W. Irwin
<irwin@...> wrote:
> On 2009-09-11 08:54+0200 Arjen Markus wrote:
>
>> By the way: I have the same failure wrt example 19 (snprintf is not
>> defined) as David Aldrich.
>
> I. Possible technical solution
>
> Since you have a fairly up-to-date Windows platform, I guess this means
> snprintf is unequivocally not available on any "bare" Windows platform.
> I don't know the situation for Cygwin and MinGW.
>
> Hez, Andrew: is replacing snprintf with sprintf (just as in all other
> examples) what should be done? Or would you like to do something more
> general here like configuring plcdemos.h to take advantage of the CMake
> variables, PL_HAVE_SNPRINTF and _PL_HAVE_SNPRINTF to implement essentially
> the same solution as in plplotP.h?

I am ok with either solution.  My reason for using snprintf is that
part of example 19 is because the "length" argument provided to the
plslabelfunc callback is fixed at compile time and the string is
allocated and freed by PLplot itself rather than in the user's code.
Using sprintf on this fixed-length array leads to the possibility of
overruns.  This should not be an issue for example 19 as the labels
never approach the existing limit of 40 characters.

If snprintf is replaced with sprintf, would a comment in example 19
and a warning in the plslabelfunc documentation be enough to let users
know of this risk?  If there is a safer way to implement the
plslabelfunc callback which doesn't risk overruns in PLplot code then
that would be another possible fix.

< on to testing >
> In any case, I think we should formally ask for some testing help on the
> plplot-general list a week before each release from now on for all platforms
> but especially for the Windows platforms where we don't have good testing
> coverage.  (A week should give us time to deal with most issues that come
> up). From our download statistics and number of questions asked on
> plplot-general there appears to be more and more interest in PLplot so
> encouraging the new users to help out with testing on all our platforms
> (especially for the many different Windows platforms where our developer
> coverage is thin) makes a lot of sense.  If there is general consensus this
> is a good idea, and Hazen is willing to send such an e-mail the week before
> each release, I will put a reminder in README.Release_Manager_Cookbook.

This sounds like an excellent idea.

Hez

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

Hi Alan,

> I. Possible technical solution
>
> Since you have a fairly up-to-date Windows platform, I guess this  
> means
> snprintf is unequivocally not available on any "bare" Windows  
> platform.
> I don't know the situation for Cygwin and MinGW.
>
> Hez, Andrew: is replacing snprintf with sprintf (just as in all other
> examples) what should be done? Or would you like to do something more
> general here like configuring plcdemos.h to take advantage of the  
> CMake
> variables, PL_HAVE_SNPRINTF and _PL_HAVE_SNPRINTF to implement  
> essentially
> the same solution as in plplotP.h?

snprintf is available for MinGW/Cygwin. But not for Visual C++. The  
correct name is _snprintf which has something to do with C99 standard  
and very likely that Microsoft always had problems with standards.  
Whatever, plplot "knows" about that and I was about to get these  
macros through to the examples, but Andrew whistled me back, since the  
examples should not see private plplot macros, which is correct. So  
the most easy solution is to add something like

#ifdef MSVCVER
#define snprintf _snprintf
#endif

to solve the locally.
>
> II. Platform testing implications
>
> I am afraid this result means at least the bare Windows platforms  
> did not
> get tested with ctest since August 5th, the last time example 19 was
> changed.  That lack of testing during the last month before our  
> release of
> 5.9.5 could have had pretty serious implications for that release,  
> but I
> believe we got off fairly lightly this time (assuming that once we
> straighten out the issue, the rest of the examples do work on bare  
> Windows).
>
> The problem with attempting to deal with this Windows testing issue in
> future is there are many bare Windows platforms as well as Cygwin  
> and MinGW
> (with and without MSYS) to test.  So our three active developers  
> with access
> to Windows are unlikely to have time, disk space, and Windows compiler
> licenses to test all variations.
>
> To help deal with this issue for all future releases let's do some  
> specific
> coordination of which developers will take firm responsibility for  
> running
> at least ctest on the Windows platforms that are accessible to  
> them.  That
> coordination will probably reveal some Windows platforms that won't be
> tested, but it would be good to identify those.
>
> In any case, I think we should formally ask for some testing help on  
> the
> plplot-general list a week before each release from now on for all  
> platforms
> but especially for the Windows platforms where we don't have good  
> testing
> coverage.  (A week should give us time to deal with most issues that  
> come
> up). From our download statistics and number of questions asked on
> plplot-general there appears to be more and more interest in PLplot so
> encouraging the new users to help out with testing on all our  
> platforms
> (especially for the many different Windows platforms where our  
> developer
> coverage is thin) makes a lot of sense.  If there is general  
> consensus this
> is a good idea, and Hazen is willing to send such an e-mail the week  
> before
> each release, I will put a reminder in  
> README.Release_Manager_Cookbook.

Apart from asking users it would generally be good to have one  
responsible person for a certain combination of OS/compiler and maybe  
bindings. So we cover maybe not all combinations, but at least some  
and as you say, we also must cover at least all OS. Although I tested  
plplot with MinGW before the release and that worked.

Regards,
Werner

>
> 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); PLplot scientific plotting  
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
       +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

Alan W. Irwin wrote:
> 
> In any case, I think we should formally ask for some testing help on the
> plplot-general list a week before each release from now on for all platforms
> but especially for the Windows platforms where we don't have good testing
> coverage.  (A week should give us time to deal with most issues that come
> up). From our download statistics and number of questions asked on
> plplot-general there appears to be more and more interest in PLplot so
> encouraging the new users to help out with testing on all our platforms
> (especially for the many different Windows platforms where our developer
> coverage is thin) makes a lot of sense.  If there is general consensus this
> is a good idea, and Hazen is willing to send such an e-mail the week before
> each release, I will put a reminder in README.Release_Manager_Cookbook.

I'm willing to send such an e-mail.

-Hazen

On Fri, Sep 11, 2009 at 1:38 PM, Werner Smekal <smekal@...> wrote:
> snprintf is available for MinGW/Cygwin. But not for Visual C++. The
> correct name is _snprintf which has something to do with C99 standard
> and very likely that Microsoft always had problems with standards.
> Whatever, plplot "knows" about that and I was about to get these
> macros through to the examples, but Andrew whistled me back, since the
> examples should not see private plplot macros, which is correct. So
> the most easy solution is to add something like
>
> #ifdef MSVCVER
> #define snprintf _snprintf
> #endif
>
> to solve the locally.

Should this be added to plcdemos.h, or to x19c.c directly?  Does the C++
example 19 need this as well?

Hez

-- 
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

On 2009-09-13 13:12-0400 Hazen Babcock wrote:

> Alan W. Irwin wrote:
>> 
>> In any case, I think we should formally ask for some testing help on the
>> plplot-general list a week before each release from now on for all 
>> platforms
>> but especially for the Windows platforms where we don't have good testing
>> coverage.  (A week should give us time to deal with most issues that come
>> up). From our download statistics and number of questions asked on
>> plplot-general there appears to be more and more interest in PLplot so
>> encouraging the new users to help out with testing on all our platforms
>> (especially for the many different Windows platforms where our developer
>> coverage is thin) makes a lot of sense.  If there is general consensus this
>> is a good idea, and Hazen is willing to send such an e-mail the week before
>> each release, I will put a reminder in README.Release_Manager_Cookbook.
>
> I'm willing to send such an e-mail.

Thanks, Hazen.

I have thought some more about organizing our release testing, and what I
would like to do is make that a joint e-mail from me and you in our roles as
testing coordinator and release manager.  "Testing coordinator" is a role I
have taken fairly seriously in the past.  Although I have not been doing 
much of that recently, I plan to increase my activity in this role again to
avoid running into release problems like we just encountered with example
19.

What I plan to do as testing coordinator two weeks before each release is
contact everyone who is interested in helping out with testing, and ask them
their specific plans (i.e., what tests, what platforms).

Here is a preliminary list of the testing team I would contact and my
understanding of the platforms they have access to/would be willing to test.

Yours, truly:  Debian stable 64-bit
Andrew Ross:  Ubuntu 32-bit and 64-bit
Orion Poplawski: Fedora
Hazen Babcock: Mac OS X (PPC, 64bit?), Ubuntu, and Windows
Werner Smekal: Mac OS X (Intel 64bit?), MinGW/MSYS, Windows
Arjen Markus: Cygwin, Windows

where "Windows" means a bare Windows platforms with one of the proprietary
Windows compilers as opposed to Cygwin or MinGW (with or without MSYS).

I know I have undoubtedly got some details wrong in the list above because
this was all from memory of previous tests rather than looking up old
e-mails, and I have also probably missed some individuals lurking on this
list that would like to help out. Therefore, please respond off-list to me
by updating the above list to what you can actually test, and I will collate
all changes and put it in a README.testing_team file in the top-level of our
source tree.  That file will also serve as official recognition of the
important role members of the test team play in providing quality releases
for PLplot.

I also plan to ask those on the testing team to report to me slightly more
than a week before the release on exactly how much of that planned testing
they got done so I could collate those reports for Hazen's and my joint
e-mail to plplot-general that calls for pre-release testing. My hope is
those definite testing reports will inspire PLplot users to try out the svn
trunk version which, in turn, should help to find any issues that our
testing missed.

Assuming we complete fairly comprehensive testing just a week+ before the
release, that implies we should probably put an informal freeze on any
development activity other than bug fixing and documentation for the week
leading up to the release so that our good testing results continue to be
relevant for the release.

These testing plans also imply that members of the test team should
contribute strongly to the discussion of release dates so we don't end up
with a testing week that happens to be at an inconvenient/awkward time 
which would make it impossible for some member of the test team to
participate in the testing 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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-09-13 13:07-0500 Hezekiah M. Carty wrote:

> On Fri, Sep 11, 2009 at 1:38 PM, Werner Smekal <smekal@...> wrote:
>> snprintf is available for MinGW/Cygwin. But not for Visual C++. The
>> correct name is _snprintf which has something to do with C99 standard
>> and very likely that Microsoft always had problems with standards.
>> Whatever, plplot "knows" about that and I was about to get these
>> macros through to the examples, but Andrew whistled me back, since the
>> examples should not see private plplot macros, which is correct. So
>> the most easy solution is to add something like
>>
>> #ifdef MSVCVER
>> #define snprintf _snprintf
>> #endif
>>
>> to solve the locally.
>
> Should this be added to plcdemos.h, or to x19c.c directly?  Does the C++
> example 19 need this as well?

PlplotP.h has a better solution than above.

Therefore, I suggest following exactly what is done in plplotP.h for both
plcdemos.h and plc++demos.h.  That should allow the current C and C++
examples 19 to compile without issues on all platforms and also allows us to
replace all versions of sprintf with snprintf (which is good practice) for
all C and C++ examples.  Note, with this solution plcdemos.h and plc++demos.h
should be renamed to plcdemos.h.in and plc++demos.h.in (as configuration
template files to create plcdemos.h and plc++demos.h).

In the configuration template files, use

#cmakedefine PL_HAVE_SNPRINTF
and
#cmakedefine _PL_HAVE_SNPRINTF

Those will get configured to

#ifdef PL_HAVE_SNPRINTF
and
#ifdef _PL_HAVE_SNPRINTF

by cmake.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On 2009-09-13 13:27-0700 Alan W. Irwin wrote:

> Therefore, I suggest following exactly what is done in plplotP.h for both
> plcdemos.h and plc++demos.h.  That should allow the current C and C++
> examples 19 to compile without issues on all platforms and also allows us to
> replace all versions of sprintf with snprintf (which is good practice) for
> all C and C++ examples.  Note, with this solution plcdemos.h and plc++demos.h
> should be renamed to plcdemos.h.in and plc++demos.h.in (as configuration
> template files to create plcdemos.h and plc++demos.h).
>
> In the configuration template files, use
>
> #cmakedefine PL_HAVE_SNPRINTF
> and
> #cmakedefine _PL_HAVE_SNPRINTF
>
> Those will get configured to
>
> #ifdef PL_HAVE_SNPRINTF
> and
> #ifdef _PL_HAVE_SNPRINTF

I didn't state that last correctly.

That should read instead,

Those will get configured to

#define PL_HAVE_SNPRINTF
and
#define _PL_HAVE_SNPRINTF

if the corresponding CMake variables are true.  If the corresponding CMake
variables are false, than you get a configured line that is simply
a comment.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

Hi Werner,

On 2009-09-11 20:38, Werner Smekal wrote:
> 
> snprintf is available for MinGW/Cygwin. But not for Visual C++. The 
> correct name is _snprintf which has something to do with C99 standard 
> and very likely that Microsoft always had problems with standards. 
> Whatever, plplot "knows" about that and I was about to get these macros 
> through to the examples, but Andrew whistled me back, since the examples 
> should not see private plplot macros, which is correct. So the most easy 
> solution is to add something like
> 
> #ifdef MSVCVER
> #define snprintf _snprintf
> #endif
> 
> to solve the locally.

IIRC MicroSoft adopted this convention (leading underscore) to support 
common library functions that are not part of the official standard.
(ISTR the practice itself is mandated by the C standard, but I am no
expert in this field).

Why it is not included as snprintf() in the newer versions of the
compiler - as witnessed by David Aldrich - is a riddle I can not
answer.

Regards,

Arjen

Hi Alan,

I added these redefinition macros to plcdemos.h and plc++demos.h. But  
since we already use such a macro for isnan(), where PL__HAVE_ISNAN is  
defined in plConfig.h, I decided to do the same as well for _snprintf.  
So I copied the relevant part form config.h.cmake to plConfig.h.cmake  
and all works again for Visual C++. If this is not correct in your  
opinion, we should make changes as well for _isnan(). Actually, why do  
we have config.h and plConfig.h, where the latter seems to be a subset  
of the first?

Best Regards,
Werner

On Sep 13, 2009, at 11:09 PM, Alan W. Irwin wrote:

> On 2009-09-13 13:27-0700 Alan W. Irwin wrote:
>
>> Therefore, I suggest following exactly what is done in plplotP.h  
>> for both
>> plcdemos.h and plc++demos.h.  That should allow the current C and C++
>> examples 19 to compile without issues on all platforms and also  
>> allows us to
>> replace all versions of sprintf with snprintf (which is good  
>> practice) for
>> all C and C++ examples.  Note, with this solution plcdemos.h and plc 
>> ++demos.h
>> should be renamed to plcdemos.h.in and plc++demos.h.in (as  
>> configuration
>> template files to create plcdemos.h and plc++demos.h).
>>
>> In the configuration template files, use
>>
>> #cmakedefine PL_HAVE_SNPRINTF
>> and
>> #cmakedefine _PL_HAVE_SNPRINTF
>>
>> Those will get configured to
>>
>> #ifdef PL_HAVE_SNPRINTF
>> and
>> #ifdef _PL_HAVE_SNPRINTF
>
> I didn't state that last correctly.
>
> That should read instead,
>
> Those will get configured to
>
> #define PL_HAVE_SNPRINTF
> and
> #define _PL_HAVE_SNPRINTF
>
> if the corresponding CMake variables are true.  If the corresponding  
> CMake
> variables are false, than you get a configured line that is simply
> a comment.
>
> 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); PLplot scientific plotting  
> software
> package (plplot.org); 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
> __________________________
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: smekal@...
web:   http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
        +43-(0)1-58801-13469 (laboratory)
fax:   +43-(0)1-58801-13499

Hi Werner:

This is mostly directed to you, but there is also a quick question for Andrew
about the java bindings in my comments below.

On 2009-09-15 15:34+0200 Werner Smekal wrote:

> Hi Alan,
>
> I added these redefinition macros to plcdemos.h and plc++demos.h. But since 
> we already use such a macro for isnan(), where PL__HAVE_ISNAN is defined in 
> plConfig.h, I decided to do the same as well for _snprintf. So I copied the 
> relevant part form config.h.cmake to plConfig.h.cmake and all works again for 
> Visual C++.

I far prefer your idea (using configured macros for PL_HAVE_SNPRINTF and
_PL_HAVE_SNPRINTF in plConfig.h) to mine (configuring those same macros in
plcdemos.h and plc++demos.h).  I had forgotten that plConfig.h was already
#included by plcdemos.h and plc++demos.h.  Anyhow, like what you have done
subject to the duplicate macros issue (see below).

N.B. I hope you or somebody else will follow up and replace sprintf by
snprintf throughout the C and C++ examples (to demonstrate our good practice
for those examples and to inspire users to use snprintf as well for their
own PLplot applications).

> Actually, why do we have config.h and plConfig.h, where 
> the latter seems to be a subset of the first?

Before answering that important question I would like to give some
background for those here who are not aware of it.

The purpose of config.h is to contain all the configured macro dreck that is
required in the core build but which we don't want to expose for example
builds and user application builds.  The purpose of plConfig.h is to contain
the minimal set of configured macros that you do need to expose for example
builds and user application builds. The way the build system implements this
separation between the two sets of configured macros in config.h and
plConfig.h is via HAVE_CONFIG_H.  That is just #defined (see

ADD_DEFINITIONS("-DHAVE_CONFIG_H")

in the top-level CMakeLists.txt file) for the core build of PLplot, but
not for the build of the examples (see

remove_definitions("-DHAVE_CONFIG_H")

in examples/CMakeLists.txt (as of revision 10413).

As of revision 10412 I have documented the different purposes of
config.h.cmake and plConfig.h.cmake in those files, and because there is
obviously no need of duplicate macros (in answer to your question) I have
removed all such duplicates from config.h.cmake.

Revision 10413 gives me good results for a (rather) complete core build
(including build-tree examples) and separate installed examples build, but
others should test that revision 10413 as well to make sure that change to
no duplication between config.h and plConfig.h introduces no build errors
for their particular configuration/platform.

FOR Andrew: There is one other place in our build system
'remove_definitions("-DHAVE_CONFIG_H")' occurs and that is in
bindings/java/CMakeLIsts.txt.  I don't know the purpose of that or even
whether it is necessary.  Andrew, do you remember? Anyhow, for now I am
leaving it because it appears to work okay for the test mentioned above.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

On Tue, Sep 15, 2009 at 11:47:53AM -0700, Alan Irwin wrote:
> Hi Werner:
>
> This is mostly directed to you, but there is also a quick question for Andrew
> about the java bindings in my comments below.
>
> On 2009-09-15 15:34+0200 Werner Smekal wrote:
>
>> Hi Alan,
>>
>> I added these redefinition macros to plcdemos.h and plc++demos.h. But 
>> since we already use such a macro for isnan(), where PL__HAVE_ISNAN is 
>> defined in plConfig.h, I decided to do the same as well for _snprintf. 
>> So I copied the relevant part form config.h.cmake to plConfig.h.cmake 
>> and all works again for Visual C++.
>
> I far prefer your idea (using configured macros for PL_HAVE_SNPRINTF and
> _PL_HAVE_SNPRINTF in plConfig.h) to mine (configuring those same macros in
> plcdemos.h and plc++demos.h).  I had forgotten that plConfig.h was already
> #included by plcdemos.h and plc++demos.h.  Anyhow, like what you have done
> subject to the duplicate macros issue (see below).
>
> N.B. I hope you or somebody else will follow up and replace sprintf by
> snprintf throughout the C and C++ examples (to demonstrate our good practice
> for those examples and to inspire users to use snprintf as well for their
> own PLplot applications).
>
>> Actually, why do we have config.h and plConfig.h, where the latter 
>> seems to be a subset of the first?
>
> Before answering that important question I would like to give some
> background for those here who are not aware of it.
>
> The purpose of config.h is to contain all the configured macro dreck that is
> required in the core build but which we don't want to expose for example
> builds and user application builds.  The purpose of plConfig.h is to contain
> the minimal set of configured macros that you do need to expose for example
> builds and user application builds. The way the build system implements this
> separation between the two sets of configured macros in config.h and
> plConfig.h is via HAVE_CONFIG_H.  That is just #defined (see
>
> ADD_DEFINITIONS("-DHAVE_CONFIG_H")
>
> in the top-level CMakeLists.txt file) for the core build of PLplot, but
> not for the build of the examples (see
>
> remove_definitions("-DHAVE_CONFIG_H")
>
> in examples/CMakeLists.txt (as of revision 10413).
>
> As of revision 10412 I have documented the different purposes of
> config.h.cmake and plConfig.h.cmake in those files, and because there is
> obviously no need of duplicate macros (in answer to your question) I have
> removed all such duplicates from config.h.cmake.
>
> Revision 10413 gives me good results for a (rather) complete core build
> (including build-tree examples) and separate installed examples build, but
> others should test that revision 10413 as well to make sure that change to
> no duplication between config.h and plConfig.h introduces no build errors
> for their particular configuration/platform.
>
> FOR Andrew: There is one other place in our build system
> 'remove_definitions("-DHAVE_CONFIG_H")' occurs and that is in
> bindings/java/CMakeLIsts.txt.  I don't know the purpose of that or even
> whether it is necessary.  Andrew, do you remember? Anyhow, for now I am
> leaving it because it appears to work okay for the test mentioned above.

Firstly, sorry for the silence over the last few weeks. I have been away 
with work. I hoped to have email access but it didn't work out.

I don't recall. I think it was copied from somewhere else. It is possible
that config.h interferes with some of the C swig generated files, but it
seems unlikely. 

Andrew

On 2009-09-16 09:22+0100 Andrew Ross wrote:

>> There is one other place in our build system
>> 'remove_definitions("-DHAVE_CONFIG_H")' occurs and that is in
>> bindings/java/CMakeLIsts.txt.  I don't know the purpose of that or even
>> whether it is necessary.  Andrew, do you remember?

> I don't recall. I think it was copied from somewhere else. It is possible
> that config.h interferes with some of the C swig generated files, but it
> seems unlikely.

Hi Andrew:

It was good to hear from you again after your trip.

That question was generated by a grep for remove_definitions in all files of
our build tree.  I actually didn't take a look at the file itself until now.
It has some commentary about why that remove_definitions is needed.

# Java compiler doesn't support -D option.
remove_definitions("-DHAVE_CONFIG_H")

That appears to be a pretty straightforward explanation, but I noticed this
remove_definitions appears at the end of the file where it probably did not
have any effect at all.  So I tried dropping it, and on my gcj/gij platform
there were no issues.  Anyhow, I have experimentally committed that change
(revision 10417), but if it causes problems for any java platform we should
reinstate the above again (at the top of the file so it is obvious to humans
it has an effect).

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________