On 2009-12-05, at 6:53 AM, St�phane Ducasse wrote:
> Excellent!
> We need really cool and well tested imageSegments without etoy and project refs everywhere.
> Let us know up to date.
>
>
> On Dec 5, 2009, at 3:17 AM, Sheridan Mahoney wrote:
>
>>
>> Great! �The other person helping me is Martin McClure, and Mariano contacted
>> me just yesterday to start collaborating, so looks like there are 3 of us
>> now
>> hooked on ImageSegment....
>>
>> -- Sheri
>>
>>
>>
>> Adrian Lienhard 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...
>>>
>>> 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
>>>
>>>
>>
>> --
>> View this message in context:
http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4116203.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> 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