Hard crash when teaching
Always fun when you want to show the students that everything can be changed in Smalltalk ... Inclusive the behavior of Integer>>+ Inclusive when the current behavior does strange things with the second argument when it is not a number (instead of simply throwing an error), e.g what happens in 1 + 'foo' Inclusive when you are debugging said expression. Apparantly that was too much to ask :-( Hard crash of the image :-( :-( Reported as issue http://code.google.com/p/pharo/issues/detail?id=3072 -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
On 7 October 2010 23:39, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Always fun when you want to show the students that everything can be changed in Smalltalk ... Inclusive the behavior of Integer>>+ Inclusive when the current behavior does strange things with the second argument when it is not a number (instead of simply throwing an error), e.g what happens in 1 + 'foo' Inclusive when you are debugging said expression.
Apparantly that was too much to ask :-( Hard crash of the image :-( :-(
Reported as issue http://code.google.com/p/pharo/issues/detail?id=3072
its not very good idea to replace ^ aNumber adaptToInteger: self andSend: #+ with ^ self error: 'boo' because many parts of system relies on 'silent' type coercion. I didn't experienced the hard crash in pharo image. What i got instead, is an error, printed in emergency console saying that it unable to handle the system error .. the culprit is in ImageMorph>>image: while somehow relying on correct behavior of Integer>>+ and ImageMorph obviously used by Morphic rendering. So, its not crashing. Image is still responsible. You just broken UI with it: a toolbuilder, when creating a new Error popup window, also creates and initializing an ImageMorph as a submorph. And since it fails with error, the error-handling layer treats this as failure to handle error and thus, it switching to emergency console. Btw, there was a good chances, that even an emergency console could be broken because of such change.
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-- Best regards, Igor Stasenko AKA sig.
On 07 Oct 2010, at 17:04, Igor Stasenko wrote:
On 7 October 2010 23:39, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Always fun when you want to show the students that everything can be changed in Smalltalk ... Inclusive the behavior of Integer>>+ Inclusive when the current behavior does strange things with the second argument when it is not a number (instead of simply throwing an error), e.g what happens in 1 + 'foo' Inclusive when you are debugging said expression.
Apparantly that was too much to ask :-( Hard crash of the image :-( :-(
Reported as issue http://code.google.com/p/pharo/issues/detail?id=3072
its not very good idea to replace ^ aNumber adaptToInteger: self andSend: #+
with ^ self error: 'boo'
because many parts of system relies on 'silent' type coercion.
Well, I was not going to use the image for anything else after that ;-)
I didn't experienced the hard crash in pharo image. What i got instead, is an error, printed in emergency console
saying that it unable to handle the system error ..
Ok I guess that my concept of a hard crash is a bit softer than yours.
the culprit is in ImageMorph>>image: while somehow relying on correct behavior of Integer>>+
The question is why is laying out doing this with non-integers? Screens work with pixels so I did not expect that. You are right that I had to have thought about coercion of others, but I did not expect that to happen at that point... Next time I will be more careful ... -- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
On 8 October 2010 00:59, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
On 07 Oct 2010, at 17:04, Igor Stasenko wrote:
On 7 October 2010 23:39, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Always fun when you want to show the students that everything can be changed in Smalltalk ... Inclusive the behavior of Integer>>+ Inclusive when the current behavior does strange things with the second argument when it is not a number (instead of simply throwing an error), e.g what happens in 1 + 'foo' Inclusive when you are debugging said expression.
Apparantly that was too much to ask :-( Hard crash of the image :-( :-(
Reported as issue http://code.google.com/p/pharo/issues/detail?id=3072
its not very good idea to replace ^ aNumber adaptToInteger: self andSend: #+
with ^ self error: 'boo'
because many parts of system relies on 'silent' type coercion.
Well, I was not going to use the image for anything else after that ;-)
I didn't experienced the hard crash in pharo image. What i got instead, is an error, printed in emergency console
saying that it unable to handle the system error ..
Ok I guess that my concept of a hard crash is a bit softer than yours.
the culprit is in ImageMorph>>image: while somehow relying on correct behavior of Integer>>+
The question is why is laying out doing this with non-integers? Screens work with pixels so I did not expect that. You are right that I had to have thought about coercion of others, but I did not expect that to happen at that point... Next time I will be more careful ...
Its a good question why its there. But of course, i wouldn't never expect from system to keep working stable & normally, when you changing something as basic as Integer>>+. But there is a bright side: such things could be used to detect low-quality code (or code, which intentionally doing coercions ;)... For instance, i often type: 100/200 if you evaluate that, you'll get a Fraction as result: (1/2) but i want the answer to be Float, so i type: 100/200 asFloat and here, when you change the Integer>>#/ to throw error instead of coercing receiver, i won't be able to use it anymore, and will be forced to write: 100 asFloat / 200 asFloat
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-- Best regards, Igor Stasenko AKA sig.
participants (2)
-
Igor Stasenko -
Johan Fabry