When in the debugger, pressing send will not get you out of a method. I think it would be good if it did. Is there any reason for the current implementation?
While I'm at it, the debugger highlighting is also misleading around conditionals. if foo is false, code like this foo ifTrue: [ do something]. next command. has "do something" highlighted after evaluating the conditional, even though it will not execute that statement. At least, that's my recollection. When I try to evaluate the following method: silly |n| self halt. n_6. n _ Project allInstances size > 30 ifTrue: [n_5]. n _ n+10. ^n.
I get a code simulation error at evaluating the +10. Other variants seem to work OK.
I've got a better example of the problematic highlighting in the debugger. myParts ifNil: [ myParts _ OrderedCollection new.]. myParts is not nil, but the "new" on OrderedCollection is highlighted as the "next" statement. It's disorienting and a little dangerous.
At 10:53 PM 6/29/01 -0700, you wrote:
When in the debugger, pressing send will not get you out of a method. I think it would be good if it did. Is there any reason for the current implementation?
While I'm at it, the debugger highlighting is also misleading around conditionals. if foo is false, code like this foo ifTrue: [ do something]. next command. has "do something" highlighted after evaluating the conditional, even though it will not execute that statement. At least, that's my recollection. When I try to evaluate the following method: silly |n| self halt. n_6. n _ Project allInstances size > 30 ifTrue: [n_5]. n _ n+10. ^n.
I get a code simulation error at evaluating the +10. Other variants seem to work OK.
squeak-dev@lists.squeakfoundation.org