- Pharo-dev - lists.pharo.org

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

by Stephane Ducasse

Welcome Trey This is nice. Did you see that we started long time ago to have a version of the original tutorial on github to port it to Pharo. Feel free to send pull requests. About this API. the old API was not good because it forced you to create a bogus rectangle often for nothing and also points for nothing. It is better to use the accessors to set the value since a layoutFrame is initialized first. Have a look at the users of LayoutFrame or asLayoutFrame. There is no raison to create a point 0@200 if you can just use the correct accessors to set 200. stef On Wed, Jun 21, 2017 at 12:10 AM, 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 22, 2017

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

by Ben Coman

On Wed, Jun 21, 2017 at 10:17 PM, Trey Tomes <trey.tomes(a)gmail.com> wrote: > Chris: Thank you for the reference to the topLeftOffset:bottomRightOffset: > API, that resolved my problem really well. > @all, Would this be suitable for a QA rule? cheers -ben > 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 22, 2017

Iceberg diff colours seem reversed?

by Tim Mackinnon

Hi Guys - when you launch the Synchronize window in iceberg - is it me, or are the colour highlights backwards (and possibly the ordering of the panes)? If the left pane is my working copy, and I've added some code to a method - why does it appear in red on the left (which typically means deleted?). I notice that in IntelliJ (and other tools) your working changes are typically on the right and things you add are in Green on that right hand side. I think that ordering and colour coding make more sense - from -> to, and red is deleted, green is added. Of course I can live with the different pane ordering, but I think the colours might be wrong? Tim

June 22, 2017

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