Opened 13 years ago
Closed 13 years ago
#5111 closed enhancement (fixed)
[with patch, positive review] axiom --> fricas ?
Reported by: | was | Owned by: | mhansen |
---|---|---|---|
Priority: | blocker | Milestone: | sage-3.4.2 |
Component: | interfaces | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | Work issues: | ||
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
Should we change axiom.py to fricas.py and the axiom command to fricas.
For the change: This is more logical since the doctests test fricas not axiom. Also, this has been specifically requested by Tim Daly -- the trademark owner on the name Axiom.
Against the change: We have an *axiom* interface already. The trademark on "Axiom" does not mean that we can't legally use the word for the command name in our program. Our interface to sage is an interface to axiom, fricas, etc.
Attachments (2)
Change History (16)
comment:1 Changed 13 years ago by
- Priority changed from major to blocker
comment:2 Changed 13 years ago by
comment:3 Changed 13 years ago by
- Description modified (diff)
- Summary changed from axiom --> fricas to axiom --> fricas ?
20:41 < wstein> On the other hand, if Tim Daly really is the trademark owner of axiom, can't he 20:41 < wstein> just tell us we can't use the name and that is that? 20:41 < cwitty> I don't think so. 20:41 < cwitty> He can tell us we can't call our product axiom. 20:42 < cwitty> He can probably tell us we can't call fricas axiom, which is closer to what we're doing. 20:43 < mhansen> cwitty: We're actually just calling whatever "axiom" command happens to be on the system.
Changed 13 years ago by
comment:4 Changed 13 years ago by
- Owner changed from was to mhansen
- Status changed from new to assigned
- Summary changed from axiom --> fricas ? to [with patch, needs review] axiom --> fricas ?
Note that this applies on top of the ReST patches so it should not go in until those are in.
Also, this patch includes the changes found in #4036.
comment:5 Changed 13 years ago by
Also, all of the axiom() commands pass tests with the January 2009 release of Axiom.
comment:6 follow-up: ↓ 7 Changed 13 years ago by
Mike,
I do not understand the reference to "ReST patches". Are these in or out of sage-3.3? Bottom line: Can your patch be applied directly to sage-3.3?
Bill.
comment:7 in reply to: ↑ 6 Changed 13 years ago by
Replying to bpage:
Mike,
Hi Bill,
I do not understand the reference to "ReST patches". Are these in or out of sage-3.3? Bottom line: Can your patch be applied directly to sage-3.3?
No. The ReST patches are about 35 tickets work of documentation fixes that will go into 3.4. It will be out before the weekend, so you might want to wait until then to play with this. Note that 3.4.alpha0 ought in about 24 hours ought to contain all the ReST patches, so that might be something you could use for review.
Cheers,
Michael
Bill.
comment:8 Changed 13 years ago by
Mike,
Thanks. I have successfully applied this patch to sage-3.4.alpha0 and have just begun testing. I noticed however that patch returned the warning:
patching file sage/structure/sage_object.pyx Hunk #1 succeeded at 305 (offset 7 lines)
So I guess there has already by some code drift.
The first bug I noticed was that
./sage -fricas
does not start a FriCAS session.
./sage -axiom
however still starts FriCAS even though /usr/local/axiom has been replaced with a dummy script.
I guess this command line processing must be done in some other part of sage?
Regards, Bill Page.
comment:9 follow-up: ↓ 10 Changed 13 years ago by
Mike,
On my Debian 5.0 (Lenny) x86 system I have not been able to compile recent versions of Axiom from source using the instructions here:
http://axiom.axiom-developer.org/axiom-website/download.html
I get build errors early in the process. What did you use to get the "January 2009 release of Axiom" referred to in your tests?
After installing the binary version of Axiom via
apt-get install axiom
I do get the older "2005" version of Axiom which does seem to run ok (known problems with Hyperdoc etc. notwithstanding). However this version seems to have pexpect synchronization problems.
sage: axiom('1+1') sage:
returns no visible result, while
sage: fricas('1+1') 2 sage:
behaves as expected.
I think the problem is probably caused by the differences in readline behavior under gcl and/or minor differences in the initial prompts. I am not sure how to handle this so long as we depend on an externally installed version of Axiom. If Sage is going to continue to support Axiom as an option, perhaps some effort needs to be given to creating an optional Axiom spkg ... (Don't look at me! :-). Otherwise, I would not be against getting rid of the 'axiom' function all together.
On this same subject: What consideration, if any, has been given to providing a similar interface for OpenAxiom?? Does anyone want this?
Regards, Bill Page.
comment:10 in reply to: ↑ 9 Changed 13 years ago by
Replying to bpage:
Mike,
On my Debian 5.0 (Lenny) x86 system I have not been able to compile recent versions of Axiom from source using the instructions here:
http://axiom.axiom-developer.org/axiom-website/download.html
I get build errors early in the process. What did you use to get the "January 2009 release of Axiom" referred to in your tests?
I just used the binary found here: http://www.axiom-developer.org/axiom-website/downloads/axiom-ubuntu64-jan2009-bin.tgz
After installing the binary version of Axiom via
apt-get install axiomI do get the older "2005" version of Axiom which does seem to run ok (known problems with Hyperdoc etc. notwithstanding). However this version seems to have pexpect synchronization problems.
Yes, this is not too surprising.
I think the problem is probably caused by the differences in readline behavior under gcl and/or minor differences in the initial prompts. I am not sure how to handle this so long as we depend on an externally installed version of Axiom. If Sage is going to continue to support Axiom as an option, perhaps some effort needs to be given to creating an optional Axiom spkg ... (Don't look at me! :-). Otherwise, I would not be against getting rid of the 'axiom' function all together.
I think Camm is updating the version of Axiom in Debian. It'd be silly not to have some support since it's very little extra work.
On this same subject: What consideration, if any, has been given to providing a similar interface for OpenAxiom?? Does anyone want this?
I don't know -- I don't really use this software. It should be pretty trivial to add support for.
Changed 13 years ago by
comment:11 follow-up: ↓ 12 Changed 13 years ago by
Here is a patch (trac_5111b.patch) that disables readline support for Axiom. With this change the axiom interface now works for me.
Also, I discovered that I was able to compile Axiom from the January 2009 source tarball. I still have a problem compiling the git or cvs head version on Debian 5.0.
Re: Axiom binaries on Debian instead of an spkg. Is there any other case in Sage where an interface is provided from something that is not available for install as an spkg? I thought this might be a Sage policy.
comment:12 in reply to: ↑ 11 Changed 13 years ago by
Replying to bpage:
Here is a patch (trac_5111b.patch) that disables readline support for Axiom. With this change the axiom interface now works for me.
Cool! Thanks for the fixes (and typo catches).
Re: Axiom binaries on Debian instead of an spkg. Is there any other case in Sage where an interface is provided from something that is not available for install as an spkg? I thought this might be a Sage policy.
Yeah, there are plenty of things like that. For example, all of the proprietary math software interfaces :-)
--Mike
comment:13 Changed 13 years ago by
- Summary changed from [with patch, needs review] axiom --> fricas ? to [with patch, positive review] axiom --> fricas ?
I did a fairly fast skim of the code (I didn't study it), and tested the axiom interface on my computer (against an old version of axiom). A couple of doctests failed with slightly different printing than expected (probably because the axiom version was old; the answer was correct, only the printing was wrong), but almost all of them passed.
Positive review (apply both patches).
comment:14 Changed 13 years ago by
- Milestone changed from sage-4.0 to sage-3.4.2
- Resolution set to fixed
- Status changed from assigned to closed
Merged both patches in Sage 3.4.2.alpha0.
Cheers,
Michael
It's been brought up that this may be a bad idea, since after all we still have an axiom interface. The purpose of this ticket is this: