How to debug blocking programs

Torsten Anders torsten.anders at
Fri Jun 8 13:23:52 CEST 2012

Wolfgang clearly points out the limitations of his current implementation, details below this message.  

Besides -- I could not get it working so far on my machine :)

Best wishes,


* Elmoz Limitations


	• The display space for annotations is limited. Large data cannot be shown completely. This can be resolved by an implementation which allows to explore the annotations interactively.

	• The debugger shows inconsistent results if the 'world' changes between executions, e.g. if global state is involved or external files are read and written. To solve this, one needs a debugger which remembers the state of all variables, along the complete callgraph, such that multiple  executions are not necessary. For large programs, this might be impractical.

	• One of the features of Oz which are not supported, are for loops. They are in fact difficult to support because it would be necessary to annotate the code with the data of every single run of the loop.
Recursive function like FoldL are less problematic. You can simply press M-Shift-t again and again if you want to explore the nested calls to such a function.
The proposed approach to debugging therefore seems to be more useful for (mostly) functional programming language like Haskell or Oz than for imperative languages like C++, which very much depend on the use of loops.

Copied from README file:

Elmoz does currently not understand class definitions, for loops, nested functor
definitions, logic programming constructs like "dis" and "cond" and constraint
programming operators like ":=<".

Buffers where elmoz is used, must have a filename. You cannot use elmoz in an unsaved
Oz buffer.

If the function definition resides inside the definition of an application functor,
i.e. a functor which does not export anything: Elmoz will only execute the functor
up to the function definition, to avoid executing the whole program. Because of that,
definitions AFTER the function definition are not available for the function to use.

The same applies to typical OPI code, e.g. you cannot debug F in this code


  fun {F X} %%< X=3
     {G X}

  fun {G X}

because G is not yet defined from the point of view of the debugger.

There is no such limitations for normal, non-application functors.


On 8 Jun 2012, at 11:28, stewart mackenzie wrote:

> Just had an off list conversation with Torsten, through which a beautiful gem slipped. I thought I should share:
> This is similar to Bret Victors talk I posted a while ago.
> What are your thoughts on this approach? How can it be bettered?
> Kind regards
> Stewart

Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315

More information about the mozart-users mailing list