How to debug blocking programs

[Torsten Anders]

Dear fellow Oz programmers,

I guess that it already happened to many of you that your program blocks without any error message (e.g., the program performs some operation on a free variable and just waits for more information to be bound to that variable before it can continue). This ability is clearly a strength of the language.

On the other hand, accidental blocks are also particularly frustrating bugs for the programmer, because the language gives no feedback about the cause of the problem. I often have spend hours identifying some trivial cause, because it took so long to isolate the bug. Quite likely, this is the single kind of bug on which I spend by far most time fixing them.

Question: what are your strategies for fixing blocking programs? Thanks a lot!

Best wishes,
Torsten

--
Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315
http://www.torsten-anders.de



_________________________________________________________________________________
mozart-users mailing list mozart-***@mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-users

[Torsten Anders]

For example, would it be somehow possible to force an error whenever the main thread blocked more than some specified timeout amount (e.g., for more than 3 secs). I would wish there would be, e.g., some compiler flag to set such behaviour, and the error message would then pinpoint where the blocking occurred.

Again, what are your strategies for fixing blocking programs? Thanks a lot!

Best wishes,
Torsten

Post by Torsten Anders
Dear fellow Oz programmers,
I guess that it already happened to many of you that your program blocks without any error message (e.g., the program performs some operation on a free variable and just waits for more information to be bound to that variable before it can continue). This ability is clearly a strength of the language.
On the other hand, accidental blocks are also particularly frustrating bugs for the programmer, because the language gives no feedback about the cause of the problem. I often have spend hours identifying some trivial cause, because it took so long to isolate the bug. Quite likely, this is the single kind of bug on which I spend by far most time fixing them.
Question: what are your strategies for fixing blocking programs? Thanks a lot!
Best wishes,
Torsten
--
Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315
http://www.torsten-anders.de

_________________________________________________________________________________
mozart-users mailing list mozart-***@mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-users

[Raoul Duke]

On Thu, Jun 7, 2012 at 11:09 AM, Torsten Anders

Post by Torsten Anders
For example, would it be somehow possible to force an error whenever the main thread blocked more than some specified timeout amount (e.g., for more than 3 secs). I would wish there would be, e.g., some compiler flag to set such behaviour, and the error message would then pinpoint where the blocking occurred.

or be able to send it a signal and get a dump of blocked variables?
sort of like a stack dump from the jvm when you send it kill -3
_________________________________________________________________________________
mozart-users mailing list mozart-***@mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-users

[Torsten Anders]

To answer my own question: a long time ago (so that I meanwhile forgot :) I documented Debug.setRaiseOnBlock in my little Oz tutorial at http://strasheela.sourceforge.net/strasheela/doc/Basics-2.html#sec49

There is a little bit more documentation at
http://www.sics.se/~nilsf/mozart/2G1116/node5.html

Best wishes,
Torsten

Post by Torsten Anders
For example, would it be somehow possible to force an error whenever the main thread blocked more than some specified timeout amount (e.g., for more than 3 secs). I would wish there would be, e.g., some compiler flag to set such behaviour, and the error message would then pinpoint where the blocking occurred.
Again, what are your strategies for fixing blocking programs? Thanks a lot!
Best wishes,
Torsten

Post by Torsten Anders
Dear fellow Oz programmers,
I guess that it already happened to many of you that your program blocks without any error message (e.g., the program performs some operation on a free variable and just waits for more information to be bound to that variable before it can continue). This ability is clearly a strength of the language.
On the other hand, accidental blocks are also particularly frustrating bugs for the programmer, because the language gives no feedback about the cause of the problem. I often have spend hours identifying some trivial cause, because it took so long to isolate the bug. Quite likely, this is the single kind of bug on which I spend by far most time fixing them.
Question: what are your strategies for fixing blocking programs? Thanks a lot!
Best wishes,
Torsten
--
Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315
http://www.torsten-anders.de

_________________________________________________________________________________
http://www.mozart-oz.org/mailman/listinfo/mozart-users

_________________________________________________________________________________
mozart-users mailing list mozart-***@mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-users

[stewart mackenzie]

What a great idea! How would you implement such a mechanism? What kind of
scenarios would you face? How would you make it convenient for IDEs? Also
make it quick and easy from a user perspective?
How to tighted the debugging feedback loop as much as possible?

Kind regards
Stewart.

[Torsten Anders]

Dear Stewart,

having a library to include then remove is just another form of awkward ?

Not a principle problem, but one of the reasons why I forgot about this debugging feature :)

Ides have a debug mode, some people use this test driven approach, its a clean slate why not think of the ideal way to debug?

I certainly agree that debuggers in general as we know them could be greatly improved. For a very interesting proposal for Oz programmers, see http://wolfgangmeyer.blogspot.co.uk/2008/04/debuggers-are-needlessly-tedious-to-use.html . Wolfgang presents there a debugger that shows some similarity to the debugging approach Bret Victor presented in his talk, a few years later (you recently shared the link http://vimeo.com/36579366).

An omplementation for Wolfgang's debugger and other nice developer tools at http://code.google.com/p/oz-code/, see in particular Wolfgang's ozfind, http://ozfind.jottit.com/

We are at the point where the code is coming alone beautifully under Sébastien's hard work. I merely worry that this feature request is above and beyond his call for duty. In other words this is an itch that needs scratching, (we all have) though is it that itchy that you or Raoul would be interested in implementing it yourself?

Great news, and I very much appreciate your concern about the debugging facilities of Mozart 2! I can confirm from my experience that debugging concurrent programs can be very challenging and that every helpful tool is highly appreciated here.

Unfortunately, I am unable to contribute to the Mozart 2 development at this point for 2 reasons: I do not "speak" C++ (nor Scala), and my really heavy workload for my job hardly gives me any time for my own research :( (I am at a teaching and not research-focused university, but I am also required to publish regularly.) I am very sorry.

Best wishes,
Torsten

--
Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315
http://www.torsten-anders.de

_________________________________________________________________________________
mozart-users mailing list mozart-***@mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-users

[stewart mackenzie]

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

[Torsten Anders]

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.

=====================================

Post by Torsten Anders
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 mozart-***@mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-users