repo to work on python scripting support

[Daniel Jacobowitz]

On Wed, Mar 26, 2008 at 10:28:53AM -0700, Doug Evans wrote:
> On Mon, Mar 24, 2008 at 10:32 PM, Tom Tromey <tromey@redhat.com> wrote:
> >  I've been thinking... maybe we do want $(...) to allow things other
> >  than Python commands.  Or, more precisely, maybe we want to let Python
> >  code register a function by name for use in $(...).  The Python
> >  function would get the uninterpreted string argument for processing.
> 
> OOC, Would there be an intent to not disallow dynamically loaded C/C++
> instead of Python for $(foo)? [Emphasis on OOC.]

My plan on this, to date, has been to insist on use of the Python
interface for marshalling and unmarshalling.  This keeps the interface
explicit.  Of course, Python can load C modules itself and there'd be
nothing to stop that if you needed to do e.g. some more intensive
computation in the C side; and with a little forethought we could
probably keep likely bulky operations (like memory reading) as
zero-copy.

> Parsing two separate languages in one line is problematic too (I'm not
> sure how far the Pythonic version was intended to be interpreted).

Yes, I think we'll not want to allow raw Python in most GDB
expressions; if it's useful in a convenience expression the
outer layer of quoting should probably belong to GDB.

print $(py "this is a python \"program\"")

-- 
Daniel Jacobowitz
CodeSourcery