I think either we must rehash collections when they are unpacked from
a stream or we must not do lookups on such collections if they come
from a stream. HashedCollection>>comeFullyUpOnReload: compacts the
collection, but that does not rehash it if the size of the array is
still correct. The previous version of loadPreferencesFrom: used
keysAndValuesDo:, which does not need to do lookups.


Am Mo., 27. Dez. 2021 um 01:14 Uhr schrieb tim Rowledge <tim at rowledge.org>:
>
> This is admittedly an older preferences file, and I could certainly just re-make it. BUT since it does break a rather useful facility let's at least record the problem.
>
> In the Preferences class>>#loadPreferencesFrom: method as of mt 11/22/2021 the loading fails because the IdentityDictionary loaded seems to get very unhappy in the reject:thenDo: process.
> The relevant code is -
>
>         dict keys
>                 reject: [:key | patternsToIgnore anySatisfy: [:pattern | pattern match: key]]
>                 thenDo: [:key | | value |
>                         value := dict at: key.
>                         (self preferenceAt: key ifAbsent: [nil]) ifNotNil:
>                                 [:pref | [pref preferenceValue: value preferenceValue]
>                                         on: Deprecation do: [ : err | "Ignore preferences which may not be supported anymore."]]].
>
> Somehow the dict at: key fails because the dict at: method cannot find the key that is passed in by code that extracted it from the dict... Well, that's not nice.
>
> The best plausible cause I can up with right now is that the use of aReferenceStream on data saved in 2017 (almost certainly a 32bit image) might be suffering from some load/conversion malaise. I reverted the method to the prior (cmm 1/10/2020) version and it loaded my prefs. Saving them afresh, reverting the method back to the mt 11/22/2021 version and loading the new prefs file into an untouched 20892 image worked. This seems to support my hypothesis.
>
> I don't think this is worth any major angst but since it may bite somebody else it is useful to have the info in archive.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: CRN: Compare to Random Number
>
>
>