From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8438 invoked by alias); 10 Jul 2008 08:24:29 -0000 Received: (qmail 8429 invoked by uid 22791); 10 Jul 2008 08:24:28 -0000 X-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Jul 2008 08:24:10 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6A8O8tn024519 for ; Thu, 10 Jul 2008 04:24:08 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6A8O8KT026383; Thu, 10 Jul 2008 04:24:08 -0400 Received: from localhost.localdomain (vpn-6-29.fab.redhat.com [10.33.6.29]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6A8O6rT009807; Thu, 10 Jul 2008 04:24:07 -0400 Message-ID: <4875C725.9090606@redhat.com> Date: Thu, 10 Jul 2008 08:24:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: tromey@redhat.com CC: Frysk List , overholt@redhat.com Subject: Re: Changes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00015.txt.bz2 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