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

[Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3754 by patchi...(a)gmail.com: Omnibrowser's an extra horizontal scrollbar http://code.google.com/p/pharo/issues/detail?id=3754 Pharo image: Pharo Pharo core version: 12337 Virtual machine used: Cog 2361 Class browser used (if applicable): Omnibrowser Steps to reproduce: 1. Open OB 2. You should see an extra horizontal scrollbar between the code editor and the category/class/protocol/messages navigation lists G code doesn't allow me to attach an image since quota was exceeded. Kind regards, Francisco

Feb. 25, 2011

Re: [Pharo-project] Hudson build became unstable: Pharo Core 1.2 #205

by Serge Stinckwich

On Fri, Feb 25, 2011 at 3:12 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 24, 2011, at 9:04 PM, hudson(a)pharo-ic.lille.inria.fr wrote: > >> See <https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/205/> >> >> > > Why exactly was I adding the Socket tests to 1.2 Core? > > I will remove them again... 1.2 is *frozen*. We do not add tests. Frozen in term of new functionality you are right, but not in term of bugs correction. If you fix some bugs, you also want to provide the tests ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Feb. 25, 2011

Re: [Pharo-project] Issue 3753 in pharo: SimpleMorphic Layout Code missing

by pharo＠googlecode.com

Comment #2 on issue 3753 by Ken.Dic...(a)whidbey.com: SimpleMorphic Layout Code missing http://code.google.com/p/pharo/issues/detail?id=3753 I wrote the Solitaire code originally to understand layout in Squeak. When I started looking at SimpleMorphic, but could did not find what I needed, so I ported the code to Cuis and then did the obvious backport. What would be the suggested strategy to get save/restore working? One natural thing would be to use Cuis' FileDialog, but this seems un-Pharo. Suggestions?

Feb. 25, 2011

Re: [Pharo-project] Issue 3753 in pharo: SimpleMorphic Layout Code missing

by pharo＠googlecode.com

Comment #1 on issue 3753 by Ken.Dic...(a)whidbey.com: SimpleMorphic Layout Code missing http://code.google.com/p/pharo/issues/detail?id=3753 Fix submitted to Pharo inbox as SimpleMorphic-KenDickey.11.mcz After loading the "fix" (the 2 SM layout classes) start SimpleMorphic [Navigate to SimpleMorphic-Kernel>>SMxReadMe doIt on 'SimpleMorphicUIManager start' The open a new morph from alphabetic list [Klondike or FreeCell] and play a game. Note that file save/restore is broken [not yet ported/integrated.

Feb. 25, 2011

[Pharo-project] Issue 3753 in pharo: SimpleMorphic Layout Code missing

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3753 by Ken.Dic...(a)whidbey.com: SimpleMorphic Layout Code missing http://code.google.com/p/pharo/issues/detail?id=3753 Cuis code for layouts is missing & I am unable to port a solitaire card game without them. Pharo image: Pharo-core 2.1 rc2 Pharo core version: 12366 Virtual machine used: VM in Pharo-1.1-OneClick.app Steps to reproduce: 1. Open a file browser and file in SimpleMorphicSolitaire.1.cs Attachments: SimpleMorphSolitaire.1.cs 276 KB

Feb. 25, 2011

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

by Eliot Miranda

On Thu, Feb 24, 2011 at 2:13 PM, John B Thiel <jbthiel(a)gmail.com> wrote: > Thanks Eliot, Stef and All for good answers on the Cog VM inlining and > implementation details. Â That is also exciting news about Eliot and > MarkusD's work on an adaptive optimizer. By "completely close the gap > to C" Â how close do you mean? The StrongTalk work posits a theoretical > best of about 2x, so I suppose you mean in that general 2x-5x > neighborhood vs machine code... ? > > The 20x slower macro algorithm I mentioned is too large to post. > Below is a simple micro-loop I made up to explore some aspects of > closures, loops and relative VM timings. Â The C-equivalent machine > code takes 400msec on my test machine. Â In Squeak/Pharo, I see a huge > range of speed factors with this, from 7x to 220x (!!) slower than > machine code, on current and near-history VMs (Cog and standard > Squeak). > > Consider: > > "A = to:by:do: Â loop" > benchLooperA > |sum| > Â Â Â Â sum:=1e8. > Â Â Â Â sum to: 1 by: -1 do: [:x | > Â Â Â Â Â Â Â Â sum := (sum bitShift: -1) + x ] . > Â Â Â Â ^sum > > "B = timesRepeat loop" > benchLooperB > |sum count| > Â Â Â Â count := sum:=1e8. > Â Â Â Â sum timesRepeat: Â [ > Â Â Â Â Â Â Â Â sum := (sum bitShift: -1) + count. > Â Â Â Â Â Â Â Â count := count - 1 ] . > Â Â Â Â ^sum > > > A and B compute the same except one using #to:by:do:, Â the other > #timesRepeat. Â The near-machine code for this computation runs about > 400msec Â (0.4 sec) on my test system. (x86 Windows 7, N450 Atom cpu, > 1.66GHz) > > On the following 3 test VM/Images, Â Â : > > 1. Â Squeak 4.1 stock (vm = Squeak 4.0.2, 2010apr3) > 2. Â Pharo 1.1.1 stock (vm = Cog 2010sep21) > 3. Â Pharo 1.2rc2 + Cog2011feb6 > > I get the following times for > Â A Â Time millisecondsToRun: [ Sandbox benchLooperA ] > Â B Â Time millisecondsToRun: [ Sandbox benchLooperB ] > > (A, B) execution times rounded to seconds > > 1. Â (24, 88) > 2. Â (34, 11) > 3. Â (3, 8) > > > Here we see a 3x-4x difference A to B, Â with an anomoly that Pharo > 1.1.1 is actually much *slower* on #to:by:do: Â (is it the closure bug > (?), see below). Â (Also we see 8x-11x speedup with the latest > Cog-2011feb6, great!) > > Now here is something odd -- if I invoke the loops via workspace DoIt, > the timing changes in Pharo 1.1.1, Â like this: > > Time millisecondsToRun: [ > |sum| > Â Â Â Â sum:=1e8. > Â Â Â Â sum to: 1 by: -1 do: [:x | > Â Â Â Â Â Â Â Â sum := (sum bitShift: -1) + x ] . > Â Â Â Â sum Â Â ] > > (highlight and DoIt) > > (A, B) invoked from workspace, time in seconds > > 1. Â (24, 88) > 2. Â (5, 11) > 3. Â (3, 8) > > > The Pharo 1.1.1 timing anomaly for case 2A disappeared - it's now 5 > seconds instead of 34. > > So, 4 questions: > > * What causes the Pharo 1.1.1. anomaly timing difference for #to:by:do > invoked via workspace DoIt vs in the #benchLooper method Â (5 sec vs 34 > sec) Â ? Cog has a policy in the VM to avoid compilation for rarely used methods. It will not compile a method to machine code unless a) it is found in the first level method lookup cache b) it is evaluated via withArgs:executeMethod: (which is how Doits are now evaluated) a) prevents Cog wasting time compiling large methods that are only run once, e.g. class initializers, where compiling the method is likely to take much longer than simply interpreting it. This si a simple heuristic but seems to work well. To avoid its effects when benchmarking simply arrange to run all code at least twice, ignoring the first run. b) means that code in a workspace, which can only ever be run once, runs at Cog speed instead of always being interpreted. > * Why is the #timesRepeat loop 3x-4x slower than #to:by:do ? Â Is that > simply the difference between inlined and non-inlined methods, or > other factors? Yes, it is due to the benefits of inlining blocks. > * Even the best Cog time here is 7x slower vs machine-code (and 20x > slower for the timesRepeat case), whereas latest Cog fib: runs at 3x. > What factors make this micro-bench loop not as optimizable as fib: for > Cog? It is not that it is not as optimizable, it is that Cog does not (currently) do aggressive optimization. In particular the temporary variables remain temporary variables on the stack and require reads and writes to access, whereas the C compiler is very probably putting these variables in registers. The plan is for Cog to do register allocation as part of Sista, i.e. when presented with optimized methods that contain hints that it should do register allocation. > > * Why is the stock Squeak 4.1 VM Â **220x slower** than machine code > for case B = timesRepeat loop, Â (88 sec vs 0.4 sec) ? Because interpreters are slow. > > > Thanks to everyone for insights and comments. > > -- jbthiel > >

Feb. 25, 2011

[Pharo-project] Which calendar does Pharo officially use?

by DougEdmunds

Try this code in a Workspace: |aDate bDate| Transcript open. aDate := Date fromString: '02.25.2011'. Transcript cr; show: aDate; cr. bDate := aDate subtractDays: 734503. Transcript show: bDate; cr; show: 'Year zero! Which calendar does Pharo officially use?'. >From http://en.wikipedia.org/wiki/0_(year): "Year zero" does not exist in the widely used Gregorian calendar or in its predecessor, the Julian calendar. Under those systems, the year 1 BC is followed by AD 1. However, there is a year zero in astronomical year numbering (where it coincides with the Julian year 1 BC) and in ISO 8601:2004 (where it coincides with the Gregorian year 1 BC) as well as in all Buddhist and Hindu calendars. -- View this message in context: http://forum.world.st/Which-calendar-does-Pharo-officially-use-tp3323638p33… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 24, 2011

Re: [Pharo-project] Pharo Sources Google Hit Ratio

by Camillo Bruni

we are close... - full smalltalk sources formatter for seaside - http://rubydoc.info/docs/yard/0.6.4/frames like interface todo: - fix some formatting issues for the st sources - get the urls fully working - adapt the javascript queries so I guess tomorrow or on saturday we will have a presentable version ready ;) m(^_-)m camillo On 2011-02-22, at 23:59, StÃ©phane Ducasse wrote: > what is squeaksource3? > when did it start? > Stef > >>>>> I do not know the exact circumstances of squeaksource's amazing low >>>>> google index, but I think we can change this. >>>> >>>> Set up some Seaside servers for Google to crawl? >>> >>> New SqueakSource currently in development by Iliad guys will have nice >>> REST-full Urls for the Smalltalk code. Google searchable therefore! >> >> >> so will squeaksource3 >> >> so long, >> -tobias > >

Feb. 24, 2011

Re: [Pharo-project] Is repository down for Magma?

by Miguel CobÃ¡

El jue, 24-02-2011 a las 15:40 -0600, Chris Muller escribiÃ³: > Hi, please copy me or the Magma list if you want me to see things > soonish. I saw this by luck. Yes, I forgot to CC. Sorry. > > > Unfortunately for all us, Chris deleted without notice, the versions > > Incidentally, notice was posted on the Magma mailing list: > > http://lists.squeakfoundation.org/pipermail/magma/2011-February/001728.html Yes, I saw that but the announce was after the deletion. Thats is why I said without notice. > > You can find the new actual load-scripts clicking the link provided in > that message. > > Also, nothing has been deleted from MagmaTester yet, so all of the old > packages are still there. However, I want to clean that up pretty > soon too.. The configuration relied on the versions on Magma, given that that is the official repository for released configuration. > > > from Magma repository that were used by the Metacello configuration to > > install Magma. So Magma isn't installable with Metacello anymore. > > > > Last weekend I started a ground up rewrite for ConfigurationOfMagma with > > support only for 1.2 (easier than fix the versions 1.1r43 1.1r44 that > > Yes, don't worry about those old Magma versions. I won't be > supporting them anymore either. Ok, good to now! :) > > > could be installed with the configuration) but after creating > > ConfigurationOfMaBase, ConfigurationOfMaClientServer and the new > > ConfigurationOfMagma (everything loaded correctly) I got stuck by the > > fact that the new Magma 1.2 is Squeak specific at the moment (it uses > > WeakOrderedCollection that Chris pushed to Squeak trunk in december 2010 > > and that is not in Pharo 1.1, nor in Pharo 1.2). > > Incidentally, > > http://lists.squeakfoundation.org/pipermail/magma/2010-November/001612.html > > To incorporate this into Pharo, see the changes in Squeak between: > > Collections-ul.403 and Collections-cmm.404. > > The changes are very simple. Basically, we simply allow the > OrderedCollection's internal 'array' to be specified by its > #arrayType, instead of being hard-coded to an Array. > > This allows WeakOrderedCollection to exist by only one single method, > an override of #arrayType on the class-side to specify WeakArray. Yes, I do now, I found that the changes are in fact small but that was too late in sunday and I had no more energy after creating the other configurations and testing that loaded correctly. > > I do hope Pharo will incorporate these changes and gain the benefit of > a weak OrderedCollection, not to mention, Magma...! C'mon Pharo, the > total gain in code-size is just one Class with a single one-line > method, plus one extra one-line method on OC. Yes, nobody has said that they aren't going to be merged, it is just that for Pharo 1.2 is frozen right now. So no new code can be added, it will be added to 1.3 that recently opened to development. That is the reason that I said that a little package with the changes will be uploaded to some repository and used as a dependency for Magma on Pharo1.2. For Pharo1.3 it won't be necessary. > > > So, I could to publish > > the new ConfigurationOfMagma to the metacello repository and you'll can > > install Magma but it won't run anymore. > > True, WeakOrderedCollection is crucial for the new proxy bulk-become > performance improvement. > > > (I have had time to check the > > WeakOrderedCollection issue only, I don't know if after fixing that > > other issues will remain because I haven't gone that far). > > Me either, we have to get this addressed first. Would someone in > Pharo help me lobby for this? > > > The way I am going to fix this, at least for Pharo 1.1.1 and Pharo 1.2, > > is to put the changes that Magma needs in a separate package somewhere > > (maybe PharoInbox or PharoTaskForces) and use it as a dependency in > > ConfigurationOfMagma. This way it will work correctly. But I will do it > > until tomorrow night. > > Ok. I hope if we can get past WeakOrderedCollection there won't be > any more special changes needed, but we'll have to see. > > Thanks Miguel! Nothing to thank, I really want Magma on Pharo healthy, just that those months I have had little time to maintain the configuration and the weekend that I dedicated to it, it was too late when I discovered the WeakOrderedCollection issue (especially because I had also to prepare the fix to Pharo and report it. So I choose to sleep because next day is workday :) I hope this weekend I will finally finish the work and report the enhancement to Pharo to be applied to Pharo1.3. Cheers > > - Chris > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Feb. 24, 2011

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

by John B Thiel

Thanks Eliot, Stef and All for good answers on the Cog VM inlining and implementation details. That is also exciting news about Eliot and MarkusD's work on an adaptive optimizer. By "completely close the gap to C" how close do you mean? The StrongTalk work posits a theoretical best of about 2x, so I suppose you mean in that general 2x-5x neighborhood vs machine code... ? The 20x slower macro algorithm I mentioned is too large to post. Below is a simple micro-loop I made up to explore some aspects of closures, loops and relative VM timings. The C-equivalent machine code takes 400msec on my test machine. In Squeak/Pharo, I see a huge range of speed factors with this, from 7x to 220x (!!) slower than machine code, on current and near-history VMs (Cog and standard Squeak). Consider: "A = to:by:do: loop" benchLooperA |sum| sum:=1e8. sum to: 1 by: -1 do: [:x | sum := (sum bitShift: -1) + x ] . ^sum "B = timesRepeat loop" benchLooperB |sum count| count := sum:=1e8. sum timesRepeat: [ sum := (sum bitShift: -1) + count. count := count - 1 ] . ^sum A and B compute the same except one using #to:by:do:, the other #timesRepeat. The near-machine code for this computation runs about 400msec (0.4 sec) on my test system. (x86 Windows 7, N450 Atom cpu, 1.66GHz) On the following 3 test VM/Images, : 1. Squeak 4.1 stock (vm = Squeak 4.0.2, 2010apr3) 2. Pharo 1.1.1 stock (vm = Cog 2010sep21) 3. Pharo 1.2rc2 + Cog2011feb6 I get the following times for A Time millisecondsToRun: [ Sandbox benchLooperA ] B Time millisecondsToRun: [ Sandbox benchLooperB ] (A, B) execution times rounded to seconds 1. (24, 88) 2. (34, 11) 3. (3, 8) Here we see a 3x-4x difference A to B, with an anomoly that Pharo 1.1.1 is actually much *slower* on #to:by:do: (is it the closure bug (?), see below). (Also we see 8x-11x speedup with the latest Cog-2011feb6, great!) Now here is something odd -- if I invoke the loops via workspace DoIt, the timing changes in Pharo 1.1.1, like this: Time millisecondsToRun: [ |sum| sum:=1e8. sum to: 1 by: -1 do: [:x | sum := (sum bitShift: -1) + x ] . sum ] (highlight and DoIt) (A, B) invoked from workspace, time in seconds 1. (24, 88) 2. (5, 11) 3. (3, 8) The Pharo 1.1.1 timing anomaly for case 2A disappeared - it's now 5 seconds instead of 34. So, 4 questions: * What causes the Pharo 1.1.1. anomaly timing difference for #to:by:do invoked via workspace DoIt vs in the #benchLooper method (5 sec vs 34 sec) ? * Why is the #timesRepeat loop 3x-4x slower than #to:by:do ? Is that simply the difference between inlined and non-inlined methods, or other factors? * Even the best Cog time here is 7x slower vs machine-code (and 20x slower for the timesRepeat case), whereas latest Cog fib: runs at 3x. What factors make this micro-bench loop not as optimizable as fib: for Cog? * Why is the stock Squeak 4.1 VM **220x slower** than machine code for case B = timesRepeat loop, (88 sec vs 0.4 sec) ? Thanks to everyone for insights and comments. -- jbthiel

Feb. 24, 2011