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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.