Re: [Pharo-project] Setting MC cache directory (was renggli mirror created on smalltalkhub)
package-cache, the .m2 of Pharo... But .m2 is under ~ by default. Why couldn't package-cache be like that on *nix by default and under the %USERPROFILE% on Windows? Phil 2012/7/4 Torsten Bergmann asta...@gmx.de Friedrich Dominicus wrote Another stuff I simply do not get is package-cache. Why is it local to every other Pharo image? Why can't I say drop all below package-cache on my machine that's it. Usually one pharo installation does not know about the other if you just unzip. So the cache is by default relative to the installation. Thats the same in Eclipse and other IDE's. If you want you can set a common directory for all images using MCCacheRepositorydefault: Since it would be better to have a setting in the Settings browser I opened http://code.google.com/p/pharo/issues/detail?id=6260 and fixed it for Pharo 2.0 in SLICE-Issue-6260-Monticello-cache-location-should-be-configurable-tbn.1 Please test on different patforms for integration. Thx T. -
Re: [Pharo-project] Setting MC cache directory
Torsten Bergmann asta...@gmx.de writes: Friedrich Dominicus wrote Another stuff I simply do not get is package-cache. Why is it local to every other Pharo image? Why can't I say drop all below package-cache on my machine that's it. Usually one pharo installation does not know about the other if you just unzip. So the cache is by default relative to the installation. Thats the same in Eclipse and other IDE's. If you want you can set a common directory for all images using MCCacheRepositorydefault: Well this is not there at least in Pharo 1.3. I found it in Pharo 2.0 So well helped myself with the symbolic links. How nice Unices sometimes are ;-) Since it would be better to have a setting in the Settings browser I opened http://code.google.com/p/pharo/issues/detail?id=6260 and fixed it for Pharo 2.0 in SLICE-Issue-6260-Monticello-cache-location-should-be-configurable-tbn.1 Ok, I see, one has to use Pharo 2.0 and the most actual Monticello to make something out of a SLICE. Another thing learned today. Regards Friedrich
Re: [Pharo-project] Setting MC cache directory (was renggli mirror created on smalltalkhub)
On Wed, Jul 4, 2012 at 5:28 PM, p...@highoctane.be p...@highoctane.be wrote: package-cache, the .m2 of Pharo... But .m2 is under ~ by default. Why couldn't package-cache be like that on *nix by default and under the %USERPROFILE% on Windows? because maven does not use standard mechanisms: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry
Re: [Pharo-project] Setting MC cache directory (was renggli mirror created on smalltalkhub)
Well, these so-called standards are well and nice but frankly, even my vim editor uses the same as maven and friends. Some examples: .m2, .mc, .inkscape, .subversion, .hg, .gitconfig, .Xcode, .cache, .cups, .wireshark, .netbeans All in my ~ on *nix and in %USERPROFILE% on Windows There are standards and defacto standards. I am with the second ones. Having package-cache embedded inside the application on OSX is plain ugly. Like storing your data in Program Files. Erk! Anyway, I can put it where I want on my own, so let's end this thread. Phil 2012/7/4 Damien Cassou damien.cas...@gmail.com On Wed, Jul 4, 2012 at 5:28 PM, p...@highoctane.be p...@highoctane.be wrote: package-cache, the .m2 of Pharo... But .m2 is under ~ by default. Why couldn't package-cache be like that on *nix by default and under the %USERPROFILE% on Windows? because maven does not use standard mechanisms: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry
Re: [Pharo-project] Setting MC cache directory (was renggli mirror created on smalltalkhub)
On 2012-07-04, at 17:36, Torsten Bergmann wrote: Camillo wrote: Here in lille almost everybody sets up symlinks to have a single shared instance of a package-cache :) This should be part of the past if issue #6260 is integrated (see [1]) The monkey is here no very helpful for the fix - since it laments on test that were red before and sets the issue state to WorkNeeded. I'll put ben on it to see what the problem with the monkey is. We run tests twice, once before and once after loading to avoid issues with existing failing tests, so this behavior is rather strange :) Any real person able to review and integrate it? There is also Marianos solution, see [2] Bye T. [1] http://code.google.com/p/pharo/issues/detail?id=6260 [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067083.html
Re: [Pharo-project] Setting MC cache directory (was renggli mirror created on smalltalkhub)
On Jul 4, 2012, at 6:02 PM, Camillo Bruni wrote: On 2012-07-04, at 17:36, Torsten Bergmann wrote: Camillo wrote: Here in lille almost everybody sets up symlinks to have a single shared instance of a package-cache :) This should be part of the past if issue #6260 is integrated (see [1]) The monkey is here no very helpful for the fix - since it laments on test that were red before and sets the issue state to WorkNeeded. I'll put ben on it to see what the problem with the monkey is. We run tests twice, once before and once after loading to avoid issues with existing failing tests, so this behavior is rather strange :) Take care that the MC tests are not immune to be rune twice. (they are actually so brittle and complex that I sometimes think we should just delete them). Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] Setting MC cache directory (was renggli mirror created on smalltalkhub)
On Wed, Jul 4, 2012 at 6:02 PM, Camillo Bruni camillobr...@gmail.comwrote: On 2012-07-04, at 17:36, Torsten Bergmann wrote: Camillo wrote: Here in lille almost everybody sets up symlinks to have a single shared instance of a package-cache :) This should be part of the past if issue #6260 is integrated (see [1]) The monkey is here no very helpful for the fix - since it laments on test that were red before and sets the issue state to WorkNeeded. I'll put ben on it to see what the problem with the monkey is. We run tests twice, the second run should be in a clean image (not where the first run was done). Is it like that now? once before and once after loading to avoid issues with existing failing tests, so this behavior is rather strange :) Any real person able to review and integrate it? There is also Marianos solution, see [2] Bye T. [1] http://code.google.com/p/pharo/issues/detail?id=6260 [2] http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067083.html -- Mariano http://marianopeck.wordpress.com
