[cram-developers] [Cram-developers] minutes from this week's meeting

[Gayane Kazhoyan]

Hi,

 * CRAM Prolog:
>    I'm not sure what you mean with it being difficult. Apart form the
> syntax, I think it is not much different from SWI-Prolog but allows much
> better for interactive development. I know that it is slow and it became
> even slower by the recent addition of callbacks in the prove process. I
> would like to get rid of those if nobody objects. I always wanted to have
> prolog compiler but I never found the time to implement it. It wouldn't be
> as fast as SWI Prolog of course, but a significant speedup could still be
> achieved. Anyway, I actually wanted to clarify a little the reasons for me
> to implement a Prolog interpreter instead of using SWI Prolog. The most
> important reason is that it is much easier to integrate common lisp data
> structures, e.g. the execution trace but also the physics engine if you
> implement the interpreter in Lisp. The other important reason is that it
> allows for multiple prove processes at the same time. The complete state of
> the search is stored in a lazy list. It can be copied around, stored or
> whatever and then re-used later when an additional solution is required.
> SWI Prolog only allows for one prolog engine per thread, i.e. you need to
> terminate the current prove process if you want to start a new one. This
> feature is definitely used in designators. Finally, communication through
> rosprolog is pretty slow. Somewhere deep in the history of the cram
> repository, you can find a common lisp wrapper for SWI prolog that uses its
> foreign function interface. Unfortunately we had to drop it though because
> prolog interop with java doesn't work together with SBCL.
>

I agree with Georg (as a result of our recent discussion) on the matter
that having both CRAM Prolog and KnowRob SWI Prolog in one system is
confusing, if we ever get to integrate CRAM and Knowrob together. Btw, is
it actually planned for the future or are they supposed to stay as two
completely independent systems with a little bit of data exchange between
one another. If yes, then I also agree with Georg that there is much
functionality that is very similar in the two systems, at least from what I
can say by reading KnowRob papers, and one could try to merge those.

Concerning the syntax, I remember when I first saw CRAM Prolog, without
having prior experience with Prolog in general, I was really confused
what's what. So unless it is clearly stated to the users of CRAM that CRAM
Prolog is a custom implementation and works a little bit differently from
what they are used to it can get really confusing. However, as soon as you
understand that, getting used to the new syntax is actually pretty easy.
But if people think that the syntax is a problem maybe there is a way to
wrap the Prolog to make it more intuitive, or not call it Prolog at all but
a DFS solver or something like that. We could think of an elegant solution
to this.


>  * CRAM Physics: Please let me know what is not working and how I can
> reproduce the problems. Is it just not compiling on Hydro? I can have a
> look there. Also, please clarify what you want to clean up. I tried to keep
> it as clean as possible and I'm really curious what specifically needs to
> be cleaned up.
>

Actually, except cram_core, nothing else rosmakes on my computer under
Hydro at the moment. Some of the messages got renamed, and some things are
missing. If you could look into that it would be great! And except
cram_language nothing compiles actually, but maybe it's only a problem with
my system. But, I guess, some of the packages got ported to Hydro already
but the changes where not pushed to the cram-code repo yet.

In order to avoid doing things twice, could you guys actually take a look
at this list and edit it if you have something to add?
https://docs.google.com/spreadsheet/ccc?key=0AvxV4RoE1wHAdDlQN2pWS2xUbHljQTBsUjJLbVBxaWc#gid=0
It's a list of all cram-related packages that `rospack list' and `grep
cram' could find on my system.
The bullet-related things are not there yet, so if you can, please add them
or any other packages missing in the list as well.

Have a nice weekend :)
Gaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.informatik.uni-bremen.de/pipermail/cram-developers/attachments/20131122/66e7ce94/attachment.html>