From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16896 invoked by alias); 10 Jan 2002 01:27:15 -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 16867 invoked from network); 10 Jan 2002 01:27:14 -0000 Content-Type: text/plain; charset="iso-8859-1" From: "Eray Ozkural (exa)" Organization: Bilkent University CS Dept. To: Ian Roxborough , Ralf Corsepius Subject: Re: SourceNav release ... Date: Thu, 10 Jan 2002 04:34:00 -0000 X-Mailer: KMail [version 1.3.2] Cc: sourcenav@sources.redhat.com, kdevelop-devel@kdevelop.org, "Thomas Schilling" References: <1010327798.1505.4.camel@mccallum> <20020107131412.30f223fb.irox@redhat.com> In-Reply-To: <20020107131412.30f223fb.irox@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-SW-Source: 2002-q1/txt/msg00024.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ian, Thanks a lot for all your work on sourcenav. Is my small call graph generator included in sourcenav now? I'd posted it here on the list. I can sign things, too. :) A fellow hacker had even made some improvements to it. It was very useful for trying to understand a large chunk of old code in a past project I worked in. I have an important question to ask. For the past two weeks or so we have been discussing how the parser backend should be in KDevelop IDE. As a computer scientist, I feel what the Right Thing (TM) is but as far as practically goes it is out of question [*]. What we have here is a class store API (which is basically a tree structure) that is intended to provide type information for class based languages. KDevelop hackers are retro-fitting a C++ parser for doing things like code completion. However, my hunch is that it will not be a general purpose or complete solution to the problem. Neither is a perfect solution implementable in our humble development environment (that being ancient parser generators and data structure driven procedural language: C++) The next best thing that comes to my mind is sourcenav for three reasons. It has solved the multiple languages & persistence problems reasonably well. And, it's very portable. Would you deem merit in trying to re-use code from source navigator in a C++ code base? (ie we would be using the C API of sourcenav). What advantages/disadvantages of sourcenav parser/type analysis backend would you think of as the sourcenav maintainer? And how should one go about it? (can the whole back end be made into a library?) Regards, [*] Doing incremental type analysis for all supported programming languages. - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8PO0XfAeuFodNU5wRArM8AJ9VZfaHTfFJh4nJHo8Dd29qGEE0EACfYubQ Egrj0otL38qswUHJriLOj4M= =kfo5 -----END PGP SIGNATURE-----