SN status?

SN status?

[Andrew Birkett]

Hi,

I'm mainly interested in the C++ parsing and xref side of SN, and I've got
a few questions which I hope someone can answer.

1. The latest released version is 4.5.2 and I understand that Redhat
people are working on 5.0.  Is there cvs access to the latest development
sources?  I don't want to start tweaking bits of the 4.5.2 snavigator
source if whole chunks are going to be rewritten for 5.0.

2. Is there a list of known issues with the C++ parsing and xref code?  Or
a public bugs database?

3. What language are the comments in the C++ parser in? :-)

4. Are there unit tests to check the expected behaviour of the C++ parser?

From reading the list archive and web searches, there doesn't appear to be
a massive amount of external development on SN, which is a pity because
it looks like it could be a great tool.  I'd like the C++ parser to get to
the stage where I'm confident it's picking up all of the xref's, since I'm 
looking to write a refactoring assistant for C++.

BTW, the 'welcome to the list' message still refers to the address
'sourcenav@sourceware.cygnus.com' which presumably is out of date?

Andrew

- www.tardis.ed.ac.uk/~adb -

Re: SN status?

[Ben Elliston]

Hi Andrew,

  Andrew> 3. What language are the comments in the C++ parser in? :-)

Hungarian (and some in German).

  Andrew> 4. Are there unit tests to check the expected behaviour of
  Andrew> the C++ parser?

No.  Should there be?  Yes.

Ben

Re: SN status?

[Mo DeJong]

On Wed, 21 Feb 2001, Andrew Birkett wrote:

> Hi,
> 
> I'm mainly interested in the C++ parsing and xref side of SN, and I've got
> a few questions which I hope someone can answer.
> 
> 1. The latest released version is 4.5.2 and I understand that Redhat
> people are working on 5.0.  Is there cvs access to the latest development
> sources?  I don't want to start tweaking bits of the 4.5.2 snavigator
> source if whole chunks are going to be rewritten for 5.0.

No, we don't have 5.0 available via CVS yet. Heck, we don't
have it available via FTP yet (but we are getting closer).
The code that implements the GUI has changed quite a bit,
the back end stuff has not.

> 2. Is there a list of known issues with the C++ parsing and xref code?  Or
> a public bugs database?

No and not yet but there will be.

> 3. What language are the comments in the C++ parser in? :-)

Welcome to the party!

> 4. Are there unit tests to check the expected behaviour of the C++ parser?

No. We have been talking about implementing a nice XML layer
that would sit between the parsers and the DB backend.
That would let us write test cases quite easily, the
problem is finding enough time to implement it.

> From reading the list archive and web searches, there doesn't appear to be
> a massive amount of external development on SN, which is a pity because
> it looks like it could be a great tool.

We think that will pick up after 5.0 is out.

> I'd like the C++ parser to get to
> the stage where I'm confident it's picking up all of the xref's, since I'm 
> looking to write a refactoring assistant for C++.

Sounds like you are interested in helping with C++
regression tests, we welcome such help. The C++
support is an area that needs work.

Mo DeJong
Red Hat Inc

Re: SN status?

[Ben Elliston]

>>>>> "Mo" == Mo DeJong <mdejong@cygnus.com> writes:

  Mo> No. We have been talking about implementing a nice XML layer
  Mo> that would sit between the parsers and the DB backend.
  Mo> That would let us write test cases quite easily, the
  Mo> problem is finding enough time to implement it.

One thing I've been itching to do is knock together a DejaGNU
framework that allows us to test the C/C++ parser against the GCC
testsuite.  Of course, we can maintain our own smaller regression
testsuite, but to get all of these tests for such little effort would
be a win.

Ben

Re: SN status?

[Mo DeJong]

On Thu, 22 Feb 2001, Ben Elliston wrote:

> >>>>> "Mo" == Mo DeJong <mdejong@cygnus.com> writes:
> 
>   Mo> No. We have been talking about implementing a nice XML layer
>   Mo> that would sit between the parsers and the DB backend.
>   Mo> That would let us write test cases quite easily, the
>   Mo> problem is finding enough time to implement it.
> 
> One thing I've been itching to do is knock together a DejaGNU
> framework that allows us to test the C/C++ parser against the GCC
> testsuite.  Of course, we can maintain our own smaller regression
> testsuite, but to get all of these tests for such little effort would
> be a win.
> 
> Ben


I don't really want to go the whole DejaGNU route.
I think we can do everything we need with straight tcltest.

You might want to check out this article:

http://www-106.ibm.com/developerworks/library/l-jacks/?dwzone=linux

It is about a test system I wrote based on tcltest
and why I avoided DejaGNU. An XML based test system
for SN parsers would be very much the same except that we
would need to compare the output a bit differently.

Mo DeJong
Red Hat Inc