Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
On Thu, Feb 17, 2011 at 03:53:13PM -0800, Robert Bradshaw wrote:
On Thu, Feb 17, 2011 at 3:12 PM, W. Trevor King <wking@drexel.edu> wrote:
* Extending class cdef/cdpef/public/readonly handling to cover enums, stucts, and possibly unions.
This seems like the best first step.
Problems with me getting started now:
* I don't know where I should start mucking about in the source.
...The other files to look at would be Parsing.py,..
I've got the the Parsing pretty much working, but portions of the test suite are now failing with things like === Expected errors: === 1:5: function definition in pxd file must be declared 'cdef inline' 4:5: inline function definition in pxd file cannot be 'public' 7:5: inline function definition in pxd file cannot be 'api' === Got errors: === 1:5: function definition in pxd file must be declared 'cdef inline' 4:12: inline function definition in pxd file cannot be 'public' 7:5: inline function definition in pxd file cannot be 'api' while cythoning tests/errors/e_func_in_pxd_support.pxd: cdef foo(): return 1 cdef public inline foo2(): return 1 cdef api inline foo3(): return 1 The current Cython implementation does not consider 'cdef' to be part of the node code, and my current implementation does not consider any qualifiers to be part of the node code. It's unclear to me what the "right" position is for the start of a function (or variable, class, ...) should be, or how errors should be formatted. My initial impression is that Node.pos should point to the beginning of the def (here 1:1, 4:1, and 7:1), but that positions of the various qualifiers (cdef, public, inline, api, ...) should be cached so that the error points to the offending qualifier. Thoughs? -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
On Sat, Feb 19, 2011 at 11:35 AM, W. Trevor King <wking@drexel.edu> wrote:
On Thu, Feb 17, 2011 at 03:53:13PM -0800, Robert Bradshaw wrote:
On Thu, Feb 17, 2011 at 3:12 PM, W. Trevor King <wking@drexel.edu> wrote:
* Extending class cdef/cdpef/public/readonly handling to cover enums, stucts, and possibly unions.
This seems like the best first step.
Problems with me getting started now:
* I don't know where I should start mucking about in the source.
...The other files to look at would be Parsing.py,..
I've got the the Parsing pretty much working, but portions of the test suite are now failing with things like
=== Expected errors: === 1:5: function definition in pxd file must be declared 'cdef inline' 4:5: inline function definition in pxd file cannot be 'public' 7:5: inline function definition in pxd file cannot be 'api'
=== Got errors: === 1:5: function definition in pxd file must be declared 'cdef inline' 4:12: inline function definition in pxd file cannot be 'public' 7:5: inline function definition in pxd file cannot be 'api'
while cythoning tests/errors/e_func_in_pxd_support.pxd:
cdef foo(): return 1
cdef public inline foo2(): return 1
cdef api inline foo3(): return 1
The current Cython implementation does not consider 'cdef' to be part of the node code, and my current implementation does not consider any qualifiers to be part of the node code.
It's unclear to me what the "right" position is for the start of a function (or variable, class, ...) should be, or how errors should be formatted. My initial impression is that Node.pos should point to the beginning of the def (here 1:1, 4:1, and 7:1), but that positions of the various qualifiers (cdef, public, inline, api, ...) should be cached so that the error points to the offending qualifier.
For better or for worse, Cython follows the same inane declarator rules as C, so cdef int a, *b, c[5], (*d)(int) is valid. This colors how c function declarations are expressed in the tree. Qualifiers don't really live in the tree and I'm not sure plumbing the "qualifier node" positions around would be worth the added complexity. - Robert
On Sat, Feb 19, 2011 at 12:52:38PM -0800, Robert Bradshaw wrote:
On Sat, Feb 19, 2011 at 11:35 AM, W. Trevor King <wking@drexel.edu> wrote:
On Thu, Feb 17, 2011 at 03:53:13PM -0800, Robert Bradshaw wrote:
On Thu, Feb 17, 2011 at 3:12 PM, W. Trevor King <wking@drexel.edu> wrote:
* Extending class cdef/cdpef/public/readonly handling to cover enums, stucts, and possibly unions.
This seems like the best first step.
Problems with me getting started now:
* I don't know where I should start mucking about in the source.
...The other files to look at would be Parsing.py,..
I've got the the Parsing pretty much working, but portions of the test suite are now failing with things like
=== Expected errors: === 1:5: function definition in pxd file must be declared 'cdef inline' 4:5: inline function definition in pxd file cannot be 'public' 7:5: inline function definition in pxd file cannot be 'api'
=== Got errors: === 1:5: function definition in pxd file must be declared 'cdef inline' 4:12: inline function definition in pxd file cannot be 'public' 7:5: inline function definition in pxd file cannot be 'api'
while cythoning tests/errors/e_func_in_pxd_support.pxd:
cdef foo(): return 1
cdef public inline foo2(): return 1
cdef api inline foo3(): return 1
The current Cython implementation does not consider 'cdef' to be part of the node code, and my current implementation does not consider any qualifiers to be part of the node code.
It's unclear to me what the "right" position is for the start of a function (or variable, class, ...) should be, or how errors should be formatted. My initial impression is that Node.pos should point to the beginning of the def (here 1:1, 4:1, and 7:1), but that positions of the various qualifiers (cdef, public, inline, api, ...) should be cached so that the error points to the offending qualifier.
For better or for worse, Cython follows the same inane declarator rules as C, so
cdef int a, *b, c[5], (*d)(int)
is valid. This colors how c function declarations are expressed in the tree. Qualifiers don't really live in the tree and I'm not sure plumbing the "qualifier node" positions around would be worth the added complexity.
So should I go ahead and update the expected error messages in my branch? -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
participants (2)
-
Robert Bradshaw -
W. Trevor King