* Getting started with tcl @ 2000-08-03 9:22 ` Thomas Heller 2000-08-03 9:40 ` Bruce Stephens 0 siblings, 1 reply; 35+ messages in thread From: Thomas Heller @ 2000-08-03 9:22 UTC (permalink / raw) To: sourcenav I'm trying to understand how SN starts 'make'. Since I'm an absolute beginner to tcl, can someone please explain the following line (from share/gui/multimake.tcl, method ExecMake): set ret [catch {@@set make_fd [@@open "| $make_cmd" r]} msg] I can decipher most of it, but what do all the @'s mean? Is this standard tcl? I did not find something like this in the Ousterhout book... Thomas Heller ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting started with tcl 2000-08-03 9:22 ` Getting started with tcl Thomas Heller @ 2000-08-03 9:40 ` Bruce Stephens 2000-08-03 10:19 ` Syd Polk 0 siblings, 1 reply; 35+ messages in thread From: Bruce Stephens @ 2000-08-03 9:40 UTC (permalink / raw) To: sourcenav Thomas Heller <thomas.heller@ion-tof.com> writes: > I'm trying to understand how SN starts 'make'. > Since I'm an absolute beginner to tcl, can > someone please explain the following line > (from share/gui/multimake.tcl, method ExecMake): > > set ret [catch {@@set make_fd [@@open "| $make_cmd" r]} msg] > > I can decipher most of it, but what do all the @'s mean? > Is this standard tcl? I did not find something like > this in the Ousterhout book... Normally it would mean nothing: @@set would simply refer to a command called "@@set". However, the ChangeLog in itcl suggests that things have been changed so that @@ means the same as ::. So try thinking of it in those terms. Ousterhout's book is unfortunately too old to cover namespaces; however, the namespace(n) manpage describes it. Anyway, namespaces work sufficiently obviously that they shouldn't be surprising. I don't know why they'd have changed things in this way. -- Bruce Stephens Bruce.Stephens@MessagingDirect.com MessagingDirect(UK) Ltd <URL: http://www.MessagingDirect.com/ > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Getting started with tcl 2000-08-03 9:40 ` Bruce Stephens @ 2000-08-03 10:19 ` Syd Polk 0 siblings, 0 replies; 35+ messages in thread From: Syd Polk @ 2000-08-03 10:19 UTC (permalink / raw) To: Bruce Stephens, sourcenav At 05:40 PM 8/3/00 +0100, Bruce Stephens wrote: >Thomas Heller <thomas.heller@ion-tof.com> writes: > > > I'm trying to understand how SN starts 'make'. > > Since I'm an absolute beginner to tcl, can > > someone please explain the following line > > (from share/gui/multimake.tcl, method ExecMake): > > > > set ret [catch {@@set make_fd [@@open "| $make_cmd" r]} msg] > > > > I can decipher most of it, but what do all the @'s mean? > > Is this standard tcl? I did not find something like > > this in the Ousterhout book... > >Normally it would mean nothing: @@set would simply refer to a command >called "@@set". However, the ChangeLog in itcl suggests that things >have been changed so that @@ means the same as ::. @@ in incr Tcl 1.5 commands does mean the same as ::. >So try thinking of it in those terms. Ousterhout's book is >unfortunately too old to cover namespaces; however, the namespace(n) >manpage describes it. Anyway, namespaces work sufficiently obviously >that they shouldn't be surprising. > >I don't know why they'd have changed things in this way. This is an evil Cygnus-local hack to get namespaces to work in incr Tcl 1.5. This will go away once we put a snapshot of SN 5.0 on the web. Hopefully, in September. Syd Polk spolk@redhat.com Engineering Manager +1 415 777 9810 x 241 Red Hat, Inc. ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: Source navigator roadmap, features list, etc.? @ 2000-09-27 1:12 ` William Gacquer 2000-09-27 22:16 ` Bruce Stephens 2000-10-03 16:02 ` Mo DeJong 0 siblings, 2 replies; 35+ messages in thread From: William Gacquer @ 2000-09-27 1:12 UTC (permalink / raw) To: Syd Polk, sourcenav 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 > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Source navigator roadmap, features list, etc.? 2000-09-27 1:12 ` Source navigator roadmap, features list, etc.? William Gacquer @ 2000-09-27 22:16 ` Bruce Stephens 2000-09-28 9:15 ` Berek 2000-09-28 13:22 ` Syd Polk 2000-10-03 16:02 ` Mo DeJong 1 sibling, 2 replies; 35+ messages in thread From: Bruce Stephens @ 2000-09-27 22:16 UTC (permalink / raw) To: sourcenav William Gacquer <wgacquer@ubisoft.fr> writes: [...] > 16/ what else?.... uhhh, I am sure I have missed something.... More/better parsers. Emacs lisp is an obvious one, but more immediately PHP would be *really* handy. Possibly there are significant limitations of many of the existing parsers, but the one that's really annoying us at the moment is C++: it seems that often, trying to xref methods gives nothing at all useful (indeed, often nothing at all). Presumably this is because the C++ parser isn't up to the job. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Source navigator roadmap, features list, etc.? 2000-09-27 22:16 ` Bruce Stephens @ 2000-09-28 9:15 ` Berek 2000-09-28 13:26 ` Syd Polk 2000-09-28 13:22 ` Syd Polk 1 sibling, 1 reply; 35+ messages in thread From: Berek @ 2000-09-28 9:15 UTC (permalink / raw) To: sourcenav I've experienced the same problem with SN (4.5.1 and 4.5.2). C++ Xref is not reliable. Often have to fall back on GREP. For me, this is probably the most serious problem I have with SN. Also, xref for local variables doesn't seem to work at all. Nor does locating the declaration of local variables. Yes, I do have "generate references to local variables" checked in XRef preferences. ----- Original Message ----- From: "Bruce Stephens" <bruce@cenderis.demon.co.uk> To: <sourcenav@sources.redhat.com> Sent: Wednesday, September 27, 2000 16:44 Subject: Re: Source navigator roadmap, features list, etc.? > William Gacquer <wgacquer@ubisoft.fr> writes: > > [...] > > > 16/ what else?.... uhhh, I am sure I have missed something.... > > More/better parsers. Emacs lisp is an obvious one, but more > immediately PHP would be *really* handy. > > Possibly there are significant limitations of many of the existing > parsers, but the one that's really annoying us at the moment is C++: > it seems that often, trying to xref methods gives nothing at all > useful (indeed, often nothing at all). Presumably this is because the > C++ parser isn't up to the job. > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Source navigator roadmap, features list, etc.? 2000-09-28 9:15 ` Berek @ 2000-09-28 13:26 ` Syd Polk 0 siblings, 0 replies; 35+ messages in thread From: Syd Polk @ 2000-09-28 13:26 UTC (permalink / raw) To: sourcenav At 12:14 PM 9/28/00 -0400, Berek wrote: >I've experienced the same problem with SN (4.5.1 and 4.5.2). C++ Xref is not >reliable. Often have to fall back on GREP. For me, this is probably the most >serious problem I have with SN. > >Also, xref for local variables doesn't seem to work at all. Nor does >locating the declaration of local variables. Yes, I do have "generate >references to local variables" checked in XRef preferences. These are known problems. Hopefully, we can address them soon, or somebody in the community can dig into it. >----- Original Message ----- >From: "Bruce Stephens" <bruce@cenderis.demon.co.uk> >To: <sourcenav@sources.redhat.com> >Sent: Wednesday, September 27, 2000 16:44 >Subject: Re: Source navigator roadmap, features list, etc.? > > > > William Gacquer <wgacquer@ubisoft.fr> writes: > > > > [...] > > > > > 16/ what else?.... uhhh, I am sure I have missed something.... > > > > More/better parsers. Emacs lisp is an obvious one, but more > > immediately PHP would be *really* handy. > > > > Possibly there are significant limitations of many of the existing > > parsers, but the one that's really annoying us at the moment is C++: > > it seems that often, trying to xref methods gives nothing at all > > useful (indeed, often nothing at all). Presumably this is because the > > C++ parser isn't up to the job. > > Syd Polk spolk@redhat.com Engineering Manager +1 415 777 9810 x 241 Red Hat, Inc. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Source navigator roadmap, features list, etc.? 2000-09-27 22:16 ` Bruce Stephens 2000-09-28 9:15 ` Berek @ 2000-09-28 13:22 ` Syd Polk 1 sibling, 0 replies; 35+ messages in thread From: Syd Polk @ 2000-09-28 13:22 UTC (permalink / raw) To: sourcenav At 09:44 PM 9/27/00 +0100, Bruce Stephens wrote: >William Gacquer <wgacquer@ubisoft.fr> writes: > >[...] > > > 16/ what else?.... uhhh, I am sure I have missed something.... > >More/better parsers. Emacs lisp is an obvious one, but more >immediately PHP would be *really* handy. > >Possibly there are significant limitations of many of the existing >parsers, but the one that's really annoying us at the moment is C++: >it seems that often, trying to xref methods gives nothing at all >useful (indeed, often nothing at all). Presumably this is because the >C++ parser isn't up to the job. The C++ parser has many bugs; we have not had time to fix them. We will be putting up a GNATS database soon. The parser we want the most is a perl parser. Syd Polk spolk@redhat.com Engineering Manager +1 415 777 9810 x 241 Red Hat, Inc. ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: Source navigator roadmap, features list, etc.? 2000-09-27 1:12 ` Source navigator roadmap, features list, etc.? William Gacquer 2000-09-27 22:16 ` Bruce Stephens @ 2000-10-03 16:02 ` Mo DeJong 2000-10-04 10:25 ` Syd Polk 1 sibling, 1 reply; 35+ messages in thread From: Mo DeJong @ 2000-10-03 16:02 UTC (permalink / raw) To: sourcenav 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. > 2/ a better interface with CVS ( why not an integration of tkCVS in SN?) This one is a well known problem that we need to deal with. > 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) What exactly are you itching to drop into SN? Drag and Drop is something that seems really cool but I find to be less than useful unless it is very consistent across applications. > 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) Yup, I looked into this before but I could not fix it without a redesign. > 7/ a clever "replace-in-files" > 8/ an interface with GNAT (with tkGNAT?) > 9/ a autoconf/automake project creation as in kdevelop This one is hard to do in a general way, but we could do something like writing a configure.in for the user in the same way that we write a Makefile. > 10/ a possibility to hide/show all SN-controlled windows This is already implemented, see the Windows->Iconize Project menu item. > 11/ a search-and-replace dialog that can jump directly to the next occurence > by clicking on replace > 12/ working real-regular-expressions everywhere The trick will be how the user can tell the system to use a regexp vs a glob for a given entry box. Mo DeJong Red Hat Inc ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: Source navigator roadmap, features list, etc.? 2000-10-03 16:02 ` Mo DeJong @ 2000-10-04 10:25 ` Syd Polk 2000-10-04 13:27 ` SN Printing Under WIN/NT Berek 0 siblings, 1 reply; 35+ messages in thread From: Syd Polk @ 2000-10-04 10:25 UTC (permalink / raw) To: sourcenav 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* SN Printing Under WIN/NT 2000-10-04 10:25 ` Syd Polk @ 2000-10-04 13:27 ` Berek 2000-10-04 15:27 ` Mo DeJong 2000-10-05 12:06 ` Syd Polk 0 siblings, 2 replies; 35+ messages in thread From: Berek @ 2000-10-04 13:27 UTC (permalink / raw) To: sourcenav 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. > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN Printing Under WIN/NT 2000-10-04 13:27 ` SN Printing Under WIN/NT Berek @ 2000-10-04 15:27 ` Mo DeJong 2000-10-04 16:50 ` Paul Selormey 2000-10-05 12:06 ` Syd Polk 1 sibling, 1 reply; 35+ messages in thread From: Mo DeJong @ 2000-10-04 15:27 UTC (permalink / raw) To: sourcenav > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN Printing Under WIN/NT 2000-10-04 15:27 ` Mo DeJong @ 2000-10-04 16:50 ` Paul Selormey 2000-10-04 17:04 ` Mo DeJong 0 siblings, 1 reply; 35+ messages in thread From: Paul Selormey @ 2000-10-04 16:50 UTC (permalink / raw) To: sourcenav 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN Printing Under WIN/NT 2000-10-04 16:50 ` Paul Selormey @ 2000-10-04 17:04 ` Mo DeJong 0 siblings, 0 replies; 35+ messages in thread From: Mo DeJong @ 2000-10-04 17:04 UTC (permalink / raw) To: sourcenav 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN Printing Under WIN/NT 2000-10-04 13:27 ` SN Printing Under WIN/NT Berek 2000-10-04 15:27 ` Mo DeJong @ 2000-10-05 12:06 ` Syd Polk 2000-10-05 13:13 ` Berek 1 sibling, 1 reply; 35+ messages in thread From: Syd Polk @ 2000-10-05 12:06 UTC (permalink / raw) To: Berek, sourcenav 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN Printing Under WIN/NT 2000-10-05 12:06 ` Syd Polk @ 2000-10-05 13:13 ` Berek 0 siblings, 0 replies; 35+ messages in thread From: Berek @ 2000-10-05 13:13 UTC (permalink / raw) To: sourcenav, Syd Polk 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. > > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <05:03:28>]
[parent not found: <-0700>]
* SN452 Installation @ 2000-09-15 5:06 ` Rouviere, Stephane 2000-09-15 5:24 ` Bruce Stephens 0 siblings, 1 reply; 35+ messages in thread From: Rouviere, Stephane @ 2000-09-15 5:06 UTC (permalink / raw) To: sourcenav [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 968 bytes --] Hello, First, Thanks to SN team for their great work !! I am trying to use SN452. But, when I try to compile it, I have the following error: ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setflags': ../../../SN452-source/snavigator/hyper/dbsym.c:365: warning: subscript has type `char' ../../../SN452-source/snavigator/hyper/dbsym.c: In function `glob_nocase_pattern': ../../../SN452-source/snavigator/hyper/dbsym.c:489: warning: subscript has type `char' ../../../SN452-source/snavigator/hyper/dbsym.c:496: warning: subscript has type `char' ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setinfo': ../../../SN452-source/snavigator/hyper/dbsym.c:2382: warning: subscript has type `char' ../../../SN452-source/snavigator/hyper/dbsym.c: In function `GetOpenMode': ../../../SN452-source/snavigator/hyper/dbsym.c:2523: warning: subscript has type `char' gmake: *** [dbsym.o] Error 1 Could someone help me ? Thanks in advance Stéphane ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN452 Installation 2000-09-15 5:06 ` SN452 Installation Rouviere, Stephane @ 2000-09-15 5:24 ` Bruce Stephens 2000-09-15 11:20 ` Syd Polk 0 siblings, 1 reply; 35+ messages in thread From: Bruce Stephens @ 2000-09-15 5:24 UTC (permalink / raw) To: sourcenav "Rouviere, Stephane" <stephane.rouviere@intel.com> writes: [...] > I am trying to use SN452. > But, when I try to compile it, I have the following error: > > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setflags': > ../../../SN452-source/snavigator/hyper/dbsym.c:365: warning: subscript has > type `char' > ../../../SN452-source/snavigator/hyper/dbsym.c: In function > `glob_nocase_pattern': > ../../../SN452-source/snavigator/hyper/dbsym.c:489: warning: subscript has > type `char' > ../../../SN452-source/snavigator/hyper/dbsym.c:496: warning: subscript has > type `char' > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setinfo': > ../../../SN452-source/snavigator/hyper/dbsym.c:2382: warning: subscript has > type `char' > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `GetOpenMode': > ../../../SN452-source/snavigator/hyper/dbsym.c:2523: warning: subscript has > type `char' > gmake: *** [dbsym.o] Error 1 Those are all warnings. Is there an actual error somewhere? What's the compiler, and compile line? -- Bruce Stephens Bruce.Stephens@MessagingDirect.com MessagingDirect(UK) Ltd <URL: http://www.MessagingDirect.com/ > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN452 Installation 2000-09-15 5:24 ` Bruce Stephens @ 2000-09-15 11:20 ` Syd Polk 0 siblings, 0 replies; 35+ messages in thread From: Syd Polk @ 2000-09-15 11:20 UTC (permalink / raw) To: Bruce Stephens, sourcenav At 01:21 PM 9/15/00 +0100, Bruce Stephens wrote: >"Rouviere, Stephane" <stephane.rouviere@intel.com> writes: > >[...] > > > I am trying to use SN452. > > But, when I try to compile it, I have the following error: > > > > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setflags': > > ../../../SN452-source/snavigator/hyper/dbsym.c:365: warning: subscript has > > type `char' > > ../../../SN452-source/snavigator/hyper/dbsym.c: In function > > `glob_nocase_pattern': > > ../../../SN452-source/snavigator/hyper/dbsym.c:489: warning: subscript has > > type `char' > > ../../../SN452-source/snavigator/hyper/dbsym.c:496: warning: subscript has > > type `char' > > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `setinfo': > > ../../../SN452-source/snavigator/hyper/dbsym.c:2382: warning: subscript has > > type `char' > > ../../../SN452-source/snavigator/hyper/dbsym.c: In function `GetOpenMode': > > ../../../SN452-source/snavigator/hyper/dbsym.c:2523: warning: subscript has > > type `char' > > gmake: *** [dbsym.o] Error 1 > >Those are all warnings. Is there an actual error somewhere? What's >the compiler, and compile line? Better yet, what is the operating system? >-- >Bruce Stephens Bruce.Stephens@MessagingDirect.com >MessagingDirect(UK) Ltd <URL: http://www.MessagingDirect.com/ > Syd Polk spolk@redhat.com Engineering Manager +1 415 777 9810 x 241 Red Hat, Inc. ^ permalink raw reply [flat|nested] 35+ messages in thread
* future plans @ 2000-11-20 4:47 Simone Contini 2000-11-20 12:02 ` Syd Polk 2000-11-20 15:24 ` Mo DeJong 0 siblings, 2 replies; 35+ messages in thread From: Simone Contini @ 2000-11-20 4:47 UTC (permalink / raw) To: sourcenav Hi, Source Navigator is very Cool!! thank you for it! I'd like to know how i can read about future plans and if the projects will take advantages of GTK/GNOME. thank you Simone Contini Games & Tools Programmer Florence - Italy Email: s.contini@fol.it WWW: http://3dfx4ever.oltrelinux.com/ http://scontini.xoasis.com/ ICQ # : 25879128 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-20 4:47 future plans Simone Contini @ 2000-11-20 12:02 ` Syd Polk 2000-11-20 15:24 ` Mo DeJong 1 sibling, 0 replies; 35+ messages in thread From: Syd Polk @ 2000-11-20 12:02 UTC (permalink / raw) To: Simone Contini, sourcenav At 12:55 PM 11/20/00 +0100, Simone Contini wrote: >Hi, > > Source Navigator is very Cool!! thank you for it! I'd like to know >how i can read about future plans and if the projects will take advantages >of GTK/GNOME. We are in the process of evaluating our future strategy. However, it is highly unlikely we will ever do Source-Navigator in GTK or GNOME. We might add the capability of communicating with the GTK/GNOME desktop services, but these would be Tcl/Tk modifications. Syd Polk spolk@redhat.com Engineering Manager +1 415 777 9810 x 241 Red Hat, Inc. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-20 4:47 future plans Simone Contini 2000-11-20 12:02 ` Syd Polk @ 2000-11-20 15:24 ` Mo DeJong 2000-11-20 15:37 ` Timothee Besset 2000-11-20 16:13 ` Tom Tromey 1 sibling, 2 replies; 35+ messages in thread From: Mo DeJong @ 2000-11-20 15:24 UTC (permalink / raw) To: sourcenav On Mon, 20 Nov 2000, Simone Contini wrote: > Hi, > > Source Navigator is very Cool!! thank you for it! I'd like to know > how i can read about future plans and if the projects will take advantages > of GTK/GNOME. What features from Gtk or Gnome do you see as a "must have". The ability to do themes might be neat, but I don't see it as a critical component of a good IDE. Gnome has some configuration management stuff that might be handy if we needed it, but I don't think we do. If you have specific things you were thinking of, I would like to hear them. Keep in mind, that we can't depend on a Gnome feature because SN need to run under Windows too. Mo DeJong Red Hat Inc ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-20 15:24 ` Mo DeJong @ 2000-11-20 15:37 ` Timothee Besset 2000-11-21 11:02 ` Mo DeJong 2000-11-20 16:13 ` Tom Tromey 1 sibling, 1 reply; 35+ messages in thread From: Timothee Besset @ 2000-11-20 15:37 UTC (permalink / raw) To: sourcenav When can we expect an update to SN? The most important feature (imo) would be auto-completion. Auto-completion of symbols, listing the members when accessing a struct with -> or . Displaying the definition of the functions in a tooltip box when the mouse comes over them Displaying possible commentaries that are typed before struct definitions or function definitons Maybe even a window that would sit somewhere on your workspade and update to the class definition or inheritance of the class you are working in (well yeah, stuff you can get already, but it's not implemented in a very efficient way) I'm also lacking some docs or tips, maybe some of the stuff I want is there already. The behaviour of the windows is weird. If the file as been edited it would open a new window, but if not it would change the edit view. I didn't find the shortcuts to switch between editor views (like Alt+TAB on MSVC). I'm free to develop on win32 or linux. I prefer linux because on win98 my app kills the GDI resources and I have to reboot quite often. But I'm strongly tempted to go back to win32 cause I don't feel as efficient with sourcenav as I can be with MSDev Hope this helps.. TTimo Mo DeJong wrote: > On Mon, 20 Nov 2000, Simone Contini wrote: > >> Hi, >> >> Source Navigator is very Cool!! thank you for it! I'd like to know >> how i can read about future plans and if the projects will take advantages >> of GTK/GNOME. > > > What features from Gtk or Gnome do you see as a "must have". > The ability to do themes might be neat, but I don't see it > as a critical component of a good IDE. Gnome has some > configuration management stuff that might be handy if we > needed it, but I don't think we do. If you have specific > things you were thinking of, I would like to hear them. > Keep in mind, that we can't depend on a Gnome feature > because SN need to run under Windows too. > > Mo DeJong > Red Hat Inc > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-20 15:37 ` Timothee Besset @ 2000-11-21 11:02 ` Mo DeJong 0 siblings, 0 replies; 35+ messages in thread From: Mo DeJong @ 2000-11-21 11:02 UTC (permalink / raw) To: sourcenav On Mon, 20 Nov 2000, Timothee Besset wrote: > When can we expect an update to SN? What kind of "update" were you looking for? We are working on getting a snapshot of 5.0 out sometime soon, but that will not even be alpha quality. It would be a "hackers only" pre-release. > The most important feature (imo) would be auto-completion. > Auto-completion of symbols, listing the members when accessing a struct > with -> or . That would be neat. Are you willing to work on implementing this feature? > Displaying the definition of the functions in a tooltip box when the > mouse comes over them This should be trivial, perhaps a day or two to implement and test. > Displaying possible commentaries that are typed before struct > definitions or function definitons Not sure what you mean by this. > Maybe even a window that would sit somewhere on your workspade and > update to the class definition or inheritance of the class you are > working in (well yeah, stuff you can get already, but it's not > implemented in a very efficient way) Is it so hard to switch to the Hier window or the class viewer? > I'm also lacking some docs or tips, maybe some of the stuff I want is > there already. > The behaviour of the windows is weird. If the file as been edited it > would open a new window, but if not it would change the edit view. I > didn't find the shortcuts to switch between editor views (like Alt+TAB > on MSVC). > I'm free to develop on win32 or linux. I prefer linux because on win98 > my app kills the GDI resources and I have to reboot quite often. But I'm > strongly tempted to go back to win32 cause I don't feel as efficient > with sourcenav as I can be with MSDev Well, feelings are a tricky thing. They might be good or they might have nothing to do with reality. When it comes to a GUI, folks start to get "bad feelings" over little things like a window taking too long to redraw. Don't forget that you do have the source, you can adapt it to better suite your "feelings". When was the last time you were able to reprogram MSDev to get around something you did not like? Mo DeJong Red Hat Inc ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-20 15:24 ` Mo DeJong 2000-11-20 15:37 ` Timothee Besset @ 2000-11-20 16:13 ` Tom Tromey 2000-11-21 12:22 ` Syd Polk 1 sibling, 1 reply; 35+ messages in thread From: Tom Tromey @ 2000-11-20 16:13 UTC (permalink / raw) To: Mo DeJong; +Cc: sourcenav >>>>> "Mo" == Mo DeJong <mdejong@cygnus.com> writes: Mo> What features from Gtk or Gnome do you see as a "must have". Mo> The ability to do themes might be neat, but I don't see it Mo> as a critical component of a good IDE. Gnome has some Mo> configuration management stuff that might be handy if we Mo> needed it, but I don't think we do. Themes are nice, but they are just candy. Most people would rather have a tool that works well than one that conforms to their environment. (Well, most people would prefer both, I'd imagine...) The config code is nice, and will get much nicer (with GConf), but unless you want network transparency and the use of weird back ends it isn't very important. There are two more important things that Gnome has that S-N currently can't do: * Drag and drop * Session management Both of these can be written as Tcl extensions though. The D&D protocol is (I believe) well-documented and in use by a few groups (both Gnome and KDE at least). (I know you've argued against D&D before, but I've never understood your argument.) Gnome's session management is just XSMP. There is an (ugly) X library to help you do this; Gnome just wraps it with a nicer API. (At some point session management and configuration storage might tie together somehow. That would be harder to emulate.) Gnome also has some other things, like the ability to play sounds in response to certain events (activate a button widget, get a beep). This is along the lines of themability though -- not deeply important. The really important Gnome stuff comes later: componentization of everything. Maybe it will be possible to use this from Tcl, too, with some work. I don't know. Maybe components aren't important for an IDE. I think they could be used though. For instance the debugger gui could be plugged in to S-N somehow. Tom ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-20 16:13 ` Tom Tromey @ 2000-11-21 12:22 ` Syd Polk 2000-11-21 12:31 ` Mo DeJong 2000-11-21 12:32 ` Tom Tromey 0 siblings, 2 replies; 35+ messages in thread From: Syd Polk @ 2000-11-21 12:22 UTC (permalink / raw) To: tromey, Mo DeJong; +Cc: sourcenav >There are two more important things that Gnome has that S-N currently >can't do: > >* Drag and drop >* Session management > >Both of these can be written as Tcl extensions though. > >The D&D protocol is (I believe) well-documented and in use by a few >groups (both Gnome and KDE at least). (I know you've argued against >D&D before, but I've never understood your argument.) I don't remember arguing against the idea of drag-and-drop. It is a great feature which I would love to have. >Gnome's session management is just XSMP. There is an (ugly) X library >to help you do this; Gnome just wraps it with a nicer API. (At some >point session management and configuration storage might tie together >somehow. That would be harder to emulate.) I don't know what "session management" means. >Gnome also has some other things, like the ability to play sounds in >response to certain events (activate a button widget, get a beep). >This is along the lines of themability though -- not deeply important. > > >The really important Gnome stuff comes later: componentization of >everything. Maybe it will be possible to use this from Tcl, too, with >some work. I don't know. > >Maybe components aren't important for an IDE. I think they could be >used though. For instance the debugger gui could be plugged in to S-N >somehow. The problem is, of course, that this is a major rewrite of something. Either Tk has to be fitted with it, or we have to rewrite the entire GUI in GNOME. I would rather not spend several man-years doing the latter. Syd Polk spolk@redhat.com Engineering Manager +1 415 777 9810 x 241 Red Hat, Inc. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-21 12:22 ` Syd Polk @ 2000-11-21 12:31 ` Mo DeJong 2000-11-21 12:32 ` Tom Tromey 1 sibling, 0 replies; 35+ messages in thread From: Mo DeJong @ 2000-11-21 12:31 UTC (permalink / raw) To: sourcenav On Tue, 21 Nov 2000, Syd Polk wrote: > > >There are two more important things that Gnome has that S-N currently > >can't do: > > > >* Drag and drop > >* Session management > > > >Both of these can be written as Tcl extensions though. > > > >The D&D protocol is (I believe) well-documented and in use by a few > >groups (both Gnome and KDE at least). (I know you've argued against > >D&D before, but I've never understood your argument.) > > I don't remember arguing against the idea of drag-and-drop. It is a great > feature which I would love to have. Syd, I think he was talking about me. It is true, I have seen some drag and drop interfaces that are just stupid and a waste of time. On the other hand, I have seen some good uses of drag and drop too. For example, on the Mac you can drag a URL out of the web browser and put it on the desktop. It turns into a click-able thingy that will open up the web browser at the given URL later. Sure, it is just a bookmark but it was a reasonable interface. I have also seen some stupid uses of drap and drop, where it just gets in the way instead of helping. One thing that might be handy in SN is to drag a set of new files into the symbol browser, that could add the given files to the project. Of course, we already provide a way to add a directory or set of files to the project so I don't think anyone is going to be beating down the door for that feature. > >Gnome's session management is just XSMP. There is an (ugly) X library > >to help you do this; Gnome just wraps it with a nicer API. (At some > >point session management and configuration storage might tie together > >somehow. That would be harder to emulate.) > > I don't know what "session management" means. Well, for starters SN could open up with the windows in the same place and open on the same tools as when it shut down. Some folks really like this sort of interface, others could not care less. Mo DeJong Red Hat Inc ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-21 12:22 ` Syd Polk 2000-11-21 12:31 ` Mo DeJong @ 2000-11-21 12:32 ` Tom Tromey 2000-11-21 15:18 ` Bruce Stephens 2000-11-21 15:41 ` Syd Polk 1 sibling, 2 replies; 35+ messages in thread From: Tom Tromey @ 2000-11-21 12:32 UTC (permalink / raw) To: Syd Polk; +Cc: Mo DeJong, sourcenav >> Gnome's session management is just XSMP. There is an (ugly) X library >> to help you do this; Gnome just wraps it with a nicer API. (At some >> point session management and configuration storage might tie together >> somehow. That would be harder to emulate.) Syd> I don't know what "session management" means. When you log out, Gnome can save the state of all applications (all those which support session management) and then later restart the session where you left off. The idea is applications will remember what documents were open, cursor positions, etc. Tom ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-21 12:32 ` Tom Tromey @ 2000-11-21 15:18 ` Bruce Stephens 2000-11-21 15:47 ` Tom Tromey 2000-11-21 15:41 ` Syd Polk 1 sibling, 1 reply; 35+ messages in thread From: Bruce Stephens @ 2000-11-21 15:18 UTC (permalink / raw) To: sourcenav Tom Tromey <tromey@cygnus.com> writes: > >> Gnome's session management is just XSMP. There is an (ugly) X library > >> to help you do this; Gnome just wraps it with a nicer API. (At some > >> point session management and configuration storage might tie together > >> somehow. That would be harder to emulate.) > > Syd> I don't know what "session management" means. > > When you log out, Gnome can save the state of all applications (all > those which support session management) and then later restart the > session where you left off. > > The idea is applications will remember what documents were open, > cursor positions, etc. I don't think this requires anything that Tk doesn't already have, does it? Can't an application just use "wm protocol <win> WM_SAVE_YOURSELF" and do something to save its state? Hmm, I guess there's a bit more to it than that: to restore, it would need to be able to identify an instance of information, but overall it shouldn't be *that* much more. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-21 15:18 ` Bruce Stephens @ 2000-11-21 15:47 ` Tom Tromey 0 siblings, 0 replies; 35+ messages in thread From: Tom Tromey @ 2000-11-21 15:47 UTC (permalink / raw) To: Bruce Stephens; +Cc: sourcenav >>>>> "Bruce" == Bruce Stephens <bruce@cenderis.demon.co.uk> writes: Bruce> I don't think this requires anything that Tk doesn't already Bruce> have, does it? Can't an application just use "wm protocol Bruce> <win> WM_SAVE_YOURSELF" and do something to save its state? Gnome can already interface with applications that use this method, via a proxy. However, XSMP has more sophisticated facilities than those available via the old ICCCM session management protocol. Tom ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: future plans 2000-11-21 12:32 ` Tom Tromey 2000-11-21 15:18 ` Bruce Stephens @ 2000-11-21 15:41 ` Syd Polk 1 sibling, 0 replies; 35+ messages in thread From: Syd Polk @ 2000-11-21 15:41 UTC (permalink / raw) To: tromey; +Cc: Mo DeJong, sourcenav At 01:40 PM 11/21/00 -0700, Tom Tromey wrote: > >> Gnome's session management is just XSMP. There is an (ugly) X library > >> to help you do this; Gnome just wraps it with a nicer API. (At some > >> point session management and configuration storage might tie together > >> somehow. That would be harder to emulate.) > >Syd> I don't know what "session management" means. > >When you log out, Gnome can save the state of all applications (all >those which support session management) and then later restart the >session where you left off. > >The idea is applications will remember what documents were open, >cursor positions, etc. > >Tom Source-Navigator does this, to a limited extent. It's buggy as all get out. Syd Polk spolk@redhat.com Engineering Manager +1 415 777 9810 x 241 Red Hat, Inc. ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <Pine.SOL.3.91.1001005110411.28967A-100000@cse.cygnus.com>]
* Re: SN Printing Under WIN/NT [not found] <Pine.SOL.3.91.1001005110411.28967A-100000@cse.cygnus.com> @ 2000-10-05 13:07 ` Berek 2000-10-05 13:28 ` Mo DeJong 2000-10-05 14:06 ` Ben Elliston 0 siblings, 2 replies; 35+ messages in thread From: Berek @ 2000-10-05 13:07 UTC (permalink / raw) To: sourcenav 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 > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN Printing Under WIN/NT 2000-10-05 13:07 ` SN Printing Under WIN/NT Berek @ 2000-10-05 13:28 ` Mo DeJong 2000-10-05 13:49 ` Berek 2000-10-05 14:06 ` Ben Elliston 1 sibling, 1 reply; 35+ messages in thread From: Mo DeJong @ 2000-10-05 13:28 UTC (permalink / raw) To: sourcenav 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN Printing Under WIN/NT 2000-10-05 13:28 ` Mo DeJong @ 2000-10-05 13:49 ` Berek 0 siblings, 0 replies; 35+ messages in thread From: Berek @ 2000-10-05 13:49 UTC (permalink / raw) To: Mo DeJong, sourcenav 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 > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: SN Printing Under WIN/NT 2000-10-05 13:07 ` SN Printing Under WIN/NT Berek 2000-10-05 13:28 ` Mo DeJong @ 2000-10-05 14:06 ` Ben Elliston 1 sibling, 0 replies; 35+ messages in thread From: Ben Elliston @ 2000-10-05 14:06 UTC (permalink / raw) To: Berek; +Cc: sourcenav 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <William>]
[parent not found: <Syd>]
[parent not found: <Rouviere,>]
end of thread, other threads:[~2000-11-21 15:47 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Thomas> [not found] ` <Heller's> [not found] ` <message> [not found] ` <of> [not found] ` <"Tue,> [not found] ` <"Fri,> [not found] ` <15> [not found] ` <"Wed,> [not found] ` <"Mon,> [not found] ` <20> [not found] ` <"Thu,> [not found] ` <3> [not found] ` <Aug> [not found] ` <2000> [not found] ` <15:23:58> [not found] ` <-0800> [not found] ` <Mo> [not found] ` <18:21:47> [not found] ` <+0200> 2000-08-03 9:22 ` Getting started with tcl Thomas Heller 2000-08-03 9:40 ` Bruce Stephens 2000-08-03 10:19 ` Syd Polk 2000-09-27 1:12 ` Source navigator roadmap, features list, etc.? William Gacquer 2000-09-27 22:16 ` Bruce Stephens 2000-09-28 9:15 ` Berek 2000-09-28 13:26 ` Syd Polk 2000-09-28 13:22 ` Syd Polk 2000-10-03 16:02 ` Mo DeJong 2000-10-04 10:25 ` Syd Polk 2000-10-04 13:27 ` SN Printing Under WIN/NT Berek 2000-10-04 15:27 ` Mo DeJong 2000-10-04 16:50 ` Paul Selormey 2000-10-04 17:04 ` Mo DeJong 2000-10-05 12:06 ` Syd Polk 2000-10-05 13:13 ` Berek [not found] ` <05:03:28> [not found] ` <-0700> 2000-09-15 5:06 ` SN452 Installation Rouviere, Stephane 2000-09-15 5:24 ` Bruce Stephens 2000-09-15 11:20 ` Syd Polk 2000-11-20 4:47 future plans Simone Contini 2000-11-20 12:02 ` Syd Polk 2000-11-20 15:24 ` Mo DeJong 2000-11-20 15:37 ` Timothee Besset 2000-11-21 11:02 ` Mo DeJong 2000-11-20 16:13 ` Tom Tromey 2000-11-21 12:22 ` Syd Polk 2000-11-21 12:31 ` Mo DeJong 2000-11-21 12:32 ` Tom Tromey 2000-11-21 15:18 ` Bruce Stephens 2000-11-21 15:47 ` Tom Tromey 2000-11-21 15:41 ` Syd Polk [not found] <Pine.SOL.3.91.1001005110411.28967A-100000@cse.cygnus.com> 2000-10-05 13:07 ` SN Printing Under WIN/NT Berek 2000-10-05 13:28 ` Mo DeJong 2000-10-05 13:49 ` Berek 2000-10-05 14:06 ` Ben Elliston [not found] <William> [not found] <Syd> [not found] <Rouviere,>
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).