This is the mail archive of the mailing list for the frysk 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]


Here's the first message of the messages I promised during the

Red Hat is revisiting its interest in Frysk.  In particular, our goal
is now:

   Build the best C++ debugger in the world.

This has a few sub-goals:

* Have a CLI
* Integrate with Eclipse
* Scale to very large programs (w/ lots of shared libraries)
* Scale to many threads

In particular I think Red Hat is not going to pursue Frysk's current
monitoring and tracing goals, or the existing GUI.

I'm sending everything in this message to this list.  However, if the
consensus is that we need a new list, that would also be fine by me.
Meanwhile I'll carry on here.

Internally we've revisited a number of decisions made during the
course of Frysk's development.  I'll summarize here our current
thinking about what we'd like to do.  Comments, criticism, etc are

Note that I'm using the Red Hat "we" in the below.  I'm sure that
individuals disagree with various statements here.  (Feel free to
speak up, etc.)  I am responsible for anything you read here, and I
don't want to avoid that, but I did not want to take undue credit for
ideas, etc, which are not mine.

* Java.  We've heard many times while discussing Frysk with other
  parties that the choice of Java is an odd one.

  In order to more fully align the interests of the developers of the
  debugger with the interests of its users, we'd like to use C++ as
  the implementation language.  We picture refactoring the core of
  Frysk into C++; not changing the design but simply the
  implementation language.

* Scripting.  One issue with gdb is its poor support for scripting.
  We think scripting is needed for debugger programmability, and in
  particular that it will be needed for C++ pretty-printing.  So, our
  thinking is that this debugger would have a Python binding to its

  In order to exercise this binding code, we picture rewriting the
  existing CLI code in Python.  The idea here is that part of the CLI
  need a rewrite anyhow, and there is no particular reason that the
  CLI needs to be written in C++.

* HPD.  We discussed HPD a little.  It seems ok, overall, though a bit
  underpowered; in particular there are common debugging operations
  that one can do in gdb which have no analog in HPD.  So, we know we
  must at least extend it.

  Some people expressed concern that the HPD language differs
  needlessly from gdb -- meaning that they need to re-learn things to
  try a new debugger.  I don't think we have a particular solution in
  mind for this.  We could move more toward a gdb-like CLI, or we
  could supply a compatibility mode; dunno.

  We think it makes sense to still have a CLI even though there is
  also a scripting language under the hood.  The reason for this is
  simply that Python would make for a funny CLI -- you'd have to quote
  arguments, etc.

* We would like to drop the existing GUI.  It does not align with our
  goals.  However, as I said during the meeting, if someone wants to
  maintain the GUI, that would be fine.

  We may want a standalone debugger GUI.  One idea is to see if we can
  reuse the Eclipse work using RCP.  Another idea is to go the gdb
  route and hope some 3rd party either writes one, or ports and
  existing one from gdb.

* Naming.  There's some contention as to whether the result should
  keep the name "Frysk".  I will let proponents and opponents make
  their arguments; I don't have an opinion on this.

* Process.  We'd like to institute some form of patch review.  Ideally
  this would be low on bureaucracy; perhaps just an Apache-style "+1"
  voting system.  The intent here is to raise coding standards overall
  -- make sure that features have more polish when they go in, and
  that both internal and external documentation are included.

* Roadmap and milestones.  We want to publish a general roadmap along
  with milestones that will describe roughly what features will be
  available when.  I don't know whether this is interesting to non-Red
  Hat folks; if not we can do this internally.  Let us know.

  The general milestone idea we've been discussing is "depth first" --
  using user-visible features to drive the development process; but
  probably the "releases" would be time-based as much as possible.

  The roadmap will be where we figure out what "best C++ debugger"
  means -- that is, what specific features this entails.  We'll be
  starting that process on this list (or elsewhere in public) soon.

* Licensing.  We discussed this at the meeting.  Eric is looking into
  the ownership issue and the choice of license.

  We've talked a bit about constraints on the license and owner:

  * Who owns the current code; what do we need to drop or relicense if
    we want to change the license
  * Can we assign to the FSF or some other entity?
  * What constraints does our Eclipse integration approach put on the
    choice?  Rick is looking into some details here.
  * Can we reuse bits of gdb if we want?  (There are a few things that
    might be worth reusing.)

* GDB.  A recurring question is: why not expend our efforts improving
  gdb?  There are no easy answers here; the tradeoffs are complicated.

  This is probably more of a Red Hat internal decision (it is about
  where we want to focus our efforts, not about the frysk project per
  se) -- but it is an obvious and important question and deserves to
  be brought up here.

  We're open to arguments either way on this topic.  Given our goals,
  what would you choose to do?

That is pretty concise.  I'm happy to try to expand on anything that
seems unclear -- goals, reasoning, etc.

I don't think I've forgotten anything here, but if I did, please bring
it up.

Since we want to build a healthy community around this project, your
opinion matters.  Please share it.  Aside from Red Hat's goals,
nothing here is truly decided; it is all open to debate.


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