[Pharo-project] Implementing MethodWrappers in Smalltalk
Hi folks. I was reading the PBE chapter about reflection where it talks a little about Method Wrappers. Then, I took a look at TestCoverage implementation. After that, I took a look at http://www.squeaksource.com/ObjectsAsMethodsWrap The main difference between both approaches are: TestCoverage - Just extends from ProtoObject, implement doesNotUnderstand: , run: aSelector with: anArray in: aReceiver , etc - To install and uninstall the wrappers uses methodDictionary at: xxx put: yyy - Just for test coverage. ObjectAsMethodWrapper - Is more generic, support pre and post closures, and you can subclass and create you own wrapper - To install and uninstall the wrappers it uses Class >> addSelector: self selector withMethod: self So...what I did ?? I created a TestCoverage but creating a subclass of ObjectAsMethodWrapper called TestCoverageMethodWrapper which just implements a 1 or 2 methods. I mean, I reused the generic ObjectAsMethodWrapper. It seems to work ok. I did some test running TestCoverage with both implementation and it seems mine (TestCoverageMethodWrapper) is 30% much slower than the original. Trying to understand why, I think it is because the original one uses just methodDictionary at: xxx put: yyy but mine uses Class >> addSelector: self selector withMethod: self. In this last method, there are all the notifications, add to localSelectors...etc Now...I have two questions: 1) For a generic approach to method wrappers, which of those two ways would you use ? should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ? 2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness. so...what do you think ? Cheers Mariano
1) For a generic approach to method wrappers, which of those two ways would you use ? Â should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ?
I used #at:put: because we put-back the identical compiled methods as fast as possible, even while the tests are running. Triggering notifications while running might also cause undesired side effects. Also note that code doing reflection (iterating over pragmas, literals, ...) might break if you are not super careful.
2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness.
I guess it is slower because it is very generic and does block activations.
so...what do you think ?
There are also MethodWrappers from the RB engine that come with an integration into OB. I wouldn't include the extra package, after all the implementation is pretty simple and also very specific. For a different use-case the implementation would probably look completely different. Check the mailing list, we had some discussions and did various iterations back when this was integrated. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mon, Mar 22, 2010 at 6:20 PM, Lukas Renggli <renggli@gmail.com> wrote:
1) For a generic approach to method wrappers, which of those two ways would you use ? should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ?
I used #at:put: because we put-back the identical compiled methods as fast as possible, even while the tests are running.
how do you do that ? your fork for each to run the tests ?
Triggering notifications while running might also cause undesired side effects. Also note that code doing reflection (iterating over pragmas, literals, ...) might break if you are not super careful.
Ok, thanks for the note :)
2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness.
I guess it is slower because it is very generic and does block activations.
so...what do you think ?
There are also MethodWrappers from the RB engine that come with an integration into OB.
Any point here ? classname ?
I wouldn't include the extra package, after all the implementation is pretty simple and also very specific. For a different use-case the implementation would probably look completely different. Check the mailing list, we had some discussions and did various iterations back when this was integrated.
Ok, perfect. Thanks! Mariano
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I used #at:put: because we put-back the identical compiled methods as fast as possible, even while the tests are running.
how do you do that ?  your fork for each to run the tests ?
After the wrapper is hit for the first time it replaces itself with the original method. For this basic kind of coverage we don't need to count and like this we can avoid speed penalty if a method is executed many times.
Triggering notifications while running might also cause undesired side effects. Also note that code doing reflection (iterating over pragmas, literals, ...) might break if you are not super careful.
Ok, thanks for the note :)
There are also MethodWrappers from the RB engine that come with an integration into OB.
Any point here ? classname ?
http://www.squeaksource.com/MethodWrappers The implementation is ugly, this is code that was written before there was #run:withArguments:, however it has a protocol compatible with other Smalltalk platforms. http://source.lukas-renggli.ch/omnibrowser/OB-Wrapper Provides a simple integration into OB to wrap a set of classes with any defined wrapper. Lukas
I wouldn't include the extra package, after all the implementation is pretty simple and also very specific. For a different use-case the implementation would probably look completely different. Check the mailing list, we had some discussions and did various iterations back when this was integrated.
Ok, perfect.
Thanks!
Mariano
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Hi Mariano, I worked on a similar problem for a new code profiler. Spy is a framework for easily performing program execution analysis. A short tutorial, screenshots, and some examples are available on: http://www.moosetechnology.org/tools/Spy If you're working in that direction, I would be delighted to collaborate. Cheers, Alexandre On 22 Mar 2010, at 12:51, Mariano Martinez Peck wrote:
Hi folks. I was reading the PBE chapter about reflection where it talks a little about Method Wrappers. Then, I took a look at TestCoverage implementation.
After that, I took a look at http://www.squeaksource.com/ObjectsAsMethodsWrap
The main difference between both approaches are:
TestCoverage - Just extends from ProtoObject, implement doesNotUnderstand: , run: aSelector with: anArray in: aReceiver , etc - To install and uninstall the wrappers uses methodDictionary at: xxx put: yyy - Just for test coverage.
ObjectAsMethodWrapper - Is more generic, support pre and post closures, and you can subclass and create you own wrapper - To install and uninstall the wrappers it uses Class >> addSelector: self selector withMethod: self
So...what I did ?? I created a TestCoverage but creating a subclass of ObjectAsMethodWrapper called TestCoverageMethodWrapper which just implements a 1 or 2 methods. I mean, I reused the generic ObjectAsMethodWrapper. It seems to work ok.
I did some test running TestCoverage with both implementation and it seems mine (TestCoverageMethodWrapper) is 30% much slower than the original. Trying to understand why, I think it is because the original one uses just methodDictionary at: xxx put: yyy but mine uses Class >> addSelector: self selector withMethod: self. In this last method, there are all the notifications, add to localSelectors...etc
Now...I have two questions:
1) For a generic approach to method wrappers, which of those two ways would you use ? should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ?
2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness.
so...what do you think ?
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mon, Mar 22, 2010 at 9:31 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Hi Mariano,
I worked on a similar problem for a new code profiler. Spy is a framework for easily performing program execution analysis. A short tutorial, screenshots, and some examples are available on: http://www.moosetechnology.org/tools/Spy
If you're working in that direction, I would be delighted to collaborate.
Hi Alexandre. I am not sure if it is in the same direction, but anyhow it is worth to look at it. I will try to do it this week and I will let you know. Basically, what i am investigating is: I want to develop a mechanism for Smalltalk that automatically can swap out objects that are not needed but still have objects pointing to them (otherwise the GC would take care), and bring them again when needed. So...image an image that can increase or decrease on demand and automatically. I have several steps, but the first one is how to detect those objects. I have different approaches in mind. For a first moment, I was trying to detect which classes and which methods were being used. Of course, the first approach (although it will probably not scale) was to create a method wrapper for that. Even almost the same as TestCoverage. Now I am looking at CUIS' ProtocolCatcher, which has a different approach. Cheers Mariano
Cheers, Alexandre
On 22 Mar 2010, at 12:51, Mariano Martinez Peck wrote:
Hi folks. I was reading the PBE chapter about reflection where it talks a
little about Method Wrappers. Then, I took a look at TestCoverage implementation.
After that, I took a look at http://www.squeaksource.com/ObjectsAsMethodsWrap
The main difference between both approaches are:
TestCoverage - Just extends from ProtoObject, implement doesNotUnderstand: , run: aSelector with: anArray in: aReceiver , etc - To install and uninstall the wrappers uses methodDictionary at: xxx put: yyy - Just for test coverage.
ObjectAsMethodWrapper - Is more generic, support pre and post closures, and you can subclass and create you own wrapper - To install and uninstall the wrappers it uses Class >> addSelector: self selector withMethod: self
So...what I did ?? I created a TestCoverage but creating a subclass of ObjectAsMethodWrapper called TestCoverageMethodWrapper which just implements a 1 or 2 methods. I mean, I reused the generic ObjectAsMethodWrapper. It seems to work ok.
I did some test running TestCoverage with both implementation and it seems mine (TestCoverageMethodWrapper) is 30% much slower than the original. Trying to understand why, I think it is because the original one uses just methodDictionary at: xxx put: yyy but mine uses Class >> addSelector: self selector withMethod: self. In this last method, there are all the notifications, add to localSelectors...etc
Now...I have two questions:
1) For a generic approach to method wrappers, which of those two ways would you use ? should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ?
2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness.
so...what do you think ?
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Alexandre Bergel -
Lukas Renggli -
Mariano Martinez Peck