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

Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0

by Nicolas Cellier

2009/10/27 Adrian Lienhard <adi(a)netstyle.ch>: > Pharo-core tests failing > ------------------------ > - FontTest>>testFallback (assumes different font, to be removed) > - FontTest>>testParagraphFallback (assumes different font, to be > removed) > - FontTest>>testResetAfterEmphasized (assumes different font, to be > removed) > - StandardSystemFontsTest>>testRestoreDefaultFonts (assumes different > font, to be removed) > - TestIndenting>>testNewLineStartsIndentedWhenWrapped (assumes > different font, to be removed) > - TestIndenting>>testSetUp (assumes different font, to be removed) > - LocaleTest>>testIsFontAvailable (some Japanese font checking that > fails with DejaVu, to be removed) > - testFinalizationOfEquals (was on my to do list, but works again: > remove expected failure tag) This remind me discussions with Norbert http://bugs.squeak.org/view.php?id=6347 and also http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-September/13165… Nicolas > - testObsoleteClasses: again includes classes from MC and others (have > to be checked) > > MorphExamplesAndDemos > --------------------- > - undeclared references to DescriptionForPartsBin and ScreeningMorph > > Cheers, > Adrian > > BTW, Damien, do we know for each package who the maintainer is? Does > each package have one? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 27, 2009

Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0

by Lukas Renggli

> RB > -- > - undeclared reference to RBBasicLintRuleTest and > RBTransformationRuleTest I take responsible for the AST and Refactoring packages. I believe these undeclared references have been fixed quite some time ago. See the attached dependency graph for details. Please make sure to take the latest code, the current Pharo distributions use outdated packages. I suggest that you do not load the separately packaged tests, some tests must fail because some parts of the refactoring engine are broken. It is getting better though, I already fixed over 40 tests and discovered and fixed many tests. Also some basic refactorings without reformatting the code are in reach. Use the following snipped to load the latest code: Gofer new squeaksource: 'rb'; addPackage: 'AST-Core'; addPackage: 'Refactoring-Core'; addPackage: 'Refactoring-Spelling'; load. > OB > ------ > - undeclared references: HttpResponse, Json, JsonObject It looks like the Pharo images contains OB-Web (the web view for OB), while all the prerequisites (Kom, Json) are not loaded. > - #dropOnClass: references InputSensor (this class does not exist > anymore!) That was fixed a long time ago. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 27, 2009

[Pharo-project] [SIXX] feedback

by Schwab,Wilhelm K

Masashi, Thanks for adding support for Pharo! So far, I have tried only the example from the workspace opened by the installation, but it was nice to see it work. Your timing was perfect, because I just encountered my first need for a serializer on Pharo. The download packaging and instructions are a little confusing. Under Installation, you say to file in install.st. The only mention of Pharo in the download section is next to the .sar file, which Pharo appears to load correctly. If the .sar is the intended way to load it, it should be mentioned in the Installation section. Thanks! Bill

Oct. 27, 2009

[Pharo-project] Making packages shipped with Pharo ready for 1.0

by Adrian Lienhard

Hi, I've more closely looked at the failing tests and undeclared references in the Pharo image. The test result is 14 expected failures, 34 failures, 54 errors, 2 unexpected passes. Considering that the Pharo-core ships with all tests green, this situation needs to be fixed. I urge the package maintainers to closely look at the list below and provide fixes and cleanups of their code. There are also 9 tests failing from Pharo-core. I will take care of those. Nil ----- - Sends deprecated message: #findLastOccuranceOfString:startingAt: - A test opens a workspace that says: "Squeak is a beautiful language. Look at http:\\www.squeak.org ..." - Another test opens another workspace - NSBuffer has method that references an undeclared variable 'collection' - undeclared reference to GradientFillMorph, StringSocketStream - Total failing tests: 10 - Total tests with errors: 11 ECompleteion ------------ - 7 tests failing - 2 errors O2 -- - #dropOnClass: references InputSensor (this class does not exist anymore!) - 15 undeclared references to OB* classes, to non-existent variable hasChanges, modifiedTimeStamp, smartGroup, and sensor - 11 failing tests - >30 tests with errors OB ------ - undeclared references: HttpResponse, Json, JsonObject - #dropOnClass: references InputSensor (this class does not exist anymore!) NewInspector ------------ - undeclared reference automaticallyHideIfNoChild - NewInspector DNU #inspect (sent in #testSymbolTableM6812) Shout ----- - undeclared variable sourceMap RB -- - undeclared reference to RBBasicLintRuleTest and RBTransformationRuleTest Pharo-core tests failing ------------------------ - FontTest>>testFallback (assumes different font, to be removed) - FontTest>>testParagraphFallback (assumes different font, to be removed) - FontTest>>testResetAfterEmphasized (assumes different font, to be removed) - StandardSystemFontsTest>>testRestoreDefaultFonts (assumes different font, to be removed) - TestIndenting>>testNewLineStartsIndentedWhenWrapped (assumes different font, to be removed) - TestIndenting>>testSetUp (assumes different font, to be removed) - LocaleTest>>testIsFontAvailable (some Japanese font checking that fails with DejaVu, to be removed) - testFinalizationOfEquals (was on my to do list, but works again: remove expected failure tag) - testObsoleteClasses: again includes classes from MC and others (have to be checked) MorphExamplesAndDemos --------------------- - undeclared references to DescriptionForPartsBin and ScreeningMorph Cheers, Adrian BTW, Damien, do we know for each package who the maintainer is? Does each package have one?

Oct. 27, 2009

Re: [Pharo-project] OCompletion in the rc1 dev image

by Niko Schwarz

By the way, what is the proper way to propose changes to the dev image script? On Tue, Oct 27, 2009 at 3:57 PM, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > My image is indeed still on version damiencassou.33. I marked the bug > as 1.0 in the bugtracker > (http://code.google.com/p/pharo/issues/detail?id=1351) hoping that it > will be integrated in the next 1.0 dev image, as the image is hardly > usable without the fix. > > Cheers, > > Niko > > On Tue, Oct 27, 2009 at 3:18 PM, Romain Robbes > <romain.robbes(a)lu.unisi.ch> wrote: >> Niko, >> >> What is the version of OCompletion in the image? >> >> I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. >> If you are indeed using that version, I'll have a look at your fix. >> Otherwise, it is just a matter of time before the >> latest version of OCompletion is used instead of the older one. >> >> Cheers, >> Â Â Â Â Romain >> >> On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: >> >>> Hi list, >>> >>> in the most recent dev image (9.10.5), OCompletion is broken for me. >>> >>> I lost my reproducible test case, but the gist was that sometimes when >>> OCompletion had no idea which type a temporal variable would be, you >>> were unable to insert code behind that variable, because if you tried, >>> a debugger would show up. >>> >>> The problem appears to be Debugger>guessTypeForName:. debuggerMap can >>> be nil and if it is, the method fails. I changed the method to the >>> following, and then the strange errors that occur on my image >>> disappear: >>> >>> guessTypeForName: aString >>> Â Â Â | index object | >>> Â Â Â index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: >>> self selectedContext) >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â indexOf: aString >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifAbsent: []]. >>> Â Â Â object := index >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifNil: [index := self receiver class allInstVarNames >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â indexOf: aString >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifAbsent: []. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â index ifNil: [^ nil]. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self receiver instVarAt: index] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [self selectedContext tempAt: index]. >>> Â Â Â ^ object class >>> >>> Essentially, I leave index at nil, if debugerMap is nil. >>> >>> I don't know enough about OCompletion to tell whether this is a fix, >>> or makes things worse somehow. >>> >>> Cheers, >>> >>> Niko >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Romain Robbes >> http://www.inf.unisi.ch/phd/robbes >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Oct. 27, 2009

[Pharo-project] update server down?

by Torsten Bergmann

>Probably. Where are they announced? Can they be posted here? It was not planned, looks like the server is/was in trouble: (it already had outages one year back) More details (October 25, October 18): http://squeakboard.wordpress.com You could also follow: http://lists.squeakfoundation.org/pipermail/box-admins/ Bye Torsten -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Oct. 27, 2009

Re: [Pharo-project] OCompletion in the rc1 dev image

by Niko Schwarz

My image is indeed still on version damiencassou.33. I marked the bug as 1.0 in the bugtracker (http://code.google.com/p/pharo/issues/detail?id=1351) hoping that it will be integrated in the next 1.0 dev image, as the image is hardly usable without the fix. Cheers, Niko On Tue, Oct 27, 2009 at 3:18 PM, Romain Robbes <romain.robbes(a)lu.unisi.ch> wrote: > Niko, > > What is the version of OCompletion in the image? > > I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. > If you are indeed using that version, I'll have a look at your fix. > Otherwise, it is just a matter of time before the > latest version of OCompletion is used instead of the older one. > > Cheers, > Â Â Â Â Romain > > On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: > >> Hi list, >> >> in the most recent dev image (9.10.5), OCompletion is broken for me. >> >> I lost my reproducible test case, but the gist was that sometimes when >> OCompletion had no idea which type a temporal variable would be, you >> were unable to insert code behind that variable, because if you tried, >> a debugger would show up. >> >> The problem appears to be Debugger>guessTypeForName:. debuggerMap can >> be nil and if it is, the method fails. I changed the method to the >> following, and then the strange errors that occur on my image >> disappear: >> >> guessTypeForName: aString >> Â Â Â | index object | >> Â Â Â index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: >> self selectedContext) >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â indexOf: aString >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifAbsent: []]. >> Â Â Â object := index >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifNil: [index := self receiver class allInstVarNames >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â indexOf: aString >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifAbsent: []. >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â index ifNil: [^ nil]. >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self receiver instVarAt: index] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [self selectedContext tempAt: index]. >> Â Â Â ^ object class >> >> Essentially, I leave index at nil, if debugerMap is nil. >> >> I don't know enough about OCompletion to tell whether this is a fix, >> or makes things worse somehow. >> >> Cheers, >> >> Niko >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Romain Robbes > http://www.inf.unisi.ch/phd/robbes > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 27, 2009

[Pharo-project] *ServiceProvider classes??

by Schwab,Wilhelm K

Hello all, Something, perhaps SIF, is creating creating classes named *ServiceProvider in a new category named *. Any ideas? Bill

Oct. 27, 2009

Re: [Pharo-project] [update] #10492 (1.0rc1)

by StÃ©phane Ducasse

may be you are right. I do not know so at least we should check all the users in the system On Oct 27, 2009, at 3:13 PM, Niko Schwarz wrote: > Well, by doing that you will confuse users that only relied on the > consensual functionality of asNumber. > > It's difficult both ways, and because of that, I'd suggest going the > lazy way and not helping the users other than by adding a comment to > #asNumber which explains the evolution of the message and points to > #squeezeOutNumber. I know that the users would appreciate help in the > migration, but I don't see a non-obtrusive way to do so. > > Cheers, > > Niko > > On Tue, Oct 27, 2009 at 2:59 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Not really >> >> we could do the following >> - check all the users of asNumber and let them as asNUmber or >> squeezeOutNumber >> - then put a deprecation during the alpha phase that state >> that they >> should pay attention >> - when we are in rc 1.1 we remove the deprecation >> - create a package which would override it with a deprecation. >> >> stef >> >> >> On Oct 27, 2009, at 2:38 PM, Niko Schwarz wrote: >> >>> Well, what do you propose? Deprecating asNumber calls altogether? >>> >>> Cheers, >>> >>> Niko >>> >>> On Sat, Oct 24, 2009 at 10:32 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Yes a good deprecation is needed. >>>> >>>> Stef >>>> On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote: >>>> >>>>> Sounds ok. At the same time as integrating the change, all senders >>>>> of >>>>> asNumber in the image need to be checked and adapted to the new >>>>> semantics if necessary. IIRC MC was not properly working after the >>>>> change. Also, users and maintainers of external packages should be >>>>> made aware of the change since it may break their code. >>>>> >>>>> Adrian >>>>> >>>>> On Oct 24, 2009, at 10:46 , StÃ©phane Ducasse wrote: >>>>> >>>>>> Thanks niko >>>>>> >>>>>> So does everybody agree with >>>>>> asNumber raising an error >>>>>> and >>>>>> squeezeOutNumber >>>>>> >>>>>> I like the proposal. >>>>>> >>>>>> Stef >>>>>> >>>>>> On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote: >>>>>> >>>>>>> Hi all, I made a follow-up patch like discussed on the workshop. >>>>>>> Now >>>>>>> porting becomes as easy as changing "asNumber" to >>>>>>> "squeezeOutNumber". >>>>>>> >>>>>>> Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2 >>>>>>> >>>>>>> >>>>>>> This slice adds squeezeNumberOutOfString: to Number, as >>>>>>> discussed in >>>>>>> the Pharo workshop. On the way, it >>>>>>> fixes an issue in SqNumberParser, where it would return itself >>>>>>> rather >>>>>>> than the result of the failblack, when >>>>>>> parsing fails. >>>>>>> >>>>>>> Also, a test is added to test and document the new squeezing >>>>>>> number >>>>>>> out of strings behavior. >>>>>>> >>>>>>> Example usage: >>>>>>> >>>>>>> self assert: '123blabla' squeezeOutNumber equals: 123. >>>>>>> self assert: 'blabla123' squeezeOutNumber equals: 123. >>>>>>> self assert: 'blabla12blabla' squeezeOutNumber equals: 12. >>>>>>> self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < >>>>>>> 0.0001. >>>>>>> self assert: '.1' squeezeOutNumber > 0. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Niko >>>>>>> >>>>>>> On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard <adi(a)netstyle.ch >>>>>>> > >>>>>>> wrote: >>>>>>>> 10492 (this is the stream of the branch 1.0rc1) >>>>>>>> ----- >>>>>>>> >>>>>>>> - Issue 1320: [squeak trunk] Sort the conflicts. This is >>>>>>>> required >>>>>>>> when >>>>>>>> merging a distant version, like Pharo for example... >>>>>>>> - Issue 1338: HostWindowTests>>testOne is failing in Windows >>>>>>>> - Issue 1345: Revert Number class>>readFrom: (was integrated >>>>>>>> with >>>>>>>> issue 1258) >>>>>>>> >>>>>>>> ___________________ >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 27, 2009

Re: [Pharo-project] OCompletion in the rc1 dev image

by Romain Robbes

Niko, What is the version of OCompletion in the image? I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. If you are indeed using that version, I'll have a look at your fix. Otherwise, it is just a matter of time before the latest version of OCompletion is used instead of the older one. Cheers, Romain On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: > Hi list, > > in the most recent dev image (9.10.5), OCompletion is broken for me. > > I lost my reproducible test case, but the gist was that sometimes when > OCompletion had no idea which type a temporal variable would be, you > were unable to insert code behind that variable, because if you tried, > a debugger would show up. > > The problem appears to be Debugger>guessTypeForName:. debuggerMap can > be nil and if it is, the method fails. I changed the method to the > following, and then the strange errors that occur on my image > disappear: > > guessTypeForName: aString > | index object | > index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: > self selectedContext) > indexOf: aString > ifAbsent: []]. > object := index > ifNil: [index := self receiver class allInstVarNames > indexOf: aString > ifAbsent: []. > index ifNil: [^ nil]. > self receiver instVarAt: index] > ifNotNil: [self selectedContext tempAt: index]. > ^ object class > > Essentially, I leave index at nil, if debugerMap is nil. > > I don't know enough about OCompletion to tell whether this is a fix, > or makes things worse somehow. > > Cheers, > > Niko > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

Oct. 27, 2009