Debug navigation

a_riot42a_riot42 AMX WizardPosts: 1,619
I didn't know about this until I discovered it the other day, but I can already see its come in handy. If you use arrays of structures and have one in the NS3 debugger, you have to click on the plus sign to expand the array to look at the structure data, and if a structure has a structure in it, that's another plus sign to click deeper into the data structure, and so you clumsily click your way through your data structures. What works better, is to click in the debugger window and use the arrow keys to navigate through your structure. Hitting right arrow at any time opens the next level, left closes it, and then you can quickly scroll through many items briefly taking a look at the data by hitting right arrow, then left, down, right, then left, looking at each element without all the mouse wrangling. Perhaps this is already well known, and if so, disregard, but I have found it helps take the tedium out of watching variables in the debugger.
Paul

Comments

  • ericmedleyericmedley Senior Member - 3709 Posts Posts: 4,156
    a_riot42 wrote: »
    I didn't know about this until I discovered it the other day, but I can already see its come in handy. If you use arrays of structures and have one in the NS3 debugger, you have to click on the plus sign to expand the array to look at the structure data, and if a structure has a structure in it, that's another plus sign to click deeper into the data structure, and so you clumsily click your way through your data structures. What works better, is to click in the debugger window and use the arrow keys to navigate through your structure. Hitting right arrow at any time opens the next level, left closes it, and then you can quickly scroll through many items briefly taking a look at the data by hitting right arrow, then left, down, right, then left, looking at each element without all the mouse wrangling. Perhaps this is already well known, and if so, disregard, but I have found it helps take the tedium out of watching variables in the debugger.
    Paul

    Paul,
    I did indeed already know about this and like you found it by accident one day. I'm sure there are quite a few things about debug (and the rest of NS) that are old hat to some and deeply hidden secrets to others.

    My example of this was I was unaware that you could monitor stack_varialbles in debug. Somewhere back in the early days of NS, perhaps the Mezazoic or around there, I think I might have heard someone say you couldn't monitor stack-locals and that's what stuck with me. Then one day Spire_jeff drug one in and it magically started working. I supposed him for some kind of minor deity or voodoo shaman or something. He then performed some other magic with a shiny thing he called a flashlight.
  • viningvining X Member Posts: 4,348
    ericmedley wrote: »
    Paul,
    I did indeed already know about this and like you found it by accident one day. I'm sure there are quite a few things about debug (and the rest of NS) that are old hat to some and deeply hidden secrets to others.

    My example of this was I was unaware that you could monitor stack_varialbles in debug. Somewhere back in the early days of NS, perhaps the Mezazoic or around there, I think I might have heard someone say you couldn't monitor stack-locals and that's what stuck with me. Then one day Spire_jeff drug one in and it magically started working. I supposed him for some kind of minor deity or voodoo shaman or something. He then performed some other magic with a shiny thing he called a flashlight.
    I love nesting structures too but I find the debugger doesn't and will often crash NS as a result.

    I also like using break points and stepping through code using the debugger and when you do you can observe stack values as well as globals and locals but half the time I can't get the damn break points to work. There must be some special sequence to make it work that I can never replicate with any consistancy. It's like rolling dice to get it to work.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    vining wrote: »
    I love nesting structures too but I find the debugger doesn't and will often crash NS as a result.

    I also like using break points and stepping through code using the debugger and when you do you can observe stack values as well as globals and locals but half the time I can't get the damn break points to work. There must be some special sequence to make it work that I can never replicate with any consistancy. It's like rolling dice to get it to work.

    I haven't found NS to crash when watching variables, but I have found the same as you have with breakpoints not working correctly so I never step through code anymore, and instead use send_strings to the console. If I can successfully create a breakpoint there seems to be some issue in getting rid of them properly as well, and I've stopped a system from running unknowingly since I had the debugger running and a previously deleted breakpoint was still there hanging things up.

    I don't see how stack variables can work in the debugger. I have a stack_var called ui in almost every button event, so I don't see how the debugger would know which one to display and they don't get values when I put them in. Is there a trick to getting them to work?
    Paul
  • viningvining X Member Posts: 4,348
    I've only had issue with large nested structures and I've since stopped going deeper than 2 structures.

    I pretty much just use send_string 0, too but there are times when stepping is the only way to see what's going on. It's rare that I try it anymore but on occassion I still do, in fact I tried yesterday and I couldn't get it to break and when it decides to break and you're not expecting it anymore it does make you want to go postal.

    Trying to watch STACKs or LOCALs in debug that are used often is obviously a pain so if I do want to watch a specific STACK/LOCAL var that is used dozens of times like UI, Btn, Index, etc I'll change the name while testing just so I can easily select it. Otherwise it would be nearly impossible to determine which one it is. Most of the times though I don't need to watch those very common var names since those are in send_string 0's at the beginning of the events that trigger them. It's hard enough to select the appropriate var that's passed to a few instantiated modules, is it first to last or last to first? Usually last to first but I swear it changes.

    Edit:
    Stacks won't have values when you add them to debug since they don't exist yet which is why you have to use breaks and step through the code that declares and uses them. Essentially have to manipulate and stop time so you need to step to the moment when the stack is created and then view it while it still exists before it goes poof... and vanishes.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    vining wrote: »
    I've only had issue with large nested structures and I've since stopped going deeper than 2 structures.

    I don't use deeply nested structures due to the fact that they really seem to slow memory read/writes.

    vining wrote: »
    Edit:
    Stacks won't have values when you add them to debug since they don't exist yet which is why you have to use breaks and step through the code that declares and uses them. Essentially have to manipulate and stop time so you need to step to the moment when the stack is created and then view it while it still exists before it goes poof... and vanishes.

    Yes I've done that before and seen the temporary values, but its easier to make them local during testing or use send_string 0, like you mention so its a feature I don't need. In other debuggers, objects on the stack are given an ID to differentiate them so you can watch the values as they occur, but I guess if your NetLinx code is so complicated that it requires this, you might want to consider a redesign.
    Paul
  • champchamp Junior Member Posts: 261
    He then performed some other magic with a shiny thing he called a flashlight
    This sounds like a magic far too great for mere mortals like myself, beware of the light
Sign In or Register to comment.