Hi Andreas

I would like to learn about this Croquet futures business.
And in so doing I would like to try to document it better.
Is this possible?
Where can I look for information?
Are there any isolated tests that I could step through?
Is there anyone who would be willing to teach me edit me?
Where could I put the new documentation?
I think the best way to teach people how futures work inside would
be to construct a sequence of tests that progress from simple
to more complex and that can be run on a single machine.
By stepping through these tests and documenting the methods
that show up along the way the implementation details can be
shown.  By putting each of the common usages into a test
you can also show how futures should be used from a user's
point of view starting with simple usage and moving on to
complex usage.  Such tests would not need to be single
stepped if the only purpose was to learn usages.  If the
implementation was to be learned then stepping could be done.
I give an example of how such things could work in the picoLARC
project on sourceforge.net for Dolphin Smalltalk community
edition 6.  You make a sequence of tests that run one after the
other.  These tests document usage and implementation in an
active way that doesn't go out of date.

Most people hate to make documentation.  I do not.  I like it.

What do you think?
Where is the info I need?
How can I upload the documentation that I make?
How can I upload new test sequences and the extra
    method documentations I will put into the methods that
    that show up along the way?
Who will edit me?

-Kjell
picoVerse

by the way there are a lot of ambiguous terms below that
I would like to make more concrete in the documentation
I attempt to make.

On Nov 7, 2007 12:31 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
> Igor Stasenko wrote:
> > On 07/11/2007, Andreas Raab <andreas.raab at gmx.de> wrote:
> >> Same answer (though strictly speaking you may get an error that you
> >> can't *wait* in an eventual system).
> > This doesn't change anything, you may put:
> > (1 to: 1000000 atRandom) do: [1+1]
> > instead of delay.
>
> Sure. But it makes no difference. I was only pointing this out for
> completeness.
>
> > Hmm. An example above was to show that when running in parallel there
> > is equal chance to get to ^3 or ^4 first.
>
> No, there isn't. It's simply not how it works. This code cannot run in
> parallel because it's on the same island (necessarily so for non-shared
> state concurrency since blocks have access to receiver variables) and
> can therefore *not* be executed in parallel. The order is completely
> deterministic - scheduling the message in the future *guarantees* that
> it will be executed only after the ^4 has completed. It can't be any
> other way for it to work; if you'd want to run it in parallel you'd need
> to copy it to a different island first in which case the return value
> from the method would *still* be 4! It's completely deterministic, the
> result is 4.
>
> > And in previous message you described behavior, when running code gets
> > to ^4 first. But what if it gets to ^3 first?
>
> It cannot. It simply cannot. If you don't understand why, then you don't
> fully understand how E and Croquet works. The block is created in the
> same island as the receiver. When it is passed to another island (as
> argument to the future ifTrue: message) it will be converted into a
> remote reference. This reference only understands future messages (all
> the immediate messages relate entirely to its role as a reference not
> the underlying object) which is the reason why I distinguished these
> cases in the True>>ifTrue: code (simply because #value on a remote
> reference has no bearing on executing the block that this reference
> points to but scheduling a future value message does).
>
> This in turn means that the second island (the one containing the
> boolean) *must schedule* the future #value with the first island which
> means that the first island will only execute it after the ^4 has been
> executed. It is the *only* way in which this can work in an event-loop
> environment.
>
> What happens is something like here:
>
> Island A:                                     Island B:
> ->message starts running
>   -> aBool future ifTrue:[] ..... -> .....  <schedules True>>ifTrue:>
>   -> Delay wait
>
>                        ... time passes ...
>            <at this point Island A is running the message>
>            <and Island B has the #ifTrue: message scheduled>
>
>                                                -> executes True>>ifTrue:
>    <schedules aBlock value>   ..... <- .....   <- aBlock future value
>                                                -> True>>ifTrue: finishes
>
>                      .... time passes ....
>             <Island A is still not finished with the delay>
>             <Island B has posted the eventual #value to Island A>
>
>   -> Delay wait ends.
>   -> message returns 4
> -> message completes
>
>        <Now, and *only* now the pending #value call will be executed>
>
> -> aBlock value starts
>    -> Attempts to [^3]
>    -> Raises BlockCannotReturn
>
>
> The result is 4. Each and every time.
>
> Cheers,
>   - Andreas
>
>