IDE independent Debugger
Community Forums/Monkey2 Talk/IDE independent Debugger
| ||
| I do not know if this is even possible? I currently use Sublime Text as my IDE of choice, I am even wondering is it possible to give us 'alternative' IDE users a way to access the debugger? Even if it requires some work on my behalf, I would be happy. |
| ||
| I think this would be a great idea. Build in a default debugger UI which will be the one used by the official IDE and any 3rd party text editors. You can optionally disable the UI and revert to the command line output if you compile with a certain switch. It would however be a bit of read only operation if this were the case. You could show the source in the custom UI, but then you would have two copies of the file open. So maybe not a perfect solution. |
| ||
| To be honest I think the best way to do debugging would be to have a Monkey "interpreter" that opens a socket for debugging tools to access. The only issue here is... how do we "interpret" native code? |
| ||
| IMHO the cleanest way to solve this would be to create a separated debugger that can be used from any editor. Enforcing this into the compiler or debugged application as in b3d is a bad idea, as you can't create better debuggers that the one provided, but having an opt-in default one for people using regular text editors, can be handy. Not sure if this should be part of the compiler tho. |
| ||
| Just curious, what's wrong with the stdio way that Blitzmax does it? |
| ||
| Just curious, what's wrong with the stdio way that Blitzmax does it? My main beef with it, is that I am already in a nicer IDE, using it happy. What I lack in that IDE is a way to use and interact with the debugger. So to use it I have to fire up another program, load my code and run with the debugger on, its just all a bit of a pain. |
| ||
| I would rather see quality runtime checking in debug mode over debugger support. From my usage of monkey1 (native chrome / xcode / eclipse / VS debuggers when needed) Debug mode should protect all API interactions and array access with sanity checks and leave debugging support off the feature set altogether. I think the mx approach of littering the code with debugger calls - causing glfw compilers to their knees should be left out of initial release, or at least disablable. Typically you would expect release mode to take longer to compile but in monkey1 release mode is an order of magnitude faster for c++ targets although I suppose some of that is the quality runtime checking I hope m2 brings to the table. |
   |