I reran the test and it passed. sage -maxima works fine. I did
realize that I said something incorrect, it looks like the install I
am using was originally from the 3.2.1.rc0 source, and I have upgraded
and renamed it several times since then. So it is not too weird an
event. Some of the c source code still makes references to the
sage-3.2.1.rc0 folder. I assume a complete rebuild would probably fix
that.
-Marshall
On Dec 19, 10:07 am, mabshoff <mabsh...@googlemail.com> wrote:
> On Dec 19, 5:21 am, mhampton <hampto...@gmail.com> wrote:
>
> > I had an interesting failure on an intel mac running 10.5. Let me
> > describe my setup a bit since I think its relevant: because of the new
> > upgrade flexibility, I decided to have a "stable" sage and an
> > "unstable" sage on my machine, and I delete almost all of my other
> > sage builds. I changed the sage script in my /usr/bin to point to the
> > unstable one, which I called "wildsage". One of the sage folders I
> > deleted was for 3.2.1.rc0. With all that in mind, here is the error I
> > got in qqbar:
>
> > sage -t "devel/sage/sage/rings/qqbar.py"
> > Exception exceptions.TypeError: TypeError(RuntimeError('Unable to
> > start maxima',),) in 'sage.structure.parent_old._unregister_pair'
> > ignored
>
> <SNIP>
>
> > It looks like its trying to use the maxima from my deleted 3.2.1.rc0
> > build for some reason.
>
> Something else looks wrong, i.e the string "3.2.1.rc0" should not
> appear in the backtrace at all. There can be numerous issues like a
> bungled SAGE_ROOT setting at some point that is now causing trouble.
> Does maxima from that install work via "sage -maxima"? Just because
> the doctest claims that is doesn't start does not mean that it doesn't
> work in general. I would also check the repos for unresolved merges,
> multiple heads and so on. Some environment variable can also play a
> role here. Since linking the sage script just works I would always
> recommend linking it into $PATH somewhere under a different name
> instead of setting $SAGE_ROOT manually as recommended in the
> documentation since it is too easy to scrw that up. The checking code
> if SAGE_ROOT is overwritten also makes it too still possible to shoot
> yourself in the foot.
>
> > My ppc powerbook is still slaving away on tests, its almost done and
> > so far just has timeout failures on eisenstein and calculus.py.
>
> Ok. I would suggest to rerun the failed tests with -long to see what
> happens. If the CPU usage stays near 0 it is a synchronization /
> maxima issue, but the timeout will be raised after 30 minutes.
>
> > -M. Hampton
>
> Cheers,
>
> Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
