Hi List,
When loading my.prefs into a new base image, if the class being configured doesn't exist loading stops quite unglamorously.
How about using a dummy superclass UndefinedClass that serves as the superclass of a class that hasn't been loaded? When the class isn't found, create it as a subclass of that. If the class is later loaded, class reshaping will change it into the appropriate class.
For the purpose of storing the preference value in the meantime, we could use method rewriting like editing help topics, or putting it directly in Preference as a dictionary entry.
By using a dummy superclass, you can browse for preferences set on unistalled software, as well as exclude them from release building.
How does this sound?
Hi Lauren --
Our current mechanism of storing and loading preferences in files uses ReferencesStream, which reads and writes binary data.
If you could share more details on this issue, we might be able to re-configure the loading code for those (missing) classes. Otherwise, a generic "[ ... ] on: Error do: [:ex | ...]" might also help for a more robust "stream next" in Preferences class >> #loadPreferencesFrom:.
For more info on data streams, see implementors of:
#classVersion
#readDataFrom:size: #objectForDataStream: #withClassVersion:
Best, Marcel Am 29.03.2022 17:42:09 schrieb Lauren P drurowin@gmail.com: Hi List,
When loading my.prefs into a new base image, if the class being configured doesn't exist loading stops quite unglamorously.
How about using a dummy superclass UndefinedClass that serves as the superclass of a class that hasn't been loaded? When the class isn't found, create it as a subclass of that. If the class is later loaded, class reshaping will change it into the appropriate class.
For the purpose of storing the preference value in the meantime, we could use method rewriting like editing help topics, or putting it directly in Preference as a dictionary entry.
By using a dummy superclass, you can browse for preferences set on unistalled software, as well as exclude them from release building.
How does this sound?
Hi Marcel,
On 4/4/22 09:20, Marcel Taeumel wrote:
If you could share more details on this issue, we might be able to re-configure the loading code for those (missing) classes. Otherwise, a generic "[ ... ] on: Error do: [:ex | ...]" might also help for a more robust "stream next" in Preferences class >> #loadPreferencesFrom:.
Take Metacello-GitHub. It defines a pragma preference on MCGitHubRepository. If you try loading a my.prefs in an image where Metacello-GitHub isn't loaded, preference loading will abruptly end.
For more info on data streams, see implementors of:
#classVersion
#readDataFrom:size: #objectForDataStream: #withClassVersion:
I looked through ReferenceStream and followed along in the debugger and some inspectors to get a feel for how it all worked.
Back to the MCGitHubRepository example, the ReferenceStream will try to instantiate a MCGitHubRepository to fill the value for the 'provider' instance variable of PragmaPreference... which rapidly fails unless it's loaded.
I've got a quick version saved in the attached file, but it's only a partial fix and is likely full of issues and not stable enough to introduce to the inbox, to see if I'm on the right track.
( I changed the error class in the failing portion from Error to KeyNotFound to match the class that SmalltalkImage>>at: signals to make it easier to detect.
If this looks like a good direction to you, I'll proceed work on it.
squeak-dev@lists.squeakfoundation.org