SourceNav release ...

[Khamis Abuelkomboz]

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