From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7967 invoked by alias); 4 Feb 2009 20:02:35 -0000 Received: (qmail 6856 invoked by uid 22791); 4 Feb 2009 20:02:21 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Feb 2009 20:02:16 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n14K2Cne003291; Wed, 4 Feb 2009 15:02:12 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n14K2CeS021364; Wed, 4 Feb 2009 15:02:12 -0500 Received: from opsy.redhat.com (vpn-14-42.rdu.redhat.com [10.11.14.42]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n14K2BoA031828; Wed, 4 Feb 2009 15:02:12 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id CB45F3785DA; Wed, 4 Feb 2009 13:02:09 -0700 (MST) To: Thiago Jung Bauermann Cc: gdb-patches ml Subject: Re: [RFC][python] Add support for commands implemented in Python References: <1233580405.7000.13.camel@localhost.localdomain> <20090204003153.GA26840@caradoc.them.org> From: Tom Tromey Reply-To: tromey@redhat.com Date: Wed, 04 Feb 2009 20:02:00 -0000 In-Reply-To: <20090204003153.GA26840@caradoc.them.org> (Daniel Jacobowitz's message of "Tue\, 3 Feb 2009 19\:31\:53 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00104.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: >> +@var{argument} is the argument to the command. The argument >> +ordinarily is a string, but may be @code{None}, meaning that there was >> +no argument. Daniel> Any opinion on making it always a string? The 'do I get NULL Daniel> or an empty string?' ambiguity shows up every time I write a Daniel> new command in C. An empty string would be fine by me. I initially chose None to parallel the C API, but it isn't clear how useful that is. An empty string is friendlier and doesn't seem to lose anything important. >> + /* For a prefix command, this is the list of sub-commands. */ >> + struct cmd_list_element *sub_list; Daniel> What's sub_list for? There's *command->prefixlist too. Overall, I'm Daniel> confused about why prefix commands are 'special' here. When core GDB Daniel> adds a command, it doesn't need any new code to handle it as a prefix; Daniel> just calls add_prefix_cmd. I'd expect to do the same here but fill in Daniel> a local FUN. I might be confused here. The reason I wrote things this way is because elsewhere in gdb there are global cmdlists which are passed by address to the various add_* functions. The 'prefixlist' field of the prefix command points to one of these globals. E.g.: in breakpoint.c, there is a global breakpoint_set_cmdlist. The "set breakpoint" prefix command is constructed: add_prefix_cmd ("breakpoint", class_maintenance, set_breakpoint_cmd, _("\ Breakpoint specific settings\n\ Configure various breakpoint-specific variables such as\n\ pending breakpoint behavior"), &breakpoint_set_cmdlist, "set breakpoint ", 0/*allow-unknown*/, &setlist); ... this sets the new prefix command's prefixlist to &breakpoint_set_cmdlist. Then, calls to add_* to create sub-commands of this prefix are given &breakpoint_set_cmdlist as an argument. So, the idea behind this part of the patch is that we need to create storage for this list somewhere. In the rest of gdb this is done as a global, but that won't fly here -- so we allocate it in the Command. Does that answer your question? Or, if I'm misunderstanding something, could you say what? I looked at this again and I still don't see what might be wrong. Daniel> Yes, alias and user are special. User is where "define"'d commands Daniel> go; should there be a command to show all Python-defined Daniel> commands similar to "show user"? As a user I don't really care if a command is implemented in Python. But I don't oppose the idea if you think it is useful. Tom