Focus3D / crunchy

Automatically exported from code.google.com/p/crunchy
0 stars 0 forks source link

Need to add a way to break from infinite loops #68

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The subject line says it all.  "Back in the old days", pre-comet, we
discussed this issue and Johannes found a way (link to a site) to stop a
thread using ctypes.  We should implement this, by adding a stop button
next to each interpreter.  We should also have a maximum running time for
each tread somehow.

Original issue reported on code.google.com by andre.ro...@gmail.com on 9 Dec 2007 at 3:52

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
broken test (comment 11) fixed.

Original comment by andre.ro...@gmail.com on 1 Jun 2008 at 3:20

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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