From: Mo DeJong <supermo@bayarea.net>
To: "Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr>
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 15:33:00 -0000 [thread overview]
Message-ID: <20020118065806.4158e85b.supermo@bayarea.net> (raw)
In-Reply-To: <E16RgzN-0006jk-00@orion.exa.homeip.net>
On Fri, 18 Jan 2002 23:55:53 +0200
"Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr> wrote:
...
> > 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.
There are always alternatives in the DB arena. Abstracting the DB interface
so that it does not strictly rely on Berkeley DB was all I meant. Attempting to
rewrite working code to make the DB layer more generic is about as much
fun as poking yourself in the eye (the SN code is guilty of this).
> > 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?
Sounds good, as long as #3 (or any other GUI front end) is left outside the scope
of the project. I think a key to success will be minimizing external dependencies
so that code can easily be incorporated into other projects. Then there is the
old C vs C++ debate and the discussion of which lame/broken compilers
should be supported.
I would be very interested in helping you get this project going. My initial focus
would be on a regression test suite and a Java parser. What comes next is
the age old question of labels and resources. This project will need a name and
a home. Sourceforge has some great features, but the mailing list archives
are really lame. I have always been impressed by the folks that run sourceware
(aka sources.redhat.com), but I don't know if it is the best place for such a
project.
reactions?
Mo
next prev parent reply other threads:[~2002-01-18 22:52 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 [this message]
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=20020118065806.4158e85b.supermo@bayarea.net \
--to=supermo@bayarea.net \
--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 \
/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).