- ghc-devs - Haskell.org

Head's up, yall: Cabal's dir layout changed
by Mark Lentczner 03 Jul '14

03 Jul '14

I just noticed that the default directory layout that cabal uses (under .cabal) has changed between 1.16 and 1.18. In particular: In 1.16 -- libsubdir: $pkgid/$compiler -- datasubdir: $pkgid -- docdir: $datadir/doc/$pkgid in 1.18 -- libsubdir: $arch-$os-$compiler/$pkgid -- datasubdir: $arch-$os-$compiler/$pkgid -- docdir: $datadir/doc/$arch-$os-$compiler/$pkgid This is a rather big change: When the same package is built with multiple compilers, before they were stored all under the same dir, now the packages are grouped by compiler. This change is actually better from a system-installer (and uninstaller) point of view, and the Mac platfrom has been shipping with a customer cabal wrapper that sets up the user's default in a similar fashion for years. This change breaks the existing uninstaller, and will require some retrenching on the platform... I'm going to try to reconcile the existing "Mac way" with the "new way" since they are closer. - Mark

2 1

Re: [commit: ghc] master: Re-add more primops for atomic ops on byte arrays (4ee4ab0)
by Páli Gábor János 03 Jul '14

03 Jul '14

Hello Johan, 2014-06-30 22:13 GMT+02:00 <git(a)git.haskell.org>: > commit 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49 > Author: Johan Tibell <johan.tibell(a)gmail.com> > Date: Fri Jun 27 13:48:24 2014 +0200 > > Re-add more primops for atomic ops on byte arrays It seems this change breaks the build on FreeBSD/i386 [1]: "inplace/bin/ghc-stage1" -o utils/dll-split/dist-install/build/tmp/dll-split -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/dll-split/dist-install/build -hidir utils/dll-split/dist-install/build -stubdir utils/dll-split/dist-install/build -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/filepath/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/containers/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/deepseq/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/array/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/base/dist-install/build' -optl-L'/usr/local/lib' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/integer-gmp/dist-install/build' -optl-L'/usr/local/lib' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build' -optl-L'/usr/home/ghc-builder/work/builder/tempbuild/build/rts/dist/build' -optl-liconv -optl-lcharset -optl-lgmp -optl-lm -optl-lrt -optl-lpthread -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.1.0 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell2010 -no-user-package-db -rtsopts -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../base-4.7.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer-gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin utils/dll-split/dist-install/build/Main.dyn_o /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_xor_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_and_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_nand_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_val_compare_and_swap_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_sub_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_add_8' /usr/home/ghc-builder/work/builder/tempbuild/build/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.9.20140703.so: undefined reference to `__sync_fetch_and_or_8' collect2: error: ld returned 1 exit status This probably due to the strict defaults of the FreeBSD of GCC, where march=i386 is assumed, which does not support the required CMPXCHG8B instruction. One would need at least an i586 to get that. It is not observed on GNU/Linux as it allegedly defaults to i586 code generation. The trivial patch below makes this explicit so now it could build: --- ghc-prim.cabal.orig 2014-07-03 03:06:16.000000000 +0200 +++ ghc-prim.cabal 2014-07-03 20:27:49.709087595 +0200 @@ -62,3 +62,6 @@ -- We need to set the package name to ghc-prim (without a version number) -- as it's magic. ghc-options: -package-name ghc-prim + -- Due to CMPXCHG8B, we have to ask for Pentium code generation. + cc-options: -march=i586 + However, my fellow developer, Konstantin Belousov pointed out that using CMPXCHG8B would officially require checking for the corresponding CPUID bit set, because that is what truly indicates the presence of that instruction. [1] http://haskell.inf.elte.hu/builders/freebsd-i386-head/304/10.html

1 0

Fwd: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
by member MP2E 03 Jul '14

03 Jul '14

I signed up for the mailing list to express my high level of interest in this project, I have been working with GHC 7.8 built as a cross compiler for Android and currently the only way to use libraries like lens, singletons, and anything else that uses Template Haskell is to add a patch to enable it in GHC during Stage1, and then to make drastic modifications to any cabal project source files that use TH and some hlint suggestions. Typically the current workflow for a cross-compiler is as follows: 1. Cross GHC 7.8 using the Stage1 TH patch and a few other patches available from Neurocyte. These need to be updated slightly as they are for GHC 7.6, I can post updated patches if anyone else is curious. I would be very interested in cleaning up and integrating the needed changes into GHC, if cross Template Haskell is to be implemented. 2. Create wrappers for hsc2hs and cabal for the cross compiler (I also have updated these) 3. Use a program called EvilSplicer on a log generated with 'cabal build --ghc-options=-ddump-splices 2>&1 | tee log' with the host compiler. This splices the host TH into the source files for use with the cross toolchain. You may notice this is cheating, and may not even work if the TH being generated is dependent on the target platform. 4. Remove most hlint hints used with the ANN pragma. For some reason these cause GHC to load shared objects which cause it to immediately crash(probably because of the whole host system/target system mismatch). I was told this is related to the TemplateHaskell issue Even getting lens to build is quite a chore, and I think with these changes, we could look forward to better iOS and Android support! I can't imagine the situation is much better for iOS devs at the moment. Again, I'd like to help get Android support polished, provided this change is ported and merged however I can :) On Wed, Jul 2, 2014 at 5:54 PM, Carter Schonwald <carter.schonwald(a)gmail.com > wrote: > This would probably be a great boon for those trying to use haskell for > Android and IOS right? how might the emulation setup work for those? > > > > > On Wed, Jul 2, 2014 at 2:20 PM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > >> wow, this is great work! >> >> If theres a clear path to getting the generic tooling into 7.10, i'm all >> for it :) (and willing to help on concrete mechanical subtasks) >> >> >> On Wed, Jul 2, 2014 at 12:14 PM, Luite Stegeman <stegeman(a)gmail.com> >> wrote: >> >>> hi all, >>> >>> I've added some code [1] [2] to GHCJS to make it run Template Haskell >>> code on node.js, rather than using the GHC linker. GHCJS has supported TH >>> for a long time now, but so far always relied on native (host) code for it. >>> This is the main reason that GHCJS always builds native and JavaScript code >>> for everything (another is that Cabal Setup.hs scripts need to be compiled >>> to some host-runnable form, but that can also be JavaScript if you have >>> node.js) >>> >>> Now besides the compiler having to do twice the work, this has some >>> other disadvantages: >>> >>> - Our JavaScript code has the same dependencies (packages) as native >>> code, which means packages like unix or Win32 show up somewhere, depending >>> on the host environment. This also limits our options in choosing >>> JS-specific packages. >>> - The Template Haskell code runs on the host environment, which might be >>> slightly different from the target, for example in integer size or >>> operating system specific constants. >>> >>> Moreover, building native code made the GHCJS installation procedure >>> more tricky, making end users think about libgmp or libiconv locations, >>> since it basically required the same preparation as building GHC from >>> source. This change will make installing much easier and more reliable (we >>> still have to update the build scripts). >>> >>> How it works is pretty simple: >>> >>> - When any code needs to be run on the target (hscCompileCoreExpr, >>> through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with >>> the thrunner.js [3] script, >>> - GHCJS sends its RTS and the Template Haskell server code [1] to >>> node.js, the script starts a Haskell thread running the server, >>> - for every splice, GHCJS compiles it to JavaScript and links it using >>> its incremental linking functionality. The code for the splice, including >>> dependencies that have not yet been sent to the runner (for earlier >>> splices), is then sent in a RunTH [4] message, >>> - the runner loads and runs the code in the Q monad, can send queries to >>> GHCJS for reification, >>> - the runner sends back the result as a serialized Template Haskell AST >>> (using GHC.Generics for the Binary instances). >>> >>> All Template Haskell functionality is supported, including recent >>> additions for reifying modules and annotations. I still need to clean up >>> and push the patches for the directory and process packages, but after >>> that, the TH code can read/write files, run processes and interact with >>> them and make network connections, all through node.js. >>> >>> Now since this approach is in no way specific to JavaScript, I was >>> wondering if there's any interest in getting this functionality into GHC >>> 7.10 for general cross compilation. The runner would be a native (target) >>> program with dynamic libraries (or object files) being sent over to the >>> target machine (or emulator) for the splices. >>> >>> Thanks to Andras Slemmer from Prezi who helped build the initial proof >>> of concept (without reification) at BudHac. >>> >>> cheers, >>> >>> Luite >>> >>> [1] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261… >>> [2] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812… >>> [3] >>> https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261… >>> [4] >>> https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812… >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > >

2 1

GenericsPropositionalEquality [Was: Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index]
by Gabor Greif 03 Jul '14

03 Jul '14

[added Pedro and Richard to "to:"] On 6/30/14, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > | Yes I have a branch, and it works! A bunch of things is still missing > | (notably record selectors), but I have a proof-of-concept with a gdiff > | library hooked up to GHC.Generics, and by appealing to type-level > | reasoning I can obtain a difference tree from True to False (which > | looks good) by using the reflection (i.e. class Generic) only, no need > | for TH or hand-coding. Comparing bigger trees (and then 'patch'ing > | them) appears to be SMOP from here. > > Do you have a wiki page explaining what "it" is (the thing that works). Here is a wiki page https://ghc.haskell.org/trac/ghc/wiki/GenericsPropositionalEquality you all are invited to make suggestions, ask questions and generally beautify. > > | instance Datatype (Dat "MyModule" "Foo") ... > | > | I get an 'orphan instance' warning. I believe that these are harmless, > > The downside of orphan instances is that GHC must visit every .hi file that > has an orphan instance, just in case it contains a relevant instance decl. > That slows down *every* compilation, whether or not it uses the instance. > > The best way to get rid of it is to declare something local that is "from > this module". Something like > > data MyModule_Foo > instance DataType (Dat MyModule_Foo) where ... > > Now MyModule_Foo is a data type from the module currently being compiled. > That tells GHC which .hi file to look in, and means the instance isn't > orphan. Yes I see, I noted it in the discussion and came up with a conservative approach (to be implemented). Furter opinions? Please add to the wiki. Thanks and cheers, Gabor > > Simon > > | so is there a way to suppress them? Since I never insert tyvars in the > | instance head, there should never be any overlap too. > | > | Cheers, > | > | Gabor > | > | On 6/30/14, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > | > You'll need to give a lot more info than this before I can help Gabor. > | > Currently I have only the vaguest idea about what you are trying to > | > accomplish. Is there a wiki page that describes the design (user's eye > | > view) in detail? > | > > | > I see you have a branch. If you are stuck, and give me repro > | instructions, > | > I can attempt to help. > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of > | Gabor > | > | Greif > | > | Sent: 27 June 2014 17:51 > | > | To: ghc-devs > | > | Subject: Resolved+new Q: TypeLits question, how to build a Type > | > | Application with Symbol index > | > | > | > | I succeeded to solve all of them :-) > | > | > | > | But now I am blocked on on a panic > | > | > | > | "not in scope during type checking, but it passed the renamer". > | > | > | > | I suspect that while "deriving Generic" some instances are defined in > | > | some empty TcEnv, which does not contain my definition in context. > | > | > | > | Is there a way to inject some type constructor into the TcEnv? > | > | > | > | Thanks, > | > | > | > | Gabor > | > | > | > | On 6/27/14, Gabor Greif <ggreif(a)gmail.com> wrote: > | > | > Hello devs, > | > | > > | > | > I have > | > | > > | > | > {{{ > | > | > data D (n :: Symbol) > | > | > }}} > | > | > > | > | > in my module, and I want to obtain a type > | > | > > | > | > {{{ > | > | > D "YAY!" > | > | > }}} > | > | > > | > | > programmatically. Where can I find code that performs this (or > | > | > something similar)? > | > | > > | > | > 1) I have to look up |D| in the current TyEnv (what if it is in a > | > | > specific module?), > | > | > 2) I have to build the type index (of kind Symbol), this involves > | > | > FastString, looks non-trivial, > | > | > 3) Apply 1) on 2), this is easy. > | > | > > | > | > Any hints welcome! > | > | > > | > | > Thanks and cheers, > | > | > > | > | > Gabor > | > | > > | > | > > | > | > PS: some morsels I have so far: > | > | > > | > | > for 1) > | > | > compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule > | (fsLit > | > | > "GHC.Generics") > | > | > > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs(a)haskell.org > | > | http://www.haskell.org/mailman/listinfo/ghc-devs > | > >

2 1

GHC 7.8.3 release
by Austin Seipp 03 Jul '14

03 Jul '14

Hello all, After a long week, I've finally gotten a little time to reply to emails, and I mainly have one question I'd like to ask. First, please direct your attention to this: https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=pa… This is the 7.8.3 milestone, but it only considers things that are: - 1) Fixed - 2) Going to be merged - 3) Are a patch to be still merged. That is, it is a solid representation of the difference between 7.8.2 and the 7.8 branch tip. The question is: when should we do the release? There are several bugs there that seem quite problematic for users - #9045, #7097, #9001, #8768 and #9078 in particular. If these bugs are really problematic (and I sort of feel they are) then the release can happen soon. I can do it within a week from now, and we could punt more to a 7.8.4 release. I ask this because my time to dedicate to GHC is a bit thin right now, so you must help me decide what's important! So please let me know - just a general vote in favor of doing it within some X timeframe (even 'real soon' or 'a week would be great') would be nice. PS: I apologize for the lack of status updates and brief email - my time for GHC has been in very short order the past two weeks in particular, and I've finally just returned to a computer (not mine) for right now to ask this. PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

13 21

Help needed: parsing pattern synonym contexts
by Dr. ERDI Gergo 02 Jul '14

02 Jul '14

Hi, I'm working on adding type signatures to pattern synonyms. The syntax I'm after would look something like, e.g.: pattern (Eq b) => P Int (Bool, b) (f [a]) :: (Show a) => Maybe [a] My problem is with parsing the two contexts. I wrote the parser in the following way, which I felt natural (actions omitted for brevity) pattern_synonym_sig :: { LSig RdrName } : 'pattern' patsyn_context patsyn_stuff '::' patsyn_context type patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType RdrName)) } : constr_stuff patsyn_context :: { LHsContext RdrName } : {- empty -} | forall context '=>' However, this doesn't work, no matter if those contexts are present or not. If I remove both contexts from the rules, i.e. if I replace pattern_synonym_sig with : 'pattern' patsyn_stuff '::' type then parsing succeeds when there are no contexts on either side. I've also tried : 'pattern' patsyn_stuff '::' ctype with the intention of recovering the required context from the ctype (and I could do similar tricks to get the provided context from the patsyn_stuff by using a modified version of constr_stuff); however, even that doesn't work as I expected it, i.e. with this latter version, this: pattern Single a :: (Eq a) => [a] fails with a parse error on "::". Can someone help me out here please? Thanks, Gergo

4 8

Code redundancy in PrelNames?
by Jan Stolarek 02 Jul '14

02 Jul '14

I'm looking at PrelNames.lhs and I believe there is some redundancy that can also lead to confusion. Consider these definitions: bindMName = methName gHC_BASE (fsLit ">>=") bindMClassOpKey arrAName = varQual aRROW (fsLit "arr") arrAIdKey Former is defined as "methName", while the latter is "varQual". These are defined like this: varQual :: Module -> FastString -> Unique -> Name varQual = mk_known_key_name varName mk_known_key_name :: NameSpace -> Module -> FastString -> Unique -> Name mk_known_key_name space modu str unique = mkExternalName unique modu (mkOccNameFS space str) noSrcSpan methName :: Module -> FastString -> Unique -> Name methName modu occ unique = mkExternalName unique modu (mkVarOccFS occ) noSrcSpan Expanding the call to mk_known_key_name in varQual the RHS of varQual becomes : mkExternalName unique modu (mkOccNameFS varName str) noSrcSpan Now, the call to "mkVarOccFS occ" in methName resolves to "mkOccNameFS varName occ", making the call to varQual identical to methName. Is this redundancy a conscious choice or just an accident? If it's conscious then what is the purpose? I spent several minutes trying to understand why bindMName and arrAName are defined differently. Names suggest that bindMName is a method, while arrAName is a qualified variable. I find this confusing and I think it would be better to drop varQual in favour of methName. Thoughts? Janek

2 1

Fixing Trac #9046 (Panic in GHCi when using :print).
by Vitaly Bragilevsky 02 Jul '14

02 Jul '14

Hello, I am trying to fix the bug #9046 (Panic in GHCi when using :print). I've discovered that It was introduced by this SPJ's commit (25 Nov 2013): https://ghc.haskell.org/trac/ghc/changeset/a8ac471d435214dbdc1fa70f938c6312… and especially by this change: -type QuantifiedType = ([TyVar], Type) -- Make the free type variables explicit +type QuantifiedType = ([TyVar], Type) + -- Make the free type variables explicit + -- The returned Type should have no top-level foralls (I believe) quantifyType :: Type -> QuantifiedType --- Generalize the type: find all free tyvars and wrap in the appropiate ForAll. -quantifyType ty = (varSetElems (tyVarsOfType ty), ty) +-- Generalize the type: find all free and forall'd tyvars +-- and return them, together with the type inside, which +-- should not be a forall type. +-- +-- Thus (quantifyType (forall a. a->[b])) +-- returns ([a,b], a -> [b]) + +quantifyType ty = (varSetElems (tyVarsOfType rho), rho) + where + (_tvs, rho) = tcSplitForAllTys ty While this change looks reasonable to me it breaks exploiting thunks created by `:print` ghci's command from polymorphic values. Before this change we could have: $ ghci -fprint-explicit-foralls GHCi, version 7.6.3.20130421: http://www.haskell.org/ghc/ :? for help > :print length length = (_t1::forall a. [a] -> Int) > _t1 [1,2,3] 3 And now we have: $ ghci -fprint-explicit-foralls GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > :print length length = (_t1::[a] -> Int) > _t1 [1,2,3] ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcTyVarDetails a{tv arw} [tv] This particular panic is caused by unification (compiler/typecheck/TcUnify.lhs line 1042). In case of `read` instead of `length` we get panic even earlier in simplification (compiler/typecheck/TcSimplify line 85). The concrete reason for the panic is wrong constructor used for tyvar (TyVar instead of TcTyVar). I see several ways to fix this: 1) rollback to forall-types in `:print` (requires change in cvObtainTerm, RtClosureInspect.hs); 2) skolemise free tyvar to RuntimeUnk (it becomes TcTyVar then): a) in cvObtainTerm; b) somewhere before typechecking. I can't decide the correct way to fix this bug or maybe there are other alternatives. Anyway I am ready to work on this though I need some advice. With best regards, Vitaly Bragilevsky

2 1

Why we need CCS entries in apply functions (rts/Apply.cmm and rts/StgStdThunks.cmm)
by Ömer Sinan Ağacan 01 Jul '14

01 Jul '14

Hi all, Code for entering cost-centres before executing the function/thunk body is generated in `compiler/codeGen/StgCmmBind.hs`, by `thunkCode` and `closureCodeBody` functions. But we also have some `enterCostCentreThunk` and `enterCostCentreFun` calls in `rts/Apply.cmm` and `rts/StgStdThunks.cmm`. I'm wondering why are those necessary. Thunk/function bodies already have CCS entries generated by functions in StgCmmBind so I'm having trouble seeing the need for this additional entries. Can anyone explain those to me? Thanks, --- Ömer Sinan Ağacan http://osa1.net

1 0

the case of the missing Cabal doc
by Mark Lentczner 01 Jul '14

01 Jul '14

In times of yore (prior to 7.8), when GHC build a bindist, it included the generated HTML manual for Cabal. As of 7.8, this seems to have gone missing-in-action. Anyone know where it went? - Mark

2 2