[Pharo-project] Question about ImageSegment, Symbols and SmartRefStream
Hi folks. I am writing some ImageSegment tests and there is something I don't know how it is done. I create a segment with a root (array) that has symbols inside. Then, I export the segment using the method ImageSegment >> writeForExportOn: which uses a SmartRefStream to serialize itself and write it to a file. Now...the situation is like this: I hold the symbols so that they go to outPointers instead of wordarray. When I export the segment using writeForExportOn: the objects from outPointers should be exported also. Case 1) I export the segment and then load it in an image where the symbols are not present, and after the load, the symbols are present (and they came from the outPointers)...This is correct Case 2) I export the segment and then load it in an image where the symbols ARE ALREADY present, and after the load, the symbols ARE NOT duplicated...Ok..this is cool. But how does this magic happens ? Why I don't have two symbols equal ? If need the unit tests of both cases, I can past it here. Any ideas where this black magic comes from ?
Any ideas where this black magic comes from ?
From what I know Symbols always end up in the out-pointers because they are always referenced at least from the Symbol table.
That means they are serialized by the reference stream, which means that the not so black magic happens in ReferenceStream>>#readSymbol. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Jan 21, 2010, at 19:56 , Lukas Renggli wrote:
Any ideas where this black magic comes from ?
From what I know Symbols always end up in the out-pointers because they are always referenced at least from the Symbol table.
Not necessarily. The symbol table is a *weak* set and hence if you don't strongly hold onto the symbols they get into the segment array and not into the out pointers! This is a potential source of subtle problems because after loading the segment you end up with duplicated symbols (we run into this with Cmsbox...). The easiest solution is to create a temporary variable and assign "Symbol allSymbols" while creating a segment.
That means they are serialized by the reference stream, which means that the not so black magic happens in ReferenceStream>>#readSymbol.
Yep. Cheers, Adrian
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Any ideas where this black magic comes from ?
From what I know Symbols always end up in the out-pointers because they are always referenced at least from the Symbol table.
Not necessarily. The symbol table is a *weak* set and hence if you don't strongly hold onto the symbols they get into the segment array and not into the out pointers! This is a potential source of subtle problems because after loading the segment you end up with duplicated symbols (we run into this with Cmsbox...). The easiest solution is to create a temporary variable and assign "Symbol allSymbols" while creating a segment.
Ok, but that is done at several places in ImageSegement. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Thu, Jan 21, 2010 at 9:26 PM, Lukas Renggli <renggli@gmail.com> wrote:
Any ideas where this black magic comes from ?
From what I know Symbols always end up in the out-pointers because they are always referenced at least from the Symbol table.
Not necessarily. The symbol table is a *weak* set and hence if you don't strongly hold onto the symbols they get into the segment array and not into the out pointers! This is a potential source of subtle problems because after loading the segment you end up with duplicated symbols (we run into this with Cmsbox...). The easiest solution is to create a temporary variable and assign "Symbol allSymbols" while creating a segment.
Ok, but that is done at several places in ImageSegement.
I "fixed" this. Actually, I don't fix it, but I put in at least only one place that fix for everybody (I think). Thanks for the tipo of ReferenceStream>>#readSymbol. however...I debug it and have empy symbols...wierd. Now I am very dead, but I hope tomorrow to check it more in depth.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ahhhh I got it :) The trick was where Lukas said: readSymbol "PRIVATE -- Read the contents of a Symbol." ^ self readString asSymbol but....I realised that, String >> asSymbol is: asSymbol "Answer the unique Symbol whose characters are the characters of the string." ^Symbol intern: self And...Symbol >> intern: intern: aStringOrSymbol ^(self lookup: aStringOrSymbol) ifNil:[ | aClass aSymbol | aStringOrSymbol isSymbol ifTrue:[ aSymbol := aStringOrSymbol. ] ifFalse:[ aClass := aStringOrSymbol isOctetString ifTrue:[ByteSymbol] ifFalse:[WideSymbol]. aSymbol := aClass basicNew: aStringOrSymbol size. aSymbol string: aStringOrSymbol. ]. NewSymbols add: aSymbol. aSymbol]. that's why I don't get duplicates!!! Thanks a lot Lukas and Adrian...each day I am understanding a bit more all this stuff :) Cheers Mariano On Thu, Jan 21, 2010 at 9:31 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Thu, Jan 21, 2010 at 9:26 PM, Lukas Renggli <renggli@gmail.com> wrote:
Any ideas where this black magic comes from ?
From what I know Symbols always end up in the out-pointers because they are always referenced at least from the Symbol table.
Not necessarily. The symbol table is a *weak* set and hence if you don't strongly hold onto the symbols they get into the segment array and not into the out pointers! This is a potential source of subtle problems because after loading the segment you end up with duplicated symbols (we run into this with Cmsbox...). The easiest solution is to create a temporary variable and assign "Symbol allSymbols" while creating a segment.
Ok, but that is done at several places in ImageSegement.
I "fixed" this. Actually, I don't fix it, but I put in at least only one place that fix for everybody (I think).
Thanks for the tipo of ReferenceStream>>#readSymbol. however...I debug it and have empy symbols...wierd. Now I am very dead, but I hope tomorrow to check it more in depth.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Adrian Lienhard -
Lukas Renggli -
Mariano Martinez Peck