From: khamis2@t-online.de (Khamis Abuelkomboz)
To: "Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr>
Cc: Mo DeJong <supermo@bayarea.net>,
corsepiu@faw.uni-ulm.de, sourcenav@sources.redhat.com,
kdevelop-devel@kdevelop.org, snuffeler@gmx.net
Subject: Re: SourceNav release ...
Date: Sat, 19 Jan 2002 08:59:00 -0000 [thread overview]
Message-ID: <3C48D677.8070408@t-online.de> (raw)
In-Reply-To: <E16RgzN-0006jk-00@orion.exa.homeip.net>
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
next prev parent reply other threads:[~2002-01-19 2:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-06 0:26 Simonovsky, Pavel
2002-01-06 3:48 ` Mo DeJong
2002-01-06 6:36 ` Ralf Corsepius
2002-01-07 12:04 ` Khamis Abuelkomboz
2002-01-07 13:11 ` Timothy M. Shead
2002-01-18 18:13 ` Mo DeJong
2002-01-07 13:22 ` Ian Roxborough
2002-01-07 13:34 ` Patches...[was: Re: SourceNav release ... ] Ian Roxborough
2002-01-10 4:34 ` SourceNav release Eray Ozkural (exa)
2002-01-11 14:34 ` Mo DeJong
2002-01-18 14:52 ` Eray Ozkural (exa)
2002-01-18 15:33 ` Mo DeJong
2002-01-18 15:58 ` Ian Roxborough
2002-01-24 10:14 ` Eray Ozkural (exa)
2002-01-19 9:03 ` Eray Ozkural (exa)
2002-01-19 8:59 ` Khamis Abuelkomboz [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-01-04 2:56 Roman Levenstein
2002-01-04 15:48 ` Khamis Abuelkomboz
2002-01-03 14:30 klmcw yahoo
2002-01-03 15:08 ` Khamis Abuelkomboz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C48D677.8070408@t-online.de \
--to=khamis2@t-online.de \
--cc=corsepiu@faw.uni-ulm.de \
--cc=erayo@cs.bilkent.edu.tr \
--cc=kdevelop-devel@kdevelop.org \
--cc=snuffeler@gmx.net \
--cc=sourcenav@sources.redhat.com \
--cc=supermo@bayarea.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).