On Sat, Dec 5, 2009 at 9:41 PM, John M McIntosh < [email protected]> 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 > > Thanks John. I am interested in your experience. However, I didn't understand this last paragraph where you said to finally make it work. I don't understand what did you change. What is the difference between "font menu" and " stored forms of each font face for the menu" ? In addition, do you know why this has solved the problems ? Best regards, Mariano > > 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
