From: Alan W. I. <ir...@be...> - 2004-06-13 04:18:08
|
I have been distracted from PLplot for the last few weeks because of a massive (two boxes for my local LUG as well as my own new box) hardware and software upgrade, but finally today I was able to try out a PLplot build on my new Debian testing distro and faster (2.4GHz CPU) hardware. This distro is much more up to date then the ancient Debian stable distro I was using before. For example, I am using the latest stable autotools (autoconf-2.59, automake-1.8.5, and libtool-1.5.6) as provided by default with Debian testing and not specially downloaded like I did before. There has been a delay promoting the latest swig (swig-1.3.21) from unstable to testing so in that case I used the unstable version. With octave enabled my first build attempt failed with the following error message: ... Perl modules not available: cannot generate full online help for plplot_octave ./massage >> plplot_stub.m 2> missing_help make[4]: *** [plplot_stub.m] Error 1 make[4]: Leaving directory /home/software/plplot_cvs/HEAD/plplot_working/bindings/octave' ... If I look at missing_help it has a single line plplot.doc not found:: No such file or directory There was a fairly obvious logic error involving plplot.doc in Makefile.am when perl modules were missing. After I fixed that issue, my build of PLplot finished with no errors so I committed the change. Looking at my configuration messages, the missing modules were XML::DOM and XML::Parser. I will try installing those and report back any failure/success I have with the usual plplot-test.sh script. It's nice to be on the air again (although I still won't be able to spend a lot of time on PLplot for a while because of other commitments). Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), 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...> - 2004-06-13 07:32:54
|
Installing and testing the installed examples of PLplot on Debian testing had mixed results: plplot-test.sh works for the c, cxx, f77, python, and tcl front ends. (I am sure Rafael confirms these good results also on his Debian testing system, but it is nice to get them myself.) plplot-test.sh does not work for java or octave. In the java case (which I don't think anyone else has tried on Linux) there seems to be a massive memory leak associated with the java command from the IBMJava2-SDK-14 that was working with Debian stable. I assume that is due to some library incompatiblity with my new Debian testing distro. I may decide to upgrade that SDK or else abandon the proprietary approach altogether and go with using gcj to build our java core and example classes (although I don't know how much work that would be or even if that is possible with our present code). Is there anybody here willing to help with the gcj approach? In the octave case there was a segfault with the following error message: plsdev: Must be called before plinit. panic: Segmentation fault -- stopping myself... Rafael, do you confirm this octave front-end problem for your Debian testing distro? Is this version (2.1.57) of octave is a recommended version then it would probably be worthwhile to get PLplot CVS HEAD working for this version of octave. Is that simply a matter of moving your Debian plplot octave interface patches to plplot CVS HEAD? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), 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...> - 2004-06-14 15:56:32
|
On Sun, Jun 13, 2004 at 12:03:55AM -0700, Alan Irwin wrote: > Installing and testing the installed examples of PLplot on Debian testing > had mixed results: > > plplot-test.sh does not work for java or octave. > > In the java case (which I don't think anyone else has tried on Linux) there > seems to be a massive memory leak associated with the java command from the > IBMJava2-SDK-14 that was working with Debian stable. I assume that is due > to some library incompatiblity with my new Debian testing distro. I may > decide to upgrade that SDK or else abandon the proprietary approach > altogether and go with using gcj to build our java core and example classes > (although I don't know how much work that would be or even if that is > possible with our present code). Is there anybody here willing to help > with > the gcj approach? > Provided you set CLASSPATH then plplot-test.sh works for me. (Debian testing + Sun j2sdk-1_4_2_04). It would be nice to get the java working with gcj, although gcj is not quite ready for the big time yet in my experience. There are still too many parts of Java Class Libraries missing. I think we probably need to maintain some support for other versions for now. Andrew |
From: Alan W. I. <ir...@be...> - 2004-06-14 17:31:19
|
On 2004-06-14 16:55+0100 Andrew Ross wrote: > It would be nice to get the java working with gcj, although gcj is not > quite ready for the big time yet in my experience. There are still too > many parts of Java Class Libraries missing. I think we probably need to > maintain some support for other versions for now. Yes, I have rethought my remarks about abandoning the proprietary approach. Instead, we should support both proprietary java and gcj. Setting up the support for these two brands of java should be straightforward using autotools. Of course before doing that, the gcj approach should be tried by hand to make sure there are no showstopper Class Library issues. My educated guess is it will work since our java use is quite minimalist and unsophisticated. I won't be able to get to this for some time, but if you are curious enough to try gcj by hand before me, I would be most interested in your results. To anticipate one issue there, compiled java objects should not be mixed with compiled C objects in the same library (recall all the trouble I had in the fortran case before I split the fortran and C objects into two separate wrapper libraries). So you will need a "Java" wrapper library for the java objects corresponding to the swigjavafiles list in Makefile.am and a "C" wrapper library corresponding to swigcfiles = plplotjavac_wrap.c in Makefile.am. The example java code executables should be linked to the "Java" wrapper library which in turn links to the "C" wrapper library which in turn links to libplplot. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), 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...> - 2004-06-14 18:20:38
|
On Mon, Jun 14, 2004 at 10:26:49AM -0700, Alan Irwin wrote: > On 2004-06-14 16:55+0100 Andrew Ross wrote: > > >It would be nice to get the java working with gcj, although gcj is not > >quite ready for the big time yet in my experience. There are still too > >many parts of Java Class Libraries missing. I think we probably need to > >maintain some support for other versions for now. > > Yes, I have rethought my remarks about abandoning the proprietary approach. > Instead, we should support both proprietary java and gcj. Setting up > the support for these two brands of java should be straightforward > using autotools. > > Of course before doing that, the gcj approach should be tried by hand to > make sure there are no showstopper Class Library issues. My educated guess > is it will work since our java use is quite minimalist and unsophisticated. > I won't be able to get to this for some time, but if you are curious enough > to try gcj by hand before me, I would be most interested in your results. > > To anticipate one issue there, compiled java objects should not be mixed > with compiled C objects in the same library (recall all the trouble I had > in > the fortran case before I split the fortran and C objects into two separate > wrapper libraries). So you will need a "Java" wrapper library for the java > objects corresponding to the swigjavafiles list in Makefile.am and a "C" > wrapper library corresponding to swigcfiles = plplotjavac_wrap.c in > Makefile.am. > > The example java code executables should be linked to the "Java" wrapper > library which in turn links to the "C" wrapper library which in turn links > to libplplot. Well if you want to use gcj as a byte compiler then it more of less works out of the box. The only problem I encountered was the configure check for jni_md.h. gcj doesn't have this. I've commited some changes to cf/java.ac to get round this. I've also added a check in the standard include search path for jni.h. With these changes java now works out of the box on debian testing with gcj / gij. No configure options or environment variables needed for compilation. Of course you still need to set CLASSPATH to run the examples. I guess the next stage (if anyone is interested) is to use gcj to compile object files rather than just byte compiled java .class files. In this case Alan's comments about making a wrapper library apply. Andrew |
From: Rafael L. <rla...@us...> - 2004-06-13 11:57:47
|
* Alan W. Irwin <ir...@be...> [2004-06-13 00:03]: > In the octave case there was a segfault > with the following error message: > > plsdev: Must be called before plinit. > panic: Segmentation fault -- stopping myself... > > Rafael, do you confirm this octave front-end problem for your Debian testing > distro? Is this version (2.1.57) of octave is a recommended version then it > would probably be worthwhile to get PLplot CVS HEAD working for this version > of octave. Is that simply a matter of moving your Debian plplot octave > interface patches to plplot CVS HEAD? This has been discussed in plplot-devel. Applying the Debian-specific patches to CVS HEAD will make the Octave bindings for PLplot work with version 2.1.57 (like in the latest octave-plplot Debian package). However, they may break for previous versions of Octave. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-06-13 15:50:45
|
On 2004-06-13 13:56+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-06-13 00:03]: > >> In the octave case there was a segfault >> with the following error message: >> >> plsdev: Must be called before plinit. >> panic: Segmentation fault -- stopping myself... >> >> Rafael, do you confirm this octave front-end problem for your Debian testing >> distro? Is this version (2.1.57) of octave is a recommended version then it >> would probably be worthwhile to get PLplot CVS HEAD working for this version >> of octave. Is that simply a matter of moving your Debian plplot octave >> interface patches to plplot CVS HEAD? > > This has been discussed in plplot-devel. Applying the Debian-specific > patches to CVS HEAD will make the Octave bindings for PLplot work with > version 2.1.57 (like in the latest octave-plplot Debian package). However, > they may break for previous versions of Octave. I think we should rediscuss this. http://www.octave.org/download.html clearly distinguishes between the various versions of octave that you can download at the present time. A new innovation there is they recommend a stable, testing, and development version. The testing version is the one recommended for most users. Therefore, I think an excellent policy for us should be to maintain the high-level octave interface to PLplot so that the testing version is supported. "testing" currently is 2.1.57 (consistent with John Eaton's post that 2.1.57 is the "recommended" version now), and there is no mention on that page of 2.1.50 (the previous "recommended" version). Thus, I think Rafael's 2.1.57 changes should be brought to CVS HEAD (with the addition of a high-level interface version check for 2.1.57), and we should not worry a bit about incompatibilities with 2.1.50. Of course, if such incompatibilities exist, the downside of that policy is that users of distros that are still stuck at 2.1.50 will be forced to use older versions of PLplot or else update their octave, but so long as the high-level version check for 2.1.57 is there with an appropriate message, I don't think they have much to complain about. Joao, do you agree it is time to move to 2.1.57? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2004-06-14 02:08:28
|
On Sunday 13 June 2004 16:38, Alan W. Irwin wrote: | On 2004-06-13 13:56+0200 Rafael Laboissiere wrote: | > * Alan W. Irwin <ir...@be...> [2004-06-13 00:03]: | >> In the octave case there was a segfault | >> with the following error message: | >> | >> plsdev: Must be called before plinit. | >> panic: Segmentation fault -- stopping myself... | >> | >> Rafael, do you confirm this octave front-end problem for your Debian | >> testing distro? Is this version (2.1.57) of octave is a recommended | >> version then it would probably be worthwhile to get PLplot CVS HEAD | >> working for this version of octave. Is that simply a matter of moving | >> your Debian plplot octave interface patches to plplot CVS HEAD? | > | > This has been discussed in plplot-devel. Applying the Debian-specific | > patches to CVS HEAD will make the Octave bindings for PLplot work with | > version 2.1.57 (like in the latest octave-plplot Debian package). | > However, they may break for previous versions of Octave. | | I think we should rediscuss this. | | http://www.octave.org/download.html clearly distinguishes between the | various versions of octave that you can download at the present time. A | new innovation there is they recommend a stable, testing, and development | version. The testing version is the one recommended for most users. | Therefore, I think an excellent policy for us should be to maintain the | high-level octave interface to PLplot so that the testing version is | supported. "testing" currently is 2.1.57 (consistent with John Eaton's | post that 2.1.57 is the "recommended" version now), and there is no mention | on that page of 2.1.50 (the previous "recommended" version). Thus, I think | Rafael's 2.1.57 changes should be brought to CVS HEAD (with the addition of | a high-level interface version check for 2.1.57), and we should not worry a | bit about incompatibilities with 2.1.50. Of course, if such | incompatibilities exist, the downside of that policy is that users of | distros that are still stuck at 2.1.50 will be forced to use older | versions of PLplot or else update their octave, but so long as the | high-level version check for 2.1.57 is there with an appropriate message, I | don't think they have much to complain about. | | Joao, do you agree it is time to move to 2.1.57? Yes, but now I don't have the time for doing the changes. I think that Rafael's Debian patches should be applied to HEAD, as Rafael reports that most (not all, if I remember correctly) p*.m demos run OK. Joao | | Alan | __________________________ | Alan W. Irwin | email: ir...@be... | phone: 250-727-2902 | | Astronomical research affiliation with Department of Physics and | Astronomy, University of Victoria (astrowww.phys.uvic.ca). | | Programming affiliations with the PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), 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 the new InstallShield X. | | >From Windows to Linux, servers to mobile, InstallShield X is the | | one installation-authoring solution that does it all. Learn more and | evaluate today! http://www.installshield.com/Dev2Dev/0504 | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Rafael L. <rla...@us...> - 2004-06-14 06:30:16
|
* João Cardoso <jc...@fe...> [2004-06-14 03:07]: > On Sunday 13 June 2004 16:38, Alan W. Irwin wrote: > | Joao, do you agree it is time to move to 2.1.57? > > Yes, but now I don't have the time for doing the changes. > > I think that Rafael's Debian patches should be applied to HEAD, as Rafael > reports that most (not all, if I remember correctly) p*.m demos run OK. I was about to release the first release candidate tarball for PLplot 5.3.1. If I apply the patches to HEAD, I will have to postpone the release. I will try to see what I can do this evening. Otherwise, I would prefer that no big changes be done to HEAD in the next days. I am not asking for a strict freeze, but avoid make changes to HEAD that would result in show-stoppers. If you really need to do changes now, please create a branch for that, please. -- Rafael |
From: Rafael L. <rla...@us...> - 2004-06-14 15:52:02
|
* Rafael Laboissiere <rla...@us...> [2004-06-14 08:29]: > I was about to release the first release candidate tarball for PLplot 5.3.1. > If I apply the patches to HEAD, I will have to postpone the release. I will > try to see what I can do this evening. It is done. The RC1 announcement will be done probably later today. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-06-14 17:34:47
|
On 2004-06-14 08:29+0200 Rafael Laboissiere wrote: > * Jo=E3o Cardoso <jc...@fe...> [2004-06-14 03:07]: > >> On Sunday 13 June 2004 16:38, Alan W. Irwin wrote: >> | Joao, do you agree it is time to move to 2.1.57? >> >> Yes, but now I don't have the time for doing the changes. >> >> I think that Rafael's Debian patches should be applied to HEAD, as Rafae= l >> reports that most (not all, if I remember correctly) p*.m demos run OK. > > I was about to release the first release candidate tarball for PLplot 5.3= =2E1. > If I apply the patches to HEAD, I will have to postpone the release. I w= ill > try to see what I can do this evening. Thanks, Rafael. I notice you have already done the octave changes in CVS. = I just tried your changes (and Andrew's recent CVS changes) with =2E/plplot-test.sh for the installed examples, and everything seems to work= fine without problems. Of course this test script only exercises the low-level part of the octave interface (the "x" examples). Out of curiosity I uncommented that part of test_octave.sh having to do with the "p" examples and the high-level octave interface. It bombs with the following messages: =2E/plplot-test.sh --front-end=3Doctave Testing front-end octave *** isfield: - Built-in Function: isfield (EXPR, NAME) Return true if the expression EXPR is a structure and it includes an element named NAME. The first argument must be a structure and the second must be a string. Additional help for built-in functions, operators, and variables is available in the on-line version of the manual. Use the command `help -i <topic>' to search the manual index. Help and information about Octave is also available on the WWW at http://www.octave.org and via the hel...@be... mailing list. error: evaluating assignment expression near line 29, column 10 error: called from `struct_contains' in file `/usr/share/octave/2.1.57/m/de= precated/struct_contains.m' error: evaluating prefix operator `!' near line 49, column 25 error: evaluating binary operator `||' near line 49, column 22 error: if: error evaluating conditional expression error: evaluating if command near line 49, column 3 error: called from `figure' in file `/usr/local/plplot/share/plplot_octave/= figure.m' error: evaluating for command near line 4, column 1 If these octave-2.1.57 problems are not easy to fix, I suggest you complete= ly disable the high-level interface for release. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________= |
From: Rafael L. <rla...@us...> - 2004-06-14 19:13:37
|
* Alan W. Irwin <ir...@be...> [2004-06-14 09:08]: > Out of curiosity I uncommented that part of test_octave.sh having to do > with the "p" examples and the high-level octave interface. It bombs with > the following messages: > > ./plplot-test.sh --front-end=octave > Testing front-end octave > > [...] > > error: evaluating assignment expression near line 29, column 10 > error: called from `struct_contains' in file > [...] Unfortunately, I saw your message just after releasing RC1. Sorry. > If these octave-2.1.57 problems are not easy to fix, I suggest you > completely disable the high-level interface for release. Completely disabling the high-level interface could be more complicated than trying to fix the bug. I will see what I can do. A RC2 tarball may be release next week. -- Rafael |
From: Rafael L. <rla...@us...> - 2004-06-14 19:58:20
|
* Rafael Laboissiere <rla...@us...> [2004-06-14 21:12]: > * Alan W. Irwin <ir...@be...> [2004-06-14 09:08]: > > > Out of curiosity I uncommented that part of test_octave.sh having to do > > with the "p" examples and the high-level octave interface. It bombs with > > the following messages: > > > > ./plplot-test.sh --front-end=octave > > Testing front-end octave > > > > [...] > > > > error: evaluating assignment expression near line 29, column 10 > > error: called from `struct_contains' in file > > [...] > > Unfortunately, I saw your message just after releasing RC1. Sorry. I cannot replicate the bug here, neither on testing nor on unstable. Could you please tell me what you obtain from: grep struct_contains /usr/local/plplot/share/plplot_octave/figure.m Otherwise, I fixed two other bugs that were preventing p7.m to work. Now the high-level demos work fine for me, by uncommenting the "p"-examples lines in test_octave.sh nad running: ./plplot-test.sh --front-end=octave -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-06-14 23:53:50
|
On 2004-06-14 21:57+0200 Rafael Laboissiere wrote: > * Rafael Laboissiere <rla...@us...> [2004-06-14 21:12]: > >> * Alan W. Irwin <ir...@be...> [2004-06-14 09:08]: >> >>> Out of curiosity I uncommented that part of test_octave.sh having to do >>> with the "p" examples and the high-level octave interface. It bombs with >>> the following messages: >>> >>> ./plplot-test.sh --front-end=octave >>> Testing front-end octave >>> >>> [...] >>> >>> error: evaluating assignment expression near line 29, column 10 >>> error: called from `struct_contains' in file >>> [...] >> >> Unfortunately, I saw your message just after releasing RC1. Sorry. > > I cannot replicate the bug here, neither on testing nor on unstable. Could > you please tell me what you obtain from: > > grep struct_contains /usr/local/plplot/share/plplot_octave/figure.m To make sure I didn't have something out of synch with you, I did a completely fresh build and install from cvs checkout using testing version of autotools and unstable version of swig. After that I copied the installed examples to /tmp/examples and everything worked fine for the ./plplot-test.sh script (except for the free java errors I noted previously). I then edited test_octave.sh and ./plplot-test --front-end=octave generated exactly those same error messages again! grep struct_contains /usr/local/plplot/share/plplot_octave/figure.m if (!exist("__pl") || !struct_contains (__pl,"inited")) if (!struct_contains(__pl, "lab_str")) if (struct_contains(__pl, "xlabel")) if (struct_contains(__pl, "shading")) if (struct_contains(__pl, "intp")) Hope this result is instructive for you. If you need more tests, let me know. If you cannot reproduce the error with a fresh checkout and install, then that really puzzles me since our two systems should be absolutely identical with regard to build environment and plplot and therefore should produce identical results. Here is my configure command: ./configure --prefix=/usr/local/plplot --disable-static --enable-octave >| configure.out 2>&1 Note the heady bash stuff. :-) (After many long years on the dark side with tcsh, I have converted over to using bash completely at the same time as moving from debian stable to debian testing. It was time.) BTW, I don't define LD_LIBRARY_PATH. Is that true for you as well? Are there any other possible environment variables that could be messing up the comparison between us? Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-06-15 07:02:20
|
* Alan W. Irwin <ir...@be...> [2004-06-14 16:51]: > If you cannot reproduce the error with a fresh checkout and install, then > that really puzzles me since our two systems should be absolutely identical > with regard to build environment and plplot and therefore should produce > identical results. Could you please install the Debian package to see whether the same error occurs? The examples directory will be installed in /usr/share/doc/octave-plplot. > (After many long years on the dark side with tcsh, I have converted over to > using bash completely at the same time as moving from debian stable to > debian testing. It was time.) Congrats! > BTW, I don't define LD_LIBRARY_PATH. Is that true for you as well? Yes, but this should be irrelevant to the isfield problem that you are having. BTW, this was one of the problems that my patch fixed. The source of the problem may be related to the Octave packages. What do you get from this: COLUMNS=132 dpkg -l octave\* -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-06-15 17:25:07
|
On 2004-06-15 09:01+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-06-14 16:51]: > >> If you cannot reproduce the error with a fresh checkout and install, then >> that really puzzles me since our two systems should be absolutely identical >> with regard to build environment and plplot and therefore should produce >> identical results. > [out of order] > The source of the problem may be related to the Octave packages. What do > you get from this: > > COLUMNS=132 dpkg -l octave\* > When I first did that it showed I had octave 2.0 installed (probably because of tasksel giving me too much) as well as octave2.1. So I removed octave2.0. tasksel also installed libplplot9 for me so I removed that as well from my system (although if we have done our job right, it should not interfere with cvs or tarball build and install of plplot so long as we use a different prefix). Then I did a build and install from scratch of PLplot and got exactly the same problem again for octave when I uncommented the "p" examples! Here is the requested information: **************** Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-===========================-===========================-====================================================================== un octave <none> (no description available) un octave-ci <none> (no description available) un octave-doc <none> (no description available) un octave-emacsen <none> (no description available) un octave-epstk <none> (no description available) un octave-forge <none> (no description available) un octave-headers <none> (no description available) un octave-htmldoc <none> (no description available) un octave-info <none> (no description available) un octave-matcompat <none> (no description available) un octave-plplot <none> (no description available) un octave-sp <none> (no description available) un octave-statdataml <none> (no description available) pn octave2.0 <none> (no description available) un octave2.0-doc <none> (no description available) un octave2.0-emacsen <none> (no description available) un octave2.0-headers <none> (no description available) un octave2.0-htmldoc <none> (no description available) un octave2.0-info <none> (no description available) un octave2.0-staticlibs <none> (no description available) ii octave2.1 2.1.57-1 The GNU Octave language for numerical computations (2.1 branch) un octave2.1-doc <none> (no description available) un octave2.1-emacsen <none> (no description available) ii octave2.1-headers 2.1.57-1 Header files for the GNU Octave language (2.1 branch) un octave2.1-htmldoc <none> (no description available) un octave2.1-info <none> (no description available) **************** [out of order] > Could you please install the Debian package to see whether the same error > occurs? The examples directory will be installed in > /usr/share/doc/octave-plplot. I didn't quite know which plplot packages were essential for this test so here is what I installed for the test (in case this is relevant). ************** Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-===========================-===========================-====================================================================== un libplplot-c++9 <none> (no description available) ii libplplot-dev 5.3.0.cvs.20040324-2 Scientific plotting library (development files) un libplplot5 <none> (no description available) ii libplplot9 5.3.0.cvs.20040324-2 Scientific plotting library ii octave-plplot 5.3.0.cvs.20040324-2 Octave support for PLplot, a plotting library un plplot <none> (no description available) un plplot-bin <none> (no description available) un plplot-doc <none> (no description available) un plplot-lib <none> (no description available) ii plplot-tcl 5.3.0.cvs.20040324-2 Tcl/Tk support for PLplot, a plotting library un plplot-tcl-dev <none> (no description available) un plplot9-driver-gd <none> (no description available) un plplot9-driver-gnome <none> (no description available) ii plplot9-driver-xwin 5.3.0.cvs.20040324-2 Scientific plotting library (X11 driver) ii python-plplot 5.3.0.cvs.20040324-2 Python support for PLplot, a plotting library ************** Also, I removed my own installed cvs version of PLplot to make sure there was no cross-contamination (very improbable, but nevertheless I did it to be sure). After the install of the above packages, here is what I did cp -a /usr/share/doc/octave-plplot/examples /tmp/ cd /tmp/examples ./plplot-test.sh --front-end=octave That generates the identical isfield error! So now I am using your exact Debian build environment and still getting the error so it should be easy for you to replicate it as well. My best guess is you have some Debian package installed that I don't have. So let me know if there is any other dpkg --list commands you want me to try. BTW, if a missing package on my system is the source of the problem, then the dependencies have to be changed on octave-plplot to deal with this. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-06-16 07:43:30
|
* Alan W. Irwin <ir...@be...> [2004-06-15 09:54]: > On 2004-06-15 09:01+0200 Rafael Laboissiere wrote: > >Could you please install the Debian package to see whether the same error > >occurs? The examples directory will be installed in > >/usr/share/doc/octave-plplot. > > I didn't quite know which plplot packages were essential for this test so > here is what I installed for the test (in case this is relevant). > > [...] > > ii octave-plplot 5.3.0.cvs.20040324-2 Octave support for PLplot, a plotting library > > [...] > > Also, I removed my own installed cvs version of PLplot to make sure there > was no cross-contamination (very improbable, but nevertheless I did it to > be sure). > > After the install of the above packages, here is what I did > > cp -a /usr/share/doc/octave-plplot/examples /tmp/ > > cd /tmp/examples > > ./plplot-test.sh --front-end=octave > > That generates the identical isfield error! I found the source of the problem, which has not been fixed in the version of octave-plplot you have (5.3.0.cvs.20040324-2, as above). In more recent versions of the Debian packages, I added a modified file struct_contain.m, which is in the debian directory in the CVS repository. This means that the Debian package octave-plplot in unstable *_do_* work correctly with Octave 2.1.57. I am going to do the necessary changes in HEAD, but since I am busy right now this may take some time. The release of RC2 will probably follow shortly after the struct_contains problem is fixed. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-06-17 00:26:16
|
On 2004-06-16 09:42+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-06-15 09:54]: >> That generates the identical isfield error! > > I found the source of the problem, [...] I am going to do the > necessary changes in > HEAD, but since I am busy right now this may take some time. Thanks, Rafael, for that change which I have just noted in CVS. I tested it here, and it works fine. I finished off the octave-2.1.57 changes by updating the version check (since 2.1.50 apparently won't work), making octave configured by default (since it now works fully again), and allowing the "p" examples to be tested again when the plplot-test.sh script is run. I am really pleased to see our octave interface working so well again. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), 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...> - 2004-06-13 18:27:08
|
On 2004-06-13 00:03-0700 Alan W. Irwin wrote: > plplot-test.sh does not work for java or octave. > > In the java case (which I don't think anyone else has tried on Linux) there > seems to be a massive memory leak associated with the java command from the > IBMJava2-SDK-14 that was working with Debian stable. I now believe the previous IBM version was only suitable for gcc-2.9.5 so I have switched to the Blackdown SDK that is suitable for gcc-3.x (j2sdk-1.4.2-rc1-linux-i586-gcc3.2.bin and j2sdk-1.4.2-rc1-linux-i586-gcc3.2.bin.sign which can be obtained from ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/JDK-1.4.2/i386/rc1/ ). This Blackdown SDK works fine on Debian testing (after some tweaks I have just committed). One of those tweaks was I had to comment out a call to plgver in x01.java. The problem with plgver also showed up in a less catastrophic way for the IBM SDK. I am keen to move from non-free java to gcj because it would allow us to use gdb and valgrind to figure out the plgver problem, would give us the freedom to treat the java interface and example code just like any other language, and also would allow Debian packaging of a free java interface to PLplot. However, I have no time at the moment to pursue this dream. Therefore, unless somebody else is really keen, we should probably put off the move to gcj until post-release. Meanwhile, my recent tests show we are good to go for a release of at least the java part of PLplot for non-free (Blackdown) java. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |