Allow user to use Debugger on Scripts [FIXED]

Request a new command, feature, or improvement

Moderator: MSandro

Post Reply
MrSteve
Posts: 61
Joined: Jun 16th, '16, 01:22

Allow user to use Debugger on Scripts [FIXED]

Post by MrSteve » Jul 5th, '16, 03:16

So when getting an exception that caused the debugger to open up, I started to play around and explore and this is a really nice feature that helped me better understand some of the internals of GP.
For now I can simply add the following block to cause an exception so I can step through my scripts:
Screen Shot 2016-07-04 at 10.53.23 PM.png
Screen Shot 2016-07-04 at 10.53.23 PM.png (9.86 KiB) Viewed 8218 times
I will use this to play around with it for now.

PS
I had made numerous attempts to try and understand the internals of Etoys and how it was implemented, but always ran into mental blocks. Perhaps its because I can now learn via block code. I think the syntax of Smalltalk threw me 1 + 2 * 3 = 9? too much cognitive dissonance and too much to unlearn perhaps. In any case I am finding it easier to explore and gain some understanding using the class browser in GP

Cheers

MrSteve
Posts: 61
Joined: Jun 16th, '16, 01:22

Re: Allow user to use Debugger on Scripts

Post by MrSteve » Jul 12th, '16, 00:32

So one suggestion could be a "debugger" tile. similar to self halt in smalltalk.

Thanks to Bert who reminded me of this (while I was watching an Etoys video he made a while back in response to one of my requests on how to debug Etoys scripts)

MrSteve
Posts: 61
Joined: Jun 16th, '16, 01:22

Re: Allow user to use Debugger on Scripts

Post by MrSteve » Jul 30th, '16, 05:24

V51 give me requested behavior (I just have to blockify 'halt' or some other keyword) to get kids into the debugger.

You folks rock!!

JohnM
Posts: 379
Joined: Sep 11th, '15, 14:42

Re: Allow user to use Debugger on Scripts

Post by JohnM » Aug 1st, '16, 15:17

In v54, there is a new 'Debugging' category (in developer mode) that has 'halt' and 'error' blocks in it.

In addition, the debugger has been both simplified and improved. The error messages should be more clear and stepping works better.

Obscure trick: shift-click on the 'Step' button to enter functions (including the implementations of built-in blocks like "move"). To get out quickly, just select the stack frame with your own script and click step -- it will finish executing whatever function you entered.
I had made numerous attempts to try and understand the internals of Etoys and how it was implemented, but always ran into mental blocks. Perhaps its because I can now learn via block code. I think the syntax of Smalltalk threw me 1 + 2 * 3 = 9? too much cognitive dissonance and too much to unlearn perhaps. In any case I am finding it easier to explore and gain some understanding using the class browser in GP
One of the goals of GP is precisely to allow the internals to be explored -- and even changed -- as programmers gain expertise. GP is still missing some of the tools that would make this sort of exploration easier, but it is designed so that you can explore the system code as blocks and without learning an entirely new programming language. True, some of the system code is complicated -- it sometimes takes complicated machinery backstage to tell a simple story onstage -- but other parts of the system, such as the implementation of collections like List and Dictionary, are self-contained and interesting to study. One of the things I loved about Smalltalk was that I could learn about math, data structures, and graphics just by reading the system code. I've never had the same experience in languages like C or Java because, even though the source code for the libraries is usually available, it isn't right there at your fingertips.

Post Reply