From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9968 invoked by alias); 9 Feb 2009 13:05:30 -0000 Received: (qmail 9957 invoked by uid 22791); 9 Feb 2009 13:05:29 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f18.google.com (HELO mail-fx0-f18.google.com) (209.85.220.18) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Feb 2009 13:05:22 +0000 Received: by fxm11 with SMTP id 11so2699153fxm.0 for ; Mon, 09 Feb 2009 05:05:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.175.8 with SMTP id c8mr2090014mup.117.1234184719579; Mon, 09 Feb 2009 05:05:19 -0800 (PST) In-Reply-To: References: <3d6b0edb0902070607x29177016m48a40bd198b88f7e@mail.gmail.com> Date: Mon, 09 Feb 2009 13:05:00 -0000 Message-ID: <3d6b0edb0902090505m6bcb142crab53b0f860535ff4@mail.gmail.com> Subject: Re: New language support : Vala From: Abderrahim KITOUNI To: tromey@redhat.com Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: 2009-02/txt/msg00204.txt.bz2 2009/2/7 Tom Tromey : > I took a quick look through the patch and there are definitely things > in there that won't apply today. So, I suggest updating to CVS gdb > and resubmitting. I'll try to do it. > > Also, I noticed a fair amount of code not conforming to GNU standards > -- missing spaces, spaces in the wrong places, comments that are not > full sentences; IOW, the usual sorts of nits. This will all come up > in any eventual review, so I'd recommend taking a stab at fixing these > beforehand. I'll try to see (I thought it was ok). > > Any new file needs a copyright header. I didn't know what to put in, I've sent it for a preliminary review. > > All new functions ought to have an introductory comment explaining > their purpose, arguments, and return value. ok > > For the stack.c change, I suggest a new language function that returns > true if the symbol ought to be printed. Other languages can always > return 1. I just didn't want to do big changes. > > I'm also not so sure about the valops.c change or the gdbtypes.c > change. In general I think explicit checks of the current language > ought to be avoided in generic code. OK, I'll try to put these in separate changes (eventually adding functions to language definitions) > > I wonder whether some of this is better done in Python. For instance, > perhaps specialized value-printing stuff could be done using a Python > pretty-printer. (This code isn't in gdb CVS yet, but is coming > soon... and you can use it today by checking out from Archer.) My > thinking here is that this might benefit all glib users, not just > Vala. But this is just an idea, I won't insist on it. Maybe. > > Alternatively, I wonder whether some of the generic changes could be > made unnecessary by having a real Vala parser. I don't think so, but I'll try to minimize them. I'll try to break the patch up into several little patches, that will ease reviewing. Regards, Abderrahim