2 days and no joy.

About Monkey 2 Forums General Discussion 2 days and no joy.

This topic contains 6 replies, has 4 voices, and was last updated by  cocon 5 months, 3 weeks ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #13733

    Richard Betson
    Participant

    I’ve been working on finding a bug for two days and can’t isolate it. What do you do to cope with the frustration of the I cant-find-the-bug-blues? I think I’ll break out the airsoft guns and take it out on some cans. 😀

    #13734

    therevills
    Participant

    Either rewrite or step back for a day and relax…

    #13736

    abakobo
    Participant

    I try to go back to the situation just before it appeared. And then add bits of code until until it comes back. With a lot of “print” everywhere to track the process. Cause the debugger might show too much sometimes. Good luck!

    #13738

    Richard Betson
    Participant

    Thanks!

    Apparently just posting about it works! I took another stab at it and found the issue. The map code I have developed can get a little difficult to visualize as it uses a map tree, roots, child nodes and leafs as well as image projection (rendering images), collision and more.  In fact I will probably make a video to help explain how it works for Alien Phoenix. It’s easy to use but difficult to easily explain the technique.

    Still, I am interested in how others get through bug-block. Off to create a solution. 🙂

    Edit: Totally fixed it. So glad I posted about it… lucky monkey. 🙂

    #13739

    cocon
    Participant

    I don’t know if there’s other way other other than debugging all the way. For example if a user would have said: “when I collide with this red ball the game crashes” it would force you going to that collision point in code and find what happens afterwards.

    Perhaps Monkey could introduce such a debug-until-crash feature, which is simply a shortcut. Instead of pressing the [Play] button on and on and on again until you reach the part of the problem. You simply do this sort of Play-Until-Crash and by the time of crash you would see the last statement you were in.

    #13744

    Richard Betson
    Participant

    In my case it was an issue of everything was working fine until I began modifying code over a few days. The app was not crashing but instead was exhibiting unwanted behavior due to code edits. So it was a case of what the heck did I change to cause the problem, which can be frustrating because there is no compile error. In this case two lines of code were accidentally deleted causing the issue (reverting was not an option).

    The other factor here is a large code base. When going in blind trying to hunt through an integrated large code base things can get complicated. Is the problem in the window image rendering code, is it in the mapping rendering code or is it in the physics code. The issue I was addressing could have been in any one of these. Add to this all of the code I use is original and in a state of architectural development which also contributes to confusion at times as it can be hard to keep track of changes and how they effect other sections of code. Right now I am developing a game engine (gaming framework) as well as a game in Monkey native code; a huge complicated task for sure.

    With that said though, spending nearly three days looking at code and not finding an issue can be frustrating. In my case it does not happen that often but when it does.. ugh! 😀

    #13747

    cocon
    Participant

    One good practice for the commits is for them to be kept focused. Another one is to do prototyping and then store it (diff/stash/branch). At a later time you would create a better order of commits, where the point is to plan one step ahead of the actual source code. 🙂

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.