From: Arjen M. <arj...@de...> - 2010-11-24 08:51:53
|
Hello, I am trying to get wxWidgets to work on Windows and see if we can expand the documented capabilities of PLplot on that platform. I downloaded wxWidgets 2.6.3 as described in the Wiki, but I ran into compilation problems: - MSVC /C++ 9.0 does not like the code in src\msw\dlsmw.cpp (line 316) - there is no matching function within the scope for some signature. - GCC 4.5 does not like the redeclaration of boolean in jmorecfg.h (line 264) as included in src\common\imagjpeg.cpp I could of course patch the source, but I do not have the time or the inclination. It would not help any others anyway. Does anybody know what version I should pick up? Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2010-11-24 10:28:20
|
Hello, I tried with version 2.8.11 and that works fine. No compilation problems with MSVC/C++ 9.0. (The Wiki page requires an update of course). Regards, Arjen On 2010-11-24 09:51, Arjen Markus wrote: > Hello, > > I am trying to get wxWidgets to work on Windows and see if we can expand > the documented capabilities of PLplot on that platform. I downloaded > wxWidgets 2.6.3 as described in the Wiki, but I ran into compilation > problems: > - MSVC /C++ 9.0 does not like the code in src\msw\dlsmw.cpp (line 316) - > there is no matching function within the scope for some signature. > - GCC 4.5 does not like the redeclaration of boolean in jmorecfg.h > (line 264) as included in src\common\imagjpeg.cpp > > I could of course patch the source, but I do not have the time or > the inclination. It would not help any others anyway. > > Does anybody know what version I should pick up? > > Regards, > > Arjen > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-11-25 02:14:56
|
On 2010-11-24 11:28+0100 Arjen Markus wrote: > Hello, > > I tried with version 2.8.11 and that works fine. No compilation > problems with MSVC/C++ 9.0. (The Wiki page requires an update of course). Oops. I should have remembered to look at all my e-mail before replying to your first one. Glad it worked out well. Probably, you should say something in the wiki like "the stable release recommended at http://www.wxwidgets.org/downloads/ (2.8.11 as of the 2010-11 time of writing) builds without issues on Windows" to encourage Wiki users to look up what is the latest stable release if the date is substantially later than 2010-11. 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...> - 2010-12-18 23:50:04
|
On 2010-12-18 20:15+0100 Werner Smekal wrote: >> I made an attempt to run comprehensive_test.sh on my Windows system, >> via win-bash, but it requires basic external programs like dirname and >> basename that are not present on the average Windows machine. Using >> msys instead might be an option, but I noticed that CMake on Windows >> does not like it when there is a Bourne-shell present in the path. > > Yes, that's a known issue - cmake doesn't want sh.exe in the path, if there > is, it wants to use the msys makefiles generator. MSys is also far from > complete, since this is just the minimum environment to run the autoconf > tools. I would stay away from msys and stick with win-bash. The missing tools > (dirname, basename, ...) get from http://gnuwin32.sourceforge.net/ - the > shellutils package provides these tools. The cool thing about GnuWin32 is, > that these tools work also in standard Windows CLI (without > bash/msys/whatever). Actually I use these tools to improve my Windows CLI - > this works quite well. Hi Werner: I have changed the subject line to something more appropriate for this thread. I think we will be able to give our Windows testers the choice of either MSYS-bash or win-bash (if that works for all Plplot tests which I have my doubts about, see below) and either gnuwin32 or MSYS. Arjen and I have just proved modern MSYS is complete enough to run all PLplot tests. For example, MSYS does include dirname and basename. I assume from what you have said that gnuwin32 (except for bash where you must use either MSYS-bash or win-bash for PLplot tests) is also complete enough to run the PLplot tests. I suspect the negative feelings you have expressed above about MSYS were established by your extensive experience with older versions of MSYS. Modern MSYS can be downloaded automatically with MinGW in ~5 minutes following the instructions in http://www.miscdebris.net/plplot_wiki/index.php?title=Install_MinGW/MSYS. Also as Arjen and I have recently discovered for Microsoft and wine versions of Windows, comprehensive_test.sh works well now with modern MSYS using the "MSYS Makefiles" generator. And I am about to generalize scripts/MinGW_MSYS_comprehensive_test.sh so that if the user prefers the "MinGW Makefiles" generator they can use it with the appropriate path manipulations to momentarily drop MSYS for the cmake invocation. That manipulation is possible with modern MSYS because the automatic installer keeps the MinGW and MSYS locations separate from each other. (Microsoft Windows users will have to test that "MinGW Makefiles" case for me when MinGW_MSYS_comprehensive_test.sh is generalized. Unlike the "MSYS Makefiles" case, I currently cannot test the "MinGW Makefiles" case on wine because certain CMake target dependencies are silently dropped by mingw32-make. mingw32-make uses many more native Windows features than the MSYS version of make, and therefore I assume this issue with mingw32-make on wine is due to some bug in wine's ability to mimic some Windows component used by mingw32-make which will be solved for some future version of wine.) MSYS-bash is easy to install now, and it has many modern bash features that win-bash doesn't have because win-bash development stopped many years ago. We did get win-bash to work for the limited "ctest" testing environment years ago, but I know the complete testing environment (e.g., including the pkg-config version of the build system for the installed examples) has many modern bash constructs (arrays, for example) which I doubt very much will work for win-bash now. And the situation is only going to get worse as more modern bash constructs creep into our PLplot test environment. Finally, you have expressed a legitimate concern that you prefer the tools you get with GnuWin32 to the (modern) MSYS ones. That should be fine, because all you have to do to assure you are using the GnuWin32 versions is to place the GnuWin32 location higher on the PATH than the MSYS location where MSYS-bash resides. In fact, for the planned change to scripts/MinGW_MSYS_comprehensive_test.sh, the MSYS location will automatically be put last in the PATH. We could also have an option to drop MSYS in the PATH altogether for those still wanting to try win-bash, but I don't think that version of bash will work for comprehensive PLplot testing for the reasons indicated above. Once I am ready, I hope you do test scripts/MinGW_MSYS_comprehensive_test.sh for the "MinGW Makefiles" case to be sure it works without issues for the combination of GnuWin32 tools (higher than MSYS on the PATH by design of MinGW_MSYS_comprehensive_test.sh) and MSYS-bash (or even win-bash if that actually works for comprehensive testing). 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...> - 2010-11-25 02:05:17
|
On 2010-11-24 09:51+0100 Arjen Markus wrote: > Hello, > > I am trying to get wxWidgets to work on Windows and see if we can expand > the documented capabilities of PLplot on that platform. I downloaded > wxWidgets 2.6.3 as described in the Wiki, but I ran into compilation > problems: > - MSVC /C++ 9.0 does not like the code in src\msw\dlsmw.cpp (line 316) - > there is no matching function within the scope for some signature. > - GCC 4.5 does not like the redeclaration of boolean in jmorecfg.h > (line 264) as included in src\common\imagjpeg.cpp > > I could of course patch the source, but I do not have the time or > the inclination. It would not help any others anyway. > > Does anybody know what version I should pick up? Hi Arjen: 2.6.3 is probably too old. According to http://www.wxwidgets.org/downloads/, 2.8.11 is the current stable release, but at www.wxwidgets.org they say the following: "2.9 series bring many improvements compared to 2.8 series and, in spite of being called a development release, we believe that 2.9.1 can be used in production environment, especially for the new projects for which (small) changes in behaviour since 2.8 are not a problem. Give it a try and let us know what do you think!" Debian testing has binary packages for 2.8.10 which at least allows our wxwidgets device to build and work without major errors (segfaults, etc.) for me, but if I were building wxwidgets from scratch I would be tempted to try 2.9.1 first to see if that worked before falling back (if necessary) to a build of 2.8.11. I hope one of those works well for you. Good luck! 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...> - 2010-11-25 07:43:22
|
Hi Alan, On 2010-11-25 03:14, Alan W. Irwin wrote: > On 2010-11-24 11:28+0100 Arjen Markus wrote: > >> Hello, >> >> I tried with version 2.8.11 and that works fine. No compilation >> problems with MSVC/C++ 9.0. (The Wiki page requires an update of course). > > Oops. I should have remembered to look at all my e-mail before > replying to your first one. Glad it worked out well. I know the feeling :). > > Probably, you should say something in the wiki like "the stable > release recommended at http://www.wxwidgets.org/downloads/ (2.8.11 as > of the 2010-11 time of writing) builds without issues on Windows" to > encourage Wiki users to look up what is the latest stable release if > the date is substantially later than 2010-11. > I will do just that. I made an attempt to run comprehensive_test.sh on my Windows system, via win-bash, but it requires basic external programs like dirname and basename that are not present on the average Windows machine. Using msys instead might be an option, but I noticed that CMake on Windows does not like it when there is a Bourne-shell present in the path. Oh well, I should be able to sort this out :). Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-03 19:40:22
|
Hi Arjen: Revision 11363 should take care of the pltcl PATH problems in a cross-platform way. To test this, run the comprehensive_test.sh script without setting your PATH to any special build-tree values. 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...> - 2010-12-12 02:31:29
|
On 2010-12-03 11:40-0800 Alan W. Irwin wrote: > Revision 11363 should take care of the pltcl PATH problems in a > cross-platform way. To test this, run the comprehensive_test.sh script > without setting your PATH to any special build-tree values. I must have forgotten to test that revision because it didn't even work on Linux! I have now solved this issue another way (revision 11367 which does work on Linux and avoids the pitfall of all previous solutions which introduced an install-tree PATH into the build-tree testing meaning that (wine) Windows would find the installed libraries rather than the correct build-tree libraries). This new implementation is also designed to work with Tcl on Windows (with MSYS bash PATH conventions), but I haven't tested it yet on (wine) Windows. 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...> - 2010-12-02 21:10:51
|
On 2010-12-02 12:25+0100 Arjen Markus wrote: > Hi Alan, > > getting the latest version of MSYS and MinGW using this installation > tool worked like a jiffy. I saw error messages about two packages > that were not downloaded, but I guess I can get them when needed. Hi Arjen: I am taking this conversation back to the list because I think this good news about a working modern installer for MinGW/MSYS is of interest to quite a few here since otherwise installing modern MinGW/MSYS is quite a nasty chore. I tried the same installer (found at "http://prdownloads.sourceforge.net/mingw/Automated MinGW Installer/mingw-get-inst/mingw-get-inst-20101030/mingw-get-inst-20101030.exe" (all on one line with a blank between "Automated", "MinGW" and "Installer...") here under wine-1.3.8. It appeared to work with no issues at all. Using that installer, I chose gcc, g++, gfortran, Ada, and the MinGW developer toolkit (which includes MSYS BaseSystem). Despite the quite large number of packages that were downloaded, the whole process was still quick (5 minutes or so) so I think we can recommend this new installer to everybody here that wants to get quickly started with the latest MinGW/MSYS packages. More later once I get PLplot's dependencies and PLplot itself built and tested with the latest MinGW/MSYS under Wine. 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...> - 2010-12-03 07:56:53
|
Hi Alan, my first results with this new version of MinGW/MSYS are encouraging: The comprehensive_test.sh script now properly redirects the output to the various files, there is only one obvious error (pltcl.exe is still not found) and the results for C, C++ and Fortran look identical (I checked a few files manually, so nothing exhaustive). The problem with pltcl.exe is most likely that the ../utils directory is missing from the path ... although the code does extend the path! Something to check then. Regards, Arjen On 2010-12-02 22:10, Alan W. Irwin wrote: > On 2010-12-02 12:25+0100 Arjen Markus wrote: > >> Hi Alan, >> >> getting the latest version of MSYS and MinGW using this installation >> tool worked like a jiffy. I saw error messages about two packages >> that were not downloaded, but I guess I can get them when needed. > > Hi Arjen: > > I am taking this conversation back to the list because I think this > good news about a working modern installer for MinGW/MSYS is of > interest to quite a few here since otherwise installing modern > MinGW/MSYS is quite a nasty chore. > > I tried the same installer (found at > "http://prdownloads.sourceforge.net/mingw/Automated MinGW > Installer/mingw-get-inst/mingw-get-inst-20101030/mingw-get-inst-20101030.exe" > > (all on one line with a blank between "Automated", "MinGW" and > "Installer...") here under wine-1.3.8. It appeared to work with no > issues at all. > > Using that installer, I chose gcc, g++, gfortran, Ada, and the MinGW > developer toolkit (which includes MSYS BaseSystem). Despite the quite > large number of packages that were downloaded, the whole process was > still quick (5 minutes or so) so I think we can recommend this new > installer to everybody here that wants to get quickly started with the > latest MinGW/MSYS packages. > > More later once I get PLplot's dependencies and PLplot itself built > and tested with the latest MinGW/MSYS under Wine. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-03 08:31:41
|
On 2010-12-03 08:56+0100 Arjen Markus wrote: > Hi Alan, > > my first results with this new version of MinGW/MSYS are encouraging: > The comprehensive_test.sh script now properly redirects the output to > the various files, there is only one obvious error (pltcl.exe is still > not found) and the results for C, C++ and Fortran look identical > (I checked a few files manually, so nothing exhaustive). That's good news that you now have a modern bash working properly on Windows now. Instead of diffing individual files, you can also take a look at e.g., comprehensive_test_disposeable/shared/output_tree/make_noninteractive.out which should show the standard diff summary near the end of that file. (And similarly for ctest.out and other test_noninteractive.out output files when you get to further tests with comprehensive_test.sh). > The problem with pltcl.exe is most likely that the ../utils directory is > missing from the path ... although the code does extend the path! > Something to check then. Yes, I have also eyeballed test_tcl.sh, and I cannot see what could be going wrong there with the PATH manipulations. To check that at run time I suggest you change directory to comprehensive_test_disposeable/shared/build_tree then edit plplot_test/test_tcl.sh to run the commands pwd echo "PATH is $PATH" right before pltcl.exe is invoked to output the current directory and PATH. Then try "make test_interactive" by hand or else its tcl subset "make test_tcl_psc". Either of those commands should indirectly run that edited plplot_test/test_tcl.sh so you can figure out what is going wrong. Good luck, and let me know how it goes. 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...> - 2010-12-03 09:46:08
|
Hi Alan, got it! The path is extended using the Windows convention, whereas it should be the MinGW/Linux-like convention. The result is: This is the current directory: /d/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/tcl And this is the (first) part of the PATH variable: D:/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/../utils:D:/plplot-svn/plplot/comprehensive_test_disposeable/shared/install_tree/bin:/d/cmake/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/PROGRA~1/plusFORT:/c/Program Files/Intel/Compiler/11.1/065/lib/ia32:... Note the use of D:/ and /d/ to indicate the drive. I will make the necessary changes and try again. (Because the tests fail on pltcl.exe the differences are never reported!) Regards, Arjen On 2010-12-03 09:31, Alan W. Irwin wrote: > On 2010-12-03 08:56+0100 Arjen Markus wrote: > >> Hi Alan, >> >> my first results with this new version of MinGW/MSYS are encouraging: >> The comprehensive_test.sh script now properly redirects the output to >> the various files, there is only one obvious error (pltcl.exe is still >> not found) and the results for C, C++ and Fortran look identical >> (I checked a few files manually, so nothing exhaustive). > > That's good news that you now have a modern bash working properly on > Windows now. > > Instead of diffing individual files, you can also take a look at e.g., > comprehensive_test_disposeable/shared/output_tree/make_noninteractive.out > which should show the standard diff summary near the end of that file. > (And similarly for ctest.out and other test_noninteractive.out output > files when you get to further tests with comprehensive_test.sh). > >> The problem with pltcl.exe is most likely that the ../utils directory is >> missing from the path ... although the code does extend the path! >> Something to check then. > > Yes, I have also eyeballed test_tcl.sh, and I cannot see what could be > going wrong there with the PATH manipulations. To check that at run > time I suggest you change directory to > > comprehensive_test_disposeable/shared/build_tree > > then edit plplot_test/test_tcl.sh to > > run the commands > > pwd > echo "PATH is $PATH" > > right before pltcl.exe is invoked to output the current directory > and PATH. > > Then try "make test_interactive" by hand or else its tcl subset "make > test_tcl_psc". Either of those commands should indirectly run that > edited plplot_test/test_tcl.sh so you can figure out what is going > wrong. > > Good luck, and let me know how it goes. > > 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...> - 2010-12-21 10:21:45
|
Hi Alan, I think you misunderstand the issue. The problem is that a file consists of bytes. In the old days, each byte corresponded to a single character, but with the advent of UTF-8 and the like a single character may be represented by one, two or more bytes. What a program will do with these bytes depends on the assumption about the character encoding. For Tcl programs the following happens: - Based on the system encoding, all sequences of bytes are translated into equivalent UTF-8 characters. - If the system encoding is NOT UTF-8, the internal resulting sequence may not be the same as in the file. For instance, on Windows "cp1252" is one way to connect the bytes above 127 to characters such as A-umlaut. So a byte that represents A-umlaut according to the cp1252 encoding is translated to the UTF-8 sequence of bytes that represents that very same character. In other words: it is a completely different sequence of bytes. - Right now we pass that _internal_ sequence of bytes to the PLplot C library - and assume that it was the original sequence of bytes. But that is only true if the system encoding is UTF-8. The code I propose as an alternative reverses the translation. Bytes lower/equal 127 represent exactly the same charachters in cp1252 and UTF-8 (by design), so most examples are not affected by this distinction. (I agree this is highly confusing - but if you simply think of bytes separated from characters it becomes a bit easier) Regards, Arjen On 2010-12-21 10:55, Alan W. Irwin wrote: > On 2010-12-21 09:25+0100 Arjen Markus wrote: > >> I solved it, based on a suggestion from a fellow Tcler: we need to >> pass the string to a Tcl_UtfToExternal*() function. The problem on >> Windows is that the system encoding is _not_ UTF-8, but cp1252. >> The strings in the source are therefore translated from cp1252 to UTF-8, >> so that the resulting string represents these characters. Using said >> function undoes this translation: the PLplot routines receive the >> original sequence of bytes. > > I think this explanation must be incomplete or incorrect. The reason I > say this is our Tcl example files, e.g., x24.tcl, (and our C code as > well, for that matter) are all encoded directly in UTF-8. So when I > use the emacs editor to look at x24.tcl, the "Peace" words below > > set peace { > > are displayed correctly for every language. Apparently it would be > impossible to encode those peace words as cp1252. That encoding is > quite limited and very close to ISO-8559-1 according to the Wikipedia > article about it, and thus would not be able to represent, e.g., the > Mandarin, Arabic, etc. words for Peace that I see when editing that > file with emacs. > > On Linux, when the pltcl executable interprets those UTF-8 encoded source > files, it does everything as expected and passes those strings directly > as UTF-8 to the PLplot core library. (I have just double-checked > that by running "../../utils/pltcl x24 -dev pngcairo -o test.png" in the > build-tree > examples/tcl subdirectory on Linux, and the result was a perfect > Peace flag just like we get on Linux with the > x24c executable that is written > in C (as can be seen by looking at, e.g., > http://plplot.sourceforge.net/examples-data/demo24/x24.01.png). > > Arjen, what happens for the x24c executable on Windows for a modern > device such as pngcairo? (My wine fonts are quite limited so I just > get blanks for the exotic languages so it is not a definitive test). If > your x24c results with pngcairo are similar to the above result > displayed on our web site, then all is well in Windows C, and the only > remaining question is what is going on in Tcl for Windows that is so > different from C for Windows in how it deals with source files that > are encoded in UTF-8. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-21 19:03:38
|
On 2010-12-21 11:21+0100 Arjen Markus wrote: > Hi Alan, > > I think you misunderstand the issue. The problem is that a file > consists of bytes. In the old days, each byte corresponded to a > single character, but with the advent of UTF-8 and the like a single > character may be represented by one, two or more bytes. What a program > will do with these bytes depends on the assumption about the > character encoding. > > For Tcl programs the following happens: > - Based on the system encoding, all sequences of bytes are translated > into equivalent UTF-8 characters. > - If the system encoding is NOT UTF-8, the internal resulting sequence > may not be the same as in the file. For instance, on Windows "cp1252" > is one way to connect the bytes above 127 to characters such as > A-umlaut. So a byte that represents A-umlaut according to the cp1252 > encoding is translated to the UTF-8 sequence of bytes that represents > that very same character. In other words: it is a completely different > sequence of bytes. > - Right now we pass that _internal_ sequence of bytes to the PLplot C > library - and assume that it was the original sequence of bytes. > But that is only true if the system encoding is UTF-8. > The code I propose as an alternative reverses the translation. > > Bytes lower/equal 127 represent exactly the same charachters in cp1252 > and UTF-8 (by design), so most examples are not affected by this > distinction. > > (I agree this is highly confusing - but if you simply think of > bytes separated from characters it becomes a bit easier) I agree it is highly confusing and difficult to describe clearly. When I look at the Peace words in the actual files x24.tcl (and x24c.c) with the system tools available to me (the emacs editor in my case), it is clear the bytes in those files can only be interpreted properly with a UTF-8 encoding. Please use your own system analysis tools to confirm that conclusion so that at least our analysis is starting at the same point. In other words, if you had some system tool there that assumed the Peace words in x24.tcl was cp1252, then the result would be displayed as gibberish or blank. Only if you interpret with the UTF-8 encoding _and_ have the Mandarin fonts installed would the Mandarin Peace word be rendered properly as happens for me with the emacs editor. Does that also happen for you with whatever file display tool that is accessible to you that is capable of understanding UTF-8 encoded files? I acknowledge that Tcl often does things in a very complex way so I would advise forgetting Tcl for the moment and instead looking at the example 24 results from C. Does the x24c executable produce the same as http://plplot.sourceforge.net/examples-data/demo24/x24.01.png on your system when you use the pngcairo or pngqt device drivers? If so, that confirms you have the proper system fonts installed, and then there is some hope of getting the same good result with Tcl. On the other hand, if you cannot make the C example give a good example 24 result on Windows with the cairo or qt devices, then there is little hope for Tcl. I will stop now and not comment more on the Tcl case, because I think it is essential to focus on C for now and one of the cairo or qt devices. Of course, as I have stated before the psc device driver is not useful for diagnosis of encoding issues because everything exotic such as the Mandarin Peace word ends up as blanks in any case because the standard Type 1 fonts that the psc device uses have an extremely limited glyph set that does not include Mandarin glyphs or any other non-English glyphs besides Greek (for mathematical purposes). 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...> - 2010-12-22 08:23:24
|
Hi Alan, On 2010-12-21 20:03, Alan W. Irwin wrote: > > I agree it is highly confusing and difficult to describe clearly. > > When I look at the Peace words in the actual files x24.tcl (and > x24c.c) with the system tools available to me (the emacs editor in my > case), it is clear the bytes in those files can only be interpreted > properly with a UTF-8 encoding. Please use your own system analysis > tools to confirm that conclusion so that at least our analysis is > starting at the same point. In other words, if you had some system > tool there that assumed the Peace words in x24.tcl was cp1252, then > the result would be displayed as gibberish or blank. Only if you > interpret with the UTF-8 encoding _and_ have the Mandarin fonts > installed would the Mandarin Peace word be rendered properly as > happens for me with the emacs editor. Does that also happen for you > with whatever file display tool that is accessible to you that is > capable of understanding UTF-8 encoded files? > If I view the file with a tool that can interpret the bytes as either cp1252 or UTF-8, then: - cp1252 gives a lot of jibberish - UTF-8 gives black rectangles to indicate a missing glyph, except for a few extended-latin scripts. For Kurdish I see an "i accent circonflexe" as is supposed to. > I acknowledge that Tcl often does things in a very complex way so I > would advise forgetting Tcl for the moment and instead looking at the > example 24 results from C. Does the x24c executable produce the same > as http://plplot.sourceforge.net/examples-data/demo24/x24.01.png on > your system when you use the pngcairo or pngqt device drivers? > > If so, that confirms you have the proper system fonts installed, and > then there is some hope of getting the same good result with Tcl. On > the other hand, if you cannot make the C example give a good example > 24 result on Windows with the cairo or qt devices, then there is > little hope for Tcl. > > I will stop now and not comment more on the Tcl case, because I think > it is essential to focus on C for now and one of the cairo or qt > devices. > > Of course, as I have stated before the psc device driver is not useful > for diagnosis of encoding issues because everything exotic such as the > Mandarin Peace word ends up as blanks in any case because the standard > Type 1 fonts that the psc device uses have an extremely limited glyph > set that does not include Mandarin glyphs or any other non-English > glyphs besides Greek (for mathematical purposes). > I will continue to research this issue. I will probably have to install some extra font files for proper viewing - on screen I see a lot of rubbish too :). Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2010-12-03 10:21:34
|
Hi Alan, I have added the directory /d/..../utils to the PATH and a number of Tcl examples get done correctly, but at no. 14 I get this: Read 721 data points, 2 separate streams Read 721 data points, 4 separate streams Read 12 data points, 1 separate streams Read 100 data points, 1 separate streams pltcl demo of plgrid x01 x02 x03 x04 x05 x06 x07 x08 x09 x10 x11 x12 x13 x14 Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. Can't open /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. *** PLPLOT ERROR, IMMEDIATE EXIT *** Too many tries. Program aborted make[3]: *** [examples/x01t.psc] Error 1 I have no idea why some program (it is unclear which one) wants to open a file "x14at.psc". There is no mention of such a file name that I can see. Regards, Arjen On 2010-12-03 09:31, Alan W. Irwin wrote: > On 2010-12-03 08:56+0100 Arjen Markus wrote: > >> Hi Alan, >> >> my first results with this new version of MinGW/MSYS are encouraging: >> The comprehensive_test.sh script now properly redirects the output to >> the various files, there is only one obvious error (pltcl.exe is still >> not found) and the results for C, C++ and Fortran look identical >> (I checked a few files manually, so nothing exhaustive). > > That's good news that you now have a modern bash working properly on > Windows now. > > Instead of diffing individual files, you can also take a look at e.g., > comprehensive_test_disposeable/shared/output_tree/make_noninteractive.out > which should show the standard diff summary near the end of that file. > (And similarly for ctest.out and other test_noninteractive.out output > files when you get to further tests with comprehensive_test.sh). > >> The problem with pltcl.exe is most likely that the ../utils directory is >> missing from the path ... although the code does extend the path! >> Something to check then. > > Yes, I have also eyeballed test_tcl.sh, and I cannot see what could be > going wrong there with the PATH manipulations. To check that at run > time I suggest you change directory to > > comprehensive_test_disposeable/shared/build_tree > > then edit plplot_test/test_tcl.sh to > > run the commands > > pwd > echo "PATH is $PATH" > > right before pltcl.exe is invoked to output the current directory > and PATH. > > Then try "make test_interactive" by hand or else its tcl subset "make > test_tcl_psc". Either of those commands should indirectly run that > edited plplot_test/test_tcl.sh so you can figure out what is going > wrong. > > Good luck, and let me know how it goes. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-03 17:26:49
|
On 2010-12-03 10:21+0100 Arjen Markus wrote: > Hi Alan, > > I have added the directory /d/..../utils to the PATH and a number of Tcl > examples get done correctly. That's a useful temporary workaround, but I will follow up (under wine) to see why the scripts are not setting the PATH correctly in a Windows environment. But at no. 14 I get this: > > Read 721 data points, 2 separate streams > Read 721 data points, 4 separate streams > Read 12 data points, 1 separate streams > Read 100 data points, 1 separate streams > pltcl demo of plgrid > x01 > x02 > x03 > x04 > x05 > x06 > x07 > x08 > x09 > x10 > x11 > x12 > x13 > x14 > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > Can't open > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. > > *** PLPLOT ERROR, IMMEDIATE EXIT *** > Too many tries. > Program aborted > make[3]: *** [examples/x01t.psc] Error 1 > > I have no idea why some program (it is unclear which one) wants to open > a file "x14at.psc". There is no mention of such a file name that I can > see. Example 14 asks for a file name to open. That is supplied by the echo "${results}"/x${index}a${lang}%n.$dsuffix | \ statement in plplot_test/test_tcl.sh. There is completely similar logic in test_c.sh that works for you. The only real difference I can see is the application in the tcl case is a shell script whose first line is #!/bin/sh I don't think that "bang line" should work at all for you. But it does for the x01, etc. cases (up to but not including x14) so I suspect it may be accessing a non-bash shell which cannot handle the special logic in the x14 shell script. One way out of the above incorrect "bang" line is to configure all of examples/tcl/x?? scripts with a first line of #!@SH_EXECUTABLE@ but I prefer not to do that since I always think non-configured files are easier to understand. Instead, I have (revision 11362) explicitly changed plplot_test/test_tcl.sh.in (which is already a configured file) so that @SH_EXECUTABLE@ executes each x?? script (which bypasses the bang line in each of the x?? shell scripts). Does that revision work any better for you? If so, great. If not, then you should disable tcl for your further runs of comprehensive_test.sh (using the option --cmake_added_options for that script) until I can figure this out. 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...> - 2010-12-24 12:05:25
|
Hi Alan, On 2010-12-21 20:03, Alan W. Irwin wrote: > > I will stop now and not comment more on the Tcl case, because I think > it is essential to focus on C for now and one of the cairo or qt > devices. > > Of course, as I have stated before the psc device driver is not useful > for diagnosis of encoding issues because everything exotic such as the > Mandarin Peace word ends up as blanks in any case because the standard > Type 1 fonts that the psc device uses have an extremely limited glyph > set that does not include Mandarin glyphs or any other non-English > glyphs besides Greek (for mathematical purposes). > I have checked the C and F95 examples 24 with the wxWidgets device on Windows: they work very nicely, except that my PC does not have all the required fonts. With Tcl I recognise the odd sequences I also see in the source code (viewed from a cp1252 perspective). Over the weekend I won't be able to do anything - holiday obligations :). I wish you all a merry Christmas and a happy New Year. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-24 21:20:39
|
On 2010-12-24 13:05+0100 Arjen Markus wrote: > Hi Alan, > > On 2010-12-21 20:03, Alan W. Irwin wrote: > >> >> I will stop now and not comment more on the Tcl case, because I think >> it is essential to focus on C for now and one of the cairo or qt >> devices. >> >> Of course, as I have stated before the psc device driver is not useful >> for diagnosis of encoding issues because everything exotic such as the >> Mandarin Peace word ends up as blanks in any case because the standard >> Type 1 fonts that the psc device uses have an extremely limited glyph >> set that does not include Mandarin glyphs or any other non-English >> glyphs besides Greek (for mathematical purposes). >> > > I have checked the C and F95 examples 24 with the wxWidgets device on > Windows: they work very nicely, except that my PC does not have all the > required fonts. With Tcl I recognise the odd sequences I also see in > the source code (viewed from a cp1252 perspective). Thus, it appears from your results that C and Fortran on Windows simply accept the byte sequences mentioned in strings without molesting them while your hypothesis is that Tcl does not follow that simple model. Instead it does an implicit transformation of all strings from (presumed) system encoding to UTF-8 which messes up the byte sequences, and your proposed cure is to take all strings input to PLplot from Tcl and do the inverse transformation which uses a call to Tcl_UtfToExternalDString with a NULL encoding. From the man page, what that will do is to convert a (presumed) UTF-8 string to the (presumed) system encoding. If your hypothesis is correct, then your proposed cure might indeed work on all platforms. Certainly on Linux, the implicit transformation is UTF-8 to UTF-8 or the identity transform (which is why Tcl works right now for example 24 on Linux), and your inverse transformation would also be the identify transformation on Linux and should therefore also work on that platform. However, I am concerned with the following issues. 1. All PLplot API arguments that are strings are assumed to be in UTF-8. Thus, the call to Tcl_UtfToExternalDString with NULL has to be made in the Tcl bindings for _every_ function in the PLplot API that has an input string. 2. Does the implicit transformation work for arbitrary UTF-8 (e.g., arbitrary series of 8-bit bytes) or are there some 8-bit bytes which cannot be validly interpreted as cp1252 or which have special meanings. 3. Is Tcl_UtfToExternalDString with NULL encoding the exact inverse of the implicit transformation? All of these issues can be dealt with. Obviously some care in the Tcl bindings should take care of issue 1 and to alleviate concern about issues 2 and 3 completely, it would be a good idea to put together a complete test of all 256 possible 8-bit character combinations. I am thinking along the lines of generating a file from C with a string of all possibilities from 255 down to a zero (to terminate the string). Then using an editor copy that exact string of 256 bytes to Tcl source code that automatically puts that string through the implicit transformation. Then use the Tcl_UtfToExternalDString with NULL to transform that string before calling a C programme that simply outputs the string. Then compare that output file with the original file with 256 characters to see if you get all 256 characters back in their original form. However, to avoid this work it would be better to convince Tcl not to do the implicit string transformation in the first place. The way this is handled in Python is to put the following string in the first or second line of the Python script that identifies the whole Python source file is encoded in utf-8: # -*- coding: utf-8 -*- We do that for the following Python examples: software@raven> grep coding: examples/python/xw??.py examples/python/xw18.py:# -*- coding: utf-8; -*- examples/python/xw24.py:# -*- coding: utf-8; -*- examples/python/xw26.py:# -*- coding: utf-8; -*- examples/python/xw33.py:# -*- coding: utf-8; -*- I think Tcl may have something equivalent in the encoding system utf-8 command. From the documentation users are discouraged from using that command because it affects everything such as system calls. For example, puts would output strings in UTF-8 encoding rather than the actual (e.g., cp1252 on your platform) system encoding on Windows machines. But is that actually an issue for the above examples? First, we don't interact with the operating system (e.g, with puts) as far as I know with those examples, and UTF-8 and cp1252 coincide in any case for ascii strings. Anyhow, if "encoding system utf-8" works for those examples, I think we should use it rather than the more difficult steps outlined above. Of course, we should inform Tcl users browsing our example code via a comment in those examples that PLplot requires utf-8 system encoding for all non-ascii input strings. > > Over the weekend I won't be able to do anything - holiday > obligations :). > > I wish you all a merry Christmas and a happy New Year. I wish everybody here a "Merry Christmas" and "Happy New Year" as well. Enjoy your holidays, Arjen, and I hope when you come back you will find the "encoding system utf-8" solution works without issues for the affected examples. 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...> - 2010-12-06 08:27:21
|
Hi Alan, I tested this, but it did not work! I got the same problem. With the information you gave me, I checked Tcl example x14. From the command-line all seems to be quite okay - it wants two file names. Also "echo aa |pltcl x14 -dev psc -o bb" works. Very odd! I will continue without Tcl for the moment. Regards, Arjen On 2010-12-03 18:26, Alan W. Irwin wrote: > On 2010-12-03 10:21+0100 Arjen Markus wrote: > >> Hi Alan, >> >> I have added the directory /d/..../utils to the PATH and a number of Tcl >> examples get done correctly. > > That's a useful temporary workaround, but I will follow up (under > wine) to see why the scripts are not setting the PATH correctly in a > Windows environment. > > But at no. 14 I get this: >> >> Read 721 data points, 2 separate streams >> Read 721 data points, 4 separate streams >> Read 12 data points, 1 separate streams >> Read 100 data points, 1 separate streams >> pltcl demo of plgrid >> x01 >> x02 >> x03 >> x04 >> x05 >> x06 >> x07 >> x08 >> x09 >> x10 >> x11 >> x12 >> x13 >> x14 >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> Can't open >> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >> >> >> *** PLPLOT ERROR, IMMEDIATE EXIT *** >> Too many tries. >> Program aborted >> make[3]: *** [examples/x01t.psc] Error 1 >> >> I have no idea why some program (it is unclear which one) wants to open >> a file "x14at.psc". There is no mention of such a file name that I can >> see. > > Example 14 asks for a file name to open. That is supplied by the > > echo "${results}"/x${index}a${lang}%n.$dsuffix | \ > > statement in plplot_test/test_tcl.sh. > > There is completely similar logic in test_c.sh that works for you. > The only real difference I can see is the application in the tcl > case is a shell script whose first line is > > #!/bin/sh > > I don't think that "bang line" should work at all for you. But it does > for the x01, etc. cases (up to but not including x14) so I suspect it > may be accessing a non-bash shell which cannot handle the special > logic in the x14 shell script. > > One way out of the above incorrect "bang" line is to configure all of > examples/tcl/x?? scripts with a first line of > > #!@SH_EXECUTABLE@ > > but I prefer not to do that since I always think non-configured files > are easier to understand. Instead, I have (revision 11362) explicitly > changed plplot_test/test_tcl.sh.in (which is already a configured > file) so that @SH_EXECUTABLE@ executes each x?? script (which bypasses > the bang line in each of the x?? shell scripts). > > Does that revision work any better for you? > > If so, great. If not, then you should disable tcl for your further > runs of comprehensive_test.sh (using the option --cmake_added_options > for that script) until I can figure this out. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2010-12-06 09:37:10
|
Hi Alan, here is the summary of that test: C example 29 is missing c++ Missing examples : 33 Differing postscript output : 04 18 26 Missing stdout : Differing stdout : C example 29 is missing f77 Missing examples : 33 Differing postscript output : 04 09 14a 18 26 Missing stdout : Differing stdout : C example 29 is missing f95 Missing examples : 33 Differing postscript output : 04 18 26 Missing stdout : Differing stdout : WARNING: Some PostScript or stdout results were different (There were some messages during the individual tests that may warrant further analysis - I will send the full report to you off-list) Regards, Arjen On 2010-12-06 09:27, Arjen Markus wrote: > Hi Alan, > > I tested this, but it did not work! I got the same problem. > With the information you gave me, I checked Tcl example x14. > From the command-line all seems to be quite okay - it wants two > file names. Also "echo aa |pltcl x14 -dev psc -o bb" works. > > Very odd! > > I will continue without Tcl for the moment. > > Regards, > > Arjen > > On 2010-12-03 18:26, Alan W. Irwin wrote: >> On 2010-12-03 10:21+0100 Arjen Markus wrote: >> >>> Hi Alan, >>> >>> I have added the directory /d/..../utils to the PATH and a number of Tcl >>> examples get done correctly. >> That's a useful temporary workaround, but I will follow up (under >> wine) to see why the scripts are not setting the PATH correctly in a >> Windows environment. >> >> But at no. 14 I get this: >>> Read 721 data points, 2 separate streams >>> Read 721 data points, 4 separate streams >>> Read 12 data points, 1 separate streams >>> Read 100 data points, 1 separate streams >>> pltcl demo of plgrid >>> x01 >>> x02 >>> x03 >>> x04 >>> x05 >>> x06 >>> x07 >>> x08 >>> x09 >>> x10 >>> x11 >>> x12 >>> x13 >>> x14 >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> Can't open >>> /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at.psc. >>> >>> >>> *** PLPLOT ERROR, IMMEDIATE EXIT *** >>> Too many tries. >>> Program aborted >>> make[3]: *** [examples/x01t.psc] Error 1 >>> >>> I have no idea why some program (it is unclear which one) wants to open >>> a file "x14at.psc". There is no mention of such a file name that I can >>> see. >> Example 14 asks for a file name to open. That is supplied by the >> >> echo "${results}"/x${index}a${lang}%n.$dsuffix | \ >> >> statement in plplot_test/test_tcl.sh. >> >> There is completely similar logic in test_c.sh that works for you. >> The only real difference I can see is the application in the tcl >> case is a shell script whose first line is >> >> #!/bin/sh >> >> I don't think that "bang line" should work at all for you. But it does >> for the x01, etc. cases (up to but not including x14) so I suspect it >> may be accessing a non-bash shell which cannot handle the special >> logic in the x14 shell script. >> >> One way out of the above incorrect "bang" line is to configure all of >> examples/tcl/x?? scripts with a first line of >> >> #!@SH_EXECUTABLE@ >> >> but I prefer not to do that since I always think non-configured files >> are easier to understand. Instead, I have (revision 11362) explicitly >> changed plplot_test/test_tcl.sh.in (which is already a configured >> file) so that @SH_EXECUTABLE@ executes each x?? script (which bypasses >> the bang line in each of the x?? shell scripts). >> >> Does that revision work any better for you? >> >> If so, great. If not, then you should disable tcl for your further >> runs of comprehensive_test.sh (using the option --cmake_added_options >> for that script) until I can figure this out. >> >> 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 >> __________________________ >> > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-06 19:54:04
|
On 2010-12-06 10:36+0100 Arjen Markus wrote: > Hi Alan, > > here is the summary of that test: > > C example 29 is missing > c++ > Missing examples : 33 > Differing postscript output : 04 18 26 > Missing stdout : > Differing stdout : > C example 29 is missing > f77 > Missing examples : 33 > Differing postscript output : 04 09 14a 18 26 > Missing stdout : > Differing stdout : > C example 29 is missing > f95 > Missing examples : 33 > Differing postscript output : 04 18 26 > Missing stdout : > Differing stdout : > WARNING: Some PostScript or stdout results were different That's a most encouraging result. The missing 33 and differing 4, 18, and 26 results occur on Linux as well at the moment. Propagation of plstring, plstring3, and pllegend to C++, f77, and f95 bindings and propagating C example 33 to those languages should solve those problems. I don't know what is going on with 9 and 14a for f77 on Windows, but I assume you can figure that out by running the various examples by hand. Important: The "C example 29 is missing" message above is a left over from when we excluded example 29 in the Windows case because we didn't have time functionality that was suitable for that platform. But now example 29 should work fine on Windows because you appear to be building the qsastime library without issues. Could you test example 29 on Windows by modifying the critical_examples variable in plplot_test/plplot-test.sh.cmake to include example 29 for the Windows case? I will respond off list to the detailed output results you sent me. 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...> - 2010-12-07 07:53:30
|
Hi Alan, thanks for reviewing these messages. I have worked on plstring and plstring3 for Fortran and Tcl, but not everything is done yet. pllegend is more of a challenge as it uses an aray of strings - the first occurrence as far as I am aware of that in PLplot. Anyway, I should be able to take care of that in the coming few weeks. I will add example 29 to the mix. That poses no particular challenges. As for Tcl example x14, I printed the command that is used for Tcl and C and it turns out that for C the name of the second file to be written is "./examples/x14ac.psc", whereas for Tcl the whole path is included - /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at%n.psc Could that be too long? (I have not checked it ...) I do not understand yet why we have this difference - oh: test_c uses ${OUTPUT_DIR} and test_tcl uses ${results}. I will change this and see what happens. Regards, Arjen On 2010-12-06 20:53, Alan W. Irwin wrote: > On 2010-12-06 10:36+0100 Arjen Markus wrote: > >> Hi Alan, >> >> here is the summary of that test: >> >> C example 29 is missing >> c++ >> Missing examples : 33 >> Differing postscript output : 04 18 26 >> Missing stdout : >> Differing stdout : >> C example 29 is missing >> f77 >> Missing examples : 33 >> Differing postscript output : 04 09 14a 18 26 >> Missing stdout : >> Differing stdout : >> C example 29 is missing >> f95 >> Missing examples : 33 >> Differing postscript output : 04 18 26 >> Missing stdout : >> Differing stdout : >> WARNING: Some PostScript or stdout results were different > > That's a most encouraging result. The missing 33 and differing 4, 18, > and 26 results occur on Linux as well at the moment. Propagation of > plstring, plstring3, and pllegend to C++, f77, and f95 bindings and > propagating C example 33 to those languages should solve those > problems. I don't know what is going on with 9 and 14a for f77 on > Windows, but I assume you can figure that out by running the various > examples by hand. > > Important: The "C example 29 is missing" message above is a left over > from when we excluded example 29 in the Windows case because we didn't > have time functionality that was suitable for that platform. But now > example 29 should work fine on Windows because you appear to be > building the qsastime library without issues. Could you test example > 29 on Windows by modifying the critical_examples variable in > plplot_test/plplot-test.sh.cmake to include example 29 for the Windows > case? > > I will respond off list to the detailed output results you sent me. > > 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 > __________________________ > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <arj...@de...> - 2010-12-07 12:14:01
|
Hi Alan, I changed the value of the "results" variable in test_tcl.sh.in to "${OUTPUT_DIR}" and it worked fine. Except that the Tcl results do not show up in the summary. Odd. Regards, Arjen On 2010-12-07 08:53, Arjen Markus wrote: > Hi Alan, > > thanks for reviewing these messages. I have worked on plstring > and plstring3 for Fortran and Tcl, but not everything is done > yet. pllegend is more of a challenge as it uses an aray of strings > - the first occurrence as far as I am aware of that in PLplot. > Anyway, I should be able to take care of that in the coming few > weeks. > > I will add example 29 to the mix. That poses no particular > challenges. > > As for Tcl example x14, I printed the command that is used for > Tcl and C and it turns out that for C the name of the second file to > be written is "./examples/x14ac.psc", whereas for Tcl the whole path > is included - > /D/plplot-svn/plplot/comprehensive_test_disposeable/shared/build_tree/examples/x14at%n.psc > Could that be too long? (I have not checked it ...) I do not understand > yet why we have this difference - oh: test_c uses ${OUTPUT_DIR} and > test_tcl uses ${results}. I will change this and see what happens. > > Regards, > > Arjen > > On 2010-12-06 20:53, Alan W. Irwin wrote: >> On 2010-12-06 10:36+0100 Arjen Markus wrote: >> >>> Hi Alan, >>> >>> here is the summary of that test: >>> >>> C example 29 is missing >>> c++ >>> Missing examples : 33 >>> Differing postscript output : 04 18 26 >>> Missing stdout : >>> Differing stdout : >>> C example 29 is missing >>> f77 >>> Missing examples : 33 >>> Differing postscript output : 04 09 14a 18 26 >>> Missing stdout : >>> Differing stdout : >>> C example 29 is missing >>> f95 >>> Missing examples : 33 >>> Differing postscript output : 04 18 26 >>> Missing stdout : >>> Differing stdout : >>> WARNING: Some PostScript or stdout results were different >> That's a most encouraging result. The missing 33 and differing 4, 18, >> and 26 results occur on Linux as well at the moment. Propagation of >> plstring, plstring3, and pllegend to C++, f77, and f95 bindings and >> propagating C example 33 to those languages should solve those >> problems. I don't know what is going on with 9 and 14a for f77 on >> Windows, but I assume you can figure that out by running the various >> examples by hand. >> >> Important: The "C example 29 is missing" message above is a left over >> from when we excluded example 29 in the Windows case because we didn't >> have time functionality that was suitable for that platform. But now >> example 29 should work fine on Windows because you appear to be >> building the qsastime library without issues. Could you test example >> 29 on Windows by modifying the critical_examples variable in >> plplot_test/plplot-test.sh.cmake to include example 29 for the Windows >> case? >> >> I will respond off list to the detailed output results you sent me. >> >> 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 >> __________________________ >> > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2010-12-07 16:41:06
|
On 2010-12-07 13:13+0100 Arjen Markus wrote: > Hi Alan, > > I changed the value of the "results" variable in test_tcl.sh.in > to "${OUTPUT_DIR}" and it worked fine. Except that the Tcl results > do not show up in the summary. Odd. One other curiosity. If you look higher in test_tcl.sh(.in) you find the following shell commands: cd "${OUTPUT_DIR}" results="`pwd`" export results So ${results} should normally refer to the same directory as ${OUTPUT_DIR}. However, the pwd command always returns absolute results so therefore ${results} is absolute as well, while ${OUTPUT_DIR} is relative if I recall correctly. So your earlier idea that ${results} refers to a pathname too long for Windows to handle _might_ be the explanation of why ${OUTPUT_DIR} works but ${results} does not. On the other hand, the thread starting at http://lists-archives.org/mingw-users/18294-msys-bash-maximum-length-of-command-line-arguments.html indicates the Windows pathname limit is 8191 characters, and in any case we are using bash here which that thread implies has even a longer pathname limit. I have no explanation of why the Tcl results are not showing up in the summary except possibly they are put into the wrong directory. Maybe the absolute pathname really is needed? I will look further at all of this once I have downloaded and installed everything I need (including Tcl) to do a thorough test of PLplot under wine. 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 __________________________ |