From greg.ewing at canterbury.ac.nz  Thu May  1 00:21:25 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 01 May 2008 10:21:25 +1200
Subject: [Cython] [Pyrex] pyrex problems
In-Reply-To: <5533c3c80804211621p39aec737lb31a2dd76cc5f2b5@mail.gmail.com>
References: <5533c3c80804211527o32568558sea7961803c79711c@mail.gmail.com>
	<85e81ba30804211612i3e38bebw5a74825815def96d@mail.gmail.com>
	<5533c3c80804211621p39aec737lb31a2dd76cc5f2b5@mail.gmail.com>
Message-ID: <4818F0E5.70101@canterbury.ac.nz>

On Mon, Apr 21, 2008 at 3:27 PM, Marco Zanger <marcozanger at gmail.com
<mailto:marcozanger at gmail.com>> wrote:

>  ctypedef struct cGCoptimization "GCoptimization":
>    EnergyType expansionIter "expansion"(int max_num_iterations)
>

You need to declare the member functions as function
pointers, e.g.

   ctypedef struct cGCoptimization "GCoptimization":
     EnergyType (*expansionIter "expansion")(int max_num_iterations)

-- 
Greg

From greg.ewing at canterbury.ac.nz  Thu May  1 00:24:37 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 01 May 2008 10:24:37 +1200
Subject: [Cython] pxi or pxd for numpy?
In-Reply-To: <96de71860804241417i4ffa5b2bm7b663b3c4f34b273@mail.gmail.com>
References: <6ce0ac130804241316p56006278y8319e49db10eb7be@mail.gmail.com>
	<96de71860804241417i4ffa5b2bm7b663b3c4f34b273@mail.gmail.com>
Message-ID: <4818F1A5.3080907@canterbury.ac.nz>

On Thu, Apr 24, 2008 at 1:16 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:

> The only way I can get all this to work is the rename numpy.pxi ->
> c_numpy.pxd and use cimport.  Then all works well.  But, this seems to
> go against the recommendation that pxd files should not be used for
> this purpose.

What recommendation are you talking about? Using a pxd file
to provide a namespace is fine as far as I'm concerned.
It's one of the things they were invented for.

-- 
Greg

From ellisonbg.net at gmail.com  Thu May  1 00:52:56 2008
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 30 Apr 2008 16:52:56 -0600
Subject: [Cython] pxi or pxd for numpy?
In-Reply-To: <4818F1A5.3080907@canterbury.ac.nz>
References: <6ce0ac130804241316p56006278y8319e49db10eb7be@mail.gmail.com>
	<96de71860804241417i4ffa5b2bm7b663b3c4f34b273@mail.gmail.com>
	<4818F1A5.3080907@canterbury.ac.nz>
Message-ID: <6ce0ac130804301552y62186885i208b0b262452dd9c@mail.gmail.com>

>  What recommendation are you talking about? Using a pxd file
>  to provide a namespace is fine as far as I'm concerned.
>  It's one of the things they were invented for.

Previously, (on this list and at an in person meeting of Sage devs)
some people were saying that .pxi files should be used for this
purpose.  Because of these discussions, numpy.pxd was renamed
numpy.pxi, but now this looks like a bad decision.

>  --
>  Greg
>

From greg.ewing at canterbury.ac.nz  Thu May  1 01:08:36 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 01 May 2008 11:08:36 +1200
Subject: [Cython] pxi or pxd for numpy?
In-Reply-To: <6ce0ac130804301552y62186885i208b0b262452dd9c@mail.gmail.com>
References: <6ce0ac130804241316p56006278y8319e49db10eb7be@mail.gmail.com>
	<96de71860804241417i4ffa5b2bm7b663b3c4f34b273@mail.gmail.com>
	<4818F1A5.3080907@canterbury.ac.nz>
	<6ce0ac130804301552y62186885i208b0b262452dd9c@mail.gmail.com>
Message-ID: <4818FBF4.4010808@canterbury.ac.nz>

Brian Granger wrote:

> Previously, (on this list and at an in person meeting of Sage devs)
> some people were saying that .pxi files should be used for this
> purpose.  Because of these discussions, numpy.pxd was renamed
> numpy.pxi, but now this looks like a bad decision.

Indeed, I would say the opposite. You should almost
*never* use a .pxi file for anything.

The reason is the same reason that "import *" is almost
always a bad idea. When you cimport a name, it's easy
to find out where it came from, but if you get it by
including a .pxi, it can be a lot harder.

The 'include' statement is only present in Pyrex mostly
for historical reasons. If I had invented 'cimport'
earlier, it might never have existed at all.

-- 
Greg

From wstein at gmail.com  Thu May  1 01:15:59 2008
From: wstein at gmail.com (William Stein)
Date: Wed, 30 Apr 2008 16:15:59 -0700
Subject: [Cython] pxi or pxd for numpy?
In-Reply-To: <6ce0ac130804301552y62186885i208b0b262452dd9c@mail.gmail.com>
References: <6ce0ac130804241316p56006278y8319e49db10eb7be@mail.gmail.com>
	<96de71860804241417i4ffa5b2bm7b663b3c4f34b273@mail.gmail.com>
	<4818F1A5.3080907@canterbury.ac.nz>
	<6ce0ac130804301552y62186885i208b0b262452dd9c@mail.gmail.com>
Message-ID: <85e81ba30804301615t95e5d1excd279c0d2ca93aec@mail.gmail.com>

On Wed, Apr 30, 2008 at 3:52 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> >  What recommendation are you talking about? Using a pxd file
>  >  to provide a namespace is fine as far as I'm concerned.
>  >  It's one of the things they were invented for.
>
>  Previously, (on this list and at an in person meeting of Sage devs)
>  some people were saying that .pxi files should be used for this
>  purpose.  Because of these discussions, numpy.pxd was renamed
>  numpy.pxi, but now this looks like a bad decision.
>

It's me.     I gave them some advice about using pxi versus
pxd files at Sage Days 8, but I did not actually *look* at numpy.pxd
before giving said advice.    Clearly I was wrong.   Sorry for
any confusion caused by my offhand comment.

 -- William

From robertwb at math.washington.edu  Thu May  1 03:17:31 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 30 Apr 2008 18:17:31 -0700
Subject: [Cython] __getattribute__
In-Reply-To: <20080430004208.GJ15181@tilt>
References: <20080430004208.GJ15181@tilt>
Message-ID: <5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>

On Apr 29, 2008, at 5:42 PM, Peter Todd wrote:

> Is there a __getattribute__ work-alike in Cython?
>
> Essentially I need direct control over an objects tp_getattro and
> tp_setattro slots to implement a wrapper class. Specificly
> wrapped.__class__ should go to the wrapped objects class attribute,  
> not
> the wrapping objects __class__ attribute.
>
> __getattr__ outputs C-source that includes a call to
> PyObject_GenericGetAttr first, and won't run my code if that call
> succeeds.
>
> Thanks,
>
> Peter

Not that I'm aware of, though I'd imagine that implementing  
__getattribute__ (if it exists) as being called at the top of this  
function would be fairly easy to do. One would want to match Python  
symantics exactly.

- Robert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/cython-dev/attachments/20080430/e5d1c3c1/attachment-0001.pgp 

From robertwb at math.washington.edu  Thu May  1 03:49:09 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 30 Apr 2008 18:49:09 -0700
Subject: [Cython] Porting the Docs
In-Reply-To: <20080430153918.GA6561@giton>
References: <20080426000805.GA5117@basestar> <20080430153918.GA6561@giton>
Message-ID: <AD59527C-2783-4979-BDD5-42101EE10B23@math.washington.edu>

On Apr 30, 2008, at 8:39 AM, Gabriel Gellner wrote:

> So I have finished the first rough mockup, which mainly consists of  
> getting
> the markup correct. There are still some rough edges, mainly with  
> tables, and
> some of the latex output, but in the spirit of release early  
> release often ;-)
>
> Check out the html at:
> http://www.mudskipper.ca/cython-doc
>
> Get the pdf at:
> http://www.mudskipper.ca/cython.pdf
>
> And finally get the source at:
> http://www.mudskipper.ca/cython_doc.tar.gz
> or
> http://www.mudskipper.ca/cython_doc.zip
>
> Again I would appreciate any comments on if I am screwing up  
> authorship. Down
> the road I think it would be good to attribute everything to the  
> 'Cython Doc
> Team' and have a page that lists contributers. To do this we should  
> make the
> license and authorship on the wiki more explicit. Tell me what you  
> think? I am
> no lawyer, and certainly don't want to piss anyone off who has put  
> the hard
> work into documenting either cython or pyrex.
>
> My plan for the next steps (in order of importance, any comments):
> - Make a PyGments lexer for cython/pyrex so we get nice color coding.
> - Fix up the latex style file so that boxes are not messed up when  
> we have
>   code examples.
> - Put on my writing hat, and do an overhaul of the structure of the  
> docs so
>   that it is faster to navigate. I will be using the python doc  
> structure as a
>   reference.
> - Get some simple howto's written.
> - Thinking if there is an easy way to test the cython code in the  
> docs so that
>   I can ensure accuracy.

Thanks again for putting these all together in a nice form. While  
browsing I noticed some inaccuracies (often just dealing with the  
differences between Cython and Pyrex). Should I send them directly to  
you, or should we set up some revision control (need not be  
centralized).

- Robert


From pete at petertodd.org  Thu May  1 03:41:07 2008
From: pete at petertodd.org (Peter Todd)
Date: Wed, 30 Apr 2008 21:41:07 -0400
Subject: [Cython] __getattribute__
In-Reply-To: <5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>
References: <20080430004208.GJ15181@tilt>
	<5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>
Message-ID: <20080501014107.GK15181@tilt>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 30, 2008 at 06:17:31PM -0700, Robert Bradshaw wrote:
> On Apr 29, 2008, at 5:42 PM, Peter Todd wrote:
> 
> >Is there a __getattribute__ work-alike in Cython?
> >
> >Essentially I need direct control over an objects tp_getattro and
> >tp_setattro slots to implement a wrapper class. Specificly
> >wrapped.__class__ should go to the wrapped objects class attribute,  
> >not
> >the wrapping objects __class__ attribute.
> >
> >__getattr__ outputs C-source that includes a call to
> >PyObject_GenericGetAttr first, and won't run my code if that call
> >succeeds.
> >
> >Thanks,
> >
> >Peter
> 
> Not that I'm aware of, though I'd imagine that implementing  
> __getattribute__ (if it exists) as being called at the top of this  
> function would be fairly easy to do. One would want to match Python  
> symantics exactly.

Thanks for the reply.

I've been looking at the Cython source myself, and it looks doable, I'll
put some effort into implementing it. From what I can see I'd be
updating generate_getattro_function() to do a scope.lookup_here() on
'__getattribute__' first, if that succeeds, output code to call it,
otherwise go on to the existing code. With the additional complication
that if __getattribute__ is defined, as well as __getattr__, the latter
must be called if the former raises AttributeError.


Another question is I noticed that the latest cython-devel code emits
warnings on usage of __new__, saying to use __cinit__ instead. I take it
there is planned work to make __new__ more like Python's __new__ and
have it create the object as well? Again, that's another feature I could
really use.


FWIW I'm writing a electrical design automation library called Tuke.
Currently I have some C extension API code written to wrap objects in
contexts, but would like to re-write that in Cython as well as implement
a whole lot of other basic functionality.

http://github.com/retep/tuke/tree/master

- -- 
http://petertodd.org 'peter'[:-1]@petertodd.org 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIGR+z3bMhDbI9xWQRAjUsAKCx7XeM/+KRs9vCA3+XUuundIfF0wCfRJcf
nH3ByGq6MPaRUktCxWho5KE=
=oz0w
-----END PGP SIGNATURE-----

From robertwb at math.washington.edu  Thu May  1 04:12:42 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 30 Apr 2008 19:12:42 -0700
Subject: [Cython] __getattribute__
In-Reply-To: <20080501014107.GK15181@tilt>
References: <20080430004208.GJ15181@tilt>
	<5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>
	<20080501014107.GK15181@tilt>
Message-ID: <8367C02B-B674-44BB-AF04-4472EE8AABED@math.washington.edu>

On Apr 30, 2008, at 6:41 PM, Peter Todd wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, Apr 30, 2008 at 06:17:31PM -0700, Robert Bradshaw wrote:
>> On Apr 29, 2008, at 5:42 PM, Peter Todd wrote:
>>
>>> Is there a __getattribute__ work-alike in Cython?
>>>
>>> Essentially I need direct control over an objects tp_getattro and
>>> tp_setattro slots to implement a wrapper class. Specificly
>>> wrapped.__class__ should go to the wrapped objects class attribute,
>>> not
>>> the wrapping objects __class__ attribute.
>>>
>>> __getattr__ outputs C-source that includes a call to
>>> PyObject_GenericGetAttr first, and won't run my code if that call
>>> succeeds.
>>>
>>> Thanks,
>>>
>>> Peter
>>
>> Not that I'm aware of, though I'd imagine that implementing
>> __getattribute__ (if it exists) as being called at the top of this
>> function would be fairly easy to do. One would want to match Python
>> symantics exactly.
>
> Thanks for the reply.
>
> I've been looking at the Cython source myself, and it looks doable,  
> I'll
> put some effort into implementing it.

Great!

> From what I can see I'd be
> updating generate_getattro_function() to do a scope.lookup_here() on
> '__getattribute__' first, if that succeeds, output code to call it,
> otherwise go on to the existing code.

Sounds like a good plan. Is __getattribute__ inherited?

>
> With the additional complication
> that if __getattribute__ is defined, as well as __getattr__, the  
> latter
> must be called if the former raises AttributeError.

Yep, it should go onto the existing code (or call the super/default  
getattribute) on an error, even if __getattr__ is not defined, to  
match the specs.

> Another question is I noticed that the latest cython-devel code emits
> warnings on usage of __new__, saying to use __cinit__ instead. I  
> take it
> there is planned work to make __new__ more like Python's __new__ and
> have it create the object as well? Again, that's another feature I  
> could
> really use.

Eventually we may implement this (I looked into it some, but it  
wasn't as straightforward as I had hoped), but using __cinit__ now is  
good to avoid the confusion.

> FWIW I'm writing a electrical design automation library called Tuke.
> Currently I have some C extension API code written to wrap objects in
> contexts, but would like to re-write that in Cython as well as  
> implement
> a whole lot of other basic functionality.
>
> http://github.com/retep/tuke/tree/master

Cool. Should I add this to http://wiki.cython.org/projects ?

- Robert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://codespeak.net/pipermail/cython-dev/attachments/20080430/38c2d1ac/attachment.pgp 

From robertwb at math.washington.edu  Thu May  1 04:16:11 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 30 Apr 2008 19:16:11 -0700
Subject: [Cython] a problem with declaring and initializing <type>
	(*pointer)[N] = NULL
In-Reply-To: <e7ba66e40804300822q4e85fab3lcfde08b67ded0e5d@mail.gmail.com>
References: <e7ba66e40804300822q4e85fab3lcfde08b67ded0e5d@mail.gmail.com>
Message-ID: <EFD5E69C-E05C-4165-9A80-4C77AAF50F07@math.washington.edu>

That is really strange, no idea why.

On Apr 30, 2008, at 8:22 AM, Lisandro Dalcin wrote:
> Just pulled from cython-devel repo, this does not work (neither  
> before the pull)
>
> cdef int (*iranges)[3] = NULL
>
> but this indeed work
>
> cdef int (*iranges)[3]
> iranges = NULL
>
>
>
> -- 
> Lisandro Dalc?n
> ---------------
> Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
> Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
> Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
> PTLC - G?emes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
> _______________________________________________
> Cython-dev mailing list
> Cython-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev


From pete at petertodd.org  Thu May  1 05:16:03 2008
From: pete at petertodd.org (Peter Todd)
Date: Wed, 30 Apr 2008 23:16:03 -0400
Subject: [Cython] __getattribute__
In-Reply-To: <8367C02B-B674-44BB-AF04-4472EE8AABED@math.washington.edu>
References: <20080430004208.GJ15181@tilt>
	<5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>
	<20080501014107.GK15181@tilt>
	<8367C02B-B674-44BB-AF04-4472EE8AABED@math.washington.edu>
Message-ID: <20080501031603.GL15181@tilt>

On Wed, Apr 30, 2008 at 07:12:42PM -0700, Robert Bradshaw wrote:
> >From what I can see I'd be
> >updating generate_getattro_function() to do a scope.lookup_here() on
> >'__getattribute__' first, if that succeeds, output code to call it,
> >otherwise go on to the existing code.
> 
> Sounds like a good plan. Is __getattribute__ inherited?

Yes, and when inherited, it overrides __getattr__:

>>> class a(object):
...     def __getattribute__(self,n):
...             print 'a getattribute',n
...             raise AttributeError
... 
>>> class b(a):
...     def __getattr__(self,n):
...             print 'b getattr',n
...             return None
... 
>>> o = b()
>>> print o.asdf
a getattribute asdf
b getattr asdf
None
>>> 

But note that b.__getattr__ is called in the end. If b defines __setattr__, it
is called for any setattr as well. 

The Python C extension API docs also state that tp_getattro and tp_setattro are
"inherited by subtypes together with tp_getattr: a subtype inherits both
tp_getattr and tp_getattro from its base type when the subtype's tp_getattr and
tp_getattro are both NULL."

I think this will cause a conflict, in the following situation:

cdef class a:
    def __getattribute__(self,n):
        return n

cdef class b(a):
    def __setattr__(self,n,v):
	print 'b setattr',n,v

Evaluating b().asdf will not evaluate to 'asdf', rather an
AttributeError will be raised. Why? Because PyObject_GenericGetAttr()
doesn't look in the base class for attributes at all. And tp_getattro
will for type b will end up pointing to PyObject_GenericGetAttr due to
the above rule of only inhereting if *both* tp_getattro and tp_setattro
are not set. From what I can see in the slot_table definition
tp_getattro and tp_setattro are handled independently, and setting
setattr will leave getattro set to 0

> >
> >With the additional complication
> >that if __getattribute__ is defined, as well as __getattr__, the  
> >latter
> >must be called if the former raises AttributeError.
> 
> Yep, it should go onto the existing code (or call the super/default  
> getattribute) on an error, even if __getattr__ is not defined, to  
> match the specs.

Will do.

> >Another question is I noticed that the latest cython-devel code emits
> >warnings on usage of __new__, saying to use __cinit__ instead. I  
> >take it
> >there is planned work to make __new__ more like Python's __new__ and
> >have it create the object as well? Again, that's another feature I  
> >could
> >really use.
> 
> Eventually we may implement this (I looked into it some, but it  
> wasn't as straightforward as I had hoped), but using __cinit__ now is  
> good to avoid the confusion.

Thanks, I'll take a look at it as well.

> >FWIW I'm writing a electrical design automation library called Tuke.
> >Currently I have some C extension API code written to wrap objects in
> >contexts, but would like to re-write that in Cython as well as  
> >implement
> >a whole lot of other basic functionality.
> >
> >http://github.com/retep/tuke/tree/master
> 
> Cool. Should I add this to http://wiki.cython.org/projects ?

Sure, although, it may still be another two or three weeks before they
is any actual Cython code in the above tree. ;)

-- 
http://petertodd.org 'peter'[:-1]@petertodd.org 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://codespeak.net/pipermail/cython-dev/attachments/20080430/f62fafeb/attachment.pgp 

From robertwb at math.washington.edu  Thu May  1 07:32:10 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 30 Apr 2008 22:32:10 -0700
Subject: [Cython] Cython 0.9.6.14 release candidate
Message-ID: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>

Up at http://www.cython.org/Cython-0.9.6.14.tar.gz (or pull from the  
devel branch). If no problems are found, this will be the release. (I  
have already tested Sage).

- Robert


From greg.ewing at canterbury.ac.nz  Thu May  1 07:44:36 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 01 May 2008 17:44:36 +1200
Subject: [Cython] __getattribute__
In-Reply-To: <20080501014107.GK15181@tilt>
References: <20080430004208.GJ15181@tilt>
	<5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>
	<20080501014107.GK15181@tilt>
Message-ID: <481958C4.2070205@canterbury.ac.nz>

Peter Todd wrote:
> Another question is I noticed that the latest cython-devel code emits
> warnings on usage of __new__, saying to use __cinit__ instead. I take it
> there is planned work to make __new__ more like Python's __new__ and
> have it create the object as well? Again, that's another feature I could
> really use.

That's the idea. I'm not sure exactly what I'm going to
do with __new__ yet, but I want to free up the name so
I can do something better with it later.

-- 
Greg

From stefan_ml at behnel.de  Thu May  1 07:54:52 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 01 May 2008 07:54:52 +0200
Subject: [Cython] __getattribute__
In-Reply-To: <20080501031603.GL15181@tilt>
References: <20080430004208.GJ15181@tilt>	<5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>	<20080501014107.GK15181@tilt>	<8367C02B-B674-44BB-AF04-4472EE8AABED@math.washington.edu>
	<20080501031603.GL15181@tilt>
Message-ID: <48195B2C.6060301@behnel.de>

Hi,


Peter Todd wrote:
>>> From what I can see I'd be
>>> updating generate_getattro_function() to do a scope.lookup_here() on
>>> '__getattribute__' first, if that succeeds, output code to call it,
>>> otherwise go on to the existing code.

Please see the code in Python's typeobject.c, functions "slot_tp_getattr_hook"
and "slot_tp_getattro" (essentially a fast path), and the comment above them.
The code Cython generates must behave like these two.


> On Wed, Apr 30, 2008 at 07:12:42PM -0700, Robert Bradshaw wrote:
>> Sounds like a good plan. Is __getattribute__ inherited?

Python is already doing a couple of things here for us. There is some code in
"inherit_slots" (typeobject.c) that inherits the slots, but only if both get*
functions are set to NULL, or set* functions respectively:

        if (type->tp_getattr == NULL && type->tp_getattro == NULL) {
                type->tp_getattr = base->tp_getattr;
                type->tp_getattro = base->tp_getattro;
        }
        if (type->tp_setattr == NULL && type->tp_setattro == NULL) {
                type->tp_setattr = base->tp_setattr;
                type->tp_setattro = base->tp_setattro;
        }

Again, Cython must behave alike here.

Stefan

From robertwb at math.washington.edu  Thu May  1 13:01:09 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 1 May 2008 04:01:09 -0700
Subject: [Cython] [Pyrex]   Python 3
In-Reply-To: <fv8a8h$g1b$1@ger.gmane.org>
References: <tkrat.f8570a2e9b3f66cf@skynet.be>	<15D9902A-0C11-4939-95C4-86C50B5B816F@math.washington.edu>	<4816BB88.6000708@canterbury.ac.nz>
	<4816C6FC.2050103@behnel.de>	<4816CC06.1040706@canterbury.ac.nz>
	<4816F091.1000505@cheimes.de> <4817A2D1.9010802@canterbury.ac.nz>
	<fv8a8h$g1b$1@ger.gmane.org>
Message-ID: <D5054997-98BC-44AC-A1F0-E2698188DA8D@math.washington.edu>


On Apr 29, 2008, at 4:16 PM, Christian Heimes wrote:
> Greg Ewing schrieb:
>> Thanks, I didn't know that.
>>
>> So it seems that we could, if it were considered desirable,
>> have an automatic cast from unicode to char *. But the encoding
>> would *have* to be utf8 -- anything else would require memory
>> allocation.
>
> You're welcome! :)
>
> The UTF-8 default encoding is hard coded in Python 3.0. IMHO it's the
> most sensible encoding for users from the Western world. Asian users
> would probably prefer UTF-16 but that's a waste of memory for the  
> rest.

Yes. Even ignoring memory concerns, UTF-8 plays much nicer with unix/ 
other tools that are not unicode-aware.

> In my opinion wchar_t support is much more important than casting
> PyUnicode objects to char*. Especially Windows developers need wchar_t
> for the wide Windows API. Python 2.6 and 3.0 have dropped support for
> the Windows 9x/ME/NT series. Only 2k SP4 and newer are supported.
> wchar_t support is an important step for the poor souls ... err  
> Windows
> developers. ;)

I'm curious what you mean by wchar_t support--one can typedef wchar_t  
to be an integer type. Or perhaps you mean something more...

- Robert


From robertwb at math.washington.edu  Thu May  1 13:02:00 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 1 May 2008 04:02:00 -0700
Subject: [Cython] MultiCores/AMD open source tools
In-Reply-To: <dd3c0ce40804291726j60809287k1ec176240e97f090@mail.gmail.com>
References: <dd3c0ce40804291712i18da1bech8fa7a7df7241a72e@mail.gmail.com>
	<dd3c0ce40804291726j60809287k1ec176240e97f090@mail.gmail.com>
Message-ID: <1C5D2BE2-66BB-4362-9244-332B7B1A7461@math.washington.edu>

There's the issue of the GIL, but if you don't touch the interpreter  
you can do threading just as in C.

On Apr 29, 2008, at 5:26 PM, Gottfried F. Zojer wrote:
> From: Gottfried F. Zojer <goenzoy at gmail.com>
> Date: Apr 30, 2008 2:12 AM
> Subject: MultiCores/AMD open source tools
> To: cython-dev at codespeak.net
>
>
> Hallo,
>
>  Just wondering if someone is using cython in combination with any  
> of AMD
>  open-source projects like framewave or have any other thoughts to use
>  cython/python for parallel programming or Multi Core programming.
>  Any feedback welcome
>
>  Rgds Gottfried
>
>
>  www.5152.eu
> _______________________________________________
> Cython-dev mailing list
> Cython-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev


From ndbecker2 at gmail.com  Thu May  1 13:56:44 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 01 May 2008 07:56:44 -0400
Subject: [Cython] Cython 0.9.6.14 release candidate
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>
Message-ID: <fvcb5t$bs1$1@ger.gmane.org>

Robert Bradshaw wrote:

> Up at http://www.cython.org/Cython-0.9.6.14.tar.gz (or pull from the
> devel branch). If no problems are found, this will be the release. (I
> have already tested Sage).
> 
> - Robert

I did
hg clone http://hg.cython.org/cython/
python setup.py build && sudo python setup.py install
python runtests.py:

Ran 317 tests in 52.931s

FAILED (failures=3)


From bblais at gmail.com  Thu May  1 15:32:33 2008
From: bblais at gmail.com (Brian Blais)
Date: Thu, 1 May 2008 09:32:33 -0400
Subject: [Cython] access to numpy functions?
Message-ID: <F425677E-4B0F-4634-BF27-0B2138304B9B@gmail.com>

Hello,

I have been using Pyrex/Cython for a couple years now, interfacing  
with the numpy ndarray objects.  I was wondering recently if there is  
direct access to some of the functions of numpy, like dot products,  
addition and subtraction, etc... without going through the python  
API?  If I have two objects in Cython/Pyrex, like:


c_numpy.ndarray x,y

and I want to do a dot product, or add the two arrays, is there  
access to the numpy C-version of this?  I know I could write my own  
for the dot product, but I'd rather not reinvent the wheel when  
possible.



			thanks,


				Brian Blais

From dagss at student.matnat.uio.no  Thu May  1 16:39:44 2008
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Thu, 01 May 2008 16:39:44 +0200
Subject: [Cython] access to numpy functions?
In-Reply-To: <F425677E-4B0F-4634-BF27-0B2138304B9B@gmail.com>
References: <F425677E-4B0F-4634-BF27-0B2138304B9B@gmail.com>
Message-ID: <4819D630.9060602@student.matnat.uio.no>


> API?  If I have two objects in Cython/Pyrex, like:
>
>
> c_numpy.ndarray x,y
>
> and I want to do a dot product, or add the two arrays, is there  
> access to the numpy C-version of this?  I know I could write my own  
> for the dot product, but I'd rather not reinvent the wheel when  
> possible.
>   

First off, you can use the Python functions directly, like this (Cython 
syntax):

---
import numpy
cimport c_numpy

cdef c_numpy.ndarray a = ..., b = ...
cdef c_numpy.ndarray c = numpy.dot(a, b)
---

As for calling the NumPy C functions directly: The a place to start is 
looking seems to be core/src/multiarraymodule.c. (You may want to ask in 
the numpy mailing list as well though. I'm not very familiar with NumPy 
internals.)

My first impression is that the implementations (say, 
PyArray_InnerProduct for instance) seem to be a) very generic (any 
number of dimensions/strides etc. and b) coded using the Python/C API 
directly, so there is no "inner layer" to communicate with. I.e., 
arguments to functions are Python objects.

So you're probably just as well off by calling the functions through the 
Python API like stated above.

If that is not fast enough, there doesn't seem to be much to be gained 
by "direct calls" to the C functions; and a new implementation in Cython 
seems in order. The main reason is that to make this faster you will 
want to make use of additional information -- if you know the number of 
dimensions (or even their size) and datatype at compile-time, you can 
make some optimizations that functions in the NumPy library will never 
be able to do. (For most if not all cases I'm guessing that we're 
talking very small gains if any gains here; though if you tend to 
multiply really small arrays a lot (like doing coordinate 
transformation...) then I suppose you must write your own code.)

-- 
Dag Sverre


From stefan_ml at behnel.de  Thu May  1 18:52:46 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 01 May 2008 18:52:46 +0200
Subject: [Cython] Cython 0.9.6.14 release candidate
In-Reply-To: <fvcb5t$bs1$1@ger.gmane.org>
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>
	<fvcb5t$bs1$1@ger.gmane.org>
Message-ID: <4819F55E.5010909@behnel.de>

Hi,

Neal Becker wrote:
> Robert Bradshaw wrote:
>> Up at http://www.cython.org/Cython-0.9.6.14.tar.gz (or pull from the
>> devel branch). If no problems are found, this will be the release. (I
>> have already tested Sage).
>>
>> - Robert
> 
> I did
> hg clone http://hg.cython.org/cython/

That's the wrong repository. As Robert said, the RC is in the devel branch:

    http://hg.cython.org/cython-devel/

Stefan

From ndbecker2 at gmail.com  Thu May  1 19:07:24 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 01 May 2008 13:07:24 -0400
Subject: [Cython] Cython 0.9.6.14 release candidate
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>
	<fvcb5t$bs1$1@ger.gmane.org> <4819F55E.5010909@behnel.de>
Message-ID: <fvctcc$9ed$1@ger.gmane.org>

Stefan Behnel wrote:

> Hi,
> 
> Neal Becker wrote:
>> Robert Bradshaw wrote:
>>> Up at http://www.cython.org/Cython-0.9.6.14.tar.gz (or pull from the
>>> devel branch). If no problems are found, this will be the release. (I
>>> have already tested Sage).
>>>
>>> - Robert
>> 
>> I did
>> hg clone http://hg.cython.org/cython/
> 
> That's the wrong repository. As Robert said, the RC is in the devel
> branch:
> 
>     http://hg.cython.org/cython-devel/
> 
> Stefan

Thanks, now I got:

Traceback (most recent call last):
  File "/usr/lib64/python2.5/doctest.py", line 2112, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for r_vree_1
  File "/home/nbecker/cython-devel/BUILD/r_vree_1.so", line 190, in r_vree_1

----------------------------------------------------------------------
File "/home/nbecker/cython-devel/BUILD/r_vree_1.so", line 203, in r_vree_1
Failed example:
    test(sys.maxint + 1)
Expected:
    2147483648L
Got:
    9223372036854775808L
----------------------------------------------------------------------
File "/home/nbecker/cython-devel/BUILD/r_vree_1.so", line 205, in r_vree_1
Failed example:
    test(sys.maxint * 2 + 1)
Expected:
    4294967295L
Got:
    18446744073709551615L


----------------------------------------------------------------------
Ran 213 tests in 53.887s

FAILED (failures=1)

These are probably harmless 32/64 bit errors?  Tests should be fixed?


From stefan_ml at behnel.de  Thu May  1 19:20:55 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 01 May 2008 19:20:55 +0200
Subject: [Cython] Cython 0.9.6.14 release candidate
In-Reply-To: <fvctcc$9ed$1@ger.gmane.org>
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>	<fvcb5t$bs1$1@ger.gmane.org>
	<4819F55E.5010909@behnel.de> <fvctcc$9ed$1@ger.gmane.org>
Message-ID: <4819FBF7.9030901@behnel.de>

Hi,

Neal Becker wrote:
> Traceback (most recent call last):
>   File "/usr/lib64/python2.5/doctest.py", line 2112, in runTest
>     raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for r_vree_1
>   File "/home/nbecker/cython-devel/BUILD/r_vree_1.so", line 190, in r_vree_1
> 
> ----------------------------------------------------------------------
> File "/home/nbecker/cython-devel/BUILD/r_vree_1.so", line 203, in r_vree_1
> Failed example:
>     test(sys.maxint + 1)
> Expected:
>     2147483648L
> Got:
>     9223372036854775808L
> ----------------------------------------------------------------------
> File "/home/nbecker/cython-devel/BUILD/r_vree_1.so", line 205, in r_vree_1
> Failed example:
>     test(sys.maxint * 2 + 1)
> Expected:
>     4294967295L
> Got:
>     18446744073709551615L
> 
> 
> ----------------------------------------------------------------------
> Ran 213 tests in 53.887s
> 
> FAILED (failures=1)
> 
> These are probably harmless 32/64 bit errors?  Tests should be fixed?

Sure, looks like the test is broken here. What is sys.maxint on a 64 bit platform?

Could you dig into this and try to provide a fix?

Stefan


From robertwb at math.washington.edu  Thu May  1 19:48:54 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 1 May 2008 10:48:54 -0700
Subject: [Cython] access to numpy functions?
In-Reply-To: <4819D630.9060602@student.matnat.uio.no>
References: <F425677E-4B0F-4634-BF27-0B2138304B9B@gmail.com>
	<4819D630.9060602@student.matnat.uio.no>
Message-ID: <65DA8D65-87AE-4D1D-9777-D843BD2B00C1@math.washington.edu>

On May 1, 2008, at 7:39 AM, Dag Sverre Seljebotn wrote:

>
>> API?  If I have two objects in Cython/Pyrex, like:
>>
>>
>> c_numpy.ndarray x,y
>>
>> and I want to do a dot product, or add the two arrays, is there
>> access to the numpy C-version of this?  I know I could write my own
>> for the dot product, but I'd rather not reinvent the wheel when
>> possible.
>>
>
> First off, you can use the Python functions directly, like this  
> (Cython
> syntax):
>
> ---
> import numpy
> cimport c_numpy
>
> cdef c_numpy.ndarray a = ..., b = ...
> cdef c_numpy.ndarray c = numpy.dot(a, b)
> ---
>
> As for calling the NumPy C functions directly: The a place to start is
> looking seems to be core/src/multiarraymodule.c. (You may want to  
> ask in
> the numpy mailing list as well though. I'm not very familiar with  
> NumPy
> internals.)
>
> My first impression is that the implementations (say,
> PyArray_InnerProduct for instance) seem to be a) very generic (any
> number of dimensions/strides etc. and b) coded using the Python/C API
> directly, so there is no "inner layer" to communicate with. I.e.,
> arguments to functions are Python objects.
>
> So you're probably just as well off by calling the functions  
> through the
> Python API like stated above.
>
> If that is not fast enough, there doesn't seem to be much to be gained
> by "direct calls" to the C functions; and a new implementation in  
> Cython
> seems in order.

And fortunately this is another GSoC project.

> The main reason is that to make this faster you will
> want to make use of additional information -- if you know the  
> number of
> dimensions (or even their size) and datatype at compile-time, you can
> make some optimizations that functions in the NumPy library will never
> be able to do. (For most if not all cases I'm guessing that we're
> talking very small gains if any gains here; though if you tend to
> multiply really small arrays a lot (like doing coordinate
> transformation...) then I suppose you must write your own code.)
>
> -- 
> Dag Sverre
>
> _______________________________________________
> Cython-dev mailing list
> Cython-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev


From ndbecker2 at gmail.com  Thu May  1 19:59:39 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 01 May 2008 13:59:39 -0400
Subject: [Cython] Cython 0.9.6.14 release candidate
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>	<fvcb5t$bs1$1@ger.gmane.org>
	<4819F55E.5010909@behnel.de> <fvctcc$9ed$1@ger.gmane.org>
	<4819FBF7.9030901@behnel.de>
Message-ID: <fvd0eb$kbh$2@ger.gmane.org>

Stefan Behnel wrote:

> Hi,
> 
> Neal Becker wrote:
...
>> These are probably harmless 32/64 bit errors?  Tests should be fixed?
> 
> Sure, looks like the test is broken here. What is sys.maxint on a 64 bit
> platform?
> 

python -c 'import sys; print sys.maxint'
9223372036854775807

This is x86_64


From stefan_ml at behnel.de  Thu May  1 20:10:38 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 01 May 2008 20:10:38 +0200
Subject: [Cython] Cython 0.9.6.14 release candidate
In-Reply-To: <fvd0eb$kbh$2@ger.gmane.org>
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>	<fvcb5t$bs1$1@ger.gmane.org>	<4819F55E.5010909@behnel.de>
	<fvctcc$9ed$1@ger.gmane.org>	<4819FBF7.9030901@behnel.de>
	<fvd0eb$kbh$2@ger.gmane.org>
Message-ID: <481A079E.8030705@behnel.de>

Hi,

Neal Becker wrote:
> Stefan Behnel wrote:
>> Neal Becker wrote:
> ...
>>> These are probably harmless 32/64 bit errors?  Tests should be fixed?
>> Sure, looks like the test is broken here. What is sys.maxint on a 64 bit
>> platform?
> 
> python -c 'import sys; print sys.maxint'
> 9223372036854775807
> 
> This is x86_64

I pushed a fix for the test case. Could you try it?

Thanks,
Stefan


From ndbecker2 at gmail.com  Thu May  1 20:46:42 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 01 May 2008 14:46:42 -0400
Subject: [Cython] Cython 0.9.6.14 release candidate
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>	<fvcb5t$bs1$1@ger.gmane.org>	<4819F55E.5010909@behnel.de>
	<fvctcc$9ed$1@ger.gmane.org>	<4819FBF7.9030901@behnel.de>
	<fvd0eb$kbh$2@ger.gmane.org> <481A079E.8030705@behnel.de>
Message-ID: <fvd36i$tsb$1@ger.gmane.org>

Stefan Behnel wrote:

> Hi,
> 
> Neal Becker wrote:
>> Stefan Behnel wrote:
>>> Neal Becker wrote:
>> ...
>>>> These are probably harmless 32/64 bit errors?  Tests should be fixed?
>>> Sure, looks like the test is broken here. What is sys.maxint on a 64 bit
>>> platform?
>> 
>> python -c 'import sys; print sys.maxint'
>> 9223372036854775807
>> 
>> This is x86_64
> 
> I pushed a fix for the test case. Could you try it?
> 
> Thanks,
> Stefan
Ran 213 tests in 22.508s

OK


From kirr at landau.phys.spbu.ru  Fri May  2 07:58:44 2008
From: kirr at landau.phys.spbu.ru (Kirill Smelkov)
Date: Fri, 2 May 2008 09:58:44 +0400
Subject: [Cython] Cython 0.9.6.14 release candidate
In-Reply-To: <fvd36i$tsb$1@ger.gmane.org>
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>
	<fvcb5t$bs1$1@ger.gmane.org> <4819F55E.5010909@behnel.de>
	<fvctcc$9ed$1@ger.gmane.org> <4819FBF7.9030901@behnel.de>
	<fvd0eb$kbh$2@ger.gmane.org> <481A079E.8030705@behnel.de>
	<fvd36i$tsb$1@ger.gmane.org>
Message-ID: <20080502055844.GA10755@evo>

On Thu, May 01, 2008 at 02:46:42PM -0400, Neal Becker wrote:
> Stefan Behnel wrote:
> 
> > Hi,
> > 
> > Neal Becker wrote:
> >> Stefan Behnel wrote:
> >>> Neal Becker wrote:
> >> ...
> >>>> These are probably harmless 32/64 bit errors?  Tests should be fixed?
> >>> Sure, looks like the test is broken here. What is sys.maxint on a 64 bit
> >>> platform?
> >> 
> >> python -c 'import sys; print sys.maxint'
> >> 9223372036854775807
> >> 
> >> This is x86_64
> > 
> > I pushed a fix for the test case. Could you try it?
> > 
> > Thanks,
> > Stefan
> Ran 213 tests in 22.508s

I still have 3 failures with latest cython-devel (b869698d6f22)

Attached is a log of 'python runtests.py' run on Debian testing.

-- 
    ????? ????????, ??????.
-------------- next part --------------
Doctest: notinop ... ok
Doctest: ishimoto2 ... ok
Doctest: classkwonlyargs ... ok
Doctest: assert ... ok
Doctest: kwargproblems ... ok
Doctest: ct_IF ... ok
Doctest: behnel3 ... ok
Doctest: r_jiba1 ... ok
Doctest: extkwonlyargs ... ok
Doctest: if ... ok
Doctest: subop ... ok
Doctest: dict ... ok
Doctest: ishimoto3 ... ok
Doctest: addressof ... ok
Doctest: baas3 ... ok
Doctest: r_docstrings ... ok
Doctest: r_hordijk1 ... ok
Doctest: unicodeliterals ... ok
Doctest: tuple ... ok
Doctest: powop ... ok
Doctest: compiledef ... ok
Doctest: print ... ok
Doctest: r_mang1 ... ok
Doctest: jarausch1 ... ok
Doctest: unop ... ok
Doctest: bishop2 ... ok
Doctest: cstruct ... ok
Doctest: unicodeliteralslatin1 ... ok
Doctest: pynumop ... ok
Doctest: isnonebool ... ok
Doctest: exarkun ... ok
Doctest: extinstantiate ... ok
Doctest: unpacklistcomp ... ok
Doctest: r_starargs ... ok
Doctest: kostyrka2 ... ok
Doctest: cfuncdef ... ok
Doctest: attr ... ok
modop.c:252: warning: ?__pyx_f_5modop_modptr? defined but not used
Doctest: modop ... ok
Doctest: bishop1 ... ok
Doctest: r_spamtype ... ok
Doctest: wundram1 ... ok
Doctest: kostyrka ... ok
Doctest: varargcall ... ok
Doctest: pyintop ... ok
Doctest: include ... ok
Doctest: classpass ... ok
Doctest: addloop ... ok
Doctest: extinherit ... ok
Doctest: cunion ... ok
Doctest: cvardef ... ok
Doctest: pinard7 ... ok
Doctest: append ... ok
Doctest: boolop ... ok
Doctest: r_pythonapi ... ok
Doctest: pass ... ok
Doctest: slice3 ... ok
Doctest: unpack ... ok
Doctest: pyextattrref ... ok
Doctest: pylistsubtype ... ok
Doctest: ass2global ... ok
Doctest: pycmp ... ok
Doctest: r_starargcall ... ok
Doctest: new_style_exceptions ... FAIL
Doctest: r_argdefault ... ok
Doctest: extstarargs ... ok
Doctest: kwonlyargs ... ok
Doctest: pinard8 ... ok
Doctest: rodriguez_1 ... ok
Doctest: r_extstarargs ... ok
Doctest: cstringmul ... ok
Doctest: multass ... ok
Doctest: r_barbieri1 ... ok
Doctest: list ... ok
Doctest: r_mitch_chapman_2 ... ok
Doctest: slice2 ... ok
Doctest: backquote ... ok
Doctest: r_toofewargs ... ok
Doctest: strconstinclass ... ok
Doctest: extclasspass ... ok
Doctest: pinard6 ... ok
Doctest: tuplereassign ... FAIL
Doctest: r_starargsonly ... ok
Doctest: dietachmayer1 ... ok
Doctest: lepage_1 ... ok
Doctest: exttype ... ok
Doctest: r_pyclassdefault ... ok
Doctest: r_addint ... ok
Doctest: unicodeliteralsdefault ... ok
Doctest: r_extcomplex2 ... ok
Doctest: return ... ok
Doctest: behnel2 ... ok
Doctest: concatcstrings ... ok
Doctest: getattr3call ... ok
Doctest: unicodefunction ... ok
Doctest: pinard5 ... ok
Doctest: r_primes ... ok
Doctest: r_pyclass ... ok
Doctest: r_print ... ok
Doctest: ass2local ... ok
Doctest: r_vree_1 ... ok
Doctest: simpcall ... ok
Doctest: modbody ... ok
Doctest: altet2 ... ok
Doctest: r_mcintyre1 ... ok
Doctest: specialfloat ... ok
Doctest: addop ... ok
Doctest: r_forloop ... ok
Doctest: strfunction ... ok
Doctest: cintop ... ok
Doctest: ref2local ... ok
Doctest: literals ... ok
Doctest: ct_DEF ... ok
Doctest: extlen ... ok
Doctest: sizeof ... ok
Doctest: inop ... ok
Doctest: starargs ... ok
Doctest: behnel1 ... ok
compiling undefinedname ... ok
compiling encoding ... ok
compiling void_as_arg ... ok
compiling arrayptrcompat ... arrayptrcompat.c:123: warning: ?__pyx_f_14arrayptrcompat_f? defined but not used
ok
compiling extsetattr ... ok
compiling ctypedef ... ok
compiling extpropertydoc ... ok
compiling extimportedsubtype ... ok
compiling extsetitem ... ok
compiling cargdef ... ok
compiling enumintcompat ... enumintcompat.c:135: warning: ?__pyx_f_13enumintcompat_f? defined but not used
ok
compiling omittedargnames ... ok
compiling import ... ok
compiling callingconvention ... ok
compiling lepage_2 ... ok
compiling extpropertyget ... ok
compiling builtin ... ok
compiling formfeed ... ok
compiling emptytry ... emptytry.c:111: warning: ?__pyx_f_8emptytry_f? defined but not used
ok
compiling extcmethcall ... extcmethcall.c:179: warning: ?__pyx_f_12extcmethcall_tomato? defined but not used
ok
compiling extdelslice ... ok
compiling ewing4 ... ewing4.c:110: warning: ?__pyx_f_6ewing4_f? defined but not used
ok
compiling extindex ... ok
compiling huss2 ... huss2.c:125: warning: ?__pyx_f_5huss2_f? defined but not used
ok
compiling declarations ... declarations.c:125: warning: ?__pyx_f_12declarations_f? defined but not used
declarations.c:146: warning: ?__pyx_f_12declarations_g? defined but not used
ok
compiling extdelitem ... ok
compiling excvaldecl ... excvaldecl.c:116: warning: ?__pyx_f_10excvaldecl_spam? defined but not used
excvaldecl.c:131: warning: ?__pyx_f_10excvaldecl_eggs? defined but not used
excvaldecl.c:146: warning: ?__pyx_f_10excvaldecl_grail? defined but not used
excvaldecl.c:161: warning: ?__pyx_f_10excvaldecl_tomato? defined but not used
excvaldecl.c:176: warning: ?__pyx_f_10excvaldecl_brian? defined but not used
excvaldecl.c:190: warning: ?__pyx_f_10excvaldecl_silly? defined but not used
ok
compiling ctypedefenum ... ok
compiling tryexcept ... ok
compiling for ... ok
compiling specmethextarg ... ok
compiling while ... while.c: In function ?__pyx_pf_5while_f?:
while.c:197: warning: ?__pyx_v_i? is used uninitialized in this function
ok
compiling jiba3 ... ok
compiling varargdecl ... varargdecl.c:110: warning: ?__pyx_f_10varargdecl_grail? defined but not used
ok
compiling extsetslice ... ok
compiling belchenko1 ... belchenko1.c:113: warning: ?__pyx_f_10belchenko1__is_aligned? defined but not used
ok
compiling ewing6 ... ewing6.c:207: warning: ?__pyx_f_6ewing6_f? defined but not used
ok
compiling jiba4 ... ok
compiling nogil ... nogil.c:114: warning: ?__pyx_f_5nogil_f? defined but not used
ok
compiling extargdefault ... ok
compiling typecast ... typecast.c:113: warning: ?__pyx_f_8typecast_f? defined but not used
ok
compiling coventry1 ... ok
compiling fromimport ... ok
compiling cstructreturn ... cstructreturn.c:124: warning: ?__pyx_f_13cstructreturn_f? defined but not used
ok
compiling globvardef ... ok
compiling ctypedefclass ... ok
compiling ia_cdefblock ... ia_cdefblock.c:157: warning: ?__pyx_f_12ia_cdefblock_priv_f? defined but not used
ok
compiling coercetovoidptr ... coercetovoidptr.c:111: warning: ?__pyx_f_15coercetovoidptr_f? defined but not used
ok
compiling withgil ... withgil.c:114: warning: ?__pyx_f_7withgil_f? defined but not used
withgil.c:140: warning: ?__pyx_f_7withgil_g? defined but not used
ok
compiling declandimpl ... ok
compiling ishimoto1 ... ok
compiling specmethargdefault ... ok
compiling funcptr ... ok
compiling globalonly ... ok
compiling extdelattr ... ok
compiling pyclass ... ok
compiling tryfinally ... tryfinally.c: In function ?__pyx_pf_10tryfinally_f?:
tryfinally.c:213: warning: ?__pyx_exc_type? is used uninitialized in this function
tryfinally.c:214: warning: ?__pyx_exc_value? is used uninitialized in this function
tryfinally.c:215: warning: ?__pyx_exc_tb? is used uninitialized in this function
tryfinally.c:223: warning: ?__pyx_exc_lineno? is used uninitialized in this function
tryfinally.c:311: warning: ?__pyx_exc_tb? is used uninitialized in this function
tryfinally.c:311: warning: ?__pyx_exc_value? is used uninitialized in this function
tryfinally.c:311: warning: ?__pyx_exc_type? is used uninitialized in this function
tryfinally.c:312: warning: ?__pyx_exc_lineno? is used uninitialized in this function
ok
compiling doda1 ... doda1.c:127: warning: ?__pyx_f_5doda1_foo? defined but not used
ok
compiling extgetattr ... ok
compiling johnson2 ... ok
compiling cenum ... cenum.c:129: warning: ?__pyx_f_5cenum_eggs? defined but not used
ok
compiling coercearraytoptr ... coercearraytoptr.c:126: warning: ?__pyx_f_16coercearraytoptr_eggs? defined but not used
ok
compiling kleckner1 ... kleckner1.c:126: warning: ?__pyx_f_9kleckner1_g? defined but not used
ok
compiling exthash ... ok
compiling extern ... extern.c:131: warning: ?__pyx_f_6extern_grail? defined but not used
ok
compiling pinard4 ... ok
compiling hinsen2 ... ok
compiling ewing9 ... ok
compiling longunsigned ... ok
compiling extinheritset ... ok
compiling ewing7 ... ok
compiling ishimoto4 ... ishimoto4.c:110: warning: ?__pyx_f_9ishimoto4_f? defined but not used
ok
compiling khavkine1 ... khavkine1.c:126: warning: ?__pyx_f_9khavkine1_f? defined but not used
ok
compiling a_capi ... ok
compiling ctypedefunion ... ok
compiling extpropertydel ... ok
compiling withnogil ... withnogil.c:113: warning: ?__pyx_f_9withnogil_f? defined but not used
withnogil.c:145: warning: ?__pyx_f_9withnogil_g? defined but not used
ok
compiling extimported ... ok
compiling ctypedefstruct ... ok
compiling constexpr ... ok
compiling ewing8 ... ok
compiling signedtypes ... ok
compiling nonctypedefclass ... ok
compiling cdefexternfromstar ... ok
compiling complexbasetype ... complexbasetype.c:115: warning: ?__pyx_f_15complexbasetype_brian? defined but not used
ok
compiling classmethargdefault ... ok
compiling cforfromloop ... ok
compiling extpropertyset ... ok
compiling ewing3 ... ok
compiling behnel4 ... behnel4.c:123: warning: ?__pyx_f_7behnel4_f? defined but not used
ok
compiling specmethdocstring ... specmethdocstring.c:131: warning: ?__pyx_doc_17specmethdocstring_1C___init__? defined but not used
specmethdocstring.c:155: warning: ?__pyx_doc_17specmethdocstring_1C_3foo___get__? defined but not used
specmethdocstring.c:171: warning: ?__pyx_doc_17specmethdocstring_1C_3foo___set__? defined but not used
ok
compiling extforward ... ok
compiling cverylongtypes ... ok
compiling argdefault ... ok
compiling nullptr ... ok
compiling extinheritdel ... ok

======================================================================
FAIL: Doctest: new_style_exceptions
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.4/doctest.py", line 2157, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for new_style_exceptions
  File "/home/kirr/src/tools/cython/cython-devel/BUILD/new_style_exceptions.so", line unknown line number, in new_style_exceptions

----------------------------------------------------------------------
File "/home/kirr/src/tools/cython/cython-devel/BUILD/new_style_exceptions.so", line ?, in new_style_exceptions
Failed example:
    test(Exception('hi'))
Expected:
    Raising: Exception('hi',)
    Caught: <type 'exceptions.Exception'> Exception('hi',)
Got:
    Raising: <exceptions.Exception instance at 0xb78ad84c>
    Caught: <class exceptions.Exception at 0xb7d8c26c> <exceptions.Exception instance at 0xb78ad84c>


======================================================================
FAIL: Doctest: tuplereassign
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.4/doctest.py", line 2157, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for tuplereassign
  File "/home/kirr/src/tools/cython/cython-devel/BUILD/tuplereassign.so", line 23, in tuplereassign

----------------------------------------------------------------------
File "/home/kirr/src/tools/cython/cython-devel/BUILD/tuplereassign.so", line 31, in tuplereassign
Failed example:
    testnonsense()
Expected:
    Traceback (most recent call last):
    TypeError: 'int' object is not iterable
Got:
    Traceback (most recent call last):
      File "/usr/lib/python2.4/doctest.py", line 1248, in __run
        compileflags, 1) in test.globs
      File "<doctest tuplereassign[3]>", line 1, in ?
        testnonsense()
      File "tuplereassign.pyx", line 26, in tuplereassign.testnonsense (tuplereassign.c:%u)
    TypeError: iteration over non-sequence


----------------------------------------------------------------------
Ran 213 tests in 289.050s

FAILED (failures=2)
Creating lexicon...
Done (0.21 seconds)
Pickling lexicon...
Done (0.02 seconds)

From stefan_ml at behnel.de  Fri May  2 09:13:10 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 02 May 2008 09:13:10 +0200
Subject: [Cython] Cython 0.9.6.14 release candidate
In-Reply-To: <20080502055844.GA10755@evo>
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>	<fvcb5t$bs1$1@ger.gmane.org>
	<4819F55E.5010909@behnel.de>	<fvctcc$9ed$1@ger.gmane.org>
	<4819FBF7.9030901@behnel.de>	<fvd0eb$kbh$2@ger.gmane.org>
	<481A079E.8030705@behnel.de>	<fvd36i$tsb$1@ger.gmane.org>
	<20080502055844.GA10755@evo>
Message-ID: <481ABF06.7020707@behnel.de>

Hi,

Kirill Smelkov wrote:
> I still have 3 failures with latest cython-devel (b869698d6f22)
> Attached is a log of 'python runtests.py' run on Debian testing.

Thanks. That's running against Python 2.4, while the two tests were depending
on Python 2.5 specifics (an exception message and new style exception types).
I relaxed them a bit to run on Py2.3-2.5.

The test runner script also prints the versions of Cython and Python now, to
put some more context into the test log.

Stefan


From kirr at landau.phys.spbu.ru  Fri May  2 09:46:38 2008
From: kirr at landau.phys.spbu.ru (Kirill Smelkov)
Date: Fri, 2 May 2008 11:46:38 +0400
Subject: [Cython] Cython 0.9.6.14 release candidate
In-Reply-To: <481ABF06.7020707@behnel.de>
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>
	<fvcb5t$bs1$1@ger.gmane.org> <4819F55E.5010909@behnel.de>
	<fvctcc$9ed$1@ger.gmane.org> <4819FBF7.9030901@behnel.de>
	<fvd0eb$kbh$2@ger.gmane.org> <481A079E.8030705@behnel.de>
	<fvd36i$tsb$1@ger.gmane.org> <20080502055844.GA10755@evo>
	<481ABF06.7020707@behnel.de>
Message-ID: <20080502074637.GB10755@evo>

Hi Stefan,

On Fri, May 02, 2008 at 09:13:10AM +0200, Stefan Behnel wrote:
> Hi,
> 
> Kirill Smelkov wrote:
> > I still have 3 failures with latest cython-devel (b869698d6f22)
> > Attached is a log of 'python runtests.py' run on Debian testing.
> 
> Thanks. That's running against Python 2.4, while the two tests were depending
> on Python 2.5 specifics (an exception message and new style exception types).
> I relaxed them a bit to run on Py2.3-2.5.
> 
> The test runner script also prints the versions of Cython and Python now, to
> put some more context into the test log.

kirr at evo:~/src/tools/cython/cython-devel$ python runtests.py 
Running tests against Cython 0.9.6.13.1
Python 2.4.5 (#2, Mar 12 2008, 00:15:51) 
[GCC 4.2.3 (Debian 4.2.3-2)]

...

Ran 213 tests in 243.547s

OK

----

Thanks!

-- 
    ????? ????????, ??????.

From robertwb at math.washington.edu  Fri May  2 10:38:42 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Fri, 2 May 2008 01:38:42 -0700
Subject: [Cython] Cython 0.9.6.14 released
Message-ID: <463FD591-1904-4CD0-A67B-0EBB62AB6A4E@math.washington.edu>

Cython 0.9.6.14 is out. This is mostly a bugfix release, however  
there are several other improvements, notably:

- Source code encoding support (PEP 263) and UTF-8 default source  
encoding (PEP 3120) (Stefan Behnel)
- New command line option -w to change the working directory when  
running Cython (Gary Furnish)
- L.append(x) now optimized if L a (runtime) list (Robert Bradshaw)
- Cdef variables may be declared python builtin types (CEP 507),  
though there is much more potential for optimization (Robert Bradshaw)
- Enums declared "public" will get exported to the (python- 
accessible) module namespace (Robert Bradshaw)
- Correct special float values (Christian Heimes/Stefan Behnel)

Thanks also to all those who submitted good bug reports as well.

- Robert


From robertwb at math.washington.edu  Fri May  2 10:40:11 2008
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Fri, 2 May 2008 01:40:11 -0700
Subject: [Cython] Cython 0.9.6.14 release candidate
In-Reply-To: <20080502074637.GB10755@evo>
References: <AB81C4C8-C77B-49C2-BE77-E2483811ADAD@math.washington.edu>
	<fvcb5t$bs1$1@ger.gmane.org> <4819F55E.5010909@behnel.de>
	<fvctcc$9ed$1@ger.gmane.org> <4819FBF7.9030901@behnel.de>
	<fvd0eb$kbh$2@ger.gmane.org> <481A079E.8030705@behnel.de>
	<fvd36i$tsb$1@ger.gmane.org> <20080502055844.GA10755@evo>
	<481ABF06.7020707@behnel.de> <20080502074637.GB10755@evo>
Message-ID: <CE708A39-DD18-405C-A8DB-A70AA0C46ABC@math.washington.edu>

On May 2, 2008, at 12:46 AM, Kirill Smelkov wrote:

> Hi Stefan,
>
> On Fri, May 02, 2008 at 09:13:10AM +0200, Stefan Behnel wrote:
>> Hi,
>>
>> Kirill Smelkov wrote:
>>> I still have 3 failures with latest cython-devel (b869698d6f22)
>>> Attached is a log of 'python runtests.py' run on Debian testing.
>>
>> Thanks. That's running against Python 2.4, while the two tests  
>> were depending
>> on Python 2.5 specifics (an exception message and new style  
>> exception types).
>> I relaxed them a bit to run on Py2.3-2.5.
>>
>> The test runner script also prints the versions of Cython and  
>> Python now, to
>> put some more context into the test log.
>
> kirr at evo:~/src/tools/cython/cython-devel$ python runtests.py
> Running tests against Cython 0.9.6.13.1
> Python 2.4.5 (#2, Mar 12 2008, 00:15:51)
> [GCC 4.2.3 (Debian 4.2.3-2)]
>
> ...
>
> Ran 213 tests in 243.547s
>
> OK
>
> ----
>
> Thanks!

Thanks for fixing this. It didn't make it into Cython 0.9.6.14 (which  
I pushed out this morning) but at least it's a bug in the testing  
code rather than in the compiler itself, and these changes will  
certainly be in the next release.

- Robert


From dagss at student.matnat.uio.no  Fri May  2 13:22:35 2008
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Fri, 02 May 2008 13:22:35 +0200
Subject: [Cython] Some small phase refactorings
Message-ID: <481AF97B.8030305@student.matnat.uio.no>

This isn't much, but it is a start.

Phase refactoring seems like it will become a bit difficult and I think 
it is better left for dev1 if possible; I need to work with someone who 
know the source more intimately. It appears that some parts must almost 
be "rebuilt" or at least control flow heavily altered between 
statements, it is all about keeping the changes to a minimum... the good 
news is that a certain amount of spaghetti will disappear through the 
process (you know -- the things that break in a different part of the 
code when you change another part in the code; while not necesarrily the 
root of all evil, it does make it harder to get to know a codebase).

But I have patch for some trivial stuff at the "top" of the call chain 
that at least is a good point for discussion (if somebody else cares how 
this is done). It can be found here:

http://wiki.cython.org/DagSverreSeljebotn/patches?action=AttachFile&do=get&target=phaserefactoring1.diff

and succeeds the testcases; I consider it ready for inclusion.

Basically, what it does is turn this (psuedo-code describing overall 
structure, you won't find this anywhere):

for each function in module:
  construct_function_scope
  analyse_control_flow
  analyse_declarations
  analyse_expressions
  generate_code

into

for each function in module: construct_function_scope
for each function in module: analyse_control_flow
for each function in module: analyse_declarations
for each function in module: analyse_expressions
for each function in module: generate_code

However, each of these are in turn run as recursive calls just like 
before. In particular, analyse_expressions is still one phase and not 
easily seperateable (it should be split in three I think: analyse types, 
coercion, allocate temps).

Also, these are all "function-level"; on module-level things happen like 
before, i.e. analyse_declarations in the module level is run at another 
time (and for the nearest future it should remain this way; just 
consider module-level and function-level analysis different phases).

The new code is implemented using visitor transforms. One could argue 
about this, but I do think it leads to pretty neat code. The third 
for-loop in the psuedo-code above is this implemented like this:

Cython/Compiler/Transforms/Analysis.py [is this source structure ok?]:

class AnalyseFunctionBodyDeclarations(VisitorTransform):
    def pre_FuncDefNode(self, node):
        node.body.analyse_declarations(node.scope)
        return False # do not recurse beyond first function level

Cython/Compiler/ModuleNode.py:

class ModuleNode:
    def generate_c_code(self, env, options, result):
        ...
        import Cython.Compiler.Transforms.Analysis as Analysis
        ...
        Analysis.AnalyseFunctionBodyDeclarations()(self, env=env)
        ...
        self.body.generate_function_definitions(env, code, 
options.transforms)
        ...


The only non-trivial part is that the function scope is constructed by a 
tree transform that adds the "scope" and "scopenode" attributes in the 
following way: The FuncDefNodes and ModuleNodes gets their "scope" 
attribute set to the object that was previously passed around everywhere 
as the "env" parameter (this is then read back in order to pass the 
"env" correctly). All nodes also have their "scopenode" attribute set to 
the node that caused creation of the enclosing scope. I.e., rather than 
relying on a passed in env passed recursively from the function/module, 
it is possible for nodes to look up self.scopenode.scope. This will aid 
seperation of phases.

-- 
Dag Sverre


From dagss at student.matnat.uio.no  Fri May  2 13:38:53 2008
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Fri, 02 May 2008 13:38:53 +0200
Subject: [Cython] Visitor patterns and Python 2.4
Message-ID: <481AFD4D.4050401@student.matnat.uio.no>

Are there any real reasons for leaving the Cython compiler (not talking 
about generated or supported code of course) at Python 2.3, rather than 
a small bump to 2.4? Reason: I'd like decorators.

The rationale: Notice that parse tree visitors can currently be written 
like this:

class AnalyseControlFlow(VisitorTransform):
    def pre_FuncDefNode(self, node):
        node.body.analyse_control_flow(node.scope)
        return False # do not recurse beyond first function level


The VisitorTransform parent implements a tree iteration/recursion and 
calls "pre_X" which is only allowed to visit and stop recursion at that 
point, "process_X" which has full control (can replace or remove node, 
do various infix processing -- if "process_X" is implemented, pre and 
post are not called) and "post_X" (which only visits)).

VisitorTransform basically looks up node.__class__.__name__ to figure 
out the name of the function to call, and uses introspection. Things are 
cached.

There are two disadvantages to this though:
- Relying on node.__class__.__name__ is a bit fragile. Multiple; and 
simply changing a class. It would be better to use a real reference

- If using multiple instances of a Transform class, each instance have 
to rebuild their call table cache. (This is not a real issue though, I 
don't expect such cases to come up.) Using a metaclass, the call table 
could however be done at class definition time which is "nicer". This is 
not a good reason.

If bumping the version to 2.4, decorators can solve this. OTOH, I'd much 
rather do with function names rather than "manually calling decorators". 
The example above could then look like this:

class AnalyseControlFlow(VisitorTransform):
    @pre(FuncDefNode)
    def call_analyse_control_flow(self, node):
        node.body.analyse_control_flow(node.scope)
        return False # do not recurse beyond first function level

This has the advantage that the class is directly references rather than 
being embedded in a string, so that name clashes, class renaming etc 
works correctly. Like this:

from Nodes import FuncDefNode
funcdef = FuncDefNode

class AnalyseControlFlow(VisitorTransform):
    @pre(funcdef)
    def call_analyse_control_flow(self, node):
        ...

Note that the standard visitor pattern (implementing accept on each and 
every node) was shot down by Fabrizio earlier (in private communication) 
as wasting code lines and unpythonic, and I guess I agree, so I 
implemented his suggestion instead. (The only reason I can see is speed 
when running under Cython compilation, if one uses "cdef" and 
compilation binding so that a dictionary lookups happen anyway. Not the 
thing to worry about at this stage IMO.)

-- 
Dag Sverre


From stefan_ml at behnel.de  Sat May  3 07:53:30 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 03 May 2008 07:53:30 +0200
Subject: [Cython] Some small phase refactorings
In-Reply-To: <481AF97B.8030305@student.matnat.uio.no>
References: <481AF97B.8030305@student.matnat.uio.no>
Message-ID: <481BFDDA.8060007@behnel.de>

Hi,

since no-one replied so far (and since I think public code-review is
important), here I go. Lines starting with ### are mine.

In general, I'm +0 for the change and -0 for the patch. I think, if we use
transformations, there should be a good way to subscribe them to what they
work on. We brought up the idea of a path language, but maybe a subscription
to an AST class and just calling the transform to let it return either the
unchanged input or a modified AST subtree might already be enough.


diff -r 3c924a0594ba Cython/Compiler/ModuleNode.py
--- a/Cython/Compiler/ModuleNode.py	Fri May 02 10:22:20 2008 +0200
+++ b/Cython/Compiler/ModuleNode.py	Fri May 02 11:42:17 2008 +0200
@@ -33,7 +33,7 @@ class ModuleNode(Nodes.Node, Nodes.Block
     #  module_temp_cname    string
     #  full_module_name     string

-    children_attrs = ["body"]
+    child_attrs = ["body"]

     def analyse_declarations(self, env):
         if Options.embed_pos_in_docstring:

### This looks like a separate fix to me.


+        import Cython.Compiler.Transforms.Analysis as Analysis
+        Analysis.CreateFunctionScope()(self, env=env)
+        Analysis.AnalyseControlFlow()(self, env=env)
+        Analysis.AnalyseFunctionBodyDeclarations()(self, env=env)
+        Analysis.AnalyseFunctionBodyExpressions()(self, env=env)
+        options.transforms.run('after_function_analysis', self, global_env=env)
+

### These look like functions, they should follow PEP 8 naming. Then again,
### why aren't they functions?


+    def get_visitfunc(self, prefix, cls):
+        mname = prefix + cls.__name__
+        m = self.visitmethods[prefix].get(mname)
+        if m is None:
+            # Must resolve, try entire hierarchy
+            for cls in inspect.getmro(cls):
+                m = getattr(self, prefix + cls.__name__, None)
+                if m is not None:
+                    break
+            if m is None: raise RuntimeError("Not a Node descendant: " + node)
+            self.visitmethods[prefix][mname] = m
+        return m

### I'm not convinced of this one. I understand why you do it, but I believe
### that using the class itself rather than dispatching on a string would help
### here (I saw your decorator proposal - still thinking about it, but might
### be worth doing).


@@ -110,7 +174,6 @@ class TransformSet(dict):
     def run(self, name, node, **options):
         assert name in self
         for transform in self[name]:
-            transform.initialize(phase=name, **options)
-            transform.process_node(node, "(root)")
+            transform(node, phase=name, **options)

### I like this part.


From stefan_ml at behnel.de  Sat May  3 07:56:42 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 03 May 2008 07:56:42 +0200
Subject: [Cython] Visitor patterns and Python 2.4
In-Reply-To: <481AFD4D.4050401@student.matnat.uio.no>
References: <481AFD4D.4050401@student.matnat.uio.no>
Message-ID: <481BFE9A.4080600@behnel.de>

Hi,

Dag Sverre Seljebotn wrote:
> Are there any real reasons for leaving the Cython compiler (not talking 
> about generated or supported code of course) at Python 2.3, rather than 
> a small bump to 2.4? Reason: I'd like decorators.
> 
> The rationale: Notice that parse tree visitors can currently be written 
> like this:
> 
> class AnalyseControlFlow(VisitorTransform):
>     def pre_FuncDefNode(self, node):
>         node.body.analyse_control_flow(node.scope)
>         return False # do not recurse beyond first function level

If this way of doing it is accepted, I'm actually for accepting 2.4 code. I
don't know any important platform that doesn't come with at least Py2.4. And
note that most people won't even need to run Cython themselves, even if they
use software implemented in Cython.

Stefan

From dagss at student.matnat.uio.no  Sat May  3 10:27:16 2008
From: dagss at student.matnat.uio.no (Dag Sverre Seljebotn)
Date: Sat, 3 May 2008 10:27:16 +0200 (CEST)
Subject: [Cython] Some small phase refactorings
In-Reply-To: <481BFDDA.8060007@behnel.de>
References: <481AF97B.8030305@student.matnat.uio.no>
	<481BFDDA.8060007@behnel.de>
Message-ID: <1078.195.159.185.117.1209803236.squirrel@webmail.uio.no>

Thanks for the feedback.

> -    children_attrs = ["body"]
> +    child_attrs = ["body"]
>
>
> ### This looks like a separate fix to me.

Indeed (sorry).

>
> +        import Cython.Compiler.Transforms.Analysis as Analysis
> +        Analysis.CreateFunctionScope()(self, env=env)
> +        Analysis.AnalyseControlFlow()(self, env=env)
> +        Analysis.AnalyseFunctionBodyDeclarations()(self, env=env)
> +        Analysis.AnalyseFunctionBodyExpressions()(self, env=env)
> +        options.transforms.run('after_function_analysis', self,
> global_env=env)
> +
>
> ### These look like functions, they should follow PEP 8 naming. Then
> again,
> ### why aren't they functions?

Note that this code will almost certainly be moved again and rewritten at
some later point (they can't really belong to ModuleNode); but more
refactoring must happen before they can be moved to their proper location
and they serve a good purpose where they are for now though.

They have to be classes as they are transform objects with member methods,
some state etc. etc. But thinking about it one could have functions like
this in Analysis.py:

def analyse_function_body_declarations(tree, **opts):
    return AnalyseFunctionBodyDeclarations()(tree, **opts)

if that helps. The reason I started using the __call__ is that I think in
time one can treat these as functions, like this:

pipeline = [
   f,
   g,
   AnalyseFunctionBodyDeclarations(),
   Coercions(),
]
for transform in pipeline:
   tree = transform(tree)

(ie, basically saying that "pipeline = f <ring> g <ring> h"...)


> ### I'm not convinced of this one. I understand why you do it, but I
> believe
> ### that using the class itself rather than dispatching on a string would
> help
> ### here (I saw your decorator proposal - still thinking about it, but
> might
> ### be worth doing).

If not, then the classical visitor pattern might put you at ease?:

class FuncDefNode:
    def accept(self, visitor):
        visitor.visit_FuncDefNode(self)

However, that's a lot of extra trivial code to add (this would have to be
added to _all_ classes), and when one is using Python anyway I'd like to
avoid pretending I'm writing Java... :-)

I hope we can start using Python 2.4, then I'll implement a
decorator/metaclass solution instead.


In conclusion, I'd like to mention that I really think the important thing
here is to consider the "grand, large-scale" features of the patch. I
didn't polish the details in any way, because I think that what is
important here is the changes they make possible in the application
structure. How the visitors look like can be changed entirely in
Visitor.py and Analysis.py without interfering with existing code; while
the phase refactoring is going to intrude everywhere and make changes all
over the place, so the form the phase refactoring will take is the
important point.

(OTOH; I guess it is a good time to think about the details as well so
that when the 1000 line coercion refactoring patch should be written one
knows what to do in the details...)

(I've asked myself as to whether it is all worth it BTW. It is a heavy and
non-fun task. But I'm still convinced there's absolutely no way around it
if the feature-set of Cython is to grow significantly in any way. And
realistically, it can be done in two or three days with for instance me,
you and Robert working together... So this might be too early to talk
about it; but I end up working on it anyway because it is effectively a
blocker for me and I cannot get anywhere with my GSoC stuff until it is
done :-) )

Dag Sverre


From kirr at mns.spb.ru  Sat May  3 18:21:36 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sat, 03 May 2008 20:21:36 +0400
Subject: [Cython] [PATCH 2 of 3] Fix cimport example in "Sharing
	Declarations" section
In-Reply-To: <patchbomb.1209831694@tugrik2.mns.mnsspb.ru>
Message-ID: <a81645475dc33f1916f6.1209831696@tugrik2.mns.mnsspb.ru>

# HG changeset patch
# User Kirill Smelkov <kirr at mns.spb.ru>
# Date 1209831534 -14400
# Node ID a81645475dc33f1916f6dc7ee5ec8f52141b20e8
# Parent  0745e2b1f904c2ab8b7c70218d59bd933cbbe3ab
Fix cimport example in "Sharing Declarations" section

- we need to define struct variables with 'cdef'
- there is no -> in Cython/Pyrex

diff --git a/docs/sharing_declarations.rst b/docs/sharing_declarations.rst
--- a/docs/sharing_declarations.rst
+++ b/docs/sharing_declarations.rst
@@ -82,9 +82,9 @@ uses it.
         d.filler = dishes.sausage
 
     def serve():
-        spamdish d
+        cdef spamdish d
         prepare(&d)
-        print "%d oz spam, filler no. %d" % (d->oz_of_spam, d->otherstuff)
+        print "%d oz spam, filler no. %d" % (d.oz_of_spam, d.otherstuff)
                                
 It is important to understand that the :keyword:`cimport` statement can only
 be used to import C data types, C functions and variables, and extension

From kirr at mns.spb.ru  Sat May  3 18:21:37 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sat, 03 May 2008 20:21:37 +0400
Subject: [Cython] [PATCH 3 of 3] Reminder to put the table about styles of
	struct, union and enum declarations
In-Reply-To: <patchbomb.1209831694@tugrik2.mns.mnsspb.ru>
Message-ID: <630bbffdd62e0e82c551.1209831697@tugrik2.mns.mnsspb.ru>

# HG changeset patch
# User Kirill Smelkov <kirr at mns.spb.ru>
# Date 1209831643 -14400
# Node ID 630bbffdd62e0e82c551334cbf4579b751859248
# Parent  a81645475dc33f1916f6dc7ee5ec8f52141b20e8
Reminder to put the table about styles of struct, union and enum declarations

diff --git a/docs/external_C_code.rst b/docs/external_C_code.rst
--- a/docs/external_C_code.rst
+++ b/docs/external_C_code.rst
@@ -158,6 +158,8 @@ header file, and the corresponding Cytho
 header file, and the corresponding Cython declaration that you should put in
 the ``cdef extern`` from block. Struct declarations are used as an example; the
 same applies equally to union and enum declarations.
+
+**TODO** put table here...
 
 Note that in all the cases below, you refer to the type in Cython code simply
 as :ctype:`Foo`, not ``struct Foo``.

From kirr at mns.spb.ru  Sat May  3 18:21:35 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sat, 03 May 2008 20:21:35 +0400
Subject: [Cython] [PATCH 1 of 3] Fix typos in documentation here and there
In-Reply-To: <patchbomb.1209831694@tugrik2.mns.mnsspb.ru>
Message-ID: <0745e2b1f904c2ab8b7c.1209831695@tugrik2.mns.mnsspb.ru>

# HG changeset patch
# User Kirill Smelkov <kirr at mns.spb.ru>
# Date 1209831403 -14400
# Node ID 0745e2b1f904c2ab8b7c70218d59bd933cbbe3ab
# Parent  bc0d87c4a2953e32beed52bdb461bba99a7adda5
Fix typos in documentation here and there

diff --git a/docs/extension_types.rst b/docs/extension_types.rst
--- a/docs/extension_types.rst
+++ b/docs/extension_types.rst
@@ -209,25 +209,26 @@ time it is written to, returns the list 
 time it is written to, returns the list when it is read, and empties the list
 when it is deleted.::
  
-    #cheesy.pyx 	Test input
+    # cheesy.pyx
     cdef class CheeseShop:
 
-    cdef object cheeses
+        cdef object cheeses
 
-    def __cinit__(self):
-        self.cheeses = []
+        def __cinit__(self):
+            self.cheeses = []
 
-    property cheese:
+        property cheese:
 
-        def __get__(self):
-            return "We don't have: %s" % self.cheeses
+            def __get__(self):
+                return "We don't have: %s" % self.cheeses
 
-        def __set__(self, value):
-            self.cheeses.append(value)
+            def __set__(self, value):
+                self.cheeses.append(value)
 
-        def __del__(self):
-            del self.cheeses[:]
+            def __del__(self):
+                del self.cheeses[:]
 
+    # Test input
     from cheesy import CheeseShop
 
     shop = CheeseShop()
@@ -242,7 +243,7 @@ when it is deleted.::
     del shop.cheese
     print shop.cheese
 
-    #Test output
+    # Test output
     We don't have: []
     We don't have: ['camembert']
     We don't have: ['camembert', 'cheddar']
@@ -280,18 +281,17 @@ functions, C methods are declared using 
 :keyword:`def`. C methods are "virtual", and may be overridden in derived
 extension types.::
 
-    pets.pyx
-            Output
+    # pets.pyx
     cdef class Parrot:
 
-    cdef void describe(self):
-        print "This parrot is resting."
+        cdef void describe(self):
+            print "This parrot is resting."
 
     cdef class Norwegian(Parrot):
 
-    cdef void describe(self):
-        Parrot.describe(self)
-        print "Lovely plumage!"
+        cdef void describe(self):
+            Parrot.describe(self)
+            print "Lovely plumage!"
 
 
     cdef Parrot p1, p2
@@ -301,7 +301,9 @@ extension types.::
     p1.describe()
     print "p2:"
     p2.describe()
-            p1:
+
+    # Output
+    p1:
     This parrot is resting.
     p2:
     This parrot is resting.
diff --git a/docs/external_C_code.rst b/docs/external_C_code.rst
--- a/docs/external_C_code.rst
+++ b/docs/external_C_code.rst
@@ -293,18 +293,16 @@ Any public C type or extension type decl
 Any public C type or extension type declarations in the Cython module are also
 made available when you include :file:`modulename_api.h`.::
 
-    delorean.pyx
-
-    marty.c
-
+    # delorean.pyx
     cdef public struct Vehicle:
-    int speed
-    float power
+        int speed
+        float power
 
     cdef api void activate(Vehicle *v):
         if v.speed >= 88 and v.power >= 1.21:
             print "Time travel achieved"
 
+    # marty.c
     #include "delorean_api.h"
 
     Vehicle car;
diff --git a/docs/language_basics.rst b/docs/language_basics.rst
--- a/docs/language_basics.rst
+++ b/docs/language_basics.rst
@@ -327,7 +327,7 @@ Error return values
 Error return values
 -------------------
 
-If you don't do anything special, a function declared with :keyword`cdef` that
+If you don't do anything special, a function declared with :keyword:`cdef` that
 does not return a Python object has no way of reporting Python exceptions to
 its caller. If an exception is detected in such a function, a warning message
 is printed and the exception is ignored.
@@ -520,7 +520,7 @@ statements, combined using any of the Py
 statements, combined using any of the Python expression syntax.
 
 The following compile-time names are predefined, corresponding to the values
-returned by :func:``os.uname``.
+returned by :func:`os.uname`.
 
     UNAME_SYSNAME, UNAME_NODENAME, UNAME_RELEASE,
     UNAME_VERSION, UNAME_MACHINE
diff --git a/docs/pyrex_differences.rst b/docs/pyrex_differences.rst
--- a/docs/pyrex_differences.rst
+++ b/docs/pyrex_differences.rst
@@ -108,7 +108,7 @@ python. One can declare variables and re
 :ctype:`bint` type.  For example::
 
     cdef int i = x
-    Cdef bint b = x
+    cdef bint b = x
 
 The first conversion would happen via ``x.__int__()`` whereas the second would
 happen via ``x.__nonzero__()``. (Actually, if ``x`` is the python object
@@ -156,7 +156,7 @@ method on the class directly, e.g.::
 
     cdef class A:
         cpdef foo(self):
-        pass
+            pass
 
     x = A()
     x.foo()  # will check to see if overridden
@@ -197,10 +197,10 @@ It does not stop one from casting where 
 It does not stop one from casting where there is no conversion (though it will
 emit a warning). If one really wants the address, cast to a ``void *`` first.
 
-As in Pyrex ``<MyExtensionType>x`` will cast ``x`` to type <ctype>`MyExtensionType` without any
+As in Pyrex ``<MyExtensionType>x`` will cast ``x`` to type :ctype:`MyExtensionType` without any
 type checking. Cython supports the syntax ``<MyExtensionType?>`` to do the cast
 with type checking (i.e. it will throw an error if ``x`` is not a (subclass of)
-<ctype>`MyExtensionType`. 
+:ctype:`MyExtensionType`. 
 
 Optional arguments in cdef/cpdef functions
 ------------------------------------------
diff --git a/docs/sharing_declarations.rst b/docs/sharing_declarations.rst
--- a/docs/sharing_declarations.rst
+++ b/docs/sharing_declarations.rst
@@ -16,7 +16,12 @@ modules, and an implementation file with
 modules, and an implementation file with a ``.pyx`` suffix, containing
 everything else. When a module wants to use something declared in another
 module's definition file, it imports it using the :keyword:`cimport`
-statement.  What a Definition File contains A definition file can contain:
+statement.
+
+What a Definition File contains
+-------------------------------
+
+A definition file can contain:
 
 * Any kind of C type declaration.
 * extern C function or variable declarations.
@@ -139,11 +144,11 @@ C functions defined at the top level of 
 :keyword:`cimport` by putting headers for them in the ``.pxd`` file, for
 example,:
 
-:file:`volume.pxd`:
+:file:`volume.pxd`::
+
+    cdef float cube(float)
 
 :file:`spammery.pyx`::
-
-    cdef float cube(float)
 
     from volume cimport cube
 
@@ -185,17 +190,22 @@ Here is an example of a module which def
 Here is an example of a module which defines and exports an extension type,
 and another module which uses it.::
  
-    Shrubbing.pxd 	Shrubbing.pyx
+    # Shrubbing.pxd
     cdef class Shrubbery:
         cdef int width
-        cdef int length 	cdef class Shrubbery:
+        cdef int length
+        
+    # Shrubbing.pyx
+    cdef class Shrubbery:
         def __new__(self, int w, int l):
             self.width = w
             self.length = l
 
     def standard_shrubbery():
         return Shrubbery(3, 7)
-    Landscaping.pyx
+
+
+    # Landscaping.pyx
     cimport Shrubbing
     import Shrubbing
 

From kirr at mns.spb.ru  Sat May  3 18:21:34 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sat, 03 May 2008 20:21:34 +0400
Subject: [Cython] [PATCH 0 of 3] Various fixes to documentation
Message-ID: <patchbomb.1209831694@tugrik2.mns.mnsspb.ru>

Hi,

While studying (again!) Cython/Pyrex, I've fixed few bits in the documentation.

Three patches attached, please apply.

Thanks!

From ggellner at uoguelph.ca  Sat May  3 19:53:48 2008
From: ggellner at uoguelph.ca (Gabriel Gellner)
Date: Sat, 3 May 2008 13:53:48 -0400
Subject: [Cython] [PATCH 0 of 3] Various fixes to documentation
In-Reply-To: <patchbomb.1209831694@tugrik2.mns.mnsspb.ru>
References: <patchbomb.1209831694@tugrik2.mns.mnsspb.ru>
Message-ID: <20080503175348.GA13881@basestar>

On Sat, May 03, 2008 at 08:21:34PM +0400, Kirill Smelkov wrote:
> Hi,
> 
> While studying (again!) Cython/Pyrex, I've fixed few bits in the documentation.
> 
> Three patches attached, please apply.
> 
Thanks for all the changes! I have applied them.

For future reference the source is now at:
http://hg.cython.org/cython-docs
(I have not pushed the new file upstream yet, but I will do it as soon as I
can. You can see the changes in the website and pdf).

Gabriel

From pete at petertodd.org  Sun May  4 07:15:32 2008
From: pete at petertodd.org (Peter Todd)
Date: Sun, 4 May 2008 01:15:32 -0400
Subject: [Cython] __getattribute__
In-Reply-To: <5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>
References: <20080430004208.GJ15181@tilt>
	<5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>
Message-ID: <20080504051532.GA7720@tilt>

On Wed, Apr 30, 2008 at 06:17:31PM -0700, Robert Bradshaw wrote:
> On Apr 29, 2008, at 5:42 PM, Peter Todd wrote:
> 
> >Is there a __getattribute__ work-alike in Cython?
> >
> >Essentially I need direct control over an objects tp_getattro and
> >tp_setattro slots to implement a wrapper class. Specificly
> >wrapped.__class__ should go to the wrapped objects class attribute,  
> >not
> >the wrapping objects __class__ attribute.
> >
> >__getattr__ outputs C-source that includes a call to
> >PyObject_GenericGetAttr first, and won't run my code if that call
> >succeeds.
> >
> >Thanks,
> >
> >Peter
> 
> Not that I'm aware of, though I'd imagine that implementing  
> __getattribute__ (if it exists) as being called at the top of this  
> function would be fairly easy to do. One would want to match Python  
> symantics exactly.

Here's my first patch. This correctly implements __getattribute__ and
__getattr__ in the single class case. FWIW I also have a mercurial tree
if it'd be better to pull from it than apply patches.

I'm working on making subclasses behave correctly, I've got test cases
written up showing where things fail, but no solutions to that written
yet. The slot_tp_getattro stuff Stefan mentioned is useful though.

-- 
http://petertodd.org 'peter'[:-1]@petertodd.org 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: __getattribute__.patch
Type: text/x-diff
Size: 4799 bytes
Desc: not available
Url : http://codespeak.net/pipermail/cython-dev/attachments/20080504/376ae4c6/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://codespeak.net/pipermail/cython-dev/attachments/20080504/376ae4c6/attachment.pgp 

From kirr at mns.spb.ru  Sun May  4 10:20:56 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 04 May 2008 12:20:56 +0400
Subject: [Cython] [PATCH 2 of 2] Initial .hgignore
In-Reply-To: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
Message-ID: <aaa56370d9fb26ca99e2.1209889256@tugrik2.mns.mnsspb.ru>

# HG changeset patch
# User Kirill Smelkov <kirr at mns.spb.ru>
# Date 1209814507 -14400
# Node ID aaa56370d9fb26ca99e2aa774e373b7383ffd685
# Parent  2fe2f4f4e58972b2a3eb106964cd68db12d88e0e
Initial .hgignore

We ignore *.pyc, vim swap files, build results under BUILD/ and Lexicon.pickle

This is handy, because otherwise, say after runtest.py run, 'hg status' shows
lots of unrelated info, thus lowering signal-to-noise ratio.

diff --git a/.hgignore b/.hgignore
new file mode 100644
--- /dev/null
+++ b/.hgignore
@@ -0,0 +1,8 @@
+syntax: glob
+
+*.pyc
+*.swp
+
+Cython/Compiler/Lexicon.pickle
+BUILD/
+

From kirr at mns.spb.ru  Sun May  4 10:20:54 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 04 May 2008 12:20:54 +0400
Subject: [Cython] [PATCH 0 of 2] A couple of handy patches when using cython
	in-tree
Message-ID: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>

Hi,

Here is a couple of handy patches for the case when cython is used "in-tree",
i.e. when no installation is done.

- First we need to 'chmod a+x' relevant files in bin/ ,
- and second, it would be convenient to finally create reasonable .hgignore

Please apply.

From kirr at mns.spb.ru  Sun May  4 10:20:55 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 04 May 2008 12:20:55 +0400
Subject: [Cython] [PATCH 1 of 2] chmod a+x bin/*
In-Reply-To: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
Message-ID: <2fe2f4f4e58972b2a3eb.1209889255@tugrik2.mns.mnsspb.ru>

# HG changeset patch
# User Kirill Smelkov <kirr at mns.spb.ru>
# Date 1209814181 -14400
# Node ID 2fe2f4f4e58972b2a3eb106964cd68db12d88e0e
# Parent  3c924a0594baee13d595e66de8577fcd1691ee7c
chmod a+x bin/*

This is handy when using cython right from development tree

diff --git a/bin/cython b/bin/cython
old mode 100644
new mode 100755
diff --git a/bin/update_references b/bin/update_references
old mode 100644
new mode 100755

From kirr at mns.spb.ru  Sun May  4 11:12:23 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 4 May 2008 13:12:23 +0400
Subject: [Cython] [PATCH 0 of 3] Various fixes to documentation
In-Reply-To: <20080503175348.GA13881@basestar>
References: <patchbomb.1209831694@tugrik2.mns.mnsspb.ru>
	<20080503175348.GA13881@basestar>
Message-ID: <200805041312.23099.kirr@mns.spb.ru>

? ????????? ?? ??????? 03 ??? 2008 Gabriel Gellner ???????(a):
> On Sat, May 03, 2008 at 08:21:34PM +0400, Kirill Smelkov wrote:
> > Hi,
> > 
> > While studying (again!) Cython/Pyrex, I've fixed few bits in the documentation.
> > 
> > Three patches attached, please apply.
> > 
> Thanks for all the changes! I have applied them.

Thanks!

Kirill.

From stefan_ml at behnel.de  Sun May  4 11:18:27 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 04 May 2008 11:18:27 +0200
Subject: [Cython] [PATCH 0 of 2] A couple of handy patches when using
 cython	in-tree
In-Reply-To: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
Message-ID: <481D7F63.5030402@behnel.de>

Hi,

Kirill Smelkov wrote:
> Here is a couple of handy patches for the case when cython is used "in-tree",
> i.e. when no installation is done.
> 
> - First we need to 'chmod a+x' relevant files in bin/ ,
> - and second, it would be convenient to finally create reasonable .hgignore

Thanks, your patches are appreciated. Still, for the next time, could you send
a bundle of changesets (hg bundle) instead of one mail per patch? Although
this list is called "cython-dev", it's a somewhat general purpose list for
Cython, so many people who read it do not care about small fixes and changes.

Thanks,
Stefan

From kirr at mns.spb.ru  Sun May  4 12:08:03 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 4 May 2008 14:08:03 +0400
Subject: [Cython]
	=?utf-8?q?=5BPATCH_0_of_2=5D_A_couple_of_handy_patches_w?=
	=?utf-8?q?hen_using_cython=09in-tree?=
In-Reply-To: <481D7F63.5030402@behnel.de>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481D7F63.5030402@behnel.de>
Message-ID: <200805041408.03746.kirr@mns.spb.ru>

Hi,

? ????????? ?? ??????????? 04 ??? 2008 Stefan Behnel ???????(a):
> Hi,
> 
> Kirill Smelkov wrote:
> > Here is a couple of handy patches for the case when cython is used "in-tree",
> > i.e. when no installation is done.
> > 
> > - First we need to 'chmod a+x' relevant files in bin/ ,
> > - and second, it would be convenient to finally create reasonable .hgignore
> 
> Thanks, your patches are appreciated. Still, for the next time, could you send
> a bundle of changesets (hg bundle) instead of one mail per patch? Although
> this list is called "cython-dev", it's a somewhat general purpose list for
> Cython, so many people who read it do not care about small fixes and changes.

Stefan, I see your points.

I used 'hg email --outgoing' to send my patches, so if i want it to be sent as
bundle, I'd use 'hg email --bundle'.

I see one problem with this approach though: bundle is a binary file, and if
someone would like to comment on the patch itself - he'll need to manually
paste relevant chunks into reply mail.

I understand this list is general purpose, so maybe it would be good idea to
create separate list for patches? e.g. cython-patches at codespeak.net

Then sending patches there in plain text would be ok for all:

- readable patches right in email client
- ready-to apply patches right from email client  (one button in mutt)
- easy to comment on patches

This is common technique, and for example we do this in sympy-patches:

http://groups.google.com/group/sympy-patches/

What do you think?

Kirill.

From gfurnish at gfurnish.net  Sun May  4 13:22:46 2008
From: gfurnish at gfurnish.net (Gary Furnish)
Date: Sun, 4 May 2008 05:22:46 -0600
Subject: [Cython] [PATCH 0 of 2] A couple of handy patches when using
	cython in-tree
In-Reply-To: <200805041408.03746.kirr@mns.spb.ru>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481D7F63.5030402@behnel.de> <200805041408.03746.kirr@mns.spb.ru>
Message-ID: <8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>

I strongly disagree.  Bundles are horrible for small changes.  Text
patches are easy to examine without using hg.  I should not have to
modify my repo to inspect a 3 line patch.

On Sun, May 4, 2008 at 4:08 AM, Kirill Smelkov <kirr at mns.spb.ru> wrote:
> Hi,
>
>  ? ????????? ?? ??????????? 04 ??? 2008 Stefan Behnel ???????(a):
>
> > Hi,
>  >
>  > Kirill Smelkov wrote:
>  > > Here is a couple of handy patches for the case when cython is used "in-tree",
>  > > i.e. when no installation is done.
>  > >
>  > > - First we need to 'chmod a+x' relevant files in bin/ ,
>  > > - and second, it would be convenient to finally create reasonable .hgignore
>  >
>  > Thanks, your patches are appreciated. Still, for the next time, could you send
>  > a bundle of changesets (hg bundle) instead of one mail per patch? Although
>  > this list is called "cython-dev", it's a somewhat general purpose list for
>  > Cython, so many people who read it do not care about small fixes and changes.
>
>  Stefan, I see your points.
>
>  I used 'hg email --outgoing' to send my patches, so if i want it to be sent as
>  bundle, I'd use 'hg email --bundle'.
>
>  I see one problem with this approach though: bundle is a binary file, and if
>  someone would like to comment on the patch itself - he'll need to manually
>  paste relevant chunks into reply mail.
>
>  I understand this list is general purpose, so maybe it would be good idea to
>  create separate list for patches? e.g. cython-patches at codespeak.net
>
>  Then sending patches there in plain text would be ok for all:
>
>  - readable patches right in email client
>  - ready-to apply patches right from email client  (one button in mutt)
>  - easy to comment on patches
>
>  This is common technique, and for example we do this in sympy-patches:
>
>  http://groups.google.com/group/sympy-patches/
>
>  What do you think?
>
>  Kirill.
>
>
> _______________________________________________
>  Cython-dev mailing list
>  Cython-dev at codespeak.net
>  http://codespeak.net/mailman/listinfo/cython-dev
>

From stefan_ml at behnel.de  Sun May  4 13:34:09 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 04 May 2008 13:34:09 +0200
Subject: [Cython] [PATCH 0 of 2] A couple of handy patches when using
 cython in-tree
In-Reply-To: <8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>	<481D7F63.5030402@behnel.de>
	<200805041408.03746.kirr@mns.spb.ru>
	<8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>
Message-ID: <481D9F31.7040800@behnel.de>

Hi,

Gary Furnish top-posted:
> I strongly disagree.  Bundles are horrible for small changes.  Text
> patches are easy to examine without using hg.  I should not have to
> modify my repo to inspect a 3 line patch.

Ok, what do you suggest then?

Stefan


From gfurnish at gfurnish.net  Sun May  4 13:51:28 2008
From: gfurnish at gfurnish.net (Gary Furnish)
Date: Sun, 4 May 2008 05:51:28 -0600
Subject: [Cython] [PATCH 0 of 2] A couple of handy patches when using
	cython in-tree
In-Reply-To: <481D9F31.7040800@behnel.de>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481D7F63.5030402@behnel.de> <200805041408.03746.kirr@mns.spb.ru>
	<8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>
	<481D9F31.7040800@behnel.de>
Message-ID: <8f8f8530805040451t3dfbea2cx670948fd8a8725b2@mail.gmail.com>

I agree with the suggestion to have a cython-patches mailing list,
either on google or codespeak.

On Sun, May 4, 2008 at 5:34 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
>  Gary Furnish top-posted:
>
> > I strongly disagree.  Bundles are horrible for small changes.  Text
>  > patches are easy to examine without using hg.  I should not have to
>  > modify my repo to inspect a 3 line patch.
>
>  Ok, what do you suggest then?
>
>  Stefan
>
>
>
>  _______________________________________________
>  Cython-dev mailing list
>  Cython-dev at codespeak.net
>  http://codespeak.net/mailman/listinfo/cython-dev
>

From stefan_ml at behnel.de  Sun May  4 14:27:09 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 04 May 2008 14:27:09 +0200
Subject: [Cython] code review
In-Reply-To: <8f8f8530805040451t3dfbea2cx670948fd8a8725b2@mail.gmail.com>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>	<481D7F63.5030402@behnel.de>
	<200805041408.03746.kirr@mns.spb.ru>	<8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>	<481D9F31.7040800@behnel.de>
	<8f8f8530805040451t3dfbea2cx670948fd8a8725b2@mail.gmail.com>
Message-ID: <481DAB9D.1070003@behnel.de>

Hi,

Gary Furnish top-posted again:
> I agree with the suggestion to have a cython-patches mailing list,
> either on google or codespeak.

I can ask on codespeak. However, wouldn't a tool like this be better:

http://codereview.appspot.com/

Guido pronounced he'd be open-sourcing it tomorrow (Apache 2 license).

http://comments.gmane.org/gmane.comp.python.python-3000.devel/13110

We could see how much work it would be to get it running with hg, and if it's
doable, maybe Robert and William could host it on their site, next to the hg
repositories?

Stefan


From gfurnish at gfurnish.net  Sun May  4 14:38:56 2008
From: gfurnish at gfurnish.net (Gary Furnish)
Date: Sun, 4 May 2008 06:38:56 -0600
Subject: [Cython] code review
In-Reply-To: <481DAB9D.1070003@behnel.de>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481D7F63.5030402@behnel.de> <200805041408.03746.kirr@mns.spb.ru>
	<8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>
	<481D9F31.7040800@behnel.de>
	<8f8f8530805040451t3dfbea2cx670948fd8a8725b2@mail.gmail.com>
	<481DAB9D.1070003@behnel.de>
Message-ID: <8f8f8530805040538o5ae2be44w333b7974e6894b44@mail.gmail.com>

Why not just use trac?  The interface is much nicer, and we could move
away from the slow and unfriendly launchpad at the same time (and we
could easily host it too).  It is not integrated with svn like
codereview is, but it does have the online patch viewer functionality,
and using trac saves us from having to port some other solution to hg.

--Gary

On Sun, May 4, 2008 at 6:27 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
>  Gary Furnish top-posted again:
>  > I agree with the suggestion to have a cython-patches mailing list,
>  > either on google or codespeak.
>
>  I can ask on codespeak. However, wouldn't a tool like this be better:
>
>  http://codereview.appspot.com/
>
>  Guido pronounced he'd be open-sourcing it tomorrow (Apache 2 license).
>
>  http://comments.gmane.org/gmane.comp.python.python-3000.devel/13110
>
>  We could see how much work it would be to get it running with hg, and if it's
>  doable, maybe Robert and William could host it on their site, next to the hg
>  repositories?
>
>  Stefan
>
>  _______________________________________________
>  Cython-dev mailing list
>  Cython-dev at codespeak.net
>  http://codespeak.net/mailman/listinfo/cython-dev
>

From kirr at mns.spb.ru  Sun May  4 14:55:31 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 4 May 2008 16:55:31 +0400
Subject: [Cython] code review
In-Reply-To: <481DAB9D.1070003@behnel.de>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<8f8f8530805040451t3dfbea2cx670948fd8a8725b2@mail.gmail.com>
	<481DAB9D.1070003@behnel.de>
Message-ID: <200805041655.31562.kirr@mns.spb.ru>

? ????????? ?? ??????????? 04 ??? 2008 Stefan Behnel ???????(a):
> Hi,
> 
> Gary Furnish top-posted again:
> > I agree with the suggestion to have a cython-patches mailing list,
> > either on google or codespeak.
> 
> I can ask on codespeak. However, wouldn't a tool like this be better:
> 
> http://codereview.appspot.com/
> 
> Guido pronounced he'd be open-sourcing it tomorrow (Apache 2 license).
> 
> http://comments.gmane.org/gmane.comp.python.python-3000.devel/13110

I'm looking forward for this!

Actually, for sympy-patches we already started to think about setting up,
say roundup instance somewhere, sitting and watching for mails on
sympy-patches. Then every review request will get into our issues tracker,
and every mail reply gets into tracker too, and also the whole thing could
be managed then from issues interface too.

I'm +1 for everything that would help manage reviews, but I think it should
integrate pretty well with plain old email and text editor.

Roundup has good email integration, and I hope Guido's tool do too.

Looking forward!
 
> We could see how much work it would be to get it running with hg, and if it's
> doable, maybe Robert and William could host it on their site, next to the hg
> repositories?

In SymPy we are too interested in such things, so the effort could be joined.

Kirill.

From stefan_ml at behnel.de  Sun May  4 14:58:38 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 04 May 2008 14:58:38 +0200
Subject: [Cython] code review
In-Reply-To: <8f8f8530805040538o5ae2be44w333b7974e6894b44@mail.gmail.com>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>	<481D7F63.5030402@behnel.de>
	<200805041408.03746.kirr@mns.spb.ru>	<8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>	<481D9F31.7040800@behnel.de>	<8f8f8530805040451t3dfbea2cx670948fd8a8725b2@mail.gmail.com>	<481DAB9D.1070003@behnel.de>
	<8f8f8530805040538o5ae2be44w333b7974e6894b44@mail.gmail.com>
Message-ID: <481DB2FE.70309@behnel.de>

Hi,

Gary Furnish continues to top-post:
> Why not just use trac?  The interface is much nicer [...] (and we
> could easily host it too).  It is not integrated with svn like
> codereview is, but it does have the online patch viewer functionality,

Hmm, I never used that. Would you know an example to look at? Is it just a
patch "viewer" or can you add comments? And if so, at what granularity? Per
patch? Per line?


> and using trac saves us from having to port some other solution to hg.

that is definitely a plus.


> the slow and unfriendly launchpad

Interesting. Why do you think so?

Stefan


From kirr at mns.spb.ru  Sun May  4 16:24:45 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 4 May 2008 18:24:45 +0400
Subject: [Cython]
	=?utf-8?q?=5BPATCH_0_of_2=5D_A_couple_of_handy_patches_w?=
	=?utf-8?q?hen_using_cython=09in-tree?=
In-Reply-To: <481D7F63.5030402@behnel.de>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481D7F63.5030402@behnel.de>
Message-ID: <200805041824.45735.kirr@mns.spb.ru>

Hi Stefan,

? ????????? ?? ??????????? 04 ??? 2008 Stefan Behnel ???????(a):
> Hi,
> 
> Kirill Smelkov wrote:
> > Here is a couple of handy patches for the case when cython is used "in-tree",
> > i.e. when no installation is done.
> > 
> > - First we need to 'chmod a+x' relevant files in bin/ ,
> > - and second, it would be convenient to finally create reasonable .hgignore
> 
> Thanks, your patches are appreciated.

I look here

http://hg.cython.org/cython-devel/

and still can't see they were applied.

Does it mean I have to do them another way, or am I missing something?

Thanks,
Kirill.




From gfurnish at gfurnish.net  Sun May  4 16:46:20 2008
From: gfurnish at gfurnish.net (Gary Furnish)
Date: Sun, 4 May 2008 08:46:20 -0600
Subject: [Cython] code review
In-Reply-To: <481DB2FE.70309@behnel.de>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481D7F63.5030402@behnel.de> <200805041408.03746.kirr@mns.spb.ru>
	<8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>
	<481D9F31.7040800@behnel.de>
	<8f8f8530805040451t3dfbea2cx670948fd8a8725b2@mail.gmail.com>
	<481DAB9D.1070003@behnel.de>
	<8f8f8530805040538o5ae2be44w333b7974e6894b44@mail.gmail.com>
	<481DB2FE.70309@behnel.de>
Message-ID: <8f8f8530805040746q3da11076l44c0709531f3a2bb@mail.gmail.com>

The canonical example of a project that uses trac is Sage:
http://trac.sagemath.org/sage_trac
It has good email integration (notify on ticket modification, etc,
although it is supposed to be even better in the next version).
Normally we attach patches to a ticket and then just comment them in
the ticket associated with the patch.  This associates the bug/feature
ticket with the patch (as opposed to needing two systems if you went
with something like codeview + launchpad).  Compared to trac,
launchpad is slow for webpage response time.  It is also slow on
ticket creation time (I can create a ticket for a given item in maybe
30 seconds on one page in trac, whereas launchpad has so much
complexity it is significantly more time consuming, requires a
multipage creation step, etc).

--Gary

On Sun, May 4, 2008 at 6:58 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
>  Gary Furnish continues to top-post:
>
> > Why not just use trac?  The interface is much nicer [...] (and we
>
> > could easily host it too).  It is not integrated with svn like
>  > codereview is, but it does have the online patch viewer functionality,
>
>  Hmm, I never used that. Would you know an example to look at? Is it just a
>  patch "viewer" or can you add comments? And if so, at what granularity? Per
>  patch? Per line?
>
>
>
>  > and using trac saves us from having to port some other solution to hg.
>
>  that is definitely a plus.
>
>
>
>  > the slow and unfriendly launchpad
>
>  Interesting. Why do you think so?
>
>  Stefan
>
>

From kirr at mns.spb.ru  Sun May  4 17:16:49 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 4 May 2008 19:16:49 +0400
Subject: [Cython] code review
In-Reply-To: <8f8f8530805040746q3da11076l44c0709531f3a2bb@mail.gmail.com>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481DB2FE.70309@behnel.de>
	<8f8f8530805040746q3da11076l44c0709531f3a2bb@mail.gmail.com>
Message-ID: <200805041916.49167.kirr@mns.spb.ru>

? ????????? ?? ??????????? 04 ??? 2008 Gary Furnish ???????(a):
> The canonical example of a project that uses trac is Sage:
> http://trac.sagemath.org/sage_trac
> It has good email integration (notify on ticket modification, etc,
> although it is supposed to be even better in the next version).

I'd like to clarify what I mean saying "good email integration":

  Good email integration is two-way

That is:

-> it is possible to affect state of the issues, add comments to patch review,
   etc... by sending mail.
<- you get notification mails, when someone changes something through web
   interface, or another way.


Personally, I think having the first entry is important - a lot of tasks could
be done via plain emails, and at least some people are more productive with
keyboard & text editor (compared to clicking with mouse) :)

Does Trac have two-way email integration?



> Normally we attach patches to a ticket and then just comment them in
> the ticket associated with the patch.  This associates the bug/feature
> ticket with the patch (as opposed to needing two systems if you went
> with something like codeview + launchpad).  Compared to trac,
> launchpad is slow for webpage response time.  It is also slow on
> ticket creation time (I can create a ticket for a given item in maybe
> 30 seconds on one page in trac, whereas launchpad has so much
> complexity it is significantly more time consuming, requires a
> multipage creation step, etc).

Gary, All, imagine you could create a patch issue with plain 'hg email',
or create new issue with just sending mail to special address.

Isn't this cool!?

Roundup has this now and it works. Also, although Roundup is not so shiny,
it was choosen as the tracker for Python itself:

http://bugs.python.org/

What do you think?

From stefan_ml at behnel.de  Sun May  4 17:36:19 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 04 May 2008 17:36:19 +0200
Subject: [Cython] [PATCH 0 of 2] A couple of handy patches when using
 cython in-tree
In-Reply-To: <200805041824.45735.kirr@mns.spb.ru>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481D7F63.5030402@behnel.de> <200805041824.45735.kirr@mns.spb.ru>
Message-ID: <481DD7F3.6040401@behnel.de>

Hi,

Kirill Smelkov wrote:
> Hi Stefan,
> 
> ? ????????? ?? ??????????? 04 ??? 2008 Stefan Behnel ???????(a):
>> Hi,
>>
>> Kirill Smelkov wrote:
>>> Here is a couple of handy patches for the case when cython is used "in-tree",
>>> i.e. when no installation is done.
>>>
>>> - First we need to 'chmod a+x' relevant files in bin/ ,
>>> - and second, it would be convenient to finally create reasonable .hgignore
>> Thanks, your patches are appreciated.
> 
> I look here
> 
> http://hg.cython.org/cython-devel/
> 
> and still can't see they were applied.

See? That's one of the advantages of a bundle. It allows you to send a
complete set of changes against the current trunk, so that things don't get lost.

Anything else missing?

Stefan


From gfurnish at gfurnish.net  Sun May  4 17:37:28 2008
From: gfurnish at gfurnish.net (Gary Furnish)
Date: Sun, 4 May 2008 09:37:28 -0600
Subject: [Cython] code review
In-Reply-To: <200805041916.49167.kirr@mns.spb.ru>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<481DB2FE.70309@behnel.de>
	<8f8f8530805040746q3da11076l44c0709531f3a2bb@mail.gmail.com>
	<200805041916.49167.kirr@mns.spb.ru>
Message-ID: <8f8f8530805040837k6cd312f4u47e64337b3dbea20@mail.gmail.com>

Trac doesn't have two way notification emails, only outgoing (as far
as I know).  Roundup looks neat (especially the two way email
integration), but I'm not happy about the lack of a good interface for
viewing patches compared to trac's (Example:
http://trac.sagemath.org/sage_trac/attachment/ticket/3025/9609.patch
), as roundup just displays the raw text.

On Sun, May 4, 2008 at 9:16 AM, Kirill Smelkov <kirr at mns.spb.ru> wrote:
> ? ????????? ?? ??????????? 04 ??? 2008 Gary Furnish ???????(a):
>
> > The canonical example of a project that uses trac is Sage:
>  > http://trac.sagemath.org/sage_trac
>  > It has good email integration (notify on ticket modification, etc,
>  > although it is supposed to be even better in the next version).
>
>  I'd like to clarify what I mean saying "good email integration":
>
>   Good email integration is two-way
>
>  That is:
>
>  -> it is possible to affect state of the issues, add comments to patch review,
>    etc... by sending mail.
>  <- you get notification mails, when someone changes something through web
>    interface, or another way.
>
>
>  Personally, I think having the first entry is important - a lot of tasks could
>  be done via plain emails, and at least some people are more productive with
>  keyboard & text editor (compared to clicking with mouse) :)
>
>  Does Trac have two-way email integration?
>
>
>
>
>  > Normally we attach patches to a ticket and then just comment them in
>  > the ticket associated with the patch.  This associates the bug/feature
>  > ticket with the patch (as opposed to needing two systems if you went
>  > with something like codeview + launchpad).  Compared to trac,
>  > launchpad is slow for webpage response time.  It is also slow on
>  > ticket creation time (I can create a ticket for a given item in maybe
>  > 30 seconds on one page in trac, whereas launchpad has so much
>  > complexity it is significantly more time consuming, requires a
>  > multipage creation step, etc).
>
>  Gary, All, imagine you could create a patch issue with plain 'hg email',
>  or create new issue with just sending mail to special address.
>
>  Isn't this cool!?
>
>  Roundup has this now and it works. Also, although Roundup is not so shiny,
>  it was choosen as the tracker for Python itself:
>
>  http://bugs.python.org/
>
>  What do you think?
>
>
> _______________________________________________
>  Cython-dev mailing list
>  Cython-dev at codespeak.net
>  http://codespeak.net/mailman/listinfo/cython-dev
>

From stefan_ml at behnel.de  Sun May  4 17:41:38 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 04 May 2008 17:41:38 +0200
Subject: [Cython] code review
In-Reply-To: <8f8f8530805040746q3da11076l44c0709531f3a2bb@mail.gmail.com>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>	
	<481D7F63.5030402@behnel.de> <200805041408.03746.kirr@mns.spb.ru>	
	<8f8f8530805040422i1a7fce66h94086394bb5cf41b@mail.gmail.com>	
	<481D9F31.7040800@behnel.de>	
	<8f8f8530805040451t3dfbea2cx670948fd8a8725b2@mail.gmail.com>	
	<481DAB9D.1070003@behnel.de>	
	<8f8f8530805040538o5ae2be44w333b7974e6894b44@mail.gmail.com>	
	<481DB2FE.70309@behnel.de>
	<8f8f8530805040746q3da11076l44c0709531f3a2bb@mail.gmail.com>
Message-ID: <481DD932.4010407@behnel.de>

Hi,

Gary Furnish consistently continues to top-post:
> The canonical example of a project that uses trac is Sage:
> http://trac.sagemath.org/sage_trac

obviously :)


> Normally we attach patches to a ticket and then just comment them in
> the ticket associated with the patch.  This associates the bug/feature
> ticket with the patch (as opposed to needing two systems if you went
> with something like codeview + launchpad).

Launchpad can do these things, but it lacks hg integration.


> Compared to trac,
> launchpad is slow for webpage response time.

I rarely had a problem with that. Maybe we're just using it from different
time zones.


> It is also slow on
> ticket creation time (I can create a ticket for a given item in maybe
> 30 seconds on one page in trac, whereas launchpad has so much
> complexity it is significantly more time consuming, requires a
> multipage creation step, etc).

I can't second that either. In launchpad, you write a subject and on submit it
will tell you (a goodie I really like) if it found any possible matches
amongst the existing tickets. You can then look at them or decide to write a
new ticket. I found that totally straight forward (even the first time I used
it) and very helpful for unexperienced users.

Stefan


From stefan_ml at behnel.de  Sun May  4 17:43:20 2008
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 04 May 2008 17:43:20 +0200
Subject: [Cython] code review
In-Reply-To: <200805041916.49167.kirr@mns.spb.ru>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>	<481DB2FE.70309@behnel.de>	<8f8f8530805040746q3da11076l44c0709531f3a2bb@mail.gmail.com>
	<200805041916.49167.kirr@mns.spb.ru>
Message-ID: <481DD998.8000204@behnel.de>

Hi,

Kirill Smelkov wrote:
> I'd like to clarify what I mean saying "good email integration":
> 
>   Good email integration is two-way
> 
> That is:
> 
> -> it is possible to affect state of the issues, add comments to patch review,
>    etc... by sending mail.
> <- you get notification mails, when someone changes something through web
>    interface, or another way.

Launchpad also has that. You can just reply to the bug notification email and
it will show up in the ticket comments.

Stefan


From mabshoff at googlemail.com  Sun May  4 17:06:10 2008
From: mabshoff at googlemail.com (Michael Abshoff)
Date: Sun, 04 May 2008 17:06:10 +0200
Subject: [Cython] code review
In-Reply-To: <200805041916.49167.kirr@mns.spb.ru>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>	<481DB2FE.70309@behnel.de>	<8f8f8530805040746q3da11076l44c0709531f3a2bb@mail.gmail.com>
	<200805041916.49167.kirr@mns.spb.ru>
Message-ID: <481DD0E2.9090207@googlemail.com>

Kirill Smelkov wrote:
> ? ????????? ?? ??????????? 04 ??? 2008 Gary Furnish ???????(a):
>   
>> The canonical example of a project that uses trac is Sage:
>> http://trac.sagemath.org/sage_trac
>> It has good email integration (notify on ticket modification, etc,
>> although it is supposed to be even better in the next version).
>>     
>
> I'd like to clarify what I mean saying "good email integration":
>
>   Good email integration is two-way
>
> That is:
>
> -> it is possible to affect state of the issues, add comments to patch review,
>    etc... by sending mail.
>   

Nope.

> <- you get notification mails, when someone changes something through web
>    interface, or another way.
>
>   
Yes.

> Personally, I think having the first entry is important - a lot of tasks could
> be done via plain emails, and at least some people are more productive with
> keyboard & text editor (compared to clicking with mouse) :)
>
>   
Well, some people like the Debian bugtracker which does let you submit 
item email, some people don't. Trac does not offer that in the default 
config and I don't think it is a good idea to do that. Trac offers some 
subset of wiki tags which make it preferable to use only the 
webinterface. The Debian bug tracker reads like an email list, so if you 
want that there is no advantage to switching to Trac.

> Does Trac have two-way email integration?
>   
Nope. It might be something available at trac-hacks, but last time I 
checked I didn't see anything.

>> Normally we attach patches to a ticket and then just comment them in
>> the ticket associated with the patch.  This associates the bug/feature
>> ticket with the patch (as opposed to needing two systems if you went
>> with something like codeview + launchpad).  Compared to trac,
>> launchpad is slow for webpage response time.  It is also slow on
>> ticket creation time (I can create a ticket for a given item in maybe
>> 30 seconds on one page in trac, whereas launchpad has so much
>> complexity it is significantly more time consuming, requires a
>> multipage creation step, etc).
>>     
>
> Gary, All, imagine you could create a patch issue with plain 'hg email',
> or create new issue with just sending mail to special address.
>
> Isn't this cool!?
>   

No. I don't really see the benefit there by just firing off an email. 
Our work flows are probably very different and I am no mouse pusher, but 
I prefer Trac and its workflow. I was skeptical initially, but since I 
spend a lot of time daily with Trac putting releases together for Sage I 
am quite sold on its work flow. I generally dislie the "submit bug 
report by email" work flow. We have sage-devel for the discussion bit 
and if we really have an issue we open a ticket.

We run 0.10.x, which is the current stable release. It has a couple 
issues, but those are mostly getting sorted out in 0.11. The main point 
of running your own trac install is that you own your data and do not 
depend on some other org to do things for you. Robert Bradshaw wrote an 
hg inspection module to let you check out patches and bundles online. 
There is also svn integration per default and some optional code to 
watch commits in an hg repo.

> Roundup has this now and it works. Also, although Roundup is not so shiny,
> it was choosen as the tracker for Python itself:
>
>   
Sure, but you need Django and a couple other things. Trac is self 
contained and has next to no dependencies, i.e. the default db is 
sqlite. It scales well for Sage, so I would assume it will work well for 
Cython which deals with a lot fewer patches on average compared to Sage.

> http://bugs.python.org/
>
> What do you think?
>   
:)

Cheers,

Michael

> _______________________________________________
> Cython-dev mailing list
> Cython-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev
>   


From kirr at mns.spb.ru  Sun May  4 18:10:43 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 4 May 2008 20:10:43 +0400
Subject: [Cython] [PATCH 0 of 2] A couple of handy patches when using
	cython in-tree
In-Reply-To: <481DD7F3.6040401@behnel.de>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<200805041824.45735.kirr@mns.spb.ru> <481DD7F3.6040401@behnel.de>
Message-ID: <200805042010.43445.kirr@mns.spb.ru>

? ????????? ?? ??????????? 04 ??? 2008 Stefan Behnel ???????(a):
> Hi,
> 
> Kirill Smelkov wrote:
> > Hi Stefan,
> > 
> > ? ????????? ?? ??????????? 04 ??? 2008 Stefan Behnel ???????(a):
> >> Hi,
> >>
> >> Kirill Smelkov wrote:
> >>> Here is a couple of handy patches for the case when cython is used "in-tree",
> >>> i.e. when no installation is done.
> >>>
> >>> - First we need to 'chmod a+x' relevant files in bin/ ,
> >>> - and second, it would be convenient to finally create reasonable .hgignore
> >> Thanks, your patches are appreciated.
> > 
> > I look here
> > 
> > http://hg.cython.org/cython-devel/
> > 
> > and still can't see they were applied.
> 
> See? That's one of the advantages of a bundle. It allows you to send a
> complete set of changes against the current trunk, so that things don't get lost.

No :)

I see that bundle v.s. text patches is another things.

You import bundle, and you apply patches.

Actually, applying patches is more convenient to me, since some of the patches could
be good, and some don't. that's why i'd like to apply only some, and with bundle you
have applied them all.

Just look at how things are done in Linux, Mercurial, etc -- they send plain text
patches.

> Anything else missing?

Everything is in, thanks!

I (minorly) wonder why you changed patch description in 'chmod a+x bin/*' patch

Kirill.

From kirr at mns.spb.ru  Sun May  4 19:08:24 2008
From: kirr at mns.spb.ru (Kirill Smelkov)
Date: Sun, 4 May 2008 21:08:24 +0400
Subject: [Cython] code review
In-Reply-To: <481DD0E2.9090207@googlemail.com>
References: <patchbomb.1209889254@tugrik2.mns.mnsspb.ru>
	<200805041916.49167.kirr@mns.spb.ru>
	<481DD0E2.9090207@googlemail.com>
Message-ID: <200805042108.24619.kirr@mns.spb.ru>

Hi, All

? ????????? ?? ??????????? 04 ??? 2008 Gary Furnish ???????(a):
> Trac doesn't have two way notification emails, only outgoing (as far
> as I know).  Roundup looks neat (especially the two way email
> integration), but I'm not happy about the lack of a good interface for
> viewing patches compared to trac's (Example:
> http://trac.sagemath.org/sage_trac/attachment/ticket/3025/9609.patch
> ), as roundup just displays the raw text.

Gary, I see your points.
Having patch viewer is indeed useful, like having two-way emails are useful too.

? ????????? ?? ??????????? 04 ??? 2008 Stefan Behnel ???????(a):
> Kirill Smelkov wrote:
> > I'd like to clarify what I mean saying "good email integration":
> > 
> >   Good email integration is two-way
> > 
> > That is:
> > 
> > -> it is possible to affect state of the issues, add comments to patch review,
> >    etc... by sending mail.
> > <- you get notification mails, when someone changes something through web
> >    interface, or another way.
> 
> Launchpad also has that. You can just reply to the bug notification email and
> it will show up in the ticket comments.

Then this is a plus for Launchpad.

From the other way is it possible to export all stored data from launchpad into
some interoperable format, e.g. csv?


? ????????? ?? ??????????? 04 ??? 2008 Michael Abshoff ???????(a):
> Kirill Smelkov wrote:
> > ? ????????? ?? ??????????? 04 ??? 2008 Gary Furnish ???????(a):
> >   
> >> The canonical example of a project that uses trac is Sage:
> >> http://trac.sagemath.org/sage_trac
> >> It has good email integration (notify on ticket modification, etc,
> >> although it is supposed to be even better in the next version).
> >>     
> >
> > I'd like to clarify what I mean saying "good email integration":
> >
> >   Good email integration is two-way
> >
> > That is:
> >
> > -> it is possible to affect state of the issues, add comments to patch review,
> >    etc... by sending mail.
> >   
> 
> Nope.

What do you mean here? You don't agree with my understanding of email integration?
Could you please clarify?


> > <- you get notification mails, when someone changes something through web
> >    interface, or another way.
> >
> >   
> Yes.
> 
> > Personally, I think having the first entry is important - a lot of tasks could
> > be done via plain emails, and at least some people are more productive with
> > keyboard & text editor (compared to clicking with mouse) :)
> >
> >   
> Well, some people like the Debian bugtracker which does let you submit 
> item email, some people don't. Trac does not offer that in the default 
> config and I don't think it is a good idea to do that. Trac offers some 
> subset of wiki tags which make it preferable to use only the 
> webinterface. The Debian bug tracker reads like an email list, so if you 
> want that there is no advantage to switching to Trac.

I don't want to be forced to only use either one of web or email. I *do*
want to use web interface often, but sometimes it is more convenient to reply
via email.

And when it comes to patch review, I think it is imho handy to use
full-featured editor, when commenting on a patch.

Maybe at least for me...

> > Does Trac have two-way email integration?
> >   
> Nope. It might be something available at trac-hacks, but last time I 
> checked I didn't see anything.
> 
> >> Normally we attach patches to a ticket and then just comment them in
> >> the ticket associated with the patch.  This associates the bug/feature
> >> ticket with the patch (as opposed to needing two systems if you went
> >> with something like codeview + launchpad).  Compared to trac,
> >> launchpad is slow for webpage response time.  It is also slow on
> >> ticket creation time (I can create a ticket for a given item in maybe
> >> 30 seconds on one page in trac, whereas launchpad has so much
> >> complexity it is significantly more time consuming, requires a
> >> multipage creation step, etc).
> >>     
> >
> > Gary, All, imagine you could create a patch issue with plain 'hg email',
> > or create new issue with just sending mail to special address.
> >
> > Isn't this cool!?
> >   
> 
> No. I don't really see the benefit there by just firing off an email. 
> Our work flows are probably very different and I am no mouse pusher, but 
> I prefer Trac and its workflow. I was skeptical initially, but since I 
> spend a lot of time daily with Trac putting releases together for Sage I 
> am quite sold on its work flow. I generally dislie the "submit bug 
> report by email" work flow. We have sage-devel for the discussion bit 
> and if we really have an issue we open a ticket.

Ok, I agree emails on usual issues maybe not so handy, and creating issue
via email may have its own drawbacks.

But my initial context was about patch reviews, and then I think
it is handy to do it in fully-featured text editor.

e.g. OP sends a mid-size patch, and reviewer comments, e.g.:

http://groups.google.com/group/sympy-patches/msg/5a23e70f64b1b776
http://groups.google.com/group/sympy-patches/msg/aa5a9ce17b9165bc
http://groups.google.com/group/sympy-patches/msg/0b5107e7885f6dcb

So maybe mailing bug reports is not a good idea, but submitting patches via
'hg email' seems (at least to me) to be good, because sending them is one
button, and importing them is one button, and reviewing them is one button
+ text edits + "y" in the end.

I agree this is not ideal, and could be improved, e.g. thus made text edits
could go into patch issue, and when viewing the diff there would be added
comments from various people.

But you know, nothing is ideal, and the scheme I'm talking about works ok in
a lot of places.

> We run 0.10.x, which is the current stable release. It has a couple 
> issues, but those are mostly getting sorted out in 0.11. The main point 
> of running your own trac install is that you own your data and do not 
> depend on some other org to do things for you.

+1 about managing your own data by yourself.

> Robert Bradshaw wrote an  
> hg inspection module to let you check out patches and bundles online. 

Do you mean importing patches from trac with 'hg somecommand'?

This would be handy.

And also, if there were another 'hg somecommand2' moddeled after 'hg email'
to send patches to trac, it would be handy^2.

Btw, how do I check myself how it works?

> There is also svn integration per default and some optional code to 
> watch commits in an hg repo.


> > Roundup has this now and it works. Also, although Roundup is not so shiny,
> > it was choosen as the tracker for Python itself:
> >
> >   
> Sure, but you need Django and a couple other things. Trac is self 

No, Django is not needed to run roundup.

> contained and has next to no dependencies, i.e. the default db is 
> sqlite. It scales well for Sage, so I would assume it will work well for 
> Cython which deals with a lot fewer patches on average compared to Sage.

Actually there are very little dependencies for roundup - it can even use
plain files as DB (not to depend on anything), or optionally sqlite and
other dbs.

I'd say roundup depends only on Python and optionally on sqlite, pytz.
And also you need to setup exim so that incoming emails work.

> 
> > http://bugs.python.org/
> >
> > What do you think?
> >   
> :)

:)

Guys, please don't get me wrong.

I'm not saying "let's use roundup, period." For amount of patches I observe I
think plain cython-patches would do, and then, if needed, we could use any
tool which would do the job.

Only myself I observed that doing things in text editor is handy, thus I
value tools that provide this ability.

I really hope Guido's codereview would be good though and helpful and well
designed.

Let's settle on something practical,
Kirill.

From pete at petertodd.org  Mon May  5 05:37:49 2008
From: pete at petertodd.org (Peter Todd)
Date: Sun, 4 May 2008 23:37:49 -0400
Subject: [Cython] __getattribute__
In-Reply-To: <20080504051532.GA7720@tilt>
References: <20080430004208.GJ15181@tilt>
	<5EB02A25-EE20-4FAB-A780-19DEC5EFA16A@math.washington.edu>
	<20080504051532.GA7720@tilt>
Message-ID: <20080505033749.GF4087@tilt>

On Sun, May 04, 2008 at 01:15:32AM -0400, Peter Todd wrote:
> Here's my first patch. This correctly implements __getattribute__ and
> __getattr__ in the single class case. FWIW I also have a mercurial tree
> if it'd be better to pull from it than apply patches.
> 
> I'm working on making subclasses behave correctly, I've got test cases
> written up showing where things fail, but no solutions to that written
> yet. The slot_tp_getattro stuff Stefan mentioned is useful though.

__getattr(ibute)__ support is now working with subclasses. The semantics
should match Python exactly if my test cases are correct. All that has
changed from the previous patch is that at compile time base classes are
checked for __getattr(ibute)__ methods and those methods are used if
found.

Attached is an hg bundle of the two commits.

-- 
http://petertodd.o