[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