Re: [pygccxml-development] problem with an array of pointers

[Gordon W. <gor...@gm...>]

With regard to
http://www.language-binding.net/pyplusplus/documentation/apidocs/pyplusplus.module_builder.builder.module_builder_t-class.html
Is there a document that explains exactly what the different methods (ie
vars, calldefs, mem_funs, decls, etc, etc) correspond to, some of them, like
vars for example are reasonably obvious, but others like call_defs are not
as obvious.

On Thu, Jul 10, 2008 at 10:06 AM, Gordon Wrigley <gor...@gm...>
wrote:

> on http://language-binding.net/pyplusplus/documentation/how_to/how_to.htmlI believe the following code:
>
> registration_code = 'def( "get_size", &%s::get_size )' %
> window.wrapper_alias
>
> mb = module_builder_t( ... )
> window = mb.class_( "window_t" )
> window.member_function( "get_size" ).exclude()
> window.add_wrapper_code( wrapper_code )
> window.registration_code( registration_code )
>
> should instead read
>
> mb = module_builder_t( ... )
> window = mb.class_( "window_t" )
> window.member_function( "get_size" ).exclude()
> window.add_wrapper_code( wrapper_code )
> registration_code = 'def( "get_size", &%s::get_size )' %
> window.wrapper_alias
> window.add_registration_code( registration_code )
>
> and I now have the getName example working
>
>
>
> On Wed, Jul 9, 2008 at 9:49 PM, Gordon Wrigley <gor...@gm...>
> wrote:
>
>> > May we switch to the mailing list? There a lot of advantages to use it.
>>
>> Sure I just dropped off the mailing list so there wouldn't be so much
>> noise for everyone else.
>>
>> > The important question is: how "pythonic" your interface should be?
>>
>> It needs to be quite pythonic, the eventual users aren't programmers by
>> trade and only have exposure to python, no C or C++ abilities, I really
>> can't count on them being careful at all.
>> I'd also like keep it all within the library, where there have to be
>> wrappers I'd rather they were not visible to the end users.
>>
>> >     void getName(char *buff, int len){
>> >         strncpy(buff, "bob", len);
>> >     }
>> > Hmm. In this case we can create new function transformation
>> > Another solution is to generate wrapper for such functions and to expose
>> it.
>>
>> The best wrapper option I can think of for this is:
>> static boost::python::object getName(const Bob& bob, int len){
>>     char buf[len];
>>     bob.getName(buf, len);
>>     std::string hw2(buf);
>>     return bp::object( hw2 );
>> }
>> And then I guess I do this stuff
>> http://language-binding.net/pyplusplus/documentation/how_to/how_to.htmlin py++ which all seems straight forward, unfortunately I can't test it
>> until I get to work tomorrow.
>> I'm not sure if this would be useful enough for other people to justify
>> turning it into a transform.
>>
>> >> The planet example seems to work fine (you suggested in another mail
>> that it
>> >> might).
>> > Good
>>
>> Sorry, my mistake I haven't actually tested the planet example, what I
>> have tested is reading a char array, and that works.
>> However when the the char array contains a nul terminated string the
>> interface is somewhat ugly so I'm considering wrapping those, but that's a
>> problem for later.
>> I will check the planet example in the morning but I suspect at this stage
>> it's just not being exported at all, I know for sure that char* variables
>> aren't showing up at all in the generated cpp file.
>>
>> >     char *fred;
>> > Consider my advice about ctypes.
>> > I can patch Py++ today, so instead of exposing the variable it will
>> > expose the variable address:
>>
>> Thank you but I think I'd rather avoid that.
>> I think can see now how I could produce and tie in get_fred and set_fred
>> functions and how not to leak memory while doing it, I will give that a go
>> tomorrow and we'll see how it works out.
>> What I would like to do that I can't currently see a way of achieving is
>> to wrap those get and set functions together into something that looks like
>> a variable so on the python side instead of going
>> bob.set_fred("hello")
>> print bob.get_fred()
>> I can use it like this instead
>> bob.fred="hello"
>> print bob.fred
>> This is a nice to have as it means I don't have to deviate as much from
>> the C++ api and once this is all going I'm going to have to document
>> everywhere where I deviate from that api.
>>
>> >> I haven't tested the loadFile example yet and I consider it low
>> priority.
>> > I guess "modify_type" function transformation could be used. It is a
>> little bit ugly but it will work
>>
>> It may already be working, like I said I haven't tried it yet, however it
>> is showing up in the generated cpp file so maybe it's all good.
>>
>>
>> On Wed, Jul 9, 2008 at 7:01 PM, Roman Yakovenko <
>> rom...@gm...> wrote:
>>
>>> On Wed, Jul 9, 2008 at 10:43 AM, Gordon Wrigley
>>> <gor...@gm...> wrote:
>>> > Ok, the disclaimers again, I'm not an expert at either C++ or Python
>>> but I
>>> > can get by in both, I don't generally use windows and I haven't done
>>> any
>>> > development for or on windows in years and I've never used boost or
>>> msvc
>>> > before.
>>>
>>> May we switch to the mailing list? There a lot of advantages to use it.
>>>
>>> > My work has recently acquired a moderately large and expensive piece of
>>> test
>>> > equipment. This device has a bunch of windows dlls with C++ headers for
>>> > developing automation tools. These headers total several thousand
>>> lines.
>>> > I've been given the job of making it work from Python which is our
>>> > automation language of choice. I got the job because I have an
>>> established
>>> > history of being able to slove problems.
>>> >
>>> > Currently I have a py++ script that gets most of the stuff exported but
>>> it's
>>> > hard to say how much is exported correctly. Currently the script
>>> produces
>>> > ~170 lines of warnings and I understand them all (this is a big step up
>>> from
>>> > yesterday). I've gotten the bjam stuff sorted and I can compile link
>>> all the
>>> > various dlls (it also uses the matlab common runtime). Then from the
>>> python
>>> > console I can import the lib (that was a big step all the dll's have to
>>> be
>>> > in line for that to work) run the initilization stuff and connect to
>>> the
>>> > device, or at least I appear to connect I haven't been able to do
>>> anything
>>> > useful with it yet.
>>>
>>> I understand your warnings and lack of confidence. I tried to build Py++
>>> in a
>>> such way, that if it exports thing they work, otherwise there is a
>>> warning or
>>> the declaration is not exported.
>>>
>>> > Alot of the stuff in the headers is very basic C like, so char*'s
>>> instead of
>>> > strings, arrays of pointers, pointer passing etc and very little in the
>>> way
>>> > of OO design or C++ style memory management, actually there's very
>>> little
>>> > dynamic memory stuff at all.
>>> >
>>> > I realise that to get a lot of it going I will need to do make custom
>>> > handlers and that's ok, once I have the first couple of those going I
>>> should
>>> > be able to figure the rest out quite quickly.
>>> >
>>> > As an example of some of the stuff I need, in the following C++ code
>>> (which
>>> > should compile and run with a couple of warnings) I need to be able to
>>> do
>>> > all the stuff in the main function from python.
>>>
>>> The important question is: how "pythonic" your interface should be?
>>> I will explain: in almost no time, you can generate code that returns the
>>> address of the variable, than you can use ctypes built-in module to work
>>> with
>>> that variable. Take a look on
>>> http://python.net/crew/theller/ctypes/reference.html#data-types
>>> "from_address" function.
>>>
>>> Of course your users will have to be very very careful.
>>>
>>> You can improve and to create small wrappers around classes in Python
>>> that checks preconditions.
>>>
>>> Another approach is to expose "Pythonic" API, but it has its price and
>>> this is not cheep. I suggest you to go
>>> with the first one.
>>>
>>> > #include <iostream>
>>> >
>>> > class Bob{
>>> > public:
>>> >     char *fred;
>>> >     char *planet;
>>> >     double image[10];
>>> >     double *data[2];
>>> >
>>> >     Bob(){
>>> >         planet="Naboo";
>>> >
>>> >         for(int i=0; i<10; i++) image[i]=i;
>>> >
>>> >         data[0] = new double[5];
>>> >         data[1] = new double[5];
>>> >         for(int i=0; i<5; i++){
>>> >             data[0][i] = 5-i;
>>> >             data[1][i] = i+5;
>>> >         }
>>> >     }
>>> >
>>> >     void getName(char *buff, int len){
>>> >         strncpy(buff, "bob", len);
>>> >     }
>>> >
>>> >     int loadFile(char *name){
>>> >         // do stuff
>>> >         return 0;
>>> >     }
>>> > };
>>> >
>>> > int main(int argc, char **argv){
>>> >     Bob *bob = new Bob();
>>> >     std::cout << "bob->planet = " << bob->planet << std::endl;
>>> >
>>> >     bob->fred = "ABC";
>>> >     std::cout << "bob->fred = " << bob->fred << std::endl;
>>> >
>>> >     char buff[10];
>>> >     bob->getName(buff, 10);
>>> >     std::cout << "buff = " << buff << std::endl;
>>> >
>>> >     std::cout << "bob->image[7] = " << bob->image[7] << std::endl;
>>> >
>>> >     std::cout << "bob->data[1][2] = " << bob->data[1][2] << std::endl;
>>> >
>>> >     std::cout << "bob->loadFile = " << bob->loadFile("data.dat") <<
>>> > std::endl;
>>> > }
>>> >
>>> > Getting the getName example above going is probably my most pressing
>>> need as
>>> > I need that to get version and status info off the device in order to
>>> verify
>>> > that I do actually have a valid connection.
>>>
>>> Hmm. In this case we can create new function transformation
>>> (
>>> http://language-binding.net/pyplusplus/documentation/functions/transformation/transformation.html
>>> )
>>>
>>> It should not be too difficult.
>>>
>>> Another solution is to generate wrapper for such functions and to expose
>>> it.
>>>
>>> > The planet example seems to work fine (you suggested in another mail
>>> that it
>>> > might).
>>>
>>> Good
>>>
>>> > Once I get the fred example going I can probably figure out the the
>>> image
>>> > and data ones.
>>>
>>> Consider my advice about ctypes.
>>>
>>> I can patch Py++ today, so instead of exposing the variable it will
>>> expose the variable address:
>>>
>>> mb = module_builder_t( ... )
>>> mb.var( 'fred' ).expose_address = True
>>>
>>> Better name for property is welcome
>>>
>>> > I haven't tested the loadFile example yet and I consider it low
>>> priority.
>>>
>>> I guess "modify_type" function transformation could be used. It is a
>>> little bit ugly
>>> but it will work
>>>
>>> > Also I very much appreciate the help you have been giving me, thank
>>> you.
>>>
>>> My pleasure.
>>>
>>> --
>>> Roman Yakovenko
>>> C++ Python language binding
>>> http://www.language-binding.net/
>>>
>>
>>
>