Re: relative source paths; "source" debug info field

[Glenn Maynard <glenn@...>]

On Fri, Oct 06, 2006 at 01:10:53PM -0400, Glenn Maynard wrote:
> Another issue I'm thinking of with this scheme: there's no way to tell
> what bit of code created any part of the table.  That makes useful error
> messages impossible, once the recursive loading becomes non-trivial.
> Right now each part is loaded on-demand, so the path is still available
> when it's used, but I'd really like loading to be done natively.  Hmm.

I'm thinking along these lines:

return definition {
    File = "file.png",
    Children = {
        definition { File = "file2.png" },
        LoadFile("secondary.lua") -- another file like this one
    }
}

where definition() looks like (probably implemented in C):

function definition(t)
   t.Path = GetPath(1) -- caller's directory
   t.File = GetFile(1) -- caller's filename
   t.Line = GetLineNumber(1)
   return t
end

where Path is used to resolve non-Lua references ("file2.png" located in
the same directory), and File and Line used for error messages (possibly
combined and preformatted like luaL_where).

I wish the debug API had better performance documentation than the
ominous "they can be very slow".  It doesn't seem like getting the
line number is a slow call, based on a quick runtime test and a glance
at the source, but documentation would be preferable than hoping I'm
not missing any obscure expensive corner cases to bite me later.  At
least the line number isn't critical here, just very handy--if it turns
out to cause problems I could remove it, but the others will be integral.

-- 
Glenn Maynard