Woaw Mariano, thanks *a lot* for this email !

On 15/04/12 06:41, Mariano Martinez Peck wrote:

Hi Edgar. The question is not stupid at all. I would like to clarify a
little bit the packages involved in Fuel and how they are related to
"code" serialization. Then I answer your question.

_Fuel package_: �This is the "core" of Fuel. It works as a general

purpose serializer and all it does is serialize and materialize. If the
graph you provide to serialize contains classes, they will all be
considered as "global". That is, in serialization we just store its
global name and during materialization we read the global name and we
search it in Smalltalk globals. Therefore, classes have to be present in
the image you are materializing. 99% of the users will be using this
package.

_FuelMetalevel package_: This is an extension to Fuel package and what

it does is to add the knowledge of how to correctly serialize and
materialize classes, traits, method dictionaries, compiled methods etc.
It knows how to serialize a class and correctly materialize it. However,
FuelMetalevel just do that: serialize and materialize. Nothing else. It
does not send class side #initialize, it does not notify the system, it

does not add the class to Smalltalk globals, no nothing. _

FuelPackageLoader package_: This was a quick prototype (proof of

concept) we did with Martin mostly to see whether we were able to
serialize packages with Fuel and to see if in the future we could
replace or integrate with Monticello. Martin could finish the package
just in time so that I could show in ESUG last year how we could load
full seaside in 15 seconds. �Anyway, this packages uses FuelMetalevel
(and therefore Fuel) and what it does is to ADD the class into the
system. That means sendind class side #initialize, add classes to
Smalltalk globals, sends notifications, etc, etc, etc. �As said, this
package was a prototype, it still have lot of work to do and that's why
we proposed it for GSoC.

What Pavel used, and what you asked, is about FuelPackageLoader. So,
first we justo to load such package when using ConfigurationOfFuel. You
should load the group 'PackageLoaderWithTests' in Pharo. Notice that nor
FuelMetalevel nor FuelPackageLoader works on Squeak nor Quis. At least,
not by default. This is because in Pharo classes have traits, which were
removed in Squeak.

Regarding your question of how to serialize a package with
FuelPackageLoader, it is something like this:

FileStream forceNewFileNamed: 'Morphic.fuel' do: [:aStream |
� � � �aStream binary.
FLPackageStore new storeOn: aStream packageNamed: 'Morphic'.].


So far we do not have the granularity of claases in FuelPackageLoader,
that is, the granularity is packages.

Cheers,


On Sun, Apr 15, 2012 at 1:24 PM, Marcus Denker <marcus.denker@inria.fr

<mailto:marcus.denker@inria.fr>> wrote:


� �On Apr 15, 2012, at 1:20 PM, Edgar J. De Cleene wrote:

� � > Mariano, Martin, Pavel
� � >
� � >> For example, a class can be considered either a global or a
� �regular object. In
� � >> the former case, it will be encoded just its name; in the latter
� �case, the
� � >> class will be encoded in detail, with its method dictionary, etc.
� � >
� � > How you do this ?
� � >> the class will be encoded in detail, with its method dictionary,
� �etc.
� � >
� � > I export most of 1.4 OneClick classes in
� �http://squeakros.org/Pharo%201dot4/
� � > as cs.gz, like to have .fuel for load classes back in target
� �image with no
� � > compiler.

� �Of course that can not work. .cs is source code, you of course need
� �a compiler
� �(if Fuel could load cs.gz, it *would be* a compiler).

� �What you need to do is to serialize the *Objects* that are code
� �(Classes, MethodDictioaries,
� �CompiledMethods) using Fuel. Then the result can be loaded back
� �using Fuel.

� � � � � �Marcus

� �--
� �Marcus Denker -- http://marcusdenker.de





--
Mariano
http://marianopeck.wordpress.com

--
http://tulipemoutarde.be
CA: +1 778 558 3225
BE: +32 65 709 131