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

WhatsUp from: 2014-02-03 until: 2014-02-16

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-02-16 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Feb. 3, 2014

leadingChar and friends

by Pharo4Stef

During my journey to the leadingChar realm I took notes and I share them with you. leadingChar: leadChar code: code code >= 16r400000 ifTrue: [ self error: 'code is out of range'. ]. leadChar >= 256 ifTrue: [ self error: 'lead is out of range'. ]. code < 256 ifTrue: [ ^self value: code ]. ^self value: (leadChar bitShift: 22) + code. charCode ^ (value bitAnd: 16r3FFFFF). leadingChar ^ (value bitAnd: (16r3FC00000)) bitShift: -22. characterSet ^ EncodedCharSet charsetAt: self leadingChar => a character encodes the characterSet. ============================ Why are we using Latin1>>leadingChar ^ 0. Unicode>>leadingChar ^ 0 and I do not get why GreekEnvironment>>leadingChar ^0 Latin2Environment>>leadingChar ^0 Latin1Environment>>leadingChar ^0 Latin9Environment>>leadingChar ^0 RussianEnvironment>>leadingChar ^0 SimplifiedChineseEnvironment>>leadingChar ^0 ====================== I do not understand why Unicode is declared as 1 and not 0. Unicode class>>initialize EncodedCharSet declareEncodedCharSet: self atIndex: 0+1. EncodedCharSet declareEncodedCharSet: self atIndex: 256. ================================ I do not understand why Latin1 does not use declareEncodedCharSet Latin1 class>>initialize " self initialize " compoundTextSequence := String streamContents: [ :s | s nextPut: (Character value: 27). s nextPut: $(. s nextPut: $B ]. rightHalfSequence := String streamContents: [ :s | s nextPut: (Character value: 27). s nextPut: $-. s nextPut: $A ] I started to distribute the initialization into subclasses starting from this method: declareEncodedCharSet: anEncodedCharSetOrLanguageEnvironmentClass atIndex: aNumber "this method is used to modularize the old initialize method: EncodedCharSets at: 0+1 put: Unicode. EncodedCharSets at: 1+1 put: JISX0208. EncodedCharSets at: 2+1 put: GB2312. EncodedCharSets at: 3+1 put: KSX1001. EncodedCharSets at: 4+1 put: JISX0208. EncodedCharSets at: 5+1 put: JapaneseEnvironment. EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment. EncodedCharSets at: 7+1 put: KoreanEnvironment. EncodedCharSets at: 8+1 put: GB2312. EncodedCharSets at: 12+1 put: KSX1001. EncodedCharSets at: 13+1 put: GreekEnvironment. EncodedCharSets at: 14+1 put: Latin2Environment. EncodedCharSets at: 15+1 put: RussianEnvironment. EncodedCharSets at: 17+1 put: Latin9Environment. EncodedCharSets at: 256 put: Unicode. and indeed Latin1Environment was not part of the list. Now apparently we can remove Latin1 because EncodedCharSets of EncodedCharSet do not contain Latin1 ================================== No senders emitSequenceToResetStateIfNeededOn: aStream forState: state rightDirection Funny nextPutRightHalfValue: ascii toStream: aStream withShiftSequenceIfNeededForTextConverterState: state nextPutValue: ascii toStream: aStream withShiftSequenceIfNeededForTextConverterState: state ========================== Ideas of cleaning steps step one: what if Character>>leadingChar ^ 0 We can probably kill the encodedSet. It looks like Latin1Environment and Latin1 are not used. Stef

Feb. 2, 2014

Re: [Pharo-dev] [Seaside] Re: ConfigurationOfGetText broken?

by Johan Brichau

Hi Paul, Gettext for Seaside is now included in the ConfigurationOfSeaside3 #bleedingEdge baseline. I propose to move the Gettext-Slime package to the Seaside30Addons repository, where the Seaside-Gettext is hosted too. Since I'm busy making modifications to Gettext for Pharo3 anyway, I will create a new baseline here too, if that sounds fine for you. cheers, Johan On 18 Jan 2014, at 18:17, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Sounds fine to me. > > > Thanks for sorting it out. > > > Paul > > > > Johan Brichau-2 wrote >> Fyi I am already adding gettext for seaside to the >> ConfigurationOfSeaside3. >> >> So, it's good to clean ConfigurationOfGettext >> >> Johan (sent from my mobile) >> >>> On 18 Jan 2014, at 13:52, Usman Bhatti < > >> usman.bhatti@ > >> > wrote: >>> >>> We've already discussed it and I am in the favor of removing non-gettext >>> dependancies from its config. >>> http://lists.squeakfoundation.org/pipermail/seaside/2013-October/030221.html >>> >>> Now, I'll wait for Paul's response to cleanup. Because debugging >>> ConfigurationOfGetText or for that matter any configuration with such >>> complexities takes a lot of time. So, as an ad-hoc solution I am loading >>> the only package in Gettext directly. >>> >>> >>> Usman >>> >>> >>>> On Sat, Jan 18, 2014 at 6:24 AM, Johan Brichau < > >> johan@ > >> > wrote: >>>> I agree. >>>> The Seaside packages should be moved to the Seaside configuration and >>>> make that one dependent on ConfigurationOfGettext. >>>> Also, the Seaside30Addons repository was moved to smalltalkhub. >>>> >>>> Johan >>>> >>>> On 17 Jan 2014, at 17:17, Hilaire Fernandes < > >> hilaire.fernandes@ > >> > wrote: >>>> >>>>> Le 17/01/2014 11:42, Usman Bhatti a Ã©crit : >>>>>> >>>>>> It seems that some recent changes in the ConfigurationOfText have >>>> broken >>>>>> the loading in the Pharo 3.0. >>>>>> >>>>> >>>>> >>>>> I only know basic of ConfigurationOf..., but it looks odd to me to see >>>>> Seaside dependencies in the Gettext configuration. Should it not >>>> belong >>>>> to this configuration? Imagine if each package depending on Gettext to >>>>> add itself in the gettext configuration? >>>>> >>>>> Hilaire >>>>> >>>>> -- >>>>> Dr. Geo http://drgeo.eu >>>>> >>>>> >>> >>> _______________________________________________ >>> seaside mailing list >>> > >> seaside@.squeakfoundation > >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > -- > View this message in context: http://forum.world.st/ConfigurationOfGetText-broken-tp4737466p4737765.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Feb. 2, 2014

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

by Sabine KnÃ¶fel

Thank you for the fix, Sven. It works fine now. Sabine On Sat, Feb 1, 2014 at 5:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. 2, 2014

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

by Sven Van Caekenberghe

Thank you, Nicolai, for the fix ! On 02 Feb 2014, at 19:12, Nicolai Hess <nicolaihess(a)web.de> wrote: > Thank you. > > > 2014-02-01 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 01 Feb 2014, at 23:03, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Nicolai Hess wrote > >> Every time the slice marks the all classes and methods as changed, > > > > I've experienced that when viewing changes for a whole slice. If you view > > the changes for each package individually instead, you should see it is > > fine. > > Yeah, it seems to be a fluke, very confusing though. > > > I see Sven has created a new slice for the monkey... > > And it seemed to have passed. > >

Feb. 2, 2014

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

by Nicolai Hess

Thank you. 2014-02-01 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 01 Feb 2014, at 23:03, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Nicolai Hess wrote > >> Every time the slice marks the all classes and methods as changed, > > > > I've experienced that when viewing changes for a whole slice. If you view > > the changes for each package individually instead, you should see it is > > fine. > > Yeah, it seems to be a fluke, very confusing though. > > > I see Sven has created a new slice for the monkey... > > And it seemed to have passed. > >

Feb. 2, 2014

Re: [Pharo-dev] Seaside extensions and lowercase package names in Pharo

by Pharo4Stef

Chris There are several points: - we will maintain compatibility when filein/out using * - now I was not aware that the class extensions should be lower case. - Pharo should clean the packages because some of the extensions are for packages not existing anymore and other edge cases. Stef > On Fri, Jan 31, 2014 at 3:57 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Now that Pharo uses real packages beside categories I see some > lowercase "ghost" packages in Monticello Browser list after loading Seaside. > > To reproduce just load Seaside using config browser and check in > Monticello browser. > > > I guess this is coming from methods in lowercase extension > categories like "*seaside-pharo-core" which do not really > match "Seaside-Pharo-Core" package. > > Any comments? > > Using a star (*) and all-lowercase method category names has been the > convention for PackageInfo / Monticello for method extensions since > the beginning (that is, for many many years now). > > You'll undoubtedly run into this several more times - at least you will when bringing in older Monticello packages or those created outside of Pharo. Not all, but some. > > -cbc > Thx > T. > > >

Feb. 2, 2014

Re: [Pharo-dev] Comparing dates

by Paul DeBruicker

#translateTo: just shifts the timezone. So he's not adding hours to anything. Why are you adding hours to a Date in the first place? I don't understand. Does that make it the next day or the same day 2 hours past the start of the day in whatever timezone you are in, intuitively? I vote: b. Bug. #= should compare calendar (gregorian, julian etc,), year, month, day or year, day # of year sebastian(a)flowingconcept.com wrote > On Feb 1, 2014, at 12:26 PM, Sven Van Caekenberghe < > sven@ > > wrote: > >> Sebastian, >> >> In my 3.0 image >> >> | today | >> today := Date today. >> (today translateTo: 2 hours) = today. >> >> => false >> > > Yeah, here too > >> But what are you trying to accomplish ? > > Detect the most simple equality in the most conventional way. A true when > two dates refers to the same date of the calendar > > >> Dates are a bit ambiguous: my Feb 1st and your Feb 1st, in one sense they >> are the same, refer to the same date, but in another sense, yours started >> at a different point in time, right ? So are they equal ? > > Well dates are the same, thatâs the convention isnât it? Localisation and > time is what's different there. > > If you want to have time involved in the equation the logic step given our > options is that you use DateAndTime > > So, againâ¦ > > Is this a bug or a feature? > > 1. Feature: our convention is injecting time in dates so we are injecting > an incompatibility with intuition in exchange of a surprising precision* > > 2. Bug: Date #= should not compare start > > *a precision that is redundant because DateAndTime also have the > #translateTo: feature > > >> Sven >> >> On 01 Feb 2014, at 14:01, Sebastian Sastre < > sebastian@ > > wrote: >> >>> Can somebody please clarify if this is a bug or feature? >>> >>> thanks >>> >>> >>> >>> >>> On Jan 31, 2014, at 9:03 PM, Sebastian Sastre < > SEBASTIAN@ > > wrote: >>> >>>> self assert: Date today = Date today. >>>> >>>> today := Date today translateTo: 2 hours. >>>> self assert: today = Date today >>>> >>>> Is this right? >>>> >>>> >>>> >>>> >>> >>> >> >> -- View this message in context: http://forum.world.st/Comparing-dates-tp4740789p4741029.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 2, 2014

Re: [Pharo-dev] How to suck (and yet be awesome)

by Pharo4Stef

>> > > yeah, we have a strong intellectual bias. Thatâs great because we make a tool to expand our creativity and expressions of intelligence > > Kathyâs point is that we might be doing more to help others be great themselves through our product/tool/service (Pharo in this case) > > You do that all the time with your students > > They, as everybody, have many options to be heroâs (like solving things with Phyton/Ruby, etc) so our challenge is to have a smooth learning curve with fast positive feedback > > Clean APIâs helps a lot on that because itâs like the UI of the code > > Great tutorials on how to do popular arctifacts (todo lists, blogs, CRUD apps) is something that comes to mind for making a bridge between theory and practical positive results > > At least that worked incredibly well for Rails and other frameworks I like her point of view. I will change what I will wrote in my book and it is related to the discussion with the pool dictionary. stef

Feb. 2, 2014

Re: [Pharo-dev] Comparing dates

by Paul DeBruicker

Why are you adding hours to a Date in the first place? I don't understand. Does that make it the next day or the same day 2 hours past the start of the day in whatever timezone you are in, intuitively? I vote: b. Bug. #= should compare calendar (gregorian, julian etc,), year, month, day or year, day # of year On Feb 1, 2014, at 12:26 PM, Sven Van Caekenberghe <sven@> wrote: > Sebastian, > > In my 3.0 image > > | today | > today := Date today. > (today translateTo: 2 hours) = today. > > => false > Yeah, here too > But what are you trying to accomplish ? Detect the most simple equality in the most conventional way. A true when two dates refers to the same date of the calendar > Dates are a bit ambiguous: my Feb 1st and your Feb 1st, in one sense they > are the same, refer to the same date, but in another sense, yours started > at a different point in time, right ? So are they equal ? Well dates are the same, thatâs the convention isnât it? Localisation and time is what's different there. If you want to have time involved in the equation the logic step given our options is that you use DateAndTime So, againâ¦ Is this a bug or a feature? 1. Feature: our convention is injecting time in dates so we are injecting an incompatibility with intuition in exchange of a surprising precision* 2. Bug: Date #= should not compare start *a precision that is redundant because DateAndTime also have the #translateTo: feature > Sven > > On 01 Feb 2014, at 14:01, Sebastian Sastre <sebastian@> wrote: > >> Can somebody please clarify if this is a bug or feature? >> >> thanks >> >> >> >> >> On Jan 31, 2014, at 9:03 PM, Sebastian Sastre <SEBASTIAN@> wrote: >> >>> self assert: Date today = Date today. >>> >>> today := Date today translateTo: 2 hours. >>> self assert: today = Date today >>> >>> Is this right? >>> >>> >>> >>> >> >> > > -- View this message in context: http://forum.world.st/Comparing-dates-tp4740789p4741022.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 2, 2014