From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17332 invoked by alias); 4 Jan 2002 18:47:37 -0000 Mailing-List: contact sourcenav-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sourcenav-owner@sources.redhat.com Received: (qmail 17258 invoked from network); 4 Jan 2002 18:47:35 -0000 Content-Type: text/plain; charset="iso-8859-1" From: "Eray Ozkural (exa)" Organization: Bilkent University CS Dept. To: kdevelop-devel@kdevelop.org, Andrea Aime , "kdevelop-devel" Subject: sourcenav and The Right Way to do it. (Re: c++ code completion status report) Date: Fri, 04 Jan 2002 10:47:00 -0000 X-Mailer: KMail [version 1.3.2] References: <001301c194a1$23a8e000$0300a8c0@dommili> In-Reply-To: Cc: sourcenav@sources.redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-SW-Source: 2002-q1/txt/msg00008.txt.bz2 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) 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