On Tue, Dec 5, 2017 at 6:39 AM, Andreas Brodbeck <da...@mindclue.ch> wrote:
> Am 28.11.17 um 13:52 schrieb Mariano Martinez Peck: > > On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck <da...@mindclue.ch> > wrote: > > > >> Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck: > >>> Hi Andreas, > >>> > >>> Do you know why method contexts are trying to be serialized? Of course, > >>> probably because of closures. Do you think / know / are aware of > >> closures > >>> as part of your graph? Maybe Sorted Collection? > >>> I am asking because if the only thing is SortedCollection then we can > use > >>> some hook... > >> > >> I have closures in several places in the object graph. These are objects > >> with some pluggable functionality, which I rely on. > >> > > > > > > *OK. The question is then if those closures are "clean" or not.* In other > > words, what's their scope? Do they refer to variables defined outside > the > > closure (in which case you would need the methods contexts / stack) or > are > > they clean in the sense that you could be able to replace them via a > string > > and then compile them again ? > > Some time ago we added a #isClean to BlockClosure. You can test a few of > > your closures to see if this is the case or not. > > > > Btw, I have an application for a client in which we also have closures to > > define some pluggable behavior. But what I do is: > > > > 1) guarantee they are 100% clean (does not go outside of scope) > > 2) aside from the "block" instVar I also add another instVar which is the > > "string" version of it. Then I always implement > > #fuelIgnoredInstanceVariableNames to ignore all those "block" instVars, > yet > > DO NOT ignore the "string" like of those closures. Then, of course, the > > getter of the block instvar does a lazy compilation if the block instVar > is > > nil... > > > > I know you already have your application written, but I am trying to > > explain how I was able to use Fuel for this case... > > Just for the record, here is the solution what I ended up with: > > --- Install Fuel version 1.9.4 for debugging: > > (ConfigurationOfFuel project version: '1.9.4') > load: #(default FuelDebug FuelPreview). > > --- Analyze the fuel serialization of the root object myDatabaseObject > in the Pharo 1.4 image: > > FileStream forceNewFileNamed: 'debug.fuel' do: [:aFile | > FLSerializer newDefault > setDebug; > serialize: myDatabaseObject on: aFile binary]. > > FLDebugSerialization last log inspect. > > > --- In the inspected Fuel-Log, look for the FLCompiledMethodCluster, > which told me in which classes I use BlockClosures which fuel wants to > persist. > > --- Changed my source code and the live objects where I use persisted > BlockClosures to only use "clean" BlockClosure and only fuel-store them > as Strings (Using fuelIgnoredInstanceVariableNames) an recompile them > when the instance is materialized (Using fuelAfterMaterialization), as > suggested by Mariano. > > --- Searched for some few usages of SortedCollection and made sure, that > there is no sortBlock but only the default sort behaviour. > > > So finally I got rid of persisted BlockClosures in the fuel file. That > 1.9.4 Fuel file stored with Pharo 1.4 could then be materialized in > Pharo 6.1. with the same Fuel version 1.9.4 without problems! I'm happy. > > > Awesome! That's exactly what I would have done. -- Mariano http://marianopeck.wordpress.com
