News aggregator

Jan Stolarek: Two new libraries to extend tasty testing framework

Planet Haskell - Tue, 02/04/2014 - 6:43am

When I recently wrote about porting my haskell-testing-stub project to tasty I mentioned that test-framework still has more libraries than tasty. I decided to contribute to changing that and released two small packages that extend tasty with extra functionality:

  • tasty-hunit-adapter allows to import existing HUnit tests into tasty (hackage, github): module Main where   import Test.HUnit ( (~:), (@=?) ) import Test.Tasty ( defaultMain, testGroup ) import Test.Tasty.HUnit.Adapter ( hUnitTestToTestTree )   main :: IO () main = defaultMain $ testGroup "Migrated from HUnit" $ hUnitTestToTestTree ("HUnit test" ~: 2 + 2 @=? 4)
  • tasty-program allows to run external program and test whether it terminates successfully (hackage, github): module Main ( main ) where   import Test.Tasty import Test.Tasty.Program   main :: IO () main = defaultMain $ testGroup "Compilation with GHC" $ [ testProgram "Foo" "ghc" ["-fforce-recomp", "foo.hs"] Nothing ]
  • This package has only this basic functionality at the moment. A missing feature is the possibility of logging stdout and stderr to a file so that it can later be inspected or perhaps used by a golden test (but for the latter tasty needs test dependencies).

Categories: Offsite Blogs

5th Answer Set Programming Competition 2014 - CALL FORPARTICIPANTS

General haskell list - Tue, 02/04/2014 - 12:50am
[apologies for any cross-posting] ======================================================================== ================================================================== 5th Answer Set Programming Competition 2014 Call for Participant Systems Aalto University, University of Calabria, University of Genova Spring/Summer 2014 https://www.mat.unical.it/aspcomp2014 aspcomp2014< at >mat.unical.it ================================================================== Special edition of the ASP competition series -system track- part of the Olympic Games of the Vienna Summer of Logic 2014 == Important Dates == * March 1st, 2014: Participant registration opens * March 31st, 2014: The competition starts * July 2014: Awards are presented at FLoC (22nd) and at ICLP (19th-22nd) ======================================================================== Answer Set Programming (ASP) is a well-established
Categories: Incoming News

Yesod Web Framework: conduit 1.0.13 and ZipSource

Planet Haskell - Tue, 02/04/2014 - 12:41am

A few months ago, Petr Pudlák kicked off the conduit-extra package with the addition of ZipSink. As a refresher, ZipSink provides an alternative Applicative instance for Sink which allows multiple Sinks to consume the same stream.

I've just release version 1.0.13 of conduit which promotes ZipSink from conduit-extra into conduit itself. This abstraction has proven to be generally useful, and I hope others enjoy it as well. If you want a more in-depth review of it, please see the original blog post. The only change since then is renaming broadcast to sequenceSinks.

Along with this change, version 1.0.13 adds a new, similar concept: ZipSource and sequenceSources. The idea here is to combine together multiple streams, instead of sequencing one stream after another.

As a simple motivating example, let's say we have some files on the filesystem, where each file contains a list of student test scores. We want to combine together the test scores for all students for each of the tests. The following program does the job:

import Control.Monad.Trans.Class (lift) import qualified Data.ByteString.Char8 as S8 import Data.Conduit import qualified Data.Conduit.Binary as CB import qualified Data.Conduit.List as CL import qualified Data.Map as Map type Name = String people :: [Name] people = words "alice bob charlie" files :: Map.Map Name FilePath files = Map.fromList $ map (\name -> (name, name ++ ".txt")) people scores :: MonadResource m => FilePath -> Source m Int scores fp = CB.sourceFile fp $= CB.lines $= CL.map (read . S8.unpack) sources :: MonadResource m => Map.Map Name (Source m Int) sources = fmap scores files sources' :: MonadResource m => Source m (Map.Map Name Int) sources' = sequenceSources sources main :: IO () main = runResourceT $ sources' $$ CL.mapM_ (lift . print)

The important bit is the definition of sources'. We use sequenceSources to combine together each of the individual test scores into a single test score map. With some basic input files, the output looks like:

fromList [("alice",1),("bob",3),("charlie",2)] fromList [("alice",2),("bob",2),("charlie",2)] fromList [("alice",3),("bob",1),("charlie",2)]
Categories: Offsite Blogs

ANNOUNCE: GHC 7.8.1 Release Candidate 1

glasgow-user - Tue, 02/04/2014 - 12:35am
We are pleased to announce the first release candidate for GHC 7.8.1: http://www.haskell.org/ghc/dist/7.8.1-rc1/ http://www.haskell.org/ghc/docs/7.8.1-rc1/html/ This includes the source tarball and bindists for Windows, Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of the SHA256 hashes available (attached) using my GPG key (keyid 0x3B58D86F). We plan to make the 7.8.1 RC2 release quite soon, as we're aware of some existing issues. Please test as much as possible; bugs are much cheaper if we find them before the release!
Categories: Offsite Discussion

CTO Opportunity

haskell-cafe - Mon, 02/03/2014 - 11:19pm
My name is Charles Weitzer. I do recruiting for major quantitative hedge funds worldwide. I have a client, a startup quantitative hedge fund located in Northern California, that would like to hire a Chief Technology Officer as soon as possible. Their job description can be found below. * Chief Technology Officer Fast-growing science and technology driven company seeks a Chief Technology Officer. We apply statistical machine learning to develop automated trading systems. We are a growing group of exceptional software and infrastructure professionals and seek an experienced candidate to lead and grow the team. The CTO will manage the implementation of our next generation infrastructure, including production trading systems, software infrastructure for our research department, and our compute and storage hardware systems. The CTO will work directly with the Head of Research and the CEO to set the technical direction of the company. A strong candidate will be well-versed in state-of-the-art technology (pa
Categories: Offsite Discussion

www.soi.city.ac.uk

del.icio.us/haskell - Mon, 02/03/2014 - 5:45pm
Categories: Offsite Blogs

Well-Typed.Com: GHC 7.8 first release candidate

Planet Haskell - Mon, 02/03/2014 - 4:30pm

This is the first blog post by our colleague Austin. Austin is one of our GHC engineers, part of the GHC HQ team and carries the heavy burden of being GHC release manager.

Today, GHC 7.8.1 RC1 has been released after many months of work, with a huge number of new features.

There are some great highlights in the new release, including:

  • A host of I/O manager improvements, which results in significantly better scalability on multicore machines (up to 32 to 40 cores).
  • The new code generator is now live. There are some new and improved optimizations, like better support for turning self-recursive tail calls into loops. Along with that, there's some preliminary support for SIMD operations in the LLVM backend, and other optimization improvements.
  • Improvements to the compiler and build system, including a parallel ghc --make -j, and significantly better (but not yet perfect) cross compilation support. We've also merged full iOS support, so it should be possible to build an iOS compiler with the main tree.
  • Dozens of other improvements, new features, and tons of fixed bugs (OS X 10.9 support, dynamic GHCi, Applicative-Monad warnings, etc).

See the release notes for the full details.

You can download the sources or pre-built binaries for your platform.

How big has this release been? The other day I did an approximated diffstat between the 7.6 and 7.8 branches:

2784 non-merge changesets 964 files changed, 99952 insertions(+), 116187 deletions(-)

That's just in GHC itself, not including the extra repositories. We've had contributions from over 70 people this release, including 15 new committers in 2013 and 2014. As always, GHC HQ and our many other contributors have yet more stuff planned for the future (Overloaded Record Fields, Applicative Do, further integer-gmp optimizations, and more type system features).

This release includes over a year of hard work by many people, and hopefully it will turn out to be a great release (finally). But please try the RC — it's much easier for us to fix bugs before it's done!

And on that note: we're planning on doing an RC2 soon, as we know there are some current issues for people using platforms like OS X Mavericks, and packages like lens. As we've learned, there's eventually diminishing returns, so we're getting it out now in the hopes we can swat the last few things swiftly with your help.

Categories: Offsite Blogs

STM and unsafePerformIO/bracket

haskell-cafe - Mon, 02/03/2014 - 12:50pm
I’ve run into a difficulty I’d appreciate some advice to solve. I am trying to make a call to C (through the FFI) within an STM transaction to compute what is effectively a pure result. By itself this doesn’t seem to be a problem, except that the C function depends on some global state in a way that compromises thread safety, and so I would like to serialize the process of setting up that state and calling the FFI. I have tried wrapping my call up with: This seems to work as intended, with one significant exception. If the surrounding STM transaction is aborted (i.e. because of a TVar conflict detected by another thread) while inside the bracket, then apparently the second argument to ‘bracket’ may never be evaluated, leaving my ‘lock’ mutex forever empty, and eventually causing deadlock. Here is a working example of the problem: http://lpaste.net/99399 When I run that, I get: taking lock... lock acquired taking lock... stm-test: thread blocked indefinitely in an MVar operatio
Categories: Offsite Discussion

test build of current ghc-7.8

glasgow-user - Mon, 02/03/2014 - 12:49pm
Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21 devel, which I think should also install to Fedora 20. I put the packages for x86_64, i386 and armv7hl into the yum repos under http://repos.fedorapeople.org/repos/petersen/ghc-7.7/ I haven't tested this latest build yet but wanted to announce its availability. Let me know if you hit any packaging problems with it. Jens ps I also upload the ghc-7.8.0.20140201 src tarball to http://petersen.fedorapeople.org/ghc/ if you want to use to build yourself. pps Next time I will build it in copr.fedoraproject.org which creates yum repos for one (like OBS). [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6483032 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Categories: Offsite Discussion

A new yaml module

haskell-cafe - Mon, 02/03/2014 - 10:57am
The yaml package[1] currently provides two modules. Text.Libyaml is a lower level, streaming API which is essentially a raw exposure of the underlying libyaml C library. Data.Yaml uses the aeson Value data type and ToJSON/FromJSON type classes for higher level serialization. For many cases, this approach works well, though there are problems: * There are problems with roundtripping, since YAML allows for ambiguity about the data type of values[2]. For example, in the yaml snippet `foo: 1234`, is 1234 intended to be numeric or a string? Either is valid. * YAML is intended to be human-readable output. But Data.Yaml provides no control over the encoded representation, e.g. should we use single or double quotes for a string (or no quotes at all), or the order of values in a mapping[3]. For other examples, just look at the issue tracker for yaml[4]. I don't want to drop the current aeson-based functionality, since I think it's still valid and useful in many cases. But I do think it's worthwhile to add in an al
Categories: Offsite Discussion

Brandon Simmons: Thoughts on FIFO-ness

Planet Haskell - Mon, 02/03/2014 - 10:28am

I’ve been doing a lot of experimenting with concurrent operations in haskell and in particular playing with and thinking about the design of concurrent FIFO queues. These structures are difficult to make both efficient and correct, due to the effects of contention on the parts of the structure tasked with coordinating reads and writes from multiple threads.

These are my thoughts so far on FIFO semantics.

FIFO? And how!

In the interesting paper “How FIFO is your concurrent FIFO queue?”(PDF). A Haas, et al. propose that an ideal FIFO queue has operations that are instantaneous (think of each write having an infinitely accurate timestamp, and each read taking the corresponding element in timestamp order). They then measure the degree to which real queues of various designs deviate from this platonic FIFO semantics in their message ordering, using a metric they call “element-fairness”. They experimentally measure element-fairness of both so-called “strict FIFO” as well as “relaxed FIFO” designs, in which elements are read in more or less the order they were written (some providing guarantees of degree of re-ordering, others not).

The first interesting observation they make is that no queue actually exhibits FIFO semantics by their metric; this is because of the realities of the way atomic memory operations like CAS may arbitrarily reorder a set of contentious writes.

The second interesting result is that the efficient-but-relaxed-FIFO queues which avoid contention by making fewer guarantees about message ordering often perform closer to ideal FIFO semantics (by their metric) than the “strict” but slower queues!

Observable FIFO Semantics

As an outsider, reading papers on FIFO queue designs I get the impression that what authors mean by “the usual FIFO semantics” is often ill-defined. Clearly they don’t mean the platonic zero-time semantics of the “How FIFO… ” paper, since they can’t be called FIFO by that measure.

I suspect what makes a queue “strict FIFO” (by the paper’s categorization) might simply be

If write x returns at time T, then x will be read before the elements of any writes that have not yet started by time T.

The idea is difficult to express, but is essentially that FIFO semantics is only observable by way of actions taken by a thread after returning from a write (think: thread A writes x, then tells B which writes y, where our program’s correctness depends on the queue returning y after x). Note that since a queue starts empty this is also sufficient to ensure writes don’t “jump ahead” of writes already in the queue.

Imagine an absurd queue whose write never returns; there’s very little one can say for certain about the “correct” FIFO ordering of writes in that case, especially when designing a program with a preempting scheduler that’s meant to be portable. Indeed the correctness criterion above is actually probably a lot stricter than many programs require; e.g. when there is no coordination between writers, an observably-FIFO queue need only ensure that no reader thread sees two messages from the same writer thread out of order (I think).

The platonic zero-time FIFO ordering criterion used in the paper is quite different from this observable, correctness-preserving FIFO criterion; I can imagine it being useful for people designing “realtime” software.

Conclusion

At a certain level of abstraction, correct observable FIFO semantics shouldn’t be hard to make efficient; after all, the moments during which we have contention (and horrible performance) are also the moments during which we don’t care about (or have no way of observing) correct ordering. In other words (although we have to be careful of the details) a thread-coordination scheme that breaks down (w/r/t element-fairness) under contention isn’t necessarily a problem. Compare-and-swap does just that, unfortunately it breaks down in a way that is slower rather than faster.

Categories: Offsite Blogs