Latest revision as of 03:07, 17 December 2007

This page is to plan the agenda for the meeting we plan to have with Jocelyn when he visits ETH in Zurich.

Involved parties:

• Jocelyn
• Bertrand
• Andreas
• Stefan
• Arno

Organisation

Date

• arrival: tuesday 18th of December, Zurich HB either at 13h56 or 12h56
• departure: wednesday around 14h..
• tuesday night, hotel, or hosted by ETH people (but not in the streets)

Meetings

• tuesday: 14:00 -> 15:00 .. about build process, ... (Arno)
• tuesday: 15:00 -> ... : debugger related points (Andreas, Arno)
• wednesday: morning: continuation of debugger related points (Andreas, Arno starting at 10)
• wednesday: afternoon .. Jocelyn will be on train, and ETH can do a final meeting to "compute" all the information ;)

References

• http://dev.eiffel.com/CddBranch
• http://se.ethz.ch/people/leitner/publications/cdd_leitner_esec_fse_2007.pdf
• http://portal.acm.org/citation.cfm?id=1082983.1083251

Please complete the following list with your items

• General dicussion about the CDD idea
  • Where should it go?
  • What are the biggest obstacles?
  • CDD debuggers needs
    • How to best do fg debuging of test cases
    • How to best do bg extraction of test cases
      • Is our approach of using the debugger in console mode the right one?

Jocelyn: For now, there is GUI debugger, TTY debugger, and I guess CDD debugger, 
 but you are not obliged to be in "console" mode (one can imagine a HTTP debugger, or even a silent debugger)

Andreas: The CDD test case extractor must be given an extractor 
 (it doesn't care whether it gets the gui one or the console one). 

• • • • Is it okay to retrieve the whole application state through ABSTRACT_DEBUG_VALUE's? Seems to become really slow with big applications.

Jocelyn: What do you mean by retrieving the whole application state ?
however, in the debugger, there are currently too many object representations: DUMP_VALUE, DEBUGGED_OBJECT, ABSTRACT_DEBUG_VALUE ...  I feel this is too much, and I'd like to find to redesign this part. However, ABSTRACT_DEBUG_VALUE is more likely to be the more stable interface for the future. So it is best sticking with it for now.

• • • Console debugger crashes (Arno can you provide details please)
      • TTY debugger seems to have problems when exception in infix features occurs -> not possible to use tty menu anymore
      • Sometimes combination of other tty functions (e.g. displaying all classes in system)

Jocelyn: TTY debugger is not perfect (not enough time to work on it), what should be done is
1) change the "menu like control" by a "shell like control"
2) having the debugger controller in a separate thread, this way we could support "interrupt" and so on
3) ... many improvement, and support all the debugger functionality

• ok, then do it :-). No, seriously, the question is if and how we can improve the tty debugger just to enable system level tests for our cdd
  • Console Menu (again Arno)
    • Multiple debuggers at the same time (large long term issue)

Jocelyn: That might be possible, but this won't be that easy for now, however, 
 I have been changing progressively the design to be more flexible, 
 and to allow that in the future. Maybe ISE could plan this for 6.3 with other major design changes.

• • • Prestate capturing
      • How can we use the debugger for it
        • old values

Jocelyn: for now, old values are not yet fully supported by the debugger, maybe for 6.3 ...

• • • • • invariants

Jocelyn: we hope to improve that part related to invariant soon, since for now the debugger is not helpful with invariant violation/

• • • • How can we use ES capture and "Review" for it?

Jocelyn: for what ?

• • Build system needs
    • How to do it properly on Windows? (Stefan, please provide details here)
    • (by Stefan) well, i am getting used to it. The problems with the updated build scripts is that they might not be compatible with 6.0, which cdd is based on? (i admit i did not try)

Jocelyn: Those days, I am integrating+updating works from es-make team (Bernd and others) into the trunk, 
 this way it should be much more easier to build the EiffelStudio tools. Still in progress.
By the way, I won't commit anything for 6.0, it would be better for you to switch to 6.1 (or trunk .. 6.2) regarding building process

• • Guided tour through debugger

Jocelyn: do you mean ... a tutorial how to use the debugger ? or you want me to present how the debugger is designed during the meeting ?

• • Guided tour through build system

Jocelyn: same question as above

• • Unable to debug ES with ES (only Stefan and Andreas). Maybe Jocelyn can have a quick look.

Jocelyn: it is definitally possible on Windows, and I used it on linux too, but maybe there are some issues with pipe sharing ... (internal to the Eiffel debugger)

• • Capture and Replay
    • Compare ES Capture and Replay and Sel. Capture and Replay

Jocelyn: ES provides "Execution Recording and Replay", or should I say "Review"

• • • What are strengths and weaknesses?
    • Can approaches be combined for mutal benefit?
    • Where to go from here?