I am currently workin on a debugger for codea. At the moment it can not do much, just show variables, and examine the call stack, and it can only be used to do post mortems after an error that terminated the program. The idea is to have breakpoints, single stepping, the whole shebang. However, because of the nature of codea, this would only work if I could yield from a debug hook - which can not be done, because lua 5.1 can not yield through a C funcion call. In order to work around this, I see 2 options.
Option one would be to replace the lua 5.1.4 coroutines by Mike Palls Coco. The advantages of this were that yielding from debug hooks would probably work, and also yielding from metamethods, through pcall and whatnot. The disadvantage is obviously that you would have to patch the interpreter. I have not tried this option.
The other option, which I am currently pursuing for a standard lua interpreter, is a small C function, that can resume a coroutine until a specified debug hook event occurs. The advantage is, it is just another additional function (probably to be injected into the debug table), but obviously it would do nothing to alleviate the “yield trough C calls” problem a standard lua interpreter has. I have created such a function, it works really well, and would be quite willing to offer it for inclusion in codea (quite selfishly, of course, because of the breakpoints and stuff ). How is your policy on such things? Would that even be an option? FTR we’re talking MIT style license, like lua has.
We’re happy to accept contributed code as part of the Codea Runtime Library (http://GitHub.com/TwoLivesLeft/Codea-Runtime). It’s under the Apache 2.0 license which is compatible with the license you mention. So far we have already included some fixes by CJ Hanson for Codea 1.4. We are crediting all contributors on the credits screen if their changes are merged back into Codea.
If you think your routines can help improve debugging then by all means, please send us a pull request (either on the develop branch or a feature branch). I’d be happy to make it part of the debug table in a future release. (I’m also keen to work on some debugging UI features for Codea.)
I understand Lua 5.2 can yield through a C function. What are your thoughts on 5.2?
Currently my stuff works against a vanilla lua 5.1.4 and 5.1.5 interpreter, I have not integrated it into the Codea Runtime yet, as I am still experimenting with some aspects of it, such as what happens if the coroutine actually yields, with return values, or resuming with arguments. This is important for debugging coroutines.
5.2 can yield through metamethods and pcalls and such, but it still can not yield through debug hooks. I have tried that. As I intend to make that resume_until thing availavle to the lua people as well, I will also build and test it against 5.2. I have a bit of code in place to inhibit yielding when lua 5.1 can not yield, this is obviously not needed for 5.2.
As for upgrading Codea to 5.2, the biggest boon would be the yielding through C calls stuff. However, as some things have changed, you should expect user code to break if you do that.
I will be on vacation starting end of next week, by then I will not have integrated the stuff into the codea runtime. I could send you the code before that by email, so that you can play with it, or wait until I have found time to integrate it, which would probably be some time in July…
@gunnar_z Thank you for the info on 5.2. Do you know how much having debug hooks added to the interpreter affects performance? Is it a small enough trade-off to always have user code running with debug hooks, or is it worth offering a no-debug option?
If you have a free Github account you can send us a pull request on the develop branch. That will make it very easy to test and merge your changes. Email is fine too, if you prefer it.
5.2 would break some user code, that’s true. We have a branch that uses 5.2 but it breaks all of the data types defined in C (vec2, image and so on), and we haven’t gotten around to resolving that yet.
@simeon if the hook does basically nothing, it should not affect performance too much. Depending on the type of hook you set, it might be called on every vm instruction, so it might have some impact. However, the debug hook stuff is not quite as straightforward as one might think. For one, there is a documentation or implementation glitch, not quite sure, which. The impact of that is that you have to pass 2 as count if you want to step one instruction, because contrary to what the lua docs claim, the debug count is decremented and if zero the count hook is invoked before the vm instruction is carried out, so if you set the count to 1, you will never execute anything. Also, if you have the line, call and return events set, only the line events are ever reported… and line events are reported when he line is invoked, so if you yield from a line hook and then resume, the line event will fire again at the same position.
My function is feature complete now, modulo bugs, of course. I will send it in a mail later, then you can play with it. I know it will help me, maybe it can also do what you want. At any rate, you can see what I did to work around some of these things, so you won’t have to re-invent the wheel on this Bottom line is, I think you will have to do some stuff in the debug hook to cater for all of the oddities, so it would probably be too much of a burden to have any debug hooks enabled all of the time.
You’re welcome. As for enabling it on request, maybe if you just wrap my luaopen_* function into a lua function, give it a funky name, that should do it. I don’t think that it needs to be possible to disable it again.
). How is your policy on such things? Would that even be an option? FTR we’re talking MIT style license, like lua has.
Bottom line is, I think you will have to do some stuff in the debug hook to cater for all of the oddities, so it would probably be too much of a burden to have any debug hooks enabled all of the time.