[rFSM] only check guard if the transition is triggered by an event (#2)

Hi Ruben,

Sorry for the late reply, I never check this channel, better send these
things to orocos-dev...

On Mo, Okt 21, 2013 at 12:53:33 -0700, Ruben Smits wrote:
>With this pull request guards will only be checked if the transition is
>triggered by an event in case a transition has both events and guards.

What is your motivation for this change, performance optimization? The
issue is the following: the events table is just a "convencience thing"
to cater the most common use case. However, the guard function is the
"real-thing". In the long run, I want to get rid of the 'events' table
and replace it with an event model, that then gets transformed into
guards. So in the end there will be only guards and nothing else. A
second issue is your patch would break the "await" extension, which
translates a special event "await('e1', 'e2')" into a guard condition
which only returns true after both e1 and w2 are received.

Best regards
Markus

Ruben Smits's picture

[rFSM] only check guard if the transition is triggered by an eve

On Fri, Jan 24, 2014 at 10:55 AM, Markus Klotzbuecher <mk [..] ...> wrote:
>
> Hi Ruben,
>
> Sorry for the late reply, I never check this channel, better send these
> things to orocos-dev...
>
> On Mo, Okt 21, 2013 at 12:53:33 -0700, Ruben Smits wrote:
> >With this pull request guards will only be checked if the transition is
> >triggered by an event in case a transition has both events and guards.
>
> What is your motivation for this change, performance optimization?

One of the motivations yes, in recent use-case we also use the guard
to trigger a state-change of a component after an event occurs and
only do the transition if it returns successfull. We however do not
want that function to be called continuously, only if the event
occurs.

We probably could have used an intermediate state to do this too.

>
> The
> issue is the following: the events table is just a "convencience thing"
> to cater the most common use case. However, the guard function is the
> "real-thing". In the long run, I want to get rid of the 'events' table
> and replace it with an event model, that then gets transformed into
> guards. So in the end there will be only guards and nothing else. A
> second issue is your patch would break the "await" extension, which
> translates a special event "await('e1', 'e2')" into a guard condition
> which only returns true after both e1 and w2 are received.

I see, I did not consider the await extension when applying this patch.

Ruben

> Best regards
> Markus
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev