 |
lua-l archive |
|
|
||
|
Am 20.05.2015 um 08:36 schröbte Dirk Laurie:
2015-05-20 8:17 GMT+02:00 Philipp Janda <siffiejoe@gmx.net>:I'd like to avoid parsing Lua files of possibly different Lua versions and patching their source code.One could argue that by definition a program with debug hooks in it is still under development, and changes to its source code are still to be expected.
The program doesn't have debug hooks in it, the debug hooks get installed by a driver program (pretty much like a debugger). The idea is to write test functions as local functions in the module, side by side with normal functions. The rationale would be similar to documentation tools like LDoc: it is supposedly easier to keep them in sync if they are next to each other. Other advantages would be that you can test internal functions without messing up the public interface of your module. Also, if you don't run under the test driver program that rescues the local test functions via the debug hook, they all vanish without a trace. Sure, I could do some arbitrary code transformations by hand (I have to write the test functions anyway), but this is very error prone: if I forget, some test functions will silently be skipped, and depending on the number of tested modules I may not notice. It's even worse if other people use this testing method, because they probably have no idea why it isn't working. Automatically patching the source code during loading on the other hand would be feasible as long as the line number information doesn't change. But I'd like to support multiple Lua versions and make the process at least coworker-proof ...
What I have learnt from this thread is "return hooks give undefined results when an expression rather than a variable is being returned". I think I'll patch it into my local copy of $LUA/doc/manual.html.
How did you come to that conclusion?! The issue of this thread explicitly also applies if you return a local variable, and there is nothing wrong with a return hook unless you want to query the local variables of the function that is about to return.
Philipp