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

[Pharo-project] Draft chapter on Settings Framework for PBE2 now online

by Oscar Nierstrasz

Hi Folks, There is now a draft chapter on the Settings Framework for "Pharo by Example 2" available for review: https://gforge.inria.fr/frs/download.php/28243/Settings.pdf http://pharobyexample.org/ Cheers, - on

Feb. 8, 2011

Re: [Pharo-project] [COTDC] 4 - RecategorizedEvent

by CÃ©drick BÃ©ler

> Also, AbstractEvent is not commented: and all subclasses... may be not needed to comment them all (except examples maybe - but if they vanish... :) )... all are in system-change-notification category > > I'm a generic event raised by the system (SystemChangeNotifier) when anything (both classes or methods) changes in the system. > Each one of my children represents a specific kind of event the system can notify. > > Now I will soon fade away and be replaced by announcements. > > (not a lot imaginative, but works :)) > > El 07/02/2011, a las 3:25p.m., StÃ©phane Ducasse escribiÃ³: > >> I'm an event raised by the system (SystemChangeNotifier) when a class or a method changed its category. The way to create my instances is the following: >> >> >> (RecategorizedEvent >> method: (aClass compiledMethodAt: selector ifAbsent: [nil]) >> selector: selector >> protocol: newCategory >> class: aClass >> oldProtocol: oldCategory) >> >> >> (RecategorizedEvent >> class: aClass >> category: newCategory >> oldCategory: oldCategory) >> >> Now I will soon fade away and be replaced by announcements. >> >> >> >> >> >> On Feb 7, 2011, at 6:25 PM, laurent laffont wrote: >> >>> 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 >> >> > >

Feb. 8, 2011

[Pharo-project] Status of Alien

by Torsten Bergmann

What is the status of Alien. According to http://bugs.squeak.org/view.php?id=7475 there is no one who confirmed it working on Linux. Any news here? Any ideas on FFI/Alien successor? Thanks T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

Feb. 8, 2011

Re: [Pharo-project] [SPAM] Re: [COTDC] 3 - HTTPClient

by laurent laffont

On Mon, Feb 7, 2011 at 9:52 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Haha, > > Perhaps there should also be a rating for class comments ... G, PG, R, > NSFW... > We can vote on 1st March to deliver the "Best Comment Of The Month" Award :) Laurent > > Dale > > > On 02/07/2011 12:07 PM, StÃ©phane Ducasse wrote: > >> this is more HTTPSocket >> I'm sure that philippe will love to answer :) >> >> Stef >> >> >> On Feb 7, 2011, at 8:23 PM, Dmitri Zagidulin wrote: >> >> Actually, can somebody explain the troll-mode comment? Why is the >>> HTTPClient an example of how not to write code? Should we not be using >>> this package in production? What does the comment about "hacker with >>> telnet"-protocol mean? >>> >>> On Mon, Feb 7, 2011 at 2:12 PM, Luc Fabresse<luc.fabresse(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> 2011/2/7 laurent laffont<laurent.laffont(a)gmail.com> >>>> >>>>> >>>>> FYI I put results >>>>> here: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >>>>> >>>> >>>> Thanks Laurent. >>>> It is a really great because it document the system and I learn a lot at >>>> the >>>> same time ;-) >>>> #Luc >>>> >>>> >>>>> Laurent >>>>> >>>>> On Mon, Feb 7, 2011 at 4:33 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> >>>>>> :) >>>>>> We should just merge the two :) >>>>>> >>>>>> >>>>>> <trollmode> >>>>>>>>> I'm a good example of how not to write code. Turn around, walk >>>>>>>>> away, >>>>>>>>> fast. I'm fully of bugs. >>>>>>>>> >>>>>>>>> Somebody at some point thought that HTTP is a simple "hacker with >>>>>>>>> telnet"-protocol. It's not. >>>>>>>>> </trollmode> >>>>>>>>> >>>>>>>> >>>>>>>> That's actually HTTPSocket, not HTTPClient. >>>>>>>> >>>>>>> >>>>>>> Although it is a negative comment, it is the truth. >>>>>>> >>>>>>> Still, adding some comments and lowering the pain for others is still >>>>>>> a >>>>>>> good idea. >>>>>>> >>>>>>> Sven >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > >

Feb. 8, 2011

Re: [Pharo-project] Our response to JS proxy API + Cog regression

by Eliot Miranda

Hi Igor, On Wed, Feb 2, 2011 at 1:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > (@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. > Yes, I didn't implement the cannotInterpret: hook for Cog fully. I'll take a look at this soon. cheers, Eliot > [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. >

Feb. 8, 2011

Re: [Pharo-project] copying all versions to squeaksource

by HwaJong Oh

Yes, GUI will make it easier for me. Gofer is powerful but need study to understand it. Best Regards -- View this message in context: http://forum.world.st/copying-all-versions-to-squeaksource-tp3263732p326552… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 8, 2011

Re: [Pharo-project] copying all versions to squeaksource

by HwaJong Oh

Hey I got my hands on to Gofer! Thanks! Gofer it url: 'http://squeaksource.com/3748782' username: '2034' password: '34058'; package: 'PocketCube'; push. I need to find ways to set source repository of the push operation from "package-cache" to my dir repo. Best Regards -- View this message in context: http://forum.world.st/copying-all-versions-to-squeaksource-tp3263732p326548… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 8, 2011

Re: [Pharo-project] Canvas >>draw: anObject

by Igor Stasenko

On 7 February 2011 22:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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? > yes, SMxCanvas ensures that not matter what happens, a morph cannot draw outside of its declared bounds. Which usually should not happen anyways.. so it looks like an additional rule enforcement. > Stef > -- Best regards, Igor Stasenko AKA sig.

Feb. 7, 2011

Re: [Pharo-project] Canvas>>render:

by Igor Stasenko

it looks like a double-dispatch pattern, same as draw/drawOn: . Its of course completely useless unless you have objects capable of rendering. Also, i'm not sure that crossing 2D -> 3D could be done so easily and painless as this method proposing.. and i'm not sure that mixing them is a good idea: - original canvas operating at bitmap level - 3d canvas operating at triangle/mesh level(s) On 7 February 2011 22:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 7, 2011

[Pharo-project] Issue 3685 in pharo: #createUserSubclass:instVarNames:categoryName: no longer accepts an inst var array

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3685 by ya...(a)rogers.com: #createUserSubclass:instVarNames:categoryName: no longer accepts an inst var array http://code.google.com/p/pharo/issues/detail?id=3685 Pharo core version: Pharo1.2rc2 Latest update: #12324 In Pharo1.1 the instance variables could be passed as an array. See attached testcase, or, for example: SomeClass createUserSubclass: 'SomeSubclass' instVarNames: #(id varOne varTwo) categoryName: 'Test'. The code change here, looks to be the cause: ClassBuilder>>name: className inEnvironment: env subclassOf: newSuper type: type instanceVariableNames: instVarString classVariableNames: classVarString poolDictionaries: poolString category: category unsafe: unsafe < instVars := instVarString subStrings: ' '. < classVars := (classVarString subStrings: ' ') collect: [ :x | x asSymbol ]. "Validate the proposed name" -- > instVars := Scanner new scanFieldNames: instVarString. > classVars := (Scanner new scanFieldNames: classVarString) collect: [ :x > | x asSymbol ]. "Validate the proposed name" This issue came up in some code that was originally derived from some GemStone code. Maybe it was never intended that instVarNames could be passed in as an array. I've changed my code to pass an instVarString, but I thought I'd mention the changed behaviour here. Attachments: ClassBuilderFormatTests-testSubclassWithInstanceVariablesArray.st 565 bytes

Feb. 7, 2011