November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] UUID comparaison is Incorrect

by StÃ©phane Ducasse

Thanks norbert. You see this was a kind of exerciseâ¦ to see if people can get a bit more involved. I could have simply introduce the fix but I want people to understand that there are a lot of little trivial things that can get done and it will help the system. So thank :) :) On Nov 5, 2011, at 11:20 AM, Norbert Hartl wrote: > And I would rather like to see another implementation like > > < aMagnitude > "Answer whether the receiver is less than the argument." > > (self size = aMagnitude size) ifFalse: [ > ^ self size < aMagnitude size ]. > 1 to: self size do: [:i | > (self at: i) = (aMagnitude at: i) ifFalse: [ > ^ (self at: i) < (aMagnitude at: i) ]]. > ^false. > > Norbert > > Am 04.11.2011 um 21:13 schrieb StÃ©phane Ducasse: > >> I was thinking that we should get the same bug for you UUID >> because the code right now is >> >> < aMagnitude >> "Answer whether the receiver is less than the argument." >> >> 1 to: self size do: [:i | >> (self at: i) < (aMagnitude at: i) ifTrue: [^true]]. >> ^false. >> >> >>>> |a b| >>>> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >>>> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >>>> (a > b) = (b > a) >> >> returns true and this looks wrong :) >> >> What do you think? >> >> Stef >> >> >> Begin forwarded message: >> >>> From: Alan Knight <knight(a)acm.org> >>> Subject: Re: [vwnc] UUID Sorting Incorrect >>> Date: November 1, 2011 3:19:23 PM GMT+01:00 >>> To: Runar Jordahl <runar.jordahl(a)gmail.com> >>> Cc: vwnc(a)cs.uiuc.edu >>> Reply-To: knight(a)acm.org >>> >>> Thanks. Created AR 64162 >>> >>>> >>>> Runar Jordahl >>>> 25 October, 2011 7:13 AM >>>> >>>> >>>> Class UUID is included in beta in VisualWorks 7.8. It seems like #< is >>>> implemented incorrect. If you evaluate the statement below it answers >>>> true: >>>> >>>> |a b| >>>> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >>>> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >>>> (a > b) = (b > a) >>>> >>>> The fix is to change the method to this: >>>> >>>> < aMagnitude >>>> "Answer whether the receiver is less than the argument. Add an >>>> initial size check, in anticipation of greater than 128-bit >>>> Smalltalk-specific UUID type." >>>> >>>> | ss ms | >>>> >>>> ss := self size. >>>> ms := aMagnitude size. >>>> ss < ms >>>> ifTrue: [^true] >>>> ifFalse: [ >>>> ss > ms >>>> ifTrue: [^false] >>>> ifFalse: [ >>>> 1 to: self size do: [:i | >>>> (self at: i) < (aMagnitude at: i) ifTrue: [^true]. >>>> (self at: i) > (aMagnitude at: i) ifTrue: [^false]]. >>>> ^false]] >>>> >>>> >>>> Runar Jordahl >>>> blog.epigent.com >>>> _______________________________________________ >>>> vwnc mailing list >>>> vwnc(a)cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> _______________________________________________ >>> vwnc mailing list >>> vwnc(a)cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >

Nov. 5, 2011

Re: [Pharo-project] UUID comparaison is Incorrect

by Norbert Hartl

And I would rather like to see another implementation like < aMagnitude "Answer whether the receiver is less than the argument." (self size = aMagnitude size) ifFalse: [ ^ self size < aMagnitude size ]. 1 to: self size do: [:i | (self at: i) = (aMagnitude at: i) ifFalse: [ ^ (self at: i) < (aMagnitude at: i) ]]. ^false. Norbert Am 04.11.2011 um 21:13 schrieb StÃ©phane Ducasse: > I was thinking that we should get the same bug for you UUID > because the code right now is > > < aMagnitude > "Answer whether the receiver is less than the argument." > > 1 to: self size do: [:i | > (self at: i) < (aMagnitude at: i) ifTrue: [^true]]. > ^false. > > >>> |a b| >>> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >>> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >>> (a > b) = (b > a) > > returns true and this looks wrong :) > > What do you think? > > Stef > > > Begin forwarded message: > >> From: Alan Knight <knight(a)acm.org> >> Subject: Re: [vwnc] UUID Sorting Incorrect >> Date: November 1, 2011 3:19:23 PM GMT+01:00 >> To: Runar Jordahl <runar.jordahl(a)gmail.com> >> Cc: vwnc(a)cs.uiuc.edu >> Reply-To: knight(a)acm.org >> >> Thanks. Created AR 64162 >> >>> >>> Runar Jordahl >>> 25 October, 2011 7:13 AM >>> >>> >>> Class UUID is included in beta in VisualWorks 7.8. It seems like #< is >>> implemented incorrect. If you evaluate the statement below it answers >>> true: >>> >>> |a b| >>> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >>> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >>> (a > b) = (b > a) >>> >>> The fix is to change the method to this: >>> >>> < aMagnitude >>> "Answer whether the receiver is less than the argument. Add an >>> initial size check, in anticipation of greater than 128-bit >>> Smalltalk-specific UUID type." >>> >>> | ss ms | >>> >>> ss := self size. >>> ms := aMagnitude size. >>> ss < ms >>> ifTrue: [^true] >>> ifFalse: [ >>> ss > ms >>> ifTrue: [^false] >>> ifFalse: [ >>> 1 to: self size do: [:i | >>> (self at: i) < (aMagnitude at: i) ifTrue: [^true]. >>> (self at: i) > (aMagnitude at: i) ifTrue: [^false]]. >>> ^false]] >>> >>> >>> Runar Jordahl >>> blog.epigent.com >>> _______________________________________________ >>> vwnc mailing list >>> vwnc(a)cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >

Nov. 5, 2011

[Pharo-project] [update 1.4] #14216

by StÃ©phane Ducasse

14216 ----- - Issue 4963: Debugger crashes the image when the selector is > or >>. Thanks Benjamin van ryseghem and nicolas cellier. http://code.google.com/p/pharo/issues/detail?id=4963 - Issue 4906: crLog http://code.google.com/p/pharo/issues/detail?id=4906 - Issue 4953: Toggle break on entry is broken. Thanks nicolas cellier. http://code.google.com/p/pharo/issues/detail?id=4953 - Issue 4962: TaskList open on cmd+shift+letf/right. Thansk Benjamin van ryseghem. http://code.google.com/p/pharo/issues/detail?id=4962 Stef

Nov. 5, 2011

Re: [Pharo-project] UUID comparaison is Incorrect

by Norbert Hartl

Am 04.11.2011 um 21:13 schrieb StÃ©phane Ducasse: > I was thinking that we should get the same bug for you UUID > because the code right now is > > < aMagnitude > "Answer whether the receiver is less than the argument." > > 1 to: self size do: [:i | > (self at: i) < (aMagnitude at: i) ifTrue: [^true]]. > ^false. > > >>> |a b| >>> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >>> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >>> (a > b) = (b > a) > > returns true and this looks wrong :) > > What do you think? > Come on, this is not a problem for UUIDs where all digits are the same. So just fix the comment "Answer whether any digit of the receiver is less than the digit of the argument at the same position." done! Norbert > Stef > > > Begin forwarded message: > >> From: Alan Knight <knight(a)acm.org> >> Subject: Re: [vwnc] UUID Sorting Incorrect >> Date: November 1, 2011 3:19:23 PM GMT+01:00 >> To: Runar Jordahl <runar.jordahl(a)gmail.com> >> Cc: vwnc(a)cs.uiuc.edu >> Reply-To: knight(a)acm.org >> >> Thanks. Created AR 64162 >> >>> >>> Runar Jordahl >>> 25 October, 2011 7:13 AM >>> >>> >>> Class UUID is included in beta in VisualWorks 7.8. It seems like #< is >>> implemented incorrect. If you evaluate the statement below it answers >>> true: >>> >>> |a b| >>> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >>> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >>> (a > b) = (b > a) >>> >>> The fix is to change the method to this: >>> >>> < aMagnitude >>> "Answer whether the receiver is less than the argument. Add an >>> initial size check, in anticipation of greater than 128-bit >>> Smalltalk-specific UUID type." >>> >>> | ss ms | >>> >>> ss := self size. >>> ms := aMagnitude size. >>> ss < ms >>> ifTrue: [^true] >>> ifFalse: [ >>> ss > ms >>> ifTrue: [^false] >>> ifFalse: [ >>> 1 to: self size do: [:i | >>> (self at: i) < (aMagnitude at: i) ifTrue: [^true]. >>> (self at: i) > (aMagnitude at: i) ifTrue: [^false]]. >>> ^false]] >>> >>> >>> Runar Jordahl >>> blog.epigent.com >>> _______________________________________________ >>> vwnc mailing list >>> vwnc(a)cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >

Nov. 5, 2011

[Pharo-project] Call for help for reviewing code

by StÃ©phane Ducasse

Hi guys there are plenty of bugs fixes that are waiting for review in the bug tracker. If each of us take two we will get really done fast. So can you give a hand and have a look the fixes. Stef

Nov. 5, 2011

Re: [Pharo-project] Keymapping Questions

by Guillermo Polito

This should not happen in the bleeding edge :) On Fri, Nov 4, 2011 at 1:34 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I found another bug - creating a shortcut with no modifiers e.g. "$c > asShortcut" fires on c, shift-c, cmd-c... > > -- > View this message in context: > http://forum.world.st/Keymapping-Questions-tp3990667p3990743.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Nov. 5, 2011

Re: [Pharo-project] Keymapping Questions

by Guillermo Polito

On Fri, Nov 4, 2011 at 1:16 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Where can I find documentation on Keymapping (if it exists)? > Hmmm, If you load the #bleedingEdge (which is pretty stable right now), there are several examples in the categories: Keymapping-Morph Keymapping-Editors Keymapping-Tools ... Also, most of the classes have comments, but I think I have to review them so far :). > > Here are the basics I have so far: > * the available set of shortcuts is per-class > * a shortcut is created by creating a builder method (similar to World Menu > registration) annotated with <keymap> > * shortcuts are grouped into categories > * categories (not individual shortcuts) are attached to Morph classes via > KMBuilder>>attachShortcutCategory:to: > * the system is updated when "KMPragmaKeymapBuilder uniqueInstance" resets > itself via #reset (but see problems below) > > Questions: > * What is the purpose of naming shortcuts? > Hmm, mainly, to bind a shortcut to a setting. And nothing else by now... So I use it as a kind of id :/. Maybe someone has a better approach... I was about to review it with Mariano tomorrow. > * Why are shortcuts held by categories as named entries and separately as > keymaps? > This is an idea I took from the original keymappings. I classify shortcuts in categories so you can: - attach a category to a specific class (letting its instances handle those keymaps) - attach a category to a specific instance (the same as above but in the instance level :) ) You can also attach a single shortcut in a morph like: someMorph on: aShortcut do: [ some task ] But this last (lets say) *annonimous* shortcut, can't be put into a setting. > > There seems to be a problem with updating shortcuts (esp. changing existing > ones): > * It seems that when an existing named shortcut is modified, eventually > KMShortcut>>shortcutHasChangedIn:by: is called, but this method does > nothing, so the shortcut never gets updated. Why is this? It seems like a > bug. > Hmm, strange. There are two implementations of this method in my image. One in KMShortcut and one in KMNoShortcut, one does nothing (on purpose with a comment :P) but the other has an implementation :/... > * When a <keymap> method is saved in OB, KMPragmaKeymapBuilder>>reset is > called twice - once via AnnouncementSubscription>>deliver:, and once via > KMPragmaKeymapBuilder>>event: > Hmm, I didn't knew this one :) > * Because KMRepository class>>reset is never called, it becomes very dirty > if shortcuts are repeatedly edited. For example, create a shortcut named > "myShortcut" with Cmd+D in Category "Test", now change its name and accept > the code. You will have two shortcuts with the same key combination. Now > change to Cmd+E and accept again. You will have three shortcuts, even > though > you have only one specified in your builder method... > > So it seems to me to keep integrity in the shortcuts, either: > * "KMRepository reset" when anything is changed, and start from scratch > * or, improve KMPragmaKeymapBuilder>>reset's ability to keep the system > clean. > I did it on purpose right now. The problem with resetting the KMContainer, is that you lose the customizations you did in the settings right now. Thinking aloud, maybe It would be good to provide two resets: - shallow reset. That resets the shortcuts but tries to remember the customizations done in the settings. This one can be done every time you modify a <keymap> annotated method. - deep reset. That just resets everything. You have to know that you are loosing everything here :). Thanks for the feedback :) Guille > Sean > > -- > View this message in context: > http://forum.world.st/Keymapping-Questions-tp3990667p3990667.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Nov. 5, 2011

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

More stuff well said. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Jimmie Houchin [jlhouchin(a)gmail.com] Sent: Friday, November 04, 2011 9:19 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy I agree! I like the focus of Pharo and its goal of enabling people to get things done. Stef, I think you are doing a great job. Especially with the limited resources of the community. And I think you are doing a fantastic job of increasing the resources of the community. You have my profound thanks and appreciation. Jimmie On 11/4/2011 4:32 PM, Schwab,Wilhelm K wrote: > Sven, Sig, > > Well said. > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Friday, November 04, 2011 11:22 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Simple vs. Easy > > Sure, Cuis is really cool as well as very impressive. > > However, it is limited: > > I want: > > Seaside > Moose > HTTP Client+Server > Monticello > Metacello > XML > JSON > Glorp > Database Access > FFI > UTF8 and other encodings > â¦ > > I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks. > > Pharo takes on all these and at the same time tries to simplify things, the hard way. > > Sven > > On 04 Nov 2011, at 14:35, Jimmie Houchin wrote: > >> Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 >> >> Hi Folks, >> >> I'm answering you off-list because I'm not subscribed to the Pharo list. >> Feel free to forward this there, if you wish. >> >> I think it is great to put focus on simplicity (an objective value) over >> easyness (a subjective value). Rich also makes a good critic to usual >> practices, including the dichotomy between understanding and TDD (test >> driven development). >> >> However, the value of simplicity is not something new. The difference >> between essential complexity and accidental complexity is the heart of >> "No Silver Bullet â Essence and Accidents of Software Engineering" (by >> Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, >> http://drdobbs.com/184407534) It is also central to Smalltalk, see >> "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, >> http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) >> These three articles might be the most important writings on software >> engineering ever. >> >> The problem with this discussion is that everybody will claim simplicity >> is a crucial objective of their project. However, Pharo and Squeak don't >> realize (or don't want to realize) that simplicity appears only by >> removing complexity, never by adding more of it. >> >> Cuis is a Squeak fork with the #1 objective of being simple and >> understandable. It is the result of more than 10 years suffering the >> accidental complexity in Squeak, comparing with other Smalltalks, >> together with a lot of reflection and work, by me and others. It is, I >> believe, the only Smalltalk in active development that pursues this >> objective of the original Smalltalk-80 project. You can get it from >> http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take >> statistics (lines of code, etc). Compare. You might have a nice surprise. >> >> Jimmie, you asked "How can we move Pharo to be a better answer to Simple >> vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up >> feature list as a priority, and focus on simplicity. Make a list of the >> features in Pharo that are really important, and not part of Cuis, and >> turn them into optional packages. Make that list as short as possible! >> Worry more about code quality and less about discarding potentially >> useful stuff, that is not good enough. >> >> Cheers, >> Juan Vuletich

Nov. 5, 2011

Re: [Pharo-project] Simple vs. Easy

by Jimmie Houchin

I agree! I like the focus of Pharo and its goal of enabling people to get things done. Stef, I think you are doing a great job. Especially with the limited resources of the community. And I think you are doing a fantastic job of increasing the resources of the community. You have my profound thanks and appreciation. Jimmie On 11/4/2011 4:32 PM, Schwab,Wilhelm K wrote: > Sven, Sig, > > Well said. > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Friday, November 04, 2011 11:22 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Simple vs. Easy > > Sure, Cuis is really cool as well as very impressive. > > However, it is limited: > > I want: > > Seaside > Moose > HTTP Client+Server > Monticello > Metacello > XML > JSON > Glorp > Database Access > FFI > UTF8 and other encodings > â¦ > > I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks. > > Pharo takes on all these and at the same time tries to simplify things, the hard way. > > Sven > > On 04 Nov 2011, at 14:35, Jimmie Houchin wrote: > >> Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 >> >> Hi Folks, >> >> I'm answering you off-list because I'm not subscribed to the Pharo list. >> Feel free to forward this there, if you wish. >> >> I think it is great to put focus on simplicity (an objective value) over >> easyness (a subjective value). Rich also makes a good critic to usual >> practices, including the dichotomy between understanding and TDD (test >> driven development). >> >> However, the value of simplicity is not something new. The difference >> between essential complexity and accidental complexity is the heart of >> "No Silver Bullet â Essence and Accidents of Software Engineering" (by >> Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, >> http://drdobbs.com/184407534) It is also central to Smalltalk, see >> "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, >> http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) >> These three articles might be the most important writings on software >> engineering ever. >> >> The problem with this discussion is that everybody will claim simplicity >> is a crucial objective of their project. However, Pharo and Squeak don't >> realize (or don't want to realize) that simplicity appears only by >> removing complexity, never by adding more of it. >> >> Cuis is a Squeak fork with the #1 objective of being simple and >> understandable. It is the result of more than 10 years suffering the >> accidental complexity in Squeak, comparing with other Smalltalks, >> together with a lot of reflection and work, by me and others. It is, I >> believe, the only Smalltalk in active development that pursues this >> objective of the original Smalltalk-80 project. You can get it from >> http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take >> statistics (lines of code, etc). Compare. You might have a nice surprise. >> >> Jimmie, you asked "How can we move Pharo to be a better answer to Simple >> vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up >> feature list as a priority, and focus on simplicity. Make a list of the >> features in Pharo that are really important, and not part of Cuis, and >> turn them into optional packages. Make that list as short as possible! >> Worry more about code quality and less about discarding potentially >> useful stuff, that is not good enough. >> >> Cheers, >> Juan Vuletich

Nov. 5, 2011

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

Stef, Please count me as a believer :) Pharo is evolving into a very nice system. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Friday, November 04, 2011 5:04 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy I wrote an answer and throw it away. I do not want to argue and keep my positive energy :) We will see in 5 years from now what will be the situation. Because we are getting more and more agile contrary to what people believe. We are making deep changes and working on the infrastructure of the system but with the challenge that we have users. And we want happy and powerful users. Infrastructure work that often invisible at first but after a while they really pay off. I want a system that people can use. The goal of Pharo is a system to build other systems. Now for 1.4 I would like to remove the rest of MethodReference, PseudoClass and Friends. Stef > Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 > > Hi Folks, > > I'm answering you off-list because I'm not subscribed to the Pharo list. > Feel free to forward this there, if you wish. > > I think it is great to put focus on simplicity (an objective value) over > easyness (a subjective value). Rich also makes a good critic to usual > practices, including the dichotomy between understanding and TDD (test > driven development). > > However, the value of simplicity is not something new. The difference > between essential complexity and accidental complexity is the heart of > "No Silver Bullet â Essence and Accidents of Software Engineering" (by > Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, > http://drdobbs.com/184407534) It is also central to Smalltalk, see > "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, > http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) > These three articles might be the most important writings on software > engineering ever. > > The problem with this discussion is that everybody will claim simplicity > is a crucial objective of their project. However, Pharo and Squeak don't > realize (or don't want to realize) that simplicity appears only by > removing complexity, never by adding more of it. > > Cuis is a Squeak fork with the #1 objective of being simple and > understandable. It is the result of more than 10 years suffering the > accidental complexity in Squeak, comparing with other Smalltalks, > together with a lot of reflection and work, by me and others. It is, I > believe, the only Smalltalk in active development that pursues this > objective of the original Smalltalk-80 project. You can get it from > http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take > statistics (lines of code, etc). Compare. You might have a nice surprise. > > Jimmie, you asked "How can we move Pharo to be a better answer to Simple > vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up > feature list as a priority, and focus on simplicity. Make a list of the > features in Pharo that are really important, and not part of Cuis, and > turn them into optional packages. Make that list as short as possible! > Worry more about code quality and less about discarding potentially > useful stuff, that is not good enough. > > Cheers, > Juan Vuletich > >

Nov. 4, 2011