From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17098 invoked by alias); 18 Jan 2002 22:02:44 -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 17014 invoked from network); 18 Jan 2002 22:02:40 -0000 Received: from unknown (HELO venus1.ttnet.net.tr) (212.156.4.3) by sources.redhat.com with SMTP; 18 Jan 2002 22:02:40 -0000 Received: from orion.exa.homeip.net ([195.174.160.184]) by venus1.ttnet.net.tr (Netscape Messaging Server 4.15) with ESMTP id GQ5MJ603.L0A; Sat, 19 Jan 2002 01:01:55 +0300 Received: from exa by orion.exa.homeip.net with local (Exim 3.32 #1 (Debian)) id 16RgzN-0006jk-00; Fri, 18 Jan 2002 23:55:57 +0200 Content-Type: text/plain; charset="iso-8859-1" From: "Eray Ozkural (exa)" Organization: Bilkent University CS Dept. To: Mo DeJong Subject: Re: SourceNav release ... Date: Fri, 18 Jan 2002 14:52:00 -0000 X-Mailer: KMail [version 1.3.2] Cc: corsepiu@faw.uni-ulm.de, sourcenav@sources.redhat.com, kdevelop-devel@kdevelop.org, snuffeler@gmx.net References: <20020110094527.676c445b.supermo@bayarea.net> In-Reply-To: <20020110094527.676c445b.supermo@bayarea.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: X-SW-Source: 2002-q1/txt/msg00037.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mo, On Thursday 10 January 2002 19:45, Mo DeJong wrote: > > You are correct, that is not a complete solution. You can't just hack a > compiler to generate symbols for your project. That works when the code is > perfectly correct but it will explode on code that does not compile. You > first reaction might be, "duh, of course the code needs to compile". Thing > is, users need the tool to work even if the code does not compile. This > fuzzy parsing functionality is not a feature you can tack on later. It > needs to be part of the original parser design. > Yes, I'm familiar with parsing issues since I had some minor involvement with NLP subject. You would typically need to build your CFG parser fault-tolerant from the ground up. > I think the right solution is to turn the SN backend into a library. Even > if you don't reuse the code, the ideas that are there have years of effort > behind them and they do work. It should make use of Berkeley DB to store > symbols but through an API so that people can swap out other database > layers if they want to. It should also provide a nice two phase parse and > dump into symbol DB sequence that is easily inspected. Just figuring out > what and where the problem with a parser is can be the most difficult part > of fixing a problem. Also, it is absolutely critical that a well defined > regression test framework is developed as part of the library. > I've looked at the code more closely now. I have some involvement with the code luckily, and it seems pretty clean to me. In particular I like the Berkeley DB design since that is the best solution to persistence on a GNU system. Abstracting the API is a good thing, but as a replacement I can't spot any good db code. It looks like the symbol extraction process has also been generalized a bit, so it gives us a framework to add support for new languages. > Of course, the tricky part is how to move forward. If you just make a KDE > version of Source-Navigator then it will only be useful to KDE folk. There > are plenty of other development tools that could really make use of this > functionality if it was available in an well documented and easy to use > library format. The larger the user base, the more bugs will get worked > out. User base is important since parsers are so bug prone. This project is > something I was thinking about working on, but it is quite a bit of work > and will require more than one developer. > I can volunteer for this project. Here is my plan: 1) Refactor sourcenav such that it can be built/used as a standalone programming-tool library. I'va already commenced work in this area. It doesn't seem to be hard. 2) Provide a generic C++ library that wraps C API. 3) A separate "kodenavigator" library that provides GUI components to sourcenav functions. How does that sound? Thanks, - -- 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 iD8DBQE8SJnsfAeuFodNU5wRAs9eAJ96oXZFnxjHvy7y+Sotlek6tA8JWwCeLzUJ 7urBCcYhlEK9QYsqLk+EdHI= =EqUN -----END PGP SIGNATURE-----