On 17/11/11 1:44 AM, Lukas Renggli wrote:
Just out of curiosity: Why are PUSecurity linked to too many other objects? Is there a bug leaking memory?
I don't think there's a memory leak. My use case here is to export a subtree of a Pier kernel, for import into another Pier kernel. [Aside - not all subtrees can be meaningfully exported, but I'm still discovering the conditions.] In the course of using Fuel (the very first version released), I found that the resulting file was big, and always the same size, no matter what structure was being exported. Looking at the de-serialized structure, I noticed the PUSecurity decoration had pulled in all the users and groups - something I did not want to be imported into the new kernel. This led me to writing a mapping object that contained only the values to be deserialized and used to reconstruct a PRStructure. Thus, the PUSecurity objects were effectively nil'ed out. Now, after upgrading to the latest Fuel, I'm trying to use the substitution feature to accomplish the same. I ended up having to use: serializer analyzer when: [:x | Array = x class and: [x anySatisfy: [:each | PUSecurity = each class ]]] substituteBy: [:x | x reject: [:each | PUSecurity = each class ]] The obvious substitution of nil for the PUSecurity object ends up putting an unexpected nil object in the children Array. I've just noticed that even with the PUSecurity object being striped before serialization, I'm still seeing that the files are big and the same size. It seems that my mapping strategy was leaving off a lot more than just the PUSecurity object.