- ghc-devs - Haskell.org

Continuous Integration and Cross Compilation
by William Knop 08 Jul '14

08 Jul '14

Hello all, I’ve seen quite a few comments on the list and elsewhere lamenting the time it takes to compile and validate ghc. It’s troublesome not only because it’s inconvenient, but, more seriously, people are holding off on sending patches in which stifles development. I would like to propose a solution: 1. Implement proper cross-compilation, such that build and host may be different— e.g. a linux x86_64 machine can build ghc that runs on Windows x86. What sort of work would this entail? 2. Batch cross-compiled builds for all OSs/archs on a continuous integration service (e.g. Travis CI) or cloud service, then package up the binaries with the test suite. 3. Send the package to our buildbots, and run the test suite. 4. (optional) If using a CI service, have the buildbots send results back to the CI. This could be useful if we'd use GitHub for pulls in the future *. Cheers, Will * I realize vanilla GitHub currently has certain annoying limitations, though some of them are pretty easy to solve via the github-services and/or webhooks. I don’t think this conflicts with the desire to use Phabricator, either, so I’ll send details and motivations to that thread.

7 12

Re: GHC status report
by Miëtek Bak 07 Jul '14

07 Jul '14

On 2014-05-01, at 23:46, Edward Kmett <ekmett(a)gmail.com> wrote: > With the old custom linker we weren't able to get our custom MPFR linked in > properly on all platforms for use in ghci. > > On Macs we ran into some rather interesting problems. We could get it to > work for actual executables, but ghci would segfault with stuff resolved to > clearly wrong addresses. If I recall correctly it may have been some kind > of MachO symbol type that wasn't being resolved properly by the custom GHC > linker, perhaps? We chased after it off and on for a long time to no avail. Did these segfaults look like the following GHCi 7.6.3 crash? https://ghc.haskell.org/trac/ghc/ticket/9278 It looks like Jason ran into something similar last year: https://gist.github.com/dagit/5986541 Unfortunately, while the new linker in GHCi 7.8.2 doesn’t suffer from this problem, there appears to be another issue: https://ghc.haskell.org/trac/ghc/ticket/9277 Any clues? Thanks, -- Miëtek

1 0

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
by Luite Stegeman 05 Jul '14

05 Jul '14

How would you do reification with that approach? On Sat, Jul 5, 2014 at 9:59 PM, John Meacham <john(a)repetae.net> wrote: > Actually, I was looking into it a little, and template haskell could > effectively be implemented by a pre-processor and a portable library > that is compiler independent. If one could get ghc to spit out the > template haskell source after it expands it then that can be fed to > jhc as a quick first pass, but ideally the pre-processor TH would > create programs that can be run under the target compiler. that would > bring TH to every haskell compiler. > > John > > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery <allbery.b(a)gmail.com> > wrote: > > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > > <carter.schonwald(a)gmail.com> wrote: > >> > >> does JHC support template haskell? > > > > > > Pretty sure TH is too closely tied to ghc. > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allbery.b(a)gmail.com > ballbery(a)sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > -- > John Meacham - http://notanumber.net/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 2

"No entry for "Haskell CPP command"" error with testsuite
by Jan Stolarek 05 Jul '14

05 Jul '14

I'm trying to run the testsuite in my symlinked build tree, but keep getting this error: [killy@xerxes : /dane/projekty/ghc/build] make test make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt fast make[1]: Wejście do katalogu `/dane/projekty/ghc/build/testsuite/tests' ../mk/boilerplate.mk:168: ../mk/ghcconfig_dane_projekty_ghc_build_inplace_bin_ghc-stage2.mk: No such file or directory "/dane/projekty/ghc/build/inplace/bin/ghc-stage2" --make -o ../mk/ghc-config ../mk/ghc-config.hs No entry for "Haskell CPP command" in "/dane/projekty/ghc/build/inplace/lib/settings" make[1]: *** [../mk/ghc-config] Error 1 make[1]: Leaving directory `/dane/projekty/ghc/build/testsuite/tests' make: *** [test] Error 2 Help? Janek

5 6

GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
by Luite Stegeman 04 Jul '14

04 Jul '14

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…

6 9

Holiday
by Simon Peyton Jones 04 Jul '14

04 Jul '14

Friends I'm on holiday all next week, back 14 July. I'm not taking my laptop! Simon

1 0

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