sourcenav and The Right Way to do it. (Re: c++ code completion status report)

sourcenav and The Right Way to do it. (Re: c++ code completion status report)

[Eray Ozkural (exa)]

On Friday 04 January 2002 14:32, Andrea Aime wrote:
>
> Anyone of you gave a look at RedHat's Source Navigator?
> It has parsers for several languages, stores the parsed information
> in bynary files and provides some simple C api to access them...
> using these files the Source Navigator GUI provides a list of every
> function/class/method/file parsed and full cross referencing... it doesn't
> know about signals and slot, but I guess only some modification to
> the available parsers is needed... using the API you will get also an
> uniform way to deal with C, Fortran, Perl, Tcl, Python etc. etc.
> Source navigator is GPL'd and can be found on sources.redhat.com.
> Hope this helps

I maintain sourcenav for debian. I've also written a call graph generator 
using the API. It's pretty slick because it uses Berkeley DB instead of a 
slooow XML approach.

What it offers you is a nice efficient database that you can access in a 
variety of ways. Please install sourcenav, see what it does, take a look at 
the API docs and examples, and then let's discuss it.

For one thing, persistence means a file organization and AFAIK none of the 
codes you've been talking about can give you true persistence. [*]

Sourcenav's parsers and database routines are fairly generic and can easily 
be reused in gideon. [+] They also offer much richer functionality than what 
we have in gideon.

Another thing: not all relations are best represented in an ASCII tree which 
is DOM. I feel like repeating myself, on #kde and here, but: DOM (or XML) 
isn't a subsitute for a mathematical model, or a proper data structure, or an 
algorithm. Not all programming domains require TRANSMISSION of structured 
(unfortunately here it is read: hierarchical, as in a tree) data (read: 
untyped, dumb data) between INDEPENDENT applications and hardware. Here, we 
have *one* application, that has to do *one* thing right, and we have access 
to *all* the source code, and we know how to retrieve/store that data, how to 
invoke parsers, etc. [!]

So a persistent class store indeed is the right way to go, but how 
extensible/generic/persistent is it really? And should we really re-invent 
the wheel?

I'm cc'ing to sourcenav list to see what sourcenav people's think of the 
reusability of sourcenav code in another IDE.

[*] Umm, even the stock sourcenav code might not give that without tweaking! 
In a really persistent system, you shouldn't have to reconstruct all objects 
into memory upon initialization, etc. I don't know how far sourcenav really 
goes, but it does have a "loading" phase when you open a project.

[+] And no, database does not mean a bloated SQL server.

[!] So, you will ask me, are trees useless? Of course they are useful, when 
your algorithms will work with a tree. A tree that can hold arbitrary _data_ 
_structures_  (rather than expensive ASCII/Binary items) at nodes and leaves 
of course, or a special tree like a binary tree or an AVL tree. When the data 
is large, an out-of-core tree is also very very useful. I know how to make 
one but it's beyond the scope of discussion ;) In this case however, a 
relational model seems to be more appropriate than a hierarchical database.

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C