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

Re: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch

by Eliot Miranda

Hi Doru, On Thu, Jun 23, 2016 at 1:24 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > On Jun 20, 2016, at 10:07 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > > > On Mon, Jun 20, 2016 at 9:03 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > [â¦] > > Isnâ t that what the mail of clement was all about? To change the > compiler to emit code according to the proposed scheme? > > > > > > I think the question Tudor asked is: Is anyone willing to implement the > scheme I detailed ?\ > > Indeed, this is my question :). > I wil do a prototype in Squeak as soon as time is available (I have some Cadence things to finish first). Then I might try and do it in Pharo. > > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." > > > > > > -- _,,,^..^,,,_ best, Eliot

June 23, 2016

Re: [Pharo-dev] shit + double click on a category :)

by stepharo

I asked alain to integrate it into FastTable. Stef Le 22/6/16 Ã 16:21, Mariano Martinez Peck a Ã©crit : > Cool! I didn't know about it :) > > On Wed, Jun 22, 2016 at 10:54 AM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > We should call a method rename and class rename refactoring for > classes and methods and it will be gorgeous :) > > yes it is shift :) > > > Setf > > > Le 22/6/16 Ã 11:50, Denis Kudriashov a Ã©crit : >> Really nice. And I found that double click on method opens new >> browser on it. >> >> 2016-06-22 11:44 GMT+02:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> Hi guys >> >> alain showed me that click + double click on a category is >> really nice to rename a category. >> >> May be you knew it but this is nice. >> >> >> Stef >> >> >> > > > > > -- > Mariano > http://marianopeck.wordpress.com

June 23, 2016

Re: [Pharo-dev] senders seems broken

by stepharo

for me the finder dropbox did not work at all. Le 22/6/16 Ã 16:23, Nicolai Hess a Ã©crit : > broken, or a deprecation warning > > 2016-06-22 16:14 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Ok > > I'm in the train so I will not try to download it :) > > The finder is broken. We cannot use the dropdown. > > Do you know if it was fixed too. > > > Setf > > > Le 22/6/16 Ã 16:02, Marcus Denker a Ã©crit : > > There where bugs but they should be fixed in the latest version. > > (in 60105 it works for me again). > > On 22 Jun 2016, at 15:53, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi marcus > > can you browse senders? Because I cannot anymore. > > Stef > > > > > > >

June 23, 2016

Re: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch

by Tudor Girba

Hi, > On Jun 20, 2016, at 10:07 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > On Mon, Jun 20, 2016 at 9:03 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > [â¦] > Isnâ t that what the mail of clement was all about? To change the compiler to emit code according to the proposed scheme? > > > I think the question Tudor asked is: Is anyone willing to implement the scheme I detailed ?\ Indeed, this is my question :). Doru -- www.tudorgirba.com www.feenk.com "Value is always contextual."

June 23, 2016

Re: [Pharo-dev] Reordering working directory mess

by Nicolas Anquetil

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

June 23, 2016

Re: [Pharo-dev] Reordering working directory mess

by stepharo

Le 23/6/16 Ã 18:38, Esteban Lorenzano a Ã©crit : >> 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 pharo-cache > > 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 stepharo

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 >

June 23, 2016

Re: [Pharo-dev] Reordering working directory mess

by Ben Coman

On Fri, Jun 24, 2016 at 12:49 AM, Cyril Ferlicot D. < cyril.ferlicot(a)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

June 23, 2016

Re: [Pharo-dev] Reordering working directory mess

by Cyril Ferlicot D.

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

June 23, 2016

Re: [Pharo-dev] SessionManager and SystemSettings?

by Yuriy Tymchuk

> On 23 Jun 2016, at 15:32, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> 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 :) Are you talking about preferences or startup scripts? > >> >>> >> >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu <http://www.synectique.eu/> >> >> 165 Avenue Bretagne >> Lille 59000 France

June 23, 2016