ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> ctypes-users
ctypes-users
Re: [ctypes-users] Since I don't seem to be getting time to do the rest of the work any time soon
by Mike C. Fletcher other posts by this author
Nov 23 2006 12:50PM messages near this date
Re: [ctypes-users] Since I don't seem to be getting time to do the rest of the work any time soon | [ctypes-users] Function pointers as arguments or structure members
Thomas Heller wrote:
...
>  I have found these bugs so far (patches for patches don't read well, so
>  I present the code snippets):
> 
>  1. The TEMPLATE of "class Function(Emitter)" must be this, I had to add
>     [] around the %(argTypes)s in the last line, otherwise invalid code is
>     generated for functions taking no arguments:
> 
>      TEMPLATE = """%(location)s%(name)s = %(libname)s.%(name)s
>  %(name)s.restype = %(returnType)s
>  %(argNames)s%(name)s.argtypes = [%(argTypes)s]
>  """
>    
Ah, good point.  Obviously I never ran the un-sub-classed version :) .
>                                  ^            ^
> 
>  2. In Generator.__init__(), I had to add parens because '+' binds stronger
>     than 'or':
> 
>          self.emitters = (emitters or []) + self.defaultEmitters()
>    
Good catch.  I guess in every case where I was using emitters I must 
have restricted the types as well.  Strange.
>                          ^              ^
> 
>  3. In Generator.generate(), if no emitter is found 'item' must
>     be added to 'self.done' to avoid unlimited recursion:
>    
Oops, guess I never actually hit that case.
>          log.warn("""Unable to find emitter for %r instance""", type(item))
>          # Added this line:
>          self.done.add(item)
> 
>     Maybe it would be better to raise an error instead of a warning, because
>     the generated code will not work anyway in this case.
>    
Hmm, I suppose so, AFAIK it should never happen, should it?  But if it 
*should* happen, wouldn't that prevent the whole wrapping process from 
completing when only 1 item might be unusable?  Skipping the item with a 
warning seems safer to me.

Have fun,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ctypes-users mailing list
ctypes-users@[...].net
https://lists.sourceforge.net/lists/listinfo/ctypes-users
Thread:
Mike C. Fletcher
Thomas Heller
Mike C. Fletcher
Thomas Heller
Thomas Heller
Mike C. Fletcher

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved