From: Koen v. d. D. <kvd...@ea...> - 2006-09-19 03:04:01
|
Hi, I haven't really been following the recent developments in plplot, but I do know that you guys are switching from make to cmake. Regarding building plplot using fink, is there anything I could test to find out what I need to change in the fink package? cheers, - Koen. |
From: Alan W. I. <ir...@be...> - 2006-09-19 18:10:58
|
On 2006-09-18 23:03-0400 Koen van der Drift wrote: > Hi, > > I haven't really been following the recent developments in plplot, > but I do know that you guys are switching from make to cmake. Just to clear up this common misconception (the confusing name is the only thing I actively dislike about cmake), cmake is a build system which configures files (in particular Makefile's) in _preparation_ for a build. The actual build and install are done with the familiar make and make install commands. In sum, cmake replaces the cf/bootstrap.sh (if building from cvs) and ./configure commands that you currently use for our autotools build system. It does not replace the make command. > Regarding building plplot using fink, is there anything I could test > to find out what I need to change in the fink package? Yes. Please get the latest version of PLplot from cvs, and give cmake a try following the wiki instructions at http://www.miscdebris.net/plplot_wiki/ . There are generic Unix instructions plus Mac OS X details there. Feel free to improve those instructions (it is a wiki, after all) if you feel there is something that needs clarification. Also, I will be happy to anwer any of your questions about our CMake build system on or off list. Good luck, getting up to speed with our CMake build system. 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 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: Koen v. d. D. <kvd...@ea...> - 2006-09-21 19:21:57
|
On Sep 19, 2006, at 1:20 PM, Alan W. Irwin wrote: > Yes. Please get the latest version of PLplot from cvs, and give > cmake a try > following the wiki instructions at http://www.miscdebris.net/ > plplot_wiki/ . > There are generic Unix instructions plus Mac OS X details there. The wiki suggests that I need to use cmake 2.4.3, however fink has version 2.4.2. I have already put in a request to upgrade cmake in fink. Will plplot work with cmake 2.4.2, or is the most recent version necessary? thanks, - Koen. |
From: Alan W. I. <ir...@be...> - 2006-09-21 22:29:52
|
On 2006-09-21 15:21-0400 Koen van der Drift wrote: > > On Sep 19, 2006, at 1:20 PM, Alan W. Irwin wrote: > >> Yes. Please get the latest version of PLplot from cvs, and give cmake a >> try >> following the wiki instructions at http://www.miscdebris.net/plplot_wiki/ >> . >> There are generic Unix instructions plus Mac OS X details there. > > The wiki suggests that I need to use cmake 2.4.3, however fink has version > 2.4.2. I have already put in a request to upgrade cmake in fink. Will plplot > work with cmake 2.4.2, or is the most recent version necessary? Yes, 2.4.3 is necessary. So you will have to build that yourself (which should be straightforward) or else download the binary version for Mac OS X from the CMake website. 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 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: Koen v. d. D. <kvd...@ea...> - 2006-09-22 02:02:47
|
On Sep 21, 2006, at 6:28 PM, Alan W. Irwin wrote: > Yes, 2.4.3 is necessary. So you will have to build that yourself > (which > should be straightforward) or else download the binary version for > Mac OS X > from the CMake website. It turns out my request was honored, version 2.4.3 is already in fink (10.4/unstable). - Koen. |
From: Hazen B. <hba...@ma...> - 2006-09-29 01:55:36
|
The latest on OS-X: (1) I cannot build with Python anymore. Linking C shared module _plplotcmodule.so cd /Users/hbabcock/Documents/OpenSource/PLplot/plplot-CBS-1/bindings/ python && /usr/local/bin/cmake -P CMakeFiles/_plplotcmodule.dir/ cmake_clean_target.cmake cd /Users/hbabcock/Documents/OpenSource/PLplot/plplot-CBS-1/bindings/ python && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/ _plplotcmodule.dir/link.txt --verbose=1 /usr/bin/gcc -bundle -headerpad_max_install_names -o _plplotcmodule.so "CMakeFiles/_plplotcmodule.dir/ plplotcmodulePYTHON_wrap.o" -L/Users/hbabcock/Documents/OpenSource/ PLplot/plplot-CBS-1/src -L/Users/hbabcock/Documents/OpenSource/PLplot/ plplot-CBS-1/lib/csa -L/Users/hbabcock/Documents/OpenSource/PLplot/ plplot-CBS-1/lib/nn -L/usr/local/lib -lplplotd -lltdl -ldl -lm - lcsirocsa -lcsironn -lqhull /usr/bin/ld: Undefined symbols: _PyArg_ParseTuple _PyArg_UnpackTuple _PyBaseObject_Type _PyCFunction_Type _PyCObject_AsVoidPtr _PyCObject_FromVoidPtr _PyCObject_Import _PyCObject_Type _PyCallable_Check _PyClass_Type It looks like OS-X specific instructions in python.cmake were removed in 9-21-06 commit... (2) Attempts to build with Octave have failed. There seems to be a problem with the setting of OCTAVE_INCLUDE_PATH. When I try to make I get: -- OCTAVE_INCLUDE_PATH = /usr/local/include/octave-2.1.73/usr/local/ include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ include/octave-2.1.73/usr/local/include/octave-2.1.73/.... and so on for many many lines ... (3) This may or may not be OS-X specific, but it looks like we are failing to set our library version number appropriately/properly. The following is the output of a perl script that attempted to use a CBS build of plplot: Can't load '/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/PDL/ Graphics/PLplot/PLplot.bundle' for module PDL::Graphics::PLplot: dlopen(/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/PDL/ Graphics/PLplot/PLplot.bundle, 1): Library not loaded: /usr/local/lib/ libplplotd.9.dylib Referenced from: /Library/Perl/5.8.6/darwin-thread-multi-2level/ auto/PDL/Graphics/PLplot/PLplot.bundle Reason: Incompatible library version: PLplot.bundle requires version 12.0.0 or later, but libplplotd.9.dylib provides version 0.0.0 at /System/Library/Perl/5.8.6/darwin-thread-multi-2level/ DynaLoader.pm line 230. at ./plfill.pl line 5 Compilation failed in require at ./plfill.pl line 5. BEGIN failed--compilation aborted at ./plfill.pl line 5. -Hazen |
From: Alan W. I. <ir...@be...> - 2006-09-29 05:18:53
|
On 2006-09-28 21:54-0400 Hazen Babcock wrote: > (1) I cannot build with Python anymore. > [...]It looks like OS-X specific instructions in python.cmake were removed > in 9-21-06 commit... Sorry, Hazen. I decided to do this a different way for all platforms (not just Mac OS X), but after removing your old method I only applied the new method to the plplot_widgetmodule target and forgot all about _plplotcmodule. I have now also applied the new method to _plplotcmodule. The result seems good on Linux, but please also test it on Mac OS X again. Once again, sorry for the screw-up. > > > (2) Attempts to build with Octave have failed. There seems to be a > problem with the setting of OCTAVE_INCLUDE_PATH. When I try to make I > get: > > -- OCTAVE_INCLUDE_PATH = /usr/local/include/octave-2.1.73/usr/local/ > include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ > include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ > include/octave-2.1.73/usr/local/include/octave-2.1.73/.... and so on > for many many lines ... More information is needed for your platform. The message above is cmake output that comes from octave.cmake. For our ABS I was forced to do long-distance second-hand debugging because virtually nobody understood that build system, but I am hoping this will no longer be necessary for our CBS since that build system is straightforward to understand. Thus, please participate strongly in the debugging of the above bad message from octave.cmake for your platform. Thus, give all octave-related output from cmake (not just the one obviously bad message above). There is a lot of such output which I deliberately left in, and if there is something you are not sure you understand, feel free to add more output (e.g., add output for _OCTAVE_VERSION to make sure the REGEX REPLACE that transforms that variable into OCTAVE_VERSION is working correctly on your platform). I am also hoping that by consulting the CMake documentation, you should be able to follow all cmake commands within the octave.cmake module (especially all the REGEX REPLACEs), and with luck find out exactly what the trouble is and fix it, but if that is not possible, you should at least be able to comment on whether the output of each message command in octave.cmake is what you expected or not for your platform from your understanding of what each cmake command is doing in that module. > > > (3) This may or may not be OS-X specific, but it looks like we are > failing to set our library version number appropriately/properly. The > following is the output of a perl script that attempted to use a CBS > build of plplot: > > Can't load '/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/PDL/ > Graphics/PLplot/PLplot.bundle' for module PDL::Graphics::PLplot: > dlopen(/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/PDL/ > Graphics/PLplot/PLplot.bundle, 1): Library not loaded: /usr/local/lib/ > libplplotd.9.dylib > Referenced from: /Library/Perl/5.8.6/darwin-thread-multi-2level/ > auto/PDL/Graphics/PLplot/PLplot.bundle > Reason: Incompatible library version: PLplot.bundle requires > version 12.0.0 or later, but libplplotd.9.dylib provides version > 0.0.0 at /System/Library/Perl/5.8.6/darwin-thread-multi-2level/ > DynaLoader.pm line 230. > at ./plfill.pl line 5 > Compilation failed in require at ./plfill.pl line 5. > BEGIN failed--compilation aborted at ./plfill.pl line 5. Perl/PDL should not have a lot to do with our CBS build. The reason is Perl/PDL uses an old system version of PLplot to run the examples that our installed by our CBS, but those examples should be the only connection with our CBS build. It's possible you got the above message because you (at some point) overwrote the old system PLplot library by using the default install prefix of /usr/local rather than using the recommended unique (non-system) install prefix. Anyhow, if you are getting error messages from Perl/PDL execution of our examples, it probably has something to do with that installation being clobbered and not much to do with our CBS (at least so long as you avoid the default /usr/local installation prefix). 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 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: Hazen B. <hba...@ma...> - 2006-10-01 23:47:19
|
On Sep 29, 2006, at 1:17 AM, Alan W. Irwin wrote: > On 2006-09-28 21:54-0400 Hazen Babcock wrote: > >> (1) I cannot build with Python anymore. > >> [...]It looks like OS-X specific instructions in python.cmake were >> removed >> in 9-21-06 commit... > > Sorry, Hazen. I decided to do this a different way for all > platforms (not > just Mac OS X), but after removing your old method I only applied > the new > method to the plplot_widgetmodule target and forgot all about > _plplotcmodule. I have now also applied the new method to > _plplotcmodule. > The result seems good on Linux, but please also test it on Mac OS X > again. > Once again, sorry for the screw-up. It works now, thanks. >> (2) Attempts to build with Octave have failed. There seems to be a >> problem with the setting of OCTAVE_INCLUDE_PATH. When I try to make I >> get: >> >> -- OCTAVE_INCLUDE_PATH = /usr/local/include/octave-2.1.73/usr/local/ >> include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ >> include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ >> include/octave-2.1.73/usr/local/include/octave-2.1.73/.... and so on >> for many many lines ... > > More information is needed for your platform. The message above is > cmake > output that comes from octave.cmake. For our ABS I was forced to do The problem here is that each time you run octave.cmake OCTAVE_INCLUDE_PATH gets 2x longer. Run octave.cmake 10x times, as you very well might if you are fiddling around with ccmake to try and get things properly configured, and OCTAVE_INCLUDE_PATH is now 2^10 times longer... -Hazen |
From: Hazen B. <hba...@ma...> - 2006-10-02 01:15:22
|
On Sep 29, 2006, at 1:17 AM, Alan W. Irwin wrote: >> >> (2) Attempts to build with Octave have failed. There seems to be a >> problem with the setting of OCTAVE_INCLUDE_PATH. When I try to make I >> get: Plplot / Octave works now, or at least builds. It appears that you must build octave with "./configure --enable-shared --enable-dl" to get shared libraries (this is not the default, at least on OS-X). If you don't then cmake will find the static libraries and enable octave but it will fail when it gets to the link with a long list of "ld undefined symbol" errors. -Hazen |
From: Alan W. I. <ir...@be...> - 2006-10-02 18:59:18
|
On 2006-10-01 19:46-0400 Hazen Babcock wrote: >>> (2) Attempts to build with Octave have failed. There seems to be a >>> problem with the setting of OCTAVE_INCLUDE_PATH. When I try to make I >>> get: >>> >>> -- OCTAVE_INCLUDE_PATH = /usr/local/include/octave-2.1.73/usr/local/ >>> include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ >>> include/octave-2.1.73/usr/local/include/octave-2.1.73/usr/local/ >>> include/octave-2.1.73/usr/local/include/octave-2.1.73/.... and so on >>> for many many lines ... > > The problem here is that each time you run octave.cmake OCTAVE_INCLUDE_PATH > gets 2x longer. Run octave.cmake 10x times, as you very well might if you are > fiddling around with ccmake to try and get things properly configured, and > OCTAVE_INCLUDE_PATH is now 2^10 times longer... That description helped me find what I think is the source of the problem in octave.cmake. On Linux the oct.h path tends to be of the form /usr/include/octave-2.1.69/octave while the gcc options have to specify two paths: -I/usr/include/octave-2.1.69/octave -I/usr/include/octave-2.1.69 So once the first form is found I trim off the /octave on the end to get the second form and combine the two. However, for the old logic the trimming operation ended with the same form if there was no trailing /octave. Also, repeat calls to the logic kept reprocessing the result to obtain even more -I options. (As you said, this gets pretty interesting for say 10 calls to ccmake). I have now tightened up the octave.cmake logic so that it only produces an extra -I option if there is a trailing "/octave" and furthermore it doesn't reprocess (using the neat new NOT DEFINED logic pointed out to me on the CMake mailing list). Please try the result to make sure octave.cmake now works properly 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 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: Hazen B. <hba...@ma...> - 2006-10-03 03:45:58
|
> it doesn't reprocess (using the neat new NOT DEFINED logic pointed > out to me > on the CMake mailing list). Please try the result to make sure > octave.cmake > now works properly on Mac OS X. It is still behaving as before. I added: message(STATUS "TRIMMED = ${OCTAVE_INCLUDE_PATH_TRIMMED}") before: if(NOT DEFINED OCTAVE_INCLUDE_PATH_TRIMMED) in octave.cmake & it looks like the value of OCTAVE_INCLUDE_PATH_TRIMMED is being forgotten between invocations of octave.cmake -Hazen |
From: Alan W. I. <ir...@be...> - 2006-10-02 20:20:39
|
On 2006-10-01 21:14-0400 Hazen Babcock wrote: > > On Sep 29, 2006, at 1:17 AM, Alan W. Irwin wrote: > >>> >>> (2) Attempts to build with Octave have failed. There seems to be a >>> problem with the setting of OCTAVE_INCLUDE_PATH. When I try to make I >>> get: > > Plplot / Octave works now, or at least builds. That's encouraging news. > It appears that you must build > octave with "./configure --enable-shared --enable-dl" to get shared libraries > (this is not the default, at least on OS-X). If you don't then cmake will > find the static libraries and enable octave but it will fail when it gets to > the link with a long list of "ld undefined symbol" errors. I think the octave ./configure default is probably set to build a simplistic octave which is easy to build on most/all systems, but which most people will not want. According to http://www.gnu.org/software/octave/doc/interpreter/Installation.html, --enable-dl is required in order to dynamically load plug-in extensions such as the octave interface to PLplot, plplot_octave.oct. They also remark that --enable-shared is required on some systems to make --enable-dl work properly, and in any case, --enable-shared makes octave much smaller. Furthermore, my simple linking mechanism for octave should only work for the --enable-shared version of octave. Thus, if we want the octave interface to Plplot to work properly, --enable-dl and --enable-shared should be considered absolutely necessary prerequisites (for all systems, not just Mac OS X) for the octave build. You may want to mention this in our Wiki although most of our users will be using a binary version of octave rather than building their own. Following what has been done for the windows case there, would you also be willing to make a table of what currently works and what doesn't for the Mac OS X platform? I presume most distributed binary versions of octave will have these prerequisites since most users will want to use plug-in extensions (such as PLplot). For example, these prerequisites are supplied automatically for binary packages of octave for Debian and Ubuntu (and presumably most/all other Linux distributions). Could you (or Koen) check that the binary package of octave supplied by fink (see http://pdb.finkproject.org/pdb/package.php/octave) also supplies these prerequisites by attempting a PLplot build that uses the fink octave package? In any case, I am glad you found those octave build prerequisites for yourself, and I am just waiting for your further report as to whether the built octave interface actually works (i.e, with ctest results in the build tree and/or ./plplot-test.sh results in the install tree.) The suspense is building rapidly.... :-) 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 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...> - 2006-10-03 17:04:47
|
On 2006-10-02 23:44-0400 Hazen Babcock wrote: > >> it doesn't reprocess (using the neat new NOT DEFINED logic pointed out to >> me >> on the CMake mailing list). Please try the result to make sure >> octave.cmake >> now works properly on Mac OS X. > > It is still behaving as before. > > I added: > message(STATUS "TRIMMED = ${OCTAVE_INCLUDE_PATH_TRIMMED}") > > before: > if(NOT DEFINED OCTAVE_INCLUDE_PATH_TRIMMED) > > in octave.cmake & it looks like the value of OCTAVE_INCLUDE_PATH_TRIMMED is > being forgotten between invocations of octave.cmake Thanks for helping me finally track this one down. Yes, my previous non-working fix depended on OCTAVE_INCLUDE_PATH_TRIMMED which is uncached and therefore by definition undefined for each cmake invocation. Normally, I clean out the build tree before every cmake invocation so I never saw the bug. The breakthrough in understanding came when I realized I could generate the bad 2^n result you discovered by simply repeating n cmake commands without cleaning out the build directory. The new logic in octave.cmake (which I just committed) depends on the cached variable OCTAVE_INCLUDE_PATH, and that new logic works for me. Please try it for yourself. 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 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: Hazen B. <hba...@ma...> - 2006-10-11 04:52:22
|
> > Thanks for helping me finally track this one down. Yes, my previous > non-working fix depended on OCTAVE_INCLUDE_PATH_TRIMMED which is > uncached > and therefore by definition undefined for each cmake invocation. > Normally, > I clean out the build tree before every cmake invocation so I never > saw the > bug. The breakthrough in understanding came when I realized I could > generate > the bad 2^n result you discovered by simply repeating n cmake commands > without cleaning out the build directory. The new logic in > octave.cmake > (which I just committed) depends on the cached variable > OCTAVE_INCLUDE_PATH, > and that new logic works for me. > > Please try it for yourself. This works for me as well. Also, while I have yet to figure out how to run a java example myself, it appears that the java interface on OS-X passes our tests. /usr/local/share/plplot5.6.1/examples : ./plplot-test.sh Testing front-end c PLplot library version: 5.6.1 Testing front-end cxx PLplot library version: 5.6.1 Testing front-end f77 PLplot library version: 5.6.1 Testing front-end f95 PLplot library version: 5.6.1 Testing front-end java PLplot library version: 5.6.1 Testing front-end octave error: `find' undefined near line 71 column 9 error: evaluating assignment expression near line 71, column 7 error: evaluating if command near line 65, column 3 error: called from `findstr' in file `/usr/local/share/octave/2.1.73/ m/strings/findstr.m' error: evaluating assignment expression near line 58, column 9 error: evaluating if command near line 55, column 3 error: evaluating if command near line 43, column 3 error: called from `split' in file `/usr/local/share/octave/2.1.73/m/ strings/split.m' error: evaluating assignment expression near line 51, column 7 error: evaluating if command near line 50, column 3 error: called from `figure' in file `/usr/local/share/plplot_octave/ figure.m' error: evaluating for command near line 4, column 1 Testing front-end python Note that I deleted this directory & reinstalled it using CBS prior to my tests. I believe that the octave difficulties are due to a failure on my part to configure Octave properly on my machine. However, I've yet to figure out what exactly is wrong. It appears that octave cannot find the file that defines the function "find". I've installed Octave in the default place so I'm not sure why it is having so much trouble, but since I can't find the file that contains that function either perhaps I should not complain :). -Hazen |
From: Alan W. I. <ir...@be...> - 2006-10-11 16:41:24
|
Hi Hazen: I am glad to hear that the java installed examples test and my second try at the 2^n fix both work for you. You should be able to get the java examples to work by hand by following what is done in plplot-test.sh and test_java.sh. That leaves the Tcl/Tk issue. Koen, will you comment on Tcl/Tk under our ABS and CBS please? It also leaves the Octave issue for which I have one important question below. On 2006-10-11 00:51-0400 Hazen Babcock wrote: > /usr/local/share/plplot5.6.1/examples : ./plplot-test.sh > Testing front-end c > PLplot library version: 5.6.1 > Testing front-end cxx > PLplot library version: 5.6.1 > Testing front-end f77 > PLplot library version: 5.6.1 > Testing front-end f95 > PLplot library version: 5.6.1 > Testing front-end java > PLplot library version: 5.6.1 > Testing front-end octave > error: `find' undefined near line 71 column 9 > error: evaluating assignment expression near line 71, column 7 > error: evaluating if command near line 65, column 3 > error: called from `findstr' in file `/usr/local/share/octave/2.1.73/ > m/strings/findstr.m' > error: evaluating assignment expression near line 58, column 9 > error: evaluating if command near line 55, column 3 > error: evaluating if command near line 43, column 3 > error: called from `split' in file `/usr/local/share/octave/2.1.73/m/ > strings/split.m' > error: evaluating assignment expression near line 51, column 7 > error: evaluating if command near line 50, column 3 > error: called from `figure' in file `/usr/local/share/plplot_octave/figure.m' > error: evaluating for command near line 4, column 1 > Testing front-end python > > I believe that the octave difficulties are due to a failure on my part to > configure Octave properly on my machine. However, I've yet to figure out what > exactly is wrong. It appears that octave cannot find the file that defines > the function "find". I've installed Octave in the default place so I'm not > sure why it is having so much trouble, but since I can't find the file that > contains that function either perhaps I should not complain :). What happens if you use the fink version of octave from http://pdb.finkproject.org/pdb/package.php/octave ? 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 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: Hazen B. <hba...@ma...> - 2006-10-18 02:35:59
|
On Oct 11, 2006, at 12:40 PM, Alan W. Irwin wrote: > Hi Hazen: > > It also leaves the Octave issue for which I have one important > question below. CBS Plplot / Octave (v2.1.73) works on OS-X. The problems I had before were due to octave, or at least they went away when I reinstalled octave. -Hazen |