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.