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

Re: [Pharo-project] [OT] Vista must-see items??

by Boris Popov

Install Windows 7 RC and revert to Classic look. -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Tuesday, July 28, 2009 3:19 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] [OT] Vista must-see items?? Hello all, I finally bought a new machine. It arrived with a severe malware infection (Vista), and while I was tempted to blow it away w/o even so much as letting it boot, I decided to have a look. Is there anything I should try before the stampede of Penguins begins? In particular, is there any way to gag the animation/visual effects/whatever they call them? Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 28, 2009

[Pharo-project] [OT] Vista must-see items??

by Schwab,Wilhelm K

Hello all, I finally bought a new machine. It arrived with a severe malware infection (Vista), and while I was tempted to blow it away w/o even so much as letting it boot, I decided to have a look. Is there anything I should try before the stampede of Penguins begins? In particular, is there any way to gag the animation/visual effects/whatever they call them? Bill

July 28, 2009

Re: [Pharo-project] Polymorph depends on Sound

by Adrian Lienhard

I've also removed these four classes. Adrian BTW, now the external package [1] properly loads into Pharo-core. [1] http://www.squeaksource.com/PharoSound.html On Jul 28, 2009, at 20:07 , John M McIntosh wrote: > Todd as an example here I ripped all of the Sound logic out of the > wikiserver image > since it takes space and I left just the > > AbstractSound > RestSound > SoundBuffer > SoundPlayer > > in the image. > > No doubt I could have tried harder and removed those too. > > On 28-Jul-09, at 1:52 AM, Eagle Offshore wrote: > >> I understand wanting to limit dependencies and clean stuff up - but >> is >> there a particular reason why we don't think the basic ability to >> play >> sounds belongs in a base application development environment? >> >> Seems like a core capability and I worry about sound rotting if it >> doesn't live in the base image. >> >> -Todd Blanchard > > -- > = > = > = > = > = > ====================================================================== > 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

July 28, 2009

Re: [Pharo-project] Fwd: [Bug and Fix] actualclass in presence of classtrait

by StÃ©phane Ducasse

>>> > then you don't need the MethodReference, > because you having a CompiledMethod(s), which are installed on system. > and RemoteMethodReference , which is not. > > Btw, i am curious myself, what is the point in referencing the methods > indirectly (through MethodReference)? no idea. now this is there and may be we will remove it but for now it should work. We should not do everything at the same time. > Why not just reference directly to CompiledMethod? > What it gives in addition to what CompiledMethod itself could answer > to you? Now package :)

July 28, 2009

Re: [Pharo-project] SmalltalkImage current platformName [WAS] Re: Baseline test results on pharo core 10392

by StÃ©phane Ducasse

+1 On Jul 28, 2009, at 8:39 PM, Igor Stasenko wrote: > I think that all such kind of queries (like isXXXPlatform) should be > not included and not used in a well-designed system. > If you want some capability - then you should ask directly for it, > irrespectively on what platform you are currently running. > > As an example, see the FileDirectory>>slash > > It is very confusing for people to see isXXXPlatform in code, because > it tells almost nothing about what platform-specific feature you rely > on. > So, i'd prefer to see the code which asks some provider object about > support of given capability (it could be OSPlatform), > instead of placing isMacOS, isWindows , isUnix into code, which > causing a lot of frustration to people who would want to port your > code to other platforms, or simply check, if their platform provides > required feature(s). > > Don't forget, that each time someone sees isMacOs, or isWindows etc.. > he thinks: 'duh.. this thing wont work on my platform'. > Instead of thinking in a different way: 'duh.. this thing depends on > following OS feature, lets take a look if i can hack it to wire it up > with my OS' > > 2009/7/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Tue, Jul 28, 2009 at 4:38 PM, Miguel CobÃ¡ >> <miguel.coba(a)gmail.com> wrote: >>> >>> I think that it should be done at least in pharo core and more >>> importantly, >> >> Yes, I wanted to say to do it in Pharo core at least. Then, it's a >> task of >> each external package developer to change their code to use this >> methods. >> >>> >>> create a new page in the wiki with the programming recommended >>> tips/techniques >>> and there to include all the tips that appear on the list: >>> >>> - Use the OSPlatform isActivePlatform and children >>> - Not to use the Utilities deprecated classes >>> - The case against SmalltalkImage current that appear in a thread a >>> couple of days ago >>> - etc >>> >>> and featured in the pharo website to avoid introducing this bad >>> idioms >>> again >>> >>> Miguel CobÃ¡ >>> >>> 2009/7/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>> >>>> >>>> On Tue, Jul 28, 2009 at 4:24 PM, Adrian Lienhard <adi(a)netstyle.ch> >>>> wrote: >>>>> >>>>> We have OSPlatform. For instance: >>>>> >>>>> MacOSXPlatform isActivePlatform >>>> >>>> Nice! I wasn't aware of them...so, what about changing >>>> >>>> SmalltalkImage current platformName = 'Mac OS' >>>> >>>> for >>>> >>>> MacOSXPlatform isActivePlatform >>>> >>>> In all places? Obviously, the same with the other platforms. >>>> >>>> Is there a reason I don't see? just time to do it ? >>>> >>>> thanks! >>>> >>>> Mariano >>>> >>>> >>>>> >>>>> HTH, >>>>> Adrian >>>>> >>>>> On Jul 28, 2009, at 18:55 , Mariano Martinez Peck wrote: >>>>> >>>>>> Ok, I write the changeset, but I don't like it hehehehe. >>>>>> >>>>>> What about puting isMacintosh, isUnix and isWindows in >>>>>> SmalltalkImage ? >>>>>> I think those methods are useful and perhaps many people in >>>>>> different >>>>>> packages are doing things like this: >>>>>> ^SmalltalkImage current platformName = 'Mac OS' >>>>>> >>>>>> This is not nice. Tomorrow we change the platformName and we >>>>>> have to >>>>>> modify >>>>>> a lot of code. >>>>>> >>>>>> For example, I searched the string "SmalltalkImage current >>>>>> platformName = >>>>>> 'Mac OS'" and it is in a lot of places. I think we should get >>>>>> rid of >>>>>> them. >>>>>> >>>>>> what do you think? >>>>>> >>>>>> best, >>>>>> >>>>>> Mariano >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 28, 2009 at 3:18 PM, Adrian Lienhard >>>>>> <adi(a)netstyle.ch> >>>>>> wrote: >>>>>> >>>>>>> Yes, if you tested it and think it is good, please change the >>>>>>> status >>>>>>> to verified. >>>>>>> >>>>>>> Cheers, >>>>>>> Adrian >>>>>>> >>>>>>> On Jul 28, 2009, at 17:12 , Miguel CobÃ¡ wrote: >>>>>>> >>>>>>>> should the ticket be marked as verified? >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 28, 2009 at 10:10 AM, Miguel >>>>>>>> CobÃ¡<miguel.coba(a)gmail.com> >>>>>>>> wrote: >>>>>>>>> It works ok on my >>>>>>>>> >>>>>>>>> Debian Linux 5.0 (Lenny) i386. >>>>>>>>> Debian Linux 5.0 (Lenny) amd64. >>>>>>>>> >>>>>>>>> Miguel CobÃ¡ >>>>>>>>> >>>>>>>>> 2009/7/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jul 28, 2009 at 11:58 AM, Adrian Lienhard >>>>>>>>>> <adi(a)netstyle.ch> wrote: >>>>>>>>>>> >>>>>>>>>>> On Jul 28, 2009, at 14:51 , Mariano Martinez Peck wrote: >>>>>>>>>>> >>>>>>>>>>>> On Tue, Jul 28, 2009 at 5:42 AM, Damien Cassou < >>>>>>> damien.cassou(a)gmail.com >>>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 2009/7/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>>>>>>>>>>> HostSystemMenusTest class>>expectedFailures >>>>>>>>>>>>>> >>>>>>>>>>>>>> SmalltalkImage current platformName = 'Mac OS' ifFalse:[ >>>>>>>>>>>>>> ^#(#testXXX #testYYY)]. >>>>>>>>>>>>>> ]. >>>>>>>>>>>>>> ^#() >>>>>>>>>>>>> >>>>>>>>>>>>> Expected failures are indications of bugs that are not yet >>>>>>>>>>>>> corrected. >>>>>>>>>>>>> Does not seem to apply here. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ahhh okok. So...shall we go for torsten solution ? >>>>>>>>>>> >>>>>>>>>>> Yes. >>>>>>>>>> >>>>>>>>>> http://code.google.com/p/pharo/issues/detail?id=996 >>>>>>>>>> >>>>>>>>>> I also attached a possible changeset. >>>>>>>>>> >>>>>>>>>> best, >>>>>>>>>> >>>>>>>>>> Mariano >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Damien Cassou >>>>>>>>>>>>> http://damiencassou.seasidehosting.st >>>>>>>>>>>>> >>>>>>>>>>>>> "Lambdas are relegated to relative obscurity until Java >>>>>>>>>>>>> makes >>>>>>>>>>>>> them >>>>>>>>>>>>> popular by not having them." James Iry >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 28, 2009

Re: [Pharo-project] SmalltalkImage current platformName [WAS] Re: Baseline test results on pharo core 10392

by StÃ©phane Ducasse

Yes and at the end we should have a kind of architecture for pharo. Stef On Jul 28, 2009, at 7:38 PM, Miguel CobÃ¡ wrote: > I think that it should be done at least in pharo core and more > importantly, > create a new page in the wiki with the programming recommended tips/ > techniques > and there to include all the tips that appear on the list: > > - Use the OSPlatform isActivePlatform and children > - Not to use the Utilities deprecated classes > - The case against SmalltalkImage current that appear in a thread a > couple of days ago > - etc > > and featured in the pharo website to avoid introducing this bad > idioms again > > Miguel CobÃ¡ > > 2009/7/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Tue, Jul 28, 2009 at 4:24 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >>> >>> We have OSPlatform. For instance: >>> >>> MacOSXPlatform isActivePlatform >> >> Nice! I wasn't aware of them...so, what about changing >> >> SmalltalkImage current platformName = 'Mac OS' >> >> for >> >> MacOSXPlatform isActivePlatform >> >> In all places? Obviously, the same with the other platforms. >> >> Is there a reason I don't see? just time to do it ? >> >> thanks! >> >> Mariano >> >> >>> >>> HTH, >>> Adrian >>> >>> On Jul 28, 2009, at 18:55 , Mariano Martinez Peck wrote: >>> >>>> Ok, I write the changeset, but I don't like it hehehehe. >>>> >>>> What about puting isMacintosh, isUnix and isWindows in >>>> SmalltalkImage ? >>>> I think those methods are useful and perhaps many people in >>>> different >>>> packages are doing things like this: >>>> ^SmalltalkImage current platformName = 'Mac OS' >>>> >>>> This is not nice. Tomorrow we change the platformName and we have >>>> to >>>> modify >>>> a lot of code. >>>> >>>> For example, I searched the string "SmalltalkImage current >>>> platformName = >>>> 'Mac OS'" and it is in a lot of places. I think we should get rid >>>> of >>>> them. >>>> >>>> what do you think? >>>> >>>> best, >>>> >>>> Mariano >>>> >>>> >>>> >>>> On Tue, Jul 28, 2009 at 3:18 PM, Adrian Lienhard <adi(a)netstyle.ch> >>>> wrote: >>>> >>>>> Yes, if you tested it and think it is good, please change the >>>>> status >>>>> to verified. >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> On Jul 28, 2009, at 17:12 , Miguel CobÃ¡ wrote: >>>>> >>>>>> should the ticket be marked as verified? >>>>>> >>>>>> >>>>>> On Tue, Jul 28, 2009 at 10:10 AM, Miguel CobÃ¡<miguel.coba(a)gmail.com >>>>>> > >>>>>> wrote: >>>>>>> It works ok on my >>>>>>> >>>>>>> Debian Linux 5.0 (Lenny) i386. >>>>>>> Debian Linux 5.0 (Lenny) amd64. >>>>>>> >>>>>>> Miguel CobÃ¡ >>>>>>> >>>>>>> 2009/7/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 28, 2009 at 11:58 AM, Adrian Lienhard >>>>>>>> <adi(a)netstyle.ch> wrote: >>>>>>>>> >>>>>>>>> On Jul 28, 2009, at 14:51 , Mariano Martinez Peck wrote: >>>>>>>>> >>>>>>>>>> On Tue, Jul 28, 2009 at 5:42 AM, Damien Cassou < >>>>> damien.cassou(a)gmail.com >>>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> 2009/7/27 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>>>>>>>>> HostSystemMenusTest class>>expectedFailures >>>>>>>>>>>> >>>>>>>>>>>> SmalltalkImage current platformName = 'Mac OS' ifFalse:[ >>>>>>>>>>>> ^#(#testXXX #testYYY)]. >>>>>>>>>>>> ]. >>>>>>>>>>>> ^#() >>>>>>>>>>> >>>>>>>>>>> Expected failures are indications of bugs that are not yet >>>>>>>>>>> corrected. >>>>>>>>>>> Does not seem to apply here. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ahhh okok. So...shall we go for torsten solution ? >>>>>>>>> >>>>>>>>> Yes. >>>>>>>> >>>>>>>> http://code.google.com/p/pharo/issues/detail?id=996 >>>>>>>> >>>>>>>> I also attached a possible changeset. >>>>>>>> >>>>>>>> best, >>>>>>>> >>>>>>>> Mariano >>>>>>>> >>>>>>>>> >>>>>>>>> Adrian >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Damien Cassou >>>>>>>>>>> http://damiencassou.seasidehosting.st >>>>>>>>>>> >>>>>>>>>>> "Lambdas are relegated to relative obscurity until Java >>>>>>>>>>> makes >>>>>>>>>>> them >>>>>>>>>>> popular by not having them." James Iry >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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

July 28, 2009

Re: [Pharo-project] Usage of fast drag

by StÃ©phane Ducasse

when david will be back from holiday I hope that we will have a version of OBpackage that can load with the one of lukas. On Jul 28, 2009, at 12:56 AM, Ramiro Diaz Trepat wrote: > +1 for the package browser, I miss it. > But I like the new inspector :) > > r. > > > On Mon, Jul 27, 2009 at 10:35 AM, Stuart Herring <st-lists(a)stuartherring.com > > wrote: > On Mon, Jul 27, 2009 at 7:37 PM, Damien > Cassou<damien.cassou(a)gmail.com> wrote: > >> (4) [...] FWIW, I still think you should reconsider fast drag - > enabling it makes a HUGE difference when moving and resizing windows. > > > > what do people think about 'fast drag' preference? > > > I use it all the time - but I do most my development on an EeePC, so > it makes a big difference there. > Interestingly, that - and switching to the Soft Squeak theme (which is > actually more because I like the colour coded windows than the > performance improvement) is the only performance change I make. I > infinitely prefer the package browser, and I even think the delays > associated with dynamic protocols are worthwhile. > > Regards, > Stuart > > _______________________________________________ > 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

July 28, 2009

Re: [Pharo-project] Fwd: [Bug and Fix] actualclass in presence of classtrait

by Igor Stasenko

2009/7/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> since I do not have internet I did not added the bugtracker but >> when we define a method in the class side of a trait we get an error: >> >> because a methodReference can be used on a method attached to a class >> so actualClass does not take into account traits >> >> MethodReference>>actualClass >> >> Â Â Â | actualClass | >> Â Â Â actualClass := Smalltalk at: classSymbol ifAbsent: [^nil]. >> Â Â Â classIsMeta ifTrue: [^actualClass classSide]. >> Â Â Â ^actualClass >> >> this breaks for example OBMethodCategoryFilter >> >> OBMethodCategoryFilter>>displayString: aStringOrText forParent: >> pNode child: cNode >> | category | >> ((cNode reference actualClass includesSelector: cNode reference >> methodSymbol) >> Â Â and: [cNode reference compiledMethod literals includes: >> #deprecated:]) >> Â Â Â ifTrue: [^aStringOrText asText addAttribute: TextEmphasis >> struckOut]. >> >> category := cNode category. >> (category beginsWith: '*') ifTrue: [ >> Â Â Â Â Â ^(category includesSubString: '-overrides') >> Â Â Â Â Â Â Â ifTrue: [aStringOrText asText addAttribute: TextEmphasis >> italic; addAttribute: TextColor red] >> Â Â Â Â Â Â Â ifFalse: [aStringOrText asText addAttribute: TextEmphasis >> italic]]. >> >> ^aStringOrText >> >> >> Here is a possible solution >> >> actualClass >> >> Â Â Â | actualClass traitName| >> Â Â Â ('*classTrait' match: classSymbol) >> Â Â Â Â Â Â Â ifTrue: [ traitName := classSymbol copyUpTo: Character space. >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ Smalltalk at: traitName asSymbol ifAbsent: [nil]]. >> Â Â Â actualClass := Smalltalk at: classSymbol ifAbsent: [^nil]. >> Â Â Â classIsMeta ifTrue: [^actualClass classSide]. >> Â Â Â ^actualClass >> >> This raises the question of MethodReference using symbol instead of >> pointers to objects. >> Funnily the creation methods require a class and not a classname. >> I can understand that in certain occasion (manipulating methods of >> classes that are not installed in the image >> is cool) but in that case may be we should have >> Â Â Â MethodReference >> Â Â Â RemoteMethodReference then you don't need the MethodReference, because you having a CompiledMethod(s), which are installed on system. and RemoteMethodReference , which is not. Btw, i am curious myself, what is the point in referencing the methods indirectly (through MethodReference)? Why not just reference directly to CompiledMethod? What it gives in addition to what CompiledMethod itself could answer to you? >> >> Stef >> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 28, 2009

[Pharo-project] Fwd: Object>>asAnnouncement seems strange

by StÃ©phane Ducasse

> > > asAnnouncement > ^ self > > I do not understand why this is like that. > beause either it returns an object (and this is not an announcement) > or it > is applied on Announcement and as such it should be defined on > Announcement. > > Stef > > >

July 28, 2009

[Pharo-project] Fwd: [Bug and Fix] actualclass in presence of classtrait

by StÃ©phane Ducasse

> since I do not have internet I did not added the bugtracker but > when we define a method in the class side of a trait we get an error: > > because a methodReference can be used on a method attached to a class > so actualClass does not take into account traits > > MethodReference>>actualClass > > | actualClass | > actualClass := Smalltalk at: classSymbol ifAbsent: [^nil]. > classIsMeta ifTrue: [^actualClass classSide]. > ^actualClass > > this breaks for example OBMethodCategoryFilter > > OBMethodCategoryFilter>>displayString: aStringOrText forParent: > pNode child: cNode > | category | > ((cNode reference actualClass includesSelector: cNode reference > methodSymbol) > and: [cNode reference compiledMethod literals includes: > #deprecated:]) > ifTrue: [^aStringOrText asText addAttribute: TextEmphasis > struckOut]. > > category := cNode category. > (category beginsWith: '*') ifTrue: [ > ^(category includesSubString: '-overrides') > ifTrue: [aStringOrText asText addAttribute: TextEmphasis > italic; addAttribute: TextColor red] > ifFalse: [aStringOrText asText addAttribute: TextEmphasis > italic]]. > > ^aStringOrText > > > Here is a possible solution > > actualClass > > | actualClass traitName| > ('*classTrait' match: classSymbol) > ifTrue: [ traitName := classSymbol copyUpTo: Character space. > ^ Smalltalk at: traitName asSymbol ifAbsent: [nil]]. > actualClass := Smalltalk at: classSymbol ifAbsent: [^nil]. > classIsMeta ifTrue: [^actualClass classSide]. > ^actualClass > > This raises the question of MethodReference using symbol instead of > pointers to objects. > Funnily the creation methods require a class and not a classname. > I can understand that in certain occasion (manipulating methods of > classes that are not installed in the image > is cool) but in that case may be we should have > MethodReference > RemoteMethodReference > > Stef > > > >

July 28, 2009