[etoys-dev] Step by Step debugging and Etoys

[Bert Freudenberg]

(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 ;)