[squeak-dev] Loading preferences fails in 64bit 20892 image

Jakob Reschke jakres+squeak at gmail.com
Wed Dec 29 21:04:12 UTC 2021

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

More information about the Squeak-dev mailing list