[gecode-users] Logilab's Python Wrapper for Gecode

Grégoire Dooms dooms at info.ucl.ac.be
Wed Mar 22 10:45:47 CET 2006


Guido Tack wrote:
> Hi Grégoire!
>
>   
>> During this print we started the development of a Python wrapper for
>> Gecode. We were able to wrap a simple generic space which allows to
>> dynamically register integer variables in it and post a few constraints. We
>> also implemented a generic propgator over ints which triggers  a Python
>> callback  on propagate().
>> The embryonic wrapper is available at
>> http://codespeak.net/pypy/dist/pypy/lib/logic/gecode_wrapper/
>>     
>
> That's nice work. I saw that you used the same idea we're using for the Alice 
> wrapper, to represent variables as array indices. One problem with this 
> approach is that you can't allocate "temporary" variables, you always have to 
> copy all the variables you've created. Are you planning to work around this?
>
>   
Yes it is was in the original design. And it is currently in add_int_var 
(the bool temp argument) but it throws Unimplemented :-)
I think it should be possible to assign other ids (negative numbers ? ) 
to temporary variables in the space. Those would be local to one Space 
and would not get copied.
> As you know, we're using swig to generate a Java wrapper. Did you consider 
> this option, too? Although we had to annotate a lot, and provide many 
> customized translations between Java and C++, I still think it saved us a lot 
> of work.
>   
Yes. We tought about using it too. The final decision was based on the 
personnal taste of Ludovic for SWIG w/ Python ( ;-) ) and also on the 
fact that we have to go through a C API to make it useable in PyPy. So 
the design involves making this special Space with dynamic arrays of 
variables then a C wrapper with only void* and int objects in the 
interface. Then on the Python we use ctypes (or rctypes in PyPy) which 
gives that same procedural interface. Finally there should be a higher 
level, more  Pythonic wrapper over that one.
 
> We recently had some problems with memory management. A propagator written in 
> Java must be kept alive as long as the "corresponding C++ propagator" is 
> alive - and due to a bug in swig, our Java propagators were never finalized. 
> This means we had a huge memory leak. Does Python provide some clever way for 
> coping with these kinds of problems?
>   

Well, that rings my bell about the discussions on keeping away from 
SWIG. There are some nice memory management features in Boost.Python but 
we need to go pure C. So that memory management will have to be hand 
written.
It is not implemented yet but does not seem too complicated:
Correct me if I'm wrong: that implies calling Propagator(home,true) in 
our  MyPropagator constructor to have its C++ destructor called.
On the Python side, memory management uses reference counting. So a 
propagator copy should INCREF and a destructor should DECREF. AFAIK it 
is not possible to do it from the C++ side through ctypes so it would 
need to be emulated on the Python side. The API to post a propagator 
would then not only provide a propagate callable but also incref and 
decref callables for the propagate one :-).

I don't have much time to work on this before the Summer but I think 
they plan on developing it in Logilab Paris.

Best,
--
Grégoire





More information about the gecode-users mailing list