Re: [Plplot-devel] Qt driver update
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 __
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,00, -0,00, 0,00. 0,00, 0,00, 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
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,00, -0,00, 0,00. 0,00, 0,00, 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: sme...@iap.tuwien.ac.at 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt driver update
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 __
Re: [Plplot-devel] Qt driver update
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
Re: [Plplot-devel] Qt driver update
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 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt driver update
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 __ -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt driver update
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 __ -- 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 ___
Re: [Plplot-devel] Qt driver update
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 __ -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
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 ff I do get the specified white background to the GUI. However, I also get the error message QColor::setNamedColor: Unknown color name 'ff' 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 __ -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Qt driver update
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 qt_patch.gz Description: qt_patch.gz -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt driver update
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@lists.sourceforge.net 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
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 __ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
Re: [Plplot-devel] Qt driver update
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt driver update
Hi, Despite the remaining size and position issues, I encourage everyone here to try the qt devices on all platforms accessible to you. Also, to make this wider testing more convenient, I have decided to turn all qt devices ON by default (revision 9732). I eventually installed qt 4.5 on Windows and after a small change in pldll.h the driver compiled and worked (qt widget driver). Qt was actually easy to install, but it needs 1.2GB of my harddisk and I had only 2GB left ;). So I tested it only with the MinGW compiler and not with Visual C++ and won't do that, due to the free space issue. I wrote some notes about that into the wiki. 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 __ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net 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: sme...@iap.tuwien.ac.at 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 -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt driver update
Alan, Alan W. Irwin wrote: On 2009-03-12 13:47- Alban Rochel wrote: Hi Alban: I am answering you on the PLplot development list because I think others there will be interested in how you have improved qt so much. I have committed your work as revision 9729. Thanks I suspect you should just revert your text placement changes for svgqt. We have found previously that any Linux SVG viewer/converter having to do with GNOME (e.g., eog) or ImageMagick (convert or display) relies on the librsvg library which has some severe text placement bugs. I have put in several bug reports about this, but the official GNOME maintainer of that library seems proud of the fact that GNOME does not use SVG that much and that therefore librsvg does not have to be maintained (!) Hopefully, GNOME will eventually replace that guy with someone who is competent, but for now you have to be careful of anything that depends on librsvg. I recommend using konqueror for getting the best text-placement results for SVG files. Scribus-ng (but not Scribus) was good, and there were some other reliable apps as well whose names I have forgotten. Right now, konqueror shows some text placement issues with the svg results, but I bet those go away once your SVG correction is removed. Thanks for the info, but I use Inkscape for this, and I haven't found that it was based on librsvg. Actually, the problem is not a placement problem, it is that the bounding box returned by Qt is about 30% too wide (but seems to have the good height) when I write the text, and I rely on this bounding box to fit the element in the page. The problem could be me forgetting to do something with resolutions for example (however, the height would not be good). I'll try and see what happens on a minimal example. My fix is simply reducing this bounding box by an arbitrary factor, so when switching to subscript for example, there may be a slight offset. I am not sure how to advise you with regards to example 23. My first guess was you were being too specific with the desired font names, but I don't spot anything in your code that is too specific that way. For example, f.setFamily(sans-serif) seems to use quite generic name which is exactly what you want. More likely, there is some way to control font lookup within Qt, and you have to set something or configure something to make it look for all sans-serif possibilities rather than taking, e.g., the first one (which is likely not to have all the glyphs you need). There is a document on the font selection engine in the Qt documentation, I'll have a look at it. I confirmed all the other issues you mentioned. One other issue I noticed was the glyphs are roughly a factor of two too small. (I would adjust the qt character size to mimic what you get for xcairo.) Is this for every driver? For a specific example? I've just checked on example 01: when pls-chrht=3.59mm (I assumed this was mm, as it is returned by plgchr) - png: 11 pix, 72dpi - 3.89mm (not bad) - eps: 3.8mm (ditto) - svg: 2.71mm (ouch... Interesting however, the error factor is about the same as for my bounding box...) I looked at example 24, and (aside from the size issue) looks good with the CTL (Complex Text Layout) languages being rendered correctly. So that is a huge improvement which shows the great potential there is with qt-related devices. Thanks very much for your continuing efforts with the qt device driver. Alan Alban -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Qt driver update
On 2009-03-12 16:30- Alban Rochel wrote: Alan W. Irwin wrote: I am not sure how to advise you with regards to example 23. My first guess was you were being too specific with the desired font names, but I don't spot anything in your code that is too specific that way. For example, f.setFamily(sans-serif) seems to use quite generic name which is exactly what you want. More likely, there is some way to control font lookup within Qt, and you have to set something or configure something to make it look for all sans-serif possibilities rather than taking, e.g., the first one (which is likely not to have all the glyphs you need). There is a document on the font selection engine in the Qt documentation, I'll have a look at it. Hi Alban: I have solved the glyph selection issue with revision 9731. I found this solution by doing google searches of doc.trolltech.com. It is clear from the documentation there, e.g., http://doc.trolltech.com/4.5/qfont.html#details, that Qt searches primarily for generic font families (Times, Helvetica, Courier) rather than font categories (sans-serif, serif, monotype). Using font family names to actually specify font categories seems illogical to me, but that appears to be the way that Qt likes to do things. I then checked http://doc.trolltech.com/4.5/qfont.html#StyleHint-enum for the generic font family names corresponding to sans-serif, serif, and monotype. When I used those, all the glyph selection issues we had before disappeared! Examples 1 and 6 now have the correct symbols, all the math symbols in example 23 are there, and the CTL glyphs continue to be there with the correct complex text layout with example 24. Although there is still more to do with the unicode fonts (size and position issues that are discussed in another thread), I am really encouraged by the present results showing access to an enormous selection of glyphs rendered beautifully even for CTL languages. My thanks to Werner and you for doing the unicode implementation work for the qt device driver to make this possible. Despite the remaining size and position issues, I encourage everyone here to try the qt devices on all platforms accessible to you. Also, to make this wider testing more convenient, I have decided to turn all qt devices ON by default (revision 9732). 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 __ -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
