Re: [Pharo-project] Xtreme Pharo hacker needed :)

>
>
> 2010/6/27 Henrik Sperre Johansen <[hidden email]>
> On 27.06.2010 20:20, laurent laffont wrote:
>>
>> On Sun, Jun 27, 2010 at 7:11 PM, Alexandre Bergel <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project