- ghc-devs - Haskell.org

Re: Advance notice that I'd like to make Cabal depend on parsec
by Mark Lentczner 22 Mar '13

22 Mar '13

This thread is raising all sorts of questions for me: Is it essential, or even sensical, that the serialization format GHC needs for storing package info bear any relation to the human authored form? If not, the split out of the package types could be accomplished in a way where GHC uses simple show/read(P) style serialization for storage of package info, where as cabal-lib would use a lovely parsec parser for humans. I'd like this approach. The issue of putting the yet one more HP package into GHC's core packages is increasing the exposure of the difficulty of the current GHC/HP relationship. See also threads in HP's mailing list for why can't we bump some packages in GHC's core set for the next HP release. The split arrangement is strange because we have two groups making up what is in the HP, but they have different processes and aims. The complex technical relationship between the moving parts only heightens the difficulty. Perhaps the major cause is that because GHC is shipped as a library itself, it exposes all it's package dependencies. And as it is a large, and growing, piece of software, the list only wants to grow. But I wonder how often GHC is used as a library itself? If not often, then perhaps GHC should be shipped as two parts: Just a compiler (plus the small number of packages that the compiler forces), and ghc-lib as an optional, even separate, package - perhaps one with even a traditional way of depending on other packages. In otherwords, users that wanted to incorporate the ghc-lib into their programs would depend, and download, and configure, and build, ghc-lib indpenendant of the GHC binaries installed on their system. Perhaps then, GHC, the compiler, built from ghc-lib, would be bootstrapped not from the past compiler, but from the past HP..... Okay, perhaps that is all just fantasy. But, no other programming system operates the way we do. They all fall into one of two camps: - The dominant implementation is maintained, built, and shipped along with a large collection of "common packages". Examples: Python, Ruby, PHP, Java. - The dominant implementation is shipped as a bare tool, and large common libraries are maintained and shipped independently. Examples: C++ (think g++ and boost), JavaScript (think browsers, and jQuery). We are in the middle and, I think, experiencing growing pains because of it. - Mark On Sat, Mar 16, 2013 at 3:42 PM, dag.odenhall(a)gmail.com < dag.odenhall(a)gmail.com> wrote: > I'd love to have a proper parser and source-location-aware AST for sake of > editor/IDE tools, so +1 from me. If you don't end up doing this after all, > I'd still like to see your parser in a separate package, although I > understand if you don't feel like maintaining two parsers especially given > the tedious process for verifying they work similarly. I guess it could > still be useful in the same way we find haskell-src-exts useful despite > some incompatibilities with GHC. > > > On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts < > duncan.coutts(a)googlemail.com> wrote: > >> Hi folks, >> >> I want to give you advance notice that I would like to make Cabal depend >> on parsec. The implication is that GHC would therefore depend on parsec >> and thus it would become a core package, rather than just a HP package. >> So this would affect both GHC and the HP, though I hope not too much. >> >> The rationale is that Cabal needs to parse things, like .cabal files and >> currently we do not have a decent parser in the core libraries. By >> decent I mean one that can produce error messages with source locations >> and that doesn't have unpredictable memory use. The only parser in the >> core libraries at the moment is Text.ParserCombinators.ReadP from the >> base package and that fails my "decent" criteria on both counts. Its >> idea of an error message is (), and on some largish .cabal files we take >> 100s of MB to parse (I realise that the ReadP in the base package is a >> cutdown version so I don't mean to malign all ReadP-style libs out >> there). >> >> Partly due to the performance problem, the terrible .cabal file error >> messages, and partly because Doaitse Swierstra keeps asking me if .cabal >> files have a grammar, I've been writing a new .cabal parser. It uses an >> alex lexer and a parsec parser. It's fast and the error messages are >> pretty good. I have reverse engineered a grammar that closely matches >> the existing parser and .cabal files in the wild, though I'm not sure >> Doaitse will be satisfied with the approach I've taken to handling >> layout. >> >> Why did I choose parsec? Practicality dictates that I can only use >> things in the core libraries, and the nearest thing we have to that is >> the parser lib that is in the HP. I tried to use happy but I could not >> construct a grammar/lexer combo to handle the layout (also, happy is not >> exactly known for its great error messages). >> >> I've been doing regression testing against hackage and I'm satisfied >> that the new parser matches close enough. I've uncovered all kinds of >> horrors with .cabal files in the wild relying on quirks of the old >> parser. I've made adjustments for most of them but I will be breaking a >> half dozen old packages (most of those don't actually build correctly >> because though their syntax errors are not picked up by the parser, they >> do cause failure eventually). >> >> So far I've just done the outline parser, not the individual field >> parsers. I'll be doing those next and then integrate. So this change is >> still a bit of a ways off, but I thought it'd be useful to warn people >> now. >> >> Duncan >> >> >> _______________________________________________ >> cabal-devel mailing list >> cabal-devel(a)haskell.org >> http://www.haskell.org/mailman/listinfo/cabal-devel >> > >

10 17

constraint deduction bug?
by Gabor Greif 22 Mar '13

22 Mar '13

In context of a bigger source file I got this error from GHC (HEAD) Could not deduce (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv ~ 'Empty [KeySegment]) from the context (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv ~ 'Empty [KeySegment]) bound by a pattern with constructor Nil :: forall (k :: BOX). Sing (Inventory k) ('Empty k), in a pattern binding in 'do' block Can somebody confirm that this constraint should be trivially deducible from the context? Then I'll try to come up with a reduced repro case. Cheers, Gabor

4 4

RE: default library path in HEAD
by Simon Peyton-Jones 21 Mar '13

21 Mar '13

I have no idea. Ian may be able to help. Ian, or anyone else... any ideas? I would start with ghc-pkg list and ghc-pkg check Simon From: Ilya Sergey [mailto:ilya.sergey@imdea.org] Sent: 21 March 2013 01:25 To: Simon Peyton-Jones Subject: default library path in HEAD Hi Simon. I've run into some troubles trying to build the nofib with the current master branch. Apparently, something has changed in the default library path, so the stage2 compiler cannot find base modules: ~~~~~~~~~~~ /Users/ilya/repos/master-ghc/inplace/bin/ghc-stage2 -H64m -O -fasm -O -Rghc-timing -package array -H32m -hisuf hi -rtsopts -c Main.hs -o Main.o Main.hs:1:1: Failed to load interface for ‛Prelude’ There are files missing in the ‛base’ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. ~~~~~~~~~~~~ The library has been compiled with profiling options (added to the end of build.mk<http://build.mk>): GhcLibHcOpts += -ticky GhcRTSWays += t GhcThreaded = NO and BuildFlavour = devel2 But I don't think it is an issue. What am I doing wrong? Thanks. Ilya

2 1

Calling convention for JavaScript?
by Luite Stegeman 20 Mar '13

20 Mar '13

hi all, We've been making some progress with GHCJS [1] recently (preemptive lightweight threads, async io, black holes and async exceptions work in the new code generator now), but have run into a problem with FFI imports. So far we've been using the ccall import syntax: foreign import ccall "sin" :: CDouble -> CDouble This would import the JavaScript function `h$sin` (in order to reduce clashes with other JavaScript functions in foreign imports of existing Haskell packages). Other than the ccall name, which is just a minor niggle, this worked completely fine. Now we would like to extend this, for example: foreign import ccall "@cos" :: CDouble -> CDouble (@ would escape the usual `h$` prefixing) foreign import ccall "$r = $1.someMethod($2)" :: JSObject -> CDouble -> CDouble (inline JavaScript macro, similar to Fay and UHC-JS) Unfortunately GHC rejects these, since they're not valid C identifiers. What we need is some calling convention that just accepts any import string, but otherwise behaves like ccall. What would be a good way of doing this, is it possible without changing GHC? If not, would it be acceptable to add a calling convention? Suggestions welcome! luite [1] https://github.com/ghcjs/ghcjs/tree/gen2-64-alth

2 2

Re: [commit: ghc] master: Give hsc2hs different options in different stages; fixes #7705 (f1fcfff)
by Bill Tutt 19 Mar '13

19 Mar '13

If the bootstrapping compiler is the Haskell Platform on Windows this change can break the build if the Platofrm install directory includes spaces. Since before this change the intree gcc was always used on Windows, but now the bootstrapping ghc's gcc is used for CC_STAGE0 for hsc2hs invocations. Adding wrapping single quotes like $1_$2_HSC2HS_CC_OPTS and $1_$2_HSC2HS_LD_OPTS to the --cc and --ld options seems like the simplest and best solution. Fyi, Bill On Sat, Mar 2, 2013 at 9:43 AM, Ian Lynagh <igloo(a)earth.li> wrote: > > diff --git a/rules/distdir-opts.mk b/rules/distdir-opts.mk > index 748e27e..50cc05e 100644 > --- a/rules/distdir-opts.mk > +++ b/rules/distdir-opts.mk > @@ -79,10 +79,11 @@ $1_$2_HSC2HS_LD_OPTS:=$$(shell for i in > $$($1_$2_DIST_LD_OPTS); do echo \'--lfla > endif > > $1_$2_ALL_HSC2HS_OPTS = \ > - --cc=$$(WhatGccIsCalled) \ > - --ld=$$(WhatGccIsCalled) \ > + --cc=$$(CC_STAGE$3) \ > + --ld=$$(CC_STAGE$3) \ > $$(CONF_HSC2HS_OPTS) \ > $$(SRC_HSC2HS_OPTS) \ > + $$(SRC_HSC2HS_OPTS_STAGE$3) \ > --cflag=-D__GLASGOW_HASKELL__=$$(if $$(filter > 0,$3),$$(GhcCanonVersion),$$(ProjectVersionInt)) \ > --cflag=-D$$(HostArch_CPP)_HOST_ARCH=1 \ > --cflag=-D$$(HostOS_CPP)_HOST_OS=1 \ > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > >

2 1

Vaidation crash
by Simon Peyton-Jones 19 Mar '13

19 Mar '13

I got this at the end of validation on Windows. Any ideas? Simon Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "./quasiquotation/T4491/test.T", line 7, in <module> only_ways([config.ghc_th_way]), AttributeError: TestConfig instance has no attribute 'ghc_th_way' make[2]: Leaving directory `/c/code/HEAD/testsuite/tests' make[1]: Leaving directory `/c/code/HEAD/testsuite/tests'

2 1

Re: [commit: ghc] master: By default, use the dynamic way for programs in the GHC tree (b712667)
by Karel Gardas 19 Mar '13

19 Mar '13

Hello Ian, am I right assuming that this patch breaks ARM/Linux compilation which now fails with: ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds ghc.mk:133: *** dyn is not in $(GhcLibWays), but $(DYNAMIC_GHC_PROGRAMS) is YES. Stop. make: *** [all] Error 2 If so, will you fix this or shall I provide a patch? Thanks, Karel On 03/17/13 01:50 AM, Ian Lynagh wrote: > Repository : http://darcs.haskell.org/ghc.git/ > > On branch : master > > https://github.com/ghc/ghc/commit/b7126674a5f4ead9c73a6a2cbe0fbc85f7d36c12 > >> --------------------------------------------------------------- > > commit b7126674a5f4ead9c73a6a2cbe0fbc85f7d36c12 > Author: Ian Lynagh<ian(a)well-typed.com> > Date: Wed Mar 13 21:29:27 2013 +0000 > > By default, use the dynamic way for programs in the GHC tree > > In particular, this means that GHCi will use DLLs, rather than loading > object files itself. > > compiler/ghc.mk | 10 ++++++++++ > compiler/ghci/Linker.lhs | 28 +++++++++++----------------- > compiler/main/DynFlags.hs | 2 ++ > compiler/utils/Util.lhs | 9 +-------- > ghc.mk | 12 ++++++------ > mk/build.mk.sample | 2 +- > mk/config.mk.in | 9 ++++++++- > mk/validate-settings.mk | 4 ++-- > rts/Linker.c | 14 +++++++------- > rts/ghc.mk | 4 ++-- > rules/build-package-data.mk | 2 +- > rules/build-package-way.mk | 2 +- > rules/build-prog.mk | 4 ++-- > rules/shell-wrapper.mk | 4 ++-- > 14 files changed, 56 insertions(+), 50 deletions(-) > > > Diff suppressed because of size. To see it, use: > > git show b7126674a5f4ead9c73a6a2cbe0fbc85f7d36c12 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

3 3

Re: kgardas-linux-arm-head (HEAD), build 119, Failure
by Erik de Castro Lopo 18 Mar '13

18 Mar '13

Builder wrote: > kgardas-linux-arm-head (HEAD), build 119 > > Build failed > Details: http://darcs.haskell.org/ghcBuilder/builders/kgardas-linux-arm-head/119.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > touching clean-check files | Success > setting version date | Success > booting | Success > configuring | Success > creating check-remove-before | Success > compiling | Failure: Just (ExitFailure 2) > > Build failed > Details: http://darcs.haskell.org/ghcBuilder/builders/kgardas-linux-arm-head/119.html > > > ghc.mk:133: *** dyn is not in $(GhcLibWays), but $(DYNAMIC_GHC_PROGRAMS) is YES. Stop. I'm getting the same on powerpc-linux. Any clues? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 1

GHC HEAD build error
by Tuncer Ayaz 18 Mar '13

18 Mar '13

I cannot build GHC HEAD on i386 at the moment and the last successful build I have is from March 2nd. To be sure, I verified it fails with both a cleaned build tree and also a fresh clone. Tools used: ghc 7.6.2 alex 3.0.5 happy 1.18.10 cabal 1.17.0 gcc 4.7.2 glibc 2.17 autoconf 2.69 perl 5.16.2 BuildFlavor: perf Can anyone else reproduce the following build error? libraries/vector/Data/Vector/Fusion/Stream/Monadic.hs:104:1: Failed to load interface for `GHC.Desugar' Perhaps you haven't installed the profiling libraries for package `base'? Use -v to see a list of the files searched for. In the expression: ForceSpecConstr In the annotation: {-# ANN type SPEC ForceSpecConstr #-} make[1]: *** [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.p_o] Error 1 make: *** [all] Error 2

4 4

[PATCH] integer-gmp: mpn_gcd_1 allocate one Word on stack instead of 'sizeof (__mpz_struct)'
by Sergei Trofimovich 18 Mar '13

18 Mar '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> gmp.h defines 'mpn_gcd_1' as following: mp_limb_t mpn_gcd_1 (mp_srcptr /* aka 'mp_limb_t *' */, mp_size_t, mp_limb_t); Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- cbits/gmp-wrappers.cmm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cbits/gmp-wrappers.cmm b/cbits/gmp-wrappers.cmm index 0390eb5..8a201f1 100644 --- a/cbits/gmp-wrappers.cmm +++ b/cbits/gmp-wrappers.cmm @@ -394,9 +394,9 @@ integer_cmm_gcdIntzh (W_ int1, W_ int2) W_ r; W_ mp_tmp_w; - STK_CHK_GEN_N (1 * SIZEOF_MP_INT); + STK_CHK_GEN_N (1 * SIZEOF_W); - mp_tmp_w = Sp - 1 * SIZEOF_MP_INT; + mp_tmp_w = Sp - 1 * SIZEOF_W; W_[mp_tmp_w] = int1; (r) = ccall __gmpn_gcd_1(mp_tmp_w "ptr", 1, int2); -- 1.8.1.2

2 1