Re: [ccmtools-devel] integration of our python binding

[Darrell S. <da...@sc...>]

On Oct 10, 2006, at 8:52 AM, Egon Teiniker wrote:

> yes, I think that's still the problem!
>
> Do you know that the ccmtools now support Java components too?
> So, what's about Jython...

Yes, I saw that when perusing the source code. I argued for Jython in  
the beginning of our project, but the argument of others that there  
are too many python addons coded in C/C++ for Jython to really be  
viable won out in the end.

Our python binding works very nicely. In general, we're please with  
the way it has worked out with ccmtools, but the test will come when  
we try to distribute our "python components" via mico. Currently, the  
components are only directly loaded into python.

I'd like to fold my python binding back into mainline ccmtools, but  
I'm at a bit of a quandary of how best to do that. I guess the  
initial questions are:

(1) we do not want to use confix; we'd like to have an alternative  
build option for C++ [in particular, we've been using Ant to build  
the C++ portion of the CCMTOOLS distribution, i.e. cpp-environment  
and wx, and Python's build system (e.g. via a setup.py file) build  
everything that gets generated]. While we are not wedded to Ant, we  
don't want to use confix (though this is based on our experience with  
it which is now a few years old). Are you open to introducing another  
C++ build option?

(2) We've introduced another layer below the *_impl.cc/h files which  
provides boiler plate for implementing the components in terms of  
standard and STL types (no CORBA, no CCMTOOLS, etc.). In this mode,  
the *_impl.cc/h files are used to provide wrappers to do any extra  
conversion that may be required. These wrappers are filled in with  
info from XML files. For example, one thing that these wrappers do is  
convert exceptions from the native library into CCMException. Our  
goal here is that the layer (we've called *_cmpt.cc/h) can serve as a  
componentized stdc++ interface to our package, and it also provides a  
clean dividing line between generated code (and the generation  
aparatus) and the hand-coded business logic. Is this something you're  
open to adding as an option (in our version, it is switched on with  
"--coda=<setup-xml-file>")?

(3) Our "any" processing seems different from what you added. In  
particular, we needed to go from a Python dictionary to a  
std::map<std::string,casac::variant>. My impression is that your  
implementation only handles structs, and to handle more complex  
things more information is required than can easily be expressed in a  
keyword/value file. We setup these "any" conversions with an XML file  
that lists the to/from conversion functions that are used at each  
stage, i.e. in our case python or "coda" (our independence layer).  
I'll attach a snippet below.

(4) I guess I need to get a new version of WX to be able to build the  
current version of CCMTOOLS.

I hope we haven't diverged too far for us to merge back into the  
mainstream. I tried to make changes in a way that was consistent, but  
in just listing these, I see that there's been a fair bit of  
modification. I guess here's what I would propose we do:

(a) I'll make our version of CCMTOOLS available via anonymous  
subversion so you can get the source and look it over if you're  
inclined to do so.
(b) we have Redhat RPMs available, and I could build them for SuSE,  
Mandrake, or Fedora if you would like to try it out.
(c) I'll get a version of WX (when someone lets me know where to find  
it), and see if I can, build things sans confix.

Let me know what you think,
Darrell

PS: I just attached our whole setup file, it specifies things like  
"polymorph" an integer to a vector of integers in the python binding  
as well as how to convert "any"s.