On Tue, May 15, 2012 at 4:51 PM, Yanni Chiu <yanni@rogers.com> wrote:

On 15/05/12 3:21 AM, Pavel Krivanek wrote:

...

The resultant image is not production-ready because Fuel Package Loader currently doesn't work with changes file.

What does this mean? Is Fuel Package Loader supposed to append corresponding source to the changes file, when compiled methods are loaded via fuel? Shouldn't that be optional?

Hi. First, let me say that FuelPackageLoader is just a baby borning. Nothing is decied completly yet. So far, the best design we have in mind is: 1) The user can export/import packages without source code. This serialization goes into a file. Say we call it yourPackage.fuel. The application can be run, deployed, and even browse decompiled code. Nothing go to .changes. 2) The user has ANOTHER possibility to ALSO serialize source code. That does not mean just source code but also timestamp, class commetns, etc. Then during import, we should do kind of waht monticello does: include source code in the system (.changes or whatever). This would be in a differnt file (also serialized with fuel, and also being a binary fuel) called it for example, yourPackage.source So you can distribute your app with or without source code. Well, that's the plans at least we have with Martin so far. 1) is working quite well (but still there are work to do). 2) is not even started (and that's why Martin is in GSoC). is this clear? This setup reminds me of .SLL files used in VSE (Visual Smalltalk

Enterprise). You could start with a "frozen" base image, and on startup, load all your application code through .SLL "library units". (I can't remember whether or not you could dynamically link/unlink the .SLL packages; I think you could.)

I don't know such details but indeed it looks similar. Cheers -- Mariano http://marianopeck.wordpress.com

Hi, Mariano extended the FLPackage and we now have FuelCommandLineHandler so (with some little hacks) we are able to reach the state where we have a Pharo Kernel image and pass the single fuel file to it and produce fully working Pharo Core image this way. Compiler is not involved. So we are the next step closer to our goal. I created a Jenkins job for the Guillermo's magic :-) https://ci.lille.inria.fr/pharo/view/Seed%20Project/ Cheers, -- Pavel On Tue, May 15, 2012 at 11:41 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

truly excellent Next week we should also sit with guillermo, ben and you so that we see how we can merge for the bootstrap because Guillermo has a 1.3 mb image now.

Stef

On May 15, 2012, at 9:21 AM, Pavel Krivanek wrote:

...

Hi,

we were able to activate the job Pharo Kernel 2.0 Reload by Fuel [1] and related tests [2]. In short, this job takes latest Pharo Kernel image and with the only single script [3] it creates working Pharo Core image. It uses code and some data previously exported by a supporting job [4] [5].

The resultant image is not production-ready because Fuel Package Loader currently doesn't work with changes file.

The next step that should be quite simple is to do the same with an image without Compiler :-)

[1] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%2... [2] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%2... [3] http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Kern... [4] https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/job/Pharo%20Kernel%2... [5] http://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Kern...

Cheers, -- Pavel