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

About <primitive: 'primitiveCompareString' module: 'MiscPrimitivePlugin'>

by StÃ©phane Ducasse

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

April 10, 2019

[Pharo 8.0] Build #216: 3140-Fixing-all-executable-comments

by ci-pharo-ci-jenkins2＠inria.fr

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…

April 10, 2019

[OT] (slightly) What makes other dialects "enjoyable" for you? (WAS: difference between double dispatch...)

by Esteban Lorenzano

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 >>>>> >>>>> >>>> >>> >> >

April 10, 2019

Re: [Pharo-dev] [Pharo-users] ARM vm limitations ?

by Esteban Lorenzano

AFAIK the armv7 is in the works, being the limitant now the FFI support? But not sure :) Esteban > On 9 Apr 2019, at 22:48, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Mon, Mar 18, 2019 at 8:26 AM Albrecht Baur via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@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/ <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… <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 <mailto:vm-dev@lists.squeakfoundation.org>> > Or maybe Pharo dev list. > > Cheers, > > -- > Mariano Martinez Peck > Email: marianopeck(a)gmail.com <mailto:marianopeck@gmail.com> > Twitter: @MartinezPeck > LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/ <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/>

April 10, 2019

Re: [Pharo-dev] Performance Issues

by Mariano Martinez Peck

Hola Pablito :) That sounds amazing. Great job!! About "Automation and CI in the future.", do you know if Smalltalk CI supports something for this? Thanks! On Tue, Apr 2, 2019 at 11:22 AM tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > 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 > -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/

April 9, 2019

Re: [Pharo-dev] [Pharo-users] ARM vm limitations ?

by Mariano Martinez Peck

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/

April 9, 2019

Re: [Pharo-dev] Performance Issues

by Francisco Ortiz PeÃ±aloza

This is great news! Thanks, Francisco On Wed, 3 Apr 2019 at 09:47 Ben Coman <btc(a)openinworld.com> wrote: > Thanks for this great initiative Pablo. > cheers -ben > > On Tue, 2 Apr 2019 at 22:23, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > >> 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. >> >> -- Sent from the past

April 8, 2019

Re: [Pharo-dev] IceGenericError: failed to stat file, Pharo LAUNCHER images and long file names on Windows

by Guillermo Polito

Hi, On Mon, Apr 1, 2019 at 9:26 PM Torsten Bergmann <astares(a)gmx.de> wrote: > If one downloads images with Launcher on Windows and accepts default names > like "Pharo 7.0 - 32bit (stable)" this will end up in path names like > > "C:/Users/Admin/Documents/Pharo/images/Pharo 7.0 - 32bit (stable)" > > The dot and space combination in such files can later make trouble when > downloading projects (like Seaside) using Iceberg and libgit and leading > later to the "IceGenericError: failed to stat file ... The filename or > extension is too long" problem. > > I guess the dot in combination with spaces in the name is sometimes seen > as the path element on current directory. > > If one gives an own name like "LatestPharo7" in Launcher (having > C:/Users/Admin/Documents/Pharo/images/LatestPharo7 then) Seaside loads > even from the FileTree format. > Wow, this is weird :) Would this be related too to this: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e8f235ef313990acae… ? > As many people prefer to use Launcher now these days they might easily hit > this problem. > > I opened an issue already for Launcher so this discussion here on ML is > watched: > https://github.com/pharo-project/pharo-launcher/issues/327 > > Feedback and tests from Windows users are welcomed. > > But still, the bug looks like a libgit bug, doesn't it? I have in my hyper long TODO list to try to enhance libgit's windows support and contribute it back to libgit...

April 4, 2019

[Pharo 8.0] Build #215: 3049-MemoryDirectoryEntry is not compatible to DiskDirectoryEntry regarding #size

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #215 was: SUCCESS. The Pull Request #3052 was integrated: "3049-MemoryDirectoryEntry is not compatible to DiskDirectoryEntry regarding #size" Pull request url: https://github.com/pharo-project/pharo/pull/3052 Issue Url: https://github.com/pharo-project/pharo/issues/3049 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 4, 2019

Re: [Pharo-dev] Green tests

by David T. Lewis

Also useful for "quick and dirty" debugging with concurrent processes: OSProcess trace: 'my debugging note' This prints to console, identifying the process, receiver, method, and whatever additional notes you may want to add. Dave On Wed, Apr 03, 2019 at 07:34:22AM +0200, Tudor Girba wrote: > Instead of printing, you can also use Beacon. We actually developed Beacon specifically to be able to debug a parallel distributed system. > > Cheers, > Doru > > > On Apr 2, 2019, at 11:56 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > > > > > On Tue, 2 Apr 2019 at 23:36, ducasse <stepharo(a)netcourrier.com> wrote: > > I???m inherently race condition incompatible and just avoid concurrent programming because I???m too dull on this. > > > > I've solved a few Pharo race conditions before, so just a tip (that you maybe already know). > > You can't troubleshoot a race condition by standard debugging, because it alters the timing. > > Best that I've done before is resorting to plain old print-line tracing between every line of the suspect code, > > or the equivalent threadsafe collection if its not a hard crash. > > e.g.... > > someMethod > > threadsafeCollection add: "methodname-A" , testCondition > > original method line 1 > > threadsafeCollection add: "methodname-B", testCondition > > original method line 2 > > threadsafeCollection add: "methodname-C", testCondition > > > > and then looking for cyclic patterns in that data and breaks in those patterns. > > > > I can have a look in a few weeks. Right now working 13 hour days to the end of the week > > and then vacationing in China for 10 days. > > > > -- > www.feenk.com > > "Sometimes the best solution is not the best solution." >

April 3, 2019