From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30259 invoked by alias); 12 May 2006 12:54:01 -0000 Received: (qmail 30248 invoked by uid 22791); 12 May 2006 12:53:59 -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; Fri, 12 May 2006 12:53:54 +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 <20060512125352.VUD15797.eastrmmtao03.cox.net@localhost.localdomain>; Fri, 12 May 2006 08:53:52 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FeXA9-0005CR-OE; Fri, 12 May 2006 08:54:33 -0400 Date: Fri, 12 May 2006 12:59:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: CLI and GDB/MI documentation patch Message-ID: <20060512125433.GD26655@brasko.net> Mail-Followup-To: Eli Zaretskii , gdb-patches@sources.redhat.com References: <20060512011730.GA26655@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00238.txt.bz2 On Fri, May 12, 2006 at 10:53:43AM +0300, Eli Zaretskii wrote: > > Date: Thu, 11 May 2006 21:17:30 -0400 > > From: Bob Rossi > > > > I hope this looks correct. Please let me know otherwise. I think it's > > an improvement over what is there now, and could save others valuable > > research time. > > Sorry, I don't understand what you are trying to say here, exactly. > Explaining why we did something in the past does not belong in the > manual (except maybe in a footnote, if it is _very_ important to > mention history). Well, I see your point, and you are the expert in this area. The reason I put this in the manual is because I think it's important front end developers know what will happen when they enter CLI commands into mi2. Old versions of mi2 will act incorrectly, where as new versions of mi2 will work better. > Perhaps I wasn't following the thread closely enough, so I missed > something important. Can you state what information is missing from > the current text in this section? You say above that the changes > ``could save others valuable research time''--what did you need to > research, and why, and what did you find that wasn't described in the > manual? Well, first off, this is incorrect: This mechanism is provided as an aid to developers of @sc{gdb/mi} clients and not as a reliable interface into the CLI. So I thought it was important to describe that it is OK to pass CLI commands to the MI interpreter for now. However, using -interpreter-exec is a better approach. Also, look at Vladimir's comments. None of this information is intuitive using the MI interface. You have to slowly figure it out. Thanks, Bob Rossi