I'm glad we agree that it should at least not get into this situation where it allocates memory endlessly and can thus disrupt other programs running on the OS.
I compared the list of ProtoObject methods in 3.7 and 3.9 and see no difference. So it must be a change in the debugger code. I also noticed it happens on my 3.8-6326 unstable image.
Anyone have any ideas?
Hi,
I have been tracking down the symptions Chris is referring to and can confirm his problem.
For the impatient see my conclusions at the bottom.
Firstly, it is possible to open a debugger in 3.7 on the 'do-it' of
ProtoObject basicNew printString.
1. When this is is evaluated a wee debugger appears indicating correctly than printString is not understood. 2. If one chooses to debug this a full debugger appears as expected. 3. If one clicks on the top row in the stack list, a new debugger appears indicating that ProtoObject does not understand inspector class. This is becuase the first debugger is trying to populate the little inspector in the bottom left hand corner of the debugger (the receiver). 4. If one abandons the second debugger, one can continue with the first debugger.
5. If one implemenents, for investigation purposes only, ProtoObject>>inspectorClass as
ProtoObject>>inspectorClass ^ Inspector !
6. If one repeats 1-3 again then the second debugger does NOT appear.
Now....
7. Step three above (with method in step 5 installed) is the same as evaluating:
Inspector openAsMorphOn: ProtoObject new withEvalPane: true withLabel: 'huh' valueViewClass: nil
In 3.7-6989 this opens just fine.
8. In 3.8-6550 this does NOT work. You can get it to work by a) adding ProtoObject>>inspectorClass as per step 5. b) reverting Inspector>>inspect: from Andrew Black's (apb) version to Anthony Hannan's (ajh) version.
9. Note. The debugger still does not open, even with the changes to 3.8 in 8 above. I am still hunting but must now sleep.
Conclusion ---------- The problems have probably been introduced at the same time as the changes to Inspector. Could this be the inspector enhancements bundled with the clousure compiler stuff.
Help requested.
Brent
"Brent Pinkney" brent.pinkney@aircom.co.za wrote:
I have been tracking down the symptions Chris is referring to and can confirm his problem.
For the impatient see my conclusions at the bottom.
Firstly, it is possible to open a debugger in 3.7 on the 'do-it' of
ProtoObject basicNew printString.
- When this is is evaluated a wee debugger appears indicating correctly
than printString is not understood. 2. If one chooses to debug this a full debugger appears as expected. 3. If one clicks on the top row in the stack list, a new debugger appears indicating that ProtoObject does not understand inspector class. This is becuase the first debugger is trying to populate the little inspector in the bottom left hand corner of the debugger (the receiver). 4. If one abandons the second debugger, one can continue with the first debugger.
This actually all sounds fine to me. ProtoObject's don't particularly need to have even basic debugging behaviors. They are not really supposed to be instatiated, themselves. You can't even print them out or send them #yourself....
Maybe we should even move in the opposite direction, and remove some methods? The following don't really seem to need to be there:
flag: the oneshot methods Also, I got the impression that the tryNamedPrim methods are vestigial. If that's true, then they should go away as well... -Lex
Man oh man, I have been in the dumps the last couple of days from being rather stuck on this.
I even headed back to 3.7 today. Looks like I won't need to do that now.
You have made my day today!
Thank you Brent.
- Chris
Yeooww, except.. Oops, it didn't work for me!
- In 3.8-6550 this does NOT work. You can get it to work by a) adding ProtoObject>>inspectorClass as per step 5. b) reverting Inspector>>inspect: from Andrew Black's (apb) version to Anthony Hannan's (ajh) version.
I tried a, then b, then both a and b in both a 3.8g-6550 image as well as the 3.9 image and it didn't work for me.
I'll bet there was some other change in the late hours you have that actually fixed it for you. Maybe its in your changes log..?
The way I test it is, I open a process browser, then do the "ProtoObject basicNew printString" then go back to the process browser and press Command+u on the process list to update the list and a ton of suspended processes are suddenly there.
Hi Chris,
The bad news is that I did not manage to fix your problem last night.
I did however manager to isolate what was happening.
I will look into it more tomorrow, time permitting.
Brent
squeak-dev@lists.squeakfoundation.org