Insight release schedule

Insight release schedule

[Sefer Tov]

Hi,

as a devoted Insight user I have been monitoring it regualrily for updates.
Observing the release of gdb 6.2 I naturally assumed that it would be 
followed by a insight 6.2 almost instantly, however, I was greatly 
disappointed to see that it was not so.

I was wondering whether insight is still under active development (it would 
be a great shame if such an excellent tool will lose further development 
focus) and whether I should expect a new version unleashed soon (any 
estimates?) - aren't gdb & insight development cycles closely tied together?

Thanks,
     Sefer.

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: Insight release schedule

[Keith Seitz]

On Wed, 2004-08-11 at 05:32, Sefer Tov wrote:
> I was wondering whether insight is still under active development (it would 
> be a great shame if such an excellent tool will lose further development 
> focus) and whether I should expect a new version unleashed soon (any 
> estimates?) - aren't gdb & insight development cycles closely tied together?

Unfortunately, Red Hat and the FSF have been unable to iron out there
differences about getting insight officially contributed, so I am only
answering email. (Ok, very occasionally will I actually do something. It
happens. I get the urge. :-)

Aside from me, there is really only one other insight developer, and
he's gotten very busy and unable to contribute as much as he would like.

There are no public contributors to this project. Even if there were, I
have no idea how to deal with the approval mess. [Contributors would
need to sign some sort of release with Red Hat instead of the FSF.]

As far as I am concerned, Red Hat, the FSF, and the community have
spoken volumes about where they'd like to see insight go.

Right now, if there is to be any more insight work, it will probably
entail abandoning the current code base in favor of a new, GNU-only
(sans-Red Hat) version. Once again, unlike all the other GUIs out there,
the goal would be for speed. Being built-in to gdb would be a
requirement.

Alas, I don't think I would get nearly as much support as I would like
to undergo such a large undertaking, and I haven't really found the time
to try it.

As for releases, I'm guessing the gdb maintainers have stopped
"releasing" tarballs of insight. [And who can blame them?] If you really
want to get the latest, hobbling-along-with-no-new-features release, I
suggest you check out the release branch from sources.redhat.com's CVS
repository. You can find the release branch tags on the gdb website in
the download area.

My apologies for the wreckage.
Keith

Re: Insight release schedule

[Fernando Nasser]

Sefer Tov wrote:
> Hi,
> 
> as a devoted Insight user I have been monitoring it regualrily for updates.
> Observing the release of gdb 6.2 I naturally assumed that it would be 
> followed by a insight 6.2 almost instantly, however, I was greatly 
> disappointed to see that it was not so.
> 
> I was wondering whether insight is still under active development (it 
> would be a great shame if such an excellent tool will lose further 
> development focus) and whether I should expect a new version unleashed 
> soon (any estimates?) - aren't gdb & insight development cycles closely 
> tied together?
> 

I agree with you 100%, but unfortunately we are subject to these black 
periods from time to time.  Until someone finds out that its not there 
anymore and decides to fund some of its development.

Last time Insight was saved by Intel funding, for which I will be 
forever grateful.

I wish the Red Hat / FSF issue was solved though, as it would entice 
more developers (although there is no real problem in assigning Insight 
work to Red Hat, as it is distributed anyway).

Unfortunately some things are only given due value when they go missing. 
  I just hope this happens again this time.


Regards to all,
Fernando

Re: Insight release schedule

[Christopher Faylor]

On Wed, Aug 11, 2004 at 08:44:06AM -0700, Keith Seitz wrote:
>My apologies for the wreckage.

And one of the side-effects (or is it a direct effect?) of the wreakage
is that there will be no new versions of insight for cygwin.  I'll
probably just release a non-insight version of gdb sometime soon,
though.

cgf

RE: Insight release schedule

[Dave Korn]

> -----Original Message-----
> From: insight-owner On Behalf Of Christopher Faylor
> Sent: 11 August 2004 17:00

> On Wed, Aug 11, 2004 at 08:44:06AM -0700, Keith Seitz wrote:
> >My apologies for the wreckage.
> 
> And one of the side-effects (or is it a direct effect?) of 
> the wreakage
> is that there will be no new versions of insight for cygwin.  I'll
> probably just release a non-insight version of gdb sometime soon,
> though.
> 
> cgf


  At least until they diverge too far, it'll still be pretty easy to
roll-your-own by copying the insight-related subdirectories[*] from an
earlier release (insight tarball) into a more up-to-date version of gdb.
WFMBYMMV.  It isn't really insight 6.2, of course, but if there are bugfixes
or whatever in the newer gdb that you need to have, there's no need to give
up using the gui.

    cheers, 
      DaveK

[*] itcl, libgui, tcl, tk, gdb/gdbtk and gdb/testsuite/gdb.gdbtk
-- 
Can't think of a witty .sigline today....

Re: Insight release schedule

[Andrew Cagney]

> On Wed, 2004-08-11 at 05:32, Sefer Tov wrote:
> 
>>> I was wondering whether insight is still under active development (it would 
>>> be a great shame if such an excellent tool will lose further development 
>>> focus) and whether I should expect a new version unleashed soon (any 
>>> estimates?) - aren't gdb & insight development cycles closely tied together?
> 
> 
> Unfortunately, Red Hat and the FSF have been unable to iron out there
> differences about getting insight officially contributed, so I am only
> answering email. (Ok, very occasionally will I actually do something. It
> happens. I get the urge. :-)

FYI, that isn't the problem, its admistrative (but resolving that 
requires a non-zero allocation from zero resources).

Andrew

Re: Insight release schedule

[Christopher Faylor]

On Wed, Aug 11, 2004 at 05:57:05PM +0100, Dave Korn wrote:
>>-----Original Message-----
>>From: insight-owner On Behalf Of Christopher Faylor
>>Sent: 11 August 2004 17:00
>
>>On Wed, Aug 11, 2004 at 08:44:06AM -0700, Keith Seitz wrote:
>>>My apologies for the wreckage.
>>
>>And one of the side-effects (or is it a direct effect?) of the wreakage
>>is that there will be no new versions of insight for cygwin.  I'll
>>probably just release a non-insight version of gdb sometime soon,
>
>At least until they diverge too far, it'll still be pretty easy to
>roll-your-own by copying the insight-related subdirectories[*] from an
>earlier release (insight tarball) into a more up-to-date version of
>gdb.  WFMBYMMV.  It isn't really insight 6.2, of course, but if there
>are bugfixes or whatever in the newer gdb that you need to have,
>there's no need to give up using the gui.

I assure you that I am capable of "rolling my own" without instruction
but this is definitely not something that I want to do.

cgf

RE: Insight release schedule

[Keith Seitz]

On Wed, 2004-08-11 at 09:57, Dave Korn wrote:
>   At least until they diverge too far, it'll still be pretty easy to
> roll-your-own by copying the insight-related subdirectories[*] from an
> earlier release (insight tarball) into a more up-to-date version of gdb.
> WFMBYMMV.  It isn't really insight 6.2, of course, but if there are bugfixes
> or whatever in the newer gdb that you need to have, there's no need to give
> up using the gui.

The sources in HEAD are kept relatively up-to-date. If there are API
changes in gdb which deprecate those used in insight, someone checks in
a fix -- when that happens is sorta iffy, but it does happen.

That's actually the one thing that I seem to find the motivation to do,
for some reason. I guess I just really want to dump the current stuff
and start over with something free & clear. 

I just don't see there being any advantage to developing insight when
there is still confusion/bickering/delay about it's real FSF status, and
the code is quickly becoming dated.

Anyone interested in starting a *new* UI for gdb? ;-)

Keith

RE: Insight release schedule

[Dave Korn]

> -----Original Message-----
> From: insight-owner On Behalf Of Christopher Faylor
> Sent: 11 August 2004 18:45

> On Wed, Aug 11, 2004 at 05:57:05PM +0100, Dave Korn wrote:
> >>-----Original Message-----
> >>From: insight-owner On Behalf Of Christopher Faylor
> >>Sent: 11 August 2004 17:00
> >
> >>On Wed, Aug 11, 2004 at 08:44:06AM -0700, Keith Seitz wrote:
> >>>My apologies for the wreckage.
> >>
> >>And one of the side-effects (or is it a direct effect?) of 
> the wreakage
> >>is that there will be no new versions of insight for cygwin.  I'll
> >>probably just release a non-insight version of gdb sometime soon,
> >
> >At least until they diverge too far, it'll still be pretty easy to
> >roll-your-own by copying the insight-related 
> subdirectories[*] from an
> >earlier release (insight tarball) into a more up-to-date version of
> >gdb.  WFMBYMMV.  It isn't really insight 6.2, of course, but if there
> >are bugfixes or whatever in the newer gdb that you need to have,
> >there's no need to give up using the gui.
> 
> I assure you that I am capable of "rolling my own" without instruction
> but this is definitely not something that I want to do.
> 
> cgf

  Steady on, old chap!  I was only pitching in with a bit of advice for the
OP who started the thread.  Sorry for not digging out an earlier post to
reply to!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

Re: Insight release schedule

[Duane Ellis]

>> Anyone interested in starting a *new* UI for gdb? ;-)

The primary benefit of Insight - vrs - DDD, XXGDB,
YourNameHere-GDB-frontend is the ease of cross platform support that
Tcl/Tk gives you, specifically - linux <-vrs-> cygwin.

What if you where to view this from the other direction - turn your
entire suggestion or question on it's head and look at it upside down.

It's a radical move. Perhaps very hair-brained.

That is to say rip GDBs existing command-line structure out and
replace it with tcl. All old commands and methods would effectively
become deprecated, or recreated in Tcl as needed.

Tcl would be come the 1st class command language to GDB rather then a
wrapper around the GDB commands.

BENIFITS

* Far more richer command set.

  Suddenly GDB gains a far more powerful set of macros, scripting
  language, etc - vrs - its existing very debugger centric set of
  commands. Have you ever written GDB Macros?  I have found that it is
  always lacking somewhere, with something, or some feature.

* Front ends providers could write, or add what ever additional
  commands they need - from a rich and powerful language.

  Perhaps - a better "package require FrontEndProtocol" could be
  used to unify all of these commands.

* Most frontends parse the output of the display or print command, if
  you mess with the default formats - you can break front
  ends. Example: Quite often Insight captures the output of printf() -
  that gets really funky and really hairy.

* Exiting front ends that do not have the abilty to add a GUI macro
  button - immediately gain the abilty to add buttons - just type the
  command "package require Tk" create a new window with what ever
  buttons you want. 
  
  Ok - it is not well not integrated into their GUI front end - but a
  window with buttons none the less. Ever want to add a button to
  XXGDB?

* Macros - with GUI elements, written for XXGDB, work with DDD, and
  work with Emacs-GUD mode, etc....

  TK as the graphic front end is not that far out there - it was
  originally glued onto Tcl, but has since been glued on to PerlTK,
  PythonTk, and other things.

* A far better set of regression test scripts, etc, could be written
  with Tcl to perform regressions tests - ineffect, GDB would have the
  core of 'expect' built into it.

* Insight would become nothing more then one giant macro that you
  enable via "package require Insight"

* People are doing something like this now - the best example of this
  I know of is the ModelTech Verilog simulator called modelsim. See
  www.model.com, you can control all kinds of things while debugging
  your hardware simulation.

  If you want to try it out - goto Xilinx.com - download the free chip
  programing software, it comes with a tiny version of ModelTech
  Modelsim.

Again - hairbrained... Lots of work... And very radical. But the
benifit and/or win would be enormous.

-Duane.

Re: Insight release schedule

[Keith Seitz]

On Wed, 2004-08-11 at 12:08, Duane Ellis wrote:

> Again - hairbrained... Lots of work... And very radical. But the
> benifit and/or win would be enormous.

Radical for gdb maybe, not for me. Not hairbrained, either. This is
definitely something that Jim Ingham, Martin Hunt, Fernando Nasser, and
I have talked about many, many times before (long, long ago now, it
seems).

FWIW, I've always liked this idea. It would be so much easier for people
to create custom views of their data/memory/etc. One really neat thing
that you could do is write some really elaborate breakpoint conditions.
Image using strcmp [hmph, "string compare" :-)] in a breakpoint
condition. Lo! How I wish I could have done that trying to chase down
symtab problems in gdb!

Keith

Re: Insight release schedule

[Evan Lavelle]

Keith Seitz wrote:

> On Wed, 2004-08-11 at 12:08, Duane Ellis wrote:
> 
> 
>>Again - hairbrained... Lots of work... And very radical. But the
>>benifit and/or win would be enormous.
> 
> 
> Radical for gdb maybe, not for me. Not hairbrained, either. This is
> definitely something that Jim Ingham, Martin Hunt, Fernando Nasser, and
> I have talked about many, many times before (long, long ago now, it
> seems).
> 
> FWIW, I've always liked this idea. It would be so much easier for people
> to create custom views of their data/memory/etc. One really neat thing
> that you could do is write some really elaborate breakpoint conditions.
> Image using strcmp [hmph, "string compare" :-)] in a breakpoint
> condition. Lo! How I wish I could have done that trying to chase down
> symtab problems in gdb!

Umm... can't you already do that?
break X::Y if(!strcmp(Z, "wibble"))

Pity about the licence problem. I'm just working up to dumping gdb 
entirely, and spending $900 on totalView, although it seems to have some 
C++ issues.

Evan

Re: Insight release schedule

[Tom Tromey]

>>>>> "Duane" == Duane Ellis <duane@franklin.com> writes:

Duane> Tcl would be come the 1st class command language to GDB rather then a
Duane> wrapper around the GDB commands.

Mo DeJong once wrote a Tcl library that understood MI, the idea being
you could then write Tcl scripts to drive gdb very easily.  I don't
know if he ever released this though.  It seemed like a nice idea to
me; similar to, but not exactly the same, as what you're proposing.

Tom

Re: Insight release schedule

[Keith Seitz]

On Wed, 2004-08-11 at 15:01, Evan Lavelle wrote:
> Keith Seitz wrote:
> 
> Umm... can't you already do that?
> break X::Y if(!strcmp(Z, "wibble"))
> 

Sure, but it involves allocating memory in the inferior (for the string
and the dummy stack) and an inferior function call. Not the nicest of
things to do... (I certainly don't advocating doing that in gdb!)

YMMV.
Keith

Re: Insight release schedule

[Fernando Nasser]

When I separated the gdb UIs to create the CLI and MI I did it so that 
we could also create a Tcl UI.  If you look carefully at the design 
you'll see that it was intended for Tcl and to have Insight at the top.

Fernando


Tom Tromey wrote:
>>>>>>"Duane" == Duane Ellis <duane@franklin.com> writes:
> 
> 
> Duane> Tcl would be come the 1st class command language to GDB rather then a
> Duane> wrapper around the GDB commands.
> 
> Mo DeJong once wrote a Tcl library that understood MI, the idea being
> you could then write Tcl scripts to drive gdb very easily.  I don't
> know if he ever released this though.  It seemed like a nice idea to
> me; similar to, but not exactly the same, as what you're proposing.
> 
> Tom
> 

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