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 1 year, 1 month ago.
-
AuthorPosts
-
February 26, 2018 at 7:11 am #13733
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.
February 26, 2018 at 7:33 am #13734Either rewrite or step back for a day and relax…
February 26, 2018 at 8:28 am #13736I 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!
February 26, 2018 at 9:20 am #13738Thanks!
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.
February 26, 2018 at 8:01 pm #13739I 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.
February 27, 2018 at 3:08 am #13744In 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!
February 27, 2018 at 8:59 am #13747One 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.
-
AuthorPosts
You must be logged in to reply to this topic.