The JESDB Page

JESDB is a debugger for the JES environment. It is currently under development. The main difference between JESDB and other debuggers is that the user can monitor the program without it having to stop. This requirement is due to the nature of the homework assignments in CS1315. Thousands of pixels and thousands of some samples need to be processed, and it would be too tedious for the programmer to tell the debugger to continue after a breakpoint has been hit, when the breakpoint could be passed thousands of times at each execution.

SECTION I. Brain Storming

Slider/Scrollbar

use for speed - a slider controls the speed of execution.

use for place in the execution - a slider or scrollbar can move within the timeline of the executing program. There is one issue with this, should we be able to go back? This is doable, it will take more work though. We need to be able to go back. But there are going to memory issues when we store one set of state for each of thousands of pixels. We can only store a fixed number of steps backward.

Question from the peanut gallery

From Jim: Can we also have a "Step" button like in Dr. Scheme? This would enable the students to step through execution at their own pace, instead of using a slider to set the speed. I could see where both features would be useful. How hard would this be? yes! This is not a problem since it's a standard debugger thing. I'll make sure most standard debugger things are included.

How to display data

There are 2 ways to represent the time axis(That I am currently liking):

time on y-axis(vertical on the screen) - There is one row for each line of code executed, along with the state of the variables being watched. You should be able to scroll up and down within the timeline. Here's an example:

time on time axis - time corresponds to...time. The current line of code (in the editor) has an arrow to the left of it and/or is highlighted. As the program executes (slowly enough for the user to follow) the arrow moves from one line to the next. There will be a watcher window (or panel) that shows the values of the currently watched variables. We need to be able to control the speed of execution. An issue is, if the text in the editor is not displayable within one window, how should we handle moving the arrow and the window positioning? In KDbg, the red circles to the right of lines are the breakpoints, and the green triangle is the current line. KDbg's Variable watch uses tree structures to represent variables. I prefer something simpler. We can just support the atomic types.

Other Issues

I think that we should just monitor variables at the breakpoints. So the student has to specify each point at which they want to see the variables and the variables they want to see.
Should we display arrays (2d arrays?) in the variable watcher? But if they need to see the image changing they can just refresh the picture at every instruction so it is like an animation. no
Should we allow them to go into other files? like media.py, etc...I don't think they should be able to call stuff from other files of their own. This keeps it simple. But now, how do we enforce this?no How to enforce? we can ignore it for the time being.
Have a cue for them to see where the values of the variables are being changed. We can use a global map of execution(a small view of the entire timeline) and dot the places where the values have changed from the last instructionno too much for the studnents.
Remember that variables used in a program are mostly local. so when registering a variable for watching, it is only valid for that scope. This makes things complicated if you want to watch variables in different scopes. We need to figure out how to handle this. For the 'time is y-axis' case, this is really messy because the variable columns can change from row to row depending on the scope. We can also include variables from all scopes, and just blank out the unused ones, but this wastes screen space. In the 'time is time-axis' case, the watcher will have always to change its context depending on the scope. This could be disrupting if the programming is running fast. Or we could just ignore this problem and leave it as the programmer's problem. Since the programmer sets the breakpoints and the variables to monitor, he can just set keep all important breakpoints in the same scope. group variables by scope and just blank them out when they don't exist
Should the debugger control panel and the variable watcher be on the same frame as the JES frame or separate?separate panel

Advanced Ideas

showing the structure of a typed variable as a collapsable tree[KDbg]
mad graphs!!! graph data used in the program, graph frequency of executed paths, etc...[DDD]
display current threads, and be able to switch between threads[jD]
display current loaded objects[jD]
display the trace(previous callers, i.e. how we got to the current instruction)[jD]
do we want to let them change the variables while running?

References

Mark Comments:

I don't know if email is more likely to get conversation with this group or CoWeb posting, so I'll write this here, then copy-paste it onto the page.

I like the slider idea!
If we're going to have Step, then I think that Step should be a setting at the bottom of the slider. If the slider is set to Step, then only the Step button moves it forward.
I've always wanted reverse-time playback, but I agree, especially with mediacomp, that it's too memory intensive.
I like the first time-on-y-axis view the most, but the variable display and time sequence has to be made clearer. Why isn't the list shown? Why doesn't "n" have a value on the line when it's set to the list size?
I'm very much against breakpoints – I think it's too hard to grok. How about we do this: User specifies VARIABLES that they want to watch, we pre-compute the lines where the variable is used or set, then we insert breakpoints (invisibly) for the student and show those variables on those lines?
I agree – arrays are too hard to watch.
I also agree with blanking out variables out of scope. Scope is mostly a red-herring here. 90% of the code that the students write is in a single function. That needs to work the best/most.

Mark

More comments?

On Thu, 12 Jun 2003, Mark Guzdial wrote:
> - If we're going to have Step, then I think that Step should be a
setting
> at the bottom of the slider. If the slider is set to Step, then only the
> Step button moves it forward.

That sounds good. That is same as having the slider at the 'stop'
position.

> - I like the first time-on-y-axis view the most, but the variable
display
> and time sequence has to be made clearer. Why isn't the list shown? Why
> doesn't "n" have a value on the line when it's set to the list size?

We had a discussion about this in the meeting. Should the column
values be before or after the execution of the instruction? In
retrospect, 'after' is probably better, but we did not have a
definite answer yet.

> - I'm very much against breakpoints – I think it's too hard to grok. How
> about we do this: User specifies VARIABLES that they want to watch,
we
> pre-compute the lines where the variable is used or set, then we
insert
> breakpoints (invisibly) for the student and show those variables on
those
> lines?

This is a good idea. It'll definitely be more understandable and less
tedious. But would it confuse some student why the lines are picked as
breakpoints? I am not sure now whether showing every line is better or
only show some of them. Because if we only show some lines, students
would be confused at the discontinuity, especially if we chose the lines.

So right now the image in my head is a hybrid of the 2 ideas (both
time on vertical-axis and time on time-axis). we have the current
line cursor moving around in the editor window. And now the watcher
is going to be a table in a separate window. It is going to look like
the time-on-vertical-axis picture. It will show about 10 rows and it
permits scrollback up to say hundreds of instructions. Is this a good
design?

-Yu Cheung "toby" Ho (airport@cc.gatech.edu)

SECTION II: First prototype and feedback

The first prototype of the graphical debugger is out (6/18/03). I demoed it at the meeting and recieved some useful feedbacks.

Screenshots

The Variable Watcher along side the JES

Entering in a variable to watch

Feedback

Andria suggests that the slider is confusing being vertical on the watcher window I think making the slider horizontal fixes the problem
'debug mode' is confusing, how about 'show watcher' and 'hide watcher'?done
'stop' button or i think show be more like 'quit' or 'exit' or 'go away' on the watcher done
speed labels on slider done
when watcher is running(thus program is running), what happens in the editor? show it be editable? load button is disabled, so we don't worry about dynamic update of code, but show editor be editable? also, i thought about having the current line executing be highlighted in the editor as it is executing. if this is to happen, then editor definitly needs to be disabled during execution. I need suggestions on this. do this

Other Todos

automatically set the width of the columns so it looks nice done
automatically scroll all the way down done
implement stepping(step button doesn't work yet) done
clear variables on the menu done
i want to highlight the current line in the watcher done
breakpoints doesn't matter right now, i am showing all lines. should i make breakpoints matter? do away with breakpoints
option on menu for toggling between text mode and graphical mode? nah
a 'running' animation on the watcher would be good do Something
the state of the variables on the row show be the state after the execution of the instruction on the row rather than before it done

SECTION III: 2nd Prototype

The second prototype is out on 2/25/03.

Screenshots

The new debugger window with cute buttons. (Yes, I can say cute)

Feedback

Highlight the current line in the editor and lock it from editing
An animation on JES to show it's running done

Other Todos

debugger button on the jes button panel to give debugger more availability done
save the previous speed position on the slider when pause is pressed done
limit the number of rows done currently limited to 200 lines, but can be changed.

Looks very nice, but how does it look with variables, too? Mark Guzdial

SECTION IV: Version III

Out July 2nd, 2003.

Screenshots

Bugs

mad bugs right now

change the newly added variable values to '' instead of '-' done
the last line of execution is never shown done
when playing midi and you stop execution, craps out done
can't play midi with debugger? works for me
current line in watcher and editor are not sync'ed done
if you pause, and then stop, the next time you type a command JES hangs. fixed
the first line of a call (the def line) will remain highlighted after it is highlighted update: this only happends for the first line of the entire text buffer. fixed
Sometimes lines next to each other swap not issue anymore because we decided not to highlight the lines anymore
when program is stopped, the highlighting doesn't cease fixed
when closing debugger window during execution, 'hide debugger' button doesn't change to 'show debugger' fixed

Other Todos

make run and pause into one button done
Have a full speed mode, where updates to the table don't happen anymore...or infrequently/sparsely, but rows are still added to the model more or less done more testing required
buttons more descriptive done
have some cue to show that the variable columns are variables done
documentation working on it
when program running, disable 'show debugger' done
we decided to highlight the line number instead of the line of text. this is in progress

Links to this Page

Sum03 JES Development last edited on 25 October 2003 at 5:41 pm by OL117-12.fibertel.com.ar
Toby last edited on 16 November 2004 at 5:31 pm by borg.ciphertrust.com
Debugger documentation last edited on 23 July 2003 at 3:29 am by c-66-56-24-29.atl.client2.attbi.com