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
next prev parent 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).