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

Re: [Pharo-project] Issue 3687 in pharo: Browse senders/implementors in Omnibrowser/OB pops up menu that doesn't respond to enter/CR

by pharo＠googlecode.com

Comment #3 on issue 3687 by stephane...(a)gmail.com: Browse senders/implementors in Omnibrowser/OB pops up menu that doesn't respond to enter/CR http://code.google.com/p/pharo/issues/detail?id=3687 Is your slide empty?

Feb. 10, 2011

Re: [Pharo-project] Issue 3689 in pharo: Transcript preference for #characterLimit

by pharo＠googlecode.com

Comment #3 on issue 3689 by bstj...(a)yahoo.com: Transcript preference for #characterLimit http://code.google.com/p/pharo/issues/detail?id=3689 Works fine! Thanks!

Feb. 10, 2011

Re: [Pharo-project] Issue 3659 in pharo: Task bar appearance does not make sense

by pharo＠googlecode.com

Updates: Status: Closed Comment #14 on issue 3659 by stephane...(a)gmail.com: Task bar appearance does not make sense http://code.google.com/p/pharo/issues/detail?id=3659 In 13046

Feb. 10, 2011

Re: [Pharo-project] A tinyBenchmark

by Levente Uzonyi

On Thu, 10 Feb 2011, Torsten Bergmann wrote: > see http://fbanados.wordpress.com/2011/02/10/a-tinybenchmark > > Maybe Eliot is able to say something here on the main > differences between Cog <-> VW VM. You made several mistakes: - You didn't post the source code for #tinyBenchmarks. Do all those Smalltalks implement it? Are the implementations equal? - You didn't specify the version numbers for the VMs used. Or if you built them yourself, then the sourcecode + compiler version + configuration parameters. Without these your measurements can't be reproduced. - There are two different Cog VMs. You didn't specify which one did you use with Pharo. - You used a CogVM (JIT) with Pharo but SqueakVM (interpreter) with Squeak 4.2. What's even worse is that you based your conclusion on this mistake. - Does #tinyBenchmarks alone give fair performance comparison? Hardly. Levente > > Thx > T. > -- > NEU: FreePhone - kostenlos mobil telefonieren und surfen! > Jetzt informieren: http://www.gmx.net/de/go/freephone > >

Feb. 10, 2011

Re: [Pharo-project] Issue 3661 in pharo: fixed the calculation of base in PNGReadWriter>>copyPixelsGray: (floor vs ceil)

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3661 by stephane...(a)gmail.com: fixed the calculation of base in PNGReadWriter>>copyPixelsGray: (floor vs ceil) http://code.google.com/p/pharo/issues/detail?id=3661 (No comment was entered for this change.)

Feb. 10, 2011

Re: [Pharo-project] Issue 3676 in pharo: Remove #example* class messages from HTTPClient

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3676 by stephane...(a)gmail.com: Remove #example* class messages from HTTPClient http://code.google.com/p/pharo/issues/detail?id=3676 in 13046

Feb. 10, 2011

Re: [Pharo-project] Issue 3691 in pharo: Cleaning by comparing SimpleMorphic and Morphic

by pharo＠googlecode.com

Comment #3 on issue 3691 by fernando...(a)gmail.com: Cleaning by comparing SimpleMorphic and Morphic http://code.google.com/p/pharo/issues/detail?id=3691 Took an initial look, fixed some comments. Did a refactoring in FormCanvas>>setPaintColor: (It seems i preserved the behavior, the UI was working fine after loading the cs) Will continue to give it an overall look. Attachments: CanvasCleaning.2.cs 25.8 KB

Feb. 10, 2011

Re: [Pharo-project] Issue 3609 in pharo: Integrate RPackage

by pharo＠googlecode.com

Comment #10 on issue 3609 by cy.delau...(a)gmail.com: Integrate RPackage http://code.google.com/p/pharo/issues/detail?id=3609 I start to have good result when running all test in a1.3 core image. Failing tests and errors are the same from a standard core image and from the one using RPackage, except: => PharoCorePackageDepenciesTests >> #testFile => PharoCorePackageDepenciesTests >> #testMonticello Both are not necessary due to a wrong behavior of RPackage, but also to some dependies found that were not expected (the expected depencies are harcoded). => ChangeHooksTest>>#testClassRecategorizedEvent2 This one is a bit hard to fix. Here is what you should evaluate to have RPackage integrated to your system: "load rpackage" Gofer new squeaksource: 'PharoTaskForces'; package: 'ConfigurationOfRPackage'; load. (Smalltalk globals at: #ConfigurationOfRPackage) loadDefault. "to be sure that the organizer is initialized before loading anything else:" "(Smalltalk globals at: #RPackageOrganizer) initializeDefault." (Smalltalk globals at: #RPackageOrganizer ) removeMockPackagesFromOldOrganizer. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'Monticello-cyrilledelaunay.518'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'MonticelloGUI-cyrilledelaunay.89'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'Tests-cyrilledelaunay.282'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'ScriptLoader13-cyrilledelaunay.41'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'Gofer-Core-cyrilledelaunay.131'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'Gofer-Tests-cyrilledelaunay.130'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'SUnit-cyrilledelaunay.40124'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'SUnitGUI-cyrilledelaunay.72'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'System-Settings-cyrilledelaunay.216'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'FixUnderscores-cyrilledelaunay.21'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'HelpSystem-Core-cyrilledelaunay.77'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'Metacello-Help-cyrilledelaunay.12'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'Metacello-ToolBox-cyrilledelaunay.88'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'SUnitGUI-cyrilledelaunay.72'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'System-Installers-cyrilledelaunay.12'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'System-Settings-cyrilledelaunay.216'; merge. Gofer new squeaksource: 'DelaunayTmpStuffs'; version: 'System-Support-cyrilledelaunay.441'; merge.

Feb. 10, 2011

Re: [Pharo-project] drawString: aString from: firstIndex to: lastIndex at: aPoint font: fontOrNil color: c

by Henrik Johansen

On Feb 10, 2011, at 1:24 55PM, Schwab,Wilhelm K wrote: > This reminds me of something: I have long been concerned about possible speed penalties that might result from Morphic's accepting colors and other drawing tools as arguments rather than having a canvas hold them as state that can be set once and used many times. > > It's probably nothing, but it always struck me as very different from the way Dolphin does things. Of course, Object Arts' focus on Windows could have simply have led them to follow along with the platform's design; there is nothing to say they would have created a context if none had existed. > > Just something to think about. > > Bill The rationale is explained in http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/morphic.final… in the section "Adding appearance" on page 6 - 7. Personally, this is one of the things I don't dislike about Morphic compared to other canvas-based systems :) Cheers, Henry

Feb. 10, 2011

Re: [Pharo-project] drawString: aString from: firstIndex to: lastIndex at: aPoint font: fontOrNil color: c

by Schwab,Wilhelm K

This reminds me of something: I have long been concerned about possible speed penalties that might result from Morphic's accepting colors and other drawing tools as arguments rather than having a canvas hold them as state that can be set once and used many times. It's probably nothing, but it always struck me as very different from the way Dolphin does things. Of course, Object Arts' focus on Windows could have simply have led them to follow along with the platform's design; there is nothing to say they would have created a context if none had existed. Just something to think about. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, February 09, 2011 8:44 AM To: Pharo Development Subject: [Pharo-project] drawString: aString from: firstIndex to: lastIndex at: aPoint font: fontOrNil color: c [snip] I was wondering why the combinationRule is not needed. Stef

Feb. 10, 2011