Breakpoints

[Andreas Pakulat]

On 15.04.09 13:06:38, Vladimir Prus wrote:
> On Wednesday 15 April 2009 11:10:17 Andreas Pakulat wrote:
> 
> > > > > We technically can have a single list (as soon as we know
> > > > > breakpoint->config association internally for the benefit of 'sync' state
> > > > > display).
> > > > 
> > > > Why is there a breakpoint->config association?
> > > 
> > > Because config is the entity that sets breakpoints, and it should be
> > > able to distinguish between:
> > 
> > Hmm, isn't it rather the debugger that sets it.
> > 
> > >   - Breakpoints that must be inserted, and are inserted
> > >   - Breakpoints that must be inserted and are not, for any reason
> > >   - Breakpoints that are irrelevant
> > > 
> > > In particular, display of  breakpoint in the breakpoint widget will
> > > be decorated with different icons depending on which of the above
> > > states is true.
> > 
> > But I don't see why you'd need to know the config for doing that.
> 
> Well, I hope you'll agree that we need some mechanism of understanding
> what breakpoints are irrelevant for the current debug session. 

If you meant to say "current debug sessions" (i.e. plural form) then yes I
agree.
 
> > > 2. Launcher having to decide, using flaky heuristics, if a breakpoint
> > > "belongs" to it and should be inserted, or, alternatively, trying
> > > to insert all breakpoints.
> > 
> > Then how do you imagine that the user explains KDevelop which breakpoint
> > should be used with which config? 
> 
> We'll have current launch config -- we already have it, and other IDEs have
> it too. Newly added breakpoints are associated with the current launch config.

No, we have a "default run", which is executed if you don't choose a
different one. But if I debug two applications at the same time, I don't
want to have to switch the "current launch config" each time something
happens in the other app. 

Also I don't see this being needed at all, a debug plugin, when starting an
app, can see _all_ breakpoints that have ever been set by the user. It can
then try to set all of them, or if it has a way to find out wether some are
irrelevant then it can ignore them. Additionally it can tell the
breakpoints that they're now set for the launch config it starts right now.

That would make the state information of "current launch config" uneeded.

Andreas

-- 
Good day to let down old friends who need help.