lua-users home
lua-l archive

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


I like this approach. Wouldn't be hard for the authors, not consume much cpu cycles, and being very 'lua-ish' altogether. :) Also, it provides a nice way to do other similar per-library stuff later, if seen necessary.

-ak


6.1.2005 kello 18:49, Mark Hamburg kirjoitti:

One of the things we did in our MacOS X bundle-based module system was to
give each bundle a unique environment (inheriting from the global
environment) and within that environment we set a variable providing a link
to the bundle.

If compound packages needed to be in directories, then one could certainly
provide a mechanism that would generate an environment of the following form
for each directory from which code was loaded:

    setmetatable( { PATH = < directory path > },
        { __index = _G, __newindex = _G  } )

C code is a bit trickier to deal with since it all shares the same global
environment. Our solution there was to treat the linked function as having a
single upvalue which would be set to the environment.

It would be nice if the package system either provided a standard for
supporting this or for overriding the standard load behavior. (I'd go dig
into it, but I've got a lot of code in my project right now that depends on
our homebrew mechanism so I'm not in the best position at the moment to go
play as much as I might like.)

Mark

on 1/6/05 8:01 AM, Asko Kauppi at asko.kauppi@sci.fi wrote:


With the new library/package system, is it possible for a library
module to know, where it is?

I'm changing Hamster to load by '-l hamster' and it would be awfully
nice if the hamster.lua code could refer to other files, using its own
installation path as a prefix.

I know.. you'll be saying use CPATH blahblah.. sure.  Only, if my
Makefile says '-l Tools/Hamster/hamster' then what?  Also to avoid
potential name clashes of subscript files, it would be better to look
straight in the right dir, imho.

-ak