From: Alan W. I. <ir...@be...> - 2007-11-08 18:56:44
|
I have just bought a new PC and installed Debian testing on it. Thus, I was anxious to know how fast the new PC was for building PLplot, and whether the svn trunk version of PLplot has any bugs for this 64-bit Linux system that would be showstoppers for the 5.8.0 release. There were some initial minor fixes that had to be done (see recent commits up to and including revision 8015) in order for the following build to work. software@raven> time cmake -DCMAKE_INSTALL_PREFIX=/home/software/plplot_cvs/installcmake -DCMAKE_VERBOSE_MAKEFILE=ON -DENABLE_ada=ON -DBUILD_TEST=ON -DENABLE_pygcw=OFF ../plplot_cmake >& cmake.out real 0m4.225s user 0m3.032s sys 0m1.152s software@raven> time make >& make.out real 0m52.774s user 0m43.395s sys 0m8.577s The conclusion from these elapsed times is the new system is extremely fast. Note, this is a fully loaded build of PLplot (almost all components were built), and all examples were built as well (which roughly doubles the build time). Actually, the new system's CPU's do not have that high a clock rate ("only" 2.33GHz), but I believe I am getting these greatly improved PLplot build speeds from much improved cache size (4MB), memory bandwidth (1333MHz FSB), disk cache size (16MB) and disk speed (measured at roughly 100MB/s for reads or writes) for the new system compared to my old system. In the future, I expect the build time to decrease by a factor of two when I use the -j2 option since I have a dual CPU, but in the past there has been trouble with that option so I have not tested it yet. The above build had no obvious problems. I did have to specify -DENABLE_pygcw=OFF because Debian testing has not yet incorporated a bug fix into the python-gtk2 package that is already in Fedora. I will agitate on Debian to get the bug fixed there as well. ctest results showed there are problems in the build tree for the Debian testing platform. software@raven> time ctest Start processing tests Test project /home/software/plplot_cvs/HEAD/build_dir 1/ 11 Testing examples_c Passed 2/ 11 Testing examples_cxx Passed 3/ 11 Testing examples_f77 Passed 4/ 11 Testing examples_f95 Passed 5/ 11 Testing examples_java ***Failed 6/ 11 Testing examples_octave Passed 7/ 11 Testing examples_python Passed 8/ 11 Testing examples_tcl ***Failed 9/ 11 Testing examples_ada Passed 10/ 11 Testing examples_svg Passed 11/ 11 Testing examples_pscairo Passed 82% tests passed, 2 tests failed out of 11 The following tests FAILED: 5 - examples_java (Failed) 8 - examples_tcl (Failed) Errors while running CTest real 0m36.762s user 0m27.850s sys 0m2.088s Clearly, there are problems with at least java and tcl on Debian testing. Andrew, do you see similar errors on your Ubuntu systems? Geoffrey, welcome back to PLplot development! You are one of our most knowledgeable Tcl developers, and it appears you are now completely up to speed with PLplot builds again. Could you please run the above ctest on the trunk version (not the branch where you have been committing recently) of Plplot to see whether you can confirm the tcl error? You will need the -DBUILD_TEST=ON option in order for ctest to work. Try "ctest --help-full" to see documentation of some options for more verbose output, just doing one of the tests, etc. Over the next few days I plan to investigate the java and tcl errors further, test whether make -j2 works, test whether I can build the PLplot documentation, and do some install-tree testing. Hazen, I suggest we continue to keep the 5.8.0 release on hold to give me time to solve the above java and tcl errors on Debian testing (hopefully with some help from Geoffrey on the tcl issue if he sees it on his platform), give us time to deal with any additional errors I find due to the above planned testing, and also to give you time to solve the fortran, java, and octave issues you have found on Mac OS X. 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...> - 2007-11-09 01:00:08
Attachments:
make.out.gz
|
On 2007-11-08 10:57-0800 Alan W. Irwin wrote: > software@raven> time cmake > -DCMAKE_INSTALL_PREFIX=3D/home/software/plplot_cvs/installcmake > -DCMAKE_VERBOSE_MAKEFILE=3DON -DENABLE_ada=3DON -DBUILD_TEST=3DON > -DENABLE_pygcw=3DOFF ../plplot_cmake >& cmake.out I forgot to mention with the above configuration options, and g++ --version g++ (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3) there were a number of compilation warnings of a particular type for the build. For exact details of all these warnings, see the attached compresse= d make.out file. To summarize, the warning message was warning: deprecated conversion from string constant to =E2=80=98char*=E2=80= =99 and it occurred for bindings/wxwidgets/wxPLplotstream.cpp: line 66 drivers/wxwidgets.cpp: lines 160 (21 times), 382, 563 (6 times), 1475, 1620= , and 1746 Werner, could you take care of this please? This warning message also occurred in a large subset of the C++ examples. Andrew, could you take care of at least some of these warnings working from the low numbers to the high numbers? Once I see one of your commits tellin= g how to deal with the problem, I could work from the high numbers down to give you a hand cleaning this up. 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: Andrew R. <and...@us...> - 2007-11-14 18:14:40
|
On Thu, Nov 08, 2007 at 05:00:28PM -0800, Alan Irwin wrote: > On 2007-11-08 10:57-0800 Alan W. Irwin wrote: > > To summarize, the warning message was > > warning: deprecated conversion from string constant to ???char*??? > > and it occurred for > > bindings/wxwidgets/wxPLplotstream.cpp: line 66 > > drivers/wxwidgets.cpp: lines 160 (21 times), 382, 563 (6 times), 1475, 1620, > and 1746 > > Werner, could you take care of this please? > > This warning message also occurred in a large subset of the C++ examples. > > Andrew, could you take care of at least some of these warnings working from > the low numbers to the high numbers? Once I see one of your commits telling > how to deal with the problem, I could work from the high numbers down to > give you a hand cleaning this up. I've tested with g++-4.2 under Ubuntu and found the same. I've got patches to correct all these problems (except for wxwidgets which I've left to Werner). This is quite intrusive though and involves making several char * arguments in the API into const char *. We've been inconsistent about this in the past. For example labels are constant, but char * arguments in the command line parsing are not. None of these text string are modified by the functions and so they probably should be const. Changed API functions are plmap plstripc plParseOpts plSetOpt plparseopts plsetopt plMergeOpts plsabort plsexit and also the definition of the PLOptionTable structure. Are people happy for me to commit this? The other option is lots of explicit casting of (const char *) to (char *) which is not pretty. Andrew |
From: Arjen M. <arj...@wl...> - 2007-11-09 07:30:08
|
Alan W. Irwin wrote: >I have just bought a new PC and installed Debian testing on it. Thus, I was >anxious to know how fast the new PC was for building PLplot, and whether the >svn trunk version of PLplot has any bugs for this 64-bit Linux system that >would be showstoppers for the 5.8.0 release. > > Hello, I am not sure whether they should count as showstoppers, but I found a few issues on the bare Windows platform that I want to communicate: - When I built the FORTRAN 77 bindings with CVF and shared libraries (DLLs) on, I get a lot of unresolved externals. (And so the build ends there) - When I exclude FORTRAN 77, things look much brighter, but example x28f for Fortran 95 gives an error on plmtex3. I suspect that the routines are not properly exported (necessary on bare Windows), so I will look into that. Regards, Arjen |
From: Andrew R. <and...@us...> - 2007-11-11 22:19:04
|
Alan, I don't see these with the latest stable Ubuntu. The latest debian packages have now made it into unstable. To run ctest with the tcl bindings required setting ITCL_LIBRARY (see debian/rules for details). Rafael discovered this, but we don't yet know why. The java packages build ok in the debian packages so you might like to check which java you are using. We're building with kaffe. Andrew On Thu, Nov 08, 2007 at 10:57:32AM -0800, Alan Irwin wrote: > I have just bought a new PC and installed Debian testing on it. Thus, I was > anxious to know how fast the new PC was for building PLplot, and whether the > svn trunk version of PLplot has any bugs for this 64-bit Linux system that > would be showstoppers for the 5.8.0 release. > > There were some initial minor fixes that had to be done (see recent commits > up to and including revision 8015) in order for the following build to > work. > > software@raven> time cmake > -DCMAKE_INSTALL_PREFIX=/home/software/plplot_cvs/installcmake > -DCMAKE_VERBOSE_MAKEFILE=ON -DENABLE_ada=ON -DBUILD_TEST=ON > -DENABLE_pygcw=OFF ../plplot_cmake >& cmake.out > > real 0m4.225s > user 0m3.032s > sys 0m1.152s > > software@raven> time make >& make.out > > real 0m52.774s > user 0m43.395s > sys 0m8.577s > > The conclusion from these elapsed times is the new system is extremely fast. > Note, this is a fully loaded build of PLplot (almost all components were > built), and all examples were built as well (which roughly doubles the build > time). Actually, the new system's CPU's do not have that high a clock rate > ("only" 2.33GHz), but I believe I am getting these greatly improved PLplot > build speeds from much improved cache size (4MB), memory bandwidth (1333MHz > FSB), disk cache size (16MB) and disk speed (measured at roughly 100MB/s for > reads or writes) for the new system compared to my old system. > > In the future, I expect the build time to decrease by a factor of two when I > use the -j2 option since I have a dual CPU, but in the past there has been > trouble with that option so I have not tested it yet. > > The above build had no obvious problems. I did have to specify > -DENABLE_pygcw=OFF because Debian testing has not yet incorporated a bug fix > into the python-gtk2 package that is already in Fedora. I will agitate on > Debian to get the bug fixed there as well. > > ctest results showed there are problems in the build tree for the > Debian testing platform. > > software@raven> time ctest > Start processing tests > Test project /home/software/plplot_cvs/HEAD/build_dir > 1/ 11 Testing examples_c Passed > 2/ 11 Testing examples_cxx Passed > 3/ 11 Testing examples_f77 Passed > 4/ 11 Testing examples_f95 Passed > 5/ 11 Testing examples_java ***Failed > 6/ 11 Testing examples_octave Passed > 7/ 11 Testing examples_python Passed > 8/ 11 Testing examples_tcl ***Failed > 9/ 11 Testing examples_ada Passed > 10/ 11 Testing examples_svg Passed > 11/ 11 Testing examples_pscairo Passed > > 82% tests passed, 2 tests failed out of 11 > > The following tests FAILED: > 5 - examples_java (Failed) > 8 - examples_tcl (Failed) > Errors while running CTest > > real 0m36.762s > user 0m27.850s > sys 0m2.088s > > Clearly, there are problems with at least java and tcl on Debian testing. > > Andrew, do you see similar errors on your Ubuntu systems? > > Geoffrey, welcome back to PLplot development! You are one of our most > knowledgeable Tcl developers, and it appears you are now completely up to > speed with PLplot builds again. Could you please run the above ctest on the > trunk version (not the branch where you have been committing recently) of > Plplot to see whether you can confirm the tcl error? You will need the > -DBUILD_TEST=ON option in order for ctest to work. Try "ctest --help-full" > to see documentation of some options for more verbose output, just doing one > of the tests, etc. > > Over the next few days I plan to investigate the java and tcl errors > further, test whether make -j2 works, test whether I can build the PLplot > documentation, and do some install-tree testing. > > Hazen, I suggest we continue to keep the 5.8.0 release on hold to give me > time to solve the above java and tcl errors on Debian testing (hopefully > with some help from Geoffrey on the tcl issue if he sees it on his > platform), give us time to deal with any additional errors I find due to the > above planned testing, and also to give you time to solve the fortran, java, > and octave issues you have found on Mac OS X. > > 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 > __________________________ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2007-11-12 00:10:17
|
On 2007-11-11 22:18-0000 Andrew Ross wrote: > > Alan, > > I don't see these with the latest stable Ubuntu. The latest debian > packages have now made it into unstable. > > To run ctest with the tcl bindings required setting ITCL_LIBRARY (see > debian/rules for details). Rafael discovered this, but we don't yet > know why. I will look into that also. > > The java packages build ok in the debian packages so you might like to > check which java you are using. We're building with kaffe. I am trying the free-java-sdk package. Perhaps there is some Debian bug with it. What I have been focussing on at the moment, is the necessity of having to specify -DENABLE_pygcw=OFF with Debian testing. Otherwise, I get the following error. [ 21%] Generating cplplotcanvas.c cd /home/software/plplot_cvs/HEAD/build_dir/bindings/gnome2/python && pygtk-code gen-2.0 --prefix cplplotcanvas --register /usr/share/pygtk/2.0/defs/gdk.defs --register /usr/share/pygtk/2.0/defs/gtk.defs --register /usr/share/pygtk/2.0/defs/gnome.defs --register /usr/share/pygtk/2.0/defs/canvas.defs --override /home/software/plplot_cvs/HEAD/plplot_cmake/bindings/gnome2/python/cplplotcanvas.override /home/software/plplot_cvs/HEAD/build_dir/bindings/gnome2/python/plplotcanvas.defs > /home/software/plplot_cvs/HEAD/build_dir/bindings/gnome2/python/cplplotcanvas.c Traceback (most recent call last): File "/usr/share/pygtk/2.0/codegen/codegen.py", line 1712, in ? sys.exit(main(sys.argv)) File "/usr/share/pygtk/2.0/codegen/codegen.py", line 1670, in main p.startParsing() File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 114, in startParsing self.handle(statement) File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 118, in handle getattr(self, cmd)(*tup[1:]) File "/usr/share/pygtk/2.0/codegen/defsparser.py", line 29, in include self.startParsing() File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 114, in startParsing self.handle(statement) File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 118, in handle getattr(self, cmd)(*tup[1:]) File "/usr/share/pygtk/2.0/codegen/defsparser.py", line 33, in include raise IOError("%s not found in include path %s" % (input_filename, inc_path)) IOError: gtk-extrafuncs.defs not found in include path ['/usr/share/pygtk/2.0/defs', '.'] make[2]: *** [bindings/gnome2/python/cplplotcanvas.c] Error 1 make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/build_dir' make[1]: *** [bindings/gnome2/python/CMakeFiles/cplplotcanvasmodule.dir/all] Error 2 This is on debian testing which has no file named gtk-extrafuncs.defs. I suspect there is some upstream error with python-gtk2. There is mention of this bug being fixed in ubuntu, but nothing about it upstream or in debian. BTW, in Debian unstable there is a file called gtk-extrafuncs.defs, but it is in quite a different package, and may be some local fixup for that package for the python-gtk2 packaging bug. Anyhow, Andrew, I am not quite sure whether to submit a Debian bug report for python-gtk2 or not and would appreciate your advice on this. 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: Andrew R. <and...@us...> - 2007-11-12 22:27:57
|
On Sun, Nov 11, 2007 at 04:11:26PM -0800, Alan Irwin wrote: > On 2007-11-11 22:18-0000 Andrew Ross wrote: > > > > > Alan, > > > > I don't see these with the latest stable Ubuntu. The latest debian > > packages have now made it into unstable. > > > > To run ctest with the tcl bindings required setting ITCL_LIBRARY (see > > debian/rules for details). Rafael discovered this, but we don't yet > > know why. > > I will look into that also. > > > > > The java packages build ok in the debian packages so you might like to > > check which java you are using. We're building with kaffe. > > I am trying the free-java-sdk package. Perhaps there is some Debian > bug with it. Actually, I've just seen the build logs today and there are java problems on some architectures too so you may not be alone. > What I have been focussing on at the moment, is the necessity of having to > specify -DENABLE_pygcw=OFF with Debian testing. Otherwise, I get the > following error. > > [ 21%] Generating cplplotcanvas.c > cd /home/software/plplot_cvs/HEAD/build_dir/bindings/gnome2/python && pygtk-code > gen-2.0 --prefix cplplotcanvas --register /usr/share/pygtk/2.0/defs/gdk.defs --register /usr/share/pygtk/2.0/defs/gtk.defs --register /usr/share/pygtk/2.0/defs/gnome.defs --register /usr/share/pygtk/2.0/defs/canvas.defs --override /home/software/plplot_cvs/HEAD/plplot_cmake/bindings/gnome2/python/cplplotcanvas.override /home/software/plplot_cvs/HEAD/build_dir/bindings/gnome2/python/plplotcanvas.defs > /home/software/plplot_cvs/HEAD/build_dir/bindings/gnome2/python/cplplotcanvas.c > Traceback (most recent call last): > File "/usr/share/pygtk/2.0/codegen/codegen.py", line 1712, in ? > sys.exit(main(sys.argv)) > File "/usr/share/pygtk/2.0/codegen/codegen.py", line 1670, in main > p.startParsing() > File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 114, in startParsing > self.handle(statement) > File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 118, in handle > getattr(self, cmd)(*tup[1:]) > File "/usr/share/pygtk/2.0/codegen/defsparser.py", line 29, in include > self.startParsing() > File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 114, in startParsing > self.handle(statement) > File "/usr/share/pygtk/2.0/codegen/scmexpr.py", line 118, in handle > getattr(self, cmd)(*tup[1:]) > File "/usr/share/pygtk/2.0/codegen/defsparser.py", line 33, in include > raise IOError("%s not found in include path %s" % (input_filename, inc_path)) > IOError: gtk-extrafuncs.defs not found in include path ['/usr/share/pygtk/2.0/defs', '.'] > make[2]: *** [bindings/gnome2/python/cplplotcanvas.c] Error 1 > make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/build_dir' > make[1]: *** [bindings/gnome2/python/CMakeFiles/cplplotcanvasmodule.dir/all] Error 2 > > This is on debian testing which has no file named gtk-extrafuncs.defs. I > suspect there is some upstream error with python-gtk2. There is mention of > this bug being fixed in ubuntu, but nothing about it upstream or in > debian. Alan, this has been a long running problem on Ubuntu as well as I recall. I had forgotten that I just created this file as a blank file and everything worked ok. > BTW, in Debian unstable there is a file called gtk-extrafuncs.defs, but it > is in quite a different package, and may be some local fixup for that > package for the python-gtk2 packaging bug. Anyhow, Andrew, I am not quite > sure whether to submit a Debian bug report for python-gtk2 or not and would > appreciate your advice on this. I will look into this further. Andrew |
From: Andrew R. <and...@us...> - 2007-11-14 13:55:22
|
On Mon, Nov 12, 2007 at 10:27:28PM +0000, Andrew Ross wrote: > On Sun, Nov 11, 2007 at 04:11:26PM -0800, Alan Irwin wrote: > > > > I am trying the free-java-sdk package. Perhaps there is some Debian > > bug with it. > > Actually, I've just seen the build logs today and there are java > problems on some architectures too so you may not be alone. OK. Some testing on Ubuntu Gutsy (latest stable). Building with jikes-kaffe works fine on i386 / amd64 architectures. ctest passes with blackdown java j2re1.4. ctest passes with gij-4.2. ctest passes with java-sun5-sdk ctest fails on example 21 with kaffe with the error FATAL ERROR: No more room for local references I believe this issue has been around for a while and is related to the way swig passes data around. I've tried a couple of things to alleviate the problem but with limited success. My knowledge of java memory allocation and garbage collection is a little limited though... ctest fails on example 8 using sablevm with the error sablevm: INTERNAL ERROR (source file "native_interface.c", function "GetBooleanArrayElements", line 25011): todo Checking the source, this is not implemented in this version of sablevm, although it is part of the standard JNI. Any functions using arrays of boolean types will not work with sablevm. Alan, can you confirm this is your version of sablevm? So from a free point of view it looks like the best option for now is to use the gij version of java, or if your conscience allows go for one of the versions based on Sun's sdk. Andrew |
From: Alan W. I. <ir...@be...> - 2007-11-14 21:31:39
|
On 2007-11-14 13:54-0000 Andrew Ross wrote: > On Mon, Nov 12, 2007 at 10:27:28PM +0000, Andrew Ross wrote: >> On Sun, Nov 11, 2007 at 04:11:26PM -0800, Alan Irwin wrote: >>> >>> I am trying the free-java-sdk package. Perhaps there is some Debian >>> bug with it. >> >> Actually, I've just seen the build logs today and there are java >> problems on some architectures too so you may not be alone. > > OK. Some testing on Ubuntu Gutsy (latest stable). > > Building with jikes-kaffe works fine on i386 / amd64 architectures. > > ctest passes with blackdown java j2re1.4. > ctest passes with gij-4.2. > ctest passes with java-sun5-sdk > > ctest fails on example 21 with kaffe with the error > FATAL ERROR: No more room for local references > > I believe this issue has been around for a while and is related to the > way swig passes data around. I've tried a couple of things to alleviate > the problem but with limited success. My knowledge of java memory > allocation and garbage collection is a little limited though... > > ctest fails on example 8 using sablevm with the error > sablevm: INTERNAL ERROR (source file "native_interface.c", function > "GetBooleanArrayElements", line 25011): todo > Checking the source, this is not implemented in this version of sablevm, > although it is part of the standard JNI. Any functions using arrays of > boolean types will not work with sablevm. Alan, can you confirm this is > your version of sablevm? You didn't mention the sablevm package version you were running. Mine is 1.13-1.1. I can confirm for that version that the build works fine, but ctest fails with exactly the above error message so I think you must have the same (limited) version. > > So from a free point of view it looks like the best option for now is to > use the gij version of java, or if your conscience allows go for one of > the versions based on Sun's sdk. Here is my assessment of PLplot java on Debian/Ubuntu. You have proved three different java implementations build and ctest fine, and two others (jikes-kaffe and free-java-sdk which depends on jikes-sablevm and sablevm) build fine, but have ctest problems. I believe that shows there are deficiencies in the kaffe and sablevm java virtual machine implementations which you should avoid by putting in specific build and run-time dependences in your Debian packages. For now, I am following my own advice. I have just run apt-get --purge remove free-java-sdk apt-get autoremove #To remove free-java-sdk dependencies apt-get install gij, gcj, fastjar One of the dependencies of gij is libgcj8-dev. That installs jni.h in /usr/lib/gcc/x86_64-linux-gnu/4.2/include for some strange reason. About a zillion different Debian packages provide jni.h (some of them in more standard locations). But if you do not have those other packages installed, then you must export CMAKE_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.2/include (or whatever is appropriate for your hardware platform) to get gij to work. After I made the above changes, java built and passed ctest without issues. Furthermore, if you run (for INDEX in ls x*j.psc |sed -e "s?x??" -e "s?j.psc??"; do echo $INDEX; \ diff x${INDEX}[cj].psc; done) |less in the test directory you will see all java examples give the same results as the C examples except for example 21 (which you may have mentioned before). To summarize the Java issues: (1) Doesn't ctest on some Debian java platforms. Andrew, could you please file the appropriate Debian bug reports for kaffe and sablevm? I also suggest you change the Debian dependencies in the Debian packaging effort you are in charge of to avoid those platforms, but that (downstream) packaging effort is not critical to our (upstream) release. (2) Example 21 does not produce results that are consistent with the C results. If you cannot come up with any quick fixes, that is something we can deal with post-release. (3) The library naming problem Hazen found on Mac OS X (see his recent post to this list). To my mind that is the only release-critical issue left for Java. Andrew, can you come up with a quick CMake fix for that? 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: Andrew R. <and...@us...> - 2007-11-14 22:52:32
|
On Wed, Nov 14, 2007 at 01:33:05PM -0800, Alan Irwin wrote: > On 2007-11-14 13:54-0000 Andrew Ross wrote: > > You didn't mention the sablevm package version you were running. Mine is > 1.13-1.1. I can confirm for that version that the build works fine, but > ctest fails with exactly the above error message so I think you must have > the same (limited) version. > > > > >So from a free point of view it looks like the best option for now is to > >use the gij version of java, or if your conscience allows go for one of > >the versions based on Sun's sdk. > > Here is my assessment of PLplot java on Debian/Ubuntu. You have proved > three different java implementations build and ctest fine, and two others > (jikes-kaffe and free-java-sdk which depends on jikes-sablevm and sablevm) > build fine, but have ctest problems. I believe that shows there are > deficiencies in the kaffe and sablevm java virtual machine implementations > which you should avoid by putting in specific build and run-time dependences > in your Debian packages. > > For now, I am following my own advice. I have just run > > apt-get --purge remove free-java-sdk > apt-get autoremove #To remove free-java-sdk dependencies > apt-get install gij, gcj, fastjar You might like to look at the java-gcj-compat and java-gcj-compat-dev packages which bundle all this together with symlinks and scripts to provide a java sdk like environment. > > One of the dependencies of gij is libgcj8-dev. That installs jni.h in > /usr/lib/gcc/x86_64-linux-gnu/4.2/include for some strange reason. About a > zillion different Debian packages provide jni.h (some of them in more > standard locations). But if you do not have those other packages installed, > then you must > > export CMAKE_INCLUDE_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.2/include > > (or whatever is appropriate for your hardware platform) to get gij to work. The whole jni thing is a mess. Automatically finding this is not easy. There seems to be little consistency. I'd rather see things in package` specific directories so you can switch between java compilers just by changing JAVA_HOME. Alas this is not to be.... > > After I made the above changes, java built and passed ctest without issues. > Furthermore, if you run > > (for INDEX in ls x*j.psc |sed -e "s?x??" -e "s?j.psc??"; do echo $INDEX; \ > diff x${INDEX}[cj].psc; done) |less > > in the test directory you will see all java examples give the same results > as the C examples except for example 21 (which you may have mentioned > before). > > To summarize the Java issues: > > (1) Doesn't ctest on some Debian java platforms. Andrew, could you please > file the appropriate Debian bug reports for kaffe and sablevm? I also > suggest you change the Debian dependencies in the Debian packaging effort > you are in charge of to avoid those platforms, but that (downstream) > packaging effort is not critical to our (upstream) release. On my list to do. > (2) Example 21 does not produce results that are consistent with the C > results. If you cannot come up with any quick fixes, that is something we > can deal with post-release. I'll take a look. Are you sure this is not just the fact that example 21 has a randomly generated data set in it? > (3) The library naming problem Hazen found on Mac OS X (see his recent post > to this list). To my mind that is the only release-critical issue left for > Java. Andrew, can you come up with a quick CMake fix for that? Hm. I'll have a think. Andrew |
From: Alan W. I. <ir...@be...> - 2007-11-14 22:30:44
|
On 2007-11-14 18:13-0000 Andrew Ross wrote: > On Thu, Nov 08, 2007 at 05:00:28PM -0800, Alan Irwin wrote: >> On 2007-11-08 10:57-0800 Alan W. Irwin wrote: >> >> To summarize, the warning message was >> >> warning: deprecated conversion from string constant to ???char*??? >> >> and it occurred for >> >> bindings/wxwidgets/wxPLplotstream.cpp: line 66 >> >> drivers/wxwidgets.cpp: lines 160 (21 times), 382, 563 (6 times), 1475, 1620, >> and 1746 >> >> Werner, could you take care of this please? >> >> This warning message also occurred in a large subset of the C++ examples. >> >> Andrew, could you take care of at least some of these warnings working from >> the low numbers to the high numbers? Once I see one of your commits telling >> how to deal with the problem, I could work from the high numbers down to >> give you a hand cleaning this up. > > I've tested with g++-4.2 under Ubuntu and found the same. > > I've got patches to correct all these problems (except for wxwidgets > which I've left to Werner). This is quite intrusive though and involves > making several char * arguments in the API into const char *. We've been > inconsistent about this in the past. For example labels are constant, > but char * arguments in the command line parsing are not. None of these > text string are modified by the functions and so they probably should be > const. > > Changed API functions are > plmap > plstripc > plParseOpts > plSetOpt > plparseopts > plsetopt > plMergeOpts > plsabort > plsexit > > and also the definition of the PLOptionTable structure. > > Are people happy for me to commit this? > > The other option is lots of explicit casting of (const char *) to (char > *) which is not pretty. I like the idea of changing to a more consistent API. However, the timing of this just before a stable release is a concern. So I suggest living with the warning messages for now and holding back your API changes until just after the stable release. Also, at that time we should do everything right with such a backwards-incompatible API change. Warn of the API change in the 5.9.0 (developmental) release announcement, bump major library soname numbers appropriately, etc. In my view, the dust should settle quite nicely from this API change by the time of our next stable release (5.10.0), if the API changes are introduced immediately after this stable release. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2007-11-14 23:00:26
|
On Wed, Nov 14, 2007 at 02:27:12PM -0800, Alan Irwin wrote: > On 2007-11-14 18:13-0000 Andrew Ross wrote: > > > I've tested with g++-4.2 under Ubuntu and found the same. > > > > I've got patches to correct all these problems (except for wxwidgets > > which I've left to Werner). This is quite intrusive though and involves > > making several char * arguments in the API into const char *. We've been > > inconsistent about this in the past. For example labels are constant, > > but char * arguments in the command line parsing are not. None of these > > text string are modified by the functions and so they probably should be > > const. > > > > Changed API functions are > > plmap > > plstripc > > plParseOpts > > plSetOpt > > plparseopts > > plsetopt > > plMergeOpts > > plsabort > > plsexit > > > > and also the definition of the PLOptionTable structure. > > > > Are people happy for me to commit this? > > > > The other option is lots of explicit casting of (const char *) to (char > > *) which is not pretty. > > I like the idea of changing to a more consistent API. However, the timing of > this just before a stable release is a concern. So I suggest living with > the warning messages for now and holding back your API changes until just > after the stable release. Also, at that time we should do everything right > with such a backwards-incompatible API change. Warn of the API change in > the 5.9.0 (developmental) release announcement, bump major library soname > numbers appropriately, etc. In my view, the dust should settle quite nicely > from this API change by the time of our next stable release (5.10.0), if the > API changes are introduced immediately after this stable release. That was my view too. I'll leave this until after the 5.8.0 release. Andrew |
From: Alan W. I. <ir...@be...> - 2007-11-15 03:01:01
|
On 2007-11-14 22:48-0000 Andrew Ross wrote: > On Wed, Nov 14, 2007 at 01:33:05PM -0800, Alan Irwin wrote: >> To summarize the Java issues: >> (2) Example 21 does not produce results that are consistent with the C >> results. If you cannot come up with any quick fixes, that is something we >> can deal with post-release. > > I'll take a look. Are you sure this is not just the fact that example 21 > has a randomly generated data set in it? You are right. I should not have even bothered with the 21st example comparison because of different random number generators for different languages as well as execution times in the plot labels which are also different between languages. Sorry for the noise. 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...> - 2007-11-15 06:19:53
|
On 2007-11-11 22:18-0000 Andrew Ross wrote: > To run ctest with the tcl bindings required setting ITCL_LIBRARY (see > debian/rules for details). Rafael discovered this, but we don't yet > know why. Thanks for the tip. The explicit error message (for each tcl application) was Testing front-end tcl application-specific initialization failed: Can't find a usable itcl.tcl in the following directories: /usr/share/tcltk/itcl3.2 /home/software/plplot_cvs/HEAD/build_dir/examples/../utils/../lib/itcl3.2 /home/software/plplot_cvs/HEAD/build_dir/examples/../utils/../library /home/software/plplot_cvs/HEAD/build_dir/examples/../utils/../../library /home/software/plplot_cvs/HEAD/build_dir/examples/../utils/../../itcl/library /home/software/plplot_cvs/HEAD/build_dir/examples/../utils/../../../itcl/library This probably means that Itcl/Tcl weren't installed properly. If you know where the Itcl library directory was installed, you can set the environment variable ITCL_LIBRARY to point to the library directory. invalid command name "plinit" invalid command name "plgdev" invalid command name "plgdev" invalid command name "plgdev" invalid command name "plgdev" I then followed those directions and set export ITCL_LIBRARY=/usr/lib/itcl3.2 which is the directory where itcl.tcl is installed on Debian testing (and also debian oldstable, debian stable, and debian unstable). So there is nothing wrong with the install location. Furthermore, there were no such problems finding itcl.tcl when I built all the tcl stuff and ctested it on debian oldstable. Thus, the likely cause of this problem is that the itcl3 package for Debian testing has been misconfigured compared to Debian oldstable. Andrew, what is the Ubuntu story? Do you have the same trouble finding itcl.tcl there? Or is this strictly a problem limited to certain Debian distros (not oldstable, maybe stable, definitely testing, and [from Rafael's and your experience] unstable as well). 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: Andrew R. <and...@us...> - 2007-11-15 07:56:52
|
On Wed, Nov 14, 2007 at 10:21:20PM -0800, Alan Irwin wrote: > > Thus, the likely cause of this problem is that the itcl3 package for Debian > testing has been misconfigured compared to Debian oldstable. > > Andrew, what is the Ubuntu story? Do you have the same trouble finding > itcl.tcl there? Or is this strictly a problem limited to certain Debian > distros (not oldstable, maybe stable, definitely testing, and [from Rafael's > and your experience] unstable as well). Alan, I don't see this on Ubuntu Gutsy (with ictl3 version 3.2.1-3.1) so this must be a recent Debian problem. This makes it hard for me to investigate. Andrew |
From: Werner S. <sm...@ia...> - 2007-11-16 07:57:24
|
Hi Andrew, > I don't see this on Ubuntu Gutsy (with ictl3 version 3.2.1-3.1) so > this > must be a recent Debian problem. This makes it hard for me to > investigate. If your computer is not that old, if you have enough ram (>1GB) and some harddisk space (10GB is enough) to spare you might consider a virtual machine. A really good, free and opensource one is VirtualBox http://www.virtualbox.org/ Nowadays the virtual machines run very close to the speed of the host computer. You can therefore use them exactly for that purpose: test code on several platforms. And there are many nice features, like e.g. snapshots (you can recall the exact state of a machine any time in the future). Very useful for development. Regards, Werner PS: There are many others like VirtualPC, VMWare, parallels, Qemu, Bochs, etc. but VirtualBox runs fine on linux, is fast and free. -- Dipl. Ing. 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 |