metacello
metacello copied to clipboard
Metacello
Metacello doesn't clean up nicely on #cleanUp in Pharo
When trying to create a minimal image on Pharo, there is a #cleanUp and/or #cleanUp: protocol for classes with registry's to clean themselves up.
I discovered lots of post load MC classes in my image taking several MB's which weren't cleaned up until I did:
MetacelloProjectRegistration resetRegistry.
This should be called from #cleanUp on Pharo to play nicely - and any other caches that Metacello holds.
Tim,
I kind of depend upon the pharo maintainers to provide updates to Metacello for platform specific capabilities ... I don't use Pharo on a regular basis so I am not keeping up with the changes in the tools and I don't have the bandwidth to figure these things out on my own ... resetRegistry is something that I would not recommend doing unless one also plans on resetting the registry with proper information and in your scenario I couldn't begin to guess what the proper reset procedure would be ...
On 8/16/17 2:51 PM, Tim Mackinnon wrote:
When trying to create a minimal image on Pharo, there is a #cleanUp and/or #cleanUp: protocol for classes with registry's to clean themselves up.
I discovered lots of post load MC classes in my image taking several MB's which weren't cleaned up until I did:
MetacelloProjectRegistration resetRegistry.
This should be called from #cleanUp on Pharo to play nicely.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dalehenrich/metacello-work/issues/445, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmFTwAu-D1XhBsECDi0VC1Zxfha5rdqks5sY2R2gaJpZM4O5hs1.
Hi Dale - of course I understand you need Pharo users to contribute which is why I submitted this.
It does seem universally useful to understand how to cleanup all of Metacello's caches for a "deployment". In Pharo the protocol is #cleanUp and I recall VA had a concept of packaging but don't remember the specific method you implement for that.
Anyway, why don't you recommend #resetRegistry?
It's a lazy cache - it holds on to megabytes of MC classes that you wouldn't want in production. It would seem like a safe operation to flush it? I don't understand the reluctance?
Is there a different method to use? Are there others?
There are a lot of classes in Metacello and it's quite difficult to follow particularly as the Pharo port had no class comments?
Tim
Sent from my iPhone
On 18 Aug 2017, at 02:04, Dale Henrichs [email protected] wrote:
Tim,
I kind of depend upon the pharo maintainers to provide updates to Metacello for platform specific capabilities ... I don't use Pharo on a regular basis so I am not keeping up with the changes in the tools and I don't have the bandwidth to figure these things out on my own ... resetRegistry is something that I would not recommend doing unless one also plans on resetting the registry with proper information and in your scenario I couldn't begin to guess what the proper reset procedure would be ...
On 8/16/17 2:51 PM, Tim Mackinnon wrote:
When trying to create a minimal image on Pharo, there is a #cleanUp and/or #cleanUp: protocol for classes with registry's to clean themselves up.
I discovered lots of post load MC classes in my image taking several MB's which weren't cleaned up until I did:
MetacelloProjectRegistration resetRegistry.
This should be called from #cleanUp on Pharo to play nicely.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dalehenrich/metacello-work/issues/445, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmFTwAu-D1XhBsECDi0VC1Zxfha5rdqks5sY2R2gaJpZM4O5hs1.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
On 8/17/17 11:35 PM, Tim Mackinnon wrote:
Hi Dale - of course I understand you need Pharo users to contribute which is why I submitted this.
It does seem universally useful to understand how to cleanup all of Metacello's caches for a "deployment". In Pharo the protocol is #cleanUp and I recall VA had a concept of packaging but don't remember the specific method you implement for that.
Anyway, why don't you recommend #resetRegistry? It depends upon what you mean by "deployment". If by "deployment" you mean that you do not intend to ever load code into the image again, then #resetRegistry would be okay ... if you ever intend to update the image after "deployment" then #resetRegistry is not the answer ...
BTW, I'm a bit surprised to hear that the registry holds onto a lot of data ... of course I don't know what you mean by "post load MC classes" either, since I'm not sure exactly what you are doing ... if you are removing MC classes then perhaps Metacello will be rendered useless?
It's a lazy cache - it holds on to megabytes of MC classes that you wouldn't want in production. It would seem like a safe operation to flush it? I don't understand the reluctance? It is not a lazy cache ... it is a record of the versions of projects that have been loaded into the image. When you load projects into your image, the registry lets Metacello calculate the changes need to match the new load specifications.
Like I said, if you NEVER intend to install bugfixes in your production image using Metacello, then the registry can certainly be cleared ...
Is there a different method to use? Are there others? For doing what exactly? I really don't have a clear picture of what you are trying to do and and what the intended semantics of cleanUp is ... if cleanUp is supposed to only clear caches, then #resetRegistry should not be on the list ...
I'm confused when you say "it holds on to megabytes of MC classes" ... are you saying that you are stripping classes from the image? If you are removing arbitrary classes from the image, then presumably you will never be able to load bugfixes into the image either in which case you should just remove all of the Metacello classes and the registry will be swept away with everything else? If you want Metacello to continue to be functional then you need the Registry ...
With all of that said, the registry does hold onto ConfigurationOf instances and perhaps these are the "megabytes of MC classes" being kept alive? The best way to get rid of ConfigurationOf instances is to move the projects to GitHub. A BaselineOf is not nearly as heavy weight as a ConfigurationOf as git is a complete SCM as opposed to Monticello ...
Perhaps going forward, you should provide more detail about the makeup of the "megabytes of MC classes" and with this additional detail, we might be able to find "post load MC classes" that are truly superfluous?
There are a lot of classes in Metacello and it's quite difficult to follow particularly as the Pharo port had no class comments? That is true ... I'm not sure that I have the documentation skills even today to adequately describe how Metacello works ... if there were a compiler and unit tests for documentation, I would probably be able to learn how to satisfy those compiler and tests:)
Tim
Sent from my iPhone
On 18 Aug 2017, at 02:04, Dale Henrichs [email protected] wrote:
Tim,
I kind of depend upon the pharo maintainers to provide updates to Metacello for platform specific capabilities ... I don't use Pharo on a regular basis so I am not keeping up with the changes in the tools and I don't have the bandwidth to figure these things out on my own ... resetRegistry is something that I would not recommend doing unless one also plans on resetting the registry with proper information and in your scenario I couldn't begin to guess what the proper reset procedure would be ...
On 8/16/17 2:51 PM, Tim Mackinnon wrote:
When trying to create a minimal image on Pharo, there is a #cleanUp and/or #cleanUp: protocol for classes with registry's to clean themselves up.
I discovered lots of post load MC classes in my image taking several MB's which weren't cleaned up until I did:
MetacelloProjectRegistration resetRegistry.
This should be called from #cleanUp on Pharo to play nicely.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dalehenrich/metacello-work/issues/445, or mute the thread
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dalehenrich/metacello-work/issues/445#issuecomment-323272096, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmFT2CnFm9Kx19Y88o9dID6ZRB6AD_aks5sZTCqgaJpZM4O5hs1.
To give some context, I am using a Pharo minimal headless image that has just enough infrastructure to run Metacello and load project code.
The gaol in this minimal image, is to create a very small runtime image - so once deployed it's not intended to load code again via Metacello (in this case, you would create a new image).
I am loading my project via a BaseLineOf (which references a related projects, ConfigurationOf).
I am then relying on the current protocol of #cleanUp/#cleanUp: to ask all libraries to cleanup.
It sounds like, the MetacelloProjectRegistration is intended to hold onto the MC classes it has loaded for future reference, however for a truly minimal image you want to dump this cache.
I will ask on the Pharo lists, if people wold expect #cleanUp: true (an agressive cleanup) to cause Metacello to get into this state (possibly - as normally #cleanUp invokes a #cleanUp: false - for non-agressive cleanup).
Yes. Clarification would be good ... The registry should not be cleared if you are just cleaning up cached data, but if there is a "destructive" cleanup option, then nuking the registry would be okay ... I am just concerned that it be clear that if the destructive option is used, Metacello will not be expected to function correctly ...
On 8/28/17 6:53 AM, Tim Mackinnon wrote:
To give some context, I am using a Pharo minimal headless image that has just enough infrastructure to run Metacello and load project code.
The gaol in this minimal image, is to create a very small runtime image - so once deployed it's not intended to load code again via Metacello (in this case, you would create a new image).
I am loading my project via a BaseLineOf (which references a related projects, ConfigurationOf).
I am then relying on the current protocol of #cleanUp/#cleanUp: to ask all libraries to cleanup.
It sounds like, the MetacelloProjectRegistration is intended to hold onto the MC classes it has loaded for future reference, however for a truly minimal image you want to dump this cache.
I will ask on the Pharo lists, if people wold expect #cleanUp: true (an agressive cleanup) to cause Metacello to get into this state (possibly - as normally #cleanUp invokes a #cleanUp: false - for non-agressive cleanup).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/dalehenrich/metacello-work/issues/445#issuecomment-325359438, or mute the thread https://github.com/notifications/unsubscribe-auth/AAmFT3QwZ1Ge4PLM8m5ktA_Pp9d5Vi9_ks5scsZHgaJpZM4O5hs1.