Tome2: Unlua

[AnonymousHero]

I've just rebased and pushed the complete removal of Lua from ToME 2.x to the "unlua" branch on gitorious.

You might be pleased to learn that I managed to port the Automatizer to plain C. It was a huge pain, but I got it done -- not elegantly, but it should work. To make porting a little easier I added a dependency on "jansson" and changed the automatizer format to JSON. (Jansson seemed much easier to use than the C XML APIs. It's also a very small library and should be pretty portable.) The navigation and display differs slightly from the Lua-based Automatizer -- in particular the XML display mode is gone -- but it should be largely functionally equivalent.

There may be rough edges, but I'm considering the "unlua" branch feature complete, and will probably merge it into 'master' and tag ToME 2.4.0 before too long. Over the next few weeks/months, I'll probably be experimenting with Go/D/C++11 as a target for porting.

All feedback welcomed. Please add bugs reports, comments, etc. to this thread for now please.

[Lord Estraven]

First off: congratulations! And wow. This is an impressive feat (especially to perform on a volunteer basis with limited free time).

Re jansson though - that seems to be of limited availability as a package under Linux. How would I got about statically linking the tome binary against it?

(And how would the use of jansson affect compiling under Windows?)

[AnonymousHero]

Fedora, Ubuntu, Debian and Arch Linux have jansson. Which distribution are you running?

According to jansson's documentation it should compile and run on MinGW.

(I realize that it may be annoying to introduce dependencies, but I'm definitely not going to reimplement JSON/XML handling... badly.)

EDIT: That said... if I end up porting further to a different language, I'll probably use a JSON parser which is written in that language.

[Lord Estraven]

N/M, Debian Squeeze has it in Backports. Though I'm currently using a rather obscure Slackware derivative, so :/

Windows will probably be a pain though. In my experience, making build systems see dependencies on it is very difficult; the OS seems hugely inimical to cross-platform software development.

[MasterShizzle]

What was the rationale behind removing lua? I sense a lot of hate for lua on this board, and I've always preferred working with a C++ engine and lua scripts rather than hard-coded everything. One of my favorite things about T2 versus other variants was the ability to script in things with lua without having to do a new build every time. Is there something about lua that doesn't work well with T2? What am I missing?

[AnonymousHero]

Short answer: The particular mix of Lua and C in ToME was a complete maintenance nightmare -- it was extremely hard to modify anything significant and the Lua interpreter in ToME was a modified fork of some ancient version of Lua -- I have no idea if those modifications were documented anywhere, but it doesn't matter any more.

Without a test suite, dynamically type checked languages are also a bad idea for big projects, IMO. If I were to use a dynamic language it would probably be a Lisp/Scheme (Racket) which have great capabilities for metaprogramming (hygienic macros, etc.) and making your own DSLs.

Lua is also not a very good language in general. It may be easy to embed (but see this), but Batteries Are Not Included. See also this blog post for more technical reasons. (I obviously have my own complaints, but I'd rather not start a long rant...)

(Not that C is my favorite language by a long shot, but it's the lesser of two evils in this case.)

[AnonymousHero]

What was the rationale behind removing lua? I sense a lot of hate for lua on this board, and I've always preferred working with a C++ engine and lua scripts rather than hard-coded everything.

Using C does not mean everything has to be hard-coded -- T2/Unlua still uses all the same edit files, for instance.

In fact, if you look at Theme vs. T2, most of the customizations that matter are in the edit files, not the Lua files. (A few things are in the Lua, for example custom spells, but the variations implemented in those could easily have been accomodated with an "edit files for spells".)

If you want more examples of extreme moddability without scripting take a look at D2:LoD and Median XL.

One of my favorite things about T2 versus other variants was the ability to script in things with lua without having to do a new build every time.

Compile times aren't great, but that's because of the insane way the .h files are "structured" -- everything was just thrown into a single monolithic .h file... which means that even trivial changes which only affect a single module require a recompilation of everything. Also, you probably remember compile times from a few years ago -- computers are a lot faster (and finally something to use those multiple cores on! )

Is there something about lua that doesn't work well with T2? What am I missing?

I hopefully answered this in my other post.

[MasterShizzle]

Short answer: The particular mix of Lua and C in ToME was a complete maintenance nightmare -- it was extremely hard to modify anything significant and the Lua interpreter in ToME was a modified fork of some ancient version of Lua -- I have no idea if those modifications were documented anywhere, but it doesn't matter any more.

Without a test suite, dynamically type checked languages are also a bad idea for big projects, IMO. If I were to use a dynamic language it would probably be a Lisp/Scheme (Racket) which have great capabilities for metaprogramming (hygienic macros, etc.) and making your own DSLs.

Lua is also not a very good language in general. It may be easy to embed (but see this), but Batteries Are Not Included. See also this blog post for more technical reasons. (I obviously have my own complaints, but I'd rather not start a long rant...)

(Not that C is my favorite language by a long shot, but it's the lesser of two evils in this case.)

Using a modded fork of an outdated version of lua would definitely cause problems. I can certainly understand why you'd want to trim it out. While I don't agree with the links you posted (I think Lua is a superior choice for a data-intensive game like ToME, and a great candidate for an entity/component framework), the beauty of the Internet is that anyone's project is their own. Regardless of what I would have done, I'm not the one doing it. So more power to ya! You're definitely a better programmer than I.

Well done on the automatizer, btw. I would hate to see that go, as it's one of my favorite things ToME has that no other Roguelike I've seen will do. Kudos.

[Lord Estraven]

Ran into a compile-time error on 32-bit. A function attempts to format a string with a "%d" in it, but is getting an variable of type s32b for the argument, instead of an int.

Code: Select all

/home/proteus/Games/tome2/src/spells4.c:108:6: error: conflicting types for ‘get_power’
/home/proteus/Games/tome2/src/externs.h:2382:12: note: previous declaration of ‘get_power’ was here
/home/proteus/Games/tome2/src/spells4.c: In function ‘print_spell’:
/home/proteus/Games/tome2/src/spells4.c:523:3: warning: format ‘%3d’ expects type ‘int’, but argument 3 has type ‘s32b’
/home/proteus/Games/tome2/src/spells4.c:533:3: warning: format ‘%3d’ expects type ‘int’, but argument 8 has type ‘s32b’
make[2]: *** [src/CMakeFiles/tome.dir/spells4.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [src/CMakeFiles/tome.dir/all] Error 2
make: *** [all] Error 2

[AnonymousHero]

Fix pushed, thanks.

[Lord Estraven]

You're welcome!

Unfortunately though, linking is failing for me on x86/32:

Code: Select all

/usr/bin/ld: cannot find -llua
collect2: ld returned 1 exit status
make[2]: *** [src/tome] Error 1
make[1]: *** [src/CMakeFiles/tome.dir/all] Error 2
make: *** [all] Error 2

I'm not quite sure I understand this. Even if Lua hasn't been removed entirely, doesn't T2 use its own Lua interpreter, not the system library?

[AnonymousHero]

Ha! It's not easy to get rid of, is it?

Yeah, I accidentally left the "lua" library reference in the CMakeFiles.txt because I, apparently, have Lua installed on my system via package manager.

Should be fixed in 721d727.

[Lord Estraven]

Yup it works now! Compiles and runs flawlessly.

(Compiles a good deal faster than the C++ version, I might add.)

[AnonymousHero]

Merged to master -- will become 2.4.x series.

[Lord Estraven]

Bah, spoke too soon about it running flawlessly. ToME runs fine, but Theme causes the game to exit immediately - no stack trace, no command line output. GDB says it "exited normally." Maybe some function is returning prematurely? No idea really.