Frank nailed it by saying that the network should be last resort. I am *really* flailing out here, ok :) Nothing works, and the ability to download and use from a local cache would be a HUGE(!!!!) help, I suspect. Frank took the words right out of my keyboard (and said it better than I would have). Otherwise, my primary comment is that the "incantations" are sugary. And yes, I am hoping to have Migrate reduce some of that, but mostly, I'd like it to work. Frank's comments about the inability to have a common base class are interesting. I would like to think that we could have a quick file-in or something, or just use indirect references to classes to get around it, but I admit he probably is correct in his statement. In fact, Migrate has a weirdness to it, and this might be helpful, maybe?? Migrate is the base class; there are some methods, #homegrownPackages, #me, #meFull and maybe others that must be defined in a subclass. I have a subclass called GatorAid (UF humor), that tells the Migrate what to do, or maybe more accurately, what it is expected to manipulate. The expression Migrate default looks for a single subclass, and instantiates that. That way, we share Migrate, I have GatorAid, you and others would have any subclass you choose as the real workhorse. I package Migrate in a single mcz, but that does not work well because it captures my configuration. So, I share it with a file out, and install it in new images using my own package. You would do the same: Migrate default saveMigrate saves the entire package. Make any sense? Feel free to steal any good ideas therein. Any progress on caching code for Metacello would be a HUGE help. Thanks, Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich@vmware.com] Sent: Tuesday, February 07, 2012 11:58 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building images Bill, With the next release of Metacello I am planning to include a scripting API where you will write scripts like the following: Metacello new project: 'Seaside30'; load. or: Metacello new project: 'Seaside30'; squeaksource: 'MetacelloRepository'; version: '3.0.6; load: #('Base'). for more examples and some discussion see[1]. The API is still under development and if you (or anyone else) would like to comment, I suggest that you join the metacello group[2] and join the discussion. The Metacello class is intended to be included in the base image of Pharo, GemStone and Squeak, which would allow for cross-platform scripting. Dale [1] http://forum.world.st/Metacello-Scripting-API-strawman-td4334979.html [2] http://groups.google.com/group/metacello ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab@anest.ufl.edu> | To: pharo-project@lists.gforge.inria.fr | Sent: Tuesday, February 7, 2012 8:12:14 AM | Subject: [Pharo-project] Building images | | | Friends, | | I know it's not a popular position, but I consider Metacello to be | poorly factored, unstable, and a bit confusing. How many times do we | type things like: | | Gofer new | squeaksource: 'Fuel' ; | package: 'ConfigurationOfFuel' ; | load . | ( Smalltalk at: # ConfigurationOfFuel ) load . | This is concise, but it is also arguably syntactic sugar. I have been | trying to condense the redundant information, and have been (trying | to) capture the details in a tool I call Migrate. I have filed out | the main class (attached). The idea is that one can save the Migrate | package, load that into a new image, and quickly configure the new | image. At least that's the plan. | | Of interest now are the helper-metacello methods. What do you think? | I'm trying to help here... | | Bill | | | | | | | | | |