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
