Hi all,
Today I posted my twentieth Etoys tutorial in the Squeaky Tales series, bringing the total to five hours of ten planned.
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.
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
Timothy,
I'm just watching the tales #20. (I admit that I haven't watched all of them including #19, but...)
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.)
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".
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.
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.
This is great! I need to watch them all and see the problems encountered in real examples!
-- Yoshiki
I, of course, like these cute characters^^;
At Wed, 14 Nov 2007 00:28:57 -0500, Timothy Falconer wrote:
Hi all,
Today I posted my twentieth Etoys tutorial in the Squeaky Tales series, bringing the total to five hours of ten planned.
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.
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
Olpc-open mailing list Olpc-open@lists.laptop.org http://lists.laptop.org/listinfo/olpc-open
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".
On 15/11/2007, Timothy Falconer timothy@immuexa.com 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. :-)
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:
On 15/11/2007, Timothy Falconer timothy@immuexa.com 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. :-)
Timothy,
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.
Yes, basically, you have to think backward; first, build a tile looks like:
whateverHolder's cursor increase by 1
and then grab the variable tile from the viewer of tot11 and drop it on to "whateverHolder's". This is one of these nasty issues Etoys has.
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.
In the context with siblings, yes, it helps. I was listening it out of context, and I just thought that "it is not quite right". But it is ok.
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.
I missed it for the first glance. Yes, look like actually uses the original size; i.e., if you have:
A look like: B
and B was originally painted in big size but resized by the yellow handle, executing this line causes A look like big (original) B.
One other request ... a "wait" tile ... with seconds. Could go in "basic".
That is tricky. The Morphic system likes synchronized, co-operative objects in its world.
(A version of object system called Tweak has it, just to mention.)
Luke posted a solution but that looks, err, brute-force^^; A good practice would be to split such a script in which you would like to "wait", and call the second part from somewhere else. (I'm pretty sure that others have better ideas).
-- Yoshiki
P.S. I put Reply-To: field to omit olpc-open. The mailing list system might change it, but probably it is better not to post detailed discussions on Etoys to that list.
On 16/11/2007, Yoshiki Ohshima yoshiki@vpri.org wrote:
Luke posted a solution but that looks, err, brute-force^^;
It's the natural way that any Erlang programmer would write it. :-)
On Nov 16, 2007, at 5:28 , Luke Gorrie wrote:
On 16/11/2007, Yoshiki Ohshima yoshiki@vpri.org 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 -
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Luke Gorrie -
Scott Wallace -
Timothy Falconer -
Yoshiki Ohshima