January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Pharo News Blog

by Tudor Girba

Excellent, indeed. Doru On 16 Jan 2010, at 18:20, Alexandre Bergel wrote: > Excellent > > Alexandre > > > On 16 Jan 2010, at 13:48, Adrian Lienhard wrote: > >> Hi all, >> >> We've started a blog on the Pharo website: >> >> http://www.pharo-project.org/news >> >> The goal of this blog is to regularly publish interesting news about >> Pharo (maybe once or twice a month). This allows people who do not >> have the time to closely follow the mailing list to stay up to date. >> >> Hope you like it! >> >> Cheers, >> Adrian >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testBlockNumbering

by Nicolas Cellier

By the way, I created http://code.google.com/p/pharo/issues/detail?id=1837 for these tests 2010/1/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I will check. > > Stef > > On Jan 16, 2010, at 5:14 PM, Nicolas Cellier wrote: > >> Then blockExtentsToTempsMap values are Arrays of pairs, not exactly >> what expected by the test... >> >> Nicolas >> >> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs >>> >>> But then, method still fails because keys does not answer a Set >>> anymore. Use keys asSet. >>> >>> Nicolas >>> >>> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> The test is incompatible with new CompiledMethod trailer >>>> Use generate rather than generate: #(0 0 0 0) >>>> >>>> Then the method still fails because sending unimplemented >>>> #blockExtentsToTempRefs >>>> >>>> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto >>>> >>>> Nicolas >>>> >>> >> >> _______________________________________________ >> 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 >

Jan. 16, 2010

Re: [Pharo-project] Date fromString: '6-Jan-10'

by StÃ©phane Ducasse

Yes Date fromString: '6-Jan-03' -> 6 January 2003 is also wrong. So david just tried to patch this wrong behavior. Stef On Jan 16, 2010, at 6:02 PM, csrabak(a)bol.com.br wrote: > I'm afraid the 'fix' is trying to repair something is not broken! > > Date fromString: '6-Jan-10'. giving "6 January 1910" has not anything wrong. Within five year we'll have users/programmers complaining that: > > Date fromString: '6-Jan-16'. gave "6 January 1916" and *obviously* it should have given "6 January 2015"!! > > Rather document that years given with two figures get counted from 1900 (as it used to be in last century) and have people to use four digits for years in the 2000s. > > Otherwise: > > 1) We need to get used to the concept of an epoch time for Pharo; or > > 2) the number to be tested has to be the current year! > > My 0.019999. . . > > -- > Cesar Rabak > > > Em 16/01/2010 07:57, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > > > hi guys > > can one of you give a look at the this fix because I'm confused. Kernel-DavidHotham.538 > > year < 20 ifTrue: [year := 2000 + year] > was > year < 10 ifTrue: [year := 2000 + year] > > both solutions look strange to me. > > http://code.google.com/p/pharo/issues/detail?id=1749 > > > readFrom: aStream > "Read a Date from the stream in any of the forms: > (5 April 1982; 5-APR-82) > (April 5, 1982) > (4/5/82) > (5APR82)" > | day month year | > aStream peek isDigit > ifTrue: [day := Integer readFrom: aStream]. > [aStream peek isAlphaNumeric] > whileFalse: [aStream skip: 1]. > aStream peek isLetter > ifTrue: ["number/name... or name..." > month := (String new: 10) writeStream. > [aStream peek isLetter] > whileTrue: [month nextPut: aStream next]. > month := month contents. > day isNil > ifTrue: ["name/number..." > [aStream peek isAlphaNumeric] > whileFalse: [aStream skip: 1]. > day := Integer readFrom: aStream]] > ifFalse: ["number/number..." > month := Month nameOfMonth: day. > day := Integer readFrom: aStream]. > [aStream peek isAlphaNumeric] > whileFalse: [aStream skip: 1]. > year := Integer readFrom: aStream. >>> year < 20 ifTrue: [year := 2000 + year] > ifFalse: [ year < 1900 ifTrue: [ year := 1900 + year]]. > > ^ self > year: year > month: month > day: day > _______________________________________________ > 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

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testBlockNumbering

by StÃ©phane Ducasse

I will check. Stef On Jan 16, 2010, at 5:14 PM, Nicolas Cellier wrote: > Then blockExtentsToTempsMap values are Arrays of pairs, not exactly > what expected by the test... > > Nicolas > > 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs >> >> But then, method still fails because keys does not answer a Set >> anymore. Use keys asSet. >> >> Nicolas >> >> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> The test is incompatible with new CompiledMethod trailer >>> Use generate rather than generate: #(0 0 0 0) >>> >>> Then the method still fails because sending unimplemented >>> #blockExtentsToTempRefs >>> >>> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto >>> >>> Nicolas >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testNewLineStartsIndentedWhenWrapped

by StÃ©phane Ducasse

thanks Kanban master! Stef > If paragraph composition width is reduced by 24 instead of 20, the > test works (taken from trunk) > > testNewLineStartsIndentedWhenWrapped > "Checks whether the beginning of a new line starts at the indented position" > | cb | > para compositionRectangle: (0@0 extent: para width - 24@100); > updateCompositionHeight. > para clippingRectangle: (0@0 extent: 200@200). > cb := para characterBlockForIndex: 8. > self assert: cb top > 0. > self assert: cb left = 24 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testToDoOutsideTempNotInlined

by StÃ©phane Ducasse

no problem. I will revert that. we cannot move without breaking eggs and after we do omelette :) Stef On Jan 16, 2010, at 4:05 PM, Nicolas Cellier wrote: > Sorry this is an effect of automatic move of temps inside blocks... > testToDoOutsideTempNotInlined REQUIRES that | temp | be declared > outside the block. > Just revert to previous version from Lukas > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testOtherClasses

by StÃ©phane Ducasse

Thanks This is what I was seeing before going shopping :) (don't go to ikea saturday afternoon. but marcus gets more chairs now :)) On Jan 16, 2010, at 3:54 PM, Nicolas Cellier wrote: > DependentsArray is no more a subclass of ArrayedCollection. > Apart this test, there is 0% chance to send byteSize nor > bytesPerBasicElement to a DependentsArray. > Simply remove DependentsArray from this test. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testAllLocalCallsOn

by StÃ©phane Ducasse

Yes thanks. I will probably kill them. or create a fixture that is stable On Jan 16, 2010, at 2:47 PM, Nicolas Cellier wrote: > Same for testAllCallsOn, this test is obsolete as soon as you make > modifications in Pharo :) > > Such test should use specific classes and messages specially crafted > for the test > > Nicolas > > 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> testAllLocalCallsOn >> " >> self debug: #testAllLocalCallsOn >> " >> >> | set | >> set := Array allLocalCallsOn: #printOn:. >> self assert: (set asArray = #('WeakActionSequence printOn:' 'Object >> fullPrintString' 'Array printOn:' 'SequenceableCollection >> asStringWithCr' 'Behavior printOn:' 'Class fileOutPool:onFileStream:' >> 'Object printStringLimitedTo:' 'Collection printNameOn:' >> 'ActionSequence printOn:' 'FixedIdentitySet printOn:')). >> "This is a bit strange that allLocalCallsOn: returns a list of string!" >> >> This one is bad for two reasons: >> 1) it relies on an arbitrary order in Set. For example, just change >> default size of sets and the order will change. Eventually you could >> test set = #() asSet but see 2) >> 2) it relies on a particular snapshot of pharo and prevent pharo from evolving. >> >> Moreover, if a user adds its own sender of printOn: in an extension or >> a subclass, this will make the test fail... >> >> Such test should create a class hierarchy dedicated to the test with a >> know set of senders and test >> Either correct it or remove it. >> >> Nicolas >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 16, 2010

Re: [Pharo-project] Package Browser and Pharo

by Alexandre Bergel

Tomorrow or Tuesday I will sit down with David and figure out why/how O2 breaks OB Alexandre On 16 Jan 2010, at 05:09, StÃ©phane Ducasse wrote: > > On Jan 16, 2010, at 12:16 AM, Alexandre Bergel wrote: > >> Hi! >> >> David arrived today and will spend few days among us. I would like to >> define a roadmap on how to improve the state of O2PackageBrowser. The >> main problem people have with O2PackageBrowser is the overrides made >> by O2PackageBrowser right? These overrides break OB. This is >> something >> we will fix. >> >> I would like that people who are using O2PackageBrowser to add their >> wishes and bug report on code.google please. Add David and me as Cc. >> We will look for the entries by entering O2 in the search field. > > Alex > > the main point is how to extend OB without breaking it. So may be > this requires some coordination with lukas. > Because else we will have the same problem in a couple of months. > > I would drastically simplify the browser: > - focus on packages and traits support > - remove the smart groups management since romain as a orthogonal > solution. > > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 16, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by GermÃ¡n Arduino

Thanks by the response Mariano. As I've said before I'm not using yet Seaside 3.0, but as I'm developing a new system, wanted to try to port now when the system is being born. I'm also on Metacello list, will check about this. My question was because my systems use heavily Magritte and need to have it on 3.0 to try anything. Thanks. GermÃ¡n. 2010/1/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Thanks GermÃ¡n, you asked a very good question. I already asked Dale as soon > as I read your email. I suggest you subscribe to metacello group as Dale is > maintaining all Seaside related configurations. > > For the moment, would you mind trying this in this dev (clean): > > That will load Seaside 2.8 + Magritte > > (ConfigurationOfMagritte project version: '1.2.1') load: #('Magritte-Model' > 'Magritte-Tests' 'Magritte-Seaside' ) > > I didn't found anything for 3.0 > > And for Pier + Magritte + Seaside 2.8 > > (ConfigurationOfPier project version: '1.2.1') load > > That's all I know for the moment. However, remember that you can install > Seaside in other ways for the moment. For example you can look at the script > used in the dev image before (I attach it if you want to look). However, all > these configurations will be fixed soon. > > Thanks > > Mariano > > On Sat, Jan 16, 2010 at 5:52 PM, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: >> >> After this mail I tried to install Magritte using >> "ConfigurationOfMagritte" from MetacelloRepository, but fails. >> >> This version of Magritte don't install with Seaside 3.0 ? >> >> Cheers. >> GermÃ¡n. >> >> >> 2010/1/16 GermÃ¡n Arduino <garduino(a)gmail.com>: >> > Hi: >> > >> >> 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> Hi Folks/Beta-Testers! >> >>> >> >>> 6) There is no Web image this time. If you want to install Seaside >> >>> 2.8.4 >> >>> evaluate: >> >>> >> >>> Gofer new >> >>> Â Â Â squeaksource: 'MetacelloRepository'; >> >>> Â Â Â package: 'ConfigurationOfSeaside28'; >> >>> Â Â Â load. >> >>> >> >>> (Smalltalk at: #ConfigurationOfSeaside28) load >> >>> >> >>> And if you want Seaside 3.0 evaluate: >> >>> >> >>> Gofer new >> >>> Â Â Â squeaksource: 'MetacelloRepository'; >> >>> Â Â Â package: 'ConfigurationOfSeaside30'; >> >>> Â Â Â load. >> >>> >> >>> (Smalltalk at: #ConfigurationOfSeaside30) loadLatestVersion >> >>> >> >>> However, I am not sure if this is perfectly working in Pharo. >> > >> > I started today, with the intention of port a new system I'm >> > developing directly to Seaside 3.0. >> > >> > All the installation seems to works ok, I must try more yet, but a >> > thing I noticed is not included >> > and should by (imho) is Magritte. >> > >> > Just my 0.02 >> > >> > Cheers. >> > GermÃ¡n. >> > >> >> _______________________________________________ >> 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 >

Jan. 16, 2010