* [RFC][0/5] Python event handling
@ 2009-08-23 15:34 Oguz Kayral
2009-09-21 21:17 ` Tom Tromey
2009-09-24 1:52 ` Richard Ward
0 siblings, 2 replies; 3+ messages in thread
From: Oguz Kayral @ 2009-08-23 15:34 UTC (permalink / raw)
To: archer
Hi,
This patch series adds inferior event handling support to GDB Python
scripting. The work is based on archer-tromey-python branch.
An example gdb session:
gsoc-gdb/install/bin/gdb ./simple
GNU gdb (GDB) 6.8.50.20090717-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) require command check_segfault
(gdb) start
Temporary breakpoint 1 at 0x80483a5: file simple.c, line 7.
Starting program: /home/oguz/simple
Temporary breakpoint 1, main () at simple.c:7
7 *p = simple();
(gdb) check_segfault
SIGSEGV handler registered.
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x080483af in main () at simple.c:7
7 *p = simple();
event type : stop
stop reason: signal
stop signal: SIGSEGV
#0 0x080483af in main () at simple.c:7
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC][0/5] Python event handling
2009-08-23 15:34 [RFC][0/5] Python event handling Oguz Kayral
@ 2009-09-21 21:17 ` Tom Tromey
2009-09-24 1:52 ` Richard Ward
1 sibling, 0 replies; 3+ messages in thread
From: Tom Tromey @ 2009-09-21 21:17 UTC (permalink / raw)
To: Oguz Kayral; +Cc: archer
>>>>> "Oguz" == Oguz Kayral <oguzkayral@gmail.com> writes:
Oguz> This patch series adds inferior event handling support to GDB Python
Oguz> scripting. The work is based on archer-tromey-python branch.
Hi Oguz.
I'm sorry about the long delay in my response here. I spent most of
August on another part of the Python interface and didn't have much time
left over.
I have a few comments on the patches. I will reply to the patches
needing comment.
One bigger thing, not specific to any particular patch, is that we like
to have documentation for all new Python APIs.
Tom
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC][0/5] Python event handling
2009-08-23 15:34 [RFC][0/5] Python event handling Oguz Kayral
2009-09-21 21:17 ` Tom Tromey
@ 2009-09-24 1:52 ` Richard Ward
1 sibling, 0 replies; 3+ messages in thread
From: Richard Ward @ 2009-09-24 1:52 UTC (permalink / raw)
To: Oguz Kayral; +Cc: archer
Oguz Kayral wrote:
> Hi,
> This patch series adds inferior event handling support to GDB Python
> scripting.
Hi Oguz, I've been looking forward to this functionality, Good stuff!
I have a few comments though, if you don't mind.
Firstly two (fairly unimportant) things about the function registration.
I think it would be nice if you could give upvalues to the registration
function (similar to gobject's `connect'), though admittedly it is very
easy to fake that in python using a class that defines __call__.
Also, I'm not sure whether this would ever be an issue but it seems
advantageous to have the registration function return a unique object or
number that could subsequently be used to unregister your callable,
rather than using the callable object itself.
Next, in python-stopevent.c:
emit_stop_event (struct bpstats *bs, const char *stop_signal)
{
/*...snip...*/
for (i = 0; i < PyList_Size (callback_list); i++)
{
PyObject_CallObject (PyList_GET_ITEM (callback_list, i), args_tuple);
}
}
A couple of issues with this. First, PyObject_Callback returns a new
reference which is the return value of the function (or NULL), so it
must be handled otherwise it will leak.
Secondly the user code may throw an exception, or the object may not be
callable. The exception should be cleared, and it would be nice to also
print the exception (PyErr_Print does both).
Most important here though is the iteration through the list. If the
user disconnects a callback from inside a callback then the some
callbacks could be skipped. It could be better to copy the list first,
but that could still lead to some confusing behaviour, for example a
callback being called after the user thinks it ought to have been
disconnected.
Thanks,
Richard
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-09-24 1:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-23 15:34 [RFC][0/5] Python event handling Oguz Kayral
2009-09-21 21:17 ` Tom Tromey
2009-09-24 1:52 ` Richard Ward
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).