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
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 to
>> export. By default it exports all declarations found in the files in
>>
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:
> 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()
>>
>> But I could not figure out what ki
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 to
>>> export. By default it exports all declar
Hello to everyone,
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 such as
libbo
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
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, because do_smth depends on it.
Unfortunately, GCCXML doesn't provide inform
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 prevent the autogenerated files being checked by PyLink and
> PyDev.
>
> htt
On Mon, Dec 14, 2009 at 1:55 AM, Nikolaus Rath wrote:
> I tried to create a patch, but when I tried to find out where the
> 'CDLL(...)' code is actually written, I got completely lost in the
> source...
I suggest you to read the following document:
http://language-binding.net/pyplusplus/documenta
On Mon, Dec 14, 2009 at 8:25 PM, Alexey Akimov
wrote:
> Hello to everyone,
>
> 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 anoth
Thanks, Nikolaus
However I am still wondering if there is a way to avoid rebuilding the
extension when one travel from machine to machine. Of course that should
definitely work, but it seems unpractical for many purposes or at least
inconvenient. Suppose I want to run some calculations on a cluster
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 generator? Specifically, I would like to add some special
>> comments to prevent the
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++ tries to make some intelligent guess what to
export. B
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
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 generator? Specifically, I would like to add some s
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, because do_smth depends on it.
>
> Unfortunate
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:
>> 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
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 another symbol 'b' that was not explicitly requested),
> what is the point of ge
On Tue, Dec 15, 2009 at 12:40 AM, Nikolaus Rath wrote:
> 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 out
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
>>> and generate code based only on the headers?
>>
>> I don't think so(
Hi,
I want to export an attribute which is a boost::shared_ptr and
I got the following error:
" TypeError: No Python class registered for C++ class class
boost::shared_ptr,class std::allocator > > "
I found an old post on a similar issue :
http://old.nabble.com/Boost.python---How-to-export-shared
23 matches
Mail list logo
