[squeak-dev] The Trunk: System-ul.253.mcz

Levente Uzonyi leves at elte.hu
Tue Feb 16 19:47:55 UTC 2010


On Tue, 16 Feb 2010, Juan Vuletich wrote:

> Levente Uzonyi wrote:
>> On Tue, 16 Feb 2010, Juan Vuletich wrote:
>> 
>>> commits at source.squeak.org wrote:
>>>> Levente Uzonyi uploaded a new version of System to project The Trunk:
>>>> http://source.squeak.org/trunk/System-ul.253.mcz
>>>> 
>>>> ==================== Summary ====================
>>>> 
>>>> Name: System-ul.253
>>>> Author: ul
>>>> Time: 14 February 2010, 9:12:11.268 am
>>>> UUID: 7aaed65b-d0e3-0040-8929-0eb0bf8ecf64
>>>> Ancestors: System-ar.252
>>>> 
>>>> - fix (again): Timer may be already nil in the #ensure: block in 
>>>> MessageTally >> #spyEvery:on: and MessageTally >> #spyAllEvery:on:
>>>> 
>>> 
>>> Hi Levente,
>>> 
>>> How could that happen? Can you post a script to reproduce it?
>> 
>> Well, the old way to reproduce this is fixed (press alt/cmd+. while 
>> profiling) and that's great. But there's another one, it happens when 
>> you're tallying something which tallies something else. I know this 
>> shouldn't happen normally, but we have some tests which use MessageTally 
>> (for no reason). If you press the "Run Profiled" button in TestRunner, 
>> these tests will set Timer's value to nil and at the end, you get a 
>> debugger.
>> 
>> 
>> Levente
>
> Thanks, I see. Anyway, nested tallies are not working at all (and never 
> worked). Your fix might give the impression that nested tallies are ok, when 
> they are not. Perhaps it would be best to just raise an error.

I agree that it's not the best solution and it shadows an issue. We could 
just fix the tests and revert the code. But I think that changing the 
value of a class variable from instance methods is a sign of bad design. 
Why is MessageTally using the class variable Timer instead of an instance 
variable?


Levente

P.S.:
I added a new instance variable timer to MessageTally, replaced 
all occurence of Timer to timer, removed the #ifNotNil: checks and 
successfully profiled the tests. Is anything wrong with this approach?

>
> Cheers,
> Juan Vuletich
>
>



More information about the Squeak-dev mailing list