SN Printing Under WIN/NT

[Berek]

See imbedded comments below.

----- Original Message -----
From: "Mo DeJong" <mdejong@cygnus.com>
To: "Berek" <berek@usa.net>
Sent: Thursday, October 05, 2000 14:19
Subject: Re: SN Printing Under WIN/NT


> > > Humm, if all of these companies are having problems why have they
> > > not contacted us about a support/development contract to improve
> > > the C++ parser support?
> >
> > Because they bought SN for evaluation: to see if it could improve the
> > development and sustaining engineering process. SN works well for
standard
> > C, but it is simply not usable for C++. Since the folks that evaluated
SN
> > (at these companies) are experienced s/w engineers, they know that SN is
not
> > a release quality product (Beta at best) for C++ code analysis, and they
> > have a good feeling for the effort and time it will take before these
> > problems are resolved. When they bought the product, they assumed they
> > wouldn't have to shell out additional money to Red Hat (Cygnus at the
time)
> > to fix bugs that shouldn't have existed (in release quality software) in
the
> > first place.
> >
> > I've been a s/w engineer for thiry-four years and I have never seen a
> > release quality product with so many serious and blatant defects.
>
> You must be joking. I have seen plenty of "released" software products
> that a much much worse than SN. While I would agree with you that
> the parsers need some serious reworking, saying SN in the worst
> product in 34 years is really a stretch. At least it does not
> core dump :)

Sorry...I stand by my statement. We're not talking about frivilous or
insignificant bugs, we're talking about basic functionality: SN does not
work as advertized for C++. Nor can it print xref charts under Windows NT
for, apparently, both C and C++.

And...it does core dump, at least dbimp croaks on an address violation when
parsing large projects. Yes, I did report this problem. No, it's not a
parsing error, it's a boundary/threshhold problem. The large project I refer
 to contains over 560,000 lines of code. It's comprised of much smaller
projects, each of which parses correctly when done separately (dbimp doesn't
croak). When I create a new project consisting of two or more of these
smaller projects, dbimp "goes south".

>
> > It raises
> > concern about the level and degree of testing applied to this product.
99%
> > of these (C++ and printing) problems should have been caught and fixed
> > before SN ever hit the streets. I apologize for the strong language, but
> > when I relate to Red Hat engineering the problems we've encountered with
> > their s/w and the response we get is "pay us to fix 'em" or "do it
> > yourself", it sends my blood pressure through the roof. If any of the
> > companies I've worked for had that sort of attitude, they'd have been
out of
> > business long ago. My $0.02 worth.
>
> I hear what you are saying. This issue does need to get solved,
> and we are looking for help to get the right solution in place.
> The trick here is that our business is customer driven. We are
> going to have a hard time justifying 3 to 4 months of work on
> the C++ parser if we do not have a customer that is paying for it.

You mean to tell me that there aren't enough customers in the United States
using C++ to justify fixing very basic, fundamental flaws in the C++ parser?
(Not to mention fixing bugs with printing xref and hierarchy charts.)

> > If you like, I can give you the names and phone numbers of people that
have
> > evaluated SN at Concord Communications, Broadband, and 3Com. I can also
tell
> > you exactly what they're going to say: "we can't use SN for C++
development
> > until these bugs are fixed".
> >
> > Cheers
> > Steve Dow
>
> So we are stuck at a catch-22. We need to figure out how to
> more forward, how about asking these folks "if the C++
> support in SN was fixed, would you consider purchasing
> support and using the product?"

Have you done a market survey yet? I find it hard to believe that managememt
at Red Hat thinks the PERL market is larger than C++. My feeling is that any
survey is going to show (in decreasing order of use): COBOL, std C, C++, all
others.

> If the answer if "yes", and we can get that in a nice
> pie chart to present to management, then it would
> be a lot easier to get resources allocated to doing it.

I just happen to have such a chart in my office. I'd be delighted to forward
it to you [smile].

> cheers
> Mo DeJong
> Red Hat Inc
>