October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About TestCase >> assert:

by Alexandre Bergel

>>> I don't know how widely used Object>>assert: is. Perhaps we >>> could have a different selector for that which takes a >>> block. >> >> I don't either, but I find strange the complete hierarchy of >> classes >> of Pharo having a method assert: available. Perhaps I'm >> blindfolded >> and Pharo and Squeak have found a wider use for assertions? > Ah, sorry for the confusion. What I'm talking about here (and I > assumed > Alexandre was as well, but I could be mistaken) is indeed the use of > #assert: or some other message to test runtime invariants. So you'd > put > something like: [...] This is exactly what I had in mind I regularly use assert: to describe invariant, pre and postcondition. This complement testing pretty well in my opinion. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 15, 2009

Re: [Pharo-project] New items in Pharo Core merger

by StÃ©phane Ducasse

I think that we should really improve the merge tool to help us so any step in that direction is welcomed. Stef On Oct 15, 2009, at 12:52 PM, Henrik Johansen wrote: > Would it be possible to enable "Keep current version" (ie, don't > install > the version from the thing being merged) to the menu list for New > items > in the Monticello merger? > It's kind of hard to f.ex. merge Squeak-trunk Collections, containing > Base64MimeConverter, when in Pharo, that Class exists in a different > package. > At least as far as I can tell (haven't actually done it, as I don't > feel > like resolving the 260 other conflicts just to find out), applying the > merge will result in move the class. > Alternatively to check if the item already exists in the system, but > in > a different package, and mark that as a conflict. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2009

Re: [Pharo-project] Sprint information

by Oscar Nierstrasz

I plan to arrive early. +41 78 628 0817 - on On 15 Oct 2009, at 09:18, StÃ©phane Ducasse wrote: > Hi guys > > Here are some information about the sprint. > > The place is located at LIFL in a room close to our office. > http://rmod.lille.inria.fr > check at the bottom of the page (pay attention our physical address > is not the same than our mail address. > We are NOT in the INRIA building. > > In short you should take the metro up to Cite Scientifique and walk > south until the round point and turn right after a moment > you should have a parking on your left and the building is doing a > kind of large L > > The entrance in the building is at the crossing of the L. > > Now the building will be closed on saturday and I can open the door. > I plan to be at the lab at 9h00. > > Now I do not have a mobile phone... so it would be good that we share > mobile numbers so that > we have a base for connecting us. > The idea is that we will write on a sheet of paper the mobile phone > number of the first one that will arrive. > > Stef > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2009

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: Kernel-ar.271.mcz

by Henrik Johansen

TestInstance: DateAndTime year: 2009 month: 11 day: 15 creation methods: 8-10 times faster midnight - ~25 times faster Published to Inbox as SLICE-DateAndTimeCreation. Cheers, Henry Workspace used to test: |date| date := DateAndTime year: 2009 month: 11 day: 15. [500000 timesRepeat: [date midnight]] timeToRun. 370 9660 [500000 timesRepeat: [DateAndTime year: 2009 month: 11 day: 15]] timeToRun. 914 8697 StÃ©phane Ducasse skrev: > thanks cedric > did you get a chance to check because I thought we did something like > that too. > > Stef > > On Oct 15, 2009, at 11:48 AM, CÃ©drick BÃ©ler wrote: > > >> ---------- Forwarded message ---------- >> From: <commits(a)source.squeak.org> >> Date: 2009/10/15 >> Subject: [squeak-dev] The Trunk: Kernel-ar.271.mcz >> To: squeak-dev(a)lists.squeakfoundation.org >> >> >> Andreas Raab uploaded a new version of Kernel to project The Trunk: >> http://source.squeak.org/trunk/Kernel-ar.271.mcz >> >> ==================== Summary ==================== >> >> Name: Kernel-ar.271 >> Author: ar >> Time: 14 October 2009, 8:49:48 am >> UUID: a603d2fe-dccf-894f-95db-ef577480b03c >> Ancestors: Kernel-nice.270, Kernel-ul.270 >> >> Merging Kernel-ul.270: >> >> - faster DateAndTime and Date creation with #year:month:day: and >> friends >> - minor formatting fixes >> >> =============== Diff against Kernel-nice.270 =============== >> >> Item was changed: >> ----- Method: DateAndTime>>midnight (in category 'squeak protocol') >> ----- >> midnight >> "Answer a DateAndTime starting at midnight local time" >> >> + ^self class basicNew >> + setJdn: jdn >> + seconds: 0 >> + nano: 0 >> + offset: self class localOffset >> - ^ self >> - dayMonthYearDo: [ :d :m :y | self class year: y >> month: m day: d ] >> ! >> >> Item was changed: >> ----- Method: DateAndTime class>>year:month:day:hour:minute: (in >> category 'squeak protocol') ----- >> year: year month: month day: day hour: hour minute: minute >> + "Return a DateAndTime" >> >> + ^self >> - "Return a DateAndTime" ^ self >> year: year >> month: month >> day: day >> hour: hour >> minute: minute >> second: 0 >> ! >> >> Item was changed: >> ----- Method: DateAndTime >> class>>year:month:day:hour:minute:second:nanoSecond:offset: (in >> category 'squeak protocol') ----- >> year: year month: month day: day hour: hour minute: minute second: >> second nanoSecond: nanoCount offset: offset >> "Return a DateAndTime" >> >> + | monthIndex daysInMonth p q r s julianDayNumber | >> - | monthIndex daysInMonth p q r s julianDayNumber since | >> >> monthIndex := month isInteger ifTrue: [month] ifFalse: [Month >> indexOfMonth: month]. >> daysInMonth := Month >> daysInMonth: monthIndex >> forYear: year. >> day < 1 ifTrue: [self error: 'day may not be zero or >> negative']. >> day > daysInMonth ifTrue: [self error: 'day is after month >> ends']. >> >> p := (monthIndex - 14) quo: 12. >> q := year + 4800 + p. >> r := monthIndex - 2 - (12 * p). >> s := (year + 4900 + p) quo: 100. >> >> julianDayNumber := >> ( (1461 * q) quo: 4 ) + >> ( (367 * r) quo: 12 ) - >> ( (3 * s) quo: 4 ) + >> ( day - 32075 ). >> >> + ^self basicNew >> + setJdn: julianDayNumber >> + seconds: hour * 60 + minute * 60 + second >> + nano: nanoCount >> + offset: offset; >> - since := Duration days: julianDayNumber hours: hour >> - minutes: minute seconds: second >> nanoSeconds: nanoCount. >> - >> - ^ self basicNew >> - ticks: since ticks offset: offset; >> yourself! >> >> Item was changed: >> ----- Method: DateAndTime class>>year:month:day: (in category >> 'squeak protocol') ----- >> year: year month: month day: day >> + "Return a DateAndTime, midnight local time" >> + >> + ^self >> - "Return a DateAndTime, midnight local time" ^ self >> year: year >> month: month >> day: day >> hour: 0 >> minute: 0 >> ! >> >> >> >> >> >> -- >> CÃ©drick >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Oct. 15, 2009

[Pharo-project] New items in Pharo Core merger

by Henrik Johansen

Would it be possible to enable "Keep current version" (ie, don't install the version from the thing being merged) to the menu list for New items in the Monticello merger? It's kind of hard to f.ex. merge Squeak-trunk Collections, containing Base64MimeConverter, when in Pharo, that Class exists in a different package. At least as far as I can tell (haven't actually done it, as I don't feel like resolving the 260 other conflicts just to find out), applying the merge will result in move the class. Alternatively to check if the item already exists in the system, but in a different package, and mark that as a conflict. Cheers, Henry

Oct. 15, 2009

Re: [Pharo-project] Fwd: [squeak-dev] The Trunk: Kernel-ar.271.mcz

by StÃ©phane Ducasse

thanks cedric did you get a chance to check because I thought we did something like that too. Stef On Oct 15, 2009, at 11:48 AM, CÃ©drick BÃ©ler wrote: > > > ---------- Forwarded message ---------- > From: <commits(a)source.squeak.org> > Date: 2009/10/15 > Subject: [squeak-dev] The Trunk: Kernel-ar.271.mcz > To: squeak-dev(a)lists.squeakfoundation.org > > > Andreas Raab uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-ar.271.mcz > > ==================== Summary ==================== > > Name: Kernel-ar.271 > Author: ar > Time: 14 October 2009, 8:49:48 am > UUID: a603d2fe-dccf-894f-95db-ef577480b03c > Ancestors: Kernel-nice.270, Kernel-ul.270 > > Merging Kernel-ul.270: > > - faster DateAndTime and Date creation with #year:month:day: and > friends > - minor formatting fixes > > =============== Diff against Kernel-nice.270 =============== > > Item was changed: > ----- Method: DateAndTime>>midnight (in category 'squeak protocol') > ----- > midnight > "Answer a DateAndTime starting at midnight local time" > > + ^self class basicNew > + setJdn: jdn > + seconds: 0 > + nano: 0 > + offset: self class localOffset > - ^ self > - dayMonthYearDo: [ :d :m :y | self class year: y > month: m day: d ] > ! > > Item was changed: > ----- Method: DateAndTime class>>year:month:day:hour:minute: (in > category 'squeak protocol') ----- > year: year month: month day: day hour: hour minute: minute > + "Return a DateAndTime" > > + ^self > - "Return a DateAndTime" ^ self > year: year > month: month > day: day > hour: hour > minute: minute > second: 0 > ! > > Item was changed: > ----- Method: DateAndTime > class>>year:month:day:hour:minute:second:nanoSecond:offset: (in > category 'squeak protocol') ----- > year: year month: month day: day hour: hour minute: minute second: > second nanoSecond: nanoCount offset: offset > "Return a DateAndTime" > > + | monthIndex daysInMonth p q r s julianDayNumber | > - | monthIndex daysInMonth p q r s julianDayNumber since | > > monthIndex := month isInteger ifTrue: [month] ifFalse: [Month > indexOfMonth: month]. > daysInMonth := Month > daysInMonth: monthIndex > forYear: year. > day < 1 ifTrue: [self error: 'day may not be zero or > negative']. > day > daysInMonth ifTrue: [self error: 'day is after month > ends']. > > p := (monthIndex - 14) quo: 12. > q := year + 4800 + p. > r := monthIndex - 2 - (12 * p). > s := (year + 4900 + p) quo: 100. > > julianDayNumber := > ( (1461 * q) quo: 4 ) + > ( (367 * r) quo: 12 ) - > ( (3 * s) quo: 4 ) + > ( day - 32075 ). > > + ^self basicNew > + setJdn: julianDayNumber > + seconds: hour * 60 + minute * 60 + second > + nano: nanoCount > + offset: offset; > - since := Duration days: julianDayNumber hours: hour > - minutes: minute seconds: second > nanoSeconds: nanoCount. > - > - ^ self basicNew > - ticks: since ticks offset: offset; > yourself! > > Item was changed: > ----- Method: DateAndTime class>>year:month:day: (in category > 'squeak protocol') ----- > year: year month: month day: day > + "Return a DateAndTime, midnight local time" > + > + ^self > - "Return a DateAndTime, midnight local time" ^ self > year: year > month: month > day: day > hour: 0 > minute: 0 > ! > > > > > > -- > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2009

Re: [Pharo-project] Polymorph observations

by Gary Chambers

Thanks Bill. The "Squeak" way allows double-click just inside the first quote to select the relevant snippet of course though ;-) Perhaps default models would be a good idea though it can, with over-reliance, tend to distance things from the real model... Nothing in TEasilyThemed for splitters. Note that Polymorph only fixes issues with SystemWindow splitter usage at present, rather than arbitrary owner morphs. Given a system window: win addPaneVSplitterBetween: morph1 and: {morph2}. main splitters last color: win paneColor. Given other morphs (for the moment). aMorph addPaneVSplitterBetween: morph1 and: {morph2}. aMorph splitters last color: aMorph paneColor; addLeftOrTop: morph1; addRightOrBottom: morph2. Regards, Gary ----- Original Message ----- From: Schwab,Wilhelm K To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, October 13, 2009 2:10 AM Subject: [Pharo-project] Polymorph observations Gary, I have done a little with Polymorph and am quite impressed. A small usability suggestion for the examples is to include comments with the text on a line by itself. It is a lot easier to execute something formatted as " ThisOrThat example ThisOrThat someOtherExample " than it is the (very common in Squeak) "GoAhead iChallengeYouToSelectMe andMissTheQuotes". On to more substantive things. TEasilyThemed is a big help, but some model and/or presenter classes would help. Consider a list. One has to define an aspect for the selection index and initialize it to zero. Similar comments apply to trees, with the added wrinkle of wrapping the nodes with appropriate objects. Dolphin's MVP framework creates default models that can be replaced. One weakness of the defaults is that they can take significant time to create for substantial objects. I hacked around that, and we could easily design it out of anything that we build. Dolphin lists and trees treat their selection in terms of the object selected rather than the index. One can get and set the index if needed, but it is not generally as interesting as the object behind the selection. One good thing about specifying the aspect is that one can can connect a view to an aspect of any model. Dolphin allows for the same flexibility via value adapters and type converters. Does TEasilyThemed include helpers for creating splitters? Bill ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2009

[Pharo-project] Fwd: [squeak-dev] The Trunk: Kernel-ar.271.mcz

by CÃ©drick BÃ©ler

---------- Forwarded message ---------- From: <commits(a)source.squeak.org> Date: 2009/10/15 Subject: [squeak-dev] The Trunk: Kernel-ar.271.mcz To: squeak-dev(a)lists.squeakfoundation.org Andreas Raab uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-ar.271.mcz ==================== Summary ==================== Name: Kernel-ar.271 Author: ar Time: 14 October 2009, 8:49:48 am UUID: a603d2fe-dccf-894f-95db-ef577480b03c Ancestors: Kernel-nice.270, Kernel-ul.270 Merging Kernel-ul.270: - faster DateAndTime and Date creation with #year:month:day: and friends - minor formatting fixes =============== Diff against Kernel-nice.270 =============== Item was changed: ----- Method: DateAndTime>>midnight (in category 'squeak protocol') ----- midnight "Answer a DateAndTime starting at midnight local time" + ^self class basicNew + setJdn: jdn + seconds: 0 + nano: 0 + offset: self class localOffset - ^ self - dayMonthYearDo: [ :d :m :y | self class year: y month: m day: d ] ! Item was changed: ----- Method: DateAndTime class>>year:month:day:hour:minute: (in category 'squeak protocol') ----- year: year month: month day: day hour: hour minute: minute + "Return a DateAndTime" + ^self - "Return a DateAndTime" ^ self year: year month: month day: day hour: hour minute: minute second: 0 ! Item was changed: ----- Method: DateAndTime class>>year:month:day:hour:minute:second:nanoSecond:offset: (in category 'squeak protocol') ----- year: year month: month day: day hour: hour minute: minute second: second nanoSecond: nanoCount offset: offset "Return a DateAndTime" + | monthIndex daysInMonth p q r s julianDayNumber | - | monthIndex daysInMonth p q r s julianDayNumber since | monthIndex := month isInteger ifTrue: [month] ifFalse: [Month indexOfMonth: month]. daysInMonth := Month daysInMonth: monthIndex forYear: year. day < 1 ifTrue: [self error: 'day may not be zero or negative']. day > daysInMonth ifTrue: [self error: 'day is after month ends']. p := (monthIndex - 14) quo: 12. q := year + 4800 + p. r := monthIndex - 2 - (12 * p). s := (year + 4900 + p) quo: 100. julianDayNumber := ( (1461 * q) quo: 4 ) + ( (367 * r) quo: 12 ) - ( (3 * s) quo: 4 ) + ( day - 32075 ). + ^self basicNew + setJdn: julianDayNumber + seconds: hour * 60 + minute * 60 + second + nano: nanoCount + offset: offset; - since := Duration days: julianDayNumber hours: hour - minutes: minute seconds: second nanoSeconds: nanoCount. - - ^ self basicNew - ticks: since ticks offset: offset; yourself! Item was changed: ----- Method: DateAndTime class>>year:month:day: (in category 'squeak protocol') ----- year: year month: month day: day + "Return a DateAndTime, midnight local time" + + ^self - "Return a DateAndTime, midnight local time" ^ self year: year month: month day: day hour: 0 minute: 0 ! -- CÃ©drick

Oct. 15, 2009

Re: [Pharo-project] About TestCase >> assert:

by Henrik Johansen

Why not rename Object>>assert: to should:, so it avoids breaking polymorphism, and keep TestCase>>assert: reserved for a boolean argument to stay compatible with SUnit in other dialects? On the negative side, it might not be as intuitive using should: for pre/post-assertions, as well as inconvenient to remember the difference between assert: and should: in TestCases. Not big enough negatives to outweigh the benefits though, imo. Cheers, Henry StÃ©phane Ducasse skrev: > The idea is that one day or later we will have to think about the > benefit of pre and post condition. > So assert: in object makes a lot of sense. > > Now indeed it would be good that all the tests use assert: without > block and use should: for that case. > > Stef > On Oct 15, 2009, at 3:55 AM, csrabak(a)bol.com.br wrote: > > >> I don't either, but I find strange the complete hierarchy of classes >> of Pharo having a method assert: available. Perhaps I'm blindfolded >> and Pharo and Squeak have found a wider use for assertions? >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Oct. 15, 2009

Re: [Pharo-project] About TestCase >> assert:

by StÃ©phane Ducasse

The idea is that one day or later we will have to think about the benefit of pre and post condition. So assert: in object makes a lot of sense. Now indeed it would be good that all the tests use assert: without block and use should: for that case. Stef On Oct 15, 2009, at 3:55 AM, csrabak(a)bol.com.br wrote: > > I don't either, but I find strange the complete hierarchy of classes > of Pharo having a method assert: available. Perhaps I'm blindfolded > and Pharo and Squeak have found a wider use for assertions?

Oct. 15, 2009