August 2012 - Haskell-Cafe

Partial statical linking
by Jason Dusek 26 Sep '12

26 Sep '12

Some time ago, I wrote to this list about making shared libraries with GHC, in such a way that the RTS was linked and ready to go. Recently, I've been looking a similar but, in a sense, opposite problem: linking Haskell executables with some of their non-Haskell dependencies, for distribution. I tried passing a few different sets of options to the linker through GHC, with -optl: -optl'-Wl,-r' -optl'-Wl,-r,-dy' -optl'-Wl,-static,-lffi,-lgmp,-dy' None of these had the desired effect. In the end, running GHC with -v and carefully editing the linker line produced the desired change (I have linked to and provided the diff below). The effect -optl seems to be to introduce options in the linker line just before -lHSrtsmain, which would seem to prevent one from linking libffi and libgmp differently. Is editing and storing away the linker script the best option at present for partially static linking? -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments https://github.com/solidsnack/arx/commit/90ec5efdb0e991344aa9a4ad29456d466e… #@@ -122,10 +122,8 @@ # -lHSarray-0.3.0.2 \ # -lHSbase-4.3.1.0 \ # -lHSinteger-gmp-0.2.0.3 \ #- -lgmp \ # -lHSghc-prim-0.2.0.0 \ # -lHSrts \ #- -lffi \ # -lm \ # -lrt \ # -ldl \ #@@ -136,4 +134,7 @@ # -lgcc_s --no-as-needed \ # /usr/lib/gcc/x86_64-linux-gnu/4.6.1/crtend.o \ # /usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../x86_64-linux-gnu/crtn.o \ #+ -static \ #+ -lgmp \ #+ -lffi \

5 10

Platform Versioning Policy: upper bounds are not our friends
by Bryan O'Sullivan 23 Sep '12

23 Sep '12

Hi, folks - I'm sure we are all familiar with the phrase "cabal dependency hell" at this point, as the number of projects on Hackage that are intended to hack around the problem slowly grows. I am currently undergoing a fresh visit to that unhappy realm, as I try to rebuild some of my packages to see if they work with the GHC 7.6 release candidate. A substantial number of the difficulties I am encountering are related to packages specifying upper bounds on their dependencies. This is a recurrent problem, and its source lies in the recommendations of the PVP itself (problematic phrase highlighted in bold): When publishing a Cabal package, you should ensure that your dependencies > in the build-depends field are accurate. This means specifying not only > lower bounds, *but also upper bounds* on every dependency. I understand that the intention behind requiring tight upper bounds was good, but in practice this has worked out terribly, leading to depsolver failures that prevent a package from being installed, when everything goes smoothly with the upper bounds relaxed. The default response has been for a flurry of small updates to packages in which the upper bounds are loosened, thus guaranteeing that the problem will recur in a year or less. This is neither sensible, fun, nor sustainable. In practice, when an author bumps a version of a depended-upon package, the changes are almost always either benign, or will lead to compilation failure in the depending-upon package. A benign change will obviously have no visible effect, while a compilation failure is actually *better* than a depsolver failure, because it's more informative. This leaves the nasty-but-in-my-experience-rare case of runtime failures caused by semantic changes. In these instances, a downstream package should *reactively* add an upper bound once a problem is discovered. I propose that the sense of the recommendation around upper bounds in the PVP be reversed: upper bounds should be specified *only when there is a known problem with a new version* of a depended-upon package.

37 59

ANNOUNCE: uuid-1.2.6
by Antoine Latter 21 Sep '12

21 Sep '12

Hi folks, I'm happy to announce a new point release of the uuid library, 1.2.6: http://hackage.haskell.org/package/uuid-1.2.6 The 'uuid' package implements most of RFC 4122[1] including random generation and generation based on hardware MAC addresses. I haven't announced a point-release in a while. The changes since 1.2.1 include: * When generating UUIDs from the hardware MAC address, if the MAC address is not available we now use a random seed for our (hidden, global) state machine * The 'Read' instance now drops leading spaces * Added the functions 'toWords' and 'fromWords', primary to support the package uuid-quasi[2]. Take care, Antoine 1: http://tools.ietf.org/html/rfc4122 2: http://hackage.haskell.org/package/uuid-quasi

2 2

Could not find module `Text.Regex'
by zaxis 16 Sep '12

16 Sep '12

import Text.Regex date_by_ntday dateStr ntday = do let [y,m,d] = map (\x -> read x::Int) $ splitRegex (mkRegex "-") dateStr .... %ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 Which package(s) do i need to use Text.Regex ? Sincerely! ----- fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Could-not-find-module-%60Text.Regex%27-tp27366745p273… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

5 5

Over general types are too easy to make.
by timothyhobbs＠seznam.cz 04 Sep '12

04 Sep '12

I'd have to say that there is one(and only one) issue in Haskell that bugs me to the point where I start to think it's a design flaw: It's much easier to type things over generally than it is to type things correctly. Say we have a >data BadFoo = > BadBar{ > badFoo::Int} | > BadFrog{ > badFrog::String, > badChicken::Int} This is fine, until we want to write a function that acts on Frogs but not on Bars. The best we can do is throw a runtime error when passed a Bar and not a Foo: >deBadFrog :: BadFoo -> String >deBadFrog (BadFrog s _) = s >deBadFrog BadBar{} = error "Error: This is not a frog." We cannot type our function such that it only takes Frogs and not Bars. This makes what should be a trivial compile time error into a nasty runtime one :( The only solution I have found to this is a rather ugly one: >data Foo = Bar BarT | Frog FrogT If I then create new types for each data constructor. >data FrogT = FrogT{ > frog::String, > chicken::Int} >data BarT = BarT{ > foo :: Int} Then I can type deFrog correctly. >deFrog :: FrogT -> String >deFrog (FrogT s _) = s But it costs us much more code to do it correctly. I've never seen it done correctly. It's just too ugly to do it right :/ and for no good reason. It seems to me, that it was a design mistake to make data constructors and types as different entities and this is not something I know how to fix easily with the number of lines of Haskell code in existence today :/ >main = do > frog <- return (Frog (FrogT "Frog" 42)) > print $ > case frog of > (Frog myFrog) -> deFrog myFrog > badFrog <- return (BadBar 4) > print $ > case badFrog of > (notAFrog@BadBar{}) -> deBadFrog notAFrog The ease with which we make bad design choices and write bad code(in this particular case) is tragically astounding. Any suggestions on how the right way could be written more cleanly are very welcome! Timothy Hobbs

12 18

Cabal install fails due to recent HUnit
by Erik Hesselink 03 Sep '12

03 Sep '12

Hi all, All cabal installs using cabal-install-0.10.2 are currently failing for us. This is due to the cabal file for HUnit-1.2.5.0, which was recently uploaded to hackage. The ouput I'm getting from cabal is just: Reading available packages... Resolving dependencies... cabal: Couldn't read cabal file "HUnit/1.2.5.0/HUnit.cabal" If I unpack HUnit-1.2.5.0 and call 'cabal configure', I get: cabal: HUnit.cabal:57: The 'type' field is required for test suites. The available test types are: exitcode-stdio-1.0 The relevant lines from the cabal file are: Test-Suite hunit-tests-optimize-0 Type: exitcode-stdio-1.0 These look fine to me. Does anyone have any idea how to go about fixing this (on hackage at least)? Could this package temporarily be removed, to avoid breaking everyone's cabal? Erik

12 26

Re: [Haskell-cafe] [Haskell] ANNOUNCE: Perdure
by Felipe Almeida Lessa 31 Aug '12

31 Aug '12

[moving discussion to haskell-cafe] Congratulations and thanks for your new open source contribution! I hope you feel at home =). Your library looks really interesting but I'm completely overwhelmed by its size. Its Cabal description is huge and there's no example of how to use the library (it actually took me some time to understand what the library tries to accomplish). I took a quick look at the modules but there are so many that I couldn't really make sense of anything in a short time. So, could you perhaps write a full example of how to use the library? It looks like a nice library but I need a starting point =). Cheers! -- Felipe.

2 1

Yesod a href render issue
by Thiago Negri 31 Aug '12

31 Aug '12

I'm following Yesod tutorial that gives this as the first example for "type-safe URLs": | getHomeR = defaultLayout [whamlet|<a href=@{Page1R}>Go to page 1!|] Worked fine, the "a href" generated looks perfect. Then I tried this: | getHomeR = defaultLayout [whamlet|Hello!<a href=@{Page1R}>Go to page 1!|] And got a "a href" referecing a URL without quotes and with no end tag for "a", something like this: | <html><head><title></title></head><body>Hello<a href=/page1>Go to page 1!</body></html> I tried in many different ways, and the only way to get it working properly was to set the "a" tag in a line by itself: | getHomeR = defaultLayout [whamlet|Hello! | <a href=@{Page1R}>Go to page 1! | |] Is this a failure of Yesod quasiquotation or am I missing something? I know Yesod clearly states that the best approach is to use external files instead of quasiquotes, but as I'm making my first steps into Yesod, I would like to use the practical embedded quasiquotes.

3 2

Build regressions due to GHC 7.6
by Bryan O'Sullivan 31 Aug '12

31 Aug '12

Since the release of the GHC 7.6 RC, I've been going through my packages and fixing up build problems so that people who upgrade to 7.6 will have a smooth ride. Sad to say, my experience of 7.6 is that it has felt like a particularly rough release for backwards incompatibility. I wanted to quantify the pain, so I did some research, and here's what I found. I maintain 25 open source Haskell packages. Of these, the majority have needed updates due to the GHC 7.6 release: - base16-bytestring - blaze-textual - bloomfilter - configurator - criterion - double-conversion - filemanip - HDBC-mysql - mwc-random - pcap - pool - riak-haskell-client - snappy - text - text-format - text-icu That's 16 out of 25 packages I've had to update. I've also either reported bugs on, or had to fix, several other people's packages along the way (maybe four?). So let's say I've run into problems with 20 out of the combined 29 packages of mine and my upstreams. The reasons for these problems fall into three bins: - Prelude no longer exports catch, so a lot of "import Prelude hiding (catch)" had to change. - The FFI now requires constructors to be visible, so "CInt" has to be imported as "CInt(..)". - bytestring finally got bumped to 0.10, so many upper bounds had to be relaxed (*cf* my suggestion that the upper-bounds-by-default policy is destructive). It has been a lot of work to test 29 packages, and then modify, rebuild, and release 20 of them. It has consumed most of my limited free time for almost two weeks. Worse, this has felt like make-work, of no practical benefit to anyone beyond scrambling to restore the status quo ante. If over half of my packages needed fixing, I'm alarmed at the thought of the effects on the rest of Hackage. I'm torn over this. I understand and agree with the impetus to improve the platform by tidying things up, and yet just two seemingly innocuous changes (catch and FFI) have forced me to do a bunch of running to stand still. I don't have any suggestions about what to do; I know that it's hard to estimate the downstream effects of what look like small changes. And so I'm not exactly complaining. Call this an unhappy data point.

10 15

Function names in Haskell lib not first-class on web!
by damodar kulkarni 31 Aug '12

31 Aug '12

Hi Cafe, It seems, the function names in Haskell libs are not first-class objects, AT LEAST when it comes to searching for them of the net! I was trying to search for the following Haskell functions in the mailing list archives. Here is a summary of the responses I have had from various servers upon searching various "valid and normally used" Haskell function identifiers from well-known libraries. Responses from the http://www.mail-archive.com >>=<http://www.mail-archive.com/search?l=haskell-cafe%40haskell.org&q=%3E%3E%3D>, It seems the script searched for the string "&*gt*; &*gt*;" * -> *<http://www.mail-archive.com/search?l=haskell-cafe%40haskell.org&q=*+-%3E+*>There are 0 results. and so on... Responses from the http://search.gmane.org >>=<http://search.gmane.org/search.php?group=gmane.comp.lang.haskell.cafe&query…> Here, too, it seems the script searched for the string "&*gt*; &*gt*;" * -> *<http://search.gmane.org/?query=*+-%3E+*&author=&group=gmane.comp.lang.haske…> Here it seems the script searched for the string "&*gt*;" and so on... *Note: google badly fails to search these functions identifiers.* My current solution to this problem is: download compressed text archives and do a simple grep on it on my machine. But the archives up to year 2000 only are found at http://www.haskell.org/pipermail/haskell-cafe/. So, as an aside: Where do I find the earlier messages for downloading? Thanks, Damodar

4 4