[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

Hi Nils, On 2012-09-07, Nils Bruin wrote: > I don't think this is happening in your present example, by the way. Indeed, changing _eval_line as I suggested does not solve the problem. Cheers, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" grou

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

First attempt at scheduling alarms a little cleaner: http://trac.sagemath.org/sage_trac/ticket/13437 In hindsight, I don't think this ever comes into play for the doctest you're looking at. There, timeout==0, so p_iter_fork never schedules SIGALRMs. The signal that is interfering must be coming f

[sage-devel] wierd behaviour from sagepad.org patchbot

Hi! The sagepad.org patchbot Fedora/17/x86_64/3.4.6-2.fc17.x86_64/sagepad.orgseems to be depressed. It is unhappy with two unrelated tickets I'm involved in (12943, which is trivial, and

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

On Sep 6, 9:00 am, Simon King wrote: > [Errno 4] Interrupted system call OK, here's at least a snippet that produces the relevant error message: sage: import signal sage: import sys sage: def handler(a,b): : print "signal handled" : sage: signal.signal(signal.SIGALRM,handler) 0 s

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

On Sep 6, 2:40 pm, Simon King wrote: >   def _eval_line(self,...): >       if self.locked: >           raise RuntimeError, "%s is locked - preventing a nested call"%self >       self.locked=True You'd need an atomic semaphore for that. And in fact, in the presence of a fork, a semaphore that woul

[sage-devel] sage 5.2 build failed - some python module libraries were not installed

I tried to build sage 5.2 from source but it failed when installing python-2.7. I figured that python did not find some modules since they were actually not installed (but they were built!) into the sage tree. Here is a relevant part of install.log: make[2]: Leaving directory `/home/sage/sage-5.2

Re: [sage-devel] This year's bug days

Hi, On Fri, Sep 7, 2012 at 12:09 AM, William Stein wrote: > On Wed, Sep 5, 2012 at 6:41 PM, Minh Nguyen wrote: >> On Thu, Sep 6, 2012 at 10:11 AM, William Stein wrote: >>> Due to generous funding for this purpose, I'm planning to again >>> organize 4 Bug Days in the next year, and would like to

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

PS: On 2012-09-06, Simon King wrote: > And nested pexpect call will lock the interface. I think I had to deal with that kind of things one or two years ago, with garbage collection of SingularElement, if I recall correctly. It makes me wonder: Shouldn't certain basic pexpect methods (such as, i

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

Hi Nils, On 2012-09-06, Nils Bruin wrote: > We've seen before that invalidated expect interfaces can interact > unexpectedly with weakreffed stuff in entirely unrelated places. grep weak -R sage/interfaces told me: sage/interfaces/expect.py: quit.expect_objects.append(weakref.ref(self)) and

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

On Sep 6, 1:48 pm, Simon King wrote: > > We've seen before that invalidated expect interfaces can interact > > unexpectedly with weakreffed stuff in entirely unrelated places. > > Is it known how the interaction occurs? Is there a ticket or an example > explaining the relation? The issue we ran

Re: [sage-devel] Strange performance (bug?) computing a specific determinant

Interesting! I have also noticed that if I just slightly modify the matrix m2, it again works efficiently. Will someone direct the pariGP guys to this issue? On Thursday, 6 September 2012 17:03:59 UTC+2, D. S. McNeil wrote: > > > That said, I am wondering if this is perhaps a bug in the default

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

Hi Nils! On 2012-09-06, Nils Bruin wrote: >> And perhaps a decisive question: Do the parallel computations have >> anything to do with weak references? Are instances of >> UniqueRepresentation involved? Or UniqueFactory? These are changed by my >> patches. > > Not that I could find. However, the

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

On Sep 6, 9:00 am, Simon King wrote: > sage: oddprime_factors.precompute(range(1,100), 4) > [Errno 4] Interrupted system call [...] > Since precompute() launches a parallel computation, I could imagine that > the interrupted system call is related with that. But I am no expert. OK, you're ending

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

Hi! On 2012-09-06, Simon King wrote: > At least the problem arises on bsd.math (where I have an account), while > the other problems were mainly found on Volker's patchbot. But that's > the only good news. Hope increases: Running the failing test in an interactive session does normally not repro

[sage-devel] Re: Can we teach the doctesting framework to check EINTR and retry?

Hi Jeroen! On 2012-09-06, Jeroen Demeyer wrote: > Regarding #715: I think the "interrupted system call" is a consequence > of the problem, not the problem itself. Where did that signal come from > in the first place? I have absolutely no idea whatsoever. Worse: Meanwhile I've run out of ideas h

Re: [sage-devel] Can we teach the doctesting framework to check EINTR and retry?

Regarding #715: I think the "interrupted system call" is a consequence of the problem, not the problem itself. Where did that signal come from in the first place? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email t

Re: [sage-devel] Strange performance (bug?) computing a specific determinant

> That said, I am wondering if this is perhaps a bug in the default > implementation of determinant()? > It seems strange to me that it takes 8 minutes to compute a determinant of a > 34x34 matrix while other algorithms do it within a second. Yeah, it looks like pari's Gauss-Bareiss takes foreve

[sage-devel] Can we teach the doctesting framework to check EINTR and retry?

Hi! Since a couple of weeks, I am chasing Heisenbugs related with my weak cache patches (see #715, #11521, #12313, #11521, #12215). In the case of #715+#11521, one test fails like this: sage -t "devel/sage/sage/misc/cachefunc.pyx" The doctested process was killed by signal 11 But it appears

Re: [sage-devel] This year's bug days

On Wed, Sep 5, 2012 at 6:41 PM, Minh Nguyen wrote: > Hi William, > > On Thu, Sep 6, 2012 at 10:11 AM, William Stein wrote: >> Due to generous funding for this purpose, I'm planning to again >> organize 4 Bug Days in the next year, and would like to start a thread >> to discuss what/when/where/how

Re: [sage-devel] Re: This year's bug days

Hi On 6 September 2012 15:08, William Stein wrote: > > > On Thursday, September 6, 2012, Martin Albrecht < > martinralbre...@googlemail.com> wrote: > > +1 for having them in Seattle proper. I liked Wallace Falls but there's > a part > > of me who enjoys the fact that Sage/Bug/Dev Days are in Sea

[sage-devel] Re: This year's bug days

On Thursday, September 6, 2012, Martin Albrecht < martinralbre...@googlemail.com> wrote: > +1 for having them in Seattle proper. I liked Wallace Falls but there's a part > of me who enjoys the fact that Sage/Bug/Dev Days are in Seattle. In any case, > it has to be in the USA, right? No, it could b

[sage-devel] Strange performance (bug?) computing a specific determinant

Consider the following program sage: G = graphs.OddGraph(4) sage: G.spanning_trees_count() 336140 It takes approximately 8 minutes to compute the number of spanning trees using this method. However, the number of spanning trees can be computed directly from the charpoly of the respe

[sage-devel] Re: [semi-OT] a social network for reseachers

I didn't know about the projects, but well. Here we go: https://www.researchgate.net/project/Sage_Mathematical_Software_System/ H -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. T

[sage-devel] Re: Re: This year's bug days

I heard that there will probably be another GAP/Singular joint meeting in the spring. Maybe one could turn it into a menage a trois? (sorry couldn't resist) Though the meeting place would then be in Europe, I guess. For the record, we have plenty of space in Dublin. Just not a lot of spare fun

[sage-devel] Re: Re: This year's bug days

+1 for having them in Seattle proper. I liked Wallace Falls but there's a part of me who enjoys the fact that Sage/Bug/Dev Days are in Seattle. In any case, it has to be in the USA, right? On Thursday 06 Sep 2012, Rob Beezer wrote: > On Wednesday, September 5, 2012 5:12:14 PM UTC-7, William wrot