- ghc-devs - Haskell.org

Windows linking
by Simon Peyton-Jones 07 Nov '13

07 Nov '13

Austin Ok with the new msys2 I get the too-many-symbols thing below. This didn't happen before. Maybe I can switch off dynamic linking? How? Simon Too many symbols in DLL compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll [5263] ghczm7zi7zi20131107_Var_zdfUniquableVar_closure [5264] ghczm7zi7zi20131107_Var_zdfUniquableVar_info [5265] ghczm7zi7zi20131107_Var_zdwsetVarUnique_closure [5266] ghczm7zi7zi20131107_Var_zdwsetVarUnique_info [5267] ghczm7zi7zi20131107_Var_zdwupdateTyVarKindM_closure [5268] ghczm7zi7zi20131107_Var_zdwupdateTyVarKindM_info [5269] ghczm7zi7zi20131107_Var_zdwzdcgmapMp_closure [5270] ghczm7zi7zi20131107_Var_zdwzdcgmapMp_info [5271] setHeapSize compiler/ghc.mk:472: recipe for target 'compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll' failed make[1]: *** [compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll] Error 1 make[1]: *** Deleting file 'compiler/stage2/build/libHSghc-7.7.20131107-0-ghc7.7.20131107.dll' Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 HEAD $

1 0

GHC error message on type mismatch
by Daniel Trstenjak 07 Nov '13

07 Nov '13

Hello, I don't know if I'm the only one struggeling with this GHC error message on type mismatches or it's because I'm not a full time Haskeller, or because I'm not a native english speaker. Couldn't match type `A' with `B´ Expected type: B Actual type: A My problem is with 'Expected' and 'Actual', that I'm often unsure if the compiler is "expecting" something or if I'm the expecting one and the same goes for "actual". I know that the compiler is the expecting one and that I'm given the actual thing, but it's quite often that I'm looking at this error and have to repeat this reasoning. It's strange, because normaly I can memorize such things quite good, but this one bothers me. Perhaps it would be easier for myself if 'Actual type' would be called e.g. 'Given type', I don't know, that just one of the two has a less generic meaning. Greetings, Daniel

1 0

Another CPP gotcha for the manual
by Mark Lentczner 07 Nov '13

07 Nov '13

Turns out that c pre-processing removes C style (/*…*/) comments. Of course, it will do this anywhere in the source. The following program can tell if it is compiled *-cpp* or not: module Main where (*/**) :: Double -> Double -> Double (*/**) a b = a / (2 ** b) howCompiled = if use > 1/16 then "normal" else "-cpp" where use = 1 */** 2 + 3 */** 4 main = putStrLn $ "compiled " ++ howCompiled When run: & runhaskell CppTest.hs compiled normal & runhaskell -cpp CppTest.hs compiled -cpp An example in the wild is in the package *wai-extra*, in the file *Network/Wai/Middleware/RequestLogger.hs* where the */* construct appears twice in the comments. Short of defining and implementing our own CPP-like preprocessing (something we might actually consider), I don't think there really is any fix for this, so the bug is that it should appear in the GHC documentation on CPP mode (§4.12.3), along with similar warnings about trailing back-slashes. Note that the way in which a multi-line comment is removed differs between *gcc* and *clang*. In *gcc*, the comment is removed and content of the line before the comment, and contents of the line after the comment are joined into a single line. In *clang*, the two line fragments are kept on separate lines. In both cases extra empty lines are added to keep the line count the same. The consequence of the *gcc* / *clang* difference is that neither the above code, nor wai-extra will compile with *clang*. Note: As far as I can tell this is not a *clang* bug, but a failure of specs: The C definition of comments and their removal is vague, and my guess is *gcc* choose its method based on historical use. The C++ definition makes it clear that comments are whitespace, even once removed, and so the *clang* method is correct. - Mark

7 10

Any GHC plans to adopt tf-random?
by Nicolas Frisby 06 Nov '13

06 Nov '13

Bugs #3575 #3620 have to do with splitting StdGens yielding dependent generators. The Haskell 2013 paper *Splittable Pseudorandom Number Generators Using Cryptographic Hashing* by Claessen and Pałka yielded the tf-random package on Hackage. Are there any plans to integrate these corrections into System.Random? Thanks.

2 2

Template Haskell and stage-1
by Simon Peyton-Jones 06 Nov '13

06 Nov '13

I'd like to make -XtemplateHaskell simply illegal in a stage-1 compiler. After all, it is! But for some reason we use the stage1 compiler to generate dependencies for the DPH libraries; those libraries have {-# LANGUAGE TemplateHaskell #-}, so the dependency generation fails. See below. But WHY do we generate deps for DPH with stage1? We don't *compile* the DPH libraries with stage1, because they need TH. Can't we just generate deps with stage2? For now I'll make it a warning, but could someone fix the build system? Thanks Simon mv libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.c_asm.tmp libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.c_asm "rm" -f libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.haskell.tmp "inplace/bin/ghc-stage1" -M -static -H32m -O -Werror -Wall -H64m -O0 -package-name dph-lifted-copy-0.8.0.1 -hide-all-packages -i -ilibraries/dph/dph-lifted-copy/. -ilibraries/dph/dph-lifted-copy/dist-install/build -ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/dist-install/build -Ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/. -optP-include -optPlibraries/dph/dph-lifted-copy/dist-install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package dph-base-0.8.0.1 -package dph-prim-par-0.8.0.1 -package ghc-7.7.20131106 -package random-1.0.1.1 -package template-haskell-2.9.0.0 -package vector-0.10.9.1 -Odph -funbox-strict-fields -fcpr-off -fno-warn-orphans -fno-warn-missing-signatures -XHaskell98 -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -Wwarn -no-user-package-db -rtsopts -odir libraries/dph/dph-lifted-copy/dist-install/build -hidir libraries/dph/dph-lifted-copy/dist-install/build -stubdir libraries/dph/dph-lifted-copy/dist-install/build -dep-makefile libraries/dph/dph-lifted-copy/dist-install/build/.depend-v-dyn.haskell.tmp -dep-suffix "" -dep-suffix "dyn_" -include-pkg-deps libraries/dph/dph-lifted-copy/./Data/Array/Parallel.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Closure.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Combinators.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/PArray.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Scalar.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/TH/Repr.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Lifted/Unboxed.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArr.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Base.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PData.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PDataInstances.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PRepr.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/PReprInstances.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Scalar.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/ScalarInstances.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/PArray/Types.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Base.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Bool.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Double.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Float.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Int.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Tuple.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prelude/Word8.hs libraries/dph/dph-lifted-copy/./Data/Array/Parallel/Prim.hs ghc-stage1: libraries/dph/dph-lifted-copy/Data/Array/Parallel/Lifted/TH/Repr.hs:1:14-28: Template Haskell requires GHC with interpreter support Perhaps you are using a stage-1 compiler? Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

5 4

Re: [commit: packages/integer-gmp] master: Clean-up Cmm of import/export primitives (dfd65a2)
by Gabor Greif 05 Nov '13

05 Nov '13

I suppose the integer-simple library also needs the <new-primops> treatment. Many embedded platforms won't have GMP. Should we just provide 'error "unimplemented"' stubs? Cheers, Gabor On 11/5/13, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/integer-gmp > > On branch : master > Link : > http://git.haskell.org/packages/integer-gmp.git/commitdiff/dfd65a28de3fe609… > >>--------------------------------------------------------------- > > commit dfd65a28de3fe6093d7e39fab6de960408abeb7e > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Tue Nov 5 21:26:17 2013 +0100 > > Clean-up Cmm of import/export primitives > > This is a follow-up to e94799c9 fixing the Cmm implementation of the > primops based on suggestions by Duncan Coutts. > > Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> > > >>--------------------------------------------------------------- > > dfd65a28de3fe6093d7e39fab6de960408abeb7e > cbits/gmp-wrappers.cmm | 33 +++++++++++++++++---------------- > 1 file changed, 17 insertions(+), 16 deletions(-) > > diff --git a/cbits/gmp-wrappers.cmm b/cbits/gmp-wrappers.cmm > index 186cfad..0da3db8 100644 > --- a/cbits/gmp-wrappers.cmm > +++ b/cbits/gmp-wrappers.cmm > @@ -71,47 +71,48 @@ import "integer-gmp" integer_cbits_decodeDouble; > > integer_cmm_importIntegerzh (P_ ba, W_ of, W_ sz, W_ e) > { > - P_ p; > - W_ mp_result1; > + W_ src_ptr; > + W_ mp_result; > > again: > STK_CHK_GEN_N (SIZEOF_MP_INT); > MAYBE_GC(again); > > - p = ba + SIZEOF_StgArrWords + of; > + mp_result = Sp - SIZEOF_MP_INT; > > - mp_result1 = Sp - SIZEOF_MP_INT; > + src_ptr = BYTE_ARR_CTS(ba) + of; > > - ccall __gmpz_init(mp_result1 "ptr"); > - ccall __gmpz_import(mp_result1 "ptr", sz, W_TO_INT(e), W_TO_INT(1), > W_TO_INT(0), 0, p "ptr"); > + ccall __gmpz_init(mp_result "ptr"); > + ccall __gmpz_import(mp_result "ptr", sz, W_TO_INT(e), W_TO_INT(1), > W_TO_INT(0), 0, src_ptr "ptr"); > > - return(TO_W_(MP_INT__mp_size(mp_result1)), > - MP_INT__mp_d(mp_result1) - SIZEOF_StgArrWords); > + return(TO_W_(MP_INT__mp_size(mp_result)), > + MP_INT__mp_d(mp_result) - SIZEOF_StgArrWords); > } > > +/* :: Int# -> ByteArray# -> MutableByteArray# s -> Word# -> Int# -> State# > s -> (# State# s, Word# #) */ > integer_cmm_exportIntegerzh (W_ s1, P_ d1, P_ mba, W_ of, W_ e) > { > - P_ dst; > + W_ dst_ptr; > W_ mp_tmp; > - W_ cnt_result1; > + W_ cnt_result; > > again: > STK_CHK_GEN_N (SIZEOF_MP_INT + SIZEOF_W); > MAYBE_GC(again); > > - mp_tmp = Sp - SIZEOF_MP_INT; > + mp_tmp = Sp - SIZEOF_MP_INT; > MP_INT__mp_alloc(mp_tmp) = W_TO_INT(BYTE_ARR_WDS(d1)); > MP_INT__mp_size(mp_tmp) = (s1); > MP_INT__mp_d(mp_tmp) = BYTE_ARR_CTS(d1); > > - cnt_result1 = Sp - (SIZEOF_MP_INT + SIZEOF_W); > - W_[cnt_result1] = 0; > + cnt_result = Sp - (SIZEOF_MP_INT + SIZEOF_W); > + W_[cnt_result] = 0; > > - dst = mba + SIZEOF_StgArrWords + of; > + dst_ptr = BYTE_ARR_CTS(mba) + of; > > - ccall __gmpz_export(dst "ptr", cnt_result1 "ptr", W_TO_INT(e), > W_TO_INT(1), W_TO_INT(0), 0, mp_tmp "ptr"); > + ccall __gmpz_export(dst_ptr "ptr", cnt_result "ptr", W_TO_INT(e), > W_TO_INT(1), W_TO_INT(0), 0, mp_tmp "ptr"); > > - return (W_[cnt_result1]); > + return (W_[cnt_result]); > } > > integer_cmm_int2Integerzh (W_ val) > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 2

Generics bugs
by Simon Peyton-Jones 05 Nov '13

05 Nov '13

Pedro, what's the status on #8479 #8468 #7346 ? Thanks, Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 2

Dynamically loading and unloading (C) object files
by Edsko de Vries 05 Nov '13

05 Nov '13

Hi guys, We started experimenting with dynamically loading and unloading C object files (using the GHC API). I have a simple example with an object file exporting a single symbol "f"; I have two versions of the object file; in the first one, f is defined int f() { return 1234; } The second one uses the value "4321" instead. I can dynamically load and unload these object files (using "linkObj" and "unlinkObj" from "ObjLink"). I can load the first, dynamically compile some Haskell code that imports this symbol, then upload this object file and load the second, and as long as I make sure that the Haskell code gets recompiled (perhaps a relink step suffices, haven't experimented an awful lot yet) it can then interact with the second object file. All this is good news -- in fact, it is more than we had hoped for, because ghci does not allow dynamically unloading or loading any object files at all. Object files specified on the command line are handled in initDynLinker and the ghci top-level function doesn't even get to see them, and we cannot load object files from inside a ghci session. So that leads me to wonder: are there limitations that we should be aware of? Have I simply been lucky so far? Any points or suggestions for things to try would be appreciated, Edsko

4 4

Why do we put GMP allocations on GHC heaps?
by Gergely Risko 04 Nov '13

04 Nov '13

Dear GHC gurus, I've been looking into how GHC uses GMP (with the hidden agenda of taking the work of replacing it with something that is BSD license compatible and so can be linked in and shipped statically by default). I think I more or less understand how GMP memory is managed and how the GC works together with it. Actually understanding the "how" was not that hard, everything is quite clearly commented. What I couldn't find any reference for is the "why". Why does GHC do this? Would it be possible to just not do this and let GMP malloc and free for itself (obviously we would have to call mpz_free here and there, but that seems doable). I have multiple ideas, but don't know which one (if any) is correct: - performance reasons, - memory defragmentation reasons, - GHC GC moves around stuff and that would somehow break, - the previous one + threads + race conditions. Second question: let's assume for a moment that we don't have any licensing issues with a GMP like library, can be linked statically into GHC, but we decide to go with the same allocation methodology as with GMP. Am I right when I think that linking statically solves the technical issues too. More concretely: openssl BN uses the openssl_malloc function can only be overridden openssl wide. But if we link statically, than this override won't affect external openssl library bindings, because the openssl symbols in our object files won't even be exported, right? Third question: is replacing with openssl bn an acceptable path to you guys? I saw that 6 years ago there were work on getting integer-simple performance wise good enough to be the default and then adding other bignum libraries externally, but none of this happened. I see how sexy project it is computer science wise to write a bignum library in Haskell, but will we really do it? Thanks, Gergely (errge)

9 21

GND and Safe Haskell
by Roman Cheplyaka 04 Nov '13

04 Nov '13

GHC HEAD still doesn't seem to recognize GND as Safe. I guess we can lift this restriction now that we have roles? Roman

2 1