- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Reordering working directory mess

by Ben Coman

On Fri, Jun 24, 2016 at 4:21 AM, Nicolas Anquetil <nicolas.anquetil(a)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 > > >

June 24, 2016

GemStone/S 3.3.1 released

by Richard Sargent

Dear GemTalk Customers, We are pleased to announce the release of GemStone/S 64 Bit 3.3.1, a maintenance release providing a number of important features and bug fixes, including support for handling ICU library version changes over upgrade. We encourage all GemStone/S customers to upgrade to this release. Downloads and documentation for this release can be found at the following URL: http://gemtalksystems.com/products/gs64/ This server release includes the latest Visual Statistics Display (VSD) release, version 5.2, with new features and fixes in particular for working with multiple files. Documentation and VSD-only downloads, e.g. for platforms other than your server, can be found at the following URL: http://gemtalksystems.com/products/vsd/ Please contact GemTalk technical support if you have any trouble downloading or upgrading. Thank you! Note that GemStone/S ships with a free-even-for-commercial-use license. -- View this message in context: http://forum.world.st/GemStone-S-3-3-1-released-tp4902747.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 23, 2016

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