On Wed, Jan 27, 2010 at 7:19 PM, Dale Henrichs
<[email protected]>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" <[email protected]> wrote:
>
> | 2010/1/26 Miguel Enrique Cobá Martinez <[email protected]>
> |
> | > 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
> | <[email protected]>
> | > > wrote:
> | > > from pharo-dev to a custom (seaside) application image.
> | > >
> | > > Read
> | > >
> | > >
> | >
> |
> http://astares.blogspot.com/2010/01/pharo-10-release-candidate-2-and-image.html
> | > >
> | > > 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
> | > > [email protected]
> | > >
> | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> | > >
> | > > _______________________________________________
> | > > Pharo-project mailing list
> | > > [email protected]
> | > >
> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> | >
> | > --
> | > Miguel Cobá
> | > http://miguel.leugim.com.mx
> | >
> | >
> | > _______________________________________________
> | > Pharo-project mailing list
> | > [email protected]
> | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> | >
> |
> | _______________________________________________
> | Pharo-project mailing list
> | [email protected]
> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
