PLplot

Alan W. Irwin wrote:
> On 2009-05-08 23:19-0400 Hazen Babcock wrote:
> 
>> Alan W. Irwin wrote:
>>> On 2009-05-08 22:30-0400 Hazen Babcock wrote:
>>>
>>>> Is it expected that ctest --verbose in the build tree will end with the
>>>> following message?
>>>>
>>>> 91% tests passed, 2 tests failed out of 22
>>>>
>>>> The following tests FAILED:
>>>>      21 - examples_pdfqt (Timeout)
>>>>      22 - examples_compare (Failed)
>>>> Errors while running CTest
>>> No, that sounds like a problem.  Could you share the output from
>>>
>>> ctest --verbose -R pdfqt
>>>
>>> ?
>>>
>>> You should see a list of the examples that are completed before the timeout
>>> occurs.  You might also want to play with the --test-timeout ctest option
>>> (see ctest --help-full for details) in case the default timeout is too low
>>> to get all the way through the pdfqt examples on your computer.
>> How long would you expect each example to take? The tests seem to be going 
>> really slowly (many minutes per example) on my computer, which is a fairly 
>> recent vintage laptop. Core 2 Duo T9600 2.8 GHZ, 4GB RAM.
> 
> ~40 seconds or so on my 2.4GHz Core 2 duo (Linux raven 2.6.26-2-amd64 #1 SMP
> Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux) box for the complete
> 
> ctest --verbose -R pdfqt
> 
> command to finish.  So obviously something is really wrong on your system.
> Could you confirm all other ctests are reasonably speedy (less than a minute)?
> For example, what about
> 
> ctest --verbose -R epsqt
> 
> and
> 
> ctest --verbose -R pscairo
> 
> ?  Are all qt tests slow or just pdfqt?

It seems to be just pdfqt.

> Forget my idea of somehow having a very low default ctest timeout.  As
> far as I can tell that is 1500 seconds by default which should be fine for
> all our tests except for systems where there is something really wrong
> for some/all of the tests.
> 
> I am using the downloadable sdk (which contains Qt-4.5.1) you can get from
> TrollTech. Perhaps that is why my results are so speedy compared to
> yours.  What version of Qt4 do you have?  What Linux distro?  (Mine is
> Debian Lenny).


I have Ubuntu and Qt 4.4.3. I'll try installing Qt 4.5.1 and see what 
happens.

-Hazen

On 2009-05-09 16:23-0400 Hazen Babcock wrote:

> I have Ubuntu and Qt 4.4.3. I'll try installing Qt 4.5.1 and see what 
> happens.

What version of Ubuntu? Is your box 32-bit or 64 bit?  It is possible that
Andrew has the exact combination you have (once you state what it is) and
will be able to verify the problem in that case.

Once more information is accumulated (e.g., the results of your further
tests with Qt 4.5.1 and Andrew's verification or not of your Ubuntu
problems), we should say something about this issue (and also the Mac OS X
problem that Werner reported) in the release notes.

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:
> On 2009-05-08 23:19-0400 Hazen Babcock wrote:
> 
>> Alan W. Irwin wrote:
>>> On 2009-05-08 22:30-0400 Hazen Babcock wrote:
>>>
>>>> Is it expected that ctest --verbose in the build tree will end with the
>>>> following message?
>>>>
>>>> 91% tests passed, 2 tests failed out of 22
>>>>
>>>> The following tests FAILED:
>>>>      21 - examples_pdfqt (Timeout)
>>>>      22 - examples_compare (Failed)
>>>> Errors while running CTest
>>> No, that sounds like a problem.  Could you share the output from
>>>
>>> ctest --verbose -R pdfqt
>>>
>>> ?
>>>
>>> You should see a list of the examples that are completed before the timeout
>>> occurs.  You might also want to play with the --test-timeout ctest option
>>> (see ctest --help-full for details) in case the default timeout is too low
>>> to get all the way through the pdfqt examples on your computer.
>> How long would you expect each example to take? The tests seem to be going 
>> really slowly (many minutes per example) on my computer, which is a fairly 
>> recent vintage laptop. Core 2 Duo T9600 2.8 GHZ, 4GB RAM.
> 
> ~40 seconds or so on my 2.4GHz Core 2 duo (Linux raven 2.6.26-2-amd64 #1 SMP
> Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux) box for the complete
> 
> ctest --verbose -R pdfqt
> 
> command to finish.  So obviously something is really wrong on your system.
> Could you confirm all other ctests are reasonably speedy (less than a minute)?
> For example, what about
> 
> ctest --verbose -R epsqt
> 
> and
> 
> ctest --verbose -R pscairo
> 
> ?  Are all qt tests slow or just pdfqt?

It seems to be just pdfqt.

> Forget my idea of somehow having a very low default ctest timeout.  As
> far as I can tell that is 1500 seconds by default which should be fine for
> all our tests except for systems where there is something really wrong
> for some/all of the tests.
> 
> I am using the downloadable sdk (which contains Qt-4.5.1) you can get from
> TrollTech. Perhaps that is why my results are so speedy compared to
> yours.  What version of Qt4 do you have?  What Linux distro?  (Mine is
> Debian Lenny).


I have Ubuntu and Qt 4.4.3. I'll try installing Qt 4.5.1 and see what 
happens.

-Hazen

Alan W. Irwin wrote:
> On 2009-05-09 16:23-0400 Hazen Babcock wrote:
> 
>> I have Ubuntu and Qt 4.4.3. I'll try installing Qt 4.5.1 and see what 
>> happens.
> 
> What version of Ubuntu? Is your box 32-bit or 64 bit?  It is possible that
> Andrew has the exact combination you have (once you state what it is) and
> will be able to verify the problem in that case.

Ubuntu 8.10/intrepid, 64 bit.

-Hazen

Alan W. Irwin wrote:
> On 2009-05-09 16:23-0400 Hazen Babcock wrote:
> 
>> I have Ubuntu and Qt 4.4.3. I'll try installing Qt 4.5.1 and see what 
>> happens.
> 
> What version of Ubuntu? Is your box 32-bit or 64 bit?  It is possible that
> Andrew has the exact combination you have (once you state what it is) and
> will be able to verify the problem in that case.
> 
> Once more information is accumulated (e.g., the results of your further
> tests with Qt 4.5.1 and Andrew's verification or not of your Ubuntu
> problems), we should say something about this issue (and also the Mac OS X
> problem that Werner reported) in the release notes.

It looks like it is a problem with 4.4.3, pdfqt works fine with 4.5.1.

-Hazen

On 2009-05-09 20:23-0400 Hazen Babcock wrote:

> It looks like it is a problem with 4.4.3, pdfqt works fine with 4.5.1.

Thanks!

I have modified README.release (revision 9950) in light of this information
and the other Ubuntu/64-bit information Hazen gave, and the information
Werner reported earlier on the qtwidget black first page problem for Mac OS
X with Qt-4.5.1.

By the way, Alban, could you please review Werner's reports to see if you
can verify that Mac OS X issue with qtwidget?  Does qtwidget use of Qt4
on Mac OS X eventually boil down to a call to X or is there some other
underlying windows system it uses there?  (Out of curiousity, I have the
same question for the Windows platform.)  If on Mac OS X, qtwidget is not
X based it is possible that quite different code paths are being used
in Qt, and Werner has found a Qt4 bug.  Alternatively, we could have a qt
bug that doesn't matter for an X-based qtwidget but which makes a difference
when some other Windows system is underlying 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 Sat, May 09, 2009 at 07:43:13PM -0700, Alan Irwin wrote:
> On 2009-05-09 20:23-0400 Hazen Babcock wrote:
> 
> > It looks like it is a problem with 4.4.3, pdfqt works fine with 4.5.1.
> 
> Thanks!
> 
> I have modified README.release (revision 9950) in light of this information
> and the other Ubuntu/64-bit information Hazen gave, and the information
> Werner reported earlier on the qtwidget black first page problem for Mac OS
> X with Qt-4.5.1.
> 
> By the way, Alban, could you please review Werner's reports to see if you
> can verify that Mac OS X issue with qtwidget?  Does qtwidget use of Qt4
> on Mac OS X eventually boil down to a call to X or is there some other
> underlying windows system it uses there?  (Out of curiousity, I have the
> same question for the Windows platform.)  If on Mac OS X, qtwidget is not
> X based it is possible that quite different code paths are being used
> in Qt, and Werner has found a Qt4 bug.  Alternatively, we could have a qt
> bug that doesn't matter for an X-based qtwidget but which makes a difference
> when some other Windows system is underlying Qt4.

Ran out of disk space running ctest. Now requires the best part of 2Gb. 
Perhaps we should have a warning about this somewhere? 

Anyway, running just the pdfqt test takes an exceedingly long time and times 
out on the first example.

This is on Ubuntu Jaunty, 32-bit, with Qt-4.5.0.

Andrew

Hi Alan,

> By the way, Alban, could you please review Werner's reports to see if you
> can verify that Mac OS X issue with qtwidget?  Does qtwidget use of Qt4
> on Mac OS X eventually boil down to a call to X or is there some other
> underlying windows system it uses there?  (Out of curiousity, I have the
> same question for the Windows platform.)
Qt doesn't use X on Mac OS X - it uses native libraries (quartz, cacoa, 
carbon, whatever, I've never fully understood all the different 
libraries Mac OS X provides). On Windows it uses the API provided by 
Windows. So in the end it's three different code paths (wxWidgets btw. 
uses carbon, gtk and Windows API).


>   If on Mac OS X, qtwidget is not
> X based it is possible that quite different code paths are being used
> in Qt, and Werner has found a Qt4 bug.  Alternatively, we could have a qt
> bug that doesn't matter for an X-based qtwidget but which makes a difference
> when some other Windows system is underlying Qt4.
>   
One problem might be, that Mac OS X doesn't actually allow that programs 
use a GUI if they are not in an app-bundle, which is basically a 
directory with all the stuff in it which the program needs including the 
executable. That's the reason why the wxWidgets driver uses a hack to 
make the GUI working. I don't know how the Qt library solves that, since 
the GUI is responsible (which is otherwise not the case), but maybe it 
doesn't get refreshed at the right time. I don't know enough about Qt to 
be any help here, though.

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
> __________________________
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> 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

On 2009-05-10 12:34+0100 Andrew Ross wrote:

> Ran out of disk space running ctest. Now requires the best part of 2Gb.
> Perhaps we should have a warning about this somewhere?

The 2GB is already mentioned in passing in 
http://www.miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot, but if
you want to emphasize that more there, go ahead.

>
> Anyway, running just the pdfqt test takes an exceedingly long time and times
> out on the first example.
>
> This is on Ubuntu Jaunty, 32-bit, with Qt-4.5.0.

Hmm.  That is the first instance where this "slow pdfqt" problem showed up
for Qt-4.5.x. Do you want to try Qt-4.5.1?  That worked for Hazen.  Whatever
that outcome, please update README.release accordingly.

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:
> On 2009-05-09 20:23-0400 Hazen Babcock wrote:
>
>   
>> It looks like it is a problem with 4.4.3, pdfqt works fine with 4.5.1.
>>     
>
> Thanks!
>
> I have modified README.release (revision 9950) in light of this information
> and the other Ubuntu/64-bit information Hazen gave, and the information
> Werner reported earlier on the qtwidget black first page problem for Mac OS
> X with Qt-4.5.1.
>
> By the way, Alban, could you please review Werner's reports to see if you
> can verify that Mac OS X issue with qtwidget?  Does qtwidget use of Qt4
> on Mac OS X eventually boil down to a call to X or is there some other
> underlying windows system it uses there?  (Out of curiousity, I have the
> same question for the Windows platform.)  If on Mac OS X, qtwidget is not
> X based it is possible that quite different code paths are being used
> in Qt, and Werner has found a Qt4 bug.  Alternatively, we could have a qt
> bug that doesn't matter for an X-based qtwidget but which makes a difference
> when some other Windows system is underlying 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
> __________________________
>   

Hello all,

Actually, I don't have access to Macs, so I cannot test plplot on this
platform. My colleague, Tony Allen, has a Mac, I can ask him to perform
some tests, but I cannot guarantee that he will be able to do them
quickly as he currently has teaching duties as well as lots of things to
do on QSAS. I'm CC-ing this e-mail to him.

Alban

Alan W. Irwin wrote:
> On 2009-05-09 20:23-0400 Hazen Babcock wrote:
>   
>
> By the way, Alban, could you please review Werner's reports to see if you
> can verify that Mac OS X issue with qtwidget?  Does qtwidget use of Qt4
> on Mac OS X eventually boil down to a call to X or is there some other
> underlying windows system it uses there?  (Out of curiousity, I have the
> same question for the Windows platform.)  If on Mac OS X, qtwidget is not
> X based it is possible that quite different code paths are being used
> in Qt, and Werner has found a Qt4 bug.  Alternatively, we could have a qt
> bug that doesn't matter for an X-based qtwidget but which makes a difference
> when some other Windows system is underlying Qt4.
>
> Alan
>   
I've just tried on Tony's Mac (Qt 4.4.3), and what we observed was more
serious than what Werner reported: all the pages in the interactive
driver are blank. However, the funny thing is that when rescaling the
window, the grey margins I added to keep a constant aspect ratio in the
plot appear. So it *is* actually drawing things, but not the plots (or
it plots a black rectangle over the whole).

Werner, can you confirm that grey margins appear when you stretch the
window, even on the first pages? If so, I may change part of the Qt
driver to make it closer to the one we use in QSAS (which works). This
was my first aim when developing the plplot driver, but it evolved much
as we discussed, finally using simpler structures, making the program
clearer.

I cannot easily debug this issue as the only test machine for me is
Tony's laptop, and Tony cannot do the job as he doesn't know much of
this driver and already has plenty of things to do on QSAS.

Alban

Hi Alban,

On 11.05.2009, at 15:55, Alban Rochel wrote:

> Alan W. Irwin wrote:
>> On 2009-05-09 20:23-0400 Hazen Babcock wrote:
>>
>>
>> By the way, Alban, could you please review Werner's reports to see  
>> if you
>> can verify that Mac OS X issue with qtwidget?  Does qtwidget use of  
>> Qt4
>> on Mac OS X eventually boil down to a call to X or is there some  
>> other
>> underlying windows system it uses there?  (Out of curiousity, I  
>> have the
>> same question for the Windows platform.)  If on Mac OS X, qtwidget  
>> is not
>> X based it is possible that quite different code paths are being used
>> in Qt, and Werner has found a Qt4 bug.  Alternatively, we could  
>> have a qt
>> bug that doesn't matter for an X-based qtwidget but which makes a  
>> difference
>> when some other Windows system is underlying Qt4.
>>
>> Alan
>>
> I've just tried on Tony's Mac (Qt 4.4.3), and what we observed was  
> more
> serious than what Werner reported: all the pages in the interactive
> driver are blank.

Even for multi-page plots, like x08? The first is blank but the  
following show up.

> However, the funny thing is that when rescaling the
> window, the grey margins I added to keep a constant aspect ratio in  
> the
> plot appear. So it *is* actually drawing things, but not the plots (or
> it plots a black rectangle over the whole).
>
> Werner, can you confirm that grey margins appear when you stretch the
> window, even on the first pages?

Yes, the grey margins appear. Another strange thing if you run example  
x08: The first page is blank and the other pages show up. BUT if you  
press Enter twice fast or the right mouse button the following page  
shows up quickly and then again a blank screen.

> If so, I may change part of the Qt
> driver to make it closer to the one we use in QSAS (which works). This
> was my first aim when developing the plplot driver, but it evolved  
> much
> as we discussed, finally using simpler structures, making the program
> clearer.
>
> I cannot easily debug this issue as the only test machine for me is
> Tony's laptop, and Tony cannot do the job as he doesn't know much of
> this driver and already has plenty of things to do on QSAS.

You could send me patches which I could try to apply and test. Or you  
can even tell me what I should try to change to get results. I just  
have no time to read the qt documentation to find my way through the  
code and debug.

Regards,
Werner
>
> Alban
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
> Your
> production scanning environment may not be a perfect world - but  
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW  
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> 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 Smekal wrote:
> Hi Alban,
>
> On 11.05.2009, at 15:55, Alban Rochel wrote:
>
>   
>> Alan W. Irwin wrote:
>>     
>>>       
>> I've just tried on Tony's Mac (Qt 4.4.3), and what we observed was  
>> more
>> serious than what Werner reported: all the pages in the interactive
>> driver are blank.
>>     
>
> Even for multi-page plots, like x08? The first is blank but the  
> following show up.
>
>   
Yes.
>> However, the funny thing is that when rescaling the
>> window, the grey margins I added to keep a constant aspect ratio in  
>> the
>> plot appear. So it *is* actually drawing things, but not the plots (or
>> it plots a black rectangle over the whole).
>>
>> Werner, can you confirm that grey margins appear when you stretch the
>> window, even on the first pages?
>>     
>
> Yes, the grey margins appear. Another strange thing if you run example  
> x08: The first page is blank and the other pages show up. BUT if you  
> press Enter twice fast or the right mouse button the following page  
> shows up quickly and then again a blank screen.
>
>   
It looks like it superimposes the black rectangle used as background
*over* the plot.
>> If so, I may change part of the Qt
>> driver to make it closer to the one we use in QSAS (which works). This
>> was my first aim when developing the plplot driver, but it evolved  
>> much
>> as we discussed, finally using simpler structures, making the program
>> clearer.
>>
>> I cannot easily debug this issue as the only test machine for me is
>> Tony's laptop, and Tony cannot do the job as he doesn't know much of
>> this driver and already has plenty of things to do on QSAS.
>>     
>
> You could send me patches which I could try to apply and test. Or you  
> can even tell me what I should try to change to get results. I just  
> have no time to read the qt documentation to find my way through the  
> code and debug.
>
>   
Can you try this simple change, just to confirm the issue?:
Comment out lines 1380 to 1382 (painter->fillRect...). These lines draw
the background (margins and black background), removing them should
leave only the plots over whatever garbage is in graphic memory, which
could make the results hard to interpret.
> Regards,
> Werner
Alban

Hi Alban,

> Can you try this simple change, just to confirm the issue?:
> Comment out lines 1380 to 1382 (painter->fillRect...). These lines  
> draw
> the background (margins and black background), removing them should
> leave only the plots over whatever garbage is in graphic memory, which
> could make the results hard to interpret.

Now the background is always grey. So the first page is gray, no plot,  
for example 8 I get on the second page a plot on grey background, but  
the plots are nice, so the background gets cleared but in grey.

Regards,
Werner

>> Regards,
>> Werner
> Alban
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
> Your
> production scanning environment may not be a perfect world - but  
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW  
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> 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,

I kind of "fixed" it by adding after line 1487

1487:	widget->resize(plsc->xlength, plsc->ylength);
1488:	widget->clearWidget();

Don't know why? But now the pages show up. Still black page if I press  
return twice fast consecutively.

HTH,
Werner


On 11.05.2009, at 16:15, Alban Rochel wrote:

> Werner Smekal wrote:
>> Hi Alban,
>>
>> On 11.05.2009, at 15:55, Alban Rochel wrote:
>>
>>
>>> Alan W. Irwin wrote:
>>>
>>>>
>>> I've just tried on Tony's Mac (Qt 4.4.3), and what we observed was
>>> more
>>> serious than what Werner reported: all the pages in the interactive
>>> driver are blank.
>>>
>>
>> Even for multi-page plots, like x08? The first is blank but the
>> following show up.
>>
>>
> Yes.
>>> However, the funny thing is that when rescaling the
>>> window, the grey margins I added to keep a constant aspect ratio in
>>> the
>>> plot appear. So it *is* actually drawing things, but not the plots  
>>> (or
>>> it plots a black rectangle over the whole).
>>>
>>> Werner, can you confirm that grey margins appear when you stretch  
>>> the
>>> window, even on the first pages?
>>>
>>
>> Yes, the grey margins appear. Another strange thing if you run  
>> example
>> x08: The first page is blank and the other pages show up. BUT if you
>> press Enter twice fast or the right mouse button the following page
>> shows up quickly and then again a blank screen.
>>
>>
> It looks like it superimposes the black rectangle used as background
> *over* the plot.
>>> If so, I may change part of the Qt
>>> driver to make it closer to the one we use in QSAS (which works).  
>>> This
>>> was my first aim when developing the plplot driver, but it evolved
>>> much
>>> as we discussed, finally using simpler structures, making the  
>>> program
>>> clearer.
>>>
>>> I cannot easily debug this issue as the only test machine for me is
>>> Tony's laptop, and Tony cannot do the job as he doesn't know much of
>>> this driver and already has plenty of things to do on QSAS.
>>>
>>
>> You could send me patches which I could try to apply and test. Or you
>> can even tell me what I should try to change to get results. I just
>> have no time to read the qt documentation to find my way through the
>> code and debug.
>>
>>
> Can you try this simple change, just to confirm the issue?:
> Comment out lines 1380 to 1382 (painter->fillRect...). These lines  
> draw
> the background (margins and black background), removing them should
> leave only the plots over whatever garbage is in graphic memory, which
> could make the results hard to interpret.
>> Regards,
>> Werner
> Alban
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
> Your
> production scanning environment may not be a perfect world - but  
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW  
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> 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 Smekal wrote:
> Hi Alban,
>
> I kind of "fixed" it by adding after line 1487
>
> 1487:	widget->resize(plsc->xlength, plsc->ylength);
> 1488:	widget->clearWidget();
>
> Don't know why? But now the pages show up. Still black page if I press  
> return twice fast consecutively.
>
> HTH,
> Werner
>
>   
Hi Werner,

Thanks for the info. I may have a clue on what's the issue... I'll have
access to Tony's system for a small hour, I'll make a few tests.

Alban

Hi Werner,

I've been able to make some progress, I have identified the issue on
Tony's Mac, but my fix is not perfect yet. Can you just check that it
fixes your issues too?

It is not perfect as it can require the user to ask for a refresh (e.g.
resizing) to display the plots. But in the end, everything should be
displayed! If so, I will work on improving it, else I will revert this
part of the driver to the "QSAS way of plotting", which looks less clean
(use of custom buffer structure rather than Qt QPicture buffer), but
reliable.

Cheers,

Alban

Werner Smekal wrote:
> Hi Alban,
>
> I kind of "fixed" it by adding after line 1487
>
> 1487:	widget->resize(plsc->xlength, plsc->ylength);
> 1488:	widget->clearWidget();
>
> Don't know why? But now the pages show up. Still black page if I press  
> return twice fast consecutively.
>
> HTH,
> Werner
>
>
> On 11.05.2009, at 16:15, Alban Rochel wrote:
>
>

On Sun, May 10, 2009 at 08:54:53AM -0700, Alan Irwin wrote:
> On 2009-05-10 12:34+0100 Andrew Ross wrote:
> 
> > Anyway, running just the pdfqt test takes an exceedingly long time and times
> > out on the first example.
> >
> > This is on Ubuntu Jaunty, 32-bit, with Qt-4.5.0.
> 
> Hmm.  That is the first instance where this "slow pdfqt" problem showed up
> for Qt-4.5.x. Do you want to try Qt-4.5.1?  That worked for Hazen.  Whatever
> that outcome, please update README.release accordingly.

I don't remember encountering this before, so I wonder if it is one of 
the recent changes that has introduced this? 

Checked and the first two examples produce output before the timeout. 
Results look absolutely fine, but just taking 7-10 mins per page. Very
odd...

Andrew

On Mon, May 11, 2009 at 09:17:36PM +0100, Andrew Ross wrote:
> On Sun, May 10, 2009 at 08:54:53AM -0700, Alan Irwin wrote:
> > On 2009-05-10 12:34+0100 Andrew Ross wrote:
> > 
> > > Anyway, running just the pdfqt test takes an exceedingly long time and times
> > > out on the first example.
> > >
> > > This is on Ubuntu Jaunty, 32-bit, with Qt-4.5.0.
> > 
> > Hmm.  That is the first instance where this "slow pdfqt" problem showed up
> > for Qt-4.5.x. Do you want to try Qt-4.5.1?  That worked for Hazen.  Whatever
> > that outcome, please update README.release accordingly.
> 
> I don't remember encountering this before, so I wonder if it is one of 
> the recent changes that has introduced this? 
> 
> Checked and the first two examples produce output before the timeout. 
> Results look absolutely fine, but just taking 7-10 mins per page. Very
> odd...

I've tried and the same thing occurs with the epsqt driver. In both cases gdb 
shows that the example is hanging on a connect system call in the cups 
library. I'm now wondering if the problem is actually to do with cups
configuration in my case rather than qt? Perhaps others can confirm / deny 
this?

Andrew

On 2009-05-11 22:35+0100 Andrew Ross wrote:

> I've tried and the same thing occurs with the epsqt driver. In both cases gdb
> shows that the example is hanging on a connect system call in the cups
> library. I'm now wondering if the problem is actually to do with cups
> configuration in my case rather than qt? Perhaps others can confirm / deny
> this?

That's a really interesting speculation that makes a certain amount of sense
since there is a strong printing component to the EPS and PDF formats.
However, I am not sure this would be an issue for the downloadable Qt SDK.
For that case, they probably provide their own CUP libraries since the Linux
ones come in all sorts of versions/configurations which would be hard
for trolltech to anticipate.

Also, this may not be an issue for Debian.  When I first tried qt, I just
used the Qt-4.4.3 Debian packages, and as best I can remember I tried pdfqt
a couple of times without any noticeable pdfqt speed issues. OTOH, I may not
be remembering right, and in any case most of my pdfqt testing has been
after I moved to the downloadable Qt4 SDK you can get from trolltech.

Did you use a Ubuntu package for Qt-4.5.0 or the downloadable SDK (which is
now Qt-4.5.1, but it was 4.5.0 not that long ago).

If you haven't yet tried that downloadable SDK, I suggest you do so to
see if this (Qt4?/cups?) problem persists.

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,

On 11.05.2009, at 18:13, Alban Rochel wrote:

> Hi Werner,
>
> I've been able to make some progress, I have identified the issue on
> Tony's Mac, but my fix is not perfect yet. Can you just check that it
> fixes your issues too?
>
> It is not perfect as it can require the user to ask for a refresh  
> (e.g.
> resizing) to display the plots. But in the end, everything should be
> displayed! If so, I will work on improving it, else I will revert this
> part of the driver to the "QSAS way of plotting", which looks less  
> clean
> (use of custom buffer structure rather than Qt QPicture buffer), but
> reliable.

The screen is again black as you say, but after I resize the window,  
the plot is displayed. So it behaves as you describe.

Regards,
Werner

>
> Cheers,
>
> Alban
>
> Werner Smekal wrote:
>> Hi Alban,
>>
>> I kind of "fixed" it by adding after line 1487
>>
>> 1487:	widget->resize(plsc->xlength, plsc->ylength);
>> 1488:	widget->clearWidget();
>>
>> Don't know why? But now the pages show up. Still black page if I  
>> press
>> return twice fast consecutively.
>>
>> HTH,
>> Werner
>>
>>
>> On 11.05.2009, at 16:15, Alban Rochel wrote:
>>
>>
>
> < 
> qt_patch_mac 
> .gz 
> > 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
> Your
> production scanning environment may not be a perfect world - but  
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW  
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com_______________________________________________
> 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,

Thanks for testing, the result is good news. Unless you plan a quick 
release, I may take a little time before updating the driver (let's say 
by the end of next week).

By the way, I have not experience speed issues on the pdfqt and epsqt 
drivers, I use the stock Qt libraries of my distribution (Qt 4.4.3 on 
openSuSE 11.1 64). But CUPS communication issues could explain it, as 
pdf and eps files are generated through a QPrinter.

Alban

Werner Smekal wrote:
> Hi Alban,
> 
> On 11.05.2009, at 18:13, Alban Rochel wrote:
> 
>> Hi Werner,
>>
>> I've been able to make some progress, I have identified the issue on
>> Tony's Mac, but my fix is not perfect yet. Can you just check that it
>> fixes your issues too?
>>
>> It is not perfect as it can require the user to ask for a refresh  
>> (e.g.
>> resizing) to display the plots. But in the end, everything should be
>> displayed! If so, I will work on improving it, else I will revert this
>> part of the driver to the "QSAS way of plotting", which looks less  
>> clean
>> (use of custom buffer structure rather than Qt QPicture buffer), but
>> reliable.
> 
> The screen is again black as you say, but after I resize the window,  
> the plot is displayed. So it behaves as you describe.
> 
> Regards,
> Werner
> 
>> Cheers,
>>
>> Alban
>>
>> Werner Smekal wrote:
>>> Hi Alban,
>>>
>>> I kind of "fixed" it by adding after line 1487
>>>
>>> 1487:	widget->resize(plsc->xlength, plsc->ylength);
>>> 1488:	widget->clearWidget();
>>>
>>> Don't know why? But now the pages show up. Still black page if I  
>>> press
>>> return twice fast consecutively.
>>>
>>> HTH,
>>> Werner
>>>
>>>
>>> On 11.05.2009, at 16:15, Alban Rochel wrote:
>>>
>>>
>> < 
>> qt_patch_mac 
>> .gz 
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
>> Your
>> production scanning environment may not be a perfect world - but  
>> thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW  
>> KODAK i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com_______________________________________________
>> 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
>

On Mon, May 11, 2009 at 05:31:22PM -0700, Alan Irwin wrote:
> On 2009-05-11 22:35+0100 Andrew Ross wrote:
> 
> > I've tried and the same thing occurs with the epsqt driver. In both cases gdb
> > shows that the example is hanging on a connect system call in the cups
> > library. I'm now wondering if the problem is actually to do with cups
> > configuration in my case rather than qt? Perhaps others can confirm / deny
> > this?
> 
> That's a really interesting speculation that makes a certain amount of sense
> since there is a strong printing component to the EPS and PDF formats.
> However, I am not sure this would be an issue for the downloadable Qt SDK.
> For that case, they probably provide their own CUP libraries since the Linux
> ones come in all sorts of versions/configurations which would be hard
> for trolltech to anticipate.
> 
> Also, this may not be an issue for Debian.  When I first tried qt, I just
> used the Qt-4.4.3 Debian packages, and as best I can remember I tried pdfqt
> a couple of times without any noticeable pdfqt speed issues. OTOH, I may not
> be remembering right, and in any case most of my pdfqt testing has been
> after I moved to the downloadable Qt4 SDK you can get from trolltech.
> 
> Did you use a Ubuntu package for Qt-4.5.0 or the downloadable SDK (which is
> now Qt-4.5.1, but it was 4.5.0 not that long ago).
> 
> If you haven't yet tried that downloadable SDK, I suggest you do so to
> see if this (Qt4?/cups?) problem persists.

I've tried on another Ubuntu system. Same versions of all the software, 
but 64-bit. This system works fine with near instantaneous running of 
the examples. Printers and so forth are different between the two 
systems, so now I just need to work out exactly what differences are 
causing the problem. But anyway it doesn't look like an intrinsic 
problem with Qt libs. 

Andrew

On Tue, May 12, 2009 at 11:02:27AM +0100, Andrew Ross wrote:
> On Mon, May 11, 2009 at 05:31:22PM -0700, Alan Irwin wrote:
> > On 2009-05-11 22:35+0100 Andrew Ross wrote:
> > 
> > > I've tried and the same thing occurs with the epsqt driver. In both cases gdb
> > > shows that the example is hanging on a connect system call in the cups
> > > library. I'm now wondering if the problem is actually to do with cups
> > > configuration in my case rather than qt? Perhaps others can confirm / deny
> > > this?
> > 
> > That's a really interesting speculation that makes a certain amount of sense
> > since there is a strong printing component to the EPS and PDF formats.
> > However, I am not sure this would be an issue for the downloadable Qt SDK.
> > For that case, they probably provide their own CUP libraries since the Linux
> > ones come in all sorts of versions/configurations which would be hard
> > for trolltech to anticipate.
> > 
> > Also, this may not be an issue for Debian.  When I first tried qt, I just
> > used the Qt-4.4.3 Debian packages, and as best I can remember I tried pdfqt
> > a couple of times without any noticeable pdfqt speed issues. OTOH, I may not
> > be remembering right, and in any case most of my pdfqt testing has been
> > after I moved to the downloadable Qt4 SDK you can get from trolltech.
> > 
> > Did you use a Ubuntu package for Qt-4.5.0 or the downloadable SDK (which is
> > now Qt-4.5.1, but it was 4.5.0 not that long ago).
> > 
> > If you haven't yet tried that downloadable SDK, I suggest you do so to
> > see if this (Qt4?/cups?) problem persists.
> 
> I've tried on another Ubuntu system. Same versions of all the software, 
> but 64-bit. This system works fine with near instantaneous running of 
> the examples. Printers and so forth are different between the two 
> systems, so now I just need to work out exactly what differences are 
> causing the problem. But anyway it doesn't look like an intrinsic 
> problem with Qt libs. 

Right. Turns out the problem is cups related. I had a ipp remote printer 
configured on my laptop which wasn't actually present. Cups was trying to
get the configuration information from the printer and hanging. Qt in 
turn was waiting on this. Goodness knows why it wanted information
from a remote printer (not the default). Anyway, deleting the printer 
solves the problem. I don't find this a very satisfactory solution
since it is quite likely that mobile users will want to keep printers
configured but not necessarily always online.

For a related bug see https://bugs.launchpad.net/ubuntu/+source/cups/+bug/276531
Seems like at least on Ubuntu the cups packager says it is a library 
problem. I'm not convinced.

Anyway all working normally again.

Andrew