Ah, but now that I've put a
(selector == #unwindTo: and: [ self name = 'Context']) ifTrue:[self
halt: 'debug me'].
I can't reproduce the problem related to removal of Context methods!!!
Instead, I've got the 'Merging Kernel-eem.1078' window with all the
MethodContext->Context renaming in conflict
I already reported that in another thread where I told that the upgrade
went "smoothly" for both my 32 & 64 bits images.
I don't know if it's related to package cache, or .mcd, or ???
It might also be that package ancestry is not correct du to overwriting of
some packages, otherwise we should not get a merge window, but well...
Ah, but now I think I understand: it's just because I have pending changes
in Kernel due to the addition of halt: above (same for my images which
usually have some unpublished experiments).
We then trigger a merge rather than a load. And the merge sees conflict
probably because of broken ancestry (the GUID are not corresponding), but
once resolved manually, it processes smoothly without removing Context
methods...
I can't instrument code that easily... This will have to wait for another
time slot :(
2017-04-08 13:41 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com>:
>
>
> 2017-04-08 6:38 GMT+02:00 Ben Coman <b...@openinworld.com>:
>
>> I was going to slip this example into the welcome help,
>>
>> 1 printString [debugIt]
>>
>> and I'm confronted by SmallInteger>>printString
>>
>> printString
>> "Highly optimized version for base 10
>> and that we know it is a SmallInteger."
>> | integer next result len |
>> self = 0 ifTrue: [^'0'].
>> self < 0 ifTrue: [^'-', self negated printString].
>> len := self decimalDigitLength.
>> result := String new: len.
>> integer := self.
>> len to: 1 by: -1 do: [:i |
>> next := integer // 10.
>> result byteAt: i put: 48 + (integer - (next * 10)).
>> integer := next].
>> ^result
>>
>>
>> and I gather from other discussions this should(?) belong in
>> SmallInteger>>printOn:
>> Or is there a large benefit to avoiding the #printStringLimitedTo:
>> machinery ?
>>
>> cheers -ben
>>
>
> It should be printOn: generally, except that printOn: requires creating a
> Stream, and requires passing thru Stream indirection for writing into the
> target String.
>
> As the comment tells, the sole reason for this implementation is "Highly
> optimized version". So consider that it's an exception to the rules. Maybe
> this kind of decision could be periodically re-examined in the light of
> performance measurements (I'm thinking of Sista)?
>
