[Pharo-project] Fuel, FuelMetalevel, FuelPackageLevel and "code" serialization Re: Stupid question about Fuel
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>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
On 4/15/12 10:41 AM, "Mariano Martinez Peck" <marianopeck@gmail.com> wrote:
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.
Thanks for clarify, and I have Fuel working on Squeak. Not on Cuis, yet
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,
I read all you and Martin made in GSoC. Good luck Very thanks Edgar
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
On Sun, Apr 15, 2012 at 8:40 PM, Francois Stephany < tulipe.moutarde@gmail.com> wrote:
Woaw Mariano, thanks *a lot* for this email !
No problem. I was thinking to add this explanation to the Fuel website....
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/<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://marianopeck.wordpress.com>
-- http://tulipemoutarde.be CA: +1 778 558 3225 BE: +32 65 709 131
-- Mariano http://marianopeck.wordpress.com
participants (3)
-
Edgar J. De Cleene -
Francois Stephany -
Mariano Martinez Peck