-
-
Notifications
You must be signed in to change notification settings - Fork 407
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added inspect() and iprint() scripting functions to help debugging
string inspect ( arg, table options ) --Provides a human description of any argument, i.e. string,bool,table,element,xml etc. Options doc: http://github.com/kikito/inspect.lua. string iprint ( ... ) --Prints any number of arguments in human readable format Also cleaned up preloaded Lua code system for easier addition of preloaded Lua in future.
- Loading branch information
1 parent
df8576f
commit e8bf3b5
Showing
9 changed files
with
574 additions
and
103 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
22 changes: 22 additions & 0 deletions
22
Shared/mods/deathmatch/logic/luascripts/coroutine_debug.lua
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
--Luaify;SCRIPT_STACK=R"~LUACODE~( | ||
--[[ | ||
SERVER AND CLIENT. | ||
Output errors that occur inside coroutines | ||
--]] | ||
|
||
-- Protect some functions from modifications by resources | ||
local tostring = tostring | ||
local outputDebugString = outputDebugString | ||
|
||
coroutine._resume = coroutine.resume -- For access to the original function | ||
local _coroutine_resume = coroutine.resume | ||
function coroutine.resume(...) | ||
local state,result = _coroutine_resume(...) | ||
if not state then | ||
outputDebugString( tostring(result), 1 ) | ||
end | ||
return state,result | ||
end | ||
|
||
--)~LUACODE~"; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
--Luaify;SCRIPT_STACK=R"~LUACODE~( | ||
--[[ | ||
SERVER AND CLIENT. | ||
Code for allowing this syntax: exports.resourceName:exportedFunctionName (...) | ||
exports["resourceName"]:exportedFunctionName (...) | ||
exports[resourcePointer]:exportedFunctionName (...) | ||
Aswell as the old: call ( getResourceFromName ( "resourceName" ), "exportedFunctionName", ... ) | ||
--]] | ||
|
||
-- Protect some functions from modifications by resources | ||
local getResourceRootElement = getResourceRootElement | ||
local call = call | ||
local getResourceFromName = getResourceFromName | ||
local tostring = tostring | ||
local outputDebugString = outputDebugString | ||
|
||
local rescallMT = {} | ||
function rescallMT:__index(k) | ||
if type(k) ~= 'string' then k = tostring(k) end | ||
self[k] = function(resExportTable, ...) | ||
if type(self.res) == 'userdata' and getResourceRootElement(self.res) then | ||
return call(self.res, k, ...) | ||
else | ||
return nil | ||
end | ||
end | ||
return self[k] | ||
end | ||
|
||
local exportsMT = {} | ||
function exportsMT:__index(k) | ||
if type(k) == 'userdata' and getResourceRootElement(k) then | ||
return setmetatable({ res = k }, rescallMT) | ||
elseif type(k) ~= 'string' then | ||
k = tostring(k) | ||
end | ||
|
||
local res = getResourceFromName(k) | ||
if res and getResourceRootElement(res) then | ||
return setmetatable({ res = res }, rescallMT) | ||
else | ||
outputDebugString('exports: Call to non-running server resource (' .. k .. ')', 1) | ||
return setmetatable({}, rescallMT) | ||
end | ||
end | ||
exports = setmetatable({}, exportsMT) | ||
|
||
--)~LUACODE~"; |
Oops, something went wrong.
e8bf3b5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Luaify" is definitely an interesting approach, but in my humble opinion a bit too hacky for the little benefit we earn.
I'd suggest moving the Lua code into a namespace in
.h
files instead.Like this:
e8bf3b5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your comment, was hoping to see opinions on this. I agree it's pretty hacky. The goal was to have .lua files that could come directly from a resource that could be loaded in transparently, or vice versa - let's say if someone wanted to improve inspect() for themself. This was never going to be entirely possible/practical - and 'Luaify' was the closest approach. I'm not opposed to your suggestion, but do think there's some do think there are advantages to making .lua files as simple as possible to load. Moving each .lua file into an individual .h file might prove a sensible middle ground (compared to the horrendous multiline C++03).
It's also worth considering the impact of dynamic allocation involved in 'Luaify' each time a new VM is created. I don't think it's significant but probably worth factoring into arguments against it.
Open to further comments surrounding this.
e8bf3b5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering Premake, this hack becomes less attractive