January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] GUI how to screencast available

by Objectiveous

> Hi, > > as I'm beginning to understand how to write a GUI in Pharo, I've made a screencast to show basic layout techniques with panels and buttons: > > http://vimeo.com/8619593 You rock! IMO, screencasts like these speak volumes and help newbies (like me) not only understand the power of smalltalk but, more importantly, help us make the shift away from our conditioning with respect to how software is developed. Good on ya!

Jan. 9, 2010

[Pharo-project] OSProcess

by Carlos Crosetti

Hi, is rhe OSProcess designed to call out an external program from a Windows vm? Regards, Carlos

Jan. 9, 2010

Re: [Pharo-project] Notifications of windows opening/closing/focus

by Schwab,Wilhelm K

Stef, Will do. What is the difference between PharoInBox and PharoTaskForces? I see many references to them, but nothing that clarifies what to use when. Is there a way to get MC to save "part of" a package? Suppose I have DolphinCompatibilty-Streams DolphinCompatibilty-ODBC DolphinCompatibilty-FFI DolphinCompatibilty-Network ... and want to save just the FFI package. Is there a way to do that? I might have been going about it incorrectly, but I found the results to be unpredictable. It matters because I sometimes work under non-disclosure agreements, and it would be really bad to put relevant code in a public respository :( Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, January 08, 2010 3:49 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus On Jan 8, 2010, at 9:38 PM, Schwab,Wilhelm K wrote: > Stef, > > I find it difficult to imagine your being dull on anything, but I guess we all have limits. :) > I have been pushing a little firmly on weak collections because Squeak/Pharo are _way_ behind where Dolphin was 12+ years ago, and it seems avoidable. Yes I imagine well. > So far I have created very simple thread safe (hopefully) wrappers around Dictionary (SharedLookupTable) and Set. The dictionary can be weak in keys or values. I subclass from Object to minimize problems with super classes filling gaps w/o my knowledge. this is why I suggest you publish some code in the PharoTaskForces and get some arguments with others and we all learn :) _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 9, 2010

Re: [Pharo-project] Nanosecond-level profiling in Pharo?

by Eliot Miranda

this is a reply to John's point and to Cesar's ,essage On Thu, Jan 7, 2010 at 8:22 PM, John McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > I think Eliot wanted those in my vm work I think qwaq has them > time to add them I think > Yes. We haven't moved to using it at the image level yet but the VM uses 64-bit microseconds from 1901 internally. The current value of the clock however is updated by the VM's heartbeat which runs anywhere from 500Hz to 1KHz. So while the clock has microsecond precision it only has millisecond resolution. I made a similar change to VisualWorks, which uses 64-bit microseconds from 1901. The advantage is that sub-second time values are actually wall clock values, as opposed to a 32-bit millisecond value that will wrap after 49 days that is unsynchronised with wall time. BTW, 64 bit microseconds from 1901 is ~580,000 years. So with e.g. 61-bit tagged integers in a 64-bit VM with maximum positive value of 2^60 - 1, the clock would take ~35,000 years to overflow tagged integers. > should it return a Long integer or a double > An unsigned long integer. > > On 1/7/10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Some times I wanted smaller grain for running tests... but most of the > > time millis are good enough :) > > > > On 2010-01-07 18:52:16 -0300, Alexandre Bergel > > <alexandre(a)bergel.eu> said: > > > >> Hi! > >> > >> I am currently working on a new profiler for Pharo. The idea is to > >> graphically renders a profiling using Mondrian. I hope to release it > >> soon. > >> When discussing with an expert in the field (Walter Binder), the > >> question about time grain was raised. I am partly based on > >> MessageTally, which has a millisecond grain. Anyone is aware of a > >> finer grain? At the level of nanosecond? Does it makes sense since > >> there is no JIT (yet)? > >> > >> Cheers, > >> Alexandre > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 9, 2010

Re: [Pharo-project] Problems saving the image on SIGTERM

by John M McIntosh

On 2010-01-08, at 8:51 AM, Damien Pollet wrote: > Hi, > - OSProcess does not seem to be able to register signal handlers at > all on the Cocoa VM (5.2b9) Unless you've compiled up a OSProcess for use in 64bit mode you should have had the loading of the 32bit OSProcess fail. If you are running the 5.2b9 VM in 32bit mode it *might* load the plugin, but I don't think I expose the argc/argv in the linker so I think the OSProcess plugin load will again fail. If you alter the info.plist and change SqueakDebug to 1 from 0 it should print a bit more info > > Cheers, > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 9, 2010

Re: [Pharo-project] Method cache

by John M McIntosh

Many many years ago I looked at method caching and how it relates to findings in the "Green Book" and testing showed the same assumptions and results, "a 96.4% cache hit ratio." Here's a note from 2001. > Well back on march 8th 2001 I looked into this (at least the cache part). > So I'll quote a part from my discussion with Dan: > > "Now in mapPointersInObjectsFromto we call > mapInterpreterOops > which calls flushMethodCache. > > Now I was thinking. Watching snow fall is boring after awhile, that couldn't we be smart and delete entries in the cache by looking at it and the range of memory? The trade is how expensive to check and of course being sure it's correct. > > So I moved flushMethodCache into mapPointersInObjectsFromto from it's location in mapInterpreterOops and created a new routine like below which considers if the cache values of oops map to a location within the range of interest, then I clear the cache value. > > I ran this for a little while and found I had > > 1356 flush calls which only resulted in 856 cache entries being invalidated. This seems much better than flushing all 512 entries in the method cache on each incremental GC event. I also noted that in lookupInMethodCacheSelclass, the number of calls was about 50 million,and cache hits: 20M on probe1, 16M on probe2, 11M on probe3 and 1.8M not found > > BTW I looked at atCache, but mmm 'since objects die young' found that over 70% of the at cache would be flushed at any given incremental GC event. (IE 70% of the time objects were in new space)." > ---------------- > > The change made way back then was to flush the cache by location because most flush are a result are newspace GC invocations, and the number of methods in NewSpace is very low. You will note the fact that the method cache of 512 had a 96.4% cache hit ratio. > > Since you can run the Squeak VM in Squeak I'd think you could easily build an instrumented VM that collects bytecode statistics to compare to number in the green book. > > Also note that Scott A Crosby <crosby(a)qwes.math.cmu.edu> on Sun Dec 9, 2001wrote > "New method cache, 30% faster macrobenchmarks and ineffeciencies." > > One should look in the archives for the details > > Mmm now if I recall I'm sure Tim, Ian and I looked (yes in sept 2002) into just the caching changes and couldn't generate > the numbers that justified the complexity (or the extra memory) for the change required. > > On Tuesday, May 13, 2003, at 07:01 AM, Alexandre Bergel wrote: > >> Hello! >> >> By reading the green book, I have some question related the send bytecode (page 210): >> - "Approximately every third instruction is a message send and sends requiring dictionary lookups occur every 6.667 bytecodes. Of the sends needing dictionary searches, 36.64% invoked primitives, and the rest resulted in the execution of a Smalltalk method which, along with process switches, accounted for a context switch every 6.50 > bytecodes." >> - "... 78.92% are arithmetic and logical operations..." >> >> This article was made in 1982, I would like to know it these proportion are still equivalent nowadays. >> >> A bit related to this, what is the effect of the method cache? In the average, what is the % of the method found in the cache? >> >> I heard once that only 1/10th of the message send are really polymorphic, and the rest is mono-morphic. >> >> Cheers, >> Alexandre >> >> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.iam.unibe.ch/~bergel >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > -- On 2010-01-08, at 6:23 AM, Igor Stasenko wrote: > 2010/1/8 Alexandre Bergel <alexandre(a)bergel.eu>: >> Hi! >> >> I think I already know the answer, but I would like to ask still. Is >> there a way in Pharo to know about cache misses? Is there a way to >> know about the method cache within the image? I guess no. Would it be >> hard to add this information? >> > > This is a 'magic' which sits deeply in VM. > Image-side stuff should not care about it much, since it is > implementation specific. > Mainly, because VM could employ different cache strategies , and by > not exposing it, we making sure that > we could change it at any moment. Especially , if we think about JIT > and method inlining... > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 9, 2010

Re: [Pharo-project] Finalization quirk

by John M McIntosh

On 2010-01-08, at 2:28 AM, Adrian Lienhard wrote: > ah, I see. I looked in PharoCore and hence didn't find it. These are > from Damien's www.squeaksource.com/ImageForDevelopers.html > > We should integrate one default policy into PharoCore. What would be a > sensible default? > > Cheers, > Adrian I'm currently looking into what the default values should be -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 9, 2010

Re: [Pharo-project] ConfigurationOfOmniBrowser

by Dale Henrichs

Jan. 9, 2010

Re: [Pharo-project] ConfigurationOfOmniBrowser

by Mariano Martinez Peck

On Sat, Jan 9, 2010 at 12:47 AM, Dale Henrichs <dale.henrichs(a)gemstone.com>wrote: > > ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: > > | So far, I created: ConfigurationOfNewInspector, > | ConfigurationOfOCompletion, > | ConfigurationOfOmniBrowser, ConfigurationOfPharoMorphicExtras, > | ConfigurationOfPharoSound, ConfigurationOfRefactoringBrowser, > | ConfigurationOfShout , and......ConfigurationOfPharo!!! > > Mariano, > > I'm working on a ConfigurationOfOmneBrowser that works on both Squeak and > Pharo (and ultimately GemStone ...). > > Would you prefer that I start a new baseline/version or just overwrite 1.0? > > Hi Dale. Good we are working in OB. This weekend / next-week I want to create a PharoDev image with OB so maybe I would rather if you can create a new baseline (taking 1.0 as a base) and if you want, later we can "merge" if necessary. What do you think ? Is this ok for you ? > I lean towards overwriting, especially this early in the process, but I > want your opinion. > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 8, 2010

[Pharo-project] ConfigurationOfOmniBrowser

by Dale Henrichs

----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | So far, I created: ConfigurationOfNewInspector, | ConfigurationOfOCompletion, | ConfigurationOfOmniBrowser, ConfigurationOfPharoMorphicExtras, | ConfigurationOfPharoSound, ConfigurationOfRefactoringBrowser, | ConfigurationOfShout , and......ConfigurationOfPharo!!! Mariano, I'm working on a ConfigurationOfOmneBrowser that works on both Squeak and Pharo (and ultimately GemStone ...). Would you prefer that I start a new baseline/version or just overwrite 1.0? I lean towards overwriting, especially this early in the process, but I want your opinion. Dale

Jan. 8, 2010