- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Review]: Case 12737 Morph sends mouseUp twice to handlers

by Pharo4Stef

Well did we lived perfectly with it over last year? yes -> 40 no -> 30 > > > > Because changing Morphic now sounds a bit shaky to me :) > That's why I'm asking for a lot of input. But it is a bug. And I think this slice version is very unlikely to break anything - 2 lines changed. I'd at least appreciate someone taking a look. If you agree that it's a straight-forward change, I will take responsibility for getting it right or reverting. > > Cheers, > Sean > > View this message in context: Re: [Review]: Case 12737 Morph sends mouseUp twice to handlers > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 2, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Pharo4Stef

I added https://pharo.fogbugz.com/default.asp?12769 Fix included. took me less than 10 min including downloading the latest version of Pharo and scanning complete sources. Stef

Feb. 2, 2014

Fwd: poolDictionaries removal breaks my projects

by Pharo4Stef

Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-dev] poolDictionaries removal breaks my projects > Date: 2 Feb 2014 00:56:28 GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > >>>> +1 on this >>> >>> There are some kinds of students who are going to find Smalltalk difficult, yes. I do not see how removing pooldictionaries from the class creation template will affect them. If they ask about them, you can say that they are there and point them to the new class creation message. And take advantage of that to say that class creation is just a message send while you are at it :-) >> >> If your students have problems to grasp the concept of pool dictionaries then how do they deal with mathematics and computer science? > > This is the proof that you never taught. I never got the time to arrive to pool. Why would I teach them something that I used two times over the last 15 years of programming (ok I just wrote moose and some parts of Pharo :). > > Why should I spend time on a detail when I can teach them real OO design? > Do you think that I attract people to Smalltalk teaching them about Pool? or because I ask them why the way boolean is implemented is so mind-blowing? I let you guess. Now during my last lectures (4.5 h in total this year). > One guy leo came after the lecture and told that he loves the way boolean are implemented and that he wants to an internship with us. > > Is it enough or I should continue? > > > >>>>> âoldtimersâ need freedom. This is one of the reasons I really enjoy dynamic typing and Smalltalk. I donât like to obey to artificial rules that only >>>>> put permanent burden to me in order to protect me from something I might do wrong sometimes. >>> >>> You still have the freedom to use pool dictionaries. They are still there. >> They are hidden for the sake of simplicity for some students. >> I want my pool dictionaries back :-D > > Donât use them you do not need them. > Why you cannot express the same with a class and a classvar + messages? > >>>>> >>>> >>>> If you donât see features you donât know what the machine can do for you. >>>> >>>> Obscuring things is sometimes a good design strategy, but here there is a well known artefact breaking tradition here, that isnât something light. And the proposed alternative design is far to be better (read: have been proven itself worth of its added burden of breaking that tradition) >>> >>> So if we cannot break tradition then Traits should never have been introduced? >> Traits are a different kind of thing. They didnât cripple existing elements in Pharo. > > really? > did you see the real class template with traits? It should be like that if we follow your reasoning > > Object subclass: #NameOfSubclass > uses: T1 (#bar -> #zork) + T2 - {#foo} > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'CollectionsTests-Strings' > > > > > CollectionRootTest subclass: #StringTest > uses: TIncludesTest + TCloneTest + TCopyTest + TSetArithmetic + TIterateSequencedReadableTest + TPrintOnSequencedTest + TAsStringCommaAndDelimiterSequenceableTest + TIndexAccess + TSequencedElementAccessTest + TSubCollectionAccess + TPutBasicTest + TCopySequenceableSameContents + TCopyPartOfSequenceable + TCopyPartOfSequenceableForMultipliness + TCopySequenceableWithOrWithoutSpecificElements + TCopySequenceableWithReplacement + TReplacementSequencedTest + (TConvertTest - {#testAsByteArray}) + TConvertAsSortedTest + TBeginsEndsWith + (TIndexAccessForMultipliness - {#testIdentityIndexOfIAbsentDuplicate. #testIdentityIndexOfDuplicate. #collectionWithNonIdentitySameAtEndAndBegining}) + TSequencedConcatenationTest + TPutTest + TConvertAsSetForMultiplinessTest + TSortTest + TSequencedStructuralEqualityTest + TOccurrencesForMultiplinessTest + TCreationWithTest > instanceVariableNames: 'string emptyString elementInNonEmpty notIn nonEmpty1element withoutEqualElements collectionNotIncluded indexInNonEmptyArray sameAtEndAndBegining nonEmpty5ElementsSorted unsortedCollection subcollection3ElementsSorted arrayWithCharacters' > classVariableNames: '' > poolDictionaries: '' > category: 'CollectionsTests-Strings' > > > >> The only problem was the lack of tool support when they were introduced. You are comparing apples and oranges. >> >>> >> For generations of Smalltalk newbies it was possible to either grasp the concept or ignore it. > > How do you measure that we did not fail? > >> Why do you need to change this without a real solution for those who want to use them? >> In my eyes itâs an absolute minority of Pharo users who arenât able to understand the concept. > > Again let me repeat. This is not a question of not being able to understand or not. > This is an accessibility point. Why do we overhelm people with unnecessary information. > Now think about it for real (read what I wrote) because I will stop reading this thread. > > >>>> Itâs a half-ass non-solution >>>> >>>> Do you really love cleaning that up? >>> >>> >>> This half-assed non-solution is the same solution as for Traits, essentially. Do you have the same issue with Traits? >>> >> Again you are comparing apples and oranges. Traits didnât take away anything but brought something new. > > No :) > This is why I do not like traits. > >> You took away something. >> BTW how do your students cope with Traits? They must be completely overwhelmed. > > They do not see them. because empty traits are not in the class template nor in the definition of classes that do not use them. > Can you reread this sentence please? > >> And how do you teach the class hierarchy and meta classes? > > much simpler. > >> >> >> >>>> The second part of your homework on this design decision was completely ignored so expecting it to be loved (popular) is unrealistic >>>> >>>> And by not doing that you just added a problem where there was none >>>> >>>> Not willing to do that second part? >>>> >>>> Then donât fix what isnât broken. >>> >>> Please see previous mail. >> >> I am a close lurker of the mailing lists and I completely missed it. >> >> Regards, >> Andreas >

Feb. 2, 2014

Fwd: poolDictionaries removal breaks my projects

by Pharo4Stef

Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-dev] poolDictionaries removal breaks my projects > Date: 2 Feb 2014 00:30:04 GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > Johan > > YOU ARE RIGHT, RIGHT, RIGHT, RIGHT. I spent a significant amount of time teaching Smalltalk to know that you are right. > And this change will be in the system :) > > Just people that know something totally ignore what is it to learn something. > Imagine people are scared and close the debuggers. Oscar wrote patterns and I always say the debugger is your best friend so do not close it. > > Stef > >> >>>> I donât see how this change make Smalltalk (the language) simpler. For me this change looks more like an obfuscation than a simplification. >>> >>> How many lectures did you give? It is annoying to have to explain something that usually people do not need to know. >> >> To complement this: in my own experience as a full-time prof, whenever you are teaching and at a given point you need to say: 'I cannot explain this yet' or resort to handwaving there is something wrong. Do I need to explain pooldictionaries to be able to talk about class creation? No, I should not need to do that. >> >> I get this feeling with Java all the time. First hello world example in Java is always a mess. public static void main(String[] args) OMG. Start to explain all that just to do a println? Were is the simplicity there? I don't want to have this kind of feeling when I explain Smalltalk. >> >>>> How should newcomers know how to enter pool dictionaries? I rarely use pool dictionaries and if I will need it I surely have forgotten about >>>> this change and expect irritation and frustration. >>> >>> Newcomers do not use pooldictionaries. In 10 years smalltalking I used them twice. >> >> I agree with Stef that pooldictionaries are advanced features. I have been Smalltalking since 1998 and I have never used them. >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >> >

Feb. 2, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Johan Fabry

On Feb 1, 2014, at 8:59 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >>> If your students have problems to grasp the concept of pool dictionaries then how do they deal with mathematics and computer science? >> >> Given enough time, no problem. But time in class and outside is limited enough as it is. > > No johan even if I multiply by two the amount of time you have you will not spend time on such uninteresting concept when > we have so much more beautiful concepts to show. There is a difference between being able to do it, and me wanting to to it :-). I don't want to because of the same reasons as you, apparently. I am just defending my students here :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 2, 2014

Re: [Pharo-dev] Can someone help me with this issue 12469 (Sometimes an empty protocol is created)

by Pharo4Stef

sorry for this situation. It is not the one we dream about believe me. Stef On 01 Feb 2014, at 18:29, Nicolai Hess <nicolaihess(a)web.de> wrote: > I tried a dozen times to create a slice for the fix. > Every time the slice marks the all classes and methods as changed, > even so, I only changed some methods. > > Now I have finally uploaded a slice with only my changes but.. > The Validator chooses an older slice for validation ? > (https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/9284//artifact/vali…) > > I don't know anymore, what I can do, I despair. > > > Nicolai > >

Feb. 2, 2014

poolDictionaries removal breaks my projects

by Pharo4Stef

yes johan you are right again :) Stef >> OK, back to topic and to summarize: we now all fully understood that the original message >> including pools is still there, will not break code loading or other things and that the >> change is on the Nautilus level. > > Yes, thanks for understanding and summarizing well. > >> But still the simple question left to be anwered here: what will this change of reducing the >> class template in the default browser give us? What problem did it really solve? >> >> The answer given so far is that it may be problematic when teaching because you want to >> introduce to language features step by step. But you said yourself in your own post >> that >> >> <quote> >> It is BORING to have to say to kids: >> - do not care of classvar >> - do not care of pooldictionaries >> </quote> >> >> So my question: if you are bored of the "complexity" of BOTH (!) >> - why do we hide pools now >> - and leave class variables still left in the template? >> >> I really do not understand because with the change it now looks in >> Pharo3.0 Latest update: #30732 like this: >> >> Object subclass: #Foo >> instanceVariableNames: '' >> classVariableNames: '' >> category: 'Bar' >> >> So why do we keep class vars then? According to your mail we would have to remove them too. > > From my point of view this is a different design decision to take since it is a different feature of the language. So it is not included in the change that I proposed. And BTW I leave it to somebody else to make the call and propose a change to Pharo that addresses this (or not, as may be the case). > >> Additionally this change violates the intention of a template (which one usually just has to fill out) >> and one now has to remember the original full keyword and have to type it in again - which is IMHO >> really awkward and stupid. >> >> So with all respect: I still can not see the introduction of the reduced template as a step forward >> or an improvement. > > For me, this reduces to the case of Traits. A low usage (arguably), so uses: is not present in the template. We do the same for pooldictionaries. If you are against this, and say that you should just fill in the template, then logically you should be against how Traits are handled. Following that logic, you are advocating for: > > Object subclass: #NameOfSubclass > uses: '' > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: '' > > Am I correct? > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Feb. 2, 2014

poolDictionaries removal breaks my projects

by Pharo4Stef

>> >> There are some kinds of students who are going to find Smalltalk difficult, yes. I do not see how removing pooldictionaries from the class creation template will affect them. If they ask about them, you can say that they are there and point them to the new class creation message. And take advantage of that to say that class creation is just a message send while you are at it :-) > > If your students have problems to grasp the concept of pool dictionaries then how do they deal with mathematics and computer science? This is the proof that you never taught. I never got the time to arrive to pool. Why would I teach them something that I used two times over the last 15 years of programming (ok I just wrote moose and some parts of Pharo :). Why should I spend time on a detail when I can teach them real OO design? Do you think that I attract people to Smalltalk teaching them about Pool? or because I ask them why the way boolean is implemented is so mind-blowing? I let you guess. Now during my last lectures (4.5 h in total this year). One guy leo came after the lecture and told that he loves the way boolean are implemented and that he wants to an internship with us. Is it enough or I should continue? >>>> âoldtimersâ need freedom. This is one of the reasons I really enjoy dynamic typing and Smalltalk. I donât like to obey to artificial rules that only >>>> put permanent burden to me in order to protect me from something I might do wrong sometimes. >> >> You still have the freedom to use pool dictionaries. They are still there. > They are hidden for the sake of simplicity for some students. > I want my pool dictionaries back :-D Donât use them you do not need them. Why you cannot express the same with a class and a classvar + messages? >>>> >>> >>> If you donât see features you donât know what the machine can do for you. >>> >>> Obscuring things is sometimes a good design strategy, but here there is a well known artefact breaking tradition here, that isnât something light. And the proposed alternative design is far to be better (read: have been proven itself worth of its added burden of breaking that tradition) >> >> So if we cannot break tradition then Traits should never have been introduced? > Traits are a different kind of thing. They didnât cripple existing elements in Pharo. really? did you see the real class template with traits? It should be like that if we follow your reasoning Object subclass: #NameOfSubclass uses: T1 (#bar -> #zork) + T2 - {#foo} instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'CollectionsTests-Strings' CollectionRootTest subclass: #StringTest uses: TIncludesTest + TCloneTest + TCopyTest + TSetArithmetic + TIterateSequencedReadableTest + TPrintOnSequencedTest + TAsStringCommaAndDelimiterSequenceableTest + TIndexAccess + TSequencedElementAccessTest + TSubCollectionAccess + TPutBasicTest + TCopySequenceableSameContents + TCopyPartOfSequenceable + TCopyPartOfSequenceableForMultipliness + TCopySequenceableWithOrWithoutSpecificElements + TCopySequenceableWithReplacement + TReplacementSequencedTest + (TConvertTest - {#testAsByteArray}) + TConvertAsSortedTest + TBeginsEndsWith + (TIndexAccessForMultipliness - {#testIdentityIndexOfIAbsentDuplicate. #testIdentityIndexOfDuplicate. #collectionWithNonIdentitySameAtEndAndBegining}) + TSequencedConcatenationTest + TPutTest + TConvertAsSetForMultiplinessTest + TSortTest + TSequencedStructuralEqualityTest + TOccurrencesForMultiplinessTest + TCreationWithTest instanceVariableNames: 'string emptyString elementInNonEmpty notIn nonEmpty1element withoutEqualElements collectionNotIncluded indexInNonEmptyArray sameAtEndAndBegining nonEmpty5ElementsSorted unsortedCollection subcollection3ElementsSorted arrayWithCharacters' classVariableNames: '' poolDictionaries: '' category: 'CollectionsTests-Strings' > The only problem was the lack of tool support when they were introduced. You are comparing apples and oranges. > >> > For generations of Smalltalk newbies it was possible to either grasp the concept or ignore it. How do you measure that we did not fail? > Why do you need to change this without a real solution for those who want to use them? > In my eyes itâs an absolute minority of Pharo users who arenât able to understand the concept. Again let me repeat. This is not a question of not being able to understand or not. This is an accessibility point. Why do we overhelm people with unnecessary information. Now think about it for real (read what I wrote) because I will stop reading this thread. >>> Itâs a half-ass non-solution >>> >>> Do you really love cleaning that up? >> >> >> This half-assed non-solution is the same solution as for Traits, essentially. Do you have the same issue with Traits? >> > Again you are comparing apples and oranges. Traits didnât take away anything but brought something new. No :) This is why I do not like traits. > You took away something. > BTW how do your students cope with Traits? They must be completely overwhelmed. They do not see them. because empty traits are not in the class template nor in the definition of classes that do not use them. Can you reread this sentence please? > And how do you teach the class hierarchy and meta classes? much simpler. > > > >>> The second part of your homework on this design decision was completely ignored so expecting it to be loved (popular) is unrealistic >>> >>> And by not doing that you just added a problem where there was none >>> >>> Not willing to do that second part? >>> >>> Then donât fix what isnât broken. >> >> Please see previous mail. > > I am a close lurker of the mailing lists and I completely missed it. > > Regards, > Andreas

Feb. 2, 2014

Paths to remove leading char

by Pharo4Stef

Hi guys I started to understand the leadingChar and I would like to get ideas about a possible path to remove the leading char. If you have an idea of the possible steps that we perform to make progress in Pharo 40 Iâm all ears open. Stef

Feb. 2, 2014

Fwd: poolDictionaries removal breaks my projects

by Pharo4Stef

From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> Subject: Re: [Pharo-dev] poolDictionaries removal breaks my projects Date: 2 Feb 2014 00:30:04 GMT+1 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Johan YOU ARE RIGHT, RIGHT, RIGHT, RIGHT. I spent a significant amount of time teaching Smalltalk to know that you are right. And this change will be in the system :) Just people that know something totally ignore what is it to learn something. Imagine people are scared and close the debuggers. Oscar wrote patterns and I always say the debugger is your best friend so do not close it. Stef > >>> I donât see how this change make Smalltalk (the language) simpler. For me this change looks more like an obfuscation than a simplification. >> >> How many lectures did you give? It is annoying to have to explain something that usually people do not need to know. > > To complement this: in my own experience as a full-time prof, whenever you are teaching and at a given point you need to say: 'I cannot explain this yet' or resort to handwaving there is something wrong. Do I need to explain pooldictionaries to be able to talk about class creation? No, I should not need to do that. > > I get this feeling with Java all the time. First hello world example in Java is always a mess. public static void main(String[] args) OMG. Start to explain all that just to do a println? Were is the simplicity there? I don't want to have this kind of feeling when I explain Smalltalk. > >>> How should newcomers know how to enter pool dictionaries? I rarely use pool dictionaries and if I will need it I surely have forgotten about >>> this change and expect irritation and frustration. >> >> Newcomers do not use pooldictionaries. In 10 years smalltalking I used them twice. > > I agree with Stef that pooldictionaries are advanced features. I have been Smalltalking since 1998 and I have never used them. > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Feb. 2, 2014