Re: [etoys-dev] Step by Step debugging and Etoys
Ricardo Moran <[email protected]>
| Newsgroups | gmane.comp.lang.smalltalk.squeak.squeakland |
|---|---|
| Message-ID | <CALr=5n3cP+jcdvLTz_Js7GObjq+bzNgnf9GJEXXU=gbJKW8R3g@mail.gmail.com> |
Hi, 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. Cheers, Richo On Fri, Nov 11, 2011 at 8:51 AM, Bert Freudenberg <[email protected]>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 <[email protected]> > 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 > [email protected] > http://lists.squeakland.org/mailman/listinfo/etoys-dev > _______________________________________________ squeakland mailing list [email protected] http://lists.squeakland.org/mailman/listinfo/squeakland
StepOverExample.002.pr
(application/octet-stream, 41.4 KB) - not displayed