Hi all again :),
My students and me are working in a kind of basic pingus/lemmings clone[1] using eToys. We would like to use the mouse pointer to select a eToy and execute an script. The idea is to make click on a button, for example the one with the message "Detener al otro" ("Stop the other") and then select the eToy who would have this script enabled using the mouse.
We are also stuck on how to make copies on an eToy, so we work only on one, defining scripts, and animations and the we put the amount we want in the game. We know about the green halo button for copy, but we would like to use not graphically but from inside of a script. We have tried to use the message eToyName's copy but it can't be dragged on a script. The animations defined for the first eToy are not copied when we copy it.
Waiting for your quick and friendly answer as always,
Offray
Pdt: It seems that we're reaching some kind of stress point of the eToys. Would be nice to have the possibility to go from them to their code, but the scripts of the eToys seem to have only a code view, but is not usable for writing new code. I have bought the BotInc book from Steffane (it will be here in Colombia in a month :-/ ), as a path in that sense, but I'm wondering if eToys2/Tweak are the way to go from eToys to code for extending them and learn more about programming.
Hi --
First, how old are these children?
Cheers,
Alan
------------
At 02:39 PM 11/9/2006, Offray Vladimir Luna Cárdenas wrote:
Hi all again :),
My students and me are working in a kind of basic pingus/lemmings clone[1] using eToys. We would like to use the mouse pointer to select a eToy and execute an script. The idea is to make click on a button, for example the one with the message "Detener al otro" ("Stop the other") and then select the eToy who would have this script enabled using the mouse.
We are also stuck on how to make copies on an eToy, so we work only on one, defining scripts, and animations and the we put the amount we want in the game. We know about the green halo button for copy, but we would like to use not graphically but from inside of a script. We have tried to use the message eToyName's copy but it can't be dragged on a script. The animations defined for the first eToy are not copied when we copy it.
Waiting for your quick and friendly answer as always,
Offray
Pdt: It seems that we're reaching some kind of stress point of the eToys. Would be nice to have the possibility to go from them to their code, but the scripts of the eToys seem to have only a code view, but is not usable for writing new code. I have bought the BotInc book from Steffane (it will be here in Colombia in a month :-/ ), as a path in that sense, but I'm wondering if eToys2/Tweak are the way to go from eToys to code for extending them and learn more about programming.
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Hi Alan,
Thanks for your quick answer/question, but before, thanks for all your inspiring thoughts, words and works. I hope to meet you in person some day, soon. I have rethought computers, after knowing Squeak, the community and the ideas behind. It's like if some kind fundamental feeling about what needs to be the computers and languages in all the past time when I was using them was full filled in some sense... it's like coming to home, and, at the same time, coming to a place to start all new travels.
About the age, they're teenagers (16 - 17 years old), some of them never have programmed before.
Thanks again,
Offray
Alan Kay escribió:
Hi --
First, how old are these children?
Cheers,
Alan
At 02:39 PM 11/9/2006, Offray Vladimir Luna Cárdenas wrote:
Hi all again :),
My students and me are working in a kind of basic pingus/lemmings clone[1] using eToys. We would like to use the mouse pointer to select a eToy and execute an script. The idea is to make click on a button, for example the one with the message "Detener al otro" ("Stop the other") and then select the eToy who would have this script enabled using the mouse.
We are also stuck on how to make copies on an eToy, so we work only on one, defining scripts, and animations and the we put the amount we want in the game. We know about the green halo button for copy, but we would like to use not graphically but from inside of a script. We have tried to use the message eToyName's copy but it can't be dragged on a script. The animations defined for the first eToy are not copied when we copy it.
Waiting for your quick and friendly answer as always,
Offray
Pdt: It seems that we're reaching some kind of stress point of the eToys. Would be nice to have the possibility to go from them to their code, but the scripts of the eToys seem to have only a code view, but is not usable for writing new code. I have bought the BotInc book from Steffane (it will be here in Colombia in a month :-/ ), as a path in that sense, but I'm wondering if eToys2/Tweak are the way to go from eToys to code for extending them and learn more about programming.
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Hi, Offray,
We are also stuck on how to make copies on an eToy, so we work only on one, defining scripts, and animations and the we put the amount we want in the game. We know about the green halo button for copy, but we would like to use not graphically but from inside of a script. We have tried to use the message eToyName's copy but it can't be dragged on a script. The animations defined for the first eToy are not copied when we copy it.
When you execute "Car's copy", the result will be the creation of a copy of Car (strictly speaking a "sibling", viz. a fellow instance of the same class as Car.)
However, if you don't *place* that copy somewhere, you won't see it. The standard idiom for placing an object somewhere via script is to tell the *container* in which you place it to "include" it.
Here's a typical usage pattern:
------------------------------------------------------------------------ ------
Pdt: It seems that we're reaching some kind of stress point of the eToys. Would be nice to have the possibility to go from them to their code, but the scripts of the eToys seem to have only a code view, but is not usable for writing new code.
Hmm, well, etoy objects are first-class Smalltalk objects, and etoy scripts are real, first-class Smalltalk methods, belonging to real, first-class Smalltalk classes, and if you switch any script's Scriptor to textual mode (by clicking on the checkbox in the Scriptor's header,) you can enter any Smalltalk code you wish there.
A plausible practice is to use tile scripting for everything in a project that *can* be readily done using tile scripts, then to supplement this with conventional Smalltalk code in one or two places where necessary.
Textual coding can actually be done using two kinds of scripts:
First, as mentioned above, you can write textual code for any existing "etoy script" that you see in a Viewer by switching its Scriptor to textual mode via the checkbox.
Secondly [and this is not so well known] you can open a conventional Smalltalk browser on the class of an etoy "object", and using that Browser you can not only see and edit the etoy scripts, you can also add any other methods you wish, including methods with multiple arguments (whereas etoy scripts are limited to 0 or 1 argument,) mid- method returns, and many other things that you can't directly obtain using tiles alone. To get such a Browser, in the Viewer's menu choose "more..." and from the auxiliary menu that pops up, choose "browse class."
I'm not claiming that this is the ideal way to transition from e-toy tile-scripting to full-scale Smalltalk, if that's what your goal is -- indeed, it may lead to false expectations; I just wanted to make sure you're aware of the availability of these two ways of blending tile-scripting with writing unrestricted Smalltalk code. It would be interesting to hear of experiences people have had with this kind of hybrid approach.
Cheers,
-- Scott
Hey Scott!! :)
Thanks for your quick answer and sorry for my late response.
Scott Wallace escribió:
[...]
When you execute "Car's copy", the result will be the creation of a copy of Car (strictly speaking a "sibling", viz. a fellow instance of the same class as Car.)
However, if you don't *place* that copy somewhere, you won't see it. The standard idiom for placing an object somewhere via script is to tell the *container* in which you place it to "include" it.
Here's a typical usage pattern:
This works pretty good. I use the world as a container and now I have a lot of stars in the wold. At the beginning I thought it was not working because all starts were copied over the original one, but then I realized what was happening. There is still something I don't know how to do: how can I send a message to a particular copy. Suppose I have copied a Car and I have a script for the original one to make the car go forward and now I wan to make the recent copy to use that script. There is some natural number in each of the copies' names. Can I use it as a reference for the copies scripts to enable them?
Pdt: It seems that we're reaching some kind of stress point of the eToys. Would be nice to have the possibility to go from them to their code, but the scripts of the eToys seem to have only a code view, but is not usable for writing new code.
Hmm, well, etoy objects are first-class Smalltalk objects, and etoy scripts are real, first-class Smalltalk methods, belonging to real, first-class Smalltalk classes, and if you switch any script's Scriptor to textual mode (by clicking on the checkbox in the Scriptor's header,) you can enter any Smalltalk code you wish there.
[...]
Textual coding can actually be done using two kinds of scripts:
First, as mentioned above, you can write textual code for any existing "etoy script" that you see in a Viewer by switching its Scriptor to textual mode via the checkbox.
Thanks. I had not notice this possibility because when I go from tile to code mode in the scriptor and change a parameter (for example increase "self forward: 5" to 10) with the script ticking I see no change and I hope some similar behavior as I had seen in the tile mode, in which a change in the parameter has an instantaneous response in the behavior of the object in the script changed was ticking. Today I probed pressing [Alt] + [d] and I see the changes. There is still a problem I can't figure out a work around. When I come back from code mode to tile mode in the scriptor the script is exactly the same, none of the changes made in code mode are stored. May be the problem is related on how the script behaves in tile and code modes and the user expecting a more similar/coherent behavior, and not with the possibilities of the eToys system.
Secondly [and this is not so well known] you can open a conventional Smalltalk browser on the class of an etoy "object", and using that Browser you can not only see and edit the etoy scripts, you can also add any other methods you wish, including methods with multiple arguments (whereas etoy scripts are limited to 0 or 1 argument,) mid-method returns, and many other things that you can't directly obtain using tiles alone. To get such a Browser, in the Viewer's menu choose "more..." and from the auxiliary menu that pops up, choose "browse class."
On this point this is what I get:
browser class
There is a #guión1 (#script1) but I don't know how to change scripts code or add new scripts. Any pointer to the documentation?
A plausible practice is to use tile scripting for everything in a project that *can* be readily done using tile scripts, then to supplement this with conventional Smalltalk code in one or two places where necessary.
[...]
I'm not claiming that this is the ideal way to transition from e-toy tile-scripting to full-scale Smalltalk, if that's what your goal is -- indeed, it may lead to false expectations; I just wanted to make sure you're aware of the availability of these two ways of blending tile-scripting with writing unrestricted Smalltalk code. It would be interesting to hear of experiences people have had with this kind of hybrid approach.
Yep, the idea is some kind of transition from e-toy tile-scripting to Smalltalk (may be not full scale yet, but with the idea of that scale in some moment of the process). I have bought the book "Squeak: learning with robots" from Steffane, because of its pedagogical advantages providing the robots as a way to "see" the effect of code (loops, conditionals, etc.), but others will come to Squeak from eToys and Bookmorphs (for interactive educational material), so making a bridge between them and Smalltalk would be a nice path to follow. I will keep you informed on the process of this approach ... and bothered with the questions it raise ;-)
Cheers,
-- Scott
Cheers also from the country of the birds (well the second one). Anytime you want come, you must be aware: mi casa es tu casa (my home is your home),
Offray
Offray Vladimir Luna Cárdenas skrev:
Hey Scott!! :)
Thanks for your quick answer and sorry for my late response.
Scott Wallace escribió:
[...]
When you execute "Car's copy", the result will be the creation of a copy of Car (strictly speaking a "sibling", viz. a fellow instance of the same class as Car.)
However, if you don't *place* that copy somewhere, you won't see it. The standard idiom for placing an object somewhere via script is to tell the *container* in which you place it to "include" it.
Here's a typical usage pattern:
This works pretty good. I use the world as a container and now I have a lot of stars in the wold. At the beginning I thought it was not working because all starts were copied over the original one, but then I realized what was happening. There is still something I don't know how to do: how can I send a message to a particular copy. Suppose I have copied a Car and I have a script for the original one to make the car go forward and now I wan to make the recent copy to use that script. There is some natural number in each of the copies' names. Can I use it as a reference for the copies scripts to enable them?
You have to keep a reference to the player.Assign it to a variable.
Pdt: It seems that we're reaching some kind of stress point of the eToys. Would be nice to have the possibility to go from them to their code, but the scripts of the eToys seem to have only a code view, but is not usable for writing new code.
Hmm, well, etoy objects are first-class Smalltalk objects, and etoy scripts are real, first-class Smalltalk methods, belonging to real, first-class Smalltalk classes, and if you switch any script's Scriptor to textual mode (by clicking on the checkbox in the Scriptor's header,) you can enter any Smalltalk code you wish there.
[...]
Textual coding can actually be done using two kinds of scripts:
First, as mentioned above, you can write textual code for any existing "etoy script" that you see in a Viewer by switching its Scriptor to textual mode via the checkbox.
Thanks. I had not notice this possibility because when I go from tile to code mode in the scriptor and change a parameter (for example increase "self forward: 5" to 10) with the script ticking I see no change and I hope some similar behavior as I had seen in the tile mode, in which a change in the parameter has an instantaneous response in the behavior of the object in the script changed was ticking. Today I probed pressing [Alt] + [d] and I see the changes. There is still a problem I can't figure out a work around. When I come back from code mode to tile mode in the scriptor the script is exactly the same, none of the changes made in code mode are stored. May be the problem is related on how the script behaves in tile and code modes and the user expecting a more similar/coherent behavior, and not with the possibilities of the eToys system.
You can only go from tile to script, not the other way around. Hopefully some day it can be done.Karl
Secondly [and this is not so well known] you can open a conventional Smalltalk browser on the class of an etoy "object", and using that Browser you can not only see and edit the etoy scripts, you can also add any other methods you wish, including methods with multiple arguments (whereas etoy scripts are limited to 0 or 1 argument,) mid-method returns, and many other things that you can't directly obtain using tiles alone. To get such a Browser, in the Viewer's menu choose "more..." and from the auxiliary menu that pops up, choose "browse class."
On this point this is what I get:
browser class
There is a #guión1 (#script1) but I don't know how to change scripts code or add new scripts. Any pointer to the documentation?
A plausible practice is to use tile scripting for everything in a project that *can* be readily done using tile scripts, then to supplement this with conventional Smalltalk code in one or two places where necessary.
[...]
I'm not claiming that this is the ideal way to transition from e-toy tile-scripting to full-scale Smalltalk, if that's what your goal is -- indeed, it may lead to false expectations; I just wanted to make sure you're aware of the availability of these two ways of blending tile-scripting with writing unrestricted Smalltalk code. It would be interesting to hear of experiences people have had with this kind of hybrid approach.
Yep, the idea is some kind of transition from e-toy tile-scripting to Smalltalk (may be not full scale yet, but with the idea of that scale in some moment of the process). I have bought the book "Squeak: learning with robots" from Steffane, because of its pedagogical advantages providing the robots as a way to "see" the effect of code (loops, conditionals, etc.), but others will come to Squeak from eToys and Bookmorphs (for interactive educational material), so making a bridge between them and Smalltalk would be a nice path to follow. I will keep you informed on the process of this approach ... and bothered with the questions it raise ;-)
Cheers,
-- Scott
Cheers also from the country of the birds (well the second one). Anytime you want come, you must be aware: mi casa es tu casa (my home is your home),
Offray
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
karl
Hi Karl,
karl escribió:
[...]
There is some natural number in each of the copies' names. Can I use it as a reference for the copies scripts to enable them?
You have to keep a reference to the player.Assign it to a variable.
[...]
¿Can I use some kind of loop inside a script to automatize the way assign variables to copied objects?
You can only go from tile to script, not the other way around. Hopefully some day it can be done.Karl
¿How can I start to program using only the code mode of the scriptor, not the tile mode?, to get something similar to the chooseMessageTarget script from Scott?
Thanks a lot,
Offray
On Nov 13, 2006, at 8:21 AM, Offray Vladimir Luna Cárdenas wrote:
When you execute "Car's copy", the result will be the creation of a copy of Car (strictly speaking a "sibling", viz. a fellow instance of the same class as Car.)
However, if you don't *place* that copy somewhere, you won't see it. The standard idiom for placing an object somewhere via script is to tell the *container* in which you place it to "include" it.
Here's a typical usage pattern: ...
This works pretty good. I use the world as a container and now I have a lot of stars in the wold. At the beginning I thought it was not working because all starts were copied over the original one, but then I realized what was happening. There is still something I don't know how to do: how can I send a message to a particular copy. Suppose I have copied a Car and I have a script for the original one to make the car go forward and now I wan to make the recent copy to use that script. There is some natural number in each of the copies' names. Can I use it as a reference for the copies scripts to enable them?
The trick here is to assign the newborn to a "player-valued" variable belonging to the object that creates the newborn. That gives you a way to refer to the it. (To create a player-valued variable within an object, first hit the V button at the top of the viewer to add a variable; give it a name; then from its menu, choose "change value type" and from the pop-up of available types, choose Player.)
Thus, if the birthing script belongs to an object named "Foo", and that the script you want the newborn to run is called "zork".
Foo's newborn := Car's copy. "creates the newborn and stashes it in a variable belonging to Foo" World append: Foo's newborn. "add the newborn to the world" Foo's newborn zork. "have the newborn run its zork script"
There is an awkward and non-intuitive construction necessary to build "Foo's newborn zork". To do this right now, the usual way is to get a "Foo's zork" statement, and then grab a "Foo's newborn" tile from the "variables" section of Foo's viewer, and drop it on top of the "Foo's" in "Foos zork", thus making "Foos' newborn's zork". The meaning of this construct is" "Send the message #zork to the object referred to by the value in Foo's variable named 'newborn' ".
One common use for this approach, since newborns created with "copy" will typically pile up all in the same location, is to have the post- birth code move the newborn a small distance away from the donor, and perhaps make some further adjustments to the newborn to give it a good start in life. I attach a tiny project that illustrates this use. Every time you click on an object, it gives birth to a new object, which starts out life at the same location as its parent, but is given its own heading and a slightly increased speed.
Secondly [and this is not so well known] you can open a conventional Smalltalk browser on the class of an etoy "object", and using that Browser you can not only see and edit the etoy scripts, you can also add any other methods you wish, including methods with multiple arguments (whereas etoy scripts are limited to 0 or 1 argument,) mid-method returns, and many other things that you can't directly obtain using tiles alone. To get such a Browser, in the Viewer's menu choose "more..." and from the auxiliary menu that pops up, choose "browse class."
On this point this is what I get:
browser class
There is a #guión1 (#script1) but I don't know how to change scripts code or add new scripts. Any pointer to the documentation?
Ah, well, this is a standard Smalltalk "class browser". To get involved earnestly at this level, one is going to need to learn how to use the tools of the Smalltalk IDE such as the Browser. Once you start adding new methods to an object in this way, you are basically dropping through a trap door into a fabulous, boundless, but much less sheltered, world. A
There is presently no documentation I know of that is specifically aimed at etoy users which covers things like the Smalltalk browser. So I would again refer you to some of the excellent, free Smalltalk books available online.
However, here are a few hints to get started working in a Smalltalk browser opened by an object's Viewer as we've been discussing, if you want to try to feel your way through:
(1) To change the code of a script, such as your #guión1, click on its name in the upper-right-pane of the browser. This will showing you the existing code of the script, in textual form, whether or not the script is currently officially designated as textually-coded. Then you text-edit the code in the usual way, and then to *submit* the code you type alt-s.
(2) To add a new method that is visible within the tile-scripting world, first choose the "selector" (method name) you want to use, then add an etoy script and give it that name. If it is to have a parameter, add it. You can subsequently textually edit the code either in the Scriptor (after you've switched the Scriptor from tiles to text) or in a full textual Smalltalk Browser.
(3) To add a new method which will operate outside the ken of the tile-scripting world (e.g. you won't see it in a Viewer): this one needs to be done using the Browser. Get a Browser for your object ("browse class" from its Viewer's more... menu), click on == all --", then, in the code pane which will now show a method template whose first line says "message selector and argument names, select all the text and hit backspace, to clear out the area, then type the new script, starting with the selector and formal arguments, then the temps, then the body of the method -- use the patterns you see when browsing the code of other objects in the system to see how these work.
Why would one want to write scripts for an object which operate completely outside the etoy framework? For one thing, etoy scripts can have at most one argument, and their arguments normally need to conform to one of the formal etoy types.
Cheers also from the country of the birds (well the second one). Anytime you want come, you must be aware: mi casa es tu casa (my home is your home),
Thank you ! I'm going to take you up on that offer one of these days ;-)
Cheers,
-- Scott
On Mon, 13 Nov 2006, Offray Vladimir Luna Cárdenas wrote:
I'm not claiming that this is the ideal way to transition from e-toy tile-scripting to full-scale Smalltalk, if that's what your goal is -- indeed, it may lead to false expectations; I just wanted to make sure you're aware of the availability of these two ways of blending tile-scripting with writing unrestricted Smalltalk code. It would be interesting to hear of experiences people have had with this kind of hybrid approach.
Yep, the idea is some kind of transition from e-toy tile-scripting to Smalltalk (may be not full scale yet, but with the idea of that scale in some moment of the process). I have bought the book "Squeak: learning with robots" from Steffane, because of its pedagogical advantages providing the robots as a way to "see" the effect of code (loops, conditionals, etc.), but others will come to Squeak from eToys and Bookmorphs (for interactive educational material), so making a bridge between them and Smalltalk would be a nice path to follow. I will keep you informed on the process of this approach ... and bothered with the questions it raise ;-)
Hi Offray,
At the moment I'm following a similar approach with a class of 11th-graders - starting with eToys and trying to find a way down to smalltalk. I'm learning quite a lot from your questions, thx.
Markus ----------------------------------------------- Markus Schlager m.slg(at)gmx.de
Hi, again, Offray,
My students and me are working in a kind of basic pingus/lemmings clone[1] using eToys. We would like to use the mouse pointer to select a eToy and execute an script. The idea is to make click on a button, for example the one with the message "Detener al otro" ("Stop the other") and then select the eToy who would have this script enabled using the mouse.
Perhaps you'll find the techniques illustrated in the attached project useful for your purposes.
In the project, all the star-lemmings (which are all siblings of one another) understand the messages "makeRed", "makeBlue", "startSpinning", and "stopSpinning", etc.
When you click on any of the buttons at the bottom, the cursor changes into a cross-hair, inviting you to choose a recipient for the button's message. After you click on one of the star-lemmings, the designated message will be sent to the one you chose.
Thus, click on "One Red", and when the cursor changes to a cross- hair, click on a blue star-lemming, and it will be told to run its script named "makeRed", which in turn will make it red. And so on for all four of the "One" buttons.
The four buttons with "Others" in their names tell all of the designated recipient's *siblings* to do the button's action, with the result tht every lemming *except* the one you click on gets the indicated message. So the "One" buttons and the "Others" buttons are kind of opposites of each other.
Invoking the "cursor mode" for selecting the target is outside the scope of etoy tiles, so this required a single tiny textual script, named "chooseMessageTarget", which I wrote for the "world". All the other code in the project is strictly tile scripts.
How close is this to what you're seeking?
Cheers,
-- Scott
Hi Scott :),
Thanks for your help again. What you're providing me is pretty close to what me and my students are looking for. Because my lack of knowledge of the Smalltalk code I'm trying to understand the textual script. I see that in that script, there is not switch from tile mode to code/text mode, only the last one is enabled. There is some special way to add this scripts? If I try, for example to use the visor of a Star I always can switch from tile to code modes, but coming back to tile, always makes the changes in text mode to get loosed (not saved).
Here is your script:
Script Editor
and here is my "literate" explanation (probably is wrong):
----
chooseMessageTarget "the name of the script"
"Choose a player as target for a message" "<- comment with the explanation" | aMorph | "<- some kind of local variable" aMorph := self costume chooseClickTarget. "<- this part changes the mouse pointer of the world from arrow to cross-hair"
"The following part gives a message to self to set message target, if a not nil morph is chosen then the selected morph is assigned to aMorph variable, if is Nil, I'm not pretty sure what's happening"
self setMessageTarget: (aMorph ifNil: [ActiveWorld presenter standardPlayer] ifNotNil: [aMorph assuredPlayer])
-----
I'm seeing that the world is "holding its breath" until a morph is chosen, and everything stops for a while until the target of the message has been choose. I image that this is related with the code "ifNil: [ActiveWorld presenter standardPlayer] ...". There is a way to keep the objects in the world moving, even with the message target still to be selected?
Cheers,
Offray
Scott Wallace escribió:
Hi, again, Offray,
My students and me are working in a kind of basic pingus/lemmings clone[1] using eToys. We would like to use the mouse pointer to select a eToy and execute an script. The idea is to make click on a button, for example the one with the message "Detener al otro" ("Stop the other") and then select the eToy who would have this script enabled using the mouse.
Perhaps you'll find the techniques illustrated in the attached project useful for your purposes.
In the project, all the star-lemmings (which are all siblings of one another) understand the messages "makeRed", "makeBlue", "startSpinning", and "stopSpinning", etc.
When you click on any of the buttons at the bottom, the cursor changes into a cross-hair, inviting you to choose a recipient for the button's message. After you click on one of the star-lemmings, the designated message will be sent to the one you chose.
Thus, click on "One Red", and when the cursor changes to a cross-hair, click on a blue star-lemming, and it will be told to run its script named "makeRed", which in turn will make it red. And so on for all four of the "One" buttons.
The four buttons with "Others" in their names tell all of the designated recipient's *siblings* to do the button's action, with the result tht every lemming *except* the one you click on gets the indicated message. So the "One" buttons and the "Others" buttons are kind of opposites of each other.
Invoking the "cursor mode" for selecting the target is outside the scope of etoy tiles, so this required a single tiny textual script, named "chooseMessageTarget", which I wrote for the "world". All the other code in the project is strictly tile scripts.
How close is this to what you're seeking?
Cheers,
-- Scott
On Nov 13, 2006, at 10:18 AM, Offray Vladimir Luna Cárdenas wrote:
Hi Scott :),
Thanks for your help again. What you're providing me is pretty close to what me and my students are looking for. Because my lack of knowledge of the Smalltalk code I'm trying to understand the textual script. I see that in that script, there is not switch from tile mode to code/text mode, only the last one is enabled. There is some special way to add this scripts? If I try, for example to use the visor of a Star I always can switch from tile to code modes, but coming back to tile, always makes the changes in text mode to get loosed (not saved).
Hi, Offray!
Once you have typed in textual code for a script, you cannot return to tile mode without losing the textual code you typed. There is no automatic translation from user-entered textual code back into etoy tiles. Indeed, the constructs supported by etoy tiles represent but a tiny fraction of what can be expressed in textual Smalltalk code.
Some people are quite disappointed, and even offended, when they first learn this brutal fact. But "etoys" is a tile-scripting system, with severe and intentional limits to vocabulary, sentence structure, expression structure, and control structures. The textual- scripting alternative provides nothing more than a "keyhole" which allows some people to "escape" from tiles, into textual Smalltalk programming, specifically to program things that cannot be expressed with tiles.
Because reverting from a textually-entered script back to tiles is destructive, the user is presented with a warning if he tries to do it -- a stern warning that any code he has manually entered via the keyboard for this script will be lost.
The reason why this warning was not presented when you tried to click the text/tiles checkbox of the #chooseMessageTarget script to revert to tiles is because of a bug that appears when you attempt to toggle a textually-coded script which has never had any non-empty tile code. (I have a fix for that bug, which I'm about to publish to the Squeakland alpha update stream.)
However, even if had been allowed, you would not have wanted to revert that script to its last-known tile form, because in so doing you would have lost the textual code which is the whole point of the script.
chooseMessageTarget "the name of the script"
"Choose a player as target for a message" "<- comment with the explanation" | aMorph | "<- some kind of local variable" aMorph := self costume chooseClickTarget. "<- this part changes the mouse pointer of the world from arrow to cross-hair"
"The following part gives a message to self to set message target, if a not nil morph is chosen then the selected morph is assigned to aMorph variable, if is Nil, I'm not pretty sure what's happening"
self setMessageTarget: (aMorph ifNil: [ActiveWorld presenter standardPlayer] ifNotNil: [aMorph assuredPlayer])
I'm seeing that the world is "holding its breath" until a morph is chosen, and everything stops for a while until the target of the message has been choose. I image that this is related with the code "ifNil: [ActiveWorld presenter standardPlayer] ...". There is a way to keep the objects in the world moving, even with the message target still to be selected?
Actually, it's the "chooseClickTarget" which does all the work, and which causes the system to "hold its breath".
This breath-holding is not absolutely necessary, it's just that that's how the underlying support for morph-picking has always worked in Squeak -- i.e. totally modally.
To explore the possibility of relaxing this limitation, I've made a suggested fix and included it in the attached revised version #5 of the StarLemmings project; in this version, things will continue to breathe during target selection. Please try it out and let me know what you think.
Cheers,
-- Scott
PS: Just as an aside, I think that perhaps better than trying to learn Smalltalk by puzzling over little oddball textual snippets such as the one I provided for this project would be to download some of the great and free Smalltalk books (including a nice one in Spanish by Diego) from Stephane Ducasse's wonderful web site, which you probably already know about:
http://www.iam.unibe.ch/~ducasse/FreeBooks.html
ATTACHED: StarLemmings.5.pr, revised version of the StarLemmings project which allows breathing during morph-picking.
Hi Offray --
Etoys was designed for 9-11 year olds, and it has worked very well with them. However, even 8th graders are able to use more features, and high schoolers should be using a pretty complete programming environment (like Squeak).
You are not the only one to want to do more with Etoys, and I think this is because the basic notion of Etoys' universal objects, easy scripting and multitasking are things every programming environment needs. In "a year or so" we will have something more like a full spectrum system that can be used by a much wider range of users.
Squeak itself is very easy -- as Tony Hoare once said about Algol, Smalltalk was a great improvement, especially with its successors! -- the problem for beginners is that the library has only one organization, which kind of lumps everything together, and this is a large lump. This is powerful but can be quite frustrating (other comprehensive systems have similar problems). Etoys is kind of a demo that quite a bit can be done with much much less in the end-user's world, but the aim at 10 year olds limits its range. Our original plan was to wind up with a more Hypercard-like system, still small and simple, but much more comprehensive.
But, since Squeak is "live" and includes all of its parts and tools written in itself, much can be done with the existing system. For example, it is quite possible to make up an end user view of a system by making a special code browser for it that would only show the relevant useful classes. Morphic itself was designed to be quite simple and to allow quick naive presentations driven by Squeak methods. Etc. E.g. instead of trying to make the tile scripting system do things it wasn't designed to do, you might look at how morphs and players could be programmed in the Squeak code browser, etc.
This would produce a system with a simple and easy to learn syntax, huge expressive power, and a number of useful graphics classes to do things with on the screen. Not the very best thing that could be done for high schoolers, but would still allow a lot to be learned without huge expeditions into the library.
Cheers,
Alan
At 04:52 AM 11/14/2006, Scott Wallace wrote:
On Nov 13, 2006, at 10:18 AM, Offray Vladimir Luna Cárdenas wrote:
Hi Scott :),
Thanks for your help again. What you're providing me is pretty close to what me and my students are looking for. Because my lack of knowledge of the Smalltalk code I'm trying to understand the textual script. I see that in that script, there is not switch from tile mode to code/text mode, only the last one is enabled. There is some special way to add this scripts? If I try, for example to use the visor of a Star I always can switch from tile to code modes, but coming back to tile, always makes the changes in text mode to get loosed (not saved).
Hi, Offray!
Once you have typed in textual code for a script, you cannot return to tile mode without losing the textual code you typed. There is no automatic translation from user-entered textual code back into etoy tiles. Indeed, the constructs supported by etoy tiles represent but a tiny fraction of what can be expressed in textual Smalltalk code.
Some people are quite disappointed, and even offended, when they first learn this brutal fact. But "etoys" is a tile-scripting system, with severe and intentional limits to vocabulary, sentence structure, expression structure, and control structures. The textual- scripting alternative provides nothing more than a "keyhole" which allows some people to "escape" from tiles, into textual Smalltalk programming, specifically to program things that cannot be expressed with tiles.
Because reverting from a textually-entered script back to tiles is destructive, the user is presented with a warning if he tries to do it -- a stern warning that any code he has manually entered via the keyboard for this script will be lost.
The reason why this warning was not presented when you tried to click the text/tiles checkbox of the #chooseMessageTarget script to revert to tiles is because of a bug that appears when you attempt to toggle a textually-coded script which has never had any non-empty tile code. (I have a fix for that bug, which I'm about to publish to the Squeakland alpha update stream.)
However, even if had been allowed, you would not have wanted to revert that script to its last-known tile form, because in so doing you would have lost the textual code which is the whole point of the script.
chooseMessageTarget "the name of the script"
"Choose a player as target for a message" "<- comment with the explanation" | aMorph | "<- some kind of local variable" aMorph := self costume chooseClickTarget. "<- this part changes the mouse pointer of the world from arrow to cross-hair"
"The following part gives a message to self to set message target, if a not nil morph is chosen then the selected morph is assigned to aMorph variable, if is Nil, I'm not pretty sure what's happening"
self setMessageTarget: (aMorph ifNil: [ActiveWorld presenter standardPlayer] ifNotNil: [aMorph assuredPlayer])
I'm seeing that the world is "holding its breath" until a morph is chosen, and everything stops for a while until the target of the message has been choose. I image that this is related with the code "ifNil: [ActiveWorld presenter standardPlayer] ...". There is a way to keep the objects in the world moving, even with the message target still to be selected?
Actually, it's the "chooseClickTarget" which does all the work, and which causes the system to "hold its breath".
This breath-holding is not absolutely necessary, it's just that that's how the underlying support for morph-picking has always worked in Squeak -- i.e. totally modally.
To explore the possibility of relaxing this limitation, I've made a suggested fix and included it in the attached revised version #5 of the StarLemmings project; in this version, things will continue to breathe during target selection. Please try it out and let me know what you think.
Cheers,
-- Scott
PS: Just as an aside, I think that perhaps better than trying to learn Smalltalk by puzzling over little oddball textual snippets such as the one I provided for this project would be to download some of the great and free Smalltalk books (including a nice one in Spanish by Diego) from Stephane Ducasse's wonderful web site, which you probably already know about:
http://www.iam.unibe.ch/~ducasse/FreeBooks.html
ATTACHED: StarLemmings.5.pr, revised version of the StarLemmings project which allows breathing during morph-picking.
Content-Id: 96EF1165-24D5-4726-9589-310502925AD6@local Content-Type: application/octet-stream; x-mac-type=534F424A; x-unix-mode=0644; x-mac-creator=46415354; name=Star Lemmings.005.pr Content-Disposition: attachment; filename="Star Lemmings.005.pr"
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
On 2006 November 14 10:41, Alan Kay wrote:
Hi Offray --
...
In "a year or so" we will have something more like a full spectrum system that can be used by a much wider range of users.
Hi Alan,
I could not resist - is this planned to be a new version eToys, or more of an extension, and, is it planned to be of the current OLPC/Squeakland Morphic based lineage or rather the Tweak eToys lineage? Or perhaps it's not defined yet,
Thanks Milan
Squeak itself is very easy -- as Tony Hoare once said about Algol, Smalltalk was a great improvement, especially with its successors! -- the problem for beginners is that the library has only one organization, which kind of lumps everything together, and this is a large lump. This is powerful but can be quite frustrating (other comprehensive systems have similar problems). Etoys is kind of a demo that quite a bit can be done with much much less in the end-user's world, but the aim at 10 year olds limits its range. Our original plan was to wind up with a more Hypercard-like system, still small and simple, but much more comprehensive.
But, since Squeak is "live" and includes all of its parts and tools written in itself, much can be done with the existing system. For example, it is quite possible to make up an end user view of a system by making a special code browser for it that would only show the relevant useful classes. Morphic itself was designed to be quite simple and to allow quick naive presentations driven by Squeak methods. Etc. E.g. instead of trying to make the tile scripting system do things it wasn't designed to do, you might look at how morphs and players could be programmed in the Squeak code browser, etc.
This would produce a system with a simple and easy to learn syntax, huge expressive power, and a number of useful graphics classes to do things with on the screen. Not the very best thing that could be done for high schoolers, but would still allow a lot to be learned without huge expeditions into the library.
Cheers,
Alan
At 04:52 AM 11/14/2006, Scott Wallace wrote:
On Nov 13, 2006, at 10:18 AM, Offray Vladimir Luna Cárdenas wrote:
Hi Scott :),
Thanks for your help again. What you're providing me is pretty close to what me and my students are looking for. Because my lack of knowledge of the Smalltalk code I'm trying to understand the textual script. I see that in that script, there is not switch from tile mode to code/text mode, only the last one is enabled. There is some special way to add this scripts? If I try, for example to use the visor of a Star I always can switch from tile to code modes, but coming back to tile, always makes the changes in text mode to get loosed (not saved).
Hi, Offray!
Once you have typed in textual code for a script, you cannot return to tile mode without losing the textual code you typed. There is no automatic translation from user-entered textual code back into etoy tiles. Indeed, the constructs supported by etoy tiles represent but a tiny fraction of what can be expressed in textual Smalltalk code.
Some people are quite disappointed, and even offended, when they first learn this brutal fact. But "etoys" is a tile-scripting system, with severe and intentional limits to vocabulary, sentence structure, expression structure, and control structures. The textual- scripting alternative provides nothing more than a "keyhole" which allows some people to "escape" from tiles, into textual Smalltalk programming, specifically to program things that cannot be expressed with tiles.
Because reverting from a textually-entered script back to tiles is destructive, the user is presented with a warning if he tries to do it -- a stern warning that any code he has manually entered via the keyboard for this script will be lost.
The reason why this warning was not presented when you tried to click the text/tiles checkbox of the #chooseMessageTarget script to revert to tiles is because of a bug that appears when you attempt to toggle a textually-coded script which has never had any non-empty tile code. (I have a fix for that bug, which I'm about to publish to the Squeakland alpha update stream.)
However, even if had been allowed, you would not have wanted to revert that script to its last-known tile form, because in so doing you would have lost the textual code which is the whole point of the script.
chooseMessageTarget "the name of the script"
"Choose a player as target for a message" "<- comment with the explanation"
| aMorph | "<- some kind of local variable"
aMorph := self costume chooseClickTarget. "<- this part changes the mouse pointer of the world from arrow to cross-hair"
"The following part gives a message to self to set message target, if a not nil morph is chosen then the selected morph is assigned to aMorph variable, if is Nil, I'm not pretty sure what's happening"
self setMessageTarget: (aMorph ifNil: [ActiveWorld presenter standardPlayer] ifNotNil: [aMorph assuredPlayer])
I'm seeing that the world is "holding its breath" until a morph is chosen, and everything stops for a while until the target of the message has been choose. I image that this is related with the code "ifNil: [ActiveWorld presenter standardPlayer] ...". There is a way to keep the objects in the world moving, even with the message target still to be selected?
Actually, it's the "chooseClickTarget" which does all the work, and which causes the system to "hold its breath".
This breath-holding is not absolutely necessary, it's just that that's how the underlying support for morph-picking has always worked in Squeak -- i.e. totally modally.
To explore the possibility of relaxing this limitation, I've made a suggested fix and included it in the attached revised version #5 of the StarLemmings project; in this version, things will continue to breathe during target selection. Please try it out and let me know what you think.
Cheers,
-- Scott
PS: Just as an aside, I think that perhaps better than trying to learn Smalltalk by puzzling over little oddball textual snippets such as the one I provided for this project would be to download some of the great and free Smalltalk books (including a nice one in Spanish by Diego) from Stephane Ducasse's wonderful web site, which you probably already know about:
http://www.iam.unibe.ch/~ducasse/FreeBooks.html
ATTACHED: StarLemmings.5.pr, revised version of the StarLemmings project which allows breathing during morph-picking.
Content-Id: 96EF1165-24D5-4726-9589-310502925AD6@local Content-Type: application/octet-stream; x-mac-type=534F424A; x-unix-mode=0644; x-mac-creator=46415354; name=Star Lemmings.005.pr Content-Disposition: attachment; filename="Star Lemmings.005.pr"
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Hi Scott :),
Scott Wallace escribió:
[...]
Hi, Offray!
Once you have typed in textual code for a script, you cannot return to tile mode without losing the textual code you typed. There is no automatic translation from user-entered textual code back into etoy tiles. Indeed, the constructs supported by etoy tiles represent but a tiny fraction of what can be expressed in textual Smalltalk code.
Some people are quite disappointed, and even offended, when they first learn this brutal fact. But "etoys" is a tile-scripting system, with severe and intentional limits to vocabulary, sentence structure, expression structure, and control structures. The textual-scripting alternative provides nothing more than a "keyhole" which allows some people to "escape" from tiles, into textual Smalltalk programming, specifically to program things that cannot be expressed with tiles.
Well... its a shame for that people. I'm quite happy with Squeak as a whole (including this community). Knowing Squeak is some kind of life changing experience and I can understand the limitations of eToys for the sake of the learning process of its primary users. Me and my class have enjoyed a lot the eToys system... and now we're going to textual scripting with happiness :).
Because reverting from a textually-entered script back to tiles is destructive, the user is presented with a warning if he tries to do it -- a stern warning that any code he has manually entered via the keyboard for this script will be lost.
The reason why this warning was not presented when you tried to click the text/tiles checkbox of the #chooseMessageTarget script to revert to tiles is because of a bug that appears when you attempt to toggle a textually-coded script which has never had any non-empty tile code. (I have a fix for that bug, which I'm about to publish to the Squeakland alpha update stream.)
¿So, you created #chooseMessageTarget script without using the visor of the world?. I see that trying to drag & drop to create a script from any object's visor gives me and script where I can switch from tiles to text (destructively) but I can't save the code wrote in text mode. I will try to see how can I made the same from the recommended bibliography.
[...]
Actually, it's the "chooseClickTarget" which does all the work, and which causes the system to "hold its breath".
This breath-holding is not absolutely necessary, it's just that that's how the underlying support for morph-picking has always worked in Squeak -- i.e. totally modally.
To explore the possibility of relaxing this limitation, I've made a suggested fix and included it in the attached revised version #5 of the StarLemmings project; in this version, things will continue to breathe during target selection. Please try it out and let me know what you think.
¿So, you have (re)implemented chooseClickTarget?. I really need to learn how to do these things. I will try to browse the docs and FreeBooks you suggested trying to search the way. The new StarLemming5 its working like a charm. I will say to my students to reimplement, copy the object from their project to yours, so we can use the code you provide us for our lemmings clone :-).
PS: Just as an aside, I think that perhaps better than trying to learn Smalltalk by puzzling over little oddball textual snippets such as the one I provided for this project would be to download some of the great and free Smalltalk books (including a nice one in Spanish by Diego) from Stephane Ducasse's wonderful web site, which you probably already know about:
I have tried those approaches before in the context of the course I talked in SqueakFest2006 (even consider using the Diego book), but it seems to me that is not enough continuity of experience from the perspective of a first approach to programming using eToys and tile based scripting and the approach suggested by the Books. While eToys are a good catch for people not familiar with programming in ages from 6 to 100, these books, despite of its excellence and good quality, are too programmer oriented. It seems that Learning to program with Robots from Stéphane is a good starting point and bridge in that sense. I have ordered it via amazon and it will be in a religious holy day here called "the days of little candles". It's some kind of advance of a Christmas gift from me to myself ;-). In some metaphoric sense it will be here just in time to bring some light about teaching Squeak to teenagers in a fun fashion, as eToys do, but with more extensibility as Smalltalk do. But your enlightenment and the one of this community has been a valuable resource and I hope to count with it in the future and share the light here also. Thanks, as always.
Cheers,
Offray
Pdt: Would be really nice to have something like "Ligth and Matter" [1] free books for Squeak (in the sense of freedom, not price). I hope to make some contributions in that sense next semester, from my novice perspective.
[1] http://www.lightandmatter.com/ [2] http://www.lightandmatter.com/area1why.html [3] http://www.lightandmatter.com/article/sneaky.html
Offray Vladimir Luna Cárdenas skrev:
Pdt: Would be really nice to have something like "Ligth and Matter" [1] free books for Squeak (in the sense of freedom, not price). I hope to make some contributions in that sense next semester, from my novice perspective.
[1] http://www.lightandmatter.com/ [2] http://www.lightandmatter.com/area1why.html [3] http://www.lightandmatter.com/article/sneaky.html
Thank you for this link. Very cool.
Squeak has a documentation team that you can reach here: http://minnow.cc.gatech.edu/squeak/808 The whole Squeak wiki has a lots of info, but it's quite messy and much is out of date. Karl
Hi Karl,
karl escribió:
Offray Vladimir Luna Cárdenas skrev:
Pdt: Would be really nice to have something like "Ligth and Matter" [1] free books for Squeak (in the sense of freedom, not price). I hope to make some contributions in that sense next semester, from my novice perspective.
[1] http://www.lightandmatter.com/ [2] http://www.lightandmatter.com/area1why.html [3] http://www.lightandmatter.com/article/sneaky.html
Thank you for this link. Very cool.
No problem Karl: "Quid pro Quo" ;-). I have readed your post with a lot of cool things also.
Squeak has a documentation team that you can reach here: http://minnow.cc.gatech.edu/squeak/808 The whole Squeak wiki has a lots of info, but it's quite messy and much is out of date. Karl
Yep. We're trying to produce some kind of Yellow Pages Wiki for Squeak with links to documentation and original documentation in Spanish[1][2]. Trying to conform a strong community with continuous participation and documentation practices is a big challenge and I think that is the major cause of messy and outdating even in Spanish documentation. Having a Free as in freedom, not in price, Squeak book would help a lot in this concern.
[1] www.el-directorio.org/Squeak [2] www.el-directorio.org/Squeakers
Cheers,
Offray
Ps: ¿Its fine to send messages to the list where you are suscribed and to you also? (I generally made this if the people is not responding messages to the list or I want to emphasize the question, but may be here the usual is the other thing).
On Wed, Nov 15, 2006 at 04:23:32PM -0500, Offray Vladimir Luna C?rdenas wrote:
Yep. We're trying to produce some kind of Yellow Pages Wiki for Squeak with links to documentation and original documentation in Spanish[1][2]. Trying to conform a strong community with continuous participation and documentation practices is a big challenge and I think that is the major cause of messy and outdating even in Spanish documentation. Having a Free as in freedom, not in price, Squeak book would help a lot in this concern.
You may want to use the tutorials written by Edgar J. De Cleene: http://ar.geocities.com/edgardec2001/TOC.html
Hi!, there is also another free book (licene creative commons) entitled "Programando con Smalltalk" (http://smalltalk.consultar.com/), in spanish for newcomers. You can download it in PDF format.
Cheers, Christian
Matthew Fulmer tapplek@gmail.com schrieb: On Wed, Nov 15, 2006 at 04:23:32PM -0500, Offray Vladimir Luna C?rdenas wrote:
Yep. We're trying to produce some kind of Yellow Pages Wiki for Squeak with links to documentation and original documentation in Spanish[1][2]. Trying to conform a strong community with continuous participation and documentation practices is a big challenge and I think that is the major cause of messy and outdating even in Spanish documentation. Having a Free as in freedom, not in price, Squeak book would help a lot in this concern.
You may want to use the tutorials written by Edgar J. De Cleene: http://ar.geocities.com/edgardec2001/TOC.html
On Nov 14, 2006, at 1:08 PM, Offray Vladimir Luna Cárdenas wrote:
¿So, you created #chooseMessageTarget script without using the visor of the world?. I see that trying to drag & drop to create a script from any object's visor gives me and script where I can switch from tiles to text (destructively) but I can't save the code wrote in text mode. I will try to see how can I made the same from the recommended bibliography.
Hi, Offray!
I *did* create that script from a Viewer, dragging an "empty script" tile from the viewer and dropping it on the desktop, then clicking the checkbox in the resulting Scriptor's header to switch to textual mode. The reason you can't (destructively) switch that script back to tile mode (which would a script with no tiles) is because of the bug I mentioned yesterday.
¿So, you have (re)implemented chooseClickTarget?. I really need to learn how to do these things. I will try to browse the docs and FreeBooks you suggested trying to search the way. The new StarLemming5 its working like a charm. I will say to my students to reimplement, copy the object from their project to yours, so we can use the code you provide us for our lemmings clone :-).
Yes, I made a "system" code change to #chooseClickTarget, in order to allow scripts to tick while in the target-choosing cursor mode, and I embedded that change in the project I sent you. Pending further discussion and testing, that system change will get published to the Squeakland update stream, so that all users will be able to benefit from it.
BTW I attach a slightly improved version of the prospective code change, which you could have your students file in when needed.

Pdt: Would be really nice to have something like "Ligth and Matter" [1] free books for Squeak (in the sense of freedom, not price). I hope to make some contributions in that sense next semester, from my novice perspective.
[1] http://www.lightandmatter.com/ [2] http://www.lightandmatter.com/area1why.html [3] http://www.lightandmatter.com/article/sneaky.html
Very cool site, thank you!
Cheers,
-- Scott
squeakland@lists.squeakfoundation.org