From: "Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr>
To: kdevelop-devel@kdevelop.org, Andrea Aime <aaime@libero.it>,
"kdevelop-devel" <kdevelop-devel@barney.cs.uni-potsdam.de>
Cc: sourcenav@sources.redhat.com
Subject: sourcenav and The Right Way to do it. (Re: c++ code completion status report)
Date: Fri, 04 Jan 2002 10:47:00 -0000 [thread overview]
Message-ID: <E16MZK3-0003CG-00@orion.exa.homeip.net> (raw)
In-Reply-To: <E16MTsh-00048c-00@barney.cs.uni-potsdam.de>
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
parent reply other threads:[~2002-01-04 18:47 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <E16MTsh-00048c-00@barney.cs.uni-potsdam.de>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E16MZK3-0003CG-00@orion.exa.homeip.net \
--to=erayo@cs.bilkent.edu.tr \
--cc=aaime@libero.it \
--cc=kdevelop-devel@barney.cs.uni-potsdam.de \
--cc=kdevelop-devel@kdevelop.org \
--cc=sourcenav@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).