On Mon, Sep 19, 2016 at 5:48 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> I have started using Fuel and Ma Serializer to store PasteUpMorphs
> stored in a project. Actually it is a collection of PastUpMorphs used
> as a slide show. I used as well SIXX for some tests.
>
> It is possible to keep all the serialization packages in the same image.
>
> Fuel and Ma Serializer work fine so far to save and restore
> PasteUpMorphs (with content).
> To use SIXX I had to go for a description and then restore from the
> description. Interestingly SIXX was about as space efficient as the
> other ones if I used compression on the the resulting file. As SISS is
> modeled after SIXX the result is probably the same (I did not verify
> this).
>
> For the tests I did so far Ma Serializer was more space efficient. And
> the claim is that it spans versions wherase Fuel description
> explicitly states that it does not.
>
> There is a need to agree on some test cases and criteria.
>
> It is as well worth considering supporting different formats.
>
> The API to do so is very thin.
>
> E.g. for the Fuel test to restore the slide collection I just had to do.
>
> slides := FLMaterializer materializeFromFileNamed:
> '/home/user/sq5.1test-Fuel/documentation/Kopie_Lit_01.FL'.
>
> slides reverseDo: [:s | s openInWorld]
>
>
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.


> --Hannes
>
>
>
> On 9/1/16, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > To widen the discussion.
> >
> > I think there was no discussion yet if the serialisation format should
> >
> > a) be a binary format
> > b) a text format
> > c) or that we need both.
> >
> > The prominent use case is saving and loading of projects, see thread
> >
> > 'Vaidotas, Squeak 5.1 saving of Morphic projects is broken'
> >
> > and the SISS thread.
> >
> > Speed of course is an issue.
> > But then as well portability between different versions of images.
> >
> > If the question is put as
> >
> > Which serialisation format should succeed image segments then then the
> > choice is probably limited to
> >
> > - Fuel
> > - Ma Serializer
> >
> >
> > On 8/31/16, Chris Muller <asqueaker at gmail.com> wrote:
> >> I would, of course, love for Ma Serializer to be considered.  Its
> >> mature and proven, and has a lot of hooks and I just know the scrutiny
> >> and brilliance of this community would benefit it tremendously, and
> >> since Magma uses it, would make Magma fundamentally better, too.
> >>
> >> The Fuel hysteria appears to have already garnered everyone's vote
> >> before I saw this thread to get myself on the ballot..    I once took
> >> at look at trying to use Fuel for Magma, but its much too limited (and
> >> not nearly as much faster than Ma Serializer as reported in the Fuel
> >> paper).  Its is good for UC1) Save an object and UC2) Load an object,
> >> but not much else.  :(
> >>
> >> On Wed, Aug 31, 2016 at 6:40 AM, Eliot Miranda <eliot.miranda at gmail.com
> >
> >> wrote:
> >>>
> >>>
> >>> On Aug 31, 2016, at 11:14 AM, Bert Freudenberg <bert at freudenbergs.de>
> >>> wrote:
> >>>
> >>> On Wednesday, 31 August 2016, H. Hirzel <hannes.hirzel at gmail.com>
> wrote:
> >>>>
> >>>>
> >>>> We might consider JSON or Fuel might as well options for a format to
> >>>> save projects (with ImageMorphs, Browsers, Workspaces, BookMorphs for
> >>>> example).
> >>>
> >>>
> >>> If someone wants to take a serious look I'd suggest Fuel. Being a
> >>> replacement for ImageSegments was one of its design goals, if I
> remember
> >>> correctly.
> >>>
> >>>
> >>> +1.  It also has a very performant architecture.  It is very similar to
> >>> VW's
> >>> parcel format which priced to be significantly faster than other
> formats
> >>> at
> >>> PPD.
> >>>
> >>>
> >>> - Bert -
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160919/37dbae32/attachment.htm