From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19367 invoked by alias); 19 Jan 2002 02:13:21 -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 19323 invoked from network); 19 Jan 2002 02:13:08 -0000 Received: from unknown (HELO mailout02.sul.t-online.com) (194.25.134.17) by sources.redhat.com with SMTP; 19 Jan 2002 02:13:08 -0000 Received: from fwd09.sul.t-online.de by mailout02.sul.t-online.com with smtp id 16Rl08-000627-00; Sat, 19 Jan 2002 03:13:00 +0100 Received: from t-online.de (520027106440-0001@[217.80.164.1]) by fwd09.sul.t-online.com with esmtp id 16Rl07-0cQimWC; Sat, 19 Jan 2002 03:12:59 +0100 Message-ID: <3C48D677.8070408@t-online.de> Date: Sat, 19 Jan 2002 08:59:00 -0000 From: khamis2@t-online.de (Khamis Abuelkomboz) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Eray Ozkural (exa)" CC: Mo DeJong , corsepiu@faw.uni-ulm.de, sourcenav@sources.redhat.com, kdevelop-devel@kdevelop.org, snuffeler@gmx.net Subject: Re: SourceNav release ... References: <20020110094527.676c445b.supermo@bayarea.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Sender: 520027106440-0001@t-dialin.net X-SW-Source: 2002-q1/txt/msg00041.txt.bz2 Eray Ozkural (exa) wrote: >-----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? > abstracting the db stuff is a good idea. Ian brought once the idea of making an xml interface for importing/reading symbol informations from/into the database, put this into a library. this would abstract the database layer with an open interface. The question is, how much work has to be done to make such an interface! khamis