On Wed, Jan 27, 2010 at 7:19 PM, Dale Henrichs <dale.henrichs@gemstone.com>wrote:
Unload is on the list of things for Metacello ... the very early versions of Metacello supported unload.
As I moved things around, I stopped trying to keep unload alive focussing on getting the loading correct.
Now that Metacello is built on top of Gofer the mechanics of Monticello unload is taken care of ...
For complete support, I have to have Metacello create an inverse of the dependency map, so that the dependent projects are unloaded, too. As I recall there wasn't a lot ofcode involved in calculating the inverse dependency map.
I _was_ inclined to stop adding features to Metacello for a bit, let things stabilize with any needed bugfixes and then release 1.0, but if there is a consensus to include unload support in 1.0, then I can make that happen.
nononono. I agree 100% with you. Don't include this in 1.0. Just discuss about this and maybe, put it in your todo for 1.1 or whatever. I know that unloading is VERY complicated stuff. This was discussed also in another thread. The overrides for example. But, I didn't mean that Metacello supports unloads of everything. Maybe a first step (of course, even "hardcoded") is to support the unload of Metacello itself. So that I can create a ConfigurationOfMyApplication that I use to load all my necessary stuff in a code (runtime) image, and then Metacello disappear. I use metacello to create the image, but then I unload it. So...that main question is how easy is to unload Metacello ? Something like this: #(Metacello-Core Metacello-MC Metacello-Platform .... ) do: [ :each | (MCPackage named: each) unload ]. Cheers Mariano
Dale ----- "Mariano Martinez Peck" <marianopeck@gmail.com> wrote:
| 2010/1/26 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> | | > El mar, 26-01-2010 a las 23:03 +0100, Mariano Martinez Peck | escribió: | > > Thanks Torsten, this is really cool :) | > > | > > I would like everybody gets the same idea as you: the current | Dev | > > image is JUST a standard, little combination of possibilities. But | we | > > have the tools and we already did the work so that everybody can | > > create it's own Dev image, with it's own flavour, without too | much | > > pain, an using a PharoCore image as a base. That's why I would | like to | > > remove from Core as much as possible. | > > | > | > Indeed that is how I work. I shamelessly use your | ConfigurationOfPharo | > to build my development images from a PharoCore image. | > But for the production images, I use only the ConfigurationOfXXX | needed | > (that is, the ConfigurationOfAzteca, that is my application) and | that | > configuration references other ConfigurationsOfXXX as dependencies | > (magma, RFB, Seaside28). This is then executed in a PharoCore image | to | > build the 2 images that makes my setup deploy. | > | > | Yes, cool! That's exactly the idea :) | | Now I wonder....suppose I take a PharoCore, I run the | ConfigurationOfMyApplication, that brings ALL I need to deploy my | application, ok ? What about removing Metacello after the install ? | I | checked and the Metacello core install are 2MB more or less. So...I | was | thinking something like this: | | "Hi, I am metacello, I will download all you need and then I will | disappear". | | In the same way we have the enusreMetacello we can have another | called | ensureUnloadMetacello or something like that that we can use in | production | images after the load. | | what do you think ? | | Cheers | | Mariano | | | So, as Torsten said, Pharo isn't only about a new image release, but | a | > lot of tools that are enabling new ways to work in Smalltalk. | > | > | This sounds great. | | | > Cheers | > | > | > | > > BTW, it didn't work on Mac OS :( The problem is that the class | > > has references to SqueakMap, which has removed quite a long in | Pharo. | > > | > > Look ExternalWebBrowserMacOS >> isApplescriptAvailable | > > | > > Sorry I am not sure how to fix it. | > > | > > I attach PharoDebug.log. | > > | > > Cheers | > > | > > Mariano | > > | > > | > > | > > | > > | > > On Tue, Jan 26, 2010 at 10:45 PM, Torsten Bergmann | <astares@gmx.de> | > > wrote: | > > from pharo-dev to a custom (seaside) application image. | > > | > > Read | > > | > > | > | http://astares.blogspot.com/2010/01/pharo-10-release-candidate-2-and-image.h... | > > | > > Bye | > > T. | > > -- | > > Nur noch bis 31.01.2010: DSL-Komplettpaket für 16,99 | > > Euro/mtl.!* | > > http://portal.gmx.net/de/go/dsl02 | > > | > > _______________________________________________ | > > Pharo-project mailing list | > > Pharo-project@lists.gforge.inria.fr | > > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > > | > > _______________________________________________ | > > Pharo-project mailing list | > > Pharo-project@lists.gforge.inria.fr | > > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > -- | > Miguel Cobá | > http://miguel.leugim.com.mx | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project