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

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

by 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

how to model this a better way

by Roelof Wobben

April 18, 2019

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

by Stephan Eggermont

TedVanGaalen <tedvga(a)gmail.com> wrote: > ok, I'll try > please give me a link to that VM 201820222239 > can't find it here: > https://files.pharo.org/vm/pharo-spur64/ Sorry, thatâs a typo. See the issue

April 18, 2019

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

by TedVanGaalen

ok, I'll try please give me a link to that VM 201820222239 can't find it here: https://files.pharo.org/vm/pharo-spur64/mac/ TedvG -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 18, 2019

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

by Esteban Lorenzano

> 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 <mailto:estebanlm@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: >> Because there is still an important place for desktop applications market and most medium-size to big business still require them. >> 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: >> >> Old GT tools will be replaced by new Spec tools (while preserving its power). >> Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). >> 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

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

by PBKResearch

+1 to Norbert. In particular, does it mean that, from Pharo 8, we will be *required* to install Gtk3 backend to use Pharo? 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 < <mailto:estebanlm@gmail.com> 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

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

by Norbert Hartl

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: > Because there is still an important place for desktop applications market and most medium-size to big business still require them. > 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: > > Old GT tools will be replaced by new Spec tools (while preserving its power). > Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). > 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

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

by Esteban Lorenzano

Ah yesâ¦ and same in morphic (but this is kind of boring ;): > On 18 Apr 2019, at 12:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > 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: > Because there is still an important place for desktop applications market and most medium-size to big business still require them. > 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: > > Old GT tools will be replaced by new Spec tools (while preserving its power). > Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). > 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

[ANN] (Re)Introducing Mars (Spec 2.0 Gtk3 bindings)

by Esteban Lorenzano

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: Because there is still an important place for desktop applications market and most medium-size to big business still require them. 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: Old GT tools will be replaced by new Spec tools (while preserving its power). Calypso UI needs to be rewritten in Spec 2.0 (it is in plain Morphic now). 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): Esteban

April 18, 2019

Re: [Pharo-users] Pharo 6.0 and 6.1 64 bit freeze on MacMini -also in 7.03

by Stephan Eggermont

TedVanGaalen <tedvga(a)gmail.com> wrote: > Thanks for the Info/Link, Stephan > > So it is a VM error then? > That is what I asked you to verify. Does the problem occur with 201820222239? If not, then it is probably the same bug. Stephsn

April 18, 2019