- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] prebuilt Core #10477

by Marcus Denker

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

Oct. 18, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Strange behavior of ContextVariableInspector

by StÃ©phane Ducasse

Excellent! I like this music :) Stef On Oct 18, 2009, at 12:18 AM, Henrik Johansen wrote: > That was issue 987 from the bugtracker, which you closed earlier > today after integrating the fix made as per Eliot's pointers. ;) > > Cheers, > Henry > On Oct 17, 2009, at 7:30 18PM, StÃ©phane Ducasse wrote: > >> >> >> 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. >>> >>> >> <ContextVariablesInspector.st> >>> >> >> _______________________________________________ >> 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. 18, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Strange behavior of ContextVariableInspector

by Henrik Johansen

That was issue 987 from the bugtracker, which you closed earlier today after integrating the fix made as per Eliot's pointers. ;) Cheers, Henry On Oct 17, 2009, at 7:30 18PM, StÃ©phane Ducasse wrote: > > > 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. >> >> > <ContextVariablesInspector.st> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 17, 2009

Re: [Pharo-project] VNC (RFB) problem (2nd attempt)

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 17-10-2009 a las 22:26 +0400, Dennis Schetinin escribiÃ³: > > > 2009/10/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > > Thank you for your help very much. > > > Using pharo1.0-10466-BETAweb09.10.1 + > RFB-DamienCassou.28 > > (still the latest): the image stops to respond after > closing > > connection remotely. Stopping the server leaves > image ok. > > > > I can't reproduce it on a PharoCore 10470 image. > ... > > I can't reproduce it on PharoCore or > pharo1.0-10466-BETAweb09.10.1 > > And I have the same problem with this image too. So, the problem can > be in my VNC client or perhaps in VM... I'll try to check both > variants. Will be thankful for more ideas. Yes, try other clients. I have very distinct results (in video quality) by using different clients. right now I am using ii gvncviewer 0.3.9-1 VNC viewer using gtk-vnc on Debian Squeeze and haven't had any problems. Also, check with Ctrl + . or Cmd + . which process is freezing the image. Check if there is a PharoDebug.log in the folder/directory where you have the image for some hints. Cheers > > > -- > Dennis Schetinin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 17, 2009

Re: [Pharo-project] VNC (RFB) problem (2nd attempt)

by Dennis Schetinin

2009/10/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> Thank you for your help very much. > Using pharo1.0-10466-BETAweb09.10.1 + RFB-DamienCassou.28 > > (still the latest): the image stops to respond after closing > > connection remotely. Stopping the server leaves image ok. > > > I can't reproduce it on a PharoCore 10470 image. > ... > I can't reproduce it on PharoCore or pharo1.0-10466-BETAweb09.10.1 > And I have the same problem with this image too. So, the problem can be in my VNC client or perhaps in VM... I'll try to check both variants. Will be thankful for more ideas. -- Dennis Schetinin

Oct. 17, 2009

Re: [Pharo-project] VNC (RFB) problem (2nd attempt)

by Miguel Enrique CobÃ¡ Martinez

El miÃ©, 14-10-2009 a las 11:51 +0400, Dennis Schetinin escribiÃ³: > I've asked this some time ago, and got no reply. Another attempt: > > Using pharo1.0-10466-BETAweb09.10.1 + RFB-DamienCassou.28 > (still the latest): the image stops to respond after closing > connection remotely. Stopping the server leaves image ok. > > Can anybody reproduce this? > > I'm working on Russian Smalltalk User Group web server currently. This > package has shown itself as a very helpful tool during my last web > project, and it will be great if I can use it... > > If I get no reply because this is not the correct list, please give me > an advice about where to send the report. :) Hi Dennis, I can't reproduce it on a PharoCore 10470 image. I download the PharoCore image. Loaded RFB with ScriptLoader loadLatestPackage: 'Installer-Core' fromSqueaksource: 'Installer'. Installer lukas project: 'unsorted'; install: 'RFB'. And start it on display 0 with: RFBServer start: 0 then, with the image open, I opened a connection in Debian with gvncviewer localhost everything worked. I closed the remote connection and the image responded without problems. So, maybe this is specific to the web image or the packages Can you try with a pharo core image or a newer. Now to test with the refered image. I downloaded pharo1.0-10466-BETAweb09.10.1.zip and started it. I opened a workspace and executed: RFBServer start: 0 then launched the vnc viewer and closed it. the image works ok after that. I can't reproduce it on PharoCore or pharo1.0-10466-BETAweb09.10.1 Cheers > > -- > Dennis Schetinin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 17, 2009

[Pharo-project] Fwd: [squeak-dev] Strange behavior of ContextVariableInspector

by StÃ©phane Ducasse

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. > > >

Oct. 17, 2009

Re: [Pharo-project] Input problems

by Lukas Renggli

This looks looks cool. As far as I could test this seems to fix the problems I reported. Thank you. Lukas 2009/10/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks mike > > stef > > On Oct 17, 2009, at 12:54 PM, Michael Rueger wrote: > >> Hi all, >> >> after looking at the different input problems again it seems to me >> that they might all go back to problems with SharedQueue. >> Attached is a small change file for all who regularly experience >> problems with loosing characters while typing or double pastes. >> >> Please let me know if after filing in the change set the issues are >> fixed, less often or unchanged. >> >> Thanks >> >> Michael >> >> <inputSensor- >> fix.cs.st.gz>_______________________________________________ >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 17, 2009

Re: [Pharo-project] Input problems

by Schwab,Wilhelm K

I just cranked up an old machine and pounded some before and after. I'm sad to say that I do not see much of a change; I had high hopes for this. Please understand that my typing is not perfect, and keyboards might not be also. One truly nutty idea that comes to mind: we might record sound from people's typing and try to pick out how many keys they actually hit. That would not be perfect either, but it could easily turn out to be more objective than my best guess at whether I'm in fact hitting keys and they are not showing up. I am confident that Pharo loses input when under stress. You must think that too or you would not be working on the problem (for which thanks). Before trying sound beyond a basic feasibility test, we should plan what we would do, and decide whether or not it is something we could publish. Some basic thoughts would be that we should capture keyboard events vs. simply edited text - that would prevent problems with the backspace confusing us, and should also tell us what Pharo thinks about the timing of the strikes. The latter should help a lot in aligning the events with sound features; any latencies we uncover might give useful clues too. I _think_ I could find the keypresses in an audio recording; I do some work with wavelets and would hopefully be able to isolate the strikes with thresholding in a suitable scale. Will work for co-authorship :) If anyone is remotely interested and has a microphone already set up, a good starting point would be to send me recordings of a couple of people typing, ideally with a really good touch typist and somebody who struggles a little. If it looks anything like I expect, I can hopefully entice you with a wavelet baed detector and then we would tackle the event capture. Eventually I would envision the usual suspects for the Sprints gathering around preferably an older computer with a shiny new keyboard, but that would happen only when we have a fix and want to compare throughput before and after the fix. I would gladly crunch the acoustic data to the best of my ability. Note that it is preferred to get data sets of an integral power of two in length, which of course couples with sampling frequency (Nyquist offers some suggestions there of course) and duration. Another factor on duration is to record long enough to see a difference. We can work out most of that later, assuming there is interest and we have a fix in hand. I'll stop now :) Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Saturday, October 17, 2009 5:55 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Input problems Hi all, after looking at the different input problems again it seems to me that they might all go back to problems with SharedQueue. Attached is a small change file for all who regularly experience problems with loosing characters while typing or double pastes. Please let me know if after filing in the change set the issues are fixed, less often or unchanged. Thanks Michael

Oct. 17, 2009

[Pharo-project] making all tests green -- ReleaseTest>>testObsoleteClasses (issue 1310)

by Oscar Nierstrasz

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

Oct. 17, 2009