From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30740 invoked by alias); 5 Jan 2007 09:26:00 -0000 Received: (qmail 30732 invoked by uid 22791); 5 Jan 2007 09:25:59 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 05 Jan 2007 09:25:53 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-248-242.inter.net.il [80.230.248.242]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id GSP21421 (AUTH halo1); Fri, 5 Jan 2007 11:25:48 +0200 (IST) Date: Fri, 05 Jan 2007 09:26:00 -0000 Message-Id: From: Eli Zaretskii To: Vladimir Prus CC: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: <200701051139.09498.ghost@cs.msu.su> (message from Vladimir Prus on Fri, 5 Jan 2007 11:39:09 +0300) Subject: Re: [doc] improve MI varobj introduction Reply-to: Eli Zaretskii References: <200612191103.55137.vladimir@codesourcery.com> <200701051139.09498.ghost@cs.msu.su> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00180.txt.bz2 > From: Vladimir Prus > Date: Fri, 5 Jan 2007 11:39:09 +0300 > Cc: drow@false.org, > gdb-patches@sources.redhat.com > > > > +Variable object is MI interface to work with expressions. > > > > Perhaps it's an interface to work with named expressions, because I > > believe you don't need anything to work with just expressions, do you? > > Although you can use -data-evaluate-expression, using varobj is the recommended > way. I don't think "named expressions" is the key here -- if MI was an interface > in any object oriented language, you would not need varobj name at all. But since MI > is pipe interface, you need some opaque token instead of object reference in a > programming language. So no fundamentally named expression are involved. > How about: > > Variable object is the recommended MI interface to work with expressions. This doesn't give a clue why it is the recommended way. I have another suggestion, based on what you explained above: Variable objects are an MI convenience feature to reference expressions. When a frontend creates a variable object, it specifies a name for an arbitrary expression in the debugged program. That name can henceforth be used as an opaque handle for the expression. The expression can be a simple variable, or it can be ... Okay? > > > Child variable objects can children themself, > > > +util we reach leaf variable objects of built-in types. ^^^^^^^^ > > ^^^^ > > Typos, and also something's wrong with this sentence in general. > > Changed to: > > > Child variable objects can themself have children, > util we reach leaf variable objects of built-in types. Hmmm... something is still wrong. I think you meant this: A child variable object can itself have children, until we reach leaf variable objects which have built-in types. > Revised patch attached -- hopefully better this time. Yes, thanks. The above two gotchas are the only things that need to be taken care of.