Kahina for QType Tutorial Part 5: Using Control Points

This tutorial assumes that you have learned about control agents in QTypeTutorial4. In this tutorial, you will finally start to define your own control agents. Since the default control agent profiles that come with Kahina for QType will normally be all you need for simplifying tracing processes, here you will learn about a type of control agent which comes in very handy when you are only interested in QType's behavior at a specific point, which will often be the case during debugging.

While the control agents you have seen in the predefined profile of QTypeTutorial4 had sensors listening for patterns on step labels, many other kinds of sensors are conceivable. Note that interesting predicates will usually be called at many different places in a Prolog program, and during debugging it will often be useful to distinguish between these places. One particularly useful kind of sensor therefore listens for the trace to arrive at a particular line in the source code. In Kahina terminology, control agents with such line-based sensors are called control points. Control points increase the degree of fine-grainedness possible for sensor patterns, as distinctions between different calls to the same predicate are not straightforward to model using patterns on a string representation of a goal. Moreover, defining a tracing action to be executed every time that a line in the source code is touched is a particularly simple and easy-to-understand type of control automation.

For this tutorial, we will again base our discussion on the project QType Tutorial 4-5, which you are asked to load now. To demonstrate the usefulness of control points in understanding and sifting through longer parses, we will parse a much longer sentence this time. After compiling the grammar, open the Grammar -> Parse example menu and choose the sentence uther has persuaded knights to storm cornwall.

Defining a break point

Control points are a very simple type of control agent for the user to create because no interaction with the control agent profile editor is required to define them. Control points can be defined directly via the context menu of the source code editor. We shall begin by creating a break point, an agent whose sensor listens for a source code line, and whose actuator sends out a break command just as if the user had clicked on the Pause button during a leap. The name of this type of agents is of course not a coincidence, as its behavior effectively emulates a line-based breakpoint as you would define it in a usual Prolog tracer.

Assume that we are interested in the exact behavior of the rule for trivial verb phrases in our example grammar. In the current version of Kahina, you need to issue the creep command twice, so that the lexentry_existence/2 call gets auto-completed, and select the db_word/4 step in the detail view in order to make the grammar file shieb4.qtg appear as a tab in the source code view (this will be more user-friendly in the final version):

Scroll up in the source code display until you arrive at the section where the syntax rules are defined. With a right click on the definition of the relevant rule (the middle one, as indicated by the comments), you open a context menu which allows you to add a break point, which is what you should do now.

Let us check whether the break point was registered in the correct control agent profile. In the control agent profile editor, switch to the Break tab. You should see an entry called shieb4.qtg:112 in this list. Clicking on the entry, you will see a very simple sensor description on the right side of the list. In the current version of Kahina, this description only consists of the complete path to the source code file followed by a colon and the line number the sensor is watching out for.

Note that Kahina cannot deduce any relevant semantic information about the code line you selected. You therefore might want to rename your new break agent for easier identification, especially if you are planning to define more than one break point at the same time. Names can be changed via the agent list's context menu, which you open with a right click on the relevant list entry. In this menu, use the Rename option to give the break point a more telling name like "trivial verb phrase rule".

Leaping between break point matches

After adding the break point, we can now observe the new behavior of the Leap command. After issuing it for the first time, Kahina should almost immediately fast-forward you to the first call of db_rule/4 which retrieves the trivial verb phrase rule, and automatically exit the leap mode there:

We encourage you to creep around a little to see the consequences of this attempted rule application. Once you have seen enough, issue the Leap command again and again, jumping between all the relevant calls to db_rule/4. If you have experience with Prolog debugging using a standard tracer, this workflow pattern will appear very familiar. If you have not used breakpoints in your Prolog tracer that much, this might be a good time to play around a little more with different break points. Note that you can define any number of break points, watching several points of interest in the grammar code at the same time.

Other types of control points

You will have noticed that the context menu for each source code lines contains additional entries for creating other types of control points. Each of the agents so created will show up in the respective tab of the control agent profile editor. Depending on the commands issued by their actuators, these control agents will be called creep points, skip points, fail points, and complete points, respectively. Depending on our own experiences as well as user demand, additional control point types might be added to this list in the future.

These different types of control points provide a very flexible method of very locally influencing Kahina's behavior, with a range of possible usage scenarios. For instance, in order to temporarily deactivate a phrase structure rule, you could put a fail point on the source code line where it is defined. If you only want a specific call of some predicate to be auto-completed for possible later inspection, but another less interesting call to be skipped, this can be achieved by putting complete and skip points on the respective code lines. You will soon find it worthwhile and effective to spend some time thinking about a possible application of the control point system whenever you are confronted with a task that seems mechanic or burdensome during tracing or debugging.

Removing a control point

In the current version of Kahina, it is not yet possible to remove or deactivate control points via the source code view. It also is not yet visible in the source code view whether a control point was defined for any given line. Both of these features are going to be present in the final release version of Kahina for QType.

In the current version, all control agents including control points can only be removed via the control agent profile editor. To remove the breakpoint which we defined in this tutorial, you need to change to the Break tab of the editor, select the breakpoint, and right-click on it. The context menu showing up contains an entry named Remove. Clicking on this menu entry will deactivate and remove the breakpoint, reverting Kahina to the predefined behavior from the previous tutorial.

In case you are wondering about the meaning of the signal color which is associated with every control agent and which can also be modified via this menu, this belongs to another feature which we yet to implement in Kahina for QType. The signal color will be used to mark the messages in the console which tell you when an agent's sensor has matched the current step, increasing the perspicuity of these special events in a trace.

Further Steps

You have now acquired first experiences with defining your own control agents. In QTypeTutorial6, you will learn how to define more complex control agents using the control agent editor, and how to administer control agent profiles. You will also learn how to define your own projects, finally giving you the freedom to go beyond the one example grammar to which we have constrained ourselves so far.