public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Steven Johnson <sjohnson@sakuraindustries.com>
To: insight@sources.redhat.com
Subject: Re: Current Status of Insight
Date: Mon, 16 May 2005 05:35:00 -0000	[thread overview]
Message-ID: <42896711.8070400@sakuraindustries.com> (raw)
In-Reply-To: <BEABF056.A26D%schlie@comcast.net>

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

  reply	other threads:[~2005-05-16  5:35 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-14 22:13 Paul Schlie
2005-05-16  5:35 ` Steven Johnson [this message]
2005-05-16 13:18   ` Insight and Licencing of TCL/TK Code Steven Johnson
2005-05-16 13:31     ` Duane Ellis
2005-05-16 13:39       ` Jon Beniston
2005-05-16 14:15         ` Steven Johnson
2005-05-16 16:12           ` Christopher Faylor
2005-05-17 19:33   ` Current Status of Insight Fernando Nasser
2005-05-16 16:10 ` Christopher Faylor
2005-05-16 17:18   ` Paul Schlie
  -- strict thread matches above, loose matches on Subject: below --
2005-05-17  8:26 Roland Schwingel
2005-05-17 10:18 ` Steven Johnson
2005-05-16 23:45 Paul Schlie
     [not found] <1115992411.3092.ezmlm@sources.redhat.com>
2005-05-13 15:44 ` E. Weddington
2005-05-13 17:15   ` Christopher Faylor
2005-05-13 17:35     ` Bernhard Walle
2005-05-13 17:45       ` Christopher Faylor
2005-05-13 17:58         ` Bernhard Walle
2005-05-13 21:51           ` Fernando Nasser
2005-05-14 14:54             ` Duane Ellis
2005-05-14 17:25               ` Bernhard Walle
2005-05-17 19:38               ` Fernando Nasser
2005-05-13  8:14 Roland Schwingel
2005-05-13  1:15 Paul Schlie
2005-05-12 10:07 Steven Johnson
2005-05-12 10:13 ` Jon Beniston
     [not found]   ` <2636500f05051203276a294e8f@mail.gmail.com>
2005-05-12 10:29     ` Nickolay Kolchin
2005-05-12 15:17 ` Keith Seitz
2005-05-12 21:46   ` Steven Johnson
2005-05-12 22:42     ` Duane Ellis
2005-05-12 22:45     ` Duane Ellis
2005-05-13  2:09     ` Christopher Faylor
2005-05-13  2:19       ` Keith Seitz
2005-05-13 13:53         ` Steven Johnson
2005-05-13 14:05           ` Christopher Faylor
2005-05-13 14:18             ` Jon Beniston
2005-05-13 14:21               ` Christopher Faylor
2005-05-13 14:16           ` Hans W. Horn
2005-05-13 14:29             ` Christopher Faylor
2005-05-13 14:33           ` James Lemke
2005-05-14 11:14           ` Nickolay Kolchin
2005-05-17 12:51             ` Fernando Nasser
2005-05-16 22:07         ` Steven Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42896711.8070400@sakuraindustries.com \
    --to=sjohnson@sakuraindustries.com \
    --cc=insight@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).