Smalltalk › Pharo › Pharo Smalltalk Developers

Question about ImageSegment, Symbols and SmartRefStream

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Mariano Martinez Peck

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 ?

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli

Re: [Pharo-project] Question about ImageSegment, Symbols and SmartRefStream

> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Adrian Lienhard

Re: [Pharo-project] Question about ImageSegment, Symbols and SmartRefStream

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli

Re: [Pharo-project] Question about ImageSegment, Symbols and SmartRefStream

>>> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck

Re: [Pharo-project] Question about ImageSegment, Symbols and SmartRefStream

On Thu, Jan 21, 2010 at 9:26 PM, Lukas Renggli <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Mariano Martinez Peck

Re: [Pharo-project] Question about ImageSegment, Symbols and SmartRefStream

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 <[hidden email]> wrote:

On Thu, Jan 21, 2010 at 9:26 PM, Lukas Renggli <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project