ok@quintus.uucp (Richard A. O'Keefe) (09/23/88)
In article <627@ecrcvax.UUCP> micha@ecrcvax.UUCP (Micha Meier) writes: >In article <264@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>[example showing the usefulness of REDO ports] > - first, when your goal q(~~) succeeds yielding wrong answer, > you normally see it immediately and retry it before > creeping to the next goal You do _see_ the wrong answer, but that doesn't mean that you _realise_ that it is wrong. Much of my debugging involves terms which are so large that abbreviation is necessary. > Before proceeding further, I must say that the idea of a four-port > debugger is ingenuous and it is not easy to think about an alternative. "Ingenuous" = "frank", "naive", "innocent". For alternatives: The DEC-10 Prolog library has a "DEBUG5.PL" which offers a NECK port in addition to CALL, EXIT, REDO, and FAIL. Dave Plummer has written two debuggers, SODA and CODA. One of them was described at SLP 87. Symbolics Prolog has a debugger with lots of stuff in it. BIM Prolog has a debugger with lots of stuff in it. (I find it bewilderingly complex, but that's just my personal opinion.) The Open University (Milton Keynes, England) is doing a lot of work on Prolog debugging. Then of course there are declarative/rational debuggers... > In a clause > p :- q, r, s, t. > when t/0 fails and the most recent alternative is for q/0, When t/0 fails, it is not possible for the most recent alternative to be for q/0. The most recent alternative can only be for s/0. If you want to go back to the first thing with a non-trivial alternative (that is, the first thing which won't immediately FAIL), that's what the "x" command is for. > I'd be interested in the experiences of other people > with the four-port debuggers, is everybody completely > satisfied with them? No, of course not. The DEC-10 Prolog debugger is powerful enough to be useful, and simple enough so that you don't find (re)learning the debugger to be the hardest part of debugging. There are lots of other things which would be nice: a way of displaying fewer goals automatic checking (of modes or types or whatever) automatic loop detection (for debugging only) integrated declarative debugging do-what-i-meant-not-what-i-said facility ... If anyone who described a debugger at the Prolog Environments workshop at SLP 88 is reading this newsgroup, how about posting a short description here? (And of course, anyone working on Prolog debugging who _didn't_ describe the work at SLP 88, please post too.) There's a lot more to debugging than debuggers. I have suggested ending one's source files with end_of_file. <test cases and other debugging support> as a method of keeping your code and test harness together (works well through the Emacs interface). You can use term_expansion/2 to add debugging code to predicates, e.g. you might map p(T1,...,Tn) :- G1, ..., Gm to p(X1,...,Xn) :- increment(247), X1 = T1,..., Xn = Tn, increment(248), G1, increment(249), G2, ... increment(255). which would give you "statement counts". What other debugging techniques are people using?
ok@quintus.uucp (Richard A. O'Keefe) (09/23/88)
In article <467@quintus.UUCP> ok@quintus.UUCP I wrote: > Dave Plummer has written two debuggers, SODA and CODA. One of them > was described at SLP 87. ... >If anyone who described a debugger at the Prolog Environments workshop at >SLP 88 is reading this newsgroup, how about posting a short description That should of course be ICLP 88 in each case. (Where did I put that brain, I was using it just a minute ago...)
alain@kulcs.uucp (Alain Callebaut) (09/30/88)
In reply to an article of Richard O'Keefe, and more especially to the following two fragments : > BIM Prolog has a debugger with lots of stuff in it. (I find it > bewilderingly complex, but that's just my personal opinion.) > If anyone who described a debugger at the Prolog Environments workshop at > SLP 88 is reading this newsgroup, how about posting a short description > here? (And of course, anyone working on Prolog debugging who _didn't_ > describe the work at SLP 88, please post too.) As you say it yourself : finding the BIM_Prolog debugger bewilderingly complex, is your personal opinion. How could you have another opinion on BIM_Prolog ? Anyway, I know a lot of people don't share that opinion. Not only researchers at our department, but also students (who aren't Prolog nor debugger guru's), use that debugger without noticeable difficulties. You don't have to understand ALL commands to be able to debug a program. It's possible to start with only a basic set of commands (that are in BIM_Prolog just the same as in any other Prolog). As one becomes more experienced or more demanding, he can add other commands to his knowledge. Nevertheless, I agree that the BIM_Prolog debugger might look complex, at first sight. This is because BIM_Prolog supports three methods for debugging, and wandering at all commands together, surely makes it look complex. You should have in mind that the commands are meant to be used in one specific method ('divide et impera' as a roman consul once said). As you asked, I will try to give an overview of the BIM_Prolog debugger. I hope this will make it somewhat clearer. There are mainly three different debugging approaches supported in BIM_Prolog : 1. The most commonly used box-model based step-wise program execution. 2. An algorithmic-like post-execution trace analyser. 3. Source oriented, break point based program execution. On SUN workstations, there is a multi-window interface, with control panels and command buttons and the like, which makes it possible to debug your program with the mouse. The three methods can be mixed : one can keep a trace of the program during step-wise execution and analyse it afterwards. Break points can be set together with spy points. By choosing the right resume command, one can switch between port and source oriented debugging. Although this mixed usage of debugging methods is perfectly possible, it is not recommended and not necessary. Each method is strong enough to stand alone. 1. Stepping debugger -------------------- In BIM_Prolog, the box has five ports : the usual four (CALL, EXIT, REDO, FAIL) and an additional UNIFY port, that is reached immediately after successful unification. Global port control includes possibilities to determine which ports have to be displayed and on which ports the execution must be suspended (known as 'leashing'). There are commands for resuming execution in different ways, as well forward as backward. Output control commands let you specify how the debugger must write out its information, independent from the program output. A very useful feature (especially in source oriented debugging) is a command for printing the current value of a variable. 2. Post-execution trace analyser -------------------------------- In this approach, a trace is recorded of the execution of a query. After completion, the trace can be analysed interactively, in a breadth first way. The analyser gives it output in source form. Here is an example of such output : 0: qsort( [3,4,1,2,5],_10 ) :- 1: split( 3,[4,1,2,5],_18,_19 ), 2: qsort( [1,2],_49 ), 3: qsort( [4,5],_87 ), 4: append( [1,2],[3,4,5],_10 ). Command : It shows a qsort/2 goal, solved in 4 subgoals. The arguments are printed as they were instantiated at the CALL port. This means you see how each subgoal was called. On simple demand, one can get the arguments as instantiated at the EXIT port. In this case, you see how the subgoal has been executed. If a goal has failed, it's displayed with all of its succeeded subgoals and with the failed subgoal, marked as such. The analysis can go on by selecting a subgoal for further investigation or by going back to the ancestor goal. There are also commands for going to the next solution of a goal. On a workstation, this can be combined with a separate source window in which the corresponding piece of the source program is indicated by the analyser. 3. Source oriented debugging ---------------------------- With this technique, the user sets break points at certain lines of his program. The most elegant way to do this, is with the window interface. You indicate the line in the source window and click the 'stop at' button. As feedback, stop signs are drawn near each line that contains a break point. When a break point is reached during execution, the program is suspended and the corresponding source line is indicated (with an arrow in the source window). Execution can be resumed by stepping, going to the next line or continuing up to the next break point. The stepping resume, will suspend the execution as soon as another source line is reached. Going to the next line means that all goals on the current line are executed silently. There are a number of commands for looking through the sources of your program. One can ask to display the ancestor goal in the source window, or the definition of a predicate. Other commands are provided for managing the break points. As mentioned above, one can print the value of a variable. The variable is pointed at in the source window and then the print command button must be clicked. One of the advantages of break points over spy points, is that you have more selectivity. Instead of stopping on each call of a predicate, it is possible to stop only on the call of that predicate from one specific goal. It's also easy to limit the suspensions to clauses of a predicate that are successfully unified, instead of having to skip from redo to redo. Another useful feature, available in all three debugging methods, is an alias mechanism. This can be used for redefining or abbreviating the names of commands or for abbreviating commonly used (complex) command constructions. For more information on the BIM_Prolog debugger, please contact : B.I.M. Tel.: +32 2 759 59 25 Kwikstraat 4 Tlx.: 63518 bimsa b B-3078 EVERBERG Fax.: +32 2 759 47 95 BELGIUM e-mail : dani@sunbim ...mcvax!prlb2!sunbim!dani Alain Callebaut K.U.Leuven - Dept. of Computer Science