 |
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
 Posted: Tue May 05, 2009 2:00 pm
Lua code from external files
|
I'm trying to come up with a way to put the majority of my Lua code in external files and load them into CMUD. What I've tried has been inconsistent and not quite the results I want, so your help will be appreciated.
Basically, I made an alias (call it "init") that sets the package.path to include my script files' directory. It then uses require (also tried dofile) to load the scripts.
| Code: |
package.path = "J:\?.lua;" .. package.path
require "affs" |
In J:\affs.lua
| Code: |
affs = {
["current"] = {},
["count"] = 0
}
print("Module loaded: affs") |
My affs variable (Lua, not zScript) does not always get initialized and the print doesn't execute, at least not when I use the init alias from an onLoad event for my session.
A related problem is that I can't reload scripts with this method, as it doesn't reinitialize the script engine and do the require anew. That's why I tried the dofile method, just to make it run the script regardless. |
|
|
|
|
wrym
Magician
Joined: 06 Jul 2007
Posts: 349
Location: The big palace, My own lil world
|
Posted: Tue May 05, 2009 2:38 pm
|
A few of my first lua scritps i did load from an external file, but I've since just put all of it into onload events, they were all using some zscirpt component and therefor completely unusable elsewhere.
But, I think i had the same problem your having. I found that dofile was capable of accepting full file paths.
| Code: |
| dofile('j:\affs.lua') |
Should do what your looking for. |
|
_________________
"To the engineer, all matter in the universe can be placed into one of two categories: (1) things that need to be fixed, and (2) things that will need to be fixed after you've had a few minutes to play with them" - Scott Adams, The Dilbert Principle |
 |
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue May 05, 2009 4:52 pm
|
I'd be interested in hearing from anyone who has a better understanding of Lua as to why Larkin's original idea didn't work. I can't think of anything unusual that I'm doing in CMUD that would prevent this. If "package.path" and "require" are all part of standard Lua, then calling them from an alias should still work.
I agree that putting stuff into onLoad events is good, but that doesn't really address Larkin's desire to put stuff in external files. I'd like to fix this if I can assuming it's something fixable within CMUD. |
|
|
|
|
wrym
Magician
Joined: 06 Jul 2007
Posts: 349
Location: The big palace, My own lil world
|
Posted: Tue May 05, 2009 5:21 pm
|
My first suspicion is/was that something with the path wasn't being set/read/used right, I vaguely remembering something with vista/lua causing erratic behavior there. But from the command line:
| Code: |
#lua {package.path = "C:\test\?.lua"}
#lua {require "bogus"} |
results in several lines in the error box, but the important one is...
| Quote: |
| no file c:estbogus.lua |
If I escaped the backslashes that line looks like it should, "C:\test\bogus.lua"
kinda odd how the t gets... eaten, and not escaped/passed on |
|
_________________
"To the engineer, all matter in the universe can be placed into one of two categories: (1) things that need to be fixed, and (2) things that will need to be fixed after you've had a few minutes to play with them" - Scott Adams, The Dilbert Principle |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue May 05, 2009 6:57 pm
|
Ahh, ok, so are you saying that doing:
| Code: |
#lua {package.path = "C:\\test\\?.lua"}
#lua {require "bogus"} |
works??
That actually makes sense. If the package.path is taking a Regular Expression, then the \ character is the normal "escape" character for regular expressions. But \t is the code for the TAB character. That would explain why it was "eating" the "t" character.
So Larkin, maybe try this:
| Code: |
package.path = "J:\\?.lua;" .. package.path
require "affs" |
The quick Google searching that I did always showed examples for package.path for Linux where the / character is used for directories. So maybe this is an issue with how Lua is compiled on Windows machines? |
|
|
|
|
wrym
Magician
Joined: 06 Jul 2007
Posts: 349
Location: The big palace, My own lil world
|
Posted: Tue May 05, 2009 7:28 pm
|
Yeah, but it's not exactly a regular expression...
| Lua 5.1 ref manual, package.loaders wrote: |
The second searcher looks for a loader as a Lua library, using the path stored at package.path. A path is a sequence of templates separated by semicolons. For each template, the searcher will change each interrogation mark in the template by filename, which is the module name with each dot replaced by a "directory separator" (such as "/" in Unix); then it will try to open the resulting file name. So, for instance, if the Lua path is the string
"./?.lua;./?.lc;/usr/local/?/init.lua"
the search for a Lua file for module foo will try to open the files ./foo.lua, ./foo.lc, and /usr/local/foo/init.lua, in that order. |
Lua is treating the package.path as a subsitution/search string/guideline.
Dofile probably doesn't have this problem because it's just trying to read that file, not find 1 file in one of several locations. |
|
_________________
"To the engineer, all matter in the universe can be placed into one of two categories: (1) things that need to be fixed, and (2) things that will need to be fixed after you've had a few minutes to play with them" - Scott Adams, The Dilbert Principle |
|
|
|
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
Posted: Wed May 06, 2009 1:17 am
|
I actually did use "J:\\?.lua;" in the package.path assignment. I typo'd it in my post (or, rather, the BB code stripped it).
Seems to just be an issue (or feature, probably) with using require more than once to try and reload the scripts. I tried the dofile function with the full path and that worked okay. I'm just used to the MUSHclient way of doing Lua now, where it actually reloads the entire script engine and pulls everything in through a single master Lua script. |
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Wed May 06, 2009 4:44 pm
|
Afaik you can't use require twice to reload a script, and that's part of its function. Well, that's not quite true - it depends on exactly what you mean by "reload". It won't call your files twice and load any changes, if that's what you mean.
The reason for this is because require first checks package.loaded[modname] to see if the package has already been loaded. If it has, then require returns the value in package.loaded and doesn't look any further. package.loaded[modname] is set to whatever your loader returns, if anything, or true if there was no return from your loader. So if your loader returns a table, then that exact same table is in package.loaded[modname] and no actual changes will take place.
You can read all about this here.
Dofile will always load whatever you tell it to load. |
|
|
|
|
Larkin
Wizard
Joined: 25 Mar 2003
Posts: 1113
Location: USA
|
Posted: Fri May 08, 2009 11:48 am
|
I already know about the behavior of require, actually, which is why I said I'm just used to the MUSHclient way of doing things. If there were a way to re-initialize the Lua script engine like there is in MUSHclient, I might even try using that for my coding, testing, and debugging. Using dofile is one way to go, but then you can get script space garbage over time, depending on what's being added/deleted in the scripts.
|
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Fri May 08, 2009 12:23 pm
|
Well, you could always just set package.loaded[modname] to false (or perhaps nil?) before you do your reload. But, like dofile, that won't actually do any cleanup of the kind you're suggesting.
But then from what I've seen of your scripts, you don't use (m)any loose variables in _G, preferring to keep everything in tables. As long as you're just putting something else in those same tables, then you won't need to do any active cleanup.
Which isn't to say that a command to reload the script engine wouldn't be useful, I guess. |
|
|
|
|
|
|
|
