Closed GoogleCodeExporter closed 8 years ago
Just as a note, this should be dead easy on silverlight - there is a
Thread.Abort()
method :)
Original comment by johannes...@gmail.com
on 8 Apr 2008 at 1:51
We might be able to implement a weak version of this via a stop button that
would
send a KeyboardInterrupt.
Original comment by andre.ro...@gmail.com
on 15 Apr 2008 at 11:38
We just have to make sure the KeyboardInterrupt is raised in the correct thread
-
easy in 2.5 using CTypes - but not in earlier versions.
see http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496960 - this uses
SystemExit exceptions instead of KeyboardInterrupts.
Original comment by johannes...@gmail.com
on 15 Apr 2008 at 5:10
Should this be in 1.0? (I think yes, marking as such).
Original comment by johannes...@gmail.com
on 31 May 2008 at 12:24
I'm taking this over, it will give me something to do that isn't revision.
Original comment by johannes...@gmail.com
on 31 May 2008 at 4:51
An initial implementation is in revision 701. This needs to be refined (hiding
the
button when no code is being executed and so on).
I am not sure whether we should send SystemExit or KeyboardInterrupt - although
using
the latter would mean we could extend the idea to interpreters and make it part
of
the output widget.
Original comment by johannes...@gmail.com
on 31 May 2008 at 5:44
From comment above:
===
An initial implementation is in revision 701. This needs to be refined (hiding
the
button when no code is being executed and so on).
I am not sure whether we should send SystemExit or KeyboardInterrupt - although
using
the latter would mean we could extend the idea to interpreters and make it part
of
the output widget.
===
This is very nice!
I suggest to use an image (perhaps the "display_big.png", or a stop sign icon)
instead of text on the button.
Regarding the second comment, without looking in detail at the code, I would
suggest
passing a parameter, something like
kill_whatever(uid, signal="SystemExit")
and pass a KeyboardInterrupt from an interpreter.
Original comment by andre.ro...@gmail.com
on 31 May 2008 at 7:37
Revision 702 now has a test page and uses KeyboardInterrupt. Also the button is
part
of the IO widget. Now we just need to finalise the look of the thing.
I like the stop sign icon idea. Should the relevant link/button be at the top
or the
bottom of the output area? (I'm thinking top, because runaway loops can easily
generate a lot of output very quickly).
Original comment by johannes...@gmail.com
on 31 May 2008 at 11:36
I agree 100% with having the link/button at the top - exactly for the reason
given.
Nice work!
Original comment by andre.ro...@gmail.com
on 1 Jun 2008 at 12:59
[deleted comment]
test_io_widget.rst is broken as a result of this work. Will fix soon.
Original comment by andre.ro...@gmail.com
on 1 Jun 2008 at 2:45
broken test (comment 11) fixed.
Original comment by andre.ro...@gmail.com
on 1 Jun 2008 at 3:20
I believe the implementation is now complete... Waiting for comment before
changing
status.
Original comment by andre.ro...@gmail.com
on 1 Jun 2008 at 9:16
I still want to make it more visually appealing - although maybe that comes
under
issue 109. I will mark this as completed for now ad make a note in the comments
for
issue 109.
Original comment by johannes...@gmail.com
on 1 Jun 2008 at 9:40
Changing status back to active again. Crunchy works fine with Python 2.4;
however,
ctypes is not included in Python 2.4 and the kill_thread mechanism does not
work.
We need to set a flag that would prevent the kill thread link to appear if
ctypes is
not available - as well as a message to the user when starting Crunchy saying
that
this feature is not available.
Original comment by andre.ro...@gmail.com
on 2 Jun 2008 at 12:50
Fixed (except for a message to the user - replaced by a note on the starting
page) in
revision 713 (which uses a kludge ...)
Original comment by andre.ro...@gmail.com
on 2 Jun 2008 at 1:35
Original issue reported on code.google.com by
andre.ro...@gmail.com
on 9 Dec 2007 at 3:52