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

[Pharo-project] git interesting article
by StÃ©phane Ducasse Feb. 11, 2012

Feb. 11, 2012

http://nvie.com/posts/a-successful-git-branching-model/ tx dale for the pointer stef

2 1

[Pharo-project] Fwd: [Vm-dev] Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt
by StÃ©phane Ducasse Feb. 10, 2012

Feb. 10, 2012

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Subject: Re: [Vm-dev] Interesting article on PyPy (P{ython's tracing JIT) by Laurence Tratt > Date: February 9, 2012 6:05:48 PM GMT+01:00 > To: lenglish5(a)cox.net, Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > > On Thu, Feb 9, 2012 at 8:32 AM, Lawson English <lenglish5(a)cox.net> wrote: > > On 2/8/12 5:41 PM, Eliot Miranda wrote: >> >> >> >> >> this is well written, relatively short, and extremely informative. >> >> http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enou… >> >> thanks to Bob Westergaard for pointing it out to me. >> -- > > Eliot, do you have plans to recreate the functionality of RPython to auto-generate JITs for other languages? > > No. This article confirmed David Simmons' conclusions as to the potential performance of tracing JITs, i.e. that they produce excellent performance for micro-benchmarks but overall perform poorly. Here are some key quotes: > > "It's clear that, in general, an RPython VM won't reach the performance of something like HotSpot, which has several advantages: the overall better performance of method-based JITs; the fact that it's hand-coded for one specific class of languages; and the sheer amount of effort put into it. But I'd certainly expect RPython VMs to get to comfortably within an order of magnitude performance levels as HotSpot. Time will tell, and as people write RPython VMs for languages like Java, we'll have better points of comparison." > > "Tracing JITs are relatively new and have some limitations, at least based on what we currently know. Mozilla, for example, removed their tracing JIT a few months back, because while it's sometimes blazingly fast, it's sometimes rather slow. This is due to a tracing JIT optimising a single code-path at a time: if a guard fails, execution falls back to the (very slow) tracing interpreter for the remainder of that bytecode (which could be quite long), and then back to the language interpreter for subsequent bytecodes. Code which tends to take the same path time after time benefits hugely from tracing; code which tends to branch unpredictably can take considerable time to derive noticeable benefits from the JIT." > > My own preferred direction remains to add adaptive optimization to Cog, after improving the object representation. > > L. > > > > > -- > best, > Eliot >

1 0

Re: [Pharo-project] 1.4 - better from Jenkins
by Marcus Denker Feb. 10, 2012

Feb. 10, 2012

On Feb 10, 2012, at 9:36 PM, Schwab,Wilhelm K wrote: > Stef, > > I am trying to simplify it :) You use a Mac, right? I'm using Linux, and the vm differences might be at play?? > How can we know if we can not reproduce the problem? Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] 1.4 - better from Jenkins
by Marcus Denker Feb. 10, 2012

Feb. 10, 2012

On Feb 10, 2012, at 11:22 AM, Schwab,Wilhelm K wrote: > Dale, > > I'm not "complaining," I'm stating facts and asking for advice. Not only did I state that I produced a "big" debug log, I also POSTED a smaller one. If you mean something different by a "stack trace," can you provide some instructions for how to obtain it? > What we need is a description of how to re-produce the problem. Do not think that anyone can (or even wants to help) if you just say "I did something and than I got strange results". Make it reproducable, and then add a bug report. Marcus -- Marcus Denker -- http://marcusdenker.de

6 5

[Pharo-project] [update 1.4] #14327
by Marcus Denker Feb. 10, 2012

Feb. 10, 2012

14327 ----- Issue 5273: Dragging files on the window (e.g. .cs) not working http://code.google.com/p/pharo/issues/detail?id=5273 Issue 5271: Bug in checkbox http://code.google.com/p/pharo/issues/detail?id=5271 -- Marcus Denker -- http://marcusdenker.de

2 1

[Pharo-project] move to gemstone!
by Camillo Bruni Feb. 10, 2012

Feb. 10, 2012

again as squeaksource was down today I think everybody should move their projects to gemstone... as mariano pointed out in his blog this is fairly easy to do if you have a configuration: conf := #ConfigurationOfSoup. ss := 'Soup'. ss3 := 'soup'. gofer := Gofer new package: conf. gofer copy squeaksource: ss; load. project := (Smalltalk at: conf) project latestVersion. project packages do: [:spec| gofer package: spec name. ]. gofer copy squeaksource: ss; fetch. gofer copy url: 'http://ss3.gemstone.com/ss/', ss3; push. best cami

1 0

[Pharo-project] detecting if method has an prim error code
by Igor Stasenko Feb. 10, 2012

Feb. 10, 2012

Is there a simple way to detect that given method using: myMethod <primitive: #primFoo module: #moduleBar error: errorCode> but not: myMethod <primitive: #primFoo module: #moduleBar> ? should i use a method's pragmas to see if it has #primitive:module:error: pragma? And if this check is ok, do i remember correctly, that temp which is used for storing an error is first temp in context, i.e.: err := context tempAt: 1 ? (ok i checked, it is actually always last temp), no matter if i declare temps before pragma or not. i.e. the order is same for: myMethod | a b c | <primitive: #primFoo module: #moduleBar error: errorCode> and myMethod <primitive: #primFoo module: #moduleBar error: errorCode> | a b c | -- Best regards, Igor Stasenko.

1 0

[Pharo-project] please ignore - just a test
by Ben Coman Feb. 10, 2012

Feb. 10, 2012

I am testing a hypothesis about the format of my posts that got screwed up. Please excuse the noise. This is a test Over several lines With each new line Starting with a capital letter And no line ending with a colon. This is a test Over several lines : With each new line Starting with a capital letter : But two of the lines ending with a colon.

1 0

Feb. 10, 2012

Hi levente we are performing a study with veronica and we looked at Monticello-ul.331 in squeak trunk you mentioned that name hashWithInitialHash: 0. is faster than String stringHash: name initialHash: 0. and I was wondering if this is true and why? String hashWithInitialHash: initialHash ^ self class stringHash: self initialHash: initialHash hash | hash | hash := name hashWithInitialHash: 0. hash := superclassName hashWithInitialHash: hash. hash := self traitCompositionString hashWithInitialHash: hash. hash := self classTraitComposition asString hashWithInitialHash: hash. hash := (category ifNil: ['']) hashWithInitialHash: hash. hash := type hashWithInitialHash: hash. variables do: [ :v | hash := v name hashWithInitialHash: hash ]. ^hash => hash | hash | hash := String stringHash: name initialHash: 0. hash := String stringHash: superclassName initialHash: hash. hash := String stringHash: self traitCompositionString initialHash: hash. hash := String stringHash: self classTraitComposition asString initialHash: hash. hash := String stringHash: (category ifNil: ['']) initialHash: hash. hash := String stringHash: type initialHash: hash. variables do: [ :v | hash := String stringHash: v name initialHash: hash. ]. ^ hash Thanks in advance Stef and Veronica

1 0

[Pharo-project] Support for returning external structures in NativeBoost
by Javier PimÃ¡s Feb. 10, 2012

Feb. 10, 2012

I have this wrapper: chooseVisual: display screen: aScreenNumber attributes: attribList <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self call: #( NBXLibVisualInfo* glXChooseVisual ( NBXLibDisplay display , int aScreenNumber, int *attribList ) ) but when generating native code it ends in: ExternalStructureType>>coerceReturn: gen " ... should we support handling return of external structures? " self error: 'returning pointer to structure?' Changing "NBXLibVisualInfo*" to "NBXLibVisualInfo" didn't help. Is there any workaround?? -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

2 2