-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: about Windows handles (Thomas Heller)

Thomas Heller <theller <at> ctypes.org>
2008-11-01 17:21:55 GMT

Stegmann Patricio schrieb:
> Thomas,
> thanks for you answer. I was looking on google for IIRC but cant find what it is. Is it a python module ? Where
can I get it ?
> Thanks again.
>
>>
>> IIRC (I don't use wx myself nowadays) wx windows have a GetHandle() method
>> or something like that.
It means: If I remember correctly (== IIRC) wx windows have a GetHandler() method
that will return the window handle.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

portability of ctypeslib-generated wrappers that use FILE*s?

Gordon Kindlmann <gk <at> bwh.harvard.edu>
2008-11-04 04:25:40 GMT

Hello-
In my continued effort to understand portability possibilities in
python/ctypes wrappers for libraries, I've noticed that one of the
main differences between the output of xml2py in ctypeslib is in the
definition of the FILE struct. Or rather, "FILE" in ctypeslib output
is always defined according to the system specific implementation of
the C "FILE" struct, which has different names, contents, and
layouts, depending on the architecture, and the ctypeslib output
shows me those differences in gory detail.
1) I was surprised that the system-specific of FILE was showing up at
all in my output; it wasn't something I was filtering for with the "-
r" flag to xml2py. Is it necessary for this to be output, especially
since none of my (very portable) code ever looks inside the FILE
struct? For example, on darwin, I see:
class __sFILE(Structure):
pass
FILE = __sFILE
...
__sFILE._fields_ = [
('_p', POINTER(c_ubyte)),
('_r', c_int),
('_w', c_int),
('_flags', c_short),
('_file', c_short),
...
]
Why is the implementation of FILE being exposed here?
2) Is there a suggested way to transform ctypeslib output so that
these FILE implementation details are removed? Taking the example
above, couldn't I just as well have:
class FILE(Structure):
pass
right?
3) How do I pass stdin and stderr to C functions that can use them to
write to? I know about sys.stdin and sys.stderr, but these didn't work:
In [16]: teem.nrrdDescribe(sys.stderr, n)
------------------------------------------------------------------------
---
ArgumentError Traceback (most recent
call last)
/Users/gk/teem-wrap/<ipython console> in <module>()
ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected
LP___sFILE instance instead of file
Any suggestions for this particular problem, or the bigger issues above?
Thanks,
Gordon
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: portability of ctypeslib-generated wrappers that use FILE*s?

Thomas Heller <theller <at> ctypes.org>
2008-11-04 16:57:06 GMT

Gordon Kindlmann schrieb:
> Hello-
>
> In my continued effort to understand portability possibilities in
> python/ctypes wrappers for libraries, I've noticed that one of the
> main differences between the output of xml2py in ctypeslib is in the
> definition of the FILE struct. Or rather, "FILE" in ctypeslib output
> is always defined according to the system specific implementation of
> the C "FILE" struct, which has different names, contents, and
> layouts, depending on the architecture, and the ctypeslib output
> shows me those differences in gory detail.
>
> 1) I was surprised that the system-specific of FILE was showing up at
> all in my output; it wasn't something I was filtering for with the "-
> r" flag to xml2py. Is it necessary for this to be output, especially
> since none of my (very portable) code ever looks inside the FILE
> struct? For example, on darwin, I see:
>
> class __sFILE(Structure):
> pass
> FILE = __sFILE
> ...
> __sFILE._fields_ = [
> ('_p', POINTER(c_ubyte)),
> ('_r', c_int),
> ('_w', c_int),
> ('_flags', c_short),
> ('_file', c_short),
> ...
> ]
>
> Why is the implementation of FILE being exposed here?
The code generator does no special filtering at all. The FILE structure
is completely described in the C header files so that the C macros
getc(), putc, and so on work for buffered output.
> 2) Is there a suggested way to transform ctypeslib output so that
> these FILE implementation details are removed? Taking the example
> above, couldn't I just as well have:
>
> class FILE(Structure):
> pass
>
> right?
The idea is to use the -m flag of the xml2py script:
-m module Python module(s) containing symbols which will be imported
instead of generated
You can define some ctypes types in a module, lets call it 'stdio.py':
# stdio.py
from ctypes import *
class FILE(Structure):
pass
# eof
Then you run the toolchain, the following example parses 'stdio.h' into xml, and then
generates wrapper code for the 'fprintf' function:
theller <at> tubu32:~/devel/ctypeslib-gccxml-0.9$ python ctypeslib/h2xml.py stdio.h -o test.xml
creating xml output file ...
running: gccxml /tmp/tmpmtCMad.cpp -fxml=test.xml
theller <at> tubu32:~/devel/ctypeslib-gccxml-0.9$ python ctypeslib/xml2py.py myxml.xml -m stdio -lc -s fprintf
from ctypes import *
from stdio import FILE
STRING = c_char_p
_libraries = {}
_libraries['libc.so.6'] = CDLL('libc.so.6')
fprintf = _libraries['libc.so.6'].fprintf
fprintf.restype = c_int
fprintf.argtypes = [POINTER(FILE), STRING]
__all__ = ['fprintf']
theller <at> tubu32:~/devel/ctypeslib-gccxml-0.9$
> 3) How do I pass stdin and stderr to C functions that can use them to
> write to? I know about sys.stdin and sys.stderr, but these didn't work:
>
> In [16]: teem.nrrdDescribe(sys.stderr, n)
>
> ------------------------------------------------------------------------
> ---
> ArgumentError Traceback (most recent
> call last)
>
> /Users/gk/teem-wrap/<ipython console> in <module>()
>
> ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected
> LP___sFILE instance instead of file
>
> Any suggestions for this particular problem, or the bigger issues above?
You can't pass sys.stdin or sys.stderr to C functions, because they are Python
objects and not FILE pointers.
However, on linux at least, the C library exports the stdin, stdout, and stderr
FILE* pointers. You can get them by calling POINTER(FILE).in_dll(...):
>>> from ctypes import *
>>> from ctypes import *
>>> from ctypes.util import find_library
>>> dll = CDLL(find_library("c"))
>>>
>>> from stdio import FILE
>>> POINTER(FILE)
<class 'ctypes.LP_FILE'>
>>> POINTER(FILE).in_dll(dll, "stdin")
<ctypes.LP_FILE object at 0xb7dda224>
>>> POINTER(FILE).in_dll(dll, "stdout")
<ctypes.LP_FILE object at 0xb7ddae3c>
>>>
Thomas
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: platform-independence of ctypes declarations (no c_ptrdiff_t)?

Thomas Heller <theller <at> ctypes.org>
2008-11-05 08:27:38 GMT

>> On the other hand, looking through
>>
>> http://python.net/crew/theller/ctypes/reference.html
>>
>> it looks like there's no c_ptrdiff_t?
>
> This is true, there are no definitions in ctypes or ctypeslib for
> these platform dependend types. It would be a good idea to make a module
> for it, and it should be integrated with the ctypeslib code generator
> so that the generated code imports them from this module instead
> of generating its own (wrong) definitions.
Should we start a module 'ansitypes.py' somewhere, that contains definitions
for the library type defined in the ansi-c standard? These are the types that
I have collected from the headers described in the Library chapter:
stddef.h: ptrdiff_t, size_t, wchar_t
signal.h: sig_atomic_t
stdio.h: FILE, fpos_t, stderr, stdout, stdin
stdlib.h: div_t, ldiv_t
time.h: clock_t, time_t, struct tm
Thomas
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: portability of ctypeslib-generated wrappers that use FILE*s?

Thomas Heller <theller <at> ctypes.org>
2008-11-05 08:37:17 GMT

Gordon Kindlmann schrieb:
> hello,
>
> On Nov 4, 2008, at 11:57 AM, Thomas Heller wrote:
>
>> Gordon Kindlmann schrieb:
>>>
>>> ...
>>>
>>> 2) Is there a suggested way to transform ctypeslib output so that
>>> these FILE implementation details are removed? Taking the example
>>> above, couldn't I just as well have:
>>>
>>> class FILE(Structure):
>>> pass
>>>
>>> right?
>>
>> The idea is to use the -m flag of the xml2py script:
>>
>> -m module Python module(s) containing symbols which will be
>> imported
>> instead of generated
>>
>> You can define some ctypes types in a module, lets call it 'stdio.py':
>>
>> # stdio.py
>> from ctypes import *
>> class FILE(Structure):
>> pass
>> # eof
>>
>> Then you run the toolchain, the following example parses 'stdio.h'
>> into xml, and then
>> generates wrapper code for the 'fprintf' function:
>>
>> theller <at> tubu32:~/devel/ctypeslib-gccxml-0.9$ python ctypeslib/
>> h2xml.py stdio.h -o test.xml
>> creating xml output file ...
>> running: gccxml /tmp/tmpmtCMad.cpp -fxml=test.xml
>> theller <at> tubu32:~/devel/ctypeslib-gccxml-0.9$ python ctypeslib/
>> xml2py.py myxml.xml -m stdio -lc -s fprintf
>
> Brilliant, thank you! This is exactly what I was looking for.
>
>> However, on linux at least, the C library exports the stdin,
>> stdout, and stderr
>> FILE* pointers. You can get them by calling POINTER(FILE).in_dll
>> (...):
>>
>>>>> from ctypes import *
>>>>> from ctypes import *
>>>>> from ctypes.util import find_library
>>>>> dll = CDLL(find_library("c"))
>>>>>
>>>>> from stdio import FILE
>>>>> POINTER(FILE)
>> <class 'ctypes.LP_FILE'>
>>>>> POINTER(FILE).in_dll(dll, "stdin")
>> <ctypes.LP_FILE object at 0xb7dda224>
>>>>> POINTER(FILE).in_dll(dll, "stdout")
>> <ctypes.LP_FILE object at 0xb7ddae3c>
>
> Okay, I got this to work too, with different names (.e.g. "__stdinp")
> on Darwin. Do you have any suggestions on how to get at these in a
> more portable way? Or should I write little C functions that return
> those pointers, and then wrap that with ctypeslib?
Well, the description of 'stdin' IS inside the xmlfile, it is *only*
a matter of generating wrapper code for them, similar to how code for
functions is generated. Maybe I can look into it when I have time...
Thomas
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: platform-independence of ctypes declarations (no c_ptrdiff_t)?

Gordon Kindlmann <gk <at> bwh.harvard.edu>
2008-11-05 20:34:19 GMT

hello,
>> This is true, there are no definitions in ctypes or ctypeslib for
>> these platform dependend types. It would be a good idea to make a
>> module
>> for it, and it should be integrated with the ctypeslib code generator
>> so that the generated code imports them from this module instead
>> of generating its own (wrong) definitions.
>
> Should we start a module 'ansitypes.py' somewhere, that contains
> definitions
> for the library type defined in the ansi-c standard? These are the
> types that
> I have collected from the headers described in the Library chapter:
>
> stddef.h: ptrdiff_t, size_t, wchar_t
> signal.h: sig_atomic_t
> stdio.h: FILE, fpos_t, stderr, stdout, stdin
> stdlib.h: div_t, ldiv_t
> time.h: clock_t, time_t, struct tm
Yes, this would be fantastic, and it would address the other problem
I had before with ptrdiff_t. I modified the stdio.py that you
suggested before, so its now:
# stdio.py
from ctypes import *
class FILE(Structure):
pass
if sizeof(c_void_p) == 4:
ptrdiff_t = c_int32
elif sizeof(c_void_p) == 8:
ptrdiff_t = c_int64
# eof
and now my xml2py-generated ctypes wrapper for my library is
completely free of the platform-specific details of both FILE and
ptrdiff :)
I think the name "ansitypes" might be misleading, since the values of
stdin/stderr/stdout aren't really types. Maybe more like "libc"?
Gordon
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: platform-independence of ctypes declarations (no c_ptrdiff_t)?

Thomas Heller <theller <at> ctypes.org>
2008-11-05 20:43:58 GMT

>> Should we start a module 'ansitypes.py' somewhere, that contains
>> definitions
>> for the library type defined in the ansi-c standard? These are the
>> types that
>> I have collected from the headers described in the Library chapter:
>>
>> stddef.h: ptrdiff_t, size_t, wchar_t
>> signal.h: sig_atomic_t
>> stdio.h: FILE, fpos_t, stderr, stdout, stdin
>> stdlib.h: div_t, ldiv_t
>> time.h: clock_t, time_t, struct tm
>
> Yes, this would be fantastic, and it would address the other problem
> I had before with ptrdiff_t. I modified the stdio.py that you
> suggested before, so its now:
>
> # stdio.py
> from ctypes import *
>
> class FILE(Structure):
> pass
>
> if sizeof(c_void_p) == 4:
> ptrdiff_t = c_int32
> elif sizeof(c_void_p) == 8:
> ptrdiff_t = c_int64
> # eof
>
> and now my xml2py-generated ctypes wrapper for my library is
> completely free of the platform-specific details of both FILE and
> ptrdiff :)
>
> I think the name "ansitypes" might be misleading, since the values of
> stdin/stderr/stdout aren't really types. Maybe more like "libc"?
Well, the idea was to suggest that the C90 (ansi C) types are in this module,
but not the C99 types.
For stdin, stdout, stderr, the situation is more complicated anyway.
I have no idea how they could be implemented in a crossplatform way
without examining the system header files. While probably the FILE
type as defined above can be used, the actual stdin/stdout/sterr pointers
must either be provided by a C extension (maybe ctypes itself), or be
generated by extending ctypeslib codegenerator to handle variables defined
in shared libraries, quite similar to functions.
Thomas
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/