RE: Lets rename insight to "insight" (imagine that)

RE: Lets rename insight to "insight" (imagine that)

[Fabrice Gautier]

> -----Original Message-----
> From: Eray Ozkural (exa) [ mailto:erayo@cs.bilkent.edu.tr ]
> Sent: Thursday, November 16, 2000 3:58 PM
> To: Mo DeJong
> Cc: insight@sources.redhat.com
> Subject: Re: Lets rename insight to "insight" (imagine that)
> 
> 
> Mo DeJong wrote:
> > 
> > I suggest we change the name of the Insight executable
> > to "insight". This will make things far more intuitive
> 
> Well, that's currently the case with the debian version!
> 
> orion:debian$ dpkg -L insight | grep bin/
> /usr/bin/insight-bin
> /usr/bin/insight
> 
> Thanks!

And I would had that debian has a mechanisme called alternatives to handle a
case like this. It would allows to install both original gdb and insight or
only one of them without conflict and allow you to choose which one is
really launched by the gdb 
command.
(Does the debian insight package use alterntives?)

This, in the end seems to be a matter of distribution.
I don't know if there is such a mechanisme with RPMs, its quite an
fundamental feature for Debian...

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: Lets rename insight to "insight" (imagine that)

[Eray Ozkural (exa)]

Fabrice Gautier wrote:
> 
> 
> And I would had that debian has a mechanisme called alternatives to handle a
> case like this. It would allows to install both original gdb and insight or
> only one of them without conflict and allow you to choose which one is
> really launched by the gdb
> command.
> (Does the debian insight package use alterntives?)
> 

Uh, no. It doesn't use alternatives because we don't think that a graphical
gdb is an alternative for gdb ;) Seriously, there's already gdb5.0 in a
separate package and we think that one of them is not really a replacement
for the other because there might be other programs which would assume
the pure gdb.

> This, in the end seems to be a matter of distribution.
> I don't know if there is such a mechanisme with RPMs, its quite an
> fundamental feature for Debian...

Yes, alternatives are nice. In fact I'd like to make it an alternative
for, let's say graphical-debugger. Something like that.

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Lets rename insight to "insight" (imagine that)

[Eray Ozkural (exa)]

Mo DeJong wrote:
> 
> Some on disk numbers from my build:
> 
> ls -la ~/project/install/insight/bin/gdb
> -rwxr-xr-x    1 mo       mo        8797610 Oct 26 09:36 /home/mo/project/install/insight/bin/gdb
> 
> % ls -la /usr/bin/gdb
> -rwxr-xr-x    1 root     root      1290416 Mar  7  2000 /usr/bin/gdb

These are the debian numbers:
orion:exa$ ls -al /usr/bin/insight*
-rwxr-xr-x    1 root     root           73 Oct 31 03:57 /usr/bin/insight
-rwxr-xr-x    1 root     root      1626876 Oct 31 03:57 /usr/bin/insight-bin
orion:exa$ ls -al /usr/bin/gdb* 
-rwxr-xr-x    1 root     root      1493504 Aug 17 02:12 /usr/bin/gdb
-rwxr-xr-x    1 root     root         4596 Jan 31  2000 /usr/bin/gdbio

What architecture are you running?

BTW, stripping insight was a good idea after all. ;) [Still, I'm going
to provide an insight-static package for convenience]

Thanks,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Lets rename insight to "insight" (imagine that)

[Chris G. Demetriou]

mdejong@cygnus.com (Mo DeJong) writes:
> You think there is no confusion involved in taking over the
> name of a well known command and replacing it with the GUI
> tool? While I would agree that shipping two versions of
> gdb on a distro is none too good, it is better than
> not including Insight because it conflicts with the
> existing gdb install (which is our current situation).
> There are also lots of folks that would want to install
> Insight on an existing system. Do we tell those
> folks it is not possible to install Insight unless
> they first un-install the existing gdb RPM?

Right, so, support the Right Thing but allow for the Not Right But
Useful thing.  8-)

By default, support the "Right Thing": gdb and insight both built and
installed with the expected behaviour, and preferably only one single
'large' binary.

Supply configure option so that people who can't tolerate the Right
Thing (e.g. because they have a 'gdb' that they don't want to clobber)
can disable the use of the 'gdb' name and use insight -nw if they
really want that functionality.  For orthogonality, maybe do the same
thing and allow use of the 'insight' name to be disabled, requiring
use of 'gdb -w'


You say it isn't so hard to use "insight -nw" to get the non-windowed
version of gdb-with-insight-windowing-extensions.

It's not, but people expect to get gdb by typing "gdb."  8-)

It sounds like i'm not the only one who's had to provide a local
mechanism to allow both windowed and non-windowed versions to be
accessed easily, with the default 'gdb' getting the 'normal' gdb
behaviour, because of just this issue...


chris

Re: Lets rename insight to "insight" (imagine that)

[Eray Ozkural (exa)]

Mo DeJong wrote:
> 
> I suggest we change the name of the Insight executable
> to "insight". This will make things far more intuitive

Well, that's currently the case with the debian version!

orion:debian$ dpkg -L insight | grep bin/
/usr/bin/insight-bin
/usr/bin/insight

Thanks!

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo

Re: Lets rename insight to "insight" (imagine that)

[Mo DeJong]

On Thu, 16 Nov 2000, Jim Ingham wrote:

> > The way I see it, Insight is a GUI debugger interface. It also
> > supports a gdb command line interface when run with the -nw
> > flag. What distro packager is going to think, hey lets replace
> > gdb with gdb + some extra mostly-unused stuff thrown in?
> 
> But, in fact, insight IS a COMPLETE copy of gdb.  If you have it,
> there is no reason for another copy of gdb.  So you need to make
> it easy to use the same binary for gdb command-line & gdb with
> the Tk bits thrown in.

Yes, yes, it also supports gdb, but at its core it is a GUI for gdb.
Running "insight -nw" for command line gdb does not seem all
that difficult to me.

> > Nope. By default we should install just the "insight" executable.
> > We should not clobber the system gdb (by putting our gdb 5.0 on the
> > PATH).
> 
> I disagree.  Why would you want to introduce the confusion of
> shipping two potentially different gdb's.  Insight is a complete
> fully featured command line debugger, as well as a complete,
> fully featured GUI debugger.  No other copy is necessary, and
> the support costs of "How do I start Insight" are trivial
> compared to sorting out which of the two versions of gdb
> on the system were actually used...

You think there is no confusion involved in taking over the
name of a well known command and replacing it with the GUI
tool? While I would agree that shipping two versions of
gdb on a distro is none too good, it is better than
not including Insight because it conflicts with the
existing gdb install (which is our current situation).
There are also lots of folks that would want to install
Insight on an existing system. Do we tell those
folks it is not possible to install Insight unless
they first un-install the existing gdb RPM?

Also, for every one person who writes in with a
"How do I run Insight" question, there are 10
more who could not figure it out and just
gave up.

> > Insight is a lot bigger than command line gdb.
> 
> This must be wrong.  I bet the one in /home/mo has debugging symbols
> still in it, and the one in /usr/bin/gdb is stripped.  No way Insight is 
> that much bigger than gdb, even if you include the Tcl/Tk/Tix libraries
> (which ought to be shared, but I don't think we ship it that way) I 
> don't think you get an extra 7.5 meg.  And the GUI related code is
> gdb is not all that much...

Oh, yeah you are probably right. Insight would still be a meg or two
bigger since Tcl/Tk is not all that small. Don't forget all the
extra files that Tcl/Tk needs on disk too, executable size is
not the only concern.

Mo DeJong
Red Hat Inc

Re: Lets rename insight to "insight" (imagine that)

[Chris G. Demetriou]

mdejong@cygnus.com (Mo DeJong) writes:
> Some on disk numbers from my build:
> 
> ls -la ~/project/install/insight/bin/gdb
> -rwxr-xr-x    1 mo       mo        8797610 Oct 26 09:36 /home/mo/project/install/insight/bin/gdb
> 
> % ls -la /usr/bin/gdb
> -rwxr-xr-x    1 root     root      1290416 Mar  7  2000 /usr/bin/gdb

I get something more like:

33 [highland] gas % ls -la
/usr/local/sbtools-mips64-sb1sim-{1.3.10,1.4.9}/bin/mips64-sb1sim-gdb
-rwxr-xr-x   1 root      6003252 Oct  1 18:37 /usr/local/sbtools-mips64-sb1sim-1.3.10/bin/mips64-sb1sim-gdb*
-rwxr-xr-x   1 root     11415142 Oct 31 05:46 /usr/local/sbtools-mips64-sb1sim-1.4.9/bin/mips64-sb1sim-gdb*
34 [highland] gas % size /usr/local/sbtools-mips64-sb1sim-{1.3.10,1.4.9}/bin/mips64-sb1sim-gdb
   text    data     bss     dec     hex filename
2067527   47893  119652 2235072  221ac0
/usr/local/sbtools-mips64-sb1sim-1.3.10/bin/mips64-sb1sim-gdb
3906670  144000  209788 4260458  41026a
/usr/local/sbtools-mips64-sb1sim-1.4.9/bin/mips64-sb1sim-gdb

(solarisl host, "1.3.10" -> gdb 4.18 + mods, "1.4.9" -> gdb+insight
from head of cvs as of a few weeks ago + mods.  Both include 'sim'
bits.  I can't easily do a head-to-head comparison right now.)


> Insight is a lot bigger than command line gdb.

So, I think i'd disagree that it's _that_ much bigger.  (2x, not 7x.
but it'll change by platform, of course, and with availability of
shlibs, etc.)


> > I think, in general, that's probably the appropriate solution to the
> > issue.
> 
> That would still clobber the existing gdb. It means we can't
> make an RPM for Insight because it would conflict with
> the /usr/bin/gdb executable from regular gdb.

Right, so, if what i proposed previously is deemed to be _not_ the
right solution, then as far as I'm concerned, the code should:

(1) build both gdb and insight binaries in the same source tree
(differing in what code they link against).

(2) install both.

(3) provide configure options to disable build/install of one or the
other.

I'm not sure how spread out the checks for the window system are
though -- it might be Hard to do this.


as has been said by others, when you build insight, you really _do_
build a complete GDB, and that's what you get if you request the
non-windowed version.

It seems ... wasteful and, to me, wrong to require a completely
separate build and install (incl. space for installed binaries) if you
happen to want one version windowed and one version without.


cgd

Re: Lets rename insight to "insight" (imagine that)

[Jim Ingham]

Mo,

> From: Mo DeJong <mdejong@cygnus.com>
> Date: Thu Nov 16, 2000  02:45:00 PM US/Pacific
> To: insight@sources.redhat.com
> Subject: Re: Lets rename insight to "insight" (imagine that)
> 
> > mdejong@cygnus.com (Mo DeJong) writes:
> 
> > > What is the cause of these problems? The unfortunate
> > > naming of the Insight executable. For some reason
> > > it is called "gdb". This is in despite of the fact
> > > that it is clearly not the gdb that most people
> > > expect to get when typing the command "gdb".
> > > 
> > > I suggest we change the name of the Insight executable
> > > to "insight". This will make things far more intuitive
> > > and will save us time and money in the long run.
> > > 
> > > I would also like to get Insight installed on the
> > > default Red Hat release, but that is not currently
> > > possible because /usr/bin/gdb is already taken.
> > 
> > What is /usr/bin/gdb taken by, if not gdb?  and, insight without
> > windows _is_ gdb, with some extra mostly-unused stuff thrown in, eh?
> 
> The way I see it, Insight is a GUI debugger interface. It also
> supports a gdb command line interface when run with the -nw
> flag. What distro packager is going to think, hey lets replace
> gdb with gdb + some extra mostly-unused stuff thrown in?

But, in fact, insight IS a COMPLETE copy of gdb.  If you have it, there is no reason for another copy of gdb.  So you need to make it easy to use the same binary for gdb command-line & gdb with the Tk bits thrown in.

> 
> > Well, it seems to me that by default, you want to install
> > (gdb==insight), under the names gdb and insight, with the former
> > providing the normal behaviour, and the latter providing windows.
> 
> Nope. By default we should install just the "insight" executable.
> We should not clobber the system gdb (by putting our gdb 5.0 on the
> PATH).

I disagree.  Why would you want to introduce the confusion of shipping two potentially different gdb's.  Insight is a complete fully featured command line debugger, as well as a complete, fully featured GUI debugger.  No other copy is necessary, and the support costs of "How do I start Insight" are trivial compared to sorting out which of the two versions of gdb on the system were actually used...

> 
> > It's a shame to have to waste N more megabytes on a gdb binary, when
> > insight will do either.
> 
> 
> Some on disk numbers from my build:
> 
> ls -la ~/project/install/insight/bin/gdb
> -rwxr-xr-x    1 mo       mo        8797610 Oct 26 09:36 /home/mo/project/
> install/insight/bin/gdb
> 
> % ls -la /usr/bin/gdb
> -rwxr-xr-x    1 root     root      1290416 Mar  7  2000 /usr/bin/gdb
> 
> 
> Insight is a lot bigger than command line gdb.
> 
>  

This must be wrong.  I bet the one in /home/mo has debugging symbols still in it, and the one in /usr/bin/gdb is stripped.  No way Insight is that much bigger than gdb, even if you include the Tcl/Tk/Tix libraries (which ought to be shared, but I don't think we ship it that way) I don't think you get an extra 7.5 meg.  And the GUI related code is gdb is not all that much...

> > My personal favorite solution (and what I use in my own source trees)
> > is to:
> > 
> > 	* whack top.c so that use_windows = 0 by default.
> > 
> > 	* install as gdb.
> > 
> > 	* if insight-style windowing support is present, a simple
> > 	script called 'insight' to invoke gdb with the -w flag and the
> > 	rest of the remaining script arguments.

Or just tell people to do 

alias insight="gdb -w"

> > 
> > I think, in general, that's probably the appropriate solution to the
> > issue.
> 
> That would still clobber the existing gdb. It means we can't
> make an RPM for Insight because it would conflict with
> the /usr/bin/gdb executable from regular gdb.

I really don't think you want to be shipping two gdb's but that is your business, not mine...

Jim

--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: Lets rename insight to "insight" (imagine that)

[Mo DeJong]

> mdejong@cygnus.com (Mo DeJong) writes:

> > What is the cause of these problems? The unfortunate
> > naming of the Insight executable. For some reason
> > it is called "gdb". This is in despite of the fact
> > that it is clearly not the gdb that most people
> > expect to get when typing the command "gdb".
> > 
> > I suggest we change the name of the Insight executable
> > to "insight". This will make things far more intuitive
> > and will save us time and money in the long run.
> > 
> > I would also like to get Insight installed on the
> > default Red Hat release, but that is not currently
> > possible because /usr/bin/gdb is already taken.
> 
> What is /usr/bin/gdb taken by, if not gdb?  and, insight without
> windows _is_ gdb, with some extra mostly-unused stuff thrown in, eh?

The way I see it, Insight is a GUI debugger interface. It also
supports a gdb command line interface when run with the -nw
flag. What distro packager is going to think, hey lets replace
gdb with gdb + some extra mostly-unused stuff thrown in?

> Well, it seems to me that by default, you want to install
> (gdb==insight), under the names gdb and insight, with the former
> providing the normal behaviour, and the latter providing windows.

Nope. By default we should install just the "insight" executable.
We should not clobber the system gdb (by putting our gdb 5.0 on the
PATH).

> It's a shame to have to waste N more megabytes on a gdb binary, when
> insight will do either.


Some on disk numbers from my build:

ls -la ~/project/install/insight/bin/gdb
-rwxr-xr-x    1 mo       mo        8797610 Oct 26 09:36 /home/mo/project/install/insight/bin/gdb

% ls -la /usr/bin/gdb
-rwxr-xr-x    1 root     root      1290416 Mar  7  2000 /usr/bin/gdb


Insight is a lot bigger than command line gdb.

 
> My personal favorite solution (and what I use in my own source trees)
> is to:
> 
> 	* whack top.c so that use_windows = 0 by default.
> 
> 	* install as gdb.
> 
> 	* if insight-style windowing support is present, a simple
> 	script called 'insight' to invoke gdb with the -w flag and the
> 	rest of the remaining script arguments.
> 
> I think, in general, that's probably the appropriate solution to the
> issue.

That would still clobber the existing gdb. It means we can't
make an RPM for Insight because it would conflict with
the /usr/bin/gdb executable from regular gdb.

Mo DeJong
Red Hat Inc

Re: Lets rename insight to "insight" (imagine that)

[Duane Ellis]

I'm sure this has been suggested:

a)  Change the default option/flag/whatever to be "-nw"
    ie: NO WINDOWS is the default.

b)  Create a stub program called "insight"
    this stub program exec's GDB with the "--insight"
    flag.

    Maybe this stub is a shell script, maybe it's C program.  
    I don't care.

Problem solved.

The only people this will directly effect are those who
need to debug "insight" it self.

They will need one additional piece of information, knowledge
that "gdb --insight" ... rest of your args is how you
debug insight.

That group is limited to mostly those people on this mailing list.

-Duane.

Re: Lets rename insight to "insight" (imagine that)

[Chris G. Demetriou]

mdejong@cygnus.com (Mo DeJong) writes:
> What is the cause of these problems? The unfortunate
> naming of the Insight executable. For some reason
> it is called "gdb". This is in despite of the fact
> that it is clearly not the gdb that most people
> expect to get when typing the command "gdb".
> 
> I suggest we change the name of the Insight executable
> to "insight". This will make things far more intuitive
> and will save us time and money in the long run.
> 
> I would also like to get Insight installed on the
> default Red Hat release, but that is not currently
> possible because /usr/bin/gdb is already taken.

What is /usr/bin/gdb taken by, if not gdb?  and, insight without
windows _is_ gdb, with some extra mostly-unused stuff thrown in, eh?

Well, it seems to me that by default, you want to install
(gdb==insight), under the names gdb and insight, with the former
providing the normal behaviour, and the latter providing windows.

It's a shame to have to waste N more megabytes on a gdb binary, when
insight will do either.


My personal favorite solution (and what I use in my own source trees)
is to:

	* whack top.c so that use_windows = 0 by default.

	* install as gdb.

	* if insight-style windowing support is present, a simple
	script called 'insight' to invoke gdb with the -w flag and the
	rest of the remaining script arguments.

I think, in general, that's probably the appropriate solution to the
issue.


cgd

Lets rename insight to "insight" (imagine that)

[Mo DeJong]

Ok, I just can't take it anymore. For some time,
I have put up a constant stream of bug reports
and requests for help related to the naming
of Insight. The most common seem to be:

1. How do I start insight?

2. I keep getting this --enable-external-editor
   error when I try to run Insight from inside
   Source-Navigator.

3. Help, I can't run gdb after installing Insight.

What is the cause of these problems? The unfortunate
naming of the Insight executable. For some reason
it is called "gdb". This is in despite of the fact
that it is clearly not the gdb that most people
expect to get when typing the command "gdb".

I suggest we change the name of the Insight executable
to "insight". This will make things far more intuitive
and will save us time and money in the long run.

I would also like to get Insight installed on the
default Red Hat release, but that is not currently
possible because /usr/bin/gdb is already taken.

Why is it like this? Well, as far as I can tell
the only reason is "because it has always been
that way". Well, I am sick of it! We don't
have a good reason to keep it the way it is.
In fact, there are many good reasons to change
it. So lets change it.

Comments?

Mo DeJong
Red Hat Inc