Opened 9 years ago
Last modified 9 years ago
#10187 closed defect
Update ecl and maxima — at Version 62
Reported by: | vbraun | Owned by: | tbd |
---|---|---|---|
Priority: | major | Milestone: | sage-4.6.1 |
Component: | packages: standard | Keywords: | |
Cc: | was, jhpalmieri, mpatel, leif, jsp, jason, kcrisman, fbissey, jpflori | Merged in: | |
Authors: | Volker Braun, David Kirkby | Reviewers: | Karl-Dieter Crisman |
Report Upstream: | Workaround found; Bug reported upstream. | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
Please update ecl and maxima to the newest upstream release. Sage packages are here:
http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg
Note that you cannot upgrade one without the other; Both need to be upgraded simultaneously or build will fail.
Relevant tickets for ecl:
- #9493: Remove extra baggage from ECL 10.2.1.p1 (again). The package has been cleaned up, but I feel removing gmp sources is too dangerous.
- #10185: the old ecl-10.2.1 does not build on Fedora 14: Hopefully fixed with the updated ecl from this ticket.
Relevant tickets for maxima:
- #8645: ECL library "maxima.fasb" is built at new location. The patches from this bug have been incorporated into the maxima spkg, and #8645 can be closed after this ticket.
- #8731: update/upgrade maxima to latest upstream (5.21.1): Latest upstream is nowadays 5.22.1.
- #8582:
sum(1/(1+k^2), k, -oo, oo)
returns 0: The new maxima seems to be able to evaluate this correctly, at leasts it returns some expression with digamma functions.
The updated maxima code seems to be more careful about signs which leads to doctest errors. Moreover, error reporting was changed. Therefore you need to apply the following patches to the Sage library (in this order):
trac_10187_fix_easy_doctests.patch
trac_10187_general_display_prefix_workaround.patch
trac_10187_mark_some_doctests_random_until_9880_gets_merged.patch
Finally, you need to patch $SAGE_LOCAL/local/bin/sage-maxima.lisp
with
trac_10187_sage-maxima_lisp.patch
Change History (64)
comment:1 Changed 9 years ago by
- Cc kcrisman added
comment:2 Changed 9 years ago by
comment:3 follow-up: ↓ 4 Changed 9 years ago by
FYI, here's the failures on OpenSolaris 06/2009 with those updated versions of Maxima and ECL.
sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py *** *** Error: TIMED OUT! PROCESS KILLED! *** *** [1800.2 s] ---------------------------------------------------------------------- The following tests failed: sage -t -long -force_lib devel/sage/sage/symbolic/integration/integral.py # 6 doctests failed sage -t -long -force_lib devel/sage/sage/symbolic/maxima_wrapper.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/symbolic/expression.pyx # 11 doctests failed sage -t -long -force_lib devel/sage/sage/misc/functional.py # 2 doctests failed sage -t -long -force_lib devel/sage/sage/calculus/wester.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/calculus/tests.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/calculus/calculus.py # 5 doctests failed sage -t -long -force_lib devel/sage/sage/calculus/functional.py # 1 doctests failed sage -t -long -force_lib devel/sage/sage/plot/plot3d/transform.pyx # 1 doctests failed sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py # Time out ---------------------------------------------------------------------- Total time for all tests: 2628.2 seconds make: *** [ptestlong] Error 192 drkirkby@hawk:~/sage-4.6.1.alpha0$
I've not applied any patches at this point. I'll apply patches and rerun later.
comment:4 in reply to: ↑ 3 Changed 9 years ago by
Replying to drkirkby:
FYI, here's the failures on OpenSolaris 06/2009 with those updated versions of Maxima and ECL.
sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py *** *** Error: TIMED OUT! PROCESS KILLED! *** *** [1800.2 s]
I'd be interested what happened if you manually removed the tests in that file which test the tab-completion for Maxima. I get a problem on Mac OS X Tiger with that file for exactly that reason. We haven't filed a ticket because nobody knows how to fix it, and tab-completion does work on that platform, just not the testing.
comment:5 follow-up: ↓ 6 Changed 9 years ago by
The TIMED OUT! error is the missing general-display-prefix
, which causes the expect interface to wait forever for maxima to print its next prompt.
I've filed a bug upstream here: https://sourceforge.net/tracker/?func=detail&aid=3098375&group_id=4933&atid=104933
comment:6 in reply to: ↑ 5 Changed 9 years ago by
Replying to vbraun:
The TIMED OUT! error is the missing
general-display-prefix
, which causes the expect interface to wait forever for maxima to print its next prompt.
Okay, thanks - so that's unrelated to the Tiger timeout from earlier Maximas.
comment:7 follow-ups: ↓ 11 ↓ 16 Changed 9 years ago by
- Report Upstream changed from N/A to Workaround found; Bug reported upstream.
I've modified sage/interfaces/maxima.py
to work with maxima's prompt_prefix
instead. Patch is attached and fixes the remaining doctest error.
This requires that `$SAGE_LOCAL/bin/sage-maxima.lisp sets
; (setf *general-display-prefix* "<sage-display>") (setf *prompt-prefix* "<sage-display>")
I've made a updated sage_scripts spkg here: http://www.stp.dias.ie/~vbraun/Sage/spkg/sage_scripts-4.6.rc0.p0.spkg
To test this ticket, you need all three spkgs and both patches.
comment:8 Changed 9 years ago by
- Status changed from new to needs_review
comment:9 Changed 9 years ago by
- Cc fbissey added
comment:10 Changed 9 years ago by
One thing we don't don, which I think would be sensible, is to include the test suite for ECL. That adds 1.7 MB. From the README.ECL file:
cd tests make You will find two types of output files: *.out The whole output of a test *.erg The errors arising from a test When there is no *.erg, it means that ECL passed the test.
Would it not be sensible to add these in? Then we could execute the tests with a spkg-check file, like we do other code which has self-tests.
Dave
comment:11 in reply to: ↑ 7 Changed 9 years ago by
Replying to vbraun:
I've modified
sage/interfaces/maxima.py
to work with maxima'sprompt_prefix
instead. Patch is attached and fixes the remaining doctest error.
Just a very minor note:
# we are now getting three lines of commented verbosity
but of course you changed it to get rid of the extra two lines from our constantly added packages :) so it's now five lines. Might as well change that too so future people are confused.
comment:12 Changed 9 years ago by
comment:13 Changed 9 years ago by
I looked trough doctest patch and compared it with mine from #8731, I have few comments.
I think that doctest fix for sage/calculus/functional.py should be modified - it was documentation of the use of assume, but now - when maxima can calculate this integral without assumption, isn't that same as applying assumption to result? And the integral is checked in other doctest now. Maybe there is better example that still needs the assume to get result?
Also the doctest in sage/misc/functional.py was here to demonstrate numerical approximation of integral that cannot be evaluated iirc, and now when it can be evaluated, I think it should be changed to something that cannot be - like Jason did in patch in #8731.
Finally, there is typo in doctest to sage/symbolic/expression.pyx - it should say that this doctest is here to check that #7334 not #7344 is fixed (#7344 point to libjpeg issue so it cannot be it) - and it should stay in here unmodified. Also - the log thing - it's not exactly regression, it's feature. This is because of Maxima ticket 947808 - http://sourceforge.net/tracker/?func=detail&aid=947808&group_id=4933&atid=104933 - they now try to keep the expression as factored as they can without using factor. This results in observed behaviour. This doctest I think cannot be changed as it demonstrated that ticket is solved, but we should apply "x = x.simplify_rational()" after "x = x.simplify_log('one')" in definition of simplify_full - that way full simplify would result in same results as before I think, and #7334 would be still fixed. Now, this doctest shows nothing.
comment:14 Changed 9 years ago by
- Status changed from needs_review to needs_work
There is a problem with the ECL package here. The history of all recent changes has been lost. The recent changes to the package have been:
=== ecl-10.2.1.p3 (David Kirkby, David Kirkby, 17th September 2010) === === ecl-10.2.1.p2 (David Kirkby, 30th July 2010) === === ecl-10.2.1.p1 (Mitesh Patel, 11th July 2010) === === ecl-10.2.1.p0 (David Kirkby, 11th July 2010) === === ecl-10.2.1 (William Stein, 14 February 2010) ===
but instead SPKG.txt shows
=== ecl-10.4.1.p0 (Leif Leonhardy, Volker Braun, 29th September 2010) === === ecl-10.4.1 (N. Bruin, W. Stein, D. Kirkby and M. Patel 19th June 2010) === === ecl-10.2.1 (William Stein, 14 February 2010) ===
This error has occurred since the package is based on one that I created several months ago, which never got merged, because their were conflicts with that and the Maxima package at the time.
The current version of ECL in Sage should have been used as a starting point - not an old one that was never merged.
I'll sort the above problem out, and add the ECL test code today.
Dave
comment:15 Changed 9 years ago by
The patch fix_easy_doctest doesn't apply cleanly on either 4.6.rc0 or 4.6.1.alpha0. Was it prepared against 4.5.3?
comment:16 in reply to: ↑ 7 ; follow-up: ↓ 17 Changed 9 years ago by
Replying to vbraun:
I've modified
sage/interfaces/maxima.py
to work with maxima'sprompt_prefix
instead. Patch is attached and fixes the remaining doctest error.This requires that `$SAGE_LOCAL/bin/sage-maxima.lisp sets
; (setf *general-display-prefix* "<sage-display>") (setf *prompt-prefix* "<sage-display>")
I've made a updated sage_scripts spkg here: http://www.stp.dias.ie/~vbraun/Sage/spkg/sage_scripts-4.6.rc0.p0.spkg
To test this ticket, you need all three spkgs and both patches.
Could you please attach a patch to the scripts repo, too (rather than a link to a complete new scripts spkg)?
Also, attaching diffs (or Mercurial patches) of the spkgs makes reviewing easier.
comment:17 in reply to: ↑ 16 Changed 9 years ago by
Replying to leif:
Could you please attach a patch to the scripts repo, too (rather than a link to a complete new scripts spkg)?
P.S.: Of course I could do that, too, but then you wouldn't be able to update it in case you later modify the patch.
comment:18 Changed 9 years ago by
I've incorporated your suggestions and updated the patches. Both are (and were) against 4.6.rc0 and apply cleanly. Maybe you had the wrong order? It should be
- trac_10187_fix_easy_doctests.patch
- trac_10187_general_display_prefix_workaround.patch
I'll attach patches for the sage_scripts
and maxima
spgk for easier review. Once Dave is finished with the ecl package then this ticket is ready for review again.
comment:19 Changed 9 years ago by
Wrong order indeed! I thought the two patches were orthogonal.
comment:20 follow-up: ↓ 21 Changed 9 years ago by
I'm going to have to ask on the ECL list how to run the test suite - I can't work out where ones supposed to copy the source.
These changes are not going to make it into 4.6. The milestone is 4.6.1, and it will easily be resolved by then.
Dave
comment:21 in reply to: ↑ 20 Changed 9 years ago by
Replying to drkirkby:
I'm going to have to ask on the ECL list how to run the test suite - I can't work out where ones supposed to copy the source.
These changes are not going to make it into 4.6. The milestone is 4.6.1, and it will easily be resolved by then.
Dave
I've now got the information on the ANSI test suite from the ECL developer, though I gather the copy on the ECL site is rather out of date. Also, the ECL developer has fixed the bug that causes #9840, so I'll patch that too, so #9840 can hopefully be closed at the same time.
I'll try to get this sorted out within the next few days.
Dave
comment:22 Changed 9 years ago by
- Description modified (diff)
I have put an updated ECL file at http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg This has only been checked on OpenSolaris - I don't have access to a Fedora 14 machine, so can't verify if it actually fixes the issues reported at #10185
I should make a few comments about this:
- I have not added an spkg-check file or the Lisp tests, as I gather from the ECL developer the Lisp tests on the ECL site are outdated. Fixing this appears to be a non-trivial issue.
- The repository information from the ecl-10.2.1.p3 version actually in Sage is kept, as it should be. (Volker's package was based on a 10.4.1 package I created months ago, which never got merged into Sage. So the repository information was not correct).
- Despite being told the Solaris text relocation issue was resolved, it appears it is not as simple as applying a single patch as I had hoped. So #9840 remains unresolved, though it should be fixed when the next stable ECL release is made.
- I've cleaned the package up somewhat.
- I did not remove the gmp sources, as doing so requires a new configure file to be created. Whilst I can see this is advantageous if done properly, I fear that this will be done incorrectly at some point in the future, which can result in chaos.
After
- Installing the new ECL package I created, and put at http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg
- Installing the Maxima package from http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg
- Trying to install all the patches (one failed, see below)
- Rebuilding the Sage library.
- Running all the doctests, which all pass.
I get one reject out of six when adding
trac_10187_general_display_prefix_workaround.patch
to sage 4.6.1.alpha0, so I think that patch needs updating. The contents of the reject are:
--- maxima.py +++ maxima.py @@ -728,10 +729,12 @@ sage: maxima._eval_line('1+1;') '2' - sage: maxima.eval('sage0: x == x;') + sage: maxima._eval_line('sage0: x == x;') Traceback (most recent call last): ... - TypeError: error evaluating "sage0: x == x;":... + TypeError: Error executing code in Maxima... + + """ if len(line) == 0: return ''
But as I say, all doctests passed for me, despite one patch was not fully applied!!
---------------------------------------------------------------------- All tests passed! Total time for all tests: 1871.3 seconds
I'm leaving as needs work, as clearly the fact one patch does not apply cleanly is a problem. It also needs testing on more than one system, but I don't have access to the Fedora 14 system where this was a particular problem.
Dave
comment:23 Changed 9 years ago by
Dave's ecl-10.4.1.spkg
compiles just fine on Fedora 14! I don't have sage 4.6.1.alpha0 installed right now, so it'll take me a few hours to update the patch.
comment:24 follow-ups: ↓ 25 ↓ 26 Changed 9 years ago by
- Status changed from needs_work to needs_review
Patches apply cleanly on sage 4.6.1.alpha0. As I wrote in http://trac.sagemath.org/sage_trac/ticket/10187#comment:18, they need to be applied in the order
- trac_10187_fix_easy_doctests.patch
- trac_10187_general_display_prefix_workaround.patch
comment:25 in reply to: ↑ 24 Changed 9 years ago by
Replying to vbraun:
Patches apply cleanly on sage 4.6.1.alpha0. As I wrote in http://trac.sagemath.org/sage_trac/ticket/10187#comment:18, they need to be applied in the order
- trac_10187_fix_easy_doctests.patch
- trac_10187_general_display_prefix_workaround.patch
Perhaps I did not have a clean sage 4.6.1.alpha0. I will start a fresh build and try again.
Dave
comment:26 in reply to: ↑ 24 Changed 9 years ago by
Replying to vbraun:
Patches apply cleanly on sage 4.6.1.alpha0. As I wrote in http://trac.sagemath.org/sage_trac/ticket/10187#comment:18, they need to be applied in the order
- trac_10187_fix_easy_doctests.patch
- trac_10187_general_display_prefix_workaround.patch
Ah, I missed that fact. I applied the patches in the order they were applied to the trac ticket, which is the reverse order to what you are saying should have been done!
I've just started a build. It takes a bit over an hour to build Sage and run all the long doctests on this machine, but it's 11 pm local time. I'll try to get it done before going to bed, so I can report on it, but it might have to wait until tomorrow. I'm feeling rather tired here.
Dave
comment:27 follow-up: ↓ 28 Changed 9 years ago by
OK, this is fine on OpenSolaris 06/2009 and Fedora 14. What about any other platforms?
comment:28 in reply to: ↑ 27 ; follow-up: ↓ 29 Changed 9 years ago by
Replying to drkirkby:
OK, this is fine on OpenSolaris 06/2009 and Fedora 14. What about any other platforms?
I have switched sage-on-gentoo to maxima-5.22.1 on sage-4.6's release I haven't run a long test of alpha1 with it but I haven't heard complaint from anyone running tests on x86 and amd64 with 4.6.
comment:29 in reply to: ↑ 28 Changed 9 years ago by
Replying to fbissey:
I have switched sage-on-gentoo to maxima-5.22.1 on sage-4.6's release I haven't run a long test of alpha1 with it but I haven't heard complaint from anyone running tests on x86 and amd64 with 4.6.
Thank you. I must do some other things today, so don't have time to test this much. But hopefully we can get some testers on other platforms. To my knowledge we know nothing about
- Any OS X release
- Solaris 10 on SPARC
- Solaris 10 on x86
all of which are supported platforms.
I've asked on sage-devel, if someone else can do some testing. It would be nice to get this merged. Experience shows if we leave updating Maxima too long, it becomes a nightmare to update. It really is something we should regularly update - not only for new functionality, but also it saves a nightmare at a later date.
Dave
comment:30 Changed 9 years ago by
- Cc jpflori added
comment:31 Changed 9 years ago by
I'm currently testing on OS X 10.4 (Tiger) PPC. ECL installed fine, but I won't be able to see the results of the rest and some testing until tomorrow.
comment:32 Changed 9 years ago by
I tested both spkg on Debian, everything compiled fine, the patches applied cleanly on 4.6.1.alpha2 and sage_scripts spkg from that version (when applied in order of comment 18, otherwise 1 hunk does not get applied) and all tests passed.
sage -t -long -force_lib "devel/sage/sage/interfaces/maxima.py" [22.4 s] ---------------------------------------------------------------------- All tests passed! Total time for all tests: 22.5 seconds
It should be noted that the Maxima update fixes #7952 (and #10273 I opened by mistake and closed as duplicate).
comment:33 Changed 9 years ago by
- Reviewers set to Karl-Dieter Crisman
- Status changed from needs_review to needs_work
- Work issues set to new interface patch needs help
I get a LOT of timeouts on PPC OS X 10.4. I think that basically any time Maxima is invoked inside Sage, it times out or does something else weird. E.g.
sage: integrate(x^2,x) Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored Exception RuntimeError: RuntimeError('maximum recursion depth exceeded in cmp',) in Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored ignored Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored Exception RuntimeError: RuntimeError('maximum recursion depth exceeded in cmp',) in Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored ignored Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored Exception RuntimeError: RuntimeError('maximum recursion depth exceeded in cmp',) in Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored ignored Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored Exception RuntimeError: RuntimeError('maximum recursion depth exceeded in cmp',) in Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored ignored
I also get the following:
sage -t -long "devel/sage/sage/calculus/functions.py" ********************************************************************** File "/Users/student/Desktop/sage-4.6/devel/sage/sage/calculus/functions.py", line 46: sage: wronskian(*[x^k for k in range(1, 5)]) assert len(self._before())==0, 'Maxima expect interface is confused!' AssertionError: Maxima expect interface is confused!
What the heck? I assume the change to the Maxima interface is to blame; reverting that patch only (not the doctest one) seems to fix the problem.
Though in that case I do get
File "/Users/student/Desktop/sage-4.6/devel/sage/sage/calculus/calculus.py", line 343: sage: taylor(gamma(1/3+x),x,0,3) Expected: -1/432*((36*(pi*sqrt(3) + 9*log(3))*euler_gamma^2 + 27*pi^2*log(3) + 72*euler_gamma^3 + 243*log(3)^3 + 18*(6*pi*sqrt(3)*log(3) + pi^2 + 27*log(3)^2 + 12*psi(1, 1/3))*euler_gamma + 324*psi(1, 1/3)*log(3) + (pi^3 + 9*(9*log(3)^2 + 4*psi(1, 1/3))*pi)*sqrt(3))*gamma(1/3) - 72*gamma(1/3)*psi(2, 1/3))*x^3 + 1/24*(6*pi*sqrt(3)*log(3) + 4*(pi*sqrt(3) + 9*log(3))*euler_gamma + pi^2 + 12*euler_gamma^2 + 27*log(3)^2 + 12*psi(1, 1/3))*x^2*gamma(1/3) - 1/6*(6*euler_gamma + pi*sqrt(3) + 9*log(3))*x*gamma(1/3) + gamma(1/3) Got: -1/432*((36*(pi*sqrt(3) + 9*log(3))*euler_gamma^2 + 27*pi^2*log(3) + 72*euler_gamma^3 + 243*log(3)^3 + 18*(6*pi*sqrt(3)*log(3) + pi^2 + 27*log(3)^2 + 12*psi(1, 1/3))*euler_gamma + 324*log(3)*psi(1, 1/3) + (pi^3 + 9*(9*log(3)^2 + 4*psi(1, 1/3))*pi)*sqrt(3))*gamma(1/3) - 72*gamma(1/3)*psi(2, 1/3))*x^3 + 1/24*(6*pi*sqrt(3)*log(3) + 4*(pi*sqrt(3) + 9*log(3))*euler_gamma + pi^2 + 12*euler_gamma^2 + 27*log(3)^2 + 12*psi(1, 1/3))*x^2*gamma(1/3) - 1/6*(6*euler_gamma + pi*sqrt(3) + 9*log(3))*x*gamma(1/3) + gamma(1/3) **********************************************************************
which is interesting; if you find where they differ (hint - transposed multiplication), you win the Where's Waldo award.
I'll report back if there are any other errors without it.
comment:34 Changed 9 years ago by
kcrisman: looks like you did not install the updated sage_scripts-4.6.rc0.p0.spkg
, see http://trac.sagemath.org/sage_trac/ticket/10187#comment:7
comment:35 Changed 9 years ago by
If sage_scripts needs to be patched, please provide a hg patch for that.
comment:36 Changed 9 years ago by
It is sage-maxima.lisp.patch provided in the ticked.
It applies cleanly on sage_script spkg of sage 4.6.1.alpha2 for me and tests pass.
comment:37 Changed 9 years ago by
Replying to jdemeyer:
If sage_scripts needs to be patched, please provide a hg patch for that.
Looks like it needs a commit message to apply straight-up with hg_scripts
, so it's not ready as it stands, perhaps.
Without *either* of those patches, I get most relevant tests passing EXCEPT the taylor(gamma(1/3+x),x,0,3)
one, on both OS X 10.6 Intel and 10.4 PPC. The interfaces/maxima.py times out without both the workaround and lisp patch on 10.6, after which it's fine on that and sage/calculus, sage/symbolic, and sage/functions.
I haven't tested that last combination of patches yet on my 10.4 machine, as it's very slow - later today I might know more.
comment:38 Changed 9 years ago by
- Status changed from needs_work to needs_review
- Work issues new interface patch needs help deleted
I've added a patch for sage-maxima.lisp
as trac_10187_sage-maxima_lisp.patch
.
To summarize, you need to
- Apply
trac_10187_sage-maxima_lisp.patch
to SAGE_LOCAL/bin - http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg
- http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg
- Apply trac_10187_fix_easy_doctests.patch to the sage library
- Apply trac_10187_general_display_prefix_workaround.patch to the sage library
Its true, but completely pointless, that some doctests pass without some of these patches. Maxima's error reporting changed and we cannot use the old parser any more. Read this ticket for details.
comment:39 follow-up: ↓ 45 Changed 9 years ago by
Okay, after running all (not long) doctests, I get the following error in addition to the taylor error above, on Mac OS X 10.6, applied to a brand-new Sage 4.6.1.alpha1 build:
sage -t devel/sage/sage/plot/plot3d/transform.pyx ********************************************************************** File "/Users/.../sage-4.6.1.alpha1/devel/sage-main/sage/plot/plot3d/transform.pyx", line 217: sage: m Expected: [ -(cos(theta) - 1)*x^2 + cos(theta) -(cos(theta) - 1)*sqrt(-x^2 - z^2 + 1)*x + sin(theta)*abs(z) -((cos(theta) - 1)*x*z^2 + sqrt(-x^2 - z^2 + 1)*sin(theta)*abs(z))/z] [ -(cos(theta) - 1)*sqrt(-x^2 - z^2 + 1)*x - sin(theta)*abs(z) (cos(theta) - 1)*x^2 + (cos(theta) - 1)*z^2 + 1 -((cos(theta) - 1)*sqrt(-x^2 - z^2 + 1)*z*abs(z) - x*z*sin(theta))/abs(z)] [ -((cos(theta) - 1)*x*z^2 - sqrt(-x^2 - z^2 + 1)*sin(theta)*abs(z))/z -((cos(theta) - 1)*sqrt(-x^2 - z^2 + 1)*z*abs(z) + x*z*sin(theta))/abs(z) -(cos(theta) - 1)*z^2 + cos(theta)] Got: [ -(cos(theta) - 1)*x^2 + cos(theta) -(cos(theta) - 1)*sqrt(-x^2 - z^2 + 1)*x + abs(z)*sin(theta) -((cos(theta) - 1)*x*z^2 + sqrt(-x^2 - z^2 + 1)*abs(z)*sin(theta))/z] [ -(cos(theta) - 1)*sqrt(-x^2 - z^2 + 1)*x - abs(z)*sin(theta) (cos(theta) - 1)*x^2 + (cos(theta) - 1)*z^2 + 1 -((cos(theta) - 1)*sqrt(-x^2 - z^2 + 1)*z*abs(z) - x*z*sin(theta))/abs(z)] [ -((cos(theta) - 1)*x*z^2 - sqrt(-x^2 - z^2 + 1)*abs(z)*sin(theta))/z -((cos(theta) - 1)*sqrt(-x^2 - z^2 + 1)*z*abs(z) + x*z*sin(theta))/abs(z) -(cos(theta) - 1)*z^2 + cos(theta)] **********************************************************************
There are several transpositions of abs(z)*sin(theta)
in this one, just like the transposition of psi(1, 1/3)*log(3)
in the other error.
I get
sage: sage.calculus.calculus.maxima.eval('taylor(gamma(1/3+x),x,0,3)') 'gamma(1/3)-(6*%gamma+%pi*sqrt(3)+9*log(3))*gamma(1/3)*x/6+(12*%gamma^2+(4*%pi*sqrt(3)+36*log(3))*%gamma+6*log(3)*%pi*sqrt(3)+%pi^2+27*log(3)^2+12*psi[1](1/3))*gamma(1/3)*x^2/24+(72*gamma(1/3)*psi[2](1/3)+(-72*%gamma^3+(-36*%pi*sqrt(3)-324*log(3))*%gamma^2+(-108*log(3)*%pi*sqrt(3)-18*%pi^2-486*log(3)^2-216*psi[1](1/3))*%gamma+(-%pi^3+(-81*log(3)^2-36*psi[1](1/3))*%pi)*sqrt(3)-27*log(3)*%pi^2-243*log(3)^3-324*psi[1](1/3)*log(3))*gamma(1/3))*x^3/432'
which looks like the 'expected' line. I also get
sage: psi(1,1/3)*log(3) log(3)*psi(1, 1/3)
which perhaps is the issue. What do people who do not have problems with this doctest get for this? (If the same for Maxima, but different for Sage, maybe it's a platform-dependent Pynac issue ... why on earth would that happen?)
comment:40 follow-up: ↓ 41 Changed 9 years ago by
- Status changed from needs_review to needs_info
Can you double-check that the maxima binary works? you should get:
[vbraun@volker-two ~]$ sage -sh Starting subshell with Sage environment variables set. Be sure to exit when you are done and do not do anything with other copies of Sage! Bypassing shell configuration files ... SAGE_ROOT=/home/vbraun/Sage/sage (sage subshell) volker-two:~ vbraun$ maxima ;;; Loading #P"/home/vbraun/Sage/sage/local/lib/ecl/sb-bsd-sockets.fas" ;;; Loading #P"/home/vbraun/Sage/sage/local/lib/ecl/sockets.fas" ;;; Loading #P"/home/vbraun/Sage/sage/local/lib/ecl/defsystem.fas" ;;; Loading #P"/home/vbraun/Sage/sage/local/lib/ecl/cmp.fas" ;;; Loading #P"/home/vbraun/Sage/sage/local/lib/ecl/sysfun.lsp" Maxima 5.22.1 http://maxima.sourceforge.net using Lisp ECL 10.4.1 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) display2d : false; (%o1) false (%i2) psi(1,1/3)*log(3); (%o2) psi(1,1/3)*log(3)
comment:41 in reply to: ↑ 40 ; follow-up: ↓ 42 Changed 9 years ago by
- Status changed from needs_info to needs_review
RReplying to vbraun:
Can you double-check that the maxima binary works? you should get:
I'm not sure how it could have passed tests without working :) but yes, it works on OS X 10.6. From command line, from sage -sh
, from maxima_console
, etc.
On 10.4 it also works once I add in the script change, and I'm currently running doctests. It is even slower than before, but so far it does seem to be working. Just FYI that on that platform testing sage/interfaces/maxima.py has no point, because of the (unrelated, I think) #9361.
Putting to needs work because of this weird multiplication issue.
comment:42 in reply to: ↑ 41 ; follow-up: ↓ 43 Changed 9 years ago by
yes, it works on OS X 10.6.
Does maxima return psi(1,1/3)*log(3)
in this order or in the reversed order?
comment:43 in reply to: ↑ 42 Changed 9 years ago by
- Status changed from needs_review to needs_work
Replying to vbraun:
yes, it works on OS X 10.6.
Does maxima return
psi(1,1/3)*log(3)
in this order or in the reversed order?
I already reverted ... but as far as I recall, it was Sage itself that reversed this, as in comment 39, and in straight Maxima I got what you did.
Sorry, put to wrong thing before - needs work because of this, or needs info if you like.
comment:44 follow-up: ↓ 46 Changed 9 years ago by
- Status changed from needs_work to needs_info
I'm still confused what, if any, issue remains. This patch only touches the capture of the whole maxima output string, and not the parsing of expression. If maxima's output ordering has not changed yet some platform returns a different output sort order then this is an unrelated bug in the maxima interface.
comment:45 in reply to: ↑ 39 Changed 9 years ago by
On Ubuntu 10.04 64-bit with 4.6.1.alpha1, everything is working -- all "ptestlong" tests pass.
Replying to kcrisman:
I get
sage: sage.calculus.calculus.maxima.eval('taylor(gamma(1/3+x),x,0,3)') 'gamma(1/3)-(6*%gamma+%pi*sqrt(3)+9*log(3))*gamma(1/3)*x/6+(12*%gamma^2+(4*%pi*sqrt(3)+36*log(3))*%gamma+6*log(3)*%pi*sqrt(3)+%pi^2+27*log(3)^2+12*psi[1](1/3))*gamma(1/3)*x^2/24+(72*gamma(1/3)*psi[2](1/3)+(-72*%gamma^3+(-36*%pi*sqrt(3)-324*log(3))*%gamma^2+(-108*log(3)*%pi*sqrt(3)-18*%pi^2-486*log(3)^2-216*psi[1](1/3))*%gamma+(-%pi^3+(-81*log(3)^2-36*psi[1](1/3))*%pi)*sqrt(3)-27*log(3)*%pi^2-243*log(3)^3-324*psi[1](1/3)*log(3))*gamma(1/3))*x^3/432'which looks like the 'expected' line. I also get
sage: psi(1,1/3)*log(3) log(3)*psi(1, 1/3)which perhaps is the issue. What do people who do not have problems with this doctest get for this? (If the same for Maxima, but different for Sage, maybe it's a platform-dependent Pynac issue ... why on earth would that happen?)
Here's what I get for those commands with all the patches and spkgs here, in 4.6.1.alpha1:
sage: sage.calculus.calculus.maxima.eval('taylor(gamma(1/3+x),x,0,3)') 'gamma(1/3)-(6*%gamma+%pi*sqrt(3)+9*log(3))*gamma(1/3)*x/6+(12*%gamma^2+(4*%pi*sqrt(3)+36*log(3))*%gamma+6*log(3)*%pi*sqrt(3)+%pi^2+27*log(3)^2+12*psi[1](1/3))*gamma(1/3)*x^2/24+(72*gamma(1/3)*psi[2](1/3)+(-72*%gamma^3+(-36*%pi*sqrt(3)-324*log(3))*%gamma^2+(-108*log(3)*%pi*sqrt(3)-18*%pi^2-486*log(3)^2-216*psi[1](1/3))*%gamma+(-%pi^3+(-81*log(3)^2-36*psi[1](1/3))*%pi)*sqrt(3)-27*log(3)*%pi^2-243*log(3)^3-324*psi[1](1/3)*log(3))*gamma(1/3))*x^3/432' sage: psi(1,1/3)*log(3) psi(1, 1/3)*log(3)
comment:46 in reply to: ↑ 44 ; follow-up: ↓ 52 Changed 9 years ago by
Dan, thanks for that confirmation of the issue.
Replying to vbraun:
I'm still confused what, if any, issue remains. This patch only touches the capture of the whole maxima output string, and not the parsing of expression. If maxima's output ordering has not changed yet some platform returns a different output sort order then this is an unrelated bug in the maxima interface.
Actually, I'm pretty sure it's an unrelated bug in something else. At first I thought Pynac/Ginac?, but maybe not (?) - in Sage 4.6 on PPC, I get
sage: psi(1,1/3)*log(3) log(3)*psi(1, 1/3) sage: from sage.misc.citation import get_systems sage: get_systems('psi(1,1/3)*log(3)') ['GMP']
This machine doesn't have the new Maxima, so it's definitely unrelated.
Nonetheless, we can't ship a Sage with a failing doctest that we know about, except at great need - this is why I put needs work. The very minor change in how Maxima grouped the coefficient of x^3
created this.
So I recommend that we replace this doctest with something very similar which doesn't have this problem, and then open a new ticket for this issue. Maybe something like
sage: taylor(gamma(1/4+x),x,0,3)
except I can't tell you what the Mac output is on this until tomorrow - maybe someone else can.
The new ticket is #10282.
comment:47 follow-up: ↓ 49 Changed 9 years ago by
I installed Sage on a Mac:
Machine Name: Power Mac G5
Machine Model: !PowerMac11,2
CPU Type: PowerPC G5 (1.1)
with Mac OS X:
System Version: Mac OS X 10.4.11 (8S165)
Kernel Version: Darwin 8.11.0
from binary packages:
http://www.sagemath.org/download-mac.html
and using cp -R - A ... to a custom directory because I don't have admin rights.
So I got Sage 4.6.
I ran Sage once.
I then patched sage_scripts (downloaded spkg, uncompressed, hg qimport patch, hg qpush) and installed it.
I installed ecl-10.4 and maxima5.22.1 spkgs.
I ran ./sage -b but got problem of paths, it was looking in /Users/Shared?/sage/sage-4.6/ ...
So I moved my installation folder there and ./sage -b worked.
I then ran ./sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py
and everything was fine:
init.sage does not exist ... creating sage -t -long -force_lib "devel/sage/sage/interfaces/maxima.py" [53.8 s] ---------------------------------------------------------------------- All tests passed! Total time for all tests: 53.8 seconds
I'll try to test on a SPARC machine with Solaris 10 soon.
comment:48 Changed 9 years ago by
I'm currently running all long doctest on the Mac machine I have access to.
The Mac output for taylor(gamma(1/4+x),x,0,3) is:
sage: taylor(gamma(1/4+x),x,0,3) -1/48*((12*(pi + 6*log(2))*euler_gamma^2 + pi^3 + 18*pi^2*log(2) + 8*euler_gamma^3 + 216*log(2)^3 + 12*(9*log(2)^2 + psi(1, 1/4))*pi + 6*(pi^2 + 12*pi*log(2) + 36*log(2)^2 + 4*psi(1, 1/4))*euler_gamma + 72*log(2)*psi(1, 1/4))*gamma(1/4) - 8*gamma(1/4)*psi(2, 1/4))*x^3 + 1/8*(4*(pi + 6*log(2))*euler_gamma + pi^2 + 12*pi*log(2) + 4*euler_gamma^2 + 36*log(2)^2 + 4*psi(1, 1/4))*x^2*gamma(1/4) - 1/2*(pi + 2*euler_gamma + 6*log(2))*x*gamma(1/4) + gamma(1/4)
On Linux with latest alpha I get :
sage: taylor(gamma(1/4+x),x,0,3) -1/48*((12*(pi + 6*log(2))*euler_gamma^2 + pi^3 + 18*pi^2*log(2) + 8*euler_gamma^3 + 216*log(2)^3 + 12*(9*log(2)^2 + psi(1, 1/4))*pi + 6*(pi^2 + 12*pi*log(2) + 36*log(2)^2 + 4*psi(1, 1/4))*euler_gamma + 72*psi(1, 1/4)*log(2))*gamma(1/4) - 8*gamma(1/4)*psi(2, 1/4))*x^3 + 1/8*(4*(pi + 6*log(2))*euler_gamma + pi^2 + 12*pi*log(2) + 4*euler_gamma^2 + 36*log(2)^2 + 4*psi(1, 1/4))*x^2*gamma(1/4) - 1/2*(pi + 2*euler_gamma + 6*log(2))*x*gamma(1/4) + gamma(1/4)
which is not the same.Look at 72*...
comment:49 in reply to: ↑ 47 ; follow-up: ↓ 50 Changed 9 years ago by
Machine Name: Power Mac G5
System Version: Mac OS X 10.4.11 (8S165)
I then ran ./sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py
Wow, you got no timeout with that file? Georg W. also said that he got this to pass... maybe it's the force lib option, I still get (unrelated to this ticket) timeouts...
Unfortunately, I did not have any luck with relieving the timeouts on my machine in any file which actually uses Maxima. With SAGE_TIMEOUT_LONG=5000
I still get them on all those files. The only difference is I have a G4, not a G5. Maxima *does* work - I tried it in various ways - but it's amazingly slow to start up.
I'll try to look at this more later today.
comment:50 in reply to: ↑ 49 Changed 9 years ago by
Replying to kcrisman:
Wow, you got no timeout with that file? Georg W. also said that he got this to pass... maybe it's the force lib option, I still get (unrelated to this ticket) timeouts...
It also passes without the froce_lib option (in 52.1 seconds).
Here is the output of ./sage -t -long -force_lib devel/sage on my Debian with 4.6.1.alpha2, the timeouts are mentionned at http://groups.google.com/group/sage-devel/browse_thread/thread/09e4cef8c8558150# :
---------------------------------------------------------------------- The following tests failed: sage -t -long -force_lib "devel/sage/build/lib.linux-x86_64-2.6/sage/misc/sagedoc.py" sage -t -long -force_lib "devel/sage/build/lib.linux-x86_64-2.6/sage/homology/examples.py" # Time out sage -t -long -force_lib "devel/sage/build/sage/misc/sagedoc.py" sage -t -long -force_lib "devel/sage/build/sage/homology/examples.py" # Time out sage -t -long -force_lib "devel/sage/sage/misc/sagedoc.py" sage -t -long -force_lib "devel/sage/sage/homology/examples.py" # Time out sage -t -long -force_lib "devel/sage/doc/en/numerical_sage/cvxopt.rst" Total time for all tests: 28820.2 seconds
And on the Mac with 4.6:
---------------------------------------------------------------------- The following tests failed: sage -t -long -force_lib "devel/sage/build/lib.macosx-10.4-ppc-2.6/sage/calculus/calculus.py" sage -t -long -force_lib "devel/sage/build/sage/calculus/calculus.py" sage -t -long -force_lib "devel/sage/build/sage/plot/plot3d/transform.pyx" sage -t -long -force_lib "devel/sage/sage/calculus/calculus.py" sage -t -long -force_lib "devel/sage/sage/plot/plot3d/transform.pyx" Total time for all tests: 60789.1 seconds
comment:51 Changed 9 years ago by
Okay, so the failures are the same as on mine *before* I add the two patches to the Maxima interface.
Summary:
- All Macs have some sort of multiplication transposition, so we will either have to simultaneously fix #10282 or find different doctests for those two examples (the taylor of gamma and the matrix in plot3d/transform.pyx).
- Debian and OpenSolaris? seem ok.
- Other Linux/Solaris? still needed?
- Finally, someone needs to actually review the content of the two Maxima interface change patches (one to Sage library, one to scripts library) and whether the spkgs do, in fact, have all properly changed (not that we don't believe the authors! just someone different needs to check them).
I still am getting this weird behavior of timeouts on mine. The problem seems to be restarting Maxima. Once Maxima is started, timings are slow but normal for this computer:
sage: time integrate(x^2,x) CPU times: user 0.15 s, sys: 0.16 s, total: 0.31 s Wall time: 134.04 s 1/3*x^3 sage: time integrate(x^2,x) CPU times: user 0.08 s, sys: 0.01 s, total: 0.09 s Wall time: 0.83 s 1/3*x^3 sage: time integrate(x^2,x) CPU times: user 0.08 s, sys: 0.02 s, total: 0.10 s Wall time: 0.92 s 1/3*x^3
But I think the way doctests work is that things are restarted from function to function - is that right?
I'm going to try to see what is going on with my computer, but if jpflori is ok with a very similar one, it shouldn't hold things up - unless there is a reason a G4 would be this much slower than a G5? I'm going to try downloading 4.6.1.alpha1, replacing the spkgs with the new ones, and then building from scratch to see what happens.
comment:52 in reply to: ↑ 46 Changed 9 years ago by
Nonetheless, we can't ship a Sage with a failing doctest that we know about, except at great need - this is why I put needs work. The very minor change in how Maxima grouped the coefficient of
x^3
created this. So I recommend that we replace this doctest with something very similar which doesn't have this problem, and then open a new ticket for this issue. Maybe something likesage: taylor(gamma(1/4+x),x,0,3)
except I can't tell you what the Mac output is on this until tomorrow - maybe someone else can. The new ticket is #10282.
As noted by Burcin in #10282 , it is related to pynac ordering and applying the patch I provided in #9880 gives me a consistent behavior on Mac and Linux:
sage: psi(1,1/3)*log(3) log(3)*psi(1, 1/3)
(I order the functions according to their name in lexicographic order)
However #9880 still needs a lot of work:
- my patch must be reviewed
- pynac must be updated
- a lot of doctests will have to be fixed afterwards
comment:53 follow-up: ↓ 54 Changed 9 years ago by
Okay, reverting the patches made no difference on the timing of starting Maxima, so maybe there is something wrong with Maxima itself on my computer... but it *does* allow some of the doctest files to actually pass. Hmm...
Yup, I just saw that update on #10282. So we have three options for this ticket:
Ignore the Mac doctest failure as a known issue with an open ticket OR make the failing doctests optional based on platform until #9880 is reviewed and merged etc. OR find similar doctests where the order doesn't matter.
comment:54 in reply to: ↑ 53 Changed 9 years ago by
Replying to kcrisman:
Okay, reverting the patches made no difference on the timing of starting Maxima, so maybe there is something wrong with Maxima itself on my computer... but it *does* allow some of the doctest files to actually pass. Hmm...
Even weirder - testing a file with no long doctests, but which uses Maxima, passes without -long
and times out with it. WHAT?
comment:55 Changed 9 years ago by
Okay, after reverting to the previous ECL/Maxima on this machine, I get
sage: time integrate(x^3,x) CPU times: user 0.14 s, sys: 0.14 s, total: 0.29 s Wall time: 17.79 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.07 s, sys: 0.01 s, total: 0.08 s Wall time: 0.20 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.08 s, sys: 0.02 s, total: 0.10 s Wall time: 0.21 s 1/4*x^4
So Maxima is taking four times as long to do things, and the startup time is woefully long. Is anyone else noticing a slowdown on Maxima via Sage this way with the new spkg? I'd especially appreciate hearing from PPC OR Tiger users. As it stands, this package makes it so slow it makes Maxima (and integration etc.) almost useless on this machine.
comment:56 follow-up: ↓ 58 Changed 9 years ago by
- Status changed from needs_info to needs_review
The new maxima certainly comes with a bigger library; Its inevitable that it is somewhat slower in exchange for being better at integration. I don't know why startup is so slow on kcrisman's antique computer, but stracing the maxima startup shows that it thrashes around quite a lot in the $SAGE_LOCAL/share/maxima/5.22.1/
directory tree.
For the record, Fedora 14 on a Thinkpad T410s Core i5:
sage: time integrate(x^3,x) CPU times: user 0.03 s, sys: 0.01 s, total: 0.04 s Wall time: 1.15 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s Wall time: 0.05 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s Wall time: 0.05 s 1/4*x^4
I say we should press ahead and update maxima so that Sage compiles on Fedora 14. If the new maxima starts up slowly on your hardware then file a ticket and see if you can profile/fix it.
comment:57 Changed 9 years ago by
On my Core 2 Quad? running Debian, here are the timings for the new Maxima:
sage: time integrate(x^3,x) CPU times: user 0.02 s, sys: 0.01 s, total: 0.03 s Wall time: 1.49 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s Wall time: 0.06 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s Wall time: 0.06 s 1/4*x^4
and with the old Maxima:
sage: time integrate(x^3,x) CPU times: user 0.01 s, sys: 0.02 s, total: 0.03 s Wall time: 1.42 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s Wall time: 0.04 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.01 s, sys: 0.00 s, total: 0.01 s Wall time: 0.04 s 1/4*x^4
On the Power G5 with the new Maxima:
sage: time integrate(x^3,x) CPU times: user 0.04 s, sys: 0.06 s, total: 0.10 s Wall time: 4.04 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.02 s, sys: 0.00 s, total: 0.02 s Wall time: 0.03 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.02 s, sys: 0.01 s, total: 0.03 s Wall time: 0.04 s 1/4*x^4
and the old Maxima:
age: time integrate(x^3,x) CPU times: user 0.04 s, sys: 0.07 s, total: 0.10 s Wall time: 4.87 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.02 s, sys: 0.00 s, total: 0.02 s Wall time: 0.04 s 1/4*x^4 sage: time integrate(x^3,x) CPU times: user 0.02 s, sys: 0.01 s, total: 0.03 s Wall time: 0.04 s 1/4*x^4
So it was actually faster with the new one.
I managed to update Ecl and Maxima on top of sage 4.5.1 on a Sunblade 1500 (SPARC with Solaris 10), but doctesting maxima.py timedout or died eating all the memory.
comment:58 in reply to: ↑ 56 Changed 9 years ago by
Replying to vbraun:
The new maxima certainly comes with a bigger library; Its inevitable that it is somewhat slower in exchange for being better at integration. I don't know why startup is so slow on kcrisman's antique computer, but stracing the maxima startup shows that it thrashes around quite a lot in the
$SAGE_LOCAL/share/maxima/5.22.1/
directory tree. I say we should press ahead and update maxima so that Sage compiles on Fedora 14. If the new maxima starts up slowly on your hardware then file a ticket and see if you can profile/fix it.
Okay, but you'd still have to address the issue in Comment 52. The best option there is finding similar doctests that don't have different orders, since #9880 isn't necessarily going to be merged in the immediate future (see above).
comment:59 Changed 9 years ago by
comment:60 follow-up: ↓ 61 Changed 9 years ago by
For tickets with many patches and multiple spkg's like this one, it would be very helpful to write in the description precisely which patches have to be applied.
comment:61 in reply to: ↑ 60 Changed 9 years ago by
Replying to jdemeyer:
For tickets with many patches and multiple spkg's like this one, it would be very helpful to write in the description precisely which patches have to be applied.
Dave, as you have admin rights on trac, you could delete the obsolete / redundant http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/sage-maxima.lisp.patch . (It's a "duplicate" of http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/trac_10187_sage-maxima_lisp.patch .)
comment:62 Changed 9 years ago by
- Description modified (diff)
The doctests show one maxima regression:
This simplified to 0 in a previous version. But at least its not wrong ;-)
The attached patch fixes all doctests except for a timeout in maxima. That one is a different issue with maxima, which forgets to print the
general-display-prefix
variable for errors: