No abstract

Live programming allows programmers to edit the code of a running program and immediately see the effect of the code changes. This tightening of the traditional edit-compile-run cycle reduces the cognitive gap between program code and execution, improving the learning experience of beginning programmers while boosting the productivity of seasoned ones. Unfortunately, live programming is difficult to realize in practice as imperative languages lack welldefined abstraction boundaries that make live programming responsive or its feedback comprehensible.This paper enables live programming for user interface programming by cleanly separating the rendering and non-rendering aspects of a UI program, allowing the display to be refreshed on a code change without restarting the program. A type and effect system formalizes this separation and provides an evaluation model that incorporates the code update step. By putting live programming on a more formal footing, we hope to enable critical and technical discussion of live programming systems.

We describe a practical method for reasoning about realistic concurrent programs. Our method allows global two-state invariants that restrict update of shared state. We provide simple, sufficient conditions for checking those global invariants modularly. The method has been implemented in VCC 1 , an automatic, sound, modular verifier for concurrent C programs. VCC has been used to verify functional correctness of tens of thousands of lines of Microsoft's Hyper-V virtualization platform 2 and of SYSGO's embedded real-time operating system PikeOS.1 VCC is available in source for academic use at http://vcc.codeplex.com/ 2 The Hypervisor verification is part of the Verisoft XT project supported by BMBF under grant 01IS07008. 3 Objects mean collections of closely related data, e.g., regions of memory interpreted as structs in C.

No abstract

Abstract. The Boogie Verification Debugger (BVD) is a tool that lets users explore the potential program errors reported by a deductive program verifier. The user interface is like that of a dynamic debugger, but the debugging happens statically without executing the program. BVD integrates with the programverification engine Boogie. Just as Boogie supports multiple language front-ends, BVD can work with those front-ends through a plug-in architecture. BVD plugins have been implemented for two state-of-the-art verifiers, VCC and Dafny. IntroductionDeductive software verification technology is sufficiently mature that tools can formally verify non-trivial programs written in semantically intricate modern languages. However, these tools remain difficult to use. They require considerable expertise, patience, and trial-and-error, especially to decipher error conditions and verification failures. In sum: our tools can understand our programs, but we cannot understand our tools.In this paper, we present a verification debugger, called BVD (Boogie Verification Debugger), to help users understand the output of a program verifier. Our tool advances the state-of-the-art in program verification by increasing the communication bandwidth between the verifier and the user. Much as a dynamic debugger allows a programmer to explore a failing run-time state, the verification debugger allows her to explore-and, by extension, understand-a failing verification state. For example, a user can inspect the assumed values of local and heap-allocated variables. Constructing such a debugger is challenging because of the disconnect between the theorem prover counterexample model and the programmer's mental model of program execution.Verification tools vary in their automation levels. At one extreme lies fully automatic verifiers. This class of verifier includes many abstract interpreters or model checkers; to obtain full automation, such tools typically limit their reasoning to certain domains. At the other extreme lies verifiers that accept user input at all proof steps. This class of verifier describes many mechanical proof assistants; to obtain this flexibility, these tools typically expose the user to the internal representation of proof obligations. In this paper, we consider a family of verifiers between the automatic and interactive extremes, which we refer to as auto-active verification. An auto-active verifier has two major characteristics: the user can define assertions for the verifier to prove, and all user interaction is done at the level of the program source language. For example, a user may help the verifier along by declaring a precondition or loop invariant in the program, but