Hard crash when teaching

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Hard crash when teaching

jfabry
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
Reply | Threaded
Open this post in threaded view
|

Re: Hard crash when teaching

Igor Stasenko
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.




> --
> 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
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Hard crash when teaching

jfabry

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

> 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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Hard crash when teaching

Igor Stasenko
On 8 October 2010 00:59, Johan Fabry <[hidden email]> wrote:

>
> On 07 Oct 2010, at 17:04, Igor Stasenko wrote:
>
>> 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.
>
> 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
> [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
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Hard crash when teaching

Stéphane Ducasse
In reply to this post by jfabry
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

> 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


_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
Reply | Threaded
Open this post in threaded view
|

Re: Hard crash when teaching

jfabry

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:

> 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
>
>> 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
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Hard crash when teaching

Stéphane Ducasse
In reply to this post by Stéphane Ducasse
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Hard crash when teaching

jfabry
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