- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo changing the game

by Lukas Renggli

> Now why don;t people want a better smalltalk? Sure, everybody wants a better Smalltalk. The ANSI standard does not make scripting impossible, it does not forbid first class instance variables, it does not forbid a MOP or a module system. The ANSI standard only talks about the basic Smalltalk syntax, Collections, Magnitudes, Streams. That's it. I don't think it is limiting in any way. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 11, 2010

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

Now why don;t people want a better smalltalk? >> get stuck with a ANSI bad standard? > > The ANSI standard is not bad. It is minimal, maybe too minimal? But it > does not forbid anything like #and:and: or Traits. The ANSI standard > gives a minimal common dominator. It is absolutely essential to > projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier, > ... > >> Now Seaside is developed on pharo and run on nearly all the dialects so there >> is a path. It is not easy. > > Because we strictly adhere to the ANSI standard and because we have > our own platform layer called Grease. > > http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 11, 2010

Re: [Pharo-project] 16rff is looking for a fix :)

by StÃ©phane Ducasse

Thanks Stef On Feb 11, 2010, at 10:21 PM, Eliot Miranda wrote: > this in the thread spawned by Torsen's posting of Kent's most excellent rant: > ttp://www.threeriversinstitute.org/blog/?p=466 > > OK, fix is to two implementations of digitValue:. BTW, I haven't fixed Character class>>digitValue: which at least in my Teleplace image looks horribly broken, answering characters not integers. Check your distro, it may also be broken > > These fixes attached: > > 'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 11 February 2010 at 1:17:50 pm'! > !EncodedCharSet class methodsFor: 'class methods' stamp: 'eem 2/11/2010 13:13'! > digitValue: char > "Answer 0-9 if the receiver is $0-$9, 10-35 if it is $A-$Z, and < 0 > otherwise. This is used to parse literal numbers of radix 2-36." > > | value | > value := char charCode. > value <= $9 asciiValue ifTrue: > [^value - $0 asciiValue]. > value >= $A asciiValue ifTrue: > [value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10]. > (value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue: > [^value - $a asciiValue + 10]]. > ^ -1 > ! ! > !Unicode class methodsFor: 'class methods' stamp: 'eem 2/11/2010 13:17'! > digitValue: char > > | value | > value := char charCode. > value <= $9 asciiValue ifTrue: > [^value - $0 asciiValue]. > value >= $A asciiValue ifTrue: > [value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10]. > (value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue: > [^value - $a asciiValue + 10]]. > > value > (DecimalProperty size - 1) ifTrue: [^ -1]. > ^ (DecimalProperty at: value+1) > ! ! > > 2010/2/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <digitValue.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 11, 2010

Re: [Pharo-project] Pharo changing the game

by Lukas Renggli

> Â Â Â Â get stuck with a ANSI bad standard? The ANSI standard is not bad. It is minimal, maybe too minimal? But it does not forbid anything like #and:and: or Traits. The ANSI standard gives a minimal common dominator. It is absolutely essential to projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier, ... > Now Seaside is developed on pharo and run on nearly all the dialects so there > is a path. It is not easy. Because we strictly adhere to the ANSI standard and because we have our own platform layer called Grease. http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 11, 2010

Re: [Pharo-project] 16rff is looking for a fix :)

by Eliot Miranda

this in the thread spawned by Torsen's posting of Kent's most excellent rant: ttp://www.threeriversinstitute.org/blog/?p=466<http://www.threeriversinstitute.org/blog/?p=466> <http://www.threeriversinstitute.org/blog/?p=466>OK, fix is to two implementations of digitValue:. BTW, I haven't fixed Character class>>digitValue: which at least in my Teleplace image looks horribly broken, answering characters not integers. Check your distro, it may also be broken These fixes attached: 'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 11 February 2010 at 1:17:50 pm'! !EncodedCharSet class methodsFor: 'class methods' stamp: 'eem 2/11/2010 13:13'! digitValue: char "Answer 0-9 if the receiver is $0-$9, 10-35 if it is $A-$Z, and < 0 otherwise. This is used to parse literal numbers of radix 2-36." | value | value := char charCode. value <= $9 asciiValue ifTrue: [^value - $0 asciiValue]. value >= $A asciiValue ifTrue: [value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10]. (value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue: [^value - $a asciiValue + 10]]. ^ -1 ! ! !Unicode class methodsFor: 'class methods' stamp: 'eem 2/11/2010 13:17'! digitValue: char | value | value := char charCode. value <= $9 asciiValue ifTrue: [^value - $0 asciiValue]. value >= $A asciiValue ifTrue: [value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10]. (value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue: [^value - $a asciiValue + 10]]. value > (DecimalProperty size - 1) ifTrue: [^ -1]. ^ (DecimalProperty at: value+1) ! ! 2010/2/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 11, 2010

Re: [Pharo-project] Alternative implementation for Cursor>>show:

by Mariano Martinez Peck

2010/2/9 Fernando olivero <oliverof(a)lu.unisi.ch> > Hi , i think this change could be performed regardless of the InputSensor > fixes. > > It's just removing a double dispatch that does not add much > > yes. Please, open a bug ticket and commit :) > > On Feb 9, 2010, at 9:36 AM, Mariano Martinez Peck wrote: > > > > On Tue, Feb 9, 2010 at 9:33 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> It is true? >> Did you check what mike sent a while ago (or in the bugtracker about >> inputEventSensor? >> >> > I don't know what you are talking about. > > >> >> > Yes, this seems reasonable, as we should delete all references to >> Cursor. >> > >> > Do you agree with this ? If true we need to create an issue and commit >> :) >> > >> > Cheers >> > >> > Mariano >> > >> > On Sat, Jan 23, 2010 at 12:28 PM, Fernando olivero < >> oliverof(a)lu.unisi.ch> wrote: >> > Hi, i think this send to Sensor could be avoided by replacing the >> Cursor>>show: method with >> > >> > Cursor>>show >> > self class currentCursor: self. >> > >> > >> > >> > >> > Instead of a: >> > >> > Cursor>>show >> > "Make the hardware's mouse cursor look like the receiver" >> > >> > Sensor currentCursor: self >> > >> > >> > InputSensor>>currentCursor: newCursor >> > "The current cursor is maintained in class Cursor." >> > >> > Cursor currentCursor: newCursor. >> > _______________________________________________ >> > 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 >> > > <ATT00001..txt> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 11, 2010

[Pharo-project] 16rff is looking for a fix :)

by StÃ©phane Ducasse

Feb. 11, 2010

Re: [Pharo-project] about and:and:and:and: and or:or:

by StÃ©phane Ducasse

Ok kill them all. thanks for push me when I think too much :) Stef On Feb 11, 2010, at 9:11 PM, Nicolas Cellier wrote: > 2010/2/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> hi all >> >> Jannik and jb started to replace all the >> and:and: >> and:and:and: >> and:and:and:and: >> and the same for or: >> >> by they equivalent ie >> >> 1 =2 or: [ 1=3 ] or: [1=1] >> => >> 1 =2 or: [ 1=3 or: [1=1]] >> >> the new compiler optimize both while the old one not. >> So now I would like to see what do you think. >> >> Personnally I do not like and:and:and: and more >> Now for and:and: I'm hesitating. >> > > IMO, the only value was for legibility. > But most time, I find nested code as readable. > Sure we could also optimize all kind of alternate forms... > But I'm not sure if it is a good idea to multiply compiler hacks... > > Nicolas > >> Stef >> >> _______________________________________________ >> 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

Feb. 11, 2010

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

here is also what I added to the blog entry "Improvements can be as simple as that. Now the first level is to communicate with people and let them know that they can improve if they want. So we will probably fix that in Pharo. If somebody provides a fix it can be fix in 2 min. The goal of pharo is to create an innovative Smalltalk that can be use to make business but also to reinvent Smalltalk. And this will not be done without breaking stuff. We do not want to live in a museum. http://www.pharo-project.org for more information and vision statement."

Feb. 11, 2010

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

pfff.... I should say that kent should have not broken his rule. Don't blog when you are mad. It gives a bad impression and not only about smalltalk Now what is the solution. get stuck with a ANSI bad standard? get with vendors evolution that are not optimal? what if we do not like VW Namespace ? what if we would like to have first class instance variables? Vendors like parceplace did not really ask the community about the changes they did. Now Seaside is developed on pharo and run on nearly all the dialects so there is a path. It is not easy. Now if would be better to think that what is the future of smalltalk. - scripting - first class instance variables - new look at the MOP - better modules system - ... and we will not to that with ANSI kind of standardization process. Stef BTW this is fun because when I read the bio of Kent on his recent book I do not see Smalltalk mentioned so this is good to know that he is back to smalltalk :) > Interesting read (read [2] then [1]), maybe Pharo can change the game ... > > bye > T. > > [1] http://www.jarober.com/blog/blogView?showComments=true&printTitle=Balkaniza… > [2] http://www.threeriversinstitute.org/blog/?p=466 > -- > NEU: Mit GMX DSL Ã¼ber 1000,- Â¿ sparen! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 11, 2010