On Tue, Dec 6, 2011 at 4:44 PM, Henrik Sperre Johansen
<henrik.s.johansen@veloxit.no> wrote:
On 06.12.2011 16:35, Mariano Martinez Peck wrote:
On Tue, Dec 6, 2011 at 4:30 PM, Henrik
Sperre Johansen
<henrik.s.johansen@veloxit.no>
wrote:
On 06.12.2011 15:55, Mariano Martinez Peck
wrote:
On Mon, Dec 5, 2011 at 4:21 PM, Stefan
Marr
<pharo@stefan-marr.de>
wrote:
Hi:
I got here a Monticello package that does not
properly load using the Metacello configuration. The
image freezes and cmd+. does not pop up a debugger
anymore.
�
Is there a way to
force Monticello/Metacello to fall back on the
included source instead of using the binary snapshot?
(I guess that is going wrong for some reason).
Not very elegant, but you can delete the .bin from the .mcz
file, and it should fall back to importing from sources.
The binary snapshot is only for the definitions. The
source is always get from the .sources.
I'm not sure what you mean, but the source compiled when you
install an MCDefinition, is taken from the .bin if that was
the source of it. (its source instvar is a string, not a
pointer to source location in .sources file).
It seems I was wrong. All I wanted to say is that the final
representation of code (classes,� compiled methods, etc) are
compiled from source code. The snapshot does not include a
"binary represenation of the code". The code is always needed.
What I thought is that it was always from
sources.st
, but you say it can be from the bin as well.
Yup!
OT: Which, as you surely know, is also why a more radical
rethinking/restructuring than the neat experiment Tobias Pape posted
recently is needed if one wanted to take full advantage of a Fuel
monticello format :) Eliminate the compilation step, and mcz loading
would probably be FAST!
Yes. With the experiment of Tobias, the #writeSnapshot: and #loadDefinitions took only 1% of the whole process.....so...
Now, for that radical change you mention, we have started to think a little bit:
1) we need to store the source code anyway. This is because we would need to recompile all CompiledMethod (because of instance variable accessing bytecodes) when the superclass of a class which is in the image changes it shape (hence, instance variables moved their index).� For this purpose, we thought we can easily store the source code in the method trailer and serialize that. The thing is at materialization. What do we once we have materialized?� we keep the sources in teh CM or we put them in the .changes file and we put back a .changes pointer in the trailer???� should a load of a package always store in .changes ?
2) Since we materialize classes without class builder, and this monster does everything together, we need to analyze what has to be done exactly when materializing a package for example: notify class creation/modification, validations (what happens if the class already exist, etc.), etc, etc. This is the most difficult part for us, since understanding what the classbuilder does is complicated....
Our progress is in FuelPackageLoader...
Cheers