Re: SN Printing Under WIN/NT

Re: 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
>

Re: SN Printing Under WIN/NT

[Mo DeJong]

On Thu, 5 Oct 2000, Berek wrote:

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

Perhaps you missed the smiley face on that sentence.

> 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".

Without a way to reproduce the error, it is unlikely we are going
to be able to fix it.

> > 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.)

Perhaps you misunderstand the meaning of "customer" in this context.
We currently have actual customers that are paying us to work
a number of projects that include Source-Navigator. This set
of folks is much smaller than the sum of all the C++ users
in the U.S.

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

I am not sure why you are so worked up about Perl. A Perl parser
was talked about in the context of things that people on the net
might want to donate. If you are so interested in C++ support,
why don't you champion the cause of writing a new C++ parser
for Source-Navigator? It sounds as though you are uninterested
in allocating any capital resources to a new parser, so how
about organizing others to help you achieve your goal?

cheers
Mo DeJong
Red Hat Inc

Re: SN Printing Under WIN/NT

[Berek]

See imbedded comments below [smile].

----- Original Message -----
From: "Mo DeJong" <mdejong@cygnus.com>
To: <sourcenav@sources.redhat.com>
Sent: Thursday, October 05, 2000 16:28
Subject: Re: SN Printing Under WIN/NT


> On Thu, 5 Oct 2000, Berek wrote:
>
> > > 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.
>
> Perhaps you missed the smiley face on that sentence.
>
> > 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".
>
> Without a way to reproduce the error, it is unlikely we are going
> to be able to fix it.

Right. I wish I could send you my code base, but Concord Comm. would have
some serious objections [smile].

> > > 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.)
>
> Perhaps you misunderstand the meaning of "customer" in this context.
> We currently have actual customers that are paying us to work
> a number of projects that include Source-Navigator. This set
> of folks is much smaller than the sum of all the C++ users
> in the U.S.

I understand. But, if the C++ parser were cleaned up, you'd have a lot more
C++ customers and a lot more revenue than you do now.

>
> > 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.
>
> I am not sure why you are so worked up about Perl. A Perl parser
> was talked about in the context of things that people on the net
> might want to donate. If you are so interested in C++ support,
> why don't you champion the cause of writing a new C++ parser
> for Source-Navigator? It sounds as though you are uninterested
> in allocating any capital resources to a new parser, so how
> about organizing others to help you achieve your goal?

There you go again with the "if you don't like the situation, fix it
yourself" attitude [smile]. Let me put it a little more bluntly: I work 60
plus hours/week at my job at Concord. The weekends (when I have both Sat and
Sun off) I devote to chores around the house/yard and spending a few minutes
here and there with my wife and kids (once in a great while I even manage to
sneak in a hug or two). I spend my "spare time" coming up to speed in such
things as Java, web page development, and papers on protocols and networking
(work-related). I have to do this to stay current and remain competitive.
Now, that having been said, how much time do you think I can devote to
fixing SN bugs [smile]? This is not my job, it's your job. BTW, my four
Golden Retrievers and two cats don't seem to know me anymore. I can't
remember the last time I was able to take the dogs for a walk.

I have a proposition for you. You dedicate some of your free time to my
wife, kids, dogs and cats, and I'll use the time saved to fix SN bugs. Deal
[grin]?

Later
-Steve Dow

> cheers
> Mo DeJong
> Red Hat Inc
>

Re: SN Printing Under WIN/NT

[Ben Elliston]

   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 probably wouldn't take much to track this bug down.  It's possible to run
the parser manually, capture the output and then feed it into dbimp by hand
(under a debugger).

I assume you're not willing to share your 560,000 lines of code?

Ben

RE: Source navigator roadmap, features list, etc.?

[William Gacquer]

Yahoo! The community rules!

More seriously, if I can give you my wishlist...

1/ automatic recognition of new files in the project directories
2/ a better interface with CVS ( why not an integration of tkCVS in SN?)
3/ an expand/collapse button in the project tree view (expansion is the
default but my project is so big that I would prefer a collapse by default)
4/ Drag&Drop with KDE/Gnome (I known, that's Tk's stuff)
5/ a UML-istic class view (even if it's not editable)
6/ clicking on xref-ed objects/functions opens the file where the
object/function is used (by default, it opens the file a function
implementation)
7/ a clever "replace-in-files"
8/ an interface with GNAT (with tkGNAT?)
9/ a autoconf/automake project creation as in kdevelop
10/ a possibility to hide/show all SN-controlled windows
11/ a search-and-replace dialog that can jump directly to the next occurence
by clicking on replace
12/ working real-regular-expressions everywhere
13/ macros
14/ the debugger by default is insight. I want to be able to call DDD
instead (or whatever debugger I like)
15/ themes : editing with SN is like burning my eyes. It is much too hard to
configure a black background with a bright fonts. 
16/ what else?.... uhhh, I am sure I have missed something....


William

-----Original Message-----
From: Syd Polk [ mailto:spolk@redhat.com ]
Sent: mardi 26 septembre 2000 19:41
To: Berek
Cc: sourcenav@sources.redhat.com
Subject: Re: Source navigator roadmap, features list, etc.?


The future is going to be dictated largely by the community. If a lot of
people
in the community want something in, we will make it a priority for
development.

Syd Polk
Engineering Manager

Berek wrote:
> 
> I agree completely. I love SN, but it does have a lot of rough edges in
the
> UI, and it's buggy. I, too, have a lot of suggestions and bug reports and
> would like to know what the future of SN is going to be
> 
> ----- Original Message -----
> From: "Timothee Besset" <timo@qeradiant.com>
> To: <sourcenav@sources.redhat.com>
> Sent: Tuesday, September 26, 2000 01:00
> Subject: Source navigator roadmap, features list, etc.?
> 
> > Is this list the only way to send feature suggestions and bug reports?
> > What are the actual plans of RedHat with source navigator, is it going
> > to evolve a lot more? Because I would have a truckload of improvement
> > suggestions and feature requests. It would be nice if there was a public
> > space somewhere that described who is doing what, maintaining what on
> > this project.
> >
> > I had to move from an MSDev environment to development under linux, and
> > Source Navigator does some things better than MSDev, but it also has
> > some big drawbacks.
> >
> > regards
> >
> > TTimo
> >
> >

RE: Source navigator roadmap, features list, etc.?

[Syd Polk]

At 04:02 PM 10/3/00 -0700, Mo DeJong wrote:
>On Wed, 27 Sep 2000, William Gacquer wrote:
>
> > Yahoo! The community rules!
> >
> > More seriously, if I can give you my wishlist...
> >
> > 1/ automatic recognition of new files in the project directories
>
>Not sure about that one. Perhaps a feature to rescan for new files
>would be a good idea, but it should not be automatic.

I think that we should have a checkbox on the directory selection dialog 
that says "Live directory". If this is checked, the directory will be 
scanned every time the project is refreshed.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

SN Printing Under WIN/NT

[Berek]

Lot's of problems printing hierarchy and cross reference charts under NT. I
have SN installed on 1/2 dozen PC's. Some use Postscript drivers, others
PCL, some use both. All have same results printing on 1/2 dozen networked
printers. Basically, printing is garbled: letters, symbols, and lines
overlaying each other. Have to resort to doing NT alt-print screen and
pasting into MS Word, then printing from Word.

In Class view, C++ class members that are "private" have symbol (transparent
diamond) for "public". Private members should have no symbol at all. Both
public and private have the public symbol.

I'm concerned about comments made by SN Development (Syd Polk?) about
priority given to Perl parser. I know of more than 1/2 dozen companies in my
area that have been forced to scale back use of SN because of many problems
with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
cannot be relied upon as a development tool. We desparately need accurate
cross references. Those of us that us SN are forced to fall back on grep's.
Please review your priorities.

Tx
Steve Dow

----- Original Message -----
From: "Syd Polk" <spolk@redhat.com>
To: <sourcenav@sources.redhat.com>
Sent: Wednesday, October 04, 2000 13:27
Subject: RE: Source navigator roadmap, features list, etc.?


> At 04:02 PM 10/3/00 -0700, Mo DeJong wrote:
> >On Wed, 27 Sep 2000, William Gacquer wrote:
> >
> > > Yahoo! The community rules!
> > >
> > > More seriously, if I can give you my wishlist...
> > >
> > > 1/ automatic recognition of new files in the project directories
> >
> >Not sure about that one. Perhaps a feature to rescan for new files
> >would be a good idea, but it should not be automatic.
>
> I think that we should have a checkbox on the directory selection dialog
> that says "Live directory". If this is checked, the directory will be
> scanned every time the project is refreshed.
>
>
> Syd Polk spolk@redhat.com
> Engineering Manager +1 415 777 9810 x 241
> Red Hat, Inc.
>
>
>
>

Re: SN Printing Under WIN/NT

[Mo DeJong]

> I'm concerned about comments made by SN Development (Syd Polk?) about
> priority given to Perl parser.

Syd was talking about a possible contribution from someone in
the net community. We are not going to write a perl parser unless
someone contracts with us to write it.

> I know of more than 1/2 dozen companies in my
> area that have been forced to scale back use of SN because of many problems
> with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
> Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
> cannot be relied upon as a development tool.

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?

> We desparately need accurate
> cross references. Those of us that us SN are forced to fall back on grep's.
> Please review your priorities.

Our current priority is Source-Navigator 5.0. If your company needs
some particular feature, you have the following options:

1. Implement it yourself
2. Contract with us to implement it
3. Hire someone else to do it

cheers
Mo DeJong
Red Hat Inc

Re: SN Printing Under WIN/NT

[Paul Selormey]

Hello Mo DeJong,

> > [...]
> 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?

Please how much will it cost to contract you. I think many here will help to
contribute that amount which will give us a good parser for C/C++ in parser
and Java where possible.

> Our current priority is Source-Navigator 5.0. If your company needs
> some particular feature, you have the following options:

We have heard much about this, but it is not building on the current
existing codes?
What is new here? since no one seems to know what is going on except the
RedHat
staff.

> 1. Implement it yourself
> 2. Contract with us to implement it
> 3. Hire someone else to do it

Now, tell me SN used to be a commercial product. Was the principle the same
too?
If you buy it and it does not work the way you expect, then implement it
yourself, pay
us more to implement it and asked somebody to do it for you :-)

It sounds interesting though.
Best regards,
Paul.

Re: SN Printing Under WIN/NT

[Mo DeJong]

On Thu, 5 Oct 2000, Paul Selormey wrote:

> Hello Mo DeJong,
> 
> > > [...]
> > 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?
> 
> Please how much will it cost to contract you. I think many here will help to
> contribute that amount which will give us a good parser for C/C++ in parser
> and Java where possible.

The cost naturally depends on what you want fixed and how long
it takes to fix the problem. When you give away free software,
you need to charge for support and services to make ends meet.

> > Our current priority is Source-Navigator 5.0. If your company needs
> > some particular feature, you have the following options:
> 
> We have heard much about this, but it is not building on the current
> existing codes?

Source-Navigator 5.0 includes a large Itcl upgrade (1.5 -> 3.0)
but it is not a "start from scratch" rewrite like mozilla or
anything.

> What is new here? since no one seems to know what is going on except the
> RedHat
> staff.

We have purposely tried to add no new features for 5.0. We are
upgrading the core technologies we depend on (Tcl/Tk/Itcl),
but we are not adding a bunch of new user visible features.
I am not sure what you mean by "no one seems to know what is going on",
we have explained this on the list a number of times.

> > 1. Implement it yourself
> > 2. Contract with us to implement it
> > 3. Hire someone else to do it
> 
> Now, tell me SN used to be a commercial product. Was the principle the same
> too?
> If you buy it and it does not work the way you expect, then implement it
> yourself, pay
> us more to implement it and asked somebody to do it for you :-)

With a closed source product, you do not have the option to
fix it yourself or hire someone else to do it. You are at the
mercy of the vendor. This is one of the critical diffs of
an open vs closed code.

We are not saying that you have to fix the code yourself, but
you do have the freedom to do so. Would you buy a car that
could only be serviced at the dealer? That said, we think
people will recognize the logic of contracting with us to fix
problems or add new features, since we already know the code base.

cheers
Mo DeJong
Red Hat Inc

Re: SN Printing Under WIN/NT

[Syd Polk]

At 04:26 PM 10/4/00 -0400, Berek wrote:
>Lot's of problems printing hierarchy and cross reference charts under NT. I
>have SN installed on 1/2 dozen PC's. Some use Postscript drivers, others
>PCL, some use both. All have same results printing on 1/2 dozen networked
>printers. Basically, printing is garbled: letters, symbols, and lines
>overlaying each other. Have to resort to doing NT alt-print screen and
>pasting into MS Word, then printing from Word.

The real problem is that there are no font preferences that just apply to 
printing, and the fonts for screen and printing don't match very well. We 
need to do some work at some point cleaning this up, as well as an overall 
preferences rewrite.


>In Class view, C++ class members that are "private" have symbol (transparent
>diamond) for "public". Private members should have no symbol at all. Both
>public and private have the public symbol.
>
>I'm concerned about comments made by SN Development (Syd Polk?) about
>priority given to Perl parser. I know of more than 1/2 dozen companies in my
>area that have been forced to scale back use of SN because of many problems
>with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
>Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
>cannot be relied upon as a development tool. We desparately need accurate
>cross references. Those of us that us SN are forced to fall back on grep's.
>Please review your priorities.

C++ parser is a high priority; we use it internally.

Thanks for your feedback; it really is appreciated.

Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.

Re: SN Printing Under WIN/NT

[Berek]

Thank you [smile]. I really love SN. If you guys manage to clean up the C++
parser so that it's as reliable as a compiler (the closer to 100%, the
better off we'll be...we absolutely have to have accurate xrefs), this
product will be a developer's "dream come true".

----- Original Message -----
From: "Syd Polk" <spolk@redhat.com>
To: "Berek" <berek@usa.net>; <sourcenav@sources.redhat.com>
Sent: Thursday, October 05, 2000 15:08
Subject: Re: SN Printing Under WIN/NT


> At 04:26 PM 10/4/00 -0400, Berek wrote:
> >Lot's of problems printing hierarchy and cross reference charts under NT.
I
> >have SN installed on 1/2 dozen PC's. Some use Postscript drivers, others
> >PCL, some use both. All have same results printing on 1/2 dozen networked
> >printers. Basically, printing is garbled: letters, symbols, and lines
> >overlaying each other. Have to resort to doing NT alt-print screen and
> >pasting into MS Word, then printing from Word.
>
> The real problem is that there are no font preferences that just apply to
> printing, and the fonts for screen and printing don't match very well. We
> need to do some work at some point cleaning this up, as well as an overall
> preferences rewrite.
>
>
> >In Class view, C++ class members that are "private" have symbol
(transparent
> >diamond) for "public". Private members should have no symbol at all. Both
> >public and private have the public symbol.
> >
> >I'm concerned about comments made by SN Development (Syd Polk?) about
> >priority given to Perl parser. I know of more than 1/2 dozen companies in
my
> >area that have been forced to scale back use of SN because of many
problems
> >with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
> >Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
> >cannot be relied upon as a development tool. We desparately need accurate
> >cross references. Those of us that us SN are forced to fall back on
grep's.
> >Please review your priorities.
>
> C++ parser is a high priority; we use it internally.
>
> Thanks for your feedback; it really is appreciated.
>
> Syd Polk spolk@redhat.com
> Engineering Manager +1 415 777 9810 x 241
> Red Hat, Inc.
>
>
>
>
>