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.