Type Generic Observing

Observing intermediate values helps to understand what is going on when your program runs. Gill presented an observation method for lazy functional languages that preserves the program's semantics. However, users need to define for each type how its values are observed: a laborious task and strictness of the program can easily be affected. Here we define how any value can be observed based on the structure of its type by applying generic programming frameworks. Furthermore we present an extension to specify per observation point how much to observe of a value. We discuss especially functional values and behaviour based on class membership in generic programming frameworks

Practical quantitative measurement of graticule misalignment relative to collimator axis of rotation.

We design a practical procedure for measuring translational and rotational misalignment of graticule with collimator axis of rotation and collimator jaws, respectively. The procedure's quantitative results are accurate to less than 0.2 mm (at isocenter) and do not assume alignment of radiation focal spot with collimator axis of rotation. When provided with these quantitative results, the manufacturer can custom-adjust graticules to the purchaser's collimator head

A Lightweight Hat::simple type-preserving instrumentation for self-tracing lazy functional programs

Existing methods for generating a detailed trace of a computation of a lazy functional program are complex. These complications limit the use of tracing in practice. However, such a detailed trace is desirable for understanding and debugging a lazy functional program. Here we present a lightweight method that instruments a program to generate such a trace, namely the augmented redex trail introduced by the Haskell tracer Hat. The new method is a major step towards an omniscient debugger for real-world Haskell programs

Algorithmic Debugging of Real-World Haskell Programs: Deriving Dependencies from the Cost Centre Stack

Existing algorithmic debuggers for Haskell require a transformation of all modules in a program, even libraries that the user does not want to debug and which may use language features not supported by the debugger. This is a pity, because a promising ap- proach to debugging is therefore not applicable to many real-world programs. We use the cost centre stack from the Glasgow Haskell Compiler profiling environment together with runtime value observations as provided by the Haskell Object Observation Debugger (HOOD) to collect enough information for algorithmic debugging. Program annotations are in suspected modules only. With this technique algorithmic debugging is applicable to a much larger set of Haskell programs. This demonstrates that for functional languages in general a simple stack trace extension is useful to support tasks such as profiling and debugging

A Millimeter-scale Single Charged Particle Dosimeter for Cancer Radiotherapy

This paper presents a millimeter-scale CMOS 64$\times$64 single charged particle radiation detector system for external beam cancer radiotherapy. A 1$\times$1 $\mu m^2$ diode measures energy deposition by a single charged particle in the depletion region, and the array design provides a large detection area of 512$\times$512 $\mu m^2$. Instead of sensing the voltage drop caused by radiation, the proposed system measures the pulse width, i.e., the time it takes for the voltage to return to its baseline. This obviates the need for using power-hungry and large analog-to-digital converters. A prototype ASIC is fabricated in TSMC 65 nm LP CMOS process and consumes the average static power of 0.535 mW under 1.2 V analog and digital power supply. The functionality of the whole system is successfully verified in a clinical 67.5 MeV proton beam setting. To our' knowledge, this is the first work to demonstrate single charged particle detection for implantable in-vivo dosimetry

Algorithmic debugging for complex lazy functional programs

An algorithmic debugger finds defects in programs by systematic search. It relies on the programmer to direct the search by answering a series of yes/no questions about the correctness of specific function applications and their results. Existing algorithmic debuggers for a lazy functional language work well for small simple programs but cannot be used to locate defects in complex programs for two reasons: Firstly, to collect the information required for algorithmic debugging existing debuggers use different but complex implementations. Therefore, these debuggers are hard to maintain and do not support all the latest language features. As a consequence, programs with unsupported language features cannot be debugged. Also inclusion of a library using unsupported languages features can make algorithmic debugging unusable even when the programmer is not interested in debugging the library. Secondly, algorithmic debugging breaks down when the size or number of questions is too great for the programmer to handle. This is a pity, because, even though algorithmic debugging is a promising method for locating defects, many real-world programs are too complex for the method to be usuable. I claim that the techniques in in this thesis make algorithmic debugging useable for a much more complex lazy functional programs. I present a novel method for collecting the information required for algorithmically debugging a lazy functional program. The method is non-invasive, uses program annotations in suspected modules only and has a simple implementation. My method supports all of Haskell, including laziness, higher-order functions and exceptions. Future language extensions can be supported without changes, or with minimal changes, to the implementation of the debugger. With my method the programmer can focus on untrusted code -- lots of trusted libraries are unaffected. This makes traces, and hence the amount of questions that needs to be answered, more manageable. I give a type-generic definition to support custom types defined by the programmer. Furthermore, I propose a method that re-uses properties to answer automatically some of the questions arising during algorithmic debugging, and to replace others by simpler questions. Properties may already be present in the code for testing; the programmer can also encode a specification or reference implementation as a property, or add a new property in response to a statement they are asked to judge

A Type Generic Definition for Debugging Lazy Functional Programs by Value Observation

Observing intermediate values helps to understand what is going on when your program runs. Gill presented an observation method for lazy functional languages that preserves the program's semantics. However, users need to define for each type how its values are observed: a laborious task and strictness of the program can easily be affected. Here we define how any value can be observed based on the structure of its type by applying generic programming. Furthermore we present an extension to specify per observation point how much to observe of a value

Landelijk overgewichtbeleid gespiegeld aan kennis uit de gedragswetenschappen - 60

Political Science; Public Administratio