Jump to content




dofile() in MC1.7.10/CC1.74


6 replies to this topic

#1 Joeld98

  • Members
  • 17 posts
  • LocationEast Coast United States

Posted 02 October 2016 - 01:40 AM

At the risk of being a duplicate of the other recent dofile() question...

I've spent the better part of the afternoon trying to really understand os.loadAPI() vs. dofile() vs. loadfile()

If you want the back story:
Spoiler

I tried various tests with 1.7.4 and could not get get dofile to work directly but could override it with a definition I found on the PIL
function dofile (filename)
	  local f = assert(loadfile(filename))
	  return f()
end

The issue reported in CC1.7.9 on github says dofile should be "fnFile, e = loadfile( _sFile, _G )"

So my questions to the Pro's are:

1) 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

2) 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.

3) Any downside to defining dofile() as stated above to allow the API's that prefer that method to run without modification?

Bonus questions:

4) Can someone point me to a LDT environment setup tutorial / primer? I tried the dofile() examples on files in the same project but got
"com.naef.jnlua.LuaRuntimeException: cannot open func.lua: No such file or directory" where func.lua was the api file in the same project.

5) 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?

#2 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 02 October 2016 - 06:10 AM

View PostJoeld98, 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.

View PostJoeld98, 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

View PostJoeld98, 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.

View PostJoeld98, 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.

View PostJoeld98, 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.

#3 MKlegoman357

  • Members
  • 1,170 posts
  • LocationKaunas, Lithuania

Posted 02 October 2016 - 06:40 PM

View PostBomb Bloke, on 02 October 2016 - 06:10 AM, said:

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.

dofile() is still a feature of Lua 5.2 and 5.3, and that ComputerCraft.cfg setting doesn't remove it.




dofile() is better if the API will have an internal state of some sort. For example, the CC's settings API stores all the settings in one place, thus if you edit a setting in one program, that setting will be immediately changed for another program. That's how some "os.loadAPI()" APIs work. When using dofile(), each program loads the API for itself, and thus gets a new API table, together with it's state, created just for it. If settings API was made to be loaded with it, each program would get it's own settings and wouldn't need to worry about other programs changing those settings.

Of course, you could simply make a "os.loadAPI()" API which would work like the vector API, which requires the program to use the vector.new() function to get a vector object with it's own state (the x, y and z coordinates).

Edited by MKlegoman357, 02 October 2016 - 06:52 PM.


#4 apemanzilla

  • Members
  • 1,421 posts

Posted 02 October 2016 - 06:50 PM

There was a beta build a while ago that had a broken version of dofile but IIRC it was fixed before release, are you sure you're using 1.74 and not an old prerelease?

#5 KingofGamesYami

  • Members
  • 3,002 posts
  • LocationUnited States of America

Posted 02 October 2016 - 07:38 PM

Of course, you can always have the best of both worlds by checking for the shell when your file is being loaded. I do that in my Stitch API.

local stitch = shell and {} or getfenv() --#either set things in a table (for dofile) or the environment (for os.loadAPI)
stitch.func = function()
 ...
end
return stitch --#if it's dofile this is necessary, if it's loadAPI this does nothing.


#6 Joeld98

  • Members
  • 17 posts
  • LocationEast Coast United States

Posted 03 October 2016 - 12:05 AM

It was definitely the configuration (Good call Bomb Bloke!). The Tekkit Legends server pack has it set to true by default. Once I set that line to false, dofile() worked like a champ.
I discounted that at first because I found dofile() in the PIL from 5.0 on like MKlegoman357 stated but that setting prevented it from working.
B:disable_lua51_features=false

Good to know there is a work around for when you don't have control of the config.

Thanks for the detailed replies. Hopefully this will help others that get tripped up on this.

#7 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 03 October 2016 - 12:40 AM

View PostMKlegoman357, on 02 October 2016 - 06:40 PM, said:

dofile() is still a feature of Lua 5.2 and 5.3, and that ComputerCraft.cfg setting doesn't remove it.

*headdesk*

That'll teach me to believe anything anybody says ever - I read this baloney and didn't even think to check it. My bad.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users