Hi Volker,
This is of course also how Sage worksheets work in CoCalc (since 2014...),
unlike say Jupyter.However, there is still the problem of the time spent to
start the first process for a new project/account/user.These are precisely
the sort of details that
Hi Volker,
This is of course also how Sage worksheets work in CoCalc (since 2014...),
unlike say Jupyter.However, there is still the problem of the time spent to
start the first process for a new project/account/user.These are precisely
the sort of details that
Not sure if I unterstand the question. You wait and then you fork() new
processes as needed. There is no ready-made thing in Sage for that purpose
afaik (is that the question?)
On Saturday, August 26, 2017 at 9:47:02 PM UTC+2, Samuel Lelievre wrote:
>
> Volker wrote:
>
> > For server use you sh
Hi,
Le 26/08/2017 à 22:57, Dr. David Kirkby (Kirkby Microwave Ltd) a écrit :
> I'm not a mathematician, but believe 0^0 is undefined.
You can either consider 0^0 to be undefined or that it is 1 by
convention : both are "correct", and neither should be considered a bug.
Snark on #debian-science
On 26 August 2017 at 01:40, David Roe wrote:
> This is not a bug. If you look at the documentation for Integer.__pow__,
> you'll see "For consistency with Python and MPFR, 0^0 is defined to be 1 in
> Sage."
> David
>
I'm not a mathematician, but believe 0^0 is undefined. Sagemath being
consiste
Just to leave a trace in case someone would hit the same issue: I just
upgraded from Ubuntu 16.4 to 17.4, and my sage (built from source)
would not start afterward:
from sage.matrix.matrix_space import MatrixSpace
File
"/opt/sage-git2/local/lib/python2.7/site-packages/sage/matrix/matrix_sp
Volker wrote:
> For server use you should be forking processes from a zygote process,
this is how chrome works.
Thanks Volker for pointing that out. Can you remind us how one does that?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubsc
I agree that startup on a warm cache is mostly a kernel / filesystem ram
cache benchmark. The actual drive hardware is irrelevant, but background
processes hitting the disk cache at the same time do matter. On a warm
cache and without background IO the sage -startuptime (i.e. importing
sage.all
Shorter traceback, with the same issue. This has probably something to do
with the behaviour of weak-cahe (which is different with python3)
Traceback (most recent call last):
File
"/home/chapoton/sage3/local/lib/python3.6/site-packages/sage/rings/polynomial/polynomial_ring_constructor.py"
, l
