SourceNav release ...
Eray Ozkural (exa)
erayo at cs.bilkent.edu.tr
Fri Jan 18 23:04:02 UTC 2002
-----BEGIN PGP SIGNED MESSAGE-----
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
How does that sound?
Eray Ozkural (exa) <erayo at cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
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
-----END PGP SIGNATURE-----
More information about the KDevelop-devel