But because of this , you can't. All you can do is modify method which
> 2009/6/25 Igor Stasenko <
[hidden email]>:
>> 2009/6/25 Andreas Raab <
[hidden email]>:
>>> 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.
>
Locked
