From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8340 invoked by alias); 30 May 2006 18:56:09 -0000 Received: (qmail 8330 invoked by uid 22791); 30 May 2006 18:56:09 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao03.cox.net (HELO eastrmmtao03.cox.net) (68.230.240.36) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 30 May 2006 18:54:48 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao03.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060530185445.NRGS15797.eastrmmtao03.cox.net@localhost.localdomain>; Tue, 30 May 2006 14:54:45 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1Fl9Mc-0006V2-AQ; Tue, 30 May 2006 14:54:46 -0400 Date: Tue, 30 May 2006 20:46:00 -0000 From: Bob Rossi To: Jim Ingham Cc: gdb@sources.redhat.com Subject: Re: MI query questions Message-ID: <20060530185446.GF31100@brasko.net> Mail-Followup-To: Jim Ingham , gdb@sources.redhat.com References: <20060529122337.GB2021@brasko.net> <20060529144640.GA12145@nevyn.them.org> <20060530171518.GB31100@brasko.net> <7A4B9D88-47FB-4721-949F-632AF2E449FC@apple.com> <20060530175310.GD31100@brasko.net> <20060530181143.GE31100@brasko.net> <6FE49E5C-CD1C-45FC-B2FF-97E4B2FFA779@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6FE49E5C-CD1C-45FC-B2FF-97E4B2FFA779@apple.com> User-Agent: Mutt/1.5.9i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00403.txt.bz2 On Tue, May 30, 2006 at 11:40:51AM -0700, Jim Ingham wrote: > Seems like having a callback in your parser to handle async messages > from gdb represents cleanly what is going on. You haven't gotten a > completed MI command yet, and you're not ready for another MI > command. But gdb is asking on the side for more input. Seems like > making the two cases look the same is more likely to cause trouble. I undstand, and sort of agree with you. However, things get slightly worse from my perspective. I've designed my FE thus far to behave like this: - It is always looking for data from GDB to assemble MI output records. - It will send only a single GDB command at a time. With that in mind, my FE assembles an MI output record, and then sends it up the chain to be looked at more specifically. However, with this callback-in-the-middle scenario, my FE will have to be retrained to handle partially returned MI output records. Does this seem acceptable to you? For instance, the annotate=2 looks like this: pre-prompt (gdb) prompt b A::func post-prompt [0] cancel [1] all [2] A::func(float) at overloaded.cpp:8 [3] A::func(int) at overloaded.cpp:7 pre-overload-choice > overload-choice I think the overload choice is as much a prompt as any other command. I'm not exactly sure why you think it's a "special" input from the user. I do see your point about the way your FE does this, however, do you see my point here? Thanks, Bob Rossi