• ## An alternative way to Memoize in Ruby

I was screwing around with Ruby Coroutines, and the concept of coroutines in general, when I came across this page. It talks about how you can use coroutines to memoize functions. Ruby has native coroutines. You can guess what happened next.

Here’s what I came up with:

class Object
def self.fiber_memoize(method_name)
meth = self.instance_method(method_name)
self.send(:define_method, method_name) do
f = Fiber.new do |s|
result = meth.bind(self).call
loop do
Fiber.yield(result)
end
end
self.send(:define_singleton_method, method_name) do
f.resume
end
f.resume
end
end
end


This works on an instance-level, which a niave implementation wouldn’t. It also works by re-defining methods on a per-instance basis when you call them, which is just another example of how much Ruby rocks.

Here’s how to use it:

class Factorial
def initialize(num)
@num = num
end

def result
puts "This run is not memoized"
(1..@num).inject(:*) || 1
end

fiber_memoize :result
end

f = Factorial.new(100)
puts f.result #=> Prints the not memoized message, then the result
puts f.result #=> Prints the (now memoized) result


Interesting, this is also a way to do memoization in ruby without any conditionals, which is pretty neat.

Please never use this in any kind of production environment. I’m begging you.

• ## Some thoughts on Ruby

I’m a well-known Ruby fanboy among my circle of friends. Even people who aren’t into programming will occasionally make a comment about it, which I think is an indication that I talk about how great the language is too often.

In truth, it’s not surprising that people might know this about me. I really, really like Ruby. I don’t think it’s perfect for all tasks—hell, I think it’s downright terrible in some contexts—but I do think it is a fantastic language, and it’s probably my favorite to write. This blog post is going to serve as a bit of a high-level introduction to Ruby as a language, as well as a justification for my fanboy-ism.

• ## Writing and Artwork

As I mentioned in my previous post, I’ve been spending the past few months working on a novel. Along the way I’ve hit the general bumps and roadblocks: outline issues, stress about characterization, plot reworks, and so on. Still, I think I’ve been at least mildly productive. Recently, especially, I feel like I’ve hit a flow. I can sit down, and with a relatively small amount of effort, I can get into the story and set to work on expanding it. It’s not perfect, or particularly easy, but it’s productive.

Writing a novel while working on ImageHex has been a sort of strange experience. Not necessarily because the act of coding and the act of writing are dissimilar—indeed, I’ve always maintained that the opposite was true, and that programming is a lot closer to fiction writing than most people would expect. Instead, it has been strange because of the two types of art I must focus on: visual art, such as drawing or painting, and writing.

When I work on ImageHex I need to think about the experience of an artist. I need to think about what problems an artist may have and what the solutions to those problems can be. I’ve actually sent messages to a few artists requesting a bit of help on that front, and I’ve been very grateful for the responses I’ve received.

When working on the novel, however, I am living the experiences of a writer. An amateur writer, sure, and somebody who is likely to never get anywhere with their writing, but still a writer in the technical sense of the word.

Writing and artwork have a strange, intertwined relationship: similar in some ways, vastly different in others. My current life has given me a lot of time to think about these differences.

• ## Undertale

I’m writing this blog post at midnight. As I write it, I am getting over a cold. I need to sleep, not only because I need to beat my sickness, but also because I have a midterm on Tuesday, and I need my sleep schedule to be in whack for it.

Yet, as I lay awake, staring at my ceiling, I can’t fall asleep. And, stupid as it is, the reason for my wakefulness is (partially) a stupid indie RPG made by a dog.

• ## mruby, C++, and Template Magic

For the past few days I’ve been trying my hand at making a simple 2D game engine. It’s a challenge that involves math and programming, two subjects I greatly enjoy.

I decided early on that I would use Ruby as the engine’s scripting language. Ruby’s pretty much my favorite language, and its ability to create DSLs seems like it would be highly useful in enabling users of the engine to be productive. The normal ruby interpreter, of course, isn’t well suited to embedding—it’s way too big and heavy. Thankfully, there’s another implementation called mruby, which is designed to be used in more resource-constrained contexts. That matches my use case pretty well, so I set it up.

Now, I needed some way to bind ruby methods to my native code. Ideally, I’d be able to expose C++ classes and their associated methods to ruby natively. I found a library called mrubybind that seemed to do what I wanted, but I soon found it had limitations. The biggest limitation was how it handled parameter types. With mrubybind, your methods can take ints, booleans, strings, floats, and void pointers. That didn’t sit well with me. void * is a horribly unsafe construct. It has its uses, of course, but I’d rather have something with a bit more type information.

It soon became clear that I would need to bite the bullet and write my own library. Hopefully, I could make use of C++ templates to design something with an interface that isn’t too terrible.