[Cython] Problem with final cdef methods
Hi, I noticed two problems with final cdef methods. When overriding a normal cdef method with a final cdef method, you currently get a C compiler warning about a call with the wrong 'self' type, and when you call them before you declare them in your code, you get an error because the method is not forward declared. http://trac.cython.org/cython_trac/ticket/819 I think this suggests that we should try to come up with a cleaner way to integrate this feature into the function overloading architecture rather than just remembering their cname and call that. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Problem with final cdef methods
2013/8/29 Stefan Behnel : > Hi, > > I noticed two problems with final cdef methods. When overriding a normal > cdef method with a final cdef method, you currently get a C compiler > warning about a call with the wrong 'self' type, and when you call them > before you declare them in your code, you get an error because the method > is not forward declared. > > http://trac.cython.org/cython_trac/ticket/819 > > I think this suggests that we should try to come up with a cleaner way to > integrate this feature into the function overloading architecture rather > than just remembering their cname and call that. > Hi Stefan, +1, current final implementation isn't clear enough and seems to be a hack to me -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: wiki spam
On Wed, Aug 28, 2013 at 11:53 AM, William Stein wrote: > On Wed, Aug 28, 2013 at 10:12 AM, Lars Buitinck wrote: >> 2013/8/28 : >>> On Wednesday, August 28, 2013 10:29:35 AM UTC-4, Josh Ayers wrote: I just noticed one of the pages on the Cython wiki was changed to spam. See the page history below. I reverted it, but it will probably happen again. It may be time to upgrade the captcha used for registering new accounts. >> >> Man, there's a lot of spam on that wiki (see >> http://wiki.cython.org/RecentChanges). Did you consider moving to a >> GitHub wiki instead? > > As the owner of the hardware on which the cython wiki is running, I > think this is well worth considering. If somebody wants to do it, > I'm happy to tar up the actual wiki install for them, so they can > somehow try to auto-convert all the pages... +1 Spam has increased a lot lately. What I really would like is a publicly editable wiki whose changes have to go through an approval first (e.g. a pull request). Unfortunately, despite expectations, github wikis don't work like this. I do really like the idea of the wiki being backed by a repo rather than some opaque format though. Anyone know of anything like that? We could also look at locking down the wiki to trac account owners only. This should probably be done right now. (I'm not sure how to do it though.) Also, I think much of the wiki content should be moved into the docs instead. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Problem with final cdef methods
On Thu, 29 Aug 2013 11:03:01 +0600, Stefan Behnel
wrote:
I noticed two problems with final cdef methods. When overriding a normal
cdef method with a final cdef method, you currently get a C compiler
warning about a call with the wrong 'self' type, and when you call them
before you declare them in your code, you get an error because the method
is not forward declared.
http://trac.cython.org/cython_trac/ticket/819
I think this suggests that we should try to come up with a cleaner way to
integrate this feature into the function overloading architecture rather
than just remembering their cname and call that.
As your ticket mentions, there is a fundamental problem with method
inheritance.
(and with the way Cython generates forward declarations...)
Any inherited method assumes 2 types simultaneously: the type of the base
method with 1st parameter being a base class pointer and the "actual" type
of the method with 1st parameter being derived class pointer.
1st type, stored in method's Entry.type, is essentially the vtable slot
type. It's used when virtual method calls a made. It's also used for
generating
forward declarations and for casting in vtable init code.
2nd type (stored in CFuncDef node) is used ONLY to generate function
definition.
The mismatch between these 2 types is the root of the problem.
Before final methods were introduced, the 2nd ("actual") type was
unimportant.
Method was cast to the vtable slot type in vtable init code and forgotten.
But final functions, bypassing vtable mechanic, rely soley on the 2nd type.
I have solved it for myself by storing BOTH types in the method entry
(Entry.type for the actual CFuncDef type and Entry.prev_type for the vtable
slot type). By using correct types in
generate_exttype_final_methods_declaration()
and generate_exttype_vtable_init_code() the problem is avoided.
You can see the patch here
https://github.com/nnemkin/cython/compare/final_subtypes
Notes for the patch:
* I removed a bit of wtf code from CFuncType.declaration_code,
these changes are incidental to the problem you describe.
(Strictly necessary parts are only the lines involving "prev_type").
* There is a disabled bug test named "inherited_final_method", you
may want to remove/merge it with the test you modified.
I hope this helps.
Best regards,
Nikita Nemkin
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Problem with final cdef methods
Nikita Nemkin, 29.08.2013 08:24:
> On Thu, 29 Aug 2013 11:03:01 +0600, Stefan Behnel wrote:
>> http://trac.cython.org/cython_trac/ticket/819
>
> As your ticket mentions, there is a fundamental problem with method
> inheritance.
> (and with the way Cython generates forward declarations...)
>
> Any inherited method assumes 2 types simultaneously: the type of the base
> method with 1st parameter being a base class pointer and the "actual" type
> of the method with 1st parameter being derived class pointer.
> 1st type, stored in method's Entry.type, is essentially the vtable slot
> type. It's used when virtual method calls a made. It's also used for
> generating
> forward declarations and for casting in vtable init code.
> 2nd type (stored in CFuncDef node) is used ONLY to generate function
> definition.
>
> The mismatch between these 2 types is the root of the problem.
> Before final methods were introduced, the 2nd ("actual") type was unimportant.
> Method was cast to the vtable slot type in vtable init code and forgotten.
> But final functions, bypassing vtable mechanic, rely soley on the 2nd type.
Thanks for writing up the analysis.
> I have solved it for myself by storing BOTH types in the method entry
> (Entry.type for the actual CFuncDef type and Entry.prev_type for the vtable
> slot type). By using correct types in
> generate_exttype_final_methods_declaration()
> and generate_exttype_vtable_init_code() the problem is avoided.
> You can see the patch here
> https://github.com/nnemkin/cython/compare/final_subtypes
Interesting. Your change dates back a while already. Were you planning to
clean it up in some way before you submit it as pull request?
> Notes for the patch:
> * I removed a bit of wtf code from CFuncType.declaration_code,
I'm not surprised. :)
> * There is a disabled bug test named "inherited_final_method",
And you had to disable it, because ... ?
> you may want to remove/merge it with the test you modified.
I already looked at it before I changed the main test. It appears to be a
regression test for a specific bug that's different from the problem at
hand, that's why I didn't touch it.
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
