On 06 Nov 2013, at 08:53, Max Leske <maxleske@gmail.com> wrote:
On 06.11.2013, at 08:05, Marcus Denker <marcus.denker@inria.fr> wrote:
On 05 Nov 2013, at 20:37, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
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 method?
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,
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. Marcus