Re: [C++-sig] [Py++] Missing struct
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 that? Just exporting the declarations in one file without taking into account their dependencies doesn't make much sense to me. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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
>> the same directory.
>
> Hmm. Is there any actual use case for that? Just exporting the
> declarations in one file without taking into account their dependencies
> doesn't make much sense to me.
//pseudo code
#include "stdio.h"
void do_smth( int i ){
printf( i );
}
Do you still think Py++ needs to export every declaration that comes
from "stdio.h" header?
Py++ assumes, that files, that belongs to the same directory as the
file you pass, contain "interface", why all others contain
implementation.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] [Py++] Include additional code with ctypes code generator
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 talks about a add_registration_code method, but it doesn't seem to exist for the ctypes generator: mb = ctypes_module_builder_t( [header_file], symbols_file, gccxml_config=gccxml_cfg ) mb.build_code_creator(shared_library_file) mb.add_registration_code( '#...@pydevcodeanalysisignore', False ) yields AttributeError: 'ctypes_module_builder_t' object has no attribute 'add_registration_code' Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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 kind of argument the select_fn function
>> gets. Can you help me out again?
>
> http://language-binding.net/pygccxml/query_interface.html
Thanks. The following now includes the missing struct:
mb.global_ns.class_('fuse_conn_info').include()
but I am actually not really interested in that struct itself, but in
the struct fuse_lowlevel_ops whose definitions happens to include a
reference to fuse_conn_info:
# from the generated code
fuse_lowlevel_ops._fields_ = [ #class fuse_lowlevel_ops
("init", ctypes.POINTER( ctypes.CFUNCTYPE( None, ctypes.c_void_p,
ctypes.POINTER( fuse_conn_info ) ) )),
("destroy", ctypes.POINTER( ctypes.CFUNCTYPE( None, ctypes.c_void_p ) )),
# [...]
So I tried to include the class that I'm interested in instead:
mb.global_ns.class_('fuse_lowlevel_ops').include()
but in that case fuse_conn_info is no longer exported. Does that mean
that I have to manually trace and include all dependencies? I can't
quite believe that...
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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 declarations found in the files in
>>> the same directory.
>>
>> Hmm. Is there any actual use case for that? Just exporting the
>> declarations in one file without taking into account their dependencies
>> doesn't make much sense to me.
>
> //pseudo code
> #include "stdio.h"
>
> void do_smth( int i ){
> printf( i );
> }
>
> Do you still think Py++ needs to export every declaration that comes
> from "stdio.h" header?
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.
> Py++ assumes, that files, that belongs to the same directory as the
> file you pass, contain "interface", why all others contain
> implementation.
In my opinion that is not a particularly good assumption. Why not work
without it and instead export all the dependencies of the file I'm
passing?
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] what do I need to correctly port boost python extensions
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 libboost_python-gcc344-1_39.so.1.39.0 and make sure that both .so files are in PATH and LD_LIBRARY_PATH) I recieve "Import Error: undefined symbol: /home/username/bin/libboost_python-gcc34-1_39.so.1.39.0: PyUnicodeUCS4_FromEncodedObject". I aslo istalled the same version (compared to one which was used for creation of the module) of Python to the Linux machine where I try to use my extension. Can anyone explain me where could the problem be. Also I would clarify what is the general way to export just created modules? As I understand the order is following: 1) create .so object (look for it in /bin/compiler-name/release-or-debug/module-name.so directory) 2) copy this file as well as other necessary library to some /bin or /lib directory (for convenience) - and make sure they are in PATH and LD_LIBRARY_PATH variables. 3) import the module in python interpreter. Do I need to do something else (define some other variables or make some other changes) in order to make my module work? Thanks a lot Alexey ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] what do I need to correctly port boost python extensions
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 such as I am not very familiar with Py++ yet, but .so libraries are not supposed to be copied around from machine to machine unless your runtime environment is exactly the same. You should probably compile test.so (and any other required libraries) on the target machine (i.e., copy the sources and not the binaries from the development system). Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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 information about function implementation and arbitrary C/C++ expression. So Py++ can't see this dependency. >> Py++ assumes, that files, that belongs to the same directory as the >> file you pass, contain "interface", why all others contain >> implementation. > > In my opinion that is not a particularly good assumption. Why not work > without it and instead export all the dependencies of the file I'm > passing? Because what you think is good for you is actually bad for me( and other users who already use Py++ ). The assumption has a simple background( at least in my case ): in most cases the project dependencies are bigger( more code ) than the project itself. So it should be much easier to define what to export, then the opposite. You can argue with this, but this is the current default behavior and it is not going to change. I understand that your use case is different than my - fine. I believe Py++ has all functionality you need, to define what declarations should be exported. Consider to use "reverse"logic: mb = ctypes_module_builder_t( ... ) mb.global_ns.exclude() #and now define what you want to include 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. HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Include additional code with ctypes code generator
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. > > http://language-binding.net/pyplusplus/documentation/inserting_code.html > talks about a add_registration_code method, but it doesn't seem to exist > for the ctypes generator: > > mb = ctypes_module_builder_t( [header_file], symbols_file, > gccxml_config=gccxml_cfg ) > mb.build_code_creator(shared_library_file) > mb.add_registration_code( '#...@pydevcodeanalysisignore', False ) > > yields > > AttributeError: 'ctypes_module_builder_t' object has no attribute > 'add_registration_code' > Right now - there is no such way. I will try to add this functionality today or tomorrow. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Generate Python code for ctypes?
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/documentation/architecture.html#code-generation-engine I hope it will clarify few things. > > What I don't quite understand is what the symbols file is actually used > for. The code seems to determine the symbols available in the shared > library, but what is it doing with that information? Py++ uses information extracted from shared library * to define the exact set of declarations which needs to be exported * to extract the function calling convention * to extract "mangled" function and/or variable name - later it will be used to provide access to that symbol. For example, you can use C++ compiler to compile "C" code and still get access to the functionality. > 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 comment out code in ctypes_builder.py and post the result :-) -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] what do I need to correctly port boost python extensions
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 another Linux > machine (I also copy some extra libraries such as > libboost_python-gcc344-1_39.so.1.39.0 and make sure that both .so files are > in PATH and LD_LIBRARY_PATH) I recieve "Import Error: undefined symbol: > /home/username/bin/libboost_python-gcc34-1_39.so.1.39.0: > PyUnicodeUCS4_FromEncodedObject". I aslo istalled the same version (compared > to one which was used for creation of the module) of Python to the Linux > machine where I try to use my extension. > Can anyone explain me where could the problem be. In my opinion you compiled the module against Python version/build which is differ from the "run" environment. > Also I would clarify what > is the general way to export just created modules? As I understand the order > is following: 1) create .so object (look for it in > /bin/compiler-name/release-or-debug/module-name.so directory) 2) copy this > file as well as other necessary library to some /bin or /lib directory (for > convenience) - and make sure they are in PATH and LD_LIBRARY_PATH variables. You can use "ldd" command to find out dependencies. In the case, you have few interpreters it also can help you to see what python*.so will be actually used. > 3) import the module in python interpreter. > > Do I need to do something else (define some other variables or make some > other changes) in order to make my module work? In case you have few modules, sometimes you need to tweak "dlopen" flags. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] what do I need to correctly port boost python extensions
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 using the extension. That means I need the library to be copied on every machine of that cluster (may be I am wrong with this but this is most straightforward way to clone the process). Also this makes lot of potential troubles for other users who would want to work with such extension - do they need to rebuild extension module every time? I hope that there may exist some fancy way to avoid rebuilding the module (also to do this the user would need boost python installed, what may require some extra-work for that user). So if anyone knows if this is still possible - please, let me know. Alexey 2009/12/14 Nikolaus Rath > 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 such as > > I am not very familiar with Py++ yet, but .so libraries are not supposed > to be copied around from machine to machine unless your runtime > environment is exactly the same. > > You should probably compile test.so (and any other required libraries) > on the target machine (i.e., copy the sources and not the binaries from > the development system). > > > Best, > > -Nikolaus > > -- > »Time flies like an arrow, fruit flies like a Banana.« > > PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C > > ___ > Cplusplus-sig mailing list > Cplusplus-sig@python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Include additional code with ctypes code generator
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 autogenerated files being checked by PyLink and >> PyDev. >> > > Right now - there is no such way. I will try to add this functionality > today or tomorrow. Nikolaus, can you take a (dummy) generated code and show me where you need to add the code? Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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. By default it exports all declarations found in the files in
the same directory.
>>>
>>> Hmm. Is there any actual use case for that? Just exporting the
>>> declarations in one file without taking into account their dependencies
>>> doesn't make much sense to me.
>>
>> //pseudo code
>> #include "stdio.h"
>>
>> void do_smth( int i ){
>> printf( i );
>> }
>>
>> Do you still think Py++ needs to export every declaration that comes
>> from "stdio.h" header?
>
> 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.
I have to correct myself. printf() is actually only important for the
implementation, so as far as ctypes is concerned, the above code does
not have any dependencies at all and I would not expect Py++ to export
any stdio.h symbols.
In the following case however, I would expect Py++ to export struct stat
from stat.h, since the code depends on it and I don't really see why
anyone would want to export only do_smth (since the generated code won't
even load into Python due to a missing symbol):
#include
void do_smth(struct stat* foo) {
printf(foo->st_ino);
}
I hope that clarifies what I mean.
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] what do I need to correctly port boost python extensions
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 architecture). Otherwise you have to recompile. > Suppose I want to run some calculations on a cluster using the > extension. That means I need the library to be copied on every machine of > that cluster (may be I am wrong with this but this is most straightforward > way to clone the process). Well, in a cluster you might be able to configure your systems sufficiently homogenous that it works. > Also this makes lot of potential troubles for > other users who would want to work with such extension - do they need to > rebuild extension module every time? No, only once when they install it on their machine. > I hope that there may exist some fancy way to avoid rebuilding the > module (also to do this the user would need boost python installed, > what may require some extra-work for that user). No, there is no way to avoid that. Say hello to the realities of software distribution :-). -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Include additional code with ctypes code generator
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 special >>> comments to prevent the autogenerated files being checked by PyLink and >>> PyDev. >>> >> >> Right now - there is no such way. I will try to add this functionality >> today or tomorrow. > > Nikolaus, can you take a (dummy) generated code and show me where you > need to add the code? At the very beginning would be best, right below '# This file has been generated by Py++'. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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.
>
> Unfortunately, GCCXML doesn't provide information about function
> implementation and arbitrary C/C++ expression. So Py++ can't see this
> dependency.
Yes, I read the example wrong. See other mail.
>>> Py++ assumes, that files, that belongs to the same directory as the
>>> file you pass, contain "interface", why all others contain
>>> implementation.
>>
>> In my opinion that is not a particularly good assumption. Why not work
>> without it and instead export all the dependencies of the file I'm
>> passing?
>
> Because what you think is good for you is actually bad for me( and
> other users who already use Py++ ).
>
> The assumption has a simple background( at least in my case ): in most
> cases the project dependencies are bigger( more code ) than the
> project itself. So it should be much easier to define what to export,
> then the opposite. You can argue with this, but this is the current
> default behavior and it is not going to change.
No, I think either I don't understand what you are saying or the other
way around. And I'm not arguing about the current implementation being
good or bad (or at least I'm trying not to), but I'm trying to
understand where we don't understand each other :-).
I totally agree with you that it is better to define what to export,
rather than what not to export (actually I'm already calling
global_ns.exclude() first thing in my code).
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 generating the code in the first place? Under which
circumstances do you want to generate code that cannot be imported?
> I understand that your use case is different than my - fine. I believe
> Py++ has all functionality you need, to define what declarations
> should be exported. Consider to use "reverse"logic:
>
> mb = ctypes_module_builder_t( ... )
> mb.global_ns.exclude()
> #and now define what you want to include
>
> 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.
Actually I already did, but I failed to understand the interface once
again. What exactly is a "set of declarations"? A list of the symbol
names? A list of element as they are returned by e.g.
global_ns.class_('mysymbol')?
Can you tell me how to instruct Py++ to include the struct
'fuse_lowlevel_ops' and everything it that it depends on?
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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.
Update: I found an usage example in ctypes_builder.py and came up with
the following code:
included_decls = set([mb.global_ns.class_('fuse_lowlevel_ops')])
to_be_included = ctypes_decls_dependencies.find_out_dependencies(included_decls)
to_be_included.update(included_decls)
map( lambda d: d.include(), to_be_included )
but the resulted generated code still contains only the single struct:
fuse_lowlevel_ops._fields_ = [ #class fuse_lowlevel_ops
("init", ctypes.POINTER( ctypes.CFUNCTYPE( None, ctypes.c_void_p,
ctypes.POINTER( fuse_conn_info ) ) )),
("destroy", ctypes.POINTER( ctypes.CFUNCTYPE( None, ctypes.c_void_p ) )),
("lookup", ctypes.POINTER( ctypes.CFUNCTYPE( None, ctypes.POINTER(
fuse_req ), ctypes.c_ulong, ctypes.c_char_p ) )),
although there are clearly dependencies on fuse_conn_info and fuse_req.
Thank you for taking so much time on my flood of questions!
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Generate Python code for ctypes?
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 comment out code in ctypes_builder.py and post the result :-) I looked into the xml file created by gccxml and (at least in the case of C code) it seems to contain all the information that's needed. I modified parsers.py to return an empty dict if no symbols_file is provided: def merge_information( global_ns, fname, runs_under_unittest=False ): """high level function - select the appropriate binary file parser and integrates the information from the file to the declarations tree. """ if fname is None: return dict() this seems to work partially. I can still export all the struct's, but I no longer get any function exports. I can mark them as to be exported without any error, but they don't show up in the generated code. Any idea? Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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 generating the code in the first place? Under which
> circumstances do you want to generate code that cannot be imported?
Consider use case, where your code is split between different modules:
module Base:
struct B;
module Derived1:
d( B* )
module Derived2:
d2( B* )
In this case, when you exposed Derived* you don't want to expose struct B.
>> I understand that your use case is different than my - fine. I believe
>> Py++ has all functionality you need, to define what declarations
>> should be exported. Consider to use "reverse"logic:
>>
>> mb = ctypes_module_builder_t( ... )
>> mb.global_ns.exclude()
>> #and now define what you want to include
>>
>> 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.
>
> Actually I already did, but I failed to understand the interface once
> again. What exactly is a "set of declarations"? A list of the symbol
> names? A list of element as they are returned by e.g.
> global_ns.class_('mysymbol')?
>
> Can you tell me how to instruct Py++ to include the struct
> 'fuse_lowlevel_ops' and everything it that it depends on?
mb = ctypes_module_builder_t( ... )
mb.global_ns.exclude()
fuse_lowlevel_ops = mb.class_( ' 'fuse_lowlevel_ops' )
for d in find_out_dependencies( [fuse_lowlevel_ops] ):
d.include()
I can't test the code right now, but it should look very similar to this.
HTH
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Missing struct
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 output is a set of all classes,
>> that need to be exposed.
>
> Update: I found an usage example in ctypes_builder.py and came up with
> the following code:
>
> included_decls = set([mb.global_ns.class_('fuse_lowlevel_ops')])
> to_be_included =
> ctypes_decls_dependencies.find_out_dependencies(included_decls)
> to_be_included.update(included_decls)
> map( lambda d: d.include(), to_be_included )
>
> but the resulted generated code still contains only the single struct:
>
> fuse_lowlevel_ops._fields_ = [ #class fuse_lowlevel_ops
> ("init", ctypes.POINTER( ctypes.CFUNCTYPE( None, ctypes.c_void_p,
> ctypes.POINTER( fuse_conn_info ) ) )),
> ("destroy", ctypes.POINTER( ctypes.CFUNCTYPE( None, ctypes.c_void_p ) )),
> ("lookup", ctypes.POINTER( ctypes.CFUNCTYPE( None, ctypes.POINTER(
> fuse_req ), ctypes.c_ulong, ctypes.c_char_p ) )),
>
> although there are clearly dependencies on fuse_conn_info and fuse_req.
Can you create a small example, which reproduce the problem and send it to me?
Thanks
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Py++] Generate Python code for ctypes?
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( it didn't worked in my use case ) but you can try. >> Start to comment out code in ctypes_builder.py and post the result :-) > > I looked into the xml file created by gccxml and (at least in the case > of C code) it seems to contain all the information that's needed. > > I modified parsers.py to return an empty dict if no symbols_file is > provided: > > def merge_information( global_ns, fname, runs_under_unittest=False ): > """high level function - select the appropriate binary file parser and > integrates > the information from the file to the declarations tree. """ > if fname is None: > return dict() > > > this seems to work partially. I can still export all the struct's, but I > no longer get any function exports. I can mark them as to be exported > without any error, but they don't show up in the generated code. > > Any idea? Yes. Py++ thinks that those functions are "private" and doesn't export them. You should dig father ( creators_factory/ctypes_creator.py ). -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Boost Python - How to export boost::shared_ptr
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_ptr%3Cvector%3Cshared_ptr%3Cstring%3E-%3E-%3E--tt22389131.html#a22389131but no one has replied :-\ Can anyone tell me how can I export this type? Thank you! Romain ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
