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

Re: [Pharo-dev] [Vm-dev] Working OSProcess configuration for Pharo 6 release (please)

by Esteban Lorenzano

> On 21 Jun 2017, at 23:07, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Cyril, Hi Alex, > > On Tue, Jun 20, 2017 at 8:08 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: > On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > Hi ClÃ©ment > > > > > > That was a mistake of mine. In the current VM it now answers e.g. 1011.6 and so things should be working again. > > > > Hi! > > The problem is that the stable vm does not have the fix and the > current latest vm is **reeeeeeeeally* slow. It happens at least on > OSX. I don't know if it is a known problem or if it comes from the > opensmalltalk build or the pharo build. > > I found and fixed the problem just now. See > > opensmalltalk-vm/Cog > commit f54456fc05c1846bb7e553c6ff5fec9f700abdae > > Author: Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> > Date: Wed Jun 21 11:17:25 2017 -0700 > > CogVM source as per VMMaker.oscog-eem.2244 > > Spur: Fix regression in VMMaker.oscog-eem.2237. sufficientSpaceAfterGC: must > compute heapSizePostGC using totalOldSpaceCapacity instead of the old broken > segment-insensitive endOfMemory - nilObj, otherwise as soon as a segment is > added it's quite possible that there will be a full GC after each scavenge. > > So the latest VMs should be back to normal. yes that should. I just need to promote them as âstableâ :P Esteban > > I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/ <http://files.pharo.org/vm/pharo-spur32/mac/> > > > > -- > Cyril Ferlicot > https://ferlicot.fr <https://ferlicot.fr/> > > http://www.synectique.eu <http://www.synectique.eu/> > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > > > > > -- > _,,,^..^,,,_ > best, Eliot

June 21, 2017

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

by Eliot Miranda

Hi Cyril, Hi Alex, On Tue, Jun 20, 2017 at 8:08 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi ClÃ©ment > > > > > > That was a mistake of mine. In the current VM it now answers e.g. > 1011.6 and so things should be working again. > > > > Hi! > > The problem is that the stable vm does not have the fix and the > current latest vm is **reeeeeeeeally* slow. It happens at least on > OSX. I don't know if it is a known problem or if it comes from the > opensmalltalk build or the pharo build. > I found and fixed the problem just now. See opensmalltalk-vm/Cog commit f54456fc05c1846bb7e553c6ff5fec9f700abdae Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: Wed Jun 21 11:17:25 2017 -0700 CogVM source as per VMMaker.oscog-eem.2244 Spur: Fix regression in VMMaker.oscog-eem.2237. sufficientSpaceAfterGC: must compute heapSizePostGC using totalOldSpaceCapacity instead of the old broken segment-insensitive endOfMemory - nilObj, otherwise as soon as a segment is added it's quite possible that there will be a full GC after each scavenge. So the latest VMs should be back to normal. > I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/ > > > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > > -- _,,,^..^,,,_ best, Eliot

June 21, 2017

Re: [Pharo-dev] New User and the Rectangle class.

by Trey Tomes

Chris/Peter: Thank you for taking the time to respond. It's good to know that I'm not the only one to encounter this problem. Chris: Thank you for the reference to the topLeftOffset:bottomRightOffset: API, that resolved my problem really well. I'm glad to have a solution that doesn't have me modifying base classes every time I open a fresh image. Thanks, Trey On Wed, Jun 21, 2017 at 6:00 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > iirc there was proposal to rename Rectangle to DisplayRectangle (or > something like that), because you are certainly not the first one to run > into such trouble. > > P > > > On Tue, Jun 20, 2017 at 04:03:48PM -0700, Chris Cunningham wrote: > > Hi Trey, > > I can't find the rational written down why Rectangle was changed > (although > > it WAS written down). If I remember right, the rational was roughly > > "Rectangles represent areas of the screen. As such, they should be 'well > > formed'- positive width and height only". > > In any case, going back through the archives, I found this bit of advice: > > > > " > > You need to use a different API: for example: > > > > frame := (0 @ 0 corner: 1.0 @ 1.0) asLayoutFrame topLeftOffset: 0 @ 50; > > bottomRightOffset: 0@50 negated. > > " > > > > Thanks, > > -cbc > > > > On Tue, Jun 20, 2017 at 3:10 PM, Trey Tomes <trey.tomes(a)gmail.com> > wrote: > > > > > Hello! > > > > > > I'm new to this list, so I apologize if this topic has already been > > > considered. > > > > > > I have been re-creating the Laser Game tutorial in Pharo 6, and have > > > encountered something that may be an error within Pharo. > > > > > > The LayoutFrame has the ability to use negative values for the bottom > and > > > right sides of the rectangle assigned to the offsets, e.g. > > > > > > LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@ > > > -4)). > > > > > > This is useful, as it allows the system to automatically calculate the > > > margins inset from the bottom and right sides of the container. > > > > > > In Pharo 6, this does not work. The setLeft:right:top:bottom: and > > > setPoint:point: messages both use the min: and max: messages to > rearrange > > > the Rectangle so that the smallest numbers get pushed to the top and > left. > > > > > > In order to get things to render correctly in my system, I had to > change > > > these messages to look like this: > > > > > > setLeft: left right: right top: top bottom: bottom > > > self setPoint: (left@top) point: (right@bottom). > > > setPoint: pt1 point: pt2 > > > origin := pt1. > > > corner := pt2. > > > > > > > > > In place of this: > > > > > > setLeft: left right: right top: top bottom: bottom > > > origin := (left min: right) @ (top min: bottom). > > > corner := (left max: right) @ (top max: bottom). > > > setPoint: pt1 point: pt2 > > > origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). > > > corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y). > > > > > > > > > I haven't found any bad side-effects to changing this yet, but is > there a > > > reason the Rectangle class was changed? > > > > > > Thanks, > > > Trey > > > > >

June 21, 2017

Pharo Monthly Newsletter June

by Marcus Denker

Hi, The Pharo Monthly Newsletter for June will be send out Friday. You can subscribe here to get it delivered by email: http://us11.campaign-archive1.com/home/?u=6f667565c2569234585a7be77&id=0486… <http://us11.campaign-archive1.com/home/?u=6f667565c2569234585a7be77&id=0486…> If someone has ideas for topics for the next newsletters, please send them to me. Marcus

June 21, 2017

Re: [Pharo-dev] New User and the Rectangle class.

by Peter Uhnak

iirc there was proposal to rename Rectangle to DisplayRectangle (or something like that), because you are certainly not the first one to run into such trouble. P On Tue, Jun 20, 2017 at 04:03:48PM -0700, Chris Cunningham wrote: > Hi Trey, > I can't find the rational written down why Rectangle was changed (although > it WAS written down). If I remember right, the rational was roughly > "Rectangles represent areas of the screen. As such, they should be 'well > formed'- positive width and height only". > In any case, going back through the archives, I found this bit of advice: > > " > You need to use a different API: for example: > > frame := (0 @ 0 corner: 1.0 @ 1.0) asLayoutFrame topLeftOffset: 0 @ 50; > bottomRightOffset: 0@50 negated. > " > > Thanks, > -cbc > > On Tue, Jun 20, 2017 at 3:10 PM, Trey Tomes <trey.tomes(a)gmail.com> wrote: > > > Hello! > > > > I'm new to this list, so I apologize if this topic has already been > > considered. > > > > I have been re-creating the Laser Game tutorial in Pharo 6, and have > > encountered something that may be an error within Pharo. > > > > The LayoutFrame has the ability to use negative values for the bottom and > > right sides of the rectangle assigned to the offsets, e.g. > > > > LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@ > > -4)). > > > > This is useful, as it allows the system to automatically calculate the > > margins inset from the bottom and right sides of the container. > > > > In Pharo 6, this does not work. The setLeft:right:top:bottom: and > > setPoint:point: messages both use the min: and max: messages to rearrange > > the Rectangle so that the smallest numbers get pushed to the top and left. > > > > In order to get things to render correctly in my system, I had to change > > these messages to look like this: > > > > setLeft: left right: right top: top bottom: bottom > > self setPoint: (left@top) point: (right@bottom). > > setPoint: pt1 point: pt2 > > origin := pt1. > > corner := pt2. > > > > > > In place of this: > > > > setLeft: left right: right top: top bottom: bottom > > origin := (left min: right) @ (top min: bottom). > > corner := (left max: right) @ (top max: bottom). > > setPoint: pt1 point: pt2 > > origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). > > corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y). > > > > > > I haven't found any bad side-effects to changing this yet, but is there a > > reason the Rectangle class was changed? > > > > Thanks, > > Trey > >

June 21, 2017

Re: [Pharo-dev] How can I save changes on memory ?

by Marcus Denker

> On 20 Jun 2017, at 14:54, JÃ©rÃ©mie Regnault <jeremie.regnault(a)outlook.com> wrote: > > Hi, > > I would like to know how to save modifications (e.g creating a > class/method ) in the memory. > Classes: - Definitions: Classes are already in memory: the definition you see in the browser are kind of âdecompiledâ (created by the class object). Object definition - in addition it is logged to the .changes, but that is not needed to look at a class, it is just logged to have it in case of a crash before the image is saved. - Comments: they are in the .changes or .sources, classes point to them (via the organiser) using a RemoteString. (this is done by the class ClassOrganization ) Methods. - When you compile they point to the .changes or .sources via an offset that is at the end of the bytecode (the so called trailer). - there is code in the system to store instead of that pointer the whole code in the trailer. - methods can be created with embedded sources (not needing to store in .changes) by calling #generateWithSource instead of #generate on the AST root node. (this is used for Doit compilation right now). Methods that use a source pointer can be converted by calling #embeddSourceInTrailer on them. Marcus

June 21, 2017

Re: [Pharo-dev] GitHub survey on open source projects

by Ben Coman

Thanks for your comments Cesar. Please also take care when replying to a digest to trim the trailing posts that are unrelated. cheers -ben On Wed, Jun 21, 2017 at 5:18 AM, <csrabak(a)bol.com.br> wrote: <snip> > -- > Cesar Rabak > Date: Tue, 20 Jun 2017 11:17:59 +0200 > From: "phil(a)highoctane.be" <phil(a)highoctane.be> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] GitHub survey on open source projects > Message-ID: > <CAMynPtwcGZv2KO==PeKxU=wwDMd7WRjY0TgVEHcqKFG=10yFGQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > <snip> > On Tue, Jun 20, 2017 at 9:52 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > <snip> > > > > Am 19.06.2017 um 20:05 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > Not sure how much this reflects our communities but this is interesting. > > > > > > GitHub Survey: Open Source Is Popular, Plagued by Poor Docs and Rude > People > > > > https://adtmag.com/articles/2017/06/05/open-source-survey.aspx > > <https://adtmag.com/articles/2017/06/05/open-source-survey.aspx?m=1> > > > > _,,,^..^,,,_ i.e. from here down... > Message: 10 > Date: Tue, 20 Jun 2017 12:54:26 +0000 > From: J?r?mie Regnault <jeremie.regnault(a)outlook.com> > To: "pharo-dev(a)lists.pharo.org" <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] How can I save changes on memory ? > Message-ID: > <AM3PR03MB083857B6104BA48E7D86DA2499C50@AM3PR03MB0838. > eurprd03.prod.outlook.com> > > <snip> > ------------------------------ > > Message: 11 > Date: Tue, 20 Jun 2017 15:10:49 +0200 > From: Cl?ment Bera <bera.clement(a)gmail.com> > To: Discusses Development of Pharo <pharo-dev(a)lists.pharo.org> > Cc: Thierry Goubier <thierry.goubier(a)cea.fr> > Subject: [Pharo-dev] Working OSProcess configuration for Pharo 6 release > (please) > Message-ID: > <CAJrdCbU6x6X0CBkgSf4XEeVw35PFn+sHfvTrdA_btDJU_Wun9w(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > <snip> > ------------------------------ > > Message: 12 > Date: Tue, 20 Jun 2017 08:04:45 -0700 > From: Eliot Miranda <eliot.miranda(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 > release (please) > Message-ID: <C3FD57E0-BC08-482F-A866-4979403827D9(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > <snip> > ------------------------------ > > Message: 13 > Date: Tue, 20 Jun 2017 17:06:40 +0200 > From: Marcus Denker <marcus.denker(a)inria.fr> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: Thierry Goubier <thierry.goubier(a)cea.fr> > Subject: Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 > release (please) > Message-ID: <2F34707C-1194-4C03-AC23-E8B55899BE6A(a)inria.fr> > Content-Type: text/plain; charset="utf-8" > > <snip> > ------------------------------ > > Message: 14 > Date: Tue, 20 Jun 2017 17:08:35 +0200 > From: Cyril Ferlicot <cyril.ferlicot(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 > release (please) > Message-ID: > <CAMyorgBfSy-PZuMmh=+WSM63bKiEcJSM5E7Jbr8GbaMqv1Ki7w(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > <snip> > ------------------------------ > > Message: 15 > Date: Tue, 20 Jun 2017 17:51:06 +0200 > From: Cl?ment Bera <bera.clement(a)gmail.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 > release (please) > Message-ID: > <CAJrdCbXP9AGABXhdM=tE1OTkJODjM-yrqaddFx22_3qrKsGwmA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > <snip> > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Pharo-dev mailing list > Pharo-dev(a)lists.pharo.org > http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org > > > ------------------------------ > > End of Pharo-dev Digest, Vol 50, Issue 24 > ***************************************** >

June 21, 2017

Re: [Pharo-dev] New User and the Rectangle class.

by Chris Cunningham

Hi Trey, I can't find the rational written down why Rectangle was changed (although it WAS written down). If I remember right, the rational was roughly "Rectangles represent areas of the screen. As such, they should be 'well formed'- positive width and height only". In any case, going back through the archives, I found this bit of advice: " You need to use a different API: for example: frame := (0 @ 0 corner: 1.0 @ 1.0) asLayoutFrame topLeftOffset: 0 @ 50; bottomRightOffset: 0@50 negated. " Thanks, -cbc On Tue, Jun 20, 2017 at 3:10 PM, Trey Tomes <trey.tomes(a)gmail.com> wrote: > Hello! > > I'm new to this list, so I apologize if this topic has already been > considered. > > I have been re-creating the Laser Game tutorial in Pharo 6, and have > encountered something that may be an error within Pharo. > > The LayoutFrame has the ability to use negative values for the bottom and > right sides of the rectangle assigned to the offsets, e.g. > > LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@ > -4)). > > This is useful, as it allows the system to automatically calculate the > margins inset from the bottom and right sides of the container. > > In Pharo 6, this does not work. The setLeft:right:top:bottom: and > setPoint:point: messages both use the min: and max: messages to rearrange > the Rectangle so that the smallest numbers get pushed to the top and left. > > In order to get things to render correctly in my system, I had to change > these messages to look like this: > > setLeft: left right: right top: top bottom: bottom > self setPoint: (left@top) point: (right@bottom). > setPoint: pt1 point: pt2 > origin := pt1. > corner := pt2. > > > In place of this: > > setLeft: left right: right top: top bottom: bottom > origin := (left min: right) @ (top min: bottom). > corner := (left max: right) @ (top max: bottom). > setPoint: pt1 point: pt2 > origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). > corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y). > > > I haven't found any bad side-effects to changing this yet, but is there a > reason the Rectangle class was changed? > > Thanks, > Trey >

June 20, 2017

New User and the Rectangle class.

by Trey Tomes

Hello! I'm new to this list, so I apologize if this topic has already been considered. I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo. The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g. LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@-4)). This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container. In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left. In order to get things to render correctly in my system, I had to change these messages to look like this: setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom). setPoint: pt1 point: pt2 origin := pt1. corner := pt2. In place of this: setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom). setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y). I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed? Thanks, Trey

June 20, 2017

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

by Eliot Miranda

Hi Alex,, Hi Cyril, On Tue, Jun 20, 2017 at 10:26 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi Eliot, > > I experience the same slowness as Cyril. > Latest Pharo's UI is completely unresponsive and it takes seconds to open > new windows, resizing is a nightmare. > Many apologies. I broke the criterion for running global GC when I added the allocation measurement support. The GC is run when the heap is found to have grown by some ration (default 1.5) after each scavenge. When I added the allocation counting support I noticed that there was a bug in the determination of the size of the heap (the old code just looked at the extent of the heap, not the sum of the size of segments) and so I changed it to use the correct size. Evidently I've broken something. I'll fix it asap, but first have some other issues to attend to. It should be fixed before the end of the week. > > I made two videos comparing latest and stable VMs. I used 32bit > Pharo-60501 on OSX Sierra 10.12.5. > â > Pharo-VMLatest.mov > <https://drive.google.com/file/d/0B-bMBVDOi3oTXy1wNmlSTlV5THM/view?usp=drive…> > ââ > Pharo-VMStable.mov > <https://drive.google.com/file/d/0B-bMBVDOi3oTX3AzUkNqcng3dUk/view?usp=drive…> > â > Cheers, > Alex > > On 20 June 2017 at 19:14, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> Hi Cyril, >> >> On Tue, Jun 20, 2017 at 8:08 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com >> > wrote: >> >>> On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >>> wrote: >>> > Hi ClÃ©ment >>> > >>> > >>> > That was a mistake of mine. In the current VM it now answers e.g. >>> 1011.6 and so things should be working again. >>> > >>> >>> Hi! >>> >>> The problem is that the stable vm does not have the fix and the >>> current latest vm is **reeeeeeeeally* slow. It happens at least on >>> OSX. >> >> >> Can you say more? I'm noticing slow start up on the latest VMs but once >> it is running I see no issue. What specifically is running slowly for you? >> >> >>> I don't know if it is a known problem or if it comes from the >>> opensmalltalk build or the pharo build. >>> >>> I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/ >>> >>> >>> >>> -- >>> Cyril Ferlicot >>> https://ferlicot.fr >>> >>> http://www.synectique.eu >>> 2 rue Jacques PrÃ©vert 01, >>> 59650 Villeneuve d'ascq France >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > > -- _,,,^..^,,,_ best, Eliot

June 20, 2017