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, Torsten ===================================== * Elmoz Limitations From http://wolfgangmeyer.blogspot.co.uk/2008/04/debuggers-are-needlessly-tedious-to-use.html • 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 declare fun {F X} %%< X=3 {G X} end fun {G X} X*2 end 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: > > http://wolfgangmeyer.blogspot.co.uk/2008/04/debuggers-are-needlessly-tedious-to-use.html > 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 http://www.torsten-anders.de _________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
