Greynode Blog

< Previous
  Showing Page 1 of 13   Next >

Haskell-Mode Newline Issues

Created on 2009-01-04 11:40:43

I recently started playing around with haskell again. I usually use vim for editing, but for languages such as haskell I can't resist but to use emacs in combination with a package such as haskell-mode. In steps the problem.


Haskell-mode ran fine on my macbook pro, but for my desktop PC running CentOS 5.2 it was a different story. When I entered into inf-haskell mode to have an interactive prompt, emacs wasn't handling newlines properly. Instead of showing newlines I would get ^J (or C-J) interspersed throughout the output. You can see an example of it here.


The solution was a bit hard to come by, but after searching for a long time, I found the problem and the solution. The problem is that inf-haskell is telling its subprocess (in this case, GHCi) that they are running in a terminal -- but it is still echoing the user input regardless of this fact. This confuses libedit into thinking it can turn off echoing in favor of its rich text editing. To fix the problem one needs to force libedit (or GHCi) into thinking it is not in a terminal. We use the "cat" facility to do this:


First, we need to make a new file to server as our haskell program. You can put this in ~/bin/ghci-no-tty


#!/usr/bin
# file: ~/bin/ghci-no-tty
# force libedit/ghci out of terminal mode

/bin/cat | /usr/local/bin/ghci

You may have to modify this code a little bit to fit the location of your binaries. Once this file is created, be sure to chmod +x ghci-no-tty or you may run into execution problems.


Now that we have a file to run, we need to tell haskell-mode where it can find the file to use as its haskell program. We can do that by adding the line below to our ~/.emacs


;; file: .emacs snippet
;; change default haskell program to ghci-no-tty
(setq haskell-program-name "/home/sheik/bin/ghci-no-tty")

Once this is added, we can reload emacs and try again. Low and behold it works! By forcing libedit/ghci to think it was getting input from cat, the problem has stopped. You can see my current .emacs configuration here.


Tags: Programming  Technology  General 

QSocketNotifier Issues

Created on 2008-12-30 10:28:00

I talked in my previous post about a bug that was causing over 100% CPU usage on both OS X and Linux. Well, I have found the bug, and I will explain it here.

The QSocketNotifier class in QT allows you to monitor socket file descriptors and generate events when they are ready. Basically, what had happened, is I made 2 socket notifiers: one for reading and one for writing. The latter socket notifier was causing the problem. Because the socket was always ready for writing, the signal for writing was constantly being generated. Disabling the socket notifier for writing has fixed the problem.


Tags: General  Technology  Programming 



< Previous
  Showing Page 1 of 13   Next >