[Pharo-project] Monticello enhancing
Dear all, afte Fuel being available for both Squeak and Pharo, I experimented a little bit. So, I put a new snapshot.fuel beside the snapshot.bin in the mcz zips (same for patch.* in mcd). But to make it easier in the future to experiment with things, I included a small facility to extend serializers/materializers or similar things more easily. How is it done? Example: new serializer in MCZ files: After my patch, include MCMczWriter class>>serializerMine ^ [:writer :snapshot | writer writeSnapshotAsMyFormat: snapshot] and MCMczWriter>>writeSnapshotAsMyFormat: snapshot self addString: (self doSomeConversion: aSnapshot) at: 'snapshot.myformat'. as Extension methods in MCMczWriter, and execute MCMczWriter populateSerializers. Now, a new file member is added to every new mcz file. As an example, I have done such thing for Fuel. Don't worry, it just uses the default behavior if Fuel is not present in either the image or the mcz-file. Best, -Tobias PS: for Squeak, see Inbox Monticello-topa.491, And I also have an MCD attached that should help using the code elsewhere.
On Fri, Dec 2, 2011 at 4:54 PM, Tobias Pape <Das.Linux@gmx.de> wrote:
Dear all,
afte Fuel being available for both Squeak and Pharo, I experimented a little bit.
Be aware that Fuel is "partially" supported in Squeak. It was just a first try Martin and I did. The idea is to have at least the "Core" working. Previously, the Core included also all the code to be able to completely serialize classes, traits and compiled methods. Most of the times this is not used, since most users want to serialize the class/trait/method as "global", that is, we just serialize its name and then search it at materialization time. In the latest version of Fuel (1.8, which is not yet released), such behavior was moved to a separate package called FuelMetalevel. That package, does NOT work in Squeak since Class and Trait are different in Squeak than Pharo. So, you are NOT able to serialize classes/traits completely. Since that package is not supported, FuelPackageLoader is not supported either. So....just the plain/core serialization works so far in Squeak. Of course we welcome someone to push with the other packages.
So, I put a new snapshot.fuel beside the snapshot.bin in the mcz zips (same for patch.* in mcd).
I am surprised that it worked since (as said) full serialization of classes/methods is not working in Squeak. I thought that Monticello serialize that in that snapshot.bin but it seems I am wrong. So...what is exactly serialized in that snapshot.bin ?
But to make it easier in the future to experiment with things, I included a small facility to extend serializers/materializers or similar things more easily. How is it done?
Example: new serializer in MCZ files: After my patch, include
MCMczWriter class>>serializerMine
^ [:writer :snapshot | writer writeSnapshotAsMyFormat: snapshot]
and
MCMczWriter>>writeSnapshotAsMyFormat: snapshot
self addString: (self doSomeConversion: aSnapshot) at: 'snapshot.myformat'.
as Extension methods in MCMczWriter, and execute
MCMczWriter populateSerializers.
Now, a new file member is added to every new mcz file.
Excellent.
As an example, I have done such thing for Fuel. Don't worry, it just uses the default behavior if Fuel is not present in either the image or the mcz-file.
So, is it working? can I commit/load with Monticello using the Fuel instead of DataStream? Did you notice performance improvement in using Fuel rather than DataStream? I guess (well, once Levente showed something) it is a small percentage in the overall process of Monticello, so I don't expect that much improvement in the whole action of saving/commiting. Thanks
Best, -Tobias
PS: for Squeak, see Inbox Monticello-topa.491, And I also have an MCD attached that should help using the code elsewhere.
-- Mariano http://marianopeck.wordpress.com
Thanks tobias This is cool to have that! With your experiment are loading MC definitions using fuel? Stef On Dec 2, 2011, at 4:54 PM, Tobias Pape wrote:
Dear all,
afte Fuel being available for both Squeak and Pharo, I experimented a little bit.
So, I put a new snapshot.fuel beside the snapshot.bin in the mcz zips (same for patch.* in mcd).
But to make it easier in the future to experiment with things, I included a small facility to extend serializers/materializers or similar things more easily. How is it done?
Example: new serializer in MCZ files: After my patch, include
MCMczWriter class>>serializerMine
^ [:writer :snapshot | writer writeSnapshotAsMyFormat: snapshot]
and
MCMczWriter>>writeSnapshotAsMyFormat: snapshot
self addString: (self doSomeConversion: aSnapshot) at: 'snapshot.myformat'.
as Extension methods in MCMczWriter, and execute
MCMczWriter populateSerializers.
Now, a new file member is added to every new mcz file.
As an example, I have done such thing for Fuel. Don't worry, it just uses the default behavior if Fuel is not present in either the image or the mcz-file.
Best, -Tobias
PS: for Squeak, see Inbox Monticello-topa.491, And I also have an MCD attached that should help using the code elsewhere.
<Monticello-topa.491.mcz><Monticello-topa.491(cmm.489).mcd><FuelMonticello-topa.1.mcz>
On Sat, Dec 3, 2011 at 12:23 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Thanks tobias This is cool to have that! With your experiment are loading MC definitions using fuel?
yes, loading and writing. Basically, for writing, for example, it is to change #writeSnapshot: or #serializeInBinary: to use Fuel instead of DataStream. For loading, #loadDefinitions Cheers
Stef
On Dec 2, 2011, at 4:54 PM, Tobias Pape wrote:
Dear all,
afte Fuel being available for both Squeak and Pharo, I experimented a little bit.
So, I put a new snapshot.fuel beside the snapshot.bin in the mcz zips (same for patch.* in mcd).
But to make it easier in the future to experiment with things, I included a small facility to extend serializers/materializers or similar things more easily. How is it done?
Example: new serializer in MCZ files: After my patch, include
MCMczWriter class>>serializerMine
^ [:writer :snapshot | writer writeSnapshotAsMyFormat: snapshot]
and
MCMczWriter>>writeSnapshotAsMyFormat: snapshot
self addString: (self doSomeConversion: aSnapshot) at: 'snapshot.myformat'.
as Extension methods in MCMczWriter, and execute
MCMczWriter populateSerializers.
Now, a new file member is added to every new mcz file.
As an example, I have done such thing for Fuel. Don't worry, it just uses the default behavior if Fuel is not present in either the image or the mcz-file.
Best, -Tobias
PS: for Squeak, see Inbox Monticello-topa.491, And I also have an MCD attached that should help using the code elsewhere.
<Monticello-topa.491.mcz><Monticello-topa.491(cmm.489).mcd><FuelMonticello-topa.1.mcz>
-- Mariano http://marianopeck.wordpress.com
Am 2011-12-03 um 14:34 schrieb Mariano Martinez Peck:
On Sat, Dec 3, 2011 at 12:23 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Thanks tobias This is cool to have that! With your experiment are loading MC definitions using fuel?
yes, loading and writing. Basically, for writing, for example, it is to change #writeSnapshot: or #serializeInBinary: to use Fuel instead of DataStream. For loading, #loadDefinitions
No. that is the point. you add a loderFuel to the class side of MCMc{d,z}Reader that returns an association of priority -> oneargblock. My proposal is about experimenting with the MC stuff _without_ changing the present logic, but augmenting them. See the FuelMonticello-topa.1.mcz for an example. (note that this mcz already contains a snapshot.fuel ;) ) best -Tobias
On Sat, Dec 3, 2011 at 3:46 PM, Tobias Pape <Das.Linux@gmx.de> wrote:
Am 2011-12-03 um 14:34 schrieb Mariano Martinez Peck:
On Sat, Dec 3, 2011 at 12:23 AM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
Thanks tobias This is cool to have that! With your experiment are loading MC definitions using fuel?
yes, loading and writing. Basically, for writing, for example, it is to change #writeSnapshot: or #serializeInBinary: to use Fuel instead of DataStream. For loading, #loadDefinitions
No. that is the point. you add a loderFuel to the class side of MCMc{d,z}Reader that returns an association of priority -> oneargblock.
My proposal is about experimenting with the MC stuff _without_ changing the present logic, but augmenting them.
See the FuelMonticello-topa.1.mcz for an example. (note that this mcz already contains a snapshot.fuel ;) )
Yes, yes, yes, I saw that :) I just wanted to point to Stef where MC was doing such magic. I know you didn't modify that directly with instead add different loaders. I saw your code :)
best -Tobias
-- Mariano http://marianopeck.wordpress.com
Am 2011-12-03 um 15:52 schrieb Mariano Martinez Peck:
On Sat, Dec 3, 2011 at 3:46 PM, Tobias Pape <Das.Linux@gmx.de> wrote:
Am 2011-12-03 um 14:34 schrieb Mariano Martinez Peck:
On Sat, Dec 3, 2011 at 12:23 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Thanks tobias This is cool to have that! With your experiment are loading MC definitions using fuel?
yes, loading and writing. Basically, for writing, for example, it is to change #writeSnapshot: or #serializeInBinary: to use Fuel instead of DataStream. For loading, #loadDefinitions
No. that is the point. you add a loderFuel to the class side of MCMc{d,z}Reader that returns an association of priority -> oneargblock.
My proposal is about experimenting with the MC stuff _without_ changing the present logic, but augmenting them.
See the FuelMonticello-topa.1.mcz for an example. (note that this mcz already contains a snapshot.fuel ;) )
Yes, yes, yes, I saw that :) I just wanted to point to Stef where MC was doing such magic. I know you didn't modify that directly with instead add different loaders. I saw your code :)
Ah, ok. nevermind. Best -Tobias
participants (3)
-
Mariano Martinez Peck -
Stéphane Ducasse -
Tobias Pape