MVC debugging

On Sat, Sep 11, 2010 at 11:26:21AM -0400, David T. Lewis wrote:
To summarize where I think we are at on this, Florin's updates all look
great to me (modulo the change from #open1: to #openDebugger: and perhaps
a check for theInterruptedProcess ifNotNil: on the first line of
#interruptName:preemptedProcess:) and I think they should be included in
trunk.

Andreas, can you confirm your agreement?

Florin, can you please confirm that your changes are contributed under
MIT license for inclusion in Squeak? Sorry if this was already done,
I'm just checking in order to be careful with the license.

If all is well I will do the updates to trunk tomorrow (unless someone
else gets to it first).

Thanks,
Dave

 On 9/11/2010 4:49 PM, David T. Lewis wrote:
Dave,

Thank you for the test cases and for the update.

Sure, the changes are under MIT.

I know that, before, the method #interruptName:preemptedProcess: used to be sometimes called with a nil parameter. But
that was part of the problem, since even in situations when we knew what process we wanted to debug, we just lost it on
the way and ended up calling with a nil argument. Not because we needed to do so. For now I did change the callers so
that they don't call with nil anymore (in MVC). If a need arises for calling with nil, sure, let's add a check and a
comment justifying why it is so (and then we'll also know what we want to do in that case), but I don't like the "just
in case". If things don't happen conforming to our mental model they should break, to inform us about it.
I also don't expect this method to be called in packages outside the image. The method did not even exist in the old MVC

Cheers,
Florin

On 9/11/2010 1:49 PM, David T. Lewis wrote:
> To summarize where I think we are at on this, Florin's updates all look
> great to me (modulo the change from #open1: to #openDebugger: and perhaps
> a check for theInterruptedProcess ifNotNil: on the first line of
> #interruptName:preemptedProcess:) and I think they should be included in
> trunk.
>
> Andreas, can you confirm your agreement?

Go for it. This is tremendous progress!

Cheers,
   - Andreas

I'm pretty stoked. The last time I tried to open an MVC project, I think the image just hung. It's neat to be able to get in there and poke around a bit again! 

Thank you so much, Florin, Andreas and Dave for making it possible to
get the MVC debugger working again in Squeak.

This is of course crucial to make ToolBuilder fully work in MVC and
for example to do refactorings of Morphic or to come up with an image
with a minimal GUI.

As this fix is now in the trunk I just updated to #10518.

The debugger works fine.

Among other things I did the test
   [1 halt] fork

you recommended.

--Hannes


BTW the screen is not updated enough times, but if you slightly shift
around a Browser windows then it is repainted and everything is fine.

On 9/12/10, Casey Ransberger <[hidden email]> wrote:

 On 9/10/2010 9:33 PM, Florin Mateoc wrote:
Hi all,

I have been thinking of a way to have our cake and eat it too (being also able to interrupt a runaway process running at
a priority higher than the ui).
Basically we should have a way to tell Squeak that we want to interrupt the preempted process instead of the
activeControllerProcess.
For example the method #handleUserInterrupt could split the user interrupts into "normal" ones and "emergency" ones. The
code would look like:

handleUserInterrupt

    | preemptedProcess |
   
    Preferences cmdDotEnabled ifTrue: [
        (Sensor shiftPressed and: [(preemptedProcess := Processor preemptedProcess) notNil])
            ifTrue: [
                [Project current
                    interruptName: 'Emergency User Interrupt'
                    preemptedProcess: preemptedProcess] fork]
            ifFalse: [
                [Project current interruptName: 'User Interrupt'] fork]]

Unfortunately the interrupt does not trigger if I also press Shift. Is there a simple way to make it trigger regardless
if Shift is pressed or not?

With this occasion, I also noticed that the method ProcessorScheduler>>preemptedProcess starts looking at the same
priority as the active process.
But a process cannot preempt another process at the same priority, therefore the method is either buggy or poorly named.

Both these tests return true:

| p | p := [[true] whileTrue: [Processor yield]] fork.
p name: 'bla'.
Processor yield.
Processor preemptedProcess == p

| p | p := [[true] whileTrue: [(Delay forMilliseconds: 2) wait]] fork.
p name: 'bla'.
Processor yield.
Processor preemptedProcess == p

(I named the processes to be able to terminate them after the test, so that I don't lose control over the image (Process
allInstances do: [:e | e name = 'bla' ifTrue: [e terminate]]))

Anyway, in both cases, these so-called preempted processes were not actually preempted, they were just nice citizens and
cooperative, so they yielded respectively waited.
I think the method #preemptedProcess should start iterating from "activeProcess priority - 1"

Cheers,
Florin

Hi -

I was playing with MVC but I noticed something odd. With the latest
changes, the pre-debug notifier shows up nicely in MVC but when you go
to actually debug things the resulting debugger doesn't show - instead,
when you back into the parent (Morphic) project, another notifier shows
there.

Any ideas what might be causing this?

Cheers,
   - Andreas

On Thu, Sep 23, 2010 at 09:16:56PM -0700, Andreas Raab wrote:
That would be a deferred UI event getting scheduled in the wrong world.
The culprit seems to be  class>>openOn:context:label:contents:fullView:
which is sending #addDeferredUIEvent: to WorldState rather than
Project current.

This is from one of our recent changes, and needs to be changed back
to use Project current. Unfortunately, "fixing" this exposes other
problems.  Try opening a debugger in MVC, then switching back to Morphic.
Very entertaining, but save your image first ;)

Dave

On 9/24/10, David T. Lewis <[hidden email]> wrote:
> On Thu, Sep 23, 2010 at 09:16:56PM -0700, Andreas Raab wrote:
>> Hi -
>>
>> I was playing with MVC but I noticed something odd. With the latest
>> changes, the pre-debug notifier shows up nicely in MVC but when you go
>> to actually debug things the resulting debugger doesn't show - instead,
>> when you back into the parent (Morphic) project, another notifier shows
>> there.

>> Any ideas what might be causing this?
>>
>> Cheers,
>>   - Andreas
>
> That would be a deferred UI event getting scheduled in the wrong world.
> The culprit seems to be  class>>openOn:context:label:contents:fullView:
> which is sending #addDeferredUIEvent: to WorldState rather than
> Project current.

A debugger shows up in MVC but it has not the usual buttons to
actually to debug things.
If I go back to the Morphic world

a 'Message not understood' comes up in
ControlManager>>activeController

The activeController does not understand #startup.

But I just can close 'Message not understood' window and resume work.
So I'm not too worried about this at the moment....

The good thing is that MVC has moved a big step forward. For doing
certain programming operations with Morphic while it is not running it
might be good enough as of now.


> This is from one of our recent changes, and needs to be changed back
> to use Project current. Unfortunately, "fixing" this exposes other
> problems.  Try opening a debugger in MVC, then switching back to Morphic.
> Very entertaining, but save your image first ;)

What do I need to do to get this behaviour?


> Dave
>
>
>