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

[Paul C. <pac...@gm...>]

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?

> - 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.

> 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 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