Dale, That sounds good. Is the mirror http://www.dsal.cl/squeaksource/ ? I want to be sure I use the correct one. I will report specifics as I identify them. The discussion here today has been helpful. "It's broke" wasn't much good, but that was about all I could tell until you guys helped to add some focus. Otherwise, I recommend trying to be more concise - though you have raised some good points about options that exist. If anything in Migrate is in any way helpful, feel free to raid the cookie jar. 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 1:43 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building images Bill, I'm not exactly sure what your real problem is ... there are downsides to all workarounds, but if using the mirrored SqueakSource site doesn't work for you (personally that looks like the best solution to a flakey SqueakSource), you can arrange to create a local disk-based repository of all of the code used by your project[1] and then tell Metacello to use the local directory for all Metacello loads[2]. If you go the Metacello route, then I suggest that you join the Metacello group[3] and ask for additional help (if you need any) there as there are a number of folks who can answer specific questions. Finally, if you can identify specific issues that you are having with Metacello you can report Metacello bugs here[4]. Dale [1] http://code.google.com/p/metacello/wiki/FAQ#How_do_I_create_a_local_cache_re... [2] http://code.google.com/p/metacello/wiki/FAQ#How_do_I_override_the_repository... [3] http://groups.google.com/group/metacello [4] http://code.google.com/p/metacello/issues/list ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab@anest.ufl.edu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, February 7, 2012 9:42:26 AM | Subject: Re: [Pharo-project] Building images | | 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 | | | | | | | | | | | | | | | | | | | | | | |