[Pharo-project] Collection new
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
On 30 January 2012 19:31, Andrew P. Black <black@cs.pdx.edu> wrote:
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
When an error occurs during error handling (which includes printing) it is not a clean failure. Emergency evaluator pops up in that case. -- Milan Mimica http://sparklet.sf.net
Hmm, is this really right? I'm used to seeing "Error in printString ..." On 30 Jan 2012, at 11:12 , Milan Mimica wrote:
On 30 January 2012 19:31, Andrew P. Black <black@cs.pdx.edu> wrote:
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
When an error occurs during error handling (which includes printing) it is not a clean failure. Emergency evaluator pops up in that case.
Go easy on the newbies, ok? :) We were all there once... It's been YEARS, but I recall being completely lost with collections and "which ones to use and how." You are indeed correct about non-newbs needing to make sure that any errors are gracefully presented vs. taking out the vm. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Andrew P. Black [black@cs.pdx.edu] Sent: Monday, January 30, 2012 1:31 PM To: Pharo Project Subject: [Pharo-project] Collection new 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
In general why is there not a catch all for Stack Overflow and infinite loops. 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
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
On Tue, Jan 31, 2012 at 3:40 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
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.
GemStone has a user variable for maximum stack depth (defaults to 10000 I think). The exception it raises is not so much a clever solution to the halting problem but it catches some human errors, which is nice.
On 31 January 2012 06:18, S Krish <krishnamachari.sudhakar@gmail.com> wrote:
In general why is there not a catch all for Stack Overflow and infinite loops.
In general, you just press Alt+., several times. -- Milan Mimica http://sparklet.sf.net
Does not work all the time in busy loops.. it continues with other debugger windows. Would love it if Alt . completely stops all other processing.. some kind of master interrupt... On 2/1/12, Milan Mimica <milan.mimica@gmail.com> wrote:
On 31 January 2012 06:18, S Krish <krishnamachari.sudhakar@gmail.com> wrote:
In general why is there not a catch all for Stack Overflow and infinite loops.
In general, you just press Alt+., several times.
-- Milan Mimica http://sparklet.sf.net
participants (6)
-
Andrew P. Black -
Eliot Miranda -
Milan Mimica -
S Krish -
Schwab,Wilhelm K -
Steve Wart