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