Buggy debugger -- solved?

[Mark Schonewille]

Tim,

I would like to know whether you have solved the problem you had 
with debugging background scripts. If not, feel free to send you 
stack to me. You can also add your (very good) analysis to bug 
329 of the Bugzilla database.

In my view, the debugger should never just drop out of debug 
mode. It should give some feedback to tell the user why it can't 
continue debugging. If we can figure out what happened with your 
stack, maybe RunRev can add some proper error handling in the 
deugger.

Best,

Mark

P.S. I'm quoting the entire previous message to make it easier 
to recall the discussion.


Timothy Miller wrote:
> It looks like this thread might die. I hope not. I hope a knowledgeable 
> someone is going to reply. I'd sure appreciate it. I'm depending on you 
> guys. I've searched the docs, learned nothing, and taken all advice 
> offered so far. Where else can I turn?
> 
> The gist is, the debugger works fine in stack scripts, but I am not able 
> to debug any background script. I'm talking about bg scripts that work 
> perfectly, every time.
> 
> If I move any background script to the stack script, the debugger works 
> perfectly. I can replicate the problem, every time. If I split a 
> sequence of handlers between a background script and a stack script, I 
> can debug those in the stack, but not those in the background.
> 
> Is this a bug or a feature? Is it well known? Documented? If so, where? 
> If it's a bug, has it been reported? Has it been fixed?
> 
> 
> Cheers,
> 
> 
> Tim
> 
> 
>>> On 7/11/05 8:34 PM, Timothy Miller wrote:
>>>
>>>> The details of my debugger frustration, previously described:
>>>>
>>>>> It works fine on, for example, a simple mouseUp script in a simple 
>>>>> button. However, if the button sends a message to a handler in a 
>>>>> stack script (for instance), which then sends another message to 
>>>>> another handler, nested or not, the debugger won't follow along. 
>>>>> "Script debug mode" is definitely turned on. Step Into, etc., are 
>>>>> absent and/or dimmed out, typically. Sometimes, I can see the 
>>>>> script window open, several windows back, but I can't get to it 
>>>>> until the script is done executing. I've tried setting multiple 
>>>>> breakpoints in each handler, tried setting breakpoints by script. 
>>>>> The script rolls right past them.
>>>
>>>
>>> I think Eric mentioned this after you wrote last time, but the 
>>> debugger doesn't track "send to" messages. It tracks everything else, 
>>> but if you "send" a handler to another object the debugger won't 
>>> follow along.
>>>
>>
>>
>> Thanks to Eric, Jacque and Mark on this thread. And thanks to Dan, again.
>>
>> First, let me clarify what happens, and what doesn't. The script 
>> window opens at the breakpoint, but it does not come to the front, and 
>> the script does not pause at the breakpoint. After the script is done 
>> executing, I can move the script window to the front, but it does me 
>> no good.
>>
>> Oops! I just solved part of the puzzle, but mysteries remain. Feel 
>> free to skip to the second row of asterisks if you want. The details 
>> lie between the asterisks if anyone is interested.
>>
>>
>> ************************** the dull details, perhaps now irrelevant, 
>> follow:
>>
>>
>> Here's a typical sequence of events.
>>
>> On mouseup
>>     get this
>>     put that into field "theotherthing"
>>     etc.
>>      goForIt -- this is a message sent to the background script. The 
>> bg script does receive it, and the script executes fine, but I can't 
>> debug it.
>> end mouseup
>>
>> Now, in the background script
>>
>> On goForIt
>>      handler1 -- this massages some data, without changing stacks or 
>> backgrounds. It terminates, so the script moves onto the next handler 
>> in goForIt
>>      handler2 -- more of the same
>>      handler3 -- this goes to another stack, picks up some data and 
>> returns. It also terminates
>>      handler4 -- this is a handler that doesn't terminate. The next 
>> handler is nested, in other words. Depending on an operator, it calls 
>> either handler5 or handler6
>> end goForIt
>>
>> The command "send" does not appear anywhere in this sequence.
>>
>> In reaction to the good comments of the good people on this thread, 
>> and also in reaction to my desire not to look like a whiner or an 
>> idiot, I re-tested. Same results. As follows:
>>
>> If I put the breakpoint in the button, the button script does open, 
>> and I can "step into" through the lines of the button. Once the script 
>> gets to the goForIt message, the script executes without pausing, even 
>> though the window of the bg script opens.
>>
>> If I put the breakpoint at the beginning of the goForIt handler in the 
>> bg script, at the the handler1 message, at the beginning of the 
>> handler1 handler, in the middle of the handler1 handler, or all of the 
>> above, or do the same with any other handler in this sequence, the 
>> same thing happens. The script window opens, but it's not the front 
>> window, and the script runs to completion, without pausing. When the 
>> script has executed, the script window remains open.
>>
>> After reading the docs again, I realized that I can initiate debugging 
>> when the error window opens. So, I deliberately placed an error at 
>> various points in the goForIt handler, or in hanlder1, handler2, etc. 
>> The debug button on the error window did respond, and took me to the 
>> error. The script has paused, the script window opens, but the 
>> debugger buttons at the bottom of the script window (step into, etc.) 
>> are absent, and the corresponding items in the debug window are dimmed 
>> out. The script stalls. All I can do is remove the offending line, 
>> save, and run the script again.
>>
>>
>>
>> **************************  The more productive part starts below:
>>
>>
>>
>> Maybe there's something about background scrips. As I write this, it 
>> strikes me that I've put most scripts of this nature in the background 
>> script. I just tried a similar kind of button-handler-handler-etc 
>> situation, where all the handlers are in the stack script. These seem 
>> to debug just fine.
>>
>> Maybe this is why the debugger seems to have worked at some times, not 
>> at others. I didn't notice the pattern before.
>>
>> Now I'm going back to the script described above. I'm moving handler1 
>> to the stack script. If I put the breakpoint at hanlder1 in the stack 
>> script, I can "step into" all the way thru handler1. When it 
>> terminates, and control reverts to the bg script, I can't debug any 
>> further.
>>
>> My hypothesis is -- there is something different about bg scripts -- 
>> maybe several things. In a way I hope so. I'm gonna feel really stupid 
>> if no one can reproduce this issue at this point.
>>
>> If background scripts are "different," what's different about them? I 
>> looked through the documentation pretty carefully, but didn't find any 
>> mention of this.
>>
>> If others on the list haven't have this problem, maybe most 
>> experienced users avoid background scripts, avoid turning on "behave 
>> like a background" or don't have HCaddressing turned on. (In my case, 
>> "behave like a background" and HCaddressing areturned on.) If that's 
>> true, few people on the list would have noticed this issue. It's also 
>> possible it's an OS X-only problem.
>>
>> Should I have known that the debugger doesn't work properly in bg 
>> scripts? Or maybe this is an un-reported bug in the debugger?
>>
>> Your ever faithful fumbling amateur,
>>
>>
>> Tim

-- 

eHUG coordinator
mailto:europe at ehug.info
http://www.ehug.info
http://home.wanadoo.nl/mark.sch
http://www.economy-x-talk.com

Please inform me about vacancies in the field of
general economics at your institute. I am also looking
for new freelance programming projects.