March 2013 - ghc-devs

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

Re: [commit: ghc] master: Implement type family instance support for ":info" (#4175) (ca39e77)
by Gabriel Dos Reis 15 Mar '13

15 Mar '13

On Fri, Mar 15, 2013 at 10:55 AM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > Repository : http://darcs.haskell.org/ghc.git/ > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/ca39e777907f8b16d8ede82e040b6… I've noticed, for about a week now, that the link embedded in commit messages no longer work as Trac appears to be unable to resolve them :-(( -- Gaby

2 3

Re: Advance notice that I'd like to make Cabal depend on parsec
by Duncan Coutts 15 Mar '13

15 Mar '13

On Fri, 2013-03-15 at 12:37 +0800, Conrad Parker wrote: > On 14 March 2013 22:53, Duncan Coutts <duncan.coutts(a)googlemail.com> wrote: > > > > 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 > > When you say you've "made adjustments for" dodgy .cabal files in the > wild, do you mean that you'll send those maintainers patches that make > their cabal files less dodgy, or do you mean you've added hacks to > your parser to reproduce the quirky behaviour? The latter, but the egregiousness of the hacks is actually not too bad in the end. I don't find it revolting. For the worst examples I didn't make adjustments and those ones will break. I think I've made a reasonable judgement about the where to draw the line between the two. I can look into generating warnings in those cases (which is probably better than me emailing them). Duncan

1 0