Re: [gobo-eiffel-develop] GEC debugger requirements

[Wolfgang J. <wj...@so...>]

Paul Cohen wrote:
> On 8/9/07, Howard Thomson <how...@di...> wrote:
>   
>> That is, the Eiffel system will be built with at least two threads, the
>> initial program entry point and first thread being a (possibly gui front
>> ended) debug and monitor thread which creates a second thread which starts in
>> the debugged system's root class and creation routine.
>>     
>
> I am strongly in favour of a CLI-based debugger. GUI frontends can
> later be added. Actually I would write a debugger API (.dll/.so) to
> ensure that any type of UI can be added later.
>
>   
>> Are you doing any development work yourself ?
>>     
>
> Not in Gobo. Due to my personal situation I just don't have that much
> time for spare time projects.
>
> On 8/9/07, Wolfgang Jansen <wj...@so...> wrote:
>   
>> Two or three weeks ago I offered to add (mutatis mutandis)
>> to GEC the debugger I developed for SE.
>>     
>
> Yes that would indeed be a great addition!
>
>   
>> The debugger is one of three possible additions.
>> The others are introspection and persistence closure.
>> Debugger and persistence closure depend on introspection,
>> and currently I'm still trying to add introspection.
>> In other words, adding the debugger will be not done
>> today or tomorrow.
>>     
>
> Ok.
>
>   
>> Which of your requirements are already satisfied?
>> - Not 1.* and 2.* since the debugger is not separate from
>> the debuggee (a situation like the SE debugger).
>> To satisfy the requirements needs much more
>> development and, as I think, has not the highest priority.
>>     
>
> Ok. Couldn't batch mode (and reading commands from a file/stdin)
> execution be implemented with not to much effort?
>   
The debugger is CLI-based. Thus, interactive mode and batch mode
by reading commands from stdin (and then from an arbitrary file)
is not very different. The necessary changes/additions include
- suppressing command prompts
- redirecting debugger output to a file
- stop after command error
There is no problem to make the changes/additions.

But is batch mode really of interest? To my experience, 
debugging will be done if the program does not what was expected,
i.e. if there is a somewhat surprising outcome.
Interactive mode is needed to react to unexpected behavior.
>   
>> - 3.1 to 3.14, 3.17, 3.18, 3.21,3.22 are available;
>> - 3.15, 3.16 are not hard to implement. Whether
>> to implement 3.19, 3.20 is a question of philosophy.
>>     
>
> I don't quite understand what you mean by philosophy. Are you saying
> that editing program data during debugging can be seen as violating
> some debugging principle or? I see them rather as power debugging
> features.
>   
Yes, philosophy means here that some people do not like to change
program data during debugging. A viable approach in case of Eiffel
may be as follows: changing an attribute value is allowed if the class
of the enclosing object has been compiled with invariant checking on
and if the invariant is still satisfied after the change.
There will be no restriction to change local variables.
But what about routine arguments? The program must not change them,
will the debugger be allowed to do so? (This is a secondary problem
and may be discussed later.)

In any case, the necessary actions (obtaining the new value as evaluation
of an expression, obtaining the variable's address, evaluating the class 
invariant)
have already been implemented as by-products of other commands.
>   
>> While not all of your requirements are satisfied,
>> some of the already implemented debugger commands
>> go far beyond, e.g. evaluation of not merely object values
>> but arbitrary expressions (which may include function calls)
>> and accompanying breakpoints with more sophisticated
>> conditions than just "class.feature name and line no".
>>     
>
> Excellent.
>
>   
>> PS:
>> The user's guide of the SE debugger.
>>     
>
> Thanks for the (obvoius) tip1 :-) I haven't used SmartEiffel for some years now.
>   
I hope that you didn't misunderstand the role that the debugger
plays in SE: it is not part of the official SE distribution.
I made the offer to SE1.2 developers to add it to this
compiler version, but I didn't get any answer so far.
> I would like to underline that my initial posting was intended to
> serve as input for you and others, like Howard who are interested in
> and have time and competence to develop a Gobo debugger.
>
> I would very much like to participate, but I don't have any experience
> in writing either compilers or debuggers and more importantly I don't
> have the spare time to learn or invest in this now. I will however
> really try to find time to test the debugger and discuss requirements
> from the perspective of a user.
>
> /Paul
>
>
>   


-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...