A few eval issues
Decoda is very sweet - we've got a lightly modified Lua 5.1 implementation with crazy sandboxing of the lua chunks and it all just works. I've been setting breakpoints with great joy! I have a few questions:
1-Compiled binary matching a script file in the project.
"This script was loaded as a compiled binary file. To view script source code,
the uncompiled script file must be added to the current project."
I've tried to match do this, but I'm not sure how the matching is done.
fileName = s:\ViolentFPS\Scripts\Awesome.lua
lua_load(mMasterState, LuaReader, &lr, fileName.c_str()
In my project I add s:\ViolentFPS\Awesome.lua - then it comes up as 'Awesome.lua' with that warning and the code and breakpoints itself comes up as '@Untitled4.lua'. So this leaves me with 3 entries in the project: @Untitled, Awesome.lua (with the compiled binary warning) and Awesome.lua (the one I added but setting breakpoints is futile).
Any hints on how this is matched to the file in decoda would be great!
2-Startup time is insanely long as mentioned in the other thread (for debug builds we use tons of DLLs, for release its statically linked). Would it be difficult to optionally scan a specific DLL (e.g. All our Lua is compiled into a Script.Debug.dll)?
3-I've not had any luck with __tostring showing up in the watch window (although I am using SWIG to bind this metamethod so it may be a SWIG related problem). No biggie, but if there are hidden gotchas anyone is aware of I'd love to hear them.
Thanks for listening!
-Steve
1-Compiled binary matching a script file in the project.
"This script was loaded as a compiled binary file. To view script source code,
the uncompiled script file must be added to the current project."
I've tried to match do this, but I'm not sure how the matching is done.
fileName = s:\ViolentFPS\Scripts\Awesome.lua
lua_load(mMasterState, LuaReader, &lr, fileName.c_str()
In my project I add s:\ViolentFPS\Awesome.lua - then it comes up as 'Awesome.lua' with that warning and the code and breakpoints itself comes up as '@Untitled4.lua'. So this leaves me with 3 entries in the project: @Untitled, Awesome.lua (with the compiled binary warning) and Awesome.lua (the one I added but setting breakpoints is futile).
Any hints on how this is matched to the file in decoda would be great!
2-Startup time is insanely long as mentioned in the other thread (for debug builds we use tons of DLLs, for release its statically linked). Would it be difficult to optionally scan a specific DLL (e.g. All our Lua is compiled into a Script.Debug.dll)?
3-I've not had any luck with __tostring showing up in the watch window (although I am using SWIG to bind this metamethod so it may be a SWIG related problem). No biggie, but if there are hidden gotchas anyone is aware of I'd love to hear them.
Thanks for listening!
-Steve
Comments
1-Compiled binary matching a script file in the project.
"This script was loaded as a compiled binary file. To view script source code,
the uncompiled script file must be added to the current project."
I've tried to match do this, but I'm not sure how the matching is done.
fileName = s:\ViolentFPS\Scripts\Awesome.lua
lua_load(mMasterState, LuaReader, &lr, fileName.c_str()
In my project I add s:\ViolentFPS\Awesome.lua - then it comes up as 'Awesome.lua' with that warning and the code and breakpoints itself comes up as '@Untitled4.lua'. So this leaves me with 3 entries in the project: @Untitled, Awesome.lua (with the compiled binary warning) and Awesome.lua (the one I added but setting breakpoints is futile).
Any hints on how this is matched to the file in decoda would be great!
2-Startup time is insanely long as mentioned in the other thread (for debug builds we use tons of DLLs, for release its statically linked). Would it be difficult to optionally scan a specific DLL (e.g. All our Lua is compiled into a Script.Debug.dll)?
3-I've not had any luck with __tostring showing up in the watch window (although I am using SWIG to bind this metamethod so it may be a SWIG related problem). No biggie, but if there are hidden gotchas anyone is aware of I'd love to hear them.
Thanks for listening!
-Steve<!--QuoteEnd--></div><!--QuoteEEnd-->
When you call lua_load, put an @ sign at the beginning of the file name. This is the convention luaL_loadfile uses and Decoda looks for that to determine if it's a file name.
The next update of Decoda will include a caching mechanism to address the slow startup problem with lots of DLLs. Sorry for the inconvenience.
There aren't any gotchas with __tostring, so I'm not sure what the problem there is.