On Jul 5, 2010, at 4:56 PM, Kristján Valur Jónsson wrote: > I've integrated the last changes from /python/trunk and we now have a > /stackless/trunk that jives with 2.7 release!
Yay! > I didn't have any trouble to speak of with the 64 bit build, and I fixed the > test_sys.py test that was failing there. But that is probably an x64_msvc build (rather than amd64_unix), right? I notice whoever built 2.6.5 stackless for OS-X (not me I think) did not include a 64-bit variant in the universal binary... I'm just wondering whether amd64 is supposed to work.. (I just went back and the release26-maint branch also has problems with 64 bit on OS-X -- so at least it's not a merely 2.7 issue...) > In my opinion, stackless/2.7 is pretty good! > I am still working on some old time issues with garbage collection. > stackless/test/taskspeed.py crashes in debug mode and this is because of GC. > I've made progress, but it needs to be perfected. Basically, what I aim to > do is to allow tasklets that have no c state to be collectable from gc, > without awakening them (killing the tasklet). Such a tasklet ought to be > just collected. Tasklets that have C state must be killed (awakened and > unrolled) and this must happen after they have been placed in gc.garbage. > I've added features to gcmodule.c so that objects can indicate at run-time > whether they can be collected or not. I've even contributed that patch to > vanilla Python (http://bugs.python.org/issue9141) but without it meeting much > enthusiasm. FWIW - sounds good to me! > > K > >> -----Original Message----- >> From: [email protected] [mailto:stackless- >> [email protected]] On Behalf Of Jeff Senn >> Sent: 5. júlí 2010 02:46 >> To: The Stackless Python Mailing List >> Subject: Re: [Stackless] stackess for 2.7 >> >> Ok - sounds fine. >> >> More generally my 64 bit build also crashes on many of the stackless >> tests - so I suspect a general problem >> as well (possibly a platform specific one -- as they are generally, >> slightly post stack swap). >> >> I don't really rely on a 64 bit build at the moment for my work (since >> I have other dependencies that >> keep me at 32) -- is the amd64 build supposed to work? >> >> On Jul 3, 2010, at 5:18 AM, Kristján Valur Jónsson wrote: >> >>> You are right. >>> This is not a new problem, though. >>> In our working branch at CCP, we have this particular test disabled >> for this reason. >>> It could be an idea to add the python recursion guard calls even to >> safe-pickle. >>> >>> Btw, I'm not sure why Christian deemed pickling to be enough of a >> special case to warrant special pickling code with stack-spilling. >>> Perhaps pickling tasklet regularly caused such deep recursions that >> this was necessary. If that is the case, then we shoulnd't >>> impose artificial recursion limits... >>> >>> I think we ought to leave this as an open issue in the "stackless >> defect tracking database in the sky" :) >>> K >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:stackless- >>>> [email protected]] On Behalf Of Jeff Senn >>>> Sent: 1. júlí 2010 18:08 >>>> To: The Stackless Python Mailing List >>>> Subject: Re: [Stackless] stackess for 2.7 >>>> >>>> >>>> On Jul 1, 2010, at 12:08 PM, Jeff Senn wrote: >>>> >>>>> Speaking of 64bit... are you compiling a 64bit version? I am having >>>> some trouble... >>>>> In particular test_cpickle crashes (segfault) in test_issue2702 >>>> (__main__.cPickleDeepRecursive) >>>> >>>> Update on this: >>>> >>>> Note the test (an attempt to pickle a deeply nested unrealistic >> object) >>>> is designed to fail due to excessive recursion. >>>> >>>> It appears that in 64-bit mode this test only survives down to a >>>> recursion limit of about 273 (note: < 1000) before things go >> horribly >>>> wrong -- I'm guessing that the greater stack requirements of 64 bit >>>> simply cause a problem (compared to the 32-bit version) and the >>>> simplest solution is just to reduce the recursion limit for that >>>> build... (It's hard to determine the "final cause" of the crash as >> the >>>> debugger is messed up when I get there... probably crunching the >> stack? >>>> dunno...) >>>> >>>> However (caveat: as I said the pickling part of stackless is not my >>>> favorite...) it seems like the stackless bit that avoids the call to >>>> Py_EnterRecursiveCall in cPickle.c, and instead uses >> slp_safe_pickling, >>>> is sort of asking for trouble in this case. >>>> >>>> In this test (in non-stackless python), the excessive recursion of >> the >>>> cPickle module itself (calling 'save') is detected by the >>>> Py_EnterRecursiveCall check. In stackless (I think) this test is >>>> bypassed (due to the unwind of pickling) and the recursion count >> grows >>>> significantly more slowly (and only incidentally due to a deeper >> call >>>> to Py_CallObject.) >>>> >>>> I'm not sure if there is a simple and satisfying fix... >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Stackless mailing list >>>> [email protected] >>>> http://www.stackless.com/mailman/listinfo/stackless >>> >>> >>> _______________________________________________ >>> Stackless mailing list >>> [email protected] >>> http://www.stackless.com/mailman/listinfo/stackless >>> >> >> >> _______________________________________________ >> Stackless mailing list >> [email protected] >> http://www.stackless.com/mailman/listinfo/stackless > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless > _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
