[Pharo-project] Bug in PharoCore1.1ALPHA [Latest update: #11192]
Henrik Sperre Johansen
henrik.s.johansen at veloxit.no
Thu Feb 4 15:34:08 EST 2010
On 04.02.2010 21:11, Stéphane Ducasse wrote:
> Nicolas nicely answered to the problem
> Thanks a lot.
> Comment 1 by nicolas.cellier.aka.nice, Today (10 hours ago)
> I tested with this:
> (TextConverter allSubclasses reject: [:e | e subclasses size> 0])
> select: [:e | (e latin1Encodings copyFrom: 129 to: 256) anySatisfy: [:e2 | e2 isNil]]
> -> a Set(MacRomanTextConverter Latin1TextConverter)
> Then this:
> (TextConverter allSubclasses reject: [:e | e subclasses size> 0]) collect: [:e | e
> ->((129 to: 256) select: [:e2 | (e latin1Encodings at: e2) isNil])]
> -> MacRomanTextConverter->#(163 164 170 178 182)
> -> Latin1TextConverter-> (129 to: 256)
> All problems disappear if I do this:
> Latin1TextConverter initializeLatin1Encodings.
> MacRomanTextConverter initializeLatin1Encodings.
> Don't know why something went wrong with lazy initialization leading to a class
> instance variables notNil, but not initialized correctly...
> Maybe the #initializeLatin1Encodings should be called in each text converter class
> I will integrate that soon :)
That is strange...
Classes were recompiled when I changed the method name from
initializeLatin1MapAndEncodings to initializeLatin1Encodings, and
removed the latin1Map (Now called nonAsciiMap, residing in ByteString.
If there's a better suggestion of where to put it, please speak up).
Not sure how the reinitialization could have failed though, especially
seeing how calling them again works :/
More information about the Pharo-dev