October 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 616625: 40320

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 61662547acfd2442545be7c8734b8ef2a7355d5b https://github.com/pharo-project/pharo-core/commit/61662547acfd2442545be7c8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-22 (Wed, 22 Oct 2014) Changed paths: A KernelTests.package/MethodContextTest.class/instance/tests - ast mapping/testSourceNodeOptimizedBlock.st M OpalCompiler-Core.package/IRSpurSqueakV3PlusClosuresBytecodeGenerator.class/instance/initialize/irPrimitive_.st M OpalCompiler-Core.package/IRSpurSqueakV3PlusClosuresBytecodeGenerator.class/instance/results/compiledMethodWith_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script320.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40320.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40320 14286 add a test for #sourceNode on Contexts for optimized blocks https://pharo.fogbugz.com/f/cases/14286 14283 Slice for Spur integration https://pharo.fogbugz.com/f/cases/14283 http://files.pharo.org/image/40/40320.zip

Oct. 22, 2014

Thanks vonBecman :) and BernardoContreras

by stepharo

Hi guys I want to thank Bernardo because he is the simple example of helping on simple issues that we love to fix but do not have the time because running on urgent ones. Bernardo fixed the complete system package by package, one after the other in this tedious and steady matter and he step by step (let us repeat again) changed all the on:do: annoucememt senders into when:do:. You could think Oh this is easy and not important. It is important. Such systematic actions improve the system! THANKS BERNARDO! Stef PS: I want to THANK NICOLAI HESSE and SVEN for their spirit. You all give me the energy to push.

Oct. 22, 2014

Re: [Pharo-dev] ProtoObject/Proxies

by Mariano Martinez Peck

On Wed, Oct 22, 2014 at 10:18 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > Hi Mariano, > > 2014-10-22 9:53 GMT-03:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Esteban, > > > > You may want to check some proxy implementations I did. You can check > Ghost > > proxies in my PhD thesis: > > http://rmod.lille.inria.fr/archives/phd/PhD-2012-Martinez-Peck.pdf and > > here: https://hal.inria.fr/hal-00877757/PDF/main.pdf > > > I'll take a look into them, thank you. > > > > One of the things I did was to be able to enable (could even be done > > dynamically) debugging capabilities to proxies..that is...proxies would > > understand theirself all necessary methods for > > inspecting/debugging/printing/exploring them without actually > intercepting > > the message. You can read about that in the above links. As a quick > > prototype.... you way want to create a subclass of ProtoObject or > directly > > add those messages to the Glorp proxy. > > That's exactly what I did, and you can see added methods to > AbstractProxy (Glorp) in the latest commits of Glorp at SmalltalkHub. > > However, my mail had two intentions, one is a rant about why some > tools depend on methods defined only in Object but not in ProtoObject > (and hence, most Proxies). > The other intention was to learn about the newcoming Proxies > implementation, about which you helpfully provided two documents to > read about. > > > Also...AFAIK, Camille Teruel was doing some stuff with Ghost Proxies, so > he > > might have the latest version available somewhere. In anycase, my > original > > code was in: http://ss3.gemstone.com/ss/Ghost but saw there is also: > > http://smalltalkhub.com/#!/~CAR/Ghost/ which may be newer. > > So this is the implementation of the previously described thesis? > > Yes. > Thank you! > > > Esteban A. Maringolo > > -- Mariano http://marianopeck.wordpress.com

Oct. 22, 2014

Re: [Pharo-dev] ProtoObject/Proxies

by Mariano Martinez Peck

On Wed, Oct 22, 2014 at 2:20 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I've been hit by a few side effects of using proxies (GLORP ones), > because some tools like the Debugger and/or inspectors expect some > objects to respond to methods not defined in ProtoObject. > > I discovered this by accident because looking at the stack in the > xterm console I saw a recursion triggered by a halt in > UnitOfWork>>#register: > Such halt caused errors that needed to be printed, and because it was > trigger in the context of a Proxy, boom, infinite recursion. > > Why such methods are not implemented in ProtoObject, or at least with > a "basic" version of it. > Is this by design? Methods like #shouldBePrintedAsLiteral or > #isSelfEvaluating (don't know what it means), along others like > #printStringLimitedTo... etc. > > I remember Steph said a better support for Proxies was in the was > roadmap, how far is that? What can be done to speed this up? > Debugging a proxy object (even one that doesn't use #become:) is really > tricky. > > If you look at the implementation of Glorp's Proxy>>#class it seems it > should answer the class of the proxied object (if materialized), but > all that is commented out returning the receiver class, it is > returning Proxy. If you uncomment that weird things happen. I'll come > back to this later, once I have time to reproduce it. > > At some point, #class was optimized by compiler/vm...simply the source code sending #class would end up with a special bytecode that then the VM would execute. Therefore...the method is never executed...you can even delete ProtoObject implementation of #class and it will work hehehe. Anyway...at some point in Pharo, that was changed and #class was not a special bytecode anymore. THERE you could start interpceting #class. For my proxies....(I was using them before Pharo changed) I simply override the compiler to not optimize #class. Then my proxies would answer the class of the target. Cheers, > Please don't forget not everything inherits from Object :) > > Esteban A. Maringolo > > -- Mariano http://marianopeck.wordpress.com

Oct. 22, 2014

Re: [Pharo-dev] ProtoObject/Proxies

by Esteban A. Maringolo

2014-10-22 10:33 GMT-03:00 Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>: > We are using Ghost in TaskIT, and it was straight forward. I never had any > issue :) Is good to know. Maybe I could replace Glorp Proxies based on #doesNotUnderstand: by Ghost proxies based on interceptors and handlers. Regards! Esteban A. Maringolo

Oct. 22, 2014

Re: [Pharo-dev] ProtoObject/Proxies

by Santiago Bragagnolo

We are using Ghost in TaskIT, and it was straight forward. I never had any issue :) 2014-10-22 14:53 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Esteban, > > You may want to check some proxy implementations I did. You can check > Ghost proxies in my PhD thesis: http://rmod.lille.inria.fr/archives/phd/ > PhD-2012-Martinez-Peck.pdf and here: > https://hal.inria.fr/hal-00877757/PDF/main.pdf > > One of the things I did was to be able to enable (could even be done > dynamically) debugging capabilities to proxies..that is...proxies would > understand theirself all necessary methods for > inspecting/debugging/printing/exploring them without actually intercepting > the message. You can read about that in the above links. As a quick > prototype.... you way want to create a subclass of ProtoObject or directly > add those messages to the Glorp proxy. > > Also...AFAIK, Camille Teruel was doing some stuff with Ghost Proxies, so > he might have the latest version available somewhere. In anycase, my > original code was in: http://ss3.gemstone.com/ss/Ghost but saw there is > also: http://smalltalkhub.com/#!/~CAR/Ghost/ which may be newer. > > Cheers, > > > > > > > > > On Wed, Oct 22, 2014 at 2:20 AM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> I've been hit by a few side effects of using proxies (GLORP ones), >> because some tools like the Debugger and/or inspectors expect some >> objects to respond to methods not defined in ProtoObject. >> >> I discovered this by accident because looking at the stack in the >> xterm console I saw a recursion triggered by a halt in >> UnitOfWork>>#register: >> Such halt caused errors that needed to be printed, and because it was >> trigger in the context of a Proxy, boom, infinite recursion. >> >> Why such methods are not implemented in ProtoObject, or at least with >> a "basic" version of it. >> Is this by design? Methods like #shouldBePrintedAsLiteral or >> #isSelfEvaluating (don't know what it means), along others like >> #printStringLimitedTo... etc. >> >> I remember Steph said a better support for Proxies was in the was >> roadmap, how far is that? What can be done to speed this up? >> Debugging a proxy object (even one that doesn't use #become:) is really >> tricky. >> >> If you look at the implementation of Glorp's Proxy>>#class it seems it >> should answer the class of the proxied object (if materialized), but >> all that is commented out returning the receiver class, it is >> returning Proxy. If you uncomment that weird things happen. I'll come >> back to this later, once I have time to reproduce it. >> >> Please don't forget not everything inherits from Object :) >> >> Esteban A. Maringolo >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 22, 2014

Re: [Pharo-dev] ProtoObject/Proxies

by Luc Fabresse

2014-10-22 15:18 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Hi Mariano, > > 2014-10-22 9:53 GMT-03:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi Esteban, > > > > You may want to check some proxy implementations I did. You can check > Ghost > > proxies in my PhD thesis: > > http://rmod.lille.inria.fr/archives/phd/PhD-2012-Martinez-Peck.pdf and > > here: https://hal.inria.fr/hal-00877757/PDF/main.pdf > > > I'll take a look into them, thank you. > > > > One of the things I did was to be able to enable (could even be done > > dynamically) debugging capabilities to proxies..that is...proxies would > > understand theirself all necessary methods for > > inspecting/debugging/printing/exploring them without actually > intercepting > > the message. You can read about that in the above links. As a quick > > prototype.... you way want to create a subclass of ProtoObject or > directly > > add those messages to the Glorp proxy. > > That's exactly what I did, and you can see added methods to > AbstractProxy (Glorp) in the latest commits of Glorp at SmalltalkHub. > > However, my mail had two intentions, one is a rant about why some > tools depend on methods defined only in Object but not in ProtoObject > (and hence, most Proxies). > The other intention was to learn about the newcoming Proxies > implementation, about which you helpfully provided two documents to > read about. > > > Also...AFAIK, Camille Teruel was doing some stuff with Ghost Proxies, so > he > > might have the latest version available somewhere. In anycase, my > original > > code was in: http://ss3.gemstone.com/ss/Ghost but saw there is also: > > http://smalltalkhub.com/#!/~CAR/Ghost/ which may be newer. > > So this is the implementation of the previously described thesis? > yes and the journal paper too. Luc > > Thank you! > > > Esteban A. Maringolo > >

Oct. 22, 2014

Re: [Pharo-dev] ProtoObject/Proxies

by Esteban A. Maringolo

Hi Mariano, 2014-10-22 9:53 GMT-03:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Esteban, > > You may want to check some proxy implementations I did. You can check Ghost > proxies in my PhD thesis: > http://rmod.lille.inria.fr/archives/phd/PhD-2012-Martinez-Peck.pdf and > here: https://hal.inria.fr/hal-00877757/PDF/main.pdf I'll take a look into them, thank you. > One of the things I did was to be able to enable (could even be done > dynamically) debugging capabilities to proxies..that is...proxies would > understand theirself all necessary methods for > inspecting/debugging/printing/exploring them without actually intercepting > the message. You can read about that in the above links. As a quick > prototype.... you way want to create a subclass of ProtoObject or directly > add those messages to the Glorp proxy. That's exactly what I did, and you can see added methods to AbstractProxy (Glorp) in the latest commits of Glorp at SmalltalkHub. However, my mail had two intentions, one is a rant about why some tools depend on methods defined only in Object but not in ProtoObject (and hence, most Proxies). The other intention was to learn about the newcoming Proxies implementation, about which you helpfully provided two documents to read about. > Also...AFAIK, Camille Teruel was doing some stuff with Ghost Proxies, so he > might have the latest version available somewhere. In anycase, my original > code was in: http://ss3.gemstone.com/ss/Ghost but saw there is also: > http://smalltalkhub.com/#!/~CAR/Ghost/ which may be newer. So this is the implementation of the previously described thesis? Thank you! Esteban A. Maringolo

Oct. 22, 2014

Re: [Pharo-dev] ProtoObject/Proxies

by Luc Fabresse

2014-10-22 14:53 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Esteban, > > You may want to check some proxy implementations I did. You can check > Ghost proxies in my PhD thesis: http://rmod.lille.inria.fr/archives/phd/ > PhD-2012-Martinez-Peck.pdf and here: > https://hal.inria.fr/hal-00877757/PDF/main.pdf > > One of the things I did was to be able to enable (could even be done > dynamically) debugging capabilities to proxies..that is...proxies would > understand theirself all necessary methods for > inspecting/debugging/printing/exploring them without actually intercepting > the message. You can read about that in the above links. As a quick > prototype.... you way want to create a subclass of ProtoObject or directly > add those messages to the Glorp proxy. > > Also...AFAIK, Camille Teruel was doing some stuff with Ghost Proxies, so > he might have the latest version available somewhere. In anycase, my > original code was in: http://ss3.gemstone.com/ss/Ghost but saw there is > also: http://smalltalkhub.com/#!/~CAR/Ghost/ which may be newer. > Yes I migrated the code to Sthub. Perhaps I added very few things. I do not remember now. In any case, please use that one. Thx Mariano for taking time to answer ;-) Cheers, Luc > > Cheers, > > > > > > > > > On Wed, Oct 22, 2014 at 2:20 AM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> I've been hit by a few side effects of using proxies (GLORP ones), >> because some tools like the Debugger and/or inspectors expect some >> objects to respond to methods not defined in ProtoObject. >> >> I discovered this by accident because looking at the stack in the >> xterm console I saw a recursion triggered by a halt in >> UnitOfWork>>#register: >> Such halt caused errors that needed to be printed, and because it was >> trigger in the context of a Proxy, boom, infinite recursion. >> >> Why such methods are not implemented in ProtoObject, or at least with >> a "basic" version of it. >> Is this by design? Methods like #shouldBePrintedAsLiteral or >> #isSelfEvaluating (don't know what it means), along others like >> #printStringLimitedTo... etc. >> >> I remember Steph said a better support for Proxies was in the was >> roadmap, how far is that? What can be done to speed this up? >> Debugging a proxy object (even one that doesn't use #become:) is really >> tricky. >> >> If you look at the implementation of Glorp's Proxy>>#class it seems it >> should answer the class of the proxied object (if materialized), but >> all that is commented out returning the receiver class, it is >> returning Proxy. If you uncomment that weird things happen. I'll come >> back to this later, once I have time to reproduce it. >> >> Please don't forget not everything inherits from Object :) >> >> Esteban A. Maringolo >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 22, 2014

Re: [Pharo-dev] ProtoObject/Proxies

by Mariano Martinez Peck

Hi Esteban, You may want to check some proxy implementations I did. You can check Ghost proxies in my PhD thesis: http://rmod.lille.inria.fr/archives/phd/PhD -2012-Martinez-Peck.pdf and here: https://hal.inria.fr/hal-00877757/PDF/main.pdf One of the things I did was to be able to enable (could even be done dynamically) debugging capabilities to proxies..that is...proxies would understand theirself all necessary methods for inspecting/debugging/printing/exploring them without actually intercepting the message. You can read about that in the above links. As a quick prototype.... you way want to create a subclass of ProtoObject or directly add those messages to the Glorp proxy. Also...AFAIK, Camille Teruel was doing some stuff with Ghost Proxies, so he might have the latest version available somewhere. In anycase, my original code was in: http://ss3.gemstone.com/ss/Ghost but saw there is also: http://smalltalkhub.com/#!/~CAR/Ghost/ which may be newer. Cheers, On Wed, Oct 22, 2014 at 2:20 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I've been hit by a few side effects of using proxies (GLORP ones), > because some tools like the Debugger and/or inspectors expect some > objects to respond to methods not defined in ProtoObject. > > I discovered this by accident because looking at the stack in the > xterm console I saw a recursion triggered by a halt in > UnitOfWork>>#register: > Such halt caused errors that needed to be printed, and because it was > trigger in the context of a Proxy, boom, infinite recursion. > > Why such methods are not implemented in ProtoObject, or at least with > a "basic" version of it. > Is this by design? Methods like #shouldBePrintedAsLiteral or > #isSelfEvaluating (don't know what it means), along others like > #printStringLimitedTo... etc. > > I remember Steph said a better support for Proxies was in the was > roadmap, how far is that? What can be done to speed this up? > Debugging a proxy object (even one that doesn't use #become:) is really > tricky. > > If you look at the implementation of Glorp's Proxy>>#class it seems it > should answer the class of the proxied object (if materialized), but > all that is commented out returning the receiver class, it is > returning Proxy. If you uncomment that weird things happen. I'll come > back to this later, once I have time to reproduce it. > > Please don't forget not everything inherits from Object :) > > Esteban A. Maringolo > > -- Mariano http://marianopeck.wordpress.com

Oct. 22, 2014