Werner, Could you try editing qt.cpp (line 99): bool initQtApp(bool isGUI) { QMutexLocker locker(&QtPLDriver::mutex); bool res=false; ++appCounter; if(qApp==NULL && appCounter==1) { argc=1; argv=new char*[2]; argv[0]=new char[10]; argv[1]=new char[1]; snprintf(argv[0], 10, "qt_driver"); argv[1][0]='\0'; new QApplication(argc, argv, isGUI); QLocale::setDefault(QLocale::c()); // add this res=true; } return res; }
I'm surprised that Qt affects the system configuration that way, but I hope that forcing it to use the "universal" C locale will help ensure we won't get these kinds of issues any more. Alban ________________________________________ De : plplot-devel-boun...@lists.sourceforge.net [plplot-devel-boun...@lists.sourceforge.net] de la part de Werner Smekal [sme...@iap.tuwien.ac.at] Date d'envoi : mardi 1 septembre 2009 09:28 À : Alan W. Irwin Cc : Plplot-devel mailing list; Hazen Babcock Objet : Re: [Plplot-devel] Qt driver update Hi Alan, > > That is a really strange result. > > The relevant code from plctrl.c (subject to line rewrap) is identified > exactly by the unique error message above. > > fgets(color_info, 160, fp); > if (sscanf(color_info, "%lf %lf %lf %lf %lf %d", > &pos_d, &r_d, &g_d, &b_d, &a_d, &rev_i) != 6) { > snprintf(msgbuf,1024, > "Unrecognized cmap1 format (wrong number of items for version 2 of > format) %s\n", > color_info); > > So the above warning message outputs exactly the color_info which > sscanf > cannot interpret properly. But if we look at the data in that warning > message above it is perfect; five floating point variables in a row, > then an > integer just like the above sscanf format directives and corresponding > pointers. In particular, we already know there is no hidden null > characters > embedded in the middle of color_info because then that would affect > the > output of color_info in an obvious way (truncated early). It is > hard to > tell from e-mail, but I suppose there could be a line ending or other > non-printing characters embedded in the middle of color_info. I think I found out what the problem is. The first page reads okay, but then qt takes over to show the plot and somehow changes the locale or something. This is on a Mac, English version, but Austrian locale - so after that scanf expects floating point numbers to be written numbers like 3,1415 and not 3.1415. scanf fails then on the numbers. I assume that this is the problem, since I printed the out the numbers with printf in case sscanf fails and the output is: 0: 0.0 0.0 0.0 0.0 1.0 0 1: 1.0 1.0 1.0 1.0 1.0 0 0: 0.0 1.0 1.0 1.0 1.0 0 0,000000, -0,000000, 0,000000. 0,000000, 0,000000, 3075440 *** PLPLOT WARNING *** Unrecognized cmap1 format (wrong number of items (1) for version 2 of format) 0.0 1.0 1.0 1.0 1.0 0 I'll try now to play around with my locale. The other Mac has also Austrian locale, but obviously Qt cocoa doesn't mess around here. I'll keep you informed. Regards, Werner > > Just to be sure that is not the case, could you run example 16 again > and > capture the warning message directly into a file (using ">&" and not > cut and > paste to make this test as direct as possible), then analyze that > file with > something like od to see whether there are any non-printing > characters in > color_info? This is improbable (since color_info is read > immediately before > in the code with fgets above), but it would be good to have rock-solid > confirmation that this improbability is not true. > > If you confirm the color_info output is perfect yet sscanf cannot > read it, > this is a second very strange result (after the very strange result > that the > problem only occurs for qt devices). > > The third very strange result is that the 3rd message above > corresponds to > cmap1_gray.pal which is read without issues for the first page of > the same > example 16! > > One hypothesis that might explain (more or less) all three strange > results > is that dynamic loading of qt devices is linking in a Qt4 library that > breaks sscanf (or fgets if color_info turns out to have some embedded > non-printing characters) on your system in some way. I know that > hypothesis > is quite speculative/improbable so if somebody here can come up with > some > more probable hypothesis to explain these strange results, please > speak up. > > Werner: here are the next steps I would appreciate you doing to help > figure > this out. > > * Check color_info by directly capturing the above error message > into a file > and binary dump that file with something like the od application to > make > sure there are no non-printing characters embedded in the middle of > color_info. (I have done that already with this e-mail, and the > color_info > output above was clean of embedded characters, but some of the > applications > used in the long e-mail chain between us could have filtered out those > non-printing characters, and the right way to do this is by > immediate file > capture on the platform where the warning message is generated.) > > * Experiment with different Qt4 versions to see if the problem goes > away > for one of them. > > Hazen and Jerry: would you do similar experimentation (running > example 16 > with a number of different Qt4 versions) to see if you can replicate > the > issue that Werner found? To switch from one Qt4 version to another, > simply > put the appropriate qmake on your path before a fresh build and > cmake does > the rest. > > If by such experiments from Werner, Hazen, and Jerry we establish > that the > cmap1 palette file reading problems for example 16 occurs only for > one Qt4 > version on OS X but not others, then we only have to warn about that > bad Qt4 > version for OS X in the release notes, and we are (finally) done > with this > issue. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting > software > package (plplot.org); the libLASi project (unifont.org/lasi); the > Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@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 ------------------------------------------------------------------------------ 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