Re: KDE/kdevelop/languages/cpp/debugger

On Fri, 14 Dec 2007 09:51:20 am Andreas Pakulat wrote:
> On 13.12.07 22:26:14, Hamish Rodda wrote:
> > Start on new way of providing specialised
debugging views for certain
> > objects - first example is parsing of QString (not
yet working). One
> > day soon you should be able to write customised
views using
> > plugins, that's going to be awesome 
>
> Didn't look at the code yet, but IMHO it makes more
sense to implement
> this inside the gdb plugin as a simple mapping of
type-names to gdb
> commands (or list of commands). That way its _very_
easy to register
> your own type for printing, without the need to do any
coding at all.
> And KDevelop doesn't have to re-invent the wheel and
can just depend on
> the existing gdb macros from kdesdk to print Qt4 and
Qt3 structures.

This is not just about returning a smart value, it's also
about showing 
different children (ie. making list/set/map etc members
accessible).  Also, 
not everything can be accomplished with a single gdb
command, and you 
couldn't provide any processing for multiple commands with
the system you're 
suggesting.  Also, you couldn't specify how to format the
output from gdb 
(QString char data has to be processed first).  Eventually I
also want to 
implement casting features so when you're shown a base
class, you can easily 
get to the subclass features.

I think it's better to do it in code.  A plugin could be
developed for cases 
where it truly is trivial to write the appropriate gdb
statement.

Cheers,
Hamish.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 14.12.07 12:01:31, Hamish Rodda wrote:
> On Fri, 14 Dec 2007 09:51:20 am Andreas Pakulat wrote:
> > On 13.12.07 22:26:14, Hamish Rodda wrote:
> > > Start on new way of providing specialised
debugging views for certain
> > > objects - first example is parsing of QString
(not yet working). One
> > > day soon you should be able to write
customised views using
> > > plugins, that's going to be awesome 
> >
> > Didn't look at the code yet, but IMHO it makes
more sense to implement
> > this inside the gdb plugin as a simple mapping of
type-names to gdb
> > commands (or list of commands). That way its
_very_ easy to register
> > your own type for printing, without the need to do
any coding at all.
> > And KDevelop doesn't have to re-invent the wheel
and can just depend on
> > the existing gdb macros from kdesdk to print Qt4
and Qt3 structures.
> 
> This is not just about returning a smart value, it's
also about showing 
> different children (ie. making list/set/map etc members
accessible).  Also, 
> not everything can be accomplished with a single gdb
command, and you 
> couldn't provide any processing for multiple commands
with the system you're 
> suggesting.  Also, you couldn't specify how to format
the output from gdb 
> (QString char data has to be processed first). 
Eventually I also want to 
> implement casting features so when you're shown a base
class, you can easily 
> get to the subclass features.

Well, I meant macro's as well. But IIRC the debugger doesn't
work when
you just execute something like printf "foo" in
gdb right? So macros
like printq4string are not going to work.

Still IMHO we need a way to make this extendable to custom
type without
having to compile a plugin. How about defining a scripting
interface
which allows to do this, i.e. people can register a script
with a type
information and then the debugger executes the script. Thats
far easier
than having to setup a plugin project and build it. Its also
easier to
write as you don't need to restart KDevelop to test a new
version.

Andreas

-- 
Beware the one behind you.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel