Abstract: This article presents a series of four experiments investigating students' debugging of LISP programs. The experiments involve a population of students who know LISP reasonably well in that their errors are best classified as slips (Brown & Van Lehn, 1980). That is, students are unlikely to repeat the same errors either within their program or across programs (Experiment 1). The students' understanding of LISP is also reflected in their debugging behavior: They can usually fix a bug once they locate it. Students' difficulties are in locating the erroneous line of code. We observe that students use a variety of bug-location strategies during debugging (Experiment 2) and that the choice of strategy differs depending on whether students are debugging their own programs or other students' programs (Experiment 3). In addition, we observe that although the different bug-location strategies affect which lines of a program are searched, once students decide on a line, their ability to judge whether or not the line is correct and their ability to correct an error are not substantially affected by the strategy used to locate the line (Experiment 4). Finally, we argue that our results have implications not only for debugging in other computer languages, but for the general processes involved in troubleshooting as well.

Abstract: Eiffel is a language and environment intended for the design and implementation of quality software in production environments. The language is based on the principles of object-oriented design, augmented by features enhancing correctness, extendibility and efficiency; the environment includes a basic class library and tools for such tasks as automatic configuration management, documentation and debugging.

Abstract: An improved machine programming and control system includes the utilization of a continuous, multiple-block, flow chart or charts, all or a portion of which is displayed. Each entered flow chart is executed without conversion to other languages, such that machines are controlled in accordance with the flow charts that are displayed. Multiple flow charts may be entered each to separately control different machines or different parts of the same machine. The flow charts are displayed in a multiple-block presentation and a block numbering system permits rapid on-screen generation of flow charts, editing of the flow charts, and debugging of the flow charts through the utilization of an interrupt. A uniquely improved debugging system, active on an execution interrupt, permits rapid value changing for selected displayed flow chart blocks and permits a single-scan program rerun for verification. Upon run-time interruption, either the number of the flow chart block being executed at the time of interruption is automatically displayed or the block is highlighted so that a flow chart or charts may be edited and corrected on-the-fly. A new formatting system, inserts a block number format entry in the object program which is the output of the compiler, which entry is skipped by an Executive program during run-time execution, but which is retrievable upon a debugging cycle.

Abstract: This paper presents an overview of the hardware and software components of the Crystal multicomputer project. The goal of the Crystal project is to design and implement a vehicle that serves a variety of research projects involving distributed computation. Crystal can be used simultaneously by multiple research projects by partitioning the available processors according to the requirements of each project. Users can employ the Crystal multicomputer in several ways. Projects such as operating systems and database machines that need direct control of processor resources (clock, memory management, communication devices) can be implemented using a reliable communication service (the "nugget" that resides on each node processor. Projects that prefer a higher-level interface can be implemented using the Charlotte distributed operating system. Finally, users interested in Crystal principally as a cycle server can run UNIX® jobs on node machines using the "remote" unix service. Development, debugging, and execution of projects can take place remotely under the control of any of several UNIX hosts. Acquiring a partition of machines, resetting each machine, and then loading an application onto each machine is performed by invoking a UNIX-resident program (the "nuggetmaster"). Communication with node machines in a partition is facilitated by a virtual terminal and window mechanism. Crystal is fully operational and has been used to support a variety of research projects. To illustrate the flexibility provided by the Crystal environment, four of these projects are described.

Abstract: The Trellis programming environment supports programming in Trellis/Owl, an object-based language with multiple inheritance and compile-time type-checking. Trellis is composed of a number of integrated tools that share a common programming environment database. It is a highly interactive, easy-to-use programming environment, providing various programming aids, incremental compilation, and good debugging support. Trellis is both integrated and open-ended.Trellis was specifically designed to support the object-oriented programming methodology. Thus it provides tools to manage the use of types and inheritance. Trellis takes advantage of the strong-typing features of the Trellis/Owl language to provide more support for the programmer by keeping track of cross-references and inconsistencies in code.

Abstract: TSL-1 is a language for specifying sequences of tasking events occuring in the execution of distributed Ada programs. Such specifications are intended primarily for testing and debugging of Ada tasking programs, although they can also be applied in designing programs. TSL-1 specifications are included in an Ada program as formal comments. They express constraints to be satis fied by the sequences of actual tasking events. An Ada program is consistent with its TSL-1 specifications if its runtime behavior always satisfies them. This paper presents an overview of TSL-1. The features of the language are described informally, and examples illustrating the use of TSL-1, both for debugging and for specification of tasking programs, are given. A definition of robust TSL-1 specifications that takes into account uncertainty in runtime observation of behavior of distributed systems is given. A runtime monitor for checking consistency of an Ada program with TSL-1 specifications has been implemented. In the future, constructs for defining abstract tasks will be added to TSL-1, forming a new language, TSL-2, for the specification of distributed systems prior to their implementation in any particular programming language.

Abstract: We wish to determine the effectiveness of some simple hardware for debugging and profiling compiled programs on a conventional processor. The hardware cost is small -- a counter decremented on each instruction that raises an exception when its value becomes zero. With the counter a debugger can provide data watchpoints and reverse execution: a profiler can measure the total instruction cost of a code segment and sample the program counter accurately. Such a counter has been included on a single-board MC68020 workstation, for which system software is currently being written. We will report our progress at the symposium.

Abstract: Sloop is a parallel language and environment that employs an object-oriented model for explicit parallel programming of MIMD multiprocessors. The Sloop runtime system transforms a network of processors into a virtual object space. A virtual object space contains a collection of objects that cooperate to solve a problem. Sloop encapsulates virtual object space semantics within the object type domain. This system-defined type provides an associative, asynchronous method by which one object gains access to another. It also provides an operation for specifying groups of objects that should, for efficiency, reside on the same physical processor, and supports exploitation of the topology of the underlying parallel machine. Domains also support the creation of indivisible objects, which provide implicit concurrency control. The encapsulation of these semantics within an object gives the programmer the power to construct an arbitrary hierarchy of virtual object spaces, facilitating debugging and program modularity. Sloop implementations are running on a bus-based multiprocessor, a hypercube multiprocessor, and on a heterogeneous network of workstations. The runtime system uses object relocation heuristics and coroutine scheduling to attain high performance.

Abstract: Integral C1 is an industrial grade integrated programming environment for C programming on an engineering workstation. A single interactive tool replaces a syntax checking editor, a compiler, and a source-level debugger. Its multi-window user interface allows program editing and animated source level debugging, tailored to the needs of a C programmer. The compiler accepts standard C code and reacts to editing changes with function-level incremental compilation. Compilation is done without prompting to maintain the client program in a ready-to-run state. Emitted code is instrumented to catch run-time errors and to permit fine grained debugging. Debugging support code is written in C in a 'workspace', which grants it direct access to a local scope while keeping it separate from the client program.

Abstract: : The authors briefly discuss the design of a new programming language, called DINO, for programming parallel numerical algorithms on distributed memory multiprocessors. A significant difficulty with most current approaches to programming such computers is that interprocess communication and process control must be specified explicitly through messages, thereby making the parallel program difficult to write, debug, and understand. The authors' approach is to add several high-level constructs to the standard C programming language that allows the programmer to describe the parallel algorithm to the computer in a natural way, similar to the way in which the algorithm designer might informally describe the algorithm. These constructs include the specification of a data structure of virtual processors that is appropriate for the problem, and the ability to map data and procedures to this virtual parallel machine. Parallelism is achieved through a concurrent procedure call that utilizes these data and procedure mappings. All the necessary interprocess communication and process control results implicitly through these constructs. The paper includes a sample DINO program for parallel solution of Poisson's Equation.

Abstract: RNet is a high-level programming system for building and executing distributed hard real-time programs. The main objective in developing RNet is to investigate how high-level programming concepts and tools can be used to simplify the real-time programming task. A distributed real-time program in RNet consists of a configuration specification that outlines the structure and real-time properties of the program, and a set of program modules written in a high-level programming language. The RNet configuration system performs a static feasibility analysis of the specifications and handles the construction, distribution, and execution of the program. A debugging and timing analysis system, currently under development and not described here, will be used to measure the real-time characteristics of network resources and the application program, and to perform a validation of the specifications via simulation. The distributed RNet kernel provides run-time support for message-passing and real-time scheduling. The RNet programming model, based on message ports having associated deadlines, provides the programmer with a direct means of expressing a variety of real-time behavioral effects in a way that can be validated. In particular, timing constraints can be used to obtain reliable event synchronization. Some properties that are considered desirable in a high-level distributed real-time programming system are identified. These address issues such as program moduilarity and reconfigurability, timing constraint specification, validation and enforcement, real-time event handling, I/O and exception handling, logical and physical structure specification, and program analysis. The degree to which RNet succeeds in possessing these properties is discussed.

Abstract: Students' (n = 23) actual programming behaviors were observed in two high school Pascal programming classes. Observation was performed with a computerized low inference instrument that collected both frequency and time data. Behaviors coded included students' production of code as well as their debugging strategies. Results revealed that students spend little time in planning their programs or writing their code before they start to key in their code. Their debugging behavior was best characterized as a trial and error strategy. Results are discussed in terms of the classroom context for programming and implications for research on the effects of programming instruction.

Abstract: DATA STRUCTURES, ABSTRACT DATA TYPES AND RECURSION: Linear Data Structures and Their Array Implementation Linear Data Structures and Their Linked Implementation Abstract Data Types Recursion Trees Sorting and Searching Algorithms Files PROGRAM DEVELOPMENT: An Overview of the program Development Process The Problem Specification Phase Program Design Techniques Module Characteristics and Structured Coding Programming Style: Programs that Look Nice Programming Style: Programs that Behave Nicely Case Study in Program Development PROGRAM IMPLEMENTATION CONCERNS: Debugging, Testing, Formal Verification Program Efficiency and the Analysis of Alogorithms Documentation, Maintenance and Programming Support Environments.

Abstract: This thesis is concerned with the principled design of a computational environment which depicts an animated view of program execution for novice programmers. We assert that a principled animated view of program execution should benefit novice programmers by: (i) helping students conceptualize what is happening when programs are executed; (ii) simplifying debugging through the presentation of bugs in a manner which the novice will understand; (iii) reducing program development time. The design is based on principles which have been extracted from three areas: (i) the problems that novices encounter when learning a programming language; (ii) the general design principles for computer systems; and (iii) systems which present a view of program execution. The design principles have been embodied in three 'canned stepper displays for Prolog, Lisp and 6502 Assembler. These prototypes, called APT-0 (Animated Program Tracer), demonstrate that the design principles can be broadly applied to procedural and declarative; low and high level languages. Protocol data was collected from subjects using the prototypes in order to check the direction of the research and to suggest improvements in the design. These improvements have been incorporated in a real implementation of APT for Prolog. This principled approach embodied by APT provides two important facilities which have previously not been available, firstly a means of demonstrating dynamic programming concepts such as variable binding, recursion, and backtracking, and secondly a debugging tool which allows novices to step through their own code watching the virtual machine in action. This moves towards simplifying the novice's debugging environment by supplying program execution information in a form that the novice can easily assimilate. An experiment into the misconceptions novices hold concerning the execution of Prolog programs shows that the order of database search, and the concepts of variable binding, unification and backtracking are poorly understood. A further experiment was conducted which looked at the effect that APT had on the ability of novice Prolog programmers to understand the execution of Prolog programs. This demonstrated that the performance of subjects significantly increased after being shown demonstrations of the execution of Prolog programs on APT, while the control group who saw no demonstration showed no improvement. The experimental evidence demonstrates the potential of APT, and the principled approach which it embodies, to communicate run-time information to novice programmers, increasing their understanding of the dynamic aspects of the Prolog interpreter. APT, uses an object centred representation, is built on top of a Prolog interpreter and environment, and is implemented in Common Lisp and Zeta Lisp and runs on the Symbolics 3600 range of machines.

Abstract: A microprocessor can stop a program by an address or data under a complex break condition. A break function as a debugging tool which is more easy to use for a user of the microprocessor is provided.

Abstract: This paper focuses on the data structures and algorithms used in an integrated electron-beam probing system for IC diagnosis. This goal is to create an effective debugging environment through access to various types of design information. Dedicated databases permit separate schematics and layouts to be cross referenced on line. Special algorithms deliver fast, interactive performance by capitalizing on design hierarchies.

Abstract: The IRn programming environment pays systematic attention to the problems entailed in developing, debugging, and optimizing large programs. This paper reviews the principal mechanisms provided by IRn to support large programs. It describes the structure used to represent large programs and the tools that manipulate this structure. It also explores the way that the IRn compiling system handles whole programs: performing interprocedural analysis, removing redundant modules, and generating customized procedure linkages.

Abstract: An augmented and/or tree representation of logic programs is presented as the basis for an advanced graphical tracing and debugging facility for Prolog. TPM can be run in slow-motion/close-up mode for novices or high-speed/long-distance mode for experts with no attendant conceptual change. Moreover, it deals correctly both with clause head matching and with the cut. The current implementation runs on Apollo workstations, and is written in Prolog.

Abstract: The DI interpreter is both a debugger and interpreter of SISAL programs. Its use as a program interpreter is only a small part of its role; it is designed to be a tool for studying compilation techniques for applicative languages. DI interprets dataflow graphs expressed in the IF1 and IF2 languages, and is heavily instrumented to report the activity of dynamic storage activity, reference counting, copying and updating of structured data values. It also aids the SISAL language evaluation by providing an interim execution vehicle for SISAL programs. DI provides determinate, sequential interpretation of graph nodes for sequential and parallel operations in a canonical order. As a debugging aid, DI allows tracing, breakpointing, and interactive display of program data values. DI handles creation of SISAL and IF1 error values for each data type and propagates them according to a well-defined algebra. We have begun to implement IF1 optimizers and have measured the improvements with DI.

Abstract: This paper describes the environment for developing and executing Warp* programs. The center of the program development environment is a customized shell that ties together a compiler for the Warp array, the Warp run-time system, and a debugger. The compiler translates high-level language programs to microcode for the Warp machine. It achieves a high utilization of the computation power of the processor. The run-time system supports remote execution of Warp programs across a network and makes the Warp machine available as a shareable resource. The debugger permits symbolic debugging of Warp programs. The Warp programming environment makes the Warp machine an easily programmable and accessible attached processor in a UNIX™ environment .

Abstract: We present a system which generates interactive high-level debugging systems from formal language definitions. The language definer has to specify a denotational semantics augmented with a formal description of the language specific debugging facilities. The generated debugger offers the traditional features such as tracing programs, setting breakpoints, displaying variables etc; interaction with the user is always on language level rather than on machine level. The concept has been implemented as part of the PSG-Programming System Generator, and has successfully been used to generate debuggers for Pascal and Modula-2. The core of the implementation consists of an interpreter for a functional language, which has been extended with the language-independent mechanisms needed in order to allow interaction with the user during program execution.

Abstract: A technique is described which can be used to help novice programmers become more self-reliant in analyzing and debugging programs. The technique requires the instructor to interact one on one with students who seek help with their programs, and has been observed informally to have beneficial results for most of these students. Although the technique has not been tested experimentally, other experimental research involving novice programmers suggests that an approach of this kind should be effective.

Abstract: A primary and most important problem in computer science education at the undergraduate level lies in providing students with interactive tools to favor learning, to stimulate a more effective laboratory activity, and to facilitate the development and debugging of programs. Toward this end, we have designed VISAL, a tool for animating the execution of a program, and a library of fundamental algorithms instrumented for visualization. Visualizing the execution of a given program should enable the students to better understand the dynamic aspects of programming. We also describe the experimental work carried out by undergraduates of a programming course, in order to verify both the effectiveness of VISAL implementation and the role played by VISAL as an aid in learning activities.