[cram-developers] CRAM meeting notes

[Georg Bartels]

Hi Lorenz,

thanks for the long and clariying message. I always appreciate hearing
about the intentions behind code. To me it sounds like there are reasons
to keep the execution traces around. And if they already proved useful
for plan transformation then maybe Gheorghe will soon find them
interesting..

Regarding unit-tests, I think no one implied you should write some. This
responsibility rests on our shoulders now.

Concluding, I'm gonna go on a limp and mirror Gaya's and Jan's messages
by saying that execution traces will remain supported in cram-core! :D

Cheers,
Georg.



On 12/18/2013 05:58 PM, Lorenz Mösenlechner wrote:
> Hi,
> 
> the purpose of the package is to provide the functionality to record
> execution traces and store them on disk if necessary. With them, it is
> possible to reconstruct the course of actions on a high level. The most
> important feature there is that the interface to the execution trace is in
> pure prolog. If I remember correctly, Michael still wants plan
> transformations. These transformations basically work by first evaluating a
> prolog program to find pre-defined flaws (these flaws are defined in
> Prolog) and then exchanging the corresponding CRAM code by whatever the
> rule specifies. A high-level access to the execution trace is essential for
> this.
> 
> I know that the current implementation has its limits, e.g. it is hard to
> record data that is received at a high rate. However, I never considered
> that as a use case for me. On the other hand. it would be good to add this
> feature to the execution trace.
> 
> Btw. with execution traces and bullet_reasoning, it is also possible to
> reconstruct the robot's internal model of the world at specific times
> (basically whenever an event was generated) and visualize it with my OpenGL
> visualization.
> 
> Just to make sure: these are not theoretical, planned or untested features.
> I had plan transformations working with Cogito, CRAM's predecessor and I
> was using the visualization of the internal world model during plan
> execution quite a lot. And there is a lot of cool stuff that could be done
> with execution traces besides plan transformation, e.g. finishing the use
> of plan projection for designator resolution.
> 
> Of course it would be nice to have tests. I just don't have the time to add
> them.
> 
> So unless you are sure that you don't want to use them in the future but
> implement something yourself, please don't deprecate or remove them.
> 
> Lorenz
> 
> 
> On Wed, Dec 18, 2013 at 5:55 PM, Gayane Kazhoyan <gaya at cs.uni-bremen.de>wrote:
> 
>> Hi,
>>
>> In my opinion, the problem with execution traces (as with most of the
>> other cram functionalities as well) is that we don't have an expert in our
>> Bremen team who knows how to use them, what they are capable of, where
>> could one apply them etc. So, if we are not using them and have to idea if
>> they actually work or not and want to be sure about the things that we're
>> releasing, the package came up for discussion.
>>
>> So, I don't know if I mentioned this before or not, the first thing that
>> I'm going to do when I'm back from vacation in January is to go through all
>> the cram_core packages (and eventually the other stacks as well at some
>> point), document them and write advanced tutorials for each important
>> functionality. I'm going to do that for the execution traces as well, so
>> maybe we can continue the discussion after I'm finished, then we'll be able
>> to go into code details. It might take a while though, a month or two.
>> Unless, of course, Michael stops me from doing that, which I guess he will
>> not because I'm new and have no deadlines yet.
>>
>> If somebody finds that it is crucial to get rid of execution traces now
>> and not include them in the next cram_core release we can discuss that.
>> (Although it looks like we're fine for now...)
>>
>> Gaya
>>
>>
>> On Wed, Dec 18, 2013 at 5:17 PM, Georg Bartels <
>> georg.bartels at cs.uni-bremen.de> wrote:
>>
>>> Hi,
>>>
>>> over the summer, Jan and Moritz (in dicussion with Michal, Hartmut and
>>> Asil) have worked on logging of low-level data in a MongoDB database
>>> outside of CRAM. That tool-chain does not use execution traces but is
>>> working during plan execution. My impression was that they preferred
>>> this new tool-chain over execution traces.
>>>
>>> Our discussion this week was how to proceed with execution traces (now
>>> that an alternative system is in active use + they are the only core
>>> package without unit-tests) in the future. My point was that execution
>>> traces seem to offer features the new tool-chain does not have, and they
>>> are there and probably working. Hence, my suggestion to add unit-tests
>>> (and maybe a tutorial or two) to clarify and document their usage in
>>> case someone wants to use/extent them in the future again. As both Jan
>>> and Moritz were not in Bremen, we did not make any decision on Tuesday.
>>> Hence, we could continue discussing online. ;)
>>>
>>> Hope this clears things up a bit.
>>>
>>> Cheers,
>>> Georg.
>>>
>>>
>>>  On 12/18/2013 04:49 PM, Lorenz Mösenlechner wrote:
>>>> Hi,
>>>>
>>>> just a question: why do you want to get rid of support for execution
>>>> traces? I always thought they are an important feature of CRAM so I
>>> wonder
>>>> what the problem with them is. Could someone please clarify? :)
>>>>
>>>> Thanks,
>>>> Lorenz
>>>>
>>>>
>>>>
>>>> On Tue, Dec 17, 2013 at 11:22 AM, Georg Bartels <
>>>> georg.bartels at cs.uni-bremen.de> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> please find attached the minutes of today's CRAM developers meeting in
>>>>> Bremen.
>>>>>
>>>>> Cheers,
>>>>> Georg.
>>>>>
>>>>> _______________________________________________
>>>>> cram-developers mailing list
>>>>> cram-developers at informatik.uni-bremen.de
>>>>>
>>> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> cram-developers mailing list
>>> cram-developers at informatik.uni-bremen.de
>>> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
>>>
>>
>>
>>
>> _______________________________________________
>> cram-developers mailing list
>> cram-developers at informatik.uni-bremen.de
>> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
>>
>>
> 
> 
> 
> _______________________________________________
> cram-developers mailing list
> cram-developers at informatik.uni-bremen.de
> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
>