- Glasgow-haskell-users

Experiencing libffi related problem with GHC HEAD on Ubuntu 11.04
by Ryan Newton 27 Jun '11

27 Jun '11

Has anyone seen this one before? # libffi.so needs to be built with the correct soname. # NOTE: this builds libffi_convience.so with the incorrect # soname, but we don't need that anyway! cd libffi && \ "cp" build/libtool build/libtool.orig; \ sed -e s/soname_spec=.*/soname_spec="libHSffi-ghc7.1.20110609.so<http://libhsffi-ghc7.1.20110609.so/>"/ build/libtool.orig > build/libtool cp: cannot stat `build/libtool': No such file or directory sed: can't read build/libtool.orig: No such file or directory make[2]: *** [libffi/stamp.ffi.configure] Error 2 make[1]: *** [all_libffi] Error 2 make[1]: Leaving directory `/home/newton/build/haskell2/ghc-validate' make: *** [all] Error 2 Thanks, -Ryan P.S. It's not new. I just did a "git pull origin master && ./sync-all pull origin master" and got this error but I also got the same error on this machine back on June 9th. However, this package has built GHC HEAD in the past. It has the standard ubuntu libffi-dev and libffi5 packages installed.

1 0

gitweb on darcs.haskell.org?
by Iavor Diatchki 26 Jun '11

26 Jun '11

Hello, Do we have an instance of "gitweb" for the various ghc related repos running somewhere? If not, I'd be happy to setup an instance, would anyone object? "gitweb" is a web-interface which makes it easy to get a quick overview of what's going on with a collection of repositories. It shows commits, branches, tags, etc. Also, it provides RSS/Atom feeds, which makes it easy to subscribe to changes for repos of interest. -Iavor PS: you can try it out locally by typing "git instaweb" in a git repository.

4 4

Hoopl: Examples of wrapFR or wrapBR?
by Justin Bailey 26 Jun '11

26 Jun '11

Can someone provide an example of how to use wrapFR/wrapBR? I know they are deprecated, but I would really like to see them in action if they are used anywhere at all ... Thanks so much! Justin

2 1

GHC and Haskell 98
by Simon Peyton-Jones 24 Jun '11

24 Jun '11

Friends, this is to ask your opinion about a possible change in GHC 7.2. The current implementation in GHC 7.2 is Plan A below. Plan A is a bit easier for us, but I think it may be a bit draconian, and therefore propose Plan B as an alternative. Opinions? Simon ============================================== With GHC 7.0 if you say ghc -c Main.hs the import of Prelude, whether implicit or explicit, will come from package 'base'. This is also true if you say ghc -c Main.hs -package haskell98 The package 'haskell98' exposes 'List' and 'Random' but not 'Prelude'. That still comes from 'base'. This isn't good, because it means that if in the future we change 'Prelude' in package 'base', a Haskell98 module might fail to compile. And later iterations of Haskell might well want to expand or change the Prelude. There appear to be two alternatives: (Plan A) Add a module 'Prelude' to package 'haskell98'. Now you can compile a pure H98 program thus: ghc -c Main.hs -hide-all-packages -package haskell98 (Cabal puts the -hide-all-packages in for you.) And this will continue to work even if later iterations of Haskell change the Prelude. BUT (A) means that this module becomes un-compilable: module Main where import Random import Data.List Why? Because 'Random' comes from 'haskell98' and 'Data.List' comes from 'base'. But if you say ghc -c Main.hs -package base -package haskell98 then the (implicit) import of 'Prelude' will say "Ambiguous module name: Prelude", because it's exported by both 'base' and 'haskell98'. To fix this you have to change 'import Random' to 'import System.Random'. But the latter's API is different, so you may have to change the source code that uses it. So the second alternative is this: (Plan B) Like Plan A, but in addition, if you say "{-# LANGUAGE Haskell98 #-}" in the file, or -XHaskell98 on the command line, the implicit import of Prelude comes from package 'haskell98', provided -package haskell98 is specified, but regardless of what other in-scope packages expose a Prelude module. Variation: an explicit 'import Prelude' is similarly directed to package 'haskell98' as well. So: Under Plan A, some Hackage packages will become un-compilable, and will require source code changes to fix them. I do not have any idea how many Hackage packages would fail in this way. Unser Plan B, Hackage package that compile now will continue to compile, if their Cabal file is altered. No source code changes. (Well, unless they depend on some innards of GHC.IO or something like that.) But Plan A is simpler. And by breaking packages it will encourage [force] libraries that use a mixture of H98 and more modern modules to move towards the more modern story.

11 11

Reducing the cost of garbage collecting small arrays
by Johan Tibell 24 Jun '11

24 Jun '11

Hi, Now when we can efficiently copy small arrays I've gone back to benchmarking/optimizing my hash array mapped trie data structure. The data structure's performance depends on how efficiently we can allocate/collect/copy Array#s and MutableArrays#s of size <=32. Speeding up copying helped quite a bit, but the HAMT is still slower than a Patricia tree for inserts. If you look at the data below you can see that GC time totally dominates the runtime. Is there anything that can be done to make the GC cheaper in this case? If I'm reading the output below right it's not allocating the space that takes most of the time, but later evacuating/scavenging it. Benchmark ========= {-# LANGUAGE BangPatterns #-} module Main (main) where import Data.List import qualified Data.HashMap as HM test :: HM.HashMap Int Int -> Int -> HM.HashMap Int Int test !m 0 = m test m n = test (HM.insert n n m) (n-1) {-# NOINLINE test #-} main = print $ HM.null $ test HM.empty 1000000 Hash array mapped trie ====================== $ time perf record -f ./test False [ perf record: Woken up 13 times to write data ] [ perf record: Captured and wrote 1.672 MB perf.data (~73041 samples) ] real 0m2.562s user 0m0.020s sys 0m0.010s # Samples: 72980 # # Overhead Command Shared Object Symbol # ........ ............... .......................... ...... # 52.79% test ./test [.] evacuate 9.49% test ./test [.] 0x000000000b4544 8.47% test ./test [.] scavenge_block 6.27% test ./test [.] s4UJ_info 4.67% test ./test [.] s1Od_info 4.22% test ./test [.] scavenge_mut_arr_ptrs 3.68% test ./test [.] s4N7_info 0.72% test ./test [.] todo_block_full 0.55% test ./test [.] GarbageCollect 0.55% test ./test [.] freeGroup Patricia tree ============= $ time perf record -f ./test False [ perf record: Woken up 11 times to write data ] [ perf record: Captured and wrote 1.292 MB perf.data (~56470 samples) ] real 0m1.984s user 0m0.020s sys 0m0.010s # Samples: 56409 # # Overhead Command Shared Object Symbol # ........ ............... .................... ...... # 49.30% test ./test [.] evacuate 24.75% test ./test [.] sa4B_info 14.56% test ./test [.] scavenge_block 1.31% test ./test [.] sa4k_info 1.25% test ./test [.] sa4m_info 1.25% test ./test [.] 0x00000000004108 0.72% test [kernel] [k] clear_page_c 0.66% test ./test [.] todo_block_full 0.46% test [kernel] [k] page_fault 0.44% test ./test [.] GarbageCollect P.S. I also need to figure out what 0x000000000b4544 corresponds to in the first perf events report. I thought my fix to the generated assembly files should have taken care of the unknown symbol problem. Cheers, Johan

3 6

Superclass equalities
by Simon Peyton-Jones 24 Jun '11

24 Jun '11

Friends I have long advertised a plan to allow so-called superclass equalities. I've just pushed patches to implement them. So now you can write class (F a ~ b) => C a b where { ... } This email is just to encourage you to try them out. Currently this is just in the HEAD git repository. It'll appear in GHC 7.2, a release we are now actively preparing. But the feature isn't heavily tested (since it didn't exist until today), so I'd appreciate people trying it out. Thanks Simon

3 2

Re: [GHC] #5051: Typechecker behaviour change
by Serge D. Mechveliani 23 Jun '11

23 Jun '11

Simon, thank you. Currently, DoCon works under ghc-7.0.1. And as I understand, the next release which is going to support DoCon (with its heavy use of overlapping instances) will be ghc-7.2. Regards, -------- Serge Mechveliani, mechvel(a)botik.ru On Wed, Jun 22, 2011 at 11:01:53AM -0000, GHC wrote: > #5051: Typechecker behaviour change > ---------------------------+------------------------------------------------ > Reporter: igloo | Owner: simonpj > Type: bug | Status: closed > Priority: high | Milestone: 7.2.1 > Component: Compiler | Version: 7.0.2 > Resolution: fixed | Keywords: > > [..] > > GHC 7 indeed falls over on `DoCon` 2.12. It turns out to be a rather > subtle interaction of overlapping instances with the ill-fated "silent > superclass parameters" I introduced to solve a problem in the > typechecker's constraint solver. > [..]

2 1

Type function under a forall type
by Stefan Holdermans 23 Jun '11

23 Jun '11

Simon, Tom, I hit this type-error message in GHC 7.0.3: Cannot deal with a type function under a forall type: forall e. El e u Is there a fundamental reason why type functions under a forall type are a bad idea? Of is it just something that hasn't been implemented/thought about yet? Cheers, Stefan

2 1

ANNOUNCE: GHC version 7.0.4
by Ian Lynagh 22 Jun '11

22 Jun '11

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.4 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 7.0.3, so we recommend upgrading. The release notes are here: http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/release-7-0-4.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

2 1

Re: GHC and Haskell 98
by John Lato 20 Jun '11

20 Jun '11

> > From: Bas van Dijk <v.dijk.bas(a)gmail.com> > > On 17 June 2011 16:47, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > So: ? ?Under Plan A, some Hackage packages will become un-compilable, > > ? ? ? and will require source code changes to fix them. ?I do not have > > ? ? ? ?any idea how many Hackage packages would fail in this way. > > Of the 372 direct reverse dependencies of haskell98: > > > http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/haskel… > > there are 344 which also depend on base (See http://hpaste.org/47933 > for calculating the intersection). > Is it easy to check, out of those 344, how many would build if the dependency on haskell98 were removed? I suspect it's not needed for the majority of cases. +1 for Plan A, but interested in mitigating the negative consequences. (Bas, your link doesn't work for me BTW, can't resolve the IP. May be my uni's dns cache.) John Lato

3 2