This file is indexed.

/usr/share/mozart/doc/ozcar/node5.html is in mozart-doc 1.4.0-8ubuntu1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

1
2
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>5 Execution Control</TITLE><LINK href="ozdoc.css" rel="stylesheet" type="text/css"></HEAD><BODY><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node4.html#chapter.sample">&lt;&lt; Prev</A></TD><TD><A href="index.html">- Up -</A></TD><TD><A href="node6.html#chapter.data">Next &gt;&gt;</A></TD></TR></TABLE><DIV id="chapter.control"><H1><A name="chapter.control">5 Execution Control</A></H1><P> This chapter describes the various possibilities of exercising fine-grained control over the execution of programs. To do so, we'll first define at what program points thread execution can be stopped, the so-called <A name="label17"></A><EM>step points</EM>. </P><H2><A name="label18">5.1 Step Points</A></H2><P> Step points are defined in terms of syntactic constructs in source code (in particular, debugging is not line-oriented). Many Oz constructs are designated to define step points, and in fact each such construct defines <EM>two</EM> step points: one at the entry and one at the exit. The entry point creates a new stack frame, which is popped at the corresponding exit point. When stopping at a step point, Emacs highlights the line containing it and inserts an additional mark within the line to indicate its exact position (where the precise syntactic construct begins or ends). </P><DIV class="apropos"><P class="margin">Constructs</P><P> The following gives a non-exhaustive list of what constructs constitute step points and how they are described in stack frames. </P><DL><DT>Definitions </DT><DD><P>The definition of a procedure, function or class constitutes a step point. The entry point is the <CODE><SPAN class="keyword">proc</SPAN></CODE>, <CODE><SPAN class="keyword">fun</SPAN></CODE>, or <CODE><SPAN class="keyword">class</SPAN></CODE> keyword, respectively, while the exit is the <CODE><SPAN class="keyword">end</SPAN></CODE> keyword. The frame description consists of the single word <CODE>definition</CODE>. </P></DD><DT>Applications </DT><DD><P>Procedure, function, object and method applications are step points. The entry and exit points are the opening and closing braces (or the comma in the case of a method application). The frame description mimics application syntax, displaying the procedure name (or <CODE>$</CODE> if it is anonymous) and the argument values. </P></DD><DT>Conditionals </DT><DD><P>Boolean and pattern-matching conditionals are step points. The entry point is the <CODE><SPAN class="keyword">if</SPAN></CODE> or <CODE><SPAN class="keyword">case</SPAN></CODE> keyword (or <CODE><SPAN class="keyword">elseif</SPAN></CODE>, <CODE><SPAN class="keyword">elsecase</SPAN></CODE>, or <CODE><SPAN class="keyword">catch</SPAN></CODE>, to be precise), the exit point the corresponding <CODE><SPAN class="keyword">end</SPAN></CODE>. The frame description consists of the word <CODE>conditional</CODE>, followed by the value tested by the conditional, if it could be determined. </P></DD><DT>Thread Creation </DT><DD><P>Thread creation using the <CODE><SPAN class="keyword">thread</SPAN>&nbsp;</CODE>...<CODE>&nbsp;<SPAN class="keyword">end</SPAN></CODE> construct is a step point, with the obvious entry and exit points. Thread creation frames consist of the word <CODE>thread</CODE>. </P></DD><DT>Installation of Exception Handlers </DT><DD><P>The <CODE><SPAN class="keyword">try</SPAN>&nbsp;</CODE>...<CODE>&nbsp;<SPAN class="keyword">end</SPAN></CODE> construct defines step points (unless it has neither <CODE><SPAN class="keyword">catch</SPAN></CODE> nor <CODE><SPAN class="keyword">finally</SPAN></CODE>, in which case it is ignored), with a frame description of <CODE>exception handler</CODE>. The actual handling of exceptions is a step point by virtue of the fact that conditionals are step points. </P></DD><DT>Critical Sections </DT><DD><P>The <CODE><SPAN class="keyword">lock</SPAN>&nbsp;</CODE>...<CODE>&nbsp;<SPAN class="keyword">end</SPAN></CODE> constructs are step points, with the frame description containing both the word <CODE>lock</CODE> and the lock itself. </P></DD><DT>Loops </DT><DD><P>The <CODE><SPAN class="keyword">for</SPAN>&nbsp;</CODE>...<CODE>&nbsp;<SPAN class="keyword">end</SPAN></CODE> construct defines step points, with frame description <CODE>loop</CODE>. </P></DD></DL><P> </P></DIV><H2><A name="label19">5.2 Actions</A></H2><DIV class="apropos"><P class="margin">Step Into</P><P> The simplest way to control the execution of a thread is to single-step, i.&nbsp;e., to proceed from one step point to the next. This is exactly what Step Into (<IMG alt="" src="step.gif">) does. This is the most fine-grained visualization of program execution. </P></DIV><DIV class="apropos"><P class="margin">Step Over</P><P> In contrast, the Step Over action (<IMG alt="" src="next.gif">), when performed at an entry point, causes thread execution to next stop at the corresponding exit point, not stopping at any nested step points. On an exit point, it behaves exactly as Step Into does. </P></DIV><DIV class="apropos"><P class="margin">Action Unleash</P><P> Actually, Step Over is a special case of a more generic action, called Unleash (<IMG alt="" src="unleash.gif">). It causes execution of the thread to continue until the <EM>selected</EM> stack frame is about to be popped from the stack (or until the thread has finished executing the whole stack if no stack frame is selected); this makes Step Over identical to an Unleash with the topmost frame selected. Remember you can select a stack frame by clicking on it or by walking to it using the up and down cursor keys. </P></DIV><DIV class="apropos"><P class="margin">Example</P><P> To illustrate the unleash action, we'll consider the following program which computes the factorial function: </P><BLOCKQUOTE class="code"><CODE><SPAN class="keyword">local</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;<SPAN class="keyword">fun</SPAN><SPAN class="variablename">&nbsp;</SPAN>{<SPAN class="functionname">Fac</SPAN>&nbsp;N}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class="keyword">if</SPAN>&nbsp;N&nbsp;<SPAN class="keyword">&lt;</SPAN>&nbsp;2&nbsp;<SPAN class="keyword">then</SPAN>&nbsp;1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class="keyword">else</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;N&nbsp;<SPAN class="keyword">*</SPAN>&nbsp;{Fac&nbsp;N<SPAN class="keyword">-</SPAN>1}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class="keyword">end</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;<SPAN class="keyword">end</SPAN>&nbsp;<BR><SPAN class="keyword">in</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;{Show&nbsp;{Fac&nbsp;5}}<BR><SPAN class="keyword">end</SPAN></CODE></BLOCKQUOTE><P> Go and activate Step Into (<IMG alt="" src="step.gif">) a couple of times, so as to build up a bit of stack, and select Frame 5. Your Ozcar should look similar to <A href="node5.html#picture.fac1">Picture&nbsp;5.1</A>. </P><DIV class="picture" id="picture.fac1"><HR><P><A name="picture.fac1"></A></P><P></P><DIV align="center"><IMG alt="" src="fac1.gif"></DIV><P> </P><P class="caption"><STRONG>Picture&nbsp;5.1:</STRONG> Before the Action ``Unleash 5''</P><HR></DIV><P> Let's decide to immediately compute the value of <CODE>{Fac&nbsp;3}</CODE>, in other words, continue the thread's execution until Frame 5 is about to be removed from the stack. Unleash (<IMG alt="" src="unleash.gif">) with Frame 5 selected does exactly this. <A href="node5.html#picture.fac2">Picture&nbsp;5.2</A> displays the result of this action. </P><DIV class="picture" id="picture.fac2"><HR><P><A name="picture.fac2"></A></P><P></P><DIV align="center"><IMG alt="" src="fac2.gif"></DIV><P> </P><P class="caption"><STRONG>Picture&nbsp;5.2:</STRONG> After the Action ``Unleash 5''</P><HR></DIV><P> </P></DIV><H2><A name="label20">5.3 Breakpoints</A></H2><P> Single-stepping is nice, but often somewhat inconvenient, because you may need a lot of steps until you reach the interesting section of your program. This is where breakpoints come in. Ozcar supports them in two flavours: <A name="label21"></A><EM>static breakpoints</EM> and <A name="label22"></A><EM>dynamic breakpoints</EM>. </P><DIV id="section.static-breakpoints"><H3><A name="section.static-breakpoints">5.3.1 Static Breakpoints</A></H3><P> A static breakpoint can be defined by editing source code to contain an application <CODE>{Ozcar<SPAN class="keyword">.</SPAN>breakpoint}</CODE> and recompiling the program (which is why they're called <EM>static</EM>). This also means that static breakpoints will persist across multiple debugging sessions. </P><DIV class="apropos"><P class="margin">Example</P><P> Let's take the factorial example again and assume we need to debug the base case of the recursion. We can do this with a static breakpoint as follows: </P><BLOCKQUOTE class="code"><CODE><SPAN class="keyword">local</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;<SPAN class="keyword">fun</SPAN><SPAN class="variablename">&nbsp;</SPAN>{<SPAN class="functionname">Fac</SPAN>&nbsp;N}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class="keyword">if</SPAN>&nbsp;N&nbsp;<SPAN class="keyword">&lt;</SPAN>&nbsp;2&nbsp;<SPAN class="keyword">then</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{Ozcar<SPAN class="keyword">.</SPAN>breakpoint}&nbsp;1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class="keyword">else</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;N&nbsp;<SPAN class="keyword">*</SPAN>&nbsp;{Fac&nbsp;N<SPAN class="keyword">-</SPAN>1}<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN class="keyword">end</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;<SPAN class="keyword">end</SPAN>&nbsp;<BR><SPAN class="keyword">in</SPAN>&nbsp;<BR>&nbsp;&nbsp;&nbsp;{Show&nbsp;{Fac&nbsp;5}}<BR><SPAN class="keyword">end</SPAN></CODE></BLOCKQUOTE><P> After feeding the code and performing the Unleash (<IMG alt="" src="unleash.gif">) action twice, we arrive directly at the desired program point. </P></DIV></DIV><DIV id="section.dynamic-breakpoints"><H3><A name="section.dynamic-breakpoints">5.3.2 Dynamic Breakpoints</A></H3><P> Sometimes we'll want to insert a breakpoint in the course of a debugging session. Then we need dynamic breakpoints. </P><DIV class="apropos"><P class="margin">Setting Breakpoints</P><P> Dynamic breakpoints can easily be set from within Emacs: Position the cursor on the line where you want to set or reset breakpoints and press <SPAN class="key">C-x space</SPAN> to set or <SPAN class="key">C-u C-x space</SPAN> to delete breakpoints. Note that this will affect <EM>all entry points</EM> on the corresponding line (there may be several, or none). </P></DIV><P> Currently, there is no way to list all currently defined dynamic breakpoints. </P></DIV></DIV><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node4.html#chapter.sample">&lt;&lt; Prev</A></TD><TD><A href="index.html">- Up -</A></TD><TD><A href="node6.html#chapter.data">Next &gt;&gt;</A></TD></TR></TABLE><HR><ADDRESS><A href="http://www.ps.uni-sb.de/~lorenz/">Benjamin&nbsp;Lorenz</A> and&nbsp;<A href="http://www.ps.uni-sb.de/~kornstae/">Leif&nbsp;Kornstaedt</A><BR><SPAN class="version">Version 1.4.0 (20110908185330)</SPAN></ADDRESS></BODY></HTML>