New Axiom package
William Stein
Recently Waldek created a (forked) version of Axiom called "FriCAS",
which means "free CAS". He set things up so it builds and installs
in the SAGE environment in about 10-15 minutes (instead of hours
for the previous version of Axiom). I've created a SAGE package and
would like to request SAGE users to test out building this package on
OS X and Linux. To try the package just do this:
sage -i axiom4sage-0.3.1.spkg
After about 10-15 minutes you should then be able to do this:
sage -axiom
and see something like what is listed below. Thanks!
fermat:~/sage-2.7.3 was$ ./sage -axiom
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2007-07-19
Timestamp: Tuesday August 14, 2007 at 12:34:52
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
(1) -> 2 + 3
(1) 5
Type: PositiveInteger
(2) -> integrate(sin(x)*cos(x), x)
On 8/14/07, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
> On Tue, 14 Aug 2007, Bill Page wrote:
>
> |
> | Waldek
> |
> | We haven't heard much from you on this list lately. :-( I presume you
> | have been busy with other things or perhaps on vacation?
> |
> | On 7/27/07, you wrote:
> | > ...
> | > I have put a tarball at:
> | >
> | > http://www.math.uni.wroc.pl/~hebisch/prog/fricas-25.nn4.tar.bz2
> | >
> | > Configuration and dependencies are like in regular FriCAS build,
> | > the difference is that this tarball skips testsuite run (you
> | > can still run tests by hand typing "make all-input") and uses
> | > precompiled Lisp (and databases) for algebra build.
> | >
> | > Disclaimer: this is relatively quick hack, intended mostly as a
> | > proof of concept.
> | >
> |
> | Your "proof of concept" is about to be released to Sage users as a
> | package called 'axiom4sage-0.3.1'. If there are other things that you
> | think should be done on this build, please let's discuss it. (E.g. I
> | know you also experimented with a faster build that did not re-start
> | clisp for every algebra file. Does that work? Does it need more
> | testing?)
> |
> | Anyway, here is a very small patch needed to build this version of
> | FriCAS on MAC OSX:
> |
> | page@sage:~/packages$ diff -au
> | axiom4sage-0.3/src/configure.ac.pamphlet
> | axiom4sage-0.3.1/src/configure.ac.pamphlet
> | --- axiom4sage-0.3/src/configure.ac.pamphlet 2007-07-27
> | 03:36:44.000000000 -0700
> | +++ axiom4sage-0.3.1/src/configure.ac.pamphlet 2007-08-14
> | 06:40:43.000000000 -0700
> | @@ -530,7 +530,7 @@
> | *solaris*)
> | AC_DEFINE([SUNplatform], [], [SunOS flavour])
> | ;;
> | - powerpc*darwin*)
> | + *darwin*)
> | AC_DEFINE([MACOSXplatform], [], [MACOX flavour])
> | CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE \
> | -I/usr/include -I/usr/include/sys"
> | page@sage:~/packages$
> |
> | -----------
> |
> | Of course you also need to run 'build-setup.sh'.
> |
> | I think the change is self-explanatory: Not all MAC OSX systems
> | identify themselves as "powerpc...". I think '*darwin*' will be
> | sufficient, right?
>
> I believe that is OK. When I put that pattern in, I was being overly
> conservative at the time.
>
> -- Gaby
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://www.williamstein.org
Mike Hansen
The build worked perfectly with SAGE 2.7.3 on Ubuntu 7.04 on a Core 2 Duo.
--Mike
Jaap Spies
> for the previous version of Axiom). I've created a SAGE package and
> would like to request SAGE users to test out building this package on
> OS X and Linux. To try the package just do this:
>
> sage -i axiom4sage-0.3.1.spkg
>
> After about 10-15 minutes you should then be able to do this:
79 Axiom installation finished.
real 12m24.290s
user 10m40.994s
sys 0m59.883s
Successfully installed axiom4sage-0.3.1
Now cleaning up tmp files.
Making SAGE/Python scripts relocatable...
Making script relocatable
[jaap@paix sage-2.8]$
The installation could be more silent or if you prefer less verbose!
Jaap
PaulOli...@gmail.com
(and I tried installing the publicly-available optional Axiom package
yesterday and that didn't work)
Paul
Axiom installation finished.
real 10m17.685s
user 8m5.767s
sys 1m27.710s
Successfully installed axiom4sage-0.3.1
Now cleaning up tmp files.
Making SAGE/Python scripts relocatable...
Making script relocatable
paul-olivier-dehayes-computer:~ pdehaye$
Alex Ghitza
Hash: SHA1
Installed successfully on Dell Latitude D620 (Core Duo T2400 1.83GHz)
running Gentoo and sage-2.8. It's slow because the laptop was running
on battery, and hence throttled down.
real 29m12.096s
user 26m1.034s
sys 1m22.641s
Successfully installed axiom4sage-0.3.1
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGwehedZTaNFFPILgRAvbnAKCom1ymjtLZFKlFzWZHcSFbIY7uiQCfT+d+
5nFtGHleE7G4N9fDcb3BuM4=
=1dLp
-----END PGP SIGNATURE-----
David Joyner
On 8/14/07, William Stein <wst...@gmail.com> wrote:
>
Bill Page
>
> Worked for me too, MacOSX MacBook.
> (and I tried installing the publicly-available optional Axiom package
> yesterday and that didn't work)
> Paul
>
The previous optional package 'axiom4sage-0.1.1' is compatible only
with versions of Sage prior to 2.8.1 and builds on a more restricted
range of machines using GCL rather than Clisp.
The new 'axiom4sage-0.3.1' includes several important bug fixes as
well as the new GUESS package:
http://arxiv.org/abs/math/0702086
Extended Rate, more GFUN
Authors: Martin Rubey
Abstract: We present a software package that guesses formulae for
sequences of, for example, rational numbers or rational functions,
given the first few terms. Thereby we extend and complement Christian
Krattenthaler's program Rate and the relevant parts of Bruno Salvy and
Paul Zimmermann's GFUN.
See also:
http://wiki.axiom-developer.org/GuessingFormulasForSequences
For example:
sage: r=[0,3,32,375,5184,84035]
sage: R=axiom(r).guessExpRat(); R
n
[[function= n (n + 2) ,order= 0]]
sage: f=axiom('%s.1.function'%N.name()); f
n
n (n + 2)
sage: f.type()
Expression Integer
sage: f.eval(axiom('n=5'))
84035
sage: f.eval(axiom('n=6'))
1572864
sage:
Regards,
Bill Page.
PaulOli...@gmail.com
displaying of rational functions (but probably wrapping too)...
I paste this:
----------------------------------------------------------------------------------------------------------------------------------------------
k = var('k')
tmp = [rising_factorial(x,k)/falling_factorial(x,k) for k in range(5)]
pol1 = axiom(tmp[1])
pol1
pol1
pol1
pol4 = axiom(tmp[4])
pol4
pol4
pol4
pol4
pol4
pol4
pol4
pol4
pol1 = axiom(tmp[1])
pol1
pol1
pol1
pol1
pol1
pol1
pol1
pol1
----------------------------------------------------------------------------------------------------------------------------------------------
and get
----------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------
| SAGE Version 2.8, Release Date: 2007-08-12 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading SAGE library. Current Mercurial branch is: paul
sage: k = var('k')
sage: tmp = [rising_factorial(x,k)/falling_factorial(x,k) for k in
range(5)]
sage:
sage: pol1 = axiom(tmp[1])
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol4 = axiom(tmp[4])
sage: pol4
sage: pol4
sage: pol4
- (0)) * ((x) - (1))) * ((x) - (2))) * ((x) - (3)))
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol4
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol1 = axiom(tmp[1])
sage: pol1
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol1
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol1
3 2
x + 6x + 11x + 6
------------------
3 2
x - 6x + 11x - 6
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage:
----------------------------------------------------------------------------------------------------------------------------------------------
Notice how when I ask for "sage: pol4" I first get blanks a few times,
then bits of the (presumably) internal representation, then what
should be displayed. And that pol4 keeps on coming when I ask for
"sage: pol1".
That seems like a first serious bug. It also hangs when I try to do
comvert SAGE rational functions to axiom rational functions without
displaying them.
I am running SAGE 2.8 on a MacBook under MacOSX
Paul
On Aug 14, 9:53 pm, "Bill Page" <bill.p...@newsynthesis.org> wrote:
Bill Page
>
> It build fine but the I/O is seriously bugged for me, at least for the
> displaying of rational functions (but probably wrapping too)...
Thanks for the report. I will look into it.
Do other things work ok? E.g. this script that posted earlier:
Bill Page
> displaying of rational functions (but probably wrapping too)...
Oops, for the full axiom interface to work reliably you need
sage-2.8.1 or the following patch:
http://sage.math.washington.edu/home/page/axiom.py-0.3.patch
(Not required just to run 'sage -axiom'.)
On 8/13/07, William Stein <wst...@gmail.com> wrote:
> Thanks. I've applied this for sage-2.8.1.
>
> On 8/13/07, Bill Page <bill...@newsynthesis.org> wrote:
> > On 8/13/07, William Stein <wst...@gmail.com> wrote:
> > > Please resend your patch as an email attachment or post it somewhere
> > > and send me a link. Your emailing + my email client mangled it.
> > >
> >
> > Sorry. Here's a link:
> >
> >
> > http://sage.math.washington.edu/home/page/axiom.py-0.3.patch
> >
> >
>
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://www.williamstein.org
>
Regards,
Bill Page.
PaulOli...@gmail.com
example, even after installing the patch. it does produce interesting
errors...
----------------------------------------------------------------------
| SAGE Version 2.8, Release Date: 2007-08-12 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: sage: r=[0,3,32,375,5184,84035]
sage: sage: r=[0,3,32,375,5184,84035]
sage: sage: R=axiom(r).guessExpRat(); R
n
[[function= n (n + 2) ,order= 0]]
sage: sage: R=axiom(r).guessExpRat(); R
[0,3,32,375,5184,84035]
sage: sage: R=axiom(r).guessExpRat(); R
sage: sage: R=axiom(r).guessExpRat(); R
84035
sage: sage: R=axiom(r).guessExpRat(); R
= [sage0,sage1,sage2,sage3,sage4,sage5]
:= guessExpRat(sage6)
= 5184
5184
sage: sage: R=axiom(r).guessExpRat(); R
375
sage: sage: R=axiom(r).guessExpRat(); R
32
sage: sage: R=axiom(r).guessExpRat(); R
3
On Aug 15, 7:57 am, "Bill Page" <bill.p...@newsynthesis.org> wrote:
> On 8/14/07, PaulOlivierS...@gmail.com <PaulOlivierS...@gmail.com> wrote:
>
>
>
> > It build fine but the I/O is seriously bugged for me, at least for the
> > displaying of rational functions (but probably wrapping too)...
> > ...
>
> Oops, for the full axiom interface to work reliably you need
> sage-2.8.1 or the following patch:
>
> http://sage.math.washington.edu/home/page/axiom.py-0.3.patch
>
> (Not required just to run 'sage -axiom'.)
>
> On 8/13/07, William Stein <wst...@gmail.com> wrote:
>
>
>
> > Thanks. I've applied this for sage-2.8.1.
>
Bill Page
>
> no, the problem is most definitely still there, in both your and my
> example, even after installing the patch. it does produce interesting
> errors...
>
I can not reproduce these errors on the sage.math server (Linux) but
careful testing on MAC OSX of *exactly* the same code including the
axiom.py-0.3.patch, I find that it does *randomly* produce the kind of
errors you describe.
There followed a long night of debugging... I have finally determined
that the problem is caused by readline in Clisp. The use of readline
in the pexpect interface seems to cause problems on some systems but
not on others. I noticed that this problem does not occur in Maxima
even though Maxima is built using Clisp because Maxima itself is run
in the maxima.py interface with readline disabled. Unfortunately, so
far as I can tell there is no similar way to dynamically disable
readline in Axiom if it is built using Clisp. How this might be done
depends on the version of Lisp. I can find a method of GCL but not for
Clisp. If anyone knows how to do this (or even how Maxima does this
internally), please let me know.
So as a last resort I modified the Clisp spkg-install script to call
./configure --without-readline ...
and re-built Clisp without readline linked in. Then I recompiled
axiom4sage-0.3.1 and now everything is working properly on both Linux
and MAC OSX!
How much objection would there be to building Clisp in Sage without
readline support?
Regards,
Bill Page.
Test results:
Using my original script
---- copy -----
r=[0,3,32,375,5184,84035]
R=axiom(r).guessExpRat(); R
f=axiom('%s.1.function'%R.name()); f
f.type()
f.eval(axiom('n=5'))
f.eval(axiom('n=6'))
---- paste -----
I get the following when pasting it into a Sage console session:
page@sage:~/sage-2.8$ ./sage
----------------------------------------------------------------------
| SAGE Version 2.8, Release Date: 2007-08-12 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading SAGE library. Current Mercurial branch is: test
sage: r=[0,3,32,375,5184,84035]
sage: R=axiom(r).guessExpRat(); R
n
[[function= n (n + 2) ,order= 0]]
sage: f=axiom('%s.1.function'%R.name()); f
n
n (n + 2)
sage: f.type()
Expression Integer
sage: f.eval(axiom('n=5'))
84035
sage: f.eval(axiom('n=6'))
1572864
sage: exit
Exiting SAGE (CPU time 0m0.05s, Wall time 0m24.78s).
Exiting spawned Axiom process.
And with Paul's script:
----- copy -------
k = var('k')
tmp = [rising_factorial(x,k)/falling_factorial(x,k) for k in range(5)]
pol1 = axiom(tmp[1])
pol1
pol1
pol1
pol4 = axiom(tmp[4])
pol4
pol4
pol4
pol4
pol4
pol4
pol4
pol4
pol1 = axiom(tmp[1])
pol1
pol1
pol1
pol1
pol1
pol1
pol1
pol1
---- paste --------
I get the result:
page@sage:~/sage-2.8$ ./sage
----------------------------------------------------------------------
| SAGE Version 2.8, Release Date: 2007-08-12 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading SAGE library. Current Mercurial branch is: test
sage: k = var('k')
sage: tmp = [rising_factorial(x,k)/falling_factorial(x,k) for k in range(5)]
sage:
sage: pol1 = axiom(tmp[1])
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol4 = axiom(tmp[4])
sage: pol4
3 2
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: pol1
1
sage: exit
Exiting SAGE (CPU time 0m0.09s, Wall time 0m11.02s).
Exiting spawned Axiom process.
page@sage:~/sage-2.8$
-----------
This now looks ok to me on both sage.math and on the MAC OSX test system.
Bill Page
> ...
> How much objection would there be to building Clisp in Sage without
> readline support?
Alternatively assuming no dynamic method of disabling readline for
Clisp is found, I guess I could use the clisp*.spkg source to build a
local copy of clisp without readline support during the axiom4sage
spkg-install. This would make the Axiom install significantly longer,
but otherwise would be transparent to the rest of Sage.
Regards,
Bill Page.
David Joyner
an idea:
(1) try building SAGE using Clisp without readline support,
check for warnings etc,
(2) run sage -testall, check for broken tests.
(3) report problems to the lists.
Would that add useful information?
++++++++++++++++++++++++++++++++++++++++
William Stein
> Maybe this is more work than you want to get into but here's
> an idea:
> (1) try building SAGE using Clisp without readline support,
> check for warnings etc,
> (2) run sage -testall, check for broken tests.
> (3) report problems to the lists.
> Would that add useful information?
The SAGE clisp *must* be built with readline support. If you don't do that,
then, e.g., maxima_console() would not have readline support, which would
be a very miserable experience.
It's almost certainly possible to program around the readline problem
in axiom.py
by using some more complicated code there to synchronize things.
That's probably
the way to go. And, of course, figuring out how maxima can disable readline
at startup is well worth doing.
-- William
Bill Page
>
> Maybe this is more work than you want to get into but here's
> an idea:
> (1) try building SAGE using Clisp without readline support,
> check for warnings etc,
> (2) run sage -testall, check for broken tests.
> (3) report problems to the lists.
> Would that add useful information?
>
Yes, I could/will easily do this. I have no reason to believe that any
tests would fail, but of course it is good to check. The main
difference would be felt by those people who use -clisp, -maxima, or
-axiom in console-mode. These users would no longer have line-editing
support. This is the main reason why I would hesitate to suggest this
option. Being able to dynamically disable it for use with pexpect
would be much nicer.
After looking into the Maxima code a little more, I doubt what I said
about --readline-off is true. It seems that this option only applies
to Maxima built using GCL. And now checking the code in maxima.py
again too, it seems that recent versions definitely don't use this
option. But maxima.py does use the
(setf *general-display-prefix* "<sage-display>")
option to help implement a general "resynchronization" protocol which
perhaps prevents this from happening so often when using Maxima from
Sage. So it seems to me that even the reliability of Maxima on
different hardware is likely to be improved by the use of Clisp built
--without-readline. Does anyone no of any test cases now for Maxima
that seem to fail due to the communication between Maxima and Sage?
Regards.
Bill Page.
William Stein
> tests would fail, but of course it is good to check. The main
> difference would be felt by those people who use -clisp, -maxima, or
> -axiom in console-mode. These users would no longer have line-editing
> support. This is the main reason why I would hesitate to suggest this
> option.
Exactly. This is not an option.
> After looking into the Maxima code a little more, I doubt what I said
> about --readline-off is true. It seems that this option only applies
> to Maxima built using GCL. And now checking the code in maxima.py
> again too, it seems that recent versions definitely don't use this
> option. But maxima.py does use the
>
> (setf *general-display-prefix* "<sage-display>")
>
> option to help implement a general "resynchronization" protocol which
> perhaps prevents this from happening so often when using Maxima from
> Sage. So it seems to me that even the reliability of Maxima on
> different hardware is likely to be improved by the use of Clisp built
> --without-readline. Does anyone no of any test cases now for Maxima
> that seem to fail due to the communication between Maxima and Sage?
Maxima should never ever fail due to communication between SAGE and Maxima.
I spent a lot of time making sure of that a few months ago, when we were rolling
out the calculus functionality, which uses the maxima interface very
very heavily.
When you doctest the SAGE_ROOT/devel/sage/sage/calculus directory, there are
literally hundreds of different and subtle interactions between SAGE and maxima
via the interface -- some involving expecting interactive questions
about input, etc.,
and it all happens very very quickly, but it works perfectly every time now.
It just took a lot of work refining how the maxima interface works --
it resynchronizes
itself before every interaction by putting "random number + 1" in the
input and waits
for the result of that arithmetic, etc. I'm sure the axiom interface
could do something
similar.
William
Bill Page
> ...
> Maxima should never ever fail due to communication between SAGE and
> Maxima. I spent a lot of time making sure of that a few months ago, when
> we were rolling out the calculus functionality, which uses the maxima interface
> very very heavily.
> When you doctest the SAGE_ROOT/devel/sage/sage/calculus directory, there
> are literally hundreds of different and subtle interactions between SAGE and
> maxima via the interface -- some involving expecting interactive questions
> about input, etc., and it all happens very very quickly, but it works perfectly
> every time now.
Wonderful.
> It just took a lot of work refining how the maxima interface works --
> it resynchronizes itself before every interaction by putting
> "random number + 1" in the input and waits for the result of that
> arithmetic, etc. I'm sure the axiom interface could do something
> similar.
Yes, I saw your new resynchronization code in 'maxima.py' and I was
**amazed** ! :-) It seems to me that you have gone to heroic lengths
to ensure that there is a way to recover from these sort of
communications problems. (At least Axiom never tries to ask the
console user a question!) I would be very interested to know how
often communications with Maxima have to be resynchronized during an
intensive interaction. If the need for resynchronization is occurring
often even when Maxima is not asking questions, and *if* this is due
to readline/pexpect interactioin - as I am now sure it is in the case
of Axiom - then it seems to me that preventing communications problems
in the first place and eliminating the (possible) spurious need for
resynchronization might make things more efficient.
I was thinking about how to do this resynchronization in 'axiom.py'
but then I realized that in my tests this was actually happening
because pexpect was (sometimes) returning a matched prompt string in
'expect.after' even though the contents of 'expect.before' did not
contain the complete output that leads up to that prompt and then it
would return the same buffer a second (and sometimes third) time, each
time a little more complete before. As a result the communications get
out of sync. This problem entirely disappears when I rebuild with
readline disabled. Maybe it is a bug in pexpect. But as you implied,
these problems seem to be exceeding difficult to debug. It is easier
to work around them. I think that to really do this right we need
better syntactical markup in the Axiom output like is possible in
Maxima.
Regards,
Bill Page.
William Stein
>
> > It just took a lot of work refining how the maxima interface works --
> > it resynchronizes itself before every interaction by putting
> > "random number + 1" in the input and waits for the result of that
> > arithmetic, etc. I'm sure the axiom interface could do something
> > similar.
>
> Yes, I saw your new resynchronization code in 'maxima.py' and I was
> **amazed** ! :-) It seems to me that you have gone to heroic lengths
> to ensure that there is a way to recover from these sort of
> communications problems. (At least Axiom never tries to ask the
> console user a question!) I would be very interested to know how
> often communications with Maxima have to be resynchronized during an
> intensive interaction. If the need for resynchronization is occurring
> often even when Maxima is not asking questions, and *if* this is due
> to readline/pexpect interactioin - as I am now sure it is in the case
> of Axiom - then it seems to me that preventing communications problems
> in the first place and eliminating the (possible) spurious need for
> resynchronization might make things more efficient.
No. It will make the communications overhead maybe 50% better, but
it would be far far less robust. And robustness is critically important.
Also, random things can happen to mess up certain interfaces, e.g., the
user hits control-C. If you want a rock solid interface,
synchronizing (or dividing
things up into clear transactions) is necessary.
> I was thinking about how to do this resynchronization in 'axiom.py'
> but then I realized that in my tests this was actually happening
> because pexpect was (sometimes) returning a matched prompt string in
> 'expect.after' even though the contents of 'expect.before' did not
> contain the complete output that leads up to that prompt and then it
> would return the same buffer a second (and sometimes third) time, each
> time a little more complete before. As a result the communications get
> out of sync. This problem entirely disappears when I rebuild with
> readline disabled. Maybe it is a bug in pexpect. But as you implied,
> these problems seem to be exceeding difficult to debug. It is easier
> to work around them. I think that to really do this right we need
> better syntactical markup in the Axiom output like is possible in
> Maxima.
Better markup would be very nice indeed. Best of luck with all this.
Do consider synchronization.
-- William
Bill Page
If you have a moment to spare, could you please try this *additional(
patch for axiom.py in sage-2.8:
http://sage.math.washington.edu/home/page/axiom.py-0.3.1.patch
----------
bsd:~/sage-2.8/devel page$ diff -au
./sage-main/sage/interfaces/axiom.py
./sage-test/sage/interfaces/axiom.py
--- ./sage-main/sage/interfaces/axiom.py 2007-08-15
11:27:03.000000000 -0700
+++ ./sage-test/sage/interfaces/axiom.py 2007-08-15
11:30:33.000000000 -0700
@@ -159,7 +159,7 @@
Expect.__init__(self,
name = 'axiom',
prompt = '\([0-9]+\) -> ',
- command = "axiom -nox -noclef",
+ command = "sh -c 'cat|axiom -nox -noclef'",
maxread = 10,
script_subdirectory = script_subdirectory,
restart_on_ctrlc = False,
bsd:~/sage-2.8/devel page$ diff -au
./sage-main/sage/interfaces/axiom.py
./sage-test/sage/interfaces/axiom.py > ~/axiom.py-0.3.1.patch
bsd:~/sage-2.8/devel page$
----------
This second patch should be applied after the earlier one:
http://sage.math.washington.edu/home/page/axiom.py-0.3.patch
One the MAC OSX system that I am using for test, this change cures the
problems that you reported. The excuse for this funny construction:
sh -c 'cat|axiom -nox -noclef'
is that it causes Clisp to disable readline.
Please let me know if it works for you.
Regards,
Bill Page.
On 8/15/07, PaulOli...@gmail.com <PaulOli...@gmail.com> wrote:
>
> no, the problem is most definitely still there, in both your and my
> example, even after installing the patch. it does produce interesting
> errors...
>
> ----------------------------------------------------------------------
> | SAGE Version 2.8, Release Date: 2007-08-12 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
>
> sage: sage: r=[0,3,32,375,5184,84035]
> sage: sage: r=[0,3,32,375,5184,84035]
> sage: sage: R=axiom(r).guessExpRat(); R
>
> n
> [[function= n (n + 2) ,order= 0]]
> sage: sage: R=axiom(r).guessExpRat(); R
> [0,3,32,375,5184,84035]
> ...
PaulOli...@gmail.com
change you said manually and both your example and mine work now.
Thanks! Now off to play with GUESS on some neat polynomials...
Paul
Bill Page
Sorry, the file was on the wrong machine. I have moved it so this link
should now work:
http://sage.math.washington.edu/home/page/axiom.py-0.3.1.patch
> but I applied the change you said manually and both your example and
> mine work now.
Excellent.
> Thanks! Now off to play with GUESS on some neat polynomials...
You are welcome. Have fun. I am sure that Martin Rubey would be happy
to discuss the program with you if you have any questions.
Regards,
Bill Page.