- Glasgow-haskell-users

building ghc-7.1.20110125 under Mac OS X
by Pavel Perikov 01 Feb '11

01 Feb '11

hi list. i have to build ghc-7.1.20110125 under mac os x, so i grabbed the stable snapshot. Everything builds fine but the resulting compiler has problems with ld. It passes gcc flags to ld like "-march=-i686". Any ideas? BTW while still here. Are there any specific docs available on building 64-bit mac os x compiler? regards pavel

2 1

Kernel panic when building HEAD on OS X 10.6.4
by Johan Tibell 31 Jan '11

31 Jan '11

Hi, My computer dies a horrible death (i.e. kernel panic) whenever I build GHC from HEAD (currently using the "quickest" build configuration). Anyone had the same problem in the past? Any workarounds? Johan

4 4

FW: Problems with the directory package on windows
by Simon Peyton-Jones 31 Jan '11

31 Jan '11

Friends Can anyone help Tim with this? Tim, it'd be a good idea to say what version of Cabal you are using (cabal --version). Also you can download a pre-compiled cabal binary I believe, which would save you cabal-installing it. (Although it seems bad that you can get into a situation where that's necesary.) Simon -----Original Message----- From: Tim Sheard [mailto:sheard@cs.pdx.edu] Sent: 28 January 2011 22:48 To: Simon Peyton-Jones Subject: Problems with the directory package on windows Simon, I have been wrestling with following problem. I cannot get the Directory package to install on windows. Normally this comes with the Haskell Platform, but out of the box, it gives an error message that it can't find the directory package, even though ghc-pkg says its there. If you try and install it you get: Resolving dependencies... Downloading directory-1.1.0.0... Configuring directory-1.1.0.0... configure: WARNING: unrecognized options: --with-compiler checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for sys/types.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/stat.h... (cached) yes configure: creating ./config.status config.status: creating include/HsDirectoryConfig.h config.status: include/HsDirectoryConfig.h is unchanged configure: WARNING: unrecognized options: --with-compiler cabal.exe: Missing dependency on a foreign library: * Missing header file: HsDirectory.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal.exe: Error: some packages failed to install: directory-1.1.0.0 failed during the configure step. The exception was: ExitFailure 1 Some one suggested I need to update cabal, but cabal needs directory so it won't update, and both cabal install cabal-install cabal install cabal end in exactly the same kind of error. Have you ever seen this problem. I have searched everywhere for similar questions and have struggled several weeks with this. Any suggestions. Tim Sheard

1 0

handleToFd without closing of the file descriptor
by Volker Wysk 31 Jan '11

31 Jan '11

Hello I need to get the file descriptor, which is encapsulated inside a handle. handleToFd gets it, but the fd is closed. Is it possible to extract the fd from the handle, without modifying the handle? Greetings, Volker

2 1

Internships at MSR Cambridge, summer 2011 and later
by Simon Marlow 28 Jan '11

28 Jan '11

Hi folks, If you're a postgraduate and would like to spend 12 weeks in Cambridge working on a GHC or Haskell-related project, then apply for an internship: we have open slots starting in July this year and later. We've had many successful intern projects over the years. Lots more information here: http://hackage.haskell.org/trac/ghc/wiki/Internships The earliest available slot is the popular July-September summer slot, and for that you would need to have an application in by *Wednesday Feb 16*. However, we can also be flexible about start dates, and if you wanted to start later than July then you have more time to get an application in. By all means apply if you're interested in coming later in the year. Don't forget to email either Simon or myself if you intend to apply. This is very important: otherwise your application gets lost in the system. Cheers, Simon

1 0

Stack overflow weirdness
by Daniel Fischer 28 Jan '11

28 Jan '11

While tuning some code, the test programme suddenly started producing stack overflows. Reverting the code to a previous version did not revert that behaviour, code that previously produced a well-behaved binary now produced stack overflowing ones. But only with ghc-7.0.1, not with ghc-6.12.3 and ghc-6.12.1, and when compiled with optimisations (both, -O and -O2) and without profiling. A HEAD from October and a freshly darcs pulled HEAD displayed the same behaviour as 7.0.1. At some point I tried compiling with -fno-strictness (+ -O or -O2) which again produced well-behaved albeit somewhat slower binaries. An hour or so later, I again compile with -O2 without -fno-strictness to see whether the Core revealed something and, as suddenly as the stack overflows started, they disappeared, for the time being, I consistently get well-behaved binaries. A run of an overflowing binary with -hT -K32M produced a triangular graph with > 10MB Blackhole allocation and > 30MB TSO allocation in the peak. Obviously the behaviour is not reproducible, nevertheless, perhaps somebody has an idea what went on. Or should I attribute it to cosmic rays? Cheers, Daniel

2 2

handleToFd without closing of the file descriptor
by Volker Wysk 28 Jan '11

28 Jan '11

Hello I need to get the file descriptor, which is encapsulated inside a handle. handleToFd gets it, but the fd is closed. Is it possible to extract the fd from the handle, without modifying the handle? Greetings, Volker

2 1

Behavior of the inliner on imported class methods
by José Pedro Magalhães 26 Jan '11

26 Jan '11

Hello all, I fail to understand the behavior of the inliner in the following example: module M1 where > > class MyEnum a where myEnum :: [a] > > instance MyEnum () where myEnum = [()] > > module M2 where > > import M1 > > f1 = map (\() -> 'p') [()] > f2 = map (\() -> 'q') myEnum > The generated core code for M2 with ghc-7.0.1 -O is: M2.f22 :: GHC.Types.Char > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 1 2}] > M2.f22 = GHC.Types.C# 'q' > > M2.f11 :: GHC.Types.Char > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 1 2}] > M2.f11 = GHC.Types.C# 'p' > > M2.f21 :: () -> GHC.Types.Char > [GblId, > Arity=1, > Caf=NoCafRefs, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] > M2.f21 = > \ (ds_dch :: ()) -> case ds_dch of _ { () -> M2.f22 } > > M2.f2 :: [GHC.Types.Char] > [GblId, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 3 0}] > M2.f2 = > GHC.Base.map > @ () @ GHC.Types.Char M2.f21 M1.$fMyEnum()_$cmyEnum > > M2.f1 :: [GHC.Types.Char] > [GblId, > Caf=NoCafRefs, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 1 3}] > M2.f1 = > GHC.Types.: > @ GHC.Types.Char M2.f11 (GHC.Types.[] @ GHC.Types.Char) > So, why does the inliner fail to get rid of the map in f2, while correctly ditching it in f1? Note that using two modules is essential here: if the instance is in M2 (and thus becoming orphan), the inliner works "correctly". Adding INLINE/INLINABLE pragmas to myEnum doesn't improve things either. Is this a bug, or is there a reason for this behavior? Thanks, Pedro

3 3

GHC 7.0.1 (or very strange dimensional-0.8.0.1) bug
by Pavel Perikov 26 Jan '11

26 Jan '11

in ghci: Prelude> import Numeric.Units.Dimensional.Prelude as D Prelude Numeric.Units.Dimensional.Prelude> D.sqrt $ let s = 9 *~ (meter D.* meter) in s 3.0 m Prelude Numeric.Units.Dimensional.Prelude> D.sqrt $ 9 *~ (meter D.* meter) ghci hangs. complied and optimized code detects <<loop>> and let-trick from the above does not help. Here's the complete ghci -v session which contains all package versions ghci -v GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.0.1, for Haskell 98, stage 2 booted by GHC version 6.12.3 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.0.1-i386/usr/lib/ghc-7.0.1/package.conf.d/package.cache Using binary package database: /Users/pavel/.ghc/i386-darwin-7.0.1/package.conf.d/package.cache hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: -static Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> import Numeric.Units.Dimensional.Prelude as D hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser: hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. Prelude Numeric.Units.Dimensional.Prelude> D.sqrt $ let s = 9 *~ (meter D.* meter) in s hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package old-locale-1.0.0.2 ... linking ... done. Loading package time-1.2.0.3 ... linking ... done. Loading package numtype-1.0 ... linking ... done. Loading package dimensional-0.8.0.1 ... linking ... done. 3.0 m hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. Prelude Numeric.Units.Dimensional.Prelude> D.sqrt $ 9 *~ (meter D.* meter) hiding package containers-0.3.0.0 to avoid conflict with later version containers-0.4.0.0 hiding package QuickCheck-2.3.0.2 to avoid conflict with later version QuickCheck-2.4.0.1 wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-0713122c5f9038c6f0355a37e294e054 wired-in package integer-gmp mapped to integer-gmp-0.2.0.2-bfb191b8468e4d812a2bb92622cb246e wired-in package base mapped to base-4.3.0.0-1ea085b64a078bd9d5eaa9d8d525e35e wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template-haskell-2.5.0.0-f262af1f92a427f5cf4133bff041044f wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: HANG!

4 6

RE: GHC 7.0.1 (or very strange dimensional-0.8.0.1) bug
by Pavel Perikov 26 Jan '11

26 Jan '11

Thanks, Simon! Is the patch in the STABLE snapshot now? pavel On 26.01.2011, at 13:57, Simon Peyton-Jones wrote: > Right; it’s a bug all right. Happily, I committed a major patch two weeks ago, which cures the bug (I checked). The fix will be in 7.0.2. Meanwhile, if you can build the HEAD or get a development snapshot, you should be good to do. > > Thanks for reporting this > > Simon

2 1