"The Moon Won't Shine"

"...It's broken down" to use Eric Clapton's words.

Lua. Enemy of mine. I love the language, don't get me wrong. But I spent oh so many nights on my Lua VM that now I burst into tears every time I glance at the project file in Windows Explorer.

First and foremost, while I believe Lua source code is highly optimized C, it kinda looks obfuscated. It gets quite hard to understand what's going on, so hard that I haven't managed to understand how function calls work. And this makes me very sad, angry, people hate me, and I hate the world. There's a lot of pointer mumbo-jumbo to maximize speed.

Calls are pushed on a "call stack". They seem to contain stack top and stack base information. However, a lua thread has a notion of stack top too. You'd think the current call info on the call stack has all the info you need in order to push values at the right index; but no, there are about two stack tops, and the macro hell makes everything even more difficult to understand.
This is more a practical problem, rather than an issue with the language itself.

Something more interesting would be discussing about the possibility of porting Lua on the CLI. I bet as soon as .NET 4.0 will be out, there will be a plethora of language implementations on the DLR.

Anyway. Lua is a strange beast, strange in the sense that Lua values just can't map to POC objects. This means that you have to implement proxy objects that wrap the same semantics of a Lua value. Not good. Quite bothersome. Prone to run slow - slower than the original C implementation, and especially so in a VM that would decode bytecode on the fly. I have faith in IDynamicObject of the 4.0 FCL.

Practical doubt: what if the Compact Framework got runtime code generation as well? All my efforts in creating a Lua VM would become useless. And right now, seeing as I can't unravel the mysteries of the Lua implementation, I'm not even enjoying the effort in making one. Yes, I have a better picture of how Lua works, but no, I don't have a full, clear picture.

Annoying.

As usual, if you don't know what you're going to code in advance, things are bound to become a mess. I thought I nailed function calls, as the output of a few test scripts would yield exactly the same results of the original Lua VM - however, things got crazy when I had to implement protected calls and coroutines. And vararg parameters. Not enough analysis, and that's the result.

For the record, it is just wrong in my opinion to use VES exceptions (oh, fancy details) to change the program flow of a Lua script (which in turn calls plain old CLI methods). The implementations I've seen just do that, seeing as the original C code uses setjmp, longjmp facilities, or C++ exceptions if #DEFINEd to do so; and it becomes hard to model Lua errors in a different way. However, I think it is possible to avoid using Exceptions (costly) with a not-so-nice set of flags that should be checked in strategic places. This might produce code that is not as readable, but it's bound to perform better. In this case, I think it might be worth to sacrifice readability - yes, purists will cry and all.

I've also discovered F#. I have too many things to do, and since work has highest priority (go live closer and closer), chances of getting any of my personal projects done gets slimmer and slimmer with time.

F# is very cool. But damn it, functional programming seems to require some kind of CS education, which I do not have.

Another challenge. Yeah.

That's about it, thanks for reading.

Nerd joke I came up with while talking with a friend some time ago:
"You don't have to kill me; just set me to null, the garbage collector will take care of the rest". I thought it was fun. :P

Of Virtual Machines

Hello my dear readers, I have been away too long.

I wanted to give a little visibility to my latest efforts: a Lua Virtual Machine. Yes, you got it right, a Lua Virtual Machine! Bytecode in, execution out! This also means that as soon as the bytecode format changes (and it can happen anytime at discretion of the creators of Lua) everything breaks.

Needless to say its based on the works of Fabio Mascarenhas (Lua2IL) and Kein-Hong Man (A No-Frills introduction to Lua 5.1 VM Instructions).

I really love Lua, I think it's a wonderful language. Not perfect, but it features metamethods and if it's something with "meta-" built-in, it must be cool (once they were called tag methods, as you can glimpse from the source). Jokes aside, metamethods seem to offer this nice extensibility and hooks to language events (indexing, new index creation, various operators, to name a few) that make every change a little microcosm of new features.

Back on topic, this Lua VM is meant to run on non-DLR-ready frameworks, such as the .NET Compact Framework. You might argue that System.Reflection.Emit comes before the DLR, but the latter is the future (had too much of IL emit at once in the past) and I like to look ahead.

I know there have been many wise guys at work on Lua implementations on the CLR, but I took up this challenge mainly for fun and not for fame. If it turns out to be complete enough for regular usage, even better. There's a lot to learn from the learning itself.

You can find the work-in-progress source at the Rainweaver Framework Codeplex page. I make a lot of changes all the time, but the core library should be stable enough to use.

I tried to use Irony to create a Lua AST generator but it looks I'm not smart enough, and I had to fall back to other solutions for the moment. It was cool to find out about monadic parser combinators (LukeH's weblog and Brian's weblog) - read them up because they will make you super smart and taint with functional sexyness your imperative ego. As soon as I manage to play with those concepts a bit, I'll be sure to post more.

Waiting for feedback as usual,
Yours truly,
Rob

Work, work, work

I know you've been missing me. I've been missing you too - blog of mine.

Anyway, it's been a super busy period with super big things to get done. For instance, I wrote a Dynamics NAV text fob parser in order to create a versioning documentation against two databases. It's been both a pain and a pleasure. I had a few "eureka!" moments worth all the stress I went through in order to deliver the tool in a timely manner. I also managed to understand parsing / compiler theory a bit more. You never stop learning.

I also took the opportunity to brush up my design patterns knowledge. I've been messing with MVC and today I've been reading up about MVP - the former being model-view-controller and the latter model-view-presenter. Curious? I'll post a pretty scheme I made tomorrow. It's pretty, I swear. Edit: and here it is:


I learned some new tricks in these months, and I got to the point where you have to actually sit down and try to make everything snap in place.

• MVP? World editor. Absolutely.
• Object persistence? Game server. Finally I realized the true form of the Entity System (more on this later).
• System.Threading? Do more with less. Locality of data - as few shared states as possible, lockless when you can, otherwise don't bother.
  
• System.AddIn? Useless, use the MEF and do yourself a favour; however, you learned that proxies and abstractions are a good thing to decouple the contract from the implementation - and if you're smart (like the System.AddIn guys) you have a version tolerant framework without even breaking a sweat. And here comes a platform-independent engine API...!

Thanks for reading.

Designing a Magic System

I just found out this amazing series thanks to gamedev.net dailies.

Designing a Magic System by Andrew Doull

(Plus a fine article from Craig Perko - found in the series above)

Seeing how magic and its systems have gotten a formal definition over time is both entertaining and enlightening. I used to design a pen and paper RPG rules for fun when I was in my teens. The act of balancing, adding to or removing from a specific rule set is not as straightforward as it might seem. Actually, while I'm all for coming up with cool ideas about magic and so on, I must admit players (including me) are used to defined schemes. So, I guess, we're not just balancing fireballs versus shields, but also marketability versus innovation.

And makes me wonder if we will eventually get used to "common" magic...