Reordering working directory mess
Locked
12
12
 
|
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 |
Re: Reordering working directory mess
|
|
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 <[hidden email]> 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/ |
|
|
In reply to this post by EstebanLM
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 <[hidden email]> 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 |
|
|
In reply to this post by SergeStinckwich
> On 23 Jun 2016, at 17:29, Serge Stinckwich <[hidden email]> 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 <[hidden email]> 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/ > |
|
|
In reply to this post by Max Leske
> On 23 Jun 2016, at 17:34, Max Leske <[hidden email]> 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 <[hidden email]> 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 > > |
Re: Reordering working directory mess
|
|
In reply to this post by EstebanLM
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? > `pharo` is maybe a little too common. What about `pharo-local`? > Esteban > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France |
signature.asc (836 bytes) |
|
On Fri, Jun 24, 2016 at 12:49 AM, Cyril Ferlicot D. <[hidden email]> wrote:
Agreed. What about `pharo-local`? Or pharodata... cheers -ben |
|
|
In reply to this post by EstebanLM
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 > |
|
|
In reply to this post by EstebanLM
Le 23/6/16 à 18:38, Esteban Lorenzano a écrit : >> On 23 Jun 2016, at 17:34, Max Leske <[hidden email]> 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 <[hidden email]> 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 >> > > |
Re: Reordering working directory mess
|
|
In reply to this post by stepharo
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 <[hidden email]> wrote: and why not put Pharo.changes in ./pharo while we are at it ? 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
|
|
|
In reply to this post by stepharo
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 <[hidden email]> 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 >> > > |
Re: Reordering working directory mess
|
|
In reply to this post by stepharo
Hi,
> On Jun 23, 2016, at 10:18 PM, stepharo <[hidden email]> 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 :)
|
|
|
My hero! :)
|
|
|
In reply to this post by EstebanLM
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 <[hidden email]> wrote: Hi, Javier Pimás Ciudad de Buenos Aires |
Re: Reordering working directory mess
|
|
This is already possible to have a shared directory for all the *.mcz
of your images. On 6/24/16, Javier Pimás <[hidden email]> 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 <[hidden email]> > 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/ |
Re: Reordering working directory mess
|
|
In reply to this post by melkyades
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 <[hidden email]> 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 <[hidden email]> 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 |
Re: Reordering working directory mess
|
|
In reply to this post by melkyades
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 <[hidden email]> wrote:
|
|
|
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
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |