- Haskell-Cafe - Haskell.org

Slow mvar when compiled with threaded
by Branimir Maksimovic 10 Jan '14

10 Jan '14

I have test network client, something like apache bench tool. It uses mvars to synchronize and everything is ok when compiled without -threaded. real 0m2.995s user 0m0.601s sys 0m2.391s With -threaded compile option result is following: real 0m18.196s user 0m2.054s sys 0m3.313s Seems that program is sleeping most of the time for some reason. I can't explain behavior as it seems that program is ok. It starts `concurrency` threads which wait on mvar to process next task. Program follows: {-# Language OverloadedStrings #-} import System.CPUTime import System.IO --import System.IO.Error import Network.Socket hiding(recv) import Network.Socket.ByteString import System.Environment import Control.Concurrent import Control.Exception main = do n <- getArgs let (host,port,conc,reqs) = parse n putStrLn $ "Connecting to " ++ host ++ " " ++ port s <- getAddrInfo Nothing (Just host) (Just port) let servAddr = head s begin <- getCPUTime process servAddr conc reqs end <- getCPUTime let diff = (fromIntegral (end - begin))/(10^12) :: Double putStrLn $ show (round (fromIntegral reqs / diff)) ++ " r/s" parse [h,p,conc,reqs] = (h,p,read conc::Int,read reqs::Int) parse _ = error "usage client host port concurrency requests" process servAddr conc reqs = do let niter = if reqs >= conc then conc else reqs putStrLn $ "loop " ++ show niter mvars <- initThreads niter [] putStrLn $ "Initialized " ++ show niter let loop n (m:mvs) f | n>0 = do flag <- isEmptyMVar m if f > length mvars then putStrLn "busy" else return () if flag || f > length mvars then do putMVar m () loop (n-1) mvs 0 else loop n mvs (f+1) | otherwise = return () loop n [] f = if n>0 then loop n mvars f else return () putStrLn $ "length " ++ show (length mvars) loop (reqs-niter) mvars 0 where initThreads niter vars | niter > 0 = do mvar <- newMVar () forkIO $ process mvar initThreads (niter-1) (mvar:vars) | otherwise = return vars process mvar = do sock <- socket (addrFamily servAddr) Stream defaultProtocol connect sock (addrAddress servAddr) sendAll sock "Hello World!\n" buf <- recv sock 1024 close sock takeMVar mvar process mvar

2 8

Re: [Haskell-cafe] Why Maybe exists if there is Either?
by Niklas Larsson 09 Jan '14

09 Jan '14

Maybe doesn't have to be used for error reporting. Optional values is a very big use case for it. ----- Ursprungligt meddelande ----- Från: "Vlatko Basic" <vlatko.basic(a)gmail.com> Skickat: ‎2014-‎01-‎09 16:37 Till: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> Ämne: Re: [Haskell-cafe] Why Maybe exists if there is Either? Hi Daniel, > If you just want to signalize a fail case without any additional > information, then a Maybe fits better than an Either, because > why should you need this bogus empty string? Now it looks to me that it might be better and more consistent to write an empty bogus string (as with: nothing = Left "") than to have two distinct ways of error reporting, and both are used widely and often should be intermixed. And at the end, call site could decide does it want to use the string or not. vlatko -------- Original Message -------- Subject: Re: [Haskell-cafe] Why Maybe exists if there is Either? From: Daniel Trstenjak <daniel.trstenjak(a)gmail.com> To: haskell-cafe(a)haskell.org Date: 09.01.2014 16:13 > > Hi Vlatko, > > On Thu, Jan 09, 2014 at 03:50:16PM +0100, Vlatko Basic wrote: >> I'm curious to find out what was the reasoning to make Maybe? >> What is the added value with introducing it? >> In which situations the above substitution does not hold? > > If you just want to signalize a fail case without any additional > information, then a Maybe fits better than an Either, because > why should you need this bogus empty string? > > How should you know that the string doesn't contain something relevant? > > > Greetings, > Daniel > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

4 3

How to determine the right path to haddock html documentation?
by Carlo Hamalainen 09 Jan '14

09 Jan '14

Hi, I'm writing a patch for ghcmod-vim so that a user can look up the haddock html documentation for a symbol. My code makes three system calls, e.g. to look up "Just" it does: $ ghc-mod info foo.hs Foo Just data Maybe a = ... | Just a -- Defined in `Data.Maybe' $ ghc-pkg find-module Data.Maybe --simple-output haskell2010-1.1.1.0 base-4.6.0.1 $ ghc-pkg field base-4.6.0.1 haddock-html haddock-html: /home/carlo/opt/ghc-7.6.3_build/share/doc/ghc/html/libraries/base-4.6.0.1 Then "Data.Maybe" is changed to Data-Maybe.html" and appended to the haddock-html value. But this procedure doesn't work in general, for example when looking up String: $ ghc-mod info foo.hs Foo String type String = [Char] -- Defined in `GHC.Base' $ ghc-pkg find-module GHC.Base /home/carlo/opt/ghc-7.6.3_build/lib/ghc-7.6.3/package.conf.d base-4.6.0.1 /home/carlo/.ghc/x86_64-linux-7.6.3/package.conf.d $ ghc-pkg field base-4.6.0.1 haddock-html haddock-html: /home/carlo/opt/ghc-7.6.3_build/share/doc/ghc/html/libraries/base-4.6.0.1 $ ls /home/carlo/opt/ghc-7.6.3_build/share/doc/ghc/html/libraries/base-4.6.0.1/GHC-Base.html ls: cannot access /home/carlo/opt/ghc-7.6.3_build/share/doc/ghc/html/libraries/base-4.6.0.1/GHC-Base.html: No such file or directory because the html is in the src subdirectory: $ ls /home/carlo/opt/ghc-7.6.3_build/share/doc/ghc/html/libraries/base-4.6.0.1/src/GHC-Base.html /home/carlo/opt/ghc-7.6.3_build/share/doc/ghc/html/libraries/base-4.6.0.1/src/GHC-Base.html But this isn't even the right place to go, one should look at the Prelude file http://hackage.haskell.org/package/base-4.6.0.1/docs/Prelude.html#t:String which is what Hoogle suggests. How does Hoogle get it right? It looks like haskell-mode for emacs runs into a similar problem: https://github.com/haskell/haskell-mode/blob/master/inf-haskell.el#L734-L740 ------------------------------- (defvar inferior-haskell-ghc-internal-ident-alist ;; FIXME: Fill this table, ideally semi-automatically. '(("GHC.Base.return" . "Control.Monad.return") ("GHC.List" . "Data.List"))) (defun inferior-haskell-map-internal-ghc-ident (ident) "Try to translate some internal GHC identifier to its alter ego in haskell docs." ------------------------------- Thanks, -- Carlo Hamalainen http://carlo-hamalainen.net

3 9

Altering Class hierarchy
by Frantisek Farka 09 Jan '14

09 Jan '14

Hi all, I was toying with Haskell classes and came across Functor-Applicative-Monad proposal[1]. It shows out that adding a super class (Applicative) to a class (Monad) is not an easy task when the class hierarchy is already in use. In this case it result in stepwise approach (step1 e. g. [2]) in order not to break already existing code which uses Monad. I am interested in other examples of such changes. Which alterings of your class hierarchy do you usually need when rewriting your code? I don't mean only adding superclass here, other modifications could be also handy, e. g. dropping out a class or splitting a class into two. Can you point me to some actual examples on real source code? How do you deal with this kind of problem on your projects? Thanks for a reply :) FF [1] http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal [2] https://ghc.haskell.org/trac/ghc/ticket/8004

2 1

ANN: MiniAgda-0.2014.1.9 Toy language with dependent and sized types
by Andreas Abel 09 Jan '14

09 Jan '14

For what it's worth, I finally uploaded MiniAgda to hackage. If you want to play around with type-based termination and coinduction in a dependently-typed setting, try: cabal install MiniAgda Some examples and pointers to literature are (still) on my old homepage: http://www2.tcs.ifi.lmu.de/~abel/miniagda/ Source code and issue tracker are on the darcs hub: http://hub.darcs.net/abel/miniagda/ Have fun playing (or despair of the horrible error messages), and have a happy new year, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch.

1 0

Drop or update the upper bounds of numerals and numerals-base
by Nikita Karetnikov 09 Jan '14

09 Jan '14

I’ve built both packages locally, and they seem to work fine with GHC 7.6.3. However, I can’t install them from Hackage due to the required dependencies. Could anyone drop or update the upper bounds? Alternatively, I could try to do so myself if someone provides the required permissions.

5 5

Class Instance with ExistentialQuantification
by Andrew Gibiansky 08 Jan '14

08 Jan '14

Why is the following not allowed? {-# LANGUAGE ExistentialQuantification, ExplicitForAll, RankNTypes, FlexibleInstances #-} class Class a where test :: a -> Bool instance Class (forall m. m -> m) where test _ = True main = do putStrLn $ test id Is there a reason that this is forbidden? Just curious. -- Andrew

4 5

ANN: cheapskate 0.1, markdown parser
by John MacFarlane 08 Jan '14

08 Jan '14

I've released a new markdown library on Hackage: http://hackage.haskell.org/package/cheapskate This library is designed to be used in web applications. It is small, accurate, and fast, in pure Haskell with few dependencies. All output is sanitized through a whitelist by default. It is designed to have performance that varies linearly with the input size, even with garbage input. To illustrate: % head -c 100000 /dev/urandom | iconv -f latin1 -t utf-8 | time cheapskate >/dev/null cheapskate > /dev/null 0.15s user 0.01s system 82% cpu 0.199 total % head -c 1000000 /dev/urandom | iconv -f latin1 -t utf-8 | time cheapskate >/dev/null cheapskate > /dev/null 1.53s user 0.03s system 88% cpu 1.770 total % head -c 10000000 /dev/urandom | iconv -f latin1 -t utf-8 | time cheapskate >/dev/null cheapskate > /dev/null 15.50s user 0.20s system 89% cpu 17.632 total This is a test that many markdown parsers fail (including my own pandoc and the markdown package on Hackage). Performance is about seven times faster than pandoc (with five times less memory used), and about 25% faster than the markdown package on Hackage. Generic functions are provided that allow transformations of the AST prior to rendering (e.g., promotion of headers, insertion of syntax highlighting, or the conversion of specially marked code blocks into diagrams). Several markdown extensions are supported, and sensible decisions have been made about several aspects of markdown syntax that are left vague by John Gruber's specification. For details, see the README at https://github.com/jgm/cheapskate.

3 4

Right approach to profiling and optimizing a concurrent data structure?
by Brandon Simmons 08 Jan '14

08 Jan '14

Happy New Year, all, I started what I thought would be a pretty straightforward project to implement a concurrent queue (with semantics like Chan) which I hoped would be faster, but the process of trying to measure and test performance has been super frustrating. I started with a really big criterion benchmark suite that ran through a bunch of Chan-like implementations as well as comparing different var primitives; I was compiling that with `-O2 -threaded` and running with +RTS -N (as that seemed realistic, and results were very consistent). Short version: at some point I realized I had (in my cabal config) enabled executable-profiling, which when disabled completely changed all timing and actually *hurt* performance. Then after a lot more head-banging I realized that +RTS -N seems to run on only one core when compiled with -prof (I didn't see that documented anywhere) although I could *force* the -prof version to use more with -N2, and so apparently for my tests[1], running on a single core just *happened* to be faster (I can see why it might; I probably can't expect a speedup when I'm just measuring throughput). I'd be interested in any comments on above, but mostly I'm trying to understand what my approach should be at this point; should I be benchmarking on 1 core and trying to maximize throughput? Should I also profile on just 1 core? How should I benchmark the effects of lots of contention and interpret the results? How can I avoid benchmarking arbitrary decisions of the thread scheduler, while still having my benchmarks be realistic? Are there any RTS flags or compile-time settings that I should *definitely* have on? Thanks for any clarity on this, Brandon http://brandon.si [1] Here's the test I used while most of the forehead-bloodying occurred, here using `Control.Concurrent.Chan`; for no combination of readers/writers/messages could I manage to get this going as fast on 2 cores as on the single-core bound -prof version runC :: Int -> Int -> Int -> IO () runC writers readers n = do let nNice = n - rem n (lcm writers readers) perReader = nNice `quot` readers perWriter = (nNice `quot` writers) vs <- replicateM readers newEmptyMVar c <- C.newChan let doRead = replicateM_ perReader $ theRead theRead = C.readChan c doWrite = replicateM_ perWriter $ theWrite theWrite = C.writeChan c (1 :: Int) mapM_ (\v-> forkIO (doRead >> putMVar v ())) vs replicateM writers $ forkIO $ doWrite mapM_ takeMVar vs -- await readers

2 1

ICFP 2014: Call for papers
by David Van Horn 08 Jan '14

08 Jan '14

===================================================================== 19th ACM SIGPLAN International Conference on Functional Programming ICFP 2014 Gothenburg, Sweden, 1-3 September 2014 http://www.icfpconference.org/icfp2014 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Submissions due: Saturday, 1 March 2014, 23:59 UTC-11 (anywhere in the world) Author response: Wednesday, 23 April, 2014 Friday, 25 April, 2014 Notification: Monday, 5 May, 2014 Final copy due: Wednesday, 11 June, 2014 Scope ~~~~~ ICFP 2014 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency and distribution; modules; components and composition; metaprogramming; interoperability; type systems; relations to imperative, object-oriented, or logic programming * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types * Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security * Education: teaching introductory programming; parallel programming; mathematical proof; algebra * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By Saturday, 1 March 2014, 23:59 UTC-11 (anywhere in the world), submit a full paper of at most 12 pages (6 pages for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication * Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available: http://www.acm.org/sigs/sigplan/authorInformation.htm Submission: Submissions will be accepted on the web at https://www.easychair.org/conferences/?conf=icfp2014 . Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 0:00 UTC-11 on Wednesday, 23 April 2014, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for fee downloads from the ACM DL. General Chair: Johan Jeuring, Utrecht University Program Chair: Manuel Chakravarty, University of New South Wales Program Committee: Edwin Brady, University of St Andrews Derek Dreyer, Max Planck Institute for Software Systems Ralf Hinze, University of Oxford Zhenjiang Hu, National Institute of Informatics Patricia Johann, Appalachian State University Ken Larsen, University of Copenhagen Yukiyoshi Kameyama, University of Tsukuba Anil Madhavapeddy, University of Cambridge Geoffrey Mainland, Drexel University David Mazières, Stanford University Jay McCarthy, Brigham Young University Matthew Might, University of Utah Ulf Norell, Chalmers University of Technology Tiark Rompf, Swiss Federal Institute of Technology in Lausanne Chung-chieh Shan, Indiana University Mary Sheeran, Chalmers University of Technology Matt Sottile, Galois Don Syme, Microsoft Research Jesse Tov, Harvard University

1 0