The hback googlecode page has been updated to reflect this. Google’s SVN is no longer officially supported, so do update your sources.

Checkout the source:

darcs get --partial http://code.haskell.org/hback/

In other news, I’m still swamped with school work, but will be back to working on hback by the end of next week. Stay tuned!

Also, if you haven’t recently checked the comments from the original post, you really ought to! The readers have raised some questions and made quite a few good arguments about protocols and limitations of dual n-back tests.

http://code.google.com/p/hback/

The source checkout includes the latest development version of the game. Eventually, I would like to host a public darcs repo for the project, but for now this will have to do.

If you are currently using or considering playing with hback, I highly recommend you checkout the latest trunk. It’s a much-improved version over 0.0.2 since it duplicates the protocol as described in the paper. If you spot any deviations, please do let me know. As soon as the most important tickets are fixed, this will be the basis for the much-revised 0.0.3 version. Additionally, I would like to explore building a win32 executable based on this trunk.

Do check out the code and post any tickets or comments! Better to fix them now than after the release :)

Based on feedback (kudos James and Joseph) I’ve refactored a lot of the code and added the following feature requests:

• Left and right arrows toggle the buttons on/off. Joseph’s suggestion worked fine, but on my setup it only highlighted the correct button. This seems a little counterintuitive to me since the API calls it an “activation”; my version looks for key events and automatically toggle the buttons.
• Game has a Pause mode which can be toggled on/off with 'p'
• Added some comments ;-)
• Added a score logger which I think would be cool for eventually analyzing lots of data (eg. pretty graphs of user improvement over time). This can be disabled with turnOffLogging=True in hback.hs, although I don’t see why you would want to: I’m not sending your data over the wire to analyze average IQs of Haskell hackers (yet).

I think the biggest changes are under the hood: I refactored the widgets and state data structures and, as a consequence, a lot of the remaining code. Hopefully the code is a little clearer on what it’s doing and why. Send in all your feedback and ideas! (I do try to get around to implementing them, eventually.)

Per user requests, here are some of the liberties I took with the original paper:

The number of graphics were chosen to be 9 different boxes (this is how I understood the paper’s description). I’ve been considering adding color variations (eg. with two colors, we would have 18 different graphics) - would this be a good idea?

The paper only stated alphabet letters were chosen for the sounds. This is consistent with what I learned about easy memory encodings in my psychology courses in college. ;-) What I am not sure about is the number of different sounds used. I decided to keep the number of unique sounds equal to the number of graphics (just to minimize unnecessary variations).

The pseudorandom generator was originally free-for-all, but I found the chance of a True Negative was unfairly high (especially at higher levels of play). In other words, with increasing levels of difficulty, it was much safer to guess that the stimuli did not repeat. Since the user could easily “win” the game by not doing anything, it clearly went against the primary objective of the game as defined in the paper: to keep the user challenged at all times. After several different iterations of pseudorandom generators, I settled on the current version: there is a 50% chance that the stimuli is in fact the same as n-th previous turn and a 50% chance it is one of the other stimuli (randomly generated with equal probabilities). I feel this most clearly follows in the spirit of the game, which is to ensure that game consistently keeps the user mentally challenged (too easy or too difficult means the user loses concentration and no learning takes place).

With the same primary goal, the next-level choice is decided: with a naive score currently calculated as ((true positive + true negative) / total), the game level difficulty will decrease at 35% or lower, increase at 75% or higher, and otherwise remain the same. These boundaries were arbitrarily chosen by me and I am waiting for feedback to find out if they do in fact deliver a “consistently challenging” environment.

Except, of course, this is Mercedes-Benz we’re talking about: among the first of car makers to introduce crumple zones, disc brakes, ABS, air bags, and electronic traction control systems. So forget everything you know about the bicycle! Welcome to the new age: with the help of alien technology the user can now pedal less and enjoy the scenery more. Let’s get down to the brass tacks; all of us here are technically-minded, Haskell and Lisp are not alien technologies, so why should a bicycle be? The motor is a 24V 300 watt DC Motor with a 20 cell 24V 5amp/hour Nickel Cadmium battery. For the less technically inclined that means we can go 19 miles at a nice cruising speed of 15 mph.

But the fun doesn’t stop there! All the best ideas were laughed at and disregarded at first; if anything, Mercedes should consider this post as a compliment that they are doing something right and on the path to a bicycle revolution. Riding the bike is in fact an enjoyable experience: with the motor on and draining the precious battery life, I can push the pedal just a little and feel a large torque swell up and kick the rear-wheel drive vehicle quickly up a steep hill. It really is a god-send: considering the weight of the bike, if the motor was drained I doubt I could actually get up the hill. But the problems start once you’re on level-ground (or dare-say, going downhill). The lawyers must have gotten to the designers before the AMG team showed up, because the bike is speed capped at roughly 15mph. That means you will get everywhere in comfort, but walking would probably be faster. And you will have to suffer the shame of having all the other bikers pass you by (or be forced to pedal furiously to keep your heavy bike in pace with all the low-tech bikes around you).

While we’re on the subject of the other bikers, I’m already hearing complaints about the slow integration of new innovations. And I agree; but where is the innovation? Most motorized bicycles fall into one of two groups: motor-powered scooters where the pedals are really just there for emergencies and decoration, and motorized bicycles which can help you go a lot faster and pedal less. This bike clearly falls into the latter category (excluding the speed boost). The first motorized electric bicycles were already showing up in the 1890s: it’s a good thing Mercedes decided to instead develop the Hybrid Bicycle, or this would be ancient history.

All things considered, Mercedes-Benz feels we should wait and charge a battery for 3 hours (recommended full charge 5.5 hours) to ride 20 miles with a limiter capping us to a little over walking speed. I feel this may be a marketing scheme to prove to us once and for all bicycles are useless aside from the leisurely Sunday stroll and we should go and buy that SLK 55 AMG or S600 when we actually want to go somewhere.

Based on a recent research paper that claims fluid intelligence could be improved by training working memory, I wrote up a dual n-back test memory game in Haskell and gtk2hs. This is an alpha release: all comments are most welcome.

Gameplay

The n-back memory game tests whether the player can remember if the nth previous turn matches the current one. The dual n-back test will measure how well the player can remember both visual and graphic stimuli simultaneously.

Given a difficulty level n, the player is expected to remember on each turn whether the nth previous sound or graphic (or both) matches the current one, and toggle the appropriate button(s). The graphic flashes for 500ms and the player has another 2.5 seconds to answer.

The training game consists of b block iterations, where each block will present (20+n) visual and audio stimuli. After each iteration, the difficulty of the n-back test may increase or decrease, depending on the performance of the player: the goal is to constantly keep the player at peak concentration.

Installation

Download hback-latest.tar.gz

 % tar -xzf hback-0.0.tar.gz
 % cd hback-0.0

Game can be played without system-wide installation:

 % make trial
 % ./hback

If you like what you see, feel free to install it:

 % make build
 % make install    # you may need root privileges for this
 % rehash
 % hback

hback takes two optional arguments:

 % ./hback b n
     - b determines the number of block iterations (eg. try 20 for an effective daily workout)
     - n determines the initial level (defaults to 1)

Errata

• Playing sounds currently through mplayer. If mplayer is not installed or you prefer a different player (all the sound files are .wav), currently the user needs to edit hback.hs (function playSound :: Audio -> IO ()) and recompile. This will be fixed as soon as I think of a good cross-platform solution; any suggestions?

import System.Console.Readline

main :: IO ()
main = do
  putStr "Key: "
  k <-  readKey
  putStrLn [k]

Looks pretty innocent, right? And it runs just fine with runhaskell. But as soon as you try to compile it with ghc and run it, Segmentation Faults occur. This was a bug that recently bit me with my hlean program.

What is the difference between the two? runhaskell invokes ghci, which makes additional readline initializations before handing it off to your main. The documentation is non-existent, so here is what you need to do in case you come across the same problem:

import System.Console.Readline

main :: IO ()
main = do
  initialize     -- System.Console.Readline.initialize :: IO ()
  putStr "Key: "
  k <-  readKey
  putStrLn [k]

Again, you test it using runhaskell and everything works fine. Except when you build and run it, the prompt just sits there - no matter how many times you hit that key - until you hit the carriage return (for the younger generation, that’s [Enter]). Turns out that initializing Readline is not enough, ghc and ghci have different buffering modes. After even more struggling which you now don’t have to suffer through, here’s the final solution:

import System.Console.Readline
import System.IO

main :: IO ()
main = do
  initialize     -- System.Console.Readline.initialize :: IO ()
  hSetBuffering stdin NoBuffering   -- System.IO
  hSetBuffering stdout NoBuffering  -- System.IO
  putStr "Key: "
  k <-  readKey
  putStrLn [k]

Hope I saved some poor googler some time and stress - I know I would have appreciated finding a post like this earlier. Kudos to pejo and dcoutts on #haskell irc for helping me sort this out.

I needed a program to find duplicate files in my constantly growing jungle, commonly referred to as a $HOME directory. I also needed a real motivation to sit down and write something in Haskell. After several cups of tea, I realized I could kill both birds with one heavy laser-targetting sniper rifle. After all, isn’t that what they say about Haskell: once you can get it to compile, you’re almost done?

hlean.hs is a command line program that takes any number of directories passed as arguments, recursively find all files, hashes them (defaults to sha256), and asks what to do with any duplicate sets found. It works fine for me, but since this is the first release, there are certainly some rough edges and caveats. Additionally, only you are responsible for your data; use this at your own risk: I cannot be held responsible if your computer blows up in a freak fire accident and coincidentally all the monkeys escape from the zoo.

Rough edges:

• All the Haskell hash function libraries I’ve tried are either too slow or don’t handle large files very well, hence I was currently forced to use an external command line hashing function.
• sha256 is the default command line hash. If you are not running FreeBSD, you will most likely need to modify two functions: hashCommand and hashCommandParse.
• Eventually, I will either find a suitable Haskell library or make a more user-friendly configuration setup.
• The “move file” action does not give the user a nice shell-like directory tab autocomplete. It would be nice to find a Readline prompt that does.

Ugliness:

• I’ve made a cabal package, but currently the ghc compiled version seg faults. The runhaskell version works perfectly fine, which has left me very confused. I will look into this more when I have the time, but I’ve uploaded both versions in case someone would like to help me debug the issue. Fixed in hlean 0.1.2

Haskell: hlean.hs
Cabal Package: hlean-0.1.1.tar.gz

Usage:
runhaskell hlean.hs [dirs]

Feel free to leave any comments, bug reports, or feature requests.

In this installment we will setup the firewall, Xorg, and basic multimedia and development ports: all the basic essentials to make use of your desktop machine. The ports list is very skimp on purpose: since there is no way I can think of everything most of us use daily, I’m not even going to try. But if you can follow along and get this much setup, you will have absolutely no problem finding and installing all the actual applications you can’t live without.

Firewall

Setup a firewall. I prefer the OpenBSD firewall pf which is also ported to FreeBSD. See also:

• http://home.nyc.rr.com/computertaijutsu/pf.html
• http://www.bgnett.no/~peter/pf/en/long-firewall.html
• http://www.openbsd.org/faq/pf/index.html

# vi /etc/rc.conf
  >> pf_enable="YES"                 # Enable PF (load module if required)
  >> pf_rules="/etc/pf.conf"         # rules definition file for pf
  >> pf_flags=""                     # additional flags for pfctl startup
  >> pflog_enable="YES"              # start pflogd(8)
  >> pflog_logfile="/var/log/pflog"  # where pflogd should store the logfile
  >> pflog_flags=""                  # additional flags for pflogd startup

# cp /usr/share/examples/pf/pf.conf $LOCALROOT/etc/
# ln -s $LOCALROOT/etc/pf.conf /etc/
# vi /etc/pf.conf
# /etc/rc.d/pf start
# /etc/rc.d/pflog start
# pfctl -f /etc/pf.conf

Xorg

Install ports:

• x11/xorg
• graphics/dri
• graphics/mesa-demos
• x11-fonts/urwfonts-ttf
• x11/kde3 or x11/gnome2 or x11/xmonad/ or …

# Xorg -configure
# mv -i /root/xorg.conf.new /etc/X11/xorg.conf
# vi /etc/X11/xorg.conf
  >> Load "freetype"
  >> FontPath     "/usr/X11R6/lib/X11/fonts/urwfonts-ttf"
  >> FontPath     "/usr/local/share/apps/konsole/fonts"
  >> FontPath     "/usr/local/share/fonts/ampspsfont/type1"
  >> FontPath     "/usr/local/share/fonts/cmpsfont/type1"
# vi /usr/local/etc/fonts/local.conf
  >> <dir>/usr/local/share/apps/konsole/fonts</dir>

# fc-cache -f
# cd /usr/ports/x11-fonts/webfonts
# make WITH_MSLICENSE="YES" install
# make clean
# vi /etc/X11/xorg.conf:
  >> FontPath "/usr/local/lib/X11/fonts/webfonts/"

Post-Install

If you are easily corrupted by power, add yourself to the wheel group.

# pw groupmod wheel -m $USER

Make sure you have the following entry in /etc/fstab:

# linproc /compat/linux/proc linprocfs rw 0 0

For some reason, FreeBSD does not have a cron job to update the locate database. I tend to use this a lot, so I setup a cronjob to run updatedb daily at 4:05:

# crontab -e
  >> 5 4 * * * /usr/libexec/locate.updatedb

Additional Ports

Multimedia:

• audio/amarok
• multimedia/mplayer
• multimedia/win32-codecs
• net-p2p/ktorrent

Utilities:

• security/sudo
• sysutils/htop
• archivers/unrar
• archivers/unzip

Development:

• editors/emacs-devel
• lang/python
• lang/ghc
• devel/darcs

Databases:

• database/postgresql83-server

Comments

Are there additional steps you like to take with new installations?
Perhaps I’ve missed something important?

Installation

Download the latest boot-only iso, md5 checksum the image, and burn to a CD.

ftp://ftp3.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/

Booting the installation disk, we will follow the standard installation routine. The installation is fairly straight forward; the only hickup for Linux users may be the partition layout. Linux “partitions” are FreeBSD “slices”, where the FreeBSD slice is then divided into “partitions”. An example partition layout:

/          256 MB
/swap      2048 MB
/usr       *
/var       1000 MB

If you are stringent with disk space, feel free to ignore the /var partition. It will install under /root and over time you can move large /var/* directories to /usr and symbolically link them back to /var/.

Install the MINIMAL set and avoid installing the ports tree. Reboot the computer, you now have a minimal FreeBSD installation.

Install your favorite shell. You’re going to be here a while, why suffer?

# pkg_add -r zsh
# chsh

Base System

I like to keep all my locally modified files under a separate directory for easy reference and backup.

# mkdir /root/local
# export LOCALROOT="/root/local/"
# mkdir $LOCALROOT/etc
# mkdir $LOCALROOT/etc/cvsup
# cp /usr/share/examples/cvsup/stable-supfile $LOCALROOT/etc/cvsup/
# vi $LOCALROOT/etc/cvsup/stable-supfile
    >> *default host=ftp4.freebsd.org

Tune the make.conf to your system settings.

# cp /usr/share/examples/etc/make.conf $LOCALROOT/etc/
# ln -s $LOCALROOT/etc/make.conf /etc/
# vi /etc/make.conf
    >> cputype=pentium4m
    >> cflags= -O2 -fno-strict-aliasing -pipe
    >> coptflags= -O -pipe

Configure the kernel for the system. Anyone who has had to recompile the Linux kernel will find the FreeBSD process a real treat. It is common practice to use the hostname (all caps), in this example DALI, as the kernel config file.

# cd /usr/src
# csup /usr/local/etc/cvsup/stable-supfile
# mkdir /root/kernels
# cp /usr/src/sys/i386/conf/GENERIC /root/kernels/DALI
# ln -s /root/kernels/DALI /usr/src/sys/i386/conf/
# vi /root/kernels/DALI

See the FreeBSD handbook for kernel configuration options. Now we can build and install the kernel and base system.

# make buildworld
# make buildkernel KERNCONF=DALI
# make installkernel KERNCONF=DALI
# reboot

# mergemaster -p
# make installworld
# mergemaster -iU
# reboot

Ports

Now we will install the ports tree…

 # portsnap fetch
 # portsnap extract

… and some essential tools.

 # cd /usr/ports/ports-mgmt/portaudit
 # make install clean
 # rehash
 # portaudit -Fda
 # cd /usr/ports/ports-mgmt/portmaster
 # make install clean
 # rehash

Use portmaster -d pkg_name to install any additional ports. As usual, see the manpage for more info.

You now have a FreeBSD 7.x compiled and tuned for your architecture. In Part 2 we will install various ports found on common desktop systems so you can actually get some work done.