No, we will have a high-level representation of Methods that replace (from the standpoint of reflection) the incomplete bytecode representation,
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?
>
>>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.
>>> 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.
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