[etoys-dev] Step by Step debugging and Etoys

Ricardo Moran richi.moran at gmail.com
Sat Nov 12 15:33:29 EST 2011


I've added a simple "step over" button in the script editor. I attached a
project to demonstrate. For now, it's an ugly red circle because I don't
have a nice image, but it should work as expected.

Limitation: it doesn't work with the repeat tile yet. And it could probably
be coded more nicely.


On Fri, Nov 11, 2011 at 8:51 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> (removing the education-team list from CC because that always bounces for
> me as a non-member)
> On 11.11.2011, at 01:38, Steve Thomas wrote:
> > On Thu, Nov 10, 2011 at 7:04 PM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> >> You couldn't even press the "next step" button because the world would
> be literally stopped. And you wouldn't see what's going on since the world
> would not be repainted. That's what "stopping the world" means.
> > Ah, well that would be problematic :)  Thought it was similar to putting
> a self halt. in a script and stepping, which does repaint on forward and
> turn.
> Well, yes, I was kind-of overly dramatic to make my point. The thing is,
> to make this simple, the world would indeed have to be stopped as I wrote.
> As soon as we let the world continue to run, affairs get way less
> predictable. Using the debugger is a delicate affair, it works just fine
> most of the time, but you have to develop an intuition of how far you can
> take things there that will still work. And "most of the time" is not good
> enough for Etoys users.
> Besides, once we have the infrastructure in place to be able to highlight
> tiles in a script sequentially (as would be needed for single-stepping
> regardless of the underlying mechanism) then it is only a small step to
> actually "perform" the action of the current tile. And that's precisely our
> "second option", which avoids all the traps of process juggling trickery
> the regular debugger has to do (*)
> >> Yes, that is a solution we discussed, and think is optimal. The script
> would be "interpreted", each message "performed" individually, rather than
> executed as a compiled method.
> >>
> >> It's just ASMOP ;)
> > Funny, I have the same answer for developing a new web site, now if I
> could only find the time ;)
> >
> > Thanks,
> > Stephen
> Exactly. But I am very happy to see Scott exploring that direction :)
> - Bert -
> (*) It is somewhat mind-boggling to me how interrupting the UI process,
> doing a few single-steps, and then proceeding could possibly work. I can
> explain it, yes, how the current UI process gets paused, a new UI process
> spawned to run the debugger, then when proceeding the new one is killed and
> the old one resumed, but still. If that is not mind-boggling to you, you
> may not have understood the problem deeply enough yet. Or you have reached
> enlightenment already ;)
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20111112/a39b3ae0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StepOverExample.002.pr
Type: application/octet-stream
Size: 42376 bytes
Desc: not available
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20111112/a39b3ae0/attachment-0001.obj>

More information about the etoys-dev mailing list