Reordering working directory mess
Hi, Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this: Pharo.image Pharo.changes PharoDebug.log pharo-cache now we have: Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory: Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir). of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory. so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like: Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc. well⦠I will commit a SLICE with the changes soon (is not a hard change at all). But then: is ./pharo a good name? will this work? Esteban
The name is .pharo or pharo ? If we have multiple images in the same directory, they will share the /pharo repository ? On 6/23/16, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
On 23 Jun 2016, at 17:29, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
The name is .pharo or pharo ?
If we have multiple images in the same directory, they will share the /pharo repository ?
yes, exactly as it is now, that you share all those common files/directories Esteban
On 6/23/16, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
I totally approve of the idea but personally I hate those hidden directories. Especially those that are silently generated in my home directory. It may not look so âprofessionalâ as Eclipse (â¦) but Iâd rather have a visible directory. Just my two cents. Max
On 23 Jun 2016, at 17:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
On 23 Jun 2016, at 17:34, Max Leske <maxleske@gmail.com> wrote:
I totally approve of the idea but personally I hate those hidden directories. Especially those that are silently generated in my home directory. It may not look so âprofessionalâ as Eclipse (â¦) but Iâd rather have a visible directory.
names as⦠? :P Esteban
Just my two cents.
Max
On 23 Jun 2016, at 17:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
Le 23/6/16 à 18:38, Esteban Lorenzano a écrit :
On 23 Jun 2016, at 17:34, Max Leske <maxleske@gmail.com> wrote:
I totally approve of the idea but personally I hate those hidden directories. Especially those that are silently generated in my home directory. It may not look so âprofessionalâ as Eclipse (â¦) but Iâd rather have a visible directory. names as⦠? :P
pharo-cache
Esteban
Just my two cents.
Max
On 23 Jun 2016, at 17:22, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
Le 23/06/2016 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
+10000 for the reordering :) `pharo` is maybe a little too common. What about `pharo-local`?
Esteban
-- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
On Fri, Jun 24, 2016 at 12:49 AM, Cyril Ferlicot D. < cyril.ferlicot@gmail.com> wrote:
Le 23/06/2016 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
+10000 for the reordering :)
`pharo` is maybe a little too common.
Agreed.
What about `pharo-local`?
Or pharodata... cheers -ben
What is the difference between play-cache play-stash Stef Le 23/6/16 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
and why not put Pharo.changes in ./pharo while we are at it ? too difficult? nicolas On 23/06/2016 22:18, stepharo wrote:
What is the difference between play-cache play-stash
Stef
Le 23/6/16 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Nicolas Anquetil RMod team -- Inria Lille
On Fri, Jun 24, 2016 at 4:21 AM, Nicolas Anquetil <nicolas.anquetil@inria.fr
wrote:
and why not put Pharo.changes in ./pharo while we are at it ? too difficult?
The same thought crossed my mind for a moment, but the two files are *tightly* coupled. If the .changes file wasn't sitting there right next to the .image file, many newcomers will forget to copy them together - and even for the rest of us, its more pain to select two files in different directories and copy them to two other directories, than if they are together. cheers -ben
nicolas
On 23/06/2016 22:18, stepharo wrote:
What is the difference between play-cache play-stash
Stef
Le 23/6/16 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Nicolas Anquetil RMod team -- Inria Lille
play-cache contains history from default playground. play-stash contains state of playground pages (if you rename "playgroundâ tab into something else it becomes a custom page. You can look it up with spotter) Uko
On 23 Jun 2016, at 22:18, stepharo <stepharo@free.fr> wrote:
What is the difference between play-cache play-stash
Stef
Le 23/6/16 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
Hi,
On Jun 23, 2016, at 10:18 PM, stepharo <stepharo@free.fr> wrote:
What is the difference between play-cache play-stash
- play-cache is populated automatically when you work in the playground. - play-stash stores only the pages that you gave concrete names to. You can double click on the tab with the name of a page and you can give it another name than Untitled. In this case, the file is copied in the play-stash folder and you can search for it by name. For example, using this mechanism you can name a script that you use for loading a piece of code and find it from spotter. Cheers, Doru
Stef
Le 23/6/16 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."
so, pharo-local will be. but regular convention is to store this kind of data into a hidden directory (hence it would be .pharo-local, maybe)⦠but I understand the opposition I will let it visible and we can re-check later. now, tool makers, please take into account the new FileLocator localDirectory Esteban ps: and yes, Iâm adding a setting so you can modify default local directory :)
On 24 Jun 2016, at 11:35, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jun 23, 2016, at 10:18 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
What is the difference between play-cache play-stash
- play-cache is populated automatically when you work in the playground. - play-stash stores only the pages that you gave concrete names to. You can double click on the tab with the name of a page and you can give it another name than Untitled. In this case, the file is copied in the play-stash folder and you can search for it by name. For example, using this mechanism you can name a script that you use for loading a piece of code and find it from spotter.
Cheers, Doru
Stef
Le 23/6/16 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Every thing should have the right to be different."
On 24 Jun 2016, at 14:36, Esteban Lorenzano <estebanlm@gmail.com> wrote:
so, pharo-local will be. but regular convention is to store this kind of data into a hidden directory (hence it would be .pharo-local, maybe)⦠but I understand the opposition I will let it visible and we can re-check later.
My hero! :)
now, tool makers, please take into account the new
FileLocator localDirectory
Esteban
ps: and yes, Iâm adding a setting so you can modify default local directory :)
On 24 Jun 2016, at 11:35, Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote:
Hi,
On Jun 23, 2016, at 10:18 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
What is the difference between play-cache play-stash
- play-cache is populated automatically when you work in the playground. - play-stash stores only the pages that you gave concrete names to. You can double click on the tab with the name of a page and you can give it another name than Untitled. In this case, the file is copied in the play-stash folder and you can search for it by name. For example, using this mechanism you can name a script that you use for loading a piece of code and find it from spotter.
Cheers, Doru
Stef
Le 23/6/16 à 17:22, Esteban Lorenzano a écrit :
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Every thing should have the right to be different."
I don't know for the new directories, but I always thought that it would be nice to have package-cache in ~/.pharo or a place shared by all images, to avoid redownloading all .MCZs from other projects each time you launch pharo from a different directory. Cheers! Pocho On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Javier Pimás Ciudad de Buenos Aires
This is already possible to have a shared directory for all the *.mcz of your images. On 6/24/16, Javier Pimás <elpochodelagente@gmail.com> wrote:
I don't know for the new directories, but I always thought that it would be nice to have package-cache in ~/.pharo or a place shared by all images, to avoid redownloading all .MCZs from other projects each time you launch pharo from a different directory.
Cheers! Pocho
On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Javier Pimás Ciudad de Buenos Aires
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
This is optional (some people want it, others not) System settings > Monticello > Local cache directory MCCacheDirectory class>>#cacheDirectory:
On 24 Jun 2016, at 15:54, Javier Pimás <elpochodelagente@gmail.com> wrote:
I don't know for the new directories, but I always thought that it would be nice to have package-cache in ~/.pharo or a place shared by all images, to avoid redownloading all .MCZs from other projects each time you launch pharo from a different directory.
Cheers! Pocho
On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote: Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Javier Pimás Ciudad de Buenos Aires
I agree with Javier, it would be much nicer to have only one shared package cache and, while I understand that there might be people not wanting that, I don't see why it couldn't be the default behavior. I think that it would be a reasonable default, don't you? On Fri, Jun 24, 2016 at 3:54 PM, Javier Pimás <elpochodelagente@gmail.com> wrote:
I don't know for the new directories, but I always thought that it would be nice to have package-cache in ~/.pharo or a place shared by all images, to avoid redownloading all .MCZs from other projects each time you launch pharo from a different directory.
Cheers! Pocho
On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Javier Pimás Ciudad de Buenos Aires
On 24 Jun 2016, at 18:14, Nicolas Passerini <npasserini@gmail.com> wrote:
I agree with Javier, it would be much nicer to have only one shared package cache and, while I understand that there might be people not wanting that, I don't see why it couldn't be the default behavior. I think that it would be a reasonable default, don't you?
I agree⦠but where to store them? same place as âpreferencesâ? real problem with this is that you reduce a little bit âportabilityâ of Pharo, because you store files outside the root directory⦠but we already do that, so I would agree :P Esteban
On Fri, Jun 24, 2016 at 3:54 PM, Javier Pimás <elpochodelagente@gmail.com <mailto:elpochodelagente@gmail.com>> wrote: I don't know for the new directories, but I always thought that it would be nice to have package-cache in ~/.pharo or a place shared by all images, to avoid redownloading all .MCZs from other projects each time you launch pharo from a different directory.
Cheers! Pocho
On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Javier Pimás Ciudad de Buenos Aires
Can't this be accomplished today with a symbolic link to a package directory somewhere on your HD? e.g. rm -rf package-cache ln -s /path/to/my/common/package/repo package-cache Works for me at least. Nicolas Passerini wrote
I agree with Javier, it would be much nicer to have only one shared package cache and, while I understand that there might be people not wanting that, I don't see why it couldn't be the default behavior. I think that it would be a reasonable default, don't you?
On Fri, Jun 24, 2016 at 3:54 PM, Javier Pimás <
elpochodelagente@
> wrote:
I don't know for the new directories, but I always thought that it would be nice to have package-cache in ~/.pharo or a place shared by all images, to avoid redownloading all .MCZs from other projects each time you launch pharo from a different directory.
Cheers! Pocho
On Thu, Jun 23, 2016 at 12:22 PM, Esteban Lorenzano <
estebanlm@
>
wrote:
Hi,
Since some time Iâve seen growing the amount of files/directories generated when running Pharo. Up to Pharo 2.0, we had just this:
Pharo.image Pharo.changes PharoDebug.log pharo-cache
now we have:
Pharo.image Pharo.changes PharoDebug.log pharo-cache epicea-sessions play-cache play-stash
it does not looks like much, but I think this does not looks professional (we take too much from user space). So I proposed (and implemented) a âconcentratorâ directory:
Pharo.image Pharo.changes ./pharo ⦠and everything for âpharo working internallyâ here
then users have again control about what they have along with the image (this allows to some nice strategies too, when we want a version that does not pollutes the file dir).
of course, this idea follows other developing spaces, where things are stored in same fashion way⦠for example in eclipse for java they store all eclipse data under .workspace directory.
so, please note that this is NOT user space⦠regular pharo users will store his files along with the image, for instance filetree repositories⦠something like:
Pharo.image Pharo.changes .pharo/ voyage/ punqlite/ etc.
well⦠I will commit a SLICE with the changes soon (is not a hard change at all).
But then:
is ./pharo a good name? will this work?
Esteban
-- Javier Pimás Ciudad de Buenos Aires
-- View this message in context: http://forum.world.st/Reordering-working-directory-mess-tp4902671p4903118.ht... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (14)
-
Ben Coman -
Cyril Ferlicot D. -
Esteban Lorenzano -
Javier Pimás -
Max Leske -
Nicolas Anquetil -
Nicolas Passerini -
Paul DeBruicker -
Serge Stinckwich -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Tudor Girba -
Yuriy Tymchuk