Sage: Ticket #10187: Update ECL to 10.4.1 and Maxima to 5.22.1 - currently the latest releases.
https://trac.sagemath.org/ticket/10187
<p>
<strong>Note:</strong> See <a class="closed ticket" href="https://trac.sagemath.org/ticket/10434" title="enhancement: add doctests from #8582 and other integration improvements from Maxima ... (closed: fixed)">#10434</a> for a follow-up ticket.
</p>
<p>
Please update ECL and Maxima to the newest upstream release. Sage packages are here:
</p>
<p>
It's unsafe to build either ECL or Maxima in parallel, so we must not do this. Updated versions of ECL and Maxima can be found here:
</p>
<p>
<a class="ext-link" href="http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg"><span class="icon"></span>http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg</a>
</p>
<p>
<a class="ext-link" href="http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg"><span class="icon"></span>http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg</a>
</p>
<p>
Note that you cannot upgrade one without the other; Both ECL and Maxima need to be upgraded simultaneously or build will fail.
</p>
<p>
Relevant tickets for ECL:
</p>
<ul><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/9493" title="task: Remove extra baggage from the ECL spkg (closed: fixed)">#9493</a>: 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.
</li></ul><ul><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/10185" title="enhancement: ECL in Sage will not build on Fedora 14, which will be released on 2nd ... (closed: invalid)">#10185</a>: the old ecl-10.2.1 does not build on Fedora 14: Hopefully fixed with the updated ECL from this ticket.
</li></ul><p>
Relevant tickets for maxima:
</p>
<ul><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/8645" title="defect: maxima package fails to install ECL library (closed: duplicate)">#8645</a>: ECL library "maxima.fasb" is built at new location. The patches from this bug have been incorporated into the maxima spkg, and <a class="closed ticket" href="https://trac.sagemath.org/ticket/8645" title="defect: maxima package fails to install ECL library (closed: duplicate)">#8645</a> can be closed after this ticket.
</li></ul><ul><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/8731" title="enhancement: update/upgrade maxima to latest upstream (5.21.1) (closed: duplicate)">#8731</a>: update/upgrade Maxima to latest upstream (5.21.1): Latest upstream is nowadays 5.22.1.
</li></ul><ul><li><a class="closed ticket" href="https://trac.sagemath.org/ticket/8582" title="defect: sum(1/(1+k^2), k, -oo, oo) returns 0 (closed: fixed)">#8582</a>: <code>sum(1/(1+k^2), k, -oo, oo)</code> returns 0: The new Maxima seems to be able to evaluate this correctly, at leasts it returns some expression with digamma functions.
</li></ul><p>
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):
</p>
<ul><li><code>trac_10187_fix_easy_doctests.patch</code>
</li><li><code>trac_10187_general_display_prefix_workaround.patch</code>
</li><li><code>trac_10187_mark_some_doctests_random_until_9880_gets_merged.patch</code>
</li></ul><p>
Finally, you need to patch <code>$SAGE_ROOT/local/bin/sage-maxima.lisp</code> with
</p>
<ul><li><code>trac_10187_sage-maxima_lisp.patch</code>
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/10187
Trac 1.1.6kcrismanFri, 29 Oct 2010 16:32:48 GMTcc changed
https://trac.sagemath.org/ticket/10187#comment:1
https://trac.sagemath.org/ticket/10187#comment:1
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
</ul>
TicketvbraunFri, 29 Oct 2010 17:20:08 GMT
https://trac.sagemath.org/ticket/10187#comment:2
https://trac.sagemath.org/ticket/10187#comment:2
<p>
The doctests show one maxima regression:
</p>
<pre class="wiki">sage: t = log(sqrt(2) - 1) + log(sqrt(2) + 1); t
log(sqrt(2) - 1) + log(sqrt(2) + 1)
sage: u = t.maxima_methods(); u
MaximaWrapper(log(sqrt(2) - 1) + log(sqrt(2) + 1))
sage: u.logcontract()
log((sqrt(2) - 1)*(sqrt(2) + 1))
</pre><p>
This simplified to 0 in a previous version. But at least its not wrong ;-)
</p>
<p>
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 <code>general-display-prefix</code> variable for errors:
</p>
<pre class="wiki">(sage subshell) volker-desktop:sage vbraun$ ./local/bin/maxima -p ./local/bin/sage-maxima.lisp
;;; 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) 1;
<sage-display>(%o1) 1
(%i2) 1==1;
incorrect syntax: = is not a prefix operator
1==
^
(%i2) 1=1;
<sage-display>(%o2) 1 = 1
</pre>
TicketdrkirkbyFri, 29 Oct 2010 17:54:28 GMT
https://trac.sagemath.org/ticket/10187#comment:3
https://trac.sagemath.org/ticket/10187#comment:3
<p>
FYI, here's the failures on OpenSolaris 06/2009 with those updated versions of Maxima and ECL.
</p>
<pre class="wiki">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$
</pre><p>
I've not applied any patches at this point. I'll apply patches and rerun later.
</p>
TicketkcrismanFri, 29 Oct 2010 17:56:34 GMT
https://trac.sagemath.org/ticket/10187#comment:4
https://trac.sagemath.org/ticket/10187#comment:4
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:3" title="Comment 3">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
FYI, here's the failures on OpenSolaris 06/2009 with those updated versions of Maxima and ECL.
</p>
</blockquote>
<pre class="wiki">sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py
*** *** Error: TIMED OUT! PROCESS KILLED! *** ***
[1800.2 s]
</pre><p>
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.
</p>
TicketvbraunFri, 29 Oct 2010 18:02:07 GMT
https://trac.sagemath.org/ticket/10187#comment:5
https://trac.sagemath.org/ticket/10187#comment:5
<p>
The TIMED OUT! error is the missing <code>general-display-prefix</code>, which causes the expect interface to wait forever for maxima to print its next prompt.
</p>
<p>
I've filed a bug upstream here: <a class="ext-link" href="https://sourceforge.net/tracker/?func=detail&aid=3098375&group_id=4933&atid=104933"><span class="icon"></span>https://sourceforge.net/tracker/?func=detail&aid=3098375&group_id=4933&atid=104933</a>
</p>
TicketkcrismanFri, 29 Oct 2010 20:23:01 GMT
https://trac.sagemath.org/ticket/10187#comment:6
https://trac.sagemath.org/ticket/10187#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:5" title="Comment 5">vbraun</a>:
</p>
<blockquote class="citation">
<p>
The TIMED OUT! error is the missing <code>general-display-prefix</code>, which causes the expect interface to wait forever for maxima to print its next prompt.
</p>
</blockquote>
<p>
Okay, thanks - so that's unrelated to the Tiger timeout from earlier Maximas.
</p>
TicketvbraunFri, 29 Oct 2010 20:50:47 GMTupstream changed
https://trac.sagemath.org/ticket/10187#comment:7
https://trac.sagemath.org/ticket/10187#comment:7
<ul>
<li><strong>upstream</strong>
changed from <em>N/A</em> to <em>Workaround found; Bug reported upstream.</em>
</li>
</ul>
<p>
I've modified <code>sage/interfaces/maxima.py</code> to work with maxima's <code>prompt_prefix</code> instead. Patch is attached and fixes the remaining doctest error.
</p>
<p>
This requires that `$SAGE_LOCAL/bin/sage-maxima.lisp sets
</p>
<pre class="wiki">; (setf *general-display-prefix* "<sage-display>")
(setf *prompt-prefix* "<sage-display>")
</pre><p>
I've made a updated sage_scripts spkg here:
<a class="ext-link" href="http://www.stp.dias.ie/~vbraun/Sage/spkg/sage_scripts-4.6.rc0.p0.spkg"><span class="icon"></span>http://www.stp.dias.ie/~vbraun/Sage/spkg/sage_scripts-4.6.rc0.p0.spkg</a>
</p>
<p>
To test this ticket, you need all three spkgs and both patches.
</p>
TicketvbraunFri, 29 Oct 2010 20:54:38 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:8
https://trac.sagemath.org/ticket/10187#comment:8
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
</ul>
TicketfbisseyFri, 29 Oct 2010 22:39:52 GMTcc changed
https://trac.sagemath.org/ticket/10187#comment:9
https://trac.sagemath.org/ticket/10187#comment:9
<ul>
<li><strong>cc</strong>
<em>fbissey</em> added
</li>
</ul>
TicketdrkirkbyFri, 29 Oct 2010 23:27:25 GMT
https://trac.sagemath.org/ticket/10187#comment:10
https://trac.sagemath.org/ticket/10187#comment:10
<p>
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:
</p>
<pre class="wiki"> 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.
</pre><p>
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.
</p>
<p>
Dave
</p>
TicketkcrismanSat, 30 Oct 2010 00:13:59 GMT
https://trac.sagemath.org/ticket/10187#comment:11
https://trac.sagemath.org/ticket/10187#comment:11
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:7" title="Comment 7">vbraun</a>:
</p>
<blockquote class="citation">
<p>
I've modified <code>sage/interfaces/maxima.py</code> to work with maxima's <code>prompt_prefix</code> instead. Patch is attached and fixes the remaining doctest error.
</p>
</blockquote>
<p>
Just a very minor note:
</p>
<pre class="wiki"># we are now getting three lines of commented verbosity
</pre><p>
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.
</p>
TicketkcrismanSat, 30 Oct 2010 00:17:34 GMT
https://trac.sagemath.org/ticket/10187#comment:12
https://trac.sagemath.org/ticket/10187#comment:12
<p>
Also, be sure to include a test that shows <a class="closed ticket" href="https://trac.sagemath.org/ticket/8729" title="defect: simple integral using trig functions gives wrong answer (closed: duplicate)">#8729</a> is fixed, as that was closed as a duplicate on the condition that <a class="closed ticket" href="https://trac.sagemath.org/ticket/8731" title="enhancement: update/upgrade maxima to latest upstream (5.21.1) (closed: duplicate)">#8731</a>'s doctests would show that.
</p>
TicketaginiewiczSat, 30 Oct 2010 08:57:59 GMT
https://trac.sagemath.org/ticket/10187#comment:13
https://trac.sagemath.org/ticket/10187#comment:13
<p>
I looked trough doctest patch and compared it with mine from <a class="closed ticket" href="https://trac.sagemath.org/ticket/8731" title="enhancement: update/upgrade maxima to latest upstream (5.21.1) (closed: duplicate)">#8731</a>, I have few comments.
</p>
<p>
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?
</p>
<p>
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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/8731" title="enhancement: update/upgrade maxima to latest upstream (5.21.1) (closed: duplicate)">#8731</a>.
</p>
<p>
Finally, there is typo in doctest to sage/symbolic/expression.pyx - it should say that this doctest is here to check that <a class="closed ticket" href="https://trac.sagemath.org/ticket/7334" title="defect: Sage cannot simplify sums of logarithms (closed: fixed)">#7334</a> not <a class="closed ticket" href="https://trac.sagemath.org/ticket/7344" title="enhancement: New libjpeg package (closed: invalid)">#7344</a> is fixed (<a class="closed ticket" href="https://trac.sagemath.org/ticket/7344" title="enhancement: New libjpeg package (closed: invalid)">#7344</a> 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 - <a class="ext-link" href="http://sourceforge.net/tracker/?func=detail&aid=947808&group_id=4933&atid=104933"><span class="icon"></span>http://sourceforge.net/tracker/?func=detail&aid=947808&group_id=4933&atid=104933</a> - 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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/7334" title="defect: Sage cannot simplify sums of logarithms (closed: fixed)">#7334</a> would be still fixed. Now, this doctest shows nothing.
</p>
TicketdrkirkbySat, 30 Oct 2010 14:05:37 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:14
https://trac.sagemath.org/ticket/10187#comment:14
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
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:
</p>
<pre class="wiki">=== 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) ===
</pre><p>
but instead SPKG.txt shows
</p>
<pre class="wiki">=== 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) ===
</pre><p>
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.
</p>
<p>
The current version of ECL in Sage should have been used as a starting point - not an old one that was never merged.
</p>
<p>
I'll sort the above problem out, and add the ECL test code today.
</p>
<p>
Dave
</p>
TicketfbisseySat, 30 Oct 2010 22:54:43 GMT
https://trac.sagemath.org/ticket/10187#comment:15
https://trac.sagemath.org/ticket/10187#comment:15
<p>
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?
</p>
TicketleifSun, 31 Oct 2010 02:03:04 GMT
https://trac.sagemath.org/ticket/10187#comment:16
https://trac.sagemath.org/ticket/10187#comment:16
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:7" title="Comment 7">vbraun</a>:
</p>
<blockquote class="citation">
<p>
I've modified <code>sage/interfaces/maxima.py</code> to work with maxima's <code>prompt_prefix</code> instead. Patch is attached and fixes the remaining doctest error.
</p>
<p>
This requires that `$SAGE_LOCAL/bin/sage-maxima.lisp sets
</p>
</blockquote>
<pre class="wiki">; (setf *general-display-prefix* "<sage-display>")
(setf *prompt-prefix* "<sage-display>")
</pre><blockquote class="citation">
<p>
I've made a updated sage_scripts spkg here:
<a class="ext-link" href="http://www.stp.dias.ie/~vbraun/Sage/spkg/sage_scripts-4.6.rc0.p0.spkg"><span class="icon"></span>http://www.stp.dias.ie/~vbraun/Sage/spkg/sage_scripts-4.6.rc0.p0.spkg</a>
</p>
<p>
To test this ticket, you need all three spkgs and both patches.
</p>
</blockquote>
<p>
Could you please attach a <em>patch to the scripts repo</em>, too (rather than a link to a complete new scripts spkg)?
</p>
<p>
Also, attaching diffs (or Mercurial patches) of the spkgs makes reviewing easier.
</p>
TicketleifSun, 31 Oct 2010 02:20:38 GMT
https://trac.sagemath.org/ticket/10187#comment:17
https://trac.sagemath.org/ticket/10187#comment:17
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:16" title="Comment 16">leif</a>:
</p>
<blockquote class="citation">
<p>
Could you please attach a <em>patch to the scripts repo</em>, too (rather than a link to a complete new scripts spkg)?
</p>
</blockquote>
<p>
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.
</p>
TicketvbraunSun, 31 Oct 2010 02:45:14 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>trac_10187_general_display_prefix_workaround.patch</em>
</li>
</ul>
<p>
Updated patch
</p>
TicketvbraunSun, 31 Oct 2010 02:51:59 GMT
https://trac.sagemath.org/ticket/10187#comment:18
https://trac.sagemath.org/ticket/10187#comment:18
<p>
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
</p>
<ul><li>trac_10187_fix_easy_doctests.patch
</li><li>trac_10187_general_display_prefix_workaround.patch
</li></ul><p>
I'll attach patches for the <code>sage_scripts</code> and <code>maxima</code> spgk for easier review. Once Dave is finished with the ecl package then this ticket is ready for review again.
</p>
TicketfbisseySun, 31 Oct 2010 03:47:02 GMT
https://trac.sagemath.org/ticket/10187#comment:19
https://trac.sagemath.org/ticket/10187#comment:19
<p>
Wrong order indeed! I thought the two patches were orthogonal.
</p>
TicketdrkirkbySun, 31 Oct 2010 20:51:47 GMT
https://trac.sagemath.org/ticket/10187#comment:20
https://trac.sagemath.org/ticket/10187#comment:20
<p>
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.
</p>
<p>
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.
</p>
<p>
Dave
</p>
TicketdrkirkbyTue, 09 Nov 2010 09:15:21 GMT
https://trac.sagemath.org/ticket/10187#comment:21
https://trac.sagemath.org/ticket/10187#comment:21
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:20" title="Comment 20">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
<p>
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.
</p>
<p>
Dave
</p>
</blockquote>
<p>
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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/9840" title="defect: link-editor thinks ECL library contains non-pic code on *all* ... (closed: duplicate)">#9840</a>, so I'll patch that too, so <a class="closed ticket" href="https://trac.sagemath.org/ticket/9840" title="defect: link-editor thinks ECL library contains non-pic code on *all* ... (closed: duplicate)">#9840</a> can hopefully be closed at the same time.
</p>
<p>
I'll try to get this sorted out within the next few days.
</p>
<p>
Dave
</p>
TicketdrkirkbyThu, 11 Nov 2010 18:11:59 GMTdescription, author changed
https://trac.sagemath.org/ticket/10187#comment:22
https://trac.sagemath.org/ticket/10187#comment:22
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/10187?action=diff&version=22">diff</a>)
</li>
<li><strong>author</strong>
changed from <em>Volker Braun</em> to <em>Volker Braun, David Kirkby</em>
</li>
</ul>
<p>
I have put an updated ECL file at <a class="ext-link" href="http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg"><span class="icon"></span>http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg</a> 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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/10185" title="enhancement: ECL in Sage will not build on Fedora 14, which will be released on 2nd ... (closed: invalid)">#10185</a>
</p>
<p>
I should make a few comments about this:
</p>
<ul><li>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.
</li><li>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).
</li><li>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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/9840" title="defect: link-editor thinks ECL library contains non-pic code on *all* ... (closed: duplicate)">#9840</a> remains unresolved, though it should be fixed when the next stable ECL release is made.
</li><li>I've cleaned the package up somewhat.
</li><li>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.
</li></ul><p>
After
</p>
<ul><li>Installing the new ECL package I created, and put at <a class="ext-link" href="http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg"><span class="icon"></span>http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg</a>
</li><li>Installing the Maxima package from <a class="ext-link" href="http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg"><span class="icon"></span>http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg</a>
</li><li>Trying to install all the patches (one failed, see below)
</li><li>Rebuilding the Sage library.
</li><li>Running all the doctests, which all pass.
</li></ul><p>
I get one reject out of six when adding
</p>
<p>
<code>trac_10187_general_display_prefix_workaround.patch</code>
</p>
<p>
to sage 4.6.1.alpha0, so I think that patch needs updating. The contents of the reject are:
</p>
<pre class="wiki">--- 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 ''
</pre><p>
But as I say, all doctests passed for me, despite one patch was not fully applied!!
</p>
<pre class="wiki">----------------------------------------------------------------------
All tests passed!
Total time for all tests: 1871.3 seconds
</pre><p>
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.
</p>
<p>
Dave
</p>
TicketvbraunThu, 11 Nov 2010 18:36:03 GMT
https://trac.sagemath.org/ticket/10187#comment:23
https://trac.sagemath.org/ticket/10187#comment:23
<p>
Dave's <code>ecl-10.4.1.spkg</code> 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.
</p>
TicketvbraunThu, 11 Nov 2010 22:24:41 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:24
https://trac.sagemath.org/ticket/10187#comment:24
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Patches apply cleanly on sage 4.6.1.alpha0. As I wrote in <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/10187#comment:18"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/10187#comment:18</a>, they need to be applied in the order
</p>
<ul><li>trac_10187_fix_easy_doctests.patch
</li><li>trac_10187_general_display_prefix_workaround.patch
</li></ul>
TicketdrkirkbyThu, 11 Nov 2010 22:43:00 GMT
https://trac.sagemath.org/ticket/10187#comment:25
https://trac.sagemath.org/ticket/10187#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:24" title="Comment 24">vbraun</a>:
</p>
<blockquote class="citation">
<p>
Patches apply cleanly on sage 4.6.1.alpha0. As I wrote in <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/10187#comment:18"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/10187#comment:18</a>, they need to be applied in the order
</p>
<ul><li>trac_10187_fix_easy_doctests.patch
</li><li>trac_10187_general_display_prefix_workaround.patch
</li></ul></blockquote>
<p>
Perhaps I did not have a clean sage 4.6.1.alpha0. I will start a fresh build and try again.
</p>
<p>
Dave
</p>
TicketdrkirkbyThu, 11 Nov 2010 23:03:41 GMT
https://trac.sagemath.org/ticket/10187#comment:26
https://trac.sagemath.org/ticket/10187#comment:26
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:24" title="Comment 24">vbraun</a>:
</p>
<blockquote class="citation">
<p>
Patches apply cleanly on sage 4.6.1.alpha0. As I wrote in <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/10187#comment:18"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/10187#comment:18</a>, they need to be applied in the order
</p>
<ul><li>trac_10187_fix_easy_doctests.patch
</li><li>trac_10187_general_display_prefix_workaround.patch
</li></ul></blockquote>
<p>
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!
</p>
<p>
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.
</p>
<p>
Dave
</p>
TicketdrkirkbyFri, 12 Nov 2010 00:10:33 GMT
https://trac.sagemath.org/ticket/10187#comment:27
https://trac.sagemath.org/ticket/10187#comment:27
<p>
OK, this is fine on OpenSolaris 06/2009 and Fedora 14. What about any other platforms?
</p>
TicketfbisseyMon, 15 Nov 2010 10:41:10 GMT
https://trac.sagemath.org/ticket/10187#comment:28
https://trac.sagemath.org/ticket/10187#comment:28
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:27" title="Comment 27">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
OK, this is fine on OpenSolaris 06/2009 and Fedora 14. What about any other platforms?
</p>
</blockquote>
<p>
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.
</p>
TicketdrkirkbyMon, 15 Nov 2010 11:16:30 GMT
https://trac.sagemath.org/ticket/10187#comment:29
https://trac.sagemath.org/ticket/10187#comment:29
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:28" title="Comment 28">fbissey</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
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
</p>
<ul><li>Any OS X release
</li><li>Solaris 10 on SPARC
</li><li>Solaris 10 on x86
</li></ul><p>
all of which are supported platforms.
</p>
<p>
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.
</p>
<p>
Dave
</p>
TicketjpfloriMon, 15 Nov 2010 11:45:50 GMTcc changed
https://trac.sagemath.org/ticket/10187#comment:30
https://trac.sagemath.org/ticket/10187#comment:30
<ul>
<li><strong>cc</strong>
<em>jpflori</em> added
</li>
</ul>
TicketkcrismanMon, 15 Nov 2010 19:00:13 GMT
https://trac.sagemath.org/ticket/10187#comment:31
https://trac.sagemath.org/ticket/10187#comment:31
<p>
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.
</p>
TicketjpfloriTue, 16 Nov 2010 12:06:43 GMT
https://trac.sagemath.org/ticket/10187#comment:32
https://trac.sagemath.org/ticket/10187#comment:32
<p>
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.
</p>
<pre class="wiki">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
</pre><p>
It should be noted that the Maxima update fixes <a class="closed ticket" href="https://trac.sagemath.org/ticket/7952" title="defect: broken binomial sum (fixed in maxima) (closed: fixed)">#7952</a> (and <a class="closed ticket" href="https://trac.sagemath.org/ticket/10273" title="defect: Maxima returns wrong value for sum(binomial(j,k),j,k,n) (closed: duplicate)">#10273</a> I opened by mistake and closed as duplicate).
</p>
TicketkcrismanTue, 16 Nov 2010 14:37:42 GMTstatus changed; reviewer, work_issues set
https://trac.sagemath.org/ticket/10187#comment:33
https://trac.sagemath.org/ticket/10187#comment:33
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>reviewer</strong>
set to <em>Karl-Dieter Crisman</em>
</li>
<li><strong>work_issues</strong>
set to <em>new interface patch needs help</em>
</li>
</ul>
<p>
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.
</p>
<pre class="wiki">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
</pre><p>
I also get the following:
</p>
<pre class="wiki">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!
</pre><p>
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.
</p>
<p>
Though in that case I do get
</p>
<pre class="wiki">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)
**********************************************************************
</pre><p>
which is interesting; if you find where they differ (hint - transposed multiplication), you win the Where's Waldo award.
</p>
<p>
I'll report back if there are any other errors without it.
</p>
TicketvbraunTue, 16 Nov 2010 15:14:45 GMT
https://trac.sagemath.org/ticket/10187#comment:34
https://trac.sagemath.org/ticket/10187#comment:34
<p>
kcrisman: looks like you did not install the updated <code>sage_scripts-4.6.rc0.p0.spkg</code>, see <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/10187#comment:7"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/10187#comment:7</a>
</p>
TicketjdemeyerTue, 16 Nov 2010 16:20:09 GMT
https://trac.sagemath.org/ticket/10187#comment:35
https://trac.sagemath.org/ticket/10187#comment:35
<p>
If sage_scripts needs to be patched, please provide a hg patch for that.
</p>
TicketjpfloriTue, 16 Nov 2010 16:34:21 GMT
https://trac.sagemath.org/ticket/10187#comment:36
https://trac.sagemath.org/ticket/10187#comment:36
<p>
It is sage-maxima.lisp.patch provided in the ticked.
</p>
<p>
It applies cleanly on sage_script spkg of sage 4.6.1.alpha2 for me and tests pass.
</p>
TicketkcrismanTue, 16 Nov 2010 16:51:19 GMT
https://trac.sagemath.org/ticket/10187#comment:37
https://trac.sagemath.org/ticket/10187#comment:37
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:35" title="Comment 35">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
If sage_scripts needs to be patched, please provide a hg patch for that.
</p>
</blockquote>
<p>
Looks like it needs a commit message to apply straight-up with <code>hg_scripts</code>, so it's not ready as it stands, perhaps.
</p>
<p>
Without *either* of those patches, I get most relevant tests passing EXCEPT the <code>taylor(gamma(1/3+x),x,0,3)</code> 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.
</p>
<p>
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.
</p>
TicketvbraunTue, 16 Nov 2010 17:28:34 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>trac_10187_sage-maxima_lisp.patch</em>
</li>
</ul>
<p>
patch to SAGE_LOCAL/bin/sage_maxima.lisp with commit message
</p>
TicketvbraunTue, 16 Nov 2010 17:34:43 GMTstatus changed; work_issues deleted
https://trac.sagemath.org/ticket/10187#comment:38
https://trac.sagemath.org/ticket/10187#comment:38
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>work_issues</strong>
<em>new interface patch needs help</em> deleted
</li>
</ul>
<p>
I've added a patch for <code>sage-maxima.lisp</code> as <code>trac_10187_sage-maxima_lisp.patch</code>.
</p>
<p>
To summarize, you need to
</p>
<ol><li>Apply <code>trac_10187_sage-maxima_lisp.patch</code> to SAGE_LOCAL/bin
</li><li><a class="ext-link" href="http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg"><span class="icon"></span>http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.4.1.spkg</a>
</li><li><a class="ext-link" href="http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg"><span class="icon"></span>http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg</a>
</li><li>Apply trac_10187_fix_easy_doctests.patch to the sage library
</li><li>Apply trac_10187_general_display_prefix_workaround.patch to the sage library
</li></ol><p>
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.
</p>
TicketkcrismanTue, 16 Nov 2010 19:40:01 GMT
https://trac.sagemath.org/ticket/10187#comment:39
https://trac.sagemath.org/ticket/10187#comment:39
<p>
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:
</p>
<pre class="wiki">
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)]
**********************************************************************
</pre><p>
There are several transpositions of <code>abs(z)*sin(theta)</code> in this one, just like the transposition of <code>psi(1, 1/3)*log(3)</code> in the other error.
</p>
<p>
I get
</p>
<pre class="wiki">
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'
</pre><p>
which looks like the 'expected' line. I also get
</p>
<pre class="wiki">sage: psi(1,1/3)*log(3)
log(3)*psi(1, 1/3)
</pre><p>
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?)
</p>
TicketvbraunTue, 16 Nov 2010 19:58:26 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:40
https://trac.sagemath.org/ticket/10187#comment:40
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
</ul>
<p>
Can you double-check that the maxima binary works? you should get:
</p>
<pre class="wiki">[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)
</pre>
TicketkcrismanTue, 16 Nov 2010 20:30:46 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:41
https://trac.sagemath.org/ticket/10187#comment:41
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
<p>
RReplying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:40" title="Comment 40">vbraun</a>:
</p>
<blockquote class="citation">
<p>
Can you double-check that the maxima binary works? you should get:
</p>
</blockquote>
<p>
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 <code>sage -sh</code>, from <code>maxima_console</code>, etc.
</p>
<p>
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) <a class="closed ticket" href="https://trac.sagemath.org/ticket/9361" title="defect: Maxima timeout on Mac OS X 10.4 (Tiger) (closed: fixed)">#9361</a>.
</p>
<p>
Putting to needs work because of this weird multiplication issue.
</p>
TicketvbraunTue, 16 Nov 2010 20:38:19 GMT
https://trac.sagemath.org/ticket/10187#comment:42
https://trac.sagemath.org/ticket/10187#comment:42
<blockquote class="citation">
<p>
yes, it works on OS X 10.6.
</p>
</blockquote>
<p>
Does maxima return <code>psi(1,1/3)*log(3)</code> in this order or in the reversed order?
</p>
TicketkcrismanTue, 16 Nov 2010 21:04:48 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:43
https://trac.sagemath.org/ticket/10187#comment:43
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:42" title="Comment 42">vbraun</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
yes, it works on OS X 10.6.
</p>
</blockquote>
<p>
Does maxima return <code>psi(1,1/3)*log(3)</code> in this order or in the reversed order?
</p>
</blockquote>
<p>
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.
</p>
<p>
Sorry, put to wrong thing before - needs work because of this, or needs info if you like.
</p>
TicketvbraunTue, 16 Nov 2010 21:29:25 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:44
https://trac.sagemath.org/ticket/10187#comment:44
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_info</em>
</li>
</ul>
<p>
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.
</p>
TicketddrakeTue, 16 Nov 2010 22:55:13 GMT
https://trac.sagemath.org/ticket/10187#comment:45
https://trac.sagemath.org/ticket/10187#comment:45
<p>
On Ubuntu 10.04 64-bit with 4.6.1.alpha1, everything is working -- all "ptestlong" tests pass.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:39" title="Comment 39">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
I get
</p>
<pre class="wiki">
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'
</pre><p>
which looks like the 'expected' line. I also get
</p>
<pre class="wiki">sage: psi(1,1/3)*log(3)
log(3)*psi(1, 1/3)
</pre><p>
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?)
</p>
</blockquote>
<p>
Here's what I get for those commands with all the patches and spkgs here, in 4.6.1.alpha1:
</p>
<pre class="wiki">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)
</pre>
TicketkcrismanWed, 17 Nov 2010 02:52:17 GMT
https://trac.sagemath.org/ticket/10187#comment:46
https://trac.sagemath.org/ticket/10187#comment:46
<p>
Dan, thanks for that confirmation of the issue.
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:44" title="Comment 44">vbraun</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
Actually, I'm pretty sure it's an unrelated bug in something else. At first I thought <a class="missing wiki">Pynac/Ginac?</a>, but maybe not (?) - in Sage 4.6 on PPC, I get
</p>
<pre class="wiki">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']
</pre><p>
This machine doesn't have the new Maxima, so it's definitely unrelated.
</p>
<p>
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 <code>x^3</code> created this.
</p>
<p>
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
</p>
<pre class="wiki">sage: taylor(gamma(1/4+x),x,0,3)
</pre><p>
except I can't tell you what the Mac output is on this until tomorrow - maybe someone else can.
</p>
<p>
The new ticket is <a class="closed ticket" href="https://trac.sagemath.org/ticket/10282" title="defect: Discrepancy in symbol ordering in multiplication (closed: duplicate)">#10282</a>.
</p>
TicketjpfloriWed, 17 Nov 2010 11:34:30 GMT
https://trac.sagemath.org/ticket/10187#comment:47
https://trac.sagemath.org/ticket/10187#comment:47
<p>
I installed Sage on a Mac:
</p>
<p>
Machine Name: Power Mac G5
</p>
<blockquote>
<p>
Machine Model: !PowerMac11,2
</p>
</blockquote>
<blockquote>
<p>
CPU Type: PowerPC G5 (1.1)
</p>
</blockquote>
<p>
with Mac OS X:
</p>
<blockquote>
<p>
System Version: Mac OS X 10.4.11 (8S165)
</p>
</blockquote>
<blockquote>
<p>
Kernel Version: Darwin 8.11.0
</p>
</blockquote>
<p>
from binary packages:
</p>
<p>
<a href="http://www.sagemath.org/download-mac.html">http://www.sagemath.org/download-mac.html</a>
</p>
<p>
and using cp -R - A ... to a custom directory because I don't have admin rights.
</p>
<p>
So I got Sage 4.6.
</p>
<p>
I ran Sage once.
</p>
<p>
I then patched sage_scripts (downloaded spkg, uncompressed, hg qimport patch, hg qpush) and installed it.
</p>
<p>
I installed ecl-10.4 and maxima5.22.1 spkgs.
</p>
<p>
I ran ./sage -b but got problem of paths, it was looking in <a class="missing wiki">/Users/Shared?</a>/sage/sage-4.6/ ...
</p>
<p>
So I moved my installation folder there and ./sage -b worked.
</p>
<p>
I then ran ./sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py
</p>
<p>
and everything was fine:
</p>
<pre class="wiki">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
</pre><p>
I'll try to test on a SPARC machine with Solaris 10 soon.
</p>
TicketjpfloriWed, 17 Nov 2010 11:58:43 GMT
https://trac.sagemath.org/ticket/10187#comment:48
https://trac.sagemath.org/ticket/10187#comment:48
<p>
I'm currently running all long doctest on the Mac machine I have access to.
</p>
<p>
The Mac output for taylor(gamma(1/4+x),x,0,3) is:
</p>
<pre class="wiki">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)
</pre><p>
On Linux with latest alpha I get :
</p>
<pre class="wiki">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)
</pre><p>
which is not the same.Look at 72*...
</p>
TicketkcrismanWed, 17 Nov 2010 14:04:20 GMT
https://trac.sagemath.org/ticket/10187#comment:49
https://trac.sagemath.org/ticket/10187#comment:49
<blockquote class="citation">
<p>
Machine Name: Power Mac G5
</p>
<blockquote>
<p>
System Version: Mac OS X 10.4.11 (8S165)
</p>
</blockquote>
<p>
I then ran ./sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py
</p>
</blockquote>
<p>
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...
</p>
<p>
Unfortunately, I did not have any luck with relieving the timeouts on my machine in any file which actually uses Maxima. With <code>SAGE_TIMEOUT_LONG=5000</code> 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.
</p>
<p>
I'll try to look at this more later today.
</p>
TicketjpfloriThu, 18 Nov 2010 11:46:59 GMT
https://trac.sagemath.org/ticket/10187#comment:50
https://trac.sagemath.org/ticket/10187#comment:50
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:49" title="Comment 49">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
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...
</p>
</blockquote>
<p>
It also passes without the froce_lib option (in 52.1 seconds).
</p>
<p>
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 <a class="ext-link" href="http://groups.google.com/group/sage-devel/browse_thread/thread/09e4cef8c8558150"><span class="icon"></span>http://groups.google.com/group/sage-devel/browse_thread/thread/09e4cef8c8558150</a># :
</p>
<pre class="wiki">----------------------------------------------------------------------
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
</pre><p>
And on the Mac with 4.6:
</p>
<pre class="wiki">----------------------------------------------------------------------
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
</pre>
TicketkcrismanThu, 18 Nov 2010 15:09:14 GMT
https://trac.sagemath.org/ticket/10187#comment:51
https://trac.sagemath.org/ticket/10187#comment:51
<p>
Okay, so the failures are the same as on mine *before* I add the two patches to the Maxima interface.
</p>
<p>
Summary:
</p>
<ol><li>All Macs have some sort of multiplication transposition, so we will either have to simultaneously fix <a class="closed ticket" href="https://trac.sagemath.org/ticket/10282" title="defect: Discrepancy in symbol ordering in multiplication (closed: duplicate)">#10282</a> or find different doctests for those two examples (the taylor of gamma and the matrix in plot3d/transform.pyx).
</li></ol><ol><li>Debian and <a class="missing wiki">OpenSolaris?</a> seem ok.
</li></ol><ol><li>Other <a class="missing wiki">Linux/Solaris?</a> still needed?
</li></ol><ol><li>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).
</li></ol><p>
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:
</p>
<pre class="wiki">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
</pre><p>
But I think the way doctests work is that things are restarted from function to function - is that right?
</p>
<p>
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.
</p>
TicketjpfloriThu, 18 Nov 2010 16:15:31 GMT
https://trac.sagemath.org/ticket/10187#comment:52
https://trac.sagemath.org/ticket/10187#comment:52
<blockquote class="citation">
<p>
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 <code>x^3</code> 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 <code> sage: taylor(gamma(1/4+x),x,0,3) </code> except I can't tell you what the Mac output is on this until tomorrow - maybe someone else can. The new ticket is <a class="closed ticket" href="https://trac.sagemath.org/ticket/10282" title="defect: Discrepancy in symbol ordering in multiplication (closed: duplicate)">#10282</a>.
</p>
</blockquote>
<p>
As noted by Burcin in <a class="closed ticket" href="https://trac.sagemath.org/ticket/10282" title="defect: Discrepancy in symbol ordering in multiplication (closed: duplicate)">#10282</a> , it is related to pynac ordering and applying the patch I provided in <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a> gives me a consistent behavior on Mac and Linux:
</p>
<pre class="wiki">sage: psi(1,1/3)*log(3)
log(3)*psi(1, 1/3)
</pre><p>
(I order the functions according to their name in lexicographic order)
</p>
<p>
However <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a> still needs a lot of work:
</p>
<ul><li>my patch must be reviewed
</li></ul><ul><li>pynac must be updated
</li></ul><ul><li>a lot of doctests will have to be fixed afterwards
</li></ul>
TicketkcrismanThu, 18 Nov 2010 16:33:20 GMT
https://trac.sagemath.org/ticket/10187#comment:53
https://trac.sagemath.org/ticket/10187#comment:53
<p>
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...
</p>
<p>
Yup, I just saw that update on <a class="closed ticket" href="https://trac.sagemath.org/ticket/10282" title="defect: Discrepancy in symbol ordering in multiplication (closed: duplicate)">#10282</a>. So we have three options for this ticket:
</p>
<p>
Ignore the Mac doctest failure as a known issue with an open ticket OR make the failing doctests optional based on platform until <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a> is reviewed and merged etc. OR find similar doctests where the order doesn't matter.
</p>
TicketkcrismanThu, 18 Nov 2010 16:57:14 GMT
https://trac.sagemath.org/ticket/10187#comment:54
https://trac.sagemath.org/ticket/10187#comment:54
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:53" title="Comment 53">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
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...
</p>
</blockquote>
<p>
Even weirder - testing a file with no long doctests, but which uses Maxima, passes without <code>-long</code> and times out with it. WHAT?
</p>
TicketkcrismanMon, 22 Nov 2010 13:37:24 GMT
https://trac.sagemath.org/ticket/10187#comment:55
https://trac.sagemath.org/ticket/10187#comment:55
<p>
Okay, after reverting to the previous ECL/Maxima on this machine, I get
</p>
<pre class="wiki">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
</pre><p>
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.
</p>
TicketvbraunTue, 23 Nov 2010 04:59:32 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:56
https://trac.sagemath.org/ticket/10187#comment:56
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
</ul>
<p>
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 <code>$SAGE_LOCAL/share/maxima/5.22.1/</code> directory tree.
</p>
<p>
For the record, Fedora 14 on a Thinkpad T410s Core i5:
</p>
<pre class="wiki">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
</pre><p>
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.
</p>
TicketjpfloriTue, 23 Nov 2010 12:10:29 GMT
https://trac.sagemath.org/ticket/10187#comment:57
https://trac.sagemath.org/ticket/10187#comment:57
<p>
On my <a class="missing wiki">Core 2 Quad?</a> running Debian, here are the timings for the new Maxima:
</p>
<pre class="wiki">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
</pre><p>
and with the old Maxima:
</p>
<pre class="wiki">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
</pre><p>
On the Power G5 with the new Maxima:
</p>
<pre class="wiki">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
</pre><p>
and the old Maxima:
</p>
<pre class="wiki">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
</pre><p>
So it was actually faster with the new one.
</p>
<p>
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.
</p>
TicketkcrismanTue, 23 Nov 2010 15:08:57 GMT
https://trac.sagemath.org/ticket/10187#comment:58
https://trac.sagemath.org/ticket/10187#comment:58
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:56" title="Comment 56">vbraun</a>:
</p>
<blockquote class="citation">
<p>
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 <code>$SAGE_LOCAL/share/maxima/5.22.1/</code> 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.
</p>
</blockquote>
<p>
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 <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a> isn't necessarily going to be merged in the immediate future (see above).
</p>
TicketvbraunWed, 24 Nov 2010 01:17:34 GMT
https://trac.sagemath.org/ticket/10187#comment:59
https://trac.sagemath.org/ticket/10187#comment:59
<p>
OK lets mark the offending doctests <code># random output</code> until <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a> is fixed. I'll attach a complimentary patch to <a class="closed ticket" href="https://trac.sagemath.org/ticket/9880" title="defect: Pynac comparison functions do not provide a SWO (closed: fixed)">#9880</a> that reverts <code>trac_10187_mark_some_doctests_random_until_9880_gets_merged.patch</code>.
</p>
TicketjdemeyerFri, 26 Nov 2010 08:36:24 GMT
https://trac.sagemath.org/ticket/10187#comment:60
https://trac.sagemath.org/ticket/10187#comment:60
<p>
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.
</p>
TicketleifFri, 26 Nov 2010 09:12:28 GMT
https://trac.sagemath.org/ticket/10187#comment:61
https://trac.sagemath.org/ticket/10187#comment:61
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:60" title="Comment 60">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
Dave, as you have admin rights on trac, you could delete the obsolete / redundant <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/sage-maxima.lisp.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/sage-maxima.lisp.patch</a> . (It's a "duplicate" of <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/trac_10187_sage-maxima_lisp.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/trac_10187_sage-maxima_lisp.patch</a> .)
</p>
TicketvbraunFri, 26 Nov 2010 09:22:50 GMTdescription changed
https://trac.sagemath.org/ticket/10187#comment:62
https://trac.sagemath.org/ticket/10187#comment:62
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/10187?action=diff&version=62">diff</a>)
</li>
</ul>
TicketleifFri, 26 Nov 2010 10:43:41 GMT
https://trac.sagemath.org/ticket/10187#comment:63
https://trac.sagemath.org/ticket/10187#comment:63
<p>
The Maxima spkg IMHO needs work; not sure if on another ticket. (I guess the authors will say yes; I personally don't like postponing spkg changes very much, since this tends to make them never happen, or leads to concurrent, "incompatible" changes.)
</p>
<p>
Besides minor things (like unquoted <code>SAGE_LOCAL</code>), unsetting <code>MAKE</code> and using <code>make</code> is a very bad thing to do. This doesn't work as expected (or intended) with <code>MAKE=make -j</code> by the way, and prohibits the user to use different <code>make</code>s, or pass other options in it.
</p>
<p>
(Currently <code>$SAGE_ROOT/spkg/install</code> does similar if <code>SAGE_PARALLEL_SPKG_BUILD</code> is not "yes", but that's equally wrong, and that code isn't executed when doing e.g. <code>./sage -i ...</code>.)
</p>
<p>
Also, I see no reason for not removing GMP from the ECL source tree, which more than halves the size of the ECL spkg. This requires just a trivial change to <code>configure</code> s.t. a different copy of <code>install-sh</code> is used. (See <a class="closed ticket" href="https://trac.sagemath.org/ticket/9493" title="task: Remove extra baggage from the ECL spkg (closed: fixed)">#9493</a>. To me it's pointless to create yet another spkg and bump the patch level for such a change when we're already at it, at least if it's likely to get merged into a different Sage release, which then causes completely useless downloads and rebuilds on upgrades.)
</p>
<p>
Such a patch to <code>configure</code> is a very good use case for the newly included GNU <code>patch</code>, since <code>configure</code> is huge while the patch is tiny, so putting a patched copy in <code>patches/</code> would again - now really unnecessarily - increase the size of the resulting spkg.
</p>
<p>
I'm not sure if there are other changes from the previous attempt to update ECL not made in the current spkg here.
</p>
TicketleifFri, 26 Nov 2010 10:56:14 GMT
https://trac.sagemath.org/ticket/10187#comment:64
https://trac.sagemath.org/ticket/10187#comment:64
<pre class="wiki"> * Removed comments about removing the src/contrib/encodings directory,
as there is no such directory.
</pre><div class="wiki-code"><div class="code"><pre>~/Sage/spkgs/ecl-10.4.1<span class="nv">$ </span>ls src/contrib/encodings/
ATARIST.BIN DOS-CP855.BIN DOS-CP865.BIN ISO-8859-10.BIN ISO-8859-2.BIN ISO-8859-9.BIN tools.lisp WINDOWS-CP1256.BIN
CP-856.BIN DOS-CP857.BIN DOS-CP866.BIN ISO-8859-11.BIN ISO-8859-3.BIN JISX0201.BIN WINDOWS-CP1250.BIN WINDOWS-CP1257.BIN
DOS-CP437.BIN DOS-CP860.BIN DOS-CP869.BIN ISO-8859-13.BIN ISO-8859-4.BIN JISX0208.BIN WINDOWS-CP1251.BIN WINDOWS-CP1258.BIN
DOS-CP737.BIN DOS-CP861.BIN DOS-CP874.BIN ISO-8859-14.BIN ISO-8859-5.BIN JISX0212.BIN WINDOWS-CP1252.BIN WINDOWS-CP932.BIN
DOS-CP775.BIN DOS-CP862.BIN generate.lisp ISO-8859-15.BIN ISO-8859-6.BIN KOI8-R.BIN WINDOWS-CP1253.BIN WINDOWS-CP936.BIN
DOS-CP850.BIN DOS-CP863.BIN ISO-2022-JP ISO-8859-16.BIN ISO-8859-7.BIN KOI8-U.BIN WINDOWS-CP1254.BIN WINDOWS-CP949.BIN
DOS-CP852.BIN DOS-CP864.BIN ISO-2022-JP-1 ISO-8859-1.BIN ISO-8859-8.BIN SHIFT-JIS.BIN WINDOWS-CP1255.BIN WINDOWS-CP950.BIN
</pre></div></div>
TicketleifFri, 26 Nov 2010 11:07:35 GMT
https://trac.sagemath.org/ticket/10187#comment:65
https://trac.sagemath.org/ticket/10187#comment:65
<pre class="wiki"> * Removed the 'patches' directory as there are no patches!
</pre><div class="wiki-code"><div class="code"><pre>~/Sage/spkgs/ecl-10.4.1<span class="nv">$ </span>ls -l patches/
ls: cannot access patches/: No such file or directory
</pre></div></div><div class="wiki-code"><div class="code"><pre><span class="c"># Add a patch which works around a gcc bug on Solaris. Actually
# the code is not standard C, but a GCC extension, which does
# not work on Solaris, causing relocation issues - see
# http://trac.sagemath.org/sage_trac/ticket/9840
# This is committed to the ECL trunk, so can be removed
# whenever we update to a version of ECL newer than 10.4.1.
</span>cp patches/bytecodes.h src/src/h/bytecodes.h
</pre></div></div>
TicketvbraunFri, 26 Nov 2010 11:10:55 GMT
https://trac.sagemath.org/ticket/10187#comment:66
https://trac.sagemath.org/ticket/10187#comment:66
<p>
What is the correct way to force-disable parallel make, then?
</p>
<p>
Apart from that, do you have any other issue than the unquoted <code>SAGE_LOCAL</code> (which this ticked did not add) for the maxima spkg? I'm happy to fix "minor things", but at the very least you have to list them if you want them fixed.
</p>
<p>
I don't think that saving 1 MB is good enough a reason to justify patching ecl's <code>configure</code> and maintaining that patch in future versions. If you want to save space then there are much bigger spkgs that could be shrunk. Or, better yet, if you have the time then fix some real bugs...
</p>
TicketleifFri, 26 Nov 2010 11:11:51 GMT
https://trac.sagemath.org/ticket/10187#comment:67
https://trac.sagemath.org/ticket/10187#comment:67
<p>
There are other flaws in ECL's <code>spkg-install</code>; also, user-specified <code>CFLAGS</code> shouldn't get overridden unless necessary. (<code>-O2</code> is appended rather than prepended.)
</p>
TicketleifFri, 26 Nov 2010 11:25:56 GMT
https://trac.sagemath.org/ticket/10187#comment:68
https://trac.sagemath.org/ticket/10187#comment:68
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:66" title="Comment 66">vbraun</a>:
</p>
<blockquote class="citation">
<p>
What is the correct way to force-disable parallel make, then?
</p>
</blockquote>
<p>
As long as we rely on a GNU <code>make</code>, the correct thing to do is
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">MAKE</span><span class="o">=</span><span class="s2">"$MAKE -j1"</span> <span class="c"># force sequential build (1 job)
</span></pre></div></div><p>
Otherwise we'd have to test if the actual <code>$MAKE</code> understands that.
</p>
<blockquote class="citation">
<p>
Apart from that, do you have any other issue than the unquoted <code>SAGE_LOCAL</code> (which this ticked did not add) for the maxima spkg? I'm happy to fix "minor things", but at the very least you have to list them if you want them fixed.
</p>
</blockquote>
<p>
:) I don't recall. A major clean-up could be done, but I won't insist on having it here.
</p>
<p>
<br />
</p>
<blockquote class="citation">
<p>
I don't think that saving 1 MB is good enough a reason to justify patching ecl's <code>configure</code> and maintaining that patch in future versions. If you want to save space then there are much bigger spkgs that could be shrunk.
</p>
</blockquote>
<p>
Yes, but they accumulate. I'm not sure if upstream would make such a patch.
</p>
<p>
Btw, it's more than 2 MB of the spkg, 13 MB uncompressed.
</p>
<p>
"Maintaining" a real patch is trivial. It will still apply or not, in which case an error message is given. The patch itself is also trivial.
</p>
<blockquote class="citation">
<p>
Or, better yet, if you have the time then fix some real bugs.
</p>
</blockquote>
TicketleifFri, 26 Nov 2010 12:33:16 GMT
https://trac.sagemath.org/ticket/10187#comment:69
https://trac.sagemath.org/ticket/10187#comment:69
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:68" title="Comment 68">leif</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:66" title="Comment 66">vbraun</a>:
</p>
<blockquote class="citation">
<p>
I don't think that saving 1 MB is good enough a reason to justify patching ecl's <code>configure</code> and maintaining that patch in future versions. If you want to save space then there are much bigger spkgs that could be shrunk.
</p>
</blockquote>
<p>
Yes, but they accumulate. I'm not sure if upstream would make such a patch.
</p>
<p>
Btw, it's more than 2 MB of the spkg, 13 MB uncompressed.
</p>
<p>
"Maintaining" a real patch is trivial. It will still apply or not, in which case an error message is given. The patch itself is also trivial.
</p>
</blockquote>
<p>
P.S.: If someone fears <code>patch</code>, a trivial alternative is to simply keep the only file from there <code>configure</code> uses, which is a redundant copy anyway, so one could even create a symbolic link to one of the other instances.
</p>
<div class="wiki-code"><div class="code"><pre>~/Sage/spkgs/ecl-10.4.1<span class="nv">$ </span>find . -name install-sh -exec head -v <span class="o">{}</span> <span class="se">\;</span>
<span class="o">==</span>> ./src/src/gc/install-sh <<span class="o">==</span>
<span class="c">#!/bin/sh
#
# install - install a program, script, or datafile
# This comes from X11R5 (mit/util/scripts/install.sh).
#
# Copyright 1991 by the Massachusetts Institute of Technology
#
# Permission to use, copy, modify, distribute, and sell this software and its
# documentation for any purpose is hereby granted without fee, provided that
# the above copyright notice appear in all copies and that both that
</span><span class="o">==</span>> ./src/src/gc/libatomic_ops-1.2/install-sh <<span class="o">==</span>
<span class="c">#!/bin/sh
# install - install a program, script, or datafile
</span>
<span class="nv">scriptversion</span><span class="o">=</span>2005-05-14.22
<span class="c"># This originates from X11R5 (mit/util/scripts/install.sh), which was
# later released in X11R6 (xc/config/util/install.sh) with the
# following copyright and license.
#
# Copyright (C) 1994 X Consortium
</span><span class="o">==</span>> ./src/src/gmp/install-sh <<span class="o">==</span>
<span class="c">#!/bin/sh
# install - install a program, script, or datafile
</span>
<span class="nv">scriptversion</span><span class="o">=</span>2004-04-01.17
<span class="c"># This originates from X11R5 (mit/util/scripts/install.sh), which was
# later released in X11R6 (xc/config/util/install.sh) with the
# following copyright and license.
#
# Copyright (C) 1994 X Consortium
</span></pre></div></div>
TicketleifFri, 26 Nov 2010 13:06:18 GMT
https://trac.sagemath.org/ticket/10187#comment:70
https://trac.sagemath.org/ticket/10187#comment:70
<p>
With the two new spkgs and all four patches applied, I got:
</p>
<pre class="wiki">sage -t -long -force_lib devel/sage/sage/modular/modform/ambient.py
*** *** Error: TIMED OUT! PROCESS KILLED! *** ***
[1800.1 s]
----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib devel/sage/sage/interfaces/r.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/modular/modform/ambient.py # Time out
----------------------------------------------------------------------
Total time for all tests: 3619.8 seconds
make: *** [ptestlong] Error 192
</pre><p>
(Sage 4.6.1.alpha2 with MPIR 2.1.3.p1 and [GMP-]ECM 6.3.p2, Ubuntu 10.04 x86_64)
</p>
<p>
Rerunning the tests individually, everything passes:
</p>
<div class="wiki-code"><div class="code"><pre>~/Sage/sage-4.6.1.alpha2/devel/sage-10187<span class="nv">$ </span>../../sage -t -long -force_lib sage/interfaces/r.py
sage -t -long -force_lib <span class="s2">"devel/sage-10187/sage/interfaces/r.py"</span>
<span class="o">[</span>23.5 s<span class="o">]</span>
----------------------------------------------------------------------
All tests passed!
Total <span class="nb">time </span><span class="k">for </span>all tests: 23.5 seconds
~/Sage/sage-4.6.1.alpha2/devel/sage-10187<span class="nv">$ </span>../../sage -t -long -force_lib sage/modular/modform/ambient.py
sage -t -long -force_lib <span class="s2">"devel/sage-10187/sage/modular/modform/ambient.py"</span>
<span class="o">[</span>5.5 s<span class="o">]</span>
----------------------------------------------------------------------
All tests passed!
Total <span class="nb">time </span><span class="k">for </span>all tests: 5.5 seconds
</pre></div></div><p>
I've run <code>ptestlong</code> many times on that installation (before testing <a class="closed ticket" href="https://trac.sagemath.org/ticket/10187" title="defect: Update ECL to 10.4.1 and Maxima to 5.22.1 - currently the latest releases. (closed: fixed)">#10187</a>) without any errors... Quite weird.
</p>
TicketjdemeyerFri, 26 Nov 2010 14:11:49 GMT
https://trac.sagemath.org/ticket/10187#comment:71
https://trac.sagemath.org/ticket/10187#comment:71
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:70" title="Comment 70">leif</a>:
</p>
<blockquote class="citation">
<p>
The following tests failed:
</p>
<blockquote>
<p>
sage -t -long -force_lib devel/sage/sage/interfaces/r.py # 1 doctests failed
</p>
</blockquote>
</blockquote>
<p>
This is probably <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/9970" title="defect: Flaky doctest in sage/interfaces/r.py (needs_work)">#9970</a>.
</p>
TicketdrkirkbyFri, 26 Nov 2010 14:19:32 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>10187-remove-encodings-and-solaris-header.patch</em>
</li>
</ul>
<p>
Remove the comment about not removing the 'endcodings' directory, as it should have been remove.d Removed attempt to patch on Solaris, as the patch did not work. This patch is ror review purposes only, as the changes are in ecl-10.4.1.spkg
</p>
TicketdrkirkbyFri, 26 Nov 2010 15:00:04 GMT
https://trac.sagemath.org/ticket/10187#comment:72
https://trac.sagemath.org/ticket/10187#comment:72
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:63" title="Comment 63">leif</a>:
</p>
<blockquote class="citation">
<p>
The Maxima spkg IMHO needs work; not sure if on another ticket. (I guess the authors will say yes; I personally don't like postponing spkg changes very much, since this tends to make them never happen, or leads to concurrent, "incompatible" changes.)
</p>
</blockquote>
<p>
A point that needs to be born in mind is that whilst the Maxima package may not be perfect (I've not looked myself), a failure to update ECL and Maxima will mean Sage will not build on the latest version of Fedora, which is the second most popular linux distro. So I feel there is some argument here for possibly accepting a package that could be improved. (I say this, despite having no involvement whatsoever in updating the Maxima package). But ECL and Maxima need to done together.
</p>
<ul><li>I've removed the src/contrib/encodings/ directory in the ECL package, and corrected comments in SPKG.txt about this.
</li><li>I've removed the <code>cp patches/bytecodes.h src/src/h/bytecodes.h</code> in the ECL package, along iwth the comments attached to why the copy was being made. (Basically the patch suggested by the ECL developer did not work on the latest stable ECL - only on a CVS snapshot).
</li><li>I've updated the ecl-10.4.1.spkg. The changes should be totally harmless - a copy which would never have occured, some changes of comments and the removal of some unused files. The md5 checksum should be <code>7a0d66ee152b847009b23b1dbbfeb75d</code>
</li></ul><blockquote class="citation">
<p>
Such a patch to <code>configure</code> is a very good use case for the newly included GNU <code>patch</code>, since <code>configure</code> is huge while the patch is tiny, so putting a patched copy in <code>patches/</code> would again - now really unnecessarily - increase the size of the resulting spkg.
</p>
</blockquote>
<p>
Agreed, but it would be unwise to start using GNU patch here for several reasons.
</p>
<ul><li>We have not agreed on how its best used (that's the subject of <a class="closed ticket" href="https://trac.sagemath.org/ticket/9419" title="enhancement: Update Developers Guide to state how patches should be made. (closed: fixed)">#9419</a>)
</li><li>Patch is not in any stable release of Sage. It would be unwise to switch to using it extensively just now.
</li><li>Robert Bradshaw stated we should not mix use the use of <code>patch</code> and <code>cp</code> in the same package. I'm not sure if I agree with that or not. I can see his logic, though I can see it could be an error prone process converting all the cp's to patches.
</li></ul><blockquote class="citation">
<p>
I'm not sure if there are other changes from the previous attempt to update ECL not made in the current spkg here.
</p>
</blockquote>
<p>
I'm not aware of any.
</p>
<p>
Dave
</p>
TicketvbraunFri, 26 Nov 2010 15:28:30 GMT
https://trac.sagemath.org/ticket/10187#comment:73
https://trac.sagemath.org/ticket/10187#comment:73
<p>
I've updated the maxima spkg to address the quotes and the MAKE issue. For review purposes see the <code>maxima-5.22.1.patch</code>.
</p>
TicketleifFri, 26 Nov 2010 16:33:50 GMT
https://trac.sagemath.org/ticket/10187#comment:74
https://trac.sagemath.org/ticket/10187#comment:74
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:72" title="Comment 72">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:63" title="Comment 63">leif</a>:
</p>
<blockquote class="citation">
<p>
The Maxima spkg IMHO needs work; not sure if on another ticket. (I guess the authors will say yes; I personally don't like postponing spkg changes very much, since this tends to make them never happen, or leads to concurrent, "incompatible" changes.)
</p>
</blockquote>
<p>
A point that needs to be born in mind is that whilst the Maxima package may not be perfect (I've not looked myself), a failure to update ECL and Maxima will mean Sage will not build on the latest version of Fedora, which is the second most popular linux distro. So I feel there is some argument here for possibly accepting a package that could be improved. (I say this, despite having no involvement whatsoever in updating the Maxima package). But ECL and Maxima need to done together.
</p>
</blockquote>
<p>
If there's a chance of getting it into 4.6.1 (and the authors are willing to open follow-up tickets ;-) ), yes.
I'm not the release manager, but other spkg updates / changes have been postponed to Sage 4.6.2. Clearly Maxima is also a "central" package in Sage, so any upgrade carries the risk to break potentially a lot, or at least more than other spkgs hardly used within Sage.
</p>
<p>
<br />
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I'm not sure if there are other changes from the previous attempt to update ECL not made in the current spkg here.
</p>
</blockquote>
</blockquote>
<blockquote class="citation">
<p>
I'm not aware of any.
</p>
</blockquote>
<p>
Certainly not... :D
</p>
<p>
(Otherwise I would have expected you to incorporate them if necessary. But I see your ECL package is "fresh"; I first thought you just took some "old" one since there were not many comments on it on the ticket, and no patch or diff attached.)
</p>
TicketleifFri, 26 Nov 2010 16:41:19 GMT
https://trac.sagemath.org/ticket/10187#comment:75
https://trac.sagemath.org/ticket/10187#comment:75
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:73" title="Comment 73">vbraun</a>:
</p>
<blockquote class="citation">
<p>
I've updated the maxima spkg to address the quotes and the MAKE issue. For review purposes see the <code>maxima-5.22.1.patch</code>.
</p>
</blockquote>
<p>
Well, if you redefine <code>MAKE</code> rather than unsetting it, you should also use it... (i.e. call <code>$MAKE</code> instead of <code>make</code>).
</p>
TicketleifFri, 26 Nov 2010 16:51:47 GMT
https://trac.sagemath.org/ticket/10187#comment:76
https://trac.sagemath.org/ticket/10187#comment:76
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:75" title="Comment 75">leif</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:73" title="Comment 73">vbraun</a>:
</p>
<blockquote class="citation">
<p>
I've updated the maxima spkg to address the quotes and the MAKE issue. For review purposes see the <code>maxima-5.22.1.patch</code>.
</p>
</blockquote>
<p>
Well, if you redefine <code>MAKE</code> rather than unsetting it, you should also use it... (i.e. call <code>$MAKE</code> instead of <code>make</code>).
</p>
</blockquote>
<p>
Of course you could also just do
</p>
<div class="wiki-code"><div xmlns="http://www.w3.org/1999/xhtml" class="diff">
<ul class="entries">
<li class="entry">
<h2>
<a>spkg-install</a>
</h2>
<pre>diff --git a/spkg-install b/spkg-install</pre>
<table class="trac-diff inline" summary="Differences" cellspacing="0">
<colgroup><col class="lineno" /><col class="lineno" /><col class="content" /></colgroup>
<thead>
<tr>
<th title="File a/spkg-install">
a
</th>
<th title="File b/spkg-install">
b
</th>
<td><em></em> </td>
</tr>
</thead>
<tbody class="unmod">
<tr>
<th>14</th><th>14</th><td class="l"><span></span></td>
</tr><tr>
<th>15</th><th>15</th><td class="l"><span>cd src/</span></td>
</tr><tr>
<th>16</th><th>16</th><td class="l"><span></span></td>
</tr>
</tbody><tbody class="rem">
<tr class="first">
<th>17</th><th> </th><td class="l"><del>unset MAKE # this can break things</del></td>
</tr><tr class="last">
<th>18</th><th> </th><td class="l"><del></del></td>
</tr>
</tbody><tbody class="unmod">
<tr>
<th>19</th><th>17</th><td class="l"><span>check_error() {</span></td>
</tr><tr>
<th>20</th><th>18</th><td class="l"><span> if [ $? -ne 0 ]; then</span></td>
</tr><tr>
<th>21</th><th>19</th><td class="l"><span> echo "***********************************************************"</span></td>
</tr>
</tbody>
<tbody class="skipped">
<tr>
<th><a href="#L35">…</a></th>
<th><a href="#L33">…</a></th>
<td><em></em> </td>
</tr>
</tbody>
<tbody class="unmod">
<tr>
<th>35</th><th>33</th><td class="l"><span> echo "you will not be able to see the output of the build"</span></td>
</tr><tr>
<th>36</th><th>34</th><td class="l"><span> echo "as it occurs. Don't worry, the build process did"</span></td>
</tr><tr>
<th>37</th><th>35</th><td class="l"><span> echo "not hang."</span></td>
</tr>
</tbody><tbody class="mod">
<tr class="first">
<th>38</th><th> </th><td class="l"><span> <del>make</del> >> "$CUR"/output.log 2>> "$CUR"/error.log</span></td>
</tr>
<tr class="last">
<th> </th><th>36</th><td class="r"><span> <ins>$MAKE -j1</ins> >> "$CUR"/output.log 2>> "$CUR"/error.log</span></td>
</tr>
</tbody><tbody class="unmod">
<tr>
<th>39</th><th>37</th><td class="l"><span>else</span></td>
</tr>
</tbody><tbody class="mod">
<tr class="first">
<th>40</th><th> </th><td class="l"><span> <del>make</del></span></td>
</tr>
<tr class="last">
<th> </th><th>38</th><td class="r"><span> <ins>$MAKE -j1</ins></span></td>
</tr>
</tbody><tbody class="unmod">
<tr>
<th>41</th><th>39</th><td class="l"><span>fi</span></td>
</tr><tr>
<th>42</th><th>40</th><td class="l"><span>check_error "Failed to make Maxima." </span></td>
</tr><tr>
<th>43</th><th>41</th><td class="l"><span></span></td>
</tr>
</tbody><tbody class="mod">
<tr class="first">
<th>44</th><th> </th><td class="l"><span><del>make</del> install</span></td>
</tr>
<tr class="last">
<th> </th><th>42</th><td class="r"><span><ins>$MAKE -j1</ins> install</span></td>
</tr>
</tbody><tbody class="unmod">
<tr>
<th>45</th><th>43</th><td class="l"><span>check_error "Failed to install Maxima."</span></td>
</tr><tr>
<th>46</th><th>44</th><td class="l"><span></span></td>
</tr><tr>
<th>47</th><th>45</th><td class="l"><span>echo "creating wrapper script with disabled readline"</span></td>
</tr>
</tbody>
</table>
</li>
</ul>
</div></div><p>
P.S.: Did anybody recently test where and if parallel Maxima builds or installs fail? Building it sequentially takes a fair amount of time...
</p>
TicketvbraunFri, 26 Nov 2010 16:56:45 GMT
https://trac.sagemath.org/ticket/10187#comment:77
https://trac.sagemath.org/ticket/10187#comment:77
<p>
Fixed the <code>make->$MAKE</code>, too. Too much jet lag ;-)
</p>
<p>
I haven't tried if parallel build suddenly works. But then, even if it were to compile in parallel on my machine, what do we learn?
</p>
TicketleifFri, 26 Nov 2010 17:17:21 GMT
https://trac.sagemath.org/ticket/10187#comment:78
https://trac.sagemath.org/ticket/10187#comment:78
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:77" title="Comment 77">vbraun</a>:
</p>
<blockquote class="citation">
<p>
I haven't tried if parallel build suddenly works. But then, even if it were to compile in parallel on my machine, what do we learn?
</p>
</blockquote>
<p>
Need not be suddenly.
</p>
<p>
If e.g. just <code>make install</code> fails with multiple jobs, we could just do <code>$MAKE -j1 install</code>.
</p>
<p>
Also, failures might be limited to the OS (e.g. MacOS X), in which case we shouldn't disable parallel builds on all platforms.
</p>
<p>
If parallel builds or installs just non-deterministically fail in, say, 5-10%, it would IMHO be acceptable to enable them though, since on a failure one simply has to rerun <code>make</code> or <code>./sage -i ...</code>.
</p>
TicketleifFri, 26 Nov 2010 17:41:56 GMT
https://trac.sagemath.org/ticket/10187#comment:79
https://trac.sagemath.org/ticket/10187#comment:79
<p>
Looks as if enabling parallel make (in Maxima) doesn't make any difference, so rather a non-issue.
</p>
TicketdrkirkbyFri, 26 Nov 2010 19:21:04 GMT
https://trac.sagemath.org/ticket/10187#comment:80
https://trac.sagemath.org/ticket/10187#comment:80
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:79" title="Comment 79">leif</a>:
</p>
<blockquote class="citation">
<p>
Looks as if enabling parallel make (in Maxima) doesn't make any difference, so rather a non-issue.
</p>
</blockquote>
<p>
I can't do it now, but later I will try my old trick of building it 1000 times, inserting random delays before invoking gcc. I don't think a few]build in parallel proves very much.
</p>
<p>
It took:
</p>
<pre class="wiki">real 9m0.386s
user 5m4.518s
sys 0m43.198s
Successfully installed maxima-5.22.1
</pre><p>
so I guess it would take about 6 minutes to build serially. So we will see see how long it takes to build in parallel and so how practical it is to test it 100 times or 1000 times.
</p>
<p>
Dave
</p>
<p>
Dave
</p>
<p>
Dave
</p>
TicketdrkirkbyFri, 26 Nov 2010 23:18:17 GMTstatus, description changed
https://trac.sagemath.org/ticket/10187#comment:81
https://trac.sagemath.org/ticket/10187#comment:81
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/10187?action=diff&version=81">diff</a>)
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:78" title="Comment 78">leif</a>:
</p>
<blockquote class="citation">
<p>
If parallel builds or installs just non-deterministically fail in, say, 5-10%, it would IMHO be acceptable to enable them though, since on a failure one simply has to rerun <code>make</code> or <code>./sage -i ...</code>.
</p>
</blockquote>
<p>
I personally think it would be unwise to enable parallel builds unless we are confident they work reliably on every platform. It's conceivable a file may not be written fully, yet processed in some way, leading to undefined behavior.
</p>
<p>
I've asked on the Maxima mailing list if parallel builds are OK or not. So far there is no reply.
</p>
<p>
I've started a build of Maxima, inserting a random delay between 0 and 1 second before invoking gcc. The problem is, Maxima is now taking 11 and a half minutes to build on my machine.
</p>
<pre class="wiki">real 11m33.576s
user 3m22.703s
sys 0m29.970s
</pre><p>
as obviously delaying gcc on average by 500 ms slows down the build. So far it has only built twice, but both times it was OK.
</p>
<p>
I'll build a few more copies of Sage, then test Maxima on them too, since testing this even 100 times is going to take 19 hours.
</p>
<p>
I've put to needs info, since I think we need to verify if parallel builds are ok or not.
</p>
<p>
A new package, with parallel builds enabled, can be found at
</p>
<p>
<a class="ext-link" href="http://boxen.math.washington.edu/home/kirkby/patches/maxima-5.22.1.spkg"><span class="icon"></span>http://boxen.math.washington.edu/home/kirkby/patches/maxima-5.22.1.spkg</a>
</p>
<p>
Dave
</p>
TicketdrkirkbyFri, 26 Nov 2010 23:58:35 GMTstatus, description changed
https://trac.sagemath.org/ticket/10187#comment:82
https://trac.sagemath.org/ticket/10187#comment:82
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/10187?action=diff&version=82">diff</a>)
</li>
</ul>
<p>
I tried to build Maxima in parallel a number of times. It failed once with the following, so I think it is unwise to attempt a parallel build.
</p>
<p>
This was without any random delays before invoking gcc, but on a heavily loaded system.
</p>
<p>
We should use <a class="ext-link" href="http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg"><span class="icon"></span>http://www.stp.dias.ie/~vbraun/Sage/spkg/maxima-5.22.1.spkg</a> and <strong>not</strong> my parallel version.
</p>
<pre class="wiki">/usr/bin/ginstall -c -m 644 maxima-index.lisp "/export/home/drkirkby/1/sage-4.6.1.alpha2/local/info/maxima-index.lisp"
mkdir: /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html: [File exists]
make[6]: *** [install-maxima-html] Error 1
make[6]: *** Waiting for unfinished jobs....
/usr/bin/ginstall -c -m 644 ./figures/contour1.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/contour1.gif
/usr/bin/ginstall -c -m 644 ./figures/contour2.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/contour2.gif
/usr/bin/ginstall -c -m 644 ./figures/contour3.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/contour3.gif
/usr/bin/ginstall -c -m 644 ./figures/dynamics1.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics1.gif
/usr/bin/ginstall -c -m 644 './maxima.info' '/export/home/drkirkby/1/sage-4.6.1.alpha2/local/info/maxima.info'
/usr/bin/ginstall -c -m 644 './maxima.info-1' '/export/home/drkirkby/1/sage-4.6.1.alpha2/local/info/maxima.info-1'
/usr/bin/ginstall -c -m 644 ./figures/dynamics2.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics2.gif
/usr/bin/ginstall -c -m 644 './maxima.info-2' '/export/home/drkirkby/1/sage-4.6.1.alpha2/local/info/maxima.info-2'
/usr/bin/ginstall -c -m 644 ./figures/dynamics3.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics3.gif
/usr/bin/ginstall -c -m 644 ./figures/dynamics4.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics4.gif
/usr/bin/ginstall -c -m 644 ./figures/dynamics5.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics5.gif
/usr/bin/ginstall -c -m 644 ./figures/dynamics6.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics6.gif
/usr/bin/ginstall -c -m 644 './maxima.info-3' '/export/home/drkirkby/1/sage-4.6.1.alpha2/local/info/maxima.info-3'
/usr/bin/ginstall -c -m 644 ./figures/dynamics7.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics7.gif
/usr/bin/ginstall -c -m 644 ./figures/dynamics8.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics8.gif
install-info --info-dir='/export/home/drkirkby/1/sage-4.6.1.alpha2/local/info' '/export/home/drkirkby/1/sage-4.6.1.alpha2/local/info/maxima.info'
/usr/bin/ginstall -c -m 644 ./figures/dynamics9.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics9.gif
/usr/bin/ginstall -c -m 644 ./figures/dynamics10.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/dynamics10.gif
/usr/bin/ginstall -c -m 644 ./figures/implicit_plot.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/implicit_plot.gif
/usr/bin/ginstall -c -m 644 ./figures/plotdf1.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotdf1.gif
/usr/bin/ginstall -c -m 644 ./figures/plotdf2.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotdf2.gif
/usr/bin/ginstall -c -m 644 ./figures/plotdf3.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotdf3.gif
/usr/bin/ginstall -c -m 644 ./figures/plotdf4.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotdf4.gif
/usr/bin/ginstall -c -m 644 ./figures/plotdf5.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotdf5.gif
/usr/bin/ginstall -c -m 644 ./figures/plotdf6.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotdf6.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting1.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting1.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting2.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting2.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting3.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting3.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting4.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting4.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting5.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting5.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting6.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting6.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting7.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting7.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting8.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting8.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting9.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting9.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting10.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting10.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting11.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting11.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting12.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting12.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting13.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting13.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting14.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting14.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting15.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting15.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting16.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting16.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting17.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting17.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting18.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting18.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting19.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting19.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting20.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting20.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting21.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting21.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting22.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting22.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting23.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting23.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting24.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting24.gif
/usr/bin/ginstall -c -m 644 ./figures/plotting25.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/plotting25.gif
/usr/bin/ginstall -c -m 644 ./figures/orthopoly1.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/orthopoly1.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs01.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs01.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs02.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs02.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs03.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs03.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs04.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs04.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs05.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs05.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs06.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs06.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs07.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs07.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs08.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs08.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs09.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs09.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs10.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs10.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs11.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs11.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs12.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs12.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs13.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs13.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs14.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs14.gif
/usr/bin/ginstall -c -m 644 ./figures/graphs15.gif /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/figures/graphs15.gif
/usr/bin/ginstall -c -m 644 ./contents.hhc /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/contents.hhc
/usr/bin/ginstall -c -m 644 ./index.hhk /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/index.hhk
/usr/bin/ginstall -c -m 644 ./header.hhp /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/header.hhp
/usr/bin/ginstall -c -m 644 ./maxima.hhp /export/home/drkirkby/1/sage-4.6.1.alpha2/local/share/maxima/5.22.1/doc/html/maxima.hhp
make[6]: Leaving directory `/export/home/drkirkby/1/sage-4.6.1.alpha2/spkg/build/maxima-5.22.1/src/doc/info'
make[5]: *** [install-am] Error 2
make[5]: Leaving directory `/export/home/drkirkby/1/sage-4.6.1.alpha2/spkg/build/maxima-5.22.1/src/doc/info'
make[4]: *** [install-recursive] Error 1
make[4]: Leaving directory `/export/home/drkirkby/1/sage-4.6.1.alpha2/spkg/build/maxima-5.22.1/src/doc/info'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/export/home/drkirkby/1/sage-4.6.1.alpha2/spkg/build/maxima-5.22.1/src/doc'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/export/home/drkirkby/1/sage-4.6.1.alpha2/spkg/build/maxima-5.22.1/src'
***********************************************************
Failed to install Maxima.
***********************************************************
real 11m2.520s
user 5m0.763s
sys 0m33.530s
sage: An error occurred while installing maxima-5.22.1
</pre>
TicketdrkirkbySat, 27 Nov 2010 00:28:14 GMT
https://trac.sagemath.org/ticket/10187#comment:83
https://trac.sagemath.org/ticket/10187#comment:83
<p>
As seen above, the parallel build appeared to work, but the install failed. But I think we should leave this. I've reported the failure on the Maxima list.
</p>
<p>
I don't feel able to review the maxima package, and obviously can't the ECL one, as I wrote most of it.
</p>
<p>
But I'm fairly convinced these two packages are working ok together myself, based on the buildbot results.
</p>
<p>
Dave
</p>
TicketdrkirkbySat, 27 Nov 2010 00:36:17 GMT
https://trac.sagemath.org/ticket/10187#comment:84
https://trac.sagemath.org/ticket/10187#comment:84
<p>
This was posted on the Maxima list by Rupert Swarbrick, who is a Maxima developer.
</p>
<hr />
<p>
<em>
Sorry, I think I was not clear. What I meant was that most of the time
compiling maxima is spent compiling code written in lisp. This code is
compiled in order using a "Makefile-like" process called asdf (or
mk:defsystem, depending on which you prefer) and this is a serial
process.</em>
</p>
<p>
<em>There are projects like XCVB that have tried to do this in parallel for
building large lisp images, but it's not clear how much success they've
had.</em>
</p>
<p>
<em>Rupert</em>
</p>
<hr />
<p>
So it looks like we wont gain much trying to build in parallel and as I've shown, at least installing in parallel is unsafe.
</p>
<p>
Dave
</p>
TicketdrkirkbySun, 28 Nov 2010 15:14:50 GMT
https://trac.sagemath.org/ticket/10187#comment:85
https://trac.sagemath.org/ticket/10187#comment:85
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:57" title="Comment 57">jpflori</a>:
</p>
<blockquote class="citation">
<p>
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.
</p>
</blockquote>
<p>
On a Blade 1500, you will need to increase the values of the timeouts. I would suggest suitable values would be :
</p>
<pre class="wiki">SAGE_TIMEOUT=600
SAGE_TIMEOUT_LONG=3000
</pre><p>
I suspect the SAGE_TIMEOUT_LONG could actually be 2000 seconds, but I'd go for 6000 to be really safe.
</p>
<p>
I use:
</p>
<pre class="wiki">SAGE_TIMEOUT=1000
SAGE_TIMEOUT_LONG=10000
</pre><p>
on a dual processor 900 MHz Blade 1000. I think however the SAGE_TIMEOUT_LONG, which defaults to 1800 s, is probably not too far from ok, so I reckon 2000 s would be fine.
</p>
<p>
The default SAGE_TIMEOUT of 300 s will certainly be too short.
</p>
<p>
Dave
</p>
TicketdrkirkbySun, 28 Nov 2010 15:18:13 GMT
https://trac.sagemath.org/ticket/10187#comment:86
https://trac.sagemath.org/ticket/10187#comment:86
<p>
What do we need for a positive review of this?
</p>
TicketjpfloriMon, 29 Nov 2010 10:47:17 GMT
https://trac.sagemath.org/ticket/10187#comment:87
https://trac.sagemath.org/ticket/10187#comment:87
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:85" title="Comment 85">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
On a Blade 1500, you will need to increase the values of the timeouts. I would suggest suitable values would be : <code> SAGE_TIMEOUT=600 SAGE_TIMEOUT_LONG=3000 </code> I suspect the SAGE_TIMEOUT_LONG could actually be 2000 seconds, but I'd go for 6000 to be really safe. I use: <code> SAGE_TIMEOUT=1000 SAGE_TIMEOUT_LONG=10000 </code> on a dual processor 900 MHz Blade 1000. I think however the SAGE_TIMEOUT_LONG, which defaults to 1800 s, is probably not too far from ok, so I reckon 2000 s would be fine. The default SAGE_TIMEOUT of 300 s will certainly be too short. Dave
</p>
</blockquote>
<p>
I did increase the timeout, to 20000 if I remember correctly.
</p>
<p>
However when I came back Sage had gotten out of memory (and the computer had to be restarted).
</p>
<p>
It could be because of the way I installed Sage (downloaded binary 4.5.1 package, updated the spkgs and could have used an old gcc at some point because the default one on the system is 3.4.something even if 4.something is available).
</p>
<p>
I should build everything from scratch but do not have the time right now.
</p>
TicketdrkirkbyMon, 29 Nov 2010 12:33:07 GMT
https://trac.sagemath.org/ticket/10187#comment:88
https://trac.sagemath.org/ticket/10187#comment:88
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:87" title="Comment 87">jpflori</a>:
</p>
<blockquote class="citation">
<p>
I did increase the timeout, to 20000 if I remember correctly.
</p>
</blockquote>
<p>
That is more than enough. Remember there are two timeout values. I think if you set just SAGE_TIMEOUT to 20000 seconds, but leave SAGE_TIMEOUT_LONG at the default 1800 seconds, then the long tests will just use 1800 seconds.
</p>
<blockquote class="citation">
<p>
However when I came back Sage had gotten out of memory (and the computer had to be restarted).
</p>
</blockquote>
<p>
I can build Sage and doctest it on a Sun Blade 1000 which has only 2 GB RAM.
</p>
<blockquote class="citation">
<p>
It could be because of the way I installed Sage (downloaded binary 4.5.1 package, updated the spkgs and could have used an old gcc at some point because the default one on the system is 3.4.something even if 4.something is available).
</p>
</blockquote>
<p>
That indeed would screw it up. We should run the 'prereq' script every time we run 'make' as that will stop some instances of people mess up, but I think installing individual packages with <code>sage -f foobar</code>, will be difficult to detect problems like a wrong gcc.
</p>
<blockquote class="citation">
<p>
I should build everything from scratch but do not have the time right now.
</p>
</blockquote>
<p>
It will take a long time on a blade 1500, so I suggest you start it asap.
</p>
<p>
Dave
</p>
TicketleifMon, 29 Nov 2010 13:44:20 GMT
https://trac.sagemath.org/ticket/10187#comment:89
https://trac.sagemath.org/ticket/10187#comment:89
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:84" title="Comment 84">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
This was posted on the Maxima list by Rupert Swarbrick, who is a Maxima developer.
</p>
<hr />
<p>
<em>
Sorry, I think I was not clear. What I meant was that most of the time
compiling maxima is spent compiling code written in lisp. This code is
compiled in order using a "Makefile-like" process called asdf (or
mk:defsystem, depending on which you prefer) and this is a serial
process.</em>
</p>
<p>
<em>There are projects like XCVB that have tried to do this in parallel for
building large lisp images, but it's not clear how much success they've
had.</em>
</p>
<p>
<em>Rupert</em>
</p>
<hr />
<p>
So it looks like we wont gain much trying to build in parallel
</p>
</blockquote>
<p>
... as I said a few comments <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/10187#comment:79"><span class="icon"></span>above</a>.
</p>
<blockquote class="citation">
<p>
and as I've shown, at least installing in parallel is unsafe.
</p>
</blockquote>
<p>
(If <em>building</em> Maxima in parallel would make [more] sense, we could still disable just parallel <em>installation</em>.)
</p>
TicketleifMon, 29 Nov 2010 14:04:14 GMT
https://trac.sagemath.org/ticket/10187#comment:90
https://trac.sagemath.org/ticket/10187#comment:90
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:88" title="Comment 88">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:87" title="Comment 87">jpflori</a>:
</p>
<blockquote class="citation">
<p>
I did increase the timeout, to 20000 if I remember correctly.
</p>
</blockquote>
<p>
That is more than enough. Remember there are two timeout values. I think if you set just SAGE_TIMEOUT to 20000 seconds, but leave SAGE_TIMEOUT_LONG at the default 1800 seconds, then the long tests will just use 1800 seconds.
</p>
</blockquote>
<p>
Unless someone has changed this recently, if you run some doctest(s) with <code>-long</code>, <strong>only</strong> <code>SAGE_TIMEOUT_LONG</code> will be used, regardless if the file(s) contain(s) doctests marked "<code>long</code>".
</p>
<p>
(And the timeout applies to the whole file being doctested, not individual doctests in it.)
</p>
<p>
If you run out of memory (i.e., the machine starts to swap), increasing the timeout doesn't help much; it's better to then reduce the number of doctests run in parallel ("<code>NUM_THREADS</code>" in the Makefile).
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
However when I came back Sage had gotten out of memory (and the computer had to be restarted).
</p>
</blockquote>
<p>
I can build Sage and doctest it on a Sun Blade 1000 which has only 2 GB RAM.
</p>
</blockquote>
TicketdrkirkbyTue, 30 Nov 2010 15:27:49 GMT
https://trac.sagemath.org/ticket/10187#comment:91
https://trac.sagemath.org/ticket/10187#comment:91
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:89" title="Comment 89">leif</a>:
</p>
<blockquote class="citation">
<p>
(If <em>building</em> Maxima in parallel would make [more] sense, we could still disable just parallel <em>installation</em>.)
</p>
</blockquote>
<p>
Yes, but for various reasons, there's no point.
</p>
<p>
Dave
</p>
TicketdrkirkbyTue, 30 Nov 2010 15:39:07 GMT
https://trac.sagemath.org/ticket/10187#comment:92
https://trac.sagemath.org/ticket/10187#comment:92
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:90" title="Comment 90">leif</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:88" title="Comment 88">drkirkby</a>:
</p>
</blockquote>
<blockquote class="citation">
<blockquote class="citation">
<p>
That is more than enough. Remember there are two timeout values. I think if you set just SAGE_TIMEOUT to 20000 seconds, but leave SAGE_TIMEOUT_LONG at the default 1800 seconds, then the long tests will just use 1800 seconds.
</p>
</blockquote>
<p>
Unless someone has changed this recently, if you run some doctest(s) with <code>-long</code>, <strong>only</strong> <code>SAGE_TIMEOUT_LONG</code> will be used, regardless if the file(s) contain(s) doctests marked "<code>long</code>".
</p>
</blockquote>
<p>
I was not aware of that.
</p>
<blockquote class="citation">
<p>
(And the timeout applies to the whole file being doctested, not individual doctests in it.)
</p>
</blockquote>
<blockquote class="citation">
<p>
If you run out of memory (i.e., the machine starts to swap), increasing the timeout doesn't help much; it's better to then reduce the number of doctests run in parallel ("<code>NUM_THREADS</code>" in the Makefile).
</p>
</blockquote>
<p>
</p>
<blockquote class="citation">
<blockquote class="citation">
<blockquote class="citation">
<p>
However when I came back Sage had gotten out of memory (and the computer had to be restarted).
</p>
</blockquote>
</blockquote>
</blockquote>
<p>
I know there are exceptions, but normally one can kill the process that's taking all the ram. If ulimit was set, this should not happen.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I can build Sage and doctest it on a Sun Blade 1000 which has only 2 GB RAM.
</p>
</blockquote>
</blockquote>
<p>
FWIW, that's running Solaris 10 03/2005, so is an almost 6 year old version of Solaris.
</p>
<p>
A later version of Solaris, if configured to use the 128-bit ZFS file system, then I doubt 2 GB would be sufficient. One could always use the old UFS file system, but ZFS has lots of advantages, but it tends to need more memory.
</p>
<p>
Dave
</p>
TicketleifTue, 30 Nov 2010 16:13:52 GMT
https://trac.sagemath.org/ticket/10187#comment:93
https://trac.sagemath.org/ticket/10187#comment:93
<p>
Don't know if I mentioned this earlier, but in the ECL spkg user-specified <code>CFLAGS</code> (and <code>CXXFLAGS</code>) still get overridden even if <code>SAGE_DEBUG</code> is <strong>not</strong> "yes".
</p>
<p>
Are <code>CXX</code> and <code>CXXFLAGS</code> used by ECL at all? I don't think so.
</p>
TicketkcrismanTue, 30 Nov 2010 18:28:56 GMTreviewer changed
https://trac.sagemath.org/ticket/10187#comment:94
https://trac.sagemath.org/ticket/10187#comment:94
<ul>
<li><strong>reviewer</strong>
changed from <em>Karl-Dieter Crisman</em> to <em>Karl-Dieter Crisman, David Kirkby, Volker Braun</em>
</li>
</ul>
<p>
Okay, I was able (finally) to rebuild everything on OS X 10.4 PPC and now have no problems.
</p>
<pre class="wiki">sage: time integrate(x^3,x)
CPU times: user 0.13 s, sys: 0.13 s, total: 0.26 s
Wall time: 14.62 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.17 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.19 s
1/4*x^4
</pre><p>
As to review and Volker's comments on sage-devel, note that sometimes the people who can review the functioning of the patch/spkg are not the same as those who can review the actual changed code. That is probably a big piece of the problem.
</p>
<p>
Anyway, I cannot review the lisp-ish changes and whether they are needed, though I can look at the rest and of course verify that things seem to work.
</p>
<p>
However, you and David could review each others' spkgs in computer terms; I think that might be okay, n'est pas?
</p>
TicketkcrismanTue, 30 Nov 2010 20:03:37 GMTreviewer changed
https://trac.sagemath.org/ticket/10187#comment:95
https://trac.sagemath.org/ticket/10187#comment:95
<ul>
<li><strong>reviewer</strong>
changed from <em>Karl-Dieter Crisman, David Kirkby, Volker Braun</em> to <em>Karl-Dieter Crisman, David Kirkby, Volker Braun, Leif Leonhardy</em>
</li>
</ul>
TicketdrkirkbyTue, 30 Nov 2010 21:31:01 GMT
https://trac.sagemath.org/ticket/10187#comment:96
https://trac.sagemath.org/ticket/10187#comment:96
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:93" title="Comment 93">leif</a>:
</p>
<blockquote class="citation">
<p>
Don't know if I mentioned this earlier, but in the ECL spkg user-specified <code>CFLAGS</code> (and <code>CXXFLAGS</code>) still get overridden even if <code>SAGE_DEBUG</code> is <strong>not</strong> "yes".
</p>
<p>
Are <code>CXX</code> and <code>CXXFLAGS</code> used by ECL at all? I don't think so.
</p>
</blockquote>
<p>
CXX is definitely used. I just tried to specify CXX=/path/to/Sun/C++-compiler
</p>
<p>
and it used the Sun compiler.
</p>
<p>
I must admit, I'm not so convinced it is honoring CXXFLAGS, but it would be unwise to not set them. That's really an ECL bug if it ignore the flags.
</p>
<p>
Dave
</p>
TicketleifTue, 30 Nov 2010 21:58:03 GMT
https://trac.sagemath.org/ticket/10187#comment:97
https://trac.sagemath.org/ticket/10187#comment:97
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:96" title="Comment 96">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:93" title="Comment 93">leif</a>:
</p>
<blockquote class="citation">
<p>
Don't know if I mentioned this earlier, but in the ECL spkg user-specified <code>CFLAGS</code> (and <code>CXXFLAGS</code>) still get overridden even if <code>SAGE_DEBUG</code> is <strong>not</strong> "yes".
</p>
</blockquote>
</blockquote>
<p>
So did you fix that?
</p>
<p>
<br />
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Are <code>CXX</code> and <code>CXXFLAGS</code> used by ECL at all? I don't think so.
</p>
</blockquote>
<p>
CXX is definitely used. I just tried to specify CXX=/path/to/Sun/C++-compiler
</p>
<p>
and it used the Sun compiler.
</p>
</blockquote>
<p>
:-) What for?
</p>
<blockquote class="citation">
<p>
I must admit, I'm not so convinced it is honoring CXXFLAGS, but it would be unwise to not set them. That's really an ECL bug if it ignore the flags.
</p>
</blockquote>
<p>
(At least I couldn't find <code>CXXFLAGS</code> being used in the build logs.)
</p>
TicketleifTue, 30 Nov 2010 22:20:45 GMT
https://trac.sagemath.org/ticket/10187#comment:98
https://trac.sagemath.org/ticket/10187#comment:98
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:97" title="Comment 97">leif</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:96" title="Comment 96">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:93" title="Comment 93">leif</a>:
</p>
<blockquote class="citation">
<p>
Are <code>CXX</code> and <code>CXXFLAGS</code> used by ECL at all? I don't think so.
</p>
</blockquote>
<p>
CXX is definitely used. I just tried to specify CXX=/path/to/Sun/C++-compiler
</p>
<p>
and it used the Sun compiler.
</p>
</blockquote>
<p>
:-) What for?
</p>
</blockquote>
<p>
I just successfully installed ECL (and afterwards Maxima) with <code>env CXX=/some/nonexistent/cxx ./sage -f ...</code>.
</p>
<p>
<code>configure</code> tests <code>CXX</code>, but it'll only be used if you also build the included GMP, with C++ support, I guess.
</p>
TicketdrkirkbyTue, 30 Nov 2010 23:11:38 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:99
https://trac.sagemath.org/ticket/10187#comment:99
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Some comments, having spent some time looking at the code others have written.
</p>
<h3 id="MyECLpackage">My ECL package</h3>
<ul><li>I don't see anything wrong with the way CXXFLAGS/CFLAGS is handled in the ECL package. It looks OK to me. It might not be 100% necessary, but in general we should set these flags and hope the package follows this.
</li></ul><hr />
<h3 id="Lookingatthedoctests:">Looking at the doc tests:</h3>
<ul><li><strong>trac_10187_general_display_prefix_workaround.patch</strong> looks OK to me. So I'll positively review that part.
</li><li><strong>trac_10187_mark_some_doctests_random_until_9880_gets_merged.patch</strong> looks OK to me, So I'll positively review that part.
</li><li> <strong>maxima-5.22.1.patch</strong> SPKG.txt looks OK, but you will need to find someone that know more about Lisp than me to tell you if that's correct. Ask on sage-devel to get someone who understands it, since I don't.
</li><li><strong>trac_10187_fix_easy_doctests.patch</strong>
</li></ul><p>
1) There are these numerical results. Has anyone independently verified this are correct?
</p>
<pre class="wiki">[2.6789385347..., -8.3905259853..., 26.662447494..., -80.683148377...]
</pre><p>
On what basis was the number of significant digits selected?
</p>
<p>
As a matter of interest, do we know if anyone every verify the original horrid looking symbolic integral is correct?
</p>
<p>
I have a dislike for tests where is appears we don't verify the result is correct, but assume it must be. Please justify why those results are correct. That should be in a comment in the code, not displayed.
</p>
<p>
2) Why was the doctest:
</p>
<pre class="wiki">integral(abs(x), x, 0, a)
</pre><p>
changed to:
</p>
<pre class="wiki">integral(abs(x)*x, x, 0, a)
</pre><p>
It rather strikes me that we should show the example of how to do this calculation in the way Maxima now wants, rather than to simply change the integral to one which gives a simpler answer.
</p>
<p>
It so happens that Mathematica 7.0.1 can do the first inegral:
</p>
<pre class="wiki">In[7]:= Integrate[Abs[x],{x,0,a}]
a Abs[a]
Out[7]= --------
2
</pre><p>
I think it would be better to show the original integral, show the failure. We could even point out how to do the integral in Maxima, and get the hopefully correct result.
Is rather strikes me that inputting something that was quite reasonable looking does not work. So we should explain why that reasonable thing is wrong, rather than just pick another example.
</p>
<p>
The Mathematica documentation often shows a section marked <strong>Possible issues</strong> and would explain problems one might get. Here it seems we should do this, rather than just pick another integral.
</p>
<p>
<strong>sage/plot/plot3d/transform.pyx</strong> Do we know if that horrible looking result is correct? I see it is a simple change from the previous horrible looking result, but how do we know if the previous one is correct? If, as I suspect, this has not been verified by hand or with another package, then we should write that fact.
</p>
<h2 id="Summary">Summary</h2>
<ul><li>The portability issues appears to have been resolved.
</li><li>Someone needs to check my ECL package
</li><li><strong>trac_10187_general_display_prefix_workaround.patch</strong> is OK
</li><li><strong>trac_10187_mark_some_doctests_random_until_9880_gets_merged.patch</strong> is OK
</li><li><strong>trac_10187_fix_easy_doctests.patch</strong> Needs explanation.
</li><li><strong>maxima-5.22.1.patch</strong> Needs someone to review with a skill set different to me.
</li></ul><p>
I'm changing to needs work, as some of these tests changes needs explanation.
</p>
<p>
Dave
</p>
TicketleifWed, 01 Dec 2010 00:07:28 GMT
https://trac.sagemath.org/ticket/10187#comment:100
https://trac.sagemath.org/ticket/10187#comment:100
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:99" title="Comment 99">drkirkby</a>:
</p>
<blockquote class="citation">
<h3 id="MyECLpackage">My ECL package</h3>
<ul><li>I don't see anything wrong with the way CXXFLAGS/CFLAGS is handled in the ECL package. It looks OK to me. It might not be 100% necessary, but in general we should set these flags and hope the package follows this.
</li></ul></blockquote>
<p>
If you change
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">if</span> <span class="o">[</span> <span class="s2">"x$SAGE_DEBUG"</span> <span class="o">=</span> xyes <span class="o">]</span> ; <span class="k">then
</span><span class="nv">CFLAGS</span><span class="o">=</span><span class="s2">"$CFLAGS -g -O0"</span>
<span class="nv">CXXFLAGS</span><span class="o">=</span><span class="s2">"$CXXFLAGS -g -O0"</span>
<span class="k">else
</span><span class="nv">CFLAGS</span><span class="o">=</span><span class="s2">"$CFLAGS -g -O2"</span>
<span class="nv">CXXFLAGS</span><span class="o">=</span><span class="s2">"$CXXFLAGS -g -O2"</span>
<span class="k">fi</span>
</pre></div></div><p>
to
</p>
<div class="wiki-code"><div class="code"><pre><span class="k">if</span> <span class="o">[</span> <span class="s2">"x$SAGE_DEBUG"</span> <span class="o">=</span> xyes <span class="o">]</span> ; <span class="k">then
</span><span class="nv">CFLAGS</span><span class="o">=</span><span class="s2">"$CFLAGS -g -O0"</span>
<span class="nv">CXXFLAGS</span><span class="o">=</span><span class="s2">"$CXXFLAGS -g -O0"</span>
<span class="k">else
</span><span class="nv">CFLAGS</span><span class="o">=</span><span class="s2">"-g -O2 $CFLAGS"</span>
<span class="nv">CXXFLAGS</span><span class="o">=</span><span class="s2">"-g -O2 $CXXFLAGS"</span>
<span class="k">fi</span>
</pre></div></div><p>
and add a comment that neither <code>CXX</code> nor <code>CXXFLAGS</code> are used within Sage / the way we configure / install ECL, I'm ok with your package.
</p>
<p>
In the long run, <code>CFLAG64</code> and <code>CXXFLAG64</code> should be set to their defaults (if empty) in (e.g.) <code>sage-env</code>.
</p>
<p>
You could remove the superfluous
</p>
<div class="wiki-code"><div class="code"><pre><span class="nb">set</span> +e
</pre></div></div><p>
The comment
</p>
<div class="wiki-code"><div class="code"><pre><span class="c"># 'export MAKE='make -j n' where n>1, breaks ECL builds, so unset make
</span></pre></div></div><p>
isn't up-to-date (since we do no longer <code>unset MAKE</code>).
</p>
<p>
I have no idea what
</p>
<div class="wiki-code"><div class="code"><pre><span class="c"># We clear MAKEFLAGS to fix building multiple spkgs in parallel on OS X.
</span><span class="nb">export </span><span class="nv">MAKEFLAGS</span><span class="o">=</span>
</pre></div></div><p>
is (now) intended to fix; <code>MAKE="$MAKE -j1"</code> should be sufficient. If it was really necessary on Darwin, it should only be done on Darwin, since it clears other <code>MAKEFLAGS</code> unrelated to parallel builds as well.
</p>
<p>
The following comment is a bit weird; <code>ln -sf ...</code> should do the right thing (without <code>rm</code>).
</p>
<div class="wiki-code"><div class="code"><pre><span class="c"># Create symbolic link to lib/ecl-version directory.
# This is important when the Sage install is moved.
</span><span class="nb">cd</span> <span class="s2">"$SAGE_LOCAL/lib/"</span> <span class="o">&&</span> rm -f ecl <span class="o">&&</span> ln -s ecl-* ecl
</pre></div></div><p>
The following won't work with spaces in <code>$SAGE_LOCAL</code> (currently a minor issue):
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">CPPFLAGS</span><span class="o">=</span><span class="s2">"$CPPFLAGS -I$SAGE_LOCAL/include"</span>
<span class="nv">LDFLAGS</span><span class="o">=</span><span class="s2">"$LDFLAGS -L$SAGE_LOCAL/lib"</span>
</pre></div></div><p>
(We could instead use <code>--with-gmp-prefix="$SAGE_LOCAL"</code>, and similar for the Boehm garbage collector...)
</p>
<p>
Perhaps add a comment to <code>SPKG.txt</code> that the <em>included</em> Boehm GC is used on MacOS X (only), if this is still the case. (I think it is; ECL used to assume <em>any</em> other Boehm GC found on MacOS X must be Fink's broken one, so always used its own there.)
</p>
<p>
I don't agree with the comment regarding the removal of the GMP source tree; leaving just <code>install-sh</code> there is totally safe, without requiring any patch.
</p>
<hr />
<p>
I'm ok with the Maxima spkg (IIRC ;-) ).
</p>
TicketvbraunWed, 01 Dec 2010 00:50:48 GMT
https://trac.sagemath.org/ticket/10187#comment:101
https://trac.sagemath.org/ticket/10187#comment:101
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:99" title="Comment 99">drkirkby</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li> <strong>maxima-5.22.1.patch</strong> SPKG.txt looks OK, but you will need to find someone that know more about Lisp than me to tell you if that's correct.
</li></ul></blockquote>
</blockquote>
<p>
The only Lisp change is adding the one line <code>(setf asdf::*user-cache* (truename "./lisp-cache"))</code> to asdf (Lisp build system). This was actually written by Nils Bruin in <a class="closed ticket" href="https://trac.sagemath.org/ticket/8645" title="defect: maxima package fails to install ECL library (closed: duplicate)">#8645</a>, I just collected the patch. So I'll positively review that line myself, if I may.
</p>
<blockquote class="citation">
<ul><li><strong>trac_10187_fix_easy_doctests.patch</strong>
</li></ul><p>
1) There are these numerical results. Has anyone independently verified this are correct?
[2.6789385347..., -8.3905259853..., 26.662447494..., -80.683148377...]
On what basis was the number of significant digits selected?
</p>
</blockquote>
<p>
The preceeding (long) symbolic expression changed in some trivial ways and I added the numerical evaluation to make sure that the old and new symbolic expression are the same.
</p>
<blockquote class="citation">
<p>
As a matter of interest, do we know if anyone every verify the original horrid looking symbolic integral is correct?
</p>
</blockquote>
<p>
I'm not the original author. All I know is that it is as correct in the patched doctest as it was before my patch.
</p>
<blockquote class="citation">
<p>
2) Why was the doctest:
</p>
<pre class="wiki">integral(abs(x), x, 0, a)
</pre><p>
changed to:
</p>
<pre class="wiki">integral(abs(x)*x, x, 0, a)
</pre></blockquote>
<p>
The old maxima could not perform the old integral, but the new maxima version can do it. To keep testing the assume facility and maxima error reporting, I made the integral more difficult.
</p>
<blockquote class="citation">
<p>
<strong>sage/plot/plot3d/transform.pyx</strong> Do we know if that horrible looking result is correct? I see it is a simple change from the previous horrible looking result, but how do we know if the previous one is correct? If, as I suspect, this has not been verified by hand or with another package, then we should write that fact.
</p>
</blockquote>
<p>
The old and new maxima actually yield different expressions because of some branch choice issue with the square roots. I'm not the original author, but I think this doctest only shows that maxima doesn't blow up with horrible expressions. I don't think anyone verified the original version. If you want to go through all maxima doctests and annotate them with a manual computation then that is great, but maybe material for a different ticket.
</p>
TicketdrkirkbyWed, 01 Dec 2010 02:28:15 GMT
https://trac.sagemath.org/ticket/10187#comment:102
https://trac.sagemath.org/ticket/10187#comment:102
<p>
If you comment the doctest, to indicate that the numerical results have not been verified, explaining why, then I;d consider that OK. But I think to stick a test with numerical results, which have not been verified, needs to be noted.
</p>
<p>
I would also remark you are not the author of the original test, but don't think the integral has been verified.
</p>
<p>
If state the reasons for the numerical results in the doctest then
</p>
<ul><li>I'm happy with everything except the Lisp.
</li><li>You copied the Lisp, but understand Lisp and know its correct.
</li><li>Someone else can verify my ECL package
</li></ul><p>
then I think that is all we need tor a positive review.
</p>
<p>
I must say, I think it's pretty unimpressive if we use as a test a result we have not verified. I would have thought it more sensible to use an example from a table of integrals from a book, verify it with Mathematica or Maple. But to base a test on something we don't even know is right is a very unfortunate state of affairs.
</p>
TicketdrkirkbyWed, 01 Dec 2010 03:03:46 GMT
https://trac.sagemath.org/ticket/10187#comment:103
https://trac.sagemath.org/ticket/10187#comment:103
<p>
When I say <em>"verify it with Mathematica or Maple"</em>, I'm not saying they are a <em>"gold standard"</em>. But if software developed independently of other software gives the same results, it would give increased confidence that the results are indeed correct.
</p>
TicketdrkirkbyWed, 01 Dec 2010 05:18:35 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>10187-cleanup.patch</em>
</li>
</ul>
<p>
clean up SPKG.txt and spkg-install on the ECL package
</p>
TicketdrkirkbyWed, 01 Dec 2010 05:23:42 GMT
https://trac.sagemath.org/ticket/10187#comment:104
https://trac.sagemath.org/ticket/10187#comment:104
<p>
I've attached a cleanup patch, addressing most of Leif's comments. See 10187-cleanup.patch
</p>
<p>
I decided not to restrict the MAKEFLAGS to only OS X, since we don't know for sure it's not needed on other systems, and I don't want to take a chance.
</p>
<p>
There appears to be no option to specify the location of the garbidge collector - only whether it is a system one or not. This differs from gmp, where you can specify the location too.
</p>
<p>
The package has been updated. MD5 hecksum = <code>a72f6967736c3d0dd9f69ab34a0cadb7</code>
</p>
<p>
Dave
</p>
TicketleifWed, 01 Dec 2010 05:52:47 GMT
https://trac.sagemath.org/ticket/10187#comment:105
https://trac.sagemath.org/ticket/10187#comment:105
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:104" title="Comment 104">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
I decided not to restrict the MAKEFLAGS to only OS X, since we don't know for sure it's not needed on other systems, and I don't want to take a chance.
</p>
</blockquote>
<p>
<em>I</em> know... ;-) (at least if we rely on <a class="ext-link" href="http://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html#Options_002fRecursion"><span class="icon"></span>GNU `make`</a>)
</p>
<blockquote class="citation">
<p>
There appears to be no option to specify the location of the garbidge collector - only whether it is a system one or not. This differs from gmp, where you can specify the location too.
</p>
</blockquote>
<p>
Yes, the apparently right one is unfortunately deprecated; I think we should report the Darwin issue upstream if ECL's behavior hasn't changed yet, since it is dumb to assume any "system" version there was broken.
</p>
TicketleifWed, 01 Dec 2010 07:30:01 GMT
https://trac.sagemath.org/ticket/10187#comment:106
https://trac.sagemath.org/ticket/10187#comment:106
<p>
Dave, how does changing
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">FOO</span><span class="o">=</span><span class="s2">"$with_spaces/foo/bar"</span>
</pre></div></div><p>
to
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">FOO</span><span class="o">=</span><span class="s2">"${with_spaces}/foo/bar"</span>
</pre></div></div><p>
solve the problem with spaces?
</p>
<p>
<code>SPKG.txt</code> contains some unterminated sentence (<em>"Added -with-gmp-prefix="$SAGE_LOCAL" --with-system-gmp=yes --enable-boehm=system to the line invoking the configure script. These..."</em> ?)
</p>
TicketvbraunWed, 01 Dec 2010 11:49:36 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>trac_10187_fix_easy_doctests.patch</em>
</li>
</ul>
<p>
Updated patch
</p>
TicketdrkirkbyWed, 01 Dec 2010 11:50:18 GMT
https://trac.sagemath.org/ticket/10187#comment:107
https://trac.sagemath.org/ticket/10187#comment:107
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:106" title="Comment 106">leif</a>:
</p>
<blockquote class="citation">
<p>
Dave, how does changing
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">FOO</span><span class="o">=</span><span class="s2">"$with_spaces/foo/bar"</span>
</pre></div></div><p>
to
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">FOO</span><span class="o">=</span><span class="s2">"${with_spaces}/foo/bar"</span>
</pre></div></div><p>
solve the problem with spaces?
</p>
</blockquote>
<p>
What's wrong with it?
</p>
<pre class="wiki">drkirkby@laptop:~$ cat tt
#!/bin/sh
SAGE_LOCAL="/this path has/some spaces in/it"
FULL_PATH="${SAGE_LOCAL}/local/lib"
echo "$FULL_PATH"
drkirkby@laptop:~$ ./tt
/this path has/some spaces in/it/local/lib
</pre><p>
As far as I can tell, that basically shows that what we have will permit spaces. If not, please explain why and provide an alternative.
</p>
<blockquote class="citation">
<p>
<code>SPKG.txt</code> contains some unterminated sentence (<em>"Added -with-gmp-prefix="$SAGE_LOCAL" --with-system-gmp=yes --enable-boehm=system to the line invoking the configure script. These..."</em> ?)
</p>
</blockquote>
<p>
I was finishing that at about 3 AM local time. I'll sort out that minor issue, and any others you can see, once we agree how to handle the spaces in the path
</p>
<p>
Dave
</p>
TicketvbraunWed, 01 Dec 2010 11:57:31 GMT
https://trac.sagemath.org/ticket/10187#comment:108
https://trac.sagemath.org/ticket/10187#comment:108
<p>
I've added a comment to explain the numeric evaluation of the taylor series in <code>trac_10187_fix_easy_doctests.patch</code> and compared it with Maple 12.
</p>
<p>
About the spaces in paths: <code>FOO="$with_spaces/foo/bar"</code> and <code>FOO="${with_spaces}/foo/bar"</code> will assign the same value to <code>FOO</code>. You only need the curly brackets if then next character is a valid part of a variable name, i.e. <code>FOO="${with_spaces}bar"</code> works but <code>FOO="$with_spacesbar"</code> is wrong.
</p>
TicketdrkirkbyWed, 01 Dec 2010 12:48:05 GMT
https://trac.sagemath.org/ticket/10187#comment:109
https://trac.sagemath.org/ticket/10187#comment:109
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:108" title="Comment 108">vbraun</a>:
</p>
<blockquote class="citation">
<p>
I've added a comment to explain the numeric evaluation of the taylor series in <code>trac_10187_fix_easy_doctests.patch</code> and compared it with Maple 12.
</p>
</blockquote>
<p>
Thank you. I'm ok with that then.
</p>
<blockquote class="citation">
<p>
About the spaces in paths: <code>FOO="$with_spaces/foo/bar"</code> and <code>FOO="${with_spaces}/foo/bar"</code> will assign the same value to <code>FOO</code>. You only need the curly brackets if then next character is a valid part of a variable name, i.e. <code>FOO="${with_spaces}bar"</code> works but <code>FOO="$with_spacesbar"</code> is wrong.
</p>
</blockquote>
<p>
So what bit of spkg-install will break with spaces in the SAGE_LOCAL? Leif commented the CPPFLAGS would not handle spaces, but I don't see why not. The braces should just make 100% sure not even a contrived example should break things.
</p>
<p>
Dave
</p>
TicketkcrismanWed, 01 Dec 2010 13:25:48 GMT
https://trac.sagemath.org/ticket/10187#comment:110
https://trac.sagemath.org/ticket/10187#comment:110
<p>
I just wanted to verify that all seems well, except possibly that the <code>trac_10187_mark_some_doctests_random_until_9880_gets_merged.patch</code> may not apply correctly after the latest change to clarify that the Taylor coefficients are correct. Certainly the <a class="closed ticket" href="https://trac.sagemath.org/ticket/8645" title="defect: maxima package fails to install ECL library (closed: duplicate)">#8645</a> changes are fine. So if that patch still applies (or is updated) and you guys figure out the spaces issue, this should definitely get positive review! Great work. Hopefully it will be merged before the *next* Maxima upgrade :)
</p>
TicketvbraunWed, 01 Dec 2010 14:04:50 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>trac_10187_mark_some_doctests_random_until_9880_gets_merged.patch</em>
</li>
</ul>
<p>
Updated patch
</p>
TicketvbraunWed, 01 Dec 2010 14:14:46 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:111
https://trac.sagemath.org/ticket/10187#comment:111
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
I've rediffed <code>trac_10187_mark_some_doctests_random_until_9880_gets_merged.patch</code> to eliminate the fuzz, nothing fancy.
</p>
<p>
I think all that remains is to give a positive review to ECL; Leif, are you satisfied?
</p>
TicketdrkirkbyWed, 01 Dec 2010 14:55:18 GMT
https://trac.sagemath.org/ticket/10187#comment:112
https://trac.sagemath.org/ticket/10187#comment:112
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:111" title="Comment 111">vbraun</a>:
</p>
<blockquote class="citation">
<p>
I think all that remains is to give a positive review to ECL;
</p>
</blockquote>
<p>
I agree.
</p>
<blockquote class="citation">
<p>
Leif, are you satisfied?
</p>
</blockquote>
<p>
Leif found a couple of errors in the documentation I put in SPKG.txt. I found two myself, but perhaps Leif found others. If he can list them, along with some suggestions to get around what he perceives as a problem with spaces in filenames, I'll address all issues at once.
</p>
<p>
Then this should get a positive review I think.
</p>
<p>
Dave
</p>
TicketleifWed, 01 Dec 2010 16:11:10 GMT
https://trac.sagemath.org/ticket/10187#comment:113
https://trac.sagemath.org/ticket/10187#comment:113
<p>
I had (<em>"in principle"</em><sup>TM</sup>) already been ok with Dave's ECL package, then he made further changes.
</p>
<p>
As said before, I consider the "spaces in <code>SAGE_ROOT</code>" issue a currently rather minor one (as long as our <code>spkg-install</code> doesn't fail in an unexpected manner), since I doubt upstream (at least some other packages) will support that.
</p>
<p>
However, Dave claimed he had fixed that (with a change that effectively changes nothing ;-) ).
While <code>echo $CPPFLAGS</code> will almost always work, running <code>gcc</code> with spaces in the include path won't as is. So if at all, I'd change it to
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">CPPFLAGS</span><span class="o">=</span><span class="s2">"$CPPFLAGS -I\"$SAGE_LOCAL/include\""</span>
<span class="nv">LDFLAGS</span><span class="o">=</span><span class="s2">"$LDFLAGS -L\"$SAGE_LOCAL/lib\""</span>
</pre></div></div><p>
which at least <code>gcc</code> does support, but not necessarily other parts of <code>configure</code> etc.
</p>
<hr />
<p>
There are some typos in <code>SPKG.txt</code> (IMHO minor as well):
</p>
<ul><li>s/sa<strong>f</strong>ter/safer/ (plus spurious ":w" ?)
</li><li>s/user defined/user<strong>-</strong>defined/
</li><li>s/overwritten, as they would have done/over<strong>ridden</strong>, as they would have <strong>been</strong>/
</li><li>s/it will cause<strong>s</strong>/it will cause/
</li><li>s/Remove/Remove<strong>d</strong>/
</li></ul><p>
But <code>SPKG.txt</code> is not the <em>User</em> or <em>Developer's Guide</em>...
</p>
<hr />
<p>
I cannot guarantee (nor test) the new parameters to <code>configure</code> work on all platforms as expected: <code>--with-system-gmp=yes</code> is IMHO (at least) superfluous if we also pass <code>--with-gmp-prefix="$SAGE_LOCAL"</code>.
</p>
<hr />
<p>
I'd prefer all error messages (in <code>spkg-install</code>) starting with <em>"Error"</em> to ease grepping for such, consistent with other packages.
</p>
TicketleifWed, 01 Dec 2010 16:17:15 GMT
https://trac.sagemath.org/ticket/10187#comment:114
https://trac.sagemath.org/ticket/10187#comment:114
<p>
Can someone test if / verify that ECL meanwhile allows us to use Sage's Boehm GC on Darwin as well, rather than the one shipped with ECL?
</p>
TicketleifWed, 01 Dec 2010 16:20:32 GMT
https://trac.sagemath.org/ticket/10187#comment:115
https://trac.sagemath.org/ticket/10187#comment:115
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:114" title="Comment 114">leif</a>:
</p>
<blockquote class="citation">
<p>
Can someone test if / verify that ECL meanwhile allows us to use Sage's Boehm GC on Darwin as well, rather than the one shipped with ECL?
</p>
</blockquote>
<p>
(If not, I think we should mention this in the <em>Special <a class="missing wiki">Update/Build?</a> Instructions</em>, and report this upstream as a bug.)
</p>
TicketdrkirkbyWed, 01 Dec 2010 18:49:45 GMT
https://trac.sagemath.org/ticket/10187#comment:116
https://trac.sagemath.org/ticket/10187#comment:116
<p>
I take your point Leif, you can't check the extra options I added to the configure script. I think they were helpful and safe. Given that, and to stop this ticket dragging on any longer, they are best removed. It's one less thing to worry about.
</p>
<p>
If I remove those options to the configured script, <strong>and</strong> implement your changes to CPPFLAGS and LDFLAGS, it actually break the code, as the Boehm header files are no longer found. (I cut and pasted your changes.) As soon as I undo your changes, so the header files are found.
</p>
<p>
Given this, I've made some more changes
</p>
<ul><li>Put CPPFLAGS and LDFLAGS back to how they were in the previous ECL package.
</li><li>Removed the options to configure, so they are the same as the previous ECL package
</li><li>Corrected the typos.
</li></ul><p>
If you want to sort out the problem with spaces in the filenames, then edit the ticket and add yourself as an author. But I don't want spend any longer on this.
</p>
<p>
I've attched another patch, which reverses some changes, and corrects the typos. A new package can be found at the old place. The MD5 checksum is <code>8f60b1b4453a277d33178683ef532a93</code>
Dave
</p>
TicketdrkirkbyWed, 01 Dec 2010 18:54:11 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>10187-further-cleanup.patch</em>
</li>
</ul>
<p>
Further clean up SPKG.txt and spkg-install on the ECL package. Reverse some previous changes
</p>
TicketleifWed, 01 Dec 2010 20:17:05 GMT
https://trac.sagemath.org/ticket/10187#comment:117
https://trac.sagemath.org/ticket/10187#comment:117
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:116" title="Comment 116">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
I take your point Leif, you can't check the extra options I added to the configure script. I think they were helpful and safe. Given that, and to stop this ticket dragging on any longer, they are best removed. It's one less thing to worry about.
</p>
<p>
If I remove those options to the configured script, <strong>and</strong> implement your changes to CPPFLAGS and LDFLAGS, it actually break the code, as the Boehm header files are no longer found. (I cut and pasted your changes.) As soon as I undo your changes, so the header files are found.
</p>
</blockquote>
<p>
Yes, with
</p>
<div class="wiki-code"><div class="code"><pre><span class="nv">CPPFLAGS</span><span class="o">=</span><span class="s2">"$CPPFLAGS -I\"${SAGE_LOCAL}/include\""</span>
<span class="nv">LDFLAGS</span><span class="o">=</span><span class="s2">"$LDFLAGS -L\"${SAGE_LOCAL}/lib\""</span>
</pre></div></div><p>
and
</p>
<div class="wiki-code"><div class="code"><pre> ./configure --prefix<span class="o">=</span><span class="s2">"$SAGE_LOCAL"</span> --with-gmp-prefix<span class="o">=</span><span class="s2">"$SAGE_LOCAL"</span> <span class="c"># --enable-boehm=system
</span></pre></div></div><p>
<code>configure</code> behaves weird (and finally the Lisp build fails for me):
</p>
<pre class="wiki">...
checking for ld flags when building shared libraries... -shared -L"/home/leif/Sage/sage-4.6.1.alpha2/local/lib"
...
checking gmp.h usability... yes
checking gmp.h presence... yes
checking for gmp.h... yes
...
checking for GC_malloc in -lgc... yes
checking whether we can use the existing Boehm-Weiser library ... yes
checking for GC_malloc in -lgc... (cached) yes
checking if we need to copy GC private headers ... checking if we use Boehm-Demers-Weiser precise garbage collector... no
...
checking for ffi_call in -lffi... no
/home/leif/Sage/sage-4.6.1.alpha2/spkg/build/ecl-10.4.1/src/src/configure: line
9924: test: =: unary operator expected
checking whether we can dynamically build calls to C functions... yes
...
checking gc.h usability... yes
checking gc.h presence... no
configure: WARNING: gc.h: accepted by the compiler, rejected by the preprocessor
!
configure: WARNING: gc.h: proceeding with the compiler's result
checking for gc.h... yes
configure: creating ./config.status
...
Configuration complete. To build ECL, issue make in this directory.
...
;;; About to load cmp/load.lsp
Too many arguments supplied to a macro or a destructuring-bind form.
No restarts available.
Broken at SI::TPL.
File: #P"/home/leif/Sage/sage-4.6.1.alpha2/spkg/build/ecl-10.4.1/src/src/lsp/to
p.lsp" (Position #20393)
C>>
</pre><p>
I'd like to see such documented in <code>SPKG.txt</code> (<em>Special <a class="missing wiki">Update/Build?</a> Instructions</em>) and / or <code>spkg-install</code> (e.g. <code># *don't* quote SAGE_LOCAL here, since...</code>), to avoid others touching this spkg running into the same problem(s).
</p>
<p>
Clearly there are bugs in <code>configure</code>, which might get fixed in future releases though.
</p>
TicketdrkirkbyWed, 01 Dec 2010 20:50:26 GMT
https://trac.sagemath.org/ticket/10187#comment:118
https://trac.sagemath.org/ticket/10187#comment:118
<p>
I will attach yet another patch, documenting the problem as requested. Hopefully this is sufficient to get a positive review. The MD5 checksum is now <code>d162c7fa859b7f894bdd6a6cfa061359</code>
</p>
<p>
BTW Leif, I'd appreciate your input on sage-devel on the thread <a class="ext-link" href="http://groups.google.com/group/sage-devel/browse_thread/thread/c201930abdbd23d3?hl=en"><span class="icon"></span>When is a test not a valid test?</a> It's clear different Sage developers have <strong>very</strong> different views on quality control.
</p>
<p>
Dave
</p>
TicketdrkirkbyWed, 01 Dec 2010 20:51:44 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>10187-Document-quoting-problem.patch</em>
</li>
</ul>
<p>
Document that quoting SAGE_LOCAL can cause problems. Correct a spelling error too.
</p>
TicketdrkirkbyThu, 02 Dec 2010 11:30:51 GMT
https://trac.sagemath.org/ticket/10187#comment:119
https://trac.sagemath.org/ticket/10187#comment:119
<p>
Since Leif's last comment was he wanted the issue of quoting of SAGE_LOCAL documented in SPKG.txt and spkg-install, and I've now added those comments, I believe this ticket should now get a positive review. I hope Leif and/or others agree!! It would be good to see it merged into 4.6.1, which will hopefully address the Fedora 14 issues.
</p>
<p>
Dave
</p>
TicketjdemeyerThu, 02 Dec 2010 11:36:50 GMT
https://trac.sagemath.org/ticket/10187#comment:120
https://trac.sagemath.org/ticket/10187#comment:120
<p>
Please confirm that the links to the spkgs and patches in the ticket description are up-to-date, then I will do some testing.
</p>
TicketleifThu, 02 Dec 2010 11:47:34 GMT
https://trac.sagemath.org/ticket/10187#comment:121
https://trac.sagemath.org/ticket/10187#comment:121
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:120" title="Comment 120">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Please confirm that the links to the spkgs and patches in the ticket description are up-to-date, then I will do some testing.
</p>
</blockquote>
<p>
Currently myself doing "final" testing... ;-)
</p>
<p>
Dave: You can still delete the redundant <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/maxima-5.22.1.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/maxima-5.22.1.patch</a> .
</p>
TicketleifThu, 02 Dec 2010 11:52:54 GMT
https://trac.sagemath.org/ticket/10187#comment:122
https://trac.sagemath.org/ticket/10187#comment:122
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:121" title="Comment 121">leif</a>:
</p>
<blockquote class="citation">
<p>
Dave: You can still delete the redundant <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/maxima-5.22.1.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/maxima-5.22.1.patch</a> .
</p>
</blockquote>
<p>
Ooops, forget that.
</p>
<p>
Confused it with the (now deleted) redundant patch to Sage scripts.
</p>
TicketdrkirkbyThu, 02 Dec 2010 11:57:43 GMT
https://trac.sagemath.org/ticket/10187#comment:123
https://trac.sagemath.org/ticket/10187#comment:123
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:122" title="Comment 122">leif</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:121" title="Comment 121">leif</a>:
</p>
<blockquote class="citation">
<p>
Dave: You can still delete the redundant <a class="ext-link" href="http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/maxima-5.22.1.patch"><span class="icon"></span>http://trac.sagemath.org/sage_trac/raw-attachment/ticket/10187/maxima-5.22.1.patch</a> .
</p>
</blockquote>
<p>
Ooops, forget that.
</p>
<p>
Confused it with the (now deleted) redundant patch to Sage scripts.
</p>
</blockquote>
<p>
Ah, we have a problem. I see your message, checked the description which no longer mentions that patch, so I have deleted it. There is no way to retrieve it from trac either.
</p>
<p>
Dave
</p>
TicketdrkirkbyThu, 02 Dec 2010 12:02:37 GMT
https://trac.sagemath.org/ticket/10187#comment:124
https://trac.sagemath.org/ticket/10187#comment:124
<p>
Leif, since you are now doing the final testing, I assume you have downloaded the patch. Can you put it back.
</p>
<p>
There's no mention in the description of applying the patch either. Is it in the .spkg, in which case it was only needed for review purposes, and can be retried with
</p>
<pre class="wiki">hg export tip
</pre><p>
Dave
</p>
TicketleifThu, 02 Dec 2010 12:13:48 GMT
https://trac.sagemath.org/ticket/10187#comment:125
https://trac.sagemath.org/ticket/10187#comment:125
<p>
Ok, except for the now obsolete changelog entry
</p>
<pre class="wiki"> * Changed method of setting CPPFLAGS and LDFLAGS so they would work with
a space in $SAGE_LOCAL.
</pre><p>
the ECL spkgs looks clean (though there's work for follow-up tickets).
</p>
<p>
The patch recently deleted by Dave was just the (cumulative) Maxima <strong>spkg</strong> patch for reference / review, so can easily be restored.
</p>
TicketleifThu, 02 Dec 2010 12:21:16 GMT
https://trac.sagemath.org/ticket/10187#comment:126
https://trac.sagemath.org/ticket/10187#comment:126
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:124" title="Comment 124">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
There's no mention in the description of applying the patch either. Is it in the .spkg, in which case it was only needed for review purposes, and can be retried with
</p>
</blockquote>
<pre class="wiki">hg export tip
</pre><p>
You'd have to export changesets 20, 21 and 22:
</p>
<pre class="wiki">changeset: 22:e8822a6306c4
tag: tip
user: Volker Braun <vbraun@stp.dias.ie>
date: Fri Nov 26 17:46:01 2010 +0100
files: spkg-install
description:
trac 10187: use MAKE variable
changeset: 21:2f6e663e08f6
user: Volker Braun <vbraun@stp.dias.ie>
date: Fri Nov 26 16:12:35 2010 +0100
files: spkg-install
description:
trac 10187: minor changes
changeset: 20:1b2e265d49d2
user: Volker Braun <vbraun@stp.dias.ie>
date: Fri Oct 29 13:40:03 2010 +0100
files: SPKG.txt spkg-install
description:
updated to latest upstream; rewritten build for maxima.fas (see spgk-install)
</pre>
TicketvbraunThu, 02 Dec 2010 12:23:04 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>maxima-5.22.1.patch</em>
</li>
</ul>
<p>
Re-uploaded diff for the maxima spkg (for review purposes only)
</p>
TicketvbraunThu, 02 Dec 2010 12:24:00 GMT
https://trac.sagemath.org/ticket/10187#comment:127
https://trac.sagemath.org/ticket/10187#comment:127
<p>
I have re-uploaded the diff for the maxima spkg. It is only for historical purposes right now as we have already reviewed the new maxima spkg.
</p>
TicketleifThu, 02 Dec 2010 12:28:02 GMTdescription changed
https://trac.sagemath.org/ticket/10187#comment:128
https://trac.sagemath.org/ticket/10187#comment:128
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/10187?action=diff&version=128">diff</a>)
</li>
</ul>
<p>
Minor correction, description is (and was) up-to-date.
</p>
TicketdrkirkbyThu, 02 Dec 2010 12:37:40 GMT
https://trac.sagemath.org/ticket/10187#comment:129
https://trac.sagemath.org/ticket/10187#comment:129
<p>
Thank you for uploading the Maxima patch again. Perhaps you could explain how one would export one patch containing those 3 changesets, as I don't know how to do that, but have often felt it would be useful.
</p>
<p>
OK, hopefully after Leif's Final<sup>TM</sup> testing, this is ready to go, with all the correct library patches and .spkg files now in place.
</p>
<p>
At least that's my understanding of the situation. Can anyone else confirm this?
</p>
<p>
Dave
</p>
TicketdrkirkbyThu, 02 Dec 2010 12:40:28 GMT
https://trac.sagemath.org/ticket/10187#comment:130
https://trac.sagemath.org/ticket/10187#comment:130
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:125" title="Comment 125">leif</a>:
</p>
<blockquote class="citation">
<p>
Ok, except for the now obsolete changelog entry
</p>
<pre class="wiki"> * Changed method of setting CPPFLAGS and LDFLAGS so they would work with
a space in $SAGE_LOCAL.
</pre><p>
the ECL spkgs looks clean (though there's work for follow-up tickets).
</p>
</blockquote>
<p>
I'll address that. Give me 10 minutes and I'll upload a new .spkg with that entry in SPKG.txt removed.
</p>
TicketleifThu, 02 Dec 2010 12:46:03 GMT
https://trac.sagemath.org/ticket/10187#comment:131
https://trac.sagemath.org/ticket/10187#comment:131
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:130" title="Comment 130">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:125" title="Comment 125">leif</a>:
I'll address that. Give me 10 minutes and I'll upload a new .spkg with that entry in SPKG.txt removed.
</p>
</blockquote>
<p>
I thought we were in "feature" freeze. ;-)
</p>
<p>
As mentioned before, positive review from me for both spkgs (and the scripts patch, haven't really looked at the others).
</p>
<p>
Final test on a slow machine will take hours; I think Jeroen is also going to test on the farm.
</p>
<p>
I'll report back then.
</p>
TicketdrkirkbyThu, 02 Dec 2010 12:57:21 GMT
https://trac.sagemath.org/ticket/10187#comment:132
https://trac.sagemath.org/ticket/10187#comment:132
<p>
A new ECL package, with an MD5 cheskcum of <code>7c612a32fef87878cf686f9c35858e15</code> has been uploaded. That has the inaccurate comment removed. I'll attach a patch in a minute or two, but there's no need for Jeroen to wait - he can test this now, as the package is fully upto date.
</p>
<p>
Dave
</p>
TicketdrkirkbyThu, 02 Dec 2010 13:00:59 GMT
https://trac.sagemath.org/ticket/10187#comment:133
https://trac.sagemath.org/ticket/10187#comment:133
<p>
Oops, forget my comment. I failed to cmmmit the change.
</p>
<p>
Give me a bit longer!!!
</p>
<p>
Dave
</p>
TicketdrkirkbyThu, 02 Dec 2010 13:09:41 GMTowner changed
https://trac.sagemath.org/ticket/10187#comment:134
https://trac.sagemath.org/ticket/10187#comment:134
<ul>
<li><strong>owner</strong>
changed from <em>tbd</em> to <em>drkirkby</em>
</li>
</ul>
<p>
OK, new package with a checksum of <code>452b5481d6e9dfd47d276cda89cebe7d</code> is now in place. Patch will follow, but it only removes two lines from SPKG.txt
</p>
<p>
Dave
</p>
TicketvbraunThu, 02 Dec 2010 13:12:23 GMT
https://trac.sagemath.org/ticket/10187#comment:135
https://trac.sagemath.org/ticket/10187#comment:135
<p>
For the record, here is how to generate a patch for a range of changesets:
</p>
<pre class="wiki">hg diff -r 19:tip > maxima-5.22.1.patch
</pre><p>
Applying the resulting patch is equivalent to applying the output of
</p>
<pre class="wiki">hg export -r 19:tip
</pre><p>
but the <code>hg diff</code> patch is not broken down into the individual changesets.
</p>
TicketdrkirkbyThu, 02 Dec 2010 13:12:27 GMTattachment set
https://trac.sagemath.org/ticket/10187
https://trac.sagemath.org/ticket/10187
<ul>
<li><strong>attachment</strong>
set to <em>10187-remove-inaccure-comment-in-SPKG.txt.patch</em>
</li>
</ul>
<p>
Removes an inaccurate comment from SPKG.txt
</p>
TicketdrkirkbyThu, 02 Dec 2010 13:13:25 GMT
https://trac.sagemath.org/ticket/10187#comment:136
https://trac.sagemath.org/ticket/10187#comment:136
<p>
All ready to be tested now.
</p>
<p>
Dave
</p>
TicketleifThu, 02 Dec 2010 14:18:34 GMT
https://trac.sagemath.org/ticket/10187#comment:137
https://trac.sagemath.org/ticket/10187#comment:137
<p>
Just for the record:
</p>
<p>
I do get doctest errors with Sage 4.6.1.alpha2 (+ <a class="closed ticket" href="https://trac.sagemath.org/ticket/8664" title="enhancement: Upgrade Sage's MPIR spkg to version 2.1.3 (closed: fixed)">#8664</a> + <a class="closed ticket" href="https://trac.sagemath.org/ticket/5847" title="enhancement: Update GMP-ECM to 6.3 (closed: fixed)">#5847</a>) running <code>ptestlong</code> on Ubuntu 9.04 x86 (Pentium 4); have to analyze later...
</p>
TicketleifThu, 02 Dec 2010 16:27:32 GMT
https://trac.sagemath.org/ticket/10187#comment:138
https://trac.sagemath.org/ticket/10187#comment:138
<p>
I hope my installation is somehow broken:
</p>
<pre class="wiki">The following tests failed:
sage -t -long -force_lib devel/sage/doc/en/a_tour_of_sage/index.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/bordeaux_2008/nf_introduction.rst # 8 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/interface_issues.rst # 4 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/linear_algebra.rst # 5 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/polynomials.rst # 1 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/calculus.rst # 31 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/plotting.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/installation/source.rst # 1 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/interfaces.rst # 18 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/latex.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/tour_rings.rst # 2 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/tour_algebra.rst # 21 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/tutorial/interfaces.rst # 18 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/a_tour_of_sage/index.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/tutorial/tour_algebra.rst # 20 doctests failed
sage -t -long -force_lib devel/sage/sage/combinat/perfect_matching.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/combinat/combinat.py # 10 doctests failed
sage -t -long -force_lib devel/sage/sage/combinat/words/word_generators.py # 11 doctests failed
sage -t -long -force_lib devel/sage/sage/geometry/lattice_polytope.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/geometry/polyhedra.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/constructor.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/heegner.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_generic.py # 16 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/latex.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/preparser.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/functional.py # 34 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/citation.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/graphs/graph_generators.py # 6 doctests failed
sage -t -long -force_lib devel/sage/sage/gsl/integration.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/modules/free_module_element.pyx # 39 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix1.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix_sparse.pyx # 6 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix2.pyx # 7 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix_symbolic_dense.pyx # 63 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/relation.py # 72 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/power_helper.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/pynac.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/function.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/function_factory.py # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/ring.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/random_tests.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/constants_c.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/maxima_wrapper.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/expression_conversions.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/constants.py # 16 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/assumptions.py # 51 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/expression.pyx # 255 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/integration/external.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/integration/integral.py # 64 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/infinity.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/fraction_field_element.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/ring.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/residue_field.pyx # 15 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/misc.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/contfrac.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/integer_ring.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/multi_polynomial.pyx # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/polynomial_element.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/polynomial_rational_flint.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/order.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/galois_group.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_element_quadratic.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_element.pyx # 12 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_base.pyx # 13 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_rel.py # 10 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/functions.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/calculus.py # 127 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/desolvers.py # 70 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/tests.py # 27 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/functional.py # 45 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/test_sympy.py # 7 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/wester.py # 49 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/special.py # 69 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/log.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/wigner.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/min_max.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/hyperbolic.py # 9 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/transcendental.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/piecewise.py # 65 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/orthogonal_polys.py # 42 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/other.py # 19 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/trig.py # 17 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/line.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/arc.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot3d/plot3d.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot3d/transform.pyx # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/structure/parent.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/structure/element.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/structure/formal_sum.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/expect.py # 26 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/tests.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/quit.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py # 218 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/group_algebra.py # 6 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quaternion_algebra_element.py # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quatalg/quaternion_algebra_element.pyx # 36 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quatalg/quaternion_algebra.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/modular/overconvergent/genus0.py # 19 doctests failed
sage -t -long -force_lib devel/sage/sage/modular/modform/ambient_R.py # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/tensor/differential_forms.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/tensor/differential_form_element.py # 43 doctests failed
----------------------------------------------------------------------
Total time for all tests: 13327.9 seconds
make: *** [ptestlong] Error 128
</pre><p>
Going to retry, which again will take hours...
</p>
TicketleifThu, 02 Dec 2010 17:03:26 GMT
https://trac.sagemath.org/ticket/10187#comment:139
https://trac.sagemath.org/ticket/10187#comment:139
<p>
Yes, <code>make</code> reverted both ECL and Maxima to the previous versions.
</p>
<p>
Another <code>ptestlong</code> in progress...
</p>
TicketdrkirkbyThu, 02 Dec 2010 18:52:57 GMT
https://trac.sagemath.org/ticket/10187#comment:140
https://trac.sagemath.org/ticket/10187#comment:140
<p>
Am I right in assuming all these patches are against sage-4.6.1.alpha1 ?
</p>
<p>
I just built sage-4.6.1.alpha2, but some of these patches are applied, and some are not. So it looks like I'm going to have to build sage-4.6.1.alpha1. I expect it will take me a couple of hours to build it, patch it, then doctest it
</p>
<p>
Dave
</p>
TicketleifThu, 02 Dec 2010 19:01:38 GMT
https://trac.sagemath.org/ticket/10187#comment:141
https://trac.sagemath.org/ticket/10187#comment:141
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:140" title="Comment 140">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Am I right in assuming all these patches are against sage-4.6.1.alpha1 ?
</p>
<p>
I just built sage-4.6.1.alpha2, but some of these patches are applied, and some are not. So it looks like I'm going to have to build sage-4.6.1.alpha1. I expect it will take me a couple of hours to build it, patch it, then doctest it
</p>
</blockquote>
<p>
Shouldn't be necessary.
</p>
<p>
I've previously tested the spkgs and patches successfully (<code>ptestlong</code>) multiple times with Sage 4.6.1.alpha2 (in addition with the new MPIR and ECM, <a class="closed ticket" href="https://trac.sagemath.org/ticket/8664" title="enhancement: Upgrade Sage's MPIR spkg to version 2.1.3 (closed: fixed)">#8664</a> and <a class="closed ticket" href="https://trac.sagemath.org/ticket/5847" title="enhancement: Update GMP-ECM to 6.3 (closed: fixed)">#5847</a>, respectively) on Ubuntu 10.04 x86_64.
</p>
<p>
On the 32-bit machine, I so far again got 47 doctest errors with the same though.
</p>
TicketleifThu, 02 Dec 2010 19:27:38 GMT
https://trac.sagemath.org/ticket/10187#comment:142
https://trac.sagemath.org/ticket/10187#comment:142
<p>
Hmmm, maybe a Mercurial issue?
</p>
<p>
Patches apply apparently clean on vanilla alpha2 as well (with an old Mercurial version), but I also get doctest errors on Ubuntu 9.04 x86_64.
</p>
TicketleifThu, 02 Dec 2010 19:49:28 GMT
https://trac.sagemath.org/ticket/10187#comment:143
https://trac.sagemath.org/ticket/10187#comment:143
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:142" title="Comment 142">leif</a>:
</p>
<blockquote class="citation">
<p>
Hmmm, maybe a Mercurial issue?
</p>
<p>
Patches apply apparently clean on vanilla alpha2 as well (with an old Mercurial version), but I also get doctest errors on Ubuntu 9.04 x86_64.
</p>
</blockquote>
<p>
Same with Sage's Mercurial version (1.6.x), i.e. patches apply cleanly.
</p>
<p>
Now at 199+ doctest errors on the 32-bit machine... :(
</p>
TicketleifThu, 02 Dec 2010 20:00:48 GMT
https://trac.sagemath.org/ticket/10187#comment:144
https://trac.sagemath.org/ticket/10187#comment:144
<p>
Ubuntu 9.04 x86_64 (gcc 4.3.3), vanilla Sage 4.6.1.alpha2 with <a class="closed ticket" href="https://trac.sagemath.org/ticket/10187" title="defect: Update ECL to 10.4.1 and Maxima to 5.22.1 - currently the latest releases. (closed: fixed)">#10187</a>:
</p>
<pre class="wiki">The following tests failed:
sage -t -long -force_lib devel/sage/doc/en/installation/source.rst # 1 doctests failed
sage -t -long -force_lib devel/sage/doc/en/a_tour_of_sage/index.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/polynomials.rst # 1 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/linear_algebra.rst # 5 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/calculus.rst # 31 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/interface_issues.rst # 4 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/plotting.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/interfaces.rst # 18 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/latex.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/tour_algebra.rst # 21 doctests failed
sage -t -long -force_lib devel/sage/doc/en/bordeaux_2008/nf_introduction.rst # 8 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/a_tour_of_sage/index.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/tutorial/interfaces.rst # 18 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/tutorial/tour_algebra.rst # 20 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix2.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix1.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix_symbolic_dense.pyx # 40 doctests failed
sage -t -long -force_lib devel/sage/sage/combinat/combinat.py # 10 doctests failed
sage -t -long -force_lib devel/sage/sage/combinat/perfect_matching.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/structure/element.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/structure/formal_sum.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/expression_conversions.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/ring.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/function.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/random_tests.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/maxima_wrapper.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/pynac.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/relation.py # 66 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/constants.py # 16 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/assumptions.py # 51 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/power_helper.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/function_factory.py # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/constants_c.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/integration/external.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/integration/integral.py # 64 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/expression.pyx # 247 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quaternion_algebra_element.py # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/group_algebra.py # 6 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quatalg/quaternion_algebra_element.pyx # 36 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quatalg/quaternion_algebra.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/geometry/lattice_polytope.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/quit.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/geometry/polyhedra.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/tests.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py # 224 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/misc.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/ring.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/expect.py # 26 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/infinity.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/fraction_field_element.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/contfrac.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/residue_field.pyx # 15 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/integer_ring.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_element_quadratic.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/galois_group.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_base.pyx # 13 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/order.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_element.pyx # 12 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_rel.py # 10 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/polynomial_element.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/heegner.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_generic.py # 15 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/arc.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/line.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot3d/plot3d.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot3d/transform.pyx # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/citation.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/functional.py # 29 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/latex.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/preparser.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/modular/modform/ambient_R.py # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/modular/overconvergent/genus0.py # 19 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/trig.py # 17 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/other.py # 19 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/piecewise.py # 65 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/special.py # 69 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/transcendental.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/log.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/min_max.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/wigner.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/hyperbolic.py # 9 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/orthogonal_polys.py # 42 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/functional.py # 45 doctests failed
sage -t -long -force_lib devel/sage/sage/graphs/graph_generators.py # 6 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/calculus.py # 127 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/test_sympy.py # 7 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/functions.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/desolvers.py # 70 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/tests.py # 24 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/wester.py # 45 doctests failed
sage -t -long -force_lib devel/sage/sage/gsl/integration.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/modules/free_module_element.pyx # 8 doctests failed
----------------------------------------------------------------------
Total time for all tests: 2000.6 seconds
make: *** [ptestlong] Error 128
</pre><p>
Currently no idea what happens there...
</p>
TicketleifThu, 02 Dec 2010 21:03:35 GMT
https://trac.sagemath.org/ticket/10187#comment:145
https://trac.sagemath.org/ticket/10187#comment:145
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:138" title="Comment 138">leif</a>:
</p>
<blockquote class="citation">
<p>
Going to retry, which again will take hours...
</p>
</blockquote>
<p>
Now I get (Ubuntu 9.04 x86, gcc 4.3.3):
</p>
<pre class="wiki">The following tests failed:
sage -t -long -force_lib devel/sage/doc/en/a_tour_of_sage/index.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/bordeaux_2008/nf_introduction.rst # 8 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/interface_issues.rst # 4 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/linear_algebra.rst # 5 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/polynomials.rst # 1 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/calculus.rst # 31 doctests failed
sage -t -long -force_lib devel/sage/doc/en/constructions/plotting.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/installation/source.rst # 1 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/interfaces.rst # 18 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/latex.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/en/tutorial/tour_algebra.rst # 21 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/tutorial/interfaces.rst # 18 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/a_tour_of_sage/index.rst # 3 doctests failed
sage -t -long -force_lib devel/sage/doc/fr/tutorial/tour_algebra.rst # 20 doctests failed
sage -t -long -force_lib devel/sage/sage/combinat/perfect_matching.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/combinat/combinat.py # 10 doctests failed
sage -t -long -force_lib devel/sage/sage/geometry/lattice_polytope.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/geometry/polyhedra.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/heegner.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/schemes/elliptic_curves/ell_generic.py # 15 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/latex.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/preparser.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/functional.py # 29 doctests failed
sage -t -long -force_lib devel/sage/sage/misc/citation.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/graphs/graph_generators.py # 6 doctests failed
sage -t -long -force_lib devel/sage/sage/gsl/integration.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/modules/free_module_element.pyx # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix1.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix2.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/matrix/matrix_symbolic_dense.pyx # 40 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/power_helper.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/relation.py # 66 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/pynac.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/function.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/function_factory.py # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/ring.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/random_tests.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/constants_c.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/maxima_wrapper.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/expression_conversions.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/constants.py # 16 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/assumptions.py # 51 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/expression.pyx # 247 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/integration/integral.py # 64 doctests failed
sage -t -long -force_lib devel/sage/sage/symbolic/integration/external.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/infinity.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/fraction_field_element.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/ring.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/residue_field.pyx # 15 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/misc.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/contfrac.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/integer_ring.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/polynomial/polynomial_element.pyx # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/order.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/galois_group.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_element_quadratic.pyx # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_element.pyx # 12 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_base.pyx # 13 doctests failed
sage -t -long -force_lib devel/sage/sage/rings/number_field/number_field_rel.py # 10 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/functions.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/calculus.py # 127 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/desolvers.py # 70 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/tests.py # 24 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/functional.py # 45 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/test_sympy.py # 7 doctests failed
sage -t -long -force_lib devel/sage/sage/calculus/wester.py # 45 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/special.py # 69 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/log.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/wigner.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/min_max.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/hyperbolic.py # 9 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/transcendental.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/piecewise.py # 65 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/orthogonal_polys.py # 42 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/other.py # 19 doctests failed
sage -t -long -force_lib devel/sage/sage/functions/trig.py # 17 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/line.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/arc.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot3d/plot3d.py # 3 doctests failed
sage -t -long -force_lib devel/sage/sage/plot/plot3d/transform.pyx # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/structure/element.pyx # 5 doctests failed
sage -t -long -force_lib devel/sage/sage/structure/formal_sum.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/expect.py # 26 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/tests.py # 1 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/maxima.py # 224 doctests failed
sage -t -long -force_lib devel/sage/sage/interfaces/quit.py # 2 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/group_algebra.py # 6 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quaternion_algebra_element.py # 4 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quatalg/quaternion_algebra_element.pyx # 36 doctests failed
sage -t -long -force_lib devel/sage/sage/algebras/quatalg/quaternion_algebra.py # 8 doctests failed
sage -t -long -force_lib devel/sage/sage/modular/overconvergent/genus0.py # 19 doctests failed
sage -t -long -force_lib devel/sage/sage/modular/modform/ambient_R.py # 5 doctests failed
----------------------------------------------------------------------
Total time for all tests: 13357.2 seconds
</pre><p>
which at first glance doesn't look much different; 525 doctest errors.
</p>
TicketleifThu, 02 Dec 2010 21:10:16 GMT
https://trac.sagemath.org/ticket/10187#comment:146
https://trac.sagemath.org/ticket/10187#comment:146
<p>
(Note that on all systems vanilla Sage 4.6.1.alpha2 passes all tests.)
</p>
TicketvbraunThu, 02 Dec 2010 21:28:28 GMT
https://trac.sagemath.org/ticket/10187#comment:147
https://trac.sagemath.org/ticket/10187#comment:147
<p>
If you would tell us what the error is then that would be much more useful than a list of failed tests. All of these work fine on Fedora 14 with sage-4.6.1.alpha2 and the new maxima/ecl. My first guess would be that you forgot to apply one of the patches (been there, done that), can you double-check?
</p>
TicketleifThu, 02 Dec 2010 22:47:49 GMT
https://trac.sagemath.org/ticket/10187#comment:148
https://trac.sagemath.org/ticket/10187#comment:148
<p>
Well, I didn't attach the logs since they're huge.
</p>
<p>
I've reverted all changes and started from scratch, and now all tests pass on the Ubuntu 9.04 x86_64 machine. I have absolutely no idea what went wrong in the first two attempts; in the succeeding one I used Sage's <code>hg</code> to apply the patches, <em>after</em> installing the spkgs, and afterwards ran <code>./sage -ba-force</code> (rather than just <code>./sage -b</code>), which IMHO shouldn't be necessary.
</p>
<p>
I did apply all patches in the right order in all cases, so something else must be wrong. Never experienced similar before...
</p>
TicketdrkirkbyThu, 02 Dec 2010 23:10:28 GMT
https://trac.sagemath.org/ticket/10187#comment:149
https://trac.sagemath.org/ticket/10187#comment:149
<p>
The patches on this ticket are not so easy to apply as usual, as part of them is already in Sage 4.6.1.alpha2. What we don't have on this ticket are changes relative to 4.6.1.alpha2.
</p>
<p>
I've built <strong>sage 4.6.1.alpha1</strong> with the patches applied and the new .spkg files. This is on a Sun Ultra 27, 3.33 GHz Xeon processor running OpenSolaris 06/2009.
</p>
<pre class="wiki">----------------------------------------------------------------------
All tests passed!
Total time for all tests: 1560.4 seconds
drkirkby@hawk:~/new/sage-4.6.1.alpha1$
</pre><p>
I wonder if Leif's problems had anything to the patch process going wrong?
</p>
<p>
Dave
</p>
TicketjdemeyerThu, 02 Dec 2010 23:16:12 GMT
https://trac.sagemath.org/ticket/10187#comment:150
https://trac.sagemath.org/ticket/10187#comment:150
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:149" title="Comment 149">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
The patches on this ticket are not so easy to apply as usual, as part of them is already in Sage 4.6.1.alpha2.
</p>
</blockquote>
<p>
Really? If that's true, it was unintentional. Which patches are in sage-4.6.1.alpha2?
</p>
TicketleifThu, 02 Dec 2010 23:39:49 GMT
https://trac.sagemath.org/ticket/10187#comment:151
https://trac.sagemath.org/ticket/10187#comment:151
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:150" title="Comment 150">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:149" title="Comment 149">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
The patches on this ticket are not so easy to apply as usual, as part of them is already in Sage 4.6.1.alpha2.
</p>
</blockquote>
<p>
Really? If that's true, it was unintentional. Which patches are in sage-4.6.1.alpha2?
</p>
</blockquote>
<p>
I don't think so. I've applied all patches multiple times with <code>-v</code> and different Mercurial versions; no rejects, no moved hunks.
</p>
<hr />
<p>
One problem I ran into seems to be that when running <code>make</code> with <code>SAGE_UPGRADING=yes</code> to (safely) install spkgs the Sage library install completely ignores the current branch, and switches back to <code>sage-main</code>, such that previously applied patches "vanish".
</p>
<p>
Another odd thing I discovered is that at least on Ubuntu 9.04, <code>gcc</code> run from Sage picks up Sage's MPFR (and GMP/MPIR).
</p>
TicketleifThu, 02 Dec 2010 23:46:30 GMT
https://trac.sagemath.org/ticket/10187#comment:152
https://trac.sagemath.org/ticket/10187#comment:152
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:151" title="Comment 151">leif</a>:
</p>
<blockquote class="citation">
<p>
One problem I ran into seems to be that when running <code>make</code> with <code>SAGE_UPGRADING=yes</code> to (safely) install spkgs the Sage library install completely ignores the current branch, and switches back to <code>sage-main</code>, such that previously applied patches "vanish".
</p>
</blockquote>
<p>
... which means one has to apply patches to the Sage library <strong>after</strong> all spkgs have been installed that way.
</p>
<p>
Also, there seems to be a missing dependency for <code>libcsage</code>, i.e. SCons doesn't always rebuild it when necessary, so one has to run <code>./sage -ba-force</code>.
</p>
TicketdrkirkbyThu, 02 Dec 2010 23:49:30 GMTstatus changed
https://trac.sagemath.org/ticket/10187#comment:153
https://trac.sagemath.org/ticket/10187#comment:153
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:150" title="Comment 150">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:149" title="Comment 149">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
The patches on this ticket are not so easy to apply as usual, as part of them is already in Sage 4.6.1.alpha2.
</p>
</blockquote>
<p>
Really? If that's true, it was unintentional. Which patches are in sage-4.6.1.alpha2?
</p>
</blockquote>
<p>
I guess I must have been mistaken - perhaps my alpha2 was not "clean", though I thought I'd extracted a fresh tarball.
</p>
<p>
Anyway, several others have got all passes, and I got all passes if I apply this to sage-4.6.1.alpha1.
</p>
<p>
I would say I'd try again with sage-4.6.1.alpha2, but it is late here, and I'm not going to start a build now, as you wont get the results until I wake in the morning. I'm pretty convinced this is OK. To my knowledge, the only thing was some minor changes Leif wanted to the ECL package, and those have been addressed. Leif seemed happy, so I'm setting this to positive.
</p>
TicketdrkirkbyFri, 03 Dec 2010 00:22:48 GMT
https://trac.sagemath.org/ticket/10187#comment:154
https://trac.sagemath.org/ticket/10187#comment:154
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:151" title="Comment 151">leif</a>:
</p>
<blockquote class="citation">
<p>
Another odd thing I discovered is that at least on Ubuntu 9.04, <code>gcc</code> run from Sage picks up Sage's MPFR (and GMP/MPIR).
</p>
</blockquote>
<p>
I'm not surprised by that, as <code>LD_LIBRARY_PATH</code> gets <code>$SAGE_LOCAL/lib</code> <strong>prepended</strong> to it when sage is run..
</p>
<p>
When building gcc, the <code>configure</code> options like <code>--with-gmp=/path/to/gmp</code> only tell the first stage build of the compiler where to find the libraries. They do not hard-code the path of the libraries, though there are ways of doing that if you wish when building gcc. If your not careful, it is easy to build gcc where the first stage of the build works, as it finds the GMP and MPFR libraries, but the second stage fails. That's hit many people on Solaris systems, a they often will not have suitable versions of the libraries on the system.
</p>
<p>
Dave
</p>
<p>
Dave
</p>
TicketdrkirkbyFri, 03 Dec 2010 00:34:34 GMTdescription, summary changed
https://trac.sagemath.org/ticket/10187#comment:155
https://trac.sagemath.org/ticket/10187#comment:155
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/10187?action=diff&version=155">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Update ecl and maxima</em> to <em>Update ECL to 10.4.1 and Maxima to 5.22.1 - currently the latest releases.</em>
</li>
</ul>
<p>
I'm just changing the ticket title, to be more explicit.
</p>
TicketleifFri, 03 Dec 2010 01:04:18 GMT
https://trac.sagemath.org/ticket/10187#comment:156
https://trac.sagemath.org/ticket/10187#comment:156
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:154" title="Comment 154">drkirkby</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/10187#comment:151" title="Comment 151">leif</a>:
</p>
<blockquote class="citation">
<p>
Another odd thing I discovered is that at least on Ubuntu 9.04, <code>gcc</code> run from Sage picks up Sage's MPFR (and GMP/MPIR).
</p>
</blockquote>
<p>
I'm not surprised by that, as <code>LD_LIBRARY_PATH</code> gets <code>$SAGE_LOCAL/lib</code> <strong>prepended</strong> to it when sage is run..
</p>
</blockquote>
<p>
Yes, but I would have expected the Debian or Ubuntu developers to set the <code>RPATH</code>.
</p>
<p>
Not many people like setting <code>LD_LIBRARY_PATH</code> (which is empty outside Sage btw.).
</p>
TicketleifFri, 03 Dec 2010 06:56:42 GMT
https://trac.sagemath.org/ticket/10187#comment:157
https://trac.sagemath.org/ticket/10187#comment:157
<p>
Finally passed all tests (<code>ptestlong</code>) with Sage 4.6.1.alpha2 on
</p>
<ul><li>Ubuntu 9.04 x86 (gcc 4.3.3),
</li><li>Ubuntu 9.04 x86_64 (gcc 4.3.3), with and without the new MPIR and GMP-ECM (<a class="closed ticket" href="https://trac.sagemath.org/ticket/8664" title="enhancement: Upgrade Sage's MPIR spkg to version 2.1.3 (closed: fixed)">#8664</a> / <a class="closed ticket" href="https://trac.sagemath.org/ticket/5847" title="enhancement: Update GMP-ECM to 6.3 (closed: fixed)">#5847</a>),
</li><li>Ubuntu 10.04 x86_64 (gcc 4.4.3) with the new MPIR and GMP-ECM.
</li></ul><p>
Sorry for the noise.
</p>
<p>
</p>
TicketjdemeyerFri, 03 Dec 2010 09:38:51 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/10187#comment:158
https://trac.sagemath.org/ticket/10187#comment:158
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-4.6.1.alpha3</em>
</li>
</ul>
TicketjasonMon, 06 Dec 2010 13:25:55 GMT
https://trac.sagemath.org/ticket/10187#comment:159
https://trac.sagemath.org/ticket/10187#comment:159
<p>
I just wanted to say "Bravo!" to everyone that has diligently worked on this. Thanks for your work!
</p>
TicketmvnguMon, 06 Dec 2010 13:39:45 GMTdescription changed
https://trac.sagemath.org/ticket/10187#comment:160
https://trac.sagemath.org/ticket/10187#comment:160
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/10187?action=diff&version=160">diff</a>)
</li>
</ul>
Ticket