* 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ messages in thread
* Re: future plans 2000-11-20 15:37 ` Timothee Besset @ 2000-11-21 11:02 ` Mo DeJong 0 siblings, 0 replies; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ messages in thread
* Re: future plans 2000-11-21 15:18 ` Bruce Stephens @ 2000-11-21 15:47 ` Tom Tromey 0 siblings, 0 replies; 32+ 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] 32+ 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; 32+ 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] 32+ messages in thread
[parent not found: <4.3.1.2.20001121204418.00b9f480@mail.qeradiant.com>]
* Re: future plans [not found] <4.3.1.2.20001121204418.00b9f480@mail.qeradiant.com> @ 2000-11-21 19:50 ` Mo DeJong 0 siblings, 0 replies; 32+ messages in thread From: Mo DeJong @ 2000-11-21 19:50 UTC (permalink / raw) To: sourcenav On Tue, 21 Nov 2000, Timothee Besset wrote: > At 11:02 AM 11/21/00 -0800, you wrote: > >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? > > Wish I had time to do that. I'm on the user side of sourcenav. I could test > stuff and report bugs but I doubt I would code actual new things. My main > concern is too see source navigator evolve and possibly in a more open way. > But I've been told it will happen with 5.0 Testing and bug reporting is really hard, we welcome any help you could provide. > TTimo > > PS: Source navigator used to be commercial software, at that time I was not > using linux. Now I am, I could get my boss to pay for a license. Instead > it's GPL and people tell me to implement stuff myself. heh .. funny There is another option. If you are interested in a specific feature, you can negotiate a custom engineering contract with Red Hat. We are currently involved in a number of custom contracts with Source-Navigator deliverables. Mo DeJong Red Hat Inc ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <Thomas>]
[parent not found: <Heller's>]
[parent not found: <message>]
[parent not found: <of>]
[parent not found: <"Wed,>]
[parent not found: <"Fri,>]
[parent not found: <15>]
[parent not found: <"Mon,>]
[parent not found: <20>]
[parent not found: <"Tue,>]
[parent not found: <"Thu,>]
[parent not found: <3>]
[parent not found: <Aug>]
[parent not found: <2000>]
[parent not found: <15:23:58>]
[parent not found: <18:21:47>]
[parent not found: <+0200>]
* Getting started with tcl @ 2000-08-03 9:22 ` Thomas Heller 2000-08-03 9:40 ` Bruce Stephens 0 siblings, 1 reply; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ 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; 32+ 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] 32+ messages in thread
* Re: SN452 Installation 2000-09-15 5:24 ` Bruce Stephens @ 2000-09-15 11:20 ` Syd Polk 0 siblings, 0 replies; 32+ 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] 32+ messages in thread
[parent not found: <William>]
[parent not found: <Syd>]
[parent not found: <Rouviere,>]
end of thread, other threads:[~2000-11-21 19:50 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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] <4.3.1.2.20001121204418.00b9f480@mail.qeradiant.com> 2000-11-21 19:50 ` Mo DeJong [not found] <Thomas> [not found] ` <Heller's> [not found] ` <message> [not found] ` <of> [not found] ` <"Wed,> [not found] ` <"Fri,> [not found] ` <15> [not found] ` <"Mon,> [not found] ` <20> [not found] ` <"Tue,> [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 [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).