Unable to load class with pool dictionary using Monticello
Locked
Unable to load class with pool dictionary using Monticello
 
|
Hi all,
while loading a class (MyClass) with an attached pool dictionary (MyPool) today using Monticello, I encountered an error from MCPackageLoader which states:
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
Carpe Squeak!
|
Re: Unable to load class with pool dictionary using Monticello
|
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
|
|
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 <[hidden email]> wrote:
|
Re: Unable to load class with pool dictionary using Monticello
|
|
> On 2021-05-18, at 10:02 AM, Vanessa Freudenberg <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Monorail doesn't go all the way to Tomorrowland. |
Re: Unable to load class with pool dictionary using Monticello
|
|
In reply to this post by codefrau
> 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 <[hidden email]> im Auftrag von Vanessa Freudenberg <[hidden email]>
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 <[hidden email]> wrote:
Carpe Squeak!
|
Re: Unable to load class with pool dictionary using Monticello
|
|
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 <[hidden email]> 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 <[hidden email]> im Auftrag von Vanessa Freudenberg <[hidden email]> > 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 <[hidden email]> 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 <[hidden email]>: >> 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; [hidden email]; http://www.rowledge.org/tim Calm down -- it's only ones and zeros. |
Re: Unable to load class with pool dictionary using Monticello
|
|
In reply to this post by Christoph Thiede
Hi Christoph, Thiede, Christoph <[hidden email]> schrieb am Sa., 29. Mai 2021, 01:25:
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 |
Re: Unable to load class with pool dictionary using Monticello
|
|
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
Carpe Squeak!
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |