[squeak-dev] Unable to load class with pool dictionary using Monticello
marcel.taeumel at hpi.de
Tue May 18 12:41:44 UTC 2021
> This error message does not make sense to me since MyPool is not a class > but a pool dictionary.
You can use classes and global dictionaries as a shared pool. From the system's perspective, it does not make any difference as long as #bindingOf: etc. is implemented. See class-side of SharedPool class. If you use a class as a shared pool in another class, the class variables will be shared. :-)
Yet, I think you found a bug. Maybe this was the reason why "FFI-Pools" exists in the first place. So that it can be loaded before "FFI-Kernel" xD
Am 18.05.2021 13:21:34 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
while loading a class (MyClass) with an attached pool dictionary (MyPool) today using Monticello, I encountered an error from MCPackageLoader which states:
Warning: This package depends on the following classes:
This error message does not make sense to me since MyPool is not a class but a pool dictionary. But in MCClassDefinition >> #requirements, all #poolDictionaries are explicitly added to the list of required items. If I exclude them from this list, I get a warning "The pool dictionary MyPool does not exist. Do you want it automatically created?" later from Class >> #sharing:. Is this a bug?
I also tried to manually add the pool dictionary initialization (Smalltalk at: #MyPool put: Dictionary new) into the preamble of the package, but this preamble is also evaluated too late (i.e., not before the dependency warning is raised. Also, this feels a bit too redundant to me.
Do we need a new subclass of MCDefinition to create pool dictionaries automatically? Or could we just remove the confirmation dialog in Class >> #sharing: so that new pools will automatically be created, especially in non-interactive CI contexts?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev