Feature Request: Debugger

Monkey Forums/Monkey Programming/Feature Request: Debugger

andrew_r(Posted 2012) [#1]
Yeah, I know this has been hashed out before, and I know that you can debug the target projects (which really isn't ideal).

However, I've been playing with monkey for the past two or three weeks and it really is a great product... except for the lack of integrated debugging.

How high is this on the feature list? I'm hoping it's right at the top, because I think it's probably the only thing that's an obvious glaring omission in the product at the moment...

Well, apart from double buffering. And offscreen surfaces. And... (you get the picture) :)

Andrew


Xaron(Posted 2012) [#2]
A debugger for the GLFW target is in discussion as far as I know (please correct me) but it's almost not doable to create one for Monkey itself because you just need a target to debug.


therevills(Posted 2012) [#3]
A debugger for the GLFW target is in discussion as far as I know


Your correct Xaron, in Mark's last blog post(October 23, 2011) he does mention an debugger for GLFW:

* Stop/Start style debugger for the GLFW target. As Monkey users are well aware, debugging can currently be a bit, erm, challenging. Basically, if your app tries to access a null object or index an array beyond bounds, the app stops and you get a stack trace - and that's it. Unfortunately, a proper stop/start debugger for all targets would be impossible, as many targets cannot be stopped as they're callback driven. Therefore, I think the most practical solution to the debugger problem would be to concentrate on making a decent debugger for the one target that can really support it - GLFW. This isn't ideal, and I'm still considering options for debugging, but given the nature of Monkey, it's kind of a tricky one!


http://marksibly.blogspot.com.au/

I'm actually finding the MonkeyMax target helpful for debugging, since BlitzMax's debugger is pretty easy to use :)


wiebow(Posted 2012) [#4]
For now, I am using my unittest module to keep the amount of bugs to a minimum. Maybe it is something for you as well?

http://code.google.com/p/mutated-monkey/


andrew_r(Posted 2012) [#5]
Yeah. I saw mention of the GLFW target debugger - that's actually what I was referring to. I was assuming it would be integrated in such a way as to present the original monkey code. I'm hoping it materialises soon.
I'll take a look at the unittest stuff, but again it's not idea. I'll also take a look at the monkey max target, although I imagine it will not be significantly different than debugging any other target.

Thanks for the replies, although I still think that an integrated debugger is the one key 'must have' feature for Monkey.


wiebow(Posted 2012) [#6]
The big problem is that the debugger has to kick in while running the code, and monkey code is never compiled, only translated.


Why0Why(Posted 2012) [#7]
Let's just say I have been using lots of print commands ;)


andrew_r(Posted 2012) [#8]
Presumably Mark was planning on some kind on debug target with custom callbacks based on the GLFW target? It's the same principle as is used by the monotouch debugger for iPhone when debugging on the device. Either way, it's the only thing holding me back from using Monkey for a lot more than I'm currently using it for.


Ferdi(Posted 2012) [#9]
I would really love this feature too. GLFW target is fine, any target is fine, which ever is easier to implement and if it is possible. Just last night I was debugging and I had to put like 5 print statements to finally realize, the problem is that I need to change was in the if statement from "<" to "<=" *SLAP FOREHEAD* =)


Tibit(Posted 2012) [#10]
I also hope Mark is still working on this. This is something that increases productivity way more than one would first think. Even super skilled natural born programmers do mistakes from time to time and I for one is not a born natural programmer. I do not want to know the time I have spent debugging Monkey Code, but I would not be surprised if that time is more than 50% of my development time.

However with that said, a debugger should add something to the debugging that using a native target would not. Preferably speed. The html5 target is quick, but the C++ or XNA target take a lot of time to build. So for me it is always a last debug resort to build on those.


Why0Why(Posted 2012) [#11]
I would class myself as intermediate level and I have to work at it. It is a hobby for me. Like Tibit, I have spent far too much time debugging on occasion. Now, I have gotten to the point where if something doesn't work quite right I take a quick look and if the mistake isn't obvious, then I start putting prints in to narrow down the problem.


slenkar(Posted 2012) [#12]
I always used Prints in BlitzMax,
to use the debugger you have to know when to stop the program to look at the variables.
By that time you may as well be using Print statements

I rarely found it useful.


jpoag(Posted 2012) [#13]
http://www.morearty.com/blog/2011/04/10/fdb-the-flex-debugger-internals-of-how-stepping-works/

You could use the fdb.jar(exe) as a command line tool and attempt to pipe commands to it (I've been moderately successful at this for Continuous Integration).

My batch file looks something like:

fdb.exe < fdb_commands.txt

where fdb_commands.txt is:
run bin/TestSuite.swf
continue


fdb has all the commands for starting/stoping/stepping an application and dumping the stack trace.

Anyways, the output is directed to stdout, and my test suites emit tagged statements like this:
writeLine("##teamcity[testStarted name='{0}']", formatTestName(description.displayName));


The build agent is redirecting stdout to its build log and looking for ##teamcity statements. You could similarly pass information back into monk/jungle.

I know that monkey embeds a stack trace into the programs, what about a lookup table for variable names? Whenever the fbd breaks execution, Monk.exe could send a set of commands:

info locals
' foreach(i in locals)
print i

and use the lookup table to populate a 'locals' section where the code execution is broken at


AndroidAndy(Posted 2012) [#14]
I was thinking that the recent addition of reflection support in Monkey was the next step in creating a Monkey interpreter. If we had a Monkey interpreter, it would be the logical platform to integrate with a debugger. Mark delivers the interpreter with the hooks for debugging and Ziggy integrates a debugger into Jungle IDE.


Soap(Posted 2012) [#15]
Command line style control over apps while they are running so we can have more direct/specific interactive debugging. Maybe have pause / resume and the ability to select objects somehow with maybe Ctrl + clicking while paused or something? Check out this video for kind of what I mean: http://www.youtube.com/watch?feature=player_embedded&v=rejYKzLglSE

Jungle IDE / Monkey support for behavior-driven development.

Specification of the desired behavior is written, build is made, automated system runs the tests and they either pass or fail (I could see this running the same way Jungle IDE continuously compiles code to find normal errors - in addition it could also run RSpec like behavior tests), and then you either fix or refactor.


AndroidAndy(Posted 2012) [#16]
http://www.monkeycoder.co.nz/Community/posts.php?topic=2329


Tibit(Posted 2012) [#17]
"Mark delivers the interpreter with the hooks for debugging and Ziggy integrates a debugger into Jungle IDE."
Yeah if that where possible it would be the best solution I think. Because it is at the Editor side the REAL magic happen. I mean what we want is for the editor to be more powerful and we only want from Mark to enable the language to make that possible.

Like unit-testing, if that is integrated in the IDE, and can compile separate from the main project, that would be a gem! I mean who would not use such a cool feature? (probably many, but cool still)


jpoag(Posted 2012) [#18]
I was looking into writing a unit testing module this morning. Jungle listens to stdout, and if you read my post above about teamcity, you would see all the editor needed was a unit test listener that generated statements like:

##jungleide[testStarted name="testQuit"]
##jungleide[testFailed line="" msg=""]

So, for the editor, it would automatically register its listener, and for running outside the user would register the Print listener (or teamcity listener in my case).


Tibit(Posted 2012) [#19]
Not entirely sure how you mean by that unittest functionality.

I have my own editor PodEdit (frozen project for now) and there I of course talk to the monkey compiler .exe. The information I get back from tans.exe is enough to find and highlight the right class and the right line, but not much more than that unfortunately.

I would love to get more data back and also be able to send more data in. Of course I can always start another trans.exe instance and run that in parallel, however I would still not be able to insert (change) the monkey code that are in the memory of the compiler. I can only restart the whole monkeytrans.exe and let it re-parse everything on error or change.

However if I could replace rows of code. If trans.exe could pause/freeze instead of exit. And then perhaps using reflection one could change the monkey code (the editor can change the .monkey file on disk AND the code running in trans.exe) and in turn that would allow break & edit.

Maybe it is that simple. From an editor standpoint, it would be easy to integrate would trans.exe accept such commands.


jpoag(Posted 2012) [#20]
Lol, I think we have different ideas about unit testing:

http://en.wikipedia.org/wiki/Unit_testing#Applications

I use unit testing to develop complex pieces of code with known inputs and outputs. Typically, it's something that's not visual on screen (although I write visual tests for things like widgets).

Then, I leave the tests in place as a part of regression testing. If any bugs do crop up, I'll implement a test case that demonstrates the bug and then correct it. That makes sure the bug doesn't reappear down the line because of a fudged repo commit.


wiebow(Posted 2012) [#21]
I also leave the tests in place. I write new tests when I need new functionality, and then write code to make those tests pass. This is called Test Driven Development, and it is a great habit to get into when you use unit testing. Keeps you focussed and the result is clean code, which you KNOW works. When implementing the code in other projects, you know for sure that any bugs are caused by the implementation and not the actual code.

You can see an example of unit testing using my module here on my WIKI which also explains the concept of unit testing:
http://code.google.com/p/mutated-monkey/wiki/unittest


jpoag(Posted 2012) [#22]
@wiebow

You just saved me a lot of work. unittest looks great. Thank you, I really appreciate it!

testsuite.monkey : line 87 should read "if last"

@on Topic:

I don't think unit testing has a whole lot to do with a debugger feature request.


wiebow(Posted 2012) [#23]
Thanks, I'll look into that error. Note that the repository is more up to date than the download.

ontopic: No, but it may help while there is no debugger around.