December 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11079

by Marcus Denker

11079 ----- Issue 1558: The old preference browser should be as much functionnal as possible while migrating to the new setting system Issue 1552: Add Float>>ulp support SLICE-PreferencesMigration-Part6 in InBox ----------------- make the old preference browser fully functional again. * hacked Preference>>preferenceValue, Preference >>preferenceValue:, Preference>>rawValue: and Preference>>togglePreferenceValue. * new Preferences class method category "settings-migration": For each preference migration, it contains 2 methods for getting and setting the preference. They are implemented using the new setting system. As an example for the migration of #annotationPanes: Preferences class>>annotationPanesSetting and Preferences class>>annotationPanesSetting: are added. ----------------- Also useful to understand correspondences between old and new preference systems

Dec. 8, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Mariano Martinez Peck

On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <adi(a)netstyle.ch> 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... > > 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 > 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 <sheridan(a)sheridan-mahoney.com> > >> Date: December 3, 2009 11:04:19 PM GMT+01:00 > >> To: pharo-project-bounces(a)lists.gforge.inria.fr > >> Subject: Re: getting rid of Symbol >> new: ? > >> Reply-To: sheridan(a)sheridan-mahoney.com > >> > >> > >> 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 > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 8, 2009

[Pharo-project] Issue 1558: The old preference browser should be as much functionnal as possible while migrating to the new setting system

by alain.plantec＠free.fr

SLICE-PreferencesMigration-Part6 in InBox ----------------- make the old preference browser fully functional again. * hacked Preference>>preferenceValue, Preference >>preferenceValue:, Preference>>rawValue: and Preference>>togglePreferenceValue. * new Preferences class method category "settings-migration": For each preference migration, it contains 2 methods for getting and setting the preference. They are implemented using the new setting system. As an example for the migration of #annotationPanes: Preferences class>>annotationPanesSetting and Preferences class>>annotationPanesSetting: are added. ----------------- Also useful to understand correspondences between old and new preference systems

Dec. 8, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Henrik Johansen

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

Dec. 8, 2009

[Pharo-project] Fwd: [squeak-dev] Re: On traits composition

by Igor Stasenko

---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: 2009/12/8 Subject: Re: [squeak-dev] Re: On traits composition To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> 2009/12/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/12/8 Andreas Raab <andreas.raab(a)gmx.de>: >> Igor Stasenko wrote: >>> >>> T1+T2 >>> should mean 'apply T1 then T2', but not 'apply combination of T1 and T2'. >>> Its much easier to implement as well as easy to understand & follow. >> >> That's what I'm thinking as well. >> >>> Also, in Pharo list i suggested extension to exclusion operator: >>> >>> in addition to: >>> T1 - selectorsArray "{ #sel1. #sel2 }" >>> >>> also have: >>> >>> T1 - T2 >>> >>> which should transparently behave as: >>> >>> T1 - (T2 selectors) >>> >>> and mean: apply all from T1 , except selectors in T2. >> >> I'll leave this as an exercise for the interested reader :) >> >>> Btw, i am curious about one thing: >>> Since traits allowed to hold method for both instance side and class side. >> >> Ah, yes. Classes and metaclasses and traits. Last time we had this >> discussion it was pretty clear that this whole area is not well-understood. >> That you can only apply a trait without class-side methods to a class for >> example, causes all sorts of irritation when you later add a class method to >> the trait, thereby making it non-applicable to compositions where it's >> already used. It's inconsistent at least (broken as far as I'm concerned >> since you can create compositions that can't be recreated). >> >>> Now, how i can specify a composition, which applies my trait, except >>> #isel1 and #csel2 ? >>> So, final class should have #isel2 method at instance side and >>> #csel2 at class side, but not #isel1 and not #csel2. >>> And what is a correct syntax for defining such composition in class >>> definition? >> >> Yes, that's just more inconsistencies resulting from the same basic problem. >> >> Cheers, >> Â - Andreas >> > > Since classInstVarNames are defined in a separate declaration, I do > not see why it couldn't be so for Traits. > This would lead to some simplications. > A possible POV is to handle #class as an ordinary message. It could > eventually return any object (squeak specific implementation apart). > So why put requirements on the protocol of object answered by #class > and not on the protocol answered by #asInteger ? It is well known the > second is a Boolean after all... If we don't put protocol requirements > on self class, we then do not need any class side Trait, do we ? (I > mean they could just be ordinary Traits). > IMO ideally, trait should NOT care where it applied to (be it class, metaclass or any other object). It should expect that object supporting a certain Behavior-based protocol (like #setTraitComposition:) but nothing more than that. Naturally, trait could be seen as a partial behavior, and so, it should Â be applicable to just behavior only, not to two behaviors at once (class/metaclass). I think this i a clear case, where we could have a much less complex implementation by sacrificing the 'class side' view of trait (ClassTrait). Because, one could always create a two separate traits (TApple , TAppleClassSide) and apply each one independently: Apple uses: TApple.. Apple class uses: TAppleClassSide. -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig.

Dec. 8, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Mariano Martinez Peck

On Sat, Dec 5, 2009 at 9:41 PM, John M McIntosh < johnmci(a)smalltalkconsulting.com> 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 <sheridan(a)sheridan-mahoney.com> > >>>>> Date: December 3, 2009 11:04:19 PM GMT+01:00 > >>>>> To: pharo-project-bounces(a)lists.gforge.inria.fr > >>>>> Subject: Re: getting rid of Symbol >> new: ? > >>>>> Reply-To: sheridan(a)sheridan-mahoney.com > >>>>> > >>>>> > >>>>> 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 > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> 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 > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 8, 2009

Re: [Pharo-project] FontTest>>testDisplay failing in Pharo image due to new StrikeFonts

by Miguel Enrique CobÃ¡ Martinez

El mar, 08-12-2009 a las 11:01 +0100, Henrik Johansen escribiÃ³: > On Dec 8, 2009, at 10:00 34AM, Adrian Lienhard wrote: > I've rewritten that test to be more robust, issue 1556 with slice in inbox. > > Cheers, > Henry And it was in just one hour! Great work, thank you very much! -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Dec. 8, 2009

Re: [Pharo-project] FontTest>>testDisplay failing in Pharo image due to new StrikeFonts

by Henrik Johansen

On Dec 8, 2009, at 10:00 34AM, Adrian Lienhard wrote: > Hi, > > The test FontTest>>testDisplay fails in the latest Pharo image. If > somebody has a bit of time left, it would be great to get a fix. We > are almost down to 0 failures/errors in the Pharo image... > > http://code.google.com/p/pharo/issues/detail?id=1555 > > Adrian > http://code.google.com/p/pharo/issues/detail?id=1136&can=1&q=black&colspec=… , I believe. It's in 1.1 already, test does not fail there. Also, in Core testResetAfterEmphasized fails but it seems to have been removed from Dev. It's a malformed test though, as it tests for empty, when it is valid for the method to leave non-synthetic versions in the derived array after a reset (Which is the case for Bitmap DejaVu, which includes bold, italic, bold italic versions) I've rewritten that test to be more robust, issue 1556 with slice in inbox. Cheers, Henry

Dec. 8, 2009

Re: [Pharo-project] VMMaker in Pharo.

by Mariano Martinez Peck

On Tue, Dec 8, 2009 at 8:00 AM, arnaud Jean Baptiste < jbaptiste.arnaud(a)gmail.com> wrote: > Sorry Mariano i don't have update the wiki of pharo, will do make that > soon. > If you want to run easily VMMaker i building a loader of VMMaker for pharo. > > on squeaksource: JBARepo > > VMMakerloader > and run loadAndFix () > It work, if you have any problem about it or any question, don't hesitate > to ask. > > > Thanks JB. I have just tried and worked perfect. Cheers, Mariano > > > On Dec 8, 2009, at 12:38 AM, David T. Lewis wrote: > > > On Mon, Dec 07, 2009 at 11:46:45PM +0100, Mariano Martinez Peck wrote: > >> On Mon, Dec 7, 2009 at 12:09 PM, David T. Lewis <lewis(a)mail.msen.com> > wrote: > >> > >>> On Mon, Dec 07, 2009 at 11:53:00AM +0100, Mariano Martinez Peck wrote: > >>>> Hi! I need to load VMMaker and I was reading this link: > >>>> http://code.google.com/p/pharo/wiki/BuildingAVMOnPharo > >>>> > >>>> I tried with the gofer script but it doesn't work in new Gofer > version, > >>> as I > >>>> need to change add: for addPackage: > >>>> There were also a problem with the ladrillos repo which was with > lowcase > >>>> instead of uppercase. The correct Gofer script to load VMMaker is: > >>>> > >>>> |gofer| > >>>> > >>>> "Create Gofer Object" > >>>> gofer := Gofer new. > >>>> > >>>> "Load the FFI package" > >>>> ScriptLoader loadFFI. > >>>> > >>>> "add the Speech packages" > >>>> gofer squeaksource: 'Ladrillos'; > >>>> addPackage: 'Speech-Klatt'. > >>>> > >>>> "add VMMaker Packages" > >>>> gofer squeaksource: 'VMMaker'; > >>>> addPackage:'VMMaker'. > >>>> > >>>> "add Alien Support Packages" > >>>> gofer squeaksource: 'Alien'; > >>>> addPackage:'Alien-VMMaker-Support'. > >>>> > >>>> " Load " > >>>> gofer load. > >>> > >>> You may want to refer to this configuration map for some other packages > >>> to load with VMMaker: > >>> > >>> http://squeaksource.com/VMMaker/update-dtl.2.mcm > >>> > >> > >> Thanks Dave. It sounds like and interesting project to create a > >> ConfigurationOf for Metacello. Or at least, we need a ScriptLoader > >> loadVMMaker. > >> > >> So, we should load all the packages of that link ? Sorry for my > ignorance, > >> but what do those packages add? I mean, with the script I used, it is > >> broken? I can still use VMMaker? what additional features do I have with > the > >> rest of the packages? > > > > It is just a configuration map for MonticelloConfigurations. It is used > > when you evaluate "VMMaker updateFromServer", but it only works if you > > have MonticelloConfigurations in your image. But the format is very > simple > > so you can just read it from > http://squeaksource.com/VMMaker/update-dtl.2.mcm > > to figure out what the packages are. > > > > It would be good if we could have something similar for Pharo, so > > if you can make this work with Metacello or one of the loaders for > > Pharo, that would be great. > > > > The list of packages came from the "recipe" that Andreas uses for > building > > Windows VMs, plus packages that I added (OSProcessPlugin etc). I know > > there are some missing from the configuration, but at least it's a start > :) > > > > Dave > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 8, 2009

[Pharo-project] FontTest>>testDisplay failing in Pharo image due to new StrikeFonts

by Adrian Lienhard

Hi, The test FontTest>>testDisplay fails in the latest Pharo image. If somebody has a bit of time left, it would be great to get a fix. We are almost down to 0 failures/errors in the Pharo image... http://code.google.com/p/pharo/issues/detail?id=1555 Adrian ___________________ http://www.adrian-lienhard.ch/

Dec. 8, 2009