This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Insight release schedule


>> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]