I could alternatively patch the error message function of Lua
That's actually what I did for keeping the error messages readable (and to redirect them more easily to my IDE).
The simplest way I found for doing so is to redefine macros luai_writestring and luai_writeline in luaconf.h
In my version of luaconf.h I replaced
if defined(LUA_LIB) || defined(lua_c)
#include <stdio.h>
#define luai_writestring(s,l) fwrite((s), sizeof(char), (l), stdout)
#define luai_writeline() (luai_writestring("\n", 1), fflush(stdout))
#endif
with:
#if defined(CIM_LUA_CUSTOM_PRINT)
extern void CIMLuaPrintAppendString (void *L, const char* s);
extern void CIMLuaPrintLine (void *L);
#define luai_writestring(s,l) CIMLuaPrintAppendString(L,s)
#define luai_writeline() CIMLuaPrintLine (L)
#elif defined(LUA_LIB) || defined(lua_c)
#include <stdio.h>
#define luai_writestring(s,l) fwrite((s), sizeof(char), (l), stdout)
#define luai_writeline() (luai_writestring("\n", 1), fflush(stdout))
#endif
where CIMLuaPrintAppendString and CIMLuaPrintLine are the external C functions where do the specific processing of the error string (easy to recognize with a regexp).
Jean-Luc
Le 3 mai 2013 à 10:48, Thomas Jericke <tjericke@indel.ch> a écrit :
Hi Jean-Luc
As I see it, you did the same as I want to do, using the sourcename to store the extra information. I just add another twist to it. Instead of '@' I would use a '\0' as delimiter. My major concern is, that I don't want to have the hash or timestamp making my error messages unreadable. With the \0 I could hide the hash. I could alternatively patch the error message function of Lua and use another delimiter. Maybe that would be better, but I would still risk that the hash is visible if I don't patch all function that print out the source name.
Probably the best thing, is to test a few different approaches and compare the results.
--
Thomas
On 05/03/2013 09:47 AM, Jean-Luc Jumpertz wrote:
Hi Thomas,
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.
Jean-Luc
Le 3 mai 2013 à 08:40, Thomas Jericke <tjericke@indel.ch> 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:
"@mysource.lua\0THEHASHGOESHERE"
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.
--
Thomas
