Zitat von Daniel Jacobowitz <drow@false.org>:
> Looks generally good.

Good, I'm generally happy then. :-)

> For the general syntax: Should we allow $() to always mean Python, or
> are there other useful potential scripting interfaces or environment
> variable access or anything, in which case we want $(python ) or $(P )
> or $python( )?  There are only so many nice grouping specifiers.  $<>
> is not so good but we still have $[] and ${}, plus $env().  I don't
> remember if we discussed this before, but we may have.

This discussion is still being carried out. In the interest of having
at least the very basic committed soon, I removed support for Python
evalution inside expressions for this patch. This is now in a separate
patch in the python-patches branch. There, you will also find another
patch which Tromey is developing implementing his other proposal
(i.e., registering functions and then using $(func args) syntax).

The downside is that this patch adds near zero value to the user.
But all other patches build on this one.

> We've discussed already the configure options - I'd prefer to avoid
> this issue and only have --with-python and maybe
> --with-python-lib/--with-python-include.  Parallel to the top level
> gmp/mpfr handling, for instance.

This patch now sports the shiny new --with-python code brought to you
by Doug Evans.

> I didn't know about python-config.  Is that new?  Could we specify a
> path to python-config instead of messing with cflags/ldflags directly?

Yes we could, but I didn't experiment with the idea...

> And we sorted this out on IRC.

Hooray for IRC. :-)

> The special_processing argument to read_next_line / read_command_lines
> is not commented and the name doesn't say much of anything about what
> it's for.  It looks like this changes the behavior of document versus
> define, probably deliberately if it does what I think it does.  So
> this would be a good patch to split out separately.  In general, any
> bits that can go in separately should; it makes the whole pile easier
> to manage :-)

You are right, I didn't know why these changes were there as well but at
the time I kept them in the patch anyway. They seem to be useful only to
varobj/MI Python bindings by Vladimir, and I separated them in another
patch (found in the python-patches branch).

> There are too many #ifdef's in the rest of GDB in this patch, IMO.
> Can python/python.h be included unconditionally, not include
> python-internal.h, and have the exposed interfaces error() when Python
> support is not compiled in?  That's the approach I took for
> xml-support.h.
>
> Similarly we should recognize python_control regardless of
> HAVE_PYTHON.  That way we can parse a .gdbinit which defines Python
> commands and give a sensible error only if they are invoked.

Done, courtesy of Tom Tromey.

> In general I would prefer we not commit any FIXMEs.  We can decide now
> what the right thing to do is and if there is room for future
> enhancement, that's not a FIXME any more :-)

All FIXMEs in this patch are now gone (also by Tromey).

> > +
> > +void
> > +eval_python_from_control_command (struct command_line *cmd)
> > +{
> > +  char *script;
> > +
> > +  if (cmd->body_count != 1)
> > +    error (_("Invalid \"python\" block structure."));
> > +
> > +  demand_python ();
> > +
> > +  script = compute_python_string (cmd->body_list[0]);
> > +  PyRun_SimpleString (script);
> > +  xfree (script);
> > +  if (PyErr_Occurred ())
> > +    {
> > +      PyErr_Print ();
> > +      error ("error while executing Python code");
> > +    }
> > +}
>
> _() around arguments to error.  Also, in general PyErr_Print is
> probably dumping to stderr?  Output should go through GDB's error
> mechanisms, and in this case probably be part of the argument to
> error.  Can you get it to return an error string instead?

This is stillpending, I think.

> > +static PyObject *
> > +execute_gdb_command (PyObject *self, PyObject *args)
> > +{
> > +  struct cmd_list_element *alias, *prefix, *cmd;
> > +  char *arg, *newarg;
> > +  volatile struct gdb_exception except;
> > +
> > +  if (! PyArg_ParseTuple (args, "s", &arg))
> > +    return NULL;
> > +
> > +  TRY_CATCH (except, RETURN_MASK_ALL)
> > +    {
> > +      execute_command (arg, 0);
> > +    }
> > +  GDB_PY_HANDLE_EXCEPTION (except);
> > +
> > +  /* gdbtk does bpstat_do_actions here... */
>
> Please figure out if we need to or not.  It looks like we do; running
> the command "continue" to a breakpoint with actions will test it.

I don't know much about bpstat_do_actions, and didn't do the experiment
you mention (not sure I understood it), so I made a crude try at adding
a call to bpstat_do_actions just to get this patch out.

> Speaking of which... a testsuite? :-)

Next in my list!
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center