July 2014 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] [pharo-project/pharo-core] 315fe0: 30851

by stepharo

I just saw that and yes thank a lot for this great fix. Stef On 2/7/14 12:31, Esteban Lorenzano wrote: > On 02 Jul 2014, at 12:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 02 Jul 2014, at 11:53, GitHub <noreply(a)github.com> wrote: >> >>> 13422 Image crashes because an open Nautilus browser hangs onto many objects while code is being loaded >>> https://pharo.fogbugz.com/f/cases/13422 >> Excellent, professional work from everybody involved ! > yes, excellent team work :) > > >

July 2, 2014

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

by kilon alios

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

July 2, 2014

AlignmentMorph class>>newRow and pinning Menus

by Nicolai Hess

As you might know, pinning a Menu (like the WorldMenu) slightly changes the size of the menu. This was somehow caused by initialising AlignmentMorphs with an extent 1@1 in #newRow. I removed that line, th fix is in Pharo 40 059. (issue 13433 <https://pharo.fogbugz.com/default.asp?13433>). As the morph layout computation is pretty complex this may cause some unforeseen issues. just to be warned :) nicolai

July 2, 2014

Re: [Pharo-dev] Seeking help

by stepharo

Hello Janko > Several days ago I was immersed in Pharo3.0 as this time things worked > well. So, did include many packaeges in image up to Eye-watcer, than > started to look what a repository is all about - so, was given offer > to have some subdomain with my name and probably uploaded everything. > Next time when I started my image from disk there was small progress > bar - clearly something was updating itself or something and > Eye-Watcher was in debuger window not understanding some message. > Clearly had installed something unfinished or wrongly initialized. So, > i deleted entire Pharo directory, and downloaded pharo, and same thing > happend. This is strange. :) Do you have startup preferences? because normally this should not happen magically. Which precise image are you using? What are the packages that you loaded? Which OS? Stef > Pretty nasty Huh, I am sorry if i ruined something on repository I am > afraid of. > > Could you please tell me what is going on? > > Or in case i ruined repository how long does it take to fix it, please > help! > > Thank You!

July 2, 2014

Re: [Pharo-dev] Project XMLParser green

by stepharo

XMLParser has some platform definition and versionner does not support them. On 1/7/14 12:02, Tudor Girba wrote: > Thanks. > > Just please detail what happened and why Versionner should not be used. > > Only like that we can learn and coordinate. > > Doru > > > On Tue, Jul 1, 2014 at 11:39 AM, Stephan Eggermont <stephan(a)stack.nl > <mailto:stephan@stack.nl>> wrote: > > Bad configuration, fixed. Do not use current version of versioner > for this configuration > > Stephan > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

July 2, 2014