Hello, Tup's Lua parser is based on version 5.2 of the official interpreter. It disables the standard functions dofile, loadfile, load and require (but leaves loadstring — a bug?), instead providing tup.include as a means to load & run arbitrary Lua files. Lua 5.2 introduced _ENV, which refers to the environment under which the currently-running code is running. Environment manipulation comes in handy for several things. For example, one could have build parameters (CC, CFLAGS and the like) in a separate Lua file, like this:
-- Fancy build parameters
CC='gcc'
CFLAGS={
'-O2'
}
and load such file under a custom environment, so that those variables
don't pollute the global environment. In standard Lua 5.2, one would do
this as follows:
local build_parameters = {}
-- See http://www.lua.org/manual/5.2/manual.html#pdf-assert and
http://www.lua.org/manual/5.2/manual.html#pdf-loadfile
assert( loadfile( "buildparameters.lua" , 't' , build_parameters ) )()
print( build_parameters.CC ) -- shall output: 'gcc'
but loadfile is forbidden in Tup. One can try to switch the environment
manually:
-- tup.include will become inaccesible after we switch the environment, so
save it in an upvalue
local tup_include = tup.include
local build_parameters= {}
-- Save the original environment for later restoration
local old_ENV = _ENV
_G._ENV = build_parameters
tup_include( "buildparameters.lua" )
-- Restore the environment
_ENV = old_ENV
but it doesn't work. Attached are two files composing a full test case. If
you are interested, put both in the same directory; then, running these
commands in the shell:
$ tup init && tup
will suffice to show the problem.
» This is the current state of affairs. The ability to load chunks (files,
in Tup) under a custom environment offers some nice possibilites, as
exemplified, and it would be very handy for me. Would it be feasible to
implement it? If so, could you, please?
A suggestion for the interface:
tup.include( path [, environment] )
If tup.include is implemented on top of loadfile, the implementation would
be:
function tup.include( path , environment )
loadfile( path , 't' , environment or _ENV )
end
As for loadstring, if it isn't intended that it be exposed, I could file a
bug or open a GitHub issue. It was deprecated in 5.2 anyway.
Regards,
Kalrish
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
test.lua
Description: Binary data
Tupfile.lua
Description: Binary data
