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 <[email protected]> >>> Date: December 3, 2009 11:04:19 PM GMT+01:00 >>> To: [email protected] >>> Subject: Re: getting rid of Symbol >> new: ? >>> Reply-To: [email protected] >>> >>> >>> 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > 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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
