- Pharo-dev - lists.pharo.org

[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

[Pharo-project] [update] #10477
by StÃ©phane Ducasse Oct. 17, 2009

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

[Pharo-project] _ into := changes based on RB
by StÃ©phane Ducasse Oct. 17, 2009

Oct. 17, 2009

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

3 13

[Pharo-project] [update] #10476
by StÃ©phane Ducasse Oct. 17, 2009

Oct. 17, 2009

10476 ----- Fix underscores

1 0

[Pharo-project] [update] #10475
by StÃ©phane Ducasse Oct. 17, 2009

Oct. 17, 2009

10475 ----- Issue 70: 7120 AndreasUTF8andFontsEnh

1 0

Oct. 17, 2009

10474 ----- - Issue 1183: OB in latest DEV draws wrong shadow on dragging - Issue 1314: StrikeFont baseKern change

2 1

[Pharo-project] Follow us on twitter!
by Niko Schwarz Oct. 17, 2009

Oct. 17, 2009

You can follow our progress on twitter! Just open this page: http://twitter.com/#search?q=%23pharolille We're using the twitter tag #Pharolille niko

1 1

Oct. 17, 2009

- Issue 1258: .1 asNumber = 0 This is true in Pharo, likely resulting in an adventure for the developer - Issue 987: stack top variable on debugger crashes it

1 0