Recently, I gave the very elegant board game “Sim Serim” away as a present, without actually playing it, leaving me curious about the game. One can easily play it on paper (you just need a paper, and 4 tokens like coins for each player, BoardGameGeek has English rules the of game), but I took this as an opportunity to learn more about HTML5 canvas and nodejs, and so I created the browser game “Sum Serum”, implementing the game mechanics of “Sim Serim”. You can play it locally with two people, or over the network. Contributions are welcome! Especially slicker graphics...
In other news, given that in recent years I became one, I’m on BoardGameGeek myself now, see my profile there.
To install, just point Eclipse to the update site: http://eclipsefp.sf.net/updates.
I expect that the next version will be a 2.6 with more features, as hopefully I'll have more free time.
Happy Haskell Hacking!
Haskellers may or not be aware that there are two libraries in the GHC sources for implementing the Integer data type.
The first, integer-gmp links to the GNU Multiple Precision Arithmetic Library which is licensed under the GNU LGPL. On most systems, libgmp is dynamically linked and all is fine. However, if you want to create statically linked binaries from Haskell source code you end up with your executable statically linking libgmp which means your binary needs to be under an LGPL compatible license if you want to release it. This is especially a problem on iOS which doesn't allow dynamic linking anyway.
The second Integer implementation is integer-simple which is implemented purely in Haskell (using a number of GHC extension) and is BSD licensed.
So why doesn't everyone just the the BSD licensed one? Well, integer-simple has a reputation for being slow. Even more intriguingly, I seem to remember Duncan Coutts telling me a couple of years ago that integer-simple was a little faster than integer-gmp when the Integer was small enough to fit in a single machine Word, but much slower when that was not the case. At the time I heard this, I decided to look into it at some time. That time has come.
A couple of weeks ago I put together some scripts and code to allow me to compile the two Integer implementations into a single program and benchmark them against each other. My initial results looked like this:
That confirmed the slowness for multiplication and division if nothing else.
Taking a look at the code to integer-simple I found that it was storing Word#s (unboxed machine sized words) in a Haskell list. As convenient as lists are they are not an optimal data structure for a something like the Integer library.
I have already started work on replacement for both versions of the current Integer library with the following properties:
- BSD licensed.
- Implemented in Haskell (with GHC extensions) so there are no issues with linking to external C libraries.
- Fast. I'm aiming to outperform both integer-simple and integer-gmp on as many benchmarks as possible.
- Few dependencies so it can easily replace the existing versions. Currently my code only depends on ghc-prim and primitive.
So far the results are looking encouraging. For Integer values smaller than a machine word, addition with my prototype code is faster than both existing libraries and for adding large integers its currently half the speed of integer-gmp, but I have an idea which will likely make the new library match the speed of integer-gmp.
To recap, there was a function, withResource, that handled creation/acquisition and disposal of resources, but if you needed to access the resource directly in the tests, you had to store the resource in an IORef (or similar) as part of the initialization routine.
At the time it seemed acceptable, but later I discovered that when the number of resources was bigger than one or two, or even not known in advance (when tests are generated rather than just written down), this was inconvenient enough to start looking for a different solution.
One of the major problems with tests receiving the resource value directly, as inwithResource :: IO a -> (a -> IO ()) -> (a -> TestTree) -> TestTree
… was that the resource could be used not only in the tests themselves, but to construct the tests, which is bad/wrong for a number of reasons. For instance, we don’t want to create the resources when we’re not running tests, but we still want to know which tests we have.
The solution I found is to pass not the value of the resource, but an IO action yielding the resource.withResource :: IO a -> (a -> IO ()) -> (IO a -> TestTree) -> TestTree
Even though it’s an IO action, it doesn’t acquire the resource, because such a resource wouldn’t be shared across multiple tests, which is the semantics we’re after. Instead, it returns the resource which has been acquired (think: reads from an IORef or MVar). But thanks to it being an IO action, it can only be used inside a test, and not to construct or alter tests based on the resource value.
Here’s a modified example from the last article which works with this new API:import Test.Tasty import Test.Tasty.HUnit -- assumed defintions data Foo acquire :: IO Foo release :: Foo -> IO () testWithFoo :: Foo -> Assertion (acquire, release, testWithFoo) = undefined main = do defaultMain $ withResource acquire release tests tests :: IO Foo -> TestTree tests getResource = testGroup "Tests" [ testCase "x" $ getResource >>= testWithFoo ]