[Stackless] stackess for 2.7

Jeff Senn senn at maya.com
Wed Jun 30 05:23:55 CEST 2010


The Lib/test ones were indeed compatible.  I also have changes:

to the build environment for unix/os-x:

M       configure
M       configure.in
M       Makefile.pre.in
M       Mac/BuildScript/build-installer.py

Yes, Richard, I'll commit these at some point soon.

M       setup.py

This adds the stackless dependency to the build for the cPickle extension:

-------------snip--------------
Index: setup.py
===================================================================
--- setup.py	(revision 82382)
+++ setup.py	(working copy)
@@ -549,7 +549,7 @@
 
         # cStringIO and cPickle
         exts.append( Extension('cStringIO', ['cStringIO.c']) )
-        exts.append( Extension('cPickle', ['cPickle.c']) )
+        exts.append( Extension('cPickle', ['cPickle.c', '../Stackless/pickling/safe_pickle.c']) )
 
         # Memory-mapped files (also works on Win32).
         if platform not in ['atheos']:
-------------snip--------------

M       Objects/descrobject.c

This one is necessary for gcc, but maybe not for windows. The diff rectifies
a conflicting static/non-static decl of 2 type structs for the stackless version 
(I also cleaned an unused variable, "pnew"):

-------------snip--------------
Index: Objects/descrobject.c
===================================================================
--- Objects/descrobject.c	(revision 82382)
+++ Objects/descrobject.c	(working copy)
@@ -478,7 +478,10 @@
 
 STACKLESS_DECLARE_METHOD(&PyClassMethodDescr_Type, tp_call)
 
-static PyTypeObject PyMemberDescr_Type = {
+#ifndef STACKLESS
+static
+#endif
+PyTypeObject PyMemberDescr_Type = {
     PyVarObject_HEAD_INIT(&PyType_Type, 0)
     "member_descriptor",
     sizeof(PyMemberDescrObject),
@@ -515,7 +518,10 @@
     (descrsetfunc)member_set,                   /* tp_descr_set */
 };
 
-static PyTypeObject PyGetSetDescr_Type = {
+#ifndef STACKLESS
+static
+#endif
+PyTypeObject PyGetSetDescr_Type = {
     PyVarObject_HEAD_INIT(&PyType_Type, 0)
     "getset_descriptor",
     sizeof(PyGetSetDescrObject),
@@ -1254,7 +1260,6 @@
                 PyObject *doc)
 {
     propertyobject *pold = (propertyobject *)old;
-    propertyobject *pnew = NULL;
     PyObject *new, *type;
 
     type = PyObject_Type(old);
-------------snip--------------

And these last have messed up line endings compared to regular python
(i.e. you could just revert them to the version in the regular python trunk)

M       Lib/email/test/data/msg_45.txt
M       Lib/email/test/data/msg_46.txt
M       Lib/test/xmltestdata/test.xml.out
M       Lib/test/xmltestdata/simple-ns.xml
M       Lib/test/xmltestdata/simple.xml
M       Lib/test/xmltestdata/test.xml


On Jun 29, 2010, at 7:03 PM, Kristján Valur Jónsson wrote:

> Ah, I actually committed a set of fixes today.  See if it matches what you have done.  I found the pickling problem, turned out to be a problem with the classes in the unittest framework, not a pickle bug as such.
> 
> I'm currently in the process of integrating more changes from /python/trunk.  There are also problems with stackless/test/taskspeed.py that I'm trying to clear up.
> 
> K
> 
>> -----Original Message-----
>> From: stackless-bounces at stackless.com [mailto:stackless-
>> bounces at stackless.com] On Behalf Of Jeff Senn
>> Sent: 29. júní 2010 12:34
>> To: The Stackless Python Mailing List
>> Subject: Re: [Stackless] stackess for 2.7
>> 
>> I guess I can agree (except for perhaps the "fortuitously" :-) )
>> 
>> Any word on whether test_functools and test_pickletools work for you?
>> 
>> Should I commit what I have so far?
>> 
>> On Jun 29, 2010, at 5:46 AM, Kristján Valur Jónsson wrote:
>> 
>>> I would agree, except that we have been doing it like this for aeons
>> and changing this would probably break code.
>>> There is code out there that silently checks for SystemExit and
>> reraises those exceptions, and fortuitously works for TaskletExit too.
>>> On the flip side, there is code in pythonrun.c (IIRC) that checks for
>> SystemExit, but which we had to patch to ignore TaskletExits...
>>> 
>>> We best leave this alone and worry about it later.
>>> K
>>> 
>>>> -----Original Message-----
>>>> From: stackless-bounces at stackless.com [mailto:stackless-
>>>> bounces at stackless.com] On Behalf Of Jeff Senn
>>>> Sent: 25. júní 2010 12:43
>>>> To: The Stackless Python Mailing List
>>>> Subject: Re: [Stackless] stackess for 2.7
>>>> 
>>>> 
>>>> On Jun 25, 2010, at 6:54 AM, Kristján Valur Jónsson wrote:
>>>> 
>>>>> Excellent.
>>>>> I'll have a look when I'm able.
>>>>> 
>>>>> Wrt TaskletExit, yes it makes perfect sense.  Like SystemExit, it
>> is
>>>> an exception that you normally don't want to handle.  So exception
>>>> clauses like:
>>>>> try:
>>>>>  do_stuff()
>>>>> except Exception:
>>>>>  handle_error()
>>>>> 
>>>>> will work as expected, and yet allow tasklets to be killed without
>>>> fuss.
>>>> 
>>>> Agree... though I was talking about BaseException (rather then
>>>> Exception).
>>>> i.e. do we want this:
>>>> 
>>>> BaseException
>>>> +-- SystemExit
>>>> +-- TaskletExit
>>>> +-- KeyboardInterrupt
>>>> +-- GeneratorExit
>>>> +-- Exception
>>>>     +-- StopIteration
>>>>     +-- StandardError
>>>>     |    +-- BufferError
>>>>      ...
>>>> 
>>>> Or
>>>> 
>>>> BaseException
>>>> +-- SystemExit
>>>>     +-- TaskletExit
>>>> +-- KeyboardInterrupt
>>>> +-- GeneratorExit
>>>> +-- Exception
>>>>     +-- StopIteration
>>>>     +-- StandardError
>>>>     |    +-- BufferError
>>>>      ...
>>>> 
>>>> Unless there is some good reason for the latter, I think we want the
>>>> former, no?
>>>> I can't think of a good reason -- and it might be confusing to
>> someone
>>>> who is doing something
>>>> where they catch SystemExit (probably in a 'finally'), expecting to
>> see
>>>> it only once...
>>>> 
>>>> 
>>>>> 
>>>>> K
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: stackless-bounces at stackless.com [mailto:stackless-
>>>>>> bounces at stackless.com] On Behalf Of Jeff Senn
>>>>>> Sent: 24. júní 2010 16:13
>>>>>> To: The Stackless Python Mailing List
>>>>>> Subject: Re: [Stackless] stackess for 2.7
>>>>>> 
>>>>>> Progress - it's now building, but I do see regular python test
>> fails
>>>>>> (compared to stock 2.7.rc2) on:
>>>>>> 
>>>>>> test_email test_functools test_pep352 test_pickletools test_sax
>>>>>> test_sys test_tk test_ttk_guionly
>>>>>> 
>>>>>> I'm looking into them.  In particular so far:
>>>>>> 
>>>>>> test_pep352 fails because a text file in the test is missing a
>>>>>> reference to TaskletExit.
>>>>>> Easy to fix, though it also raises an issue about whether
>>>> TaskletExit
>>>>>> should really be derived
>>>>>> from SystemExit or the BaseException class.
>>>>>> 
>>>>>> test_functools is related the test_pickletools fail which might
>> have
>>>>>> something to do with
>>>>>> the other pickling problem that Kristjan mentioned.  K- Does
>>>>>> test_pickletools succeed for you?
>>>>>> The problem seems to have to do with some wrapping of a function
>> by
>>>>>> stackless...
>>>>>> 
>>>>>> test_email and text_sax have to do with line endings (\n vs \r\n)
>> --
>>>>>> which is odd and troublesome...
>>>>>> and I'm looking more...
>>>>>> 
>>>>>> test_sys has to do with the slot wrapper object size (for
>>>> int.__add__)
>>>>>> being 44 bytes instead of 40.
>>>>>> (This might be correct for stackless -- it appears this test is
>>>>>> commented out in release26_maint)
>>>>>> 
>>>>>> and I haven't check the tk stuff yet at all...
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Stackless mailing list
>>>>> Stackless at stackless.com
>>>>> http://www.stackless.com/mailman/listinfo/stackless
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Stackless mailing list
>>>> Stackless at stackless.com
>>>> http://www.stackless.com/mailman/listinfo/stackless
>>> 
>>> 
>>> _______________________________________________
>>> Stackless mailing list
>>> Stackless at stackless.com
>>> http://www.stackless.com/mailman/listinfo/stackless
>>> 
>> 
>> 
>> _______________________________________________
>> Stackless mailing list
>> Stackless at stackless.com
>> http://www.stackless.com/mailman/listinfo/stackless
> 
> 
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
> 




More information about the Stackless mailing list