On Mon, Jan 30, 2012 at 9:18 PM, S Krish <krishnamachari.sudhakar@gmail.com>wrote:
In general why is there not a catch all for Stack Overflow and infinite loops.
There is, low space (and user interrupt for flat infinite loops). But the low space interrupt machinery is easily broken. It is difficult to test, and an increasingly silly approach on modern machines with huge amounts of memory. We need to think again.
Thats very annoying for newbie.. and infact gives a bad feel to using Pharo. The image they are working for say 3-4 hours and the crash just pushes them out of all the code they are working on with.. small as it maybe..
Recover / and other options are fallbacks but invariably newbies have it messed up and are not very clear on how to recover either .. thats a job for the experienced user actually...
This occurs so often from all of the polling code.. and if anyone unknowingly puts in a debug point in the methods that loop infinitely.. and so many of them lurk all around the image..
Just stop the loop and throw up a debugger if say 100 calls have gone to very same method..? or detect a clear loopback to the same method..
On Tue, Jan 31, 2012 at 12:01 AM, Andrew P. Black <black@cs.pdx.edu>wrote:
Teaching a class of novices, it's not surprising that someone tried "Collection new". What was surprising is that this got the VM is a loop of some kind, with emergency stack dumps and so on.
Here is my reply:
On 30 Jan 2012, at 01:18 , Xingzhi Harry Pan wrote:
...it's pretty innocent: Collection new
OK. I looked at this. The problem comes when trying to print the collection. Somehow the VM gets confused when trying to do do: ... I'm not quite clear why.
The quick fix is to change the Collection>>new method to
self error: 'Collection is an abstract class, and cannot be instantiated'
However this will break Heap>>new: , which sends super new. It ought to send self basicNew instead.
These two changes seem to avoid the problem, but I'm waiting to see ...
Andrew
But I don't understand the root cause. Printing eventually sends do:, which is self subclassResponsibility. Why don't we get a clean failure?
Andrew
-- best, Eliot