From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6104 invoked by alias); 14 Oct 2011 20:30:27 -0000 Received: (qmail 6092 invoked by uid 22791); 14 Oct 2011 20:30:25 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta15.emeryville.ca.mail.comcast.net (HELO qmta15.emeryville.ca.mail.comcast.net) (76.96.27.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Oct 2011 20:30:11 +0000 Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta15.emeryville.ca.mail.comcast.net with comcast id kjQA1h0051u4NiLAFkW4ds; Fri, 14 Oct 2011 20:30:04 +0000 Received: from [10.127.238.91] ([65.206.2.68]) by omta21.emeryville.ca.mail.comcast.net with comcast id kkdy1h00d1U2a2h8hke1TK; Fri, 14 Oct 2011 20:38:08 +0000 Subject: Re: Python: fetch value when building gdb.Value object Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Fri, 14 Oct 2011 20:30:00 -0000 Cc: gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <2F165381-183F-471F-8F55-457F08E6B008@comcast.net> References: <36B29E9D-F2B3-446F-AF8A-97254A3AAEE2@comcast.net> <21467A42-84A3-4DFD-83A9-28FFFB0A5C7F@comcast.net> To: Tom Tromey 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: 2011-10/txt/msg00426.txt.bz2 On Oct 14, 2011, at 4:03 PM, Tom Tromey wrote: >>>>>> "Paul" =3D=3D Paul Koning writes: >=20 > Tom> I am not convinced that this is the right approach. >=20 > Tom> I think it would probably be better to expose the laziness to the Py= thon > Tom> programmer -- via a new attribute and a new method to un-lazy the > Tom> object. >=20 > Tom> The reason is that eager fetching can be very expensive. E.g., you = may > Tom> construct an intermediate value that is a very large array, but inte= nd > Tom> only to reference a few elements. This can be done efficiently by g= db, > Tom> but eager fetching will defeat that. >=20 > Paul> I modeled what I did after the way the existing GDB code handles > Paul> convenience variables. >=20 > Convenience variables aren't really the best model. First, they are > very old, probably predating anybody worrying about this stuff. Second, > the CLI isn't really a fully-featured programming language. That's fair. At this point the change has been approved and committed (that happened bef= ore your comments arrived). So I guess we have a question of whether to ch= ange it back. paul