- ghc-devs - Haskell.org

Show-like output of GHC data types
by Johan Tibell 08 Mar '13

08 Mar '13

I'm trying to better understand how a GHC produced TypedcheckedSource is composed. I have this little example: module Test ( mysum ) where import Data.List (foldl') mysum :: [Int] -> Int mysum xs = foldl' (+) 0 xs Pretty-printing TypecheckedSource gives me something like this: {{Test.hs:7:10-21} AbsBinds [] [] {Exports: [main:Test.mysum{v rgu} [lid] <= mysum{v agP} [lid] <>] Exported types: main:Test.mysum{v rgu} [lid] :: [ghc-prim:GHC.Types.Int{(w) tc 3J}] -> ghc-prim:GHC.Types.Int{(w) tc 3J} [LclId] Binds: {Test.hs:8:1-26} mysum{v agP} [lid] :: [ghc-prim:GHC.Types.Int{(w) tc 3J}] -> ghc-prim:GHC.Types.Int{(w) tc 3J} [LclId] mysum{v agP} [lid] ((xs{v agw} [lid] :: [ghc-prim:GHC.Types.Int{(w) tc 3J}])) = {Test.hs:8:12-26} (base:Data.List.foldl'{v r4u}) @ ghc-prim:GHC.Types.Int{(w) tc 3J} @ ghc-prim:GHC.Types.Int{(w) tc 3J} (((base:GHC.Num.+{v rt})) @ ghc-prim:GHC.Types.Int{(w) tc 3J} $dNum{v agU} [lid]) 0 ((base:GHC.Num.fromInteger{v 02A}) @ ghc-prim:GHC.Types.Int{(w) tc 3J} $dNum{v ahc} [lid] 0) xs{v agw} <> Evidence: EvBinds{}}} {Test.hs:7:1-21} main:Test.mysum{v rgu} :: {Test.hs:7:10-21} [ghc-prim:GHC.Types.Int{(w) tc 3J}] -> ghc-prim:GHC.Types.Int{(w) tc 3J} nonrec {Test.hs:8:1-26} main:Test.mysum{v rgu} main:Test.mysum{v rgu} (xs{v agw}) = {Test.hs:8:12-26} base:Data.List.foldl'{v r4u} (base:GHC.Num.+{v rt}) 0 (base:GHC.Num.fromInteger{v 02A}) xs{v agw} <> This doesn't really help me understand the AST any better, as this is essentially the source printed back to me. What I would like to see is something like: HsApp (HsApp (HsApp (HsVar "foldl'") (HsVar "+")) (HsLit 0)) (HsVar "xs") Is this possible today. If not, can we derive Show for all the GHC data types so it's possible to print their structure? P.S. An example of why the pretty-printed output is not very helpful in understanding the AST: the above simple example generates a HsWrap constructor, which is nowhere to be seen in the pretty-printed output. -- Johan

6 7

Re: Resource limits for Haskell
by Edward Z. Yang 08 Mar '13

08 Mar '13

Excerpts from Andrew Adams-Moran's message of Fri Mar 08 07:01:29 -0800 2013: > > This would correspond to the ability to "freeze" Haskell threads in > > mid-execution; no MVar blocking necessary. This is not possible with > > the current RTS. I don't know how hard it would be to do. > > We have a way to interrupt Haskell threads mid-execution; could that machinery be used? It is not difficult to imagine a circumstance where you would like to resume the thread after interrupting it; I don't think the current machinery can do that. Edward

1 0

Re: Setting up a sandboxed installation of GHC HEAD
by Jan Stolarek 07 Mar '13

07 Mar '13

> The way to do this is described on a wiki page in the developers corner: > http://hackage.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace (scroll down > to "Plan B" on this page) Thanks, that helped. What I should have mentioned is that I am sandboxing my GHC installations, so whenever I compile HEAD I can switch to a different sandbox and install the new compiler within that sandbox. Now I can just install packages into user database without worrying that my original database gets cluttered with duplicate libraries. I managed to install some of the packages using plan B. This is tedious (I'd rather have dependencies resolved, downloaded and installed automatically by cabal) but works as long as packages from hackage are compatible with HEAD. Unfortunately some of them are not, which prevents me from installing libraries that I need (like blaze-builder) but I guess that can't be helped. Janek

1 0

Setting up a sandboxed installation of GHC HEAD
by Jan Stolarek 05 Mar '13

05 Mar '13

I'm trying to set up a sandboxed installation of GHC HEAD with cabal-install and some other libraries. I need this to run some benchmarks on Repa library. Right now I'm having problems with bootstraping cabal-install. I managed to work around problems with some pakcages like HTTP that put upper bound on base version but I'm stuck with cabal-install itself. I modified dependency on unix package but now I'm getting some compilation errors. I could probably fix them but I guess that this is not the correct way of setting up a working GHC HEAD installation. So the question is how should I install cabal-install with HEAD ? Janek

3 3

SplitObjs not working
by Simon Peyton-Jones 04 Mar '13

04 Mar '13

Ian In a clean build with validate.mk set thus: GhcStage1HcOpts += -DDEBUG GhcLibHcOpts += -ticky -Wwarn SplitObjs = YES I get the error below on HEAD. Could something be wrong with the build system? I assume it's the SplitObjs=YES. Thanks Simon /usr/bin/find libraries/ghc-prim/dist-install/build/GHC/Classes_o_split libraries/ghc-prim/dist-install/build/GHC/CString_o_split libraries/ghc-prim/dist-install/build/GHC/Debug_o_split libraries/ghc-prim/dist-install/build/GHC/Magic_o_split libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers_o_split libraries/ghc-prim/dist-install/build/GHC/IntWord64_o_split libraries/ghc-prim/dist-install/build/GHC/Tuple_o_split libraries/ghc-prim/dist-install/build/GHC/Types_o_split -name '*.o' -print >> libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0.a.contents /usr/bin/find: 'libraries/ghc-prim/dist-install/build/GHC/Classes_o_split': No such file or directory /usr/bin/find: 'libraries/ghc-prim/dist-install/build/GHC/CString_o_split': No such file or directory /usr/bin/find: 'libraries/ghc-prim/dist-install/build/GHC/Debug_o_split': No such file or directory /usr/bin/find: 'libraries/ghc-prim/dist-install/build/GHC/Magic_o_split': No such file or directory /usr/bin/find: 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers_o_split': No such file or directory /usr/bin/find: 'libraries/ghc-prim/dist-install/build/GHC/IntWord64_o_split': No such file or directory /usr/bin/find: 'libraries/ghc-prim/dist-install/build/GHC/Tuple_o_split': No such file or directory /usr/bin/find: 'libraries/ghc-prim/dist-install/build/GHC/Types_o_split': No such file or directory make[1]: *** [libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0.a] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 simonpj@cam-05-unx:~/5builds/HEAD-2$

2 1

RE: [GHC] #7736: Parallel array enumeration causes compiler panic (enumFromToP)
by Simon Peyton-Jones 04 Mar '13

04 Mar '13

Manuel, is this something you might look at in due course? Simon | -----Original Message----- | From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets- | bounces(a)haskell.org] On Behalf Of GHC | Sent: 04 March 2013 00:17 | Cc: ghc-tickets(a)haskell.org | Subject: [GHC] #7736: Parallel array enumeration causes compiler panic | (enumFromToP) | | #7736: Parallel array enumeration causes compiler panic (enumFromToP) | -------------------------------+---------------------------------------- | -------------------------------+---- | Reporter: amosrobinson | Owner: | Type: bug | Status: new | Priority: normal | Component: Compiler | Version: 7.6.2 | Keywords: | Os: Unknown/Multiple | Architecture: Unknown/Multiple | Failure: Compile-time crash | Blockedby: | Blocking: | Related: | -------------------------------+---------------------------------------- | -------------------------------+---- | Enumeration doesn't work in parallel array comprehensions: | | {{{ | nums = [: 0 .. 100 :] | }}} | | causes a compiler panic. Interestingly, the panic seems to happen | before typechecking because if we add some nonsense: | | {{{ | other = 5 / "bad" | nums = [: 0 .. 100 :] | }}} | | it still panics. | | -- | Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7736> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

2 1

FW: [commit: ghc] tc-arrows: Rearrange the typechecking of arrows, especially arrow "forms" (49badc9)
by Simon Peyton-Jones 04 Mar '13

04 Mar '13

Ross I've pushed a new branch, tc-arrows, for the new typechecking of arrows, based on the discussion we had last week. It all compiles, but won't work because I have done nothing to the desugaring. It uses our new representation with (env, nested-tuple-with-unit-at-end) rather than (nested-tuple-with-env-at-the-end), so desugaring needs significant attention. Would you like to work on the desugarer? I'm out of my depth, but happy to advise. Thanks Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Simon Peyton Jones | Sent: 14 February 2013 16:08 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] tc-arrows: Rearrange the typechecking of arrows, | especially arrow "forms" (49badc9) | | Repository : ssh://darcs.haskell.org//srv/darcs/ghc | | On branch : tc-arrows | | http://hackage.haskell.org/trac/ghc/changeset/49badc91c52fc1f65a3ff5bfb3 | edaecbd617de61 | | >--------------------------------------------------------------- | | commit 49badc91c52fc1f65a3ff5bfb3edaecbd617de61 | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Thu Feb 14 15:25:23 2013 +0000 | | Rearrange the typechecking of arrows, especially arrow "forms" | | The typechecking of arrow forms (in GHC 7.6) is known to be bogus, | because it marches down tuple types that may not yet be fully worked | out, depending on when constraint solving happens. Moreover, | coercions are generated and simply discarded. The fact that it | works | at all is a miracle. | | This refactoring is based on a conversation with Ross, where we | rearranged the typing of the argument stack, so that the arrows | have the form | a (env, (arg1, (arg2, ...(argn, ())))) res | rather than | a (arg1, (arg2, ...(argn, env))) res | as it was before. | | This is vastly simpler to typecheck; just look at the beautiful, | simple type checking of arrow forms now! | | We need a new HsCmdCast to capture the coercions generated from | the argument stack. | | Current state of play: | * syntax done | * renamer done | * typechecker done | * desugarer NOT DONE | | So nothing will work yet, hence on a branch | | compiler/deSugar/Coverage.lhs | 3 + | compiler/deSugar/DsArrows.lhs | 6 +- | compiler/hsSyn/HsExpr.lhs | 13 ++- | compiler/hsSyn/HsUtils.lhs | 7 +- | compiler/parser/Parser.y.pp | 4 +- | compiler/parser/RdrHsSyn.lhs | 4 +- | compiler/rename/RnExpr.lhs | 4 +- | compiler/rename/RnTypes.lhs | 2 +- | compiler/typecheck/TcArrows.lhs | 270 ++++++++++++++++++-------------- | ------- | compiler/typecheck/TcHsSyn.lhs | 6 +- | 10 files changed, 156 insertions(+), 163 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 49badc91c52fc1f65a3ff5bfb3edaecbd617de61 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 3

Re: [commit: ghc] master: Change how dependency generation works; fixes #7381 (af072fc)
by David Terei 04 Mar '13

04 Mar '13

Ian, I think this patch or one related to it may have broken the expected behaviour. Previously I could do: $ ghc -M Main.hs but now executing the above gives the error "You must specify at least one -dep-suffix". I can get the old behaviour by doing: $ ghc -M Main.hs -dep-suffix='' If the new behaviour is the expected one, then the userguide is now out of date. Cheers, David On 2 November 2012 16:38, Ian Lynagh <igloo(a)earth.li> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/af072fc35d8dbe7962e62700da052… > >>--------------------------------------------------------------- > > commit af072fc35d8dbe7962e62700da052593e999c0ef > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Fri Nov 2 21:42:33 2012 +0000 > > Change how dependency generation works; fixes #7381 > > We now do the initial dependency generation for the vanilla way > regardless of what way flags and hisuf/osuf flags are given. This > makes it easier to generate the right dependency info in the end. > >>--------------------------------------------------------------- > > compiler/main/DriverMkDepend.hs | 41 ++++++++++++++++++++++---------------- > ghc.mk | 5 ++++ > ghc/ghc.mk | 2 +- > rules/build-dependencies.mk | 12 +---------- > 4 files changed, 31 insertions(+), 29 deletions(-) > > diff --git a/compiler/main/DriverMkDepend.hs b/compiler/main/DriverMkDepend.hs > index 953b2c4..7355e31 100644 > --- a/compiler/main/DriverMkDepend.hs > +++ b/compiler/main/DriverMkDepend.hs > @@ -51,7 +51,25 @@ import Data.Maybe ( isJust ) > doMkDependHS :: GhcMonad m => [FilePath] -> m () > doMkDependHS srcs = do > -- Initialisation > - dflags <- GHC.getSessionDynFlags > + dflags0 <- GHC.getSessionDynFlags > + > + -- We kludge things a bit for dependency generation. Rather than > + -- generating dependencies for each way separately, we generate > + -- them once and then duplicate them for each way's osuf/hisuf. > + -- We therefore do the initial dependency generation with an empty > + -- way and .o/.hi extensions, regardless of any flags that might > + -- be specified. > + let dflags = dflags0 { > + ways = [], > + buildTag = mkBuildTag [], > + hiSuf = "hi", > + objectSuf = "o" > + } > + _ <- GHC.setSessionDynFlags dflags > + > + when (null (depSuffixes dflags)) $ > + ghcError (ProgramError "You must specify at least one -dep-suffix") > + > files <- liftIO $ beginMkDependHS dflags > > -- Do the downsweep to find all the modules > @@ -263,24 +281,13 @@ writeDependency root hdl targets dep > ----------------------------- > insertSuffixes > :: FilePath -- Original filename; e.g. "foo.o" > - -> [String] -- Extra suffices e.g. ["x","y"] > - -> [FilePath] -- Zapped filenames e.g. ["foo.o", "foo.x_o", "foo.y_o"] > + -> [String] -- Suffix prefixes e.g. ["x_", "y_"] > + -> [FilePath] -- Zapped filenames e.g. ["foo.x_o", "foo.y_o"] > -- Note that that the extra bit gets inserted *before* the old suffix > - -- We assume the old suffix contains no dots, so we can strip it with removeSuffix > - > - -- NOTE: we used to have this comment > - -- In order to construct hi files with alternate suffixes, we > - -- now have to find the "basename" of the hi file. This is > - -- difficult because we can't just split the hi filename > - -- at the last dot - the hisuf might have dots in it. So we > - -- check whether the hi filename ends in hisuf, and if it does, > - -- we strip off hisuf, otherwise we strip everything after the > - -- last dot. > - -- But I'm not sure we care about hisufs with dots in them. > - -- Lots of other things will break first! > - > + -- We assume the old suffix contains no dots, so we know where to > + -- split it > insertSuffixes file_name extras > - = file_name : [ basename <.> (extra ++ "_" ++ suffix) | extra <- extras ] > + = [ basename <.> (extra ++ suffix) | extra <- extras ] > where > (basename, suffix) = case splitExtension file_name of > -- Drop the "." from the extension > diff --git a/ghc.mk b/ghc.mk > index c1544ad..6c0a29a 100644 > --- a/ghc.mk > +++ b/ghc.mk > @@ -138,6 +138,11 @@ ifeq "$(findstring v,$(GhcLibWays))" "" > $(error v is not in $$(GhcLibWays), and $$(DYNAMIC_BY_DEFAULT) is not YES) > endif > endif > +ifeq "$(GhcProfiled)" "YES" > +ifeq "$(findstring p,$(GhcLibWays))" "" > +$(error p is not in $$(GhcLibWays), and $$(GhcProfiled) is YES) > +endif > +endif > endif > > ifeq "$(phase)" "" > diff --git a/ghc/ghc.mk b/ghc/ghc.mk > index ac8ce66..809756e 100644 > --- a/ghc/ghc.mk > +++ b/ghc/ghc.mk > @@ -64,7 +64,7 @@ ghc_stage3_MORE_HC_OPTS += -threaded > endif > > ifeq "$(GhcProfiled)" "YES" > -ghc_stage2_MORE_HC_OPTS += -prof > +ghc_stage2_PROGRAM_WAY = p > endif > > ghc_stage1_PROG = ghc-stage1$(exeext) > diff --git a/rules/build-dependencies.mk b/rules/build-dependencies.mk > index 8442801..4a4f563 100644 > --- a/rules/build-dependencies.mk > +++ b/rules/build-dependencies.mk > @@ -22,18 +22,8 @@ $1_$2_depfile_c_asm = $$($1_$2_depfile_base).c_asm > > $1_$2_C_FILES_DEPS = $$(filter-out $$($1_$2_C_FILES_NODEPS),$$($1_$2_C_FILES)) > > -$1_$2_MKDEPENDHS_FLAGS = -dep-makefile $$($1_$2_depfile_haskell).tmp $$(foreach way,$$(filter-out v,$$($1_$2_WAYS)),-dep-suffix $$(way)) > +$1_$2_MKDEPENDHS_FLAGS = -dep-makefile $$($1_$2_depfile_haskell).tmp $$(foreach way,$$($1_$2_WAYS),-dep-suffix "$$(patsubst %o,%,$$($$(way)_osuf))") > $1_$2_MKDEPENDHS_FLAGS += -include-pkg-deps > -# Setting hisuf/osuf is a kludge. If DYNAMIC_BY_DEFAULT is on, dyn is > -# the first way, and p is another way, then without this kludge we run > -# ghc -M -hisuf dyn_hi -osuf dyn_o -dep-suffix dyn -dep-suffix p > -# which means we get dependencies for .dyn_hi/.dyn_o and .p_dyn_hi/.p_dyn_o > -# rather than .dyn_hi/.dyn_o and .p_hi/.p_o. > -# With the kludge we also get .hi/.o dependencies that we don't need, but > -# they don't do any harm. > -# We also specify -static, as otherwise we end up with some dependencies > -# on .dyn_dyn_hi files > -$1_$2_MKDEPENDHS_FLAGS += -static -hisuf hi -osuf o > > ifneq "$$(NO_GENERATED_MAKEFILE_RULES)" "YES" > > > > > _______________________________________________ > Cvs-ghc mailing list > Cvs-ghc(a)haskell.org > http://www.haskell.org/mailman/listinfo/cvs-ghc

1 0

Testsuite framework failures
by Jan Stolarek 04 Mar '13

04 Mar '13

I'm getting four framework failures during validation: *** framework failure for 2411(bad_name) This test has an invalid name *** framework failure for 3049(bad_name) This test has an invalid name *** framework failure for 4057(bad_name) This test has an invalid name *** framework failure: found an error while executing ../../libraries/parallel/tests/2185/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/parallel/tests/2185/all.T", line 1, in <module> test('2185', [skip_if_fast, reqlib('parallel'), Is it only me? Janek

1 0

[PATCH] Fix some ghci way testsuite failures on Windows
by Bill Tutt 02 Mar '13

02 Mar '13

On my 32bit Windows make fulltest run I got these two failures: ../../libraries/directory/tests getDirContents002 [bad stdout or stderr] (ghci) ../../libraries/process/tests process004 [bad stdout or stderr] (ghci) The problem here is that although the respective all.T files have normalise_exe, However, check_stderr_ok only normalizes away '.exe' when platform override files DO NOT exist and these test cases have platform overrides for mingw32. This seems like something to add a helper function for in testlib.py. Here's the patches for one way to accomplish fixing the problem. Fyi, Bill

1 0