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

Re: [Pharo-project] Strange behavior of #printString method

by Schwab,Wilhelm K

I am by no means the expert on such things, but you caught my attention and a quick look at Array>>printOn: reveals #isLiteral and #isSelfEvaluating. The way an array prints itself changes if all of the arguments (and sometimes the receiver) fit the conditions. One of your arguments is probably failing to meet a condition in one case. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of nullPointer Sent: Tuesday, October 27, 2009 4:58 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Strange behavior of #printString method I donÂ´t understand the behavior of printString method. in a class I define a method #style , which returns an array... style style notNil ifTrue:[ ^style ] ifFalse:[ ^{ self borderColor . self borderWidth . self color . self gradientColor . (self cornerStyle = #rounded) . true }]. That method returns many times an Array. If #printString of that array is called the result is... '{Color black. 0. (Color r: 0.892 g: 0.887 b: 0.879). nil. false. true}' Well i have another method with same name in another class style ^{ self borderColor . self borderWidth . self color . self gradientColor . (self cornerStyle = #rounded) . true } but in that case when i call #printString of the Array result ... 'an Array(Color transparent 0 (Color r: 0.827 g: 0.827 b: 0.827) nil true true)'. I donÂ´t understand nothing :| Both are instances of Array, and both is declared of same way. Regards -- View this message in context: http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p39020… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ 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] Strange behavior of #printString method

by nullPointer

I donÂ´t understand the behavior of printString method. in a class I define a method #style , which returns an array... style style notNil ifTrue:[ ^style ] ifFalse:[ ^{ self borderColor . self borderWidth . self color . self gradientColor . (self cornerStyle = #rounded) . true }]. That method returns many times an Array. If #printString of that array is called the result is... '{Color black. 0. (Color r: 0.892 g: 0.887 b: 0.879). nil. false. true}' Well i have another method with same name in another class style ^{ self borderColor . self borderWidth . self color . self gradientColor . (self cornerStyle = #rounded) . true } but in that case when i call #printString of the Array result ... 'an Array(Color transparent 0 (Color r: 0.827 g: 0.827 b: 0.827) nil true true)'. I donÂ´t understand nothing :| Both are instances of Array, and both is declared of same way. Regards -- View this message in context: http://n2.nabble.com/Strange-behavior-of-printString-method-tp3902051p39020… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 27, 2009

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

by Schwab,Wilhelm K

Stef, I do not yet use Nile, but after learning a little more about the existing file streams, my first thought was "Nile is installed, right?" It would be a shame to see it removed. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Tuesday, October 27, 2009 4:34 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Making packages shipped with Pharo ready for 1.0 Adrian I will have a look at Nile with cyrille and else we remove it from 1.0 (which would be a pity). Stef On Oct 27, 2009, at 5:04 PM, Adrian Lienhard wrote: > 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? > > > _______________________________________________ > 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] Making packages shipped with Pharo ready for 1.0

by StÃ©phane Ducasse

Adrian I will have a look at Nile with cyrille and else we remove it from 1.0 (which would be a pity). Stef On Oct 27, 2009, at 5:04 PM, Adrian Lienhard wrote: > 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? > > > _______________________________________________ > 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 Adrian Lienhard

Thanks, Lukas! Damien will certainly pick up the gofer script you posted. Indeed, OB-Web is loaded and obviously should not. Also we should check that the version of OB is the newest one. Cheers, Adrian On Oct 27, 2009, at 17:36 , Lukas Renggli wrote: >> 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 > <rb.pdf>_______________________________________________ > 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] Thread-safe collections

by Schwab,Wilhelm K

John, I'm not sure whether we agree or disagree on individual points, but that's ok. I will invoke Sig in the case of 10^6 entries - something tells me one would end up with a customized implementation long before a weak collection became that large. However, I think automatic cleanup is important to keep a long-lived map from getting that large. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Tuesday, October 27, 2009 12:27 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections On 2009-10-26, at 10:37 PM, Igor Stasenko wrote: > and why the key should go away? > I think that this is an implementation nuance, but not bug or missing > feature. > No-one would expect from dictionary keys to automatically mutate > depending on the state of the associated values. > If you want such behavior, why not implement own WeakLookupTable ? > Ok, well (a) I don't think any of the set or dictionary logic is particularly written with thread safety in mind. No doubt a Mutex is needed to protect the integrity of the data. Someone can decide which version of Pharo should a fix for 0006955 (b) Although as Igor mentioned the fact the key goes away is a implementation detail, this in fact is useful. The situation you run into is storing entities in a weak value dictionary where the values do disappear however if you store a million entries then you end up with a million keys, so who is responsible for the cleanup? -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ 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 Damien Cassou

On Tue, Oct 27, 2009 at 4:00 PM, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: > By the way, what is the proper way to propose changes to the dev image script? Talk about them on the mailing list and add me on CC. Also, open an issue in the tracker and assign it to me. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Oct. 27, 2009

Re: [Pharo-project] update server down?

by Michael Roberts

There you go! I will pay more attention mike On Tuesday, October 27, 2009, Tudor Girba <tudor.girba(a)gmail.com> wrote: > The GForge maintenance was announced in a forward by Stef on Oct 23 :). > > Doru > > > On 27 Oct 2009, at 10:07, Michael Roberts wrote: > >> Probably. Where are they announced? Can they be posted here? >> >> Cheers mike >> >> On Tuesday, October 27, 2009, Tudor Girba <tudor.girba(a)gmail.com> >> wrote: >>> Wasn't this problem due to the announced maintenance of GForge for >>> Monday 26th October 2009, from 18:30 to 22:00? >>> >>> Doru >>> >>> On 27 Oct 2009, at 08:57, Michael Roberts wrote: >>> >>>> yes it's working now. thanks >>>> Mike >>>> >>>> On Tue, Oct 27, 2009 at 7:51 AM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> apparently the forge was down yesterday evening. >>>>> Not sure that this is available now. >>>>> >>>>> On Oct 26, 2009, at 8:31 PM, Michael Roberts wrote: >>>>> >>>>>> i'm getting timeouts from the update server. can someone confirm? >>>>>> >>>>>> thanks, >>>>>> Mike >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving should be concentrated on describing >>> the problem in a way that is relevant for the solution." >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > _______________________________________________ > 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] Thread-safe collections

by John M McIntosh

On 2009-10-26, at 10:37 PM, Igor Stasenko wrote: > and why the key should go away? > I think that this is an implementation nuance, but not bug or > missing feature. > No-one would expect from dictionary keys to automatically mutate > depending on the state of the associated values. > If you want such behavior, why not implement own WeakLookupTable ? > Ok, well (a) I don't think any of the set or dictionary logic is particularly written with thread safety in mind. No doubt a Mutex is needed to protect the integrity of the data. Someone can decide which version of Pharo should a fix for 0006955 (b) Although as Igor mentioned the fact the key goes away is a implementation detail, this in fact is useful. The situation you run into is storing entities in a weak value dictionary where the values do disappear however if you store a million entries then you end up with a million keys, so who is responsible for the cleanup? -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 27, 2009

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

by StÃ©phane Ducasse

say it on the mailing-list and damien takes into account the result. Stef > 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 >>> >> > > _______________________________________________ > 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