Joeld98, on 02 October 2016 - 01:40 AM, said:
I came across a statement from exxero who authored sheets who says:
Quote
There are two ways you can load Sheets into your environment, either as an API (via os.loadAPI) or as a local library (using dofile). We recommend the latter, as using dofile means that you can use any file name for the library itself, you don't pollute the global environment and accessing the local table is slightly more efficient.
Is there any truth to the environment and speed comments? It looks to me like the PIL version and CC version all end up in _G
The way Exerro intends you to use
Sheets is to call dofile() on it, and then assign the table he coded it to return when called, to a local variable. You could instead assign it to an element in _G, if you really wanted, but dofile() doesn't dump anything in there unless the code you get it to execute tells it to. It compiles source into a Lua function and then executes it, that's all. You can run code that returns stuff, you can run code that doesn't return stuff, it's a fairly low-level function with a
lot of different applications.
The ComputerCraft-specific os.loadAPI(), on the other hand, expects scripts written according to a specific layout - it executes them, as dofile() does, but uses a specific environment table and ignores any return values. Instead, when those scripts complete it takes anything they left in their global environment (usually a bunch of declared functions), bundles them up into a
new table which it names after the script file, and then sticks that in _G. It's a relatively high-level function intended for a specific purpose.
(If you're not familiar, "low-level" functions tend to perform simple tasks, whereas "high-level" functions perform complex ones. Low-level coding gives you a lot more flexibility (and often efficiency), but you tend to need to combine a lot of them to get a job done! High-level functions tend to be inflexible and inefficient, but using them allows you to keep your own scripts short and simple.)
In terms of whether accessing stuff from _G is any faster or not: it's true that you'll get faster access times from local variables. When you refer to a variable in your code, the interpreter has to figure out which scope it's in, starting with the local and ending in _G; the less places it has to look before finding it, the better.
In practise this tends not to matter. But if you intend to call certain functions
very frequently (eg within loops lasting hundreds of iterations), it
does pay to copy values from _G to a local variable. Don't just copy pointers to API tables, though! If there's a specific function you want, get the specific
function pointer! This way, you furthermore save on time that'd otherwise be spent indexing into your table over and over. Eg:
local bitBand = bit.band
for i = 1, 100000 do
-- call bitBand over and over, instead of bit.band
end
But again, for general usage this really doesn't matter - it's a micro-optimisation.
Joeld98, on 02 October 2016 - 01:40 AM, said:
Can someone confirm what version of CC dofile() was introduced in and/or fixed in? I did not see it anywhere in the release notes.
dofile() has been available within CC since long before any MC 1.7.10 builds were available. It'd surprise me if it wasn't there since day one.
The only build I'm aware of which was missing it
was a pre-release version of 1.79 (which no one's got any good reason to be using). Difficult to comment on your "attempt to call nil" error without seeing the code involved in context. You didn't set (or use a modpack which pre-sets) "disable_lua51_features" to true within
ComputerCraft.cfg, did you?
That setting blocks access to dofile() (and a bunch of additional functions), and should only be used if you're wanting to develop code that'd (hopefully) be forwards-compatible with a hypothetical future version of ComputerCraft based on Lua 5.2 (which may or may not ever actually come into existence)... If memory serves, some Tekkit pack or other does this for no good reason.
The function is defined within bios.lua. There are a few githubs around which track CC's Lua file history -
eg. Unfortunately github web interface is pretty rubbish for this purpose (even wikipedia offers a better diff tool, and
that's not intended for hosting code!), but hey, the data's there. You want the <> buttons.
The definition in 1.79 goes:
dofile = function( _sFile )
local fnFile, e = loadfile( _sFile, _G )
if fnFile then
return fnFile()
else
error( e, 2 )
end
end
Joeld98, on 02 October 2016 - 01:40 AM, said:
Any downside to defining dofile() as stated above to allow the API's that prefer that method to run without modification?
Frankly I'd say that any coder who expects you to use dofile() to load a given API should be making sure it works with the version of dofile() included in the version of ComputerCraft they expect you to use.
Again, difficult to say without seeing the code in context.
Joeld98, on 02 October 2016 - 01:40 AM, said:
Can someone point me to a LDT environment setup tutorial / primer?
Apparently one's built-in within the included help files, but
it's also online.
Joeld98, on 02 October 2016 - 01:40 AM, said:
Being relatively new to CC, Lua and coding, is this par for the course in terms of running down issues and work arounds in various versions?
os.loadAPI(), as well as various other functions, are included with CC more or less so that novice coders don't have to know about correct usage of the likes of dofile(), and can instead jump straight to making their turtles build houses or whatever.