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

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

by Igor Stasenko

On 2 February 2011 23:25, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > Just by curiosity, is there a problem that could be tackled using the > StratificationProxy that cant be solved nowadays in Pharo? > Any problem where you usually using proxies. These proxies just make sure that nothing can go past handler unnoticed. > At least one example of usage would be interesting to learn. > Well, i had need such proxies once to provide a syntactic sugar for lambda-message-sends. lambdas could be built directly using message sends, i.e.: lambda foo: bar. are turned into instance of Lambda( receiver=lambda , selector = #foo: , arguments = #(bar)) now everything works fine, if lambda does not implements #foo: message, and therefore by sending it, it intercepts this message in own DNU handler and creates a new lambda which encapsulating a message send and its argument(s). But when message is implemented by Lambda itself, things become less simple and more tedious, because i need to initialize Lambda fields manually, i.e. instead of writing: newLambda := lambda at: 1. i need to write: newLambda := Lambda receiver: lambda selector: #at: arguments: #(1). but using the proxy i can write it like following: newLambda := lambda pure at: 1. where #pure means that message send which will follow given message is guaranteed to be captured as LMS instead of being invoked normally. > Fernando > > -- Best regards, Igor Stasenko AKA sig.

Feb. 2, 2011

Re: [Pharo-project] what do we do for OmniBrowser?

by Johan Brichau

I want to use OB in 1.2 and that means I'm in for contributing as well. I just started trying 1.2-dev in the last couple of days and it seems not so many things are failing with OB? Am I wrong? 4 tests are failing in the image and there seems to be very few issues on the Pharo tracker about (most of them have a proposed fix). On 02 Feb 2011, at 15:57, Dmitri Zagidulin wrote: > (btw, I still > can't believe we as a community let SeasideTesting be broken in 1.2). Well, I just tested it in 1.2 for the first time and it works.... If something doesn't work for you, please send an email on the seaside mailinglist. I am actively using and maintaining SeasideTesting (whenever possible) and willing to help out if people experience problems. Mind that the external browser testing is a new feature that David included in his new version in VisualWorks but which I did not port to Pharo/Squeak (yet). However, the traditional simulated browser testing is working. We have over 300 tests in our application that use seaside testing. cheers, Johan

Feb. 2, 2011

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

by Fernando Olivero

Just by curiosity, is there a problem that could be tackled using the StratificationProxy that cant be solved nowadays in Pharo? At least one example of usage would be interesting to learn. Fernando On Wed, Feb 2, 2011 at 9: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. > > [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. 2, 2011

Re: [Pharo-project] Issue 3648 in pharo: A "Stratified" proxy in smalltalk

by pharo＠googlecode.com

Comment #2 on issue 3648 by siguc...(a)gmail.com: A "Stratified" proxy in smalltalk http://code.google.com/p/pharo/issues/detail?id=3648 keep in mind that this code is for review. not for immediate integration.

Feb. 2, 2011

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

by pharo＠googlecode.com

Comment #9 on issue 3609 by fernando...(a)gmail.com: Integrate RPackage http://code.google.com/p/pharo/issues/detail?id=3609 Added the convienience method SimplePackageOrganizerBrowser>>openOnGlobalPackages. Because the class comments were lacking a working example. If agreed, then we could change the class comment to use this method as an example. Fernando

Feb. 2, 2011

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

by Igor Stasenko

(@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.

Feb. 2, 2011

Re: [Pharo-project] Issue 3648 in pharo: A "Stratified" proxy in smalltalk

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3648 by stephane...(a)gmail.com: A "Stratified" proxy in smalltalk http://code.google.com/p/pharo/issues/detail?id=3648 I want that! :) Stef

Feb. 2, 2011

[Pharo-project] About *your* time and contributions

by stephane ducasse

Hi guys from the outside you can think that we have plenty of time or spending a lot of time in pharo, in fact we are just mad guys running like mad (only igor have time - but he cannot sleep the night because he wants to hack a lot of great stuff like openvg, nativeboost,....), we are fighting to grab time and improve the system. Seriously what is important is that ****EVERYBODY**** is important, each single person using pharo is important: there is no causal user, you are all important and you also can all get an IMPACT. Imagine that you all spend 10 min writing a class or method comment on the method you use frequently in your favorite package (SOUP, XML... pick one) every two days (ie less than the time reading this mail. Then suddenly the ratio of comment will increase! So what I want to say is that there is no little contribution. They all have their value and we love them. Sometimes it will take us more time to integrate that you doing them but it does not matter (we should fix the process), so consider that you have a value for us and for the system we are building together. Stef

Feb. 2, 2011

[Pharo-project] Issue 3648 in pharo: A "Stratified" proxy in smalltalk

by pharo＠googlecode.com

Status: Started Owner: siguc...(a)gmail.com Labels: Type-RequestForEnhancement New issue 3648 by siguc...(a)gmail.com: A "Stratified" proxy in smalltalk http://code.google.com/p/pharo/issues/detail?id=3648 This is an implementation of A "Stratified" proxy in smalltalk. Note: The category/package name should be changed before integrating into image. Attachments: StratifiedProxy.st 5.5 KB StratifiedProxy-Tests.st 719 bytes

Feb. 2, 2011

Re: [Pharo-project] [ANN] New Cocoa Squeak VM release

by Esteban Lorenzano

4.2.5 was working Esteban El 02/02/2011, a las 3:56p.m., StÃ©phane Ducasse escribiÃ³: >> It should be, but right now, I'm getting an "Unsupported calling convention". And same error with 5.7b3 >> >> yet another task :( >> my todo list is really, really long :P > > Do you know a VM on which it worked? Because we checked with igor and could not make it. > > Stef

Feb. 2, 2011