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

roberto.minelli at usi.ch roberto.minelli at usi.ch
Tue Oct 29 10:37:34 EDT 2013


Hi Mariano,

On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:

> 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.

Nope, trust me it serialized the whole class.

> Then at materialization it should search that class name in the SmalltalkDictionary and get that.

There is no such class at materialization.

> 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. 

Again, I removed the MethodContext and use a description for them, and everything work as expected.

Cheers,
R


> 
> 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





More information about the Pharo-dev mailing list