when I see the complexity of the code full of project and morph conditional I imagine that the primary idea beind imageSegment got damaged. Now imageSegment is probably difficult to control too.
Stef On Dec 5, 2009, at 9:41 PM, John M McIntosh wrote: > I should relate our experience with segments in Sophie was not helpful. > > We attempted to segment off our font menu since it was expensive to build, > and really > only needed to be changed if the fonts on the machine changed. > Since the image was read only we would startup, build the font menu then > image segment that off. > > On a restart we just read the segment in, confirmed the machine didn't have > font files changed. > This worked well in the *lab*. > > But when we push it to the public we started getting email about machines > crashing. > Tim and I were just unable to determine why... But it was always related to > the point > where it read the image segment, sometimes it would crash (rarely) mostly > not. > > We backed that out, and settled with a image segment that really just stored > forms of > each font face for the menu. That *seemed* to work ok > > > 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 <[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 > > -- > =========================================================================== > John M. McIntosh <[email protected]> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.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
