Debugging and 'go cd x of stack y'

[dunbarx]

I think he means an error occurred that stops the debugger.

The OP wrote:

the debugger dies and the Livecode goes back to the IDE.

"Goes back to the IDE".

I do think that we are misusing terms, and there is really nothing out of the ordinary here. But I still do not know what is happening.

Craig

[richmond62]

We probably won't cross that Fjord until it bounces back to us.
-

Ford.jpg (28.67 KiB) Viewed 4473 times

-
Mind you, I was hoping we'd get Bogged down.

[Fjord]

Wow!! so many answer… seems I'm the first guy who crashes the debugger? Actually I didn't write 'crash' in my original post: I tend to think that an abnormal behavior is usually a consequence to a bug sitting between the chair and the keyboard; mostly…
So:

stam: it's often helpful setting breakpoint in the first line of the handler (or the calling handler) and then stepping through line-by-line to see what's going on...

'exactly what I do

dunbarx : I suppose you could pull the plug on your machine as well

'exactly what I don't do when trying to understand what's going on in my code

jacque : We need to know the values of cdName and stackName

cdName="indicateursUneValeur"; stackName="Indicateurs"; those are 'the short name of' the cd and the stack; they are the correct names of the cd and the stack

richmond62: I would assume that they are the names of cards in stacks that are currently open

they are; and why not? my app goes back and forth between both stacks

dunbarx: I am suspecting that the word "debugger" is not what we think it is

well, to me, the debugger is what you get whenever Livecode runs into a line with a big red dot on the left of the script; what else?

SparkOut: try answer "go cd" && cdName && "of stack" && stackname

I get: go cd indicateursUneValeur of stack indicateurs; I suspect I could've quoted the names for safety; but really now these are a single ident

I spend some time recently playing around SparkOut idea, and noticed a behavior that seems strange to me. I have 2 stacks: a 'main' stack whose 'preopen' handler does a 'start using utility.livecode'. The utility stack manages the data from the main by storing/fetching it to/from an array each time the card is changed then saves that array into a file on quitting (I can't remember where I read about this idea).
The 'next cd' button in 'main'

Code: Select all

on mouseUp
   lock screen
   SAnextCd — this ends up calling SAreadCdFromArray below
end mouseUp

Code: Select all

on SAreadCdFromArray theCdKey , theBg , theStack — theBg is actually a card name ; theCdKey is a fld acting as an identifier of the cd
   myAssert the params , (1 <= the paramCount) and (the paramCount <= 3) , param(0) && "theCdKey [, theBg [, theStack]]" — a bit of checking
   put SAkeyExists(theCdKey,theBg,theStack) into cleExiste
   myAssert the params , cleExiste , "Pas trouvé la clé '" & theCdKey & "' du bg '" & theBg & "' of stack '" & theStack &"'"
   answer "go cd" && theBg && "of stack" && theStack 
   go cd theBg of stack theStack
   answer "I'm back to the script of" && the name of me

1. When I run this with a breakpoint on both answer instructions: the debugger stops on the 1st 'answer'; I type cmd-o, the 1st message is displayed; I type OK; the debugger stops on the 'go cd'; I type cmd-o, the second message is displayed at once; I type OK; the debugger stops on the instruction after the 2nd breakpoint. So the debugger never stops on the 2nd answer instruction before displaying the 2nd message.
2. When I run this with a breakpoint on the 1st answer but no breakpoint on the 2nd 'answer': same as above
3. When the 2nd 'answer' is commented out (therefore no breakpoint) but I set a breakpoint on the instruction that follows it: the debugger stops on the 1st 'answer'; I type cmd-o, the 1st message is displayed; I type OK; the debugger stops on the 'go cd'; I type cmd-o, the debugger disappears; the instructions after it are executed.

It seems that the 'go cd' instruction does not conform to the cmd-o signal to go to the next line of the script?

[Fjord]

Sorry for the looooong post above
>richmond: I always thought a fjord is a lill' bit deeper and wider that this … trickle?

[jacque]

What happens if you use "put" instead of "answer"? The dialog may be interfering.

[dunbarx]

I still want to know, step by step, what actually happened. Was it:

1- You were running the debugger.
2= Stepping through, line by line, all of a sudden at one particular line, LC kicked you out of the debugger back into the IDE.
3- This was repeatable at the same line in your code.

Bottom line, you cannot analyze any issues you might have, because you (or LC) cannot use the debugger.

Is it the same line that kicks you off? Id so, can you post that line?

Craig

[jacque]

I still want to know, step by step, what actually happened.

The steps are above but a little hard to follow in your head. He's stepping through the lines but one gets skipped. I'm thinking the dialog is getting in the way but that's just a guess.

[Fjord]

jacque: What happens if you use "put" instead of "answer"? The dialog may be interfering.

Just done that:

Code: Select all

   put "go cd" && theBg && "of stack" && theStack 
   go cd theBg of stack theStack
   put "I'm back to the script of" && the name of me
   logString param(0) && "go cd " & theBg & " of stack " & theStack

Red dot (aka as breakpoint) on each instruction. Run the script: the msg box disappears and the debugger stops on 1st 'put' instruction > cmd-o > displays "go cd indicateursUneValeur of stack Indicateurs" in the message box > stops on the 'go' instruction > cmd-o and continues executing, no stopping, ignoring the breakpoints that follows the 'go cd'. Everything done normally (I've got a log).

[stam]

Code: Select all

   put "go cd" && theBg && "of stack" && theStack 
   go cd theBg of stack theStack
   put "I'm back to the script of" && the name of me
   logString param(0) && "go cd " & theBg & " of stack " & theStack

This seems like ambiguous code:

Code: Select all

   put "I'm back to the script of" && the name of me

Who is “me” in this context? Can “me” change within the scope of a single handler?

[jacque]

The log info helps. It looks like the first go command is triggering a handler outside of the one you posted and that's where the problem is. You can probably see what's happening if you use Cmd-I (step into) instead of Cmd-O. If the other card uses any open* handlers then one of those is probably the cause. If you just want to see if that's the case before stepping through everything you can lock messages at the start of the handler you posted here. If that runs normally then you know the problem is elsewhere.

[Fjord]

Jacque: yeah, I thought of this and did that. I ended up removing the openStack entirely, although I didn't really understand what was happening. Could be linked to resizing the stack. I still have to experiment this more precisely.