Can't init Maxima session within TeXmacs

Same problem here; TeXmacs complains that maxima plug-ins aren't declared.

Maxima works in console mode, but however does not work with the Mascyma frontend. This could be a problem with maxima rather than TeXmacs.

What I find strange is that the last entry in changelog.Debian.gz is to say that the support for maxima had been re-enabled!

Confirmed. The problem is that the /bin/sh symlink to bash got replaced by dash for performance reasons. To resolve the bug, just edit /usr/lib/texmacs/TeXmacs/bin/maxima_detect and change to first line to #!/bin/bash

This possibly affects all scripts in /usr/lib/texmacs/TeXmacs/bin/

Could the package maintainer please fix the package and push the patches upstream. If a script is not compatible with sh (uses bash specific features) it has to point to /bin/bash. Therefore this is not a bug in Debian/Ubuntu, but rather an upstream problem.

Confirmed on edgy

Confirmed on Edgy, the package should be fixed.

There are still problem with the detection of mupad and maple, however.

The script tm_mupad is in perl, so there must be some other problem.

The script tm_maple does not work even after the fix sh -> bash.

tm_maple_5 is actually a binary file and I don't know what to do with it.

Actually

/usr/lib/texmacs/TeXmacs/bin/tm_maxima

still gives

ed Unsupported version of maxima:

even after the fix sh -> bash

but texmacs seems to recognize maxima anyway.

As a workaround:
$ sudo dpkg-reconfigure dash
and choose <No> to set /bin/sh -> bash

Maxima plugin is still broken in Gutsy: now the message is "plug-in 'maxima' not declared".

Maple is not even shown in the session list anymore, although I have it installed.

Nobody seems to care for texmacs plugins in Ubuntu, so texmacs is practically unusable as an interface to computer algebra programs for Ubuntu users, that's a pity.

The problem with maxima is still the old one: one has to modify maxima_detect by hands.

Maple is not listed anymore in the session list, but a session may be opened by chosing "other" and "maple". At the beginning did'nt work for me, but then I discovered the reason: the tm_maple script does "which maple" and could not find maple because I had it installed in /usr/local/maple9.5. I fixed this by making a link to /usr/bin. So it was essentially my fault, but I am citing this because it may happen to other people too, since Maple likes to install itself in that kind of locations.

Actually, that was also the reason of Maple not appearing in the session list (in Feisty it was found anyway, probably the script looked explicitly in /usr/local/maple9.5, it would be good to have it still working that way).

The other problem, cited in https://bugs.launchpad.net/ubuntu/+source/texmacs/+bug/73393, has been fixed in Gutsy, the needed file is now in src.9.

So things are working now with Maple, it just has to be discoverable by the command "which maple", which is reasonable.

Texmacs sessions for both Maxima and Octave plug-ins are broken and
files of both require some modifications to work at all. There may be more.

System facts:

Ubuntu Linux (Xubuntu) Release 7.10 (gutsy)

GNU/Linux 2.6.22-14-generic kernel

GNU Texmacs, version 1.0.6.10

Maxima 5.12.0
GNU Octave, version 2.1.73

Maxima:

Ubuntu is based on Debian. In Debian, /bin/sh is not a link
to /bin/bash. Instead /bin/sh is linked to but /bin/dash.
Consequently all shell scripts that reference #!/bin/sh are using
/bin/dash and not /bin/bash. This causes some scripts to fail.
Texmacs plug-in scripts are affected by this side effect and in particular
it is certain that the plug-in for Maxima is affected in this way.

Below are some files that may be affected in /usr/lib/texmacs/TeXmacs/bin:

./tm_xypic #!/bin/sh
./tm_dratex #!/bin/sh
./tm_gnuplot #!/bin/sh
./tm_eukleides #!/bin/sh
./tm_lush #!/bin/sh
./tm_matlab #!/bin/sh
./tm_lisp #!/bin/sh
./tm_maple #!/bin/sh
./tm_maxima #!/bin/bash
./fig2ps #!/bin/sh
./tm_mathematica #!/bin/sh
./r_install #!/bin/sh
./tm_gs #!/bin/sh
./maxima_detect #!/bin/bash
./tm_octave #!/bin/bash

These files may not work properly to start a Texmacs session
unless #!/bin/sh is changed to #!/bin/bash. Maxima is one of those that require
this change or the session will not work in Texmacs.

The scripts maxima_detect and tm_maxima both require this change.

Alternatively, /bin/sh may be linked to /bin/bash. However, there may be unknown
side effects elsewhere if /sh/dash is not used possibly. Should not be, but who knows.
In any case this change affects the entire operation system wherever /bin/sh is
referenced.

Octave:

The same comment for a Maxima session applies to Octave.
The script tm_octave requires this same change from #!/bin/sh to #!/bin/bash

In addition, there are changes to the syntax of Octave 2.1 that require changes
to some other files or error and warnings appear during the Texmacs Octave session.

Specifically the files tm-start and .octaverc in /usr/share/texmacs/TeXmacs/plugins/octave/octave
must be changed so that calls to gset are made to __gnuplot_set__ instead. The command gset
has been deprecated (as well as some others) in Octave and __gnuplot_set__ must be used
instead. The gset command appears on lines 8 and 9 in these two files and must be changed.

This change will prevent warnings and/or errors when a Texmacs Octave v2.1 session is started.
However, there are more issues here related to Octave sessions depending on the Octave command
entered. Some commands operate normally without any errors or warnings. Others produce error or
warning messages and may or may not operate as expected. This is because in addition to the
two files listed above there are various other files that are Octave scripts (.m) files in the subdirectories
./plot, ./polynomial, and ./tm of the same /usr/share/texmacs/TeXmacs/plugins/octave/octave directory.

These Octave script files are Octave interface support files for Texmacs. Some (not sure which) of these
files reference deprecated Octave commands and this is what is generating the error/warning messages
for some, but not all, Ocatve commands issued from the Texmacs Oc...

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., /op...

Same problem on Hardy Heron. Everything works but Maxima.

Randy LeJeune wrote:
> Same problem on Hardy Heron. Everything works but Maxima.
>
>
You might try changing the link from /bin/sh --> /bin/dash to /bin/sh
--> /bin/bash

I think the command would be:

sudo ln -sf /bin/bash /bin/sh

This should may the problem with Maxima sessions.

David E. Miller
.

> Same problem on Hardy Heron. Everything works but Maxima.

So the Maple and Mathematica plugin work?

Also confirming the issue on Hardy. I'm not sure why so many issues like this remain for several releases at a time before they are fixed...

I can think of several reason:
* There is a known workaround.
* This package are in universe.
* No active ubuntu mantainer.

So it probably will be fixed when it is fixed upstream (debian or maxima), or if someone contribute patches.

xhantt - You're probably right, but this bug is directly due to a change that Ubuntu made and didn't properly support. This stuff works in Debian because they use bash as /bin/sh. Using dash is great, but every package that it breaks is an Ubuntu bug that can't be pawned off on upstream.

I think that we all agree that for us it is necesary that these packages are fixed.

Well dash means debian alquimist shell, and I think it is a goal to debian that all shell script don't depend on bash, so still applies to debian, so fixing these scripts also may have interest to debian.

We have to interest someone that have enought skill to fix these scripts.

The fixes are already described in this page and are trivial, the main one is changing /bin/sh with /bin/bash in the first lines of the scripts. But who has the authority to apply them?

The fact that the fixes are trivial does not mean that there is no problem, the average user should not spend his day looking for fixes in order to use a program. Many will think that the program is just broken and give up.

There should be an ubuntu maintainer for texmacs and related packages, such as the scripts for the various sessions. I am not competent to do that, although I am a texmacs user and try to find workarounds for the problems I encounter.

Texmacs should be of special interest to this group:
https://help.ubuntu.com/community/UbuntuScience

By the way, pressure from the Ubuntu community could help texmacs to reach the degree of user-friendliness that would prompt its larger adoption.

Texmacs is a great program which is kept at 80% of its possibilities: it's one of the few technical innovations around, and it's really great (almost unique) to work with, but there are also some stumbling blocks that the developers have been underestimating for years, such as perfecting the session scripts, improving the graphical interface, bibliography management, styles availability, latex compatibility (although this one is not bad already), documentation. With some effort in these directions (which with some reason the developers expect should be done in part by the community) it would see much larger adoption, without it it's doomed to interest only a small niche of users (also considering that the physical-mathematical community is not large in itself).

There are also sinergies which are not exploited: a carefully tuned and well documented texmacs+scipy package could be a professional alternative to Matlab (it is harder to produce a professional alternative to Maple or Mathematica since there are no open-source project at the same level of perfection - I have not tried mathemagix yet but it seems to be in an early stage of development - and probably is draining resources away from texmacs).

After having solved the bash vs sh issue I get an "Unsupported version" message from TeXmacs. I have solved the problem by changing
file /usr/lib/texmacs/TeXmacs/bin/tm_maxima from

-------------------------------------------------
.....
.....
  5.10.*) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.10.0.lisp";;
  5.11.* | 5.12.* ) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.11.0.lisp";;
  cygwin)
    exec maxima.bat -p "`echo $TEXMACS_MAXIMA_PATH/texmacs-maxima-5.11.0.lisp|cygpath --windows -f -`";;
  *) echo -e "\2latex:\\red Unsupported version of maxima: $1\5"
esac
-------------------------------------------------

to

-------------------------------------------------
.....
.....
  5.10.*) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.10.0.lisp";;
  5.11.* | 5.12.* | 5.13.*) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.11.0.lisp";;
  cygwin)
    exec maxima.bat -p "`echo $TEXMACS_MAXIMA_PATH/texmacs-maxima-5.11.0.lisp|cygpath --windows -f -`";;
  *) echo -e "\2latex:\\red Unsupported version of maxima: $1\5"
esac
-------------------------------------------------

that is to say by adding the "| 5.13.*".

Now everything works fine.

David: Thanks! It works fine.
I second Andrea; TeXmacs is too innovative and brilliant a piece of software to be left in the state it is now, but I neither have the time nor the competence to do anything about it. sad, since a little work could lift TeXmacs from very promising to very good.

David Vonka, your solution really works fine! Thanks man! :D

I suggest this patch (adapted from the texmacs-user mailing list):

When texmacs starts a maxima session, it checks the version for
compatibility. maxima is being released more often. Version 1.0.6 of
texmacs only recognizes maxima up to 5.14, but works with maxima 5.16.
These changes allow any version up to 5.18.

--- /tmp/prev/tm_maxima 2008-11-05 10:17:37.000000000 -0500
+++ /usr/lib/texmacs/TeXmacs/bin/tm_maxima 2008-11-05 09:47:41.000000000 -0500
@@ -17,7 +17,7 @@
   5.9.1) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.9.1.lisp";;
   5.9.1.1* | 5.9.2* | 5.9.3*) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.9.2.lisp";;
   5.10.*) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.10.0.lisp";;
- 5.11.* | 5.12.* | 5.13.* | 5.14.*) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.11.0.lisp";;
+ 5.11.* | 5.12.* | 5.13.* | 5.14.* | 5.15.* | 5.16.* | 5.17.* | 5.18.*) exec maxima -u $1 -l $2 -p "$TEXMACS_MAXIMA_PATH/texmacs-maxima-5.11.0.lisp";;
   cygwin)
     exec maxima.bat -p "`echo $TEXMACS_MAXIMA_PATH/texmacs-maxima-5.11.0.lisp|cygpath --windows -f -`";;
   *) echo -e "\2latex:\\red Unsupported version of maxima: $1\5"
--- /tmp/prev/maxima_detect 2008-11-05 10:17:37.000000000 -0500
+++ /usr/lib/texmacs/TeXmacs/bin/maxima_detect 2008-11-05 09:47:41.000000000 -0500
@@ -63,7 +63,11 @@
 version 5.11
 version 5.12
 version 5.13
-version 5.14" >/dev/null
+version 5.14
+version 5.15
+version 5.16
+version 5.17
+version 5.18" >/dev/null
         then
           # 5.9.1 or 5.9.2 or 5.9.3 or 5.10 or 5.11 or 5.12 or 5.13 or 5.14
           maxima -d | grep -F 'maxima-htmldir=' | sed -e \

Incredible, David's workaround is the best.