[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Storing a hash of the source file for debug info
- From: Jean-Luc Jumpertz <jean-luc@...>
- Date: Fri, 3 May 2013 09:47:46 +0200
I had the same concern of differentiating several versions of a source file in the interpreter and solved it without changing Lua's internals, by taking advantage of the fact that you can pass an arbitrary string as the source name of a loaded Lua code chunk (e.g. in the "source" parameter of Lua function "load" or in the "name" parameter of the C function "luaL_loadbuffer").
Using these methods, it is easy to write a custom load-file function in which you define the source name that fits your needs. In my implementation, I concatenate the file name and modification date like "mysourcefile.lua@12345678" - as this allows the sorting by time of the loaded versions - but the same can be done with a hash of the source code.
Le 3 mai 2013 à 08:40, Thomas Jericke <firstname.lastname@example.org> a écrit :
> Hi all
> I am currently improving our editor/debugger (just finished painting globals purple :-) ) and my current task is to improve the source lookup.
> Currently the lookup is based on the sourcename alone. This is usually OK but we have several cases where it is possible that different versions of the same file is loaded in the interpreter. Or the source in the interpreter is very old, our application can literally run for months. The most obvious case of a source/interpreter conflict is when a programmer mode changes/fixes without restarting the program (= restarting the machine).
> So what I like to do is to store a hash of the source file which is then provided with the lua_Debug information. Once I am debugging a file I can use the hash to double check if the file that the editor is showing is really the one that the interpreter runs. I am then able to warn the user or show a "source not found" error.
> As I see it I need to add and receive the hash at exactly the same places as the source-name that would be in the "Proto" struct field "source". Now what I thought, as the two always go together, I could actually store the hash inside the source variable. I would than have the advantage of being backwards and forward compatible that is: I could load compiled Lua code from a patched parser into an unpatched interpreter, and I could load Lua code from an unpatched parser into a patched interpreter.
> My idea is, as a Lua string may have \0 within the string, I could just add the hash behind the name like:
> As the length of the string is stored, my patched interpreter will find out if there is a hash or not, on the other hand a old interpreter will simply return the char* pointer of to the name, which is from a C/C++ point of view still the same as before.
> It will break the comparability of old interpreters using the Lua debug library (not the C debug API), but we are not using the Lua debug library anyway only the API.
> So what do you think? Are there any incompatibilities I don't see? I am open to any input.