From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2020 invoked by alias); 27 Apr 2012 11:03:21 -0000 Received: (qmail 2011 invoked by uid 22791); 27 Apr 2012 11:03:20 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Apr 2012 11:03:07 +0000 Received: by qady23 with SMTP id y23so266057qad.0 for ; Fri, 27 Apr 2012 04:03:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=sQw09QwCXhHLNsufaW/LbzMfD4T0cCY5WRYs60T4nmI=; b=glsrWMHxmSm/sSTrLai3L49U3t2VnWhtd7SDiGK/i95d+AljWAYeKLVgZc96OxTQJI IBkW3UY2+9JWfKVyZbnl3dy8QnH64dOGFwyKCCxym/EuQiOhczrpnfe5lai9kL0VV2tq G9l0jFB/IL5EnzqVJQFs106+1L/d6opoFr7TzNFJT8yPKZ0PhbgYeNP424hcMA4VsJy0 XA0HLVZy0jYWHrAqwxa6rDPZdh1x5w8SAE5PX0dkk/NEP3l94n4vmDJLxKujC/fGc33O 70ub03VUqtqh5hOdLk0PUAYMI3wDCcdYBJHQi3gT6pfU8oCjE5wnU4l5xfOxtgScTrds nx1Q== Received: by 10.224.215.132 with SMTP id he4mr140703qab.96.1335524587207; Fri, 27 Apr 2012 04:03:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.215.132 with SMTP id he4mr140686qab.96.1335524587004; Fri, 27 Apr 2012 04:03:07 -0700 (PDT) Received: by 10.224.215.132 with HTTP; Fri, 27 Apr 2012 04:03:06 -0700 (PDT) In-Reply-To: <83fwbqinsw.fsf@gnu.org> References: <83bomgfcbt.fsf@gnu.org> <87ipgna94k.fsf@fleche.redhat.com> <83y5pjedjp.fsf@gnu.org> <87397qa9a0.fsf@fleche.redhat.com> <83fwbqinsw.fsf@gnu.org> Date: Fri, 27 Apr 2012 13:15:00 -0000 Message-ID: Subject: Re: [RFC - doc] Add note about the possibility of symbols getting moved across blocks From: Siva Chandra To: Eli Zaretskii Cc: Tom Tromey , Doug Evans , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnUU7ERUzY+rWg8dmjjo8Rw1lIGYfCyeeWJI+Q96Du1St/OTuckAFYccDs6Mi2J+2E3MDWls/HcIo2uOOD2hyAIUsTaxBQOQkr2mGbpIwVaGF2WlMIDohVrBNfgDVQ5jNxOejzgxwQL0VbVHjT3Wsl+DCb3zA== 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: 2012-04/txt/msg00982.txt.bz2 On Thu, Apr 26, 2012 at 7:43 PM, Eli Zaretskii wrote: > Maybe I simply miss something important here. =A0The text in question > says this: > > =A0 A @code{gdb.Block} is iterable. =A0The iterator returns the symbols > =A0 (@pxref{Symbols In Python}) local to the block. =A0Users using this > =A0 feature should keep in mind that future improvements to the internal > =A0 representation, of symbols and symbol tables, can move symbols across > =A0 blocks within a symbol table. > > Are you saying that future changes will prevent the possibility to > get the symbols local to the block by iterating it? =A0That's not what > the last sentence above seems to say. =A0It says that the symbols might > be found in a different block, or something to that effect. =A0At least > that's what I understand from reading it. =A0If my understanding is > correct, how would my Python program that works today break with > future versions of GDB? This is my thought: Take Tom's example of current 'globals' ending up in a namespace block due to a future change. Now, this is just an example. Meaning, a future existence of a namespace block is a speculation now. Since it is a speculation, it could eventually so happen that we will not have a namespace block but something else or nothing at all. Hence, how things would change are unknown now, but there is a chance that things will change. What Doug and Tom are trying to say is that, "It is OK to use the API now and for some time in future, but keep an eye out for changes and change accordingly." Also, since how things would change in future is unknown now, it is probably not possible to specify now as to how exactly would a Python program break in future. AFAICT, if there is a change in future which can break an existing Python program, or change the API behavior, then we mention this in the docs and NEWS then. (?) Thanks, Siva Chandra PS: I used the namespace block as an example and called it a speculation. It probably is not a speculation but a real plan!