Re: [RFA] Re: [RFC][patch 1/9] initial Python support

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> 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