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

[Pharo 8.0] Build #228: ClassParser: methods polymorphic to RB-nodes for Calypso integration
by ci-pharo-ci-jenkins2＠inria.fr April 17, 2019

April 17, 2019

There is a new Pharo build available! The status of the build #228 was: SUCCESS. The Pull Request #3183 was integrated: "ClassParser: methods polymorphic to RB-nodes for Calypso integration" Pull request url: https://github.com/pharo-project/pharo/pull/3183 Issue Url: https://github.com/pharo-project/pharo/issues/classParserForCalypso Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

ZnMimePart
by Alistair Grant April 16, 2019

April 16, 2019

Hi Sven, I'm trying to parse maildir emails using ZnMimePart and have a few questions: 1. The standard indicates that text lines should be terminated with CRLF, however in practice many maildir format emails (as saved by offlineimap and successfully handled by mutt) use LF. Are you open to modifying the parser to be a bit more forgiving, and allow CRLF, LF or CR? I could then completely deprecate MIMEDocument from the image and make MailMessage a bit more useful. 2. ZnStringEntity and ZnByteArrayEntity both appear to answer their contents without decoding the data based on the Content-Transfer-Encoding, e.g. if I have: Date: Sat, 16 Mar 2019 12:00:21 +0100 MIME-Version: 1.0 Content-Type: image/jpeg; name="00585-capture.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="00585-capture.jpg" base64dataincludedhere... and send: aZmMimePart contents I'll get back the the result of evaluating: 'base64dataincludedhere...' asByteArray instead of the decoded data. Is this intended? I'd expect the decoded data (with charset decoding as well, in the case of text). 3. What do you think of adding a few convenience test methods, e.g. isImage, isApplication, isText, etc.? Thanks, Alistair

2 2

[Pharo 8.0] Build #227: Make size_t work inside a nested structure
by ci-pharo-ci-jenkins2＠inria.fr April 16, 2019

April 16, 2019

There is a new Pharo build available! The status of the build #227 was: SUCCESS. The Pull Request #3142 was integrated: "Make size_t work inside a nested structure" Pull request url: https://github.com/pharo-project/pharo/pull/3142 Issue Url: https://github.com/pharo-project/pharo/issues/ffi Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #226: 3188-Some-classes-have-an-users-property
by ci-pharo-ci-jenkins2＠inria.fr April 16, 2019

April 16, 2019

There is a new Pharo build available! The status of the build #226 was: SUCCESS. The Pull Request #3190 was integrated: "3188-Some-classes-have-an-users-property" Pull request url: https://github.com/pharo-project/pharo/pull/3190 Issue Url: https://github.com/pharo-project/pharo/issues/3188 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #225: useCalypso0162
by ci-pharo-ci-jenkins2＠inria.fr April 15, 2019

April 15, 2019

There is a new Pharo build available! The status of the build #225 was: SUCCESS. The Pull Request #3182 was integrated: "useCalypso0162" Pull request url: https://github.com/pharo-project/pharo/pull/3182 Issue Url: https://github.com/pharo-project/pharo/issues/useCalypso0162 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #224: 3112-openInEnvironment-does-not-seem-to-exist-anymore-but-it-is-sent
by ci-pharo-ci-jenkins2＠inria.fr April 15, 2019

April 15, 2019

There is a new Pharo build available! The status of the build #224 was: FAILURE. The Pull Request #3137 was integrated: "3112-openInEnvironment-does-not-seem-to-exist-anymore-but-it-is-sent" Pull request url: https://github.com/pharo-project/pharo/pull/3137 Issue Url: https://github.com/pharo-project/pharo/issues/3112 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #223: 3153-Slots-Cleanups--some-first-ComposableSlot-
by ci-pharo-ci-jenkins2＠inria.fr April 12, 2019

April 12, 2019

There is a new Pharo build available! The status of the build #223 was: SUCCESS. The Pull Request #3154 was integrated: "3153-Slots-Cleanups--some-first-ComposableSlot-" Pull request url: https://github.com/pharo-project/pharo/pull/3154 Issue Url: https://github.com/pharo-project/pharo/issues/3153 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [vwnc] most energy efficient AI system - challenge of the German Federal Ministry of Education and Research BMBF
by Alexandre Bergel April 12, 2019

April 12, 2019

Hello, We conducted some experiment in characterizing virtual machine from an energetic point of view. Results are not public yet. This is just to say this is a topic that I am interested in. Cheers, Alexandre > On Apr 11, 2019, at 5:29 PM, Bernhard HÃ¶fner <bernhard.hoefner(a)web.de> wrote: > > Hello Group, > the German BMBF advertised a reward for the most energy efficient AI system, see: https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html <https://www.bmbf.de/de/mehr-ki-erfordert-weniger-energie-8156.html> (in German), and I am wondering what is the position of Smalltalk in that field or what it could be. From the early 90th I know that much of the pretended slowness of Smalltalk was absorbed by the more efficient programs due to better analysis, concepts, design and development tools (and maybe developers ? ). > > Best Regards, Bernhard

1 0

[Pharo 7.0] Build #158: Fix for corrupted fonts in Pharo7
by ci-pharo-ci-jenkins2＠inria.fr April 12, 2019

April 12, 2019

There is a new Pharo build available! The status of the build #158 was: SUCCESS. The Pull Request #3178 was integrated: "Fix for corrupted fonts in Pharo7" Pull request url: https://github.com/pharo-project/pharo/pull/3178 Issue Url: https://pharo.fogbugz.com/f/cases/3157 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0] Build #157: Fix for corrupted fonts in Pharo7
by ci-pharo-ci-jenkins2＠inria.fr April 12, 2019

April 12, 2019

There is a new Pharo build available! The status of the build #157 was: FAILURE. The Pull Request #3178 was integrated: "Fix for corrupted fonts in Pharo7" Pull request url: https://github.com/pharo-project/pharo/pull/3178 Issue Url: https://pharo.fogbugz.com/f/cases/3157 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #222: Adding flags for Smalltalk reference. Refactor some direct reference â¦
by ci-pharo-ci-jenkins2＠inria.fr April 12, 2019

April 12, 2019

There is a new Pharo build available! The status of the build #222 was: FAILURE. The Pull Request #3155 was integrated: "Adding flags for Smalltalk reference. Refactor some direct reference â¦" Pull request url: https://github.com/pharo-project/pharo/pull/3155 Issue Url: https://github.com/pharo-project/pharo/issues/FewSmalltalkRemoval Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #221: MailMessage can not send mails with attachment in Pharo8
by ci-pharo-ci-jenkins2＠inria.fr April 12, 2019

April 12, 2019

There is a new Pharo build available! The status of the build #221 was: SUCCESS. The Pull Request #3167 was integrated: "MailMessage can not send mails with attachment in Pharo8" Pull request url: https://github.com/pharo-project/pharo/pull/3167 Issue Url: https://github.com/pharo-project/pharo/issues/3164 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[OT] (slightly) What makes other dialects "enjoyable" for you? (WAS: difference between double dispatch...)
by Esteban Lorenzano April 12, 2019

April 12, 2019

Hi, Time to time I hear people like Richard saying âDolphin is the dialect most beautiful Smalltalk he usedâ and others praising it in different levels. As Pharo âarchitectâ (or whatever I am, but at least Iâm sure I have to pay attention to the IDE :P), Iâm interested to know what elements of Dolphin dialect you find âbeautifulâ, âenjoyableâ and productive. What it is? - the MVP? - integration with Windows? The way this integration is done? (If soâ¦ how is it done?) â¦ I am very interested on knowing this with some detail level. That doesnât mean I will react and do something, but I want to have a better understanding and put it in my radar to take inspiration to enhance the Pharo experience :P Esteban > On 10 Apr 2019, at 03:09, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > On this laptop I have > - Squeak > - Pharo > - GNU Smalltalk > - VisualAge Smalltalk > - VisualWorks Smalltalk > - Smalltalk/X > plus some oddballs like susie, amber, and CSOM. > On another laptop I have > - Strongtalk > - Dolphin > And of course I have my own 'astc' Smalltalk-via-C compiler. > I have to say that Dolphin is easily the most *beautiful* Smalltalk > environment I've used. (Yes, I'm the kind of person who has four > different C compilers on the same machine and uses them all. You > don't want to know how many Javascript implementations...) > > The important thing here is that there are at least two aspects to > "Smalltalk". There is Smalltalk-the-approach-to-OO and there is > Smalltalk-the-many-related-but-different-IDEs. When it comes to > productivity, the IDE is important. Really important. But when > it comes to thinking about programming and solving tasks like > exercism ones, it's the approach that matters. And that approach > pays off in languages like Javascript and Ruby and Python as well. > > I used to be a University lecturer. Now I'm a (sub)contractor. > I used to see a LOT of student code that > - had way too many classes > - did not use existing well-known classes when it should > - failed to encapsulate private state > - put responsibilities in the wrong places > and that was Java code. What prepared me to see such issues in Java? > > Lots and lots of practice in Smalltalk. > > And lots of reading Smalltalk, and figuring out what made it easy or > hard to read. > > I do not know how much time you have on your hands, > but you might find it profitable to look at > http://rosettacode.org/wiki/Rosetta_Code <http://rosettacode.org/wiki/Rosetta_Code> > specifically > http://rosettacode.org/wiki/Category:Smalltalk <http://rosettacode.org/wiki/Category:Smalltalk> > > Look at the bottom of that page for a list of 258 > problems solved in Smalltalk. > > > On Tue, 9 Apr 2019 at 03:20, Roelof Wobben <r.wobben(a)home.nl <mailto:r.wobben@home.nl>> wrote: > Thanks, > > for the discusson and lessons. > > I will think about it and also think if smalltalk is for me. > I did the pharo Mooc and still have a lot of problems making the smalltalk way click in my head so I can solve little problems like this. > > Out of coriousy what dialect do you use? > > > Op 8-4-2019 om 17:11 schreef Richard O'Keefe: >> You are expected to use my code fragments for *ideas*, >> not to incorporate them *literally* in your code. As >> I explained, *without seeing the specification*, I have >> no way to tell whether the specification uses a left-handed >> or right-handed coordinate system. >> >> For what it's worth, here's a complete program in my >> Smalltalk dialect. It doesn't plug into the exercism >> testing framework because I can do not know what it >> looks like. But if it makes the code more complicated >> that this, it's doing it wrong. >> >> require: 'geometry.st <http://geometry.st/>' "Point" >> require: 'print.st <http://print.st/>' "OutputStream>>print:" >> >> Object subclass: #Robot >> instanceVariableNames: 'position direction' >> poolDirectionaries: 'FileStream' >> >> methods for: 'initialising' >> pvtPostNew >> position := 0@0. >> direction := 1@0. >> >> methods for: 'accessing' >> direction >> ^direction copy >> >> location >> ^location copy >> >> obey: commands >> commands do: [:each | >> each caseOf: { >> [$A] -> [position := position + direction]. >> [$L] -> [direction := direction leftRotated]. >> [$R] -> [direction := direction rightRotated] >> }]. >> >> class methods for: 'main' >> start >> [StdIn atEnd] whileFalse: [ >> |robot| >> robot := Robot new. >> Robot obey: StdIn nextLine. >> StdOut print: Robot location; cr]. >> >> On Tue, 9 Apr 2019 at 02:58, Roelof Wobben <r.wobben(a)home.nl <mailto:r.wobben@home.nl>> wrote: >> yes, this is a real tests from the pharo track on exercism.io <http://exercism.io/> >> >> I understand what you mean but maybe I overthinking things. >> But if we have a robot facing north and the robot turns to the left , im my oponion it faces now to the east. >> >> like this test is saying : >> >> test04_RotatesTheRobotsDirection90DegreesClockwiseChangesTheDirectionFromEastToSouth >> | result | >> result := robotSimulatorCalculator >> moveDirection: 'east' >> position: >> (Dictionary new >> add: 'x' -> 0; >> add: 'y' -> 0; >> yourself) >> instructions: 'R'. >> self >> assert: result >> equals: >> (Dictionary new >> add: 'direction' -> 'south'; >> add: >> 'position' >> -> >> (Dictionary new >> add: 'x' -> 0; >> add: 'y' -> 0; >> yourself); >> yourself) >> >> >> but I cannot come to the same outcome with this code : >> >> >> pointToName: aPoint >> ^aPoint x isZero >> ifTrue: [aPoint y > 0 ifTrue: [#north] ifFalse: [#south]] >> ifFalse: [aPoint x > 0 ifTrue: [#west ] ifFalse: [#east ]] >> >> >> maybe exercism.io <http://exercism.io/> is not a good way to practice and learn smalltalk but I found not a better one. or smalltalk is not for me. >> >> Roelof >> >> >> >> >> >> >> >> >> >> >> >> Op 8-4-2019 om 16:44 schreef Richard O'Keefe: >>> The basic issue here is abstraction. >>> An instance of "Robot" in your program is not a >>> physical object. How could it possibly point North, >>> South, or Nor-nor-west? It cannot. >>> Its location and direction are abstract values >>> *metaphorically* related to real world notions >>> like position vectors and velocity vectors. >>> "North" in this program is not a real thing, >>> it is an *idea* which could be represented by >>> 'North', 'north', #North, #north, $N, $n, >>> 'Raki', 'raki', #Raki, #raki, $R, $r, >>> 137, (0@ -1), a picture of the star Polaris, >>> the colour red (the conventional colour for >>> that end of a compass needle which points north), >>> a sound recording of a lecture by Alfred North >>> Whitehead, or anything you please, as long as, >>> inside the program, it *acts* the way *you* want >>> "north" to act (which is not necessarily the way >>> the physical direction North acts, and in fact in >>> this case it most certainly is not). >>> >>> Locations and movements in a 2D space are, in Smalltalk, >>> commonly represented by Points. "Represented by." >>> >>> As for this method: >>> >>> test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth >>> | result | >>> result := robotSimulatorCalculator >>> moveDirection: 'north' >>> position: >>> (Dictionary new >>> add: 'x' -> 0; >>> add: 'y' -> 0; >>> yourself) >>> instructions: 'A'. >>> self >>> assert: result >>> equals: >>> (Dictionary new >>> add: 'direction' -> 'north'; >>> add: >>> 'position' >>> -> >>> (Dictionary new >>> add: 'x' -> 0; >>> add: 'y' -> 1; >>> yourself); >>> yourself) >>> >>> PLEASE tell me that is not what they are actually using. >>> Let's start with >>> (Dictionary new) >>> add: k1 -> v1; >>> ... >>> add: kn -> vn; >>> yourself >>> Did you know that sending #add: to a dictionary is not >>> portable? Storing actual Association objects inside >>> Dictionaries was originally an encapsulation error and >>> remains a performance error, so there are Smalltalks >>> that do not make that mistake. The *portable* way to >>> make a Dictionary is >>> (Dictionary new) >>> at: k1 put: v1; >>> ... >>> at: kn put: vn; >>> yourself. >>> >>> And why in the name of sanity are the keys *strings* >>> instead of *symbols*? This is not Smalltalk. It is >>> Javascript in drag. >>> >>> Now exercism.io <http://exercism.io/> has a habit of insisting on particular >>> implementations. For example, I completed the SML track, >>> and found that the test code ONLY worked with Poly and >>> not with any of the three SML implementations I already >>> had on my machine. Since you are doing this in Pharo, >>> I take it that exercism.io <http://exercism.io/> will insist on the Smalltalk >>> track being done in Pharo, and in that case it is >>> *nauseating* to use a Dictionary when you could use a >>> Point. Old-fashioned Smalltalk style would have been >>> to return something like >>> #(<direction> <x> <y>) >>> e.g. #(north 1 0), and I still prefer that. >>> >>> In fact *good* Smalltalk style for something like this >>> would be >>> test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth >>> robotSimulatorCalculator >>> moveTo: 0@0; >>> head: #north; >>> obey: 'A'. >>> self assert: robotSimulatorCalculator heading equals: #north. >>> self assert: robotSimulatorCalculator location equals: 0@1. >>> >>> -- We're starting to get the idea that identifiers like >>> robotSimulatorCalculator are not a very good idea when >>> simulatedRobot would do the job as well or better. >>> >>> (This is also pointing us towards Betrand Meyer's >>> Command/Query Separation principle, but we shan't >>> go there today.) >>> >>> This is important feedback to give to the exercism.io <http://exercism.io/> >>> people. The test code should use a SMALLTALK interface, >>> not a warmed-over JAVASCRIPT interface. >>> >>> Now, how do we map between direction *names* and >>> direction *points*? Well, we have to start by >>> laying down clearly what we *mean* by the directions. >>> >>> To move North one step is to add 1 to y and 0 to x. >>> (We know that from the appalling test case above.) >>> To move South one step is to add -1 to y and 0 to x. >>> (South is the opposite of North.) >>> To move East one step, oh we have a problem. >>> THIS NEEDS SPELLING OUT. And one of the things the >>> exercism.io <http://exercism.io/> exercises are HORRIBLY BAD AT is specifying >>> the problem. Nearly every single exercise I have tried, >>> I have been unable to tell what the problem is without >>> examining the test cases, and that is not the way >>> exercises are supposed to work. (Yeah, that's why I'm >>> screaming about it. I've taught a class using exercises >>> like this that were not of my writing and vague specifications >>> really upset the students. People who had taken the class >>> under someone else several years before were still angry >>> about it.) >>> >>> The geometric classes in Smalltalk were written to support >>> graphic user interfaces. And in user interfaces, the y >>> coordinate increases DOWN. So if we take the compass rose >>> and rotate it so that North is DOWN, it follows that >>> West is right and East is left. So >>> >>> To move East one step is to add -1 to x and 0 to y. >>> To move West one step is to add 1 to x and 0 to y. >>> >>> The chances are excellent that the problem specification >>> is inconsistent with this. Sigh. Let's proceed, though. >>> >>> North 0@1 >>> South 0@ -1 >>> East -1@0 >>> West 1@0 >>> >>> >>> pointToName: aPoint >>> ^aPoint x isZero >>> ifTrue: [aPoint y > 0 ifTrue: [#north] ifFalse: [#south]] >>> ifFalse: [aPoint x > 0 ifTrue: [#west ] ifFalse: [#east ]] >>> >>> nameToPoint: aSymbol >>> aSymbol = #north ifTrue: [^0 @ 1]. >>> aSymbol = #south ifTrue: [^0 @ -1]. >>> aSymbol = #west ifTrue: [^1 @ 0]. >>> aSymbol = #east ifTrue: [^-1 @ 0]. >>> aSymbol error: 'not a compass direction in lower case'. >>> >>> Another problem I had with exercism was a "Space-Age" >>> exercise where the README.md capitalised the planet names >>> but test_Space-Age.<whatever> insisted on lower case. >>> That might well happen here. >>> >>> Just for grins, >>> Dictionary>> >>> asPoint >>> ^(self at: 'x') @ (self at: 'y') >>> >>> Point>> >>> asDictionary >>> ^(Dictionary new) >>> at: 'x' put: self x; >>> at: 'y' put: self y; >>> yourself >>> >>> >>> >>> >>> On Mon, 8 Apr 2019 at 22:15, Roelof Wobben <r.wobben(a)home.nl <mailto:r.wobben@home.nl>> wrote: >>> Richard thanks. >>> >>> One thing I do not see direct. >>> >>> you said : >>> >>> >>> A direction could be represented by a pair of integers >>> dx, dy such that |dx|+|dy| = 1. It could also be >>> represented by a Point with integer components. >>> >>> for me a direction is the direction the robot is facing so something like north or east. >>> >>> the challenge also wants a output like this : >>> >>> test11_MovesTheRobotForward1SpaceInTheDirectionItIsPointingIncreasesTheYCoordinateOneWhenFacingNorth >>> | result | >>> result := robotSimulatorCalculator >>> moveDirection: 'north' >>> position: >>> (Dictionary new >>> add: 'x' -> 0; >>> add: 'y' -> 0; >>> yourself) >>> instructions: 'A'. >>> self >>> assert: result >>> equals: >>> (Dictionary new >>> add: 'direction' -> 'north'; >>> add: >>> 'position' >>> -> >>> (Dictionary new >>> add: 'x' -> 0; >>> add: 'y' -> 1; >>> yourself); >>> yourself) >>> >>> so how do I "convert" the point you are using to the text. >>> >>> Or do I misunderstood you somewhere wrong. >>> >>> Roelof >>> >>> >>> >>> >>> Op 8-4-2019 om 10:57 schreef Richard O'Keefe: >>>> One thing I have often seen and lamented is students >>>> writing excessively complicated code with way too many >>>> classes. There is a huge difference between >>>> "A Robot knows its position and direction." >>>> and >>>> "A Robot has-a Position and has-a Direction." >>>> The first is the important one. The second is >>>> an over-commitment to too many classses. For a >>>> problem like this, you really really do not want >>>> a Direction class, and you certainly have no use >>>> for double dispatch. >>>> >>>> A position can be represented by a pair of integers >>>> x, y. It could also be represented by a Point with >>>> integer components. >>>> >>>> A direction could be represented by a pair of integers >>>> dx, dy such that |dx|+|dy| = 1. It could also be >>>> represented by a Point with integer components. >>>> >>>> For movement, you need to be able to add the direction >>>> to the location, which could be simply >>>> x := x + dx. y := y + dy. >>>> or it could be >>>> position := position + direction. >>>> For turning, you need to be able to rotate a direction >>>> vector by ninety degrees. Now it so happens that >>>> Point has methods #leftRotated and #rightRotated. >>>> >>>> So we can do the following: >>>> a Robot has position (a Point) and direction (aPoint) >>>> position := 0 @ 0. >>>> direction := 0 @ 1. >>>> To move forward without turning: >>>> position := position + direction. >>>> To turn left without moving: >>>> direction := direction leftRotated. >>>> To turn right without moving: >>>> direction := direction rightRotated. >>>> To obey a sequence of characters, commands: >>>> commands do: [:each | >>>> each caseOf: { >>>> [$A] -> [--move forward--]. >>>> [$L] -> [--turn left--]. >>>> [$R] -> [--turn right--] >>>> }]. >>>> >>>> >>>> One of the key ideas in extreme programming is >>>> "You Ain't Gonna Need It", abbreviated to YAGNI! >>>> The idea is *DON'T* generalise beyond your immediate >>>> needs. In this case, for example, the likelihood of >>>> *this* program needing to deal with more general >>>> kinds of movement is ZERO. And the only reason for >>>> using Point here instead of just using a few simple >>>> assignment statements is that Point already exists, >>>> so costs nothing to write, and as a familiar class, >>>> code using it should be easy to read. >>>> >>>> If someone challenges you to do something counter-productive, >>>> refuse the challenge. >>>> >>>> On Mon, 8 Apr 2019 at 17:21, Roelof Wobben <r.wobben(a)home.nl <mailto:r.wobben@home.nl>> wrote: >>>> I can try to explain what I trying to solve. >>>> >>>> I have a Robot which can turn left, turn right or moveForward. >>>> >>>> now I have a string like 'LAR' >>>> >>>> that means the robot needs to turn left (l) , move forward one place (A) and turn left. >>>> and I have to keep track to which direction the robot is facing and on which coordinate it stands. >>>> >>>> so to summarize with the above string >>>> >>>> lets say the robot is facing north on coordinate (0,0) >>>> then it has to turn left , so its facing east and still on coordinate (0,0) >>>> then it has to move forward, so its still facing east but are on coordinate(0,1) >>>> then it has to turn right, so its facing north and on coordinate (0,1) >>>> >>>> and TimMacKinnon has challenged me to do this with double dispatch. >>>> >>>> So I think now I need a object Direction, a sub object North and a sub - sub object TurnLeft, turnRight and moveForward. >>>> >>>> So I can use double dispath first the direction North, East, South, West >>>> and then use double dispatch to find the right move. >>>> >>>> Roelof >>>> >>>> >>>> >>>> >>>> >>>> Op 8-4-2019 om 06:50 schreef Richard O'Keefe: >>>>> It would really REALLY **REALLY** help if we knew what >>>>> the heck you were trying to do. There is an excellent >>>>> chance that it is MUCH simpler than you think. If you >>>>> cannot show us the Smalltalk version of the problem, >>>>> can you show us the version for some other language? >>>>> >>>>> >>>>> On Sun, 7 Apr 2019 at 20:15, Roelof Wobben <r.wobben(a)home.nl <mailto:r.wobben@home.nl>> wrote: >>>>> Op 6-4-2019 om 15:15 schreef K K Subbu: >>>>> > On 06/04/19 4:49 PM, Roelof Wobben wrote: >>>>> >> Hello, >>>>> >> >>>>> >> I just learned double dispatch. >>>>> >> And now for the Robot challenge of exercism Tim has pointed me to >>>>> >> this >>>>> >> article(https://blog.metaobject.com/2019/04/accessors-have-message-obsessio… <https://blog.metaobject.com/2019/04/accessors-have-message-obsession.html>) >>>>> >> >>>>> >> but I fail to see how the move method looks like in that article. >>>>> >> I had a conversation with Tim in the exercism channel and the way he >>>>> >> explains it, it looks like double dispatch for me. >>>>> >> >>>>> >> Am I on the right track or do I oversee something here. >>>>> > unary methods like moveRight perform specific ops and are not >>>>> > parametric, so only a single dispatch, depending on the receiver, is >>>>> > needed. >>>>> > >>>>> > If you change it to move: aDistanceOrAngle, then performing requests >>>>> > like "move: 3 cms" or "move: 30 degrees" will depend not only on the >>>>> > receiver but also on the class of the argument. This would need double >>>>> > dispatch (aka multiple polymorphism). The first dispatch would be >>>>> > based on the receiver and the receiver's method would then dispatch it >>>>> > based on the class of the argument (i.e. Distance>>move or Angle>>move ) >>>>> > >>>>> > HTH .. Subbu >>>>> > >>>>> > >>>>> >>>>> >>>>> hmm, still stuck >>>>> >>>>> I have now a class Direction with as instance variables north, south, >>>>> east, west >>>>> and made the accessors. >>>>> >>>>> then I thought I need a initialize like this : >>>>> >>>>> initialize >>>>> north = Direction( 0, -1). >>>>> east = Direction( 1, 0). >>>>> south = Direction( 0, 1). >>>>> west = Direction(-1, 0). >>>>> >>>>> but the Direction (0,-1) is a problem . the compiler does not like the >>>>> (0,-1) part >>>>> >>>>> to give you the big picture. I have a Robot which can turnRight , >>>>> turnLeft and moveForward and I try to understand how the page would work >>>>> in my case. >>>>> >>>>> So I have a object Direction as described above and a Object MoveForward >>>>> which is a subobject of Direction. >>>>> MoveForward has only 1 method : >>>>> >>>>> IsMove >>>>> ^ 'A' >>>>> >>>>> Roelof >>>>> >>>>> >>>> >>> >> >

7 9

[Pharo 8.0] Build #220: 3168-pharoversion-file-is-hardcoding-wrong-version
by ci-pharo-ci-jenkins2＠inria.fr April 11, 2019

April 11, 2019

There is a new Pharo build available! The status of the build #220 was: FAILURE. The Pull Request #3169 was integrated: "3168-pharoversion-file-is-hardcoding-wrong-version" Pull request url: https://github.com/pharo-project/pharo/pull/3169 Issue Url: https://github.com/pharo-project/pharo/issues/3168 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0] Build #156: 3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat-
by ci-pharo-ci-jenkins2＠inria.fr April 11, 2019

April 11, 2019

There is a new Pharo build available! The status of the build #156 was: SUCCESS. The Pull Request #3149 was integrated: "3148-backport-2395-to-Pharo-70--Non-ASCII-class-and-author-names-break-SourceFileArraygetPreambleFromat-" Pull request url: https://github.com/pharo-project/pharo/pull/3149 Issue Url: https://pharo.fogbugz.com/f/cases/3148 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #219: 2975-Problem-when-you-read-an-mcz
by ci-pharo-ci-jenkins2＠inria.fr April 11, 2019

April 11, 2019

There is a new Pharo build available! The status of the build #219 was: FAILURE. The Pull Request #3159 was integrated: "2975-Problem-when-you-read-an-mcz" Pull request url: https://github.com/pharo-project/pharo/pull/3159 Issue Url: https://github.com/pharo-project/pharo/issues/2975 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

About <primitive: 'primitiveCompareString' module: 'MiscPrimitivePlugin'>
by StÃ©phane Ducasse April 11, 2019

April 11, 2019

Hi I recall that clement told me that returning 1,2 or 3 instead of negative, zero, positive was slow. And I wonder if the primitive got change to the logic clement proposed? Could we not introduce another primitive and use it from the image? compare: string1 with: string2 collated: order "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating order of characters given by the order array." | len1 len2 c1 c2 | <primitive: 'primitiveCompareString' module: 'MiscPrimitivePlugin'> <var: #string1 declareC: 'unsigned char *string1'> <var: #string2 declareC: 'unsigned char *string2'> <var: #order declareC: 'unsigned char *order'> len1 := string1 size. len2 := string2 size. 1 to: (len1 min: len2) do: [:i | c1 := order at: (string1 basicAt: i) + 1. c2 := order at: (string2 basicAt: i) + 1. c1 = c2 ifFalse: [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]]. len1 = len2 ifTrue: [^ 2]. len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3]. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

5 11

[Pharo 7.0] Build #155: 2975-Problem-when-you-read-an-mcz-pharo7
by ci-pharo-ci-jenkins2＠inria.fr April 11, 2019

April 11, 2019

There is a new Pharo build available! The status of the build #155 was: SUCCESS. The Pull Request #3160 was integrated: "2975-Problem-when-you-read-an-mcz-pharo7" Pull request url: https://github.com/pharo-project/pharo/pull/3160 Issue Url: https://pharo.fogbugz.com/f/cases/2975 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #218: Added comments to class ExceptionTests and ExceptionTester
by ci-pharo-ci-jenkins2＠inria.fr April 11, 2019

April 11, 2019

There is a new Pharo build available! The status of the build #218 was: FAILURE. The Pull Request #3162 was integrated: "Added comments to class ExceptionTests and ExceptionTester" Pull request url: https://github.com/pharo-project/pharo/pull/3162 Issue Url: https://github.com/pharo-project/pharo/issues/3161 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

New stable VM for Pharo8?
by Guillermo Polito April 11, 2019

April 11, 2019

Hi all, Esteban, In the last sprint with Pablo and Pierre we have detected several misbehaviours with files. The issue was particular reproducible when trying to run iceberg tests: the VM kind of ran out of slots for opening files. The strangest thing is that the leaks seemed to happen when deleting directories, so we had a look at the changes done to iterate directories, get file attributes and so on. While on the FileReference code everything seemed ok, we have observerd with `lsof` that still several directories remained open even after deleting them. Latest VM fixes this issue but contains another one related to Metal rendering, which prevents rendering in OSX versions < than High Sierra. Tracking the issue a bit, this seems to be a bug in the FileAttributes plugin that was fixed by this PR by alistair ( https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc2… ). We have tested that particular commit ( a838346b1a67712cc28298534dafbd0c26ea34fb <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a838346b1a67712cc2…>) and this one contains Alistair's fixes but not yet the new rendering using Metal. We have been testing that VM since yesterday and it seems stable, what do you think about marking it stable for Pharo8? Regarding Pharo7, Pharo7's stable VM is the same as Pharo8's, so it contains the same issue. However, since on the image side the code does not use the problematic primitives, we do not think we need to change the VM for Pharo7 (yet). However, there is seemingly a fix for directories containing blanks, maybe Alistair can give us some input here? :) Ideas? Thanks, Guille and Pablo

5 12

FreeType and the over amorous glyphs (overlapping)
by tesonep＠gmail.com April 11, 2019

April 11, 2019

Hello, After checking the problem with Guille, we have the hypothesis of the source of the problem. We have seen that accessing Free Type is not thread-safe. Basically, the FTFace holds a structure that is filled up with the glyph and its information. As this structure is part of the Font Face (a font face is a font plus size and attributes), only one request to a glyph can be executed at the time. As we are sharing the same font in many places, you will be starting to see the problem. Also, we have seen that there many accesses to the glyphs outside the UI process. This problem started to appear as we starting to use Calypso (but it is not limited to it), as Calypso uses lazy tabs. The creation of these tabs is done outside the UI process. This is only a hack to test our hypothesis. To fix it correctly we will have to rewrite the drawing of the glyphs and synchronize the access to the glyph data information. Also, we want to do it in a way that does not penalize the processing in the UI process. I have only patched the code that is used by the rendering of morphic, other renderings like Athens or any other user using FT should be correctly rewritten. Once we are sure that synchronizing the access to FT fixes the problem, we will do a real fix not a dirty hack like this. I will be testing this new Image to see if there is an improvement. I will really love you try to use this image and tell me if you still find the problem. There is a PR generating a Pharo8 image (it is called wrong, but... it is a Pharo8) 32 bits ===== https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… 64 bits ===== https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… If somebody is willing to use it in Pharo 7, I can create a PR against Pharo7 to generate patched P7 images. Thanks! -- Pablo Tesone. tesonep(a)gmail.com

6 10

[Pharo 8.0] Build #217: 3006-When-a-test-fails-open-the-debugger-on-the-test-instead-of-on-Objectassert
by ci-pharo-ci-jenkins2＠inria.fr April 10, 2019

April 10, 2019

There is a new Pharo build available! The status of the build #217 was: SUCCESS. The Pull Request #3116 was integrated: "3006-When-a-test-fails-open-the-debugger-on-the-test-instead-of-on-Objectassert" Pull request url: https://github.com/pharo-project/pharo/pull/3116 Issue Url: https://github.com/pharo-project/pharo/issues/3108 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #216: 3140-Fixing-all-executable-comments
by ci-pharo-ci-jenkins2＠inria.fr April 10, 2019

April 10, 2019

There is a new Pharo build available! The status of the build #216 was: FAILURE. The Pull Request #3141 was integrated: "3140-Fixing-all-executable-comments" Pull request url: https://github.com/pharo-project/pharo/pull/3141 Issue Url: https://github.com/pharo-project/pharo/issues/3140 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] [Pharo-users] ARM vm limitations ?
by Mariano Martinez Peck April 10, 2019

April 10, 2019

On Mon, Mar 18, 2019 at 8:26 AM Albrecht Baur via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Hi, I'd like to play around with pharo on ARM devices (like a > HummingBoard, the ones from ODROID or one of the beagleboards). But I am > not sure if I have to take care of the ARM architecture version (ARMv6 / > ARMv7 / ARMv8) when choosing my toy. > > I found this vm: > http://files.pharo.org/vm/pharo-spur32/linux/armv6/ > Is it only for armv6 like the folder name says or is ARMv7 and ARMv8 > working too? > > Are there any limitations I should know before choosing a ARM device? > > Is there a vm for 64bit (aarch64)? > Hi Albrecht, I am also interested in this answer. In general, I am interested in IoT support for Smalltalk. The only thing I found aside from ARMv6 is this: https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/build.linux32ARM… But I don't know what's the status of it. You may have more chances to get an answer with the vm list: <vm-dev(a)lists.squeakfoundation.org> Or maybe Pharo dev list. Cheers, -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

2 1

Performance Issues
by tesonep＠gmail.com April 9, 2019

April 9, 2019

Hi, this will be a long mail. I have organized it in different sections. Resume: ====== - There are performance issues in Pharo 7. - I have made benchmarks. - With Guille we made an improvement in saving source code in methods. - More improvements to come. - Automation and CI in the future. Background ========= Since the release of Pharo 7 (and before it), it was notorious that there exists a performance regression in the normal execution of the image. By checking the usual operations, we have seen ( and many have also detected) that there was an issue with the loading, compilation, and unloading of code. Also with the creation of classes, traits and the use of slots. Benchmarks ========= Although we were sure that there is a performance regression, we have to show it in a way we can test it and measure it. If we cannot measure it or repeat its execution it is worthless. For doing so, I have created an initial set of micro-benchmarks to cover normal operations of the image. The set of benchmarks is available here: https://github.com/tesonep/pharo-benchmarks These benchmarks are developed on top of SMark, only adding a command line tool and the ability to generate a CSV file. The idea is to run the benchmarks in different versions of Pharo an assert that we are not breaking anything. The first results were basically a nightmare, some operations take almost 20 times more in Pharo 7. Especially, the ones that are compiling methods. In the attached document, there is the detail of all the benchmarks, the different results and the analysis of the improvements and regressions (Positive percentages are regressions (more time), negative are improvements (less time)). I have checked the results in OSX with 64 bits images. But as the problem is in pure Smalltalk implementations the problems are (and the solutions) cross platforms. First Improvement ============== Having the benchmarks, it was easy to start looking for the problems. Thanks to the help of Guille we have detected some problems in the implementation of SourceFile. Objects of this class have the responsibility to handle the save of the source code when a method is modified. Improving this implementation we have gotten to results similar to Pharo 6 in the compilation of methods. Comparing a stock Pharo8 image with the one with the fix, we have the following improvements: AddingAnInstanceVariableToAClassWithASubclass -3.96% AddingAnInstanceVariableToAClassWithoutASubclassAndInstances -15.91% AddingAnInstanceVariableToAClassWithoutSubclasses -28.50% ClassAndSubclassCreation -25.67% ClassUsingATrait -90.05% SimpleClassCreation -26.55% TraitCreation -92.95% TraitCreationUsingOtherTrait -91.68% CompileAMethodAndModifyIt -32.92% CompileAMethodInAClassUsingATrait -83.28% CompileAMethodInATraitNotUsed -85.12% CompileAMethodInATraitUsed -88.16% CompileANewMethod -40.73% CompileANewMethodUsingInstanceVariable -33.93% MethodAccessingAGlobal -47.57% Again there are more details in the attached file. Also, we have ported this fix to Pharo 7. Next Steps ======== - Making it a part of the CI infrastructure: making it run in each PR and build to detect regressions in the changes. - Adding more micro and macro benchmarks. I have a list of things to test, but I am open to more: # Micro - Slot Implementation - Process handling - Refactorings - Files (open / write / read) # Macro - Loading: Moose / Seaside - Recompile All - Condense Sources - Startup - Shutdown We also know that there are platform related issues (especially Windows), so the idea it will be the same, build a benchmark, measure it, improve it. The idea is to have a more robust way of detecting and handling the performance of Pharo. Of course, I am open to all your comments. Cheers, Pablo

9 9