I would use STON because this is a solid solution.
Stef
On Tue, Nov 28, 2017 at 1:20 PM, Andreas Brodbeck wrote:
> 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. Fro
Sean P. DeNigris wrote
> I got: MetacelloProjectSpecLoadError:…
I then removed the FuelPreview group and got a missing NativeBoost dependecy
(NBExternalHandle)!
-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Andreas Brodbeck-3 wrote
> --- Install Fuel version 1.9.4 for debugging:
> (ConfigurationOfFuel project version: '1.9.4')
> load: #(default FuelDebug FuelPreview).
Hmmm. In Pharo #60510, I got: MetacelloProjectSpecLoadError: No version
found for '1.61' of ConfigurationOfRoassal because: Vers
As this topic has led to a solution for me, here is a more convenient
document:
https://gist.github.com/dassi/9da1aa153635f3df99643149d111021f
Cheers, Andreas
Am 28.11.17 um 11:01 schrieb Andreas Brodbeck:
> Hi all,
>
> I have a long running Seaside/Pharo application which still runs perfect
>
Hi guys,
Let me try to explain the current situation. Fuel does check if a closure
is clean or not. If clean, it avoids serializing the whole stack. The way
it does this is to simply clean the outerContext of the block to NOT have a
sender. See methods CompiledMethod >> fuelAccept:
So..a clean clo
Am 05.12.17 um 17:25 schrieb Sean P. DeNigris:
> Andreas Brodbeck-3 wrote
>> --- Searched for some few usages of SortedCollection and made sure, that
>> there is no sortBlock but only the default sort behaviour.
>
> Can't we have Fuel handle the sort block if it's clean? I feel like we
> discussed
Andreas Brodbeck-3 wrote
> --- Searched for some few usages of SortedCollection and made sure, that
> there is no sortBlock but only the default sort behaviour.
Can't we have Fuel handle the sort block if it's clean? I feel like we
discussed this before but can't recall the conclusion…
-
Ch
On Tue, Dec 5, 2017 at 6:39 AM, Andreas Brodbeck wrote:
> Am 28.11.17 um 13:52 schrieb Mariano Martinez Peck:
> > On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck
> wrote:
> >
> >> Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck:
> >>> Hi Andreas,
> >>>
> >>> Do you know why method contexts
Am 28.11.17 um 13:52 schrieb Mariano Martinez Peck:
> On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck 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.
On Tue, Nov 28, 2017 at 10:20 AM, Sven Van Caekenberghe
wrote:
>
>
> > On 28 Nov 2017, at 13:52, Mariano Martinez Peck
> wrote:
> >
> >
> >
> > On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck
> wrote:
> > Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck:
> > > Hi Andreas,
> > >
> > > Do you
> On 28 Nov 2017, at 13:52, Mariano Martinez Peck wrote:
>
>
>
> On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck 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
On Tue, Nov 28, 2017 at 9:20 AM, Andreas Brodbeck wrote:
> 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
> t
On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck 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 pa
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
Andreas Brodbeck-3 wrote
>> So other options have to be considered.
>
> That probably would be a custom mechanism storing objects in a database
> or fileformat and re-import,…
My two primary workarounds in this scenario are:
1. Try STON
2. Try Fuel in smaller hops (e.g. 1.4 -> 2 -> 4, etc), altho
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
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...
Let
On 28-11-17 11:01, Andreas Brodbeck wrote:
So, basically Fuel can not materialize the instances because the
bytecode hash of all methods have changed, comparing 1.4 to 6.1. My
feeling says that this could be a major problem for my plans to migrate
from Pharo 1.4 to 6.1.
If you export the byteco
Hello Andreas
Unfortunately Fuel is not meant for this kind of use case of migrating
an object model.
So other options have to be considered.
Does your object model have cycles?
Regards
Hannes
On 11/28/17, Andreas Brodbeck wrote:
> Hi all,
>
> I have a long running Seaside/Pharo application w
Hi all,
I have a long running Seaside/Pharo application which still runs perfect
on Pharo 1.4. I want to step into the future and migrate to the newest
Pharo 6.1.
The application's persistence is just in the image, so my plan is to use
Fuel to transfer the objects from Pharo 1.4 to Pharo 6.1.
My
20 matches
Mail list logo
