GLX2

The Concept

Do you ever insert an answer dialog in your script to see what the value of a var might be because you don't want to go through the hassle of a debug session?

 

If your answer is "yes", then you need to check out GLX2's Script Snapshot mode. It's easy to use and it's far less effort than debugging or even inserting answer dialogs or put statements (that you always forget to take out).

An Execution Inspector

Script Snapshot will show you the state of your vars at any point in your script--and without interrupting.

  

Bread Crumb-like Link

Along with status on variables, params, globals and locals, you also get a link that leads directly to the line in the script where you told Script Snapshot to capture state data.

1. Set the Mode!

First, if you have not already done so, you will need to turn on Screen Snapshot Mode under the Script menu.

 

Note: 
• When you turn on Screen Snapshot Mode it will automatically turn off Script Debug Mode. 
• Conversely, turning on Script Debug Mode will turn offScript Snapshot Mode.

Important: 
• You will need Galaxy 1.5.0r42 (or higher) to use Script Snapshot.

2. Set a Breakpoint!

Then, you need to set a Screen Snapshot breakpoint exactly the same way you set a debug breakpoint: type breakpoint in your script!

3. Run Your Script!

This inspector is not modal in any way. When a script encounters a breakpoint, Script Snapshot will quickly store your data at that instant, but it will not impede the running of your scripts. After the script has run, the Script Snapshot windows will pop up, if it isn't already visible.

You can use it as much as you like in a script, including in repeat loops. Once the script has run, you can use the pop up menu to look at different snapshots--even those taken in different object scripts at different times.

Too Much Information?

You can also filter the results you want to see with the checkboxes and the filter field--where you type a string to pare down the snapshot data.

Q&A with Trevor

Why invent a Script Snapshot?

We found that the debugger was often overkill for lots of things. I think the Snapshot behavior is a more useful in many situations given the "always on" nature of the engine. In compiled environments you have to have a debugger to look at your code. The snapshot seems like a better fit for many situations in interpreted languages. Plus the ability to store variable values is really handy when debugging repeat loops that manipulate data.

Why use "breakpoint" to take a snapshot?

Jerry and I hooked up script snapshots to the breakpoint command because that way it wouldn't cause execution errors if you left the code in your standalones. We are just branching the code in the traceBreak message based on the menu setting (debugger or snapshot).

At first we were just going to put in a glXTakeScriptSnapshot command that would handle this but then you have to make sure you always clean up after yourself before launching your standalone.

Could we have a peek at the execution context (who called the handler?)

This will be added at some point.

How about a way to stop execution conditionally ( if x > y or after N passes through the breakpoint) then to resume?

This will not be added. Snapshots in no way affect execution of a script. This is a debugger feature.

Could we have a way to alter values of variables while execution is stopped?

This too is a debugger feature.

Is there a way to peek at designated properties (e.g. the visible, the loc, the value of uMyCustomProperty) of objects, not necessarily the scripted object?

I think to add a feature like this we would probably have to add our own handler:

1. BEHAVES LIKE SCRIPT SNAPSHOT DOES NOW:
      glxTakeSnapshot
2. LOGS THE PROPERTIES OF AN OBJECT.
3. A LIST LIKE THE PROP EDITOR:
      glxTakeSnapshot the long id of button "Bob"

Why is the debugger so unpredictable?

By the way, building a debugger in Rev would be a kazillion times more reliable if the engine had one more feature - a true step over. The engine has no idea how to step over a line of code so you have to code it by hande which becomes quite interesting and time consuming.

Eventually...

At this point script snapshots are at a very infant stage. Jerry and I are using the feature in our development to see what we like/need/want. Someday soon I am going to hook up the snapshot code to work over sockets so we can have a standalone snapshot monitor. You could then monitor snapshots from standalones as well. This is something Jerry and I have wanted to do with the debugger for a while now but just haven't taken the time to do yet.