From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21686 invoked by alias); 11 Jul 2008 16:55:43 -0000 Received: (qmail 21677 invoked by uid 22791); 11 Jul 2008 16:55:42 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,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; Fri, 11 Jul 2008 16:55:16 +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 m6BGtBxt017243; Fri, 11 Jul 2008 12:55:11 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BGtBZC003281; Fri, 11 Jul 2008 12:55:11 -0400 Received: from opsy.redhat.com (vpn-10-60.bos.redhat.com [10.16.10.60]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6BGtAG0007993; Fri, 11 Jul 2008 12:55:10 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 14FDA88808C; Fri, 11 Jul 2008 10:55:10 -0600 (MDT) To: Thiago Jung Bauermann Cc: Frysk List Subject: Re: Changes References: <1215663421.5233.33.camel@localhost.localdomain> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Fri, 11 Jul 2008 16:55:00 -0000 In-Reply-To: <1215663421.5233.33.camel@localhost.localdomain> (Thiago Jung Bauermann's message of "Thu\, 10 Jul 2008 01\:17\:01 -0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00021.txt.bz2 >>>>> "Thiago" == Thiago Jung Bauermann writes: Tom> In particular I think Red Hat is not going to pursue Frysk's current Tom> monitoring and tracing goals, or the existing GUI. Thiago> Perhaps this can be left as a dormant goal, to be revisited when a Thiago> working solution is at hand? It is fine by me. If someone wants to pick this up right away, that is also fine -- this part was just more a statement of Red Hat's goals. I am not sure that there is any infrastructure that would be useful to a tracing task that would not also be useful to a debugger. So, in terms of the core, I could not think of anything that would need to be different. (If you know of something here, I'd like to hear it.) So, this is more about what deliverables Red Hat wants, and what parts of the tool Red Hat plans to work on. Thiago> Nice. IMHO, starting from scratch again in C++ would be just more work Thiago> at the end of the day... IMHO again the way to go is to reuse as much Thiago> code as possible, including from GDB. The idea is to take the shortest Thiago> path to a good working solution. This particular decision has been bothering me all week. And, I don't really have an answer, or even a good process to arrive at an answer :( I'll address that more in the roadmap email. Tom> We may want a standalone debugger GUI. One idea is to see if we can Tom> reuse the Eclipse work using RCP. Another idea is to go the gdb Tom> route and hope some 3rd party either writes one, or ports and Tom> existing one from gdb. Thiago> So having a GUI separate from Eclipse is within the goal of Thiago> the project? Just not the existing one? Sorry, I'm not sure I Thiago> understood this part. Yeah, sorry. It is confusing. The current GUI does not align with our goals. Red Hat may at some point want a standalone classic debugger GUI. However, it isn't totally decided. I probably should have simply left this off the list. Tom