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

Can someone help me with this issue 12469 (Sometimes an empty protocol is created)

by Nicolai Hess

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. 1, 2014

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

by Johan Fabry

On Feb 1, 2014, at 12:55 PM, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >> 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? Given enough time, no problem. But time in class and outside is limited enough as it is. >> 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 For simplicity of everybody that is learning the language, and everybody that writes a class without pool dicts. Note that they are still there! Just write pooldictionaries: in the next-to-last line and done. >>> 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. The only problem was the lack of tool support when they were introduced. You are comparing apples and oranges. I repeat. Nothing is broken. Pool dictionaries are still there. So the comparison stands. >>> Yeah, youâre not the only one with that perception. >>> >>> This move sucks. It allegedly solved a problem that allegedly happens to some by creating a problem for almost everybody. >> >> I have an issue with your "problem for almost everybody" statement. Pooldictionaries are rarely used. Look at the classes in the image. Can you argument why this then is a problem for almost everybody ? I do not see how you get to this conclusion. > For generations of Smalltalk newbies it was possible to either grasp the concept or ignore it. > 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. The problem is not understanding the pooldictionaries. The problem is the people that use them. Are you saying that it is a problem for everybody that the template is now without a line that they do NOT use? In that case we should not touch anything and not make any changes. >> 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. > You took away something. I repeat. Pool dictionaries are still there. I did not take away anything. Essentially I am doing the same as with traits: if you use them you see them, if not, not. The comparison stands. > BTW how do your students cope with Traits? They must be completely overwhelmed. > And how do you teach the class hierarchy and meta classes? Yes, I do teach them because I have the *time* to do it. I have the time to do it because I can focus on the essential and not lose it explaining obscure features. >> Please see previous mail. > > I am a close lurker of the mailing lists and I completely missed it. Sent today at 10:37 AM chilean time, a few minutes before I sent the mail you are replying to. Same subject as this mail. For completeness, here is the content: > For what it's worth: this was asked on the users list (some months ago). There were about 5 replies and they were positive. I do not recall having any negative replies. > > I think that asking much more than that is hard, given the nature of mailing lists and the comity being busy with many other things. > > Also, having learned about user studies and performed a few (for this "science" thing I'm supposed to be doing), I can tell you that getting a really representative group of users together is nearly impossible in the scenario we are in. So anything you can get out of an inquiry will just be 'some people say: OK'. Nothing is guaranteed about other people. Which is just what is happening here ! ;-) > > On Jan 31, 2014, at 6:43 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> Lets says it convinces youâ¦ >> >> Time to be skeptic. Test. >> >> Test with someone else. Tests it with 5 guys and ask how they feel about it. >> >> Hear. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 1, 2014

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

by Johan Fabry

On Feb 1, 2014, at 12:39 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > 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. 1, 2014

Re: [Pharo-dev] ZTimestamp>>monthName spelling error

by Sven Van Caekenberghe

Sabine, On 01 Feb 2014, at 15:15, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > Hi Sven, > > thank you for the quick fix. It works fine now. > > I do not call this directly but from > DateAndTime date: self endDate time: self endTime > > Your example: > I am no english native speaker but I assume, that 'saterday' should be spelled as 'saturday'. > If yes, there are several occurences of saterday. Terrible spelling of me! === Name: ZTimestamp-SvenVanCaekenberghe.33 Author: SvenVanCaekenberghe Time: 1 February 2014, 5:18:50.139922 pm UUID: 40111894-d387-432a-a3e1-2245af4a269b Ancestors: ZTimestamp-SvenVanCaekenberghe.32 Even worse: Saterday => Saturday (thx Sabine KnÃ¶fel) === ConfigurationOfZTimestamp has been updated everywhere. > I saw this when trying your example: > > (ZTimestampFormat fromString: 'Saterday, 3 February, 2001') > german; > format: Date today. ==>>'Samstag, 1 Februar, 2014' > > (ZTimestampFormat fromString: 'Saturday, 3 February, 2001') > german; > format: Date today. ==>>'Samurday, 1 Februar, 2014' > > Also, 'Samurday' is no german word. 'Saturday' means 'Samstag' in German. Now that example should work: (ZTimestampFormat fromString: 'Saturday, 3 February, 2001') german; format: Date today. => 'Samstag, 1 Februar, 2014' Thanks for the feedback. Sven > Regards > Sabine > > > On Sat, Feb 1, 2014 at 1:31 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Sabine, > > On 01 Feb 2014, at 12:52, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > > > Hi Sven, > > > > could you change Februari into February please? > > Ah, terrible typo, it was all over the place. > > === > Name: ZTimestamp-SvenVanCaekenberghe.32 > Author: SvenVanCaekenberghe > Time: 1 February 2014, 1:27:02.50151 pm > UUID: 70fd3b88-e15e-4139-922c-9c602e3fc532 > Ancestors: ZTimestamp-SvenVanCaekenberghe.31 > > The English spelling of the 2nd month name was consistently wrong: Februari instead of the correct February (thx Sabine KnÃ¶fel); > Now use #monthIndex instead of the less consistent #month > === > > Btw, did you know you can do: > > (ZTimestampFormat fromString: 'Saterday, 3 February, 2001') > german; > format: Date today. > > => 'Samstag, 1 Februar, 2014' > > Regards, > > Sven > > > (I use http://mc.stfx.eu/Neo, this is the right place?) > > > > Regards > > Sabine > > > > ZTimestamp>>monthName > > "Return the English name of the month of the receiver, according to the > > Gregorian calendar, a Symbol" > > > > ^ #(January Februari March April May June July August September October > > November December) at: self monthIndex > > > > > > > > -- > > View this message in context: http://forum.world.st/ZTimestamp-monthName-spelling-error-tp4740821.html > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > >

Feb. 1, 2014

Re: [Pharo-dev] subscript out of bounds in protocol creation

by Andreas Wacknitz

Am 01.02.2014 um 16:41 schrieb Jordi Delgado <jdelgado(a)lsi.upc.edu>: > That's what I mean, I did *exactly* that, and the chosen class was > KMKeymapBuilder (from Keymapping-Pragmas package). The private > protocol was added with no problem. So...? No idea. > > Bests, > > Jordi > > PS: Also with a freshly 30733 image downloaded > > OK, I tried it with KMKeymapBuilder and got the errors. So we need to check for the operating system and VM. On my machine (OSX 10.9.1) System Reporter says for VM General: Virtual Machine --------------- /Applications/Pharo.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Dec 12 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Dec 12 2013 https://github.com/pharo-project/pharo-vm.git Commit: 71adca113a9aff2876288927e5c1c86bf7ac13e2 Date: 2013-12-07 05:00:47 -0800 By: Philippe Back <philippeback(a)gmail.com> Jenkins build #14777 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: 71adca113a9aff2876288927e5c1c86bf7ac13e2 Date: 2013-12-07 05:00:47 -0800 By: Philippe Back <philippeback(a)gmail.com> Jenkins build #14777 NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Dec 12 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 Dec 12 2013 What are you using? Regards, Andreas > > >> Hi Jordi and all, >> >> here is my detailed receipt with a freshly downloaded 30733.zip from Pharo files: >> >> 1. Open Nautilus >> 2. Select an arbitrary package >> 3. Select an arbitrary class from that package >> 4. Right-click in the methods panel and select âAdd protocolâ¦â from the popup menu. >> 5. Enter âprivateâ in the dialog without selecting any entry in the listbox on top. >> 6. Hit âenterâ or press âOKâ with a left-click. >> >> -> Bummer! A cascade of 3 "SubscriptOutOfBounce: 1â pre-debuggers. >> >> Regards, >> Andreas >> >> >> >> Am 01.02.2014 um 11:46 schrieb Jordi Delgado <jdelgado(a)lsi.upc.edu>: >> >>> Hi, >>> >>> With a fresh image, I do that with a class randomly selected >>> (obviously, with no class selected nothing happens) and the >>> protocol gets added without problems. Then, I choose another class, >>> again I pick a random one, and after doing exactly the same the >>> error appears. Why? No clue. >>> >>> I said that the error is difficult to reproduce because sometimes >>> it appears, and sometimes not. And I am not able to ascertain the >>> circumstances under which it will pop up. >>> >>> Bests, >>> >>> Jordi >>> >>> >>> >>> >>>> Hi, >>>> >>>> Am 31.01.2014 um 08:36 schrieb Jordi Delgado <jdelgado(a)lsi.upc.edu>: >>>> >>>>> 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 guess I can produce this easily :-) >>>> Just hit âAdd protocolâ¦â in the popup menu of the method protocol pane. >>>> Enter a name like âprivateâ in the dialog. And then press enter without selecting anything in the listbox above. >>>> And voilÃ â¦ >>>> >>>> Regards, >>>> Andreas >>>> >>>> >>>> >>> >> >> >

Feb. 1, 2014

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

by Andreas Wacknitz

Am 01.02.2014 um 15:00 schrieb Johan Fabry <jfabry(a)dcc.uchile.cl>: > > On Feb 1, 2014, at 9:32 AM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >>> I donât give any lectures to students but I often try to âteachâ Smalltalk to some of my colleagues and friends. And with that I have hard times. >>> Typically âexperiencedâ software developers think about themselves as being experts in object orientation and programming languages, >>> even if they have only experiences with C, C# and C++. âTeachingâ them about Smalltalkâs idea of object orientation is VERY hard, almost >>> impossible because they already know everything (read: they are ignorant) and lazy. I guess there are some similarities to students. >> >> +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? > >>> Newcomers donât use a lot of things but that should not be a reason to hide them. In my experience newcomers need guidance and rules but >>> â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 > >>> At the moment I am considering pool dictionaries for a solution of a problem at hand: I need to collect some information (warnings, errors, and reports) over lots of related and unrelated classes. For the moment I have parameters, but that is getting inconvenient with a growing number of things to collectâ¦ >>> So, if you need something it should be there and not necessarily obscured and hidden! >>> >> >> 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. The only problem was the lack of tool support when they were introduced. You are comparing apples and oranges. > >> Students shouldnât be underestimated they can handle ignoring what they donât need, no problem > > If I would have infinite time, and they as well, sure! Be we don't and we need to focus. > >>> Yes, but itâs not there yet but this change already took away some power without giving me back something in exchange! >>> I am able to ignore some parts of class creation message easily (I also donât use class variables that often) and I donât see why students >>> shouldnât be able, too. Quite contrary I think if you hide these things from students they wonât see it, wonât get curious and in the end will only >>> learn the boring parts of Smalltalkâ¦ >>> >> Yeah, youâre not the only one with that perception. >> >> This move sucks. It allegedly solved a problem that allegedly happens to some by creating a problem for almost everybody. > > I have an issue with your "problem for almost everybody" statement. Pooldictionaries are rarely used. Look at the classes in the image. Can you argument why this then is a problem for almost everybody ? I do not see how you get to this conclusion. For generations of Smalltalk newbies it was possible to either grasp the concept or ignore it. 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. > >> 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. You took away something. BTW how do your students cope with Traits? They must be completely overwhelmed. And how do you teach the class hierarchy and meta classes? >> 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. 1, 2014

Re: [Pharo-dev] subscript out of bounds in protocol creation

by Jordi Delgado

That's what I mean, I did *exactly* that, and the chosen class was KMKeymapBuilder (from Keymapping-Pragmas package). The private protocol was added with no problem. So...? No idea. Bests, Jordi PS: Also with a freshly 30733 image downloaded > Hi Jordi and all, > > here is my detailed receipt with a freshly downloaded 30733.zip from Pharo files: > > 1. Open Nautilus > 2. Select an arbitrary package > 3. Select an arbitrary class from that package > 4. Right-click in the methods panel and select ÂAdd protocolÂÂ from the popup menu. > 5. Enter ÂprivateÂ in the dialog without selecting any entry in the listbox on top. > 6. Hit ÂenterÂ or press ÂOKÂ with a left-click. > > -> Bummer! A cascade of 3 "SubscriptOutOfBounce: 1Â pre-debuggers. > > Regards, > Andreas > > > > Am 01.02.2014 um 11:46 schrieb Jordi Delgado <jdelgado(a)lsi.upc.edu>: > > > Hi, > > > > With a fresh image, I do that with a class randomly selected > > (obviously, with no class selected nothing happens) and the > > protocol gets added without problems. Then, I choose another class, > > again I pick a random one, and after doing exactly the same the > > error appears. Why? No clue. > > > > I said that the error is difficult to reproduce because sometimes > > it appears, and sometimes not. And I am not able to ascertain the > > circumstances under which it will pop up. > > > > Bests, > > > > Jordi > > > > > > > > > >> Hi, > >> > >> Am 31.01.2014 um 08:36 schrieb Jordi Delgado <jdelgado(a)lsi.upc.edu>: > >> > >>> 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 guess I can produce this easily :-) > >> Just hit ÂAdd protocolÂÂ in the popup menu of the method protocol pane. > >> Enter a name like ÂprivateÂ in the dialog. And then press enter without selecting anything in the listbox above. > >> And voilÃ Â > >> > >> Regards, > >> Andreas > >> > >> > >> > > > >

Feb. 1, 2014

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

by Torsten Bergmann

Hi Stef, > Now people hear me well: you are ready to hear well. Lower the music Beside the fact that I like listening to loud music I really lowered it ;) But even with silence in the room your response told me nothing new regarding the topic discussed. It is not a discussion about "who has the vision" or "who want to get stuck" I think we all share the SAME VISION to move forward with a fresh dynamic programming environment and are not afraid if we move away from our original roots. Otherwise we would'nt be on this list or do even radical changes. Therefore: please stay on topic and stop arguing by pointing to visions because it will move us away from the original discussion and one can easily get the impression that opposite opinions on the topic are cut down as if people are either grumpy old Smalltalkers or betrayers on the Pharo movement - which is simply not the case! So lets continue discussing about the topic - because I see no violation agains the Pharo vision here. ---------------- 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. 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. 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. Music is still lowered and ears are all open... Thx T.

Feb. 1, 2014

Re: [Pharo-dev] ZTimestamp>>monthName spelling error

by Sabine KnÃ¶fel

Hi Sven, the german translations are all correct. Thanks :) Sabine Am 01.02.2014 15:44 schrieb "Sven Van Caekenberghe" <sven(a)stfx.eu>: > This is becoming really embarrassing. > > Before I do another commit, this is all correct, right ? > > german > self monthNames: #( > 'Januar' 'Februar' 'MÃ¤rz' 'April' 'Mai' 'Juni' > 'Juli' 'August' 'September' 'Oktober' 'November' 'Dezember' ). > self weekdayNames: #( > 'Sonntag' 'Montag' 'Dienstag' 'Mittwoch' 'Donnerstag' 'Freitag' > 'Samstag' ) > > On 01 Feb 2014, at 15:15, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > > > Hi Sven, > > > > thank you for the quick fix. It works fine now. > > > > I do not call this directly but from > > DateAndTime date: self endDate time: self endTime > > > > Your example: > > I am no english native speaker but I assume, that 'saterday' should be > spelled as 'saturday'. > > If yes, there are several occurences of saterday. I saw this when trying > your example: > > > > (ZTimestampFormat fromString: 'Saterday, 3 February, 2001') > > german; > > format: Date today. ==>>'Samstag, 1 Februar, 2014' > > > > (ZTimestampFormat fromString: 'Saturday, 3 February, 2001') > > german; > > format: Date today. ==>>'Samurday, 1 Februar, 2014' > > > > Also, 'Samurday' is no german word. 'Saturday' means 'Samstag' in German. > > > > Regards > > Sabine > > > > > > On Sat, Feb 1, 2014 at 1:31 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Sabine, > > > > On 01 Feb 2014, at 12:52, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> > wrote: > > > > > Hi Sven, > > > > > > could you change Februari into February please? > > > > Ah, terrible typo, it was all over the place. > > > > === > > Name: ZTimestamp-SvenVanCaekenberghe.32 > > Author: SvenVanCaekenberghe > > Time: 1 February 2014, 1:27:02.50151 pm > > UUID: 70fd3b88-e15e-4139-922c-9c602e3fc532 > > Ancestors: ZTimestamp-SvenVanCaekenberghe.31 > > > > The English spelling of the 2nd month name was consistently wrong: > Februari instead of the correct February (thx Sabine KnÃ¶fel); > > Now use #monthIndex instead of the less consistent #month > > === > > > > Btw, did you know you can do: > > > > (ZTimestampFormat fromString: 'Saterday, 3 February, 2001') > > german; > > format: Date today. > > > > => 'Samstag, 1 Februar, 2014' > > > > Regards, > > > > Sven > > > > > (I use http://mc.stfx.eu/Neo, this is the right place?) > > > > > > Regards > > > Sabine > > > > > > ZTimestamp>>monthName > > > "Return the English name of the month of the receiver, according > to the > > > Gregorian calendar, a Symbol" > > > > > > ^ #(January Februari March April May June July August September > October > > > November December) at: self monthIndex > > > > > > > > > > > > -- > > > View this message in context: > http://forum.world.st/ZTimestamp-monthName-spelling-error-tp4740821.html > > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > > > > > > > > >

Feb. 1, 2014

Re: [Pharo-dev] ZTimestamp>>monthName spelling error

by Sven Van Caekenberghe

This is becoming really embarrassing. Before I do another commit, this is all correct, right ? german self monthNames: #( 'Januar' 'Februar' 'MÃ¤rz' 'April' 'Mai' 'Juni' 'Juli' 'August' 'September' 'Oktober' 'November' 'Dezember' ). self weekdayNames: #( 'Sonntag' 'Montag' 'Dienstag' 'Mittwoch' 'Donnerstag' 'Freitag' 'Samstag' ) On 01 Feb 2014, at 15:15, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > Hi Sven, > > thank you for the quick fix. It works fine now. > > I do not call this directly but from > DateAndTime date: self endDate time: self endTime > > Your example: > I am no english native speaker but I assume, that 'saterday' should be spelled as 'saturday'. > If yes, there are several occurences of saterday. I saw this when trying your example: > > (ZTimestampFormat fromString: 'Saterday, 3 February, 2001') > german; > format: Date today. ==>>'Samstag, 1 Februar, 2014' > > (ZTimestampFormat fromString: 'Saturday, 3 February, 2001') > german; > format: Date today. ==>>'Samurday, 1 Februar, 2014' > > Also, 'Samurday' is no german word. 'Saturday' means 'Samstag' in German. > > Regards > Sabine > > > On Sat, Feb 1, 2014 at 1:31 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Sabine, > > On 01 Feb 2014, at 12:52, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > > > Hi Sven, > > > > could you change Februari into February please? > > Ah, terrible typo, it was all over the place. > > === > Name: ZTimestamp-SvenVanCaekenberghe.32 > Author: SvenVanCaekenberghe > Time: 1 February 2014, 1:27:02.50151 pm > UUID: 70fd3b88-e15e-4139-922c-9c602e3fc532 > Ancestors: ZTimestamp-SvenVanCaekenberghe.31 > > The English spelling of the 2nd month name was consistently wrong: Februari instead of the correct February (thx Sabine KnÃ¶fel); > Now use #monthIndex instead of the less consistent #month > === > > Btw, did you know you can do: > > (ZTimestampFormat fromString: 'Saterday, 3 February, 2001') > german; > format: Date today. > > => 'Samstag, 1 Februar, 2014' > > Regards, > > Sven > > > (I use http://mc.stfx.eu/Neo, this is the right place?) > > > > Regards > > Sabine > > > > ZTimestamp>>monthName > > "Return the English name of the month of the receiver, according to the > > Gregorian calendar, a Symbol" > > > > ^ #(January Februari March April May June July August September October > > November December) at: self monthIndex > > > > > > > > -- > > View this message in context: http://forum.world.st/ZTimestamp-monthName-spelling-error-tp4740821.html > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > >

Feb. 1, 2014