squeaky tales and waveplace vision

Hi all,

Today I posted my twentieth Etoys tutorial in the Squeaky Tales  
series, bringing the total to five hours of ten planned.

http://waveplace.com/movies/

Each fifteen-minute screencast forms the basis for an hour of hands-
on instruction with a child, with the mentor first presenting the  
concepts in their own fashion, then leading the class for the  
remainder of the time. The videos themselves are aimed at the mentor,  
not the students, though I suspect older students could watch the  
videos on their own.

Now half done, I've been spending time on techniques to manage  
complexity. Just like a real software project, the beginning is fresh  
with clean white designs, but midway through it's a mangled mess of  
coalescing code.

I also posted a 25 minute video of me talking into a camera,  
explaining the Waveplace vision.

http://waveplace.com/vision/

I've had the same conversation about two hundred times in the last  
six months, so I figured it'd be good to get the rap down on tape.  
The video breaks down into ten minutes on education, five minutes on  
the XO, and ten minutes on Waveplace. Let me know if you find it  
helpful.

Timothy



_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

Yoshiki,

Thanks for your suggestions and kind comments.

At the end of #19, I actually say something like, "I've run into a  
roadblock, something I don't know, which is very common in  
programming.  The thing to do at this point is send an email asking  
for help on the squeakland mailing list."

Instead of doing this, though, I go on to show a short-term  
workaround .... the "right now" answer versus the "right" answer.  
Part of my point throughout is to show the real experience of  
programming, which definitely involves roadblocks and workarounds.  
I'm trying to convey a sense for what it's really like being a  
programmer using Etoys.


>   I might be missing what you're explaining around 7 minutes, but  
> you *can* put the variable "tot11's turnHolder into the place of  
> any player-type variable (such as the left hand side of "cursor  
> increase by 1".

What I couldn't figure out in #19 was "tot11's totHolder's cursor  
increase by 1"    I knew how, but "cursor" simply didn't appear on  
the list, I'm guessing because only Player stuff shows there.

>   Around 4:30 minutes into the movie, you say something like:
> "... unless there some good reasons..., you should always use the
> commands for the same object."  Is that because you are using siblings
> and have been bitten by the issue?  (I think so.)

Hmm... I think my point there was to train people to default to using  
the "self" receiver for each message .... if it's tot11's script, use  
tot11 as the receiver of everything unless you have a good reason not  
to, such as tot11 telling some other object what to do.  There are  
several commands that really don't require the exact right receiver,  
such as sibling sends and  "clear pen trails", etc.  I'm just making  
the point that people should train themselves to stay consistent.

>   I have no idea what causes the magnification issue.  So strange.  
> You have siblings and copies, right?  If so, yes, that could be  
> hard.  The last issue you have seems to be related to it.

Yes, the visual stuff in the holder were copies and the active  
players are siblings.  If the magnification is a by-product of  
siblings/dupes co-existing, it's a good thing to know.

>   Perhaps, I'd add a variable to these guys that holds a number,  
> and each of them compares the number with page5's timeTicks to  
> figure out what to do.  In this way, the script may be shorter.

Yeah, the stuff in the timeline script in the page could be farmed  
out to the objects on the page.  I choose the massive if-statement  
approach to make the sequencing clearer to newcomers.

I might move to a scratch-like event sending approach in the  
future .... marmie sends "settleDownClass" message to the tots and  
the tots respond to the message, rather than have it all be time  
driven.  Any hints on how I'd do asynchronous multi-recipient event  
passing like this?   (on "settledDownClass" do ...)

One other request  ... a "wait" tile ... with seconds.  Could go in  
"basic".



_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

On 15/11/2007, Timothy Falconer <[hidden email]> wrote:
> One other request  ... a "wait" tile ... with seconds.  Could go in
> "basic".

The screenshot shows how I'm doing that. First drag out a script, then
'show code textually', then write Smalltalk and hit Cmd-s.

World doOneCycle forces Morphic to update and then it won't happen
again during the delay period. I don't know how to do this differently
- fortunately this is just what I've needed. :-)

_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

On 16/11/2007, Yoshiki Ohshima <[hidden email]> wrote:
>   Luke posted a solution but that looks, err, brute-force^^;

It's the natural way that any Erlang programmer would write it. :-)

_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

The problem with this kind of "wait", and indeed the reason why such a  
"wait" tile is not offered in the Viewer already, is that it paralyzes  
the rest of Squeak, including the running of all other scripts, for  
the duration of the "wait".  Thus, it's usually not acceptable within  
a multi-player simulation.


On Nov 15, 2007, at 8:17 AM, Luke Gorrie wrote:

_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland

On Nov 16, 2007, at 5:28 , Luke Gorrie wrote:

> On 16/11/2007, Yoshiki Ohshima <[hidden email]> wrote:
>>   Luke posted a solution but that looks, err, brute-force^^;
>
> It's the natural way that any Erlang programmer would write it. :-)

Indeed, Etoys-II (the Tweak-based version) supports waiting exactly  
like that. I fact, it has a "wait" tile. But the architecture needed  
to change quite a lot for that.

We could retrofit something similar to the current Etoys (in fact,  
Yoshiki made an experimental scheduler that allows this) but it is  
too great a risk IMHO.

- Bert -



_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland