SourceNav release ...

Khamis Abuelkomboz
Sat Jan 19 08:59:00 GMT 2002

Eray Ozkural (exa) wrote:

>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 
>>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!


More information about the Sourcenav mailing list