On Tue, Oct 13, 2015 at 10:33 PM, Robert Withers <[email protected]
> wrote:

> Hi Mariano,
>
> This presents me with a big challenge, then. I read the docs and explored
> the code and the only other aspect not mentioned, beyond instance creation
> (#fuelNew #fuelNew:) and postMaterialization (#fuelAfterMaterialization),
> is migrations. However, migration only allows for instanceVar mappings, no
> code blocks.
>
>
What do you mean that migrations only allows instVar mappings , and no code
blocks? I mean, what do you mean by code blocks?
We also support class renames. This is here:
http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration?_s=Pvs4DYqPRjfEy8sg&_k=X6ltJu7FDSxumm4X&_n&22

Which kind of migration example you have in mind that would not be
supported? An example would help.

#fuelAccept: is a serialization side method.
>
> If Fuel supports substitution on serialization, I don't understand why no
> substitution support on materialization.
>

There was a reason, which I cannot remember completely. Maybe Martin or Max
can remember.


>
> I am definitely going to use the world-class Fuel binary serialization
> system. However, I find myself needing to extend Fuel to support
> substitution on materialization. Perhaps the solution is a custom decoder.
>

I have made custom clusters for example for my Ghost proxies of Marea
system. It was a perfect example of how I could extent Fuel besides the
common hooks. Fuel provides many places for extending , like clusters,
analyzer,  etc


>
> No, a bit more. It looks like I need a new
> FLSubstitutePointerObjectCluster, write them on serialization with the
> substitute, then do unsubstitution on materialization, since the cluster
> controls materialization and not the decoder.
>
> Does this approach seem sound to you, from a you know architecture and
> design approach?
>

There was an issue. Hope other can remember. If not, I will try to explan
what I remember tomorrow.



>
> thanks so much ^^
> Robert
>
> On 10/13/2015 04:49 PM, Mariano Martinez Peck wrote:
>
>> No, unfortunately, as far as I can remember, we do not have that. There
>> are another hooks you may use but only in certain scenarios (#fuelNew,
>> #fuelAfterMaterialization, global sends, etc). But everything is listed
>> in
>>
>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/CustomizingGraph
>>   so if you didn't find anything of help in there there are chances
>> there isn't anything.
>>
>> Cheers,
>>
>> On Tue, Oct 13, 2015 at 5:30 PM, Robert Withers
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>     Yes, I meant dynamic substitution on materialization, to use the
>>     correct terminology.
>>
>>     thanks,
>>     Robert
>>
>>
>>     On 10/13/2015 11:40 AM, Max Leske wrote:
>>
>>
>>             On 13 Oct 2015, at 17:16, Robert Withers
>>             <[email protected]
>>             <mailto:[email protected]>> wrote:
>>
>>             Every extra source helps, thank you. I see how to do
>>             non-stream substitutions on materializations, but the
>>             documentation did not indicate a way to do non-stream
>>             substitutions on serialization. Is it possible?
>>
>>
>>         I don’t understand what you mean by “non-stream”. Could you give
>>         an example?
>>
>>
>>             thanks,
>>             Robert
>>
>>             On 10/13/2015 09:00 AM, Mariano Martinez Peck wrote:
>>
>>                 Hi Robert,
>>
>>                 As for the documentation, you have LOTS of tests, you
>>                 have the chapter
>>                 Torsten pasted, you have this documentation:
>>                 http://rmod.inria.fr/web/software/Fuel
>>
>>                 But also, as for internals, there is a journal paper we
>>                 wrote:
>>
>> http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf
>>
>>                 Let us know how it goes,
>>
>>
>>                 On Tue, Oct 13, 2015 at 6:00 AM, Torsten Bergmann
>>                 <[email protected] <mailto:[email protected]>
>>                 <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>
>>                      Hi Robert,
>>
>>                      Also checkout the chapter on Fuel in Pharo
>>                 Enterprise book:
>>
>>
>> https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/EnterprisePharo-A4.pdf
>>
>>                      Bye
>>                      Torsten
>>
>>                       > Gesendet: Dienstag, 13. Oktober 2015 um 09:44 Uhr
>>                       > Von: "Robert Withers"
>>                 <[email protected]
>>                 <mailto:[email protected]>
>>                      <mailto:[email protected]
>>                 <mailto:[email protected]>>>
>>                       > An: [email protected]
>>                 <mailto:[email protected]>
>>                 <mailto:[email protected]
>>                 <mailto:[email protected]>>
>>                       > Betreff: Re: [Pharo-dev] binary serialization
>>                       >
>>                       > Yes, I have to do object substitutions. Thanks
>>                 for the link!
>>                       >
>>                       > thanks,
>>                       > Robert
>>                       >
>>                       > On 10/13/2015 03:43 AM, Max Leske wrote:
>>                       > >
>>                       > >> On 13 Oct 2015, at 09:40, Robert Withers
>>                      <[email protected]
>>                 <mailto:[email protected]>
>>                 <mailto:[email protected]
>>                 <mailto:[email protected]>>> wrote:
>>                       > >>
>>                       > >> Sven and Torsten, that's a binary
>>                 serialization library! It
>>                      will take time to learn it and how to use mappers.
>>                       > >>
>>                       > >> What is the format; is it language neutral?
>>                       > >
>>                       > > For quick serialization you don’t need to do
>>                 anything. It works
>>                      for (almost) all objects. Only if you want to
>>                 exclude things or
>>                      treat some objects in a special way, you will need
>>                 to do some stuff.
>>                       > >
>>                       > > Documentation:
>>                 http://rmod.inria.fr/web/software/Fuel.
>>                       > >
>>                       > >
>>                       > >>
>>                       > >> thanks,
>>                       > >> Robert
>>                       > >>
>>                       > >> On 10/13/2015 01:21 AM, Sven Van Caekenberghe
>>                 wrote:
>>                       > >>> Yes, it is called FUEL and it is a standard
>>                 part of the
>>                      image. See FLSerializer and FLMaterializer.
>>                       > >>>
>>                       > >>>> On 13 Oct 2015, at 06:59, Robert Withers
>>                      <[email protected]
>>                 <mailto:[email protected]>
>>                 <mailto:[email protected]
>>                 <mailto:[email protected]>>> wrote:
>>                       > >>>>
>>                       > >>>> Does Pharo have stream classes to binary
>>                 de/serialize an
>>                      object, such that the protocol accepts an object as
>>                 an argument and
>>                      converts it to a byteArray?
>>                       > >>>>
>>                       > >>>> --
>>                       > >>>> thanks,
>>                       > >>>> Robert
>>                       > >>>>
>>                       > >>>
>>                       > >>>
>>                       > >>
>>                       > >
>>                       > >
>>                       >
>>                       >
>>
>>
>>
>>
>>                 --
>>                 Mariano
>>                 http://marianopeck.wordpress.com
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Reply via email to