February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] It would be me first

by Mariano Martinez Peck

On Tue, Feb 7, 2012 at 6:38 PM, Steve Wart <steve(a)wart.ca> wrote: > Isn't there a mirror somewhere? Yes, in Chile. Search the mailing list. I however, choose something different: http://marianopeck.wordpress.com/2011/11/08/migrating-projects-to-squeaksou… > Seems like it's always down. > > On Tue, Feb 7, 2012 at 7:58 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > >> On 7 February 2012 15:08, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > saying that SqueakSource down. >> > >> > or it is down only for me , such an unlucky guy? :) >> >> Looks like it's dead. The machine's alive, and the HTTP server's alive >> though. >> >> frank >> >> > -- Mariano http://marianopeck.wordpress.com

Feb. 7, 2012

Re: [Pharo-project] Building images

by Dale Henrichs

Bill, Follow the link that I gave you for the mirror as the details are there... Dale ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | To: Pharo-project(a)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(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale | Henrichs [dhenrich(a)vmware.com] | Sent: Tuesday, February 07, 2012 1:43 PM | To: Pharo-project(a)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_r… | [2] | http://code.google.com/p/metacello/wiki/FAQ#How_do_I_override_the_repositor… | [3] http://groups.google.com/group/metacello | [4] http://code.google.com/p/metacello/issues/list | | ----- Original Message ----- | | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | | To: Pharo-project(a)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(a)lists.gforge.inria.fr | | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale | | Henrichs [dhenrich(a)vmware.com] | | Sent: Tuesday, February 07, 2012 11:58 AM | | To: Pharo-project(a)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(a)anest.ufl.edu> | | | To: pharo-project(a)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 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Feb. 7, 2012

Re: [Pharo-project] Building images

by Schwab,Wilhelm K

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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenrich(a)vmware.com] Sent: Tuesday, February 07, 2012 1:43 PM To: Pharo-project(a)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_r… [2] http://code.google.com/p/metacello/wiki/FAQ#How_do_I_override_the_repositor… [3] http://groups.google.com/group/metacello [4] http://code.google.com/p/metacello/issues/list ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | To: Pharo-project(a)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(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale | Henrichs [dhenrich(a)vmware.com] | Sent: Tuesday, February 07, 2012 11:58 AM | To: Pharo-project(a)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(a)anest.ufl.edu> | | To: pharo-project(a)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 | | | | | | | | | | | | | | | | | | | | | | |

Feb. 7, 2012

[Pharo-project] [update 1.4] #14320 + 14321

by Marcus Denker

14320 + 14321 -------------- Issue 4813: MethodWrapper related fixes from Eliot http://code.google.com/p/pharo/issues/detail?id=4813 -- Marcus Denker -- http://marcusdenker.de

Feb. 7, 2012

[Pharo-project] [update 1.4] #14319

by Marcus Denker

14319 ----- Issue 5258: Another minor fix in Abstract Tool http://code.google.com/p/pharo/issues/detail?id=5258 Issue 5257: Minor fix in Abstract Tool http://code.google.com/p/pharo/issues/detail?id=5257 Issue 5262: PLuggableMultiColumnListMorph issue http://code.google.com/p/pharo/issues/detail?id=5262 Issue 5261: Fix in PluggableIconListMorph http://code.google.com/p/pharo/issues/detail?id=5261 -- Marcus Denker -- http://marcusdenker.de

Feb. 7, 2012

Re: [Pharo-project] Building images

by Dale Henrichs

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_r… [2] http://code.google.com/p/metacello/wiki/FAQ#How_do_I_override_the_repositor… [3] http://groups.google.com/group/metacello [4] http://code.google.com/p/metacello/issues/list ----- Original Message ----- | From: "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> | To: Pharo-project(a)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(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale | Henrichs [dhenrich(a)vmware.com] | Sent: Tuesday, February 07, 2012 11:58 AM | To: Pharo-project(a)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(a)anest.ufl.edu> | | To: pharo-project(a)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 | | | | | | | | | | | | | | | | | | | | | | |

Feb. 7, 2012

Re: [Pharo-project] Building images

by Schwab,Wilhelm K

+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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Tuesday, February 07, 2012 1:16 PM To: Pharo-project(a)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

Feb. 7, 2012

Re: [Pharo-project] Building images

by Dale Henrichs

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(a)anest.ufl.edu> | To: Pharo-project(a)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(a)lists.gforge.inria.fr | [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Dale | Henrichs [dhenrich(a)vmware.com] | Sent: Tuesday, February 07, 2012 11:58 AM | To: Pharo-project(a)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(a)anest.ufl.edu> | | To: pharo-project(a)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 | | | | | | | | | | | | | | | | | | | | | | |

Feb. 7, 2012

Re: [Pharo-project] Building images

by Sven Van Caekenberghe

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

Feb. 7, 2012

Re: [Pharo-project] Building images

by Schwab,Wilhelm K

It IS killing the experience, and the error handling is too optimistic for its own good, I think?? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Tuesday, February 07, 2012 12:58 PM To: Pharo-project(a)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

Feb. 7, 2012