April 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] how to model this a better way

by Tim Mackinnon

You quickly find itâs a more interesting exercise than just a âpoint and dictionaryâ, particularly if you want to do it in an elegant Smalltalk way (but not over do it either). The interesting bit is that when facing a new direction, you need to know how to advance in that direction , and also what âleftâ and ârightâ of that direction are too. So it teases out having some objects and techniques for this. For those interested - join exercism-Pharo (https://exercism.io/tracks/pharo-smalltalk/installation) in non mentor mode and you can easily download it with the tests and try it out yourself (without running through the other exercises). Tim Sent from my iPhone > On 18 Apr 2019, at 21:41, Richard Sargent <richard.sargent(a)gemtalksystems.com> wrote: > > Your system would have instance variables holding the cardinal directions and another holding the current direction vector. > e.g. > north := DirectionVector x: 0 y: 1 name: 'north'. > > Your robot would implement e.g. #faceNorth to assign the "north" direction vector to the current direction vector instance variable. > > > >> On Thu, Apr 18, 2019 at 12:17 PM Roelof Wobben <r.wobben(a)home.nl> wrote: >> oke, and how must I see those classes and elemating the need for a lookup. >> >> it may be explained in pseudo-code. >> >> Roelof >> >> >> >> Op 18-4-2019 om 20:28 schreef Richard Sargent: >>>> On Thu, Apr 18, 2019 at 10:33 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >>>> oke >>>> >>>> Maybe I understand something not right, >>>> >>>> Lets say we have this scenario. >>>> >>>> Robot is on position (0,0) >>>> now it turns left so the robot faces East >>> >>> I don't understand what position has to do with direction nor why that would be a problem. They are two distinct attributes. >>> Point and Dictionary are sufficient classes to model the limited requirements of this exercise. >>> You could model a new class DirectionVector which internalizes the Point used to provide the direction and provides its own name, eliminating the need for a look up of any kind. >>> >>>> >>>> or this scenario >>>> >>>> Robot is on position (0,0) >>>> now it turns right so the robot faces west. >>>> >>>> it looks that dictionary cannot provide this answer. >>>> or do I overlook something >>>> >>>> Roelof >>>> >>>> >>>> >>>> Op 18-4-2019 om 19:17 schreef Richard Sargent: >>>>>> On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >>>>>> yep, I have read that one >>>>>> but I never gets a answer how I can "convert" a point to something like north, east >>>>>> >>>>>> because the challenge wants this to be the answer : >>>>>> >>>>>> (Dictionary new >>>>>> add: 'direction' -> 'north'; >>>>>> add: >>>>>> 'position' >>>>>> -> >>>>>> (Dictionary new >>>>>> add: 'x' -> 0; >>>>>> add: 'y' -> 0; >>>>>> yourself); >>>>>> yourself) >>>>> >>>>> If you have previously defined a "representation map", you would be golden. >>>>> >>>>> e.g. >>>>> Dictionary new >>>>> at: self northDirectionVector put: 'north'; >>>>> at: self eastDirectionVector put: 'east'; >>>>> at: self southDirectionVector put: 'south'; >>>>> at: self westDirectionVector put: 'west'; >>>>> yourself. >>>>> >>>>> Then: >>>>> (Dictionary new >>>>> add: 'direction' -> (self directionRepresentationMap at: self directionVector); >>>>> ... >>>>> >>>>>> >>>>>> >>>>>> and I think I need then to use if then , which I try to avoid as much as possible. >>>>>> >>>>>> Roelof >>>>>> >>>>>> >>>>>> >>>>>> Op 18-4-2019 om 18:33 schreef Richard Sargent: >>>>>>>> On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I know I have asked earlier but im still stuck on this one : https://github.com/exercism/problem-specifications/blob/master/exercises/ro… >>>>>>>> >>>>>>>> I tried with all double dispatch but that will be a lot of duplicate classes >>>>>>>> >>>>>>>> The problem I cannot solve right is that a robot can move or turn. when a robot turns only the direction the robot is facing changes and the position not. when a robot moves the facing direction stays the same but the position changes. but the change is dependend on the facing. Also the new facing direction is dependend on the old facing direction/ >>>>>>>> How can I model this the best. >>>>>>>> >>>>>>>> I already have a object Robot that contains the facing direction and the current position >>>>>>>> or tried without it but then I use a lot of if then's >>>>>>>> >>>>>>>> >>>>>>>> so it there a better way to model this problem so it will be all nice and readable code. >>>>>>> >>>>>>> If I remember correctly, Richard O'Keefe gave you a viable design. 1) Use a Point for your direction vector. 2) Use a second Point for your position. >>>>>>> >>>>>>> e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 is South, 1@0 is East, and -1@0 is West. When you move, you add the direction vector to your current position. If you allow movements of greater than a single unit, you multiply the direction vector by the distance before adding that product to the position. >>>>>>> >>>>>>>> >>>>>>>> Roelof >>>>>>>> >>>>>> >>>> >>

April 18, 2019

Re: [Pharo-users] how to model this a better way

by Richard Sargent

Your system would have instance variables holding the cardinal directions and another holding the current direction vector. e.g. north := DirectionVector x: 0 y: 1 name: 'north'. Your robot would implement e.g. #faceNorth to assign the "north" direction vector to the current direction vector instance variable. On Thu, Apr 18, 2019 at 12:17 PM Roelof Wobben <r.wobben(a)home.nl> wrote: > oke, and how must I see those classes and elemating the need for a lookup. > > it may be explained in pseudo-code. > > Roelof > > > > Op 18-4-2019 om 20:28 schreef Richard Sargent: > > On Thu, Apr 18, 2019 at 10:33 AM Roelof Wobben <r.wobben(a)home.nl> wrote: > >> oke >> >> Maybe I understand something not right, >> >> Lets say we have this scenario. >> >> Robot is on position (0,0) >> now it turns left so the robot faces East >> > > I don't understand what position has to do with direction nor why that > would be a problem. They are two distinct attributes. > Point and Dictionary are sufficient classes to model the limited > requirements of this exercise. > You could model a new class DirectionVector which internalizes the Point > used to provide the direction and provides its own name, eliminating the > need for a look up of any kind. > > >> or this scenario >> >> Robot is on position (0,0) >> now it turns right so the robot faces west. >> >> it looks that dictionary cannot provide this answer. >> or do I overlook something >> >> Roelof >> >> >> >> Op 18-4-2019 om 19:17 schreef Richard Sargent: >> >> On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> yep, I have read that one >>> but I never gets a answer how I can "convert" a point to something like >>> north, east >>> >>> because the challenge wants this to be the answer : >>> >>> (Dictionary new >>> add: 'direction' -> 'north'; >>> add: >>> 'position' >>> -> >>> (Dictionary new >>> add: 'x' -> 0; >>> add: 'y' -> 0; >>> yourself); >>> yourself) >>> >> >> If you have previously defined a "representation map", you would be >> golden. >> >> e.g. >> Dictionary new >> at: self northDirectionVector put: 'north'; >> at: self eastDirectionVector put: 'east'; >> at: self southDirectionVector put: 'south'; >> at: self westDirectionVector put: 'west'; >> yourself. >> >> Then: >> (Dictionary new >> add: 'direction' -> (self directionRepresentationMap at: >> self directionVector); >> ... >> >> >>> >>> and I think I need then to use if then , which I try to avoid as much as >>> possible. >>> >>> Roelof >>> >>> >>> >>> Op 18-4-2019 om 18:33 schreef Richard Sargent: >>> >>> On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >>> >>>> Hello, >>>> >>>> I know I have asked earlier but im still stuck on this one : >>>> https://github.com/exercism/problem-specifications/blob/master/exercises/ro… >>>> >>>> I tried with all double dispatch but that will be a lot of duplicate >>>> classes >>>> >>>> The problem I cannot solve right is that a robot can move or turn. when >>>> a robot turns only the direction the robot is facing changes and the >>>> position not. when a robot moves the facing direction stays the same but >>>> the position changes. but the change is dependend on the facing. Also the >>>> new facing direction is dependend on the old facing direction/ >>>> How can I model this the best. >>>> >>>> I already have a object Robot that contains the facing direction and >>>> the current position >>>> or tried without it but then I use a lot of if then's >>>> >>>> >>>> so it there a better way to model this problem so it will be all nice >>>> and readable code. >>>> >>> >>> If I remember correctly, Richard O'Keefe gave you a viable design. 1) >>> Use a Point for your direction vector. 2) Use a second Point for your >>> position. >>> >>> e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 >>> is South, 1@0 is East, and -1@0 is West. When you move, you add the >>> direction vector to your current position. If you allow movements of >>> greater than a single unit, you multiply the direction vector by the >>> distance before adding that product to the position. >>> >>> >>>> Roelof >>>> >>>> >>> >> >

April 18, 2019

Re: [Pharo-users] how to model this a better way

by Roelof Wobben

April 18, 2019

Re: [Pharo-users] how to model this a better way

by Richard Sargent

On Thu, Apr 18, 2019 at 10:33 AM Roelof Wobben <r.wobben(a)home.nl> wrote: > oke > > Maybe I understand something not right, > > Lets say we have this scenario. > > Robot is on position (0,0) > now it turns left so the robot faces East > I don't understand what position has to do with direction nor why that would be a problem. They are two distinct attributes. Point and Dictionary are sufficient classes to model the limited requirements of this exercise. You could model a new class DirectionVector which internalizes the Point used to provide the direction and provides its own name, eliminating the need for a look up of any kind. > or this scenario > > Robot is on position (0,0) > now it turns right so the robot faces west. > > it looks that dictionary cannot provide this answer. > or do I overlook something > > Roelof > > > > Op 18-4-2019 om 19:17 schreef Richard Sargent: > > On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben <r.wobben(a)home.nl> wrote: > >> yep, I have read that one >> but I never gets a answer how I can "convert" a point to something like >> north, east >> >> because the challenge wants this to be the answer : >> >> (Dictionary new >> add: 'direction' -> 'north'; >> add: >> 'position' >> -> >> (Dictionary new >> add: 'x' -> 0; >> add: 'y' -> 0; >> yourself); >> yourself) >> > > If you have previously defined a "representation map", you would be golden. > > e.g. > Dictionary new > at: self northDirectionVector put: 'north'; > at: self eastDirectionVector put: 'east'; > at: self southDirectionVector put: 'south'; > at: self westDirectionVector put: 'west'; > yourself. > > Then: > (Dictionary new > add: 'direction' -> (self directionRepresentationMap at: > self directionVector); > ... > > >> >> and I think I need then to use if then , which I try to avoid as much as >> possible. >> >> Roelof >> >> >> >> Op 18-4-2019 om 18:33 schreef Richard Sargent: >> >> On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >> >>> Hello, >>> >>> I know I have asked earlier but im still stuck on this one : >>> https://github.com/exercism/problem-specifications/blob/master/exercises/ro… >>> >>> I tried with all double dispatch but that will be a lot of duplicate >>> classes >>> >>> The problem I cannot solve right is that a robot can move or turn. when >>> a robot turns only the direction the robot is facing changes and the >>> position not. when a robot moves the facing direction stays the same but >>> the position changes. but the change is dependend on the facing. Also the >>> new facing direction is dependend on the old facing direction/ >>> How can I model this the best. >>> >>> I already have a object Robot that contains the facing direction and the >>> current position >>> or tried without it but then I use a lot of if then's >>> >>> >>> so it there a better way to model this problem so it will be all nice >>> and readable code. >>> >> >> If I remember correctly, Richard O'Keefe gave you a viable design. 1) Use >> a Point for your direction vector. 2) Use a second Point for your position. >> >> e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 >> is South, 1@0 is East, and -1@0 is West. When you move, you add the >> direction vector to your current position. If you allow movements of >> greater than a single unit, you multiply the direction vector by the >> distance before adding that product to the position. >> >> >>> Roelof >>> >>> >> >

April 18, 2019

Re: [Pharo-users] how to model this a better way

by Roelof Wobben

Ben, I have such a dictionary in my first attempt to solve this one. and another one for the facing. Lets say we have this scenario: Robot begins at (0,0) facing north then it turns right so it faces west then it moves one step so the new position is (-1,0) then it turns left so it faces north again then it moves one step so theÂ new position is (-1,1) so if I see it , the position has nothing to do with the direction the robot is facing this is only important for finding out a new direction orÂ to find out if the x or the y needs to change. Roelof Op 18-4-2019 om 19:27 schreef Ben Coman: > map := Dictionary newFromPairs: { > 'north'. 0 @ 1 . > 'south'. 0 @ -1 . > 'east'. 1 @ 0 . > 'west' . -1 @ 0 }. > (map at: 'north') inspect. > (map keyAtValue: 0 @ -1) inspect

April 18, 2019

Re: [Pharo-users] how to model this a better way

by Roelof Wobben

April 18, 2019

Re: [Pharo-users] how to model this a better way

by Ben Coman

>> e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 is South, 1@0 is East, and -1@0 is West. On Fri, 19 Apr 2019 at 01:01, Roelof Wobben <r.wobben(a)home.nl> wrote: > > yep, I have read that one > but I never gets a answer how I can "convert" a point to something like north, east Maybe you are looking for something like this... map := Dictionary newFromPairs: { 'north'. 0 @ 1 . 'south'. 0 @ -1 . 'east'. 1 @ 0 . 'west' . -1 @ 0 }. (map at: 'north') inspect. (map keyAtValue: 0 @ -1) inspect. cheers -ben > > because the challenge wants this to be the answer : > > (Dictionary new > add: 'direction' -> 'north'; > add: > 'position' > -> > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself); > yourself) > > > and I think I need then to use if then , which I try to avoid as much as possible. > > Roelof > > > > Op 18-4-2019 om 18:33 schreef Richard Sargent: > > On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben <r.wobben(a)home.nl> wrote: >> >> Hello, >> >> I know I have asked earlier but im still stuck on this one : https://github.com/exercism/problem-specifications/blob/master/exercises/ro… >> >> I tried with all double dispatch but that will be a lot of duplicate classes >> >> The problem I cannot solve right is that a robot can move or turn. when a robot turns only the direction the robot is facing changes and the position not. when a robot moves the facing direction stays the same but the position changes. but the change is dependend on the facing. Also the new facing direction is dependend on the old facing direction/ >> How can I model this the best. >> >> I already have a object Robot that contains the facing direction and the current position >> or tried without it but then I use a lot of if then's >> >> >> so it there a better way to model this problem so it will be all nice and readable code. > > > If I remember correctly, Richard O'Keefe gave you a viable design. 1) Use a Point for your direction vector. 2) Use a second Point for your position. > > e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 is South, 1@0 is East, and -1@0 is West. When you move, you add the direction vector to your current position. If you allow movements of greater than a single unit, you multiply the direction vector by the distance before adding that product to the position. > >> >> Roelof >> >

April 18, 2019

Re: [Pharo-users] how to model this a better way

by Richard Sargent

On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben <r.wobben(a)home.nl> wrote: > yep, I have read that one > but I never gets a answer how I can "convert" a point to something like > north, east > > because the challenge wants this to be the answer : > > (Dictionary new > add: 'direction' -> 'north'; > add: > 'position' > -> > (Dictionary new > add: 'x' -> 0; > add: 'y' -> 0; > yourself); > yourself) > If you have previously defined a "representation map", you would be golden. e.g. Dictionary new at: self northDirectionVector put: 'north'; at: self eastDirectionVector put: 'east'; at: self southDirectionVector put: 'south'; at: self westDirectionVector put: 'west'; yourself. Then: (Dictionary new add: 'direction' -> (self directionRepresentationMap at: self directionVector); ... > > and I think I need then to use if then , which I try to avoid as much as > possible. > > Roelof > > > > Op 18-4-2019 om 18:33 schreef Richard Sargent: > > On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben <r.wobben(a)home.nl> wrote: > >> Hello, >> >> I know I have asked earlier but im still stuck on this one : >> https://github.com/exercism/problem-specifications/blob/master/exercises/ro… >> >> I tried with all double dispatch but that will be a lot of duplicate >> classes >> >> The problem I cannot solve right is that a robot can move or turn. when a >> robot turns only the direction the robot is facing changes and the position >> not. when a robot moves the facing direction stays the same but the >> position changes. but the change is dependend on the facing. Also the new >> facing direction is dependend on the old facing direction/ >> How can I model this the best. >> >> I already have a object Robot that contains the facing direction and the >> current position >> or tried without it but then I use a lot of if then's >> >> >> so it there a better way to model this problem so it will be all nice >> and readable code. >> > > If I remember correctly, Richard O'Keefe gave you a viable design. 1) Use > a Point for your direction vector. 2) Use a second Point for your position. > > e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 > is South, 1@0 is East, and -1@0 is West. When you move, you add the > direction vector to your current position. If you allow movements of > greater than a single unit, you multiply the direction vector by the > distance before adding that product to the position. > > >> Roelof >> >> >

April 18, 2019

Re: [Pharo-users] how to model this a better way

by Roelof Wobben

April 18, 2019

Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Ronie Salgado

That looks very cool For the text editor are you using GtkSourceView or something else? Greetings, Ronie El jue., 18 abr. 2019 a las 7:23, Esteban Lorenzano (<estebanlm(a)gmail.com>) escribiÃ³: > > > On 18 Apr 2019, at 13:08, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > +1 to Norbert. In particular, does it mean that, from Pharo 8, we will be > *required* to install Gtk3 backend to use Pharo? > > > For now is in early development so there is no easy way to install (since > there are things to replace/fix in current image). > We will provide an install script soon (or maybe a prepared image, while > we arrive to have a reliable baseline). > > And no, you will not need it. Gtk3 bindings are an extra. If you want to > do a desktop application (for example Schmidt is doing it), maybe you will > want to install it. Otherwise you will continue as before. > > And to be clear: Pharo 8 WILL NOT be a Gtk3 application. > Even if eventually the IDE will be able to run with it (since it will be a > Spec 2.0 based IDE), there are a lot of huge things that need to be > migrated before (and the GTInspector is not big: Calypso is). > And still then (maybe in Pharo 9), running with Gtk3 will be a choice. > > Esteban > > > Peter Kenny > > *From:* Pharo-users <pharo-users-bounces(a)lists.pharo.org> *On Behalf Of *Norbert > Hartl > *Sent:* 18 April 2019 11:58 > *To:* Pharo users users <pharo-users(a)lists.pharo.org> > *Cc:* Pharo Dev <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] [ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 > bindings) > > Great! > > Can you explain what is there, what somebody can load and what to expect. > And even more important: what not to expect? > > I donât get any of the essential details from this mail. > > Norbert > > > > > Am 18.04.2019 um 12:08 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > People that assisted to Pharo Days 2019 (or that follow my twitter > account) already know this, but it needs to be formally announced: > > > *We are working on Spec 2.0, and it will provide not just the classic > Morphic bindings but also a new option for developers: Gtk3 bindings!* > > Why we want a Spec 2.0 with different backends? > > There are reasons that converged to decide us to make it: > > > - First, to provide a validated abstract Spec 2.0 that can be used > with different backends, preparing Pharo to be able to switch backends > without needing to recreate the full IDE from scratch each time (a problem > we have partially now in our way to deprecate Morphic). > - Second, because we receive from different sources the requirement of > having the possibility of developing real native-looking desktop > applications. Yes, in moment where people talk about the cloud, SaaS and > web-applications as the "next big thing" (something that is been declared > since years, by the way), we believe is important to provide this, for two > big reasons: > > > 1. Because there is still an important place for desktop applications > market and most medium-size to big business still require them. > 2. Because Pharo itself is a desktop application! (And we need to > provide the best experience possible on it). > > > For us, this is a fundamental step to continue improving Pharo itself, and > it matches also the work we are doing on going real-headless: Pharo users > will be able to start the Morphic world, a Gtk application or the next > backend to come. > > Why Gtk3? > > There are some other important players in the "native widgets scene", so > why we choose Gtk3? > > Again, several reasons were taken into account: > > > - Gtk3 is cross platform. Yes, technically is just "native" in linux, > but it works on Windows and macOS too. > - It is very mature and popular. > - It is made in plain C. > > > Next step: tool migration > > The only way to know if you have covered what is needed is actually taking > real-life use cases and implementing them. We have a list of tools that > needs to be migrated and we are starting from them: > > > 1. Old GT tools will be replaced by new Spec tools (while preserving > its power). > 2. Calypso UI needs to be rewritten in Spec 2.0 (it is in plain > Morphic now). > 3. Pharo launcher as a standalone application is a good example of > what you can do with the Gtk3 bindings. > > > And that's it. Pharo 8.0 will come with Spec 2.0 and users will be able to > benefit of it immediately :) > > > A small screenshot of the new Inspector (WIP): > > <Screenshot 2019-04-18 at 12.07.16.png> > > Esteban > > >

April 18, 2019