The end product of a few days of hacking together code: an interactive Lua terminal, in the browser, via AJAX magic.

The javascript side was lovingly ripped from the TryRuby site (as it is conveniently BSD licensed). The server side is implemented using Apache, mod_lua, a custom "persistent Lua" C module and some Lua scripts.

Feel free to try it out, but remember that it is currently very crude and at the technical proof of concept stage, rather than nice user friendly stage.

mod_lua (what was mod_wombat, and is part of Apache core since version 2.3) is something which I'd quite like to work with for Google Summer of Code 2009. In order to work on it, you first need to be able to compile and run it. Doing this on linux is trivial - checkout the svn head of httpd, ./configure (with appropriate command line arguments), make and then sudo make install. Doing so on Windows is less trivial, but it can be done.

For my Windows setup, I've got a standard binary distribution of win32 Apache 2.2.9 (complete with development include and library files) running on Vista. This makes things slightly more interesting, as mod_lua targets Apache 2.3 and above, but I can't find win32 binary distributions of 2.3, nor do I feel confident in compiling it under windows. From this baseline, I did the following:

1. Checkout the mod_lua svn trunk (using TortoiseSVN)
2. Create a new Visual Studio project and add all of the mod_lua source files
3. Add additional include directories ("E:\CPP\lua-5.1.4\src";"C:\Program Files\Apache Software Foundation\Apache2.2\include")
4. Add LUA_DECLARE_EXPORT to the preprocessor definitions
5. Add additional library directories ("C:\Program Files\Apache Software Foundation\Apache2.2\lib";"E:\CPP\lua-5.1.4\Debug")
6. Add lua5.1.lib, libapr-1.lib, libaprutil-1.lib and libhttpd.lib to the library list
7. Add a post-build event to copy the resultant DLL to the modules folder (cp "$(OutDir)\$(ProjectName).dll" "C:\Program Files\Apache Software Foundation\Apache2.2\modules\mod_lua.so")
8. Fix the usage of AP_DECLARE and AP_DECLARE_LUA throughout the codebase (patch available on the httpd-dev mailing list)
9. Copy the ap_args_to_table and ap_body_to_table functions over from Apache 2.3's util_script.c into a new file, util_script_ap23.c. This is compilcated due to ap_body_to_table's usage of the request_req::body_table field, which is not present in the 2.2 version - but can be worked around via usage of apr_pool_userdata_[sg]et with the request's pool.
10. Compile the project and tweak httpd.conf as required to load and configure the module

(for comparison, similar info screenshot on the linux build)

So, time for the daily development screenshot:

I use hex editors a lot. In particular, I use XVI32 a lot. While it's a very nice hex editor, I feel that some extra functionality in many areas would be very nice. For example:

• Ability to open 'massive' (i.e. between 4 and 100 GB) files (XVI32 is limited to 2GB)
• Faster loading of 'large' (i.e. between 100 MB and 4 GB) files
• Plugin system to extend the editor in various parts
• 'Data transformation' system to facilitate data [de]compression and [de|en]cryption within the editor
• 'Structure analysis' system to facilitate viewing the structure of a known formats (e.g. Relic Chunky files) - extended to new formats using the plugin system
• More options for the data inspector (i.e. "byte: 0xf4, x86 instruction: hlt") - again, extended via aforementioned plugins
• More built-in checksums (XVI32 only calculates CRC16 and CRC32)
• 'Data visualisation' system to facilitate viewing plaintext or image data in a suitable manner

As such, I'm writing my own hex editor, HexEditIX, the first development screenshot of which is shown below. (of course, it's not much of an editor yet, but that's software development for you - you have to start somewhere)

First of all, if you're not aware of DoW2DB, it's my latest website - a database of information about the units in Dawn of War II.

One of the reasons for making the site was to see how well Google AdSense (online adverts provided by Google) works. Despite applying for AdSense 3 weeks ago, I've only just been able to put up ads on DoW2DB.

1. February 14th: Applied for AdSense. Application page stated that it should take a day or two to review the application, help pages state it may take up to one week if they are busy.
2. February 26th (almost 2 weeks later): Got email reply stating that the application was refused due to an invalid or incorrect postal address. This confused me, as the address in my application matched exactly the address on my bank statement. Hence I sent an email to AdSense support with a scan of a bank statement with address on attached, and queried why they decided that my address was invalid. Got an automated reply "We noticed that you may have contacted us without first visiting our Help Center: ... To receive faster responses to your questions, we encourage you to visit our help resources -- they're full of instant, reliable answers to many common questions and issues ...". The Help Center does not contain any entries on Google deciding that postal addresses are incorrect when they are not.
3. March 5th (one week later): Still no human response from AdSense support. Decided to re-apply to AdSense without making any changes to the application. Application page stated that it should take a day or two to review the application.
4. March 7th (two days later): Application approved.

I'm intrigued as to why it took Google much longer than their stated two days, and almost double their busy period stated week. I'm further intrigued as to why they decided that my address was incorrect, why there was no useful response from their support email address within a week, and why they then decided that everything was good when I hadn't changed anything.

Anyway, there are now ads up on DoW2DB, and I'm interested in seeing what happens as a result.