June 2012 - Glasgow-haskell-users

Haddock problems with Haskell-Platform2012.2.0.0
by Katsutoshi Itoh 11 Jun '12

11 Jun '12

Hi all. I installed ghc-7.4.1 and haskell-platform-2.12.2.0.0 on debian linux. I'm getting lots of complaints from 'ghc-pkg check', of the following form: ---- Warning: haddock-interfaces: /usr/pkg/share/doc/haskell- platform-2012.2.0.0/html/haskell-platform.haddock doesn't exist or isn't a file Warning: haddock-html: /usr/pkg/share/doc/haskell-platform-2012.2.0.0/ html doesn't exist or isn't a directory Warning: haddock-interfaces: /usr/pkg/share/doc/zlib-0.5.3.3/html/ zlib.haddock doesn't exist or isn't a file Warning: haddock-html: /usr/pkg/share/doc/zlib-0.5.3.3/html doesn't exist or isn't a directory ... ---- Any advice? -- ---- いとうかつとし cutsea110(a)gmail.com

3 4

ANNOUNCE: GHC version 7.4.2
by Paolo Capriotti 10 Jun '12

10 Jun '12

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.4.2 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 7.4.1, so we recommend upgrading. The release notes are here: http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/release-7-4-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

1 0

problem with FFI and libsane
by Ganesh Sittampalam 07 Jun '12

07 Jun '12

Hi, I'm having some trouble making Haskell bindings to libsane (a scanner access library: http://www.sane-project.org/) When I build the cut down sample of my code (below) with GHC 7.4.1 with the non-threaded runtime, it hangs at runtime in the call to c'sane_get_devices (after printing "go"). Pressing ^C causes it to continue and print "done" before exiting. If I compile with GHC 7.2.2 non-threaded, it doesn't hang, printing first "go" then "done" after a few seconds. That pause is expected, as it's also seen in the equivalent C version (also below). If I switch to the threaded runtime, then things go wrong differently. Most of the time there's a hang after "go" and after pressing ^C they just exit immediately, without printing "done". This doesn't change between 7.2.2 and 7.4.1. Occasionally, things do work and I get "go" then "done". All these symptoms seem to point to some kind of threading problem, and I believe that libsane is using pthreads, although ldd doesn't report it and strace only shows it loading the library. The platform is Linux x86, and I've reproduced the behaviour on two different machines (Debian and Ubuntu). I've also tried with GHC 7.4.1.20120508, the most recent i386 snapshot I could fine. Is there anything obvious I'm doing wrong, or something I could try next? Cheers, Ganesh Haskell code: {-# LANGUAGE ForeignFunctionInterface #-} import Foreign.Marshal.Alloc import Foreign.Ptr import System.IO import Foreign.C.Types foreign import ccall "sane_init" c'sane_init :: Ptr CInt -> Callback -> IO CUInt type Callback = FunPtr (Ptr CChar -> Ptr CChar -> Ptr CChar -> IO ()) foreign import ccall "sane_exit" c'sane_exit :: IO () -- the () in the ptr type is incorrect, but in -- this cut-down example we never try to dereference it foreign import ccall "sane_get_devices" c'sane_get_devices :: Ptr (Ptr (Ptr ())) -> CInt -> IO CUInt main :: IO () main = do hSetBuffering stdout NoBuffering _ <- c'sane_init nullPtr nullFunPtr putStrLn "go" ptr <- malloc _ <- c'sane_get_devices ptr 0 putStrLn "done" c'sane_exit C code: #include <sane/sane.h> #include <stdlib.h> int main() { sane_init(NULL, NULL); puts("go"); const SANE_Device **ptr; sane_get_devices(&ptr, 0); puts("done"); sane_exit(); }

2 2

Known problems with promoted tuples and lists in GHC 7.4.1?
by David Menendez 07 Jun '12

07 Jun '12

Are there any known issues involving type-level pairs and lists? I've hit a few baffling type errors that went away when I refactored my code to use locally-defined pairs and lists instead of those provided by the prelude. More worryingly, I had one function that would stop passing the type checker if I replaced '[n] with (n ': '[]) in its signature. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

3 4

Mac OS X: compiling for 10.5 under 10.6
by Soenke Hahn 07 Jun '12

07 Jun '12

Hi! I was trying to use the ghc on a system with OS X 10.6 to compile for both 10.6 and 10.5 (and hopefully 10.7). In the past (with ghc-7.2.2 IIRC) I had luck with if os(darwin) cc-options: -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 ld-options: -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 in the cabal file, but with ghc-7.4.1 (from Haskell-Platform-2012.2.0.0) I get linker errors: Undefined symbols: "_fopen$DARWIN_EXTSN", referenced from: _procRtsOpts in libHSrts.a(RtsFlags.o) _initProfiling2 in libHSrts.a(ProfHeap.o) _exitHpc in libHSrts.a(Hpc.o) _startupHpc in libHSrts.a(Hpc.o) "_fopen$UNIX2003", referenced from: _loadArchive in libHSrts.a(Linker.o) _addDLL in libHSrts.a(Linker.o) "_kevent64", referenced from: _s3VN_info in libHSbase-4.5.0.0.a(KQueue__166.o) ld: symbol(s) not found If I remove the backward-compatibility flags from the cabal file, everything works fine. (I assume it won't run on OS X 10.5 then, of course.) If I understand correctly the RTS and the base library in ghc-7.4.1 depend on a newer version of the OS X SDK (>= 10.6). Is there an easy way to work around this version constraint? If not, does that mean, ghc-7.4.1 does not support OS X 10.5? Thanks, Sönke

3 2

Re: [Haskell-beginners] GHC7.4.1 -> LLVM ->W64
by Antoine Latter 05 Jun '12

05 Jun '12

On Tue, Jun 5, 2012 at 1:49 AM, Alexander.Vladislav.Popov <alexander.vladislav.popov(a)gmail.com> wrote: > Hi Haskellers, > > I want to build 64-bit Windows application. > Will 64-bit mingw and compilation via LLVM help me? > Who will shed light on it and lead me through darkened forest of my search? > If you're talking about using GHC to do this you might be better off asking on the GHC-Users list (which I've CC'd, so I guess you've already asked them!). I know that folks were spending time on making GHC work for Win-64, but I don't remember if it has shipped. Antoine

2 1

Source Location of DataCon objects in GHC 7.4.1 API
by JP Moresmau 05 Jun '12

05 Jun '12

Hello I have a failing test in BuildWrapper when moving from GHC 7.0.4 to 7.4.1. As far I can tell, in the TypecheckedSource I get DataCon objects that have no location info, and hence I can't retrieve them by location... Which is useful in a IDE (tell me what's under my mouse cursor, tell me where else it's used). Given the simple data declaration: data DataT=MkData {name :: String} In 7.0.4 I obtain a hierarchy that ends in FunBind (on a Var called "name")/MatchGroup/Match/ConPatOut and the contained DataCon named "MkData" has a SrcSpan associated with it, and so do the Var, MatchGroup and Match. In 7.4.1 I have the same hierarchy but the DataCon tells me "no location info". The Var "name" has a location, but the MatchGroup and Match don't either. Is it a normal change? Do I need to change something in the way I load the module? Is it a regression? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/

4 8

Prelude for type-level programming
by Etienne Laurin 04 Jun '12

04 Jun '12

Hello, To experiment with some of GHC's new features in HEAD, I have started ported part of the Prelude from values and functions to types and constraints. For example: comparing lists. instance Compare '[] '[] EQ instance Compare '[] (x ': xs) LT instance Compare (x ': xs) '[] GT instance (Compare x y o, Case o [ EQ --> Compare xs ys r, o --> o ~ r ]) => Compare (x ': xs) (y ': ys) r Prelude.Type> T :: (Compare '[I 1, I 2] '[I 1, I 3] a) => T a LT Sometimes I get nice error messages. Prelude.Type> T :: If (I 1 == I 2) (a ~ "hello") (a ~ 3) => T a Kind mis-match The left argument of the equality predicate had kind `Symbol', but `3' has kind `Nat' But often GHC refuses to type large constraints when there are too many constraint kinds and free variables. It also gets confused if I pretend to use higher-order kinds. instance ((a >>= Const b) c) => (a >> b) c Kind mis-match The first argument of `>>' should have kind `k0 k1', but `a' has kind `k0 k1' In the instance declaration for `(a >> b) c' I'm not sure yet how this is useful this, but I hope it can at least entertain a few people and stress-test the typechecker. http://code.atnnn.com/projects/type-prelude/repository/entry/Prelude/Type.hs darcs get http://code.atnnn.com/darcs/type-prelude/ Etienne Laurin

2 2

Understanding ghc-pkg dependencies when not using cabal
by Tim Cuthbertson 02 Jun '12

02 Jun '12

Hi all, I'm very interested in distributing ghc packages via zero-install [0]. I'm excited about ghc 7.4's ${pkgroot} support, since it means that many packages could now be made relocatable (as long as they don't need to know about paths to resources, etc). But I'm having some trouble understanding exactly what relationships exist between packages and when packages are needed / used. I have a lot of questions. Answering all of them would be wonderful, but even just some at least would be handy too ;) For an example, lets use ansi-terminal [1] (and assume we're building it on a unix host) ansi-terminal depends on `base` and `unix` packages. Do these need to be present in source form, or just in "compiled package" form? I'm assuming the latter. (by "compiled package", I mean the stuff that ends up in e.g ~/.cabal/lib/PACKAGENAME) When I built ansi-terminal, the package.conf I got out of `cabal register` had the following field: depends: base-4.5.0.0-6db966b4cf8c1a91188e66d354ba065e unix-2.5.1.0-c004d6a0692bba682bbf2ac7b61d8322 So presumably this is the exact version that was used for compilation. Obviously the first part is the version, but what is the second part? Is it the abi-hash of the library that was used at compile time? If I want to use ansi-terminal in a program that I'm compiling, how strict are these dependencies? Will a `unix` package of a different version and the same abi-hash be acceptable? Does it need to be strictly _newer_ than 2.5.1.0 (and still have the same abi-hash)? Or is this an exact dependency? If I distribute the `unix` library in compiled form, how likely is it that a given compiled version of `unix` will satisfy the requirement? If I have compiled two libraries that both depend on `unix`, but they ended up referencing a different abi-hash of `unix` (maybe I compiled them on a different computer, or on slightly different versions of the source), what happens when I try to compile an application that depends on these two libraries? I presume it couldn't work, even if I had registered both versions of `unix` simultaneously (is this even possible to do?). Under what circumstances will the same package source code (e.g "unix-2.5.1.0") have two different abi-hashes? From [2], it sounds like only major GHC version changes should affect it. Is the abi-hash consistent on different platforms (assuming the same major GHC version is used)? Can the output of `ghc --abi-hash` (with no arguments) be used as a "linkage" restriction? (i.e if I have the exact same source and two versions of ghc with the same abi-hash, will the compiled library necessarily end up with the same abi-hash in both cases?). If the `unix` package releases a new version that is compatible with ansi-terminal, what would I have to do to get this updated code into my application (that depends on ansi-terminal)? - install new version of `unix`, and recompile my application - as above, but also rebuilding the current version of `ansi-terminal` before I rebuild my application (despite ansi-terminal not actually changing itself) Perhaps the above question could be rephrased as "if a new version of `unix` is source-compatible with the previous, what recompilation (if any) of downstream libraries is / could be required? I know that ghc compiles applications statically by default. Given this, I'm a little confused by the lifetime of packages in ghc. Are packages (in the sense of "the stuff that is listed by `ghc-pkg list`") only required at compilation time? If I run a precompiled program that depends on another haskell package which has been compiled as a shared library, does this mean I need the ghc package to be registered, or is it sufficient to just have the compiled .so on my $LD_LIBRARY_PATH? Apologies for the large number of questions, and thanks for your time. - Tim. [0]: http://0install.net/ [1]: http://hackage.haskell.org/package/ansi-terminal-0.5.5 [2]: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Packages

2 2