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

[Pharo-project] [update] 10478
by Adrian Lienhard Oct. 18, 2009

Oct. 18, 2009

!! We backtracked and removed the 1.1alpha branch again (we implement a more clever infrastructure for the update mechanism). Please take an image <=10477 and update. Delete existing images with version 10478. !! Issue 1310: Make all tests green (work in progress) Issue 818: MethodContext tempNames wrong implementation or usage for Closure Issue 1270: ClassBuilder wrong class format validation Issue 1317: Add MethodHighlightingTests back Tests for ImageSegment (including support for analyzing a segment) Adrian ___________________ http://www.adrian-lienhard.ch/

1 0

[Pharo-project] New Pharo based on core 10477
by Damien Cassou Oct. 18, 2009

Oct. 18, 2009

http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

1 0

[Pharo-project] [update] 10478: advance to 1.1 or stay at 1.0
by Marcus Denker Oct. 18, 2009

Oct. 18, 2009

Hi, There is now an update that asks to advance to 1.1 or stay at 1.0 If you stay at 1.0, you will get the following changes up to the release of 1.0 If yu advance to 1.1, you get all 1.1 unstable changes (which of course will include all the 1.0 ones, too). Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de 2denker UG (haftungsbeschrÃ¤nkt) Sitz KÃ¶ln Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker

1 0

[Pharo-project] ReleaseTest>>testUndeclared
by Michael Roberts Oct. 18, 2009

Oct. 18, 2009

this test fails because of this method UndefinedObject>>requestHostAndDisplay: version from Damien. Is there a reason why 1) this method is on nil class and 2) it has no senders, is it sent in another package? thanks Mike

2 1

[Pharo-project] [ANN] prebuilt Core #10477
by Marcus Denker Oct. 18, 2009

Oct. 18, 2009

Core #10477 ----------- http://gforge.inria.fr/frs/download.php/24356/PharoCore-1.0-10477-BETA.zip Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de

1 0

[Pharo-project] Fwd: [squeak-dev] Strange behavior of ContextVariableInspector
by StÃ©phane Ducasse Oct. 18, 2009

Oct. 18, 2009

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: October 16, 2009 12:10:14 AM GMT+02:00 > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: Re: [squeak-dev] Strange behavior of ContextVariableInspector > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > > > On Thu, Oct 15, 2009 at 1:02 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > I suspect this is due to latest updates to debugger & compiler etc, > brought by Eliot. > > To display a context variable 'contents', a message #contents is sent > to ContextVariableInspector. > The problem is, that in TextMorphForEditView>>newContents: > which sends this message to model (which is a > ContextVariableInspector) expects that returned value is text, or > string at least. > While at some point, this is not always true, and inspection of > different context slots in debugger could lead to interesting results, > where > #contents returns an actual object, which does not implements #asText > , and as result i often get an > DNU: SmallInteger>>asText > or similar. > > The root of evil, i think, is in > ContextVariableInspector>>toggleIndex: method, in following code: > > self contentsIsString > ifTrue: [contents := self selection] > ifFalse: [contents := self selectionPrintString]]. > > which sometimes returns an actual object (self selection) instead of > (self selectionPrintString). > > I don't really understand, what exactly tests the #contentsIsString > method: > > contentsIsString > "Hacked so contents empty when deselected" > > ^ #(0 2 3) includes: selectionIndex > > This defines which indices in the context inspector answer meta- > values rather than actual slot contents. Open up a debugger on the > activation of a method with args and/or temps and you'll see > thisContext > stack top > all temp vars > textOrStream > aContext > receiver > aRequestor > failBlock > logFlag > methodNode > method > value > toLog > itsSelection > itsSelectionString > thisContext is an object, but "stack top" and "all temp vars" are > strings computed by ContextvariablesInspector>>selection. i.e. > > selection > "Refer to the comment in Inspector|selection." > selectionIndex = 0 ifTrue:[^'']. > selectionIndex = 1 ifTrue: [^object]. > selectionIndex = 2 ifTrue: [^object stackPtr > 0 ifTrue: [object > top]]. > selectionIndex = 3 ifTrue: [^object tempsAndValues]. > ^object debuggerMap namedTempAt: selectionIndex - 3 in: object > > So the meta values at index 0 (unselected null string), 2 & 3 > shouldn't be sent printString, otherwise e.g. an unselected CVI > would show '' (the printString of ByteString new) instead of nothing. > > > maybe a proper fix would be to test additionally, that selection is > string, and if not, then return false, so > caller will use #selectionPrintString later. > > The right thing is to ensure thatContextvariablesInspector > contentsIsString fieldList replaceSelectionValue: & selection all > agree. I think I added "stack top" to the list. I may have > forgotten to integrate the changes for one or more of these which in > my image are (also attached): > > !ContextVariablesInspector methodsFor: 'accessing' stamp: 'eem > 5/21/2008 12:31'! > fieldList > "Refer to the comment in Inspector|fieldList." > > object == nil ifTrue: [^Array with: 'thisContext']. > ^fieldList ifNil:[fieldList := (Array with: 'thisContext' with: > 'stack top' with: 'all temp vars') , object tempNames]! ! > > !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem > 3/6/2009 10:05'! > contentsIsString > ^ #(0 3) includes: selectionIndex! ! > > !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem > 7/18/2008 11:18'! > replaceSelectionValue: anObject > "Refer to the comment in Inspector|replaceSelectionValue:." > > ^selectionIndex = 1 > ifTrue: [object] > ifFalse: [object namedTempAt: selectionIndex - 3 put: anObject]! ! > > !ContextVariablesInspector methodsFor: 'selecting' stamp: 'eem > 6/10/2008 09:37'! > selection > "Refer to the comment in Inspector|selection." > selectionIndex = 0 ifTrue:[^'']. > selectionIndex = 1 ifTrue: [^object]. > selectionIndex = 2 ifTrue: [^object stackPtr > 0 ifTrue: [object > top]]. > selectionIndex = 3 ifTrue: [^object tempsAndValues]. > ^object debuggerMap namedTempAt: selectionIndex - 3 in: object! ! > > -- > Best regards, > Igor Stasenko AKA sig. > > >

2 2

[Pharo-project] making all tests green -- ReleaseTest>>testObsoleteClasses (issue 1310)
by Oscar Nierstrasz Oct. 17, 2009

Oct. 17, 2009

When running all the tests, ReleaseTest>>testObsoleteClasses discovers some hundreds of generated classes that are not properly cleaned up. You can also get an inspector on these classes by running: SmalltalkImage current fixObsoleteReferences. (If the result is not empty, an inspector will pop up.) Here are the tests cases responsible for many of these classes: Tests-Traits -- 130 obsolete classes RequiresOriginalTestCase>>testSins creates CAB ... TraitsResource>>setUp creates C1 ... SUnit-Extensions, SUnit-Tests ? ClassFactoryForTestCase>>newName creates ClassForTestToBeDeleted IVsAndClassVarNamesConflictTest>>setUp creates ClassForTestToBeDeleted These sometimes are left as obsolete classes ... Tests-Monticello -- 2 obsolete classes MCFileInTest>> ... creates MCMockClassA MCMockClassG To check this, grab a clean pharo core image, run: SmalltalkImage current fixObsoleteReferences The result should be empty. Then run Tests-Traits (or any of the others) and re-run the expression. You will then see the obsolete classes. Exploring pointers to these classes however does not tell me why they are still hanging around. That's as far as I got. - on

1 0

Oct. 17, 2009

10477 ----- - Issue 1224: Avoiding uncessary pop up when compiling a method - Issue 1044: MethodContext allInstances loops forever

1 0

[Pharo-project] Issue 1311: Refactoring scope is broken
by Oscar Nierstrasz Oct. 17, 2009

Oct. 17, 2009

Take latest pharo1.0-10470-BETAdev09.10.2 (must be a dev image). - Select (say) AST-Nodes category (or any other category) - refactoring scope>super-sends - Yields: Error: Unknown character in literal array The same is observed for self-sends ... Also using the package browser. According to David Roethlisberger, this should be a problem in RB. It encounters a nil character while parsing all the methods, which happens when an unknown character is encountered. The problem appears to be an unknown character somewhere within ClosureCompilerTest>>#testInjectIntoDecompilations Deleting the body of this method "fixes" the problem :-( - on

4 6

Oct. 17, 2009

lukas we would like to clean the image using your _ -> := rewrite rules. How can do that? Stef

3 13