[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
On 7 February 2012 16:12, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Friends,
I know it's not a popular position, but I consider Metacello to be poorly factored, unstable, and a bit confusing.
Would you please expand a bit on the above? Confusing, I'll happily agree with, but then configuration management is not pretty at the best of times. It's no worse than Maven's pom.xml files, except for the Turing-completeness of the DSL. The issues I've had with Metacello have either been addressed in the not-yet-released latest release (beta32, IIRC), or not the fault of Metacello: many folks write their specs assuming an available network. Instead, one should always attempt the package-cache (MCCacheRepository default, in other words) FIRST, and IF the package isn't already there, then try load it. Metacello's next release will be able to bootstrap itself without relying on the network, but there are many configurations out there that won't be able to. (I must still submit a fix to MetacelloBaseConfiguration (if I remember the name correctly - whatever MetacelloToolBox [1] uses ) to fix the issue for new configurations. Bad me.) [1] https://gist.github.com/1438930
 How many times do we type things like:
Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. (Smalltalk at: #ConfigurationOfFuel) load.
Well, I don't ever type that, but that's because Squeak doesn't ship with Gofer, so I use Installer instead :)
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.
Which redundant information? There isn't any in the above, except maybe 'ConfigurationOfFuel', or 'Fuel'. If you ASSUME that you only want to use SqueakSource, you could say [:packageName | | confName | confName := 'ConfigurationOf', packageName. Gofer new squeaksource: packageName; package: confName; load. (Smalltalk at: confName asSymbol) load] value: 'Fuel'. Not exactly what I'd call clear and concise, but it does remove redundancies.It looks like you're trying to do something vaguely similar in Migrate - #loadMetacelloPackage:name:version: in particular. But I _don't_ see much of Metacello in any of this. Well, let me be clearer: I don't see any talk of specs, and that's pretty much most of Metacello right there. A properly written Metacello spec will also take care of pulling in transitive dependencies, which #web looks like it's doing by hand. You can't have a common base class for configurations because that would be part of Metacello, and you would need to have Metacello in your image in order to load Metacello! frank
 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
2012/2/7 Frank Shearar <frank.shearar@gmail.com>:
On 7 February 2012 16:12, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Friends,
I know it's not a popular position, but I consider Metacello to be poorly factored, unstable, and a bit confusing.
Would you please expand a bit on the above? Confusing, I'll happily agree with, but then configuration management is not pretty at the best of times. It's no worse than Maven's pom.xml files, except for the Turing-completeness of the DSL.
The issues I've had with Metacello have either been addressed in the not-yet-released latest release (beta32, IIRC), or not the fault of Metacello: many folks write their specs assuming an available network. Instead, one should always attempt the package-cache (MCCacheRepository default, in other words) FIRST, and IF the package isn't already there, then try load it.
I suspect a nasty side effect is that an erroneous network address in the Metacello configuration will get undetected. This can happen easily because you previously loaded some package with Monticello, but then edited your Metacello configuration by hand. There is also a more subtle possible problem if names match but GUID don't. That easily happens, I created such mess when noob working with multiple images and local repositories. At least, the configuration needs to be validated with an available network. And the validation process shall check these two potential problems. Nicolas
Metacello's next release will be able to bootstrap itself without relying on the network, but there are many configurations out there that won't be able to. (I must still submit a fix to MetacelloBaseConfiguration (if I remember the name correctly - whatever MetacelloToolBox [1] uses ) to fix the issue for new configurations. Bad me.)
[1] https://gist.github.com/1438930
 How many times do we type things like:
 Gofer new     squeaksource: 'Fuel';     package: 'ConfigurationOfFuel';     load.  (Smalltalk at: #ConfigurationOfFuel) load.
Well, I don't ever type that, but that's because Squeak doesn't ship with Gofer, so I use Installer instead :)
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.
Which redundant information? There isn't any in the above, except maybe 'ConfigurationOfFuel', or 'Fuel'. If you ASSUME that you only want to use SqueakSource, you could say
[:packageName | | confName |  confName := 'ConfigurationOf', packageName.  Gofer new   squeaksource: packageName;   package: confName;   load.  (Smalltalk at: confName asSymbol) load] value: 'Fuel'.
Not exactly what I'd call clear and concise, but it does remove redundancies.It looks like you're trying to do something vaguely similar in Migrate - #loadMetacelloPackage:name:version: in particular.
But I _don't_ see much of Metacello in any of this. Well, let me be clearer: I don't see any talk of specs, and that's pretty much most of Metacello right there. A properly written Metacello spec will also take care of pulling in transitive dependencies, which #web looks like it's doing by hand.
You can't have a common base class for configurations because that would be part of Metacello, and you would need to have Metacello in your image in order to load Metacello!
frank
 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
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 | | | | | | | | | |
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 | | | | | | | | | |
On 07 Feb 2012, at 18:42, Schwab,Wilhelm K wrote:
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).
I agree that better caching behavior would be good, but really this is inherently a network related operation: loading remotely stored code. I fail to see how updating let's say Ubuntu would work with a failing network. SqueakSource has been failing today and was maybe slow before that, that would kill your whole experience, especially if you do big builds. Sven
It IS killing the experience, and the error handling is too optimistic for its own good, I think?? ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Tuesday, February 07, 2012 12:58 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building images On 07 Feb 2012, at 18:42, Schwab,Wilhelm K wrote:
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).
I agree that better caching behavior would be good, but really this is inherently a network related operation: loading remotely stored code. I fail to see how updating let's say Ubuntu would work with a failing network. SqueakSource has been failing today and was maybe slow before that, that would kill your whole experience, especially if you do big builds. Sven
On 07 Feb 2012, at 19:05, Schwab,Wilhelm K wrote:
It IS killing the experience, and the error handling is too optimistic for its own good, I think??
Well, I am on the side of signalling all exceptional situations immediately. There is no excuse for silently ignoring the fact that a download did not work. Unless the code can successfully deal with the exceptional situation. Sven
+100 :) As it is, the image melts down into a retry hell that I can't break and seems to no chance of succeeding. I probably have made mistakes (Migrate has evolved with *every* release of Dolphin and now Pharo). Change is the nature of software, and tweaking loaders goes along for the ride. But I would want errors highlighted so I can fix them if I own them. As it is, I can't get a 1.3 image to build :( Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven@beta9.be] Sent: Tuesday, February 07, 2012 1:16 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building images On 07 Feb 2012, at 19:05, Schwab,Wilhelm K wrote:
It IS killing the experience, and the error handling is too optimistic for its own good, I think??
Well, I am on the side of signalling all exceptional situations immediately. There is no excuse for silently ignoring the fact that a download did not work. Unless the code can successfully deal with the exceptional situation. Sven
Bill, Have you tried using the SqueakSource mirror. There are instructions here[1] for configuring your Pharo image to "seamlessly" switch to using the mirror site. I haven't personally used the mirror, but it looks like exactly the solution you want: MRManager redirectFrom: 'http://www.squeaksource.com/' to: 'http://dsal.cl/squeaksource/'. and all references to http://www.squeaksource.com/ are mapped to http://dsal.cl/squeaksource/ references ... Dale [1] http://dsal.cl/squeaksource/ ----- 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 | | | | | | | | | | | | | | | | | | | | | | |
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 | | | | | | | | | | | | | | | | | | | | | | |
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 | | | | | | | | | | | | | | | | | | | | | | |
Bill, Follow the link that I gave you for the mirror as the details are there... Dale ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab@anest.ufl.edu> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, February 7, 2012 11:09:13 AM | Subject: Re: [Pharo-project] Building images | | 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 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
On 07 Feb 2012, at 17:58, Dale Henrichs wrote:
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.
Looking forward to all that, Dale! Sven
participants (5)
-
Dale Henrichs -
Frank Shearar -
Nicolas Cellier -
Schwab,Wilhelm K -
Sven Van Caekenberghe