Library Building

[S Ferguson]

No it isn't what you think. I was wondering if anyone has built a general LUA library, or know of any compatible libraries dealing with the "string" or "list" set of objects. I think it would be beneficial to programmers, as the code readability improves (as long as you are familiar with the i/o of the library functions). much used code, such as lexers or other functional routines could be separated into logical categories and can be made part of the language (the benefits of LUA).

Any help would be much appreciated.

[Moon Wizard]

I'd be interested in what you find for LUA string and list libraries. Currently, I implemented a StringManager package in the 3.5E and 4E rulesets to provide string functions general to rulesets. I've thought about building in some common string functions to enhance the default LUA string library (i.e. trim), but I only had a couple functions that made sense that weren't already in the string library.

Cheers,
JPG

[S Ferguson]

Actually I've found a MIT Licensed library called PL. the string and list manipulation routines are fairly robust. The code encourages readability too. You can take a look.


.

[S Ferguson]

Oh, and it provides other useful functions, I've found, but I don't know enough about low level Lua code in FG to translate them it is written for 5.1 but has a 5.2 "update," and usually the code relies on other parts that it requires. the String and List functions I believe you could easily remove.

[S Ferguson]

I'm finding that without the _G and metatables, that some code (in what little examples of Lua code I could find) which would allow in string parsing, and more terse code is difficult like a mapping over a string variable. I don't know how this was built up - amazing coding.

It would be nice though, if there were a developer's library in which a fair amount of the code were rewritten functionally to increase readability and stability in a user's code. That and so you don't break anything coding a simple window. Or a complex window could be added in a more 'intuitive" manner.

Mabye a higher level scripting language is in order? ;)

[phantomwhale]

Lua was a brand new language for me, and I perhaps haven't grappled with the nuts and bolts of it enough to realise what I'm missing out on - certainly I've developed more and more clever tricks in my coding of Savage Worlds ruleset (and hope there are plenty of great examples of code there - if not in the 4E ruleset which comes with FGII).

But I guess I'm not sure what tricks I'm missing without metaprogramming here (other than when I tried to write an OO card deck, and ended up with a pseudo OO card deck of sorts when I couldn't follow the examples I found online). Perhaps an example or two might enlighten me ? Not sure if it's feasible to add these things back into FGII - that's more a question for moon_wizard!

[S Ferguson]

The metatemplates would allow you you far more flexibility, basically bring "macros" into the language. But like you said there is some pretty slick tricks in the 4e set. It's just that if you've programmed in "pure" Lua, you can pull even slicker tricks, for a language of just 500 some lines of code.

[S Ferguson]

Just out of curiosity, does anyone know why the metatable, and _G functions were left out of FG's Lua base?

[Moon Wizard]

The Lua in FG is deliberately sandboxed and limited, in order to prevent malicious actions. Many packages and meta functions are disabled to prevent people from loading and using packages which can access the user's OS in any way.

Regards,
JPG

[S Ferguson]

O.K. Thanks for the response. I think if you disable the i/o routines, but leave in the metatable functions, can they cause any harm outside the sandbox?

[Moon Wizard]

I'm not comfortable at this point enabling meta table functions, since I'm not familiar enough with any potential security issues. It would require quite a bit of research, code review and reflection. I'd rather spend the time writing new features, to be honest. ;)

Regards,
JPG

[S Ferguson]

I don't blame you. I'd rather be playing than writing code. ;)

[S Ferguson]

Incidently, what made you choose Lua as a scripting language? The size and speed?

Not that I'm complaining, but you would think a more procedural language would be more intuitive to users (most having a background in at least one) for programming purposes. Even functional languages, like LISP or Scheme (heck, even Smalltalk) are equally as fast and are far more flexible and proven to be secure - just look at AutoLISP and Autocad.

Just curious from a design point of view.

Thanks in advance.

[Moon Wizard]

Actually, Lua was chosen long before I got my hands on the code. However, I think it was a decent choice. Lots of game platforms use Lua for scripting/macro interfaces. I've done similar projects with JavaScript, and they were much more prone to errors.

Regards,
JPG

[S Ferguson]

Mmmmm. But in most game platforms in which it's used, it's usually called through the C++ or C interface. I downloaded Lua 5.14 (the version that FG uses) and had to admit that it was a pretty lean contraption *if* the scripts accessed C++ functionality. I had no problem compiling the interpreter and attaching and scripting Lua in a C++ project.

The choice was probably based on speed and the fact it handles data efficiently. It's no Python (the "other" choice de jour). But I suppose it does the job. It's just the lack of a solid code base out there that one needs to build libraries of code. After all it is OOPS capable.

Heck, I suppose I'll get used to it. If only there was a central repository for FG Lua libraries. ;)