From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12199 invoked by alias); 11 Feb 2008 13:07:00 -0000 Received: (qmail 12188 invoked by uid 22791); 11 Feb 2008 13:07:00 -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; Mon, 11 Feb 2008 13:06:40 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 66B1398036; Mon, 11 Feb 2008 13:06:38 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 108B19801D; Mon, 11 Feb 2008 13:06:37 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JOYMm-00026n-CS; Mon, 11 Feb 2008 08:06:36 -0500 Date: Mon, 11 Feb 2008 13:07:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: Nick Roberts , gdb@sources.redhat.com Subject: Re: Variable objects and STL containers Message-ID: <20080211130636.GA7796@caradoc.them.org> Mail-Followup-To: Vladimir Prus , Nick Roberts , gdb@sources.redhat.com References: <18343.64413.689019.489727@kahikatea.snap.net.nz> <200802101010.49506.ghost@cs.msu.su> <18351.26207.310382.539746@kahikatea.snap.net.nz> <200802111211.36848.ghost@cs.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802111211.36848.ghost@cs.msu.su> User-Agent: Mutt/1.5.17 (2007-12-11) 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: 2008-02/txt/msg00057.txt.bz2 On Mon, Feb 11, 2008 at 12:11:36PM +0300, Vladimir Prus wrote: > I think that likewise, -var-update should create varobjs for new children, > and return them -- we probably need a new attribute to indicate that a varobj > was just created. This might sound like breaking frontends not prepared to see > new varobjs in -var-update output. However, this dynamic child behaviour will > happen only as result of explicit request from frontend. It's natural to > give frontend a choice between 'raw' representation and 'pretty' representation, > and for compatibility, it's best to default to 'raw'. And if frontend asks > gdb to use pretty representation for a varobj, or all varobj of given type, > we can expect the frontend to property handle auto-created varobjs. I suggest we wait until you have something implemented, and then see how various front ends (emacs, kdevelop, Eclipse) react to it. If they break, we can limit the new behavior to mi3. I want to finish up the quoting changes I discussed last year for mi3, too... -- Daniel Jacobowitz CodeSourcery