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