Re: [ANN] Lua 5.2.0 (rc6) now available

[HyperHacker <hyperhacker@...>]

On Wed, Dec 7, 2011 at 19:07, Ryan Pusztai <rpusztai@gmail.com> wrote:
>
> On Dec 7, 2011 6:21 PM, "Daurnimator" <quae@daurnimator.com> wrote:
>>
>> On 8 December 2011 06:06, Florian Weimer <fw@deneb.enyo.de> wrote:
>> > * Luiz Henrique de Figueiredo:
>> >
>> >> We expect this release candidate to be the final version of Lua 5.2.0,
>> >> unless serious glitches are found soon.
>> >
>> > The library search path seems wrong to me:
>> >
>> > src/lua: /tmp/t.lua:1: module 'lpeg' not found:
>> >        no field package.preload['lpeg']
>> >        no file '/usr/local/share/lua/5.2/lpeg.lua'
>> >        no file '/usr/local/share/lua/5.2/lpeg/init.lua'
>> >        no file '/usr/local/lib/lua/5.2/lpeg.lua'
>> >        no file '/usr/local/lib/lua/5.2/lpeg/init.lua'
>> >        no file './lpeg.lua'
>> >        no file '/usr/local/lib/lua/5.2/lpeg.so'
>> >        no file '/usr/local/lib/lua/5.2/loadall.so'
>> >        no file './lpeg.so'
>> >
>> > I think the correct order would be:
>> >
>> > src/lua: /tmp/t.lua:1: module 'lpeg' not found:
>> >        no field package.preload['lpeg']
>> >        no file '/usr/local/share/lua/5.2/lpeg.lua'
>> >        no file '/usr/local/share/lua/5.2/lpeg/init.lua'
>> >        no file '/usr/local/lib/lua/5.2/lpeg.lua'
>> >        no file '/usr/local/lib/lua/5.2/lpeg/init.lua'
>> >        no file '/usr/local/lib/lua/5.2/lpeg.so'
>> >        no file '/usr/local/lib/lua/5.2/loadall.so'
>> >        no file './lpeg.lua'
>> >        no file './lpeg.so'
>> >
>> > The idea is that a module is not picked up from the current directory,
>> > unless it cannot be found elsewhere.
>> >
>>
>> Lua files are searched for before C modules (ie, iterates over
>> package.path before package.cpath)
>> PS though; adding ./?/init.lua to the default search path is probably
>> useful.
>>
>
> +1 Yes please.
> --
> Regards,
> Ryan
>
> Sent from my Droid

My Lua init script (referred from the LUA_INIT environment variable)
sets some useful paths, and wraps require() to look for 32-bit and
64-bit versions (and just use whichever loads successfully):
package.path
 =  './?/init.lua;'
 .. './libs/?.lua;'
 .. './libs/?/init.lua;'
 .. '/home/rena/dev/lua/libs/?.lua;'
 .. '/home/rena/dev/lua/libs/?/init.lua;'
 .. '/home/rena/.luarocks/lib/lua/5.1/lua51-?.lua;'
 .. '/usr/local/lib/lua/5.1/?.lua;'
 .. '/usr/lib/lua/5.1/?.lua;' .. package.path
package.cpath
 = './?/init.so;'
 .. './libs/?.so;'
 .. './libs/?/init.so;'
 .. '/home/rena/dev/lua/libs/?.so;'
 .. '/home/rena/dev/lua/libs/?/init.so;'
 .. '/home/rena/.luarocks/lib/lua/5.1/lua51-?.so;'
 .. '/usr/local/lib/lua/5.1/?.so;'
 .. '/usr/lib/lua/5.1/?.so;' .. package.cpath

local _require = require
function require(name)
	local names = {name, name .. '-x86', name .. '-x64'}
	for i, name in ipairs(names) do
		local res = {pcall(_require, name)}
		if res[1] then return unpack(res, 2) end
	end
	
	--we couldn't load any module, so do an unprotected call to load
	--the given name again, so that it throws an appropriate error.
	--we need to clear the module from package.loaded too or we'll just get
	--"loop or previous error" from trying to require it again.
	package.loaded[name] = nil
	return _require(name)
end


I still wonder why package.path/cpath are strings rather than tables...

-- 
Sent from my toaster.