Re: repo to work on python scripting support

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

Daniel> No, I'm concerned about what the C-defined functions would include
Daniel> or call to interpret the details.  I don't want them including any
Daniel> of GDB's normal headers.

Gotcha, that makes sense to me.

Long-term compatibility in the Python API is something we haven't
discussed.  I'm really not sure what to do about this -- we really are
exposing a decent amount of gdb internals to the world this way.

>> print $(py do something in python)

Daniel> But what if there's quotes in there?  Or parentheses, or both?

Yeah.  They have to match and if gdb does any processing (I didn't
look into this), you have to know how to trick it.  Talk about
unsatisfactory...  OTOH double-quoting the python code is also a bit
yucky.  But, I suppose this will be a relatively unusual thing to want
to do.

I'll try to implement this soon.

So far my list of declarative argument "kinds" is:

* expression
* linespec (or whatever the thing that "break" takes is called)
* filename (do we need it?)

I was thinking that the declaration could be a tuple using named
constants; string elements in the tuple would be looked for
explicitly, like: (EXPRESSION "," EXPRESSION) would parse an
expression, a comma (ignoring whitespace around it), and another
expression.

I guess we need a syntax for optional arguments as well, perhaps just
a named 'OPTIONAL' constant in the tuple.

Maybe we could do the same kind of parsing for commands.

Tom