Re: Changes

[Phil Muldoon <pmuldoon@redhat.com>]

Tom Tromey wrote:


Hi Tom,

> Here's the first message of the messages I promised during the
> meeting.
>
> Red Hat is revisiting its interest in Frysk.  In particular, our goal
> is now:
>
>    Build the best C++ debugger in the world.
>   


I brought these up as off-the-cuff remarks in a previous conversation, 
but I think they have some meaning as a guiding principles:

- must not mislead the user by presenting incorrect data;
- must not further erode the stability of the inferior;
- must not quiesce the inferior unless necessary.

I'm sure there are others. I think a set a common quality criteria would 
be good principles to keep in mind.

Brought up in the meeting, but in email too:  What are our 
differentiators? There are several debuggers out there. How will this 
one be better than the others? Will it do "stuff" better, will it do 
"stuff" that the others don't?


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

Language choice is not a terribly compelling debate for me; I'll happily 
use whatever language people reason for. However for completeness here 
are my arguments for C++:

- it places the project in the same environment as C++ developers, their 
pain is our pain;
- we will use our debugger to solve our own C++ problems;
- C++ acts as a common language to reimplement ideas for C, and from Java.

In particular, porting of existing patterns should not be so painful in 
C++ from Java. I think there are many patterns in Frysk that are high 
value and well worth porting.

> * 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
>   core.
>
>   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++.
>   

This is incredibly important, and should be a guiding goal from day one. 
It should be clear and present in all our minds as we design this 
debugger.  I cannot see the days of a monolithic debugger with wire 
protocols lasting too much longer. The maintenance and erosion of any 
large code base are compelling stories in terms of cost. 

If there is a particular reason for it, and the tools we create are 
"present and well-designed", I think people will write their own layers 
of utilities on top of our own. What better measure of success if people 
use our scripting support to create their own tools?


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


Other than some small fixes that Rick has heroically being putting into 
the UI, there has not been any serious work on it for over a year. It 
was effectively de-staffed. I think this is a non-issue, it's been 
dropped already.


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

For our first client, I really don't want a huge dependency chain that 
may come with an Eclipse Rich Client Platform  application. However, I 
think an Eclipse IDE plug-in - hosted and developed on the Eclipse Linux 
distribution project - is an essential element. I've  CC'd Andrew 
Overholt; I'd really value his opinion. But for my own 2 pence worth,  
the IDE plug-in  should really be integrating with DSDP-DD project 
goals. GDB/MI is the only client of DSDP-DD that I have knowledge at the 
moment, and that is driving the design. It shouldn't, we should ;)

Personally as an initial driver, I would much rather see existing 
lightweight tools ported to work with our engine. I've spent the last 
two weeks examining Nemiver; its back-end code is built for expansion to 
other engines. As part of our outreach, we should engage  developers of 
existing tools and try to persuade them to develop with us.


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

I think we should start a new project, with a new name. It's been done 
before. Frysk used to be called Accudog. Leave the Frysk base as it is, 
and start a new project site. Maybe at Fedora Hosted. Or somewhere else. 
The current name is saddled with  previous release experiences, and 
instability.  If the new debugger is written from scratch with ideas 
from Frysk, it''s not Frysk; it is something derived or based on Frysk 
and GDB.


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

Good. Some ideas:

- no change should go into the base without at least one person seeing it;
- no refactor should ever happen as an imposition of one will over another.;
- good humour, in an environment of learning.

This project is far too big and complex for one brain; we will all be 
deeply novice in many areas, while being expert in others.  I look 
forward to this discussion.

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

I think a release roadmap is compelling to the project. No reason for 
one company to have one roadmap and another have theirs. Lets see if the 
people on the project now, across all the companies can come up with a 
mutual document. This gives list-lurkers a chance to show-up and be seen ;)


> * 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?  

I've talked in this email about ideas regarding a new debugger, so my 
ideas are pretty transparent here. I'll tackle the GDB question in 
another separate email.

Regards

Phil