Going back to the todo.txt haskell project, this post will continue on with more advanced parsers and how to test them.
Posts tagged tutorial
I’ve always liked self hosting as it gives you the most flexability. With projects like gitolite you can ditch the heavy database, the server side scripting languages and run a nicely configured and feature rich server on something as small as a Raspberry Pi.
Gitolite supports gitweb, but when running on Debian it required me to install apache2, and configure CGI. Other distros I’ve tried were even worse with dependencies. All I want to is give public, read-only access via http. Can’t be too difficult, right?
Continuing with the todo.txt haskell project, this post will introduce parsers.
Up to this point we have written some code, explained type classes, and done a little pattern matching. But we haven’t written anything that really does anything. Until we have some IO to perform, we will have to find another way to interact with our code. This is a perfect chance to introduce Unit Testing.
Now that we have a few basic types we should start working on making their interaction nicer. It is pretty important to be able to print and compare data types so we will start there. Once we are able to compare, we should be able to filter lists of data types.
To work on my Haskell skills I decided to work on a little side project. I didn’t want something too complicated but I did want to try out some of the more fun and interesting tasks that Haskell does well.
As I work on the project I’ll go through the code, as a sort of tutorial on creating an actual application.
History: Another high traffic page from my previous site being transitioned here.
If you’ve ever worked with embedded systems or built code for a system other than your build machine you’ve probably found that running code on native hardware can sometimes generate different results than on your Beige Box. Being able to run and debug your code on your target hardware can be very useful but sometimes quite difficult to do. Using GNU’s Debugger gdb can be extremely cumbersome on its own and I typically prefer to use the GUI client ddd. With most of my projects, the target hardware does not have X support and most of my interactions are through Serial or Ethernet. If you are in the same situation you might find gdbserver, which comes with gdb, of use.
For a while now I’ve been using building applications using a Cross Compiler Jail (see blog post) on my development system to make the use of cross compilers much simpler. I can compile inside a system that looks and feels like I’m on the target’s OS having gcc, arch, and a bunch of other attributes all pointing to a ARM CPU even though I’m compiling on an x86_64. No need for calling
gcc-arm-unknown-linux-gnueabi-gcc when the jail macros it to
A bit of history: I had written a wiki article a few years back about how to setup a cross compiler and a build environment for working with ARM CPUs and Debian based distributions. I’m in the process of getting rid of the site so I thought it was a good time to retry this setup and put it on my new site.
This tutorial will cover setting up a build environment for cross compiling. This tutorial assumes you are building on a Debian based system for a Debian based target. If your systems are slightly different follow the spirit of the tutorial rather than the letter.
I’m a big proponent of taking personal security measures when interacting on the internet. I sign all my emails using my PGP key so you know it is from me and not a virus, spammer, or a stolen account. I encrypt my netbook’s hard drive and keep a pretty tight firewall. For the most part I like to keep everything under lock and key because you just never know who might get your info and what they might do with it.
What if you don’t want to go through all this work. Without a Public/Private Key you can still use Symmetric Encryption to send files and emails and store data on your computer with an increased level of security. All possible with a few utilities found on most *nix systems.