Runtime data visualization plugin architecture

[Andreas Pakulat]

On 17.02.10 21:31:39, Manoj Rajagopalan 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, but I don't think the support for memory-dump-stuff etc. is written
yet. So far it mostly deals with variables and breakpoints only afaik
(Niko Sams or Vladimir Prus know for sure).
 
> 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 ...? >

c) is the right thing to do then, but not as dependency for KDev4 as
whole, rather just the plugin needs it. It needs to make sure it finds
Qwt and QwtPlot3D in their Qt4 versions and the plugin should be
disabled if either of the two is missing. Thats the "right and elegant"
thing to do :) (svn support and classbrowser work the same way)
 
> 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?

Sure, all plugins can be loaded/unloaded anytime. And we don't
necessarily have to ship this plugin within kdevelop or kdevplatform.
There's a separate module that contains releasable plugins in svn now.
The php plugins are there currently, this place would be a perfect fit
for your plugin too, IMHO. And packagers are going to package that -
either each plugin individually, or all together as they wish.
 
> 4. The playgound mentioned above - is it for 3.5 branch or 4.x or both?

4.x only. I think there's also a kde3-playground, if you want to import
your existing KDevelop 3.5 plugin. I'd have to look for it though, not
sure where it sits right now.

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

We have one debugger plugin for xdebug, a debugger for JS/HTML (IIUC)

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

I don't think I have a clear idea of what your plugin does. Is this
about something like ddd (or this mischa debugger) has, a graph of the
data in the application?
 
>    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?
> 
>    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'll leave that to the debugger experts, in theory though I think it
should be possible to have a generic API that delivers the data you need
- if the debugger-"backend" support fetching such data.

Andreas

-- 
If you think last Tuesday was a drag, wait till you see what happens tomorrow!