No decompile string at all, bad idea?
Locked
No decompile string at all, bad idea?
 
|
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?
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??? Serializing compiled methods is not fun either since we cannot decompile it after...
|
Re: No decompile string at all, bad idea?
|
|
On 05 Nov 2013, at 20:37, Mariano Martinez Peck <[hidden email]> 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. > Serializing compiled methods is not fun either since we cannot decompile it after... > You can embedd the source into the method before serialising. Marcus |
|
|
On 06.11.2013, at 08:05, Marcus Denker <[hidden email]> wrote: > > On 05 Nov 2013, at 20:37, Mariano Martinez Peck <[hidden email]> 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? > >> 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. > > Marcus > > > > |
Re: No decompile string at all, bad idea?
|
|
On 06 Nov 2013, at 08:53, Max Leske <[hidden email]> wrote: > > On 06.11.2013, at 08:05, Marcus Denker <[hidden email]> wrote: > >> >> On 05 Nov 2013, at 20:37, Mariano Martinez Peck <[hidden email]> 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? > >> >>> 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 |
|
|
On 06.11.2013, at 08:57, Marcus Denker <[hidden email]> wrote:
Ok, good to know.
I agree that that’s sometimes necessary.
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.
|
Re: No decompile string at all, bad idea?
|
|
In reply to this post by Marcus Denker-4
On Wed, Nov 6, 2013 at 4:57 AM, Marcus Denker <[hidden email]> wrote:
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 management).
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.
Mariano http://marianopeck.wordpress.com |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |