[squeakland] [etoys-dev] Step by Step debugging and Etoys

[Steve Thomas]

Go Richo, Go Richo, Go Richo :)


On Sat, Nov 12, 2011 at 3:33 PM, Ricardo Moran <richi.moran at gmail.com>wrote:

> 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 <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
>>
>
>
> _______________________________________________
> 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/squeakland/attachments/20111112/3e86eb7c/attachment.html>