2010/6/27 Henrik Sperre Johansen henrik.s.johansen@veloxit.no
On 27.06.2010 20:20, laurent laffont wrote:
On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel alexandre@bergel.euwrote:
The problem is that I don't really know if the method I've changed has
been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use
MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
If you know exactly which compiled method you are interested in, I would wrap it using a plain object that answers to #run:with:in: This is a feature supported which is supported for quite some time by the VM. Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdfhttp://www.iam.unibe.ch/%7Escg/Archive/Papers/Bergel06bRDLPrototyping.pdf, Section 2.2
Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.
Laurent
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people?
best Eliot
Cheers, Henry
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people?
It is quite important. Most prominently it is used in the test runner to calculate test coverage. Also the Method Wrappers of the refactoring engine use it and various research projects (Persephone, Reflectivity, ...) use it.
Lukas
Hi eliot
this was used quite a lot for a lot of infrastructure. For example, persephone put ast that gets recompile on the fly. so this is a nice MOP entry point.
Stef
On Jun 28, 2010, at 1:46 AM, Eliot Miranda wrote:
2010/6/27 Henrik Sperre Johansen henrik.s.johansen@veloxit.no On 27.06.2010 20:20, laurent laffont wrote:
On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel alexandre@bergel.eu wrote:
The problem is that I don't really know if the method I've changed has been actually "hit" by the tests. I just see that tests has been run. I don't know if my method has been called when running the tests.
So I want to detect this.
One way of doing this seems to use MethodContext>>runSimulated:contextAtEachStep:. I've found this looking at MessageTally. Is it the best solution ?
If you know exactly which compiled method you are interested in, I would wrap it using a plain object that answers to #run:with:in: This is a feature supported which is supported for quite some time by the VM. Info on http://www.iam.unibe.ch/~scg/Archive/Papers/Bergel06bRDLPrototyping.pdf , Section 2.2
Thank you, it's cool to learn so sexy stuff :) Should be in Pharo book.
Laurent
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people?
best Eliot
Cheers, Henry
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
On Jun 28, 2010, at 1:46 AM, Eliot Miranda wrote:
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people?
For Research: very. Lots of the experiments we did at SCG used this at least at some stage of implementing the prototype:
-> For the AOSTa experiments I looked at it originally (see http://www.slideshare.net/MarcusDenker/diplom-vortrag-slides) -> Persephone and therefore Reflectivity: http://scg.unibe.ch/research/reflectivity -> ChangeBoxes used it: http://scg.unibe.ch/scgbib?query=Denk07c&display=abstract -> I think ClassBoxes, too -> The most commonly used implementation of MethodWrappers these days uses it (and is *much* simpler than the method-compilation-stub-generating one)
It's a quite nice way to hook into "method execution" without having to resort to compile a stub method. If you need an "in-image" JIT of some sort, it provides a real nice way of doing this purely from the image side (no VM change needed):
http://scg.unibe.ch/scgbib?query=Denk07b&display=abstract
I think Andreas originally suggested ObjectsAsMethods years ago and I then made sure that it was integrated in the VM, as the AOStA experiments showed how powerful this can be for experiments.
AOStA had to use a patched VM, then later persephone could run on a standard VM, which simplified things a lot...
Yes, stub-methods can do anything (and with care can be faster), and having a good code-generation framework simplified actually doing this a lot.... e.g. one can use bytesurgeon and do it on the level of bytecode. (the paper uses MethodWrappers as an example: http://scg.unibe.ch/cgi-bin/scgbib.cgi/abstract=yes?Denk06a) Or just the RB AST (with the code generator), maybe helped by Helvetia's quoting... (more on Helevetia's quoting implementation: http://scg.unibe.ch/research/helvetia/languageboxes)
Nut nevertheless: a MOP for method execution is very valuable not just from an implementation standpoint, even more from a concepual / thinking point of view. Good MOPs provide a better way of *thinking*, they enable exploration.
I always rated this as one of those changes that, while being simple, opened up a lot of space for experiments.
And it showed to me the value of a platform where a change like this is integrated and not ignored.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
+1 on this.
Marcus, we have to talk about Persephone when I'm visiting in Sept!
On 28 Jun 2010, at 13:10, Marcus Denker wrote:
On Jun 28, 2010, at 1:46 AM, Eliot Miranda wrote:
Note: The Cog VM crashes on TestObjectsAsMethods.
Yes. I never tried to get this to work. How important is this to people?
For Research: very. Lots of the experiments we did at SCG used this at least at some stage of implementing the prototype:
-> For the AOSTa experiments I looked at it originally (see http://www.slideshare.net/MarcusDenker/diplom-vortrag-slides) -> Persephone and therefore Reflectivity: http://scg.unibe.ch/research/reflectivity -> ChangeBoxes used it: http://scg.unibe.ch/scgbib?query=Denk07c&display=abstract -> I think ClassBoxes, too -> The most commonly used implementation of MethodWrappers these days uses it (and is *much* simpler than the method-compilation-stub-generating one)
It's a quite nice way to hook into "method execution" without having to resort to compile a stub method. If you need an "in-image" JIT of some sort, it provides a real nice way of doing this purely from the image side (no VM change needed):
http://scg.unibe.ch/scgbib?query=Denk07b&display=abstractI think Andreas originally suggested ObjectsAsMethods years ago and I then made sure that it was integrated in the VM, as the AOStA experiments showed how powerful this can be for experiments.
AOStA had to use a patched VM, then later persephone could run on a standard VM, which simplified things a lot...
Yes, stub-methods can do anything (and with care can be faster), and having a good code-generation framework simplified actually doing this a lot.... e.g. one can use bytesurgeon and do it on the level of bytecode. (the paper uses MethodWrappers as an example: http://scg.unibe.ch/cgi-bin/scgbib.cgi/abstract=yes?Denk06a) Or just the RB AST (with the code generator), maybe helped by Helvetia's quoting... (more on Helevetia's quoting implementation: http://scg.unibe.ch/research/helvetia/languageboxes)
Nut nevertheless: a MOP for method execution is very valuable not just from an implementation standpoint, even more from a concepual / thinking point of view. Good MOPs provide a better way of *thinking*, they enable exploration.
I always rated this as one of those changes that, while being simple, opened up a lot of space for experiments.
And it showed to me the value of a platform where a change like this is integrated and not ignored.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
squeak-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Johan Fabry -
Lukas Renggli -
Marcus Denker -
Stéphane Ducasse