Re: Current Status of Insight

Re: Current Status of Insight

[Roland Schwingel]

Hi...

 > > Or should I use DDD (which i dont really like, because i think Motif
 > > must have been designed by people that had no eyes, and was then hit
 > > with the ugly stick 3 times on birth. [Personal opinion, Motif guys if
 > > you like how it looks, more power to you])
 >
 > DDD, Eclipse CDT, xgdb (and friends) are all still options. I admit,
 > though, I still use Insight from CVS head. IMO, it will be quite some
 > time before something can match the simplecity of the UI and the speed
 > of insight.
I also use Insight from CVS head. It works well, and at present
it is for me the *one and only* solution to debug gcc compiled code
on windows! I also tried DDD on cygwin but it is not that reliable.

 > The real question is: Is it worth it? Does anyone really care anymore?
YES YES YES!!!! I am building insight from CVS frequently to run
on windows. Beside of the stack dump problem in gdb 6.x itself it works
really great!!! I use Insight on cygwin to debug mingw code all day!
 
 > At one time I considered branching, dumping all the Tcl code (assigned
 > to Red Hat) and rewriting in some form of gtk (all new code assigned to
 > FSF). I don't believe there is enough interest to justify this work,
 > though.
Well a replacement GUI would be nice, but should IMHO run also on
windows/cygwin.

Roland

Re: Current Status of Insight

[Roland Schwingel]

Hi...

Christopher Faylor wrote on 16.05.2005 18:08:44:

 > The project is only "dead" because no one is actively caring for it.
 > Making it part of gdb does not mean that someone will magically appear
 > to keep it alive.  You still need people to do that.
 >
 > We CAN fix this.  All that we need are volunteers to keep insight
 > healthy.  While it would be nice to have insight officially part of gdb,
 > it has managed to survive fairly well for a long time in its present
 > state.

As many others I am interested in keeping Insight alive and prospering.
Unfortunately my knowledge of tcl/tk is only of experimental nature, so
I might be not of much help there but (with limited time - I also need
to talk to my employer first) I could maybe do something here and there.

Roland

Re: Current Status of Insight

[Steven Johnson]

Roland Schwingel wrote:

> Hi...
>
> Christopher Faylor wrote on 16.05.2005 18:08:44:
>
> > The project is only "dead" because no one is actively caring for it.
> > Making it part of gdb does not mean that someone will magically appear
> > to keep it alive.  You still need people to do that.
> >
> > We CAN fix this.  All that we need are volunteers to keep insight
> > healthy.  While it would be nice to have insight officially part of 
> gdb,
> > it has managed to survive fairly well for a long time in its present
> > state.
>
> As many others I am interested in keeping Insight alive and prospering.
> Unfortunately my knowledge of tcl/tk is only of experimental nature, so
> I might be not of much help there but (with limited time - I also need
> to talk to my employer first) I could maybe do something here and there.

Many of us fall into that basket (tcl/tk being an unknown quantity), 
Myself included.  Although i find that by looking at what is there 
already, and using a good reference, the arcane nature of its syntax 
becomes understandable.  I tend to say "what do i need to do" and "what 
can i find that looks like it does this for some other purpose, that i 
can adapt".  I tend to achieve most of what i want with this method.

Steven

Re: Current Status of Insight

[Paul Schlie]

> Do we have any other new volunteers that are putting up their hands?

- would be please to assist verifying Insight's operability hosted on
  OSX for embedded targets such as AVR, which should help cover at least
  one of the extreme end-points; being a somewhat atypical embedded target
  development host, and the very low end of the processor target spectrum
  typically both OS&Shared-Library-less.

  (and presently assume that gdbtk will/should continue to be hosted within
   GDB's CVS directory structure to maintain as close a correspondence and
   link between it's the two corresponding efforts, creating a virtually
   unified effort?)

Re: Current Status of Insight

[Paul Schlie]

>> But what Java does not have - is a command line it is
>> compiled langauge Tcl/Tk - it is some what enherent.
>
> Well, something similar could be implemented in Java with BeanShell
> (http://www.beanshell.org/). jEdit uses this.

It seems a lot simpler to simply encourage Insight/GDB as it present stands,
to be officially (or even semi-officially) considered as part of the GDB
release, and maintained as interest allows along side if it; and remain
complemented with the separately maintained TK/TCL library etc. as may be
necessary in parallel; similar to the way it is now, but without the sigma
of "it's dead" lying over it's head.

(Although I'm personally not fan of TK/TCL, I seriously doubt any attempted
re-architecture would end up being more productive than disruptive; so an
in-place successive refinement seems simplest and most logical.)

Re: Current Status of Insight

[Steven Johnson]

Paul Schlie wrote:

>>>But what Java does not have - is a command line it is
>>>compiled langauge Tcl/Tk - it is some what enherent.
>>>      
>>>
>>Well, something similar could be implemented in Java with BeanShell
>>(http://www.beanshell.org/). jEdit uses this.
>>    
>>
>
>  
>
Wouldnt a front end to GDB written in Java, and using MI be Eclipse 
CDT?  Surely it would be better to contribute to that project, if thats 
what people wanted, rather than do it again?  The Eclipse CDT GDB Front 
end certainly seems to need a lot of work, especially where access to 
the GDB command line, and embedded development are concerned (I cant 
find how to do a "Load" from the interface, for example).  [This is not 
a criticism of Eclipse/CDT or the work they have already done, which is 
a lot, just an observation.]

>It seems a lot simpler to simply encourage Insight/GDB as it present stands,
>to be officially (or even semi-officially) considered as part of the GDB
>release, and maintained as interest allows along side if it; and remain
>complemented with the separately maintained TK/TCL library etc. as may be
>necessary in parallel; similar to the way it is now, but without the sigma
>of "it's dead" lying over it's head.
>
>  
>
I would agree with that.

>(Although I'm personally not fan of TK/TCL, I seriously doubt any attempted
>re-architecture would end up being more productive than disruptive; so an
>in-place successive refinement seems simplest and most logical.)
>
>  
>
I would agree with that also.

I also would have thought, from the FSF view, "JAVA" would be more evil 
[def: less compaitble with the ideals of the FSF] than "tcl" because 
"JAVA" isnt really free.  Im sure most people have seen the message on 
the FSF sites about Java.

It seems to me that the less we need to do, the more likely it is its 
that it is going to get done.

On the point about branching, if its not necessary, then im not pushing 
it.  The less we need to do the better.

It does appear however that there are a lot of people that "care about 
Insight".

So the first challenge is to create a Snapshot of the current 
development, so people can easily download it, and the stigma of "its 
dead" can start to go away.

The second will be to get the "People that care about Insight" to 
actively contribute, so that it can be an even better tool.

Re-synching with the GDB source tree as at 6.3 wouldnt be good,  GDB 6.3 
(as released) has at least one nasty bug for embedded systems, 
preventing it downloading properly (fixed in CVS).  So it probably isnt 
appropriate to rewind the GDB portion to GDB 6.3 stage.  Which leaves us 
with CVS_HEAD.

What about we made a snapshot of CVS_HEAD, with the current GDB Version 
Number GDB6.3.50.whatever.

Put a link to it on the web site to the snapshot, say something about it 
being a beta release for the next "Stable" which will be released 
shortly after the next GDB is released.  That it is considered better to 
use this Beta than the previous stable release Insight 5.3, due to the 
numerous changes that have been made with GDB and Insight in the mean 
time, and request people to both:
(a) test it in their environments
(b) submit improvements or changes.
(c) put their hand up to help with continued maintenance, or it will die 
off. So if you use it, get involved, or get used to a different tool.

Every so often, (Every couple of months, or after a mojor change/bug 
fix) we make another "Beta" snapshot, when people feel its a good time, 
and stable enough.

Make a TODO, expanding on what Fernando wrote, covering what people 
think the deficiencies are, including the list of code that needs to be 
replaced to have all the source FSF assigned. (If it isnt going to be 
assigned by Redhat).

Also, just as an observation, it appears a lot of the people who are 
currently using Insight are using it in the embedded space.  I would be 
interested to know how many are using CVS_HEAD for embedded, or are you 
using Insight 5.3 or some other version?  Im having real difficulty with 
GDB 6.3 (and the things it does to a target) in the embedded space, and 
im wondering if its just me, or what?

If we can generate enough interest to get it being re-released in synch 
with GDB, then we could start worrying about wholesale changes.

There shouldnt be a lot of work to this first stage, so im putting up my 
hand to do it, but im going to need help getting there (in the form of 
guidance, etc).

Also, im in no way trying to imply the great work of Keith Seitz and 
others maintaining Insight to this stage is nothing short of fantastic, 
and I applaud their hard work and dedication.  Without it, Insight would 
be a footnote in history, and not just hiding in the shadows.  I also 
dont profess to know very much about the deeper workings of Insight.  
There is no way I could currently fill the shoes of Keith or the other 
major maintainers for the amount of actual coding and testing they do.  
All this is really about (from my perspective) is preparing releases, so 
the project at least looks as active, as it in reality is.

Comments?

Steven Johnson

Re: Current Status of Insight

[Fernando Nasser]

Steven Johnson wrote:
> Paul Schlie wrote:
> 
>>>> But what Java does not have - is a command line it is
>>>> compiled langauge Tcl/Tk - it is some what enherent.
>>>>     
>>>
>>> Well, something similar could be implemented in Java with BeanShell
>>> (http://www.beanshell.org/). jEdit uses this.
>>>   
>>
>>
>>  
>>
> Wouldnt a front end to GDB written in Java, and using MI be Eclipse 
> CDT?  Surely it would be better to contribute to that project, if thats 
> what people wanted, rather than do it again?  The Eclipse CDT GDB Front 
> end certainly seems to need a lot of work, especially where access to 
> the GDB command line, and embedded development are concerned (I cant 
> find how to do a "Load" from the interface, for example).  [This is not 
> a criticism of Eclipse/CDT or the work they have already done, which is 
> a lot, just an observation.]
> 

Unfortunately that code is tightly coupled with Eclipse.  Ans many 
people don't want to use Eclipse, just a debugger GUI.



> 
> I also would have thought, from the FSF view, "JAVA" would be more evil 
> [def: less compaitble with the ideals of the FSF] than "tcl" because 
> "JAVA" isnt really free.  Im sure most people have seen the message on 
> the FSF sites about Java.
> 

That is moot.  The MI interface is standard and decouples whatever GUI 
it is from GDB.

One can write it under whichever license, whichever language, anything.

There are many GUIs already written with MI that fall in all possible 
categories you can imagine.

MI is not an API, it is a line protocol where messages are exchanged in 
an ASCII format.  Think of it as a SOAP poor cousin.

Re: Current Status of Insight

[Christopher Faylor]

On Sat, May 14, 2005 at 06:13:42PM -0400, Paul Schlie wrote:
>>> But what Java does not have - is a command line it is
>>> compiled langauge Tcl/Tk - it is some what enherent.
>>
>> Well, something similar could be implemented in Java with BeanShell
>> (http://www.beanshell.org/). jEdit uses this.
>
>It seems a lot simpler to simply encourage Insight/GDB as it present stands,
>to be officially (or even semi-officially) considered as part of the GDB
>release, and maintained as interest allows along side if it; and remain
>complemented with the separately maintained TK/TCL library etc. as may be
>necessary in parallel; similar to the way it is now, but without the sigma
>of "it's dead" lying over it's head.

The project is only "dead" because no one is actively caring for it.
Making it part of gdb does not mean that someone will magically appear
to keep it alive.  You still need people to do that.

We CAN fix this.  All that we need are volunteers to keep insight
healthy.  While it would be nice to have insight officially part of gdb,
it has managed to survive fairly well for a long time in its present
state.

This is FREE SOFTWARE we're talking about.  There is no reason for anything
to die when the source code is available as long as people are actively
interested in maintaining it.

cgf

Re: Current Status of Insight

[Paul Schlie]

> From: Christopher Faylor <me@cgf.cx>
>> On Sat, May 14, 2005 at 06:13:42PM -0400, Paul Schlie wrote:
>>>> But what Java does not have - is a command line it is
>>>> compiled langauge Tcl/Tk - it is some what enherent.
>>> 
>>> Well, something similar could be implemented in Java with BeanShell
>>> (http://www.beanshell.org/). jEdit uses this.
>> 
>> It seems a lot simpler to simply encourage Insight/GDB as it present stands,
>> to be officially (or even semi-officially) considered as part of the GDB
>> release, and maintained as interest allows along side if it; and remain
>> complemented with the separately maintained TK/TCL library etc. as may be
>> necessary in parallel; similar to the way it is now, but without the sigma
>> of "it's dead" lying over it's head.
> 
> The project is only "dead" because no one is actively caring for it.
> Making it part of gdb does not mean that someone will magically appear
> to keep it alive.  You still need people to do that.
> 
> We CAN fix this.  All that we need are volunteers to keep insight
> healthy.  While it would be nice to have insight officially part of gdb,
> it has managed to survive fairly well for a long time in its present
> state.
> 
> This is FREE SOFTWARE we're talking about.  There is no reason for anything
> to die when the source code is available as long as people are actively
> interested in maintaining it.

Thanks for the clarification, I was mistakenly under the impression that
it was potentially more politically complicated than that for some reason
(possibly as it seemed somewhat unsympathetically needlessly divorced from
GDB's development I guess, but good to know otherwise; and will help as I
can, although likely very limitedly, as I'm very unfamiliar with Tk/Tcl,
which seems fairly critical.)

Re: Current Status of Insight

[E. Weddington]

[Apologies for breaking any threading. Thunderbird cannot yet respond to 
individual mails in a digest! Please CC me in any reply.]

> It seems that there is at least 6 people that care:
>
> (in no particular order, and sorry if i list you and you dont really 
> care)
>
> 1. Keith Seitz
> 2. Duane Ellis
> 3. Roland Schwingel
> 4. Paul Schlie
> 5. Christopher Faylor
> 6. Steven Johnson (me)
> And Maybe (although it is less than clear from their posts):
> 7. Nickolay Kolchin
> 8. Jon Beniston
>
> Anybody else care to add their name to this list of people that care 
> about, or at the very least use a version of insight and would like to 
> see it continue in some form. 

Add my name.

I build Insight/GDB and include it in the WinAVR package:
<http://sourceforge.net/projects/winavr>
Which is a suite of open source cross development tools targetting the 
AVR and hosted on Windows. Note that one of the previous releases of 
WinAVR has had over 42,000 downloads.

WinAVR is designed for Windows users, and there are a lot of them where 
WinAVR is their first exposure to the GNU toolchain. A lot of Windows 
users prefer to have GUI based tools. Insight is absolutely critical in 
this area as it may be a users first exposure to using GDB. If they get 
comfortable with using the Insight interface, then that can lead them to 
using the power of the CLI interface of raw GDB.

Unfortunately, most of my interest in Insight is as a 
builder/redistributor, not so much as a developer. But it would be 
incredibly unfortunate if Insight were to go away. As it is, I've been 
stuck on building Insight 6.1 (with minimal patches), since there's been 
no further release tarballs. I have yet to jump into building from CVS HEAD.

My concern with forking the project is, IIUC, the fact that GDB and 
Insight closely coupled. Keith, anybody, correct me if I'm wrong, but 
the Insight executable contains all of GDB. It's not like Insight is a 
separate GUI program that calls a separate GDB program. Unfortunately, 
one of down sides to having this close coupling is the fact that Insight 
has not in the past been able to be built as a native Win32 executable 
without Cygwin. Yes, I saw the recent thread on the gdb list about 
building gdb for Windows without Cygwin; I'd rather not go over that 
again. I just want to throw out that there could be advantages about 
having the GUI decoupled from GDB, especially if forked.

Eric Weddington

Re: Current Status of Insight

[Christopher Faylor]

On Fri, May 13, 2005 at 09:44:17AM -0600, E. Weddington wrote:
>I build Insight/GDB and include it in the WinAVR package:
><http://sourceforge.net/projects/winavr> Which is a suite of open
>source cross development tools targetting the AVR and hosted on
>Windows.  Note that one of the previous releases of WinAVR has had over
>42,000 downloads.
>
>WinAVR is designed for Windows users, and there are a lot of them where
>WinAVR is their first exposure to the GNU toolchain.  A lot of Windows
>users prefer to have GUI based tools.  Insight is absolutely critical
>in this area as it may be a users first exposure to using GDB.  If they
>get comfortable with using the Insight interface, then that can lead
>them to using the power of the CLI interface of raw GDB.
>
>Unfortunately, most of my interest in Insight is as a
>builder/redistributor, not so much as a developer.  But it would be
>incredibly unfortunate if Insight were to go away.  As it is, I've been
>stuck on building Insight 6.1 (with minimal patches), since there's
>been no further release tarballs.  I have yet to jump into building
>from CVS HEAD.
>
>My concern with forking the project is, IIUC, the fact that GDB and
>Insight closely coupled.  Keith, anybody, correct me if I'm wrong, but
>the Insight executable contains all of GDB.  It's not like Insight is a
>separate GUI program that calls a separate GDB program.  Unfortunately,
>one of down sides to having this close coupling is the fact that
>Insight has not in the past been able to be built as a native Win32
>executable without Cygwin.  Yes, I saw the recent thread on the gdb
>list about building gdb for Windows without Cygwin; I'd rather not go
>over that again.  I just want to throw out that there could be
>advantages about having the GUI decoupled from GDB, especially if
>forked.

Since gdb itself couldn't be built as a native executable on Windows
until recently, I don't see why the inability to do this with insight is
important.  Getting insight working on windows without cygwin shouldn't
be that hard now that gdb works.  However, it will require someone to
actually do the work.

Maybe another question that should be considered is "How much would you
pay (in time or money) to keep insight alive?" If we're talking about
moving insight to the FSF, that doesn't mean that things will get
better.  The problem with insight is not that it doesn't belong to the
FSF.  The problem is that no one is actively responsible for it.  Keith
should be commended for keeping the project alive as much as he has but
we really need someone(s) who are willing to put some work into doing
things like generating snapshots and keeping the web site alive.

This is now the second time I've made this observation but people still
seem to just be responding to the "who's interested" aspect of this
discussion.  To me that's like asking how many people at a ball park are
there because they're interested in watching a ball game.  Of course
everyone here is interested in insight.  The question is what are you
going to devote to keeping insight alive and healthy?

Btw, I notice an executable in the download area of winavr but I don't
see any source code downloads.  The GPL requires that you provide the
source code for any executables that you provide.  Pointing to another
web site is not enough, you have to provide the sources.  Maybe the
source code is actually part of the .exe, though, if that is the case
then nevermind.

cgf

Re: Current Status of Insight

[Bernhard Walle]

Hello,

* Christopher Faylor [13.05.2005 19:15]:
> 
> This is now the second time I've made this observation but people still
> seem to just be responding to the "who's interested" aspect of this
> discussion.  To me that's like asking how many people at a ball park are
> there because they're interested in watching a ball game.  Of course
> everyone here is interested in insight.  The question is what are you
> going to devote to keeping insight alive and healthy?

Maybe you or someone else which is able to do that can put an
announcement on the Insight website that developers are needed, what to
do and how to get in contact.

I think this mailing list has a small audience. But: Insight is used in
the embedded segment, and there's no real (GUI) alternative on Windows.
DDD is good but needs X11 and GVD doesn't exist any more.


> Btw, I notice an executable in the download area of winavr but I don't
> see any source code downloads.  The GPL requires that you provide the
> source code for any executables that you provide.  Pointing to another
> web site is not enough, you have to provide the sources.  Maybe the
> source code is actually part of the .exe, though, if that is the case
> then nevermind.

Can you contact WinAVR people? I'm sure they can solve the problem!


Regards,
 Bernhard

-- 

Re: Current Status of Insight

[Christopher Faylor]

On Fri, May 13, 2005 at 07:33:41PM +0200, Bernhard Walle wrote:
>* Christopher Faylor [13.05.2005 19:15]:
>>This is now the second time I've made this observation but people still
>>seem to just be responding to the "who's interested" aspect of this
>>discussion.  To me that's like asking how many people at a ball park
>>are there because they're interested in watching a ball game.  Of
>>course everyone here is interested in insight.  The question is what
>>are you going to devote to keeping insight alive and healthy?
>
>Maybe you or someone else which is able to do that can put an
>announcement on the Insight website that developers are needed, what to
>do and how to get in contact.

That's Keith's call.  It seems like we should be able to find one or two
people who are willing to volunteer out of 160 subscribers, though.

>I think this mailing list has a small audience. But: Insight is used in
>the embedded segment, and there's no real (GUI) alternative on Windows.
>DDD is good but needs X11 and GVD doesn't exist any more.
>
>
>> Btw, I notice an executable in the download area of winavr but I don't
>> see any source code downloads.  The GPL requires that you provide the
>> source code for any executables that you provide.  Pointing to another
>> web site is not enough, you have to provide the sources.  Maybe the
>> source code is actually part of the .exe, though, if that is the case
>> then nevermind.
>
>Can you contact WinAVR people? I'm sure they can solve the problem!

The message that I responded to said this:

"I build Insight/GDB and include it in the WinAVR package:
<http://sourceforge.net/projects/winavr> Which is a suite of open source
cross development tools targetting the AVR and hosted on Windows.  Note
that one of the previous releases of WinAVR has had over 42,000
downloads."

That would imply that I was already speaking to the WinAVR people.

cgf

Re: Current Status of Insight

[Bernhard Walle]

* Christopher Faylor [13.05.2005 19:45]:
> The message that I responded to said this:
> 
> "I build Insight/GDB and include it in the WinAVR package:
> <http://sourceforge.net/projects/winavr> Which is a suite of open source
> cross development tools targetting the AVR and hosted on Windows.  Note
> that one of the previous releases of WinAVR has had over 42,000
> downloads."
> 
> That would imply that I was already speaking to the WinAVR people.

Ok, your're right.


Regards,
 Bernhard

-- 

Re: Current Status of Insight

[Fernando Nasser]

I will try to bring up the FSF thing again.
Is anyone taking resumes :-)

Another thing: anyone interested in rewritting the GUI in Java?
I mean basically the Tk part that we can convert very easily with NetBeans.

Most of the C-code would be replaced by MI calls.

Now with Java ME we can perhaps still keep some of the Tcl benefits 
(although I still think there is no real replacement for Tcl).

Regards to all,
Fernando

Re: Current Status of Insight

[Duane Ellis]

>> Another thing: anyone interested in rewritting the GUI in
>> Java?

>> Is anyone taking resumes :-)

Java sounds interesting... - another feature I can put on my
resume :-)

>> (although I still think there is no real replacement for
>> Tcl).

That's the problem. 

Perhaps explaining why Insight is the killer app for me
would be helpful to others.

--------------------------------------------------

Insight is really 

   gdb     - a very configurable debugger
   Tk      - the gui front end
   Tcl	   - the script that binds the two

For us - the sum of the parts are a greater benifit.

From a software department management view point I have one
debugger that most people can use both on the host
environment, the target environment, and in our case, a
simulation environment.

ie: At the end of the day - the basic commands in GDB
work in all 3 environments.

--------------------------------------------------
SIMULATION

If I factor in simulation - I get an even better
bang for my buck.

I don't need cycle accurate 100% perfect simulation with all
kinds of feed back.... Thats my world. Other worlds are very
different.

The real feature that the GDB Tcl/Tk combo shines in is
simulation.  I've done a number of smoke & mirrors front
ends for product development. I've also done 95% hardware
accurate simulations

The truth of it is - GDB's macro language sucks, it is very
limited then too - it is very task specific.

--------------------------------------------------
MODEL SIM

Perhaps if people had a chance to see/use the VHDL simulator
from Model Technologies which uses Tcl/Tk as it's front end
you'd see what I mean.

One of the modelsim examples/tutorial is a traffic light
controller. In their case - they are hooking up a (chip)
hardware simulation to fancy little lights and buttons.

There is great benifit to this - expecially in the embedded
software environment. However - the benifit is really only
found if and only if the customer is willing or can really
make a few scarafices. You can't always do that.

Historically - it is hard to convince somebody they should
do this. It is like the classic argument - write your design
document, then write your code. People don't always see the
benifit until it is too late.

It also has to do with the size of your customer base and
how common are things they are working on... for some items
it is not worth it.

--------------------------------------------------
IN MY CASE

In our case - it works really nicely. Think: PALM simulator
which - used GDB but has a completely different GUI front
end on it.

I did this:

 Create a tk canvas with a picture of the device.

 Create tk ovals or rects on the canvas
        Right over the buttons on the device

 Create a 'tksim' command implimented in C.
 
    Write/bind tcl scripts to those buttons
    that execute the tksim command, ie:
	 tksim button press $row $col 
	 tksim button release $row $col

 Create a tk Photo on the canvas
      This becomes the LCD simulation

      in C - get access to that photo, follow the example in
      the Tcl/Tk books & docs.. that is all I did. When the
      simulation writes to memory calculate what pixel that
      translates to convert the value to RGB and update the
      photo.

 Create/bind mouse events on the LCD photo

      ie: mouse button 1 press & drag becomes nothing more
      then tksim mouse down $oldx $oldy $newx $newy
 
      Now you have a touch screen simulation.

To use a different platform or device - it's a different
tcl/tk skin, nothing more....

----------------------------------------
SIMPLE HARDWARE SIMULATION is sometimes enough..

To do simple hardware simulation it requires a little change
in the memory read/write simulation functions. For example -
GDB's ARMulator has two core functions: PutWord() and
GetWord() all memory reads & writes go through these
functions.  You change them like this:


>>    ARMword
>>    GetWord( ..., ARMword address, ARMword data, ... ) 
>>    {
>>       switch( address ){
>>       case SIM_KEYBOARD_STATUS_REG_ADDRESS:
>>	    return simulated_keyboard_fifo_status();
>>	    break;
>>       case SIM_KEYBOARD_DATA_REG_ADDRESS:
>>	    return simulated_keyboard_fifo_getkey();
>>	    break;
>>	.....
>>       }
>>       ... normal arm code goes here ...
>>    }    

----------------------------------------
Using a HAL layer.

In some embeded systems its hard/impossible to simulate.
For example - realtime mechanical feedback - ie: Turn on
motor, read position feedback, track acceleration... - it
depends on what you are doing. It is not always the same as
the hardware - you are not bit banging SPI stuff or little
serial eproms, or programing a flash memory.

But - you can do quite a bit... You can simulate slow ADC
voltage inputs with a tcl/tk slider, or an DAC output with a
progress bar.

We have a fairly good hardware abstraction layer. We either
link with the simulation library, or the hardware.
Somethings can only be done on the hardware.

----------------------------------------
Java Vrs Tcl - I need a command line.

For me - the above is the true benifit of Insight.

I believe Java can do the same thing.

But what Java does not have - is a command line it is
compiled langauge Tcl/Tk - it is some what enherent.

----------------------------------------

PREVIOUSLY - Turn GDB inside out.

When this came up previously, somebody made this observation
and suggestion: (I forget who)

Today - tcl/tk is bolted onto GDB. In effect, GDB is the first
class citizen, Tcl/Tk is 2nd class.

The suggestion was to turn Insight inside out - and make the
GDB commands tcl commands, and tcl objects.

The macro ability that Tcl would give GDB is huge.

The trick is that the GUI (TK) portion becomes optional.

If you've ever done a lot with ModelSim you'll see what I
mean. My hunch is - doing exactly that - turing Insight/GDB
inside out is probably the better solution.

That's my 3.5 cents.

-Duane.

Re: Current Status of Insight

[Bernhard Walle]

Hello,

* Duane Ellis [14.05.2005 16:54]:
> But what Java does not have - is a command line it is
> compiled langauge Tcl/Tk - it is some what enherent.

Well, something similar could be implemented in Java with BeanShell
(http://www.beanshell.org/). jEdit uses this.


Regards,
 Bernhard

-- 

Re: Current Status of Insight

[Fernando Nasser]

Duane Ellis wrote:
> 
> Perhaps explaining why Insight is the killer app for me
> would be helpful to others.
> 
> --------------------------------------------------
> 
> Insight is really 
> 
>    gdb     - a very configurable debugger
>    Tk      - the gui front end
>    Tcl	   - the script that binds the two
> 
> For us - the sum of the parts are a greater benifit.
> 

So far so good.


>From a software department management view point I have one
> debugger that most people can use both on the host
> environment, the target environment, and in our case, a
> simulation environment.
> 

Tcl/Tk and Java share this advantages.


 From now on, you are mentioning the advantages of GDB.  It would be the 
same GDB, so whatever GUI we use the god olde GDB will there to provide 
all this.


I think the greatest advantage of Insight is that it is a simple and 
very intuitive User Interface that seems to be unchallenged after all 
these years.

Perhaps it is because it very closely follow the GDB "User Model" 
without trying to add fancy abstractions, nicely named artifacts or 
anything.  It is just a graphical GDB, but still very GDBish.
If you know how to use the GDB command line, you know how to use Insight.


Regards,
Fernando




> ie: At the end of the day - the basic commands in GDB
> work in all 3 environments.
> 
> --------------------------------------------------
> SIMULATION
> 
> If I factor in simulation - I get an even better
> bang for my buck.
> 
> I don't need cycle accurate 100% perfect simulation with all
> kinds of feed back.... Thats my world. Other worlds are very
> different.
> 
> The real feature that the GDB Tcl/Tk combo shines in is
> simulation.  I've done a number of smoke & mirrors front
> ends for product development. I've also done 95% hardware
> accurate simulations
> 
> The truth of it is - GDB's macro language sucks, it is very
> limited then too - it is very task specific.
> 
> --------------------------------------------------
> MODEL SIM
> 
> Perhaps if people had a chance to see/use the VHDL simulator
> from Model Technologies which uses Tcl/Tk as it's front end
> you'd see what I mean.
> 
> One of the modelsim examples/tutorial is a traffic light
> controller. In their case - they are hooking up a (chip)
> hardware simulation to fancy little lights and buttons.
> 
> There is great benifit to this - expecially in the embedded
> software environment. However - the benifit is really only
> found if and only if the customer is willing or can really
> make a few scarafices. You can't always do that.
> 
> Historically - it is hard to convince somebody they should
> do this. It is like the classic argument - write your design
> document, then write your code. People don't always see the
> benifit until it is too late.
> 
> It also has to do with the size of your customer base and
> how common are things they are working on... for some items
> it is not worth it.
> 
> --------------------------------------------------
> IN MY CASE
> 
> In our case - it works really nicely. Think: PALM simulator
> which - used GDB but has a completely different GUI front
> end on it.
> 
> I did this:
> 
>  Create a tk canvas with a picture of the device.
> 
>  Create tk ovals or rects on the canvas
>         Right over the buttons on the device
> 
>  Create a 'tksim' command implimented in C.
>  
>     Write/bind tcl scripts to those buttons
>     that execute the tksim command, ie:
> 	 tksim button press $row $col 
> 	 tksim button release $row $col
> 
>  Create a tk Photo on the canvas
>       This becomes the LCD simulation
> 
>       in C - get access to that photo, follow the example in
>       the Tcl/Tk books & docs.. that is all I did. When the
>       simulation writes to memory calculate what pixel that
>       translates to convert the value to RGB and update the
>       photo.
> 
>  Create/bind mouse events on the LCD photo
> 
>       ie: mouse button 1 press & drag becomes nothing more
>       then tksim mouse down $oldx $oldy $newx $newy
>  
>       Now you have a touch screen simulation.
> 
> To use a different platform or device - it's a different
> tcl/tk skin, nothing more....
> 
> ----------------------------------------
> SIMPLE HARDWARE SIMULATION is sometimes enough..
> 
> To do simple hardware simulation it requires a little change
> in the memory read/write simulation functions. For example -
> GDB's ARMulator has two core functions: PutWord() and
> GetWord() all memory reads & writes go through these
> functions.  You change them like this:
> 
> 
> 
>>>   ARMword
>>>   GetWord( ..., ARMword address, ARMword data, ... ) 
>>>   {
>>>      switch( address ){
>>>      case SIM_KEYBOARD_STATUS_REG_ADDRESS:
>>>	    return simulated_keyboard_fifo_status();
>>>	    break;
>>>      case SIM_KEYBOARD_DATA_REG_ADDRESS:
>>>	    return simulated_keyboard_fifo_getkey();
>>>	    break;
>>>	.....
>>>      }
>>>      ... normal arm code goes here ...
>>>   }    
> 
> 
> ----------------------------------------
> Using a HAL layer.
> 
> In some embeded systems its hard/impossible to simulate.
> For example - realtime mechanical feedback - ie: Turn on
> motor, read position feedback, track acceleration... - it
> depends on what you are doing. It is not always the same as
> the hardware - you are not bit banging SPI stuff or little
> serial eproms, or programing a flash memory.
> 
> But - you can do quite a bit... You can simulate slow ADC
> voltage inputs with a tcl/tk slider, or an DAC output with a
> progress bar.
> 
> We have a fairly good hardware abstraction layer. We either
> link with the simulation library, or the hardware.
> Somethings can only be done on the hardware.
> 
> ----------------------------------------
> Java Vrs Tcl - I need a command line.
> 
> For me - the above is the true benifit of Insight.
> 
> I believe Java can do the same thing.
> 
> But what Java does not have - is a command line it is
> compiled langauge Tcl/Tk - it is some what enherent.
> 
> ----------------------------------------
> 
> PREVIOUSLY - Turn GDB inside out.
> 
> When this came up previously, somebody made this observation
> and suggestion: (I forget who)
> 
> Today - tcl/tk is bolted onto GDB. In effect, GDB is the first
> class citizen, Tcl/Tk is 2nd class.
> 
> The suggestion was to turn Insight inside out - and make the
> GDB commands tcl commands, and tcl objects.
> 
> The macro ability that Tcl would give GDB is huge.
> 
> The trick is that the GUI (TK) portion becomes optional.
> 
> If you've ever done a lot with ModelSim you'll see what I
> mean. My hunch is - doing exactly that - turing Insight/GDB
> inside out is probably the better solution.
> 
> That's my 3.5 cents.
> 
> -Duane.
> 
> 
> 

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Current Status of Insight

[Paul Schlie]

> Keith Seitz writes:
> ...
> I still use Insight from CVS head. IMO, it will be quite some
> time before something can match the simplecity of the UI and the speed
> of insight.

- Fully agree, and convenient for cross-compiled target debugging.

> ...
> Andrew Cagney (the GDB maintainer) decided that enough was enough. If
> Insight isn't officially assigned to the FSF, he was under no obligation
> to spin the release for it (even though it cost him nothing to do it).
> So no more snapshots, releases, tagging the sources, etc.
> ...

- It may be worth proposing that Insight build/distribution with GDB be
  re-enabled, as it's still a nice complement to the otherwise text only
  interface (and already integrated, so it would be a shame to ignore).

Current Status of Insight

[Steven Johnson]

Hi, ive been away from Insight for quite some time.

Correct me (and maybe forgive me) if i make any errors, the following is 
from my memory, and i do not wish to upset anyone.

I seem to recall there was a falling out between FSF and Redhat over 
Insight. (I do not know exactly what about, and if i did i wouldnt have 
a position either way) and at about the same time (V5.3) vintage (around 
2 years ago) Insight stopped being
(a) actively developed and
(b) released in synch with the GDB mainline.

There was a time when GDB X.YY would be released and insight X.YY seemed 
to be there right along with it, that was a long time ago now.

My email is basically a query on the status, is Insight alive and well?

Is the FSF/Redhat thing over Insight resolved?

Is there a road map for re-synching Insight with GDB releases, so people 
dont get stuck using an over 2 year old version (cause the web site says 
thats the latest stable version).  Telling people to use CVS_HEAD is 
hardly ideal.  It doesnt really inspire confidence in stability.  
Although I understand that might be the best answer anyone can currently 
give.

Or should I use DDD (which i dont really like, because i think Motif 
must have been designed by people that had no eyes, and was then hit 
with the ugly stick 3 times on birth. [Personal opinion, Motif guys if 
you like how it looks, more power to you])

Is Insight CVS_HEAD currently in-synch with GDB 6.3?  If so, could an 
Insight 6.3 be cut and released as a stable version?  If not whats the 
impediment?

Im happy to do the checking out and packaging of the source (if someone 
can tell me the appropriate CVS tag to use), and web site updating if 
thats all it requires.

Steven Johnson

RE: Current Status of Insight

[Jon Beniston]

Hi Steve,

> Is the FSF/Redhat thing over Insight resolved?

I don't think so.
 
> Is there a road map for re-synching Insight with GDB 
> releases, so people 
> dont get stuck using an over 2 year old version (cause the 
> web site says 
> thats the latest stable version). 

I think the last release of GDB with insight was 6.0.

> Or should I use DDD (which i dont really like, because i think Motif 
> must have been designed by people that had no eyes, and was then hit 
> with the ugly stick 3 times on birth. [Personal opinion, 
> Motif guys if 
> you like how it looks, more power to you])

You could always try eclipse. The CDT plugin is based around GCC/GDB. Quite
nice it is to.

Cheers,
Jon

Current Status of Insight

[Nickolay Kolchin]

Does this mean that insight is dead?

On 5/12/05, Jon Beniston <jbeniston@compxs.com> wrote:
> Hi Steve,
>
> > Is the FSF/Redhat thing over Insight resolved?
>
> I don't think so.
>
> > Is there a road map for re-synching Insight with GDB
> > releases, so people
> > dont get stuck using an over 2 year old version (cause the
> > web site says
> > thats the latest stable version).
>
> I think the last release of GDB with insight was 6.0.
>
> > Or should I use DDD (which i dont really like, because i think Motif
> > must have been designed by people that had no eyes, and was then hit
> > with the ugly stick 3 times on birth. [Personal opinion,
> > Motif guys if
> > you like how it looks, more power to you])
>
> You could always try eclipse. The CDT plugin is based around GCC/GDB. Quite
> nice it is to.
>
> Cheers,
> Jon
>
>

Re: Current Status of Insight

[Keith Seitz]

On Thu, 2005-05-12 at 21:10 -1100, Steven Johnson wrote:

> I seem to recall there was a falling out between FSF and Redhat over 
> Insight. (I do not know exactly what about, and if i did i wouldnt have 
> a position either way) and at about the same time (V5.3) vintage (around 
> 2 years ago) Insight stopped being
> (a) actively developed and
> (b) released in synch with the GDB mainline.

Actually, the "falling out" was between Cygnus Solutions (acquired by
Red Hat in January 2000) and the FSF. The FSF labeled Tcl as "evil" and
consequently refused to allow Cygnus to assign the tcl sources to the
FSF.

They've since lost that attitude, but unfortunately, Red Hat does not
consider Insight worthy of their attorney's time to review and sign the
paperwork.

> There was a time when GDB X.YY would be released and insight X.YY seemed 
> to be there right along with it, that was a long time ago now.

Andrew Cagney (the GDB maintainer) decided that enough was enough. If
Insight isn't officially assigned to the FSF, he was under no obligation
to spin the release for it (even though it cost him nothing to do it).
So no more snapshots, releases, tagging the sources, etc.

> My email is basically a query on the status, is Insight alive and well?
> Is the FSF/Redhat thing over Insight resolved?

Sadly, the answer to both is "no".

> Is there a road map for re-synching Insight with GDB releases, so people 
> dont get stuck using an over 2 year old version (cause the web site says 
> thats the latest stable version).  Telling people to use CVS_HEAD is 
> hardly ideal.  It doesnt really inspire confidence in stability.  
> Although I understand that might be the best answer anyone can currently 
> give.

A group in Red Hat re-hired me in 2001 to work on insight. About a year
later, I was transferred to another group with different
responsibilities. By then, my old group was already wanting to replace
insight, and they were relying on me to develop Insight for them (for
nothing). I did that for over a year, all the while trying to get the
sources donated to the FSF. I gave up.

If this group wanted Insight development, they would have to rely on the
community or pay for it. They still use insight and, predictably,
complain like bloody hell when it doesn't work. Yet they refuse to do
anything about it.

> Or should I use DDD (which i dont really like, because i think Motif 
> must have been designed by people that had no eyes, and was then hit 
> with the ugly stick 3 times on birth. [Personal opinion, Motif guys if 
> you like how it looks, more power to you])

DDD, Eclipse CDT, xgdb (and friends) are all still options. I admit,
though, I still use Insight from CVS head. IMO, it will be quite some
time before something can match the simplecity of the UI and the speed
of insight.

> Is Insight CVS_HEAD currently in-synch with GDB 6.3?  If so, could an 
> Insight 6.3 be cut and released as a stable version?  If not whats the 
> impediment?

It is my goal to keep CVS HEAD buildable. I don't always notice when it
is buildable, but when I do (or someone else like Martin Hunt, Ben
Elliston, and a few others does), it is fixed in a pretty timely manner.

> Im happy to do the checking out and packaging of the source (if someone 
> can tell me the appropriate CVS tag to use), and web site updating if 
> thats all it requires.

That certainly wouldn't hurt. If you really want to do this, let me know
(off-list) and I will send necessary info.

The real question is: Is it worth it? Does anyone really care anymore?

At one time I considered branching, dumping all the Tcl code (assigned
to Red Hat) and rewriting in some form of gtk (all new code assigned to
FSF). I don't believe there is enough interest to justify this work,
though.

Keith

Re: Current Status of Insight

[Steven Johnson]

Hi Keith,

Thanks for the informative reply.  I suppose the question is (and this 
is the right place to ask it):

1. What do the user's of Insight think about this? Is it worth it? Does 
anyone really care anymore?

>At one time I considered branching, dumping all the Tcl code (assigned
>to Red Hat) and rewriting in some form of gtk (all new code assigned to
>FSF). I don't believe there is enough interest to justify this work,
>though.
>  
>

2. Is there enough interest to do what you say, and attempt to create an 
insight derivitave, that is assignable to the FSF?  (Not suggesting 
Keith do it, just gauging the interest, if it is there, then there 
should be people willing to contribute to the effort (money or time or 
both).)

>DDD, Eclipse CDT, xgdb (and friends) are all still options.
>
Yes they are, ive tried to use them, and even though they have some nice 
fancy features, they just lack basic usability.  I keep finding myself 
wishing they were more like Insight.  But that could just be my simple 
brain.  And for what its worth ive never found the MI or CL Tack a front 
end over the top approach to be (a) very effective, or (b) very 
reliable.  I much prefered how Insight really just linked with GDB and 
went from there.  There is a maintained TUI in GDB, so I cant see why 
there shouldnt be a maintained GUI in GDB either.

So what your really saying (if i understand your post), is the main 
impediment to breathing new life into insight (apart from re-writing 
large chunks) is a standard FSF assignment.  Sheesh, i think that is 
really weak for RedHat's part, given everything they have made out of 
the work of the FSF and the GNU Licence.  How hard is it to just sign it 
over, they obviously dont give two tosses about it, so whats the big 
deal. (But i Digress).

I am sadened by this state of affairs, because I believe Insight was a 
really great part of GDB.

Steven Johnson

Re: Current Status of Insight

[Duane Ellis]

>> 1. What do the user's of Insight think about this?

>> >DDD, Eclipse CDT, xgdb (and friends) are all still
>> >options.

Insight is great in cross compile solutions for one reason.
It builds under CYGWIN - solves the nagging smelly wet
ms-dog problem I have to deal with. I support our internal
and external development group.

A lesser feature is that you can do great tricks with
tcl/tk.

I've been hoping the FSF/RH thing would iron it self out as
I've got some nice ARM simulation features I'd like to try
to get contributed/added.

For LINUX debugging I don't use GDB, can't stand it. I use
UPS a *GREAT* debugger, started using it on SunOS 4.1 over
ten - yes ten years ago. It's that old.

      http://ups.sourceforge.net

-Duane.

Re: Current Status of Insight

[Duane Ellis]

>> sjohnson@sakuraindustries.com

what type of development work in Port Vila vanuatu?

Re: Current Status of Insight

[Christopher Faylor]

On Fri, May 13, 2005 at 08:49:45AM -1100, Steven Johnson wrote:
>So what your really saying (if i understand your post), is the main 
>impediment to breathing new life into insight (apart from re-writing 
>large chunks) is a standard FSF assignment.  Sheesh, i think that is 
>really weak for RedHat's part, given everything they have made out of 
>the work of the FSF and the GNU Licence.  How hard is it to just sign it 
>over, they obviously dont give two tosses about it, so whats the big 
>deal. (But i Digress).

I think past and current employees of Red Hat would probably agree with
you about this sorry state of affairs.

Keith, what about a petition to Red Hat?  Think that would work?

cgf

Re: Current Status of Insight

[Keith Seitz]

On Thu, 2005-05-12 at 22:09 -0400, Christopher Faylor wrote:
> I think past and current employees of Red Hat would probably agree with
> you about this sorry state of affairs.
> 
> Keith, what about a petition to Red Hat?  Think that would work?

I have no idea. For all I know, it might get me fired! [Okay, I don't
actually think it would, but who the heck knows?] I've thought about
this and other things.

I know this looks very badly upon Red Hat, but I want to make it
absolutely clear: I don't blame them one darn bit for not wanting to
take the time (and money) to see all the paperwork done. It does not
make economic sense.

I would also like to emphasize that when it comes to programming tools
(compilers, debuggers, etc), Red Hat is not a company, IME, that is all
take an no give. I've been involved with several projects where Red Hat
took AND gave back to the community.

Once again, I think we're finally at the point where we must ask
ourselves: Does it matter to anyone?*

Keith

* A question I have been meaning to ask for almost two years, but kept
chickening out in the last second...

Re: Current Status of Insight

[Steven Johnson]

It seems that there is at least 6 people that care:

(in no particular order, and sorry if i list you and you dont really care)

1. Keith Seitz
2. Duane Ellis
3. Roland Schwingel
4. Paul Schlie
5. Christopher Faylor
6. Steven Johnson (me)
And Maybe (although it is less than clear from their posts):
7. Nickolay Kolchin
8. Jon Beniston

Anybody else care to add their name to this list of people that care 
about, or at the very least use a version of insight and would like to 
see it continue in some form.

If we cant join em (FSF GDB and RH Insight) why dont we just fork em?

We could go to Sourceforge, do a checkout of insight CVS Head, move 
development over to there, and at least then it can progress, we can cut 
releases, etc.  Official insight can stay here, and do whatever its 
going to.  If the FSF and RH ever feel like getting together on this 
they can, and we could merge back our changes.

We track official GDB (ie merge GDB CVS with our tree daily), and 
release (close to synch with it), but are really independent from it. 

To the extent anyone cares, insight would continue to be (visibly) 
maintained and survive.  If people really stopped caring it would die, 
at least we could attempt to attract new users (1 or 2 of which might 
even contribute something useful), as there would be "stable" releases, 
synched to official GDB the attraction would be greater.  It does seem 
like most of the people that care are using it for embedded programming, 
a few (maybe most) want it to work under windows. (I use it under 
Linux).  In the mean time, we would have a maintainable version.

CVS_Head of Insight, is that the same level of code as CVS_Head of GDB? 
(ie, does it incorporate CVS_Head of GDB?)

As a minimum all that needs to happen is ensure that Insight continues 
to build and function on top of current GDB.  And I think thats what 
Keith is basically saying he does with CVS_Head, keep it building and 
functional against CVS_Head of GDB, all im really proposing (as a 
minimum) is making the process a little more transparent, and cutting 
releases (maybe its more work than that? Keith?).

Anyway is this feasible, of interest, or a waste of time?

There are a lot of nify features a debugger targeted to embedded systems 
could have, and insight could have them reasonably easily.  We could 
even start re-writing the portions that are Red Hat copyright, over 
time, if we felt like it.  Any new code, could be put in new files and 
assigned to the FSF, over time (maybe years) id suspect the RH code 
would eventually disappear and it would all be assigned to the FSF.

The first thing to do, i would see is create a new project on 
sourceforge, move the code over there, and cut a first (current) 
version.  Even if it isnt quite GDB 6.3, we could call it "insight 6.3D" 
or some such (D for development release).  BTW, is "insight" a RH 
trademark, would it need to be renamed.  I always fancied "oversight" 
:)  Any new code, could be put in new files and assigned to the FSF. 
over time (maybe years) id suspect the RH code would eventually 
disappear and it would all be assigned to the FSF.

If this is something ive generated interest with (with others), I will 
even invest in some web space for the project, so it can have its own 
URL (at least for a year or two, depending on its life, and my continued 
ability to fund it).

Keith, you seem to be the primary maintainer of insight, i dont want to 
mess with your project here, so your comments are of significant 
interest to me, in this regard.  I wouldnt like to see more "code 
hostility" if forking is feasible, then we should do it in a 
constructive way, for the benefit of all users, just to get rid of some 
of the restrictions the code base currently seems to face.

Also, i realise that i seem to have jumped in here and stirred things 
up, i have been an insight user for a long time, have submitted various 
things in the past (cheers go out to Fernando Nasser if hes listening).  
Its not my intention.  But if there are a lot of people building insight 
from CVS_Head and then using it for real work, then i thnk it should be 
kept going in a visible way, otherwise people will think what i thought 
"insight is dead, boo hoo, how crappy", when instead it is really just 
bubbling along under the surface, not progressing in great leaps and 
bounds, but still breathing.

Steven Johnson

Keith Seitz wrote:

>On Thu, 2005-05-12 at 22:09 -0400, Christopher Faylor wrote:
>  
>
>>I think past and current employees of Red Hat would probably agree with
>>you about this sorry state of affairs.
>>
>>Keith, what about a petition to Red Hat?  Think that would work?
>>    
>>
>
>I have no idea. For all I know, it might get me fired! [Okay, I don't
>actually think it would, but who the heck knows?] I've thought about
>this and other things.
>
>I know this looks very badly upon Red Hat, but I want to make it
>absolutely clear: I don't blame them one darn bit for not wanting to
>take the time (and money) to see all the paperwork done. It does not
>make economic sense.
>
>I would also like to emphasize that when it comes to programming tools
>(compilers, debuggers, etc), Red Hat is not a company, IME, that is all
>take an no give. I've been involved with several projects where Red Hat
>took AND gave back to the community.
>
>Once again, I think we're finally at the point where we must ask
>ourselves: Does it matter to anyone?*
>
>Keith
>
>* A question I have been meaning to ask for almost two years, but kept
>chickening out in the last second...
>
>
>  
>

Re: Current Status of Insight

[Christopher Faylor]

On Sat, May 14, 2005 at 12:55:41AM -1100, Steven Johnson wrote:
>It seems that there is at least 6 people that care:
>
>(in no particular order, and sorry if i list you and you dont really care)
>
>1. Keith Seitz
>2. Duane Ellis
>3. Roland Schwingel
>4. Paul Schlie
>5. Christopher Faylor
>6. Steven Johnson (me)
>And Maybe (although it is less than clear from their posts):
>7. Nickolay Kolchin
>8. Jon Beniston
>
>Anybody else care to add their name to this list of people that care 
>about, or at the very least use a version of insight and would like to 
>see it continue in some form.
>
>If we cant join em (FSF GDB and RH Insight) why dont we just fork em?
>
>We could go to Sourceforge, do a checkout of insight CVS Head, move 
>development over to there, and at least then it can progress, we can cut 
>releases, etc.  Official insight can stay here, and do whatever its 
>going to.  If the FSF and RH ever feel like getting together on this 
>they can, and we could merge back our changes.

What good does a fork do?  It would just complicate matters.  Keith (and
I) have the ability to give people CVS checkin privileges so I don't see
any reason to move to sourceforge.

cgf

RE: Current Status of Insight

[Jon Beniston]

> 8. Jon Beniston

I'm interested.

> What good does a fork do?  It would just complicate matters.  
> Keith (and
> I) have the ability to give people CVS checkin privileges so 
> I don't see any reason to move to sourceforge.

For me, it doesn't matter whether insight is merged with GDB. It would be
good enough if working tar balls were made available shortly after each
major GDB release. It would nice if the web page were updated to show the
project is still alive (I don't mind volunteering for this, or doing
occasional testing of Cygwin builds).

Cheers,
Jon

Re: Current Status of Insight

[Christopher Faylor]

On Fri, May 13, 2005 at 03:18:57PM +0100, Jon Beniston wrote:
>> 8. Jon Beniston
>
>I'm interested.
>
>> What good does a fork do?  It would just complicate matters.  
>> Keith (and
>> I) have the ability to give people CVS checkin privileges so 
>> I don't see any reason to move to sourceforge.
>
>For me, it doesn't matter whether insight is merged with GDB.  It would
>be good enough if working tar balls were made available shortly after
>each major GDB release.  It would nice if the web page were updated to
>show the project is still alive (I don't mind volunteering for this, or
>doing occasional testing of Cygwin builds).

Keith can give privileges to update the web page to anyone he wants.  If
you are volunteering to do this, then you should coordinate with him.

cgf

Re: Current Status of Insight

[Hans W. Horn]

I, Hans Horn,  care too!
Pls add me to the list!
H.

Steven Johnson wrote:
> It seems that there is at least 6 people that care:
> 
> (in no particular order, and sorry if i list you and you dont really
> care) 
> 
> 1. Keith Seitz
> 2. Duane Ellis
> 3. Roland Schwingel
> 4. Paul Schlie
> 5. Christopher Faylor
> 6. Steven Johnson (me)
> And Maybe (although it is less than clear from their posts):
> 7. Nickolay Kolchin
> 8. Jon Beniston
> 
> Anybody else care to add their name to this list of people that care
> about, or at the very least use a version of insight and would like to
> see it continue in some form.
> 
> If we cant join em (FSF GDB and RH Insight) why dont we just fork em?
> 
> We could go to Sourceforge, do a checkout of insight CVS Head, move
> development over to there, and at least then it can progress, we can
> cut releases, etc.  Official insight can stay here, and do whatever
> its 
> going to.  If the FSF and RH ever feel like getting together on this
> they can, and we could merge back our changes.
> 
> We track official GDB (ie merge GDB CVS with our tree daily), and
> release (close to synch with it), but are really independent from it.
> 
> To the extent anyone cares, insight would continue to be (visibly)
> maintained and survive.  If people really stopped caring it would die,
> at least we could attempt to attract new users (1 or 2 of which might
> even contribute something useful), as there would be "stable"
> releases, synched to official GDB the attraction would be greater. 
> It does seem like most of the people that care are using it for
> embedded programming, a few (maybe most) want it to work under
> windows. (I use it under 
> Linux).  In the mean time, we would have a maintainable version.
> 
> CVS_Head of Insight, is that the same level of code as CVS_Head of
> GDB? (ie, does it incorporate CVS_Head of GDB?)
> 
> As a minimum all that needs to happen is ensure that Insight continues
> to build and function on top of current GDB.  And I think thats what
> Keith is basically saying he does with CVS_Head, keep it building and
> functional against CVS_Head of GDB, all im really proposing (as a
> minimum) is making the process a little more transparent, and cutting
> releases (maybe its more work than that? Keith?).
> 
> Anyway is this feasible, of interest, or a waste of time?
> 
> There are a lot of nify features a debugger targeted to embedded
> systems could have, and insight could have them reasonably easily. 
> We could 
> even start re-writing the portions that are Red Hat copyright, over
> time, if we felt like it.  Any new code, could be put in new files and
> assigned to the FSF, over time (maybe years) id suspect the RH code
> would eventually disappear and it would all be assigned to the FSF.
> 
> The first thing to do, i would see is create a new project on
> sourceforge, move the code over there, and cut a first (current)
> version.  Even if it isnt quite GDB 6.3, we could call it "insight
> 6.3D" or some such (D for development release).  BTW, is "insight" a
> RH trademark, would it need to be renamed.  I always fancied
> "oversight" :)  Any new code, could be put in new files and assigned
> to the FSF. 
> over time (maybe years) id suspect the RH code would eventually
> disappear and it would all be assigned to the FSF.
> 
> If this is something ive generated interest with (with others), I will
> even invest in some web space for the project, so it can have its own
> URL (at least for a year or two, depending on its life, and my
> continued ability to fund it).
> 
> Keith, you seem to be the primary maintainer of insight, i dont want
> to mess with your project here, so your comments are of significant
> interest to me, in this regard.  I wouldnt like to see more "code
> hostility" if forking is feasible, then we should do it in a
> constructive way, for the benefit of all users, just to get rid of
> some of the restrictions the code base currently seems to face.
> 
> Also, i realise that i seem to have jumped in here and stirred things
> up, i have been an insight user for a long time, have submitted
> various things in the past (cheers go out to Fernando Nasser if hes
> listening). Its not my intention.  But if there are a lot of people
> building insight from CVS_Head and then using it for real work, then
> i thnk it should be kept going in a visible way, otherwise people
> will think what i thought "insight is dead, boo hoo, how crappy",
> when instead it is really just bubbling along under the surface, not
> progressing in great leaps and bounds, but still breathing.
> 
> Steven Johnson
> 
> Keith Seitz wrote:
> 
>> On Thu, 2005-05-12 at 22:09 -0400, Christopher Faylor wrote:
>> 
>> 
>>> I think past and current employees of Red Hat would probably agree
>>> with you about this sorry state of affairs.
>>> 
>>> Keith, what about a petition to Red Hat?  Think that would work?
>>> 
>>> 
>> 
>> I have no idea. For all I know, it might get me fired! [Okay, I don't
>> actually think it would, but who the heck knows?] I've thought about
>> this and other things.
>> 
>> I know this looks very badly upon Red Hat, but I want to make it
>> absolutely clear: I don't blame them one darn bit for not wanting to
>> take the time (and money) to see all the paperwork done. It does not
>> make economic sense.
>> 
>> I would also like to emphasize that when it comes to programming
>> tools (compilers, debuggers, etc), Red Hat is not a company, IME,
>> that is all take an no give. I've been involved with several
>> projects where Red Hat took AND gave back to the community.
>> 
>> Once again, I think we're finally at the point where we must ask
>> ourselves: Does it matter to anyone?*
>> 
>> Keith
>> 
>> * A question I have been meaning to ask for almost two years, but
>> kept chickening out in the last second...

Re: Current Status of Insight

[Christopher Faylor]

On Fri, May 13, 2005 at 07:10:13AM -0700, Hans W. Horn wrote:
>I, Hans Horn,  care too!
>Pls add me to the list!
>H.

There are 160 people or so in this mailing list.  Isn't it a safe bet
that the majority of them care about insight?

It seems like the only thing missing is volunteers to actively work on
the project.

So, we shouldn't be composing a list of people who care, we should be
composing a list of volunteers.

AFAICT, we need people to:

  1) fix bugs

  2) test (on linux/unix/cygwin)

  3) produce snapshots and releases

  4) maintain and update the web page

  5) maintain and update the documentation

  6) add new features

  7) respond to queries on the mailing list

All of the above are possible within the current system.  We just need
actual people to do the actual work.

cgf

Re: Current Status of Insight

[James Lemke]

On Sat, 2005-05-14 at 07:55, Steven Johnson wrote:
> It seems that there is at least 6 people that care:
> 
> (in no particular order, and sorry if i list you and you dont really care)
> 
> 1. Keith Seitz
> 2. Duane Ellis
> 3. Roland Schwingel
> 4. Paul Schlie
> 5. Christopher Faylor
> 6. Steven Johnson (me)
> And Maybe (although it is less than clear from their posts):
> 7. Nickolay Kolchin
> 8. Jon Beniston

I care.
And we have customers using it, draw your own conclusions.

-- 
James Lemke   jim@wasabisystems.com   Orillia, Ontario
http://www.wasabisystems.com

Re: Current Status of Insight

[Nickolay Kolchin]

I care about Insight future.

In my opinion you all speak about wrong thing: we need a good
integrated GUI for GDB, which is available on all platforms, have same
same look and feel on them and support most (all) gdb features. At
present time, only Insight fills this niche.

Instead of making GDB split or doing other weird things, we can make
patches for GDB, to make libgdb reality. This will allow separate
development of Insight and GDB. Such patches should be also "easily"
accepted by GDB team.

As I understand, "libgdb" idea was talken about for years.

Any comments?

Nickolay Kolchin

Re: Current Status of Insight

[Fernando Nasser]

Nickolay Kolchin wrote:
> I care about Insight future.
> 
> In my opinion you all speak about wrong thing: we need a good
> integrated GUI for GDB, which is available on all platforms, have same
> same look and feel on them and support most (all) gdb features. At
> present time, only Insight fills this niche.
> 
> Instead of making GDB split or doing other weird things, we can make
> patches for GDB, to make libgdb reality. This will allow separate
> development of Insight and GDB. Such patches should be also "easily"
> accepted by GDB team.
> 
> As I understand, "libgdb" idea was talken about for years.
> 

We make the libgdb functionality available through the MI interface.

I designed the MI functions to resemble the (never implemented) set of 
libgdb functions.

So the current idea is just to exchange information with GDB throught 
the standardized MI.

Regards,
Fernando

Re: Current Status of Insight

[Steven Johnson]

 > Christofer Fayler Wrote:
> AFAICT, we need people to:
> 
>   1) fix bugs
> 
>   2) test (on linux/unix/cygwin)
> 
>   3) produce snapshots and releases
> 
>   4) maintain and update the web page
> 
>   5) maintain and update the documentation
> 
>   6) add new features
> 
>   7) respond to queries on the mailing list

And I add

     8) Review and Apply user submited patches


 > .....
> The project is only "dead" because no one is actively caring for it.
> Making it part of gdb does not mean that someone will magically appear
> to keep it alive.  You still need people to do that.
> 

It is apparent that there are a reasonable number of people that want to 
get involved, from the various replies.

For my part, I want to help with
     (1 - already doing it now
     (2 - linux in an X Debug envirnoment for MPC8XX and ARM
     (3 - A Major Requirement, which im happy to do
     (4 - Im also happy to update the web site, to the limit of my
        - meagre HTML and WEB Design skills.
     (5 - Should be part of the review process for new
        - patches/features. Cant or shouldnt go in without appropriate
        - documentation. Similar to what happens with core
        - gdb.
     (6 - Id like to add the ability to view memory as an
        - arbitrary bitmap, plus put watchpoints on memory
        - dumps
     (7 - As far as my capability and ego allow.
     (8 - Im happy to do it, but my experience level probably means
        - I shouldnt.

What next?

Do we have any other new volunteers that are putting up their hands?

Steven Johnson