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

[Pharo-project] [COTDC] 5 - PseudoFileStream
by laurent laffont Feb. 9, 2011

Feb. 9, 2011

Today: PseudoFileStream Comment Of The Day Contest - One Day One Comment Rules: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

10 18

[Pharo-project] new Cog VMs available
by Eliot Miranda Feb. 9, 2011

Feb. 9, 2011

Hi All, new Cog VMs are available, SimpleStackBasedCogit @ http://www.mirandabanda.org/files/Cog/VM/VM.r2359/ and StackToRegisterMappingCogit @ http://www.mirandabanda.org/files/Cog/VM/VM.r2361. I think the new code generator is ready for prime time now. I fixed a number of bugs over the past three weeks and we're now using the StackToRegisterMappingCogit internally at Teleplace. There's still work to be done merging plugins and details with the standard VMs but I hope that r2361 is production-ready as far as core Smalltalk execution is concerned. Enjoy. Eliot

9 17

[Pharo-project] [COTDC] 4 - RecategorizedEvent
by laurent laffont Feb. 8, 2011

Feb. 8, 2011

Comment Of The Day Contest - One Day One Comment Rules: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). Today: RecategorizedEvent Laurent

7 9

[Pharo-project] Delay error after system crash
by Esteban Lorenzano Feb. 8, 2011

Feb. 8, 2011

Hi, I'm having a problem with Delay after a system crash (yeah, the real problem is the system crash, but I'm also having this one after it happens) I have several processes running who monitor some state, and synchronize some file outs (the sync is made using a mutex). The original crash seems to be happening somewhere there. After the crash, I restart the image tries to reconstruct the data (taking the files previously saved) and I'm getting this error: THERE_BE_DRAGONS_HERE Error: This Delay has already been scheduled. 8 February 2011 5:00:05 am VM: unix - i686 - linux-gnu - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35] Image: Pharo-1.1.1-- [Latest update: #11414] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/administrator/emanual Trusted Dir /home/administrator/emanual/secure Untrusted Dir /home/administrator/emanual/My Squeak Delay(Object)>>error: Receiver: a Delay(10 msecs; 10 msecs remaining) Arguments and temporary variables: aString: 'This Delay has already been scheduled.' Receiver's instance variables: delayDuration: 10 resumptionTime: 18218709 delaySemaphore: a Semaphore(a Process in [] in Delay>>wait) beingWaitedOn: true Delay>>schedule Receiver: a Delay(10 msecs; 10 msecs remaining) Arguments and temporary variables: Receiver's instance variables: delayDuration: 10 resumptionTime: 18218709 delaySemaphore: a Semaphore(a Process in [] in Delay>>wait) beingWaitedOn: true Delay>>wait Receiver: a Delay(10 msecs; 10 msecs remaining) Arguments and temporary variables: Receiver's instance variables: delayDuration: 10 resumptionTime: 18218709 delaySemaphore: a Semaphore(a Process in [] in Delay>>wait) beingWaitedOn: true InputEventPollingFetcher>>waitForInput Receiver: an InputEventPollingFetcher Arguments and temporary variables: Receiver's instance variables: eventHandlers: an OrderedCollection(a RFBEventSensor an UserInterruptHandler) fetcherProcess: a Process in Debugger class>>openOn:context:label:contents:full...etc... inputSemaphore: a Semaphore() InputEventPollingFetcher(InputEventFetcher)>>eventLoop Receiver: an InputEventPollingFetcher Arguments and temporary variables: eventBuffer: #(0 0 0 0 0 0 0 0) type: 0 window: nil Receiver's instance variables: eventHandlers: an OrderedCollection(a RFBEventSensor an UserInterruptHandler) fetcherProcess: a Process in Debugger class>>openOn:context:label:contents:full...etc... inputSemaphore: a Semaphore() [] in InputEventPollingFetcher(InputEventFetcher)>>installEventLoop Receiver: an InputEventPollingFetcher Arguments and temporary variables: Receiver's instance variables: eventHandlers: an OrderedCollection(a RFBEventSensor an UserInterruptHandler) fetcherProcess: a Process in Debugger class>>openOn:context:label:contents:full...etc... inputSemaphore: a Semaphore() [] in BlockClosure>>newProcess Receiver: [self eventLoop] Arguments and temporary variables: Receiver's instance variables: outerContext: InputEventPollingFetcher(InputEventFetcher)>>installEventLoop startpc: 48 numArgs: 0 --- The full stack --- Delay(Object)>>error: Delay>>schedule Delay>>wait InputEventPollingFetcher>>waitForInput InputEventPollingFetcher(InputEventFetcher)>>eventLoop [] in InputEventPollingFetcher(InputEventFetcher)>>installEventLoop [] in BlockClosure>>newProcess Any idea what can be causing this? I also noticed that there is another error when the image restarts: 'Trying to activate Delay twice' which is thrown on Delay class>>#startUp Any idea what can be happening? Cheers, Esteban

2 2

[Pharo-project] Fwd: [squeak-dev] Squeak vs Python "smack down"
by StÃ©phane Ducasse Feb. 8, 2011

Feb. 8, 2011

From: GÃ¶ran Krampe <goran(a)krampe.se> > Date: February 8, 2011 12:01:48 AM GMT+01:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org>, Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Subject: [squeak-dev] Squeak vs Python "smack down" > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > Hi folks! > > Since we are on the verge of 4.2, and we have a brand new Cog VM to play with I felt like dusting off my old Pystone port to Squeak - Sqystone, which I wrote back in 2004. > > At that time Squeak was around 5 times faster than CPython. How do we stack up today? Yeah, I know - hardly a good benchmark, they all lie etc etc. :) > > I am using Ubuntu 10.10 on a corei7, so this is running on a 64 bit CPU. > > > Cog! > ==== > Squeak 4.2-10966 (soon to be released) + latest Cog r2361 (binary download): > Pystone(1.1) time for 50000 passes = 0.06 > This machine benchmarks at 833333.3 pystones/second > > NOTE: AFAICT running with more passes does not improve it. Also, not sure if I could get more out of this if I built from source on my box. > > > Regular Squeak > ============== > Squeak 4.2-10966 (soon to be released) + regular Squeak VM 4.4.7-2357 (built from src): > Pystone(1.1) time for 50000 passes = 0.503 > This machine benchmarks at 99403.6 pystones/second > > > Regular CPython > =============== > CPython 3.1.2 (newest in Ubuntu Meerkat, minimal): > gokr@quigon:/usr/lib/python3.1/test$ python3.1 pystone.py > Pystone(1.1) time for 50000 passes = 0.57 > This machine benchmarks at 87719.3 pystones/second > > NOTE: 3.2 is reportedly a teeny bit faster. Also not built from source. > > > Pypy 1.4 > ======== > wget http://pypy.org/download/pypy-1.4.1-linux64.tar.bz2 > gokr@quigon:~/python/pypy-1.4.1-linux64$ ./bin/pypy ./lib-python/2.5.2/test/pystone.py > Pystone(1.1) time for 50000 passes = 0.15 > This machine benchmarks at 333333 pystones/second > gokr@quigon:~/python/pypy-1.4.1-linux64$ ./bin/pypy ./lib-python/2.5.2/test/pystone.py 5000000 > Pystone(1.1) time for 5000000 passes = 4.8 > This machine benchmarks at 1.04167e+06 pystones/second > > NOTE: Also not built from source. Here we run pystone a second time with 100x more loops and get a substantially better number. > > > Shedskin 0.7 > ============ > sudo apt-get install g++ libpcre3-dev libgc-dev python-dev > sudo dpkg -i shedskin_0.7_all.deb > wget http://shedskin.googlecode.com/files/shedskin-examples-0.7.tgz > shedskin pystone.py > gokr@quigon:~/python/shedskin-examples-0.7$ make > g++ -O2 -march=native -fomit-frame-pointer -Wno-deprecated -I. -I/usr/share/shedskin/lib /usr/share/shedskin/lib/builtin.cpp pystone.cpp /usr/share/shedskin/lib/time.cpp /usr/share/shedskin/lib/re.cpp -lgc -lpcre -o pystone > gokr@quigon:~/python/gokr@quigon:~/python/shedskin-examples-0.7$ ls -la pystone* > -rwxr-xr-x 1 gokr gokr 297329 2011-02-07 23:01 pystone > -rw-r--r-- 1 gokr gokr 9193 2011-02-07 23:00 pystone.cpp > -rw-r--r-- 1 gokr gokr 1893 2011-02-07 23:00 pystone.hpp > -rw-r--r-- 1 gokr gokr 5774 2010-12-11 11:40 pystone.py > gokr@quigon:~/python/shedskin-examples-0.7$ ./pystone > This machine benchmarks at 2500000.000000 pystones/second > > NOTE: I am wondering a bit about this. It tells the same whatever loops I give it... But ok, perhaps it is all fine. > > > Summary > ======= > > - The regular Squeak VM has not been overrun by CPython in these 6 years time. When I wrote Sqystone Squeak was 5x faster IIRC (can't find the post anymore). Now they are equal more or less, Squeak still a teeny bit faster. > > - Cog is brutally fast on this one. Compared to CPython and regular Squeak almost 10x faster. > > - Pypy is about 20% faster than Cog if given enough time to actually start jitting. Cool for the Pypy project! And cool that they aren't that much faster than Cog. :) > > - Shedskin is the "state of the art" of statically compiling Python via C++ using type inferencing etc etc - so I hear. It is said to be faster than Cython and Psyco. It ends up beating Cog, but "only" by a factor of 3x. I say "only" because that seems pretty good to me given that Cog is a JIT and still pretty young and that Shedskin can only run a subset of Python. Rerunning Cog and CPython too with 5000000 loops didn't change the numbers much, but for Shedskin it turns out more proper: gokr@quigon:~/python/shedskin-examples-0.7$ ./pystone This machine benchmarks at 3546099.290780 pystones/second 50000 loops was just too small. So in fact it is about 4.4x faster than Cog. And yes, the ported pystone for shedskin had the loops hard coded. :) regards, GÃ¶ran

1 0

[Pharo-project] Fwd: Canvas >>draw: anObject
by StÃ©phane Ducasse Feb. 8, 2011

Feb. 8, 2011

Begin forwarded message: > From: "juan(a)jvuletich.org" <juan(a)jvuletich.org> > Date: February 8, 2011 2:25:33 AM GMT+01:00 > To: stephane.ducasse(a)inria.fr, juan(a)jvuletich.org > Subject: RE: Canvas >>draw: anObject > Reply-To: juan(a)jvuletich.org > > (Please forward to Pharo, it seems I can't send to it from webmail) > > The difference is not really important. If you have a Morph that draws > outside > its bounds (no morph should ever do that) the version in SM (I guess it is > the > original Squeak code), will clip. The Pharo version won't. That means that > such > a morph would leave a trail if moved around. > > For example, I just added: > aCanvas fillRectangle: (bounds translateBy: 10) fillStyle: Color red. > at the start of EllipseMorph>>drawOn: , and modified #draw: to be like in > Pharo. > Then you open an ellipse, and when you move it around it leaves red garbage. > > If morphs work properly, then it makes no difference. Maybe a very slight > performance difference, but not sure. > > HTH. > > Cheers, > Juan Vuletich > > Original Message: > ----------------- > From: StÃ©phane Ducasse stephane.ducasse(a)inria.fr > Date: Mon, 7 Feb 2011 22:41:08 +0100 > To: juan(a)jvuletich.org, Pharo-project(a)lists.gforge.inria.fr > Subject: Canvas >>draw: anObject > > > Canvas>>draw: anObject > ^anObject drawOn: self > > > Now in SM we got > > SMxCanvas>>draw: anObject > ^self clipBy: anObject bounds during: [ :c | anObject drawOn: c] > > and I'm wondering what is the exact difference. > Any idea? > > Stef > > > -------------------------------------------------------------------- > mail2web.com â Enhanced email for the mobile individual based on MicrosoftÂ® > Exchange - http://link.mail2web.com/Personal/EnhancedEmail > >

1 0

[Pharo-project] Canvas>>render:
by StÃ©phane Ducasse Feb. 8, 2011

Feb. 8, 2011

Hi I have the impression that we could remove this method and friends since it definition on FormCanvas is render: anObject "Do some 3D operations with the object if possible" ^self asBalloonCanvas render: anObject But BalloonCanvas does not implement render: and Canvas>>render: anObject "Do some 3D operations with the object if possible" is a nop. Stef

3 2

[Pharo-project] Our response to JS proxy API + Cog regression
by Igor Stasenko Feb. 8, 2011

Feb. 8, 2011

(@Eliot, don't skip this message there is a regression detected in Cog with this stuff). I read the paper, which i found once on Stephane's table: Proxies: Design Principles for Robust Object-oriented Intercession APIs [1] and we discussed it.. and while there is not much interesting stuff for smalltalkers, still a couple of things were said about smalltalk that was not quite true :) The main point was: in smalltalk you can't do proper stratification. Yes, we can. Some background: ---- 4.3 Stratification Bracha and Ungar [2] introduce the principle of stratifica- tion for mirror-based architectures. The principle states that meta-level facilities must be separated from base-level func- tionality. Bracha and Ungar focus mostly on stratification in the context of introspection and self-modification. In this pa- per we focus on the application of this principle to interces- sion. Mirrors are further discussed in Section 7.2. The distinction between a proxy and its handler object enforces stratification of the traps. Traps are not defined as part of the interface of the proxy object, but as part of the interface of the handler. The handler is a regular object. It may inherit from other objects, and its inheritance chain is completely independent from that of the proxy it handles. A single handler may handle multiple proxies. The handler can be a proxy itself (we will illustrate a use case of this in Section 4.5). Accessing aProxy.has explicitly on a proxy will not trig- ger the proxyâs corresponding has trap. Instead, the access will be reified like any other as handler.get(aProxy,âhasâ). Like- wise, aProxy.get is reified as handler.get(aProxy,âgetâ). Traps can only be invoked explicitly on a proxyâs handler, not on the proxy itself. This enforces stratification (the meta-level traps should not interfere with base-level method names). Thus, proxies continue to work correctly if an application (by ac- cident or by design) uses the names get, set, etc. The principle of stratification when applied to proxies can be summarized as follows. Stratification: a proxyâs traps should be stratified by defining them on a separate handler object. ---- Usually, when implementing a proxies in smalltalk, we are creating a subclass of Object, or ProtoObject and then by using DNU pattern implementing a handler for messages. It works most of the ways, except that for #doesNotUnderstand: and rest of method implemented in Object/ProtoObject you cannot make difference if this message sent by VM (because of lookup failure) or it were sent directly to proxy object, like: proxy doesNotUnderstand: foo So, such kind of proxies are not having proper stratification. But it does not means that we could not have a proper 'stratification' in smalltalk.. The proxy implementation, which i presented more than a year ago doing it without much problems. In [2] there is "beautified" "stratified" proxy implementation + some examples which showing how to implement various kinds of proxies based on it. So, to the summary, which can be found at the end of that paper, we can to add some corrections: API: Smalltalk cannotInterpret: Values that can be virtualized - it was like that before JS were born Stratification - yes, sure, why not Temporary Intercession - yes, sure, why not Meta-level shifting - yes, sure, why not Meta-level funnelling - yes, sure, why not Selective interception - No, since all interaction is via messages, and all messages are trapped Fundamental vs. Derived Traps - we don't need that BS Handler Encapsulation - piece of cake Uniform intercession - it was like that before JS were born :) There is only one thing, which not OK with it: - Cog having a regression comparing to Squeak VM. Its not handling #cannotInterpret: message correctly. [1] research.google.com/pubs/archive/36574.pdf [2] http://code.google.com/p/pharo/issues/detail?id=3648 -- Best regards, Igor Stasenko AKA sig.

4 4

[Pharo-project] [COTDC] 3 - HTTPClient
by laurent laffont Feb. 8, 2011

Feb. 8, 2011

Comment Of The Day Contest - One Day One Comment Rules: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). Today: HTTPClient Laurent

9 22

[Pharo-project] copying all versions to squeaksource
by HwaJong Oh Feb. 8, 2011

Feb. 8, 2011

Hi, I've figured out how to copy 97 version of mine to squeaksource, quickly. Is there a standard way to do this? MCVersionInspector >> copyAllVersionsToSqueakSourceRepository | repository | repository := MCHttpRepository location: 'http://www.squeaksource.com/3748782' user: '2034' password: '34058'. 1 to: self versionList size do: [:ii| self versionSelection: ii. repository storeVersion: version ]. Best Regards HwaJong Oh -- View this message in context: http://forum.world.st/copying-all-versions-to-squeaksource-tp3263732p326373… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 5