Planet Haskell

July 02, 2009

Holden Karau

Your browser history is showing (an open source web application in scheme)


my web2.0collage
Originally uploaded by dmcopernicus
Over the course of last weekend I wrote web2.0collage, a browser history sniffing collage generator in scheme. Web2.0collage is designed to graphically illustrate just how easy it is for sites to determine what your browser history is. When you visit the site it sniffs your browser history, and creates a collage of the (safe for work) sites that you visit. It is an interesting application of potentially scary technology (imagine a job application site using this to screen candidates). Ideally, given some time in my schedule, I'd like to make it a bit more user friendly and robust so that I could perhaps show it to the general public to increase awareness of privacy issues on the web.

The code, while not good since I was learning how the plt-webserver & imagemagick bindings worked at the time, is available under the agpl. Today it hit the front page of slashdot, causing some less than fortunate scaling issues to be discovered. Hatguy & myself managed to fix them (sort of) without too many interruptions.

by Holden Karau (holden@pigscanfly.ca) at July 02, 2009 11:36 AM

July 01, 2009

Michael Snoyman

Hack sample- chat server

Not that you’ll want to replace IRC with this any time soon, but I’ve put together an incredibly simplistic chat server to demonstrate Hack. The code is available in my hack-samples github repo. I’m not going to copy the source code here, but point out a few cool pieces.

In the imports list, I say import qualified Hack.Handler.SimpleServer as Handler to use the SimpleServer handler. Later on, I use Handler.run 3000 to run a simple server on port 3000. If you instead replace SimpleServer with CGI and remove the 3000, you immediately have a CGI application. Of course, all of the MVar concurrency code is unneeded overhead in a CGI application, but you could also use Happstack, FastCGI or any other handler.

Also, I alluded in my previous post to the idea of using currying to initiate some stuff. This code is a perfect example. In my main function, I load up data from a text file, create a Handle to write to, wrap them both in MVars and use that to curry the app function. This way, all of that initialization code only gets called once, no matter how many requests are served. This is a simple approach which works very well in production.

Not much more to say, I think the code speaks for itself!

by admin at July 01, 2009 09:31 PM

Luke Palmer

On the By functions


Here’s a quick little note that has been bugging me for a while, and nobody wants to talk about it right now on IRC.

I think the By functions:

sortBy :: (a -> a -> Ordering) -> [a] -> [a]
maximumBy :: (a -> a -> Ordering) -> [a] -> a
groupBy :: (a -> a -> Bool) -> [a] -> [[a]]
nubBy :: (a -> a -> Bool) -> [a] -> [a]

Etc. should be replaced by On functions:

sortOn :: (Ord b) => (a -> b) -> [a] -> [a]
maximumOn :: (Ord b) => (a -> b) -> [a] -> a
groupOn :: (Eq b) => (a -> b) -> [a] -> [[a]]
nubOn :: (Eq b) => (a -> b) -> [a] -> [a]

My argument is: the functions provided to sortBy etc. have some preconditions. sortBy is not well-defined (or oughtn’t be) for functions which are not linear ordering functions; nubBy is shouldn’t be well-defined (to the dismay of some 31337s) for functions which do not encode an equivalence relation. But the folklore is that functions are typically “as total as possible”, so if it wants a function of some type, all I have to do is conjure a function of that type and my output will be something reasonable in terms of that function.

On the other hand, the folklore of typeclasses is that they typically come with laws. You need to prove — or at least think you know how to prove — some laws when you make a type an instance of a typeclass. The On functions use this obligation to encode their precondition. They are easier to use in a verified setting, too; there are a bunch of standard instances of Eq and Ord for which the laws are known to hold; map your data on to that in any way you like and the precondition is guaranteed.

Thoughts?

by Luke at July 01, 2009 07:51 PM

Magnus Therning

Dataenc finally making it into Debian

Erik de Castro Lopo is having a lot more success with getting dataenc into Debian than I ever had.

by Magnus at July 01, 2009 01:54 PM

Thomas ten Cate

New build instructions

Because of many problems I experienced with Darcs, I converted the EclipseFP repository to Git. I really like the clean and simple model and UI of Darcs, and I’m sorry to see it go, but it was simply too slow and too unreliable. Also, I removed all dependencies on Cohatoe. Without further ado, here are [...]

by Thomas ten Cate at July 01, 2009 10:35 AM

Erik de Castro Lopo

Three More for the Debian New Queue.

Over the last couple of weeks I've managed to get three new packages into the Debian NEW queue :

  • haskell-polyparse - A variety of alternative parser combinator libraries for Haskell (this is a dependency for later versions of HaXml).
  • haskell-dataenc - A Haskell library of data encoders and decoders like Base64, uuencoding etc.
  • haskell-json - Haskell library for serialising data to and from JSON.

Thanks to Simon Horman for sponsoring/uploading the first two of and Matt Palmer for sponsoring/uploading haskell-json.

July 01, 2009 08:32 AM

June 30, 2009

Greg Bacon

FFI: calling into kernel32.dll

Calling the Win32 API function GetComputerName makes for a nice demonstration of combining Haskell's FFI, hsc2hs, and Cabal.

The front matter:

{-# LANGUAGE ForeignFunctionInterface #-}

module Win32.Kernel32 (getComputerName) where

import Control.Monad (when, unless)
import Data.Bits ((.|.))
import Foreign.Marshal.Alloc (alloca)
import Foreign.Ptr (nullPtr)
import Foreign.Storable (peek, poke)
import System.Win32.Types (DWORD, LPDWORD, LPTSTR, LPVOID,
                           peekTStringLen, peekTString, withTString)

#include <windows.h>
With hsc2hs, it's possible to #include C headers and use constants in Haskell programs, as we'll see below.

Now to get hold of a few entry points in kernel32.dll. The types defined in System.Win32.Types are handy:

foreign import stdcall unsafe "GetComputerNameW"
  win32_getComputerName :: LPTSTR -> LPDWORD -> IO Bool

foreign import stdcall unsafe "GetLastError"
  win32_getLastError :: IO DWORD

foreign import stdcall unsafe "FormatMessageW"
  win32_formatMessage :: DWORD
                      -> LPVOID
                      -> DWORD
                      -> DWORD
                      -> LPTSTR
                      -> DWORD
                      -> LPVOID
                      -> IO DWORD
Note the use of the stdcall calling convention and that we're calling the wide-character versions.

GetComputerName takes two parameters, a pointer to a character-buffer and a pointer to an in-out DWORD (in: capacity; out: used). On the Haskell side, this means a couple of allocations, initialize the length parameter, call GetComputerName, and read the result:

getComputerName :: IO String
getComputerName =
  withTString maxBuf $
    \buf ->
      alloca $ \len -> do
        poke len (fromIntegral maxLength)

        success <- win32_getComputerName buf len
        unless success $ failWithLastError "GetComputerName"

        len' <- peek len
        peekTStringLen (buf, (fromIntegral len'))
  where
    maxBuf = replicate maxLength '\0'
    maxLength = #const MAX_COMPUTERNAME_LENGTH
The #const bit at the end tells hsc2hs to substitute the value of the C preprocessor symbol MAX_COMPUTERNAME_LENGTH.

If all goes well, GetComputerName returns non-zero, but we'd like to handle cases when things go wrong. In the Win32 API, we'd call GetLastError and convert the error code to a human-readable diagnostic with FormatMessage:

failWithLastError :: String -> IO a
failWithLastError name = do
  code <- win32_getLastError
  withTString errbuf $
    \buf -> do
      gotmsg <- win32_formatMessage flags
                                    nullPtr
                                    code
                                    lang
                                    buf
                                    (fromIntegral errlen)
                                    nullPtr
      fmtcode <- win32_getLastError
      when (gotmsg == 0) $
        fail $ name ++ " failed: " ++ show (code, fmtcode)

      msg <- peekTString buf
      fail $ name ++ ": " ++ filter notEOL msg
  where
    errbuf = replicate errlen '\0'
    errlen = 300
    flags = #const FORMAT_MESSAGE_FROM_SYSTEM
            .|.
            #const FORMAT_MESSAGE_IGNORE_INSERTS
    lang = 0
    notEOL c = c /= '\n' && c /= '\r'
FormatMessage can fail too, so in that case, the poor user is stuck with a couple of opaque error codes. Otherwise, peekTString copies the formatted error message for use with fail. Note also that Win32's FormatMessage is variadic, but this wrapper does not take advantage, instead passing a canned null pointer.

Having nice error messages can be sort of helpful with programming errors such as forgetting to initialize the length parameter in a call to GetComputerName:

$ cabal test
test: user error (GetComputerName: The file name is too long.)
The code above lives in a file named Kernel32.hsc. The package definition (.cabal file) points to the module name, and when Cabal finds the .hsc extension, it transparently runs the code through hsc2hs:
Library
  hs-source-dirs:  src
  exposed-modules: Win32.Kernel32
  build-depends:   base, Win32
  extensions:      ForeignFunctionInterface
  ghc-options:     -Wall
The package includes a simple test that calls getComputerName and prints the result to the standard output, so the following sequence of commands should remind you of your machine's name:
cabal configure -ftest
cabal build
cabal test
The code is also available on GitHub.

by Greg (greg.bacon@gmail.com) at June 30, 2009 11:57 PM

Ralf Lammel

SYB goes Prolog

I am about to finish a short article on SYB in Prolog.

Deadline seems to be in 30 hours from now.

If anyone has suggestions, I'd appreciate it.

Thanks,

Ralf

http://www.uni-koblenz.de/~laemmel/OdeToProlog/

 

Scrap Your Boilerplate---Prologically!

Status (30 June 2009)
Paper available in draft form.
Code distribution not yet available online.

 

Author(s)
Ralf Lämmel

 

Abstract
``Scrap Your Boilerplate'' (SYB) is an established style of generic functional programming. The present paper reconstructs SYB within the Prolog language with the help of the univ operator and higher-order logic programming techniques. We pay attention to the particularities of Prolog. For instance, we deal with traversal of non-ground terms. We also develop an alternative model of SYB-like traversal based on metaprogramming. This generative, type-driven model is also amenable to type-driven optimization.

 

Keywords
Scrap Your Boilerplate, Haskell, Prolog, Stratego.

 

Bibtex entry
@inproceedings{OdeToProlog,
author = "Ralf L{\"a}mmel",
title = "{Scrap Your Boilerplate---Prologically!}",
booktitle = "Proceedings of the 11th ACM SIGPLAN international conference on Principles and practice of declarative programming",
publisher = ACM,
year = 2009,
note = "6 pages"
}

 

Downloads

by RalfLammel at June 30, 2009 09:52 PM

Arch Haskell News

Arch Haskell News: June 30 2009


Another update, since there was a bit of a package backlog.

Hackage now has 1395 (+130) Haskell packages, of which 1222 (+113) (87.6%) have been natively packaged for Arch in AUR. All these packages are available via AUR, using the “yaourt” tool.

The full log of updates and new packages is available here.

Notable Updates

Dozens of other packages have been added as well. Interestingly, a handful of new Haskell games have been published.

by dons00 at June 30, 2009 09:25 PM

Galois, Inc

Tech Talk: The Fleet Architecture

The July 7th Galois Tech Talk will be delivered by Ivan Sutherland, titled “The Fleet Architecture”

  • Date: Tuesday, July 7th, 2009
  • Time: 10:30am - 11:30am
  • Location: Galois, Inc.
    421 SW 6th Ave. Suite 300
    (3rd floor of the Commonwealth Building)
    Portland, OR 97204

Abstract: This talk describes a radically different architecture for computing called Fleet. Fleet accepts the limitations to computing imposed by physics: moving data around inside a computer costs more energy, more delay, and more chip area than the arithmetic and logical operations ordinarily called “computing.” Fleet puts the programmer firmly in charge of the most costly resource, communication, instead of in charge of the arithmetic and logical resources that are now almost free. Fleet treats arithmetic and logical operations as side effects of where the programmer sends data.

Fleet achieves high performance through fine grain concurrency. Everything Fleet does is concurrent at the lowest level; programmers who wish sequentiality must program it explicitly. Fleet presents a stark contrast to today’s multi-core machines in which programmers seek concurrency in an inherently sequential environment.

The Fleet architecture uses a uniform switch fabric to simplify chip design. A few thousand identical copies of a programmable interface connect a thousand or so repetitions of basic arithmetic, logical, input-output, and storage units to the switch fabric. The uniform switch fabric and its identical programmable interfaces replace many of the hard parts of designing the computing elements themselves.

Both software and FPGA simulators of a Fleet system are available at UC Berkeley. Berkeley students have written a variety of Fleet programs; their work helped to define what the programmable interface between computing and communication must do. A simple compiler now produces the programs required at source and destination to provide flow-controlled communication. We expect work on a higher-level language to appear soon as a PhD dissertation.

A recent 90 nanometer TSMC test chip, called Infinity, demonstrated switch fabric performance at about 4 GHz. A new test chip, called Marina, has just gone out for fabrication. Marina will test the programmable interface, and if successful, will give us confidence to build a complete Fleet. We seek participation from sponsors, programmers, and designers of basic computation elements.

Bio: Ivan Sutherland is a Visiting Scientist at Portland State University where he and Marly Roncken have recently established the “Asynchronous Research Center” (ARC). The ARC occupies both physical and intellectual space half way between the Computer Science (CS) and Electrical and Computer Engineering (ECE) departments at the university. The ARC seeks to free designers from the tyranny of the clock by developing better tools and teaching methods for design of self-timed systems. Prior to moving to Portland, Ivan spent 25 years as a Fellow and Vice President at Sun Microsystems. A graduate of Carnegie Tech, Ivan got his PhD at MIT in 1963 and has taught at Harvard, University of Utah, and Caltech.

Dr. Sutherland received the 1998 Turing Award, for his pioneering work in the field of computer graphics.


Galois has been holding weekly technical seminars for several years on topics from functional programming, formal methods, compiler and language design, to cryptography, and operating system construction, with talks by many figures from the programming language and formal methods communities. The talks are open and free. An RSVP is not required, but feel free to contact the organizer with questions and comments.

by Levent Erkok at June 30, 2009 08:23 PM

Greg Bacon

Setting up a simple test with Cabal

With the Cabal build and packaging system for Haskell, add a simple test program to your build with a couple of easy steps.

First, add the following to your project's cabal file:

Build-Type: Custom

...

flag test
  description: Build test program.
  default:     False

Executable test
  hs-source-dirs:  src, test
  other-modules:   MyModule1, MyModule2
  main-is:         Main.hs
  build-depends:   base
  if !flag(test)
    buildable:     False
When enabled (via cabal configure -ftest but otherwise off), this builds an extra program called test.

The custom build type gives you more flexibility in your setup script, so add code such as the following to Setup.hs:

main = defaultMainWithHooks hooks
  where hooks = simpleUserHooks { runTests = runTests' }

runTests' :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO ()
runTests' _ _ _ lbi = system testprog >> return ()
  where testprog = (buildDir lbi) </> "test" </> "test"
When you run cabal test, it will kick off your test program whose source is in test/Main.hs.

This approach has a few drawbacks. Users must explicitly enable the test builds. Building the test program entails rebuilding the other libraries in your package. Installing from a -ftest configuration will also install your test program.

by Greg (greg.bacon@gmail.com) at June 30, 2009 01:57 PM

Philip Wadler

Ketil Malde

Dephd updates

Dephd is a small application for performing various analysis of nucleotide sequences.  Originally, it was used for analyzing/converting PHD-file output from the basecaller phred, but it has since grown a bit beyond that.  A new update was just pushed onto HackageDB, this is just a quick note describing new features.

by ketil at June 30, 2009 11:41 AM

Bryan O'Sullivan

What’s in a text API?

Now that I’ve got the DEFUN 2009 schedule sorted out (you are coming, aren’t you?), I’ve had time to take a breath and think about the Haskell text library again. Its API is currently a clone of the ancient and venerable Haskell list API. If you’ve used the list API to do much text processing, you’ve probably spilled more than a few tears into your whiskey. The bytestring library also mostly clones the list API, albeit with a few improvements. This state of affairs makes me somewhat sad: here we are with a fabulous language, but a 1991-era API for mangling text.

To put this state of affairs into perspective, here is a function-by-function comparison of the string manipulation APIs of Python 2.6 and Haskell. This is intentionally somewhat pessimistic: I focus on aspects of the Python API that are either absent from or not trivially reimplemented in Haskell, but not the reverse. (If the details that follow make your eyes glaze over, skip them and read on after the table below.)

PythonHaskell
x + yx `append` y
x in yx `isInfixOf` y
x < yx < y
x <= yx <= y
x == yx == y
x != yx /= y
x > yx > y
x >= yx >= y
x % (...)
x[i] x `index` i
x[i:j](j-i) `take` (i `drop` x)
hash(x)
len(x)length x
x * yy `replicate` x
x.capitalize()
x.center(y)
x.count()
x.decode()decode... family
x.encode()encode... family
x.endswith(y)y `isSuffixOf` x
x.expandtabs()
x.find(y)
x.format(...)
x.index(y)
x.isalnum()all isAlphaNum x
x.isalpha()all isAlpha x
x.isdigit()all isDigit x
x.islower()all isLower x
x.isspace()all isSpace x
x.istitle()
x.isupper()all isUpper x
x.join(y)intercalate x y
x.ljust(w)
x.lower()toLower x
x.lstrip()dropWhile isSpace
x.partition(y)break (==y) x
x.replace(y,z)
x.rfind(y)
x.rindex(y)
x.rjust(y)
x.rpartition(y)
x.rsplit(y)
x.rstrip(y)
x.split(y)
x.splitlines()lines x
x.startswith(y)y `isPrefixOf` x
x.strip()
x.swapcase()
x.title()
x.translate(y)
x.upper()toUpper x
x.zfill()

For now, I’m intentionally not looking at Python’s unicodedata or string packages, even though each contains a handful of additional useful functions.

How would I broadly categorise what’s missing from the current Haskell APIs?

  1. Formatting. The format method that’s new in Python 2.6 is well designed and extremely useful. While there are a few formatting libraries on Hackage, each has flaws which I think are substantial enough to make them undesirable for wide use. As examples of those shortcomings, I’m thinking of a lack of static type safety or a poor fit for automated translation tools.
  2. Searching and splitting text. The Haskell APIs are based on predicates over individual characters, whereas what’s usually needed is predicates over strings. In other words, don’t just find me a character; find me a substring.
  3. Parsing. I’m not overly concerned about this, since Haskell’s libraries far outshine those of Python in this area. Although they currently lack support for the text library, the Parsec and attoparsec libraries will acquire it, I’m sure, as soon as there’s demand. What would be welcome is a decent Unicode-capable regular expression engine, for those times when you just have to get yourself into trouble in the name of expediency.

I intend to address each of these areas over the coming months, and I’ll write up the APIs I intend to flesh out here before I actually implement them, to solicit feedback from the community. One step that I think I’ll probably take, for instance, is to move a few of the functions in the Data.Text module that clone the list API into a new module, Data.Text.Legacy, so that I can use the same function names in Data.Text, but with more useful types. As an example of what I have in mind, I’d be inclined to move split :: Char -> Text -> [Text] into the legacy module, and replace it with split :: Text -> Text -> [Text].

There’s something of a tension between the goals of providing a small, focused text library and getting all the API details right in a way that will make it truly useful. I find the proliferation of tiny libraries on Hackage, each providing a few little pieces of missing functionality, to be pretty dispiriting from the point of view of getting dug in and producing useful application code quickly, so I intend for the text and text-icu libraries to be broadly useful from the get-go.

If you have opinions, or better yet patches, to contribute, let’s get things rolling!

by Bryan O'Sullivan (bos@serpentine.com) at June 30, 2009 06:13 AM

Tom Moertel

Dear Jeff Bezos: Here's an easy, effective way to fix the production problems in Amazon Kindle-edition books and, at the same time, prove that the Kindle is really, truly better than paper

I recently purchased a Kindle DX, mainly to read PDF documents that contain math and comp-sci formulas. Still, I couldn’t resist the temptation to try out the instant gratification of purchasing a “Kindle edition” ebook, so I ordered a sci-fi novel I had read as a child, Alan Dean Foster’s The Tar-aiym Krang.

The Good

The purchase and download via the ever-so-branded “Whispernet” wireless network went without a hitch. The Kindle DX, itself, was great and made reading easy. The text looked good, the navigation seemed intuitive. There was just one problem.

The Bad

The production standards of the content destroyed any chance of convincing me that I was reading something akin to a real book. I found numerous typographical errors, something that just doesn’t occur in real mass-market books, which have been subjected to professional review after typesetting. By far, the most common error was the substitution of a left open single quote for what should have been an apostrophe, an error that I don’t think Amazon missed an opportunity to make. For example, when shortening computer to ’puter:

Dear Amazon: that's not an apostrophe

The brilliant fix (no need to thank me, Mr. Bezos)

So, if you’re Jeff Bezos, you’re probably wondering what you can do to improve the quality of Kindle edition books. After all, you spent all that time, effort, and money on the Kindle itself, getting the look and feel just right, crafting the perfect book-reading experience, even insisting upon seamless “Whispernet” downloads to encourage impulse purchases of Kindle editions. You certainly wouldn’t want the content owners, the lovely folks who supply you with typo-ridden source documents, to undo all that you have worked so hard to achieve with the Kindle, to destroy the immersive, luxurious reading experience that you are so close to delivering, to unweave the spell that convinces readers that the Kindle is just as good as – if not better than! – a real book. Somehow, you must fix the content problem, but you know, you just know, the content owners are going to screw it up for you.

So, here’s what you do, Jeff. Let the content owners screw it up – you know that’s what they’re going to do, anyway – and fix the errors yourself. How? With an army of focused, motivated proofreaders: your customers!

Seriously, this idea would work miracles for you, Jeff. You know how the Kindle lets you make annotations to the Kindle editions you read? Just extend those annotations to include corrections. Then when those annotations are saved to Amazon’s servers, extract the corrections, combine them with the corrections from other readers, maybe verify them with a quick third-party review (a perfect job for the Mechanical Turk, wouldn’t you say?), and then automagically distribute the relevant, approved corrections to every Kindle reader who could benefit from them. Further, to make your readers happy that they found mistakes in the Kindle editions that they purchased, offer them a bounty, say 25 cents, for the first report of each correction found.

In one fell swoop, all your problems with production quality are fixed:

  • customers who find errors are no longer angry but happy
  • most Kindle editions will be corrected quickly, ensuring a blemish-free reading experience for the bulk of your customers
  • even if the content owners give you garbage for source documents, and even if they won’t allow you to change those documents one iota (they are pretty controlling, after all), you can still deliver perfection to your customers: apply corrections on the “client side,” correcting the pristine, yet error-filled source material, on the fly, right in the Kindle itself

And there’s one big bonus I didn’t mention. This capability would make Kindle editions better than real books. Not just marketing-copy, in-theory better, but really better. As in, now we have a compelling reason to switch from paper: to get the benefits of collaborative, peer-augmented reading and correction, in which each reader’s contributions enrich the reading experience for all who follow. Think about it, Jeff, it’s a big deal.

No need to thank me.

by Tom Moertel at June 30, 2009 04:28 AM

DEFUN 2009

DEFUN and CUFP 2009 registration are now open!

I’m pleased to announce that registration for DEFUN 2009 is now open, along with ICFP and associated workshops. For general information, you can see the ICFP registration page, and then step through to the online registration form.

People who register prior to July 30 will see a significant reduction in prices, which range from US$100 per day for students to $190 for people who are not ACM members. Do take note that if you want to attend both days of DEFUN, you must register for each one separately.

Also, if you’re planning to attend DEFUN, I strongly encourage you to sign up for our sister workshop, CUFP 2009, the best place to learn how real world developers are using functional programming in industry.

by admin at June 30, 2009 04:19 AM

June 29, 2009

Brent Yorgey

2009 ICFP programming contest reflections


This year, unlike last year, I had the good fortune to be physically located in the same place as several other people interested in competing in the 2009 ICFP Programming Contest. We only ended up with three people—we could have used more—but it was quite a lot of fun.

The problem this year (controlling some satellites to accomplish certain goals) was a good one. I especially liked the approach of distributing binaries to be run on a virtual machine, and requiring execution traces as submissions—as opposed to last year’s contest, it removed all the ickiness with wrangling execution platforms and ensuring your code would run on the organizers’ servers. And the problem itself was nifty, easy to get started on, difficult to finish, and always left room for improvements. My only complaint is that I would have been more excited about something with a more discrete flavor, since this was the second contest in a row with a simulation of physical objects, vector math, trig, and so on—but that’s only a small complaint. We did respectably, solving 8 of the 16 scenarios (100x and 200x)—although of course hindsight is 20/20, and I think in particular we could have pretty easily solved all the 300x scenarios. We ended up spending too much time trying to work things out mathematically and not enough just doing simulation and search (although I’m definitely biased since I’m the one who wrote a physics simulator module… =).

We used Haskell, of course, which seemed to mostly work well. I wrote our VM, and although it wasn’t blazing fast, it was fast enough for what we ended up doing with it. The only truly annoying part was serializing and deserializing IEEE doubles, since Data.Binary doesn’t use IEEE format, and I didn’t know about the data-binary-ieee754 package until too late. I ended up doing some ugliness involving ByteStrings, foreign pointers, peek and poke… yuck!

The first scenario was easy enough, using the provided information about Hohmann transfer orbits and looking up some math on computing the required vectors (my teammate Julien did most of the heavy lifting mathematics-research-wise… I just typed what he told me to =). For the second scenario, we were able to figure out how to compute the correct angle at which to initiate a Hohmann transfer in order to meet up with the second satellite, but the problem at first was that it wasn’t accurate enough—but we finally got it to work doing some simple searches with a physics simulator (after I spent two hours figuring out that negating an angle is NOT the same thing as adding pi to it!). I’m confident we could have gotten the third scenario to work similarly, by first transferring to a circular orbit tangent to an apogee of the target orbit (doing some sort of calculation/simulation to work out the timing correctly), but oh well, we didn’t get there. This is also where having more people would have helped, both to be able to code more stuff in parallel and for some fresh ideas.

But, all in all, a most enjoyable experience, and I look forward to putting together a (hopefully larger) team again next summer!

by Brent at June 29, 2009 09:41 PM

Haskell Weekly News

Haskell Weekly News: June 29, 2009

Haskell Weekly News: June 29, 2009

Welcome to issue 123 of HWN, a newsletter covering developments in the Haskell community.

A bit late this week since over the weekend I was trying to get some unruly satellites to behave (with moderate success). Anyway, some fun stuff this week: Haskell on the iPhone; new libraries for 3D animation, web development, session types; new releases of haskell-src-exts and darcs; and more. Also, if it seems that there haven't been many quotes lately, it's because people haven't been @remembering very many in #haskell. I cannot telepathically sense (via the Haskell-force, hereafter known as the "Horce") when someone says something funny.

Announcements

Haskell Symposium call for participation. Stephanie Weirich announced that registration is now open for the ACM SIGPLAN Haskell Symposium 2009, to be held on 3 September 2009 in Edinburgh, Scotland (co-located with ICFP). The purpose of the Haskell Symposium is to discuss experiences with Haskell and future developments for the language. The scope of the symposium includes all aspects of the design, semantics, theory, application, implementation, and teaching of Haskell.

jhc 0.6.1. John Meacham announced the release of jhc 0.6.1, featuring a a much simplified cross-compilation mechanism.

X Haskell Bindings 0.3. Antoine Latter announced the 0.3.* series release of the X Haskell Bindings. This release, like the prior 0.2.* series focuses on making the API prettier.

happstack-0.3.2. Matthew Elder announced the release of happstack-0.3.2, with many changes, updates, and bug fixes.

sendfile-0.1. Matthew Elder announced the release of sendfile, a library which exposes zero-copy sendfile functionality in a portable way. Right now it natively supports linux 2.6+ (maybe older too) and windows 2000+; on other platforms it will fall back seamlessly to a portable haskell implementation.

Reusable Corecursive Queues via Continuations. Leon Smith requested feedback on a draft of an upcoming article in Monad.Reader issue 14, "Lloyd Allison's Corecursive Queues: Why Continuations Matter", describing the implementation of the control-monad-queue package.

Haskell on the iPhone. Ryan Trinkle announced that his company, iPwn Studios Inc., is currently preparing to release an open source patch to GHC that allows it to output binaries for iPhone OS. The patch will be released under a BSD license as soon as possible and hopefully integrated into the GHC main-line in the near future.

Program to set the GNOME desktop background picture randomly. Colin Paul Adams announced gnome-desktop, a library which periodically picks a random picture from $HOME/Pictures, and sets it as the GNOME desktop background.

loli: a minimal web dev DSL. Jinjing Wang announced the release of loli, a web development DSL built on top of hack. It allows you to easily define routes, build your custom template backends through a simple Template interface, and integrate with other hack middleware.

Cal3D animation library. Gregory D. Weber announced the Cal3D for Haskell project, which provides a partial binding to the C++ Cal3D animation library, a platform- and graphics-API-independent C++ library for skeletal-based character animation. There are three packages available on hackage: cal3d-0.1, a Haskell binding to the Cal3D library itself; as well as cal3d-opengl-0.1 and cal3d-examples-0.1.

A Reader Monad Tutorial. Henry Laxen announced a nice Reader monad tutorial.

full-sessions: yet another implementation of session types. Keigo Imai announced the pre-release of full-sessions, yet another implementation of session types in Haskell. Session types are used to statically check the safe and consistent use of communication channels according to protocols. A notable advantage of this implementation is that it requires almost no type annotation or term annotations. and at the same time provides full functionality of session types including channel-generation and channel-passing.

darcs 2.3 beta 1. Petr Rockai announced the immediate availability of a first beta release of darcs 2.3. There are a number of improvements and bugfixes over the last stable release, 2.2 (see the announcement for a full list). Moreover, work has been done on performance of "darcs whatsnew" for large repositories. This has also introduced a slight risk of regressions, but please note that all of the disruptive changes are in read-only code paths: the new code will never touch your repository, so it is unable to cause permanent harm. The worst that could happen is that you get no or bad diff from "darcs whatsnew". Please help test it (cabal install darcs-beta)!

New release of ZeroTH. Robin Green announced a new release (2009.6.23.3) of ZeroTH, a tool for preprocessing Haskell code to run splices and remove Template Haskell dependencies. Major changes include support for more Haskell code via haskell-src-exts 1.0.0, better error messages, and librification.

Emping-0.6 and Tests/Examples. Hans van Thiel announced version 0.6 of Emping, a (prototype) interactive tool for the discovery and analysis of (universal, not statistical) predictive rules in tables of nominal data.

haskell-src-exts-1.0.0. Niklas Broberg announced the first stable release of the haskell-src-exts package, version 1.0.0! haskell-src-exts is a package for Haskell source code manipulation. In particular it defines an abstract syntax tree representation, and a parser and pretty-printer to convert between this representation and String. It handles (almost) all syntactic extensions to the Haskell 98 standard implemented by GHC, and the parsing can be parametrised on what extensions to recognise.

HaRe (the Haskell Refactorer) in action - short screencast. Claus Reinke linked to a short video showing HaRe, the Haskell refactorer, in action. HaRe still exists---but needs some love in the form of time and/or funding for maintenance and continued development.

Trivial pivoting for the DSP lu decomposition. Fernan Bolando announced the beginnings of a simple circuit simulator using haskell, which uses a modified version of the haskell DSP library matrix, extended with a simple pivoting method.

Discussion

make some Applicative functions into methods, and split off Data.Functor. Ross Paterson proposed moving several functions such as ($), (*>), and so on into their respective classes with default definitions, to allow for specialized implementations.

base library and GHC 6.12. Ian Lynagh began a discussion about how to structure the base library in the future.

Proposal: ExplicitForall. Niklas Broberg proposed adding a new GHC extension, ExplicitForall, to be used for turning on explicit 'forall' syntax in types, and to help disentangle and simplify some existing extensions.

Generic Graph Class. Ivan Lazar Miljenovic proposed a generic graph class to serve as a common interface for the many Haskell libraries that deal with graph data structures.

Type system trickery. Andrew Coppin asked how to statically ensure certain properties of recursive data structures with the type system, generating varied suggestions involving GADTs.

Blog noise

Haskell news from the blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them!

Quotes of the Week

  • gnuvince: Contributions to Hackage are measured in µConals.
  • DavidWheeler: Compatibility means deliberately repeating other people's mistakes.

About the Haskell Weekly News

New editions are posted to the Haskell mailing list as well as to the Haskell Sequence and Planet Haskell. RSS is also available, and headlines appear on haskell.org.

To help create new editions of this newsletter, please see the information on how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get http://code.haskell.org/~byorgey/code/hwn/ .

by byorgey at June 29, 2009 08:06 PM

Galois, Inc

Galois, Inc. Wins Two Small Business Research Awards from Federal Agencies

Galois, Inc., a Portland, Oregon research and development company, has been awarded two Phase I Small Business Innovative Research contracts. Galois will be engaging with the Department of Energy and the Department of Homeland Security on innovative technology solutions.

DHS Topic: Highly Scalable Identity Management Tools

Galois has been granted a Phase I SBIR from the Department of Homeland Security to develop a reusable identity management metasystem which will be designed foundationally to support government certification for deployment across agency boundaries, focusing on open standards, secure development, and a cross-domain design.

The Department of Homeland Security’s charter has a fundamental requirement to collaborate with other government agencies. Secure collaboration on this scale requires strong identity management which can “vouch for” DHS personnel working with other agencies and makes it possible to provide DHS resources to individuals in other agencies whose work requires it.

Anticipated Benefits: This work will provide an opportunity to deploy standard trusted components in a variety of agencies, each of which can continue to maintain its own method of managing identity and authorization. Agencies can share information based on this layer, which will evolve to support a wide variety of needs.

Potential commercial applications: Compliance with government standards of trustworthiness in software used for critical purposes, along with a user-centric approach to identity management, can enable Internet users to merge their many usernames and passwords, allow critical transactions to be executed with a higher degree of trust, and help bring about an environment where e-voting increases voters’ trust in the validity of the outcome of elections.

DOE Topic: Grid 2.0: Collaboration and Sharing on the Grid

Galois has been granted a Phase I SBIR from the Department of Energy to implement a Web 2.0 collaboration system based on Grid technologies. Galois’ system will allow dispersed scientific teams to collaborate effectively on large amounts of data produced by collections of networked computers.

Grid computing makes accessible significant computational and data resources to distributed teams of scientific researchers. In doing so, it also poses a challenge: How do distributed teams collaborate effectively with these resources?

The problem is determining how best to apply social and collaboration software techniques to improve the efficiency of collaboration between distributed teams working on grid systems.

Potential Commercial Applications: Grid computing is inherently social in the sense of involving multiple, loosely connected parties. Social collaboration in the area of large datasets is relevant to industrial and academic scientists.

About Galois, Inc.

Galois is a research and development company with a strong drive to transition technology from research into practice in the commercial and government sphere. Located in downtown Portland, Galois is a company of around 35 employees, including software developers, project managers, and business development personnel. Galois has experience in programming language design and compiler implementation, secure web application development, secure operating system development, and several other fields. Since its founding in 1999, Galois has been funded for R&D by members of the Intelligence Community and the DoD.  Read more about Galois’ research and technology on their web site: www.galois.com.

by Galois at June 29, 2009 05:04 PM

Greg Bacon

Cleaning up your Haskell imports

Explicit imports have a couple of benefits. For one, doing so reduces compile times with ghc. Another is giving a hand to your future self (or other maintainers) and especially to those who are reading your code to learn. We've all been there: scratching our heads wondering, ‘Where does that function live?’ Yes, ghci's :info command and Hoogle are your friends, but explicit imports right there in your code will give the answer in a snap.

Neil Mitchell calls explicit imports “needlessly verbose,” certainly a fair point in the context where he made it, so this is a matter of polish, not strict necessity. There's also a certain aspy-appeal to it.

The -ddump-minimal-imports option to ghc writes the cleaned-up list to M.imports, where M is the module being compiled. For example, consider the following code that finds anagrams in a dictionary file:

module Main where

import Control.Arrow
import Control.Monad
import Data.Char
import Data.List
import Data.Map hiding (filter, map)
import System.Environment
import System.Exit
import System.IO

usage :: IO a
usage = do
  me <- getProgName
  hPutStrLn stderr $ "Usage: " ++ me ++ " [ dictionary ]"
  exitWith (ExitFailure 1)

main :: IO ()
main =
  getPath >>= readFile >>= mapM_ (putStrLn . unwords) . sorted
  where sorted = sort . map sort . anagrams . lines

anagrams :: [String] -> [[String]]
anagrams words = filter ((>1) . length) equiv
  where equiv = elems $
                  fromListWith (++)
                    [ (normal w, [w]) | w <- words ]
        normal = sort . map toLower

getPath :: IO FilePath
getPath = getArgs >>= go
  where go [path] = return path
        go []     = return "/usr/share/dict/words"
        go _      = usage
To get the minimal set of imports:
$ ghc-6.10.3 -ddump-minimal-imports --make anagram.hs 
$ cat Main.imports
import System.IO(IO, FilePath, putStrLn, readFile, hPutStrLn,
                 stderr)
import Data.Map(elems, fromListWith)
import Control.Arrow()    -- Instances only
import Control.Monad(Monad(return, (>>=)), mapM_)
import Data.Char(String, toLower)
import Data.List((++), filter, map, length, lines, unwords, sort)
import System.Environment(getArgs, getProgName)
import System.Exit(ExitCode(ExitFailure), exitWith)
Although nice, the result is less than satisfying. The cuddled lists are ugly. The imports are in an odd order. Having to do run a separate compilation by hand followed by copy-paste, as opposed to automatically à la Eclipse's organize imports for Java, is a bit of a pain.

Notice that although Control.Arrow is unnecessary, it remains in the “minimal” set with an empty import list. Its presence is an artifact of the list comprehension being equivalent to

map (normal &&& (:[])) words
Cool, yes. Readable, not so much.

Note also there's an open ticket against ghc concerning the interaction between -ddump-minimal-imports and qualified imports.

by Greg (greg.bacon@gmail.com) at June 29, 2009 05:27 PM

Douglas M. Auclair (geophf)

Realized Constants are Comonadic

An interesting problem that often arises is "to make" constants. Put another way, it often happens that a system acquires information over time. The system may wish to formalize what it has acquired by creating a constant value.

Here's the problem, however: "Variables don't; Constants aren't"citation?

Or, put another way:

1. One man's constant is another man's variable.


To make a constant sometime down the road, as it were, in languages that have logic variables is simplicity itself: once a variable is unified with a value, it keeps that value throughout that proof.

In "pure" functional languages, that is, languages that do not have side effects, the same can be said.

What about the rest of the world? Take Java, for example. One can make a variable keep its value by declaring that variable final, but that is not helpful if we do not know what our constant value is to be at the time of object creation.

In what scenario could this possibly occur? We need a constant value, but we do not know what it is?

Actually, this situation arises quite frequently. Let's take a concrete example. You have many databases in your database management system, and at compile time you do not know on which port your DBMS is running nor do you know which database the user wishes to query. That's fine, you can lazily create the database connection and access the value through a method:

2. Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process.


But what's not fine is this: the user is data-mining, examining chunks at a time, occasionally calling for the next chunk. How does one know that one has fallen off the end of the table? A simple SELECT on the maximum indexed key will tell you that, but to do that with every query? This seems wasteful. So, once we do the query once, let's just store that value in a variable with a flag to say we've already looked it up.

That sounds suspiciously like a lazily initialized constant, right?

But here's the rub: code that sets a flag allows for other code to unset it, just as code that sets a constant value allows other code to unset that. Using just plain-old regular variables gives no guarantee that the variable, once set, stays set at that constant value.

What to do?

Well, what is the work-flow of this process? We perform an action, checking that we are still within the bounds the valid domain, but the domain only becomes valid after program start, so we cannot make the bounds constant using the final keyword on the variable. This is a very common programming action ... sort of like ... dare I say ... a design pattern. Gee, I wish there was one invented that did all this.

In fact, there does exist such a pattern, and it comes from us via Category Theory. The programming language Haskell has incorporated elements of Category theory in its use of monads and arrows, but the downside of these ways of thinking about computation is that one must "lift" the entire computation into that domain, transforming the original computation to work in that regime.

No, what is needed is something less intrusive, and I found that less intrusive thing when I read an article by sigfpe on comonadic plumbing. In this article he describes three different ways of looking at constants: 1. as a constant, 2. as the Reader Monad, 3. or as the Reader Comonad.

The first one is sometimes untenable, given the programming need, and doesn't work for our case.

The second one is useful if one is already programming in a monad. Umm ... how many OO programmers use monads? Hands up.

[sound of crickets] ... thought so.

The third one allows one to use the constant on demand. And here's the thing, the comonad is very easily comprehended: it has a value that can be extracted "down" from the comonad, it allows a value to be extended over the comonad.

This sounds, in OO parlance, very much like an object. Let's ignore the extentionability of the comonad for now and simply look at extraction (this narrowed functionality is a thing in and of itself. Objects of this type are called Copointed, but let us not be too dogmatic here). Creating such a type is simplicity itself:

> public interface Comonad<T> { public T extract(); }

Um, yawn?

But that is the power of pattern language: not the ability to create these incredibly complex things in a controlled way (they do do that), but the ability to recognize that such and so is a pattern and then encapsulate behavior into the pattern.

Using the comonad pattern, we need simply to make our "maximum row number of Table x" an implementation of the Comonad interface, and then, when we do have enough information to create the database connection (that is, we now have our domain in which our constant resides), we instantiate the comonadic object (which is that domain). Whenever extract is called, it simply returns the constant value required, with the implementation that it does a database look up the first time, then it does the internal constant value look up all other times. Since the Comonad interface does not have methods to change its internals (here), so long as one has the copointed object, the value extract has a guarantee that it remains constant.

Summary

This article examined a commonly recurring problem: one needs to constify a value at some point during a program run and guarantee that it remain constant after being created. A simplification of the comonad was offered as a pattern that is simple to define and to implement.

by geophf (doug@cotilliongroup.com) at June 29, 2009 05:25 PM

Greg Bacon

Dear Congressman Griffith

Before entering office, you gave your solemn word to support the U.S. constitution. Article I, Section 8 of that instrument invests in the Congress oversight of the currency of the United States: “The Congress shall have power to … coin money, regulate the value thereof, and of foreign coin …”

As an aside, the English verb coin has a couple of meanings. One is to stamp metal with guarantees of weight and fineness. The other is to invent out of thin air, as in “coin a phrase.” The delegates in Philadelphia clearly intended the first sense, but others have substituted the latter via stealthy amendments.

I write to urge you to join with 186 (as of this writing) of your colleagues in the people's House and cosponsor HR 1207, the Federal Reserve Transparency Act.

In earlier correspondence, you passed the buck to the Financial Services Committee, writing that you will keep my views in mind "should this legislation reach the House floor for a vote." More than forty percent of your fellows have forsaken the slick politician's fence-sitting, non-committal, wait-and-see opportunism in favor of leadership by taking clear stands.

In the same letter, you assured me that you “support the highest level of accountability.” HR 1207's sunshine on the Federal Reserve, a body that acts in your name thanks to the oath of office you took willingly, would create accountability where secrecy and subterfuge have been the standard, and your active support would demonstrate your commitment to open, honest, accountable government.

Sincerely yours,
Greg Bacon

UPDATE: Mr. Griffith has cosponsored HR 1207!

by Greg (greg.bacon@gmail.com) at June 29, 2009 01:54 PM

June 28, 2009

Magnus Therning

Making a choice from a list in Haskell, Vty (part 0)

I haven’t had much free time lately, which means I haven’t written much non-work code. The only exception is some experiments with a small piece of Haskell code using the Vty module. Many moons ago I wrote a small piece of code that let’s the user choose options from a list in a terminal. Somewhat similar to what you get using dialog --menu ..., but of course a lot more limited and less good looking.

Anyway, over the last few weeks I’ve slowly expanded it in a direction that would be useful if I ever get around to work on yet another of those projects that so far only exist in my head :-)

I’ve kept the transformations in a stack of patches using quilt, and I thought I’d write a little about them. Not because I think they are extremely useful or even good in any way, but more because I really need to get back to writing some blog posts ;-)

This is the zeroth post containing the version I put together when I first came across Vty. It is an executable program so it starts with the familiar

module Main where

Next comes a few modules that have to be imported:

import Data.Maybe
import Graphics.Vty
import qualified Data.ByteString.Char8 as B

The options are, in this version, represented as a list of strings. For now it’s enough to have a nonsensical list of unique strings.

options = [ (show i) ++ " Foo" | i <- [0..59]]

The main function is as small as possible, two rows, the first creating an instance of Vty and the second getting the choice and feeding it into print.

main = do
    vt <- mkVty
    getChoice vt options >>= print

Of course one would think that geChoice would be the meat of the code, but it is also short. After getting the size of the terminal it calls _getChoice, which is the meat of the code. The reason for this split is the handling of resize events.

getChoice vt opts = do
    (sx, sy) <- getSize vt
    _getChoice vt opts 0 sx sy

The main part of _getChoice is straight forward, first update the terminal, then wait for an event, and finally handle the event. Unless the user wants to exit (pressing enter choses an item, pressing escape exits without a choice) a recursive call is made to _getChoice with slightly modified arguments.

Probably the most complicated part is the calculation of the top of the list of visible items. The idea is that if the list has more items than there are lines in the terminal then the cursor moves down until the middle line, once there any down movement will result in the list scrolling up. This continues until the end of the list is visible, at that point the cursor moves down towards the last line in the terminal. I doubt that explanation makes sense, hopefully it’ll be clear to anyone who bothers running the code.

_getChoice vt opts idx sx sy =
    let
        _calcTop winHeight listLength idx = max 0 ((min listLength ((max 0 (idx - winHeight `div` 2)) + winHeight)) - winHeight)
        _top = _calcTop sy (length opts) idx
        _visible_opts = take sy (drop _top opts)
    in do
        update vt (render _visible_opts (idx - _top) sx)
        k <- getEvent vt
        case k of
            EvKey KDown [] -> _getChoice vt opts (min (length opts - 1) (idx + 1)) sx sy
            EvKey KUp [] -> _getChoice vt opts (max 0 (idx - 1)) sx sy
            EvKey KEsc [] -> shutdown vt >> return Nothing
            EvKey KEnter [] -> shutdown vt >> return (Just $ (idx, opts !! idx))
            EvResize nx ny -> _getChoice vt opts idx nx ny
            _ -> _getChoice vt opts idx sx sy

The final piece is the code that renders the list. The items of the list are zipped together with a list of integers. Each such tuple is then rendered into a line((The reason for the line rendering looking so complicated is that Vty requires each line to be of equal lenght.)), where the line of the cursor is highlighted. The resulting list of rendered lines is then folded into a full image.

render opts idx sx = pic {
    pImage = foldr1 (<->) $ map _render1 $ zip [0..] opts
    }
    where
        _render1 (i, o) = renderHFill attr ' ' 5 <|> renderBS (_attr i) (B.pack o) <|> renderHFill attr ' ' (sx - 5 - length o)
        _attr i = if i /= idx
            then attr
            else setRV attr

That’s it, that’s the starting point. It’s also likely to be the longest post in this planned series. :-)

by Magnus at June 28, 2009 09:17 PM

John Goerzen (CosmicRay)

Review: Google Voice

I got my Google Voice invitation over the weekend, and thought I’d share a bit about what it does and how well it works.

The Basics

The idea about Google Voice (formerly GrandCentral, which Google acquired) is this: lots of us have more than one phone, and it would be nice to have a single number to give out that will reach us on any of these phones.

So, when you sign up for Google Voice (I’ll call it GV for the rest of the article), you pick a new phone number. Then, you tell GV about your other phones. Whenever someone calls your GV number, all the phones you’ve associated with that number will ring. When you pick up at a given phone, you can talk.

As somewhat of a side benefit, you can place long distance calls to anywhere in the continental USA for free via GV, as well as call internationally for rather competitive rates.

This sounded like a great idea to me. I have a continuing problem with this. I have a cell phone, work phone, and home phone. My cell phone gets poor reception both at work and at home. Also, at home, I may leave it in the bedroom but spend most of the day downstairs, and not even hear it.

But a lot of people are confused by this. They call the cell phone only, assuming that it will reach me wherever I am. Sometimes no amount of saying “call work or home first” seems to get through, or if they do call one of those, they only leave a voicemail on the cell, which is just as bad.

So the promise of Google Voice seemed very helpful.

Voicemail

GV, of course, has to centralize your voice mail as well. When someone is transferred to your GV voice mail box, GV will record a message like usual. It has a “transcription” feature which performs speech recognition and thus presents the message in both voice and text form in various places. General word is that the transcription ranges from moderately successful to mostly useless; I haven’t had enough experience yet to weigh in.

In any case, you can get your GV voice mail in a number of places: from any telephone in a standard manner, on the website, or my email. GV will email you the transcription of the message along with a link to the audio file, if you wish. It can also send an SMS to your cellphone when you’ve been left a new voicemail at GV. In this manner, GV voice mail can be almost as tightly integrated with your mobile phone as its built-in voice mail.

Call Screening

If call screening is enabled, the first time someone from a given phone number calls you, GV asks them for their name. Then it rings you, and plays the name when you pick up, giving you the opportunity to accept or reject the call. It also remembers the name given the first time someone calls you, and never asks them for it again as long as they call from the same number.

You can turn call screening on for everyone, off for everyone, or on only for people that don’t present valid caller ID.

There are some big caveats with call screening though; I’ll mention them below.

Call Presentation

By default, when someone calls your GV number, GV presents the original caller ID to each phone. When you answer the call, you aren’t immediately connected to the person. Rather, GV plays their name (if call screening is on), then gives you a menu: press 1 to accept, 2 to send straight to voicemail, 3 to send to voicemail while you listen, and 4 to accept and record the call. (If you pick #4, both parties are informed that the call is being recorded.)

This serves both a practical and a functional purpose. Functionally, it gives you some nice options for picking up a call and restores the old answering machine feature of listening to someone as they leave a message.

Practically, it gives GV affirmation that it was a human that picked up, and not the phone’s voice mail.

You can disable call presentation for all callers, for only certain callers, or for only certain devices. However, if you do so, you run the risk that the voice mail on the device, rather than the GV voice mail, may answer.

Phones and Scheduling

You can associate as many phones as you like with your GV account. You can tell GV when to ring the phones. So, for instance, it won’t bother ringing your home phone when you’re at work. A “simple” schedule just has three options: always ring this phone, ring it only on weekends, or only on weekdays.

You can set up “custom” schedules. This lets you give specific time ranges to accept calls on weekdays or weekends. But you can’t set up, say, one schedule for Mondays, Wednesdays, and Fridays and another for Tuesdays and Thursdays. Overall, it’s fine for me, but I can imagine that it would be rather frustrating for people that work nontraditional schedules.

You can temporarily disable receiving calls on a given device, or add a new device temporarily, but you can’t temporarily override the schedule and force a device to receive calls.

Adding a new device temporarily is done from a phone. It’s useful, for instance, if you’re traveling and want to receive calls at your hotel phone.

All other changes to these settings can only be made over the Internet.

VOIP

This may be their biggest missed opportunity for right now. The only VOIP support in GV is the ability to receive GV calls with a free Gizmo5 account. You can then associate devices to your Gizmo5 VOIP “number” with SIP. So, with GV, you can receive calls on any standard SIP device.

Unfortunately, you can’t call in to GV via SIP, so if you wanted to check your voicemail from Gizmo5, you’d have to pay long-distance to Gizmo to do so.

It seems to me that it would be cheaper for Google to let me dial in to GV via SIP than to have to accept those calls via POTS.

Problems with GV

These mostly fall into the category of “obvious features that aren’t there yet”. GV is still a very new service, so I’ll cut them some slack right now. Anyhow, here are some things I’ve noticed:

Once you’ve signed up for GV, you can’t change your GV number, ever. So if you move and want a local number in your new area, you’re out of luck. You’d have to create a new Google account, which could lead to maddening amounts of logging out and back in if you use other Google services such as Gmail on the account you registered GV to in the first place.

Moreover, you can only assign one GV number to an account. So, in our case, my wife and I would have to have separate Google accounts if we each got a GV number, even though many of our contacts are the same, and we share a home phone number.

Call screening is horribly broken for a common case: callers from a corporate PBX. Many corporations present the same caller ID for any of hundreds or thousands of internal phones. The first person from that company that calls you will record a name, and from then on, you’ll hear that name announced even for the dozens or hundreds of people at that company that may call you. There is no way to override this, tell it to forget the name, or any such thing. Even if you disable call screening for unblocked numbers, it STILL announces the name it first recorded. Jarring and annoying.

You can’t port an existing number to GV, though there is some indication you may be able to do so in the future.

GV won’t attach an audio recording of a message to an email; you just get a link to the audio recording in the email, so you can’t listen to your messages when you’re offline.

Conclusion

Overall, an interesting and useful service — I plan to try it out some more. But it obviously, to me anyhow, isn’t “finished” yet.

by John Goerzen at June 28, 2009 02:25 PM

The Gentoo Haskell Team

Haskell in Gentoo

Gentoo Linux supports Haskell! #gentoo-haskell on freenode

by kolmodin at June 28, 2009 09:41 AM

Michael Snoyman

Hack Introduction

There’s been some noise- and confusion- recently about hack. Hopefully this post can address some of the issues.

What it is

Hack is a webserver interface. This means, it defines a protocol for allowing web applications to talk to different web servers. For example, I can write a web application to use the Hack protocol and then easily switch backends from CGI to FastCGI to Happstack.

Hack is authored by Jinjing Wang.

What is isn’t

  • A web server. This is just a protocol for talk