Re: [RFA][patch 1/9] Yet another respin of the patch with initial Python support

[Eli Zaretskii <eliz@gnu.org>]

> Cc: bauerman@br.ibm.com, gdb-patches@sourceware.org
> From: Tom Tromey <tromey@redhat.com>
> Date: Sat, 26 Jul 2008 12:44:33 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The "define" command creates new user-defined commands, which are
> >> sequences of gdb commands.
> >> 
> >> The python command accesses the python interpreter.  It is not really
> >> useful unless you already know python and want to use gdb's python
> >> api.  So, it has a much narrower audience.
> 
> Eli> But the goal is the same: create user-defined commands, isn't it?  Or
> Eli> is there something else?
> 
> There's a distinction to be aware of here ... what we have and what is
> planned are not identical.

I was talking about what was planned.

> For instance, you will be able to write new "gdb-side" functions in
> Python; this is related to exprsseion evaluation, not new commands.

Sorry, I don't understand.  Can you give an example, please?

> And, you will be able to script gdb in any number of ways.

What do you mean by "script gdb"?

> Some of the immediate things will not be visible as user commands.
> For example, pretty-printing will not be exposed that way.  It will be
> part of the "print" command (or just automatic in the MI case).

If it's automatic, it's part of GDB and there's no need to mention it
in the manual.  For non-MI cases, are you talking about some kind of
hooks into which user-defined Python code can be plugged to modify how
certain objects are printed?

> However, library authors and the like will be able to write new
> pretty-printers

How will those pretty-printers be invoked by GDB?

> Long term I want to make it possible to fully script gdb.  In
> particular I want to be able to start a python script with
> "#!/usr/bin/gdb" and have it completely control execution.

For what purpose?

Bottom line, unless I'm again missing something, we are talking about
extending GDB.  CLI scripting is also a way of extending GDB, albeit
very limited one.  So I still think having these two in the same
chapter is OK.