July 2012 - Glasgow-haskell-users

GHC ARM builds?
by Austin Seipp 13 Jul '12

13 Jul '12

With 7.4.2, the patches for full ARM linker support were merged and released. Are there any official builds of GHC for Linux/ARM yet? I have a PandaBoard ES I'd be willing to contribute for builds and/or testing/development, but I don't know where to get a GHC for bootstrapping. It's also worth asking if there's any page documenting needed prerequisites/expected build environment. If not it should be added to the wiki (I don't see any as of right now.) -- Regards, Austin

4 5

Imported foreign functions should be strict
by Favonia 12 Jul '12

12 Jul '12

Hi all, Recently I am tuning one of our incomplete libraries that uses FFI. After dumping the interface file I realized strictness/demand analysis failed for imported foreign functions---that is, they are not inferred to be strict in their arguments. In my naive understanding all imported foreign functions are strict! Here's a minimum example (with GHC 7.4.2): {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Foreign.C foreign import ccall unsafe "sin" sin' :: CDouble -> CDouble where in the interface file the function sin' will have strictness U(L) (meaning Unpackable(Lazy)). Regards, Favonia

3 3

[Fwd: Memory corruption issues when using newAlignedPinnedByteArray, GC kicking in?]
by Nicolas Trangez 11 Jul '12

11 Jul '12

All, I sent this mail to Haskell Cafe earlier today, and was pointed [1] at this list. As such... Any help/advice would be greatly appreciated! Thanks, Nicolas [1] http://www.haskell.org/pipermail/haskell-cafe/2012-July/102242.html -------- Forwarded Message -------- > From: Nicolas Trangez <nicolas(a)incubaid.com> > To: haskell-cafe(a)haskell.org > Cc: Roman Leshchinskiy <rl(a)cse.unsw.edu.au> > Subject: Memory corruption issues when using > newAlignedPinnedByteArray, GC kicking in? > Date: Tue, 10 Jul 2012 19:20:01 +0200 > > All, > > While working on my vector-simd library, I noticed somehow memory I'm > using gets corrupted/overwritten. I reworked this into a test case, and > would love to get some help on how to fix this. > > Previously I used some custom FFI calls to C to allocate aligned memory, > which yields correct results, but this has a significant (+- 10x) > performance impact on my benchmarks. Later on I discovered the > newAlignedPinnedByteArray# function, and wrote some code using this. > > Here's what I did in the test case: I created an MVector instance, with > the exact same implementation as vector's > Data.Vector.Storable.Mutable.MVector instance, except for basicUnsafeNew > where I pass one more argument to mallocVector [1]. > > I also use 3 different versions of mallocVector (depending on > compile-time flags): > > mallocVectorOrig [2]: This is the upstream version, discarding the > integer argument I added. > > Then here's my first attempt, very similar to the implementation of > mallocPlainForeignPtrBytes [3] at [4] using GHC.* libraries. > > Finally there's something similar at [5] which uses the 'primitive' > library. > > The test case creates vectors of increasing size, then checks whether > they contain the expected values. For the default implementation this > works correctly. For both others it fails at some random size, and the > values stored in the vector are not exactly what they should be. > > I don't understand what's going on here. I suspect I lack a reference > (or something along those lines) so GC kicks in, or maybe the buffer > gets relocated, whilst it shouldn't. > > Basically I'd need something like > > GHC.ForeignPtr.mallocPlainAlignedForeignPtrBytes :: Int -> Int -> IO > (ForeignPtr a) > > Thanks, > > Nicolas > > [1] https://gist.github.com/3084806#LC37 > [2] https://gist.github.com/3084806#LC119 > [3] > http://hackage.haskell.org/packages/archive/base/latest/doc/html/src/GHC-Fo… > [4] https://gist.github.com/3084806#LC100 > [5] https://gist.github.com/3084806#LC81 > >

2 2

Re: How to describe this bug?
by Tyson Whitehead 10 Jul '12

10 Jul '12

On July 10, 2012 10:39:41 Colin Adams wrote: > Sure they would be better modelled that way, but the whole point of using > floating point arithmetic is to sacrifice accuracy for performance, is it > not? True. I just find it interesting that some types have a builtin Nothing value. Some further examples are pointer (where NULL is Nothing) and clamped/saturation arithmetic (where min and max values are Nothing). It would be nice if somehow they could be unified at the top level without the performance penalty associated with a genuine Maybe value. Another possibility might be to consider NaN to encode bottom in Float#. When you constructed Float from Float# with a NaN it would give bottom. Would the existance of unboxed lifted types be a problem? Cheers! -Tyson

1 0

Modified layout for lambda-case
by Tyson Whitehead 09 Jul '12

09 Jul '12

It seems my suggestion isn't getting too much traction. It occurs to me this may be because I jumped right into layout rules and didn't first give some simple motivating examples to get the idea across. SHORT VERSION: Assume '\' is a grouping construct. I proposed always interpreting ... \x -> do (3a) ... as ... \ { x -> do { ... } } (3b) and never as ... \ { x -> do { }; ... } (3c) or ... \ { x -> do { } } ... (3d) This would be apposed to our current situation of all these being possible depending on if the second line starts past (3c), at (3b), or before (3d) 'x'. We loose nothing is at best empty groups do nothing (let and where) and at worst are errors (do and case) as in the above. LONGER VERSION: What I was suggesting was to change the layout rule that gives you empty groupings. Currently nonsensical nested empty where and let clauses like let { x = ... where { }; ... } (1a) do { let { }; ... } (2a) can be expressed using layouts let x = ... where (1b) ... do let (2b) ... because each new grouping has to be indented further than the previous. This trips us up if we change '\' into a grouping construct as the common ... \x -> do (3a) ... will get interpreted incorrectly as ... \ { x -> do { } } ... (3d) It all seems silly though. At best empty grouping does nothing (let and where) and at worst is an error (do and case). Why then not always go with ... \ { x -> do { ... } } (3b) That is, if a line ends in a grouping clauses and the next line is further indented, then what follows is the associated grouped statements. It's also easier to read. Further indented lines following a grouping clause are associated with that clause. No need to identify other potential grouping clauses and check relative indentation levels. Cheers! -Tyson

1 0

More infinite simplifier bugs?
by Ron Alford 07 Jul '12

07 Jul '12

So a while back Simon added a tick counter to the simplifier: http://hackage.haskell.org/trac/ghc/ticket/5448 Are there any known bugs that can cause the simplifier to run out of memory /without/ hitting the tick counter limit? I have code that /used/ to run (at least after hacking around the previous simplifier bug): https://github.com/ronwalf/Planning With GHC 7.4.[12], it exhausts all the RAM on my machine (4GB). Compiling with -O0 fixes the problem. I can start bisecting my code to find the problem if nothing comes to mind. -Ron Alford (who seems to be good at killing the simplifier)

2 2

Creating stubs statically
by Paolo Capriotti 05 Jul '12

05 Jul '12

As explained in detail here: http://www.haskell.org/pipermail/ffi/2012-June/001867.html, it may be useful to have a form of foreign declaration that creates a static stub for a haskell function without exporting a symbol. Here is a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/7048. It is not particularly clear how such a declaration would look like syntactically. In the ticket I proposed the following: foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback but please do suggest better alternatives. It would also be useful to see some use cases of this new form of declaration. Library binding authors: would this be a welcome addition for you? BR, Paolo

2 1

[GHC Users] Dictionary sharing
by Jonas Almström Duregård 02 Jul '12

02 Jul '12

Hi, Is there a way to ensure that functions in a class instance are treated as top level definitions and not re-evaluated? For instance if I have this: >>> class C a where list :: [a] instance List a => List [a] where list = permutations list <<< How can I ensure that list :: [[X]] is evaluated at most once for any type X (throughout my program)? I assume this is potentially harmful, since list can never be garbage collected and there may exist an unbounded number of X's. I currently have a solution that uses Typeable to memoise the result of the function based on its type. Is there an easier way? Regards, Jonas

3 4

Compiling ghcjs
by Nathan Hüsken 02 Jul '12

02 Jul '12

Hi, I hope this is the correct list to ask this question. I am trying to compile the ghcjs compiler. I am on ubuntu 12.04 and have ghc-7.4.1 installed (via apt-get). I am following the instruction I found here: https://github.com/ghcjs/ghcjs The first trouble comes with "git pull ghcjs". I get: remote: Counting objects: 42, done. remote: Compressing objects: 100% (9/9), done. remote: Total 26 (delta 22), reused 21 (delta 17) Unpacking objects: 100% (26/26), done. >From github.com:ghcjs/packages-Cabal * [new branch] encoding -> ghcjs/encoding * [new branch] ghc-7.2 -> ghcjs/ghc-7.2 * [new branch] ghc-7.4 -> ghcjs/ghc-7.4 * [new branch] master -> ghcjs/master You asked to pull from the remote 'ghcjs', but did not specify a branch. Because this is not the default configured remote for your current branch, you must specify a branch on the command line. So I am doing: git pull ghcjs ghc-7.4 Then "git branch ghc-7.4 ghcjs/ghc-7.4" gives me: fatal: A branch named 'ghc-7.4' already exists. And finaly "perl boot" fails with: Error: libraries/extensible-exceptions/LICENSE doesn't exist. Maybe you haven't done './sync-all get'? at boot line 74, <PACKAGES> line 57. What can I do? Thanks! Nathan

2 1