Many Maple users have a preference of user interface, whether it be command line (TTY), Standard (Worksheet or Document mode), or Classic. My personal view is that each may be suited for different types of task. While it's understood that Maplesoft is dedicated to supporting the Standard interface, I understand that some users remain devoted to the Classic interface.
I often use Maple 10 on a 64bit Linux machine, on which the performance of the 64bit Maple 10 kernel is comparatively faster for some types of computation. I discussed this briefly in an earlier post. But there is no officially released 64bit Linux port of the Classic interface. So below I'll mention an unofficial and unsupported way to use the 64bit Linux Maple kernel with the 32bit Linux Maple Classic interface.
One reason that this is possible at all is that Maple interfaces communicate with running Maple kernel processes over sockets. The interface binaries are not compiled and linked to the kernel binaries.
First I'll give a disclaimer. This is not an officially supported release. I've tried to lay it out in such a way that it does not interfere with the ability of the other interfaces to function properly. If you are not familiar with Linux tools such as tar, etc, or don't understand any of what I've written below, or are doubtful of your ability to alter your Maple installation in any way, then don't try it. It'd be a good idea to back up or copy your Maple installation first too, if you cannot easily re-install it if something goes wrong for you here.
Let's assume that you have both the (x86) 32bit Linux versions and either of the (x86-64 or IA-64) 64bit Linux versions of Maple 10 installed and working under the same base location. See part 1 if running the 32bit version on a 64bit machine is unfamiliar to you.
For simplicity, let's call your installation location .
I've attached two .tgz files
which each contain a new directory containing only symlinks and an example of an edited version of the maple script.
Untar the file appropriate for your platform and move the directory or to the base directory of the Maple 10 installation, ie, immediately within . So now there is a new directory or . You might observe that this new directory contains symlinks to binaries already installed.
Now, you'll need to have a version of the maple script which knows how to make use of the new directory. Usually the maple script is located in the subdirectory under the Maple installation location, eg, as . I suggest placing a new, edited version of the script into some other directory in your PATH that would be found before that, eg, . I suggest that because it's conceivable that some future point-release update to the Maple installation might clobber any edits were they instead made to the original script.
The key edit to the script is that at a platform-specific location two lines
echo "Classic Worksheet is not available for this platform. Use the xmaple or maple -x to start the Standard Worksheet."
are replaced by
The modified versions of the maple script within the .tgz files are there to illustrate the above edit. You wouldn't be able to use the actual script files in the .tgz archive unless you also edited the line which set the base location variable . In the x86-64 version that I attached, that location is set to and your Maple 10 is very likely not installed there. So you couldn't use that exact file unless you also edited the line that set the base location variable . The reason that I include these edited script versions is that they should show precisely which two platform-specific lines get edited as above.
I've noticed that when using the 32bit Classic interface combined with the 64bit Maple kernel the status bar will show memory allocation that is off by a factor of two. I presume that this is because the kernel communicates the amount of memory allocated by passing a figure in terms of words of information. The difference in wordsize between the two platforms would then explain that discrepency.
Other than that, I've had good experience with it so far. Inline OpenGL plots, help, Maplets, x11 plotdevice plots, and computations appear to work ok.
As mentioned before, this is not an officially supported process. It'd probably be a good idea to move aside the new bin.XXX directory temporarily before doing any point-release update.
Thanks go to Allan, for the much cleaner layout than what I had originally.
View file details
View file details