Fuel transfer from Pharo 1.4 to Pharo 6.1

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.

Just for my better understanding, I like to ask: The FLMethodChanged
errors will show up for *EVERY* method of a materialized object (Since
the bytecodesHash changed for every method) or just those methods which
involve fuel-persisted MethodContexts? (Sorry, if the question is
stupid, but I am rather new to Fuel internals)

Cheers,

Andreas

--
Andreas Brodbeck
www.mindclue.ch

Am 28.11.17 um 11:13 schrieb H. Hirzel:
> Hello Andreas
>
> Unfortunately Fuel is not meant for this kind of use case of migrating
> an object model.

That's sad to hear. From 1.4 to 6.1 is a big step, I agree, but I really
thought that Fuel can be considered as a good "transport vehicle" at
least for small steps like from Pharo 5 to 6.

>
> So other options have to be considered.

That probably would be a custom mechanism storing objects in a database
or fileformat and re-import, I think. Lots of work and very error prone.
But maybe the only way unfortunately ...

SIXX would be an option you think?

>
> Does your object model have cycles?

Yes.


Regards,

Andreas

--
Andreas Brodbeck
www.mindclue.ch

> On 28 Nov 2017, at 13:52, Mariano Martinez Peck <[hidden email]> wrote:
>
>
>
> On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck <[hidden email]> 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...

Ah, that's cheating ;-)

But totally acceptable with clean blocks.

So,

[ :x :y | x < y ] isClean.

  => true

[ :x :y | x < y ] sourceNode formattedCode.

  => '[ :x :y | x < y ]'

But

Compiler evaluate: '[ :x :y | x < y ]'.

  => [ :arg1 :arg2 | arg1 < arg2 ]

So the argument names get lost, which seems like a pity. How are you doing it ? Can it be done differently ?

> 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 my better understanding, I like to ask: The FLMethodChanged
> errors will show up for *EVERY* method of a materialized object (Since
> the bytecodesHash changed for every method) or just those methods which
> involve fuel-persisted MethodContexts? (Sorry, if the question is
> stupid, but I am rather new to Fuel internals)
>
>
> As far as I can remember, the latter.
>
>
>
>
> Cheers,
> Andreas
>
> --
> Andreas Brodbeck
> www.mindclue.ch
>
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com

Am 28.11.17 um 13:52 schrieb Mariano Martinez Peck:
> On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck <[hidden email]> 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.