From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16349 invoked by alias); 10 Jul 2008 19:43:03 -0000 Received: (qmail 16243 invoked by uid 22791); 10 Jul 2008 19:43:01 -0000 X-Spam-Status: No, hits=-1.9 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; Thu, 10 Jul 2008 19:42:29 +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 m6AJgPsx019634; Thu, 10 Jul 2008 15:42:25 -0400 Received: from pobox.fab.redhat.com (pobox.fab.redhat.com [10.33.63.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6AJgOb5019076; Thu, 10 Jul 2008 15:42:24 -0400 Received: from [10.32.4.53] (vpn-4-53.str.redhat.com [10.32.4.53]) by pobox.fab.redhat.com (8.13.1/8.13.1) with ESMTP id m6AJgMi4027014; Thu, 10 Jul 2008 15:42:23 -0400 Message-ID: <487665E9.1050601@redhat.com> Date: Thu, 10 Jul 2008 19:43:00 -0000 From: Dodji Seketeli Organization: Red Hat User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Thiago Jung Bauermann CC: Tom Tromey , Frysk List Subject: Re: Changes References: <1215663421.5233.33.camel@localhost.localdomain> In-Reply-To: <1215663421.5233.33.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/msg00019.txt.bz2 Thiago Jung Bauermann a écrit : [...] > >> * Integrate with Eclipse > > The debugger being in C++, do you see this happening with an MI-like > interface? > I'd think that starting off with the debugging engine being alone in its own process can be something good for many reasons: 1/being in one coherent language, whatever the language is. If the language is c/c++ that eases debugging during developments thanks to tools like valgrind etc ... 2/shield the user interface against wierd things like signal based interactions that can happen between the debugging engine and the inferior process being debugged. 3/gives a chance to the UI process to be single threaded, using mainloops like the glib mainloop or the Qt mainloop to come up with non blocking UIs and still being asynchronously notified about state changes in the remote debugging engine process. This scenario requires a wire protocol. It's not obliged to be GDB/MI, though. [...] > > Nice. IMHO, starting from scratch again in C++ would be just more work > at the end of the day... IMHO again the way to go is to reuse as much > code as possible, including from GDB. The idea is to take the shortest > path to a good working solution. > Exactly. That's also why having the debugger in C/C++ can be interesting. It eases code sharing with GDB. Much more than if we need to write (and debug) bindings each time we want to use a C function coming from outside. [...] > > So having a GUI separate from Eclipse is within the goal of the project? > Just not the existing one? Sorry, I'm not sure I understood this part. > I'd think that if the APIs UI <-> debugging engine are well defined and nice, debugger UIs including ad hoc tools built by other project to debug particular scenarii we don't even know about today will be likely to flourish. >> * 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. > > I like the idea of a patch review process, I agree it will be a benefit. Yes, I like that as well. If we stick to git - I love git - I think it could be nice do something like what the X.org project did. Potential contributors foo could be given write access to sourceware.org/users/foo so that they can slam their own branches in there. They'd then post urls to the commits (in their branches) they want to see pushed to the official tree and wait for reviewers approval. Of course that wouldn't remove the possibility to send patches to the list directly. My 2 euro cents. Cheers, Dodji.