November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About deprecated methods

by Adrian Lienhard

Nice! > I wanted to remove the deprecated methods of 1.0 in 1.1 > Here is a first cut of deprecated methods that are not called by > other in the system. This means that there are deprecated methods called by existing methods in the image? That should not be the case... > May be we should not integrate it now but create a slice that people > could load if they want. > <RemovingDeprecatedMethods.2.cs> I think this could be integrated already now. What would also be good is a wiki page that documents in which version a method was deprecated, and when it was removed. This would help people migrate their code. Adrian

Nov. 9, 2009

[Pharo-project] About deprecated methods

by StÃ©phane Ducasse

Hi guys I wanted to remove the deprecated methods of 1.0 in 1.1 Here is a first cut of deprecated methods that are not called by other in the system. May be we should not integrate it now but create a slice that people could load if they want. Stef

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Dale Henrichs

Bill, You add the overrides to the loader for a version, so you'd use the overrides in an emergency or when you wanted to explicitly use a different repository....It's literally an override - when used all packages are loaded from the override repositories. Instead of launching a load with this expression: (ConfigurationOfGLASS project version: '1.0-beta.2') load: 'Dev'. You'd use this expression: | version | version := ConfigurationOfGLASS project version: '1.0-beta.2'. version versionSpec loader repositoryOverrides: <list of MC repositories>. version load: 'Seaside3.0 Dev'. The repository overrides are passed along throughout the load chain for dependent packages etc. Apologies for the 'version versionSpec loader' sequence, but I've been slowly pulling various bits of capability out to the version API as demand surfaces ... After this email exchange, I'll probably pull the repositoryOverrides: message all the way out to the version:) Dale ----- "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> wrote: | That is a valuable feature. When/how does it make the decision that | overrides are needed? Does it timeout and fail-over on each attempt? | That could get painful to watch, or could be problematic on slow | connections. | | Bill | | | | -----Original Message----- | From: pharo-project-bounces(a)lists.gforge.inria.fr | [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale | Henrichs | Sent: Monday, November 09, 2009 3:26 PM | To: Pharo-project(a)lists.gforge.inria.fr | Cc: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] Not a disaster (this time) | | As an FYI... for those using Metacello... | | In Metacello you can arrange to override the repositories used for | loading ... useful in cases where servers are down or offline/not | accessible for other reasons ...saves you from having to edit | configurations ... | | I use the override for creating a repository from scratch | (bootstrapping from a local disk-based repositories) when the | configurations that I'm using reference the public HTTP repositories. | | Dale | | ----- "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> wrote: | | | Adrian, | | | | You are correct, it does contain them (thanks for mentioning that). | | | Saving my own copies _is_ a problem, but fortunately I do not need | to | | do so. | | | | How do you enforce local loads? Do you insist on downloading | | everything yourselves, or do you have some type of lazy download | with | | cancel capability? In an ideal world, I would hope to see a tool | that | | tries to download the latest versions, shows progress toward same, | and | | accepts user interaction to head off a hopeless situation like | today. | | If the user cancels the download, then there would be an option to | | install from the local repository. | | | | Bill | | | | | | | | -----Original Message----- | | From: pharo-project-bounces(a)lists.gforge.inria.fr | | [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of | | Adrian Lienhard | | Sent: Monday, November 09, 2009 2:31 PM | | To: Pharo-project(a)lists.gforge.inria.fr | | Subject: Re: [Pharo-project] Not a disaster (this time) | | | | Hi Bill, | | | | At netstyle.ch and Cmsbox we have the rule that all projects have to | | | be completely loadable from our own MC repository. I suggest to do | the | | same for the reasons you mention below. You never know what happens | to | | external resources... | | | | Storing a local copy with MC should not be a problem. Actually, the | | | package-cache folder should already contain the file. | | | | Cheers, | | Adrian | | | | On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: | | | | > Hello all, | | > | | > I am trying to be a good tester, and have been shot in the foot | now | | | | > for a couple of days. That's no great loss, but a similar set of | | | > circumstances could be very ugly in the future. My ailing build | | > process for RC1 is thwarted by source.squeakfoundation.org's being | | | > offline. Imagine a deadline (paying customer, mission-critical | | gizmo, | | > grant submission - whatever haunts you) and being stuck. | | > | | > I have even tried to save the FFI packages locally, and that | seems | | to | | > go haywire over talking to the server. Having chosen the package | | name | | > and a local repository, I would expect MC to take the code it has | | | > locally and save it to my local drive, but apparently that's not | | what | | > it does. | | > | | > There is no need for urgent action (this is only a drill<g>), but | | | > there should be some redundancy in where the code is stored, and | MC | | > should not prevent my saving code I already have to my local | drive. | | | | > There isn't (at least not that I can find), and it does :( | | > | | > Bill | | > | | > | | > _______________________________________________ | | > Pharo-project mailing list | | > Pharo-project(a)lists.gforge.inria.fr | | > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | | | | _______________________________________________ | | Pharo-project mailing list | | Pharo-project(a)lists.gforge.inria.fr | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | | _______________________________________________ | | Pharo-project mailing list | | Pharo-project(a)lists.gforge.inria.fr | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by StÃ©phane Ducasse

What I would like especially when coding in the train is that my script using a given repository can use my local cache. I know that Installer did not support that. Lukas is gofer supporting that behavior? Stef On Nov 9, 2009, at 9:06 PM, Adrian Lienhard wrote: > We don't have any automated approach. All images built load from our > own repository. If a developer wants to add an external package or > update an existing one, he has to save into our repository. > > Adrian > > On Nov 9, 2009, at 21:01 , Schwab,Wilhelm K wrote: > >> Adrian, >> >> You are correct, it does contain them (thanks for mentioning that). >> Saving my own copies _is_ a problem, but fortunately I do not need >> to do so. >> >> How do you enforce local loads? Do you insist on downloading >> everything yourselves, or do you have some type of lazy download >> with cancel capability? In an ideal world, I would hope to see a >> tool that tries to download the latest versions, shows progress >> toward same, and accepts user interaction to head off a hopeless >> situation like today. If the user cancels the download, then there >> would be an option to install from the local repository. >> >> Bill >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- >> project-bounces(a)lists.gforge.inria.fr >> ] On Behalf Of Adrian Lienhard >> Sent: Monday, November 09, 2009 2:31 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Not a disaster (this time) >> >> Hi Bill, >> >> At netstyle.ch and Cmsbox we have the rule that all projects have to >> be completely loadable from our own MC repository. I suggest to do >> the same for the reasons you mention below. You never know what >> happens to external resources... >> >> Storing a local copy with MC should not be a problem. Actually, the >> package-cache folder should already contain the file. >> >> Cheers, >> Adrian >> >> On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: >> >>> Hello all, >>> >>> I am trying to be a good tester, and have been shot in the foot now >>> for a couple of days. That's no great loss, but a similar set of >>> circumstances could be very ugly in the future. My ailing build >>> process for RC1 is thwarted by source.squeakfoundation.org's being >>> offline. Imagine a deadline (paying customer, mission-critical >>> gizmo, >>> grant submission - whatever haunts you) and being stuck. >>> >>> I have even tried to save the FFI packages locally, and that seems >>> to >>> go haywire over talking to the server. Having chosen the package >>> name >>> and a local repository, I would expect MC to take the code it has >>> locally and save it to my local drive, but apparently that's not >>> what >>> it does. >>> >>> There is no need for urgent action (this is only a drill<g>), but >>> there should be some redundancy in where the code is stored, and MC >>> should not prevent my saving code I already have to my local drive. >>> There isn't (at least not that I can find), and it does :( >>> >>> Bill >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Schwab,Wilhelm K

That is a valuable feature. When/how does it make the decision that overrides are needed? Does it timeout and fail-over on each attempt? That could get painful to watch, or could be problematic on slow connections. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, November 09, 2009 3:26 PM To: Pharo-project(a)lists.gforge.inria.fr Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) As an FYI... for those using Metacello... In Metacello you can arrange to override the repositories used for loading ... useful in cases where servers are down or offline/not accessible for other reasons ...saves you from having to edit configurations ... I use the override for creating a repository from scratch (bootstrapping from a local disk-based repositories) when the configurations that I'm using reference the public HTTP repositories. Dale ----- "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> wrote: | Adrian, | | You are correct, it does contain them (thanks for mentioning that). | Saving my own copies _is_ a problem, but fortunately I do not need to | do so. | | How do you enforce local loads? Do you insist on downloading | everything yourselves, or do you have some type of lazy download with | cancel capability? In an ideal world, I would hope to see a tool that | tries to download the latest versions, shows progress toward same, and | accepts user interaction to head off a hopeless situation like today. | If the user cancels the download, then there would be an option to | install from the local repository. | | Bill | | | | -----Original Message----- | From: pharo-project-bounces(a)lists.gforge.inria.fr | [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of | Adrian Lienhard | Sent: Monday, November 09, 2009 2:31 PM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] Not a disaster (this time) | | Hi Bill, | | At netstyle.ch and Cmsbox we have the rule that all projects have to | be completely loadable from our own MC repository. I suggest to do the | same for the reasons you mention below. You never know what happens to | external resources... | | Storing a local copy with MC should not be a problem. Actually, the | package-cache folder should already contain the file. | | Cheers, | Adrian | | On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: | | > Hello all, | > | > I am trying to be a good tester, and have been shot in the foot now | | > for a couple of days. That's no great loss, but a similar set of | > circumstances could be very ugly in the future. My ailing build | > process for RC1 is thwarted by source.squeakfoundation.org's being | > offline. Imagine a deadline (paying customer, mission-critical | gizmo, | > grant submission - whatever haunts you) and being stuck. | > | > I have even tried to save the FFI packages locally, and that seems | to | > go haywire over talking to the server. Having chosen the package | name | > and a local repository, I would expect MC to take the code it has | > locally and save it to my local drive, but apparently that's not | what | > it does. | > | > There is no need for urgent action (this is only a drill<g>), but | > there should be some redundancy in where the code is stored, and MC | > should not prevent my saving code I already have to my local drive. | | > There isn't (at least not that I can find), and it does :( | > | > Bill | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Dale Henrichs

As an FYI... for those using Metacello... In Metacello you can arrange to override the repositories used for loading ... useful in cases where servers are down or offline/not accessible for other reasons ...saves you from having to edit configurations ... I use the override for creating a repository from scratch (bootstrapping from a local disk-based repositories) when the configurations that I'm using reference the public HTTP repositories. Dale ----- "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> wrote: | Adrian, | | You are correct, it does contain them (thanks for mentioning that). | Saving my own copies _is_ a problem, but fortunately I do not need to | do so. | | How do you enforce local loads? Do you insist on downloading | everything yourselves, or do you have some type of lazy download with | cancel capability? In an ideal world, I would hope to see a tool that | tries to download the latest versions, shows progress toward same, and | accepts user interaction to head off a hopeless situation like today. | If the user cancels the download, then there would be an option to | install from the local repository. | | Bill | | | | -----Original Message----- | From: pharo-project-bounces(a)lists.gforge.inria.fr | [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of | Adrian Lienhard | Sent: Monday, November 09, 2009 2:31 PM | To: Pharo-project(a)lists.gforge.inria.fr | Subject: Re: [Pharo-project] Not a disaster (this time) | | Hi Bill, | | At netstyle.ch and Cmsbox we have the rule that all projects have to | be completely loadable from our own MC repository. I suggest to do the | same for the reasons you mention below. You never know what happens to | external resources... | | Storing a local copy with MC should not be a problem. Actually, the | package-cache folder should already contain the file. | | Cheers, | Adrian | | On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: | | > Hello all, | > | > I am trying to be a good tester, and have been shot in the foot now | | > for a couple of days. That's no great loss, but a similar set of | > circumstances could be very ugly in the future. My ailing build | > process for RC1 is thwarted by source.squeakfoundation.org's being | > offline. Imagine a deadline (paying customer, mission-critical | gizmo, | > grant submission - whatever haunts you) and being stuck. | > | > I have even tried to save the FFI packages locally, and that seems | to | > go haywire over talking to the server. Having chosen the package | name | > and a local repository, I would expect MC to take the code it has | > locally and save it to my local drive, but apparently that's not | what | > it does. | > | > There is no need for urgent action (this is only a drill<g>), but | > there should be some redundancy in where the code is stored, and MC | > should not prevent my saving code I already have to my local drive. | | > There isn't (at least not that I can find), and it does :( | > | > Bill | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Schwab,Wilhelm K

Adrian, That's fine - it will certainly avoid the trap. Thanks! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, November 09, 2009 3:06 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) We don't have any automated approach. All images built load from our own repository. If a developer wants to add an external package or update an existing one, he has to save into our repository. Adrian On Nov 9, 2009, at 21:01 , Schwab,Wilhelm K wrote: > Adrian, > > You are correct, it does contain them (thanks for mentioning that). > Saving my own copies _is_ a problem, but fortunately I do not need to > do so. > > How do you enforce local loads? Do you insist on downloading > everything yourselves, or do you have some type of lazy download with > cancel capability? In an ideal world, I would hope to see a tool that > tries to download the latest versions, shows progress toward same, and > accepts user interaction to head off a hopeless situation like today. > If the user cancels the download, then there would be an option to > install from the local repository. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Adrian Lienhard > Sent: Monday, November 09, 2009 2:31 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Not a disaster (this time) > > Hi Bill, > > At netstyle.ch and Cmsbox we have the rule that all projects have to > be completely loadable from our own MC repository. I suggest to do the > same for the reasons you mention below. You never know what happens to > external resources... > > Storing a local copy with MC should not be a problem. Actually, the > package-cache folder should already contain the file. > > Cheers, > Adrian > > On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: > >> Hello all, >> >> I am trying to be a good tester, and have been shot in the foot now >> for a couple of days. That's no great loss, but a similar set of >> circumstances could be very ugly in the future. My ailing build >> process for RC1 is thwarted by source.squeakfoundation.org's being >> offline. Imagine a deadline (paying customer, mission-critical >> gizmo, grant submission - whatever haunts you) and being stuck. >> >> I have even tried to save the FFI packages locally, and that seems to >> go haywire over talking to the server. Having chosen the package >> name and a local repository, I would expect MC to take the code it >> has locally and save it to my local drive, but apparently that's not >> what it does. >> >> There is no need for urgent action (this is only a drill<g>), but >> there should be some redundancy in where the code is stored, and MC >> should not prevent my saving code I already have to my local drive. >> There isn't (at least not that I can find), and it does :( >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Igor Stasenko

2009/11/9 Lukas Renggli <renggli(a)gmail.com>: >> If i understanding the problem clearly, MC checks the current contents >> of all repositories, defined for package, >> before saving a package, even locally. > > No. Monticello saves into the selected repository and into the local > package-cache only. This is the same as you get with Git (and other > similar distributed versioning systems), when you do a "git commit" > and "git push <repository>" . > Then how do you comment this: >I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the >package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but >apparently that's not what it does. >> So, if one of repositories can't be reached, this leads to error and >> unability to save a local copy on hard drive. > > Monticello only loads from a selected repository, it does not try > multiple repositories. It could lead to different results depending on > from what repository you load. Again that is the same same as with > "git pull <repository>". > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Schwab,Wilhelm K

Michael, Good point. Without starting a flame war, I find it necessary to give a big +1 to Pharo (the system and the people behind it) - I doubt I would be this far along in a move to Squeak. Servers quit (especially Windows boxes<g>), routers fail, and ISPs have bad days. The external world is not always visible. There is clearly a part of MC that does not anticipate these problems, and there need to be workarounds. It sounds like others have found them; I might build it into a future version of Migrate. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Monday, November 09, 2009 2:57 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) Lukas Renggli wrote: >> There is no need for urgent action (this is only a drill<g>), but >> there should be some redundancy in where the code is stored, and MC >> should not prevent my saving code I already have to my local drive. >> There isn't (at least not that I can find), and it does :( > > Parse error. > > Monticello is a distributed versioning system, so it is highly > redundant by definition. You can't really blame anybody else if a > version your are interested in is not reachable. I usually copy > important code into my local repository. Well, on the other hand it is extremely bad publicity if the Squeak community's main source repository, written in Squeak, is extremely unreliable. How can one expect someone to switch to Squeak when the first thing is encountering it being unreliable? Michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009

Re: [Pharo-project] Not a disaster (this time)

by Adrian Lienhard

We don't have any automated approach. All images built load from our own repository. If a developer wants to add an external package or update an existing one, he has to save into our repository. Adrian On Nov 9, 2009, at 21:01 , Schwab,Wilhelm K wrote: > Adrian, > > You are correct, it does contain them (thanks for mentioning that). > Saving my own copies _is_ a problem, but fortunately I do not need > to do so. > > How do you enforce local loads? Do you insist on downloading > everything yourselves, or do you have some type of lazy download > with cancel capability? In an ideal world, I would hope to see a > tool that tries to download the latest versions, shows progress > toward same, and accepts user interaction to head off a hopeless > situation like today. If the user cancels the download, then there > would be an option to install from the local repository. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Adrian Lienhard > Sent: Monday, November 09, 2009 2:31 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Not a disaster (this time) > > Hi Bill, > > At netstyle.ch and Cmsbox we have the rule that all projects have to > be completely loadable from our own MC repository. I suggest to do > the same for the reasons you mention below. You never know what > happens to external resources... > > Storing a local copy with MC should not be a problem. Actually, the > package-cache folder should already contain the file. > > Cheers, > Adrian > > On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: > >> Hello all, >> >> I am trying to be a good tester, and have been shot in the foot now >> for a couple of days. That's no great loss, but a similar set of >> circumstances could be very ugly in the future. My ailing build >> process for RC1 is thwarted by source.squeakfoundation.org's being >> offline. Imagine a deadline (paying customer, mission-critical >> gizmo, >> grant submission - whatever haunts you) and being stuck. >> >> I have even tried to save the FFI packages locally, and that seems to >> go haywire over talking to the server. Having chosen the package >> name >> and a local repository, I would expect MC to take the code it has >> locally and save it to my local drive, but apparently that's not what >> it does. >> >> There is no need for urgent action (this is only a drill<g>), but >> there should be some redundancy in where the code is stored, and MC >> should not prevent my saving code I already have to my local drive. >> There isn't (at least not that I can find), and it does :( >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2009