Hmm forget about this, wrong thread... 2017-04-08 13:58 GMT+02:00 Nicolas Cellier < [email protected]>:
> 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.nice@ > gmail.com>: > >> >> >> 2017-04-08 6:38 GMT+02:00 Ben Coman <[email protected]>: >> >>> 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)? >> > >
