LuaPlus binding with Tilde debugger.

#101 @James

As a database guy, i prefer SQL :P .

Concerning garbage collection, we are forcing a LUA GC every few frames, so the garbage to collect won't become too big.

For syncing the state of LUA to the C++ side, my preference is doing it in a "lazy" way. Accumulating a journal of changes that need to happen on the LUA side, and then playing the journal on the LUA side when appropriate.

#102 I want to add

#define DefineEngineMethod( className, name, returnType, args, defaultArgs, usage )

IMPLEMENT_LUA_FUNC0( className, _ ## className ## name ## frame:_exec, returnType )

I want to add this to the DefineEngineMethod Macro but my problem is that I want LUA_FUNC# to represent the number of arguments.

How do I do this?

I don't want a case statement or pass through another function.

Any ideas?

#103 Hey Lefteris? Am I wasting my time on Lua when you already have an implementation? Are you unable to make it open source? Sorry to put you on the spot. :)

#104 github.com/GarageGames/Torque3D/commit/59a5261b0298cdd04f1c7ba684e8d85b9dff2057 that was merged into development a couple days back seems relevant to your interests...

On argc bit, looks like there's a hook via _EngineConsoleThunkCountArgs along with 6 usage samples?

#105 @ Antony

Do you mean something like this:

#define TEST_FUNC0 Con::printf("worked0");
#define TEST_FUNC1 Con::printf("worked1");
#define TEST_FUNC2 Con::printf("worked2");

#define TEST(func_num) TEST_FUNC##func_num

#106 Thank you both.

Azaezel. Thank you that seems to be working.

#107 If you're going to make a macro for each number of arguments then you could use templates as easily. The reason the team stayed with macros in the first place instead of going over to EngineAPI was that variadic templates didn't exist at the time.

Instead of making a macro for each case, you could pass in the number of parameters yourself, or just let Lua figure out how many parameters it is receiving - though this does make early error detection difficult.

#108 Thanks Richard. As I dig into this template & macros stuff. I keep making connections with previous Forum messages. Thank you for all of the previous information. I think I did everything I could to avoid digging in too deeply. Don't get me wrong templates are awesome, but this stuff is so very hard to read.

#109 OMGosh. Now I know what James means about Global namespace. Ugghhh!

#110 I don't know if what I am about to suggest is what WLE did. But I think I can get my parsing script to point to the static functions created by the macros so at least I wouldn't duplicate the functions. But maintain the structure from previous. No scriptbinding.h and scriptbinding.cpp. Just the bindinging files pointing to the Macro generated functions. It's hard to get what I want in the macros because the global functions are not completed in the scope of the macro and there is no pre-declaration. The more I think of it the more I hate the thought of having people maintain the lua binding by running a generator to generate the binding. Rock and hard place. Ughhh! :)

#111

Quote:
The more I think of it the more I hate the thought of having people maintain the lua binding by running a generator to generate the binding.

Agreed. This is a worse case scenario in my books.

#112 What I said was probably not very constructive. The reason I didn't think the binding generator was a good idea for the community. Was because the binding requires continued maintenance. I think I have come to the similar conclusion as James about Lua being added in via the macros and templates. But I really want to use Lua so I will just maintain a separate repository for Lua and maintain it until i can't stand it anymore. Thank you everyone for all of your help. This community is the best!

#113 Pointing Lua to the macro-generated binding functions seems like a good idea, instead of adding manual binding functions.

One thing to note is that using an external parser tool might have benefits such as reducing duplicate documentation. Currently many fields are documented twice - one in Doxygen style in the source, and one in the API macros or initPersistField. If an external tool was used it could theoretically reuse the Doxygen comments. The two sets of documentation do have different audiences (engine coders versus scripters) but there is a lot of duplication happening, especially on member fields.

#114
okay, I promise no more ;)

#115 Daniel I see where you are coming from but I am having a hard time figuring out a way to use the current templates to create a more direct binding and push work into templates.

The way James has done it previously, feel free to correct me if I am wrong James, is called a bridge. Which provides a function which translates from one language to another at a run-time performance cost. I am looking for a way via templates similar to how TorqueScript bindings have been done. You guys may not have liked my previous attack on the problem. But it certainly, although not good on memory usage and flexibility, was Fast.

Unfortunately I have not used templates to this extent so I am having a hard time getting my head around it. But I haven't completely given up on it.

Steve is right about one thing. I have never tried previously to develop a game in Torque. But I am trying now. I could be wrong... Steve. But it seems like ALL you're rhetoric is going to accomplish, is alienate people who are trying to contribute and make Torque better.

#116 "Hey Lefteris? Am I wasting my time on Lua when you already have an implementation? Are you unable to make it open source? Sorry to put you on the spot. :)"

Luis is going to open source it.

Nevertheless, your work is not wasted. I think that the knowledge that you've gained from your work will help in solidifying the perfect bindings :) . It is very probable that you'll have insights and solutions for problems that we've missed and vice versa.

#117 Give me some time for release our LuaJit work, sure we can work together for improve current branches :)

#118 @Anthony - Steve is messing with you....

Of course, he is one of the few people who has actually shipped a game with Torque 3D.

WARNING - opinions follow

More to the point, though - Torquescript is rarely the bottleneck and for all its warts it's still completely functional. It may not be optimal, but if you're calling fifty million lines of script per tick then there is a fundamental flaw in your design, not the scripting language.

I like Lua a lot more than I like Torquescript, but as you can see there is a ton of work involved in this. Time that could be used to make a game instead. I think you're doing something very cool, but even if I disagreed with you one hundred percent I'd still bow to my belief that only you can decide where your time is best spent. My earlier mention of the EngineAPI and variadic templates was intended both as a historical note and a helpful hint - even though I wouldn't use my time for this I don't want to be discouraging or negative. All projects are worthy, if simply for the sake of learning.

#119 @Lefteris & Luis - Very exiting stuff guys. :)

@Richard - I have been actually very torn about the issue of scripting languages since using Torque. Just to learn about it. I started a project in it and have spent most of my time in Visual Studio. This is definitely fine by me as a programmer with lots of technical experience and a small project. But I know from my personal experience bigger projects require the use of more data driven solutions. This may involve using scripting in time critical areas of code. Data driven solutions may not only facilitate the programmer, but the designer & the artist.

I'm sorry for being on a soap box. You guys are professionals and know this stuff already. I think I am slowly whittling down my aspirations to more realistic ones. And you guys are helping me. You guys are all really brilliant. Like you guys, I really like Torque and want to provide for the common good.

#120 @Antony

The approach with the T2D lua code was to piggy back onto the existing console function binding system (i.e. the namespace stuff and the field accessor functions). This was in effect a bridge.

This certainly was not without its problems. In current T2D all console functions and property access is done by parsing or printing strings which to say the least isn't optimal or "as friendly" (e.g. no friendly type wrappers in lua land). If you are just using your scripting language to configure objects though it's probably fine. ;)

On the plus side though since my approach reused the namespace stuff it also meant torque was more in control of the object system. Consequently Torquescript still worked so I didn't need to bother rewriting anything else. Also I didn't need to bother with writing a class system in lua. ;)

@Richard

I had a look into supporting variable arguments (from script land) with the DefineEngine* macros. There didn't seem to be any safe way of doing it besides directly exposing the console stack to the functions. :(