On 06 Nov 2013, at 08:53, Max Leske <[email protected]> wrote:
>
> On 06.11.2013, at 08:05, Marcus Denker <[email protected]> wrote:
>
>>
>> On 05 Nov 2013, at 20:37, Mariano Martinez Peck <[email protected]>
>> 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
