From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5941 invoked by alias); 7 Sep 2007 18:06:00 -0000 Received: (qmail 5927 invoked by uid 22791); 7 Sep 2007 18:05:59 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Sep 2007 18:05:52 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 23A23982AD; Fri, 7 Sep 2007 18:05:53 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 215D59814E; Fri, 7 Sep 2007 18:05:51 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1ITiDE-0001Wa-Az; Fri, 07 Sep 2007 14:05:48 -0400 Date: Fri, 07 Sep 2007 18:18:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Vladimir Prus , nickrob@snap.net.nz, gdb@sources.redhat.com Subject: Re: MI: "^running" issues Message-ID: <20070907180548.GA5595@caradoc.them.org> Mail-Followup-To: Eli Zaretskii , Vladimir Prus , nickrob@snap.net.nz, gdb@sources.redhat.com References: <200709041653.22357.ghost@cs.msu.su> <18145.5117.427647.382269@kahikatea.snap.net.nz> <200709071404.14065.ghost@cs.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00084.txt.bz2 On Fri, Sep 07, 2007 at 08:56:06PM +0300, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Fri, 7 Sep 2007 14:04:13 +0400 > > Cc: Eli Zaretskii , > > gdb@sources.redhat.com > > > > That's pretty much what I was complaining recently -- without a design > > doc for async mode it's not only impossible to understand the existing > > code, but it's also impossible to understand the code that you're proposing. > > We don't require a design doc for any other change, and I don't see > why the async mode should be any different. We ask for more information than we've got in this case, though. And you try to get internals chapters written for things like this :-) We're in a tricky situation. The developers of async mode were respected contributors - but they're not here any more to explain their work. It doesn't work as-is, so we can't test it. And Nick's patches to bring it into shape require someone who really understands what they're doing to review them. That's not going to be me, since I couldn't figure the patches out when I last tried. -- Daniel Jacobowitz CodeSourcery