Archive for the ‘Uncategorized’ Category
Fun with Fibonacci
Or, how to annihilate an interview question. I was asked this a little over a year ago in an interview, and I’d been asked it a few times before then too; it’s pretty common.
“Write a function that takes a parameter n and returns the nth Fibonacci number.” The Fibonacci sequence, if you don’t already know, is defined like this: f(1) and f(2) are both 1. After that, each number in the sequence is the sum of the previous two, so, f(3) is 2 (because 1+1), then f(4) is 3, then f(5) is 5, and so on.
Making a toy programming language in Lua, part 4
This is part four of my series on writing a toy programming language using LPeg. You should start with part one here.
Last time, we used the new AST generation to make conditionals and loops. Now, we’re going to add the ability to define functions, complete with lexical scoping.
Making a toy programming language in Lua, part 3
This is part three of my series on writing a toy programming language using LPeg. You should start with part one here.
Last time, we added variables and arrays to the language. Assigning to arrays was starting to strain our design some, so this time we’ll refactor it a lot, and add two features that would be impossible without that refactoring: conditional statements and loops.
Making a toy programming language in Lua, part 2
This is part two of my series on writing a toy programming language using LPeg. You should first read part one here.
Last time, we made an interpreter for a simple calculator: it would read in mathematical expressions and evaluate them, printing the result. This time, we’re going to add two new features: variables and arrays. First though, we’ll refactor our parser some.
Read the rest of this entry »
Making a toy programming language in Lua, part 1
In this post, and the following posts in this series, I aim to fix something that’s bothered me for a while: writing a parser in Lua isn’t very approachable. In C you have the excellent chapter in The Unix Programming Environment (probably the best book on programming ever written) about how to use Lex and Yacc. For Ruby there’s the excellent Dhaka gem, as well as Racc, both of which work a lot like Yacc / Bison. There’s also Antlr, which seems to speak to every language except Lua.
Meanwhile Lua has LPeg, which is used nothing like Yacc, and tutorials are thin on the ground. So, I want to change that. This is going to be about how to make a toy programming language in Lua, in three parts. I’m going to loosely follow what the Lex / Yacc chapters of The Unix Programming Environment do, and we’ll end up with the same language.
Let’s begin.
Read the rest of this entry »
My Lua init file
I don’t think it’ll surprise anyone when I say that I think Lua is a great language. But, it does have a very small standard library. So, there are a few other utilities that I end up including or writing in almost everything I do. Luckily, Lua has a facility for loading them automatically when I open up the REPL.
Read the rest of this entry »
Iterators
Lua doesn’t have a lot of control structures. There’s the obvious if
statement, the while
loop and repeat
/until
loop, and the for
loop. Mostly, the for
gets used to iterate over tables:
t = {'a','b','c','d','e'} for i, v in ipairs(t) do print(i,t) end
It’s annoying to have to remember to type ipairs
every time. I’ve forgotten more than once. But, that minor annoyance is a good trade for the benefit of what the for
statement actually does: generic iteration.
Read the rest of this entry »
Telegrams
A few days ago at work, a friend of mine came up with this problem. I call it the “telegram” problem: you get a string consisting of words run together without spaces, and figure out where spaces can go to separate out the words. For example, a famous misunderstanding:
parse_telegram("turkeytrotstowaterwhereistaskforcethirtyfourtheworldwonders") -- turkey trots to water where is task force thirty four the world wonders
I wrote a solution last night.
Pushing crates
Player movement is really hard to get right. It seems like it wouldn’t be, like it’s just as simple as “if the left arrow key is down, move to the left”, but it’s actually surprisingly difficult. Feel is really important. Try playing Mario 2: each character plays the same levels with the same enemies and the same rules, but because they have their movement tweaked differently they play totally differently. Luigi can jump the farthest but has a lot of inertia for changing direction mid-jump, for example. It’s something you can tweak indefinitely.
In this post, and probably the next one, I’m going to walk through one way to do it for a top-down (Zelda-like) game in Löve, that feels “right” to me. This isn’t going to touch on code organization at all, or how to start using Löve (there are other posts about that already), it’s just going to be an explanation of what I have figured out over the past couple weeks of poking at this. So, let’s start with some basics:
Points
I’ve been doing a lot of writing games in Löve. Writing games usually involves a lot of code that deals with positions and directions and velocities. To make this easier to write, I made a little library to represent a point in a two-dimensional coordinate space.
This is a little different for posts here because I’m not going to go into the code too much; I’m just going to show some examples of how to use it. Really, the motivation here is that I want to make other posts with code examples that use this, and so I should document it. Next up, my “map” class.
If you just want the code, the canonical repository is here.