- Glasgow-haskell-users

GHC 6.8.1 is impressive!
by Ravi Nanavati 10 Nov '07

10 Nov '07

I just finished a running Bluespec's regression suite on a version of our tools compiled with ghc 6.8.1. The results were impressive on two fronts: 1. All of our tests (almost 14,000) had the same behavior as with ghc 6.6.1 2. Our Haskell code was roughly 33% faster (relative to ghc 6.6.1). It seems that pointer-tagging made a big difference for our code base (since, if I'm reading the release notes correctly, constructor specialization isn't in yet). We just wanted to take a moment to say that we were pleasantly surprised by ghc 6.8.1 (so much so that we're going to try and use it for released builds sooner than we would have otherwise planned) and to thank everyone involved for the effort they put into it. Thank you, - Ravi Nanavati (and the rest of Bluespec, Inc.)

8 12

Re: Getting source code on Mac OS X
by richardg＠richardg.name 09 Nov '07

09 Nov '07

I did some more digging and it looks like Mac OS X (BASH? BASH on Mac OS X? BSD? POSIX?) limits the number of files that a program can have open. Increasing this limit makes the issue disappear. By default, user accounts are limited to 256 open files (per process?) but this can be changed with ulimit. To see the current limit, type in `ulimit -n'. To increase the allowed number of files to the maximum, type in `ulimit -n unlimited'. Sometimes an error message will be generated, sometimes not. If a message is generated, restart Terminal.app and try again. After the operation succeeds, it's probably a good idea to set the limit back to its original value (`ulimit -n 256'). After doing some testing, it appears that 256 files is only slightly too small; `darcs pull -a' succeeds (at the moment) when the file limit is set to 320. I'll update the GHC wiki and follow up on the darcs bug in a bit. Richard

1 0

Getting source code
by richardg＠richardg.name 08 Nov '07

08 Nov '07

Hello I'm trying to get the source code for development purposes (helping add some Haddock documentation for TH). I tried following the steps listed on http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources and ran into trouble. I downloaded ghc-HEAD-2007-08-29-ghc-corelibs-testsuite.tar.bz2 and continued through the steps. On step 3, I received an error message from darcs: $ darcs pull -a Pulling from "http://darcs.haskell.org/ghc"... This is the GHC darcs repository (HEAD branch) For more information, visit the GHC developer wiki at http://hackage.haskell.org/trac/ghc ********************** darcs: getCurrentDirectory: resource exhausted (Too many open files) I tried using darcs get but I think I ran into the same case issue as on Windows: $ darcs get http://darcs.haskell.org/ghc This is the GHC darcs repository (HEAD branch) For more information, visit the GHC developer wiki at http://hackage.haskell.org/trac/ghc ********************** Copying patch 17349 of 17349... done. Applying patch 12 of 17349... Unapplicable patch: Thu Jan 11 07:26:13 MST 1996 partain * [project @ 1996-01-11 14:06:51 by partain] darcs failed: Error applying hunk to file ./ghc/includes/rtsTypes.lh I'm using GHC 6.6.1 (binary distribution) and darcs 1.0.9 (can't remember if it's binary distribution or if I compiled it myself) on Mac OS X 10.4.10 for Intel. Any help would be appreciated. Thanks, Richard

4 3

6.8.1 compilation error
by Seth Kurtzberg 08 Nov '07

08 Nov '07

All, While compiling the new release (6.8.1, with both the primary source and the extra libraries) I experienced a gcc error, gcc of course called by ghc. I'm compiling 6.8.1 with ghc 6.6.1. The gcc version is 4.1.1. I've seen similar behavior in the past where some sort of heap corruption occurs within gcc and triggers an internal compiler error. So this may not be a true ghc error at all, but one can't completely rule it out. This type of error, especially appearing at random, is suggestive of a memory hardware problem. To eliminate this possibility I ran memtest86 for several hours on the machine. No errors were detected. I'll repeat the build again from a fresh directory to see if the problem is repeatable. Then I plan to run a build after upgrading gcc from 4.1.1 to 4.2.1. I'll report the results. The environment is Linux using kernel 2.6.21. The compilation command and the resulting error: /usr/local/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -c rename/RnSource.lhs -o stage1/rename/RnSource.o -ohi stage1/rename/RnSource.hi /tmp/ghc1316_0/ghc1316_0.hc: In function 'raVb_entry': /tmp/ghc1316_0/ghc1316_0.hc:1983:0: internal compiler error: in referenced_var_lookup, at tree-dfa.c:578 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. <<ghc: 586234044 bytes, 718 GCs, 10149393/21203304 avg/max bytes residency (9 samples), 55M in use, 0.02 INIT (0.00 elapsed), 6.94 MUT (27.32 elapsed), 3.53 GC (3.67 elapsed) :ghc>> make[1]: *** [stage1/rename/RnSource.o] Error 1 make: *** [stage1] Error 1 Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface

3 6

ANNOUNCE: GHC version 6.8.1
by Ian Lynagh 08 Nov '07

08 Nov '07

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.1 ============================================================= The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Haskell Program Coverage (hpc) support has been added to the compiler * GHCi now includes a debugger * The first phase of the base package split has been done * The code generator now uses pointer tagging (which should mean most code improves by 10-15%, and as a result the compiler is also faster). The full release notes are here: http://haskell.org/ghc/docs/6.8.1/html/users_guide/release-6-8-1.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; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. 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

3 3

Problem compiling 6.8.1 extralibs
by Alexis Hazell 08 Nov '07

08 Nov '07

Hi all, i'm having some difficulties compiling the 6.8.1 extralibs on a Mandriva 2007.0 box. Despite happy 1.15 being installed (with the happy binary in /usr/bin/), i get the following error: Preprocessing library haskell-src-1.0.1.1... Setup: The program happy is required but it could not be found make[1]: *** [haskell-src/GNUmakefile] Error 1 make[1]: Leaving directory `/usr/src/ghc-6.8.1/libraries' make: *** [stage1] Error 2 Command exited with non-zero status 2 Any suggestions as to how to fix this would be greatly appreciated. :-) Alexis.

3 3

Template Haskell documentation
by Richard Giraud 08 Nov '07

08 Nov '07

Hello I'm trying to learn how to use Template Haskell and I'm finding that the documentation is sparse. In particular, the constructors for Dec, Exp, Con, etc. in Language.Haskell.TH.Syntax aren't explained. Would documentation patches be welcomed for this library? Thanks, Richard

3 2

Building a prelude
by Victor Nazarov 08 Nov '07

08 Nov '07

Is it possible to build Prelude from scratch. Or just some modules like GHC.Base. For example when I do % ghcjs-inplace.bat -fglasgow-exts -fjavascript -cpp -c Err.lhs-boot % ghcjs-inplace.bat -fglasgow-exts -fjavascript -cpp -c Base.lhs I've got this error: Base.lhs:94:0: Bad interface file: C:/Program Files/Visual Haskell\imports/GHC/Err.hi-boot Something is amiss; requested module base:GHC.Err differs from name found in the interface file main:GHC.Err What can I do to overcome this. Really what I want is to build some runtime system for my ghc-derived-javascript-compiler. And to embed JavaScript integers into it. I understand that I need to write some primitive operations in JavaScript like addition. I can build some numerals on the top of Haskell, but I'd like to get access to underlying javascript features and integers is a good point to start. Can you recommend me some strategy or smth? -- vir http://vir.comtv.ru/

2 1

Why only inference in type checking?
by Philip K.F. Hölzenspies 07 Nov '07

07 Nov '07

Dear All, A while ago, I had trouble understanding the coverage condition and I raised a question on this mailing list. Help was swift and adequate, especially the reference to the paper entitled "Understanding Functional Dependencies via Constraint Handling Rules" was very useful. However, having considered the problem of non-termination of the type checker, I can't help but wonder why the type checker is "inference only." From the paper mentioned above, consider the following example: class Mul a b c | a b -> c where (*) :: a -> b -> c type Vec b = [b] instance Mul a b c => Mul a (Vec b) (Vec c) where ... f b x y = if b then (*) x [y] else y For actual arguments of f, there is no issue whatsoever with decidability. The type checker in my brain uses unification, i.e. top-down. The type checker in GHC uses inference, i.e. bottom-up. Why inference potentially suffers from non-termination for this program, I understand. My question is this: Is there a reason why type checking in GHC is inference-only, as opposed to a meet-in-the-middle combination of unification and inference? Would the type checker use both unification and inference (let's say alternating evaluation of both), the number of programs for which termination can be guaranteed is considerably larger - if I'm not mistaken, but I may very well have gotten it wrong. Regards, Philip PS. I realize that for this dependent typing scenario is useless once Type Families are here. I can't wait for a GHC with TFs. I raise this question, simply to understand why inference was chosen exclusively.

2 3

Generalized newtype deriving 6.6 vs. 6.8
by Twan van Laarhoven 06 Nov '07

06 Nov '07

Hello, I noticed there is a difference in generalized newtype deriving between 6.6 and 6.8. In GHC 6.4.1 the following: > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > > import Control.Monad.Error > > newtype MyMonad m a = MyMonad (m a) > deriving (Monad, MonadError String) correctly gives a derived instance MonadError String m => MonadError String (MyMonad m) The new GHC 6.8.1 complains with: No instance for (MonadError String m) arising from the 'deriving' clause of a data type declaration at DeriveTest.hs:(5,0)-(6,36) Possible fix: add an instance declaration for (MonadError String m) When deriving the instance for (MonadError String (MyMonad m)) Generalizing the instance to MonadError e m => MonadError e (MyMonad m) works in both versions. Twan

3 2