Since compiling the program from source appears to have solved the
problem for you, I do not believe that it is related to the issue
of my bug report since that report involves Ubuntu and seems to be a
Debian idiosyncrasy due to this /bin/sh and /bin/dash vs. /bin/bash
decision made by the Debian distro guys. Not a good choice in my mind.
One of the frustrations of open source in general and Linux in
particular is that the distro proliferation results in this chaos of
compatibility
problems for each package. I switched to FreeBSD for a long time because
of this issue. However, I could not get FreeBSD to work
on my laptop and ran into problems of using Linux on my laptop for the
purpose of duplicating what was on my server-- hence more
distro and version incompatibilities. However, I really liked FreeBSD as
a server platform. I switched back to Linux for convenience
and to get access to programs on the desktop. I am paying the price. I
picked Debian and Ubuntu due to the rep of the distro. It seems
to be okay.
As far a Texmacs is concerned, these session problems are here to stay I
believe, unless an individual user wants to get into the plug-in code,
or in your case, through trial and error, and fix these problems that
crop up. There seems to be two kinds of problems:
1. Distro issues. This includes problems like yours and mine. Things
don't fit together, like having the wrong pipe sizes and fittings or
threading
in plumbing. The guys that put out the distro don't seems to be
maintaining these plug-ins as these issues come up. The same bugs that
you and
I have are a year or more old.
2. Package changes. Octave is a good example. There are problems with
the Octave plug-in, not because the plug-in does not work due to distro
issues ( I had to fix those by editing the files), but rather because
the plug-ins use support files as interface code to Texmacs that contain
code
from the package and these are changed or deprecated and hence errors
and warnings spit out in the Texmacs session depending on the command
or statement issued in the Texmacs session. In other words, the plug-in
is not being maintained current and in some cases does not recognize the
different
versions of the package that may be installed. Maxima tries to get it
right by detecting the versions and going from there, but the rest are
helter-skelter.
You probably will not see this kind of problem from say, a Python
session. Python code is stable so that there should be no surprises when
the next
version of Python is installed.
Now all the sessions Sage can access use one plug-in interface through
this Sage Texmacs plug-in which is Python code and not likely to break.
Note that the SAGE plug-in must be in your home directory in
~/.Texmacs/plugins
Also note that the path to the SAGE executable (that is the place where
you have parked the SAGE distro by unpacking it (e.g., /opt/sage)
must be in your PATH environment variable when you run Texmacs. I did
this by merely creating a shell script to call Texmacs and added
the path to the first part:
#!/bin/bash
export PATH=$PATH:/opt/sage
texmacs
This does the trick. Otherwise SAGE will not show up as a session in
Texmacs. A plus with SAGE is that it comes with most of the packages
(Maxima, et al.)
and it uses these (batteries included), so there are no real interface
issues here with SAGE. Octave is an exception (also R), but SAGE will
use Octave if installed and executable from
the shell command line--this is mostly going to be the case. SAGE
includes interfaces to Magma, Maple, Mathematica, MATLAB, and MuPAD, and
the free programs Axiom, GAP,
GP/PARI, Macaulay2, Maxima, Octave, and Singular. Most of the free ones
are in the SAGE tarball and it uses these and not the one installed as a
package. Sage is well-documented.
It has some optional add-ons that I have not used. The standard packages
are listed at:
Tim McQ wrote:
> I came across this thread trying to solve the same issue with openSuse
> 10.3 x86_64 using both maxima versions 5.13.0-2.2 x86_64, 5.14.0-2.1
> x86_64 installed from:
>
> http://software.opensuse.org/search?p=1&q=wxmaxima&baseproject=openSUSE%3A10.3
>
> and TeXmacs 1.0.6.9-54 x86_64 installed directly from YaST.
>
> I have the same exact problem where using TeXmacs as a front end to
> maxima complains: "Unsupported version of maxima: 5.xx.x"
>
> I tried your advice to change the first line of the two scripts,
> maxima_detect and tm_maxima located in /usr/lib64/TeXmacs/bin, from
> #!/bin/sh to #!/bin/bash.
>
> This does not fix the issue. I did however notice in the script
> tm_maxima that there is not even an entry for this recent version:
>
> It seems the only versions of maxima compatible with this version of
> TeXmacs have plugins located in /usr/share/TeXmacs/plugins/maxima/lisp:
>
> The contents of this directory are as follows:
>
> -rw-r--r-- 1 root root 5126 2007-09-21 17:56 texmacs-maxima-5.10.0.lisp
> -rw-r--r-- 1 root root 5128 2007-09-21 17:56 texmacs-maxima-5.11.0.lisp
> -rw-r--r-- 1 root root 26027 2007-09-21 17:56 texmacs-maxima-5.6.lisp
> -rw-r--r-- 1 root root 7449 2007-09-21 17:56 texmacs-maxima-5.9.0.lisp
> -rw-r--r-- 1 root root 1471 2007-09-21 17:56 texmacs-maxima-5.9.1.lisp
> -rw-r--r-- 1 root root 5239 2007-09-21 17:56 texmacs-maxima-5.9.2.lisp
>
> I then tried uninstalling all previous versions of maxima and installed
> the newest one in the list, maxima-5.11.0-1.1.x86_64.rpm, from:
>
> http://download.opensuse.org/repositories/science/SUSE_Linux_10.0/repodata/repoview/maxima-0-5.11.0-1.1.html
>
> This one actually did not complain about versions when I launched
> TeXmacs but it did not run. It said it was "dead" instead of "idle". It
> also would not work from the terminal either whereas the newer ones did.
> It complained with the following:
>
> /usr/bin/maxima: unable to determine MAXIMA_PREFIX
>
> This RPM was built for openSuse 10.0 not 10.3 that I am using.
>
> So I next removed this package and grabbed the source for maxima-5.11.0
> here:
>
> http://sourceforge.net/project/showfiles.php?group_id=4933&package_id=4960&release_id=473008
>
> I moved into the source directory and issued a ./configure to generate a
> makefile but I got this error:
>
> configure: error: No lisp implementation specified and none of the
> default executables
> clisp(clisp),gcl(GCL),lisp(CMUCL),scl(SCL),sbcl(SBCL),lisp(ACL),openmcl(OpenMCL)
> were found in PATH
>
> So I went into YaST and installed clisp. After that finished I did
> another ./configure then a make and then a make install. This is what I
> get:
>
>
> Maxima 5.11.0 http://maxima.sourceforge.net
>
> Using Lisp CLISP 2.41 (2006-10-13)
>
> Distributed under the GNU Public License. See the file COPYING.
>
> Dedicated to the memory of William Schelter.
>
> This is a development version of Maxima. The function bug_report()
>
> provides bug reporting information.
>
> Looks like it works... This took me quite some time to do but it appears
> to work. I now have to go through a tutorial to use it and will re post
> if it does not work.
>
> -Tim
>
>
Since compiling the program from source appears to have solved the
problem for you, I do not believe that it is related to the issue
of my bug report since that report involves Ubuntu and seems to be a
Debian idiosyncrasy due to this /bin/sh and /bin/dash vs. /bin/bash
decision made by the Debian distro guys. Not a good choice in my mind.
One of the frustrations of open source in general and Linux in
particular is that the distro proliferation results in this chaos of
compatibility
problems for each package. I switched to FreeBSD for a long time because
of this issue. However, I could not get FreeBSD to work
on my laptop and ran into problems of using Linux on my laptop for the
purpose of duplicating what was on my server-- hence more
distro and version incompatibilities. However, I really liked FreeBSD as
a server platform. I switched back to Linux for convenience
and to get access to programs on the desktop. I am paying the price. I
picked Debian and Ubuntu due to the rep of the distro. It seems
to be okay.
As far a Texmacs is concerned, these session problems are here to stay I
believe, unless an individual user wants to get into the plug-in code,
or in your case, through trial and error, and fix these problems that
crop up. There seems to be two kinds of problems:
1. Distro issues. This includes problems like yours and mine. Things
don't fit together, like having the wrong pipe sizes and fittings or
threading
in plumbing. The guys that put out the distro don't seems to be
maintaining these plug-ins as these issues come up. The same bugs that
you and
I have are a year or more old.
2. Package changes. Octave is a good example. There are problems with
the Octave plug-in, not because the plug-in does not work due to distro
issues ( I had to fix those by editing the files), but rather because
the plug-ins use support files as interface code to Texmacs that contain
code
from the package and these are changed or deprecated and hence errors
and warnings spit out in the Texmacs session depending on the command
or statement issued in the Texmacs session. In other words, the plug-in
is not being maintained current and in some cases does not recognize the
different
versions of the package that may be installed. Maxima tries to get it
right by detecting the versions and going from there, but the rest are
helter-skelter.
You probably will not see this kind of problem from say, a Python
session. Python code is stable so that there should be no surprises when
the next
version of Python is installed.
One possible work around is to use SAGE.
http:// www.sagemath. org/
You want the Linux binary version.
SAGE accesses these same programs through a common interface and there
is a SAGE plug-in for Texmacs that you have to install manually.
http:// www.sagemath. org:9001/ TeXmacs
Now all the sessions Sage can access use one plug-in interface through
this Sage Texmacs plug-in which is Python code and not likely to break.
Note that the SAGE plug-in must be in your home directory in
~/.Texmacs/plugins
Also note that the path to the SAGE executable (that is the place where
you have parked the SAGE distro by unpacking it (e.g., /opt/sage)
must be in your PATH environment variable when you run Texmacs. I did
this by merely creating a shell script to call Texmacs and added
the path to the first part:
#!/bin/bash /opt/sage
export PATH=$PATH:
texmacs
This does the trick. Otherwise SAGE will not show up as a session in
Texmacs. A plus with SAGE is that it comes with most of the packages
(Maxima, et al.)
and it uses these (batteries included), so there are no real interface
issues here with SAGE. Octave is an exception (also R), but SAGE will
use Octave if installed and executable from
the shell command line--this is mostly going to be the case. SAGE
includes interfaces to Magma, Maple, Mathematica, MATLAB, and MuPAD, and
the free programs Axiom, GAP,
GP/PARI, Macaulay2, Maxima, Octave, and Singular. Most of the free ones
are in the SAGE tarball and it uses these and not the one installed as a
package. Sage is well-documented.
It has some optional add-ons that I have not used. The standard packages
are listed at:
http:// www.sagemath. org/packages/ standard/
I would try this and be done with it as I have.
Good Luck:
David Miller
Tim McQ wrote: software. opensuse. org/search? p=1&q=wxmaxima& baseproject= openSUSE% 3A10.3 TeXmacs/ bin, from TeXmacs/ plugins/ maxima/ lisp: maxima- 5.10.0. lisp maxima- 5.11.0. lisp maxima- 5.6.lisp maxima- 5.9.0.lisp maxima- 5.9.1.lisp maxima- 5.9.2.lisp 5.11.0- 1.1.x86_ 64.rpm, from: download. opensuse. org/repositorie s/science/ SUSE_Linux_ 10.0/repodata/ repoview/ maxima- 0-5.11. 0-1.1.html sourceforge. net/project/ showfiles. php?group_ id=4933& package_ id=4960& release_ id=473008 ,gcl(GCL) ,lisp(CMUCL) ,scl(SCL) ,sbcl(SBCL) ,lisp(ACL) ,openmcl( OpenMCL) maxima. sourceforge. net
> I came across this thread trying to solve the same issue with openSuse
> 10.3 x86_64 using both maxima versions 5.13.0-2.2 x86_64, 5.14.0-2.1
> x86_64 installed from:
>
> http://
>
> and TeXmacs 1.0.6.9-54 x86_64 installed directly from YaST.
>
> I have the same exact problem where using TeXmacs as a front end to
> maxima complains: "Unsupported version of maxima: 5.xx.x"
>
> I tried your advice to change the first line of the two scripts,
> maxima_detect and tm_maxima located in /usr/lib64/
> #!/bin/sh to #!/bin/bash.
>
> This does not fix the issue. I did however notice in the script
> tm_maxima that there is not even an entry for this recent version:
>
> It seems the only versions of maxima compatible with this version of
> TeXmacs have plugins located in /usr/share/
>
> The contents of this directory are as follows:
>
> -rw-r--r-- 1 root root 5126 2007-09-21 17:56 texmacs-
> -rw-r--r-- 1 root root 5128 2007-09-21 17:56 texmacs-
> -rw-r--r-- 1 root root 26027 2007-09-21 17:56 texmacs-
> -rw-r--r-- 1 root root 7449 2007-09-21 17:56 texmacs-
> -rw-r--r-- 1 root root 1471 2007-09-21 17:56 texmacs-
> -rw-r--r-- 1 root root 5239 2007-09-21 17:56 texmacs-
>
> I then tried uninstalling all previous versions of maxima and installed
> the newest one in the list, maxima-
>
> http://
>
> This one actually did not complain about versions when I launched
> TeXmacs but it did not run. It said it was "dead" instead of "idle". It
> also would not work from the terminal either whereas the newer ones did.
> It complained with the following:
>
> /usr/bin/maxima: unable to determine MAXIMA_PREFIX
>
> This RPM was built for openSuse 10.0 not 10.3 that I am using.
>
> So I next removed this package and grabbed the source for maxima-5.11.0
> here:
>
> http://
>
> I moved into the source directory and issued a ./configure to generate a
> makefile but I got this error:
>
> configure: error: No lisp implementation specified and none of the
> default executables
> clisp(clisp)
> were found in PATH
>
> So I went into YaST and installed clisp. After that finished I did
> another ./configure then a make and then a make install. This is what I
> get:
>
>
> Maxima 5.11.0 http://
>
> Using Lisp CLISP 2.41 (2006-10-13)
>
> Distributed under the GNU Public License. See the file COPYING.
>
> Dedicated to the memory of William Schelter.
>
> This is a development version of Maxima. The function bug_report()
>
> provides bug reporting information.
>
> Looks like it works... This took me quite some time to do but it appears
> to work. I now have to go through a tutorial to use it and will re post
> if it does not work.
>
> -Tim
>
>