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

Re: [Pharo-project] Draft streams proposal on the Wiki

by StÃ©phane Ducasse

buzy :) Stef On Aug 12, 2009, at 3:25 PM, Schwab,Wilhelm K wrote: > Stef, > > You have not responded that I can see. Are you just busy, didn't > see it, or is it such a crushing disappointment you don't know where > to start? :) > > I am simply seeking some guidance on how it should evolve to be > useful to you. > > Bill > > > > -----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: Monday, August 10, 2009 10:11 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Draft streams proposal on the Wiki > > Stef, > > Please take a quick look at the StreamsForRobustSoftware page on the > Wiki. It needs a lot of work, but any hints about how to make it > meet your needs would be appreciated. > > 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

Aug. 12, 2009

Re: [Pharo-project] right button still doesn't work on Windows

by Adrian Lienhard

We need to change the startup list such that the InputEventSensor comes after OSPlatform. This can be done in InputEventSensor class>>initialize. Will do that in one of the next updates. Adrian On Aug 12, 2009, at 15:26 , Mariano Martinez Peck wrote: > 2009/8/12 Andrew Tween <amtween(a)hotmail.com> > >> Hi Mariano, >> You are not alone. >> I also get this problem on Windows (Vista) with >> Pharo1.0betaCore-10401. >> >> The cause of the problem is this... >> >> Both OSPlatform and InputEventSensor are in the Smalltalk >> StartUpList. >> It is ESSENTIAL that OSPlatform's startup code runs BEFORE >> InputEventSensor's startup code. >> >> This is because installMouseDecodeTable calls "Preferences >> swapMouseButtons", which in turn calls "OSPlatform current >> platformFamily". >> The OSPlatform startup code sets "OSPlatform Current" to a new >> instance >> representing the current platform. >> >> If InputEventSensor startup runs BEFORE OSPlatform's startup, then >> "OSPlatform current" will be an instance representing the Operating >> System >> on which the image was SAVED. (This explains why saving the image and >> restarting solves the problem) >> >> Try evaluating this in an image with the right mouse button not >> working... >> >> ((SystemDictionary classPool at: 'StartUpList') indexOf: >> #OSPlatform) < >> ((SystemDictionary classPool at: 'StartUpList') indexOf: >> #InputEventSensor). >> >> It should be true, but will evaluate to false. >> >> Now evaluate... >> >> OSPlatform initialize. >> ((SystemDictionary classPool at: 'StartUpList') indexOf: >> #OSPlatform) < >> ((SystemDictionary classPool at: 'StartUpList') indexOf: >> #InputEventSensor). >> >> It is now true - the startups are in the correct order. >> >> I guess that the solution is to build a new core image with the >> startup >> order repaired by evaluating "OSPlatform initialize." >> >> > > WOW! Nice debugging!! Thanks for the help. Now I wonder, where to > put that > "OSPlatform initialize." . This may be evaluated when an image is > generated? > > What about adding that in something like "ScriptLoader > cleanUpForRelease" ? > > Best, > > Mariano > > >> Cheers, >> Andy >> >> "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote in message >> news:a38fadc50908111224p181c8408qd8c6161229bcae90@mail.gmail.com... >> >> >> On Tue, Aug 11, 2009 at 6:15 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >> >>> Can you reproduce this with a fresh Pharo-core? >>> >>> It would be interesting to know whether the method is run at startup >>> in your image. It is run as expected in my image (latest pharo- >>> core). >>> Could you add a halt in #installMouseDecodeTable save and restart >>> the >>> image? >> >> >> Yes, I did that. Clean pharo beta core. The situation is this: >> >> When you first open the image, it doesn't work. However, if you >> save it >> (without doing nothing) and open it again, it start working (even >> when not >> evaluating InputEventSensor installMouseDecodeTable) >> >> I am alone? >> >> best, >> >> mariano >> >> >>> >>> Adrian >>> >>> On Aug 11, 2009, at 20:38 , Mariano Martinez Peck wrote: >>> >>>> On Tue, Aug 11, 2009 at 5:29 PM, Adrian Lienhard < >>> adi-cTM//Nd5/DIfv37vnLkPlQ(a)public.gmane.org <adi(a)netstyle.ch>> >>> >>>> wrote: >>>> >>>>> What I don't understand is why InputEventSensor >>>>> installMouseDecodeTable would solve the problem because this >>>>> method >>>>> is >>>>> run at startup... >>>> >>>> >>>> I really don't know, but works :( >>>> >>>> >>>>> >>>>> >>>>> Adrian >>>>> >>>>> On Aug 11, 2009, at 20:19 , Torsten Bergmann wrote: >>>>> >>>>>>> With Pharo beta, right button still doesn't work out of the box >>>>>>> in Windows. >>>>>> >>>>>> Mariano, can you try the installer executable on >>>>>> http://pharo-project.org/pharo-download ? >>>>>> >>>>>> For me right button work out of the box on XP and Vista and the >>>>>> installer uses the same image as Damien provides on the download >>>>>> site. >>>>>> >>>>>> Bye >>>>>> Torsten >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla >>>>>> Firefox 3 - >>>>>> sicherer, schneller und einfacher! >>> http://portal.gmx.net/de/go/atbrowser >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr<Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org >>>>>> > >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr<Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org >>>>> > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr<Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org >>>> > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr<Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org >>> > >>> 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

Aug. 12, 2009

Re: [Pharo-project] right button still doesn't work on Windows

by Mariano Martinez Peck

2009/8/12 Andrew Tween <amtween(a)hotmail.com> > Hi Mariano, > You are not alone. > I also get this problem on Windows (Vista) with Pharo1.0betaCore-10401. > > The cause of the problem is this... > > Both OSPlatform and InputEventSensor are in the Smalltalk StartUpList. > It is ESSENTIAL that OSPlatform's startup code runs BEFORE > InputEventSensor's startup code. > > This is because installMouseDecodeTable calls "Preferences > swapMouseButtons", which in turn calls "OSPlatform current platformFamily". > The OSPlatform startup code sets "OSPlatform Current" to a new instance > representing the current platform. > > If InputEventSensor startup runs BEFORE OSPlatform's startup, then > "OSPlatform current" will be an instance representing the Operating System > on which the image was SAVED. (This explains why saving the image and > restarting solves the problem) > > Try evaluating this in an image with the right mouse button not working... > > ((SystemDictionary classPool at: 'StartUpList') indexOf: #OSPlatform) < > ((SystemDictionary classPool at: 'StartUpList') indexOf: #InputEventSensor). > > It should be true, but will evaluate to false. > > Now evaluate... > > OSPlatform initialize. > ((SystemDictionary classPool at: 'StartUpList') indexOf: #OSPlatform) < > ((SystemDictionary classPool at: 'StartUpList') indexOf: #InputEventSensor). > > It is now true - the startups are in the correct order. > > I guess that the solution is to build a new core image with the startup > order repaired by evaluating "OSPlatform initialize." > > WOW! Nice debugging!! Thanks for the help. Now I wonder, where to put that "OSPlatform initialize." . This may be evaluated when an image is generated? What about adding that in something like "ScriptLoader cleanUpForRelease" ? Best, Mariano > Cheers, > Andy > > "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote in message > news:a38fadc50908111224p181c8408qd8c6161229bcae90@mail.gmail.com... > > > On Tue, Aug 11, 2009 at 6:15 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> Can you reproduce this with a fresh Pharo-core? >> >> It would be interesting to know whether the method is run at startup >> in your image. It is run as expected in my image (latest pharo-core). >> Could you add a halt in #installMouseDecodeTable save and restart the >> image? > > > Yes, I did that. Clean pharo beta core. The situation is this: > > When you first open the image, it doesn't work. However, if you save it > (without doing nothing) and open it again, it start working (even when not > evaluating InputEventSensor installMouseDecodeTable) > > I am alone? > > best, > > mariano > > >> >> Adrian >> >> On Aug 11, 2009, at 20:38 , Mariano Martinez Peck wrote: >> >> > On Tue, Aug 11, 2009 at 5:29 PM, Adrian Lienhard < >> adi-cTM//Nd5/DIfv37vnLkPlQ(a)public.gmane.org <adi(a)netstyle.ch>> >> >> > wrote: >> > >> >> What I don't understand is why InputEventSensor >> >> installMouseDecodeTable would solve the problem because this method >> >> is >> >> run at startup... >> > >> > >> > I really don't know, but works :( >> > >> > >> >> >> >> >> >> Adrian >> >> >> >> On Aug 11, 2009, at 20:19 , Torsten Bergmann wrote: >> >> >> >>>> With Pharo beta, right button still doesn't work out of the box >> >>>> in Windows. >> >>> >> >>> Mariano, can you try the installer executable on >> >>> http://pharo-project.org/pharo-download ? >> >>> >> >>> For me right button work out of the box on XP and Vista and the >> >>> installer uses the same image as Damien provides on the download >> >>> site. >> >>> >> >>> Bye >> >>> Torsten >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla >> >>> Firefox 3 - >> >>> sicherer, schneller und einfacher! >> http://portal.gmx.net/de/go/atbrowser >> >>> >> >>> _______________________________________________ >> >>> Pharo-project mailing list >> >>> Pharo-project(a)lists.gforge.inria.fr<Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org> >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr<Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr<Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<Pharo-project-bM+ny+RY8h+a+bCvCPl5/gCzwTLBPCX0(a)public.gmane.org> >> 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 >

Aug. 12, 2009

Re: [Pharo-project] Draft streams proposal on the Wiki

by Schwab,Wilhelm K

Stef, You have not responded that I can see. Are you just busy, didn't see it, or is it such a crushing disappointment you don't know where to start? :) I am simply seeking some guidance on how it should evolve to be useful to you. Bill -----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: Monday, August 10, 2009 10:11 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Draft streams proposal on the Wiki Stef, Please take a quick look at the StreamsForRobustSoftware page on the Wiki. It needs a lot of work, but any hints about how to make it meet your needs would be appreciated. Bill _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 12, 2009

[Pharo-project] Croquet - was Sideways marketing of pharo, seaside, etc.

by Schwab,Wilhelm K

Stef, I don't dispute it, but what is this about Croquet being dead? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Wednesday, August 12, 2009 2:22 AM To: Pharo-project(a)lists.gforge.inria.fr; lenglish5(a)cox.net Subject: Re: [Pharo-project] Sideways marketing of pharo, seaside, etc. On Aug 12, 2009, at 2:39 AM, Lawson English wrote: > Hey all, I'm in one of my manic brainstorming moods and whilest I'm > working on a baby interface between Second Life and Squeak, it dawns > on me that there is a huge potential for evangelicalism on your part > here: > One of hte myriad complains Second LIfe power users have is that the > build-in programming tools are extremely limited. There are numerous > options for plugins as with Eclipse and emacs (I believe) but they all > run as standalone tools with no easy integration with the 3D virtual > world experience, which is hte main reason why people bother to script > things in SL in the first place: they have interactive feedback with > potentialky thousands of other people. > > The point being that seaside runs just fine on localhost and the > builtin SL browser works just fine with everything seaside I have > tested. what do you mean by the previous sentence? > If someone wanted to entice potentially 100,000 Second LIfe users to > install seaside, implementing a nice LSL scripting interface in a > seaside webpage, complete with syntax coloring, databases of scripts, > version control, etc etc, would go a long way toards convincing the > Second Life powerusers, at least, that seaside is a worthwhile > install. > > If/when I get my interface to the client-server packets proxy working, > one could see potential for many more elaborate uses for squeak/ > seaside and Second LIfe. Keep us informed it looks exciting. > (interop between SL and Cobalt/Croquet is left as an exercise for the > reader ;-)) I thought Croquet was dead as an open-source project. > Anyway, if someone with a talent for writing editor code wanted to > look at the existing external LSL scripting editors and port something > to squeak for use on a webpage in seaside, I can almost promise you > that squeak/seaside useage would go up by a huge, HUGE factor. Such a > project is beyond me, personally due to my lack of formal education, > etc., but it should be a worthy project for anyone wishing to promote > seaside/smalltalk use. May be this is a nice job for helvetia. Lukas? mixing SL in Smalltalk :) > Feel free to ask any questions, privately if appropriate. > > Lawson English LEnglish5 (at) cox [dot] net Saijanai Kuhn in Second > Life > > > > > > > > > > _______________________________________________ > 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

Aug. 12, 2009

Re: [Pharo-project] [squeak-dev] Squeak 4.x should adopt Pharo 1.0

by Mariano Martinez Peck

On Wed, Aug 12, 2009 at 6:28 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Mariano > what do you mean that you cannot copy? Someone said that he couldn't copy and I just said that here in Linux I can perfectly copy and paste :) > > > > > Pharo1.0beta latest update: #10413. > > > > BTW: it's not possible to copy text from the About this System > > Dialog... > > > > Here in Linux works using ctrl + c not only to a workspace (inside > > image) but also to an external program. > > > > > > > > > > Em 11/08/2009 19:05, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > > > escreveu: > > > > > > Which image are you using? > > Because on mine = core 10371 > > deprecatedWarning = on > > I do not get them. > > > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 12, 2009

Re: [Pharo-project] Complex neurotic

by Schwab,Wilhelm K

Sig, +1+0.000000001i :) The small imaginary part is due to my concern over calling complex numbers "non-scalars." In what sense do you mean that? They are indeed used as a field of scalars for vector spaces. That sticking point aside, they are different, and I agree they would be best treated somewhat separately, so that -1 sqrt is an error, -1 asComplex sqrt gives a complex (pure imaginary) result. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Wednesday, August 12, 2009 3:16 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex neurotic 2009/8/12 Ken.Dickey <Ken.Dickey(a)whidbey.com>: >> AFAIK, one has to be careful ordering complex numbers: > > I am aware of this. Â There are a large number of ways to define #< for > complex numbers -- and a large number of problems with each of them. > > What I object to are bad behaviors for things which are perfectly well > defined. > > Currently: > > -1 asComplex isNumber --> true > Â 1 asComplex isNumber -> true > -1 asComplex < 1 asComplex --> error > > -4 sqrt --> error and it should. Not many people using a complex numbers. And -4 is an integer number, not complex number (i hope this non-objectionable?). And sqrt function is not defined for real/integer numbers < 0 ,and should lead to error, period. If you change this behavior, some of code will fail to work correctly , definitely. But you are free to use something like: -4 asComplex sqrt > -3 ln -> NaN > same as above, use it as: -3 asComplex ln. >> If in doubt, I would #shouldNotImplement #< until we can get a >> conclusive answer. > > An answer to what? Â I wrote the test cases first and then did code to > make the tests pass. > > I am certainly open to alternate definitions, but I think if an object > answers true to isNumber it should behave as a number. > > What would you expect of the following? > > -1 asFloat < 1 asFloat. > -1 asNumber < 1 asNumber. > -1 asFraction < 1 asFraction. > -1 asComplex < 1 asComplex. > i personally, don't see any reason why bother defining an ordering operator for non-scalar value(s). Complex numbers is not scalars and ordering operator having a little sense on vectors (however you can find its defined in Point protocol). I really wonder, where #<, #> could be used for Point(s), or vectors in general? And there always will be questions how to define them. As for complex numbers, i wonder , what is correct answer in comparison between real number and any complex number (and moreover, what is the mathematical meaning of such comparison?), because if you introducing it, you can expect someone to compare occasionally: (a * x) < (b * x) where a,b,x could be either complex or real numbers, and #* behavior could turn the complex number to real for one side, but not for another one. > > One can add checks and make off-axis complex numbers fail (why?), but > why cause the last case above to fail? > > Smalltalk is known for reasonable behaviors. Â E.g in Java (1/2) + > (1/3) + 1/6) can yield zero (integer division truncates). Â I much > prefer to get an exact 1. > > Why should I expect complex numbers to be unreasonable? > They shoudn't, just keep real numbers be reasonable in parallel :) > $0.02, > -KenD > > _______________________________________________ > 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

Aug. 12, 2009

Re: [Pharo-project] Complex neurotic

by Igor Stasenko

2009/8/12 Ken.Dickey <Ken.Dickey(a)whidbey.com>: >> AFAIK, one has to be careful ordering complex numbers: > > I am aware of this. Â There are a large number of ways to define #< for complex > numbers -- and a large number of problems with each of them. > > What I object to are bad behaviors for things which are perfectly well > defined. > > Currently: > > -1 asComplex isNumber --> true > Â 1 asComplex isNumber -> true > -1 asComplex < 1 asComplex --> error > > -4 sqrt --> error and it should. Not many people using a complex numbers. And -4 is an integer number, not complex number (i hope this non-objectionable?). And sqrt function is not defined for real/integer numbers < 0 ,and should lead to error, period. If you change this behavior, some of code will fail to work correctly , definitely. But you are free to use something like: -4 asComplex sqrt > -3 ln -> NaN > same as above, use it as: -3 asComplex ln. >> If in doubt, I would #shouldNotImplement #< until we can get a conclusive >> answer. > > An answer to what? Â I wrote the test cases first and then did code to make the > tests pass. > > I am certainly open to alternate definitions, but I think if an object answers > true to isNumber it should behave as a number. > > What would you expect of the following? > > -1 asFloat < 1 asFloat. > -1 asNumber < 1 asNumber. > -1 asFraction < 1 asFraction. > -1 asComplex < 1 asComplex. > i personally, don't see any reason why bother defining an ordering operator for non-scalar value(s). Complex numbers is not scalars and ordering operator having a little sense on vectors (however you can find its defined in Point protocol). I really wonder, where #<, #> could be used for Point(s), or vectors in general? And there always will be questions how to define them. As for complex numbers, i wonder , what is correct answer in comparison between real number and any complex number (and moreover, what is the mathematical meaning of such comparison?), because if you introducing it, you can expect someone to compare occasionally: (a * x) < (b * x) where a,b,x could be either complex or real numbers, and #* behavior could turn the complex number to real for one side, but not for another one. > > One can add checks and make off-axis complex numbers fail (why?), but why > cause the last case above to fail? > > Smalltalk is known for reasonable behaviors. Â E.g in Java (1/2) + (1/3) + 1/6) > can yield zero (integer division truncates). Â I much prefer to get an exact > 1. > > Why should I expect complex numbers to be unreasonable? > They shoudn't, just keep real numbers be reasonable in parallel :) > $0.02, > -KenD > > _______________________________________________ > 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.

Aug. 12, 2009

Re: [Pharo-project] right button still doesn't work on Windows

by Adrian Lienhard

That explains it! Thanks for figuring out, Andrew. I reopened http://code.google.com/p/pharo/issues/detail?id=838 Adrian On Aug 12, 2009, at 09:54 , Andrew Tween wrote: > Hi Mariano, > You are not alone. > I also get this problem on Windows (Vista) with > Pharo1.0betaCore-10401. > > The cause of the problem is this... > > Both OSPlatform and InputEventSensor are in the Smalltalk StartUpList. > It is ESSENTIAL that OSPlatform's startup code runs BEFORE > InputEventSensor's startup code. > > This is because installMouseDecodeTable calls "Preferences > swapMouseButtons", which in turn calls "OSPlatform current > platformFamily". > The OSPlatform startup code sets "OSPlatform Current" to a new > instance representing the current platform. > > If InputEventSensor startup runs BEFORE OSPlatform's startup, then > "OSPlatform current" will be an instance representing the Operating > System on which the image was SAVED. (This explains why saving the > image and restarting solves the problem) > > Try evaluating this in an image with the right mouse button not > working... > > ((SystemDictionary classPool at: 'StartUpList') indexOf: > #OSPlatform) < ((SystemDictionary classPool at: 'StartUpList') > indexOf: #InputEventSensor). > > It should be true, but will evaluate to false. > > Now evaluate... > > OSPlatform initialize. > ((SystemDictionary classPool at: 'StartUpList') indexOf: > #OSPlatform) < ((SystemDictionary classPool at: 'StartUpList') > indexOf: #InputEventSensor). > > It is now true - the startups are in the correct order. > > I guess that the solution is to build a new core image with the > startup order repaired by evaluating "OSPlatform initialize." > > Cheers, > Andy > "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote in message news:a38fadc50908111224p181c8408qd8c6161229bcae90@mail.gmail.com > ... > > > > On Tue, Aug 11, 2009 at 6:15 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > > Can you reproduce this with a fresh Pharo-core? > > It would be interesting to know whether the method is run at > startup > in your image. It is run as expected in my image (latest pharo- > core). > Could you add a halt in #installMouseDecodeTable save and restart > the > image? > > Yes, I did that. Clean pharo beta core. The situation is this: > > When you first open the image, it doesn't work. However, if you > save it (without doing nothing) and open it again, it start working > (even when not evaluating InputEventSensor installMouseDecodeTable) > > I am alone? > > best, > > mariano > > > Adrian > > > On Aug 11, 2009, at 20:38 , Mariano Martinez Peck wrote: > >> On Tue, Aug 11, 2009 at 5:29 PM, Adrian Lienhard <adi(a)netstyle.ch> >> wrote: >> >>> What I don't understand is why InputEventSensor >>> installMouseDecodeTable would solve the problem because this method >>> is >>> run at startup... >> >> >> I really don't know, but works :( >> >> >>> >>> >>> Adrian >>> >>> On Aug 11, 2009, at 20:19 , Torsten Bergmann wrote: >>> >>>>> With Pharo beta, right button still doesn't work out of the box >>>>> in Windows. >>>> >>>> Mariano, can you try the installer executable on >>>> http://pharo-project.org/pharo-download ? >>>> >>>> For me right button work out of the box on XP and Vista and the >>>> installer uses the same image as Damien provides on the download >>>> site. >>>> >>>> Bye >>>> Torsten >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla >>>> Firefox 3 - >>>> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser >>>> >>>> _______________________________________________ >>>> 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

Aug. 12, 2009

Re: [Pharo-project] right button still doesn't work on Windows

by Andrew Tween

Hi Mariano, You are not alone. I also get this problem on Windows (Vista) with Pharo1.0betaCore-10401. The cause of the problem is this... Both OSPlatform and InputEventSensor are in the Smalltalk StartUpList. It is ESSENTIAL that OSPlatform's startup code runs BEFORE InputEventSensor's startup code. This is because installMouseDecodeTable calls "Preferences swapMouseButtons", which in turn calls "OSPlatform current platformFamily". The OSPlatform startup code sets "OSPlatform Current" to a new instance representing the current platform. If InputEventSensor startup runs BEFORE OSPlatform's startup, then "OSPlatform current" will be an instance representing the Operating System on which the image was SAVED. (This explains why saving the image and restarting solves the problem) Try evaluating this in an image with the right mouse button not working... ((SystemDictionary classPool at: 'StartUpList') indexOf: #OSPlatform) < ((SystemDictionary classPool at: 'StartUpList') indexOf: #InputEventSensor). It should be true, but will evaluate to false. Now evaluate... OSPlatform initialize. ((SystemDictionary classPool at: 'StartUpList') indexOf: #OSPlatform) < ((SystemDictionary classPool at: 'StartUpList') indexOf: #InputEventSensor). It is now true - the startups are in the correct order. I guess that the solution is to build a new core image with the startup order repaired by evaluating "OSPlatform initialize." Cheers, Andy "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote in message news:a38fadc50908111224p181c8408qd8c6161229bcae90@mail.gmail.com... On Tue, Aug 11, 2009 at 6:15 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: Can you reproduce this with a fresh Pharo-core? It would be interesting to know whether the method is run at startup in your image. It is run as expected in my image (latest pharo-core). Could you add a halt in #installMouseDecodeTable save and restart the image? Yes, I did that. Clean pharo beta core. The situation is this: When you first open the image, it doesn't work. However, if you save it (without doing nothing) and open it again, it start working (even when not evaluating InputEventSensor installMouseDecodeTable) I am alone? best, mariano Adrian On Aug 11, 2009, at 20:38 , Mariano Martinez Peck wrote: > On Tue, Aug 11, 2009 at 5:29 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >> What I don't understand is why InputEventSensor >> installMouseDecodeTable would solve the problem because this method >> is >> run at startup... > > > I really don't know, but works :( > > >> >> >> Adrian >> >> On Aug 11, 2009, at 20:19 , Torsten Bergmann wrote: >> >>>> With Pharo beta, right button still doesn't work out of the box >>>> in Windows. >>> >>> Mariano, can you try the installer executable on >>> http://pharo-project.org/pharo-download ? >>> >>> For me right button work out of the box on XP and Vista and the >>> installer uses the same image as Damien provides on the download >>> site. >>> >>> Bye >>> Torsten >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla >>> Firefox 3 - >>> sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser >>> >>> _______________________________________________ >>> 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

Aug. 12, 2009