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

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

by TedVanGaalen

Hi Stephan I am a bit confused, not really at home in your VM world, so please send me a link for the VM + an Image that you'd like me to try on my mac. Thanks Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 19, 2019

Re: [Pharo-users] NewWave - WorkflowEngine

by Serge Stinckwich

On Wed, Apr 17, 2019 at 4:32 PM BrunoBB <smalltalk(a)adinet.com.uy> wrote: > Hi Sebastijan, > > Excellent work !!! > > I have something similar (a BPM engine) but developed with GemStone > Smalltalk: > Code: > https://github.com/brunobuzzi/BpmFlow > Documentation: > https://bpmflow.gitbook.io/project/introduction > > It can be ported to Pharo, from the top of my head i see a couple of issues > with the port: > - GemStone/S special indexes collection must be changed for regular Pharo > collections. > - GsQuery should be implemented in Pharo (maybe already is i do not know) > or > remove GsQuery references and so regular collection queries (select:, > collect: anySatisfy and so on) > > The project is totally open source. > > There is also the BPMN engine that we build with Alvaro Peralta: https://github.com/A4BP Maybe we can work together ? Regards, -- Serge Stinckwic h Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) Sorbonne University (SU) French National Research Institute for Sustainable Development (IRD) U niversity of YaoundÃ© I, Cameroun "Programs must be written for people to read, and only incidentally for machines to execute." https://twitter.com/SergeStinckwich

April 19, 2019

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

by Esteban Lorenzano

Hi Ronie, > On 18 Apr 2019, at 18:56, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > That looks very cool > > For the text editor are you using GtkSourceView or something else? For now, we are using a plain GtkTextView but we will switch to GtkSourceView later (just because it provides some functionality like adornments for breakpoints and that the I do not want to do myself, even if it would be possible). Esteban > > Greetings, > Ronie > > El jue., 18 abr. 2019 a las 7:23, Esteban Lorenzano (<estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>) escribiÃ³: > > >> On 18 Apr 2019, at 13:08, PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@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 <mailto:pharo-users-bounces@lists.pharo.org>> On Behalf Of Norbert Hartl >> Sent: 18 April 2019 11:58 >> To: Pharo users users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> >> Cc: Pharo Dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@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 19, 2019

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

by Andres Valloud

I wanted to go for coffee! :P On 4/18/19 23:50 , Richard Sargent wrote: > You are so right! > > Q: now that I've gotten to the bottom of the Grand Canyon and found a > narrow spot, how do I cross the river? > > A: WTF are you doing down there???? > > > On April 18, 2019 11:41:48 PM PDT, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net> wrote: > > I can't escape the feeling that this answer is leaving a lot on the > table because the question is asked from a narrow perspective. > > On 4/18/19 10:01 , Roelof Wobben wrote: > > 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) >

April 19, 2019

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

by Roelof Wobben

April 19, 2019

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

by Richard Sargent

You are so right! Q: now that I've gotten to the bottom of the Grand Canyon and found a narrow spot, how do I cross the river? A: WTF are you doing down there???? On April 18, 2019 11:41:48 PM PDT, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: >I can't escape the feeling that this answer is leaving a lot on the >table because the question is asked from a narrow perspective. > >On 4/18/19 10:01 , Roelof Wobben wrote: >> 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)

April 19, 2019

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

by Andres Valloud

I can't escape the feeling that this answer is leaving a lot on the table because the question is asked from a narrow perspective. On 4/18/19 10:01 , Roelof Wobben wrote: > 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)

April 19, 2019

Re: [Pharo-users] Why are package tags not proper sub-packages?

by Tim Mackinnon

Thatâs the struggle I face - I might be able to coerce Calypso to show extension methods in the tag, but there seems no way to understand what tag it/they are associated with - which also got me to the catch you mention, when saving an exercise I canât know what extensions to save with it... Iâd have to Save them all and this will end up as a big mess when loading different exercises later. I wish Iâd known this job hasnât been finished and Iâm curious why itâs not on the roadmap anymore if itâs a stepping stone (unless it means Cargo - but that seems to have been lowered in priority?) Tim Sent from my iPhone > On 19 Apr 2019, at 03:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Ben Coman wrote >>> The implication here is that extension methods canât live on the tag >>> (they >>> live on the parent package > > Won't that cause existing code not designed with that restriction in mind to > be lost on save? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

April 19, 2019

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

by Ben Coman

On Fri, 19 Apr 2019 at 01:33, 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 think the required method was mentioned previously, but here is how to discover it yourself... + Tool > Finder > Examples + Enter... (0@1) . (1@0) <Search> finds... Point>>leftRotated e.g. (0@1) leftRotated ==> (1@0) On Fri, 19 Apr 2019 at 01:39, Roelof Wobben <r.wobben(a)home.nl> wrote: > > Ben, > > I have such a dictionary in my first attempt to solve this one. > and another one for the facing. This sounds strange that you have two Dictionaries. It can be useful to encapsulate the mapping to avoid that being littered around your Robot code... Object subclass: #Facing instanceVariables: 'map directionVector' Facing >> initialize map := Dictionary newFromPairs: { 'north'. (0@1) . 'west' . (0@1) leftRotated . 'south'. (0@1) leftRotated leftRotated. 'east' . (0@1) rightRotated }. directionVector := map atRandom. Facing >> directionString ^ map keyAtValue: directionVector Facing >> printOn: aStream " Facing new inspect " aStream nextPutAll: self className, '-', self directionString "The above is produces a minimum-viable object that displays nicely in Inspector to facilitate incrementally coding your scenario in TDD way..." > Lets say we have this scenario: TestCase subclass: FacingTest FacingTest>>testAllTogether |position facing| "Robot begins at (0,0) facing north" position := 0@0. facing := Facing new face: 'north'. self assert: facing printString equals: 'Facing-north'. "then it turns right so it faces >>EAST<<" facing turnRight. self assert: facing printString equals: 'Facing-east'. "then it moves one step so the new position is (-1,0)" position := position + (facing movementSteps: 1). self assert: position equals: (-1@0). "then it turns left so it faces north again" facing turnLeft. self assert: facing printString equals: 'Facing-north'. "then it moves one step so the new position is (-1,1)" position := position + (facing movementSteps: 1). self assert: position equals: (-1@1). Which I'll leave as an exercise for you to complete with these hints... Facing >> face: aDirectionString directionVector := ... Facing >> turnRight directionVector := ... Facing >> turnLeft directionVector := ... Facing >> movementSteps: steps ^ ... > so if I see it , the position has nothing to do with the direction the > robot is facing yes. they only interact when the robot moves > this [position] is only important for finding out a new direction no - position has no impact for determining the new direction > or to find out if the x or the y needs to change. You don't need to treat x and y separately. Using Points for both the "position" and "directionVector" facilitates simple addition. cheers -ben > > 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 19, 2019

Re: [Pharo-users] Why are package tags not proper sub-packages?

by Sean P. DeNigris

Ben Coman wrote >> The implication here is that extension methods canât live on the tag >> (they >> live on the parent package Won't that cause existing code not designed with that restriction in mind to be lost on save? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 19, 2019