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

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

by Trey Tomes

I did not know about the GitHub tutorial. I'll take a look for it. Will fraction:offset: be deprecated then you think? ~Trey On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Avoid fraction:offset: it is a bad interface. > > > > On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > 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] vested interest in PharoJS?

by Siemen Baader

Very cool, Norbert. I have been watching what you are doing at 2denker and thought you might be interested ;) What is holding you back - do you need more from PharoJS before starting to use it commercially, or are you waiting for a (paid) project before you can start? -- Siemen On Thu, Jun 22, 2017 at 1:08 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I thought I responded already. We are interested in pharoJS. We developed > stuff with amber but stopped using it. We have one app in the app store > with ionic and amber and I'd like to do another one with pharoJS. > Additionally I think that combining pharoJS with electron could be a nice > thing to have in order to create desktop apps. And finally I was shortly > researching native callouts from javascript with javascript core on ios and > it seems you can do pharo code, transpile to javascript that calls > javascript functions which are OS-native functions. > > Norbert > > > Am 14.06.2017 um 11:46 schrieb Siemen Baader <siemenbaader(a)gmail.com>: > > > > Hi all, > > > > Is anyone else interested in PharoJS and making it mature for their own > commercial mobile and single page web app (and node.js) development? > > > > I think it has a huge potential because it brings the browser runtime > and many libraries and online services from the JS world to us Smalltalkers > while letting us keep our agile development and good CS practices. But it > does not yet have the necessary features and documentation to work smoothly. > > > > -- Siemen > >

June 22, 2017

Re: [Pharo-dev] vested interest in PharoJS?

by Norbert Hartl

I thought I responded already. We are interested in pharoJS. We developed stuff with amber but stopped using it. We have one app in the app store with ionic and amber and I'd like to do another one with pharoJS. Additionally I think that combining pharoJS with electron could be a nice thing to have in order to create desktop apps. And finally I was shortly researching native callouts from javascript with javascript core on ios and it seems you can do pharo code, transpile to javascript that calls javascript functions which are OS-native functions. Norbert > Am 14.06.2017 um 11:46 schrieb Siemen Baader <siemenbaader(a)gmail.com>: > > Hi all, > > Is anyone else interested in PharoJS and making it mature for their own commercial mobile and single page web app (and node.js) development? > > I think it has a huge potential because it brings the browser runtime and many libraries and online services from the JS world to us Smalltalkers while letting us keep our agile development and good CS practices. But it does not yet have the necessary features and documentation to work smoothly. > > -- Siemen

June 22, 2017

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

by ClÃ©ment Bera

On Thu, Jun 22, 2017 at 8:03 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Clement why you cannot load OSSubprocess? > > 1) project has to work on itimer Linux VM. 2) existing project working with OSProcess and I don't want to spend time migrating. 3) code base has to work at least in Squeak and Pharo, I don't want to add extra code so it uses different frameworks in different platforms and then maintain this extra code. > > > On Tue, Jun 20, 2017 at 3:10 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > Hi Thierry, hi all, > > > > The Pharo catalog version of OSProcess is not working in the Pharo 6 > release > > and I need to load OSProcess in one of my projects. I cannot load > > OSSubProcess instead, so no need to answer this mail talking about it. > > > > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os > > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess tests > the > > version number against 1000, and should now test against 10. > > > > I checked the SqueakSource repo of OSProcess, I can see that the last > > version is 4.6.8 and the catalog configuration loads an older version, > but I > > cannot see any fix related to the version number ? > > > > Can someone update the OSProcess configuration in the Pharo catalog so > that > > it loads a working version in the Pharo 6 release or point me to an > > OSProcess configuration, outside of the catalog, which works in the > release > > of Pharo 6 please ? > > > > Thank you very much. > > > > Clement > >

June 22, 2017

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

by Stephane Ducasse

Clement why you cannot load OSSubprocess? On Tue, Jun 20, 2017 at 3:10 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi Thierry, hi all, > > The Pharo catalog version of OSProcess is not working in the Pharo 6 release > and I need to load OSProcess in one of my projects. I cannot load > OSSubProcess instead, so no need to answer this mail talking about it. > > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess tests the > version number against 1000, and should now test against 10. > > I checked the SqueakSource repo of OSProcess, I can see that the last > version is 4.6.8 and the catalog configuration loads an older version, but I > cannot see any fix related to the version number ? > > Can someone update the OSProcess configuration in the Pharo catalog so that > it loads a working version in the Pharo 6 release or point me to an > OSProcess configuration, outside of the catalog, which works in the release > of Pharo 6 please ? > > Thank you very much. > > Clement

June 22, 2017

Re: [Pharo-dev] Iceberg diff colours seem reversed?

by Norbert Hartl

I didn't look at the iceberg diff right now. But I can say whenever I see a diff view in pharo it is so confusing I never know what I see. In the changes window I alwas switch from diff to source to see at least what I have now. Maybe a general problem how to put chronological change. And maybe for left-to-right readers to only way is older left - newer right Norbert > Am 22.06.2017 um 03:40 schrieb Tim Mackinnon <tim(a)testit.works>: > > 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] New User and the Rectangle class.

by Stephane Ducasse

Avoid fraction:offset: it is a bad interface. On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > 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 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