<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 19, 2016 at 5:48 PM, H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have started using Fuel and Ma Serializer to store PasteUpMorphs<br>
stored in a project. Actually it is a collection of PastUpMorphs used<br>
as a slide show. I used as well SIXX for some tests.<br>
<br>
It is possible to keep all the serialization packages in the same image.<br>
<br>
Fuel and Ma Serializer work fine so far to save and restore<br>
PasteUpMorphs (with content).<br>
To use SIXX I had to go for a description and then restore from the<br>
description. Interestingly SIXX was about as space efficient as the<br>
other ones if I used compression on the the resulting file. As SISS is<br>
modeled after SIXX the result is probably the same (I did not verify<br>
this).<br>
<br>
For the tests I did so far Ma Serializer was more space efficient. And<br>
the claim is that it spans versions wherase Fuel description<br>
explicitly states that it does not.<br>
<br>
There is a need to agree on some test cases and criteria.<br>
<br>
It is as well worth considering supporting different formats.<br>
<br>
The API to do so is very thin.<br>
<br>
E.g. for the Fuel test to restore the slide collection I just had to do.<br>
<br>
slides := FLMaterializer materializeFromFileNamed:<br>
'/home/user/sq5.1test-Fuel/<wbr>documentation/Kopie_Lit_01.FL'<wbr>.<br>
<br>
slides reverseDo: [:s | s openInWorld]<br>
<br></blockquote><div><br></div><div>You can even add the #openInWorld as a post materialization action which is serialized in a header. That way, the #materialize will automatically evaluate your post actions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--Hannes<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 9/1/16, H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>> wrote:<br>
> To widen the discussion.<br>
><br>
> I think there was no discussion yet if the serialisation format should<br>
><br>
> a) be a binary format<br>
> b) a text format<br>
> c) or that we need both.<br>
><br>
> The prominent use case is saving and loading of projects, see thread<br>
><br>
> 'Vaidotas, Squeak 5.1 saving of Morphic projects is broken'<br>
><br>
> and the SISS thread.<br>
><br>
> Speed of course is an issue.<br>
> But then as well portability between different versions of images.<br>
><br>
> If the question is put as<br>
><br>
> Which serialisation format should succeed image segments then then the<br>
> choice is probably limited to<br>
><br>
> - Fuel<br>
> - Ma Serializer<br>
><br>
><br>
> On 8/31/16, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>> I would, of course, love for Ma Serializer to be considered. Its<br>
>> mature and proven, and has a lot of hooks and I just know the scrutiny<br>
>> and brilliance of this community would benefit it tremendously, and<br>
>> since Magma uses it, would make Magma fundamentally better, too.<br>
>><br>
>> The Fuel hysteria appears to have already garnered everyone's vote<br>
>> before I saw this thread to get myself on the ballot.. I once took<br>
>> at look at trying to use Fuel for Magma, but its much too limited (and<br>
>> not nearly as much faster than Ma Serializer as reported in the Fuel<br>
>> paper). Its is good for UC1) Save an object and UC2) Load an object,<br>
>> but not much else. :(<br>
>><br>
>> On Wed, Aug 31, 2016 at 6:40 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On Aug 31, 2016, at 11:14 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>><br>
>>> wrote:<br>
>>><br>
>>> On Wednesday, 31 August 2016, H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>> We might consider JSON or Fuel might as well options for a format to<br>
>>>> save projects (with ImageMorphs, Browsers, Workspaces, BookMorphs for<br>
>>>> example).<br>
>>><br>
>>><br>
>>> If someone wants to take a serious look I'd suggest Fuel. Being a<br>
>>> replacement for ImageSegments was one of its design goals, if I remember<br>
>>> correctly.<br>
>>><br>
>>><br>
>>> +1. It also has a very performant architecture. It is very similar to<br>
>>> VW's<br>
>>> parcel format which priced to be significantly faster than other formats<br>
>>> at<br>
>>> PPD.<br>
>>><br>
>>><br>
>>> - Bert -<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br></div>
</div></div>