↑ Writing ↑


Generic Card Debugger

June 15, 1994

While I don't doubt that there are good reasons for ignoring most of Ward's suggestions, I don't understand why - in all the discussions of GUIs and debuggers, etc. - everyone is ignoring Ward's valuable contribution in bringing Tcl and Tk into the light of Code 521's day.

The card debuggers, in particular, are good candidates for using Tcl, an embedded command language. I'm not familiar with Code 521's debuggers, but I envision a debugging system consisting of:

An advantage of the ASCII I/O interface is that it loosens the coupling between the user interface and the debugger. New commands can be added to the debugger and existing commands can be enhanced without having to recompile, let alone write new code for, the GUI. For example, my Motif- and Tcl-based wimp GUI could be programmed in Tcl to talk to a debugger as follows:

    wmp_net call frame_sync_dbgr@host -input process_response

    wmp_button button1 -label "Read Status"         -command {frame_sync_dbgr write "dbg_read register0"}

(wimp with extensions for the TPOCC/GenSAA widgets, was, of course, called twerp!) The first line establishes a network connection to the frame sync debugger; input received from the debugger is passed to a process_response procedure. The second line creates a Motif button, "Read Status", on the screen; when the button is pressed, the command "dbg_read register0" is sent to the frame sync debugger. Any messages returned by the debugger are interpreted by process_response.

New debugger commands can be incorporated into the GUI by simply defining new buttons with different labels and different on-button-click commands. (I'm using buttons in my example, but the debugger commands can also be generated via menus, etc.) The "ASCII advantage" is not lost on non-Tcl-based GUIs like TPCE. Such GUIs could register a callback procedure with the Motif Resource Manager that sends a command to the debugger. That procedure (a C function) could then be bound to a widget's callback in the display's UIL file:

    callbacks {
        XmNactivateCallback = procedures {
            send_debugger ("frame_sync dbg_read register0") ;
        } ;
    } ;

(You should also be able to specify the callback binding in your GUI builder.) When the widget is "activated" (e.g., via a button click), send_debugger() would be called to send "dbg_read register0" to the frame sync debugger. send_debugger() would have to be smart enough to know how to connect to the specified debugger, if not already connected, and to send the command.

Ideally, of course, TPCE would be a programmable GUI having its own embedded Tcl interpreter, complete with MEDS extensions.

Alex Measday  /  E-mail