1: \NeedsTeXFormat{LaTeX2e}
2: \documentclass[runningheads]{llncs}
3:
4: \usepackage{epsfig}
5: \usepackage{amssymb}
6: \usepackage{latexsym}
7:
8: \begin{document}
9: \setcounter{page}{47}
10: \title{CLPGUI: a generic graphical user interface for constraint logic programming over finite domains}
11: \titlerunning{CLPGUI: a generic graphical user interface for CLP(FD)}
12: \author{Fran{\c{c}}ois Fages}
13: \authorrunning{F. Fages}
14: \institute{Projet Contraintes, INRIA-Rocquencourt,\\
15: BP105, 78153 Le Chesnay Cedex, France, \\
16: \email{Francois.Fages@inria.fr}}
17:
18: \maketitle
19:
20: \addtocounter{footnote}{1}
21: \footnotetext{In Alexandre Tessier (Ed), proceedings of the 12th International Workshop on Logic Programming Environments (WLPE 2002), July 2002, Copenhagen, Denmark.\\Proceedings of WLPE 2002: \texttt{http://xxx.lanl.gov/html/cs/0207052} (CoRR)}
22:
23: \begin{abstract}
24: CLPGUI is a graphical user interface for visualizing and interacting
25: with constraint logic programs over finite domains. In CLPGUI, the
26: user can control the execution of a CLP program through several views
27: of constraints, of finite domain variables and of the search tree.
28: CLPGUI is intended to be used both for teaching purposes, and for
29: debugging and improving complex programs of realworld scale. It is
30: based on a client-server architecture for connecting the CLP process
31: to a Java-based GUI process. Communication by message passing provides
32: an open architecture which facilitates the reuse of graphical
33: components and the porting to different constraint programming
34: systems. Arbitrary constraints and goals can be posted incrementally
35: from the GUI.
36: %The level of granularity of the search tree is specified by
37: %annotations in the CLP program.
38: %The visualized search tree is a
39: %subtree of the SLD derivation tree with constraints.
40: We propose several dynamic 2D and 3D visualizations of the search tree
41: and of the evolution of finite domain variables. We argue that the 3D
42: representation of search trees proposed in this paper provides the most
43: appropriate visualization of large search trees. We describe the
44: current implementation of the annotations and of the interactive
45: execution model in GNU-Prolog, and report some evaluation results.
46: \end{abstract}
47:
48: %\nocite*
49:
50: \section{Introduction}
51:
52: Several tools for visualizing the execution of constraint programs
53: have been developed in the last few years.
54: These tools have been found very useful
55: for debugging and improving
56: constraint programs, and for teaching constraint programming.
57: One can distinguish:
58: \begin{itemize}
59: \item {\em post-mortem visualization} tools, these tools are used after execution
60: of the program, the program is annotated with specifications of the information to trace.
61: This approach is implemented for example in the CHIP or CIAO systems, it allows using a wide variety of
62: viewers, including both application oriented tools \cite{SCDFNT00discipl},
63: and generic tools, for visualizing the search tree \cite{CH00discipl,SA00discipl}, finite domain variables \cite{CH00discipl2},
64: or constraint propagation \cite{SABB00discipl}.
65: \item {\em dynamic visualization} tools, these tools are connected to the constraint programming interpreter
66: and realize a visualization on-line, possibly with animations \cite{GB00discipl}. This approach is implemented in
67: Grace tool \cite{Meier95cp} for finite domains visualization, and in OPL studio \cite{BGP01wlpe}
68: for search tree and constraint propagation visualization.
69: \item {\em dynamic visualization and control} tools which allow interaction
70: with a CLP process through different visualizations. One example is the Oz-Explorer system \cite{Schulte97cp}
71: where it is possible to jump to any previously encountered state by simply clicking on a node of the search tree,
72: and restart computation from that state. User-guided search is implemented in Oz-Explorer using the first-class computation spaces of Oz.
73: Recomputation is used to trade space for time in Oz-Explorer, and similarly in OPL studio \cite{BGP01wlpe},
74: the state restoration mechanisms in tree search are described in \cite{CHK01cp}.
75: \end{itemize}
76:
77: In this paper we propose to push forwards these ideas
78: towards an open architecture for connecting a CLP process
79: with dynamic visualization and control tools.
80: To our knowledge, the visualization of search trees in three dimensions has not been much investigated.
81: We argue that the 3D representation of search trees proposed in this paper
82: provides the most appropriate visualization of large search trees.
83:
84: Our ambition is not to realize an {\em ad hoc} tool limited to a particular
85: constraint programming system, namely GNU-Prolog \cite{Diaz01gprolog}, but a generic tool which can be ported
86: to other constraint programming systems.
87: The main reason for this is that a wide variety of viewers can be useful for debugging
88: constraint programs and it is possible in this way to share developments.
89: Our approach relies on the generic trace format which is defined in the OaDymPPac consortium \cite{OADymPPaC}
90: for post-mortem analysis.
91: We propose to extend this format with a similar generic format for control, and to use these formats
92: for connecting on-line the CLP process to the GUI process.
93: Our implementation of CLPGUI \cite{Fages01clpgui} in GNU-Prolog and Java is depicted in Figure \ref{schema}.
94:
95: \begin{figure}[htb]
96: \begin{center}
97: \epsfig{file=schema.ps, width=12.5cm}
98: \end{center}
99: \caption{Information flow for dynamic visualization in CLPGUI.}\label{schema}
100: \end{figure}
101: In Section \ref{console} of this paper, we describe the client-server architecture of CLPGUI and the user console
102: which facilitates the establishment of a connection with a CLP server, and controls the execution of the CLP program.
103: Section \ref{annotations} describes annotations that can be added to a CLP program,
104: in order to give an external name to finite domain variables,
105: to create buttons for posting constraints or goals from the CLPGUI console,
106: and to define the level of granularity of the search tree which will be visualized.
107: Section \ref{finitedomains} presents a dynamic 3D viewer for visualizing the evolution of finite domains
108: variables over time.
109: Section \ref{searchtree} describes the representation of the explored search space
110: by partial CSLD derivation trees, presents different visualizations with 2D and 3D viewers,
111: and discusses their use in CLPGUI.
112: Then in Section \ref{02/implementation} we discuss the implementation of the interactive execution model
113: and of the annotations, using the global variables of GNU-Prolog.
114: Finally we provide some evaluation results, and conclude on the current limitations of the system and
115: on some perspectives for future work.
116:
117: \section{Client-Server Architecture}\label{console}
118:
119:
120: \begin{figure}[htb]
121: \begin{center}
122: \epsfig{file=consoleCLPGUI.ps, width=12cm}
123: \caption{CLPGUI console.}\label{consoleCLPGUI}
124: \end{center}
125: \end{figure}
126: The graphical user interface of CLPGUI is a Java application
127: connected by sockets as a client to a server which executes CLP goals.
128: Both processes can run on different machines and communicate over the network.
129: This has been experienced with CLPGUI for visualizing the execution of CLP programs on a Workbench of
130: Virtual Reality.
131: The choice of the Java language for implementing the GUI is motivated by several reasons:
132: \begin{itemize}
133: \item its object-orientation, all 3D viewers presented in the following sections inherit from a single
134: class for moving and projecting 3D figures;
135: \item the encapsulation of events handling, that is preponderant in dynamic visualization;
136: \item the threaded execution, which is mandatory for implementing communication with the CLP process;
137: \item its wide availability.
138: \end{itemize}
139: For efficiency reasons, we did not use the Java-3D library for the viewers presented in this paper,
140: as they can directly benefit from {\em ad hoc} optimizations that speed-up their incremental display.
141: Nevertheless the architecture can support the use of the powerful Java-3D library
142: for developing complex application-oriented viewers.
143:
144: During initialization, the CLP server starts an interpreter of the command lines
145: received on the socket. The command lines may contain any CLP goal.
146: The GUI Java client opens a graphical console such as the one in Figure \ref{consoleCLPGUI}.
147: That console is used for establishing a connection to the CLP server,
148: and for posting constraints or executing CLP goals.
149:
150: The CLP program may contain annotations for creating buttons for some
151: constraints or for some Prolog goals to execute in an interactive manner.
152: These buttons for posting constraints or Prolog goals then appear at the bottom in the CLPGUI console, see Figure \ref{consoleCLPGUI}.
153: A click on the button posts the constraint or executes the goal associated to the button.
154: Other arbitrary goals can be executed by entering them in a text field.
155: In addition, one button called ``backtrack'' continues the execution of the current goal up to the next success,
156: or, if there are no more success, returns to the state of the previous interaction.
157: Another button called ``backtrack interaction'' forces backtracking to the state of the previous interaction.
158: The menu bar of this console contains menus to select and activate the viewers of the search tree or of
159: the finite domain variables.
160:
161:
162: \section{Annotations}\label{annotations}
163:
164: The CLP program may contain annotations for giving an external name to CLP(FD) variables,
165: for creating buttons for posting constraints or goals from the CLPGUI console,
166: and for marking the goals to visualize in the search tree.
167: The following predicates are part of the annotation library:
168: \begin{itemize}
169: \item {\tt varnames([V1,...,VN],[name1,...,nameN])} and {\tt varnames([V1,...,Vn])}
170: give an external name to a list of CLP variables.
171: These external names are used in the graphical user interface and for the communication by sockets.
172: \item {\tt button(goal)} creates a button in the GUI console for executing a goal or for posting a constraint.
173: \item {\tt bagof\_buttons(goal, call)} creates a bag of buttons for each successful instance of the second argument.
174: \item {\tt trace\_search(goal)} executes the goal and traces the execution of that goal, by creating nodes in the search tree.
175: The goals and constraints posted from the graphical console are always traced.
176: \item {\tt show\_domains} updates the visualization of the current state of FD variables.
177: \end{itemize}
178:
179: Annotations provide a simple mechanism for encapsulating communications towards the GUI process \cite{CH00discipl}.
180: The advantages of this abstraction are:
181: \begin{itemize}
182: \item the flexibility for defining different levels of granularity
183: concerning the information to visualize.
184: \item the easiness for making interactive already existing programs,
185: \item the portability of the GUI to other constraint programming systems,
186: as all communications with the GUI are encapsulated in the implementation of annotation predicates.
187: \end{itemize}
188: The limitations of annotations are well-known in standard programming environments:
189: they may be difficult to maintain in large programs. In that case, one solution is to automatically
190: generate annotations with a graphical editor of the program source, where spy points and trace options can be specified.
191: Nevertheless, one peculiarity of constraint logic programming is the conciseness of programs.
192: CLP(FD) programs for solving combinatorial optimization problems on real-size data
193: may compute with a huge amount of constraints and variables, but the program source for handling
194: constraints and defining complex search strategy usually remains relatively concise.
195: Therefore in this context, the proposed annotations appear as a satisfactory solution.
196:
197: In many CLP systems however, the heuristic labeling procedures are built-in,
198: and cannot be precisely traced with a simple annotation.
199: In these cases, the annotations have to rely on the tracing facilities of the CLP system
200: in order to extract, and communicate to the GUI, the relevant information.
201: A simpler solution is to program the labeling heuristics in the host language,
202: for making available in the host language the information coming from the constraint solvers
203: that is relevant to the search heuristics.
204: In that case, the effect of the search strategy can be visualized at different levels of granularity.
205: In its simplest form, a predicate for tracing a labeling procedure can be defined
206: with a {\tt trace\_search} annotation as follows:
207: {\small
208: \begin{verbatim}
209: trace_labeling([]).
210: trace_labeling([X|L]):- trace_search(fd_labeling(X)), trace_labeling(L).
211: \end{verbatim}} It is worth noting that even if the search strategy is implemented with a meta-interpreter,
212: or constraint posting is combined with labeling,
213: the relevant goals of the execution can still be traced with annotations.
214:
215: The same difficulty arises for tracing internal constraint propagation steps.
216: This is not possible without access to the wakening events of the constraint solver.
217: The annotations for tracing constraint propagation steps have thus to rely
218: on the tracing facilities of the solver in order to extract and communicate constraint wakening events.
219:
220: \begin{example}\label{send.pl}
221: The following annotated GNU-Prolog program solves the well known
222: SEND+MORE=MONEY puzzle in an interactive manner,
223: by creating buttons for posting the constraints and for trying two labeling goals in this example:
224: {\small
225: \begin{verbatim}
226: sendmore(L):-
227: L=[S,E,N,D,M,O,R,Y],
228: varnames(L,['S','E','N','D','M','O','R','Y']),
229: fd_domain(L,0,9),
230: button(fd_domain([S,M],1,9)),
231: button(1000*S+100*E+10*N+D + 1000*M+100*O+10*R+E
232: #= 10000*M+1000*O+100*N+10*E+Y),
233: button(fd_all_different(L)),
234: button(trace_labeling(L)),
235: reverse(L,L2),
236: button(trace_labeling(L2)).
237: \end{verbatim}
238: }
239: This program generates the console in Figure \ref{consoleCLPGUI}.
240: The evolution of the finite domain variables over time, after the posting of constraints and of the
241: first labeling goal, is depicted in Figure \ref{domainsCLPGUI}.
242: The visualization of the search tree for obtaining all solutions under the first
243: labeling goal, and then under the second labeling goal executed after a backtracking command,
244: is depicted in Figure \ref{sendtreeCLPGUI}.
245: Under the first ordering, the labeling is deterministic.
246: Under the second ordering, few backtracking steps occur on variable {\tt Y} when searching for other solutions.
247: Note that other labeling heuristics can be tried directly from the console.
248: On such pedagogical examples, the advantage of immediately visualizing the effect
249: of posting a constraint or trying a labeling, is clear for teaching purposes.
250: \end{example}
251:
252: \begin{figure}[htb]
253: \begin{center}
254: %\epsfig{file=sendtreeCLPGUI.ps, width=8cm, height=5cm}
255: epsfig{file=sendtreeCLPGUI.ps, width=8cm, height=5cm}
256: \end{center}
257: \caption{Search trees with two labeling orderings in the puzzle SEND+MORE=MONEY.}\label{sendtreeCLPGUI}
258: \end{figure}
259:
260:
261: \begin{example}\label{queens.pl}
262: The following program solves the N queens problem
263: by creating buttons for posting the constraints ({\tt safe} predicate)
264: and labeling goals for each variable ({\tt fd\_labeling} predicate) and for all variables ({\tt trace\_labeling} predicate).
265: {\small
266: \begin{verbatim}
267: queens(N,L):-
268: length(L,N),
269: varnames(L),
270: fd_domain(L,1,N),
271: button(safe(L)),
272: bagof_buttons(fd_labeling(X),member(X,L)),
273: button(trace_labeling(L)).
274: \end{verbatim}
275: }
276: Three visualizations of the search tree for the 8 queens problem are depicted in Figures \ref{arbre2DCLPGUI}, \ref{arbre3DCLPGUI}
277: and \ref{treemapCLPGUI}.
278: %The evolution of finite domain variables on the 100 queens problem is depicted in Figure \ref{domains100queens}.
279: %TIMING ...
280: \end{example}
281:
282:
283: \section{3D Views of Finite Domain Variables}\label{finitedomains}
284: \begin{figure}[htb]
285: \begin{center}
286: %\epsfig{file=domainsCLPGUI.ps, width=12cm, height=8cm}
287: epsfig{file=domainsCLPGUI.ps, width=12cm, height=8cm}
288: \end{center}
289: \caption{Dynamic 3D view of finite domain variables in the puzzle SEND+MORE=MONEY.}\label{domainsCLPGUI}
290: \end{figure}
291:
292: The evolution of finite domain variables is visualized
293: in a three dimensional graph variable-domain-time, as proposed in the VIFID/TRIFID tool \cite{SCH99pac}.
294: Here the visualization is dynamic, the Java process reads the stream of finite domains information
295: and paints the figure in an incremental manner.
296: Domains are depicted by their size on the vertical axis, see Figure \ref{domainsCLPGUI}.
297: According to options, that can be set in the CLP program or in the GUI,
298: only the size, the interval or the complete domain of variables is visualized.
299: But in any case only the sizes of the domains are memorized, therefore the extra information is
300: lost when the figure is repaint.
301: The time axis traces the interactions (i.e.~the posting of constraints in the example), and the execution of traced goals
302: (i.e.~the labeling in the example). This view shows that the posting of constraints instantiate variables $S,M,O$
303: and that the first labeling step on variable {\tt E} in fact instantiates
304: all variables by constraint propagation.
305: An option determines whether backtracked states are traced or erased.
306:
307: The figure can be moved, zoomed and rotated.
308: For efficiency reasons, the rotations are limited to a quadrant of a sphere
309: which is not a real limitation for the user.
310: In this way the visible faces are efficiently determined and
311: the figure can be drawn incrementally.
312: %This explains that the animation for reaching the first solution of the 100-queens problem
313: %takes ???.
314:
315: Extra information on variables and executed goals can be obtained by moving the mouse
316: on the position of a variable or on a time position.
317:
318: The 3D dynamic view of finite domain variables evolution is very useful for teaching constraint programming.
319: The effect of constraints is immediately seen and many strategies can be tried step by step.
320: On large set of variables, the 3D view of domains can still be useful to get a view of the pruning power of
321: different constraint modelings, and of the efficiency of different search heuristics, by comparing
322: the general shape of domain reductions.
323:
324: \section{2D and 3D Views of the Search Tree}\label{searchtree}
325: \subsection{Partial CSLD derivation trees}
326:
327: \begin{figure}[htb]
328: \begin{center}
329: %\epsfig{file=arbre2DCLPGUI.ps, width=12cm, height=8cm}
330: epsfig{file=arbre2DCLPGUI.ps, width=12cm, height=8cm}
331: \end{center}
332: \caption{2D view of the search tree in the 8-queens problem.}\label{arbre2DCLPGUI}
333: \end{figure}
334:
335: \begin{figure}[htb]
336: \begin{center}
337: %\epsfig{file=arbre3DCLPGUI.ps, width=12cm, height=8cm}
338: epsfig{file=arbre3DCLPGUI.ps, width=12cm, height=8cm}
339: \end{center}
340: \caption{3D of the search tree in the 8-queens problem.}\label{arbre3DCLPGUI}
341: \end{figure}
342:
343: \begin{figure}[htb]
344: \begin{center}
345: %\epsfig{file=treemapCLPGUI.ps, width=12cm, height=8cm}
346: epsfig{file=treemapCLPGUI.ps, width=12cm, height=8cm}
347: \end{center}
348: \caption{Treemap representation obtained by rotation of the 3D view.}\label{treemapCLPGUI}
349: \end{figure}
350:
351: The search tree considered in CLPGUI is a labeled tree defined as follows:
352: \begin{itemize}
353: \item a node is introduced for each call to a traced goal (called a {\em call node}),
354: and for each success to a traced goal (called a {\em success node}),
355: \item the label of a call node is the called goal,
356: \item the label of a success node is the list of named variables with their value,
357: \item the arcs correspond to the operational CLP transitions.
358: \end{itemize}
359:
360: This tree is a subtree of the CSLD derivation tree \cite{JM94jlp}.
361: It is thus a quite natural representation of the search tree for describing CLP program execution.
362: A branch represents a conjunction, and the different successors of a node represents a disjunction.
363: A success node may have several successors if
364: there is an untraced non-deterministic goal which is executed after the success,
365: and before the next call to a traced goal.
366: This is the main reason why success nodes are introduced in partial CSLD trees.
367: In this way, the non-determinism due to untraced goals cannot be confused with the
368: non-determinism of traced goals.
369:
370: One disadvantage of CSLD trees is that in the case of deterministic programs
371: they are threadlike and thus space consuming in their standard representation.
372: AND-OR trees provide a more compact representation, as the threadlike parts of the CSLD tree
373: are compacted in the successors of a single AND-node.
374: For this reason, in the context of logic programs where most predicates are deterministic,
375: AND-OR trees, and their variant AORTA diagrams which
376: indicate the status of resolution of the goals,
377: have been preferred \cite{EB88jlp}.
378: Nevertheless in the context of constraint logic programming over finite domains,
379: the situation is quite different. The search tree to visualize is usually focused
380: on the labeling predicates, or more generally on the branching procedure,
381: which is highly non-deterministic (at least during debugging). The representation of the deterministic part
382: of the search tree with threadlike structures provides an immediate visualization
383: of the pruning power of constraints.
384:
385: A naive solution for tracing constraint propagation steps in this approach is to
386: add deterministic nodes for tracing constraint wakening events.
387: For space limitation reasons, it is preferable however to aggregate constraint propagation information
388: to the nodes of the search tree. This is proposed in the ``Christmas trees'' of OPL studio \cite{BGP01wlpe}.
389:
390: For search engines not based on backtracking, it is worth noting that
391: a partial CSLD derivation tree can still provide a valid representation of the explored search space,
392: as long as the explored states can be defined by their relation
393: to some ancestor states. A formalization of an interactive constraint solver
394: by transformations of CSLD derivation trees was done in \cite{FFS95iclp}.
395:
396: \subsection{Visualization}
397: Once the search tree is formally defined, it can still be visualized in many ways,
398: and in some cases it can be interesting to use several visualizations at the same time.
399: We have currently implemented several two-dimensional and three-dimensional viewers,
400: but many more representations could be imagined and fruitfully used.
401:
402: In all the following representations, the labels of the nodes are visualized when the mouse is moved on them,
403: and an option makes all nodes visible.
404: The successes are materialized by a red cross.
405: Each view can be moved, zoomed and rotated.
406:
407:
408: Figure \ref{sendtreeCLPGUI} uses a standard 2D representation of the search tree in a fixed width.
409: Figure \ref{arbre2DCLPGUI} uses a dynamic 2D representation of the tree with a fixed spacing between leaves.
410: This representation of the tree can be drawn incrementally and is thus appropriate
411: for the dynamic visualization of large trees.
412:
413: To our knowledge, the 3D visualization of search trees has not been much investigated.
414: Figure \ref{arbre3DCLPGUI} shows a somewhat original 3D representation of the search tree with alternating planes of successors.
415: One advantage of this 3D representation is that it is relatively compact,
416: it helps visualizing rather large trees by playing with rotations, see Figure \ref{bridgeCLPGUI} for another example.
417: Our experience is that the 3D view is the most appropriate view to apprehend the shape
418: of large search trees.
419:
420: It is interesting to note that one obtains a treemap representation of the tree
421: by rotation of the 3D alternate tree up to its vertical projection, as done in Figure \ref{treemapCLPGUI}.
422: Treemap representations (with colors for aggregating information)
423: are known to be particularly efficient to represent very large data \cite{Schneiderman92tog}
424: and to visualize complex phenomenons such as correlations, patterns or symmetries.
425:
426: The interaction allowed in these views to restore a state is currently
427: limited to user-guided backtracking and recomputation.
428: The automatic recomputation of any state of the tree as described in \cite{BGP01wlpe,CHK01cp,Schulte97cp}
429: is currently not implemented.
430:
431: \subsection{Branch and bound optimization}\label{optimization}
432:
433:
434: \begin{figure}[htb]
435: \begin{center}
436: %\epsfig{file=bridge2.ps, width=12cm, height=8cm}
437: epsfig{file=bridge2.ps, width=12cm, height=8cm}
438: \end{center}
439: \caption{3D view of the search tree in the bridge problem (3905 call nodes).}\label{bridgeCLPGUI}
440: \end{figure}
441:
442: The branch and bound procedure is widely used in constraint programming
443: to solve optimization problems. Branch and bound optimization develops search trees
444: in two parts. The first part corresponds to the enumeration of solutions with
445: decreasing costs (for minimization problems). The second part exhausts the search space
446: to show that there does not exist a better solution than the last solution found.
447: The second part of the search tree constitutes the proof of optimality.
448:
449: Figure \ref{bridgeCLPGUI} shows the search tree for the bridge problem \cite{VH89mit},
450: a medium size job-shop scheduling problem. The first descent corresponds to the search of the first solution
451: of cost 108. It contains 78 call nodes.
452: The second descent (after some hesitation) corresponds to the search of the optimal solution of cost 104.
453: It contains 99 call nodes. The bottom part of the tree contains 3728 call nodes and corresponds to the proof of optimality.
454: The 3D view is the most appropriate view of this search tree. It can be moved and rotated without difficulty.
455:
456: \section{Implementation}\label{02/implementation}
457:
458: \subsection{Interactive Execution Model for CLP}
459:
460: The interactive execution model of the CLP process derives from
461: a more general model for adding and removing constraints and goals described
462: in \cite{FFS95iclp}. In CLPGUI, constraints and goals can only be added to the current goal,
463: the removing of constraints or goals occurs by backtracking.
464: It is therefore possible on a success of the current goal:
465: \begin{itemize}
466: \item
467: to add constraints or any goals to the current goal
468: and continue resolution,
469: \item to backtrack to the next success (command ``backtrack'' of Section \ref{console}),
470: \item or to backtrack to the last interaction (command ``backtrack interaction'').
471: \end{itemize}
472: It is worth noting that such a top level is in fact very appropriate for standard Prolog systems,
473: where the capability of adding goals on a success of the current goal, and continue resolution,
474: is usually missing.
475:
476: Our current implementation uses the global variables of GNU-Prolog \cite{Diaz01gprolog}
477: to memorize global information, such as input and output sockets, variable names,
478: and information used for backtracking.
479: Global variables make it possible to avoid adding parameters to many predicates and lead to a simple
480: implementation of annotations.
481:
482:
483: \subsection{Communication messages}
484:
485: In this section we describe the communication messages which are transmitted between
486: the CLP process and the GUI process.
487: The CLP process produces the trace information specified by the annotations in the CLP program,
488: or asked from the GUI.
489: The messages emitted from the CLP to the GUI are the following:
490: \begin{itemize}
491: \item {\tt <variables ...>} sends the list of FD variable names
492: \item {\tt <button G>} asks the GUI to create a button for posting the constraint or goal {\tt G}
493: \item {\tt <undo button G>} indicates backtracking on the creation of a button for {\tt G}
494: \item {\tt <node G>} traces a call to goal {\tt G}
495: \item {\tt <undo node G>} traces backtracking on the call to {\tt G}
496: \item {\tt <child G>} traces a success to {\tt G}
497: \item {\tt <undo child G>} traces backtracking on the success to {\tt G}
498: \item {\tt <undo goal G>} indicates backtracking on the call to goal {\tt G}
499: \item {\tt <domainSizes ...>} sends the domain sizes of FD variables
500: \item {\tt <domainIntervals ...>} sends the current intervals of FD variables
501: \item {\tt <domainValues ...>} sends the current finite domains of FD variables
502: \item {\tt <undo domainValues>, <undo domainIntervals>, <undo domainSizes>} warns the GUI that
503: the finite domain variables are updated by backtracking.
504: \item {\tt <success>} indicates that the current derivation is a success
505: \item {\tt <clear>} indicates return to top level.
506: \end{itemize}
507:
508: In the other direction, the messages emitted from the GUI to the CLP process are the following:
509: \begin{itemize}
510: \item {\tt <showSize>, <showInterval>, <showValues>} sets the information on finite domains that need be sent
511: \item {\tt <execute G>} asks to post constraint {\tt G} or execute goal {\tt G}
512: \item {\tt <backtrack>} asks backtracking to the next success
513: \item {\tt <backtrackInteraction>} forces backtracking to the last interaction
514: \item {\tt <clear>} asks to abort the current execution.
515: \end{itemize}
516:
517: The portability of CLPGUI to a new constraint programming system is determined by the ability of
518: the constraint programming system to produce and interpret these communication messages.
519: The messages of the first list are produced by the predicates of
520: annotation library described in Section \ref{annotations}.
521: The messages in the second list are interpreted by the interactive execution model described in the previous section.
522:
523: \section{Evaluation}
524:
525: Our experience of using CLPGUI for teaching constraint programming has been very positive.
526: The dynamic visualization of CLP programs really speeds-up the process of learning
527: the basic concepts of domain filtering, constraint propagation and search trees.
528: CLPGUI has also been fruitfully used to visualize the search tree of CLP(R) programs.
529:
530: On real-size data, CLPGUI has shown satisfactory performance figures.
531: We report in this section the timings on a Pentium III 600 MHz processor under Linux.
532: GNU-Prolog solves the bridge problem mentioned in Section \ref{optimization}
533: in 100 ms, including the proof of optimality.
534: The solving together with the visualization of the search tree with 3905 call nodes
535: takes 470 ms with CLPGUI.
536: This overhead is due to the communication of messages by sockets.
537: The overhead was reduced from 2600 ms to 470 ms by optimizing socket calls and by
538: using simple data compression techniques for communication.
539: Moreover, the drawing of the tree is immediate and the figure can be moved and rotated
540: without difficulty.
541:
542: \section{Conclusion and future work}\label{conclusion}
543:
544: We have described an open architecture for visualizing and controlling the execution of
545: constraint logic programs. Communication by sockets between the CLP process and the GUI process
546: has proved efficient enough for dynamic visualization and interactions.
547: An important reduction of the overhead was obtained by optimizing socket calls and by
548: using simple data compression techniques for communication.
549:
550: CLPGUI supports the use of different viewers.
551: Our experience has shown that
552: a somewhat original 3D visualization of the search tree proposed in the paper, is often the preferred view
553: to apprehend the shape of large search trees, as it is very compact.
554: More work is needed however to parametrize the different viewers
555: and invent novel visualizations of complex data.
556: In this respect the flexibility of the architecture makes it possible to connect CLPGUI
557: to external generic viewers, or to use powerful libraries like Java 3D
558: to develop application-oriented viewers.
559:
560: The most obvious limitation of our current implementation of CLPGUI is
561: the absence of connection to a system for tracing constraint propagation,
562: simply because such a tracer does not exist yet for GNU-Prolog.
563: Nevertheless a generic trace format for finite domain constraint solvers has been defined in
564: the OaDymPpac consortium \cite{OADymPPaC},
565: and we plan to use this format in future versions of CLPGUI.
566:
567: Finally, CLPGUI is not a visual programming tool as far as the capabilities of defining goals from the GUI
568: are extremely rudimentary. Nevertheless the proposed architecture can support this kind of
569: extension by adding the capability to define constraints and goals graphically, that is certainly worth investigating.
570:
571: \subsubsection*{Acknowledgements.}{\small
572: I would like to thank all members of the OaDymPpac RNTL project
573: of the French Ministry of Research, and especially
574: Abderrahmane Aggoun, Thomas Baudel, Pierre Deransart, Jean-Daniel Fekete, Ludovic Langevine and Mohammad Gonhiem
575: for interesting discussions on this topic.
576: I am grateful also to Anupam Agarwal for optimizing communication by sockets,
577: and to Jean-Michel Leconte for his preliminary work along these lines
578: on the workbench of virtual reality at INRIA.}
579:
580: %\bibliography{biblio2}
581: %
582: %\end{document}
583:
584: \begin{thebibliography}{10}
585:
586: \bibitem{BGP01wlpe}
587: C.~Bracchi, C.~Gefflot, and F.~Paulin.
588: \newblock Combining propagation information and search-tree visualization using
589: {OPL} studio.
590: \newblock In A.~Kusalik, M.~Ducass\'e, and G.~Puebla, editors, {\em Proceedings
591: of WLPE'01}, pages 27--39, Cyprus, D\'ecembre 2001. Cyprus University.
592:
593: \bibitem{CH00discipl2}
594: M.~Carro and M.~Hermenegildo.
595: \newblock Tools for constraint visualization: The vifid/trifid tool.
596: \newblock In {\em \cite{DMH99discipl}}, pages 253--272. Springer Verlag, 2000.
597:
598: \bibitem{CH00discipl}
599: M.~Carro and M.~Hermenegildo.
600: \newblock Tools for search tree visualization: The apt tool.
601: \newblock In {\em \cite{DMH99discipl}}, pages 237--252. Springer Verlag, 2000.
602:
603: \bibitem{CHK01cp}
604: Chiu~Wo Choi, M.~Henz, and Ka~Boon Ng.
605: \newblock Components for state restoration in tree search.
606: \newblock In {\em Proceedings of the Seventh International Conference on
607: Principles and Practice of Constraint Programming ({\sc CP}'01)}, Lecture
608: Notes in Computer Science, pages 240--255, Cyprus, November 2001.
609: Springer-Verlag.
610:
611: \bibitem{DMH99discipl}
612: Pierre Deransart, Jan Ma{\l}uszy\`nski, and Manuel Hermenegildo, editors.
613: \newblock {\em Analysis and Visualization Tools for Constraint Programming}.
614: \newblock Springer Verlag, 2000.
615:
616: \bibitem{Diaz01gprolog}
617: D.~Diaz.
618: \newblock Gnu-prolog user's manual, 2001.
619: \newblock {\tt http://gprolog.inria.fr}.
620:
621: \bibitem{EB88jlp}
622: M.~Eisenstadt and M.~Brayshaw.
623: \newblock The transparent prolog machine: an execution model and graphical
624: debugger for logic programming.
625: \newblock {\em Journal of Logic Programming}, 5(4):277--342, 1988.
626:
627: \bibitem{Fages01clpgui}
628: F.~Fages.
629: \newblock Clpgui: A graphical user interface in java for constraint logic
630: programming over finite domains, user's manual, 2001.
631: \newblock {\tt http://contraintes.inria.fr/$\sim$fages/CLPGUI}.
632:
633: \bibitem{FFS95iclp}
634: F.~Fages, J.~Fowler, and T.~Sola.
635: \newblock A reactive constraint logic programming scheme.
636: \newblock In Leon Sterling, editor, {\em International Conference on Logic
637: Programming, ICLP'95}, Tokyo, 1995. MIT Press.
638:
639: \bibitem{GB00discipl}
640: F.~Goualard and F.~Benhamou.
641: \newblock Debugging {C}onstraint {P}rograms by {S}tore {I}nspection.
642: \newblock In Deransart et~al. \cite{DMH99discipl}, chapter~11.
643:
644: \bibitem{VH89mit}
645: P.~Van Hentenryck.
646: \newblock {\em Constraint satisfaction in Logic Programming}.
647: \newblock MIT Press, 1989.
648:
649: \bibitem{JM94jlp}
650: J.~Jaffar and M.~Maher.
651: \newblock Constraint logic programming: A survey.
652: \newblock {\em Journal of Logic Programming}, 19,20:503--581, 1994.
653:
654: \bibitem{Meier95cp}
655: M.~Meier.
656: \newblock Debugging constraint programs.
657: \newblock In {\em Proceedings of the First International Conference on
658: Principles and Practice of Constraint Programming ({\sc CP}'95)}, number 976
659: in Lecture Notes in Computer Science, pages 204--221, Cassis, France, 1995.
660: Springer-Verlag.
661:
662: \bibitem{OADymPPaC}
663: OADymPPaC.
664: \newblock Tools for dynamic analysis and debugging of constraint programs.
665: \newblock A French RNTL project. http://contraintes.inria.fr/OADymPPaC.
666:
667: \bibitem{Schneiderman92tog}
668: B.~Schneiderman.
669: \newblock Tree visualization with treemaps: 2d space filling approach.
670: \newblock {\em ACM Transactions on Graphics TOG'92}, 11(1), January 1992.
671:
672: \bibitem{Schulte97cp}
673: C.~Schulte.
674: \newblock Oz {E}xplorer: {A} {V}isual {C}onstraint {P}rogramming {T}ool.
675: \newblock In {\em Proceedings of the Fourteenth International Conference on
676: Logic Programming ({\sc Iclp}'97)}, pages 286--300, Leuven, juin 1997. The
677: MIT Press.
678:
679: \bibitem{SA00discipl}
680: H.~Simonis and A.~Aggoun.
681: \newblock Search-{T}ree {V}isualisation.
682: \newblock In Deransart et~al. \cite{DMH99discipl}, chapter~7.
683:
684: \bibitem{SABB00discipl}
685: H.~Simonis, A.~Aggoun, N.~Beldiceanu, and E.~Bourreau.
686: \newblock Complex constraint abstraction~: Global constraint visualisation.
687: \newblock In Deransart et~al. \cite{DMH99discipl}, chapter~12.
688:
689: \bibitem{SCDFNT00discipl}
690: H.~Simonis, T.~Cornelissen, V.~Dumortier, G.~Fabris, F.~Nanni, and
691: A.~Tirabosco.
692: \newblock Using constraint visualisation tool.
693: \newblock In Deransart et~al. \cite{DMH99discipl}, chapter~13.
694:
695: \bibitem{SCH99pac}
696: G.~Smedb\"ack, M.~Carro, and M.~Hermenegildo.
697: \newblock Interfacing prolog and vrml and its application to constraint
698: visualization.
699: \newblock In {\em The Practical Application of Constraint Technologies and
700: Logic programming}, pages 453--471. The Practical Application Company, 1999.
701:
702: \end{thebibliography}
703:
704:
705: \end{document}
706: