Roman Yakovenko writes:
> On Mon, Dec 28, 2009 at 12:54 AM, Nikolaus Rath wrote:
>> Hello,
>>
>> Is there a way to export preprocessor definitions (#define ...) with the
>> ctypes code generator?
>>
>> At the moment I'm using this rather nasty hack:
Roman Yakovenko writes:
> On Thu, Dec 24, 2009 at 1:55 AM, Nikolaus Rath wrote:
>> I think POINTER(c_char) should indeed be the default because it is the
>> safer choice.
>
> Unfortunately, I don't agree with you. It is a safer choice - right,
> but it should not be
Roman Yakovenko writes:
> On Sun, Dec 27, 2009 at 10:10 AM, Roman Yakovenko
> wrote:
>> On Sun, Dec 27, 2009 at 2:46 AM, Nikolaus Rath wrote:
>>> Hi,
>>>
>>> Thanks for looking into this. I'm afraid the fix for the CFUNCTYPE vs
>>> POIN
Hello,
Is there a way to export preprocessor definitions (#define ...) with the
ctypes code generator?
At the moment I'm using this rather nasty hack:
/* Header file */
// FUSE_SET_ATTR_* is defined with #define in fuse_lowlevel.h
#include
const int D_FUSE_SET_ATTR_MODE = FUSE_SET_ATTR_MODE;
c
Roman Yakovenko writes:
> On Sat, Dec 26, 2009 at 10:57 AM, Roman Yakovenko
> wrote:
>> Thanks. I will try to fix the problems you reported this evening and
>> will let you know.
>
> Nikolaus, I fixed both issues you reported:
> * http://pygccxml.svn.sourceforge.net/pygccxml/?rev=1784&view=rev
>
Hello,
The ctypes code generator translates the struct
struct fuse_file_info {
int flags;
unsigned long fh_old;
int writepage;
unsigned int direct_io : 1;
unsigned int keep_cache : 1;
unsigned int flush : 1;
unsigned int padding : 29;
Hello,
Py++ translates the struct
typedef int cb_fun_t(char *);
struct info {
cb_fun_t* cb_fun;
int flag;
};
into the Python Structure
class info(ctypes.Structure):
"""class info"""
info._fields_ = [ #class info
("cb_fun", ctypes.POINTER( ctypes.CFUNCTYPE( ctypes.c_int, ctypes.c_c
Roman Yakovenko writes:
> On Wed, Dec 23, 2009 at 9:21 PM, Nikolaus Rath wrote:
>> It would be great if there was a way to tell Py++ that it should not
>> represent the C char * type to the ctypes c_char_p, because the later is
>> supposed to be used only for \0 terminat
Hi Roman,
I know you are busy, so I have already monkeypatched pyplusplus locally
for my purposes. But maybe you are interested to add this feature add
some point in the future:
It would be great if there was a way to tell Py++ that it should not
represent the C char * type to the ctypes c_char_p
Roman Yakovenko writes:
> On Mon, Dec 14, 2009 at 4:00 PM, Nikolaus Rath wrote:
>> Hello,
>>
>> Is there a way to add additional code to the output generated by the
>> ctypes code generator? Specifically, I would like to add some special
>> comments to prev
Roman Yakovenko writes:
> On Tue, Dec 15, 2009 at 12:35 AM, Nikolaus Rath wrote:
>> Roman Yakovenko writes:
>>>> Certainly all the exported symbols should already be available from
>>>> parsing the header file... Is it possible to omit the symbols file
>>
Roman Yakovenko writes:
> On Tue, Dec 15, 2009 at 12:05 AM, Nikolaus Rath wrote:
>> But what I don't understand his this: If exporting only one symbol "a"
>> produces python code that cannot be imported (because it depends on the
>> definition of anothe
Roman Yakovenko writes:
>> Certainly all the exported symbols should already be available from
>> parsing the header file... Is it possible to omit the symbols file
>> and generate code based only on the headers?
>
> I don't think so( it didn't worked in my use case ) but you can try.
> Start to c
Roman Yakovenko writes:
> May be you should take a look on
> "module_builder/ctypes_decl_dependencies.py" module. It contains
> "find_out_dependencies" functionality. As input it takes a set of
> declarations you want to expose, the output is a set of all classes,
> that need to be exposed.
Updat
Roman Yakovenko writes:
> On Mon, Dec 14, 2009 at 7:22 PM, Nikolaus Rath wrote:
>> No, but that's not what I'm saying. The only dependency here is printf,
>> so Py++ should export do_smth, because it is from the main file, and
>> printf from stdio.h
Roman Yakovenko writes:
> On Mon, Dec 14, 2009 at 9:33 PM, Roman Yakovenko
> wrote:
>> On Mon, Dec 14, 2009 at 4:00 PM, Nikolaus Rath wrote:
>>> Hello,
>>>
>>> Is there a way to add additional code to the output generated by the
>>> ctypes code g
Alexey Akimov writes:
> However I am still wondering if there is a way to avoid rebuilding the
> extension when one travel from machine to machine.
The only way is to have exactly the same runtime environment (i.e.,
having installed the same distributions with the same version on the
same archite
Nikolaus Rath writes:
> Roman Yakovenko writes:
>> On Mon, Dec 14, 2009 at 3:14 PM, Nikolaus Rath wrote:
>>> Roman Yakovenko writes:
>>>>> Why is the fuse_file_info struct not translated into ctypes code?
>>>>
>>>> This is because Py++
Alexey Akimov writes:
> I get confused trying to port my boost python extension module. So I've made
> a shared object file test.so which actually perfectly works in the original
> development directory. However, when I copy this file to another Linux
> machine (I also copy some extra libraries su
Roman Yakovenko writes:
> On Mon, Dec 14, 2009 at 3:14 PM, Nikolaus Rath wrote:
>> Roman Yakovenko writes:
>>>> Why is the fuse_file_info struct not translated into ctypes code?
>>>
>>> This is because Py++ tries to make some intelligent guess what t
Roman Yakovenko writes:
> On Mon, Dec 14, 2009 at 2:06 AM, Nikolaus Rath wrote:
>> mb = ctypes_module_builder_t( [header_file], symbols_file, gccxml_cfg )
>> select_fn = lambda f: (check if f is the struct that I want)
>> mb.calldefs( select_fn ).include()
>>
>>
Hello,
Is there a way to add additional code to the output generated by the
ctypes code generator? Specifically, I would like to add some special
comments to prevent the autogenerated files being checked by PyLink and
PyDev.
http://language-binding.net/pyplusplus/documentation/inserting_code.html
Roman Yakovenko writes:
>> Why is the fuse_file_info struct not translated into ctypes code?
>
> This is because Py++ tries to make some intelligent guess what to
> export. By default it exports all declarations found in the files in
> the same directory.
Hmm. Is there any actual use case for tha
Roman Yakovenko writes:
>> The generated code contains
>>
>> libfuse_lib = ctypes.CDLL( r"/usr/lib/libfuse.so" )
>>
>> I'd rather have the library looked up dynamically, as in
>>
>> libfuse = CDLL(find_library("fuse"))
>>
>> Is there a way to accomplish this?
>
> The functionality you ask doesn't
Roman Yakovenko writes:
>> Why is the fuse_file_info struct not translated into ctypes code?
>
> This is because Py++ tries to make some intelligent guess what to
> export. By default it exports all declarations found in the files in
> the same directory.
>
> I suggest you to use include/exclude f
Roman Yakovenko writes:
>>> You can take a look on gmplib example:
>>> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/examples/gmplib_dev/
>>> It is fully working.
There seems to be a problem with the generated code:
,
| $ python
| Python 2.6.4 (r264:75706, Nov 2 2009, 1
Roman Yakovenko writes:
> On Sun, Dec 13, 2009 at 4:54 AM, Nikolaus Rath wrote:
>> Roman Yakovenko writes:
>>> You can take a look on gmplib example:
>>> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/examples/gmplib_dev/
>>> It is fu
Roman Yakovenko writes:
> You can take a look on gmplib example:
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/examples/gmplib_dev/
> It is fully working.
I downloaded Pyplusplus 1.0 from
http://sourceforge.net/projects/pygccxml/files/, but when I try to run
the code, I get
Roman Yakovenko writes:
> On Tue, Dec 8, 2009 at 5:55 PM, Nikolaus Rath wrote:
>>
>> Hello,
>>
>> Is it possible to use Py++ to "convert" structures from a C header, say
>>
>> ,
>> | struct flock
>> | {
>> |
Hello,
Is it possible to use Py++ to "convert" structures from a C header, say
,
| struct flock
| {
| short int l_type; /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK. */
| short int l_whence; /* Where `l_start' is relative to (like `lseek'). */
| #ifndef __USE_FILE_OFFSET64
|
30 matches
Mail list logo
