[Pharo-dev] No decompile string at all, bad idea?

Max Leske maxleske at gmail.com
Wed Nov 6 03:09:18 EST 2013


On 06.11.2013, at 08:57, 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> 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,

Ok, good to know.

> 
>>> 
>>>> 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.

I agree that that’s sometimes necessary.

> 
> 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.

Haha :) nice!

That means we’ll have to figure something out for Fuel to work with not installed compiled methods in 3.0. Thanks for the explanation.

> 
> 	Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131106/b8a37df8/attachment-0002.html>


More information about the Pharo-dev mailing list