Re: getting rid of Symbol >> new: ?
Locked
12
12
Re: getting rid of Symbol >> new: ?
 
|
From: Sheridan Mahoney <[hidden email]> _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
>> From: Sheridan Mahoney <[hidden email]>
>> Date: December 3, 2009 11:04:19 PM GMT+01:00 >> To: [hidden email] >> Subject: Re: getting rid of Symbol >> new: ? >> Reply-To: [hidden email] >> >> >> 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 I'm not sure that forbidding new: is a good idea. In Smalltalk it is rare to forbid such methods. Do you know from where your two byteSymbols were coming? Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
Stéphane Ducasse wrote:
> I'm not sure that forbidding new: is a good idea. > In Smalltalk it is rare to forbid such methods. > There are actually quite a few examples in existing code where #new and #new: are implemented as #shouldNotImplement or #error:. Classes that require a special way of creating their instances, such as CompiledMethod, often disallow new:. Singleton classes disallow new. Symbols seem to fit the pattern pretty well, and although it doesn't cause huge problems it seems like you shouldn't be able to create an invalid system state by sending public messages like #new:. Regards, -Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On Dec 3, 2009, at 2:19 PM, Stéphane Ducasse wrote:
> I'm not sure that forbidding new: is a good idea. In Smalltalk it is rare to forbid such methods. "If an instance created by sending the #new method ... would cause an error, a common practice is to override the behavior of #new so that it fails." Skublics, Klimas, & Thomas, Smalltalk with Style, p. 14 (Prentice Hall, 1996). James Foster _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
thanks. I know these book
Now the question is: are they any senders... > I'm not sure that forbidding new: is a good idea. In Smalltalk it is rare to forbid such methods. > > "If an instance created by sending the #new method ... would cause an error, a common practice is to override the behavior of #new so that it fails." Skublics, Klimas, & Thomas, Smalltalk with Style, p. 14 (Prentice Hall, 1996). > > James Foster > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
In reply to this post by Stéphane Ducasse
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 <[hidden email]> >> Date: December 3, 2009 11:04:19 PM GMT+01:00 >> To: [hidden email] >> Subject: Re: getting rid of Symbol >> new: ? >> Reply-To: [hidden email] >> >> >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
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
|
Re: getting rid of Symbol >> new: ?
|
|
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 <[hidden email]> >>>> Date: December 3, 2009 11:04:19 PM GMT+01:00 >>>> To: [hidden email] >>>> Subject: Re: getting rid of Symbol >> new: ? >>>> Reply-To: [hidden email] >>>> >>>> >>>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> >>>>> Date: December 3, 2009 11:04:19 PM GMT+01:00 >>>>> To: [hidden email] >>>>> Subject: Re: getting rid of Symbol >> new: ? >>>>> Reply-To: [hidden email] >>>>> >>>>> >>>>> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
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 <[hidden email]> >>>>>> Date: December 3, 2009 11:04:19 PM GMT+01:00 >>>>>> To: [hidden email] >>>>>> Subject: Re: getting rid of Symbol >> new: ? >>>>>> Reply-To: [hidden email] >>>>>> >>>>>> >>>>>> 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 >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <[hidden email]> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Issue 1551: possible to create 2 ByteSymbols with the same sequence of characters( WAS: getting rid of Symbol >> new: ?)
|
|
In reply to this post by Adrian Lienhard
This is just to let the people of the list know I have reported the above bug (Issue 1551) and
submitted a fix and tests to PharoInbox. It is called: SLICE-disallow-Symbol-new-SheridanMahoney.2 I didn't see a way to change the status to "Fixed", so it is just listed as "New". Cheers, Sheri
|
Re: Issue 1551: possible to create 2 ByteSymbols with the same sequence of characters( WAS: getting rid of Symbol >> new: ?)
|
|
and, forgot to mention, I did an image check, and did not find any uses of
Symbol >> new: once we changed Symbol >> intern: . Also, does something need to be enabled in order to be able to modify the description fields in the issue tracker? Not having much luck in my searches... Thanks, Sheri
|
Re: Issue 1551: possible to create 2 ByteSymbols with the same sequence of characters( WAS: getting rid of Symbol >> new: ?)
|
|
Hi Sheri,
Thanks for the contribution! Please send me the mail address you use for the Google account. I'll add you to the list of developers. BTW, have you signed the license agreement? Cheers, Adrian On Dec 7, 2009, at 21:14 , Sheridan Mahoney wrote: > > and, forgot to mention, I did an image check, and did not find any > uses of > Symbol >> new: once we changed Symbol >> intern: . > > Also, does something need to be enabled in order to be able to > modify the > description fields in the issue tracker? Not having much luck in my > searches... > Thanks, > Sheri > > > > Sheridan Mahoney wrote: >> >> This is just to let the people of the list know I have reported the >> above >> bug (Issue 1551) and >> submitted a fix and tests to PharoInbox. It is called: >> SLICE-disallow-Symbol-new-SheridanMahoney.2 >> >> I didn't see a way to change the status to "Fixed", so it is just >> listed >> as "New". >> >> Cheers, >> 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)). >>> >>> >> >> > > -- > View this message in context: http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4128207.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1551: possible to create 2 ByteSymbols with the same sequence of characters( WAS: getting rid of Symbol >> new: ?)
|
|
The address for my Google account is:
smagooey@yahoo.com I just sent Stef an email attachment with the license agreement, and will be putting a hard copy in the mail. Cheers, Sheri
|
Re: Issue 1551: possible to create 2 ByteSymbols with the same sequence of characters( WAS: getting rid of Symbol >> new: ?)
|
|
I added you as a project committer.
Cheers, Adrian On Dec 7, 2009, at 22:55 , Sheridan Mahoney wrote: > > The address for my Google account is: > > [hidden email] > > I just sent Stef an email attachment with the license agreement, and > will be > putting a hard copy in the mail. > > Cheers, > Sheri > > > > Adrian Lienhard wrote: >> >> Hi Sheri, >> >> Thanks for the contribution! >> >> Please send me the mail address you use for the Google account. I'll >> add you to the list of developers. >> >> BTW, have you signed the license agreement? >> >> Cheers, >> Adrian >> >> >> On Dec 7, 2009, at 21:14 , Sheridan Mahoney wrote: >> >>> >>> and, forgot to mention, I did an image check, and did not find any >>> uses of >>> Symbol >> new: once we changed Symbol >> intern: . >>> >>> Also, does something need to be enabled in order to be able to >>> modify the >>> description fields in the issue tracker? Not having much luck in my >>> searches... >> >>> Thanks, >>> Sheri >>> >>> >>> >>> Sheridan Mahoney wrote: >>>> >>>> This is just to let the people of the list know I have reported the >>>> above >>>> bug (Issue 1551) and >>>> submitted a fix and tests to PharoInbox. It is called: >>>> SLICE-disallow-Symbol-new-SheridanMahoney.2 >>>> >>>> I didn't see a way to change the status to "Fixed", so it is just >>>> listed >>>> as "New". >>>> >>>> Cheers, >>>> 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)). >>>>> >>>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4128207.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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-tp4109230p4128749.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
In reply to this post by johnmci
On Sat, Dec 5, 2009 at 9:41 PM, John M McIntosh <[hidden email]> wrote: I should relate our experience with segments in Sophie was not helpful. 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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
On Dec 8, 2009, at 11:33 20AM, Mariano Martinez Peck wrote: > > > 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" ? The way I read it, instead of storing the fonts themselves in an image segment, they stored a form with a string rendered by the font, then used that to display in list instead of actually loading the font, and rendering text with it. That way the list could be shown fast, without having to load the fonts themselves until actually used/fonts on the machine changes. > > In addition, do you know why this has solved the problems ? If you look at the relative complexity of TTCFont and Form instances, it'd hardly come as a surprise that one may be loaded consistently, while the other is harder to get loaded correctly in all cases... In other words, to me it seems like a workaround for non-repeatable errors when loading complex objects within ImageSegments (by storing simpler objects instead). Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
In reply to this post by Adrian Lienhard
On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <[hidden email]> wrote: Hi Sheri, Ok...let me see if I understood you correctly. When you are creating your root of objects and you put symbols inside, they are not put in ourPointers but in ByteArray. This is due to the fact that the only object who is pointing to that symbol is inside the segment ? What you do with this piece of code: symbolHolder := Symbol allSymbols. is to hold those symbols there. So, when ImageSegment uses the GC techniques to detect which objects are ONLY pointed from inside of the segment, the symbols is not found (because it is accessible trough that test) and thus, it goes to outPointers instead of ByteArray. And of course, if it is in outPointers instead of ByteArray when the segment is loaded again, yo don't create a symbol again but use the same object (the one of the oop). I am correct? or I understood anything ? Cheers, Mariano BTW, Mariano is also writing ImageSegment tests, so maybe you want to _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
On Dec 8, 2009, at 12:08 , Mariano Martinez Peck wrote: > On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <[hidden email]> > wrote: > When you are creating your root of objects and you put symbols > inside, they > are not put in ourPointers but in ByteArray. > This is due to the fact that the only object who is pointing to that > symbol > is inside the segment ? To be precise, the symbols are also pointed to by the symbol table, but only by weak references. Since image segments use the GC mark logic, these pointers are not considered. > What you do with this piece of code: > > symbolHolder := Symbol allSymbols. > > is to hold those symbols there. So, when ImageSegment uses the GC > techniques > to detect which objects are ONLY pointed from inside of the segment, > the > symbols is not found (because it is accessible trough that test) and > thus, > it goes to outPointers instead of ByteArray. > > And of course, if it is in outPointers instead of ByteArray when the > segment > is loaded again, yo don't create a symbol again but use the same > object (the > one of the oop). > > I am correct? or I understood anything ? yes. Cheers, Adrian _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: getting rid of Symbol >> new: ?
|
|
On Tue, Dec 8, 2009 at 5:07 PM, Adrian Lienhard <[hidden email]> wrote:
Ahhh ok. Now I see Symbol class >> rehash where it sets to SymbolTable := WeakSet Now...my finally question is, where in the code you can see the GC only mark "normal" objects and that week objects are not being taken into account. Do you know ? I tried to search it but I didn't find it. Thanks!! Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |