From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5255 invoked by alias); 17 Sep 2002 16:03:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5187 invoked from network); 17 Sep 2002 16:03:02 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 17 Sep 2002 16:03:02 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A768F3DAA; Tue, 17 Sep 2002 12:03:02 -0400 (EDT) Message-ID: <3D875236.3060100@ges.redhat.com> Date: Tue, 17 Sep 2002 09:03:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part References: <20020917143553.GA28408@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00341.txt.bz2 > On Mon, Sep 16, 2002 at 03:25:53PM -0700, David Carlton wrote: > >> This is the first of three patches that will begin the process of >> converting blocks to do variable lookup via dictionaries. (Which are >> what I'd been calling environments until Andrew noted that that >> clashed with the existing 'struct environ'.) >> >> The goal of these three patches it to make sure that all blocks that >> are created have a 'dict' member. Once these patches are applied, it >> will be possible to lookup variables either using the old methods >> (BLOCK_SYM, etc.) or using the new dictionary methods. Phase 2 will >> then convert all accessors over to using th new dictionary methods; >> phase 3 will get rid of the old methods so that the new dictionary >> methods get used exclusively. > > > David, > > I've only skimmed this, but it looks nice. I think that you should > take Andrew's suggestion, though - create a branch to finish this work > on. It's a bit of a hassle, since you'll need to do periodic merges to > the branch, but I don't feel right adding something with this many > temporary interfaces and FIXMEs to the trunk. Then you can commit > patches on the branch without approval, and get it into a stabler > state. It will still need a general thumbs up, but at least the maintainer will have the confidence of knowing that it really does work. cf the recent problem with ranges. Andrew