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

[Lorenz Mösenlechner]

Hi Gaya,

On Fri, Nov 22, 2013 at 5:41 PM, Gayane Kazhoyan <gaya at cs.uni-bremen.de>
 wrote:

> 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.
>

I think this is a pretty old discussion :) If you guys are motivated enough
and have enough time, I definitely would say that dropping CRAM Prolog in
favor of SWI Prolog would be a good thing. Unfortunately, I still don't see
how that would be possible. As I said, one of the most important problems
is that performing a lot of json_prolog requests is just way too expensive.
Maybe replacing it with a faster communication mechanism or generating
multiple solutions at once instead of requesting them incrementally could
help there. A second issue is that it is not trivial to represent Lisp data
structures as, for instance, used in execution traces. Both issues would be
solved by using SWI Prolog though its foreign function interface directly
from Common Lisp. But I don't see how to make it work at the moment. If you
have ideas for possible solutions or maybe completely different ideas that
were not considered yet, please let me know.


> 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.
>

I think feature-wise the only notable difference between SWI Prolog and
CRAM Prolog is its syntax. Am I missing something? Of course, SWI's
performance is much better since it is a real Prolog compiler.

Btw. I think there are a bunch of low-hanging fruits to improve the
performance of CRAM Prolog. Currently, the computational complexity for
proving one single predicate is linear in the number of all predicates
defined. This could easily be reduced to linear complexity in the number of
all predicates that match the name of the predicate to be proved. I'll have
a look if I find some spare time this weekend.


>
>
>>  * 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.
>

I'll at least have a look at cram_physics.


>
> 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.
>

Great, thanks!
Lorenz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.informatik.uni-bremen.de/pipermail/cram-developers/attachments/20131122/e5537db7/attachment.html>