Runtime data visualization plugin architecture

[Niko Sams]

On Thu, Feb 18, 2010 at 03:31, Manoj Rajagopalan <rmanoj at umich.edu> wrote:
> Hi all,
>
>   Forking this from the thread "FOSDEM Idea: Visualize runtime data (e.g.
> during debugging)"
>
>   I have developed a working visualizer with the 3.5 branch on my personal
> machines and am interested in porting this to 4.x. Aleix Pol mentioned the
> playground and a plugin model. I have a few questions:
>
>
> 1. In KDev 3.5 the code had to be tightly bound to the GDB plugin - it emitted
> GDBMI instructions to extract memory dump information from gdb. Does KDev4
> have a debugger abstraction which hides details like GDBMI and provides
> access through an easier, debugger-independent API abstraction?
Yes, KDevelop4 has a generic debugger frame work with currently 3 backends:
- gdb
- xdebug (in playground)
- crossfire (in playground, not yes really working)

> 2. Qwt and QwtPlot3D are dependencies for plotting graphs. If the plugin is
> tightly bound and invasive, as in 3.5, then these libraries will have to be
> included somehow:
>   (a) include their code within the KDev4 source tree someplace and build as
> subproject,
>   (b) tear out only the relevant code and create subproject (too much work)
>   (c) specify them as explicit KDev4 dependencies (IMHO unacceptable)
>   (d) <the ideal, elegant solution, which is ...? >
We don't want to maintain this code, so it should be a dependency.
When your plugin in optional thats no problem at all.

>  2.Q: What would an acceptable alternative be?
>
> 3. If the plugin is loosely-bound (can be (un)loaded on demand) then it can be
> shipped separately with explicit external dependences on the Qwt* libs and
> packaging can take care of this.
>
>   3.Q: does the KDev4 architecture permit this?
loading/unloading plugins? yes.

> 4. The playgound mentioned above - is it for 3.5 branch or 4.x or both?
3.5 is dead.
Active development happens for 4.

> 5. The 3.5 gdb plugin was specific to cpp. Other language directories like
> fortran, pascal etc. had no debugger subdirs or files so I am guessing no
> debugger existed for them (I see something for ruby).
>
>   5.Q1: Does the 4.x trunk (intend to) support debuggers for languages other
> than c/c++?
as mentioned above there are other debugger backends. the Gdb plugin currently
only supports cpp.

>   5.Q2: If so, will a visualization plugin be useful? I know python is used
> for scientific computing - not sure about other languages.
sure.

>   5.Q3:  If(5.Q2), then how should a visualization plugin be architected so
> that it remains extensible to a variety of languages with minimal extra
> effort?
if possible the plugin should work with any debugger plugin.

>   5.Q4:  In practice, would it be better to architect the plugin for
> languages supported specifically by GDB, beginning with C/C++, and then get
> to re-engineering much later? What is the expectation of the kdevelop-devel
> community on this? (GDB supports C, C++, Objective-C, Fortran, Java, Pascal,
> assembly, Modula-2, and Ada)
I never debugged anything different than C++. I don't know what needs to be done
to support other langauges.
bin grod aufgstondn

Niko