Race condition in robot.

[Tomas]

I made a wave for this in the sandbox, but decided to post here too,
just in case. I'm not sure yet where to discuss issues with robot
programminh, here or in the waves. Anyway, here goes ...

I inadvertently managed to explode a wave, i.e. it grew to large. What
I did was to add a new blip everytime any of the two events
BLIP_VERSION_CHANGED and WAVELET_VERSION_CHANGED occured,

What I experienced was the wave rapidly filling up with robot blips
until it grew too large.

Apparently the 10. GOTO 10 looks like this:

1. The robot creates a blip "Hello world"
2. The robot receives the events above from the wave
3. The robot appends a blip saying it got the events
4. GOTO 2

I haven't decided how to handle this in my robot yet, but just wanted
to give you guys a heads up on the problem here.

I inadvertently managed to explode a wave, i.e. it grew to large. What
I did was to add a new blip everytime any of the two events
BLIP_VERSION_CHANGED and WAVELET_VERSION_CHANGED occured,

What I experienced was the wave rapidly filling up with robot blips
until it grew too large.

Apparently the 10. GOTO 10 looks like this:

1. The robot creates a blip "Hello world"
2. The robot receives the events above from the wave
3. The robot appends a blip saying it got the events
4. GOTO 2

I haven't decided how to handle this in my robot yet, but just wanted
to give you guys a heads up on the problem here.

[Michael Van Biesbrouck]

On Sun, Jul 19, 2009 at 5:19 PM, Tomas<tomas.g....@gmail.com> wrote:
>
> I made a wave for this in the sandbox, but decided to post here too,
> just in case. I'm not sure yet where to discuss issues with robot
> programminh, here or in the waves. Anyway, here goes ...
>
> I inadvertently managed to explode a wave, i.e. it grew to large. What
> I did was to add a new blip everytime any of the two events
> BLIP_VERSION_CHANGED and WAVELET_VERSION_CHANGED occured,
>
> What I experienced was the wave rapidly filling up with robot blips
> until it grew too large.
>
> Apparently the 10. GOTO 10 looks like this:
>
> 1. The robot creates a blip "Hello world"
> 2. The robot receives the events above from the wave
> 3. The robot appends a blip saying it got the events
> 4. GOTO 2
>
> I haven't decided how to handle this in my robot yet, but just wanted
> to give you guys a heads up on the problem here.

Not a race condition (non-deterministic behaviour in which one event
sometimes happens before another), but definitely a problem with your
robot. The sample robots detect their own blip changes and don't
respond to them, thus avoiding this problem. I think that Debuggy is
one example.

Michael

[mohit chavakula]

I guess its inherent that robots do not catch the changes made by the robots itself. Else it would result in an explosion, just as it did. His problem must be some bug there. Coz my wave too gave the same msg, though it was not running any loop, like in Tomas' case.

Auto

[Tomas]

On 20 Juli, 11:42, Michael Van Biesbrouck <mlvan...@gmail.com> wrote:
> Not a race condition (non-deterministic behaviour in which one event
> sometimes happens before another), but definitely a problem with your
> robot.  The sample robots detect their own blip changes and don't
> respond to them, thus avoiding this problem.  I think that Debuggy is
> one example.
>

I stand corrected, not a race condition. I was tired when I wrote that
post.

Anyway, Debuggy doesn't listen for the VERSION events at all.

<w:capability name="wavelet_self_added"/>
<w:capability name="wavelet_participants_changed"/>
<w:capability name="blip_submitted"/>
<w:capability name="document_changed"/>
<w:capability name="wavelet_blip_created"/>

Yes, there is a problem with the bot, but my question is how to adress
it. The Debuggy bot, for instance, does not perform any precondition
checks before procesing the event. The only check is to prevent it to
trace it's own blips. It still acts on every event it receives, which
leads me to believe that the above event, i.e. the one it responds to
do not trigger the bot when it sends it's delta to the server.

As opposed to the behaviour of my bot. I can post the source if anyone
is interested but it's trivial. It just writes the event name to the
wave when it receives it. And it receives the BLIP_VERSION_CHANGED and
WAVELET_VERSION_CHANGED events when it posts to the wave (and here's
the interesting part) but not the other events.

[Tomas]

On 20 Juli, 11:51, mohit chavakula <mohit.i...@gmail.com> wrote:
> I guess its inherent that robots do not catch the changes made by the robots
> itself. Else it would result in an explosion, just as it did.

That was my assumption also.

> His problem must be some bug there. Coz my wave too gave the same msg, though it was not
> running any loop, like in Tomas' case.

Did your robot write to the wave too, like mine did?

[manatlan]

are you the creator of Eliza bot ?

[Tomas]

On 20 Juli, 08:38, manatlan <manat...@gmail.com> wrote:
> are you the creator of Eliza bot ?
>

No I am not, from reading the waves I think the creator is Anne Veling.

[Michael Van Biesbrouck]

WAVELET_VERSION_CHANGED is going to happen every time you make a
modification to the wavelet. Since it is for an entire wavelet, you
currently might not get a useful context sent to you. In general,
this event type will only be useful for observation. If you add a
blip that gives the current version, then adding the blip will update
the current version (making the just-added blip out of date and
creating a new event). You could display the version number on a web
page or in a different wavelet.

You could avoid the infinite loop by having a stateful robot that only
adds a blip every other version change. (It would have a race
condition with concurrent updates from other sources, though.) Two
copies of the modified robot added to the same wavelet would combine
to create a infinite loop. The same problem would occur if two debug
robots added child blips to all new blips that they did not create
themselves. Robots that create event logs in other wavelets are safe
to add to any wavelet (except their logs, of course).

You might want to track changed versions for blips that you created as
version numbers represent positions in playback history.

Michael

> >
>

[Tomas]

On 21 Juli, 02:31, Michael Van Biesbrouck <mlvan...@gmail.com> wrote:

I thought as much. Thank you for clearing things up for me, it is
greatly appreciated.

I toyed with the idea of tracking the state by spawning a private
wavelet for the bot and keep a copy of the wave there, and then when
the VERSION event triggers do a diff on the waves to see what's
changed, and use that for the precondition. But in the end I discarded
the idea as I would rather rely on the framework to keep track of
things for me, and the solution felt a little inelegant in any case.

How about using annotations to keep track of things in the wave? I
haven't managed to find as much information as I would like on
annotations and how they work here, but it looks like I could use
those for keeping metadata in the wave and the blips. And hence use
them for some state keeping.

Tomas.