On 14 Oct 2015, at 09:45, Max Leske <maxleske@gmail.com> wrote:
On 14 Oct 2015, at 04:39, Robert Withers <robert.w.withers@gmail.com> wrote:
On 10/13/2015 09:43 PM, Mariano Martinez Peck wrote:
On Tue, Oct 13, 2015 at 10:33 PM, Robert Withers
<robert.w.withers@gmail.com <mailto:robert.w.withers@gmail.com>> 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?
Sounds to me like this (see FuelOutStackDebuAction):
serializeTestFailureContext: aContext toFileNamed: aFilename
| serializer |
serializer := FLSerializer newDefault.
self encodeDebugInformationOn: serializer.
serializer addPostMaterializationAction: [ :materialization |
Smalltalk tools debugger
openOn: Processor activeProcess
context: materialization root
label: 'External stack'
contents: nil
fullView: false ].
serializer
" use the sender context, generally the current context is not interesting"
serialize: aContext
toFileNamed: aFilename
This stores a block in the serialization which is evaluated after materialization. The only requirement is that it���s a clean block (no closure!).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.
Well, my pics will demonstrate. I am interested in doing more than mappping ivars or a class rename. I want to do a total substitution, then a further substitution on the receiving, import side:
Vat1: anObject (Class A) ---> On wire: desc (Descriptor) ---> Vat2: aProxy (Class FarERef)
A desc is substituted for a PassByProxy object, then a FarERef is substituted for the desc.
#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.
It seems your focus was pickling to disk then back. My focus is distributed proxy graphs, which has different use cases.
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
Right on, exactly! Could you tell me more about your Ghost proxies and Marea, please? As well, could you mention how you select a custom cluster on the serialization side?
thanks so much ^^
Robert<Exporting Vat.jpg><Importing Vat.jpg>
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
<robert.w.withers@gmail.com <mailto:robert.w.withers@gmail.com>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>>> 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
<robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>>> 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
<astares@gmx.de <mailto:astares@gmx.de>
<mailto:astares@gmx.de <mailto:astares@gmx.de>>
<mailto:astares@gmx.de <mailto:astares@gmx.de>
<mailto:astares@gmx.de <mailto:astares@gmx.de>>>> 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
TorstenGesendet: Dienstag, 13. Oktober 2015 um09:44 UhrVon: "Robert Withers"<robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>>>>An: pharo-dev@lists.pharo.org<mailto:pharo-dev@lists.pharo.org>
<mailto:pharo-dev@lists.pharo.org
<mailto:pharo-dev@lists.pharo.org>>
<mailto:pharo-dev@lists.pharo.org
<mailto:pharo-dev@lists.pharo.org>
<mailto:pharo-dev@lists.pharo.org
<mailto:pharo-dev@lists.pharo.org>>>Betreff: Re: [Pharo-dev] binaryserializationThanks
Yes, I have to do object substitutions.
for the link!<robert.w.withers@gmail.com
thanks,
Robert
On 10/13/2015 03:43 AM, Max Leske wrote:On 13 Oct 2015, at 09:40, Robert Withers
<mailto:robert.w.withers@gmail.com>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>>>> wrote:serialization library! It
Sven and Torsten, that's a binary
will take time to learn it and how to use
mappers.neutral?
What is the format; is it languageneed to do
For quick serialization you don���t
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.http://rmod.inria.fr/web/software/Fuel.
Documentation:Caekenberghe
thanks,
Robert
On 10/13/2015 01:21 AM, Sven Van
wrote:standardYes, it is called FUEL and it is a
part of the
image. See FLSerializer and FLMaterializer.WithersOn 13 Oct 2015, at 06:59, Robert
<robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>
<mailto:robert.w.withers@gmail.com
<mailto:robert.w.withers@gmail.com>>>> wrote:binary
Does Pharo have stream classes to
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