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

Re: [Pharo-project] [squeak-dev] Re: Just a little point

by Keith Hodges

Janko MivÅ¡ek wrote: > Sorry Keith, but I must say this: > > The obvious reason Pharoers reject your contributions are not > contributions as such but your attitude as the contributor. And I'd do > the same, reject them, because they are dangerous. Because they bring > you and your attitude with them. > > Please think that way a bit. For the sake of Squeak community and our > progress. And for the sake of your work at the end. Changing your > attitude will change the acceptance of your work too, be sure! > > Best regards > Janko Janko, with respect this situation did not happen overnight. It started to go down hill when I was forced to re-merge a simple submission into seaside 3+ times, the submission was summarily rejected with out explanation or discussion. Have a look at magritte-model in the magritte repository, and you will see a typical example. A trivial submission made in good faith. best regards Keith

July 7, 2009

Re: [Pharo-project] Fwd: about sensor vs. InputSensor in primitiveError:

by StÃ©phane Ducasse

>>> should not this method use InputSensor? > > Sensor is a global pointing to the current sensor instance. > > Michael > P.S. We should remove the old Sensor classes to avoid confusion. what is the "old sensor class" ? so we have Sensor -> to InputSensor default or InputEventSensor?

July 7, 2009

Re: [Pharo-project] Fwd: issue 348

by StÃ©phane Ducasse

Hi Pavel > Hi, > > every UIManager may have its own preference about this behaviour > (for example the dummy ui manager has no user input). It is cleaner > solution than to set interactivity for every Compiler instance or > for the Compiler class. In fact I have the impression that this is the same pattern than with preference class. We are now making sure that the Preference layer can be remove by removing references from within the package to the Preference class and we turn into a flow from the preference class to push value to the tools default value. Similarly we prefer that the UIManager pushes information to the compiler and not that the compiler rely on UIManager. I would like to think about a Compiler been able to run standalone without UI. Now we could have UIManager>> setUpForNonInteraction Compiler setInNonInteractiveMode ,... other class and Compiler code referring to itself (its value for non interaction) This way we could even remove completely the UIManager. Else I think that UIManager will become another huge facade that we cannot remove. > > Cheers, > -- Pavel > > > On Tue, Jul 7, 2009 at 7:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > pavel I was wondering why you want to have interactiveParserFor: in > UIManager and not in Compiler? > > May be I missed something but I'm ready to learn. > > Stef > > > > > On Jul 7, 2009, at 7:18 PM, StÃ©phane Ducasse wrote: > > > > > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> > > Date: July 6, 2009 2:26:56 PM CEDT > > To: stephane ducasse <stephane.ducasse(a)free.fr> > > Subject: issue 348 > > > > Hi Stef, > > > > I updated the issue http://code.google.com/p/pharo/issues/detail? > > id=348 > > > > Cheers, > > -- Pavel > > > > > > > > > > _______________________________________________ > > 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 7, 2009

Re: [Pharo-project] [squeak-dev] Re: Just a little point

by Janko MivÅ¡ek

Sorry Keith, but I must say this: The obvious reason Pharoers reject your contributions are not contributions as such but your attitude as the contributor. And I'd do the same, reject them, because they are dangerous. Because they bring you and your attitude with them. Please think that way a bit. For the sake of Squeak community and our progress. And for the sake of your work at the end. Changing your attitude will change the acceptance of your work too, be sure! Best regards Janko Keith Hodges pravi: >> If find it weird that 2 Smalltalk implementations/communities, so >> close to each other like Squeak and Pharo, go to great lengths at >> flaming each other... > > No they don't, it's just me. > > Please don't tar the mostly polite squeak-dev with my brush. > > I spent a lot of time working on stuff that pharo could use, > particularly because a lot of it was Stephane's idea in the first place, > going back to August 2006. > > My two main points of contention are Monticello and SUnit but as you can > see there are others. > > Monticello: I put a LOT, read LOTS of effort into joining the 3+ > Monticello forks into one, and assuring that it loads in to all forks of > squeak, as a strategic approach for the whole community to have common > tools everywhere. > Pharo has made that effort a waste of time, simply because they wont use > or contribute to the merged uber-Monticello. > > SUnit: I put a second lot of effort into improving SUnit so that it > could support multiple forks of squeak simultaneously. I also wrote a > non Gui test runner for automated testing. SUnit is a public resource > and is maintained in a public repository. Pharo have needlessly forked > SUnit. > > Several things that wind me up, one is wasted effort, and another is > duplicated effort, and the third is making plans to duplicate effort on > purpose. >> that will only leave us isolated, both in our own camps ? I'm >> puzzled! What do I do if I like both? Choose my camp or abandon them >> both ? > If you like both, then please encourage them to make parts that could be > common common. For example I maintain ProcessSpecific for Logging, Pharo > has integrated ProcessSpecific but has made no attempt to pick or offer > feedback to version that was maintained. This is one of numerous example > of subsystems that could easily be mutually maintained. > > There are many initiatives in the pharo camp, that could be developed > and deployed into both camps. I spent all that time on Monticello in > order to ensure that this could happen, but pharo only develops > initiatives for itself, therefore Pharo is effectively planning for > duplicated effort. > > One more example, Pharo could come up with an initiative to fix the > sources/changes file mess. This would be very benefitcial to me. However > its no good if I cant load it into squeak where a lot of my code runs. > So at some point someone would have to duplicate the effort for Squeak. > All it would take is a little thought and planning. > > When I took the initiative to write Rio as a replacement for > FileDirectory, I did it in such a way as anyone could benefit. > When I took the initiative to write Logging as a potential core feature > for Kernel/Server images I did it so that anyone could benefit. > When I wrote the TestReporter as a text based tool for testing I did it > so that anyone could benefit. > When I wrote Bob for automated image building and testing I have done it > so that it can build any image. > When I wrote Sake for rake like functionality it loads into any image. > When I wrote Sake/Packges for managing packges dependencies I did it so > that any image can benefit. > > I dont know what initiatives pharo has completed, but, and please do > correct me if I am wrong. I havent seen a single initiative from pharo > that has been developed and deployed so that everyone could benefit. > > best regards > > Keith -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

Oh, just something I forgot to mention: ScaledDecimal should behave the way you expect. 1.3s1 = (13/10). -> true. 1.3s2*1.3s2 = 1.69s2. -> true 1.3 * 1.3 = 1.69. -> false Nicolas 2009/7/7 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Hi Hernan, > This is the new Behavior of Float comparison and it is desired. > > 1) 1.3 is represented in machine as > (1.3 significandAsInteger printStringRadix: 2) , '.0e' , (1.3 exponent > - Float precision + 1) printString. > -> '2r10100110011001100110011001100110011001100110011001101.0e-52' > > Or if you prefer: > (1.3 asTrueFraction numerator printStringBase: 2) , '/' , (1.3 > asTrueFraction denominator printStringBase: 2). > -> '10100110011001100110011001100110011001100110011001101/10000000000000000000000000000000000000000000000000000' > > As you can see, this is quite different from 13/10. > > However, you can test (13/10) asFloat = 1.3 and that happens to be > true, but that won't always be true. > > 2) comparing Float with strict equality is a dangerous game. Floating > point operation are inherently inexact and thus asserting an exact > equality is considered a bad practice. > > 3) basing comparisons and equality tests on inexact arithmetic rather > than on exact arithmetic leads to weird behaviours. See > http://bugs.squeak.org/view.php?id=3374 > > > So i do not consider this fragment of code alone as a bug but as a feature. > There might be some code depending on the old behaviour that can > eventually break. > If you have such an example in true application, I'm interested. > I think we'd better fix such code to not rely on exact equality... > > Cheers. > > Nicolas > > > > 2009/7/7 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> I added this new issue that happens on the latest image. >> I'm posting it here because I think it is an important bug because it >> affects the number model. >> The problem is related with all fractions who's denominator is not power of >> two. (130/100 = 1.3 or 1/5 = 0.2, etc) >> (See >> >> Float>>adaptToFraction: rcvr andCompare: selector where it does >> Â Â .... >> Â Â "Try to avoid asTrueFraction because it can cost" >> Â Â selector == #= ifTrue: [ >> Â Â Â rcvr denominator isPowerOfTwo ifFalse: [^false]]. >> >> Â Â ...) >> >> >> Hernan. >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

July 7, 2009

Re: [Pharo-project] Just a little point

by Keith Hodges

Reinout Heeck wrote: >> Pharo continues with a not invented here policy, and has made no >> attempt >> to review the code based for projects that could be mutually >> maintained. >> > > I think it is a misanalysis to label that NIH, there are quite > different factors contributing to the lack of pushing contributions > upstream. > > Fail to plan, plan to fail? > As it happens your timing is unfortunate in that a discussion was just > kindled here on which processes and mechanisms to put in place to > solve this issue. > Unfortunately a lot of messages have been posted here to the effect of > making statements without proposing solutions, washing out the > original constructive thread. > It is the fact that proposed solutions have been ignored that brings me to raise these issues. I am not just meaning technical solutions, I primarily mean philosophical and process solutions. I started working on the technical solutions for this very problem 3 years ago with Stephanes encouragement. Finally I am glad that someone is considering looking at it. >> This is not a fighting attitude, its a pragmatic attitude aiming to >> help >> people to avoid wasting their time and effort. >> > > It would help if the balance of the message traffic moved from > pointing out problems towards discussing solutions > I have been discussing solutions all along. Monticello is our bread and butter for exchanging code, we all want it to be better, we all want it to work everywhere. So it is a strategic choice to chose to adopt and contribute to one implementation of Monticello that is being actively maintained (was - since pharo isnt using it I have stopped maintaining it). SUnit is our bread and butter for testing code, we all want it to work, we all want our tests to be compatible accross forks, we all want as many green tests as possible with as few false negatives as possible. Some of us would like to branch out to use SSpec for testing/design purposes. Many of us would like to have an automated test server, with periodic offline testing. www.squeaksource.com/Testing was established to address these very same issues. We want a minimal image, that we can pull things out of and reliably put things back into no matter what image we are using even if it doesnt yet have a GUI. In a multifork world we need to capture the knowledge of what works where, and what patches are needed to make things work where. Sake/Packages was developed for this purpose. I look forward to good things from your discussions. etc etc etc Keith

July 7, 2009

Re: [Pharo-project] Just a little point

by Keith Hodges

> > Pharo continues with a not invented here policy, and has made no attempt > to review the code based for projects that could be mutually maintained. > This is a problem, and I shall continue to point it out until it is > resolved. It's a mindset issue. > > I would like to make my point in a different polite way. If you are the maintainer of a package and, in this multi-fork world, you would like to maintain a single test suite for both squeak and pharo, such that all tests run green, then the SUnit in squeaksource.com/Testing may be for you. It was developed for a multi-fork world back in August/Sept 2006. It allows you to categorise which tests you expect to work on which platform and which image version. It is a multi-fork world out there, why not think it through? Keith

July 7, 2009

Re: [Pharo-project] Issue 940: (13/10) = 1.3 returns false

by Nicolas Cellier

Hi Hernan, This is the new Behavior of Float comparison and it is desired. 1) 1.3 is represented in machine as (1.3 significandAsInteger printStringRadix: 2) , '.0e' , (1.3 exponent - Float precision + 1) printString. -> '2r10100110011001100110011001100110011001100110011001101.0e-52' Or if you prefer: (1.3 asTrueFraction numerator printStringBase: 2) , '/' , (1.3 asTrueFraction denominator printStringBase: 2). -> '10100110011001100110011001100110011001100110011001101/10000000000000000000000000000000000000000000000000000' As you can see, this is quite different from 13/10. However, you can test (13/10) asFloat = 1.3 and that happens to be true, but that won't always be true. 2) comparing Float with strict equality is a dangerous game. Floating point operation are inherently inexact and thus asserting an exact equality is considered a bad practice. 3) basing comparisons and equality tests on inexact arithmetic rather than on exact arithmetic leads to weird behaviours. See http://bugs.squeak.org/view.php?id=3374 So i do not consider this fragment of code alone as a bug but as a feature. There might be some code depending on the old behaviour that can eventually break. If you have such an example in true application, I'm interested. I think we'd better fix such code to not rely on exact equality... Cheers. Nicolas 2009/7/7 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > I added this new issue that happens on the latest image. > I'm posting it here because I think it is an important bug because it > affects the number model. > The problem is related with all fractions who's denominator is not power of > two. (130/100 = 1.3 or 1/5 = 0.2, etc) > (See > > Float>>adaptToFraction: rcvr andCompare: selector where it does > .... > "Try to avoid asTrueFraction because it can cost" > selector == #= ifTrue: [ > rcvr denominator isPowerOfTwo ifFalse: [^false]]. > > ...) > > > Hernan. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 7, 2009

Re: [Pharo-project] Just a little point

by Reinout Heeck

> > Pharo continues with a not invented here policy, and has made no > attempt > to review the code based for projects that could be mutually > maintained. I think it is a misanalysis to label that NIH, there are quite different factors contributing to the lack of pushing contributions upstream. > This is a problem, and I shall continue to point it out until it is > resolved. It's a mindset issue. As it happens your timing is unfortunate in that a discussion was just kindled here on which processes and mechanisms to put in place to solve this issue. Unfortunately a lot of messages have been posted here to the effect of making statements without proposing solutions, washing out the original constructive thread. > This is not a fighting attitude, its a pragmatic attitude aiming to > help > people to avoid wasting their time and effort. It would help if the balance of the message traffic moved from pointing out problems towards discussing solutions. R -

July 7, 2009

Re: [Pharo-project] Fwd: issue 348

by Pavel Krivanek

Hi, every UIManager may have its own preference about this behaviour (for example the dummy ui manager has no user input). It is cleaner solution than to set interactivity for every Compiler instance or for the Compiler class. Cheers, -- Pavel On Tue, Jul 7, 2009 at 7:22 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > pavel I was wondering why you want to have interactiveParserFor: in > UIManager and not in Compiler? > > May be I missed something but I'm ready to learn. > > Stef > > > > > On Jul 7, 2009, at 7:18 PM, StÃ©phane Ducasse wrote: > > > > > From: Pavel Krivanek <pavel.krivanek(a)gmail.com> > > Date: July 6, 2009 2:26:56 PM CEDT > > To: stephane ducasse <stephane.ducasse(a)free.fr> > > Subject: issue 348 > > > > Hi Stef, > > > > I updated the issue http://code.google.com/p/pharo/issues/detail? > > id=348 > > > > Cheers, > > -- Pavel > > > > > > > > > > _______________________________________________ > > 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 7, 2009