lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



On 18-Oct-06, at 4:41 PM, Edward Mitchell wrote:


"Rici Lake" <lua@ricilake.net> wrote in message
de0b517e2d945e342c767922176483f6@ricilake.net">news:de0b517e2d945e342c767922176483f6@ricilake.net...

On 17-Oct-06, at 8:38 PM, Edward Mitchell wrote:
As far as I can see, there's nothing like this in lua.c. It seems that
lua_load(...) (or luaL_loadbuffer) should return an status code that
implies
"Needs more input."

It returns a syntax error with an easily parseable error message, which is
what lua.c does. See the function incomplete() on line 161 (v5.1.1)

On that basis, it seems that I can use the loop like:

    while(templateFile) {
        templateFile.getline(buff, BUFSIZ);
        // ?? debug echo to the console
        fprintf(stdout, "%s\n", buff);
while(Incomplete(L, luaL_loadbuffer(L, buff, strlen(buff), "Line")))
{
            templateFile.getline(buff, BUFSIZ);
        }
        iError = lua_pcall(L, 0, 0, 0);
        if(iError) {
            // echo the error message
            fprintf(stdout, "%s\n", lua_tostring(L, -1));
            // quit on any error
            break;
        }
    }

I looked at incomplete() and it seems to make a decision on whether the
string <eof> is present in the error message. Since incomplete() is not one of the lua_... or luaL_... group of routines, is it likely that the '<eof>'
ending message will go away in the future.

Possibly. But anyway, that's only useful for compiling single chunks. Note that lua.c concatenates all the lines together each time it tries, which is probably unreasonable for a large file.

lua_load processes an entire compilation unit, although it will call the supplied callback function in order to receive the compilation unit in separate strings. It does not retain state from one call to the next.