- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] issue with Nautilus?

by Nicolai Hess

Can you attach or send me the .st file you filed in. 2014-07-02 17:09 GMT+02:00 Sebastian Sastre <sebastian(a)flowingconcept.com>: > Iâve opened this: > > https://pharo.fogbugz.com/f/cases/13456/Nautilus-showing-methods-that-are-n… > > quite strange. First time I see something like that > > > > > sebastian <https://about.me/sebastianconcept> > > o/ > > blog: http://sebastianconcept.com > LinkedIn: http://www.linkedin.com/in/sebastiansastre > github: https://github.com/sebastianconcept > > > > > >

July 3, 2014

Re: [Pharo-dev] Pharo running with spur (work in process)

by Tudor Girba

Fantastic. Thanks for all the effort to everyone involved! Doru On Wed, Jul 2, 2014 at 4:13 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Iâve been working on prepare Pharo to run with the new Spur VMâ¦ and > finally this week Guille and I sit together and make a huge advance :) > here a screenshot of pharo 4 running with spur: > > for more information, same image before migration, with a regular cogvm > gives this numbers: '1297023432 bytecodes/sec; 161029354 sends/secâ, so > that means that the tiny benchmarks run at 166% the speed of the old vmâ¦ > Of course this is just one benchmark, but Iâm very impressed :) > > Now, it is still not usable but Iâm confident I can put a jenkins job to > work very soon :) > > Esteban > > ps: before you start asking: Spur WILL NOT be available for Pharo3, it > will be part of Pharo4. > > > > -- www.tudorgirba.com "Every thing has its own flow"

July 3, 2014

New Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3029/. I've taken down the 3021 and 3024 VMs as their LargeIntegers code was badly broken. That's fixed now. The major changes are that Spur now correctly handles forwarding in primitives invoked from machine code, and that sends to Characters have the expected performance. CogVM binaries as per VMMaker.oscog-eem.797/r3029 Fix mixup of old & young spaces in primitiveVMParameter, and comment some new parameters. Fix return types for positive[64/32]BitValueOf:. positive32BitValueOf: must answer a usqInt, positive64BitValueOf: must answer a usqLong. Use positiveMachineIntegerValueOf: to decode arg in primitiveNewWithArg and ensure positiveMachineIntegerValueOf: is inlined there-in. Spur: Fix inline cache for Characters in Spur. Existing code failed all machine code sends to characters, creating PICs at those send sites which failed back to the interpreter. Implement forwarder following on primitive failure for all primitive calls from machine code. Allow the JIT to not compile primitiveDoNamedPrimitiveWithArgs to avoid any potential complications. Have spur's fetchClassOfNonImm: answer nilObj for forwarders to avoid assert fails. Fix assert fails in updateStateOfSpouseContextForFrame:WithSP: and elsewhere with forwarders. Add read barriers to primitiveSuspend and synchronousSignal:'s myList access, because the process list manipulation routines do no checking. Add assert checks for forwarders in the process list manipulation routines. Fix StackInterpreter>>actuallyFollowNecessaryForwardingInMethod:literalCount: so that it no longer corrupts the methodClassAssociation. Rewrite all the semaphore installing primitives to fail if the semaphore arg is neither a semaphore or nil instead of assuming if its not a semaphore it must be nil, so as to fail and retry when semaphores are forwarded (as they are when Semaphore is redefined). Implement isSemaphoreOop:/Obj: in the object memories to abstract away the code. Base Spur's on the class index of splObj: ClassSemaphore, avoiding the table lookup to derive the class. Make checkForEventsMayContextSwitch: treat all its semaphores consistently. These changes allow Cog Spur to redefine Process and/or Semaphore and not hang. Fix sign and overflow issues in instantiating larger objects and determining the size of large instances. Fix some freeChunk accesses that used fetchPointer:ofObject:. Make sure forwarders have accurate slot counts, bumping it to 1 if it was zero. Plugins: Fix LargeIntegersPlugin>>isNormalized: for forwarders, no longer assuming that if its arg isn't a SmallInteger it must be a large integer. Squash an assert fail in lengthOf:format: on forwarders by using numSlotsOfAny:. Fix the shift for divide issues in the LargeIntegersPlugin. Change the SmartSyntaxPluginCodeGenerator to generate code that ifdefs out the remapOop:in: rigmarole on Spur. Windows: Set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header of the Windows executables to allow e.g. Spur to allocate more than 2Gb. Slang: Rip out the UseRightShiftForDivide optimization. It gets unsigned division wrong, and C compilers can and will optimize this correctly themselves. -- best, Eliot

July 3, 2014

Re: [Pharo-dev] PillarHub

by mikefilonov

Hi everyone, Thanks! I think Alexey will be really happy to read this thread when he is back to university in a month :) As for versioning yes we plan to implement it. I think it should be easy as Monticello implement it so it should be possible to reuse. I need to see the code though. Also Damien gave a great idea to add a configuration for a hub to sync it's content to GitHub so cloud could be used for backup/versioning. I think it is a perfect solution but I don't see yet how it can be implemented. Is any one knows classes to talk to github? Thanks for a feedback guys! Any suggestions on future plans for PillarHub are welcomed. -- View this message in context: http://forum.world.st/PillarHub-tp4766012p4766256.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 3, 2014

Re: [Pharo-dev] Pharo running with spur (work in process)

by kilon alios

For me its 99 milliseconds with my iMac (Pharo 3) which is a 3.2 Intel Core i5 and 8GB 1600Mhz DDR3 Ram. Very impressive stuff. On Wed, Jul 2, 2014 at 10:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Wed, Jul 2, 2014 at 11:43 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> 0.00000000549181 seconds per message is just insanely low number . This >> is not even in the realm of nanoseconds. Is this number real ? Because I >> am very skeptical that one can get this kind of performance from a dynamic >> language even with a JIT VM. >> > > Here's a measurement on my 2.2GHz Mac Book Pro Core i7: > > | r | {[r := 34 benchFib] timeToRun. r} #(140 18454929) > > benchFib is nfib that adds one for each call, so the answer is the number > of calls necessary to compute the answer. > > benchFib ^self < 2 ifTrue: [1] ifFalse: [(self-1) benchFib + (self-2) > benchFib + 1] > > So that's 18 million calls in 140 milliseconds, or about 132 calls per > microsecond. That's indeed in the realm of nanoseconds, 13.2 nsecs per > call. > > > >> >> On Wed, Jul 2, 2014 at 9:08 PM, Camille Teruel <camille.teruel(a)gmail.com> >> wrote: >> >>> >>> A spur image :) awesome !! >>> Thanks Esteban & Guille! >>> I'll start adapting the new class builder to Spur next wednesday when I >>> come back from holidays. >>> >>> On 2 juil. 2014, at 16:13, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>> > Hi, >>> > >>> > Iâve been working on prepare Pharo to run with the new Spur VMâ¦ and >>> finally this week Guille and I sit together and make a huge advance :) >>> > here a screenshot of pharo 4 running with spur: >>> > <Screen Shot 2014-07-02 at 15.58.17.png> >>> > for more information, same image before migration, with a regular >>> cogvm gives this numbers: '1297023432 bytecodes/sec; 161029354 sends/secâ, >>> so that means that the tiny benchmarks run at 166% the speed of the old vmâ¦ >>> > Of course this is just one benchmark, but Iâm very impressed :) >>> > >>> > Now, it is still not usable but Iâm confident I can put a jenkins job >>> to work very soon :) >>> > >>> > Esteban >>> > >>> > ps: before you start asking: Spur WILL NOT be available for Pharo3, it >>> will be part of Pharo4. >>> > >>> > >>> > >>> >>> >>> >> > > > -- > best, > Eliot >

July 2, 2014

Re: [Pharo-dev] Pharo running with spur (work in process)

by phil＠highoctane.be

Ah ah, insanely sweet! Le 2 juil. 2014 21:29, "Eliot Miranda" <eliot.miranda(a)gmail.com> a Ã©crit : > > > > On Wed, Jul 2, 2014 at 12:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> >> >> >> On Wed, Jul 2, 2014 at 11:43 AM, kilon alios <kilon.alios(a)gmail.com> >> wrote: >> >>> 0.00000000549181 seconds per message is just insanely low number . This >>> is not even in the realm of nanoseconds. Is this number real ? Because I >>> am very skeptical that one can get this kind of performance from a dynamic >>> language even with a JIT VM. >>> >> >> Here's a measurement on my 2.2GHz Mac Book Pro Core i7: >> >> | r | {[r := 34 benchFib] timeToRun. r} #(140 18454929) >> >> benchFib is nfib that adds one for each call, so the answer is the number >> of calls necessary to compute the answer. >> >> benchFib ^self < 2 ifTrue: [1] ifFalse: [(self-1) benchFib + (self-2) >> benchFib + 1] >> >> So that's 18 million calls in 140 milliseconds, or about 132 calls per >> microsecond. That's indeed in the realm of nanoseconds, 13.2 nsecs per >> call. >> > > Ugh, let me try again... > > that's 184549290 / 0.14 = 1.3182092142857141e9 calls per second, which is > 0.76 nsecs per call. > > > >> >> >> >>> >>> On Wed, Jul 2, 2014 at 9:08 PM, Camille Teruel <camille.teruel(a)gmail.com >>> > wrote: >>> >>>> >>>> A spur image :) awesome !! >>>> Thanks Esteban & Guille! >>>> I'll start adapting the new class builder to Spur next wednesday when I >>>> come back from holidays. >>>> >>>> On 2 juil. 2014, at 16:13, Esteban Lorenzano <estebanlm(a)gmail.com> >>>> wrote: >>>> >>>> > Hi, >>>> > >>>> > Iâve been working on prepare Pharo to run with the new Spur VMâ¦ and >>>> finally this week Guille and I sit together and make a huge advance :) >>>> > here a screenshot of pharo 4 running with spur: >>>> > <Screen Shot 2014-07-02 at 15.58.17.png> >>>> > for more information, same image before migration, with a regular >>>> cogvm gives this numbers: '1297023432 bytecodes/sec; 161029354 sends/secâ, >>>> so that means that the tiny benchmarks run at 166% the speed of the old vmâ¦ >>>> > Of course this is just one benchmark, but Iâm very impressed :) >>>> > >>>> > Now, it is still not usable but Iâm confident I can put a jenkins job >>>> to work very soon :) >>>> > >>>> > Esteban >>>> > >>>> > ps: before you start asking: Spur WILL NOT be available for Pharo3, >>>> it will be part of Pharo4. >>>> > >>>> > >>>> > >>>> >>>> >>>> >>> >> >> >> -- >> best, >> Eliot >> > > > > -- > best, > Eliot >

July 2, 2014

Re: [Pharo-dev] Pharo running with spur (work in process)

by Eliot Miranda

On Wed, Jul 2, 2014 at 12:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Wed, Jul 2, 2014 at 11:43 AM, kilon alios <kilon.alios(a)gmail.com> > wrote: > >> 0.00000000549181 seconds per message is just insanely low number . This >> is not even in the realm of nanoseconds. Is this number real ? Because I >> am very skeptical that one can get this kind of performance from a dynamic >> language even with a JIT VM. >> > > Here's a measurement on my 2.2GHz Mac Book Pro Core i7: > > | r | {[r := 34 benchFib] timeToRun. r} #(140 18454929) > > benchFib is nfib that adds one for each call, so the answer is the number > of calls necessary to compute the answer. > > benchFib ^self < 2 ifTrue: [1] ifFalse: [(self-1) benchFib + (self-2) > benchFib + 1] > > So that's 18 million calls in 140 milliseconds, or about 132 calls per > microsecond. That's indeed in the realm of nanoseconds, 13.2 nsecs per > call. > Ugh, let me try again... that's 184549290 / 0.14 = 1.3182092142857141e9 calls per second, which is 0.76 nsecs per call. > > > >> >> On Wed, Jul 2, 2014 at 9:08 PM, Camille Teruel <camille.teruel(a)gmail.com> >> wrote: >> >>> >>> A spur image :) awesome !! >>> Thanks Esteban & Guille! >>> I'll start adapting the new class builder to Spur next wednesday when I >>> come back from holidays. >>> >>> On 2 juil. 2014, at 16:13, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>> > Hi, >>> > >>> > Iâve been working on prepare Pharo to run with the new Spur VMâ¦ and >>> finally this week Guille and I sit together and make a huge advance :) >>> > here a screenshot of pharo 4 running with spur: >>> > <Screen Shot 2014-07-02 at 15.58.17.png> >>> > for more information, same image before migration, with a regular >>> cogvm gives this numbers: '1297023432 bytecodes/sec; 161029354 sends/secâ, >>> so that means that the tiny benchmarks run at 166% the speed of the old vmâ¦ >>> > Of course this is just one benchmark, but Iâm very impressed :) >>> > >>> > Now, it is still not usable but Iâm confident I can put a jenkins job >>> to work very soon :) >>> > >>> > Esteban >>> > >>> > ps: before you start asking: Spur WILL NOT be available for Pharo3, it >>> will be part of Pharo4. >>> > >>> > >>> > >>> >>> >>> >> > > > -- > best, > Eliot > -- best, Eliot

July 2, 2014

Re: [Pharo-dev] Pharo running with spur (work in process)

by Eliot Miranda

On Wed, Jul 2, 2014 at 11:43 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > 0.00000000549181 seconds per message is just insanely low number . This is > not even in the realm of nanoseconds. Is this number real ? Because I am > very skeptical that one can get this kind of performance from a dynamic > language even with a JIT VM. > Here's a measurement on my 2.2GHz Mac Book Pro Core i7: | r | {[r := 34 benchFib] timeToRun. r} #(140 18454929) benchFib is nfib that adds one for each call, so the answer is the number of calls necessary to compute the answer. benchFib ^self < 2 ifTrue: [1] ifFalse: [(self-1) benchFib + (self-2) benchFib + 1] So that's 18 million calls in 140 milliseconds, or about 132 calls per microsecond. That's indeed in the realm of nanoseconds, 13.2 nsecs per call. > > On Wed, Jul 2, 2014 at 9:08 PM, Camille Teruel <camille.teruel(a)gmail.com> > wrote: > >> >> A spur image :) awesome !! >> Thanks Esteban & Guille! >> I'll start adapting the new class builder to Spur next wednesday when I >> come back from holidays. >> >> On 2 juil. 2014, at 16:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> > Hi, >> > >> > Iâve been working on prepare Pharo to run with the new Spur VMâ¦ and >> finally this week Guille and I sit together and make a huge advance :) >> > here a screenshot of pharo 4 running with spur: >> > <Screen Shot 2014-07-02 at 15.58.17.png> >> > for more information, same image before migration, with a regular cogvm >> gives this numbers: '1297023432 bytecodes/sec; 161029354 sends/secâ, so >> that means that the tiny benchmarks run at 166% the speed of the old vmâ¦ >> > Of course this is just one benchmark, but Iâm very impressed :) >> > >> > Now, it is still not usable but Iâm confident I can put a jenkins job >> to work very soon :) >> > >> > Esteban >> > >> > ps: before you start asking: Spur WILL NOT be available for Pharo3, it >> will be part of Pharo4. >> > >> > >> > >> >> >> > -- best, Eliot

July 2, 2014

Re: [Pharo-dev] Pharo running with spur (work in process)

by Sebastian Sastre

On Jul 2, 2014, at 3:43 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > 0.00000000549181 seconds per message is just insanely low number . This is not even in the realm of nanoseconds. Is this number real ? Because I am very skeptical that one can get this kind of performance from a dynamic language even with a JIT VM. Nice! careful guys, as weâre start dealing with things in the Planck scale with all this power we can accidentally open a portal to another multiverse :D

July 2, 2014

Re: [Pharo-dev] Athens and StrikeFont ( again )

by Nicolai Hess

2014-07-02 10:00 GMT+02:00 Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no>: > On 01.07.2014 22:05, Nicolai Hess wrote: > > > 2014-07-01 3:16 GMT+02:00 Igor Stasenko <siguctua(a)gmail.com>: > >> >> >> >> On 30 June 2014 21:36, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> The real question was: >>> Why can't we draw a text with StrikeFont and with Athens. >>> >>> Igor, can't we use AthensCairoText (cairo toy text api) for >>> non-truetype fonts? >>> >>> >> Because strike fonts are stored in special format which you cannot render >> directly by cairo library. Because strike fonts are not scalable. Because >> it will be horribly slow. Choose one. >> > > > > I choose the first one, horrible slow or not scaleable is better than a > drawing error :) > > If someday all rendering is done through Athens, how do we solve this > problem with the StrikeFont? > > You would have to implement a special rendering path for StrikeFonts > utilizing essentially the same method used for rendering bitmaps. > In theory, if cairo bitmap perf is about the same as traditional bitmap > perf, that'd be about as slow as FT-rendering is in non-cairo images, if > there's no scaling involved. > Scaled, it would probably look horrible, take a screenshot of this mail, > zoom to 400% in Paint or something, that's what to expect. > (Though, one *could* do some tricks translating point size /scale factor > to another font with point size closer to the final result (if one exists) > and get slightly less horrible results) > another solution in: 13458 <https://pharo.fogbugz.com/default.asp?13458> Rendering text with Athens and StrikeFonts Here I use Athens/Cairos simple text api. Maybe not a good solution, but it is better than the drawing error, I think. > > Cheers, > Henry >

July 2, 2014