M. Ducass#. Opium: An extendable trace analyser for Prolog. Journal of Logic programming, 39:177223, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds).  Home/Search   Document Not in Database   Summary   Related Articles   Check

....debugging support in Morphine. This introduction lists potential users of Morphine and briefly describe its basic features. Morphine is an adaptation to Mercury of the Opium debugger which was designed for Prolog. A number of articles describe in detail the principles of Opium, see in particular [2, 4] 1 . An adaptation of Opium to C called coca is described in [3] 1.1 Why should you use Morphine If you think that simply stepping through execution traces is all you need, you should still try Morphine because with a handful of commands plus Prolog you can specify easily the very trace ....

....trial 6 month licence are available from http: www.ecrc.de eclipse eclipse.html NT n1234 12 Mireille Ducass, Erwan Jahier [Morphine] fget( module = not(printlist) fail. 1: 1 [1] call main(state( cpointer ) 2: 2 [2] call main3( state( cpointer ) 3: 3 [3] call main1( 4: 4 [4] call data( 5: 4 [4] exit data( 3, 1, 2] 6: 5 [4] call qsort( 3, 1, 2] 7: 5 [4] switch qsort( 3, 1, 2] s1] 8: 6 [5] call partition( 1, 2] 3, 9: 6 [5] switch partition( 1, 2] 3, s1] 10: 6 [5] then partition( 1, 2] 3, s1,c2,t] 11: 7 [6] call partition( 2] ....

[Article contains additional citation context not shown here]

M. Ducass'e. Opium: An extendable trace analyser for Prolog. The Journal of Logic programming, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds), Also Rapport Technique INRIA 3257.

No context found.

M. Ducass#. Opium: An extendable trace analyser for Prolog. Journal of Logic programming, 39:177223, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds).

....to pay the necessary price. A direct, and very important, consequence is that the trace model can be as rich as people want. Because the price of the richness will be paid only if the information is used. The bases of the analysis scheme were initially designed for the analysis of Prolog programs [5]. They had been extended in order to cope with the global variables of C [4] In this document, we extend them further to address the constraint store of constraint solvers, and we apply them to three constraint solving dedicated analyses. The first one gives a graphical view of the search tree ....

M. Ducass'e. Opium: An extendable trace analyser for Prolog. The Journal of Logic programming, 39:177--223, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds), Also Rapport Technique INRIA 3257.

....provides a precise but verbose image of the execution. It is sometimes stated that it should not be used in debuggers. Whether Byrd s trace is a proper output format for an end user may indeed be discussed. A trace, however, can be the basis of higher level tools as we have shown for debugging [13] or monitoring [16] In general, automated dynamic analysis needs an execution model to be based upon, and Byrd s box model is a good candidate for logic programming languages. As detailed by Tobermann and Beckstein [31] Prolog debugging systems have quite different interpretations of what ....

....that existing implementations of trace systems are correct with respect to a model specified in this kind of settings. We plan to do that with the Prolog tracer implementation described in [14] Once the tracer is validated, we can safely base dynamic analyses on it, as we have done for debugging [13] or monitoring [16] Kishon and al. on the other hand, aim at directly deriving the monitoring tools from the semantics. One advantage of our approach is that it can be used on top on existing systems whereas Kishon and al. rebuild the whole monitoring tools from scratch. 5.3 Deriving ....

M. Ducass'e. Opium: An extendable trace analyser for Prolog. Journal of Logic programming, 39, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds).

....are. Byrd s box model is often judged too low level and it is sometimes stated that it should not be used in debuggers. Whether Byrd s trace is a proper output format for an end user may indeed be discussed. A trace, however, can be the basis of automated tools, as we have shown for debugging [5] or monitoring [7] In general, automated dynamic analysis needs an execution model to be based upon and Byrd s box model is a good candidate for Prolog. Tobermann and Beckstein [12] have already proposed a formal specication 1 jahier, ducasse, ridoux irisa.fr www.irisa.fr lande c fl2000 ....

M. Ducass#. Opium: An extendable trace analyser for Prolog. The Journal of Logic programming, 39, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds).

....debugging support in OpiumM. This introduction lists potential users of Opium M and briefly describe its basic features. Opium M is an adaptation to Mercury of the Opium debugger which was designed for Prolog. A number of articles describe in detail the principles of Opium, see in particular [2, 4] 1 . An adaptation of Opium to C called coca is described in [3] 1.1 Why should you use Opium M If you think that simply stepping through execution traces is all you need, you should still try Opium M because with a handful of commands plus Prolog you can specify easily the very trace ....

....trial 6 month licence are available from http: www.ecrc.de eclipse eclipse.html PI n1234 12 Mireille Ducass e, Erwan Jahier [Opium M] fget( module = not(printlist) fail. 1: 1 [1] call main(state( cpointer ) 2: 2 [2] call main3( state( cpointer ) 3: 3 [3] call main1( 4: 4 [4] call data( 5: 4 [4] exit data( 3, 1, 2] 6: 5 [4] call qsort( 3, 1, 2] 7: 5 [4] switch qsort( 3, 1, 2] s1] 8: 6 [5] call partition( 1, 2] 3, 9: 6 [5] switch partition( 1, 2] 3, s1] 10: 6 [5] then partition( 1, 2] 3, s1,c2,t] 11: 7 [6] call partition( 2] ....

[Article contains additional citation context not shown here]

M. Ducass'e. Opium: An extendable trace analyser for Prolog. The Journal of Logic programming, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds), Also Rapport Technique INRIA 3257.

....are. Byrd s box model is often judged too low level and it is sometimes stated that it should not be used in debuggers. Whether Byrd s trace is a proper output format for an end user may indeed be discussed. A trace, however, can be the basis of automated tools, as we have shown for debugging [7] or monitoring [10] In general, automated dynamic analysis needs an execution 1 model to be based upon and Byrd s box model is a good candidate for Prolog. Tobermann and Beckstein [19] have already proposed a formal specification for Byrd s box model based on directed graphs. Their ....

M. Ducass'e. Opium: An extendable trace analyser for Prolog. Journal of Logic Programming, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds).

....seems acceptable to us. 3 Note that a Mercury program compiled in mode debug generates an executable that is bigger but not slower than the same program compiled without debugging information 7 Related work All the monitors presented in this article have first been implemented with Opium M [5, 6, 11], a Mercury trace analyzer designed for debugging that operates in coroutining with the analyzed program. However, debugging in general does not need to collect as much data as monitoring; our experience with Opium M is that it was a nice tool to easily prototype monitors, but performances were ....

M. Ducass'e. Opium: An extendable trace analyser for Prolog. Journal of Logic Programming, 1999. Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds).

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC