February 2014 - Pharo-dev - lists.pharo.org

subscript out of bounds in protocol creation
by Jordi Delgado Feb. 2, 2014

Feb. 2, 2014

Hi, I realized that sometimes, when creating new protocols, it appears an error "subscript out of bounds: 1". I have not been able -yet- to reproduce it from a clean image, but it happens often (at least to me). It seems to me that it has something to do with protocol creation before any method has been written, but I am still investigating. I used the latest image downloaded yesterday, and it still happens. I browsed fogbuz looking for this error before reporting it, but I could not find it. I did not search thorougly, though. Just to let you know... Bests, and thanks a lot for the work you are doing. It's amazing. Jordi

5 14

[pharo-project/pharo-core]
by GitHub Feb. 2, 2014

Feb. 2, 2014

Branch: refs/tags/30735 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 84479c: 30735
by GitHub Feb. 2, 2014

Feb. 2, 2014

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 84479c3be512ca637893e3061cf4843e85816d5b https://github.com/pharo-project/pharo-core/commit/84479c3be512ca637893e306… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-02-02 (Sun, 02 Feb 2014) Changed paths: A Polymorph-Widgets.package/ListDialogWindow.class/instance/actions/doubleClickOk.st M Polymorph-Widgets.package/ListDialogWindow.class/instance/items creation/buildListMorph.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script388.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30735.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/AbstractTool.class/class/private/requestProtocolNameFor_initialAnswer_.st M Tools.package/AbstractTool.class/instance/class/addCategoryIn_before_.st Log Message: ----------- 30735 12469 Sometimes an empty protocol is created https://pharo.fogbugz.com/f/cases/12469 http://files.pharo.org/image/30/30735.zip

1 0

Fwd: poolDictionaries removal breaks my projects
by Pharo4Stef Feb. 2, 2014

Feb. 2, 2014

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 >

2 2

[Review]: Case 12737 Morph sends mouseUp twice to handlers
by Sean P. DeNigris Feb. 2, 2014

Feb. 2, 2014

https://pharo.fogbugz.com/default.asp?12737 DoIt: Morph new on: #mouseUp send: #inspect to: 1; openInWorld. Two inspectors will appear. Fix in inbox: SLICE-Issue-12737-Morph-sends-mouseUp-twice-to-handlers-SeanDeNigris.1 Please review. It definitely fixes the problem, but it fiddles around inside Morphic so... Test included - fails before, passes after ----- Cheers, Sean -- View this message in context: http://forum.world.st/Review-Case-12737-Morph-sends-mouseUp-twice-to-handle… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

4 10

Fwd: poolDictionaries removal breaks my projects
by Pharo4Stef Feb. 2, 2014

Feb. 2, 2014

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 >> >> >

1 0

poolDictionaries removal breaks my projects
by Pharo4Stef Feb. 2, 2014

Feb. 2, 2014

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 > >

1 0

poolDictionaries removal breaks my projects
by Pharo4Stef Feb. 2, 2014

Feb. 2, 2014

>> >> 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

1 0

Paths to remove leading char
by Pharo4Stef Feb. 2, 2014

Feb. 2, 2014

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

1 0

Fwd: poolDictionaries removal breaks my projects
by Pharo4Stef Feb. 2, 2014

Feb. 2, 2014

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 > >

1 0