Breakpoints

[Vladimir Prus]

On Wednesday 15 April 2009 09:47:00 Niko Sams wrote:
> On Wed, Apr 15, 2009 at 7:27 AM, Vladimir Prus <ghost at cs.msu.su> wrote:
> > 1. Breakpoint table showing 100 breakpoints, only 5 of them are relevant
> > to the current lunch config
> I don't see a problem if the user can click always a clear-all button

And -- loose all breakpoints in all projects? For example, if I debug GDB
there's a pile of function that breakpoint should always be set on,
say 'internal_error'. Whenever I hack on GDB, I want this breakpoint to
be there, and I don't want this breakpoint to eat up precious screen
space when hacking on KDevelop, or on Python program. This sounds like
per-project breakpoints, but note that a single project can have
both C++ and Python programs, or different programs, so maybe per-launch-config
makes more sense.

> > alternatively, trying to insert all breakpoints.
> I would do that.

I am worried about two things:

1. Ideally, if you insert breakpoint and insertion fails, you need
to inform the user, as opposed to silently not stopping. If you send
random breakpoints you'll get random error messages.
2. When doing specific debug session you typically has a few breakpoints
you really want to stop on. If we automatically insert breakpoints from
other projects and launch configs, some of them might actually get inserted
and you'll have stops on places you don't want.

> 1. per config:
> - The current Breakpoint-Model design can stay as it is (as every
> plugin can provide it's own breakpoint classes).
> - we can't easily switch to a global single model (as in this case
> there must be a single breakpoint class)

I don't understand the point about single breakpoint class -- it
seems independent from per-config/global discussion.

> 2. per project / global
> - gdb-plugin has to be ported, code moded out of breakpoint class
> - much more flexible (easy to implement breakpoints per config, or -
> as david suggested a brekpoint-set combobox)

FWIW, I think breakpoint-set -- as a new concept in addition to project
and launch config -- will just complicate the conceptual model.

> - actually i'm working already on this

Maybe, you can give more details how it will work? I don't mind in principle
trying something can be be easily tweaked later -- but the details matter.

- Volodya