[Vm-dev] [squeak-dev] re: Image Segment semantics and weakness

Chris Muller asqueaker at gmail.com
Thu Oct 23 16:43:11 UTC 2014

>> I would also like to put in a good word for Fuel. It is well designed, well
>> documented, and well supported on Squeak and Pharo. Very high quality work.
>> I use Fuel in RemoteTask (in package CommandShell) for inter-image communication.
>> ReferenceStream also works, and both are supported in RemoteTask. But if you
>> want to have a serializer that you can read and understand, I'd say that Fuel
>> is hard to beat.
>> I am not advocating anything with respect to image segments, project saving,
>> and so forth, I'm just saying that Fuel is a very good thing. It works well
>> in Squeak, and I suspect that many folks may not be aware of this.
> Oh I agree.  If only ImageSegments weren't used... :-).  We use an early version of Fuel at Cadence which is essential to our system.  We haven't upgraded as it "just works".

I'd just like to remind everyone, there is another stand-alone
serializer available for Squeak called "Ma-Object-Serializer".  It was
developed from the ground up for _Squeak_ -- meaning, it already
supports all the same Squeak-specific preserialization and
postmaterialization pickling/unpickling behaviors, like for Project,
etc. which used by ReferenceStream.

There is nothing more that I would *love* than for interest from my
fellow Squeakers to lead to significant improvements in this
serializer from trying to incorporate it into your applications.  I
think there is some low-hanging fruit (like the nascent
#addNewElement:!) to be had simply by everyone's different development
views and experience.  Such improvements would be directly inherited
by Magma!

I looked at trying to incorporate Fuel as the serializer for Magma, to
take advantage of its purported speed.  But one of the very first
things I found was the benchmarks for "the Magma serializer" in the
Fuel paper were totally bogus.  I had asked Mariano to separate out
initialization from serialization and materialization, but since he
didn't, the numbers reported are a tiny fraction of their actual

I came to realize that Fuel is really targeted at just two primary
use-cases:  1) saving a complete-graph and 2) loading a
complete-graph.  But Ma-Object-Serializer has the ability to
serialize/materialize *partial* graphs by letting the user specify a
TraversalStrategy, which is essential for Magma.  Unfortunately, Fuel
cannot do this.

The other innovation of Ma-Object-Serializer is its first-class access
to the object-graph **in its serialized state** in the same ways
(partial or complete) like when they were Smalltalk objects.

More information about the Vm-dev mailing list