Breakpoints
Community Forums/Monkey2 Talk/Breakpoints
| ||
| DebugStop() gets old once you're used to breakpoints. The Scintilla text editor handles these well. |
| ||
| This will be quite difficult given the source translation. As it is, the stack tracing in Monkey is a dirty hack of pushing and popping strings. That's not to say it's impossible, but I don't think it should be super high priority just yet. Definitely something to put on the roadmap though. |
| ||
| I do think better debug support should be reasonably high priority. And if we're concentrating on c++ here, there's not really any excuse not to do a better job! It'd be nice if we could hook into GDB somehow, although I have no idea how hard this'd be. Guess it'd involve 'unmunging' c++ symbols somewhere along the waym so possibly 'hard'. |
| ||
| Pretty excited if monkey2 is gonna get some improved debug support! |
| ||
| If it's targeting clang, there is LLDB. But for proper multi-platform support I'm guessing a hand-rolled version might be needed. I'm pretty happy with the Bmax debugger. The Monkey1 debugger never quite shows enough info though (globals,consts, statics etc). |
| ||
| @GW_: If it's targeting clang... I think the point is to step through actual Monkey2 code rather than the translated source. This is what makes it tricky. |
| ||
| Mark, I did some research on this a while back. You can define a "fake" line number in between every single C++ line and it will fool GDB, so you can relate C++ code back to the original source..or something like that. I suspect GDB might be better than the horrible Code::Blocks implementation, but I don't know. The Code::Blocks debugger is nearly unusable. LLVM is supposedly the next big thing, and Xcode moved over to it, but I don't know much about it. Valve is/was working on their own LLVM debugger about a year ago. Hmm, maybe it was actually LLDB they are working on: http://www.phoronix.com/scan.php?page=news_item&px=MTQwNzk |
| ||
| Bruceys BMX-NG can use GDB too whith the BMX->C-translated code, just have a look how it is handled there. Of course this adds a bunch of extra lines for "debug builds". bye Ron |
| ||
| JoshKlint  wrote:DebugStop() gets old once you're used to breakpoints. The Scintilla text editor handles these well. I think it's basically two different things. DebugStop() is a language feature. Breakpoints within an IDE/Editor can be set visually, and the IDE/Editor just inserts DebugStop() in front of the line. |
| ||
| @Danilo: I think it's basically two different things. Agreed. It always bugged me how BlitzMax needed these statements inserted, because to be honest it should be done behind the scenes dynamically rather than before compilation. |
| ||
| The problem of pipes-based debugger is that you cannot ask the debugger to stop the application while it's running, you need to pre-defined where you're going to stop execution before you compile it. A TCP/IP based system, allows the IDE user to dynamically pass debug stop points to the application being run, and also allows the IDE user to send a "DebugStop NOW!" message, in case the application enters infinite loop, weird behaviour, etc. This is very handy, and maybe could be added to Monkey 2 somehow |
   |