On 6/24/2011 8:40 AM, Johan de Kleer wrote:
> Thanks for your answer. I should describe my application. I have a
> large Allegro Lisp application that now needs to do symbolic
> manipulation. I could interface with Matlab/Mathematica but thats a
> lot of new learning and I won't have the source.
>
> Since you have done this before let me ask you a question. If I have
> maxima running (with run), any other listener's read-eval-print is
> disabled which is a real pain. A lot of my problems went away when I
> dynamically bind some critical variables in run like *debugger-hook*,
> *readtable*,.... The current Macsyma doesn't rebind them and clobbers
> them globally??????????
The Macsyma/Maxima read-eval-print loop has grown over the years to
include a host of hacks to allow it to run in various incompatible
lisps. In addition to which, some people have just written their own
front ends (like wxmaxima) in non-Lisp languages, to make themselves
more comfortable, and perhaps more portable over different operating
systems.
wxmaxima allows a user to type on a command line :lisp (defun .....
whatever)
and so it must change back the readtable and such to normal lisp, at
least when parsing the rest of that line.
there is also a function to_lisp()
which puts you in a lisp REPL until you type (to-maxima).
So this is something other people have done.
On the other hand, I don't know exactly how they've done it and I don't
know what dbm-read is really supposed to do.
If I have a program calling something in Maxima, I never use Maxima's
front end. I compose the problem and create the data, and
call the appropriate program. e.g. to compute polynomial gcd, I do
(pgcd A B).
As far as multivariate polynomials -- they do form a Euclidean domain;
considered recursively in variables v1,v2,...,vn, a polynomial ring in
v1 whose coefficients are (recursively) polynomials in v2 , ... vn ...
are just fine.
Maxima has Grobner basis calculations, but unless you absolutely need
this, it is generally to be avoided.
Solving systems of polynomial constraints may be done by computing
resultants.
I hope this is of some use.
RJF
>
> My current problem is that if one Listener is running maxima,
> read-eval-print is broken for every othre one. And I cannot figure
> out the problem. After some hours I've isolated it to a read-char in
> dbm-read. If that read-char is waiting for a character all the other
> Listener's cannot eval. So there is some other variable Maxima is
> setting globally which is causing the problem that I have not
> identified. Any idea of which? One clue is that if I print out
> messages to the listener in dmb-read those same messages gets read by
> dbm-read and it gets obvious syntax errors. Or, if I don't, things
> are sensitive to the delay, so just sleeping a bit or printing out
> something causes an error too many characters to unread. Something is
> very messed up in the reading/processes inside of dbm-read but I
> cannot figure out what the problem is. Very very bizarre behavior.
>
> BTW, since you are an expert. The first I need is multivareate
> polynomial gcd. They do not form a Euclidean domain so I need Grobner
> bases which I assume this Macsyma does?
>
>
>
> At 07:39 AM 6/24/2011, Richard Fateman wrote:
>> On 6/23/2011 1:06 PM, dekleer at parc.com <mailto:dekleer at parc.com> wrote:
>>> I see a number of emails about using Allegro. However, I downloaded
>>> the latest version and it seems to have many problems. I managed to
>>> get Macsyma to work, but its still fragile. Am I using a wrong
>>> version? I have Allegro 8.2 and 5.24.0. I used configure.lisp to
>>> create Maxima. A few of the problems are:
>>>
>>> - Case errors in package names, e.g., the source uses
>>> (in-package "BIGLOAT") and (in-package "bigfloat") interchangeably.
>>> - Share-subdirs.lisp does not get created. So I have to
>>> construct it by hand.
>>> - Some of the $file_... search pathnames are incorrect.
>>> Some of the pathnames have "//" which are not legal under Windows.
>>> Source of the problem seems to be whatever sets **maxima-userid**
>>> - Error handling (i.e., catch tags) does not work.
>>> Haven't debugged that yet.
>>>
>>> I'm willing to upload these and other fixes. But I suspect someone
>>> must have done this all before judging from the email traffic.
>>>
>>> _______________________________________________
>>> Maxima mailing list
>>> Maxima at math.utexas.edu <mailto:Maxima at math.utexas.edu>
>>>
>>> http://www.math.utexas.edu/mailman/listinfo/maxima
>> I have built Maxima on Allegro a number of times, and it (Maxima) is
>> not entirely satisfactorily configured for Allegro
>> when Allegro is run in my favorite mode (in which upper and lower
>> case are used). But if I use Allegro in the upper-casifying "ANSI"
>> mode, which is, I think, the default for the free system, then it
>> generally works. I have not tried to bring up the interface to gplot
>> or wxmaxima, so I don't know if it works.
>>
>> For some systems, a package name can appear as :bigfloat :BIGFLOAT
>> "BIGFLOAT" and be the same. I think it should be :bigfloat, but at
>> least it should always be the same.
>>
>> I have not used makefile at all, and have not constructed the share
>> subdirectories. Macsyma originally had (and still has) a
>> lisp-language makefile kind of thing to build a system. I have long
>> ago given up on the notion of keeping that up to date, and now
>> building Maxima depends on a raft of other tools, some of which are
>> handy and standard in ways that ANSI CL may not be, some of which are
>> superfluous and represent some habit inherited from some programmer's
>> previous projects.
>>
>> Maxima code should be conditionalized for error handling since (I
>> think) GCL doesn't conform to ANSI. so some of the
>> conditionalizations like #+CMU might need to be changed to #+(or
>> CMU Franz) or some such.
>>
>> You may, in fact, have gone further than I have in pushing Maxima
>> through the free Allegro. Note: I was not able to compile all the
>> converted-from-fortran stuff in the free Allegro. At least a few
>> years ago. But it DOES compile in a paid-up copy, and can be loaded
>> into a free Allegro. I don't know about now.
>>
>> If you have strong reasons to use Maxima in a free Allegro, maybe we
>> should talk. As it is, there is not exactly a groundswell for
>> setting this up, and Franz Inc doesn't seem to care one way or the
>> other. [It represents no income, so that is fair business assessment!]
>>
>> RJF