News aggregator

Functional Jobs: Senior Software Engineer at McGraw-Hill Education (Full-time)

Planet Haskell - Mon, 01/05/2015 - 8:15am

This Senior Software Engineer position is with the new LearnSmart team at McGraw-Hill Education's new and growing Research & Development center in Boston's Innovation District.

We make software that helps college students study smarter, earn better grades, and retain more knowledge.

The LearnSmart adaptive engine powers the products in our LearnSmart Advantage suite — LearnSmart, SmartBook, LearnSmart Achieve, LearnSmart Prep, and LearnSmart Labs. These products provide a personalized learning path that continuously adapts course content based on a student’s current knowledge and confidence level.

On our team, you'll get to:

  • Move textbooks and learning into the digital era
  • Create software used by millions of students
  • Advance the state of the art in adaptive learning technology
  • Make a real difference in education

Our team's products are built with Flow, a functional language in the ML family. Flow lets us write code once and deliver it to students on multiple platforms and device types. Other languages in our development ecosystem include especially JavaScript, but also C++, SWF (Flash), and Haxe.

If you're interested in functional languages like Scala, Swift, Erlang, Clojure, F#, Lisp, Haskell, and OCaml, then you'll enjoy learning Flow. We don't require that you have previous experience with functional programming, only enthusiasm for learning it. But if you have do some experience with functional languages, so much the better! (On-the-job experience is best, but coursework, personal projects, and open-source contributions count too.)

We require only that you:

  • Have a solid grasp of CS fundamentals (languages, algorithms, and data structures)
  • Be comfortable moving between multiple programming languages
  • Be comfortable with modern software practices: version control (Git), test-driven development, continuous integration, Agile

Get information on how to apply for this position.

Categories: Offsite Blogs

Write You a Haskell

Haskell on Reddit - Mon, 01/05/2015 - 8:01am
Categories: Incoming News

Error handling in acid-state

Haskell on Reddit - Mon, 01/05/2015 - 3:46am

Using Exceptions as a general error handling strategy within an acid-state update/query won't work, read the point about stateNestedError1 here.

Until now I have been using the following pattern for error handling:

type MyUpdate st e a = StateT st (Either e) a runMyUpdate :: MyUpdate st e a -> Update st (Either e a) runMyUpdate act = do s <- get case runStateT act s of Left e -> return $ Left e Right (x,s') -> do put s' return $ Right x setVal' :: Int -> MyUpdate Int String () setVal' 5 = throwError "wrong number" setVal' x = put x setVal :: Int -> Update Int (Either String ()) setVal = runMyUpdate . setVal' makeAcidic ''Int ['setVal]

But I realize that this will still write the failing update to the event log, so you will have a lot of transactions in the log that don't modify the state. An alternative would be for runMyUpdate to throw an Exception instead (this will be ok since the exception is not nested).

What error handling strategies are other acid-state users using?

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

Douglas M. Auclair (geophf): December 2014 1HaskellADay Problems and Solutions

Planet Haskell - Sun, 01/04/2015 - 6:31pm

December 2014
  • December 30th, 2014: Why can't we all just consensus along? for today's Haskell problem lpaste.net/117487 Pro-, con-, anti-, ... it's all sensus to me! lpaste.net/117490
  • December 29th, 2014: Uh, wait! What? It's another day? We need another #haskell puzzler? Here ya go! Rosalind subs (not grinders) http://lpaste.net/117421 Rose petals falling ... and a soution to the #rosalind subs problem http://lpaste.net/117481
  • December 24th, 2014: A||B||C == Merry Christmas for today's haskell problem http://lpaste.net/117213
  • December 23rd, 2014: Convergence, but not the movie, is today's #haskell problem http://lpaste.net/117089 A rational solution was posted by @sheshanaag at http://lpaste.net/117232 
  • December 22rd, 2014: Yesterday was about the zeroes, today's haskell problem is about the squares http://lpaste.net/116990
  • December 21nd, 2014: In which we want to have the most zeros. Fancy that! http://lpaste.net/116932 (I guess we're not playing Dodgeball, then!)
  • December 19th, 2014: A question for today's #haskell problem: how do YOUclear a Writer monad's log? http://lpaste.net/116849 A FlushableWriter solutionwas posted by @aditcr8 at http://lpaste.net/117115
  • December 18th, 2014: Why can't you spell 'PROTEIN' with proteins?lpaste.net/116723 The solution for this problem is to Eat your proteins, young man! lpaste.net/116808
  • December 17th, 2014: In which we find out that Mendel was into the Domme-scene for today's #haskell problem http://lpaste.net/116683 Whether hetero- or homo- a zygous is still a zygous... whatever that is. A solution to today's #haskell-zygous problem is posted at http://lpaste.net/116711
  • December 16th, 2014: All actors should relate to today's #haskell problem; it's all about H-A-M-M! http://lpaste.net/116578 Go HAMM it up; #Rosalind will love you. And the solution is so HAMMy! http://lpaste.net/116585
  • December 15th, 2014: Wanna Date? In which Jane Austen writes today's #haskell problem in her modern book titled: "The Hook Up" http://lpaste.net/116486 aka Pride and Prejudice. To get to our solution space, first we have to write an l-expr scanner/parser, of course. http://lpaste.net/116558
  • December 12th, 2014: In this case 'GC' does NOT mean 'garbage collection' for today's #rosalind #haskell problem lpaste.net/116305. Yeah, not garbage-collected, but a solution, nonetheless http://lpaste.net/116335 
  • December 11th, 2014: Why ... you ... wascally wabbit! Today's #haskell problem has a solution multiplying like Fibonaccis! http://lpaste.net/116216 I mean: rabbits. And speaking of rabid rabbits http://lpaste.net/116303, the solution is there. BLARGH! 
  • December 10th, 2014: "Hello, Strand, you're looking lovely in that dress!" Complimenting DNA for today's #haskell problem. http://lpaste.net/116147 No, wait: 'comPLEmenting' a strand of DNA. Sorry, Miss Rosalind! A nicely complimented solution to the DNA-complement problem posted at http://lpaste.net/116151
  • December 9th, 2014: I think this is my week with dear Rosalind: DNA-to-RNA transcriber for today's #haskell problem http://lpaste.net/116068 Another #TweetedHaskellSolution posted to http://lpaste.net/116071 for today's DNA-to-RNA transcriber
  • December 8th, 2014: Rosalind, dear Rosalie, wherefore art thou givest me bioinformatic puzzles to solve, counting nucleotides? http://lpaste.net/115961 #haskell Nucleotide-counter, HO! A nucleotide-counting solution is posted at http://lpaste.net/116011 
  • December 5th, 2014: This visit to Liar's-berg (or is it Truth-town?) we encounter only two women, so this should be 2x as easy to solve http://lpaste.net/114437 By coercion, we find that we are in Liarsberg, after all: http://lpaste.net/115769
  • December 4th, 2014: Gadzooks! It's (past) that time of day again for the daily #haskell problem. Here: eat some glow worms! http://lpaste.net/114435
  • December 3rd, 2014: Substantive citizens (with some substantive hints, for a change) for today's #haskell problem http://lpaste.net/114438
  • December 2nd, 2014: There are some curious fractions to find fromprojecteuler.net for today's #haskell problem at http://lpaste.net/114208 Asolution to this curious fraction problem is posted at lpaste.net/114209
  • December 1st, 2014: Today's Haskell problem is all about lambda-terms. It has NOTHING to do with for-loops and if-statements, ... NOT ONE BIT http://lpaste.net/115420 Solution: lpaste.net/115452 
Categories: Offsite Blogs

Christopher Done: Measuring duration in Haskell

Planet Haskell - Sun, 01/04/2015 - 6:00pm

Happy new year, everyone. It’s a new year and time for new resolutions. Let’s talk about time. Specifically, measuring it in Haskell.

A wrong solution

How do you measure how long something takes in Haskell? Here’s a naive attempt:

import Control.Exception import Data.Time main = do start <- getCurrentTime evaluate (sum [1 .. 1000000]) end <- getCurrentTime print (diffUTCTime end start)

Running it, we see that it does what we expect:

λ> main 0.316653s Inaccurate measuring

Here’s what’s wrong with this implementation:

  • The clock can be changed by the user at any moment.
  • Time synchronization services regularly update time.

If you’re on an Ubuntu desktop, time is updated when you first boot up from NTP servers. If you’re on a server, likely there is a daily cron job to update your time, because you don’t tend to reboot servers. My laptop has been on for 34 days:

$ uptime 21:13:47 up 34 days, 2:06, 3 users, load average: 0.74, 0.83, 0.84

If I run a manual update, it adjusts my clock by 500 milliseconds:

$ sudo ntpdate ntp.ubuntu.com 5 Jan 21:11:53 ntpdate[4805]: adjust time server x.x.x.x offset 0.517166 sec

Because there is a certain amount of “drift” that occurs over time.

Additionally, leap seconds can be introduced at any time and cannot be predicated systematically, but there is at least a 6 months in advance notice for time servers. In 2015 there will be an extra second added to time in-between the 30th of June to the 1st of July.

These factors mean that if our main function is run during an update, the reported time could be completely wrong. For something simple like the above, maybe it doesn’t matter. For long term logging and statistics gathering, this would represent an anomaly. For a one-off, maybe it’s forgivable, because it’s convenient. But above all, it’s simply inaccurate reporting.

Accurate measuring

Readers familiar with this problem will think back to measuring time in C; it requires inspecting the system clock and dividing by clocks per second. In fact there are a couple solutions around that use this:

  • The timeit package. This is good if your use-case is simple.
  • In turn, that package uses System.CPUTime from base, which is also handy.

These are more reliable, because the time cannot be changed. But they are limited, as both only measure CPU time and not IO time. So if your program takes 10 seconds but only does 5 seconds of CPU processing and 5 seconds of waiting for the disk, then you will not have the real time. Also known as wall time.

In the Criterion package, there’s need for fine-grained, fast, accurate measuring of both real and CPU time, so it includes its own cross-platform implementations:

That’s nice, but it’s embedded in a specific package built for benchmarking, which we may not necessarily be doing. For example, I am dabbling with a program to measure the speed of my key presses. It turns out there is a package that does similarly to Criterion, already prepared and similarly cross-platform and only depends on base and ghc-prim.

The clock package

I discovered this really nice package called clock which has the option for several time measurements:

  • Monotonic: a monotonic but not-absolute time which never changes after start-up.
  • Realtime: an absolute Epoch-based time (which is the system clock and can change).
  • ProcessCPUTime: CPU time taken by the process.
  • ThreadCPUTime: CPU time taken by the thread.

Let’s rewrite our example using this package and the formatting package (which provides a handy TimeSpec formatter as of 6.1):

{-# LANGUAGE OverloadedStrings #-} import Control.Exception import Formatting import Formatting.Clock import System.Clock main = do start <- getTime Monotonic evaluate (sum [1 .. 1000000]) end <- getTime Monotonic fprint (timeSpecs % "\n") start end

Running it, we see we get similar information as above, but now it’s accurate.

λ> main 276.05 ms

If you just want CPU time for the process, or the OS thread, just provide a different argument to getTime.

Summary

So next time you want to measure how long something takes, unless you’re doing benchmarking, check out the clock package!

Categories: Offsite Blogs

Haskell library for generating fake data

Haskell on Reddit - Sun, 01/04/2015 - 11:14am

I've noticed there is no library in Haskell for generating fake data as in other languages (Ruby - faker, ffaker, Elixir - faker, etc). So I decided that it will be good start for me as beginner in Haskell world to make project like this. It is not finished yet but I will really appreciate if you find a minute to take a look and tell what do you think and what I can improve (I know that there is a lot!). Also I will be really grateful for any other help as PRs and ideas… Here is the link https://github.com/gazay/faker

submitted by gazay
[link] [17 comments]
Categories: Incoming News

The Frank programming language

Haskell on Reddit - Sun, 01/04/2015 - 6:25am
Categories: Incoming News

FP Complete: Announcing LTS Haskell 1.0

Planet Haskell - Sun, 01/04/2015 - 5:03am

The Stackage team is happy to announce the first official LTS Haskell release, LTS Haskell 1.0. The LTS Haskell Github repository has a good overview of the project, and our initial blog post provides quite a bit more detail. To quote:

LTS Haskell: Version your Ecosystem

LTS Haskell is a curated set of packages which includes non-breaking point releases. It is a companion to Stackage Nightly: whereas Stackage Nightly releases include potentially breaking changes with each new release, LTS Haskell maintains major version stability for a longer period of time.

The plan for LTS 1 is:

  • Run weekly point releases. The first point release, LTS Haskell 1.1, will be run on Sunday, January 11.
  • Continue running these releases until LTS 2 is released, scheduled for April 1.
  • Like all Stackage snapshots, each release will be available for usage in perpetuity going forward. The only timeline is how far into the future we will continue generating patch releases.

As discussed previously, we are aware that three months is not really "long term support." The reason for the short terms here is so that we can shake out the process well for this first release. If things go exceptionally well and there is community desire to change the planned dates, we will certainly discuss it.

If you want the incredibly short guide to using this release, just run the following in your project:

wget http://www.stackage.org/lts/1.0/cabal.config

In the future, when you want to upgrade to a new point release, just delete your old cabal.config and download the latest point release, e.g.:

wget http://www.stackage.org/lts/1/cabal.config

Your code should continue compiling against the new snapshot without any code changes, barring typical caveats of the PVP (unqualified import lists, mistakes by authors, etc).

Together with this release, we're also announcing some improvements to Stackage Server around hosted documentation to make LTS Haskell more useful.

Full module listing

The main page for LTS Haskell 1.0 contains a listing of all packages, their version numbers, and- where available- a link to documentation. (Documentation may not be available if the package only contains executables, or if there is a bug in the Haddock markup in the package.)

We've now added one more feature: a full module listing. This allows you to view all available modules and easily determine which package provides a module.

If you are using LTS Haskell for your projects, I strongly encourage you to use the stackage.org hosted documentation when looking things up, for one simple reason: you're guaranteed that links to other packages will include versions that are also part of the LTS Haskell release set. (The same logic applies to Stackage Nightly releases.)

All of this adds up to a hopefully more pleasant way of thinking about the Haskell library ecosystem: instead of a huge number of individual packages whose individual modules and changesets you need to keep in your head, relying on an LTS Haskell release reduces it all to a single version number for "my Haskell ecosystem," with a massive number of modules at your disposal to write your applications.

Experimental Hoogle support

FP Complete has hosted a Hoogle service for a few years now. This Hoogle provides access to the full FP Haskell Center library set. I personally use this service on an almost daily basis, as I know many others do as well. However, the FP Haskell Center package sets are not completely in sync (yet) with LTS Haskell releases, and therefore the documentation can be slightly out of date.

So to address that, we've added Hoogle search support to stackage.org as well. You can go to any snapshot page- including LTS Haskell 1.0- and perform a Hoogle search. This search will encompass the entirety of the package set. As usual, a big thank you goes to Neil for providing such an awesome tool to the community.

And since I brought it up: FP Complete does intend to synchronize the FP Haskell Center library set with LTS Haskell releases. That will take a little bit longer, but we'll make an announcement when it's ready.

Dive in!

LTS Haskell is out. I'm already using it, and given the minor delta from how Stackage Nightlies work, I believe it should present no hurdles for greater adoption. The community process of dealing with patch releases will be an interesting adventure that I'm looking forward to. Please give this a spin, provide feedback, and let's make a solid, stable basis for doing Haskell development!

Categories: Offsite Blogs

Is there anything planned to solve the orphan instances problems ?

Haskell on Reddit - Sun, 01/04/2015 - 4:57am

The question is in the title, is any body working on how to solve the orphan instances problem ?

I mean, it seems doable to have a way of non exporting (or hidding) an orphan instance, or to have to export orphan instance explicitely

example

module MonoInt ( instance Monoid Int ) import Monoid instance Monoid Int where ...

Is just a syntax problem, a backward compatibility problem, a much more complicated problem, or nobody cares : people are happy with newtype and GeneralizedNewtypeDeriving (I'm not)?

submitted by maxigit
[link] [36 comments]
Categories: Incoming News

www.jdon.com

del.icio.us/haskell - Sun, 01/04/2015 - 1:02am
Categories: Offsite Blogs

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!

~d

Categories: Incoming News