> In other words, your shared pool should indeed be a class. It doesn’t matter for using it, but it does matter for loading it reliably.


Hmm, I am pretty sure that this would confuse Squot (which is also based on Monticello) ...


For now, I have defined the shared pool in question as a Smalltalk global in my baseline preload script. Still, I don't think this solution is optimal. But I'll note it down for later. :-)


Best,

Christoph

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Vanessa Freudenberg <vanessa at codefrau.net>
Gesendet: Dienstag, 18. Mai 2021 19:02:37
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Unable to load class with pool dictionary using Monticello

I’m certain we had a good reason to turn loadable shared pools into classes. I think (but I’m not entirely sure) it had to do with ensuring they had been properly initialized before executing code that depended on the constants declared in that pool. Class initialization of a designated class was TSTTCPW.

In other words, your shared pool should indeed be a class. It doesn’t matter for using it, but it does matter for loading it reliably.

I admit I could be misremembering, it’s been quite a while.

–Vanessa–


On Tue, May 18, 2021 at 05:42 Marcel Taeumel <marcel.taeumel at hpi.de<mailto:marcel.taeumel at hpi.de>> wrote:
Hi Christoph,

> 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

Best,
Marcel

Am 18.05.2021 13:21:34 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de<mailto:christoph.thiede at student.hpi.uni-potsdam.de>>:

Hi all,


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:

MyPool

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?

Best,
Christoph

<http://www.hpi.de/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210528/dba55a20/attachment-0001.html>