lua-users home
lua-l archive

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


On Tue, Feb 7, 2017 at 5:59 AM, Javier Guerra Giraldez
<javier@guerrag.com> wrote:
> On 7 February 2017 at 02:23, Stephen Irons <stephen.irons@clear.net.nz> wrote:
>> However, in the source code, it is package.searchpath() (file
>> loadlib.c, function searchpath()) that implements the way Lua finds
>> modules. searchpath() modifies the name of the module to find
>> (replacing '.' with the directory separator), then takes a list of
>> path templates (from package.path), replaces '?' with the modified
>> name of the module, and passes each in turn to the C standard function
>> fopen(). This code is all very straightforward, with no special cases.
>>
>
>
> What I would like is that package.searchpath() would replace another
> character, like '$' with the directory where the function calling
> 'request' resides. a crude implementation:
>
> --------------
> local function getcallingdir(lvl)
>     for i = (lvl or 2), 1000 do
>         local fi = debug.getinfo(i, 'S')
>         if not fi then break end
>         if fi.source and fi.source:sub(1,1) == '@' then
>             local fname = fi.short_src or fi.source:sub(2)
>             return fname:match('^(.*)/[^/]*$') or fname
>         end
>     end
> end
>
> local oldsearch=package.searchpath
>
> function package.searchpath (name, path, sep, rep)
>     local calldir = getcallingdir(3)
>     if calldir then
>         path = path:gsub('%$', calldir)
>     end
>     return oldsearch(name, path, sep, rep)
> end
> -----------------------
>
> something like this would make it easy to write multi-source-file
> packages that can be installed anywhere, or even used as a "private"
> part of a bigger bundle.  a "main" file could require() other
> submodules with relative paths from itself, instead of having to
> specify the whole path or making all pieces directly visible to all
> scripts.

Ugh, this stuff is too interesting. I'll sleep when I'm dead...

So a very terse reading of lua.c (by an amateur C programmer) shows
there to be a define for "setprogdir()"; one function for Windows, one
for everything else. If I understand from past conversations, lua.c
isn't used when loading lua as a library. That aside, could the
function be removed from the define, and simply pass in a different
path separator based on the OS? I say loading lua as a library aside
because an application sophisticated enough to be loading as a library
perhaps would not need require() relative to the script being loaded
(or perhaps it would be very beneficial, I just don't know)?

Two things I noticed when reading lua.c:

1)There is a local char* in the Windows setprogdir called lb that
doesn't seem to be used anywhere?
2) The comments all call the loaded script an executable. My
understanding of the term executable means the OS can run a binary
file without another intervening application. Even if the file is byte
code, it still requires the Lua interpreter to run it, does it not?
Perhaps I am using the term wrong?

Night!

Russ