On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
Hi Sheri,

Sounds ok to make new: raise an exception if you adjust the tests (and
any code that exists in the image using new: (but I assume there is
none)).

However, the actual reason why you get multiple same symbols after
loading a segment likely is unrelated to ByteSymbol class>>new:. I
guess it is because when creating the segment you do not hold onto
these symbols. Like this they do not get into the outPointers ref
stream but in the bytearray. When installing the segment again, with
same symbols existing in the image already, then you get duplicates.

The "right way" to do this is to strongly hold onto all symbols when
creating a segment. See #createSegmentFrom:. You can reproduce this
problem by commenting out the first line of #createSegmentFrom: and
running #testSymbols.

Let us know how it goes...


Ok...let me see if I understood you correctly.

When you are creating your root of objects and you put symbols inside, they are not put in ourPointers but in ByteArray.
This is due to the fact that the only object who is pointing to that symbol is inside the segment ?
�
What you do with this piece of code:

��� symbolHolder := Symbol allSymbols.

is to hold those symbols there. So, when ImageSegment uses the GC techniques to detect which objects are ONLY pointed from inside of the segment, the symbols is not found (because it is accessible trough that test) and thus, it goes to outPointers instead of ByteArray.

And of course, if it is in outPointers instead of ByteArray when the segment is loaded again, yo don't create a symbol again but use the same object (the one of the oop).

I am correct? or I understood anything ?

Cheers,

Mariano

BTW, Mariano is also writing ImageSegment tests, so maybe you want to
join forces (or maybe he already is the colleague you mentioned?).

Cheers,
Adrian

On Dec 3, 2009, at 23:10 , St�phane Ducasse wrote:

>> From: Sheridan Mahoney <sheridan@sheridan-mahoney.com>
>> Date: December 3, 2009 11:04:19 PM GMT+01:00
>> To: pharo-project-bounces@lists.gforge.inria.fr
>> Subject: Re: getting rid of Symbol >> new: ?
>> Reply-To: sheridan@sheridan-mahoney.com
>>
>>
>> A colleague and I are investigating the ImageSegment class and its
>> methods, we came across an issue I would like to get external
>> opinions on. �Newbie alert, BTW (at least one of us, no names
>> mentioned...). �Also, this is not a problem that will affect many
>> users, but it is familiarizing us with the check-in process,
>> slices, etc. �While working on ImageSegment tests, we discovered a
>> problem on trying to load segments that had Symbols in the root
>> array. �It is possible to create 2 ByteSymbols with the same
>> sequence of characters. �:( �In trying to track down how this is
>> possible, we came across a side issue, that � ByteSymbol new: � had
>> the capacity to create multiple new ByteSymbols with the same
>> number of nil characters (as in, initialized with nil). �We want to
>> dissallow � Symbol new: � , which would cause people to use one of
>> the nicer methods for Symbol/ByteSymbol creation (namely, one which
>> checks that the sequence of characters doesn't already exist, as
>> part of the creation process). �We have a fix we want to check in,
>> but currently it breaks a test case in the SymbolTest class, which
>> is checking that � new: � works. We also changed the � intern:
>> method on the class side of Symbol to use � basicNew: � instead
>> of � new: � . �Are there reasons to keep 'Symbol new:' , that
>> outweigh the reasons to get rid of it?
>> Many thanks,
>> and Cheers,
>> Sheri Mahoney
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project