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
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@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/]
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@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@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
On 2021-05-18, at 10:02 AM, Vanessa Freudenberg vanessa@codefrau.net wrote:
I’m certain we had a good reason to turn loadable shared pools into classes.
This is stuff Andreas & I did in 2003. By making the shared variables stuff classes we could map them into the version system decently so that they got loaded. It also makes them a bit more maintainable since you don't rely on magic doits to establish the contents.
One very important matter we bailed on (most definitely wimping out) was sorting out the TextConstants stuff. That is still awaiting some brave hero to ride into frame and Sort It Out.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Monorail doesn't go all the way to Tomorrowland.
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@lists.squeakfoundation.org im Auftrag von Vanessa Freudenberg vanessa@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@hpi.demailto:marcel.taeumel@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@student.hpi.uni-potsdam.demailto:christoph.thiede@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
I refer the honourable gentleman to the answer I gave on May 18 at 12:15pm PST.
On 2021-05-28, at 4:25 PM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
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 Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Vanessa Freudenberg vanessa@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@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@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
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Calm down -- it's only ones and zeros.
Hi Christoph,
Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de schrieb am Sa., 29. Mai 2021, 01:25:
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) ...
Why do you think so? The fact that it is still based on Monticello in that
regard would imply to me that the class as pool dictionary approach should be better there too.
Kind regards, Jakob
Hi Jakob,
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) ...
Why do you think so? The fact that it is still based on Monticello in that regard would imply to me that the class as pool dictionary approach should be better there too.
Yeah, you are probably right. Just conceptually, it would feel a bit weird to me to see an empty class stub for every pool dictionary in my image.
@Tim: Sorry I missed your message! Same argument as above, if possible, I would like to avoid the ambivalency in my image.
Best, Christoph
squeak-dev@lists.squeakfoundation.org