From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7739 invoked by alias); 18 Jul 2008 23:24:59 -0000 Received: (qmail 7728 invoked by uid 22791); 18 Jul 2008 23:24:58 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 23:24:41 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6INOa3t011763; Fri, 18 Jul 2008 19:24:37 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6INOawE007969; Fri, 18 Jul 2008 19:24:36 -0400 Received: from opsy.redhat.com (vpn-10-33.bos.redhat.com [10.16.10.33]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6INOZA4013964; Fri, 18 Jul 2008 19:24:36 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 314125086F9; Fri, 18 Jul 2008 17:24:30 -0600 (MDT) To: Thiago Jung Bauermann Cc: gdb-patches ml Subject: Re: [RFA] Re: [RFC][patch 1/9] initial Python support References: <20080429155212.444237503@br.ibm.com> <20080429155304.288626880@br.ibm.com> <20080528205921.GA2969@caradoc.them.org> <20080615181833.uxmo25mg0kko40kw@imap.linux.ibm.com> <1216107418.14956.27.camel@localhost.localdomain> <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Fri, 18 Jul 2008 23:24:00 -0000 In-Reply-To: <20080718195010.GA14356@caradoc.them.org> (Daniel Jacobowitz's message of "Fri\, 18 Jul 2008 15\:50\:10 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (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: 2008-07/txt/msg00372.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Just a quick note to comment on a couple things in the review. Daniel> Also, perhaps this should use a prefix command, like "set python Daniel> print-stack"? No problem. Daniel> There should probably be an explicit table item for the "python" Daniel> command, too. I saw tables elsewhere but it seemed odd to have one with just a single entry. No big deal, though, I'll do it. >> +#undef _POSIX_C_SOURCE Daniel> Odd. For me, pyconfig.h and features.h define it to the same thing. Daniel> Anyway, this is gross but acceptable. I think Doug had a case where this was needed. >> + { "write", gdbpy_write, METH_VARARGS, >> + "Write a string using gdb's filtered stream." }, >> + { "flush", gdbpy_flush, METH_NOARGS, >> + "Flush gdb's filtered stdout stream." }, Daniel> I think that these are now "gdb commands", effectively. So, sorry, Daniel> but there's a bit more documentation you get to write :-) No new Daniel> undocumented public interfaces. So, you mean, document the Python API in the manual? Or more info in the doc strings here? (I assume the former.) >> + PyRun_SimpleString ("\ >> +import sys\n\ >> +class GdbOutputFile:\n\ [...] Daniel> This is OK for now, but it is likely to grow. There's code to convert Daniel> a text file into a C string, in features/ (used for XML files); maybe Daniel> we should internalize a couple of Python source files that way? Daniel> Alternatively we could install Python source files to a known path in Daniel> the build / install directories; that lets vendors precompile the Daniel> files for faster startup. Daniel> Anyway, that's a future note, not a current problem. Just to be clear, I have thought about this, and I think we will want a library of Python code that is distributed with gdb and installed by 'make install'. However, I think this particular snippet should remain in the source (or be compiled in -- I don't care either way about that). My reasoning is that it would be nice, if at all possible, if gdb would still properly start up even if someone deleted the python library by mistake. So, truly critical python code should just be included directly; but at the same time the amount of critical code should be kept to a minimum. Tom