June 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reordering working directory mess

by Esteban Lorenzano

> On 23 Jun 2016, at 17:34, Max Leske <maxleske(a)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(a)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 > >

June 23, 2016

Re: [Pharo-dev] Reordering working directory mess

by Esteban Lorenzano

> On 23 Jun 2016, at 17:29, Serge Stinckwich <serge.stinckwich(a)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(a)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/ >

June 23, 2016

Re: [Pharo-dev] Reordering working directory mess

by Max Leske

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(a)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

June 23, 2016

Re: [Pharo-dev] Reordering working directory mess

by Serge Stinckwich

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(a)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/

June 23, 2016

Reordering working directory mess

by Esteban Lorenzano

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

June 23, 2016

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

by Igor Stasenko

On 23 June 2016 at 16:19, J.F. Rick <self(a)je77.com> wrote: > Are .dmp files useful? If so, I can share those. I do still get crashes > but they are far less since I only use one surface. > > Another thing that is happening is that the form-based paints are sticking > around though the form should have been collected. It seems like the way > that paints are being handled is changing in Athens development. I tried > upgrading but that broke things. Is there a way I can be at the bleeding > edge and contribute back to the Athens development? I can't do anything on > the C side but I can contribute on the Smalltalk side. > > Unfortunately, i am not in the bussiness right now to help with your problem. And i cannot teach everyone how to handle problems with hanging pointers nor mentor people how to write code to prevent risk of their appearance in a first place. It is a common problem of every system with garbage collector under the hood.. now its time for Athens to face it. Oh well, one more, one less.. Such thing will keep popping up time to time around the place, unless people start to think before coding :) I guess, someone who made those changes could help you better. > Cheers, > > Jeff > > On Thu, Jun 23, 2016 at 7:11 AM Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 18 June 2016 at 19:36, J.F. Rick <self(a)je77.com> wrote: >> >>> I'm using Athens rendering for my multi-touch applications on Pharo5. As >>> part of that, I create a surface: >>> surface := AthensCairoSurface extent: bounds extent asIntegerPoint. >>> >>> Though the object creating that surface is deleted, the surface sticks >>> around. So, each time I run the app, I get another instance of >>> AthensCairoSurface hanging around. That means all the forms stick around as >>> well. So my image can quickly grow towards the 1GB size. >>> >>> Is there anything I can do about that? Can I manually get the surface >>> to delete itself? >>> >>> >> follow the pointers and look for the culprit, that holding it and not >> releasing. That's all i can advice. >> >> >>> Cheers, >>> >>> Jeff >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

June 23, 2016

Re: [Pharo-dev] SessionManager and SystemSettings?

by Cyril Ferlicot Delbecque

On 23/06/2016 15:32, Esteban Lorenzano wrote: > > no it shouldnâtâ¦ and *my* preferences are correctly loaded :) > > > I check on my Mac, mine are loaded too. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

June 23, 2016

Re: [Pharo-dev] SessionManager and SystemSettings?

by Esteban Lorenzano

> On 23 Jun 2016, at 15:29, Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com> wrote: > > > > On 23/06/2016 15:07, Christophe Demarey wrote: >> What happens if you execute >> 'SystemSettingsPersistence resumeSystemSettingsâ in a 60103 image? >> If nothing happens, it could be that 'SystemSettingsPersistence >> instVarNamed: âalreadyResumedââ is true >> >> I checked the startupList and PharoCommandLineHandler>>#runPreferences >> but nothing changed there. >> >> > > > I think I read something about a script esteban added to clear the > ever-growing stack. Couldn't it be that? Maybe it open the image and the > system setting think he already loaded the settings. no it shouldnâtâ¦ and *my* preferences are correctly loaded :) > >> > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France >

June 23, 2016

Re: [Pharo-dev] SessionManager and SystemSettings?

by Cyril Ferlicot Delbecque

On 23/06/2016 15:07, Christophe Demarey wrote: > What happens if you execute > 'SystemSettingsPersistence resumeSystemSettingsâ in a 60103 image? > If nothing happens, it could be that 'SystemSettingsPersistence > instVarNamed: âalreadyResumedââ is true > > I checked the startupList and PharoCommandLineHandler>>#runPreferences > but nothing changed there. > > I think I read something about a script esteban added to clear the ever-growing stack. Couldn't it be that? Maybe it open the image and the system setting think he already loaded the settings. > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

June 23, 2016

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

by J.F. Rick

Are .dmp files useful? If so, I can share those. I do still get crashes but they are far less since I only use one surface. Another thing that is happening is that the form-based paints are sticking around though the form should have been collected. It seems like the way that paints are being handled is changing in Athens development. I tried upgrading but that broke things. Is there a way I can be at the bleeding edge and contribute back to the Athens development? I can't do anything on the C side but I can contribute on the Smalltalk side. Cheers, Jeff On Thu, Jun 23, 2016 at 7:11 AM Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 June 2016 at 19:36, J.F. Rick <self(a)je77.com> wrote: > >> I'm using Athens rendering for my multi-touch applications on Pharo5. As >> part of that, I create a surface: >> surface := AthensCairoSurface extent: bounds extent asIntegerPoint. >> >> Though the object creating that surface is deleted, the surface sticks >> around. So, each time I run the app, I get another instance of >> AthensCairoSurface hanging around. That means all the forms stick around as >> well. So my image can quickly grow towards the 1GB size. >> >> Is there anything I can do about that? Can I manually get the surface to >> delete itself? >> >> > follow the pointers and look for the culprit, that holding it and not > releasing. That's all i can advice. > > >> Cheers, >> >> Jeff >> > > > > -- > Best regards, > Igor Stasenko. >

June 23, 2016