[Pharo-dev] No decompile string at all, bad idea?
Mariano Martinez Peck
marianopeck at gmail.com
Wed Nov 6 07:17:19 EST 2013
On Wed, Nov 6, 2013 at 4:57 AM, Marcus Denker <marcus.denker at inria.fr>wrote:
> On 06 Nov 2013, at 08:53, Max Leske <maxleske at gmail.com> wrote:
> > On 06.11.2013, at 08:05, Marcus Denker <marcus.denker at inria.fr> wrote:
> >> On 05 Nov 2013, at 20:37, Mariano Martinez Peck <marianopeck at gmail.com>
> >>> Hi. From what I understand you removed the old Compiler but yet Opal
> does not support compiling. Also, #sourceCode was changed etc...
> >>> That means that there is no way to see the decompiled string of a
> >> Yes.
> >>> Which means I cannot deploy and image without sources and then
> browse/debug/inspect/write pharoDebug.log etc because we don't have even
> the decompile string???
> >> Exactly. But this is just temporary, .sources and .changes will go away
> in Pharo4 and there will be just a .pharo4 image file.
> > By “temporary” do you mean decompilation will come back?
> No, we will have a high-level representation of Methods that replace (from
> the standpoint of reflection) the incomplete bytecode representation,
OK. This is the key from my point of view. I have always seen methods like
2 things: 1) the runtime execution part of a method (you have bytecodes,
you can evaluate it, etc etc) 2) the method as source code (which has the
temps also and accepts all types of things regarding source code
So I am all in of having that high-level representation of methods,
however, I am not sure if I would like to loose a representation of methods
that just means runtime/bytecodes.
> >>> Serializing compiled methods is not fun either since we cannot
> decompile it after...
> >> You can embedd the source into the method before serialising.
> > That means storing redundant information though (if the user is only
> interested in functionality) and that will increase file size, and
> serialization/materalzation time. So it’s not an ideal situation.
> The thing is that we can either not move or move step by step taking
> (sometimes) into account that things are sub-optimal for a little while.
> You can envision the current implementation as a peak on a map: it’s a
> very good local optimum. But *Much* better is possible. Maybne a local
> metaphor: We are in the Gurten now, you can
> not reach the Eiger without going down for a while.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev