On 2014-09-28 22:03, Volker Braun wrote:
The threshold is a certain fraction of the total doctest time, so it
takes the relative speed of computers into account.
But it wrongly assumes that doctest time scales linearly with computer
speed.
--
You received this message because you are
On Tuesday, September 30, 2014 11:37:04 AM UTC+1, Jeroen Demeyer wrote:
But it wrongly assumes that doctest time scales linearly with computer
speed.
Sure. At the end of the day, it is basically impossible to predict how long
a piece of code is going to take to run on a modern computer
Op maandag 29 september 2014 03:51:18 UTC+2 schreef François:
Anyone else see doctest failure of the kind:
sage -t --long /usr/share/sage/src/sage/symbolic/expression.pyx
**
File
This is some more fallout from #16858. Jeroen, do you already have a
followup ticket for numerical noise?
On Saturday, September 27, 2014 9:51:46 PM UTC+1, Justin C. Walker wrote:
On Sep 27, 2014, at 07:51 , Volker Braun wrote:
As usual, get the updated develop git branch.
On Ubuntu 14.04 LTS Opteron, (a SageMathCloud node), I get numerical
noise failures, as alluded to above:
sage -t --long --warn-long 57.7
src/sage/rings/polynomial/polynomial_element.pyx # 2 doctests failed
sage -t --long --warn-long 57.7 src/sage/rings/real_double.pyx # 2
doctests failed
sage
On 28 September 2014 17:47, John Cremona john.crem...@gmail.com wrote:
I am getting a doctest failure in src/doc/en/bordeaux_2008/elliptic_curves.rst
and I wonder if others can confirm or deny. You should have
sage: C = CremonaDatabase()
sage: C[37]
{'allcurves': {'a1': [[0, 0, 1, -1, 0],
On 2014-09-28 14:46, Volker Braun wrote:
This is some more fallout from #16858. Jeroen, do you already have a
followup ticket for numerical noise?
http://trac.sagemath.org/ticket/17063
--
You received this message because you are subscribed to the Google Groups
sage-release group.
To
On Sunday, September 28, 2014 5:54:23 PM UTC+1, Stein William wrote:
Also, all those by default warning slow doctests things in the log
(on doing make ptestlong) are annoying...
Good, I hope somebody will clean up some of the unnecessarily long doctests
--
You received this message
Good, I hope somebody will clean up some of the unnecessarily long doctests
This is not the only occasion for which we need something between
reporting an error or saying nothing.
What about a bit red warning when running the tests on a file, that
would show the list of very long doctests ?
On Sun, Sep 28, 2014 at 11:49 AM, Volker Braun vbraun.n...@gmail.com wrote:
On Sunday, September 28, 2014 5:54:23 PM UTC+1, Stein William wrote:
Also, all those by default warning slow doctests things in the log
(on doing make ptestlong) are annoying...
Good, I hope somebody will clean up
The threshold is a certain fraction of the total doctest time, so it takes
the relative speed of computers into account.
Really, there is no point in having tests run for minutes just because you
can. Also, if you want to debug things then disabling optimization and can
quickly lead to
On Sun, 28 Sep 2014 09:53:42 William A Stein wrote:
On Ubuntu 14.04 LTS Opteron, (a SageMathCloud node), I get numerical
noise failures, as alluded to above:
sage -t --long --warn-long 57.7
src/sage/rings/polynomial/polynomial_element.pyx # 2 doctests failed
sage -t --long --warn-long 57.7
On Sun, Sep 28, 2014 at 1:03 PM, Volker Braun vbraun.n...@gmail.com wrote:
The threshold is a certain fraction of the total doctest time, so it takes
the relative speed of computers into account.
When I did make ptestlong (with MAKE=make -j12 and 12 cores), it says
sage -t --long
Anyone else see doctest failure of the kind:
sage -t --long /usr/share/sage/src/sage/symbolic/expression.pyx
**
File /usr/share/sage/src/sage/symbolic/expression.pyx, line 9349, in
sage.symbolic.expression.Expression.solve
Failed
On Sat, Sep 27, 2014 at 4:51 PM, Volker Braun vbraun.n...@gmail.com wrote:
Note: boxen will be reinstalled soon, and the source tarball link might be
unavailable. Watch this thread for an updated url ;-)
should one of us put it on the mirrors?
-- harald
--
You received this message because
On 27 September 2014 16:32, Harald Schilly harald.schi...@gmail.com wrote:
On Sat, Sep 27, 2014 at 4:51 PM, Volker Braun vbraun.n...@gmail.com wrote:
Note: boxen will be reinstalled soon, and the source tarball link might be
unavailable. Watch this thread for an updated url ;-)
should one of
Is anyone still building development pre-releases from tarballs
instead of pulling from the git repository?
Yes. That’s the only way I do a “vanilla” build. I’ll admit I only do
it occasionally these days.
And also the only way if your machine does not have 'git' installed
It's the only simple way from my point of view when you want to build on a
machine without internet access.
Much easier that copying a non-built git install with a full upstream
directory.
On top of that, make download pulls huge tarballs (including some of John
database if IIRC :) ).
On
On 27 September 2014 19:53, Jean-Pierre Flori jpfl...@gmail.com wrote:
It's the only simple way from my point of view when you want to build on a
machine without internet access.
Of course, and I certainly want that to continue to be possible,
though I suspect that those who are developing use
On Sep 27, 2014, at 07:51 , Volker Braun wrote:
As usual, get the updated develop git branch. Alternatively,
self-contained source tarball is here:
http://boxen.math.washington.edu/home/release/sage-6.4.beta4.tar.gz
Built from the tarball on two OS X systems (10.6.8/Dual 6-core Xeons;
On 2014-09-27 20:53, Jean-Pierre Flori wrote:
It's the only simple way from my point of view when you want to build on
a machine without internet access.
+1
I have also used it for this reason.
--
You received this message because you are subscribed to the Google Groups
sage-release group.
21 matches
Mail list logo
