2.15
DATA FILE LINK SPECS
2.17
UNIVERSAL LANGUAGE FOR COMPUTING
Debugging can be as nerve racking as programming can be fun. ROBACUS tries to balance the two by put enough discipline in programming that debugging becomes manageably predictable. In fact ROBACUS has made debugging so systematic that it can be fully automated.
ROBACUS' commitment to full automation, when it applies to debugging, however, represents by far the greatest challenge undertaken by any software group in the world of computing. This is where software robots become indispensible. We just need to create some real hardworking robots to handle the works that are too cumbersome to do manually. The time-consuming, iterative nature of debugging fits nicely with the emerging, new, processing-hungry computers.
The basis of debugging is diagnosis. We simply let the bug reveal itself by revealing the processing around it. This is done by systematically putting "IF(LOGBUG.GE.1)WRITE(LOGDEB,9...)..." statements at the start and end of each subroutine, as well as: "IF(LOGBUG.GE.2)WRITE(LOGDEB,9...)..." in places relevent to the troubled area, where LOGBUG can be set to 1,2 or 3 and LOGDEB can be set to 70 or 6 or, 60 for editor. Pushing this to the limit, ROBACUS actually perfected a scheme where every statement is written out dynamically in the path of the execution. This allows revealing of the execution flow path and pinpointing the statement where the execution gets bombed out.
To diagnose/debug, simply enter: 'd' or click the Diagno button at the upper right. Then select one of the following option:
1.TRACK ROUTINES
2.ALSO INTERNAL VARIAB
3.MANUAL DEBUG AND TRACK
4.AUTO DEBUG COMPILE EXE
5.LINE TRACK OF ROUTINE
These are 5 levels of background tracking of the execution.
In the case of the editor, we can also take advantage of the robot file that keeps a log of all the commands issued. In this robot file, we could also write in it via unit 60 all the debugging statements, and when intermingled within the sequences of editting command, it gives a clear picture of what's going on during the editing session.
The diagnoser will set up two update source files that contain debugging statements. The first file, ???u0c, does a full compilation of all the subroutines to generated the new library for linking. The second file, ???u0d, then can be used iteratively to only modify and compile the trouble subroutine.
The line-by-line tracking is pretty much a full-brute-force, fool-proof way of tracking down the bug. It guarranttees to pin down where the bug occurs and the statement-by-statement execution that leads to it. But this process may be very lengthy, so it will be automated.
In the automated debugging process, the diagnoser would automatically bring you to editting the troubled statement, inside the troubled subroutine, and also ready to be submitted and executed again.
The detailed auto debugging strategy is described below:
1. search out in which subroutine the bug exits
2. search out at which statement the bug exits
3. the file containing the subroutine is edited and the subroutine and then the statement are searched so that the cursor will end up at the bug position
4. this file can be modified and recompiled iteratively until the bug is resolved
The automated process involving:
* read the last record of unit 70(fort.70) to see if the "SUCCESS..." statement exits(written out in subroutine AUTPUT) that indicate no bug occurred
* if SUCCESS is nonexistent, then unit 70 is searched backward to locate the 1st 'ENTERING...' that does not have a matching 'EXITING...' statement for the particular subroutine. This indicates a subroutine that has been entered but never exited, thus, contains the bug.
* generate codu0caand codu0d for the file that contains the bug subroutine.
* codu0c is compiled to produce an executable that produce a line-by-line tracking, capable of pin-point the line at which the execution bombs out.
* problem is automatically reexecuted by the problem's software robot using codu0c's executable
* the bug statement will be read as the last statement in the debugging output
* codu0d is then edited by an edirob which robotically search for the bug statement.
* if the nature of the bug is known, a bug-fixing robot will be used to fix it automatically.
* otherwise, codu0d can be used iteratively to fix the bug.
* if the same kind of bug is expected to occur in the future, an editting robot can be constructed to fix the bug automatically. a search and selection scheme is also constructed to selctively active the bug-fixing feature during autmated debugging.
2.15
DATA FILE LINK SPECS
2.17
UNIVERSAL LANGUAGE FOR COMPUTING
