Btw, this inability to interrupt in all such methods is the reason of
another annoying and confusing debugger behavior:

try debug:

1 isNumber

and when debugger opens, press 'into'.
Debugger not shows the method, but instead immediately shows as if
method already returns.
Now you have to spend time figuring out, what its returned, even if
there is constant - sometimes you need to know exact value.
But because of this , you can't. All you can do is modify method which
sends this message to see returned result, like:

| temp |

temp := 1 isNumber.

and then check it in temps.

Besides another issues, it would be good if debugger would display a
stack top somewhere (so we can always see a value(s) returned from
method(s) or primitives or whatever).

2009/6/25 Igor Stasenko <siguctua at gmail.com>:
> 2009/6/25 Igor Stasenko <siguctua at gmail.com>:
>> 2009/6/25 Andreas Raab <andreas.raab at gmx.de>:
>>> Igor Stasenko wrote:
>>>>
>>>> I prefer a more shorter way to get puzzled:
>>>>
>>>> type:
>>>> 0
>>>>
>>>> and then use 'debug it' from menu
>>>>
>>>> :)
>>>
>>> There is an easy fix for it, just change one expression in
>>>
>>>   ParagraphEditor>>debug:receiver:in:
>>>
>>> from this
>>>
>>>  [debugger interruptedContext method == aCompiledMethod]
>>>      whileFalse: [debugger send].
>>>
>>> to instead
>>>
>>>  [debugger interruptedContext method == aCompiledMethod or:[guineaPig
>>> isTerminated]]
>>>      whileFalse: [debugger send].
>>>
>>> The issue is that because the expression has no send the simulation runs
>>> away and causes a bunch of problems.
>>>
>>> BTW, since this thread is about mastering Squeak, if you can explain why the
>>> runaway simulation suspends the simulator process I will personally
>>> acknowledge your mastery of Squeak. I couldn't figure out why that happens
>>> :-)
>>>
>>
>> 1. The compiled method '0' looks like following:
>> all bytecodes: Quick return 0
>> header: 261 "primitive: 261
>>  numArgs: 0
>>  numTemps: 0
>>  numLiterals: 0
>>  frameSize: 16
>>  isClosureCompiled: false"
>>
>> 2.  stepToSendOrReturn doesn't treat this as return:
>>
>>  stepToSendOrReturn
>>        "Simulate the execution of bytecodes until either sending a message or
>>        returning a value to the receiver (that is, until switching contexts)."
>>
>>        | ctxt |
>>        [self willReallySend | self willReturn | self willStore]
>>                whileFalse: [
>>                        ctxt _ self step.
>>                        ctxt == self ifFalse: [self halt.
>>                                "Caused by mustBeBoolean handling"
>>                                ^ctxt]]
>> neither 'willStore' nor 'willReallySend' nor 'willReturn'
>> checks that method contains no bytecode, but an primitive which does
>> quick return of literal value.
>> I think a #willReturn need to be modified to check against this
>> primitive number.
>> Another way - is to force compiler to not optimize the 'doit' method.
>> Unfortunately squeak's compiler having no option to turn off all
>> optimizations.
>>
>> 3. because of 2. the process continue simulation and returns to a
>> #newProcess: method
>
> ah, forgot to add:
>
> and because debugger waits a method's context to be activated:
>
>        [debugger interruptedContext method == aCompiledMethod]
>                whileFalse: [debugger send].
>
> but its never is, because its having no chance to iterrupt inside that
> method  - '0' .
> That's why its going to 'Processor terminateActive' without any clues
> that something went wrong.
>
>> newProcess
>>        "Answer a Process running the code in the receiver. The process is not
>>        scheduled."
>>        <primitive: 19> "Simulation guard"
>>        ^Process
>>                forContext:
>>                        [self value.
>>                        Processor terminateActive]
>>                priority: Processor activePriority
>>
>> where "Processor terminateActive" effectively kills/suspends the
>> debugger process, because active process is not the simulated process,
>> as this method thinking :)
>>
>> This could be fixed like following:
>>
>> newProcess
>>        "Answer a Process running the code in the receiver. The process is not
>>        scheduled."
>>        <primitive: 19> "Simulation guard"
>>  | process |
>>        ^process := Process
>>                forContext:
>>                        [self value.
>>                        process terminate]
>>                priority: Processor activePriority
>>
>> ---
>> It seems works at first try, not sure about side effects. I'm letting
>> you to explore :)
>> On debug '0' its now spawns another error: subscript out of bounds.
>> But its not hangs anymore.
>>
>>
>>
>>> Cheers,
>>>  - Andreas
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



-- 
Best regards,
Igor Stasenko AKA sig.