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

[Glenn Maynard <glenn@...>]

On Fri, Oct 06, 2006 at 11:39:32AM +0100, David Jones wrote:
> What mystic forces locates "code snippets" can arrange that when a  
> located code snippet wants to "source in" another chunk the mystic  
> invocation that it uses to do that "source in" the other code chunk  
> is able to find the code chunk using the information that was  
> obtained when the first code snippet was located.

I'm not sure what information you're referring to.  If I load a chunk:

return { a = "file", parts = { loadfile("tail.lua"), loadfile("nose.lua") } };

with luaL_loadfile(L, "asset/path/dog/dog.lua", and evaluate it later
on, I can't see any way at that point to discover "asset/path/dog/",
other than by parsing it out of debug info.

I suppose I could also store the path in a weak table, keyed to the
chunk itself.  That wouldn't need any special attention if debug
information was disabled for low-memory systems.

> You presumably have some function "foo" that finds another code chunk  
> and runs it?  "foo" can arrange that when it is running another code  
> chunk and that code chunk does "foo" its "foo" is able to find code  
> chunk relative to the first one.  "foo" knows this because it found  
> the first code chunk in the first place.

I have no "foo"; that's exactly what I'm planning to implement.
Currently, I only load individual code chunks, with absolute paths.

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.

-- 
Glenn Maynard