no debugger = murder
Monkey Forums/Monkey Programming/no debugger = murder
| ||
| I spent the last two weeks converting a massive Blitzmax project to Monkey. All was going swimmingly until just now. I'm getting an error, that, despite its best efforts, it is utterly failing to convey to me its meaning. Maybe its just me. Null object access That's fine - there's a null object some place. But, where? The above, is the error message in its entirety. I mean seriously, what am I expected to do with this information? A hundred source files, close to twenty thousand lines of code, and this is ALL it can give me?? |
| ||
| Have you tried to build on XNA or any other platform? It may give more information... |
| ||
| My debugging sessions usually go something like this... HTML5 - enable Chrome ->Tools->Developer Tools. If your app is crashing really quickly then just refresh and it should catch it. GLFW - run Visual Studio and attach to the running process MonkeyGame.exe. When it fails - it should show you where in the original Monkey code it failed. If all else fails divide and conquer - print is your friend. Somewhere in your highest level put prints just before lower level methods are called. You'll eventually narrow it down to the errant line(s). |
| ||
| I dunno what happened - I undid the stuff that had caused it to throw the useless error, redid it exactly the same (or so I thought), and now it works. Handy tips above - thanks. I had tried doing a Flash build but because all my sound files are OGG, that went tits up straight away. :D |
| ||
| Hi, > That's fine - there's a null object some place. But, where? Have you got 'debug' enabled? This should produce a stack dump that shows where the error occurs in the monkey code. If it's not, there's a bug. [edit] Just double checked, and there does appear to be a problem with stack dumps in GLFW, and possibly with errors occurring before mojo starts up - ie: in Main(). Will fix. [/code] |
| ||
| I know it doesn't help for lots of issues such as phone or tablet inputs like accelerometers etc but is it practicable to have monkey compile to a native exe rather than trans? And use this to do true source level debug against? It's probably too much work given that you would have to do a native compiler for Both windows and osx but there would be no other way to get a single step and watch style debugger I'm guessing. |
| ||
| I would also love to get a debugger that allows step by step exection in at last one of the targets... |
| ||
| Print("In my opinion monkey contradicts its purpose of being a easy to use overall solution when it comes to debugging and a few basic missing features like Pixmap access, easy to use multidimensional arrays, ... in such cases monkey is quite unbalanced and debugging is part of programming just like writing code. According to the complexity of your project it can be a lot easier hunting down a bug or a weird behaviour if you get meaningful compile information, can set/unset breakpoints dynamically, watch your variables, define special watch lists and step through your code/functions.") |
| ||
| Debugging in Monkey is definitely not for the faint-of-heart. To use Monkey effectively you do need to have a decent understanding of the Target language and some familiarity of the existing target tool-chain. I for one would really like something as simple as a #trace (on/off) command that I could use. When monkey generates the target language - instead of embedding the original monkey code as comments it echo's them to the console. Then I could avoid having to throw prints into the code in an attempt to narrow down the problem. This would be most useful for tracking down flawed logic bugs rather than nulls and array out of bounds issues. The flawed logic usually requires lots of prints and/or single stepping through suspect code in the target debugger. |
| ||
| I agree. That said you can use DDMS for the Android platform, or FireBug for the HTML5 platform, which should be able to give you a closer idea of what's going wrong (in the native code, not the Monkey code, unfortunately). It's not ideal, but it's a hell of a lot better than, let's say CoronaSDK, which has an entirely useless debugger, and even worse stack traces. |
| ||
| Mark: i do have debug enabled and i do normally get a helpful stack trace, but not on this occasion. hence my confusion. i'm building for html5 at the moment. |
| ||
| Mark, Will there ever be a "debug" target that allows us to step through? It seems like a logical solution to have it sit on the back of glfw or javascript. IT also seems like it is Monkeys only real weak point at the moment. There is also: http://demonsterdebugger.com/ which could be a good solution. Would the debugging system really have to be cross-paltform or could this be one area where you would need the speciffic enviroment for a full debugger? Another idea would be to embed the original source in debug builds and have the custom html server provide a step through interface? |
| ||
| I've wasted yet another morning trying to figure out why my "Mouse-up" code works, but in one particular method it does not. Doesn't seem to be the code itself, but somewhere the 'mouseUp' flag is being reset, apparently, and I don't know how, why, or where. I'm no closer to solving it than I was four hours ago. If Monkey could execute its own native code via an interpreter of some sort - however slowly - this would be incredibly helpful. Not being able to step through code and check variable contents is a complete killer, sometimes. |
| ||
| Like other's said, I usually run firebug or similar in Html5. Since Javascript is "live" (IE, executed by your browser on the fly) it makes it easy to play/debug with. |
| ||
| GfK: this is why I started using unit tests, so I can 'try' my code in small chunks. |
| ||
| Like other's said, I usually run firebug or similar in Html5. Since Javascript is "live" (IE, executed by your browser on the fly) it makes it easy to play/debug with. I just tried Firebug Lite for Chrome, but found out it doesn't have a java debugger which made the whole exercise pretty pointless.So I installed FF6 and Firebug, but couldn't make head nor tail of it. Maybe if I understood Java it'd help. Also there wasn't any sound when using HTML5 in FF6. Anyhoo, I solved the problem. Not sure what was going on but it seems like because the mouse-up flag was only being set for one single frame, that wasn't enough for the code to 'catch' it. I modified my mouse class a bit to allow a 0.5-second window after mouse release before the flag is reset, and that did the trick. I'll revisit the issue when I get things running in iOS in case it was just an HTML5 oddity. |
| ||
| For what it's worth, JavaScript != Java And Chrome/Safari have their own equivalent of "Firebug" included as standard. It's called the Web Inspector. |
| ||
| I mostly debug in Chrome -- build+run, hit ctrl-shift-i in the browser window and there you are. It's useful to set a breakpoint in the page initialisation to avoid scenarios where the javascript kills the page before you can organise yourself. Occasionally I'll debug the GLFW target in VS as that offers conditional breakpoints and a more flexible watch window. Obviously, on occasions where a bug is target specific, there's not much choice but even FlashDevelop manages a usable debugger (although it's a pain about restarting the player). |
| ||
| Anybody care to write a small tutorial on debugging with Web Inspector i.e. setting breakpoints, step-thru code etc? Might be straightforward to some but I have absolutely no clue how to use it. Eight bloody hours I've wasted today trying to hunt down a bug and I'm still no closer to getting it. |
| ||
| The most reliable way to develop for iOS is using XCode directly. This gives you a reasonable IDE, debugger, access to all iOS components. There does not exist a single solution out there i'm aware of which works in a convincing way for a broader use on projects. Unity has its issues, monkey has, ... You just don't get it all in one product. Either you choose a great language with limited possibilities like monkey or you use a uglier language but with all the possibilities. I would love to use monkey but in this state it's nice for playing around but nothing for the project work i have to do. You want an iOS keyboard, a debugger, access to the camera? Use XCode. You don't want compiler/linker issues with the latest iOS version? Then scratch Unity from your list as well and use XCode. You can life with monkey's extreme limited function set? Enjoy monkey. I think i would have prefered a monkey which does everything right for iOS and Android instead of running on this many platforms but with this many limitations, plus enhancing BlitzMax to be monkeylike to properly support the desktop platforms. Maybe things will enhance in a few years and this is more meant as a long term strategy but for now i see more benefits for less platforms to be supported in a better way. |
| ||
| @Gfk There are plenty of tutorials on debugging in Chrome or Firefox already out there. Here's one in 40 secs: http://www.youtube.com/watch?v=c_oiQYirKuY Here's one in 40 minutes: http://www.youtube.com/watch?v=TH7sJbyXHuk If there's something specific to monkey you want to know then ask away. |
| ||
| The mapping of Monkey to Xcode is pretty straightforward and yes debugging is easier there. Need to compile tough. |
| ||
| My biggest issue with monkey is how it displays absolute paths for everything. This is unnecessary and adds a lot of clutter to any sort of debugging. I would love it if absolute paths were only used for stuff outside of the compiling directory. |
| ||
| "I think i would have prefered a monkey which does everything right for iOS and Android instead of running on this many platforms." For me that would completely remove the point of Monkey. What I hope is that modules will evolve that will access the features of individual platforms, while Monkey itself gets even more multiplatform if possible! And of course I would like a debugger, even the ability to look at local variables when it crashes would be half the battle! |
   |