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  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

On 7 October 2010 23:39, Johan Fabry <[hidden email]> 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.






--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

On 07 Oct 2010, at 17:04, Igor Stasenko wrote:

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  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

On 8 October 2010 00:59, Johan Fabry <[hidden email]> wrote: 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



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

this is not beacuse self surgery is good when you cut your nails the morning in your bathroom
that operating your brain is not a stupid idea.

Stef


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

It depends on when you want to use that particular brain later to do real work or not ... :-P

On 08 Oct 2010, at 02:54, Stéphane Ducasse wrote:

--
Johan Fabry  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

> It depends on when you want to use that particular brain later to do real work or not ... :-P

;D
_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

So I was a bit annoyed about this behavior, because I still think it is a cool demo to show in class. So I had a poke around the system (Thanks Igor for pointing me in the right direction). What happens is that ImageMorph>>image: does at some point

super extent: 2 * self borderWidth + image extent.

where self borderWidth is an int. Now wait a minute, what does it mean, conceptually to sum an int with a point? I have no idea. So what are we doing here? Computing the extent considering the extra border size we have. So what we want to do is sum 2 points, now that does makes sense.

super extent: (2 * self borderWidth) asPoint + image extent.

With this fix, I can turn of coercion for Integers without any problem, fixing the original issue. Plus the behavior of ImageMorph>>image: is the same, as far as I can tell. Bonus: conceptually cleaner, more robust system, and the ability to do funky demos in class.

See, I can do brain surgery, just not at the same time as teaching :-)

(Marcus: this fix attached to the bug report, even though it is closed, just in case you consider it worthwhile ...)

On 08 Oct 2010, at 09:07, Stéphane Ducasse wrote:

>> It depends on when you want to use that particular brain later to do real work or not ... :-P
>
> ;D
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

--
Johan Fabry  
[hidden email] - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile




_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users