On Monday, May 27, 2019 at 11:40:00 AM UTC-7, Tracy Hall wrote:
>
> Thanks for the reply. That's disappointing—I'm not crazy about the idea of
> spawning a hundred million Sage processes, most of them to do about 1/50th
> of a second's worth of calculation, just because a few of them will need
On 27.05.19 20:40, Tracy Hall wrote:
> If anyone is curious to see an example
> [...]
> sage: for ii in range(1):
> : alarm(10)
> : try:
> : if prod(P.gens())^2 in anideal:
> : cancel_alarm()
> [...]
> : except AlarmInterrupt:
> :
On 27.05.19 18:08, Jeroen Demeyer wrote:
> On 2019-05-27 16:11, Tracy Hall wrote:
>> in particular it seems to have undefined
>> behavior in subsequent calls after it has been interrupted by alarm().
>
> This is simply a fact of life and not really considered to be a bug. You
> should not rely on
Thanks for the reply. That's disappointing—I'm not crazy about the idea of
spawning a hundred million Sage processes, most of them to do about 1/50th
of a second's worth of calculation, just because a few of them will need to
be timed out before they take hours or days or run out of memory. I'm
On 2019-05-27 16:11, Tracy Hall wrote:
in particular it seems to have undefined
behavior in subsequent calls after it has been interrupted by alarm().
This is simply a fact of life and not really considered to be a bug. You
should not rely on the fact that interruptions (using either CTRL-C
Hello,
Has this ever been addressed? Five years later this is still happening.
Something appears to be fundamentally broken in the way that Sage is using
the Singular C library; in particular it seems to have undefined behavior
in subsequent calls after it has been interrupted by alarm().
