A few weeks back, I described an XML Parser Generator that I was working on. At the time, it could generate the parser it used itself. Now, it’s got Objective-C support and Lisp support. (The Lisp support is slightly better than the Objective-C support right now. With the Objective-C backend, you can create arrays of structs, but not arrays of strings or integers.)
Here is the Parser Generator home page.
Roto Mortar was written for the 2010 LISP Game Design Challenge. The challenge was to design and implement a game in seven days using some LISP dialect.
The KPs have been beating on your base all week. Your defenses are just about to collapse. In fact, your mortar cannons are both on the fritz. Billy Bob, the ACME Repair Guy, has just gotten one of your mortar cannons back online. Unfortunately, he had to wire things a little wonky. Your cannon is spinning all on its own. Youâve only got one button to control both the elevation of the cannon and when to fire it. And, you better fire it, because the KPs are still coming at you.
A few years ago, I read the book Game Design Workshop: Designing, Prototyping, and Playtesting Games. One of the exercises in the first chapter is to design a game with a “one-button interface”. At the time, I didn’t come up with anything particularly thrilling.
When I started brainstorming what to do for this Game Challenge, I remembered that exercise. I came up with this concept just under (as in 3.5 hours under) seven days ago. The game is nowhere near as polished as I’d like… but it was a 7-day thing. And, it was fun to take a break from Objective C to get back to some Lisp programming.
You can find out more about the game, including where to get the source and a Mac OS X binary, on the game’s web page.
A few years back (for a very generous few
), we needed to parse a wide variety of XML strings. It was quite tedious to go from the XML to the native-language representations of the data (even from a DOM version). Furthermore, we needed to parse this XML both in Java and in C++.
I wrote (in Java) an XML parser generator that took an XML description of how you’d like the native-language data structures to look and where in the XML it could find the values for those data structures. The Java code-base for this was ugly, ugly, ugly. I tried several times to clean it up into something publishable. I tried to clean it up several times so that it could actually generate the parser it used to read the XML description file. Alas, the meta-ness, combined with the clunky Java code, kept me from completing the circle.
Fast forward to last week. Suddenly, I have a reason to parse a wide variety of XML strings in Objective C. I certainly didn’t want to pull out the Java parser generator and try to beat it into generating Objective C, too. That’s fortunate, too, because I cannot find any of the copies (in various states of repair) that once lurked in ~/src
.
What’s a man to do? Write it in Lisp, of course.
Here’s an example to show how it works. Let’s take some simple XML that lists food items on a menu:
We craft an XML description of how to go from the XML into a native representation:
Now, you run the parser generator on the above input file:
This generates two files for you: types.lisp
and reader.lisp
. This is what types.lisp
looks like:
I will not bore you with all of reader.lisp
as it’s 134 lines of code you never had to write. The only part you need to worry about is the parse
function which takes a stream for or pathname to the XML and returns an instance of the menu
class. Here is a small snippet though:
I currently have the parser generator generating its own parser (five times fast). I still have a little bit more that I’d like to add to include assertions for things like the minimum number of elements in an array or the minimum value of an integer. I also have a few kinks to work out so that you can return some type other than an instance of a class for cases like this where the menu
class just wraps one item.
My next step though is to get it generating Objective C parsers.
Somewhere in there, I’ll post this to a public git repository.
Last month, I posted some code for rendering text under CL-OpenGL with ZPB-TTF. Toward the very end of that post, I said:
Technically, that check with the squared distance from the calculated midpoint to the segment midpoint shouldnât just compare against the number one. It should be dynamic based on the current OpenGL transformation. I should project the origin and the points and through the current OpenGL projections, then use the reciprocal of the maximum distance those projected points are from the projected origin in place of the one. Right now, I am probably rendering many vertexes inside each screen pixel.
It was pretty obvious that when you tried to render something very small, it looked quite jaggy and much more solid than you would expect.
Here is the new code:
The squared distance
check that I mentioned now employs a cutoff value:
I have tweaked the (render-string …) and (render-glyph …) accordingly to propagate that value down to the interpolate function, and I have added a method to calculate the appropriate cutoff value.
The appropriate cutoff value depends upon the font, the desired rendering size in viewport coordinates, and the current OpenGL transformations. The basic idea is that I prepare the OpenGL transformation the same way that I will later do for rendering the font; I will reverse-project 
I started building an application on top my Sheeple/CL-OpenGL library Woolly.
I coach a volleyball team. I often sit down with a piece of paper and try to determine new serve-receive and defensive positions for my team. This is quite tedious because I can’t just move the players around on the page. Additionall, I have to figure this out for all six rotations while keeping the overlap requirements in mind the whole time.
I tried once doing it with cut-out players. This worked better, but still suffered from having to track the rotations and overlap requirements all myself.
After adding checkboxes to Woolly, I had a usable application for doing these rotations in 300 lines of code. Yellow are front-row players, blue are back-row players, and green are sidelined players. It still needs some work so that I can change player identifiers, substitute players in off the bench, save/load the rotations, and make print-outs.
I’m not sure yet whether I’m going to print just by slurping the OpenGL buffer into ZPNG, or if I am going to make a separate callback hierarchy for printing with Vecto or CL-PDF so that I can print at higher than screen resolution.
I’m also having trouble getting SBCL’s save-lisp-and-die function happy with the whole CL-OpenGL setup under MacOSX. I thought I had figured this out before. Alas, my own hacked version of CL-OpenGL isn’t working any better for me than the current CL-OpenGL release is when I try to run the saved image. *shrug* I’ll fight with that later.