From: Hazen B. <hba...@ma...> - 2009-08-30 15:51:32
|
Alan W. Irwin wrote: > To Werner, Hazen, and Jerry: > > Without decent colour maps, PLplot is pretty useless so colour issues are > release critical by definition. Therefore, I hope all three of you with > access to OS X will give the current plspal1 issues on Mac OS X that were > discovered by Werner your immediate attention. > > Hazen and Jerry, do you confirm the issues Werner is seeing on Mac OS X? As > far as I know he has only tested for qt, but I assume this issue is device > independent. Could you make sure your experiments (with revision 10358, > see > below) include the following experiments I asked Werner to try? > > On 2009-08-28 10:29-0700 Alan W. Irwin wrote: > >> So to summarize the experiments I would like you to try, please see >> whether >> -dev psc also produces the example 16 warning messages and please see >> whether can you reproduce similar issues for example 10 using -cmap1. >> >> Once the new warning messages have identified exactly where in the >> code the >> problem is occurring, could you please try a gdb session (or printf's >> scattered around plspal1) to see exactly what is going wrong? I'm not exactly sure what tests you wanted, but I ran examples 10 and 16 using both the psc driver and the xwin driver and everything was as expected w/ no warning messages. I have a pretty old mac now. It is a PowerPC running OS-X 10.4.11. uname -a Darwin hazen-babcocks-imac-g5.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5370) -Hazen |
From: Alan W. I. <ir...@be...> - 2009-08-31 01:10:36
|
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 __________________________ |
From: Werner S. <sm...@ia...> - 2009-08-31 06:27:48
|
Hi Alan, weekend is family time, so no work from my side on this issue here. I just updated to the last plplot version and I get now little different warnings. >> >> No, colors changed, but I still get warnings, and the colors are >> also still >> wrong: >> >> *** PLPLOT WARNING *** >> Unrecognized cmap1 format 0.0 1.0 1.0 1.0 1.0 0 >> >> *** PLPLOT WARNING *** >> Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0 >> >> *** PLPLOT WARNING *** >> Unrecognized cmap1 format 0.0 0.0 0.0 0.0 1.0 0 *** PLPLOT WARNING *** Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0 1.0 1.0 1.0 1.0 0 *** PLPLOT WARNING *** Unrecognized cmap1 format (wrong number of items for version 2 of format) 0. 240. 0.5 1.0 1. 0 *** PLPLOT WARNING *** Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0 0.0 0.0 0.0 1.0 0 > > First, I cannot reproduce any of the difficulties/warning messages > you are > seeing. So finding the solution to this issue is going to require > some > more experimentation/debugging on your part. Sure, I'll try to debug that, but have limited time to do so. > > Second, please use revision 10355 (or later) for all further > investigation. > I just now made changes for that revision to output more information > in the > warning messages to make it easier to identify exactly which part of > the > code is generating the warning message. That explains the more verbose warning messages. > By the way, I am pretty sure (unless a device driver is really > screwed up) > that cmap1 palette reading troubles should be device independent. > Could you > confirm that by trying -dev psc for example 16? Nope, this warnings only occur with the qt devices. All other drivers I tried (wxwidgets, xwin, ps, pdf) worked as expected. > > The above warning message seem to be only related to the palette > files I > identified and cmap1_default.pal (used for page 4 of example 16) > doesn't > appear to be giving you any trouble. On the other hand, the (very) > strange > thing is example 16 also uses cmap1_gray.pal for the first page, and > you > didn't report any warning messages for that page. > > Could you please try some experiments with > > examples/c/x10c -cmap1 cmap1_*.pal -dev psc -o test.psc > > to see if you have any problems with the above palette files in that > case? Will do that now. > > Once the new warning messages have identified exactly where in the > code the > problem is occurring, could you please try a gdb session (or printf's > scattered around plspal1) to see exactly what is going wrong? > > I am sorry so much of the work tracking down this issue is on your > shoulders, but there is not much I can do here except make > suggestions for > experiments since I am getting perfect (valgrind-clean and heap-clean) > results here. My guess is there is something in the plspal1 code that > depends on some assumption that is only true on Linux, but I don't > know > what that could be. The problem must be somehow related to the qt driver (though as you, I can't imagine what the problem might be) and I try to debug it. Since I have not much experience with qt and also not much time, this might take a little. Regards, Werner > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting > software > package (plplot.org); the libLASi project (unifont.org/lasi); the > Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2009-08-31 17:35:35
|
Hi Werner: Most of this is directed to you but there is also a request for Hazen and Jerry at the end. On 2009-08-31 08:27+0200 Werner Smekal wrote: > Hi Alan, > > weekend is family time, so no work from my side on this issue here. Understood. We are all volunteers here with limited (and variable) spare time so we should all expect that responses to questions on this list are sometimes delayed. > I just > updated to the last plplot version and I get now little different warnings. > > *** PLPLOT WARNING *** > Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0 > 1.0 1.0 1.0 1.0 0 > > *** PLPLOT WARNING *** > Unrecognized cmap1 format (wrong number of items for version 2 of format) 0. > 240. 0.5 1.0 1. 0 > > *** PLPLOT WARNING *** > Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0 > 0.0 0.0 0.0 1.0 0 > >> By the way, I am pretty sure (unless a device driver is really screwed up) >> that cmap1 palette reading troubles should be device independent. Could you >> confirm that by trying -dev psc for example 16? > > Nope, this warnings only occur with the qt devices. All other drivers I tried > (wxwidgets, xwin, ps, pdf) worked as expected. That is a really strange result. The relevant code from plctrl.c (subject to line rewrap) is identified exactly by the unique error message above. fgets(color_info, 160, fp); if (sscanf(color_info, "%lf %lf %lf %lf %lf %d", &pos_d, &r_d, &g_d, &b_d, &a_d, &rev_i) != 6) { snprintf(msgbuf,1024, "Unrecognized cmap1 format (wrong number of items for version 2 of format) %s\n", color_info); So the above warning message outputs exactly the color_info which sscanf cannot interpret properly. But if we look at the data in that warning message above it is perfect; five floating point variables in a row, then an integer just like the above sscanf format directives and corresponding pointers. In particular, we already know there is no hidden null characters embedded in the middle of color_info because then that would affect the output of color_info in an obvious way (truncated early). It is hard to tell from e-mail, but I suppose there could be a line ending or other non-printing characters embedded in the middle of color_info. Just to be sure that is not the case, could you run example 16 again and capture the warning message directly into a file (using ">&" and not cut and paste to make this test as direct as possible), then analyze that file with something like od to see whether there are any non-printing characters in color_info? This is improbable (since color_info is read immediately before in the code with fgets above), but it would be good to have rock-solid confirmation that this improbability is not true. If you confirm the color_info output is perfect yet sscanf cannot read it, this is a second very strange result (after the very strange result that the problem only occurs for qt devices). The third very strange result is that the 3rd message above corresponds to cmap1_gray.pal which is read without issues for the first page of the same example 16! One hypothesis that might explain (more or less) all three strange results is that dynamic loading of qt devices is linking in a Qt4 library that breaks sscanf (or fgets if color_info turns out to have some embedded non-printing characters) on your system in some way. I know that hypothesis is quite speculative/improbable so if somebody here can come up with some more probable hypothesis to explain these strange results, please speak up. Werner: here are the next steps I would appreciate you doing to help figure this out. * Check color_info by directly capturing the above error message into a file and binary dump that file with something like the od application to make sure there are no non-printing characters embedded in the middle of color_info. (I have done that already with this e-mail, and the color_info output above was clean of embedded characters, but some of the applications used in the long e-mail chain between us could have filtered out those non-printing characters, and the right way to do this is by immediate file capture on the platform where the warning message is generated.) * Experiment with different Qt4 versions to see if the problem goes away for one of them. Hazen and Jerry: would you do similar experimentation (running example 16 with a number of different Qt4 versions) to see if you can replicate the issue that Werner found? To switch from one Qt4 version to another, simply put the appropriate qmake on your path before a fresh build and cmake does the rest. If by such experiments from Werner, Hazen, and Jerry we establish that the cmap1 palette file reading problems for example 16 occurs only for one Qt4 version on OS X but not others, then we only have to warn about that bad Qt4 version for OS X in the release notes, and we are (finally) done with this issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2009-09-03 19:48:28
|
I have assigned a new subject because this topic deserves its own thread. On 2009-09-01 11:24-0700 Alan W. Irwin wrote: > [...] Thus, I think our best solution to this whole issue is to save > the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then > restore the user locale in both cmap0_palette_read and plspal1. This method > absolutely guards against any locale issue (say for a different library than > qt) ever again screwing up palette file reading so this is what I like. > > What do you think of this idea? I have continued to think some more about LC_NUMERIC issues in PLplot, and to give some context to further discussion of this, have a look at http://en.wikipedia.org/wiki/File:DecimalSeparator.png. My own country of Canada has different decimal separators depending upon whether you are located in Quebec or otherwise, and a substantial fraction of the countries in the world use the comma for the separator rather than a period. The current status is our plots all correspond to setlocale(LC_NUMERIC, "C"); That is they use the period as the decimal separator on axis labels. This is probably consistent with the policy of many scientific publishers out there, but there are almost guaranteed to be some publishers that accept a decimal separator in plots that is whatever the author likes and even some that demand the comma separator regardless of the locale of the author. In addition, although we advertise PLplot as a scientific plotting library, it is also used in other contexts as well where there may be a need to follow the local locale with a comma decimal separator. Thus, for maximum PLplot usefulness, I think we should have a global variables local_locale set to 0 or 1 at user option so that plinit calls either setlocale(LC_NUMERIC, "C"); for local_locale = 0 or setlocale(LC_NUMERIC, ""); for local_locale = 1, where the first one should be the default, and the latter one gives complete flexibility since it obtains LC_NUMERIC from the environment (which can be set to anything by the user). Furthermore, this would fit in with my proposed solution to the above issue if we always setlocale(LC_NUMERIC, "C"); before reading palette files regardless of local_locale and restore to either of the above two choices depending on local_locale. Finally, in qt.cpp we should change back to the PLplot locale specified by local_locale just in case the Qt4 libraries change it. I hope to implement all of this later today or early tomorrow so please let me know quickly your comments on my proposal to deal with LC_NUMERIC issues in PLplot. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@de...> - 2009-09-04 06:59:50
|
Hi Alan, much as I appreciate the use of commas instead of periods (living in a country where commas are used - or should be - as the decimal separator), I do see a number of problems: - If a user sets the locale in his/her program before a call to plinit(), a default enforced by PLplot might cause a different behaviour than expected. - If PLplot sets the locale, does this have consequences for functions like fscanf()? I have never dug into the specifics, but it might all of a sudden read "1,2" as the number 1.2. The effect of introducing setlocale() in PLplot should, in my opinion, be limited entirely to calls to the PLplot library. Otherwise there could be all manner of trouble that is difficult to hunt down. Maybe I am pessimistic, but I have seen too many bizarre consequences from half-hearted implementations of locale settings. (Older versions of MS Excel made spreadsheets written in one locale unuseable in another locale, because "1.2" suddenly was a literal string instead of a number. Even more troublesome: current versions use function names that are specific to the human language the operating system is set to. At home I need to type SOM(A1:A10) instead of SUM(A1:A10), as the OS is set to Dutch.) Regards, Arjen On 2009-09-03 21:48, Alan W. Irwin wrote: > I have assigned a new subject because this topic deserves its own thread. > > On 2009-09-01 11:24-0700 Alan W. Irwin wrote: > >> [...] Thus, I think our best solution to this whole issue is to save >> the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then >> restore the user locale in both cmap0_palette_read and plspal1. This method >> absolutely guards against any locale issue (say for a different library than >> qt) ever again screwing up palette file reading so this is what I like. >> >> What do you think of this idea? > > I have continued to think some more about LC_NUMERIC issues in PLplot, and > to give some context to further discussion of this, have a look at > http://en.wikipedia.org/wiki/File:DecimalSeparator.png. My own country of > Canada has different decimal separators depending upon whether you are > located in Quebec or otherwise, and a substantial fraction of the countries > in the world use the comma for the separator rather than a period. > > The current status is our plots all correspond to > > setlocale(LC_NUMERIC, "C"); > > That is they use the period as the decimal separator on axis labels. This is > probably consistent with the policy of many scientific publishers out there, > but there are almost guaranteed to be some publishers that accept a decimal > separator in plots that is whatever the author likes and even some that > demand the comma separator regardless of the locale of the author. In > addition, although we advertise PLplot as a scientific plotting library, it > is also used in other contexts as well where there may be a need to follow > the local locale with a comma decimal separator. Thus, for maximum PLplot > usefulness, I think we should have a global variables local_locale set to 0 > or 1 at user option so that plinit calls either > > setlocale(LC_NUMERIC, "C"); > > for local_locale = 0 > > or > > setlocale(LC_NUMERIC, ""); > > for local_locale = 1, > > where the first one should be the default, and the latter one gives complete > flexibility since it obtains LC_NUMERIC from the environment (which can be > set to anything by the user). > > Furthermore, this would fit in with my proposed solution to the above issue > if we always setlocale(LC_NUMERIC, "C"); before reading palette files > regardless of local_locale and restore to either of the above two choices > depending on local_locale. Finally, in qt.cpp we should change back to the > PLplot locale specified by local_locale just in case the Qt4 libraries > change it. > > I hope to implement all of this later today or early tomorrow so please let > me know quickly your comments on my proposal to deal with LC_NUMERIC issues > in PLplot. > > Alan > __________________________ > > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2009-09-08 03:50:50
|
On 2009-09-06 18:36-0700 Alan W. Irwin wrote: > BTW, plsave_set_locale and plrestore_locale are the antithesis of functional > programming because they have no arguments and return nothing. That is, > they cause nothing but side effects. However, that is the name of the game > when dealing with POSIX locale issues. plsave_set_locale simply saves the > original locale string (set by external code such as x01c.c) in a global way > and sets locale to "C". plrestore_locale restores the original locale, and > frees the memory where the original global locale string was stored. > > I think this is the best way to implement this pair of functions because I > think we will always need them to communicate with each other between > different routines. (Note, the file open and close are in different routines > in ps.c if we want to block all locale changes when writing the output > PostScript file from ps.c as above.) However, my C skills are not as good as > I would like them to be so I would be interested in discussing changes in > the implementation of these two functions if someone has some better ideas. Well, practical experience with plsave_set_locale and plrestore_locale today showed me that these are always called from the same routine so I didn't need the global variable approach. Dropping that allowed me to change these to reentrant routines (which was required for some situations [i.e., the -debug option which recursively called these routines] in any case). I have now protected all PLplot core device driver calls with these routines (revision 10383), and the result is all devices appear to work fine for the -locale option for example 1. That is, LC_NUMERIC=nl_NL.utf8 examples/c/x01c -locale appears to give a comma decimal separator for axis labels for every device I have tried with no obvious valgrind or other issues. So this looks quite promising, and I plan to follow up by expanding the testing of this new PLplot feature to all devices and all examples to see if there are any limitations for this new feature. The test of locale for all examples will be made possible by replacing the limited example 1 -locale option by a general -locale option that executes setlocale(LC_NUMERIC, ""); to establish the basic PLplot locale and thus make PLplot generally portable to all LC_NUMERIC locales depending on how users set the LC_NUMERIC or LC_ALL environment variables. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jerry <lan...@qw...> - 2009-09-01 05:10:14
|
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 |
From: Alan W. I. <ir...@be...> - 2009-09-01 05:41:17
|
On 2009-08-31 22:09-0700 Jerry wrote: > > On Aug 29, 2009, at 10:30 AM, Alan W. Irwin wrote: > >> To Werner, Hazen, and Jerry: >> >> Without decent colour maps, PLplot is pretty useless so colour >> issues are >> release critical by definition. Therefore, I hope all three of you >> with >> access to OS X will give the current plspal1 issues on Mac OS X that >> were >> discovered by Werner your immediate attention. > > My working copy is in a state where it won't build because I'm working > on getting example 19 fixed. I could swap my copy out and look at > these color issues but I'd rather get 19 fixed first. It's looking now like this is a little less urgent since the problem seems confined (for some really strange reason that nobody seems to understand!) to just when qt devices are used on example 16 on OS X (and maybe only Werner's version of OS X?). So if you get a chance before the release to try out example 16 with a qt device and at least one Qt4 version (and hopefully more) that would be great, but I think you are right to give the Ada example 19 fix a higher priority. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2009-09-01 07:12:34
Attachments:
hex.png
|
Hi Alan, > > Just to be sure that is not the case, could you run example 16 again > and > capture the warning message directly into a file (using ">&" and not > cut and > paste to make this test as direct as possible), then analyze that > file with > something like od to see whether there are any non-printing > characters in > color_info? This is improbable (since color_info is read > immediately before > in the code with fgets above), but it would be good to have rock-solid > confirmation that this improbability is not true. I only see text, spaces and linefeeds, so it should be ok (see attached png). > > If you confirm the color_info output is perfect yet sscanf cannot > read it, > this is a second very strange result (after the very strange result > that the > problem only occurs for qt devices). > > The third very strange result is that the 3rd message above > corresponds to > cmap1_gray.pal which is read without issues for the first page of > the same > example 16! Yup, that also puzzles me :) > > One hypothesis that might explain (more or less) all three strange > results > is that dynamic loading of qt devices is linking in a Qt4 library that > breaks sscanf (or fgets if color_info turns out to have some embedded > non-printing characters) on your system in some way. I know that > hypothesis > is quite speculative/improbable so if somebody here can come up with > some > more probable hypothesis to explain these strange results, please > speak up. Just to make it more strange. Nokia actually provides two packages of Qt - cocoa and carbon, whil cocoa is the "new" API (use for Mac OS X 10.6). I actually have two Macs here (both latest 10.5.8 and xcode) and on one I installed the carbon binary package and on the other cocoa binary package (see http://qt.nokia.com/downloads/mac-os-cpp). While the Qt carbon leads to this strange cmap results, does Qt cocoa not print out this warnings - so the file qt devices work regarding the color. But qtwidget is messed up again, since the first plot appears (for multipage examples and after I click on the plot, before only grey window), but the following plots are not shown only the background color. I really have to say that Qt on Mac OS X is quite buggy as it seems. > > Werner: here are the next steps I would appreciate you doing to help > figure > this out. > > * Check color_info by directly capturing the above error message > into a file > and binary dump that file with something like the od application to > make > sure there are no non-printing characters embedded in the middle of > color_info. (I have done that already with this e-mail, and the > color_info > output above was clean of embedded characters, but some of the > applications > used in the long e-mail chain between us could have filtered out those > non-printing characters, and the right way to do this is by > immediate file > capture on the platform where the warning message is generated.) done, see picture. > > * Experiment with different Qt4 versions to see if the problem goes > away > for one of them. I even installed the latest Qt version 4.5.2 (cocoa and carbon) - see the results above. > > Hazen and Jerry: would you do similar experimentation (running > example 16 > with a number of different Qt4 versions) to see if you can replicate > the > issue that Werner found? To switch from one Qt4 version to another, > simply > put the appropriate qmake on your path before a fresh build and > cmake does > the rest. I used the binary packages, where a switch is not that easy. I just don't have the time to download the 450Mb source package and compile qt in different versions, which I assume will really take a long time, if this 450MB monster is uncompressed. > > If by such experiments from Werner, Hazen, and Jerry we establish > that the > cmap1 palette file reading problems for example 16 occurs only for > one Qt4 > version on OS X but not others, then we only have to warn about that > bad Qt4 > version for OS X in the release notes, and we are (finally) done > with this > issue. I'll now try to set a breakpoint in plctrl.c and see if I find something with gdb. Regarding the grey window/not shown plots I would like to give Alban direct access to my Mac(s), but I need to establish a ssh tunnel to this macs since they are behind a firewall. Let's see if I can do this, but since I have no experience here, this may need some time. Regards, Werner > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting > software > package (plplot.org); the libLASi project (unifont.org/lasi); the > Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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: sm...@ia... 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 |
From: Rochel, A. <a.r...@im...> - 2009-09-01 07:57:32
|
Werner, I have the "grey plot/refresh" issue on Windows, so it will be easier for me to fix this one. Alban |
From: Alan W. I. <ir...@be...> - 2009-09-01 16:47:47
|
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 __________________________ |
From: Rochel, A. <a.r...@im...> - 2009-09-01 07:34:55
|
Hi Werner, ________________________________________ De : Werner Smekal [sm...@ia...] Date d'envoi : mardi 1 septembre 2009 08:12 À : Alan W. Irwin Cc : Hazen Babcock; Jerry; Plplot-devel mailing list; Rochel, Alban Objet : Re: [Plplot-devel] Qt driver update I'll now try to set a breakpoint in plctrl.c and see if I find something with gdb. Regarding the grey window/not shown plots I would like to give Alban direct access to my Mac(s), but I need to establish a ssh tunnel to this macs since they are behind a firewall. Let's see if I can do this, but since I have no experience here, this may need some time. Regards, Werner > Having access to one of your Macs could help, indeed, thank you. However, for your "grey plot" issues, could you just try the following: - In bindings/qt_gui/plqt.cpp, change QtPLWidget::flush as follows (as I previously asked you to) void QtPLWidget::flush() { repaint(); QApplication::processEvents(); // add this } - In drivers/qt.cpp, change plD_eop_qtwidget as: void plD_eop_qtwidget(PLStream *pls) { QtPLWidget* widget=((QtPLWidget*)pls->dev); int currentPage=widget->pageNumber; widget->flush(); // add this while(currentPage==widget->pageNumber && handler.isMasterDevice(widget) && ! pls->nopause) { qApp->processEvents(QEventLoop::WaitForMoreEvents); } } As for the colour issues, I suspect we have the same kind of issue as we have with getenv() on Linux. Qt, as we use it, seems to mess up something in the system environment (and I have no idea what). I've not had getenv() issues with Qt 4.4. Is it possible for you to try this version of Qt? I am currently starting to work on Windows for Tuomas Seppala's issues. I have no experience on cmake on Windows, so I hope it won't take me too long. I'll be away (part of) this afternoon. To tell you everything, my wife and I are expecting a baby within 3 weeks, we have to go to the hospital this afternoon, and don't be surprised if I appear to be away unexpectedly some time in the next weeks. However, I'll try to work as much as possible on fixing the issues before the release. Alban |
From: Werner S. <sm...@ia...> - 2009-09-01 07:59:28
|
Hi Alban, > Having access to one of your Macs could help, indeed, thank you. > However, for your "grey plot" issues, could you just try the > following: > - In bindings/qt_gui/plqt.cpp, change QtPLWidget::flush as follows > (as I previously asked you to) > void QtPLWidget::flush() > { > repaint(); > QApplication::processEvents(); // add this > } This I already did and wrote an email to the list - this fixes example 17 but not the other examples. > > - In drivers/qt.cpp, change plD_eop_qtwidget as: > void plD_eop_qtwidget(PLStream *pls) > { > QtPLWidget* widget=((QtPLWidget*)pls->dev); > int currentPage=widget->pageNumber; > widget->flush(); // add this > while(currentPage==widget->pageNumber && > handler.isMasterDevice(widget) && ! pls->nopause) > { > qApp->processEvents(QEventLoop::WaitForMoreEvents); > } > } This solves the problems for the grey page. After you run a program the first plot will be shown (after a short while if there are multiplots). This is for the carbon qt binary, but I expect this to work also for the cocoa qt binary. The only thing left now (apart from this color crazyness) is that the window is in the background when you start it. Is it possible in Qt to bring the window into the foreground, since this is something the user would await? I'll commit these changes. > > As for the colour issues, I suspect we have the same kind of issue > as we have with getenv() on Linux. Qt, as we use it, seems to mess > up something in the system environment (and I have no idea what). > I've not had getenv() issues with Qt 4.4. Is it possible for you to > try this version of Qt? It must be something like that since the cocoa library of the same qt version doesn't have these problems. That's really strange that Qt somehow overloads the stdlib functions with buggy functions. > > I am currently starting to work on Windows for Tuomas Seppala's > issues. I have no experience on cmake on Windows, so I hope it won't > take me too long. I'll be away (part of) this afternoon. To tell you > everything, my wife and I are expecting a baby within 3 weeks, we > have to go to the hospital this afternoon, and don't be surprised if > I appear to be away unexpectedly some time in the next weeks. > However, I'll try to work as much as possible on fixing the issues > before the release. It's actually not much a problem, maybe the wiki helps you a bit: http://www.miscdebris.net/plplot_wiki/index.php?title=Qt Congratulations to you and your wife about the upcoming birth! I wish you all the best and I'm sure it will be a great time for all of you. Regards, Werner > > Alban -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Rochel, A. <a.r...@im...> - 2009-09-01 08:07:50
|
Werner, Good news for the flush() issue. It works on Windows too (I just had forgotten to save the changes I told you to do). To bring the window to front, try to add widget->raise() after widget->flush() in plD_eop_qtwidget. Alban ________________________________________ De : Werner Smekal [sm...@ia...] Date d'envoi : mardi 1 septembre 2009 08:58 À : Rochel, Alban Cc : Alan W. Irwin; Hazen Babcock; Jerry; Plplot-devel mailing list Objet : Re: RE : [Plplot-devel] Qt driver update This solves the problems for the grey page. After you run a program the first plot will be shown (after a short while if there are multiplots). This is for the carbon qt binary, but I expect this to work also for the cocoa qt binary. The only thing left now (apart from this color crazyness) is that the window is in the background when you start it. Is it possible in Qt to bring the window into the foreground, since this is something the user would await? I'll commit these changes. > > As for the colour issues, I suspect we have the same kind of issue > as we have with getenv() on Linux. Qt, as we use it, seems to mess > up something in the system environment (and I have no idea what). > I've not had getenv() issues with Qt 4.4. Is it possible for you to > try this version of Qt? It must be something like that since the cocoa library of the same qt version doesn't have these problems. That's really strange that Qt somehow overloads the stdlib functions with buggy functions. > > I am currently starting to work on Windows for Tuomas Seppala's > issues. I have no experience on cmake on Windows, so I hope it won't > take me too long. I'll be away (part of) this afternoon. To tell you > everything, my wife and I are expecting a baby within 3 weeks, we > have to go to the hospital this afternoon, and don't be surprised if > I appear to be away unexpectedly some time in the next weeks. > However, I'll try to work as much as possible on fixing the issues > before the release. It's actually not much a problem, maybe the wiki helps you a bit: http://www.miscdebris.net/plplot_wiki/index.php?title=Qt Congratulations to you and your wife about the upcoming birth! I wish you all the best and I'm sure it will be a great time for all of you. Regards, Werner > > Alban -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Werner S. <sm...@ia...> - 2009-09-01 08:14:54
|
Hi Alban, this works as well. Very good, so apart from this color issue, the qt drivers on Mac work quite well. I'll commit this as well. Please test on Linux if these changes did mess something up. Thanks, Werner On 01.09.2009, at 10:03, Rochel, Alban wrote: > Werner, > > Good news for the flush() issue. It works on Windows too (I just had > forgotten to save the changes I told you to do). To bring the window > to front, try to add widget->raise() after widget->flush() in > plD_eop_qtwidget. > > Alban > ________________________________________ > De : Werner Smekal [sm...@ia...] > Date d'envoi : mardi 1 septembre 2009 08:58 > À : Rochel, Alban > Cc : Alan W. Irwin; Hazen Babcock; Jerry; Plplot-devel mailing list > Objet : Re: RE : [Plplot-devel] Qt driver update > > This solves the problems for the grey page. After you run a program > the first plot will be shown (after a short while if there are > multiplots). This is for the carbon qt binary, but I expect this to > work also for the cocoa qt binary. The only thing left now (apart from > this color crazyness) is that the window is in the background when you > start it. Is it possible in Qt to bring the window into the > foreground, since this is something the user would await? I'll commit > these changes. >> >> As for the colour issues, I suspect we have the same kind of issue >> as we have with getenv() on Linux. Qt, as we use it, seems to mess >> up something in the system environment (and I have no idea what). >> I've not had getenv() issues with Qt 4.4. Is it possible for you to >> try this version of Qt? > > It must be something like that since the cocoa library of the same qt > version doesn't have these problems. That's really strange that Qt > somehow overloads the stdlib functions with buggy functions. >> >> I am currently starting to work on Windows for Tuomas Seppala's >> issues. I have no experience on cmake on Windows, so I hope it won't >> take me too long. I'll be away (part of) this afternoon. To tell you >> everything, my wife and I are expecting a baby within 3 weeks, we >> have to go to the hospital this afternoon, and don't be surprised if >> I appear to be away unexpectedly some time in the next weeks. >> However, I'll try to work as much as possible on fixing the issues >> before the release. > > It's actually not much a problem, maybe the wiki helps you a bit: http://www.miscdebris.net/plplot_wiki/index.php?title=Qt > > Congratulations to you and your wife about the upcoming birth! I wish > you all the best and I'm sure it will be a great time for all of you. > > Regards, > Werner > >> >> Alban > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > > email: sm...@ia... > 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 > Plp...@li... > 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: sm...@ia... 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 |
From: Werner S. <sm...@ia...> - 2009-09-01 08:33:31
|
Hi Alan, > > That is a really strange result. > > The relevant code from plctrl.c (subject to line rewrap) is identified > exactly by the unique error message above. > > fgets(color_info, 160, fp); > if (sscanf(color_info, "%lf %lf %lf %lf %lf %d", > &pos_d, &r_d, &g_d, &b_d, &a_d, &rev_i) != 6) { > snprintf(msgbuf,1024, > "Unrecognized cmap1 format (wrong number of items for version 2 of > format) %s\n", > color_info); > > So the above warning message outputs exactly the color_info which > sscanf > cannot interpret properly. But if we look at the data in that warning > message above it is perfect; five floating point variables in a row, > then an > integer just like the above sscanf format directives and corresponding > pointers. In particular, we already know there is no hidden null > characters > embedded in the middle of color_info because then that would affect > the > output of color_info in an obvious way (truncated early). It is > hard to > tell from e-mail, but I suppose there could be a line ending or other > non-printing characters embedded in the middle of color_info. I think I found out what the problem is. The first page reads okay, but then qt takes over to show the plot and somehow changes the locale or something. This is on a Mac, English version, but Austrian locale - so after that scanf expects floating point numbers to be written numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I assume that this is the problem, since I printed the out the numbers with printf in case sscanf fails and the output is: 0: 0.0 0.0 0.0 0.0 1.0 0 1: 1.0 1.0 1.0 1.0 1.0 0 0: 0.0 1.0 1.0 1.0 1.0 0 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440 *** PLPLOT WARNING *** Unrecognized cmap1 format (wrong number of items (1) for version 2 of format) 0.0 1.0 1.0 1.0 1.0 0 I'll try now to play around with my locale. The other Mac has also Austrian locale, but obviously Qt cocoa doesn't mess around here. I'll keep you informed. Regards, Werner > > Just to be sure that is not the case, could you run example 16 again > and > capture the warning message directly into a file (using ">&" and not > cut and > paste to make this test as direct as possible), then analyze that > file with > something like od to see whether there are any non-printing > characters in > color_info? This is improbable (since color_info is read > immediately before > in the code with fgets above), but it would be good to have rock-solid > confirmation that this improbability is not true. > > If you confirm the color_info output is perfect yet sscanf cannot > read it, > this is a second very strange result (after the very strange result > that the > problem only occurs for qt devices). > > The third very strange result is that the 3rd message above > corresponds to > cmap1_gray.pal which is read without issues for the first page of > the same > example 16! > > One hypothesis that might explain (more or less) all three strange > results > is that dynamic loading of qt devices is linking in a Qt4 library that > breaks sscanf (or fgets if color_info turns out to have some embedded > non-printing characters) on your system in some way. I know that > hypothesis > is quite speculative/improbable so if somebody here can come up with > some > more probable hypothesis to explain these strange results, please > speak up. > > Werner: here are the next steps I would appreciate you doing to help > figure > this out. > > * Check color_info by directly capturing the above error message > into a file > and binary dump that file with something like the od application to > make > sure there are no non-printing characters embedded in the middle of > color_info. (I have done that already with this e-mail, and the > color_info > output above was clean of embedded characters, but some of the > applications > used in the long e-mail chain between us could have filtered out those > non-printing characters, and the right way to do this is by > immediate file > capture on the platform where the warning message is generated.) > > * Experiment with different Qt4 versions to see if the problem goes > away > for one of them. > > Hazen and Jerry: would you do similar experimentation (running > example 16 > with a number of different Qt4 versions) to see if you can replicate > the > issue that Werner found? To switch from one Qt4 version to another, > simply > put the appropriate qmake on your path before a fresh build and > cmake does > the rest. > > If by such experiments from Werner, Hazen, and Jerry we establish > that the > cmap1 palette file reading problems for example 16 occurs only for > one Qt4 > version on OS X but not others, then we only have to warn about that > bad Qt4 > version for OS X in the release notes, and we are (finally) done > with this > issue. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting > software > package (plplot.org); the libLASi project (unifont.org/lasi); the > Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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: sm...@ia... 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 |
From: Rochel, A. <a.r...@im...> - 2009-09-01 08:42:20
|
Werner, Could you try editing qt.cpp (line 99): bool initQtApp(bool isGUI) { QMutexLocker locker(&QtPLDriver::mutex); bool res=false; ++appCounter; if(qApp==NULL && appCounter==1) { argc=1; argv=new char*[2]; argv[0]=new char[10]; argv[1]=new char[1]; snprintf(argv[0], 10, "qt_driver"); argv[1][0]='\0'; new QApplication(argc, argv, isGUI); QLocale::setDefault(QLocale::c()); // add this res=true; } return res; } I'm surprised that Qt affects the system configuration that way, but I hope that forcing it to use the "universal" C locale will help ensure we won't get these kinds of issues any more. Alban ________________________________________ De : plp...@li... [plp...@li...] de la part de Werner Smekal [sm...@ia...] Date d'envoi : mardi 1 septembre 2009 09:28 À : Alan W. Irwin Cc : Plplot-devel mailing list; Hazen Babcock Objet : Re: [Plplot-devel] Qt driver update Hi Alan, > > That is a really strange result. > > The relevant code from plctrl.c (subject to line rewrap) is identified > exactly by the unique error message above. > > fgets(color_info, 160, fp); > if (sscanf(color_info, "%lf %lf %lf %lf %lf %d", > &pos_d, &r_d, &g_d, &b_d, &a_d, &rev_i) != 6) { > snprintf(msgbuf,1024, > "Unrecognized cmap1 format (wrong number of items for version 2 of > format) %s\n", > color_info); > > So the above warning message outputs exactly the color_info which > sscanf > cannot interpret properly. But if we look at the data in that warning > message above it is perfect; five floating point variables in a row, > then an > integer just like the above sscanf format directives and corresponding > pointers. In particular, we already know there is no hidden null > characters > embedded in the middle of color_info because then that would affect > the > output of color_info in an obvious way (truncated early). It is > hard to > tell from e-mail, but I suppose there could be a line ending or other > non-printing characters embedded in the middle of color_info. I think I found out what the problem is. The first page reads okay, but then qt takes over to show the plot and somehow changes the locale or something. This is on a Mac, English version, but Austrian locale - so after that scanf expects floating point numbers to be written numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I assume that this is the problem, since I printed the out the numbers with printf in case sscanf fails and the output is: 0: 0.0 0.0 0.0 0.0 1.0 0 1: 1.0 1.0 1.0 1.0 1.0 0 0: 0.0 1.0 1.0 1.0 1.0 0 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440 *** PLPLOT WARNING *** Unrecognized cmap1 format (wrong number of items (1) for version 2 of format) 0.0 1.0 1.0 1.0 1.0 0 I'll try now to play around with my locale. The other Mac has also Austrian locale, but obviously Qt cocoa doesn't mess around here. I'll keep you informed. Regards, Werner > > Just to be sure that is not the case, could you run example 16 again > and > capture the warning message directly into a file (using ">&" and not > cut and > paste to make this test as direct as possible), then analyze that > file with > something like od to see whether there are any non-printing > characters in > color_info? This is improbable (since color_info is read > immediately before > in the code with fgets above), but it would be good to have rock-solid > confirmation that this improbability is not true. > > If you confirm the color_info output is perfect yet sscanf cannot > read it, > this is a second very strange result (after the very strange result > that the > problem only occurs for qt devices). > > The third very strange result is that the 3rd message above > corresponds to > cmap1_gray.pal which is read without issues for the first page of > the same > example 16! > > One hypothesis that might explain (more or less) all three strange > results > is that dynamic loading of qt devices is linking in a Qt4 library that > breaks sscanf (or fgets if color_info turns out to have some embedded > non-printing characters) on your system in some way. I know that > hypothesis > is quite speculative/improbable so if somebody here can come up with > some > more probable hypothesis to explain these strange results, please > speak up. > > Werner: here are the next steps I would appreciate you doing to help > figure > this out. > > * Check color_info by directly capturing the above error message > into a file > and binary dump that file with something like the od application to > make > sure there are no non-printing characters embedded in the middle of > color_info. (I have done that already with this e-mail, and the > color_info > output above was clean of embedded characters, but some of the > applications > used in the long e-mail chain between us could have filtered out those > non-printing characters, and the right way to do this is by > immediate file > capture on the platform where the warning message is generated.) > > * Experiment with different Qt4 versions to see if the problem goes > away > for one of them. > > Hazen and Jerry: would you do similar experimentation (running > example 16 > with a number of different Qt4 versions) to see if you can replicate > the > issue that Werner found? To switch from one Qt4 version to another, > simply > put the appropriate qmake on your path before a fresh build and > cmake does > the rest. > > If by such experiments from Werner, Hazen, and Jerry we establish > that the > cmap1 palette file reading problems for example 16 occurs only for > one Qt4 > version on OS X but not others, then we only have to warn about that > bad Qt4 > version for OS X in the release notes, and we are (finally) done > with this > issue. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting > software > package (plplot.org); the libLASi project (unifont.org/lasi); the > Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > 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: sm...@ia... 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 Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Werner S. <sm...@ia...> - 2009-09-01 08:47:32
|
Hi, > I think I found out what the problem is. The first page reads okay, > but then qt takes over to show the plot and somehow changes the locale > or something. This is on a Mac, English version, but Austrian locale - > so after that scanf expects floating point numbers to be written > numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I > assume that this is the problem, since I printed the out the numbers > with printf in case sscanf fails and the output is: > > 0: 0.0 0.0 0.0 0.0 1.0 0 > 1: 1.0 1.0 1.0 1.0 1.0 0 > 0: 0.0 1.0 1.0 1.0 1.0 0 > 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440 > > *** PLPLOT WARNING *** > Unrecognized cmap1 format (wrong number of items (1) for version 2 of > format) 0.0 1.0 1.0 1.0 1.0 0 > > I'll try now to play around with my locale. The other Mac has also > Austrian locale, but obviously Qt cocoa doesn't mess around here. Ok, this is the problem. Qt carbon changes the locale and sscanf doesn't work as expected any more. If I add setlocale(LC_NUMERIC, "C"); just before the sscanf call, everything works as expected. This is obviously not the correct solution but at least we know what is going wrong. Also if I change my locale to UK the example works as expected. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Rochel, A. <a.r...@im...> - 2009-09-01 08:54:32
|
Oops, I forgot: add "#include <QLocale>" somewhere at the top (e.g. below #include <QMutexLocker>) ________________________________________ De : plp...@li... [plp...@li...] de la part de Werner Smekal [sm...@ia...] Date d'envoi : mardi 1 septembre 2009 09:47 À : Alan W. Irwin Cc : Plplot-devel mailing list; Hazen Babcock Objet : Re: [Plplot-devel] Qt driver update Hi, > I think I found out what the problem is. The first page reads okay, > but then qt takes over to show the plot and somehow changes the locale > or something. This is on a Mac, English version, but Austrian locale - > so after that scanf expects floating point numbers to be written > numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I > assume that this is the problem, since I printed the out the numbers > with printf in case sscanf fails and the output is: > > 0: 0.0 0.0 0.0 0.0 1.0 0 > 1: 1.0 1.0 1.0 1.0 1.0 0 > 0: 0.0 1.0 1.0 1.0 1.0 0 > 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440 > > *** PLPLOT WARNING *** > Unrecognized cmap1 format (wrong number of items (1) for version 2 of > format) 0.0 1.0 1.0 1.0 1.0 0 > > I'll try now to play around with my locale. The other Mac has also > Austrian locale, but obviously Qt cocoa doesn't mess around here. Ok, this is the problem. Qt carbon changes the locale and sscanf doesn't work as expected any more. If I add setlocale(LC_NUMERIC, "C"); just before the sscanf call, everything works as expected. This is obviously not the correct solution but at least we know what is going wrong. Also if I change my locale to UK the example works as expected. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Werner S. <sm...@ia...> - 2009-09-01 08:56:29
|
Hi Alban, yes it compiles now, but it doesn't work. Still the same problem (I reverted all my changes to plctrl.c). Any other ideas? Regards, Werner On 01.09.2009, at 10:53, Rochel, Alban wrote: > Oops, I forgot: add "#include <QLocale>" somewhere at the top (e.g. > below #include <QMutexLocker>) > ________________________________________ > De : plp...@li... [plp...@li... > ] de la part de Werner Smekal [sm...@ia...] > Date d'envoi : mardi 1 septembre 2009 09:47 > À : Alan W. Irwin > Cc : Plplot-devel mailing list; Hazen Babcock > Objet : Re: [Plplot-devel] Qt driver update > > Hi, > >> I think I found out what the problem is. The first page reads okay, >> but then qt takes over to show the plot and somehow changes the >> locale >> or something. This is on a Mac, English version, but Austrian >> locale - >> so after that scanf expects floating point numbers to be written >> numbers like 3,1415 and not 3.1415. scanf fails then on the >> numbers. I >> assume that this is the problem, since I printed the out the numbers >> with printf in case sscanf fails and the output is: >> >> 0: 0.0 0.0 0.0 0.0 1.0 0 >> 1: 1.0 1.0 1.0 1.0 1.0 0 >> 0: 0.0 1.0 1.0 1.0 1.0 0 >> 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440 >> >> *** PLPLOT WARNING *** >> Unrecognized cmap1 format (wrong number of items (1) for version 2 of >> format) 0.0 1.0 1.0 1.0 1.0 0 >> >> I'll try now to play around with my locale. The other Mac has also >> Austrian locale, but obviously Qt cocoa doesn't mess around here. > > Ok, this is the problem. Qt carbon changes the locale and sscanf > doesn't work as expected any more. If I add > > setlocale(LC_NUMERIC, "C"); > > just before the sscanf call, everything works as expected. This is > obviously not the correct solution but at least we know what is going > wrong. Also if I change my locale to UK the example works as expected. > > Regards, > Werner > > -- > Dr. Werner Smekal > Institut fuer Allgemeine Physik > Technische Universitaet Wien > Wiedner Hauptstr 8-10 > A-1040 Wien > Austria > > email: sm...@ia... > 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 > Plp...@li... > 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: sm...@ia... 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 |
From: Werner S. <sm...@ia...> - 2009-09-01 10:09:09
|
Hi Alban, yes this works. I'll commit this as well. We may have to discuss, if this doesn't break anything else, e.g. if someone wants to use the driver in her Qt application, but as I understand it will initQtApp() only called if there is no existing qt app (or at least the specific lines), so this should be not much trouble. Thanks for your help, Werner On 01.09.2009, at 10:58, Rochel, Alban wrote: > Hi Werner, > > I'm not sure when Qt makes this change to the system settings, but I > suppose it's during the QApplication creation. So, can you try > changing > QLocale::setDefault(QLocale::c()) > into > setlocale(LC_NUMERIC, "C"); > in qt.cpp (line ~100)? > > I hope this will work because I'm out of ideas... > > Alban > ________________________________________ > De : Werner Smekal [sm...@ia...] > Date d'envoi : mardi 1 septembre 2009 09:56 > À : Rochel, Alban > Cc : Alan W. Irwin; Plplot-devel mailing list; Hazen Babcock > Objet : Re: RE : [Plplot-devel] Qt driver update > > Hi Alban, > > yes it compiles now, but it doesn't work. Still the same problem (I > reverted all my changes to plctrl.c). Any other ideas? > > Regards, > Werner > > On 01.09.2009, at 10:53, Rochel, Alban wrote: > >> Oops, I forgot: add "#include <QLocale>" somewhere at the top (e.g. >> below #include <QMutexLocker>) >> ________________________________________ >> De : plp...@li... [plp...@li... >> ] de la part de Werner Smekal [sm...@ia...] >> Date d'envoi : mardi 1 septembre 2009 09:47 >> À : Alan W. Irwin >> Cc : Plplot-devel mailing list; Hazen Babcock >> Objet : Re: [Plplot-devel] Qt driver update >> >> Hi, >> >>> I think I found out what the problem is. The first page reads okay, >>> but then qt takes over to show the plot and somehow changes the >>> locale >>> or something. This is on a Mac, English version, but Austrian >>> locale - >>> so after that scanf expects floating point numbers to be written >>> numbers like 3,1415 and not 3.1415. scanf fails then on the >>> numbers. I >>> assume that this is the problem, since I printed the out the numbers >>> with printf in case sscanf fails and the output is: >>> >>> 0: 0.0 0.0 0.0 0.0 1.0 0 >>> 1: 1.0 1.0 1.0 1.0 1.0 0 >>> 0: 0.0 1.0 1.0 1.0 1.0 0 >>> 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440 >>> >>> *** PLPLOT WARNING *** >>> Unrecognized cmap1 format (wrong number of items (1) for version 2 >>> of >>> format) 0.0 1.0 1.0 1.0 1.0 0 >>> >>> I'll try now to play around with my locale. The other Mac has also >>> Austrian locale, but obviously Qt cocoa doesn't mess around here. >> >> Ok, this is the problem. Qt carbon changes the locale and sscanf >> doesn't work as expected any more. If I add >> >> setlocale(LC_NUMERIC, "C"); >> >> just before the sscanf call, everything works as expected. This is >> obviously not the correct solution but at least we know what is going >> wrong. Also if I change my locale to UK the example works as >> expected. >> >> Regards, >> Werner >> >> -- >> Dr. Werner Smekal >> Institut fuer Allgemeine Physik >> Technische Universitaet Wien >> Wiedner Hauptstr 8-10 >> A-1040 Wien >> Austria >> >> email: sm...@ia... >> 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 >> Plp...@li... >> 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: sm...@ia... > web: http://www.iap.tuwien.ac.at/~smekal > phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 > (laboratory) > fax: +43-(0)1-58801-13499 > -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2009-09-01 18:24:28
|
On 2009-09-01 12:08+0200 Werner Smekal wrote: > Hi Alban, > > yes this [setting locale in qt] works. Hi Werner: Thanks very much for thinking of locale as a possibility for messing up sscanf. That was a stroke of debugging genius, and it is wonderful news that we now have the reason for all the strange results you were getting when attempting to read palette files. However, I don't think the current solution (revision 10363) to this problem is correct. Instead of forcing the C locale whenever we use qt, the user should be allowed to use any locale they like for _user_ input to PLplot regardless of device driver. Of course, our palette files absolutely require setlocale(LC_NUMERIC, "C"); in order to be read properly as you have discovered. Thus, I think our best solution to this whole issue is to save the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then restore the user locale in both cmap0_palette_read and plspal1. This method absolutely guards against any locale issue (say for a different library than qt) ever again screwing up palette file reading so this is what I like. What do you think of this idea? If you agree, would you be willing to help with the implementation and testing? (I don't know how to get the current locale [there appears to be no function called getlocale, although localeconv might be a possibility on Linux], and we have to insure that setlocale [and whatever you recommend for getting the current locale information] works on all our platforms.) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@de...> - 2009-09-04 11:43:36
|
Hi Alan, I have looked at the locale behaviour with the small program below: /* chklocale.c -- Check the behaviour of the locale - printf() and friends */ #include <stdio.h> #include <locale.h> int main( int argc, char *argv[] ) { float x = 1.2; setlocale(LC_NUMERIC, ""); printf( "Number: %f\n", x ); if ( argc > 1 ) { sscanf( argv[1], "%f", &x ); printf( "Read: %f\n", x ); } } Setting LC_NUMERIC to "nl_NL.UTF-8" gives the following results: > chklocale 1.3 chklocale 1.3 Number: 1,200000 Read: 1,000000 > chklocal 1,3 chklocale 1.3 Number: 1,200000 Read: 1,300000 So indeed - as was to be expected, the comma is used on input and output instead of a period. If PLplot's setting of the locale is visible outside the PLplot functions, this may give very nasty errors! Regards, Arjen On 2009-09-04 08:59, Arjen Markus wrote: > Hi Alan, > > much as I appreciate the use of commas instead of periods (living in > a country where commas are used - or should be - as the decimal > separator), I do see a number of problems: > - If a user sets the locale in his/her program before a call to > plinit(), a default enforced by PLplot might cause a different > behaviour than expected. > - If PLplot sets the locale, does this have consequences for > functions like fscanf()? I have never dug into the specifics, > but it might all of a sudden read "1,2" as the number 1.2. > > The effect of introducing setlocale() in PLplot should, in my > opinion, be limited entirely to calls to the PLplot library. > Otherwise there could be all manner of trouble that is difficult > to hunt down. > > Maybe I am pessimistic, but I have seen too many bizarre consequences > from half-hearted implementations of locale settings. (Older versions > of MS Excel made spreadsheets written in one locale unuseable in > another locale, because "1.2" suddenly was a literal string instead > of a number. Even more troublesome: current versions use function > names that are specific to the human language the operating system > is set to. At home I need to type SOM(A1:A10) instead of SUM(A1:A10), > as the OS is set to Dutch.) > > Regards, > > Arjen > > On 2009-09-03 21:48, Alan W. Irwin wrote: >> I have assigned a new subject because this topic deserves its own thread. >> >> On 2009-09-01 11:24-0700 Alan W. Irwin wrote: >> >>> [...] Thus, I think our best solution to this whole issue is to save >>> the user locale, use setlocale(LC_NUMERIC, "C"); to read the file, then >>> restore the user locale in both cmap0_palette_read and plspal1. This method >>> absolutely guards against any locale issue (say for a different library than >>> qt) ever again screwing up palette file reading so this is what I like. >>> >>> What do you think of this idea? >> I have continued to think some more about LC_NUMERIC issues in PLplot, and >> to give some context to further discussion of this, have a look at >> http://en.wikipedia.org/wiki/File:DecimalSeparator.png. My own country of >> Canada has different decimal separators depending upon whether you are >> located in Quebec or otherwise, and a substantial fraction of the countries >> in the world use the comma for the separator rather than a period. >> >> The current status is our plots all correspond to >> >> setlocale(LC_NUMERIC, "C"); >> >> That is they use the period as the decimal separator on axis labels. This is >> probably consistent with the policy of many scientific publishers out there, >> but there are almost guaranteed to be some publishers that accept a decimal >> separator in plots that is whatever the author likes and even some that >> demand the comma separator regardless of the locale of the author. In >> addition, although we advertise PLplot as a scientific plotting library, it >> is also used in other contexts as well where there may be a need to follow >> the local locale with a comma decimal separator. Thus, for maximum PLplot >> usefulness, I think we should have a global variables local_locale set to 0 >> or 1 at user option so that plinit calls either >> >> setlocale(LC_NUMERIC, "C"); >> >> for local_locale = 0 >> >> or >> >> setlocale(LC_NUMERIC, ""); >> >> for local_locale = 1, >> >> where the first one should be the default, and the latter one gives complete >> flexibility since it obtains LC_NUMERIC from the environment (which can be >> set to anything by the user). >> >> Furthermore, this would fit in with my proposed solution to the above issue >> if we always setlocale(LC_NUMERIC, "C"); before reading palette files >> regardless of local_locale and restore to either of the above two choices >> depending on local_locale. Finally, in qt.cpp we should change back to the >> PLplot locale specified by local_locale just in case the Qt4 libraries >> change it. >> >> I hope to implement all of this later today or early tomorrow so please let >> me know quickly your comments on my proposal to deal with LC_NUMERIC issues >> in PLplot. >> >> Alan >> __________________________ >> >> Alan W. Irwin >> >> Astronomical research affiliation with Department of Physics and Astronomy, >> University of Victoria (astrowww.phys.uvic.ca). >> >> Programming affiliations with the FreeEOS equation-of-state implementation >> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software >> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of >> Linux Links project (loll.sf.net); and the Linux Brochure Project >> (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Plplot-devel mailing list >> Plp...@li... >> 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2009-09-04 18:00:40
|
On 2009-09-04 13:43+0200 Arjen Markus wrote: > Hi Alan, > > I have looked at the locale behaviour with the small program below: > > /* chklocale.c -- > Check the behaviour of the locale - printf() and friends > */ > > #include <stdio.h> > #include <locale.h> > > int main( int argc, char *argv[] ) { > > float x = 1.2; > > setlocale(LC_NUMERIC, ""); > > printf( "Number: %f\n", x ); > > if ( argc > 1 ) { > sscanf( argv[1], "%f", &x ); > printf( "Read: %f\n", x ); > } > } > > Setting LC_NUMERIC to "nl_NL.UTF-8" gives the following > results: > > > chklocale 1.3 > chklocale 1.3 > Number: 1,200000 > Read: 1,000000 > > > chklocal 1,3 > chklocale 1.3 > Number: 1,200000 > Read: 1,300000 > > So indeed - as was to be expected, the comma is used on input and > output instead of a period. If PLplot's setting of the locale is visible > outside the PLplot functions, this may give very nasty errors! Hi Arjen: I was hoping you would respond to my post since you live in a country where the decimal separator is a comma rather than period. However, now I have slept on this idea I don't like my suggested implementation any more. I don't think it is a good idea for the PLplot library to set locale since that might conflict with what is assumed by libraries or applications that use the PLplot library. (We were the victim of this ourselves when one form of Qt4 library on OS X set locale without restoring it to whatever PLplot assumed after it was done.) My new idea is it is perfectly legitimate for applications such as examples/c/x01c.c to contain setlocale(LC_NUMERIC, ""); So I now lean toward making that call as a special option for that example (implemented the same general way as the xor option for that example). That should give those who prefer the comma separator for the axis label a specific example of how their applications should be set up to do just that. Note such an example option would also demand the comma separator be used consistently for user input, e.g., "-fsiz 0,5G" rather than "-fsiz 0.5G" for specifying PLplot floating point values on the command line, but I think that is okay since if a user specifically demands comma separators via his locale, but then fails to use them for his command-line input, he probably gets what he deserves. :-) Demonstrating the possibility of using the user's locale as an option for example 1 is probably the correct way to show this possibility for PLplot, but it still leaves the issue of protecting PLplot library file reads (such as the palette file reads which require a period decimal separator) from whatever locale other libraries and applications have set. My reading of the man page for setlocale indicates we can store the current locale in an opaque character string using a NULL locale string as an argument, and then after executing setlocale(LC_NUMERIC, "C"); to protect the read, we can restore back the original locale using the opaque character string. Anyhow, today I will try implementing the example 1 -use_locale option and see whether I can get that to work with my suggested method of protecting the file reads. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |