February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] here's a curio for compiler mavens...

by Eliot Miranda

OK, I fixed this (a pleasant Monday afternoon distraction) (at least I *think* I've fixed it; I still have to check the decompiler). But... in doing so I realised I had to fix CompiledMethod>>#= since I needed to see exactly which methods the compiler change affected (just committed as Kernel-eem.669). In doing this I noticed that recent compiler changes have not been applied by recompiling affected methods in the system. If you look at Behavior>>#sourceMatchesBytecodeAt: it uses CompiledMethod>>#= to check that the compiler's output remains unchanged. In the 4.3 trunk image with CompiledMethod>>#= fixed, sourceMatchesBytecodeAt: reports that some 19654 methods need recompiling: (SystemNavigation new allSelect: [:m| (m methodClass sourceMatchesBytecodeAt: m selector) not]) size 19654 Being selective in recompiling, via e.g. SystemNavigation new allSelect: [:m| (m methodClass sourceMatchesBytecodeAt: m selector) ifFalse: [m methodClass recompile: m selector]. false] one gets to the desired (SystemNavigation new allSelect: [:m| (m methodClass sourceMatchesBytecodeAt: m selector) not]) size 0 So the question is should we add an update that does the selective recompile? I think we should, e.g. by committing a version of Compiler that contains the selective recompile as a post-script. Agreed? On Mon, Feb 13, 2012 at 11:58 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > (whitewash alert) I just had occasion to look at the bytecode > generated by the standard compiler for HashedCollection > class>>#goodPrimeAtLeast:. Here's the source, with the issue in bold: > > goodPrimeAtLeast: lowerLimit > "Answer the next good prime >= lowerlimit. > If lowerLimit is larger than the largest known good prime, > just make it odd." > | primes low mid high prime | > primes := self goodPrimes. > low := 1. > high := primes size. > lowerLimit > (primes at: high) ifTrue: [ > ^lowerLimit bitOr: 1 ]. > [ high - low <= 1 ] whileFalse: [ > mid := high + low // 2. > prime := primes at: mid. > prime = lowerLimit ifTrue: [ ^prime ]. > *prime < lowerLimit* > * ifTrue: [ low := mid ]* > * ifFalse: [ high := mid ]* ]. > (primes at: low) >= lowerLimit ifTrue: [ ^primes at: low ]. > ^primes at: high > > The code for this sequence is > 58 <15> pushTemp: 5 > 59 <10> pushTemp: 0 > 60 <B2> send: < > 61 <9B> jumpFalse: 66 > 62 <13> pushTemp: 3 > *63 <81 42> storeIntoTemp: 2* > 65 <92> jumpTo: 69 > 66 <13> pushTemp: 3 > *67 <81 44> storeIntoTemp: 4* > *69 <87> pop* > > where-as the following would be better: > > 58 <15> pushTemp: 5 > 59 <10> pushTemp: 0 > 60 <B2> send: < > 61 <9B> jumpFalse: 66 > 62 <13> pushTemp: 3 > 63 <82 42> popIntoTemp: 2 > 65 <92> jumpTo: 69 > 66 <13> pushTemp: 3 > 67 <82 44> popIntoTemp: 4 > > The reason is that the code generator favours using a single pop for both > arms of the if: > > MessageNode>>sizeCodeForIf: encoder value: forValue > | thenExpr elseExpr branchSize thenSize elseSize | > thenExpr := arguments at: 1. > elseExpr := arguments at: 2. > (forValue > or: [(thenExpr isJust: NodeNil) > or: [elseExpr isJust: NodeNil]]) not > "(...not ifTrue: avoids using ifFalse: alone during this compile)" > ifTrue: *"Two-armed IFs forEffect share a single pop"* > [^super sizeCodeForEffect: encoder]. > ... > > MessageNode>>emitCodeForIf: stack encoder: encoder value: forValue > | thenExpr thenSize elseExpr elseSize | > thenSize := sizes at: 1. > elseSize := sizes at: 2. > (forValue not and: [elseSize * thenSize > 0]) ifTrue: > *"Two-armed IFs forEffect share a single pop"* > [^super emitCodeForEffect: stack encoder: encoder]. > > It would be nice if this only happened if doing so actually reduced the > size of the generated code. > -- > best, > Eliot > > -- best, Eliot

Feb. 14, 2012

Re: [Pharo-project] SocketPlugin: ignoring unknown option 'TCP_CORK'

by Eliot Miranda

On Mon, Feb 13, 2012 at 1:14 PM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 13.02.2012 19:25, Eliot Miranda wrote: > >> >> >> On Sun, Feb 12, 2012 at 11:59 PM, Philippe Marschall >> <philippe.marschall(a)netcetera.**ch <philippe.marschall(a)netcetera.ch> >> <mailto:philippe.marschall@**netcetera.ch<philippe.marschall(a)netcetera.ch>>> >> wrote: >> >> On 02/13/2012 12:08 AM, Eliot Miranda wrote: >> >> >> >> >> >> Hi Phillipe, >> >> you'll need to add TCP_CORK to the list of known options in >> platforms/unix/plugins/__**SocketPlugin/sqUnixSocket.c >> >> >> >> Do you accept patches? >> >> >> With gratitude :) >> > > There you go, has also TCP_NOPUSH for Mac OS (no, I didn't actually test > that). > Thanks! While I'm at it, anyone think any other socket options should be added? > > Cheers > Philippe -- best, Eliot

Feb. 13, 2012

Re: [Pharo-project] NB How can I pass a NULL argument?

by StÃ©phane Ducasse

Thanks for the question. Which version do you use? Stef > Hello list, > > I want to call the following C function using NativeBoost: > > const char* uenum_next(UEnumeration * en, int32_t * resultLength, UErrorCode * status) > > According to the (icu4c) documentation you can pass NULL for the resultLenth argument [1]. But when I try: > > self nbCall: #( char* uenum_next_48( self, nil, ICUErrorCodeNB* anErrorCode ) ) module: 'libicuuc.dylib' > > My image craches. Does anyone know what I'm doing wrong? > > Jan. > > [1] http://icu-project.org/apiref/icu4c/uenum_8h.html#a99298eabaa3874cdfd9793b2…

Feb. 13, 2012

[Pharo-project] 24-25 May 2012: Pharo conference registration is ready

by StÃ©phane Ducasse

http://pharoconference.eventbrite.com/ The Pharo core team organises a Pharo Conference hosted at INRIA Lille Nord Europe located at Villeneuve D'ascq (close to Lille). Pharo is an open-source Smalltalk http://www.pharo-project.org The goals of the conference is to bring companies, developers and users together. You are invited to propose a talk on - your business with pharo - a technical presentation of a framework or solution you built with pharo - experience reports Please contact stephane.ducasse(a)inria.fr and marcus.denker(a)inria.fr for possible presentations. Stef

Feb. 13, 2012

[Pharo-project] NB How can I pass a NULL argument?

by Jan van de Sandt

Hello list, I want to call the following C function using NativeBoost: const char* uenum_next(UEnumeration * en, int32_t * resultLength, UErrorCode * status) According to the (icu4c) documentation you can pass NULL for the resultLenth argument [1]. But when I try: self nbCall: #( char* uenum_next_48( self, nil, ICUErrorCodeNB* anErrorCode ) ) module: 'libicuuc.dylib' My image craches. Does anyone know what I'm doing wrong? Jan. [1] http://icu-project.org/apiref/icu4c/uenum_8h.html#a99298eabaa3874cdfd9793b2…

Feb. 13, 2012

Re: [Pharo-project] SocketPlugin: ignoring unknown option 'TCP_CORK'

by Philippe Marschall

On 13.02.2012 19:25, Eliot Miranda wrote: > > > On Sun, Feb 12, 2012 at 11:59 PM, Philippe Marschall > <philippe.marschall(a)netcetera.ch > <mailto:philippe.marschall@netcetera.ch>> wrote: > > On 02/13/2012 12:08 AM, Eliot Miranda wrote: > > > > > > Hi Phillipe, > > you'll need to add TCP_CORK to the list of known options in > platforms/unix/plugins/__SocketPlugin/sqUnixSocket.c > > > Do you accept patches? > > > With gratitude :) There you go, has also TCP_NOPUSH for Mac OS (no, I didn't actually test that). Cheers Philippe

Feb. 13, 2012

Re: [Pharo-project] how to load rb in pharo 1.4?

by Esteban Lorenzano

i don't know... but loading ob loads rb too :) El 13/02/2012, a las 5:44p.m., Tudor Girba escribiÃ³: > I could not find it. > > Could someone please point me to the magic invocation? > > Doru > > > On 13 Feb 2012, at 21:21, Mariano Martinez Peck wrote: > >> >> >> On Mon, Feb 13, 2012 at 9:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> mariano and guillermo did a configuration to load >> >> Guille did it. I was just a lucky beta tester :) >> >> shout >> OC >> RB >> in 1.4 >> >> Check in the mailing-list >> >> Stef >> On Feb 13, 2012, at 9:11 PM, Tudor Girba wrote: >> >>> Hi, >>> >>> I lost track of the latests developments around RB. What is the way to load RB in Pharo 1.4? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "What we can governs what we wish." >>> >>> >>> >>> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > >

Feb. 13, 2012

Re: [Pharo-project] how to load rb in pharo 1.4?

by Tudor Girba

I could not find it. Could someone please point me to the magic invocation? Doru On 13 Feb 2012, at 21:21, Mariano Martinez Peck wrote: > > > On Mon, Feb 13, 2012 at 9:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > mariano and guillermo did a configuration to load > > Guille did it. I was just a lucky beta tester :) > > shout > OC > RB > in 1.4 > > Check in the mailing-list > > Stef > On Feb 13, 2012, at 9:11 PM, Tudor Girba wrote: > > > Hi, > > > > I lost track of the latests developments around RB. What is the way to load RB in Pharo 1.4? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "What we can governs what we wish." > > > > > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Obvious things are difficult to teach."

Feb. 13, 2012

Re: [Pharo-project] [squeak-dev] here's a curio for compiler mavens...

by Igor Stasenko

On 13 February 2012 20:58, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > Â Â (whitewash alert) Â I just had occasion to look at the bytecode generated > by the standard compiler for HashedCollection class>>#goodPrimeAtLeast:. > Â Here's the source, with the issue in bold: > > goodPrimeAtLeast: lowerLimit > "Answer the next good prime >= lowerlimit. > If lowerLimit is larger than the largest known good prime, > just make it odd." > | primes low mid high prime | > primes := self goodPrimes. > low := 1. > high := primes size. > lowerLimit > (primes at: high) ifTrue: [ > ^lowerLimit bitOr: 1 ]. > [ high - low <= 1 ] whileFalse: [ > mid := high + low // 2. > prime := primes at: mid. > prime = lowerLimit ifTrue: [ ^prime ]. > prime < lowerLimit > ifTrue: [ low := mid ] > ifFalse: [ high := mid ] ]. > (primes at: low) >= lowerLimit ifTrue: [ ^primes at: low ]. > ^primes at: high > > The code for this sequence is > 58 <15> pushTemp: 5 > 59 <10> pushTemp: 0 > 60 <B2> send: < > 61 <9B> jumpFalse: 66 > 62 <13> pushTemp: 3 > 63 <81 42> storeIntoTemp: 2 > 65 <92> jumpTo: 69 > 66 <13> pushTemp: 3 > 67 <81 44> storeIntoTemp: 4 > 69 <87> pop > > where-as the following would be better: > > 58 <15> pushTemp: 5 > 59 <10> pushTemp: 0 > 60 <B2> send: < > 61 <9B> jumpFalse: 66 > 62 <13> pushTemp: 3 > 63 <82 42> popIntoTemp: 2 > 65 <92> jumpTo: 69 > 66 <13> pushTemp: 3 > 67 <82 44> popIntoTemp: 4 > [ (a) ifTrue:[ b] ifFalse: [c] ] value should answer b or c (depending on a) now if you use pop instead of store, it will break. Of course in while loop, the [ loop-body closure ] value is always discarded, so yes we can eliminate extra pop. But you can do even more: 1. loop head ... .... 61 <9B> jumpFalse: 66 62 <13> pushTemp: 3 63 <82 42> popIntoTemp: 2 ** 65 <92> jumpTo: 1 66 <13> pushTemp: 3 67 <82 44> popIntoTemp: 4 69 ... jumpTo: 1 so, we can have 1 less jump when code enters first branch. > The reason is that the code generator favours using a single pop for both > arms of the if: > > MessageNode>>sizeCodeForIf: encoder value: forValue > | thenExpr elseExpr branchSize thenSize elseSize | > thenExpr := arguments at: 1. > elseExpr := arguments at: 2. > (forValue > or: [(thenExpr isJust: NodeNil) > or: [elseExpr isJust: NodeNil]]) not > "(...not ifTrue: avoids using ifFalse: alone during this compile)" > ifTrue: Â "Two-armed IFs forEffect share a single pop" > [^super sizeCodeForEffect: encoder]. > ... > > MessageNode>>emitCodeForIf: stack encoder: encoder value: forValue > | thenExpr thenSize elseExpr elseSize | > thenSize := sizes at: 1. > elseSize := sizes at: 2. > (forValue not and: [elseSize * thenSize > 0]) ifTrue: > "Two-armed IFs forEffect share a single pop" > [^super emitCodeForEffect: stack encoder: encoder]. > > It would be nice if this only happened if doing so actually reduced the size > of the generated code. > -- > best, > Eliot > > > > -- Best regards, Igor Stasenko.

Feb. 13, 2012

Re: [Pharo-project] how to load rb in pharo 1.4?

by Mariano Martinez Peck

On Mon, Feb 13, 2012 at 9:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > mariano and guillermo did a configuration to load > Guille did it. I was just a lucky beta tester :) > shout > OC > RB > in 1.4 > > Check in the mailing-list > > Stef > On Feb 13, 2012, at 9:11 PM, Tudor Girba wrote: > > > Hi, > > > > I lost track of the latests developments around RB. What is the way to > load RB in Pharo 1.4? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "What we can governs what we wish." > > > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

Feb. 13, 2012