[Fuel] How to tell Fuel *not* to encode references?
Hi, Iâm struggling with Fuel and I probably discovered my problem. When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max. I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so? Cheers and thanks for the help, Roberto
I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method. So I think in some way your object is referencing that problematic block closure. Maybe it can give you a clue if you put a halt in FLAnalysis>>trace: Maybe a "self haltIf: anObject isClosure" HTH, MartÃn On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Hi,
Iâm struggling with Fuel and I probably discovered my problem.
When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max.
I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so?
Cheers and thanks for the help, Roberto
Hi Martin, Thanks for the answer, I have another question. Is there any way to tell Fuel to serialize only the object with its instance variables and thatâs it? I donât want Fuel to traverse any reference, just the object with its fields. Thanks, Roberto On Oct 28, 2013, at 4:00 PM, Martin Dias <tinchodias@gmail.com> wrote:
I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method.
So I think in some way your object is referencing that problematic block closure.
Maybe it can give you a clue if you put a halt in FLAnalysis>>trace:
Maybe a "self haltIf: anObject isClosure"
HTH, MartÃn
On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Hi,
Iâm struggling with Fuel and I probably discovered my problem.
When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max.
I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so?
Cheers and thanks for the help, Roberto
Currently there is no such option. You might want to customize how your "development session" objects are encoded. Like in DateAndTime... you can look at these methods: #fuelAccept: #serializeOn: #materializeFrom: (at class-side) Or you can tell fuel to ignore some instance variables, if you override #fuelIgnoredInstanceVariableNames at class-side. Both alternatives are covered in the documentation http://rmod.lille.inria.fr/web/pier/software/Fuel (which is sadly down in this moment, but will be up again soon) MartÃn On Mon, Oct 28, 2013 at 4:10 PM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Hi Martin,
Thanks for the answer, I have another question. Is there any way to tell Fuel to serialize only the object with its instance variables and thatâs it?
I donât want Fuel to traverse any reference, just the object with its fields.
Thanks, Roberto
On Oct 28, 2013, at 4:00 PM, Martin Dias <tinchodias@gmail.com> wrote:
I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method.
So I think in some way your object is referencing that problematic block closure.
Maybe it can give you a clue if you put a halt in FLAnalysis>>trace:
Maybe a "self haltIf: anObject isClosure"
HTH, MartÃn
On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote: Hi,
Iâm struggling with Fuel and I probably discovered my problem.
When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max.
I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so?
Cheers and thanks for the help, Roberto
Thanks, On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@gmail.com> wrote:
Currently there is no such option.
Maybe it is something which is needed, what do you think?
You might want to customize how your "development session" objects are encoded. Like in DateAndTime... you can look at these methods:
#fuelAccept: #serializeOn: #materializeFrom: (at class-side)
Or you can tell fuel to ignore some instance variables, if you override #fuelIgnoredInstanceVariableNames at class-side.
Both alternatives are covered in the documentation
http://rmod.lille.inria.fr/web/pier/software/Fuel
(which is sadly down in this moment, but will be up again soon)
MartÃn
On Mon, Oct 28, 2013 at 4:10 PM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Hi Martin,
Thanks for the answer, I have another question. Is there any way to tell Fuel to serialize only the object with its instance variables and thatâs it?
I donât want Fuel to traverse any reference, just the object with its fields.
Thanks, Roberto
On Oct 28, 2013, at 4:00 PM, Martin Dias <tinchodias@gmail.com> wrote:
I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method.
So I think in some way your object is referencing that problematic block closure.
Maybe it can give you a clue if you put a halt in FLAnalysis>>trace:
Maybe a "self haltIf: anObject isClosure"
HTH, MartÃn
On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Hi,
Iâm struggling with Fuel and I probably discovered my problem.
When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max.
I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so?
Cheers and thanks for the help, Roberto
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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?
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⦠Cheers, R On Oct 28, 2013, at 4:57 PM, Martin Dias <tinchodias@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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?
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch < roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <
roberto.minelli@usi.ch> wrote:
Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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?
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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch <roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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?
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@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch < roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <
roberto.minelli@usi.ch> wrote:
Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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
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@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@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch <roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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
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. Thanks a lot for the support, Roby On Oct 29, 2013, at 8:03 AM, roberto.minelli@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@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@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch <roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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
On Tue, Oct 29, 2013 at 6:53 AM, roberto.minelli@usi.ch < roberto.minelli@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@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@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@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch <
roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <
roberto.minelli@usi.ch> wrote:
Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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
Hi Mariano, On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Oct 29, 2013 at 6:53 AM, roberto.minelli@usi.ch <roberto.minelli@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@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@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@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch <roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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
On Tue, Oct 29, 2013 at 11:37 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Hi Mariano,
On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Oct 29, 2013 at 6:53 AM, roberto.minelli@usi.ch < roberto.minelli@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.
So that is a bug. Do you have a reproducible test case?
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@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@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@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch <
roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <
roberto.minelli@usi.ch> wrote:
Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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
-- Mariano http://marianopeck.wordpress.com
On Oct 29, 2013, at 3:41 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Oct 29, 2013 at 11:37 AM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Hi Mariano,
On Oct 29, 2013, at 1:35 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, Oct 29, 2013 at 6:53 AM, roberto.minelli@usi.ch <roberto.minelli@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.
So that is a bug. Do you have a reproducible test case?
Iâll try to isolate the problem and provide a TC tomorrow
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@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@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@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli@usi.ch <roberto.minelli@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@gmail.com> wrote:
On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli@usi.ch <roberto.minelli@usi.ch> wrote: Thanks,
On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias@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
-- Mariano http://marianopeck.wordpress.com
participants (4)
-
Mariano Martinez Peck -
Martin Dias -
Max Leske -
roberto.minelli＠usi.ch