[Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

Mariano Martinez Peck marianopeck at gmail.com
Tue Oct 29 08:35:28 EDT 2013


On Tue, Oct 29, 2013 at 6:53 AM, roberto.minelli at usi.ch <
roberto.minelli at usi.ch> wrote:

> Guys,
>
> Fuel it’s perfect, it was–of course–my fault.
>
> When I considered everything and I moved away from Ring definition which
> caused me lot of troubles I forgot to consider MethodContext objects, which
> in turn points to CompiledMethod which point to classes. Thus Fuel
> serialize all this crap (including classes) and in the materialization
> phase I got clearly a FLClassNotFound.
>
>

Even in this case, Fuel should have not serialized classes. Instead, if a
class was found in the graph, Fuel should have serialized a "mock" object
that just contains the class name and a few other things, but not the whole
class. Then at materialization it should search that class name in the
SmalltalkDictionary and get that.
So...it could still happen that the class name you stored during
serialization is NOT present in materialization. But Fuel should not have
serialized the class itself but rather this mock object.

Cheers,


> Thanks a lot for the support,
> Roby
>
> On Oct 29, 2013, at 8:03 AM, roberto.minelli at usi.ch wrote:
>
> > I’ll look at the doc… However if some of you is online in Skype we can
> have a chat…
> >
> > Cheers and thanks for help,
> > Roby
> >
> > On Oct 28, 2013, at 11:45 PM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
> >
> >> Indeed, I think I agree with Max. You can also use the substitute
> feature and replace the instVars you don't want with nil or something...See
> the doc link Martin sent.
> >>
> >>
> >> On Mon, Oct 28, 2013 at 7:00 PM, Max Leske <maxleske at gmail.com> wrote:
> >> In my opinion the #fuelAccept: for the meta description object should
> be overridden and there the behaviour for problematic references should be
> defined.
> >>
> >> Roberto, what references does your meta object hold on to?
> >>
> >> Max
> >>
> >>
> >> On 28.10.2013, at 22:16, Martin Dias <tinchodias at gmail.com> wrote:
> >>
> >>>
> >>>
> >>>
> >>> On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli at usi.ch <
> roberto.minelli at usi.ch> wrote:
> >>> The idea is that I have an object (a session) which has meta data
> (time, duration, author) and some other object inside.
> >>>
> >>> I want that Fuel serializes just that object and not pointes to other
> object, globals and what not.
> >>>
> >>> This causes me a lot of troubles, moreover it makes the fuel file
> bigger than the optimum…
> >>>
> >>> Still there is something that I don't understand in your problem. If
> you just prune the graph, what your objects represent (conceptually) can be
> lost. Did you pick one of your problematic "session objects" are explored
> it until find how the unwanted block closures are referenced? I mean, fuel
> doesn't invent the unwanted closures magically, you are saying to fuel to
> serialize the graph with the unwanted objects already there.
> >>>
> >>>
> >>> Cheers,
> >>> R
> >>>
> >>>
> >>> On Oct 28, 2013, at 4:57 PM, Martin Dias <tinchodias at gmail.com> wrote:
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli at usi.ch <
> roberto.minelli at usi.ch> wrote:
> >>>> Thanks,
> >>>>
> >>>> On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias at gmail.com>
> wrote:
> >>>>
> >>>>> Currently there is no such option.
> >>>>
> >>>> Maybe it is something which is needed, what do you think?
> >>>>
> >>>> The idea is that, if you serialize:
> >>>>
> >>>> a -> b -> c
> >>>>
> >>>> fuel actually would encode:
> >>>>
> >>>> a -> b -> nil
> >>>>
> >>>>
> >>>> that?
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> Mariano
> >> http://marianopeck.wordpress.com
> >
> >
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131029/c7131262/attachment-0002.html>


More information about the Pharo-dev mailing list