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

[Pharo-project] Issue 3728 in pharo: Changed MenuMorph references to go through UIManager default menuClass

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3728 by fernando...(a)gmail.com: Changed MenuMorph references to go through UIManager default menuClass http://code.google.com/p/pharo/issues/detail?id=3728 the attached changeset replaces all the refs to the class MenuMorph by the usage of UIManager default menuClass. 9 uses remain, mostly due to #isKindOf: senders. Attachments: menuMorphReferences.1.cs 51.7 KB

Feb. 17, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Eliot Miranda

On Thu, Feb 17, 2011 at 1:59 AM, Douglas Brebner < squeaklists(a)fang.demon.co.uk> wrote: > On 16/02/2011 20:13, Eliot Miranda wrote: > > > > On Wed, Feb 16, 2011 at 12:04 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote: >> >> > >> > >> > On Tue, Feb 15, 2011 at 11:50 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> > Eliot a final question. >> > So how will you handle OPAL compiler change in Cog? >> > Do you require that marcus and jorge have to deal with decompiler of >> caseOf: in addition to all the rest? >> > Is it a strong requirement? Because then this is clear that Opal will be >> delayed. But may be it is not that important after all. >> > Just curious. >> > >> > OPAL is a Smalltalk compiler. I can therefore assume that it will >> compile Smalltalk. caseOf: is valid Smalltalk and so will be compiled by >> OPAL. Whether Marcus chooses to optimise caseOf: or not is up to him. >> >> This is exactly my point. >> > > No it's not. Your point was to raise two straw-=man arguments: > 1. that Marcus and Jorge would have to deal with the decompiler (not an > issue; the decompiler already deals with optimized caseOf: and the new > decompiler will deal with optimized caseOf: just as it'll deal with > optimized ifTrue: ifNotNil: et al). > 2. that supporting caseOf: in optimized form will delay Opal (not an issue; > Opal will optimize certain constructs, this is just one more and won't add a > lot of time). > > So your point appears to be to try and justify removing caseOf: on > spurious grounds by spreading FUD. > > This is so unlike you I'm having a hard time really understanding what's > going on. > > > > Correct me if I'm wrong but isn't Stephane essentially saying that Opal > will just demote #caseOf: from inlined special form to normal method? > (Possibly so it can be unloadable instead of being pinned in the system by > the compiler support). > It seems to me that this shouldn't affect caseOf: use in Cog since the > inlining there is handled by the SLang translator. > It certainly won't affect the production Cog since indeed that goes through Slang to emerge as C. However it will affect developing in Cog, which is done by rnning the simulator, and as I've shown case statements are used in some performance-critical parts of the system (byte access). > > Or have I totally misunderstood? > > Of course, where caseOf: is kept afterwards another question :) > I don't see why one would want to get rid of this useful functionality. There is nothing inherrently wrong with a flexible case statement. Its certainly far more preferrable than a performance-equivalent set of nested ifTrue:ifFalse:'s. Further, the dictionary/perform or multiple classes approaches only make sense at a certain scale (that's especially true of the dictionary/perform alternative since maintaining the dictionary is painful). So for me it makes absolutely no sense for a Squeak-derived Smalltalk dialect to eliminate a construct that is really useful in certain circumstances. That kind of thinking eliminates things like contexts and that's a slippery slope to eliminating the essential flexibility of the system. 2Â¢ Eliot

Feb. 17, 2011

Re: [Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions

by Eliot Miranda

Hi John, good questions. On Thu, Feb 17, 2011 at 6:21 AM, John B Thiel <jbthiel(a)gmail.com> wrote: > Cog VM -- Thanks and Performance / Optimization Questions > > > To Everyone, thanks for your great work on Pharo and Squeak, and to > Eliot Miranda, Ian Piumarta, and all VM/JIT gurus, especially thanks > for the Squeak VM Cog and its precursors, which I was keenly > anticipating for a decade or so, and is really going into stride with > the latest builds. > > I like to code with awareness of performance issues. Can you tell or > point me to some performance and efficiency tips for Cog and the > Squeak compiler -- detail on which methods are inlined, best among > alternatives, etc. For example, I understand #to:do: is inlined -- > what about #to:do:by: and #timesRepeat and #repeat ? Basically, I > would like to read a full overview of which core methods are specially > optimized (or planned). > The bytecode compiler inlines a set of selectors if the arguments are suitable (typically literal blocks). The standard compiler's list is MessageNode classPool at: #MacroSelectors, e.g. #ifTrue: #ifFalse: #ifTrue:ifFalse: #ifFalse:ifTrue: #and: #or: #whileFalse: #whileTrue: #whileFalse #whileTrue #to:do: #to:by:do: #caseOf: #caseOf:otherwise: #ifNil: #ifNotNil: #ifNil:ifNotNil: #ifNotNil:ifNil: Note that Nicolas Cellier has just added support for inlining repeat and timesRepeat in Squeak trunk. > I know about the list of NoLookup primitives, as per Object > class>>howToModifyPrimitives, supposing that is still valid? > Not for Cog. While #== and #class are inlined all other primitives are looked up. > What do you think is a reasonable speed factor for number-crunching > Squeak code vs C ? I am seeing about 20x slower in the semi-large > scale, which surprised me a bit because I got about 10x on smaller > tests, and a simple fib: with beautiful Cog is now about 3x (wow!). > That range, 3x tiny tight loop, to 20x for general multi-class > computation, seems a bit wide -- is it about expected? > Are you saying that you have a macro benchmark that is 20 times faster in C than in Cog? Cog, while faster than the interpreter, is still a non-inlining, non-globally-optimizing system and so performance is certainly to be expected to be worse than C. But 20x sounds a little high so your benchmark could be useful. If you can post this please do. The current state of Cog is that the new code generator gives a significant speed-up but that the object model and garbage collector remain substantially the same as the Squeak interpreter. The GC is slow and badly needs replacing. The object model is both slow, especially for class access, which slows down all sends a little, and over-complex, which means that several performance-critical primitives have yet to be implemented in machine-code, especially at:put:, basicNew, basicNew:, and closure creation, all of which currently require expensive calls into C instead of using inline machine code. I would expect that improving all these could add at least another factor of 33%. I'm trying to find funding to work on these two issues ASAP. > My profiling does not reveal any hotspots, as such -- it's basically > 2, 3, 5% scattered around, so I envision this is just the general > vm/jit overhead as you scale up -- referencing distant objects, slots, > dispatch lookups, more cache misses, etc. But maybe I am generally > using some backwater loop/control methods, techniques, etc. that could > be tuned up. e.g. I seem to recall a trace at some point showing > #timesRepeat taking 10% of the time (?!). Also, I recall reading > about an anomaly with BlockClosures -- something like being rebuilt > every time thru the loop - has that been fixed? Any other gotchas to > watch for currently? > BlockClosures for non-inlined blocks are still created when mentioned. So if you do have a loop which contains a block creation, consider pulling the block out into a temp variable. > (Also, any notoriously slow subsystems? For example, Transcript > writing is glacial.) > Someone should replace the Transcript's reliance on (I think) some kind of FormMorph which moved huge numbers of bits on each write. But this is not a VM issue. It's a Smalltalk issue. Whoever did this would instantly become a hero. > The Squeak bytecode compiler looks fairly straightforward and > non-optimizing - just statement by statement translation. So it > misses e.g. chances to store and reuse, instead of pop, etc. I see > lots of redundant sequences emitted. Are those kind of things now > optimized out by Cog, or would tighter bytecode be another potential > optimization path. (Is that what the Opal project is targetting?) > There is some limited constant folding in the StackToRegisterMapingCogit. For example the pushTrue jumpFalse sequences generated in inlined and: and or: statements is eliminated. Also constant SmallInteger arithmetic is folded iff the receiver is a literal. The JIT doesn't have any type information so it can't fold var + 1 + 2, but it can and does fold 1 + 2 + var into 3 + var. Marcus Denker and I are working as I write on the infrastructure for an adaptive-optimizer/speculative-inliner that will initially operate at the bytecode level, deriving type information from the JIT's inline caches and using this to direct bytecode-to-bytecode optimization that will inline blocks, inline methods, etc. We hope eventually to target floating-point and other performance-critical code. Marcus posted a presentation I did a while back <Smalltalk Books Video Tutorials Smalltalk in Latam About Us! Contact Us Actually, I'm trying to make Ruby natural, not simple. -- Yukihiro "Matz" Matsumoto Home Talks & Presentations Eliot Miranda - Bytecode-to-bytecode adaptive optimization for Smalltalk Eliot Miranda - Bytecode-to-bytecode adaptive optimization for Smalltalk Last Updated (Sunday, 14 February 2010 20:21) | Written by Administrator | Monday, 18 August 2008 19:28 Multimedia Gallery - Talks & Presentations More ... Comments from the google video: This talk summarises two decades of work on Smalltalk and Self compilation and virtual machine technology and describes a novel attempt at an adaptive optimizer for Smalltalk that is written in Smalltalk and to a meaningful extent, portable across implementations. Smalltalk-80 and Self are fully object-oriented implicitly typed dynamic programming languages and interactive programming environments hosted above virtual machines that appear to execute stack-oriented bytecode for a pure stack machine. These systems' code and execution state are all represented by objects programmed in Smalltalk, such that the compiler, debugger, exception system and more are all implemented entirely in Smalltalk and available to the programmer for immediate incremental and interactive modification LikeDislike Community Disqus Add New Comment Optional: Login below. Post as â¦ Showing 0 comments Sort by Subscribe by email Subscribe by RSS blog comments powered by DISQUS back to top < Prev Next > Main Menu Home ClubSmalltalk Merchandise About Us! Contact Us Articles Frontpage news Interviews Community ClubSmalltalk | Mailing List [In Spanish] ClubSmalltalk | LinkedIn Group ClubSmalltalk | Facebook ClubSmalltalk | Community Blogs Smalltalkers Blogs & Personal pages Smalltalkers - Social Network Environments Commercial Smalltalk Environments Free Smalltalk Environments Abbandon Smalltalk Environments Frameworks, Platforms & Tools FAQ Smalltalk Frequently Asked Questions GemStone Frequently Asked Questions ENVY/Manager Frequently Asked Questions Resources Smalltalk Jobs! Smalltalk Web Links Smalltalk News Feeds Smalltalk Books Smalltalk Podcasts Multimedia Gallery Back to the future - Photo Gallery Smalltalk History Channel Talks & Presentations Smalltalk Documentaries Login If you don't want to register in this site, you can use your Gmail or OpenId authentication. Username Password Remember Me Forgot your password? Forgot your username? Create an account Login with an OpenID What is OpenId? Smalltalk on Twitter J_WICKS_CTE (J.Wicks) : I hate 2 word sentences #smalltalk 11th_echo (Yvonne) : Da fand er unseren Smalltalk wohl so einlullend, dass er erstmal seine SchlÃ¼ssel liegen lieÃ :DDDDDDDDDDDD hÃ¶hÃ¶ Dennis_Klinger (Dennis Klinger) : benachrichtigung bei antwort: hi leute ich hab mal ne frage. wie kann man sich benachrichtigen lassen wenn in ... http://bit.ly/gTytl0 onizee (Oneal Madumo) : Those who understnd #smalltalk ,guy walks in on me in th gym showers,and he says,"eish o tshwara shawara",how do i respond to this? JusCardo (Ricardo Cherry) : #SMALLtalk RT @_SweetTeee @JusCardo lol I hate you Paypal Donation Please, make a Paypal donation at least of 1 dollar! Thanks! Copyright Â© 2011 ClubSmalltalk. All Rights Reserved. Contact Us! Please, if you like the site visit our sponsors. Thanks.> that covers the essential ideas. This project could completely close the gap to C if augmented by a good quality code generator. At least, that's a goal. > -- jbthiel > >

Feb. 17, 2011

[Pharo-project] [COTDC] 14 - MCSnapshotReader

by laurent laffont

Today: MCSnapshotReader Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

Feb. 17, 2011

Re: [Pharo-project] Issue 3717 in pharo: Missing float array methods

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.2 -Milestone-1.3 Milestone-1.2-DevImage Comment #3 on issue 3717 by stephane...(a)gmail.com: Missing float array methods http://code.google.com/p/pharo/issues/detail?id=3717 For pharo-dev configuration maintainer: we should include the collectionArithmetic package to pharo-dev

Feb. 17, 2011

Re: [Pharo-project] Issue 3727 in pharo: Fix Inspector Menu

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #1 on issue 3727 by stephane...(a)gmail.com: Fix Inspector Menu http://code.google.com/p/pharo/issues/detail?id=3727 tx

Feb. 17, 2011

Re: [Pharo-project] Issue 3723 in pharo: The Finder tool does not alphabetize methods.

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #2 on issue 3723 by stephane...(a)gmail.com: The Finder tool does not alphabetize methods. http://code.google.com/p/pharo/issues/detail?id=3723 (No comment was entered for this change.)

Feb. 17, 2011

Re: [Pharo-project] Issue 3715 in pharo: Workspace shouting after switching between shout/unshout

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #2 on issue 3715 by stephane...(a)gmail.com: Workspace shouting after switching between shout/unshout http://code.google.com/p/pharo/issues/detail?id=3715 (No comment was entered for this change.)

Feb. 17, 2011

Re: [Pharo-project] [BUG] 1.2 UTF8TextConverter: Invalid utf8 input detected

by StÃ©phane Ducasse

**tx** > > Can you open a ticket? > > Already done: http://code.google.com/p/pharo/issues/detail?id=3721 > > Janko Igor could you have a look? Stef

Feb. 17, 2011

Re: [Pharo-project] [COTDC] 13 - NullEncoder

by StÃ©phane Ducasse

On Feb 16, 2011, at 11:27 PM, Igor Stasenko wrote: > On 16 February 2011 21:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Igor encoder was used for postcript encoding too. >> So this is not totally bad. >> > > But if it needed only by postscript canvas, what it doing in base class? indeed I missed that :) Stef

Feb. 17, 2011