Re: about Windows handles (Thomas Heller)

-------------------------------------------------------------------------
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=/

_______________________________________________
ctypes-users mailing list
ctypes-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ctypes-users

Re: about Windows handles (Thomas Heller)

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?

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?

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: portability of ctypeslib-generated wrappers that use FILE*s?

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?

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: platform-independence of ctypes declarations (no c_ptrdiff_t)?

>> 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?

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)?

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)?

>> 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=/

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

> 
> 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.
> 

Here is a very preliminary patch for the code generator (gccxml-0.9 branch)
which kind-of works on ubuntu (forget the first chunk, this is just some unrelated
patch that I have in my sandbox):

Index: ctypeslib/codegen/codegenerator.py
===================================================================
--- ctypeslib/codegen/codegenerator.py  (Revision 66981)
+++ ctypeslib/codegen/codegenerator.py  (Arbeitskopie)
 <at>  <at>  -262,6 +262,9  <at>  <at> 
     def c_ulonglong(self, tp, init, is_pointer=False):
         return self._init_integer(ctypes.c_ulonglong, "ul", init)

+    def c_longdouble(self, tp, init, is_pointer=False):
+        return self._init_float(ctypes.c_double, "l", init)
+
     def c_double(self, tp, init, is_pointer=False):
         return self._init_float(ctypes.c_double, "", init)

 <at>  <at>  -451,6 +454,15  <at>  <at> 
         self._variables += 1
         if tp.init is None:
             # wtypes.h contains IID_IProcessInitControl, for example
+            dllname = self.find_dllname(tp)
+            if dllname:
+                libname = self.get_sharedlib(dllname, "cdecl")
+                self.generate(tp.typ)
+                print >> self.stream, "%s = %s.in_dll(%s, %r)" % (tp.name,
+                                                                  self.type_name(tp.typ, True),
+                                                                  libname,
+                                                                  tp.name)
+                self.names.add(tp.name)
             return
         try:
             value = self.initialize(tp.typ, tp.init)

and here is what it generates after first running 'h2xml stdio.h -c -o stdio.xml':

theller <at> tubu32:~/devel/ctypeslib-gccxml-0.9$ python ctypeslib/xml2py.py stdio.xml -lc -s fprintf -sstdout
from ctypes import *

_libraries = {}
_libraries['libc.so.6'] = CDLL('libc.so.6')
STRING = c_char_p

class _IO_FILE(Structure):
    pass
stdout = POINTER(_IO_FILE).in_dll(_libraries['libc.so.6'], 'stdout')
FILE = _IO_FILE
fprintf = _libraries['libc.so.6'].fprintf
fprintf.restype = c_int
fprintf.argtypes = [POINTER(FILE), STRING]
class _IO_marker(Structure):
    pass
__off_t = c_long
_IO_lock_t = None
__quad_t = c_longlong
__off64_t = __quad_t
size_t = c_uint
_IO_FILE._pack_ = 4
_IO_FILE._fields_ = [
    ('_flags', c_int),
    ('_IO_read_ptr', STRING),
    ('_IO_read_end', STRING),
    ('_IO_read_base', STRING),
    ('_IO_write_base', STRING),
    ('_IO_write_ptr', STRING),
    ('_IO_write_end', STRING),
    ('_IO_buf_base', STRING),
    ('_IO_buf_end', STRING),
    ('_IO_save_base', STRING),
    ('_IO_backup_base', STRING),
    ('_IO_save_end', STRING),
    ('_markers', POINTER(_IO_marker)),
    ('_chain', POINTER(_IO_FILE)),
    ('_fileno', c_int),
    ('_flags2', c_int),
    ('_old_offset', __off_t),
    ('_cur_column', c_ushort),
    ('_vtable_offset', c_byte),
    ('_shortbuf', c_char * 1),
    ('_lock', POINTER(_IO_lock_t)),
    ('_offset', __off64_t),
    ('__pad1', c_void_p),
    ('__pad2', c_void_p),
    ('__pad3', c_void_p),
    ('__pad4', c_void_p),
    ('__pad5', size_t),
    ('_mode', c_int),
    ('_unused2', c_char * 40),
]
_IO_marker._fields_ = [
    ('_next', POINTER(_IO_marker)),
    ('_sbuf', POINTER(_IO_FILE)),
    ('_pos', c_int),
]
__all__ = ['stdout', '__off64_t', '__quad_t', 'size_t', '_IO_marker',
           'fprintf', 'FILE', '__off_t', '_IO_lock_t', '_IO_FILE']
theller <at> tubu32:~/devel/ctypeslib-gccxml-0.9$

As you can see, the complete definition of struct _IO_FILE is generated although
unneeded, but it is working code.  One problem is that using the flag '-m module'
with 'module' containing our 'class FILE(Structure); pass' statement does
not work the way one would expect.  At the moment I have no idea how this could
be fixed.

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=/