- Pharo-dev - lists.pharo.org

[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

[Pharo-project] Fwd: may be a bottleneck

by StÃ©phane Ducasse

> > > Hi > > I'm trying to fix the problem of actualClass and I realize that > actualClass is invoked all the time by the browsers > on redisplay. I wonder why the browser are refreshing when normally > they should only do that on events. > > Stef > > >

July 28, 2009

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

by Igor Stasenko

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.

July 28, 2009

Re: [Pharo-project] Polymorph depends on Sound

by John M McIntosh

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 = = = ========================================================================

July 28, 2009

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

by Mariano Martinez Peck

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 >

July 28, 2009

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

by Miguel CobÃ¡

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 >

July 28, 2009

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

by Mariano Martinez Peck

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 >

July 28, 2009

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

by Adrian Lienhard

We have OSPlatform. For instance: MacOSXPlatform isActivePlatform 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

July 28, 2009

Re: [Pharo-project] Anyone mixing Matlab/Octave and Pharo?

by Schwab,Wilhelm K

Nicolas, Thanks for your reply. I am aware of lapack, and will give it some more consideration. However, I am mostly interested in FFTs, wavelets, and least squares fits; GSL is a nice entry point. Do you have a better recommendation? Recent work leads me to something that could (I think) be expressed as a non-linear least squares fit on complex valued functions. Options include finding something that can crunch the problem as-is, which Octave might be able to do, and doing a lot of algebra to reduce everything (which I again _think_ is possible) to real-valued functions and then turn GSL's Levenberg-Marquardt algorithm loose on it. Mapping GSL into Dolphin was not a small job and is not by any means complete, though I was able to automate parts of it. The result is nice, because the I/O, memory management and algorithms can be done in Smalltalk, and compiled C/C++ does the tight loops that would be slow in Smalltalk. Presumably, Octave would offer a similar mix of fast basic routines and a relatively slow interpreter making the calls. The snag is that suddenly everything degrades from the usual benefits of Smalltalk. Driving the Octave interpreter is a possibility, but I wonder whether it would turn into an exercise in writing Octave scripts. My preference (at the risk of repeating myself) is to do the I/O and logic in Smalltalk and leave the number crunching stepss to something called from Smalltalk. An example would be f := SampledFunction loadFrom:'file.name'. fft := f copy fourierTransformForward. "do something to the transform" ^fft copy fourierTransformBackward. Of coruse, exactly what/when to copy and when to modify in place depends on the algorithm and goals. Any ideas on whether such a thing would be possible with the octave interpreter? I fear it would all turn into programming in Octave vs. programming in Smalltalk. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Monday, July 27, 2009 4:52 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Anyone mixing Matlab/Octave and Pharo? Hi Bill, I tried to port Smallapack - a Smalltalk interface to Lapack - into squeak but never finished it... google it if you have time to loose. It works on VW and Dolphin yet. In squeak, I have chosen to use FFI, but maybe it would have been more secure to generate a VM plugin... As you may know, Lapack is a very stable robust and public domain algebra library used for example in Matlab, Octave, Scilab, etc... It is my number one choice far above gsl. Now the idea to go thru octave interpreter might work as well. You may however loose some time in interpreting inputs/outputs back and forth... Depends on the volume of I/O you are planning. I presume there is also an access possible to an octave engine doable via plugin/FFI, passing directly Octave objects to Octave functions... Nicolas 2009/7/24 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > Are any of you doing scientific computing on Pharo? Â I have some seriously old Numerical Recipes code that I altered and compiled, and more recently have used the GNU Scientific Library. Â All of that is connected to Dolphin, and it will take some time to adapt it to Pharo. Â Even more recently, I found reason to exceed GSL's feature list, and Octave might be able to do the job. > > The first thing would be do the minimum work to get some data into Octave and see how it does. Â Ideally, I would want to pipe data into Octave, get results from it, and then do some post-processing in Pharo. Â In GSL (dll/so) terms, the idea is to do all of the memory management and algorithm level work in Smalltalk, and the tight loops via the external code, and hopefully to do all of that w/o littering the drive with temporary files. > > Any experience, good or bad, in those directions? > > Bill > > > > > > _______________________________________________ > 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