[Pharo-dev] New decompiler

Clément Bera bera.clement at gmail.com
Wed Jul 22 10:02:58 EDT 2015


Just some precision because this is really good work.

For the past 3 years at least, the existing Decompiler used in Pharo has
not been able to decompile correctly all the methods of the Pharo image. We
proved it by recompiling all the methods using their decompiled sources:
this operation was crashing the image as some methods were installed but
not correct.

With Kevin's Decompiler, the image can now be recompiled from decompiled
sources, still works fine and all the relevant tests can be run
successfully. Hence all the Pharo methods covered by tests or used by
normal development process are proven to be correctly decompiled.

Therefore, his Decompiler has proven to be better the the existing one.

I also believe that his Decompiler is overall simpler to understand, but
software simplicity and readability is always very subjective and arguable
so I let you guys have your own opinion on that matter.

2015-07-21 19:09 GMT+02:00 Sven Van Caekenberghe <sven at stfx.eu>:

>
> > On 21 Jul 2015, at 17:31, Kevin Lanvin <kevin.lanvin at inria.fr> wrote:
> >
> > Hello everyone !
> >
> > I've been working for 3 months as an intern in RMoD team to develop a
> new decompiler.
> > It has been integated today.
> > It can decompile a whole image.
>
> Great work, impressive.
>
> > The only methods that I can't decompile are Native boost calls because
> they are based on arguments names, and the name of temporaries and
> arguments are lost when a method is compiled.
> > If anyone has an idea about how to fix this, let me know.
> >
> > Thank you !
>
> No, thank you !
>
> > Kevin Lanvin
>
> Sven
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20150722/1c392149/attachment-0002.html>


More information about the Pharo-dev mailing list