From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12081 invoked by alias); 17 Sep 2002 14:35:56 -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 12057 invoked from network); 17 Sep 2002 14:35:54 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 17 Sep 2002 14:35:54 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rKOJ-0003s4-00 for ; Tue, 17 Sep 2002 10:35:55 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rJSD-0007Qg-00 for ; Tue, 17 Sep 2002 10:35:53 -0400 Date: Tue, 17 Sep 2002 07:35:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part Message-ID: <20020917143553.GA28408@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00339.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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer