public inbox for sourcenav@sourceware.org
 help / color / mirror / Atom feed
From: "Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr>
To: Mo DeJong <supermo@bayarea.net>
Cc: corsepiu@faw.uni-ulm.de, sourcenav@sources.redhat.com,
	kdevelop-devel@kdevelop.org, snuffeler@gmx.net
Subject: Re: SourceNav release ...
Date: Fri, 18 Jan 2002 14:52:00 -0000	[thread overview]
Message-ID: <E16RgzN-0006jk-00@orion.exa.homeip.net> (raw)
In-Reply-To: <20020110094527.676c445b.supermo@bayarea.net>

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

Thanks,

- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
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

iD8DBQE8SJnsfAeuFodNU5wRAs9eAJ96oXZFnxjHvy7y+Sotlek6tA8JWwCeLzUJ
7urBCcYhlEK9QYsqLk+EdHI=
=EqUN
-----END PGP SIGNATURE-----

  reply	other threads:[~2002-01-18 22:02 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) [this message]
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
  -- 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=E16RgzN-0006jk-00@orion.exa.homeip.net \
    --to=erayo@cs.bilkent.edu.tr \
    --cc=corsepiu@faw.uni-ulm.de \
    --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).