February 2013 - Haskell-Cafe

tplot (out of memory)
by Manish Trivedi 27 Feb '13

27 Feb '13

Hi, I am running into a weird out of memory issue. While running timeplot over an input file having ~800 rows. From below provided info, seems like machine has enough ram (1849MB). Please let me know if anyone has pointers. * # free -m * total used free shared buffers cached Mem: 3825 1975 1849 0 13 71 -/+ buffers/cache: 1891 1934 Swap: 4031 111 3920 *#time tplot -o out.png -or 1024x768 -k 'CurrentPerHour' 'lines' -k 'RequiredPerHour' 'lines' -if adgroup_delivery_chart.input -tf 'date %Y-%m-%d %H:%M:%OS' * tplot: user error (out of memory) real 0m0.026s user 0m0.018s sys 0m0.008s -Manish

5 7

GHC API wiki update
by satvik chauhan 27 Feb '13

27 Feb '13

I was playing with the GHC api and found that examples on the GHC wiki don't seem to work with GHC 7.6.1. Does anybody have the updated examples of the same? Regards, Satvik

1 0

derivatives and integrals
by Christopher Howard 27 Feb '13

27 Feb '13

Hi. The scope of this question is likely bigger that Haskell, but this seems like the right crowd to ask. I'm in Calc II right now, and I'm looking for a FOSS desktop application (I use Gnu/Linux) to replace the functionality of my TI-98 in finding derivatives and integrals. (It's very convenient for double checking my own solutions.) I've heard of some software like Octave, but the manuals are usually very large, and I'm not sure what is the best one to start with. I was wondering if there is anyone on this list who uses free software to do that sort of simpler Calc stuff, and what it is that they use. -- frigidcode.com

2 1

package dependencies should distinguish between API and implementation?
by Johannes Waldmann 26 Feb '13

26 Feb '13

Package dependencies are modelled by a relation "A depends-on B". Shouldn't this in fact be two relations: API-depends-on and implementation-depends-on? (meaning that A API-depends-on B iff some type of B is visible to the user of A) So what we currently have is implementation-depends-on and API-depends-on is a sub-relation of that. The point being the following: assume * A implementation-depends-on B.1 * not (A API-depends-on B.1), * U implementation-depends-on A * U implementation-depends-on B >= 2 Then U (indirectly) implementation-depends on two versions of B but it should still be safe? (e.g., I can install B.3, re-compile U, but keep A) Example: A = template-haskell, B = containers (at least I don't see any mention of Data.Map/Set in th's API, I think the only dependency is in the implementation of PprM http://hackage.haskell.org/packages/archive/template-haskell/2.8.0.0/doc/ht… ) or in general, A (and B.1) are baked into ghc, but there is some B.2/B.3 out there which U wants to use. Or is this what already happens? (ghc would notice that B.1.foo is different from B.2.foo. cabal-install would warn, but proceed? Then the effect of the proposal would just be to switch off these warnings in some cases?) - J.W.

3 3

Thunks and GHC pessimisation
by oleg＠okmij.org 26 Feb '13

26 Feb '13

Tom Ellis wrote: > To avoid retaining a large lazy data structure in memory it is useful to > hide it behind a function call. Below, "many" is used twice. It is hidden > behind a function call so it can be garbage collected between uses. As you discovered, it is quite challenging to ``go against the grain'' and force recomputation. GHC is quite good at avoiding recomputation. This is a trade-off, of time vs space. For large search tree, it is space that is a premium, and laziness and similar strategies are exactly the wrong trade-off. The solution (which I've seen in some of the internal library code) is to confuse GHC with extra functions: http://okmij.org/ftp/Haskell/misc.html#memo-off So, eventually it is possible to force recomputation. But the solution leaves a poor taste -- fighting a compiler is never a good idea. So, this is a bug of sort -- not the bug of GHC, but of lazy evaluation. Lazy evaluation is not the best evaluation strategy. It is a trade-off, which suits a large class of problems and punishes another large class of problems.

2 1

Parser left recursion
by Martin Drautzburg 26 Feb '13

26 Feb '13

Hello all, this was previously asked on haskell-beginners, but only partially answered. As an exercise I am writing a parser roughly following the expamples in Graham Hutton's book. The language contains things like: data Exp = Lit Int -- literal integer | Plus Exp Exp My naive parser enters an infinite recursion, when I try to parse "1+2". I do understand why: "hmm, this expression could be a plus, but then it must start with an expression, lets check". and it tries to parse expression again and again considers Plus. Twan van Laarhoven told me that: > Left-recursion is always a problem for recursive-descend parsers. and suggested to do something like: > parseExp = do > lit <- parseLit > pluses <- many (parsePlusToken *> parseLit) > return (combinePlusesWithLit lit pluses) > > combinePlusesWithLit = foldr Plus -- or foldl This indeed does the trick, but only when the first token is a Lit (literal integer). I then added the possibility to optionally put things in parentheses. But then I cannot parse "(1+2)+3". The original code fails, because "(1+2)" is not a Lit and when I allow an expression as the first argument to "+" I get infinite recursion again. I am generally confused, that saying "a plus expression is an integer followed by many "plus somethings" is not what the language says. So this requires a lot of "paying attention" to get right. I'd much rather say "a plus expression is two expressions with a '+' in between". I do know for sure, that it is possible to parse "(1+2)+3" (ghci does it just fine). But I seem to be missing a trick. Can anyone shed some light on this? -- Martin

9 24

Status of GHC type-nats branch
by Takayuki Muranushi 26 Feb '13

26 Feb '13

Hi, everyone, In order to merge two type-level key-value pairs (More specifically, to use TypeNats branch of unittyped: https://bitbucket.org/xnyhps/haskell-unittyped/commits/all/tip/branch%28%22… ) I'd like to use overlapping type families and the type level Naturals at the same time. However, I couldn't build the type-nats branch of ghc, as I've been trying this week. I could build that in late 2012, so maybe this is due to updates in the git submodules. Do you reproduce this? Is there anyone else trying to build the type-nats branch? Any advice is helpful, including negative ones, if it's temporally broken or no more supported. And, I'm particularly glad if anyone has a x86-64 linux tarball of type-nats branch, and share it with me :) Best regards, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

2 2

ifdef based on which OS you're on
by Andrew Cowie 25 Feb '13

25 Feb '13

I've got a piece of code that looks like this: baselineContextSSL :: IO SSLContext baselineContextSSL = do ctx <- SSL.context SSL.contextSetDefaultCiphers ctx #if defined __MACOSX__ SSL.contextSetVerificationMode ctx SSL.VerifyNone #elif defined __WIN32__ SSL.contextSetVerificationMode ctx SSL.VerifyNone #else SSL.contextSetCADirectory ctx "/etc/ssl/certs" SSL.contextSetVerificationMode ctx $ SSL.VerifyPeer True True Nothing #endif return ctx all very nice (this being necessary because apparently the non-free operating systems don't store their certs in a reliably discoverable place; bummer). That, however, is not the problem. After all, this sort of thing is what #ifdefs are for. The problem is needing to get an appropriate symbol based on what OS you're using defined. I naively assumed there would be __LINUX__ and __MACOSX__ and __WIN32__ defined by GHC because, well, that's just the sort of wishful thinking that powers the universe. So my question is: what's an appropriate Haskell mechanism for building code that is OS / arch / distro specific? It's not like I have autoconf running generating me a config.h I could #include, right? This feels simple and an appropriate use of CPP; even the symbol names look just about like what I would have expected; stackoverflow said so, must be true. Just need to get the right symbol defined at build time. Any suggestions? AfC Sydney

8 14

ANN: lazy-csv - the fastest and most space-efficient parser for CSV
by Malcolm Wallace 25 Feb '13

25 Feb '13

There are lots of Haskell CSV parsers out there. Most have poor error-reporting, and do not scale to large inputs. I am pleased to announce an industrial-strength library that is robust, fast, space-efficient, lazy, and scales to gigantic inputs with no loss of performance. http://code.haskell.org/lazy-csv/ Downloads from Hackage: http://hackage.haskell.org/package/lazy-csv This library has been in industrial use for several years now, but this is the first public release. No doubt the API is not as general as it could be, but it already serves many purposes very well. I'm happy to receive bug reports and suggestions for improvements. Regards, Malcolm

7 7

ANN: conduit-network-stream, A base layer for network protocols with Conduits
by Nils 25 Feb '13

25 Feb '13

Hello everyone, I just uploaded my "conduit-network-stream" package to hackage. It's a base layer for network protocols based on the "Conduit" package by Michael Snoyman which makes it possible to send multiple messages over a continuous network connection in a convenient way. I wrote more about it at: https://github.com/mcmaniac/conduit-network-stream/blob/master/README.md It is available on hackage and github: http://hackage.haskell.org/package/conduit-network-stream https://github.com/mcmaniac/conduit-network-stream Until the documentation on hackage is generated, I also host the haddock documentation at: http://hs.nils.cc/conduit-network-stream/index.html For any questions/problems/requests, please ask! - Nils

3 5