+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=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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Johan Fabry jfa...@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
