News aggregator

How to represent a list of opaque fingerprint data?

Haskell on Reddit - Wed, 10/08/2014 - 10:26am


I'm currently porting my efforts on finding function addresses in patched binaries in D to Haskell (FWIW, D:, Haskell: I do so by computing fingerprints consisting of certain characteristics for each function, its basic blocks that is.

In order not to have to save the base binary itself, I decided that every characteristic can return some opaque data in its characterize function which can later be accessed when computing the score in matchingScore.

There might be a characterizer counting instructions, where the payload might be an [Int] and another might compute a hash for early detection of unchanged functions. Both payloads are opaque to calling code. Nevertheless they should be handled in a uniform way, e.g. mappable. I figured I could use existential types for that, but it feels just wrong. Obviously, don't take the last two functions too seriously, it's just how I want to call it.

Here is what I got so far:

{-# LANGUAGE ExistentialQuantification #-} type Address = Int data Disassembly = MkDisassembly data Characterizer ch = MkCharacterizer { characterize :: Disassembly -> Address -> ch , matchingScore :: Disassembly -> Address -> ch -> Float } data GenericCharacterizer = forall ch . WrapCharacterizer (Characterizer ch) type Characterizers = [GenericCharacterizer] --computeCharacteristics :: Characterizers -> Disassembly -> Address -> [forall ch . ch] --totalScore :: Characterizers -> Disassembly -> Address -> [forall ch . ch] -> Float

I'm actually looking for design advice: As I see it, there are at least 3 different ways to achieve what I want:

  • Existentials as done here, although the last 2 functions can't function like that yet
  • Data.Dynamic
  • Data.HList.HList (only type safe solution, but also least extensible I think)

I hope I could convey what I mean. How would you design this if you knew that ch will never need to be accessed outside Characterizer functions (except for a possible serialization step later on)?

submitted by sgraf812
[link] [8 comments]
Categories: Incoming News

As a follow-up for my previous question, is this an acceptable way to encode "interferes" in Haskell?

Haskell on Reddit - Wed, 10/08/2014 - 9:36am
import Data.Array {- Hello, I'm trying to figure out how I am supposed to do "inheritance", or interfaces, in Haskell. Many solutions were suggested, but I personally tend to avoid typeclasses, so I've enjoyed this take: -} {- define a common Map interface as a type. -} data Map = Map { get :: Int -> Int, set :: Int -> Int -> Map } {- To implement a particular instance, we use another type... -} data ListMap = ListMap [Int] deriving Show {- And just a function to inject from that type into Map. -} makeMap (ListMap list) = Map { get = (list !!), set = \i x -> makeMap (ListMap (take i list ++ x : drop (i+1) list))} {- So a particular map can be created from a ListMap using makeMap. -} mp = makeMap (ListMap [0,1,4,9,16,25]) {- And it works... -} main = print $ (get mp 2, get (set mp 3 99) 3) {- Questions: 1. Is this linguistic? 2. Will I be yelled at if I do this instead of typeclasses from now on? 3. Is there any problem with this approach, in general, including performance? -} submitted by SrPeixinho
[link] [24 comments]
Categories: Incoming News

Proposal: Make a very slight change to the semantics of Data.List.isSuffixOf

libraries list - Wed, 10/08/2014 - 9:15am
Currently, isSuffixOf is defined like this: xs `isSuffixOf` ys = reverse xs `isPrefixOf` reverse ys If ys is much longer than xs, this is not so wonderful, because we have to reverse the whole spine of ys. It also will fail whenever either xs *or* ys is infinite. The following implementation seems a lot saner (although longer): isSuffixOf :: forall a . (Eq a) => [a] -> [a] -> Bool [] `isSuffixOf` _ = True needle `isSuffixOf` hay = maybe False (\fp -> needle `eq` getEndChunk hay fp) (getFrontPointer needle hay) where eq :: [a] -> [a] -> [a] (x:xs) `eq` (y:ys) = x==y && (xs `eq` ys) getEndChunk :: [a] -> [a] -> [a] getEndChunk (_:hy) (_:fp) = getEndChunk hy fp getEndChunk hy _ = hy getFrontPointer :: [a] -> [a] -> Maybe [a] getFrontPointer [] hy = Just hy getFrontPointer _ [] = Nothing getFrontPointer (_:nd) (_:hy) = getFrontPointer nd hy This doesn't do any of that crazy stuff, and it will w
Categories: Offsite Discussion

Range Performance.

Haskell on Reddit - Wed, 10/08/2014 - 8:41am

What is the difference between haskell's [x..x] and python's range()?

submitted by sprkyco
[link] [20 comments]
Categories: Incoming News

cabal sandbox: Can't load .so/.DLL for...

haskell-cafe - Wed, 10/08/2014 - 8:18am
Hi all, I have some trouble with cabal sandboxes. I used `cabal sandbox add-source` to add a library. When I add the library as a dependency for my project and try to build I’m always getting <command line>: can't load .so/.DLL for: /Users/joel/workspace/haskell/bookingsystem/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/google-maps- (dlopen(/Users/joel/workspace/haskell/bookingsystem/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/google-maps-, 9): Symbol not found: _googlezmmapszm0zi1zi0zi0_WebziGoogleziMapsziInternal_queryAPI_closure Referenced from: /Users/joel/workspace/haskell/bookingsystem/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/google-maps- Expected in: flat namespace in /Users/joel/workspace/haskell/bookingsystem/.cabal-sandbox/lib/x86_64-osx-ghc-7.8.3/google-maps- I couldn’t find a solution so far. Anyone can help
Categories: Offsite Discussion

Functional Jobs: Software Engineer / Developer at Clutch Analytics/ Windhaven Insurance (Full-time)

Planet Haskell - Wed, 10/08/2014 - 7:26am

Position Description:

Windhaven Insurance is seeking an experienced Software Engineer/ Developer to join a small elite team who are disrupting the auto insurance industry with innovative technology. You will work in a startup atmosphere as part of a subsidiary of a rapidly growing larger company. This means that along with programming, you’ll have a hand in the larger issues, such as product architecture and direction.


  • Someone who knows at least one functional language such as: Elixir, Erlang, Lisp, Scheme, Haskell, ML, Clojure, Racket, Ocaml or F#
  • Someone who ENGAGES a.k.a “gives a damn” about what we do and how technology can help make us more competitive in the marketplace.
  • Someone who COLLABORATES. We have the flattest organization in the industry designed with one main goal – the TEAM. Are you hungry to make a significant impact in the tech world?
  • Someone who RESPECTS Teammates, customers and the community.

Special Requirements:

You need to have made an achievement, in any field, of significance worth talking about, that required grit, determination and skill. This can be a personal achievement that few know about, or it could have gotten coverage by the media. It doesn’t matter, what does matter is some demonstration of grit, determination and skill. If it can be described succinctly, please describe the achievement in your cover letter, if not, be prepared to tell us all about it during the interview.

Professional & Technical Qualifications:

  • Experience with languages such as Elixir or Erlang
  • Experience with Ember.js (or Angular.js)
  • Experience with NoSQL data stores, such as Couchbase, Riak, etc.
  • DevOps experience a plus
  • Ability to explain technical issues and recommend solutions
  • Strong team player with a high degree of flexibility
  • Excellent verbal and written communication skills


Competitive salary based on experience. Benefits package includes: medical, dental, vision insurance, life insurance, short term and long term disability insurance, 401K, paid time off. EOE.

Get information on how to apply for this position.

Categories: Offsite Blogs

IO Exceptions through monad transformers stack

haskell-cafe - Tue, 10/07/2014 - 10:25pm
Hi, I’m not sure if this is the right list for “base” questions like this, if there are any more specific lists please let me know. I’m writing a parser and it works in a stack of monad transformers defined in this way: type Parser = StateT ParserState (ExceptT ParserError IO) The base monad is IO because the parse could have the need to load other files included by the file that’s being parsed. The ExceptT transformer make it easy for the lexer and the parser to signal errors. At the end I have a runParser function that compose runExceptT and evalStateT and provides me with a nice Either that contains the parsed result or a value of type ParserError. The ParserError data type is the following: data ParserError = LexingError <fields> | ParsingError <fields> Currently, whenever the parser encounter an error I simply do throwError $ ParsingError something…, for example. What I would like to do is to report in this way also the possible IO errors that can occur, by adding a IOError construc
Categories: Offsite Discussion

Fingerprinting Haskell Objects

haskell-cafe - Tue, 10/07/2014 - 9:30pm
Hello everybody, I have a little question I wanted to run by the folks here. I've run into it several times over the past few years and would love to lock down a good answer. What's the best way to "fingerprint" a Haskell object into, say, ByteString, so that this fingerprint can be used as the "lookup key" in a database (for example) and be trusted that it will remain constant over time even as the underlying libraries evolve? Here's a simple example: - Say I'm building a manual index on top of a key-value store (redis, dynamodb, etc.) - I want my keys to be arbitrary tuples (or similar records) that may contain various fields in them - I would like to avoid ad-hoc, hand-written MyTuple -> ByteString and ByteString -> MyTuple conversions. However, Generic derivations, template-haskell, etc. are acceptable - Notice how your fingerprint, which is used as a lookup key in the database, has to remain stationary. If it changes even by a single bit over time for the same MyTupl
Categories: Offsite Discussion

[help] Setting up Haskell on a Mac?

Haskell on Reddit - Tue, 10/07/2014 - 8:36pm

I've got GHCI running fine, but I'm having a hard time setting my editor. Does anyone know how? I'm super new to OSX which doesn't help.

It was easy on windows using :set editor <path>

But that isn't the case here it seems.

Also, anything else I'll need to get up and running on OSX would be awesome.

Thanks in advance.

submitted by qspec02
[link] [5 comments]
Categories: Incoming News

ANN: islink check if an HTML element is a link (useful for web scraping)

haskell-cafe - Tue, 10/07/2014 - 7:59pm
Hello everybody, I'd like to announce the first public release of islink. It's library that basically provides a list of combinations of HTML tag names and attributes that correspond to links to external resources. This includes things like ("a", "href"), ("img", "src"), ("script", "src") etc. It also comes with a convenience function to check if a particular pair (tag, attribute) corresponds to a link. This can be useful for web scraping. Here's an example how to use it to extract all (external) links from an HTML document (with the help of hxt): {-# LANGUAGE Arrows #-} import Text.Html.IsLink import Text.XML.HXT.Core
Categories: Offsite Discussion

Why haskellers tend to use data-structures directly, instead of type classes?

Haskell on Reddit - Tue, 10/07/2014 - 5:18pm

When reading Haskell code, I notice almost always Haskellers tend to use data-structures directly, as opposed to just using type classes. For example, when implementing a graphing library, one would implement a function such as:

fillRect :: Color → Bounds → Image → Image

As opposed to:

fillRect :: Image a => Color → Bounds → a → a

I see this is also recommended, if not enforced, by prelude, considering that is how it does things as well.

My problem with such approach is that, after your code is finished, if you decide to change the used structure you will have to refactor every single piece of code using it. That is completely unacceptable in 2014, even more so considering even in old languages such as C++, the whole refactoring would be a matter of changing a single line typedef.

Just, why???

submitted by SrPeixinho
[link] [26 comments]
Categories: Incoming News

Neil Mitchell: Bake - Continuous Integration System

Planet Haskell - Tue, 10/07/2014 - 3:24pm

Summary: I've written a continuous integration system, in Haskell, designed for large projects. It works, but probably won't scale yet.

I've just released bake, a continuous integration system - an alternative to Jenkins, Travis, Buildbot etc. Bake eliminates the problem of "broken builds", a patch is never merged into the repo before it has passed all the tests.

Bake is designed for large, productive, semi-trusted teams:

  • Large teams where there are at least several contributors working full-time on a single code base.
  • Productive teams which are regularly pushing code, many times a day.
  • Semi-trusted teams where code does not go through manual code review, but code does need to pass a test suite and perhaps some static analysis. People are assumed to be fallible.

Current state: At the moment I have a rudimentary test suite, and it seems to mostly work, but Bake has never been deployed for real. Some optional functionality doesn't work, some of the web UI is a bit crude, the algorithms probably don't scale and all console output from all tests is kept in memory forever. I consider the design and API to be complete, and the scaling issues to be easily fixable - but it's easier to fix after it becomes clear where the bottleneck is. If you are interested, take a look, and then email me.

To give a flavour, the web GUI looks of a running Bake system looks like:

The Design

Bake is a Haskell library that can be used to put together a continuous integration server. To run Bake you start a single server for your project, which coordinates tasks, provides an HTTP API for submitting new patches, and a web-based GUI for viewing the progress of your patches. You also run some Bake clients which run the tests on behalf of the server. While Bake is written in Haskell, most of the tests are expected to just call some system command.

There are a few aspects that make Bake unique:

  • Patches are submitted to Bake, but are not applied to the main repo until they have passed all their tests. There is no way for someone to "break the build" - at all points the repo will build on all platforms and all tests will pass.
  • Bake scales up so that even if you have 5 hours of testing and 50 commits a day it will not require 250 hours of computation per day. In order for Bake to prove that a set of patches pass a test, it does not have to test each patch individually.
  • Bake allows multiple clients to run tests, even if some tests are only able to be run on some clients, allowing both parallelisation and specialisation (testing both Windows and Linux, for example).
  • Bake can detect that tests are no longer valid, for example because they access a server that is no longer running, and report the issue without blaming the submitted patches.
An Example

The test suite provides both an example configuration and commands to drive it. Here we annotate a slightly simplified version of the example, for lists of imports see the original code.

First we define an enumeration for where we want tests to run. Our server is going to require tests on both Windows and Linux before a patch is accepted.

data Platform = Linux | Windows deriving (Show,Read)
platforms = [Linux,Windows]

Next we define the test type. A test is something that must pass before a patch is accepted.

data Action = Compile | Run Int deriving (Show,Read)

Our type is named Action. We have two distinct types of tests, compiling the code, and running the result with a particular argument. Now we need to supply some information about the tests:

allTests = [(p,t) | p <- platforms, t <- Compile : map Run [1,10,0]]

execute :: (Platform,Action) -> TestInfo (Platform,Action)
execute (p,Compile) = matchOS p $ run $ do
cmd "ghc --make Main.hs"
execute (p,Run i) = require [(p,Compile)] $ matchOS p $ run $ do
cmd ("." </> "Main") (show i)

We have to declare allTests, then list of all tests that must pass, and execute, which gives information about a test. Note that the test type is (Platform,Action), so a test is a platform (where to run the test) and an Action (what to run). The run function gives an IO action to run, and require specifies dependencies. We use an auxiliary matchOS to detect whether a test is running on the right platform:

myPlatform = Windows
myPlatform = Linux

matchOS :: Platform -> TestInfo t -> TestInfo t
matchOS p = suitable (return . (==) myPlatform)

We use the suitable function to declare whether a test can run on a particular client. Finally, we define the main function:

main :: IO ()
main = bake $
ovenGit "" "master" $
ovenTest readShowStringy (return allTests) execute

We define main = bake, then fill in some configuration. We first declare we are working with Git, and give a repo name and branch name. Next we declare what the tests are, passing the information about the tests. Finally we give a host/port for the server, which we can visit in a web browser or access via the HTTP API.

Using the Example

Now we have defined the example, we need to start up some servers and clients using the command line for our tool. Assuming we compiled as bake, we can write bake server and bake client (we'll need to launch at least one client per OS). We can view the state by visiting in a web browser.

To add a patch we can run bake addpatch --name=cb3c2a71, using the SHA1 of the commit, which will try and integrate that patch into the master branch, after all the tests have passed.

Categories: Offsite Blogs

How do I install QuickCheck?

Haskell on Reddit - Tue, 10/07/2014 - 2:21pm

I've tried using "cabal install QuickCheck" but I get this message.

Is there another way I can install QuickCheck or something I'm not doing right on the cabal install?

submitted by willrobertshaw
[link] [6 comments]
Categories: Incoming News