A Parameterized Attack on Programming

2018 EDIT: One of those posts you look back on and wonder what you were thinking. I think I know?

I will be frank; I don't like the programming language L. If I could stop people from using it directly I would, forcing them to first formulate their problem in a better language.

Practitioners are subtly but profoundly swayed to take shortcuts with correctness because of a lack of simple or idiomatic expression in L -- after which, of course, they are encouraged to compromise performance for some measure of the correctness gained back. Double-of-course -- correctness is everything!

Truthfully, there is little wrong with L, but more the culture surrounding it. By refusing to use anything but L, a mono-culture forms, and L is forced to handle more and more concept mappings that bring L to the very limits of (and, sometimes, off the charts of) its intended cost/benefit trade-off.

The economic viability of programming has given it a very dense and awe-inspiring history -- but correct language is essential -- all industries are doing what will inevitably be called 'early programming'.

Consider the culture of programming as a whole:

Money drives programming hours in a series of chaotic directions. Man-millenia become spent on redundant interfaces to obsolete versions of redundant programs by obsolete and redundant companies. Those observing these practices identify similar but frustratingly hard to generalize flaws over and over. It is discouragingly hard to incrementally improve something for which your system has no intelligence.

And of course, why bother with thinking about a gradual path of improvement when you face costly ad-hoc reformulation, creeping obsolescence, changing requirements, no market demand, et al staring at you. You can almost feel the boulder rolling back as you reach to push it up the hill. Individuals in these situations sometimes find solace in the delusion that since they are avoiding changes they are avoiding the problem of programming -- only to be pulled back in for one last 'hit' by the winds of change. And this describes our dense landscape of opportunity, where history is not only doomed to repeat itself but to synchronize at many points as industries struggle to solve problems in excitingly identical ways.

And that's precisely what's wrong with the programming language L, and it has almost nothing to do with the programming language L.

When our most fundamental set of tools are thought of, therefore spoken of, therefore implemented as constraints not strictly the minimum of our problem domain, we create (at least slightly) divergent paths of progress. As long as we continue to rely on competing ad-hoc imperative logic models to handle conceptually non-imperative tasks we have literally no hope for normalization (viz Halting Problem).

Only when we leave 'early programming' can the very confused non-software-oriented industries return to business as usual. Producing correct software is a minefield compared to ensuring correct manual labour. Once the designer for even a non-technical discipline can manipulate a set of sufficiently expressive symbols that appeal to their intuition without fear of being forced to reason about arbitrarily-imperative behaviour or any other ad-hoc idiosyncrasies, then we can say we are observing modern programming.

Lanarts, Devblog for Release 13Alpha

I keep wanting to make grand long blogs describing Lanarts development in-depth. That doesn't seem to be working; I'll try shorter blogs.

Lately, there's some exciting stuff happening with Lanarts, and it'd be a shame not to share -- especially because I don't know how long it will take to stabilize all the new features!

Randomly Generated Overworld:

This happened much sooner than I thought! For those of you following, Release 12 introduced an overworld -- however, it was not randomly generated.

I really didn't know how I'd approach the overworld -- connectivity is tricky with non-grid layouts. The approach taken was fairly simple. The algorithm is basically just a bunch of random polygons, and lines connect nearby polygons. I used libxmi to draw the polygons efficiently, and baked it into my map generation library. From there, Lua code controls the map generation, and it it is quite well-performing, even for large maps.

New Stat System:

From a gameplay perspective, this is huge (and criminally overdue). This replaces the previous simplistic stat system (Melee/magic damage types, and resistance/effectiveness/damage/defence for each). Now possible are elemental damage types, bonuses against specific monsters, easily-definable custom status-types, equipment that can grant virtually any ability, etc.

I could probably write a whole blog about the nuances of the stat system, but essentially it was rewritten in clean Lua with many interesting possibilities. The stat system comprises of base stats, and components of these base stats, eg the inventory, result in bonuses to the derived stats. This way eg you can have a spell that is granted only when wielding an item, since it can be added to the derived copy of the stats. This derived copy is computed whenever needed.

Roadmap:Finally, the goals I laid out for Lanarts Release 1.0 have started to take shape. The two issues being tackled by this release plagued me for a long time, and I'm happy to have found elegant solutions to both of them (thanks to the expressiveness of Lua!)

Another, relatively unseen, issue that I have gone a long way to fulfilling is the ad-hoc nature of the Lua API. Recently, a lot of effort has been taken to clean-up and modularize the Lua part of the code. The Lua API continues to become more lower-level and general to take full advantage of Lua's expressiveness.

While development for release 13 is well underway, there is still lots to do. Unfortunately, there is a lot of balancing work ahead with the new stat system, but I have some promising ideas for automating this task.

Feedback:

Please direct any bugs, comments, or inquiries either as a github issue, a comment on this blog, or through IRC or email:

IRC Channel: #lanarts at freenode
Contact Email: domuradical@gmail.com

Feedback very welcome !

Lanarts release 12, now with overworld!

New release, here is the download for Windows!
Source-code for this release: Source

This one was pretty delayed. It's about time I released a version with some of the large recent changes.

READ BEFORE PLAYING:

The game does not provide much instruction (the README is woefully outdated), but your mission currently is to clear the dungeon that has warning skulls near it. You begin near the first of two dungeons.

It is recommended you move with WASD, melee with H, fire spells with YUIOP, mouse controls for everything else. Mouse controls for spells are fairly suboptimal at the moment.

Additionally, 1 to 9 for inventory slots 1 through 9.
Right click is needed to drop items, however.

Screenshots and Changes

Major changes:

• There is now an overworld with multiple dungeons!
• As a result, almost all the areas in the game have been majorly revamped. The red dragon is now on the overworld, a different boss resides in the first dungeon.
• There is now a new logo, courtesy of Kevin Siapno.
• Two new spells - Minor Missile, a mana-conserving Mage spell, and Expedite, an archer spell that causes them to move much faster for a short time. 
• Poison Cloud has been moved from the Mage to the Archer. 
• Magic Blast is now a 3rd-level Mage spell.
• Minimap is much more visible. You can click to adjust zoom level, right click to look around.
• [Code-only] The Lua code has been refactored to be much more modular, and has grown significantly. The area generation code has been rewritten (and improved, in the process) in Lua.

Too many minor changes to list. If curious, you can always check the commit logs.

Special thanks to Matt Simon, Steven Trumble, putterson, and the 2013 Toronto Red Hat interns, for their help testing the game. Thanks as well to Kevin Siapno for the original logo.

Downloads and Discussion

Windows:
Download!

Linux:
Compiling on Linux is very easy!
Download the source here: Source
-or- if you want the very latest updates:
git clone http://github.com/ludamad/lanarts --depth 1

Then from the folder you extracted or cloned to:
./run.sh

This will build and then run the game. If you are missing dependencies on Linux (probably the case) please run either fedora-deps.sh for Fedora, or debian-deps.sh for Debian or Ubuntu.

I do not yet provide linux packages, please do kick me if they'd be useful for you.

Other systems:
The game has been written to be very cross-platform; however it has not yet been tried on Mac or other systems. Anyone willing to help try Lanarts on a different platform is asked graciously to email domuradical@gmail.com.

Feedback:

Please direct any bugs, comments, or inquiries either as a github issue, a comment on this blog, or through IRC or email:

IRC Channel: #lanarts at freenode
Contact Email: domuradical@gmail.com

Feedback very welcome !

A 'fork & exec' surprise

See my gist for a self-contained C++ example of the problem code:
https://gist.github.com/ludamad/5579602

So recently during my work at Red Hat I was looking into an issue with Java on Linux (with IcedTea7+ and Oracle's JDK).

The straight-forward seeming code

FileWriter writer = new FileWriter(someScriptName);
writer.write( ... some contents ...);
writer.close();
giveFileExecPrivileges(someScriptName); // eg, using UnixFilePermissions
Runtime.getRuntime().exec(someScriptName);

This code snippet creates a new text file, sets executable permissions, and then tries to execute it.

This code runs just fine when executed in a single thread. Introduce multiple threads (also running this spawning code) and every-so-often you will get an IOException with the message 'error=26 Text file busy'. This IOException means that Linux is refusing to execute the file because it is open for writing.

However, this is clearly the only place we ever open the file - and we promptly close it. So what's going on ?

An aside about executable text files

On Linux (and originally, UNIX), we can execute a text file by looking up the 'shebang' line, eg at the start of the file:

    #!/bin/bash

This tells the kernel which program to use to execute the file. You get 'text file busy' basically if you try to execute a file that is being written to. Normally this would be a text file (you can get this error with binary files as well, though).

Digging deeper

Unfortunately, you can stare at the Java code endlessly; it won't tell you anything. Luckily, we have OpenJDK. A quick foray into UNIXProcess_md.c shows the native implementation of Java's Runtime#exec method. It is implemented using the system calls 'fork' and 'exec'. (Actually, it uses 'vfork', in OpenJDK7, but it's not important.)

Fork, if you're not familiar, essentially creates a new copy of the process, with enough copy-on-write magic to do it efficiently. Worth noting, this child process gets a copy of all the file descriptors opened by the program.

To spawn the program we actually want, we then use 'exec'. This replaces the current process with the specified executable. However, we continue to inherit whatever file descriptors were already open in the new process.

Don't copy my file descriptors, please

Normal programs will take care that the file descriptors copies are closed upon 'exec'. This prevents unwanted information from leaking. Indeed, this is the case in Java-land, where all open file descriptors are marked with FD_CLOEXEC.

This solves a very important problem -- that file descriptors can leak into the child process. However, this does not prevent the copy from occurring in the first place!

Back to the code

Is this knowledge enough to pose an explanation of what's going on ? In fact, it is.

FileWriter writer = new FileWriter(someScriptName);
writer.write( ... some contents ...);
// Say another thread executes 'Runtime.getRuntime().exec(someOtherScriptName);'
// this forked process will have a copy of the file descriptor we are about to close!
writer.close();
giveFileExecPrivileges(someScriptName); // eg, using UnixFilePermissions
// It is very possible that the forked process has not released the copy here!
Runtime.getRuntime().exec(someScriptName);

Unfortunately, the fork from another thread can copy the file-descriptor, suddenly be set aside to let other threads execute, and the file will remain open!

See my gist for a self contained example: https://gist.github.com/ludamad/5579602

Avoiding problems

So what's the takeaway ? If you're going to fork & exec in a multi-threaded program, you cannot do any operations that require file-descriptors to be closed predictably. This is true even if only one of the threads does the process spawning!

icedtea-web 1.4 Released!

icedtea-web 1.4 is here! Lots of fixes and enhancements in this release. This release also fixes known regressions that occurred from 1.2->1.3.

Release announcement by Jiri Vanek:

Hi all!

After long and furious development, I'm finally proud to announce release of icedtea-web 1.4.

http://icedtea.wildebeest.org/download/source/icedtea-web-1.4.tar.gz
97c1d5f02f9a4ab19812a216f39e401a  icedtea-web-1.4.tar.gz

How we were dealing and what we plan to do, can be  checked on wiki:

http://icedtea.classpath.org/wiki/IcedTea-Web#IcedTea-Web_1.4
http://icedtea.classpath.org/wiki/IcedTea-Web#IcedTea-Web_1.5

New in IcedTea-Web 1.4

* Numerous improvements and enhancements in core and system of classloaders
* Added cs localization
* Added de localization
* Added pl localization
* Splash screen for javaws and plugin
* Better error reporting for plugin via Error-splash-screen
* All IcedTea-Web dialogues are centered to middle of active screen
* Download indicator made compact for more then one jar
* User can select its own JVM via itw-settings and deploy.properties.
* Added extended applets security settings and dialogue
* Security updates
  - CVE-2013-1926, RH916774: Class-loader incorrectly shared for applets with same relative-path.
  - CVE-2013-1927, RH884705: fixed gifar vulnerabilit
  - CVE-2012-3422, RH840592: Potential read from an uninitialized memory location
  - CVE-2012-3423, RH841345: Incorrect handling of not 0-terminated strings
* NetX
  - PR1027: DownloadService is not supported by IcedTea-Web
  - PR725: JNLP applications will prompt for creating desktop shortcuts every time they are run
  - PR1292: Javaws does not resolve versioned jar names with periods correctly
* Plugin
  - PR1106: Buffer overflow in plugin table-
  - PR1166: Embedded JNLP File is not supported in applet tag
  - PR1217: Add command line arguments for plugins
  - PR1189: Icedtea-plugin requires code attribute when using jnlp_href
  - PR1198: JSObject is not passed to javascript correctly
  - PR1260: IcedTea-Web should not rely on GTK
  - PR1157: Applets can hang browser after fatal exception
  - PR580: http://www.horaoficial.cl/ loads improperly
* Common
  - PR1049: Extension jnlp's signed jar with the content of only META-INF/* is considered
  - PR955: regression: SweetHome3D fails to run
  - PR1145: IcedTea-Web can cause ClassCircularityError
  - PR1161: X509VariableTrustManager does not work correctly with OpenJDK7
  - PR822: Applets fail to load if jars have different signers
  - PR1186: System.getProperty("deployment.user.security.trusted.cacerts") is null
  - PR909: The Java applet at http://de.gosupermodel.com/games/wardrobegame.jsp fails
  - PR1299: WebStart doesn't read socket proxy settings from firefox correctly



People who helped with this release (If I forgot somebody, please let me know!):


Deepak Bhole <dbhole@redhat.com>
Danesh Dadachanji <ddadacha@redhat.com>
Adam Domurad <adomurad@redhat.com>
Jana Fabrikova <jfabriko@redhat.co>
Peter Hatina <phatina@redhat.com>
Andrew John Hughes <ahughes@redhat.com>
Matthias Klose <doko@ubuntu.com>
Alexandr Kolouch <skolnag@gmail.com>
Jan Kmetko <jan.kmetko.ml@gmail.com>
Omair Majid <omajid@redhat.com>
Thomas Meyer <thomas@m3y3r.de>
Saad Mohammad <smohammad@redhat.com>
Martin Olsson  <martin@minimum.se>
Pavel Tisnovsky <ptisnov@redhat.com>
Jiri Vanek <jvanek@redhat.com>
Jacob Wisor  <gitne@excite.co.jp>


Special thanks to:

 * Adam Domurad - for deep investigations and  fixes in core, and in numerous classloaders or otherwise complicated bugs
 * Jan Kmetko - for initial design of splashscreen
 * Deepak Bhole and Omair Majid - for ever keeping an watchful eye on patches
 * to community - namely:
   -  Jacob Wisor and Alexandr Kolouch  - who voluntary offered and delivered Pl+De and Cz translation

And not finally to all who tested the pre and final versions for regressions


Best regards
  J.

Happy hacking,
-Adam

icedtea-web 1.2.3, 1.3.2 Released!

Newest incremental releases in 1.2.x & 1.3.x series for icedtea-web were released! Stay tuned for the much-improved icedtea-web 1.4, in about a month.

From the release announcement by Jiri Vanek (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-April/022790.html)

The changes well... are as they are. Not much, but at least something - as development was strongly 
focused to HEAD.
 From this point of view, I strongly encourage every user to move to 1.4 as smoothly and quickly as 
possible (will be based on future head anyway).
Also please note that 1.2 is getting close to end of its life.

http://icedtea.wildebeest.org/download/source/icedtea-web-1.3.2.tar.gz
http://icedtea.wildebeest.org/download/source/icedtea-web-1.2.3.tar.gz

md5sums:
ab56d94251975a9bb5359ea85136ea79  icedtea-web-1.2.3.tar.gz
94ce02c42c1e4d1411357fb3c1014f67  icedtea-web-1.3.2.tar.gz

New in release 1.3.2 (2013-04-17):
* Security Updates
   - CVE-2013-1927, RH884705: fixed gifar vulnerability
   - CVE-2013-1926, RH916774: Class-loader incorrectly shared for applets with same relative-path.
* Common
   - Added new option in itw-settings which allows users to set JVM arguments when plugin is 
initialized.
* NetX
   - PR580: http://www.horaoficial.cl/ loads improperly
* Plugin
    PR1260: IcedTea-Web should not rely on GTK
    PR1157: Applets can hang browser after fatal exception

For details you can see changesets:
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/2d76719a5e4d
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/88fb945c9397
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/25dd7c7ac39c
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/25dd7c7ac39c
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/19f5282f53e8
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/ca8b00cca4c3
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/f63bdf513e9d
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.3/rev/b619cda99360

New in release 1.2.3 (2013-04-17):
* Security Updates
   - CVE-2013-1927, RH884705: fixed gifar vulnerability
   - CVE-2013-1926, RH916774: Class-loader incorrectly shared for applets with same relative-path.
* Common
   - PR1161: X509VariableTrustManager does not work correctly with OpenJDK7
* Plugin
   - PR1157: Applets can hang browser after fatal exception

For details you can see changesets:
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.2/rev/34b6f60ae586
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.2/rev/cb58b31c450e
   * http://icedtea.classpath.org/hg/release/icedtea-web-1.2/rev/cd4a9f25808e

Please consider for next few hours HEAD as frozen (until you see similar commits;)

Thanks to everyone who helped with this releases:
   Deepak Bhole
   Adam Domurad
   Jana Fabrikova
   Tomas Hoger
   Omair Majid
   Jiri Vanek

Direct all bug reports to:
  http://icedtea.classpath.org/bugzilla/
Direct all inquiries/comments/patches to the distro-pkg-dev mailing list:
  http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev

Happy hacking.

Lanarts Goals

So I decided to write up a post about my hopes for when I finally release 'Lanarts 1.0'. I hope outlining where the game is going encourages people to contribute.

The design philosophy:
To create a fun, dangerous, procedurally generated, co-op RPG which allows for continual character advancement without repetitive elements. The game will be very light on plot, and feature critical decisions, such as choosing between different challenges. The game will be best played end-to-end with a team of around 4-6 friends. The game will be designed with a loss-condition in mind, but one that can be made more lenient to players' liking.
 
Guiding points:
Any tedious aspects should be as streamlined and automated as possible.

The character advancement should introduce more interesting and nuanced features rather than just stat-gain. Character races and other game bonuses should be versatile enough to provide benefit to a large number of play-styles.

The game should be as data-driven as possible, allowing for easy content creation. The game should lend easily to hosting modified game content. Modified game content will happily be considered for integration into the base game.

The V1.0 goals:

• Stable Lua API that allows for developing/customizing the game as much as possible. V1.0 will introduce a (loose) API freeze and best-effort backwards compatibility measures.
• Well-performing game-play with at least 4 players (more is ideal).
• A lobby server for easy match-making.
• A flexible stat system based on character traits and abilities. This includes items with interesting effects, and a variety of 'tech-tree' style advancement options.
• An overworld with towns, thematic dungeons, and a final boss.

What aren't my goals:

• I'm not sure if V1.0 will have original graphics. While nice, I do not consider this a version-number assignable goal (primarily because I do not have the talent to decide when it happens.
• I don't intend to make Lanarts a generic RPG engine. I will move towards this as much as possible, but only where it enables smooth growth of the game.

7Day Roguelike Challenge Complete!

OK time to release.
Download: http://7drl.org/wp-content/uploads/2013/03/bughack.zip

I'm a bit exhausted from working on it so I'll just paste the README.

Welcome to BUGHACK.

The idea for the game was to include roguelike mechanics based on how ants find food through scents.

You are a leader ant who must lead worker ants to delicious harvest. Every sector you must gather a certain amount of harvest. Keep your ants safe, or you'll take damage! You must call ants out of an ant hole and then lead them to to fruit.

Press C in-game to see controls.

THE GAME IS TOO SMALL:
To fullscreen, hit F in game.
Alternatively, replace the occurrence tiles12x12_gs_ro.png in bughack.py with tiles18x18_gs_ro.png

Dependencies:
Python 2.X (32 bit is needed on windows)
SDL (included in Windows, needed on Linux)

RUNNING:
python main.py
(Or on windows, right click main.py and run with python 2)

Created by:
 Programming by ludamad (Adam Domurad), art by REZ (Clay Bullard)

7DayRL Competition!

OK, this will look silly in case I don't complete, but I will be joining the 7day roguelike competition!

I will be teaming up with putterson (who does occasional work on lanarts with me) and REZ (who I previously did a Halloween competition with, resulting in Carny Death Peddlers). The hope is to have a tiles-mode with ASCII.

I'll say at this point to save myself from potential foolishness that any potential failing of the competition will be due to being too ambitious with too little free time, and not because of lack of interest!

Anyway, cautiously optimistic.

I'd discuss the game idea but they're going to change a buttload -- and we'll find out soon enough, ain't it ?

So plans are to use libtcod & Python. It won't be my first game in Python but it'll be my first graphical one. So far just learning libtcod and going through the tutorials, but I find it straight-forward. It's funny how well suited libtcod is for this competition.

Lanarts Update March 4th, 2013

New release, ready for download!

It is recommended you move with WASD, melee with H, fire spells with YUIOP, mouse controls for everything else. Mouse controls for spells are fairly suboptimal at the moment.

Additionally, 1 to 9 for inventory slots 1 through 9.
Right click is needed to drop items, however.

So it's been 2 months since I felt like compiling this thing on Windows ... damn. About time for another lanarts release !
I hope sincerely to go back to a biweekly release schedule.

Major changes:

• Enemies now do not regen health a bit after hit. This makes enemy packs a lot less annoying. [Credit for idea goes to serprex]
• Floating point strictness flags turned out to help a lot with the remaining syncing issues.
• Saving the game is much more streamlined -- now you simply need to exit (via shift+escape) and the game will automatically save. Reload the game and hit Continue (or enter), and your game is loaded. I feel comfortable having this the default now since I haven't run into any save-file bugs in a good amount of time.
• Victory screen added, you can win the game now !
• Scoreboard added, with stats for your previous characters, whether you won, etc. Navigate it with arrow keys/pageup&down if you have a lot of entries.

Minor changes:

• Made it easier to distinguish walls and floor in the brick&hive tileset
• A lot more code was brought to the lua side, including the menu implementation. The scripting is becoming quite mature, and the game much more engine-like. Documentation to come !
• Unit tests moved fully to use UnitTest++
• Network debug mode was fixed, logging was made more verbose. Diff'ing logs proved to be very effective rooting out syncing issues.
• Game pausing and the steps_per_draw setting work again.
• Minor balancing to spells
• Added key display overlay for spells, and FPS counter in corner
• Moved the wide-open and difficult floor 4 layout to floor 7
• More options for hosting games, and the server's options now override client options (whereas before they could be weirdly out of sync)

Special thanks to putterson for all the online & LAN testing.

Windows:
Download!

Linux:
I do not yet provide linux packages, please do kick me if they'd be useful for you.

git clone http://github.com/ludamad/lanarts --depth 1
./run.sh

If you are missing dependencies on Linux (probably the case) please run either fedora-deps.sh for Fedora, or debian-deps.sh for Debian or Ubuntu.

Feedback

Please direct any bugs and inqueries either as a github issue, a comment on this blog, a post on the #lanarts freenode channel, or an email to domuradical@gmail.com. Feedback very welcome !

Fedora 18+Cinnamon

So, I had told myself I'd get use to Linux prior to coming to Red Hat, but truthfully that wasn't much needed. You learn fast when you're thrown in, and its sink or swim.

So, Fedora 16 was my first Linux distribution. I liked it a lot. I liked GNOME 3 a lot. With Fedora 16's end-of-life approaching (today, in fact) it was time to jump ship. GNOME 3 was nice enough, but I decided to put some of the noise about it in perspective and try something else.

Installing

Noticeably worse - a bit sad because obviously a lot of work was put into it. The new layout shows you all your options at once, but I think stepping you through them was more user-friendly.  Partitioning was confusing but in the end, it all worked well. Once I figured out I had to click on my F16 install, and hit a 'minus sign', everything went smoothly.

GNOME 3.6 Visuals, Graphical boot loader, etc

This probably impressed me more than it should have, but everything looked really tight to me. The fedora boot loader has a graphical back-drop, the login screen looks really nice, as were the various GNOME3 visual improvements. All of it fit together really nicely. Of course, at the end of the day, I would happily turn off any of these things for a better workflow. It sure is nice when people ask 'Whats this Linux thing?', and you have something shiny to show them.

Bugs

So once I tried to get some real work, I was unhappy to find a lot of small Eclipse issues. While F18 can only be blamed for bugs in Eclipse to a limited extent, it is one of those 'too big to fail' applications these days, so its worth mentioning. Without going into detail, these included issues with Java perspective not showing up after installing Eclipse Java Tools, and various graphical glitches using Eclipse C++ Tools. A more fundamental bug occurred when I tried to turn on desktop icons in GNOME 3.6 - instant crash, and crashing whenever I logged in.

Cinnamon!
The best thing about failing to get icons working on GNOME (admittedly I didn't try hard) was the decision to try out if they worked with Cinnamon. First off, I was very impressed with how well Cinnamon integrated with the whole Fedora user experience. Not only did a single yum command and a 'cinnamon --replace' have me trying it out in seconds flat, it was very simple to make my default desktop environment (toggle on log-in).

For someone like me that found GNOME 3's visually appealing, Cinnamon was perfect. Very soon I got rid of that 'hot corner' that GNOME 3 is so centered on, and set up some settings to my liking. Overall I find it more featureful, perhaps more Windows-like, but I'm not complaining.

Some things I do miss though is the nice way of dragging windows into workspaces with GNOME 3, and the 'application-centric' alt-tab that groups windows based on application.

Anyway, that's it for now. Overall I really like it, but then again I would have just been happy to get up to date packages again. YMMV.

A Lesson from Java's Swing

So whenever possible, I like to apply things I learn in my hobby programming to my professional programming. Conversely though, sometimes I am inspired by the design of parts of icedtea-web (the project I work on at Red Hat). To be fair, this is more the design of Java's Swing library, but it got me thinking.

The menu code in Lanarts was pragmatic but also hackish. It piggy-backed the normal event loop and each menu was a pseudo-level. That meant there was a bunch of classes that inherited from GameInst that were only part of the menu code. The menu code was created based off these objects being planted into the pseudo-level, configured with callbacks to wire the menu logic and drawing, and just enough menu placement logic code so that things were spaced sanely on different resolutions.

Taking a Swing at a better design

Although it wasn't the first time I used Swing, recently while having to assemble a dialogue box with nothing but Swing layout managers, it struck me that this could be a good approach for Lanarts user interfaces. While Swing has a large number of obscure layouts, a comment struck me that I forget the source of: "Using GridLayout and BorderLayout you can create pretty much any interface". So I coded the equivalent of these in Lua. This resulted in two small classes:

1. InstanceLine:

Arranges objects in rows, this is similar to Java's GridLayout, but is designed to be especially convenient if you just want a single row.

2. InstanceBox:

Objects are added based on relative position; a value 0 to 1 is used for x & y coordinates. Using this layout you can easily align something against the center-top of a box, and another component on the center-bottom, for example.

Using these classes nested together, flexible layouts can be created with a lot less mucking around with coordinates. The x & y positions of each menu component are now calculated each time they are drawn, instead of being fixed absolute values. This allows each layout to only store relative positions, making logic simpler. As well components can be created without their locations having to be known at the time of creation.

The GameInst structure was abandoned as well, and instead a simple event loop was created in Lua.

It was really fun to code, and ended up being a large improvement. Here is a picture of the result with debugging code turned on:

Note this looks exactly like it did before -- not bad for a complete reprogramming in Lua!

The elegance with which it could be programmed made me feel a lot more confident in Lanarts ability to act as an effective moddable engine. I was able to code it in Lua with only take very brief breaks to quickly add a missing function or two on the C++ side.

One surprising inspiration I got is to have a similar mechanism for the level generation. A nested tree of randomly generated layouts could produce very interesting results!

Lua & Lanarts

So lately I have been making some significant progress on the Lua side of Lanarts. Here's some summary!

LuaWrap, my pet Lua binder

After much frustration with existing Lua binding solutions (manual bindings, LuaBind, SimpleLuaBinder) I decided like any arrogant programmer to simply write my own. Of course, since I wrote it from the ground up, it suits my use-case quite well.

It is fairly small (24 short source files), flexible, and does not try to control your Lua environment in any way like SLB does. As well, although some performance was traded for ease-of-use, it provides an easy to use interface to eg Lua tables that suffers no performance penalties (assuming sufficient inlining). Here's an example of binding a global variable that should compile to the same code as if written by hand:

void bind_globals(lua_State* L) {
     LuaSpecialValue globals = luawrap::globals(L);

     globals["foo"] = "bar";
     globals["baz"] = 1;
}

LuaWrap is located in the lanarts source-tree under src/luawrap/. It does not depend on any libraries other than Lua.

Rewriting the main loop

So I wanted to move more towards having Lanarts as a game engine controlled by Lua. Now I definitely treat this as the compromise that it is -- it is perfectly possible to write a game in Lua, and that is not the goal. The plan is to allow people to modify the game very flexible in Lua without worrying about the networking aspect (except possibly for very heavy modification). The hope is that will inspire experimentation with the game mechanics.

So, as a start to this direction, I rewrote the main loop in Lua. Here's a look at the inside of the loop!

function main()
    net.sync_message_consume()

    local timer = timer_create()

    if not steponly then
        game.draw()
    end

    if not game.step() then 
        return false 
    end

    if not game.input_handle() then 
        return false 
    end

    local surplus = settings.time_per_step - timer:get_milliseconds()

    if surplus > 0 then 
        game.wait(surplus) 
    end

    return true
end

Object-Oriented Lua!
Figuring I'd continue this top-down approach, I have begun working on porting some of the menu code in Lua. For the first time, this actually meant I wanted to write something object-oriented on the Lua side! Now, OOP isn't a silver bullet, and I always like to weigh the pros & cons of other solutions -- but for graphical interfaces I think object orientation makes a lot of sense.

The first task I had was to decide on an object model. Now I think this is a really cool part of Lua -- it does not impose an object model on you. I settled on a very simple syntax, a single function 'newtype' returns a table suitable for use a 'type'. After which you simply add methods to the type. A special method, the 'init' method, is used to form a 'create' function. Here's what this looks like in action!

import "utils.lua" -- imports 'do_nothing'

TextLabel = newtype()

function TextLabel:init(font, options, text)
    self.font = font
    self.options = options
    self.text = text
end

TextLabel.step = do_nothing

function TextLabel:draw(xy)
    self.font:draw( self.options, xy, self.text )
end

-- Example usage
mylabel = TextLabel.create(font, options, text)

Some things notable here that highlight features of Lua:

1. For people coming from a Python background, 'import' seems like a Lua keyword. Actually, it's a function that is being called with a string literal. Lua allows this syntax for one-argument table & string literal functions.
2. 'function TextLabel:draw(xy)' is equivalent to 'function TextLabel.draw(self, xy)'. The colon operator is nothing more than syntax sugar for 'pass self as first parameter'.
3. Lua silently (for better, or for worse!) ignores extra parameters, allowing a generic 'do_nothing' function like the one used.

 Anyway, that's all for today! Just wanted to give an update as I take a break from gameplay-oriented updates, and the dreaded mess of implementing client-side prediction. Stay tuned.